Remplacer des profils de principal du service par des principaux du service

Si votre solution utilise des profils de principal de service (SPP) et que des limitations liées à leur identité, leur gouvernance, leurs API ou leur exploitation contraignent vos exigences, ce guide vous aide à évaluer et à implémenter un remplacement basé sur des principaux de service dédiés Microsoft Entra. Si votre solution basée sur un profil existant répond à vos besoins, vous pouvez continuer à l’utiliser.

Pour les clients qui choisissent de migrer, ce guide recommande l’identité managée et les informations d’identification fédérées lorsque les exigences d’hébergement et de confiance sont remplies. L’authentification directe du principal de service reste une alternative. Les deux chemins fournissent des identités client dédiées pour la gouvernance des annuaires, la surveillance indépendante des connexions et l’accès aux services pris en charge au-delà des interfaces prenant en charge les profils.

Pourquoi migrer depuis des profils

Envisagez de remplacer des profils lorsque les limitations suivantes constituent une contrainte pour votre solution :

• Les profils ne sont pas conformes aux meilleures pratiques de Microsoft Entra ID pour les identités de charge de travail pouvant être régies. Un profil n’a aucune représentation dans Microsoft Entra ID. Il ne produit aucun journal de connexion indépendant, ne peut pas porter sa propre stratégie d’accès conditionnel et ne peut pas être régi par les outils utilisés pour le reste de l’environnement d’identité.

Par exemple, vous ne pouvez pas configurer un profil en tant qu’identité pour une connexion Direct Lake à partir d’un modèle sémantique vers un lakehouse ou un entrepôt. Vous ne pouvez pas non plus lui accorder l’accès, en tant qu’identité Microsoft Entra indépendante, à d’autres services en aval auxquels l’application ou ses charges de travail doivent accéder. Un principal de service dédié peut recevoir ces autorisations là où le service le prend en charge.

Vous ne pouvez pas utiliser de profils avec les API REST Fabric. Les profils sont pris en charge uniquement par l’API REST prenant en charge les profils, son sdk .NET et les interfaces XMLA/TOM prises en charge. Les API REST Fabric ne prennent pas en charge les profils et la prise en charge n'est pas planifiée. Utilisez une identité prise en charge pour ces appels d’API au lieu d’un profil. La création d’un principal de service dédié répond à l’exigence d’identité, mais chaque API et chaque opération doivent toujours prendre en charge cette identité et lui accorder les autorisations nécessaires.

• L’authentification reste liée à l’identité mère. Lorsque le parent utilise un secret ou un certificat, protégez et renouvelez cet identifiant. Le modèle de remplacement recommandé évite les identifiants client/d’application stockés. Les profils peuvent également utiliser un parent d’identité managée, de sorte que l’authentification sans secret n’exige pas de remplacer les profils. Un parent d’identité managée ne donne pas aux profils des identités d’annuaire indépendantes ou une prise en charge plus large de l’API.

Les profils résolvent un problème de mise à l’échelle, et non un problème d’identité indépendante. Un principal de service parent peut créer jusqu’à 100 000 profils, et chaque profil peut accéder à jusqu’à 1 000 espaces de travail ou en créer jusqu’à 1 000. Un principal de service lui-même peut appartenir à au plus 1 000 espaces de travail dans ce modèle. Les identités client dédiées consomment plutôt des objets d’annuaire Microsoft Entra. Validez les limites applicables par rapport au nombre de clients avant de lancer la migration.

Autres limitations de profil à prendre en compte

Modèle d’identité gérée et d’identifiants fédérés

Utilisez ce modèle pour une nouvelle solution de principal de service dédié ou lorsque vous choisissez de remplacer des profils, à condition que votre environnement d’exécution réponde aux exigences d’hébergement d’identité managée.

Le motif

Donnez à chaque client un véritable principal de service Microsoft Entra et utilisez l'identité managée de l'application comme source d'assertion. Cette approche remplace le justificatif d’application partagé et l’abstraction de profil. Vous pouvez consigner, régir et prendre en compte chaque identité client pour l’accès conditionnel de l’identité de charge de travail, et celle-ci peut appeler les API REST Fabric prises en charge.

Cette approche est la voie de migration recommandée lorsque ses exigences d’hébergement Azure et de confiance correspondent à la solution. Il supprime les identifiants d’application client du client stockés et leurs processus de rotation sans modifier l’emplacement où l’autorisation d’espace de travail et de ressource est appliquée.

L’architecture montre les opérations d’exécution de l’application, trois identités d’application client et relations de confiance, ainsi que les relations d’espace de travail client un-à-un. Il représente la disposition par défaut du runtime partagé, et non une nouvelle limite d’isolation.

Figure 1. Une identité managée s’authentifie à l’aide de principaux de service dédiés au client.

Fonctionnement

1. Identité managée d’application. Attribuez une identité managée affectée par l’utilisateur à l’application ISV exécutée sur des ressources de calcul Azure prises en charge, comme App Service, Container Apps, une charge de travail AKS correctement configurée ou une machine virtuelle. Utilisez une identité managée pour l’application, et non une par client. Il n’a pas d’espace de travail client ni d’autorisations de service cible propres ; son rôle ici consiste uniquement à fournir une assertion.

2. Par client, utilisateur ou principal du service de groupe. Pour chaque client existant ou limite d’autorisation, créez une inscription d’application Microsoft Entra et le principal de service dans le locataire d’annuaire du fournisseur de logiciels indépendants. Un client logique ne signifie pas nécessairement un locataire Microsoft Entra distinct et une identité par utilisateur final n'est pas requise, sauf si la conception d'accès existante le prévoit.

3. Identifiant d’identité fédérée Configurez des informations d’identification d’identité fédérée sur chaque inscription d’application cliente pour faire confiance à l’identité gérée de l’application. Le runtime peut ensuite utiliser son jeton d’identité managée comme assertion pour obtenir un jeton d’accès pour cette application cliente sans clé secrète client ou certificat.

4. Échange de jetons au runtime. Lorsque l’utilisateur A ou une tâche spécifique au client appelle l’application, identifiez le client A par le biais d’un mappage côté serveur approuvé. Acquérir le jeton d’identité managée avec l’audience api://AzureADTokenExchange; l’échanger pour un jeton d’accès en tant que SP-A, puis appeler les API cibles à l’aide du jeton SP-A pour gérer les espaces de travail, effectuer des opérations de ressources ou demander des jetons spécifiques à l’application si nécessaire.

   Pour l’échange à l’étape précédente, la .NET Azure Identity ClientAssertionCredential accepte le jeton d’identité managée comme assertion du client. Il s’agit d’un type d’informations d’identification d’identité Azure, et non d’une classe MSAL. Le jeton d’accès doit cibler l’audience de l’API de ressource, et non l’audience d’échange de jetons.

5. Accès à l’espace de travail. Accordez à chaque principal de service un accès de membre ou d’administrateur uniquement à ses espaces de travail désignés lorsque ces rôles sont nécessaires, ou le rôle pris en charge offrant le moins de privilèges pour les opérations requises. Cette autorisation définit l’accès aux ressources. Étant donné que l’identité managée de l’application peut s’authentifier comme chaque application cliente qui lui font confiance, traitez-la et ses hôtes de calcul comme des identités et une infrastructure à valeur élevée.

Pourquoi ce chemin est recommandé

• Moins d’identifiants à longue durée de vie. Vous n’avez pas besoin de stocker, récupérer ou distribuer un secret d’application cliente ou une clé privée de certificat au runtime.

• Moins d’efforts liés à la rotation. Azure gère les informations d’identification de l’identité managée et émet des jetons de courte durée. Vous n’avez pas besoin d’un processus de renouvellement de secret ou de certificat distinct pour chaque application client à l’aide de cette relation de confiance.

• Prise en main cohérente. Provisionnez une application cliente et un service principal, définissez la relation de confiance explicite et accordez l’accès aux ressources client. Les nouveaux clients n’ont pas besoin de nouveaux identifiants à long terme.

Ces avantages ne suppriment pas la nécessité d’une administration des relations d’approbation, d’une autorisation client, d’une surveillance d’audit ou d’une planification de la capacité d’annuaire.

Alternative : Authentification directe du principal de service

Si vous ne souhaitez pas utiliser d’identité managée et d’informations d’identification de fédération, créez les mêmes enregistrements d’applications client dédiés et les mêmes principaux de service, mais authentifiez-les directement avec des certificats ou d’autres informations d’identification d’application prises en charge. Préférer les certificats aux secrets client lorsqu’ils sont pris en charge. Protégez les clés privées et les secrets, limitez l’accès à ces clés et automatisez la rotation.

L’authentification directe conserve la visibilité des annuaires, les journaux de connexion par principal et l’accès aux API prises en charge. Elle ne nécessite pas l’hébergement d’identité gérée ou la relation de confiance, mais elle n’élimine pas les informations d’identification du client stockées.

Concepts clés

Distinguez les informations d’identification qui établissent la confiance des jetons utilisés au moment de l’exécution.

Identifiants d’identité fédérée

Configurez un identifiant fédéré (FIC) sur l’inscription d’application Microsoft Entra associée au principal de service client. Il définit une relation de confiance avec un émetteur de jeton et spécifie quelle assertion l’application accepte au lieu d’un secret client ou d’un certificat.

Dans cette architecture, l’identité cible est l’application cliente et le principal de service ; l’identité managée de l’application est la source d’assertion. C’est pourquoi vous configurez les informations d’identification du client sur l’inscription de l’application plutôt que sur l’objet service principal ou l’identité managée source.

Lorsque l’application présente le jeton d’identité managée et demande un jeton d’accès pour l’application cliente, Microsoft Entra ID valide l’assertion par rapport au justificatif d’identité fédéré. L’émetteur, le sujet et l’audience doivent correspondre. Si la validation réussit, elle émet un jeton d’accès représentant le principal de service client cible pour la ressource demandée.

L’identité gérée et l’inscription de l’application approuvante doivent se trouver dans le même tenant Microsoft Entra. Le destinataire de la ressource est un choix distinct du destinataire de l’assertion. Pour Azure Identity, la portée d’échange de jetons cloud global est api://AzureADTokenExchange/.default; la portée de l’API cible est normalement l’identificateur de ressource suivi de /.default.

Flux d’échange de jetons : informations d’identification du client avec une assertion fédérée

Ce flux implique trois participants et six étapes. SP-A est l’application et le service principal du client A. Le jeton d’assertion d’identité managée et le jeton d’accès à la ressource SP-A retourné servent à des fins différentes.

Figure 2 : L’échange de jeton d’informations d’identification du client est basé sur une assertion d’identité managée.

1. Demandez le jeton d’identité managée. L’application sur Azure demande un jeton d’identité managée avec l’audience api://AzureADTokenExchange.

2. Retourne le jeton d’assertion. Microsoft Entra ID émet le jeton d'identité managée, que l'application reçoit par le biais de son mécanisme d'identité managée de l'environnement d'hébergement Azure.

3. Envoyez la demande de jeton client. Envoyez une requête au point de terminaison du locataire du répertoire /oauth2/v2.0/token avec grant_type=client_credentials, client_id=<SP-A-client-id>, client_assertion=<MI-token> et scope=<target-resource>/.default. La requête OAuth complète fournit client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearerégalement ; une bibliothèque d’identité gère ce paramètre.

4. Validez l’assertion. Microsoft Entra ID valide le jeton d'identité managée par rapport aux informations d'identification fédérées sur l'inscription d'application de SP-A.

5. Retournez le jeton d’accès du client. Microsoft Entra ID retourne un jeton d’accès pour SP-A avec la ressource cible en tant qu’audience.

6. Appelez les API REST cibles. L’application envoie le jeton d’accès de SP-A à l’API cible. Il n’utilise pas le jeton d’assertion comme jeton porteur de ressource et ne sélectionne pas de profil.

Comparaison d’architecture

La colonne de remplacement couvre généralement les identités de service dédiées. L’identité gérée et la fédération sont la méthode d’authentification recommandée, mais l’authentification directe par certificat ou d’autres méthodes d’authentification par informations d’identification prises en charge sont également possibles.

Comment lire ce tableau : aucune configuration ne fournit l’isolation cryptographique des clients. Les autorisations de ressources contrôlent l’accès, et le runtime peut avoir une portée indirecte entre les clients. Les profils offrent une mise à l’échelle de l’identité légère. Les principaux de sécurité dédiés améliorent la gouvernance des annuaires, la visibilité de la connexion et la compatibilité des API. L’identité managée et le chemin de fédération recommandés suppriment également les informations d’identification stockées de l’application du client.

Chemin de migration

Le chemin suivant remplace les profils par les principaux de service dédiés. Conservez les décisions de migration et de retour arrière distinctes pour chaque client.

Des profils à l’identité gérée et aux informations d’identification fédérées

Utilisez les phases de migration suivantes avec une petite cohorte pilote et un interrupteur de déploiement progressif par client. Conservez la route de profil disponible jusqu’à ce que la validation et la période de retour arrière convenue soient terminées.

Phase 0 : Créer l’identité managée de l’application

• Créez l’identité managée affectée par l’utilisateur pour l’application et affectez-la à la ressource de calcul. Le guide d’implémentation montre les commandes de création et d’attribution.

• Enregistrez son ID principal de l’objet. Les informations d’identification fédérées de chaque application cliente utilisent cette valeur comme sujet. Enregistrez également l’ID client, l’ID de locataire d’annuaire et l’ID de ressource Azure.

Utilisez une identité managée pour l’application, et non une par client. Un MI distinct pour chaque client n’est pas nécessaire dans ce modèle : l’identité du client est le principal du service et le MI fournit l’assertion. Pour les déploiements plus volumineux ou une plus petite étendue de compromission, répartissez les clients entre un petit nombre d’identités d’exécution, chacune approuvée uniquement par le sous-ensemble d’applications clientes qui lui est attribué.

Phase 1 : Inventaire

Répertoriez tous les profils existants via l’API profile-management :

GET {profile-api-base}/v1.0/myorg/profiles

Pour chaque profil, enregistrez :

• ID de profil et nom d’affichage, principal du service parent et mappage client.

• Espaces de travail et attributions de rôles associés.

• Modèles sémantiques ou jeux de données associés, rapports et autres ressources.

• Connexions, informations d’identification de source de données, dépendances de propriété, travaux en arrière-plan et opérations d’API qui dépendent du profil.

Avant de modifier la configuration d’un client, enregistrez les rôles d’espace de travail existants, la propriété du modèle sémantique, les identités de connexion, la configuration des informations d’identification et le mappage client-à-profil nécessaires à la restauration. Enregistrez des références sécurisées aux informations d’identification et non des valeurs secrètes.

Enregistrez le nombre total de clients et comparez les objets d’application et de principal de service requis à votre quota d’objets d’annuaire Microsoft Entra avant de continuer. Validez également la limite d’appartenance à 1 000 espaces de travail et toutes les limites spécifiques aux ressources. Si la population dépasse le quota d’un répertoire unique, planifiez une augmentation de quota prise en charge ou gérez délibérément la conception de plusieurs annuaires ; ce problème n’est pas résolu automatiquement par ce modèle.

Phase 2 : Créer de nouvelles identités

Pour chaque profil ou groupe de profils appartenant à la même limite d’autorisation client :

1. Créez une inscription d’application et un principal du service. Enregistrez l’ID client de l’application, l’ID d’objet d’application et l’ID d’objet du principal de service séparément.

2. Configurez des informations d’identification de fédération sur l’inscription d’application du client qui fait confiance à l’application MI créée à la phase 0.

3. Accordez au nouveau service principal l’accès aux mêmes espaces de travail et ressources client. Utilisez Membre là où les opérations inventoriées l’exigent, ou le rôle pris en charge le moins privilégié. N’accordez les droits d’administrateur qu’en cas de nécessité.

Conservez les ID d’espace de travail et de ressource existants partout où ils sont pris en charge. Une autorisation d’espace de travail ne transfère pas automatiquement la propriété des ressources, les identités de connexion ou les informations d’identification de source de données. Effectuez ces mises à jour spécifiques au service avant le basculement.

Phase 3 : Mettre à jour le code de l’application

• Remplacez l’en-tête de sélection de profil et la configuration du profil sdk par l’échange de jetons avec identité managée pour l’application cliente sélectionnée.

• Mettez à jour le mappage client-à-identité dans votre base de données d’application.

Les ID de client sont des identificateurs logiques des clients ISV, pas nécessairement des ID de locataire Microsoft Entra. Validez l’adhésion client de l’utilisateur authentifié avant de sélectionner une identité. Met en cache les jetons de clé par locataire d’annuaire, ID client et ressource ou étendue.

• Mettez à jour la génération de jetons spécifique à l’application pour utiliser le jeton d’accès du principal de service client. Si votre solution incorpore des rapports ou d’autres contenus, mettez également à jour cette génération de jetons ; l’incorporation est un scénario existant à migrer, et non pas un prérequis pour ce guide.

• Mettez à jour la gestion de l’espace de travail, les connexions en aval, l’approvisionnement, les tâches planifiées et tous les autres points d’entrée à l’aide de l’ancienne configuration de profil.

Phase 4 : Valider

Pour chaque client, vérifiez :

• L’accès à l’espace de travail et aux ressources s’effectue via la nouvelle identité de service.

• L’acquisition de jetons d’identité managée et l’échange de jetons fédérés réussissent pour l’application cliente prévue.

• Les jetons spécifiques à l’application sont générés avec succès lorsqu’ils sont utilisés, et les rapports existants ou d’autres contenus incorporés s’affichent correctement, le cas échéant.

• Les nouvelles connexions du service principal s’affichent dans Microsoft Entra ID et peuvent être corrélées avec les journaux d’audit des applications et des ressources.

• L’accès inter-clients est refusé : un appelant ne peut pas sélectionner l’identité d’application ou les ID de ressource d’un autre client.

Avant le basculement de production, documentez et testez la procédure de restauration pour un client pilote. Incluez la restauration de tout propriétaire d’un modèle sémantique, des identités de connexion, des informations d’identification de source de données et des autorisations modifiées pendant la migration. Vérifiez que le profil précédent peut effectuer ses opérations requises après la restauration, notamment l’actualisation de la configuration et la mise à jour des paramètres.

Changez la route de l’application du client uniquement une fois les critères d’acceptation remplis. Surveillez les échecs, les performances et les autorisations avant d’étendre le déploiement.

Si la validation échoue, suspendez les travaux en arrière-plan affectés et restaurez la configuration précédente à l’aide des procédures prises en charge pour chaque service. Le basculement de la route de l’application vers le profil seul peut ne pas restaurer les opérations qui dépendent de la propriété ou des informations d’identification. Après avoir restauré la configuration requise, revenez à la route basée sur le profil et vérifiez l’accès aux ressources et les opérations dépendantes avant de reprendre les tâches. Conservez les profils d’origine et les autorisations requises tout au long de la période de restauration.

Phase 5 : Mise hors service des profils

• Après la période de retour arrière, supprimez les autorisations obsolètes des espaces de travail original-parent et profile, après avoir confirmé que les principaux de service dédiés du client disposent de l’accès requis.

Supprimez chaque profil migré via l’API de gestion des profils :

DELETE {profile-api-base}/v1.0/myorg/profiles/{profileId}

• Supprimez éventuellement l’inscription d’application partagée et le principal du service d’origine si aucun client, tâche ou charge de travail non liée ne les utilise toujours. Retirez les informations d’identification obsolètes et conservez les mappages de migration et les enregistrements d’audit en fonction de vos besoins de rétention.

Guide d’implémentation

Ce guide implémente l’identité managée recommandée et l’approche des informations d’identification fédérées. L’alternative d’authentification directe suit la même configuration d’identité et d’autorisation et est décrite après les étapes principales. Les exemples Azure CLI utilisent la syntaxe Bash ; remplacez les paramètres fictifs et connectez-vous au répertoire et à l’abonnement prévus avant de les exécuter.

Prerequisites

• Un abonnement Azure et des autorisations pour créer et affecter des identités managées pour le chemin recommandé.

• Autorisations dans Microsoft Entra ID pour créer des inscriptions d’application et des principaux de service et mettre à jour les informations d’identification de l’application. Les autorisations de ressources Azure et les autorisations d’annuaire sont distinctes.

• Une application hébergée sur des ressources de calcul Azure prises en charge, comme App Service, Container Apps, une charge de travail AKS correctement configurée ou une machine virtuelle. La source d’assertion adossée à MI dans ce schéma dépend de cette configuration d’hébergement Azure.

• Autorisations administratives pour accorder l’accès à l’espace de travail du client et aux ressources, configurer les paramètres de service requis et accorder des autorisations d’API ou un consentement lorsque le service cible en a besoin.

• Azure CLI installé et authentifié auprès du locataire d’annuaire approprié. Confirmez le contexte de l’abonnement avant de créer des ressources Azure.

Paramètres de l'espace de travail du développeur

Passez en revue les paramètres pertinents dans l’interface d’administration de votre service sous paramètres de locataire et paramètres du développeur. Limitez l’accès du principal de service à un groupe de sécurité autorisé contenant les principaux de service du client. Pour connaître les étiquettes exactes et le comportement actuel, consultez les paramètres du tenant de développeur.

Pour chaque paramètre d’étendue de groupe requis par votre solution, ajoutez chaque principal de service de remplacement du client à un groupe de sécurité autorisé avant de tester ou de basculer. L’accès accordé au principal de service parent d’origine n’autorise pas automatiquement les principaux de remplacement. Le paramètre d'accès à l'API publique s'applique à la fois aux API REST existantes tenant compte des profils et aux API REST Fabric ; la migration uniquement de l'identité ne supprime pas cette condition préalable.

Le paramètre d’API publique suivant utilise une étiquette neutre pour le produit ; l’interface d’administration peut inclure le nom du service.

Vérifiez les valeurs réelles au lieu de supposer les valeurs par défaut. Les clients nouveaux et existants peuvent différer, et les administrateurs peuvent modifier les paramètres. Conservez le paramètre de profil jusqu’à ce que chaque client dépendant et chaque tâche soit migré. N’activez pas les paramètres d’intégration pour une charge de travail sans intégration.

Étape 1 : Créer et affecter l’identité gérée affectée par l’utilisateur

Cette identité managée représente l’application ISV, et non un client individuel. Utilisez un groupe de ressources existant :

az identity create \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --location "<azure-region>"

Enregistrez son ID client, son ID principal (objet), son ID de locataire d’annuaire et son ID de ressource Azure. Affectez-la à la ressource de calcul. Pour une application App Service existante :

az webapp identity assign \
  --resource-group "<resource-group>" \
  --name "<web-app-name>" \
  --identities "<managed-identity-resource-id>"

Utilisez la procédure d’attribution d’identité correspondante pour d’autres services de calcul. Sélectionnez explicitement cette identité affectée par l’utilisateur dans le runtime. Étant donné que l’identité est indépendante de la ressource hôte, le redéploiement d’un hôte n’a pas besoin de remplacer chaque relation de confiance avec chaque client.

Étape 2 : Créer un service principal pour chaque client

Pour chaque client, utilisateur ou étendue de groupe représenté(e) par les profils existants, créez un enregistrement d’application et son principal de service. Cet exemple crée une application monolocataire dans le répertoire de l’ISV :

APP_CLIENT_ID=$(az ad app create \
  --display-name "customer-a-application" \
  --sign-in-audience AzureADMyOrg \
  --query appId --output tsv)

az ad sp create --id "$APP_CLIENT_ID"

APP_OBJECT_ID=$(az ad app show \
  --id "$APP_CLIENT_ID" --query id --output tsv)

SP_OBJECT_ID=$(az ad sp show \
  --id "$APP_CLIENT_ID" --query id --output tsv)

Étape 3 : Configurer les informations d’identification fédérées

Récupérez l’ID du principal d’identité managée et son ID de locataire d’annuaire. Utilisez le tenant de l’identité plutôt que de supposer qu’un autre abonnement actuel a le même tenant :

MI_PRINCIPAL_ID=$(az identity show \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --query principalId --output tsv)

DIRECTORY_TENANT_ID=$(az identity show \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --query tenantId --output tsv)

Ajoutez des informations d’identification d’identité fédérée à chaque inscription d’application client. La commande global-cloud suivante utilise l’ID d’objet d’application de l’étape 2 et les valeurs MI juste récupérées :

az ad app federated-credential create \
  --id "$APP_OBJECT_ID" \
  --parameters "{
    \"name\": \"trust-application-mi\",
    \"issuer\": \"https://login.microsoftonline.com/$DIRECTORY_TENANT_ID/v2.0\",
    \"subject\": \"$MI_PRINCIPAL_ID\",
    \"audiences\": [\"api://AzureADTokenExchange\"],
    \"description\": \"Trust the ISV application managed identity\"
  }"

Vous pouvez également enregistrer le même JSON avec des valeurs substituées dans un fichier local --parameters credential.json et passer credential.json. Répétez la relation de confiance sur chaque application client. Autorisez la propagation de la configuration avant de valider l’échange de jetons.

Étape 4 : Accorder à chaque principal de service l’accès à l’espace de travail

Ajoutez l’identité du service client en tant que membre ou administrateur uniquement à ses espaces de travail désignés où ce rôle est requis. Préférez un rôle pris en charge inférieur s’il répond aux exigences de l’opération. Cette autorisation est ce qui définit réellement l’accès aux ressources du client.

Utilisez l’interface d’administration de l’espace de travail ou l’opération REST d’attribution de rôle de l’espace de travail. L’exemple suivant utilise des identificateurs d’API et de ressources configurables. Elle nécessite une identité d’approvisionnement autorisée ; le MI d’exécution lui-même ne s’est pas vu accorder d’autorisations de ressources client pour l’échange de jetons.

PROFILE_API_BASE="<existing-profile-aware-api-base-url>"
PROFILE_RESOURCE="<existing-api-resource-identifier>"
WORKSPACE_ID="<customer-workspace-id>"

TOKEN=$(az account get-access-token \
  --resource "$PROFILE_RESOURCE" \
  --query accessToken --output tsv)

curl --fail-with-body --request POST \
  "$PROFILE_API_BASE/v1.0/myorg/groups/$WORKSPACE_ID/users" \
  --header "Authorization: Bearer $TOKEN" \
  --header "Content-Type: application/json" \
  --data "{
    \"identifier\": \"$SP_OBJECT_ID\",
    \"groupUserAccessRight\": \"Member\",
    \"principalType\": \"App\"
  }"

Utilisez le point de terminaison et la forme de requête documentées pour le service auquel appartient l’espace de travail existant. L’opération affichée s’applique à l’API d’espace de travail sensible au profil ; d’autres API peuvent utiliser différents schémas d’attribution de rôle. Ne remplacez pas un ID client là où l’opération attend un ID d’objet du principal de service. Évitez de journaliser les jetons Bearer et autorisez la propagation des autorisations.

Étape 5 : Authentifier et appeler des API au moment de l’exécution

1. Résolvez l’ID client d’application du client authentifié et les ressources autorisées de la configuration côté serveur de confiance.

2. Acquérir un jeton d’assertion à l’aide de l’identité managée affectée par l’utilisateur sélectionnée et de l’étendue api://AzureADTokenExchange/.default dans le cloud global.

3. Utilisez le jeton MI comme assertion de client pour l’application cliente. Demandez un jeton d’accès avec la portée de l’application de l’API de ressource, et non l’audience d’assertion.

4. Appelez l’API cible à l’aide de ce jeton d’accès d’application client et sans configuration de sélection de profil. Gérez les espaces de travail, demandez tous les jetons spécifiques à l’application requis et effectuez d’autres opérations inventoriées via l’identité du client.

Pour .NET, utilisez Azure Identity ClientAssertionCredential avec le jeton d’identité managée comme fonction de rappel d’assertion. Le flux en six étapes et les exemples de configuration officiels montrent l’échange sans nécessiter d’exemple de code d’application spécifique à l’intégration.

Automatiser l’intégration et le départ

Encapsulez les quatre opérations d’intégration dans votre pipeline d’approvisionnement : créez l’enregistrement de l’application, créez son principal de service, configurez son approbation d’identité fédérée et accordez le rôle de l’espace de travail. Créez le parcours de départ correspondant en même temps : supprimez les allocations de ressources, révoquez la relation de confiance obsolète ou les informations d’identification et supprimez les identités d’application uniquement après avoir vérifié les dépendances.

Implémentation alternative : Authentification directe des identités de service

Si vous ne souhaitez pas utiliser MI et fédération, ignorez les étapes 1 et 3. Effectuez l’étape 2 pour chaque locataire et configurez des informations d’identification d’application prises en charge au lieu d’une approbation de confiance fédérée.

Utilisez un certificat lorsque cette option est prise en charge et suivez les instructions de configuration des informations d’identification de l’application. Chargez le certificat public, protégez la clé privée dans un magasin d’informations d’identification sécurisé et automatisez le renouvellement. Si un secret client est nécessaire, protégez-le et renouvelez-le avant l’expiration.

Effectuez l’étape 4 avec les mêmes autorisations client à privilèges minimaux. À l’étape 5, utilisez l’ID client du client et ses informations d’identification pour demander directement un jeton d’accès d’identifiants client. Conservez le même routage des clients, la séparation du cache de jetons, la validation et les contrôles de nettoyage de migration.

Sécurité, limitations et considérations

Appliquez les contrôles suivants à la méthode d’authentification que vous sélectionnez et tenez compte de ses limites de fonctionnement.

Recommandations de sécurité

• Utilisez une identité managée stable affectée par l’utilisateur. Cela évite de perdre des relations de confiance avec les clients simplement parce qu’une ressource de calcul est remplacée. N’utilisez pas d’identité affectée par le système comme source de l’assertion pour ce modèle de confiance d’application.

• Traitez l’application MI comme une identité hautement privilégiée. Il peut s’authentifier au nom de chaque application cliente qui lui fait confiance. Limitez les droits de déploiement des ressources de calcul, d’attribution d’identité gérée, de propriété des applications et d’administration des informations d’identification. Partitionnez les identités d’exécution si nécessaire pour réduire l’étendue de la compromission.

• N’accordez au MI aucune autorisation de service client qui lui soit propre. Il s’agit d’une source d’assertion ; les principaux du service client reçoivent l’espace de travail et les autorisations du service en aval.

• Définir les paramètres du locataire à l’aide d’un groupe de sécurité. Incluez tous les principaux de service concernés dans le groupe autorisé au lieu d’activer l’accès aux principaux de service pour l’ensemble de l’organisation.

• Surveillez et configurez des alertes sur les connexions de chaque identité de service. Mettre en corrélation avec les journaux d’activité des applications et des ressources. La collecte des journaux sans investigation spécifique au client ni génération d’alertes ne fournit pas l’avantage opérationnel.

• Automatisez l’intégration et le départ ensemble. La suppression des rôles d’espace de travail, la mise hors service des informations d’identification ou des relations d’approbation et la suppression des identités de service obsolètes doivent être aussi contrôlées et reproductibles que leur provisionnement.

Conservez les mappages de clients côté serveur, validez l’appartenance avant de sélectionner une identité et refusez les ID de ressource ou d’identité arbitraires fournis par le client. La réutilisation des jetons signifie qu’un enregistrement de connexion n’est pas un enregistrement de chaque appel d’API. Ne consignez pas les secrets, les assertions, les jetons d’accès ou les clés privées de certificat.

Limitations et exigences opérationnelles

Consultez Microsoft Entra limites de service et la prise en charge de l'identité d'API du service cible avant de finaliser la capacité et les autorisations.

Pour connaître les limites de confiance actuelles et le comportement de propagation, consultez les considérations relatives aux informations d’identification fédérées.

Pour connaître l’éligibilité actuelle aux politiques et les licences, consultez Accès conditionnel pour les identités de charge de travail.

Utilisez l’audience api://AzureADTokenExchangeglobal-cloud token-exchange, l’audience api://AzureADTokenExchangeUSGovdu gouvernement des États-Unis ou l’audience api://AzureADTokenExchangeChinade la Chine, le cas échéant. Faire correspondre le point de terminaison d’autorisation au cloud. Les exemples de cet article portent sur le cloud global.

Utilisez les bibliothèques d’identités prises en charge pour la mise en cache et l’actualisation des jetons. Autorisez la propagation de la confiance et des autorisations, réessayez les échecs temporaires avec délai de reprise limité et examinez les incompatibilités persistantes entre l’émetteur, le sujet ou l’audience. Pour l’authentification directe, effectuez une rotation des certificats et des clés secrètes avec une période de chevauchement et surveillez l’expiration.

Ne supposez pas que la suppression d’un profil, la suppression d’informations d’identification ou la modification d’une relation de confiance invalide instantanément les jetons émis précédemment. Tenez compte de la durée de vie des jetons et du comportement d’autorisation et de révocation de chaque service de ressources lors de la planification du basculement et de l’offboarding.

Contenu connexe

Utilisez ces références pour les autorisations spécifiques à l’API, les restrictions d’identité actuelles et la configuration de charge de travail existante.

Profils, identités de service et charges de travail existantes

• Mutualisation avec des identités de service dédiées
• Profils de principaux de service : solution multilocataire facultative
• Profils de principal de service pour les applications multilocataire
• Configurer une application de contenu existante pour utiliser un principal de service
• Paramètres du tenant développeur
• Vue d’ensemble de l’intégration d’analytique existante
• Aperçu de l’intégration du tableau de bord en temps réel pour utilisateur délégué

Fédération des identités de charge de travail et identité gérée

• Vue d’ensemble de la fédération des identités de charge de travail
• Considérations et restrictions importantes pour les informations d’identification d’identité fédérée
• Configurer une application pour approuver une identité managée
• Identités managées pour les ressources Azure
• Exemples de configuration de fédération

Kits de développement logiciel (SDK), API et limites de service

• Azure Identity ClientAssertionCredential pour .NET
• Référence de génération de jetons spécifique à l’application pour les charges de travail de plongement existantes
• Microsoft Entra limites et restrictions de service
• Identités d’application prises en charge pour les API REST Fabric
• Identité de connexion et sécurité Direct Lake
• Accès conditionnel pour les identités d'applications de service
• Opération d’attribution de rôle d’espace de travail
• API de gestion des profils