In vielen Tenants, die ich betreue, galt der Notfallzugang lange als notwendiges Übel. Gemeint ist ein Konto, das in keiner Conditional-Access-Richtlinie steckt und im Zweifel nur durch ein simples Passwort geschützt ist. Seit Microsoft die Multi-Faktor-Authentifizierung für die Azure- und Microsoft-365-Adminportale verpflichtend gemacht hat, ist diese Zeit vorbei. Microsoft empfiehlt inzwischen sehr deutlich, Break-Glass-Konten sicher aufzubewahren und sie zusätzlich selbst auf den höchsten Authentifizierungsstandard zu heben, am besten mit FIDO2-Passkeys oder zertifikatsbasierter Authentifizierung.

Microsoft verlangt für Notfallkonten heute starke Authentifizierung

Ein Notfallzugang ist heute deutlich mehr als ein „Konto ohne MFA“. Seit die Azure-MFA-Pflicht im Oktober 2024 durchgesetzt wird (siehe meinen Erfahrungsbericht), lassen sich Ausnahmen kaum noch rechtfertigen. In seinen Empfehlungen setzt Microsoft auf zwei Break-Glass-Konten, die jeweils eine andere starke Authentifizierungsmethode nutzen, etwa eines mit FIDO2 und eines mit CBA. Die Schlüssel oder Smartcards gehören in einen gesicherten Safe, physisch getrennt von den Zugangsmitteln, mit denen die Admins im Alltag arbeiten. Auf den ersten Blick mag das übertrieben wirken. Tritt der Ernstfall aber tatsächlich ein, ist man über jede dieser Vorkehrungen froh.

Der Ausschluss aus Conditional Access darf keine neue Schwachstelle schaffen

Schwierig wird es an der Stelle, an der man Break-Glass-Konten aus Conditional-Access-Richtlinien ausnimmt, ohne sie dadurch wieder zum schwächsten Glied zu machen. Ich arbeite dafür mit einem Gruppenausschluss und nehme die Break-Glass-Konten in eine eindeutig benannte Gruppe auf, zum Beispiel „Emergency Access Accounts“. Der Ausschluss sollte allerdings nicht für sämtliche Richtlinien gelten. Richtlinien, die eine bestimmte Authentifizierungsstärke verlangen (mindestens „stark“, etwa per FIDO2-Passkey oder CBA), müssen für die Break-Glass-Konten ausdrücklich greifen. Am einfachsten gelingt das mit einer zweiten Richtlinie, die genau diese Konten per „Include“ einschließt. Einzelheiten dazu stehen in den Empfehlungen von Microsoft. In der Praxis sehe ich oft, dass der Notfallzugang am Ende dann doch wieder überall ausgeschlossen wird.

# Beispiel: Gruppe mit Break-Glass-Konten anlegen
# PowerShell 7, Microsoft.Graph-Modul, Rolle: Privileged Role Administrator
New-MgGroup -DisplayName "Emergency Access Accounts" -MailEnabled:$false -SecurityEnabled:$true -MailNickname "emergencyaccess"

Tipp aus Projekten: Wählen Sie für die Notfallgruppe einen bewusst unauffälligen Namen, damit sie im Tenant-Explorer nicht sofort ins Auge sticht. Bei „breakglass“ wird auch ein Angreifer hellhörig.

FIDO2 und Zertifikate sichern die beiden Konten unabhängig voneinander ab

Inzwischen setze ich konsequent auf zwei Konten mit unterschiedlichen Methoden. Das eine bekommt einen FIDO2-Token (YubiKey o. Ä.), beim zweiten läuft die Anmeldung über eine Smartcard oder CBA. Die Hardware liegt in getrennten Safes, idealerweise an verschiedenen Standorten. Für das Notfallkonto lassen sich die FIDO2-Token ohne großen Aufwand über die Richtlinie für Authentifizierungsmethoden freischalten. Registrieren sollte die Token übrigens nicht ein einzelner Admin für sich selbst, sondern ein „Verwahrer“ oder das Sicherheitsmanagement nach dem Vier-Augen-Prinzip. Für Alltagsaufgaben haben diese Konten nichts verloren, und mit weiteren Methoden wie der Authenticator-App sollte man sie auf keinen Fall kombinieren.

Jede Anmeldung eines Notfallkontos löst einen Alarm aus

Am gefährlichsten ist ein Notfallzugang, dessen Nutzung niemand bemerkt, ganz gleich, ob ein Angreifer dahintersteckt oder ein Fehlgebrauch. Abhilfe schaffen gezielte Alerts in Log Analytics. Dafür müssen die SigninLogs an einen Log-Analytics-Workspace gesendet werden (Lizenz: Entra ID P1 oder höher, Diagnostic Setting aktiviert). Unter Workspace → Logs legen Sie mit der folgenden KQL-Abfrage einen Alert an, der jede Anmeldung eines Break-Glass-Kontos erfasst:

SigninLogs
| where UserId in ("<Objekt-ID-Konto-1>", "<Objekt-ID-Konto-2>")

Als Alert-Rule ist das in wenigen Minuten eingerichtet. Ich ergänze zusätzlich eine automatische Benachrichtigung an ein eigenes SOC-Postfach. Den regelmäßigen Test der Konten ersetzt das Monitoring allerdings nicht. Mindestens einmal im Quartal sollte man sich testweise anmelden und dabei alle Komponenten prüfen, also Schlüssel, Gruppenmitgliedschaft und Richtlinie.

Der sichere Break-Glass-Prozess folgt einem festen Ablauf

Das folgende Diagramm zeigt, wie ein Notfallzugang mit FIDO2 und CBA abläuft, vom Auslöser bis zum Alarm:

flowchart TD
    Ausfall["Admin-Zugang verloren"] --> Safe1["FIDO2-Token aus Safe 1"]
    Ausfall --> Safe2["Smartcard aus Safe 2"]
    Safe1 --> FIDOLogin["Login mit FIDO2"]
    Safe2 --> CBALogin["Login mit CBA"]
    FIDOLogin --> CA["Conditional Access prüft Authentifizierungsstärke"]
    CBALogin --> CA
    CA --> Zugriff["Admin-Zugang gewährt"]
    Zugriff --> Monitoring["Sign-in Monitoring: Alert"]

Abbildung: Notfallzugang über getrennte Methoden mit Monitoring und CA-Prüfung.

Break-Glass-Konten gehören in die Routine und nicht in die Schublade

Einmal einrichten und dann vergessen, das funktioniert bei Break-Glass-Konten nicht mehr. Sie brauchen ein sauberes, professionelles Verfahren. Wer sich an Microsofts aktuelle Empfehlungen hält, den Einsatz der Konten regelmäßig übt und das Monitoring ernst nimmt, schließt eine der letzten großen Lücken bei den Identitäten in Microsoft 365 und Azure. Offen gesagt: Ein Notfallzugang, der noch auf einfachen Passwörtern oder der Authenticator-App beruht, entspricht längst nicht mehr dem Stand der Technik. Mehr zur Umsetzung und zu meinen Erfahrungen findet ihr in meinen Beiträgen zum Notfallzugang, zur MFA-Pflicht und zur passenden Authentifizierungsstärke.