Was ist S3 Object Lock?

S3 Object Lock ist eine Funktion von Amazon S3 und S3-kompatiblem Objektspeicher, die verhindert, dass eine Objektversion für einen festgelegten Zeitraum – oder unbegrenzt – überschrieben oder gelöscht wird. Es ist der Mechanismus, mit dem die meisten Organisationen heute Daten wirklich unveränderlich machen, und er verwandelt gewöhnlichen Objektspeicher in ein konformes WORM-Archiv (write once, read many).

Zwei Konstruktionsentscheidungen erklären seine Stärke. Der Schutz gilt für eine einzelne Objektversion und nicht für einen Dateinamen, und er wird von der Speicherplattform erzwungen, nicht von der schreibenden Anwendung. Weil die Regel unterhalb der Anwendungsschicht liegt, können ein kompromittierter Backup-Server, ein bösartiges Skript oder ein Administrator mit vollen Zugangsdaten geschützte Daten nicht unbemerkt löschen.

Wie S3 Object Lock funktioniert

Object Lock setzt Versionierung voraus. Es lässt sich nur in Buckets mit aktivierter S3-Versionierung verwenden und schützt einzelne Objektversionen. Object Lock kann beim Anlegen eines Buckets aktiviert oder einem bestehenden Bucket hinzugefügt werden, sobald die Versionierung aktiv ist – die Entscheidung ist jedoch endgültig: Nach der Aktivierung kann Object Lock nicht mehr deaktiviert und die Versionierung nicht mehr ausgesetzt werden.

Ist der Bucket konfiguriert, wird die Aufbewahrung entweder beim Schreiben pro Objekt gesetzt oder über eine Standardaufbewahrung des Buckets in Tagen oder Jahren vorgegeben. Ab diesem Punkt ändert die Plattform ihr Verhalten bei Schreib- und Löschanfragen:

• Überschreiben erzeugt neue Versionen. Ein Schreibvorgang auf denselben Schlüssel ersetzt die geschützten Daten nicht, sondern legt eine zusätzliche Version daneben an.
• Versionsgenaues Löschen scheitert. Ein DELETE, das die gesperrte Versions-ID nennt, wird mit einem Zugriffsfehler abgewiesen.
• Einfaches Löschen erzeugt eine Löschmarkierung. Ein DELETE ohne Versions-ID ist erfolgreich und setzt eine Löschmarkierung, die zur aktuellen Version wird.

Dieses letzte Verhalten wird am häufigsten übersehen. Löschmarkierungen sind selbst nicht durch die Aufbewahrung geschützt. Ein Objekt kann also gelöscht erscheinen, während alle darunterliegenden gesperrten Versionen unversehrt und vollständig wiederherstellbar bleiben – das Objekt ist verborgen, nicht zerstört.

Compliance-Modus und Governance-Modus

Object Lock bietet zwei Aufbewahrungsmodi, und die Wahl zwischen ihnen ist die folgenreichste Einstellung.

Der Compliance-Modus ist absolut. Niemand kann eine gesperrte Objektversion vor ihrem Aufbewahrungsdatum löschen oder überschreiben – kein Administrator, nicht der Kontoinhaber, nicht der Root-Benutzer. Der Aufbewahrungszeitraum kann verlängert, aber niemals verkürzt oder entfernt werden. Dieser Modus ist die Wahl, wenn ein Prüfer die Gewissheit braucht, dass Aufzeichnungen tatsächlich nicht verändert werden können.

Der Governance-Modus gewährt denselben Schutz standardmäßig, lässt aber bewusst eine Hintertür: Ein Benutzer mit der Berechtigung zum Umgehen der Governance-Aufbewahrung, der die Umgehung ausdrücklich anfordert, kann die Aufbewahrung verkürzen oder die Version löschen. Das passt zu Teams, deren Hauptsorge versehentliches oder böswilliges Löschen ist und nicht die regulatorische Aufbewahrung, und die einen kontrollierten Weg brauchen, Fehler zu korrigieren.

In der Praxis nutzen viele Organisationen den Governance-Modus in Entwicklung und Test und reservieren den Compliance-Modus für Produktion und regulierte Daten, wo die Unmöglichkeit des Eingreifens gerade der Zweck ist.

Aufbewahrungszeiträume und Legal Hold

Object Lock bietet zwei unabhängige Steuerungen, und eine Objektversion kann die eine, die andere, beide oder keine tragen.

Ein Aufbewahrungszeitraum legt ein festes Aufbewahrungsdatum fest. Er wird üblicherweise von der schreibenden Anwendung gesetzt – Backup-Software etwa bestimmt die Aufbewahrung nach ihrer eigenen Richtlinie – oder von der Standardaufbewahrung des Buckets übernommen. Läuft der Zeitraum ab, endet der Schutz und die Version kann gemäß der üblichen Lifecycle-Richtlinie gelöscht werden.

Ein Legal Hold ist ein einfacher Ein/Aus-Schalter ohne Ablaufdatum. Er bleibt in Kraft, bis ihn jemand mit der passenden Berechtigung ausdrücklich entfernt – das richtige Werkzeug für Rechtsstreitigkeiten, Ermittlungen und Prüfungen, deren Dauer zu Beginn unbekannt ist. Da beide Steuerungen unabhängig sind, schützt ein Legal Hold eine Objektversion auch dann weiter, wenn ihr Aufbewahrungszeitraum längst abgelaufen ist.

Object Lock, WORM und Unveränderlichkeit

Diese drei Begriffe beschreiben denselben Schutz auf verschiedenen Ebenen. Unveränderlichkeit ist die Eigenschaft: Daten, die nicht geändert werden können. WORM (write once, read many) ist das Speichermodell, das sie liefert. Object Lock ist der konkrete API-Mechanismus, der die WORM-Aufbewahrung auf einzelne Objekte in S3-kompatiblem Speicher anwendet. Object Lock ist die Art, WORM einzuschalten; WORM ist die Art, Unveränderlichkeit zu erreichen.

Es lohnt sich, Object Lock von Kontrollen abzugrenzen, die ihm ähneln, aber nicht gleichwertig sind. Bucket-Richtlinien und IAM-Deny-Regeln können Löschvorgänge blockieren, sind aber Konfiguration – ein ausreichend privilegierter Administrator kann sie ändern. Object Lock im Compliance-Modus kann niemand ändern. Snapshots, Versionierung allein und Air-Gap-Kopien sind ergänzende Schutzmaßnahmen, kein Ersatz: Versionierung bewahrt die Historie, erlaubt aber das endgültige Löschen von Versionen – genau die Lücke, die Object Lock schließt.

S3 Object Lock und ARTESCA

Scality ARTESCA setzt S3 Object Lock im Governance- und im Compliance-Modus um, samt Aufbewahrungszeiträumen und Legal Hold. Auf ARTESCA geschriebene Backup- und Archivdaten sind damit vom ersten Moment an unveränderlich. Die Aufbewahrung wird auf der Speicherebene erzwungen und kann von einem kompromittierten Administratorkonto nicht abgeschaltet werden.

Sicherheit ist eingebaut statt nachgerüstet: architektonische Unveränderlichkeit, ein gehärtetes Betriebssystem und durchgängige Cyber-Resilienz-Kontrollen umgeben jedes Objekt und erweitern den Object-Lock-Schutz über den gesamten Datenpfad.

ARTESCA ist mit den führenden Backup-Plattformen validiert – darunter Veeam, Commvault und Rubrik –, die die Object-Lock-Aufbewahrung beim Schreiben automatisch setzen. Das Ergebnis ist ein konformes, ransomware-resilientes unveränderliches Speicherziel, das sich auf Standardservern installieren lässt.

Häufige Fragen zu S3 Object Lock

Setzt S3 Object Lock Versionierung voraus?

Ja. Object Lock funktioniert nur in Buckets mit aktivierter S3-Versionierung, denn der Schutz gilt für einzelne Objektversionen und nicht für Dateinamen.

Kann S3 Object Lock abgeschaltet werden?

Nicht auf Bucket-Ebene. Nach der Aktivierung kann Object Lock nicht mehr deaktiviert und die Versionierung nicht mehr ausgesetzt werden. Eine im Governance-Modus gesetzte Aufbewahrung kann ein besonders berechtigter Benutzer umgehen; eine im Compliance-Modus gesetzte kann niemand umgehen.

Kann ein gesperrtes Objekt trotzdem gelöscht werden?

Eine Löschanfrage, die die gesperrte Versions-ID nennt, wird abgewiesen. Eine Anfrage ohne Versions-ID ist erfolgreich und setzt eine Löschmarkierung – das Objekt erscheint gelöscht, während alle geschützten Versionen unversehrt und wiederherstellbar bleiben.

Was unterscheidet Compliance- und Governance-Modus?

Der Compliance-Modus lässt keine Ausnahmen und keine Verkürzung der Aufbewahrung zu, auch nicht für den Kontoinhaber. Der Governance-Modus erlaubt Benutzern mit Umgehungsberechtigung, die Aufbewahrung zu verkürzen oder eine gesperrte Version zu löschen, wenn sie es ausdrücklich anfordern.

Ist S3 Object Lock dasselbe wie WORM?

Object Lock ist der Mechanismus, WORM das Modell, das er umsetzt. Erst das Aktivieren der Object-Lock-Aufbewahrung lässt S3-kompatiblen Speicher wie ein WORM-Archiv arbeiten.