Datenbank Spektrum (2016) 16:107–117 DOI 10.1007/s13222-016-0216-7

SCHWERPUNKTBEITRAG

Datenschutz im PArADISE Hannes Grunert1 · Andreas Heuer1

Eingegangen: 1. Februar 2016 / Angenommen: 12. April 2016 / Online publiziert: 1. Juni 2016 © Springer-Verlag Berlin Heidelberg 2016

Zusammenfassung Durch die Ereignisse in den vergangenen Jahren ist die Integration von Datenschutzmechanismen in Informationssysteme wieder ein zentrales Forschungsproblem geworden. Insbesondere in smarten, dem Menschen assistierenden Umgebungen werden in vielen Fällen mehr Informationen generiert und verarbeitet als die Analysefunktionen des Assistenzsystems benötigen. Der in diesem Artikel beschriebene Forschungsansatz stellt ein Framework für Anwendungsentwickler und Nutzer zur Durchsetzung von Datenschutzbestimmungen in ubiquitären Umgebungen vor, welches insbesondere den Aspekt der Datensparsamkeit in einer heterogenen Systemumgebung realisieren soll. Eine Verwendung des Frameworks kann sowohl in Peerto-Peer-Umgebungen als auch in festgelegten Client-Server-Hierarchien erfolgen. Durch die Aufteilung der Anfrageverarbeitung in eine Vorverarbeitungsphase, in der die ursprüngliche Anfrage umgeschrieben wird, und in eine nachgelagerte Anonymisierungsphase wird ein hohes Datenschutzniveau als auch ein geringer Informationsverlust erreicht. PArADISE wird als Prototyp für Softwareentwickler im Bereich der Modellbildung für Intentions- und Situationserkennung in Assistenzsystemen entwickelt. Eine Verwendung des Frameworks in weiteren Anwendungsbereichen ist jedoch ebenso möglich.

Die Arbeit wurde teilweise durch die Deutsche Forschungsgemeinschaft (DFG), Graduiertenkolleg 1424 (MuSAMA), gefördert.  Hannes Grunert

[email protected] 1

Institut für Informatik, Universität Rostock, 18051 Rostock, Deutschland

Schlüsselwörter Datenschutz · Datensparsamkeit · Assistenzsysteme · Anfrageverarbeitung

1 Einleitung Smart Metering, Internetüberwachung, Bewegungsprofile, biometrische Datenbanken, Vorratsdatenspeicherung: In der digitalen Welt werden stetig mehr Informationen über uns und unsere Umwelt gesammelt. Dabei werden unter Umständen auch Angaben über unsere persönlichen und sachlichen Verhältnisse erfasst, ohne dass wir unsere Zustimmung erteilt haben. Mit persönlichen Daten sind nicht nur Informationen zu unserem Namen oder Geburtstag zu verstehen, sondern auch Angaben zu unserem Gesundheitszustand, unseren politischen und ethischen Ansichten und zu unseren Vermögensverhältnissen. Während das Recht auf informationelle Selbstbestimmung durch verschiedene Gesetze, wie dem Bundesdatenschutzgesetz [4] und dem Strafgesetzbuch, gefestigt ist, existieren in der technologischen Umsetzung erhebliche Risiken. Bei der automatisierten Erhebung, Verarbeitung1 und Nutzung personenbezogener Daten kann in bestehenden Informationssystemen nicht garantiert werden, dass sensible Daten erkannt werden und ob deren Nutzung verhältnismäßig und mit Einwilligung des betroffenen Nutzers geschieht. Leider geht der Trend bei smarten Systemen immer mehr dahin, die Daten fast vollständig in die Cloud zu übertragen und beim Anbieter des Systems dann ungeschützt mit Big-Data-Analytics-Methoden zu sezieren. Die Privatheitsansprüche des Nutzers werden nur dahingehend beruhigt, dass die Daten angeblich nur zum Besten des Nutzers aus1 Dies bezieht sowohl die Speicherung, Veränderung, Übermittlung, Sperrung als auch Löschung ein.

K

108

gewertet werden sollen, beziehungsweise dass die Auswertung der detaillierten Nutzungsdaten ausschließlich der Verbesserung des Systems dient. Dieses ehrenhafte Ziel mag man verschiedenen Systemanbietern nun aber nicht so recht glauben: warum müssen smarte Fernseher mit HbbTV und Spracheingabe alle aufgezeichneten Kommandos zum Hersteller übertragen? Warum müssen alle im Kinderzimmer aufgezeichneten Dialoge eines Kindes mit einer Spielzeugpuppe namens Hello zum Anbieter übertragen werden? Und selbst Anbieter von AAL-Systemen wie Teppichen mit Sensoren zur Sturzerkennung verzichten auf jegliche lokale Intelligenz und übertragen die Sensorinformationen komplett zum Hersteller, um sie dort auszuwerten. Dabei ist es ohne Probleme möglich, mit der Leistungsfähigkeit einer preiswerten Spielekonsole sogar kamerabasiert Stürze zu erkennen, bei denen dann nur ein Signal “Sturz wahrscheinlich” aus der Wohnung heraus zu einem Pflegedienst geleitet werden muss [22]. Und dass die Auswertung der Informationen beim Anbieter des smarten Systems nicht immer zum Vorteil oder zum Besten des Nutzers ist, merkt man insbesondere daran, dass die smarten Systeme bei Gerichtsprozessen gegen ihre Nutzer und zugunsten des Anbieters (im übertragenen Sinne) aussagen (am Beispiel eines Autos in [1] thematisiert). Aufgrund der Big-Data = Big-Brother-, NSA- und Snowden-Diskussion wäre es dagegen für deutsche Hersteller ein Leichtes, smarte Systeme zu verkaufen und damit zu werben, dass ihre Systeme systemimmanent die Privatheit gewährleisten, weil sie eben konstruktionsbedingt nur die für die definierte Zielsetzung des smarten Systems nötigen Daten aus der Privatsphäre des Nutzers (Wohnung, Auto, mobiles Gerät wie Smartphone) heraus transportieren. Das PArADISE-Framework soll es daher Forschern und Entwicklern ermöglichen, solche smarten, aber privatsphäre-sichernden Systeme zu konstruieren.

2 Grundlagen und Motivation 2.1 Problemstellung

Informationssysteme werden mit der Zielsetzung entwickelt, konkrete Aufgaben und Problemstellungen zu lösen. Dabei werden häufig personenbezogene Daten gesammelt und verarbeitet. Zur Wahrung des Datenschutzes werden persönliche Daten vor der Herausgabe und Weiterverarbeitung an Dritte anonymisiert. Im folgenden Beitrag stellen wir ein Framework vor, welches ausgehend vom vorhandenen Datenbestand und der verwendeten Analysetechnik eine geeignete Anonymisierung der Daten realisiert. Die präsentierten Lösungen

K

Datenbank Spektrum (2016) 16:107–117

wurden am Graduiertenkolleg MuSAMA2 der Universität Rostock entwickelt. Zielsetzung von MuSAMA ist die Entwicklung von Modellen und Algorithmen [24, 8] für die ingenieurstechnische Umsetzung von Assistenzsystemen in dynamischen ad-hoc-Umgebungen. Der Einsatz des Frameworks erfolgt in einem ubiquitären Besprechungsraum, welcher mit verschiedenen Sensoren und Geräten ausgestattet ist. Dabei werden ausgehend von den Sensordaten die aktuelle Situation im Raum und die Handlungen der Personen in Echtzeit ermittelt [15]. Mittels Intentionserkennung werden die Besprechungsteilnehmer durch die automatisierte Steuerung des Raumes unterstützt [17]. Der Lehrstuhl Datenbank- und Informationssysteme beschäftigt sich innerhalb von MuSAMA einerseits mit der Datenbankunterstützung für komplexe Analyseverfahren [21], aber auch mit der Fragestellung, inwiefern Datenschutz direkt durch Datenbanktechnologien gewährleistet werden kann. Der Fokus liegt neben der effizienten Erkennung von schützenswerten Daten [11] auf der Minimierung des Informationsverlustes durch die Anonymisierung von personenbezogenen Daten und der Umsetzung von Datensparsamkeit durch Anfrageumschreibungen. Neben dem MuSAMA-Leitszenario werden auch weitere Szenarien untersucht, wie mobile Assistenzsysteme (außerhalb und innerhalb von Gebäuden, im Auto) und das Smart Home, also Assistenzfunktionalitäten in unserer eigenen Wohnung. Das letztgenannte Szenario findet sich bei uns in diversen Projekten zur Unterstützung älterer Personen in ihrer eigenen Wohnung (AAL, Ambient Assisted Living) [3]. Wir werden im späteren Verlauf des Artikels unsere Datenschutztechniken am Wohnungsszenario erläutern. 2.2 Smarte Umgebungen

Bei der Verarbeitung von Big Data sind Assistenzsysteme als besonders kritisch anzusehen, da diese Systeme fast ausschließlich auf personenbezogenen Daten arbeiten. Neben “klassischen” Einzelangaben über Personen, wie den Namen, das Alter oder das Geschlecht, zeichnen eine Vielzahl von Sensoren die Handlungen und Neigungen der Nutzer auf. Verschiedene Ortungssysteme wie aktive und passive RFID-Tags, Kameras, Mikrophone, aber auch Sensoren an Lichtschaltern und Steckdosen erfassen bis zu 100-mal pro Sekunde die aktuelle Situation im Raum. Ausgehend von diesen Daten werden Modelle zur Kontext- und Intentionserkennung abgeleitet, um den Raum zielgerichtet und nutzerorientiert zu steuern [2]. Neben der Datenschutzproblematik ergibt sich aus den zu sammelnden bzw. gesammelten Daten eine Vielzahl von 2

Multimodal Smart Appliance Ensembles for Mobile Applications

Datenbank Spektrum (2016) 16:107–117

109

Abb. 1 Probleme und datenbankunterstützte Lösungen für Big Data und Assistenzsysteme. a Die bekannten vier Vs b Vier Ps als Lösungsansatz

von PArADISE werden insbesondere die Punkte Privatheit und Parallelisierung durch Forschungsarbeiten bearbeitet. Schwerpunkt dieses Artikels bildet die datenschutzfreundliche Anfrageverarbeitung durch die datensparsame und datenvermeidende Verarbeitung von Sensordaten. 2.3 Grundlagen des Datenschutzes

Abb. 2 Prüfschema zur datenschutzrechtlichen Gestaltung von Informationssystemen

Problemen. Assistenzsysteme stellen ein gutes Beispiel für eine Big-Data-Anwendung dar, da sie alle 4V-Merkmale (Abb. 1a) von Big Data erfüllt. Viele unterschiedliche (Variety) Sensoren erfassen die Daten im System. Die Sensoren weisen dabei aber einen gewissen Grad an Unschärfe (Veracity) auf. Diese Daten werden mit einer hohen Frequenz erhoben und müssen nach Möglichkeit in Echtzeit (Velocity) verarbeitet werden. Für die Modellbildung müssen Datenmassen (Volume) effizient gespeichert und ausgewertet werden. Die Herausforderungen von Big Data werden am Lehrstuhl im Rahmen der Langzeitprojekte METIS3, PArADISE4 und HyDRA5 durch ein 4P-Modell (Abb. 1b) angegangen [13]. Die Forschungsschwerpunkte bilden die Themen Privatheit (Datensparsamkeit und Datenvermeidung), Performance durch Parallelisierung, Provenance (Rückverfolgbarkeit von Analyseergebnissen) und Preservation (nachhaltige Speicherung von wichtigen Daten). Innerhalb 3 Management, Evolution, Transformation und Integration von Schemata 4 Privacy AwaRe Assistive Distributed Information System Environment 5 a HYpergraph of Documents in a Relational Archive

Personenbezogene Daten gilt es so zu anonymisieren oder zu pseudonymisieren, dass einzelne Attributwerte nur mit einem unverhältnismäßig hohen Aufwand an Zeit oder Kosten einer bestimmten Person zugeordnet werden können. Zusätzlich ist zu beachten, dass die veränderten Daten über einen ausreichend hohen6 Informationsgehalt verfügen müssen, damit das Informationssystem die Daten für weitere Analysen nutzen kann. Es gilt daher die größtmögliche Anonymität bei minimalem Informationsverlust zu gewährleisten. Um dies zu erreichen, dürfen Datenschutzaspekte nicht on-top auf bestehende Systeme aufgesetzt werden, sondern müssen bereits während der Entwicklung in Abstimmung mit den datenverarbeitenden Funktionen integriert werden. Aus diesem Grund ist es notwendig, im Vorfeld festzulegen, welche Daten im Informationssystem gespeichert werden sollen und ob es sich um sensible Daten im Sinne des BDSG [4] handelt (siehe Abb. 2). Falls dies zutrifft, muss ermittelt werden, auf welcher Grundlage (Rechtsvorschrift oder informierte Einwilligung) die Erhebung und Verarbeitung erfolgt und ob die Informationserhebung verhältnismäßig zum angestrebten Nutzen ist. Sofern alle Kriterien erfüllt sind, muss entschieden werden, wie die Anforderungen an den Datenschutz technisch umgesetzt werden. Zwei Kernaspekte des Datenschutzes stellen die Datenvermeidung und die Datensparsamkeit dar. In §3a des Bundesdatenschutzgesetzes [4] wird gefordert, dass

6

abhängig von der konkreten Anwendung

K

110

Datenbank Spektrum (2016) 16:107–117

[d]ie Erhebung, Verarbeitung und Nutzung personenbezogener Daten und die Auswahl und Gestaltung von Datenverarbeitungssystemen [...] an dem Ziel auszurichten [sind], so wenig personenbezogene Daten wie möglich zu erheben, zu verarbeiten oder zu nutzen. Datenvermeidung und Datensparsamkeit sind somit gesetzlich vorgeschriebene, unverzichtbare Anforderungen für die Gestaltung von IT-Systemen. Datenschutzbehörden fordern, dass die Realisierung dieser Anforderungen durch eine entwicklungsbegleitende und somit systemimmanente, datenschutzfreundliche Ausgestaltung der Technik erfolgt. Konkrete Forderungen sind unter anderem: ●

●

● ● ●

der Verzicht auf personenbezogene Daten (sofern nicht erforderlich) die Verarbeitung möglichst weniger Daten mit Personenbezug eine frühestmögliche Anonymisierung eine frühestmögliche Pseudonymisierung und die frühestmögliche Löschung der personenbezogenen Daten, sofern auf deren weitere Verarbeitung verzichtet werden kann

In einer smarten Umgebung ist nicht nur ein einzelner Rechner für die gesamte Datenverarbeitung zuständig. Informationen werden in vielen unterschiedlichen Quellen erzeugt und an anderer Stelle integriert. Unsere Zielstellung ist es, dass nur Daten weitergegeben werden, die für die spätere Auswertung unabdingbar sind und nicht bereits früher ausgewertet werden können. Zusätzlich zur Datenvermeidung ist es unabdingbar, dass personenbezogene Daten vor der Herausgabe anonymisiert werden. Dazu werden die Daten generalisiert, bis Detailinformationen verborgen und Kriterien wie beispielsweise k-Anonymität [25] erfüllt sind. Dieses Vorgehen stellt sich in der Praxis jedoch als unzureichend heraus, da die Daten durch den hohen Informationsverlust bei der Anonymisierung ungeeignet für komplexere Analyseverfahren sind. Neben der Generalisierung von Daten existieren alternative Anonymisierungstechniken, wie die Slicing-Technik [20] oder Differential Privacy [7]. In früheren Publikationen haben wir gezeigt [12], dass insbesondere bei der spaltenorientierten Analyse von Daten ein höherer Datennutzen gewährleistet wird, wenn Slicing anstatt Generalisierung eingesetzt wird.

3 Das PArADISE-Framework Die Anwendung eines bestimmten Anonymisierungskriteriums für die Gesamtheit aller Analysefunktionen eines Systems ist nicht praktikabel. Die Auswahl einer Analysefunktion hängt nicht nur von der genutzten Datenbasis

K

Abb. 3 Der Anfrageprozessor mit Präprozessor (links) und dem Postprozessor (rechts)

ab, sondern auch von der gestellten Anfrage. So können spaltenbasierte Funktionen, wie beispielsweise eine lineare Regressionsanalyse, wenig Nutzen aus zu stark generalisierten Daten ziehen, während die Permutation ausgewählter Attributgruppen wenig Einfluss hat. Die Anwendung des Kriteriums der Datensparsamkeit für unterschiedliche Analyseverfahren hat Vorteile für alle Beteiligte: Modellierer suchen nach Modellbeschreibungen für die Intentionsund Situationserkennung und bestimmten Parametrisierungen eines Modells. Durch die Anonymisierung der Daten können sie feststellen, welche minimale Attributmenge (im Anwendungsszenario: minimale Menge von Sensoren) ausreicht, um ihr Modell zu charakterisieren. Nutzer legen vor allem Wert auf die Wahrung ihrer Privatsphäre: sie wollen sicherstellen, dass nur diejenigen Daten vom System verwendet werden, die für die Ausführung benötigt werden. Die Betreiber des Systems erhalten Rechtssicherheit, da der nach außen gelangende Datenbestand reduziert wird und somit wenig bis gar keine zusätzlichen Informationen über die Nutzer durch (böswillige) Dritte abgefangen werden können. Wir entwickeln ein modulares Framework namens Privacy-aware Assistive Distributed Information System Environment (PArADISE), um Forscher, Anwendungsentwickler und Nutzer bei der Umsetzung datenschutzfreundlicher Informationssysteme zu unterstützen. Es ermöglicht die einfache Integration von Datenschutzmechanismen und komplexen Analysefunktionen. Unter der Anwendung von Datenschutzkriterien und Informationsverlustmetriken können verschiedene Anonymisierungstechniken für eine oder mehrere gegebene Datenbanken geprüft werden, um eine passende auszuwählen. Die Architektur des PArADISE-Frameworks ist in Abb. 3 dargestellt. Das Framework ist vorwiegend in Java implementiert, greift aber auch auf SQL zurück, um einige Datenschutzaspekte direkt in Datenbanksystemen auszuführen. Mögliche Ansatzpunkte stellen dabei das

Datenbank Spektrum (2016) 16:107–117

Umformen der Anfragen und der Ergebnisrelation sowie das Ausnutzen von Sichtenkonzepten [14] dar. Der Kern des Frameworks bildet der Anfrageprozessor, der aus vier Hauptkomponenten besteht: ●

●

●

●

Der Präprozessor ermöglicht die Analyse und die Umschreibung von Datenbankanfragen. Bei der Anfrageausführung wird entschieden, ob die Anfrage direkt auf dem aktuellen Netzwerkknoten beantwortet und anonymisiert wird oder an einen sensornäheren Knoten weitergeleitet wird. Im Postprozessor wird die Anonymisierung des Anfrageergebnisses unter Berücksichtigung verschiedener Qualitäts- und Datenschutzkriterien realisiert. Es werden dazu verschiedene Datenschutzmetriken und -algorithmen bereitgestellt. Das Modul für die automatische Generierung von Datenschutzeinstellungen betrachtet bestehende Datenschutzrichtlinien von Nutzern und passt sie an neue Geräte und veränderte Anforderungen an.

Zusätzlich zu diesen vier Komponenten wird während des Betriebs des Assistenzsystems überprüft, ob in der gespeicherten Datenmenge identifizierende Attributmengen vorhanden sind. Dies wird durch den QI-Detektor realisiert. Die Bereitstellung der Liste von Quasi-Identifikatoren (QI) dient zur Parametrisierung der anderen Komponenten. Die einzelnen Bestandteile werden im Folgenden ausführlicher beschrieben.

111

Im Gegensatz zu sensitiven Daten sind insensitive Daten solche, die nicht unbedingt geschützt werden müssen. Auch hier sind die Domäne und die persönlichen Präferenzen entscheidend, wie die Daten einzuordnen sind. Quasi-Identifikatoren (QI) haben schlüsselähnliche Eigenschaften. Die Identifizierung eines Tupels in einer Relation ist mit diesen Attributkombinationen meistens möglich, aber nicht zu 100 %. QI können Teile eines Schlüssels, aber auch Kombinationen aus Teilschlüsseln, sensitiven und insensitiven Daten sein. Durch die hohe Dimensionalität und die große Menge an Daten, die in einem Assistenzsystem anfallen, ist es für einen unerfahrenen Nutzer, aber auch für den Entwickler des Systems, nicht einfach zu erkennen, welche Attributkombinationen die Identifizierung eines Objekts ermöglichen. Gleiches gilt für die Ableitung von zusätzlichen Informationen aus den bestehenden Daten. In [9] stellen wir einen Ansatz vor, mit dem sich QuasiIdentifikatoren in hochdimensionalen Datenbanken schnell und vollständig erkennen lassen. Die Geschwindigkeit ist für smarte Umgebungen dahingehend wichtig, weil neue Teilsysteme und Sensoren in das System hinzugefügt werden und Daten aufzeichnen können, ohne dass der Nutzer dies merkt und sofort darauf reagieren kann. Durch eine rasche Erkennung schützenswerter Daten lassen sich so schnell temporäre Datenschutzprofile erzeugen, bevor das System weiterhin unerwünscht Daten aufnimmt. 3.2 Anfrageverteilung

3.1 Erkennung schützenswerter Daten

Die von Assistenzsystemen gespeicherten Daten lassen sich in vier Kategorien unterteilen: Schlüsselattribute, QuasiIdentifikatoren, sensitive Daten und nicht-sensitive Daten. Schlüsselattribute ermöglichen die eindeutige Identifizierung eines Objektes, beispielsweise einer bestimmten Person oder einer Handlung. Diese Attribute ermöglichen es, Informationen aus verschiedenen Relationen oder gar unterschiedlichen Datenquellen miteinander zu verknüpfen. Die Schlüsseleigenschaft eines Attributes wird für gewöhnlich beim Datenbankentwurf festgelegt. Meist werden für Schlüssel eigene, künstliche Attribute angelegt, es können aber auch ein oder mehrere bestehende Attribute als Schlüssel ausgezeichnet werden. Schlüssel sollten nicht weitergegeben werden, da sie mit Informationen außerhalb des Systems verknüpft werden können und so neue Informationen über das betroffene Objekt ermittelt werden können. Sensitive Daten sind solche Daten, die es zu schützen gilt. Diese sind von der Anwendungsdomäne und von der betroffenen Person, auf die sich die Daten beziehen, abhängig. Im Gesundheitssektor sind dies beispielsweise Informationen zu Krankheitsverläufen, im Finanzwesen Details zu Ein- und Ausgaben.

In smarten Umgebungen bzw. Assistenzsystemen werden Auswertungen an zentraler Stelle berechnet, die Daten für die Auswertung sind aber in der Regel auf mehrere Datenbanken verteilt. Für die Umsetzung wird eine Datenbankanfrage Q an die Datenbank d gesendet, welche den gesamten gespeicherten Sensordatenbestand der Umgebung integriert. Das Ergebnis der Anfrage Q wird benötigt, um eine bestimmte Aktivitäts- und Intentionserkennungen durchzuführen. Die Datenquellen sind Sensoren, welche in unserer Umgebung, beispielsweise in unserer Wohnung bzw. im Büro, platziert wurden. Wir werden im Folgenden das Szenario Wohnung betrachten. Stellen wir uns vor, wir hätten für unsere Wohnung einen umfassenden Assistenz-Service bei der Firma Poodle bestellt. Poodle, früher ein reiner Suchmaschinen-Anbieter, hat sich in der Zwischenzeit auch zum Anbieter von Smart-Home-Technologien wie intelligenten Heizungsthermostaten, Fernsehern, Küchengeräten, Teppichen sowie Möbeln entwickelt, alle natürlich mit diverser Sensorik ausgestattet. Von Poodle erwarten wir nun bestimmte Dienste, wie eine automatisierte Problemerkennung (etwa eine Sturzerkennung). Um diese Dienste anbieten zu können, muss der Cloud-Server von Poodle nun diverse

K

112

Datenbank Spektrum (2016) 16:107–117

Die Rechenknoten auf den unteren Verarbeitungsebenen besitzen meist eine sehr geringe Rechenleistung in Vergleich zu den oberen Knoten. Während Sensoren nur einfache Filterungen, Selektionen und Aggregationen aktueller Sensordaten ausführen können, kann ein Audio-VideoGerät – wie ein Fernseher oder eine smarte Musikanlage im Heimnetzwerk – zumindest einfache Anfragen an eine Datenbank (SQLsuperlight) ausführen. Ein komplexeres System wie ein Android-basiertes Home-EntertainmentSystem kann noch kompliziertere Anfragen ausführen. Die so aufgebaute Anfrageverarbeitung Q(d) ∶= d j = Q j (...d i ′ = A(d i = Q i (...(d1 = Q1 (d))...)

Abb. 4 Stufen der Anfrageumschreibung

Anfragen (wie das oben genannte Q) an die Sensordatenmenge d unserer Wohnung stellen dürfen. Da Poodle uns die Assistenzumgebung sehr preiswert überlässt, möchte das Unternehmen unsere Daten und daraus abgeleiteten Profile aber weiterverkaufen. Wir möchten das allerdings nicht. Daher sind wir froh, dass Poodle den Dienst auch in einer mit PArADISE entwickelten Variante anbietet. Anstatt die Daten d an den Cloud-Server von Poodle, welcher die Anfrage stellt, zu übertragen, werden maximale Anteile von Q so nahe wie möglich am Sensor ausgewertet. Wie in Abb. 4 zu sehen, wird Q(d) nicht in der Cloud ausgeführt, sondern die maximale Teilanfrage Q j auf den nächstgelegenen Knoten in der Anfragekette übertragen, im Beispiel auf einen Computer, der sich in unserer Wohnung befindet. Während Q einen in R und SQL implementierten, iterativen Lernalgorithmus ausführt und Q j eine komplexe, rekursive SQL-Anfrage, können die untersten Knoten in der Verarbeitungskette (in unserem Anwendungsszenario: Sensoren) nur einfache Filter- und Selektionsbedingungen ausführen sowie einfache Aggregationen über die zuletzt generierten Werte (Windowfunktionen, z. B. den Durchschnitt der letzten Minute) berechnen. Jeder Rechenknoten überträgt das Ergebnis d j der Anfrage Q(d) an den Knoten, welcher die Anfrage gesendet hat. Nach der Anonymisierung A verlassen die modifizierten Daten d ′ unsere Umgebung, enthalten jedoch nur einen kleinen, aber für die ursprüngliche Anfrage Q ausreichenden, Bruchteil der Originaldaten. Poodle ist nun in der Lage, mit dem Ergebnis die benötigte Aktivitätserkennung (etwa Sturzerkennung) durchzuführen, allerdings sind über dieses Ziel hinausgehende Auswertungen unserer Daten deutlich erschwert worden.

wird so transformiert, dass der Cloud-Server die Restanfrage Q δ auf dem Datenbestand d ′ ausführt statt die Originalanfrage Q auf d, woraus sich eine Anfrageumschreibung Q(d) → Q δ (d ′ ) ergibt, die gleichzeitig die Aspekte der Datensparsamkeit und Datenvermeidung umsetzt. Kurz gefasst: die Anfrage Q wird in mehrere Teilanfragen Q j fragmentiert, die auf den leistungsschwachen Knoten ausgeführt werden können. Die verbleibende Anfrage Q δ wird auf den leistungsstärkeren Knoten in dieser vertikalen Verteilung der Anfrageverarbeitung ausgeführt. Obwohl die Erkennung von maximalen SQL-Anfragen innerhalb eines in R verfassten Lernalgorithmus im Allgemeinen unentscheidbar ist (aufgrund der Unentscheidbarkeit des Problems für Turingmaschinen), lassen sich größere, in SQL umformbare Patterns, wie beispielsweise Regressionsanalysen, in Aktivitäts- und Intentionserkennungsmethoden (vgl. [17]) herausfiltern. Durch die Umschreibung der Anfrage Q in Q j und Q δ , wobei nur Q δ außerhalb unserer geschützten Systemumgebung ausgeführt wird, wird höchstwahrscheinlich schon verhindert, dass Poodle unsere personenbezogenen Daten für andere Zwecke verwendet als ursprünglich vorgesehen und bei der Beauftragung des Dienstes definiert. Offen bleibt zu beweisen bzw. zu widerlegen, ob eine “boshafte” Anfrage Q↓ existiert, welche auch auf der Teildatenbank d ′ von d personenbezogene Daten abgreifen kann. Falls eine solche Anfrage existiert, muss die Anonymisierung A verschärft werden. Diese Fragestellung mündet in ein Query-Containment-Problem7 bestehend aus den Anfragen Q, Q↓ und Q j , welches wir in unserer zukünftigen Forschung untersuchen wollen.

7 Zu Query-Containment-Problemen sei auf [5] oder Kapitel 8 aus [16] verwiesen.

K

Datenbank Spektrum (2016) 16:107–117

113

4 Beispiel Betrachten wir folgende SQL-Anweisungen, die in einem R-Programm zur Auswertung von Sensordaten (Ausschnitt aus einem Kalman-Filter) eingebettet sind:

Die Funktion filterByClass filtert die Datensätze eines DataFrames (R-Datencontainer) nach dem Kriterium, ob die ausgeführte Handlung “walk” entspricht. Das Ergebnis der Analyse soll nicht grafisch ausgegeben werden (do.plot=F). Der DataFrame wird mittels der Funktion sqldf aus dem Ergebnis einer verschachtelten SQL-Anfrage erzeugt8. Die SQL-Anfrage realisiert eine komplexere Regressionsanalyse mit Partitionierungen, Aggregationen und Order-byBedingungen. Die Daten stammen von einer Datenquelle d ′ , welche Teil eines Peer-to-Peer-Netzwerkes ist (siehe Abb. 4). Im Netzwerk befinden sich sowohl cloudbasierte und lokale Server als auch integrierte Rechner und klein(st)e Sensoren mit unterschiedlichen Leistungsmerkmalen hinsichtlich Rechen- und Speicherkapazität und Möglichkeiten zur Verarbeitung von Anfragen. Für unser Beispiel stammen die Daten von einem kleinen Bewegungssensor auf der untersten Ebene. Die Ursprungsanfrage Q wird über mehrere Knoten bis an den Sensor weitergeleitet. Dabei werden grundsätzlich immer alle Daten des Sensors angefragt (SELECT * FROM d i bzw. SELECT * FROM stream). Zusätzlich zu der Anfrage des Assistenzsystems existiert eine Datenschutzrichtlinie [10, 23] für den Bewegungserkennungsfilter (siehe Abb. 5; vereinfachte Darstellung). In der Richtlinie werden zwei Datenschutzansprüche formuliert: Der x-Wert des Sensors muss immer größer als der y-Wert sein (x > y). Für den z-Wert soll gelten, dass dieser immer kleiner als 2 ist (z < 2) und dass dieser nur in einer Durchschnitts-Aggregation, gruppiert nach x und y und in der Summe größer als 100, vorkommen darf. Für die Transformation (Umschreibung) der Anfrage wird zunächst die Datenschutzrichtlinie mit der Anfrage verschmolzen. Dabei werden die zusätzlichen Bedingungen als WHERE- bzw. HAVING-Klausel in die tiefst mögliche SQL-Anfrage innerhalb der Schachtelung eingefügt. Für aggregierte Werte werden neue Attributnamen eingefügt und ggf. in die äußeren SQL-Anfragen übertragen.

Abb. 5 Datenschutzrichtlinie für das laufende Beispiel

Die umgeformte Anfrage wird anschließend auf die einzelnen Rechenknoten verteilt. Dabei wird der R-Code weiterhin auf dem Cloud-Server ausgeführt, während der lokale Server über ausreichend Leistung verfügt um die Regressionsanalyse der SQL-Anfrage eigenständig auszuführen.

8 Die SQL-Anteile werden dabei von einem Parser für R-Code ermittelt, welcher in der prototypischen Umsetzung bereits enthalten ist. Für die Unterstützung weiterer Programmiersprachen müssen weitere Parser per Plugin integriert werden.

K

114

Das Ergebnis der Regressionsanalyse d ′ wird dem CloudServer als DataFrame bereitgestellt. Auf dem lokalen Server lässt sich die innere SQL-Anfrage abspalten und an das Home-Media-Center auslagern.

Das Media-Center selbst übernimmt nur den Aggregationsanteil der SQL-Anfrage.

Datenbank Spektrum (2016) 16:107–117

gung von Informationsverlustmetriken wie der KullbackLeibler-Distanz [18] oder der Direct Distance (DD) lässt sich die Qualität der Ergebnisse von Anfragen ermitteln. Dabei muss gelten, dass der Informationsverlust von den gewollten Anfragen möglichst gering gehalten werden sollte, während “unerwünschte” Anfragen einen möglichst hohen Informationsverlust aufweisen sollten. Ein einfach gehaltenes Maß zur Messung des Informationsverlustes ist die Direct Distance, die durch n

m

DD(R, R ′) = ∑ ∑ distance(i, j) i=1 j=1

definiert ist, wobei n die Anzahl der Tupel und m die Anzahl der Attribute in der Originalrelation R bzw. in der anonymisierten Relation R ′ sind, sowie Die WHERE-Klausel wird zum einen in die Appliance (Wertevergleich zwischen zwei Attributen)

und den Sensor (nur Selektionsbedingung einer Variable gegenüber einer Konstanten) ausgelagert.

Die Daten werden schrittweise vom Sensor zurück an den Cloud-Server gesendet und weiterverarbeitet. Sobald die Daten auf der höchsten Stufe, die noch im Einflussbereich des Nutzers liegt (hier: der lokale Server), werden die Daten zusätzlich so anonymisiert, dass die Daten 2-anonym sind (siehe Abb. 4). Zusätzlich kann auch die Anonymität bezüglich der Kommunikation ab dieser Stelle realisiert werden, beispielsweise durch die Nutzung eines Tor-Netzwerkes [6]. Dies ist allerdings nicht Forschungsgegenstand innerhalb von PArADISE.

5 Anonymisierung Die Verteilung der Anfrage auf mehrere Ebenen und die Verschneidung der ursprünglichen Anfrage mit dem Datenschutzprofil des Nutzers stellen zwei Kernprinzipien unseres Datenschutzkonzeptes dar. Dennoch kann es erforderlich sein, dass die aus der Datenbank ermittelten Daten vor der Herausgabe anonymisiert werden müssen. Dabei wird überprüft, ob konkrete Kriterien wie k-Anonymität [25] oder t-closeness [19] zutreffen. Unter Berücksichti-

K

distance(i, j) ∶= {

0, falls Wer t[R i , j ] = Wer t[R ′i , j ] 1 sonst

die Anzahl der nicht übereinstimmenden Attributwerte zwischen R und R ′ ermittelt. Aus dem Verhältnis zwischen der Anzahl an unterschiedlichen Werten in R ′ zur Gesamtzahl der Werte in der Originalrelation R (m ∗ n Werte) lässt sich die Qualität des Ergebnisses für eine Anfrage ableiten. Datenschutz, insbesondere die Anonymisierung von Daten, wird sowohl in der Wirtschaft als auch in der Forschung häufig als Hindernis angesehen, da ein Verlust der Genauigkeit der Analysen bis hin zu falschen Ergebnissen befürchtet wird. Um den Bedenken vorzubeugen, gilt es den Informationsverlust durch die Anonymisierung soweit zu minimieren, dass die Ergebnisse unmerklich von den Rohdaten abweichen. Gleichzeitig gilt es aber auch ein hohes Datenschutzniveau zu erreichen. In den letzten Jahren wurden viele Verfahren basierend auf k-Anonymität [25], Differential Privacy [7] und ähnlichen Konzepten aufgebaut. Es existiert aber keine one-size-fits-all-Lösung, welche alle Problemstellungen löst. Durch die Auswahl eines für bestimmte Analysen geeigneten Anonymisierungskonzeptes lassen sich Daten zielgerichtet anonymisieren (vgl. Abb. 6). Die Entscheidung, welches Verfahren später eingesetzt wird, muss dabei eng mit den Entwicklern der Analysefunktionalitäten erfolgen. Durch die vorherige Analyse und Umschreibung der Anfrage lässt sich dabei ermitteln, welche Attribute für die Anonymisierung in Frage kommen, und ob die Anonymisierung spalten- (Slicing [20]) oder zeilenweise (k-Anonymität [25]) erfolgen sollte.

Datenbank Spektrum (2016) 16:107–117

115

Abb. 6 Beispielrelation vor der Anonymisierung (oben) sowie nach Anwendung von Generalisierungen (links) bzw. des Slicing-Konzeptes mit permutierten Attributwerten (rechts)

6 Ausblick Der Anfrageprozessor von PArADISE existiert als prototypische JDBC-Treiber-Implementierung. Der Prozessor wird gegenwärtig Schritt für Schritt um weitere Datenschutzkriterien und -algorithmen sowie weitere Module erweitert. Sobald die letzten Programmierarbeiten und Tests abgeschlossen sind, wird der JDBC-Treiber als Open Source bereitgestellt. Der bisherige Entwicklungsstand realisiert die Ergebnistransformation unter der Einbindung von Datenschutzeinstellungen sowie die rudimentäre Anfrageverteilung über mehrere Rechenknoten. Es fehlen jedoch noch die Komponenten zur Anfrageumschreibung und zum Messen des Informationsverlustes. Ziel ist es zudem, Schnittstellen bereitzustellen, um Forschungsgruppen die Möglichkeit zu bieten, ihre eigenen Algorithmen und Konzepte zu testen und mit anderen Ansätzen zu vergleichen. Für die weitere Entwicklung des Treibers ist es insbesondere interessant, verschiedene Anonymisierungstechniken zur Verfügung zu haben, um auf verschiedene Arten von legitimen und bösartigen Anfragen ein höchstmögliches Niveau von Datenschutz und Informationsqualität zu erreichen. Zudem sollen verschiedene Testdatensätze direkt im Treiber angebunden werden. Für die Konfiguration wird derzeit eine grafische Oberfläche implementiert, damit zum einen die verschiedenen Einstellungen leicht verändert werden können, zum anderen aber auch zur besseren Veranschaulichung der Anfragetransformation und der Ergebnisse. Weiterhin werden folgende Probleme noch tiefergehend untersucht:

1. Informationsverlustmetriken. Zum gegenwärtigen Zeitpunkt enthält PArADISE nur eine Verlustmetrik auf Basis der Kullback-Leibler-Divergenz, welche insbesondere für Anonymisierungstechniken verwendet wird. Die Integration weiterer Metriken ermöglicht eine bessere Vergleichbarkeit von verschiedenen Anonymisierungskonzepten. 2. Analysefunktionen. Die verbleibende Qualität des anonymisierten Ergebnisses hängt nicht nur ausschließlich von der ausgewählten Datenschutztechnik und deren Parametrisierung ab. Es ist auch entscheidend, welche Arten von Anfragen gestellt werden. In Big-Data-Anwendungen werden Daten häufig spaltenweise analysiert. Gängige Anonymisierungskonzepte wie k-Anonymität arbeiten hingegen zeilenweise und verringern insbesondere den Informationsgehalt einzelner Attribute, wodurch beispielsweise Durchschnittswerte stark verfälscht werden können. Alternative Algorithmen wie das Slicing verringern nicht die Qualität von einzelnen Werten und erlauben so weiterhin die Auswertung bestimmter Daten. Es bleibt die offene Frage, welche Analysemethoden zu welchen Anonymisierungskonzepten “passen”. 3. Nachvollziehbarkeit. Zusätzlich zur Ausgabe der anonymisierten Ergebnismenge muss dem Anfragesteller mitgeteilt werden, inwieweit das Ergebnis von der ursprünglichen SQL-Anfrage abweicht. Dies kann durch Provenance-Informationen in den Metadaten der Ergebnisrelation realisiert werden. Dabei werden neue Methoden im Treiber der Java-Klasse bereitgestellt, welche Informationen zu den Arten der entfallenden Tupel bzw. Attribute enthalten sowie Angaben zu Art und Umfang der vorgenommenen Anonymisierung.

K

116

7 Zusammenfassung Die Wahrung der Privatsphäre stellt in ubiquitären Umgebungen eine besondere Herausforderung dar. Eine Vielzahl von Sensoren halten jeden Augenblick unseres Lebens fest und durchleuten unser Privatleben. In diesem Artikel stellen wir eine Möglichkeit vor, mit der sich Privatheitsansprüche gegenüber einem Assistenzsystem formulieren lassen, damit wir wieder Herr unserer eigenen Daten werden. Durch die Reduzierung und Vorverarbeitung der Daten, die von den Sensoren erzeugt und durch das System verarbeitet werden, auf die minimal benötigten Informationen kann der Datenschutz in smarten Umgebungen gewährleistet werden. Das PArADISE-Framework unterstützt sowohl Anwendungsentwickler als auch Nutzer von smarten Umgebungen also bei der Einhaltung des Datenschutzes durch die Anwendung des Privacy-by-Design-Prinzips. Der vorgestellte Prototyp des Anfrageprozessors setzt die technischen Anforderungen an die rechtlichen Datenschutzregelungen in zwei Phasen um und ermöglicht die Formulierung und automatische Generierung neuer Datenschutzregeln nach Veränderung des Datenbestandes bzw. -schemas. PArADISE stellt unterschiedliche Methoden zur Anonymisierung von personenbezogenen Daten bereit. Entwickler von Assistenzsystemen können ihre Datenbasis mit der für ihre Analysefunktionen am besten geeigneten Datenschutz-Metrik gezielt anonymisieren, während der Datennutzen weiterhin ein hohes Niveau behält. Zudem bietet das Framework ein Modul zur Umschreibung von Anfragen an den Datenbestand mit dem Ziel, nur die Informationen auszulesen und zu verarbeiten, die in der späteren Analyse von Bedeutung sind. Mit derselben Technik können erfasste Daten nah am Datenerzeuger (meist Sensoren) verarbeitet und verdichtet werden, so dass etwa in Smart-Home-Umgebungen die meisten Detaildaten die Wohnung nicht verlassen müssen. Zusätzlich kann das PArADISE-Framework genutzt werden, um neue Datenschutzrichtlinien aus bereits bestehenden Einstellungen (von bereits vorhandenen Analysefunktionen und Sensoren) zu generieren. Existierende smarte Umgebungen übertragen dagegen die Originaldaten fast vollständig in die Cloud, damit sie erst beim Hersteller analysiert und ausgewertet werden. In PArADISE formuliert der Dienstanbieter dagegen die Auswertungsstrategie, die er auf den Daten des Nutzers ausführen möchte (pull), im System wird diese aber dann vertikal (nahe an die Sensoren) verteilt, damit nur die relevanten Daten übertragen werden, die eventuell auch noch weitergehend anonymisiert werden können. Diese Entscheidungen münden in ein push der relevanten und nicht privatheitsgefährdenden Daten. Auf längere Sicht könnte das Framework auch als Rahmenarchitektur für verschiedene Forschungsvorhaben ge-

K

Datenbank Spektrum (2016) 16:107–117

nutzt werden. Dazu wurde in PArADISE ein einfaches Plugin-System integriert, mit dem das Framework leicht um zusätzliche Algorithmen, neue Arten von Datenquellen und Datenschutzrichtlinien erweitert werden kann. Über einheitliche Schnittstellen lassen sich bestehende Algorithmen leicht in das System integrieren. Danksagung Wir danken den studentischen Projektgruppen und Hilfskräften für ihre Unterstützung bei der Implementierung einzelner Komponenten des PArADISE-Frameworks: Felix Köppl, Stefan Lüdtke, Steffen Sachse, Jan Svacina, Dennis Weu, Pia Wilsdorf (Regressions- und Korrelationsanalysen auf SQL-Plattformen); Tobias Fitschen, Mark Lukas Möller, Lars Nonnemann (Verteilte Datenanalyse); Johannes Goltz, Christian Langmacher, Irene Martin Rodriguez, Gunnar Raßmann (JDBC-Grundgerüst); Martin Müller (Domain Generalization Hierarchy in SQL), Marc-Eric Meier, Georgi Straube (Generierung von Datenschutzrichtlinien).

Literatur 1. ADAC (2014) Spion im Cabrio: Z4 sagt gegen Fahrer aus. ADACMotorwelt 72(7):30 2. Bader S, Dyrba M (2011) Goalaviour-based control of heterogeneous and distributed smart environments. In: 7th International Conference on Intelligent Environments, 2011, IEEE, pp 142–148 3. Bruder I, Heuer A, Karopka T, Schuldt J, Kosche K (2015) Experiences in Developing and Testing an Ambient Assisted Living Course for Further Education. In: HIS Conference Proceedings, Springer, Lecture Notes in Computer Science, vol 9085, pp 154–164 4. Bundesrepublik Deutschland (2010) Bundesdatenschutzgesetz in der Fassung der Bekanntmachung vom 14. Januar 2003 (BGBl. I S 66), das zuletzt durch Artikel 1 des Gesetzes vom 14. August 2009 (BGBl. I S 2814) geändert worden ist 5. Chirkova R (2009) Query containment. In: Encyclopedia of Database Systems. Springer, US, S 2249–2253 6. Dingledine R, Mathewson N, Syverson PF (2004) Tor: The secondgeneration onion router. In: Blaze M (Hrsg) Proceedings of the 13th USENIX Security Symposium, August 9–13, 2004, San Diego, CA, USA, USENIX, S 303–320 7. Dwork C (2011) Differential privacy. In: Encyclopedia of Cryptography and Security. Springer, US, S 338–340 8. Giersich M, Heider T, Kirste T (2007) AI Methods for Smart Environments – A Case Study on Team Assistance in Smart Meeting Rooms. In: Ferscha A, Aitenbichler E (eds) Constructing Ambient Intelligence – AmI 2007 Workshops Darmstadt, Germany, November 7-10, 2007 Revised Papers, Springer, Communications in Computer and Information Science, vol 11, pp 4–13 9. Grunert H (2014) Distributed Denial of Privacy. In: INFORMATIK 2014: Big Data Komplexität meistern. GI, LNI, vol 232, S 2299–2304 10. Grunert H (2016) Privacy Policy for Smart Environments. http:// www.ls-dbis.de/pp4se. Zugegriffen: 1. Febr. 2016 11. Grunert H, Heuer A (2014) Big Data und der Fluch der Dimensionalität: Die effiziente Suche nach Quasi-Identifikatoren in hochdimensionalen Daten. In: Klan F, Specht G, Gamper H (eds) Proceedings of the 26th GI-Workshop Grundlagen von Datenbanken, Bozen-Bolzano, Italy, October 21–24, 2014, CEUR-WS.org, CEUR Workshop Proceedings, vol 1313, pp 29–34 12. Grunert H, Heuer A (2015) Slicing in Assistenzsystemen – Wie trotz Anonymisierung von Daten wertvolle Analyseergebnisse gewonnen werden können. In: Saake G, Broneske D, Dorok S, Meister A (eds) Proceedings of the 27th GI-Workshop Grundlagen

Datenbank Spektrum (2016) 16:107–117 von Datenbanken, Gommern, Germany, May 26–29, 2015, CEURWS.org, CEUR Workshop Proceedings, vol 1366, pp 24–29 13. Heuer A (2015) METIS in PArADISE: Provenance Management bei der Auswertung von Sensordatenmengen für die Entwicklung von Assistenzsystemen. In: BTW 2015 – Workshopband, GI, LNI, vol 242, pp 131–136 14. Heuer A, Lubinski H (1998) Data Reduction – an Adaptation Technique for Mobile Environments. In: Interactive Applications of Mobile Computing (IMC’98), pp 1–2 15. Konieczek B, Rethfeldt M, Golatowski F, Timmermann D (2015) Real-Time Communication for the Internet of Things using jCoAP. In: IEEE 18th International Symposium on Real-Time Distributed Computing (ISORC), 2015, IEEE, pp 134–141 16. Köppen V, Saake G, Sattler K (2014) Data Warehouse Technologien, 2. Aufl. MITP, Bonn 17. Krüger F, Nyolt M, Yordanova K, Hein A, Kirste T (2014) Computational State Space Models for Activity and Intention Recognition. A Feasibility Study. PLoS ONE 9(11):e109381 18. Kullback S, Leibler RA (1951) On information and sufficiency. Annals of Mathematical Statistics 79–86 19. Li N, Li T, Venkatasubramanian S (2007) t-closeness: Privacy beyond k-anonymity and l-diversity. In: IEEE 23rd International Conference on Data Engineering, IEEE, pp 106–115

117 20. Li T, Li N, Zhang J, Molloy I (2012) Slicing: A new approach for privacy preserving data publishing. IEEE Transactions on Knowledge and Data Engineering 24(3):561–574 21. Marten D, Heuer A (2015) Transparente Datenbankunterstützung für Analysen auf Big Data. In: Saake G, Broneske D, Dorok S, Meister A (eds) Proceedings of the 27th GI-Workshop Grundlagen von Datenbanken, Gommern, Germany, May 26–29, 2015, CEURWS.org, CEUR Workshop Proceedings, vol 1366, pp 36–41 22. Marzahl C, Penndorf P, Staemmler M, Bruder I (2012) Unobtrusive fall detection using 3D images of a gaming console: Concept and first results. In: Tagungsband des deutschen AAL-Kongresses, Ambient Assisted Living, vol 5, pp 135–146 23. Meier ME (2015) Implementierung eines Data-Mining-Verfahrens für adaptive Datenquellen. Bachelorarbeit, U Rostock 24. Nyolt M, Yordanova K, Kirste T (2015) Checking Models for Activity Recognition. In: Loiseau S, Filipe J, Duval B, Herik HJ van den (Hrsg) ICAART 2015 – Proceedings of the International Conference on Agents and Artificial Intelligence. SciTePress, Portugal, S 497–502 25. Samarati P (2001) Protecting respondents identities in microdata release. IEEE Trans. Knowledge and Data Engineering 13(6):1010–1027

K