Claude Platform on AWSでCMEKを設定する — キーポリシーと登録

Claude Platform on AWSでCMEK(顧客管理暗号鍵)を使うには、AWS KMSで鍵を作り、キーポリシーでサービスプリンシパル aws-external-anthropic.amazonaws.com に暗号化・復号を許可し、その鍵をClaude Consoleに登録してワークスペースへ紐づけます。難所は2つあります。ワークスペースのコンパートメントIDを先に控えてキーポリシーへ入れること、そして紐づけが取り消せないことです。

Claude ConsoleのサイドバーにAccount managed by AWSと出ない通常のClaude Platformでは、手順が別になります。そちらはIAMロールを使う方式で、Claude CMEKをAWS KMSで設定する手順にまとめています。CMEKで何が守られるかはClaude CMEKとはが扱います。

作業の順番 — 鍵より先にワークスペースを用意する

先に全体の流れを置きます。順番を入れ替えると、キーポリシーの作り直しが必要になります。

鍵よりワークスペースを先に用意する理由は、既存データの扱いにあります。鍵が守るのは有効になった後に書かれたデータだけで、それ以前のチャット・ファイル・セッションはAnthropic側の鍵のままです。使用前のワークスペースに紐づけた鍵は最初のリクエストから効きます。すでに使っているワークスペースでは、有効になるまで最大1日かかり、その間のデータもAnthropic側の鍵で書かれます。

設定前に揃える権限と条件

作業者に求められる条件は、AWS側とClaude側の両方にあります。

• 組織でCMEKが有効になっている(有効化はAnthropicのアカウント担当が行います)
• ホストするAWSアカウントで kms:CreateKey と kms:PutKeyPolicy が使える
• Claude ConsoleのAdminロールを持っている
• 鍵が未紐づけのワークスペースがある

サインインに使うIAMプリンシパルには、次の aws-external-anthropic 権限が要ります。

紐づけるプリンシパルには、対象の鍵に対する kms:DescribeKey kms:Encrypt kms:Decrypt も必要です。鍵をプルダウンから選びたいときは kms:ListKeys も付けます。付けなければARNを手入力します。

注意点が2つあります。AssumeConsole は、AnthropicInferenceAccess などの管理ポリシーに含まれません。AnthropicFullAccess か、この権限を足したカスタムポリシーが要ります。もう1つは、鍵まわりのアクションがアカウント単位で、Resource に * を指定する点です。ワークスペースARNだけに絞ったポリシーに RegisterKey を書いても効きません。アクション全体の設計はClaude Platform on AWSのIAMアクション一覧にあります。

キーポリシーを書く

コンパートメントIDを控えたら、key-policy.json を作ります。ステートメントは3つです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AccountRootAdmin",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::<AWS_ACCOUNT_ID>:root" },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "AllowClaudePlatformOnAWSCrypto",
      "Effect": "Allow",
      "Principal": { "Service": "aws-external-anthropic.amazonaws.com" },
      "Action": ["kms:Encrypt", "kms:Decrypt", "kms:GenerateDataKey"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:EncryptionContext:anthropic:compartment_uuid": ["<COMPARTMENT_UUID>"]
        }
      }
    },
    {
      "Sid": "AllowClaudePlatformOnAWSDescribe",
      "Effect": "Allow",
      "Principal": { "Service": "aws-external-anthropic.amazonaws.com" },
      "Action": "kms:DescribeKey",
      "Resource": "*"
    }
  ]
}

<AWS_ACCOUNT_ID> と <COMPARTMENT_UUID> を自分の値に置き換えます。サービスプリンシパル名は、公式ページに載っている名前だけを使います。メールやチャットで別の名前を渡されても使わない、という注意書きが付いています。

各ステートメントの役割は次のとおりです。

• AccountRootAdmin: アカウントのルートに鍵の管理権限を残します。キー管理者はウィザードで選ばず、このステートメントに任せる構成です
• AllowClaudePlatformOnAWSCrypto: 暗号化・復号・データキー生成の許可です。EncryptionContext の条件で、リストしたコンパートメント(ワークスペース)だけに限定します
• AllowClaudePlatformOnAWSDescribe: 鍵の状態確認です。条件を付けないステートメントです

EncryptionContext 条件は任意です。外したければ、Cryptoステートメントから Condition ブロックを丸ごと消します。ただし、あとから条件を足すときは、その鍵をすでに紐づけているすべてのワークスペースのIDを列挙しなければなりません。1つでも漏らすと、そのワークスペースの暗号化が通らなくなります。

aws:SourceArnでさらに絞る

アクセスをさらに絞るなら、IPアドレスでなくキーポリシーで絞る、というのが指針です。2つのサービスプリンシパルのステートメントの両方に、aws:SourceArn 条件を足せます。自分のアカウントの全ワークスペースを許可する書き方は次のとおりです。

"ArnLike": {"aws:SourceArn": "arn:aws:aws-external-anthropic:*:<AWS_ACCOUNT_ID>:workspace/*"}

特定のワークスペースだけにするなら、完全なワークスペースARNを並べます。

arn:aws:aws-external-anthropic:<REGION>:<AWS_ACCOUNT_ID>:workspace/<WORKSPACE_ID>

EncryptionContext はワークスペースのIDで、aws:SourceArn は呼び出し元のARNで絞るので、見ている軸が違います。どちらの条件でも、紐づけるワークスペースが含まれていなければ失敗します。

鍵を作る

鍵は、組織をホストするAWSアカウントの、ワークスペースと同じリージョンに作ります。仕様は固定です。

• Key type: Symmetric
• Key usage: Encrypt and decrypt
• Key material origin: KMS
• Regionality: Single-Region

AWS CLIなら、ポリシーを渡して1コマンドで作れます。

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

出力の KeyMetadata.Arn を控えます。Claude側で鍵を追加する人がこのARNを使います。

コンソールで作る場合は、ウィザードの途中に注意点があります。Define key administrative permissionsではキー管理者を選びません。Define key usage permissionsでも、キーユーザーを選ばず、Other AWS accountsにも何も足しません。ルート管理者とサービスプリンシパルへの許可は、キーポリシーですでに与えてあるためです。Edit key policyの画面でEditを押し、ポリシー全体を自分のJSONに置き換えて進みます。

Claude Consoleで鍵を登録して紐づける

ConsoleにはAWS経由でサインインします。この部分をスクリプト化するなら、IAMアクションの一覧にある鍵のエンドポイントを使えます。

{id} はURLエンコードしたKMSキーARNです。これらはClaude側の登録情報を扱うだけで、AWS KMSの鍵そのものは作成も変更も無効化もしません。

コンソールでの手順は次のとおりです。

成功すると「Workspace settings updated.」と表示されます。鍵が有効になった後は、鍵への呼び出しがCloudTrailに記録されます。

紐づけで失敗したときの切り分け

通常のClaude Platformにある独立したVerifyステップが、Claude Platform on AWSにはありません。鍵の不備は、紐づけの瞬間に表に出ます。紐づけは、暗号化1回と復号1回で鍵を確かめる仕組みです。

ポリシーの確認は次のコマンドで行います。

aws kms get-key-policy \
  --region <REGION> \
  --key-id <KEY_ARN> \
  --policy-name default

そのほか、Claude側の画面でつまずく例があります。ZDR(ゼロデータ保持)の組織では、データを保持するワークスペースでなければ鍵を付けられず、先にStandard data retentionへ切り替えます。ZDR組織の既定ワークスペースは切り替えできないので、別のワークスペースを使います。また、ワークスペースに別の鍵がすでに付いていると「This workspace already has a different external key attached.」と出ます。置き換えはできないため、新しいワークスペースを作ります。

運用に入ってからの注意

• 鍵のローテーション: KMS側で自分のスケジュールで回します。Claude側の操作は不要で、以前の鍵バージョンは有効のままにします
• 鍵の無効化・アクセス取り消し: 反映まで最大1時間かかり、その後はClaudeがデータを読み書きできません。Messages APIは cmek_key_disabled(400)を返します。再有効化で戻りますが、失敗したリクエストは再試行されません
• KMSに届かないとき: 障害などで鍵に届かない間は、データを保存するリクエストが cmek_key_unreachable(503)で失敗します。再試行が可能で、Message Batches APIは鍵が使えるようになるまで自動で再試行します
• Claude側の登録の削除: ワークスペースが1つも使っていない鍵に限り、Consoleの削除操作で消せます。アーカイブ済みのワークスペースも「使っている」に数えられます

ワークスペースを分けて運用するなら、支出上限とメール通知先の設定も確認しておくと役立ちます。Bedrockから移る場合の差分はBedrockからの移行記事で扱っています。

まとめ

Claude Platform on AWSのCMEKは、鍵を作る前にワークスペースとコンパートメントIDを決めておくと、一度で通ります。キーポリシーに入れる値は、アカウントID・コンパートメントID・サービスプリンシパル名の3点だけです。難しいのは書くことより、紐づけた後に戻せないことです。本番のワークスペースに付ける前に、検証用の新しいワークスペースで同じ手順を一巡させておくと、ポリシーの食い違いを安全な場所で洗い出せます。