Backup & Recovery für Entra ID | Architektur & Setup

Bisher war die Wiederherstellung von Identitätsobjekten in Microsoft 365 primär auf den 30-tägigen Papierkorb für weich gelöschte Benutzer und Gruppen beschränkt. Konfigurationsobjekte wie Conditional Access Policies oder Service Principals wurden bei einer Löschung sofort hart gelöscht, wodurch ein Rollback bei Fehlkonfigurationen ohne externe Tools oder komplexe PowerShell-Skripte schlichtweg unmöglich war. Microsoft hat nun ein natives Backup & Recovery für Entra ID im Preview ausgerollt, das exakt diese "Core Tenant Objects" automatisiert im Hintergrund sichert und dir wieder Handlungsspielraum gibt.

Der Service erstellt täglich vollautomatische Snapshots deiner Identitätsinfrastruktur, inklusive Anwendungen, Authentifizierungsmethoden und Conditional Access Policies. Microsoft wählt hierbei architektonisch ein strikt geschlossenes System: Du kannst die Backups weder deaktivieren noch den Zeitplan anpassen. Durch diese Zwangsimplementierung stellt Microsoft sicher, dass selbst kompromittierte Administratorenkonten oder Ransomware-Akteure die Sicherungskette nicht manipulieren können. Die Backup-Daten verbleiben georedundant in der exakt gleichen Region wie dein Entra-Tenant, wodurch Data-Residency-Vorgaben nativ erfüllt werden.

Ein entscheidender Design-Faktor ist die rollierende Speicherung von exakt fünf Tagen. Diese extrem kurze Vorhaltezeit dient primär der unmittelbaren Disaster Recovery bei administrativen Fehlkonfigurationen. Wenn ein Administrator aus Versehen die MFA-Ausnahme für Break-Glass-Accounts entfernt, droht der vollständige Ausschluss des IT-Teams. Mit dem nativen Backup hältst du einen fixen Wiederherstellungspunkt bereit, wodurch die fehlerhafte Policy durch den funktionalen Zustand vom Vortag fehlerfrei überschrieben wird.

Um einen sauberen Rollback durchzuführen, musst du vor dem eigentlichen Restore evaluieren, welche Attribute sich verändert haben. Ein blindes Zurückrollen würde legitime Systemänderungen der letzten Stunden überschreiben, weshalb der Prozess zwingend über sogenannte Difference Reports gesteuert wird. Du wählst den gewünschten Snapshot aus der Timeline und startest die Generierung des Berichts. Das System berechnet hierbei den vollständigen Graph-Zustand. Wenn ein Nutzer aus einer Gruppe entfernt wird, betrifft das auch verbundene Enterprise Applications und App-Rollen.

Da Entra ID diese tiefgreifenden Abhängigkeiten vollständig iterieren muss, um Inkonsistenzen in der Datenbankstruktur zu vermeiden, beansprucht die Berechnung erhebliche Rechenzeit. Folglich musst du selbst bei kleineren Tenants mit Wartezeiten von bis zu 75 Minuten rechnen, bevor du eingreifen kannst.

Sobald der Report vorliegt, wählst du die korrumpierten Objekte aus und triggerst den Restore-Prozess, welcher asynchron abläuft. Wenn du beispielsweise ein fehlerhaftes Skript ausgeführt hast und 500.000 Objektänderungen rückgängig machen musst, blockiert der Restore-Prozess das System für bis zu 30 Stunden. Du musst diese RTO (Recovery Time Objective) zwingend in deine Notfallpläne einkalkulieren.

Für den Zugriff auf die Snapshots benötigst du eine Entra ID P1 oder P2 Lizenz. Die Berechtigungen werden über dedizierte Rollen gesteuert:

Da ein Restore tiefgreifende Systemzustände verändert, solltest du diese administrativen Rollen niemals permanent vergeben. Nutze stattdessen Privileged Identity Management (PIM), um die Backup-Admin-Rolle nur im akuten Fehlerfall für wenige Stunden zu aktivieren, wodurch du das Risiko minimierst, dass ein Angreifer unsichere Alt-Konfigurationen als Backdoor wiederherstellt.

Das native Backup & Recovery für Entra ID schließt eine kritische Vektorlücke, die Systemarchitekten bei der Absicherung ihrer Cloud-Identitäten lange Zeit umgehen mussten. Die Implementierung als nicht abschaltbarer Hintergrunddienst erhöht die Resilienz gegen Insider-Bedrohungen drastisch. Selbst bei einer vollständigen Kompromittierung der globalen Admin-Konten bleiben die unveränderlichen Snapshots der letzten fünf Tage unangetastet, wodurch du immer einen gesicherten Ausgangspunkt für die Rekonstruktion deiner Zugriffsrichtlinien behältst.

Dennoch musst du die aktuelle Preview-Phase als reine Notfall-Rückfallebene für operative Fehler betrachten. Hard-deleted Objekte lassen sich über diese native Schnittstelle aktuell nicht rekonstruieren, weshalb du bei echten Datenverlusten weiterhin auf den 30-tägigen Papierkorb angewiesen bist. Zudem fehlt eine API- oder Export-Funktion für die Difference Reports, wodurch eine automatisierte Weiterverarbeitung in einem SIEM-System stark erschwert wird. Die harte Limitierung auf lediglich fünf Tage Retention-Time kollidiert fundamental mit gängigen Audit-Frameworks, die eine Vorhaltezeit von mehreren Monaten fordern. Große Enterprise-Umgebungen werden bis auf Weiteres auf spezialisierte ISV-Lösungen setzen müssen, da nur diese erweiterte RPO/RTO-Anforderungen und unlimitierte Archivierungszeiträume abdecken. Du solltest das Feature dennoch umgehend in einer Sandbox evaluieren, die Laufzeiten der Difference Reports messen und deine Disaster-Recovery-Runbooks entsprechend der neuen nativen Möglichkeiten aktualisieren.