Ein Notfallkonto ist kein zweites Administratorkonto

Ein hochprivilegiertes Notfallkonto löst einen Widerspruch: Es muss verfügbar sein, wenn normale Administrationswege ausfallen. Gleichzeitig darf es nicht zum bequemsten und damit gefährlichsten Zugang der Umgebung werden.

Viele Konzepte lösen nur die Aufbewahrungsfrage. Ein Kennwort wird versiegelt, in einem Passworttresor hinterlegt oder zwei Personen bekannt gemacht. Das beweist noch nicht, dass sich im Ernstfall jemand anmelden, die notwendige Änderung ausführen und den Vorgang nachvollziehbar abschließen kann.

Ein Notfallkonto ist deshalb nicht bloß ein Benutzerobjekt. Es ist ein vollständiger Wiederherstellungsweg aus Konto, Authentisierung, Endgerät, Netzpfad, Berechtigung, Entscheidungsrecht, Alarmierung und getesteter Handlungsanweisung.

Zuerst die Ausfallszenarien benennen

„Falls die Administration nicht funktioniert“ ist zu ungenau. Ein regulärer Zugang kann aus unterschiedlichen Gründen unbrauchbar werden:

• Der zentrale Identitätsdienst oder eine Föderation ist nicht erreichbar.
• Eine fehlerhafte Zugriffsrichtlinie sperrt privilegierte Rollen aus.
• Das reguläre Mehrfaktorverfahren oder seine Geräte stehen nicht zur Verfügung.
• Ein privilegierter Zugang wurde kompromittiert und muss umgangen werden.
• Das Administrationsnetz, der Passworttresor oder eine Bastion ist ausgefallen.
• Die einzigen berechtigten Personen sind nicht erreichbar.
• Eine Fehlkonfiguration muss korrigiert werden, bevor der normale Weg wieder funktioniert.

Aus diesen Szenarien folgt, welche Abhängigkeiten der Notfallweg gerade nicht teilen darf. Ein Cloud-Notfallkonto hilft wenig, wenn es dieselbe ausgefallene Föderation verwendet. Ein lokales Administratorkonto hilft wenig, wenn sein Kennwort ausschließlich in einem nicht erreichbaren Tresor liegt.

Das BSI beschreibt in ORP.4, dass ein Notfallvorsorgekonzept auch dann funktionieren muss, wenn das Identitäts- und Berechtigungsmanagement selbst ausgefallen ist. Diese Forderung lenkt den Blick weg vom einzelnen Konto und hin zur gesamten Kette.

Unabhängigkeit darf keine Schutzlosigkeit bedeuten

Ein Notfallkonto braucht bewusst andere Abhängigkeiten. Daraus folgt nicht, dass jede Sicherheitskontrolle abgeschaltet werden sollte. Der Schutz muss dem außergewöhnlichen Privileg entsprechen und darf nur so gestaltet sein, dass er das angenommene Ausfallszenario übersteht.

Für Microsoft Entra empfiehlt Microsoft in seiner aktuellen Dokumentation zu Emergency-Access-Konten unter anderem mindestens zwei cloudbasierte Konten, Authentisierungsmethoden ohne dieselben Abhängigkeiten wie reguläre Administratorkonten, Schutz vor blockierenden Conditional-Access-Regeln, sichere Aufbewahrung und regelmäßige Validierung. Das sind produktspezifische Empfehlungen. Für lokale Verzeichnisdienste, Netzwerkgeräte, Virtualisierungsplattformen oder andere Cloud-Dienste müssen Anzahl, Authentisierung und Rechte aus deren Architektur und Ausfallszenarien abgeleitet werden.

Allgemein sollten folgende Fragen beantwortet sein:

• Ist die Identität vom regulären Anmeldeweg ausreichend unabhängig?
• Ist das Zugangsmittel auch außerhalb des normalen Tresors oder Gerätepools erreichbar?
• Besitzt der Zugang nur die Rechte, die für die definierten Rettungsmaßnahmen notwendig sind?
• Kann ein Angreifer ihn unbemerkt verwenden?
• Verhindert die Schutzmaßnahme genau den Notfall, für den das Konto gedacht ist?
• Gibt es einen zweiten Weg, wenn Konto oder Zugangsmittel selbst ausfallen?

Die Antwort kann je Plattform verschieden sein. Ein universelles „Break-Glass-Rezept“ wäre gerade bei Authentisierung und Rollen gefährlich.

Befugnis, Zugriff und Ausführung trennen

Wer das Kennwort technisch verwenden kann, ist nicht automatisch befugt, den Notfall auszurufen. Umgekehrt darf eine entscheidungsbefugte Führungskraft nicht der einzige Mensch sein, der die technischen Schritte ausführen kann.

Ein tragfähiges Modell unterscheidet mindestens:

• Wer stellt fest, dass die Auslösekriterien erfüllt sind?
• Wer gibt die Nutzung verbindlich frei?
• Wer entnimmt oder aktiviert die Zugangsmittel?
• Wer führt die technische Maßnahme aus?
• Wer überwacht und protokolliert den Vorgang?
• Wer setzt Zugangsmittel und Umgebung anschließend in einen sicheren Zustand zurück?

Bei besonders weitreichenden Konten kann eine Mehrpersonenregel angemessen sein. Sie darf jedoch keinen einzelnen, nicht verfügbaren Entscheider zum neuen Ausfallpunkt machen. Vertretung, Eskalation und ein zeitkritischer Ausnahmeweg gehören deshalb in dasselbe Modell.

Die CISA nennt für Break-Glass-Zugänge in Cloud-Szenarien unter anderem starken Schutz, die mögliche Koordination mehrerer Personen sowie umfangreiche Protokollierung und Erkennung. Welche Kontrolle angemessen ist, hängt von Risiko, Plattform und Wiederherstellungsziel ab.

Jede Nutzung muss auffallen

Ein Konto, das im Normalbetrieb nie verwendet werden soll, besitzt ein besonders klares Überwachungssignal: Jede Anmeldung ist ein Ereignis, das unmittelbar geprüft werden muss. Dasselbe gilt für Änderungen an Kennwort, Authentisierungsmethoden, Rollen und Alarmregeln.

Microsoft empfiehlt für seine Plattform eine hoch priorisierte Alarmierung bei jeder Anmeldung und Änderung eines Emergency-Access-Kontos. Diese Security-Operations-Empfehlung ist auf andere Systeme übertragbar, auch wenn die technische Umsetzung anders aussieht.

Die Alarmkette sollte nicht vollständig vom überwachten System abhängen. Wenn der zentrale Dienst gestört ist, muss die Meldung über einen erreichbaren Kanal bei einer handlungsfähigen Rolle ankommen. Ein Logeintrag, den niemand zeitnah prüft, ist keine wirksame Erkennung.

Auch ein angekündigter Test muss alarmieren. Sonst prüft der Test nur den Zugang, nicht die Überwachung.

Konstruiertes Beispiel: Das Passwort ist da, der Zugang nicht

Das folgende Beispiel ist konstruiert.

Eine fehlerhafte Zugriffsrichtlinie sperrt alle regulären Cloud-Administratoren aus. Für diesen Fall liegt das Kennwort eines Notfallkontos in einem Tresor. Beim Anmeldeversuch stellt das Team fest, dass auch dieses Konto von derselben Richtlinie erfasst wird. Der zweite Faktor ist außerdem an ein Mobiltelefon eines abwesenden Mitarbeiters gebunden.

Auf dem Papier existiert ein Break-Glass-Konto. Praktisch teilen normaler und alternativer Zugang dieselben Ausfallursachen. Der Fehler wäre bei einem vollständigen Test sichtbar geworden: Zugangsmittel entnehmen, von einem vorgesehenen Endgerät anmelden, eine harmlose privilegierte Prüffunktion ausführen, Alarm empfangen und den Ablauf ordnungsgemäß beenden.

Das Beispiel zeigt auch, warum eine reine Kennwortkontrolle zu kurz greift. Verfügbarkeit entsteht erst aus der erfolgreich geprüften Kette.

Die Notfallzugangs-Karte

Für jede kritische Plattform sollte eine knappe Karte die technische und organisatorische Kette verbinden.

Feld	Inhalt
Plattform und Zweck	welches System mit welchem Rettungsziel erreicht werden soll
Auslösekriterien	konkrete Szenarien, in denen die Nutzung zulässig ist
ausgeschlossene Nutzung	normale Administration, Bequemlichkeit oder Umgehung regulärer Freigaben
Konto und Rechte	Identität, wirksame Rollen und bewusste Begrenzungen
unabhängige Abhängigkeiten	Identitätsweg, Authentisierung, Endgerät, Netz und Tresor
Entscheidungsrecht	Freigabe, Vertretung und zeitkritische Eskalation
Zugangsmittel	sichere Aufbewahrung und berechtigte Entnahme
Alarmierung	Empfänger, Kanal, Priorität und erwartete Reaktion
Arbeitsschritte	zulässige Rettungsmaßnahmen und Abbruchkriterien
Nachbereitung	Protokollsicherung, Änderungskontrolle, Rücksetzung und Review
letzter Test	Datum, Umfang, Ergebnis, Abweichung und nächster Termin

Die Karte gehört in die technische Wiederanlaufdokumentation und muss auch dann erreichbar sein, wenn zentrale Systeme gestört sind. Eine Offline-Kopie kann sinnvoll sein, braucht aber Schutz, Versionierung und einen geregelten Aktualisierungsweg.

Testen heißt die vollständige Kette durchlaufen

Eine Bestandsprüfung bestätigt nur, dass das Konto existiert. Ein Wirksamkeitstest prüft den tatsächlichen Ablauf:

1. Das Szenario und ein sicherer Testumfang werden freigegeben.
2. Die vorgesehenen Personen finden die aktuelle Anweisung und erhalten die Zugangsmittel.
3. Die Anmeldung erfolgt über den vorgesehenen unabhängigen Weg.
4. Eine ungefährliche, aber hinreichend privilegierte Prüfhandlung bestätigt die Rolle.
5. Alarmierung und Reaktion werden beobachtet.
6. Protokolle werden gesichert und der Vorgang dokumentiert.
7. Zugangsmittel werden bei Bedarf erneuert oder zurückgesetzt.
8. Abweichungen erhalten Owner und Termin.

Der Test darf keine riskante Produktivänderung erzwingen. Eine reine Anmeldung kann andererseits zu wenig sein, wenn erst beim Zugriff auf die notwendige Funktion ein weiterer Schutz oder eine fehlende Rolle sichtbar wird. Der Umfang muss plattformspezifisch und sicher gewählt werden.

Wie bei einem Restore-Test ist ein erfolgreiches Teilergebnis kein Beweis für die ganze Wiederherstellung. Ein verfügbares Konto ohne erreichbare Dokumentation, funktionierende Alarmierung oder befugte Bediener bleibt ein unvollständiger Notfallweg.

Nach der Nutzung beginnt die Sicherung

Der Notfall endet nicht mit der erfolgreichen Reparatur. Danach muss geklärt werden:

• Welche Aktionen wurden mit dem Konto ausgeführt?
• Welche Konfigurationen oder Rollen wurden verändert?
• Sind Kennwort, Schlüssel oder Authentisierungsmittel zu erneuern?
• Wurden temporäre Ausnahmen und Berechtigungen vollständig zurückgenommen?
• Warum war der reguläre Administrationsweg nicht verfügbar?
• Muss der Notfallablauf oder das Monitoring angepasst werden?

Die Nutzung sollte außerdem in den geregelten Incident- und Change-Kontext überführt werden. Das schafft keine nachträgliche Bürokratie, sondern stellt sicher, dass Rettungsmaßnahmen nicht als unbekannte Dauerlösung verbleiben.

Der pragmatische Einstieg ist eine einzige kritische Plattform. Benennen Sie das wahrscheinlichste Aussperr- oder IAM-Ausfallszenario. Zeichnen Sie alle Abhängigkeiten vom Entscheider bis zur erfolgreichen privilegierten Handlung auf. Führen Sie anschließend einen sicheren Ende-zu-Ende-Test durch. Jede Abhängigkeit, die nur angenommen, aber nicht geprüft wurde, ist der nächste konkrete Arbeitsauftrag.