Data Lake, Datenschutz und die Cloud

 

Data Lake in der Cloud

Ein wichtiges Thema, dass fast jedes Unternehmen „umtreibt“ ist die Frage, ob man mit seinen IT-Systemen wie etwa einem Data Lake in die Cloud gehen soll. Der Betrieb von Anwendungen in der Cloud bietet nämlich zahlreiche Vorteile, die in vielen Fällen das Entwickeln und auch die Betriebsführung derselben einfacher und billiger machen können. Auf der anderen Seite gibt es aber Nachteile, welche sorgfältig gegen die Vorteile abgewogen werden müssen. Dazu gehört unter anderem, eine genaue Vorstellung zu entwickeln, wie man mit einem geeigneten Vorgehen den eher negativ bewerteten Aspekten gegensteuern kann, ohne die eigentlichen Vorteile zu verlieren.  Zu diesen gehören:

  • Die Cloud bietet standardisierte Produkte und eine möglichst einfache Automatisierung aller Arbeitsschritte
  • „Pay per Use“ oder „Pay as you go“: Klare Preismodelle, d.h. die Kosten sind vorhersagbar. Das hängt natürlich davon ab, ob man die Einsatzszenarien hinreichend genau kennt: Ein möglicher Kostentreiber kann Datentransfer von und in die Cloud sein. Klar bedeutet hierbei auch nicht, dass sich die Kosten einfach berechnen lassen, denn es gibt typischerweise viele Faktoren und Unbekannte, die die Kosten am Ende bestimmen… Und: „Cloud“ ist nicht unbedingt in allen Fällen billiger!
  • Verläßliche und bei Bedarf hochverfügbare und einfach skalierbare Umgebungen, ohne eine eigene Infrastruktur dafür betreiben zu müssen

Dem gegenüber stehen auch Nachteile, wie:

  • Höhere Abhängigkeit im Vergleich mit „On-Premise“ Lösungen, da die Infrastruktur nicht mehr in meiner eigenen Hand liegt und gegebenenfalls auch proprietäre Lösungen des Cloud Providers in Frage kommen
  • Das Thema Dateneigentümerschaft ist problematisch, denn der Cloud Provider hat ja notwendigerweise auch die Daten
  • Datenschutzthemen allgemein werden vor dem Hintergrund der Cloud kritisch gesehen

Erhalten der Vorteile, minimieren der Nachteile..

Dem Problem „höhere Abhängigkeit“ läßt sich relativ leicht gegensteuern. Im Grunde genommen muss ich nur dafür sorgen, dass Standardprodukte zum Einsatz kommen, welche problemlos auch in der Cloud eines anderen Providers laufen könnten, wie hier skizziert:

  • Aufbau des Data Lakes in „leeren“ virtuellen Umgebungen mit einer Standard Linux Distribution als Betriebssystem
  • Einsatz einer standardisierten Big Data Distribution wie beispielsweise Hortonworks und, soweit möglich, Vermeidung irgendwelcher herstellerspezifischer Komponenten
  • Generell Einsatz von Open Source Hadoop Tools und Big Data Komponenten
  • Verwendung von Architekturstandards und –patterns
  • Einsatz gängiger Programmiersprachen und Protokolle
  • Vermeiden des Einsatzes von Cloud Provider spezifischen Lösungen

Ein schwierigeres Thema ist das des Datenschutzes und der eng damit verbundenen Problematik der Dateneigentümerschaft. Hier besteht ja das Grundproblem schon darin, dass die Daten nicht „bei mir“ sondern „irgendwo“ in der Cloud liegen. Das heißt natürlich, sie liegen in der Infrastruktur des Cloud Providers. Dieser hat damit potentiell auch Vollzugriff auf die Daten, wobei nicht zwischen sensiblen und (relativ) unsensiblen Daten unterschieden wird. Genau hier kommt auch gleich der Datenschutz ins Spiel – ohne nachgewiesenen Schutz dürfen sensible Daten typischerweise gar nicht das Unternehmen verlassen. Manchmal heißt „gar nicht“ auch im absoluten Sinne, dass es unmöglich ist, die Daten außerhalb bestimmter zugelassener „Bereiche“ innerhalb des Unternehmens zu speichern. In diesem Falle ist Cloud leider keine Lösung. Wenn es darum geht, dass Daten nur in Cloudcentern einer bestimmte Region physikalisch gespeichert werden oder gar ein Land nicht verlassen dürfen, dann ist die Antwort größerer Cloud Provider meist das Angebot, Daten auch physikalisch nur in Cloud-Rechenzentren einer bestimmten Region (Europa) oder eines Landes (z.B. Deutschland / Frankfurt) zu speichern. Oftmals ist das verbunden mit rechtlichen Konstrukten die unterbinden, dass Dritte Zugriff auf die Daten verlangen dürfen.

Eine Stufe „tiefergelegt“

Neben diesen allgemeinen Maßnahmen gibt es zahlreiche weitere, die tiefer gehen. Im folgenden eine Auswahl anhand von konkreter Praxiserfahrung in Data Lake Projekten:

  • Verschlüsselung der Root Partition aller „Server“ Instanzen und aller weiteren Partitionen (falls vorhanden), ganz besonders auch der Bereiche, in denen meine Daten gespeichert werden
  • Verschlüsselung aller Daten vor Upload in den Data Lake in der Cloud, Entschlüsselung erst nach Download aus der Cloud
  • Sichere Protokolle
  • Zugriffe über Edge Server / Bastion Server
  • Nur die benötigten Services und Ports zwischen konkreten Endpunkten freischalten
  • Feingranulares Berechtigungskonzept
  • Mandantenbasierte Architektur und Sandboxing
  • Klardaten speichern nur wo explizit hierfür eine Rechtsgrundlage existiert
  • Pseudonymisierung und Anonymisierung aller anderen Daten
  • Feingranulares Löschkonzept von Beginn an vorsehen

Und, und , und … Hier ließen sich sicher noch weitere Dinge aufzählen. Doch ich denke, dass das, was ich hier skizziert habe schon mal einen gewissen Überblick zu möglichen Lösungsszenarien gibt. Wenn ich alle diese Dinge beachte (es dürfen auch gerne mehr sein), dann habe ich tatsächlich eine Chance, einen sicheren Data Lake in der Cloud aufzubauen. Einen Data Lake, der den Anforderungen aus Compliance und Datenschutz wirklich genügt.

 

0 Antworten

Hinterlassen Sie einen Kommentar

Wollen Sie an der Diskussion teilnehmen?
Feel free to contribute!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.