Ransomware-resistente Storage-Architekturen
Unter Verschluss
Veröffentlicht in Ausgabe 05/2026 - SCHWERPUNKT
Viele Organisationen stärken ihre Abwehr durch Endpoint-Schutz, Firewalls und SIEM-Plattformen. Diese Maßnahmen bleiben wichtig, verlieren jedoch an Wirksamkeit, sobald Cyberkriminelle administrative Rechte erlangen. In diesem Moment kann der Angreifer Schutzmechanismen umgehen, Richtlinien verändern oder Wiederherstellungspunkte entfernen. Eine Ransomware-resistente Storage-Architektur verankert Schutzmechanismen so, dass sie auch unter kompromittierten Identitäten greifen und verlässliche Restore-Punkte erhalten.
Wie Ransomware Storage angreift
Ransomware greift Speichersysteme nicht zufällig an. Die Täter analysieren die Umgebung systematisch, sobald sie ersten Zugriff erlangen. Sie suchen nach Zielen mit hoher Datenkonzentration und maximaler Wirkung. Storage- und Backupsysteme erfüllen genau diese Kriterien. Ein erfolgreicher Angriff auf diese Ebene beschleunigt die Erpressung und erschwert die Wiederherstellung.
Dabei nutzen Cyberkriminelle meist vorhandene Verwaltungswege. Sie arbeiten nicht zwingend über eigene Hintertüren, sondern missbrauchen legitime Funktionen. Storage-Managementinterfaces, Backupkonsolen und Automatisierungs-APIs liefern enorme Durchschlagskraft. Gelangen sie in falsche Hände, skalieren Angreifer ihre Wirkung mit wenigen Klicks. Ein einziger kompromittierter Admin-Zugang reicht oft aus, um Snapshots zu löschen, Retention-Zeiten zu verkürzen oder Replikationsziele unbrauchbar zu machen.
Viele Organisationen stärken ihre Abwehr durch Endpoint-Schutz, Firewalls und SIEM-Plattformen. Diese Maßnahmen bleiben wichtig, verlieren jedoch an Wirksamkeit, sobald Cyberkriminelle administrative Rechte erlangen. In diesem Moment kann der Angreifer Schutzmechanismen umgehen, Richtlinien verändern oder Wiederherstellungspunkte entfernen. Eine Ransomware-resistente Storage-Architektur verankert Schutzmechanismen so, dass sie auch unter kompromittierten Identitäten greifen und verlässliche Restore-Punkte erhalten.
Wie Ransomware Storage angreift
Ransomware greift Speichersysteme nicht zufällig an. Die Täter analysieren die Umgebung systematisch, sobald sie ersten Zugriff erlangen. Sie suchen nach Zielen mit hoher Datenkonzentration und maximaler Wirkung. Storage- und Backupsysteme erfüllen genau diese Kriterien. Ein erfolgreicher Angriff auf diese Ebene beschleunigt die Erpressung und erschwert die Wiederherstellung.
Dabei nutzen Cyberkriminelle meist vorhandene Verwaltungswege. Sie arbeiten nicht zwingend über eigene Hintertüren, sondern missbrauchen legitime Funktionen. Storage-Managementinterfaces, Backupkonsolen und Automatisierungs-APIs liefern enorme Durchschlagskraft. Gelangen sie in falsche Hände, skalieren Angreifer ihre Wirkung mit wenigen Klicks. Ein einziger kompromittierter Admin-Zugang reicht oft aus, um Snapshots zu löschen, Retention-Zeiten zu verkürzen oder Replikationsziele unbrauchbar zu machen.
In der Praxis verwenden kriminelle Akteure verschiedene Pfade, damit sie schneller ans Ziel kommen und Ausweichrouten behalten. Oft beginnt es mit einem kompromittierten Benutzerkonto, das sich im Alltag unauffällig verhält. Danach folgen Privilege Escalation und laterale Bewegung, bis ein Konto mit erweiterten Rechten verfügbar wird. Von dort aus greifen die Täter typische Ziele an:
- File- und Object-Shares, weil sie große Datenmengen enthalten und viele Systeme versorgen,
- Virtualisierungs-Storage, da sich damit viele VMs gleichzeitig treffen lassen,
- Backupserver und -Repositorys, die den Restore-Pfad kontrollieren und
- Replikations- und DR-Ziele, die die "zweite Kopie" eliminieren sollen.
Dabei setzen Angreifer oft auf Standardfunktionen. Sie löschen Backupjobs, reduzieren Retention-Zeiten oder deaktivieren Replikation, weil solche Änderungen in vielen Umgebungen nicht sofort Alarm auslösen. Sie beenden vorbereitend kritische Dienste, damit Datenbankprozesse stoppen und Sicherungen scheitern oder inkonsistent bleiben.
Immutable Storage schützt
Immutable Storage setzt Schutzmechanismen direkt in der Datenebene um und nicht nur in vorgelagerten Managementschichten. Damit adressiert das Konzept konkret das Szenario, das in realen Incident-Analysen immer wieder auftritt: Ein Angreifer erlangt Domänen- oder Backup-Admin-Rechte und nutzt legitime Verwaltungsfunktionen, um Wiederherstellungspunkte zu entfernen. Immutability verankert die Unveränderbarkeit dort, wo selbst privilegierte Accounts nur eingeschränkt agieren.
In der Praxis bedeutet das, dass das Storage-System jede Schreib-, Änderungs- oder Löschoperation gegen eine technisch erzwungene Retention-Policy prüft. Diese speichert das System manipulationsgeschützt in den Metadaten des jeweiligen Objekts oder Snapshots. Versucht ein Administrator, einen geschützten Datenbestand vor Ablauf der Frist zu löschen, lehnt der Storage-Controller die Operation ab. Die Entscheidung fällt also nicht in der Managementkonsole, sondern im Kern des Systems.
Unveränderbarkeit auf Storage-Ebene
Je nach Plattform implementieren Hersteller Immutability unterschiedlich. Object-Storage-Systeme verknüpfen Objekte mit Retention-Metadaten. Block- und File-Storage arbeiten mit Snapshot-Techniken, die referenzierte Datenstände logisch einfrieren. Entscheidend bleibt jedoch nicht das Verfahren, sondern die Durchsetzungsebene. Die Policy greift unterhalb der administrativen Oberfläche.
Robuste Architekturen trennen den Datenpfad vom Kontrollpfad. Über den Datenpfad laufen die normalen I/O-Zugriffe: Anwendungen lesen und schreiben Daten. Der Kontrollpfad steuert dagegen die "Regeln über den Daten", also Retention, Snapshot-Policys und Löschrechte. Wenn beide Ebenen getrennt bleiben, kann ein kompromittiertes Konto nicht automatisch auch die Schutzregeln ändern. Zusätzliche Hürden wie Multifaktor-Authentifizierung, getrennte Admin-Rollen oder ein Change-Prozess für Policy-Änderungen senken das Risiko weiter.
Manipulationssichere Audit-Logs ergänzen das Konzept, weil sie jede administrative Aktion dokumentieren und später nachvollziehbar machen. Immutable Storage wirkt damit als strukturelles Sicherheitsprinzip. Er entzieht kritischen Datenständen die Abhängigkeit von einzelnen Identitäten und verankert Schutz im Systemkern.
WORM-Snapshots für den Alltag
WORM-Snapshots übertragen Immutability in den operativen Alltag. Sie sichern Wiederherstellungspunkte mit einer verbindlichen Aufbewahrungsfrist. Je nach Plattform schützen sie Snapshots auf Primär-Storage oder Backupobjekte im Object Storage. Das System erzwingt die Retention technisch und blockiert Löschversuche bis zum Ablauf der Frist.
Betrachten wir als Beispiel WORM im Object Storage (S3 Object Lock). Der folgende AWS CLI-Aufruf versieht ein Backupobjekt direkt beim Schreiben mit Retention im Compliancemodus:
aws s3api put-object
--bucket immutable-backups
--key veeam/full-2026-02-10.vbk
--body full-2026-02-10.vbk
--object-lock-mode COMPLIANCE
--object-lock-retain-until-date 2026-03-25T00:00:00Z
Mit diesem Befehl schreibt das System nicht nur die Backupdatei, sondern verankert gleichzeitig die Unveränderbarkeit bis zum definierten Datum. Selbst ein Administrator mit weitreichenden Rechten kann das Objekt in dieser Zeit nicht löschen oder überschreiben. Das Storage-System prüft jede Löschanfrage gegen den gesetzten Retention-Time-stamp und weist sie bei Bedarf zurück. Genau dieser Mechanismus verhindert, dass Angreifer nach einer Kompromittierung die gesamte Backuphistorie einfach entfernen.
Ein anderes Beispiel ist der Snapshot-Schutz im Filesystem (ZFS Hold). Auch auf klassischem Filesystem- oder Block-Storage lässt sich ein ähnliches Prinzip anwenden. ZFS bietet beispielsweise die Möglichkeit, Snapshots durch einen sogenannten Hold gegen Löschung zu schützen. Der Snapshot bleibt so lange erhalten, bis ein Administrator den Hold explizit entfernt:
zfs snapshot tank/vmstore@daily-2026-02-10
zfs hold worm tank/vmstore@daily-2026-02-10
Solange der Hold aktiv ist, blockiert ZFS jeden Versuch, den Snapshot zu zerstören. Der Schutz wirkt direkt auf Dateisystemebene. Ein Angreifer, der lediglich versucht, Snapshots automatisiert zu löschen, scheitert an dieser Barriere. In produktiven Umgebungen kombiniert man diesen Mechanismus mit restriktiven Rollen und einer klaren Trennung von Storage- und Backupadministration.
WORM-Snapshots entfalten ihre Wirkung nur bei korrekter Konfiguration. Sie sollten Retention-Zeiten realistisch dimensionieren, Snapshot-Intervalle an Recovery Point Objective (RPO)-Ziele anpassen. Achten Sie auch darauf, Administrationsrollen strikt zu trennen sowie Änderungen an Snapshot-Policys zu überwachen.
Hilfreich sind außerdem regelmäßige Restore-Tests aus WORM-Snapshots. Nur so zeigt sich, ob Abhängigkeiten zwischen Applikationen, Datenbanken und Storage konsistent bleiben. WORM-Snapshots stellen jedoch keinen vollständigen Schutz dar. Sie bilden jedoch eine starke Verteidigungslinie auf Primär-Storage-Ebene. In Kombination mit Immutable Backup-Repositorys und Air-Gap-Strategien erhöhen sie die Widerstandsfähigkeit deutlich.
Air-Gap für physischen Schutz
WORM-Snapshots schützen Daten innerhalb eines Systems. Ein Air-Gap geht einen Schritt weiter. Er trennt Backupdaten bewusst von der Primärumgebung. Damit unterbricht er typische Angriffsketten, die sich über gemeinsame Identitäten, Netzsegmente oder Management-Schnittstellen ausbreiten.
Angreifer bewegen sich nach einer Kompromittierung meist entlang bestehender Berechtigungen. Sie nutzen identische Domänenkonten, zentrale Authentifizierung oder offene Netzwerkpfade. Wenn das Backupziel in derselben Sicherheitsdomäne liegt wie das Produktionssystem, erreicht der Angreifer es oft ohne zusätzlichen Aufwand. Ein Air-Gap durchbricht genau diese Konstellation.
Logische und physische Trennung
Ein physisches Air-Gap trennt Systeme vollständig vom Netzwerk. Klassische Beispiele sind Offline-Tapes oder Storage-Systeme, die nur während eines Backupfensters verbunden sind. Diese Variante bietet einen hohen Schutzgrad, erhöht jedoch den operativen Aufwand und verlängert im Zweifel die Wiederherstellungszeit.
In modernen Rechenzentren und Cloudumgebungen setzen viele Organisationen auf ein logisches Air-Gap. Dabei isolieren sie Backupsysteme durch dedizierte Netzsegmente, restriktive Firewallregeln und getrennte Identitäten. Entscheidend bleibt, dass das Produktionsnetz keine direkte, bidirektionale Kontrolle über das Backupziel besitzt. Ein typisches Muster in der Praxis sieht so aus:
- Der Backupserver initiiert Verbindungen ausschließlich in Richtung Repository.
- Das Repository akzeptiert nur definierte Protokolle bekannter Quellsysteme.
- Administrative Zugriffe erfolgen über separate Accounts mit MFA.
- Das Backup-Repository gehört nicht zur gleichen Active-Directory-Domäne wie die Produktivsysteme.
In Cloudszenarien ergänzen Admins diese Trennung häufig durch separate Accounts oder Subscriptions. Das Backup-Repository liegt dann in einer eigenen Sicherheitsdomäne mit eigenem Identity- und Rechtekonzept. Selbst wenn ein Angreifer vollständige Kontrolle über das Primärkonto erhält, kann er nicht ohne Weiteres auf das isolierte Backup zugreifen.
Air-Gaps technisch umsetzen
Ein logisches Air-Gap lässt sich beispielsweise durch eine restriktive Firewallregel umsetzen, die ausschließlich eingehende Verbindungen vom Backupserver erlaubt und keinerlei ausgehende Sessions ins Produktionsnetz zulässt. Das Repository wird damit zu einem passiven Ziel. Es nimmt Daten entgegen, steuert jedoch keine Prozesse im Primärnetz.
Parallel sollten Sie das Managementinterface des Backup-Storage vom Datentransfer trennen. Idealerweise läuft die Administrationsschnittstelle in einem separaten Managementnetz, das nur über Jump-Hosts mit starker Authentifizierung erreichbar ist. So reduziert sich die Wahrscheinlichkeit, dass ein kompromittiertes Benutzerkonto direkten Zugriff auf die Storage-Kontrolle erhält.
Ein Air-Gap ersetzt weder Immutability noch WORM-Snapshots, sondern ergänzt sie. Während WORM-Mechanismen Löschversuche technisch blockieren, verhindert der Air-Gap, dass Angreifer das Backupsystem überhaupt erreichen oder kontrollieren. Erst im Zusammenspiel entsteht eine belastbare Schutzschicht gegen gezielte Angriffe auf die Wiederherstellungsfähigkeit.
Kombinierte Schutzarchitektur
Kein einzelner Mechanismus stoppt heutige Ransomware-Angriffe zuverlässig. Die Täter kombinieren geschickt Credential-Theft, API-Missbrauch und automatisierte Löschroutinen. Wer nur auf einen Schutzbaustein setzt, bietet eine einzelne Angriffsfläche. Eine belastbare Architektur verteilt Schutz deshalb auf mehrere Ebenen und zwingt Angriffe in technische Sackgassen.
Eine robuste Schutzarchitektur sollte Folgendes umfassen:
- Immutable oder WORM-geschützte Backups im Object Storage,
- unveränderbare Snapshots auf dem Primär-Storage,
- logisch oder physisch isoliertes Backup-Repository mit Air-Gap-Charakter,
- strikt getrennte Rollen und Identitäten für Storage-, Backup- und Infrastrukturadministration und
- Monitoring und Alarmierung bei Änderungen an Retention-Policys, Snapshot-Regeln oder Replikationspfaden
Diese Ebenen greifen ineinander: Werden Snapshots auf dem Primärsystem gelöscht oder verschlüsselt, stehen immutable Backups im isolierten Repository bereit. Versucht derweil jemand, das Backup-Repository direkt anzugreifen, blockiert die technisch erzwungene Retention. Breitet sich ein Angriff lateral aus, unterbricht wiederum das Air-Gap die Vertrauenskette zwischen Produktionsnetz und Backupziel.
Entscheidend ist dabei nicht die einzelne Maßnahme, sondern vielmehr ihr Zusammenspiel. Die Architektur reduziert bewusst das Vertrauen in administrative Konten. Sie verlagert Schutzentscheidungen in den Storage-Controller, in die Retention-Mechanismen und in die Netzwerkisolation. Administratoren konfigurieren diese Mechanismen, doch sie können sie im Ernstfall nicht einfach aushebeln.
Auf diesem Weg entsteht eine mehrschichtige Verteidigung. Primär-Storage schützt kurzfristige Restore-Punkte, immutable Backups sichern historische Datenstände, und das Air-Gap verhindert den direkten Zugriff auf die letzte Sicherungslinie. Erst diese Kombination macht aus einzelnen Funktionen eine resiliente Storage-Strategie.
Datenverlust vs. Datenmanipulation
Viele Sicherheitskonzepte konzentrieren sich auf den Schutz vor Datenverlust. Ransomware beschränkt sich jedoch nicht auf reine Verschlüsselung. Angreifer manipulieren Daten zunehmend gezielt. Sie verändern Inhalte, fügen fehlerhafte Informationen ein oder löschen einzelne Datensätze. Diese Manipulationen bleiben oft lange unentdeckt.Für Unternehmen entsteht daraus ein zusätzliches Risiko. Selbst wenn sich Daten wiederherstellen lassen, bleibt unklar, ob sie konsistent und vertrauenswürdig sind. Eine wirksame Storage-Architektur muss deshalb nicht nur Löschungen verhindern. Sie muss auch unveränderbare Wiederherstellungspunkte bereitstellen, die eine verlässliche Rückkehr zu einem definierten Zustand ermöglichen. Genau hier liefern Immutable Storage und WORM-Snapshots unveränderbare Referenzstände.
Betrieb und Best Practices
Technische Schutzmechanismen entfalten ihre Wirkung nur dann, wenn der Betrieb sie konsequent unterstützt. Eine Ransomware-resistente Storage-Architektur verlangt klare Zuständigkeiten, verlässliche Prozesse und eine regelmäßige Überprüfung. Wer Immutability aktiviert, aber Retention-Zeiten nie kontrolliert, erzeugt nur scheinbare Sicherheit.
Zunächst sollten Unternehmen die Rollen strikt trennen. Storage-Administration, Backupadministration und Domänenadministration gehören nicht in dieselbe Hand. Jede Rolle erhält nur die Rechte, die sie für ihre Aufgabe benötigt. Zusätzlich sollten Organisationen Multifaktor-Authentifizierung für alle privilegierten Zugriffe durchsetzen, insbesondere auf Managementinterfaces von Storage- und Backupsystemen. Ein kompromittiertes Passwort darf nicht automatisch zur vollständigen Kontrolle führen.
Ebenso wichtig bleibt die Härtung der Control Plane. Managementschnittstellen sollten ausschließlich über dedizierte Netze erreichbar sein. Jump-Hosts mit Protokollierung und starker Authentifizierung reduzieren das Risiko unkontrollierter Direktzugriffe. API-Tokens sollten kurzlebig sein und regelmäßig rotieren. Gemeinsame Administratorkonten erhöhen dagegen das Risiko und erschweren die Nachvollziehbarkeit.
Ein zentraler Baustein im Betrieb ist der regelmäßige Restore-Test. Unternehmen sollten nicht nur prüfen, ob ihre Backups erfolgreich durchlaufen, sondern ob sich die Daten auch vollständig und konsistent wiederherstellen lassen. Idealerweise automatisiert das Team Test-Restores in isolierten Umgebungen. So erkennt es frühzeitig Inkonsistenzen, fehlende Abhängigkeiten oder fehlerhafte Retention-Policys.
Monitoring ergänzt diese Maßnahmen. Das System sollte Änderungen an Snapshot-Regeln, Retention-Zeiten oder Replikationszielen aktiv melden. Auch ungewöhnlich viele Löschversuche oder Policy-Änderungen verdienen Aufmerksamkeit. Moderne Storage-Systeme liefern entsprechende Audit-Logs. Diese Logs gehören in ein zentrales Monitoring oder SIEM, damit das Security-Team Korrelationen erkennt.
Dokumentierte Notfallprozesse runden den Betrieb ab. Im Ernstfall darf kein Team erst klären müssen, wer Snapshots zurücksetzt oder Backup-Repositorys freigibt. Klare Eskalationswege und vordefinierte Restore-Szenarien verkürzen die Reaktionszeit deutlich.
Stolpersteine in der Praxis
Selbst eine gut geplante Architektur liefert keinen absoluten Schutz. Kleine Konfigurationsfehler oder schwache Betriebsprozesse können die stärksten Mechanismen entwerten. Deshalb lohnt sich ein nüchterner Blick auf typische Fallstricke, die in Audits und Incident-Reviews immer wieder auftauchen.
Zu kurze Retention-Zeiten zählen zu den häufigsten Problemen. Wenn Teams einen Vorfall erst nach Wochen erkennen, helfen Sieben-Tage-Snapshots nicht mehr. Ähnlich kritisch wirken Lücken in der Historie, die durch fehlgeschlagene Jobs oder zu aggressive Aufbewahrungsregeln entstehen. Wer Retention staffeln will, sollte sie auch aktiv überwachen. Sonst existieren Restore-Punkte zwar auf dem Papier, aber nicht im Repository.
Ein weiteres Praxisproblem betrifft Abhängigkeiten. Applikationskonsistenz entsteht nicht automatisch. Datenbanken, VM-Stacks und verteilte Services verlangen abgestimmte Snapshot- oder Backupmechanismen. Wer nur Volume-Snapshots zieht, kann im Restore Inkonsistenzen erzeugen, die erst nach dem Wiederanlauf auffallen. Regelmäßige Restore-Tests decken solche Lücken auf, bevor sie im Incident die Recovery Time Objective (RTO), also die Zeit bis zur Wiederherstellung, sprengen.
Insiderrisiko und Governance
Immutability greift nur so gut wie ihre konkrete Ausprägung. Typische Fehler sind falsch gesetzte Default-Retention, inkonsistente Policys zwischen Snapshot- und Backupebene oder fehlende Sperren gegen Policy-Änderungen. Auch "weiche" Betriebsmodi können zum Problem werden, wenn Teams Governance-Mechanismen nicht konsequent aktivieren. Wer unveränderbare Restore-Punkte will, muss dafür sorgen, dass das System Löschungen und Überschreibungen wirklich blockiert und dass niemand die Regeln im Alltag stillschweigend aushebelt.
Viele Organisationen unterschätzen das Insiderrisiko. Technische Immutability blockiert spontane Löschaktionen, aber sie ersetzt keine Governance. Wer Policy-Änderungen ohne Vier-Augen-Prinzip erlaubt, öffnet ein Einfallstor absichtlich oder versehentlich. Deshalb sollten Teams Änderungen an Retention, Snapshot-Regeln und Repository-Konfigurationen wie sicherheitskritische Changes behandeln: mit Approval, Logging, Alarmierung und regelmäßigen Reviews.
Fazit
Eine Ransomware-resistente Storage-Architektur beantwortet diese Frage mit einer Kombination aus Immutable-Storage, WORM-Snapshots und Air-Gap-Strategien. Sie verankert Schutzmechanismen direkt im Storage-System und ergänzt sie durch klare Rollenmodelle sowie konsequente Betriebsprozesse. Dadurch reduziert sie die Abhängigkeit von einzelnen Identitäten und verschiebt Sicherheitsentscheidungen in technisch erzwungene Ebenen. Ausschlaggebend bleibt, dass Teams Retention, Policys und Zugriffswege regelmäßig prüfen, Restore-Tests automatisieren und Alarme auf Policy-Änderungen ernst nehmen.
(dr)