Windows Server Administration

Härtung und Wiederherstellung

Eine Sicherung, die läuft, ist eine Datei — ob daraus ein funktionierender Dienst wird, ist eine andere Frage, und sie wird meistens erstmals im Ernstfall gestellt. Dieses Modul behandelt die Windows-Seite davon: welcher Wiederherstellungsweg ein laufendes System voraussetzt und welcher nicht, warum das Kennwort für den Verzeichnisdienst-Wiederherstellungsmodus nach sechs Jahren verlässlich niemand mehr kennt, und warum eine Härtungseinstellung mit UEFI-Sperre auch das Löschen ihres eigenen Schalters überlebt.

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

Sicherung ist ein Artefakt, Wiederherstellung eine Fähigkeit

Eine Sicherung, die läuft, ist eine Datei. Ob sich daraus ein funktionierender Dienst herstellen lässt, ist eine andere Frage — und sie wird in vielen Umgebungen erstmals im Ernstfall gestellt.

Der Unterschied ist nicht theoretisch. Eine Sicherung kann vollständig sein und trotzdem nicht zum Ziel führen: weil der Wiederherstellungsweg ein Medium braucht, das niemand hat; weil die Reihenfolge mehrerer Systeme nicht bekannt ist; oder weil der Server danach zwar startet, aber nicht in ein Netz darf, in dem noch dieselbe Lücke offen ist.

AbgrenzungDer Nachbartrack backup-disaster-recovery behandelt Wiederherstellbarkeit als Disziplin — Wiederherstellungsziele, unabhängige Kopien, unveränderbare Aufbewahrung, Übungsprogramme. Hier geht es um die Windows-Werkzeuge und die Entscheidungen, die auf dem Server selbst fallen: was gesichert wird, womit zurückgeholt wird, und was gehärtet sein muss, damit die Rückkehr nicht in denselben Vorfall führt.

Was Windows Server Backup kann

Windows bringt eine eigene Sicherungsfunktion mit. Sie ist für einzelne Server gedacht, nicht für eine Flotte, und ihre Kommandozeile heißt wbadmin.

wbadmin start backup
Sichert Volumes, Dateien, Ordner oder Anwendungen — je nach Angabe.
wbadmin start systemstatebackup
Sichert den Systemstatus: Registry, Startdateien, Systemdateien, bei einem Domänencontroller auch das Verzeichnis.
wbadmin start recovery
Holt Volumes, Anwendungen, Dateien oder Ordner zurück.
wbadmin start systemstaterecovery
Holt den Systemstatus zurück.
wbadmin start sysrecovery
Vollständige Wiederherstellung des Systems — laut Dokumentation nur in der Wiederherstellungsumgebung verfügbar.
Die Zeile, die den Plan bestimmtDer letzte Eintrag ist der wichtigste: Eine vollständige Systemwiederherstellung läuft nicht aus dem laufenden Windows heraus. Sie setzt voraus, dass man in die Wiederherstellungsumgebung kommt — also genau das, was im Modul über Start und Wiederherstellung als Übernahmeprüfung steht. Ein Wiederanlaufplan, der sysrecovery vorsieht und nicht klärt, wie man dorthin kommt, hat eine Lücke an der teuersten Stelle.

Für den Alltag sind zwei weitere Befehle nützlich. wbadmin get versions listet die vorhandenen Sicherungen mit ihrem Zeitpunkt und ihrer Kennung — die braucht man für jede gezielte Wiederherstellung. wbadmin get items -version:<Kennung> zeigt, was in einer bestimmten Sicherung tatsächlich enthalten ist. Der zweite Befehl beantwortet eine Frage, die überraschend oft offen ist: ob die nächtliche Sicherung wirklich das enthält, was man später zurückholen will, oder ob jemand vor Monaten ein Volume ausgeschlossen hat.

Systemstatus ist nicht das System

Der Systemstatus umfasst die Bestandteile, die einen Windows-Server zu diesem Server machen — nicht die Daten, die darauf liegen. Das macht ihn klein und schnell und beantwortet nur einen Teil der Frage.

Systemstatus
Registry, Startdateien, Systemdateien, Leistungsindikatoren, bei einem Domänencontroller das Verzeichnis. Klein, häufig sicherbar.
Volume-Sicherung
Die Daten. Getrennt zu planen, oft mit anderer Frequenz und anderem Ziel.
Vollständige Wiederherstellung
Alles kritischen Volumes zusammen, aus der Wiederherstellungsumgebung heraus.
Der Fall, der jeden überraschtAuf einem Domänencontroller steckt das Verzeichnis im Systemstatus, und seine Wiederherstellung ist kein normaler Vorgang: Sie läuft im Verzeichnisdienst-Wiederherstellungsmodus, für den ein eigenes Kennwort gilt — dasselbe, das laut Dokumentation Windows LAPS auf Domänencontrollern verwalten kann. Wer dieses Kennwort nicht hat, hat die Sicherung, aber nicht den Weg hinein. Das ist kein seltener Ausnahmefall; es ist der Normalfall in Umgebungen, in denen der Domänencontroller vor Jahren aufgesetzt wurde.

Für die Planung ergibt sich daraus eine einfache Trennung mit zwei Frequenzen. Der Systemstatus ist klein und ändert sich bei jedem Change — er darf und soll häufig gesichert werden, und aus ihm kommt ein Server zurück, der wieder er selbst ist. Die Datenvolumes sind groß und ändern sich nach der Arbeit der Nutzer — ihre Frequenz ergibt sich aus der Frage, wie viel Arbeit im Verlustfall verloren gehen darf. Wer beides in einen Auftrag legt, bekommt entweder eine zu seltene Systemstatussicherung oder eine zu teure Datensicherung.

Was ein Restore-Test wirklich prüft

Ein Wiederherstellungstest, der eine einzelne Datei zurückholt, prüft, dass die Sicherung lesbar ist. Das ist nicht nichts und beantwortet keine der Fragen, die im Ernstfall zählen.

  • Ist das Sicherungsziel im Ernstfall erreichbar — oder hängt es an demselben System, das ausgefallen ist?
  • Wie lange dauert die vollständige Wiederherstellung tatsächlich, gemessen und nicht geschätzt?
  • Wer darf sie auslösen, und ist diese Person im Ernstfall verfügbar?
  • Funktioniert der Dienst danach — geprüft über den Weg, den ein Client benutzt?
Der Test, der nichts kostet und viel sagtDie billigste Steigerung ist, den Test einmal von jemandem durchführen zu lassen, der ihn nicht eingerichtet hat, nur mit der vorhandenen Dokumentation. Was dabei fehlt, fehlt im Ernstfall auch — und es fehlt dann unter Zeitdruck, ohne dass jemand nachfragen kann.

Der Test, der die Zeit misst

Szenario

Für einen Dateiserver mit 4 TB Daten ist eine Wiederanlaufzeit von acht Stunden zugesagt. Die Sicherung läuft auf ein Netzziel über eine 1-Gbit-Anbindung. Ein Wiederherstellungstest hat bisher nur einzelne Dateien geholt.

Anforderungen

  • Die zugesagte Wiederanlaufzeit soll belegt oder widerlegt werden.
  • Der produktive Betrieb soll nicht gestört werden.

Schritte

  1. Die reine Übertragungszeit rechnen: 4 TB über 1 Gbit ergibt bei realistischem Durchsatz deutlich über neun Stunden — allein für die Daten.
  2. Dazu die Zeit für Systemwiederherstellung, Neustarts und fachliche Prüfung addieren.
  3. Ergebnis der Rechnung dem zugesagten Wert gegenüberstellen: Die Zusage ist rechnerisch nicht haltbar.
  4. Einen Test auf einem Ersatzsystem durchführen, um die Rechnung zu bestätigen statt sie zu behaupten.
  5. Entweder die Zusage korrigieren oder das Verfahren ändern — schnelleres Ziel, lokale Kopie, andere Wiederherstellungsreihenfolge.

Merksatz: Die Rechnung dauert fünf Minuten und widerlegt die Zusage, bevor der Ernstfall es tut. Wiederanlaufzeiten, die nie gegen Datenmenge und Bandbreite gehalten wurden, sind Wunschwerte — und im Ernstfall wird daraus ein Vertrauensverlust zusätzlich zum Ausfall.

Härtung hat vier Achsen

Härtung wird oft als Liste von Einstellungen behandelt. Nützlicher ist die Sortierung nach dem, was sie jeweils schwerer machen — denn dieselbe Maßnahme kann auf einer Achse viel und auf einer anderen nichts bringen.

Konten und Rechte
Wer darf sich anmelden, wer darf was? Anmelderechte, Gruppenmitgliedschaften, verwaltete Dienstkonten.
Angriffsfläche
Was läuft überhaupt? Installationsoption, Rollen, Dienste, offene Ports.
Anmeldeinformationen
Was liegt im Speicher und auf der Platte? LSA-Schutz, keine geteilten Kennwörter, kein interaktives Anmelden mit hohen Rechten auf beliebigen Servern.
Nachvollziehbarkeit
Was bleibt übrig, wenn jemand es versucht hat? Protokollierung, Weiterleitung, Aufbewahrung.

Die vierte Achse wird bei Härtungsprojekten regelmäßig übersprungen, weil sie nichts verhindert. Sie ist trotzdem die, ohne die man hinterher nicht sagen kann, ob eine der anderen drei gehalten hat.

Nützlich ist die Sortierung vor allem beim Priorisieren. Eine Umgebung, in der dasselbe lokale Administratorkennwort überall gilt, gewinnt mit einer Maßnahme auf der dritten Achse mehr als mit zwanzig Einstellungen auf der zweiten. Umgekehrt bringt der Verzicht auf eine Rolle, die niemand braucht, auf der zweiten Achse sofort etwas und kostet fast nichts. Die Reihenfolge ergibt sich also nicht aus einer Checkliste, sondern aus der Frage, welche Achse in dieser Umgebung am schwächsten ist.

Der Schutz des Anmeldeinformationsspeichers

Der lokale Sicherheitsdienst prüft Anmeldungen und verwaltet dabei Anmeldeinformationen im Speicher. Genau dieser Speicher ist das Ziel, wenn jemand aus einem kompromittierten Server heraus weiterkommen will.

Zusätzlicher LSA-SchutzEine Einstellung, die den Dienst als geschützten Prozess ausführt. Nicht geschützte Prozesse können seinen Speicher dann weder lesen noch Code in ihn einschleusen.

Der Preis, den man vorher kennen mussIm geschützten Modus muss jedes Plug-in, das in den Dienst geladen wird, digital mit einer Microsoft-Signatur versehen sein. Unsignierte oder anders signierte Plug-ins laden nicht. Betroffen sind laut Dokumentation Chipkartentreiber, kryptografische Plug-ins und Kennwortfilter — also genau die Erweiterungen, die in gewachsenen Umgebungen von Drittanbietern stammen. Ein Härtungsprojekt, das diese Einstellung flächig aktiviert, ohne vorher zu inventarisieren, legt Anmeldewege lahm, an die niemand gedacht hat.

Der Schutz wirkt gegen eine konkrete Angriffsform: das Auslesen des Speichers, um an dort liegende Anmeldeinformationen zu kommen. Er wirkt nicht gegen jemanden, der ohnehin schon als hoch berechtigtes Konto auf dem Server arbeitet — dieser Weg bleibt offen und wird durch die Einstellung nur teurer. Wie bei jeder Maßnahme lohnt es deshalb, sie mit der Angriffsform zu benennen, gegen die sie hilft. Eine Härtungsliste ohne diese Zuordnung lässt sich weder priorisieren noch verteidigen.

Erst prüfen, dann einschalten

Für genau diesen Fall gibt es einen dokumentierten Weg, der die Reihenfolge umdreht: Statt einzuschalten und zu hoffen, lässt sich zuerst protokollieren, welche Plug-ins unter dem Schutz nicht laufen würden.

Alle Plug-ins und Treiber inventarisieren, die in den Sicherheitsdienst geladen werden — auch die von Drittanbietern und die selbst entwickelten.Prüfen, ob sie mit einem Microsoft-Zertifikat signiert sind.Über die Überwachungsprotokolle feststellen, welche unter dem Schutz scheitern würden.Fehlende Signaturen beim Hersteller nachfordern oder das Plug-in ersetzen.Erst danach den Schutz aktivieren — und prüfen, ob alle Plug-ins weiterhin laden.
Der dritte Schritt ist der eigentliche Gewinn: Er beantwortet die Frage ohne Ausfall.
Und ein Werkzeug, das danach fehltBei aktiviertem LSA-Schutz lässt sich kein eigenes Plug-in mehr debuggen, und ein Debugger lässt sich nicht an den geschützten Prozess anhängen. Für einen produktiven Server ist das meistens richtig — für den Server, auf dem jemand ein Herstellerproblem nachstellen soll, ist es eine Einschränkung, die man vorher kennen muss.

Die Tür, die zufällt

Der LSA-Schutz lässt sich über einen Registry-Wert unter HKLM\SYSTEM\CurrentControlSet\Control\Lsa steuern. Das klingt nach einer Einstellung, die man zurücknehmen kann — und unter bestimmten Bedingungen ist sie es nicht.

Wörtlich dokumentiertWird der Schutz zusammen mit UEFI-Sperre und sicherem Start aktiviert, hat das Deaktivieren des Registry-Schlüssels keine Wirkung. Die Einstellung überlebt das Löschen ihres eigenen Schalters. Das ist genau so gewollt — sie soll sich von einem Angreifer nicht abschalten lassen —, und es bedeutet für den Betrieb: Wer diese Kombination einschaltet, trifft eine Entscheidung, die sich nicht durch einen Registry-Eingriff korrigieren lässt. Sie gehört deshalb in dieselbe Kategorie wie die Installationsoption aus dem ersten Modul.

Rückkehr nach einem Vorfall

Nach einem Sicherheitsvorfall ist die Wiederherstellung des Dienstes nicht der letzte Schritt, sondern der vorletzte. Dazwischen liegt die Frage, die im Zeitdruck am liebsten übersprungen wird: Ist der Weg geschlossen, über den jemand hereinkam?

Kurzcheck

Ein kompromittierter Anwendungsserver soll wieder in Betrieb gehen. Die Sicherung von vor dem Vorfall ist vorhanden und geprüft. Was fehlt in dieser Reihenfolge: zurückspielen, starten, freigeben?

  • Der Eintrittsweg muss geschlossen sein, sonst holt die Sicherung ihn zurück
  • Nichts — eine geprüfte Sicherung von vor dem Vorfall ist per Definition sauber
  • Ein zweiter Wiederherstellungstest, um die Integrität der Sicherung zu bestätigen

Treffer. Richtig. Eine Sicherung von vor dem Vorfall enthält den Zustand von vor dem Vorfall — einschließlich der Lücke, über die jemand hereinkam. Ohne Schließen wiederholt sich derselbe Vorgang.

Daraus ergibt sich eine Reihenfolge, die im Ernstfall Zeit kostet und deren Verletzung mehr kostet: eingrenzen, Beweise sichern, Eintrittsweg bestimmen und schließen, wiederherstellen, prüfen, freigeben. Der vorletzte Schritt ist eine fachliche Prüfung über den Clientweg — nicht ein grüner Dienststatus.

Praktisch heißt „Eintrittsweg bestimmen“ nicht, den vollständigen Hergang aufzuklären — das kann Wochen dauern und ist im Wiederanlauf nicht leistbar. Es heißt, die plausiblen Wege zu benennen und die zu schließen, die mit vertretbarem Aufwand zu schließen sind: ein ungepatchter Dienst, ein offener Verwaltungszugang aus einem falschen Netz, ein Dienstkonto mit zu weiten Rechten. Was danach bleibt, gehört als bewusst getragenes Restrisiko in die Freigabeentscheidung, nicht in eine Fußnote.

Was aus einer Sicherung zurückkommen darf

Nicht alles, was in einer Sicherung steht, soll zurück. Bei einer Wiederherstellung nach einem Vorfall gehören drei Dinge getrennt betrachtet.

Daten
Sollen zurück, möglichst aktuell. Der Grund für die ganze Übung.
Konfiguration
Soll zurück — aber ohne die Einstellung, die den Vorfall ermöglicht hat.
Anmeldeinformationen
Sollen nicht unverändert zurück. Was ein Angreifer gesehen haben könnte, ist verbrannt.
Der Punkt, der Projekte sprengtDie dritte Zeile bedeutet in der Praxis: Kennwörter von Dienstkonten drehen, lokale Administratorkennwörter neu setzen, gegebenenfalls Computerkonten neu aufnehmen. Bei verwalteten Dienstkonten übernimmt das Verzeichnis diesen Teil, bei statischen Kennwörtern jemand von Hand — für jeden Dienst, der es benutzt. Das ist der Moment, in dem sich die Entscheidung aus dem Modul über Dienstidentitäten auszahlt oder rächt.

Was in die Übergabe gehört

Wie bei Start und Beobachtbarkeit gilt: Fast nichts davon lässt sich im Ernstfall noch herstellen. Die Liste ist kurz und wird trotzdem selten abgearbeitet.

  • Welche Sicherung gibt es für diesen Server, mit welcher Frequenz und welchem Ziel?
  • Ist das Ziel im Ernstfall erreichbar, wenn dieser Server ausgefallen ist?
  • Wie lange dauert die vollständige Wiederherstellung — gemessen, nicht geschätzt?
  • Gibt es einen Weg in die Wiederherstellungsumgebung, und wer hat die Zugangsdaten?
  • Bei einem Domänencontroller: Wer kennt das Kennwort für den Verzeichnisdienst-Wiederherstellungsmodus?
Die unbequeme ZahlDer dritte Punkt ist der, der Wiederanlaufpläne am häufigsten widerlegt. Eine vollständige Wiederherstellung über das Netz dauert so lange, wie die Datenmenge geteilt durch die Bandbreite ergibt — und diese Rechnung liefert regelmäßig Werte, die weit über der zugesagten Wiederanlaufzeit liegen. Sie einmal zu machen ist billiger, als sie im Ernstfall zu erfahren.

Diese fünf Punkte gehören in dieselbe Übernahmeprüfung wie die aus den Modulen über Start und über Beobachtbarkeit. Zusammen beantworten sie drei Fragen über jeden Server: Wie komme ich an ihn heran, wenn er nicht mehr antwortet? Was kann er mir über sich sagen? Und wie bekomme ich ihn zurück, wenn er weg ist? Alle drei Antworten entstehen an dem Tag, an dem der Server übernommen wird — oder sie entstehen gar nicht.

Der Preis der Härtung

Jede Maßnahme in diesem Modul hat einen Preis, und ihn zu verschweigen macht Härtungsprojekte unglaubwürdig. Drei Muster wiederholen sich.

Etwas läuft nicht mehr
Signaturpflichten, engere Rechte, geschlossene Ports treffen immer auch etwas Legitimes. Der Auditmodus ist die Antwort, wo es ihn gibt.
Etwas lässt sich nicht mehr zurücknehmen
UEFI-gesperrte Einstellungen, Konvertierungen, entfernte Rückwege. Sie gehören vor die Aktivierung, nicht danach.
Etwas wird langsamer oder umständlicher
Zusätzliche Anmeldeschritte, getrennte Verwaltungswege, mehr Freigabeschritte. Wer den Aufwand nicht anerkennt, erzeugt Umgehungen.
Was daraus folgtEine Härtungsmaßnahme ist erst dann fertig, wenn ihr Preis benannt und akzeptiert ist. Eine Maßnahme, die eingeführt und nach drei Wochen unter Druck wieder abgeschaltet wird, hinterlässt weniger als keine — sie hinterlässt den Eindruck, dass Härtung nicht funktioniert, und macht die nächste schwerer.

Für den Betrieb ist daraus eine praktische Regel abzuleiten: Jede Maßnahme bekommt vor der Einführung einen benannten Verantwortlichen, ein Datum für die Wirksamkeitsprüfung und eine Aussage darüber, was passiert, wenn sie etwas blockiert, das gebraucht wird. Der dritte Punkt ist der entscheidende. Ohne ihn wird jede Störung, die zeitlich in die Nähe der Änderung fällt, ihr zugeschrieben — und die Maßnahme fällt, unabhängig davon, ob sie die Ursache war.

Jetzt anwenden

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

Zum Modul →
Quellen & Aktualität10 Primärquellen · zuletzt geprüft:
  1. 01wbadmin
  2. 02Configuring additional LSA protection
  3. 03How to configure protected accounts
  4. 04Volume Shadow Copy Service (VSS)
  5. 05REAgentC Command-Line Options
  6. 06Windows LAPS overview
  7. 07Registry Hives
  8. 08learn.microsoft.com/en-us/powershell/module/windowsserverbackup
  9. 09learn.microsoft.com/en-us/windows-server/secur…curity-and-assurance
  10. 10learn.microsoft.com/en-us/windows-server/ident…ing-active-directory