Unveränderliche Backups, WORM, Air Gap und Ransomware: was ein Backup vor Angreifern schützt

Von Lucas Flores, IT Systeme Flores UG. Zuletzt aktualisiert am 2026-10-16

Wie gehen Angreifer gegen Backups vor?

Der #StopRansomware Guide der CISA sagt, dass die meisten Ransomware-Akteure versuchen, erreichbare Backups zu finden und dann zu löschen oder zu verschlüsseln, damit eine Wiederherstellung unmöglich ist, wenn das Lösegeld nicht bezahlt wird. Sie suchen nach Zugangsdaten, die in der Umgebung liegen, und nutzen sie gegen Backup-Lösungen, und sie setzen öffentliche Exploits gegen Backup-Lösungen ein, die nicht gepatcht sind. Die CISA warnt auch, dass ein automatisches Cloud-Backup, das nur Dateien synchronisiert, nicht genügen muss: Werden lokale Dateien verschlüsselt, werden die verschlüsselten Dateien synchronisiert und können gute Daten in der Cloud überschreiben.

MITRE ATT&CK beschreibt die Techniken genauer unter „Inhibit System Recovery“. Angreifer löschen mit eingebauten Werkzeugen die Windows-Schattenkopien und den Backup-Katalog, löschen Snapshots virtueller Maschinen und löschen Online-Backups auf Netzwerkspeicher oder in Ordnern, die mit der Cloud synchronisiert sind. In Cloud-Umgebungen schalten sie Versionierung und Backup-Richtlinien ab und löschen dann Snapshots, Backups und frühere Objektversionen. Das BSI, das Bundesamt für Sicherheit in der Informationstechnik, schreibt, es sei gängige Praxis, dass Angreifende mit Administratorrechten nach allen Backups suchen und sie ebenso wie die Produktivsysteme verschlüsseln.

Der gemeinsame Nenner ist der Zugriff. Ein Angreifer nutzt dieselben Zugangsdaten, denselben Netzwerkpfad und dieselbe Administratorrolle, die Ihre Backup-Software nutzt. Ein Backup, das die Software löschen kann, kann ein Angreifer mit dem Zugriff dieser Software auch löschen. Beide Maßnahmen unten sind Wege, diesen Zugriff weniger wichtig zu machen.

Was leisten Unveränderlichkeit und WORM?

Unveränderlich heißt, dass der Speicher durchsetzt, dass Daten für einen festgelegten Zeitraum weder geändert noch gelöscht werden können, statt sich darauf zu verlassen, dass die Backup-Software sich benimmt. WORM, write once read many, ist das Modell: Das SNIA Dictionary beschreibt es als Speicher für feste Inhalte, der bewahrt, was darauf geschrieben wird, auf unveränderliche Weise.

Das weit verbreitete Beispiel ist Amazon S3 Object Lock. Es schützt eine einzelne Objektversion auf eine von zwei Arten, mit einem Aufbewahrungszeitraum mit Enddatum oder einer rechtlichen Aufbewahrungsfrist (Legal Hold) ohne, und es funktioniert nur in Buckets mit eingeschalteter Versionierung. Ein dauerhaftes Löschen einer gesperrten Version wird abgelehnt. Ein einfaches Löschen ohne Versions-ID wird angenommen, legt aber nur eine Löschmarkierung obenauf, die gesperrten Versionen bleiben darunter. Auch andere S3-kompatible Dienste bieten Object Lock, mit eigenen Grenzen: Die Dokumentation von Hetzner sagt zum Beispiel, es müsse beim Erstellen des Buckets aktiviert werden und lasse sich nicht nachträglich hinzufügen.

Was ist der Unterschied zwischen Governance-Modus und Compliance-Modus?

Ein Aufbewahrungszeitraum hat einen von zwei Modi, und die Wahl ist der Kern der Sache:

Eine rechtliche Aufbewahrungsfrist (Legal Hold) bietet denselben Schutz wie ein Aufbewahrungszeitraum ohne Enddatum, und sie bleibt, bis jemand mit der richtigen Berechtigung sie entfernt. Die CISA fügt eine Warnung hinzu, die für alles gilt: Unveränderlicher Speicher erfüllt die Kriterien bestimmter Vorschriften nicht, und eine Fehlkonfiguration kann erhebliche Kosten verursachen, weil Sie für das zahlen, was Sie nicht löschen können.

Was deckt Unveränderlichkeit nicht ab?

• Daten, die schon beim Sichern schlecht waren. Gesperrter Speicher bewahrt, was man ihm gab. Hat Schadsoftware Dateien vor dem Lauf verschlüsselt, enthält der gesperrte Sicherungsstand verschlüsselte Dateien. Das BSI merkt an, dass Angreifer sich teils mehrere Wochen im Netz bewegen und daher schon im Backup stecken können, und es empfiehlt, Backups vor einem Restore auf Schadsoftware zu prüfen und mit Kopien der Backups oder einem Write-Blocker zu arbeiten.
• Diebstahl von Daten. Das BSI sagt ausdrücklich, dass Backups nicht vor Angreifenden schützen, die Daten kopieren und mit deren Veröffentlichung drohen. Nur Daten, die gespeichert werden, können abfließen.
• Eine Sperre, die niemand gesetzt oder geprüft hat. Ein Bucket ohne Object Lock oder eine Aufbewahrung, die das Backup-Werkzeug nicht setzt, schützt nichts. Prüfen Sie, was Ihr Werkzeug tatsächlich schreibt und ob seine eigene Bereinigung mit der Sperre noch funktioniert.
• Verlust des Kontos oder des Anbieters. Ein Anbieterkonto ist eine Ausfalldomäne; siehe die 3-2-1-Regel.

Was ergänzen Offline-Kopien und Air Gaps?

Das NIST beschreibt einen Air Gap als Schnittstelle zwischen zwei Systemen, die nicht physisch verbunden sind, wobei jede logische Verbindung nicht automatisiert ist. Für Backups heißt das eine Kopie, die getrennt ist, wenn niemand auf sie schreibt. Das BSI verlangt in seinem Maßnahmenkatalog zumindest je eine Kopie, die offline gesichert wird: Sie wird nach dem Backup von den anderen Systemen getrennt und ist so vor Remote-Angriffen geschützt. Als Beispiele nennt es getrennte Tapes, ein getrenntes Archiv, für das physischer Zugriff nötig ist, oder einen komplett vom eigenen Netz getrennten Cloud-Speicher. Es rät außerdem, diese Trennung regelmäßig zu prüfen, etwa indem ein (Domänen-)Administrierender testweise versucht, auf die getrennten Kopien zuzugreifen, was nicht gelingen sollte, und Kopien an verschiedenen Orten zu halten. Auch der Leitfaden der CISA verlangt Offline-Backups, verschlüsselt und getestet.

Band ist das klassische Offline-Medium. Das LTO Program nennt einmal beschreibbare Kassetten ab LTO-3 und Hardware-Verschlüsselung ab LTO-4 und beschreibt Bänder, die offline genommen und weggebracht werden, als physisch von Angreifern getrennt. Der Preis ist der Aufwand: Jemand muss die Medien rotieren, die Offline-Kopie ist so alt wie die letzte Rotation, und eine Wiederherstellung vom Band ist langsamer als von Platte.

Welche Maßnahme hilft gegen welchen Angriff?

Was ist ein sinnvolles Minimum für ein kleines Unternehmen?

1. Folgen Sie der Idee von 3-2-1-1-0: mindestens eine Kopie, die unveränderlich oder offline ist, und ein Restore, der ausprobiert wurde.
2. Geben Sie dem Backup-Speicher Zugangsdaten, die sich von den Administratorkonten der geschützten Systeme unterscheiden.
3. Sorgen Sie dafür, dass jemand erfährt, wenn ein Backup fehlschlägt oder überfällig ist, denn ein gelöschtes Backup sieht aus wie ein fehlendes.
4. Behalten Sie Sicherungsstände lange genug, um vor den Zeitpunkt zurückzureichen, zu dem ein Eindringling im Netz gewesen sein könnte, und prüfen Sie, was ein Restore zurückbringt, bevor Sie es wieder anschließen.
5. Wählen Sie die Maßnahme, die Sie betreiben können. Eine Offline-Platte, die jede Woche rotiert und getestet wird, schlägt einen Object-Lock-Bucket, den niemand geprüft hat.

So macht es Restow

Seit 0.4.0 kann Restow Backup-Daten selbst sperren, und es beurteilt jeden neuen Sicherungsstand auf Anzeichen von Ransomware. Das ist, was das tut, was es Ihnen überlässt und wo es endet. Das Produkt sagt dazu „unveränderbar“, Sie finden die Funktion also unter „Unveränderbare Backups“.

Unveränderbare Backups, je Repository

Jedes Repository hat eine eigene Einstellung für Unveränderbarkeit. Sie ist aus, bis ein Administrator sie unter Repositories einschaltet („Unveränderbarkeit ändern“), und vorher ist nichts gesperrt.

• S3 mit Object Lock, im Compliance- oder Governance-Modus, für 1 bis 3650 Tage. Das Einschalten prüft den Bucket und lehnt einen ohne Object Lock ab. Object Lock lässt sich nur beim Anlegen eines Buckets einschalten, ein bestehender Bucket ohne es lässt sich also nicht nutzen. Jedes gesperrte Objekt wird mit einem Aufbewahrungsende von Zeitraum plus 7 Tagen geschrieben, und der tägliche Aufbewahrungslauf verlängert jedes noch verwendete Objekt, sobald die letzte Verlängerung 6 Tage alt ist, weil die Deduplizierung einen neuen Sicherungsstand auf Packs aufsetzen lässt, die vor Monaten geschrieben wurden. Restow sendet nie den Governance-Bypass-Header. Trifft die Aufbewahrung, die Garbage Collection oder ein Prune auf ein Objekt, das noch gesperrt ist, zählt die Löschung als „noch nicht“: Der Sicherungsstand bleibt sichtbar und wiederherstellbar, und der Platz kommt zurück, sobald die Sperre abgelaufen ist.
• Ein Verzeichnis (das Docker-Volume, ein NFS-Netzlaufwerk) bekommt nur eine Löschverzögerung („Löschverzögerung (nicht unveränderbar)“): Restows eigener Code lehnt ab, eine Backup-Datei vor Ablauf des Zeitraums zu löschen oder zu überschreiben. Das schützt vor Missbrauch von Restow, etwa einem gestohlenen Administratorkonto oder einer Aufbewahrungsrichtlinie, die verkürzt wurde, um Sicherungsstände zu löschen. Es schützt nicht vor jemandem mit Zugriff auf den Server oder die Freigabe, und die Oberfläche sagt, dass es keine Unveränderbarkeit ist.

Gesperrt sind die Packs, die festgeschriebenen Manifeste und die umhüllten Schlüssel des Chunk-Stores (Microsoft 365 einschließlich SharePoint, IMAP, Proxmox-VE-VM-Datenträger und der Nachrichteninhalt des Archivs) und die Objekte data, snapshots, keys und config jedes restic-Repositorys (Server und Clients, Freigaben, Proxmox-VE-Container). Nicht gesperrt sind Checkpoints, Staging, Exporte und Downloads sowie restics eigene Dateien locks und index; restic repair index baut den Index aus den gesperrten Packs neu auf. Die Datensätze der Archivelemente behalten ihre eigene Aufbewahrung, wie bisher. Ein Sicherungsstand zeigt „Unveränderbar bis“ mit einem Datum, grün nur, wenn der Speicher selbst eine Compliance-Sperre gemeldet hat. Den Schutz zu erhöhen steht jedem offen, der das Repository konfigurieren darf; ihn zu senken (weniger Tage, ein schwächerer Modus, aus) ist dem Provider-Inhaber mit jüngerer Anmeldung vorbehalten, gilt nur für Daten, die ab dann geschrieben werden, und steht im Audit-Log.

Was es nicht abdeckt

• Wer Restow kontrolliert, kann neue Sperren und die Verlängerung anhalten. Was gesperrt ist, bleibt bis zu seinem Datum gesperrt, aber neue Backups danach sind nicht geschützt.
• Eine Governance-Sperre hebt jedes Konto mit s3:BypassGovernanceRetention auf. Geben Sie dem Schlüssel von Restow eine Richtlinie ohne sie und ohne s3:PutBucketObjectLockConfiguration und s3:PutBucketVersioning, oder nutzen Sie den Compliance-Modus.
• Löschmarker und neuere Versionen können gesperrte Daten verstecken. Die gesperrten Versionen bleiben und lassen sich zurückholen, aber das ist Arbeit.
• Der Hauptschlüssel liegt nicht im Bucket. Bewahren Sie eine Kopie getrennt vom Server auf, sonst lassen sich gesperrte Daten nicht öffnen.
• Das Standard-Repository der Installation lässt sich nicht unveränderbar machen: Geben Sie dem Mandanten ein eigenes Repository oder eine unveränderbare Kopie. Ein Mandant, dessen Aufbewahrungsplan gelöscht wurde, wird nicht verlängert, und der Platz gelöschter Daten kommt erst zurück, wenn ihre Sperre abgelaufen ist.
• Tests. Unveränderbare Backups wurden gegen einen simulierten S3-Dienst mit Object Lock getestet, noch nicht gegen einen echten S3-Dienst mit Object Lock und nicht gegen einen echten Hetzner-Bucket. Wir haben Restow nicht gegen einen Bucket mit einer Standard-Aufbewahrung von Object Lock getestet; behandeln Sie diese Kombination als ungetestet.

Das ganze Bild, auch die Berechtigungen, die der Zugriffsschlüssel braucht, steht auf der Speicherseite.

Ransomware-Erkennung

Jeder neue Sicherungsstand wird aus Daten, die das Backup ohnehin hat, auf Anzeichen von Ransomware beurteilt: Menge der Änderungen im Vergleich zur eigenen Vorgeschichte des Objekts, Löschungen, umbenannte Endungen, bekannte Ransomware-Namen, Stichprobendateien, die verschlüsselt wirken, und Daten, die sich weder komprimieren noch deduplizieren lassen. Ein verdächtiger Sicherungsstand bekommt ein rotes Kennzeichen („Verdächtig“), die Wiederherstellungsansichten bieten den neuesten ohne Befund an, ein Alarm geht einmal je Angriff raus, und die Aufbewahrung dieses Objekts wird angehalten („Aufbewahrung angehalten“), bis ein Administrator den Befund als Fehlalarm markiert oder die Aufbewahrung freigibt, damit die sauberen älteren Sicherungsstände nicht gelöscht werden, während verschlüsselte sich anhäufen. Es ist ein Frühwarnsystem, kein Virenscanner; ein Sicherungsstand ohne Befund beweist nichts; und es wurde mit simulierten Angriffen getestet, nicht mit echter Ransomware. Siehe Ransomware-Erkennung.

Was Restow außerdem tut

• Append-only-Agenten für Server und Clients. Der Agent kann Backups hinzufügen, sie aber nie löschen oder überschreiben. Der Restow-Server erzwingt das, und Aufbewahrung und Bereinigung laufen nur auf dem Server. Der Agent hält nie die Zugangsdaten des Speichers; ein gestohlenes Agent-Geheimnis würde erlauben, neue Backups in das Repository dieses Rechners zu schreiben und es zu lesen, aber nichts zu löschen. Knoten von Proxmox VE (eine Preview) können Backups ihres eigenen Clusters lesen und hinzufügen, aber nicht löschen.
• Verschlüsselung. Jeder Chunk wird vor dem Schreiben mit AES-256-GCM verschlüsselt, mit einem eigenen Schlüssel je Mandant. Das schützt die Vertraulichkeit; das Löschen verhindert es nicht.
• Eine zweite Kopie unter getrennten Zugangsdaten. Jedes Repository hat eigene Zugriffsschlüssel, und ein Kopie-Repository kann bei einem anderen Anbieter liegen, mit eigener Einstellung für Unveränderbarkeit. Eine Kopie deckt Mail, Kalender, Kontakte, OneDrive, SharePoint, IMAP und VM-Daten von Proxmox VE ab; Server, Clients, Freigaben und Container von Proxmox VE bleiben im primären Repository, bei ihnen muss also das primäre das unveränderbare sein. Der Restow-Server hält die Zugangsdaten jedes Repositorys und führt die Aufbewahrung aus, wer diesen Server übernimmt, erreicht also beide Kopien. Schützen Sie den Server und den Hauptschlüssel entsprechend.
• Erkennung. Eine wöchentliche Restore-Prüfung liest eine Stichprobe jedes Backups zurück und vergleicht sie mit den aufgezeichneten Prüfsummen, sodass beschädigte oder unlesbare Daten auffallen. Die Speicherprüfung liest jede Woche eine Stichprobe und jeden Monat jedes gespeicherte Pack. Lesezugriffe und Wiederherstellungen werden in ein Audit-Log mit Hash-Kette geschrieben, und Meldungen decken fehlgeschlagene und überfällige Backups ab („Sicherung überfällig“).

Was Restow Ihnen überlässt

Restow hat keine Funktion, Medien zu trennen oder zu rotieren; eine Offline-Kopie muss also außerhalb von Restow entstehen, und Sie sollten einen Restore daraus testen, Schlüssel eingeschlossen. Es kann nicht erkennen, ob Ihr Kopie-Repository mit dem primären eine Ausfalldomäne teilt; einen anderen Anbieter oder Standort zu wählen, ist Ihre Entscheidung, ebenso die Wahl der Sperrfrist. Siehe Verschlüsselung und Schlüsselverwaltung, Server- und Client-Backup und Speicher.

Häufig gestellte Fragen

Quellen

Gelesen am 16. Oktober 2026.

1. BSI: Maßnahmenkatalog Ransomware, Arbeitspapier, Version 1.0 (23. Februar 2022), Kapitel 2 Backups. Mindestens eine Offline-Kopie, regelmäßige Prüfung, dass die Trennung hält, Kopien an verschiedenen Orten, und wogegen Backups nicht schützen
2. BSI: Top 10 Ransomware-Maßnahmen, Backups, Datensicherungskonzept und zentrale Datenhaltung. Ein Backup als wichtigste vorbeugende Maßnahme, Offline-Backups und Restore-Tests
3. CISA: #StopRansomware Guide, Version 3.0 (Oktober 2023, englisch). Teil 1: Offline-, verschlüsselte und getestete Backups; Ransomware-Akteure versuchen, erreichbare Backups zu löschen oder zu verschlüsseln; Löschschutz oder Object Lock
4. MITRE ATT&CK: T1490 Inhibit System Recovery (englisch). Wie Angreifer Schattenkopien, Backup-Kataloge, Online-Backups und Cloud-Snapshots löschen
5. MITRE ATT&CK: T1485 Data Destruction (englisch). Backups außerhalb des betroffenen Systems und Multi-Faktor-Authentifizierung für das Löschen in Cloud-Speicher
6. Amazon S3 Benutzerhandbuch: Sperren von Objekten mit Object Lock. WORM-Modell, Aufbewahrungszeiträume, rechtliche Aufbewahrungsfristen (Legal Hold), Governance- und Compliance-Modus, Versionierung
7. Hetzner Docs: Object Lock: Retention. Ein S3-kompatibler Dienst mit Object Lock: Es muss beim Erstellen des Buckets aktiviert werden
8. SNIA Dictionary (Stand 28. April 2026, englisch): Write Once Read Many. WORM als Speicher, der Geschriebenes unveränderlich bewahrt
9. NIST-Glossar: air gap (englisch). Definition eines Air Gap
10. LTO Program: Benefits of LTO (englisch). WORM-Kassetten ab LTO-3, Hardware-Verschlüsselung ab LTO-4, Bänder offline genommen

Verwandte Artikel

• Die 3-2-1-Backup-Regel Drei Kopien, zwei Arten von Speicher, eine Kopie an einem anderen Ort, dazu die Erweiterung um eine unveränderliche Kopie und null Fehler. Mit Microsoft-365-Beispiel.
• Backup-Speicher wählen Lokale Platte, NAS und NFS, S3-kompatibler Objektspeicher, Band und Cloud-Archivklassen im Vergleich bei Kosten, Haltbarkeit, Unveränderlichkeit und Restore-Tempo.
• DSGVO und Backups Was Artikel 17 von einem Backup verlangt, was der EDSA und deutsche Aufsichtsbehörden sagen, warum Backups üblicherweise auslaufen und wo Sperren dem Löschverlangen begegnen. Keine Rechtsberatung.
• Backup und Archivierung Wiederherstellung gegen Aufbewahrung, eine Vergleichstabelle, Archivierung oder Journaling, warum ein rotierendes Backup kein Beleg ist, der GoBD-Blick für Unternehmen in Deutschland und wie man beides betreibt.
• Backup-Glossar Nachschlagewerk Kurze Definitionen zu Backup, Restore, Aufbewahrung, Speicher und DSGVO, von 3-2-1-Regel bis WORM, mit Links zu den Artikeln und Funktionsseiten.