AnthropicがCMEK保存イベントを明確化、顧客鍵の外へ再暗号化される例外をどう監査するか

AnthropicはClaude PlatformのAccess Transparency資料を更新し、CMEK利用組織でコンテンツが通常の保持期間を超えて保存される場合の記録方法を明確化した。

重大なポリシー違反や安全調査などで特定コンテンツの保存が必要になった場合、Compliance APIのActivity Feedへcmek_preserveイベントが記録される。CMEK組織では、調査を顧客鍵の状態から独立して継続できるよう、保存対象コンテンツが顧客管理鍵の外へ再暗号化される場合がある。

これはCMEKの価値を否定する変更ではない。しかし、「顧客鍵を無効化すれば、すべての内容を常に復号不能にできる」という単純な理解では、実際の保持例外を説明できない。企業は暗号鍵、データ保持、透明性ログ、契約上の例外を一つの統制として扱う必要がある。

確認できた仕様

主な内容は次の通りである。

cmek_preserveは、誰かが閲覧したことだけを示すイベントではない。コンテンツの保持状態と鍵の管理境界が変わったことを示す。

Access TransparencyとCMEKは別の統制

混同しやすい三つの仕組みを分けて考える必要がある。

CMEK

顧客が管理する暗号鍵を使い、対象データの暗号化制御を強化する。鍵のローテーション、無効化、監査を自社の鍵管理ポリシーへ組み込める。

Access Transparency

Anthropic側の人間が対象コンテンツへアクセスした場合、その事実と目的をCompliance APIへ記録する。アクセスを防止する機能ではなく、アクセスを可視化する機能である。

データ保持ポリシー

通常の保存期間、Zero Data Retention、法的・安全上の保存例外を定める。暗号鍵や透明性ログだけでは、保持期間そのものを決めない。

これらを別々に導入しても、統合した説明責任は自動的には生まれない。

cmek_preserveが意味すること

CMEK環境で保存対象となったコンテンツが顧客管理鍵の外へ再暗号化されると、顧客が後から自社鍵を無効化しても、その保存コピーの調査継続を止められない可能性がある。

この動作は、通常保持される他のコンテンツまで顧客鍵の外へ移ることを意味しない。公式資料では、保存対象以外の保持データは引き続き顧客鍵の下にあると説明されている。

したがって、監査上の問いは「CMEKだから外部に残らないか」ではなく、次のようになる。

• どの条件で保存例外が発生するか
• 誰または何が保存を開始できるか
• どのデータが対象になったか
• どの理由コードが記録されたか
• いつ保存され、いつ通知されたか
• 保存期間と削除条件は何か
• 顧客への追加通知や異議申立ての経路はあるか

人間アクセスと自動処理を区別する

anthropic_accessイベントは、人間によるアクセスを記録する。モデル提供、分類器、安全検知などの自動処理は、通常このイベントを生成しない。

そのため、Activity Feedが空であることは、Anthropicの人間が内容を閲覧していないことを示す可能性はあるが、内容が自動システムで処理されていないことを示さない。

一方、cmek_preserveは自動安全パイプラインが保存を開始した場合でも記録される。これは主体の監視ではなく、保持状態の変化を監視するイベントだからである。

SIEMでは両イベントを同じ重要度で処理するべきではない。

2営業日の遅延をどう扱うか

Access Transparencyのイベントは、アクセスまたは保存から2営業日以内に配信される。したがって、リアルタイム侵害検知としては使えない。

accessed_atは実際のアクセスまたは保存時刻、created_atはフィード上で可視化された時刻を示す。監視では両方を保存し、遅延を明示する必要がある。

誤った設計は次である。

cmek_preserveを検知
  -> 直ちに保存処理を阻止する

通知時点では、既に保存状態が変更されている。正しい目的は、事後確認、契約上の通知、証跡保全、影響評価、追加照会である。

リアルタイムの流出防止は、入力前のデータ分類、送信制御、権限、DLP、利用ポリシーで実施する必要がある。

対象範囲の空白を確認する

Access TransparencyはすべてのClaude利用経路を一律に覆うわけではない。

公式資料では、Claude APIの通常リクエストやAPIキー経由のClaude Codeは対象である一方、Batch API、Files API、Claude for Enterprise、Workbench、Microsoft Foundry、Amazon Bedrock、Google Cloudなどは対象外または別の統制を参照する扱いである。

同じClaudeモデルを利用していても、契約・経路によって監査イベントの入手方法が異なる。

組織は次のマトリクスを作るべきである。

「Claudeを利用している」という製品単位ではなく、実際のAPIサーフェス単位で統制を割り当てる必要がある。

推奨する監視設計

1. Activity Feedを定期取得する

anthropic_accessとcmek_preserveを明示的に取得する。最終取得時刻だけでなく、重複排除用のイベントIDを保存する。

activity_types[]=anthropic_access
activity_types[]=cmek_preserve

2営業日の遅延とAPI障害を考慮し、過去数日を重複取得してイベントIDで冪等処理する。

2. 生データを改変せず保存する

正規化後のSIEMイベントだけでなく、受信した原文JSONを耐改ざんストレージへ保存する。後からフィールドや理由コードが追加された場合にも再解析できる。

3. イベントを業務データへ対応付ける

resource_detailsのメッセージIDだけでは、社内の案件、利用者、アプリケーションを特定できない場合がある。API呼び出し時に次を内部ログへ残す。

• AnthropicメッセージID
• 社内リクエストID
• アプリケーション
• テナント
• データ分類
• 担当部署
• 送信時刻
• モデル
• 保持設定

個人情報や本文を監査ログへ過剰に複製しないよう、識別子中心に設計する。

4. 対応レベルを定義する

cmek_preserveを検出した場合の例を示す。

重大度: High
通知先: セキュリティ、法務、DPO、サービス責任者
初動目標: 1営業日以内
確認項目:
  - reason_code
  - resource ID
  - 送信元システム
  - データ分類
  - 契約条項
  - 当局・本人通知要否

すべてを侵害と断定してはならない。公式に定義された調査目的の保存である可能性がある一方、社内データ分類や顧客契約によって追加対応が必要になる。

契約と社内説明の見直し

CMEK導入資料に「鍵を無効化すればデータは利用不能になる」とだけ記載している場合、保存例外を反映する必要がある。

確認すべき文書は次である。

• ベンダーリスク評価
• データ処理契約
• セキュリティ設計書
• 顧客向けプライバシー説明
• Zero Data Retentionの説明
• 鍵管理手順
• インシデント対応計画
• 規制当局向け統制記述

法務判断は契約内容と法域に依存する。技術資料だけで保持義務や通知義務を断定せず、実際の契約条項と照合する必要がある。

鍵無効化テストの限界

CMEKの運用テストでは、鍵を無効化し通常データへのアクセスが失敗することを確認する場合がある。この試験は有用だが、cmek_preserveの保存コピーまで削除されることを証明しない。

試験計画では次を分ける。

1. 通常データの暗号化・復号
2. 鍵ローテーション
3. 鍵無効化時のサービス挙動
4. 鍵復旧
5. 保存例外の契約・監査確認
6. Activity Feedの取得と遅延

保存例外は実データで意図的に発生させるべきではない。テスト用イベント、契約資料、ベンダー確認で統制の有効性を検証する。

よくある誤判断

CMEKなら保持例外は存在しない

CMEKは鍵管理を強化するが、安全・法的調査に伴う保存例外を自動的に排除しない。

Activity Feedが空なら何も処理されていない

人間アクセスがないことと、自動処理がないことは異なる。

cmek_preserveは人間アクセスの一種

保存状態の変更を記録するイベントであり、自動パイプラインが開始した場合にも生成される。

SIEMへ送ればリアルタイム防御になる

最大2営業日の配信遅延がある。事後監査と対応のチャネルとして設計する。

Claudeの全利用経路が対象

APIサーフェスやパートナープラットフォームによって対象範囲が異なる。

編集部分析

CMEKは企業向けAIの重要な統制だが、鍵を持つこととデータの全ライフサイクルを単独で支配することは同じではない。

クラウドサービスでは、暗号化、バックアップ、安全調査、法的保持、障害対応が複数の管理境界にまたがる。顧客管理鍵は通常運用の制御を強める一方、契約や法令に基づく例外処理まで消滅させるものではない。

今回の明確化で重要なのは、例外が存在することだけではなく、例外が顧客可視のイベントとして記録されることである。企業はこの透明性を、単なるログ保管ではなく、説明責任へ変換しなければならない。

そのためには、イベントを受け取った後に誰が判断し、どの契約と照合し、どの顧客へ説明するかまで決める必要がある。ログがあるだけでは統制にならない。

また、AI基盤の選定では「CMEK対応」のチェックボックスだけを比較するべきではない。保存例外、通知時期、対象サーフェス、理由コード、監査API、契約上の救済まで含めて評価する必要がある。

実務チェックリスト

• [ ] Access TransparencyとCMEKの役割を分けて文書化した
• [ ] anthropic_accessとcmek_preserveを両方取得している
• [ ] accessed_atとcreated_atを保存している
• [ ] 2営業日の通知遅延を監視設計へ反映した
• [ ] Activity Feed原文を耐改ざんストレージへ保存している
• [ ] AnthropicメッセージIDを社内リクエストへ対応付けられる
• [ ] policy_violation_investigationとcsae_reportの対応手順がある
• [ ] 法務、DPO、セキュリティへの連絡基準を定めた
• [ ] Batch、Files、Bedrock、Google Cloud等の対象外範囲を確認した
• [ ] CMEK鍵無効化の説明に保存例外を反映した
• [ ] Zero Data Retentionと保存例外を契約条項で確認した
• [ ] 顧客・監査人向けの説明文を更新した

一次情報

• Access Transparency
• Claude Platform release notes
• Compliance API