Recovery neu denken: Wenn Restore Sicherheit nicht garantiert

Persistenz ohne Vertrauensanker wird zum Risiko

Genau hier liegt die Schwachstelle einiger Architekturen. Daten werden als persistente Objekte betrachtet, deren Zustand sich aus der letzten erfolgreichen Schreiboperation ergibt. In vielen Cloud-Umgebungen ist jedoch nicht der Datenverlust das eigentliche Problem, sondern die fehlende Möglichkeit zu beweisen, dass ein Datenbestand überhaupt noch korrekt ist.

Wenn Angreifer Schreibzugriffe oder erhöhte API-Berechtigungen erlangen, können sie Daten gezielt verändern, ohne sofort auffällige Anomalien im Systemverhalten zu erzeugen. Die Kompromittierung verschiebt sich damit von der Infrastruktur auf die semantische Integrität der Daten selbst. Da diese Veränderungen innerhalb legitimer Prozesse stattfinden, bleiben sie für klassische Intrusion Detection und Monitoring häufig unsichtbar.

Unsere Daten zeigen, dass 52 Prozent der Unternehmen in Deutschland nicht sicher sind, dass ihre Daten nach einem Cyberangriff unverändert und funktionsfähig bleiben. Diese Unsicherheit ist technisch begründet, denn in manchen Umgebungen fehlt eine saubere Trennung zwischen produktiven Datenströmen und deren Sicherungskopien auf Ebene von Identitäten, APIs und administrativen Kontrollpfaden.  Sobald IAM-Strukturen kompromittiert sind, können Angreifer auf beide Ebenen zugreifen und sie manipulieren.

Hinzu kommt, dass fast die Hälfte aller deutschen Unternehmen bereits Angriffe erlebt hat, bei denen der Zugriff auf Public-Cloud-Daten temporär oder dauerhaft unterbrochen wurde. Solche Ausfälle entstehen nicht zwingend durch physische Zerstörung von Daten, sondern häufig durch gezielte Manipulation von Zugriffskontrollen, Bucket Policies oder Versionierungslogiken. In verteilten Objektspeichern genügt es, Referenzen innerhalb der Versionierung oder Indexstrukturen zu verändern, um Daten logisch unlesbar zu machen, obwohl sie physisch weiterhin vorhanden sind.

Wie Angreifer gezielt Metadaten und Versionierung ausnutzen

38 Prozent der von uns befragten Unternehmen geben an, dass ihre Public-Cloud-Anbieter nicht die notwendigen Funktionen bereitstellen, um solche Szenarien adäquat zu adressieren. Das Problem liegt weniger in fehlenden Sicherheitsmechanismen als in unzureichend geschützten Kontrollpfaden. Versionierungsfunktionen lassen sich über API-Zugriffe manipulieren. Darüber hinaus sind Object-Lock-Mechanismen nicht konsequent durchgesetzt oder über privilegierte Rollen umgehbar, und Metadaten werden selten als eigenständige Angriffsfläche behandelt.

Ohne manipulationssichere Versionierung, strikt getrennte Kontrollinstanzen und unveränderbare Referenzpunkte lässt sich nicht eindeutig bestimmen, welcher Datenstand vertrauenswürdig ist. Manche Architekturen verfügen zwar über zahlreiche Snapshots oder Versionen, jedoch fehlt ein belastbarer Mechanismus, um deren Integrität unabhängig von kompromittierten Identitäten zu validieren.

In der Praxis zeigt sich dabei eine zusätzliche Schwachstelle, die über reine Integritätsfragen hinausgeht. Selbst wenn Datenstände grundsätzlich vorhanden sind, werden sie häufig nicht aktiv genutzt oder getestet, weil der Zugriff auf große Datenmengen mit erheblichen Kosten verbunden ist. In manchen Cloud-Umgebungen entfallen signifikante Teile der Ausgaben nicht auf die Speicherung selbst, sondern auf Zugriff, Egress und wiederholtes Laden von Daten für Test- und Validierungszwecke. Zudem geben 48 Prozent der deutschen Unternehmen an, ihr Cloud-Storage-Budget überschritten zu haben, wobei 88 Prozent mindestens einen gebührenbezogenen Faktor als Ursache für die höheren Ausgaben nennen. Das führt dazu, dass genau jene Recovery-Szenarien, die im Ernstfall funktionieren müssen, im Alltag zu selten überprüft werden.

Diese Defizite werden durch den zunehmenden Einsatz datengetriebener Anwendungen verstärkt. KI-Workloads erzeugen und verarbeiten große Mengen an Trainings- und Produktionsdaten, deren Konsistenz unmittelbar die Qualität der Ergebnisse beeinflusst. In Deutschland sichern 95 Prozent der Unternehmen ihre produktiven KI-Daten, 74 Prozent auch Entwicklungsumgebungen. Die Sicherung allein löst jedoch nicht das Problem der Integritätsfrage. Werden Trainingsdaten auf Ebene einzelner Features oder Label verändert, entstehen fehlerhafte Modelle, ohne dass dies unmittelbar sichtbar wird. Die Wiederherstellung reproduziert in diesem Fall lediglich deterministisch denselben Fehler.

Warum Redundanz ohne Zustandskontrolle ins Leere läuft

Technisch betrachtet erfordert Datenresilienz mehr als Redundanz oder geografische Verteilung. Replikation schützt vor Infrastrukturverlust, repliziert jedoch auch kompromittierte Zustände. Entscheidend ist die Fähigkeit, Zustände eindeutig zu versionieren, voneinander zu isolieren und gegen nachträgliche Veränderung abzusichern.

Unveränderbare Storage-Mechanismen sind ein zentraler Baustein, da sie Schreiboperationen nach Abschluss logisch einfrieren und damit eine nachträgliche Manipulation unterbinden. In Kombination mit objektbasierter Versionierung entsteht eine belastbare Zustandschronologie, die nicht durch privilegierte API-Zugriffe überschrieben werden kann.

„In der Praxis zeigt sich dabei eine zusätzliche Schwachstelle, die über reine Integritätsfragen hinausgeht. Selbst wenn Datenstände grundsätzlich vorhanden sind, werden sie häufig nicht aktiv genutzt oder getestet, weil der Zugriff auf große Datenmengen mit erheblichen Kosten verbunden ist.“

Marco Pfuhl, Wasabi

Darüber hinaus gewinnen Architekturen an Bedeutung, die besonders schützenswerte Datenbestände nicht nur unveränderbar speichern, sondern sie der regulären Sichtbarkeit innerhalb der Umgebung vollständig entziehen. Solche logisch isolierten Kopien sind weder über Standard-APIs adressierbar noch über kompromittierte Identitäten auffindbar und erfordern mehrstufige Autorisierung, um überhaupt zugänglich zu werden. Damit verschiebt sich der Schutzansatz von reiner Unveränderlichkeit hin zu einer Kombination aus Isolation, Nichtauffindbarkeit und kontrolliertem Zugriff.

Ebenso entscheidend ist die Trennung von Control Plane und Data Plane sowie die Isolation von Kontrollpfaden. In manchen Architekturen teilen sich produktive Workloads und Backup-Prozesse dieselben Identitäts- und Berechtigungsmodelle. Wird eine administrative Identität kompromittiert oder lateral erweitert, lassen sich darüber sowohl Daten verändern als auch Sicherungskopien löschen oder Versionierungsregeln anpassen. Eine belastbare Architektur erfordert dedizierte Kontrollinstanzen mit strikt getrennten Zugriffspfaden, die nicht über dieselben IAM-Strukturen erreichbar sind wie die Primärumgebung.

Recovery als deterministisches Systemproblem statt Notfallprozess

Ein weiterer technischer Aspekt betrifft die Wiederherstellungslogik selbst. In komplexen Cloud-Umgebungen bestehen Anwendungen aus verteilten Zuständen, die über mehrere Services, Datenbanken und Storage-Klassen hinweg konsistent gehalten werden müssen. Eine Wiederherstellung auf Basis inkonsistenter Zeitpunkte oder nicht synchronisierter Snapshots führt zu funktionalen Fehlern, selbst wenn einzelne Datensätze formal korrekt erscheinen.

Recovery wird damit zu einem deterministischen Problem.  Ziel ist nicht Verfügbarkeit, sondern die reproduzierbare Herstellung eines konsistenten Systemzustands über alle Abhängigkeiten zwischen Datenquellen, Services und Metadatenstrukturen hinweg. Ohne ein solches Modell bleibt jede Wiederherstellung ein Best-Effort-Ansatz mit begrenzter Aussagekraft.

Damit Recovery in der Praxis belastbar wird, müssen diese Zustände nicht nur definiert, sondern regelmäßig und wirtschaftlich überprüfbar sein. Architekturen, die den Zugriff auf große Datenmengen für Tests und Validierungen ohne zusätzliche Gebühren oder operative Hürden ermöglichen, schaffen hier einen entscheidenden Vorteil. Erst wenn Wiederherstellungsszenarien ohne Kostenbarrieren regelmäßig durchgespielt werden können, lässt sich die tatsächliche Funktionsfähigkeit im Ernstfall sicherstellen.

Regelmäßige Tests sind in diesem Kontext kein organisatorisches Beiwerk, sondern ein technischer Validierungsmechanismus. Gleichzeitig wird ihre Umsetzung durch operative und kommerzielle Faktoren begrenzt, da das wiederholte Laden großer Datenmengen in vielen Cloud-Architekturen kostenpflichtig ist und damit direkt die Häufigkeit und Tiefe von Validierungsszenarien beeinflusst. Nur durch vollständige Wiederherstellungsszenarien unter realistischen Bedingungen lässt sich überprüfen, ob definierte Zustände tatsächlich reproduzierbar sind und ob Control Plane und Data Plane konsistent zusammengeführt werden können. Entscheidend ist dabei die vollständige Rekonstruktion eines konsistenten Zustandsgraphen.

Die eigentliche Schwachstelle ist weniger die Häufigkeit von Angriffen, als die fehlende Möglichkeit, die Korrektheit von Datenzuständen nach einem Vorfall überhaupt noch nachzuweisen. Neben Verfügbarkeit und Skalierbarkeit wird die nachweisbare Integrität zur eigenständigen Systemeigenschaft. Erst wenn Datenzustände eindeutig überprüfbar und reproduzierbar sind, entsteht eine belastbare Grundlage für Geschäftskontinuität. Recovery wird dadurch zur deterministische Kernfunktion moderner Systemarchitekturen.

Über den Autor:
Marco Pfuhl ist Country Manager für Deutschland, Österreich und die Schweiz bei Wasabi Technologies und verantwortlich für Wachstum und Marktentwicklung im Bereich Cloud-Storage in diesen Ländern. Zuvor war er in verschiedenen Vertriebs- und Führungspositionen bei anderen Unternehmen tätig.

Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.