Well-Architected Framework のセキュリティの柱におけるこの原則では、クラウド アプリケーション、サービス、プラットフォームの設計に堅牢なセキュリティ機能、制御、プラクティスを組み込むための推奨事項が示されています。Google Cloud アイデア出しから運用まで、セキュリティは設計プロセスのあらゆる段階に不可欠な要素として組み込まれることで、より効果を発揮します。
原則の概要
Google の設計によるセキュリティへの取り組みの概要で説明したように、 セキュア バイ デフォルトと設計によるセキュリティは、しばしば同じ意味で使用されますが、 安全なシステムを構築するためのアプローチは異なります。どちらのアプローチも脆弱性を最小限に抑えてセキュリティを強化することを目的としていますが、範囲と実装が異なります。
- デフォルトでセキュリティを確保する設計: システムのデフォルト 設定が安全なモードに設定されていることを確認し、ユーザーや 管理者がシステムを保護するための操作を行う必要性を最小限に抑えることに重点を置いています。このアプローチは、すべてのユーザーにベースライン レベルのセキュリティを提供することを目的としています。
- 設計によるセキュリティ: システムの開発ライフサイクル全体を通じて、セキュリティ上の 考慮事項をプロアクティブに組み込むことを重視しています。このアプローチは、潜在的な脅威と脆弱性を早期に予測し、リスクを軽減する設計を選択することです。このアプローチでは、安全なコーディング手法を使用し、セキュリティ レビューを実施し、設計プロセス全体にセキュリティを組み込みます。設計によるセキュリティは、開発プロセスを導く包括的な理念であり、セキュリティが後付けではなく、システムの設計に不可欠な要素となるようにします。
推奨事項
クラウド ワークロードに設計によるセキュリティ原則を実装するには、次のセクションの推奨事項を検討してください。
- ワークロードの保護に役立つシステム コンポーネントを選択する
- 階層化されたセキュリティ アプローチを構築する
- 強化された証明済みのインフラストラクチャとサービスを使用する
- 保存データと転送中データを暗号化する
ワークロードの保護に役立つシステム コンポーネントを選択する
この推奨事項は、すべての 重点分野に関連しています。
効果的なセキュリティを実現するための基本的な決定は、プラットフォーム、ソリューション、サービスを構成する堅牢なシステム コンポーネント（ハードウェア コンポーネントとソフトウェア コンポーネントの両方）を選択することです。セキュリティ攻撃の対象領域を減らし、潜在的な損害を制限するには、これらのコンポーネントのデプロイ パターンとその構成を慎重に検討する必要があります。
アプリケーション コードでは、脆弱性のクラスを排除するために、シンプルで安全かつ信頼性の高いライブラリ、抽象化、アプリケーション フレームワークを使用することをおすすめします。ソフトウェア ライブラリの脆弱性をスキャンするには、サードパーティ ツールを使用できます。また、 Assured Open Source Software を使用すると、 Google が使用して保護しているオープンソース ソフトウェア（OSS）パッケージを使用することで、ソフトウェア サプライ チェーンのリスクを軽減できます。
インフラストラクチャでは、安全な運用をサポートし、セキュリティ要件とリスク許容レベルに沿ったネットワーキング、ストレージ、コンピューティングのオプションを使用する必要があります。インフラストラクチャのセキュリティは、インターネットに公開されるワークロードと内部ワークロードの両方で重要です。
この推奨事項をサポートする他の Google ソリューションについては、 次を ご覧ください。シフトレフト セキュリティを実装する
階層化されたセキュリティ アプローチを構築する
この推奨事項は、次の 重点分野に関連しています。
- AI と ML のセキュリティ
- インフラストラクチャのセキュリティ
- ID とアクセスの管理
- データ セキュリティ
多層防御アプローチを適用して、アプリケーションとインフラストラクチャ スタックの各レイヤにセキュリティを実装することをおすすめします。
プラットフォームの各コンポーネントのセキュリティ機能を使用します。アクセスを制限し、セキュリティ インシデントが発生した場合の潜在的な影響の範囲（つまり、影響範囲）を特定するには、次の操作を行います。
- 可能であれば、柔軟性に対応するためにシステムの設計を簡素化します。
- 各コンポーネントのセキュリティ要件を文書化します。
- 復元力と復旧の要件に対応するために、堅牢なセキュリティ メカニズムを組み込みます。
セキュリティ レイヤを設計するときは、リスク評価を実施して、内部セキュリティ要件と外部規制要件を満たすために必要なセキュリティ機能を決定します。クラウド環境に適用され、規制要件に関連する業界標準のリスク評価フレームワークを使用することをおすすめします。たとえば、Cloud Security Alliance（CSA）は Cloud Controls Matrix（CCM）を提供します。 リスク評価では、リスクのカタログと、リスクを軽減するための対応するセキュリティ制御が提供されます。
リスク評価を実施する際は、クラウド プロバイダと責任共有契約を締結していることを念頭に置いてください。そのため、クラウド環境におけるリスクは、オンプレミス環境におけるリスクとは異なります。たとえば、オンプレミス環境ではハードウェア スタックの脆弱性を軽減する必要があります。一方、クラウド環境では、こうしたリスクはクラウド プロバイダが負担します。また、クラウド プロバイダごとに、IaaS、PaaS、SaaS サービス間で責任共有の境界が異なることに注意してください。
潜在的なリスクを特定したら、技術的、管理的、運用上の制御、契約上の保護、サードパーティの証明書を使用して、軽減計画を設計して作成する必要があります。また、脅威 モデリング手法（ OWASP アプリケーション脅威モデリング手法など）を使用すると、 潜在的なギャップを特定し、ギャップに対処するためのアクションを提案できます。
強化された証明済みのインフラストラクチャとサービスを使用する
この推奨事項は、すべての 重点分野に関連しています。
成熟したセキュリティ プログラムは、セキュリティ速報で説明されている新しい脆弱性を軽減します。また、セキュリティ プログラムでは、既存のデプロイの脆弱性を修正し、VM イメージとコンテナ イメージを保護するための修復も提供する必要があります。イメージの OS とアプリケーション に固有の強化ガイドや、 Center of Internet Security（CIS）が提供するベンチマークなどを使用できます。
Compute Engine VM にカスタム イメージを使用する場合は、イメージに自分でパッチを適用する必要があります。また、Google が提供する キュレートされた OS イメージを使用することもできます。 このイメージには定期的にパッチが適用されます。Compute Engine VM でコンテナを実行するには、 Google がキュレートした Container-Optimized OS イメージを使用します。 Google はこれらのイメージのパッチと更新を定期的に行っています。
GKE を使用している場合は、クラスタノードに常に最新のパッチが適用されるように、 ノードの自動アップグレード を有効にすることをおすすめします。Google では、GKE コントロール プレーンを管理し、自動更新を行ってパッチを適用しています。コンテナの攻撃対象領域をさらに減らすには、 distroless イメージを使用します。 Distroless イメージは、セキュリティに配慮したアプリケーション、マイクロサービス、イメージサイズと攻撃対象領域の最小化が最優先される状況に最適です。
機密性の高いワークロードには Shielded VMを使用します。 Shielded VM は、VM の起動サイクル中に悪意のあるコードが読み込まれることを防ぎます。 Shielded VM インスタンスは、ブート セキュリティを提供して整合性をモニタリングし、 the Virtual Trusted Platform Module（vTPM）を使用します。
SSH アクセスを保護するために、 OS Login を使用すると、従業員は SSH 認証鍵に依存することなく、 Identity and Access Management（IAM）権/3} 限を信頼できる情報源として使用して VM に接続できます。したがって、組織全体で SSH 認証鍵を管理する必要はありません。OS Login では、管理者による従業員のライフサイクルへのアクセスが関連付けられます。そのため、従業員がロールを変更したり、退職した場合、そのユーザーのアクセス権はそのユーザーのアカウントで取り消されます。OS Login は Google の 2 要素認証もサポートしています。 これにより、アカウントの乗っ取り攻撃に対するセキュリティを強化できます。
GKE では、アプリケーション インスタンスは Docker コンテナ内で実行されます。定義済みのリスク プロファイルを有効にして、ユーザーがコンテナを変更できないようにするには、コンテナをステートレスにし、変更されないようにします。不変性の原則は、従業員がコンテナを変更したり、コンテナにインタラクティブにアクセスしないことを意味します。コンテナを変更する必要がある場合は、新しいイメージを作成してデプロイします。特定のデバッグ シナリオでのみ、基盤となるコンテナへの SSH アクセスを有効にします。
環境全体で構成をグローバルに保護するには、 組織のポリシー を使用して、 クラウド アセットの動作に影響するリソースに制約またはガードレールを設定します。たとえば、次の組織のポリシーを定義し、組織全体にグローバルに適用することも、フォルダまたはプロジェクト レベルで選択的に適用することもできます。 Google Cloud
- VM への外部 IP アドレスの割り当てを無効にします。
- リソースの作成を特定の地理的ロケーションに制限します。
- サービス アカウントまたはその鍵の作成を無効にします。
保存データと転送中データを暗号化する
この推奨事項は、次の 重点分野に関連しています。
- インフラストラクチャのセキュリティ
- データ セキュリティ
データ暗号化は、機密情報を保護するための基本的な制御であり、 それは データ ガバナンスの重要な要素です。 効果的なデータ保護戦略には、アクセス制御、データのセグメンテーションと地理的な配置、監査、要件の慎重な評価に基づく暗号化の実装が含まれます。
デフォルトでは、 Google Cloud 保存されている顧客データを暗号化します。 お客様が特別な操作を行う必要はありません。デフォルトの暗号化に加えて、 Google Cloud エンベロープ暗号化と暗号鍵 を管理できます。ストレージ、コンピューティング、ビッグデータ ワークロード用の鍵の選択に関しては、鍵の生成、保管、ローテーションの要件にどのソリューションが最適かを判断する必要があります。たとえば、 顧客管理の暗号鍵（CMEK） は Cloud Key Management Service（Cloud KMS）で作成できます。 CMEK は、暗号鍵を定期的にローテーションする必要があるなど、規制要件やコンプライアンス要件を満たすために、ソフトウェア ベースまたは HSM で保護 できます。Cloud KMS Autokey を使用すると、CMEK のプロビジョニングと割り当てを自動化できます。また、独自の鍵 を持ち込むこともできます。これらの鍵は、 Cloud External Key Manager（Cloud EKM）を使用して、サードパーティの鍵管理システムから取得したものです。
転送中のデータを暗号化することを強くおすすめします。 転送中のデータはすべて、Google が管理しているまたは Google が管理を委託している物理的境界の外へ出るときに、 1 つ以上のネットワーク レイヤで暗号化され認証されます。 VPC ネットワークとピアリングした VPC ネットワーク内の VM 間トラフィックはすべて暗号化されます。Cloud Interconnect 接続を介したトラフィックの暗号化には、 MACsec を使用できます。IPsec は、Cloud VPN 接続を介したトラフィックの暗号化を提供します。コンテナ化されたアプリケーションの Apigee と Cloud Service Mesh で TLS や mTLS 構成などのセキュリティ機能を使用すると、クラウド内のアプリケーション間トラフィックを保護できます。
デフォルトでは、 Google Cloud ネットワーク上で保存データと転送中のデータを暗号化します。ただし、メモリ内で使用中のデータはデフォルトでは暗号化されません。組織で機密データを扱う場合は、アプリケーション メモリまたはシステムメモリ内のデータの機密性と整合性を損なう脅威に対処する必要があります。これらの脅威を軽減するには、コンピューティング ワークロードに高信頼実行環境を提供する Confidential Computing を使用します。詳細については、 Confidential VMs の概要をご覧ください。