Entra ID Break-Glass Notfallzugangskonten: Fehlend, unüberwacht, nicht ausgeschlossen

Was ist ein Entra ID Break-Glass-Notfallzugangskonto

Ein Entra ID Break-Glass-Notfallzugangskonto ist ein Global-Administrator-Konto, das für genau das eine Szenario in Reserve gehalten wird, das jeder andere Admin-Zugangsweg verhindern soll: die vollständige Aussperrung. Microsofts eigene Anleitung listet die Situationen auf, für die diese Konten existieren – ein Federation-Ausfall, der jeden synchronisierten Admin aussperrt, ein Ausfall des MFA-Geräts oder -Dienstes, der die Rollenaktivierung blockiert, das Ausscheiden des letzten aktiven Global Administrators, eine Naturkatastrophe, die Telefonnetze lahmlegt, oder eine Privileged-Identity-Management-(PIM)-Genehmigungssackgasse, bei der jede berechtigte Zuweisung als Global Administrator oder Privileged Role Administrator einen Genehmiger benötigt und keiner aktiv ist. Einen breiteren Blick darauf, wie PIM-Zuweisungen und die Anzahl dauerhafter Global-Admin-Konten das Tenant-Risiko treiben, bietet Azure Privileged Access: Zu viele globale Admins.

Keines davon ist exotisch. Es sind die konkreten Grenzfälle, die „einfach MFA nutzen" und „einfach PIM nutzen" nicht abdecken – weil MFA und PIM genau das sind, was ausfallen kann.

Die Governance-Lücke, um die es in diesem Artikel geht, ist nicht das Konzept selbst – die meisten Sicherheitsteams kennen Break-Glass-Konten. Es geht darum, dass Microsofts Audit-Katalog drei unterschiedliche, in der Praxis häufige Arten erfasst, wie diese Kontrolle in echten Tenants versagt:

1. Es existiert überhaupt kein Notfallzugangskonto (PA_NO_EMERGENCY_ACCOUNTS) – der Basisfall und laut EtcSecs Katalog die Standardeinstufung mit kritischem Schweregrad: null Break-Glass-Abdeckung bedeutet null Wiederherstellungsweg, falls der primäre Admin-Zugang ausfällt.
2. Das Konto existiert, ist aber nicht von Conditional Access ausgeschlossen (PA_EMERGENCY_NO_EXCLUSION / CA_NO_BREAK_GLASS_EXCLUSION) – sodass genau die Richtlinie, die den Tenant schützen soll, das Wiederherstellungskonto während des Notfalls aussperrt, für den es gedacht war.
3. Das Konto existiert und ist ausgeschlossen, aber niemand überwacht es (PA_EMERGENCY_NO_MONITORING) – sodass ein Anmeldeereignis, das eigentlich höchste Alarmstufe auslösen sollte (ein Global-Admin-Konto außerhalb der normalen CA-Kontrollen hat sich gerade angemeldet), keinerlei Alarm erzeugt.

Eine vierte, verwandte Lücke findet sich in derselben Katalog-Familie: veraltete Anmeldeinformationen (PA_EMERGENCY_CREDENTIAL_STALE) – ein Notfallkonto, dessen Authentifizierungsmethode oder Gerät so lange nicht validiert wurde, dass niemand mehr weiß, ob es überhaupt noch funktioniert.

Wie die Lücke in der Praxis entsteht

Break-Glass-Konten werden meist einmalig angelegt, bei der initialen Tenant-Einrichtung oder im Rahmen eines Compliance-Vorstoßes, und danach unangetastet gelassen – was genau das Problem ist, denn „unangetastet" wirkt in beide Richtungen.

Komplett fehlend

Kleinere Tenants, aus einem älteren Identitätsanbieter migrierte Tenants oder Tenants, die annahmen, „unsere Admins haben ja alle MFA" zähle als Abdeckung, haben häufig überhaupt kein dediziertes Notfallzugangskonto. Microsoft empfiehlt die Einrichtung von mindestens zwei reinen Cloud-Konten in der Standarddomäne *.onmicrosoft.com des Tenants – nicht föderiert, nicht aus On-Premises synchronisiert – genau damit ein On-Prem- oder Federation-Ausfall nicht auch noch den Wiederherstellungsweg mit sich reißen kann.

Nicht von Conditional Access ausgeschlossen

Das ist die Fehlerart, die eine Kontrolle in eine Falle verwandelt. Eine CA-Richtlinie, die ein konformes Gerät, eine bestimmte MFA-Methode verlangt oder nach Standort blockiert, greift anstandslos auch für das Notfallkonto wie für jeden anderen Global Administrator – was bedeutet, dass genau die Richtlinie, die den Tenant schützen soll, der Grund dafür wird, dass sich das Notfallkonto während des Ausfalls oder der Aussperrung, für die es existiert, nicht anmelden kann. Microsoft ist hier eindeutig: Break-Glass-Konten von jeder CA-Richtlinie ausschließen, die die Anmeldung blockiert oder einschränkt; Richtlinien im Nur-Bericht-Modus blockieren keinen Zugriff und benötigen den Ausschluss nicht. Das ist ein Spezialfall eines breiteren Musters – siehe Entra ID Conditional-Access-Lücken dazu, wie Fehler beim Ausschlussumfang generell über Richtlinien hinweg auftreten.

Nicht überwacht

Selbst bei korrekt angelegtem und ausgeschlossenem Konto haben die meisten Tenants keine Alarmierung für dessen Nutzung eingerichtet. Ein Break-Glass-Konto ist so konzipiert, dass es sich so gut wie nie anmeldet. Diese Eigenschaft macht die Überwachung günstig und hochsignifikant: Jede Authentifizierung von diesem Konto ist entweder eine geplante Validierungsübung oder ein aktiver Vorfall (ein legitimer Notfall oder ein Angreifer, der das eine Konto gefunden und kompromittiert hat, das explizit aus der Richtliniendurchsetzung herausgenommen wurde). Ohne einen dauerhaften Alarm bleibt dieses Signal unsichtbar, bis jemand zufällig die Anmeldeprotokolle durchsieht – was bei den meisten Tenants selten oder nie geschieht. Dieser blinde Fleck steht neben den breiteren Risikosignal-Lücken, die in Azure Identity Protection: Geleakte Anmeldeinformationen blockieren behandelt werden.

Erkennung

Prüfen Sie den Status der Break-Glass-Notfallzugangskonto-Abdeckung anhand dieser Checks, zugeordnet zu den Katalogeinträgen:

Aufbau der Anmelde-Alarmabfrage

Speziell für den Überwachungscheck ist Microsofts dokumentierter Ansatz eine Log-Analytics-Custom-Log-Alarmregel gegen die Tabelle SigninLogs, verschlüsselt über die Objekt-ID des Kontos (zu finden unter Entra ID → Users → [Konto] → Object ID):

// Alert query — any sign-in from an emergency access account
SigninLogs
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

Setzen Sie den Schwellenwert des Alarms auf 0 (größer als), den Schweregrad auf 0 – Kritisch, und hängen Sie eine Aktionsgruppe an, die Ihr Sicherheitsteam per E-Mail und SMS alarmiert – denn laut Microsofts Anleitung sollte jede Anmeldung von diesem Konto eine Überprüfung auslösen, egal ob es sich um eine geplante Übung oder einen echten Vorfall handelt.

Ziehen Sie außerdem die Audit-Log-Einträge des Kontos heran (nicht nur das Anmeldeprotokoll) – Änderungen an Rollenzuweisungen, Registrierungen von Anmeldeinformationen und Änderungen der CA-Richtlinienmitgliedschaft, die das Konto betreffen, sind alle unabhängig von der Anmeldeaktivität eine Alarmierung wert. Wenn Sie diese Art von Check im Rahmen einer breiteren Tenant-Überprüfung statt als Einzelmaßnahme aufbauen, führt Sie Wie man Microsoft Entra ID Sicherheit auditiert durch den vollständigen Prüfumfang, in den dies eingebettet ist.

Behebung

1. Legen Sie mindestens zwei Notfallzugangskonten an. Reine Cloud-Konten, Domäne *.onmicrosoft.com, nicht föderiert oder synchronisiert. Microsofts Anleitung empfiehlt mindestens zwei, damit eine einzelne kompromittierte oder nicht verfügbare Anmeldeinformation nicht die gesamte Wiederherstellungsfähigkeit entzieht.
2. Verwenden Sie phishing-resistente, passwortlose Authentifizierung. Passkey (FIDO2) ist Microsofts empfohlene Methode; zertifikatsbasierte Authentifizierung ist die Alternative, falls Ihre Organisation bereits eine PKI betreibt. Verwenden Sie nicht dieselbe MFA-Methode wie Ihre normalen Admin-Konten – wenn Microsoft-Authenticator-Push für Admins Standard ist, statten Sie das Notfallkonto stattdessen mit einem FIDO2-Hardware-Key aus, damit ein einzelner Ausfall oder eine einzelne Kompromittierungsklasse nicht beide Wege gleichzeitig lahmlegen kann.
3. Weisen Sie Global Administrator in PIM als dauerhaft, aktiv – nicht berechtigt – zu. Ein Notfallkonto, das hinter einem PIM-Aktivierungsschritt liegt, verfehlt seinen Zweck, wenn PIM selbst Teil des Ausfalls ist.
4. Schließen Sie die Konten von jeder Conditional-Access-Richtlinie aus, die die Anmeldung blockiert oder einschränkt. Legen Sie eine dedizierte Sicherheitsgruppe an (Microsofts Beispielname: EmergencyAccess) und schließen Sie diese Gruppe von erzwungenen Richtlinien aus – Nur-Bericht-Richtlinien benötigen den Ausschluss nicht, da sie den Zugriff nicht blockieren können. Überprüfen Sie die Ausschlussliste jedes Mal erneut, wenn eine neue CA-Richtlinie veröffentlicht wird.
5. Richten Sie die Anmeldeüberwachung ein, bevor Sie sie brauchen. Bauen Sie die oben genannte Log-Analytics-Alarmregel, leiten Sie sie an eine echte Aktionsgruppe weiter (E-Mail + SMS, nicht ein Postfach, das niemand beachtet), und setzen Sie den Schweregrad auf Kritisch.
6. Bewahren Sie Anmeldeinformationen an einem gesicherten, zugriffskontrollierten Ort auf – physisch getrennte, feuerfeste Aufbewahrung für Hardware-Token oder CBA-Zertifikate, zugänglich für mehr als eine autorisierte Person, an kein einzelnes Mitarbeitergerät gebunden.
7. Validieren Sie alle 90 Tage und nach jeder Änderung im Admin-Team. Bestätigen Sie, dass sich das Konto unter der aktuellen CA-Konfiguration noch erfolgreich anmelden kann, dass der Alarm noch auslöst und dass die Liste der autorisierten Nutzer aktuell ist. Microsofts Anleitung ist eindeutig, dass diese Validierung mindestens alle 90 Tage und nach jeder personellen Veränderung erfolgen muss – ein Notfallzugangskonto, das niemand unter echten Ausfallbedingungen getestet hat, ist keine funktionierende Kontrolle, sondern eine Annahme.
8. Führen Sie nach jeder Auslösung ein Post-Mortem durch, ob Übung oder echter Vorfall, um zu bestätigen, dass die Nutzung autorisiert war und die ergriffenen Maßnahmen zum Vorfall passten.

Break-Glass-Abdeckung ist ein Baustein einer breiteren Tenant-Härtungsbasis – siehe Azure Tenant Hardening: Unsichere Standardeinstellungen beheben für die weiteren Standard-Konfigurationslücken, die zusammen mit dieser geschlossen werden sollten.

Wie EtcSec dies erkennt

Der EtcSec Entra-ID-Audit prüft alle drei hier behandelten Fehlerarten: PA_NO_EMERGENCY_ACCOUNTS markiert Tenants ohne qualifizierende Notfallzugangskonten, PA_EMERGENCY_NO_EXCLUSION (gepaart mit CA_NO_BREAK_GLASS_EXCLUSION) markiert Konten, die noch im Geltungsbereich einer erzwungenen Conditional-Access-Richtlinie liegen, PA_EMERGENCY_NO_MONITORING markiert Konten ohne entsprechende Anmelde-Alarmkonfiguration, und PA_EMERGENCY_CREDENTIAL_STALE markiert Konten, deren Anmeldeinformationen nicht innerhalb des empfohlenen Zeitfensters validiert wurden.