4 Die meisten Wiederherstellungspläne für Ransomware sind eigentlich Schutzpläne. Sie legen fest, wo Backups landen, wie lange sie aufbewahrt werden und welche Aufbewahrungssperre gilt. Sie werden geprüft, genehmigt und abgelegt. Dann tritt ein Vorfall ein, und die Frage, die niemand aufgeschrieben hat, ist plötzlich die einzige, die zählt: Wie viele Stunden dauert es, bis das Geschäft wieder läuft? Schutz und Wiederherstellung sind nicht dieselbe Disziplin. Schutz ist eine Eigenschaft des Schreibpfads – einmal konfiguriert und durch Prüfung verifiziert. Wiederherstellung ist eine Eigenschaft des Lesepfads unter Last und lässt sich nur verifizieren, indem man sie durchführt. Eine Architektur kann beim Ersten makellos und beim Zweiten unerprobt sein – und genau in dieser Lage finden sich viele Unternehmen am denkbar schlechtesten Tag wieder. In diesem Leitfaden geht es um die zweite Hälfte: wie Sie die Wiederherstellungsgeschwindigkeit als belastbare Zahl ausdrücken, warum Objektspeicher die Rechnung verändert und welche vier architektonischen Eigenschaften – Unveränderlichkeit, Isolation, Parallelität und Validierung – darüber entscheiden, ob diese Zahl real ist. Was ist die Wiederherstellung nach Ransomware? Die Wiederherstellung nach Ransomware umfasst die Prozesse und Technologien, mit denen nach einem Ransomware-Vorfall Daten wiederhergestellt und der Betrieb fortgesetzt wird, ohne auf den Angreifer angewiesen zu sein. Sie unterscheidet sich in einem Punkt von einer gewöhnlichen Backup-Wiederherstellung: Es wird angenommen, dass die Wiederherstellungsinfrastruktur selbst ein Ziel ist. Diese Annahme verändert die Anforderungen. Ein funktionierender Plan muss Folgendes liefern: Point-in-Time-Wiederherstellung – konsistente Wiederherstellungspunkte, nicht nur abrufbare Dateien Unveränderlichen Schutz – Backup-Kopien, die weder verändert noch gelöscht werden können, auch nicht von einem Administrator Isolation – einen Wiederherstellungspfad, der nicht von der kompromittierten Control Plane abhängt Wiederherstellungsdurchsatz im großen Maßstab – gemessen in wiederhergestellten Workloads, nicht in Gigabytes pro Sekunde Validierung – regelmäßig erzeugte Nachweise, dass sich Wiederherstellungspunkte tatsächlich wiederherstellen lassen Die Zahlung eines Lösegelds ersetzt keinen dieser Punkte. Von Angreifern bereitgestellte Entschlüsselungstools sind oft langsam, unvollständig oder fehlerhaft und helfen nicht bei Systemen, die gelöscht statt verschlüsselt wurden. Die Wiederherstellung aus vertrauenswürdigen Kopien ist der einzige Weg, der zum Ziel führt. Wiederherstellung in Workloads pro Stunde messen, nicht in Gigabytes pro Sekunde Durchsatzwerte sind die Standardwährung bei der Beschaffung von Speicher – und für die Wiederherstellungsplanung nahezu nutzlos. Ein Repository, das in einem sequenziellen Benchmark 10 GB/s erreicht, sagt nichts darüber aus, wie lange es dauert, 400 virtuelle Maschinen wieder online zu bringen. Denn dieser Vorgang wird durch Parallelität, Metadatenoperationen und die eigene Ablaufsteuerung der Backup-Anwendung begrenzt, lange bevor die reine Bandbreite zum Engpass wird. Die Kennzahl, die sich auf das Geschäft übertragen lässt, sind wiederhergestellte Workloads pro Stunde – meist ausgedrückt als VMs pro Stunde. Nur sie lässt sich direkt in eine Recovery Time Objective umrechnen, und nur auf ihrer Grundlage kann die Geschäftsleitung handeln. Ein Modell, das Sie auf Ihre eigene Umgebung anwenden können Die Rechnung ist einfach genug für ein Whiteboard – und aufschlussreicher als die meisten Benchmarks von Anbietern. Nehmen Sie eine Umgebung mit 400 VMs von durchschnittlich je 200 GB – also 80 TB, die wiederhergestellt werden müssen. Parallele WiederherstellungsströmeEffektive GesamtrateVMs pro StundeZeit zur Wiederherstellung von 400 VMs40,8 GB/s~14~28 Stunden163,2 GB/s~58~7 Stunden6412,8 GB/s~230~1,7 StundenBeispielmodell unter der Annahme von 200 MB/s pro Strom und linearer Skalierung. Reale Umgebungen weichen davon ab – entscheidend ist die Form der Kurve, nicht die absoluten Werte. Daraus folgen drei Dinge. Erstens: Der Unterschied zwischen einer zweistündigen und einer zweitägigen Wiederherstellung ist Parallelität, nicht Bandbreite – die Rate pro Strom ist in allen drei Zeilen identisch. Zweitens: Keine realistische Umgebung skaliert linear bis zu 64 Strömen; irgendetwas sättigt zuerst, und herauszufinden, was das ist, ist die eigentliche Planungsaufgabe. Drittens: Wenn Sie Ihre eigene Zahl nicht in diesem Format angeben können, haben Sie keine Recovery Time Objective. Sie haben eine Wunschvorstellung. Hier hört auch der Unterschied zwischen RTO und RPO auf, akademisch zu sein. Die Recovery Point Objective ist eine Funktion der Backup-Häufigkeit und meist gut kontrolliert. Die Recovery Time Objective ist eine Funktion der Wiederherstellungsparallelität und wird meist überhaupt nicht gemessen. Zu den grundlegenden Definitionen siehe RTO vs. RPO: die wichtigsten Unterschiede erklärt. Warum Objektspeicher die Rechnung der Wiederherstellung verändert Objektspeicher hat sich in Backup-Architekturen durchgesetzt, weil er Kapazität kostengünstig skaliert. Seine Bedeutung für die Wiederherstellung nach Ransomware ist eine andere und spezifischere: Er bietet einen flachen, standardmäßig parallelen Namespace mit durchsetzbarer Aufbewahrung – und damit fast genau das, was eine Massenwiederherstellung braucht. Parallelität ist eine Eigenschaft der Architektur, kein Tuning-Parameter Ein hierarchisches Dateisystem serialisiert über die Verzeichnis-Metadaten. Jeder Wiederherstellungsstrom konkurriert um dieselben Namespace-Strukturen, und die Konkurrenz nimmt mit steigender Parallelität zu – genau das Gegenteil dessen, was eine Massenwiederherstellung braucht. Ein flacher Namespace im S3-Stil hat keinen Verzeichnisbaum, der gesperrt werden müsste. Wiederherstellungsströme sind konstruktionsbedingt unabhängig; zusätzliche Ströme erhöhen also den Durchsatz, bis das Netzwerk oder die Backup-Anwendung zum Engpass wird. Das ist der Mechanismus hinter der Tabelle oben. Der Schritt von der ersten zur dritten Zeile ist keine Frage schnellerer Festplatten, sondern eine Frage, ob das Repository 64 gleichzeitige Leser verkraftet, ohne dass der Namespace zum Engpass wird. Mehr zum zugrunde liegenden Verhalten in Durchsatz von Objektspeicher und Resilienz im Unternehmensbetrieb. Unveränderlichkeit, die einen kompromittierten Administrator übersteht Die meisten gescheiterten Wiederherstellungen sind keine langsamen, sondern ausbleibende Wiederherstellungen – Backups, die gelöscht, an Ort und Stelle verschlüsselt oder deren Aufbewahrung Wochen vor der Verschlüsselung unbemerkt verkürzt wurde. Objektspeicher begegnet dem mit einer Aufbewahrung, die auf der Speicherebene statt auf der Anwendungsebene durchgesetzt wird. S3 Object Lock setzt eine Semantik nach dem Prinzip Write Once, Read Many um: Innerhalb der Aufbewahrungsfrist kann ein Objekt mit keinerlei Anmeldedaten geändert oder gelöscht werden, auch nicht mit Root-Rechten. Betrieblich entscheidend ist der Unterschied zwischen dem Governance-Modus, den eine ausreichend privilegierte Identität außer Kraft setzen kann, und dem Compliance-Modus, den niemand außer Kraft setzen kann. Die Fehlerart, gegen die Sie planen müssen, ist nicht „Wir haben vergessen, die Unveränderlichkeit zu aktivieren“, sondern „Die Unveränderlichkeit war in einem Modus aktiviert, den die gestohlenen Anmeldedaten des Angreifers abschalten konnten“. Die Mechanik haben wir ausführlicher beschrieben in echte Unveränderlichkeit mit S3-Objektspeicher (auf Englisch). Die Aufbewahrung muss Ihre Erkennungslücke überdauern Die Aufbewahrungsdauer wird meist aus einer Compliance-Anforderung abgeleitet. Bei Ransomware sollte sie sich an der Verweildauer (Dwell Time) orientieren – der Zeitspanne zwischen der ersten Kompromittierung und ihrer Erkennung, die häufig Wochen beträgt. Beträgt die Aufbewahrung 14 Tage und war der Angreifer 30 Tage präsent, kann jede unveränderliche Kopie, die Sie besitzen, bereits vergiftet sein. Die Unveränderlichkeit hat den falschen Zustand perfekt bewahrt. Legen Sie die Aufbewahrung anhand der tatsächlich beobachteten Erkennungslücke fest, nicht anhand der gewünschten. Dieselbe Überlegung gilt allgemein für schleichende Kompromittierungen – siehe Wiederherstellung nach Zero-Day-Angriffen. Isolation sicherer Kopien: den Wiederherstellungspfad vom Angriffspfad trennen Unveränderlichkeit schützt die Bytes. Gegen den Weg, über den Sie sie erreichen, unternimmt sie nichts. Die Isolation sicherer Kopien (Safe Copy Isolation) bedeutet, mindestens eine Wiederherstellungskopie über einen Pfad erreichbar zu halten, der keine Identität, kein Netzwerk und keine Control Plane mit der Produktion teilt. Der Test ist einfach: Wenn die Domäne kompromittiert ist und jede Produktions-Anmeldung als feindlich gilt – können Sie dann noch ein Backup einbinden und lesen? In vielen Architekturen lautet die ehrliche Antwort Nein, weil sich Backup-Katalog, Repository-Anmeldedaten und Wiederherstellungskonsole alle gegen dasselbe Verzeichnis authentifizieren, das nun der Angreifer kontrolliert. Isolation ist mehrschichtig, und die Schichten sind voneinander unabhängig: Identitätsisolation – Anmeldedaten für die Wiederherstellung stammen von einem separaten Identitätsanbieter, nicht aus dem Produktionsverzeichnis Netzwerkisolation – ein logischer Air Gap zwischen Produktion und Repository, wobei das Repository aus einem kompromittierten Produktionssegment nicht erreichbar ist Isolation der Control Plane – Aufbewahrungsrichtlinien werden an einer Stelle verwaltet, die der Backup-Server nicht erreicht Begrenzung des Blast Radius – keine einzelne kompromittierte Identität kann jede Kopie beeinflussen; das ist eine Frage der Fehlerdomäne, angewendet auf administrative Berechtigungen statt auf Hardware Eine hilfreiche Faustregel für das Design: Gehen Sie von einer vollständigen Kompromittierung aller Anmeldedaten aus und fragen Sie dann, welche Kopien überleben und welche Wiederherstellungspfade noch funktionieren. Alles, was diesen Test nicht besteht, ist Sicherheitstheater. Clean-Room-Wiederherstellung: wohin wiederhergestellte Daten gehen Wer eine kompromittierte VM in ein kompromittiertes Netzwerk zurückspielt, infiziert sie erneut. Das ist nicht hypothetisch, sondern einer der häufigeren Gründe, warum ein Wiederherstellungsversuch im ersten Anlauf scheitert und einen Tag kostet. Ein Clean Room ist eine isolierte Umgebung – separates Netzwerksegment, separate Identität, keine Route zurück in die Produktion –, in der wiederhergestellte Workloads hochgefahren, gescannt und validiert werden, bevor sie wieder in Betrieb gehen. Dort lässt sich die Frage beantworten, die den gesamten Zeitplan der Wiederherstellung bestimmt: Welcher Wiederherstellungspunkt ist der letzte bekannte fehlerfreie? Ohne Clean Room bedeutet die Suche nach diesem Wiederherstellungspunkt, Kandidaten in die Produktion zurückzuspielen und zu beobachten, was passiert. Das ist langsam und gefährlich zugleich. Mit einem Clean Room wird die Suche zu einer parallelen Hintergrundaktivität, die läuft, während der Rest der Wiederherstellung voranschreitet. Beachten Sie, dass sich dadurch die Anforderung an den Durchsatz ändert: Ein Clean Room bedeutet, dieselben Daten mehr als einmal wiederherzustellen, und das Repository muss das verkraften, ohne die primäre Wiederherstellung auszubremsen. Wiederherstellungstests: der einzige Beweis, dass all das funktioniert Ein erfolgreicher Backup-Job ist ein Signal für den Schreibpfad. Er bestätigt, dass Bytes übertragen wurden. Er sagt nichts darüber aus, ob diese Bytes ein bootfähiges, anwendungskonsistentes System ergeben – und ein grünes Dashboard voller erfolgreicher Jobs ist durchaus mit einem Repository vereinbar, aus dem sich nichts wiederherstellen lässt. Wiederherstellungstests schließen diese Lücke, müssen aber abgestuft sein, denn die günstigen Tests beweisen nicht viel: Verifizierung auf Objektebene – Prüfsummen und Aufbewahrungsstatus. Kontinuierlich, kostengünstig, beweist die Unversehrtheit der Daten. Wiederherstellung eines einzelnen Workloads – eine VM wird wiederhergestellt und gebootet. Wöchentlich. Beweist, dass die Pipeline durchgängig funktioniert. Anwendungskonsistente Wiederherstellung – eine Datenbank wird wiederhergestellt und abgefragt. Monatlich. Beweist Point-in-Time-Konsistenz, nicht nur den Abruf von Dateien. Massive parallele Wiederherstellung – Dutzende Workloads gleichzeitig, mit Zeitmessung. Vierteljährlich. Nur dieser Test liefert einen belastbaren Wert für VMs pro Stunde. Vollständige isolierte Wiederherstellung – eine Umgebung wird in einem Clean Room ausschließlich mit isolierten Kopien und Out-of-Band-Anmeldedaten neu aufgebaut. Jährlich. Beweist, dass die Isolation real ist. Die meisten Unternehmen führen die ersten beiden durch und gelten dann als getestet. An den letzten beiden scheitern Architekturen – und genau deshalb werden sie ausgelassen: Sie sind störend und liefern unbequeme Zahlen. Diese Zahlen sind das eigentliche Ergebnis. Backup-Ebenen und wo die Wiederherstellungsgeschwindigkeit wirklich entsteht Backup-Architekturen sind häufig in Ebenen gegliedert: eine Performance-Ebene für aktuelle Wiederherstellungspunkte, eine Kapazitätsebene für kosteneffiziente Skalierung und eine Langzeitebene für Aufbewahrung und Compliance. Lange Zeit galt Objektspeicher als nur für die zweite und dritte Ebene geeignet. Diese Annahme ist überholt – Backup-Anbieter validieren Objektspeicher inzwischen auch für die Performance-Ebene, einschließlich Instant Recovery, bei der ein Workload direkt aus dem Backup eingebunden und ausgeführt wird, während im Hintergrund die vollständige Wiederherstellung läuft. Speziell bei Ransomware hat das zur Folge, dass die beiden Anforderungen nicht mehr konkurrieren. Sie brauchen schnellen Zugriff auf aktuelle Wiederherstellungspunkte, um eine ehrgeizige RTO zu erreichen, und eine lange unveränderliche Aufbewahrung, um eine lange Erkennungslücke zu überstehen. Erstreckt sich Objektspeicher über alle drei Ebenen, stammen beide aus einer Architektur statt aus zweien. Die skalierbare Backup-Ziel-Architektur zeigt, wie das typischerweise aufgebaut ist; die Begriffe erläutert der Eintrag Backup-Ziel im Glossar. Checkliste zur Bereitschaft für die Wiederherstellung nach Ransomware Unveränderlichkeit Aufbewahrung wird auf der Speicherebene durchgesetzt, nicht von der Backup-Anwendung Compliance-Modus, wo die Kopie einen kompromittierten Administrator überstehen muss Aufbewahrungsdauer an der beobachteten Erkennungslücke ausgerichtet, nicht am Compliance-Minimum Änderungen an der Aufbewahrung werden protokolliert und gemeldet, nicht nur für privilegierte Rollen erlaubt Isolation Mindestens eine Kopie ist ohne Produktionsidentität erreichbar Repository ist aus einem kompromittierten Produktionsnetzwerksegment nicht erreichbar Aufbewahrungsrichtlinien werden außerhalb der Reichweite des Backup-Servers verwaltet Keine einzelne Identität hat Befugnis über jede Kopie Wiederherstellungsgeschwindigkeit Ein angegebener Wert für VMs pro Stunde aus einem Test mit Zeitmessung, nicht aus einem Datenblatt Bekannte Obergrenze der Parallelität und ein bekannter Grund dafür Wiederherstellungsreihenfolge nach geschäftlichen Abhängigkeiten festgelegt, nicht alphabetisch Instant Recovery validiert, wenn die RTO davon abhängt Validierung Wiederherstellungstests auf allen fünf Stufen, nach festem Plan Eine Clean-Room-Umgebung, die existiert, bevor sie gebraucht wird Eine dokumentierte Methode, um den letzten bekannten fehlerfreien Wiederherstellungspunkt zu ermitteln Runbooks, die auch jemand ausführen kann, der das System nicht entworfen hat Häufig gestellte Fragen Wie schnell sollte die Wiederherstellung nach Ransomware sein? Es gibt keinen universellen Zielwert – die sinnvolle Frage ist, ob Ihre gemessene Wiederherstellungszeit kürzer ist als der Ausfall, den Ihr Unternehmen verkraften kann. Drücken Sie sie in wiederhergestellten Workloads pro Stunde aus, leiten Sie die Gesamtdauer aus Ihrer tatsächlichen Anzahl an Workloads ab und vergleichen Sie das Ergebnis mit der vom Geschäft angegebenen Toleranz. Wurden diese beiden Zahlen noch nie nebeneinandergestellt, ist das die erste Aufgabe. Garantiert unveränderlicher Speicher die Wiederherstellung nach Ransomware? Nein. Unveränderlichkeit garantiert, dass eine Kopie in dem Zustand existiert, in dem sie geschrieben wurde. Sie garantiert nicht, dass dieser Zustand sauber war, dass Sie die Kopie ohne Produktions-Anmeldedaten erreichen oder dass Sie schnell genug daraus wiederherstellen können. Sie ist eine notwendige, aber keine hinreichende Bedingung. Warum ist Objektspeicher bei großen Wiederherstellungen schneller? Weil ein flacher Namespace keine Verzeichnis-Metadaten hat, über die serialisiert werden müsste. Wiederherstellungsströme arbeiten unabhängig voneinander, sodass der Durchsatz mit der Parallelität skaliert, statt darunter zu leiden. Bei einer Massenwiederherstellung – Hunderte oder Tausende Workloads gleichzeitig – ist die Parallelität der dominierende Faktor in der Gleichung der Wiederherstellungszeit. Was ist die Isolation sicherer Kopien? Mindestens eine Wiederherstellungskopie über einen Pfad erreichbar zu halten, der keine Identität, kein Netzwerk und keine Control Plane mit der Produktion teilt. Der Test lautet, ob Sie ein Backup noch einbinden und lesen könnten, wenn Sie davon ausgehen, dass sich jede Produktions-Anmeldung in feindlichen Händen befindet. Wie oft sollten Wiederherstellungstests stattfinden? Abgestuft nach Kosten und Störung: Objektverifizierung kontinuierlich, Wiederherstellungen einzelner Workloads wöchentlich, anwendungskonsistente Wiederherstellungen monatlich, massive parallele Wiederherstellungen mit Zeitmessung vierteljährlich und eine vollständige isolierte Wiederherstellung jährlich. Der vierteljährliche Test liefert den Wert für VMs pro Stunde, den Sie belegen können. Wiederherstellung ist ein Vorgang, keine Konfiguration Architekturen, die sich gut wiederherstellen lassen, zeichnen sich nicht durch mehr aktivierte Schutzfunktionen aus, sondern dadurch, dass etwas gemessen wurde. Sie kennen ihren Wert für VMs pro Stunde, weil sie ihn gemessen haben. Sie wissen, dass ihre Isolation hält, weil sie sie unter der Annahme verlorener Produktions-Anmeldedaten getestet haben. Sie wissen, welcher Wiederherstellungspunkt sauber ist, weil sie einen Ort geschaffen haben, um es herauszufinden. Unveränderlichkeit, Isolation, Parallelität und Validierung sind vier unabhängige Eigenschaften, und eine Lücke bei einer davon macht die anderen drei nahezu zur Dekoration. Objektspeicher ist ein gutes Fundament, weil er durchsetzbare Aufbewahrung und parallele Wiederherstellung im selben System bietet – doch das Fundament ist nicht das Ergebnis. Das Ergebnis ist eine Zahl, die Sie laut aussprechen können. Wenn Sie Ihre heute nicht nennen können, ist genau das die Erkenntnis. Alles Weitere folgt daraus, das zu beheben. Scality entwickelt cyberresilienten S3-Objektspeicher für die Wiederherstellung im großen Maßstab. Entdecken Sie die Architektur oder stöbern Sie im Glossar nach den Begriffen aus diesem Leitfaden.
