Synthetische Daten gegen anonymisierte Daten: Was der Unterschied bedeutet

Synthetische Daten gegen anonymisierte Daten klingt wie die Wahl zwischen zwei Sorten derselben Sache, und wer es so behandelt, bekommt echten Ärger. Eines der beiden hat nie jemandem gehört; das andere hat jemandem gehört und wurde verarbeitet, um diese Person zu entfernen. Der Unterschied entscheidet, wer die Daten sehen darf, wie lange sie aufbewahrt werden dürfen und ob sie überhaupt außerhalb der Organisation geteilt werden können.

Dieser Artikel legt die vier Ansätze dar, die tatsächlich verwendet werden, was jeder garantiert und was nicht, und warum das Kombinieren von Feldern das Detail ist, an dem die meisten Versuche des Entfernens still scheitern.

Die vier Ansätze im Vergleich

Die meisten Testdatensätze entstehen nach einer von vier Methoden, und sie werden häufig mit demselben Wort beschrieben.

Nur der erste beginnt bei nichts. Die anderen drei starten alle bei echten Datensätzen, weshalb jeder von ihnen eine Pflicht erbt, die der erste nie hatte.

Warum anonymisiert das Entfernen von Namen einen Datensatz nicht?

Weil ein Name nur eine von vielen Möglichkeiten ist, eine Person herauszugreifen, und meist nicht die zuverlässigste. Eine Tabelle ohne Namensspalte sagt Ihnen immer noch, dass eine Frau in ihren Dreißigern bei einem bestimmten kleinen Arbeitgeber in einer bestimmten kleinen Stadt arbeitet, und in dieser Bevölkerung gibt es womöglich genau eine solche Person. Anonymisiert wurde nichts; die Kennung wurde lediglich durch eine Menge von Kennungen ersetzt, die etwas mehr Aufwand erfordern.

Die statistische Fassung desselben Problems ist, dass jeder Datensatz Quasi-Kennungen trägt — Werte, die für sich nicht eindeutig sind, in Kombination aber eindeutig werden. Geburtsdatum, Postleitzahl, Geschlecht und Beruf sind der klassische Satz, und die Arithmetik ist unbarmherzig: Eine Kombination, die über ein ganzes Land breit wirkt, kann innerhalb einer Stadt eindeutig sein, und eine Testdatenbank ist meist ein Ausschnitt eines Marktes und keine Stichprobe der Welt.

Die Re-Identifikation ist deshalb nichts Exotisches. Sie ist die gewöhnliche Folge daraus, ein paar Spalten gegen öffentlich verfügbare Informationen zu kombinieren, und sie wird mit jedem zusätzlich verfügbaren Datensatz leichter. Deshalb muss sich eine ehrliche Anonymisierungsaussage mit dem befassen, was übrig bleibt, und nicht nur mit dem, was gelöscht wurde.

Was gilt tatsächlich als anonym?

Daten sind anonym, wenn die darin enthaltenen Personen von niemandem identifiziert werden können, und zwar mit jedem Mittel, dessen Verwendung vernünftigerweise wahrscheinlich ist — eine stärkere Bedingung, als die meisten Teams annehmen, weil auch anderweitig gehaltene Informationen dazuzählen. Praktisch heißt das, dass eine ordentliche Anonymisierungsaussage auf einer dokumentierten Bewertung ruht: welche Felder entfernt oder vergröbert wurden, wie die verbleibende Bevölkerung aussieht, was in Kombination bleibt und warum eine Identifikation vernünftigerweise nicht möglich ist.

Zwei Konsequenzen sind ernst zu nehmen. Erstens: Die Bewertung gilt für einen Datensatz und einen Kontext, ein Ansatz, der für eine Freigabe funktioniert, tut es für die nächste womöglich nicht, wenn neue Spalten dazukommen. Zweitens: Die Bewertung ist wirklich schwer, weil der Beweis einer Verneinung über Identifikation viel mehr Arbeit ist als der Nachweis, dass eine Zeichenspalte entfernt wurde.

Wo die Schwierigkeit hoch ist, lautet die ehrliche Antwort meist, die Daten aufzuhören anonym zu nennen. Pseudonymisiert, eingeschränkt oder nur intern sind alles vertretbare Beschreibungen; anonym ist eine Aussage, die verdient werden muss.

Welchen Ansatz sollte eine Testumgebung wählen?

Synthetische Daten, in der großen Mehrheit der Fälle, weil sie die Pflicht entfernen statt sie zu verwalten. Ein aus Regeln und einer festen Eingabe erzeugter Datensatz enthält überhaupt keine Personen, es gibt also keine Aufbewahrungsfrist, keine Einwilligungsfrage, keinen Löschantrag zu erfüllen und keinen Vorfall zu melden, wenn er leakt. Er kann ohne zweiten Gedanken darüber, wessen Informationen er enthält, in ein Test-Repository übernommen, zwischen Teams verschickt und in ein Ticket kopiert werden.

Er umgeht außerdem ein praktisches Problem, das verkleidete Daten immer wieder erzeugen: die Zuordnung. Pseudonymisierte Daten brauchen eine irgendwo aufbewahrte Zuordnung, und diese Zuordnung ist selbst ein sensibler Datensatz, der geschützt, gewechselt und geprüft werden muss. Teams wenden routinemäßig mehr Mühe für den Schutz der Zuordnung auf, als die Erzeugung der Daten gekostet hätte.

Was synthetische Datensätze nicht tun, ist, jede Eigenschaft echter Daten automatisch nachzubilden. Hängt ein Test an der Verteilung — der Häufigkeit eines seltenen Randfalls, der Korrelation zweier Felder, der Form eines langen Ausläufers —, muss das bewusst modelliert und nicht geerbt werden. Die Anforderungen an die Feldkonsistenz sind ein Beispiel dafür: Ein Erzeuger muss so gebaut sein, dass verwandte Felder übereinstimmen, weil der Zufall allein das nicht schafft.

Wie halten Sie einen erzeugten Datensatz wiederholbar?

Indem Sie ihn zu einer Funktion einer Eingabe machen, die Sie kontrollieren, statt einer Uhr oder einer Zufallsquelle, die Sie nicht wiederholen können. Die übliche Anordnung ist ein Startwert: ein kurzer, von Menschen notierbarer Wert, der jede Entscheidung des Erzeugers treibt, sodass derselbe Startwert auf jeder Maschine und an jedem Tag dieselben Datensätze liefert.

Wiederholbarkeit zählt aus drei Gründen, die man unter Zeitdruck leicht vergisst. Ein automatisierter Test kann ein festes Beispiel halten und dagegen zusichern, ein Fehler ist also diagnostizierbar und kein Münzwurf. Ein Fehlerbericht kann den genauen Datensatz benennen, den er gesehen hat, sodass ihn jede Person auf der eigenen Maschine nachbauen kann. Und eine Durchsicht kann eine Vorführung exakt wiederholen, was zählt, wenn ein Datensatz als Beleg dafür angeboten wird, dass keine echten Datensätze beteiligt sind.

Erzeugte Datensätze aus dem Identitätsdatensatz-Erzeuger arbeiten so, und die Werte folgen den echten Formatierungskonventionen jedes Landes, während sie vollständig erfunden bleiben. Es sind synthetische Datensätze allein für Softwaretests; sie beschreiben keine echte Person, und sie können nicht an ihre Stelle treten oder eine echte Prüfung bestehen.

Wie belegen Sie, dass ein Testdatensatz keine echten Datensätze enthält?

Indem Sie beschreiben können, woher jeder Wert stammt. Das ist eine Frage der Herkunft, und sie wird zur Erzeugungszeit beantwortet und nicht zur Prüfungszeit. Ein Datensatz, der durch Ausführen eines Erzeugers mit bekanntem Startwert entsteht, aus einem Erzeuger, der keine Produktionsquelle liest, hat eine Antwort aus einem Satz. Ein Datensatz, der durch Umformung eines Produktionsexports entsteht, hat eine Antwort, die davon abhängt, dass die Umformung korrekt ist, und die Last dieses Belegs geht nie ganz weg.

Zwei Gewohnheiten machen die Herkunft haltbar. Kennzeichnen Sie die Daten selbst — eine Spalte oder einen Kopf, der Zeilen als synthetisch markiert —, damit eine Kopie, die in ein Ticket, eine Tabelle oder einen Screenshot wandert, weiterhin ansagt, was sie ist. Und halten Sie den Erzeugungsschritt in der Versionsverwaltung, damit derselbe Datensatz erneut herzustellen ein Befehl ist statt einer mündlichen Überlieferung.

Eine letzte Prüfung lohnt sich für jeden Datensatz, der sich als sicher bezeichnet: Versuchen Sie, eine Person darin zu identifizieren. Gelingt der Versuch auch nur einmal, war die Aussage zu weit gefasst, und die richtige Antwort ist eine engere Aussage und nicht eine lautere.

Für Entwickler: Startwerte, Verteilungen und ehrliche Aussagen

Entwerfen Sie den Erzeuger so, dass jede zufällige Entscheidung über einen einzigen dokumentierten Pfad aus dem Startwert fließt. Zwei Erzeuger, die beide einen Startwert annehmen, den Zufall aber in verschiedener Reihenfolge verbrauchen, werden sich uneinig sein, und die Uneinigkeit sieht wie ein Fehler im Test aus und nicht im Erzeuger.

Modellieren Sie die Verteilung bewusst. Echte Daten haben von allem ungleiche Mengen, und eine gleichverteilte Ziehung erzeugt einen zu aufgeräumten Datensatz: keine seltenen Namen, keine ungewöhnlichen Alter, keine fehlenden Felder. Braucht der Test einen langen Ausläufer, muss der Erzeuger einen mit Absicht liefern, und das ist eine Spezifikationsfrage zu den Daten und keine Eigenschaft, die von selbst entsteht.

Halten Sie die Aussage über die Daten eng und wahr. Synthetisch und für Tests erzeugt ist eine Aussage, die sich durch Lesen des Erzeugungsschritts überprüfen lässt. Das ist für eine Prüfung weit mehr wert als eine breitere Aussage über Anonymität, die niemand reproduzieren kann. Und tragen Sie die Einschränkung in die Fixture-Vermerke: So erzeugte Datensätze existieren, um Software durchzuspielen, nicht um sich als jemand auszugeben oder irgendwo als echte Identität angeboten zu werden.

Nächste Schritte

Finden Sie einen Datensatz in Ihren Testumgebungen, dessen Herkunft niemand nennen kann, und verfolgen Sie ihn; diese Antwort ist meist interessanter als der Datensatz selbst. Ersetzen Sie ihn dann durch einen erzeugten Stapel und notieren Sie den Startwert neben den Daten, damit jede Person ihn nachbauen kann. Wenn Sie die Alternativen abwägen, behandelt der Artikel über die Datenschutzregeln für Testdaten, wozu Sie jede Wahl anschließend verpflichtet.