Inhaltsverzeichnis

Besonders deutlich wird die notwendige Trennung beim Backup. Ein Backup-Bucket benötigt typischerweise Versioning, Object Lock, eine definierte Retention, eingeschränkte Delete-Rechte, separate Credentials und getrennte administrative Zuständigkeiten, während ein Bucket für temporäre Analytics-Ergebnisse möglicherweise keine dieser Eigenschaften braucht. 

S3 Object Lock basiert im AWS-Modell auf Versioning und schützt einzelne Objektversionen über Retention Periods oder Legal Holds, wobei zwei Modi zu unterscheiden sind. Im Governance Mode können privilegierte Identitäten die Retention umgehen; erforderlich sind dafür die Berechtigung s3:BypassGovernanceRetention und ein expliziter Request-Header, der das Umgehen anfordert. Im Compliance Mode kann eine geschützte Objektversion während der Retention dagegen von keinem Benutzer überschrieben oder gelöscht werden, einschließlich des Root Users des Accounts. Der Retention Mode ist dann nicht mehr änderbar und die Retention Period nicht verkürzbar, und Amazon dokumentiert, dass die einzige Möglichkeit, ein solches Objekt vor Ablauf zu entfernen, die Löschung des zugehörigen Accounts ist. 

Diese Unterscheidung ist für Cyber-Resilience-Architekturen wesentlich, und sie hat eine unmittelbare Betriebsfolge: Der Compliance Mode schützt auch vor der eigenen Organisation, einschließlich fehlerhaft gesetzter Retention-Werte. Praktisch relevant ist außerdem die Nachrüstbarkeit. Amazon erlaubt seit November 2023, Object Lock auf bestehenden Buckets zu aktivieren, und bestehende Objekte lassen sich anschließend über Batch-Operationen mit Retention-Parametern versehen. Diese Eigenschaft ist, wie sich weiter unten zeigt, nicht bei jeder S3-kompatiblen Implementierung gegeben. 

Neben dem Schutz steht die Frage des Lebenszyklus. Bei großen Object-Storage-Umgebungen muss nicht nur festgelegt werden, wo Daten gespeichert werden, sondern auch, wie lange sie dort verbleiben. Lifecycle-Regeln können anhand von Alter, Präfix oder Tags Aktionen auslösen, wobei Amazon S3 zwei Aktionstypen unterscheidet: Transition Actions verschieben Objekte in eine andere Storage Class, Expiration Actions löschen abgelaufene Objekte. Damit lässt sich der Lebenszyklus eines Objekts prinzipiell als Policy beschreiben, die von der Erzeugung über einen aktiven und einen selten genutzten Zustand bis zu Archivierung und Ablauf führt. Welche dieser Zustände tatsächlich zur Verfügung stehen, hängt vom jeweiligen Storage-Service ab. Lifecycle Management ist damit nicht lediglich eine Kostenfunktion, sondern Bestandteil der Datenarchitektur, denn eine Backup-Datei, ein revisionsrelevantes Archivobjekt und ein temporäres Analytics-Ergebnis besitzen typischerweise unterschiedliche Lebenszyklen. 

Eine dritte Abgrenzung betrifft die Versionierung. S3 Versioning kann mehrere Versionen eines Objekts innerhalb eines Buckets aufbewahren und erlaubt so die Wiederherstellung nach versehentlichem Überschreiben oder Löschen. Versioning ist deshalb ein wichtiger Data-Protection-Mechanismus, aber kein vollständiges Backup-Konzept, denn die Versionen verbleiben zunächst innerhalb derselben Storage- und administrativen Umgebung. Anforderungen an unabhängige Recovery Copies, separate Failure Domains oder getrennte administrative Trust Domains müssen zusätzlich betrachtet werden. Dasselbe gilt für Replikation: Weder Replikation noch Versionierung ersetzen ein Backup, auch wenn beide Bestandteile einer Data-Protection-Architektur sein können. 

Beide Datenklassen – geschützter Langzeitbestand und flüchtiges Zwischenergebnis – identisch zu konfigurieren würde den Vorteil einer gemeinsamen Plattform wieder reduzieren. Die tragfähige Abstraktion lautet daher: gemeinsame Infrastruktur, unterschiedliche Data Policies.