# Immutable Backups: Der ultimative Schutz gegen Ransomware

TL;DR / Management Summary Moderne Ransomware greift heute gezielt die Backup-Infrastruktur an, um Restores zu verhindern und das Lösegeld zu erzwingen. Immutable Backups (unveränderliche Sicherungen) nutzen die WORM (Write Once, Read Many) Technologie. Einmal geschrieben, können diese Daten für einen definierten Zeitraum von niemandem – auch nicht vom Admin – gelöscht oder verschlüsselt werden. Ein Senior Admin implementiert Immutability via S3 Object Lock in der Cloud oder Linux Hardened Repositories lokal im RZ.

# 1. Einführung & Das WORM-Prinzip

Die Einbahnstraße für Daten.

Immutability bedeutet, dass die Datei-Attribute auf der Speicherebene so gesetzt werden, dass kein Lösch- oder Schreibbefehl akzeptiert wird.

# 2. Implementierung in der Praxis

Vom Standard-Repo zum Tresor.

# 1. Cloud: S3 Object Lock (AWS / Wasabi)

Beim Erstellen des Buckets muss “Object Lock” aktiviert werden.

# 2. Lokal: Linux Hardened Repository

Veeam und andere nutzen einen gehärteten Linux-Server (z.B. mit XFS).

# 3. Deep Dive: Clock Skew & NTP Attacks

Der Angriff auf die Zeit.

Wenn ein Angreifer die Systemzeit der Firewall/Server um 30 Tage in die Zukunft stellt, “denkt” das System, die Retention sei abgelaufen und löscht die (nun nicht mehr geschützten) Backups.

# 4. Day-2 Operations: Rechtssicheres Löschen

Wenn Daten wirklich weg müssen.

Was ist, wenn Sie aus rechtlichen Gründen (z.B. richterliche Anordnung) Daten löschen müssen, die noch 90 Tage “Immutable” sind?

# 5. Troubleshooting & “War Stories”

Wenn der Speicher nicht leerer wird.

# Top 3 Herausforderungen

  1. Symptom: Der Speicherplatz läuft voll, und Lösch-Befehle werden ignoriert.

    • Ursache: Die Immutability-Periode war zu lang gewählt (z.B. 180 Tage).
    • Lösung: Kaufen Sie mehr Speicher oder reduzieren Sie die Periode für zukünftige Backups. Bestehende Daten sind “eingefroren”.

  2. Symptom: Backup-Job schlägt fehl mit “Permission Denied” beim Überschreiben.

    • Grund: Das Backup-Programm versucht, Metadaten in einer Datei zu ändern, die bereits gesperrt ist.
    • Fix: Nutzen Sie nur Backup-Tools, die explizit für “Immutable Targets” zertifiziert sind (z.B. PBS, Veeam, Rubrik).

  3. Symptom: Performance-Einbruch.

    • Lösung: Immutability hat fast keinen Einfluss auf die Performance, da es nur ein Metadaten-Flag im Filesystem ist.

# “War Story”: Der verhinderte Totalverlust

Ein Kunde wurde Opfer einer gezielten Phishing-Attacke. Der Angreifer erlangte Domain-Admin Rechte und löschte alle virtuellen Maschinen in Proxmox sowie alle Backup-Jobs in der Konsole. Das Ergebnis: Die Daten in Proxmox waren weg. Aber: Da das Unternehmen einen S3-Bucket mit Object Lock (Compliance Mode) nutzte, konnte der Angreifer die physischen Backup-Dateien in der Cloud nicht löschen. Die Rettung: Wir setzten eine neue OPNsense und einen neuen Proxmox-Knoten auf und konnten die Infrastruktur innerhalb von 24 Stunden vollständig aus der Cloud wiederherstellen. Lehre: Immutability ist die einzige Maßnahme, die auch bei einem kompromittierten Admin-Konto funktioniert.

# 6. Monitoring & Reporting

Status der Unveränderlichkeit.

# Immutability Audit

Überwachen Sie via Dashboard:

# 7. Fazit & Empfehlung

Immutable Backups sind der heutige Sicherheits-Standard.

# Anhang: Cheatsheet (AWS CLI Check)

Aufgabe Befehl
Bucket Status prüfen aws s3api get-object-lock-configuration --bucket NAME
Objekt-Sperre sehen aws s3api get-object-retention --bucket NAME --key KEY
Versionierung checken aws s3api get-bucket-versioning --bucket NAME

# Referenzen