Google Workspace 向け Cloud HSM のベスト プラクティス

このドキュメントでは、Google Workspace 用 Cloud HSM を構成するためのベスト プラクティスについて説明します。これにより、鍵マテリアルが偶発的または不正な破棄や削除から保護され、重要な暗号鍵の高可用性と耐久性が確保され、規制とコンプライアンスの要件を満たすことができます。

このドキュメントは、Google Workspace のクライアントサイド暗号化（CSE）で使用される暗号鍵のセキュリティと運用上の復元性を担当するクラウド アーキテクト、セキュリティ チーム、Google Workspace 管理者を対象としています。このドキュメントは、Google Workspace 向け Cloud HSM についてすでに理解しており、オンボーディング プロセスを完了していることを前提としています。

鍵マテリアルの損失を軽減する

プリンシパルが破壊的なアクション（特にプリンシパルの通常の業務範囲外のアクション）を完了する権限を付与するロールを保持している場合、セキュリティ リスクが発生する可能性があります。たとえば、プロジェクト オーナー（roles/owner）ロールが広すぎるユーザーは、Google Workspace CSE に使用される鍵マテリアルを破棄し、暗号化されたデータに永久にアクセスできなくなる可能性があります。

以降のセクションでは、Google Workspace クライアントサイド暗号化（CSE）で使用される Cloud KMS 鍵マテリアルの破棄または削除の権限を削除し、鍵の破棄を制限することで、鍵の誤った破棄と悪意のある破棄の両方のリスクを軽減するプラクティスについて説明します。

フォルダレベルの IAM 拒否ポリシーを適用する

IAM 拒否ポリシーを使用すると、プリンシパルが保持するロールによって権限が付与されている場合でも、プリンシパルに権限を拒否できます。たとえば、ユーザーにプロジェクト オーナー（roles/owner）ロールが付与されていても、フォルダレベルの IAM 拒否ポリシーによって、鍵の破棄や削除が禁止されることがあります。Cloud HSM プロジェクトをフォルダ内に配置し、フォルダレベルで拒否ポリシーを適用すると、ポリシーが適用されている間、鍵の破棄と削除を防ぐガードレールが作成されます。フォルダに対する拒否管理者（roles/iam.denyAdmin）などのロールがないと、適用された拒否ポリシーをキャンセルできません。

フォルダ管理者（roles/resourcemanager.folderAdmin）や拒否管理者（roles/iam.denyAdmin）などのフォルダ管理ロールは、Cloud HSM 鍵が存在するプロジェクトで Cloud KMS 管理者（roles/cloudkms.admin）ロールも持たないプリンシパルにのみ付与されていることを確認します。この職務分離により、1 つのプリンシパルが鍵の管理と破棄の両方を行うことはできません。

次の構成例に基づいて拒否ポリシーを設定します。

displayName: Deny KMS key destruction and deletion
rules:
- description: "Denies destroy and delete permissions on Cloud KMS keys for all principals."
  denyRule:
    deniedPrincipals:
    - "principalSet://goog/public:all"
    deniedPermissions:
    - "cloudkms.googleapis.com/cryptoKeyVersions.destroy"
    - "cloudkms.googleapis.com/cryptoKeys.delete"

IAM 拒否ポリシーの詳細については、IAM 拒否ポリシーの概要をご覧ください。

鍵の破棄に組織のポリシーの制約を適用する

IAM 以外にも、組織のポリシーの制約を使用して、組織レベルまたはフォルダレベルでセキュリティ ガードレールを適用できます。これらの制約は、作成できるリソースの種類と構成方法を制限する厳格な要件として機能します。適用された組織のポリシーの制約は、禁止されたアクションを完了するために必要な権限を持つプリンシパルであっても、バイパスできません。組織に組織ポリシー管理者（roles/orgpolicy.policyAdmin）などのロールがないと、適用された組織のポリシーの制約をキャンセルできません。

  • 最小破棄期間（constraints/cloudkms.minimumDestroyScheduledDuration）: ポリシーが有効になっている組織またはリソース内のすべての鍵に、最小の破棄予定期間（90 日または 120 日など）を適用します。この制約により、ユーザーは復元ウィンドウを構成された最小値より短くすることができなくなります。
  • 破棄前に無効にする（constraints/cloudkms.disableBeforeDestroy）: 鍵バージョンの破棄をスケジュールする前に、鍵バージョンが DISABLED 状態になっていることを要求します。この制約により、削除ワークフローに必須のステップが追加され、監査ログでのアクションの可視性が向上します。

詳細については、鍵バージョンの破棄を制御するをご覧ください。

鍵破棄のウィンドウを最大化する

鍵バージョンの破棄がスケジュールされると、削除猶予期間に入ります。鍵バージョンが破棄の予定状態の間は、鍵を復元して鍵の破棄をキャンセルできます。この構成可能な期間を最長の 120 日に設定すると、誤って、または悪意を持って削除がスケジュールされた鍵バージョンを復元するのに十分な時間を確保できます。この値は、鍵の作成時にのみ設定できます。

破棄がスケジュール設定されている鍵バージョンを復元すると、鍵バージョンの状態が DISABLED に設定されます。暗号化された Google Workspace データへのアクセスを復元するには、鍵バージョンを再度有効にする必要があります。

次の gcloud CLI コマンドは、120 日間のスケジュールされた破棄期間で HSM バックアップ鍵を作成します。

gcloud kms keys create KEY_NAME \
    --location LOCATION \
    --keyring KEY_RING \
    --purpose encryption \
    --protection-level hsm \
    --destroy-scheduled-duration 120d

次のように置き換えます。

  • KEY_NAME: 鍵の名前
  • LOCATION: キーリングの Cloud KMS のロケーション
  • KEY_RING: 鍵を含むキーリングの名前。

この期間を各鍵に設定するのではなく、組織内のすべての鍵に適用するには、カスタムの組織のポリシー制約を定義して適用します。次の制約の例では、破棄予定日までの期間が 90 ～ 120 日の場合にのみ、ユーザーが鍵を作成できます。

name: organizations/ORGANIZATION_ID/customConstraints/custom.limitScheduledDestruction
resourceTypes:
- cloudkms.googleapis.com/CryptoKey
methodTypes:
- CREATE
condition: "resource.destroyScheduledDuration >= duration('7776000s') && resource.destroyScheduledDuration <= duration('10368000s')"
actionType: ALLOW
displayName: Require scheduled destruction duration between 90 and 120 days
description: Allows key creation only if the destroyScheduledDuration is between 90 and 120 days.

ORGANIZATION_ID は、組織の数値 ID に置き換えます。

破棄のスケジュール設定期間の構成の詳細については、鍵バージョンの破棄と復元をご覧ください。Cloud KMS でカスタムの組織のポリシー制約を使用する方法については、Cloud KMS にカスタムの組織のポリシー制約を作成するをご覧ください。

インフラストラクチャとプロジェクトを保護する

このドキュメントで説明したガードレールは、キーの破棄と削除を防ぐことに重点を置いています。ただし、キー プロジェクトの削除を防ぐためのガードレールも必要です。次のガードレールを使用して、Google Workspace キーを格納するプロジェクト環境を保護します。

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

プロジェクト リーエンにより、プロジェクトが削除されなくなります。プロジェクト オーナー（roles/owner）のロールを持つユーザーでも、リーエンが有効な間はプロジェクトをシャットダウンできません。これは、Google Workspace キーが存在するプロジェクトが誤って削除されたり、不正に削除されたりするのを防ぐ最も効果的な方法です。

プロジェクトのリーエンの詳細については、リーエンによるプロジェクトの保護をご覧ください。

プロジェクトの復元期間について

プロジェクトが正常に削除されると（プロジェクトの留置権（プレビュー版）が削除された後など）、30 日間の復元期間に入ります。この期間中、プロジェクト オーナー（roles/owner）または組織管理者（roles/resourcemanager.organizationAdmin）のロールを持つユーザーは、プロジェクトを復元できます。30 日が経過すると、プロジェクトとその中のすべての鍵が完全に削除されます。

プロジェクトの留置権はそのままにして、復元ウィンドウは最後の手段としてのみ使用することをおすすめします。

プロジェクトの復元について詳しくは、削除したプロジェクトを復元するをご覧ください。

VPC Service Controls を使用する

VPC Service Controls を使用すると、Cloud HSM プロジェクトの周囲にセキュリティ境界を定義できます。これにより、Cloud KMS API には信頼できるネットワークまたは特定の ID からのみアクセスできるようになり、企業環境外からの不正な管理アクションのリスクを軽減できます。

インポートした鍵（BYOK）で鍵マテリアルの主権を確保する

ほとんどの組織では、Cloud HSM に鍵マテリアルの生成と管理を任せることをおすすめします。

ただし、独自の鍵（BYOK）機能が必要な場合は、オンプレミスで鍵マテリアルを生成して Cloud HSM にインポートできます。この BYOK アプローチでは、鍵マテリアルの独立したオンプレミス コピーの維持などの要件を満たすことができます。たとえば、データ主権の要件を満たしたり、鍵マテリアルの壊滅的な損失から復元したりできます。この方法では、Cloud KMS の鍵バージョンが破棄された場合に再インポートできる鍵マテリアルの独立したコピーを取得できます。

同じバージョンに再インポートする

Cloud KMS では、破棄された鍵バージョンに同じ鍵マテリアルを再インポートして、リソース識別子と URI を元のインポートされた鍵バージョンと同じにすることができます。これにより、同じ Google Workspace 構成を引き続き使用できます。Google Workspace 構成で使用されている鍵バージョンを再インポートすると、鍵バージョンのインポートが完了するとすぐにデータアクセスが復元されます。

破棄された鍵バージョンの再インポートの詳細については、破棄された鍵バージョンの再インポートをご覧ください。

シングルテナント Cloud HSM による高度な保護

最高レベルの分離を必要とするお客様向けに、Single-tenant Cloud HSM は専用の HSM パーティションを提供します。シングルテナント Cloud HSM インスタンスは、クォーラム認証を使用して作成および管理されます。この認証では、シングルテナント Cloud HSM インスタンスの削除などの重要なオペレーションの前に、構成された最小数のクォーラム メンバーの承認が必要です。これにより、単一の不正使用されたアカウントによって Single-tenant Cloud HSM インスタンスが破壊されるのを防ぐことができます。Single-tenant Cloud HSM を使用する場合は、次のプラクティスが適用されます。詳細については、クォーラムベースの認証をご覧ください。

プロジェクト間でインフラストラクチャと鍵を分離する

Single-tenant Cloud HSM インスタンスと Google Workspace キーを別々のプロジェクトに作成します。リソース プロジェクトを分離すると、鍵プロジェクトの管理者ロールを持つユーザーが基盤となるシングルテナント Cloud HSM インスタンスに対する権限を持たないようにできます。インフラストラクチャ管理と鍵管理の職務分離により、インフラストラクチャ レベルでの不正な操作のリスクが軽減されます。

Single-tenant Cloud HSM の詳細については、Single-tenant Cloud HSM の概要をご覧ください。

ベスト プラクティスの概要

次の表に、このドキュメントで推奨するベスト プラクティスをまとめます。

トピック タスク
IAM 拒否ポリシー フォルダレベルの拒否ポリシーを適用して、高い権限を持つユーザーでも鍵の破棄と削除をブロックします。
組織ポリシーの制約 制約を適用して、最短復元期間を義務付け、破棄する前に鍵を無効にするよう要求します。
破棄予定期間
  • 破棄の予定の値を最長 120 日に設定して鍵を作成します。期間を短くすることもできますが、破棄が予定されているキーを復元できるだけの十分な期間を確保してください。
  • カスタムの組織のポリシーの制約を使用すると、ニーズに適した期間ですべての鍵が作成されるようにできます。
プロジェクト リーエン プロジェクト リーエンを適用して、暗号鍵を格納するプロジェクトが削除されないようにします。
VPC Service Controls の境界 VPC Service Controls の境界を定義して、信頼できるネットワークと ID への Cloud KMS API アクセスを制限します。
BYOK の再インポート オンプレミスで鍵マテリアルを生成し、再インポートを使用して、リソース名を変更せずに破棄された鍵バージョンを復元します。
クロス プロジェクト アーキテクチャ Single-tenant Cloud HSM を使用する場合は、職務の分離を強制するために、Single-tenant Cloud HSM インスタンスと鍵を異なるプロジェクトに分離します。

次のステップ