Ein Immutable Backup schützt Sicherungsstände für eine festgelegte Zeit davor, verändert oder gelöscht zu werden. Selbst ein kompromittiertes Administratorkonto soll die gesperrten Wiederherstellungspunkte nicht vor Ablauf dieser Frist entfernen können. Für Unternehmen ist dabei nicht das Etikett „immutable“ entscheidend, sondern die technische Durchsetzung: Die Sperre muss auch gegen Backup-Administratoren, manipulierte Aufbewahrungsregeln und Angriffe auf die Verwaltungsoberfläche bestehen.
Eine belastbare Lösung verbindet unveränderlichen Speicher mit getrennten Identitäten, Netzwerksegmentierung, mehreren Sicherungskopien und regelmäßig geprüften Wiederherstellungen. Im ersten Schritt sollte ein Unternehmen klären, welche Daten und Systeme nach einem Ransomware-Angriff für den Betrieb nötig sind. Danach lassen sich Speichertechnik, Sperrfrist und Wiederanlaufplan passend festlegen.
Was ein unveränderliches Backup tatsächlich leistet
Immutability bedeutet, dass gespeicherte Backup-Objekte innerhalb einer definierten Aufbewahrungsdauer weder überschrieben noch verkürzt noch regulär gelöscht werden können. Das entspricht dem WORM-Prinzip: einmal schreiben, mehrfach lesen. Je nach Plattform wird dieser Schutz durch Object Lock, unveränderliche Snapshots, gesperrte Recovery Points, ein gehärtetes Repository oder unveränderliche Archivmedien umgesetzt.
Der Nutzen zeigt sich vor allem nach der Kompromittierung privilegierter Konten. Ransomware beschränkt sich längst nicht zwingend auf erreichbare Windows-Freigaben. Angreifer können nach erlangten Administratorrechten auch Sicherungsaufträge deaktivieren, Kataloge löschen, Aufbewahrungszeiten verkürzen oder Backup-Speicher verschlüsseln. Eine wirksam gesperrte Sicherung begrenzt diesen Schaden, weil mindestens einige ältere Datenstände erhalten bleiben.
Unveränderlichkeit löst jedoch nicht jedes Problem. Sie erkennt keine Schadsoftware, garantiert keine vollständigen Sicherungen und verhindert nicht, dass bereits verschlüsselte oder manipulierte Daten als neuer Wiederherstellungspunkt gesichert werden. Sie schützt außerdem nicht automatisch Zugangsdaten, Konfigurationsdaten des Backup-Systems oder den Schlüssel einer clientseitigen Verschlüsselung. Das Verfahren ist eine Schutzschicht für gespeicherte Sicherungsstände, kein vollständiges Sicherheitskonzept.
Vier technische Wege und ihre unterschiedlichen Grenzen
Unter dem Begriff Immutable Backup werden mehrere Verfahren zusammengefasst. Sie sollten nicht als gleichwertig behandelt werden, denn sie reagieren unterschiedlich auf kompromittierte Konten, Fehlkonfigurationen und physische Schäden.
Object Lock im Objektspeicher
Ein Objektspeicher kann Sicherungsobjekte bis zu einem festgelegten Zeitpunkt gegen Löschen und Überschreiben sperren. Die Plattform setzt diese Frist auf Speicherebene durch. Das ist stärker als ein bloßes Schreibschutz-Häkchen in der Backup-Anwendung.
Bei der Auswahl ist zu prüfen, wer eine Sperre setzen, verlängern oder umgehen darf. Manche Plattformen unterscheiden zwischen einer administrativ noch beeinflussbaren Betriebsart und einem strengeren Modus, in dem auch privilegierte Konten die Aufbewahrung nicht vorzeitig beenden können. Die genaue Bezeichnung und Wirkung müssen in der Produktdokumentation des Speicheranbieters geprüft werden.
Object Lock ist besonders geeignet, wenn Backups ohnehin in einen S3-kompatiblen oder herstellereigenen Objektspeicher geschrieben werden. Die Backup-Software muss diese Funktion ausdrücklich unterstützen. Eine normale Dateiablage in einem Cloud-Speicher wird nicht allein dadurch unveränderlich, dass Benutzer nur Leserechte erhalten.
Gehärtetes Backup-Repository
Ein gehärtetes Repository ist ein besonders abgesicherter Sicherungsserver, dessen Betriebssystem, Konten und Dateisystemfunktionen auf die Speicherung unveränderlicher Wiederherstellungspunkte ausgerichtet sind. In Windows-Umgebungen läuft ein solches Repository häufig bewusst nicht als normaler, dauerhaft in die Domäne eingebundener Dateiserver. Dadurch soll eine kompromittierte Active-Directory-Identität nicht automatisch Zugriff auf den Backup-Speicher erhalten.
Die Schutzwirkung hängt stark von der Einrichtung ab. Ein Repository ist nicht gehärtet, nur weil es Linux verwendet oder vom Backup-Server getrennt steht. Lokale Administratorrechte, SSH-Zugriff, Wartungskonten, Zeitsynchronisation, physischer Zugriff und die Möglichkeit, Datenträger neu zu formatieren, gehören in die Bewertung. Unterstützt der Hersteller eine festgelegte Installationsweise, sollte diese nicht durch zusätzliche Software oder allgemeine Serverrollen aufgeweicht werden.
Offline- und Air-Gap-Kopien
Eine Offline-Kopie ist nach dem Schreiben nicht mehr über das produktive Netzwerk erreichbar. Wechselmedien, ausgelagerte Bänder oder getrennt aufbewahrte Datenträger können diese physische Trennung herstellen. Ein logischer Air Gap arbeitet dagegen mit zeitweilig geschlossenen Verbindungen, isolierten Konten oder einem separaten Abrufmechanismus.
Die Trennung reduziert die Angriffsfläche, erschwert aber häufig schnelle Wiederherstellungen. Außerdem ist ein Band nur dann geschützt, wenn es nach dem Sicherungslauf tatsächlich ausgeworfen und sicher gelagert wird. Ein dauerhaft eingelegtes oder über eine Management-Schnittstelle erreichbares Medium ist kein vollständiger Air Gap. Offline-Kopien eignen sich daher gut als zusätzliche letzte Rückfallebene, nicht als alleinige Sicherungsstrategie.
Unveränderliche Snapshots und Backup-Appliances
Speichersysteme und Backup-Appliances können Snapshots mit Löschsperren anbieten. Das ermöglicht kurze Wiederanlaufzeiten, weil Datenstände nahe am produktiven System verfügbar bleiben. Ein Snapshot auf demselben Array schützt allerdings nicht vor dem Ausfall, der Zerstörung oder einer vollständigen administrativen Übernahme dieses Arrays.
Hier muss die Prüfung über die Funktion „Snapshot erstellen“ hinausgehen: Kann ein Speicheradministrator die Sperre entfernen? Bleibt die Kopie bei einer Neuinitialisierung des Systems erhalten? Existiert eine unabhängige Replikation in einen zweiten Sicherheitsbereich? Erst die Antworten auf diese Fragen zeigen, ob der Snapshot eine echte Schutzkopie oder nur eine bequeme lokale Rücksetzoption ist.
Die Schutzarchitektur aus dem Geschäftsbedarf ableiten
Eine feste Sperrfrist für sämtliche Daten ist selten sinnvoll. Sie kann zu kurz sein, sodass der letzte saubere Stand bereits abgelaufen ist, oder unnötig lang, sodass Speicherverbrauch und Löschpflichten schwer beherrschbar werden. Ausgangspunkt sind stattdessen Wiederanlaufziele, Erkennungsdauer und Datenklassen.
- Datenverlustgrenze festlegen: Das Recovery Point Objective beschreibt, wie viel Datenverlust zeitlich tragbar ist. Ein Ziel von vier Stunden verlangt Sicherungspunkte in entsprechend kurzen Abständen; eine tägliche Sicherung erfüllt dieses Ziel nicht.
- Wiederanlaufzeit definieren: Das Recovery Time Objective gibt vor, wann ein Dienst wieder verfügbar sein soll. Langsame Archivmedien können als Notfallkopie geeignet sein, aber ein knappes Wiederanlaufziel allein möglicherweise nicht erfüllen.
- Sperrfrist festlegen: Sie sollte die realistische Zeit bis zur Erkennung eines Angriffs plus einen Sicherheitsaufschlag abdecken. Dabei sind interne Aufbewahrungsregeln, Datenschutzanforderungen und vertragliche Vorgaben einzubeziehen.
- Mindestens einen getrennten Sicherheitsbereich schaffen: Die unveränderliche Kopie darf nicht allein von denselben Konten, demselben Verzeichnisdienst und derselben Verwaltungsebene abhängen wie die Produktivumgebung.
Als Architekturhilfe wird häufig die 3-2-1-1-0-Regel verwendet: drei Datenkopien, zwei unterschiedliche Speicherarten, eine Kopie an einem anderen Standort, eine offline oder unveränderlich geschützte Kopie und null ungeprüfte Sicherungsfehler. Die Regel ist kein Produktmerkmal. Sie zwingt aber dazu, Abhängigkeiten sichtbar zu machen und Wiederherstellungstests als Teil der Sicherung zu behandeln.
Identitäten entscheiden über die Widerstandsfähigkeit
Ein unveränderlicher Speicher kann durch eine schwache Verwaltungsebene entwertet werden. Backup-Dienste sollten daher nicht mit normalen Domänenadministratorkonten betrieben werden. Für Backup-Konsole, Speicherplattform und Produktivsysteme sind getrennte Rollen und Anmeldeinformationen sinnvoll.
- Verwende eigene Administratorkonten ausschließlich für die Backup-Verwaltung.
- Schütze interaktive Anmeldungen mit Mehrfaktor-Authentifizierung, sofern die Plattform dies unterstützt.
- Trenne tägliche Bedienung, Sicherheitsadministration und Freigabe kritischer Änderungen.
- Speichere Notfallzugänge geschützt und überwache ihre Verwendung.
- Beschränke Dienstkonten auf die benötigten Systeme und Rechte.
- Leite Protokolle an ein System weiter, das nicht vom Backup-Administrator allein kontrolliert wird.
Besondere Aufmerksamkeit verdient die Wiederherstellung von Active Directory. Wird nach einem Angriff eine alte Domänenumgebung zurückgebracht, können kompromittierte Konten, Gruppenmitgliedschaften oder Gruppenrichtlinien ebenfalls wieder erscheinen. Der Wiederanlaufplan muss daher nicht nur Dateien, sondern auch eine vertrauenswürdige Identitätsbasis vorsehen. Dazu gehören dokumentierte Notfallkonten, gesicherte Systemzustände und eine festgelegte Reihenfolge für die Wiederherstellung abhängiger Dienste.
Windows-, Server- und Microsoft-365-Daten getrennt betrachten
Unternehmensdaten liegen selten in einem einzigen Sicherungssystem. Windows-Endgeräte, lokale Server, virtuelle Maschinen und Microsoft 365 benötigen unterschiedliche Erfassungs- und Wiederherstellungsverfahren. Eine unveränderliche Kopie ist nur hilfreich, wenn alle benötigten Bestandteile im Sicherungsumfang enthalten sind.
Bei Windows Server reicht eine reine Dateisicherung für bestimmte Rollen nicht aus. Anwendungen und Verzeichnisdienste benötigen anwendungskonsistente Sicherungen oder vom jeweiligen Hersteller unterstützte Wiederherstellungsabläufe. Virtuelle Maschinen sollten nicht ausschließlich über Kopien einzelner virtueller Festplattendateien gesichert werden, wenn dadurch Konsistenz und Metadaten fehlen.
Microsoft 365 ist ein eigener Schutzbereich. Eine lokale Serversicherung erfasst keine ausschließlich in Exchange Online, SharePoint Online, OneDrive oder Teams gespeicherten Inhalte. Nutzt das Unternehmen dafür eine separate Backup-Plattform, müssen Immutability, Aufbewahrungsregeln, Mandantentrennung und Wiederherstellung dort eigenständig geprüft werden. Vorhandene Papierkörbe und Versionsverläufe sind nützliche Funktionen, ersetzen aber keine unabhängig verwaltete Sicherung.
Windows-Clients wiederum enthalten oft lokale Dateien, Gerätekonfigurationen oder Spezialsoftware, obwohl zentrale Speicherung vorgesehen ist. Eine Bestandsaufnahme zeigt, ob die Wiederherstellung eines standardisierten Geräts genügt oder ob Endgerätedaten gesichert werden müssen. Dadurch wird vermieden, große Mengen austauschbarer Betriebssystemdateien zu schützen, während tatsächlich wichtige lokale Arbeitsdaten fehlen.
Einführungsreihenfolge ohne gefährliche Abkürzungen
Die Umstellung sollte zunächst mit einer begrenzten Datenklasse erprobt werden. Eine sofortige lange Sperre für alle Sicherungen kann bei falscher Dimensionierung erhebliche Kapazitätsprobleme verursachen und lässt sich bei streng durchgesetzter Unveränderlichkeit absichtlich nicht einfach zurücknehmen.
- Ist-Zustand erfassen: Dokumentiere Sicherungsquellen, Ziele, Administratoren, Aufbewahrungszeiten, Netzwerkpfade und vorhandene Kopieraufträge.
- Angriffspfad prüfen: Stelle fest, ob ein Domänenadministrator sowohl Produktivdaten als auch sämtliche Backups löschen kann. Ist das möglich, fehlt eine wirksame administrative Trennung.
- Geeignete Speicherfunktion auswählen: Prüfe die Herstellerdokumentation auf unterstützte Unveränderlichkeit, Mindestaufbewahrung, Zeitabhängigkeiten und Verhalten bei Kontolöschung oder Vertragsende.
- Testbereich aufsetzen: Aktiviere die Sperre zunächst für einen überschaubaren Sicherungsauftrag und kontrolliere, ob Lösch- und Überschreibversuche tatsächlich scheitern.
- Kapazität beobachten: Ermittle anhand realer Änderungsraten, wie stark Datenmenge und Aufbewahrungsdauer den Speicherbedarf erhöhen. Deduplizierung und Komprimierung können helfen, dürfen aber nicht als garantierte Einsparung eingeplant werden.
- Rollen und Netzwege trennen: Entferne unnötige Domänenabhängigkeiten, begrenze Verwaltungszugriffe und erlaube nur die benötigten Verbindungen zwischen Backup-Komponenten.
- Wiederherstellung durchführen: Stelle ausgewählte Dateien, eine vollständige Arbeitslast und mindestens einen abhängigen Dienst in einer isolierten Testumgebung wieder her.
- Schrittweise ausweiten: Nimm weitere Systeme erst auf, wenn Löschschutz, Überwachung, Kapazität und Wiederanlauf für den Testbereich nachvollziehbar funktionieren.
Woran ein Unternehmen die Schutzwirkung prüft
Ein erfolgreicher Sicherungsjob beweist nur, dass Daten geschrieben wurden. Für ein Immutable Backup sind zusätzliche Tests nötig. Dabei sollte die Organisation nicht in der produktiven Umgebung mit riskanten Manipulationsversuchen arbeiten, sondern einen freigegebenen Testbestand und dokumentierte Testkonten verwenden.
- Löschtest: Ein berechtigter Backup-Administrator versucht, einen gesperrten Test-Wiederherstellungspunkt vor Ablauf der Frist zu entfernen. Der Vorgang muss abgewiesen und protokolliert werden.
- Änderungstest: Es wird geprüft, ob die Aufbewahrungszeit eines bereits geschützten Objekts nachträglich verkürzt werden kann. Eine streng geschützte Kopie darf dadurch nicht vorzeitig löschbar werden.
- Identitätstest: Der Ausfall oder die Sperrung des produktiven Verzeichnisdienstes darf den Zugriff auf autorisierte Notfallwiederherstellungen nicht unmöglich machen.
- Integritätstest: Die Backup-Plattform sollte Datenblöcke oder Objekte auf Lesbarkeit und Konsistenz prüfen. Ein Restore ausgewählter Daten bestätigt zusätzlich, dass die Sicherung praktisch verwendbar ist.
- Isolierter Wiederanlauf: Wiederhergestellte Systeme werden zunächst ohne Verbindung zum Produktionsnetz untersucht. So wird verhindert, dass verbliebene Schadsoftware oder kompromittierte Automatisierung sofort erneut aktiv wird.
Die Auswertung muss zu Handlungen führen. Schlägt nur der Löschtest fehl, liegt das Problem wahrscheinlich bei Sperrmodus, Berechtigungen oder Speicherintegration. Ist das Objekt geschützt, aber nicht wiederherstellbar, sind Sicherungsqualität, Katalog, Schlüssel und Anwendungsabhängigkeiten zu untersuchen. Funktioniert die Wiederherstellung technisch, dauert aber länger als das festgelegte Wiederanlaufziel, fehlt möglicherweise eine schnellere zusätzliche Recovery-Schicht.
Fehlkonfigurationen, die nur scheinbar Sicherheit bieten
Ein häufiger Irrtum ist die Gleichsetzung von Aufbewahrungsrichtlinie und Unveränderlichkeit. Eine Richtlinie, die Sicherungen nach 30 Tagen automatisch löscht, verhindert nicht zwingend eine manuelle Löschung am ersten Tag. Entscheidend ist, ob der Speicher die Mindestfrist technisch erzwingt.
Auch eine schreibgeschützte Netzwerkfreigabe bietet keinen gleichwertigen Schutz. Wer den Dateiserver administrieren oder die Zugriffsrechte ändern kann, kann den Schreibschutz möglicherweise aufheben. Gleiches gilt für Snapshots, die vom selben kompromittierten Administratorkonto gelöscht werden können.
Weitere Schwachstellen entstehen durch gemeinsam genutzte Konten, unüberwachte Notfallzugänge und eine Backup-Konsole im normalen Benutzernetz. Kritisch ist außerdem ein einzelner Verschlüsselungsschlüssel ohne gesicherten Rückweg. Sind Backups clientseitig verschlüsselt und geht der Schlüssel verloren, bleibt die unveränderliche Kopie zwar erhalten, ist aber nicht nutzbar.
Unbegrenzte Sperrfristen sind ebenfalls keine automatische Verbesserung. Sie können Speicher dauerhaft binden und mit zulässigen Löschanforderungen kollidieren. Retention und Datenschutz müssen gemeinsam geplant werden: Unveränderlichkeit verhindert unbefugte oder voreilige Löschung, darf aber nicht ohne Prüfung als dauerhafte Archivierung eingesetzt werden.
Notfallwiederherstellung nach einem Ransomware-Fund
Nach einem bestätigten Angriff sollte nicht sofort der neueste Wiederherstellungspunkt in das bereinigte Produktionsnetz eingespielt werden. Zuerst sind Zeitpunkt und Ausbreitungsweg des Angriffs einzugrenzen. Der jüngste Datenstand kann bereits verschlüsselte Dateien, manipulierte Konten, schädliche geplante Aufgaben oder andere Persistenzmechanismen enthalten.
Die Wiederherstellung beginnt in einem isolierten Bereich mit vertrauenswürdigen Verwaltungsgeräten und getrennten Zugangsdaten. Danach werden Identitätsdienste, grundlegende Infrastruktur und geschäftskritische Anwendungen in ihrer dokumentierten Abhängigkeitsreihenfolge aufgebaut. Sicherheitsprüfung und Fachtest entscheiden, ob ein Datenstand freigegeben wird. Erst dann folgt die kontrollierte Rückkehr in das Produktionsnetz.
Der geeignete Recovery Point ist somit nicht zwingend der neueste, sondern der jüngste Stand, der mit hinreichender Sicherheit vor der Kompromittierung liegt und die benötigten Daten enthält. Mehrere unveränderliche Generationen erhöhen die Chance, einen solchen Stand zu finden. Genau darin liegt der praktische Wert einer angemessenen Sperrfrist.
Häufige Fragen zu unveränderlichen Unternehmens-Backups
Was geschieht, wenn während der Sperrfrist Speicherplatz knapp wird?
Gesperrte Sicherungen lassen sich absichtlich nicht beliebig entfernen. Das Unternehmen muss deshalb Warnschwellen, Kapazitätsprognosen und einen Erweiterungsweg einrichten. Eine Notfalllöschung darf nicht als reguläre Kapazitätsstrategie eingeplant werden. Bei strengem Object Lock kann selbst der Plattformadministrator die betroffenen Objekte bis zum Fristende nicht freigeben.
Müssen unveränderliche Sicherungen zusätzlich verschlüsselt werden?
Immutability und Verschlüsselung erfüllen unterschiedliche Aufgaben. Die Sperre schützt vor Veränderung und Löschung, während Verschlüsselung die Vertraulichkeit gespeicherter Daten schützt. Unternehmen benötigen in vielen Umgebungen beides. Schlüssel, Zertifikate und Wiederherstellungskennwörter müssen getrennt gesichert werden, weil eine unlesbare unveränderliche Kopie keinen Wiederanlauf ermöglicht.
Wie lässt sich ein externer Backup-Dienst prüfen?
Verlange eine klare Beschreibung der technischen Sperre, der administrativen Rollen und des Verhaltens bei einem kompromittierten Kundenkonto. Zusätzlich sind die Dauer bis zur Wiederherstellung, der Export größerer Datenmengen, die Löschung nach Vertragsende und die Zuständigkeit für Schlüssel zu klären. Ein eigener Wiederherstellungstest zeigt, ob die zugesagte Funktion mit den tatsächlichen Unternehmensdaten und Abhängigkeiten funktioniert.
