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はKMSのような対称鍵のラッピングに対応していないため、鍵の種類そのものが他の2つのクラウドと異なります。

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

• RBAC認可が有効(enableRbacAuthorization: true)かつパブリックネットワークアクセスが許可されたKey Vault。Anthropicはパブリックのデータプレーンエンドポイント経由で呼び出すため、プライベートエンドポイント構成には対応していません。
• 消去保護(purge protection)が有効(enablePurgeProtection: true)なVault。無効のままだと、ソフト削除の保持期間中に鍵が完全消去され、CMEKで保護したデータが復元不能になります。消去保護は一度有効にすると無効化できません。
• Vaultに鍵を作りRBACロールを割り当てる権限
• Entraテナントでサービスプリンシパルを作成できる権限(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

次にVaultへRSA鍵を作ります。Azure Key Vaultは対称鍵のラッピングに対応していないため、鍵は3072ビット以上のRSAで、許可する操作を wrapKey と unwrapKey に絞ります。

az keyvault key create \
  --vault-name <your-vault-name> \
  --name <your-key-name> \
  --kty RSA --size 3072 \
  --ops wrapKey unwrapKey

HSM保護の鍵にしたい場合は --kty RSA-HSM を使います(Premium SKUのVaultが必要)。ソフトウェア保護のRSA鍵でも構いません。

権限は、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が実行できるのはラップとアンラップだけになります。この鍵だけを保持する専用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, uri:properties.vaultUri, tenantId:properties.tenantId}"

rbac と purge が true、pub が "Enabled" であることを確認します。tenantId は鍵を登録するときに使う tenant_id で、現在サインイン中のサブスクリプションのテナントとは限らない点に注意します(クロステナント構成では両者が異なることがあります)。

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

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"

成功すれば {"status": "success", "error": null} が返ります。検証後、新しいワークスペースを作る前に鍵を紐づけます(既存ワークスペースへの後付けは反映まで最大1日)。

Claude Enterpriseでは、claude.ai > Organization settings > Data and privacyのEncryption keysからAdd keyを選び、Azureを選択してVault URI・鍵名・テナントIDを入力するだけです。検証後にverifiedと表示された時点から組織全体がCMEKで保護されます。ワークスペース単位の紐づけは無く、組織が持てる鍵も1つだけです。

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

公式ドキュメントはTerraformのサンプルコードまでは示していません。書かれているのは「同じ手順は azurerm と azuread プロバイダーにマッピングできる」という一文だけです。

構成管理に落とし込むなら、サービスプリンシパルの作成は azuread_service_principal(既存のマルチテナントアプリを参照する形)、RSA鍵の作成は azurerm_key_vault_key、Key Vault Crypto User ロールの割り当ては azurerm_role_assignment に対応させることになります。Vault自体のRBAC認可・消去保護・パブリックネットワークアクセスの設定も azurerm_key_vault のプロパティとして表現できます。ただしAnthropicへの外部鍵登録・検証・ワークスペースへの紐づけはAzure側のリソースではなくAdmin API呼び出しなので、Terraformで完結させたい場合は null_resource や外部プロバイダーで補う設計が必要です。公式に書かれていない実装の細部を断定で書くのは避け、まずはVaultと鍵側だけをTerraform管理に置くのが手堅い進め方です。

検証やアクセスでよくあるつまずき

Azure特有の注意点として、Diagnostic Settingsを設定していないと鍵操作の監査ログがそもそも残らないため、検証は通っているのに「何が起きているか分からない」状態になりがちです。設定前の段階でログ転送を有効にしておくと、後から原因を追いやすくなります。

リージョン選びも他のクラウドとは独立に考える必要があります。CMEKの暗号化処理はUSリージョンで行われるため、Vaultは northcentralus か eastus2 のように、Anthropicの米国インフラに近い場所を選ぶとレイテンシを抑えられます。すでに別リージョンでVaultを運用している場合でも、CMEK用の鍵だけをこれらのリージョンに新規作成する選択肢があります。

有効化後に効いてくる制約

CMEKはさかのぼって適用されません。鍵が実際に効き始める前に書かれたデータは、既存のチャット・ファイル・セッションと同じくAnthropic管理鍵のまま残り、あとから自分の鍵で再暗号化されることはありません。ラップ・アンラップの往復にはKey Vaultとの通信が挟まるぶん、データの読み書きにわずかなレイテンシが加わる点も見込んでおきます。

Key Vaultの利用自体にAzure側の課金が発生する点も見落としがちです。CMEKはAWS KMS・Google Cloud KMS・Azure Key Vaultのいずれを使う場合も、そのクラウドプロバイダーが個別に請求するサービスに依存する構成になります。鍵を紐づけたワークスペースは、そのあとデータ保持設定(30日保持からゼロデータ保持への変更)も固定されるため、ゼロデータ保持に戻したい場合は新しいワークスペースを作って移行する必要があります。

まとめ

Azure Key VaultでのCMEK設定は、①Anthropicのマルチテナントアプリに同意してサービスプリンシパルを作る、②3072ビット以上のRSA鍵を作り鍵スコープでKey Vault Crypto Userを割り当てる、③Admin API(Claude EnterpriseならClaude Console)で登録・検証し、ワークスペースに紐づける、という流れです。RBAC・消去保護・パブリックネットワークアクセス・Diagnostic Settingsの4点は、鍵を作る前にVault側で満たしておく必要があります。

AWS KMSやGoogle Cloud KMSで同じ組織にCMEKを構成する場合は、鍵の種類も検証の失敗パターンもクラウドごとに変わります。AWS KMSでCMEKを設定する手順とGoogle Cloud KMSでCMEKを設定する手順も合わせて確認してください。Claude Managed Agentsを併用している場合、CMEKはエージェント設定やセッションデータも保護対象に含みますが、vault credentialの値だけはAnthropic管理鍵のまま残る点はManaged Agentsの設計思想で押さえておくと運用の見通しが立ちます。