Data Lake und Datenschutz: Anonymisierung und Pseudonymisierung

Datenschutz im Data Lake wird zu „Muss“… Wie geht man vor?

Mit der Einführung der europäischen Datenschutz-Grundverordnung (EU-DSGVO) hat sich auch das Vorgehen beim Aufbau von Data Lakes gewandelt. Datenschutzaspekte spielen eine sehr viel größere Rolle als vorher. Themen wie Anonymisierung und Pseudonymisierung von Daten und ganzen Datenbereichen sind zu einem Muss geworden und erzwingen ein sehr durchdachtes Vorgehen. Warum ist das aber gerade beim Aufbau von Data Lakes so kritisch? Sind denn Anonymisierung und Pseudonymisierung von Daten etwas Neues? Eigentlich nein, aber im Kontext von Data Lakes in gewisser Weise schon: Der ursprüngliche Focus von solchen Systemen lag in der Vergangenheit auf dem Managen von enorm vielen heterogenen Daten. Das heißt, man kümmerte sich in der Regel zunächst um das Bereitstellen dieser Daten für Analysen und operative Zwecke in unverschlüsselter Form, was auch die Umsetzung analytischer Use Cases mit diesen Daten mit eingeschlossen hat. Warum man das gemacht hat, liegt eigentlich auch auf der Hand: Man spart sich Komplexität und kann mit Klardaten auch sehr viel einfacher umgehen, da sich Analysen und analytische Anwendungen sehr einfach mit ihnen realisieren realisieren lassen. In solchen Systemen hat man in der Regel keine große Anforderungen in Sachen Datensicherheit und Governance realisieren zu müssen geschweige denn realisiert, da Ziel und Zweck eines Data Lakes von anderen Faktoren bestimmt wurde. Dieses Bild ändert sich allerdings sehr stark in letzter Zeit.

Eine daraus folgende Anforderung, mit dem man also sehr viel stärker als früher konfrontiert ist, ist die Forderung nach Pseudonymisierung und, noch stärker, Anonymisierung der Daten oder zumindest von Datenbereichen im Data Lake. Daten, die keinen direkten zeitlichen und operativen Zweckbezug mehr haben, können nicht einfach mehr klar abgelegt werden. Es reicht auch nicht, einfach die Datenträger zu verschlüsseln. Die Daten selbst müssen in einem solchen Fall in der Regel anonymisiert oder mindestens pseudonymisiert werden. Was verbirgt sich aber hinter diesen Begriffen?

Anonymisierung, Pseudonymisierung und Analytik

Kurz gesagt bedeutet Pseudonymisierung, dass ich die Daten bei Bedarf noch auf einen Ursprung (Person, Kunde, Mitarbeiter,…) zurückführen kann, zumindest theoretisch. Bei der Anonymisierung ist das nicht mehr möglich. Eine gute Gegenüberstellung findet sich hier: Anonymisisierung und Pseudonymisierung

Für die Durchführbarkeit von Analysen ist natürlich wichtig, dass bei diesen Vorgehensweisen nicht die Beziehungen in den Daten verlorengehen. Das bedeutet, dass eine Person in einem für mich wichtigen Datenauswertungskontext immer das gleiche Pseudonym bekommt. Ist dieses nicht mehr auf die Person rückführbar – was allerdings in der Regel sehr schwer nachweisbar ist – ist die Person sogar anonymisiert. Es wird typischerweise auch gefordert, dass der Schlüssel

  • nach einem bekannten sicheren Verfahren erzeugt wird
  • nur in eine Richtung funktioniert, das kann man organisatorisch „sicherstellen“, indem der Schlüssel „weggeworfen“ oder sicher verwahrt wird
  • der Schlüssel nicht im Data Lake selbst abgelegt werden darf, sondern eine sichere Stelle außerhalb benutzt wird

Aber die Schwachstelle des Ganzen ist oben schon angedeutet: Ein Nachweis zu führen, dass solchermaßen anonymisierte Daten tatsächlich anonym sind in dem Sinn, dass unter keinen Umständen über sie ein Personenbezug hergestellt werden kann, kann sich als unmöglich oder doch sehr schwierig herausstellen. Es gibt nämlich bekannte Situationen, in denen aus den Daten selbst ohne höheren Aufwand doch ein Personenbezug hergestellt werden kann. Ein typisches Beispiel sind Mitarbeiterdaten, die aufgrund ihres Arbeitsplatzes und ihrer Einordnung in die Organisationshierarchie des Unternehmen leicht identifizierbar sind. Oder Kundendaten, die alleine aufgrund der Tatsache, dass Adressgebiete nicht hinreichend groß gewählt wurden, auf einzelne Personen rückführbar sind – zumindest indirekt und unter Umständen unter Zuhilfenahme von „hinreichend schlauen“ Verfahren. Im ersten Fall der Mitarbeiterdaten ist das sogar besonders kritisch, da hier nicht nur die Interessen des Datenschutzes selbst, sondern auch des Betriebsrats und eventuell vorhandener Betriebsvereinbarungen berücksichtigt werden müssen. Ich glaube, diese Beispiele zeigen sehr gut, in welche Fallen man hier geraten kann.

Und was ist mit Klardaten?

Klardaten dürfen nur dann im Data Lake gespeichert und verwendet werden, wenn eine Erlaubnis dazu vorliegt. Es ist also bei der Verarbeitung und Speicherung solcher Daten immer auch eine Prüfung  der „Permissions“ zu diesen Daten vorzunehmen. Die Daten müssen auch unverzüglich  bei berechtigtem Entzug der „Permissions“ gelöscht werden können. Ein solcher Widerruf oder genereller Einspruch gegen die Datenspeicherung kann beispielsweise durch einen Kundenauftrag veranlasst sein. Jetzt ist aber allein die Aufgabe, diese „Permissions“ in korrekter Weise zu verwalten eine keinesfalls triviale Aufgabe, mit der die zum Management eines Data Lakes Berechtigten in der Regel ein Problem haben. Eine mögliche Abhilfe kann hier sein, dass zwar die grundlegenden Infrastruktur zum Speichern dieser Daten seitens des Data Lakes bereitgestellt und verwaltet wird (das „System an sich“), die Benutzung von solchermaßen kritischen Bereichen aber in die Hand dafür speziell Berechtigter gelegt wird. Diese müssen dann auch zwingend die Berechtigung nachweisen – denn die Verantwortung für diese Daten liegt jetzt komplett in deren Hand! Ein Zugriff von dem normalen (und in der Regel anonymisierten) Data Lake in diese Daten ist nicht möglich und wird normalerweise technisch unterbunden. Die Datenhaltung inklusive dem Laden und Verarbeiten der Daten und das Löschen wird von den dazu Berechtigten ausgeführt und hat mit der eigentlichen Betriebsführung des Data Lakes dann „nichts zu tun“. Das erfordert natürlich ein ausgeklügeltes Sicherheits- und Mandantenkonzept. Hierauf werde ich demnächst ein Licht werfen.

 

 

 

 

 

 

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.