Wie anonymisiert man neue Protokolldatensätze, ohne die Beziehungen zwischen alten und neuen Daten zu unterbrechen?

Question

Ich erzeuge Protokolldatensätze über Benutzeraktionen. Aus Datenschutzgründen müssen diese nach N Tagen anonymisiert werden. Ich muss jedoch auch Berichte über diese anonymisierten Daten erstellen.

Ich möchte alle Aktionen von realen Benutzer A unter gefälschten Benutzer X in den anonymisierten Protokollen aufgeführt werden - Datensätze von einem Benutzer müssen immer noch Datensätze von einem (falschen) Benutzer in den Protokollen bleiben. Dies bedeutet natürlich, dass ich eine Zuordnung zwischen echten und gefälschten Benutzern haben muss, die ich bei der Anonymisierung neuer Datensätze verwende. Damit wird die Anonymisierung natürlich komplett zunichte gemacht - bei einer Zuordnung können die ursprünglichen Benutzerdaten wiederhergestellt werden.

Beispiel:

Benutzer Frank Müller gekauft 3 Dosen Suppe.

Drei Tage später bat Benutzer Frank Müller um Erstattung für 3 Dosen Suppe.

Wenn ich den zweiten Protokolleintrag anonymisiere, wurde der erste bereits anonymisiert. Ich möchte immer noch, dass beide Protokolldatensätze auf denselben Benutzer verweisen. Nun, das scheint mir in der Praxis fast unmöglich zu sein, deshalb möchte ich eine Methode der Datenaufteilung verwenden, die mir hoffentlich erlaubt, so viel Integrität wie möglich in den Daten zu halten. Vielleicht die Logs als Data Warehouse nutzen - alles in Fakten aufteilen und einfach akzeptieren, dass einige Dimensionen nicht analysiert werden können?

Sind Sie schon einmal auf ein solches Szenario gestoßen? Was sind meine Möglichkeiten hier? Ich muss natürlich einen Kompromiss eingehen - was hat sich für Sie als effektiv erwiesen? Wie kann man solche Daten optimal nutzen?

Answer 1

Auf die Gefahr pedantisch, was Sie beschreiben, ist nicht anonym Daten, sondern pseudonyme Daten. Haben Sie darüber nachgedacht, eine Art von Keyed-Hash-Funktion wie HMAC-SHA1 zu verwenden, um die Pseudonymgenerierung durchzuführen? Sie können einen fairen Kompromiss mit einem Schema wie folgt erreichen:

• Trennen Sie Ihre Analyse und OLTP-Datenbanken. Minimieren Sie die Anzahl der Personen, die Zugriff auf beide haben.
• Behalten Sie den HMAC-Schlüssel für die Anwendung privat, die Daten in die Analysedatenbank kopiert, auf die in keiner der Datenbanken zugegriffen werden kann. Vielleicht muss die Anwendung sie bei der Installation generieren und sie mit einem fest codierten Schlüssel verschleiern, so dass weder die Systemadministratoren noch die Softwareentwickler es als trivial erachten, ohne Absprachen zu erreichen.
• Kopieren Sie keine echten Namen und Adressen oder gleichwertige oder einfach verknüpfbare Schlüssel wie Benutzernummer, Rechnungsnummern usw. aus der OLTP-Datenbank ohne Hashing.

Wenn Sie dies tun, gibt es zwei Hauptwege des Angriffs, um die wahre Identität aus dem Pseudonym zu erhalten.

• Direkter Angriff: Besorgen Sie sich den HMAC-Schlüssel, berechnet das Pseudonym für jeden bekannten Benutzer, und umgekehrt die Suche in der Ergebnistabelle. (HMAC ist irreversibel: gegeben nur ein Pseudonym und der Schlüssel können Sie nicht in der Lage, den ursprünglichen Wert zu erhalten.)
• Information Fusion Angriff: Ohne Kenntnis des Schlüssels und der Liste der Identitäten, ist die nächst beste Sache einfach zu versuchen, das Pseudonym zu korrelieren Daten mit anderen Daten - vielleicht sogar eine gestohlene Kopie der OLTP-Datenbank.

Pseudonymous Datensätze sind notoriously vulnerable zu Informationen Fusion Angriffe - Sie haben zu Streifen oder „Unschärfe“ eine Menge Schlüssel korrelierende Informationen, die Daten zu machen gesetzt resistent gegen solche Angriffe, aber ganz genau, wie viel müssen Sie strippen ist ein topic of current research.