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

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

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

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

• 課金が有効な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 形式)を許可リストに追加する必要があります。

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

キーリングは既に使えるものがあればそれを再利用できます。キーリングはリージョナルなリソースで、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の検証を受けており、ソフトウェア鍵との費用差はわずかです。

gcloud kms keys create <your-key-name> \
  --project=<your-project-id> \
  --location=<region> \
  --keyring=<your-keyring-name> \
  --purpose=encryption \
  --protection-level=hsm

ソフトウェア保護でよい場合は --protection-level=hsm を省略します。それ以外の手順は変わりません。

権限は鍵単位の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)に使われます。コンソールから設定する場合は、鍵ではなくキーリングやプロジェクトの権限ページを開いてしまわないよう注意します。

最後に鍵のフルリソース名を控えます。登録時にAnthropicへ渡す値です。

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では、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} が返ります。検証後、新しいワークスペースを作る前に鍵を紐づけます(既存ワークスペースへの後付けは反映まで最大1日)。

Claude Enterpriseでは、claude.ai > Organization settings > Data and privacyのEncryption keysからAdd keyを選び、Google Cloudを選択して鍵のフルリソース名を貼り付けるだけです。検証後にverifiedと表示された時点から組織全体がCMEKで保護されます。ワークスペース単位の紐づけは無く、組織が持てる鍵も1つだけです。

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

公式ドキュメントは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側のリソースではなくAdmin API呼び出しなので、Terraformで完結させたい場合は null_resource や外部プロバイダーで補う設計が必要です。Terraform管理はキーリングと鍵の作成までに留め、Admin API側は別手順として切り出す構成になります。

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

Google Cloud特有の注意点として、データアクセス監査ログは既定で無効なので、検証や暗号化・復号のたびに「本当にAnthropicが鍵を使っているか」をログで追いたい場合は、設定前の段階で DATA_READ と DATA_WRITE を有効にしておく必要があります。後から有効にしても、それ以前の操作の記録は残りません。

リージョン選びも独立に考える必要があります。CMEKの暗号化処理は現状USリージョンでのみ処理されるため、キーリングは us-central1 か us-east5 のように、Anthropicの米国インフラに近い場所を選ぶとレイテンシを抑えられます。別リージョンで他のリソースを運用していても、CMEK用のキーリングだけをこれらのリージョンに新規作成する選択肢があります。

有効化後に効いてくる制約

鍵をワークスペースに紐づけた後は、その鍵を外したり別の鍵に差し替えたりはできません。別の鍵に切り替えたい場合は新しいワークスペースを作って移行する必要があります。紐づけと同時に、そのワークスペースのデータ保持設定(30日保持)も固定され、ゼロデータ保持に戻したい場合は新しいワークスペースへの移行が必要になります。Cloud KMSのローテーションスケジュールのように同じ鍵の中で鍵材料だけを更新する操作は透過的にサポートされ、Anthropic側の再設定は不要です。

鍵を取り消す(revoke)操作にも、反映まで最大1時間のキャッシュTTLがかかります。取り消しの直前に飛んでいたリクエストは、その間そのまま成功し続けることがあります。また、CMEKが保護するのは有効化後に書き込まれたデータだけで、それ以前の会話・ファイル・セッションはAnthropic管理鍵のまま残り、あとから自分の鍵で再暗号化されることはありません。鍵と鍵の暗号化・復号操作にはGoogle Cloud側のCloud KMS利用料が別途発生する点も予算に織り込んでおきます。

まとめ

Google Cloud KMSでのCMEK設定は、①シングルリージョンのキーリングと対称鍵(推奨はHSM保護)を作る、②鍵単位で2つのIAMロールをAnthropicのサービスアカウントに渡す、③Admin API(Claude Enterpriseならclaude.aiの組織設定)で登録・検証し、ワークスペースに紐づける、という流れです。マルチリージョンのキーリングが使えない点と、ドメイン制限共有の組織ポリシーがバインディングを無効化しうる点は、Google Cloud側で先に潰しておく落とし穴です。

AWS KMSやAzure Key Vaultで同じ組織にCMEKを構成する場合は、鍵の種類も検証の失敗パターンもクラウドごとに変わります。AWS KMSでCMEKを設定する手順とAzure Key VaultでCMEKを設定する手順も合わせて確認してください。Claude Managed Agentsを併用している場合、CMEKはエージェント設定やセッションデータも保護対象に含みますが、vault credentialの値だけはAnthropic管理鍵のまま残る点はManaged Agentsの設計思想で押さえておくと運用の見通しが立ちます。