このページでは、 Google Cloud リソースで顧客管理の暗号鍵（CMEK）を使用して保存データの暗号化を構成する際の推奨事項について説明します。このガイドは、クラウド アーキテクトとセキュリティ チームを対象としており、CMEK アーキテクチャの設計時に行う必要のある推奨事項と決定事項について説明します。
このガイドは、Cloud Key Management Service（Cloud KMS）と顧客管理の暗号鍵について理解しており、Cloud KMS の詳細を読んでいることを前提としています。CMEK を使用する場所を選択する
クラウド内のデータまたは顧客のデータの周囲に暗号境界を設定する場合は、顧客管理の暗号鍵を使用することをおすすめします。詳細については、顧客管理の暗号鍵（CMEK）をご覧ください。
互換性のあるサービスで手動で作成した CMEK または Autokey で作成した鍵を使用すると、次の目標を達成できます。暗号鍵を所有する。
ロケーション、保護レベル、作成、アクセス制御、ローテーション、使用、破棄の選択など、暗号鍵を制御、管理する。
Cloud KMS で鍵マテリアルを生成するか、 Google Cloudの外部で管理されている鍵マテリアルをインポートします。
鍵を使用する必要がある場所に関するポリシーを設定する。
オフボーディングが発生した場合や、セキュリティ イベントを修復（クリプト シュレッディング）する場合に、鍵で保護されたデータを選択して削除します。
お客様に固有の鍵を作成して使用し、データの周囲に暗号境界を確立します。
暗号鍵への管理とデータアクセスをログに記録する。
これらの目標のいずれかを必要とする現在または将来の規制に対応できます。
また、ビジネスニーズに適用されるコンプライアンス フレームワークを検討することもおすすめします。コンプライアンス フレームワークごとに、暗号化と鍵管理の要件が異なります。コンプライアンス フレームワークは通常、暗号鍵管理の一般的な原則と目的を概説しますが、コンプライアンスを実現する特定のプロダクトや構成については規定されていません。コンプライアンス フレームワークの要件と、鍵管理を含む自社での制御がそれらの要件を満たす方法を理解するのは、お客様の責任です。
Google Cloud サービスがさまざまなコンプライアンス フレームワークの要件を満たすのにどのように役立つかについては、次のリソースをご覧ください。
鍵マテリアルのソースを選択する
鍵を作成するときは、Cloud KMS で鍵マテリアルを生成するか、 Google Cloudの外部で生成された鍵マテリアルを手動でインポートする必要があります。可能な場合は、Cloud KMS で鍵マテリアルを生成することをおすすめします。このオプションでは、Cloud KMS の外部で未加工の鍵マテリアルが公開されるリスクがなく、選択した鍵のローテーション期間に基づいて新しい鍵バージョンが自動的に作成されます。独自の鍵マテリアルをインポートする必要がある場合は、次の運用上の考慮事項と、お客様所有の鍵（BYOK）方式を使用するリスクを評価することをおすすめします。
新しい鍵バージョンを一貫してインポートする自動化を実装できるかどうか。これには、鍵バージョンをインポートのみに制限する Cloud KMS の設定と、鍵マテリアルを一貫して生成してインポートするための Cloud KMS 以外の自動化の両方が含まれます。自動化で新しい鍵バージョンが想定どおりに作成されなかった場合、どのような影響があるか。
未加工の鍵マテリアルを安全に保存またはエスクローするにはどうすればよいか。
鍵のインポート プロセスで未加工の鍵マテリアルが漏洩するリスクをどのように軽減すればよいか。
未加工の鍵マテリアルが Google Cloudの外部に保持されているため、以前に破棄した鍵を再インポートする場合、どのような影響があるか。
鍵マテリアルを自分でインポートするメリットにより、運用オーバーヘッドとリスクの増加を正当化できるかどうか。
鍵ガバナンス モデルと鍵ストレージ モデルを選択する
CMEK アーキテクチャを設計する際は、鍵の管理場所と管理方法を決定する必要があります。理想的には、整合性のある鍵ガバナンス モデルと鍵ストレージ モデルを選択します。選択したガバナンス モデルとストレージ モデルは、職務分離の適用などの重要な構成に影響します。
鍵のガバナンス
鍵ガバナンスは、組織内の誰が Cloud KMS リソースのライフサイクルを管理し、Cloud KMS の使用方法を制御するためのガードレールを維持する責任を負うかを説明します。主なガバナンス アプローチは、一元化されたガバナンスから委任されたガバナンスまで、スペクトル上に存在します。
- 一元化されたガバナンス: 組織全体のすべての暗号鍵のライフサイクルを管理する専用のセキュリティ チームまたはプラットフォーム チームが担当します。このモデルは、厳格なコンプライアンス要件が適用される規制の厳しい企業でよく選択されます。
- 委任されたガバナンス: 中央のセキュリティ チームがガードレールを使用して暗号化標準を義務付けますが、鍵のライフサイクル オペレーションの責任はプロジェクト内のアプリケーション オーナーに委任します。これらのガードレールには、マネージド制約とカスタム制約を使用する組織のポリシー、IAM 許可ポリシーと拒否ポリシーなどがあります。これにより、中央の運用上のボトルネックが解消されます。
キーの保管
鍵ストレージは、組織内で Cloud KMS リソースが作成される場所を示します。鍵ストレージには、専用プロジェクトの鍵ストレージと同一プロジェクトの鍵ストレージという 2 つの主な方法があります。
専用プロジェクトの鍵ストレージ: 専用の鍵プロジェクトには、複数のアプリケーションで使用される鍵が含まれています。通常、各環境フォルダには独自の鍵プロジェクトがあります。Autokey は専用プロジェクトの鍵ストレージで使用できます。専用プロジェクトの鍵ストレージ モデルの詳細については、専用プロジェクトの鍵ストレージをご覧ください。
同じプロジェクトの鍵ストレージ: 鍵は、保護対象のリソースと同じGoogle Cloud プロジェクトに保存されます。これは「キーがデータに追従する」と表現されることもあります。Autokey は、同じプロジェクトの鍵ストレージで使用できます。同じプロジェクトの鍵ストレージ モデルの詳細については、同じプロジェクトの鍵ストレージをご覧ください。
ガバナンスとストレージを調整する
次のマトリックスは、さまざまな組織のニーズを満たすために、これらのガバナンス モデルとストレージ モデルを組み合わせる方法の例を示しています。
| ガバナンス モデル | 専用プロジェクトの鍵ストレージ | 同じプロジェクトの鍵ストレージ |
|---|---|---|
| ガバナンスの一元化 | 完全集中型のアプローチ 推奨される使用方法: プロジェクト境界の分離を義務付ける厳しい規制要件がある組織。 運用への影響: 設定の複雑さが増します。開発チームの運用遅延を防ぐために、堅牢な自動化（「プロジェクト ファクトリー」など）が必要です。 |
管理された所有権 推奨される使用方法: セキュリティの一元管理が必要だが、デベロッパーの速度を最大化したい組織。 運用への影響: 設定の複雑さが低い。一元化されたセキュリティは、ガードレールを使用してポリシーを適用します。鍵は、管理を容易にするために、保護するリソースと同じ場所に配置されます。 |
| 委任されたガバナンス | 非推奨 プロジェクト間の IAM の複雑さを導入すると、鍵管理をアプリケーション チームに委任する目的が損なわれます。 |
自律型 DevOps 推奨される使用方法: DevOps 文化が根強い、高速で分散型の組織。 運用への影響: 設定の複雑さが最小限に抑えられます。アプリケーション チームは、プロジェクト境界内のリソースと鍵の両方に対して完全な自律性を持ちます。 |
環境全体で一貫したアーキテクチャを使用する
任意のアプリケーションでは、開発環境、テスト環境、本番環境で同じキーストレージ パターンを使用することをおすすめします。このアーキテクチャの整合性により、IAM 権限、デプロイ パイプライン、セキュリティ制御を本番環境にデプロイする前に、下位環境で徹底的にテストできます。環境に異なるアーキテクチャを選択すると、構成のドリフトが発生し、デプロイの失敗につながる可能性があります。
専用プロジェクトの鍵ストレージ
専用プロジェクトの鍵ストレージ モデルでは、特定の環境フォルダ（本番環境など）のすべての鍵は、一元化された共有鍵プロジェクトに保存されます。鍵管理権限は、共有セキュリティ チームに付与されます。このチームは通常、CMEK 組織ポリシー、IAM ポリシー、ロール付与などの鍵のライフサイクル オペレーションとガードレールも管理します。
ユースケース
組織が暗号鍵の厳格な一元管理を優先する場合（多くの場合、規制要件によるもの）、または鍵が外部 HSM でホストされている場合は、専用プロジェクトの鍵ストレージ モデルを使用することをおすすめします。
組織が PCI DSS や BSI C5 などの暗号担当者または鍵管理者を必要とするコンプライアンス フレームワークの対象となる場合は、このモデルが適しています。アプリケーションのすべての鍵を単一の専用鍵プロジェクトに分離することで、Cloud KMS 管理者ロールを監査済みの少数のセキュリティ管理者のグループにのみ付与できます。これにより、主要な管理アクセス ポリシーを確認する必要があるプロジェクトの数を制限して、コンプライアンス監査を簡素化できます。
考慮事項
このアプローチでは、プロジェクト間の IAM の複雑さと、開発チームの潜在的なボトルネックが発生する可能性があります。 このリスクを軽減するために、自動化されたプロジェクト プロビジョニング（「プロジェクト ファクトリー」と呼ばれることもあります）を実装して、鍵の作成と権限の割り当てを自動化するか、Cloud KMS Autokey を使用して、Infrastructure as Code（IaC）パイプラインでも職務分離をサポートするオンデマンド プロビジョニングを有効にできます。
例
次の図は、専用プロジェクトの鍵ストレージ モデルを使用する本番環境のリソース階層の例を示しています。
- Prod フォルダには、さまざまなアプリケーションの個々のフォルダとプロジェクト、および Shared フォルダが含まれています。
- アプリケーション プロジェクトには、Compute Engine インスタンスや Cloud Storage バケットなど、さまざまなリソースが含まれていますが、Cloud KMS 鍵は含まれていません。
- Shared フォルダには、さまざまなアプリケーション間で共有されるリソースが含まれています。
- 共有フォルダ内には、Cloud KMS API が有効になっている専用の鍵プロジェクトがあります。このプロジェクトには、Prod フォルダ内のリソースを保護するために使用されるすべての鍵が含まれています。Cloud KMS Autokey を使用する場合、この専用の鍵プロジェクトは、Autokey が鍵をプロビジョニングする場所です。
- 組織のポリシー制約や IAM ポリシーなどの組織レベルとフォルダレベルのガードレールは、職務の分離やその他のプラクティスを適用します。
- デベロッパーは、キー プロジェクトに対する権限を付与することなく、個々のアプリケーション フォルダまたはプロジェクト内でプロジェクト オーナーのロールなどの権限昇格を持つことができます。
同じプロジェクトの鍵ストレージ
このモデルでは、鍵は保護対象のリソースと同じプロジェクトに保存されます。デベロッパーが独自のアプリケーションの鍵のライフサイクルを管理する場合でも、鍵管理ガードレールは通常、コア セキュリティ チームによって実装されます。
ユースケース
デベロッパーの速度、アジリティ、明確なアカウンタビリティを優先する場合は、同じプロジェクトの鍵ストレージ モデルを使用することをおすすめします。鍵を保護対象のリソースと同じ場所に配置すると、鍵の所有権とデータの所有権が一致します。つまり、鍵はデータに従います。このモデルにより、鍵管理の主な責任をワークロード オーナーに委任できます。ワークロード オーナーは、CMEK 組織のポリシーとの整合性を確保し、プロジェクト内の鍵のライフサイクル オペレーションを管理する責任を負います。
考慮事項
このモデルはアプリケーション チームに権限を付与しますが、最小権限を適用するには、各プロジェクト内の IAM ロールの厳格な監査が必要です。このモデルでは、システム間の調整のオーバーヘッドにより、Bring Your Own Key（BYOK）を実装している組織や Cloud EKM 鍵を使用している組織の運用上の複雑さが増す可能性があります。
例
次の図は、同じプロジェクトの鍵ストレージ モデルを使用する本番環境のリソース階層の例を示しています。
- Prod フォルダには、さまざまなアプリケーションの個々のフォルダとプロジェクトが含まれています。
- アプリケーション プロジェクトには、Compute Engine インスタンスや Cloud Storage バケットなど、さまざまなリソースが含まれています。これらのリソースを保護する Cloud KMS 鍵も含まれます。
- Cloud KMS Autokey を使用する場合、Autokey はリソース プロジェクトに鍵をプロビジョニングします。
- 組織のポリシー制約や IAM ポリシーなどの組織レベルとフォルダレベルのガードレールは、職務の分離やその他のプラクティスを適用しますが、Autokey を使用していない場合は、職務の分離を適用するために、より慎重な構成が必要になることがあります。
- Autokey を使用していない場合、デベロッパーはリソース プロジェクトに対する Cloud KMS の昇格された権限が必要です。Autokey を使用する場合、ユーザーに必要なのは、作成するリソースのサービス固有のロール（BigQuery ユーザーロールや Compute 管理者ロールなど）のみです。
職務の分離を実施する
ストレージ モデルに関係なく、暗号鍵を管理するユーザーと暗号鍵を使用するユーザーのプリンシパルと権限は個別に管理する必要があります。最小権限の原則と職掌分散を厳格に適用するには、特定の運用責任に基づいて IAM ロールを付与します。
次の表に、Cloud KMS で推奨されるロールの分離を示します。
| 責任範囲 | 推奨されるロール | 権限の概要 |
|---|---|---|
鍵管理（鍵のライフサイクルやガバナンスなど） これには、権限昇格が必要な人間の管理者と IaC プリンシパルが含まれます。 |
Cloud KMS 管理者（roles/cloudkms.admin） |
|
リソースのプロビジョニング（CMEK で保護されたリソースの作成など） これには、権限が昇格されていない人間のデベロッパーと IaC プリンシパルが含まれます。 |
次のようなサービス固有の管理者ロールまたは編集者ロール。
|
リソースの作成時に鍵を選択します。 |
鍵の使用状況（暗号化、復号など） このロールはサービス エージェントにのみ付与します。CMEK 統合で使用される鍵の場合、人間のプリンシパルにこれらの権限は必要ありません。 Autokey を使用すると、このロールはサービス エージェントに自動的に付与されます。 |
Cloud KMS 暗号鍵の暗号化/復号（roles/cloudkms.cryptoKeyEncrypterDecrypter） |
鍵を使用してデータを暗号化および復号します。 |
IaC パイプラインに最小権限昇格を適用する
多くの組織では、Terraform ランナーなどの Infrastructure as Code（IaC）パイプラインを使用して、リソースのプロビジョニングを自動化しています。鍵ストレージのアーキテクチャは、これらのパイプラインのセキュリティ ポスチャーに直接影響します。
Cloud KMS 鍵のプロビジョニングを自動化するには、鍵の生成と IAM ポリシーの変更を行うために、IaC パイプラインに特権管理者ロールを付与する必要があります。攻撃者が IaC パイプラインを侵害すると、キー管理プレーンに対する完全な管理者権限を取得する可能性があります。
- 専用プロジェクトの鍵ストレージを使用する場合、パイプラインには中央の Cloud KMS プロジェクトに対する管理者アクセス権が必要です。パイプラインが侵害されると、組織全体の鍵管理プレーンが公開される可能性があります。
- 同じプロジェクトの鍵ストレージを使用する場合、パイプラインに必要なのはリソース プロジェクトへの管理者アクセス権のみです。これにより、潜在的なリスクの範囲が特定のアプリケーションに限定されますが、プロジェクト内で昇格された権限を管理する必要があります。
Cloud KMS Autokey は、鍵のプロビジョニングを安全な Google 管理のサービス エージェントに委任することで、このリスクに対処します。これにより、継続的な鍵のプロビジョニングに最小権限のパイプラインを実装できます。
- 低権限のパイプライン: IaC パイプラインでは、
KeyHandleリソースを作成して鍵をリクエストするために、低権限の Cloud KMS Autokey ユーザー ロール（roles/cloudkms.autokeyUser）のみが必要です。 - 自動プロビジョニング: 実際の鍵の作成と IAM ポリシーの更新は、Google 管理の Cloud KMS サービス エージェントによってバックグラウンドで処理されます。
- リスクの範囲を限定する: パイプラインに付与される権限を最小限に抑えることで、この設計では、デプロイ パイプラインにキー作成権限やセキュリティ管理者権限を付与したり、ヘルパーロールを割り当てたりすることを回避します。これにより、パイプラインが侵害されるリスクが大幅に軽減されます。
Autokey を有効にする IaC パイプラインには、Cloud KMS Autokey 管理者（roles/cloudkms.autokeyAdmin）などのより権限の強いロールが必要です。したがって、IaC パイプラインを使用して Autokey の有効化を管理する場合は、個々の IaC プリンシパルにも職務分離を適用する必要があります。
Autokey を使用するかどうかを選択する
主要なストレージ アーキテクチャを選択したら、鍵のプロビジョニング方法を決定する必要があります。手作業によるトイルと構成エラーを減らすため、可能な限り Cloud KMS Autokey を使用して鍵の作成を自動化することをおすすめします。Autokey には、次の両方のストレージ モデルに対する組み込みサポートがあります。
- 同じプロジェクトの鍵ストレージを使用する Autokey: デベロッパーは、中央のガードレールに準拠しながら、独自のプロジェクト内で鍵をオンデマンドでシームレスに生成します。同じプロジェクトの鍵ストレージで Autokey を有効にするには、プロジェクトごと、またはフォルダ内のすべてのプロジェクトに対して有効にします。
- 専用プロジェクトの鍵ストレージを使用する Autokey: デベロッパーは、他のプロジェクトのリソースに代わって、中央の鍵プロジェクト内で鍵をシームレスに生成します。フォルダレベルで専用プロジェクトの鍵ストレージを使用して Autokey を有効にします。
Autokey を使用すると、次の推奨事項が自動化されます。
- 保護するリソースと同じロケーションに鍵を作成する
- 鍵管理者とリソース所有者の職掌分散を維持する
- 新しい鍵に IAM ロール付与を付与する
HSM保護レベルを使用します。- 推奨される粒度戦略に沿う
- 365 日ごとに鍵の自動ローテーションをスケジュールする
Cloud KMS Autokey は継続的な鍵のプロビジョニングと割り当てを処理するため、Autokey を使用すると、カスタム ポリシー、ツール、運用手順の確立に伴うオーバーヘッドを大幅に削減できます。初期費用と継続的な労力を軽減できますが、組織全体で一貫したガバナンスを確保するには、運用ガードレールを設定し、検出とモニタリングの制御を構成する必要があります。
コンプライアンスと Autokey
多くのコンプライアンス体制では、クラウド サービス プロバイダとは無関係に、暗号鍵の制御を最終的に維持することが求められています。
鍵のプロビジョニングのルーティン タスクを Cloud KMS Autokey に委任しても、この標準に違反することはありません。Autokey は、事前定義されたポリシーを実行する自動化エンジンとして厳密に機能します。次の 3 つの主なメカニズムにより、最終的な所有権、権限、暗号制御を保持できます。
- 暗号管理者は鍵に対する排他的な制御を保持します。鍵バージョンの無効化、ローテーション、破棄を行うことができるのは管理者のみです。Autokey サービスは、これらのライフサイクル アクションを実行できません。
- 管理者は、Autokey が有効になる場所と、鍵をリクエストできるプリンシパルを正確に決定します。Autokey を無効にするか、リソース階層の任意のレベルで権限を取り消すと、自動化が直ちに停止します。
- Autokey によって生成されたすべての鍵、割り当てられた権限、調整されたポリシーは、Cloud Logging に記録されます。これにより、監査人は継続的かつ自動化された監査証跡を使用してコンプライアンスを検証できます。
プロビジョニングを Autokey に委任すると、ガバナンスが弱まるのではなく、コンプライアンスが強化されます。手動でエラーが発生しやすい構成手順を、職務分離とパイプライン セキュリティのプログラムによる適用に置き換えることで、NIST SP 800-152 や PCI DSS などのコンプライアンス スキームの厳格な制御要件を満たします。
推奨される鍵管理のプラクティスに沿う
Google は、鍵のロケーション、保護レベル、ローテーション スケジュール、粒度、権限に関するプラクティスを推奨しています。 これらのプラクティスは、Cloud KMS Autokey を使用した自動化されたアプローチで実装することも、手動で構成することもできます。 暗号化指標ダッシュボードを使用すると、鍵がこれらの方法にどの程度準拠しているかを確認できます。職務分離の違反は、Security Command Center の脆弱性検出結果を使用して検出できます。
鍵のロケーション
手動 CMEK を使用する場合は、CMEK で暗号化されたリソースをデプロイする予定のロケーションに Cloud KMS キーリングを作成する必要があります。 Google Cloud 鍵を作成する前にこれを行う必要があります。- リージョン リソースとゾーン リソースは、リソースと同じリージョンまたは
globalロケーションのキーリングと鍵を使用する必要があります。 シングル リージョン リソースとゾーンリソースでは、global以外のマルチリージョン キーリングを使用できません。 - マルチリージョン リソース（
usマルチリージョンの BigQuery データセットなど）は、同じマルチリージョンのキーリングと鍵を使用する必要があります。マルチリージョン リソースではリージョン鍵を使用できません。 - グローバル リソースは、
globalロケーションのキーリングと鍵を使用する必要があります。
ほとんどの場合、これらの制限は Google Cloudサービスによって適用されます。
リージョン鍵の使用を強制することは、データ リージョナライゼーション戦略を成功させるための 1 つの要素です。定義されたリージョンでキーリングと鍵の使用を適用すると、リソースがキーリングのリージョンと一致するように強制されます。 データ所在地に関するガイダンスについては、データ所在地を制御するをご覧ください。 詳細については、適切なロケーションを選択するをご覧ください。
Cloud KMS Autokey を使用する場合、キーリングは保護するリソースと同じロケーションに作成されます。
キーの粒度戦略を選択する
粒度とは、各キーの使用目的の規模と範囲を指します。たとえば、複数のリソースを保護する鍵は、1 つのリソースのみを保護する鍵よりも粒度が低いと言われます。適切な鍵の粒度戦略を選択すると、各鍵に特定の目的があるという NIST の推奨事項に沿うことができます。
通常は、各キーを次のように使用することをおすすめします。
- 単一の Google Cloud プロジェクトに使用されます。
- 単一の場所で使用される（例:
us-central1）。 - 単一のサービスまたはプロダクト（BigQuery など）で使用されます。
- 可能な限り、単一のリソース（単一の Cloud Storage バケットなど）に使用されます。
ほとんどの組織にとって、この戦略は、粒度の高い鍵を多数維持するオーバーヘッドと、多くのプロジェクト、サービス、リソース間で共有される粒度の低い鍵を使用する潜在的なリスクとの間で、適切なバランスを提供します。
Cloud KMS Autokey で作成された鍵は、この推奨事項に沿っています。
この粒度ガイドラインに沿って作業すると、鍵のバージョンを安全に無効化または破棄しやすくなり、鍵の誤った破棄や悪意のある破棄のリスクを軽減できます。
鍵の保護レベルを選択する
お客様には、鍵を作成する場合、CMEK で暗号化されたデータとワークロードの要件に基づいて各鍵に適した保護レベルを選択する必要があります。次の質問は、評価に役立ちます。
特別な分離、所在地、規制の要件はありますか？ワークロードに次の高セキュリティ特性が必要かどうかを評価します。
- 外部ストレージ: Cloud EKM で手動 CMEK を使用します。可用性を高めるため、
EXTERNAL_VPCの保護レベルをおすすめします。 - 専用ハードウェア: シングルテナント Cloud HSM で手動 CMEK を使用します。
それ以外の場合は、次の質問に進みます。
- 外部ストレージ: Cloud EKM で手動 CMEK を使用します。可用性を高めるため、
鍵のプロビジョニングとライフサイクル管理を自動化しますか？
その場合は、Cloud KMS Autokey を使用します。Autokey は、マルチテナント Cloud HSM 保護レベルを使用して鍵を自動的に作成します。ソフトウェア格納型鍵が許容される場合でも、Cloud HSM のより高いセキュリティ ベースラインを受け入れて、Autokey が提供する自動化のメリットを享受することをおすすめします。
「いいえ」の場合は、次の質問に進みます。
鍵マテリアルをハードウェア セキュリティ モジュール（HSM）の物理的境界内に保持する必要がありますか？
- その場合は、マルチテナント Cloud HSM を使用します。
- そうでない場合は、ソフトウェア バックアップ鍵を使用します。
ローテーション期間を選択する
Cloud KMS は、CMEK に使用されるようなソフトウェア格納型とハードウェア格納型の対称鍵の自動鍵ローテーションをサポートしています。ソフトウェア ベースの鍵には、業界標準のローテーション期間である 90 日を使用することをおすすめします。Cloud HSM 鍵の場合は、業界標準のローテーション期間である 365 日間をおすすめします。外部キーは、選択したスケジュールに従って手動でローテーションする必要があります。
ニーズに合った適切な鍵のローテーション期間を評価することをおすすめします。鍵のローテーションの頻度は、機密性またはコンプライアンスに基づくワークロードの要件によって異なります。たとえば、特定のコンプライアンス基準を満たすために、鍵のローテーションが少なくとも年に 1 回必要になる場合があります。また、機密性の高いワークロードの場合は、より頻繁なローテーション期間を選択することもあります。
鍵のローテーションを頻繁に行うことで、同じ鍵バージョンで暗号化されるメッセージの数を制限し、鍵が不正使用されるリスクと影響を軽減できます。
最小権限の原則を適用する
IAM ロールを付与する場合は、最小権限の原則に従います。オーナー、編集者、閲覧者などの基本ロールの使用は避けることを強くおすすめします。代わりに、事前定義された Cloud KMS ロールを付与して、過剰な権限によるアクセスに関連するセキュリティ インシデントのリスクを軽減します。たとえば、プリンシパルが鍵マテリアルのインポートのみを必要とする場合は、権限の強い Cloud KMS 管理者ロール（roles/cloudkms.admin）ではなく、Cloud KMS インポータ ロール（roles/cloudkms.importer）を付与します。
運用上のガードレールを設定する
以降のセクションでは、鍵の使用の不整合、誤って削除または破棄されるなどのリスクを軽減するために実装できる制御について説明します。
プロジェクトのリーエンを適用する
Cloud KMS プロジェクトとそれに含まれる鍵が誤って削除されないように、リーエンでプロジェクトを保護する（プレビュー）ことをおすすめします。プロジェクト リーエンが適用されている間、リーエンが削除されるまでプロジェクトは削除できません。Cloud KMS 鍵を含むプロジェクトの場合、これにより、鍵の誤削除の原因となる可能性を 1 つ防ぐことができます。
CMEK 鍵を必須にする
組織のポリシーの制約を使用して、環境全体で CMEK の使用を適用することをおすすめします。
constraints/gcp.restrictNonCmekServices を使用して、CMEK 鍵を指定せずに特定のリソースタイプを作成するリクエストをブロックします。
Cloud KMS Autokey を必須にする
Cloud KMS Autokey を使用してすべての CMEK を作成すると、鍵が一貫して作成されます。この整合性を適用する場合は、Autokey で作成された CMEK を必須とし、手動で作成された鍵が CMEK に使用されないようにフォルダを構成できます。これらの制限を構成する方法については、Autokey の使用を適用するをご覧ください。
最短予定破棄期間を要求する
破棄の予定期間を最小に設定することをおすすめします。鍵の破棄は取り消し不能なオペレーションであり、データが完全に失われる可能性があります。デフォルトでは、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 の脆弱性検出に対して Security Command Center を有効にする
Security Command Center は、Cloud KMS や他のリソースに関連する構成ミスをハイライト表示する脆弱性検出結果を生成します。Security Command Center を有効にして、検出結果を既存のセキュリティ運用に統合することをおすすめします。検出される問題には、一般公開されている Cloud KMS 鍵、過剰な権限が付与された owner ロールを持つ Cloud KMS プロジェクト、職掌分散に違反する IAM ロールなどが含まれます。
モニタリングと修復
鍵の使用状況と推奨事項との整合性の確認は、CMEK 設定のリスクと構成ミスを特定するための重要な検出制御として機能するため、モニタリング戦略の中核コンポーネントにすることをおすすめします。検出結果を追跡し、セキュリティ手順に沿ってトリアージして、迅速に修正します。次のツールは、セキュリティ ポスチャーを改善するために解決できる問題を特定するのに役立ちます。
暗号化指標ダッシュボード: 暗号化指標を表示して、どのリソースが CMEK で保護されているか、それらの CMEK が推奨事項にどの程度準拠しているかを確認できます。CMEK で保護されていないリソースのリストと、推奨事項に完全には準拠していない鍵のリストを表示することで、修正する問題を特定できます。
鍵の使用状況ダッシュボード: 鍵の使用状況を表示すると、Cloud KMS 鍵に依存して保護されている組織内のリソースを特定できます。 Google Cloud このダッシュボードを使用すると、鍵バージョンと、それらが保護するリソースの状態、使用状況、可用性をモニタリングできます。また、無効または破棄された鍵が原因でアクセスできないデータもダッシュボードで識別されるため、アクセスできないデータのパージや鍵の再有効化などのアクションを実行できます。鍵の使用状況ダッシュボードの情報は、Cloud KMS Inventory API を使用して取得することもできます。
重要なイベントを自動的に検出して、鍵の使用状況ダッシュボードを定期的に確認する運用計画を立てることをおすすめします。
ベスト プラクティスの概要
次の表に、このドキュメントで推奨するベスト プラクティスをまとめます。
| トピック | タスク |
|---|---|
| 手動または自動での鍵の作成を選択する | 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 を選択します。鍵マテリアルを他の Google Cloud ユーザーと共有する 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 を一貫して使用するための労力が軽減される仕組みについて学ぶ。