Groupes et escalade de privilèges : quand un propriétaire de groupe devient administrateur
Attribuer des privilèges à des groupes plutôt qu'à des personnes est une bonne pratique. Elle déplace cependant la question de la sécurité : ce n'est plus seulement qui détient le rôle qui compte, mais qui peut modifier l'appartenance au groupe. C'est là que se cachent de nombreux chemins d'escalade.
Les groupes assignables à des rôles
Pour attribuer un rôle Entra ID à un groupe, celui-ci doit être créé avec la propriété isAssignableToRole, qui ne peut plus être modifiée ensuite. Ces groupes bénéficient de protections spécifiques : seuls les administrateurs généraux et les administrateurs de rôle privilégié peuvent les créer et en gérer l'appartenance, ils ne peuvent pas être dynamiques et n'acceptent pas de groupes imbriqués.
Une exception de taille demeure : les propriétaires du groupe peuvent en gérer les membres. Un utilisateur sans aucun rôle, désigné propriétaire d'un groupe qui porte le rôle d'administrateur général, peut s'y ajouter lui-même.
Get-MgGroup -Filter "isAssignableToRole eq true" -All -ConsistencyLevel eventual -CountVariable n |
ForEach-Object { $_.DisplayName; Get-MgGroupOwner -GroupId $_.Id | Select-Object -ExpandProperty Id }
Les groupes ordinaires, angle mort fréquent
Les groupes non assignables à des rôles ne bénéficient pas de ces protections. Leur appartenance peut être modifiée par leurs propriétaires, par les administrateurs des groupes ou des utilisateurs, et par toute application disposant de la permission Graph adéquate. Or ces groupes servent souvent à accorder des accès très sensibles :
- un rôle Propriétaire ou Contributeur sur un abonnement Azure ;
- l'accès à une application qui détient elle-même des permissions élevées ;
- l'exclusion d'une stratégie d'accès conditionnel exigeant la MFA ;
- l'éligibilité à un rôle via PIM pour les groupes.
Dans ces cas, un administrateur du support qui peut gérer ce groupe détient, de fait, le privilège qu'il confère.
Les groupes synchronisés depuis AD
Un groupe synchronisé depuis Active Directory est géré en local. Toute personne qui peut modifier son appartenance dans AD, un opérateur de comptes ou un administrateur délégué sur une unité d'organisation, contrôle donc aussi les droits cloud qui lui sont attribués. C'est l'un des chemins les plus fréquents entre une compromission de l'AD et une prise de contrôle du cloud.
Principe. Le niveau de protection d'un groupe doit être au moins égal à celui du privilège qu'il accorde. Un groupe qui donne accès à un rôle de niveau 0 doit être géré exclusivement par des identités de niveau 0, et uniquement dans le cloud.
PIM pour les groupes : utile, pas suffisant
Rendre l'appartenance éligible via PIM ajoute activation, justification et durée limitée. Mais si un propriétaire permanent peut modifier les membres ou les paramètres, le contrôle est contournable. Rendez aussi la propriété éligible, ou supprimez les propriétaires superflus.
Ce qu'un audit vérifie
- Les propriétaires de chaque groupe assignable à un rôle.
- Les groupes non protégés qui portent des droits Azure, des accès applicatifs sensibles ou des exclusions d'accès conditionnel.
- Les groupes synchronisés depuis AD qui accordent des privilèges cloud.
- Les applications disposant de permissions d'écriture sur les groupes ou leurs membres.