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