Google Cloud には、コンピューティング リソースと Google Kubernetes Engine（GKE）コンテナ リソースを保護するコントロールがあります。Google Cloud アーキテクチャ フレームワークのこのドキュメントでは、主なコントロールと、それらを使用するためのベスト プラクティスについて説明しています。
強化されたキュレート済み VM イメージを使用する
Google Cloud には、VM インスタンスを強化できる Shielded VM が含まれています。Shielded VM は、起動サイクル中に悪意のあるコードが読み込まれることを回避するように設計されています。これは、ブート時のセキュリティを提供し、整合性をモニタリングします。また、Virtual Trusted Platform Module（vTPM）を使用します。機密性の高いワークロードには Shielded VM を使用してください。
Shielded VM に加えて、Google Cloud パートナー ソリューションを使用して VM をさらに保護できます。Google Cloud で提供されている多くのパートナー ソリューションは、イベント脅威検出とヘルス モニタリングを提供する Security Command Center と統合されます。パートナーを使用して、高度な脅威分析やランタイム セキュリティの強化を行うことができます。
機密データの処理に Confidential Computing を使用します
デフォルトでは、Google Cloud はネットワーク上で保存時と転送時にデータを暗号化しますが、メモリ内で使用中のデータは暗号化されません。組織で機密データを扱う場合は、アプリケーション メモリまたはシステムメモリ内のデータの機密性と整合性を損なう脅威に対処する必要があります。機密データには、個人を特定できる情報（PII）、財務データ、健康情報が含まれます。
Confidential Computing は Shielded VM 上に構築されています。ハードウェアベースの高信頼実行環境で計算を行うことで、使用中のデータを保護します。このような安全で隔離された環境により、データが使用中の間はアプリケーションとデータの不正アクセスや変更を防ぐことができます。高信頼実行環境を提供することで、機密データや規制対象データを管理する組織のセキュリティも向上します。
Google Cloud では、Confidential VMs または Confidential GKE Node により Confidential Computing を実現できます。Confidential Computing は、機密のワークロードを処理する場合や、処理中に公開する必要がある機密データ（Secret など）がある場合に有効にします。詳細については、Confidential Computing Consortium をご覧ください。
VM とコンテナを保護する
OS Login を使用すると、ユーザーは SSH 認証鍵に依存することなく、Identity and Access Management（IAM）権限を信頼できる情報源として使用して VM に接続できます。したがって、組織全体で SSH 認証鍵を管理する必要はありません。OS Login では、管理者による従業員のライフサイクルへのアクセスが関連付けられます。つまり、従業員が別のロールに移動したり、退職した場合、そのユーザーのアクセス権はそのユーザーのアカウントで取り消されます。OS Login は 2 要素認証もサポートしています。これにより、アカウントの乗っ取り攻撃に対するセキュリティを強化できます。
GKE では、App Engine が Docker コンテナ内でアプリケーション インスタンスを実行します。定義済みのリスク プロファイルを有効にして、ユーザーがコンテナを変更できないようにするには、コンテナをステートレスにし、変更されないようにします。この不変性の原則は、ユーザーがコンテナを変更したり、コンテナにインタラクティブにアクセスしないことを意味します。変更が必要な場合は、新しいイメージを作成して再デプロイします。特定のデバッグ シナリオでのみ、基盤となるコンテナへの SSH アクセスを有効にします。
不要な外部 IP アドレスを無効にする
本番環境の VM で外部 IP アドレスの割り振りを無効にする（動画）と、外部ロードバランサの使用を防ぎ、組織のポリシーを使用できます。VM がインターネットまたはオンプレミスのデータセンターに到達する必要がある場合は、Cloud NAT ゲートウェイを有効にできます。
GKE には限定公開クラスタをデプロイできます。限定公開クラスタでは、ノードに内部 IP アドレスしかないため、ノードと Pod がデフォルトでインターネットから隔離されています。ネットワーク ポリシーを定義して、クラスタ内の Pod 間の通信を管理することもできます。詳細については、サービスのプライベート アクセス オプションをご覧ください。
コンピューティング インスタンスと GKE の使用状況をモニタリングする
Cloud Audit Logs は、Compute Engine と GKE に対して自動的に有効になります。監査ログを使用すると、クラスタでのすべてのアクティビティを自動的に収集し、不審なアクティビティをモニタリングできます。
GKE をパートナー プロダクトと統合してランタイム セキュリティを実現できます。これらのソリューションを Security Command Center と統合すると、単一のインターフェースでアプリケーションをモニタリングできます。
イメージとクラスタを最新の状態に保つ
Google Cloud では、定期的にパッチが適用される OS イメージを提供しています。カスタム イメージを用意して Compute Engine で実行することもできますが、実行した場合は自分でパッチを適用する必要があります。Google Cloud は、定期的に OS イメージをアップデートして、セキュリティに関する公開情報で説明されている新しい脆弱性を緩和し、既存のデプロイの脆弱性を修正しています。
GKE を使用している場合は、クラスタノードに常に最新のパッチが適用されているように、ノードの自動アップグレードを有効にすることをおすすめします。Google では、GKE コントロール プレーンを管理し、自動更新を行ってパッチを適用しています。また、Google が選んだコンテナ最適化イメージをデプロイに使用します。Google はこれらのイメージのパッチと更新を定期的に行っています。
イメージとクラスタへのアクセスを制御する
インスタンスを作成および起動できるユーザーを把握しておくことが重要です。IAM を使用すると、このアクセスを制御できます。必要なアクセス ワークロードを決定する方法については、ワークロード ID の計画をご覧ください。
また、VPC Service Controls を使用して、プロジェクトにカスタム割り当てを定義し、イメージを起動できるユーザーを制限することもできます。詳細については、ネットワークを保護するをご覧ください。
クラスタのインフラストラクチャのセキュリティを強化するため、GKE では IAM とロールベース アクセス制御（RBAC）を使用して、クラスタと Namespace へのアクセスを管理できます。
サンドボックスでコンテナを分離する
GKE Sandbox を使用して、追加のセキュリティ レイヤとホストカーネルからの分離を必要とするマルチテナント アプリケーションをデプロイします。たとえば、不明なコードや信頼できないコードを実行する場合は、GKE Sandbox を使用します。GKE Sandbox は、GKE 上でコンテナ化されたワークロード間の 2 番目の防御レイヤを提供するコンテナ分離ソリューションです。
GKE Sandbox は、低 I/O 要件でありながら高度にスケールされたアプリケーションを考慮して構築されました。このようなコンテナ化されたワークロードは、速度とパフォーマンスを維持する必要があり、セキュリティの強化を必要とする信頼できないコードが含まれる可能性もあります。コンテナのランタイム サンドボックスである gVisor を使用して、アプリケーションとホストカーネル間のセキュリティ分離を強化します。gVisor は、追加の整合性チェックを提供し、サービスに対するアクセス スコープを制限します。これは、外部の脅威から保護するためのコンテナ強化サービスではありません。gVisor の詳細については、gVisor: 現実世界で GKE とサーバーレス ユーザーを保護をご覧ください。
次のステップ
コンピューティングとコンテナのセキュリティの詳細については、次のリソースをご覧ください。
- ネットワークを保護する（このシリーズの次のドキュメント）
- コンテナのセキュリティが重要な理由（PDF）
- Google Cloud 用リリース チェックリスト
- インスタンスの ID の確認
- Workload Identity Federation for GKE
- Shielded VM
- 永続ディスクのスナップショットに関するベスト プラクティス
- イメージ管理のベスト プラクティス