Identités des agents : analyse approfondie de la conception

Note de la rédaction: Bienvenue dans le chapitre 4 de « 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 les protéger contre les acteurs malveillants. Pour consulter les chapitres précédents et les exercices pratiques, cliquez ici.

Dans le chapitre précédent de ce guide complet consacré à la prévention des attaques visant l’identité des agents Entra ID, nous avons défini les objets fondamentaux qui composent le modèle Agent ID. En gardant à l’esprit ce modèle global — et, espérons-le, après avoir fait un petit détour pour nous exercer à créer un Agent ID avec MS Graph —, nous sommes prêts à approfondir notre compréhension de la structure des identités au sein de la plateforme Agent ID.

Reprenons là où nous en étions.

Découverte du modèle de données de Microsoft Graph

Pour comprendre comment les quatre éléments constitutifs de l'identité sont représentés dans la hiérarchie sous-jacente des données de Microsoft Graph, nous pouvons examiner le point de terminaison des métadonnées de Graph.

Microsoft Graph expose son modèle de données via le point de terminaison de métadonnées OData à l'adresse https://graph.microsoft.com/beta/$metadata. Lorsque vous y accédez, vous obtenez un document XML qui définit les types d’entités, les types complexes, les énumérations et les relations pris en charge par l’API. En termes plus simples, il s’agit de la carte structurelle de Microsoft Graph. Elle ne nous indique pas tout ce que la plateforme autorisera lors de l’exécution, mais elle nous montre comment Microsoft a choisi de modéliser les objets.

Microsoft explique que ces métadonnées aident les développeurs à comprendre le modèle de données et les relations entre les entités. Pour les chercheurs en sécurité, ce point de terminaison est extrêmement précieux car il met en évidence la hiérarchie d'héritage et les définitions de propriétés qui déterminent le comportement des objets Entra ID, y compris les nouveaux types d'Agent ID.

Cela dit, Agent ID reste une interface en constante évolution, et certains détails du schéma sont susceptibles de changer à mesure que la plateforme gagne en maturité.

Avant d'aborder les objets proprement dits, précisons qu'il existe deux concepts de métadonnées qu'il convient de distinguer : EntityType et ComplexType.

• Un EntityType représente généralement un objet pouvant faire l'objet d'une requête directement via son propre point de terminaison, qui possède des propriétés de navigation (relations avec d'autres entités) et qui peut être stocké, récupéré et mis à jour de manière indépendante. Voici quelques exemples de ce type d'entités : user, application, servicePrincipalet group.
• A ComplexType est un type de valeur structuré qui regroupe plusieurs propriétés. Il n'a pas d'identité propre ; il existe intégré à une entité (voire à une autre ComplexType) et ne peuvent pas faire l'objet d'une requête directe en tant qu'objet autonome. Voici quelques exemples de ces types : apiApplication, appRole, federatedIdentityCredentialet keyCredential.

Voyez les choses ainsi : un EntityType c'est comme une ligne d'une table de base de données, et un ComplexType est un objet JSON imbriqué dans cette ligne.

Dans la réponse des métadonnées XML, on peut voir le type d'entité de base abstrait dont héritent presque tous les types d'entités Graph (et c'est pourquoi presque toutes les ressources Microsoft Graph possèdent finalement une chaîne d'identification) :

La pièce suivante est la directoryObject entité, qui hérite de l'entité.

À partir de là, nous pouvons examiner servicePrincipal son type et sa structure.

Une interface utilisateur textuelle n'est, pour le moins, pas le format le plus lisible pour parcourir un document de métadonnées de 428 Ko ; nous avons donc rapidement développé une application web locale pour faciliter un peu la navigation parmi ces relations entre entités.

Désormais, au lieu d'essayer de comprendre le type d'entité « agentIdentity » en examinant ses métadonnées brutes :

… nous pouvons explorer visuellement la hiérarchie des objets et interagir avec les relations qui entourent chaque type de manière plus approfondie :

Les métadonnées nous indiquent que agentIdentity hérite de servicePrincipal (avec OpenType="true", ce qui signifie qu'il peut également exister des propriétés dynamiques ou non documentées) et ajoute le petit ensemble d'éléments spécifiques à l'agent suivant au niveau du sous-type :

• Deux propriétés :
  • agentIdentityBlueprintId (une chaîne de caractères obligatoire qui relie l'identité de l'agent à son modèle parent)
  • createdDateTime
• Trois propriétés de navigation :
  • sponsors (une liste de directoryObject)
  • inheritedAppRoleAssignments (une collection de appRoleAssignment)
  • inheritedOauth2PermissionGrants (une collection de oAuth2PermissionGrant)

Les deux derniers éléments ont été récemment ajoutés au schéma bêta et revêtent une importance particulière, car ils représentent le mécanisme d'héritage des autorisations de l'entité principale « Agent Identity Blueprint » vers l'identité de l'agent. Microsoft décrit ces attributions de rôles d'application héritées et ces autorisations déléguées comme des autorisations effectives appliquées au moment de l'émission du jeton.

C'est également là que la différence entre les « agents classiques » et les « agents modernes » dans Entra ID commence à se préciser.

• Les agents classiques, tels que ceux créés par Copilot Studio et Azure AI Foundry avant l'introduction du nouveau modèle d'identifiant d'agent, sont représentés en arrière-plan par des objets « service principal » classiques.
• Les agents modernes, en revanche, sont représentés par le nouveau agentIdentity sous-type.

Sachant cela, on comprend aisément pourquoi le filtrage par la colonne « Agent Blueprint ID » dans le portail Agent ID (version préliminaire) peut aider à distinguer ces deux univers. Les objets dont l’ agentIdentityBlueprintId relèvent du nouveau modèle d'identifiant d'agent, contrairement aux anciens agents basés sur des entités de service.

Il convient de noter que les métadonnées de la version 1.0 présentent actuellement une définition plus succincte du schéma, sans les deux inherited* propriétés de navigation sur agentIdentity. Ce genre d'écart entre la version bêta et la v1.0 est courant pour les fonctionnalités en avant-première, mais il a un réel impact sur la sécurité pour les responsables de la sécurité qui souhaitent évaluer agents Entra déjà intégrés au sein de leur organisation. Tout outil d'audit, produit CSPM ou script d'énumération des autorisations qui ne tient pas compte de ces relations d'autorisations héritées risque de ne pas refléter l'intégralité des autorisations effectives des objets d'identifiant d'agent.

Et si nous configurons des autorisations héritables sur un blueprint, que nous accordons le consentement d'administrateur à l'entité principale du blueprint et que nous interrogeons un agent qui lui est associé via différentes versions de l'API, cette faille devient visible.

Tout le reste — les plus de 40 propriétés et les plus de 20 propriétés de navigation issues du servicePrincipal objet — est hérité structurellement. Cela inclut des propriétés telles que keyCredentials, passwordCredentials, owners, federatedIdentityCredentialset memberOf.

C'est pourtant précisément là que ce schéma peut nous induire en erreur.

L'héritage OData décrit la structure du modèle d'objet. Il ne garantit pas que chaque fonctionnalité héritée soit effectivement disponible lors de l'exécution. La documentation de Microsoft le précise explicitement concernant les ressources liées à l'identifiant d'agent :

… bien que cette ressource hérite de `servicePrincipal`, certaines propriétés ne s'appliquent pas.

Les propriétés d'identification en sont l'exemple le plus parlant, car les identités d'agent ne disposent pas de leurs propres identifiants : ni mot de passe, ni certificat, ni secret client. Elles s'appuient sur le « blueprint » parent pour obtenir des jetons en leur nom ; toute tentative d'ajouter des identifiants directement à un objet d'identité d'agent est rejetée par l'API.

Ainsi, alors que keyCredentials et passwordCredentials apparaissent dans le schéma hérité, elles sont nulles ou vides pour les identités d'agent et sont donc de fait indisponibles. Cette contrainte ne provient pas du fichier de métadonnées lui-même. Elle provient des chemins de code de la logique d'exécution au niveau de la couche API, qui doivent reconnaître le sous-type et rejeter les opérations qui ne devraient pas s'appliquer.

La même chose vaut pour le agentIdentityBlueprintPrincipal objet, qui hérite également de servicePrincipal et n'ajoute que la relation « propriétaire » dans la définition de son sous-type. À l'instar de l'identité de l'agent, il hérite de l'ensemble complet des informations d'identification de servicePrincipal En théorie, mais dans la pratique, ses identifiants sont gérés via l'objet d'application « blueprint », et les opérations effectuées sur cet objet sont associées à des mesures de sécurisation spécifiques à chaque point de terminaison, à des vérifications dynamiques en temps d'exécution, etc.

C'est l'un des principes de sécurité les plus importants du modèle Agent ID : le schéma nous indique ce dont l'objet hérite, mais c'est à la plateforme qu'il revient de contrôler ce que l'objet est autorisé à faire.

La partie du problème liée à l'utilisateur

Les agentUser Cette entité suit le même modèle d'héritage que celui que nous avons examiné, mais cette fois-ci, elle se situe au-dessus de la user objet plutôt que servicePrincipal.

Et si l’ajout de sous-types d’agents à la surface de l’entité de service est une opération sensible, leur ajout à la surface de l’utilisateur est sans doute encore plus délicat. L’objet utilisateur touche aux politiques d’authentification, à la gestion des licences, aux fonctionnalités de collaboration, à l’appartenance à des groupes, à la structure organisationnelle et aux flux d’affectation administrative qui ont été initialement conçus autour des identités humaines.

En examinant les métadonnées, agentUser hérite de graph.user et n'ajoute aucune nouvelle propriété ni aucune nouvelle propriété de navigation au niveau du sous-type. En d'autres termes, chaque propriété et chaque documenté La relation d'un utilisateur-agent dépend du type de base d'utilisateurs.

Mais « zéro nouvel attribut » ne signifie pas qu’il n’y ait aucun signal distinctif.

Les identityParentId La propriété, qui relie l'utilisateur-agent à l'identité de son agent parent, est définie sur le type de base « utilisateur » lui-même. Pour les humain Pour les utilisateurs, cette propriété est toujours nulle, mais pour les utilisateurs agents, elle contient l'ID de l'objet correspondant à l'identité de l'agent associé et est obligatoire lors de la création. La documentation de Microsoft précise également que cette relation est immuable une fois établie et ne peut être ni supprimée ni modifiée.

Contrairement à ce qui se passe dans le agentIdentity et agentIdentityBlueprintPrincipal En ce qui concerne les objets, Microsoft a fait ici un choix architectural consistant à faire remonter la propriété distinctive au type parent plutôt que de la définir au niveau du sous-type, ce qui signifie que les métadonnées OData ne suffiront pas à elles seules à nous indiquer que agentUser est autre chose qu'un utilisateur et que le seul indicateur au niveau du schéma est le @odata.type discriminateur sur l'objet lui-même.

Cette distinction est importante en raison de la fonction pour laquelle les utilisateurs-agents ont été conçus. Contrairement aux identités d'agent, qui sont des objets dérivés d'un principal de service et dont l'authentification s'effectue via des flux de jetons réservés aux applications, les utilisateurs-agents sont spécifiquement destinés aux contextes où une identité à l'image de l'utilisateur est requise.

En termes de jetons, ils reçoivent des jetons avec le idtyp=user une autorisation, ce qui signifie qu’ils peuvent accéder à des API et à des services qui vérifient spécifiquement la présence d’un jeton d’utilisateur plutôt que d’un jeton d’application (Outlook, Teams, SharePoint et tout autre service dont l’accès dépend du type d’identité), ce qui leur permet de disposer de boîtes aux lettres, de rejoindre des canaux Teams et d’apparaître dans les organigrammes. Une vision de l’assistant personnel basé sur l’IA dans toute sa splendeur.

Microsoft a répertorié plusieurs contraintes de sécurité concernant les identités des utilisateurs des agents :

• Ils ne peuvent pas avoir de mots de passe ni de clés d'accès.
• On ne peut pas leur attribuer de rôles d'administrateur privilégiés.
• Ils n'ont pas accès aux attributions de rôles personnalisées ni aux groupes auxquels on peut attribuer des rôles.
• Leur modèle d'autorisation par défaut est similaire à celui des utilisateurs invités, avec des capacités légèrement plus étendues pour répertorier les utilisateurs et les groupes.

Ce sont là des mesures de sécurité importantes. Mais chacune d’entre elles doit être appliquée au niveau de l’API et des règles, individuellement, pour chaque chemin d’exécution du code qui interagit avec un user objet.

C'est là que ça se complique. Si un terminal traite agentUser comme un simple user et s'il oublie d'appliquer les restrictions spécifiques au sous-type, le résultat n'est pas seulement un bug. Cela peut devenir un problème lié aux limites des privilèges.

Par exemple, malgré le contraintes officielles en matière de sécurité En ce qui concerne l'attribution des rôles privilégiés, lors des tests, nous avons pu attribuer des rôles d'agent à des utilisateurs 3 sur 32 les rôles marqués d'un isPrivileged=true:

• Global Reader : accès en lecture à l'ensemble du répertoire et des données Microsoft 365
• Security Reader : accès en lecture aux outils de sécurité, à Microsoft Defender et à Identity Protection
• Administrateur IA : contrôle administratif des fonctionnalités liées à l'IA et aux agents

Nous avons également pu attribuer de nombreux rôles qui ne sont pas signalés comme privilégiés (ou qui sont considérés comme standardAssigned) mais qui, dans la pratique, relèvent en réalité du niveau 0, comme les administrateurs de facturation, les administrateurs Exchange, les administrateurs SharePoint et les comptes de synchronisation d'annuaire.

Ce phénomène n'est pas nouveau, et il ne se limite pas aux identités des agents.

L’octroi excessif de droits au rôle « AI Administrator » et^{la découverte concernant Silverfort¹ dont} nous avons parlé dans le chapitre précédent en sont les exemples les plus récents, mais ils s’inscrivent dans une lignée bien documentée de « lacunes de périmètre » d’Entra ID. Dans ces cas, une autorisation ou un rôle qui semble s’appliquer à une classe d’objets plus restreinte finit par atteindre un type de base plus large ou une surface de contrôle plus sensible que prévu. Les chemins classiques d’escalade des privilèges des administrateurs d’applications et des administrateurs d’applications cloud en sont des exemples par excellence.

Documenté de manière exhaustive par Dirk-jan Mollema²et SpecterOps,³ Ces voies d'escalade exploitent le fait que les rôles peuvent ajouter des identifiants à tous entité de service dans le locataire. Si une entité de service dispose d'autorisations d'application à fort impact, telles que RoleManagement.ReadWrite.Directory ou AppRoleAssignment.ReadWrite.All—ou à qui des rôles de répertoire privilégiés ont été attribués—l'ajout d'identifiants à ce service peut permettre à l'attaquant de s'authentifier en tant que ce principal de service et d'hériter de ses privilèges effectifs.

La question de la portée est ici subtile ; le rôle est décrit en toute honnêteté comme consistant à gérer des applications. L’hypothèse dangereuse réside dans le fait que « gérer des applications » ne devrait pas signifier également « être capable de prendre le contrôle de n’importe quel entité de service disposant de privilèges élevés ». Microsoft a par la suite introduit des contrôles de verrouillage des propriétés des instances d’application afin de réduire en partie ce risque, mais le problème sous-jacent reste important : le contrôle d’un objet peut se transformer en contrôle des autorisations déjà associées à cet objet.

Étude 2024 de Semperis sur UnOAuthorized a mis en évidence une autre variante de ce schéma. Plusieurs entités de service propriétaires de Microsoft (vous vous souvenez de ce type dans la taxonomie?) pouvaient être utilisées par les administrateurs d’applications et les administrateurs d’applications cloud pour ajouter et supprimer des utilisateurs de rôles privilégiés. Le problème ne se résumait pas simplement à un « excès de droits » dans l’abstrait. Il s’agissait d’un décalage entre les limites prévues pour les rôles et la manière dont les périmètres OAuth 2.0 et les entités de service propriétaires étaient évalués dans la pratique.

De même, Datadog Je vois⁴Les informations publiées à partir de 2025 ont révélé une nouvelle variation. Dans certains scénarios, les entités de service disposant des rôles « Administrateur d’applications cloud », « Administrateur d’applications » ou Application.ReadWrite.All pourrait détourner l'entité de service Exchange Online d'Office 365 en y ajoutant des identifiants. Dans les environnements hybrides, cela pourrait se traduire, via une relation de confiance de domaine fédérée, par un accès d'administrateur global. Une surface d'attaque différente, mais la même leçon : les autorisations limitées aux « applications » peuvent devenir bien plus dangereuses lorsque l'application ciblée est elle-même une entité de confiance privilégiée.

Et la vulnérabilité « Actor Token » découverte par Dirk-jan^{Mollema⁵, CVE-2025-55241}, bien que structurellement différente, s’inscrit dans la même grande famille. Dans ce cas précis, des jetons d’usurpation d’identité inter-services internes non documentés, combinés à une faille de validation des locataires dans l’ancienne API Azure AD Graph, ont permis l’usurpation d’identité inter-locataires de n’importe quel utilisateur, y compris les administrateurs globaux, sans journalisation ni application de l’accès conditionnel. La faille de périmètre se situait ici au niveau de la limite du locataire plutôt qu’à celle du sous-type d’objet, mais la leçon fondamentale reste la même : lorsqu’une primitive privilégiée est introduite sans validation stricte à chaque point d’accès, l’un de ces points finit inévitablement par devenir une voie d’accès.

Alors, qu'est-ce que tout cela signifie ?

Eh bien, tout d'abord, cet « Agent ID » n'est pas un nouveau type d'objet isolé. Il s'agit d'un nouveau modèle d'identité qui s'appuie sur des éléments de base qu'Entra ID connaît déjà très bien : les applications, les entités de service, les utilisateurs, les autorisations OAuth, les attributions de rôles d'application, les identifiants d'accès et les rôles d'annuaire.

D'autre part, cette conception est certes pratique, mais elle implique également que le modèle de sécurité repose sur un élément plus délicat. La hiérarchie du schéma des métadonnées peut nous indiquer ce dont un objet hérite, mais seul le comportement en exécution nous permet de savoir quelles capacités héritées sont effectivement accessibles.

C'est là que réside la tension fondamentale d'Agent ID : Microsoft accorde aux agents IA une place de premier plan au sein d'Entra ID, mais pour ce faire, il étend des types d'objets qui revêtent depuis des années une importance particulière en matière de sécurité. Chaque propriété héritée, chaque action de rôle, chaque flux de jetons et chaque point de terminaison entre désormais en ligne de compte.

Avant d'aborder la manière dont on peut détourner, protéger ou surveiller les identités d'agent, il faut donc d'abord comprendre la nature même de ce concept.

Et maintenant, espérons-le, cette image est un peu plus claire.

Bon, parlons des autorisations

La plateforme Agent ID introduit de nouveaux types d’identités capables d’effectuer des actions de manière autonome, d’agir au nom des utilisateurs et de disposer d’autorisations persistantes. Il est essentiel de bien comprendre leur modèle d’autorisation pour empêcher l’escalade des privilèges et éviter les chemins d’accès involontaires ayant un impact important. Ce modèle introduit également un nouveau concept d’autorisation héréditaire, qu’il est nécessaire de bien comprendre.

Autorisations réservées aux applications et autorisations déléguées

Tout comme les applications classiques et les entités de service, les modèles d'identité d'agent et les identités d'agent peuvent se voir attribuer des autorisations propres à l'application ou des autorisations déléguées.

Comme nous l'avons vu précédemment, le modèle d'identité de l'agent dispose toujours d'une autorisation réservée à l'application — AgentIdentity.CreateAsManager—par défaut, ce qui lui permet de créer et de gérer les identités des agents.

En ce qui concerne les identités d'agent, les autorisations « réservées à l'application » doivent être utilisées lorsque l'agent fonctionne de manière entièrement autonome. Les autorisations déléguées s'appliquent lorsqu'un utilisateur intervient dans le flux de travail et que l'agent doit agir en son nom.

Autorisations héritables

Les autorisations héritables constituent une configuration d'héritage des autorisations définie au niveau du modèle d'identité d'agent. Elles permettent aux identités d'agent créées à partir de ce modèle d'hériter automatiquement des autorisations approuvées du modèle, au lieu de devoir obtenir séparément le même consentement pour chaque identité d'agent.

À l'origine, cela concernait principalement les autorisations déléguées, mais la documentation actuelle de Microsoft indique désormais que les autorisations héritables prennent en charge à la fois les portées déléguées et les rôles d'application. Les portées déléguées apparaissent dans le jeton d'accès délégué de l'identité de l'agent dans le scp réclamation, tandis que les rôles d'application apparaissent dans le jeton d'accès réservé à l'application dans le roles allégation.

Pour que les autorisations héritables prennent effet, la configuration du modèle ne suffit pas à elle seule. Deux conditions doivent être remplies :

• L'application de ressource concernée doit être configurée dans le blueprint’s inheritablePermissions.
• L'autorisation doit également être accordée au principal du blueprint.

Microsoft décrit cela comme la différence entre la déclaration, l'octroi et l'héritage : inheritablePermissions Il s'agit d'une configuration, tandis que c'est le consentement au niveau de l'entité principale du modèle qui accorde l'autorisation.

Cela signifie que le allAllowed Ce paramètre ne doit pas être interprété comme signifiant que « l’agent obtient automatiquement toutes les autorisations exposées par l’application-ressource ». Cela signifie que toutes les autorisations éligibles de ce type, pour cette application-ressource, qui sont accordées à l’entité principale du modèle, peuvent être transmises aux identités des agents. Le jeton effectif correspond alors à la fusion des autorisations héritées et de toutes les autorisations accordées directement à l’identité spécifique de l’agent.

La configuration s'effectue via l'application de ressources ; les portées déléguées et les rôles d'application peuvent être configurés indépendamment pour une même ressource. Par exemple, un modèle peut hériter de portées déléguées mais pas de rôles d'application ; il peut hériter de rôles d'application mais pas de portées déléguées. Les exemples fournis par Microsoft illustrent cela à l'aide de inheritableScopes et inheritableRoles séparément.

Pour que les autorisations déléguées et héritables prennent effet, l'entité de service du blueprint doit déjà disposer des OAuth2PermissionGrants entrées pour ces domaines, après obtention d'un consentement au niveau du schéma directeur.

En ce qui concerne les autorisations déléguées, les modèles d'héritage de portée documentés sont les suivants :

• allAllowed: Ces modèles héritent de toutes les portées déléguées disponibles pour la ressource qu’ils ont attribuée.
• noScopes: Ces modèles n'héritent d'aucune portée déléguée pour cette application de ressources.
• enumerated: Ces modèles, qui n'apparaissent que dans la documentation de l'API bêta, ne comprennent que les champs d'application spécifiés dans la liste. Lorsque vous utilisez le modèle énuméré, vous pouvez inclure jusqu'à 40 champs d'application par application de ressource.

En ce qui concerne les autorisations des applications, les modèles d'héritage réservés aux applications actuellement documentés sont les suivants :

• allAllowed: Ces modèles héritent de toutes les portées d'application disponibles pour l'application-ressource à laquelle ils ont accordé l'accès.
• noRoles: Ces modèles n'héritent d'aucun rôle d'application pour cette application-ressource.

Or, la documentation officielle ne mentionne aucune option spécifique à l'héritage « app-only ». Cependant, après avoir effectué quelques tests, nous avons constaté que cette option pouvait être intégrée au processus d'héritage « app-only ».

Le schéma suivant illustre le principe des autorisations déléguées, énumérées et héritables. Un schéma similaire s'appliquerait aux autorisations propres à l'application, qui fonctionnent de manière très similaire. (Les différences seront présentées dans le point de contrôle pratique n° 2.)

Un modèle peut définir des autorisations transmissibles à un maximum de 60 applications de ressources. Cette limite ne s'applique pas uniquement aux modèles.

Il est également important de noter que certaines autorisations Microsoft Graph à haut risque sont bloquées pour les identités d'agent. Microsoft précise que les portées d'autorisation déléguées ou les rôles d'application bloqués ne peuvent pas être accordés aux identités d'agent, et que l'inclusion d'une portée déléguée ou d'un rôle d'application bloqué entraîne le rejet de la requête.

Les autorisations héritables sont facultatives. Même sans y recourir, il est toujours possible d'accorder des autorisations directement à chaque identité d'agent individuellement. La différence réside dans le fait que les autorisations accordées directement ne s'appliquent qu'à cette identité d'agent spécifique, tandis que les autorisations héritables permettent à un administrateur d'approuver les autorisations une seule fois au niveau du modèle, afin que les autorisations éligibles soient transmises aux identités d'agent actuelles et futures créées à partir de ce modèle.

Appartenance à un groupe (réservé aux utilisateurs agents)

L'appartenance à un groupe est réservée aux utilisateurs agents. Les utilisateurs agents peuvent être ajoutés à des groupes de sécurité, mais pas à des groupes auxquels on peut attribuer des rôles. Ils héritent des autorisations liées à leur appartenance à un groupe, tout comme les utilisateurs standard.

Rôles Microsoft Entra

Des rôles d’annuaire Microsoft Entra peuvent être attribués aux identités d’agent, à l’instar des entités de service, mais avec des restrictions importantes. Les rôles dotés de privilèges élevés, tels que « Administrateur global », « Administrateur de rôles privilégiés » et « Administrateur d’utilisateurs », ne peuvent pas être attribués aux identités d’agent. Seul un sous-ensemble défini de rôles Microsoft Entra est pris en charge, et certains de ces rôles restent de nature administrative ; ils doivent donc être attribués avec prudence, en fonction de l’objectif visé par l’agent et des exigences en matière de principe du moindre privilège.

La liste complète des rôles pris en charge est disponible ici.

Forfait d'accès

Outre l'attribution directe d'un accès à un identifiant d'agent, les organisations peuvent utiliser des packages d'accès. Un package d'accès permet à un agent ou à un ensemble d'agents ayant les mêmes besoins d'accéder à des ressources. Les packages d'accès peuvent inclure des rôles Entra, des appartenances à des groupes de sécurité, des autorisations déléguées OAuth2 et des autorisations d'application — éléments que nous avons tous décrits précédemment.

Les packages d'accès sont configurés par un administrateur, qui définit :

• Quelles sont les ressources incluses ?
• Qui est autorisé à demander l'accès ?
• Qui doit autoriser l'accès ?
• Durée de l'accès
• Et d'autres paramètres de politique

Un agent peut demander lui-même un ensemble d'accès, ou bien un parrain ou un responsable peut en faire la demande en son nom. Celui-ci peut également être attribué directement par l'administrateur. Une fois la demande approuvée, l'agent bénéficie d'un accès limité dans le temps aux ressources incluses, et un parrain peut demander une prolongation si nécessaire.

Faire le point sur les autorisations

Pour résumer le modèle d'autorisations, chaque composant de la plateforme Agent ID peut disposer de ses propres autorisations. Les identités d'agent peuvent détenir des autorisations propres à une application ou des autorisations déléguées ; les utilisateurs d'agent peuvent faire partie de groupes ; et les modèles d'identité d'agent peuvent définir des autorisations héritables qui sont transmises à chaque identité d'agent créée à partir de ces modèles. En fonction du processus d'authentification, les éléments concernés sont combinés lors de l'exécution.

Dans le cas d'un flux « Au nom de », associé aux nouvelles autorisations héritables, les autorisations finales de l'agent se présenteront comme suit :

Un flux similaire est prévu lorsque l'on utilise les autorisations « réservées à l'application » avec des autorisations héritables. Il suffit de remplacer tous les termes délégués par des termes « réservés à l'application ».

Suivant : Exercice sur la configuration des autorisations d'identité des agents

Faites maintenant un petit détour par notre deuxième point de contrôle pratique et suivez les étapes pour attribuer des autorisations à l'identité d'agent que vous avez configurée lors du premier exercice.

Entraînez-vous à définir les autorisations relatives à l'identité des agents.

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
• Point de contrôle n° 2 : Configuration des autorisations d’identité des agents

Notes de fin d'ouvrage

1. https://www.silverfort.com/blog/agent-id-administrator-scope-overreach-service-principal-takeover-in-entra-id/
2. Élévation de privilèges dans Azure AD – Prise de contrôle des autorisations par défaut d'une application en tant qu'administrateur d'application – dirkjanm.io
3. Élévation des privilèges sur Azure via l'exploitation d'une entité de service – SpecterOps
4. I SPy : escalade vers l'administrateur global d'Entra ID via une application propriétaire | Datadog Security Labs
5. Vulnérabilité liée au jeton « Actor »