21 gefährliche Rollen – Azure AD / Entra ID
Wussten Sie, dass es in der Microsoft Cloud gefährliche Rollen und weitere sicherheitsrelevante Themen gibt, um die Sie sich als Kunde kümmern müssen? Klar, weiß doch jeder – nimmt aber nicht jeder ernst. Zur Absicherung des eigenen Tenants gehört das Thema Rollen und Berechtigungen in Microsoft Entra ID (Azure AD) zum Pflichtprogramm. Zu den typischen Fehlern in der realen Welt zählen beispielsweise:
- Unüberlegte Vergabe hoch-privilegierter Rollen
- Unsichere Custom-Rollen
- Zu viele hoch-privilegierte Accounts
- Schlecht abgesicherte Zugänge
- Ungenügende Passwort-Reset-Vorgänge
- Fehlender oder unzureichendes Logging und Alerting
Bei über 90 „built-in“ Rollen in Entra ID fällt es auch nicht leicht den Überblick zu behalten. Aber Microsoft hilft!
Die Grundlagen zur Absicherung eines Microsoft Tenants haben wir bereits hier erläutert und zuletzt hier über die Verwendung von Phishing-resistenter Authentifizierung gesprochen. In diesem kurzen Beitrag schauen wir explizit nur auf die Rollen im Azure AD und die von Microsoft bereitgestellten Hilfsdokumente.
Privilege Escalation-Angriffe in der Cloud über gefährliche Rollen
Gefährliche Rollen sind nicht neu. Specterops hat bereits im Oktober 2021 vor dem Missbrauch von Rollen und Berechtigungen im Azure AD mit dem Fokus auf Service Principals gewarnt. Klar ist aber: Auch normale Administratoren und Benutzer können ein Ziel von Angriffen sein und ungewollt weitreichenden Zugriff auf den eigenen Tenant und die darin verarbeiteten Daten gewähren.
Zum Zeitpunkt der Erstellung dieses Beitrags listet Microsoft 21 privilegierte Rollen auf. Die aktuelle Implementierung von Entra ID / Azure AD zeigt auf einen Blick, wie vielen Benutzern eine der Rollen zugewiesen wurde. Im Bild links etwa 5x der Global Administrator und 1x der Global Reader. Eine praktische Übersicht für den Einstieg in die Rollen- und Berechtigungsprüfung.
Dass der „Global Administrator“ eine privilegierte Rolle ist, ist offensichtlich. Der „Application Administrator“ hat ebenfalls das Flag „Privileged“ – zurecht. Eines der beliebtesten Beispiele für Privilege Escalation in der Microsoft Cloud ist der Missbrauch der Rolle „Application Administrator“. Im verlinkten Artikel von Microsoft werden nicht nur die Rollen, sondern auch die einzelnen Berechtigungen (Permissions) und deren Kritikalität aufgeführt. Hilfreich vor allem, wenn Custom-Rollen definiert und vergeben wurden.
Auch Enterprise Applications können weitreichende Berechtigungen im Tenant haben – etwa Directory.ReadWrite.All. Ein Angreifer mit Kontrolle über eine solche App kann relativ frei im Tenant wüten.
Der oben angesprochene „Application Administrator“ verfügt über die Permission „microsoft.directory/applications/credentials/update“, die es ihm erlaubt, zu einer bestehenden Enterprise App neue Authentifizierungsmerkmale hinzuzufügen – im Klartext: er kann sich ein neues Client Secret erstellen, darüber auf die App zugreifen und darüber die Directory.ReadWrite.All-Berechtigung der App für seine Zwecke missbrauchen. Derartige Wege zur Erweiterung der eigenen Rechte gibt es zahlreiche im Microsoft 365 Universum – wie auch in der on-Premises Welt.
Least Privileges - Rollen und Aufgaben
Die korrekte Vergabe der notwendigen Rollen und Berechtigungen im Azure AD ist eine Herausforderung. Gerade in den Anfangszeiten fehlten einer Rolle oft einzelne Berechtigungen, was zur Definition von Custom-Rollen geführt hat – ein Alptraum im Audit. Mit der wachsenden Reife des Azure AD hat Microsoft auch hierfür mittlerweile brauchbare Empfehlungen zur Beantwortung der Frage veröffentlicht: Welche Rolle benötige ich im AAD für welche Aufgabe?
Das vermeidet überprivilegierte Benutzer, aber: Wer z. B. Enterprise Applications erstellen möchte, der muss natürlich die passende Admin-Rolle dafür haben:
Zumindest braucht ein Enterprise Application Admin nicht die Global Admin Rolle – also, solange er nicht die User Settings ändern möchte.
Ein regelmäßiger Review der Rollen lohnt sich. Wenn die Anzahl kritischer Rollen auf ein Minimum reduziert ist, dann sinkt auch die Angriffsfläche im Tenant.
Azure AD / Microsoft Tenant absichern
Die vollständige Kompromittierung des eigenen Tenants hat weitreichende Folgen. Dafür brauchte es eigentlich keinen MGM-Hack mehr. Aber Aufmerksamkeit schadet bei dem Thema wohl nie. Wie auch im on-Premises Active Directory gilt in der Cloud, dass der IT-Admin nicht unbedingt der Spezialist für IT-Sicherheit ist und das Systemhaus nicht unbedingt der Cloud-Security-Profi.
In unseren Blog-Artikeln und Schulungen zeigen wir, was wir aus unseren Projekten rund um Azure und M365 gelernt haben und wie sich die eigene Infrastruktur testen und absichern lässt. Dazu gehört natürlich:
- Sichere Basiskonfiguration des Tenants
- Sauber aufgebautes Conditional Access Regelwerk
- Admin-Konzept mit Least Privileges
- Logging & Monitoring verdächtiger Ereignisse
Letzteres ist ein spannendes Thema, dem wir uns u.a. im November in einem Webinar gemeinsam mit Heise widmen werden. Der Schwerpunkt wird hier auf der Frage liegen, „wer liest eigentlich meine E-Mails und wie bekomme ich davon mit?“ – ein kleiner Seitenhieb auf die verloren Signaturschlüssel von Microsoft und der Versuch zwischen Rollen, Berechtigungen und Audit-Logs brauchbare Schutzmaßnahmen für die eigene Infrastruktur zu extrahieren.
