Claude CMEKをAWS KMSで設定する — ARN登録とTerraform

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

CMEK(customer-managed encryption key)は、ClaudeのワークスペースデータをAnthropicではなく自分が管理する鍵で暗号化する仕組みです。AWS KMSで設定する場合、鍵を作るのは自分のAWSアカウントで、AnthropicのIAMロールにその鍵へのアクセス権を渡す形になります。

CMEKは任意の機能で、有効にするにはAnthropicのアカウントチームへの連絡が要ります。設定できるのは、Claude PlatformではOrganization Admin、Claude Platform on AWSではAdminロール、Claude EnterpriseではOwnerとPrimary Ownerです。

始める前に次を用意します。

• KMSキーの作成とキーポリシー設定ができる権限(kms:CreateKey と kms:PutKeyPolicy)を持つAWSアカウント
• 組織のAnthropic Admin APIキー(Claude Consoleから操作するなら不要です)
• 認証済みのAWS CLI

CMEKの有効化は取り消せません。鍵を削除・無効化すると、Anthropicはその鍵で暗号化されたデータを復元できません。Anthropicは鍵のコピーを持たないため、設定ミスや鍵の紛失がそのままデータの永久消失になります。

もう一点、保護の対象は鍵が有効になった後に書き込まれたデータです。過去のチャットやファイル、セッションはAnthropic管理の鍵で暗号化されたまま残り、あとから再暗号化されません。

CMEKはZero data retentionと併用できますが、契約形態によって適用範囲が変わる点はClaude Zero Data Retentionが有効になる契約形態側で先に確認しておくと迷いません。

KMSキーを作成しAnthropicのIAMロールへ権限を渡す

AWS KMSでの設定は、クロスアカウントのキーポリシーを持つ対称鍵を作るところから始まります。キーポリシーには3つのステートメントが要ります。

1. アカウントルート管理者への標準的なKMS権限。自分のアカウントは常にフル管理権限を保持します。
2. Anthropicの暗号化・復号権限。kms:Encrypt と kms:Decrypt を許可し、ワークスペースデータを守るデータキーの暗号化・復号(エンベロープ暗号化)に使われます。
3. Anthropicのメタデータ読み取り権限。起動時のヘルスチェックで使う kms:DescribeKey です。DescribeKey には EncryptionContext パラメータが無いため、他の2つとは別ステートメントに分けて許可します。

暗号化・復号のステートメントには、組織IDを縛る条件が必須です。kms:EncryptionContext:anthropic:org_uuid を自分のAnthropic組織IDに限定する StringEquals 条件で、これが無い鍵は検証で拒否されます。

組織IDは、Claude ConsoleのSettings > OrganizationのOrganization ID欄か、claude.aiのOrganization settings > Organizationからコピーします。org_ で始まるIDではなく、UUIDだけを使います。1つの鍵を複数のAnthropic組織で共有する場合は、条件の値に組織IDを並べます。

次のポリシーを key-policy.json として保存し、<AWS_ACCOUNT_ID> と <ORGANIZATION_UUID> を置き換えます。AWSアカウントIDは aws sts get-caller-identity --query Account --output text で取れます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AccountRootAdmin",
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::<AWS_ACCOUNT_ID>:root"},
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "AllowAnthropicCMEKCrypto",
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::915198916910:role/anthropic-cmek-client-us"},
      "Action": ["kms:Encrypt", "kms:Decrypt"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:EncryptionContext:anthropic:org_uuid": ["<ORGANIZATION_UUID>"]
        }
      }
    },
    {
      "Sid": "AllowAnthropicCMEKDescribe",
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::915198916910:role/anthropic-cmek-client-us"},
      "Action": "kms:DescribeKey",
      "Resource": "*"
    }
  ]
}

鍵はこのファイルを指定して作ります。

aws kms create-key \
  --region <REGION> \
  --description "Anthropic CMEK" \
  --key-usage ENCRYPT_DECRYPT \
  --policy file://key-policy.json

出力の KeyMetadata.Arn は次の登録ステップで使うので控えておきます。

鍵の使い道をワークスペース単位に絞る

組織IDの条件に加えて、特定のワークスペースだけに鍵を使わせることもできます。暗号化・復号のステートメントに StringEqualsIfExists で kms:EncryptionContext:anthropic:compartment_uuid を足し、ワークスペースごとのコンパートメントIDを並べます。

検証では、Anthropicが対象ワークスペースのコンパートメントIDを送ります。この条件を足すと、鍵の使用範囲をIAM層でも縛れます。

コンパートメントIDはワークスペースを作った後でないと分かりません。新しいワークスペースは鍵なしで先に作り、そのIDを条件に足してから鍵を紐づけます。IDはClaude ConsoleのManage > Securityで、サイドバー上部のワークスペース切り替えから対象を選び、Encryption key内のCompartment ID欄で見られます。Get Workspace APIが返す compartment_id からも取れます。

すでにCMEKとして使っていて既存データを守っている鍵には、もう1つ要件があります。kms:Decrypt だけを許可する追加ステートメントを足し、その鍵が紐づいている、または過去に紐づいていた全ワークスペースのコンパートメントIDを条件に並べます。これが無いと、既存データを復号できなくなります。

AWSコンソールで作るときの落とし穴

コンソールから作る場合は、対称鍵・暗号化と復号・シングルリージョン鍵・KMSキーマテリアルを選びます。Create-keyウィザードはReviewステップでキーポリシーを確定するため、ここが罠になります。

「AWSアカウント915198916910」を鍵使用権限に追加すると、kms:ReEncrypt* や kms:GenerateDataKey* まで含む広い権限が、EncryptionContext 条件なしでAnthropicアカウント全体に付与されます。このポリシーは検証で拒否されますが、鍵そのものは過剰な権限を持ったまま残ります。

ウィザードは管理者権限だけで完了させ、使用権限は空のままにします。鍵ができたらKey policyタブを開き、JSONを上の key-policy.json に置き換えます。

CloudTrailに出るアクセス拒否は異常ではない

Anthropicは、鍵の検証時とワークスペースへの紐づけ時に鍵を検証します。1回の検証でCloudTrailにはアクセス拒否のエラーが4件記録されますが、想定された動作です。

ノイズを除外したいときは、次の3つの値をすべて条件にします。1つ目だけでは、誰でも同じ値を設定できるため絞り込みになりません。

• requestParameters.encryptionContext.associatedData が Y21lay12YWxpZGF0aW9u
• userIdentity.accountId が 915198916910
• resources.ARN が arn:aws:kms:<REGION>:<AWS_ACCOUNT_ID>:key/<KEY_ID>

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

鍵を登録する手順は、使っている製品によって変わります。Claude Platformでは、Claude ConsoleでもAdmin APIでも同じ結果になります。

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": "aws",
      "kms_arn": "<key-arn-from-create-key-step>"
    }
  }'

レスポンスに含まれる 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} が返れば成功です。紐づけは、ワークスペースの更新APIに 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>"}'

どちらの経路でも、鍵は新しいワークスペースにリクエストを送る前に紐づけます。既にリクエストを受けているワークスペースに後付けすると、鍵が反映されるまで最大1日かかります。その間に書かれたデータはAnthropic管理の鍵で暗号化されます。

Claude Enterpriseでは操作がまったく違います。claude.ai > Organization settings > Data and privacyのEncryption keysからAdd keyを選び、AWSを選択して前段で控えたKey ARNを貼り付けるだけです。

この画面には「Organization ID for the key policy」が表示され、コピーボタンも付いています。鍵を作る前に画面を開いてIDをコピーしておけば、キーポリシーの <ORGANIZATION_UUID> を先に埋められます。

Anthropicが暗号化・復号のラウンドトリップで検証し、verifiedと表示された時点から組織全体がCMEKで保護されます。Claude Enterpriseでは組織単位の設定のためワークスペース単位の紐づけ操作は無く、組織が持てる鍵も1つだけです。

Claude Platform on AWSでは何が変わるか

AWS上で動くClaude Platform on AWSを使っている場合、CMEKの設定はここまでの手順と別物になります。権限を渡す相手からしてIAMロールではなくAWSサービスプリンシパルです。

Claude Platform on AWSの鍵ポリシーも、ルート管理者・暗号化と復号・DescribeKeyの3ステートメントです。暗号化と復号の側に付ける任意の条件が、kms:EncryptionContext:anthropic:compartment_uuid にワークスペースのコンパートメントIDを並べる形です。この場合も、ワークスペースを先に作ってIDを控え、条件に加えてから鍵を紐づけます。

別の絞り方として、aws:SourceArn 条件があります。サービスは呼び出しのたびに、ワークスペースのARN(arn:aws:aws-external-anthropic:<region>:<account-id>:workspace/<workspace-id>)をソースARNとして渡します。ArnLike で workspace/* を自分のアカウントに限れば、他アカウントのワークスペースを締め出せます。

Consoleにサインインするプリンシパルにも、AWS側の権限が要ります。aws-external-anthropic:AssumeConsole に加え、鍵の登録は RegisterKey、紐づけは UpdateWorkspace か CreateWorkspace です。これらはアカウント単位の権限なので、Resource は * で付与します。ワークスペースのARNだけに限定したポリシーには含まれません。

紐づけるプリンシパルには、鍵に対する kms:DescribeKey kms:Encrypt kms:Decrypt も要ります。Consoleの鍵ピッカーに鍵を一覧表示させたいときは、さらに kms:ListKeys を付けます。付けない場合はARNを手入力します。

紐づけに失敗したときは、次の順に見ます。

• キーポリシーがサービスプリンシパルを名指しし、kms:Encrypt kms:Decrypt kms:GenerateDataKey を許可しているか。kms:DescribeKey は EncryptionContext 条件のない別ステートメントにあるか
• EncryptionContext 条件にこのワークスペースのコンパートメントIDが入っているか。aws:SourceArn 条件を付けた場合は、このワークスペースのARNに一致するか
• 鍵が有効で、シングルリージョンで、ワークスペースと同じアカウント・同じリージョンにあるか
• AWS Organizationsのサービスコントロールポリシーやリソースコントロールポリシーが、鍵の使用を止めていないか
• それでも直らなければ、鍵のアカウントのCloudTrailで拒否された kms: イベントを探し、呼び出し元と暗号化コンテキストを見て、kms:PutKeyPolicy で条件を直して再試行する

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

公式ガイドにTerraformのサンプルコードはなく、書かれているのは「同じ手順は aws プロバイダーの aws_kms_key と aws_kms_alias リソースにマッピングできる」という一文だけです。key-policy.json をそのまま policy に渡す形が、いちばん手戻りの少ない対応づけです。

resource "aws_kms_key" "anthropic_cmek" {
  description = "Anthropic CMEK"
  key_usage   = "ENCRYPT_DECRYPT"
  policy      = file("${path.module}/key-policy.json")
}
 
resource "aws_kms_alias" "anthropic_cmek" {
  name          = "alias/anthropic-cmek"
  target_key_id = aws_kms_key.anthropic_cmek.key_id
}

JSONに <AWS_ACCOUNT_ID> や <ORGANIZATION_UUID> を残したままでは通らないので、templatefile() で値を埋めるか、jsonencode() でHCL内に書き直します。

外部鍵の登録・検証・ワークスペースへの紐づけはAWS側のリソースではなく、AnthropicのAdmin APIまたはConsoleの操作です。そのため、Terraformで管理するのは鍵とキーポリシーまでに置き、ARNを控えて以降はAPIかConsoleで進める分担が現実的です。

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

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

CMEKは有効化した瞬間に完了ではなく、その後の運用にも制約を持ち込みます。鍵をワークスペースに紐づけた後は、その鍵を外したり別の鍵に差し替えたりはできません。別の鍵に切り替えたい場合は新しいワークスペースを作って移行する必要があります。

Claude Platformでは、鍵の紐づけと同時にそのワークスペースの30日データ保持設定もロックされます。紐づけ後にZero data retentionへ戻すことはできず、戻したい場合は新しいワークスペースを作り直すしかありません。

一方、AWS KMSの自動ローテーションのように同じ鍵の中で鍵材料だけを更新する操作は、Anthropic側に何も変更せず透過的に使えます。

鍵を取り消す(revoke)操作は、反映まで最大1時間のキャッシュTTLがかかります。取り消しの直前に飛んでいたリクエストは、その間そのまま成功し続けることがあります。

取り消し後も、法的保持、差し迫った危害、利用規約違反の3つの限られたケースでは、Anthropicが特定の記録をAnthropic管理の暗号化のまま保存することがあります。鍵を失効させれば全データが復元不能になる、とは言い切れません。

導入前に決めておきたいのは、鍵でどこまで守れるかです。Claude Platformの場合は次のように分かれます。

機能面にも影響が出ます。Claude PlatformではConsoleのPlaygroundが無効になり、プロンプトやレスポンスなど生の内容を返すCompliance APIの一部も使えません。Claude FableとClaude Mythosのモデルでは、CMEK組織で構造化出力を使えません。

Claude Enterpriseでは、チャット検索とプロジェクトナレッジの検索が無効になります。Claude Code on the webとClaude in Slackは新規セッションを始められず、組織データとログのエクスポートも無効です。Claude Design、Claude Slides、routinesもCMEK組織では使えません。Artifactsは組織内でしか共有できず、公開共有はできません。Claudeの応答への評価(高評価・低評価)も無効です。

鍵の操作はクラウド側の監査ログに残ります。Anthropicはデータキーのラップ・アンラップを標準のパブリックIPレンジから行うため、IPで鍵へのアクセスを制限している場合は、公開されているIPアドレス一覧を許可します。Claude Platform on AWSではIP制限に頼らず、キーポリシーで絞ります。

Claude Codeをゲートウェイ経由(独自の ANTHROPIC_BASE_URL)で使っている場合は、CMEKはClaude Codeの運用テレメトリには適用されません。このテレメトリを止めたい場合は DISABLE_TELEMETRY 環境変数を 1 に設定します。

まとめ

CMEKは取り消せない設定で、データの扱いも製品ごとに変わります。鍵を作る前に、組織IDの条件を含むキーポリシーと、自分が使う製品(Claude Platform・Claude Enterprise・Claude Platform on AWS)の経路を決めておくと、やり直しを避けられます。

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