Claude CMEKをGoogle Cloud KMSで設定する手順

Google Cloud KMSでCMEKを設定する前に確認すること

CMEK(customer-managed encryption key)は、ClaudeのワークスペースデータをAnthropic管理鍵ではなく自分のGoogle Cloud KMS鍵で暗号化する仕組みです。鍵は自分のGoogle Cloudプロジェクトに作り、AnthropicのサービスアカウントにIAMバインディングでアクセス権を渡します。

CMEKはオプトイン方式で、有効にするには担当のアカウントチームへの連絡が要ります。設定できるのは、Claude PlatformではOrganization Admin、Claude EnterpriseではOwnerとPrimary Ownerだけです。ゼロデータ保持(ZDR)との併用もできます。

前提として次を揃えます。

• 課金が有効なGoogle Cloudプロジェクト
• Cloud KMS API(cloudkms.googleapis.com)の有効化
• KMSのキーリングと鍵を作りIAMポリシーを設定できる権限(roles/cloudkms.admin 相当)
• 組織のAnthropic Admin APIキーと、認証済みの gcloud CLI
• プロジェクトでのCloud KMSデータアクセス監査ログの有効化(IAM & Admin > Audit Logs > Cloud Key Management Serviceで DATA_READ と DATA_WRITE)

監査ログは既定で無効です。有効にしないと、Anthropicの暗号化・復号の操作がCloud Loggingに一件も残りません。

プロジェクトが constraints/iam.allowedPolicyMemberDomains というドメイン制限共有の組織ポリシーの配下にある場合、Anthropicのサービスアカウントは自組織の外にあるため、後述のIAMバインディングは拒否されます。プロジェクト単位の例外を設けるか、AnthropicのCloud Identityのカスタマー ID(C0xxxxxxxx 形式)を許可リストに加えます。カスタマー IDはAnthropicに問い合わせて受け取ります。

キーリングと鍵を作りサービスアカウントへ権限を渡す

キーリングは既存のものを再利用できます。リージョナルなリソースなので、us や global のようなマルチリージョンは使えません。設定するAnthropicのgeoに合わせて、us-east5 のようなシングルリージョンのUSロケーションを選びます。

gcloud kms keyrings create <your-keyring-name> \
  --project=<your-project-id> \
  --location=<region>

次に ENCRYPT_DECRYPT 用途の対称鍵を作ります。AnthropicはHSM保護を強く推奨しています。Cloud KMSのHSM鍵はFIPS 140-2 Level 3の検証を受けており、ソフトウェア鍵との費用差はわずかです。

ここで見落としやすいのが組織ラベルです。anthropic-org-<ORGANIZATION_UUID> というキーに値 true を付けたラベルが、Anthropic側の鍵検証に必須とされています。<ORGANIZATION_UUID> は自分のAnthropic組織IDを小文字にしたもので、org_ の接頭辞は付けません。

ラベル付きで鍵を作るコマンドは次のとおりです。

gcloud kms keys create <your-key-name> \
  --project=<your-project-id> \
  --location=<region> \
  --keyring=<your-keyring-name> \
  --purpose=encryption \
  --protection-level=hsm \
  --labels=anthropic-org-<organization-uuid>=true

ソフトウェア保護でよい場合は --protection-level=hsm を省略します。それ以外の手順は変わりません。Google Cloudコンソールから作るなら、キーリングを開いてCreate keyからGenerated keyを選び、用途とアルゴリズムを対称の暗号化・復号にして、保護レベルはHSMにします。

ラベルを付け忘れた既存の鍵には、あとから追加できます。--update-labels は鍵が持つ既存のラベルとマージされるので、他のラベルは消えません。

gcloud kms keys update <your-key-name> \
  --project=<your-project-id> \
  --location=<region> \
  --keyring=<your-keyring-name> \
  --update-labels=anthropic-org-<organization-uuid>=true

1つの鍵を複数のAnthropic組織で共有するときは、組織ごとに同じ形式のラベルを足します。ラベルは1つの鍵に最大64個で、自分用のラベルも含めた数です。

権限は鍵単位の2つのIAMバインディングで渡します。プロジェクト全体やキーリング全体には広げません。

gcloud kms keys add-iam-policy-binding <your-key-name> \
  --project=<your-project-id> \
  --location=<region> \
  --keyring=<your-keyring-name> \
  --member="serviceAccount:anthropic-cmek-client-us@gcp-anthropic-cmek-clients.iam.gserviceaccount.com" \
  --role=roles/cloudkms.cryptoKeyEncrypterDecrypter
 
gcloud kms keys add-iam-policy-binding <your-key-name> \
  --project=<your-project-id> \
  --location=<region> \
  --keyring=<your-keyring-name> \
  --member="serviceAccount:anthropic-cmek-client-us@gcp-anthropic-cmek-clients.iam.gserviceaccount.com" \
  --role=roles/cloudkms.viewer

cryptoKeyEncrypterDecrypter は、ワークスペースデータを守るデータキーの暗号化・復号(エンベロープ暗号化)に使われます。viewer は、起動時に鍵の用途とアルゴリズムを確かめるメタデータ読み取り(cryptoKeys.get)用です。コンソールから設定するときは、鍵のPermissionsパネルでGrant accessを押し、2つのロールを同じ画面で付けます。キーリングやプロジェクトの権限ページを開くと、付与範囲が広がってしまいます。

最後に鍵のフルリソース名を控えます。登録時にAnthropicへ渡す値です。コンソールなら鍵の詳細ページのCopy resource nameでも取れます。

gcloud kms keys describe <your-key-name> \
  --project=<your-project-id> \
  --location=<region> \
  --keyring=<your-keyring-name> \
  --format="value(name)"

形式は projects/<your-project-id>/locations/<region>/keyRings/<your-keyring-name>/cryptoKeys/<your-key-name> です。

作成した鍵をAnthropicへ登録して検証する

登録の入口は契約しているプロダクトで変わります。スコープの違いは、どこで躓くかにも関わります。

Claude Platformの場合

Claude Consoleでは、次の流れで進めます。

Admin APIで進めるなら、鍵のフルリソース名を渡して外部鍵を登録します。

curl -sS "https://api.anthropic.com/v1/organizations/external_keys" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "display_name": "<friendly-name>",
    "geo": "us",
    "provider_config": {
      "type": "gcp",
      "key_name": "projects/<your-project-id>/locations/<region>/keyRings/<your-keyring-name>/cryptoKeys/<your-key-name>"
    }
  }'

レスポンスの ekey_<id> を使って、暗号化・復号のラウンドトリップを検証します。

curl -sS -X POST "https://api.anthropic.com/v1/organizations/external_keys/ekey_<id>/validate" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01"

成功すれば {"type": "external_key_validation", "status": "success", "error": null} が返ります。検証が通ったら、ワークスペースの更新エンドポイントに external_key_id を渡して紐づけます。

curl -sS -X POST "https://api.anthropic.com/v1/organizations/workspaces/<workspace-id>" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "external_key_id": "ekey_<id>"
  }'

紐づけのタイミングが肝心です。Anthropicは、新しいワークスペースを作り、リクエストを1件も送る前に鍵を紐づけることを勧めています。すでにリクエストを受けているワークスペースに後から付けると、反映まで最大1日かかります。その間に書かれたデータは、既存データと同じくAnthropic管理鍵のままで、あとから再暗号化されません。

Claude Enterpriseの場合

claude.ai > Organization settings > Data and privacyでEncryption keysを開き、Add keyを押します。Google Cloudを選んでフルリソース名を貼り、Continueに進みます。暗号化・復号の検証が走り、verifiedと表示された時点から、組織はCMEKで保護されます。

TerraformでCMEK設定をコード化できるか

Google Cloud KMSの設定ガイドにTerraformのサンプルコードはありません。あるのは、同じ手順が google プロバイダーの google_kms_key_ring、google_kms_crypto_key、google_kms_crypto_key_iam_member にマッピングできるという一文だけです。

対応づけると、キーリングは google_kms_key_ring、対称鍵とHSM保護レベルは google_kms_crypto_key です。組織ラベルも鍵の属性なので、鍵のリソースに載せることになるでしょう。Anthropicのサービスアカウントへの2つのIAMバインディングは、google_kms_crypto_key_iam_member を2回使い、roles/cloudkms.cryptoKeyEncrypterDecrypter と roles/cloudkms.viewer を付けます。

一方、Anthropicへの外部鍵の登録・検証・ワークスペースへの紐づけは、Google Cloudのリソースではなく、AnthropicのConsoleかAdmin APIの操作です。Terraformの管理範囲は、キーリングと鍵とIAMバインディングまでで区切るのが素直です。

検証やアクセスでよくあるつまずき

もう1つ、IP制限による遮断があります。Anthropicはキー管理サービスを標準のパブリックIPレンジから呼び出します。鍵へのアクセスをIPで絞っている環境では、AnthropicのIPアドレス一覧を許可する必要があります。

組織ラベルの付け忘れも、検証が通らない原因になります。ラベルが必須とされているのは鍵の検証のためなので、検証で止まったらIAMだけでなく、鍵に anthropic-org-<organization-uuid> ラベルが付いているかも見ます。

ログの在処も押さえておきます。CMEKの設定変更のイベントは、AnthropicのCompliance APIのActivity Feedに出ます。一方、Anthropicが鍵に対して行うデータキーのラップ・アンラップは、Compliance APIには出ません。自分のGoogle Cloud側の監査ログに記録されるので、前提で触れたデータアクセス監査ログが効いてきます。

リージョン選びも見ておきます。CMEKの暗号化処理は、Claude Platform on AWS以外ではUSリージョンだけで行われます。Anthropicの米国インフラに近い us-central1 か us-east5 を選ぶと、レイテンシを抑えられます。

有効化で止まる機能と戻せない制約

CMEKを有効にすると、一部の機能が止まるか挙動が変わります。公式の一覧は網羅的ではないとされているので、有効化の前にチームで見ておく価値があります。

不可逆な制約もあります。鍵をワークスペースに紐づけたあとは、外したり別の鍵に差し替えたりできません。別の鍵にしたければ、新しいワークスペースを作って移行します。

Claude Platformでは、紐づけと同時にそのワークスペースの30日データ保持の設定が固定されます。ゼロデータ保持に戻すには、新しいワークスペースを作ってトラフィックを移す必要があります。Cloud KMSのローテーションスケジュールのように、同じ鍵の中で鍵材料だけを更新する操作は透過的に扱われ、Anthropic側の再設定は要りません。

鍵を取り消したり無効にしたりすると、そのワークスペースのCMEK保護データには永久にアクセスできなくなります。戻す手段はありません。取り消しの反映には最大1時間のキャッシュTTLがかかり、その間に飛んでいたリクエストは成功し続けることがあります。

保護の範囲にも限りがあります。CMEKが守るのは有効化後に書き込まれたデータだけです。それ以前の会話・ファイル・セッションはAnthropic管理鍵のまま残ります。キャッシュなど保存期間が24時間より短いデータや、Managed Agentsのvault credentialの値も、Anthropic管理鍵のままです。

費用面では、Cloud KMS側の利用料が別途かかる場合があります。Claude Codeを ANTHROPIC_BASE_URL で別のゲートウェイやプロキシ経由にしている場合は、運用テレメトリにCMEKが及びません。止めたいときは環境変数 DISABLE_TELEMETRY を 1 にします。

まとめ

Google Cloud KMSのCMEKは、鍵の作成よりも、組織ラベル・鍵単位のIAM・ドメイン制限共有の3点で止まりやすい設定です。ワークスペースへ紐づけたあと(Enterpriseでは登録後)は外せず、鍵の運用がデータの可用性そのものになります。

AWS KMSやAzure Key Vaultで同じ組織にCMEKを構成する場合は、鍵の種類も検証の失敗パターンもクラウドごとに変わります。AWS KMSでCMEKを設定する手順とAzure Key VaultでCMEKを設定する手順も参照してください。Claude Managed Agentsを併用している場合、CMEKはエージェント設定やセッションデータも保護対象に含みます。仕組みの全体はManaged Agentsの設計思想に書いています。