WISSEN > OBJECT STORAGE -> CYBER RESILIENCE MIT OBJECT STORAGE
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
Cyber Resilience mit Object Storage
Die unabhängige Recovery-Kopie schützen
Das sollten Sie mitnehmen: FALSCH - ÜBERARBEITEN
- WAN-Latenz lässt sich nicht wegkaufen, nur umgehen.
Edge File Services sorgen dafür, dass möglichst wenige Zugriffe den WAN-Pfad durchlaufen.
- Global verfügbar heißt nicht lokal gespeichert.
Für die Cache-Größe zählt der lokale Working Set, nicht die Gesamtkapazität.
- Caching und Locking lösen zwei verschiedene Probleme.
Das eine optimiert den Weg zu den Daten, das andere koordiniert konkurrierende Schreibzugriffe. Wer nur das erste plant, bekommt das zweite als Überraschung.
- Nicht jedes Produkt kann standortübergreifend sperren.
DFS Replication und Azure File Sync bieten kein globales Locking – das entscheidet die Auswahl früher als jede Performance-Kennzahl.
- Sizing braucht Nutzungsdaten, keine Kapazitätszahlen.
Aussagekräftig sind Dateianzahl, Änderungsverhalten und Zugriffsverhalten am Standort.
Cyber Resilience mit Object Storage
Inhaltsverzeichnis
- Object Storage hat eine andere Aufgabe als der Primärspeicher
- S3 allein macht Daten nicht immutable
- Immutability und administrative Isolation sind zwei verschiedene Dinge
- Der S3-Client selbst ist Teil des Threat Models
- Object Lock schützt Versionen – nicht automatisch die gesamte Recovery-Architektur
- ASSISTRA-Praxiserfahrung: Die Daten überlebten – die Plattform nicht
- „S3-kompatibel" ist keine Zusicherung identischer Security Semantics
- Eine zweite Kopie ist nur dann unabhängig, wenn ihre Failure Domains unabhängig sind
- Retention erzeugt einen unvermeidbaren Trade-off
- Was eine belastbare Object-Storage-Recovery-Ebene ausmacht
- Fazit
- Quellen
Ransomware-Schutz endet nicht dort, wo produktive Daten durch Snapshots oder Versionierung wiederherstellbar sind. Bei einem weitreichenden Angriff können gleichzeitig Produktionssysteme, Virtualisierungsplattform, Backup-Server, Identitätsdienste und administrative Zugänge betroffen sein. Dann stellt sich eine andere Frage:
Existiert noch eine Datenkopie, die der Angreifer weder löschen noch manipulieren konnte – und lässt sich daraus die Plattform tatsächlich wiederherstellen?
Genau hier kann Object Storage eine eigenständige Rolle in einer Cyber-Resilience-Architektur übernehmen. Entscheidend ist jedoch nicht allein, dass Daten über S3 gespeichert werden. Eine belastbare Recovery-Ebene entsteht erst aus dem Zusammenspiel von Object-Level-Immutability, Retention, Versionierung, Berechtigungen, administrativer Isolation und einem unabhängigen Recovery-Pfad.
Die zentrale Erkenntnis lautet deshalb:
Eine Kopie ist nicht deshalb unabhängig, weil sie auf Object Storage liegt.
Object Storage hat eine andere Aufgabe als der Primärspeicher
Cyber Resilience wird häufig als ein einzelnes Storage-Thema behandelt. Tatsächlich müssen unterschiedliche Schutzebenen verschiedene Aufgaben erfüllen.
Ein produktives Storage-System soll einen Angriff möglichst früh erkennen, einen brauchbaren Recovery Point erhalten und eine schnelle Wiederaufnahme des Betriebs ermöglichen. Bei einem Global File System stehen wiederum Benutzeraktivitäten, Dateiänderungen, Versionierung und die Wiederherstellung von Dateien oder Verzeichnisstrukturen im Vordergrund.
Object Storage kann eine andere Aufgabe übernehmen:
Er soll eine Recovery-Kopie bereitstellen, deren Vertrauensgrenze möglichst unabhängig von der kompromittierten Produktionsumgebung ist.
Innerhalb einer mehrstufigen Architektur lassen sich diese Rollen klar voneinander abgrenzen:
text
BENUTZER / ENDPOINT
│
▼
GLOBAL FILE SYSTEM
Detection · Containment
File Version Recovery
│
▼
ENTERPRISE STORAGE
Storage Detection
Immutable Snapshot
Fast Operational Recovery
│
▼
OBJECT STORAGE
Object Lock / WORM
Administrative Isolation
Independent Recovery Copy
Das Global File System adressiert die Ausbreitung und Wiederherstellung auf Datei- und Benutzerebene. Enterprise Storage kann Mechanismen für Detection, unveränderliche Snapshots und schnelle Operational Recovery bereitstellen. Object Storage ist dagegen nicht die Detection-Ebene. Er beantwortet eine andere Frage:
Welche Kopie bleibt vertrauenswürdig verfügbar, wenn die vorgelagerten Systeme und ihre Administration nicht mehr als vertrauenswürdig betrachtet werden können?
Das Ziel ist damit nicht primär ein möglichst niedriger RTO. Es geht zunächst darum, nach einer weitreichenden Kompromittierung überhaupt noch eine vertrauenswürdige Datenbasis für die Wiederherstellung zu besitzen.
NIST behandelt Ransomware und andere destruktive Ereignisse in SP 1800-11 entsprechend als Data-Integrity-Problem: Für eine belastbare Wiederherstellung muss nicht nur eine Kopie vorhanden sein; es muss auch bestimmt werden können, welche Daten verändert wurden, wann diese Veränderung stattfand und welche Backup-Version für eine Wiederherstellung geeignet ist.
Vereinfacht ergibt sich daraus folgender Pfad:
text
Produktive Daten
│
▼
Applikation / File Service / Backup
│
▼
S3 API + Credentials
│
▼
Object Storage
│
├── Versioning
├── Object Lock / Retention
├── getrennte Berechtigungen
└── administrative Trust Boundary
│
▼
Unabhängige Recovery-Kopie
S3 allein macht Daten nicht immutable
Ein grundlegendes Missverständnis besteht darin, Object Storage oder das S3-Protokoll selbst mit Immutability gleichzusetzen.
Ein normal über S3 gespeichertes Objekt ist nicht automatisch gegen einen Client mit ausreichenden Berechtigungen geschützt. Schutz vor Löschung oder Veränderung entsteht erst durch zusätzliche Mechanismen: Versioning, Object Lock, Retention Periods, Governance- beziehungsweise Compliance-Modi, Legal Hold sowie entsprechende IAM- und Administrationsmodelle.
Das muss architektonisch getrennt betrachtet werden.
Versioning ist noch keine Immutability
S3 Versioning erlaubt mehrere Versionen desselben Object Keys. Eine neue Schreiboperation kann dadurch eine neue Version erzeugen, anstatt die vorherige Version physisch zu ersetzen.
Bei einem einfachen DELETE in einem versionierten Amazon-S3-Bucket wird ein Delete Marker als aktuelle Version erzeugt. Die ältere Objektversion existiert weiterhin.
Das schützt jedoch nicht grundsätzlich vor einem Angreifer mit ausreichenden Rechten. Versionen können gezielt adressiert und permanent gelöscht werden.
Versioning verbessert die Wiederherstellbarkeit, ist aber allein keine belastbare WORM-Grenze.
Ein Detail mit erheblichen Kapazitätsfolgen wird dabei häufig übersehen: Jede Version ist eine vollständige, eigenständige Kopie des Objekts. S3-Versioning speichert keine Deltas zwischen Versionen. Wer eine ein Gigabyte große Datei ablegt und anschließend ein einzelnes Byte ändert, hält danach zwei vollständige Kopien vor. Auf diesen Punkt kommen wir bei der Retention zurück.
Was Object Lock tatsächlich schützt
S3 Object Lock implementiert ein Write-Once-Read-Many-Modell auf Ebene einzelner Objektversionen und setzt Versioning voraus. Für eine Objektversion kann eine Retain Until Date definiert werden. Bis zu diesem Zeitpunkt greifen die Regeln des gewählten Retention-Modus. Neue Versionen und Delete Marker können weiterhin entstehen; die geschützte ältere Version bleibt entsprechend ihrer Retention erhalten.
Das bedeutet einen wichtigen Architekturwechsel:
text
ohne Object Lock
Client mit ausreichenden Rechten
│
└────────► Objektversion löschen
mit wirksamer Retention
Client
│
└──────► DELETE
│
▼
Retention Policy
│
X
geschützte Version
Die Anwendung, welche die Daten geschrieben hat, muss damit nicht mehr zwangsläufig auch die Möglichkeit besitzen, bereits geschützte Versionen wieder zu entfernen. Genau diese Entkopplung ist für Cyber Resilience relevant.
Ist Object Lock auf einem Bucket aktiviert, lässt es sich nicht wieder deaktivieren, und die Versionierung kann nicht mehr suspendiert werden. Bei Amazon S3 kann Object Lock inzwischen auch für bestehende Buckets nachträglich aktiviert werden; bereits vorhandene Objekte müssen dann allerdings gesondert mit Retention-Parametern versehen werden. Bei S3-kompatiblen Implementierungen hängt diese Nachrüstbarkeit von der eingesetzten Release ab – ältere Stände verlangen häufig die Aktivierung bereits bei der Bucket-Erstellung, was eine spätere Einführung zu einem Datenmigrationsprojekt macht.
Governance und Compliance sind sicherheitstechnisch nicht dasselbe
Amazon S3 unterscheidet zwei Retention-Modi.
Governance Mode schützt Objektversionen vor normalen Lösch- und Änderungsoperationen. Ein Principal mit der Berechtigung s3:BypassGovernanceRetention kann die Retention jedoch umgehen. Dazu genügt die Berechtigung allein nicht: Der Bypass muss im Request zusätzlich explizit über den Header x-amz-bypass-governance-retention:true angefordert werden. Die S3-Konsole setzt diesen Header bei vorhandener Berechtigung standardmäßig.
Compliance Mode zieht eine wesentlich härtere Grenze. Während der festgelegten Retention kann laut AWS auch der Root User des Accounts eine geschützte Objektversion weder löschen noch überschreiben; Retention Mode und Retention Period können nicht verkürzt, sondern nur verlängert werden. Der einzige verbleibende Weg, ein solches Objekt vor Ablauf der Retention zu entfernen, ist die Löschung des zugehörigen AWS-Accounts.
Damit besitzt die Wahl des Modus unmittelbare Auswirkungen auf das Threat Model. Ein Governance Lock kann gegen kompromittierte Application Credentials wirksam sein, während die Übernahme eines hoch privilegierten Administrationskontos mit Bypass-Recht ein anderes Risiko darstellt.
Die Frage darf daher nicht nur lauten: „Ist Object Lock aktiviert?" Sondern: „Welche Identität kann die Retention unter welchen Bedingungen verändern oder umgehen?"
Immutability und administrative Isolation sind zwei verschiedene Dinge
Dieser Unterschied ist für eine Cyber-Resilience-Architektur zentral.
Immutability beantwortet:
Kann eine geschützte Objektversion gelöscht oder verändert werden?
Administrative Isolation beantwortet:
Kann der Angreifer Kontrolle über die administrative Domäne des Storage-Systems erlangen?
Beides darf nicht gleichgesetzt werden.
Eine Umgebung kann eine starke Object-Lock-Konfiguration besitzen, aber Storage-Administration, Backup-Administration und zentrale Identitätsverwaltung eng miteinander koppeln. Umgekehrt kann ein Object Storage keine WORM-Retention besitzen und trotzdem einen Angriff überstehen, weil dessen administrative Credentials außerhalb der kompromittierten Identitätsdomäne liegen. Letzteres ist allerdings kein garantierter Immutability-Schutz. Es reduziert lediglich bestimmte Angriffspfade.
Object Lock wirkt auf der S3-API-Ebene
Der Grund, warum diese beiden Eigenschaften nicht ineinander überführbar sind, liegt in der Durchsetzungsebene des Mechanismus. Object Lock wird an der S3-Schnittstelle durchgesetzt: Trifft ein Löschrequest am Gateway ein, prüft dieses den Lock-Status und verweigert die Operation.
Daraus ergibt sich eine präzise beschreibbare Schutzgrenze. Object Lock wirkt gegen versehentliche Löschungen durch S3-Clients, gegen böswillige Löschungen mit kompromittierten S3-Credentials, gegen programmatische Massenlöschungen durch Skripte oder Ransomware, die auf S3-APIs zielt – und im Compliance-Modus gegen jeden Benutzer einschließlich Bucket-Owner und Storage-Admin-Account.
Nicht geschützt sind dagegen Operationen unterhalb dieser Schnittstelle: direkte Zugriffe auf die darunterliegende Speicherebene, administrative Kommandos auf Cluster-Ebene sowie die physische Zerstörung der Medien. Wer Zugriff auf die Infrastruktur unterhalb des S3-Endpunkts besitzt, operiert an einer anderen Vertrauensgrenze.
Das ist keine Eigenheit einer bestimmten Implementierung, sondern gilt für jeden softwaredurchgesetzten Schutz. Es hat aber eine unmittelbare architektonische Konsequenz: Object Lock und administrative Isolation schützen nicht dieselbe Angriffsfläche und können einander deshalb nicht ersetzen. Wer nur den einen Mechanismus implementiert, lässt die jeweils andere Ebene offen.
Deshalb sollte eine Recovery-Architektur mindestens drei Ebenen getrennt untersuchen:
Ebene
Technische Frage
Data Plane
Kann die angebundene Anwendung vorhandene Objekte oder Versionen löschen beziehungsweise verändern?
Control Plane
Wer kann Retention, Policies, Accounts und Berechtigungen administrieren – und wer besitzt Zugriff auf die Infrastruktur unterhalb der S3-Schnittstelle?
Identity Plane
Von welchem Identitätssystem hängen diese administrativen Berechtigungen ab?
Cyber Resilience entsteht erst, wenn die Abhängigkeiten zwischen diesen Ebenen verstanden werden.
Der S3-Client selbst ist Teil des Threat Models
Ein häufig übersehener Angriffspfad liegt vor dem Object Storage.
Eine Backup-Software, ein Global File System oder eine andere Anwendung benötigt Credentials, um Objekte zu schreiben und später wieder zu lesen. Damit entsteht eine Vertrauensbeziehung:
text
Applikation
│
│ S3 Credentials
▼
S3 Endpoint
│
▼
Bucket
│
▼
Objekte / Versionen
Wird die Anwendung kompromittiert, muss davon ausgegangen werden, dass ein Angreifer möglicherweise auch auf die dort hinterlegten Credentials zugreifen kann. Entscheidend ist dann der tatsächliche Berechtigungsumfang.
Besitzt die Anwendung Rechte zum Schreiben neuer Objekte, zum Lesen vorhandener Objekte, zum Löschen von Objektversionen, zum Ändern von Retention, zum Setzen oder Entfernen eines Legal Hold oder zum Umgehen von Governance Retention, entstehen jeweils völlig unterschiedliche Angriffsmöglichkeiten.
Least Privilege ist deshalb auch beim Zugang eines Backup- oder Filesystems zum Object Storage ein Bestandteil der Recovery-Architektur.
Object Lock kann hier eine zusätzliche Grenze schaffen: Eine kompromittierte Anwendung kann unter geeigneter Konfiguration weiterhin schädliche neue Versionen schreiben, ohne deshalb bereits geschützte Versionen löschen zu können.
Das ist ein wesentlicher Unterschied zwischen Write Access und destruktiver Kontrolle über die Recovery-Historie.
Eine ergänzende Grenze bietet MFA Delete. Ist dieser Mechanismus aktiviert, erfordern das dauerhafte Löschen von Objektversionen sowie die Änderung des Versionierungszustands eines Bucketseine Mehrfaktor-Authentisierung. Damit reicht der Besitz von Credentials allein für die destruktivsten Operationen nicht mehr aus – ein Schutz, der gerade dann greift, wenn Zugangsdaten aus einer kompromittierten Anwendung abfließen.
Object Lock schützt Versionen – nicht automatisch die gesamte Recovery-Architektur
Selbst eine technisch nicht löschbare Objektversion löst nur einen Teil des Problems.
Ein vollständiger Service besteht häufig aus wesentlich mehr als den eigentlichen Nutzdaten:
text
Recovery
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Nutzdaten Metadaten Konfiguration
│
▼
Plattformdienste
│
▼
Identitäten
Ein Global File System kann beispielsweise Objekte im Object Storage speichern, während Namespace-Informationen, Policies, Konfigurationen oder andere Metadaten in separaten Plattformkomponenten beziehungsweise Datenbanken liegen.
Überleben nur die Object-Daten, folgt daraus nicht automatisch, dass daraus unmittelbar wieder ein funktionsfähiger File Service entsteht.
Deshalb müssen zwei Eigenschaften sauber unterschieden werden:
Data Survival – Die gespeicherten Nutzdaten haben den Angriff überstanden.
Service Recoverability – Aus den erhaltenen Daten, Metadaten, Konfigurationen und Plattformkomponenten kann wieder ein funktionierender Service aufgebaut werden.
Oder kürzer:
Data Survival ≠ Service Recovery
NIST betrachtet Recovery in SP 1800-11 entsprechend nicht ausschließlich als Wiederherstellung einzelner Dateien. Das Projekt untersucht die Wiederherstellung von Betriebssystemen, Datenbanken, Benutzerdateien, Anwendungen sowie Software- und Systemkonfigurationen und bezieht damit die gesamte Betriebsumgebung in das Recovery-Problem ein.
ASSISTRA-Praxiserfahrung: Die Daten überlebten – die Plattform nicht
Wie wichtig diese Unterscheidung ist, zeigte sich in einem von ASSISTRA begleiteten Ransomware-Fall.
Bei dem Angriff wurden große Teile der IT-Infrastruktur einschließlich der virtualisierten Plattform und vorhandener Backups zerstört. Die File-Daten und Dateiversionen eines Global File Systems befanden sich auf einem Ceph Object Storage. Diese Daten blieben erhalten.
Entscheidend ist jedoch, warum.
Zum Zeitpunkt des Angriffs bestand kein Object-Lock- oder WORM-Schutz. Die angebundene Plattform verfügte sogar über volle Rechte auf den Object Storage. Eine technisch erzwungene Immutability verhinderte die Löschung der Daten daher nicht.
Ein anderer Faktor erwies sich als entscheidend: Die administrativen Zugangsdaten des Object Storage waren nicht in das kompromittierte Active Directory integriert. Der Angriff erreichte diese administrative Domäne nicht.
Die Trennung war zu diesem Zeitpunkt allerdings nicht als gezielte Cyber-Resilience-Maßnahme geplant. Dass sie den Angriff überstand, war eine Eigenschaft der bestehenden Architektur, deren Bedeutung erst durch den Vorfall sichtbar wurde.
Aus einem einzelnen Ereignis lässt sich daraus nicht ableiten, dass administrative Trennung Object Lock ersetzt. Im Gegenteil: Da die angebundene Plattform volle Storage-Rechte besaß, existierte weiterhin ein möglicher destruktiver Zugriffspfad.
Bemerkenswert ist die Konstellation aus einem anderen Grund. Die administrative Trennung schützte genau jene Ebene, die Object Lock prinzipiell nicht schützen kann – den Zugriff unterhalb der S3-Schnittstelle. Wäre der Angriff in die administrative Domäne des Storage-Systems vorgedrungen, hätte auch eine aktivierte WORM-Retention die Daten nicht garantiert erhalten. Die beiden Schutzmechanismen adressieren komplementäre Angriffsflächen; in diesem Fall war zufällig diejenige abgedeckt, die technisch schwerer nachrüstbar ist.
Die Erfahrung zeigt damit:
Administrative Unabhängigkeit kann eine eigenständige Schutzschicht darstellen – sie ist aber kein Ersatz für technisch erzwungene Immutability, und Immutability ist kein Ersatz für administrative Unabhängigkeit.
Nach dem Vorfall wurde die zuvor zufällig vorhandene Trennung bewusst als Bestandteil der Schutzarchitektur etabliert.
Die zweite Erkenntnis war noch weitreichender
Obwohl die eigentlichen File-Daten erhalten geblieben waren, ließ sich der Dienst nicht einfach wieder einschalten.
Die virtualisierten Plattformserver waren ebenfalls zerstört worden. Damit fehlten Komponenten, die benötigt wurden, um aus den gespeicherten Daten wieder einen nutzbaren Service bereitzustellen. Eine separat vorhandene Kopie der erforderlichen Datenbank wurde für den Wiederaufbau entscheidend.
Der Vorfall machte damit zwei voneinander unabhängige Anforderungen sichtbar:
1. Die Daten müssen den Angriff überleben.
2. Die Plattform muss aus unabhängigen Informationen rekonstruierbar sein.
Eine Cyber-Recovery-Architektur, die ausschließlich die Nutzdaten immutable speichert, kann daher weiterhin eine kritische Abhängigkeit von zerstörbaren Metadaten- oder Managementsystemen besitzen.
„S3-kompatibel" ist keine Zusicherung identischer Security Semantics
Object Lock ist als S3-Funktion spezifiziert, aber nicht überall identisch implementiert. Zwischen S3-kompatiblen Systemen bestehen Unterschiede, die sicherheitstechnisch relevant sind.
Verbreitete S3-kompatible Plattformen stellen eine eigene Benutzerverwaltung vor dem darunterliegenden Storage bereit und unterstützen S3-Operationen für Object Retention und Legal Hold, üblicherweise mit den Modi GOVERNANCE und COMPLIANCE sowie einer auf Bucket-Ebene definierbaren Default Retention für neue Objekte. Die Übereinstimmung mit der AWS-Semantik ist damit jedoch nicht automatisch vollständig.
Abweichungen treten insbesondere an folgenden Stellen auf:
ob Object Lock nachträglich auf bestehenden Buckets aktiviert werden kann oder die Aktivierung bei der Bucket-Erstellung erfolgen muss,
ob beide Retention-Modi unterstützt werden oder nur ein Modus mit Compliance-ähnlicher Semantik,
wie der Governance Bypass berechtigt und angefordert wird,
welche administrativen Kommandos außerhalb der S3-Schnittstelle existieren,
wie sich Lifecycle-Regeln, Replikation und Tiering gegenüber geschützten Objektversionen verhalten,
welches Verhalten im Fehlerfall vorgesehen ist.
Für eine konkrete Architekturentscheidung muss deshalb die tatsächlich eingesetzte Produkt- und Softwareversion gegen die jeweilige Herstellerdokumentation geprüft werden. Der Funktionsumfang entwickelt sich zwischen Releases weiter – gerade die Frage der nachträglichen Aktivierbarkeit hat sich bei mehreren Implementierungen erst in neueren Ständen geändert.
S3-Kompatibilität beschreibt die Schnittstelle, nicht die Schutzwirkung.
Eine zweite Kopie ist nur dann unabhängig, wenn ihre Failure Domains unabhängig sind
Aus den bisherigen Mechanismen ergibt sich eine weitergehende Architekturfrage:
Wie unabhängig ist die Recovery-Ebene tatsächlich von der Produktionsumgebung?
Eine Architektur wie
text
Active Directory
│
├── Production Admin
├── Backup Admin
└── Object Storage Admin
besitzt einen gemeinsamen administrativen Failure Domain. Wird diese Identitätsdomäne vollständig kompromittiert und besitzen die übernommenen Identitäten ausreichende Rechte, können mehrere Schutzebenen gleichzeitig betroffen sein.
Eine stärker getrennte Architektur kann dagegen unterschiedliche administrative Vertrauensdomänen vorsehen:
text
Production Identity Domain
│
├── Produktionssystem
└── Backup / File Platform
│
│ eingeschränkte S3-Rechte
▼
Object Storage
▲
│
separate Administration
│
Recovery Trust Domain
Dabei geht es nicht darum, Active Directory grundsätzlich als ungeeignet darzustellen. Entscheidend ist die Korrelation administrativer Failure Domains. Werden mehrere vermeintlich unabhängige Schutzebenen letztlich von derselben kompromittierbaren Identität kontrolliert, ist ihre technische Unabhängigkeit geringer, als die physische oder logische Trennung zunächst vermuten lässt.
Air Gap und Immutability sind ebenfalls nicht dasselbe
Auch die Begriffe immutable und air-gapped sollten nicht synonym verwendet werden.
Object Lock kontrolliert, ob geschützte Objektversionen innerhalb ihrer Retention verändert oder gelöscht werden können. Ein Air Gap beschreibt dagegen eine Form der Isolation zwischen Systemen beziehungsweise Sicherheitsdomänen. Wie stark diese Isolation tatsächlich ist, hängt von der konkreten Architektur ab.
Ein über ein produktives Netzwerk erreichbarer S3-Bucket mit Object Lock kann immutable sein, ohne physisch vom Netzwerk getrennt zu sein. Umgekehrt ist eine isolierte Kopie nicht zwangsläufig immutable.
Die beiden Mechanismen adressieren unterschiedliche Angriffsmöglichkeiten:
Immutability → verhindert bestimmte Änderungen an gespeicherten Daten.
Isolation → reduziert beziehungsweise unterbricht Zugriffspfade.
Eine belastbare Architektur kann beide Prinzipien kombinieren.
Replikation erzeugt nicht automatisch eine unabhängige Kopie
Replikation besitzt primär eine andere Aufgabe: Sie hält Daten über Failure Domains hinweg verfügbar beziehungsweise dauerhaft vor. Werden jedoch schädliche Änderungen oder legitime Löschoperationen repliziert, kann eine zweite Instanz denselben logischen Zustand übernehmen.
Für Cyber Resilience muss deshalb zusätzlich gefragt werden:
Werden Löschoperationen repliziert?
Werden neue korrupte Versionen repliziert?
Sind ältere Versionen geschützt?
Gelten dieselben Credentials für Quelle und Ziel?
Besitzt dieselbe Administration Kontrolle über beide Systeme?
Können Retention Policies auf beiden Seiten verändert werden?
Ist die Recovery-Kopie unabhängig erreichbar und administrierbar?
Geografische Redundanz und Cyber-Isolation lösen unterschiedliche Probleme. Ein zweiter Standort schützt nicht automatisch vor einem Angriff, wenn derselbe kompromittierte administrative Kontext beide Standorte kontrolliert.
Retention erzeugt einen unvermeidbaren Trade-off
Immutability besitzt auch operative Konsequenzen.
Wenn eine Objektversion während einer festgelegten Retention nicht gelöscht werden darf, belegt sie auch dann Speicher, wenn sie aus Sicht der Anwendung nicht mehr benötigt wird. Da jede Version eine vollständige Kopie darstellt und keine Deltas gespeichert werden, addiert sich dieser Effekt bei änderungsintensiven Daten schnell auf ein Vielfaches der logischen Datenmenge.
Diese gebundene Kapazität ist nicht nur eine Kostenfrage. Sie bedeutet dauerhaft betriebene Kapazität mit entsprechender Leistungsaufnahme, Kühllast und Stellfläche über die gesamte Retention-Dauer. Eine Retention-Entscheidung ist damit auch eine Entscheidung über den Energiebedarf der Recovery-Ebene – ein Aspekt, der bei der Auslegung immutabler Repositories regelmäßig unterschlagen wird.
Längere Retention erhöht daher den Zeitraum, aus dem unveränderliche Versionen für eine Recovery verfügbar bleiben, verlängert aber gleichzeitig die Zeit, in der diese Daten nicht regulär gelöscht werden können.
Die Retention ist deshalb keine Einstellung nach dem Prinzip „je länger, desto besser". Sie muss unter anderem zum gewünschten Recovery-Fenster, zur erwarteten Zeit bis zur Angriffserkennung, zur Datenänderungsrate, zur Kapazitätsplanung, zum Lifecycle-Management, zu regulatorischen Löschpflichten und zu den vorgesehenen Recovery-Verfahren passen.
Bei einem spät erkannten Angriff ist eine zu kurze Retention problematisch: Die letzte vertrauenswürdige Version kann bereits außerhalb des geschützten Fensters liegen. Eine extrem lange Retention erzeugt dagegen Kapazitäts-, Energie- und Governance-Konsequenzen.
Die technische Frage lautet deshalb:
Wie lange muss eine garantiert nicht manipulierbare Version existieren, damit ein Angriff mit realistischer Detection Time noch recoverbar bleibt?
Was eine belastbare Object-Storage-Recovery-Ebene ausmacht
Aus den bisherigen Punkten lässt sich ein mehrschichtiges Modell ableiten.
text
┌─────────────────────────────────────────┐
│ 1. OBJECT IMMUTABILITY │
│ Versioning · Retention · Object Lock │
└──────────────────┬──────────────────────┘
│
┌──────────────────▼──────────────────────┐
│ 2. ACCESS SEPARATION │
│ Least Privilege · getrennte Credentials │
└──────────────────┬──────────────────────┘
│
┌──────────────────▼──────────────────────┐
│ 3. ADMINISTRATIVE ISOLATION │
│ getrennte administrative Trust Domain │
└──────────────────┬──────────────────────┘
│
┌──────────────────▼──────────────────────┐
│ 4. PLATFORM RECOVERABILITY │
│ Metadaten · DB · Config · Credentials │
└──────────────────┬──────────────────────┘
│
┌──────────────────▼──────────────────────┐
│ 5. VALIDATED RECOVERY │
│ sauberer Recovery Point · Restore-Test │
└─────────────────────────────────────────┘
Keine einzelne Ebene ersetzt die anderen.
Object Lock schützt nicht die Plattformdatenbank. Eine getrennte Administration macht ein löschbares Objekt nicht immutable. Eine intakte Kopie garantiert nicht, dass sie frei von bereits verschlüsselten Daten ist. Und ein technisch perfektes Repository hilft wenig, wenn niemand geprüft hat, wie daraus der eigentliche Service rekonstruiert wird.
Genau deshalb ist Cyber Resilience eine Ende-zu-Ende-Eigenschaft der Recovery-Architektur und keine einzelne Storage-Funktion.
Welche Fragen vor einer Architekturentscheidung beantwortet werden sollten
Bei der Bewertung eines Object Storage als Cyber-Recovery-Ebene sind nicht primär Produktnamen entscheidend. Wesentlicher ist das tatsächliche Berechtigungs- und Failure-Modell. Die folgenden Fragen bilden die fünf Ebenen ab.
Objekte und Retention (Ebene 1)
Ist Versioning aktiviert? Welche Objektversionen werden geschützt? Wird Retention automatisch gesetzt? Governance oder Compliance? Kann die Retention verkürzt oder umgangen werden?
Application Credentials (Ebene 2)
Welche Rechte besitzt die angebundene Backup-, File- oder Archivplattform? Kann sie nur neue Objekte schreiben oder auch Versionen permanent löschen und Retention verändern? Ist MFA Delete aktiviert?
Storage Administration und Identity Architecture (Ebene 3)
Wer kann Buckets, Policies, Benutzer und Retention konfigurieren? Wer besitzt Zugriff unterhalb der S3-Schnittstelle? Ist die Object-Storage-Administration von der produktiven Identitätsdomäne abhängig? Welche Konsequenzen hätte die vollständige Kompromittierung dieser Domäne?
Plattformabhängigkeiten (Ebene 4)
Welche Daten außerhalb des Object Storage werden benötigt, um die Anwendung wiederherzustellen? Wo liegen Datenbanken, Metadaten, Konfigurationen, Schlüssel und Credentials?
Recovery (Ebene 5)
Wie wird ein vertrauenswürdiger Recovery Point bestimmt? Wie wird geprüft, dass die ausgewählte Version nicht bereits kompromittiert ist? Wurde die vollständige Wiederherstellung tatsächlich getestet?
Erst aus den Antworten ergibt sich, ob ein Object Storage tatsächlich eine unabhängige Recovery-Ebene bildet.
Fazit
Immutable Object Storage kann eine wichtige letzte Recovery-Ebene bilden. S3 oder Object Storage allein erzeugen diese Eigenschaft jedoch nicht.
Eine belastbare Architektur muss mindestens Object Immutability, Retention, Application Permissions, administrative Isolation und die Wiederherstellbarkeit der Plattform gemeinsam betrachten. Object Lock wirkt an der S3-Schnittstelle; administrative Isolation wirkt unterhalb davon. Beide Mechanismen decken unterschiedliche Angriffsflächen ab und ersetzen einander nicht.
Der von ASSISTRA begleitete Ransomware-Fall verdeutlicht diese Trennung. Die File-Daten überlebten, obwohl keine WORM-Retention aktiviert war – entscheidend war, dass die Storage-Administration außerhalb des kompromittierten Active Directory lag. Gleichzeitig zeigte der Vorfall die Grenze dieser Betrachtung: Erhaltene Objekte waren noch kein wiederhergestellter Service.
Die entscheidende Architekturfrage lautet daher nicht:
„Unterstützt mein Object Storage S3 Object Lock?"
Sondern:
„Welche Daten, Identitäten, Berechtigungen und Plattformkomponenten müssen einen vollständigen Angriff überleben, damit wir aus einer vertrauenswürdigen Kopie tatsächlich wieder einen funktionierenden Service aufbauen können?"
Erst wenn diese Frage technisch beantwortet ist, wird aus immutable Object Storage eine echte Cyber-Recovery-Ebene.
Quellen
National Institute of Standards and Technology (NIST): Data Integrity: Recovering from Ransomware and Other Destructive Events, NIST Special Publication 1800-11, Final, September 2020.
National Institute of Standards and Technology (NIST): Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events, NIST Special Publication 1800-25, Final, Dezember 2020.
National Institute of Standards and Technology (NIST): Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events, NIST Special Publication 1800-26, Final, Dezember 2020.
Amazon Web Services: Locking objects with Object Lock – Amazon Simple Storage Service. Dokumentation zu Versioning, Retention Periods, Legal Hold sowie Governance- und Compliance-Modus. Abruf: 25.08.2026.
Amazon Web Services: Object Lock considerations – Amazon Simple Storage Service. Dokumentation zu Berechtigungen, s3:BypassGovernanceRetention und dem Header x-amz-bypass-governance-retention. Abruf: 25.08.2026.
Amazon Web Services: PutObjectRetention – Amazon S3 API Reference. Abruf: 25.08.2026.
Amazon Web Services: Amazon S3 now supports enabling S3 Object Lock on existing buckets, Ankündigung vom 20. November 2023.
Ceph Documentation: Ceph Object Gateway – S3 API; Object Operations (Put/Get Object Retention, Put/Get Object Legal Hold); Bucket Operations – Object Lock. Abruf: 25.08.2026.
Parkes, D. A.; D'Atri, A.: Ceph Object Storage Deep Dive Series Part 3: Version and Object Lock, ceph.io, 11. Dezember 2025. Referenz für die Durchsetzung von Object Lock auf S3-API-Ebene, MFA Delete sowie die nachträgliche Aktivierbarkeit von Object Lock auf bestehenden versionierten Buckets.
Welche Entscheidung steht bei Ihnen an?
Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.
Spezialist für moderne Dateninfrastruktur
