このページでは、 Cloud de Confiance リソースで顧客管理の暗号鍵（CMEK）を使用して保存データの暗号化を構成するためのベスト プラクティスについて説明します。このガイドは、クラウド アーキテクトとセキュリティ チームを対象としており、CMEK アーキテクチャの設計時に決定する必要があるベスト プラクティスと事項について説明します。
このガイドでは、Cloud Key Management Service（Cloud KMS）と顧客管理の暗号鍵についてすでに理解していることを前提としています。CMEK を使用するかどうかを決定する
次の機能のいずれかが必要な場合は、CMEK を使用して Cloud de Confianceサービス内の保存データを暗号化することをおすすめします。
暗号鍵を所有する。
ロケーション、保護レベル、作成、アクセス制御、ローテーション、使用、破棄の選択など、暗号鍵を制御、管理する。
Cloud KMS で鍵マテリアルを生成するか、 Cloud de Confianceの外部で管理されている鍵マテリアルをインポートします。
鍵を使用する必要がある場所に関するポリシーを設定する。
オフボーディングが発生した場合や、セキュリティ イベントを修復（クリプト シュレッディング）する場合に、鍵で保護されたデータを選択して削除します。
お客様に固有の鍵を作成して使用し、データの周囲に暗号境界を確立します。
暗号鍵への管理とデータアクセスをログに記録する。
これらの目標のいずれかを必要とする現在または将来の規制に対応できます。
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 で暗号化されたCloud de Confiance リソースをデプロイするロケーションに作成する必要があります。
- リージョン リソースとゾーン リソースは、リソースと同じリージョンまたは
globalロケーションにあるキーリングと CMEK を使用する必要があります。 - グローバル リソースは、
globalロケーションのキーリングと CMEK を使用する必要があります。
リージョン鍵の適用は、データ リージョン化戦略の一部です。定義されたリージョンでキーリングと鍵の使用を適用すると、リソースがキーリングのリージョンと一致するように強制されます。
お客様には、複数のロケーションにまたがる高可用性または障害復旧機能を必要とするワークロードの場合、特定のリージョンで Cloud KMS が使用できなくなった場合にワークロードが復元力があるかどうかを評価する責任があります。たとえば、リージョン A の Cloud KMS 鍵で暗号化された Compute Engine 永続ディスクは、リージョン A が使用できない障害復旧シナリオでは、リージョン B で再作成できません。このシナリオのリスクを軽減するには、global 鍵でリソースを暗号化することを計画します。
キーの粒度戦略を選択する
粒度とは、各キーの使用目的の規模と範囲を指します。たとえば、複数のリソースを保護する鍵は、1 つのリソースのみを保護する鍵よりも粒度が低いと言われます。
CMEK に使用される Cloud KMS 鍵は、鍵で暗号化されるリソース（Compute Engine Persistent Disk など）を作成する前に、事前にプロビジョニングする必要があります。 個々のリソースに非常に細かい鍵を作成することも、リソース間で広範に再利用できるように細かい鍵を作成することもできます。
一般に、次の粒度戦略をおすすめします。
- 各鍵は、単一のロケーション（
us-central1など）のリソースを保護します。 - 各鍵は、単一のサービスまたはプロダクト（BigQuery など）のリソースを保護します。
- 各鍵は、単一のプロジェクト内のリソースを保護します。 Cloud de Confiance
この推奨事項は、組織にとって理想的な粒度戦略ではない可能性があります。ほとんどの組織にとって、この戦略は、粒度の高い鍵を多数維持するオーバーヘッドと、多くのプロジェクト、サービス、リソース間で共有される粒度の低い鍵を使用する潜在的なリスクとの間で、適切なバランスを実現します。
別の粒度戦略を採用する場合は、さまざまなパターンのトレードオフを考慮してください。
粒度の高い鍵 - 個々のリソースごとに 1 つの鍵など
- 鍵バージョンを安全に無効にするための制御の強化:狭い範囲で使用される鍵バージョンを無効化または破棄する場合、共有鍵を無効化または破棄する場合よりも、他のリソースに影響するリスクが低くなります。また、粒度の高い鍵を使用すると、粒度の低い鍵を使用する場合と比較して、鍵が不正使用された場合の影響を軽減できます。
- 費用: 粒度の高い鍵を使用すると、粒度の低い鍵を使用する戦略と比較して、より多くのアクティブな鍵バージョンを維持する必要があります。 鍵の粒度が高いほど、アクティブな鍵バージョンの数が増え、追加費用が発生します。
- 運用上のオーバーヘッド: 粒度の高い鍵を使用すると、大量の Cloud KMS リソースをプロビジョニングし、サービス エージェントが適切な鍵のみを使用できるようにサービス エージェントのアクセス制御を管理するために、管理上の労力や自動化のための追加ツールが必要になる場合があります。
粒度の低い鍵 - アプリケーション、リージョン、環境ごとに 1 つの鍵など:
- 鍵バージョンを安全に無効にするには注意が必要です。広範囲で使用される鍵バージョンを無効化または破棄する場合は、粒度の低い鍵を無効化または破棄する場合よりも注意が必要です。古い鍵バージョンを無効にする前に、その鍵バージョンで暗号化されたすべてのリソースが新しい鍵バージョンで安全に再暗号化されていることを確認する必要があります。 また、粒度の低い鍵を使用すると、粒度の高い鍵を使用する場合と比較して、鍵が不正使用された場合の影響が大きくなる可能性があります。
- 費用: 粒度の低い鍵を使用すると、作成する鍵バージョンの数が少なくなり、費用が削減されます。
- 運用オーバーヘッド: 適切なアクセス制御を確保するために必要な労力を削減して、既知の数の鍵を定義して事前プロビジョニングできます。
鍵の保護レベルを選択する
お客様には、鍵を作成する場合、CMEK で暗号化されたデータとワークロードの要件に基づいて各鍵に適した保護レベルを選択する必要があります。次の質問は、評価に役立ちます。
CMEK の機能が必要ですか？このページの CMEK を使用するかどうかを決定するで、機能を確認できます。
- 該当する場合は次の質問に進みます。
- そうでない場合は、 S3NS デフォルトの暗号化を使用することをおすすめします。
レベル 2 またはレベル 3 の FIPS 140-2 認定が必要ですか。または、鍵マテリアルを Cloud de Confianceの外部に保存する必要がありますか？
- 該当する場合は、Cloud External Key Manager を使用した CMEK をおすすめします。
- そうでない場合は、ソフトウェア格納型鍵で CMEK を使用することをおすすめします。
可能な限り Cloud de Confiance生成の鍵マテリアルを使用する
このセクションは Cloud EKM 鍵には当てはまりません。
鍵を作成するときは、Cloud KMS に鍵マテリアルの生成を許可するか、 Cloud de Confianceの外部で生成された鍵マテリアルを手動でインポートする必要があります。可能な場合は、生成されたオプションを選択することをおすすめします。このオプションでは、Cloud KMS の外部で未加工の鍵マテリアルが公開されることはなく、選択した鍵のローテーション期間に基づいて新しい鍵バージョンが自動的に作成されます。独自の鍵マテリアルをインポートするオプションが必要な場合は、次の運用上の考慮事項と、お客様所有の鍵（BYOK）方式を使用するリスクを評価することをおすすめします。
- 新しい鍵バージョンを一貫してインポートする自動化を実装できるかどうか。これには、鍵バージョンをインポートのみに制限する Cloud KMS の設定と、鍵マテリアルを一貫して生成してインポートするための Cloud KMS 以外の自動化の両方が含まれます。自動化で新しい鍵バージョンが想定どおりに作成されなかった場合、どのような影響があるか。
- 未加工の鍵マテリアルを安全に保存またはエスクローするにはどうすればよいか。
- 鍵のインポート プロセスで未加工の鍵マテリアルが漏洩するリスクをどのように軽減すればよいか。
- 未加工の鍵マテリアルが Cloud de Confianceの外部に保持されているため、以前に破棄した鍵を再インポートする場合、どのような影響があるか。
- 鍵マテリアルを自分でインポートするメリットにより、運用オーバーヘッドとリスクの増加を正当化できるかどうか。
ニーズに合った鍵の目的とアルゴリズムを選択する
鍵を作成するときは、鍵の目的と基盤となるアルゴリズムを選択する必要があります。CMEK のユースケースでは、対称 ENCRYPT_DECRYPT の目的を持つ鍵のみを使用できます。この鍵の目的では、常に GOOGLE_SYMMETRIC_ENCRYPTION アルゴリズムを使用します。このアルゴリズムでは、Galois Counter Mode（GCM）で 256 ビットの高度暗号化標準（AES-256）鍵を使用し、Cloud KMS 内部のメタデータでパディングされます。Autokey を使用すると、これらの設定が自動的に適用されます。
クライアントサイド暗号化などの他のユースケースについては、利用可能な鍵の用途とアルゴリズムを確認して、ユースケースに最適なオプションを選択してください。
ローテーション期間を選択する
ニーズに合わせて適切な鍵のローテーション期間を評価することをおすすめします。鍵のローテーションの頻度は、機密性またはコンプライアンスに基づくワークロードの要件によって異なります。たとえば、特定のコンプライアンス基準を満たすために、鍵のローテーションが少なくとも年に 1 回必要になる場合があります。また、機密性の高いワークロードの場合は、より頻繁なローテーション期間を選択することもあります。
対称鍵をローテーションすると、新しいバージョンが主鍵バージョンとしてマークされ、すべての新しいリクエストで情報保護に使用されます。古い鍵バージョンは、そのバージョンで保護されていた以前に暗号化されたデータの復号に引き続き使用できます。鍵をローテーションする場合、以前の鍵バージョンで暗号化されたデータは自動的に再暗号化されません。
鍵のローテーションを頻繁に行うことで、同じ鍵バージョンで暗号化されるメッセージの数を制限し、鍵が不正使用されるリスクと影響を軽減できます。
適切なアクセス制御を適用する
アクセス制御を計画する際は、最小権限の原則と職掌分散を検討することをおすすめします。以降のセクションでは、これらの推奨事項について説明します。
最小権限の原則を適用する
CMEK の管理権限を割り当てる場合は、最小権限の原則を考慮し、タスクの実行に必要な最小限の権限を付与します。基本ロールは使用しないことを強くおすすめします。代わりに、事前定義済みの Cloud KMS ロールを付与して、過剰な権限に関連するセキュリティ インシデントのリスクを軽減します。
職務の分離を計画する
暗号鍵を管理するユーザーと暗号鍵を使用するユーザーの ID と権限は、個別に管理します。NIST SP 800-152 では、暗号鍵管理システムのサービスを有効にして管理する暗号担当者と、それらの鍵を使用してリソースを暗号化または復号するユーザーの間の職掌分散が定義されています。
CMEK を使用して Cloud de Confiance サービスで保存時の暗号化を管理する場合、暗号鍵を使用する IAM ロールは個々のユーザーではなく、 Cloud de Confiance サービスのサービス エージェントに割り当てられます。たとえば、暗号化された Cloud Storage バケットにオブジェクトを作成するには、ユーザーに IAM ロール roles/storage.objectCreator のみが必要で、同じプロジェクト内の Cloud Storage サービス エージェント（service-PROJECT_NUMBER@gs-project-accounts.s3ns-system.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 の検出コントロールを構成する
Cloud de Confiance は、CMEK にさまざまな検出制御を提供します。以降のセクションでは、Cloud KMS に関連するこれらの制御を有効にして使用する方法について説明します。
監査ロギングを有効にして集約する
Cloud KMS 管理アクティビティ監査ログ（すべてのサービスの管理アクティビティ ログを含む）を、組織内のすべてのリソースに対して一元化された場所に集約することをおすすめします。これにより、セキュリティ チームや監査担当者は、Cloud KMS リソースの作成や変更に関連するすべてのアクティビティを一度に確認できます。集約ログシンクの構成については、組織のログを集約して保存するをご覧ください。
必要に応じて、データアクセス ログを有効にして、暗号化や復号などの鍵を使用するオペレーションを記録できます。CMEK を使用すると、CMEK を使用するすべてのサービスからのすべてのオペレーションでデータアクセス ログが作成されるため、ログの量が増加し、費用に影響する可能性があります。データアクセス ログを有効にする前に、追加のログの明確なユースケースを定義し、ロギング費用がどのように増加するかを評価することをおすすめします。
コンプライアンス要件を評価する
コンプライアンス フレームワークごとに、暗号化と鍵管理の要件が異なります。コンプライアンス フレームワークは通常、暗号鍵管理の一般的な原則と目的を概説しますが、コンプライアンスを実現する特定のプロダクトや構成については規定されていません。コンプライアンス フレームワークの要件と、鍵管理を含む自社での制御がそれらの要件を満たす方法を理解するのは、お客様の責任です。
さまざまなコンプライアンス フレームワークの要件を満たすうえで Cloud de Confiance サービスがどのように役立つかについては、次のリソースをご覧ください。ベスト プラクティスの概要
次の表に、このドキュメントで推奨するベスト プラクティスをまとめます。
| トピック | タスク |
|---|---|
| CMEK を使用するかどうかを決定する | CMEK で有効になる機能のいずれかが必要な場合は、CMEK を使用します。 |
| Cloud KMS 鍵プロジェクト | 環境ごとに 1 つの一元化された鍵プロジェクトを使用します。鍵で保護する Cloud de Confianceリソースと同じプロジェクトに Cloud KMS リソースを作成しないでください。 |
| Cloud KMS キーリング | Cloud de Confianceリソースを保護する各ロケーションに Cloud KMS キーリングを作成します。 |
| 鍵の粒度 | リスク許容度、費用、運用上のオーバーヘッドのニーズを満たす鍵の粒度のパターンを選択します。 |
| 保護レベル | 鍵マテリアルを Cloud de Confiance の外部に保存する必要がある場合や、レベル 2 またはレベル 3 の FIPS 140-2 認証が必要な場合は、Cloud EKM を選択します。それ以外の場合は、ソフトウェア キーを選択します。保護レベルを選択するためのガイダンスを確認してください。 |
| 鍵のマテリアル | Cloud de Confianceでホストされている鍵マテリアルには、可能な限り Cloud de Confiance生成の鍵マテリアルを使用します。インポートされた鍵マテリアルを使用する場合は、リスクを軽減するための自動化と手順を実装します。 |
| 鍵の目的とアルゴリズム | すべての CMEK 鍵は、対称 ENCRYPT_DECRYPT 鍵の目的と GOOGLE_SYMMETRIC_ENCRYPTION アルゴリズムを使用する必要があります。 |
| ローテーション期間 | 鍵の自動ローテーションを使用して、鍵がスケジュールどおりにローテーションされるようにします。ニーズに合ったローテーション期間を選択して適用します。1 年に 1 回以上が理想的です。機密性の高いワークロードには、より頻繁な鍵のローテーションを使用します。 |
| 最小限の権限 | プリンシパルがタスクを完了できる最も制限された事前定義ロールを付与します。基本ロールは使用しないでください。 |
| 職掌分散 | 鍵管理者と鍵を使用するプリンシパルの権限を別々に管理します。 |
| プロジェクト リーエン | プロジェクト リーエンを使用して、重要なプロジェクトが誤って削除されないようにします。 |
| CMEK を必須にする | constraints/gcp.restrictNonCmekServices 制約を使用します。 |
| 最短予定破棄期間を要求する | constraints/cloudkms.minimumDestroyScheduledDuration 制約を使用します。 |
| CMEK に許可される保護レベルを適用する | constraints/cloudkms.allowedProtectionLevels 制約を使用します。 |
| 監査ロギングを有効にして集約する | 組織内のすべてのリソースの管理アクティビティ監査ログを集計します。鍵を使用するオペレーションのロギングを有効にするかどうかを検討します。 |
| コンプライアンス要件を評価する | Cloud KMS アーキテクチャを確認し、遵守する必要があるコンプライアンス要件と比較します。 |