Die meisten Unternehmen kennen das Konzept des Break-Glass-Accounts: ein hochprivilegiertes Notfallkonto, das im Ernstfall den Zugriff auf den Microsoft-Tenant sicherstellt. Weniger bekannt ist, dass Microsoft mit der Break-Glass-Application einen alternativen Ansatz ermöglicht, der in bestimmten Szenarien deutliche Vorteile bietet.
Der klassische Break-Glass-Account: Bewährt, aber nicht ohne Schwächen
Ein Break-Glass-Account ist ein interaktives Benutzerkonto mit Global-Administrator-Rechten. Die Anmeldung erfolgt über das Entra-ID-Portal mit Benutzername und FIDO2-Schlüssel oder Passwort. Dieser Ansatz ist erprobt, gut dokumentiert und von Microsoft offiziell empfohlen. Die Stärken liegen in der Einfachheit: Jeder Administrator versteht das Konzept, die Einrichtung ist mit Bordmitteln möglich, und die Bedienung im Notfall erfordert keine speziellen Tools.
Die Schwächen zeigen sich bei genauerem Hinsehen. Als interaktives Benutzerkonto unterliegt der Break-Glass-Account allen benutzerzentrierten Sicherheitsrichtlinien. Zwar wird er aus Conditional-Access-Policies ausgenommen, doch genau diese Ausnahme vergrößert die Angriffsfläche. Zudem ist das Konto anfällig für Credential-basierte Angriffe, selbst wenn FIDO2 eingesetzt wird. Die physischen Schlüssel können verloren gehen, beschädigt werden oder im entscheidenden Moment nicht rechtzeitig verfügbar sein.
Die Break-Glass-Application: Ein neuer Ansatz mit nicht-interaktiver Anmeldung
Eine Break-Glass-Application in Microsoft Entra ID nutzt eine App-Registrierung mit Service-Principal-Authentifizierung. Statt sich als Benutzer anzumelden, authentifiziert sich die Anwendung über eine Kombination aus App-ID und Zertifikat. Die Anmeldung erfolgt nicht-interaktiv – und umgeht damit sämtliche benutzerzentrierten Conditional-Access-Richtlinien von Grund auf, ohne als Ausnahme definiert werden zu müssen.
Das reduziert die Wahrscheinlichkeit, von Fehlkonfigurationen betroffen zu sein, erheblich. Ein großflächiger MFA-Ausfall, eine fehlerhafte Conditional-Access-Policy oder ein kompromittierter Identity Provider – all diese Szenarien betreffen interaktive Benutzerkonten, nicht aber eine korrekt konfigurierte Application. Der Notfallzugriff erfolgt über Microsoft Graph API-Aufrufe, die dieselben administrativen Aktionen ermöglichen wie eine interaktive Session.
Welcher Ansatz passt zu welchem Szenario?
Die Wahl zwischen Account und Application hängt von der Risikolandschaft und den operativen Fähigkeiten des Unternehmens ab. Für Organisationen, deren IT-Teams im Notfall über das Portal arbeiten und administrative Aufgaben manuell durchführen, bleibt der klassische Break-Glass-Account die pragmatische Lösung. Er erfordert keine Entwicklerkenntnisse und funktioniert über den Browser.
Für Unternehmen mit höherem Reifegrad in der Automatisierung bietet die Break-Glass-Application klare Vorteile. Vordefinierte Skripte können im Ernstfall innerhalb von Sekunden ausgeführt werden: Conditional-Access-Richtlinien anpassen, kompromittierte Konten sperren, Gruppenänderungen zurückrollen. Die Fehleranfälligkeit durch menschliche Interaktion sinkt, und die Wiederherstellungszeit verkürzt sich deutlich.
Die optimale Strategie: Beide Ansätze kombinieren
In der Praxis empfiehlt sich ein Defense-in-Depth-Ansatz, der beide Konzepte vereint. Zwei Break-Glass-Accounts für den interaktiven Notfallzugriff, ergänzt durch eine Break-Glass-Application für automatisierte Recovery-Szenarien. Damit ist sichergestellt, dass selbst im Worst Case – wenn ein Ansatz versagt – der alternative Zugriffspfad verfügbar bleibt.
Die Überwachung beider Zugriffswege sollte zentral über ein SIEM erfolgen. Sowohl interaktive als auch nicht-interaktive Anmeldungen müssen mit Echtzeit-Alerting versehen sein. Unser SOC as a Service bietet dafür die passende Infrastruktur, damit kein Notfallzugriff unbemerkt bleibt.
Sie möchten Ihre Notfallstrategie auf den Prüfstand stellen? Unsere Cyber Security-Experten entwickeln mit Ihnen ein resilientes Break-Glass-Konzept.
