Immutable Backups mit Veeam, Wasabi oder S3 Object Lock einrichten

Warum normale Backups gegen Ransomware nicht mehr reichen

Die Zeiten, in denen Ransomware einfach Dateien auf dem Desktop verschlüsselt hat, sind vorbei. Moderne Ransomware-Gruppen operieren nach einem methodischen Playbook: Sie verschaffen sich Zugang zum Netzwerk, häufig über Phishing oder kompromittierte VPN-Zugänge. Dann bewegen sie sich wochen- oder monatelang unauffällig durch die Infrastruktur, verschaffen sich Administratorrechte und kartieren die Umgebung. Bevor sie die Verschlüsselung starten, suchen und zerstören sie gezielt die Backups.

Das Muster ist gut dokumentiert. Ransomware-Familien wie LockBit, BlackCat und Royal enthalten Module, die automatisch nach Backup-Software suchen (Veeam, Acronis, Veritas), Backup-Dienste stoppen, Backup-Repositories löschen und Shadow Copies entfernen. Wenn der Angreifer Administratorrechte hat und dein Backup-System über dasselbe Active Directory erreichbar ist, sind deine Backups genauso gefährdet wie deine Produktionsdaten.

Immutable Backups lösen dieses Problem, weil sie selbst für einen Angreifer mit vollständigen Administratorrechten nicht löschbar oder veränderbar sind. Die Unveränderlichkeit wird nicht durch Zugriffsrechte erzwungen (die ein Admin umgehen kann), sondern durch technische Mechanismen, die für den definierten Zeitraum nicht aufhebbar sind.

Was "immutable" technisch bedeutet

Immutability kann auf verschiedenen Ebenen implementiert werden, und nicht alle Implementierungen sind gleich sicher.

Object Lock auf Speicherebene

S3 Object Lock (und kompatible Implementierungen bei anderen Anbietern) verhindert das Löschen und Überschreiben von Objekten für einen definierten Zeitraum. Es gibt zwei Modi:

Governance Mode: Objekte sind geschützt, aber Benutzer mit speziellen Berechtigungen (s3:BypassGovernanceRetention) können den Schutz aufheben. Das ist nützlich für Testzwecke, bietet aber keinen vollständigen Schutz gegen einen Angreifer mit Root-Zugriff auf das AWS-Konto.

Compliance Mode: Objekte können von niemandem gelöscht oder verändert werden, bis die Retention-Periode abgelaufen ist. Nicht einmal der Root-Account des AWS-Kontos kann den Schutz aufheben. Das ist die sicherste Variante, aber auch die unflexibelste. Wenn du eine falsche Retention-Periode setzt, musst du warten, bis sie abläuft.

Immutable Flag auf Dateisystemebene

Linux-Dateisysteme (ext4, XFS) unterstützen das immutable-Attribut über chattr +i. Dateien mit diesem Attribut können nicht verändert, gelöscht, umbenannt oder verlinkt werden, auch nicht von root. Das Attribut kann nur von root mit chattr -i wieder entfernt werden, was bedeutet, dass ein Angreifer mit Root-Zugriff den Schutz aufheben kann.

Veeam nutzt dieses Konzept im Hardened Repository mit einer Absicherung: Der Veeam-Dienst, der die Backups schreibt, hat keinen Root-Zugriff. Er setzt das immutable-Flag über einen separaten Prozess, und der einzige Weg, das Flag zu entfernen, ist ein lokaler Root-Zugang zum Linux-Server (der zusätzlich abgesichert wird, z.B. durch deaktiviertes SSH-Root-Login).

WORM-Storage auf Hardwareebene

Spezielle Storage-Systeme wie NetApp SnapLock oder dedizierte WORM-Appliances implementieren Unveränderlichkeit auf Hardwareebene. Das ist die sicherste, aber auch teuerste Option und für die meisten mittelständischen Unternehmen überdimensioniert.

Option 1: Veeam Hardened Linux Repository

Das Veeam Hardened Repository ist die populärste Lösung für Immutable Backups im Mittelstand. Es basiert auf einem gehärteten Linux-Server, der als Backup-Ziel dient.

So funktioniert es

Ein dedizierter Linux-Server (Ubuntu oder RHEL/Rocky) wird minimal installiert und gehärtet. Veeam installiert auf dem Server einen Transport-Dienst, der Backup-Daten empfängt und schreibt. Für jede geschriebene Backup-Datei wird automatisch das immutable-Attribut gesetzt. Die Retention-Periode wird in Veeam konfiguriert. Erst nach Ablauf der Periode darf die Datei gelöscht werden.

Der entscheidende Sicherheitsmechanismus ist die Trennung der Berechtigungen. Der Veeam-Dienst auf dem Linux-Server läuft unter einem unprivilegierten Benutzer und hat keinen Root-Zugriff. Er kann Dateien schreiben und das immutable-Flag setzen (über einen SUID-Helper), aber er kann das Flag nicht entfernen. SSH-Root-Login ist deaktiviert. Der einzige Weg, das immutable-Flag zu entfernen, ist ein lokaler Konsolenzugriff mit Root-Passwort.

Einrichtung Schritt für Schritt

1. Linux-Server vorbereiten: Installiere Ubuntu Server 22.04 LTS (oder neuer) mit minimaler Konfiguration. Kein Desktop, keine unnötigen Dienste. Erstelle einen dedizierten Benutzer für Veeam (z.B. veeamrepo) und konfiguriere SSH-Key-Authentifizierung für diesen Benutzer. Deaktiviere SSH-Root-Login und Passwort-Authentifizierung.

2. Storage bereitstellen: Richte ein XFS-Dateisystem für die Backup-Daten ein. XFS ist empfohlen, weil es das immutable-Attribut zuverlässig unterstützt und performant mit großen Dateien umgeht. Formatiere das Volume und mounte es dauerhaft (z.B. unter /mnt/veeam-repo).

3. In Veeam als Repository hinzufügen: In der Veeam-Konsole fügst du den Linux-Server als "Direct attached storage" oder "Linux" Repository hinzu. Aktiviere die Option "Make recent backups immutable for X days". Veeam empfiehlt mindestens 7 Tage, sinnvoller sind 14 bis 30 Tage.

4. Server härten: Konfiguriere eine lokale Firewall (iptables/nftables), die nur den Veeam-Traffic auf den benötigten Ports zulässt. Richte automatische Sicherheitsupdates ein (unattended-upgrades). Beschränke den physischen Zugang zum Server.

Fallstricke und Best Practices

Der Veeam-Service-Account darf keine sudo-Rechte haben. Das klingt offensichtlich, wird aber beim Setup manchmal übersehen, weil die automatische Konfiguration über SSH initial erhöhte Rechte braucht. Nach der Einrichtung müssen diese entfernt werden.

Die Immutability-Periode muss länger sein als deine Aufbewahrungspolitik für die ältesten Wiederherstellungspunkte. Wenn du 14 Tage aufbewahren willst und die Immutability auf 7 Tage setzt, sind die Backups ab Tag 8 nicht mehr geschützt.

Plane genug Speicherplatz ein. Immutable Backups können nicht vorzeitig gelöscht werden, um Platz zu schaffen. Wenn dein Repository vollläuft und die ältesten Backups noch immutable sind, schlagen neue Backup-Jobs fehl.

Option 2: Wasabi Hot Cloud Storage mit Object Lock

Wasabi hat sich als kosteneffiziente Alternative zu AWS S3 für Backup-Zwecke etabliert. Der große Vorteil gegenüber AWS: Wasabi berechnet keine Egress-Gebühren, was für Backup-Szenarien entscheidend ist. Du zahlst für die gespeicherte Datenmenge, nicht für den Download bei einem Restore.

Preismodell

Wasabi berechnet derzeit 6,99 USD pro TB pro Monat (Stand März 2026), ohne Egress-Gebühren und ohne API-Request-Gebühren. Zum Vergleich: AWS S3 Standard kostet 23 USD pro TB pro Monat plus Egress-Gebühren von 90 USD pro TB. Für ein Backup-Volumen von 5 TB zahlst du bei Wasabi rund 35 USD pro Monat, bei AWS S3 Standard rund 115 USD pro Monat (ohne Egress).

Wasabi hat eine Minimum-Speicherdauer von 90 Tagen. Wenn du ein Objekt nach 30 Tagen löschst, zahlst du trotzdem für 90 Tage. Das ist für Backup-Szenarien mit typischen Retention-Perioden von 30 bis 90 Tagen unproblematisch.

Object Lock bei Wasabi einrichten

1. Bucket erstellen mit Object Lock: Object Lock muss beim Erstellen des Buckets aktiviert werden. Es kann nachträglich nicht hinzugefügt werden. In der Wasabi-Konsole oder per CLI: aws s3api create-bucket --bucket mein-backup-bucket --object-lock-enabled-for-bucket --endpoint-url https://s3.eu-central-1.wasabisys.com

2. Default Retention konfigurieren: Setze eine Standard-Retention für den Bucket im Compliance Mode: aws s3api put-object-lock-configuration --bucket mein-backup-bucket --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}' --endpoint-url https://s3.eu-central-1.wasabisys.com

3. IAM-Benutzer erstellen: Erstelle einen dedizierten Benutzer für die Backup-Software mit minimalen Rechten: PutObject, GetObject, ListBucket. Vergib ausdrücklich kein DeleteObject und kein s3:BypassGovernanceRetention.

4. Backup-Software konfigurieren: Konfiguriere Veeam (Scale-out Repository mit Capacity Tier), Restic, BorgBackup oder ein anderes S3-kompatibles Tool mit dem Wasabi-Endpoint und den Zugangsdaten des dedizierten Benutzers.

Wasabi-spezifische Hinweise

Wasabi unterstützt sowohl Governance als auch Compliance Mode. Verwende für Backups ausschließlich Compliance Mode, weil Governance Mode von einem Benutzer mit entsprechenden Rechten umgangen werden kann.

Object Versioning wird automatisch mit Object Lock aktiviert. Das bedeutet, dass auch bei einem Überschreibversuch die alte Version erhalten bleibt. Das erhöht den Speicherverbrauch, bietet aber zusätzlichen Schutz.

Wasabi hat Rechenzentren in Europa (Amsterdam, Frankfurt). Für DSGVO-konforme Datenhaltung solltest du einen europäischen Standort wählen.

Option 3: AWS S3 mit Object Lock

AWS S3 ist der Referenzstandard für Object-Lock-Implementierungen. Wenn du bereits AWS nutzt oder die Enterprise-Features von S3 brauchst, ist es die naheliegende Wahl.

S3-Speicherklassen für Backups

Nicht jede S3-Speicherklasse eignet sich gleich gut für Backups. S3 Standard bietet die niedrigste Latenz und schnellste Zugriffe, ist aber die teuerste Option. Für Backups, die du selten abrufen musst, ist das Verschwendung.

S3 Glacier Instant Retrieval ist deutlich günstiger (ca. 4 USD pro TB pro Monat) und bietet Zugriff in Millisekunden. Das ist die beste Option für Backups, die du im Notfall schnell brauchst, aber selten abrufst.

S3 Glacier Flexible Retrieval ist noch günstiger (ca. 3,60 USD pro TB pro Monat), aber der Zugriff dauert Minuten bis Stunden. Geeignet für Langzeit-Archivierung, nicht für operatives DR.

S3 Glacier Deep Archive ist die günstigste Option (ca. 1 USD pro TB pro Monat), aber der Zugriff dauert bis zu 12 Stunden. Nur für regulatorische Langzeitarchivierung sinnvoll.

Alle Speicherklassen unterstützen Object Lock.

Einrichtung

1. Bucket mit Object Lock erstellen: Wie bei Wasabi muss Object Lock beim Erstellen des Buckets aktiviert werden. aws s3api create-bucket --bucket mein-backup-bucket --region eu-central-1 --create-bucket-configuration LocationConstraint=eu-central-1 --object-lock-enabled-for-bucket

2. Lifecycle-Regeln für Speicherklassen-Übergang: Konfiguriere eine Lifecycle-Regel, die Backups nach einer definierten Zeit in eine günstigere Speicherklasse verschiebt: z.B. nach 30 Tagen von S3 Standard nach Glacier Instant Retrieval, nach 90 Tagen nach Glacier Flexible Retrieval.

3. Default Retention im Compliance Mode setzen: aws s3api put-object-lock-configuration --bucket mein-backup-bucket --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

4. IAM-Policy erstellen: Erstelle eine restriktive IAM-Policy, die nur die notwendigen Rechte gewährt. Blockiere explizit DeleteObject und BypassGovernanceRetention.

5. MFA Delete aktivieren: Für zusätzlichen Schutz kannst du MFA Delete aktivieren, was bedeutet, dass Löschoperationen eine Multi-Faktor-Authentifizierung erfordern. Das schützt auch dann, wenn die IAM-Zugangsdaten kompromittiert werden.

Kostenoptimierung bei AWS

Die Egress-Gebühren bei AWS können bei einem Restore erheblich sein. 5 TB aus S3 herunterladen kostet rund 450 USD. Plane diese Kosten in dein DR-Budget ein. Alternativen: AWS Snowball für große Datenmengen (physischer Versand eines Speichergeräts) oder ein lokales Cache-Tier (z.B. über Veeam), das die häufigsten Restore-Anfragen lokal bedient.

Weitere Optionen für den Mittelstand

Backblaze B2 mit Object Lock

Backblaze B2 unterstützt seit 2022 Object Lock im Governance und Compliance Mode. Die Preise liegen bei 6 USD pro TB pro Monat, ohne Egress-Gebühren für die ersten 3x des gespeicherten Volumens pro Monat (danach 0,01 USD pro GB). Für viele Backup-Szenarien ist der Egress effektiv kostenlos.

Backblaze B2 ist S3-kompatibel und funktioniert mit Veeam, Restic, Duplicati und den meisten anderen Backup-Tools. Die Einrichtung von Object Lock funktioniert analog zu AWS S3.

Linux-Server mit XFS und immutable-Attribut (ohne Veeam)

Wenn du kein Veeam nutzt, kannst du Immutability auch manuell auf einem Linux-Server implementieren. Der Backup-Prozess (z.B. Restic oder BorgBackup) schreibt die Daten auf ein XFS-Dateisystem. Ein separates Skript setzt anschließend das immutable-Attribut mit chattr +i auf die geschriebenen Dateien. Ein Cronjob entfernt das Attribut nach Ablauf der Retention-Periode.

Diese Lösung ist kostenlos, erfordert aber mehr manuelles Setup und Wartung. Die Sicherheit hängt davon ab, wie gut der Linux-Server gehärtet ist. Wenn ein Angreifer Root-Zugriff auf den Server erlangt, kann er das immutable-Attribut entfernen.

Retention-Perioden richtig wählen

Die Wahl der Retention-Periode ist ein Balanceakt. Zu kurz: Das Backup ist nicht mehr geschützt, bevor du einen Angriff bemerkst. Zu lang: Du zahlst für Speicher, den du nicht brauchst, und kannst im Compliance Mode nicht aufräumen.

Orientierungswerte

Die durchschnittliche Verweildauer eines Angreifers im Netzwerk (Dwell Time) liegt laut aktuellen Studien bei 10 bis 21 Tagen. Das bedeutet: Ein Angreifer ist im Schnitt zwei bis drei Wochen in deinem Netzwerk, bevor er die Ransomware aktiviert. Deine Immutability-Periode sollte mindestens so lang sein wie die erwartete Dwell Time plus die Zeit, die du für die Erkennung und Wiederherstellung brauchst.

Eine pragmatische Empfehlung: 30 Tage Immutability für operative Backups und 90 Tage für die monatlichen oder quartalsweisen Full-Backups, orientiert am 3-2-1-1-0-Prinzip. Damit bist du gegen die typische Dwell Time und gegen verzögerte Erkennung abgesichert.

Kosten kalkulieren

Immutable Backups können nicht vorzeitig gelöscht werden. Kalkuliere dein Speichervolumen konservativ. Wenn du täglich 50 GB inkrementelle Backups schreibst und die Immutability auf 30 Tage setzt, brauchst du mindestens 1,5 TB Speicher allein für die inkrementellen Daten der letzten 30 Tage. Dazu kommen die Full-Backups.

Rechne mit einem Puffer von 30 bis 50 % für unerwartetes Datenwachstum. Wenn dein immutabler Speicher vollläuft, können keine neuen Backups geschrieben werden, und das ist ein ernstes Problem.

Immutable Backups testen

Immutability schützt die Integrität der gespeicherten Daten, aber nicht deren Qualität. Ein immutabler Backup, der fehlerhafte Daten enthält, bleibt fehlerhaft. Deshalb sind Restore-Tests, idealerweise als Bare-Metal-Recovery-Test, auch bei immutablen Backups unverzichtbar.

Teste zusätzlich die Immutability selbst: Versuche, ein immutablees Backup zu löschen oder zu verändern, und überprüfe, ob die Aktion korrekt blockiert wird. Das klingt trivial, aber Fehlkonfigurationen kommen vor. Ein Object-Lock-Bucket, bei dem versehentlich Governance statt Compliance Mode konfiguriert ist, bietet weniger Schutz als angenommen.

Dokumentiere die Tests inklusive des Nachweises, dass die Immutability funktioniert – in ISMS Lite lassen sich Backup-Strategien, Retention-Perioden und Testergebnisse zentral nachweisen. Ein Auditor wird nicht nur fragen, ob deine Backups immutable sind, sondern ob du das auch überprüft hast.

Integration in die Backup-Strategie

Immutable Backups sind ein Baustein deiner Backup-Strategie, nicht die gesamte Strategie. Sie adressieren eine spezifische Bedrohung (Manipulation oder Löschung von Backups durch Angreifer oder Insider), ersetzen aber nicht die anderen Aspekte wie Backup-Intervall (RPO), Restore-Geschwindigkeit (RTO), externe Aufbewahrung und regelmäßige Tests.

Die ideale Kombination für ein mittelständisches Unternehmen sieht so aus: Lokale Backups auf einem Veeam Hardened Repository für schnelle Restores (Minuten bis wenige Stunden) und Cloud-Backups auf Wasabi oder S3 mit Object Lock für externen Schutz und Langzeit-Immutability. Beide Kopien sind immutable, beide werden regelmäßig getestet.

Weiterführende Artikel

• Datensicherung nach BSI: Das 3-2-1-1-0-Prinzip in der Praxis
• Disaster Recovery Plan erstellen: Vom Notfall zurück zum Normalbetrieb
• RPO und RTO richtig definieren: So findest du die passenden Werte
• Bare-Metal-Recovery testen: Vom Totalausfall zur laufenden Maschine
• Ransomware-Angriff: Sofortmaßnahmen, Kommunikation und Wiederherstellung