DORA-konform? Ja. Wiederherstellbar? Nicht garantiert …

Wer Object Lock aktiviert hat, glaubt, sein Backup sei ransomware-sicher. Wer seinen Offsite-Speicher bei AWS oder Azure betreibt, glaubt, seine Daten seien souverän. Beides kann falsch sein. Und weder DORA noch MaRisk prüfen, ob die Konfiguration tatsächlich hält.

von Marcel Jost, CI­SO Impossible Cloud

Wer als IT-Verantwortlicher in einem BaFin-regulierten Institut heute seinen Disaster-Recovery-Plan vorlegt, hat drei Dinge vorzuweisen: eine dokumentierte 3-2-1-Backup-Strategie, definierte RTO- und RPO-Werte sowie den Nachweis regelmäßiger Recovery-Tests.

Das genügt der Regulatorik. Es genügt nicht der Realität.“

Denn weder DORA noch MaRisk AT 7.3 greifen in die technische Infrastruktur ein. Beide verlangen Nachweise, keine Architekturen. Die Lücke entsteht auf Konfigurationsebene, und sie ist in keiner Compliance-Checkliste sichtbar.

Schicht eins: Die Backup-Architektur

MaRisk AT 7.3 schreibt Notfallkonzepte mit definierten Wiederanlaufzeiten vor. DORA konkretisiert das EU-weit: Artikel 12 verlangt Backup-Richtlinien mit RPO- und RTO-Werten, Artikel 17 fordert den Nachweis, dass diese Werte im Ernstfall eingehalten werden. Für kritische Systeme liegen die Zielwerte typischerweise bei RPO unter einer Stunde und RTO unter vier Stunden.

Das Fundament ist die 3-2-1-Backup-Regel: drei Kopien, auf zwei Medien, eine davon Offsite.“

Für Institute mit on-premises-Primärinfrastruktur bedeutet das: Die Offsite-Kopie landet bei einem Cloud-Anbieter über eine S3-kompatible API. Marktführer Veeam hält rund 25 Prozent Marktanteil im Enterprise-Segment; daneben gibt es weitere etablierte Anbieter, darunter europäische wie Novastore aus Hamburg.
Moderne Backup-Lösungen arbeiten mit inkrementellen Backups. Veeam nutzt dafür CBT (Changed Block Tracking), das auf Hypervisor-Ebene ansetzt und nur veränderte Datenblöcke überträgt, dupliziert und komprimiert. Das Netzwerk ist der entscheidende Flaschenhals: Wer die Bandbreite zum Offsite-Speicher nicht ausreichend dimensioniert, riskiert inkonsistente Restore-Punkte, weil Backup-Jobs nicht abgeschlossen werden, bevor der nächste startet. Ist die Anbindung stabil, lassen sich RPO-Werte unter einer Stunde mit unbegrenzter Versionierung realisieren.
Das Setup funktioniert, solange niemand aktiv eingreift.

Schicht zwei: Object Lock, und warum die Konfiguration entscheidet

Ransomware verschlüsselt oder löscht Daten. Besonders gefährlich sind dabei Angreifer, die sich monatelang unentdeckt im System bewegen: Sie können gezielt warten, bis saubere Restore-Punkte aus dem Versionierungsfenster herausgefallen sind – und erst dann den eigentlichen Angriff auslösen. Damit ist das Backup wertlos, bevor der Schaden überhaupt sichtbar wird. Die Antwort ist Object Lock, auf dem WORM-Prinzip basierend (Write Once Read Many).

Auf Objektebene kann Retention etwa über x-amz-object-lock-mode und x-amz-object-lock-retain-until-date gesetzt werden; alternativ kann eine Default Retention auf Bucket-Ebene neue Objektversionen automatisch schützen.“

Während der Retention-Periode bleibt eine geschützte Objektversion mit den passenden Berechtigungen lesbar, kann aber nicht dauerhaft überschrieben oder per versioniertem DELETE gelöscht werden. Ein PUT auf denselben Key erzeugt bei aktivem Versioning eine neue Version; ein DELETE ohne Versions-ID setzt lediglich einen Delete-Marker. Die gesperrte Version wird dadurch nicht entfernt, kann aber für normale Lese- und Listenoperationen aus dem Vordergrund verschwinden. Im Governance-Modus können Nutzer mit s3:Bypass­Governance­Retention den Lock aufheben. Im Compliance-Modus ist das für niemanden möglich, auch nicht für den Root-Account. Für regulierte Umgebungen ist der Compliance-Modus daher der relevante.

Ein typischer Konfigurationsfehler: Object Lock muss vor dem ersten Schreibvorgang auf Bucket-Ebene aktiviert sein. Ein nachträgliches Aktivieren ist nicht möglich.“

Die Verknüpfung mit Versionierung ist dagegen keine separate Fehlerquelle: Gängige Cloud-Provider verhindern technisch, dass Object Lock ohne aktive Versionierung eingerichtet werden kann. Object Lock schützt gesperrte Versionen vor permanenter Löschung oder Veränderung, verhindert aber nicht, dass neue Versionen oder Delete-Marker entstehen. Ein DELETE ohne Versions-ID entfernt die gesperrte Version nicht, sondern setzt einen Delete-Marker; Restore-Prozesse müssen deshalb Versionen und Delete-Marker korrekt berücksichtigen.

Hinzu kommt: Object Lock muss vom Cloud-Speicher vollständig implementiert und durch eine Zertifizierung des Backup-Software-Herstellers bestätigt sein.“

Wer einen nicht zertifizierten Anbieter einsetzt, riskiert, dass Object Lock im Ernstfall nicht greift. Technisch sieht das Setup vollständig aus. Es ist es nicht. Und selbst wenn es das wäre, bleibt eine Lücke, die sich auf Storage-Ebene nicht schließen lässt.

Schicht drei: Die Rechtsfrage, die keine Checkliste stellt

Daten bei einem amerikanischen Cloud-Anbieter in einem deutschen Rechenzentrum unterliegen nicht europäischem Recht. Der US CLOUD Act von 2018 verpflichtet amerikanische Unternehmen, US-Behörden bei gezielten Anfragen Zugang zu Daten zu gewähren, unabhängig vom physischen Speicherort. Das gilt für Google Cloud und weitere Anbieter gleichermaßen.

DORA Artikel 28 verlangt, dass Institute Konzentrationsrisiken bei IKT-Drittdienstleistern bewerten und sicherstellen, dass kritische Funktionen nicht von einem Anbieter abhängen, dessen Ausfall nicht kompensiert werden kann.“

Ein US-Anbieter, der unter politischem Druck Dienste einschränkt oder dessen Datenzugang behördlich eingeschränkt wird, ist genau dieses Szenario. Egress-Gebühren verschärfen das: Wer hunderte Terabyte Backup-Daten migrieren muss, zahlt dafür, und zwar dann, wenn der Druck am größten ist.
DORA prüft lediglich, ob eine Offsite-Kopie existiert und ein Drittanbietervertrag vorliegt. Sie prüft nicht, ob der Zugriff im Ernstfall garantiert ist.

Was das für die Praxis bedeutet

Ein DR-Setup, das alle drei Schichten sauber umsetzt, umfasst: Backup-Software mit zertifizierter Object-Lock-Unterstützung, CBT-basierte inkrementelle Backups alle 15 bis 30 Minuten für kritische Systeme, Object Lock im Compliance-Modus mit aktiver Versionierung, Retention-Perioden, die auch verzögert entdeckte Angriffe abdecken, sowie einen Cloud-Anbieter, der ausschließlich europäischem Recht unterliegt. Dazu kommen regelmäßige Restore-Tests mit Messung der tatsächlich erreichten RTO-Werte, inklusive des Szenarios, in dem der primäre Cloud-Anbieter nicht erreichbar ist.

Ein Institut, das seinen DR-Plan auf Basis eines US-amerikanischen Cloud-Anbieters aufgebaut hat, ist möglicherweise DORA-konform und erfüllt MaRisk AT 7.3.“

Ob seine Daten im Ernstfall tatsächlich wiederherstellbar sind, hängt von Faktoren ab, die außerhalb seiner Kontrolle liegen. Die Regulatorik gibt darauf keine Antwort. Die Architekturentscheidung muss es tun. von Marcel Jost, Impossible Cloud