Claude CMEKをAzure Key Vaultで設定する手順

Azure Key VaultでCMEKを設定する前に確認すること

CMEK(customer-managed encryption key)は、ClaudeのワークスペースデータをAnthropic管理鍵ではなく自分のAzure Key Vault鍵で暗号化する仕組みです。AWSやGoogle Cloudと違い、Azure Key Vaultは対称鍵のラッピングに対応していません。鍵の種類そのものが他の2つのクラウドと異なります。

CMEKは任意で、対象の組織がオプトインする形です。有効にするにはAnthropicのアカウントチームへの連絡が要ります。設定できるのは、Claude PlatformではOrganization Admin、Claude EnterpriseではOwnerとPrimary Ownerだけです。

有効化は取り消せません。Anthropicは鍵のコピーを持たないため、鍵の削除や設定ミスはそのままデータの消失になります。

前提として次を揃えます。

• RBAC認可が有効(enableRbacAuthorization: true)かつパブリックネットワークアクセスが許可されたKey Vault。Anthropicはパブリックのデータプレーンエンドポイント経由で呼び出すため、プライベートエンドポイント構成には対応していません。
• 消去保護(purge protection)が有効(enablePurgeProtection: true)なVault。無効のままだと、ソフト削除の保持期間中に鍵が完全消去され、CMEKで保護したデータが復元不能になります。消去保護は一度有効にすると無効化できません。
• Vaultに鍵を作りRBACロールを割り当てる権限
• Entraテナントでサービスプリンシパルを作成できる権限(Application Administrator、Cloud Application Administrator、または同等のカスタムロール)
• 組織のAnthropic Admin APIキーと、認証済みの az CLI
• VaultのDiagnostic Settingsで AuditEvent ログをLog Analyticsなどへ転送する設定。Azure Key Vaultは既定でデータプレーンの監査ログ(KeyWrap・KeyUnwrap・KeyGet)を出さないため、これを設定しないとAnthropicの鍵操作が一切ログに残りません。

サービスプリンシパルを作りRSA鍵に権限を渡す

まずAnthropicのマルチテナントアプリケーションに同意し、自分のEntraテナントにサービスプリンシパルを作ります。このアプリはMicrosoft Graphの権限を一切要求せず、Key Vaultのデータプレーンアクセスのための連携先としてのみ存在します。

az ad sp create --id 8635ae1a-3e5d-44e8-a4ed-e0f614466f87

出力の id フィールドがテナント内でのサービスプリンシパルのオブジェクトIDです。「already exists」エラーになった場合は既に存在しているので、代わりに次で取得します。

az ad sp show --id 8635ae1a-3e5d-44e8-a4ed-e0f614466f87 --query id -o tsv

このステップにPortalの画面操作はなく、az CLIが手元に無ければPortal上部のCloud Shellで実行します。成功後は、Microsoft Entra ID > Enterprise applicationsで検索できます。アプリケーションの種類の既定フィルターを外し、anthropic-cmek-client-us を探すとオブジェクトIDが出ます。

次にVaultへRSA鍵を作ります。鍵は3072ビット以上のRSAで、許可する操作を wrapKey と unwrapKey に絞ります。もう1つ必須なのが組織タグです。anthropic-org-<ORGANIZATION_UUID> というタグに値 true を付けます。このタグが無いとAnthropic側で鍵を検証できません。

az keyvault key create \
  --vault-name <your-vault-name> \
  --name <your-key-name> \
  --kty RSA --size 3072 \
  --ops wrapKey unwrapKey \
  --tags anthropic-org-<ORGANIZATION_UUID>=true

<ORGANIZATION_UUID> はAnthropicの組織IDを小文字で書いたものです。org_ の接頭辞は付けず、UUID本体だけを使います。Claude ConsoleではSettings > OrganizationのOrganization ID欄に出ます。claude.aiではOrganization settings > Organizationの同名欄です。

HSM保護の鍵にしたい場合は --kty RSA-HSM を使います(Premium SKUのVaultが必要)。ソフトウェア保護のRSA鍵でも構いません。Portalで作るなら、Keys > Generate/Importで種類をRSA、サイズを3072以上にします。Permitted operationsはキーバージョンの画面で、Wrap KeyとUnwrap Key以外のチェックを外します。

既にある鍵へタグを足すときは、az keyvault key set-attributes の --tags を使います。ただしこのオプションはバージョンのタグを置き換えるので、元から付いているタグも 名前=値 の形で並べて渡します。Managed HSMの鍵なら --vault-name の代わりに --hsm-name です。1つの鍵を複数のAnthropic組織で共有するなら、組織ごとにタグを1つ足します。キーバージョンに付けられるタグは自分のものを含めて最大15個です。

権限は、Vault全体ではなく個別の鍵にスコープしたKey Vault Crypto Userロールを割り当てます。

VAULT_ID=$(az keyvault show --name <your-vault-name> --query id -o tsv)
 
az role assignment create \
  --role "Key Vault Crypto User" \
  --assignee-object-id <sp-object-id> \
  --assignee-principal-type ServicePrincipal \
  --scope "${VAULT_ID}/keys/<your-key-name>"

Key Vault Crypto User は暗号化・復号・ラップ・アンラップ・署名・検証と鍵の読み取りを許可する組み込みロールです。ただし鍵側で --ops wrapKey unwrapKey に絞っているので、実際にAnthropicが実行できるのはラップとアンラップだけになります。Portalから割り当てるなら、Vaultではなく鍵を開いてAccess control (IAM)タブから行います。

この鍵だけを保持する専用Vaultを用意する場合は、Microsoft推奨どおりVaultスコープでロールを割り当てても効果は同じです。共有Vaultの場合は鍵スコープに絞ります。

最後に設定を検証します。

az keyvault show --name <your-vault-name> \
  --query "{rbac:properties.enableRbacAuthorization, purge:properties.enablePurgeProtection, pub:properties.publicNetworkAccess, net:properties.networkAcls.defaultAction, ipRules:properties.networkAcls.ipRules, uri:properties.vaultUri, tenantId:properties.tenantId}"

rbac と purge が true、pub が "Enabled" であることを見ます。net は "Allow"、または "Deny" で ipRules にAnthropicの送信元レンジが入っている状態が条件です。purge が false か null なら、先に消去保護を有効にします。

tenantId は鍵を登録するときに使う tenant_id で、現在サインイン中のサブスクリプションのテナントとは限りません。クロステナント構成では両者が異なることがあります。

作成した鍵をAnthropicへ登録して検証する

登録の入口は製品で変わります。Claude Platformは鍵をワークスペース単位で持ち、Claude Enterpriseは組織単位で持ちます。

Claude PlatformではAdmin APIからも同じ結果になります。VaultのURI・鍵名・テナントIDを渡して外部鍵を登録します。

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": "azure",
      "vault_uri": "https://<your-vault-name>.vault.azure.net/",
      "key_name": "<your-key-name>",
      "tenant_id": "<your-tenant-id>"
    }
  }'

レスポンスの 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"

成功すれば {"type": "external_key_validation", "status": "success", "error": null} が返ります。失敗したときは error に理由が入ります。

検証を通したら、新しいワークスペースに external_key_id を渡して紐づけます。

curl -sS -X POST "https://api.anthropic.com/v1/organizations/workspaces/<workspace-id>" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"external_key_id": "ekey_<id>"}'

リクエストを送る前の新しいワークスペースに紐づけるのが推奨の順序です。既にリクエストを受けているワークスペースへの後付けは、反映まで最大1日かかります。

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

Azure Key VaultのガイドにあるTerraformの記述は、「同じ手順は azurerm と azuread プロバイダーにマッピングできる」という一文だけです。サンプルコードはありません。

たとえば一般的なTerraformの書き方では、サービスプリンシパルは azuread プロバイダー、RSA鍵は azurerm_key_vault_key、ロールの割り当ては azurerm_role_assignment で表します。あくまで一般的な対応で、ガイドが示す構成ではありません。

Anthropicへの外部鍵登録・検証・ワークスペースへの紐づけはAzureのリソースではなくAdmin API呼び出しです。Terraformで完結させたい場合も、この部分は別の手段で呼び出すことになります。

検証が失敗したときの原因と切り分け

検証が通らないときの原因は、error フィールドの内容で絞れます。

送信元IPの入手先は、公式ページ同士で書き方が違います。Azure Key Vaultのガイドは「Anthropicに現行のレンジを問い合わせる」としています。CMEKの概要ページは、Anthropicが標準のパブリックIPレンジから呼び出すとして、IP addressesのページに載るアドレスを許可するよう案内しています。

検証が通ったあとの鍵操作は、見る場所が分かれます。CMEKの設定イベントはCompliance APIのActivity Feedに出ます。ラップ・アンラップのような鍵操作はそこには出ず、Azure側の監査ログにだけ残ります。前提に挙げたDiagnostic Settingsを入れていないと、検証は通っても鍵操作の記録がどこにも残りません。

CMEKは現在USリージョンのみで、暗号化処理もUSで行われます。Azureでは、Anthropicの米国インフラに近い northcentralus か eastus2 にVault自体を置くのが推奨です。他のクラウドでは、AWSが us-east-2、Google Cloudが us-central1 か us-east5 を推奨しています。

有効化後に止まる機能と残る制約

CMEKは、鍵が効き始めたあとに書かれたデータだけを保護します。既存のチャット・ファイル・セッションはAnthropic管理鍵のままで、あとから再暗号化はされません。

制約はいくつかあります。

• 紐づけは取り消せません。鍵をワークスペースに紐づけると、外すことも別の鍵に替えることもできません。別の鍵にするには、新しいワークスペースを作ってデータを移します。同じ鍵の中での鍵素材のローテーション(Azure Key Vaultならローテーションポリシー)は、Anthropic側の変更なしに使えます。
• データ保持設定も固定されます。Claude Platformでは、紐づけたワークスペースで30日保持を切れなくなります。ゼロデータ保持に戻すには新しいワークスペースが必要です。ゼロデータ保持との併用自体は認められています。
• 鍵の無効化は取り返せません。失効や無効化は最大1時間(キャッシュのTTL)かけて効き、その間に処理中のリクエストは成功し続けることがあります。効いたあとは、そのワークスペースのCMEK保護データに永久にアクセスできません。
• レイテンシとコスト。ラップ・アンラップのたびにKey Vaultとの往復が入り、データの読み書きにわずかな遅延が加わります。Key Vaultの利用料はAzure側から別に請求されます。
• ゲートウェイ経由のClaude Code。 ANTHROPIC_BASE_URL を差し替えたゲートウェイやプロキシ経由では、Claude Codeの運用テレメトリにCMEKが及びません。止めるには環境変数 DISABLE_TELEMETRY を 1 にします。

有効にした組織では、製品側の機能も一部が使えなくなります。Claude Platformでは、ConsoleのPlaygroundが無効になり、生のプロンプト・応答・ファイルを返すCompliance APIの一部も無効です。Claude FableとClaude Mythosのモデルでは、構造化出力が使えません。

Claude Enterpriseのほうが影響は広く、次の機能が止まるか縮小します。

• チャット検索が無効になり、過去のチャットをメンバーもClaudeも検索できなくなる
• プロジェクトナレッジの検索(RAG)が無効になり、知識は会話のコンテキストへ直接読み込まれるため、扱える量が減る
• Claude Code on the webとClaude in Slackで新しいセッションを始められない
• アーティファクトの公開共有ができず、共有は組織内に限られる
• 組織データのエクスポートと監査ログのエクスポートが無効になる
• skillsとconnectorsの管理者向け分析、スマートレポート、Claude Codeのコントリビューション指標が縮小する
• 回答への評価(thumbs up / thumbs down)が無効になる
• ルーティンがリサーチプレビュー機能として使えない

Claude Managed Agentsを併用している場合、CMEKはエージェント設定やセッションデータも保護対象に含みます。ただしvault credentialの値(OAuthトークンやクライアントシークレット)はAnthropic管理鍵のままです。詳しくはManaged Agentsの設計思想にあります。

CMEKの鍵で暗号化されない対象もあります。Activity Feed・監査ログ・OTELのようなテレメトリ通信は、鍵を失効させてもコンプライアンスを維持できるよう、Anthropic管理鍵のままです。TTLが24時間未満のPlatformのデータも対象外です。

まとめ

設定の核は、組織IDのタグを付けたRSA鍵と、鍵スコープの Key Vault Crypto User です。紐づけは取り消せないので、新しいワークスペースで検証を通してから本番に回す手があります。Enterpriseは止まる機能が多いので、チャット検索やRAGに頼る運用かどうかを先に洗い出しておくと判断しやすくなります。

AWSやGoogle Cloudで同じ組織にCMEKを構成する場合は、鍵の種類も検証の失敗パターンもクラウドごとに変わります。手順はAWS KMSとGoogle Cloud KMSの記事にあります。