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