Kommentar von Stephan Kessler, SAP SAP HANA – Datenschutz-konforme Analyse privater Daten

Anbieter zum Thema

Insider Research

OutSystems

SAP SE

Personenbezogene Daten aus Datenbanken wie SAP HANA umfassend und datenschutzkonform analysieren: Wie Unternehmen mit Anonymisierungsverfahren sensible Informationen nutzen können, ohne die Data Privacy zu gefährden.

Im Smart Home sorgen intelligente Stromzähler in Verbindung mit einer App dafür, dass die Bewohner ihren Energieverbrauch genau verfolgen und nachhaltig steuern können. Dafür wandern die erhobenen Nutzungsdaten an die Energieversorger, App-Entwickler oder Smart-Home-Dienstleister. Sie alle speichern die Daten nicht nur in ihren Datenbanken, sondern analysieren sie auch, um Effizienzgewinne zu ermitteln. Dabei müssen sie stets den Schutz personenbezogener Daten gewährleisten.

Auch für Personalabteilungen spielen intelligente Datenanalysen eine wichtige Rolle: Sie verfügen über einen großen Pool an Mitarbeiterinformationen, aus denen sich wertvolle Erkenntnisse ableiten lassen – etwa für umfangreiche Kompetenzprofile oder HR-Reports. Auch hier gilt es, Datenschutz und Big-Data-Analysen unter einen Hut zu bringen.

Die Beispiele zeigen: Daten werden für Unternehmen eine immer wertvollere Basis für strategische Entscheidungen. Gerade smarte Technologien – wie Maschinelles Lernen oder das Internet der Dinge – benötigen Daten, um funktionieren zu können. Doch nur der verantwortungsvolle Umgang mit personenbezogenen Daten stellt ihre Weiterentwicklung sicher. Die Veröffentlichung oder Weitergabe personenbezogener Daten birgt das Risiko, die Privatsphäre zu verletzen. Laut DSGVO dürfen Unternehmen personenbezogene Daten daher nur für vordefinierte und eingeschränkte Zwecke nutzen. Oder sie anonymisieren die Daten, um jeglichen Personenbezug auszuschließen.

Oft sind die in den Unternehmen genutzten IT-Systeme aber nur eingeschränkt oder gar nicht in der Lage, personenbezogene Daten entsprechend der DSGVO anonymisiert zu verarbeiten. Insbesondere dann, wenn der Verwendungszweck von dem der ursprünglichen Datenerhebung abweicht und die betroffenen Personen einer weiteren Nutzung nicht zugestimmt haben. Die Lösung: Tools wie SAP HANA Data Anonymization. Mit ihrer Hilfe lassen sich Daten anonymisieren und originär personenbezogene Daten innerhalb des gesetzlichen Rahmens nutzen.

Einblick in die Forschungslage

Seit knapp zwei Jahrzehnten beschäftigt sich die Forschung mit der Frage, wie sich personenbezogene Daten korrekt anonymisieren lassen. Das ist tatsächlich nicht trivial: Das Entfernen von Identifikatoren, wie z. B. Namen, reicht für eine Anonymisierung nicht aus. Andere Attribute reichen zur Identifikation meist aus. Ein Modell ist die so genannte k-Anonymität, die Aussagen über anonymisierte Datensätze ermöglicht. Das Verfahren basiert auf den für die Analyse notwendigen Quasi-Identifikatoren (QID), die nicht gelöscht werden dürfen um den Datenbestand noch nutzbar zu halten. Allerdings erlauben QIDs nach wie vor, Informationen einer bestimmten Person zuzuordnen – im Fachjargon Re-Identifikation genannt.

Auch die Kombination mehrerer QID-Werte kann zu einer Re-Identifikation führen. Das lässt sich vermeiden, wenn im Datenbestand mehrere Personen dieselben Attribute besitzen. Eine eindeutige Zuordnung ist dann nicht mehr möglich, die sogenannte k-Anonymität ist erreicht. Im Umkehrschluss bedeutet dies: Ein Datenbestand gilt als k-anonym, wenn mindestens k-Personen sich hinsichtlich der QIDs nicht unterscheiden lassen.

Die k-Anonymität ist eine der ersten Prinzipien zur Anonymisierung, ein weiteres Prinzip aus der jüngeren Forschung ist die Differential Privacy. Hierbei werden die Resultate um Zufallszahlen – unabhängig von jeglichem Hintergrundwissen – ergänzt. Werden Zufallszahlen auf die Daten selbst addiert, spricht man von Local Differential Privacy. Denn das Verfahren wird lokal auf einem Datensatz angewendet. Als Beispiel dafür dient das iOS-Betriebssystem von Apple.

Einstieg in die Anonymisierung

Erster Schritt: die Integration von Anonymisierungsverfahren in die vorhandenen Systeme. Typischerweise basiert die Unternehmens-IT auf drei Schichten: Über der Infrastrukturebene befindet sich die Datenhaltungsschicht – in der Regel Datenbanksysteme wie SAP HANA. Sie speichern und verwalten die Unternehmensdaten, die von Anwendungen der Applikationsschicht gelesen und geschrieben werden.

Um Anonymisierungen erfolgreich umzusetzen, gilt es zunächst folgende Fragen zu klären:

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

• 2. Wie kann die Anonymisierung für die verarbeitenden Applikationen so transparent wie möglich erfolgen?

• 3. Wie lassen sich beliebige Anonymisierungsverfahren unterstützen, um eine – je nach Anwendungsfall – optimale Balance zwischen Data Privacy und Nutzung der Daten zu ermöglichen?

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

Personas in der Unternehmens-IT

Möchten Unternehmen personenbezogene Daten für ihre Analysen nutzen, kommt es auf drei Personas an: Der Data Consumer fordert die Daten an – beispielsweise die Data-Science-Abteilung, die Gehaltsdaten analysieren möchte. Daneben verwaltet der Data Controller die Daten. Er sorgt verantwortlich dafür, dass sie entsprechend geschützt und gesichert sind und innerhalb des Unternehmens rechtskonform verarbeitet werden. Zu guter Letzt gilt es, den Datenschutzbeauftragten (Data Protection and Privacy Officer, DPPO), über die Datennutzung zu informieren.

Laut DSGVO darf ein Data Consumer nicht direkt auf die Datenbank zugreifen, die beispielsweise die Gehaltsdaten für HR-Applikationen vorhält. Stattdessen muss ihm der Data Controller die Daten anonymisiert bereitstellen. Dafür erzeugt dieser eine anonymisierte Repräsentation der Daten und stimmt sich mit dem Datenschutzbeauftragten ab. Passt alles zusammen, kann er dem Data Consumer Zugriff auf die anonymisierten Daten gewähren.

Am besten lassen sich Anonymisierungsverfahren in die Datenbank beziehungsweise Datenhaltungsschicht integrieren. Zum einen handelt es sich um die Schicht, auf die der Data Controller zugreifen kann. Zum anderen wandern keine Originaldaten in externe Systeme. Vorteil der zentralisierten Lösung: Der DPPO erhält direkt aus dem herausgebenden System Informationen über Anonymisierungskonfigurationen und bewahrt somit den Überblick.

Privacy View: Transparent für Applikationen, flexibel für die Anonymisierung

Doch wie lassen sich die Anonymisierungsverfahren in die Datenbank einbetten? Zunächst sollte die vom Data Consumer genutzte Anwendung mit anonymisierten Daten arbeiten können und dafür möglichst keine Anpassungen benötigen. In diesem Zusammenhang nutzt SAP HANA Data Anonymization die gängigen SQL-Views. Mit ihnen lassen sich die Ergebnisse einer Anonymisierung abstrahieren. Typische Analytics-Anwendungen oder die für statistische Berechnungen geeigneten Open-Source-Programmiersprachen wie R und Python können Standard-Datenbankentitäten berücksichtigen – und damit auch anonymisierte Views.

Bei SQL-Views handelt es sich um eine externe Darstellung von Daten, die in einer anderen Quelle vorliegen. Dieses Prinzip passt sehr gut zur Anonymisierung. Sie lässt ebenfalls keine Rückschlüsse auf einzelne Personen zu, während gleichzeitig der Bezug in der ursprünglichen Datenschicht erhalten bleibt. Für diesen Fall speichert SAP HANA verschiedene Metadaten, anhand derer Anonymisierungen möglich sind. Bei jeder Anfrage durch den Data Consumer auf die Privacy Views werden die Originaldaten erneut in anonymisierte Daten umgewandelt, nur die Metadaten müssen persistiert werden. Diese geben dem Datenschutzbeauftragten Einsicht in Verfahren und Parameter, die der Data Controller zuvor konfiguriert hat. Der DPPO kann weitere Anpassungen fordern und letztlich seine Genehmigung erteilen oder verweigern.

In wenigen Schritten zu Privacy Views

Um Anonymisierungsverfahren intuitiv als Privacy Views in die Architektur integrieren zu können, sollten die Verantwortlichen folgendes beachten: Privacy Views speichern weder sensible noch anonymisierte Daten. So können sie zum einen immer den aktuellen Stand der Originaldaten widerspiegeln. Zum anderen verringert sich der Verwaltungs- und Speicheraufwand für den Benutzer. Oftmals stellen Data Consumer mehrere Anfragen an die Privacy View R‘. Bei gleichbleibenden Originaldaten sollten sich auch die Resultate der Anonymisierung nicht ändern. Würden unterschiedlich anonymisierte Versionen des Datenbestandes in Umlauf geraten, ließe sich die Data Privacy nicht mehr gewährleisten.

Die Herausforderung: Der Benutzer muss wissen, ob sich die zugrundeliegenden Originaldaten verändert haben: Sind die Daten hinsichtlich der Vorgaben für die Privatsphäre bereits anonymisiert oder lassen sie sich noch anonymisieren? Etwaige Veränderungen festzustellen, ist dabei alles andere als trivial, weil sich die Originaldaten aus beliebigen Quellen zusammensetzen oder je nach Anwendungsfall aus diversen Datenbanken stammen können.

Um Änderungen aufzuspüren, generieren Anonymisierungsverfahren für jeden personenbezogenen Eintrag eine Sequenznummer (Zahl) – quasi eine Art Schlüssel. So erhält jeder Eintrag eine individuelle Zahl, die sich mit neuen oder veränderten Datensätzen weiter erhöht. In die Metadaten fließen dann sowohl die höchste Sequenznummer als auch die Anzahl der Gesamtzeilen einer Ausgangsrelation ein. Erfolgt eine erneute Abfrage auf R‘, werden die höchste 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, erzeugt die Software initiale Metadaten und speichert sie ab. Im Falle der eingangs erwähnten k-Anonymität legt das System eine optimale Generalisierung fest. „Optimal“ bedeutet in diesem Fall, dass möglichst wenig Information verlorengeht. Das optimale Generalisierungsniveau wandert in den Metadatenspeicher, wo es für spätere Anfragen bereitsteht. Im Falle von Local Differential Privacy wird ein Seed zur Generierung von Zufallszahlen festgelegt und gespeichert. So lassen sich reproduzierbare Zufallszahlen erzeugen und Anfragen zu anonymisierten Sichten konsistent beantworten.

Haben sich die Daten in R verändert, überprüft das System, ob noch alle Datenschutzvorgaben eingehalten werden. Gegebenenfalls zeigt es entweder einen Fehler an oder integriert neue Daten in das Ergebnis. Die eigentliche Anonymisierung erfolgt im nächsten Schritt: Anhand der gespeicherten Metadaten lassen sich die Daten aus R entsprechend transformieren. Konkret werden bei der k-Anonymität Werte aus R generalisiert und bei Local Differential Privacy Zufallszahlen auf Originalwerte aus R addiert. Dieser Schritt ist auch für die Performance am wichtigsten.

(ID:46633809)