Immutability im Backup: warum es 2026 unter NIS2 nicht-verhandelbar ist

Was Immutability technisch bedeutet

Immutable Backup heißt: ein einmal geschriebenes Backup kann für eine definierte Retention-Periode weder geändert noch gelöscht werden, auch nicht durch privilegierte Accounts oder durch den Backup-Admin selbst.

Drei technische Auspragungen sind üblich. WORM (Write Once Read Many) auf Objekt-Storage-Ebene, z.B. S3 Object Lock im Compliance-Modus, Azure Blob Immutability Policy, Google Cloud Storage Bucket Lock. Hardware-Immutability über Tape oder Object-Based-Appliances (Veeam Hardened Repository, Dell PowerProtect Cyber Recovery). Echte Air-Gap-Lösungen, bei denen Speicher physisch nur während des Backups verbunden ist.

Eine 'Soft' Immutability (Löschsperre, die durch Admin übersteuerbar ist) reicht nicht. Wenn der Backup-Admin über Credentials den Speicher löschen kann, kann es der Angreifer auch.

Warum Cloud-Backup allein nicht ausreicht

Viele Unternehmen halten Cloud-Backup für hinreichend, weil 'Cloud sicher ist'. Stimmt nicht. Wer in einer Microsoft-365- oder Google-Workspace-Welt arbeitet und das Backup im selben Identity-Trust-Bereich hält, hat keinen echten Air-Gap.

Beispiel: Ransomware kompromittiert einen Domain-Admin oder einen Global Admin. Damit kann der Angreifer Backup-Konfigurationen ändern, Retention auf null setzen, Snapshots löschen. Cloud-Backup ohne Immutability auf Speicher-Ebene ist verloren.

Cloud-Backup wird stark, wenn Immutability auf Objekt-Storage-Ebene aktiviert ist und die Schlüssel-Hoheit beim Kunden liegt (BYOK), nicht beim Anbieter.

Die 3-2-1-1-0-Architektur

Erweiterung der klassischen 3-2-1-Regel. Drei Kopien der Daten, auf zwei verschiedenen Medien, eine davon offsite, eine davon offline oder immutable, null Fehler beim regelmäßigen Recovery-Test.

Konkret: Produktiv-Datenbank, Snapshot in zweiter Region, Backup auf Object-Storage mit WORM, plus regelmäßiges Recovery-Testing. Der Zero steht für 'Null Fehler im Test', also: nicht nur Backup, sondern getestetes Backup.

Versicherer und Audits akzeptieren diese Architektur breit. Wer weniger hat, riskiert Audit-Findings unter NIS2 Art. 21 Buchst. c.

Typische Fehler im Audit

Backup wird gemacht, aber nie wiederhergestellt. NIS2 verlangt regelmäßige Wirksamkeits-Prüfung. Wer keine Restore-Protokolle hat, hat kein wirksames Backup.

Backup wird in derselben Identity-Domain gehalten. Domain-Admin-Kompromittierung löscht beides.

Retention zu kurz. Wenn Ransomware drei Monate dormant ist, helfen 30 Tage Retention nicht. 90-180 Tage immutable Retention sind Stand der Technik für kritische Daten.

Schlüssel-Hoheit unklar. Wenn der Anbieter den Schlüssel hält, kann eine US-CLOUD-Act-Anordnung Backup-Zugriff erzwingen, ohne dass das Unternehmen es weiss.

Pragmatischer Vorgehensplan

1. Bestandsaufnahme: welche Workloads, welche Retentions, welche Storage-Tier, welche Verschlüsselung.

2. Klassifizierung: kritisch (RTO < 4h, RPO < 1h), wichtig, unterstützend. Pro Klasse Architektur definieren.

3. Architektur-Entscheidung: 3-2-1-1-0 als Soll-Bild, Gap-Analyse, Quick-Wins (WORM auf vorhandenem S3) und mittelfristige Investments (Hardened-Repository oder PowerProtect-Cyber-Recovery).

4. Recovery-Testing-Plan: vierteljährlicher Restore-Test für kritische Anwendungen, jährlicher End-to-End-DR-Test.

5. Decision Memo: die Anbieter-Auswahl strukturiert dokumentieren, mit gewichteten Kriterien, Dealbreakern (Immutability, Schlüssel-Hoheit, EU-Hosting), Stakeholder-Alignment, Residualrisiken. So entsteht ein audit-festes Backup-Konzept.