DSGVO und Data Warehouse – unvereinbar?

Ein Data Warehouse (DWH) hat den Anspruch, die Historie aller Unternehmensdaten vollständig abzubilden. Da sich nie voraussehen lässt, welche Daten in Zukunft für Auswertungen interessant werden könnten, speichert das Kern-DWH in der Regel die Daten auf der detailliertest-möglichen Ebene. Löschungen von Daten, also eine Verfälschung der Historie, sind in den einschlägigen Methoden zur DWH-Modellierung nicht vorgesehen. Wie passt dies zum „Recht auf Vergessenwerden“, wie es insbesondere die neue EU-Datenschutzgrundverordnung (DSGVO) fordert?

Über diese Frage habe ich mir Gedanken gemacht und diese ursprünglich in einem Artikel in der Zeitschrift „BI-Spektrum“ (Ausgabe 05/2018) veröffentlicht. Mein – noch nicht durch juristische Expertise gestütztes – Fazit lautet, dass den bisherigen öffentlichen Diskussionen zufolge eine vollständige Anonymisierung aller personenbezogenen Daten im Data Warehouse dem „Recht auf Vergessenwerden“ genüge tun würde. Es muss also nichts gelöscht werden! Dennoch sind auch bei der Anonymisierung einige Fallstricke zu beachten.

Dieser Artikel enthält einige methodische Vorschläge, wie Daten in einem Kern-Data-Warehouse anonymisiert werden können, sodass viele wichtige Auswertungen möglich bleiben und unverfälschte Ergebnisse liefern. Die Vorschläge beziehen sich auf zwei gängige Modellierungsmethoden für das Kern-DWH:

• Sternschema-Modellierung nach Kimball [Kim13]
• Data-Vault-Modellierung nach Linstedt [Lin15]

Dabei gehen wir von folgenden Prämissen aus, deren Gültigkeit in jedem Fall mit der eigenen Rechtsabteilung geprüft werden sollte:

• Das Recht auf Vergessenwerden muss auch in einem DWH umgesetzt werden.
• Dem Recht auf Vergessenwerden ist Genüge getan, wenn die jeweiligen personenbezogenen
  Daten überall im Unternehmen vollständig anonymisiert sind (vgl. [Bir18; Gra18]).

Problemstellung

Ein Bericht, der für den August 2018 eine Zahl von 13 verkauften Waschmaschinen im Raum Hamburg ausweist, soll diese Zahl auch dann noch liefern, wenn er im März 2020 neu aus den Detaildaten abgeleitet werden muss – auch wenn in der Zwischenzeit einige der Käufer aus Hamburg weggezogen sind oder ihre Adressen aufgrund von Anonymisierung nicht mehr ermittelbar sind. Um dieser Art Anforderung zu entsprechen, nutzt beispielsweise die Sternschema-Methodik nach Kimball [Kim13] eine Faktentabelle mit unveränderlichen Fakten, aus der die Verkäufe hervorgehen.

Die Fremdschlüssel der Faktentabelle verweisen auf Dimensionstabellen, in denen die Kontextdaten zum Zeitpunkt der Entstehung des Faktums gespeichert bleiben. Zieht ein Käufer von Hamburg nach München, bleibt der Verkauf der Waschmaschine mit dem Kontext der Hamburger Adresse verbunden, die Münchener Adresse gilt erst später (vgl. Abbildungen 1 und 2).

Was geschieht nun, wenn der Kunde mit der Kundennummer KND003 auf seinem „Recht auf
Vergessenwerden“ besteht oder das Unternehmen die Löschung seiner Daten routinemäßig nach Ablauf des Verarbeitungszwecks vorsieht? (Die folgenden Überlegungen werden weiter unten auch auf die Data-Vault-Methodik übertragen.)

Erster Lösungsansatz

Eine Möglichkeit wäre, alle Einträge dieses Kunden in der Dimensionstabelle zu löschen und die zugehörigen Fremdschlüssel der Faktentabelle umzubiegen auf einen gesonderten, künstlichen Eintrag in der Dimensionstabelle, der stellvertretend für alle gelöschten Kunden steht und als Wohnort „Unbekannt“ enthält. Wird der Bericht zu den Absatzzahlen der Waschmaschinen im Jahr 2020 neu erzeugt, so weist er für August 2018 weniger als 13 Verkäufe in Hamburg aus und dafür einige in der Region „Unbekannt“.

Dieser Ansatz löst das Problem der unverfälschten Historie nicht, mag aber für Fakten, die weit
genug in der Vergangenheit liegen, sodass korrekte Auswertungen nicht mehr relevant sind, eine einfache Lösung darstellen.

Zweiter Lösungsansatz

Oft werden Summen wie die Anzahl der verkauften Waschmaschinen je Region und Monat in eigenen Data Marts oder Cubes gespeichert, wobei diese keine detaillierten Daten und damit keine personenbezogenen Daten enthalten. Berichte zeigen die Daten dieser Data Marts an, statt die Summen bei jedem Aufruf neu aus dem Kern-DWH (den Detaildaten) zu berechnen. In diesem Fall könnte für das Kern-DWH der erste Lösungsansatz verfolgt werden: Die Detaildaten dieses Kunden werden im Kern-DWH gelöscht, aber die darauf beruhenden Summen bleiben in den Data Marts unverändert, sodass die darauf aufbauenden Auswertungen weiterhin die richtigen Werte liefern.

Der Nachteil dieser Lösung liegt in der Architektur des DWH. Im Normalfall lässt sich ein Data
Mart jederzeit aus dem Kern-DWH wiederherstellen, sodass die Data Marts eine eigene Schicht
bilden, die mit weniger Aufwand gesichert werden muss als das Kern-DWH, weil deren Konsistenz mit dem Kern-DWH jederzeit gegeben bzw. herstellbar ist. Bei Löschungen im Kern-DWH geht diese Konsistenz verloren, weil der Data Mart nicht wieder mit gleichen Resultaten aus den Detaildaten abgeleitet werden kann. Die Data Marts werden damit zu „Bürgern erster Klasse“ im DWH, die dennoch widersprüchliche Ergebnisse liefern können im Vergleich zu Auswertungen, die auf dem Detail-DWH beruhen. Solche Inkonsistenzen möchten sich viele DWH-Architekten vermutlich lieber ersparen.

Dritter Lösungsansatz

Für den dritten Ansatz wird im Kern-DWH keine Löschung, sondern eine Anonymisierung durchgeführt. Dabei werden in einem ersten Schritt personenbezogene Felder (Attribute) in den Dimensionstabellen, wie etwa Name, Geburtsdatum oder genaue Adresse, durch Zufalls-, Default- oder Leerwerte überschrieben, und zwar für alle Einträge des jeweiligen fachlichen Schlüssels, auch für solche, deren Gültig-bis-Datum bereits abgelaufen ist. Zusätzlich wird das Gültig-bis-Datum des aktuellsten Eintrags auf den gestrigen Tag gesetzt, um erkennbar zu machen, dass keine aktuellen Daten vorliegen.

Weitere Schritte sind erforderlich, denn es bleiben folgende Herausforderungen:

• Fachliche Schlüssel
• Indirekte Identifizierung

Fachliche Schlüssel

Die Kundennummer KND003 könnte in externer Kommunikation verwendet worden sein, beispielsweise als Identifizierungsmerkmal gegenüber dem Kunden in Briefen oder E-Mails oder auch gegenüber Behörden. Somit könnten ggf. externe Stellen der Kundennummer KND003 die richtige natürliche Person zuordnen, selbst wenn im Unternehmen selbst aufgrund der umfassenden Anonymisierung keine Zuordnung mehr möglich ist. Daher muss die Kundennummer im DWH überall durch eine neue Nummer ersetzt werden, die aus einem getrennten Nummernkreis gezogen wird, der nur für anonymisierte Kunden verwendet wird.

Die Zuordnung der alten Kundennummer zur neuen Nummer darf nirgends gespeichert werden, sondern existiert nur temporär im Moment der Ersetzung. Die Ersetzung findet einheitlich in allen Dimensionstabellen statt (die Faktentabellen enthalten im Kimball-Modell nur technische Schlüssel, diese müssen nicht ersetzt werden). Die Information, welche Einträge der Dimensionstabellen zum gleichen Kunden gehören, darf und soll also erhalten bleiben.

Indirekte Identifizierung

Wenn im obigen Beispiel die Auswertung der Anzahl verkaufter Waschmaschinen nach dem Ort unveränderte Ergebnisse liefern soll, darf das Feld „Wohnort“ nicht anonymisiert werden. Doch was ist bei Kunden, die in einem 200-Seelen-Dorf wohnen und vielleicht über das weitere Feld „Beruf“, das man ggf. ebenfalls nicht anonymisiert hat, doch noch indirekt identifizierbar wären?
Dieses Beispiel zeigt, dass die Liste der Felder, die man anonymisiert bzw. eben nicht anonymisiert, in Zusammenarbeit mit der eigenen Rechtsabteilung genau betrachtet werden sollte. Dabei besteht ein Zielkonflikt zwischen dem Anspruch, Auswertungen, deren Notwendigkeit sich vielleicht erst in der Zukunft zeigt – beispielsweise für neue Analytics-Projekte –, möglichst nicht zu verfälschen und andererseits die Anonymisierung sicher durchzuführen.

Im obigen Beispiel könnte es eine Lösung sein, den Wert des Feldes „Wohnort“ durch den Namen
der zugehörigen, genügend groß gewählten Region zu ersetzen, so dass das 200-Seelen-Dorf nicht mehr erkennbar ist. Ein Wohnort wie „Hamburg“ bliebe also unverändert, während Namen von sehr kleinen Orten durch eine Regionsangabe (die auch „Hamburg“ lauten könnte, wenn der Ort dort in der Nähe liegt) ersetzt würden. Analog könnte man seltene Berufe, falls diese überhaupt erfasst werden, durch Standard-Bezeichnungen wie „Angestellter“ ersetzen.

Ob das Anonymisierungsverfahren damit sicher vor indirekten Identifizierungen ist, kann letztlich
nicht garantiert werden. Eine pragmatische Einschätzung sollte aber möglich sein, indem man die Wertekombinationen der auswertbaren Felder nach der Anonymisierung durchgeht. Eine
Wertekombination wie „weiblich, Ingenieur, Hamburg“ ist hoffentlich „anonym genug“!

Übertragung auf den Data-Vault-Ansatz

Der erste und der zweite Lösungsansatz sind in einem Data Vault schwieriger zu realisieren als im
Sternschema-Modell, weil im Data Vault zahlreiche Schlüsselbeziehungen zwischen Hubs, Links und Satelliten beachtet werden müssen. Der dritte Ansatz lässt sich dagegen leicht übertragen.

Die fachlichen Schlüssel (wie Kundennummer etc.) werden beim Data-Vault-Ansatz nur in Hubs
abgelegt und müssen dort, wie oben beschrieben, einheitlich durch neue Schlüssel aus einem
gesonderten Nummernkreis ersetzt werden. Nach der Data-Vault-2.0-Methodik sollten als technische Schlüssel überall im Data Vault die Hash-Werte der fachlichen Schlüssel verwendet werden [Lin15]. Damit fachlicher Schlüssel und Hash-Wert weiterhin zusammenpassen, müssen die Hash-Werte also ebenfalls ersetzt werden, das heißt, in allen Tabellen des Data Vault werden die bisherigen Hash-Werte der wegfallenden Schlüssel durch den neuen Hash-Wert ersetzt, der sich aus dem neuen fachlichen Schlüssel aus dem gesonderten Nummernkreis ergibt.

In den Satellitentabellen werden die Gültig-bis-Angaben des jeweils aktuellsten Eintrags auf den
gestrigen Tag gesetzt. Die Satellitentabellen beinhalten die beschreibenden Attribute – für deren
Anonymisierung gilt das Gleiche wie im Sternschema.

Weitere Aspekte

Eine zusätzliche Schwierigkeit ergibt sich durch die Notwendigkeit, personenbezogene Daten auch
in älteren Sicherungsdateien (Backups) des Kern-DWH zu löschen. Hier ist es von Vorteil, wenn stets eine Gesamtsicherung des DWH vorgenommen wird, sodass die oben beschriebenen Methoden direkt auf jede Sicherung „in sich“ angewandt werden können. Falls dagegen von jeder Tabelle des Kern-DWH eigene Sicherungen existieren, kann die Konsistenz der Tabellen und/oder Schlüsselbeziehungen (bei Einsatz eines der oben beschriebenen Lösungsansätze) nach einer Wiederherstellung mehrerer Tabellen aus unterschiedlichen Sicherungszeitpunkten
nicht sichergestellt werden, da einige Daten in einem Teil der Tabellen bereits gelöscht bzw. anonymisiert sein könnten, in einem anderen dagegen noch nicht.

Inwieweit die diskutierten Ansätze auf andere Formen dispositiver Datenhaltungen übertragbar
sind – beispielsweise auf einen Data Lake –, hängt von der verwendeten Datenmodellierung ab. Die obigen Empfehlungen gelten für Sternschema und Data Vault. Bei der Übertragung auf andere Methoden ist Vorsicht geboten. Wenn beispielsweise ein Data Lake diverse Daten ohne Schlüsselbeziehungen speichert, lassen sich Löschung oder Anonymisierung in jeder einzelnen Komponente des Data Lake leicht durchführen, doch die Überprüfung, ob indirekte Identifizierungen möglich sind, wird sehr erschwert.

Dies unterstreicht die Notwendigkeit einer durchgehenden Data-Governance-Strategie auch für Data Lakes. Dagegen sollten die obigen Vorgehensweisen unabhängig von der physikalischen
Umsetzung von Sternschema oder Data Vault sein, sodass Technologien wie In-Memory-Datenbanken oder spaltenorientierte Datenbanken hier nicht gesondert betrachtet werden.

Fazit

Viele wichtige Maßnahmen rund um die DSGVO (siehe [Eur16]) wurden hier nicht angesprochen.
Dazu wird auf die Artikel in Ausgabe 1/2018 von BI-SPEKTRUM verwiesen ([Bir18; Gra18]). Dort werden die Rolle von Pseudonymisierung, Anonymisierung und Verschlüsselung sowie die von DSGVO-bezogenen Metadaten und deren Verwaltung zur Einhaltung von Löschfristen, Regelung von Zugriffsrechten etc. diskutiert.

Dieser Artikel konzentriert sich auf technische Aspekte der Durchführung von Anonymisierungen
in einem Kern-Data-Warehouse, das nach bestimmten Methoden modelliert ist. Die gegebenen
Empfehlungen sind nicht durch juristisches Expertenwissen gestützt. Ob die hier vorgeschlagenen
Vorgehensweisen für eine konkrete Organisation in Frage kommen, muss diese in Zusammenarbeit mit Juristen jeweils selbst entscheiden. Ziel dieses Artikels ist es lediglich, geeignete Anregungen zu geben, um einen Weg zu finden, trotz der Anonymisierung
personenbezogener Daten flexible Auswertungsmöglichkeiten auf Basis des Kern-DWH zu
behalten.

Literatur

[Bir18] Birsin, E.: Sicher unterwegs im Data Lake. In: BI Spektrum, Nr. 1, 2018, S. 8–12

[Eur16] Europäisches Parlament und der Rat: Verordnung (EU) 2016/679 des Europäischen Parlaments und des Rates vom 27. April 2016 zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten, zum freien Datenverkehr und zur Aufhebung der Richtlinie 95/46/EG (Datenschutz-Grundverordnung), 2016

[Gra18] Gramlich, L. / Schmidt-Mittenzwei, P.: Datenschutz im Data Lake. In: BI Spektrum, Nr. 1, 2018, S. 14–18

[Kim13] Kimball, R. / Ross, M.: The Data Warehouse Toolkit. The Definitive Guide to Dimensional Modeling. Wiley 2013

[Lin15] Linstedt, D. / Olschimke, M.: Building a Scalable Data Warehouse with Data Vault 2.0. Morgan Kaufmann 2015

Autor

Dr. Timm Euler war bis September 2020 Senior-Berater bei der viadee IT-Unternehmensberatung und Leiter des F&E-Bereichs Business Intelligence.

Er interessiert sich für alles rund um Big Data, Data Warehousing und Data Mining.