異なるテナント間でカスタマーマネージドキーを構成する

Note

Azure AI 検索は、Azure ポータル、REST API、およびAzure SDKから使用できます。また、Foundry IQ は、エンタープライズコンテンツを、Microsoft Foundry ポータルのエージェントの再利用可能なアクセス許可に対応したナレッジベースに変換するマネージドナレッジレイヤーです。

Important

機能、またはマークされたプロパティ (プレビュー) は、サービスレベルアグリーメントの対象ではなく、運用環境のワークロードには推奨されず、一般公開される前に変更または制約される可能性があります。 Azure AI 検索プレビューの用語は、スタンドアロンでも一般公開されている機能の一部でも、すべてのプレビュー機能に適用されます。

この記事では、サービスプロバイダーが独自のテナントでAzure AI 検索ホストし、マルチテナント Microsoft Entra アプリケーションを使用して customer マネージドキー (CMK) 暗号化を有効にするテナント間のシナリオについて説明します。

この構成では、顧客は自分のテナントのAzure Key Vaultを使用して暗号化キーを管理します。サービスプロバイダーには、このキーへのアクセス権がありません。

[前提条件]

テナント A: テナントと、Azure AI 検索サービスと関連するオブジェクト (インデックス、シノニムリスト、インデクサー、データソース、ベクターライザー、スキルセット) を作成するために必要なアクセス許可。カスタマーマネージドキー (CMK) のサポートには、Basic 価格レベル以上が必要です。
ロールベースのアクセス用に検索サービスを構成します (セキュリティ強化に推奨されます。必須ではありません)。
テナント B: Azure Key Vaultとそのテナントに必要なアクセス許可を持つ個別の顧客テナント:
- Key Vault 共同作成者: 新しいkey vaultを作成する必要がある場合は、このロールが必要です。
- アプリケーションを Microsoft Entra ID: テナント間 CMK 用にサービスプロバイダーによって構成されたマルチテナントアプリをインストールするには、Microsoft Entra IDでアプリ登録を作成するアクセス許可が必要です。これには通常、アプリケーション開発者ロール、またはアプリケーション管理者やグローバル管理者などの上位の管理ロールが必要です。
- Key Vault Crypto Officer: このロールは、key vaultに新しいキーを追加するために必要です。
- Key Vault Crypto Service Encryption User: key vaultのカスタマーマネージドキーへのアクセス権をサービスプリンシパルに付与するには、インストールされているマルチテナントアプリケーション用に作成されたサービスプリンシパルにこのロールを割り当てる必要があります。これを行うには、ユーザーアクセス管理者のアクセス許可が必要です。サービスプリンシパル GUID (オブジェクト ID とも呼ばれます) は、 Enterprise applications\<installed multitenant application>\Manage\Properties\Object IDで表示できます。
Azure Key Vaultはロールベースのアクセス用に構成する必要もあります。
要求を送信するためのAzure CLI。

認証方法を選択する

テナント間シナリオでカスタマーマネージドキーを使用するようにマルチテナント Microsoft Entra アプリケーションを構成するには、次のいずれかの方法を使用します。

フェデレーション ID のサポート (プレビュー、推奨): ユーザー割り当てマネージド ID (UAMI) を使用してMicrosoft Entraフェデレーション ID 資格情報 (FIC) を構成します。このアプローチでは、マネージド ID トークンを使用してアクセストークンと交換します。これにより、有効期間の長いシークレットの必要性がなくなり、ワークロード ID フェデレーションの原則に合わせて調整されます。この方法では、API バージョン federatedIdentityClientIdで導入されたプレビュー 2026-05-01-preview プロパティが必要です。
クライアントシークレット: accessCredentials プロパティを使用してクライアントシークレットを構成します。この方法は安全性が低く、シークレットをローテーションして保護するために追加の管理が必要です。

Note

Azure Key Vaultおよび Azure Key Vault Managed HSM では、カスタマーマネージドキーに対して同じ API と管理インターフェイスが使用されます。 Azure Key Vaultでサポートされている操作は、Azure Key Vault Managed HSM でもサポートされます。

テナント A でマルチテナント Microsoft Entra アプリケーションを作成する

Azure CLI を使用して要求を送信します。 Azure AI 検索を含むサービスプロバイダーのテナントは、テナント A と呼ばれます。

テナント ID を取得します。 az account show --query tenantId --output tsv
テナント A にサインインしていることを確認します。 az login --tenant \<tenant-A-id\>
アプリケーション登録を作成します。 az ad app create --display-name cross-tenant-auth --sign-in-audience AzureADMultipleOrgs
この手順のアプリ ID 出力を保存します。

フェデレーション ID のサポートを使用する (プレビュー)

フェデレーション ID を使用してテナント間 CMK シナリオをサポートするには:

サービスプロバイダーは、テナント (テナント A) で AI Search サービスを構成します。この方法については、検索サービスの作成 (Azure portal 内) を参照するか、Azure CLI で az search service create コマンドを使用してください。
サービスプロバイダーは、マルチテナント Microsoft Entra アプリの登録を作成します。これを行う方法のガイダンスについては、「アプリを Microsoft Entra ID に登録する方法」を参照するか、Azure CLI コマンドを使用します:az ad app create。アプリの登録が完了したら、アプリケーション (クライアント) ID を記録します。
サービスプロバイダーは、ユーザー割り当てマネージド ID を設定します。これを行う方法については、Azure portal を使用したユーザー割り当てマネージド ID の管理またはAzure CLI を使用したユーザー割り当てマネージド ID の管理を参照してください。
サービスプロバイダーは、ユーザー割り当てマネージド ID をアプリのフェデレーション ID 資格情報として構成します。これを行う方法のガイダンスについては、「外部 ID プロバイダーを信頼するようにアプリを構成する」を参照してください。
サービスプロバイダーがマルチテナントアプリ ID を共有すると、顧客は、テナント (テナント B) のKey Vaultへのアクセス権をサービスプロバイダーのアプリに付与します。テナント B にアプリをインストールするには、マルチテナントアプリ ID を使用してサービスプリンシパルを作成する必要があります。サービスプリンシパルを作成するには、admin-consent URL を作成し、テナント全体の同意を付与するか、Azure CLIで az ad sp コマンドを使用します。
お客様に使用するキーコンテナーがまだない場合は、「クイックスタート - Azure ポータルでAzure Key Vaultを作成する」または「クイックスタート - Azure CLIでAzure Key Vaultを作成する」を参照してください。 Key Vault では、アクセス許可モデルを "Azure ロールベースのアクセス制御 (RBAC)" に設定し、サービスプロバイダーのマルチテナントアプリケーションに Key Vault Crypto Service Encryption User role を割り当ててアクセス許可を付与する必要があります。その後、顧客は暗号化キーを作成できます。この方法に関するガイダンスについては、「Azure RBAC を使用して Azure キーコンテナーにアクセスするためのアクセス許可をアプリケーションに付与する」を参照してください。

これらの手順が完了すると、サービスプロバイダーは次の機能を備えます。

顧客のテナント内にインストールされ、カスタマーマネージドキーへのアクセスが許可されている、マルチテナントアプリケーションのアプリケーション ID。
マルチテナントアプリケーションでフェデレーション資格情報として構成されたマネージド ID。
顧客のキーコンテナー内のキーの場所。

この 3 つのパラメーターを使用して、サービスプロバイダーは Tenant A にAzure AI 検索オブジェクトを作成できるようになりました。このオブジェクトは、Tenant B に格納されているカスタマーマネージドキーを使用して暗号化できます。新しい検索オブジェクトでカスタマーマネージドキーを構成する方法のガイダンスについては、「暗号化されたデータのカスタマーマネージドキーの構成Azure AI 検索を参照してください。

フェデレーション ID のクロステナント CMK 構成を検証する

マルチテナント Microsoft Entra アプリケーションを構成し、それを顧客のKey Vaultに接続したら、検索サービス (テナント A) にテストオブジェクトを作成してセットアップを確認します。この例では、検索サービスがフェデレーション ID 認証を使用してカスタマーマネージドキーにアクセスできることを確認するインデックスを作成します。

カスタマーマネージドキーを使用して検索サービスと新しいインデックスオブジェクトを作成する方法のガイダンスについては>Azure AI 検索暗号化されたデータの構成のカスタマーマネージドキーの構成に関する

インデックスオブジェクトが作成されたら、次の内容を入力する必要があります。

keyVaultUri: 顧客からの URI アドレス。
keyVaultKeyName: 顧客のキー名。
keyVaultKeyVersion: 顧客のキーバージョン。
userAssignedIdentity: テナントからの <subscription-id> と <resource-group> 、 <identity-name> はユーザー割り当てマネージド ID 名です。
federatedIdentityClientId: このプロパティ値 <application-client-id>は、マルチテナントアプリケーション (クライアント) ID になります。

{
  "name": "cross-tenant-cmk-test",
  "fields": [
    {
      "name": "id",
      "type": "Edm.String",
      "key": true
    }
  ],
  "encryptionKey": {
    "keyVaultUri": "https://<key-vault-name>.vault.azure.net/",
    "keyVaultKeyName": "<key-name>",
    "keyVaultKeyVersion": "<key-version>",
    "identity": {
      "@odata.type": "#Microsoft.Azure.Search.DataUserAssignedIdentity",
      "userAssignedIdentity": "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity-name>",
      "federatedIdentityClientId": "<application-client-id>"
    }
  }
}

GET要求を送信して、インデックスを確認します。GET https://<search-service>.search.windows.net/indexes/cross-tenant-cmk-test?api-version=2026-08-01-preview

要求が成功すると、テナント間の CMK 構成が正しく動作します。

キーアクセスエラーでインデックスの作成が失敗した場合は、次のことを確認します。

ユーザー割り当てマネージド ID が正しく構成されている
フェデレーション ID 資格情報がアプリで設定されている
Key Vault のアクセスポリシーまたは RBAC ロールの割り当ては適切です

クライアントシークレットを使用する (フェデレーション ID を使用するオプションではない場合)

フェデレーション ID がオプションでない場合は、マルチテナントアプリケーションにクライアントシークレットを追加して、テナント間 CMK シナリオをサポートできます。

テナント A のマルチテナントアプリケーションにクライアントシークレットを追加するには、次のコマンドを実行します。

az ad app credential reset --id <multitenant-app-id>
この手順のパスワード出力を保存します。パスワード出力は、Azure AI 検索で CMK を設定するために必要な入力です。
クライアントシークレットの有効期限を指定するには、このコマンドに終了日パラメーターを指定します。

az ad app credential reset --id <multitenant-app-id> --end-date <end-date>

終了日パラメーターは、ISO 8601 形式の日付を受け取ります。たとえば、 az ad app credential reset --id <multitenant-app-id> --end-date 2026-12-31と指定します。

マルチテナントアプリケーションのテナント B にサービスプリンシパルを作成する

Azure Key Vault を含むテナントを テナント B と見なします。テナント B で、テナント A のマルチテナントアプリケーションのサービスプリンシパルを作成します。

テナント B にログインします。

az login --tenant <tenant-B-id>
最初の手順のマルチテナントアプリ ID 出力を使用して、サービスプリンシパルを作成します。

az ad sp create --id <multitenant-app-id>

このサービスプリンシパルは、テナント A のマルチテナントアプリケーションのインスタンスです。テナント B でこのサービスプリンシパルに割り当てられたロールは、テナント A のマルチテナントアプリケーションにも割り当てられます。
次のコマンドで "appOwnerOrganizationId" を確認して、テナント A と B の間のリンクを確認します。

az ad sp show --id <multitenant-app-id>

このコマンドは、サービスプリンシパルの詳細を JSON で表示します。出力で "appOwnerOrganizationId" フィールドを探して、テナント A の ID と一致することを確認します。
このステップで、サービスプリンシパルのオブジェクト ID ("id" フィールドから) を保存します。オブジェクト ID は、Azure AI 検索で CMK を設定するために必要な入力です。
Azure Key Vault のリソース ID を取得します。

az keyvault show --name <key-vault-name> --query id --output tsv
テナント B の キーコンテナーの Key Vault Crypto Service Encryption ユーザー ロールを新しいサービスプリンシパルに割り当てます。

az role assignment create --assignee <service-principal-object-id> --role "Key Vault Crypto Service Encryption User" --scope <key-vault-resource-id>

この割り当ての例は次のようになります。

az role assignment create --assignee 00001111-aaaa-2222-bbbb-3333cccc4444 --role "Key Vault Crypto Service Encryption User" --scope /subscriptions/87654321-4321-4321-4321-210987654321/resourceGroups/myKeyVaultRG/providers/Microsoft.KeyVault/vaults/myCompanyKeyVault

テナント間の CMK 構成におけるクライアントシークレットの検証

マルチテナント Microsoft Entra アプリケーションを構成し、それを顧客のKey Vaultに接続したら、検索サービス (テナント A) にテストオブジェクトを作成してセットアップを確認します。この例では、検索サービスがクライアントシークレットを使用してカスタマーマネージドキーにアクセスできることを確認するインデックスを作成します。

カスタマーマネージドキーを使用して検索サービスと新しいインデックスオブジェクトを作成する方法のガイダンスについては>Azure AI 検索暗号化されたデータの構成のカスタマーマネージドキーの構成に関する
Azure ポータルを使用してインデックスを追加してこの JSON を指定するか、REST クライアントを使用して Create Index 要求を送信できます。インデックスオブジェクトが作成されたら、次の内容を入力する必要があります。
- keyVaultUri: 顧客からの URI アドレス。
- keyVaultKeyName: 顧客のキー名。
- keyVaultKeyVersion: 顧客のキーバージョン。
- accessCredentials: applicationId は 00001111-aaaa-2222-bbbb-3333cccc4444のようなもので、 applicationSecret は先ほど作成した値です。

{
  "name": "cross-tenant-cmk-test",
  "fields": [
        {
            "name": "id",
            "type": "Edm.String",
            "key": true
        }
      ],
 "encryptionKey": {
        "keyVaultUri": "https://<key-vault-name>.vault.azure.net/",
        "keyVaultKeyName": "<key-name>",
        "keyVaultKeyVersion": "<key-version>",
    "accessCredentials": {
      "applicationId": "<application-client-id>",
      "applicationSecret": "<application-client-secret>"
    }
  }
}

インデックスが正常に作成されたことを確認します。

GET https://<search-service>.search.windows.net/indexes/cross-tenant-cmk-test?api-version=2026-04-01

キーをローテーションまたは管理する方法の詳細については、「データ暗号化用にカスタマーマネージドキーを構成する」を参照してください。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-07-21

異なるテナント間でカスタマー マネージド キーを構成する