Nachdem Sie verschiedene Ansätze zur Pseudonymisierung und Anonymisierung kennengelernt haben, werden wir uns nun damit beschäftigen, wie Sie diese Ansätze direkt in die üblichen Datenworkflows integrieren können. Pipelines und andere groß angelegte Dateninfrastrukturen stellen einen nachhaltigen und erweiterbaren Ansatz dar, mit dem sich Datenschutz in Ihre Datenarchitektur integrieren lässt. Datenschutzmethoden lassen sich skalieren, wenn sie von einem multidisziplinären Expertenteam ausgearbeitet und von einem Team implementiert werden, das nicht nur Datenschutztechnologien versteht, sondern auch die Infrastruktur des Unternehmens. So gelangen Sie von Stückwerk zu leicht wartbarem Privacy by Design.
In diesem Kapitel erfahren Sie, wie Sie Datenschutztechnologien in die datenverarbeitende Infrastruktur und Software einbinden können.1 Ich gebe Ihnen auch Tipps für die Zusammenarbeit mit Data-Engineering-Teams (falls Sie noch keinem angehören). Abschließend werden Sie lernen, wie Datenschutz in Datenerhebungsmethoden integriert werden kann und wie Differential Privacy sich als Teil einer entsprechenden Pipeline darstellt.
In Kapitel 1 haben Sie sich mit den Grundlagen der Data Governance befasst und gelernt, wie grundlegende Datenschutzmaßnahmen anzuwenden sind. In Kapitel 2 haben Sie Anonymisierungs- und Differential-Privacy-Methoden kennengelernt. Nachdem Sie nun die Grundbausteine des Datenschutzes verinnerlicht haben, ist es Zeit, mit ihnen zu experimentieren und sie anschließend zu automatisieren und in einer realen Dateninfrastruktur zu skalieren.
Bevor Sie damit beginnen, Datenschutz in diese Workflows zu integrieren, sollten Sie die Risiken sorgfältig bewerten, die Daten (so gut es geht) dokumentieren, den Anwendungsfall einschätzen, die Sensitivität der Daten ermitteln und Ihr Vorhaben in Bezug auf die Verarbeitung und den Datenschutz für andere darlegen. Mithilfe des in Kapitel 1 beschriebenen Vorgehens haben Sie die Governance und die Sensitivität der Daten bestimmt und wissen jetzt, welche Methoden im Rahmen der Datenerhebung, -nutzung und -transformation erforderlich sind. Unabhängig davon, ob Sie eine Maskierung, eine Pseudonymisierung oder Differential Privacy verwenden, können Sie diese Schritte befolgen, wenn Sie Ihre Datenschutzmaßnahmen in Pipelines integrieren wollen.
Sie haben vielleicht Hunderte oder Tausende von Data-Engineering-Jobs, die täglich ausgeführt werden. Unabhängig davon, in welchem Umfang Daten in Ihrem Unternehmen verarbeitet werden, sollten Sie allen Beteiligten klar darlegen, welche Datenschutzmaßnahmen Sie für die verschiedenen Datentypen, die Sie verarbeiten, ergreifen werden. Sind Sie sich nicht sicher, welche technischen Datenschutzmaßnahmen Sie ergreifen sollten, fangen Sie am besten klein an (z.B. indem Sie sensible Felder maskieren bzw. unkenntlich machen) und probieren erst einmal verschiedene aus. Ihr Ziel ist es, den goldenen Mittelweg für Ihre Daten zwischen einem möglichst hohen Informationsgehalt und einem angemessenen Datenschutz zu finden, um so sicherzustellen, dass sie den Zweck, für den sie erhoben wurden, erfüllen und gleichzeitig die Privatsphäre der betroffenen Personen geschützt wird. Es ist immer eine schlechte Idee, persönliche bzw. sensible Daten zu erheben, die komplett ungenutzt bleiben!
Sehen wir uns an, wie Sie am besten vorgehen können und welche Fragen Sie sich stellen müssen, um beurteilen zu können, ob Ihre Maßnahmen dem jeweiligen Anwendungsfall gerecht werden:
Bestimmung des Zwecks und des Anwendungsfalls
Welchen Zweck verfolgen Sie mit der Erfassung dieser Daten? Wer wird sie verwenden und wofür? Bestimmen Sie Ihre Anwendungsfälle gemeinsam mit den internen oder den Endnutzerinnen und -nutzern. Wenn Sie sich nicht sicher sind, warum die Daten erhoben oder wofür Sie verwendet werden, müssen Sie gemeinsam mit anderen abwägen, ob es das Risiko wert ist, die entsprechenden Daten zu erheben, wenn diese vielleicht nie gebraucht werden. Beschäftigen Sie sich mit dem Konzept der Datensparsamkeit (https://oreil.ly/SK8Xq) (engl. Data Minimization) und folgen Sie diesem; es ist der bestmögliche Mechanismus zum Schutz der Privatsphäre. Für Ihre erste Implementierung sollten Sie einen Anwendungsfall auswählen, der ein vergleichsweise hohes Datenschutzrisiko birgt.
Größtmöglicher Datenschutz
Ausgehend von Ihrem anfänglichen Anwendungsfall, wie viel Datenschutz können Sie bieten, ohne dass Ihre Arbeit beeinträchtigt wird? Oftmals ist es sinnvoll, verschiedene Datenschutztechnologien zu erproben und sich die Ergebnisse anzusehen. Damit keine Daten verloren gehen, sollten Sie einen temporären, sicheren internen Speicher oder eine Stichprobe der Daten erstellen, auf den bzw. die keine Datenschutzmethoden angewandt wurden. Testen Sie verschiedene Methoden und lassen Sie das Team bzw. die Personen, die die Daten verwenden, einen Blick darauf werfen, um zu sehen, ob sie noch einen ausreichend hohen Nutzen aus den Daten ziehen können. Wenn es geht, sollten Sie mit einem möglichst hohen Maß an Datenschutz beginnen (d.h. Löschen von Feldern, Maskierung und/oder Differential Privacy). Ähnlich wie bei der Entwicklung eines neuen Produkts sollten Sie erst herausfinden, was der Kunde braucht, und ihm nicht einfach das geben, wonach er fragt.
Zum einen könnten Sie als Datenschutzexperte Möglichkeiten erkennen, wie deren Bedürfnissen auf eine datenschutzfreundlichere Weise entsprochen werden kann. Zum anderen könnten sich die Datennutzer zu sehr auf ihre eigene Analyse konzentrieren und ihre eigenen Interessen nicht mit den Rechten der Betroffenen in Einklang bringen. Wie immer gilt: Suchen Sie das Gespräch! Schon nach wenigen Gesprächsrunden werden Sie für sich und Ihr Team herausfinden, welche Maßnahmen für welche Arten von Aufgaben geeignet sind. Sie werden auch neue Bibliotheken und Ansätze kennenlernen, wenn diese im Rahmen Ihrer Experimente erprobt werden.
Übertragen auf andere Anwendungsfälle
Welche anderen Aufgaben, Anwendungsfälle oder Datenkonsumenten hätten die gleichen oder ähnliche Anforderungen, wenn für das erste Projekt ein angemessenes Gleichgewicht zwischen Schutz und Nützlichkeit der Daten gefunden wurde? Sofern Ihr Unternehmen über eine Datenklassifizierung verfügt, die an die Einwilligung oder Nutzung gebunden ist, sollten Sie mit Anwendungsfällen beginnen, die dieselben Klassifizierungs- bzw. Nutzungsanforderungen erfüllen. Verwenden Sie einen agilen Ansatz, bei dem Sie diese kleinen Änderungen einführen und nach und nach einen weiteren Anwendungsfall oder eine weitere Aufgabe berücksichtigen. Auch Ihre Datenkonsumenten (bzw. Endnutzer) werden nach und nach lernen und möglicherweise andere Bedürfnisse haben, die kleinere Anpassungen erfordern. Wenn sich ein Ansatz über mehrere Teams und ähnliche Anwendungsfälle hinweg bewährt, kann er als Standardmethode oder Standardansatz eingeführt werden. Dies kann dokumentiert und an neue Mitarbeitende in den Bereichen Data Engineering und Data Privacy weitergegeben werden. Für den Fall, dass der Ansatz aus irgendeinem Grund nach einiger Zeit nicht mehr funktioniert, sollte sichergestellt werden, dass die Datenkonsumenten oder Endnutzer über die Änderungen informiert werden.
Erproben, lernen und anpassen
Wenn neue Datenschutztechnologien verfügbar werden oder wenn die Kompetenzen im Bereich Datenschutz im Team ausgebaut wurden, sollten Sie überlegen, an welchen Stellen Sie Optimierungen und Anpassungen vornehmen können. Der Bereich wächst und verändert sich stetig. Ein paar Ihrer Teammitglieder sollten stets über neue Entwicklungen informiert bleiben. Liegt eine neuere Version einer Bibliothek vor, die Sie verwenden? Wenn ja, welche neuen Funktionen bietet sie? Bringt ein neues Teammitglied gegebenenfalls spezielle Fachkenntnisse mit, oder wurde ein neuer Privacy Engineer eingestellt? Wie lassen sich ihre Empfehlungen sinnvoll in die Workflows einbinden? Beurteilen Sie geplante Änderungen der Datenschutzrichtlinien und anderer Data-Governance-Maßnahmen im Unternehmen und arbeiten Sie gemeinsam an neuen Richtlinien, Standards und Implementierungen. Wenn Sie Datenschutz im Kontext zukünftiger Entwicklungen betrachten, können Sie sicherstellen, dass Ihre Datenschutzmaßnahmen sowohl aktuell als auch in Zukunft angemessen sind.
Sie haben bereits in Kapitel 2 gelernt, dass Differential Privacy eine strenge Definition von Privacy ist, die eine belegbare Garantie bietet. Alle anderen Verfahren sind daher weniger sicher und weniger empfehlenswert. In Bezug auf den Datenschutz in der Praxis werden Sie wahrscheinlich Methoden verwenden müssen, die nicht so sicher und streng sind wie Differential Privacy. Mein Anliegen ist, dass Sie das in diesem Buch erworbene Wissen nutzen, um sich für die sicherste Methode zu entscheiden, mit der Sie Ihre Arbeit erledigen können. Wenn das bedeutet, dass Sie statt Differential Privacy lediglich ein Feld entfernen, dann ist es auch Ihre Aufgabe, dafür zu sorgen, dass Ihr Team und andere, die die Daten verwenden, das damit verbundene Risiko verstehen.
Sobald Sie die Maßnahmen gefunden haben, die für Ihre Anwendungsfälle geeignet sind, ist es an der Zeit, diese in allen Arbeitsabläufen bzw. Workflows zu verankern. Doch bevor Sie dazu übergehen, möchte ich Ihnen zeigen, wie Sie Datenflüsse aufbauen können, die auf alle Beteiligten abgestimmt sind.
Wer bezieht am Ende Ihrer Pipeline die Daten? Welche Anforderungen hat diese Person in Bezug auf Datenschutz und -qualität? Herauszufinden, wer Ihr »Datenkonsument« ist, ist ein wesentlicher Aspekt, der beim Aufbau besserer und nützlicherer Pipelines berücksichtigt werden muss.
Wenn Sie deren Bedürfnisse und Anwendungsfälle kennen, werden Sie besser verstehen, wie Sie den Datenschutz am besten gewährleisten und wie Sie Kontrollmechanismen einrichten können, die sicherstellen, dass alles wie geplant funktioniert.
Wie Sie bereits in Kapitel 2 erfahren haben, setzt die Anwendung von Differential Privacy ein gutes Verständnis der Daten, des Anwendungsfalls und der damit verbundenen Sensitivität voraus. Jeder dieser Faktoren wird sich im Laufe der Zeit ändern. Durch regelmäßige Rücksprachen mit den Datenkonsumenten können Sie sich vergewissern, dass die der Differential Privacy unterliegenden Daten immer noch den Erwartungen und Anforderungen des Teams bzw. der Konsumenten entsprechen. Wenn sich dies ändert oder wenn sich die zugrunde liegende Verteilung grundlegend ändert (z.B. infolge einer Änderung der Software oder Anwendung, mit der die Daten erzeugt werden, oder einer systematischen Veränderung der Grundgesamtheit), sollte der Differential-Privacy-Mechanismus entsprechend umgestaltet werden. Dies kann so einfach sein wie die Anpassung der Grenzwerte (Clamping Bounds), der Sensitivität, der Privacy Units oder des Epsilons oder auch so komplex wie die Entwicklung eines neuen Algorithmus.
Genauso wichtig ist es, zu kommunizieren, dass sich die Daten, die die Konsumenten sehen werden, aufgrund des eingeführten Datenschutzes verändern. Im Idealfall handelt es sich dabei um regelmäßige Gespräche, da das Team, das die Datenschutzmaßnahmen einführt, diese an die Bedürfnisse des Unternehmens sowie der Compliance- und Rechtsabteilung und anderer Interessengruppen anpasst. Den Nutzern beizubringen, wie sie Daten verwenden können, die Datenschutzmaßnahmen unterzogen wurden, gehört mittlerweile zu den erforderlichen Fähigkeiten der Privacy- und Datenteams. Entscheidend für den Erfolg oder Misserfolg Ihrer Datenschutzinitiativen wird sein, dass dieses Gespräch reibungslos abläuft und dass alle Beteiligten das Gefühl haben, Fragen stellen und experimentieren zu können.
Ich persönlich finde es sehr wichtig, Menschen dort abzuholen, wo sie sich in Bezug auf ihre Nutzererfahrung befinden. Wenn Sie einen Analysten oder einen Informatiker ansprechen, der 20 Jahre lang auf eine bestimmte Art und Weise gearbeitet hat, und Sie dies nun ändern möchten, sollten Sie sich überlegen, wie Sie die Umstellung möglichst reibungslos gestalten können. Möglicherweise haben diese Menschen jahrelang die gleichen Methoden angewandt. Zudem sollten Sie sicherstellen, dass ihre Arbeit dadurch nicht gestört wird und dass Sie darauf hinwirken, dass sie neue Datenschutztechnologien annehmen. Nehmen Sie kleine, kaum wahrnehmbare Änderungen vor, gehen Sie die Änderungen Schritt für Schritt an, hören Sie sich ihre Bedenken an und beziehen Sie sie in den Aufbau und die Planung ein. Holen Sie während des Prozesses immer wieder Feedback dazu ein, ob alles ordnungsgemäß funktioniert. Bereits eine geringfügige Verbesserung der psychologischen Sicherheit (bzw. des Gefühls von Sicherheit) kann sehr viel bewirken!
Dank dieser Bemühungen werden Sie auch herausfinden, wie Sie kleine Teile der Arbeit in Ihre Pipelines integrieren können.
Wenn Sie damit beginnen, Ihre Datenschutzmaßnahmen zu automatisieren (Privacy Engineering), sollten Sie versuchen, sie direkt in Ihre Systeme einzubetten, und nicht jedes Mal aufs Neue benutzerdefinierte Funktionen erstellen. Zu Beginn sollten Sie einen Schritt zurücktreten und prüfen, ob es ganzheitliche Lösungen gibt, mit denen Sie sie in Ihr System integrieren können, sobald sich ein Ansatz, den Sie ausprobiert haben, bewährt hat.
Eine Möglichkeit besteht darin, kleine Softwarepakete in der von Ihnen verwendeten Programmiersprache oder Plattform zu erstellen, die diese Schritte ausführen. Wenn Sie bereits Tools einsetzen, die verschiedene Privacy-Funktionen von Haus aus unterstützen (wie Apache Beam (https://oreil.ly/24cOE), das eine Unterstützung für Differential Privacy bietet), greifen Sie auf diese zurück, wann immer es möglich ist! Sollten Sie Spark verwenden, können Sie auch die Tumult-Analytics-Bibliothek (https://oreil.ly/fNrKw) (die im Laufe dieses Kapitels noch vorgestellt wird) oder das PipelineDP-Projekt (https://oreil.ly/jA1Xs) nutzen. Entwickeln Sie nur dann eigene Lösungen, wenn ein Anwendungsfall so spezifisch ist, dass dies unumgänglich ist – z.B. wenn ein Team eine ganz spezielle Art formaterhaltender Verschlüsselung verwenden muss.
Sie sollten nicht nur die Datenschutztechnologien direkt in der Pipeline einsetzen, sondern auch testen und überprüfen, ob die Dinge so funktionieren, wie Sie es erwarten.
Sicherlich testen Sie Ihre Pipelines bereits, oder? Dies gehört schon seit vielen Jahren zu den bewährten Verfahren, die es Ihnen ermöglichen, die Funktionsweise besser zu verstehen und zu validieren. Zusätzlich zu Unittests oder Integrationstests ist es für die Beurteilung des Zustands Ihres Systems unerlässlich, auch die übertragenen Daten zu testen.
Ich nutze hierfür Great Expectations (https://greatexpectations.io), das bereits seit Längerem das Tool meiner Wahl ist. Es hat eine recht intuitive Oberfläche, über die Sie sowohl vordefinierte »Expectations« verwenden als auch neue bauen können. Stellen Sie sich das wie eine statische Analyse Ihrer Daten vor: Bestehen die Daten den Smell Test?2 Wenn nicht, sollten Sie die Daten kennzeichnen oder den gesamten Prozess unterbrechen. Auf diese Weise können Sie Rechenkosten sparen und Fehler im System oder in den Pipelines schneller erkennen und beheben.
Was sollten Sie mit einem Tool wie Great Expectations letztlich testen, um in Erfahrung zu bringen, ob Sie sich datenschutzkonform verhalten? Nun, Sie könnten testen, ob bestimmte Felder vorhanden sind bzw. gelöscht wurden, wenn Sie Felder nach Anwendung des Datenschutzmechanismus hinzugefügt haben bzw. wenn Sie erwarten, dass bestimmte sensible Felder gelöscht oder nicht aufgenommen werden. Sie können auch testen, ob die Grenzwerte, die Sie im Rahmen der Differential Privacy getroffen haben (Clamping Bounds), wie erwartet funktionieren. Sie können sogar ziemlich ausgeklügelte Tests entwickeln, mit denen Sie sicherstellen können, dass bestimmte Felder gehasht bzw. verschlüsselt sind (indem Sie die Entropie von Zeichenketten überprüfen) oder dass gewisse Maskierungstokens in Feldern vorhanden sind, in denen sie zu erwarten sind.
Um diese Grundprinzipien und Standards praxisnäher zu verdeutlichen, erfahren Sie nun anhand eines Beispiels, wie Sie sie umsetzen können.
Sie sind jetzt bereit, den ersten Anwendungsfall bzw. mehrere Anwendungsfälle zu entwickeln. Um Ihre getesteten und genehmigten Datenschutztransformationen in eine Produktionsumgebung zu bringen, müssen Sie sicherstellen, dass sie zu Ihren aktuellen Datenworkflows passen und ordnungsgemäß implementiert und getestet werden.
Sehen wir uns ein konkretes Beispiel an, bei dem es um den Austausch von Daten zwischen verschiedenen Abteilungen in einem Unternehmen geht.
Es ist üblich, Daten innerhalb eines Unternehmens oder sogar innerhalb verschiedener Unternehmen gemeinsam zu nutzen. Wie können Sie dies auf sichere und datenschutzfreundliche Weise tun? Sie verfolgen zwei Ziele: zum einen die Wahrung der Privatsphäre der Nutzer bzw. Mitarbeitenden und zum anderen den Bedürfnissen der Datenkonsumenten gerecht zu werden. Sie haben sich mit internen Expertinnen und Experten beraten, um das Datenschutz- und Sicherheitsrisiko zu analysieren und das erforderliche Schutzniveau zu bestimmen.
Angenommen, Sie arbeiten bei einem Unternehmen, das nachhaltige Schokolade produziert, und verfügen über Einkaufsdaten von Kunden, die über die Webseite bestellt haben. Die Marketingabteilung möchte diese Daten nutzen, um die Effektivität ihrer Kampagnen auf Basis der Anwendergruppe (User-by-User) zu messen.3
Nachdem Sie den Anwendungsfall erst einmal analysiert haben, legen Sie sich in einem Plan zurecht, wie die Daten am besten transformiert werden sollten, sodass einerseits ein angemessener Datenschutz gewährleistet ist und andererseits ausreichend Nutzen aus den Daten gezogen werden kann. Ihr Plan sieht dabei wie folgt aus:
Umreißen wir einmal, wie dies in einem Workflow aussehen könnte. Der Pseudo-Python-Code sähe etwa wie folgt aus:
order_dataframe.drop(['street_address', 'first_name', 'last_name',...])
browser_dataframe.drop(['ip_address', 'browser_Nutzer_agent',...])
order_campaign_df = order_dataframe.merge(browser_dataframe, how='inner', on=['order_id'])
# Hier würden Sie einen Chiffrierschlüssel verwenden, der auf sichere
# Weise für diesen speziellen Auftrag generiert und gespeichert wurde.
# Der Schlüssel wird nur für die Dauer der
# Analyse der Daten vorgehalten und dann gelöscht.
order_campaign_df.Nutzer_id.map(lambda x: encrypt(x, key))
order_campaign_df = order_campaign_df.groupby('order_id').agg(
{'campaign_uri': 'first',
'Nutzer_id': 'first',
'city': 'first',
'state': 'first'
'total': 'sum',
'num_items': 'count',
})
order_campaign_df = order_campaign_df.total.map(remove_outliers)
# Anschließend exportieren und samt Verarbeitungsdetails bereitstellen!
Ein funktionierendes Beispiel für diesen Arbeitsschritt finden Sie im entsprechenden Jupyter Notebook im Repository des Buchs (https://github.com/kjam/practical-data-privacy). Passen Sie das Beispiel einfach an das Framework und die Programmiersprache an, die in Ihrem Unternehmen verwendet werden.
Woher wissen Sie jedoch, ob die Pipeline auch richtig funktioniert? Klar, Sie testen sie!
Hierfür verwenden wir ein paar Expectations aus der Great-Expectations-Bibliothek. Als Erstes sollten Sie die Great-Expectations-Bibliothek in Ihr Notebook importieren und so einrichten, dass Sie Daten direkt aus dem Pandas-Dataframe abfragen können:
Als Nächstes sollten Sie sich ein Bild davon machen, welche Expectations verfügbar sind, indem Sie einen erweiterten Dataframe erstellen, in dem zusätzlich die Expectations berücksichtigt sind. Verwenden Sie dazu die Tabulator-Autovervollständigungsfunktion, indem Sie im Jupyter Notebook expect eintippen und dann die Tabulatortaste drücken. Ihnen wird eine lange Liste angezeigt, durch die Sie navigieren können:
ge_df = ge.from_pandas(summary_by_order)
ge_df.expect # Drücken Sie nun die Tabulatortaste!
Mit der folgenden Funktion können Sie testen, ob Sie alle Ausreißer in der Spalte total_price entfernt haben. Sie könnten alternativ auch Perzentil-, Maximal- oder Minimalwerte oder auch Standardabweichungen zugrunde legen.
ge_df.expect_column_values_to_be_between('total_price', 1500, 27000)
Normalerweise würden Sie anschließend weitere Expectations von Hand hinzufügen, es gibt jedoch auch die Möglichkeit, einen Profiler aus der Great-Expectations-Bibliothek zu verwenden und eine Reihe von Expectations automatisch auf Basis der Daten erstellen zu lassen. Wenn Sie mit der Datenexploration fertig sind, müssen Sie die Expectations speichern und die Pipeline so einrichten, dass sie als ein Verarbeitungsschritt ausgeführt werden. Weitere Informationen zur Einrichtung der Pipeline sowie zahlreiche Anleitungen finden Sie in der Dokumentation der Great-Expectations-Bibliothek (https://docs.greatexpectations.io):
ge_df.get_expectation_suite(discard_failed_expectations=False)
# Hier können Sie überprüfen, ob die Expectations
# Ihren Anforderungen entsprechen!
# Anschließend speichern Sie sie in einer JSON-Datei und richten Ihr
# System so ein, dass es die Daten während der Verarbeitung
# mithilfe dieser Datei und GE testet!
import json
with open("order_summary_for_sharing_expecation_file.json", "w") as
my_file: my_file.write(
json.dumps(ge_df.get_expectation_suite().to_json_dict())
)
Nun können Sie sicher sein, dass Sie gewarnt werden, wenn etwas nicht funktioniert. Erkundigen Sie sich während der ersten Durchläufe bei Ihren Datenkonsumenten, ob ihre Analyse ohne Probleme verläuft. Konnten sie Veränderungen im Rahmen ihrer Analyse oder Verarbeitung feststellen? Haben sie mit ihren Datenkonsumenten bzw. den Personen, die deren Analysen verwenden, gesprochen? Ich empfehle Ihnen, in der ersten Woche täglich und im folgenden Monat einmal wöchentlich nachzufragen. Sorgen Sie dafür, dass sich jemand aus dem Team die von Great Expectations erstellten Gesamtstatistiken im Rahmen eines wöchentlichen Zustandsberichts für alle Pipelines ansieht und darauf hinweist, wenn erhebliche Abweichungen zu verzeichnen sind, die eine weitere Untersuchung erfordern würden. Sie sollten ein Warnsystem einrichten, das auf Fehler hinweist, die nicht auftreten sollten, und sicherstellen, dass die Teammitglieder die Warnmeldungen erhalten und auch wissen, wie sie die Fehler beheben können.
Betrachten wir nun eine andere Art von Anwendungsfall, anhand dessen wir uns näher mit Data Governance in Pipelines befassen. Wie kommen Sie überhaupt an die Auftrags- und Sitzungsinformationen?
In Kapitel 1 haben Sie erfahren, wie wichtig es ist, bei der Erhebung von Daten die Einwilligung einzuholen und sie mit den Daten zu verknüpfen. Diese Art der Datenerhebung zu automatisieren und so zu strukturieren, dass sie einfach zu handhaben ist, bestimmt maßgeblich den Erfolg der Integration des Datenschutzes in die Datenerhebung.
Idealerweise sollte die Einwilligung nicht nur für die Erhebung, sondern auch für den Gebrauch der Daten eingeholt werden. Allerdings sind die meisten Systeme und Schnittstellen derzeit nicht so gestaltet. In der Regel wird den Nutzerinnen und Nutzern eine Reihe von Daten, die erfasst werden, aufgelistet, und umfangreiche Nutzungsbedingungen bzw. eine Datenschutzerklärung werden angezeigt. Diese sind jedoch eher pauschal gehalten, als dass sie konkrete Verwendungszwecke aufzeigen, die ein Nutzer dann aus- oder abwählen (Opt-in bzw. Opt-out) kann.
Wenn Sie in einem Unternehmen arbeiten, das eine alternative Herangehensweise an Datenschutz anstrebt, könnten Sie Ihre Datenschutzerklärung und Datenerhebung auch anders gestalten, beispielsweise wie in Abbildung 3-1 dargestellt. Wenn eine Nutzerin die Anwendung bzw. Webseite zum ersten Mal öffnet, werden die Voreinstellungen geladen, und die Benutzeroberfläche wird eingeblendet. Die Voreinstellungen sollten so gewählt werden, dass sie einen möglichst hohen Schutz der Privatsphäre gewährleisten und dass nur zwingend erforderliche Daten erhoben werden, während alle anderen Einstellungen deaktiviert sind. Wenn neue Funktionen hinzugefügt bzw. die Daten in anderer Weise als zuvor verarbeitet werden, wird die Nutzerin dazu aufgefordert, ihre Einstellungen anzupassen. Darüber hinaus kann sie auch entscheiden, ob die Daten nur lokal gespeichert werden sollen, d.h. nur auf dem Gerät, und nicht an einen zentralen Server oder eine Anwendung weitergegeben werden, es sei denn, es ist für die Funktionalität unbedingt erforderlich (mehr dazu in Kapitel 6).
Wenn Sie den Verwendungszweck bzw. Anwendungsfall ändern oder die Daten auf eine neue Art und Weise verwenden möchten, z.B. mit einem neuen Machine-Learning-Modell, würden Sie dies den Nutzern mitteilen und diese explizit darum bitten, dem neuen Verwendungszweck zuzustimmen.
Abbildung 3-1: Datenschutzfreundliche Einverständniserklärung im Rahmen der Erhebung von Daten
Als weitere benutzerfreundliche Option können Sie den Nutzerinnen und Nutzern eine Benutzeroberfläche zur Verfügung stellen, über die sie sämtliche von ihnen festgelegten Einwilligungen für die verschiedenen Verwendungszwecke abrufen und separat aus- oder abwählen können. Das könnte etwa so aussehen wie in Abbildung 3-2. Auf dieser Benutzeroberfläche wird angegeben, welche Daten für die einzelnen Verwendungszwecke bzw. Anwendungsfälle benötigt werden, wobei das verwendete Vokabular leicht verständlich ist. Dem Nutzer wird eine Reihe von Wahlmöglichkeiten eingeräumt, darunter die Möglichkeit, Daten zu anonymisieren oder auf dem Endgerät zu speichern.
Es wurde intensiv erforscht, wie sich die Gestaltung von Benutzeroberflächen auf die Benutzererfahrung (User Experience, UX) auswirkt, um bessere Benutzeroberflächen für den Datenschutz zu entwickeln – wie beispielsweise das Ethical Design Framework von ind.ie (https://oreil.ly/Oqzox) oder auch Privacy UX (https://oreil.ly/o0cO5). Ebenso wurde untersucht, was nicht zu empfehlen ist – wie im Fall der Studie der Universität Ulm zu schlechten Design-Patterns im Bereich des Datenschutzes (https://oreil.ly/qrmP1).
Abbildung 3-2: Benutzeroberfläche, mit der die Einwilligungen gezielt verwaltet werden können
Wenn es in Ihrem Unternehmen Customer-Experience-Designer gibt, lohnt es sich, mit ihnen ins Gespräch zu treten, um herauszufinden, wie Workflows angeglichen und Einwilligungen besser eingeholt und klarer kommuniziert werden könnten.4 Als Nutzer solcher Benutzeroberflächen wissen Sie, dass es einem bedeutend leichter fällt, seine Zustimmung zu geben, wenn klar ist, wofür die Daten verwendet werden und warum – und wenn es eine Möglichkeit gibt, diese Einstellungen zu überprüfen. Das ist auch eine wesentliche Anforderung der DSGVO (mehr dazu in Kapitel 8).
Selbst wenn Sie die Einholung der Einwilligung nicht sinnvoll umgestalten können, sollten Sie festhalten, zu welchen Daten Ihnen zum Zeitpunkt der Datenerhebung eine Einwilligung vorliegt. Die gesetzlichen Rahmenbedingungen sind bekanntermaßen dynamisch. Wenn Sie wissen, welche Datenschutzbestimmungen zum Zeitpunkt der Erhebung der Daten zugrunde lagen, können Sie zu einem späteren Zeitpunkt besser darüber entscheiden, wie Sie die Daten verwenden, aufbewahren oder auch möglichst sparsam einsetzen.
Wie würde eine datenschutzfreundliche Einwilligung und Erhebung von Daten in der Praxis aussehen? Skizzieren wir zunächst die Anforderungen an die Datenerhebung und erarbeiten wir ein Schema, das im Hinblick auf künftige Datenschutzanforderungen geeignet ist. Beispielsweise könnten Sie folgende Daten erheben:
Denken Sie daran, dass eine Software erst dann wirklich entwickelt ist, wenn sie ausreichend getestet und validiert wurde. Wie können Sie also sicherstellen, dass die Einwilligungsdaten ordnungsgemäß erfasst wurden und nachverfolgt werden können?
Im Folgenden sehen Sie ein Beispiel für eine Schemaüberprüfung, mit der Sie sicherstellen können, dass die entsprechenden Daten ordnungsgemäß erfasst und gespeichert werden. In diesem Beispiel wird die Syntax von Apache Avro (https://avro.apache.org) genutzt, mit dem Sie ebenfalls das Datenschema testen und Datenstrukturen in Pipelines validieren können:
{"namespace": "example.avro",
"type": "record",
"name": "Nutzer Consent Data",
"fields": [
{"name": "Nutzername", "type": "string"},
{"name": "policy_version", "type": "float"},
{"name": "retention_months", "type": "int"},
{"name": "agreement_date", "type": "datetime"},
{"name": "processing_purposes", "type": "array", "items" : "string", "default": []},
{"name": "terms_version", "type": "float"},
{"name": "data_localities", "type": "array", "items" : "string", "default": ["us-aws-east"]},
{"name": "usage_detail__location_on", "type": "bool"},
{"name": "usage_detail__location_ml", "type": "bool"},
{"name": "usage_detail__location_analytics", "type": "bool"},
{"name": "usage_detail__location_sharing", "type": "bool"},
{"name": "usage_detail__actions_on", "type": "bool"},
{"name": "usage_detail__actions_ml", "type": "bool"},
{"name": "usage_detail__actions_analytics", "type": "bool"},
{"name": "usage_detail__actions_sharing", "type": "bool"},
{"name": "provenance_location", "type": "string"},
/* Anwendung oder Website usw. */
]
}
Im vorliegenden Beispiel wurden die Felder für die Nutzungsdaten eingeebnet, wodurch sich die Daten leicht anhand der verschiedenen Arten von Einwilligungen filtern lassen. Auf diese Weise können die im Zusammenhang mit Machine Learning genutzten Continuous-Integration-Pipelines automatisch die Nutzer auswählen, die ihr Einverständnis gegeben haben, und diese Daten sofort für Analysen oder zum Trainieren von Modellen bereitstellen.
Außerdem liegen Ihnen nun Daten vor, die Aufschluss darüber geben, wie lange die Daten gemäß den Bestimmungen aufbewahrt werden dürfen und wann die Einwilligung erteilt wurde. Somit können Sie Daten, die in Kürze nicht mehr aufbewahrt werden dürfen, ganz einfach als Batches zusammenfassen und anonymisieren oder auch löschen. Dementsprechend sollten Sie den Aufbau der Pipelines frühzeitig angehen, ehe die Aufbewahrungsfrist abläuft. Wenn Sie die Daten aufbewahren möchten und mit der Rechtsabteilung vereinbart haben, Differential Privacy als Anonymisierungsmechanismus anzuwenden (siehe Kapitel 8), bedeutet dies, dass Sie Differential Privacy als festen Bestandteil in Ihre Datenworkflows integrieren müssen. Nehmen wir das einmal genauer unter die Lupe!
Wenn Sie sich dazu entschließen, Differential Privacy in bestehenden oder neuen Pipelines zu implementieren, sollten Sie eine Bibliothek verwenden, die eine gute Unterstützung bietet und sich in die Technologie, die Sie derzeit verwenden, integrieren lässt. Sollten Sie bereits Apache Beam auf der Google Cloud Platform verwenden, empfehle ich Ihnen, die dort bereitgestellten Codelab-Notebooks (https://oreil.ly/IKHm4) auszuprobieren und die verschiedenen Möglichkeiten zu erkunden, die sich Ihnen bieten, wenn Sie Differential Privacy implementieren möchten.
Wenn Sie Spark verwenden, empfehle ich die Tumult-Analytics-Bibliothek (https://oreil.ly/idW3D), die speziell darauf ausgerichtet ist, datenschutzkonforme Verfahren zu unterstützen, und auch eine Vielzahl weiterer Funktionen bietet.
Die Tumult-Analytics-Bibliothek war zum Zeitpunkt des Verfassens dieses Buchs noch relativ neu. Sie sollten daher in der Dokumentation (https://oreil.ly/gI2ia) nachsehen, ob sich etwas geändert hat. Die Notebooks aus dem Repository des Buchs werden regelmäßig aktualisiert, weshalb Sie die Bibliothek am besten dort untersuchen sollten.
Probieren wir die Differential-Privacy-Bibliothek von Tumult Analytics einmal aus, um zu sehen, wie sie im Rahmen Ihres gewohnten Workflows eingesetzt werden kann. Verwenden Sie dazu einen anderen Datensatz, auf den in der Tumult-Dokumentation (https://oreil.ly/gI2ia) verwiesen wird, oder nutzen Sie einfach direkt den Datensatz aus dem Code-Repository dieses Buchs.
Starten Sie zunächst eine Spark-Session und initiieren Sie ein Differential Privacy Budget. Dabei verwenden Sie einen Wert für Epsilon von 1,1:
session = Session.from_dataframe(
privacy_budget=PureDPBudget(epsilon=1.1),
source_id="members",
dataframe=members_df,
protected_change=AddOneRow(),
)
Bei diesem Datensatz handelt es sich um eine Liste von Bibliotheksmitgliedern. Sehen wir uns zunächst an, welche Spalten der Datensatz umfasst:
members_df.columns
Die Ausgabe ist wie folgt:
['id',
'name',
'age',
'gender',
'education_level',
'zip_code',
'books_borrowed',
'favorite_genres',
'date_joined']
Angenommen, Sie möchten wissen, ob es eine Korrelation zwischen der Anzahl der ausgeliehenen Bücher und dem Bildungsniveau gibt. Um in der Tumult-Analytics-Bibliothek mit kategorialen Spalten arbeiten zu können, müssen Sie zunächst ein KeySet (https://oreil.ly/4vHVJ) erstellen und vorgeben, welche verschiedenen Ausprägungen Sie für die entsprechende kategoriale Variable erwarten, die sie zur Gruppierung heranziehen möchten:
edu_levels = KeySet.from_dict({
"education_level": [
"up-to-high-school",
"high-school-diploma",
"bachelors-associate",
"masters-degree",
"doctorate-professional",
]
})
edu_average_books_query = (
QueryBuilder("members")
.groupby(edu_levels)
.average("books_borrowed", low=0, high=100)
)
edu_average_books = session.evaluate(
edu_average_books_query,
privacy_budget=PureDPBudget(0.6),
# Ich spare etwas Budget für später auf, weshalb ich jetzt
# nur 0,6 meines Epsilons aufwende (insgesamt 1,1).
)
edu_average_books.sort("books_borrowed_average").show(truncate=False)
Hierbei erstellen die Tumult-Klassen KeySet und QueryBuilder (https://oreil.ly/-DcfZ) eine Abfrage, die Differential Privacy garantiert. Der Code ist in diesem Beispiel so ausgestaltet, dass die Anzahl der ausgeliehenen Bücher auf einen Wertebereich zwischen 0 und 100 begrenzt ist. Dabei handelt es sich um die sogenannten Clamping Bounds, die Sie in Kapitel 2 kennengelernt haben. Damit die Abfrage ausgewertet werden kann, müssen Sie der Bibliothek mitteilen, wie viel Sie von Ihrem Privacy Budget dafür aufwenden möchten. Als ich die Abfrage ausgeführt habe, erhielt ich die folgende Ausgabe. Ihre Ausgabe wird aufgrund der Anwendung von Differential Privacy anders ausfallen:
+----------------------+----------------------+
|education_level |books_borrowed_average|
+----------------------+----------------------+
|doctorate-professional|18.929587482219063 |
|masters-degree |19.1402224030377 |
|bachelors-associate |19.173858890761228 |
|up-to-high-school |19.361286812215194 |
|high-school-diploma |19.57674149725407 |
+----------------------+----------------------+
In diesem Datensatz ist kein eindeutiger Zusammenhang zwischen dem Bildungsniveau und der Anzahl der ausgeliehenen Bücher zu erkennen. Das Ausleihverhalten der Bibliotheksmitglieder scheint nicht wesentlich von diesem Merkmal abzuhängen. Möglicherweise ist auch die Spanne der Clamping Bounds zu hoch angesetzt, weshalb es eine Überlegung wert ist, sie in künftigen Abfragen anzupassen.
Gehen wir nun der Frage nach, ob die Personen in Abhängigkeit von ihrer Bildung und ihrem Alter ein unterschiedliches Ausleihverhalten aufweisen. Zunächst müssen Sie (mittels Binning) Altersklassen (https://oreil.ly/ihlxx) erstellen, nach denen Sie anschließend gruppieren können:
age_binspec = BinningSpec([10*i for i in range(0, 11)])
age_bin_keys = KeySet.from_dict({
"age_binned": age_binspec.bins()
})
binned_age_with_filter_query = QueryBuilder("members")\
.filter("education_level='masters-degree' or"\+
"education_level='doctorate-professional'")\
.bin_column("age", age_binspec)\
.groupby(age_bin_keys)\
.average("books_borrowed", low=0, high=22)
session.evaluate(binned_age_with_filter_query,
privacy_budget=PureDPBudget(0.4)).show(truncate=False)
Ich erhielt die folgende Ausgabe, als ich den Code ausgeführt habe:
+----------+----------------------+
|binned_age|books_borrowed_average|
+----------+----------------------+
|100-109 |-2.0 |
|80-89 |11.476923076923077 |
|40-49 |11.034418604651163 |
|30-39 |11.501822600243013 |
|70-79 |11.256830601092895 |
|50-59 |11.599250936329588 |
|10-19 |14.0 |
|90-99 |-24.0 |
|60-69 |10.970472440944881 |
|0-9 |19.0 |
+----------+----------------------+
Großartig! In einigen dieser Spalten ist eine Menge Rauschen infolge der Differential Privacy zu erkennen, denn manche Werte sind sogar negativ. Was ist schiefgelaufen? Bei der Filterung nach dem Alter wurde nicht berücksichtigt, dass einige der Altersklassen wahrscheinlich unterrepräsentiert sind. Die Wahrscheinlichkeit, dass ein Achtjähriger einen Master-Abschluss vorweisen kann, ist äußerst gering.
Das Beispiel lehrt Sie: Wenn Sie mit Differential Privacy arbeiten, müssen Sie sich Gedanken über Ihre Daten machen und Ihre Abfragen und Hypothesen klären, um Ihre Analyse zu planen, bevor Sie einen Code ausführen. Im vorliegenden Beispiel wäre es sinnvoll gewesen, zunächst eine Abfrage durchzuführen, mit deren Hilfe Sie sich einen Überblick über die verschiedenen Altersklassen verschaffen können, oder eine Grafik zu erstellen, mit der Sie ermitteln können, welche Altersklassen vorhanden sind (mit oder ohne Anzahl). So können Sie sich erst mal ein besseres Bild von Ihren Daten machen, bevor Sie die eigentlichen Abfragen formulieren. Wenn Sie die Tumult-Analytics-Bibliothek verwenden, können Sie mit einem unbegrenzten Privacy Budget beginnen, um herauszufinden, wie sich geringfügige Änderungen des Epsilon-Werts auf Ihre Ergebnisse auswirken. Wie Sie Differential Privacy und andere Mechanismen im Rahmen des gesamten Data-Science-Prozesses angehen können, erfahren Sie in Kapitel 5.
Datenzugriff und Differential Privacy
In einem Szenario, in dem Differential Privacy in großem Umfang eingesetzt wird, könnten Sie am Ende verschiedene Zugriffsmöglichkeiten einrichten, die unterschiedliche Privacy-Garantien bieten. Hier sind ein paar Szenarien, die Sie durchdenken sollten:
Zugriffsbeschränkungen mit Differential Privacy
Der unternehmensweite Zugriff auf Daten erfolgt nur über Differential Privacy unterliegenden Abfragen, erlaubt aber einer begrenzten Anzahl von Mitgliedern des Datenteams den Zugriff mit einem sehr großen Wert für Epsilon oder ganz ohne Differential Privacy.
Datenweitergabe an Dritte mit Differential Privacy
Verwenden Sie für sämtliche mit Dritten geteilten Daten einen Differential-Privacy-Mechanismus.
Differential Privacy für Data-Science-Workflows
Binden Sie Differential Privacy an einen bestimmten Teil des Data-Science-Workflows – jedoch erst nachdem Sie eine erste explorative Datenanalyse (engl. Exploratory Data Analysis, EDA) durchgeführt und die Daten besser kennengelernt haben. Denken Sie daran, dass Sie herausfinden möchten, wie Sie die Daten besser schützen können, während Sie gleichzeitig den Nutzerinnen und Nutzern ermöglichen, sie zu analysieren und wichtige Fragen zu beantworten!
Probieren Sie aus, welche Lösung für Ihr Unternehmen am besten geeignet ist, und beurteilen Sie dabei, inwieweit Sie den Schutz und den Informationsgehalt der Daten austarieren sollten, um sicherzustellen, dass sie zwar geschützt sind, aber der Zugriff auf sie dennoch etwas bringt.
Weitere Abfragebeispiele mit diesem Datensatz und der Bibliothek finden Sie im Repository des Buchs. Sie können die Bibliothek auch mit Ihrem eigenen Datensatz ausprobieren. Solange Sie sie nur ausprobieren wollen, können Sie Ihr Privacy Budget auf unendlich setzen, in der Realität müssen Sie jedoch einen Wert für Epsilon festlegen und sich überlegen, wie Sie Ihr Budget aufteilen. Wenn Sie eine ähnliche Fehlermeldung wie die folgende sehen:
RuntimeError: Cannot answer query without exceeding privacy budget:
it needs approximately 0.100, but the remaining budget
is approximately 0.000 (difference: 1.000e-01)
… wissen Sie, dass Ihr zugewiesenes Budget nicht dafür ausreicht, dass die Anfrage beantwortet wird.
Ich empfehle Ihnen dringend, einen Beispieldatensatz herzunehmen und sich selbst ein Bild von den Möglichkeiten der Tumult-Bibliothek oder einer anderen bewährten Open-Source-Bibliothek für Differential Privacy zu machen! Tumult ist nicht die einzige Bibliothek, die mit Spark kompatibel ist. Sie können auch PipelineDP verwenden, das von einigen Google-Mitarbeitern gemeinsam mit der OpenMined-Community (https://www.openmined.org) gepflegt wird. Im entsprechenden GitHub-Repository (https://oreil.ly/Xjk4z) finden Sie Beispiele, die Ihnen den Einstieg erleichtern.
Nicht jede Bibliothek verfügt über sogenannte End-to-End-Differential-Privacy-Garantien. Deshalb erweist es sich in anderen Bibliotheken oft als kompliziert und fehleranfällig, das Budget zu nachzuverfolgen und zuzuweisen. Insbesondere für den Einstieg in die Differential Privacy empfehle ich Ihnen, auf Bibliotheken zurückzugreifen, die das Management des Budgets für Sie übernehmen.
Einen eigenen Differential-Privacy-Mechanismus aufzubauen und das Privacy Budget nachzuverfolgen, kann, wie Sie in Kapitel 2 gelernt haben, sehr aufwendig sein und mit komplexen Sonderfällen und Fehlern einhergehen. Zum Glück steht die Data Science gerade am Anfang einer neuen Ära, in der Open-Source-Bibliotheken die nötige Unterstützung bei dieser Aufgabe bieten. Da Sie bereits Ihren eigenen simplen Mechanismus aufgebaut haben und dabei nachvollziehen konnten, wie er intern funktioniert, ist Ihnen bewusst, wie Sie Ihr Budget einsetzen und sicherstellen können, dass die Privacy-Garantien für alle Beteiligten nachvollziehbar sind. Sie sollten zudem auch den nachfolgenden Empfängern mitteilen, wie die Daten verarbeitet wurden, damit diese den hinzugefügten Fehler besser verstehen und berücksichtigen können.
Sie fragen sich vielleicht, ob Sie Differential Privacy auch direkt bei Erhebung der Daten anwenden können. In der Tat gibt es dafür eine ganze Reihe von Möglichkeiten. Sehen wir uns an, wie sich Daten im Rahmen der Erhebung anonymisieren lassen!
Nachdem Sie nun in der Lage sind, quelloffene und geprüfte Differential-Privacy-Bibliotheken in Ihren Pipelines zu verwenden, könnten Sie darüber nachdenken, Daten in anonymisierter Form zu erheben. In diesem Zusammenhang ergeben sich einige neue Überlegungen, wie z.B. die Frage, woher Sie wissen können, wie hoch die Sensitivität der Daten ist, wenn Sie nicht darauf zugreifen können? Und wie können Sie garantieren, dass sie geschützt sind, wenn sie bereits vor der Erfassung anonymisiert werden?
Nehmen wir einmal unter die Lupe, wie Apple seinen ersten datenschutzfreundlichen Emoji-Sampler implementiert hat, um herauszufinden, wie lokale Differential Privacy funktioniert (im Vergleich zur zentralen Differential Privacy, die Sie in Kapitel 2 kennengelernt haben).
Apple war eines der ersten Unternehmen, das lokale Differential Privacy (ein Differential-Privacy-Mechanismus, der angewandt wird, bevor die Daten erfasst und zentral gespeichert werden) auf Ebene des Internets eingesetzt hat. Das Unternehmen verfügt über ein Team aus Wissenschaftlerinnen und Wissenschaftlern sowie Entwicklern, die sich speziell mit Datenschutzsystemen befassen, und hat sich als Marke und Unternehmen dazu entschlossen, dass Datenschutz ein wichtiges Unterscheidungsmerkmal für seine Produkte darstellen soll.
Apple wollte seine Vorschläge für Emojis verbessern und herausfinden, welche Emojis in unmittelbarer Nähe eines bestimmten Texts vorkommen – jedoch ohne dass dabei private Textdaten an seine Server gesendet werden. Im Unternehmen war man überzeugt, dass die Häufigkeit der Emojis und die angrenzenden Tokens ausreichen würden, um das Problem zu lösen, und daher begann man damit, dies unter Anwendung von Differential Privacy für iOS-Geräte zu implementieren.
In dem ersten Artikel, den Apple zu seinen Differential-Privacy-Mechanismen (https://oreil.ly/AtH_I) veröffentlichte, sind mehrere praktische Grafiken enthalten, die sehr gut veranschaulichen, wie Differential Privacy auf Ebene von Geräten vor Erfassung der Daten funktioniert. Nach Anwendung des Differential-Privacy-Mechanismus werden die Daten an die Apple-Server gesendet.
Dabei wird dem Emoji das vorgegebene Rauschen direkt auf dem jeweiligen Endgerät hinzugefügt (siehe Abbildung 3-3). Wenn Sie ein iOS-Gerät nutzen, können Sie auf Ihrem Smartphone nachsehen, welche Werte für Epsilon verwendet werden, indem Sie zu Einstellungen/Datenschutz & Sicherheit/Analyse & Verbesserungen gehen und sich die Analytics-Daten in den Einträgen ansehen, die mit DifferentialPrivacy beginnen. Nachdem das Rauschen hinzugefügt wurde, wird nun eine Emoji-Darstellung, auf die zuvor Differential Privacy angewandt wurde, an die Apple-Server gesendet, wobei die IP-Adresse und Informationen, aus denen hervorgeht, woher die Daten stammen, verworfen werden. Die Ergebnisse werden als statistische Verteilung verdichtet, mit der anschließend mithilfe des Streuungsparameters und der (nur Apple bekannten) verwendeten Differential-Privacy-Parameter das Rauschen entfernt werden kann. In den Abbildungen 3-3 und 3-4 ist die gesamte Pipeline dargestellt.
Abbildung 3-3: Die unter Anwendung von lokaler Differential Privacy erhobenen Emoji-Daten von Apple
In Abbildung 3-4 können Sie erkennen, dass der Differential-Privacy-Mechanismus gleich am Anfang direkt auf dem Gerät angewandt wird (auch in Abbildung 3-3 gezeigt). Wenn die anonymisierten Daten dann an den Server gesendet werden, wird die IP-Adresse verworfen, sodass niemand die Daten direkt zu einer bestimmten Person zurückverfolgen bzw. ihr zuordnen kann, da dadurch alle durch Differential Privacy erzielten Privacy-Garantien sofort zunichtegemacht würden. Intern verwendet Apple einen Ingestor (zum Einspeisen der Daten) und einen Aggregator, die die eingehenden Daten transformieren und für Analysezwecke zusammenfassen. Schließlich gibt es noch interne Dashboards und Auswertungen, die vom Datenteam und den Anwendungsentwicklern genutzt werden. Jede der gestrichelten Linien stellt eine Trust Boundary, sozusagen eine Vertrauensgrenze, dar. Wenn diese im Zuge der Verarbeitung verletzt wird oder wenn ein interner Mitarbeiter die Daten zurückverfolgen kann, verlieren die Privacy-Garantien ihre Gültigkeit.
Abbildung 3-4: Die Pipeline für Apples Emoji-Datenerhebung
Was ist eine Trust Boundary?
Eine Trust Boundary ist eine Art Grenze, an der sich die Sicherheit grundlegend ändert. In der Regel bedeuten diese Grenzen, dass die Nutzer und Betreiber eines Bereichs jeweils keinen Zugriff auf den Bereich des anderen haben sollten. Hier ein paar Beispiele, die die Definition verdeutlichen:
Von außen nach innen
Wenn eine Nutzerin Daten in ein Anwendungsformular eingibt und diese an den Anwendungsserver schickt, überschreitet sie eine Trust Boundary. Bevor der Server ordnungsgemäß antwortet, muss sichergestellt werden, dass die Anfrage korrekt formuliert und validiert ist und keine bösartigen Befehle (z.B. eine SQL-Injection-Attack) enthält. Dies muss unter Aufsicht der Server- und Anwendungsadministratoren geschehen.
Aus sicherer Umgebung zu weniger sicher
Wenn Sie Daten von einer sicheren, durch bestimmte Standards regulierten Architektur in eine weniger sichere verschieben, überschreiten Sie ebenfalls eine Trust Boundary. Hierbei kann es sich um den Transfer von einem lokalen System in die Cloud oder von einem stark geschützten Bereich der Architektur in einen weniger geschützten Bereich handeln.
Nachgelagerte Datenströme
Wenn Sie Datenworkflows aufbauen, gibt es möglicherweise mehrere Datenkonsumenten. Diese haben oft unterschiedliche Zugriffsrechte sowie Zielgruppen, was bedeutet, dass diese Datenströme auch über Trust Boundaries hinweg operieren. Daher ist es wichtig, zunächst zu durchdenken, wo die Trust Boundaries bei Ihren Datenworkflows liegen könnten, um so besser bestimmen zu können, an welchen Stellen Sie Datenschutzkontrollen und -technologien einsetzen sollten.
Sobald die Ausführung der Pipeline beendet ist, sind die resultierenden Analysen interpretierbar. Das bedeutet, dass jeder Nutzer glaubhaft abstreiten kann, welche Emojis er nutzt. Dem für die Entwicklung der Tastatur zuständigen Team liegen nun aber Informationen vor, mit deren Hilfe es passendere Vorschläge für Emojis für die verschiedenen Sprachversionen der Tastatur machen kann. Wie die Analysen des Beitrags zeigen, gibt es zwischen französisch- und englischsprachigen Tastaturbenutzern tatsächlich einen Unterschied in der Beliebtheit bestimmter Emojis (siehe Abbildung 3-5).
Abbildung 3-5: Analyse zur Verwendung von Emojis auf der Tastatur nach Anwendung von Differential Privacy
Dieser Ansatz kann sinnvoll sein, wenn Sie Daten auf der Ebene von Geräten erheben können und ein paar einfache Diagramme erstellen oder mehr über die zugrunde liegenden Verteilungen erfahren möchten. Er ist jedoch aufgrund des Rauschens, das auf individueller Ebene hinzugefügt wird – wie Sie im nächsten Abschnitt erfahren werden –, nur praktikabel, wenn er in großem Maßstab verfolgt wird.
Das Differential-Privacy-Team von Apple veröffentlicht regelmäßig seine neuesten Forschungsergebnisse (https://oreil.ly/20UxD), die für Sie von Interesse sein könnten, sollten Sie erwägen, Differential Privacy auf der Ebene von Endgeräten zu implementieren.5
Gibt es noch weitere Möglichkeiten, Datenschutz direkt im Rahmen der Erhebung von Daten zu integrieren? Bei Google wurde ein Ansatz entwickelt, der anschließend jedoch wieder eingestellt wurde. Dennoch handelt es sich dabei um ein lehrreiches Anwendungsbeispiel.
Das im Jahr 2014 von Google eingeführte Differential-Privacy-System RAPPOR war eines der ersten, das erfolgreich in großem Maßstab deployt wurde. Sie können sich noch immer die Details zur Implementierung (https://oreil.ly/sqy3M) und sogar den Code (https://oreil.ly/bqz1o) ansehen, indem Sie einen Blick auf das frei zugängliche Repository oder die Dokumentation werfen.
RAPPOR wurde mit dem Ziel entwickelt, sensible Daten aus Chrome-Browsern zu erfassen, ohne dabei die Privatsphäre zu verletzen. Zu diesem Zweck implementierten die Teams in einer ihrer Bibliotheken eine Randomized-Response-Technik, die dazu diente, grundlegende Statistiken in Form von Bitstrings zu erheben. Dabei könnten die Chrome-Entwickler an einer ganzen Reihe von Ereignissen oder Metriken interessiert gewesen sein, z.B. ob ein bestimmtes Add-on verwendet wurde oder ob ein bestimmter Fehler aufgetreten ist, oder an gewissen Informationen bezüglich des Browserverlaufs des Nutzers.
Zunächst sollten wir noch klären, was unter einer Randomized Response bzw. einer randomisierten Antwort (https://oreil.ly/EPUBT) verstanden wird. Die Technik wurde erstmals im Jahr 1965 von Umfrageforschern vorgeschlagen, als diese Personen zu sensiblen Themen befragen sollten und darauf angewiesen waren, ehrliche Antworten zu erhalten. Mithilfe dieser Methode, die auch einen Differential-Privacy-Mechanismus darstellt, konnten sie den befragten Personen eine glaubhafte Abstreitbarkeit garantieren.
In einem Beispiel, in dem die Randomized Response auf Basis eines Münzwurfs erfolgt, sähe die Methode folgendermaßen aus:
Der hier zum Tragen kommende Differential-Privacy-Mechanismus geht offenbar mit einem recht niedrigen Wert für Epsilon und einem hohen Maß an Rauschen einher! Wollten Sie den Bias des Ergebnisses korrigieren, würden Sie davon ausgehen, dass etwa die Hälfte der Ja-Antworten falsch ist, und diese außen vor lassen. Sollten Ihnen mehr Informationen über die Grundgesamtheit vorliegen, könnten Sie Ihre Annahme noch verfeinern. Wenn Sie mehr erfahren und experimentieren möchten, finden Sie im Code-Repository des Buchs (https://github.com/kjam/practical-data-privacy) ein Notebook mit einem ausführlicheren Leitfaden und weiterführenden Links.
RAPPOR setzt einen dreiteiligen Workflow ein, mit dem die Metriken von einem lokalen Rechner über einen längeren Zeitraum hinweg weitergeleitet werden, während gleichzeitig Differential-Privacy-Garantien geboten werden. Diese Garantien sind ähnlich wie bei der Randomized-Response-Technik. Im Wesentlichen werden die Antworten in Form einer Folge von Bits codiert. Jede dieser Antworten war mit einem kleinen Datenpunkt verbunden. Die Bitfolge wurde dann zu einem Bloom-Filter gehasht. Dieser Filter durchläuft einen Randomized-Response-Prozess und wird als permanenter Datenspeicher auf dem Endgerät gespeichert. Anschließend wird ein Array von Bits vorbereitet, das zusätzlich mit Rauschen versehen wird. Auf diese Weise soll verhindert werden, dass jemand im Laufe der Zeit die dauerhaft auf dem Filter-Array gespeicherten Antworten in Erfahrung bringen kann.
Die in dem ursprünglichen Beitrag verwendete Abbildung ist sehr aufschlussreich (siehe Abbildung 3-6). Die permanente RAPPOR-Antwort (B') wird gespeichert und die derzeitige randomisierte Antwort zusätzlich mit Rauschen versehen, um lokale Differential-Privacy-Garantien zu bieten. Die senkrechten Linien entsprechen jeweils einem Bit. Dementsprechend können Sie von der Nachricht bis zum Bericht nachvollziehen, wie diese Kombination aus Informationen (ursprüngliche Nachricht) und Rauschen (permanenter Bloom-Filter und randomisierte Antwort) vonstattengeht. Welche Bits wurden gesendet und welche nicht?
Abbildung 3-6: Wie Daten von RAPPOR gesendet werden
Google hat das Projekt im Jahr 2014 als Open Source zur Verfügung gestellt und 2016 die Aktualisierung des Projekts dann eingestellt. Doch warum?
Der relative Fehler von Randomized-Response-Methoden ist im Vergleich zu anderen Methoden der zentralisierten Differential Privacy (wie in Kapitel 2) ziemlich hoch. Um bei Randomized-Response-Methoden halbwegs akkurate Ergebnisse zu erzielen, müssen Sie nicht nur große Mengen an Daten sammeln, sondern auch einen beträchtlichen Fehler in den Daten einkalkulieren.
Um Differential-Privacy-Garantien in einem zentralisierten Modell mit Laplace-verteiltem Rauschen zu erhalten, wird der Streuungsparameter für die Verteilung und das resultierende Rauschen auf den Wert Sensitivität /ε für eine Gesamtanzahl an Datenpunkten (k) gesetzt. Um die gleichen Garantien für einen lokalen Differential-Privacy-Mechanismus zu erhalten, muss man den Fehler in Höhe von Sensitivität /ε für jeden Nutzer und jede Nutzerin hinzuaddieren. Das bedeutet, dass der relative Fehler für lokale Differential Privacy mit der Anzahl der Nutzer ungefähr um den Faktor 
zunimmt, was eine deutlich stärkere Zunahme darstellt als die des relativen Fehlers in einem zentralisierten Modell, bei der der Faktor ungefähr 
ist.
Wenn Sie Ihren Nutzern lokale Differential Privacy bieten möchten (wie es RAPPOR tat und wie es Apple bei seiner Datenerfassung tut), müssen Sie sich darüber im Klaren sein, dass der Fehler im Laufe der Zeit relativ groß ausfällt. Vermutlich war die vom Chrome-Team angestrebte Datenanalyse mit einem derart großen Fehler schlichtweg nicht möglich, weshalb das System schließlich nicht mehr gepflegt wurde und heute auch nicht mehr verwendet oder unterstützt wird.
Was können Sie hieraus lernen? Vergewissern Sie sich, dass Sie genau wissen, was Sie mit den Daten anstellen und wie Sie sie im Laufe der Zeit analysieren wollen, ehe Sie Zeit und Ressourcen in die Entwicklung einer Differential-Privacy-Lösung investieren, die nicht auf Ihre Analyse zugeschnitten ist. Zum Zeitpunkt des Verfassens dieses Buchs ist das mit einer lokalen Differential Privacy einhergehende Rauschen meist zu groß, um noch eine aussagekräftige explorative Analyse durchführen zu können – es sei denn, man ist sich darüber genau im Klaren, was man herausfinden möchte (wie im Fall der Emoji-Analyse von Apple).
Google hat daraufhin die Prochlo-Methode (https://oreil.ly/-z4dX) entwickelt, die seine Verarbeitungsinfrastruktur, Trust Boundaries, ein gewisses Maß an Rauschen und Verschlüsselung nutzt, um Differential-Privacy-Garantien im Rahmen der Datenerhebung zu bieten. Es lohnt sich, den Artikel zu lesen, um nachzuvollziehen, wie bei Differential-Privacy-Garantien im großen Maßstab die Ideen von lokaler und zentraler Differential Privacy miteinander kombiniert werden können, um eine entsprechende Lösung zu implementieren. Diese Art von Lösung kann allerdings nur dann umgesetzt werden, wenn Ihre Architektur fest definierte Trust Boundaries unterstützen kann!
Dieses Beispiel zeigt noch einmal deutlich, wie wichtig es bei der Entwicklung eines angemessenen Privacy-Engineering-Systems ist, mit den Stakeholdern zusammenzuarbeiten. Nur so können Sie den hinzugefügten Fehler richtig erklären, Fragen erläutern, falls sie beantwortet werden können, und herauszufinden, was für eine langfristige Strategie am besten geeignet ist.
In diesem Kapitel haben Sie erfahren, wie Sie Ihre Workflows um Governance und Differential Privacy erweitern können. Sie arbeiten jedoch nicht allein. Wie können Sie einen teambasierten Ansatz entwickeln und im gesamten Unternehmen Unterstützung gewinnen?
In relativ großen Unternehmen sind Data-Science- und Data-Engineering-Teams meist voneinander unabhängig. Meiner Meinung nach ist das eine bedauerliche Entwicklung, denn die beiden Teams sind zwangsläufig miteinander verflochten. Wenn keine Kommunikation zwischen Data Engineers, Data Scientists und Data Managers bzw. Data Stewards besteht, können die Daten auch nicht optimal genutzt werden. Darunter leiden ebenfalls die Entscheidungen, die im Zusammenhang mit Daten und Datenschutz getroffen werden. Die Datenschutzmethoden funktionieren nur dann in allen Teilen des Unternehmens, wenn die Führungsebene und das gesamte Datenteam die Standards und Methoden kennen und verstehen, wie sie sich auf die Daten sowie die Arbeit mit den Daten auswirken und warum sie so wichtig sind.
Wenn in Ihrem Unternehmen die Abteilungen, die bei diesen Themen zusammenarbeiten müssen, isoliert voneinander arbeiten, versuchen Sie, eine Brücke zu schlagen. Schon mit wenig Aufwand kann die Kommunikation erheblich verbessert werden.
Die Automatisierung von Datenworkflows ist nicht nur die Aufgabe von Data-Engineering- oder Data-Management-Teams. Vielmehr ist es auch die Aufgabe von Data Scientists, konkret zu bestimmen, welche Fragestellungen von Bedeutung sind und welche Daten benötigt werden, um diese beantworten zu können.
Das Data-Science-Team muss die geschäftlichen Anforderungen und Zielsetzungen umreißen und sie so gut verstanden haben, dass es Produktentscheidungen oder Features, die das Data-Science-Team benötigt, frühzeitig erkennen kann. Die Data-Science-Experten sollten mögliche Lücken in der aktuellen Datenerhebung vorhersehen und andere Teams, die die Erhebung und Software verwalten, anleiten, diese Lücken zu schließen. Wenn Sie zu einem Data-Science-Team gehören, ist dies auch ein guter Zeitpunkt, um Anregungen für mögliche Datenschutzanforderungen im Zuge der Erhebung von Daten zu geben.
Die Qualität, Interoperabilität und Standardisierung von Daten ist Teil der Data Governance und sollte unabhängig von der Größe eines Unternehmens teamübergreifend koordiniert werden. Dafür sollten Unternehmen ein Governance-Gremium, einen Ausschuss oder eine Gruppe einrichten und die Standards und Richtlinien regelmäßig auf der Grundlage des Feedbacks seitens der Community anpassen. Dank Ihrer erworbenen Kenntnisse in den Bereichen Data Governance und Data Privacy können Sie bei diesen Gesprächen Unterstützung leisten und als Bindeglied zwischen den verschiedenen Bereichen des Unternehmens fungieren.
Ein multidisziplinäres Datenteam sollte Daten regelmäßig testen und überprüfen, um sicherzustellen, dass die Standards und Richtlinien eingehalten werden und dass sie den Anforderungen aller Beteiligten entsprechen. Schließlich möchten Sie sicherlich nicht erleben, dass ein zusätzliches Feld, das Sie angefordert hatten, in den letzten sechs Monaten nicht erhoben wurde oder dass das Format eines anderen Felds nicht nachvollziehbar ist und Ihnen deshalb nicht weiterhilft. Stellen Sie sicher, dass Pipelines und andere Verarbeitungsschritte stets getestet werden (wie das, was Sie zuvor in diesem Kapitel implementiert haben) und dass sie regelmäßig anhand der Inputdaten aller Nutzer aktualisiert werden.
Insbesondere in größeren Unternehmen ist es wichtig, dass Sie Ihre Arbeit dokumentieren und so eine einheitliche Vorgehensweise und Kommunikation gewährleisten. Im Folgenden erfahren Sie, wie Sie dies für Privacy-Workflows umsetzen können.
Gut dokumentierte Systeme sind einfacher zu verwenden, zu betreiben und zu verwalten. Das heißt, wenn Sie bereits in einem gemeinsamen Repository arbeiten und die Jobs als Teil dieses Repositorys klar dokumentiert sind, sollte es ein Leichtes sein, dieser Dokumentation einen Abschnitt hinzuzufügen, in dem die Datenschutzanforderungen und -empfehlungen erläutert werden!
Sie haben in Kapitel 1 bereits viele Tipps erhalten, wie Sie Ihre Daten dokumentieren können. Im Folgenden erhalten Sie einige zusätzliche Anregungen, wie Sie die Dokumentation in Ihren normalen Arbeitsablauf integrieren können:
Wenn Sie einige gute Beispiele für Workflows haben, bei denen adäquate Datenschutzmaßnahmen hinzugefügt wurden, stellen Sie sicher, dass diese ordnungsgemäß dokumentiert sind. Verweisen Sie dann auf diese Beispiele oder halten Sie einen kurzen internen Vortrag darüber, wie Sie es gemacht haben. Häufig reicht es aus, den Leuten ein paar gute Beispiele an die Hand zu geben, mit denen sie sich vertraut machen können, und einen Ansprechpartner zu haben, an den sie sich bei Fragen wenden können. All diese Maßnahmen tragen dazu bei, die Dokumentation der Data Governance zu verbessern und in Ihrem Unternehmen eine eigene Datenschutzkultur zu schaffen.
Sie werden es wesentlich leichter haben, wenn der Datenschutz von zahlreichen Teammitgliedern – bzw. dem gesamten Unternehmen – als ein zentrales Wertversprechen (engl. Core Value Proposition) gesehen wird. Wenn Ihnen dieser Gedanke neu ist, sollten Sie überlegen, welche Teile Ihres Produkts oder Angebots mit dem Thema Datenschutz in Verbindung stehen und welchen Wert die Integration des Datenschutzes für Ihr Unternehmen insgesamt hätte.
Sofern Sie mit Verbraucherdaten arbeiten, liegt dies auf der Hand. Wenn Sie Ihren Kunden eine stärkere Datenschutzgarantie bieten, trägt dies wesentlich dazu bei, Vertrauen aufzubauen und eine Marke zu schaffen, die von den Menschen positiv wahrgenommen wird. Indem Sie öffentlich über Ihre Bemühungen sprechen, schaffen Sie nicht nur dieses Vertrauen, sondern könnten auch neue Talente anziehen, die in einem Umfeld arbeiten möchten, in dem der Datenschutz ernst genommen wird.
Die Vorteile liegen auch dann auf der Hand, wenn Sie im Business-to-Business-Bereich (B2B) oder nur mit internen Daten arbeiten. Wenn Sie mit internen Daten auf eine datenschutzgerechte Art und Weise arbeiten, bedeutet das für Ihre Mitarbeitenden und Sie selbst einen weniger starken Eingriff in die Privatsphäre. Zudem werden sicherlich auch Ihre B2B-Kunden, deren Daten Sie verwalten, die zusätzlichen Bemühungen, Privacy by Design zu gewährleisten, zu schätzen wissen und diese Botschaft vielleicht an ihre Kunden weitergeben. Nicht zuletzt kann es auch der Fall sein, dass das Unternehmen selbst diese Themen als normalen Bestandteil des Geschäftsalltags betrachtet.
Eine Datenschutzkultur aufzubauen, in der die in diesem Buch aufgeworfenen Fragen zu einem selbstverständlichen Teil der Gespräche rund um das Thema Daten werden, ist ein langjähriger Weg. Wie beim Aufbau einer Sicherheitskultur wird es sicherlich einige Personen geben, die sich sofort für das Thema begeistern können (wie Sie vielleicht?) und andere darauf aufmerksam machen.
Die Sicherheitscommunity hat großartige Arbeit beim Aufbau von Unternehmenskulturen geleistet. Wenn Sie eine Brücke zu den Sicherheitsexpertinnen und -experten in Ihrem Unternehmen schlagen und in Erfahrung bringen können, wie es ihnen gelingt, Sicherheit in die Unternehmenskultur zu integrieren und Befürworter im gesamten Unternehmen zu gewinnen, können Sie herausfinden, wie Sie dies auch beim Datenschutz erreichen können. Wie Sie feststellen werden, sind die Sicherheitsbeauftragten oft dazu bereit, sich im Rahmen ihrer normalen Aufklärungsarbeit für Datenschutz stark zu machen.7
Letztlich geht es darum, sicherzustellen, dass sich möglichst viele Menschen aus verschiedenen Blickwinkeln mit diesen Themen befassen. Das heißt nicht, dass sich alle daran beteiligen müssen, aber es sollten ausreichend viele sein, damit keine Dinge durch die Maschen rutschen und im Deployment oder in der Nähe des Deployments landen, ohne dass jemand zuvor den Schutz der Daten bedacht hat.
In diesem Kapitel haben Sie gelernt, wie Sie den Datenschutz in Pipelines automatisieren können, indem Sie zunächst die Datenschutzanforderungen des Systems analysieren und nach geeigneten Stellen suchen, an denen Sie Datenschutz berücksichtigen können. Herzlichen Glückwunsch! Damit sind Sie einen wichtigen Schritt in Richtung Integration des Datenschutzes in Ihre Datenworkflows und Produkte gegangen.
Dabei haben Sie gelernt, wie Arbeitsabläufe und Workflows datenschutzgerecht gestaltet werden können. Außerdem haben Sie neue Datenschutz- und Data-Governance-Technologien an verschiedenen Stellen der Pipeline implementiert. Sie hatten die Gelegenheit, eine Differential-Privacy-Bibliothek auszuprobieren, die Sie in Spark-basierte Systeme integrieren können. Sie haben lokale Differential Privacy und Differential-Privacy-Mechanismen, die im Rahmen der Erfassung von Daten zum Einsatz kommen können, kennengelernt. Darüber hinaus haben Sie sich damit beschäftigt, wie Sie teamübergreifend und unternehmensweit zusammenarbeiten können, damit das Bewusstsein für den Datenschutz in allen Teams, die für das Management von Datenworkflows verantwortlich sind, gestärkt wird.
Im nächsten Kapitel erfahren Sie mehr über Angriffe auf die Privatsphäre. Dadurch erhalten Sie eine bessere Vorstellung davon, wovor Sie sich schützen wollen, und können besser nachvollziehen, welche Risiken für die Privatsphäre (bzw. auch hinsichtlich des Datenschutzes) bestehen.
