Ransomware-sichere Backups: Unveränderlichkeit richtig umsetzen

Wer heute Backups plant, plant gegen einen Angreifer, nicht gegen einen Festplattendefekt. Das ist der wesentliche Unterschied zur Datensicherung von vor zehn Jahren – und er verändert die Anforderungen grundlegend.

Eine defekte Platte greift deine Sicherungen nicht an. Ransomware tut genau das, und zwar zuerst.

Wie der Angriff tatsächlich abläuft

Die verbreitete Vorstellung – „Trojaner kommt rein, verschlüsselt alles, Lösegeld wird gefordert“ – ist unvollständig und führt zu falschen Schutzmaßnahmen. Realistisch läuft es in Phasen:

1. Zugang       Phishing, offengelegter Dienst, gestohlene Zugangsdaten
2. Ausbreitung  Rechteausweitung, Bewegung im Netz         <- dauert oft Wochen
3. Aufklaerung  Wo liegen die Backups? Welche Zugaenge gibt es?
4. Sabotage     Backups loeschen, Aufbewahrung verkuerzen, Jobs deaktivieren
5. Exfiltration Daten abziehen (fuer die zweite Erpressungsstufe)
6. Verschluesselung  erst jetzt - wenn die Rueckwege weg sind

Zwei Konsequenzen daraus, die den Rest dieses Artikels bestimmen:

Erstens: Phase 4 kommt vor Phase 6. Wenn du die Verschlüsselung bemerkst, sind die Sicherungen bereits behandelt worden. Ein Backup-Ziel, das vom Produktivsystem aus löschbar ist, ist zum Zeitpunkt des Schadens wertlos.

Zweitens: Zwischen Phase 1 und Phase 6 liegt Zeit. Oft Wochen. Wenn deine Aufbewahrung kürzer ist als diese Zeitspanne, enthalten alle vorhandenen Stände bereits den kompromittierten Zustand. Du kannst dann zwar wiederherstellen – aber du stellst den Angreifer mit wieder her.

Die drei Schutzebenen

Ebene 1: Rechtetrennung

Der wirksamste Einzelschritt und derjenige, der nichts kostet.

Grundregel: Das gesicherte System darf seine eigenen Sicherungen nicht löschen können.

Praktisch heißt das:

Umgebung	Umsetzung
PBS	Client-Token mit Rolle DatastoreBackup – schreiben und lesen, nicht löschen. Prune und GC laufen auf dem PBS selbst.
restic auf S3	Anwendungsschlüssel ohne DeleteObject. Der Aufräumlauf nutzt einen zweiten Schlüssel, der nicht auf dem Quellsystem liegt.
Borg über SSH	command="borg serve --append-only" in der authorized_keys des Backup-Ziels. Der Client kann anhängen, nicht entfernen.

Diese Trennung hat einen Nebeneffekt, den man kennen muss: Das Aufräumen wird zu einem eigenen Vorgang. Es läuft nicht mehr nebenbei mit dem Backup-Job, sondern auf dem Ziel oder mit getrennten Zugangsdaten. Wer das nicht einplant, wundert sich über einen vollen Speicher – siehe Backup-Aufbewahrung planen.

Was ausdrücklich nicht genügt: ein SMB- oder NFS-Share, das auf dem Produktivsystem eingehängt ist. Ein eingehängtes Backup-Laufwerk ist für Schadsoftware ein Laufwerk wie jedes andere – und meist das erste Ziel.

Ebene 2: Unveränderlichkeit

Rechtetrennung schützt gegen einen kompromittierten Client. Sie schützt nicht, wenn der Angreifer die Zugangsdaten des Backup-Systems selbst erlangt. Dafür braucht es Unveränderlichkeit: Daten, die technisch nicht löschbar sind, bis eine Frist abläuft – auch nicht durch den Kontoinhaber.

Objekt-Sperre bei S3-kompatiblem Speicher ist die praktikabelste Form. Sie kennt zwei Betriebsarten:

Modus	Bedeutung
Governance	Löschen ist mit besonderen Rechten möglich. Schützt gegen Versehen und gegen einen normalen Angreifer.
Compliance	Löschen ist bis zum Fristende für niemanden möglich – auch nicht für dich.

Compliance ist der echte Schutz und gleichzeitig ein scharfes Werkzeug: Speicherplatz, den du versehentlich mit einer 90-Tage-Sperre belegst, bezahlst du 90 Tage. Beginne mit kurzen Fristen und verlängere, wenn das Verfahren steht.

Wichtig: Die Sperre muss beim Anlegen des Buckets aktiviert werden – nachträglich ist das bei vielen Anbietern nicht möglich.

ZFS-Snapshots auf dem Backup-Server sind eine gute Ergänzung. Das Quellsystem schreibt in den Datastore, der Backup-Server erzeugt davon unabhängig Snapshots. Wer den Datastore-Inhalt löscht, entfernt die Snapshots nicht mit.

Offline-Kopie. Die konsequenteste Variante: ein Datenträger, der physisch nicht angeschlossen ist. Rotierende Wechselplatten oder Band. Nicht elegant, aber gegen Netzwerkangriffe unschlagbar – der Angreifer kann nichts erreichen, was nicht angeschlossen ist. Der Schwachpunkt ist menschlich: Die Rotation muss tatsächlich stattfinden.

Ebene 3: Aufbewahrungsdauer

Die Ebene, die am häufigsten übersehen wird, obwohl sie nichts kostet.

Wenn zwischen Kompromittierung und Verschlüsselung Wochen liegen, muss deine Aufbewahrung diese Zeitspanne überdecken. Sonst sind alle Stände befallen.

Wenn die Verweildauer im schlechten Fall 6 Wochen betraegt,
darf die Aufbewahrung nicht bei 14 Tagen enden.

Sinnvoll: taegliche Staende fuer 2 Wochen
        + woechentliche fuer 3 Monate
        + monatliche fuer 12 Monate

Die monatlichen Stände sind hier nicht für die Steuerprüfung da, sondern als Rückfallebene für genau diesen Fall. Herleitung in Backup-Aufbewahrung planen.

Zugänge absichern

Die Ebenen oben nützen wenig, wenn der Angreifer sich am Backup-System anmelden kann.

• Eigenes Konto beim Anbieter, nicht dasselbe wie für den restlichen Betrieb.
• Zwei-Faktor-Authentifizierung an der Verwaltungsoberfläche – ausnahmslos.
• Getrennte Zugangsdaten für Sicherung, Aufräumen und Wiederherstellung.
• Backup-System nicht in der Domäne. Ein PBS, der gegen dasselbe Verzeichnis authentifiziert wie alles andere, fällt mit diesem Verzeichnis. Lokale Konten sind hier die richtige Wahl.
• Verwaltungsoberfläche nicht öffentlich erreichbar. Zugang über VPN, nicht über eine Portweiterleitung.
• Zugangsdaten nicht ausschließlich digital. Wenn der Passwortmanager auf dem ausgefallenen System lief, hilft er nicht mehr. Ein versiegelter Ausdruck an einem sicheren Ort ist altmodisch und funktioniert.

Erkennen, dass etwas nicht stimmt

Unveränderlichkeit hilft, wenn der Angriff bereits läuft. Besser ist, ihn vorher zu bemerken. Zwei Signale kommen ohne Zusatzsoftware aus:

Ungewöhnliches Datenwachstum. Verschlüsselte Dateien lassen sich nicht deduplizieren. Wenn ein Sicherungslauf plötzlich ein Vielfaches der üblichen Datenmenge überträgt, ist das ein starkes Signal – oft das erste. Die Werkzeuge zeigen die übertragene Menge pro Lauf an; sie zu überwachen kostet nichts.

Fehlgeschlagene oder deaktivierte Jobs. Ein Backup-Job, der ohne Ankündigung nicht mehr läuft, ist verdächtig. Beides gehört überwacht: Backup-Monitoring.

Der Test, der zählt

Ein unveränderliches Backup ist nur dann etwas wert, wenn du daraus wiederherstellen kannst. Der passende Test ist Stufe 4 aus Restore testen: Wiederaufbau ausschließlich aus der Offsite-Kopie, ohne Zugriff auf die lokale Infrastruktur.

Zusätzlich zu prüfen:

• Lässt sich ein gesperrtes Objekt tatsächlich nicht löschen? Einmal ausprobieren.
• Kommst du an die Daten heran, wenn die Verwaltungsoberfläche des Backup-Systems nicht verfügbar ist?
• Ist der Verschlüsselungsschlüssel unabhängig erreichbar?

Checkliste

• Das gesicherte System hat keine Löschrechte auf dem Backup-Ziel
• Kein Backup-Speicher ist dauerhaft auf dem Produktivsystem eingehängt
• Mindestens eine Kopie ist unveränderlich oder offline
• Objekt-Sperre wurde beim Anlegen des Buckets aktiviert
• Die Sperrfrist überdeckt eine realistische Verweildauer
• Die Aufbewahrung reicht über Wochen, nicht nur über Tage
• Das Backup-System nutzt eigene, nicht domänengebundene Konten
• Zwei-Faktor-Authentifizierung am Anbieterkonto aktiv
• Zugangsdaten sind auch ohne die Produktivumgebung erreichbar
• Übertragene Datenmenge pro Lauf wird beobachtet
• Ein Restore ausschließlich aus der unveränderlichen Kopie wurde durchgeführt

Weiter im Cluster

• 3-2-1-Backup-Strategie – die „1“ in 3-2-1-1-0
• Offsite-Backup – wo Objekt-Sperren eingerichtet werden
• Backup-Aufbewahrung planen – warum die Dauer Schutzmaßnahme ist
• Backup-Verschlüsselung – schützt gegen Datenabfluss, nicht gegen Löschung
• Restore testen – der Nachweis
• Typische Backup-Fehler