5 Fast jedes Speicher- und Backup-Produkt, das heute verkauft wird, verspricht Unveränderlichkeit. Kaum zwei meinen damit dasselbe, und die Unterschiede bleiben nahezu unsichtbar – bis zu dem Tag, an dem es darauf ankommt. Dann sind sie das Einzige, was zählt. Unveränderlichkeit ist keine Funktion, die sich durch das Lesen eines Datenblatts überprüfen lässt, denn das Wort beschreibt ein Ergebnis und keinen Mechanismus. Zwei Produkte können beide unveränderlich sein und sich dennoch völlig darin unterscheiden, wer sie abschalten kann, was unterhalb der API geschieht und ob der Schutz einen kompromittierten Administrator übersteht. Genau um diese Unterschiede geht es. Dieser Leitfaden behandelt zunächst die Definition und widmet sich dann ausführlich dem wirklich schwierigen Teil: erzwungene Unveränderlichkeit von der Marketingversion zu unterscheiden. Was ist unveränderlicher Speicher? Unveränderlicher Speicher ist Speicher, in dem Daten nach dem Schreiben für eine festgelegte Aufbewahrungsfrist weder geändert noch gelöscht werden können – auch nicht von einem Administrator. Entscheidend ist die Aufbewahrungsfrist. Unveränderlich bedeutet nicht dauerhaft, sondern unveränderbar für eine bestimmte Dauer, nach der wieder die normalen Lifecycle-Regeln gelten. Das Umsetzungsmuster ist Write Once, Read Many – WORM: Einmal schreiben – Daten werden als neues Objekt oder neue Version gespeichert, statt direkt bearbeitet zu werden Mehrfach lesen – die Daten bleiben während der gesamten Aufbewahrungsfrist lesbar Durchsetzung der Aufbewahrung – das System verweigert Löschungen und Überschreibungen, bis die Aufbewahrung abläuft Beim dritten Punkt gehen die Produkte auseinander. Die ersten beiden setzt jeder Anbieter um. Was sie unterscheidet, ist, was die Aufbewahrung durchsetzt und wer sie außer Kraft setzen kann. Das Spektrum der Unveränderlichkeit: fünf Umsetzungen, fünf verschiedene Garantien Alle fünf der folgenden Ansätze werden als „unveränderlich“ bezeichnet. Sie sind nicht gleichwertig, und die Lücke zwischen der obersten und der untersten Zeile entspricht dem Unterschied zwischen einem behebbaren und einem nicht behebbaren Vorfall. UmsetzungDurchgesetzt durchBackup-Admin kann umgehenStorage-Root kann umgehenÜbersteht kompromittierte AnmeldedatenUnveränderlichkeits-Flag der Backup-SoftwareDie Backup-AnwendungJaJaNeinDateisystemberechtigungen + SnapshotsZugriffskontrolle des BetriebssystemsManchmalJaNeinWORM-ApplianceSpeziell entwickelte HardwareNeinNeinJa, innerhalb ihres ÖkosystemsS3 Object Lock – Governance-ModusSpeicherebeneNur mit einer bestimmten BerechtigungAbhängig von der UmsetzungTeilweiseS3 Object Lock – Compliance-ModusSpeicherebeneNeinNeinJaDie Frage, die die Zeilen voneinander trennt, lautet nicht „Ist es unveränderlich?“, sondern „Wer behält die Befugnis, es wieder veränderbar zu machen?“ Ein hilfreicher Perspektivwechsel: Unveränderlichkeit ist keine Eigenschaft der Daten. Sie ist eine Aussage darüber, wer die Löschbefugnis hat. Wenn ein Anbieter „unveränderlich“ sagt, lautet die Anschlussfrage immer gleich: unveränderlich gegenüber wem? Die vier Wege zur Umgehung Unveränderlichkeit scheitert auf einige wenige, gut verstandene Arten. Jede davon war aktiviert, konfiguriert und als funktionsfähig gemeldet – bis sie getestet wurde. 1. Die Durchsetzung liegt in der Anwendung, nicht im Speicher Die Backup-Software hat eine Unveränderlichkeitseinstellung, und sie ist aktiviert. Das zugrunde liegende Repository ist jedoch ein gewöhnlicher Bucket oder ein Dateisystem ohne konfigurierte Aufbewahrung, und das Einzige, was das Löschen verhindert, ist die Backup-Anwendung, die den Löschbefehl nicht ausführt. Ein Angreifer mit Backup-Admin-Anmeldedaten muss die Unveränderlichkeit gar nicht überwinden – er schaltet die Einstellung einfach ab. Der Test: Deaktivieren Sie die Backup-Software vollständig und versuchen Sie, ein Objekt direkt über die Speicher-API zu löschen. Lässt es sich löschen, war die Unveränderlichkeit nur ein Häkchen in der Oberfläche. 2. Governance-Modus, obwohl Compliance-Modus angenommen wurde S3 Object Lock hat zwei Aufbewahrungsmodi mit deutlich unterschiedlichen Garantien. Der Governance-Modus blockiert das Löschen durch gewöhnliche Identitäten, erlaubt aber eine Außerkraftsetzung durch eine Identität mit einer bestimmten Bypass-Berechtigung. Der Compliance-Modus erlaubt während der Aufbewahrungsfrist niemandem eine Außerkraftsetzung, auch nicht dem Root-Konto. Der Governance-Modus ist ein sinnvoller Standard für betriebliche Flexibilität – und die falsche Wahl für eine Kopie, deren einziger Zweck darin besteht, einen kompromittierten Administrator zu überstehen. Sehr viele Bereitstellungen laufen im Governance-Modus in dem Glauben, Schutz auf dem Niveau des Compliance-Modus zu haben. 3. Unterhalb der API Diesen Punkt übersehen die meisten Bewertungen. Object Lock wird an der S3-API durchgesetzt. Ist die darunterliegende Plattform ein universelles Dateisystem auf universellen Servern, ist ein Speicheradministrator mit Root-Zugriff auf diese Knoten überhaupt nicht an die S3-API gebunden. Er kann direkt auf die Dateien zugreifen – oder auf die Metadaten, in denen der Aufbewahrungsstatus gespeichert ist. Unveränderlichkeit auf API-Ebene ist notwendig, aber nicht ausreichend. Was darunter liegt, entscheidet, ob die Sperre eine Mauer ist oder nur ein Schild. 4. Das Replikat ohne Sperre Die Aufbewahrung muss mit den Daten mitwandern. Ist die primäre Kopie gesperrt, das Replikationsziel aber ein gewöhnlicher Bucket, bestimmt die schwächste Kopie das tatsächliche Schutzniveau der Architektur – und ein Angreifer, der auch nur etwas Aufklärung betrieben hat, wird sie finden. Dasselbe gilt für Tiering: Ein Objekt, das ohne seine Aufbewahrung in eine günstigere Ebene verschoben wird, ist stillschweigend veränderbar geworden. Defense in Depth: warum eine einzige Ebene nie die Antwort ist Die Umgehungswege zwei bis vier beschreiben alle dasselbe strukturelle Problem: einen einzigen Durchsetzungspunkt auf einer Ebene, unter dem alles ungeschützt ist. Die Antwort besteht darin, auf mehr als einer Ebene zu schützen, sodass das Überwinden einer einzelnen Ebene nicht ausreicht. Das Scality-Framework CORE5 ist eine Möglichkeit, dies zu formalisieren – und ein nützlicher Bewertungsmaßstab, egal welchen Anbieter Sie prüfen. Es schützt auf fünf Ebenen: API-Ebene – Unveränderlichkeit per S3 Object Lock, angewendet in dem Moment, in dem ein Backup geschrieben wird Datenebene – Identitäts- und Zugriffsmanagement sowie kryptografische Kontrollen, ausgerichtet auf Exfiltration statt auf Löschung Speicherebene – fortschrittliches Erasure Coding, das Daten für jeden unlesbar macht, der die zugrunde liegenden Medien direkt ausliest; das ist die Antwort auf Umgehungsweg drei Geografische Ebene – Kopien an mehreren Standorten, sodass ein einzelnes Rechenzentrum nicht den gesamten Blast Radius ausmacht Architekturebene – Härtung der eigenen Angriffsfläche des Systems Es geht nicht um den Markennamen. Entscheidend ist, dass ein glaubwürdiges Unveränderlichkeitskonzept auf jeder Ebene eine Antwort hat, nicht nur an der API. Antwortet ein Anbieter auf die Frage „Was hält einen Speicheradministrator mit Root-Zugriff auf?“ nur mit dem Hinweis auf seine Object-Lock-Unterstützung, hat er eine andere Frage beantwortet. Die Überlegungen dahinter beschreiben wir ausführlicher in den fünf Ebenen eines unerschütterlichen Cyberresilienz-Frameworks (auf Englisch). Unveränderlicher Speicher vs. unveränderliches Backup Die Begriffe werden oft synonym verwendet, beschreiben aber Unterschiedliches. Unveränderlicher Speicher ist eine Fähigkeit der Plattform: Das System kann WORM-Aufbewahrung durchsetzen. Unveränderliches Backup ist ein betriebliches Ergebnis: Ihre Backup-Kopien sind tatsächlich manipulationssicher. Der Mechanismus erzeugt das Ergebnis nicht von allein. Sie können unveränderlichen Speicher betreiben und trotzdem kein einziges unveränderliches Backup besitzen – wenn die Aufbewahrung nie auf den Bucket angewendet wurde, in den die Backup-Jobs schreiben, wenn sie im Governance-Modus angewendet wurde oder wenn die entscheidende Kopie das ungesperrte Replikat ist. Die Fähigkeit ist eine Voraussetzung. Das Ergebnis erfordert eine Konfiguration, die Sie überprüft haben. Unveränderlicher Speicher vs. Snapshots Snapshots werden häufig für unveränderlich gehalten. Sie sind nützlich, aber eine andere Kontrolle. Snapshots eignen sich gut für kurzfristige Rollbacks, die betriebliche Wiederherstellung nach Fehlern und die schnelle Wiederherstellung eines aktuellen Zustands. Gegen einen gezielt vorgehenden Angreifer haben sie drei strukturelle Schwächen: Der Abstand zwischen Snapshots ist ein Gefährdungsfenster; Snapshots lassen sich meist von derselben privilegierten Identität löschen, die auch die Produktion verwaltet; und die Snapshot-Verwaltung teilt sich typischerweise eine Control Plane mit den geschützten Systemen. Wer diese Control Plane kontrolliert, kontrolliert auch die Snapshots. Behalten Sie Snapshots. Sie haben ihren Platz. Lassen Sie sie aber nicht an die Stelle einer richtliniengesteuerten Aufbewahrung auf einer unabhängigen Control Plane treten. Was ohne unveränderliche Backups tatsächlich schiefgeht Das Risiko wird meist so beschrieben: „Ein Angreifer löscht Ihre Backups.“ Das ist eine Fehlerart, aber nicht die häufigste. Die realistischen sind: Die Aufbewahrung wird verkürzt, nicht gelöscht. Das ist leiser als ein Löschen und löst nicht die Alarme aus, die ein Löschen auslösen würde. Bis es jemand bemerkt, sind die Wiederherstellungspunkte von selbst abgelaufen. Backups werden an Ort und Stelle verschlüsselt. Die Jobs laufen weiter erfolgreich durch. Die Dashboards bleiben grün. Das Repository enthält die richtige Anzahl an Dateien – und keine davon lässt sich wiederherstellen. Statt der Daten wird der Katalog angegriffen. Die Backups überleben, der Index, der sie nutzbar macht, aber nicht. Jede verbliebene Kopie ist jünger als die Verweildauer des Angreifers. Nichts wurde gelöscht. Alles ist intakt. Und alles ist vergiftet. Unveränderlichkeit begegnet den ersten beiden Fällen direkt und dem vierten nur, wenn die Aufbewahrung richtig festgelegt ist – darum geht es im nächsten Abschnitt. Die Aufbewahrung muss Ihre Erkennungslücke überdauern Die Aufbewahrungsdauer wird normalerweise aus einer Compliance-Anforderung abgeleitet. Bei Ransomware ist eine andere Zahl maßgeblich: die Verweildauer (Dwell Time), also die Zeitspanne zwischen der ersten Kompromittierung und ihrer Erkennung – und die beträgt häufig Wochen. Beträgt die Aufbewahrung 14 Tage und war der Eindringling 30 Tage präsent, kann jede unveränderliche Kopie, die Sie besitzen, die Kompromittierung bereits enthalten. Die Unveränderlichkeit hat genau wie vorgesehen funktioniert. Sie hat den falschen Zustand perfekt bewahrt – und Ihnen verweigert, ihn zu löschen. Eine praxistaugliche Aufbewahrungsstaffel, ausgerichtet am Risiko statt an den Speicherkosten: 7 Tage – operativer Rollback, alltägliche Fehler 30 Tage – Zeitfenster für die Wiederherstellung nach Vorfällen 90+ Tage – Abdeckung realistischer Verweildauern bei Ransomware 1 Jahr+ – Compliance und Archiv Dieselbe Überlegung gilt allgemein für schleichende Kompromittierungen – siehe Wiederherstellung nach Zero-Day-Angriffen. So bewerten Sie unveränderlichen Speicher: sieben Fragen Stellen Sie diese Fragen jedem Anbieter, auch uns. Entscheidend ist nicht, ob er mit Ja antwortet, sondern ob die Antwort konkret ist. Kann irgendein Administrator geschützte Daten während der Aufbewahrung löschen? Eine gute Antwort nennt den Modus und die Identität. Ein vages „Ja, wir unterstützen Unveränderlichkeit“ ist ein Nein. Erfolgt die Durchsetzung auf der Speicherebene oder in der Anwendung? Lassen Sie sich beschreiben, was passiert, wenn die Backup-Software vollständig umgangen wird. Was hält jemanden mit Root-Zugriff auf die Speicherknoten auf? Diese Frage trennt echte Architekturen von bloß konfigurierten. Codierung und Verschlüsselung unterhalb der API sind legitime Antworten. „Object Lock“ ist keine. Übersteht die Aufbewahrung Replikation und Tiering? Lassen Sie sich das für jede Kopie und jede Ebene bestätigen, nicht nur für die primäre. Ist die Aufbewahrungskonfiguration sichtbar, auditiert und mit Alarmen versehen? Sonst bleiben Abweichungen bei Richtlinien unbemerkt – und eine verkürzte Aufbewahrung ist in der Praxis der häufigste Fehler. Wie wird die Integrität nachgewiesen? Prüfsummen, durchgängige Verifizierung, regelmäßige Validierung. Unveränderlich und intakt sind zwei verschiedene Aussagen. Wie schnell erfolgt die Wiederherstellung in Ihrem Maßstab? Ein Tresor, den Sie nicht innerhalb Ihrer RTO leeren können, hat die Daten geschützt, nicht aber das Geschäft. Siehe Wiederherstellungsgeschwindigkeit nach Ransomware, um dafür eine konkrete Zahl zu ermitteln. Wo unveränderlicher Speicher seinen Platz hat Die gängigen Einsatzszenarien, grob danach geordnet, wie oft sie den Aufwand rechtfertigen: Backup-Repositorys – Backups von VMs, NAS und Datenbanken. In den meisten Umgebungen das wertvollste Ziel und der übliche Ausgangspunkt. Cyber-Recovery-Vault – ein logisch isoliertes Repository mit langer Aufbewahrung, strengen Richtlinien und separatem Zugriff, abgeschirmt durch einen logischen Air Gap. Compliance-Archiv – regulierte Aufbewahrung, rechtliche Unterlagen, medizinische Bilddaten. Hier hat WORM seinen Ursprung, und hier passt es nach wie vor am besten. Logs und Audit-Trails – Sicherheitsereignisse und Audit-Nachweise, deren Wert davon abhängt, dass niemand sie bearbeiten konnte. Gut betreiben Drei Praktiken unterscheiden Bereitstellungen, die standhalten, von solchen, die auf dem Papier gleich aussehen. Halten Sie die Zahl der Aufbewahrungsklassen gering. Vier reichen aus. Komplexe Aufbewahrungsrichtlinien erzeugen Lücken, die niemand sieht – und diese Lücken werden immer unter den falschen Umständen entdeckt. Trennen Sie die Anmeldedaten. Keine einzelne Identität sollte Backup-Konfiguration, Speicherkonfiguration und die Außerkraftsetzung der Aufbewahrung kontrollieren. Kann ein Konto alle drei, ist die Unveränderlichkeit reine Dekoration – der Angreifer muss nur dieses eine Konto kompromittieren. Erwägen Sie kundenverwaltete Schlüssel in einem Hardware-Sicherheitsmodul, wenn die Trennung technisch durchsetzbar statt nur organisatorisch sein muss. Testen Sie Wiederherstellungen, nicht Backups. Ein erfolgreicher Job ist ein Signal für den Schreibpfad. Er sagt nichts darüber aus, ob sich die Daten wiederherstellen lassen. Testen Sie vollständige, teilweise und zeitgemessene Wiederherstellungen im großen Maßstab nach einem festen Plan – und betrachten Sie die Ergebnisse als den tatsächlichen Zustand des Systems. Häufig gestellte Fragen Ist unveränderlicher Speicher dasselbe wie WORM-Speicher? WORM ist das Umsetzungsmuster; unveränderlicher Speicher ist die Kategorie. Nahezu jeder unveränderliche Speicher setzt auf eine Durchsetzung der Aufbewahrung nach WORM-Prinzip, doch „WORM-Appliance“ bezeichnet meist eine bestimmte Klasse speziell entwickelter Hardware, während unveränderlicher Speicher heute häufiger S3 Object Lock auf Objektspeicher meint. Kann Ransomware unveränderlichen Speicher verschlüsseln? Die geschützten Objekte nicht, solange die Aufbewahrung läuft. Ransomware kann nur verschlüsseln, worauf sie schreiben kann, und ein Objekt mit aktiver Aufbewahrung lehnt sowohl Änderungen als auch Löschungen ab. Die Einschränkungen sind die Umgehungswege: Erfolgt die Durchsetzung auf Anwendungsebene, wird der Governance-Modus genutzt oder hat der Angreifer Root-Zugriff unterhalb der API, hält der Schutz möglicherweise nicht. Was ist der Unterschied zwischen Governance-Modus und Compliance-Modus? Der Governance-Modus blockiert das Löschen, erlaubt aber eine Außerkraftsetzung durch eine Identität mit einer bestimmten Bypass-Berechtigung. Der Compliance-Modus erlaubt bis zum Ablauf der Aufbewahrung niemandem eine Außerkraftsetzung, auch nicht dem Root-Konto. Der Governance-Modus passt zu betrieblicher Flexibilität; der Compliance-Modus ist das, was Sie für eine Kopie brauchen, die einen kompromittierten Administrator überstehen muss. Brauche ich für Unveränderlichkeit Objektspeicher? Nein – WORM-Appliances und einige dateisystembasierte Ansätze bieten sie ebenfalls. S3-kompatibler Objektspeicher mit Object Lock hat sich jedoch als gängige Wahl durchgesetzt, weil er sich mit praktisch jeder modernen Backup-Plattform integrieren lässt, ohne Forklift-Upgrades skaliert und die Aufbewahrung über eine Richtlinienebene statt über Dateiberechtigungen durchsetzt. Reicht unveränderlicher Speicher allein aus? Nein. Er schützt eine Kopie vor Veränderung. Er isoliert nicht den Weg, über den Sie diese Kopie erreichen, sagt Ihnen nicht, welcher Wiederherstellungspunkt sauber ist, und macht die Wiederherstellung nicht schnell genug, um etwas zu bewirken. Unveränderlichkeit ist eine von vier Eigenschaften, die eine Wiederherstellungsarchitektur braucht – neben Isolation, paralleler Wiederherstellung und Validierung. Die Kurzfassung Unveränderlicher Speicher ist die wirksamste einzelne Kontrolle zum Schutz von Wiederherstellungsdaten. Zugleich ist er die Kontrolle, die am häufigsten behauptet und am seltensten überprüft wird – denn die Behauptung ist einfach, und die Überprüfung erfordert die Frage, wer auf jeder Ebene des Stacks die Löschbefugnis hat. Unternehmen, die es richtig machen, behandeln Unveränderlichkeit als System und nicht als Einstellung: durchgesetzt auf der Speicherebene, unterhalb der API nicht umgehbar, auf jedes Replikat übertragen, länger aufbewahrt, als ein Angreifer voraussichtlich unentdeckt bleibt, und nachgewiesen durch Wiederherstellungen, die tatsächlich jemand durchgeführt hat. Alles andere ist ein Häkchen, das nie getestet wurde. Scality entwickelt S3-Objektspeicher, dessen Unveränderlichkeit von der API bis in die Architektur durchgesetzt wird. Erfahren Sie, wie CORE5 funktioniert oder stöbern Sie im Glossar nach den Begriffen aus diesem Leitfaden.
