Data Lake und Datenschutz: Alles schwimmt in eigenen Bahnen

Sandboxing und logische Trennung von Bereichen

Ein Begriff, der in Diskussionen zur Architektur von Hadoop-basierten Data Lakes immer wieder fällt, ist „Sandboxing“. Damit ist gemeint, dass es für bestimmte Zwecke nützlich, für manche sogar notwendig ist, vom „eigentlichen“ Data Lake getrennte Bereiche zu haben. Diese können auch außerhalb der Data Lake Infrastruktur liegen. Ein Beispiel hierfür sind analytische Sandboxes, die maßgeschneiderte Umgebungen und Daten nur für Data Scientists bereitstellen. In solchen Umgebungen können verschiedene Methoden und Verfahren entwickelt und erprobt werden, ohne die große „Allgemeinheit“ der Data Lake User zu stören. Da solche Sandboxes typischerweise kleine Varianten derselben Hadoop Distribution sind, ist es in der Regel sehr einfach, später die Ergebnisse in den großen Data Lake zu übertragen. „Klein“ bedeutet hierbei, dass die Anzahl der Worker Nodes und damit auch des Speicherplatzes gegenüber dem eigentlichen Data Lake kleiner ausfallen. Es kann sogar Sinn machen, einen Single Node Cluster aufzusetzen, beispielsweise um bestimmte Funktionalitäten initial auszuprobieren.

Was natürlich auch in Hinblick auf Kosten und gemeinsame Verwendung von Ressourcen oftmals angestrebt wird, ist die Realisierung von „Sandboxes“ in der eigentlichen Data Lake Infrastruktur als alternative Variante. Neben der Notwendigkeit, für alle Benutzerkreise ein passendes Ressourcenmanagement zu entwickeln – hier ist YARN eine wichtige Komponente zur Steuerung – muss man auch Daten und Zugriffsbereiche separieren. Oder anders gesagt: Hier ist nicht nur aus Gründen des Datenschutzes ein passendes Sicherheits- und Zugriffskonzept zu entwickeln – in der Regel gibt es User, die nur auf bestimmte Daten in bestimmten „Sandboxes“ zugreifen dürfen! Jeder Benutzerkreis schwimmt also in seinen eigenen Bahnen.

 

 

 

 

Das läuft darauf hinaus, dass man abgegrenzte Bereiche einrichtet, auf die der eigentliche Data Lake keinen Zugriff hat, sondern nur ein bestimmter Kreis von Usern und / oder Mandanten. Ein typisches Beispiel sind spezielle Klardatenbereiche, die nur dann zulässig sind, wenn man nachweisen kann, dass nur berechtigte Personen mit diesen Daten etwas „machen dürfen“. Das Managen und Nutzen dieser Daten obliegt dann auch ausschließlich diesem Personenkreis. Genauso aber können das auch anonymisierte oder pseudonymisierte Bereiche sein, für die ähnliches gilt. Was also generell gefordert wird ist eine Mandantenfähigkeit des Data Lakes, also die Möglichkeit klar abgegrenzte Bereiche einzurichten

  • mit feingranularer Zugriffsteuerung
  • mit der Möglichkeit einer passenden Ressourcensteuerung

Es ist natürlich innerhalb eines großen Data Lakes viel schwieriger das alles einzurichten, zu steuern und zu administrieren. Deshalb muss immer auch eine Abwägung vorgenommen werden, ob es vielleicht einfacher ist, mit separaten Umgebungen zu arbeiten. Hier sind die Bereiche auch „physisch“ getrennt. Eine Forderung, die von Seiten des Datenschutzes oftmals erhoben wird. Aber nehmen wir mal an, wir könnten mit „logisch“ getrennten Bereichen im Data Lake arbeiten. Wie kann man das erreichen?

Mandantenfähigkeit

Typische Hadoop Distributionen wie z.B. Hortonworks enthalten Mittel für solche Zwecke. Das sind Services und Tools, die die Trennung von Mandanten unterstützen. Wichtig ist dabei, dass eine zentrale Security und Governance Infrastruktur eine Klammer um das Ganze bilden kann.

Im Fall von Hortonworks ist hierbei Apache Ranger eine wesentliche Komponente. Über Ranger lassen sich User, Gruppen / Rollen und deren Berechtigungen feingranular in den folgenden wichtigen Hadoop Komponenten verwalten:

  • Apache Hadoop HDFS
  • Apache Hive
  • Apache HBase
  • Apache Solr
  • Apache Storm
  • Apache Knox
  • Apache Kafka
  • Apache Nifi
  • Apache YARN

Mandanten sind hierbei Gruppen / Rollen und deren Berechtigungen. Grundsätzlich sind das zunächst die Berechtigungen zu schreiben, zu lesen, Daten zu löschen, Objekte anzulegen und zu löschen. Aber es geht auch noch spezieller: In Hive lässt sich beispielsweise der Zugriff auf Tabellen und Views, bestimmte Spalten und sogar eine „row-level“ Security in den Daten selbst realisieren. Das heißt es lässt sich eine Filterung der Daten abhängig vom Security Kontext über eine implizite „where-clause“ des SQL (HiveQL) Statements erreichen. Genauso lassen sich im Hadoop Filesystem HDFS Bereiche (Folder) nur für Mandanten einrichten, dasselbe gilt für Kafka Topics, also die Kafka Messages Bereiche, die nur für bestimmte Mandanten gedacht sind. Ranger wiederum nutzt die nativen Security Mechanismen der einzelnen Komponenten via Plug-Ins.

Und „Sandboxes“?

Sandboxes sind dann einfach die jeweils für bestimmte Nutzergruppen und / oder Mandanten zugänglichen Bereiche wie Hive und HBase Tabellen, bestimmte Directories im HDFS, bestimmte Kafka Topics und auch Solr Collections, beziehungsweise in Hive auch Views und noch tiefergehende Berechtigungen wie „Row-level Security“, die an einer „Mandanten-ID“ in der jeweiligen Tabelle festgemacht werden kann. Wichtig ist eigentlich nur, dass man allen anderen Usern / Gruppen / Rollen, die auch Zugriff auf den Data Lake haben, den Zugriff auf die solchermaßen geschützten Ressourcen entzieht. Für Klardaten bietet sich zusätzlich auch die Verwendung von „Encryption Zones“ im HDFS an, d.h. nur ein Mandant mit dem entsprechenden Schlüssel kann die Daten in Klarform abgreifen, alle anderen bleiben hier außen vor, selbst wenn sie unberechtigterweise sich Zugriff auf die Daten verschaffen können. Das generelle Verschlüsseln von Daten jenseits der speziellen Anforderungen der Anonymisierung und Pseudonymisierung ist besonders für den Cloud Betrieb relevant. Dazu demnächst mehr.

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.