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