Unveränderlicher Speicher schützt Backups vor Ransomware

Backups als primäres Angriffsziel

Moderne Angriffe folgen einem wiederkehrenden Muster. Nach dem Erstzugriff über Phishing, gestohlene Zugangsdaten oder ungepatchte VPN-Systeme weiten die Täter ihre Rechte aus, bis sie auf Domänenebene mit Administratorrechten agieren. Anschließend suchen sie Backup-Server, Repositories und Hypervisoren, stoppen dort Dienste, beseitigen Wiederherstellungspunkte und chiffrieren die abgelegten Sicherungen. Erst danach beginnt die Verschlüsselung der Produktionssysteme. Einem Unternehmen ohne intakte Sicherungen bleibt in der Verhandlung keine Rückfallebene.

KI-gestützte Werkzeuge beschleunigen inzwischen beide Phasen. Generative Modelle produzieren überzeugendere Phishing-Nachrichten samt Deepfake-Material, automatisierte Routinen zerstören Datenbestände schneller als klassische Erkennungs- und Reaktionsprozesse reagieren. Unveränderlicher Speicher (Immutable Storage) setzt an einem Punkt an, den erbeutete Zugangsdaten nicht erreichen. Die Speicherplattform selbst verweigert Lösch- und Änderungsoperationen, unabhängig davon, welche Berechtigungen ein Angreifer übernommen hat.

WORM-Schutz auf Objektebene

S3 Object Lock speichert Objekte nach dem WORM-Prinzip (Write Once Read Many). Einmal geschriebene Daten bleiben beliebig oft lesbar, Änderungen und Löschungen blockiert der Dienst bis zum Ende der Aufbewahrungsfrist. Die Funktion setzt aktivierte Versionierung voraus und bindet den Schutz an eine konkrete Objektversion. Ein Upload unter gleichem Namen legt eine weitere Version an, die gesperrte bleibt unangetastet und dient als verlässlicher Wiederherstellungspunkt. Neben zeitbasierten Fristen existiert der Legal Hold, eine unbefristete Sperre für Rechtsstreitigkeiten und Audits. Berechtigte Rollen heben ihn jederzeit wieder auf, für den Ransomware-Schutz zählt deshalb allein die zeitbasierte Variante.

Der Aufbewahrungsmodus bestimmt die Belastbarkeit des Schutzes. Im Governance-Modus heben Benutzer mit speziellen IAM-Berechtigungen die Frist auf oder verkürzen sie. Das eignet sich für Tests und gegen versehentliches Löschen. Als letzte Wiederherstellungslinie taugt allein der Compliance-Modus. Dort kann niemand die geschützte Objektversion überschreiben oder entfernen und niemand die Frist verkürzen, der Root-Benutzer eingeschlossen. Verlängern lässt sich die Frist jederzeit, der Weg zurück bleibt versperrt. Ein Angreifer mit vollständigen Administratorrechten scheitert an dieser Stelle, dieselbe Endgültigkeit verpflichtet aber zu sorgfältiger Planung der Fristen vor dem Scharfschalten.

WORM-Sperren gehören inzwischen zum Standardumfang aller großen Cloud-Plattformen. Azure bietet Immutable Storage für Blob-Daten mit zeitbasierter Aufbewahrung und Legal Hold, wahlweise pauschal pro Container oder mit Versionierung bis hinunter auf einzelne Blobs. Google Cloud stellt mit dem Object Retention Lock eine vergleichbare Funktion bereit. Die Durchsetzung erfolgt auf Plattformebene, nach Angaben von Microsoft können selbst eigene Mitarbeiter gesperrte Daten nicht vorzeitig freigeben. Unabhängige Prüfungen gegen regulatorische Vorgaben, darunter die SEC-Regel 17a-4, bestätigen den Anspruch der Implementierungen. Ein Löschversuch auf ein gesperrtes Objekt endet mit einer Fehlermeldung der Plattform, gleichgültig ob er aus einer Konsole, einem Skript oder einer kompromittierten Anwendung stammt.

Eigenes Konto außerhalb der Produktion

Object Lock wirkt erst in einer Architektur, die Zugriffswege konsequent trennt. Die unveränderlichen Kopien liegen in einem eigenen Konto oder Tenant, auf den aus der Produktionsumgebung keine Schreib- oder Löschrechte bestehen. Übernimmt ein Täter Domäne, Backup-Software oder einzelne Administratorkonten, fehlt ihm weiterhin jeder Zugang zur Verwaltungsebene des Sicherungskontos. Eigene Anmeldedaten mit Multifaktor-Authentifizierung (MFA), eine Berechtigungsstruktur nach dem Prinzip minimaler Rechte und der Verzicht auf eine Domänenmitgliedschaft der Backup-Systeme vervollständigen die Trennung.

Das zweite Element trennt Steuerungs- und Datenebene. Der API-Schlüssel der Backup-Software darf Daten schreiben und lesen, das Aufheben von Sperren oder das Ändern von Aufbewahrungsrichtlinien bleibt der getrennt abgesicherten Verwaltungsoberfläche vorbehalten. Ein erbeuteter Schlüssel erlaubt damit keine Zerstörung geschützter Bestände. Bei Replikationen auf ein zweites System erhöht das Pull-Verfahren die Widerstandsfähigkeit zusätzlich. Das Zielsystem holt die Daten mit eigenen Zugangsdaten ab und setzt eine eigene, abweichende Aufbewahrungsrichtlinie durch, die Quelle kennt keine Anmeldedaten des Ziels. Ein kompromittiertes Primärsystem hat auf die zweite Kopie deshalb keinerlei Zugriff.

Überwachung schließt die organisatorische Seite ab. Protokollierte Zugriffe auf das Sicherungskonto, Alarme bei fehlgeschlagenen Löschversuchen und eine nachvollziehbare Historie aller Änderungen an Aufbewahrungsrichtlinien zeigen aktive Angriffe früh an. Auch die Audit-Protokolle brauchen einen Bucket mit Compliance-Sperre, damit Täter ihre Aktivitäten nicht nachträglich aus den Aufzeichnungen entfernen können.

Air Gap und die Regel 3-2-1-1-0

Unveränderlichkeit wirkt logisch, ein Air Gap ergänzt die physische oder zeitliche Isolation. Getrennte Netzsegmente, private Anbindungen statt öffentlicher Internetwege und zeitgesteuerte Zugriffsfenster reduzieren die Angriffsfläche. Speicherziele, die nur für die Dauer des Sicherungsvorgangs erreichbar sind, bleiben für Schadsoftware in der übrigen Zeit unerreichbar. Magnetbänder in ausgelagerter Rotation erfüllen denselben Zweck mit höherem manuellem Aufwand. Beide Mechanismen wirken zusammen. Der WORM-Schutz sichert Bestände gegen Manipulation mit gestohlenen Berechtigungen, die Isolation nimmt Angreifern zusätzlich die Sicht auf das Ziel.

Die Regel 3-2-1-1-0 fasst die Bausteine zu einer prüfbaren Vorgabe zusammen. Drei Datenkopien verteilen sich auf zwei unterschiedliche Medientypen, eine Kopie lagert außerhalb des Standorts, eine weitere ist unveränderlich oder offline gehalten, und null Fehler bei verifizierten Wiederherstellungen vervollständigen die Vorgabe. Der letzte Punkt bestimmt den Wert der gesamten Strategie. Automatisierte Restore-Tests, Integritätsprüfungen auf Speicherebene und Wiederherstellungsübungen in isolierten Sandbox-Umgebungen belegen, dass die geschützten Kopien im Ernstfall nutzbar sind. Erst geprüfte Kopien sichern im Ernstfall den Neustart der Systeme.

Grenzen der Unveränderlichkeit

Zu kurz bemessene Aufbewahrungsfristen verschlechtern den Schutz. Angreifer halten sich vor der Verschlüsselung häufig über Wochen unbemerkt im Netz auf. Eine Sperrfrist von sieben Tagen endet, bevor der Vorfall auffällt, die vermeintlich geschützten Kopien enthalten dann bereits kompromittierte Stände oder sind erneut löschbar. Die Frist muss die realistische Erkennungszeit samt Puffer abdecken. Gleichzeitig bindet jede Verlängerung Kapazität und Kosten, denn gesperrte Objekte lassen sich vor dem Fristende nicht bereinigen. Gestaffelte Fristen entschärfen den Zielkonflikt, kurze Sperren für tägliche Sicherungen, längere für wöchentliche und monatliche Stände. Ein tragfähiges Retention-Konzept dokumentiert die Begründung der gewählten Zeiträume und überprüft sie nach jedem Vorfall und jeder Übung.

Der Governance-Modus lässt eine Umgehung zu, die im Betrieb regelmäßig übersehen wird. Rechte zum Aushebeln der Sperre landen über weit gefasste IAM-Rollen bei Konten, die ein Angreifer übernehmen kann. Kritisch bleibt zudem die Backup-Software selbst. Kompromittiert ein Täter den Backup-Server oder zerstört den Katalog mit den Metadaten der Sicherungen, bleiben die unveränderlichen Objekte zwar erhalten, die Wiederherstellung verzögert sich jedoch erheblich, da die Zuordnung der Datenblöcke fehlt. Eine geschützte Kopie des Katalogs und dokumentierte Verfahren für den Neuaufbau der Backup-Umgebung sind deshalb fester Bestandteil der Architektur.

Fehlkonfigurationen untergraben den Schutz an weiteren Stellen. Fehlende Versionierung, dauerhaft entsperrte Richtlinien aus der Testphase oder Lifecycle-Regeln, die Objektversionen nach Fristende automatisch entfernen, hinterlassen Lücken. Unveränderlichkeit beschreibt eine Eigenschaft des Gesamtsystems. Erst die Durchsetzung über sämtliche Schichten hinweg, vom Objektspeicher über die Zugriffssteuerung bis zur Replikation, macht den Schutz belastbar. Ein einzelner schwacher Punkt, zum Beispiel ein Cloud-Konto mit ausstehender Zahlung und drohender Kündigung, gefährdet den gesamten Bestand.

Souveräne Optionen mit S3-kompatiblen Systemen

Object Lock gehört zur S3-API und steht damit auch außerhalb der Hyperscaler bereit. S3-kompatible Objektspeicher für den Eigenbetrieb setzen die WORM-Sperren im eigenen Rechenzentrum oder bei europäischen Providern um. Für Organisationen mit Anforderungen an digitale Souveränität verbindet dieser Ansatz die Unveränderlichkeit mit voller Kontrolle über Standort, Zugriff und Vertragsbedingungen der Sicherungsdaten. Auch bei einer Rückverlagerung von Workloads aus der Public Cloud bleibt der WORM-Schutz erhalten, da die Schnittstelle identisch bleibt und die Sicherungsprozesse keine Anpassung benötigen. Gehärtete Linux-Repositories mit Unveränderlichkeit auf Dateisystemebene erweitern das Spektrum lokaler Speicherziele. Backup-Anwendungen sprechen beide Varianten über dieselben Schnittstellen an, die Architekturprinzipien aus getrenntem Konto, Compliance-Modus und Air Gap bleiben unverändert gültig.

Fazit

Object Lock im Compliance-Modus nimmt Ransomware ein zentrales Druckmittel, die Zerstörung der Sicherungen. Die Schutzwirkung hängt an der Architektur, an einem eigenen Konto außerhalb der Produktionsberechtigungen, an ausreichend bemessenen Aufbewahrungsfristen, an einem ergänzenden Air Gap und an regelmäßig verifizierten Wiederherstellungen nach der Regel 3-2-1-1-0. Die Werte aus dem Jahr 2026 bestätigen den Zusammenhang. Organisationen mit Investitionen in Unveränderlichkeit stellen ihre Daten nach einem Angriff mehr als doppelt so häufig vollständig wieder her.