Identités managées ou principaux de service à secret : choisir et auditer
Les identités managées suppriment le problème le plus courant des identités de charge de travail : le secret stocké quelque part. Elles ne suppriment pas pour autant le risque lié aux droits qu'on leur accorde, et elles sont souvent oubliées dans les revues de privilèges.
Ce qu'est une identité managée
Une identité managée est un principal de service particulier, créé et géré par Azure, dont les informations d'identification ne sont jamais exposées. La ressource qui l'utilise (machine virtuelle, App Service, Function, conteneur, automatisation) demande un jeton au point de terminaison local de la plateforme, et Azure se charge de la rotation. Il n'y a ni secret à stocker, ni certificat à renouveler, ni expiration à surveiller.
En contrepartie, une identité managée ne peut être utilisée que depuis une ressource Azure à laquelle elle est attachée, ou depuis un serveur relié par Azure Arc. Pour une application hébergée ailleurs, il faut une inscription d'application, idéalement avec la fédération d'identité de charge de travail plutôt qu'un secret.
Affectée par le système ou par l'utilisateur
| Affectée par le système | Affectée par l'utilisateur | |
|---|---|---|
| Cycle de vie | Liée à la ressource, supprimée avec elle | Ressource Azure indépendante |
| Partage | Une seule ressource | Peut être attachée à plusieurs ressources |
| Usage type | Charge de travail isolée | Flotte de ressources partageant les mêmes droits, droits préparés à l'avance |
L'identité affectée par l'utilisateur est pratique, mais chaque ressource qui la porte peut obtenir ses jetons. Partagée entre une application sensible et une machine de test mal protégée, elle expose la première via la seconde. Qui peut attacher une identité affectée par l'utilisateur à une ressource est aussi une question de droits Azure à vérifier.
Le secret n'a pas disparu, il s'est déplacé. Toute personne capable d'exécuter du code sur la ressource, ou de modifier son code, peut obtenir un jeton de l'identité managée. Les contributeurs d'une Function ou d'un compte Automation disposent donc, de fait, des droits de son identité.
Les droits à auditer
Une identité managée peut recevoir trois familles de droits, qu'il faut examiner ensemble :
- Les rôles Azure RBAC : Propriétaire ou Contributeur sur un abonnement ou un groupe d'administration, Administrateur de l'accès utilisateur, accès aux coffres de clés ;
- Les permissions d'application sur Microsoft Graph et d'autres API : elles ne s'attribuent pas depuis le portail mais par PowerShell ou par l'API, ce qui les rend moins visibles ;
- Les rôles d'annuaire Entra ID, attribuables à une identité managée comme à tout principal de service.
Dans les locataires que nous auditons, il est fréquent de trouver un compte Automation dont l'identité managée détient des permissions Graph étendues pour un script de gestion des utilisateurs, alors que de nombreuses personnes sont contributrices du compte.
Quand garder un principal de service à secret
Le principal de service classique reste nécessaire pour les applications hors Azure sans fédération possible, pour certains logiciels tiers, ou pour une application multilocataire. Dans ces cas, préférez un certificat, limitez les propriétaires et documentez l'emplacement de l'information d'identification. Un principal de service à secret qui tourne dans une ressource Azure est en revanche un candidat évident à la migration.
Méthode d'inventaire
- Lister les principaux de service de type identité managée dans Entra ID ;
- Pour chacun, récupérer ses attributions de rôles d'application et de rôles d'annuaire ;
- Récupérer ses attributions Azure RBAC sur l'ensemble des abonnements et groupes d'administration ;
- Identifier les ressources qui la portent et les personnes pouvant y exécuter du code.
Ce qu'un audit vérifie
- Les identités managées disposant de rôles Azure élevés ou de permissions Graph sensibles.
- Les identités affectées par l'utilisateur partagées entre ressources de sensibilités différentes.
- Les personnes capables d'exécuter du code sur les ressources qui portent des identités privilégiées.
- Les principaux de service à secret qui pourraient être remplacés par une identité managée.