S3 Object Lock: die Kopie, die sich nicht löschen lässt – WORM, Retention und Anti-Ransomware

WebDisk Blog · Kategorie: Sicherheit · Lesezeit: ~12 Minuten

Kurz gefasst:- S3 Object Lock verwandelt den Objektspeicher in WORM (write once, read many): Eine gespeicherte Datei lässt sich lesen, aber für den festgelegten Zeitraum kann keine S3-Anfrage – auch nicht die eines Administrators oder Kontoinhabers – sie ändern oder löschen.- Das ist heute die grundlegende Verteidigung von Backups gegen Ransomware, die Backups routinemäßig löscht, bevor sie die Produktion verschlüsselt.- In WebDisk Files heißt dieser Mechanismus Anti-Ransomware: Sie aktivieren ihn mit einem Schalter am Speicher und erhalten einen Speicher der WORM-Klasse für Ihre Backups. >Sie arbeiten nicht mit dem Terminal? Überspringen Sie die Codebeispiele – die Beschreibung des Mechanismus und der Abschnitt über WebDisk vermitteln das vollständige Bild.

Ein moderner Ransomware-Angriff beginnt selten mit der Verschlüsselung. Ein Angreifer, der Zugriff auf die Infrastruktur erlangt hat, verbringt darin zunächst Tage oder Wochen – und sucht in dieser Zeit methodisch nach Backups. Er löscht sie, verschlüsselt sie oder beschädigt sie im Stillen. Erst wenn das Opfer nichts mehr hat, worauf es zurückgreifen könnte, startet er die eigentliche Verschlüsselung und stellt die Lösegeldforderung. Die Logik ist brutal einfach: ein Unternehmen mit funktionierendem Backup zahlt nicht.

Die Lehre aus Tausenden solcher Vorfälle lautet: Ein Backup, das sich mit denselben Berechtigungen löschen lässt, mit denen es geschrieben wurde, ist kein Schutz – es ist die Illusion von Schutz. Gebraucht wird eine Kopie, die weder ein Angreifer mit gestohlenen Schlüsseln löschen kann noch ein fehlbares Skript, noch – was am schwersten zu akzeptieren ist – wir selbst an einem schlechten Tag. In der S3-Welt leistet genau das Object Lock. In diesem Artikel erklären wir, wie er funktioniert, zeigen Anwendungsbeispiele und beschreiben, wie wir darauf die Funktion Anti-Ransomware in WebDisk Files aufgebaut haben.

Was ist WORM und woher kommt es?

WORM (write once, read many – „einmal schreiben, viele Male lesen“) ist ein seit Jahrzehnten bekanntes Konzept. Das vertrauteste Beispiel ist die CD-R: Einmal gebrannte Inhalte lassen sich beliebig oft lesen, aber weder überschreiben noch löschen – die Physik des Mediums lässt es schlicht nicht zu. Banken und Archive nutzen seit Jahren WORM-Medien und -Arrays überall dort, wo das Gesetz verlangt, dass Aufzeichnungen unangetastet bleiben: Transaktionsregister, medizinische Dokumentation, aufsichtspflichtige Korrespondenz.

S3 Object Lock überträgt diese Garantie auf den Objektspeicher – ohne Spezialhardware. Die Sperre wird von der Speicherschicht selbst durchgesetzt: Eine Anfrage, eine geschützte Objektversion zu löschen oder zu überschreiben, wird abgelehnt, unabhängig davon, wer sie mit welchen Berechtigungen gesendet hat. Das ist der entscheidende Unterschied zu gewöhnlichen Berechtigungen (IAM-Richtlinien): Eine Richtlinie kann jemand mit entsprechendem Zugriff ändern – eine WORM-Sperre im Compliance-Modus kann keine S3-Anfrage aufheben.

Warum erfordert Object Lock Versionierung?

Object Lock arbeitet nicht im luftleeren Raum – er erfordert die Versionierung des Buckets (Bucket – ein Behälter für Dateien im S3-Speicher, das Gegenstück zu einem Laufwerk oder einer Freigabe; in den WebDisk-Diensten nennen wir ihn Speicher). Versionierung sorgt dafür, dass der Speicher niemals etwas an Ort und Stelle überschreibt: Jeder Schreibvorgang unter einem bestehenden Namen erzeugt eine neue Version des Objekts, die vorherigen bleiben erhalten. Auch das „Löschen“ einer Datei in einem versionierten Bucket entfernt keine Daten – es fügt lediglich eine Löschmarkierung (Delete Marker) hinzu, unter der sich ältere Versionen jederzeit wieder hervorholen lassen.

Erst auf diesem Fundament ergibt die Sperre Sinn, denn Object Lock schützt konkrete Objektversionen. Eine praktische Konsequenz, die man verstehen sollte: Das Schreiben neuer Inhalte unter demselben Namen wird nicht blockiert – es entsteht einfach eine weitere Version. Die geschützte Version liegt unversehrt daneben. Bildlich:

Datei „raport.pdf“ in einem Bucket mit Object Lock:

  [Löschmarkierung] ← die Datei ist aus dem Listing „verschwunden“…
  v2 Ransomware-Zugriff ← …der „überschreibende“ Müll landete DANEBEN, nicht an ihrer Stelle
  v1 🔒 Compliance bis 1.11. ← das Original: unantastbar, bereit zur Wiederherstellung

Ransomware kann Ihre Dateien also mit verschlüsseltem Müll „überschreiben“ und aus dem Listing „löschen“ – aber die originalen, gesperrten Versionen überstehen das, und Sie werden zu ihnen zurückkehren können.

Governance, Compliance oder Legal Hold – worin unterscheiden sie sich?

Eine Versionssperre lässt sich auf zwei Arten und in zwei Modi setzen – und diese Unterscheidungen sind der wichtigste technische Teil dieses Artikels.

Retention (Aufbewahrung) – eine Sperre auf Zeit: Die Version trägt ein Datum retain-until-date, vor dem sie weder gelöscht noch geändert werden kann. Das Datum lässt sich direkt beim Schreiben des Objekts setzen, oder man konfiguriert eine Standard-Retention des Buckets (z. B. „jedes neue Objekt: 90 Tage“) – dann greift der Schutz automatisch für alles, ohne Mitwirkung des schreibenden Tools.

Retention-Modi:

• Governance – eine Sperre mit Hintertür: Gewöhnliche Benutzer können nichts tun, aber ausgewählte Benutzer mit einer speziellen Berechtigung (s3:BypassGovernanceRetention) können die Sperre verkürzen oder aufheben. Gut zum Einspielen von Prozessen und für Testphasen: Sie schützt vor Versehen, aber nicht vor einem Angreifer, der ein privilegiertes Konto übernimmt.
• Compliance – eine Sperre ohne Hintertür in der S3-Schicht: bis zum Ablauf des Retention-Datums kann keine S3-Anfrage die Version löschen – unabhängig davon, ob sie der Kontoinhaber, der Administrator der Organisation oder ein Angreifer mit übernommenem privilegiertem Konto sendet. Der Zeitraum lässt sich ausschließlich verlängern, niemals verkürzen. Das ist der richtige Modus für den Schutz vor Ransomware und für rechtliche Anforderungen. (Außerhalb der S3-Schicht bleibt bei jedem Anbieter höchstens eine streng kontrollierte, auditierte Betreiberprozedur – wie sie bei uns aussieht, beschreiben wir offen im FAQ.)
• Legal Hold – eine unbefristete Sperre, unabhängig von der Retention: ein Schalter „alles anhalten bis auf Widerruf“ an einer einzelnen Version. Es gibt kein Enddatum; aufgehoben wird sie durch die bewusste Entscheidung einer Person mit entsprechender Berechtigung. Verwendet wird sie, wenn ein Rechtsstreit oder eine Ermittlung läuft und die Daten nicht angerührt werden dürfen, bis die Sache abgeschlossen ist.

Der Vergleich in Kürze:

• Dauer – Governance: bis zum Retention-Datum · Compliance: bis zum Retention-Datum · Legal Hold: bis auf Widerruf
• Verkürzen/Aufheben möglich? – Governance: ja, mit spezieller Berechtigung · Compliance: nein – durch keine S3-Anfrage · Legal Hold: ja, mit der Legal-Hold-Berechtigung
• Verlängern möglich? – Governance: ja · Compliance: ja (nur verlängern) · Legal Hold: entfällt
• Typischer Einsatz – Governance: interne Prozesse, Tests · Compliance: Ransomware, rechtliche Anforderungen · Legal Hold: Gerichtsverfahren, Ermittlungen

Selbst ausprobieren: WORM im Terminal

Bevor Sie beginnen. Die Beispiele verwenden die aws CLI, konfiguriert wie in den vorherigen Artikeln dieser Serie (aws configure + --endpoint-url Ihres Anbieters – wir lassen ihn unten der Lesbarkeit halber weg). Vorsicht mit echten Daten: Compliance-Sperren lassen sich nicht rückgängig machen – deshalb verwenden alle Übungen unten eine Retention von 1 Tag und einen Test-Bucket; Produktionswerte zeigen wir in den Kommentaren.

Object Lock wird beim Erstellen des Buckets aktiviert (zum Nachrüsten eines bestehenden – siehe FAQ):

# 1. Bucket mit aktiviertem Object Lock (Versionierung wird automatisch aktiviert)
aws s3api create-bucket --bucket backup-worm \
  --object-lock-enabled-for-bucket

# 2. Standard-Retention Compliance — ACHTUNG: Dieser Schritt ist in seinen Folgen unumkehrbar,
# jedes neue Objekt wird für den festgelegten Zeitraum unantastbar sein
aws s3api put-object-lock-configuration --bucket backup-worm \
  --object-lock-configuration \
  '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":1}}}'
# zum Üben: 1 Tag · in der Produktion für Backups: {"Mode":"COMPLIANCE","Days":90}

# 3. gewöhnlicher Upload — der Schutz greift von selbst, das Backup-Tool
# muss nichts über Object Lock wissen
aws s3 cp backup-2026-08-02.tar.gz s3://backup-worm/

Von diesem Moment an ist jede gespeicherte Version für den festgelegten Zeitraum unantastbar. Prüfen wir das:

# Metadaten der Version: Sperrmodus und Datum, bis zu dem sie gilt
aws s3api head-object --bucket backup-worm --key backup-2026-08-02.tar.gz
# "ObjectLockMode": "COMPLIANCE",
# "ObjectLockRetainUntilDate": "...",

# Versuch, die geschützte Version dauerhaft zu löschen
aws s3api delete-object --bucket backup-worm \
  --key backup-2026-08-02.tar.gz --version-id "<versions-id>"
# → AccessDenied — und genau darum geht es

Und was ist mit dem gewöhnlichen aws s3 rm, ohne Angabe einer Version? Es funktioniert „erfolgreich“ – und das ist kein Loch im Schutz:

aws s3 rm s3://backup-worm/backup-2026-08-02.tar.gz
# Erfolg — aber das ist nur die Löschmarkierung aus dem Abschnitt über Versionierung!

aws s3api list-object-versions --bucket backup-worm
# die geschützte Version existiert weiter unter der Markierung — die Daten sind unangetastet

Die Datei ist aus dem Listing verschwunden, aber nicht aus dem Speicher; die Wiederherstellung besteht darin, die Markierung zu entfernen oder die Version über ihre ID abzurufen.

Der Schutz einer einzelnen Version lässt sich auch explizit beim Schreiben setzen (ein so gesetztes Datum hat Vorrang vor der Standard-Retention des Buckets) oder nachträglich – wohlgemerkt: Im Compliance-Modus geht es nur in eine Richtung:

# explizite Sperre beim Schreiben (zum Üben: Datum einen Tag voraus;
# in der Produktion z. B. ein Jahr: 2027-08-02)
aws s3api put-object --bucket backup-worm --key raport-roczny.pdf \
  --body raport-roczny.pdf \
  --object-lock-mode COMPLIANCE \
  --object-lock-retain-until-date "2026-08-03T00:00:00Z"

# Verlängerung des Schutzes einer bestehenden Version (Verkürzung → Ablehnung)
aws s3api put-object-retention --bucket backup-worm --key raport-roczny.pdf \
  --version-id "<versions-id>" \
  --retention '{"Mode":"COMPLIANCE","RetainUntilDate":"2026-08-04T00:00:00Z"}'

# Legal Hold: anhalten bis auf Widerruf (unabhängig von Retention-Daten)
aws s3api put-object-legal-hold --bucket backup-worm --key raport-roczny.pdf \
  --legal-hold '{"Status":"ON"}'

Retention heißt nicht nur Sperren – sondern auch Aufräumen

Eine Retention-Richtlinie hat zwei Seiten. Die erste sagt: „nicht löschen vor Ablauf der Frist“. Die zweite – ebenso wichtige – sagt: „nach Ablauf der Frist automatisch löschen“. Diese zweite Seite übernehmen die Lifecycle-Regeln des Speichers. Im Zusammenspiel mit Object Lock ergibt das einen selbstreinigenden WORM-Speicher: Die Kopien sind während der Schutzfrist unantastbar und verschwinden nach deren Ablauf von selbst – ohne Skripte, ohne Cron, ohne manuelles Durchsehen. Eine aktive Sperre respektiert die Lifecycle-Regel dabei: Eine geschützte Version wird nicht vor ihrem Retention-Datum gelöscht.

Um das Beispiel aus dem vorherigen Abschnitt abzurunden – das Aufräumen der Versionen, abgestimmt auf die 90-tägige Produktions-Retention:

aws s3api put-bucket-lifecycle-configuration --bucket backup-worm \
  --lifecycle-configuration '{
    "Rules": [{
      "ID": "sprzataj-po-ochronie",
      "Status": "Enabled",
      "Filter": {},
      "Expiration": { "Days": 90 },
      "NoncurrentVersionExpiration": { "NoncurrentDays": 90 }
    }]
  }'

Eine gut eingestellte Retention ist immer ein Kompromiss: Eine zu kurze schützt nicht vor einem Angreifer, der geduldig wartet (der Einbruch liegt oft lange vor der Verschlüsselung); eine zu lange vervielfacht die Speicherkosten und kann mit Löschpflichten kollidieren (dazu im FAQ). Für Backups ist ein vernünftiges Minimum an unveränderlichem Schutz etwa 90 Tage – plus längere, seltenere Archivkopien.

Was löst Object Lock NICHT?

• Compliance heißt Compliance. Ein Fehler wirkt in beide Richtungen: Wenn Sie 10 TB Müll für 7 Jahre sperren, werden Sie sie 7 Jahre lang aufbewahren (und bezahlen). Es gibt keinen Knopf „ausnahmsweise löschen“ – Ausnahmen von der Unlöschbarkeit beschränken sich auf streng geregelte, in den Nutzungsbedingungen des Dienstes beschriebene Situationen. Retention setzt man mit Bedacht, und Tests macht man mit kurzen Zeiträumen.
• Versionen kosten. Ein Speicher mit Versionierung und Retention bewahrt alles auf, was während der Schutzfrist geschrieben wurde – auch die von Ransomware „überschriebenen“ Versionen. Das ist der Preis der Garantie; kalkulieren Sie beim Budgetieren eines WORM-Backups: Kapazität × Anzahl der Kopien im Retention-Fenster.
• Die Sperre schützt die Integrität, nicht die Vertraulichkeit. Ein Angreifer mit Zugriff kann die Daten weiterhin lesen und stehlen. Davor schützen Verschlüsselung (wir schrieben über SSE in dieser Serie), Zugriffskontrolle und kurzlebige Zugangsdaten (siehe unseren Text über STS).
• WORM ersetzt keine Backup-Grundsätze. Eine unveränderliche Kopie in einem einzigen Speicher ist immer noch nur eine Kopie. Die 3-2-1-Regel (drei Kopien, zwei Medien, eine außer Haus) gilt weiterhin – Object Lock härtet eines ihrer Glieder.
• Neue Schreibvorgänge werden nicht blockiert. Object Lock fixiert bestehende Versionen; er hält niemanden davon ab, dem Bucket immer neue Objekte hinzuzufügen. Limits, Quoten und Schreib-Monitoring sind eine eigene Schicht.

Wie funktioniert Anti-Ransomware in WebDisk Files?

In WebDisk Files ist der gesamte beschriebene Mechanismus in eine einzige Funktion mit eindeutigem Namen verpackt: Anti-Ransomware. Sie arbeitet auf der Ebene eines zusätzlichen Speichers (Buckets) und wird per Schalter aktiviert – mit einer Schutzfrist von 90 Tagen bis 7 Jahren (das Minimum sind bewusst 90 Tage: Einbrüche gehen der Verschlüsselung um Wochen voraus, ein kürzerer Schutz ist oft eine Illusion):

• Unter der Haube ist das einfach S3 Object Lock im Compliance-Modus: Jede Version jeder Datei im Speicher ist bis zum Ablauf der Schutzfrist unveränderbar und unlöschbar. Die Garantie wird von der Speicherschicht durchgesetzt, nicht von der Anwendung – sie bleibt in Kraft, selbst bei einer Kompromittierung der Anwendung selbst oder des Administratorkontos der Organisation. Genau um dieses Modell geht es beim Schutz vor Ransomware.
• Die Entscheidung ist eine Einbahnstraße – und wir sagen das ganz offen: Ein Speicher mit aktiviertem Anti-Ransomware lässt sich nicht „entsperren“, und die Schutzfrist seiner Inhalte lässt sich nicht verkürzen. Der Speicher lässt sich auch nicht löschen, solange er irgendwelche Versionen schützt. Das ist keine Einschränkung, die wir zu umgehen versuchen – das ist der Kern des Produkts.
• Ergänzend dazu gibt es die Auto-Rotation: eine Aufbewahrungsregel, die alte Objekte nach Ablauf des festgelegten Zeitraums dauerhaft löscht – umgesetzt über Lifecycle-Richtlinien auf Speicherseite, ohne jeglichen Cron auf Anwendungsseite. Bei einem Speicher mit Anti-Ransomware entspricht der Rotationszeitraum der Schutzfrist (die Dateien verschwinden genau mit dem Ende des Schutzes); bei einem gewöhnlichen Speicher wählen Sie den Zeitraum selbst. In Kombination ergibt das den erwähnten selbstreinigenden WORM-Speicher.
• Die Funktion hat eine Datenschutz-Folgenabschätzung durchlaufen (DPIA, DSGVO Art. 35) – denn die Unlöschbarkeit von Daten muss mit dem Recht auf ihre Löschung in Einklang gebracht werden; die Schutzfrist wird daher bewusst passend zum Charakter der Daten gewählt. Das Dokument stellen wir B2B-Kunden auf Wunsch zur Verfügung – als Input für ihre eigenen Folgenabschätzungen.

Das Einsatzszenario, für das wir das gebaut haben, ist einfach: ein sicheres Backup-Ziel der WORM-Klasse. Geben Sie einen Anti-Ransomware-Speicher als Ziel Ihrer Backups an – über S3 (jedes Backup-Tool, das nach S3 schreibt – den Schutz übernimmt die Standard-Retention des Buckets, das Tool muss von Object Lock überhaupt nichts wissen), über die Web-App oder die Desktop-App. Jede Kopie, die Sie speichern, wird automatisch unantastbar. Auch die Backups der Schlüsselkomponenten unserer eigenen Plattform bewahren wir in WORM-Speichern mit S3 Object Lock auf.

Hinweis für Nutzer von Tools mit nativer Object-Lock-Unterstützung (z. B. Veeam): Solche Software verwaltet die Retention pro Objekt selbst und benötigt gemäß den Anforderungen des Herstellers einen Bucket mit aktiviertem Object Lock, aber ohne Standard-Retention und ohne Lifecycle-Regeln – die Integrationsdokumentation warnt, dass Standard-Sperren auf dem Bucket zu unvorhersehbarem Datenverlust führen können. Der Anti-Ransomware-Speicher (mit erzwungener Compliance-Retention und Auto-Rotation) ist für Tools konzipiert, die von Object Lock nichts wissen; für Veeam und ähnliche Tools wird ein separat konfigurierter, den Herstellervorgaben entsprechender Bucket benötigt – schreiben Sie uns, wir helfen Ihnen.

Die ergänzenden Schichten in Files kennen Sie bereits aus den vorherigen Artikeln der Serie: Dateiversionierung, Verschlüsselung im Ruhezustand (SSE-S3 pro Speicher, SSE-C pro Organisation) und Zugriffskontrolle. Object Lock schließt dieses Set auf der Integritätsseite ab: Selbst wenn alles andere versagt, existiert die Kopie von vor dem Angriff – und aus ihr lässt sich zurückkehren.

Häufige Fragen

Kann ich WebDisk bitten, eine Datei vor Ablauf des Schutzes aus dem Anti-Ransomware-Speicher zu löschen? Mit keiner S3-Operation, nicht über das Panel und nicht „auf Zuruf“ – nein. Die Sperre wird von der Speicherschicht durchgesetzt, und weder der Administrator Ihrer Organisation noch ein Angreifer mit gestohlenen Schlüsseln noch unser Support kann sie aufheben. Ausnahmen beschränken sich auf streng geregelte, auditierte, in den Nutzungsbedingungen des Dienstes vorgesehene Situationen – etwa die Erfüllung rechtlicher Pflichten – und sie lassen sich weder leise noch aus der Ferne noch mit kompromittierten S3-Schlüsseln auslösen. Für das Ransomware-Szenario bedeutet das: keine Hintertür.

Ich habe mich vertan und Daten zu lange gesperrt. Was nun? In der S3-Schicht – nichts; die Daten bleiben bis zum Ablauf der Retention. Deshalb: Testen Sie neue Richtlinien mit kurzen Zeiträumen und in einem separaten Bucket, setzen Sie die Standard-Retention vorsichtig, und reservieren Sie sehr lange Zeiträume für Daten, bei denen Sie sich sicher sind. Der Governance-Modus existiert genau dafür, die Prozesse einzuspielen, bevor Sie auf Compliance umschalten.

Kann Ransomware Dateien in einem Speicher mit Object Lock verschlüsseln? Sie kann höchstens verschlüsselte Versionen neben den geschützten ablegen – die Originale bleiben unangetastet und wiederherstellbar. Sie kann sie weder an Ort und Stelle überschreiben noch löschen. Die Wiederherstellung läuft darauf hinaus, die Version von vor dem Angriff zurückzuholen.

Lässt sich Object Lock auf einem bestehenden Bucket aktivieren? Das hängt von Plattform und Version ab: AWS erlaubt das Nachrüsten eines bestehenden Buckets, in Ceph RGW ermöglichen das erst die neuesten Releases – hier zählt die Version, auf der Ihr Anbieter läuft. In Files lösen wir das direkt: Anti-Ransomware aktivieren Sie beim Anlegen des Speichers (das kann auch ein bestehender, leerer Speicher sein); für einen Speicher mit Daten legen Sie einen neuen geschützten an und kopieren die Daten dorthin.

Was passiert mit dem Anti-Ransomware-Speicher, wenn ich mein Konto schließe? Der Schutz verschwindet nicht mit dem Konto: Der Speicher lässt sich nicht löschen, solange er irgendwelche Versionen schützt; seine Löschung wird also eingeplant und erst nach Ablauf der Schutzfrist ausgeführt. Die Abrechnungsregeln für diesen Zeitraum finden Sie in den Nutzungsbedingungen des Dienstes – berücksichtigen Sie die Schutzfrist bei der Entscheidung über ihre Länge.

Wie verträgt sich WORM mit der DSGVO und dem Recht auf Löschung? Durch die bewusste Wahl von Umfang und Zeitraum. In den WORM-Speicher gehören Backups und Archive, nicht der tägliche Umlauf personenbezogener Daten; die Schutzfrist wird so gewählt, dass sie das Ransomware-Risiko mit den Löschpflichten ausbalanciert. In Files hat die Funktion genau deshalb eine DPIA (DSGVO Art. 35) durchlaufen, damit diese Abwägung dokumentiert ist – und Grenzfälle wie die Erfüllung rechtlicher Pflichten werden in dem in den Nutzungsbedingungen des Dienstes vorgesehenen Verfahren behandelt.

Governance oder Compliance – womit anfangen? Wenn Sie Ihren Backup-Prozess gerade erst aufbauen: Governance für die Zeit des Einspielens der Prozeduren (schützt vor Versehen, erlaubt Aufräumen), danach Compliance für die Produktions-Backups. Wenn das Ziel der Schutz vor Ransomware oder eine rechtliche Anforderung ist – am Ende immer Compliance; die Governance-Hintertür ist genau das, was ein übernommenes privilegiertes Konto ausnutzen kann.

Fazit

Object Lock kehrt die übliche Berechtigungslogik um: Statt zu überwachen, wer Daten löschen darf, sorgt er dafür, dass es für die festgelegte Zeit niemand kann – mit keiner S3-Anfrage. Drei Dinge sollten Sie sich merken:

• das Fundament ist die Versionierung – die Sperre schützt Versionen, vom Angreifer „überschriebene“ Dateien haben also unangetastete Originale,
• Compliance ist eine Garantie ohne Hintertür in der S3-Schicht, unwiderruflich auch für unseren Support – deshalb wählt man die Retention mit Bedacht, und das Aufräumen übernehmen Lifecycle-Regeln,
• WORM schützt Integrität und Wiederherstellbarkeit; Vertraulichkeit und Zugriff sind Aufgabe der Verschlüsselung (SSE) und der kurzlebigen Zugangsdaten (STS) aus den vorherigen Teilen der Serie.

In WebDisk Files finden Sie das als Anti-Ransomware: ein WORM-Speicher für Backups, aktiviert mit einem einzigen Schalter, mit Schutz von 90 Tagen bis 7 Jahren und – optional – automatischem Aufräumen nach dessen Ablauf. Testen Sie WebDisk Files oder schreiben Sie uns, wenn Sie die Architektur eines ransomware-resistenten Backups in Ihrer Organisation durchsprechen möchten. Und wenn Sie der breitere technische Hintergrund interessiert, werfen Sie einen Blick in unsere Übersicht des Open-Source-Sicherheits-Stacks bei WebDisk.

Dieser Artikel ist Teil einer Serie über Datensicherheit in den WebDisk-Diensten – zuvor erschienen Texte über die Verschlüsselung im Ruhezustand (SSE-S3, SSE-KMS, SSE-C) und über den Zugriff via STS/SSO. Die Beispiele können Sie auf jeder S3-Plattform mit Object-Lock-Unterstützung ausführen; der Parameter --endpoint-url in der aws CLI verweist auf den Endpoint Ihres Anbieters.