Nachdem wir uns angeschaut haben, wie viel Kontrolle BYOK, Customer Key und Double Key Encryption wirklich bieten, stellt sich fast zwangsläufig die nächste Frage: Was bedeutet das eigentlich für Backup und Wiederherstellung? Hier entsteht in der Praxis einer der größten Denkfehler rund um Microsoft 365.

Im sogenannten Shared Responsibility Model betreibt Microsoft die Plattform und sorgt für deren Verfügbarkeit – für den Schutz und die Sicherung der eigenen Daten bleibt jedoch der Kunde verantwortlich. Microsoft empfiehlt ausdrücklich, Daten zusätzlich zu sichern.

Retention ist kein Backup

Der zentrale Irrtum liegt dabei oft in der Verwechslung von Retention und Backup. Microsoft 365 bietet umfangreiche Funktionen wie Aufbewahrungsrichtlinien, Versionierung oder Papierkörbe. Diese wirken auf den ersten Blick wie ein Backup, sind es aber nicht.

Retention dient der Governance und Compliance – also der Frage, wie lange Daten aufbewahrt oder gelöscht werden. Ein echtes Backup hingegen dient der Wiederherstellung nach einem Schadenfall. Das hat konkrete Konsequenzen: Wird eine Datei gelöscht und die Aufbewahrungsfrist läuft ab, wird sie endgültig entfernt – eine Wiederherstellung ist dann nicht mehr möglich. Auch Funktionen wie Litigation Hold helfen hier nur eingeschränkt, denn sie sind für eDiscovery und rechtliche Aufbewahrung optimiert, nicht für schnelle Wiederherstellung im Betrieb.

Verschlüsselung und Wiederherstellbarkeit

Gerade im Kontext von BYOK, Customer Key und DKE wird das besonders spannend. Denn: Mehr Kontrolle über Verschlüsselung bedeutet nicht automatisch bessere Wiederherstellbarkeit. Im Gegenteil – sie kann sie sogar komplizierter machen.

Bei Customer Key und BYOK hängt die Lesbarkeit der Daten unmittelbar an der Verfügbarkeit und Korrektheit der Schlüssel. Geht ein Schlüssel verloren oder wird falsch konfiguriert, kann das im schlimmsten Fall dazu führen, dass Daten nicht mehr entschlüsselt werden können – selbst wenn sie technisch noch vorhanden sind. Backup-Strategien müssen diese Abhängigkeit zwingend berücksichtigen.

Noch deutlicher wird es bei Double Key Encryption. Hier ist ein externer, kundenseitig kontrollierter Schlüssel notwendig, um Daten überhaupt zu entschlüsseln. Das bedeutet: Ohne diesen Schlüssel ist auch ein Backup wertlos, weil die Daten zwar vorhanden, aber nicht lesbar sind. Gleichzeitig sind viele Plattformfunktionen eingeschränkt, was auch Backup- und Restore-Szenarien beeinflussen kann.

Was eine belastbare Backup-Strategie braucht

Daraus ergibt sich eine entscheidende Erkenntnis: Backup in Microsoft 365 ist kein Feature, sondern ein Architekturthema. Eine belastbare Strategie muss mehrere Dinge gleichzeitig berücksichtigen.

Erstens braucht es eine echte, unabhängige Sicherungskopie der Daten. Native Funktionen arbeiten „in place“, also innerhalb derselben Plattform. Ein Backup hingegen sollte eine getrennte Kopie erzeugen, die auch bei Ransomware, Fehlkonfiguration oder Tenant-Kompromittierung nutzbar bleibt.

Zweitens müssen Workloads unterschiedlich betrachtet werden. Exchange, SharePoint, OneDrive und Teams haben unterschiedliche Datenstrukturen und Wiederherstellungsmöglichkeiten. Eine einheitliche „One size fits all“-Strategie funktioniert hier selten.

Drittens ist das Thema Wiederherstellbarkeit (Recovery) wichtiger als das reine Vorhandensein von Daten. Entscheidend ist nicht, ob Daten existieren, sondern ob sie vollständig, konsistent und innerhalb eines akzeptablen Zeitfensters wiederherstellbar sind. Microsoft selbst unterscheidet hier klar über Kennzahlen wie Recovery Point Objective (RPO) – also wie viel Datenverlust maximal akzeptabel ist.

Und schließlich – und das ist oft der kritischste Punkt – müssen Backup und Verschlüsselung zusammengedacht werden. Wer eigene Schlüssel nutzt, muss sicherstellen, dass Schlüssel verfügbar bleiben (Key Lifecycle Management), Backups im Ernstfall auch entschlüsselbar sind und Prozesse für Schlüsselverlust oder Rotation existieren.

Fazit

Ein perfekt verschlüsseltes System ohne funktionierende Wiederherstellung ist im Ernstfall genauso problematisch wie ein unsicheres System.

Die eigentliche Herausforderung liegt also nicht darin, sich zwischen BYOK, Customer Key oder DKE zu entscheiden – sondern darin, diese Entscheidungen in eine durchdachte Backup- und Recovery-Strategie einzubetten.