Note de la rédaction : Bienvenue dans le quatrième et dernier tutoriel pratique de la série « Comprendre et prévenir les attaques ciblant l’identité des agents Entra ID : guide complet ». Ce guide technique en plusieurs parties vous aide à comprendre l’approche de Microsoft en matière d’identités d’agents et à découvrir comment vous pouvez les protéger contre les acteurs malveillants. Pour revoir les chapitres précédents et les leçons pratiques, cliquez ici.
Au chapitre 5 de notre guide, vous avez découvert et vous vous êtes exercé à utiliser le registre des agents de Microsoft, et vous avez suivi pas à pas les étapes de trois flux d'authentification d'identité d'agent dans Entra ID.
Dans ce « Practice Checkpoint », nous allons vérifier les trois flux dont nous avons parlé en les suivant chacun de bout en bout via Microsoft Graph et en affichant les revendications réelles des jetons à chaque étape afin de relier tous les éléments entre eux.
Par souci de cohérence et de clarté, nous continuerons à utiliser l'identité d'agent que nous avons créée lors des étapes précédentes et nous examinerons les jetons générés à l'issue de chaque flux.
Voici un bref récapitulatif des informations dont vous avez besoin :
- ID du plan = 3534ec06-21ea-4080-abd4-95116e260203
- ID du plan SP = 17a48807-f813-421b-85b9-8c7e794bc4b9
- Identifiant de l'agent: b85d92be-fa90-486b-94ed-b5ad91d35ceb
- Identifiant de l'agent utilisateur = 2954440b-1617-46b1-9156-dad15f1f824f
- Autorisations déléguées héritables = Group.Read.All
- Autorisations directes réservées à l'application au niveau de l'identité de l'agent = User.Read.All
Débit autonome
Dans ce flux, c'est l'identité de l'agent elle-même qui doit accéder à une ressource.
Pour commencer, nous devons obtenir le jeton T1. Cette procédure est similaire à celle permettant d'obtenir un jeton d'accès pour un modèle d'identité d'agent, mais présente deux différences majeures :
- champ d'application =
api://AzureADTokenExchange/.default - inclure fmi_path =
<agent-identity-id>
Nous pouvons décoder le jeton T1, dans lequel :
- Les cartes « oid » correspondent à l'identifiant SP du schéma.
- « azp » correspond à l'ID du modèle d'identité de l'agent.
- aud appartient à l'application « AAD Token Exchange Endpoint », qui est
api://AzureADTokenExchange.
À l'aide du jeton T1, nous pouvons désormais obtenir le jeton d'accès d'identité de l'agent.
En examinant le jeton Graph, on constate que :
- La revendication en question concerne Microsoft Graph.
- L'appid, tout comme l'entité oid, correspond à l'identifiant de l'agent.
- Les rôles la réclamation porte notamment sur
User.Read.Allautorisation, que nous avons attribuée précédemment et directement associée à l'identité de l'agent en tant qu'autorisation réservée à l'application.
À ce stade, l'identité de l'agent peut appeler Graph dans le tenant conformément à ses autorisations réservées à l'application.
Flux « au nom de »
Dans ce flux, l'identité de l'agent effectue des actions déléguées en tant qu'utilisateur et illustre les portées de délégation transmissibles.
Pour commencer, nous devons obtenir un jeton client (TC). Pour cela, nous devons d'abord définir les champs d'application des autorisations OAuth2 sur le blueprint, puis donner mon consentement en tant qu'utilisateur.
Dans un deuxième temps, nous allons créer une application SAP via l'interface utilisateur.
Nous allons ajouter les autorisations Blueprint que nous venons de créer à notre application DemoSAP :
Pour cette démonstration, nous autoriserons également le flux client public :
Nous pouvons désormais obtenir un jeton TC. Le ClientID correspond à l'identifiant de l'application que nous venons de créer :
Ensuite, nous devons passer en revue les demandes de consentement habituelles prévues.
Cela renverra le jeton TC qui m'appartient en tant qu'utilisateur. On constate que la revendication « aud » correspond à l'identifiant du Blueprint :
Nous pouvons désormais récupérer le jeton T1 en utilisant la même méthode que celle que nous avons déjà employée.
Avant de poursuivre, nous devons donner notre consentement afin que l'identité de l'agent puisse agir au nom de notre utilisateur, à l'aide d'un appel OAuth2PermissionGrants standard avec la portée que nous avons définie comme autorisations héritables.
Si vous avez déjà donné votre accord pour « AllPrincipals » dans la section « Configuration des autorisations héritables », vous pouvez ignorer cette étape.
Enfin, en utilisant à la fois les jetons TC et T1, nous pouvons obtenir le jeton d'accès (TR).
Le jeton d'accès décodé indique :
- Droit SCP associé aux autorisations « Group.Read.All » héritables que nous avons ajoutées précédemment au niveau du modèle.
- le nom d'affichage de l'application et la revendication « appid », qui identifient l'agent agissant pour le compte de l'utilisateur.
- Les revendications « idtyp », « name » et « oid » appartiennent toutes à l'utilisateur (car il s'agit d'un jeton délégué).
Parcours utilisateur de l'agent
Ce flux s'adresse à un utilisateur agent qui doit effectuer des actions en fonction du contexte de l'utilisateur.
Comme pour le flux autonome « agent-identity », nous devons obtenir un jeton T1.
Ensuite, nous devrions donner notre consentement pour permettre à l'identité de l'agent d'agir au nom de l'utilisateur de l'agent, comme nous l'avons fait dans le flux OBO.
Cette fois-ci, nous allons spécifier l'ID utilisateur de l'agent comme ID du principal. Si vous avez déjà donné votre accord pour « AllPrincipals » dans la section « Configuration des autorisations héritables », vous pouvez ignorer cette étape.
À présent, à partir du jeton T1, nous pouvons obtenir le jeton T2.
Le jeton T2 décodé révèle les revendications « azp », « oid » et « sub », toutes définies sur l'identifiant de l'agent.
En utilisant à la fois les jetons T1 et T2, nous pouvons obtenir le jeton d'accès TR.
Comme on peut le constater, ce jeton d'accès a été émis pour Microsoft Graph. Il indique :
- La revendication « idtyp » correspond à un utilisateur
- La réclamation « oid » correspond à l'identifiant utilisateur de l'agent
- La variable « appid » est définie sur l'identifiant de l'agent, qui est le parent de l'utilisateur de l'agent.
- scp contient le
Group.Read.All, les lunettes que nous avons ajoutées tout à l'heure.
Vous disposez désormais d'une identité d'agent opérationnelle. Comment la protéger ?
La création de votre identité d'agent au cours de ces sessions pratiques devrait vous avoir permis de comprendre concrètement comment les agents travailleront dans votre instance Entra ID.
Lisez maintenant le dernier chapitre de notre guide pour avoir un aperçu des problèmes qui peuvent survenir — et découvrir comment protéger ces nouvelles identités.
Découvrez comment éviter une catastrophe au chapitre 6.
Découvrez le guide
- Introduction : Comprendre et prévenir les attaques d'usurpation d'identité de l'agent Entra ID : un guide complet
- Chapitre 1 : Découvrez les identités des agents d’Entra ID (au fait, ce ne sont pas des personnes)
- Chapitre 2 : La taxonomie des identités de charge de travail dans Entra ID : applications d’entreprise, entités de service et autres formes de confusion organisée
- Chapitre 3 : Comprendre l'identifiant Microsoft Agent et la plateforme d'identité Agent
- Point de contrôle n° 1 : Création d'un identifiant d'agent avec MS Graph
- Chapitre 4 : Identités des agents : analyse approfondie de la conception
- Point de contrôle n° 2 : Configuration des autorisations d’identité des agents
- Chapitre 5 : Le registre des agents et le fonctionnement des identités d’agents dans Entra ID
- Point de contrôle n° 3 : Enregistrement d’un agent — avec et sans identifiant d’agent
- Chapitre 6 : Les risques liés aux identités d’agents dans Entra ID — et comment éviter la catastrophe
