Vertrauen wiederherstellen: Notfallzugänge, Schlüssel und ihre Fristen

Der Zugang zum Sicherungssystem hängt am Verzeichnisdienst, der Verzeichnisdienst soll aus der Sicherung kommen, und der Schlüssel dafür liegt im Geheimnisspeicher hinter derselben Anmeldung. Dieses Modul löst diesen Kreis auf und zeigt die Fristen, die dabei über Erfolg entscheiden: warum ein zur Löschung vorgemerkter Schlüssel schon 30 Tage vor seinem Ende unbenutzbar ist, warum Rotation alte Sicherungen nicht gefährdet und nach einem Vorfall trotzdem nicht genügt, und warum ein Notfallkonto genau an den Maßnahmen scheitert, die Alltagskonten schützen.

Lehrtext · 11 Abschnitte · zuletzt geprüft: 2026-09-04

Vor dem ersten Restore steht eine Anmeldung

Jede Wiederherstellung beginnt damit, dass sich jemand irgendwo anmeldet: am Sicherungssystem, an der Virtualisierungsplattform, am Speichersystem. Und jede Entschlüsselung beginnt damit, dass ein Schlüssel verfügbar ist. Beides gehört nicht zu den Daten, die gesichert werden — beides ist die Voraussetzung dafür, überhaupt anzufangen.

Daraus entsteht die unangenehmste Abhängigkeit dieses Themengebiets, und sie ist kreisförmig: Der Zugang zum Sicherungssystem hängt am Verzeichnisdienst. Der Verzeichnisdienst soll aus der Sicherung wiederhergestellt werden. Der Schlüssel für diese Sicherung liegt im Geheimnisspeicher. Der Geheimnisspeicher verlangt eine Anmeldung am Verzeichnisdienst.

Dieser Kreis lässt sich nicht durch bessere Sicherungen auflösen, sondern nur durch einen Weg, der ihn umgeht: einen Zugang, der ohne den Verzeichnisdienst funktioniert, und einen Schlüssel, der ohne den Geheimnisspeicher erreichbar ist. Beides muss vorher eingerichtet und erprobt sein — im Ernstfall ist keine Zeit, es zu bemerken, und die Werkzeuge, mit denen man es einrichten würde, sind genau die ausgefallenen.

Warum dieses Modul früher kommen müsste, als es meist behandelt wirdIdentitäten und Schlüssel gelten als Sicherheitsthema und landen deshalb im Sicherheitsprojekt. Für die Wiederherstellbarkeit sind sie aber die erste Voraussetzung, nicht eine begleitende Maßnahme: Ein Betrieb mit perfekten Sicherungen und ohne Notfallzugang ist im Ernstfall genauso handlungsunfähig wie einer ohne Sicherungen — nur teurer.

Was einen Notfallzugang ausmacht

Notfallzugang — Ein Konto, dessen einziger Zweck darin besteht, handlungsfähig zu bleiben, wenn die üblichen Anmeldewege nicht funktionieren. Es ist kein zweites Administratorkonto für den Alltag, sondern eine Ausnahme mit eigenen Regeln — und es darf von nichts abhängen, wogegen es schützt.

Die Microsoft-Dokumentation für Notfallzugänge in Entra ID führt eine Reihe von Anforderungen auf, die sich fast vollständig auf andere Umgebungen übertragen lassen, weil sie aus derselben Überlegung folgen.

Mindestens zwei Konten: Redundanz, damit ein einzelnes gesperrtes oder verlorenes Konto die Handlungsfähigkeit nicht beendet.
Ohne Abhängigkeit von Verbundanmeldung: Reine Konten des Zielsystems selbst — im dokumentierten Fall solche der .onmicrosoft.com-Domäne, nicht aus einer lokalen Umgebung synchronisiert oder föderiert.
Andere Anmeldeverfahren als die Alltagskonten: Phishing-resistente Verfahren wie FIDO2-Schlüssel oder zertifikatsbasierte Anmeldung — und ausdrücklich andere als die der normalen Administratorkonten.
Keine Bindung an eine Person: Nicht an einzelne Beschäftigte gekoppelt, nicht auf privaten Geräten registriert. Zugangsdaten an einem bekannten, sicheren Ort, der mehreren Personen zugänglich ist.
Getrennte, gesicherte Aufbewahrung: Die Dokumentation nennt getrennte, brandgeschützte Orte für die Zugangsdaten — der Notfallzugang darf nicht mit dem Rechenzentrum verbrennen.

Die zweite Zeile ist der Kern und übertragbar auf jede Umgebung: Ein Notfallzugang, der über dasselbe Verzeichnis läuft wie alles andere, ist kein Notfallzugang. Die Frage lautet immer gleich — welche Systeme müssen laufen, damit diese Anmeldung funktioniert? Ist die Antwort dieselbe Liste wie beim Alltagskonto, ist nichts gewonnen.

Der Zugang, der genau im Ernstfall blockiert

Die Schutzmaßnahmen, die für Alltagskonten richtig sind, wenden sich beim Notfallzugang gegen ihren Zweck. Die Dokumentation formuliert das so deutlich, dass es sich zu zitieren lohnt: Eine erzwungene bedingte Zugriffsrichtlinie könne die Anmeldung genau in dem Notfall verhindern, für den das Konto gedacht ist.

Bedingte Zugriffsrichtlinien prüfen Standort, Gerätezustand oder Netz — alles Dinge, die im Ernstfall anders aussehen als im Alltag. Notfallkonten gehören deshalb ausgenommen, und die Ausnahme braucht eine eigene Überwachung.
Rollenaktivierung auf Anforderung ist im Alltag die bessere Praxis. Für den Notfallzugang ist die Rolle dauerhaft aktiv zuzuweisen, nicht nur berechtigend — sonst hängt die Handlungsfähigkeit an einem Aktivierungsvorgang.
Genehmigungspflichtige Aktivierung ist der gefährlichste Fall. Die Dokumentation beschreibt eine vollständige Aussperrung: Wenn alle Rollenzuweisungen nur berechtigend sind, die Aktivierung eine Genehmigung verlangt und keine genehmigungsberechtigte Person aktiv ist, kann niemand mehr genehmigen — die Verwaltung ist wirksam gesperrt.
Ablaufende Anmeldeinformationen beenden den Zugang lautlos. Dazu gleich mehr.

Das Muster hinter allen vier PunktenJede dieser Maßnahmen ist im Alltag richtig und im Notfall eine zusätzliche Abhängigkeit. Der Entwurf eines Notfallzugangs besteht deshalb weniger darin, ihn abzusichern, als darin, Abhängigkeiten von ihm zu entfernen — und den Verlust an Kontrolle durch Überwachung auszugleichen, statt durch Bedingungen. Anders gesagt: Der Notfallzugang wird nicht durch Hürden geschützt, sondern dadurch, dass jede seiner Benutzungen sofort auffällt.

Ablauf und automatische Bereinigung

Die unauffälligste Art, einen Notfallzugang zu verlieren, ist, ihn gut zu verwalten. Kennwortablauf, Aufräumroutinen für ungenutzte Konten, Ablaufdaten auf Zertifikaten und Sicherheitsschlüsseln — alles Mechanismen, die im Alltag sinnvoll sind und deren gemeinsame Wirkung darin besteht, ein Konto zu entfernen, das definitionsgemäß nie benutzt wird.

Die Dokumentation nennt die Anforderung ausdrücklich: Anmeldeinformationen und Geräte der Notfallkonten dürfen nicht ablaufen und nicht der automatischen Bereinigung unterliegen. Das ist keine Bequemlichkeit, sondern die Bedingung dafür, dass ein Konto nach zwei Jahren Nichtbenutzung noch funktioniert.

Die Prüfung, die dazugehörtWeil der Zugang nie benutzt wird, verrottet er unbemerkt — die Ausnahme von der Bereinigung wird bei einer Umstellung vergessen, das Verfahren wird abgekündigt, der Sicherheitsschlüssel liegt in einer Schublade, deren Schlüssel niemand mehr hat. Die Dokumentation verlangt deshalb regelmäßige Überprüfung der Konten. Praktisch heißt das: sich zweimal im Jahr tatsächlich anmelden, den Vorgang protokollieren und die Protokollierung als erwarteten Eintrag behandeln. Ein Notfallzugang, der seit drei Jahren nicht erprobt wurde, ist eine Annahme.

Schlüssel: Rotation ist harmlos, Löschung ist endgültig

Bei Schlüsseln werden zwei Vorgänge regelmäßig verwechselt, die für die Wiederherstellbarkeit gegensätzlich wirken. Die AWS-Dokumentation beschreibt beide präzise, und die Aussagen gelten sinngemäß für jede Schlüsselverwaltung mit Versionsbegriff.

Rotation: Ändert nur das aktuelle Schlüsselmaterial. Beim Entschlüsseln wird automatisch das Material verwendet, mit dem verschlüsselt wurde; eine bestimmte Version lässt sich für die Entschlüsselung gar nicht auswählen. Alte Sicherungen bleiben lesbar.
Löschung: Entfernt das Schlüsselmaterial und alle Metadaten und ist unumkehrbar. Danach sind alle damit verschlüsselten Daten nicht mehr entschlüsselbar — endgültig.
Deaktivierung: Der dokumentierte Zwischenweg: Wer unsicher ist, deaktiviert statt zu löschen. Ein deaktivierter Schlüssel lässt sich wieder aktivieren, ein gelöschter nicht.

Für den Betrieb folgt daraus eine beruhigende und eine beunruhigende Erkenntnis. Beruhigend: Turnusmäßige Rotation gefährdet die Aufbewahrungstiefe nicht — alte Bestände bleiben lesbar, solange der logische Schlüssel existiert. Beunruhigend: Der logische Schlüssel ist damit ein einzelner Gegenstand, dessen Löschung die gesamte Aufbewahrungstiefe auf einmal vernichtet.

Die Konsequenz für den BetriebAus beidem zusammen folgt eine klare Trennung im Umgang. Rotation gehört in den Regelbetrieb und braucht keine besondere Vorsicht — sie ist für die Wiederherstellbarkeit folgenlos. Löschung gehört in eine sehr kurze Liste von Vorgängen mit doppelter Freigabe, und zwar nicht wegen ihres Sicherheitsrisikos, sondern wegen ihrer Reichweite: Ein einziger Schlüssel trägt in aller Regel sämtliche Aufbewahrungsstände eines Dienstes. Wer diese Trennung nicht macht, behandelt beide Vorgänge gleich vorsichtig — und weil Rotation häufig vorkommt, wird die Vorsicht dann für beide abgeschliffen.

Die Frist, in der der Schlüssel schon tot ist

Weil die Löschung so folgenreich ist, erzwingen Schlüsselverwaltungen eine Wartefrist. Genau in dieser Frist steckt eine Falle, die auf den ersten Blick wie ein Sicherheitsnetz aussieht.

Noch 29 Tage — und trotzdem kein Restore möglich

Szenario

Beim Aufräumen alter Ressourcen wird ein Schlüssel zur Löschung vorgemerkt; die voreingestellte Wartefrist von 30 Tagen läuft. Am Folgetag wird ein Restore aus einer Sicherung nötig, die mit diesem Schlüssel verschlüsselt wurde. Die Annahme im Team lautet: Es sind noch 29 Tage Zeit, der Schlüssel ist also noch da.

Anforderungen

Der Restore soll heute gelingen.
Die Ursache soll verstanden werden, damit sie nicht wiederkehrt.

Schritte

Den Restore versuchen und feststellen, dass die Entschlüsselung fehlschlägt, obwohl der Schlüssel in der Übersicht noch vorhanden ist.
Die Dokumentation lesen: Während der Wartefrist steht der Schlüssel im Zustand Pending deletion und kann in keinerlei kryptografischen Vorgängen verwendet werden. Er existiert, aber er arbeitet nicht.
Den dokumentierten Ausweg nutzen: Die vorgemerkte Löschung lässt sich vor Ablauf der Frist zurücknehmen. Erst danach ist der Schlüssel wieder benutzbar.
Die Ursache abstellen: Für Schlüssel, die Sicherungen schützen, eine ausdrückliche Kennzeichnung vergeben und die Löschung an eine zweite Freigabe binden.
Die Frühwarnung einrichten, die die Dokumentation nennt — eine Meldung, sobald jemand versucht, einen zur Löschung vorgemerkten Schlüssel zu benutzen.

Merksatz: Die Wartefrist schützt vor der endgültigen Vernichtung, nicht vor dem Ausfall. Ab der Vormerkung ist der Schlüssel für den Betrieb bereits verloren — die Frist ist ein Fenster zum Zurücknehmen, kein Weiterbetrieb. Wer sie als Sicherheitsnetz einplant, hat 7 bis 30 Tage lang keine Wiederherstellbarkeit und merkt es erst beim Versuch.

Rotation schützt nicht rückwirkend

Nach einem Sicherheitsvorfall ist der erste Reflex, alle Schlüssel zu rotieren. Für künftige Daten ist das richtig. Für die vorhandenen Sicherungen leistet es nichts, und auch das steht so in der Dokumentation.

Dort heißt es unmissverständlich: Die Rotation hat keine Auswirkung auf die Daten, die der Schlüssel schützt. Sie rotiert nicht die von ihm erzeugten Datenschlüssel und verschlüsselt keine bereits geschützten Daten neu. Und ausdrücklich: Sie mildert nicht die Folgen eines kompromittierten Datenschlüssels.

Was Rotation bewirkt: Neue Daten werden mit neuem Material verschlüsselt. Der Zeitraum, in dem ein einzelnes Material gilt, wird begrenzt.
Was Rotation nicht bewirkt: Vorhandene Sicherungen bleiben mit dem alten Material verschlüsselt. Wer dieses Material besitzt, kann sie weiterhin lesen.
Was nach einer Kompromittierung nötig ist: Neuverschlüsselung der betroffenen Bestände — also erneutes Schreiben — oder ihre kontrollierte Vernichtung. Beides ist Arbeit, keine Einstellung.

Die Frage, die vorher zu klären istWenn ein Schlüssel als kompromittiert gilt, stellt sich sofort die unangenehme Rechnung: Wie viele Aufbewahrungsstände sind damit verschlüsselt, und wie lange dauert es, sie alle neu zu schreiben? Bei zwölf Monatsständen von je mehreren Terabyte ist die Antwort in Tagen zu messen — und während dieser Zeit läuft die Aufbewahrung mit einem Schlüssel weiter, dem man nicht mehr traut. Diese Rechnung gehört in den Entwurf, nicht in den Vorfall.

Zertifikate und die Zeit während des Ausfalls

Ein wiederhergestelltes System kommt mit dem Zustand seines Sicherungszeitpunkts zurück — auch mit dessen Zertifikaten. Liegt der Stand weit genug zurück oder dauerte der Ausfall lange genug, sind sie abgelaufen. Das System läuft dann technisch einwandfrei und ist für Clients nicht benutzbar.

Der Fall tritt in zwei Spielarten auf, und die zweite überrascht auch erfahrene Teams. Erstens: Der wiederhergestellte Stand ist älter als die Restlaufzeit des Zertifikats — dann ist es schlicht abgelaufen. Zweitens: Der Ausfall selbst dauerte länger als die Restlaufzeit. Ein Zertifikat mit drei Wochen Restgültigkeit und ein Wiederanlauf, der sich über vier Wochen zieht, ergeben denselben Zustand, ohne dass der Sicherungsstand alt war. Beide Fälle brauchen dieselbe Vorsorge, und beide fallen erst auf, wenn ein Client sich verbindet.

Kurzcheck

Ein Dienst wird aus einem drei Monate alten Stand wiederhergestellt. Sein Serverzertifikat war zum Sicherungszeitpunkt gültig und ist inzwischen abgelaufen. Was ist der belastbare Umgang damit?

Ein neues Zertifikat ausstellen und einspielen — das gehört als eigener Schritt in den Wiederanlaufplan.
Die Systemzeit des wiederhergestellten Systems auf den Sicherungszeitpunkt zurückstellen, damit das Zertifikat gültig ist.
Das abgelaufene Zertifikat vorübergehend auf den Clients als vertrauenswürdig eintragen.

Treffer. Richtig. Zertifikate haben eine eigene Lebensdauer, die von der Sicherung unberührt bleibt. Der Wiederanlaufplan muss den Ausstellungsweg enthalten, einschließlich der Frage, ob die ausstellende Stelle im Ernstfall erreichbar ist.

Derselbe Gedanke gilt für alles mit Gültigkeitsdauer: Kennwörter von Dienstkonten, Signaturschlüssel, Vertrauensstellungen zwischen Systemen, Lizenzen. Ein Wiederanlaufplan, der einen alten Stand vorsieht, muss eine Zeile enthalten, welche dieser Gegenstände nach dem Restore erneuert werden müssen — und wer das darf.

Doppelte Kontrolle für die endgültigen Schritte

Aus dem bisher Gesagten ergibt sich eine kurze Liste von Vorgängen, die nicht rückgängig zu machen sind und deren Folgen die gesamte Aufbewahrung betreffen. Für sie lohnt sich die zusätzliche Hürde, die man sonst vermeidet.

Löschung eines Schlüssels, mit dem Sicherungen verschlüsselt sind — die Vormerkung allein macht ihn bereits unbenutzbar.
Entfernen einer Aufbewahrungssperre oder Verkürzen einer Frist, wo das technisch möglich ist.
Deaktivieren oder Löschen eines Notfallzugangs, auch im Rahmen einer Aufräumaktion.
Änderung der Ausnahmeregeln, die Notfallkonten von Zugriffsrichtlinien oder Bereinigungen ausnehmen.

Warum die Liste so kurz sein mussDoppelte Kontrolle wirkt nur, solange sie selten verlangt wird. Wer sie über zwanzig Vorgänge legt, bekommt eine Routine, in der die zweite Person unterschreibt, ohne hinzusehen — und hat die Wirkung verloren, ohne den Aufwand loszuwerden. Vier Vorgänge, die höchstens ein paarmal im Jahr vorkommen, halten die Aufmerksamkeit; zwanzig tun es nicht.

Praktisch umgesetzt wird die doppelte Kontrolle selten über ein Werkzeug, sondern über eine Rechteaufteilung: Die Rolle, die den Vorgang auslösen kann, besitzt die Berechtigung dafür nicht dauerhaft, sondern bekommt sie auf Anforderung von einer zweiten Rolle. Das ist im Alltag unbequem und für vier Vorgänge im Jahr vertretbar. Wichtig ist nur, dass die zweite Rolle nicht dieselbe Person ist — und dass ihr Weg auch dann funktioniert, wenn der Verzeichnisdienst nicht läuft, sonst hat man eine weitere Abhängigkeit im Wiederanlauf geschaffen.

Die Reihenfolge im Ernstfall

Alles bisher Gesagte ordnet sich zu einer Reihenfolge, die vor jedem Datenrestore steht. Sie ist kurz, sie ist nicht verhandelbar, und sie ist der Grund, warum dieses Modul vor den Modulen über den eigentlichen Wiederanlauf steht.

Handlungsfähigkeit herstellen — Notfallzugang benutzen→Zugriff auf Schlüssel und Geheimnisse sichern→Prüfen, ob Schlüssel und Zertifikate gültig und benutzbar sind→Erst dann die Wiederherstellung der Daten beginnen

Vertrauen vor Datenpfad

Was diese Reihenfolge im Angriffsfall zusätzlich bedeutetNach einem Angriff kommt eine Frage dazu, die im Ausfallfall keine Rolle spielt: Sind die Identitäten und Schlüssel überhaupt noch vertrauenswürdig? Ein Notfallzugang, dessen Anmeldedaten der Angreifer besitzt, ist kein Notfallzugang mehr. Diese Unterscheidung — und der Wiederaufbau von Vertrauen unter der Annahme, dass die Umgebung kompromittiert war — ist das Thema des nächsten Moduls.

Abgrenzung

Hier geht es um Identitäten und Schlüssel als Voraussetzung der Wiederherstellung. Die Beispiele stammen aus dokumentierten Umgebungen zweier Anbieter; die Entscheidungen dahinter sind produktunabhängig, die genauen Fristen und Bezeichnungen nicht — sie gehören für die eigene Umgebung nachgeschlagen und im Recovery-Vertrag festgehalten.

NachbartracksAufbau und Betrieb von Verzeichnisdiensten stehen in active-directory und microsoft-entra-m365, Zertifikatsverwaltung und Vertrauensketten in pki-tls-operations, Geheimnisverwaltung auf Plattformebene in cloud-infra. Hier interessiert nur, was davon vorhanden sein muss, damit eine Wiederherstellung überhaupt beginnen kann.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität4 Primärquellen · zuletzt geprüft: 2026-09-04