このページでは、 Google Cloud リソースで顧客管理の暗号鍵（CMEK）を使用して保存データの暗号化を構成するためのベスト プラクティスの概要について説明します。このガイドは、クラウド アーキテクトとセキュリティ チームを対象としており、CMEK アーキテクチャの設計時に決定する必要があるベスト プラクティスと事項について説明します。
このガイドは、Cloud Key Management Service（Cloud KMS）と顧客管理の暗号鍵についてすでに理解しており、Cloud KMS の詳細を読んでいることを前提としています。予備的な決定
このページの推奨事項は、CMEK を使用してデータを暗号化するお客様を対象としています。セキュリティ戦略の一環として手動で作成した CMEK と自動作成された CMEK のどちらを使用するか迷っている場合は、このセクションでこれらの予備的な判断に関するガイダンスをご覧ください。
CMEK を使用するかどうかを決定する
次の機能のいずれかが必要な場合は、CMEK を使用して Google Cloudサービス内の保存データを暗号化することをおすすめします。
暗号鍵を所有する。
ロケーション、保護レベル、作成、アクセス制御、ローテーション、使用、破棄の選択など、暗号鍵を制御、管理する。
Cloud KMS で鍵マテリアルを生成するか、 Google Cloudの外部で管理されている鍵マテリアルをインポートします。
鍵を使用する必要がある場所に関するポリシーを設定する。
オフボーディングが発生した場合や、セキュリティ イベントを修復（クリプト シュレッディング）する場合に、鍵で保護されたデータを選択して削除します。
お客様に固有の鍵を作成して使用し、データの周囲に暗号境界を確立します。
暗号鍵への管理とデータアクセスをログに記録する。
これらの目標のいずれかを必要とする現在または将来の規制に対応できます。
手動または自動での鍵の作成を選択する
このガイドでは、CMEK を自分でプロビジョニングする際に決定する必要がある事項のベスト プラクティスについて説明します。Cloud KMS Autokey は、これらの決定の一部を自動的に行うため、このガイドの推奨事項の多くを自動化できます。Autokey を使用する方が鍵を自分でプロビジョニングするよりも簡単です。Autokey で作成された鍵がすべての要件を満たしている場合は、Autokey を使用することをおすすめします。
Autokey は CMEK をプロビジョニングします。Autokey によってプロビジョニングされた CMEK には次の特徴があります。
- 保護レベル: HSM。
- アルゴリズム: AES-256 GCM。
ローテーション期間: 1 年。
Autokey で鍵を作成した後、Cloud KMS 管理者はローテーション期間をデフォルトから編集できます。
- 職掌分散:
- サービスのサービス アカウントには、鍵に対する暗号化と復号の権限が自動的に付与されます。
- Cloud KMS 管理者の権限は、Autokey で作成された鍵に通常どおり適用されます。Cloud KMS 管理者は、Autokey で作成された鍵の表示、更新、有効化、無効化、破棄を行うことができます。Cloud KMS 管理者には、暗号化と復号の権限は付与されません。
- Autokey デベロッパーは、鍵の作成と割り当てのみをリクエストできます。鍵の表示や管理はできません。
- 鍵の限定性または粒度: Autokey によって作成された鍵の粒度は、リソースタイプによって異なります。鍵の粒度に関するサービス固有の詳細については、互換性のあるサービスをご覧ください。
ロケーション: Autokey は、保護するリソースと同じロケーションに鍵を作成します。
Cloud HSM が利用できないロケーションで CMEK で保護されたリソースを作成する必要がある場合は、CMEK を手動で作成する必要があります。
- 鍵バージョンの状態: Autokey を使用してリクエストされて新規作成された鍵は、有効な状態のプライマリ鍵バージョンとして作成されます。
- キーリングの命名: Autokey によって作成されたすべての鍵は、選択したロケーションの Autokey プロジェクトの
autokeyというキーリングに作成されます。Autokey プロジェクトのキーリングは、Autokey デベロッパーが指定されたロケーションで最初の鍵をリクエストするときに作成されます。 - 鍵の命名: Autokey によって作成された鍵は、
PROJECT_NUMBER-SERVICE_SHORT_NAME-RANDOM_HEXという命名規則に従います。 - 鍵のエクスポート: すべての Cloud KMS 鍵と同様に、Autokey で作成された鍵はエクスポートできません。
- キー トラッキング: キー トラッキングと互換性がある CMEK 統合サービスで使用されるすべての Cloud KMS 鍵と同様に、Autokey で作成された鍵は Cloud KMS ダッシュボードで追跡されます。
HSM 以外の保護レベルや Autokey と互換性のないサービスなど、Autokey で作成された鍵では満たせない要件がある場合は、Autokey ではなく手動で作成された CMEK を使用することをおすすめします。
CMEK アーキテクチャを設計する
CMEK アーキテクチャを設計する際は、使用する鍵の構成と、これらの鍵の管理方法を検討する必要があります。これらの決定は、コスト、運用上のオーバーヘッド、暗号シュレディングなどの機能の実装の容易さに影響します。
以降のセクションでは、各設計上の選択に関する推奨事項について説明します。
環境ごとに一元化された CMEK 鍵プロジェクトを使用する
環境フォルダごとに一元化された CMEK 鍵プロジェクトを使用することをおすすめします。Cloud KMS 鍵を管理するプロジェクトと同じプロジェクトに、CMEK で暗号化されたリソースを作成しないでください。このアプローチは、環境間での暗号鍵の共有を防ぎ、職掌分散を可能にします。
次の図は、推奨される設計におけるこれらのコンセプトを示しています。
- 各環境フォルダには、アプリケーション プロジェクトとは別に管理される Cloud KMS 鍵プロジェクトがあります。
- Cloud KMS キーリングと鍵は Cloud KMS 鍵プロジェクトでプロビジョニングされ、これらの鍵はアプリケーション プロジェクトのリソースの暗号化に使用されます。
- Identity and Access Management（IAM）ポリシーは、プロジェクトまたはフォルダに適用され、職掌分散を可能にします。Cloud KMS 鍵プロジェクトで Cloud KMS 鍵を管理するプリンシパルが、アプリケーション プロジェクトで暗号鍵を使用するプリンシパルと同じではありません。
ロケーションごとに Cloud KMS キーリングを作成する
Cloud KMS キーリングは、CMEK で暗号化されたGoogle Cloud リソースをデプロイするロケーションに作成する必要があります。
- リージョン リソースとゾーンリソースは、リソースと同じリージョンまたは
globalロケーションにあるキーリングと CMEK を使用する必要があります。 シングル リージョン リソースとゾーンリソースでは、global以外のマルチリージョン キーリングを使用できません。 - マルチリージョン リソース（
usマルチリージョンの BigQuery データセットなど）は、同じマルチリージョンまたはデュアルリージョンのキーリングと CMEK を使用する必要があります。マルチリージョン リソースでは、リージョン キーリングを使用できません。 - グローバル リソースは、
globalロケーションのキーリングと CMEK を使用する必要があります。
リージョン鍵の適用は、データ リージョン化戦略の一部です。定義されたリージョンでキーリングと鍵の使用を適用すると、リソースがキーリングのリージョンと一致するように強制されます。 データ所在地に関するガイダンスについては、データ所在地を制御するをご覧ください。
お客様には、複数のロケーションにまたがる高可用性または障害復旧機能を必要とするワークロードの場合、特定のリージョンで Cloud KMS が使用できなくなった場合にワークロードが復元力があるかどうかを評価する責任があります。たとえば、リージョン A の Cloud KMS 鍵で暗号化された Compute Engine 永続ディスクは、リージョン A が使用できない障害復旧シナリオでは、リージョン B で再作成できません。このシナリオのリスクを軽減するには、global 鍵でリソースを暗号化することを計画します。
詳細については、最適なロケーション タイプの選択をご覧ください。
Cloud KMS Autokey を使用する場合、キーリングは保護するリソースと同じロケーションに作成されます。
キーの粒度戦略を選択する
粒度とは、各キーの使用目的の規模と範囲を指します。たとえば、複数のリソースを保護する鍵は、1 つのリソースのみを保護する鍵よりも粒度が低いと言われます。
CMEK 用に手動でプロビジョニングされた Cloud KMS 鍵は、鍵で暗号化されるリソース（Compute Engine Persistent Disk など）を作成する前に、事前にプロビジョニングする必要があります。 個々のリソースに非常に細かい鍵を作成することも、リソース間で広範に再利用できるように細かい鍵を作成することもできます。
一般に、次の粒度戦略をおすすめします。
- 各鍵は、単一のロケーション（
us-central1など）のリソースを保護します。 - 各鍵は、単一のサービスまたはプロダクト（BigQuery など）のリソースを保護します。
- 各鍵は、単一の Google Cloud プロジェクト内のリソースを保護します。
この推奨事項は、組織にとって理想的な粒度戦略ではない可能性があります。ほとんどの組織にとって、この戦略は、粒度の高い鍵を多数維持するオーバーヘッドと、多くのプロジェクト、サービス、リソース間で共有される粒度の低い鍵を使用する潜在的なリスクとの間で、適切なバランスを提供します。
Cloud KMS Autokey で作成された鍵は、この推奨事項に沿っています。
別の粒度戦略を採用する場合は、さまざまなパターンのトレードオフを考慮してください。
粒度の高い鍵 - 個々のリソースごとに 1 つの鍵など
- 鍵バージョンを安全に無効にするための制御の強化: 狭い範囲で使用される鍵バージョンを無効化または破棄する場合、共有鍵を無効化または破棄する場合よりも、他のリソースに影響するリスクが低くなります。また、粒度の高い鍵を使用すると、粒度の低い鍵を使用する場合と比較して、鍵が不正使用された場合の影響を軽減できます。
- 費用: 粒度の高い鍵を使用すると、粒度の低い鍵を使用する戦略と比較して、より多くのアクティブな鍵バージョンを維持する必要があります。 Cloud KMS の料金はアクティブな鍵バージョンの数に基づいているため、鍵の粒度を高くすると費用が増加します。
- 運用上のオーバーヘッド: 粒度の高い鍵を使用すると、大量の Cloud KMS リソースをプロビジョニングし、サービス エージェントが適切な鍵のみを使用できるようにサービス エージェントのアクセス制御を管理するために、管理上の労力や自動化のための追加ツールが必要になる場合があります。粒度の高い鍵が必要な場合は、Autokey を使用してプロビジョニングを自動化することをおすすめします。各サービスの Autokey 鍵の粒度の詳細については、互換性のあるサービスをご覧ください。
粒度の低い鍵 - アプリケーション、リージョン、環境ごとに 1 つの鍵など:
- 鍵バージョンを安全に無効にするには注意が必要です。広範囲で使用される鍵バージョンを無効化または破棄する場合は、粒度の低い鍵を無効化または破棄する場合よりも注意が必要です。古い鍵バージョンを無効にする前に、その鍵バージョンで暗号化されたすべてのリソースが新しい鍵バージョンで安全に再暗号化されていることを確認する必要があります。 多くのリソースタイプでは、鍵の使用状況を表示して、鍵が使用された場所を特定できます。 また、粒度の高い鍵を使用する場合と比較して、粒度の低い鍵を使用すると、鍵が不正使用された場合の影響が大きくなる可能性があります。
- 費用: 粒度の低い鍵を使用すると、作成する鍵バージョンの数が少なくなります。Cloud KMS の料金は、アクティブな鍵バージョンの数に基づいています。
- 運用オーバーヘッド: 適切なアクセス制御を確保するために必要な労力を削減して、既知の数の鍵を定義して事前プロビジョニングできます。
鍵の保護レベルを選択する
お客様には、鍵を作成する場合、CMEK で暗号化されたデータとワークロードの要件に基づいて各鍵に適した保護レベルを選択する必要があります。次の質問は、評価に役立ちます。
CMEK の機能が必要ですか？このページの CMEK を使用するかどうかを決定するで、機能を確認できます。
- 該当する場合は次の質問に進みます。
- そうでない場合は、Google デフォルトの暗号化を使用することをおすすめします。
鍵マテリアルをハードウェア セキュリティ モジュール（HSM）の物理的境界内に保持する必要がありますか？
- 該当する場合は次の質問に進みます。
- そうでない場合は、ソフトウェア格納型鍵で CMEK を使用することをおすすめします。
鍵マテリアルを Google Cloudの外部に保存する必要がありますか？
- 該当する場合は、Cloud External Key Manager を使用した CMEK をおすすめします。
- そうでない場合は、Cloud HSM（ハードウェア格納型鍵）を使用した CMEK をおすすめします。
可能な限り Google Cloud生成の鍵マテリアルを使用する
このセクションは Cloud EKM 鍵には当てはまりません。
鍵を作成するときは、Cloud KMS に鍵マテリアルの生成を許可するか、 Google Cloudの外部で生成された鍵マテリアルを手動でインポートする必要があります。可能な場合は、生成されたオプションを選択することをおすすめします。このオプションでは、Cloud KMS の外部に未加工の鍵マテリアルが公開されることはなく、選択した鍵のローテーション期間に基づいて新しい鍵バージョンが自動的に作成されます。独自の鍵マテリアルをインポートするオプションが必要な場合は、次の運用上の考慮事項と、お客様所有の鍵（BYOK）方式を使用するリスクを評価することをおすすめします。
- 新しい鍵バージョンを一貫してインポートする自動化を実装できるかどうか。これには、鍵バージョンをインポートのみに制限する Cloud KMS の設定と、鍵マテリアルを一貫して生成してインポートするための Cloud KMS 以外の自動化の両方が含まれます。自動化で新しい鍵バージョンが想定どおりに作成されなかった場合、どのような影響があるか。
- 未加工の鍵マテリアルを安全に保存またはエスクローするにはどうすればよいか。
- 鍵のインポート プロセスで未加工の鍵マテリアルが漏洩するリスクをどのように軽減すればよいか。
- 未加工の鍵マテリアルが Google Cloudの外部に保持されているため、以前に破棄した鍵を再インポートする場合、どのような影響があるか。
- 鍵マテリアルを自分でインポートするメリットにより、運用オーバーヘッドとリスクの増加を正当化できるかどうか。
ニーズに合った鍵の目的とアルゴリズムを選択する
鍵を作成するときは、鍵の目的と基盤となるアルゴリズムを選択する必要があります。CMEK のユースケースでは、対称 ENCRYPT_DECRYPT の目的を持つ鍵のみを使用できます。この鍵の目的では、常に GOOGLE_SYMMETRIC_ENCRYPTION アルゴリズムを使用します。このアルゴリズムでは、Galois Counter Mode（GCM）で 256 ビットの高度暗号化標準（AES-256）鍵を使用し、Cloud KMS 内部のメタデータでパディングされます。Autokey を使用すると、これらの設定が自動的に適用されます。
クライアントサイド暗号化などの他のユースケースについては、利用可能な鍵の用途とアルゴリズムを確認して、ユースケースに最適なオプションを選択してください。
ローテーション期間を選択する
ニーズに合わせて適切な鍵のローテーション期間を評価することをおすすめします。鍵のローテーションの頻度は、機密性またはコンプライアンスに基づくワークロードの要件によって異なります。たとえば、特定のコンプライアンス基準を満たすために、鍵のローテーションが少なくとも年に 1 回必要になる場合があります。また、機密性の高いワークロードの場合は、より頻繁なローテーション期間を選択することもあります。
対称鍵をローテーションすると、新しいバージョンが主鍵バージョンとしてマークされ、すべての新しいリクエストで情報保護に使用されます。古い鍵バージョンは、そのバージョンで保護されていた以前に暗号化されたデータの復号に引き続き使用できます。鍵をローテーションする場合、以前の鍵バージョンで暗号化されたデータは自動的に再暗号化されません。
鍵のローテーションを頻繁に行うことで、同じ鍵バージョンで暗号化されるメッセージの数を制限し、鍵が不正使用されるリスクと影響を軽減できます。
Autokey を使用する場合、鍵はデフォルトの鍵ローテーション期間（1 年）を使用して作成されます。鍵の作成後にローテーション期間を変更できます。適切なアクセス制御を適用する
アクセス制御を計画する際は、最小権限の原則と職掌分散を検討することをおすすめします。以降のセクションでは、これらの推奨事項について説明します。
最小権限の原則を適用する
CMEK の管理権限を割り当てる場合は、最小権限の原則を考慮し、タスクの実行に必要な最小限の権限を付与します。基本ロールは使用しないことを強くおすすめします。代わりに、事前定義済みの Cloud KMS ロールを付与して、過剰な権限に関連するセキュリティ インシデントのリスクを軽減します。
この原則の違反と関連する問題は、IAM の Security Command Center の脆弱性検出によって自動的に検出できます。職務の分離を計画する
暗号鍵を管理するユーザーと暗号鍵を使用するユーザーの ID と権限は、個別に管理します。NIST SP 800-152 では、暗号鍵管理システムのサービスを有効にして管理する暗号担当者と、それらの鍵を使用してリソースを暗号化または復号するユーザーの間の職掌分散が定義されています。
CMEK を使用して Google Cloud サービスで保存時の暗号化を管理する場合、暗号鍵を使用する IAM ロールは個々のユーザーではなく、 Google Cloud サービスのサービス エージェントに割り当てられます。たとえば、暗号化された Cloud Storage バケットにオブジェクトを作成するには、ユーザーに IAM ロール roles/storage.objectCreator のみが必要で、同じプロジェクト内の Cloud Storage サービス エージェント（service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com など）には、IAM ロール roles/cloudkms.cryptoKeyEncrypterDecrypter が必要です。
次の表は、どのジョブ機能に通常どの IAM ロールが関連付けられているかを示しています。
| IAM ロール | 説明 | NIST SP 800-152 の指定 |
|---|---|---|
roles/cloudkms.admin |
制限付きリソースタイプと暗号オペレーションへのアクセスを除く、Cloud KMS リソースへのアクセス権を付与します。 | 暗号責任者 |
roles/cloudkms.cryptoKeyEncrypterDecrypter |
encrypt オペレーションと decrypt オペレーションに限り、Cloud KMS リソースを使用する権限を付与します。 |
暗号鍵管理システム ユーザー |
roles/cloudkms.viewer |
get オペレーションと list オペレーションを有効にします。 |
監査管理者 |
CMEK を一貫して適用する
以降のセクションでは、鍵の使用の不整合、誤って削除または破棄されるなどのリスクを軽減するための追加の制御について説明します。
プロジェクトのリーエンを適用する
誤って削除されないように、リーエンでプロジェクトを保護することをおすすめします。プロジェクトのリーエンが適用されると、リーエンが削除されるまで Cloud KMS 鍵プロジェクトは削除できなくなります。
CMEK 鍵を必須にする
組織のポリシーの制約を使用して、環境全体で CMEK の使用を適用することをおすすめします。
constraints/gcp.restrictNonCmekServices を使用して、CMEK 鍵を指定せずに特定のリソースタイプを作成するリクエストをブロックします。
最短予定破棄期間を要求する
破棄の予定期間を最小に設定することをおすすめします。鍵の破棄は取り消し不能な操作であり、データ損失を引き起こす可能性があります。デフォルトでは、Cloud KMS は鍵マテリアルが復元不能に破棄されるまでの 30 日間を破棄予定期間（別名、削除（復元可能）期間）として使用します。これにより、誤って鍵を破棄した場合に鍵を復元する時間を確保できます。ただし、Cloud KMS 管理者ロールを持つユーザーは、破棄予定期間を 24 時間以内に設定して鍵を作成できます。この期間では、問題を検出して鍵を復元するには不十分な可能性があります。破棄予定期間は、鍵の作成時にのみ設定できます。
鍵の破棄がスケジュールされている間は、その鍵を暗号オペレーションに使用できず、鍵を使用するリクエストは失敗します。この期間中は、監査ログをモニタリングして、キーが使用されていないことを確認します。鍵を再度使用する場合は、破棄予定期間が終了する前に鍵をrestoreする必要があります。
作成されたすべての鍵が最小の破棄予定期間を遵守するようにするには、30 日以上（または任意の期間）で組織のポリシー制約 constraints/cloudkms.minimumDestroyScheduledDuration を構成することをおすすめします。この組織のポリシーにより、ユーザーはポリシーで指定された値よりも短い破棄予定期間の鍵を作成できなくなります。
CMEK に許可される保護レベルを適用する
組織のポリシー制約を使用して、環境全体でキー保護レベルの要件を一貫して適用することをおすすめします。
constraints/cloudkms.allowedProtectionLevels を使用して、新しい鍵、鍵バージョン、インポート ジョブで許可された保護レベルを使用するように強制します。
CMEK の検出制御を構成する
Google Cloud は、CMEK 用のさまざまな検出制御を提供します。以降のセクションでは、Cloud KMS に関連するこれらのコントロールを有効にして使用する方法について説明します。
監査ロギングを有効にして集約する
Cloud KMS 管理アクティビティ監査ログ（すべてのサービスの管理アクティビティ ログを含む）を、組織内のすべてのリソースに対して一元化された場所に集約することをおすすめします。これにより、セキュリティ チームや監査担当者は、Cloud KMS リソースの作成または変更に関連するすべてのアクティビティを一度に確認できます。集約ログシンクの構成については、組織のログを集約して保存するをご覧ください。
必要に応じて、データアクセス ログを有効にして、暗号化や復号などの鍵を使用するオペレーションを記録できます。CMEK を使用すると、CMEK を使用するすべてのサービスからのすべてのオペレーションでデータアクセス ログが作成されるため、ログの量が増加し、費用に影響する可能性があります。データアクセス ログを有効にする前に、追加のログの明確なユースケースを定義し、ロギング費用がどのように増加するかを評価することをおすすめします。
鍵の使用状況をモニタリングする
Cloud KMS Inventory API を使用して鍵の使用状況を表示すると、Cloud KMS 鍵に依存して保護されている組織内の Google Cloud リソースを特定できます。このダッシュボードを使用すると、鍵バージョンと、それらが保護する対応するリソースの状態、使用状況、可用性をモニタリングできます。また、無効または破棄された鍵が原因でアクセスできないデータもダッシュボードで識別されるため、アクセスできないデータのパージや鍵の再有効化などのアクションを実行できます。 Cloud KMS で Cloud Monitoring を使用すると、鍵の破棄のスケジュール設定など、重要なイベントのアラートを設定できます。Cloud Monitoring を使用すると、このようなオペレーションが実行された理由をトリアージし、必要に応じてオプションのダウンストリーム プロセスをトリガーして鍵を復元できます。重要なイベントを自動的に検出して、鍵の使用状況ダッシュボードを定期的に確認する運用計画を立てることをおすすめします。
Cloud KMS の脆弱性検出に対して Security Command Center を有効にする
Security Command Center は、Cloud KMS や他のリソースに関連する構成ミスをハイライト表示する脆弱性検出結果を生成します。Security Command Center を有効にして、検出結果を既存のセキュリティ運用に統合することをおすすめします。検出される問題には、一般公開されている Cloud KMS 鍵、過剰な権限が付与された owner ロールを持つ Cloud KMS プロジェクト、職掌分散に違反する IAM ロールなどが含まれます。
コンプライアンス要件を評価する
コンプライアンス フレームワークごとに、暗号化と鍵管理の要件が異なります。コンプライアンス フレームワークは通常、暗号鍵管理の一般的な原則と目的を概説しますが、コンプライアンスを実現する特定のプロダクトや構成については規定されていません。コンプライアンス フレームワークの要件と、鍵管理を含む自社での制御がそれらの要件を満たす方法を理解するのは、お客様の責任です。
さまざまなコンプライアンス フレームワークの要件を満たすうえで Google Cloud サービスがどのように役立つかについては、次のリソースをご覧ください。ベスト プラクティスの概要
次の表に、このドキュメントで推奨するベスト プラクティスをまとめます。
| トピック | タスク |
|---|---|
| CMEK を使用するかどうかを決定する | CMEK で有効になる機能のいずれかが必要な場合は、CMEK を使用します。 |
| 手動または自動での鍵の作成を選択する | Autokey によって作成された鍵の特性がニーズを満たしている場合は、Cloud KMS Autokey を使用します。 |
| Cloud KMS 鍵プロジェクト | 環境ごとに 1 つの一元化された鍵プロジェクトを使用します。鍵で保護する Google Cloudリソースと同じプロジェクトに Cloud KMS リソースを作成しないでください。 |
| Cloud KMS キーリング | Google Cloudリソースを保護する各ロケーションに Cloud KMS キーリングを作成します。 |
| 鍵の粒度 | ニーズに合った鍵の粒度のパターンを選択するか、Autokey を使用して、各サービスに推奨される粒度で鍵を自動的にプロビジョニングします。 |
| 保護レベル | 鍵マテリアルを Google Cloudの外部に保存する必要がある場合は、Cloud EKM を選択します。鍵マテリアルを Google Cloud所有のハードウェア セキュリティ モジュール（HSM）でホストできる場合は、Cloud HSM を選択します。Cloud HSM や Cloud EKM が不要な場合は、ソフトウェア鍵を選択します。保護レベルを選択するためのガイダンスを確認してください。 |
| 鍵のマテリアル | Google Cloudでホストされている鍵マテリアルには、可能な限り Google Cloud生成の鍵マテリアルを使用します。インポートされた鍵マテリアルを使用する場合は、リスクを軽減するための自動化と手順を実装します。 |
| 鍵の目的とアルゴリズム | すべての CMEK 鍵は、対称 ENCRYPT_DECRYPT 鍵の目的と GOOGLE_SYMMETRIC_ENCRYPTION アルゴリズムを使用する必要があります。 |
| ローテーション期間 | 鍵の自動ローテーションを使用して、鍵がスケジュールどおりにローテーションされるようにします。ニーズに合ったローテーション期間を選択して適用します。1 年に 1 回以上が理想的です。機密性の高いワークロードには、より頻繁な鍵のローテーションを使用します。 |
| 最小限の権限 | プリンシパルがタスクを完了できる最も制限の厳しい事前定義ロールを付与します。基本ロールは使用しないでください。 |
| 職掌分散 | 鍵管理者と鍵を使用するプリンシパルの権限を別々に管理します。 |
| プロジェクト リーエン | プロジェクト リーエンを使用して、重要なプロジェクトが誤って削除されないようにします。 |
| CMEK を必須にする | constraints/gcp.restrictNonCmekServices 制約を使用します。 |
| 最短予定破棄期間を要求する | constraints/cloudkms.minimumDestroyScheduledDuration 制約を使用します。 |
| CMEK に許可される保護レベルを適用する | constraints/cloudkms.allowedProtectionLevels 制約を使用します。 |
| 監査ロギングを有効にして集約する | 組織内のすべてのリソースの管理アクティビティ監査ログを集計します。鍵を使用するオペレーションのロギングを有効にするかどうかを検討します。 |
| 鍵の使用状況をモニタリングする | Cloud KMS インベントリ API または Google Cloud コンソールを使用して、鍵の使用状況を把握します。必要に応じて Cloud Monitoring を使用し、鍵の破棄のスケジュール設定などの機密性の高いオペレーションに対するアラートを設定します。 |
| Cloud KMS に対して Security Command Center を有効にする | 脆弱性の検出結果を確認し、脆弱性の検出結果の確認をセキュリティ オペレーションに統合します。 |
| コンプライアンス要件を評価する | Cloud KMS アーキテクチャを確認し、遵守する必要があるコンプライアンス要件と比較します。 |
次のステップ
- Cloud KMS Autokey で CMEK を一貫して使用するための労力が軽減される仕組みについて学ぶ。