Break-Glass-Konten sind nicht einfach ein weiterer MFA-geschützter Admin

Jeder MSP wird irgendwann gefragt, warum ein Kunde eigene Notfallzugriffskonten benötigt, wenn ohnehin jeder Admin zur Multi-Faktor-Authentifizierung verpflichtet ist. Die Antwort: Break-Glass-Konten lösen ein anderes Problem – sie müssen nutzbar bleiben, wenn der Identitätsanbieter oder das MFA-System selbst nicht verfügbar ist, statt eine weitere Schicht auf ein bereits funktionierendes System zu legen.

Was Microsoft empfiehlt

Microsofts Leitfaden für Entra ID verlangt mindestens zwei reine Cloud-Notfallzugriffskonten, die nicht aus einem lokalen Verzeichnis synchronisiert und nicht über einen externen Identitätsanbieter föderiert werden – denn ein Konto, das von derselben Infrastruktur abhängt, die es retten soll, ist kein echtes Notfallkonto. Microsoft empfiehlt Phishing-resistente Authentifizierung wie FIDO2-Schlüssel oder zertifikatsbasierte Authentifizierung, bewusst unabhängig von den Methoden, die normale Admins verwenden, sowie eine dauerhafte – nicht berechtigte oder zeitlich begrenzte – Zuweisung der Rolle 'Globaler Administrator' in Privileged Identity Management, da ein Aktivierungsworkflow genau das ist, was bei einem Ausfall möglicherweise nicht funktioniert. Diese Konten sollten weiterhin durch Richtlinien für bedingten Zugriff abgedeckt sein, die Phishing-resistente MFA verlangen; die empfohlene Ausnahme betrifft ausdrücklich die geolokalisierungsbasierte Sperre und nicht Zugriffskontrollen im Allgemeinen, da es in der Vergangenheit Fälle gab, in denen legitime Anmeldungen stundenlang geografisch falsch eingestuft wurden.

Was NIST und OWASP ergänzen

Die Kontrolle AC-2(2) aus NIST SP 800-53 beschreibt Notfallkonten als etwas, das für eine definierte Krise aktiviert und danach automatisch deaktiviert oder entfernt wird, statt unbegrenzt zu bestehen. Die MFA-Leitlinien von OWASP kennzeichnen Wiederherstellungs- und Umgehungsprozesse als eigenständiges Angriffsziel: Der Mechanismus, der im Notfall den Zugriff wiederherstellt, darf nicht stillschweigend zu einem Weg werden, MFA unter normalen Bedingungen zu umgehen.

Wie „Beweisen, dass es funktioniert“ aussieht

• Anmeldungen bei diesen Konten gezielt überwachen, mit einer Warnung bei jedem Versuch – erfolgreich oder fehlgeschlagen.
• Zugriffsübungen in festem Turnus durchführen, üblicherweise alle 90 Tage, statt anzunehmen, dass die Einrichtung noch funktioniert.
• Nach jedem echten Einsatz oder jeder Übung ein kurzes Post-Mortem verfassen und die Einrichtung anhand der Ergebnisse anpassen.
• Dokumentieren, wer Zugangsdaten abrufen kann und wie, denn Redundanz ohne Abrufprozess ist nicht wirklich redundant.

Ein Notfallzugriffsdesign, das nie unter simulierten Ausfällen getestet wurde, ist keine Absicherung – es ist eine Annahme.

Quellen: Microsoft Learn – Notfallzugriffskonten, NIST SP 800-53 Rev. 5.