WISSEN > ENTERPRISE STORAGE > STORAGE VOR RANDSOMEWARE SCHÜTZEN
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
Wie lässt sich Storage vor Randsomeware schützen?
Das sollten Sie mitnehmen:
- Ransomware-Schutz beginnt vor dem Storage.
Endpoint-, Identity- und Netzwerksicherheit entscheiden darüber, ob ein Angreifer die Daten überhaupt erreicht.
- Storage trägt die Verantwortung für die Wiederherstellbarkeit.
Versagen die vorgelagerten Schichten, müssen Daten und Recovery Points trotzdem geschützt bleiben.
- Datenzugriff, Administration und Datenschutzfunktionen gehören getrennt.
Netzwerkpfade, Identitäten und Berechtigungen bestimmen, wie weit sich eine Kompromittierung ausbreiten kann.
- Snapshot, Immutability und unabhängige Kopie lösen unterschiedliche Probleme.
Keine dieser Funktionen ersetzt die anderen, und keine allein ergibt eine Cyber-Resilience-Architektur.
- Recovery umfasst mehr als Daten.
Auch Identitäten, Konfigurationen und Plattformkomponenten müssen wiederherstellbar sein, sonst bleiben intakte Daten unbenutzbar.
Wie lässt sich Storage vor Randsomeware schützen?
Inhaltsverzeichnis
- Ransomware erreicht den Storage über legitime Datenpfade
- Der Zugriffsweg entscheidet über die Reichweite eines Angriffs
- Was Storage zur Schadensbegrenzung beitragen kann
- Intakte Daten stellen noch keinen Service wieder her
- Aus einem begleiteten Ransomware-Fall: Die Daten überlebten, die Plattform nicht
- Ransomware-Schutz ist eine Kette, keine Einzelfunktion
- Wo die Grenzen der Storage-seitigen Cyber Resilience liegen
- Die Fragen, die eine Storage-Bewertung beantworten muss
- Fazit
- Quellen
Ransomware-Schutz beginnt nicht am Storage. Wenn Schadsoftware Daten auf einem Storage-System verschlüsselt, gelöscht oder manipuliert hat, sind meist bereits andere Sicherheitsbarrieren überwunden worden: Ein Endpoint wurde kompromittiert, Zugangsdaten wurden erbeutet, Berechtigungen missbraucht oder Angreifer konnten sich innerhalb des Netzwerks bewegen. Ein belastbares Schutzkonzept muss deshalb früher ansetzen. Netzwerksegmentierung, Identity & Access Management, Multi-Faktor-Authentifizierung, Endpoint Security und die Absicherung administrativer Zugänge gehören ebenso zur Ransomware-Abwehr wie die Schutzmechanismen des Storage-Systems.
NIST betrachtet Ransomware entsprechend nicht als isoliertes Storage-Problem. Das aktuelle NIST IR 8374 Revision 1 ordnet Maßnahmen gegen Ransomware über den gesamten Cybersecurity-Lifecycle ein und folgt dabei den sechs Funktionen des Cybersecurity Framework 2.0: Govern, Identify, Protect, Detect, Respond und Recover.
Trotzdem besitzt Storage eine besondere Bedeutung, denn hier liegen die Daten, die ein Unternehmen nach einem erfolgreichen Angriff wieder benötigt. Storage ist damit nicht die erste Verteidigungslinie gegen Ransomware, aber eine entscheidende Verteidigungslinie für Datenintegrität und Wiederherstellbarkeit.
Ransomware erreicht den Storage über legitime Datenpfade
Ein Storage-System sieht zunächst Zugriffe auf Daten. Ob diese Zugriffe legitim sind, lässt sich auf dieser Ebene nicht immer eindeutig bestimmen. Ein kompromittierter Applikationsserver kann beispielsweise weiterhin ordnungsgemäß authentifiziert sein und Schreibrechte auf ein Volume besitzen. Verschlüsselt die Ransomware über diesen Server Dateien oder Datenblöcke, erreichen den Storage reguläre Schreiboperationen über die vorgesehenen Datenpfade. Ähnliches gilt für File Storage: Wird ein Benutzerkonto kompromittiert, kann ein Angreifer grundsätzlich alle Dateien verändern, für die dieses Konto Schreibberechtigungen besitzt.
Eine Schutzarchitektur muss deshalb mehrere Ebenen umfassen, die vom Endpoint über Identität, Netzwerk und Applikationsschicht bis zum Storage und schließlich zur Recovery-Ebene reichen. Der Storage kann keine dieser vorgelagerten Sicherheitsfunktionen ersetzen. CISA empfiehlt zur Ransomware-Prävention unter anderem phishing-resistente MFA, abgesicherte Remote-Zugänge und logische oder physische Netzwerksegmentierung, wobei Segmentierung insbesondere die laterale Bewegung eines Angreifers innerhalb einer Infrastruktur erschweren beziehungsweise begrenzen soll.
Der Zugriffsweg entscheidet über die Reichweite eines Angriffs
Storage-Systeme sind über unterschiedliche Netzwerkpfade erreichbar. Dabei sollte nicht nur betrachtet werden, über welchen Weg Anwendungen ihre Daten lesen und schreiben. Mindestens ebenso relevant ist die Frage, über welchen Weg ein Angreifer den Storage administrieren oder dessen Schutzmechanismen beeinflussen kann.
NIST SP 800-209 führt für diese Betrachtung den Begriff der Data Planes ein und beschreibt am Beispiel eines Block Device drei logisch unterschiedliche Bereiche. Die Aufzählung ist ausdrücklich nicht abschließend gemeint, hat sich aber als Denkmodell für Storage-Architekturen bewährt. Wir verwenden sie im Folgenden auch für File- und Object-Zugriffe, weil die zugrunde liegende Trennungslogik dort identisch greift.
Data Consumption Plane
Über diese Ebene greifen Hosts und Anwendungen auf die eigentlichen Daten zu. In der Praxis umfasst sie in einer heterogenen Storage-Umgebung Zugriffe über Fibre Channel, iSCSI und NVMe-oF ebenso wie über SMB, NFS oder S3. Wird ein berechtigter Host kompromittiert, können dessen vorhandene Zugriffsrechte gegen die Daten verwendet werden.
Data Management Plane
Hier wird die Storage-Infrastruktur administriert: über Management-GUIs und APIs, über administrative Benutzerkonten, über Konfigurations- und Provisionierungszugriffe sowie über die Zuordnung von Storage-Ressourcen zu Hosts. Eine Kompromittierung dieser Ebene besitzt potenziell eine andere Tragweite als die Kompromittierung eines einzelnen Datenpfades. Ein Storage-Administrator kann, abhängig von Produkt, Konfiguration und Berechtigungsmodell, weitreichende Änderungen an der gesamten Storage-Infrastruktur durchführen.
Data Protection Plane
Diese Ebene umfasst die Zugriffe und Operationen für Replikation, Snapshots, Backup und Archivierung. Gerade für Cyber Resilience ist ihre Trennung von besonderer Bedeutung. NIST SP 800-209 weist ausdrücklich darauf hin, dass eine unzureichende Trennung zwischen Data Consumption Plane und Data Protection Plane dazu führen kann, dass ein Angreifer nach der Übernahme eines Hosts nicht nur Produktionsdaten, sondern auch Kopien und Backups beschädigt. Als mögliche Trennmechanismen nennt NIST unter anderem VLANs, getrennte IP-Subnetze, ACLs sowie unterschiedliche Benutzer und Rollen.
Damit wird Netzwerkarchitektur unmittelbar Bestandteil des Storage-Schutzes. Ein separates Storage-Netz allein ist jedoch noch keine Cyber-Resilience-Architektur. Entscheidend ist, welche Systeme, Identitäten und Kommunikationspfade zwischen den einzelnen Schutzbereichen bestehen.
Was Storage zur Schadensbegrenzung beitragen kann
Wenn die vorgelagerten Schutzmaßnahmen versagen, muss die Storage- und Data-Protection-Architektur die Auswirkungen eines erfolgreichen Angriffs begrenzen und eine Wiederherstellung ermöglichen. Dafür lassen sich mehrere Schutzebenen unterscheiden, die unterschiedliche Aufgaben erfüllen und einander nicht ersetzen.
Schutzebene
Ziel
Beispiele
Access Protection
Zugriff auf Storage und Management begrenzen
RBAC, MFA, separate Admin-Konten, Netzwerksegmentierung
Detection
ungewöhnliche Datenveränderungen erkennen
I/O- oder File-Anomalien, Änderung von Datenmustern, Malware-Scanning
Containment / Response
Auswirkungen eines Angriffs begrenzen
Alarmierung, zusätzliche Recovery Points, Isolation oder produktspezifische automatische Reaktionen
Recovery Points
frühere Datenzustände erhalten
Snapshots, Versionierung, Point-in-Time Copies
Immutability
Recovery Points gegen Manipulation schützen
Immutable Snapshots, Retention Lock, WORM, Object Lock
Isolation
gemeinsame Angriffs- und Administrationspfade reduzieren
getrennte Credentials, Management-Netze, separate Systeme
Data Recovery
Daten auf einen vertrauenswürdigen Zustand zurücksetzen
Snapshot Restore, Clone, Backup Restore
Independent Recovery Copy
Wiederherstellung trotz weitreichender Kompromittierung ermöglichen
getrennt administrierter Backup- oder Object Storage, Offline Copy, Air-Gap-Konzepte
Die Angriffsfläche der Management Plane reduzieren
Der erste Schritt besteht darin, die Angriffsfläche des Storage selbst zu verkleinern. Besonders relevant ist dabei die Management Plane. Administrative Storage-Zugänge sollten nicht unnötig aus allgemeinen Benutzer- oder Servernetzen erreichbar sein, Berechtigungen nach dem Least-Privilege-Prinzip vergeben und administrative Rollen auf die tatsächlich benötigten Funktionen beschränkt werden. Wo die eingesetzten Systeme dies unterstützen, gehören starke Authentisierung und MFA insbesondere für administrative Zugänge in das Sicherheitskonzept.
Die entscheidende Architekturfrage lautet, wer mit welcher Identität über welchen Netzwerkpfad welche Storage-Funktion ausführen kann. Damit wird aus einer reinen Produktkonfiguration ein Security- und Architekturthema.
Veränderungen erkennen, ohne Detection zu überschätzen
Moderne Storage-Systeme können zusätzliche Informationen zur Erkennung von Angriffen liefern. Je nach Implementierung lassen sich ungewöhnliche Änderungsraten, Dateiverhalten, I/O-Muster oder Veränderungen von Datencharakteristika analysieren. File-basierte Systeme können darüber hinaus näher an Dateien, Dateitypen und Benutzeraktivitäten arbeiten, andere Architekturen integrieren externe Malware-Scanner.
Dabei sind zwei Aufgaben zu unterscheiden. Malware Detection versucht bekannte oder als schädlich klassifizierte Inhalte zu erkennen, während Behavioral beziehungsweise Anomaly Detection ungewöhnliches Verhalten oder Veränderungen im Datenbestand identifiziert. Storage-seitige Detection ergänzt damit Endpoint-, Netzwerk- und Security-Monitoring, ersetzt diese Systeme aber nicht. Wie unterschiedliche Enterprise-Storage-Hersteller solche Mechanismen technisch implementieren, behandeln wir separat im Artikel „Marktüberblick: Cyber Resilience im Enterprise Storage".
Recovery Points erzeugen
Snapshots und andere Point-in-Time-Verfahren halten definierte Zustände eines Datenbestands fest. Das ist für Ransomware-Recovery wichtig, weil nach einem Angriff nicht nur die aktuelle Version der Daten benötigt wird. Es muss ein Zustand existieren, der vor der Manipulation liegt.
Ein Snapshot ist jedoch zunächst nur ein Recovery Point. Ob daraus ein belastbarer Schutz gegen Ransomware entsteht, hängt davon ab, wer den Snapshot löschen und wer seine Retention verändern kann, welche Administratoren Zugriff besitzen, ob Snapshot und Produktionsdaten derselben administrativen Failure Domain angehören und ob überhaupt bekannt ist, welcher Recovery Point noch vertrauenswürdig ist. Snapshot und immutable Snapshot sind deshalb nicht dasselbe.
Recovery Points unveränderbar machen
Immutability soll verhindern, dass geschützte Daten oder Recovery Points innerhalb einer definierten Retention verändert oder gelöscht werden können. Je nach Storage-Klasse und Implementierung kommen dafür immutable Snapshots, WORM-Mechanismen, Retention Lock, S3 Object Lock oder geschützte Backup-Repositories zum Einsatz.
Entscheidend ist nicht allein, dass ein Hersteller eine Funktion als immutable bezeichnet. Für die Architektur muss geklärt werden, gegen welche Identitäten und administrativen Operationen die Unveränderbarkeit tatsächlich durchgesetzt wird. Kann ein kompromittierter Administrator die Retention reduzieren, die Schutzfunktion deaktivieren oder das zugrunde liegende System vollständig administrieren, verändert dies das Threat Model erheblich. Die technischen Mechanismen im Enterprise Storage behandeln wir ausführlicher unter „Cyber Resilience im Enterprise Storage".
Schutzbereiche voneinander isolieren
Eine zentrale Erkenntnis moderner Cyber-Resilience-Architekturen lautet, dass mehr Kopien nicht automatisch mehr Schutz bedeuten. Drei replizierte Kopien können gegen Hardwareausfälle schützen. Wenn ein Angreifer mit derselben administrativen Identität alle drei Kopien löschen kann, entsteht daraus jedoch keine Isolation gegenüber diesem Angriffsszenario. Für Ransomware muss deshalb neben der Anzahl der Kopien die Unabhängigkeit der Schutzbereiche betrachtet werden.
Die relevanten Trennungsebenen ergeben sich aus einer Reihe von Fragen: Sind Produktions-, Management- und Protection-Pfade voneinander getrennt? Werden für Produktion und Recovery dieselben administrativen Accounts beziehungsweise dieselbe Identity-Infrastruktur verwendet? Kann ein Administrator sowohl Produktionsdaten als auch deren Recovery Points löschen? Befinden sich Produktion und Recovery auf derselben Storage-Plattform? Und existiert eine zusätzliche Recovery Copy außerhalb der unmittelbaren Failure Domain des Primärsystems?
NIST SP 800-209 beschreibt genau diese Trennung als relevante Sicherheitsentscheidung und weist zugleich auf den Trade-off hin: Eine stärkere Separation erhöht die Sicherheitsisolation, verursacht aber zusätzlichen Netzwerk- und Administrationsaufwand. Der derzeit in Kommentierung befindliche Entwurf der Revision 1 führt diesen Gedanken weiter und unterscheidet ausdrücklich zwischen Kopien für nicht-böswillige Wiederherstellungsszenarien und Kopien für die Wiederherstellung nach einem Cyberangriff. Für letztere fordert der Entwurf getrennte Storage-Umgebungen sowie ein eigenes Managementsystem, das sich nicht mit den regulären Credentials der Produktionsumgebung erreichen lässt.
Eine unabhängige Recovery Copy vorsehen
Für besonders weitreichende Angriffsszenarien reicht es nicht aus, nur die Produktionsdaten zu schützen. CISA empfiehlt, kritische Daten in offline gehaltenen und verschlüsselten Backups vorzuhalten und deren Verfügbarkeit und Integrität regelmäßig im Rahmen von Disaster-Recovery-Szenarien zu testen. Als Begründung nennt CISA ausdrücklich, dass Ransomware auch erreichbare Backups suchen und löschen oder verschlüsseln kann.
Dabei sind drei Eigenschaften zu unterscheiden, die kombiniert werden können, technisch aber nicht identisch sind. Immutability beschreibt die Veränderbarkeit der Daten innerhalb definierter Regeln. Isolation beschreibt die Trennung von Zugriffs- und Administrationspfaden. Air Gap beschreibt eine weitergehende Trennung, bei der eine Recovery Copy zeitweise oder dauerhaft nicht über den normalen produktiven Zugriffspfad erreichbar ist.
Object Storage kann als zusätzliche Recovery-Ebene eingesetzt werden. Welche Rolle Object Lock, administrative Trennung und unabhängige Failure Domains dabei spielen, behandeln wir im Artikel „Cyber Resilience mit Object Storage".
Intakte Daten stellen noch keinen Service wieder her
Ein Punkt wird bei der Betrachtung von Ransomware häufig unterschätzt: Nutzdaten allein ergeben noch keinen produktiven IT-Service. Für den Zugriff auf Daten sind weitere Komponenten erforderlich, von der Storage-Konfiguration und den Management-Systemen über Server, virtuelle Maschinen und Datenbanken bis zu Active Directory oder anderen Identity Services, DNS, Zertifikaten und Schlüsseln, Netzwerkkomponenten, Backup-Katalogen, Backup-Servern und den Applikationen selbst.
Cyber Resilience muss deshalb mindestens zwei unterschiedliche Aufgaben betrachten. Data Recovery beantwortet die Frage, wie Daten auf einen vertrauenswürdigen Zustand zurückgesetzt werden. Platform Recovery beantwortet die Frage, wie die Systeme und Abhängigkeiten wiederhergestellt werden, die erforderlich sind, um diese Daten produktiv bereitzustellen. Auch NIST behandelt Ransomware entsprechend über Schutz, Erkennung, Reaktion und Wiederherstellung hinweg und nicht ausschließlich als Frage der Datenkopie.
Aus einem begleiteten Ransomware-Fall: Die Daten überlebten, die Plattform nicht
Warum diese Trennung relevant ist, zeigte sich in einem Ransomware-Fall, den wir begleitet haben. Der Angriff hatte große Teile der IT-Infrastruktur einschließlich der Identity-Umgebung beeinträchtigt. Ein separat administrierter Object Storage blieb dagegen intakt, weil seine administrativen Konten nicht in die kompromittierte zentrale Identity-Infrastruktur eingebunden waren. Damit waren wichtige Daten weiterhin vorhanden.
Gleichzeitig zeigte der Vorfall eine zweite Seite der Recovery-Architektur: Komponenten der darüberliegenden Plattform und deren Backups waren ebenfalls vom Angriff betroffen. Ein separat vorhandenes Datenbank-Backup wurde deshalb für die Wiederherstellung relevant.
Aus einem einzelnen Projekt lässt sich nicht ableiten, dass eine bestimmte Technologie Ransomware-Angriffe verhindert. Der Fall zeigt jedoch einen Architekturpunkt, den wir seither konsequent trennen: Die Überlebensfähigkeit der Daten und die Wiederherstellbarkeit des gesamten Services sind zwei unterschiedliche Anforderungen. Wir berücksichtigen die Trennung der Recovery-Abhängigkeiten seither stärker und integrieren beispielsweise auch Plattform-Datenbank-Backups in einen entsprechend geschützten S3-basierten Speicherbereich.
Ransomware-Schutz ist eine Kette, keine Einzelfunktion
Für die Architekturentscheidung lässt sich Ransomware-Schutz als Kette betrachten, die von Prevention über Detection und Containment zu Data Recovery, Platform Recovery und schließlich zur unabhängigen Recovery Copy führt. Jedes Glied hat eine eigene Aufgabe.
Prevention soll verhindern, dass Angreifer Storage und Daten überhaupt erreichen. Dazu gehören Maßnahmen außerhalb und innerhalb des Storage: Endpoint Security, Identity Security, MFA, Netzwerksegmentierung, Least Privilege sowie die Absicherung der Storage Management Plane.
Detection greift, wenn Prevention versagt, und soll ungewöhnliches Verhalten möglichst früh sichtbar machen. Storage-seitige Detection bildet dabei eine zusätzliche Beobachtungsebene neben Endpoint-, Netzwerk- und Security-Systemen.
Containment soll nach einer Erkennung verhindern, dass sich der Schaden unbegrenzt fortsetzt. Welche automatischen oder manuellen Reaktionen möglich sind, hängt stark von der jeweiligen Storage-Implementierung ab.
Data Recovery setzt voraus, dass Recovery Points existieren, die zeitlich vor dem Angriff liegen und nicht ebenfalls zerstört wurden. Platform Recovery setzt voraus, dass auch die Infrastruktur wiederherstellbar ist, über die Daten bereitgestellt werden. Und für Szenarien, in denen Produktions- und Administrationsumgebungen weitreichend kompromittiert wurden, sollte eine Recovery-Ebene existieren, die nicht denselben Trust- und Failure Domains unterliegt.
Wo die Grenzen der Storage-seitigen Cyber Resilience liegen
Ein Storage-System kann, abhängig von seiner Implementierung, Zugriffe kontrollieren, Veränderungen beobachten, Recovery Points erzeugen und unveränderbar schützen, Daten replizieren und die Wiederherstellung unterstützen. Es kann aber keine vollständige Ransomware-Schutzarchitektur für das gesamte Unternehmen ersetzen.
Ein kompromittierter Endpoint bleibt ein Endpoint-Problem, gestohlene Credentials bleiben ein Identity-Problem, laterale Bewegung bleibt unter anderem ein Netzwerk- und Access-Control-Problem, und eine kompromittierte Backup-Infrastruktur bleibt ein Data-Protection-Problem. Cyber Resilience entsteht erst durch das Zusammenspiel dieser Ebenen.
Die Fragen, die eine Storage-Bewertung beantworten muss
Bei der Bewertung eines Storage-Systems sollte deshalb nicht nur gefragt werden, ob das System über Ransomware Protection verfügt. Technisch aussagekräftiger sind konkrete Fragen:
- Wie werden Data, Management und Protection Plane voneinander getrennt?
- Welche Identitäten besitzen Zugriff auf Produktionsdaten und Recovery Points?
- Welche Veränderungen kann das Storage-System erkennen und auf welcher Ebene?
- Was geschieht nach einer Erkennung?
- Welche Recovery Points existieren und wie lange werden sie aufbewahrt?
- Wer kann diese Recovery Points verändern oder löschen?
- Wie wird verhindert, dass kompromittierte Produktions-Administratoren auch die Recovery-Ebene kontrollieren?
- Wie wird ein vertrauenswürdiger Recovery Point identifiziert?
- Wie werden nicht nur Daten, sondern auch Storage- und Plattformkomponenten wiederhergestellt?
- Existiert für kritische Daten eine ausreichend unabhängige Recovery Copy?
- Wurde die Wiederherstellung tatsächlich getestet?
Erst die Antworten auf diese Fragen zeigen, wie belastbar die Architektur gegenüber einem konkreten Angriffsszenario ist.
Fazit
Storage spielt eine zentrale Rolle bei der Abwehr der Auswirkungen von Ransomware, aber Ransomware-Schutz beginnt nicht am Storage. Endpoint Security, Identity & Access Management, Netzwerksegmentierung und der Schutz administrativer Zugänge sollen verhindern, dass ein Angreifer überhaupt bis zu kritischen Daten und Storage-Systemen gelangt. Die Empfehlungen von NIST und CISA betrachten Ransomware deshalb als durchgängiges Cybersecurity-Risiko und nicht als isoliertes Storage-Problem.
Der Storage übernimmt eine andere, ebenso entscheidende Aufgabe: Er muss dazu beitragen, dass ein erfolgreicher Angriff nicht automatisch zum endgültigen Verlust der Daten und der Wiederherstellbarkeit führt. Dafür reicht eine einzelne Funktion nicht aus. Detection ohne geschützte Recovery Points erkennt möglicherweise den Angriff, ermöglicht aber noch keine Wiederherstellung. Snapshots ohne ausreichende administrative Absicherung bleiben Teil derselben Failure Domain. Immutability schützt Daten vor bestimmten Veränderungen, isoliert aber nicht automatisch Management- und Netzwerkpfade. Eine unabhängige Recovery Copy schafft einen zusätzlichen Schutzbereich, löst aber allein weder Detection noch Platform Recovery.
Eine belastbare Storage-Strategie verbindet deshalb Zugriffsschutz, Detection, Containment, geschützte Recovery Points, Isolation, Data Recovery, Platform Recovery und eine unabhängige Recovery Copy. Die entscheidende Frage lautet damit nicht mehr, welche Ransomware-Funktion ein Storage-System besitzt, sondern welche Schutzschichten noch wirksam bleiben, wenn eine andere Schutzschicht bereits kompromittiert wurde. Genau darin liegt der Unterschied zwischen einzelnen Security Features und einer Cyber-Resilience-Architektur.
Quellen
National Institute of Standards and Technology (NIST): Ransomware Risk Management: A Cybersecurity Framework 2.0 Community Profile, NIST IR 8374 Revision 1, Juni 2026, DOI 10.6028/NIST.IR.8374r1.
National Institute of Standards and Technology (NIST): Security Guidelines for Storage Infrastructure, NIST Special Publication 800-209, Oktober 2020, DOI 10.6028/NIST.SP.800-209. Insbesondere Abschnitt 4.2 zur Unterscheidung von Data Consumption Plane, Data Management Plane und Data Protection Plane sowie zu den Trennungsmechanismen zwischen diesen Ebenen.
National Institute of Standards and Technology (NIST): Security Guidelines for Storage Infrastructure, NIST Special Publication 800-209 Revision 1, Initial Public Draft, Juli 2026, DOI 10.6028/NIST.SP.800-209r1.ipd. Entwurfsstatus; die öffentliche Kommentierungsphase endet am 8. September 2026. Herangezogen für die Unterscheidung zwischen Kopien für nicht-böswillige Wiederherstellung und Kopien für die Wiederherstellung nach Cyberangriffen sowie für die zugehörigen Isolationsanforderungen.
Cybersecurity and Infrastructure Security Agency (CISA), FBI, NSA, MS-ISAC: #StopRansomware Guide, Version 3.0, Oktober 2023 (Erstveröffentlichung September 2020). Empfehlungen unter anderem zu MFA, Netzwerksegmentierung, abgesicherten Remote-Zugängen sowie offline gehaltenen und regelmäßig getesteten Backups.
National Institute of Standards and Technology (NIST): Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events, NIST SP 1800-26, Dezember 2020; ergänzend NIST SP 1800-25, Dezember 2020, und NIST SP 1800-11, September 2020, zu Schutz und Wiederherstellung
Welche Entscheidung steht bei Ihnen an?
Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.
Spezialist für moderne Dateninfrastruktur
