Microsoft 365 - Backup und Restore-Challenge
Microsoft 365 ist der Cloud-Dienst von Microsoft, in dessen Kern Entra ID dafür sorgt, dass wir Collaboration Features wie Teams, OneDrive und SharePoint nutzen können. Entra ID (ehemals Azure AD) stellt den zentralen Directory-Dienst in der Microsoft-Cloud.
Damit die Daten bei Angriffen oder Fehlern nicht verloren gehen, erstellen die meisten Firmen Backups der Daten. E-Mails, Chats, Dateien.
Mit steigendem Reifegrad identifiziert man als M365-Nutzer, dass man zwar die Daten mit den üblichen Mitteln sichert, nicht aber die Konfiguration.
Und Im Desaster-Fall? Lassen sich alle Objekte wiederherstellen? Kann man CA-Policies, Benutzerkonten, Sicherheitsgruppen und co. wirklich "restoren"?
Wissen schützt besser als glauben: Die - vielleicht auch bei Ihnen - trügerische Sicherheit und die aktuelle Restore-Challenge beleuchten wir hier!
Backups gehören zum Standardportfolio einer jeden IT. Ob DORA-reguliert oder einfach nur nicht vollkommen leichtsinnig. Backups gehören dazu.
Dabei ist die Frage "was" gesichert wird schon unterschiedlich:
- Alle Daten (E-Mails, Dateien, SharePoint-Seiten, Teams-Räume, ...)
- Alle Benutzer, Gruppen und Geräte
- Die Intune Config Profiles, Apps und Compliance Policies
- Die Rollenzuweisungen in Entra
- Das Conditional-Access-Regelwerk
- Die Enterprise Apps / App Registrations
- ...
Das geht in unterschiedlichen Reifegraden und Umfängen mit allen gängigen Lösungen, ob VEEAM, Rubrik oder über NAS-Lösungen. Über Microsoft 365 DSC kann ggf. Konfiguration gesichert werden, wenn die auserwählte Backup-Lösung sich aktuell noch auf die Inhalte und Daten fokussiert und die Konfiguration des Tenants nicht im Blick hat.
Doch was passiert, wenn etwas wiederhergestellt werden muss? Wo liegt die Restore-Challenge?
Die Restore-Lüge in Microsoft 365
Hard- & Soft-Delete
Seit Anfang Oktober 2025 sprießen die freudigen Blog-Posts aus dem Boden, in denen das neu eingeführte Soft-Delete-Feature für Conditional Access beschrieben wird. Was gut klingt, wirft Fragen auf. Soft-Delete und die Möglichkeit zum Restore für Conditional Access gibt es erst in 2025?
Für welche Objekte gibt es ein Soft-Delete?
Naja, die Liste ist kurz:
- Benutzer /Users
- M365 Gruppen / M365-Groups
- Anwendungen / Apps / Applications
- Cloud-Only-Security Groups (Rollout ab November 2025)
Und eben das Conditional Access-Regelwerk seit kurzem. Mit Stand 2025-07-11 endet die Liste in den offiziellen Microsoft-Dokumenten.
Das Problem?
Ein technischer "Restore" ist nur möglich, solang ein Objekt im Soft-Delete-Zustand ist.
Alle Objekte, die nicht über einen Soft-Delete verfügen, bieten keine Möglichkeit für einen Restore. Das betrifft:
- Geräte / Devices
- Security Groups
- Custom Roles
- Configuration Profiles / Policies
- ... {you name it}
Wenn wir über die Restore-Challenge sprechen, dann sprechen wir über Objekte, für die es keinen Soft-Delete gibt.
Die Learn-Seiten von Microsoft sind eindeutig: Objekte, die hard-deleted sind, können weder von Microsoft, noch vom Kunden restored werden.
Das betrifft auch Security Groups. Also im Zweifel die abgebildete Struktur des gesamten Unternehmens, inklusive aller Berechtigungszuweisungen für interne und externe Dienste, die Ausnahmen für das CA-Regelwerk und und und.
Ob das Szenario im diesjährigen Restore-Test und im Wiederanlaufplan der Business Continuity vorhanden war, sollte wenigstens mal geprüft werden,
Restore vs. Recovery
Die Daten aus der M365-Welt können wir sichern. Dateien, E-Mails, etc. Die meisten Backup-Lösungen erlauben auch, die Daten direkt innerhalb der Lösung einzusehen, in den gleichen Kontext (Gruppe, Benutzer, SharePoint) oder an einem anderen Ort wiederherzustellen. Technisch wird hierbei eine neue Datei oder E-Mail mit einer neuen, zufälligen GUID erzeugt. Der Grund ist einfach: Alle Objekte (Benutzer, Gruppen, Dateien, ...) sind über GUIDs referenziert. Diese vergibt Microsoft bei der Erstellung. Ein Objekt, was Hard-Deleted ist, existiert nicht mehr. Wird es "wiederhergestellt", dann wird inhaltlich die Graph-API zur Erstellung eines Objekt (Benutzer, Datei, Gruppe) aufgerufen und ein Objekt mit den Eigenschaften oder Inhalten angelegt, die es vorher hatte.
Wenn also ein Benutzer aus dem Backup "recovered" werden soll, dann wird also mit hoher Wahrscheinlichkeit die zugehörige Graph-API "Create User" aufgerufen: https://learn.microsoft.com/en-us/graph/api/user-post-users?view=graph-rest-1.0
Ein Blick in die zugehörige API-Beschreibung zeigt die Restore-Challenge. Beim Anlegen eines Benutzers lassen sich Attribute wie accountEnabled, displayName und co. vergeben - die GUID aber nicht.
Es handelt sich technisch um ein neues Objekt. Die GUID ist auch in keiner Gruppe enthalten. Und die GUID des Benutzers hat auch auf kein SharePoint eine Berechtigung. Und das zugehörige E-Mail-Postfach des Benutzers gehört nicht zur GUID des gelöschten Kontos.
Nun möge man denken: Dann nimm doch einfach die API für Restore!
Und der Gedanke ist bei einer Enterprise-Lösung nur allzu naheliegend. Und tatsächlich gibt es den API-Endpunkt: https://learn.microsoft.com/en-us/graph/api/directory-deleteditems-restore?view=graph-rest-1.0&tabs=http.
Sie ahnen das Problem?
Natürlich gilt diese API nur für Objekte im Soft-Delete-Status, also jene, bei denen das ursprüngliche Objekt mit seiner GUID noch im Trashbin existiert.
Datensicherung vs. Konfigurationssicherung
Die Sicherung von Nutzdaten steht außer Frage. Doch wie sieht es aus mit der Konfiguration? Da sind nicht alle Backup-Lösungen auf der Höhe der Zeit und ein Blick zu seinem Anbieter kann sich lohnen. Insbesondere, wenn es sich um ein Microsoft 365-Backup handelt, dann sind CA-Policies, Config-Profiles und co. nicht immer in der Sicherung dabei. Für unsere eigenen M365-Services nutzen wir eine Kombination aus dem Entra Exporter gepaart mit einem individuellen Backup-Konzept, was über die Graph-API die relevanten Konfigurationen abruft und deren JSON-Repräsentation abspeichert. Das steigert die Flexibilität gegenüber M365DSC und ermöglicht gerade in größeren Umgebungen, gezielt die Sicherungen so zu verteilen, dass immer ein aktueller Datenbestand da ist. Recovery? Bleibt in allen Szenarien eine Herausforderung, die mit Bordmitteln schon etwas Arbeit verursacht!
Final words
Würden Sie eine Enterprise-SAAS-Lösung buchen, in der Backup und Restore nicht vollständig funktionieren?
Sie haben es getan! Herzlichen Glückwunsch!
Während über Regulatorik wie DORA oder NIS2 viel gemeckert wird, weil detaillierte und happige Vorgaben enthalten sind, stolpern gerade Unternehmen im Zuge der Compliance-Projekte über derartige Baustellen. Papier ist geduldig und die Möglichkeit, hunderte Security Groups inklusive Benutzer und Abhängigkeiten zu testen steht vielleicht noch nicht in jedem Testplan für die digitale Resilienz.
Wiederherstellungstests und Wiederanlauftests sind deutlich komplexer, als die "ich kann eine Datei in OneDrive recovern"-Szenarien, die einem im technischen Berateralltag begegnen. Nicht alle Herausforderungen und Restore-Challenges lassen sich ad-hoc lösen. Aber Transparenz darüber, dass es sie gibt, ist immer ein erster guter Schritt. Und das Risikomanagement erlaubt uns ja schließlich die Akzeptanz von Risiken oder die Definition von Maßnahmenplänen, um die identifizierten Risiken anzugehen.
Was bleibt zu tun? Hausaufgaben - wie so oft :):
- Prüfen, ob das Backup Daten und Konfiguration vollumfänglich umfasst
- Prüfen, ob die aktuellen Wiederherstellungs- und Notfalltests neben Daten auch die Konfiguration umfassen
- Maßnahmen ableiten und ggf. Backups und Restore-Prozesse anpassen
Dann sind nicht nur die Prüfer glücklich, sondern auch das eigene Gewissen.
Bei Fragen unterstützen wir Sie gerne im Rahmen unserer Dienstleistungen!