Groupes Privilégiés Imbriqués Entra ID, Groupes Attribuables à un Rôle et Invités dans les Groupes de Sécurité

Que Sont les Groupes Attribuables à un Rôle et les Groupes Privilégiés Imbriqués dans Entra ID

Groupes privilégiés imbriqués Entra ID, groupes attribuables à un rôle : cette recherche composée couvre l'un des recoins les moins audités du contrôle d'accès de Microsoft Entra ID — le privilège imbriqué via des groupes attribuables à un rôle, et un invité qui s'infiltre dans un groupe de sécurité par l'appartenance plutôt que par l'invitation, formant ensemble un chemin silencieux vers Administrateur Général que la plupart des tenants n'ont jamais cartographié.

Un groupe attribuable à un rôle est un groupe de sécurité dont la propriété isAssignableToRole est définie sur true (ou « Les rôles Microsoft Entra peuvent être attribués à ce groupe » réglé sur Oui dans le portail). Attribuer un rôle Microsoft Entra à un groupe plutôt qu'à des utilisateurs individuels permet à une organisation de gérer l'appartenance aux rôles via des changements d'appartenance au groupe plutôt que par des appels répétés à l'API d'attribution de rôle. Selon la documentation de Microsoft, la création de groupes attribuables à un rôle nécessite Microsoft Entra ID P1 ou P2, la propriété isAssignableToRole est immuable une fois le groupe créé, un groupe attribuable à un rôle ne peut pas utiliser l'appartenance dynamique, et un tenant peut avoir un maximum de 500 groupes attribuables à un rôle. Microsoft « protège » également spécifiquement les propriétaires des groupes attribuables à un rôle pour réduire le risque d'élévation de privilège sur l'objet groupe lui-même.

Les groupes privilégiés imbriqués décrivent un groupe membre d'un autre groupe qui porte des rôles Entra privilégiés ou un accès à des ressources — la même logique de « chemin vers Domain Admin » qui existe dans Active Directory on-prem (voir imbrication dangereuse de groupes dans Active Directory), appliquée à l'annuaire cloud. Microsoft bloque explicitement la version la plus évidente de ceci : un groupe ne peut pas être un membre actif d'un groupe attribuable à un rôle. Ce que Microsoft autorise en revanche — et ce que la plupart des tenants n'ont pas anticipé — c'est qu'un groupe soit membre éligible d'un groupe attribuable à un rôle via Privileged Identity Management (PIM) pour les groupes.

Enfin, les invités dans les groupes de sécurité constituent un problème distinct de la gouvernance des invitations d'invités. Cet article ne traite pas de qui peut inviter un invité (voir Comptes Invités Azure : La Surface d'Attaque Oubliée pour cet angle) — il traite d'un compte invité qui se retrouve membre d'un groupe de sécurité porteur d'un accès ou d'une éligibilité à un rôle, via l'imbrication ou une règle d'appartenance dynamique, sans que personne n'ait explicitement décidé d'accorder quoi que ce soit à cet invité.

Groupes Privilégiés Imbriqués Entra ID Attribuables à un Rôle : La Chaîne d'Escalade

Étape 1 — Un groupe non privilégié est imbriqué comme membre éligible

PIM pour les groupes permet à un administrateur de configurer des attributions éligibles dans deux directions : soit des utilisateurs sont activement ajoutés à un groupe et le groupe lui-même est rendu éligible pour un rôle, soit un rôle est activement attribué à un groupe et des utilisateurs sont rendus éligibles à l'appartenance à ce groupe — et, selon la documentation même de Microsoft sur PIM pour les groupes, un groupe peut lui aussi être configuré comme membre éligible d'un autre groupe, y compris un groupe attribuable à un rôle. Comme la restriction d'appartenance active sur les groupes attribuables à un rôle ne bloque que l'appartenance directe et permanente, un groupe de moindre privilège peut être configuré comme membre éligible d'un groupe attribuable à un rôle sans enfreindre cette restriction.

Étape 2 — Aucun workflow d'approbation n'est appliqué à l'activation

PIM pour les groupes prend en charge les mêmes contrôles de politique que PIM pour les rôles Entra : exiger une approbation, imposer le MFA à l'activation, exiger une justification métier, et plafonner la durée maximale d'activation. Lorsque ces contrôles ne sont pas configurés — ce qui est la posture par défaut dans de nombreux tenants ayant adopté PIM pour les groupes sans le durcir — tout membre du groupe de niveau inférieur peut auto-activer son appartenance éligible au groupe privilégié et hériter du rôle porté par ce groupe (Administrateur Général, Administrateur de Rôle Privilégié, Administrateur d'Application, etc. — voir Accès Privilégié Azure : Trop d'Administrateurs Généraux sur les raisons pour lesquelles un accès Administrateur Général permanent et facilement atteignable est déjà un constat courant).

Étape 3 — Un invité s'infiltre par le même groupe

Le groupe imbriqué de l'étape 1 n'a rarement commencé son existence en tant que groupe « privilégié » — il s'agit souvent d'une équipe de projet, d'un groupe d'accès applicatif, ou d'un groupe avec une règle d'appartenance dynamique large. Si un compte invité a été ajouté à ce groupe (directement, ou parce que la règle dynamique du groupe a été écrite plus largement que prévu — par exemple en filtrant sur des attributs qui n'excluent pas de façon fiable userType eq Guest ; voir le retrait de l'opérateur de règle de groupe dynamique memberOf pour comment ces règles évoluent déjà), l'invité hérite du même chemin éligible vers le groupe attribuable à un rôle que n'importe quel utilisateur membre. Personne n'a explicitement examiné la question « cet invité devrait-il être éligible à Administrateur Général » — l'imbrication de groupe a pris cette décision implicitement.

Compte invité
  -> membre du groupe de sécurité "Project-Falcon" (appartenance dynamique ou manuelle)
      -> "Project-Falcon" est membre éligible de "Tier0-Admins" (groupe attribuable à un rôle)
          -> "Tier0-Admins" est activement attribué le rôle Administrateur Général
              -> l'invité auto-active son appartenance éligible (aucune approbation requise)
                  -> l'invité détient désormais Administrateur Général pour la fenêtre d'activation

L'outillage d'évaluation EntraFalcon de Compass Security documente la même faiblesse sous-jacente sous un angle d'évaluation offensive : il signale tout groupe qui n'est ni attribuable à un rôle, ni synchronisé depuis l'on-premise, ni placé dans une Unité d'Administration à Gestion Restreinte comme un groupe privilégié « non protégé » (identifiant de constat GRP-005 dans leurs rapports), car aucune de ces trois propriétés n'est garantie pour un groupe qui ne devient privilégié que transitivement, par imbrication.

Détection

Ici, la détection consiste à trouver les groupes attribuables à un rôle, à trouver ce qui est imbriqué de façon éligible à l'intérieur, et à trouver les invités dans l'arborescence de groupes qui les alimente — rien de tout cela n'apparaît comme une alerte unique par défaut.

# Microsoft Graph — énumérer les groupes attribuables à un rôle
GET https://graph.microsoft.com/v1.0/groups?$filter=isAssignableToRole eq true&$select=id,displayName,membershipRuleProcessingState

# Microsoft Graph — invités transitivement présents dans un groupe donné
GET https://graph.microsoft.com/v1.0/groups/{group-id}/transitiveMembers/microsoft.graph.user?$filter=userType eq 'Guest'

// Sentinel / Log Analytics — changements d'appartenance de groupe alimentant une liste de surveillance d'ID de groupes privilégiés
AuditLogs
| where OperationName in ("Add member to group", "Add owner to group")
| where TargetResources[0].id in (privilegedGroupIds)
| project TimeGenerated, OperationName, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName), Target = tostring(TargetResources[0].displayName)

Remédiation

1. Inventoriez tous les groupes attribuables à un rôle avec la requête Graph isAssignableToRole eq true ci-dessus — ne vous fiez pas à la mémoire du tenant sur « les groupes créés pour cela ». Attribuez un propriétaire à chacun et retirez les propriétaires qui n'ont plus besoin de cet accès, car les recommandations de Microsoft elles-mêmes signalent la propriété non gouvernée comme le principal risque d'élévation sur ces objets.
2. Exigez l'approbation et le MFA à l'activation pour toute attribution éligible PIM pour les groupes se terminant dans un groupe attribuable à un rôle, et fixez une durée d'activation maximale bornée plutôt que de la laisser ouverte.
3. Interdisez l'imbrication de groupes vers des groupes attribuables à un rôle là où elle n'est pas opérationnellement nécessaire. Les recommandations de Microsoft préconisent de limiter ou d'éviter les groupes imbriqués pour les chemins d'élévation de rôle, car chaque niveau d'imbrication ajoute des propriétaires de groupe pouvant indirectement gérer qui atteint le rôle, qu'ils l'aient voulu ou non.
4. Auditez les règles d'appartenance dynamique qui alimentent tout groupe dans une chaîne privilégiée, et rendez l'exclusion des invités explicite (userType -ne "Guest") plutôt que supposée — un groupe attribuable à un rôle lui-même ne peut pas utiliser l'appartenance dynamique, mais les groupes imbriqués en dessous le peuvent, et c'est précisément là qu'une règle trop large fait des dégâts.
5. Effectuez des revues d'accès sur l'appartenance des groupes attribuables à un rôle et sur les chaînes d'appartenance éligible, pas seulement sur les attributions de rôle directes — une revue trimestrielle limitée à « qui détient Administrateur Général » ne détectera pas un invité assis deux niveaux d'imbrication en dessous.
6. Retirez les invités des groupes de sécurité qu'ils n'étaient jamais censés rejoindre. Si la présence d'un invité dans un groupe ne s'explique que par « la règle dynamique l'a capté » ou « quelqu'un l'a ajouté au mauvais groupe », traitez cela comme un incident à clôturer, pas comme un détail de configuration à noter pour plus tard.

Ces contrôles s'intègrent dans une revue plus large — voir comment auditer la sécurité de Microsoft Entra ID pour situer l'hygiène des groupes et de PIM par rapport à l'accès conditionnel, au MFA et aux permissions applicatives.

Comment EtcSec Détecte Cela

L'audit Azure/Entra ID d'EtcSec vérifie exactement cette chaîne : Groupes Imbriqués avec Accès Privilégié (AZ_GROUP_NESTED_PRIVILEGED) signale les groupes qui atteignent un groupe attribuable à un rôle par imbrication éligible ou transitive, Groupes Attribuables à un Rôle (AZ_GROUP_ROLE_ASSIGNABLE) inventorie chaque groupe isAssignableToRole ainsi que sa posture de propriété/approbation, et Utilisateurs Invités dans les Groupes de Sécurité (AZ_GROUP_GUEST_IN_SECURITY) fait remonter les comptes invités présents dans des groupes de sécurité, qu'ils aient été invités directement ou qu'ils aient obtenu leur appartenance par imbrication ou par une règle dynamique. Des contrôles associés — Rôle Admin Attribué à un Groupe (PA_GROUP_ASSIGNED_ADMIN) et Groupes Privilégiés sans Surveillance des Changements (AZ_GROUP_PRIVILEGED_CHANGES) — étendent le même audit aux attributions de rôle sur des groupes et à la question de savoir si les changements d'appartenance sur ces groupes sont réellement journalisés et revus.