Differential Privacy in einem Absatz, und wo sie nicht passt

Worum es geht

NIST SP 800-226 beschreibt Differential Privacy als mathematisches Rahmenwerk, das den Datenschutzverlust für Einheiten quantifiziert, deren Daten in einem Datensatz erscheinen. Die Kurzfassung: Ein Mechanismus, der Abfragen zu einem Datensatz beantwortet, ist differentiell privat, wenn sich seine Ausgabeverteilung nur um einen begrenzten, durch Epsilon parametrisierten Faktor ändert, wenn der Datensatz einer einzelnen Person hinzugefügt oder entfernt wird. Der Mechanismus erreicht dies, indem er den Ergebnissen kalibriertes Zufallsrauschen hinzufügt, und jede beantwortete Abfrage verbraucht einen Teil eines Datenschutzbudgets. Die Garantie ist eine Eigenschaft des Mechanismus, nicht der Daten, und sie gilt unabhängig davon, was ein Angreifer sonst weiss. Es gibt Umsetzungen: Googles Differential-Privacy-Repository stellt Baustein-Bibliotheken mit Primitiven zur Rauschzugabe und differentiell privaten Aggregationen, End-to-End-Frameworks sowie eine Buchhaltungsbibliothek zur Verfolgung des Datenschutzbudgets bereit.

Warum es wichtig ist

Ihre Garantie gilt unabhängig von Zusatzwissen und bleibt auch über wiederholte Abfragen hinweg kombinierbar – genau dort, wo Unterdrückung und Aggregation gar keine Garantie geben. NIST SP 800-226 benennt zudem Datenschutzrisiken: typische Fallstricke, die entstehen, wenn die Mathematik in Software umgesetzt wird.

So wird es angewendet

• Passt: Veröffentlichen aggregierter Statistiken (Zählungen, Summen, Mittelwerte, Histogramme) über eine grosse Population, besonders wenn die Veröffentlichung wiederholt erfolgt oder als Abfrageschnittstelle bereitgestellt wird, und wenn der Genauigkeitsverlust durch Rauschen bei den betroffenen Populationsgrössen hinnehmbar ist.
• Passt nicht: Daten auf Einzelfallebene (eine Kundentabelle lässt sich nicht differentiell privat machen und dabei eine Kundentabelle bleiben); kleine Gruppen, in denen das Rauschen das Signal überdeckt; Operationen, die exakte Antworten brauchen (Abrechnung, die eigenen Daten einer Person, Abstimmung); Freitext und Bilder; einmalige interne Analysen, bei denen Zugriffskontrolle plus Pseudonymisierung einfacher und ausreichend ist.
• Eine Bibliothek verwenden statt Rauschen von Hand hinzuzufügen: NIST SP 800-226 hält fest, dass Praktiker gut getestete Implementierungen aus Bibliotheken verwenden sollten, statt die Mechanismen selbst zu implementieren, und listet Fliesskomma-Arithmetik unter den Datenschutzrisiken.
• Epsilon und das Gesamtbudget pro Veröffentlichung als dokumentierte Produktentscheidung festlegen; jede Veröffentlichung gegen das Budget protokollieren.
• Die rohe pseudonymisierte Tabelle und die differentiell private Veröffentlichung getrennt halten; beides denselben Konsumenten zu geben, hebt den Sinn auf.

Stolpersteine

Ein grosses Epsilon wählen, um die Genauigkeit zu erhalten, und das Ergebnis dann als privat bezeichnen; NIST SP 800-226 weist darauf hin, dass grosse Epsilon-Werte keinen aussagekräftigen Datenschutz bieten müssen. Den Mechanismus pro Abfrage anwenden, ohne die Summe zu verfolgen. Ihn als Ersatz für Datenminimierung und Aufbewahrungsbegrenzung statt als Veröffentlichungsmechanismus für Aggregate behandeln.