InfiniteFlow - stock.adobe.com
Ransomware-Recovery für KI-Stacks in einem Data Lakehouse
Angreifer zielen auf die Metadaten ab, die eine Data-Intelligence-Plattform benötigt. Ermitteln Sie, wo KI-Risiken liegen und was für ein Recovery des Betriebs erforderlich ist.
Wenn Ransomware den modernen Daten-Stack eines Unternehmens befällt, zielen Angreifer zunehmend auf die zentralen Komponenten ab – also auf Steuerungsebenen, Kataloge und Pipelines –, um Analyse- und KI-Infrastrukturen lahmzulegen.
Viele Datenteams führen Analysen und KI-Prozesse auf SaaS-gehosteten Data Lakehouses aus. Das ist zwar komfortabel, kann aber Schwachstellen bei der Ausfallsicherheit offenlegen. Viele Unternehmen gehen davon aus, dass der Anbieter den Datenschutz übernimmt. Im SaaS-Modell der geteilten Verantwortung liegen jedoch nur die Verfügbarkeit des Dienstes und die Sicherheit der Infrastruktur beim Provider, während Data Protection, Backup und Wiederherstellung in der Verantwortung des Kunden bleiben. Werden diese Rollen missverstanden, kann ein Ransomware-Angriff erhebliche Ausfälle von Analyse- und KI-Systemen verursachen.
Um Vorfälle und Audits zu bewältigen, setzt ein Ansatz zur Ransomware-Wiederherstellung für Data Lakehouses auf eine Clean-Room-Architektur, metadatenbasierte Backups sowie Versionierung und Rollback-Funktionen auf Pipeline-Ebene.
Architektur für die Clean-Room-Wiederherstellung
Die Wiederherstellung einer KI- oder Analyseumgebung unterscheidet sich grundlegend von der Wiederherstellung eines klassischen Dateiservers. Pipelines, Modellversionen, Feature Stores und Kataloge, die diese Systeme betreiben, sind eng miteinander verknüpft.
Die erneute Integration einer kompromittierten Pipeline oder eines beschädigten Modells in die Produktionsumgebung stellt keine vollständige Wiederherstellung dar, da weiterhin das Risiko einer erneuten Infektion besteht.
Der sicherste Ansatz in einem Ransomware-Recovery-Plan für ein Data Lakehouse besteht darin, Wiederherstellungen zu validieren, ohne eine Verbindung zur kompromittierten Umgebung herzustellen.
Genau dafür dient eine Clean-Room-Wiederherstellungsumgebung, auch isolierte Recovery-Umgebung genannt. Dabei handelt es sich um einen speziell eingerichteten Bereich mit eigener Identitäts- und Netzwerk-Infrastruktur – etwa Active Directory, DNS und DHCP –, in dem Teams Systeme wiederherstellen und ihre Funktionsfähigkeit prüfen können, bevor sie erneut mit der Produktionsumgebung verbunden werden.
Für den Aufbau eines Clean Rooms haben sich zwei Ansätze etabliert, die sich hinsichtlich Kosten, Geschwindigkeit und Personalaufwand unterscheiden:
- Air-Gapped. In diesem Szenario ist die Umgebung physisch von externen Netzwerken getrennt. Das bietet die stärkste Isolierung, erfordert jedoch dedizierte Hardware und zusätzliches Personal. Die Recovery Time Objectives (RTOs) können mehrere Tage betragen.
- Logisch isoliert. Bei diesem Ansatz sorgen Netzwerksegmentierung und strenge Zugriffskontrollen für die Trennung. Das ist schneller und kostengünstiger, die Wirksamkeit hängt jedoch von der konsequenten Umsetzung dieser Kontrollen ab.
Eine isolierte Umgebung ist nur so vertrauenswürdig wie die darin gespeicherten Daten. Backups sollten daher unveränderlich (immutable) sein – etwa mithilfe von WORM-Objektspeicher-Kontrollen –, damit Angreifer Wiederherstellungspunkte weder manipulieren noch löschen können.
Wiederherstellungspläne müssen zudem regelmäßig getestet werden. Teams sollten den gesamten Stack wiederherstellen, prüfen, ob Pipelines mit den wiederhergestellten Daten korrekt ausgeführt werden, bestätigen, dass Modelle die erwarteten Ergebnisse liefern, und den zeitlichen Ablauf aller Schritte dokumentieren, bevor die Verbindung zur Produktionsumgebung wiederhergestellt wird.
Wiederherstellung des Data Lakehouse
Die meisten Maßnahmen zur Abwehr von Ransomware konzentrieren sich auf die Speicherebene, um Datendateien zu schützen. Dabei wird jedoch häufig die Metadatenebene übersehen, die KI- und Analysesysteme zur Interpretation dieser Daten benötigen.
Ein Data Lakehouse speichert Daten typischerweise in offenen Formaten wie Apache Parquet auf kostengünstigem Objektspeicher, etwa Amazon S3 oder Azure Data Lake Storage. Ohne die Metadaten des Tabellenformats, die Dateien, Schemata und Versionen verwalten, können KI- und Analyse-Engines diese Daten jedoch nicht zuverlässig abfragen.
Die drei populären offenen Tabellenformate Delta Lake, Apache Iceberg und Apache Hudi basieren auf Transaktionsprotokollen und Snapshots als zentrale Referenz für den Tabellenzustand. Verschlüsseln oder beschädigen Angreifer diese Metadaten-Artefakte, verliert das KI- und Analyse-Ökosystem den Überblick über die Datenbestände.
Das reine Kopieren der Datendateien reicht deshalb nicht aus. Herkömmliche Backup-Tools für Objektspeicher behandeln Daten als isolierte Dateien und sichern häufig nicht die Metadaten, die für die Wiederherstellung einer Tabelle erforderlich sind. Ohne geeignete Metadaten-Backups müssen Unternehmen die Tabellenstruktur manuell rekonstruieren.
Ein Runbook für die Zeit nach einem Failover sollte daher folgende Prozesse beschreiben:
- die Isolation der kompromittierten Steuerungsebene,
- das Umschalten auf regionenübergreifend replizierte Kataloge und Transaktionsprotokolle,
- die Wiederherstellung der Kataloge und Transaktionsprotokolle aus unveränderlichen und versionierten Backups,
- das Abgleichen der Metadaten mithilfe von Time-Travel-Funktionen mit den Datendateien und Prüfen der Konsistenz, bevor Workloads wieder aufgenommen werden.
End-to-End-Ausfallsicherheit für KI-Pipelines sicherstellen
Für Verantwortliche im Bereich KI-Governance ist die Ransomware-Resilienz ebenso eine Frage von Datenherkunft und Integrität sowie von Backup und Recovery.
Können Unternehmen die Herkunft der Daten nachweisen, Manipulationen an Komponenten erkennen und das gesamte System auf einen nachweislich sauberen Zustand zurücksetzen? Dafür ist eine Versionierung auf jeder Ebene der Datenpipeline erforderlich: von Trainingsdaten, Feature-Store-Snapshots, Modellgewichten, Pipeline-Definitionen, Modellregistrierungseinträgen mit Herkunftsinformationen und Vektorindex-Snapshots.
Die Nachvollziehbarkeit der Herkunft erfordert eine durchgängige Datenherkunft (Data Lineage) von der Quelle über das Training bis hin zur Modellausgabe. Manipulationen lassen sich durch die Validierung kryptografischer Hashes in jeder Phase der Pipeline erkennen. Gemeinsam liefern diese Kontrollen Governance-Teams die erforderlichen Nachweise, um die Qualität eines wiederhergestellten Modells zu bestätigen.
Wie schnell sich Analyse- und KI-Systeme von einem Ransomware-Vorfall erholen können, hängt vom gewählten Bereitstellungsmodell ab. Für Unternehmen gibt es zwei vorherrschende Ansätze:
Drei Frameworks bieten Sicherheits- und KI-Teams einen mehrschichtigen Ansatz, um Datenherkunft, Manipulationserkennung und Risiken in der Lieferkette systematisch statt nur reaktiv zu adressieren:
- NIST AI RMF (AI Risk Management Framework). Das Framework nutzt auf Unternehmensebene die vier Kernfunktionen Governance, Zuordnung, Messung und Management, um Risiken in Bezug auf Drittanbieter-Software, Daten und Lieferketten zu bewerten.
- Gartner AI TRiSM (Trust, Risk and Security Management). Ein Framework zur Identifizierung der Technologien und Prozesse, die erforderlich sind, um KI-Systeme in den Bereichen Vertrauen, Risiko und Sicherheit zu steuern.
- MITRE ATLAS (Adversarial Threat Landscape for AI Systems). Teams nutzen diese Wissensdatenbank, um Taktiken und Techniken zu analysieren, die auf KI-Systeme abzielen, darunter Data Poisoning und Hintertüren (Backdoors).
Für Daten- und Sicherheitsverantwortliche ist die Ransomware-Resilienz von KI- und Analyseumgebungen letztlich eine Architekturentscheidung, die lange vor einem Vorfall getroffen werden muss. NIST, MITRE und Gartner haben diese Frameworks entwickelt, weil KI-Pipelines Risiken mit sich bringen, die von klassischen Disaster-Recovery-Konzepten nicht abgedeckt werden. Ohne einen strukturierten Ansatz zur Ransomware-Wiederherstellung im Data Lakehouse bleiben Herkunftsnachweise und Manipulationserkennung reine Best-Effort-Maßnahmen – und damit oft die ersten Kontrollen, die unter dem Druck eines Vorfalls vernachlässigt werden.
Dieser Artikel ist im Original in englischer Sprache auf SearchDisasterRecovery.com erschienen.
