DSGVO und Testdaten ist eine Wendung, die meist mit einer unangenehmen Erkenntnis ankommt: Die Staging-Datenbank, die alle frei abgefragt haben, enthält echte Namen, echte Adressen und echte Identifikationsnummern, und niemand hat je entschieden, dass das erlaubt sein soll. Es war einfach bequem.
Dieser Artikel behandelt, was in einem Testdatensatz als personenbezogenes Datum zählt, warum Entwicklungsumgebungen der falsche Ort für Produktionskopien sind, den Unterschied zwischen dem Verkleiden von Daten und ihrem Entfernen und wie ein brauchbarer Ersatz aussieht.
Was zählt hier als personenbezogenes Datum?
Mehr, als man erwartet, und die Liste ist verhaltensbezogen und nicht technisch. Ein Name, eine Identifikationsnummer, ein Geburtsdatum, eine Wohnadresse, eine Telefonnummer und eine E-Mail-Adresse sind die offensichtlichen Mitglieder. Weniger offensichtliche kommen hinzu: ein Lichtbild, eine Gerätekennung, eine Standortspur, ein Kontoname und jede Notiz in einem Supportsystem, die zufällig jemanden beschreibt.
- Offensichtliche Mitglieder: ein Name, eine Identifikationsnummer, ein Geburtsdatum, eine Wohnadresse, eine Telefonnummer und eine E-Mail-Adresse
- Weniger offensichtliche: ein Lichtbild, eine Gerätekennung, eine Standortspur, ein Kontoname
- Ebenfalls personenbezogen: jede Notiz in einem Supportsystem, die zufällig jemanden beschreibt
Der Begriff ist über die Person definiert und nicht über das Feld. Daten sind personenbezogen, wenn sie sich auf eine identifizierbare Person beziehen, unmittelbar oder mittelbar; ein Feld muss also keinen Namen enthalten, um personenbezogen zu sein. Ein Datensatz mit Geburtsdatum, Postleitzahl und Berufsbezeichnung kann personenbezogen sein, wenn diese drei zusammen eine Person in der abgedeckten Bevölkerung herausgreifen.
Diese Definition macht die Testumgebung zu einer laufenden Frage statt zu einer Formalie. Enthält die Staging-Datenbank irgendetwas davon, verarbeitet Staging personenbezogene Daten, und jede Argumentation zu Aufbewahrung, Zugriff und Sicherheit gilt nun für ein System, das ohne sie entworfen wurde.
Warum sollten Testsysteme keine Produktionsdaten halten?
Weil die Kontrollen, die die Produktion schützen, genau die sind, die niedrigeren Umgebungen fehlen. Die Produktion hat meist eingeschränkten Zugriff, verschlüsselte Speicherung, Prüfprotokolle und einen Änderungsprozess. Staging hat typischerweise keines der vier, weil es bequem sein soll. Einen Datensatz hineinzukopieren ist damit eine Herabstufung des Schutzes, angewandt auf die sensibelsten Datensätze, die die Organisation hält.
Daraus folgen drei Konsequenzen, jede auf ihre Weise teuer. Der Zugriff vervielfacht sich: jede Auftragskraft, jedes automatisierte Testkonto und jeder Laptop, der einen Abzug wiederherstellt, hält nun personenbezogene Daten. Die Aufbewahrung wird zufällig: Die Kopie wird aktualisiert, vergessen, gesichert und in einem Speicher gelassen, der niemandem gehört. Und der Umfang eines Vorfalls wächst: Wenn irgendwo ein routinemäßiges Leck passiert, lautet die Frage nicht mehr, welche Systeme betroffen waren, sondern wie viele Kopien existieren.
Der regulatorische Blick ist enger als der technische, zeigt aber in dieselbe Richtung. Personenbezogene Daten müssen für festgelegte Zwecke erhoben und dürfen nicht für unvereinbare Zwecke verwendet werden; Produktionsdatensätze still zum Testen einer Migration wiederzuverwenden, ist also ein neuer Zweck, dem niemand zugestimmt hat. Nichts davon ist auf ein einziges Rechtssystem beschränkt; dieselbe Überlegung erscheint in den meisten Datenschutzordnungen, weshalb der praktische Ratschlag zusammenläuft.
Was ist der Unterschied zwischen Anonymisierung und Pseudonymisierung?
Diese beiden werden ständig als Synonyme behandelt, und sie sind es nicht. Bei pseudonymisierten Daten wurden direkte Kennungen durch einen Code ersetzt, wobei die Zuordnung irgendwo erhalten bleibt. Der Datensatz lässt sich ohne diese Zusatzinformation nicht zuordnen, aber die Verknüpfung existiert weiterhin und kann verfolgt werden, wenn die Zuordnung leakt. Anonymisierte Daten wurden so verarbeitet, dass die Person von niemandem mehr identifiziert werden kann, auch nicht von der Organisation, die sie hält, und die Umformung lässt sich nicht rückgängig machen.
Dieser Unterschied entscheidet, ob die Daten weiterhin personenbezogen sind. Pseudonymisierte Datensätze bleiben für die meisten Zwecke personenbezogen, weil ein Schlüssel existiert. Anonymisierte Datensätze, richtig gemacht, sind es nicht — doch eine ordnungsgemäße Anonymisierung zu belegen ist wirklich schwer, und diese Schwierigkeit macht die Verwendung von Produktionsdaten für Tests zu einem so schlechten Tausch.
Es gibt eine zweite Falle jenseits der direkten Kennungen. Namen aus einer Tabelle zu entfernen anonymisiert sie nicht, weil Kombinationen der übrigen Felder Personen identifizieren. Eine seltene Berufsbezeichnung in einer kleinen Stadt genügt oft schon allein. Bei einer rechtlichen Prüfung lautet die richtige Frage nicht, ob ein Name vorhanden ist, sondern ob jemand die Person vernünftigerweise aus dem verbleibenden Rest identifizieren könnte, mit Informationen, die er hat oder beschaffen kann.
Lösen Maskierung und Löschen das Problem?
Die Maskierung ersetzt sensible Zeichen durch ein festes Muster und ist für die Anzeige hervorragend: Eine Supportkraft sieht die letzten vier Ziffern einer Nummer, während der Rest verborgen ist. Anonymisierung ist sie nicht, weil der ursprüngliche Wert meist weiterhin gespeichert ist, und eine Maskierungsschicht vor einem echten Datensatz ändert an dem echten Datensatz nichts.
Das Löschen einzelner Felder hat dieselbe Schwäche in anderem Gewand. Nehmen Sie den Namen heraus, und der Datensatz hat weiterhin eine Adresse, ein Geburtsdatum und eine Telefonnummer. Ersetzen Sie auch die Adresse, und die verbleibenden Felder können immer noch eine Person in der Bevölkerung herausgreifen. Jede Entfernung verkleinert das Risiko, ohne es zu schließen, und selten gibt es einen klaren Punkt, an dem jemand beweisen kann, dass das Risiko null erreicht hat.
Dazu kommt ein Dokumentationsproblem. In der Praxis können Teams nicht zeigen, welche Datensätze ordnungsgemäß anonymisiert und welche bloß verkleidet wurden, weil die Umformung beiläufig geschah und keine Spur hinterließ. Ein Datensatz, dessen Herkunft niemand rekonstruieren kann, lässt sich später nicht verteidigen.
Was sollte Produktionskopien ersetzen?
Datensätze, die nie jemandem gehört haben. Das ist das Argument dafür, Daten zu erzeugen statt sie zu ernten, und es ist der Grund, warum synthetische Datensätze die Datenschutzfrage und die Qualitätsfrage auf einmal lösen. Es gibt nichts zu schützen, nichts aufzubewahren, nichts zu leaken und keine Zweckbindung zu erörtern, weil die Daten nie einer Person gehört haben.
Erzeugte Datensätze verhalten sich in Tests auch besser. Werte aus dem Identitätsdatensatz-Erzeuger sind in sich stimmig — Adresse, Postleitzahl und Telefonvorwahl gehören zum selben Land, und Kennungsformate folgen dessen Konventionen —, ein Testdatensatz muss also nicht von Hand repariert werden. Es sind synthetische Datensätze allein für Softwaretests, und sie sind nicht dazu brauchbar, sich als echte Person auszugeben oder eine echte Identitäts-, Alters- oder Berechtigungsprüfung zu bestehen.
Der ehrliche Vorbehalt ist, dass synthetische Daten nicht automatisch jede Korrelation der echten Welt nachbilden. Hängt ein Test wirklich an der statistischen Form echter Daten, muss diese Form bewusst modelliert werden, und der Vergleich der Ansätze legt dar, was Modellierung bedeutet und wo sie zu kurz greift.
Wie halten Sie Personendaten aus Protokollen und Screenshots?
Das Leck ist selten die Datenbank. Es ist das Abfrageprotokoll, das einen vollständigen Datensatz mitgeschrieben hat, der Fehlerbericht, in dem der Anfragekörper steckt, der Screenshot am Ticket, die für die Analyse exportierte und im Ablageordner gelassene Tabelle und der lokale Abzug, den jemand genommen hat, um einen Defekt im Flugzeug nachzustellen.
Drei Kontrollen verringern das meiste davon. Erstens: Halten Sie echte Datensätze aus Umgebungen heraus, in denen Protokolle ausführlich sind — ein direktes Argument für synthetische Daten in Staging. Zweitens: Behandeln Sie einen Screenshot oder Export so, als enthielte er, was der Bildschirm enthielt, und verlangen Sie, dass Testergebnisse aus Umgebungen stammen, die keine echten Datensätze halten. Drittens: Machen Sie die Aufbewahrung ausdrücklich: Eine Kopie, die für einen Zweck existiert, sollte ein Enddatum haben, und eine Kopie ohne Enddatum ist keine Kopie, sondern eine zweite Produktionsdatenbank.
Auch die Zugriffsüberprüfung gehört hierher. Zu wissen, wer den Datensatz erreichen kann, nützt nur, wenn die Antwort kürzlich geprüft wurde, und in dem Moment, in dem eine Kopie breit geteilt wird, hört diese Überprüfung auf, aussagekräftig zu sein.
Für Entwickler: Trennung, Herkunft und Nachweis
Trennen Sie die Umgebungen, statt einen Datenstrom in den anderen zu filtern. Eine Entwicklungsumgebung sollte durch einen Erzeugungsschritt befüllt werden, nie durch eine Wiederherstellung aus der Produktion, und die Verbindung von der Entwicklung zur Produktion sollte gar nicht existieren — nicht bloß ungenutzt sein.
Kennzeichnen Sie die Herkunft der Daten im Datensatz selbst. Eine Markierung, die besagt, dass diese Zeilen synthetisch und nur für Tests sind, übersteht den Export, den Screenshot und das Supportticket, und sie sagt einer späteren Leserin alles Nötige darüber, was sie vor sich hat. Sie ist die billigste verfügbare Absicherung und die am häufigsten ausgelassene.
Bereiten Sie schließlich die Antwort auf die Frage vor, die eine Prüfung stellen wird: Woran erkennen Sie, dass dieser Datensatz keine echten Datensätze enthält? Ein Erzeugungsschritt, der aus einem Startwert läuft und nie eine Produktionsquelle liest, ist eine nachweisbare Antwort. Eine Verarbeitungskette, die einen Produktionsexport umgeformt hat, ist es nicht, so gründlich die Umformung in der Durchsicht auch wirken mag. Nachweisbare Abwesenheit schlägt belegbare Verkleidung jedes Mal.
Nächste Schritte
Finden Sie heraus, ob Ihre Staging-Datenbank aus einem Produktionsabzug wiederhergestellt wurde, und falls ja, begründen Sie den Ersatz durch erzeugte Zeilen vor der nächsten vierteljährlichen Zugriffsüberprüfung. Gehen Sie dann einen Fehlerbericht vom letzten Monat durch und zählen Sie, an wie vielen Stellen die Details einer echten Person darin gereist sind — Protokolle, Anhänge, Screenshots —, denn diese Zahl ist der Maßstab, gegen den der Ersatz antritt. Wenn Sie umstellen, erzeugen Sie den ersten Stapel im Identitätsdatensatz-Erzeuger und kennzeichnen Sie jede Zeile als synthetisch, bevor sie importiert wird.