Break-Glass-Accounts in Entra ID: Notfallzugang richtig absichern

Von · Veröffentlicht

Ein Break-Glass-Account ist ein Administratorkonto, das ausschließlich für den Notfall existiert: wenn eine Conditional-Access-Richtlinie alle Administratoren aussperrt, der MFA-Dienst gestört ist oder der Föderationsdienst ausfällt. Im Alltag wird es nie benutzt.

Genau deshalb wird es in vielen Microsoft-365-Umgebungen vergessen – oder es existiert, funktioniert im Ernstfall aber nicht mehr. Dieser Artikel fasst die aktuelle Empfehlung von Microsoft zusammen und zeigt, worauf es in der Praxis ankommt.

Wie viele Konten und welche Art

Microsoft empfiehlt mindestens zwei Notfallkonten, damit der Ausfall eines Kontos nicht den gesamten Notfallzugang kostet. Beide sind reine Cloud-Konten auf der Domain „onmicrosoft.com“ – nicht föderiert und nicht aus dem lokalen Active Directory synchronisiert. So bleiben sie nutzbar, selbst wenn die lokale Infrastruktur oder der Identitätsanbieter ausfällt.

Die Konten erhalten die Rolle Globaler Administrator, und zwar dauerhaft aktiv statt nur „berechtigt“ in Privileged Identity Management. Im Notfall soll keine Aktivierung über einen Prozess nötig sein, der selbst gestört sein könnte.

Authentifizierung: phishing-resistent und anders als im Alltag

Microsoft setzt für die Admin-Portale verpflichtend Multi-Faktor-Authentifizierung durch. Notfallkonten brauchen deshalb eine starke Methode, die diese Anforderung erfüllt. Empfohlen wird ein Passkey (FIDO2-Sicherheitsschlüssel); wer eine eigene PKI betreibt, kann alternativ zertifikatsbasierte Authentifizierung nutzen.

Wichtig ist der Unterschied zu den normalen Admin-Konten: Die Notfallkonten sollen eine andere Methode verwenden. Fällt zum Beispiel das Mobilfunknetz aus und funktioniert die Authenticator-App nicht, bleibt der Hardware-Schlüssel trotzdem nutzbar.

Ausnahme aus Conditional Access

Notfallkonten werden aus allen Conditional-Access-Richtlinien ausgenommen, die eine Anmeldung blockieren oder einschränken können. Am saubersten gelingt das über eine eigene Sicherheitsgruppe, die in jeder relevanten Richtlinie als Ausnahme eingetragen ist. Richtlinien im Berichtsmodus blockieren nicht und brauchen keine Ausnahme.

Prüfen Sie bei jeder neuen Richtlinie, ob die Ausnahme gesetzt ist. Eine einzige vergessene Ausnahme reicht, um den Notfallzugang wertlos zu machen.

Überwachung: Jede Anmeldung ist ein Alarm

Weil die Konten im Alltag nie benutzt werden, ist jede Anmeldung ein Ereignis, das sofort auffallen muss. Microsoft empfiehlt, die Anmeldeprotokolle an einen Log-Analytics-Workspace zu senden und eine Warnregel einzurichten, die bei jeder Anmeldung der Notfallkonten auslöst und Administratoren per E-Mail oder SMS benachrichtigt.

Nach jeder Nutzung folgt eine kurze Nachbetrachtung: Wer hat das Konto benutzt, warum, und war der Einsatz berechtigt?

Aufbewahrung und regelmäßiger Test

Zugangsdaten und Sicherheitsschlüssel werden getrennt an mindestens zwei sicheren Orten aufbewahrt, zum Beispiel in feuerfesten Tresoren, und sind mehreren berechtigten Personen zugänglich – nie nur einer. Sie dürfen weder an persönliche Geräte gebunden sein noch automatisch ablaufen.

Microsoft empfiehlt, den Notfallzugang mindestens alle 90 Tage zu testen sowie nach Personalwechseln in der IT oder Änderungen an Rollen und Lizenzen.

  • Ist die Liste der berechtigten Personen aktuell?
  • Funktioniert die Anmeldung mit der aktuellen Conditional-Access-Konfiguration?
  • Lassen sich administrative Aufgaben ausführen?
  • Löst die Überwachung den Alarm aus?

Fazit

Ein Notfallkonto, das nie getestet wurde, ist im Ernstfall nur eine Annahme. Zwei Cloud-Konten mit Passkey, eine saubere Ausnahme in Conditional Access, ein Alarm bei jeder Anmeldung und ein Test alle 90 Tage machen daraus einen verlässlichen Notfallzugang.

Quellen