Identités managées : les privilèges Graph et Azure que personne ne regarde
Les identités managées sont une excellente pratique : plus de secret à stocker, plus de certificat à renouveler. Mais elles restent des identités, avec des droits parfois considérables. Comme elles n'apparaissent pas là où l'on cherche habituellement les applications, leurs privilèges échappent souvent aux revues.
Rappel : ce qu'est une identité managée
Une identité managée est un principal de service créé et géré par Azure pour une ressource : machine virtuelle, Function App, Logic App, compte Automation, App Service, etc. Le code qui s'exécute sur la ressource obtient des jetons auprès d'un point de terminaison local, sans aucun secret à manipuler. Il en existe deux formes :
- Attribuée par le système : liée à une seule ressource, supprimée avec elle.
- Attribuée par l'utilisateur : ressource Azure autonome, qui peut être associée à plusieurs ressources à la fois.
Dans Entra ID, ces identités apparaissent comme des principaux de service de type « ManagedIdentity ». Elles ne figurent pas dans les inscriptions d'applications et sont masquées par le filtre par défaut des applications d'entreprise.
Des privilèges cachés
Une identité managée peut recevoir trois catégories de droits, et chacune se gère à un endroit différent :
- Des rôles Azure RBAC sur des abonnements, groupes de ressources ou ressources, par exemple Contributeur ou Propriétaire.
- Des autorisations d'application Microsoft Graph (ou d'autres API), comme
User.ReadWrite.All,Mail.SendouRoleManagement.ReadWrite.Directory. Le portail ne propose pas d'interface pour les accorder : elles sont attribuées par PowerShell ou par l'API, ce qui les rend d'autant moins visibles. - Des rôles d'annuaire Entra ID, attribués comme à n'importe quel principal de service.
Nous rencontrons régulièrement des comptes Automation dotés d'autorisations Graph très larges pour un script de provisionnement, ou des identités attribuées par l'utilisateur partagées entre de nombreuses ressources « par commodité ».
Le vrai chemin d'escalade
Le point clé est le suivant : quiconque peut exécuter du code sur la ressource hérite des privilèges de son identité managée. Un utilisateur Contributeur sur une Function App peut modifier son code ; un opérateur d'un compte Automation peut lancer un runbook ; un administrateur d'une machine virtuelle peut interroger le point de terminaison local. Dans tous ces cas, il obtient un jeton au nom de l'identité.
Conséquence directe. Une identité managée disposant d'un rôle d'annuaire privilégié ou d'autorisations Graph sensibles fait de la ressource qui la porte, et de tous ceux qui l'administrent, un élément de niveau 0. Le périmètre d'administration Azure devient alors un chemin vers le contrôle d'Entra ID.
Inventorier les identités et leurs droits
Un inventaire utile croise les deux mondes, Entra ID et Azure :
- lister via Microsoft Graph les principaux de service dont le type est « ManagedIdentity » ;
- pour chacun, récupérer les attributions de rôles d'application (autorisations Graph et autres API) et les rôles d'annuaire éventuels ;
- côté Azure, lister les attributions RBAC de ces identités sur l'ensemble des abonnements, par exemple avec Azure Resource Graph ou Azure CLI ;
- identifier pour chaque identité les ressources qui l'utilisent et les personnes qui peuvent administrer ces ressources ;
- repérer les identités orphelines : identités attribuées par l'utilisateur rattachées à aucune ressource, ou dont la ressource n'est plus utilisée.
Appliquer le moindre privilège
Une fois l'inventaire établi, la réduction des droits suit quelques principes simples :
- Une identité par usage : éviter de partager une identité attribuée par l'utilisateur entre des applications sans rapport.
- Des autorisations ciblées : préférer
Sites.Selectedà un accès à tout SharePoint, ou les étendues d'application d'Exchange Online à un accès à toutes les boîtes aux lettres. - Des rôles Azure au plus juste : au niveau de la ressource ou du groupe de ressources, pas de l'abonnement, et rarement Propriétaire.
- Protéger les ressources porteuses : restreindre qui peut modifier le code, les runbooks ou se connecter aux machines virtuelles concernées.
- Surveiller : alerter sur l'attribution de nouvelles autorisations Graph ou de rôles d'annuaire à des identités managées.
Ce qu'un audit vérifie
- L'inventaire complet des identités managées et de leur type.
- Les autorisations Microsoft Graph et autres API accordées à chacune.
- Les rôles d'annuaire Entra ID attribués à des identités managées.
- Les rôles Azure RBAC et leur portée.
- Les personnes capables d'exécuter du code sur les ressources porteuses des identités les plus privilégiées.
- Les identités orphelines ou partagées sans justification.