Data Lake und Datenschutz: Eine schwierige Beziehung

Focus von Hadoop-basierten Systemen

Nachdem der Focus von Hadoop-basierten Big Data Systemen in der Vergangenheit im Wesentlichen auf dem Managen und Bereitstellen von Daten für Analysen und operative Zwecke gelegen hat, ohne große Anforderungen in Sachen Datensicherheit und Governance realisieren zu müssen, ändert sich dieses Bild stark in letzter Zeit. Mit dem Bekanntwerden der europäischen Datenschutz Grundverordnung https://dsgvo-gesetz.de/, welche zusammen mit einer Erneuerung des Bundesdatenschutzgesetzes ab Ende Mai 2018 zwingend angewendet werden muss und einen grundlegenden Paradigmenwechsel darstellt, wurde vielen Organisationen und Unternehmen deutlich, dass bisher eingeschlagene Wege und ein gewisser „sorgloser“ Umgang mit Daten in der Datenverarbeitung in Zukunft nicht mehr gangbar sind. Die europäische Datenschutzgrundverordnung soll jedem ein Recht einräumen, über seine Daten grundsätzlich selbst zu bestimmen. In diesem Zusammenhang sind auch traditionell so verstandene vom Kunden selbst eingeräumte Rechte an seinen Daten mit Hilfe von pauschalen Formulierungen nicht mehr tragbar. Die Rechte müssen stattdessen zukünftig sehr feingranular behandelt werden. Was heißt das? Technisch bedeutet das, dass auf Kundenanforderung  die von ihm gesammelten Daten zugänglich gemacht und von diesem beanstandete Daten schnell aus den Systemen gelöscht werden müssen, siehe dazu auch https://www.datenschutzbeauftragter-info.de/eu-datenschutzgrundverordnung-das-sind-die-neuerungen/. Besonders heikel sind die bei Verstößen gegen die Verordnung möglicherweise zu zahlenden Bußgelder. Diese können bis zu 4 Prozent der Jahresumsätze eines Unternehmens betragen! Klar, dass hier Handlungsbedarf besteht.

Personenbezogene Daten sind schwierige Daten…

Zu personenbezogenen Daten und dem gewünschten (geforderten!) Umgang mit diesen kann man dazu in Datenschutz-Handbüchern in etwa folgendes lesen:

Personenbezogene Daten sollen jederzeit gelöscht werden können, soweit nicht gesetzliche oder vertragliche Aufbewahrungspflichten entgegenstehen. Dasselbe gilt, wenn Grund zu der Annahme besteht, dass durch eine Löschung schutzwürdige Interessen des Betroffenen beeinträchtigt würden. In diesen Fällen wird typischerweise gefordert, dass an die Stelle einer Löschung eine Sperrung tritt.

Diese Daten sind also in den folgenden Fällen zu löschen:

  • Ihre Speicherung ist per se unzulässig
  • Es handelt sich um „schwierige“ Daten über die rassische oder ethnische Herkunft, politische, religiöse oder philosophische Meinungen und Überzeugungen, sexuelle Vorlieben, Vorstrafen und ähnliche Dinge, wobei ihre Richtigkeit von der verantwortlichen Stelle nicht bewiesen werden kann. Aber: Der Beweis ist zu erbringen, sobald der Betroffene die Richtigkeit bestreitet.
  • Wenn sie für eigene Zwecke verarbeitet werden, sobald ihre Kenntnis für die Erfüllung des Zweckes der Speicherung nicht mehr erforderlich ist. Das trifft in der Regel für dispositive Systeme wie Data Lakes, Data Warehouses und Artverwandte zu.

Recht auf Vergessenwerden

Das sogenannte „Recht auf Vergessenwerden“ soll sicherstellen, dass digitale Informationen mit einem Personenbezug nicht dauerhaft zur Verfügung stehen. In der am 24. Mai 2016 in Kraft getretenen und ab dem 25. Mai 2018 in allen EU-Mitgliedstaaten unmittelbar geltenden Datenschutz-Grundverordnung wird das Recht auf Löschung in Art. 17 geregelt. Näheres dazu kann man in der deutschen Version des Artikels 17 der DSGVO nachlesen. Kurz zusammengefasst hat eine betroffene Person hat das Recht, zu verlangen, dass sie betreffende personenbezogene Daten unverzüglich gelöscht werde, wenn

  • die personenbezogenen Daten für die Zwecke, für die sie erhoben oder auf sonstige Weise verarbeitet wurden, nicht mehr notwendig sind
  • die betroffene Person ihre Einwilligung, auf die sich die Verarbeitung stützte, widerruft, und es sonst an einer anderweitigen Rechtsgrundlage für die Verarbeitung fehlt. Solche können zum Beispiel gesetzliche Aufbewahrungspflichten sein oder aber das Einfrieren der Daten zur Beweissicherung („Legal Hold“).

Was ist also zu tun? Prinzipiell muss ich beim Aufbau von Data Lakes (und natürlich auch von anderen Systemen) die Forderungen „Data protection by design“ und „Data protection by default“ beachten, sonst laufe ich in eine gefährliche Sackgasse. Sackgasse kann im Extremfall bedeuten, dass ich die ganze „illegale“ Datenhaltung forensisch löschen muss – ein Albtraum für alle Beteiligten. Damit das nicht passiert, ist von Anfang an sauber zu trennen zwischen Daten, die personenbeziehbar sind und klar vorliegen müssen und solche, die lediglich anonymisiert, eventuell auch pseudonymisiert gespeichert werden können. Diese „Datentöpfe“ müssen in der Regel mindestens logisch voneinander separiert gespeichert und geschützt werden – Stichwort logische „Sandboxes“. Hierzu ist ein Mandantenkonzept zu entwickeln und im Data Lake auch konsequent umzusetzen.

Klardaten…

Zu den klar vorliegenden Daten, aber auch bei anderweitig problematischen Daten, ist immer eine Prüfung  der vom Kunden gegebenen Einverständnisse zu diesen Daten vorzunehmen. Diese müssen auch ohne größeren Zeitverzug bei Entzug dieser gelöscht werden können. Das impliziert natürlich, dass man in geeigneter Weise jeden (!) Datensatz mit den dazu gegebenen Permissions verknüpfen können muss. Üblicherweise wird von Datenschutzseite auch eine maximale Aufbewahrungsdauer gefordert, falls der Data Lake in einem solchen Fall nur als bereitstellendes System dient. Ein Ausweg aus diesem Dilemma bietet der Ansatz, nicht  einen zentralen Data Lake zu bauen, sondern im Rahmen eines „Sandboxing“ auch physikalisch getrennte Umgebungen für verschiedene klar definierte Anwendungszwecke aufzubauen.

Das Bereitstellen der aktuellen Kunden-Permissions erfordert in der Regel ein separates System. Dies muss in der Regel in Lage sein, in nahezu Echtzeit die Permissions aktualisieren zu können. Üblicherweise stellt ein solches System über einen Service die Informationen zu den Berechtigungen bereit. Vorteil der Entkoppelung ist, dass man im Data Lake nicht mit Aufgabe konfrontiert ist, das operative Handling rund um die Kunden-Permissions zu implementieren – es recht in der Regel der Aufruf eines solchen Services bei Bedarf.

Implikationen für den Betrieb des Data Lakes

Was ist ein solcher Bedarf? Nun, im Grunde genommen alles, wo Daten, die im Data Lake gespeichert sind, verwendet werden beziehungsweise auch für den Fall, das regelmäßig Löschroutinen über den Bestand des Data Lakes laufen (müssen). Für Anwendungen, die operativen Charakter haben, sind Klardaten meist  notwendig. Die Verarbeitung ist in Regel durch den Zweckbezug gedeckt, wenn der zeitliche Rahmen auch dazu passt. Ein Beispiel: Um Verspätungen im öffentlichen Verkehr berechnen zu können und personalisierte Verspätungsmeldungen und Empfehlungen geben zu können, braucht man neben den Streckendaten, Fahrtdaten und weiteren nützlichen Informationen auch personenbezogene Daten. Diese werden für die Berechnung von Prognosen bereitgestellt und können auch verarbeitet werden, wenn dieses zeitnah erfolgt, also zeitnah zur tatsächlichen Reise oder Fahrt. Genauso können daraus abgeleitete Empfehlungen an den Kunden weitergegeben werden. Voraussetzung ist natürlich, dass der Kunde sein Einverständnis zum Empfang solcher Information gegeben hat. Die Daten selbst, sofern sie noch personenbeziehbar sind, müssen allerdings dann auch zeitnah wieder gelöscht werden.

Umgekehrt dürfen diese Informationen nicht ohne weiteres für andere analytische Zwecke verwendet werden, zumindest nicht, wenn hierbei noch ein Personenbezug herstellbar ist. Hier kommen jetzt verschiedene Möglichkeiten in Betracht, die die Situation trotzdem „retten“ können. Wichtige Stichwörter sind Pseudonymisierung und Anonymisierung und der Aufbau mindestens logisch streng getrennte Bereiche. Was dahinter steckt und wie man sich ein weiteres Vorgehen vorstellen kann? Dazu demnächst mehr.