Unveränderliche Backups: Verhindern, dass Ransomware Wiederherstellungskopien löscht

Ransomware begnügt sich längst nicht mehr damit, Dateien in Produktionsumgebungen zu verschlüsseln. Ein fähiger Angriff sucht auch nach den Systemen, die den Schaden rückgängig machen könnten: Backup-Server, Management-Konsolen, Snapshot-Speicher und Cloud-Repositories. Wenn Angreifer diese Kopien löschen oder verschlüsseln können, bevor sie eine Zahlung fordern, verliert das Unternehmen seinen sichersten Weg zurück zum normalen Betrieb.

Unveränderliche Backups schließen genau diese Schwachstelle. Sie erstellen Wiederherstellungspunkte, die während eines festgelegten Aufbewahrungszeitraums nicht geändert oder gelöscht werden können – selbst dann nicht, wenn ein Angreifer weitreichende Zugangsdaten erlangt hat. Damit sind sie ein zentraler Bestandteil des Ransomware-Schutzes, aber allein noch keine vollständige Wiederherstellungsstrategie. Auch Verschlüsselung, Schlüsselverwaltung, Zugriffskontrollen, Überwachung und verifizierte Wiederherstellungen sind wichtig.

Für Unternehmen, die ihre eigenen Server betreiben, bietet Safenix ein in Deutschland gespeichertes Offsite-Backup. Die Backup-Daten werden mit einem Schlüssel verschlüsselt, den Safenix niemals besitzt, und die Kopien bleiben während des ausgewählten Aufbewahrungszeitraums unveränderlich. So entsteht eine von der Produktionsumgebung getrennte Wiederherstellungsebene, die vor unbefugtem Löschen geschützt ist. Safenix schützt vom Kunden kontrollierte Server, bietet jedoch keine Backup-Tarife für Websites auf Shared-Hosting-Plattformen.

Warum Ransomware Backup-Systeme angreift

Viele Unternehmen betrachten Backups als eine Sammlung von Dateien, die auf ihre Wiederherstellung wartet. Angreifer sehen darin etwas Wertvolleres: eine Karte der Widerstandsfähigkeit des Unternehmens. Sobald sie Zugriff auf ein Server-Administratorkonto, eine Virtualisierungsplattform, eine Backup-Konsole oder eine privilegierte Cloud-Identität erlangen, können sie möglicherweise herausfinden, wo Kopien gespeichert sind und wie lange sie aufbewahrt werden.

Der Angriffsablauf umfasst häufig mehrere Phasen:

• Zugangsdaten eines privilegierten Benutzers stehlen oder erraten.
• Endpoint-Schutz und Überwachung deaktivieren.
• Vom Ausgangssystem zu Dateiservern, Datenbanken und Virtualisierungshosts wechseln.
• Nach Backup-Software, Repositories, Snapshots und Dienstkonten suchen.
• Wiederherstellungspunkte löschen oder ihre Aufbewahrungseinstellungen verkürzen.
• Produktionsdaten und alle noch erreichbaren Backup-Kopien verschlüsseln.
• Zahlung fordern und behaupten, eine Wiederherstellung sei ohne den Schlüssel des Angreifers unmöglich.

Ein Backup-Repository, das lediglich mit demselben Identitätssystem oder Netzwerk verbunden ist, kann daher gefährdet sein, selbst wenn es sich auf separater Hardware befindet. Physische Trennung ist hilfreich, macht eine Kopie jedoch nicht automatisch sicher. Wenn ein kompromittierter Administrator einen Löschbefehl ausführen kann, kann das Repository genau in dem Moment versagen, in dem es gebraucht wird.

Ransomware-Schutz muss die Möglichkeit berücksichtigen, dass der Angreifer über Administratorrechte verfügt. Die Frage ist nicht nur, ob unbefugte Benutzer das Backup-System erreichen können. Entscheidend ist, ob irgendjemand – einschließlich eines kompromittierten legitimen Kontos – den letzten sauberen Wiederherstellungspunkt entfernen kann.

Was unveränderliche Backups tatsächlich verhindern

Ein unveränderliches Backup ist ein Wiederherstellungspunkt, der für einen festgelegten Zeitraum vor Änderung oder Löschung geschützt ist. Während dieses Zeitraums können die Daten nicht durch gewöhnliche administrative Vorgänge überschrieben, verändert oder entfernt werden. Der Schutz gilt für das gespeicherte Objekt oder den Backup-Datensatz und beruht nicht allein auf einer Richtlinie, die einem Administrator das Löschen untersagt.

Unveränderlichkeit lässt sich am besten als Durchsetzungsmechanismus verstehen. Eine Aufbewahrungsrichtlinie legt fest, dass eine Kopie 30, 90 oder 365 Tage verfügbar bleiben soll. Eine unveränderliche Aufbewahrungsrichtlinie macht es technisch schwierig oder unmöglich, diese Vorgabe vor Ablauf des Zeitraums zu umgehen. Dieser Unterschied wird entscheidend, wenn Zugangsdaten gestohlen wurden.

Angenommen, ein Unternehmen erstellt tägliche Backups mit einer Aufbewahrungsfrist von 90 Tagen. Erlangt ein Angreifer Zugriff auf die Backup-Konsole und ändert die Einstellung auf einen Tag, bietet die Richtlinie keinen praktischen Schutz. Sind dieselben Wiederherstellungspunkte jedoch bis zu ihrem Ablaufdatum gegen Löschung gesperrt, entfernt eine Änderung der Konsoleneinstellung die gesperrten Objekte nicht.

Unveränderlichkeit bedeutet nicht, dass jedes Backup dauerhaft gespeichert wird. Kopien können normalerweise nach Ablauf ihrer Aufbewahrungsfrist gelöscht werden. Sie garantiert auch nicht, dass die Daten nutzbar sind. Eine beschädigte Datenbank, ein unvollständiges Anwendungsbackup oder ein nicht getestetes Wiederherstellungsverfahren kann weiterhin zu einem Wiederherstellungsfehler führen. Unveränderlicher Speicher schützt die Existenz und Integrität der Kopie; er prüft nicht automatisch, was sich darin befindet.

Unveränderlichkeit im Vergleich zur gewöhnlichen Aufbewahrung

Die gewöhnliche Aufbewahrung ist ein Zeitplan. Sie bestimmt, wie viele Wiederherstellungspunkte ein Backup-System behalten soll und wann ältere Punkte entfernt werden dürfen. Dieser Zeitplan ist für die Verwaltung der Speicherkosten notwendig, kann jedoch von derselben Konsole und denselben Administratorkonten gesteuert werden, auf die es Angreifer abgesehen haben.

Eine unveränderliche Aufbewahrung ergänzt den Zeitplan um eine technische Einschränkung. Sobald eine Kopie festgeschrieben wurde, kann sie vor Ablauf ihrer Sperrfrist nicht gelöscht werden. Ein gutes Design trennt die Entscheidung über die Aufbewahrung von der täglichen Backup-Administration, damit ein kompromittierter Betreiber das Zeitfenster nach Beginn eines Vorfalls nicht verkürzen kann.

Beide Kontrollen ergänzen sich:

• Aufbewahrung definiert, wie weit zurück das Unternehmen eine Wiederherstellung durchführen möchte.
• Unveränderlichkeit verhindert, dass eine geschützte Kopie vor diesem Zeitpunkt entfernt oder geändert wird.
• Versionierung kann mehrere Wiederherstellungszustände statt einer fortlaufend aktualisierten Kopie bewahren.
• Wiederherstellungstests bestätigen, dass die aufbewahrten Daten tatsächlich eine Wiederherstellung ermöglichen.

Unveränderlichkeit ist nicht dasselbe wie eine Offline-Kopie

Ein Offline-Backup ist von Produktionssystemen, Netzwerken oder administrativen Schnittstellen getrennt. Das kann sehr effektiv sein, da Ransomware eine Kopie nicht direkt verschlüsseln oder löschen kann, auf die sie keinen Zugriff hat. Außerhalb des Netzwerks gelagerte Bänder sind ein traditionelles Beispiel. Eine Wechselfestplatte, die regelmäßig für Backups angeschlossen wird, bietet möglicherweise weniger Schutz, wenn sie während eines Angriffs verbunden bleibt.

Offline-Speicher und unveränderlicher Speicher lösen verwandte, aber unterschiedliche Probleme. Offline-Kopien verringern die Angriffsfläche, indem sie die Verbindung entfernen. Unveränderliche Kopien bleiben für automatisierte Backups und Wiederherstellungen erreichbar, während sie während der Sperrfrist Änderungen blockieren. Ein widerstandsfähiges Design kann beides einsetzen, insbesondere wenn die Wiederherstellungsanforderungen den betrieblichen Aufwand rechtfertigen.

Es gibt Zielkonflikte. Vollständig offline gelagerte Medien können häufige Backups, Überwachung und schnelle Wiederherstellungen erschweren. Jemand muss die Medien wechseln, sie physisch schützen, die verfügbare Version nachverfolgen und sicherstellen, dass sie bei Bedarf gelesen werden kann. Unveränderlicher Online- oder Offsite-Speicher ist möglicherweise leichter zu betreiben, muss jedoch ordnungsgemäß von kompromittierten Identitäten und Management-Systemen isoliert werden.

Wichtig ist, eine getrennte Kopie nicht automatisch als sicher einzustufen. Eine Offline-Festplatte kann verloren gehen, beschädigt werden, bereits vor der Trennung infiziert gewesen sein oder versehentlich überschrieben werden. Sie benötigt ebenso wie jedes andere Backup Bestandskontrollen, Zugriffsbeschränkungen und Wiederherstellungstests.

Zugriffskontrollierter Speicher ist nicht automatisch unveränderlich

Die Beschränkung des Zugriffs auf ein Repository ist unverzichtbar, verhindert allein jedoch keine Löschung. Ein Administrator kann die einzige zugriffsberechtigte Person sein und trotzdem die Berechtigung besitzen, jeden Wiederherstellungspunkt zu löschen. Wird dieses Administratorkonto kompromittiert, wird die Kontrolle zur Fähigkeit des Angreifers.

Das Prinzip der geringsten Berechtigung sollte daher auf mehreren Ebenen angewendet werden. Das Konto, das Backups schreibt, sollte nicht zwangsläufig auch die Berechtigung haben, sie zu löschen. Das Konto für die Verwaltung von Backup-Aufträgen sollte nicht unbedingt Aufbewahrungssperren ändern können. Die Person, die eine Wiederherstellung genehmigt, sollte nicht automatisch Zugriff auf Verschlüsselungsschlüssel oder die Repository-Konfiguration haben.

Multi-Faktor-Authentifizierung, getrennte administrative Identitäten, Netzwerkbeschränkungen und Genehmigungsprozesse verringern die Wahrscheinlichkeit, dass ein gestohlenes Passwort zu einer vollständigen Kompromittierung führt. Sie sind wichtige Schutzmaßnahmen, ersetzen jedoch keine Unveränderlichkeit. Ein Angreifer kann eine Kontrolle über einen verwundbaren Endpunkt, ein gestohlenes Sitzungstoken oder Social Engineering umgehen. Ein gesperrter Wiederherstellungspunkt bietet Schutz, nachdem präventive Kontrollen versagt haben.

Object Lock, WORM und isolierte Repositories

Unveränderliche Backups lassen sich auf verschiedene Weise implementieren. Die Begriffe unterscheiden sich je nach Produkt, die Designprinzipien sind jedoch einheitlich: Daten an einem geschützten Ort festschreiben, eine Aufbewahrungsfrist anwenden und Löschung oder Änderung bis zu deren Ablauf verhindern. Unternehmen sollten verstehen, was genau gesperrt wird, wer die Richtlinie ändern kann und ob ein Administrator die Sperrfrist verkürzen kann.

Object-Lock-Speicher

Object Lock wird häufig mit Objektspeicher verwendet. Jedes Backup-Objekt erhält einen Aufbewahrungszeitpunkt, und der Speicherdienst lehnt Lösch- oder Überschreibanforderungen vor diesem Zeitpunkt ab. Manche Implementierungen bieten einen Governance-Modus, der autorisierte Ausnahmen erlaubt, sowie einen strengeren Compliance-Modus, der solche Ausnahmen – auch durch Administratoren – verhindern soll.

Der Unterschied ist wichtig. Eine Sperre nach dem Governance-Modell kann für alltägliche Bedienfehler ausreichen, ist jedoch weniger geeignet, wenn das Bedrohungsmodell eine gestohlene Administratoridentität umfasst. Ein strengerer Modus bietet stärkeren Schutz, erfordert aber eine sorgfältige Planung der Aufbewahrung, da Fehler nicht einfach durch Löschen des Objekts korrigiert werden können.

Object Lock eignet sich gut für große Repositories und automatisierte Backup-Workflows. Dennoch müssen auch das Speicherkonto, API-Zugangsdaten, Bucket-Konfiguration, Replikationseinstellungen und Protokollierung geschützt werden. Ein Angreifer kann gesperrte Objekte möglicherweise nicht löschen, könnte aber versuchen, neue Backups zu stoppen, Auftragspläne zu ändern oder die Management-Ebene anzugreifen.

WORM-Speicher

WORM steht für „Write Once, Read Many“ – einmal schreiben, vielfach lesen. Ein WORM-System erlaubt das Schreiben und Lesen von Daten, verhindert jedoch, dass sie während der Schutzfrist geändert oder entfernt werden. WORM kann in Objektspeichern, spezialisierten Appliances oder anderen Speicherarchitekturen implementiert werden.

WORM beschreibt das Speicherverhalten, ist jedoch keine Garantie dafür, dass jedes Produkt mit dieser Bezeichnung dasselbe Sicherheitsniveau bietet. Fragen Sie, ob die Aufbewahrungsfrist von der Speicherebene durchgesetzt wird, ob ein Administrator sie umgehen kann, wie das System mit Uhrzeitänderungen umgeht und was bei Kapazitäts- oder Replikationsfehlern geschieht.

Isolierte Backup-Repositories

Ein isoliertes Repository trennt Backup-Daten vom Produktionsnetzwerk, vom Identitätsverzeichnis und von der Management-Ebene. Die Isolation kann physisch, logisch oder beides sein. Sie kann ein separates Konto, eigene Zugangsdaten, eingeschränkte Netzwerkpfade, einen unidirektionalen Backup-Pfad und einen eigenen Administrationsprozess umfassen.

Isolation ist besonders wertvoll, wenn ein Kunde mehrere Server oder Standorte betreibt. Selbst wenn eine Produktionsumgebung kompromittiert wird, sollte der Angreifer nicht automatisch Zugriff auf jedes Repository erhalten. Das Repository sollte nur die für die Aufnahme und Bereitstellung von Backups erforderlichen Berechtigungen erhalten, während Löschungen und Änderungen der Aufbewahrung durch eine separate Kontrolle geschützt bleiben.

Eine praktische Gegenüberstellung dieser Ansätze, einschließlich Konzepten für unveränderliche Backups und Ransomware-Schutz, finden Sie in den aktuellen Empfehlungen zu Ansätzen für unveränderliche Backups zum Ransomware-Schutz sowie in der technischen Dokumentation der jeweils in Betracht gezogenen Speicherplattform.

Warum Verschlüsselung und Schlüsselverwaltung wichtig sind

Unveränderlichkeit verhindert, dass ein Angreifer ein Backup löscht oder verändert. Verschlüsselung schützt den Inhalt, wenn jemand Zugriff auf den Speicher erlangt, die Daten kopiert oder auf die zugrunde liegende Infrastruktur zugreift. Beide Kontrollen sind notwendig, denn ein Backup, das Ransomware übersteht, aber Gehalts-, Kunden-, Rechts- oder Gesundheitsdaten offenlegt, führt zu einem anderen Sicherheitsvorfall.

Die Verschlüsselung sollte Daten während der Übertragung und im Ruhezustand abdecken. Der Backup-Agent sollte die Daten über eine geschützte Verbindung übertragen, und gespeicherte Backup-Daten sollten im Repository verschlüsselt bleiben. Verschlüsselung verringert den Wert gestohlener Speicherdaten jedoch nur dann, wenn die Schlüssel getrennt von den Daten verwaltet werden und nicht jedem Administrator zur Verfügung stehen, der auf die Backup-Plattform zugreifen kann.

Der Verwahrung der Schlüssel verdient besondere Aufmerksamkeit. Besitzt der Dienstanbieter den einzigen verwendbaren Entschlüsselungsschlüssel, könnte eine Kompromittierung der Systeme des Anbieters oder eine unbefugte interne Handlung die Daten offenlegen. Kontrolliert der Kunde den Schlüssel, erhält er eine stärkere Kontrolle über die Vertraulichkeit, übernimmt aber auch die Verantwortung, den Schlüssel zu schützen und einen funktionsfähigen Wiederherstellungsprozess aufrechtzuerhalten.

Safenix verwendet vom Kunden kontrollierte Verschlüsselungsschlüssel, die Safenix niemals besitzt. Dieser Ansatz hilft, die Speicherrolle des Anbieters von der Fähigkeit des Kunden zu trennen, die eigenen Daten zu entschlüsseln. Unternehmen, die dieses Modell bewerten, können sich über den Verschlüsselungsansatz von Safenix und die vom Kunden gehaltenen Schlüssel informieren und anschließend prüfen, wie Schlüsselerzeugung, Sicherung, Rotation, Zugriff und Notfallwiederherstellung in der eigenen Umgebung funktionieren sollen.

Die Schlüsselverwaltung sollte vor einem Vorfall dokumentiert werden. Legen Sie fest, wer auf den Schlüssel zugreifen darf, wie der Zugriff autorisiert wird, wo eine Notfallkopie aufbewahrt wird und wie das Unternehmen wiederhergestellt werden kann, wenn der übliche Schlüsseladministrator nicht verfügbar ist. Ein verlorener Schlüssel kann ein ansonsten intaktes unveränderliches Backup unwiederherstellbar machen.

Backup-Aufbewahrung für die Ransomware-Wiederherstellung planen

Auf die Frage „Wie lange sollten unveränderliche Backups aufbewahrt werden?“ gibt es keine allgemeingültige Antwort. Der richtige Zeitraum hängt davon ab, wie schnell ein Angriff erkannt wird, wie lange ein Angreifer unbemerkt bleiben kann, welche gesetzlichen und vertraglichen Pflichten bestehen und wie viel Zeit für die Untersuchung und den Wiederaufbau von Systemen erforderlich ist.

Ein kurzes Aufbewahrungsfenster kann für eine kleine Umgebung mit schneller Erkennung und geringer Datenkomplexität ausreichen. Für ein Unternehmen, in dem eine Kompromittierung wochenlang verborgen bleiben kann, könnte es gefährlich sein. Wenn verschlüsselte oder veränderte Dateien 30 Tage lang in tägliche Backups aufgenommen werden, bevor der Vorfall entdeckt wird, bietet ein 30-tägiges unveränderliches Fenster möglicherweise keinen sauberen Wiederherstellungspunkt.

Faktoren, die das Aufbewahrungsfenster beeinflussen sollten

• Erkennungszeit: Schätzen Sie, wie lange es dauern könnte, ungewöhnliche Verschlüsselung, Kontomissbrauch oder stille Datenbeschädigung zu erkennen.
• Untersuchungszeit: Bewahren Sie saubere Wiederherstellungspunkte lange genug auf, um den Angriff zu analysieren, ohne Beweise zu zerstören oder aus einem kontaminierten Zeitraum wiederherzustellen.
• Wiederherstellungszeit: Berücksichtigen Sie die Zeit für den Wiederaufbau der Infrastruktur, die Validierung von Anwendungen und die schrittweise Datenwiederherstellung.
• Geschäftsauswirkungen: Kritische Systeme können eine längere Aufbewahrung und häufigere Wiederherstellungspunkte rechtfertigen.
• Compliance und Verträge: Für manche Aufzeichnungen gelten längere Aufbewahrungspflichten. Die Backup-Aufbewahrung sollte jedoch nicht als vollständige Richtlinie für das Aufzeichnungsmanagement betrachtet werden.
• Speicherkosten: Eine längere Aufbewahrung benötigt mehr Speicher. Verwenden Sie daher Speicherklassen oder Zeitpläne, die zum Wert und zur Änderungsrate jeder Arbeitslast passen.

Ein sinnvoller Ansatz kombiniert operative Backups in kurzen Abständen mit länger aufbewahrten Wiederherstellungspunkten. Ein Unternehmen kann beispielsweise häufige aktuelle Kopien für eine schnelle Wiederherstellung, tägliche Kopien über mehrere Wochen sowie ausgewählte wöchentliche oder monatliche Punkte über einen längeren Zeitraum aufbewahren. Der genaue Zeitplan sollte sich an den Wiederherstellungszielen und nicht an einer Standardeinstellung orientieren.

Lassen Sie die Aufbewahrungsfrist nicht ablaufen, während ein Vorfall noch untersucht wird. Wird eine mögliche Kompromittierung entdeckt, bewahren Sie relevante unveränderliche Punkte auf und verlängern Sie die Frist oder exportieren Sie benötigte Daten separat für forensische Arbeiten und Wiederherstellungen, soweit es das Speicherkonzept erlaubt. Das Incident-Team sollte wissen, welche Kopien gesperrt sind und wann sie ablaufen.

Wiederherstellung bei gestohlenen Administratorzugangsdaten

Gestohlene Zugangsdaten setzen unveränderliche Backups nicht automatisch außer Kraft. Wenn der Angreifer auf die Backup-Konsole zugreifen kann, die Wiederherstellungspunkte jedoch im Speicher gesperrt sind, kann er möglicherweise zukünftige Aufträge stoppen oder den Betrieb stören, ohne die geschützten Kopien zu löschen. Diese Trennung ist einer der wichtigsten Gründe für den Einsatz unveränderlichen Speichers.

Die Reaktion sollte dennoch unverzüglich und methodisch erfolgen:

1. Betroffene Systeme isolieren. Trennen Sie kompromittierte Server oder Netzwerksegmente, sofern dies praktikabel ist. Verhindern Sie, dass der Angreifer weiterhin Daten verschlüsselt oder zusätzliche Systeme erreicht.
2. Zugangsdaten deaktivieren und rotieren. Widerrufen Sie gestohlene Sitzungen, setzen Sie privilegierte Passwörter zurück und rotieren Sie Dienstzugangsdaten. Prüfen Sie API-Schlüssel, Token und Konten, die auf Repositories oder Verschlüsselungssysteme zugreifen können.
3. Die Backup-Umgebung schützen. Beschränken Sie den Konsolenzugriff, blockieren Sie verdächtige Quelladressen, prüfen Sie administrative Änderungen und bestätigen Sie, dass Aufbewahrungssperren weiterhin aktiv sind.
4. Zerstörerische Automatisierung stoppen. Halten Sie Aufträge oder Integrationen an, die saubere Daten überschreiben könnten, und bewahren Sie bereits festgeschriebene unveränderliche Kopien.
5. Den letzten bekannten sauberen Punkt ermitteln. Nutzen Sie Protokolle, Endpoint-Beweise und Anwendungskontrollen, um den Beginn der Kompromittierung zu bestimmen. Gehen Sie nicht davon aus, dass das neueste Backup sicher ist.
6. Vertrauenswürdige Infrastruktur neu aufbauen. Stellen Sie zentrale Identitäts-, Netzwerk- und Management-Komponenten aus bekannten sauberen Quellen wieder her, anstatt kompromittierte Systeme weiterzuverwenden.
7. In einer kontrollierten Umgebung wiederherstellen. Stellen Sie zunächst ein repräsentatives System wieder her, scannen Sie es, validieren Sie seine Konfiguration und prüfen Sie, ob Anwendungen und Daten korrekt funktionieren.
8. Entscheidungen und Beweise dokumentieren. Halten Sie fest, welcher Wiederherstellungspunkt verwendet wurde, wer ihn genehmigt hat, was wiederhergestellt wurde und welche Kompromittierungsindikatoren gefunden wurden.

Testen Sie eine Wiederherstellung niemals, indem Sie direkt über die einzige verbleibende Produktionskopie wiederherstellen. Verwenden Sie nach Möglichkeit ein isoliertes Netzwerk oder ein separates Ziel. So verhindern Sie, dass ein beschädigtes oder kompromittiertes Backup die saubere Umgebung beschädigt, und geben dem Reaktionsteam einen sicheren Ort für die Validierung.

Wiederherstellungstests sind Teil der Backup-Sicherheit

Eine unveränderliche Kopie, die nicht wiederhergestellt werden kann, ist ein teures Archiv und kein verlässlicher Wiederherstellungsplan. Backup-Aufträge können erfolgreich gemeldet werden, obwohl eine Anwendungsdatenbank fehlt, eine erforderliche Konfigurationsdatei ausgeschlossen wurde, kein konsistenter Zustand erfasst wurde oder die Wiederherstellung ungelöste Abhängigkeiten aufweist.

Wiederherstellungstests sollten regelmäßig stattfinden und die Systeme abbilden, die das Unternehmen tatsächlich benötigt. Ein Test auf Dateiebene ist nützlich, beweist jedoch nicht, dass eine gesamte Anwendung wieder online gebracht werden kann. Testen Sie mehrere Wiederherstellungstypen:

• Einzelne Dateien wiederherstellen und Berechtigungen, Eigentümer sowie Zeitstempel bestätigen.
• Eine Datenbank wiederherstellen und Anwendungstransaktionen sowie Indizes validieren.
• Einen vollständigen Server oder eine virtuelle Maschine in einer isolierten Umgebung wiederherstellen.
• Einen kritischen Dienst neu aufbauen, wenn die ursprüngliche Infrastruktur nicht verfügbar ist.
• Überprüfen, ob Verschlüsselungsschlüssel verfügbar sind und von autorisiertem Wiederherstellungspersonal verwendet werden können.
• Die Dauer der Wiederherstellung messen und mit dem geschäftlichen Wiederherstellungsziel vergleichen.

Verwenden Sie Testdaten mit Bedacht. Eine Wiederherstellungsumgebung kann personenbezogene oder vertrauliche Informationen enthalten und benötigt daher geeignete Zugriffskontrollen und Entsorgungsverfahren. Führen Sie ein schriftliches Protokoll über Testergebnisse, Fehler und Korrekturmaßnahmen. Ein Test, der eine fehlende Abhängigkeit aufdeckt, ist nur dann wertvoll, wenn das Backup-Design anschließend angepasst wird.

Mindestens eine Übung sollte den Verlust der Produktionsumgebung und der Backup-Konsole simulieren. Dabei wird geprüft, ob das Unternehmen geschützte Kopien finden, sich beim Wiederherstellungsdienst authentifizieren, auf kundengesteuerte Schlüssel zugreifen und wiederherstellen kann, ohne auf einen kompromittierten Management-Server angewiesen zu sein.

Überwachung und geringste Berechtigung für unveränderliche Kopien

Unveränderlichkeit verringert die Auswirkungen von Löschversuchen, aber Überwachung hilft, den Angriff zu erkennen, bevor eine Wiederherstellung erforderlich wird. Achten Sie auf Änderungen der Backup-Häufigkeit, ungewöhnliche Datenmengen, fehlgeschlagene Aufträge, neue Administratoren, Änderungen an Aufbewahrungsrichtlinien, Zugriffe von unbekannten Standorten und plötzliche Versuche, Repositories aufzulisten.

Warnmeldungen sollten Personen erreichen, die nicht ausschließlich auf die möglicherweise kompromittierte Produktionsumgebung angewiesen sind. Wenn Ransomware E-Mail- oder Überwachungstools deaktiviert, wird eine ausschließlich über diese Tools zugestellte Backup-Fehlermeldung möglicherweise nie gesehen. Schützen Sie Protokolle vor Änderungen und bewahren Sie ausreichend Historie auf, um zu untersuchen, wer auf den Backup-Dienst zugegriffen hat und welche Aktionen versucht wurden.

Die geringsten Berechtigungen sollten regelmäßig überprüft werden, statt sie einmal zu konfigurieren und anschließend zu vergessen. Entfernen Sie inaktive Konten, trennen Sie menschliche und Dienstidentitäten, beschränken Sie die Quellnetzwerke für Management-Schnittstellen und verlangen Sie Multi-Faktor-Authentifizierung für privilegierten Zugriff. Verwenden Sie nach Möglichkeit getrennte Zugangsdaten für das Schreiben von Backups, Wiederherstellungen, Administration und die Verwaltung der Aufbewahrung.

Geben Sie einem Anwendungsserver keine weitreichende Berechtigung zum Löschen von Repository-Daten. Ein kompromittierter Server sollte die für sein Backup erforderlichen Daten senden können, nicht die gesamte Backup-Umgebung verwalten. Dasselbe Prinzip gilt für Agenturen, die mehrere Kundenumgebungen verwalten.

Mehrere Kundenumgebungen schützen, ohne Wiederherstellungen unpraktisch zu machen

Agenturen, Managed-Service-Provider und IT-Teams müssen häufig mehrere Unternehmen gleichzeitig schützen. Zentralisierung kann die Konsistenz verbessern, aber auch ein attraktives Ziel schaffen. Wenn ein gemeinsames Administratorkonto oder eine zentrale Management-Konsole jedes Kunden-Repository steuert, könnte ein einziges gestohlenes Zugangsmittel das gesamte Portfolio gefährden.

Ein sichereres Mehrkundenmodell trennt Mandanten, Zugangsdaten, Richtlinien und Wiederherstellungsberechtigungen. Jede Kundenumgebung sollte eine eigene logische Grenze und eine klare Zuständigkeit für die Verschlüsselungsschlüssel haben. Ein Techniker, der den Server eines Kunden wiederherstellen muss, sollte nicht automatisch die Backups eines anderen Kunden durchsuchen oder löschen können.

Die betriebliche Einfachheit bleibt dennoch wichtig. Eine übermäßige Trennung kann Wiederherstellungen verlangsamen oder verwirrend machen, insbesondere während eines größeren Vorfalls. Agenturen sollten für jeden Kunden einen klaren Servicekatalog pflegen, der Folgendes umfasst:

• Geschützte Server und Anwendungen.
• Backup-Häufigkeit und Aufbewahrungszeitraum.
• Status des unveränderlichen Speichers und Ablaufdaten.
• Eigentümer der Verschlüsselungsschlüssel und Verfahren für den Notfallzugriff.
• Genehmigte Ansprechpartner für Wiederherstellungen und erforderliche Autorisierungen.
• Wiederherstellungsprioritäten und Abhängigkeiten zwischen Systemen.
• Letzter erfolgreicher Wiederherstellungstest und offene Probleme.

Verwenden Sie Standardrichtlinien für ähnliche Arbeitslasten, machen Sie Ausnahmen jedoch ausdrücklich. Ein kleiner Dateiserver, ein Datenbank-Cluster und ein Domaincontroller können unterschiedliche Zeitpläne und Wiederherstellungsfolgen benötigen. Vorlagen helfen, Auslassungen zu vermeiden; sie ersetzen keine arbeitslastspezifischen Tests.

Agenturen sollten außerdem ein Szenario zur Mandantentrennung üben. Gehen Sie davon aus, dass das Administratorkonto eines Kunden kompromittiert wurde, und prüfen Sie, ob das Incident-Team den Zugriff dieses Mandanten unterbrechen kann, ohne die anderen zu beeinträchtigen. Führen Sie anschließend eine Wiederherstellung mit dem richtigen Kundenschlüssel, Genehmigungsweg und Ziel durch. So wird bestätigt, dass Sicherheitsgrenzen nicht zu einer betrieblichen Sackgasse führen.

Häufige Fehler, die den Schutz unveränderlicher Backups schwächen

Das einzige Backup auf dem Produktionsserver aufbewahren

Ein lokales Backup kann schnell und nützlich sein, teilt jedoch die Risiken des Produktionsservers. Ein Ransomware-Prozess mit Administratorrechten kann sowohl die aktiven Dateien als auch das lokale Backup-Verzeichnis verschlüsseln. Hardwareausfall, Feuer oder Diebstahl können ebenfalls beide Kopien gleichzeitig vernichten. Lokale Backups sollten die schnelle Wiederherstellung unterstützen und nicht die einzige Wiederherstellungsebene darstellen.

Annehmen, dass Snapshots unveränderlich sind

Snapshots sind praktische Zeitpunkte, können jedoch häufig von demselben Administrator gelöscht werden, der die Produktionsplattform kontrolliert. Einige Snapshots sind durch eingebundene Volumes oder geerbte Berechtigungen auch für Ransomware erreichbar. Betrachten Sie einen Snapshot nur dann als unveränderlich, wenn der zugrunde liegende Speicher eine Sperre durchsetzt, die die betreffenden Administratoren nicht umgehen können.

Ein Konto für alles verwenden

Ein einzelnes Konto, das Aufträge erstellt, Aufbewahrung ändert, Daten löscht und Verschlüsselung verwaltet, verfügt über zu viele Rechte. Außerdem erschwert es die Untersuchung, da keine sinnvolle Aufgabentrennung besteht. Verwenden Sie eigene Identitäten und dokumentieren Sie, welche Aktionen jede davon ausführen darf.

Den Prozess zur Schlüsselwiederherstellung ignorieren

Kundengesteuerte Verschlüsselung ist nur dann leistungsfähig, wenn der Kunde den Schlüssel im Notfall abrufen und verwenden kann. Bewahren Sie Wiederherstellungsanweisungen sicher auf, testen Sie den Zugriff mit autorisierten Personen und planen Sie für die Abwesenheit von Mitarbeitern. Legen Sie keine ungeschützte Schlüsselkopie neben dem Backup-Repository ab.

Nur testen, wenn etwas schiefgeht

Ein Notfall ist der schlechteste Zeitpunkt, um festzustellen, dass ein Backup-Agent eine Datenbank ausgeschlossen hat, eine Zugangsdaten abgelaufen ist oder dem Wiederherstellungsziel die Kapazität fehlt. Planen Sie Tests und behandeln Sie fehlgeschlagene Tests als Sicherheitsfeststellungen mit Verantwortlichen und Fristen.

Praktische Checkliste für die Sicherheit unveränderlicher Backups

Verwenden Sie die folgenden Fragen, wenn Sie ein bestehendes Backup-Design prüfen oder einen Offsite-Dienst bewerten:

• Kann Ransomware mit Produktionsadministratorrechten die gespeicherten Wiederherstellungspunkte löschen?
• Wird die Aufbewahrungssperre von der Speicherebene und nicht nur durch eine Einstellung in der Backup-Konsole durchgesetzt?
• Kann ein Administrator die Sperrfrist verkürzen oder umgehen?
• Werden Backups außerhalb des Produktionsnetzwerks und des Identitätssystems gespeichert?
• Sind Daten während der Übertragung und im Ruhezustand verschlüsselt?
• Wer besitzt den Verschlüsselungsschlüssel, und kann das Unternehmen ihn wiederherstellen, wenn ein Schlüsseladministrator nicht verfügbar ist?
• Sind Berechtigungen für Backup, Wiederherstellung, Löschung und Richtlinienverwaltung getrennt?
• Ist Multi-Faktor-Authentifizierung für privilegierten Zugriff aktiviert?
• Werden Änderungen, fehlgeschlagene Aufträge und verdächtige Zugriffsversuche überwacht?
• Berücksichtigt das Aufbewahrungsfenster die voraussichtliche Verweildauer von Ransomware im Unternehmen?
• Wurden vollständige Anwendungswiederherstellungen getestet und nicht nur einzelne Dateien?
• Kann das Unternehmen wiederherstellen, wenn die Produktions-Backup-Konsole kompromittiert wurde?
• Sind bei mehreren Kunden Mandanten, Zugangsdaten, Schlüssel und Wiederherstellungsberechtigungen getrennt?

Unveränderliche Backups sind eine Grundlage, nicht der gesamte Wiederherstellungsplan

Die Widerstandsfähigkeit gegen Ransomware beruht auf mehreren Ebenen. Endpoint-Schutz, Patchmanagement, Identitätssicherheit, Netzwerksegmentierung und geschulte Mitarbeiter verringern die Wahrscheinlichkeit einer Kompromittierung. Unveränderliche Offsite-Backups begrenzen den Schaden, wenn diese Kontrollen versagen. Verschlüsselung und kundengesteuerte Schlüssel schützen die Vertraulichkeit. Überwachung macht verdächtige Aktivitäten sichtbar. Wiederherstellungstests verwandeln gespeicherte Daten in eine funktionierende Wiederherstellungsfähigkeit.

Die wichtigste Unterscheidung besteht zwischen einem vorhandenen Backup und einem Wiederherstellungspunkt, der auch unter einem Angriff verfügbar bleibt. Eine gewöhnliche Aufbewahrung, ein zugriffskontrolliertes Repository oder ein Snapshot auf der Produktionsplattform übersteht einen kompromittierten Administrator möglicherweise nicht. Unveränderlicher Speicher ist für genau dieses Ausfallszenario konzipiert: Er bewahrt Wiederherstellungspunkte während des vereinbarten Aufbewahrungszeitraums, selbst wenn jemand mit gestohlenen Zugangsdaten versucht, sie zu löschen.

Für Unternehmen, die ihre eigenen Server kontrollieren, kann ein Offsite-Backup-Design mit Verschlüsselung, kundengehaltenen Schlüsseln, deutscher Datenspeicherung und Unveränderlichkeit eine starke unabhängige Wiederherstellungsebene bereitstellen. Die Schutzmaßnahmen sollten regelmäßig überprüft und getestet werden, denn unveränderlicher Speicher ersetzt keine verifizierten Wiederherstellungen. Er macht eine vertrauenswürdige Wiederherstellung möglich; eine disziplinierte Wiederherstellungspraxis beweist, dass sie funktioniert.