Claude CMEKの鍵を削除・無効化したら何が起きるか — 操作別の影響
Claude CMEKの鍵をローテーション・無効化・削除すると、データへの影響と反映までの時間、元に戻せるかが操作ごとに変わります。エラーコードの見分け方も載せています。
Claude CMEKの鍵は、無効化なら戻せますが、削除は戻せません。ローテーションはClaude側の操作が要りません。同じ「鍵を止める」操作でも、データへの影響と取り返しのつきやすさは大きく違います。ここでは操作を5つに分け、何が起きるか、どれくらいで反映されるか、元に戻せるかを順に見ます。
鍵そのものとClaude側の記録は別のもの
CMEK(顧客管理鍵)を使うと、鍵は自社のKMS(AWS KMS、Google Cloud KMS、Azure Key Vault)にあります。Claudeが持つのは、その鍵を指す記録だけです。鍵の削除と、記録の削除は別の操作です。
仕組みはエンベロープ暗号化です。Anthropicはデータキーでデータを暗号化し、自社の鍵がそのデータキーをラップ(暗号化)します。読み書きのたびに、AnthropicがKMSへデータキーのラップかアンラップを頼みます。鍵はKMSの外へ出ません。Anthropicは鍵のコピーを持たないので、鍵が使えなくなればClaudeは保護対象のデータを読めません。
この前提を置くと、次の早見表が読みやすくなります。
| 操作 | 何が起きるか | 元に戻せるか |
|---|---|---|
| ワークスペースに鍵を紐づける(Claude Enterpriseでは組織に追加) | 何が起きるか有効になった後に書かれたデータを鍵が守る。Claude Platformでは保持設定も固定される | 元に戻せるか戻せない。鍵の取り外しも差し替えもできない |
| 同じ鍵の中で鍵材料をローテーションする | 何が起きるかKMS側で自分のスケジュールで行う。Claude側の操作は不要 | 元に戻せるか戻す対象がない。以前の鍵バージョンは有効のままにする |
| 鍵を無効化する、またはAnthropicのアクセスを取り消す | 何が起きるか反映まで最大1時間。その後、保護対象データの読み書きが失敗する | 元に戻せるか鍵を再有効化するか、アクセスを戻せば復旧する。ただし制限が2つある |
| KMSで鍵を削除する、削除予約する、鍵材料を破棄する | 何が起きるかAnthropicはその鍵が守るデータを復元できない | 元に戻せるかAnthropicには戻せない。鍵のコピーがないため |
| Claude側の鍵の記録を削除する | 何が起きるかどのワークスペースも使っていないときだけ実行できる | 元に戻せるか戻せない |
操作が効くまでの時間
反映までの上限
最大1時間
この間に処理中のリクエストは成功することがある
反映後のエラー
400
cmek_key_disabled を返す(Messages API)
ローテーションは何もしなくてよい
KMS内で鍵材料を更新するローテーションは、Claudeの設定を触らずに済みます。AWS KMSの自動ローテーションのように、同じ鍵のまま材料だけが新しくなる操作が対象です。自社のスケジュールで回せます。
注意は1点です。以前の鍵バージョンは有効のままにしておきます。旧バージョンを無効化したときの挙動は、鍵ライフサイクルのページに個別の記載がありません。旧バージョンを止める運用は、鍵の無効化に近いリスクを抱える可能性があるため、避けたほうが安全です。
また、ローテーションで既存データが再暗号化されるかどうかも、このページには記載がありません。別の鍵に切り替えるのとは話が違い、ローテーションは「同じ鍵の更新」である点だけ押さえてください。鍵そのものを替えたい場合は、後ろの節で触れるとおり選択肢が限られます。
無効化とアクセス取り消しは、止血であって消去ではない
鍵を無効化する、またはAnthropicに与えたアクセス権を取り消すと、反映まで最大1時間かかります。この間、処理中のリクエストは成功することがあります。緊急停止のつもりで操作しても、1時間は完全には止まりません。
反映後は、Claudeが保護対象のデータを読むことも書くこともできなくなります。Messages APIでは、そのワークスペースへのリクエストが400エラーで失敗します。
Customer-managed encryption key is disabled or revoked. Re-enable the key to restore access.エラーコードは cmek_key_disabled です。メッセージのとおり、鍵を再有効化すれば戻ります。
戻したときに戻らないもの
再有効化、またはアクセスの復旧で、保護対象データへのアクセスは戻ります。ただし制限が2つあります。
- 無効化中に失敗したリクエストは、自動では再実行されません
- 無効化しても、データの保持期間のカウントは止まりません
1つ目は、呼び出し側で再送の仕組みを持つ必要があるという意味です。Messages APIのクライアントが失敗を握りつぶしていると、復旧後も欠けたままになります。2つ目は、無効化中も保持期間は進み続けるという意味です。Claude Platformで鍵を付けられるのは、30日の標準データ保持を使うワークスペースだけです。無効化の期間を、保持期間の延長として数えることはできません。
400でも原因は4つに分かれる
cmek_key_disabled の400は、KMSがAnthropicの呼び出しを拒否したことを表します。トラブルシューティングのページは、次の順で原因を確かめるよう案内しています。
- 鍵が無効化されている
- Anthropicのアクセスが取り除かれている
- AWS KMSで、キーポリシーがワークスペースを列挙しているのにこのワークスペースが入っていない
- AWS KMSで、IP条件がAnthropicの送信元IPを塞いでいる
3と4は「操作した覚えがない」のに起きます。鍵を触っていないのに突然400が返るときは、1と2だけで切り上げないほうが早く片付きます。
400エラーが出たときの切り分け
- Qエラーコードは cmek_key_disabled(400)か?答えがいいえのとき答えがはい
cmek_key_unreachable(503)なら鍵に届いていません。次の節のとおり再試行します。cmek_key_network_blocked(400)なら、KMSのファイアウォールやIP許可リストがAnthropicの公開IPを塞いでいます。 - QKMSで鍵は有効な状態か?答えが無効になっている答えがはい
鍵を再有効化します。
- QAnthropicのアクセス権は残っているか?答えが外れている答えがはい
セットアップページが示すアクセス権を戻します。
- QAWS KMSのキーポリシーにこのワークスペースが載り、IP条件がAnthropicの送信元IPを塞いでいないか?答えがどちらかが違う答えがはい
ワークスペースのコンパートメントIDをポリシーに加えるか、IP条件を直します。
それでも当てはまらないとき
Anthropicのアカウントチームに連絡します。
到達できないだけのときは503になる
鍵が無効化されたわけではなく、Anthropicが鍵に届かないだけの場合もあります。たとえばKMS側の障害です。このとき、鍵のもとにデータを保存するリクエストが失敗します。Claude Enterpriseでは、チャットや音声モードのメッセージも対象です。
Messages APIでは503エラーとコード cmek_key_unreachable が返り、再試行できます。Message Batches APIは、鍵が使えるようになるかバッチが期限切れになるまで、Anthropicが再試行します。
整理すると、400の cmek_key_disabled は「鍵かアクセス権の側に変更がある」サインです。503の cmek_key_unreachable は「届かないだけ」のサインです。前者は人の手で直す必要があり、後者はまず待って再試行します。エラーの種類を分けてアラートを組むと、深夜に鍵を探しに行く手間が減ります。
削除は戻せない
KMSで鍵を削除する、削除予約する、鍵材料を破棄する。このどれかに至ると、Anthropicはその鍵が守るデータを復元できません。Anthropicは鍵のコピーを持たないからです。
ここで「削除予約」まで並んでいる点に注意が要ります。予約から実際の削除までの猶予は、各KMSの仕様です。鍵ライフサイクルのページに猶予の長さの記載はありません。猶予の間に取り消せるかどうかは、利用しているKMSのドキュメントで確かめる必要があります。
無効化と削除の差は、結局この1点に尽きます。無効化は止めても戻せます。削除は戻せません。鍵を長期間使わせたくない、というだけの目的なら、削除より無効化が筋の通った選択です。削除は、データを二度と読めなくすると決めたときの操作です。
例外として残る記録
鍵を失っても、法的保持、差し迫った危害、利用規約違反の3つの限られた場合には、Anthropicが特定の記録をAnthropic管理の暗号化のまま保存することがあります。安全性スクリーニングのメタデータも、鍵の取り消し後に読めるまま残ります。会話の中身ではなく、パターン識別子や一致の有無といった記録です。詳細はCMEKを有効化する前に確認すべき制約の記事にまとめています。
Claude側の鍵の記録は消せる条件が狭い
Claude ConsoleのDelete encryption keyで、Claude側の鍵の記録を削除できます。使われていない鍵の記録を片付ける操作です。
実行できるのは、その鍵をどのワークスペースも使っていないときだけです。アーカイブ済みのワークスペースも「使っている」に数えます。この操作は戻せません。
紐づけは取り外せないという条件と合わせると、一度ワークスペースに付けた鍵の記録は、そのワークスペースが残っている間は消せないことになります。アーカイブしても、条件は変わりません。記録の削除を目的にワークスペースを整理する場面は、まずありません。
鍵を替える、やめる
ワークスペースや組織は、別の鍵に切り替えることも、鍵なしに戻ることもできません。Claude Platformでは、別の鍵で、あるいは鍵なしで新しいワークスペースを作り、トラフィックをそちらへ移すのが唯一の手です。Claude Enterpriseには、組織の中で鍵を替える方法も、CMEKをやめる方法もありません。
この制約は、有効化前の判断に直結します。設定手順の側は、AWS KMS、Google Cloud KMS、Azure Key Vaultの各ガイドにあります。たとえばAWS KMSで設定する手順は、鍵のポリシーと検証までを扱っています。Claude側の守備範囲そのものはClaude CMEKの解説が受けています。
誰が鍵を止めたかをどう追うか
操作の記録は、2か所に分かれます。AnthropicがKMSに対して行った操作は、自社クラウドの監査ログに残ります。AWS CloudTrailでは一部のエントリが想定内のエラーとして出ます。
一方、Compliance APIのActivity Feedには、CMEKの設定変更が出ます。鍵の操作は出ません。鍵を止めた操作の記録は、Claude側のフィードではなく、自社のKMSの監査ログに残ります。
まとめ
操作を戻せるかで分けると、次のようになります。
- 戻せる: 無効化、アクセスの取り消し。反映に最大1時間かかり、復旧後も失敗したリクエストは再実行されません
- 何もしなくてよい: 同じ鍵の中でのローテーション。旧バージョンは有効のまま
- 戻せない: KMSでの削除・削除予約・鍵材料の破棄、Claude側の記録の削除、鍵の紐づけそのもの
無効化は、削除に比べれば穏やかな操作です。それでも1時間の遅れと、失敗リクエストの未再送という2つの癖があります。障害対応の手順書には、400と503の見分け方と、再送の仕組みを先に書いておくと運用が安定します。