La taxonomie des identités de charge de travail dans Entra ID : entités de service, applications d'entreprise et autres formes de confusion organisée

C'est à ce stade que notre guide aborde des aspects plus techniques ; prenons donc le temps de les passer en revue attentivement.

Commençons par le commencement : pour faire simple, le terme « identité de charge de travail » est un concept générique utilisé par Microsoft pour désigner plusieurs types d’identités non humaines qui opèrent au sein d’Entra ID. Ces identités permettent aux applications, aux services, aux ressources cloud, aux charges de travail d’automatisation — et désormais aux agents —de s’authentifier et d’interagir avec d’autres systèmes avec peu ou pas d’intervention humaine.

Voici le point essentiel : toutes les identités de charge de travail, y compris les nouveaux types d'identité d'agent, se résument finalement à un seul type d'objet sous-jacent : le « Service Principal ».

Et franchement, c'est tout à fait logique.

Comment appréhender les « Service Principals » ?

Les servicePrincipal L'entité est sans doute l'objet d'identité le plus polyvalent d'Entra ID. Si vous consultez son schéma via le point de terminaison OData $metadata de Microsoft Graph, le nombre de propriétés, de propriétés de navigation et d'actions liées exposées par cet objet en dit déjà long sur son rôle au sein de la plateforme.

Ce service principal « Foundation » accomplit ici un travail considérable, bien que discret. Il est connecté à de nombreuses interfaces et sous-systèmes gérés par Entra ID afin de prendre en charge des fonctionnalités telles que la gestion des identifiants, l’octroi d’autorisations OAuth, l’attribution de rôles aux applications, l’appartenance à des groupes, la propriété, l’évaluation de l’accès conditionnel, les mécanismes RBAC, l’audit et la journalisation des connexions.

Ainsi, lorsque Microsoft a développé les identités d'agent, l'entreprise n'a pas choisi de créer une primitive d'identité entièrement nouvelle à partir de zéro, mais plutôt d'en étendre une existante.

Comme l'indique la documentation, les deux agentIdentity¹ et agentIdentityBlueprintPrincipal² les objets (que nous aborderons plus en détail dans un chapitre ultérieur) sont types spécialisés des entités de service qui représentent des instances d'identité d'agent au sein de l'écosystème Microsoft Entra ID. Concrètement, cela signifie qu'elles reprennent l'architecture existante des entités de service, y compris ses avantages, sa compatibilité avec les API existantes et, bien sûr, une partie de sa complexité.

C'est là que l'architecture entre en jeu en matière de sécurité.

Un bon exemple en est la^{découverte³} publiée il y a peu par l'équipe de Silverfort.

Lorsque Microsoft a introduit le rôle « Agent ID Administrator » pour gérer le nouveau plan de contrôle des identités d’agents, celui-ci était présenté comme étant strictement limité aux objets liés aux agents. Dans la pratique, cette limite n’a pas été respectée. Les identités auxquelles seul ce rôle était attribué pouvaient prendre le contrôle de principes de service arbitraires, y compris ceux qui n’avaient aucun rapport avec les identités d’agents, en s’ajoutant elles-mêmes en tant que propriétaires, en ajoutant des informations d’identification au principe de service, puis en s’authentifiant en tant que ce principe.

Il s'agit d'une reprise de contrôle total.

La cause première probable correspond exactement au modèle décrit ci-dessus.

Si agentIdentity et agentIdentityBlueprintPrincipal les objets sont implémentés par-dessus le servicePrincipal fondation, la couche d'autorisation doit alors distinguer de manière fiable les entités de service soutenues par un agent des entités de service « classiques ». Cette distinction doit être appliquée de manière explicite.

C'est en partie pour cette raison que Microsoft a introduit de nouveaux rôles liés aux répertoires (administrateur d'identifiants d'agent, développeur d'identifiants d'agent et administrateur du registre des agents) ainsi que des rôles de gestion spécifiques aux objets (propriétaire, promoteur et gestionnaire) parallèlement au nouveau modèle d'identité des agents.

D'un point de vue conceptuel, ces rôles sont censés gérer la nouvelle surface spécifique à l'agent :

• Identités des agents
• Principes fondamentaux de l'identité des agents
• Modèles d'identité des agents
• Utilisateurs de l'agent

Leur autorité devrait être limitée au modèle d'agent, et non à chaque entité de service du locataire.

À titre d'anecdote intéressante et assez longue , le modèle RBAC visible ne présente pas toujours clairement l'ensemble de la surface de l'agent. Actuellement, la documentation de Microsoft relative à l'Agent ID Administrator fait référence aux « Actions » liées à l'agent au sens large ; il s'agit d'entrées d'autorisation qui définissent les opérations qu'un rôle d'annuaire est autorisé à effectuer sur des types de ressources spécifiques.

En s'appuyant sur la documentation officielle, Silverfort a émis l'hypothèse (à juste titre !) que des actions telles que microsoft.directory/agentIdentities/owners/update et microsoft.directory/agentIdentityBlueprintPrincipals/owners/update a fuité du rôle intégré vers le plan de contrôle général des entités de service.

Cependant, lors d'une requête sur la définition du rôle en temps réel via Microsoft Graph, les informations visibles allowedResourceActions semblent se concentrer uniquement sur agentUsers/*.

Et en énumérant les éléments déclarés microsoft.directory Les actions relatives aux ressources présentent le même écart : 18 entrées liées aux agents, toutes sous agentUsers/*. Aucun pour les sous-types de la couche « service principal » (agentIdentities/*, agentIdentityBlueprintPrincipals/*et agentIdentityBlueprints/*). Ce qui revient en gros à dire qu'aucun rôle ne les prévoit.

Une remarque quelque peu similaire s'applique au rôle d'administrateur IA.

Contrairement au poste d’« Agent ID Administrator », qui semble correspondre à une fonction très spécifique dédiée à la gestion du plan de contrôle des identifiants d’agent, celui d’« AI Administrator » est beaucoup plus susceptible d’être confié à un large éventail de collaborateurs. Ses responsabilités, telles qu’elles sont décrites, portent principalement sur Microsoft 365 Copilot, les services d’IA, les agents Copilot, les analyses d’utilisation, l’état de santé des services et les opérations d’assistance.

En d'autres termes, cela ressemble davantage à un poste dédié aux opérations d'IA qu'à un contrôle total sur le plan d'identité sous-jacent d'Agent ID.

Mais dans la pratique, ce rôle semble disposer de capacités de plan de contrôle liées à l’Agent ID pratiquement identiques à celles de l’Administrateur Agent ID. Les 17 opérations que nous avons testées ont toutes abouti à des résultats identiques pour les deux rôles. Cela signifie que toute personne détenant le rôle d’Administrateur Agent ID peut prendre possession de n’importe quelle identité d’agent au sein du tenant, associer des identifiants à n’importe quel blueprint et hériter de toutes les autorisations d’application que les administrateurs ont accordées à ces blueprints.

Bien que ces deux rôles soient décrits de manière légèrement différente, allowedResourceActions, et bien qu'ils héritent tous deux de la base « Directory Readers » dont héritent presque tous les rôles privilégiés (ce qui représente 55 actions en lecture seule), la différence réelle se limite aux actions suivantes :

Ces détails ne figurent pas dans le rapport Silverfort lui-même, mais ils sont utiles pour replacer les choses dans leur contexte. Ils montrent qu’une partie du plan de contrôle de l’identité des agents n’est pas représentée sous la forme d’un vocabulaire RBAC clair et entièrement visible. Une partie des autorisations relatives aux objets liés aux agents semble être appliquée à un niveau plus profond de la couche API (par exemple, des mesures de renforcement de sécurité par point de terminaison, des remplacements liés à l’identifiant de modèle, des vérifications dynamiques en temps d’exécution). Cela explique également pourquoi les objets d’application n’ont pas été affectés, car la faille ne concernait pas la gestion des droits de propriété.

Ce qui nous ramène à la question de la sécurité.

L'héritage confère aux systèmes d'identité leur flexibilité, leur cohérence et leur réutilisabilité. Mais en l'absence de limites précises de portée, il peut également étendre la surface d'attaque à tous les objets concernés.
Cependant, la hiérarchie d'héritage n'est qu'une variante du modèle d'entité de service. Outre le fait qu'elles partagent la même architecture d'objets sous-jacente, les entités de service sont également classées logiquement en différents types d'identité.

Types d'entités de service logiques — et leurs limites

Au cours de l'année écoulée, j'ai eu l'occasion de voyager et de présenter EntraGoat, un laboratoire open source délibérément vulnérable que nous avons mis au point chez Semperis afin de partager et de mettre en pratique des scénarios d'attaques d'identité réels dans Microsoft Entra ID.

Les retours ont été très positifs, mais ce qui m'a le plus marqué, ce sont les discussions qui ont suivi. Un thème revenait sans cesse : les applications et les « service principals » sont bien plus complexes qu'il n'y paraît à première vue.

Nous espérons donc ici décortiquer cette complexité et faire la lumière sur les attaques dont ces identités font l'objet.

Le type d'un principal de service peut être identifié grâce à la servicePrincipalType propriété enum, qu’Entra ID a attribué en interne pour indiquer la catégorie logique de l’identité.

Selon Microsoft, documentation relative à la servicePrincipal type de ressource, ce champ peut contenir cinq valeurs principales :

• Application
• ManagedIdentity
• Héritage
• SocialIdp
• ServiceIdentity

D'après mon expérience, ces identités comptent parmi les objets les plus puissants d'Entra ID, puisqu'elles se trouvent souvent au cœur des chemins d'accès critiques.

Il est essentiel de comprendre comment ces types d'entités de service se comportent, d'où ils proviennent, comment ils s'authentifient et en quoi ils diffèrent les uns des autres pour saisir le fonctionnement interne d'Entra ID.

Comprendre les 5 principales valeurs des entités de service dans Entra ID

Commençons par répertorier les types d'entités de service logiques dans l'environnement d'identité des charges de travail.

Un grand merci à Eric Woodruff, architecte en chef de l'identité chez Semperis, pour avoir mis en lumière cette taxonomie et nous l'avoir présentée.

Applications

Comme le montre le schéma des identités de charge de travail ci-dessus, le premier groupe à créer des entités de service dans un tenant Entra ID est constitué des applications que nous utilisons et connaissons tous, telles que Microsoft Teams, Salesforce ou des systèmes développés en interne, comme un portail RH.

Un objet « Application » représente la définition globale d'une application. Il est créé dans le locataire où l’application a été initialement créée (visible dans l’interface utilisateur des enregistrements d’applications ) et sert de modèle ou de gabarit définissant la configuration d’identité de l’application, notamment les URI de redirection, les autorisations API requises, les informations d’identification et d’autres paramètres. Cela signifie que l’objet décrit comment le fournisseur d’identité (IdP) peut émettre des jetons permettant aux clients d’accéder à l’application, les ressources auxquelles l’application pourrait avoir besoin d’accéder, ainsi que les actions ou autorisations que l’application peut effectuer au sein d’un locataire.

Pour permettre tout cela et l'intégrer, et comme vous pouvez le constater dans le point de terminaison de l'API $metadata, l'objet « application » est lui aussi un objet complexe (et très pertinent pour les identités des agents !) comportant de nombreuses propriétés et méthodes différentes.

A Objet « Service Principal » avec servicePrincipalType : application représente l'instance de cette application au sein d'un locataire spécifique et peut être consultée dans le Applications d'entreprise UI. Il s'agit du principe de sécurité qu'Entra ID utilise concrètement lors des processus d'authentification et d'autorisation.

L'entité de service permet à l'application de se connecter ou d'accéder à des ressources au sein de ce répertoire et stocke des données spécifiques au locataire, telles que les autorisations accordées, le consentement de l'administrateur et les attributions de rôles d'application. En d'autres termes, l'entité de service est l'objet qui obtient des jetons, dispose d'autorisations, apparaît dans les journaux de connexion—et qui est la cible des attaques.

Quelle est la différence entre les applications et les entités de service ?

D'après notre expérience, la distinction entre les objets d'application et les objets d'entité de service est l'un des concepts les plus souvent mal compris dans Entra ID.

Pour tenter de clarifier cette différence, nous avons répertorié ci-dessous des exemples qui montrent comment ces deux notions sont liées tout en restant très distinctes. N’hésitez pas à parcourir rapidement les points si vous connaissez déjà le sujet.

• Un objet d'application n'existe que dans son tenant d'origine.
• Une application à locataire unique dispose d'exactement un principal de service, qui n'existe que dans ce même locataire (d'origine).
• Lorsqu'une application multi-locataires est acceptée dans un locataire externe, seul un entité de service y est créé, et aucun objet d'application.
• Les appId La propriété (ID d'application / ID client) identifie la définition de l'objet d'application et correspond à unique au niveau mondial pour l'ensemble des locataires d'Entra ID. Il est attribué lors de la création et ne change jamais.
• Les appId La propriété d'un entité de service correspond toujours à la appId de l'objet d'application correspondant. C'est pourquoi une même application propriétaire (telle que Microsoft Graph) partage le même appId pour l'ensemble des locataires à travers le monde.
• Chaque entité de service dispose de son propre id (ID d'objet) qui est unique au sein du tenant dans lequel il se trouve.
• Les attributions de rôles d'application et les autorisations OAuth2 sont attribuées à l'entité de service, et non à l'objet d'application ; ainsi, deux locataires peuvent donner leur consentement à la même application avec des périmètres d'autorisation totalement différents.
• Les identifiants ajoutés directement à une entité de service ne s'appliquent qu'à ce locataire spécifique et ne peuvent pas être utilisés en dehors de celui-ci.
• Les informations d'identification ajoutées à l'objet d'application sont héritées par toutes les entités de service dans chaque locataire où l'application a reçu l'autorisation, ce qui ouvre la voie à un vecteur d'attaque inter-locataires.
• La suppression d'un objet « service principal » dans un locataire n'a aucune incidence sur l'objet d'application (ni sur les objets « service principal » des autres locataires), car le cycle de vie de chaque objet « service principal » est indépendant.
• La suppression de l'objet d'application dans le tenant d'origine entraîne automatiquement la suppression de l'entité de service de ce tenant, mais ne supprime pas les entités de service des autres tenants (celles-ci restent en place jusqu'à ce qu'elles soient explicitement supprimées).
• Jusqu'au 1er avril 2026, et dans certains cas particuliers, il était possible d'utiliser une application sans créer d'entité de service ; toutefois, cette « authentification sans entité de service » ne devrait plus être prise en charge.

Types d'objets d'application

Tous les entités de service associées à une application relèvent généralement de l'une des trois catégories logiques d'applications suivantes.

Identification des types d'applications

Les applications propriétaires de Microsoft sont des applications détenues et gérées par Microsoft qui fournissent des services Azure et M365 tels qu’Exchange Online, SharePoint, Microsoft Graph et des centaines d’autres. Elles apparaissent dans votre tenant lorsqu’un utilisateur donne son consentement, qu’un administrateur leur accorde l’accès ou que Microsoft les provisionne automatiquement lors de l’activation d’un service ou d’une licence (comme E5, Defender ou Intune).

Pour identifier ces types d'identités de charge de travail, il suffit de consulter le appOwnerOrganizationId Propriété GUID d'un objet d'entité de service. Dans les applications officielles de Microsoft, cette propriété est généralement définie sur l'ID de locataire de Microsoft (f8cdef31-a31e-4b4a-93e4-5f571e91255a), bien que certains utilisent d'autres identifiants de locataire appartenant à Microsoft.

Il est important de comprendre que, bien qu’ils puissent apparaître dans les journaux de connexion, la plupart des entités de service propriétaires sont masquées par défaut dans le volet « Applications d’entreprise » de l’interface utilisateur du Portail Azure, mais restent accessibles via l’API Graph.

En effet, le volet de l'interface utilisateur effectue un filtrage sur le WindowsAzureActiveDirectoryIntegratedApp balise, qui identifie généralement les applications intégrées à Entra ID ; toutefois, les entités de service propriétaires de Microsoft n’en disposent pas (intentionnellement).

De plus, les applications propriétaires de Microsoft fonctionnent à l'aide de mécanismes d'autorisation internes qui vont au-delà des champs d'application OAuth standard, ce qui signifie que leurs autorisations effectives peuvent dépasser celles qui sont visibles via les octrois d'autorisation et ne peuvent pas être entièrement vérifiées à l'aide de requêtes standard de l'API Graph.

Le type d'objets d'application qui s'ensuit logiquement est celui de vos propres applications, c'est-à-dire les applications d'inscription.

Il s'agit d'applications enregistrées directement par des administrateurs ou des développeurs via l'interface « Enregistrement d'applications ». Dans ce cas, l'organisation est propriétaire de l'objet « application » et peut contrôler entièrement sa configuration, ses identifiants et ses autorisations. Une entité de service correspondante est automatiquement créée dans le tenant d'origine lors de l'enregistrement.

Pour répertorier les entités de service créées à partir d'applications enregistrées par notre organisation, de la même manière que nous filtrons les applications natives de Microsoft, nous pouvons énumérer toutes les entités de service dont appOwnerOrganizationId est défini sur l'identifiant de notre locataire.

Le dernier type d'application logique est celui des applications tierces/de la galerie.

Il s'agit d'applications SaaS intégrées via la Microsoft Entra App Gallery, telles que Salesforce, ServiceNow ou Zoom. Comme indiqué précédemment dans ce chapitre, lorsqu'une de ces applications est autorisée pour un locataire, un entité de service (faisant référence à l'objet d'application multi-locataires du fournisseur) est créé localement.

Pour identifier les entités de service créées par des applications tierces, c'est-à-dire des applications qui n'ont pas été enregistrées dans notre locataire et qui n'appartiennent pas à Microsoft, il suffit d'exclure à la fois l'identifiant de notre locataire et celui de Microsoft de l'ensemble complet des entités de service côté client (puisque Microsoft Graph ne prend pas en charge ne filtres activés appOwnerOrganizationId).

Exploit d'application

Comme nous l'avons déjà dit (probablement trop souvent à présent), chacun de ces trois types d'application instancie un objet « service principal » local dans votre tenant. Le « service principal » correspond à l'identité d'exécution : il contient les autorisations accordées, la configuration SSO et les paramètres spécifiques au protocole qu'Entra ID applique au moment de l'authentification.

En examinant le preferredSingleSignOnMode À partir de la propriété de l'objet « service principal », Entra ID détermine quel protocole SSO l'application utilise. Les valeurs possibles sont les suivantes :

• saml : L'application utilise SAML 2.0, Entra ID faisant office de fournisseur d'identité et émettant des assertions SAML signées.
• oidc : L'application utilise OpenID Connect / OAuth 2.0, le protocole moderne basé sur des jetons.
• mot de passe : authentification unique (SSO) par mot de passe, dans laquelle Entra ID saisit les identifiants dans le formulaire de connexion de l'application au nom de l'utilisateur.
• notSupported : Aucune authentification unique (SSO) n'est configurée via Entra ID.
• null : Indique des applications SAML ou OIDC plus anciennes pour lesquelles la valeur n'a pas été définie automatiquement ; également utilisé pour d'autres types logiques d'entités de service (comme nous le verrons dans un instant).

Du point de vue de la sécurité, le mode SSO a des implications directes. Les applications SAML s'appuient sur un certificat de signature de jetons configuré sur l'entité de service elle-même. Si un attaquant parvient à se procurer la clé privée de ce certificat, il peut falsifier des assertions SAML et s'authentifier en tant que n'importe quel utilisateur auquel l'application fait confiance.

Les chercheurs de Semperis ont illustré ce scénario précis dans leur article de blog intitulé « Meet Silver SAML : Golden SAML in the Cloud », en démontrant que l'importation d'un certificat de signature généré en externe dans une entité de service (plutôt que d'utiliser le certificat auto-signé intégré à Entra ID) crée un vecteur d'attaque exploitable qui ne nécessite aucune interaction avec Entra ID.

Essayez-le vous-même dans EntraGoat

Comme rien ne permet mieux d’illustrer l’influence des « service principals » sur le paysage actuel des menaces liées à l’identité que de les observer en action dans un environnement de laboratoire, plusieurs des voies d’escalade de privilèges les plus significatives d’EntraGoat — le laboratoire Entra ID délibérément vulnérable que nous avons mis en place ici chez Semperis — s’articulent entièrement autour de ces éléments.

Les scénarios varient quant à leur point de départ et à leur méthode, mais le schéma reste délibérément le même : il suffit de trouver un moyen d'accéder à une entité de service liée à une application pour que le chemin menant à une compromission à l'échelle du tenant soit souvent plus court que ce à quoi on pourrait s'attendre.

Si vous souhaitez découvrir le processus dans son intégralité, EntraGoat est un bon point de départ. Pour en savoir plus et suivre les tutoriels, consultez notre série d'articles de blog.

Identités gérées

Les identités gérées constituent, en quelque sorte, la tentative de Microsoft de résoudre un problème que nous avons nous-mêmes créé : la gestion des identifiants.

Toute identité, et en particulier toute identité non humaine, qui s'authentifie à l'aide de secrets client (mots de passe, clés d'accès ou certificats) pose un défi lié au cycle de vie de ce secret (rotation, stockage, expiration et fuite). La mise en œuvre des identités gérées a cherché à éliminer ce fardeau en transférant entièrement la gestion des informations d'identification vers le plan de contrôle Azure. L'identité existe ; elle s'authentifie, mais aucun être humain ne touche (ni ne manipule de manière inappropriée) les informations d'identification qui lui sont associées.

Types d'identités gérées

Toute ressource prenant en charge l'authentification Entra ID (telle qu'une machine virtuelle, un service d'application, une application logique, un cluster Kubernetes, ainsi que de nombreux autres services et types de ressources Azure) peut utiliser des identités gérées pour obtenir des jetons et accéder à d'autres ressources.

Il en existe deux types :

• Les identités gérées attribuées par le système sont créées dans le cadre et le contexte de la ressource Azure elle-même. La relation est strictement de type 1:1. Une ressource, une identité, un cycle de vie. L'identité ne peut pas exister de manière indépendante, ne peut pas être partagée et est automatiquement supprimée lorsque la ressource est supprimée. Ce couplage étroit constitue également son principal avantage en matière de sécurité.
• Les identités gérées attribuées par l'utilisateur, quant à elles, constituent des ressources Azure autonomes. Elles peuvent être associées à une ou plusieurs ressources, et leur cycle de vie est indépendant de celui des ressources qui les utilisent. Ce découplage propre à l'identité gérée attribuée par l'utilisateur constitue un avantage opérationnel, mais représente naturellement un compromis en matière de sécurité.

Identification des identités gérées

L'identification des entités de service représentant des identités gérées dans Entra ID est assez simple. Il suffit d'interroger l'annuaire pour obtenir les servicePrincipalType propriété définie sur ManagedIdentity.

En arrière-plan, ces deux types d'identité s'authentifient via des points de terminaison gérés par Azure, tels que le Service de métadonnées d'instance (IMDS) à 169.254.169.254—ou via des points de terminaison d’identité exposés par des services tels qu’App Service et Functions. Le processus d’obtention du jeton se déroule entièrement au sein d’Azure ; aucune information confidentielle n’est transmise par le réseau et aucune information d’identification n’est stockée dans Key Vault (ou pire encore, dans appsettings.json), ni même mises à la disposition des développeurs.

Contrairement aux entités de service associées à une application, les identités gérées ne sont pas liées à un objet d'application dans l'annuaire ; il n'y a donc ni enregistrement d'application, ni manifeste, ni URI de redirection. Elles ne sont pas non plus visibles par les utilisateurs et ne participent à aucun protocole d'authentification unique (SSO).

Vous vous souvenez du preferredSingleSignOnMode propriété dont nous avons parlé précédemment ? Nous espérons que vous comprenez désormais pourquoi cette propriété, ainsi que d’autres propriétés spécifiques à l’authentification, sont généralement nulles pour les identités gérées. En effet, celles-ci ne s’authentifient pas via SAML, OIDC ou des flux basés sur un mot de passe. À la place, Azure émet et gère des certificats d’une durée de validité de 90 jours, qu’il renouvelle tous les 45 jours, pour chaque identité gérée.

Ces certificats sont délivrés par Microsoft.ManagedIdentity et d'inclure l'ID d'objet de l'entité du service d'identité gérée dans le sujet du certificat. Azure s'en sert pour effectuer une authentification basée sur un certificat et émettre des jetons directement via son plan de contrôle, sans exposer les identifiants au locataire (ni à ses administrateurs).

On peut observer une partie de ce mécanisme à travers le keyCredentials propriété de l'objet d'entité de service de l'identité gérée.

Contrairement aux entités de service associées à une application, où keyCredentials Alors qu'il contient généralement des certificats téléchargés par un administrateur ou un développeur, les identités gérées voient leurs informations d'identification de clé entièrement renseignées et renouvelées par Azure.

Et lorsque l'on interroge cette propriété, on constate en effet qu'elle affiche un AsymmetricX509Cert entrée dont le paramètre « Usage » est défini sur « Verify », et dont l'ID de l'objet principal du service correspond au sujet du certificat.

Cette conception est élégante, jusqu'à ce qu'on l'examine du point de vue d'un pirate.

Exploits liés aux identités gérées

Il existe deux types distincts d'abus qu'il est utile de comprendre, car ils montrent comment le modèle commence à s'assouplir lorsque la théorie se heurte aux exigences de la réalité.

Le premier est le vol de jetons via la ressource associée.

Étant donné que les identités gérées s'authentifient via des points de terminaison locaux (IMDS ou le point de terminaison d'identité de la plateforme), tout sujet disposant d'un accès (c'est-à-dire capable d'exécuter du code sur la ressource sous-jacente) peut demander un jeton au nom de l'identité gérée.

Il s'agit là du vecteur d'attaque classique, largement documenté :

1. Compromettre un utilisateur ayant accès à une machine virtuelle / un registre de conteneurs / Arc / AKS / des comptes d'automatisation / des services d'applications / des Logic Apps / des scripts de déploiement / Data Factory
2. Interroger le point de terminaison des jetons d'une manière ou d'une autre (Invoke-WebRequest 169.254.169.254/metadata/identity/oauth2/token)

Si cette opération renvoie un résultat, vous disposez désormais d'un jeton OAuth valide, dont la portée correspond aux autorisations dont dispose cette identité pour utiliser les API Azure.

Bien que cette technique s'applique aussi bien aux identités gérées attribuées par le système qu'à celles attribuées par l'utilisateur, la surface d'attaque varie directement en fonction du contexte de l'identité.

Dans le cas d'identités gérées attribuées par l'utilisateur et partagées entre plusieurs ressources, une seule identité compromise peut être utilisée pour demander des jetons pour toutes les ressources sur lesquelles elle dispose d'autorisations. Un cas d'école de mouvement latéral.

Ou, comme cela est brièvement expliqué sur Microsoft Learn:

La limite de sécurité des identités gérées pour les ressources Azure correspond à la ressource sur laquelle l'identité est utilisée. Tout code ou script s'exécutant sur une machine virtuelle peut demander et récupérer des jetons pour toutes les identités gérées disponibles sur celle-ci.

Le deuxième type d'abus concerne l'utilisation abusive des identifiants fédérés, qui sape le modèle de confiance sur lequel reposent les identités gérées.

Comme nous l'avons vu il y a un instant, les identités gérées attribuées par l'utilisateur ne prennent pas en charge la configuration d'informations d'identification traditionnelles ; il est explicitement interdit de modifier ces propriétés sur l'entité de service représentant l'identité gérée dans Entra ID. Elles prennent toutefois en charge les informations d'identification fédérées. Celles-ci permettent à des fournisseurs d'identité externes (tels que GitHub Actions ou tout émetteur conforme à la norme OIDC, y compris un émetteur auto-hébergé) de s'authentifier en tant qu'identité gérée sans aucun échange de secrets.

Nous n'allons pas trop nous attarder ici sur les détails de mise en œuvre, car ce chapitre s'est déjà suffisamment éloigné du sujet, mais d'un point de vue général, cela peut se faire en créant un federatedIdentityCredential objet sur l'entité de service de l'identité gérée via l'API ARM, en spécifiant une URL d'émetteur OIDC et un identifiant de sujet.

Ensuite, au moment de l'authentification, Entra ID valide le jeton externe par rapport à l'émetteur configuré et vérifie la correspondance avec la revendication relative au sujet. Cependant, il ne vérifie pas la propriété entre l'émetteur et le locataire ou la ressource de l'identité gérée.

Cela signifie que tout directeur disposant de la Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write Une action dans le cadre des autorisations RBAC d'Azure (qui comprend plusieurs rôles intégrés tels que « Contributeur », « Propriétaire » et « Contributeur d'identité gérée ») permet d'ajouter un nouvel identifiant fédéré pointant vers un référentiel externe ou un environnement qu'il contrôle.

Une fois ces informations d'identification configurées, l'attaquant s'authentifie depuis son propre workflow GitHub (ou tout autre environnement conforme à la norme OIDC), reçoit un jeton valide pour l'identité gérée et opère avec l'ensemble complet de ses autorisations (entièrement depuis l'extérieur des limites de la ressource Azure).

Dans les deux cas, le problème fondamental est le même : les identités gérées ont été conçues pour éliminer le risque lié aux identifiants à l'intérieur d'une limite de ressource, mais le modèle d'autorisation propre à Azure permet à toute personne disposant d'un accès RBAC suffisant d'étendre cette limite (ou de la contourner complètement).

L'identité est destinée à exister au sein d'un contexte d'exécution spécifique, mais l'accès à celle-ci ne se limite pas toujours à ce contexte. Dans le premier cas, elle peut être usurpée en obtenant l'exécution de code sur une ressource à laquelle l'identité gérée est associée. Dans le second cas, elle peut être usurpée par le biais d'une relation de confiance fédérée qui ne nécessite absolument aucune connexion réelle à la ressource Azure d'origine.

Identités « Legacy » et « SocialIdp »

Les deux types d'identités de principal de service suivants sont « Legacy » et « SocialIdP ». Ces deux types étant moins pertinents au regard de l'objectif principal de ce guide, nous ne les aborderons que brièvement.

Le type « Legacy » désigne les anciennes applications créées avant la mise en place du modèle moderne d'enregistrement des applications, ou via des interfaces héritées. Le appId Cette propriété existe, mais ne renvoie pas à un enregistrement d'application. Une entité de service héritée peut toujours disposer d'informations d'identification et d'URL de réponse que les administrateurs peuvent gérer directement ; elle ne peut être utilisée que dans le locataire où elle a été créée.

Le type SocialIdp est décrit par Microsoft comme étant « à usage interne » ; il existe donc peu d’informations publiques à son sujet. D’après son nom et son contexte d’utilisation, il désigne probablement des fournisseurs d’identité sociale (tels que Google ou Facebook) configurés pour les flux utilisateur B2C. En pratique, ce type permet à B2C de s’intégrer à des fournisseurs sociaux externes, mais vous n’interagirez généralement pas directement avec lui, sauf si vous travaillez avec des politiques personnalisées B2C.

ServiceIdentity : le type d'entité de service pour les agents

Cela nous amène à la toute dernière catégorie de cet écosystème : ServiceIdentity, le modèle d'identité mis en place pour prendre en charge les opérations numériques basées sur des agents.

Les identités d'agent s'appuient sur deux concepts fondamentaux d'Entra ID : l'objet « Application » et l'objet « Service Principal ». C'est pourquoi, pour comprendre le fonctionnement des identités d'agent et leur « potentiel », nous avons d'abord dû comprendre les différents modèles dont elles héritent.

D'une manière générale, le agentIdentityBlueprint, qui est un sous-type d'application, définit le modèle d'agent et contient les informations d'identification. Le agentIdentity, un sous-type de servicePrincipal avec des biens immobilierservicePrincipalType fixé à ServiceIdentity, est l'objet d'exécution propre à chaque agent qui obtient les autorisations et interagit avec les ressources.

Cette distinction est importante car les identités d'agent ne disposent pas de leurs propres informations d'authentification.

Au lieu de cela, ils s'appuient sur le « blueprint » pour obtenir des jetons en leur nom grâce à un modèle d'usurpation d'identité. Le « blueprint » s'authentifie à l'aide de ses propres identifiants et effectue un échange de jetons : le jeton ainsi obtenu identifie l'agent comme étant le client, même si c'est le « blueprint » qui a procédé à l'authentification proprement dite.

Comme vous pouvez le voir sur le schéma, il y a également un troisième objet (Attention, spoiler : il y en a aussi un quatrième) dans le modèle : le agentIdentityBlueprintPrincipal, qui hérite de servicePrincipal et sert de représentation d'exécution locale du blueprint au niveau du tenant. Il est créé lorsqu'un blueprint est instancié dans un tenant et permet à ce dernier d'obtenir des jetons réservés à l'application afin de créer et de gérer les identités des agents.

Une autre distinction architecturale importante concerne le modèle de relation. Les applications traditionnelles suivent généralement une relation « un-à-un » entre l’objet d’application et l’entité de service au sein du locataire d’origine, tandis que les applications multi-locataires créent une entité de service par locataire dans lequel l’application est utilisée. Le modèle d’agent ajoute une couche supplémentaire : un même modèle peut générer plusieurs entités de service d’identité d’agent au sein d’un même locataire et entre plusieurs locataires.

Il est essentiel de bien saisir cette distinction pour comprendre à la fois l'architecture et la surface d'attaque, car les identités d'agent ne constituent pas simplement « un autre type d'entité de service ».

Dans un chapitre ultérieur, nous approfondirons un peu cette architecture, nous examinerons ce que le point de terminaison de métadonnées OData de Microsoft Graph révèle sur ces relations entre objets, nous analyserons les couches d'autorisation probablement en place, et nous émettrons quelques hypothèses éclairées sur les endroits où de futures vulnérabilités pourraient apparaître.

Mais avant toute chose, nous allons examiner le cadre mis en place par Microsoft pour l'authentification, l'autorisation, la gouvernance et la protection de ces identités non humaines.

Ne manquez pas le prochain chapitre : Comprendre l'identifiant Microsoft Agent et la plateforme d'identité Agent.

Découvrez le guide

Passez au prochain chapitre publié de la série… ou choisissez votre propre aventure.

• Introduction : Comprendre et prévenir les attaques d'usurpation d'identité de l'agent Entra ID : un guide complet
• Découvrez les identités des agents d'Entra ID (au fait, ce ne sont pas des personnes)

Notes de fin d'ouvrage

• 1 https://github.com/microsoftgraph/microsoft-graph-docs-contrib/blob/main/api-reference/beta/resources/agentidentity.md
• 2 https://github.com/microsoftgraph/microsoft-graph-docs-contrib/blob/main/api-reference/beta/resources/agentidentityblueprintprincipal.md
• 3 https://www.silverfort.com/blog/agent-id-administrator-scope-overreach-service-principal-takeover-in-entra-id/