Azure Privilegierter Zugriff: Globale Admins reduzieren

Was ist Azure Privilegierter Zugriff (Privileged Access Management)?

Azure Privilegierter Zugriff umfasst die Identitäten, Rollen, Richtlinien und Workflows, die administrative Macht in Microsoft Entra ID, Microsoft 365, Azure und verbundenen Diensten steuern. In Microsoft Entra ID können Rollen wie Globaler Administrator, Administrator für privilegierte Rollen, Administrator für bedingten Zugriff, Sicherheitsadministrator und Anwendungsadministrator Sicherheitseinstellungen ändern, Berechtigungen zuweisen, Anwendungen verwalten oder dauerhafte Zugriffspfade schaffen.

Das macht privilegierten Zugriff zu einem Thema der Tenant-Kontrollebene. Eine kompromittierte privilegierte Identität kann Richtlinien für bedingten Zugriff ändern, Rollenzuweisungen hinzufügen oder ändern, Anwendungen registrieren, Authentifizierungsmethoden ändern und die Kontrollen schwächen, auf die sich Verteidiger während der Reaktion verlassen.

Privileged Identity Management (PIM) reduziert dauerhafte Exposition, indem es Administratoren erlaubt, berechtigte Zuweisungen und zeitlich begrenzte Aktivierung zu nutzen, anstatt leistungsstarke Rollen dauerhaft aktiv zu halten. PIM ist nicht nur eine UI-Funktion. Es ist ein Kontrollmodell: nur bei Bedarf aktivieren, wo angebracht stärkere Authentifizierung oder Genehmigung verlangen, den Grund dokumentieren und die Rolle nach der Nutzung überprüfen.

Wie Azure Privilegierter Zugriff versagt

Dieselben Fehler bei privilegiertem Zugriff treten in echten Tenants immer wieder auf:

zu viele Globale Administratoren
permanente Rollenzuweisungen, wo berechtigte Zuweisungen ausreichen würden
Admin-Konten ohne starke Authentifizierungsabdeckung
Notfallkonten, die existieren, aber weder überwacht noch getestet werden
privilegierte Dienstprinzipale und Anwendungen, die von menschlichen Admin-Überprüfungen ausgeschlossen sind
PIM für manche Rollen eingeführt, aber nicht für die Rollen, die Angreifer interessieren
Ausnahmen bei bedingtem Zugriff, die Admin-Konten aus dem vorgesehenen Kontrollpfad entfernen

Das Risiko liegt nicht nur in der Anzahl der Administratoren. Ein Tenant mit wenigen Globalen Admins kann trotzdem exponiert sein, wenn diese Identitäten permanent, phishbar, für die tägliche Arbeit wiederverwendet oder von Richtlinien ausgenommen sind. Ein Tenant mit vielen eingeschränkten Administratoren kann sicherer sein, wenn jede Rolle begründet, berechtigt, überwacht und mit starker Authentifizierung geschützt ist.

Warum Globaler Administrator anders ist

Microsoft dokumentiert Globaler Administrator als hochprivilegierte Rolle, die fast jede administrative Einstellung in Microsoft Entra ID lesen und ändern kann, mit wenigen Ausnahmen, und zusätzlich nahezu alle administrativen Einstellungen von Microsoft 365 lesen und ändern kann. Globaler Administrator kann in manchen Szenarien auch Zugriff eskalieren. Das unterscheidet die Rolle von einer eng gefassten operativen Rolle wie Benutzeradministrator oder Berichteleser.

Verwenden Sie die Rolle mit den geringsten Rechten, die für die Aufgabe ausreicht. Wenn die Arbeit Anwendungs-Consent, Änderungen am bedingten Zugriff, Exchange-Administration oder Sicherheitsuntersuchungen betrifft, weisen Sie die zur Aufgabe passende Rolle zu, statt standardmäßig auf Globaler Administrator zurückzugreifen. Das verringert den Blast Radius, wenn ein Konto, eine Sitzung oder ein Genehmigungsworkflow versagt.

Die Angriffskette

Schritt 1 – Privilegierten Zugriff enumerieren

Ein Angreifer mit Lesezugriff auf das Verzeichnis beginnt oft damit, Verzeichnisrollen, Rollenmitglieder, privilegierte Gruppen, Anwendungen und Dienstprinzipale zu enumerieren. Gesucht werden Konten mit dauerhafter Macht, schwacher Authentifizierung oder inaktiven Eigentümern.

Schritt 2 – Den schwächsten Admin-Pfad anvisieren

Das einfachste Ziel ist nicht unbedingt der offensichtliche Globale Administrator. Es kann ein veralteter Administrator für privilegierte Rollen sein, ein Anwendungseigentümer mit weitreichenden App-Berechtigungen, ein Notfallkonto mit schwacher Überwachung oder ein Admin-Konto, das wegen eines früheren Ausfalls vom bedingten Zugriff ausgeschlossen wurde.

Schritt 3 – Zugriff in Persistenz umwandeln

Sobald privilegierter Zugriff besteht, kann der Angreifer versuchen, eine weitere Rollenzuweisung hinzuzufügen, Authentifizierungsmethoden zu ändern, eine Richtlinie zu schwächen, eine Anwendungsanmeldeinformation zu erstellen oder einen Berechtigungspfad für einen Dienstprinzipal hinzuzufügen. Der Persistenzpfad hängt von den Rollen ab, die die kompromittierte Identität innehat.

Schritt 4 – Sich in legitimer Administration verstecken

Privilegierte Änderungen sind oft selten, aber legitim. Angreifer profitieren, wenn der Tenant keine Baseline dafür hat, wer PIM aktiviert, wer Anfragen genehmigt, welche Konten permanent sein sollten und welche Anwendungen hohe Privilegien halten dürfen.

Erkennung

Entra ID Audit-Log-Ereignisse

Überwachen Sie administrative Änderungen, die die Kontrollebene des Tenants verändern:

Bereich	Was zu prüfen ist
Rollenzuweisungen	Neue Mitglieder in privilegierten Rollen, insbesondere Globaler Administrator und Administrator für privilegierte Rollen
PIM-Aktivität	Aktivierungen, Genehmigungen, abgelehnte Anfragen und Änderungen an Rolleneinstellungen
Authentifizierungsmethoden	Änderungen an den Authentifizierungsmethoden privilegierter Benutzer
Bedingter Zugriff	Erstellung, Aktualisierung, Löschung oder Ausnahmeänderungen von Richtlinien
Anwendungen	Neue App-Registrierungen, neue Anmeldeinformationen, neue Eigentümer und Consent mit hohen Privilegien
Notfallkonten	Jede Anmeldung, Änderung von Anmeldeinformationen oder Rollenänderung

PIM-Aktivitätssignale

PIM sollte Privilegien besser beobachtbar machen. Prüfen Sie:

Aktivierung außerhalb normaler Geschäfts- oder Wartungsfenster
Aktivierung für Rollen, die der Benutzer normalerweise nicht nutzt
Aktivierung ohne aussagekräftige Begründung, wo eine Begründung erforderlich ist
Genehmigung durch einen unerwarteten Genehmiger
wiederholte Aktivierung durch Konten, die auch Anmelderisiko zeigen
permanente Zuweisungen, die nach einem PIM-Rollout erstellt wurden

Einschränkungen bei der Erkennung

Behandeln Sie ein einzelnes Audit-Ereignis nicht als Kompromittierungsbeweis. Eine Rollenzuweisung kann Teil eines legitimen Projekts sein. Der Alert sollte Kontext enthalten: Akteur, Ziel, Rolle, Zuweisungsart, Aktivierungsdauer, Genehmigungspfad, Gerät, Standort, Risikostufe und ob der Benutzer diese Rolle normalerweise ausübt.

Behebung

Das Ziel ist nicht, jede Administration zu entfernen. Das Ziel ist, unnötige dauerhafte Privilegien zu entfernen und privilegierten Zugriff explizit, zeitlich begrenzt, stark authentifiziert und überprüfbar zu machen.

1. Anzahl der Globalen Administratoren reduzieren

Listen Sie alle Zuweisungen von Globaler Administrator auf und klassifizieren Sie jedes Konto:

normaler menschlicher Administrator
Notfallzugriffskonto
Dienstkonto oder Automatisierungsidentität
veraltetes Konto
externe oder Gastidentität
unbekannter Eigentümer

Normale menschliche Administratoren sollten in der Regel keinen permanenten aktiven Globaler-Administrator-Status benötigen. Wandeln Sie sie, wo Lizenzierung und Betrieb es erlauben, in engere Rollen oder berechtigte Zuweisungen über PIM um. Behandeln Sie die Ausnahme für Notfallzugriff gesondert, statt sie als reguläres Admin-Modell zu betrachten.

2. PIM-Rolleneinstellungen konfigurieren

Konfigurieren Sie für hochwertige Rollen die PIM-Einstellungen bewusst:

berechtigt statt permanent aktiv für normale Admins
zur Rolle passende Aktivierungsdauer
MFA oder Authentifizierungskontext für bedingten Zugriff bei der Aktivierung, wo erforderlich
Genehmigung für besonders sensible Rollen
Geschäftsbegründung und Ticketinformationen, wo der Prozess Nachvollziehbarkeit erfordert
Benachrichtigungen an das Team, dem die Rolle gehört
regelmäßige Zugriffsüberprüfungen für permanente und berechtigte Zuweisungen

Die Rolleneinstellungen von Microsoft PIM unterstützen Kontrollen wie Genehmigung, Begründung, Ticketinformationen und Zuweisungsdauer. Ticketinformationen sind ein Informationsfeld, keine automatische Validierung gegen ein Ticketsystem – gehen Sie also nicht davon aus, dass sie allein die Änderungsberechtigung belegen.

3. Notfallzugriffskonten richtig schützen

Notfallzugriffskonten sind bewusst anders. Microsoft empfiehlt zwei oder mehr Cloud-only-Notfallzugriffskonten für Break-Glass-Szenarien, und Microsoft-Empfehlungen besagen, dass diese Zuweisungen von Globaler Administrator aktiv permanent statt berechtigt in PIM sein sollten. Das verhindert, dass eine PIM-Abhängigkeit den Tenant während eines Ausfalls blockiert.

Diese Ausnahme bedeutet keine schwachen Kontrollen. Notfallkonten sollten Cloud-only sein, wo möglich mit phishing-resistenter Authentifizierung geschützt, sicher aufbewahrt, bei jeder Anmeldung überwacht und regelmäßig validiert werden. Sie sollten nicht für die reguläre Administration verwendet werden.

4. Starke Authentifizierung für privilegierte Benutzer erzwingen

Verlangen Sie starke Authentifizierung für privilegierte Benutzer und Rollen. Bevorzugen Sie für die wertvollsten Rollen phishing-resistente Methoden, soweit Lizenzierung, Geräteunterstützung und Betrieb es zulassen. Prüfen Sie außerdem, ob Admins die Richtlinie nicht über vertrauenswürdige Standorte, ausgeschlossene Gruppen, veraltete Testkonten oder Legacy-Workflows umgehen.

5. Anwendungen und Dienstprinzipale einbeziehen

Privilegierter Zugriff ist nicht nur menschlich. Überprüfen Sie Dienstprinzipale, App-Registrierungen, Anmeldeinformationen, Eigentümer und Anwendungsberechtigungen. Ein Tenant kann eine saubere Liste von Globaler Administrator haben und trotzdem einen Anwendungspfad besitzen, der Verzeichnisdaten lesen, Objekte ändern oder Persistenz aufrechterhalten kann.

Überprüfungsrhythmus und Eigentümerschaft

Privilegierter Zugriff sollte einen Eigentümer und einen Überprüfungsrhythmus haben. PIM reduziert dauerhaften Zugriff, beweist aber nicht automatisch, dass jede berechtigte Zuweisung noch gerechtfertigt ist. Vergleichen Sie mindestens einmal pro Überprüfungszyklus jede privilegierte Rollenzuweisung mit dem aktuellen Betriebsmodell: wem die Rolle gehört, welche Aufgabe sie erfordert, ob die Zuweisung weiterhin berechtigt bleiben sollte, ob die Aktivierungseinstellungen noch streng genug sind und ob der Benutzer noch zur Admin-Population gehört.

Überprüfen Sie auch Änderungen nach Migrationen, Fusionen, Incident Response, Nutzung von Notfallzugriff und großen SaaS-Onboardings. Das sind die Momente, in denen aus temporären Admin-Pfaden oft permanente werden.

Validierung nach dem PIM-Rollout

Validieren Sie nach der Bereinigung die tatsächliche Sicherheit statt nur die Existenz von Richtlinien:

bestätigen, dass normale Admins für hochwertige Rollen berechtigt statt permanent aktiv sind
bestätigen, dass Notfallkonten die einzigen beabsichtigten permanenten Ausnahmen für Globaler Administrator sind
eine kontrollierte Aktivierung durchführen und bestätigen, dass MFA, Genehmigung, Dauer und Protokollierung wie erwartet funktionieren
Audit-Logs nach der Bereinigung auf neue Rollenzuweisungen überprüfen
prüfen, dass bedingter Zugriff privilegierte Konten nicht unbeabsichtigt ausschließt
Dienstprinzipale und App-Registrierungen auf Privilegien überprüfen, die Admin-Rollen entsprechen
bestätigen, dass Alerting bei Notfallkonto-Anmeldung und privilegierter Rollenzuweisung auslöst

Ein guter Validierungstest fragt: Wenn dieses Admin-Passwort oder diese Sitzung heute gestohlen wird, welche Privilegien hat der Angreifer sofort, und welche zusätzlichen Kontrollen muss er erfüllen, bevor er mehr ausüben kann?

Wie EtcSec dies erkennt

EtcSec prüft die Konfiguration des privilegierten Azure-Zugriffs bei jedem Scan und konzentriert sich auf die Bedingungen, die aus einem kompromittierten Konto tenant-weite Kontrolle machen.

PA_TOO_MANY_GLOBAL_ADMINS identifiziert Tenants mit übermäßiger Anzahl an Globalen Administratoren.

PA_PERMANENT_ADMIN_ASSIGNMENTS hebt dauerhafte privilegierte Zuweisungen hervor, die auf Umwandlung in berechtigten Zugriff überprüft werden sollten.

PA_PIM_NOT_ENABLED zeigt Tenants auf, bei denen just-in-time privilegierte Zugriffskontrolle fehlt oder unwirksam ist.

PA_GLOBAL_ADMIN_NOT_MFA identifiziert Konten mit Globaler Administrator ohne starke Authentifizierungsabdeckung.

Azure Privilegierter Zugriff: Zu Viele Globale Admins