Entra ID: Verschachtelte privilegierte Gruppen, rollenfähige Gruppen und Gäste in Sicherheitsgruppen

Was sind rollenfähige Gruppen und verschachtelte privilegierte Gruppen in Entra ID

„Entra ID verschachtelte privilegierte Gruppen rollenfähig" — diese Suchkombination deckt einen der am wenigsten geprüften Bereiche der Zugriffssteuerung von Microsoft Entra ID ab: verschachtelte Berechtigungen über rollenfähige Gruppen und ein Gastkonto, das über eine Gruppenmitgliedschaft statt über eine Einladung in eine Sicherheitsgruppe gelangt — zusammen ergeben sie einen stillen Pfad in Richtung Global Administrator, den die meisten Mandanten nie kartiert haben.

Eine rollenfähige Gruppe ("role-assignable group") ist eine Sicherheitsgruppe, bei der die Eigenschaft isAssignableToRole auf true gesetzt ist (im Portal: „Microsoft Entra-Rollen können dieser Gruppe zugewiesen werden" = Ja). Wird eine Microsoft-Entra-Rolle einer Gruppe statt einzelnen Benutzern zugewiesen, kann eine Organisation die Rollenmitgliedschaft über Änderungen der Gruppenmitgliedschaft verwalten, statt wiederholte Rollenzuweisungs-API-Aufrufe durchzuführen. Laut Microsoft-Dokumentation erfordert das Erstellen rollenfähiger Gruppen Microsoft Entra ID P1 oder P2, die Eigenschaft isAssignableToRole ist nach dem Erstellen der Gruppe unveränderlich, eine rollenfähige Gruppe kann keine dynamische Mitgliedschaft verwenden, und ein Mandant kann maximal 500 rollenfähige Gruppen haben. Microsoft „schützt" außerdem die Besitzer rollenfähiger Gruppen gezielt, um das Risiko einer Rechteausweitung am Gruppenobjekt selbst zu verringern.

Verschachtelte privilegierte Gruppen beschreiben eine Gruppe, die Mitglied einer anderen Gruppe mit privilegierten Entra-Rollen oder Ressourcenzugriff ist — dieselbe Logik des „Pfads zum Domain Admin", die in lokalem Active Directory existiert (siehe gefährliche Gruppenverschachtelung in Active Directory), übertragen auf das Cloud-Verzeichnis. Microsoft blockiert explizit die offensichtlichste Variante: Eine Gruppe kann kein aktives Mitglied einer rollenfähigen Gruppe sein. Was Microsoft jedoch zulässt — und worauf die meisten Mandanten nicht vorbereitet sind — ist, dass eine Gruppe über Privileged Identity Management (PIM) für Gruppen ein berechtigtes ("eligible") Mitglied einer rollenfähigen Gruppe sein kann.

Schließlich sind Gäste in Sicherheitsgruppen ein eigenständiges Problem, losgelöst von der Governance der Gasteinladung. Dieser Artikel behandelt nicht, wer einen Gast einladen darf (siehe dazu Azure-Gastkonten: Die vergessene Angriffsfläche) — sondern die Tatsache, dass ein Gastkonto durch Verschachtelung oder eine dynamische Mitgliedschaftsregel zum Mitglied einer Sicherheitsgruppe wird, die Zugriff oder Rollenberechtigung trägt, ohne dass jemand explizit entschieden hat, diesem Gast etwas zu gewähren.

Entra ID Verschachtelte Privilegierte Gruppen Rollenfähig: Die Eskalationskette

Schritt 1 — Eine nicht privilegierte Gruppe wird als berechtigtes Mitglied verschachtelt

PIM für Gruppen erlaubt einem Administrator, berechtigte Zuweisungen in zwei Richtungen zu konfigurieren: Entweder werden Benutzer aktiv einer Gruppe hinzugefügt und die Gruppe selbst wird für eine Rolle berechtigt, oder eine Rolle wird der Gruppe aktiv zugewiesen und Benutzer werden für die Mitgliedschaft in dieser Gruppe berechtigt — und laut Microsofts eigener Dokumentation zu PIM für Gruppen kann auch eine Gruppe selbst als berechtigtes Mitglied einer anderen Gruppe konfiguriert werden, einschließlich einer rollenfähigen. Da die Einschränkung der aktiven Mitgliedschaft bei rollenfähigen Gruppen nur die direkte, dauerhafte Mitgliedschaft blockiert, kann eine niedriger privilegierte Gruppe als berechtigtes Mitglied einer rollenfähigen Gruppe konfiguriert werden, ohne diese Einschränkung zu verletzen.

Schritt 2 — Kein Genehmigungsworkflow wird bei der Aktivierung erzwungen

PIM für Gruppen unterstützt dieselben Richtlinienkontrollen wie PIM für Entra-Rollen: Genehmigung erzwingen, MFA bei Aktivierung erzwingen, geschäftliche Begründung verlangen und die maximale Aktivierungsdauer begrenzen. Wenn diese Kontrollen nicht konfiguriert sind — was in vielen Mandanten, die PIM für Gruppen übernommen haben, ohne es zu härten, die Standardhaltung ist —, kann jedes Mitglied der niedriger privilegierten Gruppe seine berechtigte Mitgliedschaft in der privilegierten Gruppe selbst aktivieren und erbt damit jede Rolle, die diese Gruppe trägt (Global Administrator, Privileged Role Administrator, Application Administrator und so weiter — siehe Azure Privileged Access: Zu viele globale Admins dazu, warum dauerhafter und leicht erreichbarer Global-Administrator-Zugriff bereits ein häufiger Befund ist).

Schritt 3 — Ein Gast reitet über dieselbe Gruppe mit

Die verschachtelte Gruppe aus Schritt 1 war selten von Anfang an eine „privilegierte" Gruppe — oft handelt es sich um ein Projektteam, eine App-Zugriffsgruppe oder eine Gruppe mit einer breiten dynamischen Mitgliedschaftsregel. Wurde dieser Gruppe ein Gastkonto hinzugefügt (direkt, oder weil die dynamische Regel der Gruppe breiter formuliert wurde als beabsichtigt — zum Beispiel durch Übereinstimmung mit Attributen, die userType eq Guest nicht zuverlässig ausschließen; siehe die Abschaffung des memberOf-Operators für dynamische Gruppenregeln dazu, wie sich solche Regeln bereits verschieben), erbt der Gast denselben berechtigten Pfad in die rollenfähige Gruppe wie jeder andere Mitgliedsbenutzer. Niemand hat explizit geprüft, „sollte dieser Gast für Global Administrator berechtigt sein" — die Gruppenverschachtelung hat diese Entscheidung implizit getroffen.

Gastkonto
  -> Mitglied der Sicherheitsgruppe "Project-Falcon" (dynamische oder manuelle Mitgliedschaft)
      -> "Project-Falcon" ist berechtigtes Mitglied von "Tier0-Admins" (rollenfähige Gruppe)
          -> "Tier0-Admins" ist aktiv der Rolle Global Administrator zugewiesen
              -> Gast aktiviert selbst die berechtigte Mitgliedschaft (keine Genehmigung erforderlich)
                  -> Gast besitzt für das Aktivierungsfenster Global Administrator

Die Assessment-Tools EntraFalcon von Compass Security dokumentieren dieselbe zugrunde liegende Schwachstelle aus offensiver Perspektive: Sie markieren jede Gruppe, die weder rollenfähig noch aus On-Premises synchronisiert noch in einer eingeschränkten Verwaltungseinheit (Restricted Management Administrative Unit) platziert ist, als „ungeschützt" (Finding-ID GRP-005 in ihren Reports) — denn keine dieser drei Eigenschaften ist bei einer Gruppe garantiert, die erst durch Verschachtelung transitiv privilegiert wird.

Erkennung

Erkennung bedeutet hier, rollenfähige Gruppen zu finden, herauszufinden, was darin berechtigt verschachtelt ist, und Gäste im Gruppenbaum zu finden, der in diese Gruppen einfließt — nichts davon erscheint standardmäßig als einzelner Alarm.

# Microsoft Graph — rollenfähige Gruppen auflisten
GET https://graph.microsoft.com/v1.0/groups?$filter=isAssignableToRole eq true&$select=id,displayName,membershipRuleProcessingState

# Microsoft Graph — Gäste transitiv innerhalb einer bestimmten Gruppe
GET https://graph.microsoft.com/v1.0/groups/{group-id}/transitiveMembers/microsoft.graph.user?$filter=userType eq 'Guest'

// Sentinel / Log Analytics — Gruppenmitgliedschaftsänderungen für eine Watchlist privilegierter Gruppen-IDs
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)

Abhilfe

1. Jede rollenfähige Gruppe inventarisieren mit der oben genannten isAssignableToRole eq true-Graph-Abfrage — nicht auf das Mandantengedächtnis „die Gruppen, die wir dafür erstellt haben" verlassen. Jeder Gruppe einen Besitzer zuweisen und Besitzer entfernen, die den Zugriff nicht mehr benötigen, da Microsofts eigene Leitlinien ungeregeltes Eigentum als primäres Rechteausweitungsrisiko an diesen Objekten markieren.
2. Genehmigung und MFA bei der Aktivierung erzwingen für jede berechtigte PIM-für-Gruppen-Zuweisung, die in einer rollenfähigen Gruppe endet, und eine begrenzte maximale Aktivierungsdauer festlegen, statt sie offen zu lassen.
3. Gruppenverschachtelung in rollenfähige Gruppen verbieten, wo sie betrieblich nicht erforderlich ist. Microsofts eigene Leitlinien empfehlen, verschachtelte Gruppen für Rollen-Eskalationspfade zu begrenzen oder zu vermeiden, da jede Verschachtelungsebene Gruppenbesitzer hinzufügt, die indirekt mitbestimmen können, wer die Rolle erreicht — ob beabsichtigt oder nicht.
4. Dynamische Mitgliedschaftsregeln prüfen, die eine Gruppe in einer privilegierten Kette speisen, und den Ausschluss von Gästen explizit (userType -ne "Guest") statt angenommen formulieren — eine rollenfähige Gruppe selbst kann keine dynamische Mitgliedschaft verwenden, aber die darunter verschachtelten Gruppen können es, und genau dort richtet eine zu breite Regel den Schaden an.
5. Zugriffsüberprüfungen für die Mitgliedschaft rollenfähiger Gruppen und für berechtigte Mitgliedschaftsketten durchführen, nicht nur für Rollenzuweisungen direkt — eine vierteljährliche Überprüfung, die nur „wer hat Global Administrator" umfasst, erfasst keinen Gast, der zwei Verschachtelungsebenen darunter sitzt.
6. Gäste aus Sicherheitsgruppen entfernen, denen sie nie beitreten sollten. Wenn sich die Anwesenheit eines Gastes in einer Gruppe nur durch „die dynamische Regel hat ihn erfasst" oder „jemand hat ihn versehentlich der falschen Gruppe hinzugefügt" erklären lässt, behandeln Sie das als zu schließenden Vorfall, nicht als später zu notierendes Konfigurationsdetail.

Diese Prüfungen fließen in eine breitere Überprüfung ein — siehe wie man die Sicherheit von Microsoft Entra ID auditiert dazu, wo Gruppen- und PIM-Hygiene im Verhältnis zu Conditional Access, MFA und App-Berechtigungen stehen.

Wie EtcSec das erkennt

Das Azure/Entra-ID-Audit von EtcSec prüft genau diese Kette: Verschachtelte Gruppen mit privilegiertem Zugriff (AZ_GROUP_NESTED_PRIVILEGED) markiert Gruppen, die über berechtigte oder transitive Verschachtelung eine rollenfähige Gruppe erreichen, Rollenfähige Gruppen (AZ_GROUP_ROLE_ASSIGNABLE) inventarisiert jede isAssignableToRole-Gruppe samt Eigentümerschafts-/Genehmigungsstatus, und Gastbenutzer in Sicherheitsgruppen (AZ_GROUP_GUEST_IN_SECURITY) deckt Gastkonten auf, die sich in Sicherheitsgruppen befinden — unabhängig davon, ob sie direkt eingeladen wurden oder ihre Mitgliedschaft durch Verschachtelung oder eine dynamische Regel erhalten haben. Verwandte Prüfungen — Admin-Rolle einer Gruppe zugewiesen (PA_GROUP_ASSIGNED_ADMIN) und Privilegierte Gruppen ohne Änderungsüberwachung (AZ_GROUP_PRIVILEGED_CHANGES) — erweitern dasselbe Audit um Rollen-zu-Gruppen-Zuweisungen und darauf, ob Mitgliedschaftsänderungen an diesen Gruppen tatsächlich protokolliert und überprüft werden.