このドキュメントでは、Google Cloudでワークロードを実行する際の Compute Engine、Google Kubernetes Engine（GKE）、Pub/Sub、Dataflow、Cloud Run functions などの Google Cloudサービスのベスト プラクティスとガイドラインについて説明します。
コンピューティングの制御
これらの制御は、コンピューティング サービスに適用されます。
IP 転送を有効にできる VM インスタンスを定義する
| Google コントロール ID | VPC-CO-6.3 |
|---|---|
| 実装 | 必須 |
| 説明 | compute.vmCanIpForward 制約により、IP 転送を有効にできる VM インスタンスを定義します。デフォルトでは、すべての VM がすべての仮想ネットワークで IP 転送を有効にすることができます。次のいずれかの形式で VM インスタンスを指定します。
|
| 対象プロダクト |
|
| パス | constraints/compute.vmCanIpForward |
| 演算子 | = |
| 値 |
|
| 型 | リスト |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
VM のネストされた仮想化を無効にする
| Google コントロール ID | VPC-CO-6.6 |
|---|---|
| 実装 | 必須 |
| 説明 | compute.disableNestedVirtualization ブール値制約により、Compute Engine VM のハードウェア アクセラレーションによりネストされた仮想化が無効になります。 |
| 対象プロダクト |
|
| パス | constraints/compute.disableNestedVirtualization |
| 演算子 | 次に一致 |
| 値 |
|
| 型 | ブール値 |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
VM の外部 IP アドレスを制限する
| Google コントロール ID | VPC-CO-6.2 |
|---|---|
| 実装 | 必須 |
| 説明 | 必要がない限り、パブリック IP アドレスを持つ Compute Engine インスタンスの作成を禁止します。 Compute Engine インスタンスに外部 IP アドレスが割り当てられないようにして、インターネットへの露出を大幅に減らします。外部 IP アドレスを持つインスタンスはすぐに検出され、自動スキャン、総当たり攻撃、脆弱性の悪用の直接のターゲットになります。代わりに、インスタンスでプライベート IP アドレスを使用し、Identity-Aware Proxy（IAP）トンネルや踏み台インスタンスなどの制御、認証、ロギングされたパスウェイを介してアクセスを管理します。 このデフォルト拒否の姿勢を採用することは、攻撃対象領域を最小限に抑え、ネットワークに対するゼロトラスト アプローチを適用するのに役立つ基本的なセキュリティのベスト プラクティスです。この制約は遡及的ではありません。 |
| 対象プロダクト |
|
| パス | constraints/compute.vmExternalIpAccess |
| 演算子 | = |
| 値 |
|
| 型 | リスト |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
VM インスタンスに対して許可されている外部 IP アドレスを定義する
| Google コントロール ID | CBD-CO-6.3 |
|---|---|
| 実装 | 必須 |
| 説明 |
|
| 対象プロダクト |
|
| パス | compute.vmExternalIpAccess |
| 演算子 | = |
| 値 |
|
| 型 | リスト |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
VM シリアルポート アクセスを無効にする
| 実装 | 必須 |
|---|---|
| 説明 |
シリアルポート アクセスを無効にすると、すべての管理アクセスが SSH などの標準の監査済みパスウェイを介して強制的に行われるため、多層防御のセキュリティ体制が強化されます。このパスウェイは、Identity and Access Management（IAM）と Identity-Aware Proxy（IAP）を有効にすることで保護できます。 |
| 対象プロダクト |
Compute Engine |
| パス | constraints/compute.disableSerialPortAccess |
| 演算子 | = |
| 値 |
|
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
Cloud Run functions の VPC コネクタを必須にする
| Google コントロール ID | CF-CO-4.4 |
|---|---|
| 実装 | 必須 |
| 説明 |
|
| 対象プロダクト |
|
| パス | constraints/cloudfunctions.requireVPCConnector |
| 演算子 | = |
| 値 |
|
| 型 | ブール値 |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
Shielded VM 機能を有効にする
| 実装 | 必須 |
|---|---|
| 説明 | インスタンスの Shielded VM の仮想トラステッド プラットフォーム モジュール（vTPM）と整合性モニタリング属性を有効にします。vTPM と整合性モニタリング属性は、デフォルトの VM インスタンス作成プロセスの一部です。Shielded VM の vTPM と整合性モニタリングの属性を使用して、VM が信頼できる変更されていないコードでのみ起動するようにします。 vTPM は、UEFI ファームウェアからカーネル ドライバまでのブート シーケンス全体の暗号測定値を生成して保存する安全な仮想暗号プロセッサを提供します。整合性モニタリングは、VM の初回作成時に確立された既知の適切なベースラインと、これらのランタイム測定値を継続的に比較します。 これらの機能は、検証可能な信頼の連鎖を提供し、ブートキットやルートキットなどの悪意のある変更を検出すると、自動的にアラートを送信したり、対策を講じたりします。Shielded VM の機能は、インスタンスの起動時からワークロードの整合性を維持するのに役立ちます。 |
| 対象プロダクト |
Compute Engine |
| パス | compute.instances/shieldedInstanceConfig.enableVtpm |
| 演算子 | 次に一致 |
| 値 |
|
| 型 | ブール値 |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
VM に OS Login を適用する
| 実装 | 必須 |
|---|---|
| 説明 | デベロッパーが SSH を使用して Compute Engine リソースにアクセスできるようにする場合は、2 段階認証プロセスを使用した OS Login を構成します。OS Login を使用して、 SSH 権限をユーザーの ID に関連付けることは、セキュリティにとって非常に重要です。ユーザーの IAM ロールを削除すると、すべてのインスタンスに対するアクセス権が直ちに取り消され、古いアカウントからの不正な侵入を防ぐことができます。このシステムは、鍵の管理を簡素化して鍵の拡散を防ぎ、Cloud Audit Logs のすべてのログイン イベントに対して明確で一元化された監査証跡を提供します。OS Login では、2 要素認証を適用することもできます。これにより、盗まれた SSH 認証鍵や認証情報に対する重要な保護レイヤを追加できます。侵害された OAuth トークンを持つが、パスワードまたはセキュリティ キーがない攻撃者は、この機能によってブロックされます。 Compute Engine 上の Windows インスタンスへのリモート デスクトップ プロトコル（RDP）アクセスでは OS Login サービスがサポートされていないため、RDP セッションで 2 段階認証プロセスを細かく適用できません。IAP Desktop や Google Chrome ベースの RDP プラグインを使用する場合は、きめが粗い制御（Google サービスのセッション継続時間や、ユーザーのウェブ セッションの 2 段階認証プロセス設定など）を設定し、2 段階認証プロセスの [信頼できるデバイスの登録を許可する] の設定を無効にします。 |
| 対象プロダクト |
Compute Engine |
| パス | compute.projects/commonInstanceMetadata.items |
| 演算子 | 次に一致 |
| 値 |
|
| 型 | ブール値 |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
メッセージ ストレージ ポリシーの構成
| Google コントロール ID | PS-CO-4.1 |
|---|---|
| 実装 | 省略可 |
| 説明 | メッセージをグローバル Pub/Sub エンドポイントにパブリッシュすると、Pub/Sub は最も近い Google Cloud リージョンにメッセージを自動的に保存します。メッセージを保存するリージョンを制御するには、トピックにメッセージ ストレージ ポリシーを構成します。次のいずれかの方法で、トピックのメッセージ ストレージ ポリシーを構成します。
|
| 対象プロダクト |
|
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
Dataflow ジョブの外部 IP アドレスをオフにする
| Google コントロール ID | DF-CO-6.1 |
|---|---|
| 実装 | 省略可 |
| 説明 | Dataflow ジョブに関連する管理タスクとモニタリング タスクの外部 IP アドレスをオフにします。代わりに、SSH を使用して Dataflow ワーカー VM へのアクセスを構成します。 プライベート Google アクセスを有効にして、Dataflow ジョブで次のいずれかのオプションを指定します。
ここで
|
| 対象プロダクト |
|
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
ファイアウォール ルールにネットワーク タグを使用する
| Google コントロール ID | DF-CO-6.2 |
|---|---|
| 実装 | 省略可 |
| 説明 | ネットワーク タグは、Dataflow ワーカー VM などの Compute Engine VM に付加されるテキスト属性です。ネットワーク タグを使用すると、VPC ネットワーク ファイアウォール ルールと一部のカスタム静的ルートを特定の VM インスタンスに適用できます。Dataflow では、特定の Dataflow ジョブを実行するすべてのワーカー VM にネットワーク タグを追加できます。 |
| 対象プロダクト |
|
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
コンテナ コントロール
これらの制御は、GKE 内のコンテナに適用されます。
コントロール プレーンへのアクセスを制限する
| Google コントロール ID | GKE-CO-1.1 |
|---|---|
| 実装 | 必須 |
| 説明 | デフォルトでは、Google Kubernetes Engine（GKE）クラスタのコントロール プレーンとノードには、任意の IP アドレスからアクセスできる、インターネット上でルーティング可能なアドレスが割り当てられます。DNS ベースのエンドポイントを使用してプライベート クラスタを作成し、コントロール プレーンへのネットワーク アクセスを制限します。コントロール プレーンは Kubernetes クラスタの管理センターであり、インターネットに公開すると攻撃者の標的になりやすくなります。この構成により、コントロール プレーンがプライベートになり、インターネットから削除されます。 コントロール プレーンへのアクセスを制限すると、組織のプライベート ネットワーク内の信頼できるデバイスのみがクラスタを管理できるようになり、外部攻撃のリスクが大幅に軽減されます。 |
| 対象プロダクト |
GKE |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
最小権限のファイアウォール ルールを使用する
| Google コントロール ID | GKE-CO-1.2 |
|---|---|
| 実装 | 必須 |
| 説明 | ファイアウォール ルールを作成する場合は、最小権限の原則に従って、必要な目的に限りアクセス権を付与します。可能な場合は、ファイアウォール ルールが GKE のデフォルトのファイアウォール ルールと競合しないようにしてください。 |
| 対象プロダクト |
GKE |
| 関連する NIST-800-53 コントロール |
|
| 関連情報 |
RBAC 向け Google グループを使用する
| Google コントロール ID | GKE-CO-1.3 |
|---|---|
| 実装 | 必須 |
| 説明 | ロールベースのアクセス制御（RBAC）に Google グループを使用します。これにより、既存のユーザー アカウント管理プラクティスと連携することもできます。たとえば、社員が退職したときに、そのユーザーのアクセス権を取り消すことができます。RBAC 用 Google グループは、Identity and Access Management（IAM）と Google グループを使用してクラスタ アクセスを効率的に管理するのに役立ちます。これは、Google グループを使用するほとんどの組織に適しています。 |
| 対象プロダクト |
Google Kubernetes Engine（GKE） |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
Shielded GKE Nodes を有効にする
| Google コントロール ID | GKE-CO-1.4 |
|---|---|
| 実装 | 必須 |
| 説明 | クラスタ内のノードの暗号検証に Shielded GKE Nodes を有効にします。Shielded GKE Nodes は、強固で検証可能なノード ID と整合性を提供します。クラスタを作成または更新するときに、Shielded GKE Nodes を有効にします。可能な場合は、セキュアブートで Shielded GKE Node を使用して、ブートプロセス中にノード VM のブート コンポーネントも認証します。サードパーティの未署名のカーネル モジュールが必要な場合は、セキュアブートを使用しないでください。 クラスタを作成すると、Shielded GKE Nodes がデフォルトで有効になります。 |
| 対象プロダクト |
GKE |
| 関連する NIST-800-53 コントロール |
|
| 関連情報 |
containerd ランタイムで Container-Optimized OS を使用する
| Google コントロール ID | GKE-CO-1.5 |
|---|---|
| 実装 | 必須 |
| 説明 | Container-Optimized OS を使用して、強化されたマネージド コンテナ OS を実装します。汎用オペレーティング システムには、コンテナの実行に必要のないプログラムが多数含まれているため、攻撃者にとって不要なターゲットが大きくなります。Container-Optimized OS は、必要なものだけを含む最小限のロックダウンされたオペレーティング システムであり、攻撃対象領域を大幅に削減します。マネージド OS である Container-Optimized OS には、Google によって自動的に適用されるセキュリティ パッチも用意されています。これにより、重大な脆弱性が修正され、運用ワークロードが軽減されます。 Containerd を使用した Container-Optimized OS（cos_containerd）を含むイメージには、Kubernetes と直接統合されているメイン コンテナ ランタイムとして containerd が含まれています。containerd は Docker のコア ランタイム コンポーネントであり、Kubernetes Container Runtime Interface（CRI）のコア コンテナ機能を配信するように設計されています。これは、完全な Docker デーモンよりもはるかに簡潔なので、攻撃対象領域が小さくなります。 |
| 対象プロダクト |
Container-Optimized OS |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
Workload Identity Federation for GKE を使用する
| Google コントロール ID | GKE-CO-1.6 |
|---|---|
| 実装 | 必須 |
| 説明 | Workload Identity Federation for GKE を使用して、Google Kubernetes Engine（GKE）ワークロードから Google Cloud API に対する認証を安全に行います。Workload Identity Federation for GKE は、サービス アカウント キーを使用するよりもシンプルで安全な方法を提供します。 |
| 対象プロダクト |
GKE |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
GKE Sandbox を有効にする
| Google コントロール ID | GKE-CO-1.7 |
|---|---|
| 実装 | 必須 |
| 説明 | GKE Sandbox を使用すると、セキュリティに新たなレイヤを追加し、信頼できないコードから Google Kubernetes Engine（GKE）クラスタノードのホストカーネルを保護できます。GKE Sandbox は、信頼できないワークロードや機密性の高いワークロードのワークロード分離を強化し、コンテナ エスケープ攻撃に対する保護レイヤを追加します。 |
| 対象プロダクト |
GKE |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
kubelet 読み取り専用ポートを無効にする
| Google コントロール ID | GKE-CO-1.9 |
|---|---|
| 実装 | 必須 |
| 説明 | kubelet 読み取り専用ポート 10255 を無効にして、より安全なポート 10250 を使用します。Kubernetes では、このポートに対して認証や認可のチェックが行われません。kubelet は、より安全な認証済みのポート 10250 で同じエンドポイントにサービスを提供します。 GKE バージョン 1.26.4-gke.500 以降でのみ安全でない kubelet 読み取り専用ポートを無効にできます。 |
| 対象プロダクト |
GKE |
| 関連する NIST-800-53 コントロール |
|
| 関連情報 |
Namespace と RBAC を使用してクラスタ リソースへのアクセスを制限する
| Google コントロール ID | GKE-CO-1.10 |
|---|---|
| 実装 | 必須 |
| 説明 | 各チームと環境に個別の Namespace またはクラスタを作成して、Kubernetes への最小権限アクセスを実装します。アカウンタビリティとチャージバックに基づいて各 Namespace にコストセンターと適切なラベルを割り当てます。開発者に付与する Namespace へのアクセス権は（特に本番環境において）、アプリケーションのデプロイと管理に必要なレベルのみに制限します。ユーザーがクラスタに対して行う必要があるタスクをマッピングし、各タスクの実行に必要な権限を定義します。 Google Kubernetes Engine（GKE）に適した Identity and Access Management（IAM）ロールをグループやユーザーに割り当て、プロジェクト レベルでの権限を付与します。また、RBAC を使用してクラスタと Namespace レベルで権限を付与します。 |
| 対象プロダクト |
|
| 関連する NIST-800-53 コントロール |
|
| 関連情報 |
Pod 間のトラフィックを制限する
| Google コントロール ID | GKE-CO-1.11 |
|---|---|
| 実装 | 必須 |
| 説明 | デフォルトでは、クラスタ内のすべての Pod が相互に通信できます。ワークロードのニーズに応じて Pod 間通信を制御します。サービスへのネットワーク アクセスを制限することで、攻撃者によるクラスタ内での横移動の難易度を大幅に上げることができ、偶発的または意図的な DoS 攻撃に対してサービスをある程度は保護できます。 トラフィックを制御する方法は 2 つあります。
|
| 対象プロダクト |
GKE |
| 関連する NIST-800-53 コントロール |
|
| 関連情報 |
アドミッション コントローラを使用してポリシーを適用する
| Google コントロール ID | GKE-CO-1.12 |
|---|---|
| 実装 | 必須 |
| 説明 | アドミッション コントローラは、クラスタの使用方法を管理し、適用するプラグインです。アドミッション コントローラは、クラスタを強化するための多層防御アプローチの重要な部分であるため、Kubernetes の高度なセキュリティ機能の一部を使用できるようにします。デフォルトでは、Kubernetes の Pod は、必要とする以上の機能で動作します。アドミッション コントロールを使用して、Pod の機能をそのワークロードに必要な機能だけに制限します。 GKE は、明示的に付与された機能のみを使用して Pod を実行するように制限する制御手段を多数サポートしています。たとえば、Policy Controller はフリート内のクラスタで使用できます。Kubernetes には、個々のクラスタに Pod セキュリティ標準を適用できる PodSecurity アドミッション コントローラも組み込まれています。Policy Controller は、宣言型ポリシーを使用して GKE クラスタにセキュリティを大規模に適用し、検証できる GKE の機能です。 |
| 対象プロダクト |
GKE |
| 関連する NIST-800-53 コントロール |
|
| 関連情報 |
ワークロードの自己変更機能を制限する
| Google コントロール ID | GKE-CO-1.13 |
|---|---|
| 実装 | 必須 |
| 説明 | 特定の Kubernetes ワークロード（特にシステム ワークロード）には、自己変更の権限があります。たとえば、一部のワークロードは垂直方向に自動スケーリングされます。これは便利ですが、すでにノードを不正使用した攻撃者がクラスタ内でさらに攻撃を行う可能性があります。たとえば、攻撃者がノード上のワークロード自体を変更して、同じ Namespace 内に存在する、より権限の高いサービス アカウントとして実行するおそれがあります。 デフォルトでは、ワークロードに自己変更の権限を付与しないでください。自己変更が必要な場合は、オープンソースの Gatekeeper ライブラリから NoUpdateServiceAccount などの Gatekeeper または Policy Controller の制約を適用して権限を制限します。これにより、いくつかの有用なセキュリティ ポリシーが提供されます。 ポリシーをデプロイする場合は、クラスタのライフサイクルを管理するコントローラがポリシーをバイパスできるようにします。コントローラは、クラスタのアップグレードの適用など、クラスタに変更を加える必要があります。たとえば、GKE に NoUpdateServiceAccount ポリシーをデプロイする場合は、制約で次のパラメータを設定する必要があります。 parameters: allowedGroups: - system:masters allowedUsers: - system:addon-manager |
| 対象プロダクト |
GKE |
| 関連する NIST-800-53 コントロール |
|
| 関連情報 |
クラスタ構成をモニタリングする
| Google コントロール ID | GKE-CO-1.14 |
|---|---|
| 実装 | 必須 |
| 説明 | クラスタ構成と定義した設定に矛盾がないか監査してください。これらのベスト プラクティスで説明した設定と、その他の一般的な構成ミスは、Security Command Center を使用して自動的に確認できます。 |
| 対象プロダクト |
|
| 関連する NIST-800-53 コントロール |
|
| 関連情報 |
Binary Authorization を適用する
| Google コントロール ID | BIN-CO-1.1 |
|---|---|
| 実装 | 必須 |
| 説明 | Binary Authorization を使用して、信頼できるイメージが Google Kubernetes Engine（GKE）と Cloud Run にデプロイされるようにします。Binary Authorization を使用すると、検証済みの信頼できるコンテナ イメージのみをクラスタにデプロイできるため、ソフトウェア サプライ チェーンのセキュリティが強化されます。 |
| 対象プロダクト |
|
| パス | constraints/binaryauthorization.requireBinauthz |
| 演算子 | == |
| 値 |
|
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
GKE Autopilot を使用する
| 実装 | 必須 |
|---|---|
| 説明 | Google Kubernetes Engine（GKE）Autopilot クラスタを使用する。Autopilot クラスタは、コンテナまたは GKE の多くのセキュリティのベスト プラクティスがデフォルトで有効になっている、堅牢なセキュリティ対策を提供します。 |
| 対象プロダクト |
GKE |
| パス | container.clusters/autopilot.enabled |
| 演算子 | 次に一致 |
| 値 |
|
| 型 | ブール値 |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
GKE クラスタとノードに最小権限のアカウントを使用する
| 実装 | 必須 |
|---|---|
| 説明 | Google Kubernetes Engine（GKE）クラスタとノードに最小権限の Identity and Access Management（IAM）サービス アカウントを使用します。GKE コントロール プレーンへのアクセスは、単一の DNS ベースのエンドポイントに制限されます。最小権限を実装すると、追加のファイアウォール ルールや踏み台ホストを必要とせずに、攻撃対象領域を大幅に削減できます。 |
| 対象プロダクト |
GKE |
| パス | container.clusters/nodeConfig.serviceAccount |
| 演算子 | != |
| 値 |
|
| 型 | 文字列 |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
限定公開 GKE ノードを使用する
| 実装 | 必須 |
|---|---|
| 説明 | インターネットへの露出を減らすために、プライベート ノードを作成します。限定公開 Google Kubernetes Engine（GKE）ノードは、GKE ノードにパブリック IP アドレスがないようにすることで、インターネットへの露出を減らします。 |
| 対象プロダクト |
GKE |
| パス | container.clusters/networkConfig.defaultEnablePrivateNodes |
| 演算子 | 次に一致 |
| 値 |
|
| 型 | ブール値 |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
Confidential Google Kubernetes Engine ノードを使用する
| 実装 | 必須 |
|---|---|
| 説明 | Confidential GKE Node を使用して、ノードとワークロードで使用中のデータの暗号化を強制適用します。Confidential GKE Node は、Confidential Computing を使用して使用中のデータを暗号化することで、機密性の高いワークロードを保護します。 |
| 対象プロダクト |
Google Kubernetes Engine（GKE） |
| パス | container.clusters/confidentialNodes.enabled |
| 演算子 | 次に一致 |
| 値 |
|
| 型 | ブール値 |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
GKE でカスタム認証局を実行する
| 実装 | 必須 |
|---|---|
| 説明 | 独自の認証局を実行して、Google Kubernetes Engine（GKE）内の鍵を管理します。独自の認証局を使用すると、暗号オペレーションをより細かく制御できます。この機能へのアクセス権をリクエストするには、 Google Cloud アカウント チームにお問い合わせください。 |
| 対象プロダクト |
GKE |
| パス | container.clusters/userManagedKeysConfig.clusterCa |
| 演算子 | 設定されている |
| タイプ | 文字列 |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
Cloud KMS を使用して Kubernetes Secret を暗号化する
| 実装 | 必須 |
|---|---|
| 説明 | Cloud Key Management Service（Cloud KMS）で管理されている鍵を使用して、保存時の Kubernetes Secret を暗号化します。Cloud KMS では、所有および管理する鍵を使用して Kubernetes Secrets を暗号化できるため、etcd データのセキュリティ レイヤが追加されます。 |
| 対象プロダクト |
|
| パス | container.clusters/databaseEncryption.keyName |
| 演算子 | 設定されている |
| タイプ | 文字列 |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
ノード ブートディスクに CMEK を使用する
| 実装 | 必須 |
|---|---|
| 説明 | ノード ブートディスクの暗号化に顧客管理の暗号鍵（CMEK）を使用します。CMEK を使用すると、ユーザーが所有および管理する鍵を使用して Kubernetes ノードのブートディスクを暗号化できます。 |
| 対象プロダクト |
|
| パス | container.clusters/nodeConfig.bootDiskKmsKey |
| 演算子 | 設定されている |
| タイプ | 文字列 |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
VMware Engine の制御
VMware Engine の管理者ロールの割り当てを制限する
| Google コントロール ID | GCVE-CO-3.1 |
|---|---|
| 実装 | 必須 |
| 説明 | Google Cloud VMware Engine プライベート クラウドをデプロイして構成するサービス アカウントと、少数の管理者にのみ管理者ロールを付与します。通常、クラスタとノードの手動での追加と削除は頻繁には行われない操作であり、課金やクラスタの可用性に大きな影響を与える可能性があります。 VMware Engine サービス管理者のロールが割り当てられているユーザーを定期的に監査してください。これは、VMware Engine に使用するプロジェクトで直接行うか、リソース階層の親レベルのいずれかで行います。その際は、VMware Engine に関連する重要な権限を含む基本的な編集者ロールやオーナーロールなど、他のロールも監査する必要があります。IAM Recommender などのサービスを使用して、過剰な権限を持つロールを特定できます。 |
| 対象プロダクト |
|
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
最小権限に VMware Engine サービス閲覧者ロールを使用する
| Google コントロール ID | GCVE-CO-3.3 |
|---|---|
| 実装 | 必須 |
| 説明 | デフォルトでは、必要に応じてのみ、VMware Engine サービス閲覧者ロールをユーザーに付与します。VMware Engine サービス閲覧者ロールは、 Google Cloud 上の Google Cloud VMware Engine への読み取り専用アクセス権を付与し、ほとんどのタスクに十分な権限を提供するように設計されています。 |
| 対象プロダクト |
|
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
vCenter Server Appliance ロールに RBAC と最小権限を使用する
| Google コントロール ID | GCVE-CO-3.4 |
|---|---|
| 実装 | 必須 |
| 説明 | vCenter Server Appliance で VMware レベルのロールを付与する場合は、ロールベース アクセス制御（RBAC）と最小権限の原則を使用します。 |
| 対象プロダクト |
VMware Engine |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
VMware ユーザーに ID 連携を使用する
| Google コントロール ID | GCVE-CO-3.5 |
|---|---|
| 実装 | 必須 |
| 説明 | ユーザー アカウントのプロビジョニングと管理が可能な単一の ID ソリューションを維持します。この推奨事項により、ID ライフサイクル管理、グループ管理、パスワード管理などのアクティビティを一元化できます。断片化した ID 戦略の作成を回避する。 |
| 対象プロダクト |
VMware Engine |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
vCenter Server Appliance で個人ではなくグループにロールを付与する
| Google コントロール ID | GCVE-CO-3.6 |
|---|---|
| 実装 | 必須 |
| 説明 | vCenter Server Appliance で VMware レベルのロールを付与する場合は、ID プロバイダで作成したグループにロールを付与します。断片的な ID 戦略を作成しない。 |
| 対象プロダクト |
VMware Engine |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
vSphere のユーザー グループに Cloud-Owner-Role を割り当てない
| Google コントロール ID | GCVE-CO-3.7 |
|---|---|
| 実装 | 必須 |
| 説明 | vSphere でユーザー グループを作成するときは、Cloud-Owner-Role を割り当てないでください。このロールは、プライベート クラウドの vCenter 環境に対する管理制御を付与しますが、特定の基盤となるグローバル インフラストラクチャ権限を制限します。Cloud-Owner-Role より高い権限を持つユーザー グループは、自動的に Cloud-Owner-Role にリセットされます。 |
| 対象プロダクト |
VMware Engine |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
デフォルトの vCenter サービス アカウントと NSX-T サービス アカウントの使用を避ける
| Google コントロール ID | GCVE-CO-3.8 |
|---|---|
| 実装 | 必須 |
| 説明 | 初期構成プロセスと緊急手順を除き、デフォルトの vCenter サービス アカウント（CloudOwner@gve.local）とデフォルトの NSX-T サービス アカウント管理者（admin）は使用しないでください。これらのデフォルトのサービス アカウントには、Cloud-Owner-Role や Enterprise Admin などの強力な権限が含まれています。これらのサービス アカウントの認証情報を Secret Manager に保存します。 |
| 対象プロダクト |
VMware Engine |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
デフォルトの vCenter サービス アカウントと NSX-T サービス アカウントのパスワードを 90 日ごとにローテーションする
| Google コントロール ID | GCVE-CO-3.9 |
|---|---|
| 実装 | 必須 |
| 説明 | デフォルトの vCenter サービス アカウント（CloudOwner@gve.local）とデフォルトの NSX-T サービス アカウント管理者（admin）の認証情報の不正な開示を防止して軽減するには、90 日ごとにパスワードをローテーションします。 |
| 対象プロダクト |
VMware Engine |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
NSX ゲートウェイ ファイアウォールを使用して North-South トラフィックをセグメント化する
| Google コントロール ID | GCVE-CO-1.2 |
|---|---|
| 実装 | 必須 |
| 説明 | NSX ゲートウェイ ファイアウォールを使用して、プライベート クラウドに出入りする North-South ネットワーク トラフィックを制御します。NSX ゲートウェイ ファイアウォールは、境界の保護に役立つ North-South ファイアウォールです。 |
| 対象プロダクト |
VMware Engine |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
NSX 分散ファイアウォールを使用して East-West トラフィックをセグメント化する
| Google コントロール ID | GCVE-CO-1.3 |
|---|---|
| 実装 | 必須 |
| 説明 | NSX Distributed Firewall（DFW）を使用して、プライベート クラウド内の East-West ネットワーク トラフィックを制御します。デフォルトでは、すべてのサブネットが相互に通信できます。DFW を使用して、アプリケーション間やアプリケーション内のサービス間の許可されたトラフィックを定義します。 |
| 対象プロダクト |
VMware Engine |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
セキュリティ要件が異なるワークロード用に個別のサブネットを作成する
| Google コントロール ID | GCVE-CO-1.4 |
|---|---|
| 実装 | 必須 |
| 説明 | セキュリティ要件やデータ分類が異なるワークロードを実行する場合は、ワークロード サブネットを作成して分離します。サブネットを使用すると、セキュリティ要件とポスチャーが異なるワークロードを混在させないことで、潜在的な影響範囲を縮小できます。 |
| 対象プロダクト |
VMware Engine |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
VMware Engine 監査ログを保存するログシンクを作成する
| Google コントロール ID | GCVE-CO-4.1 |
|---|---|
| 実装 | 必須 |
| 説明 | ログシンクを使用して、Google Cloud VMware Engine API の監査ログを保存します。必要に応じて、監査ログをさまざまな宛先に転送できます。 |
| 対象プロダクト |
VMware Engine |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
VMware レベルのプラットフォーム ログを収集する
| Google コントロール ID | GCVE-CO-4.2 |
|---|---|
| 実装 | 必須 |
| 説明 | VMware レベルのプラットフォーム ログ（vCenter や NSX-T の syslog メッセージなど）を収集するには、syslog ログを一元的なログ アグリゲータに転送するように Google Cloud VMware Engine プライベート クラウドを構成します。これらのログは VMware Engine 監査ログに収集されないため、個別に収集する必要があります。 |
| 対象プロダクト |
VMware Engine |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
Logging と Monitoring を使用してアプリケーションをモニタリングする
| Google コントロール ID | GCVE-CO-4.3 |
|---|---|
| 実装 | 必須 |
| 説明 | スタンドアロン エージェントをインストールして、VMware vSphere プラットフォームから Cloud Logging と Cloud Monitoring を有効にします。スタンドアロン エージェントを使用すると、ワークロード レベルのログを収集して、分析と保存のためにロギングとモニタリングに送信できます。 |
| 対象プロダクト |
|
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
データ所在地要件に一致するリージョンにプライベート クラウドを作成する
| Google コントロール ID | GCVE-CO-2.1 |
|---|---|
| 実装 | 必須 |
| 説明 | 組織のデータ所在地要件に一致するリージョンに Google Cloud VMware Engine プライベート クラウドを作成します。プライベート クラウドは、デプロイと再配置が容易ではない、プロビジョニングされたリソースです。 |
| 対象プロダクト |
VMware Engine |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
バックアップと障害復旧の戦略を実装する
| Google コントロール ID | GCVE-CO-5.1 |
|---|---|
| 実装 | 必須 |
| 説明 | ワークロードに Backup and DR サービスまたはサードパーティのバックアップ ソリューションを実装します。デフォルトでは、Google Cloud VMware Engine は vCenter と NSX の構成のみを自動的にバックアップします。Backup and DR を使用すると、VM のバックアップと復元が簡単になります。 |
| 対象プロダクト |
|
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
VMware ワークロードにアプリケーション レベルの暗号化を実装する
| Google コントロール ID | GCVE-CO-1.1 |
|---|---|
| 実装 | 必須 |
| 説明 | Google Cloud VMware Engine で実行されるアプリケーションがトラフィックを暗号化するようにします。VMware Engine は、転送中のワークロード トラフィックを暗号化しません。 |
| 対象プロダクト |
VMware Engine |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
VMware vSAN クラスタで転送中のデータの暗号化を有効にする
| Google コントロール ID | GCVE-CO-2.3 |
|---|---|
| 実装 | 必須 |
| 説明 | VMware vSAN クラスタで転送中のデータの暗号化を有効にして、データ、メタデータ、ファイル サービス トラフィックを暗号化します。 |
| 対象プロダクト |
VMware Engine |
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
CMEK を使用するように vSAN 保存データの暗号化を構成する
| Google コントロール ID | GCVE-CO-2.2 |
|---|---|
| 実装 | 必須 |
| 説明 | 規制環境で必要な場合は、顧客管理の暗号鍵（CMEK）を使用するように vSAN 保存データの暗号化を構成します。 |
| 対象プロダクト |
|
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
vSAN の保存データの暗号化に使用される鍵をローテーションする
| Google コントロール ID | GCVE-CO-2.4 |
|---|---|
| 実装 | 必須 |
| 説明 | vSAN の保存データ暗号化に使用する鍵暗号鍵（KEK）のライフサイクルを管理します。組織の要件に沿った鍵のローテーション手順を実装します。 |
| 対象プロダクト |
|
| 関連する NIST-800-53 コントロール |
|
| 関連する CRI プロファイル コントロール |
|
| 関連情報 |
次のステップ
データ管理コントロールを確認する。