Saubere Wiederherstellung – nicht nur schnelle Wiederaufnahme
Die Wiederherstellung nach einem Ransomware-Angriff erfordert mehr als redundante Speicherung. Sichern Sie vertrauenswürdige Wiederherstellungspunkte, verhindern Sie den Zugriff von Angreifern auf alle Kopien und definieren Sie, wie ein verifizierter Geschäftsbetrieb wiederhergestellt wird
den Vorfall
einen fehlerfreien Zustand
durch separate Steuerung
Cyberresilienz beginnt vor dem Speicherereignis
NIST gliedert die Ransomware-Bereitschaft in die Bereiche Steuern, Identifizieren, Schützen, Erkennen, Reagieren und Wiederherstellen. Der Schutz vor Storage ist Teil dieses umfassenderen Betriebsmodells
Steuern
Zuständigkeiten, akzeptables Risiko, Wiederherstellungsbefugnisse und Meldepflichten zuweisen
Identifizieren
Kritische Dienste, Abhängigkeiten, Dateneigentümer und Wiederherstellungsprioritäten kennen
Schützen
Gefährdung reduzieren und geschützte, unabhängige Wiederherstellungspunkte erhalten
Erkennen
Anomale Zugriffe, Änderungsraten, Löschungen und Aktivitäten auf der Steuerungsebene erkennen
Reagieren
Zugriffe eindämmen, Beweise sichern und technische und geschäftliche Entscheidungen koordinieren
Wiederherstellen
Einen bekannten Zustand wiederherstellen, Anwendungen überprüfen und Dienste gezielt wieder verbinden
Storage kann Datenexfiltration nicht selbstständig verhindern Wiederherstellungsmaßnahmen können Verfügbarkeit und Datenintegrität wiederherstellen, Datenschutz, Benachrichtigung, Forensik und Reaktion auf Anmeldeinformationen bleiben jedoch separate Zuständigkeiten im Rahmen von Vorfällen
Design für mehr als nur Dateiverschlüsselung
Moderne Angriffe können Produktionsdaten, Backup-Systeme, administrative Identitäten und sensible Informationen gleichzeitig angreifen
Nutzbare Daten werden unlesbar
Für die Wiederherstellung wird ein Wiederherstellungspunkt vor den schädlichen Schreibvorgängen und eine ausreichend saubere Infrastruktur benötigt
Daten und Wiederherstellungspunkte gehen verloren
Aufbewahrung, Versionierung, Object Lock/WORM oder Offline-Kopien können die Möglichkeiten des Angreifers einschränken, jede Version zu entfernen
Legitime Kontrollpfade werden missbraucht
Getrennte Identitäten, das Prinzip der minimalen Berechtigungen und eine geschützte Wiederherstellungsverwaltung reduzieren die Auswirkungen eines einzelnen Kontos
Vertrauliche Daten verlassen das Unternehmen
Die Wiederherstellung von Daten macht die Offenlegung nicht rückgängig. Erkennung, rechtliche Prüfung, Benachrichtigung und die Reaktion auf Schlüssel oder Zugangsdaten können weiterhin erforderlich sein
Ein Failover sollte nicht automatisch ausgelöst werden, nur weil Produktionsdaten beschädigt sind
Ein sekundäres System kann bereits dieselben unerwünschten Schreibvorgänge enthalten, und die erneute Verbindung mit kompromittierten Identitäten oder Hosts kann es erneut beschädigen. Die Eindämmung des Vorfalls und die Entscheidung über einen Clean-Point müssen der Wiederherstellung vorausgehen
Wiederherstellungspfad mehrschichtig schützen
Einzelne Speicherfunktionen schaffen keine Cyberresilienz. Kontrollmechanismen müssen kombiniert werden, damit eine kompromittierte Identität oder ein kompromittiertes System weder die Produktionskopie noch die Wiederherstellungskopien beeinträchtigen kann
Separate administrative Identität
Berechtigungen einschränken, Aufgaben trennen und Wiederherstellungszugangsdaten schützen Produktionsadministratoren sollten nicht automatisch jede gespeicherte Kopie verwalten
Steuerung und Datenpfade segmentieren
Laterale Ausbreitung reduzieren Management-, Speicher-, Backup- und Wiederherstellungskommunikation gemäß dem Bedrohungsmodell isolieren
Versionsverlauf beibehalten
Snapshots und Objektversionen bieten auswählbare Punkte Ihr Wert hängt von Aufbewahrung, Zugriffskontrolle und Unabhängigkeit vom angegriffenen System ab
Unveränderliche oder Offline-Kopien verwenden
Löschen und Überschreiben einschränken Korrekt konfigurierte Object Lock/WORM- oder Offline-Medien können die Zerstörung einer Wiederherstellungskopie erschweren
Überwinden Sie eine Fehler- und Vertrauensgrenze
Bewahren Sie mindestens eine geeignete Kopie außerhalb der Produktionsumgebung auf Ein zweiter Standort ist nur dann sinnvoll, wenn derselbe Angriff nicht beide Standorte kompromittieren kann
Testen Sie eine saubere Wiederherstellung
Validieren Sie mehr als nur die Lesbarkeit der Dateien Identität, Anwendungen, Abhängigkeiten, Malware-Prüfungen und die Akzeptanz durch das Unternehmen gehören in die Prüfung
Wissen Sie, was jede Kontrollmaßnahme leisten kann und was nicht
Verwenden Sie mehrere Ebenen. Eine Kontrollmaßnahme, die die Hardwareverfügbarkeit schützt, bietet möglicherweise keine historische Wiederherstellung, während eine gespeicherte Kopie keine schnelle Servicekontinuität gewährleistet
| Steuerung | Hardware-Kontinuität | Früherer Datenzustand | Löschresistenz | Separate Vertrauensgrenze | Kritische Einschränkung |
|---|---|---|---|---|---|
| HA / Controller-Failover | Primärer Zweck | Nein | Nein | Normalerweise nein | Kann weiterhin verschlüsselte, gelöschte oder beschädigte Daten bereitstellen |
| Synchrones Spiegeln | Unterstützt lokale Kontinuität | Kein eigener historischer Zustand | Nein | Nein – beide Knoten bilden einen HA-System | Unerwünschte Schreibvorgänge werden synchronisiert |
| Lokaler Snapshot | Nein | Ja, gemäß Zeitplan und Aufbewahrung | Nur wenn Zugriff und Aufbewahrung dies gewährleisten | Normalerweise nein | Der Quelladministrator oder ein Speicherereignis kann Snapshots beeinträchtigen |
| Asynchrone Replikation | Nicht automatisch, es sei denn, das übergeordnete Design sieht dies vor | Möglicherweise vor dem nächsten Replikationszyklus | Nur mit beibehaltenen Versionen oder separater Richtlinie | Möglicherweise, wenn Identität und Kontrolle getrennt sind | Löschung oder Verschlüsselung können später repliziert werden |
| S3-Versionierung | Nein | Frühere Objektversionen | Versionen benötigen weiterhin Berechtigungen und Lebenszyklusschutz | Abhängig vom Bucket- und Kontodesign | Verhindert nicht automatisch das privilegierte Löschen von Versionen |
| S3 Object Lock / WORM | Nein | Geschützte, beibehaltene Objektversionen | Ja, während der gültigen Aufbewahrungsdauer bei korrekter Konfiguration | Abhängig von Identität und Bereitstellung | Konfiguration, Aufbewahrungsmodus, Verschlüsselungsschlüssel und Anwendungsverhalten sind weiterhin relevant |
| Unabhängige Sicherung | Nein | Ausgewählte Wiederherstellungspunkte | Stark im Offline-Modus, unveränderlich oder separat gesteuert | Sollte explizit festgelegt werden | Wiederherstellungszeit und Anwendungskonsistenz müssen getestet werden |
Unveränderlichkeit ist eine Konfigurationseigenschaft, kein Marketing-Label Überprüfen Sie, wer die Aufbewahrungsdauer ändern kann, welche Objektversionen geschützt sind, wie Verschlüsselungsschlüssel verwaltet werden und was passiert, wenn Lebenszyklusregeln oder Anmeldeinformationen kompromittiert werden
Wiederherstellung von Diensten durch eine kontrollierte Vertrauensentscheidung
Die Wiederherstellungsgeschwindigkeit ist wichtig, aber die Wiederverbindung kompromittierter Hosts, Identitäten oder Verwaltungspfade kann die wiederhergestellte Umgebung sofort beschädigen
- Dokumentieren, wer einen Vorfall melden und die Wiederherstellung autorisieren darf
- Protokolle und Beweismittel vor einer destruktiven Behebung gegebenenfalls sichern
- Den letzten bekannten sauberen Zustand anhand von Sicherheits- und Anwendungsnachweisen ermitteln
- Abhängigkeiten in der Reihenfolge ihrer Geschäftspriorität wiederherstellen, nicht einfach in der Reihenfolge ihrer Speicherung
- Die Zeit messen, bis Benutzer einen validierten Dienst erhalten – nicht nur bis Bytes kopiert sind
Die Wiederherstellungsmethode an den beschädigten Bereich anpassen
Eine Wiederherstellung von mehr als nötig erhöht Zeitaufwand und Risiko. Eine zu geringe Wiederherstellung kann versteckte Abhängigkeiten oder Sicherheitslücken hinterlassen
Granulare Wiederherstellung
Ausgewählte Benutzerdateien, Datenbankexporte oder Objektversionen wiederherstellen, wenn die Anwendung und die Betriebsumgebung weiterhin vertrauenswürdig sind
Berechtigungen, Eigentümer, Version und Anwendungskontext prüfenKonsistenter Anwendungsstatus
Daten und Protokolle gemäß den Konsistenz- und Sequenzierungsanforderungen der Anwendung wiederherstellen
Ein lesbares Volume ist kein Nachweis für eine gültige Datenbank oder AnwendungWiederherstellung des gesamten Systems
Eine vollständige VM zurückgeben, wenn Betriebssystem- und Anwendungsstatus zusammengehören oder die ursprüngliche Instanz nicht vertrauenswürdig ist
Patchen, scannen, Anmeldeinformationen rotieren und Abhängigkeiten vor dem erneuten Verbinden validierenNotfallwiederherstellung
Rechenleistung, Identität, Netzwerk, Anwendungen und Daten wiederherstellen, wenn die Produktionsgrenze nicht vertrauenswürdig ist oder nicht verwendet werden kann
Das Runbook muss Reihenfolge, Berechtigung und Rückkehr zum primären System definierenVerschiedene VM-Wiederherstellungsmethoden dienen unterschiedlichen Anwendungsbereichen
eEVOS ist eine Virtualisierungsplattform mit integriertem Backup & Disaster Recovery. Wählen Sie die Methode anhand von Wiederherstellungsgeschwindigkeit, Trennung und Aufbewahrung – nicht anhand einer universellen Hierarchie
Schnelle und unabhängige Wiederherstellung auf unterschiedlichen Schnittstellen platzieren
Die genaue Implementierung variiert, aber ein zuverlässiges Design lässt nicht zu, dass eine Produktionsidentität jede Ebene verändert
euroNAS-Plattformen tragen auf verschiedenen Schutzebenen bei
Diese Funktionen unterstützen ein umfassenderes Design für Cyberresilienz. Keine dieser Lösungen ersetzt Endpunktsicherheit, Identitätsschutz, Überwachung, Reaktion auf Sicherheitsvorfälle oder eine unabhängige Wiederherstellungsrichtlinie
euroNAS Premium
Eigenständiger Speicher für einen physischen Server oder Virtual Storage Appliance
- Storage-Snapshots für die Wiederherstellung zu einem bestimmten Zeitpunkt
- Geplante asynchrone Replikation auf ein anderes System oder einen anderen Standort
- Datei-, Block- und S3-Dienste für geeignete Wiederherstellungsarchitekturen
HA Cluster
Automatisches Zwei-Knoten-Speicher-Failover mittels synchronem Spiegel oder gemeinsam genutztem Speicher mit zwei Controllern
- Lokale Servicekontinuität bei Infrastrukturausfällen
- Snapshots für historische Speicherpunkte
- Separate asynchrone Replikationsoptionen
eEKAS
Grafisch verwalteter Ceph-Block-, Datei- und S3-Speicher über mehrere Knoten
- Schutz verteilter Infrastrukturen über definierte Ausfalldomänen hinweg
- Versionierung von S3 und Steuerung von Object Lock/WORM
- Grafische Verwaltung von Buckets, Richtlinien, Lebenszyklus und Aufbewahrung
eEVOS
Eine Virtualisierungsplattform, kein Speicherprodukt
- Integrierte Backup & Disaster Recovery
- Instant Backup & Recovery
- Netzwerk-, S3-kompatible Cloud- und externe Backup-Workflows
Wiederherstellungsannahmen explizit machen
Geschäftsdienste priorisieren und deren Identitäts-, Netzwerk-, Anwendungs- und Datenabhängigkeiten dokumentieren
Konten, Schlüssel, Konsolen und Automatisierungen zuordnen, die Produktionsumgebungen, Snapshots, Replikate und Backups ändern können
Aufbewahrungsdauer ab Erkennungszeitpunkt, Annahmen zur Verweildauer und Toleranz gegenüber Datenverlusten festlegen
Offline- oder unveränderliche Wiederherstellungspunkte definieren und Aufbewahrungsmodus, Versionsbereich und Schlüsselverwaltung überprüfen
Saubere Rechen-, Netzwerk-, Identitäts-, Lizenz-, Dokumentations- und Verwaltungstools bereitstellen
Testdateien, Anwendungen, Authentifizierung, Integrationen, Sicherheitsstatus und Geschäftsakzeptanz
Unabhängige Leitlinien zur Ransomware-Vorsorge
Bedrohungen und empfohlene Vorgehensweisen ändern sich. Überprüfen Sie die aktuellen offiziellen Leitlinien und validieren Sie den kundenspezifischen Notfall- und Wiederherstellungsplan
NIST IR 8374 Rev. 1
Das Community-Profil des Cybersecurity Framework 2.0 2026 ordnet das Ransomware-Risiko den Bereichen Governance, Identifizierung, Schutz, Erkennung, Reaktion und Wiederherstellung zu
NIST-Leitfaden öffnen →CISA #StopRansomware-Leitfaden
Leitfaden zu Prävention, Offline- oder unveränderlichen Backups, Reaktion auf Vorfälle und regelmäßigen Wiederherstellungstests
CISA-Leitfaden öffnen →Amazon S3 Object Lock
Offizielle Erläuterung der Aufbewahrungspflichten für WORM, rechtliche Aufbewahrungspflichten, Versionsumfang und wichtige betriebliche Aspekte
AWS-Dokumentation öffnen →Wiederherstellungspfad vor einem Vorfall entwerfen
Wir können Wiederherstellungspunkte, Vertrauensgrenzen, Speicher- oder VM-Schutz, Aufbewahrung, RPO, RTO und Wiederherstellungstests für eine Geschäftsarchitektur überprüfen