Consider Anonymization – Process Mining Rule 3 of 4

This is article no. 3 of the four-part article series Privacy, Security and Ethics in Process Mining.

Read this article in German:
Datenschutz, Sicherheit und Ethik beim Process Mining – Regel 3 von 4

If you have sensitive information in your data set, instead of removing it you can also consider the use of anonymization. When you anonymize a set of values, then the actual values (for example, the employee names “Mary Jones”, “Fred Smith”, etc.) will be replaced by another value (for example, “Resource 1”, “Resource 2”, etc.).

If the same original value appears multiple times in the data set, then it will be replaced with the same replacement value (“Mary Jones” will always be replaced by “Resource 1”). This way, anonymization allows you to obfuscate the original data but it preserves the patterns in the data set for your analysis. For example, you will still be able to analyze the workload distribution across all employees without seeing the actual names.

Some process mining tools (Disco and ProM) include anonymization functionality. This means that you can import your data into the process mining tool and select which data fields should be anonymized. For example, you can choose to anonymize just the Case IDs, the resource name, attribute values, or the timestamps. Then you export the anonymized data set and you can distribute it among your team for further analysis.


  • Determine which data fields are sensitive and need to be anonymized (see also the list of common process mining attributes and how they are impacted if anonymized).
  • Keep in mind that despite the anonymization certain information may still be identifiable. For example, there may be just one patient having a very rare disease, or the birthday information of your customer combined with their place of birth may narrow down the set of possible people so much that the data is not anonymous anymore.


  • Anonymize the data before you have cleaned your data, because after the anonymization the data cleaning may not be possible anymore. For example, imagine that slightly different customer category names are used in different regions but they actually mean the same. You would like to merge these different names in a data cleaning step. However, after you have anonymized the names as “Category 1”, “Category 2”, etc. the data cleaning cannot be done anymore.
  • Anonymize fields that do not need to be anonymized. While anonymization can help to preserve patterns in your data, you can easily lose relevant information. For example, if you anonymize the Case ID in your incident management process, then you cannot look up the ticket number of the incident in the service desk system anymore. By establishing a collaborative culture around your process mining initiative (see guideline No. 4) and by working in a responsible, goal-oriented way, you can often work openly with the original data that you have within your team.

Responsible Handling of Data – Process Mining Rule 2 of 4

This is article no. 2 of the four-part article series Privacy, Security and Ethics in Process Mining.

Read this article in German:
Datenschutz, Sicherheit und Ethik beim Process Mining – Regel 2 von 4

Like in any other data analysis technique, you must be careful with the data once you have obtained it. In many projects, nobody thinks about the data handling until it is brought up by the security department. Be that person who thinks about the appropriate level of protection and has a clear plan already prior to the collection of the data.


  • Have external parties sign a Non Disclosure Agreement (NDA) to ensure the confidentiality of the data. This holds, for example, for consultants you have hired to perform the process mining analysis for you, or for researchers who are participating in your project. Contact your legal department for this. They will have standard NDAs that you can use.
  • Make sure that the hard drive of your laptop, external hard drives, and USB sticks that you use to transfer the data and your analysis results are encrypted.


  • Give the data set to your co-workers before you have checked what is actually in the data. For example, it could be that the data set contains more information than you requested, or that it contains sensitive data that you did not think about. For example, the names of doctors and nurses might be mentioned in a free-text medical notes attribute. Make sure you remove or anonymize (see guideline No. 3) all sensitive data before you pass it on.
  • Upload your data to a cloud-based process mining tool without checking that your organization allows you to upload this kind of data. Instead, use a desktop-based process mining tool (like Disco [3] or ProM [4]) to analyze your data locally or get the cloud-based process mining vendor to set-up an on-premise version of their software within your organization. This is also true for cloud-based storage services like Dropbox: Don’t just store data or analysis results in the cloud even if it is convenient.

Privacy, Security and Ethics in Process Mining – Article Series

When I moved to the Netherlands 12 years ago and started grocery shopping at one of the local supermarket chains, Albert Heijn, I initially resisted getting their Bonus card (a loyalty card for discounts), because I did not want the company to track my purchases. I felt that using this information would help them to manipulate me by arranging or advertising products in a way that would make me buy more than I wanted to. It simply felt wrong.

Read this article in German:
Datenschutz, Sicherheit und Ethik beim Process Mining – Artikelserie

The truth is that no data analysis technique is intrinsically good or bad. It is always in the hands of the people using the technology to make it productive and constructive. For example, while supermarkets could use the information tracked through the loyalty cards of their customers to make sure that we have to take the longest route through the store to get our typical items (passing by as many other products as possible), they can also use this information to make the shopping experience more pleasant, and to offer more products that we like.

Most companies have started to use data analysis techniques to analyze their data in one way or the other. These data analyses can bring enormous opportunities for the companies and for their customers, but with the increased use of data science the question of ethics and responsible use also grows more dominant. Initiatives like the Responsible Data Science seminar series [1] take on this topic by raising awareness and encouraging researchers to develop algorithms that have concepts like fairness, accuracy, confidentiality, and transparency built in (see Wil van der Aalst’s presentation on Responsible Data Science at Process Mining Camp 2016).

Process Mining can provide you with amazing insights about your processes, and fuel your improvement initiatives with inspiration and enthusiasm, if you approach it in the right way. But how can you ensure that you use process mining responsibly? What should you pay attention to when you introduce process mining in your own organization?

In this article series, we provide you four guidelines that you can follow to prepare your process mining analysis in a responsible way:

Part 1 of 4: Clarify the Goal of the Analysis

Part 2 of 4: Responsible Handling of Data

Part 3 of 4: Consider Anonymization

– Part 4 of 4: Establish a collaborative Culture (COMING SOON!)


We would like to thank Frank van Geffen and Léonard Studer, who initiated the first discussions in the workgroup around responsible process mining in 2015. Furthermore, we would like to thank Moe Wynn, Felix Mannhardt and Wil van der Aalst for their feedback on earlier versions of this article.

Einstieg in das Maschinelle Lernen mit Python(x,y)

Python(x,y) ist eine Python-Distribution, die speziell für wissenschaftliche Arbeiten entwickelt wurde. Es umfasst neben der Programmiersprache auch die Entwicklungsumgebung Spyder und eine Reihe integrierter Python-Bibliotheken. Mithilfe von Python(x,y) kann eine Vielzahl von Interessensbereichen bearbeitet werden. Dazu zählen unter anderem Bildverarbeitung oder auch das maschinelle Lernen. Das All-in-One-Setup für Python(x,y) ist für alle gängigen Betriebssysteme online erhältlich. Read more

R Data Frames meistern mit dplyr – Teil 2

Dieser Artikel ist Teil 2 von 2 aus der Artikelserie R Data Frames meistern mit dplyr.

Noch mehr Datenbank-Features

Im ersten Teil dieser Artikel-Serie habe ich die Parallelen zwischen Data Frames in R und Relationen in SQL herausgearbeitet und gezeigt, wie das Paket dplyr eine Reihe von SQL-analogen Operationen auf Data Frames standardisiert und optimiert. In diesem Teil möchte ich nun drei weitere Analogien aufzeigen. Es handelt sich um die

  • Window Functions in dplyr als Entsprechung zu analytischen Funktionen in SQL,
  • Joins zwischen Data Frames als Pendant zu Tabellen-Joins
  • Delegation von Data Frame-Operationen zu einer bestehenden SQL-Datenbank

Window Functions

Im letzten Teil habe ich gezeigt, wie durch die Kombination von group_by() und summarise() im Handumdrehen Aggregate entstehen. Das Verb group_by() schafft dabei, wie der Name schon sagt, eine Gruppierung der Zeilen des Data Frame anhand benannter Schlüssel, die oft ordinaler oder kategorialer Natur sind (z.B. Datum, Produkt oder Mitarbeiter).

Ersetzt man die Aggregation mit summarise() durch die Funktion mutate(), um neue Spalten zu bilden, so ist der Effekt des group_by() weiterhin nutzbar, erzeugt aber „Windows“, also Gruppen von Datensätzen des Data Frames mit gleichen Werten der Gruppierungskriterien. Auf diesen Gruppen können nun mittels mutate() beliebige R-Funktionen angewendet werden. Das Ergebnis ist im Gegensatz zu summarise() keine Verdichtung auf einen Datensatz pro Gruppe, sondern eine Erweiterung jeder einzelnen Zeile um neue Werte. Das soll folgendes Beispiel verdeutlichen:

Das group_by() unterteilt den Data Frame nach den 4 gleichen Werten von a. Innerhalb dieser Gruppen berechnen die beispielsweise eingesetzten Funktionen

  • row_number(): Die laufende Nummer in dieser Gruppe
  • n(): Die Gesamtgröße dieser Gruppe
  • n_distinct(b): Die Anzahl verschiedener Werte von b innerhalb der Gruppe
  • rank(desc(b)): Den Rang innerhalb der selben Gruppe, absteigend nach b geordnet
  • lag(b): Den Wert von b der vorherigen Zeile innerhalb derselben Gruppe
  • lead(b): Analog den Wert von b der folgenden Zeile innerhalb derselben Gruppe
  • mean(b): Den Mittelwert von b innerhalb der Gruppe
  • cumsum(b): Die kumulierte Summe der b-Werte innerhalb der Gruppe.

Wichtig ist hierbei, dass die Anwendung dieser Funktionen nicht dazu führt, dass die ursprüngliche Reihenfolge der Datensätze im Data Frame geändert wird. Hier erweist sich ein wesentlicher Unterschied zwischen Data Frames und Datenbank-Relationen von Vorteil: Die Reihenfolge von Datensätzen in Data Frames ist stabil und definiert. Sie resultiert aus der Abfolge der Elemente auf den Vektoren, die die Data Frames bilden. Im Gegensatz dazu haben Tabellen und Views keine Reihenfolge, auf die man sich beim SELECT verlassen kann. Nur mit der ORDER BY-Klausel über eindeutige Schlüsselwerte erreicht man eine definierte, stabile Reihenfolge der resultierenden Datensätze.

Die Wirkungsweise von Window Functions wird noch besser verständlich, wenn in obiger Abfrage das group_by(a) entfernt wird. Dann wirken alle genannten Funktionen auf der einzigen Gruppe, die existiert, nämlich dem gesamten Data Frame:

Anwendbar sind hierbei sämtliche Funktionen, die auf Vektoren wirken. Diese müssen also wie in unserem Beispiel nicht unbedingt aus dplyr stammen. Allerdings komplettiert das Package die Menge der sinnvoll anwendbaren Funktionen um einige wichtige Elemente wie cumany() oder n_distinct().

Data Frames Hand in Hand…

In relationalen Datenbanken wird häufig angestrebt, das Datenmodell zu normalisieren. Dadurch bekommt man die negativen Folgen von Datenredundanz, wie Inkonsistenzen bei Datenmanipulationen und unnötig große Datenvolumina, in den Griff. Dies geschieht unter anderem dadurch, dass tabellarische Datenbestände aufgetrennt werden Stammdaten- und Faktentabellen. Letztere beziehen sich über Fremdschlüsselspalten auf die Primärschlüssel der Stammdatentabellen. Durch Joins, also Abfragen über mehrere Tabellen und Ausnutzen der Fremdschlüsselbeziehungen, werden die normalisierten Tabellen wieder zu einem fachlich kompletten Resultat denormalisiert.

In den Data Frames von R trifft man dieses Modellierungsmuster aus verschiedenen Gründen weit seltener an als in RDBMS. Dennoch gibt es neben der Normalisierung/Denormalisierung andere Fragestellungen, die sich gut durch Joins beantworten lassen. Neben der Zusammenführung von Beobachtungen unterschiedlicher Quellen anhand charakteristischer Schlüssel sind dies bestimmte Mengenoperationen wie Schnitt- und Differenzmengenbildung.

Die traditionelle R-Funktion für den Join zweier Data Frames lautet merge(). dplyr erweitert den Funktionsumfang dieser Funktion und sorgt für sprechendere Funktionsnamen und Konsistenz mit den anderen Operationen.

Hier ein synthetisches Beispiel:

Nun gilt es, die Verkäufe aus dem Data Frame sales mit den Produkten in products zusammenzuführen und auf Basis von Produkten Bilanzen zu erstellen. Diese Denormalisierung geschieht durch das Verb inner_join() auf zweierlei Art und Weise:

Die Ergebnisse sind bis auf die Reihenfolge der Spalten und der Zeilen identisch. Außerdem ist im einen Fall der gemeinsame Schlüssel der Produkt-Id als prod_id, im anderen Fall als id enthalten. dplyr entfernt also die Spalten-Duplikate der Join-Bedingungen. Letzere wird bei Bedarf im by-Argument der Join-Funktion angegeben. R-Experten erkennen hier einen „Named Vector“, also einen Vektor, bei dem jedes Element einen Namen hat. Diese Syntax verwendet dplyr, um elegant die äquivalenten Spalten zu kennzeichnen. Wird das Argument by weggelassen, so verwendet dplyr im Sinne eines „Natural Join“ automatisch alle Spalten, deren Namen in beiden Data Frames vorkommen.

Natürlich können wir dieses Beispiel mit den anderen Verben erweitern, um z.B. eine Umsatzbilanz pro Produkt zu erreichen:

dplyr bringt insgesamt 6 verschiedene Join-Funktionen mit: Neben dem bereits verwendeten Inner Join gibt es die linksseitigen und rechtsseitigen Outer Joins und den Full Join. Diese entsprechen genau der Funktionalität von SQL-Datenbanken. Daneben gibt es die Funktion semi_join(), die in SQL etwa folgendermaßen ausgedrückt würde:

Das Gegenteil, also ein NOT EXISTS, realisiert die sechste Join-Funktion: anti_join(). Im folgenden Beispiel sollen alle Produkte ausgegeben werden, die noch nie verkauft wurden:

… und in der Datenbank

Wir schon mehrfach betont, hat dplyr eine Reihe von Analogien zu SQL-Operationen auf relationalen Datenbanken. R Data Frames entsprechen Tabellen und Views und die dplyr-Operationen den Bausteinen von SELECT-Statements. Daraus ergibt sich die Möglichkeit, dplyr-Funktionen ohne viel Zutun auf eine bestehende Datenbank und deren Relationen zu deligieren.

Mir fallen folgende Szenarien ein, wo dies sinnvoll erscheint:

  • Die zu verarbeitende Datenmenge ist zu groß für das Memory des Rechners, auf dem R läuft.
  • Die interessierenden Daten liegen bereits als Tabellen und Views auf einer Datenbank vor.
  • Die Datenbank hat Features, wie z.B. Parallelverarbeitung oder Bitmap Indexe, die R nicht hat.

In der aktuellen Version 0.5.0 kann dplyr nativ vier Datenbank-Backends ansprechen: SQLite, MySQL, PostgreSQL und Google BigQuery. Ich vermute, unter der Leserschaft des Data Science Blogs dürfte MySQL (oder der Fork MariaDB) die weiteste Verbreitung haben, weshalb ich die folgenden Beispiele darauf zeige. Allerdings muss man beachten, dass MySQL keine Window Funktionen kennt, was sich 1:1 auf die Funktionalität von dplyr auswirkt.

Im folgenden möchte ich zeigen, wie dplyr sich gegen eine bestehende MySQL-Datenbank verbindet und danach einen bestehenden R Data Frame in eine neue Datenbanktabelle wegspeichert:

Die erste Anweisung verbindet R mit einer bestehenden MySQL-Datenbank. Danach lade ich den Data Frame diamonds aus dem Paket ggplot2. Mit str() wird deutlich, dass drei darin enthaltene Variablen vom Typ Factor sind. Damit dplyr damit arbeiten kann, werden sie mit mutate() in Character-Vektoren gewandelt. Dann erzeugt die Funktion copy_to() auf der MySQL-Datenbank eine leere Tabelle namens diamonds, in die die Datensätze kopiert werden. Danach erhält die Tabelle noch drei Indexe (von dem der erste aus drei Segmenten besteht), und zum Schluß führt dplyr noch ein ANALYSE der Tabelle durch, um die Werteverteilungen auf den Spalten für kostenbasierte Optimierung zu bestimmen.

Meistens aber wird bereits eine bestehende Datenbanktabelle die interessierenden Daten enthalten. In diesem Fall lautet die Funktion zum Erstellen des Delegats tbl():

Die Rückgabewerte von copy_to() und von tbl() sind natürlich keine reinrassigen Data Frames, sondern Objekte, auf die die Operationen von dplyr wirken können, indem sie auf die Datenbank deligiert werden. Im folgenden Beispiel sollen alle Diamanten, die ein Gewicht von mindestens 1 Karat haben, pro Cut, Color und Clarity nach Anzahl und mittlerem Preis bilanziert werden:

Die Definition der Variablen bilanz geschieht dabei komplett ohne Interaktion mit der Datenbank. Erst beim Anzeigen von Daten wird das notwendige SQL ermittelt und auf der DB ausgeführt. Die ersten 10 resultierenden Datensätze werden angezeigt. Mittels der mächtigen Funktion explain() erhalten wir das erzeugte SQL-Kommando und sogar den Ausführungsplan auf der Datenbank. SQL-Kundige werden erkennen, dass die verketteten dplyr-Operationen in verschachtelte SELECT-Statements umgesetzt werden.

Zu guter Letzt sollen aber meistens die Ergebnisse der dplyr-Operationen irgendwie gesichert werden. Hier hat der Benutzer die Wahl, ob die Daten auf der Datenbank in einer neuen Tabelle gespeichert werden sollen oder ob sie komplett nach R transferiert werden sollen. Dies erfolgt mit den Funktionen compute() bzw. collect():

Durch diese beiden Operationen wurde eine neue Datenbanktabelle „t_bilanz“ erzeugt und danach der Inhalt der Bilanz als Data Frame zurück in den R-Interpreter geholt. Damit schließt sich der Kreis.


Mit dem Paket dplyr von Hadley Wickham wird die Arbeit mit R Data Frames auf eine neue Ebene gehoben. Die Operationen sind konsistent, vollständig und performant. Durch den Verkettungs-Operator %>% erhalten sie auch bei hoher Komplexität eine intuitive Syntax. Viele Aspekte der Funktionalität lehnen sich an Relationale Datenbanken an, sodass Analysten mit SQL-Kenntnissen rasch viele Operationen auf R Data Frames übertragen können.

Zurück zu R Data Frames meistern mit dplyr – Teil 1.


Was ist eigentlich Apache Spark?

Viele Technologieanbieter versprechen schlüsselfertige Lösungen für Big Data Analytics, dabei kann keine proprietäre Software-Lösung an den Umfang und die Mächtigkeit einiger Open Source Projekten heranreichen.

Seit etwa 2010 steht das Open Source Projekt Hadoop, ein Top-Level-Produkt der Apache Foundation, als einzige durch Hardware skalierbare Lösung zur Analyse von strukturierten und auch unstrukturierten Daten. Traditionell im Geschäftsbereich eingesetzte Datenbanken speichern Daten in einem festen Schema ab, das bereits vor dem Laden der Daten definiert sein muss. Dieses Schema-on-Write-Prinzip stellt zwar sicher, dass Datenformate bekannt und –konflikte vermieden werden. Es bedeutet jedoch auch, dass bereits vor dem Abspeichern bekannt sein muss, um welche Daten es sich handelt und ob diese relevant sind. Im Hadoop File System (HDFS) wird ein Schema für erst bei lesenden Zugriff erstellt.

Apache Spark ist, ähnlich wie Hadoop, dank Parallelisierung sehr leistungsfähig und umfangreich mit Bibliotheken (z. B. für Machine Learning) und Schnittstellen (z. B. HDFS) ausgestattet. Allerdings ist Apache Spark nicht für jede Big Data Analytics Aufgabe die beste Lösung, Als Einstiegslektüre empfiehlt sich das kostenlose Ebook Getting Started with Spark: From Inception to Production. Wer jedoch erstmal wissen möchte, erfährt nachfolgend die wichtigsten Infos, die es über Apache Spark zu wissen gilt.

Was ist Apache Spark?

Apache Spark ist eine Allzweck-Tool zur Datenverarbeitung, eine sogenannte Data Processing Engine. Data Engineers und Data Scientists setzen Spark ein, um äußerst schnelle Datenabfragen (Queries) auf große Datenmengen im Terabyte-Bereich ausführen zu können.

Spark wurde 2013 zum Incubator-Projekt der Apache Software Foundation, eine der weltweit wichtigsten Organisationen für Open Source. Bereits 2014 es wie Hadoop zum Top-Level-Produkt. Aktuell ist Spark eines der bedeutensten Produkte der Apache Software Foundation mit viel Unterstützung von Unternehmen wie etwa Databricks, IBM und Huawei.

Was ist das Besondere an Spark?

Mit Spark können Daten transformiert, zu fusioniert und auch sehr mathematische Analysen unterzogen werden.
Typische Anwendungsszenarien sind interactive Datenabfragen aus verteilten Datenbeständen und Verarbeitung von fließenden Daten (Streaming) von Sensoren oder aus dem Finanzbereich. Die besondere Stärke von Spark ist jedoch das maschinelle Lernen (Machine Learning) mit den Zusätzen MLib (Machine Learning Bibliothek) oder SparkR (R-Bibliotheken direkt unter Spark verwenden), denn im Gegensatz zum MapReduce-Algorithmus von Hadoop, der einen Batch-Prozess darstellt, kann Spark sehr gut iterative Schleifen verarbeiten, die für Machine Learning Algorithmen, z. B. der K-Nearest Neighbor Algorithmus, so wichtig sind.spark-stack

Spark war von Beginn an darauf ausgelegt, Daten dynamisch im RAM (Arbeitsspeicher) des Server-Clusters zu halten und dort zu verarbeiten. Diese sogenannte In-Memory-Technologie ermöglicht die besonders schnelle Auswertung von Daten. Auch andere Datenbanken, beispielsweise SAP Hana, arbeiten In-Memory, doch Apache Spark kombiniert diese Technik sehr gut mit der Parallelisierung von Arbeitsschritten über ein Cluster und setzt sich somit deutlich von anderen Datenbanken ab. Hadoop ermöglicht über MapReduce zwar ebenfalls eine Prallelisierung, allerdings werden bei jedem Arbeitsschrit Daten von einer Festplatte zu einer anderen Festplatte geschrieben. Im Big Data Umfeld kommen aus Kostengründen überwiegend noch mechanisch arbeitende Magnet-Festplatten zum Einsatz, aber selbst mit zunehmender Verbreitung von sehr viel schnelleren SSD-Festplatten, ist der Arbeitsspeicher hinsichtlich der Zeiten für Zugriff auf und Schreiben von Daten unschlagbar. So berichten Unternehmen, die Spark bereits intensiv einsetzen, von einem 100fachen Geschwindigkeitsvorteil gegenüber Hadoop MapReduce.

Spark kann nicht nur Daten im Terabyte, sondern auch im Petabyte-Bereich analysieren, ein entsprechend großes Cluster, bestehend aus tausenden physikalischer oder virtueller Server, vorausgesetzt. Ähnlich wie auch bei Hadoop, skaliert ein Spark-Cluster mit seiner Größe linear in seiner Leistungsfähigkeit. Spark ist neben Hadoop ein echtes Big Data Framework.
Spark bringt sehr viele Bibliotheken und APIs mit, ist ferner über die Programmiersprachen Java, Python, R und Scala ansprechbar – das sind ohne Zweifel die im Data Science verbreitetsten Sprachen. Diese Flexibilität und geringe Rüstzeit rechtfertigt den Einsatz von Spark in vielen Projekten. Es kann sehr herausfordernd sein, ein Data Science Team mit den gleichen Programmiersprachen-Skills aufzubauen. In Spark kann mit mehreren Programmiersprachen gearbeitet werden, so dass dieses Problem teilweise umgangen werden kann.spark-runs-everywhere

In der Szene wird Spark oftmals als Erweiterung für Apache Hadoop betrachtet, denn es greift nahtlos an HDFS an, das Hadoop Distributed File System. Dank der APIs von Spark, können jedoch auch Daten anderer Systeme abgegriffen werden, z. B. von HBase, Cassandra oder MongoDB.

Was sind gängige Anwendungsbeispiele für Spark?

  • ETL / Datenintegration: Spark und Hadoop eignen sich sehr gut, um Daten aus unterschiedlichen Systemen zu filtern, zu bereinigen und zusammenzuführen.
  • Interaktive Analyse: Spark eignet sich mit seinen Abfragesystemen fantastisch zur interaktiven Analyse von großen Datenmengen. Typische Fragestellungen kommen aus dem Business Analytics und lauten beispielsweise, welche Quartalszahlen für bestimmte Vertriebsregionen vorliegen, wie hoch die Produktionskapazitäten sind oder welche Lagerreichweite vorhanden ist. Hier muss der Data Scientist nur die richtigen Fragen stellen und Spark liefert die passenden Antworten.
  • Echtzeit-Analyse von Datenströmen: Anfangs vor allem zur Analyse von Server-Logs eingesetzt, werden mit Spark heute auch Massen von Maschinen- und Finanzdaten im Sekundentakt ausgewertet. Während Data Stream Processing für Hadoop noch kaum möglich war, ist dies für Spark ein gängiges Einsatzgebiet. Daten, die simultan von mehreren Systemen generiert werden, können mit Spark problemlos in hoher Geschwindigkeit zusammengeführt und analysiert werden.
    In der Finanzwelt setzen beispielsweise Kreditkarten-Unternehmen Spark ein, um Finanztransaktionen in (nahezu) Echtzeit zu analysieren und als potenziellen Kreditkartenmissbrauch zu erkennen.
  • Maschinelles Lernen: Maschinelles Lernen (ML – Machine Learning) funktioniert desto besser, je mehr Daten in die ML-Algorithmen einbezogen werden. ML-Algorithmen haben in der Regel jedoch eine intensive, vom Data Scientist betreute, Trainingsphase, die dem Cluster viele Iterationen an Arbeitsschritten auf die großen Datenmengen abverlangen. Die Fähigkeit, Iterationen auf Daten im Arbeitsspeicher, parallelisiert in einem Cluster, durchführen zu können, macht Spark zurzeit zu dem wichtigsten Machine Learning Framework überhaupt.
    Konkret laufen die meisten Empfehlungssysteme (beispielsweise von Amazon) auf Apache Spark.


Eine Hadoop Architektur mit Enterprise Sicherheitsniveau

Dies ist Teil 3 von 3 der Artikelserie zum Thema Eine Hadoop-Architektur mit Enterprise Sicherheitsniveau.

Die ideale Lösung

Man denkt, dass die Integration einer sehr alten Technologie, wie ActiveDirectory oder LDAP zusammen mit einem etablierten und ausgereiften Framework wie Hadoop reibungslos funktionieren würde. Leider sind solche Annahmen in der IT Welt zu gut um wahr zu sein. Zum Glück gibt es bereits erste Erfahrungsberichte  von  Unternehmen, die ihre Hadoop Infrastruktur an ein zentrales IMS gekoppelt haben.

Da die meisten Unternehmen  Active Directory als IMS benutzen, werden die im Folgenden  dargestellte Bilder und Architekturen dies ebenfalls tun.  Die vorgeschlagene Architektur ist jedoch derartig flexibel und technologieunabhängig, dass man das Active Directory auf den Bildern problemlos gegen LDAP austauschen könnte. Vielmehr ist die Integration eines Hadoop Clusters mit LDAP einfacher, da beide Technologien nativ zu Linux sind.

Schritt Eins – Integration von Hadoop mit Active Directory

Der erste Schritt, um Hadoop in dasActive Directory zu integrieren, ist ein sogenannter One-Way Trust von der Linux Welt hin zur Windows Welt . Dabei ist das Vertrauen des Authentisierungsmechanismuses von Hadoop zum Active Directory gemeint. Alle Identity Management Systeme bieten diese Funktionalität an, um sich gegenseitig vertrauen zu können und User aus anderen Domänen (Realms) zu akzeptieren. Das ermöglicht z.B. globalen Firmen mit vielen Standorten und unterschiedlichen IT Infrastrukturen und Identity Management Systemen diese zu verwalten und miteinander kommunizieren zu lassen.

Das Key Distribution Center (KDC) von Kerberos ist das Herz des Kerberos Systems im Hadoop. Hier  werden die User und ihre Passwörter oder Keytabs geschützt und verwaltet. Dabei brauchen wir lediglich den One Way Trust von KDC zu Active Directory. Allerdings gibt es eine vielversprechendere Technologie, die FreeIPA. Diese hat laut Wikipedia das Ziel, ein einfach zu verwaltendes Identity,-Policy-and-Audit-System (IPA) zur Verfügung zu stellen. Seit der Version 3.0.0 kann sich FreeIPA in das Active Directory integrieren. Die aussagekräftigen Vorteile von FreeIPA sind folgende:

  1. Reibungslose Integration mit Active Directory
  2. Es wird zusammen mit der Technologie SSSD geliefert, die das temporäre Speichern von Rechten und Passwörtern erlaubt. Das erlaubt auch offline den Zugriff auf  Fähigkeiten und Unabhängigkeit vom zentralen IPA, dem unterliegenden System.
  3. Integrierte Kerberos und Single Sign On (SSO) Funktionalitäten.

Wir lassen dann FreeIPA die Verwaltung von Kerberos und die primäre Authentisierung unseres Clusters übernehmen. Sowohl das Active Directory, als auch FreeIPA erlauben eine kinderleichte Umsetzung des One Way Trusts mithilfe von Web Tools. Im Prinzip muss man beim One Way Trust lediglich die öffentlichen Zertifikate jedes Tools mit denen der anderen bekannt machen.

Schritt Zwei – Synchronisation der Rechte & Rollen von Active Directory

Jetzt sind alle User, die sich im Active Directory befinden, unserem Hadoop Cluster bekannt. Ein User kann sich mithilfe des kinit Kommandos und nach Eingabe seines Usernames und Passwortes einloggen. Aber man braucht auch die im Active Directory definierten Rollen und Gruppen, um eine Autorisierung mithilfe von Ranger oder Sentry zu ermöglichen. Ohne die Provisionierung der Rollen haben wir bei der Autorisierung ein ähnliches Problem, wie es bei der Authentisierung aufgetreten ist.  Man müsste die Rollen selber verwalten, was nicht ideal ist.

Zum Glück gibt es verschiedene Ansätze um eine regelforme Synchronisierung der Gruppen von Active Directory in Ranger oder Sentry zu implementieren. Ranger kommt mit einem LDAP Plugin namens uxugsync, das sowohl mit LDAP als auch mit dem Active Directory kommunizieren kann. Leider hat die aktuelle Version dieses Plugins einige Nachteile:

  1. Leistungsprobleme, weil es defaultsmäßig versucht, den ganzen Hierarchiebaum von Active Directory zu synchronisieren. Das kann zu einem großen Problem für große Firmen werden, die mehrere tausend User haben. Außerdem müssen nicht alle User Zugriff auf Hadoop haben.
  2. Man kann bestimmte User syncen lassen, indem man ihren Gruppename im Gruppenfeld vom Plugin einträgt. Nachteil dabei ist, dass diese Abfrage nicht rekursiv funktioniert und alle Gruppe die im Ranger sein sollen einzeln abgefragt werden müssen, Das wiederum skaliert nicht sonderlich gut.
  3. Massive und regelmäßige Abfragen des Plugins können sogar zu einem DDoS Angriff auf den zentralen Active Directory führen.

Eine bessere Lösung wäre es, wenn wir die schönen Features des SSSD Deamons (der wie oben beschrieben zusammen mit FreeIPA kommt) ausnutzen könnten. Mithilfe von SSSD werden alle User und ihre entsprechenden Gruppen dem unterliegenden Linux Betriebssystem bekannt gemacht. Das bedeutet, dass man ein einfaches Script schreiben könnte, das die User und ihre Gruppen vom System direkt abfragt und zu Ranger oder Sentry über ihre entsprechende REST APIs überträgt. Dabei schont man sowohl das Active Directory vor regelmäßigen und aufwändigen Abfragen und schafft sogar ein schnelleres Mapping der Rollen zwischen Hadoop und Betriebssystem, auch wenn Active Directory nicht erreichbar ist. Es gibt derzeit Pläne, ein solches Plugin in den nächsten Versionen von Ranger mitzuliefern.

Schritt Drei – Anlegen und Verwaltung von technischen Usern

Unser System hat jedoch neben personalisierten Usern, die echten Personen in einem Unternehmen entsprechen, auch  technische User. Die technischen Users (Nicht Personalisierte Accounts – NPA), sind die Linux User mit denen die Hadoop Dienste gestartet werden. Dabei hat HDFS, Ambari usw. jeweils seinen eigenen User mit demselben Namen. Rein theoretisch könnten diese User auch im Active Directory einen Platz finden.

Meiner Meinung nach gehören diese User aber nicht dorthin. Erstens, weil sie keine echten User sind und zweitens, weil die Verwaltung solcher User nach Upgrades oder Neuinstallation des Clusters schwierig sein kann. Außerdem müssen solche User nicht den gleichen Sicherheitspolicies unterliegen, wie die normalen User. Am besten sollten sie kein Passwort besetzen, sondern lediglich ein Kerberos Keytab, das sich nach jedem Upgrade oder Neuinstallierung des Clusters neu generiert und in FreeIPA angelegt ist. Deswegen neige ich eher dazu, die NPAs in IPA anzulegen und zu verwalten.

High Level Architektur

Das folgende Bild fasst die Architektur zusammen. Hadoop Dienste, die üblicherweise in einer explorativen Umgebung benutzt werden, wie Hive und HBase, werden mit dargestellt. Es ist wichtig zu beachten, dass jegliche Technologie, die ein Ausführungsengine für YARN anbietet, wie Spark oder Storm, von dieser Architektur ebenfalls profitiert. Da solche Technologien nicht direkt mit den unterliegenden Daten interagieren, sondern diese immer über YARN und die entsprechenden Datanodes erhalten, benötigen sie auch keine besondere Darstellung oder Behandlung. Der Datenzugriff aus diesen 3rd Party Technologien respektiert die im Ranger definierten ACLs und Rollen des jeweiligen Users, der sie angestoßen hat.


Architektur in einer Mehrclusterumgebung

Wir haben schon das Argument untermauert, warum  unsere technischen User direkt im IPA liegen sollten. Das kann jedoch insofern Probleme verursachen, wenn man mit mehreren Clustern arbeitet, die alle die gleichen Namen für ihre technischen User haben. Man merkt sofort, dass es sich hier um eine Namenskollision handelt. Es gibt zwei Lösungsansätze hierfür:

  1. Man fügt den Namen Präfixen, die als kurze Beschreibungen der jeweiligen Umgebung dienen, wie z.B. ada, proj1, proj2 hinzu. Dadurch haben die User unterschiedliche Namen, wie proj1_hdfs für die proj1 Umgebung und ada_hdfs für die ada Umgebung. Man kann diese Lösung auch bei Kerberos KDCs benutzen, die in jeder Umgebung dediziert sind und die technischen User der jeweiligen Umgebung beibehalten.
  2. Man benutzt einen separaten Realm für jede Umgebung und damit auch eine separate IPA Instanz. Hier gibt es wiederum zwei verschiedene Ansätze. Ich muss jedoch zugeben, dass ich die Zweite nie ausprobiert habe und daher für ihre Durchführbarkeit nicht garantieren kann:
    1. Man bindet jede Umgebung einzeln über ihre FreeIPA per One Way Trust an das zentrale Active Directory. Das hat natürlich den Nachteil einer uneinheitlichen User Management Infrastruktur für alle Umgebungen, da Jede ihre eigene IPA Infrastruktur verwaltet und wartet.
    2. Man baut einen Hierarchiebaum von unterschiedlichen IPA Instanzen, so wie man es bei Forests von Active Directory Instanzen macht.

Das folgende Bild stellt den letzten Ansatz dar. Im Prinzip haben wir hier einen hierarchischen IPA Cluster mit mehreren One Way Trusts von den lokalen IPA Instanzen zu der zentralen IPA.



Wie Sie vielleicht von der gesamten Diskussion her abgeleitet haben, ist die Umsetzung einer unternehmerisch-konformen und personenbasierten Sicherheitsarchitektur innerhalb von Hadoop  keine einfache Sache. Man muss mit unterschiedlichen Architekturen und Ansätzen spielen, bevor man einen relativ vernünftigen oder sogar idealen Zustand erreicht hat. Die Berücksichtigung der jeweiligen IT Architektur spielt dabei eine sehr große Rolle. Ich hoffe, ich konnte die wichtigsten Merkmalen einer solchen Architektur und die Punkte, die ein Architekt besonders beachten muss, klar darstellen.

Als Zusammenfassung habe ich Ihnen am Ende eine Art Shoppingliste aller Komponenten zusammengestellt, die wichtig für den personalisierten Zugriff im Hadoop sind:

  1. Kerberos – Authentisierung
  2. FreeIPA – Authentisierung, Integration mit Active Directory
  3. Active Directory oder LDAP
  4. Ranger oder Sentry
    1. Plugin für Rollen/Gruppen Mapping zwischen AD und dem Betriebssystem
  5. Optional SSSD für schnellere Abfrage der Gruppen und Rollen des Betriebssystems

Zurück zu Teil 2 von 3 – Sicherheitstechnologie in Hadoop

Data Leader Guide – Call for Papers

Connected Industry e. V., der Verband für Digitalisierung und Vernetzung, sammelt wegweisende Anwendungsfälle rund um Digitalisierung und Data Science und fasst diese in einem Leitfaden zusammen, dem Data Leader Guide 2016.


Welche Inhalte kommen in den Data Leader Guide?

Der Data Leader Guide konzentriert sich auf Anwendungsfälle aus dem deutschsprachigen Wirtschaftsraum D/A/CH. In diesem Data Leader Guide werden vornehmlich die praktisch umgesetzten Use Cases / Business Cases von Anwender-Unternehmen aus den Branchen Industrie/Produktion, Dienstleistungen, Finanzen und Handel praxisorientiert beschrieben.

Was ist das Ziel des Data Leader Guide?

Anhand greifbarer Erfahrungswerte soll Entscheidern, Entwicklern und sonstigen Interessenten eine Orientierung und der Zugang zu dieser komplexen Materie erleichtert werden. Von besonderem Nutzen ist dabei der branchenübergreifende Blickwinkel des Leitfadens, da der Wissenstransfer von anderen Industrien gerade bei Big Data nicht hoch genug eingeschätzt werden kann.

Wann wird der Data Leader Guide 2016 erscheinen?

Pünktlich zum Data Leader Day am 17. November 2016. Die Ausgaben werden als Druckversion sowie als digitale Version erscheinen.

Warum sollte Ihre Anwendungsfall bzw. Projekt nicht fehlen?

Ihr Projekt wird zum Aushängeschild für die Innovationskraft und des Fortschritts Ihres Unternehmens. Darüber hinaus unterstreicht es die Attraktivität Ihres Unternehmens für qualifizierten Nachwuchs aus dem IT- und ingenieurswissenschaftlichen Bereich. Schließlich ist die Aufnahme Ihres Anwendungsfalles in den Data Leader Guide eine der seltenen Möglichkeiten, diesen auch öffentlich zu präsentieren und somit die Leistung des gesamten Projekt-Teams zu würdigen.

Call for Papers

So bringen Sie Ihren Anwendungsfall in den Data Leader Guide:

Sie sind Geschäftsführer, CIO oder ein Mitarbeiter mit Verantwortung für ein Projekt mit starkem Bezug zur Digitalisierung, Big Data, Data Science oder Industrie 4.0? Dann sollten Sie Ihr Projekt für einen Eintrag in den Data Leader Guide von Connected Industry bewerben. Genauere Informationen, wie Sie Ihren Anwendungsfall (Use Case / Business Case) in den Data Leader Guide 2016 bringen, finden Sie über diesen Direktlink zum Connected Industry e.V.

Eine Hadoop Architektur mit Enterprise Sicherheitsniveau

Dies ist Teil 2 von 3 der Artikelserie zum Thema Eine Hadoop-Architektur mit Enterprise Sicherheitsniveau.

Der aktuelle Stand der Technologie

Zum Glück ist Hadoop heutzutage ein bisschen reifer, als es noch vor zehn Jahren war. Es gibt viele Tools, einige davon OpenSource und einige lizenziert, die den Sicherheitsmangel im Hadoop zu lösen versuchen. Die Tabelle unten zeigt eine Auswahl der am meisten genutzten Sicherheitstools. Da jedes Tool von einer anderen Hadoop Distribution bevorzugt wird, habe ich diese Parameter mit berücksichtigt.

Es ist zu beachten, dass die zwei populärsten Hadoop Distributions (Hortonworks und Cloudera) kaum Unterschiede aufweisen, wenn man sie auf funktionaler Ebene vergleicht. Der größte Unterschied  besteht darin, dass Hortonworks ein Open Source und Cloudera ein kommerzielles Produkt ist. Abgesehen davon hat jeder Vendor den einen oder anderen Vorteil, ein ausführlicher Vergleich würde jedoch den Rahmen dieses Artikels sprengen.


Hadoop kommt von der Stange ohne aktivierte Authentisierung. Die Hadoop Dienste vertrauen jedem User, egal als was er oder sie sich ausgibt. Das sieht  folgendermaßen aus:

Angenommen Mike arbeitet an einer Maschine, die ihm Zugriff auf den Hadoop Cluster erlaubt und Sudo-Rechte gibt. Aber Mike hat das Passwort für den hdfs Superuser nicht. Er kann sich jetzt einfach als der hdfs User ausgeben, indem er die folgenden Kommandos ausführt. Dabei bekommt er fatalerweise alle Rechten des hdfs Superusers und ist in der Lage das gesamte HDFS Filesystem zu löschen. Es würde sogar bereits der Environment variabel USER ausreichen, um einen anderen User umzuwandeln.


Kerberos ist im Moment der einzige Weg um Authentisierung im Hadoop zu gewährleisten. Kein Weg führt daran vorbei, es sei denn, man ist verrückt genug, um ein hochkompliziertes System auf Linux basierter ACLs auf jeder Maschine zu installieren und zu verwalten, um User daran zu hindern sich falsch zu authentifizieren. Es ist zudem wichtig zu beachten, dass Kerberos als einziges Sicherheitsmerkmal zur Authentifizierung dient, aber ohne richtige Authentisierung gibt es auch keine richtige Autorisierung. Wenn User jetzt selbst in der Lage sind, sich beliebig als jemand anderes auszugeben, können sie so selbst zu den sensibelsten Daten unbefugten Zugriff erlangen.

Apache Ranger oder Sentry erlauben die Definition und Verwaltung von Access Control Lists (ACLs). Diese Listen legen fest, welche User Zugriff auf welchen Bereich des HDFS Filesystems haben Der gleiche Effekt kann auch ohne diese Tools, durch einfache  Hadoop ACLs erreicht werden, die den normalen Linux ACLs ähneln. Es empfiehlt sich jedoch die neuesten Tools zu benutzen, wegen a) ihrer Benutzerfreundlichkeit, b) ihrer ausgearbeiteten APIs, die einem Administrator erlauben die Listen ohne GUI zu verwalten und beim Programmieren sogar zu automatisieren, und c) wegen ihrer Auditingfähigkeiten, die das Nachverfolgen von Zugriffen und Aktionen ermöglichen.

Anbei ist das Bild einer Ranger Policy, die der Gruppe der User rekursiv Lese- und Ausführungsrechte auf das Verzeichnis /projects/autonomous_driving gibt.

Alle einzelne Stücke des Puzzles kommen zusammen

Nachdem wir ermittelt haben, welche Technologien es gibt, die uns zu einem sicheren Cluster verhelfen, müssen diese im nächsten Schritt zusammengesetzt werden. Zum Glück hat jeder Vendor seine eigene Technologie, um Tools aus dem  Hadoop Ecosystem zu integrieren und zu verwalten. Cloudera beispielsweise bietet den sehr wirksamen Cloudera Manager und Hortonworks das Apache Ambari an. Die beiden Tools kümmern sich um das Anlegung der technischen Hadoop User (hdfs, hadoop, hive, ranger, e.t.c.) und der entsprechenden Kerberos Keytabs, die den technischen Usern erlauben, sich gegenüber Hadoop zu authentisieren. Am Ende der Installation hat man sämtliche Konfigurationen zentral platziert und kann neue personalisierte Accounts anlegen. Man kann sich dann im Ranger oder Sentry Web UI anmelden und ACLs für die User und Gruppen definieren.

Das ist allerdings nicht der Idealzustand. Jedes Unternehmen verwaltet ihre User bereits in bestimmten Verwaltungssystemen, die sich innerhalb der IT Infrastruktur befinden. Diese Systeme (oder auch Identity Management Systems) sind ein wichtiges vertikales, abteilungsübergreifendes Element der unternehmerischen IT Architektur. Jedes EDS Tool im Unternehmen ist an ein Identity Management System, wie Active Directory oder LDAP, gekoppelt und muss damit die User nicht selbst verwalten.

Der Stellenwert solcher Tools wird sofort erkennbar, wenn man die strengen Sicherheitsregeln eines modernen Unternehmens betrachtet: Passwörter müssen bestimmte Kriterien erfüllen und alle 30 Tagen gewechselt werden. Außerdem darf niemand eins seiner letzten zehn Passwörter benutzen.

Eine IT Architektur, die die Implementierung solcher unternehmensbreiten  Anforderungen in jeder einzelne Applikation fördert ist der Alptraum jedes Applikationsentwicklers und zeigt das Versagen des IT-Architekten.

Aber lassen Sie uns zurück zu unserem Hauptthema kommen. Wie können wir ein System wie Active Directory oder LDAP in Hadoop integrieren?  Der nächste Abschnitt gibt die Antwort auf diese Frage.

Weiter zu  Teil 3 von 3 – Eine Einterprise Hadoop Architektur für beste Sicherheit

Zurück zu Teil 1 von 3 – Motivation und Anforderungen einer Data Science Plattform

Eine Hadoop Architektur mit Enterprise Sicherheitsniveau

Die Motivation für eine unternehmenskonforme Sicherheitsarchitektur für Hadoop

Hadoop und die damit einhergehenden Technologien und Applikationen (Hadoop Ecosystem) stellen keine neue Idee mehr dar. Zugegebenermaßen hat man jedoch das Gefühl, dass Hadoop noch lange nicht reif genug für dessen Integration an die IT Infrastruktur und an die Prozesse eines Unternehmens ist. Bei fast jeder Hadoop Distribution mangelt es an bestimmten nicht-funktionalen Aspekten. Die Hadoop Community hat sich sehr lange um die Erfüllung der funktionalen Anforderungen gekümmert und dabei Aspekte wie Sicherheit, Monitoring, Data Governance und Auditing vernachlässigt.

Eine berechtigte Frage wäre nun: Warum ist das so?

Zum besseren Verständnis der Leser werde ich zunächst auf diese Frage und die Geschichte von Hadoop eingehen, bevor ich mich mit dem Aufbau einer sicheren Hadoop Infrastruktur beschäftige.
Hadoop hat eine, für IT Verhältnisse, relativ lange Geschichte hinter sich. Das erste Release fand im Februar 2006 statt, wobei Yahoo bereits von Beginn an Interesse an der Mitwirkung und Benutzung bekundete. Am Anfang waren alle Applikationen, die für Hadoop geschrieben wurden, Backend Data-Crunching Jobs. Diese führten eine Art von Datenanalyse, basierend auf großen Datenmengen,  durch, die sonst, ohne die Verwendung der von Hadoops verteilter Architektur und Prozessframework, viel länger gedauert hätte. Dabei haben die Entwickler mithilfe der MapReduce Ausführungsengine Aggregierungen und  anderen SQL-ähnliche Abfragen von Datenbeständen geschrieben. Sämtliche Applikationen waren von ihrer Natur her Batchjobs, die regelmäßig auf dem Cluster angestoßen wurden, um Resultate zu berechnen und diese weiter an standardisierte Visualisierungstools zu leiten. Normale User brauchten daher keinen direkten Zugriff auf den Cluster selbst, sondern nur auf die Tools, die die Resultate der Hadoop Jobs sammelten. Das hat die Arbeit der ITler stark vereinfacht, da sie  den Hadoop Cluster, der viele sensible Daten über ihr Unternehmen beherbergt , komplett von der restlichen IT Infrastruktur abtrennen und durch Firewalls sichern konnten. Die Kommunikationskanäle zwischen Hadoop und anderen Tools waren dabei auf das absolut Notwendigste –   sprich Daten rein, Resultate raus –  begrenzt. Durch diese Limitierung fiel das zeitaufwendige Installieren und Verwalten von Usern und das Schreiben von Autorisierungspolicies weg.
Mit dem Zuwachs der Datenmenge in modernen Unternehmen und der wachsenden Popularität des Hadoop Ecosystems kamen weitere Use Cases und mehrere Tools hinzu. Hadoop2 hat in diesem Zuge eine komplett neue Architektur veröffentlicht, in der man nicht mehr vom MapReduce abhängig ist. Andere Ausführungsengines sind aufgetaucht, die auf bestimmte Use Cases abzielen und sich in diesen Fällen durch bessere Leistung als das MapReduce Framework auszeichnen. Mehr und mehr Business- und Daten-Analysten wurden daraufhin auf Hadoop aufmerksam und wollten die Technik für sich nutzen.. Insbesondere Banken und Finanzdienstleister erkannten das gewaltige Potenzial dieser Technologie und wollten sie nutzen, um ihre Kunden besser zu verstehen.
Das war der Moment, in dem Unternehmen weltweit den Druck empfanden, eine ernste Sicherheitsarchitektur für Hadoop zu entwickeln. Dabei stießen ihre Ingenieure jedoch auf erste Probleme:
Wie gewährleistet man nutzerbasierten Zugriff auf Tools, die sich normalerweise innerhalb eines Hadoop Clusters befinden? Und noch wichtiger: Wie beschützt man sensible Daten vor unbefugtem Zugriff? Welcher Nutzer darf auf welche Daten zugreifen?
All diese Fragen, die sich mit dem Thema „Personalisierter Zugriff“  befassten, brauchten umgehend eine Antwort.

Die Sicherheitsanforderungen einer Data Science Plattform

Den Bedarf an höheren Sicherheitsvorkehrungen haben insbesondere die Hadoop Plattformen, die ihren Usern interaktive und adhoc Jobs/Abfragen ermöglichen möchten. Solche Plattformen sind in der BigData Welt als interaktive oder explorative (abgeleitet vom englischen Wort Exploration) Umgebungen bekannt. Ihr Hauptziel ist es, eine BigData Umgebung anzubieten, die den Usern erlaubt, neue Techniken und maschinelles Lernen auf Datensätze anzuwenden, um versteckte Muster zu erkennen.

Hier sind einige der wichtigsten Ziele, die ein sicheres Hadoop Umfeld erfüllen muss:

  1. Jeder User muss in der Lage sein, selber Abfragen oder Machine Learning Algorithmen auf große Datenmengen anzustoßen.
  2. User müssen sogar in der Lage sein, selber Daten einzufügen und zwar in einer kontrollierten Art und Weise.
  3. Resultate müssen direkt auf dem Cluster abrufbar sein, damit die neuesten BigData Visualisierungstechnologien genutzt werden können
  4. Unbefugter Zugriff auf Datensätze einer dritten Abteilung durcheinzelne Personen oder Gruppen muss verhindert werden.
  5. Jeder Datenzugriff muss kontrolliert und auditiert werden können.

Dieser Artikel ist der Start der drei-teiligen Serie zum Thema Sicherheit auf Enterprise-Niveau für Hadoop. 

Weiter zu Teil 2 von 3 – Sicherheitstechnologie in Hadoop