Note de la rédaction : Bienvenue dans le deuxième tutoriel pratique de la série « Comprendre et prévenir les attaques visant 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, commencez ici.
Lors de notre premier « Practice Checkpoint », vous avez appris à configurer l'identifiant d'agent (Agent ID) et à créer votre premier utilisateur agent.
Maintenant que les objets principaux existent, nous allons mettre en place le modèle d'autorisations tel qu'il apparaît dans les déploiements réels : des autorisations directes, réservées à l'application, sur l'identité de l'agent, et des autorisations déléguées accordées au niveau du blueprint et marquées comme héritables.
Ce point de contrôle définit les données d'entrée exactes que nous validerons ultérieurement dans les jetons au cours des processus d'authentification.
Attribuer une autorisation à l'identité de l'agent
Pour illustrer les autorisations « directes » propres à une application au niveau de l'identité de l'agent, attribuez un rôle d'application à <agent-identity-id> en utilisant le même appRoleAssignments selon le même schéma que précédemment.
Dans cette démo, le appRoleId représente User.Read.All. Nous l'utiliserons plus tard pour nous authentifier en tant qu'agent et pour répertorier les utilisateurs.

Configurer les autorisations héritables
Configurez les autorisations héritables afin que l'agent puisse hériter des périmètres délégués dans les flux délégués.
Étape 1 : Accorder l'autorisation déléguée
Créer un oauth2PermissionGrants enregistrement qui accorde Group.Read.All vers le modèle d'identité de l'agent (processus standard de consentement délégué).

Étape 2 : Le marquer comme héritable
Appelez le /applications/microsoft.graph.agentIdentityBlueprint /<agent identity blueprint id>/inheritablePermissions point de terminaison et incluez l'ID d'application de la ressource Graph. Utilisez une portée énumérée afin que l'identité de l'agent n'hérite que de la Group.Read.All autorisations.

Dans un scénario d'authentification déléguée, nous allons examiner et utiliser ces autorisations pour répertorier les groupes de locataires. Si vous souhaitez que toutes les autorisations soient héritées, il suffit de définir gentil à allAllowed au lieu de enumerated et supprimez la propriété « scopes ».
Bien que cela ne soit pas documenté, il est possible d'hériter des autorisations énumérées propres à l'application. Au lieu des champs d'application, nous utiliserons appRoleIds, qui nécessitent le GUID du rôle de l'application. La requête se présentera donc comme suit :

Vous pouvez également définir les deux en même temps. Pour mettre à jour les autorisations héritables existantes, envoyez une requête « Patch » à la ressource concernée que vous souhaitez mettre à jour.
Correctif : /applications/microsoft.graph.agentIdentityBlueprint//inheritablePermissions/
Prochaine étape : nous allons découvrir comment votre identité d'agent s'authentifie et fonctionne dans Entra ID.
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
