Claude Media
Claude CMEKのエラーと検証失敗の原因 — cmek_key_disabledの切り分け

Claude CMEKのエラーと検証失敗の原因 — cmek_key_disabledの切り分け

cmek_key_disabled・network_blocked・unreachableの違いと、AWS KMS・Google Cloud KMS・Azure Key Vaultで検証が通らない原因を症状別にたどります。

まず症状を2つに分ける

CMEK(顧客管理暗号鍵)まわりの不具合は、鍵を登録する段階で止まるか、登録後にリクエストが失敗するかの2通りに分かれます。切り分けの起点はここです。

Claude ConsoleのVerify、claude.aiのAdd、Admin APIのvalidate呼び出しは、どれも同じ検証を走らせます。失敗すると、Claude ConsoleではConnection failedと表示されます。原因はKMSの種類ごとに違うので、AWS KMS・Google Cloud KMS・Azure Key Vaultの順に見ていきます。

登録後の失敗は、エラーコードが手がかりになります。cmek_key_disabled、cmek_key_network_blocked、cmek_key_unreachable の3つです。

一方、CMEKを有効にすると止まる機能があります。機能が急に使えなくなった場合は、エラーではなく仕様の可能性があるため、CMEKの機能制限一覧を先に確かめてください。

切り分け

症状と最初に見る場所

  • 登録・検証で失敗する

    KMSごとの原因表へ進みます。AWS KMSはキーポリシーの条件、Google Cloud KMSはラベルと組織ポリシー、Azure Key Vaultはタグとネットワーク規則が主な疑いどころです。

  • 登録後にリクエストが400で失敗する

    cmek_key_disabled か cmek_key_network_blocked です。鍵の状態、Anthropicへのアクセス権、IP制限の順に確認します。

  • 登録後にリクエストが503で失敗する

    cmek_key_unreachable です。鍵に到達できていない状態で、再試行が前提のエラーです。

登録後にリクエストが失敗するとき

cmek_key_disabledは「KMSが拒否した」エラー

メッセージは「Customer-managed encryption key is disabled or revoked. Re-enable the key to restore access.」で、ステータスは400です。名前にdisabledとありますが、鍵が無効化されているケースだけを指すわけではありません。KMSがAnthropicの呼び出しを拒否した状態全般が、このコードで返ります。

確認する順番は次のとおりです。

  1. 鍵そのものが無効になっていないか
  2. Anthropicのアクセス権が外されていないか。必要な権限は、Claude Consoleの設定ページに表示されます
  3. AWS KMSの場合、キーポリシーに列挙したワークスペースに、失敗しているワークスペースが入っているか
  4. AWS KMSの場合、IP条件がAnthropicの送信元IPアドレスを締め出していないか

3つ目は見落としやすい原因です。ワークスペースを足すたびに、キーポリシーの compartment_uuid 条件へその分の識別子を足す必要があります。追加を忘れると、そのワークスペースのリクエストが拒否される原因になります。ワークスペース単位の書き方はAWS KMSでの設定手順にまとめています。

4つ目のIP条件は、Anthropicが公表している送信元IPの範囲を許可していれば解消します。一覧と登録の考え方は固定IP一覧と許可登録の手順にあります。

落とし穴

無効化は反映までに最大1時間かかる

鍵を無効にする、またはAnthropicのアクセス権を外すと、変更が効くまでに最大1時間かかり、その間に処理中だったリクエストは成功することがあります。「無効にした直後は動いていたのに、しばらくして400になった」という動きは、この遅延で説明がつきます。

原因を直してアクセスが戻ると、鍵が保護しているデータへ再び届きます。ただし戻らないものが2つあります。

  • 鍵が無効だった間に失敗したリクエストは、自動では再試行されません
  • 鍵を無効にしても、保持期間のカウントは止まりません

つまり、止まっていた時間の分だけ、保持期間は進んでいます。失敗したリクエストは、呼び出し側で投げ直します。

cmek_key_network_blockedは鍵が無事でも起きる

こちらも400で、メッセージにはKMSのネットワークアクセス制御(KMSのファイアウォールやIP許可リストなど)に阻まれたと書かれています。鍵自体は正常でも発生します。対処は、Anthropicが公表しているIPアドレスをKMS側のネットワーク規則で許可することです。

cmek_key_disabled の4つ目の原因(AWS KMSのIP条件)と近く、見分けにくい組み合わせです。コードが network_blocked ならまず経路を、disabled ならまず鍵とポリシーを疑う、という順で切り分けると無駄が出ません。

cmek_key_unreachableは再試行する

ステータスは503です。Anthropicが鍵に届かなかったことを示し、KMS側の障害時などに出ます。Messages APIなら、時間を置いてリクエストを再送します。Message Batches APIは、鍵が使えるようになるかバッチが期限切れになるまで、Anthropic側で再試行します。

鍵を保管するリクエストが対象なので、Claude Enterpriseではチャットや音声モードのメッセージも失敗します。再試行しても続く場合は、KMS側で鍵が利用可能かを確認し、それでも直らなければAnthropicへ連絡する流れです。

切り分け

登録後の失敗を切り分ける

  1. Qステータスは503ですか?
    答えが400なら次へ

    cmek_key_unreachable です。しばらくして再送し、続くならKMSの稼働状況を確認します。

    答えがはい
  2. Qコードは cmek_key_network_blocked ですか?
    答えがcmek_key_disabledなら次へ

    KMSのネットワーク規則に、Anthropicの公表IPを許可します。

    答えがはい
  3. Q鍵は有効で、Anthropicのアクセス権も残っていますか?
    答えがどちらかが外れています

    有効化とアクセス権の復元が先です。

    答えがはい

AWS KMSならポリシーとIP条件を確認

失敗するワークスペースが compartment_uuid に入っているか、IP条件が送信元を弾いていないかを見ます。

検証が通らない原因はKMSごとに違う

AWS KMS

原因は3つに絞れます。

原因直し方
組織IDの誤り直し方org_uuid 条件に、Anthropicの組織IDから org_ を除いたUUIDを入れる
ワークスペースの未記載直し方compartment_uuid 条件に、鍵を紐づける全ワークスペースの識別子を並べる
IAMでアクセスを渡している直し方AnthropicのロールへのアクセスをIAMではなくキーポリシー本体に書く

現状のキーポリシーは、次のコマンドで取り出して確認します。

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

出力の中で、org_uuid と compartment_uuid の値が、Consoleに表示される値と一致しているかを見比べてください。

すでにデータを保護している鍵のポリシーを差し替える場合は、既存データを復号するための文を足す必要があります。条件には、その鍵が現在つながっている、または過去につながっていた全ワークスペースの識別子を入れます。次は、その文の形です(<COMPARTMENT_UUID> は置き換えます)。

{
  "Sid": "AllowAnthropicCMEKDecryptExistingData",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::915198916910:role/anthropic-cmek-client-us"
  },
  "Action": "kms:Decrypt",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:EncryptionContext:anthropic:compartment_uuid": ["<COMPARTMENT_UUID>"]
    }
  }
}

条件に入れるのは、現在と過去のすべてのワークスペースです。

Google Cloud KMS

原因直し方
組織ラベルの誤り直し方鍵に組織ラベルを付け、値はAnthropicの組織IDを小文字にしたものにする
ドメイン制限共有直し方この組織ポリシーがAnthropicのサービスアカウントへの付与を阻むため、例外を追加する
鍵バージョンの無効化・破棄直し方プライマリバージョンを有効にする

付与の状態は、gcloud kms keys get-iam-policy で確認できます。鍵名・プロジェクト・ロケーション・キーリングを指定します。

gcloud kms keys get-iam-policy <your-key-name> \
  --project=<your-project-id> \
  --location=<region> \
  --keyring=<your-keyring-name>

ドメイン制限共有の組織ポリシーが有効だと、Anthropicのサービスアカウントへの付与が阻まれます。例外を足さない限り、検証は通りません。設定手順はGoogle Cloud KMSでの設定を参照してください。

Azure Key Vault

原因直し方
組織タグの誤り直し方鍵の現行バージョンに組織タグを付ける
ロール割り当てが未反映直し方新しい割り当ては反映まで数分かかるため、待って再実行する
Vaultのネットワーク規則直し方Anthropicが必要とするVault設定に照らして規則を見直す

タグは「鍵」ではなく「鍵の現行バージョン」に付ける点に注意が要ります。ロール割り当ての遅延は、設定直後に検証を押して失敗したときの典型的な原因で、焦って設定をいじり直す前に数分待つのが先です。手順はAzure Key Vaultでの設定にあります。

Claude Platform on AWSでは保存時に失敗する

Claude Platform on AWSにはVerifyの段階がありません。鍵の不備は、ワークスペースに鍵を付けて保存する時点で表面化します。

原因直し方
キーポリシーの不一致直し方get-key-policy で取り出し、セットアップページのポリシーと突き合わせる
条件の不一致直し方EncryptionContext や aws:SourceArn の条件に、このワークスペースを含める
鍵の状態・場所直し方鍵が有効で、単一リージョンで、ワークスペースと同じAWSアカウント・リージョンにあること
権限不足直し方操作中のプリンシパルに kms:DescribeKey・kms:Encrypt・kms:Decrypt を付ける

それでも通らないときは、鍵のあるアカウントのCloudTrailで、拒否された kms: イベントを探します。呼び出したプリンシパルと、暗号処理なら暗号化コンテキストが載っています。原因を直したら、もう一度Saveを押します。Claude Platform on AWS全体の位置づけはClaude Platform on AWSの解説を参照してください。

鍵を付ける操作そのものが断られるとき

検証以前に、画面や操作が断られる場合があります。

拒否

断られる操作と原因

  • CMEK keys can only be attached to workspaces ... inference data retention enabled

    ZDR(ゼロデータ保持)の組織では、鍵を付けられません。CMEKは保存データの暗号化なので、データを保存するワークスペースが前提だからです。先にそのワークスペースをStandard data retention(30日)へ切り替えます。

  • ワークスペースにEncryption keyの設定がない

    データを保持するワークスペースにしか出ない項目です。ZDR組織の既定ワークスペースは切り替えられないため、別のワークスペースを使います。

  • Encryption keysの節がない

    Claude ConsoleのData retentionページで、上部のドロップダウンからOrganizationを選びます。それでも出なければ、ロールに権限がないか、組織でCMEKが有効になっていません。有効化はAnthropicのアカウントチームが行います。

  • This workspace already has a different external key attached.

    ワークスペースの鍵は差し替えられません。別の鍵を使うなら、新しいワークスペースを作ります。

データ保持の切り替えは一方通行です。鍵を付けたあとは、そのワークスペースの保持を止められません。ZDRに戻したいときは、新しいワークスペースを作って通信を移します。切り替えの前に、この点を確かめてください。

claude.aiで鍵を追加して「The encryption key couldn’t be added.」と出た場合は、鍵の検証が失敗しています。上のKMS別の表で原因を探し、直したらAdd keyをもう一度押します。ダイアログには前回の入力が残っているので、チェックボックスを選んでContinue、Addと進めば再試行できます。

CloudTrailに出る拒否ログは異常ではない

Claude PlatformとClaude Enterpriseでは、鍵の検証、ワークスペースへの紐づけ、claude.aiでの鍵の表示のたびに、Anthropicが鍵の状態を確かめます。この確認1回ごとに、アクセス拒否のエラーが4件、CloudTrailへ記録されます。想定された動作で、障害ではありません。

監視アラートに引っかかるのを避けたい場合は、次の3つの値を全部満たすイベントだけを除外します。

  • requestParameters.encryptionContext.associatedData が Y21lay12YWxpZGF0aW9u
  • userIdentity.accountId が 915198916910
  • resources.ARN が自分の鍵のARN(arn:aws:kms:<REGION>:<AWS_ACCOUNT_ID>:key/<KEY_ID>)

1つ目の値は、Base64をデコードすると cmek-validation という文字列です。ただし、1つ目だけで除外してはいけません。この値は誰でも設定できるため、1つ目だけでは判定の根拠になりません。3つを組み合わせて、Anthropicの検証だけを選び出します。

切り分けで迷ったときの指針

エラーの出る場所とコードから考えると、確認先は決まります。

  • 登録時に失敗する: KMS別の表
  • 400で cmek_key_disabled: 鍵の状態、Anthropicのアクセス権、ワークスペースの記載漏れ、IP条件
  • 400で cmek_key_network_blocked: KMS側のネットワーク規則とAnthropicのIP
  • 503で cmek_key_unreachable: 再試行とKMSの稼働確認

表に当てはまる原因が見つからない場合は、Anthropicのアカウントチームに連絡する流れになります。連絡のときは、失敗した操作、エラーコード、CloudTrailで見つけた拒否イベントを添えると、切り分けが早く進みます。CMEKの全体像と保護される範囲はCMEKの概要にあります。

この記事を共有:XはてブLinkedIn