In vielen Tenants, die ich mir anschaue, laufen Notfallzugriffskonten noch immer unter „machen wir später“. Dabei weiß eigentlich jeder, wie schnell man sich mit einer zu strengen oder fehlerhaften Conditional-Access-Richtlinie selbst aussperrt. Durch die angekündigte verpflichtende Azure-MFA für alle (mehr dazu hier) wird das Thema noch drängender. Wer für den Ernstfall nichts vorbereitet hat, verliert womöglich für Tage die Kontrolle.

Ein gutes Notfallzugriffskonto folgt wenigen festen Grundsätzen

Die Anforderungen an sogenannte „Break-Glass-Accounts“ beschreibt Microsoft recht deutlich (Dokumentation). In der Praxis halte ich mich an ein paar Grundsätze, die sich über die Jahre bewährt haben. Ich lege zwei Cloud-only-Konten im onmicrosoft.com-Standardtenant an, beide mit globalen Administratorrechten. Sie bekommen keine persönlichen Mailadressen, gehören keiner echten Person und sind mit keiner Handynummer verknüpft. Die Passwörter sind lang und zufällig erzeugt. Hinterlegt werden sie an zwei räumlich getrennten Orten im Unternehmen, ganz klassisch im Tresor, dokumentiert und nach jedem Test neu gesetzt. Als zweiten Faktor setze ich grundsätzlich FIDO2-Keys ein. Sie schützen vor Phishing und stellen sicher, dass sich auch im Notfall niemand allein mit dem Passwort anmelden kann.

Konten, die nur durch ein Passwort geschützt sind, waren früher weit verbreitet. Heute haben sie in einem Tenant nichts mehr verloren, und mit der MFA-Pflicht für Azure werden sie ohnehin bald unbrauchbar. Auch wenn ein Tenant bislang weder passwortlose noch phishingresistente MFA erzwingt, sollte man jetzt umstellen. Der Aufwand hält sich in Grenzen, die Sicherheit steigt dagegen deutlich.

Die Conditional-Access-Ausnahmen bleiben bewusst eng gefasst

Immer wieder sehe ich, dass Notfallzugriffskonten viel zu großzügig von Conditional-Access-Richtlinien ausgenommen werden. Natürlich müssen sie im Notfall funktionieren. Das ist aber kein Grund, sie von sämtlichen Sicherheitsmaßnahmen zu befreien. Ausnahmen halte ich bei Richtlinien für sinnvoll, die etwa den Zugriff auf administrative Portale oder MFA-Anforderungen regeln, alles andere bleibt aktiv. Vor allem den Schutz durch phishingresistente MFA darf man nicht aushebeln. Als Orientierung eignet sich die von Microsoft empfohlene Baseline-Richtlinie für alle Benutzer (mehr dazu hier).

Die Ausnahmen sollte man regelmäßig kontrollieren und bei jeder neuen Richtlinie daran denken, die Break-Glass-Accounts richtig einzubeziehen. Die beste Dokumentation hilft nicht weiter, wenn im Ernstfall dann doch etwas blockiert.

Sentinel und Log Analytics melden jede Anmeldung eines Notfallkontos

Die Überwachung ist mindestens so wichtig wie die technische Absicherung. Sobald sich ein Notfallkonto anmeldet, muss sofort ein Alarm ausgehen. Meist nutze ich dafür eine Alert-Regel in Azure Sentinel, die auf den Entra-ID-SigninLogs aufsetzt. Diese sind über die Log-Analytics-Integration angebunden. Das folgende KQL-Snippet filtert alle Anmeldungen der Notfallzugriffskonten heraus und taugt direkt als Grundlage für einen Alarm:

SigninLogs
| where UserPrincipalName in ("[email protected]", "[email protected]")
| where ResultType == 0

Aus der Praxis kann ich empfehlen, bei jeder erfolgreichen (und fehlgeschlagenen) Anmeldung eines Notfallkontos eine E-Mail und optional einen Teams-Alarm zu verschicken. Die Zugriffe selbst sollten mindestens einmal im Quartal überprüft werden. Regelmäßige, dokumentierte Tests sorgen außerdem dafür, dass im Fall der Fälle keine bösen Überraschungen warten.

Lebenszyklus und Dokumentation verdienen genauso viel Aufmerksamkeit

Mit dem Anlegen allein ist es bei einem Notfallkonto nicht getan. In mehreren Umgebungen erlebe ich, dass niemand die Passwörter rotiert oder dass FIDO2-Keys verloren gehen. Ist der Prozess nicht sauber dokumentiert, weiß im Ernstfall womöglich keiner mehr, wie man an den zweiten FIDO2-Schlüssel kommt oder wo das Passwort hinterlegt ist. Auch die Zugriffsrechte der Notfallkonten gehören regelmäßig auf den Prüfstand, und für alltägliche Admin-Aufgaben dürfen die Konten nie verwendet werden.

Abhilfe schafft ein klar definierter Prozess, der jeden Schritt festlegt – von der Erstellung über Tests und Hinterlegung bis zur regelmäßigen Überprüfung. Die Dokumentation gehört an einen sicheren Ort, auf den das Notfallteam trotzdem zugreifen kann, und sie muss die Zuständigkeiten eindeutig benennen.

Im Ernstfall greifen die Bausteine in fester Reihenfolge ineinander

Wie die einzelnen Komponenten zusammenspielen, zeigt das folgende einfache Ablaufdiagramm, das ich dafür erstellt habe:

flowchart TD
A["Notfall: Kein Zugriff"] --> B["Login mit Break Glass Account"]
B --> C["Phishingresistentes MFA (FIDO2)"]
C --> D["Sign-In überwacht (Sentinel)"]
D --> E["Alarm & Dokumentation"]
E --> F["Tenant-Fehler beheben"]

Abbildung: Ablauf einer Notfallanmeldung mit Break-Glass-Account, MFA und Überwachung.

Mit eingeübter Routine bleibt im Ernstfall die Panik aus

Mit Notfallzugriffskonten verhält es sich wie mit dem Feuerlöscher im Serverraum. Man hofft, ihn nie zu brauchen, doch wenn es so weit ist, muss er funktionieren. Die technischen Anforderungen sind 2024 klarer und strenger als je zuvor. Wer sich an die Empfehlungen hält, schließt die typischen Lücken und muss im entscheidenden Moment keine Zeit mit Improvisieren vergeuden. Gefährlich wird es weniger durch die Technik als durch Nachlässigkeit im Alltag, etwa beim Testen, Hinterlegen und Überwachen. Wer das Thema ernst nimmt, schläft ruhiger und hat den Kopf frei für die wirklich spannenden Projekte.