このページは Cloud Translation API によって翻訳されました。

CMEK の使用に関するベストプラクティス

このページでは、Google Cloud リソースで顧客管理の暗号鍵（CMEK）を使用して保存データの暗号化を構成するためのベストプラクティスについて説明します。このガイドは、クラウドアーキテクトとセキュリティチームを対象としています。CMEK アーキテクチャを設計する際に決定する必要があるベストプラクティスと決定事項について説明します。

このガイドは、Cloud Key Management Service（Cloud KMS）に精通しており、Cloud KMS の詳細を読んでいることを前提としています。

予備的な判断

このページの推奨事項は、CMEK を使用してデータを暗号化するお客様を対象としています。セキュリティ戦略の一環として手動で作成した CMEK と自動作成された CMEK のどちらを使用するか迷っている場合は、このセクションでこれらの予備的な判断に関するガイダンスをご覧ください。

CMEK を使用するかどうかを決定する

次のいずれかの機能が必要な場合は、CEMK を使用して Google Cloud サービス内の保存データを暗号化することをおすすめします。

暗号鍵を所有する。
ロケーション、保護レベル、作成、アクセス制御、ローテーション、使用、破棄の選択など、暗号鍵を制御、管理する。
Cloud KMS で鍵マテリアルを生成するか、Google Cloud の外部で管理されている鍵マテリアルをインポートします。
鍵を使用する必要がある場所に関するポリシーを設定する。
オフボーディングが発生した場合や、セキュリティイベントを修復（クリプトシュレッディング）する場合に、鍵で保護されたデータを選択して削除します。
お客様に固有の鍵を作成して使用し、データの周囲に暗号境界を確立します。
暗号鍵への管理とデータアクセスをログに記録する。
これらの目標のいずれかを必要とする現在または将来の規制に対応できます。

これらの機能が不要な場合は、Google が管理する暗号鍵を使用したデフォルトの保存データの暗号化がユースケースに適しているかどうかを評価します。デフォルトの暗号化のみを使用する場合は、このガイドを読む必要はありません。

手動または自動での鍵の作成を選択する

このガイドでは、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 Autokey を使用する場合は、Autokey が有効になっている各フォルダに専用の Cloud KMS 鍵プロジェクトが必要です。

ロケーションごとに Cloud KMS キーリングを作成する

CMEK で暗号化された Google Cloud リソースをデプロイするロケーションに Cloud KMS キーリングを作成する必要があります。

リージョンリソースとゾーンリソースは、リソースと同じリージョンまたは global ロケーションにあるキーリングと CMEK を使用する必要があります。シングルリージョンリソースとゾーンリソースでは、global 以外のマルチリージョンキーリングを使用できません。
マルチリージョンリソース（us マルチリージョンの BigQuery データセットなど）は、同じマルチリージョンまたはデュアルリージョンでキーリングと CMEK を使用する必要があります。マルチリージョンリソースでは、リージョンキーリングを使用できません。
グローバルリソースは、global ロケーションのキーリングと CMEK を使用する必要があります。

リージョン鍵の適用は、データのリージョン化戦略の一部です。定義されたリージョンでキーリングと鍵の使用を適用すると、リソースがキーリングのリージョンと一致するように強制されます。データ所在地に関するガイダンスについては、データ所在地と主権の要件を実装するをご覧ください。

お客様には、複数のロケーションにまたがる高可用性または障害復旧機能を必要とするワークロードの場合、特定のリージョンで Cloud KMS が使用できなくなった場合にワークロードが復元力があるかどうかを評価する責任があります。たとえば、us-central1 の Cloud KMS 鍵で暗号化された Compute Engine Persistent Disk は、us-central1 を使用できない障害復旧シナリオで us-central2 に再作成できません。このシナリオのリスクを軽減するには、global 鍵でリソースを暗号化することを計画します。

詳細については、最適なロケーションタイプの選択をご覧ください。

Cloud KMS Autokey を使用する場合、鍵リングは保護するリソースと同じロケーションに作成されます。

鍵の粒度戦略を選択する

粒度とは、各キーの使用目的の規模と範囲を指します。たとえば、複数のリソースを保護する鍵は、1 つのリソースのみを保護する鍵よりも粒度が低いと言われます。

CMEK 用に手動でプロビジョニングされた Cloud KMS 鍵は、鍵で暗号化されるリソース（Compute Engine Persistent Disk など）を作成する前に、事前にプロビジョニングする必要があります。個々のリソースに非常に細かい鍵を作成することも、リソース間で広範に再利用できるように細かい鍵を作成することもできます。

普遍的に正しいパターンはありませんが、次のようにさまざまなパターンのトレードオフを考慮してください。

粒度の高い鍵 - 個々のリソースごとに 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 をおすすめします。

Autokey は HSM 保護レベルのみをサポートしています。他の保護レベルが必要な場合は、鍵を自分でプロビジョニングする必要があります。

可能な限り Google 生成の鍵マテリアルを使用する

このセクションは 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` オペレーションを有効にします。	監査管理者

この原則への違反と関連する問題は、Cloud KMS の Security Command の脆弱性検出によって自動的に検出できます。

CMEK を一貫して適用する

以降のセクションでは、鍵の使用の不整合、誤って削除または破棄されるなどのリスクを軽減するための追加の制御について説明します。

プロジェクトのリーエンを適用する

誤って削除されないように、リーエンでプロジェクトを保護することをおすすめします。プロジェクトのリーエンが適用されると、リーエンが削除されるまで Cloud KMS 鍵プロジェクトは削除されなくなります。

CMEK 鍵を必須にする

組織のポリシーの制約を使用して、環境全体で CMEK の使用を適用することをおすすめします。

constraints/gcp.restrictNonCmekServices を使用して、CMEK 鍵を指定せずに特定のリソースタイプを作成するリクエストをブロックします。

最短予定破棄期間を要求する

破棄の予定期間を最小に設定することをおすすめします。鍵の破棄は、データ損失につながる可能性がある元に戻せないオペレーションです。デフォルトでは、Cloud KMS は鍵マテリアルが復元不能に破棄されるまでの 30 日間を破棄予定期間（別名、削除（復元可能）期間）として使用します。これにより、誤って破棄された場合に鍵を復元するための時間ができます。ただし、Cloud KMS 管理者ロールを持つユーザーは、破棄予定期間を 24 時間以内に設定して鍵を作成できます。この期間では、問題を検出して鍵を復元するには不十分な可能性があります。破棄予定期間は、鍵の作成時にのみ設定できます。

鍵の破棄がスケジュールされている間は、その鍵を暗号オペレーションに使用できず、鍵を使用するリクエストは失敗します。この間、監査ログをモニタリングして、鍵が使用されていないことを確認します。鍵を再度使用する場合は、破棄予定期間が終了する前に鍵を復元する必要があります。

作成されたすべての鍵が最小の破棄予定期間を遵守するようにするには、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 所有のハードウェアセキュリティモジュール（HSM）でホストできる場合は、Cloud HSM を選択します。Cloud HSM や Cloud EKM が不要な場合は、ソフトウェア鍵を選択します。保護レベルを選択するためのガイダンスを確認してください。
鍵のマテリアル	Google Cloud でホストされている鍵マテリアルの場合は、可能な限り Google 生成の鍵マテリアルを使用します。インポートされた鍵マテリアルを使用する場合は、自動化と手順を実装してリスクを軽減します。
鍵の目的とアルゴリズム	すべての CMEK 鍵は、対称 `ENCRYPT_DECRYPT` 鍵の目的と `GOOGLE_SYMMETRIC_ENCRYPTION` アルゴリズムを使用する必要があります。
ローテーション期間	鍵の自動ローテーションを使用して、鍵がスケジュールに従ってローテーションされるようにします。ニーズに合ったローテーション期間を選択して適用します。1 年に 1 回以上が理想的です。機密性の高いワークロードには、より頻繁な鍵のローテーションを使用します。
最小限の権限	プリンシパルがタスクを完了できるように、最も制限された事前定義ロールを付与します。基本ロールは使用しないでください。
職掌分散	鍵管理者と鍵を使用するプリンシパルの権限を別々に管理します。
プロジェクトリーエン	プロジェクトリーエンを使用して、重要なプロジェクトが誤って削除されないようにします。
CMEK を必須にする	`constraints/gcp.restrictNonCmekServices` 制約を使用します。
最短予定破棄期間を要求する	`constraints/cloudkms.minimumDestroyScheduledDuration` 制約を使用します。
CMEK に許可される保護レベルを適用する	`constraints/cloudkms.allowedProtectionLevels` 制約を使用します。
監査ロギングを有効にして集約する	組織内のすべてのリソースの管理アクティビティ監査ログを集約します。鍵を使用したオペレーションのロギングを有効にするかどうかを検討します。
鍵の使用状況をモニタリングする	Cloud KMS Inventory API または Google Cloud コンソールを使用して、鍵の使用状況を確認します。必要に応じて Cloud Monitoring を使用し、鍵の破棄のスケジュール設定などの機密性の高いオペレーションに対するアラートを設定します。
Cloud KMS に対して Security Command Center を有効にする	脆弱性の検出結果を確認し、脆弱性の検出結果の確認をセキュリティ運用に統合します。
コンプライアンス要件を評価する	Cloud KMS アーキテクチャを確認し、遵守する必要があるコンプライアンス要件と比較します。

次のステップ

Cloud KMS Autokey で CMEK を一貫して使用するための労力が軽減される仕組みについて学ぶ。

CMEK の使用に関するベスト プラクティス