Service Principals et Managed Identities : les identités non humaines à surveiller

Quand on parle d'identité dans Entra ID, on pense d'abord utilisateurs. Pourtant, un nombre croissant d'incidents — Midnight Blizzard et consorts — passe par des Service Principals (SP) ou des Managed Identities (MI). Ces identités machine ont des privilèges parfois très larges, des credentials qui ne sont pas protégés par MFA, et leur télémétrie passe trop souvent sous le radar. Cet article remet à plat les concepts.

Service Principal : la version « machine » d'un compte

Un Service Principal est créé quand on enregistre une application dans Entra ID. À quoi ça sert ?

Service Principal : pourquoi en a-t-on besoin

Trois usages typiques

•     Automatisation : un SP permet à un script ou à un job d'appeler des APIs sans compte humain.

•     Access Control : on attribue des permissions granulaires à un SP (un SP qui ne peut interroger qu'une API précise).

•     Sécurité : le SP supporte une auth basée tokens, et évite d'exposer des couples user/password en clair.

Comment un SP s'authentifie

Un SP authentifie en présentant trois éléments :

Les trois éléments nécessaires à l'auth d'un SP

•     L'Application (Client) ID — identifiant de l'application enregistrée.

•     Le Tenant ID — l'identifiant du tenant cible.

•     Un Secret ou un Certificat — le credential de l'application.

Côté investigation, ces trois valeurs sont systématiquement présentes dans les logs d'authentification quand un SP se connecte. Les retrouver permet de pister précisément quelle application a fait quoi.

Exemple concret en PowerShell

Voici comment un SP s'authentifie via PowerShell pour appeler Microsoft Graph — utile pour comprendre ce qu'on observe dans les logs quand un attaquant abuse d'un SP :

Exemple PowerShell : login Microsoft Graph avec un SP

Managed Identities : des SP particuliers, attachés à des ressources

Une Managed Identity est un SP spécial associé à une ou plusieurs ressources Azure. Deux propriétés clés :

•      Les credentials ne sont pas visibles côté utilisateur — Azure les gère.

•     L'authentification se fait directement entre la MI et la ressource cible.

  

Managed Identities : System-assigned vs User-assigned

Deux types se croisent :

•     System-assigned MI : liée à une ressource unique (par exemple une VM). Quand la ressource est supprimée, la MI disparaît avec elle.

•     User-assigned MI : ressource Azure à part entière, qui peut être attachée à plusieurs ressources (utile pour partager une identité entre VMs d'un cluster).

Cas d'usage typique : une VM avec une MI qui peut écrire dans un Storage Account. Un attaquant qui compromet cette VM hérite des permissions de la MI sur le Storage. C'est exactement le pattern derrière de nombreuses escalations cloud — d'où l'intérêt d'auditer régulièrement les MI attribuées et leurs permissions.

App Registration vs Enterprise Application : ne pas confondre

App Registration vs Enterprise Application

Quand une application est créée, on retrouve un Application/Client ID (globalement unique) dans le menu Entra → App Registrations. Quand cette application (interne ou externe) s'enregistre dans le tenant, un Service Principal est créé, visible dans Entra → Enterprise Applications. C'est l'Object ID dans Enterprise Applications qui est le SP Object ID — celui à utiliser pour pister ce que l'application a fait dans le tenant.

Cas particulier important : pour les applications multi-tenants (typiquement des apps SaaS tierces), il n'y a pas d'App Registration locale — uniquement une entrée dans Enterprise Applications. C'est par cette entrée qu'on suit ce que la tierce partie a réellement effectué dans le tenant.

Member vs Guest : les types d'utilisateurs

Les types d'utilisateurs : Member vs Guest

Pour clore le tour des security principals, deux types d'utilisateurs existent par défaut dans Azure :

•     Member — utilisateur cloud standard. Un membre AD peut lire toutes les infos de l'annuaire, inviter des utilisateurs externes, gérer son profil et enregistrer des applications.

•     Guest — utilisateur restreint. Ne peut gérer que ses propres données de profil, ne peut pas naviguer dans l'annuaire ni enregistrer d'applications.

En IR, l'apparition d'un guest avec des privilèges anormaux, ou la conversion d'un guest en member, sont des anomalies à monitorer (les Audit Logs portent ces événements).

À retenir pour l'investigation

Pour toute compromission Entra ID, la première question utile est : « est-ce un user, un SP ou une MI ? ». La réponse change la façon dont on investigue (logs concernés), la façon dont on contiendra (révoquer un secret SP vs révoquer la session d'un user), et la façon dont on remonte le kill chain (un SP compromis peut avoir été créé légitimement il y a longtemps puis abusé via un secret ajouté tardivement — d'où la valeur des Audit Logs sur la création de credentials).