Semion Vasilevitzky et Jonathan Elkabas

Note de la rédaction : Bienvenue au chapitre 6 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 vous pouvez les protéger contre les acteurs malveillants. Pour consulter les chapitres précédents et les exercices pratiques, commencez ici.

La plateforme Agent ID introduit de nouveaux types d’identité et de nouveaux modèles opérationnels. Cette fonctionnalité n’en étant qu’à ses débuts, les erreurs de configuration et les vecteurs d’attaque concrets commencent tout juste à apparaître. Dans cette section, nous ne chercherons pas à passer en revue tous les risques ou faiblesses possibles. Nous mettrons plutôt en évidence un petit ensemble d’erreurs de configuration simples mais importantes, qui risquent de se généraliser à mesure que les organisations adopteront Agent ID à grande échelle.


À qui appartient cet agent ? Identifiants d'agent sans propriétaire ni parrain

Les identités d'agents non gérées (celles qui n'ont ni propriétaire ni parrain) créent une lacune en matière de gouvernance des identités. En l'absence de personne ou d'équipe désignée comme responsable, ces identités associées aux charges de travail risquent davantage d'être négligées lors des audits et de passer inaperçues lors de la gestion des incidents.

Sur la page de présentation des identifiants d'agent Entra, on peut voir le nombre d'identités d'agent non gérées.

Figure 1. Affichage des identités d'agents non gérés dans la vue d'ensemble des identifiants d'agents Microsoft

Bien qu'il faille indiquer au moins un parrain lors de la création d'une identité d'agent, il est tout de même possible que certaines identités se retrouvent sans parrain au fil du temps. Cette situation peut par exemple se produire si un utilisateur qui faisait office de parrain a été supprimé, par exemple après avoir quitté l'organisation.

Une autre situation similaire, qui n'apparaît toutefois pas sur la page de synthèse, se produit lorsque le compte du parrain ou du propriétaire est désactivé. Dans ces cas-là, l'identité de l'agent semble avoir un propriétaire ou un parrain attribué, mais le compte associé n'est plus actif au sein de l'organisation. L'identité se retrouve alors en quelque sorte « orpheline » et peut facilement échapper à l'attention des administrateurs.

Dans l'idéal, chaque identité d'agent devrait toujours être placée sous la responsabilité d'une personne physique active, consciente de sa finalité. Garantir une prise en charge continue constitue un élément essentiel de la gouvernance des identités.

Dans Semperis Lightning Intelligence et Directory Services Protector DSP)— deux solutions qui font partie de la Identity Resilience Platform— nous signalons déjà ces deux situations. Grâce à un tableau de bord clair, vous pouvez voir non seulement le nombre d’identités d’agents non gérées, mais aussi la liste exacte de celles-ci.

Figure 2. Affichage des identités des agents non gérés sur la plateforme Semperis

Vous pouvez également consulter la liste des identités d'agents « orphelins » dont il a été question, ainsi que les sponsors ou propriétaires précis qui ont été désactivés et qui, dans la pratique, ont rendu ces identités d'agents « orphelines ».

Figure 3. Identification des sponsors et des propriétaires des agents désactivés

Qui connaît mon secret ? Modèles d'utilisation des secrets client

Comme nous l’avons décrit précédemment dans le point de contrôle pratique n° 1 de ce guide, un secret client est l’un des types d’identifiants pouvant être attribués à un modèle d’identité d’agent. Ce type d’identifiant est considéré comme faible, car il est souvent stocké dans des fichiers de configuration, des scripts, des pipelines CI/CD ou des dépôts de code source, où il risque d’être divulgué par inadvertance. Si un attaquant parvient à mettre la main sur un secret client, il peut s’authentifier en tant que ce modèle d’identité d’agent ou en tant que les identités d’agent qui y sont associées, sans avoir besoin d’une connexion interactive ni d’une authentification multifactorielle (MFA).

Microsoft met explicitement en garde contre le fait que :

Les secrets client ne doivent pas être utilisés comme identifiants client dans les environnements de production pour les modèles d'identité d'agent, en raison des risques de sécurité que cela comporte.

Microsoft recommande plutôt d'utiliser des identifiants fédérés (FIC) avec des identités gérées ou des certificats pour l'authentification.

Les indicateurs Semperis vous permettent de suivre l'ensemble des modèles d'identité des agents contenant des secrets depuis un emplacement centralisé et d'identifier précisément les identifiants mal configurés dans chaque modèle.

Figure 4. Visibilité sur les informations d'identification mal configurées du modèle d'identité de l'agent

Un pouvoir excessif : les identités d'agents jouissant de privilèges exceptionnels

Jusqu’à présent, nous avons expliqué comment les agents obtiennent des autorisations réservées aux applications ou déléguées, et comment s’effectue l’attribution des rôles dans ce modèle. Bien que Microsoft limite les autorisations et les rôles pouvant être attribués aux identités d’agent, il reste essentiel d’appliquer le principe du moindre privilège.

Les autorisations à privilèges élevés associées à une identité d'agent augmentent le risque, même en l'absence de tout attaquant. Les identités d'agent peuvent s'exécuter automatiquement et effectuer des actions à grande échelle. Si un agent est mal configuré, se comporte de manière inattendue ou est mal intégré dans un flux de travail, ces privilèges élevés peuvent transformer une simple erreur en un incident touchant l'ensemble du tenant. Du point de vue de la sécurité, les identités d'agent dotées de privilèges excessifs élargissent la surface d'attaque et constituent une cible pour les attaquants.

Les administrateurs de l'organisation doivent vérifier régulièrement les autorisations attribuées aux identités d'agent et les limiter au strict minimum nécessaire au bon fonctionnement de l'agent.

Les indicateurs Semperis vous permettent de visualiser en un seul endroit les identités des agents disposant de privilèges élevés ainsi que leurs rôles précis associant des privilèges excessifs.

Figure 5. Identification des rôles dotés de privilèges excessifs

Conclusions

Les « identités d’agent » ne sont pas simplement une case à cocher de plus dans le centre d’administration de Microsoft Entra. Elles constituent la tentative de Microsoft de doter les agents IA d’une identité formelle au sein de l’annuaire. Il ne s’agit pas d’un vague objet d’automatisation, ni simplement d’une entité de service endossant un nouveau rôle. Il s’agit d’un nouveau modèle d’identité qui vise à représenter les agents comme des entités que la plateforme peut reconnaître, gérer, autoriser et auditer.

Et cela a son importance, car dès qu’un agent doit franchir une frontière de système, appeler une API, lire des données organisationnelles, mettre à jour un état, envoyer un message, accéder à une boîte aux lettres ou agir au nom d’une entité plus grande que lui-même, il cesse d’être uniquement une « logique d’IA ». Il devient un participant au système d’identité. Il a besoin d’un principal. Il a besoin d’autorisations. Il a besoin d’un jeton. Il a besoin d’une place dans l’annuaire.

Agent ID est la solution proposée par Microsoft pour répondre à ce besoin.

Au cœur de ce modèle se trouve l’« Agent Identity Blueprint », le modèle à partir duquel les identités d’agent sont créées et par lequel les autorisations héritées peuvent être transmises. Autour de celui-ci, Microsoft a introduit plusieurs objets associés : les identités d’agent, les utilisateurs d’agent, les entités de référence du modèle et les agents hérités adossés à une entité de service. Ensemble, ils forment une nouvelle couche opérationnelle pour les agents IA au sein d’Entra ID.

Mais comme nous l'avons vu tout au long de ce guide, l'Agent ID ne surgit pas de nulle part. Il s'appuie sur les primitives existantes d'Entra ID, et ces primitives sont déjà assorties d'une structure, de droits d'accès, d'hypothèses et d'un héritage historique.

Les identités d'agent héritent de celles des entités de service. Les utilisateurs d'agent héritent de celles des utilisateurs. Les modèles (blueprints) héritent de celles des applications. Les autorisations sont gérées via les mécanismes habituels d'OAuth et d'attribution de rôles aux applications. L'application des rôles repose toujours sur les actions RBAC, les vérifications via l'API et le comportement en exécution. Les noms sont nouveaux, mais le plan de contrôle sous-jacent reste très familier.

Et pour être honnête, c'est à la fois la force (opérationnelle) et le risque (de sécurité) de ce modèle.

Cela signifie que l'Agent ID peut s'intégrer naturellement à Entra ID, à Microsoft Graph, aux journaux d'audit, aux autorisations d'application et aux flux d'administration existants. Mais cela signifie également que chaque fonctionnalité héritée, chaque hypothèse implicite et chaque ancien problème de périmètre redevient pertinent dans un nouveau contexte.

Les identités d'agent introduisent une nouvelle surface d'attaque, et il faut s'attendre à ce que de nouvelles voies d'attaque apparaissent à mesure que les organisations commencent à les adopter. Certaines proviendront probablement de modèles dotés de droits d'accès excessifs. D’autres résulteront de délimitations de rôles floues. D’autres encore proviendront d’autorisations héritées que les responsables de la sécurité n’ont pas encore correctement répertoriées. D’autres seront dues au fait que des utilisateurs d’agents interagissent avec des interfaces initialement conçues pour des utilisateurs humains. D’autres encore seront liées à l’accès conditionnel et au comportement des jetons, qui nécessitent encore des tests pratiques plus approfondis. Et enfin, comme toujours, certaines proviendront d’endroits insignifiants que personne n’a examinés, car le portail et la documentation les faisaient paraître inoffensifs.

L'important est de ne pas considérer les agents comme quelque chose de magique ou de distinct de ce que nous connaissons déjà, car ce sont des identités.

Et les identités s'authentifient, obtiennent des autorisations, effectuent des actions et laissent des traces derrière elles. Le bon vieux cycle AAA porte désormais un masque aux allures d'IA.

S'il y a donc une leçon concrète à retenir de cette analyse, c'est bien celle-ci.

Ne vous arrêtez pas à la désignation du portail ou au tableau de documentation. Suivez le modèle d'objet. Suivez la hiérarchie d'héritage. Suivez le jeton. Suivez les autorisations. Suivez les actions liées aux rôles. Suivez les journaux d'audit et de connexion. Le comportement réel de la plateforme se révèle généralement quelque part entre ce que décrit le schéma, ce que promet la documentation et ce que le moteur d'exécution autorise réellement.

À mesure que l’Agent ID continue d’évoluer, les questions épineuses ne seront pas uniquement d’ordre technique. Il s’agira de questions de confiance : quel niveau d’accès sommes-nous prêts à accorder à ces identités, dans quelle mesure pouvons-nous suivre clairement leurs activités, et dans quelle mesure la plateforme est-elle capable de faire respecter les limites qui leur sont imposées une fois qu’elles commenceront à fonctionner à grande échelle ?

Car les agents ne sont pas simplement du code s'exécutant discrètement en arrière-plan. Il s'agit d'un code doté d'autonomie, revêtu d'une identité, disposant de droits d'accès, prenant des décisions et franchissant des limites au nom de quelqu'un ou de quelque chose d'autre.

Et dès lors que le code dispose d’autonomie, d’identité et de confiance, il devient bien plus qu’une simple « automatisation ».

Elle devient une volonté déléguée au sein du système, porteuse de nos autorisations, de nos hypothèses et, à terme, de nos conséquences.


Ne vous fiez pas à vos suppositions : scannez. Comment Semperis peut-il vous aider ?

Les outils Semperis permettent déjà d’identifier les lacunes en matière de gouvernance, de mettre en évidence les points de vulnérabilité potentiels et de contribuer à faire émerger ce type de erreurs de configuration et de risques. Ce domaine est encore en pleine évolution, et chez Semperis, nous travaillons déjà à la mise au point d’indicateurs de vulnérabilité supplémentaires et de capacités de détection plus approfondies qui seront progressivement mis en place.

À mesure que vous étendrez l'utilisation des identités d'agent dans vos systèmes d'identité, vous vous poserez certainement de nouvelles questions à chaque étape. N'hésitez pas à nous contacter à tout moment ; nous sommes là pour vous aider.


Pour en savoir plus


Découvrez le guide