Identity Resilience: Active Directory und Entra ID absichern

Warum Identitäten im Mittelpunkt stehen

Active Directory (AD) und Microsoft Entra ID entscheiden, wer sich anmelden darf und worauf er zugreifen kann. Genau deshalb sind sie ein bevorzugtes Ziel: Wer Administratorrechte im Verzeichnis erlangt, kann Sicherheitssoftware abschalten, Backups löschen und Ransomware im ganzen Netz verteilen.

Fällt das Verzeichnis aus oder ist es kompromittiert, hilft auch das beste Server-Backup nur begrenzt: Ohne Anmeldung, DNS und Gruppenrichtlinien lassen sich wiederhergestellte Systeme nicht sinnvoll nutzen. Die Wiederherstellung der Identitäten steht deshalb im IT-Notfallplan ganz am Anfang.

Active Directory und Entra ID im Vergleich

Was Entra ID selbst wiederherstellen kann

Gelöschte Benutzer, Microsoft-365-Gruppen, Cloud-Sicherheitsgruppen, App-Registrierungen, Dienstprinzipale, Verwaltungseinheiten, Richtlinien für bedingten Zugriff und benannte Standorte landen zunächst im Papierkorb und lassen sich 30 Tage lang wiederherstellen. Alle anderen Objekttypen löscht Entra ID sofort endgültig; sie müssen neu angelegt werden.

Microsoft bietet zusätzlich „Microsoft Entra Backup and Recovery“ an, um geänderte Objekte auf einen früheren Stand zurückzusetzen. Endgültig gelöschte Objekte stellt aber auch dieser Dienst nicht wieder her, und für Objekte aus dem lokalen Active Directory verweist Microsoft auf eine separate Lösung. Ein unabhängiges Backup für Entra ID außerhalb des eigenen Tenants schließt diese Lücke.

Active Directory nach einem Angriff wiederherstellen

Microsoft beschreibt die Wiederherstellung eines kompletten AD-Forests in einem eigenen Leitfaden. Die wichtigsten Punkte: Pro Domäne wird zuerst ein beschreibbarer Domain Controller aus einem sauberen Backup zurückgeholt, getrennt vom Produktionsnetz. Danach werden die Kennwörter aller Administratorkonten zurückgesetzt und das Kennwort des krbtgt-Kontos zweimal geändert – mit ausreichend Abstand für die Replikation, damit gestohlene Kerberos-Tickets ungültig werden. Anschließend wird der RID-Pool erhöht, und erst dann kommen weitere Domain Controller hinzu. Wer diesen Ablauf nie geübt hat, verliert im Ernstfall Tage.

Hybride Umgebungen: Die Synchronisierung nicht vergessen

In vielen Unternehmen sind Active Directory und Entra ID über Microsoft Entra Connect oder Cloud Sync gekoppelt. Das macht die Wiederherstellung anspruchsvoller: Wird das lokale AD aus einem älteren Backup zurückgeholt, fehlen dort alle Objekte, die nach dem Backup angelegt wurden. Läuft die Synchronisierung weiter, überträgt sie diesen alten Stand in die Cloud – Konten und Gruppen in Entra ID werden dann gelöscht oder überschrieben.

Deshalb gilt: Synchronisierung vor der Wiederherstellung anhalten, das AD zurückholen und bereinigen, die anstehenden Änderungen in einer Vorschau prüfen und erst dann die Synchronisierung wieder einschalten. Der Server mit Entra Connect selbst gehört zu den kritischsten Systemen im Netz: Wer ihn kontrolliert, kann Kennwörter und Konten in beiden Welten beeinflussen. Er braucht deshalb denselben Schutz und dieselbe Sicherung wie ein Domain Controller.

Bausteine der Identity Resilience

Erstens getrennte, unveränderliche Backups von mindestens zwei beschreibbaren Domain Controllern pro Domäne, nicht älter als die Tombstone-Lebensdauer (standardmäßig 180 Tage). Zweitens Vollsicherungen der Server: Ein Systemstatus-Backup lässt sich laut Microsoft nicht auf neue Hardware zurückspielen, dafür braucht es eine Bare Metal Recovery. Drittens ein unabhängiges Backup für Entra ID. Viertens eine Überwachung, die schädliche Änderungen an Konten und Gruppen erkennt. Fünftens regelmäßige Wiederherstellungstests in einer isolierten Umgebung.

Änderungen erkennen, bevor sie Schaden anrichten

Angreifer löschen selten, sie verändern. Ein neuer globaler Administrator, eine aufgeweichte Richtlinie für bedingten Zugriff, ein zusätzliches Geheimnis für eine App-Registrierung oder eine abgeschaltete Mehr-Faktor-Methode – solche Änderungen fallen im Alltag kaum auf, öffnen aber dauerhaft eine Tür. Der Papierkorb hilft hier nicht, denn es wurde nichts gelöscht.

Wirksam ist eine Überwachung, die kritische Änderungen an Konten, Gruppen, Rollen und Richtlinien meldet, und ein Backup, mit dem sich einzelne Einstellungen gezielt auf einen früheren Stand zurücksetzen lassen. So lässt sich eine Manipulation in Minuten rückgängig machen, statt das gesamte Verzeichnis wiederherzustellen.

Das Backup darf nicht vom Verzeichnis abhängen

Ein häufiger Planungsfehler: Die Anmeldung an der Backup-Konsole läuft über dasselbe Active Directory oder denselben Entra-Tenant, der geschützt werden soll. Ist das Verzeichnis kompromittiert oder ausgefallen, kommt im Ernstfall niemand mehr an die Backups – oder der Angreifer kommt mit denselben Rechten hinein.

Die Backup-Umgebung braucht deshalb eigene, getrennte Administratorkonten mit eigener Mehr-Faktor-Anmeldung. Dazu kommen Notfallzugänge (Break-Glass-Konten) für Entra ID, die nicht an die normalen Richtlinien gebunden sind, sicher verwahrt und regelmäßig getestet werden. Erst wenn der Zugriff auf die Wiederherstellung unabhängig vom angegriffenen System funktioniert, ist der Notfallplan belastbar.

Identity Resilience und NIS2

NIS2 nennt unter anderem Backup-Management, Wiederherstellung nach einem Notfall und Konzepte für die Zugriffskontrolle als Pflichtmaßnahmen. Identity Resilience verbindet beides: Wer Verzeichnisdienste absichert und ihre Wiederherstellung regelmäßig übt, erfüllt einen zentralen Teil dieser Pflichten. Mehr dazu im Eintrag NIS2.