Active Directory-Wiederherstellung: Planung für Worst-Case-Szenarien
Aug 4, 2026
Wenn die Active Directory-Wiederherstellung auf die Forest-Ebene eskaliert, stoppen E-Mail, VPN, Dateizugriff und alle abhängigen Anwendungen aufgrund von Identitäts- und DNS-Abhängigkeiten. Um diesen Ausfall zu überstehen, braucht es mehr als Backups: Definieren Sie die Wiederherstellungsreihenfolge, halten Sie Systemstatus-Backups offline und unveränderlich, weisen Sie Verantwortliche für jede Wiederherstellungsphase zu, setzen Sie ein AD-spezifisches Wiederherstellungszeit-Ziel und proben Sie die gesamte Sequenz isoliert, bis die Zahlen stimmen.
Nur 36 % der Organisationen haben in den letzten 12 Monaten eine Sicherheitsbewertung von Active Directory (AD) durchgeführt, laut The Netwrix 2026 Data and Identity Security Report. Dieselbe Umfrage ergab, dass 73 % nicht vollständig sicher sind, dass ihr AD frei von Fehlkonfigurationen ist, die eine Privilegieneskalation ermöglichen.
Microsoft Threat Intelligence berichtet, dass Bedrohungsakteure in mehr als 78 % der von Menschen durchgeführten Cyberangriffe einen Domänencontroller kompromittieren und dabei genau die Lücken ausnutzen, die unbewertete Umgebungen offenlassen.
Das macht die AD-Disaster-Recovery zu einem Problem der Identitätsresilienz, und das Worst-Case-Szenario ist ein waldweites Ereignis, bei dem jeder Domain Controller (DC) ausgefallen ist, die Replikation beschädigt ist oder die Backups selbst verschlüsselt sind.
Ein Backup-Plan und ein Wiederherstellungsplan beweisen auch unterschiedliche Dinge. Der Plan zeigt, dass Daten irgendwo existieren. Der Wiederherstellungsplan beweist, dass das Unternehmen unter Druck ein funktionierendes Verzeichnis aus diesen Daten wiederherstellen kann. Ein brauchbarer Plan definiert daher die schlimmsten Ausfälle, die er überstehen muss, die Wiederherstellungssequenz und die Testfrequenz, die seine Funktionstüchtigkeit beweist.
Was ist die Active Directory-Notfallwiederherstellung?
Die Active Directory-Notfallwiederherstellung ist der dokumentierte, sequenzielle Prozess zur Wiederherstellung eines gesamten AD-Waldes nach einem Ausfall, den die Wiederherstellung einzelner Objekte nicht beheben kann, wie z. B. ein waldbreitiger Ausfall, eine Beschädigung oder Kompromittierung.
Die Wiederherstellung des Forests folgt einer strengen, abhängigkeitengesteuerten Reihenfolge. Der Plan legt fest, welcher Domänencontroller zuerst zurückkehrt, in welcher Reihenfolge das Team die Flexible Single Master Operations (FSMO roles) neu zuweist und wie die Replikation wiederhergestellt wird, ohne beschädigte Daten zu verbreiten.
Der Begriff wird locker auf alles angewendet, von der Wiederherstellung eines einzelnen gelöschten Benutzerkontos bis hin zum Wiederaufbau eines gesamten Forests, und beide erfordern völlig unterschiedliche Pläne. Die Wiederherstellung eines einzelnen Objekts aus dem AD-Papierkorb setzt voraus, dass der umgebende Forest gesund ist; die vollständige Forest-Wiederherstellung geht davon aus, dass der Forest selbst beschädigt ist.
Wie sehen Worst-Case-AD-Ausfallszenarien aus?
Diese AD-Ausfallszenarien zwingen Organisationen dazu, eine vollständige Forest-Wiederherstellung anzustreben statt routinemäßiger Fehlerbehebung.
Ransomware, das alle Domaincontroller gleichzeitig verschlüsselt oder löscht
Ransomware-Betreiber zielen jetzt direkt auf Domänencontroller ab, und das Erlangen von highly privileged accounts ermöglicht Angreifern, Backups als Teil derselben Operation zu löschen. Wenn Backup-DCs im selben Netzwerksegment wie die Produktion stehen, kann derselbe Angriff, der AD lahmlegt, auch die Backups lahmlegen, die zur Wiederherstellung dienen. Microsofts Kriterium für die Wiederherstellung des Forests ist, dass alle DCs logisch beschädigt oder physisch so stark beschädigt sind, dass die Geschäftskontinuität unmöglich ist.
Der NotPetya-Vorfall bei Maersk im Jahr 2017 ist das Lehrbuchbeispiel für dieses Szenario. Die Malware löschte innerhalb einer Stunde fast alle Domänencontroller im globalen Netzwerk von Maersk, und das Unternehmen vermied einen Totalverlust nur, weil ein DC in seinem Büro in Accra, Ghana, während eines lokalen Stromausfalls ausgeschaltet war, als der Angriff erfolgte. Diese einzige überlebende Kopie ermöglichte es Maersk, den Rest seines Active Directory-Waldes wieder aufzubauen, obwohl der CISO von Maersk später sagte dass die neun Tage zur Wiederherstellung „nicht gut genug“ seien. Der umfassendere Wiederaufbau umfasste schließlich etwa 4.000 Server und 45.000 PCs, und Maersk schätzte die Gesamtkosten auf bis zu 300 Millionen US-Dollar.
Ein kompromittiertes Admin-Konto, das OUs, GPOs oder ganze Teilbäume löscht
Ein böswilliger Administrator mit Domain Admin- oder Schema Admin-Rechten kann Änderungen vornehmen, die im Replikationsstrom nicht von legitimen Operationen zu unterscheiden sind. Ohne eine bekannte, gute Basislinie aus dem Backup kann keine einzelne Objektwiederherstellung feststellen, welche Änderungen bösartig waren.
Das Löschen von organisatorischen Einheiten (OUs), Group Policy Objects (GPOs) oder Teilbäumen bleibt oft unbemerkt, da es wie eine normale Verwaltungsaktion erscheint. Persistenztechniken, die Kerberos-Tickets, SIDHistory, AdminSDHolder oder GPOs verändern, können in der Verzeichnisdatenbank verbleiben, sofern das Team nicht von einem vertrauenswürdigen Backup wiederherstellt und das Ergebnis überprüft.
Beschädigte Replikation oder eine fehlerhafte Schemaänderung, die sich auf alle DCs ausbreitet
Ein Angreifer oder Administrator kann ein Skript ausführen, das Datenkorruption verbreitet im gesamten Forest oder das Schema mit widersprüchlichen Änderungen erweitert, die sich überall replizieren. Wenn der Fehler sichtbar wird, kann er bereits auf jedem Domänencontroller im Forest vorhanden sein, einschließlich derjenigen, die der Wiederherstellungsplan als sauber annimmt. Die Schema-Partition ist forestweit und wird von jeder Domäne geteilt, daher führt ein beschädigtes Schema zu Ausfällen in allen Domänen gleichzeitig.
Ein hardwareweiter Ausfall oder eine Naturkatastrophe ohne geografisch redundanten DC
Die Wiederherstellungskriterien für Forests von Microsoft konzentrieren sich auf logische Beschädigungen und physische Schäden, und ein physisches Ereignis an einem einzigen Standort führt zum gleichen Ergebnis. Organisationen, die jeden Domänencontroller von einem einzigen Standort oder Rechenzentrum aus betreiben, riskieren, den gesamten Forest durch ein einzelnes Feuer, eine Überschwemmung oder einen Stromausfall zu verlieren, was die Produktion und alle dort befindlichen Backup-DCs lahmlegt. Geografische Redundanz ist die wichtigste strukturelle Verteidigung gegen diese Art von Ausfall.
Ein fehlgeschlagenes AD-Upgrade oder eine Migration, die das Schema mitten im Prozess beschädigt
Über angriffsbedingte Ausfälle hinaus kann eine Schemaänderung auch den Forest in einen inkonsistenten Zustand versetzen. Schemaänderungen werden auf alle DCs repliziert und sind unter normalen Betriebsbedingungen weitgehend irreversibel, daher ist ein Zurückrollen nicht immer einfach, und ein beschädigtes oder widersprüchliches Schema kann forestweite Operationen für jede Domäne gleichzeitig unterbrechen.
Netwrix Identity Recovery stellt AD-Objekte, Attribute und ganze Forests nach Ransomware oder Korruption in einen bekannten guten Zustand wieder her. Fordern Sie eine Demo an
Warum die Planung der AD-Notfallwiederherstellung wichtig ist
Ohne Plan endet jedes der oben genannten Szenarien gleich: mit Improvisation, unter Druck, während alle abhängigen Systeme bereits ausgefallen sind.
Ransomware-Gruppen zielen jetzt direkt auf Domänencontroller und Backups ab
Dokumentierte Taktiken zeigen, wie weit dies über die Endpunktverschlüsselung hinausgegangen ist. Angreifer fahren jetzt virtuelle Domänencontroller herunter, um Anmeldedatenbanken direkt zu extrahieren, und übertragen FSMO-Rollen auf von ihnen kontrollierte bösartige Domänencontroller.
Die Exponierung zeigt sich auch in Umfragedaten. In der Umfrage hinter The Netwrix 2026 Data and Identity Security Report gaben 25 % der Organisationen an, in den letzten 12 Monaten einen Vorfall erlebt zu haben, bei dem unautorisierte Identitäten auf sensible Daten zugegriffen haben.
Eine Wiederherstellungsstrategie, die davon ausgeht, dass Backups automatisch sicher sind, entspricht nicht mehr dem Ablauf dieser Angriffe.
Jedes abhängige System fällt aus, sobald AD ausfällt
E-Mail, Dateizugriff, VPN und die meisten Geschäftsanwendungen authentifizieren sich gegen AD, sodass sich die Ausfallkosten stündlich auf jedes abhängige System summieren. Wenn identity, DNS, Netzwerk, Geheimnisse oder Datenbanken nicht verfügbar sind, kann eine Anwendung zwar wiederhergestellt werden, bleibt aber unbrauchbar, wodurch die Ausfallzeit über das angegebene Wiederherstellungszeit-Ziel hinaus verlängert wird.
First National Bank Minnesota erkannte diesen Bedarf direkt und schloss einen Active Directory-Neuaufbau in drei Wochen mit Unterstützung von Netwrix Auditor, gegenüber einer ursprünglichen Schätzung von sechs Monaten ab.
Der Wiederherstellungsprozess des Microsoft-Waldes ist lang, sequenzabhängig und unerbittlich
Der offizielle Microsoft AD forest recovery guide behandelt ausführlich die mechanischen Wiederherstellungsschritte und schließt ausdrücklich die Sicherheitswiederherstellung nach einer Kompromittierung, Planung und Governance sowie Berichte an Führungskräfte oder Versicherer aus. Ein Schritt, der in falscher Reihenfolge ausgeführt wird, wie das Überspringen der metadata cleanup oder das Wiederherstellen von Domänencontrollern außerhalb der Abhängigkeitsreihenfolge, kann die Wiederherstellung ungültig machen und einen Neustart erzwingen.
Vorstände und Cyber-Versicherer verlangen ein getestetes Wiederherstellungszeit-Ziel
Ein getestetes AD-Wiederherstellungszeit-Ziel liefert Führungskräften, Vorständen und Versicherern eine spezifische Kennzahl zur Überprüfung. Es spiegelt eine tatsächlich unter realistischen Bedingungen durchgeführte Wiederherstellung wider. Eine allgemeine Aussage, dass ein Notfallwiederherstellungsplan existiert, liefert weniger operative Belege als ein datierter Wiederherstellungstest mit gemessenen Phasenzeiten und Abschlusskriterien.
Ungetestete Pläne scheitern während des tatsächlichen Vorfalls
Lücken in einem Wiederherstellungsplan treten unter realem Druck am schnellsten zutage, was der teuerste Zeitpunkt ist, sie zu entdecken. Vertrauen und Fähigkeit messen unterschiedliche Dinge, und nur Tests bringen sie in Einklang.
Was ein AD-Disaster-Recovery-Plan enthalten sollte
Jede der folgenden Komponenten beschreibt, was sie abdeckt und warum das Weglassen den Plan gerade dann bricht, wenn es am wichtigsten ist.
- Unveränderliche, offline Backups des Systemzustands auf jedem Domain Controller: Wenn Backups im selben Netzwerk wie die Produktion liegen, kann Ransomware, die AD lahmgelegt hat, die Kopien erreichen, die zur Wiederherstellung gedacht sind. Air-gapped oder unveränderlicher Speicher hält die Wiederherstellungsmedien außerhalb des gleichen Ausfallpfads, und eine AD-kompatible Backup-Anwendung vermeidet beim Wiederherstellen einen Rollback der Update-Sequenznummer (USN).
- Eine dokumentierte, geordnete Wiederherstellungssequenz: Die Wiederherstellung des Forests erfordert strikte Reihenfolgen, und das Wiederherstellen von DCs oder das Neuvergeben von FSMO-Rollen in falscher Reihenfolge kann den Forest eher beschädigen als reparieren. Microsoft weist darauf hin, dass es keine durchgängige Automatisierung gibt, die im Prozess eingebaut ist, was die Last auf einen umgebungsspezifischen Plan legt.
- Ein getestetes Recovery Time Objective (RTO), spezifisch für AD: Ein Backup-Plan zeigt, dass Daten vorhanden sind; ein RTO zeigt, wie lange das Geschäft stillsteht, eine Zahl, die Führungskräfte und Versicherer prüfen können. Recovery Point Objective (RPO) ergänzt dies und definiert, wie viele Verzeichnisänderungen Sie zu verlieren tolerieren können.
- Ein definierter Kommunikations- und Eskalationsplan für einen AD-Ausfall: Bei einem echten AD-Ausfall sind die Werkzeuge, die Teams normalerweise zur Koordination verwenden, einschließlich E-Mail, Teams und Ticketsysteme, oft ebenfalls ausgefallen. Der Plan muss festlegen, wie das Team ohne diese kommuniziert, mithilfe von offline gespeicherten und im Voraus verteilten Kontaktlisten.
- Geplante Wiederherstellungsübungen oder Tabletop-Übungen: Ein Plan, den das Team nie geprobt hat, zeigt seine Lücken während eines Live-Vorfalls und nicht während eines kontrollierten Tests. Regelmäßige Übungen stärken das organisatorische Muskelgedächtnis, bevor das Wiederherstellungsteam unter Vorfallsdruck arbeitet.
Directory-Wiederherstellungssoftware sollte beide Betriebsmodi unterstützen, granulare Objektreparatur und vollständigen Forest-Wiederaufbau, damit eine Fehlerklasse das Team nicht mitten im Vorfall zu einem zweiten Tool zwingt.
Die Verzeichniswiederherstellung hängt auch von angrenzenden Identitätskontrollen ab: zero standing privilege reduziert die anhaltende Administrator-Exposition vor einem Vorfall, ephemeral admin accounts begrenzen die Lebensdauer privilegierter Anmeldeinformationen, und access certification hält Nachweise für privilegierten Zugriff aktuell.
Wie man einen AD-Notfallwiederherstellungsplan erstellt, der ein Worst-Case-Szenario übersteht
Den Plan in der richtigen Reihenfolge zu erstellen, ist genauso wichtig wie sein Inhalt. Jeder Schritt unten baut auf dem vorherigen auf, und das Überspringen führt zu einem Plan, der vollständig erscheint, aber nicht auf Abhängigkeiten getestet wurde.
1. Erfassen Sie zuerst Ihre forest-Struktur und alle Abhängigkeiten
Kartieren Sie jeden Domänencontroller, FSMO-Rolleninhaber, Vertrauensstellung und DNS-Abhängigkeit, bevor Sie einen einzigen Wiederherstellungsschritt schreiben. Ein Plan, der ohne dieses Inventar erstellt wurde, übersieht eine Abhängigkeit genau dann, wenn sie tatsächlich benötigt wird.Die Anleitung von Microsoft betrachtet die Liste der DCs der Forest Root Domain als das wichtigste Element, da diese Domäne zuerst wiederhergestellt wird.
Beziehen Sie globale Katalogserver, Standortverbindungen und die Replikationstopologie ein, da diese die Reihenfolge bestimmen, in der DCs wieder online gehen. Erfassen Sie die Basis-Ausgabe von repadmin /showrepl und dcdiag zusammen mit dem Inventar, damit das Wiederherstellungsteam weiß, wie ein gesunder Zustand aussah.
Notieren Sie jetzt das Domain Admin-Passwort und die Directory Services Restore Mode (DSRM) Passwörter für jede Domäne, da eine Systemstatuswiederherstellung diese benötigt und Sie sie aus einem toten Forest nicht abrufen können.
2. Legen Sie ein dediziertes Wiederherstellungszeit-Ziel für AD außerhalb des allgemeinen DR-Plans fest
Der RTO von AD muss kürzer sein als der RTO jedes Systems, das davon abhängt, da nichts anderes vollständig wiederhergestellt werden kann, bevor AD dies tut. Microsofts Regel, dass immer zuerst eine übergeordnete Domäne vor einer untergeordneten wiederhergestellt wird, bedeutet, dass der RTO der Waldroutine alles nachgelagerte steuert. Die Behandlung der AD-Wiederherstellung als Punkt in einem umfassenderen Notfallwiederherstellungsplan unterschätzt meist, wie dringend sie tatsächlich ist.
Messen Sie die AD-RTO von der Fehlererklärung bis zum Zeitpunkt, an dem ein funktionierender Forest-Root-DC wiederhergestellt und die Replikation bestätigt ist. Die RTO jeder abhängigen Anwendung sollte diesen Wert übersteigen.
3. Schreiben Sie die Wiederherstellungssequenz in der richtigen Reihenfolge auf und speichern Sie sie an einem Ort, an dem AD Sie nicht aussperren kann
The sequence needs to specify which DC restores first, in what order FSMO roles get reassigned, and how replication gets re-verified. For the first writable DC in a domain, the runbook needs to cover each recovery action in this order:
- Führen Sie eine nicht autoritative Wiederherstellung von Active Directory Domain Services (AD DS) durch.
- Complete an authoritative restore of SYSVOL, the shared system volume that stores domain scripts and Group Policy files.
- Run metadata cleanup for DCs you aren't restoring.
- Seize FSMO roles.
- Invalidate the Relative Identifier (RID) pool and raise the available RID pool value by 100,000 to prevent reissuing RIDs consumed after the backup.
- Reset the DC computer account password twice.
- Reset the krbtgt password twice to protect the Kerberos Ticket Granting Ticket account, with a 10-hour wait between resets.
Write these steps clearly enough for the recovery team to follow them without normal AD-dependent tools. The plan itself has to live outside AD-dependent systems. A runbook stored on a SharePoint site that requires AD to authenticate is useless when AD is down.
4. Build immutable, air-gapped backups of system state
Backups need isolation from the production network so that whatever took down AD, whether ransomware or a compromised admin account, can't also reach the copies meant to restore it. Critical backups belong in separate storage protected from unauthorized modification.
Das Alter der Sicherung muss ebenfalls innerhalb der Tombstone-Lebensdauer des Forests bleiben (standardmäßig 180 Tage), da AD Wiederherstellungen von älteren Medien ablehnt.
Ein Backup, das nach einer Kompromittierung erstellt wurde, kann Malware und die Persistenz des Angreifers zusammen mit AD wiederherstellen, da SIDHistory-Manipulationen, AdminSDHolder-Änderungen und bösartige GPOs in der Verzeichnisdatenbank gespeichert sind. Isolation und Validierung einer sauberen Wiederherstellung verhindern, dass sich der Angreifer erneut im Verzeichnis einnistet.
5. Weisen Sie klare Zuständigkeit und einen benannten Eskalationsweg zu
Benennen Sie, wer jede Phase der Wiederherstellung durchführt und an wen er sich wendet, wenn ein Schritt fehlschlägt, damit der Plan nicht ins Stocken gerät, während auf Freiwillige im tatsächlichen Vorfall gewartet wird.
Ohne vorgefertigte Abhängigkeitsinventare und benannte Eigentümer entdecken Wiederherstellungsteams Abhängigkeiten reaktiv, unter Druck und ohne die Verfügbarkeit aller ursprünglichen Systemarchitekten.
Weisen Sie für jede Phase einen Hauptverantwortlichen und einen Ersatz zu und bestätigen Sie, dass beide wissen, wie sie sich über die im Plan definierten Offline-Kommunikationskanäle erreichen können.
Wie man einen AD-Wiederherstellungsplan testet, bevor man ihn braucht
Ein Wiederherstellungsplan, der nur auf dem Papier existiert, bleibt eine Hypothese, bis Tests seine Wirksamkeit beweisen.
1. Führen Sie eine Tischübung durch, bevor Sie einen Live-Failover-Test versuchen
Führen Sie das Team Schritt für Schritt durch den schriftlichen Plan, ohne die Produktion zu berühren. Verwenden Sie eine diskussionsbasierte Übung, bei der das Personal seine Rollen und Reaktionen auf einen bestimmten Notfall bespricht, ohne Ausrüstung einzusetzen. Dies deckt Lücken in der Zuständigkeit und Reihenfolge auf, bevor ein System gefährdet ist, und die Ergebnisse schärfen den Umfang der anschließenden Live-Übung.
2. Stellen Sie einen Forest in einer isolierten Testumgebung in festgelegten Abständen wieder her
Ein Tabletop überprüft die Logik des Plans. Nur eine echte Wiederherstellung in einer isolierten Umgebung prüft, ob die Backups und die Wiederaufbau-Sequenz tatsächlich funktionieren.
Microsoft empfiehlt, virtualisierte DCs in ein von der Produktion isoliertes virtuelles Netzwerk zu verschieben und Produktions-Backups im Labor zu verwenden, damit der Test beweist, dass die echten Wiederherstellungsdaten wiederhergestellt werden. Microsoft empfiehlt diese Übung mindestens einmal jährlich und erneut, wenn sich die Mitgliedschaft in den Gruppen Enterprise Admins oder Domain Admins ändert.
3. Messen Sie den tatsächlichen Wiederherstellungszeitraum
Die im Plan angegebene RTO ist nur gültig, wenn sie anhand einer echten Testwiederherstellung gemessen wurde. Eine nicht verifizierte Zahl ist eine Schätzung. Erfassen Sie die tatsächliche Zeit pro Phase, einschließlich Isolation, Wiederherstellung, FSMO-Übernahme und Replikationsprüfung, damit der Plan widerspiegelt, was das Team tatsächlich ausführen kann.
Help Net Security berichtete 2024 dass nur 6 % der Unternehmen AD in unter einer Stunde wiederherstellen können, was bedeutet, dass die meisten angegebenen RTOs weit über den Annahmen der Teams liegen. Abschluss der Prüfung mit dcdiag, läuft sauber; SYSVOL- und NETLOGON-Freigaben sind vorhanden, und DNS läuft gesund.
4. Aktualisieren Sie den Plan jedes Mal, wenn sich die Forest-Topologie ändert
Ein neuer Domänencontroller, eine Schemaänderung oder eine neue Vertrauensstellung können Teile der Wiederherstellungssequenz ungültig machen, daher benötigt der Plan neben der jährlichen Überprüfung auch eine triggerbasierte Überprüfung. Änderungen an FSMO-Rolleninhabern, Standorttopologie oder Replikationsverbindungen sind die häufigsten Ursachen für Planabweichungen.
Fügen Sie Migrationen, Upgrades und neue Anwendungsbereitstellungen zur Auslöserliste hinzu, da jede eine Abhängigkeit einführen kann, die die bestehende Reihenfolge nicht berücksichtigt. Jede ausgelöste Überprüfung sollte mit einem aktualisierten Inventar enden und, wenn die Änderung Topologie, trusts oder das Schema betrifft, mit einem neuen Wiederherstellungstest.
Wie Netwrix die Active Directory-Wiederherstellung unterstützt
Netwrix Identity Recovery deckt beide Wiederherstellungsmodi ab, die dieser Plan unterscheidet. Bei Vorfällen auf Objektebene führt es eine Zeitleiste der Verzeichnisänderungen und stellt gelöschte oder geänderte Benutzer, Gruppen, GPOs und DNS-Einträge in einen bekannten guten Zustand zurück, ohne den Rest des Forests zu berühren.
Für die oben genannten Worst-Case-Szenarien automatisiert es die vollständige AD-Wald-Wiederherstellungssequenz. Die Abdeckung erstreckt sich auf Entra ID und Okta, sodass die hybride Identität mit demselben Runbook wiederhergestellt wird.
Wiederherstellungsentscheidungen hängen auch von Beweisen ab, denn die erste Frage bei einer Kompromittierung ist, welches Backup älter als der Angreifer ist.
Netwrix Auditor liefert diesen Kontext durch kontinuierliches AD change auditing, das zeigt, wer was wann geändert hat, mit Vorher-Nachher-Werten, die böswillige Änderungen von legitimen unterscheiden. Seine Zeitpunktberichte vergleichen die Konfiguration des Verzeichnisses zwischen zwei Zeitpunkten, wodurch ein Team feststellen kann, wann die Kompromittierung begann und welches Backup davor liegt.
Regierung des Landkreises Cheshire nutzte Netwrix Auditor, um einen Vorfall mit 27.000 Dateiänderungen in 15 Minuten zu untersuchen – die Beweisschnelligkeit, die ein Wiederherstellungsteam benötigt, während das Verzeichnis ausgefallen ist.
Durchführung von Übungen und echten Vorfällen mit demselben Tool macht jede Phase vergleichbar, sodass der im isolierten Labor gemessene RTO derselbe Wert ist, den das Team der Führung präsentiert.
Verwandeln Sie Ihren AD-Wiederherstellungsplan in einen getesteten, funktionierenden Prozess
Echte Bereitschaft beruht auf Nachweisen, die die Führung überprüfen kann. Das bedeutet einen datierten Wiederherstellungstest, eine gemessene AD-RTO, ein bekannt gutes Backup innerhalb der Tombstone-Lebensdauer und ein Runbook, das für jede Wiederherstellungsphase Verantwortliche benennt.
Das Paket beantwortet die Fragen, die Vorstände, Prüfer und Cyber-Versicherer jetzt stellen, und es hält stand, weil jeder Punkt aus einer Probe und nicht aus einer Behauptung stammt.
Die erste isolierte Wiederherstellung bringt das fehlende DSRM-Passwort, die Abhängigkeit, die niemand inventarisiert hat, und die Phase ans Licht, die die angenommene RTO sprengt. Der zweite Test läuft sauberer und liefert eine Zahl, mit der das Unternehmen planen kann. Von dort an halten triggerbasierte Überprüfungen den Plan mit dem Forest synchron, während sich Domänencontroller, Vertrauensstellungen und Schema weiterentwickeln, sodass die Lücke zwischen dem dokumentierten Plan und der realen Umgebung nie wieder zu einem Risiko wird.
Fordern Sie eine Demo an und sehen Sie, wie Netwrix Identity Recovery Forest-Rebuilds, granulare Rollbacks und Recovery-Übungen in Ihrer eigenen Topologie handhabt.
Häufig gestellte Fragen zur Active Directory-Wiederherstellung
Teilen auf
Erfahren Sie mehr
Über den Autor