Meine Daten in Entra ID sind gesichert! Sicher?
Datensicherung und -wiederherstellung in Microsoft Entra ID
Von: Klaus Bierschenk
Datensicherung gehört seit jeher zu den Grunddisziplinen der IT. Trotzdem wird sie in Microsoft Entra ID vernachlässigt. Dabei ist Entra ID kein klassisches Dateisystem, dessen Informationen ein Administrator sofort mit der Notwendigkeit der Sicherung in Verbindung bringt. Diese Daten umfassen Identitäts- und Konfigurationsobjekte wie Benutzer, Gruppen, Administrative Units, Richtlinien usw. Viele davon sind geschäftskritisch, lassen sich aber nur eingeschränkt oder gar nicht ohne Weiteres wiederherstellen. Doch was davon schützt Microsoft und wofür trägt der Administrator die Verantwortung?
Soft Delete vs. Hard Delete
In Entra ID lassen sich grundsätzlich zwei Arten von Objekten unterscheiden: Identitäten (z. B. Benutzer und Gruppen) und Konfigurationen (Conditional Access Policies oder andere Richtlinien).
Je nach Objekttyp gibt es beim Löschen zwei Vorgehensweisen:
- Soft Delete: Das Objekt wird zunächst in einen Papierkorb verschoben und bleibt dort für 30 Tage erhalten. Innerhalb dieses Zeitraums kann es wiederhergestellt werden. Nach Ablauf der 30 Tage erfolgt die endgültige Löschung automatisch.
- Hard Delete: Ein Objekt wird endgültig gelöscht, wenn es 30 Tage im Papierkorb gelegen hat oder direkt aus dem Papierkorb gelöscht wird. Eine Wiederherstellung nach einem Hard Delete ist mit Bordmitteln nicht möglich.
Der Zeitraum von 30 Tagen ist fest vorgegeben und kann nicht geändert werden. Wird ein Objekt aus dem Papierkorb gelöscht, so erfolgt vorzeitig ein Hard Delete.
Warum ist das mit dem Soft und Hard Delete so wichtig?
Der erwähnte Papierkorb fungiert im Wesentlichen als Container, in den gelöschte Objekte verschoben werden. Alle ihre Eigenschaften, einschließlich der Attributinformationen, bleiben dabei erhalten. Hierzu zählt auch die Object-ID, welche der eindeutigen Referenzierung von Elementen dient. Bei der Wiederherstellung eines gelöschten Elements aus dem Papierkorb bleiben die ursprünglichen Inhalte unversehrt. Dieser Aspekt ist insbesondere im Kontext von Conditional Access Policies von Bedeutung. Werden Benutzer oder Gruppen in den Include- oder Exclude-Bereichen einer Richtlinie eingetragen, wird unter der Haube nicht der Benutzername, sondern die Object-ID verwendet.
Angenommen, ein Administrator löscht versehentlich einen Benutzer oder noch schlimmer eine wichtige Sicherheitsgruppe. Dies fällt nach 30 Tagen auf oder sie werden manuell aus dem Papierkorb entfernt. Und nehmen wir weiter an, der Administrator hat mit einem Export vorgesorgt und aus dem Entra ID Admin Center heraus alle Benutzer und Gruppen in eine CSV-Datei geschrieben. Wenn er nun ein gelöschtes Objekt aus der CSV-Datei wiederherstellt, erhält er zwar die ursprünglichen Inhalte mitsamt aller Eigenschaften, doch das Objekt selbst wird dabei neu angelegt und ebenso die Object-ID. Das bedeutet, in allen Richtlinien, in denen dieses Objekt referenziert wurde, ist es wegen der nun neuen ID nach wie vor nicht vorhanden.
Soft deleted, aber kein Papierkorb
Leider hat es Microsoft versäumt, in den diversen Dashboards des Entra ID Admin Centers den Papierkorb zu integrieren. Das ist verwirrend, aber kein allzu großes Problem, wenn bekannt ist, wie im Ernstfall Objekte wieder ans Tageslicht befördert werden können. Dafür ist es wichtig, eine Ebene tiefer in Entra ID einzutauchen und einen Blick auf die Deleted-Items-API zu werfen. Das ist eine Schnittstelle, über die sich sogenannte Soft Deletes anzeigen und auch wiederherstellen lassen. Abbildung 1 zeigt ein Beispiel im Graph Explorer zur Auflistung gelöschter Administrative Units (AUs).
Abbildung 1
Aus dem Ergebnis dieser Query holen wir uns die ID, die dann mit einem POST-Befehl dazu verwendet wird, die AU wiederherzustellen (siehe Abbildung 2).
Abbildung 2
Die AU ist anschließend wieder mit ihren gesamten Inhalten, Einstellungen und Rollen vorhanden.
Richtig gute Nachrichten
Bislang bestand ein signifikanter Unterschied im Löschverhalten der verschiedenen Objekttypen innerhalb von Entra ID. Die beiden besonders kritischen Elemente Sicherheitsgruppen und Conditional Access Policies wurden stets dauerhaft und unwiederbringlich gelöscht (Hard Delete). Ein Papierkorb war nicht vorhanden. Glücklicherweise hat Microsoft diese Situation geändert. Seit September 2025 werden Conditional Access Policies und seit November auch Sicherheitsgruppen zunächst in den Papierkorb verschoben (Soft Delete). Diese Neuerung stellt eine erhebliche Verbesserung dar. Versehentliche Löschungen, z. B. von Sicherheitsgruppen, können nun schneller rückgängig gemacht werden und sind somit weniger gravierend als zuvor.
Die nachfolgende Tabelle zeigt das Löschverhalten für gängige Objekttypen:
Prophylaxe
Obwohl gelöschte Objekte in der Regel zunächst im Papierkorb landen, ist es ratsam, im Voraus für deren Sicherung zu sorgen, insbesondere für den Fall eines unbeabsichtigten Hard Delete. Dafür gibt es diverse Tools, sowohl kommerzielle als auch Community-basierte Open-Source-Alternativen.
Der EntraExporter, verfügbar unter https:\\github.com\microsoft\EntraExporter, ist eines davon. Er stellt kein klassisches Backup- oder Restore-Werkzeug dar. Wie der Name impliziert, handelt es sich um ein Export-Tool, welches eine Vielzahl von Richtlinien und Objekten in Form eines Dumps im Dateisystem speichert. Dies umfasst auch komplexe Objekte wie Privileged-Identity-Management-, kurz PIM-Gruppen. Im September 2025 wurde der EntraExporter aktualisiert. Mit der Version 3.0.1 wurde nicht nur das Spektrum der gesicherten Objekte erweitert, sondern auch die Exportgeschwindigkeit erhöht. Exportierte Daten liegen in Form von JSON-Dateien vor und lassen sich wieder importieren. Der Importprozess ist objektabhängig. Bei Enterprise Applications beispielsweise ist der Graph Explorer erforderlich. In anderen Fällen, etwa bei Conditional Access Policies, erfolgt die Wiederherstellung über das jeweilige Dashboard in Entra ID mithilfe eines direkten Imports der JSON-Dateien. Die Einrichtung eines Exports ist dafür eine wesentliche Voraussetzung. Und um wirklich auf den Ernstfall vorbereitet zu sein, empfiehlt es sich, für Backup- und Restore-Strategien Trockenübungen zu machen, damit eine Wiederherstellung nicht zum Desaster wird.
Ein Beispiel, wie sich eine Administrative Unit, die nicht mehr im Soft-Delete-Status vorliegt, aus einem Export rekonstruieren lässt, erkläre ich in diesem Beitrag. Hier findet sich auch eine Beschreibung, wie ein Export in ein versioniertes lokales Git auf einer Workstation gelegt werden kann und einiges mehr.
Vorbeugen durch minimale Rechte
An dieser Stelle mag es zwar etwas didaktisch erscheinen, aber es ist von wesentlicher Bedeutung: Ein optimaler Schutz wird vor allem durch die Absicherung administrativer Tätigkeiten und Konten erreicht. Microsoft Entra ID stellt hierfür eine Vielzahl an Methoden bereit. Bei korrekter Anwendung lassen sich administrative Aktionen und Konfigurationselemente wirkungsvoll absichern. Zwei in diesem Zusammenhang häufig genannte Begriffe sind Just-in-Time Access (JIT) und Just-Enough Access (JEA). Beide verfolgen das Ziel, Admins für einen klar definierten Zeitraum ausschließlich mit den minimal erforderlichen Berechtigungen auszustatten – ein zentrales Prinzip des Zero-Trust-Ansatzes.
Die dafür eingesetzte Technologie ist Privileged Identity Management (PIM). Mit PIM lässt sich für jede administrative Rolle festlegen, wie ein Administrator diese aktiviert, z.B. über Genehmigungsworkflows durch Dritte, und wie lange die Rollenmitgliedschaft besteht, bevor sie automatisch wieder entzogen wird. PIM ist ein wirksames Mittel, um administrative Tätigkeiten abzusichern. Um jedoch Objekte selbst vor unbeabsichtigtem oder unberechtigtem Löschen zu schützen, stehen in Microsoft Entra ID weitere Mechanismen zur Verfügung.
Eine dieser Möglichkeiten sind die sogenannten Restricted Administrative Units (Restricted AUs). In diese lassen sich besonders schützenswerte Objekte wie Benutzerkonten oder Gruppen ablegen. Der Zugriff auf diese Objekte ist ausschließlich Benutzerkonten vorbehalten, denen explizit administrative Rollen auf der jeweiligen Administrative Unit zugewiesen wurden. Selbst Global Admins haben ohne eine entsprechende Rollenzuweisung für diese Administrative Unit keinen direkten Zugriff auf diese Objekte. Zwar können sie sich diesen Zugriff bei Bedarf verschaffen, was bewusst so vorgesehen ist, doch der primäre Zweck ist damit erfüllt: eine zusätzliche Schutzschicht gegen unbeabsichtigte oder delegierte Änderungen. Besonders sensible Gruppen lassen sich auf diese Weise gezielt absichern, etwa gegenüber Rollen wie dem Intune-Administrator, der von Haus aus die Möglichkeit besitzt, tenantweit alle Gruppen zu ändern oder zu löschen.
Fazit
Es ist bedauerlich, dass Administratoren in Microsoft Entra ID keine durchgängige, einheitliche Strategie vorfinden, um Objekte verlässlich zu sichern und im Ernstfall wiederherzustellen. Stattdessen existiert ein Nebeneinander unterschiedlicher Funktionen und Konzepte, die je nach Objekttyp jeweils eigene Vorgehensweisen erfordern. Das wirkt paradox, wenn man bedenkt, wie zentral und unternehmenskritisch die in Entra ID verwalteten Identitäten und Konfigurationen sind. Umso wichtiger ist es, dass sich Admins intensiv mit diesen Mechanismen und den klar aufgeteilten Verantwortlichkeiten zwischen Microsoft und dem Kunden auseinandersetzen. Hierfür ist dieser Microsoft-Learn-Artikel hilfreich. Er geht auf diverse Wiederherstellungsoptionen ein und beschreibt auch, was die Rolle von Microsoft und was die Aufgabe des Admins dabei ist. Positiv ist, dass Microsoft in den letzten Monaten erkennbar Schritte in die richtige Richtung unternommen hat, etwa mit der Einführung eines Papierkorbs für Sicherheitsgruppen.
Entra ID – Neuerungen in Q3/2025
Dieses Quartalsupdate zu Entra ID beleuchtet die neuesten Änderungen im Identitäts- und Zugriffsverwaltungsdienst von Microsoft – für eine noch sicherere und effizientere Tenant-Verwaltung. IT-Experte Klaus Bierschenk zeigt alle Inhalte Schritt für Schritt und anhand praktischer Beispiele.
Über den Autor: Klaus Bierschenk
Klaus Bierschenk ist seit über 20 Jahren in der IT-Branche tätig und wirkt schon lange in internationalen Identity- und Security-Projekten mit. Als Technologieberater bei CGI Deutschland liegt sein Schwerpunkt auf hybriden Themen. Klaus Bierschenkt berät IT-Betreiber bei Herausforderungen im Kontext von Microsoft Active Directory und Microsoft Entra ID. Regelmäßig tritt er als Referent in der Microsoft Azure Community auf, zudem schreibt er in seinem Technik-Blog „NothingButCloud“ und publiziert Fachartikel.