Unveränderliche Backups:: Die letzte Verteidigungslinie richtig gestalten, betreiben und prüfen

Angreifer nehmen gezielt Sicherungen ins Visier: Sie versuchen etwa, Aufbewahrungsfristen für Backups zu verkürzen, Soft-Delete zu deaktivieren oder komplette Sicherungsspeicher zu löschen. Aktuelle Schutzkonzepte setzen deshalb auf drei Bausteine – unveränderliche Speicherziele, eine konsequente Isolierung der Kopien und eine Automatisierung, die bei Bedrohungsalarmen Schutzmechanismen aktiviert, Aufbewahrungsfristen einfriert und Wiederherstellungspunkte vor vorzeitigem Löschen schützt. Praxiserfahrungen zeigen, dass sich so die Wahrscheinlichkeit eines sauberen Restores deutlich steigern lässt.

Was „unveränderlich“ technisch bedeutet

Im Kontext von Backups bezeichnet „Immutability“ Speicher- und Steuerungsmechanismen, die das Löschen oder Ändern von Backup-Objekten bis zum Ende der Aufbewahrungsfrist technisch verhindern. Dazu zählen WORM-Speichersysteme (Write Once, Read Many), Objektspeicher mit Retention-Regeln und rechtlich belastbaren Sperren sowie Backup-Repositories, die applikationsseitig „Write Once“-Eigenschaften erzwingen. Entscheidend dabei ist, dass die Sperren auch privilegierte Zugriffe einschließen und dass das Deaktivieren von Schutzmechanismen nur über einen mehrstufigen Freigabeprozess möglich ist.

Dabei gilt: Snapshots sind zwar hilfreich, taugen aber nicht als vollwertiges Backup, weil sie an den Primärspeicher gekoppelt bleiben. Einen robusteren Schutz bietet die Kombination aus

• klar definierten Vorgaben für den maximal zulässigen Datenverlust (Recovery Point Objective, RPO) und die maximal akzeptable Wiederherstellungszeit (Recovery TimeObjective, RTO),
• unveränderlich gespeicherten Backups und
• einer durchgängigen Sicherungsarchitektur.

Bausteine einer tragfähigen Architektur

Eine belastbare Immutability-Strategie ruht auf drei Ebenen: Speicher, Backup-Software und Isolierung.

Auf der Speicherebene kommen Objektspeicher mit definierten Aufbewahrungsregeln und optionalen rechtlichen Sperren zum Einsatz. In Cloud-Umgebungen nutzen Administratoren dafür spezielle Backup-Vaults mit Schutz vor versehentlichem Löschen und gesperrter Unveränderlichkeit. Private Endpoints, verschlüsselte Speicherschlüssel und restriktive Netzwerkpfade sichern ergänzend die Datenflüsse ab. Je nach Umgebung können WORM-Bänder oder Dateisysteme mit Write-Once-Eigenschaft die Strategie ergänzen. Ihre Wirkung entfalten diese Bausteine allerdings nur, wenn verbindliche Richtlinien eine nachträgliche Verkürzung der Aufbewahrungsfristen ausschließen.

Auf der Ebene der Backup-Software geht es um gehärtete Ablageorte, getrennte Konten für Betrieb und Verwaltung sowie Konfigurationen, die die Unveränderlichkeit zusätzlich kryptografisch signieren oder anderweitig auf Anwendungsebene absichern. Kritische Eingriffe wie das Aufheben von Sperren sollten nur über eine Mehrpersonenfreigabe möglich sein.

Eine tragfähige Isolierung lässt sich entweder physisch umsetzen – etwa wenn eine Kopie die Produktionsumgebung verlässt – oder logisch, indem Netze, Identitätsverwaltung und Betriebsabläufe konsequent voneinander getrennt werden. Konkret heißt das: getrennte Netzsegmente, eine eigenständige Konten- und Rollenverwaltung in einem separaten Verzeichnisdienst oder Mandanten sowie automatisierte Abläufe nach dem Pull-Prinzip, bei denen das Zielsystem die Sicherung abholt, statt dass das Quellsystem sie aktiv überträgt. Mindestens ebenso wichtig ist die Absicherung der Steuerungsebene, denn ein erfolgreicher Angriff auf die Verwaltungsfunktionen kann genügen, um viele Systeme gleichzeitig zu kompromittieren.

Cloudnative Umsetzung

In Cloud-Umgebungen lassen sich die beschriebenen Architekturprinzipien mit plattformeigenen Diensten umsetzen. Backup-Vaults, die Unveränderlichkeit unterstützen, verhindern das Löschen oder Modifizieren von Wiederherstellungspunkten vor Ablauf der Aufbewahrungsfrist.

In der Praxis bringt das allerdings Nebenwirkungen mit sich, die Administratoren einkalkulieren müssen: Eine Verkürzung der Aufbewahrungsfrist ist nicht möglich, solange die Sperre greift. Wird ein Workload gelöscht und anschließend in gleicher Form neu bereitgestellt, lassen sich ältere, gesperrte Wiederherstellungspunkte häufig nicht mehr zuordnen oder verwenden. Änderungen am Lebenszyklus eines Systems sollten deshalb konsequent gegen die gewählten Aufbewahrungsfristen geprüft werden.

Ergänzend erhöht eine saubere Absicherung von Netzwerk und Identitäten die Widerstandskraft – etwa durch Private Endpoints, klar definierte Rollen und eine Mehrpersonenfreigabe für sensible Eingriffe.

In hybriden und lokalen Umgebungen kombinieren viele Organisationen ein separates, gehärtetes Sicherungsziel in der eigenen Infrastruktur mit einer zweiten Kopie in einem Objektspeicher, der verbindliche Aufbewahrungsfristen pro Objekt erzwingt. Für lange Aufbewahrung und zusätzlichen Schutz kommt häufig eine weitere Ebene hinzu, die räumlich getrennt betrieben wird – etwa ein externes Archiv. So entstehen kurze Wiederherstellungszeiten vor Ort, während die isolierte Kopie einen belastbaren Schutz gegen Manipulation und Löschversuche in der Produktionsumgebung bietet.

Auch Software-as-a-Service-(SaaS)-Anwendungen benötigen unabhängige Sicherungen, die außerhalb des jeweiligen Anbieters liegen. Die in vielen Produkten enthaltenen Papierkörbe sind kein gleichwertiger Ersatz. Auch hier sollte die Zielumgebung unveränderlich sein und in einer separaten Steuerungsdomäne betrieben werden – nur so bleibt die Wiederherstellungsfähigkeit erhalten, wenn das Quellsystem ausfällt oder kompromittiert wird.

Vier verbreitete Irrtümer

Obwohl vielen Verantwortlichen klar ist, worauf es bei unveränderlichen Backups ankommt, scheitern Organisationen in der Praxis dennoch regelmäßig an denselben Fehleinschätzungen.
Erstens gehen viele Teams davon aus, dass Snapshots bereits eine vollständige Datensicherung darstellen. Wie oben beschrieben bleiben Snapshots jedoch an den Primärspeicher gekoppelt – ohne isolierte und unveränderliche Kopie bleibt ein Angriff auf den Primärspeicher ein direktes Risiko für die Wiederherstellung.

Zweitens unterschätzen Administratoren die Folgen für die Flexibilität: Wer Unveränderlichkeit aktiviert, kann Aufbewahrungsfristen nicht mehr beliebig verkürzen. Vor Migrationen oder Systemänderungen müssen die Auswirkungen auf bestehende Sperren bewertet werden. Drittens wiegt eine unveränderliche Kopie ohne getrennte Identitäten und Netzpfade Verantwortliche in falscher Sicherheit – auf der Steuerungsebene bleibt sie angreifbar. Viertens verkennen viele Organisationen die Rolle der Governance: Ohne verbindliche Richtlinien, regelmäßige Audits und klare Verantwortlichkeiten bleiben selbst technisch einwandfreie Sicherungen ein unvollständiger Schutz.

Reifegrad messen, Wiederherstellung testen

Deshalb brauchen Organisationen Kennzahlen, die den Reifegrad ihrer Sicherungsstrategie greifbar machen. Dazu gehören RPO und RTO, der Anteil tatsächlich unveränderlich gesicherter Workloads, die Zeit bis zum ersten sauberen Restore und der Anteil erfolgreicher Wiederherstellungen, die zuvor auf Schadsoftware geprüft wurden. Automatisierung unterstützt diesen Weg: Bei sicherheitsrelevanten Alarmen können Workflows automatisch Schutzmaßnahmen aktivieren, Aufbewahrungsfristen einfrieren und die Angriffsfläche für Löschoperationen verkleinern. Das entlastet die Teams und kann verhindern, dass in einer kritischen Lage wertvolle Wiederherstellungspunkte verloren gehen.

Tragfähig wird das Ganze erst durch eine saubere Governance: Eine Backup- und Recovery-Steuerung muss fachliche Anforderungen an Verfügbarkeit und Wiederherstellbarkeit mit Aufbewahrungspflichten und nachvollziehbaren Kontrollen verknüpfen. Wer die Sicherungsstrategie sauber in die Regelwerke des Informationssicherheitsmanagements einbettet, erleichtert Audits, erhöht die Vergleichbarkeit zwischen Bereichen und schafft Klarheit über Mindeststandards. Dokumente, die Anforderungen aus etablierten Normen wie ISO 27001 abbilden, haben sich in der Praxis bewährt und helfen, den Nachweis dauerhaft zu führen.

Konkretes Vorgehen

Wer Immutable Backups einführen will, kann sich an sechs Schritten orientieren: Am Anfang steht ein vollständiges Inventar: Welche Systeme und Daten sind kritisch? Welche regulatorischen Aufbewahrungsfristen gelten? Welche Wiederherstellungsziele sind verbindlich?

Auf dieser Grundlage definieren die Verantwortlichen eine Zielarchitektur, die mindestens eine unveränderliche Kopie und eine Isolierungsstufe vorsieht.

Im zweiten Schritt legen sie Richtlinien für Aufbewahrungsfristen und Sperren fest, die eine spätere Verkürzung ausschließen.

Drittens härten sie die Steuerungsebene – mit getrennten Administrationskonten, Mehrpersonenfreigabe für kritische Eingriffe und streng geregelten Notfallzugängen.

Viertens setzen sie die Isolierung technisch konsequent um: Netz und Identität trennen, Kopien in eigenständigen Konten oder Mandanten führen, Datenflüsse so gestalten, dass möglichst Pull-Mechanismen zum Einsatz kommen. Ergänzend helfen Malware-Prüfungen auf Datenpfaden und automatische Schutzlogik, die bei Bedrohungsalarmen greift.

Fünftens üben die Teams die Wiederherstellung regelmäßig. Die Ergebnisse fließen dokumentiert und geprüft in die Verbesserung der Architektur zurück. Sechstens braucht die Umgebung ein Lebenszyklusmanagement, das Änderungen an Workloads frühzeitig gegen die Unveränderlichkeitsregeln spiegelt und Speicherbedarf sowie Kosten realistisch plant.

Fazit

Unveränderliche Backups sind kein einzelnes Produkt, sondern ein Sicherheitsprinzip. Es verbindet geschützte Speicherziele, gehärtete Steuerungsebenen, echte Isolierung und geübte Wiederherstellung. Richtig umgesetzt verkürzt es die Zeit bis zur Rückkehr in den Betrieb, reduziert den Erpressungsdruck und stärkt die Widerstandsfähigkeit der Organisation. Die Erfahrung aus Projekten zeigt: Dieser Ansatz trägt besonders dann, wenn Technik, Governance und Automatisierung gemeinsam gedacht und nachweisbar gelebt werden.