Configurer des clés gérées par le client sur différents locataires

Cet article décrit un scénario entre locataires dans lequel un fournisseur de services héberge Recherche Azure AI dans son propre locataire et active le chiffrement avec clé gérée par le client (CMK) à l’aide d’une application Microsoft Entra multilocataire.

Dans cette configuration, le client utilise Azure Key Vault dans son propre locataire pour gérer sa clé de chiffrement. Le fournisseur de services n’a pas accès à cette clé.

Prerequisites

• Tenant A : un locataire et les autorisations nécessaires pour créer le service Recherche Azure AI et les objets associés (indexes, listes de synonymes, indexeurs, sources de données, vectoriseurs, ensembles de compétences). La prise en charge des clés gérées par le client (CMK) nécessite un niveau tarifaire de base ou supérieur.

• Configurez le service de recherche pour l’accès en fonction du rôle (recommandé pour une sécurité renforcée, non obligatoire).

• Tenant B : Un locataire client distinct avec un Azure Key Vault et les autorisations nécessaires sur ce locataire :

  • Key Vault Contributeur : ce rôle est requis si vous devez créer une nouvelle key vault.
  • Autorisation d’enregistrer des applications dans Microsoft Entra ID : pour installer l’application multilocataire configurée par le fournisseur de services pour le CMK entre locataires, vous devez disposer de l’autorisation de créer des enregistrements d’applications dans Microsoft Entra ID. Cela nécessite généralement le rôle Développeur d’applications ou un rôle d’administration supérieur, tel que l’administrateur d’application ou l’administrateur général.
  • Key Vault Agent de chiffrement : ce rôle est requis pour ajouter une nouvelle clé au key vault.
  • Key Vault Crypto Service Encryption User : ce rôle doit être attribué au principal de service créé pour l’application multilocataire installée afin de lui accorder l’accès à la clé gérée par le client dans le coffre de clés. Vous devez disposer de l’autorisation Administrateur de l’accès utilisateur pour effectuer cette opération. Vous pouvez afficher le GUID du principal de service (également appelé ID d’objet) sous : Enterprise applications\<installed multitenant application>\Manage\Properties\Object ID.

• La Azure Key Vault doit également être configurée pour l’accès en fonction du rôle.

• Azure CLI pour l’envoi de requêtes.

Choisir une approche d’authentification

Vous pouvez configurer une application multilocataire Microsoft Entra pour utiliser des clés gérées par le client dans un scénario interlocataire à l’aide de l’une des approches suivantes :

1. Prise en charge des identités fédérées (préversion, recommandé) : configurez des informations d’identification d’identité fédérée Microsoft Entra (FIC) avec une identité managée affectée par l’utilisateur (UAMI). Cette approche utilise des jetons d’identité managée et les échange contre des jetons d’accès, éliminant ainsi le besoin de secrets de longue durée et s’alignant sur les principes de fédération des identités de charge de travail. Cette approche nécessite la propriété en préversion federatedIdentityClientId , introduite dans la version 2026-05-01-previewde l’API.

2. Secrets client : configurez une clé secrète client à l’aide de la accessCredentials propriété. Cette approche est moins sécurisée et nécessite une gestion supplémentaire pour renouveler et protéger le secret.

Créer une application multi-tenant Microsoft Entra dans le tenant A

Utilisez Azure CLI pour envoyer des demandes. Le locataire du fournisseur de services qui contient Recherche Azure AI sera appelé locataire A.

1. Obtenez l’ID de locataire : az account show --query tenantId --output tsv

2. Vérifiez que vous êtes connecté au locataire A : az login --tenant \<tenant-A-id\>

3. Créez l’enregistrement de l’application : az ad app create --display-name cross-tenant-auth --sign-in-audience AzureADMultipleOrgs

4. Enregistrez la sortie de l’ID d’application à partir de cette étape.

Utiliser la prise en charge des identités fédérées (préversion)

Pour utiliser une identité fédérée afin de prendre en charge un scénario CMK multilocataire :

1. Le fournisseur de services configure le service AI Search dans son locataire (Locataire A). Pour obtenir des conseils sur la procédure à suivre, consultez Create a Search Service (dans le portail Azure) ou utilisez la commande az search service create dans Azure CLI.

2. Le fournisseur de services crée un enregistrement d’application multilocataire Microsoft Entra. Pour obtenir des conseils sur la procédure à suivre, consultez How to register an app in Microsoft Entra ID, or use the Azure CLI command : az ad app create. Enregistrez l’ID d’application (client) une fois que vous avez terminé l’inscription de l’application.

3. Le fournisseur de services configure une identité managée affectée par l’utilisateur. Pour obtenir des conseils sur la procédure à suivre, consultez Identités managées affectées par l’utilisateur à l’aide du portail Azure ou Identités managées affectées par l’utilisateur à l’aide des Azure CLI.

4. Le fournisseur de services configure les identités managées affectées par l’utilisateur en tant qu’informations d’identification d’identité fédérée sur l’application. Pour obtenir des conseils sur la procédure à suivre, consultez Configurer une application pour approuver un fournisseur d’identité externe.

5. Une fois que le fournisseur de services partage l’ID de l’application multilocataire, le client donne à l’application du fournisseur de services l’accès au coffre de clés dans son locataire (Locataire B). Pour installer l’application dans le locataire B, un principal de service doit être créé avec l’ID d’application multilocataire. Pour créer le principal de service, créez une URL admin-consent et accordez un consentement à l’échelle du locataire, ou utilisez la commande az ad sp dans Azure CLI.

6. Si le client n'a pas encore de coffre de clés à utiliser, consultez Démarrage rapide - Créer un Azure Key Vault avec le portail Azure ou le démarrage rapide - Créer un Azure Key Vault avec le Azure CLI. Le coffre de clés doit avoir le modèle d’autorisation défini sur « Contrôle d’accès basé sur les rôles (RBAC) », et l’application multilocataire du fournisseur de services doit ensuite recevoir les autorisations nécessaires en se voyant attribuer le rôle Utilisateur du service de chiffrement de Key Vault. Le client peut ensuite créer une clé de chiffrement. Pour obtenir des conseils sur la procédure à suivre, consultez Autorisation d’accès aux applications pour accéder à un coffre de clés Azure à l’aide de Azure RBAC.

Une fois ces étapes terminées, le fournisseur de services dispose désormais des éléments suivants :

• L’ID d’une application multilocataire installée dans le locataire du client, qui a reçu l’accès à la clé gérée par le client.

• Identité managée configurée en tant qu’informations d’identification fédérées sur l’application multilocataire.

• Emplacement de la clé dans le coffre de clés du client.

Avec ces trois paramètres, le fournisseur de services peut désormais créer des objets Recherche Azure AI dans Tenant A qui peuvent être chiffrés avec la clé gérée par le client stockée dans Tenant B. Pour obtenir des conseils sur la configuration des clés gérées par le client sur de nouveaux objets de recherche, consultez Configurer les clés gérées par le client pour Recherche Azure AI données chiffrées.

Valider la configuration CMK interlocataire de l’identité fédérée

Après avoir configuré l'application multilocataire Microsoft Entra et la connecter au Key Vault du client, vérifiez l'installation en créant un objet de test dans votre service de recherche (locataire A). Cet exemple crée un index pour confirmer que le service de recherche peut accéder à la clé gérée par le client à l’aide de l’authentification d’identité fédérée.

1. Consultez Configurer les clés gérées par le client pour Recherche Azure AI données chiffrées pour obtenir des conseils sur la création d’un service de recherche et d’un nouvel objet d’index avec une clé gérée par le client.

2. Une fois l’objet d’index créé, vous devez renseigner les éléments suivants :

   • keyVaultUri: adresse URI du client.
   • keyVaultKeyName: nom de clé du client.
   • keyVaultKeyVersion : la version de la clé fournie par le client.
   • userAssignedIdentity : les valeurs <subscription-id> et <resource-group> proviennent de votre locataire, et <identity-name> correspond au nom de l’identité managée attribuée par l’utilisateur.
   • federatedIdentityClientId: Cette valeur de propriété, <application-client-id>, correspond à l’ID d’application (client) multilocataire.

   {
     "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>"
       }
     }
   }
   

3. Vérifiez l’index en envoyant une GET requête : GET https://<search-service>.search.windows.net/indexes/cross-tenant-cmk-test?api-version=2026-08-01-preview

Si la requête aboutit, la configuration CMK interlocataire fonctionne correctement.

Si la création d’index échoue avec une erreur d’accès à la clé, vérifiez que :

• L’identité managée affectée par l’utilisateur est configurée correctement
• Les informations d’identification de l’identité fédérée sont définies sur l’application
• La stratégie d’accès Key Vault ou les attributions de rôles RBAC sont correctes

Utiliser une clé secrète client (si l’utilisation de l’identité fédérée n’est pas une option)

Si l’identité fédérée n’est pas une option, vous pouvez ajouter un secret client à l’application multilocataire pour prendre en charge un scénario CMK entre locataires :

1. Pour ajouter la clé secrète client à l’application multilocataire dans le locataire A, exécutez la commande suivante :

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

2. Enregistrez la sortie du mot de passe à partir de cette étape. La sortie du mot de passe est une entrée requise pour configurer CMK dans Recherche IA Azure.

3. Pour spécifier quand la clé secrète client expire, vous pouvez spécifier un paramètre de date de fin à cette commande.

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

   Le paramètre date de fin accepte une date au format ISO 8601. Par exemple : az ad app credential reset --id <multitenant-app-id> --end-date 2026-12-31.

Créer un principal de service dans le locataire B pour l’application multilocataire

Nous faisons référence au locataire contenant Azure Key Vault en tant que locataire B. Dans le locataire B, créez un principal de service pour l’application multilocataire du locataire A.

1. Connectez-vous au locataire B :

   az login --tenant <tenant-B-id>

2. Créez le principal de service à l’aide de l’ID d’application multilocataire provenant de la première étape :

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

   Ce principal de service est une instance de l’application mutualisée dans le locataire A. Les rôles attribués à ce principal de service dans le locataire B sont également attribués à l’application mutualisée dans le locataire A.

3. Vérifiez le lien entre le locataire A et B en examinant « appOwnerOrganizationId » dans la commande suivante :

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

   Cette commande affiche les détails du principal de service au format JSON. Recherchez le champ « appOwnerOrganizationId » dans la sortie pour confirmer qu’il correspond à l’ID du locataire A.

4. Enregistrez l’ID d’objet du principal de service (à partir du "id" champ) à partir de cette étape. L’ID d’objet est une entrée requise pour configurer CMK dans Recherche IA Azure.

5. Obtenez l’ID de ressource pour Azure Key Vault :

   az keyvault show --name <key-vault-name> --query id --output tsv

6. Attribuez le rôle Utilisateur du service de chiffrement Key Vault sur le coffre de clés du locataire B au nouveau principal de service.

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

   Un exemple de cette affectation peut ressembler à ceci :

   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

Valider la configuration CMK interlocataire de la clé secrète client

Après avoir configuré l'application multilocataire Microsoft Entra et la connecter au Key Vault du client, vérifiez l'installation en créant un objet de test dans votre service de recherche (locataire A). Cet exemple crée un index pour confirmer que le service de recherche peut accéder à la clé gérée par le client à l’aide de la clé secrète client.

1. Consultez Configurer les clés gérées par le client pour Recherche Azure AI données chiffrées pour obtenir des conseils sur la création d’un service de recherche et d’un nouvel objet d’index avec une clé gérée par le client.

2. Vous pouvez utiliser le portail Azure pour ajouter un index et fournir ce json, ou utiliser un client REST pour envoyer une requête Create Index. Une fois l’objet d’index créé, vous devez renseigner les éléments suivants :

   • keyVaultUri: adresse URI du client.
   • keyVaultKeyName: nom de clé du client.
   • keyVaultKeyVersion : la version de la clé fournie par le client.
   • accessCredentials: Le applicationId est quelque chose comme 00001111-aaaa-2222-bbbb-3333cccc4444, et le applicationSecret est la valeur que vous venez de créer.

{
  "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>"
    }
  }
}

Vérifiez que l’index a été créé avec succès :

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

Pour plus d’informations sur la rotation ou la gestion des clés, consultez Configurer des clés gérées par le client pour le chiffrement des données.