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

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

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

始める前に次を確認します。

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

CMEKの有効化は取り消せません。鍵を削除・無効化すると、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つとは別ステートメントに分けて許可します。

export YOUR_ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
 
aws kms create-key \
  --region <region> \
  --description "Anthropic CMEK" \
  --key-usage ENCRYPT_DECRYPT \
  --policy "{
    \"Version\": \"2012-10-17\",
    \"Statement\": [
      {
        \"Sid\": \"AccountRootAdmin\",
        \"Effect\": \"Allow\",
        \"Principal\": {\"AWS\": \"arn:aws:iam::${YOUR_ACCOUNT}: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\": \"*\"
      },
      {
        \"Sid\": \"AllowAnthropicCMEKDescribe\",
        \"Effect\": \"Allow\",
        \"Principal\": {\"AWS\": \"arn:aws:iam::915198916910:role/anthropic-cmek-client-us\"},
        \"Action\": \"kms:DescribeKey\",
        \"Resource\": \"*\"
      }
    ]
  }"

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

EncryptionContext 条件(kms:EncryptionContext:anthropic:compartment_uuid を特定のコンパートメントIDに絞る条件)は推奨ですが必須ではありません。Anthropicは常にワークスペースのコンパートメントIDを暗号化コンテキストに含めるため、条件を付けなくても暗号文はそのコンパートメントに紐づきます。条件を足すのはIAM層での多層防御です。コンパートメントIDはClaude ConsoleのWorkspace > Securityで確認できます。

AWSコンソールから作る場合は要注意です。Create-keyウィザードのReviewステップで「AWSアカウント915198916910」を鍵使用権限に追加すると、kms:ReEncrypt* や kms:GenerateDataKey* まで含む過剰な権限がAnthropicアカウント全体に付与され、しかも検証は通ってしまいます。ウィザードは管理者権限だけで完了させ、後からKey policyタブでロール限定のJSONに置き換えます。

作成した鍵を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": "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"

{"status": "success", "error": null} が返れば成功です。検証に成功したら、新しいワークスペースを作る前に鍵を紐づけます。既にリクエストを受けているワークスペースに後付けする場合、鍵が反映されるまで最大1日かかります。

Claude Enterpriseでは操作がまったく違います。claude.ai > Organization settings > Data and privacyのEncryption keysからAdd keyを選び、AWSを選択して前段で控えたKey ARNを貼り付けるだけです。Anthropicが暗号化・復号のラウンドトリップで検証し、verifiedと表示された時点から組織全体がCMEKで保護されます。Claude Enterpriseでは組織単位の設定のためワークスペース単位の紐づけ操作は無く、組織が持てる鍵も1つだけです。

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

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

Claude Platform on AWSの鍵ポリシーは、aws:SourceArn 条件でどのワークスペースからの呼び出しかを絞れる点も独自です。ワークスペースを先に作ってコンパートメントIDを控え、それをキーポリシーの条件に加えてから鍵を紐づける、という順序になります。紐づけに失敗した場合はCloudTrailで拒否された kms: イベントを探し、呼び出し元プリンシパルと暗号化コンテキストを確認するのが定石です。

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

公式ドキュメントはTerraform用のサンプルコードまでは示していません。書かれているのは「同じ手順は aws プロバイダーの aws_kms_key と aws_kms_alias リソースにマッピングできる」という一文だけです。

つまり、ここまでの手順を構成管理に落とし込むなら、鍵の作成とキーポリシーの適用は aws_kms_key リソースの policy 属性に、エイリアスは aws_kms_alias リソースに対応させることになります。鍵ポリシーのJSON自体は前段で示した3ステートメント構成をそのまま jsonencode() などで渡す形が自然です。ただし外部鍵の登録・検証・ワークスペースへの紐づけはAWS側のリソースではなくAnthropicのAdmin API呼び出しなので、Terraformで完結させたい場合は null_resource や外部プロバイダーでcurl相当の処理を挟む設計が必要になります。公式にない実装の細部を断定で書くのは避け、まずは鍵側だけをTerraform管理に置き、登録以降はAdmin API呼び出しに留めるのが手堅い進め方です。

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

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

CMEKは有効化した瞬間に完了ではなく、その後の運用にも制約を持ち込みます。鍵をワークスペースに紐づけた後は、その鍵を外したり別の鍵に差し替えたりはできません。別の鍵に切り替えたい場合は新しいワークスペースを作って移行する必要があります。さらにClaude Platformでは、鍵の紐づけと同時にそのワークスペースの30日データ保持設定もロックされます。紐づけ後にZero data retentionへ戻すことはできず、戻したい場合は新しいワークスペースを作り直すしかありません。またAWS KMSの自動ローテーションのように同じ鍵の中で鍵材料だけを更新する操作は透過的にサポートされますが、Anthropic側に何かを変更する必要はありません。

鍵を取り消す(revoke)操作も、反映まで最大1時間のキャッシュTTLがかかります。取り消しの直前に飛んでいたリクエストは、その間そのまま成功し続けることがあります。Claude Codeをゲートウェイ経由(独自の ANTHROPIC_BASE_URL)で使っている場合は、CMEKはClaude Codeの運用テレメトリには適用されません。このテレメトリを止めたい場合は DISABLE_TELEMETRY 環境変数を 1 に設定します。

まとめ

AWS KMSでのCMEK設定は、①クロスアカウントのキーポリシーを持つ鍵を作る、②Claude PlatformならAdmin APIで登録して検証する(Claude EnterpriseならClaude Console)、③ワークスペースに紐づける、という3段階です。AWSコンソールのウィザードでアカウントIDを鍵使用権限に直接入れると過剰な権限になる点と、Claude Platform on AWSでは権限を渡す相手も検証タイミングも別物になる点は、設定前に必ず押さえておく価値があります。TerraformはAWS側のリソースをコード化できますが、Anthropicへの登録・検証はAdmin API呼び出しとして別途扱う設計になります。

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