In diesem Kapitel erfahren Sie, was Anonymisierung ist, wie man sie einsetzt und was Sie beachten müssen, wenn Sie sie im Rahmen von Data Science verwenden. Gut möglich, dass Ihnen bereits einiges zum Thema Anonymisierung vorschwebt – dieses Kapitel könnte Ihre Vorstellungen von Anonymisierung durchaus auf den Kopf stellen bzw. ihnen widersprechen! Die Frage, wie Daten anonymisiert werden können, beschäftigt Forschende sowie Wissenschaftlerinnen und Wissenschaftler schon seit Jahrzehnten – und sorgt auch heute noch für Diskussionen zwischen Datenschutzfachleuten. In diesem Kapitel lernen Sie eine streng wissenschaftliche Definition von Anonymisierung kennen – nämlich die der sogenannten Differential Privacy. Auf dieser Grundlage können Sie das Problem mit modernsten Technologien angehen, und Sie lernen Werkzeuge kennen, die Sie in die Lage versetzen, strenge Datenschutzstandards einzuhalten, ohne dabei auf Qualität im Rahmen der datenwissenschaftlichen Arbeit zu verzichten.
Eine Anonymisierung ist »die Entfernung von identifizierenden Informationen (aus etwas, wie z.B. aus elektronischen Daten), damit die ursprüngliche Datenquelle nicht ermittelt werden kann«.1 Wenn Sie personenbezogene Daten anonymisieren, möchten Sie also sicherstellen, dass die Daten nicht auf eine bestimmte Person zurückgeführt werden können. Doch wie genau können Sie das bewerkstelligen?
In der Vergangenheit gab es zahlreiche Ansätze, von denen die meisten inzwischen überholt sind und durch neuere Erkenntnisse abgelöst wurden. Zu den ersten Ansätzen (zusammengefasst unter der Kategorie statistische Offenlegungskontrolle, engl. Statistical Disclosure Control (https://oreil.ly/KfE-z)) gehörte eine Reihe von inzwischen nicht mehr empfohlenen Methoden wie die Suppression, die Aggregierung und die Transformation von Daten zum Zweck der Anonymisierung. Diese Methoden ähneln frühen kryptografischen Chiffren. Sie verschleiern die ursprüngliche Quelle, aber durch einen gezielten Angriff wäre es möglich, zusätzliche Informationen abzuleiten bzw. zu extrapolieren und möglicherweise sogar an die ursprüngliche Information zu gelangen.
Ähnlich wie bei der Entwicklung der Kryptoanalyse in der Kryptografie (die auch Kryptanalyse genannt wird) wurden im Laufe der Jahrzehnte neue Privacy-Angriffsmethoden entwickelt, mit denen die Schwachstellen in diesen simplen Ansätzen aufgezeigt wurden. Vermutlich sind Sie schon einmal auf »anonymisierte« Daten gestoßen, bei denen Techniken wie die folgenden angewandt wurden:
Von einem sicherheitstechnischen Standpunkt aus mögen solche Verschleierungsmethoden, auch Obfuskationsmethoden genannt, interessant sein, doch leider sind sie nicht in der Lage, den Schutz der Privatsphäre zu gewährleisten.
Cynthia Dwork und einige ihrer Kolleginnen und Kollegen konnten nachweisen, dass die Veröffentlichung jeglicher Daten das Risiko einer Re-Identification Attack bzw. eines Informationsgewinns birgt.2 In dem wegweisenden Artikel wird dies anhand eines Beispiels veranschaulicht. Angenommen, Sie wissen, dass eine Person zwei Zentimeter größer ist als die Durchschnittsgröße der Menschen in einem bestimmten Land. Plötzlich veröffentlicht eine Regierungsbehörde die durchschnittliche Körpergröße der Menschen in diesem Land. Damit kennen Sie nun die genaue Körpergröße dieser Person – und sie muss nicht einmal in dem Datensatz enthalten sein!
Die wichtigste Botschaft hierbei ist, dass Sie nicht wissen können, was ein Angreifer bereits über eine Person bzw. eine Gruppe von Personen weiß (oft als Zusatzinformationen [engl. Auxiliary Information] bezeichnet). Zu den Zusatzinformationen gehören nicht nur die heute verfügbaren Daten, sondern auch alle Daten, die in Zukunft noch bekannt werden können, sodass eine Abschätzung praktisch unmöglich ist. Dementsprechend können Sie nicht garantieren, dass eine Veröffentlichung von Informationen – ganz gleich, wie verschleiert oder unbedenklich sie zu sein scheinen – dazu führt, dass eine Person weder identifiziert werden kann noch Informationen über sie preisgegeben werden.
Sie könnten sich nun die Frage stellen, wozu eine Anonymisierung überhaupt gut sein soll. Wenn es keine Garantie dafür gibt, dass ein Angreifer keine Informationen erlangen kann, warum sollten Sie dann überhaupt einen Versuch unternehmen? Obgleich Sie nicht garantieren können, dass ein Angreifer nichts erfährt, sollten Sie darüber nachdenken, wie Sie die Menge der Informationen, die in Erfahrung gebracht werden können, quantifizieren können. Das ist es, was Dwork und einige andere Forscherinnen und Forscher zu entwickeln begannen, nachdem sie bewiesen hatten, dass diese Methoden für die statistische Offenlegungskontrolle ein Irrtum waren.3
Da sie nachweisen konnten, dass eine anonymisierte Veröffentlichung von Daten, wie sie im Merriam-Webster-Dictionary definiert ist, in mathematischer und logischer Hinsicht nicht möglich ist, verlagerte sich das Problem von »Wie können wir Daten anonymisieren?« zu »Wie können wir den Verlust an Privatsphäre – den sogenannten Privacy Loss – quantifizieren, wenn Daten veröffentlicht werden?«. Sie wollten Wege finden, wie Forschende den Privacy Loss bei der Veröffentlichung von Daten messen können, anstatt zu garantieren, dass dieser Verlust nie eintreten wird. Das bedeutet, dass ein binäres Verständnis von Privacy – also entweder »an« oder »aus« – durch ein abgestuftes Verständnis von Privacy abgelöst wird.
Dies bedeutet auch für Sie einen grundlegenden Umdenkprozess. Der einzige Weg, einen vollkommenen Schutz der Privatsphäre garantieren zu können, besteht darin, alle Daten zu löschen oder sie gar nicht erst zu erheben. Ich bin zwar eine begeisterte Anhängerin der Datenminimierung, aber auch pragmatische Data Scientist. Um Probleme lösen zu können, sind Daten erforderlich. Wenn Sie Datenschutz im Sinne einer gewissen Bandbreite betrachten, können Sie sich darüber klar werden, worauf Sie Wert legen. In welchem Maße bin ich bereit, den Schutz der Privatsphäre einzuschränken, wenn ich eine Frage beantworten will? Wie viel Schutz der Privatsphäre kann ich gewährleisten und trotzdem noch nützliche Antworten auf meine Fragen erhalten?
Um Ihnen beim Nachdenken über diese Fragen und über Datenschutz verschiedener Ausprägungen zu helfen, habe ich ein kleines Diagramm erstellt (siehe Abbildung 2-1), das das mögliche Spektrum zwischen vollkommenem Schutz und maximalem Informationsgehalt von Daten illustriert. Ganz links besteht ein vollkommener Schutz von Daten, was im Umkehrschluss bedeutet, dass keinerlei Informationen mehr vorhanden sind – sämtliche Daten werden gelöscht. Ganz rechts ist der maximal mögliche Informationsgehalt von Daten zu verorten – die Daten unterliegen keinerlei Schutz (sofern sie überhaupt als sensibel einzustufen sind). Innerhalb dieses Spektrums stehen Ihnen unzählige Privacy-Technologien zur Verfügung, mit denen Sie einen angemessenen Grad an Datenschutz gewährleisten bzw. auch im Hinblick auf die Nützlichkeit der Daten für Ihre Analysen eine geeignete Balance finden können.
Abbildung 2-1: Mögliches Spektrum zwischen vollkommenem Schutz und maximalem Informationsgehalt von Daten
Auch wenn in Abbildung 2-1 die entsprechenden Ansätze jeweils einem bestimmten Grad zugeordnet sind, werden in diesem Kapitel auch Anonymisierungsverfahren vorgestellt, die mehr Informationen liefern können, sowie Pseudonymisierungsverfahren, bei denen mehr Informationen verloren gehen, als die Abbildung suggeriert. Sie ist weniger als Empfehlung à la »Verwenden Sie dies anstelle von jenem« gedacht, sondern eher als Denkanstoß dazu, dass es eine Reihe von Technologien und eine Bandbreite gibt, in der Sie zwischen einem hohen Informationsgehalt und dem Schutz Ihrer Daten abwägen müssen. Wenn Sie dieses Buch zu Ende gelesen haben, werden Sie zahlreiche Möglichkeiten kennengelernt haben, die Sie kombinieren können, um bei Ihrer Arbeit die richtige Balance innerhalb dieses Spektrums zu finden.
Mithilfe von Differential Privacy können Sie den Informationsgrad messen, um ein geeignetes Gleichgewicht innerhalb dieses Spektrums in Bezug auf Ihr vorliegendes Problem zu finden, und gleichzeitig den Schutz der Privatsphäre des Einzelnen garantieren (Individual Privacy Guarantees). Im Folgenden erfahren Sie, was genau unter Differential Privacy zu verstehen ist, sodass Sie eine bessere Vorstellung davon bekommen, welche Möglichkeiten Sie innerhalb dieses Spektrums haben.
Differential Privacy ist eine präzise und wissenschaftlich fundierte Definition der Offenlegung von datenschutzsensiblen Informationen. Sie begrenzt das Ausmaß des sogenannten Privacy Loss – also des Verlusts an Privatsphäre der betroffenen Personen –, der bei der Veröffentlichung von Daten entstehen kann. Sie bietet Ihnen die Möglichkeit, diesen Verlust an Privatsphäre (Privacy Loss) für jede einzelne Person in einem Datensatz zu quantifizieren. Diese Methode ist der heutige »Goldstandard« der Anonymisierung. Bei Differential Privacy werden die Grenzen im Hinblick auf die Offenlegung von Informationen durch bestimmte Parameter in der Definition festgelegt. Diese werden garantiert, wenn auf die Daten zugegriffen wird, sie abgefragt oder veröffentlicht werden. Sie werden durch Algorithmen (sogenannte Mechanismen) gewahrt, die so viele Informationen preisgeben, um aus den Daten genügend Informationen zu gewinnen, ohne zu viel über eine einzelne Person preiszugeben.
Ein wichtiger Unterschied zwischen Differential Privacy und früheren Ansätzen besteht darin, dass sich Differential Privacy auf den Prozess und nicht auf das Ergebnis konzentriert. Bei den bisherigen Methoden wurde versucht, die resultierenden Daten zu untersuchen, um festzustellen, ob sie ausreichend »anonymisiert« sind. Die Forschungsarbeit von Dwork et al. hat gezeigt, dass dieser Weg ein Trugschluss ist. Bei Differential Privacy geht man dazu über, die Garantien, die ein bestimmter Algorithmus bieten kann, zu quantifizieren, indem man die Informationen misst, die der Algorithmus selbst kontinuierlich freigibt. Wenn man sich auf den Prozess und den Algorithmus konzentriert, kann man auch dynamischere Systeme aufbauen, Algorithmen ändern und dennoch den Privacy Loss im Laufe der Zeit analysieren!
Im Grunde genommen wird bei Differential Privacy zunächst eine bestimmte Bedingung definiert, die ein Algorithmus bzw. Mechanismus erfüllen muss, damit die Privatsphäre gewahrt bleibt. Später werden Sie lernen, wie Algorithmen diese strikte Definition tatsächlich erfüllen, indem sie gewisse Grenzen für den Beitrag jedes Einzelnen festlegen und ein behutsam gestaltetes Rauschen (engl. Noise) hinzufügen. In diesem Kapitel wird zunächst die ursprüngliche Definition erläutert und anschließend eine spielerische Implementierung vorgestellt. Es ist nicht unbedingt erforderlich, dass Sie die gesamte hier beschriebene Mathematik verstehen, aber es lohnt sich, wenn Sie sich damit vertraut machen. So können Sie besser nachvollziehen, warum diese Algorithmen funktionieren und datenschutzwahrende Ergebnisse liefern.
Die ursprüngliche Definition von Differential Privacy unterscheidet zwischen zwei Datenbanken D1 und D2, die sich um eine Zeile unterscheiden. Entweder wurde eine Zeile, die eine Person repräsentiert, hinzugefügt, oder es wurde eine Zeile aus der ersten Datenbank entfernt, um die andere Datenbank zu erstellen. Das Ziel ist, dass ein motivierter und informierter Angreifer nicht zu viele Informationen über die Person erhalten kann, deren Daten hinzugefügt oder entfernt wurden, und auch nicht feststellen kann, ob die Person hinzugefügt oder entfernt wurde. Es kommt ein Algorithmus (A) zum Einsatz, der die Antwort auf die Abfrage ausgibt. Dabei soll sichergestellt werden, dass die Antwort die folgende Definition erfüllt:
P[A(D1) ∈ S] ≤ exp(ε) × P[A(D2) ∈ S]
Anders ausgedrückt: Die Wahrscheinlichkeit P, dass ein Angreifer auf Basis der Antwort (A(D1) oder A(D2)) feststellen kann, ob er mit der ersten oder der zweiten Datenbank interagiert, ist auf einen kleinen Wert eε beschränkt. Dabei steht eε für die Menge an Informationen, die ein engagierter Angreifer, der die Antwort auf eine Anfrage oder veröffentlichte Daten untersucht, im schlimmsten Fall erhält.
Im vorliegenden Szenario möchte der Angreifer Informationen sammeln, mit denen er feststellen kann, ob eine Person seiner Vermutung nach im vorliegenden Datensatz (∈S) enthalten ist oder nicht, und seine Vermutung auf der Grundlage der Antwort entsprechend anpassen. Die Aufgabe besteht darin, dieser Möglichkeit Grenzen zu setzen und dabei weiterhin auf Abfragen zu antworten. Das Ziel des Algorithmus ist es, die Menge an Informationen so hoch wie möglich zu halten, aber dennoch einen möglichst hohen Schutz der Daten zu gewährleisten.
Der Algorithmus (A) muss diese Beschränkungen einhalten, ganz gleich, welche Zeile hinzugefügt oder entfernt wurde. Wenn Sie Differential-Privacy-Algorithmen aufbauen, müssen Sie festlegen, welche Abfragen unterstützt werden. Genau hier zeigt sich die Schwierigkeit des Problems. Was ist, wenn es einen Ausreißer gibt? Was ist, wenn die Abfrage mehrere verschiedene Datenbanken mittels Join-Anweisungen miteinander verknüpft? Aus diesem Grund eignen sich speziell auf bestimmte Anwendungsfälle zugeschnittene Algorithmen für komplexe Probleme. Nur wenn Sie Ihre Abfrage präzise formulieren, können Sie herausfinden, welcher Algorithmus das richtige Gleichgewicht zwischen Privacy und Informationsgehalt bietet.
ε definiert die Grenze, bis zu der die Privatsphäre eines Einzelnen gewahrt bleibt. Schauen wir uns eine praktischere Definition an, um Ihnen zu verdeutlichen, wie Sie damit die bestmögliche Annäherung an eine Anonymisierung erreichen können.
Wenn Sie sich die vorherige Gleichung vor Augen führen, leistet das Epsilon eine ganze Menge Arbeit! Für jede Person in Ihrem Datensatz wird das Informationsleck (engl. Information Leakage) durch den Wert eε begrenzt. Doch was bedeutet das im Klartext?
Nehmen wir ein Beispiel aus der Praxis, um es konkreter zu machen. Angenommen, wir arbeiteten beide in demselben Unternehmen und ich möchte die Höhe Ihres Gehalts erfahren. Sie sind eine Neueinsteigerin, und ich habe einen Screenshot von einem firmeninternen Gehalts-Dashboard gemacht, das mir aus Transparenzgründen jeweils das Durchschnittsgehalt für eine Vielzahl von Positionen anzeigt. Nachdem Sie eingestellt wurden, habe ich meinen Screenshot mit dem aktualisierten Dashboard verglichen und versucht, herauszufinden, welche Position Sie innehaben und wie hoch Ihr Gehalt ist. Wenn das Durchschnittsgehalt für eine bestimmte Position um 1.000 Geldeinheiten gestiegen ist und ich eine ungefähre Ahnung davon hatte, wie viele Mitarbeitende diese Position bekleiden, könnte ich diese Information verwenden, um mittels Reverse Engineering Ihr Gehalt zu schätzen.
Ob ich diesen Angriff auf Ihre Privatsphäre erfolgreich durchführen kann, hängt von verschiedenen Faktoren ab: von meiner Annahme, dass das Dashboard aktualisiert wurde, von meiner Kenntnis darüber, wie viele Mitarbeiterinnen und Mitarbeiter die entsprechende Position besetzen, und von meiner Annahme, dass Sie die einzige neue Mitarbeiterin sind. Sollte ich unsicher sein, wie viele Personen diese Position innehaben oder wie genau die angezeigten Werte des Dashboards sind, nehme ich eine Schätzung des möglichen Fehlers mit auf. Anstatt hundertprozentig sicher zu sein, dass Ihr Gehalt einem bestimmten Wert entspricht, kann ich meine Vermutung nunmehr innerhalb eines Wahrscheinlichkeitsbereichs anpassen bzw. Ihr Gehalt als Wahrscheinlichkeitsverteilung betrachten (d.h., dass es mit hoher Wahrscheinlichkeit zwischen den Werten X und Y und mit einer geringen Wahrscheinlichkeit außerhalb dieses Wertebereichs liegt, also höher oder niedriger ist).
Anhand dieses Beispiels können Sie nachvollziehen, wie Sie die Grenzen, die Sie mit der Differential Privacy festlegen, interpretieren können. Es geht darum, zu bestimmen, wie viele Informationen ein Angreifer erlangen kann, und diese innerhalb eines bestimmten Wahrscheinlichkeitsbereichs einzuschränken bzw. zu halten. Wann wäre der Informationsgewinn (engl. Information Gain) »zu groß«? Wäre er zu groß, wenn ich meine anfängliche (A-priori-)Vermutung, dass sich eine bestimmte Person im Datensatz befindet, so anpassen könnte, dass die Wahrscheinlichkeit, richtig zu liegen, von 25 % auf 75 % steigt, nachdem ich eine Antwort gesehen habe?
Mithilfe des Satzes von Bayes können Sie die Definition von Differential Privacy aus der Sicht des Angreifers umformulieren, der versucht, etwas über den zugrunde liegenden Datensatz zu lernen.4 Das A-posteriori- bzw. neue Wissen des Angreifers beruht auf den in der Antwort enthaltenen neuen Informationen. Der Angreifer versucht, auf Basis von Antwort A herauszufinden, ob die Datenbank D, mit der er interagiert, D1 oder D2 ist.
Die ursprüngliche (A-priori-)Vermutung des Angreifers wird durch D = D1 dargestellt, die Informationen aus dem Ergebnis der Abfrage durch A(D) = 0, wobei 0 die tatsächliche Antwort darstellt, die der Angreifer erhält. P[A(D1) = 0] entspricht der Wahrscheinlichkeit, dass das Ergebnis von D1 stammt, und die A-posteriori- bzw. aktualisierte Vermutung entspricht P[D = D1|A(D) = 0], was die Wahrscheinlichkeit darstellt, dass die Datenbank, mit der er interagiert, D1 ist, gegeben (|) der Antwort, die er auf die Anfrage erhalten hat. Mittels des Satzes von Bayes kann die Formel für Differential Privacy umgeschrieben werden, um die neue (A-posteriori-)Vermutung in Abhängigkeit von der vorherigen (A-priori-)Vermutung zu definieren:5
Im vorliegenden binären Fall gilt P[D = D1] = 1 – P[D = D2], da die Wahrscheinlichkeiten in Summe 1 ergeben müssen, da der Angreifer versucht, die Veränderung aus derselben Datenbank abzuleiten. Mit ein wenig Mathematik lässt sich die Gleichung wie folgt umformulieren:6
Mit dieser Gleichung wird der potenzielle Informationsgewinn auf der Grundlage des Epsilons und der anfänglichen Vermutung des Angreifers (die auf Zusatzinformationen basiert) berechnet. Die Wahrscheinlichkeitsgrenzen (bzw. Grenzwerte) werden durch den von Ihnen gewählten Wert für Epsilon festgelegt (im Best-Case-Szenario niedriger, im Worst-Case-Szenario höher) und sind daher von entscheidender Bedeutung für den Betrieb eines auf Differential Privacy basierenden Systems.
Betrachten Sie die Gleichung nun einmal in grafischer Form in Abbildung 2-2, die auf einen einführenden Blogpost von Damien Desfontaines zum Thema Differential Privacy (https://oreil.ly/_4Mhy) zurückgeht.
Abbildung 2-2: Den Informationsgewinn auf Basis von Epsilon schätzen
Damit Sie dieses Diagramm richtig interpretieren können, müssen Sie sich die x-Achse als potenzielle A-priori- bzw. Vorabinformation vorstellen, die man weder vorhersagen noch beeinflussen kann. Die y-Achse gibt an, wie viele Informationen ein Angreifer auf Basis seiner Vorabinformationen in Erfahrung bringen kann. Für jedes in der Legende angegebene Epsilon existieren Grenzwerte für Best- und Worst-Case-Szenarien, die Aufschluss darüber geben, wie viel mehr Gewissheit ein Angreifer auf der Grundlage einer bestimmten Vorabinformation aus einer Abfrageantwort erhalten kann, die Differential Privacy unterliegt. Aus dem Diagramm wird ersichtlich, dass bestimmte Werte von Epsilon zur Folge haben, dass die Antwort recht aufschlussreich ist, und es einem Angreifer möglicherweise erlauben, seine Vermutung schnell und mit einer höheren Gewissheit anzupassen.
Häufig wird empfohlen, einen kleinen Wert für Epsilon zu wählen, der nahe 1 oder sogar darunter liegt. Wie das Beispiel in Abbildung 2-2 zeigt, bleibt der Privacy Loss dadurch selbst im ungünstigsten Fall recht gering. Ein Epsilon von 1 hat beispielsweise zur Folge, dass ein Bayesscher Angreifer, bei dem die Wahrscheinlichkeit seiner anfänglichen Vermutung, richtig zu liegen, 0,5 (bzw. 50 %) beträgt, seine Vermutung infolge der Antwort nur so anpassen kann, dass sich die Wahrscheinlichkeit um maximal plus/minus 0,2 verändert.
Sie können die Veränderung für verschiedene Wahrscheinlichkeitswerte für die anfängliche Vermutung (die auf der im vorherigen Absatz hergeleiteten Gleichung beruhen) im Notebook testen, das sich im Repository des Buchs (https://github.com/kjam/practical-data-privacy) befindet. Aber beachten Sie, dass diese Gleichung das Worst-Case-Szenario berechnet, das zwar unwahrscheinlich, aber dennoch nicht ausgeschlossen ist. Wenn Sie später in diesem Kapitel einen Beispielmechanismus aufbauen, werden Sie lernen, wie man damit umgeht.
Wie können Sie Algorithmen implementieren, die dafür sorgen, dass diese Grenzwerte tatsächlich eingehalten werden? Kurz gesagt, dem Abfrageergebnis wird ein Rauschen (engl. Noise) basierend auf einer spezifischen und kalibrierten Verteilung hinzugefügt, das garantiert, dass das Informationsleck innerhalb dieser Wahrscheinlichkeitsgrenzen liegt. Das Rauschen folgt keiner gleichverteilten Zufallsverteilung, sondern wird aus einer anderen Verteilung gezogen, auf die ich im weiteren Verlauf noch näher eingehen werde. Mithilfe dieser Verteilung, aus der das Rauschen zufällig gezogen wird, können wir festlegen, welche Garantien für den Privacy Loss gelten sollen, und Szenarien für den bestmöglichen (Best Case), den ungünstigsten (Worst Case) und den durchschnittlichen Privacy Loss ermitteln.
Ich hoffe, Sie haben inzwischen ein gewisses Grundverständnis für Differential Privacy entwickeln können. Darauf aufbauend, erfahren Sie nun, was sie garantiert und was nicht (siehe Tabelle 2-1).
Tabelle 2-1: Garantien im Rahmen von Differential Privacy
Differential Privacy ist … |
Differential Privacy ist nicht … |
Ein wahrscheinlichkeitsbasierter Ansatz zur Begrenzung des Informationsgewinns eines Angreifers bei der Veröffentlichung von Daten. |
Ein Ansatz, der garantiert, dass kein Privacy Loss entsteht und dass jede und jeder immer »anonymisiert« ist. |
Eine Möglichkeit, den Privacy Loss einer Person in einem veröffentlichten Datensatz zu quantifizieren und zu verfolgen bzw. zu tracken. |
Ein Zauberstab, der auf jeden Data-Science-Anwendungsfall und dessen potenzielles Datenschutzrisiko angewandt werden kann. |
Die beste Methode, die Experten kennen, um in einem Datensatz enthaltenen Personen eine glaubhafte Abstreitbarkeit (engl. Plausible Deniability) zu bieten. |
Ein Ansatz, bei dem gar keine persönlichen Informationen in Erfahrung gebracht werden können (dies gilt insbesondere für gruppenspezifische Informationen). |
Differential Privacy ist der beste den Fachleuten bekannte Ansatz, um den betroffenen Personen bzw. Teilnehmenden eine glaubhafte Abstreitbarkeit zu bieten und dennoch Datenanalysen durchführen zu können. Die Ergebnisse können sensible Informationen über die Beteiligten offenbaren, basierend auf ihrer Gruppenzugehörigkeit oder den Schlussfolgerungen der Studie. Wenn ich zum Beispiel weiß, dass Sie an einer Studie teilgenommen haben und die Studie gezeigt hat, dass 80 % der Frauen und der Teilnehmenden, die einer geschlechtlichen Minderheit angehören, schlechter bezahlt wurden als Männer, kann ich anhand Ihres Geschlechts darauf schließen, ob Sie fair bezahlt werden oder nicht. Durch Differential Privacy können Sie sich die Möglichkeit bewahren, zu sagen: »Das mag auf viele meiner Kolleginnen und Kollegen zutreffen, aber nicht auf mich im Besonderen.« Das ist Ihre glaubhafte Abstreitbarkeit!
Ein Vorteil dieser glaubhaften Abstreitbarkeit ist die Öffnung der Forschung zu sensiblen Themen wie der gerechten Entlohnung. Differential Privacy kann den Teilnehmenden bessere Datenschutzgarantien und sicherere Möglichkeiten bieten, ihre Daten für die Forschung zur Verfügung zu stellen und gleichzeitig die Offenheit von Daten und die Transparenz in der Forschung weiter zu unterstützen.
Ein weiterer Vorteil von Differential Privacy ist, dass Sie aufhören können, über Zusatzinformationen (engl. Auxiliary Information) zu diskutieren, und stattdessen über Wahrscheinlichkeiten und den Informationsgewinn auf der Grundlage des Mechanismus von Differential Privacy (A) argumentieren können. Das bedeutet, dass Sie nicht versuchen, herauszufinden, was jemand wissen könnte (unmöglich!), sondern stattdessen Ihr probabilistisches Verständnis nutzen, um realistische Datenschutzgarantien anzusetzen. Da Sie immer die maximale Veränderung berechnen können, die eine Veröffentlichung von Daten unter Berücksichtigung von Differential Privacy mit sich bringen würde, müssen Sie nicht explizit jede einzelne potenzielle Zusatzinformation berücksichtigen. Es käme einer Sisyphusarbeit gleich, alle möglichen Zusatzinformationen ermitteln zu wollen – deshalb ist das eine große Erleichterung!
Zusammenarbeit mit Rechtsexperten
Wenn Sie über die Anonymisierung oder die Weitergabe personenbezogener Daten diskutieren, sollten Sie stets im Austausch mit Rechtsexperten stehen. Sie sollten deren Ratschläge folgen und deren Definitionen von Anonymisierung beherzigen.
In Kapitel 8 werden Sie einige bekannte Datenschutzvorschriften kennenlernen, deren Durchsetzung und rechtliche Rahmenbedingungen sich jedoch häufig ändern können und die im Laufe der Zeit oftmals verschärft werden. Die gute Nachricht ist, dass Differential Privacy von vielen Juristinnen und Juristen als »Goldstandard« angesehen wird, da es dem aktuellen Stand der Technik (»State-of-the-Art«) entspricht. Das bedeutet jedoch nicht, dass Sie bei der Beratung einen Freifahrtschein erhalten – Sie müssen immer noch einen Ansatz entwickeln, der Ihren rechtlichen und technischen Stakeholdern das nötige Vertrauen in Ihre Entscheidungen und Begründungen hinsichtlich der Veröffentlichung von Daten gibt.
Damit Sie ein besseres Verständnis dafür bekommen, wie Differential Privacy Ihre Daten tatsächlich schützt, möchte ich Ihnen einige Implementierungsbeispiele vorstellen. Dazu werden Sie zunächst einen realen Anwendungsfall analysieren und dann Ihren eigenen Mechanismus bauen und prüfen, welche Datenschutzgarantien er bietet.
Die Verfassung der Vereinigten Staaten von Amerika sieht alle zehn Jahre eine vollständige Volkszählung vor. Diese Zählung wird für zahlreiche wichtige Entscheidungen herangezogen, unter anderem für die Sitzverteilung im Kongress, die Verteilung von Finanzmitteln durch die Bundesregierung in Washington und die finanzielle Unterstützung einzelstaatlicher Initiativen. Um sicherzustellen, dass alle Personen korrekt, d.h. nur einmal, gezählt werden, sind enorme Anstrengungen erforderlich. Ebenso weitreichend sind die Auswirkungen auf die Privatsphäre.
In der Vergangenheit hat das US-amerikanische Volkszählungsamt (US Census Bureau) eine Reihe von »Verschleierungstechniken« (Obfuskationsmethoden genannt) genutzt, um eine »Anonymisierung« der Ergebnisse zu gewährleisten. Hierzu zählten Kombinationen aus Aggregierungsmethoden und eine Methode namens Shuffling (manchmal auch Scrambling genannt), bei der Haushalte unterschiedlicher Zensusblöcke miteinander gemischt wurden. Da bei diesen Methoden Informationen über einzelne Personen erhalten blieben, konnten persönliche Informationen auf eine Art und Weise nach außen dringen, mit der die damaligen Mitarbeiter des Census Bureau nicht gerechnet hatten.
Das Census Bureau hat mehrere Angriffe auf die Ergebnisse der Volkszählung 2010 durchgeführt, um festzustellen, inwieweit es Außenstehenden möglich ist, Haushalte in den veröffentlichten Daten zu re-identifizieren. Durch eine Reconstruction Attack mithilfe von Kombinationen aus Alter, Geschlecht und ethnischer Zugehörigkeit wurden die Daten in 38 % der Fälle korrekt re-identifiziert, nachdem sie mit externen Datenquellen kombiniert wurden.
Solche Quellen können zum Beispiel Datenbanken mit Verbraucherdaten, Datenbanken mit Wahl- oder Führerscheindaten und auch Datenbanken sein, die Versicherungsdaten umfassen. Die verfügbaren externen Quellen enthielten oft vollständige Angaben zur Identität (Namen, Adressen, Kontaktdaten und andere Detailangaben). Insbesondere bei kleineren Zensusblöcken gelang die Re-Identifizierung mit wesentlich größerem Erfolg. Angesichts der Tatsache, dass unzählige Daten kostenlos oder zu niedrigen Preisen zur Verfügung stehen – oder dass solche Angriffe von einem Unternehmen mit umfassendem Zugang zu Verbraucher- und Haushaltsdaten wie beispielsweise großen E-Commerce-Anbietern durchgeführt werden könnten –, ist diese Art von Angriff nicht nur möglich, sondern wird auch erfolgreich im Rahmen von Direktmarketingkampagnen und gezielter Werbung (engl. Targeted Advertising) eingesetzt.
Doch wie haben diese Reconstruction Attacks konkret funktioniert? Sie haben ein mathematisches Gleichungssystem erstellt und mithilfe eines Solvers potenzielle Kandidaten ermitteln können (weitere Einzelheiten finden Sie in diesem Artikel (https://oreil.ly/AwIuL)). Anschließend konnten sie aus diesen Kandidaten die wahrscheinlichsten ableiten, indem sie diese Informationen mit verschiedenen Verbraucherdatenbanken oder anderen Datensätzen zusammenführten, die infolge eines Datenlecks erworben werden konnten. Speziell in dünn besiedelten Regionen erwies sich der Ansatz als sehr effektiv (bis zu 72 % korrekt), auch wenn die Anzahl falschpositiver Fälle relativ hoch war.7 Wenn Sie nachvollziehen möchten, wie man mithilfe von Solver-Software eine Reconstruction Attack auf einen kleinen Beispieldatensatz durchführen kann, empfehle ich Ihnen, sich das Beispiel-Notebook meiner Kollegen Mitchell Lisle und Menghong Li anzusehen, das Sie im Repository des Buchs (https://github.com/kjam/practical-data-privacy) finden.
Infolgedessen beschloss das US Census Bureau, für den Zensus 2020 Differential Privacy einzusetzen. Die Aufgabe bestand darin, einen Datenworkflow zu konzipieren, der einerseits die Privatsphäre von 330 Millionen Menschen mittels Differential Privacy wahrt und andererseits ausreichend akkurate Ergebnisse für die mit der Volkszählung verbundenen wesentlichen Aufgaben liefert.
Sie verfeinerten ihre Privacy-Parameter anhand von Beispieldaten und den Ergebnissen früherer Erhebungen und fanden so heraus, welches Maß an Rauschen und welche Verteilungen für ihre Anforderungen am besten geeignet waren. Dabei haben sie sich bemüht, die richtige Balance zwischen Datenschutz und Nutzbarkeit der Daten zu finden, bei der die Genauigkeit erhalten und gleichzeitig der grundlegende Schutz der Privatsphäre gewährleistet wird. Sie bauten eine Infrastruktur mit Apache Spark auf, um alle Ergebnisse zu berechnen, zu aggregieren und zu finalisieren. Die Ergebnisse sind auf der Homepage des US Census Bureau (https://oreil.ly/xHWm_) einsehbar.
Einen groben Überblick darüber, wie sie Differential Privacy implementiert haben, finden Sie in Abbildung 2-3. Sie begannen mit den obersten Bevölkerungsebenen (was sie als Top-Down-Ansatz bezeichnen), erstellten Histogramme bzw. skizzierten die Daten und fügten dann ein Rauschen hinzu (Differential-Privacy-Mechanismen für Histogramme), sodass die erstellten Histogramme von einem Rauschen überlagert wurden. Anschließend wiederholten sie diese Prozedur für jeden kleineren regionalen Datensatz und führten eine Überprüfung durch, um sicherzustellen, dass die aggregierten Statistiken auf jeder Ebene gleich waren. Eine interessante Eigenschaft von Daten, die mit Differential Privacy aufbereitet wurden, ist, dass sie beliebig oft nachbearbeitet werden können, ohne dass die Privacy-Garantien beeinträchtigt werden.
Abbildung 2-3: Differential Privacy bei der Volkszählung in den USA
Wenn Sie weitere Einzelheiten erfahren möchten, empfehle ich Ihnen, sich das Video von der Spark-Konferenz des US Census (https://oreil.ly/kmMxV) anzuschauen oder die Blogbeiträge auf der NIST-Homepage zum Thema Differential Privacy (https://oreil.ly/BbSx_) oder auch diese umfassende Folienpräsentation zum ursprünglichen Ansatz (https://oreil.ly/TVKFW) zu lesen.
Ein Kritikpunkt an der Verwendung von Differential Privacy für öffentlich zugängliche Daten ist, dass unterrepräsentierte Gruppen möglicherweise nicht ausreichend erfasst werden. Wenn es in einem bestimmten Zensusblock nur eine Person mit einer bestimmten ethnischen Zugehörigkeit gibt, ist es unwahrscheinlich, dass deren ethnische Zugehörigkeit im Histogramm dieser Wohngegend vertreten ist. Wie wirkt sich dieser Umstand auf die Bereitstellung von Bundesmitteln, die Neuaufteilung von Wahlbezirken usw. aus? Ist es besser, dafür zu sorgen, dass Sie in der Zählung berücksichtigt und dass Ihre persönlichen Daten offengelegt werden?
Derartige Fragen können nicht von einer einzelnen Person beantwortet werden, sondern sollten von der Branche als Ganzes und von jedem von uns als Data Scientist bei der Einführung von Systemen mit Differential Privacy berücksichtigt werden. Sich den Auswirkungen auf in Daten unterrepräsentierte Gruppen bewusst zu sein und sie zu verstehen, wird stets ein ernst zu nehmender Aspekt sein, der bei der Einführung von Privacy-Mechanismen bedacht werden muss. Personen, die unterrepräsentierten Gruppen angehören, sind auch in Bezug auf ihr Privatsphärerisiko stärker gefährdet als andere und haben im täglichen Leben oft weniger Möglichkeiten, ihre Privatsphäre zu schützen. Sie müssen den Zielkonflikt vollständig ausloten zwischen einerseits dem Gewähren von mehr Privatsphäre für unterrepräsentierte Gruppen als Schutz vor Angriffen und Ausbeutung und andererseits der Garantie, dass diese Gruppen nicht aus Ergebnissen verschwinden oder der Nutzen aus Ergebnissen (in diesem Fall für demokratische Prozesse) verloren geht. Ich werde diese Debatte noch in den Kapiteln 4 und 11 vertiefen. Außerdem empfehle ich Ihnen, die Beiträge von Aktivistinnen und Vordenkern in diesem Bereich zu verfolgen, zum Beispiel von Chris Gilliard (https://oreil.ly/n4qy1) und Ruha Benjamin (https://oreil.ly/FAGuV).
Damit Sie die technischen Aspekte des Problems besser verstehen und sicher sein können, dass Sie wohlüberlegte Entscheidungen treffen, werfen wir nun einen Blick darauf, wie Differential Privacy tatsächlich funktioniert!
Die Theorie der Differential Privacy besagt, dass das Hinzufügen von Rauschen zu den Daten und/oder Abfrageergebnissen wirksam sein kann, um den Schutz der Privatsphäre von Individuen zu gewährleisten. Als Data Scientist ist es Ihr Ziel, so wenig Rauschen wie möglich hinzuzufügen und die richtige Balance zwischen dem Informationsgehalt von Daten und dem Schutz der Privatsphäre zu finden. Dazu müssen Sie die Anforderungen der Differential Privacy erfüllen und gleichzeitig herausfinden, wie Sie ein Ergebnis erhalten können, das genau genug ist, um einen Nutzen daraus zu ziehen.
Ein schon früh vorgeschlagener und auch heute noch häufig verwendeter Ansatz zur Maximierung des Informationsgehalts besteht darin, das Rauschen stichprobenartig aus einer Laplace-Verteilung zu ziehen. Auf diese Weise kann garantiert werden, dass die Privacy-Garantie hinsichtlich der Einhaltung von Epsilon mit einem möglichst geringen Maß an Rauschen einhergeht. Warum diese Methode so gut geeignet ist, können Sie im Folgenden anhand ihrer Eigenschaften nachvollziehen.
Die Laplace-Verteilung besitzt, wie Sie in Abbildung 2-4 sehen können, ähnliche Eigenschaften wie die Exponentialverteilung und wird manchmal auch als Doppelexponentialverteilung oder zweiseitige Exponentialverteilung bezeichnet.
Abbildung 2-4: Eine Dichtefunktion der Laplace-Verteilung
Die Wahrscheinlichkeitsdichtefunktion lautet wie folgt:
Hierbei entspricht μ dem Lageparameter bzw. dem Mittelwert. An dieser Stelle deckt sich die Dichtefunktion der Laplace-Verteilung mit der der Exponentialverteilung (und hat dort auch ihren Scheitelpunkt). b entspricht dem Skalen- bzw. Streuungsparameter der Verteilung. In Abbildung 2-5 können Sie nachvollziehen, wie sich die Streuung der Verteilung infolge der Anpassung des Streuungsparameters verändert.
Wenn Sie diese Verteilung als Grundlage für das Rauschen verwenden und μ = 0 wählen, werden Sie feststellen, dass das Rauschen mit großer Wahrscheinlichkeit relativ gering ausfällt. Dadurch bleiben die Informationen gut erhalten. Es besteht jedoch immer die Möglichkeit, dass das Rauschen aus den Rändern der Verteilung gezogen wurde (d.h. weiter von dem Wert 0 entfernt ist), wodurch eine glaubhafte Abstreitbarkeit gewährleistet wird. Bei Betrachtung der Daten sollte dementsprechend nicht erkennbar sein, aus welchem Teil der Verteilung das Rauschen gezogen wurde.
Abbildung 2-5: Laplace-Verteilung: verschiedene Werte für den Streuungsparameter im Vergleich (bei gleichbleibendem Lageparameter)
Werfen wir nun einen Blick darauf, wie dies bei einem auf Differential Policy basierenden Mechanismus funktionieren könnte. Ziel ist es, das Rauschen auf eine Weise hinzuzufügen, die sicherstellt, dass jedes Individuum geschützt wird. Eine Möglichkeit wäre, ein Laplace-verteiltes Rauschen zu Ihrem Abfrageergebnis hinzuzufügen. Ich werde Ihnen jedoch auf einfache Weise zeigen, warum das nicht funktioniert.
Die Codebeispiele in diesem Kapitel stellen relativ simple Implementierungen von Differential-Privacy-Mechanismen dar und sind nicht sicher! Bitte verwenden Sie sie nicht im Rahmen eines realen Anwendungsfalls. Wenn Sie diese Mechanismen von Grund auf neu implementieren, werden Sie ein besseres Verständnis ihrer Funktionsweise entwickeln. In realen Systemen können subtile Fehler auftreten und Privacy-Garantien aushebeln (siehe Kapitel 4 für weitere Informationen). Im Allgemeinen ist die Entwicklung Ihres eigenen Differential-Privacy-Systems vergleichbar mit der Entwicklung Ihrer eigenen Kryptografie – Sie sollten sie nur dann in Angriff nehmen, wenn Sie eine Expertin oder ein Experte darin sind, und auch dann sollten Sie Ihre Arbeit von anderen Experten überprüfen lassen!
Im vorliegenden Beispiel geht es um einen generierten Datensatz, der Alters- und Gehaltsinformationen enthält. Den entsprechenden Code finden Sie im Code-Repository des Buchs auf GitHub (https://github.com/kjam/practical-data-privacy) und können ihn selbst ausführen.
Das Ziel ist, dass die Daten abgefragt werden können, aber dennoch die Privatsphäre geschützt wird. Im weiteren Verlauf des Kapitels werden Sie einen Differential-Privacy-Mechanismus von Grund auf neu entwickeln. Dabei werden Sie einiges Interessantes über diese Mechanismen lernen und unterwegs auf ein paar Probleme stoßen.
Eine simpler Differential-Privacy-Mechanismus mit einem Laplace-verteilten Rauschen könnte in Python wie folgt implementiert werden:
epsilon = 1.1
def naive_laplace_dp_mechanism(value, epsilon):
# Diese Funktion bitte auf keinen Fall verwenden :)
orig_value = value
value = np.random.laplace(value, 1/epsilon) # Gleich mehr dazu!
print("Rauschen: {}".format(value - orig_value))
return value
Im vorliegenden Codebeispiel wird ein Wert stichprobenartig aus einer Laplace-Verteilung, die durch einen bestimmten Wert für Epsilon charakterisiert wird, gezogen. Doch was steckt hinter dieser Berechnung?
np.random.laplace(value, 1/epsilon)
value steht hier für den Wert von μ, der dem Lageparameter der Laplace-Verteilung entspricht und Auskunft darüber gibt, um welchen Wert die Verteilung zentriert ist (Mittelwert). Im vorliegenden Fall legen Sie fest, dass der Lageparameter dem Inputwert gleicht, was bedeutet, dass der gezogene Wert mit sehr großer Wahrscheinlichkeit in der Nähe des Inputwerts liegt (da sich dort der größte Teil der Wahrscheinlichkeitsmasse befindet und die Dichtefunktion um den Wert zentriert ist).
epsilon entspricht dem Wert von Epsilon, der Ihre Garantien im Rahmen der Differential Privacy definiert. Hier haben Sie epsilon=1.1 vorgegeben.
Aus der NumPy-Dokumentation geht hervor, dass die Methode np.random.laplace den Lageparameter (μ) und den Streuungsparameter (b) als Argumente voraussetzt. Dementsprechend haben Sie als Streuungsparameter den Wert 1/epsilon gewählt. Im Folgenden werden wir untersuchen, ob 1/epsilon eine vernünftige Wahl darstellt.
Auf Basis des im Notebook zufällig gezogenen Werts kann ich nun den Mittelwert für das Alter der Personen im Datensatz ermitteln:
laplace_dp_mechanism(np.mean(ages), epsilon)
Als ich die Codezeile ausgeführt hatte, erhielt ich das folgende Ergebnis. Bei Ihnen werden die Werte anders ausfallen:
Rauschen: 1.277692233946226
46.55769223394623
Das »Durchschnittsalter« liegt also bei 46,6 Jahren.
In diesem einfachen Beispiel habe ich explizit eine print-Anweisung hinzugefügt, um zu zeigen, wie stark das hinzugefügte Rauschen ist. Bei einer echten Implementierung würden Sie diese Information niemals einsehen oder direkt aus einem Mechanismus ableiten können, da das sofort gegen die Privacy-Garantien verstößt. Damit die Privatsphäre gewahrt bleibt, müssen Sie Ihren Nutzern und auch sich selbst gegenüber geheim halten, wie viel Rauschen hinzugefügt wurde. Andernfalls würden Sie die Informationen und den probabilistischen Mechanismus, durch den Differential Privacy erst ermöglicht wird, direkt preisgeben. Da niemand genau weiß, wie viel Rauschen hinzugefügt wurde, können Sie die Privatsphäre wahren und den Personen eine glaubhafte Abstreitbarkeit bieten! Da es sich hier um ein rein fiktives Beispiel handelt, das sonst in keinem realen System verwendet werden würde, können Sie sich auch die inneren Abläufe ansehen und so ein besseres Verständnis entwickeln.
Doch kann das so wirklich richtig sein? Das hinzugefügte Rauschen und der Streuungsfaktor 1/epsilon scheinen relativ klein zu sein, um so etwas wie einem Durchschnittsalter über eine größere Bevölkerungsgruppe angemessen Rechnung zu tragen. Aus Abbildung 2-6 können Sie erkennen, dass die überwiegende Mehrheit der Werte für das Rauschen zwischen –2 und 2 liegt.
Abbildung 2-6: Die Auswirkung des Streuungsfaktors »1/epsilon«
Was aber, wenn mein Alter bedeutend niedriger oder höher als das Durchschnittsalter ist? Dadurch könnte sich das berechnete »Durchschnittsalter« (d.h., nachdem Rauschen hinzugefügt wurde) gegebenenfalls so stark verschieben, dass es etwas über mein Alter verrät. Sie können mit dem Beispiel-Notebook aus dem Repository des Buchs experimentieren und herausfinden, wie sich der Mittelwert ändert, wenn Sie Ausreißer hinzufügen, und wie viele Informationen dadurch preisgegeben werden!
Es scheint, als habe ich hier etwas Gefährliches entwickelt. Deshalb sollte die Sensitivität eingehend untersucht werden, um festzustellen, was möglicherweise falsch gelaufen ist.
Als ich 1/epsilon gewählt habe, um die Streuung der Laplace-Verteilung vorzugeben, habe ich auch einen weiteren Parameter festgelegt, nämlich die Sensitivität (engl. Sensitivity) des Differential-Privacy-Mechanismus. Die Sensitivität quantifiziert, wie stark sich das Abfrageergebnis infolge einer Änderung des zugrunde liegenden Datensatzes maximal ändert. Damit die Definition von Differential Privacy zutrifft, müssen Sie hinsichtlich eines Datensatzes sowohl die Situation vor als auch nach dem Hinzufügen oder Entfernen einer Person berücksichtigen und die Änderung der Abfrageergebnisse infolge des Hinzufügens oder Entfernens einer Person entsprechend beschränken.
Mit der Sensitivität wird ermittelt, wie stark sich ein Wert – höchstens – ändern kann, wenn eine Person hinzugefügt oder entfernt wird. Am einfachsten können Sie dies nachvollziehen, wenn Sie sich den Unterschied zwischen einer Zählung und einer Summenbildung vor Augen führen (gute Nachrichten, denn Sie brauchen beides, um einen Durchschnitt zu berechnen!).
Angenommen, ich bin 81 Jahre alt. Wenn ich dem Datensatz hinzugefügt werde und Sie anschließend eine Abfrage vornehmen, um die Anzahl der Mitarbeitenden, die älter als 40 Jahre sind, zu ermitteln, hat sich dieser Wert um 1 erhöht. Wenn Sie jedoch das Durchschnittsalter berechnen, bewirke ich, dass sich der Teil der Durchschnittsermittlung, in dem die Summe gebildet wird, um 81 verändert (d.h. der Zähler, da Durchschnitt = Summe / Anzahl)! Um einen angemessenen Schutz der Privatsphäre bei der Berechnung des Durchschnittsalters zu gewährleisten, müssen Sie daher herausfinden, wie hoch die Sensitivität bei der Summenbildung ausfällt.
Bei einigen Abfragen (wie z.B. einer Summenbildung) gibt es mathematisch gesehen keine Grenzen für den Sensitivitätswert, d.h., es gibt weder eine Ober- noch eine Untergrenze für den individuellen Beitrag. Genau wie im Beispiel des Dashboards würde die Gesamtsumme aller Gehälter umfangreiche Informationen preisgeben, sobald ein weiteres Gehalt hinzuaddiert wird. Wenn den Daten kein beträchtliches Ausmaß an Rauschen hinzugefügt wird, kann ich das Gehalt einer neuen bzw. ehemaligen Mitarbeiterin leicht abschätzen! Dazu muss ich lediglich wissen, wie hoch die ursprüngliche Gehaltssumme war, und herausfinden, wie sie sich verändert hat, nachdem die Person eingestellt wurde bzw. das Unternehmen verlassen hat.
Ein weiteres gutes Beispiel dafür, wann der Sensitivität keine Grenzen gesetzt sind, ist die Abfrage des Mindest- oder Höchstwerts. Es mag zwar unwahrscheinlich sein, dass sich das Abfrageergebnis ändert, wenn Sie einen beliebigen Nutzer hinzufügen oder entfernen. Doch wenn dies der Fall ist, haben Sie – auch unabhängig vom Ausmaß des hinzugefügten Rauschens – wieder eine sehr präzise Schätzung des zugrunde liegenden Werts, was einen schwerwiegenden Eingriff in die Privatsphäre der betreffenden Person bedeuten würde.
Wenn eine Abfrage eine unbegrenzte Sensitivität hat, müssen Sie anders vorgehen als bei Abfragen, deren Sensitivität Sie ermitteln können. Eine Lösung ist, Abfragen mit unbegrenzter Sensitivität nicht zu beantworten bzw. zuzulassen. Eine andere Möglichkeit besteht darin, Grenzwerte festzulegen und die zulässigen Antworten künstlich auf einen bestimmten Wertebereich zu begrenzen. Dabei wird angenommen, dass sich keine Person außerhalb dieser Grenzwerte befindet. Falls doch, wird ihre Existenz in der Antwort auf die Abfrage kaschiert, indem ihr Wert so geändert wird, dass er innerhalb der Grenzwerte liegt.
Bei einigen Abfragen ist die Sensitivität ziemlich eindeutig und begrenzt. Wenn Sie beispielsweise die Anzahl der Nutzerinnen und Nutzer zählen möchten, sollte jeder Nutzer nur einmal gezählt werden. Er kann das Ergebnis dementsprechend nur um 1 beeinflussen – daher ist die Sensitivität 1, unabhängig davon, wer die Person ist. Wenn Sie ein Bewertungssystem erstellen und jeder Nutzer seine Bewertung nur auf einer Skala von 0 bis 5 vornehmen kann, beträgt die Sensitivität einer einzelnen Bewertung 5. Ähnlich wie bei der künstlichen Begrenzung des Höchst- und Mindestbeitrags eines jeden Nutzers gibt es gewisse Anwendungsfälle, die sich sehr gut eignen, um die Sensitivität möglichst genau zu bestimmen.
Wenn Sie die Sensitivität analysieren, sollten Sie auch mögliche Fehler im Blick haben. Legen Sie eine bestimmte Verteilung für das Rauschen zugrunde, haben Sie die Möglichkeit, den Einfluss von Fehlern beim Einfügen abzuschätzen und zu untersuchen, wie sich dies auf den relativen Fehler auswirkt, d.h. den Gesamtfehler geteilt durch den tatsächlichen Wert. Sie können eine Schätzung des Fehlers auf der Grundlage der gewählten Verteilung und ihrer Streuung vornehmen und plausible Ergebnisse modellieren, indem Sie die Verteilung unter Verwendung ähnlicher nicht privater Datenquellen reproduzieren und damit experimentieren. Auf diese Weise können Sie sicherstellen, dass Sie die Auswirkungen eines Fehlers auf die spätere Analyse richtig einschätzen können. Im Code-Repository des Buchs finden Sie einige Experimente, die diesen Ansatz veranschaulichen.
Wie sollten Sie vor dem Hintergrund dieser Überlegungen die Abfrage zur Durchschnittsbildung anpassen, um Differential Privacy tatsächlich angemessen anzuwenden? Wie wirkt sich die Durchschnittsbildung auf die Sensitivität aus? Sie müssen Grenzwerte für das Alter festlegen, damit Sie für die Summenbildung einen akzeptablen Wert für die Sensitivität erhalten.
Die Auswahl sinnvoller Grenzwerte hängt von der Altersstruktur im Datensatz ab, was wiederum eine sensible Information darstellen kann. Wie lässt sich dieses Problem lösen?
Im vorliegenden Fall bezieht sich die Datenbank auf die Belegschaft eines Unternehmens. Daher kann es sinnvoll sein, das Alter auf einen Bereich zwischen 20 und 70 Jahren zu beschränken. Wenn Sie über weitere nützliche Informationen verfügen – z.B. wie der Einstellungsprozess abläuft oder wie hoch das übliche Renteneintrittsalter in der Branche ist –, können Sie diese bei der Berechnung dieser Werte verwenden und die Grenzen entsprechend niedriger oder höher ansetzen. Beachten Sie, dass die Sensitivität auch durch die Grenzwerte selbst beeinflusst wird und damit das Ausmaß des Rauschens. Je weiter die Grenzwerte auseinanderliegen, desto mehr Rauschen wird erzeugt. Die Entscheidung, die Sie hier treffen, ist sehr wichtig, da Sie entscheiden, inwieweit Sie den Schutz der Privatsphäre gegen den Informationsgehalt der Daten abwägen.
Wenn Sie sich für eine Altersspanne zwischen 20 und 70 Jahren entscheiden, können Sie die Daten wie folgt eingrenzen:
def filter_bounds(value, lower_bound, upper_bound):
if value < lower_bound:
return lower_bound
elif value > upper_bound:
return upper_bound
return value
bounded_ages = [filter_bounds(age, 20, 70) for age in ages]
Nun können Sie beantworten, wie hoch die Sensitivität der beiden vorherigen Abfragen ist! Die Zählung (bzw. Ermittlung der Anzahl) weist eine Sensitivität von 1 auf, und die der Summenbildung beträgt jetzt 50. Dementsprechend müssen Sie im Rahmen Ihrer Differential-Privacy-Implementierung immer dafür Sorge tragen, dass Sie die -Funktion anwenden, wenn neue Personen in den Datensatz aufgenommen werden.
Allerdings werden nun zwei Berechnungen vorgenommen und nicht nur eine. Da bei Ihrer Differential-Privacy-Implementierung das gesamte Epsilon für eine Abfrage verwendet wird, müssen Sie Ihren Ansatz so anpassen, dass Sie mehr als eine Abfrage verarbeiten können. Dazu ist es erforderlich, sowohl den Privacy Loss als auch das Epsilon über mehrere Abfragen hinweg nachzuverfolgen. Hierfür sind sogenannte Privacy Budgets geeignet, auf die ich im Folgenden näher eingehe.
Differential Privacy wurde entwickelt, damit Fragen auf Basis von Daten beantwortet werden können und dabei gleichzeitig der Schutz der Privatsphäre der betroffenen Individuen gewährleistet wird. Bisher habe ich Ihnen jedoch nur gezeigt, wie Sie eine einzelne Frage mittels eines simplen Differential-Privacy-Mechanismus beantworten können. Was aber, wenn Sie mehrere Fragen zu den Daten beantworten möchten? Wie verhält es sich, wenn Sie die Datenbank mithilfe von Differential Privacy für externe Abfragen freigeben möchten? Differential Privacy erlaubt es Ihnen, den Privacy Loss nachzuverfolgen und zu quantifizieren, aber wie?
Eine bemerkenswerte Eigenschaft von Differential Privacy ist, dass der Wert von Epsilon (ε) dem Privacy Loss für eine bestimmte Antwort entspricht. Der Wert ist für jede Anfrage individuell, aber dennoch zusammensetzbar, das heißt, wenn Sie zwei Anfragen beantworten und den gesamten Privacy Loss ermitteln möchten, müssen Sie lediglich deren Epsilon-Werte addieren!
Was bedeutet das für die Praxis?
Sehen wir uns einmal an, wie das funktionieren könnte, indem wir nun das Durchschnittsalter ermitteln.
Zur Berechnung des Altersdurchschnitts benötigen Sie sowohl die Gesamtsumme des Alters aller Personen als auch die Gesamtanzahl der Personen (Zählung), die Sie jeweils unter Berücksichtigung von Differential Privacy ermitteln müssen. Wie bereits erläutert, kann sich die Anzahl (Zählung) höchstens um 1 ändern, wenn Sie eine Zeile hinzufügen oder löschen. Dementsprechend können Sie die Sensitivität auf 1 festlegen.
Als Nächstes müssen Sie die Summe berechnen. Sie haben bereits eine Technik namens Clamping kennengelernt, als Sie die Funktion filter_bounds angewandt haben, um die Summenbildung auf eine adäquate Weise vorzunehmen. Mithilfe von Clamping können Sie eine künstliche Unter- und Obergrenze für die Werte definieren und dadurch die Sensitivität auf deterministische Weise begrenzen.
Sie könnten Ihr Epsilon ganz einfach auf beide Abfragen aufteilen, d.h., jedes Epsilon entspräche einem Wert von 0,5. Nun sind Sie so weit, dass Sie den Durchschnitt mit Differential Privacy berechnen können. Experimentieren Sie in den Notebooks im Code-Repository des Buchs, um verschiedene Ansätze auszuprobieren.
Sie müssen auch Ihren Differential-Privacy-Mechanismus dahin gehend anpassen, dass er die Sensitivität einbezieht. Der Streuungsfaktor 1/epsilon wird jetzt zu sen sitivity/epsilon, was verdeutlicht, warum 1 eine schlechte Wahl im Rahmen der Durchschnittsbildung war! Abfragen, die eine höhere Sensitivität aufweisen, weisen auch eine größere Streuung auf, was wiederum bedeutet, dass ein größeres Ausmaß an Rauschen erforderlich ist, um den Schutz der Privatsphäre zu gewährleisten (siehe Abbildung 2-5). Klasse!
def laplace_dp_mechanism(value, epsilon, sensitivity):
# Diese Funktion bitte auf keinen Fall verwenden :)
orig_value = value
value = np.random.laplace(value, sensitivity/epsilon)
# Hier wird deutlich, warum 1 eine schlechte Wahl war!
print("Rauschen: {}".format(value - orig_value))
return value
epsilon_for_sum = 0.5
epsilon_for_count = 0.5
summed_ages = laplace_dp_mechanism(np.sum(bounded_ages), epsilon_for_sum, sensitivity=50)
count_ages = laplace_dp_mechanism(len(bounded_ages), epsilon_for_count, sensitivity=1)
summed_ages / count_ages
Als ich diesen Code ausgeführt habe, erhielt ich Folgendes:
Rauschen: -53.24175804583501
Rauschen: 1.928454653399541
43.88135047434459
Der tatsächliche Mittelwert des ursprünglichen Altersdatensatzes, bei dem das Alter nicht eingegrenzt war, beträgt 45,28. Im Ergebnis liegt also ein relativer Fehler (hinzugefügtes Rauschen geteilt durch den tatsächlichen Mittelwert des unverfälschten Datensatzes) in Höhe von etwa –0,03 vor. Je nachdem, wofür Sie das Ergebnis verwenden oder ob es sich auf verwandte Abfragen auswirkt, kann der Fehler als akzeptabel oder auch als zu groß angesehen werden.
Im Repository des Buchs (https://github.com/kjam/practical-data-privacy) finden Sie noch weitere einfach gehaltene Beispiele zur Anwendung von Differential Privacy! Darüber hinaus gibt es eine Reihe zusätzlicher mit dem Inhalt des Kapitels im Zusammenhang stehender Berechnungen und Erklärungen sowie einige Notebooks, die Ihnen als Einstieg zu anderen verwandten Konzepten dienen können (z.B. lokale Differential Privacy und Debiasing von Differential-Privacy-Ergebnissen). Zudem stehen Ihnen zu den meisten Kapiteln Notebooks zur Verfügung, die Sie im weiteren Lernprozess unterstützen!
Eben haben Sie Ihr Budget auf beide Abfragen im gleichem Verhältnis aufgeteilt. Stattdessen könnten Sie das Budget wie jede andere begrenzte Ressource betrachten und es entsprechend aufteilen. Beispielsweise könnten Sie mehr Budget für Abfragen bereitstellen, die für Ihr Endergebnis bzw. das, was Sie berechnen wollen, wichtiger sind.
Am besten machen Sie sich nun mithilfe von Beispieldaten selbst ein Bild davon, wie sich diese Budgetierung auswirkt. Nutzen Sie hierfür die Beispiele im Repository und nehmen Sie einen beliebigen Datensatz zur Hand, auf den Sie Zugriff haben. Wie verhalten sich Ihre Daten, wenn Sie diese Mechanismen anwenden? Was funktioniert gut, und was sollten Sie überdenken?
Sie fragen sich nun vielleicht, wie Sie bei der Implementierung von Differential Privacy die Budgets nachverfolgen können. Die gute Nachricht ist, dass Sie eine Bibliothek verwenden können, die dies automatisch für Sie erledigt und Ihnen zudem verschiedene Optionen bietet, mit denen Sie Fehler auf ein Minimum reduzieren können. Das Wichtigste ist jedoch, dass Sie jetzt wissen, wie Sie Ihr begrenztes Budget aufteilen und bestmöglich nutzen können. In Kapitel 3 werden Sie eine Bibliothek verwenden, die genau das tut!
Wenn Sie über die Einrichtung von Budgets, die Nachverfolgung und das Deployment von Differential-Privacy-Systemen nachdenken, fragen Sie sich vielleicht auch, ob es neben der Laplace-Verteilung noch weitere Verteilungen gibt, die eine Differential Privacy gewährleisten können. Als Data Scientist ziehen Sie es vielleicht vor, mit etwas Vertrauterem als der Laplace-Verteilung zu arbeiten – etwa mit der Normalverteilung.
Die gute Nachricht ist: Sie können eine Normalverteilung (bzw. gaußsche Verteilung) verwenden, um »Differential-Privacy-Rauschen« mit Differential-Privacy-Garantien zu erzeugen. Auf diese Weise kommen Ihnen alle Vorteile, die Sie bei der Verwendung einer Normalverteilung haben, zugute. Außerdem profitieren Sie davon, Ergebnisse besser erklären und Abfrageergebnisse mithilfe vertrauter Tools und Mechanismen von dem hinzugefügten Rauschen bereinigen (De-Bias) zu können.
Zur Nutzung von gaußschem Rauschen ist es zunächst erforderlich, Differential Privacy weniger strikt zu definieren. Bei dieser Definition wird der ursprünglichen Definition ein kleiner Wert, Delta, hinzugefügt, wodurch es möglich wird, die Wahrscheinlichkeitsgrenzen zu lockern. Durch das Delta wird ein unwahrscheinliches Ergebnis berücksichtigt, das ein »katastrophales Versagen« (engl. Catastrophic Failure) bzw. ein sogenanntes Distinctive Event bedeuten kann.8
Pr[A(D1) ∈ S] ≤ exp(ε) × Pr[A(D2) ∈ S] + δ
Welchen Wert sollten Sie vernünftigerweise für Delta (Fehlerspanne) wählen? Angenommen, Ihr Wert für Delta ist so ausgestaltet, dass er es Ihrer Implementierung erlaubt, im Grunde alle Informationen bezüglich einer geringen Anzahl an Zeilen freizugeben, solange der Wert von Delta nicht überstiegen wird – und zwar ohne dass Sie zusätzliches Rauschen hinzufügen. Angenommen, Sie haben eine Datenbank mit einer Million Zeilen vorliegen und geben eine einzelne Zeile im »Klartext« frei (d.h. ohne jegliche Änderungen bzw. Anpassungen). Wenn der Wert Ihres Deltas 
oder größer ist, können Sie im vorliegenden Fall also von Differential Privacy sprechen (nur ein Scherz, bitte nicht!). Deshalb wird empfohlen, den Wert von Delta kryptografisch klein zu wählen bzw. mindestens kleiner als 1/Gesamtanzahl der Zeilen, damit ein derartiges unerwünschtes Verhalten ausgeschlossen ist.
Wie funktioniert diese Lockerung und die Verwendung von gaußschem Rauschen in der Praxis? Wenn Sie mit einem gaußschen Mechanismus arbeiten, müssen Sie zunächst die Differential-Privacy-Garantien festlegen.
Die folgende Definition für einen gaußschen Mechanismus gilt nur für Epsilon < 1 und fügt mehr Rauschen hinzu, als Sie eigentlich benötigen bzw. möchten, da sie auf dem ursprünglichen Forschungsbeitrag basiert. Der empfohlene Weg, um gaußsches Rauschen hinzuzufügen, ist »analytisches« gaußsches Rauschen, das in dem Artikel von Balle und Wang, »Improving the Gaussian Mechanism for Differential Privacy: Analytical Calibration and Optimal Denoising« (International Conference on Machine Learning, 2018), erläutert wird. Es gibt auch einen Blogbeitrag, in dem einige der Eigenschaften beschrieben werden (https://oreil.ly/g5jhq). Da dieser Mechanismus eine kompliziertere Formel beinhaltet, werden Sie im Folgenden eine vereinfachte Version verwenden, um zunächst ein Gefühl für den Mechanismus zu bekommen. In Kapitel 3 werden Sie dann auf eine Bibliothek zurückgreifen, mit der Sie gaußsches Rauschen auch auf effiziente Weise hinzufügen können.
Ein gaußscher Mechanismus (ε, δ) garantiert Differential Privacy, wenn er die folgende Bedingung erfüllt und der Wert von Epsilon < 1 ist:
F(x) = f(x) + N(σ2)
wobei
N(σ2) entspricht einer Normalverteilung mit einem Mittelwert von 0 mit einer Varianz von σ2. Hierbei steht s für die Sensitivität.
Beachten Sie, dass Sie jetzt auch Delta berücksichtigen müssen, was bei der Laplace-Verteilung nicht der Fall war. Das liegt daran, dass das Laplace-verteilte Rauschen die sogenannte (ε, 0)-Differential-Privacy erfüllt, bei der Delta gleich 0 ist – bei der Normalverteilung ist dies hingegen nicht der Fall.
Sie wissen jetzt, dass der Wert von Delta theoretisch »kryptografisch klein« sein sollte (was als ≤ 2–30 definiert ist). Da Sie einen Differential-Privacy-Mechanismus und keine trickreiche Freigabe einer Zeile vornehmen, können Sie diese Vorgabe etwas lockern. Eine gute Wahl für den Wert von Delta liegt irgendwo zwischen 1/n, wobei n der Anzahl der Zeilen entspricht, und 2–30 ≈ 9 × 10–10, wobei zu beachten ist, dass Ihnen ein kleinerer Wert stets ein höheres Maß an Schutz bzw. eine höhere Garantie bietet.
Legen wir nun einen Wert fest, mit dem Sie für Ihren Alters- und Gehaltsdatensatz beginnen. δ =10–5 scheint ein geeigneter Wert zu sein, da er zwischen den empfohlenen Grenzwerten liegt. Mit dem gewählten Wert für Delta können Sie nun einen auf der Normalverteilung basierenden Differential-Privacy-Mechanismus berechnen und anwenden und Ihre Ergebnisse mit denen des Laplace-Mechanismus vergleichen. Doch zunächst sollten wir uns noch genauer damit befassen, wie sich diese Mechanismen auf den von Ihnen hinzugefügten Fehler auswirken.
Bevor Sie Laplace-verteiltes und gaußsches Rauschen miteinander vergleichen und beurteilen können, sollten Sie sich noch einmal die Grundlagen zur Sensitivität vergegenwärtigen. Beiden Mechanismen liegen unterschiedliche Konzepte von Sensitivität zugrunde. Bisher haben Sie Sensitivität so kennengelernt, dass sie aussagt, in welchem Ausmaß eine einzelne Person einen bestimmten Wert beeinflussen kann.
Es gibt jedoch noch eine andere Variante von Sensitivität, die Sie bei der Verwendung von Differential Privacy berücksichtigen müssen. Es geht nicht nur darum, wie stark eine Person einen Wert beeinflussen kann. Es geht vielmehr darum, wie oft und wie stark eine Person Werte in den von Ihnen veröffentlichten Daten bzw. den von Ihnen beantworteten Abfragen beeinflussen kann.
Verdeutlichen wir das anhand eines konkreten Beispiels. Sie arbeiten mit der Personalabteilung zusammen, um gemeinsam zu analysieren, ob es in bestimmten Teams oder Abteilungen Probleme gibt, die die Führungsebene angehen muss. Ihr Ziel ist es, die Personen zu schützen, die zu diesen Problemen beitragen. Die Führungsebene möchte die Problemfelder im Auge behalten und entsprechende Prioritäten setzen. Deshalb sollen Sie die durchschnittliche Anzahl an Beschwerden pro Team und/oder Abteilung und die durchschnittliche Zeit, die bis zur Klärung dieser Beschwerden vergeht, ermitteln.
Zunächst müssen Sie eine Ober- und eine Untergrenze (Clamping Bounds) festlegen, da die Anzahl der Beschwerden pro Monat 0 bis unendlich sein kann. Sie entscheiden sich für eine Spanne von 0 bis 10. Außerdem möchten Sie die durchschnittliche Zeit, die bis zur Klärung dieser Beschwerden vergeht, in eine Spanne von 0 bis 5 einteilen (z.B. könnte 0 für ein Ticket stehen, das noch am selben Tag von einer Mitarbeiterin in der Personalabteilung abgearbeitet wurde, die es entgegengenommen hat, und 5 für ein Ticket, das nach 30 Tagen noch nicht erledigt wurde). Dadurch können länger andauernde Probleme hervorgehoben und möglichen False Positives, bei denen jemand die Beschwerde falsch eingestuft haben könnte, weniger Bedeutung zugemessen werden.
Bezogen auf Ihre bisherige Definition von Sensitivität bedeutet dies, dass Sie hinsichtlich der von Ihnen berechneten Statistiken zu den Beschwerden vermutlich eine Sensitivität von 5 × 10 benötigen, damit Sie eine Person angemessen schützen können, sollte diese mehrere Beschwerden eingereicht haben, die lange ungelöst bleiben.
Anders ausgedrückt, bedeutet dies, dass das Rauschen und der Fehler sich proportional zur Anzahl der Statistiken verhalten, die eine einzelne Person beeinflussen kann. Um die Korrelation zwischen mehreren Features (bzw. hier Statistiken) zu berechnen, müssten Sie, wenn eine einzelne Person mehrere Datenpunkte beitragen kann, jedes Mal das Worst-Case-Szenario bzw. die größtmögliche Sensitivität in Betracht ziehen.
Es gibt jedoch Methoden, die Ihnen dazu verhelfen, dass Ihr Fehler kleiner ausfällt! Stellen Sie sich hierzu einen mehrdimensionalen Vektorraum vor. Ihnen liegt die anfängliche »unverrauschte« Vektordarstellung des wahren Ergebnisses aller Abfragen vor. Um einen passenden Differential-Privacy-Mechanismus hinzuzufügen, müssen Sie eine angemessene Sensitivität ansetzen. Wie können Sie in diesem mehrdimensionalen Raum so viel Rauschen hinzufügen, dass dieses Rauschen zur Sensitivität der einzelnen Abfragen passt und gleichzeitig so gering wie möglich gehalten wird?
Bei Laplace-Mechanismen verwendet man zur Optimierung und Minimierung des Fehlers und des Rauschens die Manhattan-Distanz bzw. L1-Norm (engl. Manhattan Distance). Bei gaußschen Mechanismen kann man hingegen den euklidischen Abstand (engl. Euclidean Distance) nutzen, da das Rauschen, das hinzugefügt wird, das gleiche ist, das man bei einem normalverteilten Fehler erwarten würden. Bei gaußschem Rauschen ist der Fehler normalverteilt und lässt sich am besten mit dem euklidischen Abstand bzw. der L2-Norm berücksichtigen.
Um die Manhattan-Distanz bzw. die L1-Norm im Vektorraum zu ermitteln, muss folgende Berechnung vorgenommen werden:
Um den euklidischen Abstand bzw. die L2-Norm im Vektorraum zu ermitteln, wiederum die folgende Berechnung:
Diese Unterschiede in Bezug auf Fehler und Rauschen lassen sich im zweidimensionalen Raum anhand eines Vergleichs der L1- und L2-Norm von zwei Punkten veranschaulichen (siehe Abbildung 2-7).
Abbildung 2-7: Vergleich zwischen L1- und L2-Norm
In Abbildung 2-7 wird deutlich, warum die Methoden ihre Namen haben. Bei der Manhattan-Distanz wird die Distanz wie Straßen in Manhattan, das ein rasterförmiges Stadtdesign hat, behandelt. Beim euklidischen Abstand wird der kürzeste Abstand zwischen zwei Punkten (hier die Hypotenuse) mittels geometrischer Methoden ermittelt.
Um zu dem konkreten Beispiel für das Hinzufügen von Rauschen zu den Beschwerden zurückzukehren: Wenn Sie Laplace-verteiltes Rauschen verwenden und eine Mitarbeiterin 10 oder mehr Beschwerden einreicht, die unerledigt bleiben, müssen Sie für ihr Rauschen die Manhattan-Distanz als Streuungsfaktor verwenden. Das bedeutet, dass Sie für das Rauschen 5 × 10 als Streuungsfaktor einsetzen. Wenn Sie hingegen gaußsches Rauschen verwenden, nutzen als Streuungsfaktor 5 × 
. An dieser Stelle wird deutlich, wie wichtig es ist, zu verstehen, wie eine Nutzerin bzw. ein Nutzer zu mehreren Statistiken beiträgt!
Als Faustregel können Sie sich merken, dass sich die Streuung von Laplace-verteiltem Rauschen proportional zur Anzahl der Statistiken, die eine Person beeinflussen kann (k), verhält, während gaußsches Rauschen mit der Quadratwurzel aus k skaliert. Wenn also die Sensitivität hoch ist und eine Person eine ganze Reihe von Ergebnissen beeinflussen kann, ist gaußsches Rauschen besser geeignet.
Was bedeutet das in der Praxis? Fügen wir dem Datensatz mit den Gehalts- und Altersangaben etwas Rauschen hinzu und sehen wir uns die Ergebnisse an. Zur Berechnung des Mittelwerts verwenden Sie jetzt gaußsches anstelle von Laplace-verteiltem Rauschen. Diese einfache Implementierung beinhaltet nicht die Optimierungen, die Sie mit dem euklidischen Abstand vornehmen können, da es sich um ein Beispiel handelt, das nur Anschauungszwecken dient und nicht in einem realen Anwendungsfall verwendet werden sollte. In dem Notebook, das sich mit gaußschem Rauschen befasst, finden Sie einen Vergleich, mit dem Sie Ihr Verständnis spielerisch vertiefen können. Darüber hinaus werden Sie in Kapitel 3 eine Bibliothek verwenden, in der die neuesten Techniken bereits implementiert sind:
sum_epsilon = 0.79
delta=10**-5
def gaussian_dp_mechanism(value, epsilon, sensitivity=sensitivity):
# Bitte verwenden Sie diese Funktion nicht in realen Anwendungs-
# fällen - sie ist anfällig gegenüber bekannten Angriffen.
# Verwenden Sie stattdessen eine anerkannte und geprüfte
# Open-Source-Bibliothek für Differential Privacy. orig_value = value
gauss_scale = sqrt((2*sensitivity**2*log(1.25/delta))/epsilon**2)
value = np.random.normal(value, gauss_scale)
print("Rauschen: {}".format(value - orig_value))
return value
summed_ages = gaussian_dp_mechanism(np.sum(bounded_ages), sum_epsilon, sensitivity=50)
count_ages = gaussian_dp_mechanism(len(bounded_ages), count_epsilon, sensitivity=1)
mean_age = summed_ages / count_ages
mean_age
Wenn ich den Code ausführe, um zu sehen, wie viel Rauschen hinzugefügt wird, erhalte ich das folgende Ergebnis:
Rauschen: 332.0995166206894
Rauschen: 25.527328637215277
38.7015287377063
Das tatsächliche Durchschnittsalter für den ursprünglichen Datensatz beträgt 45,28, woraus sich ein relativer Fehler von etwa 0,15 ergibt. Das ist etwa das Fünffache des relativen Fehlers des Laplace-Mechanismus, allerdings unter Verwendung eines kleineren Werts für Epsilon (0,99 gegenüber 1,1). Es ist schwierig, einen Eins-zu-eins-Vergleich anzustellen, da Sie die einfachsten Versionen dieser Mechanismen implementiert haben und es Optimierungen gibt, die Sie noch nicht vorgenommen haben. Außerdem ändert sich das Rauschen jedes Mal, wenn Sie das Experiment durchführen (was so beabsichtigt ist!). Abgesehen davon hatten Sie das Vergnügen, sich von Grund auf mit den verschiedenen Stellschrauben vertraut zu machen, an denen man bei Mechanismen zur Gewährleistung von Differential Privacy drehen kann.
Sie sollten nun über eine fundierte Entscheidungsgrundlage verfügen, um die richtigen Entscheidungen treffen zu können. Es würde den Rahmen sprengen, alle Methoden zu behandeln, die Sie verwenden könnten, aber Sie haben ein gutes Grundlagenwissen, um zu beurteilen, inwieweit Sensitivität, Rauschen und Fehler miteinander zusammenhängen.
Wenn Sie Daten verwenden, auf die Differential Privacy angewandt wurde, verwenden Sie im Wesentlichen Daten, die einen höheren Fehler aufweisen. Sie sollten sich Gedanken darüber machen, wie Sie die Ergebnisse, die Sie erhalten, intelligent nutzen können. Was können Sie tun, um die durch Differential Privacy verursachten Fehler zu reduzieren?
Wie sich das Rauschen wieder verringern lässt (engl. Noise Reduction), ist ein seit Langem bestehendes Forschungsgebiet für Statistiker und Data Scientists gleichermaßen. Jüngste Innovationen wie Diffuser und Stable Diffusion (https://oreil.ly/UYZX3) haben Techniken der Rauschreduzierung auf neue Probleme angewandt, sodass »verrauschte« Bilder oder Audiodaten zu realistischen Inhalten »entrauscht« werden können. Es wäre interessant, diese Methoden auf Ergebnisse anwendbar zu machen, bei denen Differential Privacy zur Anwendung kam, d.h. zu lernen, wie das im Rahmen der Differential Privacy hinzugefügte Rauschen vorhergesagt werden kann und wie es entfernt werden kann. Da Sie niemals eine hundertprozentige Genauigkeit erreichen können – es sei denn, der Mechanismus ist falsch implementiert –, könnten Sie die Ergebnisse ohne Bedenken »entrauschen« und dabei die Privacy-Garantien aufrechterhalten, da sich die Gewissheit des Angreifers nicht ändert (d.h., beim Debiasing des Rauschens kann weder garantiert werden, dass die Ausgabe dem ursprünglichen Wert entspricht, noch kann dies jemand beweisen, es sei denn, er inspiziert den Mechanismus zur Laufzeit, was strengstens untersagt ist).
Sie könnten auch mithilfe des bayesschen Denkens (engl. Bayesian Reasoning) Annahmen über die Abfragen und deren tatsächliche Ergebnisse aufstellen. Um diese Annahmen zu modellieren, könnten Sie eine bayessche Bibliothek wie PyMC3 verwenden und eine Reihe von Experimenten durchführen. Wenn Sie Ihre A-priori-Wahrscheinlichkeiten richtig bestimmen, dokumentieren und modellieren, können Sie sehen, ob sich Ihre Experimente mit dem Verhalten der Datenquelle, die Differential Privacy unterliegt, decken. Scheint Ihr Modell falsch zu sein, bedeutet das wahrscheinlich, dass Sie Ihre A-priori-Wahrscheinlichkeiten anpassen müssen!
Ein Grund, gaußsches Rauschen zu bevorzugen, ist die Tatsache, dass bei wissenschaftlichen Untersuchungen häufig von normalverteilten Fehlern ausgegangen wird. Welche Fehlernormalisierung oder -korrektur Sie auch immer in Ihrem anfänglichen Design und Ihrer Argumentation berücksichtigt haben – sie funktioniert in der Regel gut, wenn Sie gaußsches Rauschen verwenden.
In diesem Kapitel habe ich die Begriffe Rauschen und Fehler gelegentlich synonym verwendet. Das war durchaus Absicht. Ich wollte damit verdeutlichen, dass Daten bereits einen gewissen Anteil an Fehlern und Rauschen enthalten. Es gibt keine »Ground Truth« bzw. keine »reinen Daten«. Somit verändern Sie eine bereits fehlerbehaftete Version der Realität zu einer anderen, wenn Sie mittels Differential Privacy künstliches Rauschen hinzufügen.
Ein weiterer guter Grund, gaußsches Rauschen für die Data Science in Betracht zu ziehen, sind die Eigenschaften, die eine Normalverteilung aufweist. Wenn Ihr Datensatz – oder zumindest bestimmte Variablen im Datensatz – ebenfalls normalverteilt sind, erhalten Sie wiederum eine normalverteilte Größe. Außerdem haben Normalverteilungen günstige Eigenschaften im Hinblick auf lineare Algebra und maschinelles Lernen, z.B. wenn Sie lineare oder affine Transformationen auf Matrizen oder Vektoren anwenden müssen.
Die derzeitigen Ansätze zu Differential Privacy werden immer noch weiterentwickelt und erforscht, und es können jederzeit neue hinzukommen. Um Ihre Entscheidungen im Rahmen Ihrer Anwendungsfälle bestmöglich treffen zu können, sollten Sie versuchen, das große Ganze im Auge zu behalten und ein Verständnis dieser Technologie zu entwickeln. Als Entscheidungshilfe lohnt es sich, einen abstrakteren, theoretischen Blick auf Differential Privacy zu werfen.
Bisher haben Sie die Definition der Sensitivität auf eine hinzugefügte Person bzw. gelöschte Person bezogen. Dies wird auch als Privacy Unit, im Deutschen also sinngemäß »Datenschutzeinheit«, bezeichnet. Es gibt Fälle, in denen eine Person als Privacy Unit für das Privacy-Problem, das Sie zu lösen versuchen, ungeeignet ist.
Was ist, wenn ein Gerät von mehreren Nutzern verwendet wird (z.B. ein Auto, ein Home-Assistent oder ein WLAN-Router)? Dann möchten Sie wahrscheinlich sicherstellen, dass das entsprechende Gerät die Privatsphäre aller Nutzer wahrt, sodass der Unterschied zwischen D1 und D2 vom Gerät abhängt.
Wenn Sie das Verhalten von Nutzern über einen längeren Zeitraum hinweg untersuchen möchten, z.B. den Browser- oder Standortverlauf oder die Kaufhistorie, werden Sie auf ein weiteres Problem stoßen. Führen Sie über einen längeren Zeitraum mehrere Abfragen auf derartige Daten durch, würde Ihr Privacy Budget wahrscheinlich ausgeschöpft werden, ohne dass es Ihnen möglich wäre, eine aussagekräftige Analyse anzustellen. In diesem Fall könnten Sie das Differential Privacy Budget auf einen bestimmten Zeitraum begrenzen, das nach Ablauf dieses Zeitraums wieder zurückgesetzt wird. Oder Sie könnten sich dafür entscheiden, dass ein Nutzer nicht alle Aktionen, die möglich wären, durchführen kann, sondern nur bestimmte, für die Sie den Schutz der Privatsphäre gewährleisten (wobei Sie dann versuchen, die Privatsphäre pro Klick bzw. pro Aktion zu schützen).9 Dieser Schutz verringert sich natürlich, wenn die Daten auf einer kleineren Ebene (Privacy Unit) veröffentlicht werden, z.B. wenn der Schutz der Privatsphäre nur für einen Tag oder eine Woche oder für einen Klick oder eine andere Aktion gewährleistet wird anstatt für alle Aktionen, die ein Nutzer ausführen kann. Wenn ein Angreifer über zusätzliche Informationen verfügt, kann er die Ergebnisse der Abfragen bzw. die veröffentlichten Daten, die dieser Form von Differential Privacy unterliegen, dazu verwenden, seine Vermutung mit der Zeit noch mehr zu stützen. Zudem hat sich gezeigt, dass äußerst aktive Nutzer (sogenannte Superuser) trotz Differential-Privacy-Mechanismen besonders stark gefährdet sind und in den Ergebnissen identifiziert werden können.
Wenn Sie eine Anonymisierung durchführen, um der Datenschutzgesetzgebung zu entsprechen – wie z.B. Differential Privacy zur Anonymisierung von Daten im Rahmen der DSGVO anzuwenden –, ist es besonders wichtig, diese Entscheidungen mit Ihrem juristischen Team zu besprechen (mehr dazu in Kapitel 8). Wenn Sie gewillt sind, neuartige Ansätze zu implementieren, kann ein Blick in die Fachliteratur zu einem bestimmten Algorithmus oder Anwendungsfall, der Ihnen vorschwebt, eine nützliche Implementierung zutage fördern, die Ihren Anforderungen an den Datenschutz am besten gerecht wird.10
In Kapitel 3 werden Sie sich noch mit einer der nützlichsten Open-Source-Bibliotheken für Differential Privacy vertraut machen, wodurch Ihnen die in der Praxis angewandten Ansätze besser greifbar werden sollten. Dennoch dürften Sie sich im Moment vielleicht fragen, ob es nicht noch weitere Definitionen von Anonymisierung gibt. Möglicherweise haben Sie ja schon mal von k-Anonymity (bzw. k-Anonymität) gehört? Sehen wir uns einmal an, worum es sich dabei handelt und warum nicht mehr empfohlen wird, sie zu verwenden.
k-Anonymity ist ein älterer Anonymisierungsansatz, der von der Informatikerin Latanya Sweeney (https://latanyasweeney.org) entwickelt wurde, nachdem sie nachgewiesen hatte, dass sie die vom Bundesstaat Massachusetts freigegebenen Krankenakten de-anonymisieren kann. Der damalige Gouverneur William Weld hatte zuvor vorgeschlagen, alle staatlichen Krankenakten zur öffentlichen Einsichtnahme freizugeben, und dabei erklärt, sie seien ordnungsgemäß anonymisiert worden. Nachdem sie die veröffentlichten Krankenakten mit leicht zu beziehenden Daten aus dem Wählerverzeichnis zusammengeführt hatte, war es Sweeney möglich, Welds Krankenakten unter Hinzuziehung von Alter, Postleitzahl und Geschlecht herauszufiltern bzw. zu identifizieren. Daraufhin hat sie ihm seine Krankenakten zugeschickt, was ihn dazu veranlasste, die freigegebenen Daten zurückzuziehen.
k-Anonymity wurde ursprünglich entwickelt, um diese Art von Linkage Attacks zu verhindern. Bei k-Anonymity werden Personen mit ähnlichen sensiblen Merkmalen bzw. Attributen (wie Alter, Postleitzahl und Geschlecht) gruppiert, und Gruppen, die weniger als k Personen enthalten, werden nicht veröffentlicht. Wenn Sie zum Beispiel eine Tabelle hätten, die wie Tabelle 2-2 aussieht:
Tabelle 2-2: Ursprünglicher Datensatz
Alter |
Postleitzahl |
Diagnose |
54 |
11189 |
Covid-19 |
44 |
11188 |
gewöhnliche Grippe |
22 |
11187 |
Covid-19 |
25 |
11189 |
Covid-19 |
44 |
34555 |
Covid-19 |
72 |
34555 |
Covid-19 |
66 |
34556 |
gewöhnliche Grippe |
77 |
34555 |
gewöhnliche Grippe |
78 |
11189 |
gewöhnliche Grippe |
75 |
33444 |
Covid-19 |
würden Sie sie so anpassen, dass Sie wie Tabelle 2-3 aussieht und dabei k = 2 wählen.
Tabelle 2-3: Der Datensatz mit k = 2
Alter |
Postleitzahl |
Diagnose |
40-60 |
1118* |
Covid-19 |
40-60 |
1118* |
gewöhnliche Grippe |
20-40 |
1118* |
Covid-19 |
20-40 |
1118* |
Covid-19 |
60+ |
3455* |
Covid-19 |
60+ |
3455* |
gewöhnliche Grippe |
60+ |
3455* |
gewöhnliche Grippe |
Sie sehen, dass Sie die Größe der Gruppen teilweise noch weiter gefasst haben, um eine höheres Maß an Privatsphäre zu gewährleisten und sicherzustellen, dass eine einzelne Person nicht identifiziert werden kann. Außerdem haben Sie einige Zeilen weggelassen, sodass k = 2 gilt und somit keine Einzelpersonen mehr in der Tabelle enthalten sind. Ist die Privatsphäre damit nun geschützt?
Wenn ich mir ziemlich sicher bin, dass Sie in dem Datensatz enthalten sind, dass Sie Mitte 20 sind und dass Sie eine Postleitzahl haben, die mit 1118 beginnt, kann ich sofort ableiten, dass Sie wahrscheinlich Covid-19 hatten, weil in diesem Datensatz 100 % der 20- bis 40-Jährigen mit dieser Postleitzahl eine positive Diagnose hatten. Doch genau das wollten Sie eigentlich verhindern. Informationen wie diese wurden in mehreren k-anonymisierten Datensätzen ausgenutzt, darunter ein veröffentlichter edX-Datensatz, der mithilfe von LinkedIn-Daten re-identifiziert wurde (https://oreil.ly/gTcKg).
Angesichts der Tatsache, dass es infolge dieser Schwachstellen zu bekannten Angriffen kam, schlugen die Forscher eine neue Methode vor, die in Verbindung mit k-Anonymity verwendet werden kann: l-Diversity (die im Deutschen auch als l-Vielfalt bezeichnet wird). l-Diversity besagt, dass es auch bei verwandten sensiblen Merkmalen eine Varianz geben muss, damit der Prozess von k-Anonymity nicht zu homogenen Gruppen führt, in denen sensible Merkmale ungewollt offengelegt werden.
Leider verursachte l-Diversity zusätzliche Probleme bei der Verwendung der Daten. Im Zuge der Bildung der Gruppen könnten die Daten verzerrt werden, sodass sie für Methoden wie maschinelles Lernen oder statistische Inferenz unbrauchbar wären und unausgewogene Gruppen entstehen würden, die für die eigentlichen Daten nicht mehr repräsentativ wären. Was wäre zum Beispiel, wenn Sie einen Wert von k = 2 und einen Wert von l = 2 festlegten? Im Endeffekt würden Sie dann nur noch die Zeilen erhalten, die in Tabelle 2-4 aufgeführt sind.
Tabelle 2-4: Der Datensatz mit k = 2 und l = 2
Alter |
Postleitzahl |
Diagnose |
40-60 |
1118* |
Covid-19 |
40-60 |
1118* |
gewöhnliche Grippe |
60+ |
3455* |
Covid-19 |
60+ |
3455* |
gewöhnliche Grippe |
60+ |
3455* |
gewöhnliche Grippe |
Dadurch stehen Ihnen jetzt nicht nur weniger Informationen und Daten zur Verfügung, sondern Ihr Datensatz wurde auch verfälscht. Die Inzidenz der gewöhnlichen Grippe fällt nun höher aus als die von Covid-19, was im vollständigen Datensatz nicht der Fall ist.
Zur Lösung dieses Problems wurde t-Closeness (seltener auch als t-Nachbarschaft bezeichnet) vorgeschlagen, die besagt, dass die l-diversen Gruppen eine t-Closeness zur Verteilung dieser Attribute in der Gesamtpopulation aufweisen müssen. Daher müssen Sie jetzt Gruppen erstellen, die die Verteilung dieser verwandten Attribute in der Gesamtpopulation besser widerspiegeln. Mal sehen, wie sich das auf unsere Tabelle auswirkt (siehe Tabelle 2-5).
Tabelle 2-5: Der Datensatz mit k = 2, l = 2 und t-Closeness
Alter |
Postleitzahl |
Diagnose |
keiner |
keiner |
keiner |
Ja, genau so! Es ist nicht möglich, Daten zu veröffentlichen und gleichzeitig diese Anforderungen zu erfüllen.
Ich denke, Ihnen ist klar geworden, welche Einschränkungen es gibt. k-Anonymity ist so, als würde man Ihren Datensatz mit einer Axt bearbeiten, obwohl ein Meißel für Ihre Zwecke eigentlich besser geeignet wäre. k-Anonymity bietet keine Möglichkeit, Datenschutzgarantien zu quantifizieren, muss bei jedem Datensatz individuell angepasst werden, benötigt viel Rechenleistung, um richtig implementiert zu werden, und fügt dem Datensatz zahlreiche Verzerrungen (engl. Bias) hinzu. Anders als bei Differential Privacy gibt es keine Möglichkeit, zu ermitteln, inwieweit ein Angreifer Informationen in Erfahrung bringen kann, oder Rückschlüsse auf den Privacy Loss einzelner Personen im Datensatz zu ziehen. Daher wird es heutzutage im Allgemeinen nicht mehr zur Anonymisierung von Daten verwendet bzw. nicht mehr empfohlen.
Möglicherweise haben Sie sich bereits Gedanken über synthetische Daten gemacht. Ich werde die möglichen Verwendungszwecke synthetischer Daten noch in Kapitel 10 erläutern. Bislang war es schwierig, synthetische Daten mit realistischen Eigenschaften zu generieren, ohne dass dafür reale Daten als Grundlage verwendet werden, was jedoch unter Umständen zu einem Leakage von Informationen führen kann. Beispielsweise bietet Gretel.ai Möglichkeiten, synthetische Daten aus realen Daten zu generieren und dabei gleichzeitig Differential Privacy anzuwenden (https://oreil.ly/bcZun). In Kapitel 4 erfahren Sie mehr darüber, welche Risiken für die Privatsphäre mit der Generierung realistischer synthetischer Daten auf Basis realer Daten verbunden sind, wenn keine Differential Privacy zum Einsatz kommt.
In diesem Kapitel haben Sie eine genaue und wissenschaftliche Definition von Privacy kennengelernt, und zwar von Differential Privacy, der derzeit führenden Lösung zur Anonymisierung. Sie haben einfach gehaltene Mechanismen implementiert und verschiedene Arten von Rauschen verglichen, ein eigenes Privacy Budget erstellt und eine erste Vorstellung davon entwickelt, wie Differential Privacy in der Praxis umgesetzt wird. Sie können nun nachvollziehen, wie schwierig es ist, umfassende Mechanismen zu entwickeln, die komplexe Themen wie Sensitivität adressieren und die richtige Balance zwischen dem Schutz der Privatsphäre und dem Informationsgehalt von Daten zu wahren. Darüber hinaus haben Sie auch frühere Ansätze einer Bewertung unterzogen und herausgefunden, dass diese nur selten zu empfehlen sind.
Ich hoffe, Sie können der Komplexität der im Zusammenhang mit Privacy auftretenden Probleme inzwischen etwas abgewinnen. Im nächsten Kapitel werden Sie Ihr neu erworbenes Wissen über Governance, Datenschutz und Differential Privacy auf reale Systeme anwenden und dabei verfügbare Bibliotheken nutzen.
