Sicherheit von Cloud Data Lakes

Die Sicherheit eines Cloud-Data-Lake umfasst Verschlüsselung, Zugriffskontrolle, Schlüsselverwaltung und Überwachungsmechanismen, die ein zentrales Cloud-Datenrepository vor unberechtigtem Zugriff und Verstößen gegen gesetzliche Bestimmungen schützen. Sie ist von entscheidender Bedeutung, da Data Lakes strukturierte, semistrukturierte und unstrukturierte Daten aus dem gesamten Unternehmen in einem einzigen Ziel zusammenführen und dadurch ein attraktives Ziel für Sicherheitslücken darstellen. Empfohlen wird, zunächst alle ruhenden Daten mit einem vom Kunden verwalteten Verschlüsselungsschlüssel zu verschlüsseln, das Prinzip der minimalen Berechtigungen pro Data-Lake-Zone durchzusetzen, die Protokollierung aller Schlüsseloperationen zu aktivieren und frühzeitig zu entscheiden, ob die native Cloud-Schlüsselverwaltung, BYOK (Bring Your Own Key) oder HYOK (Your Your Own Key) Ihren Anforderungen an die Datensouveränität entspricht.

Kurzantwort: Was benötigt ein sicherer Cloud-Data-Lake?

Ein sicherer Cloud-Data-Lake erfordert vier Kontrollmechanismen: Verschlüsselung ruhender Daten für jedes Objekt in jeder Zone mittels AES-256, durchgesetzt mit kundenseitig verwalteten Schlüsseln, die Sie kontrollieren und auditieren können; Verschlüsselung der Datenübertragung via TLS, durchgesetzt durch Richtlinien für Speicher-Buckets; Identitäts- und Zugriffsmanagement, das jeder Rolle nur die Berechtigungen gewährt, die sie für die jeweiligen Zonen benötigt; und ein Audit-Log, das jeden Lese-, Schreib- und Schlüsselzugriff einer authentifizierten Identität erfasst. Compliance-Rahmenwerke wie HIPAA, PCI DSS, DSGVO und FedRAMP fordern alle vier. Keiner dieser Mechanismen allein ist ausreichend.

Wichtige Erkenntnisse

• Data Lakes sind attraktive Ziele für Sicherheitsverletzungen: Die Zusammenführung aller Organisationsdaten an einem zentralen Ort vereinfacht zwar die Analyse, birgt aber ein potenzielles Sicherheitsrisiko. Sicherheit muss von Anfang an in die Architektur integriert werden und darf nicht erst nachträglich hinzugefügt werden, wenn die Daten bereits fließen.
• Zonenbasierte Zugangskontrolle bildet die architektonische Grundlage: Durch die Aufteilung des Data Lakes in temporale, Rohdaten-, vertrauenswürdige und verfeinerte Zonen können Sie für jede Zone unterschiedliche Verschlüsselungsschlüssel und Zugriffsrichtlinien anwenden und so die seitliche Ausbreitung einschränken, falls eine Zone kompromittiert wird.
• Kundenseitig verwaltete Verschlüsselungsschlüssel sind das Minimum für regulierte Daten: Native Cloud-Verschlüsselung (anbieterverwaltete Schlüssel) schützt vor Diebstahl auf physischen Speichermedien, bietet aber keine Protokollierung der Vorgänge und keine unabhängige Schlüsselkontrolle. Kundenverwaltete Schlüssel (CMKs) bieten beides.
• BYOK vs. HYOK ist eine Souveränitätsentscheidung: BYOK bewahrt die Herkunft der Schlüsseldaten bei Ihnen, ermöglicht dem Cloud-Anbieter jedoch die operative Nutzung. HYOK (clientseitige Verschlüsselung vor dem Upload) bedeutet, dass der Cloud-Anbieter unter keinen Umständen auf Klartext zugreifen kann.
• Die Audit-Protokollierung muss sowohl Speicherereignisse als auch Schlüsselereignisse umfassen: Speicherzugriffsprotokolle erfassen, wer Daten gelesen oder geschrieben hat. Schlüsselverwaltungsprotokolle erfassen, wer sie verschlüsselt oder entschlüsselt hat. Beide sind für einen vollständigen Nachweis der Compliance erforderlich.

Was ist ein Cloud Data Lake?

Ein Data Lake ist ein zentrales Repository, das Rohdaten in ihrem Originalformat speichert, bis sie für Analysen oder die Weiterverarbeitung benötigt werden. Im Gegensatz zu einem Data Warehouse, das strukturierte und transformierte Daten vor der Aufnahme benötigt, akzeptiert ein Data Lake beliebige Formate: strukturierte relationale Daten, semistrukturierte JSON- oder Parquet-Dateien, unstrukturierte Text- oder Protokolldateien, Binärdaten und Streaming-Telemetrie. Als Speicherschicht dient typischerweise Cloud-Objektspeicher: Amazon S3 für AWS Data Lakes, Azure Data Lake Storage Gen2 (ADLS Gen2) für Azure und Google Cloud Storage (GCS) für GCP.

Cloud-Data-Lakes basieren auf dieser Objektspeicherinfrastruktur und sind mit Compute-Engines (Amazon EMR, Azure Databricks, Google Dataproc), Abfrage-Engines (Amazon Athena, Azure Synapse Analytics, BigQuery) sowie Datenkatalog- und Governance-Tools (AWS Glue Data Catalog, Microsoft Purview, Google Dataplex) ausgestattet. Sicherheitskontrollen müssen auf jeder Ebene dieses Stacks angewendet werden, nicht nur auf der Ebene der Speicher-Buckets.

Warum Cloud-Data-Lakes attraktive Ziele für Sicherheitslücken darstellen

Die gleiche Eigenschaft, die Data Lakes für Analysen so wertvoll macht (die Konsolidierung aller Organisationsdaten an einem Ort), macht sie auch zu attraktiven Zielen für Angreifer. Ein einziger falsch konfigurierter S3-Bucket oder ein übermäßig privilegiertes Dienstkonto kann Daten aus mehreren Geschäftsbereichen gleichzeitig offenlegen. Zu den gängigen Angriffsvektoren gegen Cloud-Data-Lakes gehören falsch konfigurierte Bucket-Richtlinien, die öffentlichen Lesezugriff gewähren, übermäßig privilegierte IAM-Rollen, die von Analyse-Workloads verwendet werden und auch Zugriff auf unformatierte personenbezogene Daten haben, kompromittierte Anmeldeinformationen, die zum großflächigen Datenabfluss aus Objektspeichern verwendet werden, und Lieferkettenangriffe auf Datenpipeline-Tools, die Schreibzugriff auf Daten in vertrauenswürdigen Zonen haben.

Das Bedrohungsmodell für einen Data Lake unterscheidet sich von dem für eine Transaktionsdatenbank. Data Lakes enthalten oft historische Daten über Jahre hinweg, verschiedene Datentypen und Daten von übernommenen Unternehmen mit unterschiedlichen ursprünglichen Sicherheitsstandards. Sicherheitsmaßnahmen müssen dieser Vielfalt Rechnung tragen und auch bei zunehmendem Datenvolumen und zunehmender Datenvielfalt im Data Lake konsistent angewendet werden.

Data-Lake-Zonierung: Die Grundlage der Sicherheitsarchitektur

Die Zonierung unterteilt den Data Lake in separate Speicherbereiche basierend auf Datenverarbeitungsphase, Sensibilität und Zugriffsanforderungen. Die vier Standardzonen sind:

• Zeitzone: Dieser Bereich enthält temporäre Erfassungsdaten, die nicht langfristig gespeichert werden müssen. Die Daten in diesem Bereich sind häufig ungevalidiert und können Rohdatenströme oder unvollständige Datensätze enthalten. Der Zugriff sollte ausschließlich auf Datenerfassungspipelines beschränkt sein.
• Rohdatenbereich: Speichert Daten im Originalformat und in voller Qualität, wie sie von den Quellsystemen empfangen wurden. Rohdaten enthalten häufig personenbezogene Daten (PII), geschützte Gesundheitsdaten (PHI) und andere sensible Felder, die noch nicht maskiert oder tokenisiert wurden. Der Zugriff auf Rohdaten sollte auf Dateningenieure und Datenverarbeitungspipelines beschränkt sein, nicht auf Analysten oder Endbenutzer.
• Vertrauenswürdige Zone: Dieser Bereich enthält validierte, bereinigte, transformierte und in vielen Fällen anonymisierte oder maskierte Daten. Die Daten in diesem Bereich sind für die Nutzung durch Analyse-Workloads, Data Scientists und Business-Intelligence-Tools bereit. Der Zugriff ist umfassender als im Rohdatenbereich, aber dennoch rollenbeschränkt.
• Verfeinerte Zone: Enthält aggregierte, zusammengefasste oder speziell erstellte Ergebnisse der Analyseverarbeitung. Die Daten in diesem Bereich wurden häufig weiter reduziert oder anonymisiert. Hier verbinden sich in der Regel Endnutzer und Reporting-Tools.

Aus Sicherheitsgründen sollte jede Zone über einen eigenen Verschlüsselungsschlüssel (bzw. eine eigene Schlüsselhierarchie), eigene Zugriffsrichtlinien und einen eigenen Audit-Log-Stream verfügen. Ein Sicherheitsvorfall, der eine Zone kompromittiert, sollte nicht automatisch Zugriff auf andere Zonen gewähren. Verwenden Sie separate IAM-Rollen, separate KMS-Schlüssel und separate Speicher-Bucket-Richtlinien pro Zone.

Verschlüsselung für Cloud-Data-Lakes: Im Ruhezustand und während der Übertragung

Alle gängigen Compliance-Frameworks für Cloud-Data-Lakes fordern Verschlüsselung sowohl ruhender Daten (zum Schutz gespeicherter Objekte) als auch während der Übertragung (zum Schutz der Daten beim Transfer zwischen Diensten). Diese Verschlüsselungsmethoden erfordern separate Konfigurationen und werden nicht automatisch zusammen bereitgestellt.

Die Verschlüsselung ruhender Daten in einem Cloud-Data-Lake bedeutet, dass jedes im zugrunde liegenden Cloud-Objektspeicher abgelegte Objekt vor dem Speichern auf der Festplatte verschlüsselt wird. Der Verschlüsselungsalgorithmus ist AES-256 (Advanced Encryption Standard mit einem 256-Bit-Schlüssel), typischerweise im GCM-Modus (Galois Counter Mode), der eine authentifizierte Verschlüsselung gewährleistet. Die entscheidende Frage ist nicht, ob eine Verschlüsselung stattfindet (alle drei großen Cloud-Service-Provider verschlüsseln Objektspeicher standardmäßig), sondern wer die Kontrolle über die Verschlüsselungsschlüssel hat.

Verschlüsselung während der Übertragung bedeutet, dass alle Daten, die zwischen Clients, Recheneinheiten und Objektspeichern ausgetauscht werden, über TLS (Transport Layer Security) übertragen werden. Cloud-Anbieter unterstützen HTTPS für den Zugriff auf Objektspeicher. Sie müssen dies jedoch durch Richtlinien für Speicher-Buckets erzwingen, die alle Anfragen ablehnen, die nicht HTTPS verwenden. Ohne eine explizite Ablehnungsrichtlinie greifen einige SDKs und ältere Anwendungen möglicherweise auf HTTP zurück und senden Daten im Klartext.

Neben der Verschlüsselung ruhender und übertragener Daten sollten Data-Lake-Workloads mit spaltenorientierten Speicherformaten (Parquet, ORC) auch die spaltenbasierte Verschlüsselung in Betracht ziehen. Diese verschlüsselt spezifische sensible Spalten (z. B. Sozialversicherungsnummer, Kreditkartennummer, Geburtsdatum) innerhalb eines Analysedateiformats, während nicht sensible Spalten für Analyseabfragen ohne Entschlüsselung zugänglich bleiben. Apache Parquet unterstützt die spaltenbasierte Verschlüsselung nativ, was insbesondere für Daten aus vertrauenswürdigen Bereichen nützlich ist, die von Analysten abgefragt werden müssen, die keine personenbezogenen Daten einsehen dürfen.

Native Key Control vs. BYOK vs. HYOK: Die Souveränitätsentscheidung

Die wichtigste Sicherheitsentscheidung für einen Cloud-Data-Lake betrifft die Kontrolle der Verschlüsselungsschlüssel. Es gibt drei Modelle, die jeweils unterschiedliche Auswirkungen auf die Compliance, den Betriebsaufwand und die Kosten haben.

Option 1: Native Cloud Provider Keys (vom Anbieter verwaltet)

Der Cloud-Anbieter generiert, speichert, rotiert und verwaltet alle Verschlüsselungsschlüssel. Bei AWS ist dies der AWS/S3-Dienstschlüssel, bei Azure die von Microsoft verwalteten Schlüssel und bei GCP die von Google verwalteten Verschlüsselungsschlüssel (GMEK). Die Daten sind verschlüsselt, aber der Anbieter kontrolliert die Schlüssel. Sie können den Schlüssel nicht eigenständig deaktivieren, um den Zugriff zu entziehen, einzelne Entschlüsselungsvorgänge nicht anhand bestimmter Identitäten prüfen und einer Aufsichtsbehörde nicht nachweisen, dass der Schlüsselzugriff vom Datenzugriff getrennt ist.

Die anbietereigene Schlüsselverwaltung eignet sich für nicht regulierte Daten, bei denen Einfachheit im Vordergrund steht. Sie ist jedoch unzureichend für Workloads, die HIPAA-, PCI-DSS-, FedRAMP- oder DSGVO-Anforderungen erfüllen und die Kontrolle des Kunden über die Verschlüsselungsschlüssel erfordern.

Option 2: BYOK (Bring Your Own Key – Bringen Sie Ihren eigenen Schlüssel mit)

BYOK bedeutet, dass Sie Ihr Verschlüsselungsschlüsselmaterial außerhalb des Cloud-Anbieters generieren und es in dessen Schlüsselverwaltungsdienst importieren: AWS KMS, Azure Key Vault oder GCP Cloud KMS. Der KMS des Cloud-Anbieters verwendet Ihr Schlüsselmaterial, um die Datenverschlüsselungsschlüssel zu generieren, die Ihre Data-Lake-Objekte schützen. Sie behalten das ursprüngliche Schlüsselmaterial in Ihrem eigenen HSM und können es aus dem KMS des Cloud-Anbieters löschen, um diesem die Berechtigung zur Entschlüsselung Ihrer Daten sofort zu entziehen.

BYOK mit einem vom Kunden verwalteten Schlüssel bietet Ihnen eine vollständige Protokollierung aller Ver- und Entschlüsselungsvorgänge: Jeder Vorgang wird im Überwachungsdienst des Cloud-Anbieters (CloudTrail für AWS, Azure Monitor für Azure, Cloud Audit Logs für GCP) mit der Schlüssel-ID, der anfragenden Identität und einem Zeitstempel protokolliert. Sie können den Schlüssel deaktivieren, um weitere Entschlüsselungen sofort zu verhindern, ohne Ihre Daten zu löschen. Sie können das Schlüsselmaterial nach Ihrem eigenen Zeitplan rotieren.

Der Kompromiss: Während der aktiven Nutzung hat das KMS des Cloud-Anbieters operativen Zugriff auf das Schlüsselmaterial, um Ver- und Entschlüsselungsvorgänge durchzuführen. BYOK erfüllt zwar die Anforderungen des Kunden an die Schlüsselherkunft, jedoch nicht die Anforderungen, bei denen der Cloud-Anbieter zu keiner Zeit Zugriff auf den Schlüssel haben darf.

Option 3: HYOK (Hold Your Own Key)

HYOK bedeutet, dass Ihre Anwendung Daten verschlüsselt, bevor sie diese in den Cloud-Speicher hochlädt. Was der Cloud-Anbieter speichert, ist bereits verschlüsselter Text; der Cloud-Anbieter hat unter keinen Umständen Zugriff auf den Klartext oder den Verschlüsselungsschlüssel, auch nicht bei rechtlicher Anordnung. Dies ist das einzige Modell, das den Cloud-Anbieter vollständig aus der Vertrauenskette für Ihre Daten ausschließt.

HYOK setzt voraus, dass Ihre Anwendung oder Datenpipeline alle kryptografischen Operationen durchführt, bevor die Daten in die Cloud gelangen, dass Ihr externes Schlüsselverwaltungssystem hochverfügbar ist (da jeder Schreib- und Lesevorgang im Data Lake eine Schlüsseloperation gegen Ihr externes KMS erfordert) und dass Ihr Team den gesamten Schlüssellebenszyklus einschließlich Schlüsselrotation, Datensicherung und Notfallwiederherstellung für die externe Schlüsselverwaltungsinfrastruktur verwaltet.

HYOK eignet sich für Verschlusssachen, Daten, die strengen nationalen Anforderungen an die Datensouveränität unterliegen, bei denen der Zugriff ausländischer Regierungen auf die Infrastruktur des Cloud-Anbieters ein glaubwürdiges Bedrohungsmodell darstellt, oder Daten, bei denen regulatorische Anforderungen ausdrücklich vorschreiben, dass der Cloud-Anbieter keinen Zugriff auf die Verschlüsselungsschlüssel haben darf.

Abmessungen	Native (vom Anbieter verwaltete Schlüssel)	BYOK (Customer-Managed Key in Cloud KMS)	HYOK (Clientseitige Verschlüsselung)
Schlüssel generiert von	Cloud-Anbieter	Kunde (in Cloud-KMS importiert)	Kunde (tritt nie in die Cloud ein)
Anbieterzugriff auf den Schlüssel während der Nutzung	Ja	Ja (betriebsbereit)	Nein
Prüfprotokoll pro Vorgang	Nein	Ja (in den Cloud-KMS-Audit-Protokollen)	Nur wenn Ihr externer KMS-Server dies protokolliert.
Unabhängige Tastendeaktivierung/-widerruf	Nein	Ja (CMK sofort deaktivieren)	Ja (Widerruf bei Ihrem externen KMS)
Automatische Schlüsseldrehung	Ja (Anbieterplan)	Ja (jährlich für CMK) oder manuell für importiertes Material	Vollständig vom Kunden verwaltet
Operative Komplexität	Niedrig	Medium	Hoch
Kosten	In den Lagerkosten enthalten	KMS-Schlüsselgebühr + Gebühr pro API-Aufruf	Kosten für externe KMS-Infrastruktur
Am besten geeignet,	Nicht regulierte, interne Analysedaten	Daten, die den Bestimmungen von HIPAA, PCI DSS, FedRAMP und der DSGVO unterliegen	Klassifizierte, durch staatliche Vorgaben geschützte Zero-Trust-Daten

IAM-Modell: Prinzip der minimalen Berechtigungen für den Zugriff auf Cloud-Data-Lake-Daten

Das Prinzip der minimalen Berechtigungen erfordert, dass jede Identität (Benutzer, Dienstkonto oder Anwendung) nur auf die spezifischen Data-Lake-Zonen, Speicherorte und Operationen Zugriff hat, die sie zur Erfüllung ihrer definierten Funktion benötigt. In einem Cloud-Data-Lake bedeutet dies, Zugriffskontrollen auf drei Ebenen zu entwerfen:

Identitätsrichtlinien (pro Rolle): Definieren Sie die Aktionen, die jede Rolle ausführen darf. Eine Rolle in der Datenaufnahmepipeline benötigt lediglich Schreibzugriff auf die temporäre Zone. Eine Rolle im Bereich Datenverarbeitung benötigt Lesezugriff auf die Rohdatenzone und Schreibzugriff auf die vertrauenswürdige Zone. Eine Analyserolle benötigt lediglich Lesezugriff auf die vertrauenswürdige und die verfeinerte Zone. Keine Analyserolle sollte Lesezugriff auf die Rohdatenzone haben, in der unmaskierte personenbezogene Daten (PII) gespeichert sind. Trennen Sie die Berechtigungen für die Schlüsselverwendung von den Berechtigungen für die Schlüsselverwaltung: Eine Rolle, die Daten mithilfe eines KMS-Schlüssels verschlüsseln und entschlüsseln kann, sollte diesen Schlüssel nicht rotieren, deaktivieren oder löschen dürfen.

Ressourcenrichtlinien (pro Zone): Wenden Sie Bucket- oder Containerrichtlinien an, die den Zugriff für Prinzipale, die nicht in der Liste der genehmigten Rollen für diese Zone enthalten sind, explizit verweigern – unabhängig von Identitätsrichtlinien. Ressourcenbasierte Verweigerungsrichtlinien bieten eine zusätzliche Schutzebene: Selbst wenn eine Identitätsrichtlinie falsch konfiguriert ist und einen umfassenderen Zugriff gewährt, verhindert die Verweigerung auf Ressourcenebene die Operation. Verweigern Sie den Zugriff auf die Rohdatenzone für alle Prinzipale außer der Rolle „Datenverarbeitung“ und den Dienstkonten der Datenpipeline. Verweigern Sie den Schreibzugriff auf die vertrauenswürdige Zone für alle Prinzipale außer der Transformationspipeline.

Richtlinien für Verschlüsselungsschlüssel (pro CMK): Jeder vom Kunden verwaltete KMS-Schlüssel einer Zone sollte über eine Schlüsselrichtlinie verfügen, die Schlüsseladministratoren (die den Schlüssel verwalten können) und Schlüsselbenutzer (die den Schlüssel zum Ver- und Entschlüsseln verwenden können) separat definiert. Keine Identität sollte gleichzeitig Schlüsseladministrator und Schlüsselbenutzer für denselben Schlüssel sein. Bei kontoübergreifenden Data-Lake-Architekturen muss eine ressourcenbasierte Schlüsselrichtlinie dem kontoübergreifenden Prinzipal zusätzlich zu dessen eigener Identitätsrichtlinie explizit die Berechtigung zur Verwendung des Schlüssels erteilen.

Schlüsselrotation in einem Cloud-Data-Lake

Die Schlüsselrotation in einem Cloud-Data-Lake-Kontext bedeutet, dass der vom Kunden verwaltete Schlüssel (Customer-Managed Key, CMK) rotiert wird, der Ihre Datenverschlüsselungsschlüssel auf Zonenebene schützt. Es geht nicht darum, jedes Objekt im Data Lake neu zu verschlüsseln. Wenn Sie die automatische jährliche Rotation eines CMK in AWS KMS, Azure Key Vault oder GCP Cloud KMS aktivieren, generiert der Dienst gemäß dem konfigurierten Zeitplan neues kryptografisches Material. Neu in den Data Lake geschriebene Objekte verwenden dieses neue Schlüsselmaterial. Vorhandene Objekte bleiben mit der Schlüsselversion verschlüsselt, die zum Zeitpunkt ihres Uploads aktiv war. Der KMS speichert alle vorherigen Schlüsselversionen, um diese älteren Objekte zu entschlüsseln. Es müssen keine Objekte erneut hochgeladen werden.

Bei BYOK-Schlüsseln mit importiertem Material ist die automatische Rotation über das KMS des Cloud-Anbieters nicht verfügbar. Sie müssen die Rotation extern verwalten: Generieren Sie neues Schlüsselmaterial in Ihrem HSM, importieren Sie es als neue Schlüsselversion in den CMK, legen Sie es als primäre Schlüsselversion fest und warten Sie, bis die laufenden Operationen abgeschlossen sind, bevor Sie die vorherige Version außer Betrieb nehmen. Dieser Prozess erfordert eine sorgfältige Abstimmung aller Datenpipelines, die den Schlüssel verwenden.

Neben der Rotation der CMKs sollten Data-Lake-Umgebungen auch die Anmeldeinformationen für Dienstkonten und IAM-Zugriffsschlüssel nach einem festgelegten Zeitplan rotieren und alle aktiven Anmeldeinformationen mit der Liste der noch gültigen Anmeldeinformationen abgleichen. Langlebige Anmeldeinformationen, die von Datenaufnahmepipelines verwendet werden, sind eine häufige Ursache für unberechtigten Zugriff.

Audit-Protokollierung für die Sicherheit von Cloud-Data-Lakes

Für einen vollständigen Prüfpfad eines Cloud-Data-Lakes ist eine Protokollierung auf zwei Ebenen erforderlich: Speicherzugriffsereignisse und Schlüsselverwaltungsereignisse. Keine der beiden Ebenen allein reicht für die Einhaltung der Vorschriften aus.

Speicherzugriffsprotokolle erfassen, wer Objekte in den einzelnen Data-Lake-Zonen gelesen, geschrieben, aufgelistet oder gelöscht hat. Auf AWS decken die S3-Serverzugriffsprotokollierung und die S3-CloudTrail-Datenereignisse Operationen auf Objektebene ab. Auf Azure erfassen die ADLS-Gen2-Diagnoseprotokolle Lese- und Schreibvorgänge in Speichercontainern. Auf GCP erfassen die Cloud-Audit-Protokolle den Objektzugriff in Cloud-Storage-Buckets. Speicherprotokolle müssen explizit aktiviert werden; sie sind in der Regel nicht standardmäßig aktiviert. Leiten Sie Speicherprotokolle an ein separates, schreibgeschütztes Audit-Konto weiter, um Manipulationen zu verhindern.

Die Protokolle der Schlüsselverwaltung erfassen jeden Ver- und Entschlüsselungsvorgang, der mit einem bestimmten CMK verknüpft ist, einschließlich der anfragenden Identität, des Zeitstempels und der verschlüsselten oder entschlüsselten Ressource. Auf AWS wird jeder KMS-API-Aufruf in CloudTrail protokolliert. Auf Azure erfassen die Key Vault-Audit-Protokolle Schlüsseloperationen. Auf GCP erfassen die Cloud KMS-Audit-Protokolle kryptografische Operationen. Die Protokolle der Schlüsselverwaltung liefern den identitätsbezogenen Nachweis, dass auf Daten zugegriffen wurde, und nicht nur, dass ein Objekt von einem unbekannten Prozess berührt wurde.

Warnung bei folgenden Mustern: Entschlüsselungsvorgänge durch einen Principal, der nicht in der Liste der genehmigten Rollen für den CMK dieser Zone enthalten ist; Entschlüsselungsanfragen in großem Umfang (mögliche Datenexfiltration); Versuche, einen Data Lake CMK zu deaktivieren oder zu löschen; und Speicherzugriffe von einer IP-Adresse oder einem geografischen Standort außerhalb Ihres erwarteten Betriebsbereichs.

Bewährte Verfahren für die Sicherheit von Cloud-Data-Lakes

1. Daten klassifizieren, bevor sie in den See gelangen: Jede Datenquelle muss vor der Aufnahme mit einer Sensibilitätsklassifizierung versehen werden. Die Klassifizierung bestimmt, in welche Zone die Daten gelangen, welcher Verschlüsselungsschlüssel sie schützt und welche Zugriffsrichtlinien gelten. Daten, die ohne Klassifizierung in die Rohdatenzone gelangen, erhalten standardmäßig die höchste Sensibilitätsstufe.
2. Zonenspezifische Verschlüsselungsschlüssel anwenden: Verwenden Sie pro Zone einen separaten, vom Kunden verwalteten KMS-Schlüssel. Sollte der vertrauenswürdige Zonenschlüssel kompromittiert werden, bleiben die Rohdaten der Zone geschützt. Muss der Rohzonenschlüssel aufgrund eines vermuteten Kompromittierungsfalls ausgetauscht werden, sind die vertrauenswürdigen und bereinigten Zonendaten davon nicht betroffen.
3. Verschlüsselung über Ressourcenrichtlinien erzwingen, nicht nur über Standardeinstellungen: Legen Sie die Standardverschlüsselung für den Bucket oder Container auf die von Ihnen gewählte Methode fest und fügen Sie zusätzlich eine Ablehnungsrichtlinie für alle PutObject-Anfragen hinzu, die den erforderlichen Verschlüsselungsheader nicht enthalten. Die Standardverschlüsselung ist eine Voreinstellung und wird nicht erzwungen; ein falsch konfigurierter Client kann sie ohne Ablehnungsrichtlinie überschreiben.
4. Trennen Sie die Rollen im Data Lake von den wichtigsten Managementrollen: Keine Rolle im Bereich Data Engineering oder Analytics sollte über Berechtigungen zur KMS-Schlüsselverwaltung verfügen. Die Schlüsselverwaltung (Erstellen, Rotieren, Deaktivieren, Löschen) sollte einen separaten, protokollierten Workflow über eine dedizierte Rolle im Bereich Sicherheitsbetrieb erfordern.
5. Aktivieren Sie die S3-Objektsperre oder eine gleichwertige Funktion für Überwachungsprotokolle: Konfigurieren Sie Ihren Ziel-Bucket oder -Container für Audit-Logs mit WORM-Schutz (Write Once, Read Many), um zu verhindern, dass Protokolle von einem kompromittierten Konto geändert oder gelöscht werden. Unveränderliche Audit-Logs sind erforderliche Nachweise für SOC-2-, FedRAMP- und PCI-DSS-Audits.
6. Automatisches Scannen der Rohdatenzone nach sensiblen Daten: Nutzen Sie Cloud-native Tools zur Datenermittlung (Amazon Macie, Microsoft Purview, GCP Cloud DLP), um Rohdaten der vertrauenswürdigen Zone beim Dateneingang auf personenbezogene Daten (PII), Gesundheitsdaten (PHI) und andere sensible Muster zu überprüfen. Kennzeichnen Sie Objekte mit sensiblen Feldern für zusätzliche Zugriffsbeschränkungen, bevor sie in die vertrauenswürdige Zone verarbeitet werden.
7. Verwenden Sie spaltenbasierte Verschlüsselung für analytische Workloads: Bei Parquet- oder ORC-Daten in der vertrauenswürdigen Zone sollte eine Verschlüsselung auf Spaltenebene auf sensible Felder (Sozialversicherungsnummer, Geburtsdatum, Kreditkartennummer) angewendet werden, damit Analyseabfragen auf nicht sensiblen Spalten keine Entschlüsselungsschlüssel benötigen, die auch die sensiblen Spalten entschlüsseln.
8. Führen Sie vierteljährliche Zugriffsüberprüfungen durch: Überprüfen Sie vierteljährlich die Liste der IAM-Prinzipale mit Zugriff auf die einzelnen Data-Lake-Zonen. Entfernen Sie Zugriffsrechte für nicht mehr benötigte Rollen. Stellen Sie sicher, dass die mit stillgelegten Datenpipelines verknüpften Dienstkonten widerrufen wurden.

Sicherheitsfunktionen des Data Lakes von Cloud-Anbietern

Jeder große Cloud-Anbieter bietet ein eigenes Set an Sicherheitsdiensten, die auf die Sicherheitsanforderungen von Data Lakes abgestimmt sind. Wenn Sie wissen, was die einzelnen Anbieter nativ anbieten, können Sie Lücken identifizieren, die Tools von Drittanbietern oder individuelle Konfigurationen erfordern.

AWS-Data-Lake-Sicherheit: Amazon S3 dient als Speichergrundlage. AWS Key Management Service (KMS) ermöglicht die kundenseitige Schlüsselverwaltung mit CloudTrail-Integration. Amazon Macie automatisiert die Erkennung und Klassifizierung personenbezogener Daten (PII) in S3. AWS Lake Formation bietet eine einheitliche Zugriffskontrollschicht für S3, mit der Sie Zugriffsrichtlinien auf Spalten- und Zeilenebene für Analyseabfragen definieren können, ohne dass diese Richtlinien in jeder Abfrage-Engine repliziert werden müssen. AWS Glue Data Catalog stellt Metadaten zur Datenklassifizierung bereit. AWS CloudTrail liefert sowohl KMS-Schlüsseloperationsprotokolle als auch S3-Datenereignisprotokolle.

Azure Data Lake-Sicherheit: Azure Data Lake Storage Gen2 (ADLS Gen2) bildet die Speichergrundlage. Azure Key Vault ermöglicht die vom Kunden verwaltete Schlüsselverwaltung mit Azure Monitor-Integration. Microsoft Purview bietet Datengovernance, -klassifizierung und -kennzeichnung für die Vertraulichkeit in ADLS Gen2. Azure Active Directory (Entra ID) übernimmt die Identitätsverwaltung. Azure Policy stellt Richtlinien zur Durchsetzung von Verschlüsselungs- und Zugriffskonfigurationsstandards bereit. Azure Monitor liefert Speicherdiagnoseprotokolle und Key Vault-Überwachungsprotokolle.

Sicherheit des GCP-Data-Lake: Google Cloud Storage (GCS) bildet die Speichergrundlage. Google Cloud KMS (einschließlich Cloud HSM für FIPS 140-2 Level 3-konforme Schlüsselspeicherung) ermöglicht die kundenseitige Schlüsselverwaltung mit Integration von Cloud Audit Logs. Google Cloud DLP (Data Loss Prevention) automatisiert die Erkennung und Klassifizierung sensibler Daten in GCS. Dataplex gewährleistet Daten-Governance und Richtlinienmanagement für alle GCS-Buckets. Cloud Audit Logs liefert KMS-Betriebsprotokolle und GCS-Datenzugriffsprotokolle.

Sicherheitsarchitektur für Multi-Cloud-Data-Lake

Organisationen, die Data Lakes über mehrere Cloud-Anbieter hinweg betreiben oder Cloud-Data-Lakes mit lokalen Data Warehouses kombinieren, stehen vor einer spezifischen Sicherheitsherausforderung: Die nativen Sicherheitstools jedes Cloud-Anbieters sind anbieterspezifisch. AWS Lake Formation-Richtlinien gelten nicht für ADLS Gen2. GCP Cloud DLP-Klassifizierungen werden nicht automatisch auf S3-Objekte übertragen. Die Verwaltung separater Schlüsselinventare, Zugriffsrichtlinien, Klassifizierungsschemata und Audit-Log-Streams für jeden Anbieter vervielfacht die operative Komplexität und erhöht das Risiko eines inkonsistenten Sicherheitsniveaus im gesamten Netzwerk.

Drei Muster adressieren die Sicherheit von Multi-Cloud-Data-Lakes:

• Einheitlicher Datenkatalog und Klassifizierungsebene: Implementieren Sie eine Cloud-unabhängige Datenkatalog- und Klassifizierungsplattform, die Metadaten von allen drei Cloud-Anbietern erfasst, einheitliche Vertraulichkeitskennzeichnungen anwendet und konsistente Zugriffsrichtlinien durchsetzt, unabhängig davon, welcher Cloud-Anbieter die Daten speichert. Dieser Governance-orientierte Ansatz wird in stark regulierten Unternehmen mit Multi-Cloud-Infrastruktur immer häufiger eingesetzt.
• Zentralisiertes BYOK mit Cloud-basierter Schlüsselbereitstellung: Generieren Sie sämtliche Verschlüsselungsschlüssel aus einem einzigen externen HSM oder Schlüsselverwaltungssystem. Importieren Sie abgeleitete Schlüssel in AWS KMS (für S3-Data-Lakes), Azure Key Vault (für ADLS Gen2) und GCP Cloud KMS (für GCS). Alle Verschlüsselungsprozesse lassen sich auf eine einzige autoritative Schlüsselquelle zurückführen, wodurch die Schlüsselverwaltung und die Erfassung von Compliance-Nachweisen anbieterübergreifend konsistent sind.
• HYOK mit gemeinsamer Verschlüsselungsschicht: Verschlüsseln Sie Daten auf Pipeline-Ebene, bevor sie an Cloud-Speicher übermittelt werden. Verwenden Sie unabhängig von der Ziel-Cloud dieselbe clientseitige Verschlüsselungsbibliothek und denselben Hauptschlüssel. Dies gewährleistet höchste Datenkonsistenz und -souveränität, erfordert jedoch, dass alle Datenpipelines kryptografische Operationen vor jedem Cloud-API-Aufruf durchführen.

Compliance-Frameworks für die Sicherheit von Cloud-Data-Lakes

Cloud-Data-Lakes, die regulierte Daten speichern, müssen die spezifischen technischen Kontrollen des jeweiligen Compliance-Rahmenwerks erfüllen. Die am häufigsten in Cloud-Data-Lake-Implementierungen verwendeten Rahmenwerke sind:

HIPAA (Health Insurance Portability and Accountability Act): Erfordert die Verschlüsselung von geschützten Gesundheitsdaten (Protected Health Information, PHI) im Ruhezustand und während der Übertragung, Zugriffskontrollen, die den PHI-Zugriff auf autorisierte Personen beschränken, die Protokollierung aller PHI-Zugriffe sowie eine Vereinbarung zur Auftragsverarbeitung (Business Associate Agreement, BAA) mit jedem Cloud-Anbieter, der PHI verarbeitet. Die Rohdatenzone eines Data Lakes im Gesundheitswesen enthält typischerweise PHI und erfordert strengste Zugriffskontrollen sowie einen dedizierten CMK (Clinical Master Key).

PCI DSS (Payment Card Industry Data Security Standard): Erfordert die Verschlüsselung von Karteninhaberdaten im Ruhezustand und während der Übertragung, Schlüsselverwaltungsmechanismen einschließlich Schlüsselrotation und Vier-Augen-Prinzip für Schlüsseloperationen, Beschränkungen des Netzwerkzugriffs und vierteljährliche Zugriffsüberprüfungen. Karteninhaberdaten in einem Zahlungsdatenspeicher sollten in einer separaten Rohdatenzone mit einem dedizierten CMK (Cardholder Key) gespeichert werden, auf den nur autorisierte Zahlungsabwicklungssysteme Zugriff haben.

DSGVO (Datenschutz-Grundverordnung): Sie schreibt technische und organisatorische Maßnahmen zum Schutz personenbezogener Daten von EU-Bürgern vor, darunter Verschlüsselung, Pseudonymisierung und die Gewährleistung der Rechte betroffener Personen (Auskunftsrecht, Recht auf Löschung). Eine DSGVO-konforme Data-Lake-Architektur muss alle Datensätze einer bestimmten Person in allen Zonen auffinden und löschen können. Dies erfordert die Kennzeichnung der Daten bei der Erfassung sowie ein abfragefähiges Datenherkunftssystem.

FedRAMP (Federal Risk and Authorization Management Program): Erfordert FIPS 140-2- oder FIPS 140-3-validierte kryptografische Module für die Verschlüsselung, Sicherheitskontrollen gemäß NIST SP 800-53 Rev. 5 und kontinuierliche Überwachung. Für Workloads mit hohem FedRAMP-Anteil ist ein FIPS 140-2 Level 3 HSM-gestützter Schlüsselspeicher erforderlich. Alle drei großen Cloud-Anbieter bieten FedRAMP-autorisierte Dienste für Data-Lake-Workloads an; der Kunde muss diese Dienste jedoch gemäß den erforderlichen Kontrollstandards konfigurieren.

Wie Verschlüsselungsberatung helfen kann

Encryption Consulting ist ein Beratungsunternehmen für angewandte Kryptografie und Cloud-Sicherheit mit Zertifizierungen nach ISO/IEC 27001:2022 und SOC 2. Wir unterstützen Organisationen bei der Konzeption, Implementierung und Prüfung von Sicherheitsarchitekturen für Cloud-Data-Lakes – vom ersten Verschlüsselungskonzept bis hin zur laufenden Erfassung von Nachweisen zur Einhaltung der Vorschriften.

• Hinweis zum Datenschutz in der Cloud: Wir analysieren Ihre aktuelle Data-Lake-Verschlüsselungskonfiguration, identifizieren Schwachstellen (unverschlüsselte Zonen, vom Anbieter verwaltete Schlüssel, für die CMKs erforderlich sind, fehlende Audit-Protokollierung, übermäßig privilegierte Servicekonten) und entwerfen die Ziel-Sicherheitsarchitektur inklusive zonenbasierter CMK-Hierarchie, IAM-Least-Privilege-Modell, Bucket-Richtliniendurchsetzung und Rotationsplan. Weitere Informationen finden Sie in unserem Cloud-Beratungsdienste.
• HSM als Dienstleistung: Für BYOK- und HYOK-Data-Lake-Architekturen, bei denen das Verschlüsselungsschlüsselmaterial in einem FIPS-validierten HSM außerhalb des Cloud-Anbieters generiert werden muss, bietet Encryption Consulting die Lösung an. HSM als Service Bietet eine dedizierte FIPS 140-2 Level 3 HSM-Infrastruktur mit Integration in AWS KMS, Azure Key Vault und GCP Cloud KMS Schlüsselimport-Workflows.
• CBOM Secure: Multi-Cloud-Data-Lake-Umgebungen führen häufig zu inkonsistenten Verschlüsselungskonfigurationen in Hunderten von Buckets und Containern. Encryption Consulting bietet hierfür Lösungen an. CBOM Secure Erkennt und inventarisiert alle Speicherverschlüsselungseinstellungen, KMS-Schlüsselkonfigurationen und Zugriffsrichtlinien über AWS-, Azure- und GCP-Konten hinweg und generiert eine kryptografische Stückliste (CBOM) im CycloneDX-Format, die Sicherheitslücken aufzeigt und die Erstellung von Prüfnachweispaketen unterstützt.
• PKI als Dienstleistung: Für Data-Lake-Umgebungen, die Mutual TLS (mTLS) zur Dienst-zu-Dienst-Authentifizierung zwischen Datenpipeline-Komponenten verwenden, bietet Encryption Consulting die Lösung an. PKI als Service bietet eine verwaltete private Zertifizierungsstelle mit ACME-automatisierter Zertifikatslebenszyklusverwaltung, wodurch sichergestellt wird, dass die Zertifikate der Datenpipeline immer aktuell und ordnungsgemäß gültig sind.
• Compliance-Beratung (HIPAA, PCI DSS, FedRAMP, DSGVO): Wir ordnen die Sicherheitskontrollen Ihres Data Lakes den spezifischen technischen Anforderungen Ihres Compliance-Rahmenwerks zu, identifizieren Kontrolllücken, erstellen den Abhilfeplan und stellen die Nachweisdokumentation für Ihr Audit zusammen. Compliance-Beratungsdienste decken HIPAA, PCI DSS, FedRAMP, GDPR, NIST CSF 2.0 und NIST SP 800-53 Rev. 5 ab.
• PQC-Bereitschaft: Das NIST finalisierte im August 2024 die Post-Quanten-Kryptographiestandards FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA). NIST IR 8547 deutet darauf hin, dass RSA und ECC für neue Anwendungsfälle um das Jahr 2030 als veraltet gelten werden. Obwohl AES-256-GCM, das für die Verschlüsselung von Data-Lake-Objekten verwendet wird, als quantenresistent gilt, muss die Schlüsselverwaltungsinfrastruktur (KMS-Schlüsselkapselung, TLS-Verbindungen zwischen Pipeline-Komponenten) angepasst werden. (Encryption Consulting) PQC-Bereitschaft Der Dienst bildet die kryptografische Sicherheitslage Ihres Data Lakes auf den Zeitplan der Post-Quanten-Migration ab.

Um Ihre Sicherheitsanforderungen an Ihren Cloud-Data-Lake zu besprechen, wenden Sie sich an Encryption Consulting.

Fazit

Cloud-Data-Lakes konsolidieren Organisationsdaten in einem Umfang und einer Vielfalt, die herkömmliche Data-Warehouses nicht erreichen. Genau diese Konsolidierung macht sie zum wertvollsten Ziel in einer Cloud-Umgebung. Die zum Schutz eines Data-Lakes erforderlichen Sicherheitsmaßnahmen sind keine optionalen Erweiterungen, sondern integraler Bestandteil der Architektur.

Die zonenbasierte Architektur bildet die Grundlage: Sie ermöglicht die Anwendung unterschiedlicher Verschlüsselungsschlüssel, Zugriffsrichtlinien und Aufbewahrungssteuerungen auf Daten in verschiedenen Verarbeitungsstadien und Sensibilitätsstufen und begrenzt so die Auswirkungen eines einzelnen Sicherheitsvorfalls. Kundenseitig verwaltete Verschlüsselungsschlüssel sind das Minimum für regulierte Workloads: Sie bieten die Nachvollziehbarkeit und unabhängige Schlüsselkontrolle, die anbieterseitig verwaltete Schlüssel nicht gewährleisten können. BYOK erfüllt die Anforderungen an die Schlüsselherkunft; HYOK erfüllt die Anforderungen an die Datensouveränität im Zero-Trust-Ansatz, bei dem der Cloud-Anbieter vollständig aus der Schlüsselhierarchie ausgeschlossen werden muss.

Das IAM-Modell, die Durchsetzung der Bucket-Richtlinien, der Schlüsselrotationsplan und die Konfiguration des Audit-Logs sind genauso wichtig wie die Wahl des Verschlüsselungsalgorithmus. Eine Data-Lake-Sicherheit, die lediglich die Verschlüsselung gewährleistet, ohne Zugriffskontrolle, Schlüsselverwaltung und kontinuierliche Überwachung zu berücksichtigen, lässt die wertvollsten Angriffsvektoren ungeschützt.

Häufig gestellte Fragen

Was versteht man unter Cloud-Data-Lake-Sicherheit?

Die Sicherheit eines Cloud-Data-Lake umfasst alle Kontrollmechanismen, die ein zentrales Cloud-Datenrepository vor unberechtigtem Zugriff und Compliance-Verstößen schützen. Zu den Kernmechanismen gehören die Verschlüsselung ruhender Daten (AES-256 mit kundenseitig verwalteten Schlüsseln) und während der Übertragung (TLS, erzwungen durch Bucket-Richtlinien), Identitäts- und Zugriffsmanagement mit Durchsetzung des Prinzips der minimalen Berechtigungen pro Data-Lake-Zone, Schlüsselverwaltung inklusive Rotation und Protokollierung, Datenklassifizierung sowie kontinuierliche Überwachung mittels SIEM und Cloud-nativer Sicherheitstools.

Worin besteht der Unterschied zwischen BYOK und HYOK in einem Cloud-Data-Lake?

BYOK bedeutet, dass Sie Schlüsselmaterial außerhalb des Cloud-Anbieters generieren und in dessen KMS importieren. Der Anbieter verwendet Ihren Schlüssel für Verschlüsselungsvorgänge und hat daher während der Nutzung Zugriff auf den Schlüssel, jedoch nicht auf das Quellmaterial. HYOK bedeutet, dass Sie Daten vor dem Hochladen verschlüsseln. Der Cloud-Anbieter speichert somit nur den verschlüsselten Text und hat unter keinen Umständen Zugriff auf den Verschlüsselungsschlüssel. HYOK bietet maximale Datensouveränität, erfordert jedoch eine höhere Anwendungskomplexität und einen größeren Bedarf an externer KMS-Infrastruktur.

Wie lässt sich das Prinzip der minimalen Zugriffsrechte in einem Cloud-Data-Lake durchsetzen?

Setzen Sie das Prinzip der minimalen Berechtigungen durch drei Kontrollebenen durch: Identitätsrichtlinien, die jeder Rolle nur die Berechtigungen gewähren, die sie für die jeweiligen Zonen benötigt; ressourcenbasierte Bucket- oder Containerrichtlinien, die den Zugriff für Benutzer, die nicht in der Liste der genehmigten Rollen für diese Zone enthalten sind, explizit verweigern; und KMS-Schlüsselrichtlinien, die Schlüsseladministratoren (die Schlüssel verwalten können) von Schlüsselbenutzern (die verschlüsseln und entschlüsseln können) trennen. Wenden Sie separate Richtlinien für jede Data-Lake-Zone an, damit der Zugriff auf eine Zone nicht automatisch den Zugriff auf eine vertrauenswürdige Zone gewährt.

Welche Compliance-Rahmenbedingungen gelten für die Sicherheit von Cloud-Data-Lakes?

HIPAA gilt für Gesundheitsdatenbanken mit geschützten Gesundheitsdaten (PHI) und erfordert Verschlüsselung, Zugriffskontrollen und Protokollierung. PCI DSS gilt für Zahlungsdatenbanken und erfordert Verschlüsselung, Schlüsselrotation, Vier-Augen-Prinzip bei Schlüsseloperationen und Zugriffsüberprüfungen. Die DSGVO gilt für personenbezogene Daten von EU-Bürgern und erfordert technische Kontrollen sowie die Möglichkeit, die Rechte der betroffenen Personen, einschließlich des Rechts auf Löschung, zu gewährleisten. FedRAMP gilt für Cloud-Workloads der US-Regierung und verweist auf die Kontrollen gemäß NIST SP 800-53 Rev. 5. Für die hohe Sicherheitsstufe sind FIPS 140-2- oder 140-3-validierte kryptografische Module erforderlich.

Wie funktioniert die Rotation von Verschlüsselungsschlüsseln in einem Cloud-Data-Lake?

Die Schlüsselrotation erfolgt über das KMS des Cloud-Anbieters, das das kryptografische Material des kundenverwalteten Schlüssels gemäß dem konfigurierten Zeitplan rotiert. Neu in den Data Lake geschriebene Objekte verwenden das neue Schlüsselmaterial. Bestehende Objekte bleiben mit der zum Zeitpunkt ihrer Erstellung aktiven Schlüsselversion verschlüsselt, und das KMS speichert alle vorherigen Versionen zur Entschlüsselung. Sie müssen bestehende Data-Lake-Objekte nicht erneut verschlüsseln oder hochladen. Für BYOK-Schlüssel mit importiertem Material ist die automatische Rotation über das Cloud-KMS nicht verfügbar; Sie müssen die Rotation extern verwalten und das aktualisierte Schlüsselmaterial erneut importieren.

Was ist Data-Lake-Zonierung und warum ist sie für die Sicherheit wichtig?

Die Zonierung eines Data Lakes unterteilt diesen in separate Speicherbereiche basierend auf dem Datenverarbeitungsstadium: temporäre Daten (temporär erfasste Daten), Rohdaten (Originalformat, oft personenbezogene Daten enthaltend), vertrauenswürdige Daten (validiert und verarbeitet, bereit für die Analyse) und bereinigte Daten (aggregierte Ergebnisse). Die Zonierung ist wichtig, da sie die Anwendung unterschiedlicher Verschlüsselungsschlüssel, Zugriffsrichtlinien und Aufbewahrungsrichtlinien pro Zone ermöglicht. Eine Kompromittierung der vertrauenswürdigen Zone führt nicht automatisch zur Offenlegung personenbezogener Daten in der Rohdatenzone, sofern diese durch separate Schlüssel und Zugriffsrichtlinien geschützt sind.