M365 Backup Realitätscheck: Was gesichert ist – und was nicht

Microsoft 365 läuft. Die Mails kommen an, Teams-Meetings funktionieren, SharePoint liefert Dokumente. Viele Organisationen schließen daraus: „Microsoft kümmert sich schon um Backups." Das ist ein Irrtum mit potenziell teuren Konsequenzen. Dieser Artikel zeigt, wo die tatsächlichen Grenzen der eingebauten Datensicherung liegen – und wo ein eigenständiges Backup-Konzept zwingend erforderlich ist.

Das Shared-Responsibility-Modell verstehen

Microsoft betreibt die Infrastruktur hochverfügbar und repliziert Daten georedundant. Damit ist sichergestellt, dass der Dienst selbst verfügbar bleibt. Was Microsoft nicht übernimmt, ist der Schutz vor logischen Datenverlusten: versehentlichem Löschen, bösartigen Aktionen durch interne Accounts oder Ransomware, die Dateien verschlüsselt, bevor die Retention-Periode greift.

In den Microsoft-Nutzungsbedingungen steht sinngemäß: Der Kunde trägt die Verantwortung für seine Daten. Microsoft empfiehlt ausdrücklich den Einsatz von Drittanbieter-Backuplösungen. Das klingt unspektakulär, hat aber erhebliche praktische Auswirkungen.

Was Microsoft nativ bietet – und was das bedeutet

M365 stellt mehrere Mechanismen bereit, die wie Backups wirken, es aber technisch nicht sind:

• Papierkorb (Exchange, SharePoint, OneDrive): Gelöschte Elemente landen im Papierkorb und können innerhalb definierter Fristen wiederhergestellt werden. Exchange hält gelöschte Mails standardmäßig 14 Tage, SharePoint 93 Tage im Site-Papierkorb.
• Versionsverlauf (SharePoint/OneDrive): Dateien werden in mehreren Versionen vorgehalten. Die Anzahl konfigurierbarer Versionen ist begrenzt – bei intensiver Bearbeitung können ältere Versionen schnell verdrängt werden.
• Litigation Hold / In-Place Hold: Mails und Dokumente lassen sich für rechtliche Zwecke einfrieren. Das ist kein Backup, sondern eine Compliance-Funktion – sie schützt vor Löschung, erlaubt aber keine granulare Wiederherstellung einzelner Elemente in den Originalzustand.
• Recycle Bin Second Stage: SharePoint kennt einen zweistufigen Papierkorb. Aber: Wird ein Site-Collection-Admin die zweite Stufe leert, sind Daten endgültig weg.

Das Problem: Alle diese Mechanismen arbeiten innerhalb desselben Mandanten. Ein kompromittiertes Admin-Konto kann sie deaktivieren oder leeren – bevor irgendjemand reagiert hat.

Exchange Online: Wo die Lücken liegen

Exchange Online bietet keine vollständige Point-in-Time-Wiederherstellung auf Postfachebene. Was fehlt:

• Kalendereinträge und Kontakte aus gelöschten Postfächern lassen sich nach Ablauf der Aufbewahrungsfrist nicht wiederherstellen.
• Postfachregeln, Signaturen und Delegates werden nicht versioniert.
• Shared Mailboxes ohne Litigation Hold sind nach dem Löschen des letzten Benutzers unmittelbar gefährdet.
• Bei einem Ransomware-Angriff, der Mails ändert (statt nur löscht), greift der Papierkorb nicht – die veränderte Version ist die „aktuelle".

SharePoint und OneDrive: Sync-Probleme als unterschätzte Gefahr

Der OneDrive-Sync-Client ist praktisch – und ein potenzieller Angriffspfad. Ransomware, die lokal ausgeführt wird, kann über den Sync-Client tausende Dateien in SharePoint überschreiben, bevor die Versionierung greift. Versionen können manuell oder per Skript bereinigt werden:

# Alle Versionen einer Datei außer der aktuellen löschen (PnP PowerShell)
Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/Marketing" -Interactive

$file = Get-PnPFile -Url "/sites/Marketing/Shared Documents/Bericht.xlsx" -AsFileObject
$versions = Get-PnPFileVersion -Url "/sites/Marketing/Shared Documents/Bericht.xlsx"

foreach ($version in $versions) {
    Remove-PnPFileVersion -Url "/sites/Marketing/Shared Documents/Bericht.xlsx" `
        -Identity $version.Id -Force
}

Dieses Skript ist legitim für Speicheroptimierung – aber ein Angreifer mit Site-Owner-Rechten kann es genauso einsetzen, um Wiederherstellungspunkte zu vernichten. Nach Ausführung bleibt nur die verschlüsselte Version übrig.

Weitere Risikofaktoren bei SharePoint:

• Site-Collections können von Site-Admins dauerhaft gelöscht werden.
• Die 93-Tage-Retention gilt für den Papierkorb, nicht für Versionen. Wer 500 Versionen aktiviert hat, schützt sich besser – aber das ist kein Standard.
• Microsoft Lists und Planner haben keine Versionierung und keinen vergleichbaren Schutz.

Microsoft Teams: Die blinden Flecken

Teams-Chats werden in verborgenen Exchange-Ordnern gespeichert (SubstrateHold). Das klingt gut, hat aber Einschränkungen:

• Direktnachrichten (1:1 und Gruppen-Chats) werden im Postfach des jeweiligen Nutzers gespeichert – verlässt der Nutzer das Unternehmen und wird das Postfach gelöscht, gehen diese Daten verloren.
• Teams-Kanalnachrichten landen im Group-Mailbox der M365-Gruppe. Wird die Gruppe gelöscht, startet eine 30-Tage-Frist – danach sind auch Kanalnachrichten weg.
• Teams-Meeting-Aufzeichnungen (Stream) haben eigene Retention-Richtlinien, die separat konfiguriert werden müssen.
• Tabs, Wikis und App-Daten in Teams-Kanälen werden von keiner nativen Retention-Richtlinie erfasst.

Entra ID (Azure AD): Oft vergessen, selten gesichert

Entra ID enthält Gruppen, Rollen, App-Registrierungen, Conditional-Access-Richtlinien und Benutzerattribute. Microsoft bietet keinen nativen Export oder Snapshot dieser Konfigurationen. Was das bedeutet:

• Accidentell gelöschte Gruppen können über das Entra-Portal 30 Tage lang wiederhergestellt werden – aber nur, wenn es sich um M365-Gruppen handelt. Sicherheitsgruppen haben keinen Papierkorb.
• Gelöschte App-Registrierungen und Service Principals sind nach 30 Tagen endgültig verloren.
• Conditional-Access-Richtlinien haben keine Versionierung. Ein falsch konfiguriertes Update kann den Zugang für alle Nutzer sofort blockieren – und es gibt kein „Undo".

Für Entra ID empfiehlt sich ein regelmäßiger Export der Konfiguration per Microsoft Graph API:

# Conditional Access Policies exportieren (Graph API via curl)
ACCESS_TOKEN=""

curl -s -H "Authorization: Bearer $ACCESS_TOKEN" \
  "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" \
  | jq '.' > ca_policies_$(date +%Y%m%d).json

# App-Registrierungen exportieren
curl -s -H "Authorization: Bearer $ACCESS_TOKEN" \
  "https://graph.microsoft.com/v1.0/applications?\$top=999" \
  | jq '.' > app_registrations_$(date +%Y%m%d).json

Dieser Export ist kein vollständiges Backup, aber er ermöglicht eine schnelle Rekonstruktion kritischer Richtlinien nach einem Vorfall.

Drittanbieter-Backuplösungen: Worauf es ankommt

Dedizierte M365-Backup-Lösungen (etwa Veeam Backup for Microsoft 365, Acronis Cyber Protect, Commvault) arbeiten über die Graph API und sichern Daten außerhalb des M365-Mandanten. Entscheidende Kriterien bei der Auswahl:

• Datenspeicherort: Werden Backups in einem eigenen Storage-Account (Azure, on-premises, S3) gespeichert oder beim Anbieter? Im zweiten Fall verlässt man eine Cloud und betritt die nächste.
• Granularität der Wiederherstellung: Kann eine einzelne Mail, eine Dateiversion oder ein Kalendertermin gezielt zurückgespielt werden? Oder nur ganze Postfächer?
• Abdeckung: Werden Exchange, SharePoint, OneDrive, Teams-Chats, Teams-Kanäle, Planner und Entra ID abgedeckt – oder nur ein Teil davon?
• API-Throttling-Handling: Microsoft drosselt API-Anfragen. Lösungen, die das nicht sauber handhaben, produzieren unvollständige Backups ohne Fehlermeldung.
• Immutability: Können Backups selbst gelöscht oder verändert werden? WORM-Storage oder unveränderliche Blobs sind Pflicht für Ransomware-Schutz.

Retention Policies sind kein Backup-Ersatz

Ein häufiger Denkfehler: Wer Retention-Richtlinien im Microsoft Purview Compliance Portal konfiguriert, glaubt, damit ein Backup zu haben. Der Unterschied ist fundamental:

Retention-Richtlinien verhindern das endgültige Löschen von Daten für Compliance-Zwecke. Sie sind für eDiscovery und gesetzliche Aufbewahrungspflichten gedacht, nicht für operative Wiederherstellung. Sie ermöglichen keine granulare Restauration in einen bestimmten Zustand, keinen Export in ursprüngliche Ordnerstrukturen und keine Wiederherstellung von Metadaten wie Berechtigungen oder Sharing-Links.

Kurz: Retention sichert den Zugriff auf Daten für Juristen – Backup sichert den Betrieb nach einem Vorfall.

Fazit und Handlungsempfehlungen

M365 ist kein selbst gesichertes System. Die eingebauten Mechanismen sind für Standardfälle ausreichend – nicht für ernsthafte Vorfälle. Eine pragmatische Grundstrategie:

1. Bestandsaufnahme: Welche Daten liegen wo? Exchange, SharePoint, Teams, OneDrive, Entra ID – jeder Dienst braucht eine eigene Betrachtung.
2. Kritikalität bewerten: Nicht alles braucht gleichwertigen Schutz. Kundenkommunikation und Vertragsunterlagen haben andere Anforderungen als interne Arbeitsnotizen.
3. Drittanbieter-Backup einführen: Für produktive Umgebungen ist ein externes Backup kein Nice-to-have, sondern Teil einer verantwortungsvollen IT-Governance.
4. Entra-ID-Konfiguration exportieren: Auch ohne vollständige Lösung: regelmäßige Exports per Graph API und Ablage in einem versionierten Repository (z. B. Azure DevOps, Git) sind besser als gar nichts.
5. Wiederherstellung testen: Ein Backup, das nie getestet wurde, ist eine Vermutung. Mindestens jährlich sollte eine Wiederherstellung einzelner Elemente durchgespielt werden.

Die gute Nachricht: Die technischen Mittel für ein solides M365-Backup-Konzept sind vorhanden. Die schlechte Nachricht: Sie sind nicht standardmäßig aktiviert – und die Verantwortung liegt beim Kunden.