Es gibt jedoch Forschungsansätze, die die Anonymisierung der Daten ermöglichen und es Anwenderunternehmen erlauben, mit gewissen Garantien ehemals personenbezogene Daten im gesetzlichen Rahmen zu nutzen. Diese Ansätze müssen aber in IT-Systeme verständlich integriert werden, um sie in den Unternehmen regelkonform einsetzen zu können.

Anonymisierungsverfahren

Wenn im Folgenden von Anonymisierungsverfahren die Rede ist, sind damit technische Verfahren gemeint, die Daten so modifizieren, dass bestimmte Privatheitsgarantien eingehalten werden.

• So stellt die "k-Anonymity" sicher, dass eine Person in einer Gruppe von "k" bezüglich bestimmter Felder ununterscheidbar ist. Das wird häufig über eine Generalisierung von Attributen erreicht: Beispielsweise ist die Altersangabe nicht mehr auf das Jahr genau heruntergebrochen, sondern in einem 5-Jahresbereich enthalten.

• "Differential Privacy" ist ein Privatheitskriterium, das häufig im Umfeld statistischer Datenbanken zum Einsatz kommt und - mithilfe generierter Zufallszahlen - Informationen über einzelne Personen versteckt.

Anonymisierung - eine Frage der Schicht

Typischerweise ist die Unternehmens-IT in drei Schichten aufgebaut (Abb. 1): Über der Infrastrukturebene (möglicherweise auch einer IaaS-Schicht in der Cloud) befindet sich die Datenhaltungsschicht - beispielsweise Datenbanksysteme wie SAP HANA. Diese speichern und verwalten die Unternehmensdaten, die von Anwendungen der Applikationsschicht gelesen und geschrieben werden.

Der Einsatz von Anonymisierungsverfahren erfordert die Beantwortung folgender Fragen:

1. Auf welcher Ebene in der Unternehmens-IT-Architektur müssen Verfahren zur Anonymisierung implementiert werden?

2. Wie kann die Anwendung von Anonymisierungsmethoden so transparent wie möglich für Applikationen erfolgen?

3. Wie können beliebige Anonymisierungsverfahren unterstützt werden, um eine - je nach Anwendungsfall - optimale Balance zwischen Privatheit und Nutzbarkeit der Daten zu ermöglichen?

4. Wie lassen sich unnötige Kopien der Daten vermeiden?

Personas in der Unternehmens IT

Sollen personenbezogene und sensible Daten für Analysen genutzt werden, sind in Unternehmen in der Regel drei "Personas" beteiligt (Abb.2):

1. Ein Data Consumer fordert die Daten an - im Beispiel die Data-Science-Abteilung, die Gehaltsdaten analysieren möchte.

2. Der Data Controller verwaltet die Daten, bzw. ist verantwortlich dafür, dass die Daten entsprechend geschützt und gesichert sind und innerhalb des Unternehmens rechtskonform verarbeitet werden.

3. Zu guter Letzt muss der Data Protection and Privacy Officer (DPPO) oder der Datenschutzbeauftragte über die Datennutzung innerhalb des Unternehmens informiert werden. Er ist für die Durchsetzung von Unternehmensrichtlinien und aktuell geltendem Recht zuständig, insbesondere dann, wenn es um personenbezogene und sensible Daten geht.

Der Data Consumer kann nicht einfach direkten Zugriff auf die Datenbank bekommen, die die Gehaltsdaten für die entsprechende Unternehmensapplikation bereithält. Um die Informationen dennoch regelkonform zu nutzen, kann der Data Controller die Daten anonymisiert bereitstellen. Dazu erzeugt er eine anonymisierte Repräsentation der Daten (wie weiter unten erläutert, eine anonymisierte Sicht) und stimmt sich hinsichtlich des Datenschutzes mit dem DPPO ab. Schließlich kann er dem Data Consumer Zugriff auf die anonymisierten Daten gewähren.

Einbettung in die Architektur

Die bisherigen Ausführungen legen es nahe: Anonymisierungsverfahren passen am besten in die Datenbank beziehungsweise Datenhaltungsschicht. Es ist zum einen die Schicht, auf die der Data Controller Zugriff hat und zum anderen würde ein externes System einen Transfer der Originaldaten aus der Datenbank heraus bedeuten. Das muss natürlich aus Datensicherheitsaspekten vermieden werden. Eine zentralisierte Lösung hat zusätzlich den Vorteil, dass der DPPO direkt aus dem herausgebenden System Informationen über Anonymisierungskonfigurationen bekommen und so einen Überblick wahren kann.

Privacy View: Transparent für Applikationen, flexibel für Anonymisierungsverfahren

Wie lassen sich nun Anonymisierungsverfahren in der Datenbank selbst einbetten? Der Data Consumer beziehungsweise dessen Anwendung soll natürlich unabhängig von einer möglichen Anonymisierung sein - die Anwendung konsumiert Daten und soll möglichst keine Anpassungen benötigen, falls diese anonymisiert sind.

In unserem Beispiel (Abb. 3) nutzt SAP HANA Data Anonymization die bekannten SQL-Views als Abstraktion für die Ergebnisse einer Anonymisierung. Typische Analytics-Anwendungen oder auch Tools wie R und Python können Standard-Datenbankentitäten konsumieren - also auch anonymisierte Views ohne technische Anpassung.

Ein SQL-View stellt eine externe Repräsentation von Daten dar, die in einer anderen internen Repräsentation vorliegen. Allgemein erfolgt für Views die Transformation durch eine SQL-Anfrage, die in dieser gekapselt wird. In dieses Modell lässt sich auch die Anonymisierung einbauen, da die externe Repräsentation keinen Rückschluss auf einzelne Personen zulässt, dieser Bezug jedoch intern erhalten bleibt.

Hierzu speichert SAP HANA Metadaten, anhand derer die Daten anonymisiert werden können. Das funktioniert für beliebige Anonymisierungsverfahren. Die Transformation der Originaldaten geschieht bei jeder Anfrage durch den Data Consumer auf die Privacy View erneut, nur die Metadaten müssen also persistiert werden. Diese geben auch dem DPPO Einsicht in Verfahren und Parameter, wie sie durch den Data Controller konfiguriert wurden. Der DPPO kann also Anpassungen fordern und letztlich eine Genehmigung erteilen oder verweigern.

Implementierung der Privacy View

Anonymisierungsverfahren architektonisch als View in die Datenschicht einzubetten, ist für den Benutzer intuitiv, birgt jedoch einige Herausforderungen bei der Implementierung. Dabei ist wichtig zu betonen: Ein View speichert keine sensiblen oder auch anonymisierten Daten. Das ist wichtig, da sie immer den aktuellen Stand der Originaldaten widerspiegeln soll. Außerdem verringert das den Verwaltungs- und Speicheraufwand für Benutzer.

Data Consumer stellen natürlich möglicherweise mehrere Anfragen an die Privacy View R' (Abb. 4). Bei gleichbleibenden Originaldaten sollen selbstverständlich auch die Resultate der Anonymisierung die gleichen sein. Für die Anonymisierung ist das von zusätzlicher Bedeutung: Würden unterschiedlich anonymisierte Versionen des Datenbestandes in Umlauf geraten, könnten zugesprochene Privatheitsgarantien potenziell nicht mehr eingehalten werden.

Werden zum Beispiel bei einem Release von Daten mittels (Local) Differential Privacy Daten neue Zufallszahlen für das gleiche Gehalt gewählt, kann man zusätzliche Rückschlüsse auf den Originalwert schließen, da die Summe der Zufallszahlen den Erwartungswert 0 hat. Um das zu gewährleisten, müssen Metadaten abgespeichert werden. Was das genau für die Anfrageverarbeitung bedeutet, wird im Folgenden erläutert.

Abbildung 5 zeigt die Verarbeitung der Anfrage select * auf R' im Kontext des Metadatenspeichers. Metadaten folgen dem transaktionalen Modell und werden innerhalb der Datenbank gespeichert. Der Zugriff ist natürlich für keinen Benutzer der Datenbank möglich, sondern nur systemintern für die Anonymisierungskomponente.

Die erste Herausforderung liegt darin, festzustellen, ob sich die zugrundeliegenden Originaldaten verändert haben oder noch nie anonymisiert wurden, demnach also neu sind. In beiden Fällen muss das System sicherstellen, dass die Daten hinsichtlich der Garantien für die Privatsphäre anonymisiert sind oder anonymisiert werden können. Änderungen festzustellen, ist aber keine triviale Aufgabe: Die Originaldaten könnten sich aus beliebigen Quellen zusammensetzen und je nach konkretem Anwendungsfall sogar aus anderen Datenbanken stammen.

Um das nachvollziehen zu können, ist eine Sequenznummer (Zahl) als eine Art Schlüssel für jeden personenbezogenen Eintrag zu generieren: Jeder personenbezogene Eintrag besitzt eine individuelle Zahl und diese Zahl wächst weiter für neue oder veränderte Datensätze. Im Metadatenspeicher wird dann immer das Maximum dieser Sequenznummer und die Anzahl der Gesamtzeilen einer Ausgangsrelation gespeichert. Erfolgt eine erneute Abfrage auf R', werden Maximum der Sequenznummer und Zeilenanzahl der aktuellen Version von R mit den gespeicherten verglichen. Sind sie gleich, ist R identisch mit dem Stand der letzten Anfrage. Sind sie unterschiedlich, wurde R verändert.

Sind die Originaldaten dem Anonymisierungssystem noch unbekannt oder neu, müssen initiale Metadaten in Schritt (2) erzeugt und später, in Schritt (3), gespeichert werden. Im Falle der k-Anonymity legt das System eine optimale Generalisierung fest. "Optimal" bedeutet in diesem Fall, dass möglichst wenig Information verloren geht, gleichzeitig aber das k-Anonymity-Kriterium erfüllt wird. Das optimale Generalisierungsniveau wird im Metadatenspeicher für spätere Anfragen abgelegt. Im Falle von (Local) Differential Privacy wird ein Seed zur Generierung von Zufallszahlen festgelegt und gespeichert. Dadurch ist es möglich, reproduzierbare Zufallszahlen zu erzeugen und Anfragen zu anonymisierten Sichten konsistent zu beantworten.

Haben sich die Daten in R verändert, wird in Schritt (2) überprüft, ob die geforderten Garantien für die Privatheit noch eingehalten werden, gegebenenfalls wird entweder ein Fehler angezeigt oder neue Daten in das Ergebnis integriert.

Die eigentliche Anonymisierung erfolgt in Schritt (4): Anhand der gespeicherten Metadaten werden die Daten aus R entsprechend transformiert. Konkret werden bei k-Anonymity Werte aus R generalisiert und bei Local Differential Privacy Zufallszahlen auf Originalwerte aus R addiert.

Beispieldefinition einer Privacy View

Anonymisierte Sichten wie weiter oben beschrieben, lassen sich für die beiden Methoden k-Anonymity und Differential Privacy jeweils mittels folgender SQL Kommandos in SAP HANA definieren:

CREATE VIEW PERONAL_K_ANON (ID, VERTRAG_SEIT, PLZ, GESCHLECHT, AUSBILDUNG, GEHALT)
AS SELECT ID, VERTRAG_SEIT, PLZ, GESCHLECHT, AUSBILDUNG, GEHALT FROM PERSONAL
WITH ANONYMIZATION ( ALGORITHM 'K-ANONYMITY' PARAMETERS '{"k": 2}'
COLUMN ID PARAMETERS '{"is_sequence": true}'
COLUMN VERTRAG_SEIT PARAMETERS '{"is_quasi_identifier":true,
hierarchy":{"embedded": [["2001", "[2001-2015]"], <…>]}}'
COLUMN PLZ PARAMETERS '{"is_quasi_identifier":true,
"hierarchy":{"embedded": [["76131", "7613*", "761**", <…>], <…>]}}'
COLUMN GESCHLECHT PARAMETERS '{"is_quasi_identifier":true,
"hierarchy":{"embedded": [["M"], ["W"]]}}'
COLUMN AUSBILDUNG PARAMETERS '{"is_quasi_identifier":true,
"hierarchy":{"embedded": [
["Dr. rer. nat.", "Dr."], ["Dr.-Ing.", "Dr."],
["Diplom", "Hochschulabschluss"], <…>]]}}'
);

CREATE VIEW PERSONAL_DIFF_PRIV (ID, VERTRAG_SEIT, PLZ, GESCHLECHT, AUSBILDUNG, GEHALT)
AS SELECT ID, VERTRAG_SEIT, PLZ, GESCHLECHT, AUSBILDUNG, GEHALT FROM PERSONAL
WITH ANONYMIZATION (ALGORITHM 'DIFFERENTIAL_PRIVACY'
COLUMN ID PARAMETERS '{"is_sequence": true}'
COLUMN GEHALT PARAMETERS '{"is_sensitive":true, "epsilon":0.1, "sensitivity":2000}');

In beiden Fällen werden Spalten aus der Tabelle mit Orginaldaten selektiert (SELECT), die nach außen hin sichtbar sein sollen. Es folgt die Anweisung, eine Sicht mit Anonymisierung anzulegen (WITH ANONYMIZATION) und die Wahl der Methode (ALGORITHM), sowie Festlegung etwaiger Parameter im JSON Format (z.B. k), die für alle Spalten gelten (PARAMETERS). Danach werden den jeweiligen Spalten Parameter zugewiesen. Im Falle von k-Anonymity sind dies die Rolle einer QID und zugehörige Hierarchien. Im Falle von Differential Privacy ist das die Spalte, die mit Zufallszahlen modifiziert werden soll, zusammen mit zwei numerischen Werten (epsilon und sensitivity), die die Verteilung der Zufallszahlen bestimmen.

Nach einem CREATE ist das Kommando REFRESH auf den View abzusetzen, um die benötigten Metadaten zu generieren. Erst danach können mittels SELECT beliebige Anfragen auf den View erfolgen.

Fazit

Viele Technologien - wie Maschinelles Lernen oder Anwendungen im Bereich des Internet der Dinge - benötigen Daten, um überhaupt funktionieren zu können. Doch nur der verantwortungsvolle Umgang mit personenbezogenen Daten stellt sicher, dass sich solche Technologien in Zukunft sicher weiterentwickeln lassen.

Mit Hilfe von Anonymisierungsverfahren können zwei zunächst widersprüchlich wirkende Anforderungen erfüllt werden: Die Privatheit einzelner Personen wird im Datenbestand geschützt, aber gleichzeitig können die Daten für umfangreiche Analysen verwendet werden. Das ermöglicht Anwendungen basierend auf der Auswertung personenbezogener Daten, die ohne Anonymisierungsverfahren nicht möglich wären, da die Privatheit nicht hinreichend geschützt wäre. Dazu ist es aber auch nötig, solche Verfahren aus der Forschung in Produktivsystemen verfügbar zu haben. Mit der SAP HANA Data Anonymization ist das im Unternehmensumfeld produktiv möglich. (ba)