Fast jedes Angebot für Backup-Speicher trägt heute das Wort unveränderlich auf der ersten Seite. Hinter diesem Wort steht meist ein konkreter Mechanismus, S3 Object Lock, und hinter diesem Mechanismus eine Reihe von Garantien, die enger und präziser sind, als die Kurzform vermuten lässt. Teams, die genau wissen, was gesperrt ist, von wem und wie lange, erholen sich in der Regel von Ransomware; Teams, die annehmen, „unveränderlich“ bedeute „sicher“, entdecken den Unterschied manchmal erst während eines Vorfalls.
Das ist wichtig, weil sich die Angreifer angepasst haben. Das Verschlüsseln von Produktionsdaten ist die eine Hälfte einer modernen Ransomware-Operation; die andere Hälfte ist, zuerst die Backups zu zerstören, damit dem Opfer keine Alternative zum Zahlen bleibt. Object Lock existiert, um diesen zweiten Schritt scheitern zu lassen. Es tut das zuverlässig, wenn es korrekt konfiguriert ist, und überhaupt nicht, wenn es das nicht ist. Dieser Artikel definiert Object Lock präzise, behandelt die drei Modi, erklärt, warum Aufbewahrungsfenster die häufigste Schwachstelle sind, beschreibt, wie Backup-Anwendungen es nutzen, und endet mit einer Checkliste.
Was tut Object Lock?
S3 Object Lock ist eine Write-Once-Read-Many-Kontrolle (WORM), die das Speichersystem auf einzelne Objektversionen anwendet. Ist eine Version gesperrt, kann kein API-Aufruf sie löschen oder überschreiben, bis ihre Aufbewahrungsfrist abläuft. Dieser Satz enthält vier Einschränkungen, und jede davon ist wichtig.
Pro Objektversion, nicht pro Bucket
Object Lock wird auf Bucket-Ebene aktiviert, aber die Sperre selbst ist eine Eigenschaft jeder Objektversion. Ein Bucket mit aktiviertem Object Lock kann weiterhin ungesperrte Versionen enthalten, wenn der Schreiber keine Aufbewahrung angefordert hat und der Bucket keinen Standardwert besitzt. Die Aktivierung der Funktion ist eine Voraussetzung, nicht der Schutz.
WORM-Semantik
Eine gesperrte Version kann beliebig oft gelesen und anderswohin kopiert oder repliziert werden. Ein PUT auf denselben Schlüssel erzeugt eine neue Version, statt die alte zu verändern. Was Object Lock verhindert, ist das Entfernen oder Ersetzen der bestehenden Version; die alten Daten bleiben lesbar, unabhängig davon, was danach geschrieben wird.
Eine Aufbewahrungsfrist mit festem Ende
Jede Sperre hat einen „Retain until“-Zeitstempel. Vor diesem Datum wird das Löschen verweigert. Danach wird die Version zu einem gewöhnlichen Objekt, das Lifecycle-Regeln oder die Backup-Anwendung aufräumen können. Die Aufbewahrung einer bestehenden Version kann verlängert, im Compliance-Modus aber nie verkürzt werden.
Durchgesetzt vom Speichersystem, nicht von der Backup-Anwendung
Diese Einschränkung verleiht Object Lock seinen Wert. Der Backup-Server, seine Datenbank, sein Dienstkonto und jeder Administrator, der sich daran anmelden kann, liegen außerhalb der Durchsetzungsgrenze. Sind sie alle kompromittiert, verweigert die Speicherebene das Löschen trotzdem, weil die Entscheidung anhand der Metadaten des Objekts selbst getroffen wird. Ein Schutz, der von der Anwendung durchgesetzt wird, die der Angreifer bereits übernommen hat, ist kein Schutz.
Wovor Object Lock nicht schützt
Die Liste der Dinge, die Object Lock nicht tut, ist länger als die Liste der Dinge, die es tut. Nichts davon sind Mängel der Funktion; es sind Grenzen, und die meisten realen Ausfälle fallen in eine davon.
- Buckets, in denen es nie aktiviert wurde. Object Lock muss beim Anlegen des Buckets eingeschaltet werden und lässt sich auf den meisten Plattformen nicht nachrüsten. Ein aus einem älteren Bucket migriertes Repository oder eine in Eile erstellte Sekundärkopie hat möglicherweise gar keine Sperre, während das Primärsystem als unveränderlich gekennzeichnet ist.
- Verlust des einzigen Standorts. Unveränderlichkeit ist eine logische Kontrolle. Sie überlebt weder Feuer noch Hochwasser, weder den Diebstahl der Hardware noch die Löschung des gesamten Clusters durch jemanden mit Zugriff auf Infrastrukturebene. Eine einzelne gesperrte Kopie bleibt eine einzelne Kopie.
- Zugangsdaten, die den Governance-Modus umgehen können. Sperren im Governance-Modus können von jeder Identität entfernt werden, die die Bypass-Berechtigung besitzt. Trägt das Backup-Dienstkonto oder ein gemeinsam genutztes administratives Konto diese Berechtigung, erbt ein Angreifer, der dieses Konto stiehlt, die Fähigkeit zum Entsperren und Löschen.
- Gateway-Implementierungen über einem löschbaren Dateisystem. Manche S3-Endpunkte übersetzen S3-Aufrufe auf ein darunterliegendes Datei- oder Blocksystem. Die API mag die Sperre respektieren, während das darunterliegende Volume für einen Speicher- oder Hypervisor-Administrator oder jeden mit einer Root-Shell beschreibbar bleibt. Die Sperre ist nur so stark wie die Schicht, die die Bytes hält.
- Deaktivierte Versionierung oder missverstandene Delete Marker. Object Lock erfordert Versionierung. Ein einfaches DELETE auf ein gesperrtes Objekt schlägt nicht fehl; es setzt einen Delete Marker darüber, und die gesperrte Version bleibt darunter erhalten, sodass eine oberflächliche Auflistung das Objekt als verschwunden anzeigt. Operatoren, die das nicht wissen, nehmen möglicherweise an, ein gelistetes Objekt sei geschützt, obwohl es lediglich eine ungesperrte aktuelle Version ist.
- Backup-Katalog und Metadaten. Die Blöcke im Bucket sind nutzlos ohne den Katalog, der sagt, welche Blöcke zu welchem Wiederherstellungspunkt gehören. Liegt der Katalog ungeschützt auf dem Backup-Server, kann ein Angreifer die Daten intakt lassen und sie dennoch in jedem praktikablen Zeitrahmen unwiederherstellbar machen.
Wie unterscheiden sich Compliance-Modus, Governance-Modus und Legal Hold?
S3 definiert zwei Aufbewahrungsmodi und ein unabhängiges Flag. Sie verhalten sich unter Angriff unterschiedlich, daher verdient die Wahl mehr Überlegung als das Akzeptieren eines Standardwerts.
| Kontrolle | Wer sie entfernen oder verkürzen kann | Wie sie abläuft | Typische Verwendung |
|---|---|---|---|
| Compliance-Modus | Keine Identität, einschließlich des Kontoinhabers. | Nur zum Retain-until-Datum. Die Aufbewahrung kann verlängert, nie verkürzt werden. | Kopien für die Ransomware-Wiederherstellung, regulierte Aufbewahrung, jede Kopie, die einen kompromittierten Administrator überstehen muss. |
| Governance-Modus | Jede Identität mit der Bypass-Berechtigung. | Zum Retain-until-Datum oder früher per Bypass. | Schutz vor Unfällen und gewöhnlichem Missbrauch, wo ein kontrollierter Notausgang akzeptabel ist. |
| Legal Hold | Jede Identität mit der Legal-Hold-Berechtigung. | Nie von selbst; bleibt bestehen, bis er explizit aufgehoben wird. | Aufbewahrung für Rechtsstreitigkeiten oder Ermittlungen, über einen der beiden Modi gelegt; für sich allein keine Ransomware-Kontrolle. |
Für Backup-Repositorys, deren Zweck es ist, einen Einbruch zu überstehen, ist der Compliance-Modus der angemessene Standard. Der Governance-Modus wird oft gewählt, weil ein offener Ausweg sicherer wirkt, aber genau diesen Ausweg wird ein Angreifer mit gestohlenen Zugangsdaten nutzen. Wird ein Governance-Notausgang tatsächlich benötigt, sollte die Bypass-Berechtigung einer Identität gehören, die nie für Routinearbeit verwendet wird und durch starke Multi-Faktor-Authentifizierung geschützt ist.
Warum ist das Aufbewahrungsfenster die häufigste Lücke?
Eine Sperre, die abläuft, bevor jemand den Einbruch bemerkt, schützt nichts. Die Aufbewahrungsdauer ist eine Sicherheitsentscheidung, keine Kapazitätsentscheidung, und sollte an der erwarteten Zeit zwischen erstem Eindringen und Entdeckung ausgerichtet werden, oft als Verweildauer des Angreifers (Dwell Time) bezeichnet.
Angenommen, eine Organisation legt eine Unveränderlichkeitsfrist von sieben Tagen fest, weil das zu ihrem Backup-Zyklus passt und die Kapazität planbar hält. Angenommen, ein Angreifer verschafft sich an Tag eins einen Zugang, verbringt drei Wochen mit dem Sammeln von Zugangsdaten und löst an Tag zweiundzwanzig die Verschlüsselung aus. Jedes vor Tag fünfzehn geschriebene Backup hat sein Aufbewahrungsfenster bereits verlassen und kann von jedem gelöscht werden, der die Zugangsdaten des Backup-Dienstes besitzt. Die einzigen unveränderlichen Wiederherstellungspunkte sind die jüngsten sieben, die möglicherweise bereits vorbereitete oder verschlüsselte Daten enthalten. Die Sperre hat genau so funktioniert wie konfiguriert; die Konfiguration passte nicht zur Bedrohung. Daraus folgen drei Konsequenzen.
Die Aufbewahrung sollte die realistische Verweildauer mit Reserve übersteigen
Veröffentlichte Schätzungen zur Verweildauer variieren und ändern sich von Jahr zu Jahr, daher zitiert dieser Artikel keine. Das Prinzip ist stabil: Kann die Organisation einen Eindringling nicht zuverlässig innerhalb einer bestimmten Anzahl von Tagen entdecken, muss das unveränderliche Fenster länger sein als diese Zahl. Dreißig Tage sind ein gängiger Ausgangspunkt; regulierte oder hochwertige Umgebungen gehen oft weiter.
Unveränderlichkeitsfrist und Backup-Aufbewahrung sind unterschiedliche Einstellungen
Backup-Anwendungen unterscheiden zwischen der Dauer, für die ein Wiederherstellungspunkt aufbewahrt wird (Aufbewahrungsrichtlinie), und der Dauer, für die der Speicher das Löschen verweigert (Unveränderlichkeitsfrist). Beide können gleich sein, oder die Unveränderlichkeitsfrist kann kürzer sein. Was nicht passieren darf, ist eine so kurze Unveränderlichkeitsfrist, dass die eigene Bereinigung der Anwendung, oder eine kompromittierte Kopie davon, Wiederherstellungspunkte entfernen kann, die die Organisation noch benötigt.
Längere Sperren kosten Kapazität
Daten, die nicht gelöscht werden können, lassen sich nicht freigeben. Die Verlängerung der Sperre von sieben auf dreißig Tage erhöht den vorgehaltenen Speicherbedarf, und dieser Zuwachs muss geplant und nicht erst entdeckt werden; der Beitrag zur Dimensionierung von Backup-Repositorys beschreibt, wie er modelliert wird.
Wie nutzen Backup-Anwendungen Object Lock?
Backup-Software legt die rohen S3-Aufbewahrungseinstellungen selten offen. Stattdessen trägt das Repository oder der Job eine Unveränderlichkeitseinstellung, die die Anwendung beim Schreiben in eine Aufbewahrung pro Objekt übersetzt. Typischerweise richtet der Administrator ein Repository auf einen Bucket mit aktiviertem Object Lock und gibt eine Unveränderlichkeitsfrist in Tagen an. Jedes vom Job erzeugte Objekt erhält ein aus dieser Frist berechnetes Retain-until-Datum, das in vielen Produkten so verlängert wird, dass die gesamte Kette, von der ein Wiederherstellungspunkt abhängt, so lange gesperrt bleibt wie der Wiederherstellungspunkt selbst.
Zwei Details verdienen eine Überprüfung. Erstens: Prüfen Sie, welchen Modus die Anwendung anfordert; die meisten Anbieter, die Object Lock unterstützen, schreiben im Compliance-Modus, aber der Operator sollte das prüfen, statt es anzunehmen. Zweitens: Prüfen Sie, wie die Anwendung mit der Standardaufbewahrung des Buckets zusammenwirkt. Wo beides existiert, gewinnt in der Regel die längere Frist, aber Abweichungen zwischen beiden sind bei Audits eine häufige Quelle der Verwirrung.
Die Seite zu den validierten Backup-Anwendungen listet die gegen ARTESCA getesteten Plattformen auf, was einen Teil dieses Rätselratens beseitigt.
Bevor Sie sich darauf verlassen: eine Checkliste
Diese Prüfungen dauern einen Nachmittag und hätten die meisten der oben genannten Ausfälle verhindert.
- Prüfen Sie, dass Object Lock auf jedem Bucket aktiviert ist, der Backup-Daten hält, einschließlich Sekundärkopien und während Migrationen angelegter Buckets.
- Prüfen Sie, dass die Versionierung aktiviert und verstanden ist und dass Operatoren wissen, dass ein Delete Marker keine Löschung ist.
- Ziehen Sie Stichproben aktueller Objekte und lesen Sie deren Aufbewahrungsmetadaten direkt über die S3-API aus. Verifizieren Sie, dass Modus und Retain-until-Datum dem Design entsprechen.
- Versuchen Sie, eine gesperrte Version mit den eigenen Zugangsdaten der Backup-Anwendung zu löschen, und bestätigen Sie, dass der Speicher dies verweigert.
- Wird der Governance-Modus verwendet, listen Sie jede Identität mit der Bypass-Berechtigung auf und begründen Sie jede einzelne.
- Richten Sie die Unveränderlichkeitsfrist an der Verweildauer des Angreifers aus, nicht am Backup-Zyklus, und dokumentieren Sie die Begründung.
- Schützen Sie Backup-Katalog und Konfiguration ebenso ernsthaft wie die Daten, etwa indem Sie sie in einen gesperrten Bucket exportieren.
- Halten Sie mindestens eine Kopie an einem zweiten Standort oder in einer zweiten administrativen Domäne, damit Unveränderlichkeit mit Unabhängigkeit kombiniert wird.
- Stellen Sie nach Zeitplan aus einer unveränderlichen Kopie wieder her. Eine Sperre, die nie gegen eine echte Wiederherstellung getestet wurde, ist eine Hypothese.
Object Lock ist gerade deshalb verlässlich, weil seine Garantien eng und mechanisch sind. Zu wissen, wo sie enden, macht aus einem Häkchen einen Wiederherstellungsplan. Weiteren architektonischen Hintergrund finden Sie unter Immutable Backup.
Wie Scality ARTESCA Object Lock durchsetzt
Scality ARTESCA ist S3-Objektspeicher, der als Backup-Ziel konzipiert ist, und Object Lock wird in seinem Datenpfad durchgesetzt, statt als Gateway über ein separat beschreibbares Dateisystem gelegt zu werden. Das Löschen einer gesperrten Version wird vom Speichersystem selbst verweigert, unabhängig davon, welche Zugangsdaten oder welche Konsole die Anfrage gestellt haben.
ARTESCA unterstützt den Compliance-Modus, sodass eine einmal gesetzte Aufbewahrungsfrist von keinem Konto, einschließlich des Speicheradministrators, verkürzt oder entfernt werden kann. Es ist mit den wichtigsten Backup-Anwendungen validiert, darunter Veeam, Commvault, Cohesity und Rubrik, sodass die Zuordnung zwischen der Unveränderlichkeitseinstellung eines Jobs und der auf jedes Objekt geschriebenen Aufbewahrung getestet und nicht angenommen ist. Das Sicherheitsmodell ist auf der Seite zu Sicherheit und Cyber-Resilienz beschrieben.
Welche Plattform die Backups auch hält, der praktische Schritt ist derselbe: Lesen Sie die Aufbewahrungsmetadaten eines echten Objekts aus, versuchen Sie, es mit den Zugangsdaten zu löschen, die ein Angreifer stehlen würde, und setzen Sie das Fenster länger als die Zeit, die es dauern würde, ihn zu bemerken.