Die Idee ist einfach: Eine Sicherung wird für einen festgelegten Zeitraum schreibgeschützt – und zwar so, dass auch ein Administrator sie nicht vorzeitig löschen kann. Selbst wer die volle Kontrolle über das Netzwerk erlangt, kann die Daten dieses Zeitfensters weder verschlüsseln noch entfernen. Genau das rettet im Ernstfall die Wiederherstellung.
Jahrzehntelang wurde dieses Ziel physisch erreicht: Bänder wurden beschrieben, entnommen und in einen Tresor oder an einen zweiten Standort gebracht. Was nicht angeschlossen ist, kann nicht angegriffen werden. Der Nachteil liegt im Ablauf – jemand muss wechseln, transportieren und dokumentieren, und im Ernstfall muss das richtige Band erst zurückgeholt werden. Unveränderbare Speicherbereiche erreichen die Trennung logisch statt räumlich: Die Sicherung bleibt erreichbar, um gelesen zu werden, aber nicht, um verändert zu werden.
Wie Unveränderbarkeit technisch funktioniert
Das Grundprinzip heißt WORM, „write once, read many“: Daten werden einmal geschrieben und können danach bis zum Ablauf einer Sperrfrist nur noch gelesen werden. Umgesetzt wird das auf verschiedenen Wegen, die sich in Schutzwirkung und Handhabung unterscheiden.
- Objektspeicher mit Aufbewahrungssperre: Verbreitet ist etwa S3 Object Lock, das auch viele kompatible Speichersysteme nachbilden. Der Hersteller unterscheidet zwei Modi: Im Governance-Modus können Konten mit Sonderrechten die Sperre aufheben; im Compliance-Modus kann niemand eine gesperrte Version vor Fristablauf löschen oder die Frist verkürzen, auch nicht das Hauptkonto.
- Gehärtete Sicherungsspeicher im eigenen Haus: Systeme, auf die die Sicherungssoftware nur schreibend zugreift, deren Verwaltung nicht über das Netzwerk erreichbar ist und die eine Sperrfrist selbst durchsetzen.
- Wechselmedien mit Schreibschutz: WORM-Bänder oder ausgelagerte Bänder bleiben eine gültige Form, vor allem als zusätzliche Kopie mit langer Aufbewahrung.
Für den Schutz vor einem Angreifer mit Administratorrechten ist dieser Unterschied entscheidend. Eine Sperre, die ein privilegiertes Konto aufheben kann, schützt vor Versehen und vor Schadsoftware ohne diese Rechte, aber nicht vor jemandem, der genau dieses Konto übernommen hat. Die entscheidende Frage an die eigene IT lautet deshalb nicht „Ist unser Backup unveränderbar?“, sondern „Wer genau könnte die Sperre aufheben, und auf welchem Weg?“ Lautet die ehrliche Antwort „jeder mit dem Administratorpasswort“, ist das Ziel verfehlt.
Worauf es bei der Umsetzung ankommt
Entscheidend ist, dass die Unveränderbarkeit auf der Speicherebene durchgesetzt wird und nicht nur eine Einstellung in der Backup-Software ist. Ebenso wichtig: getrennte Zugangsdaten. Wenn dasselbe Administratorkonto Server und Sicherungssystem verwaltet, ist ein Teil des Schutzes wieder aufgehoben. Und die Aufbewahrungsdauer sollte länger sein als die typische Zeit, die zwischen Einbruch und Entdeckung vergeht – Angreifer warten mitunter Wochen. Darüber hinaus gehören einige weniger offensichtliche Punkte in jede Prüfung:
- Die Zeitquelle absichern: Sperrfristen hängen an der Uhr des Speichersystems. Wer die Systemzeit verstellen kann, lässt Fristen womöglich vorzeitig ablaufen.
- Änderungen an Sperrfristen und Löschvorgänge nur im Vier-Augen-Prinzip zulassen oder technisch ganz ausschließen.
- Auffälligkeiten überwachen: Eine laufende Verschlüsselung im Produktivsystem zeigt sich häufig als sprunghaft steigende Datenmenge in der nächsten Sicherung.
- Den Wiederherstellungsweg selbst schützen: Sicherungssoftware, Kataloge und Schlüssel müssen auch dann verfügbar sein, wenn die übrige Umgebung verloren ist.
Grenzen und Preis der Unveränderbarkeit
Unveränderbarkeit schützt, was vor dem Angriff gesichert wurde – nicht mehr. Waren Angreifer lange unbemerkt im Netz, können auch die gesperrten Sicherungen bereits Hintertüren oder manipulierte Konten enthalten. Eine Rücksicherung nach einem Angriff beginnt deshalb mit der Suche nach einem sauberen Stand, nicht mit dem jüngsten. Ebenso wenig verhindert eine Sperre, dass Daten abgezogen werden. Damit gestohlene Sicherungskopien für Angreifer wertlos sind, sollten sie zusätzlich verschlüsselt sein.
Hinzu kommt der Speicherbedarf, denn was gesperrt ist, lässt sich auch dann nicht löschen, wenn der Platz knapp wird. Ein vereinfachtes Rechenbeispiel mit frei gewählten Annahmen: 5 TB Datenbestand, täglich 2 % geänderte Daten, also 100 GB, und eine Sperrfrist von 30 Tagen. Ohne Komprimierung und Deduplizierung ergibt das 5 TB für die Vollsicherung und 3 TB für die täglichen Änderungen, zusammen rund 8 TB vor jeder Reserve. Wird zwischendurch eine neue Vollsicherung angelegt, bleibt die alte bis zum Fristende zusätzlich stehen. Läuft ein solcher Speicher voll, scheitern neue Sicherungen – und Aufräumen ist gerade nicht möglich.
Für die Länge der Sperrfrist gibt es deshalb keine allgemeingültige Zahl. Sie ist ein Kompromiss aus drei Größen: der Zeit, die ein Einbruch im ungünstigsten Fall unentdeckt bleiben kann, dem verfügbaren Speicher und der Frage, wie weit eine saubere Wiederherstellung zurückreichen muss. Eine Möglichkeit ist, die täglichen Sicherungen kürzer zu sperren und wenige Monatsstände deutlich länger. So bleibt der Speicherbedarf beherrschbar, ohne auf weit zurückreichende Stände zu verzichten.
Auch der Datenschutz verlangt eine Abwägung. Personenbezogene Daten, deren Löschung verlangt wird, bleiben in gesperrten Sicherungen bis zum Fristende erhalten. Das ist beherrschbar, sollte aber im Löschkonzept beschrieben sein: wie lange Daten in Sicherungen verbleiben und wie verhindert wird, dass gelöschte Datensätze bei einer Rücksicherung wieder in den Bestand gelangen.
Unsere Einordnung: Unveränderbare Sicherungen ersetzen kein Konzept, sie vervollständigen es. Sie sind die Kopie, auf die man sich verlassen kann, wenn alles andere kompromittiert ist. In Kombination mit regelmäßigen Wiederherstellungstests entsteht daraus die belastbarste Form von Datensicherung, die heute wirtschaftlich erreichbar ist.
Verwandte Themen: Wer hier weiterdenkt, liest bei Backup-Strategie, revisionssichere Archivierung und Backup verschlüsseln weiter.
Quellen
- CON.3 Datensicherungskonzept · BSIamtlich
- Ransomware – Fakten und Abwehrstrategien · BSIamtlich
