Aus dem Produktivabzug eine brauchbare Testkopie machen
Die Kunst besteht darin, die Daten so weit zu entschärfen, dass sie niemandem mehr zuzuordnen sind, und so realistisch zu lassen, dass Tests damit noch etwas aussagen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Kopie des Produktivsystems ist der bequemste Weg und der riskanteste
Für einen belastbaren Test braucht es echte Datenmengen, echte Sonderfälle und echte Verteilungen. Deshalb landet in vielen Häusern der nächtliche Abzug der Produktivdatenbank unverändert auf dem Entwicklungssystem. Dort gelten dann andere Regeln: mehr Konten mit Zugriff, schwächere Absicherung, Kopien auf Notebooks, Zugriff durch externe Dienstleister, und die Sicherung des Testsystems liegt an einem anderen Ort als die des Produktivsystems.
Damit wandert der komplette personenbezogene Bestand in eine Umgebung, die für ihn nicht gebaut ist. Das ist weniger ein hypothetisches Risiko als eine Frage der Zeit, denn Testsysteme werden kopiert, umgezogen und für Vorführungen benutzt. Und anders als beim Produktivsystem merkt niemand, wenn eine Kopie liegen bleibt.
Der übliche Gegenvorschlag, einfach synthetische Daten zu erzeugen, löst das Problem nur zum Teil. Erzeugte Bestände enthalten die Sonderfälle nicht, an denen Software tatsächlich scheitert: den Kunden mit vierzig Lieferadressen, den Auftrag ohne Position, den Datensatz aus der Migration von 2011 mit dem falschen Zeichensatz. Genau deshalb ist die entschärfte Kopie in den meisten Fällen der bessere Weg.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wer entscheidet, wer setzt um
Anonymisierung scheitert selten am Skript. Sie scheitert daran, dass niemand entschieden hat, welche Felder heikel sind, und dass die Freigabe der Kopie keine benannte Stelle hat.
| Thema | Wer entscheidet | Wer setzt um | Stolperfalle |
|---|---|---|---|
| Welche Felder entschärft werden müssen | Der Fachbereich als Eigentümer der Daten, gemeinsam mit dem Datenschutz | Die Entwicklung pflegt die Regeln je Spalte, das Datenbankteam führt sie beim Abzug aus | Entschieden wird über die offensichtlichen Felder. Freitextnotizen, Betreffzeilen aus dem Schriftverkehr und Protokolltabellen bleiben unberührt und enthalten dieselben Angaben im Klartext. |
| Wie stark der Bestand verkleinert wird | Die Testverantwortung gemeinsam mit der Entwicklung, abhängig davon, was getestet werden soll | Das Datenbankteam über eine Auswahlregel, die von den Bewegungsdaten ausgeht und die Stammdaten vollständig lässt | Ein zu kleiner Bestand macht Lasttests wertlos, weil der Optimizer bei anderer Datenmenge andere Pläne wählt. Was auf der kleinen Kopie schnell ist, kann in der Produktion stehen bleiben. |
| Wer die fertige Kopie freigibt | Die Stelle, die auch über Zugriffe auf die Produktivdaten entscheidet | Der Betrieb, der die Kopie erst nach bestandener Prüfung aus der Zwischeninstanz herausgibt | Der unbearbeitete Abzug liegt für die Dauer der Bearbeitung irgendwo. Liegt dieses Zwischenlager auf dem Testsystem, war die ganze Anonymisierung umsonst. |
| Wann der Vorgang wiederholt wird | Die Entwicklung meldet den Bedarf, der Betrieb setzt den Rhythmus | Ein Job, der Rückspielen, Anonymisieren und Prüfen in einem Durchlauf erledigt | Beim ersten Mal läuft alles ordentlich, ein Jahr später zieht jemand schnell einen Abzug von Hand, weil der Job Fehler wirft. Genau diese Handkopie landet ungeschützt im Test. |
| Wer prüft, ob es funktioniert hat | Der Datenschutz legt fest, was als Nachweis gilt | Eine automatische Stichprobe, die in der fertigen Kopie nach bekannten Namen, Adressen und Kennungen sucht | Ohne Gegenprobe fällt eine vergessene Spalte erst auf, wenn jemand im Testsystem zufällig den eigenen Namen findet, und dann ist die Kopie längst verteilt. |
Welche Felder entschärft werden müssen
- Wer entscheidet
- Der Fachbereich als Eigentümer der Daten, gemeinsam mit dem Datenschutz
- Wer setzt um
- Die Entwicklung pflegt die Regeln je Spalte, das Datenbankteam führt sie beim Abzug aus
- Stolperfalle
- Entschieden wird über die offensichtlichen Felder. Freitextnotizen, Betreffzeilen aus dem Schriftverkehr und Protokolltabellen bleiben unberührt und enthalten dieselben Angaben im Klartext.
Wie stark der Bestand verkleinert wird
- Wer entscheidet
- Die Testverantwortung gemeinsam mit der Entwicklung, abhängig davon, was getestet werden soll
- Wer setzt um
- Das Datenbankteam über eine Auswahlregel, die von den Bewegungsdaten ausgeht und die Stammdaten vollständig lässt
- Stolperfalle
- Ein zu kleiner Bestand macht Lasttests wertlos, weil der Optimizer bei anderer Datenmenge andere Pläne wählt. Was auf der kleinen Kopie schnell ist, kann in der Produktion stehen bleiben.
Wer die fertige Kopie freigibt
- Wer entscheidet
- Die Stelle, die auch über Zugriffe auf die Produktivdaten entscheidet
- Wer setzt um
- Der Betrieb, der die Kopie erst nach bestandener Prüfung aus der Zwischeninstanz herausgibt
- Stolperfalle
- Der unbearbeitete Abzug liegt für die Dauer der Bearbeitung irgendwo. Liegt dieses Zwischenlager auf dem Testsystem, war die ganze Anonymisierung umsonst.
Wann der Vorgang wiederholt wird
- Wer entscheidet
- Die Entwicklung meldet den Bedarf, der Betrieb setzt den Rhythmus
- Wer setzt um
- Ein Job, der Rückspielen, Anonymisieren und Prüfen in einem Durchlauf erledigt
- Stolperfalle
- Beim ersten Mal läuft alles ordentlich, ein Jahr später zieht jemand schnell einen Abzug von Hand, weil der Job Fehler wirft. Genau diese Handkopie landet ungeschützt im Test.
Wer prüft, ob es funktioniert hat
- Wer entscheidet
- Der Datenschutz legt fest, was als Nachweis gilt
- Wer setzt um
- Eine automatische Stichprobe, die in der fertigen Kopie nach bekannten Namen, Adressen und Kennungen sucht
- Stolperfalle
- Ohne Gegenprobe fällt eine vergessene Spalte erst auf, wenn jemand im Testsystem zufällig den eigenen Namen findet, und dann ist die Kopie längst verteilt.
Der Weg vom Produktivabzug zur freigegebenen Kopie
- 01 Der Abzug wird in eine abgeschottete Zwischeninstanz zurückgespielt.
- 02 Der Katalog wird gegen die Regeln geprüft, unbekannte Spalten halten an.
- 03 Schlüsselfelder werden deterministisch ersetzt, Beziehungen bleiben erhalten.
- 04 Freitexte, Anhänge und Protokolltabellen werden getrennt behandelt.
- 05 Eine Stichprobe sucht nach bekannten Namen und Adressen in der Kopie.
- 06 Erst nach dieser Prüfung geht die Kopie an Test und Entwicklung.
Was eine brauchbare Testkopie ausmacht
Eine gute Testkopie erfüllt zwei Bedingungen gleichzeitig: Niemand lässt sich darin wiedererkennen, und die Software verhält sich darauf so wie in der Produktion. Beides zusammen bekommt man nur mit einem Verfahren, das die Beziehungen zwischen den Tabellen kennt und bei jedem Abzug automatisch läuft.
Deterministisch ersetzen, wo verknüpft wird
Derselbe Ausgangswert muss überall dasselbe Ergebnis liefern, sonst zerfallen Verknüpfungen über Kundennummern hinweg. Ein geheimer Schlüsselwert im Verfahren verhindert, dass jemand ohne diesen Schlüssel die Zuordnung zurückrechnet. Wer ihn aufbewahrt, kann sie jederzeit herstellen, und damit bleibt die Kopie pseudonymisiert.
Formate erhalten, Inhalte tauschen
Eine IBAN mit falscher Prüfziffer bringt die Anwendung zum Stolpern, eine Adresse ohne Hausnummer den Druck. Ersetzt wird durch Werte, die dieselben Regeln erfüllen.
Datumsangaben verschieben statt löschen
Alle Daten eines Vorgangs um denselben Betrag zu verschieben erhält Abstände und Reihenfolgen. Ein Geburtsdatum durch NULL zu ersetzen macht jede Altersauswertung im Test unbrauchbar.
Freitexte und Anhänge mitdenken
Der Name steht selten nur im Namensfeld. Notizen, Betreffzeilen, Protokolltabellen und angehängte Dokumente enthalten dieselben Angaben und werden regelmäßig vergessen.
Verkleinern mit Blick auf die Beziehungen
Wer fünf Prozent der Kunden zieht, muss alle abhängigen Sätze dieser Kunden mitziehen und die Stammdaten vollständig lassen. Sonst laufen Tests in Fehler, die es in der Produktion nicht gibt.
Vollständigkeit erzwingen statt hoffen
Eine neue Spalte ohne Regel muss den Ablauf anhalten. Ein Abgleich gegen den Systemkatalog findet genau die Spalten, für die noch niemand entschieden hat, was mit ihnen geschieht.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Anonym und pseudonym sind nicht dasselbe
Der Unterschied entscheidet darüber, welche Regeln für das Testsystem gelten. Wirklich anonyme Daten lassen keinen Rückschluss auf eine Person zu, und Erwägungsgrund 26 der Datenschutz-Grundverordnung hält fest, dass die Grundsätze des Datenschutzes für solche Informationen nicht gelten. Pseudonymisierte Daten sind etwas anderes: Nach Artikel 4 Nummer 5 liegt Pseudonymisierung vor, wenn die Zuordnung mit zusätzlichen Informationen weiterhin möglich ist, und damit bleiben es personenbezogene Daten.
Übersetzt auf die Testkopie heißt das: Sobald es irgendwo eine Zuordnungstabelle oder einen wiederverwendbaren Schlüssel gibt, mit dem sich die ursprünglichen Werte zurückgewinnen lassen, ist die Kopie pseudonymisiert und nicht anonym. Sie braucht dann dasselbe Schutzniveau wie die Produktion, und genau das wollte man mit der Anonymisierung ja vermeiden. Wer ohne Zuordnungstabelle arbeitet und den verwendeten Schlüsselwert nach dem Lauf verwirft, ist deutlich näher am anonymen Fall.
Der zweite Punkt betrifft die Kombination. Ein einzelnes Feld sagt oft wenig, mehrere zusammen sehr viel: Geburtsdatum, Postleitzahl und Geschlecht grenzen eine Person weit stärker ein, als die drei Felder einzeln vermuten lassen. Deshalb reicht es nicht, Namen und Anschrift zu ersetzen und den Rest stehen zu lassen. Eine rechtliche Bewertung des Einzelfalls gehört zum Datenschutz im Haus, die technische Konsequenz ist aber unabhängig davon dieselbe.
Die Verfahren, und wann welches passt
Löschen oder auf NULL setzen ist das einfachste Verfahren und taugt für Felder, die im Test niemand braucht, etwa hinterlegte Bankverbindungen. Es hat einen Preis: Jede Auswertung, jede Pflichtfeldprüfung und jeder Bericht, der auf dem Feld aufsetzt, verhält sich im Test anders als in der Produktion. Maskieren ist die nächste Stufe und behält den sichtbaren Aufbau, indem es nur einen Teil ersetzt, etwa die ersten Stellen einer Kundennummer. Das ist schnell, reicht aber selten aus, weil sich aus dem verbleibenden Rest zusammen mit anderen Feldern oft wieder eine Person ergibt.
Deterministisch ersetzen ist das Verfahren, das die meisten Fälle löst. Aus einem Ausgangswert entsteht über eine Berechnung mit einem geheimen Schlüsselwert immer derselbe Ersatzwert. Damit bleiben Verknüpfungen über Tabellen hinweg erhalten, dieselbe Kundennummer in Auftrag, Rechnung und Protokoll wird überall gleich ersetzt, und ohne den Schlüsselwert lässt sich nichts zurückrechnen. Ein reiner Hash ohne Schlüssel genügt dafür nicht, weil sich bei kleinen Wertebereichen wie Geburtsdaten alle möglichen Werte einfach durchprobieren lassen.
Erzeugen liefert neue, aber realistische Werte: Namen aus einer Liste, Anschriften mit gültigem Aufbau, Kontonummern mit richtiger Prüfziffer. Verschieben ist der Sonderfall für Zeitangaben: Alle Datumswerte eines Vorgangs werden um denselben Betrag versetzt, wodurch Abstände, Reihenfolgen und Fristen erhalten bleiben. Verkleinern schließlich reduziert die Menge, und zwar entlang der Beziehungen: Man wählt einen Ausschnitt der Bewegungsdaten und nimmt alles mit, was daran hängt, während Stamm- und Schlüsseltabellen vollständig bleiben.
Was stimmig bleiben muss, damit die Kopie noch etwas taugt
Fremdschlüssel sind die erste Hürde. Wird die Kundennummer in der Kundentabelle anders ersetzt als in der Auftragstabelle, laufen sämtliche Verknüpfungen ins Leere, und die Anwendung zeigt Aufträge ohne Kunden. Deshalb muss die Ersetzung deterministisch sein, und zwar über alle Tabellen hinweg. Ob sie das auch über mehrere Läufe hinweg sein soll, ist eine bewusste Abwägung: Bleibt der Schlüsselwert erhalten, passen aufeinanderfolgende Abzüge zusammen und gespeicherte Testfälle funktionieren weiter, die Kopie bleibt dafür dauerhaft pseudonymisiert und braucht dasselbe Schutzniveau wie die Produktion. Wird er nach jedem Lauf verworfen, ist die Kopie näher am anonymen Fall, dafür müssen die Testfälle nach jedem Abzug neu aufgebaut werden. Die zweite Hürde sind Eindeutigkeiten: Wenn zweitausend E-Mail-Adressen auf denselben Ersatzwert abgebildet werden, bricht der eindeutige Index, weshalb bei kurzen Feldern eine laufende Nummer in den erzeugten Wert gehört. Ebenso müssen Prüfregeln weiter greifen, also Prüfziffern bei Kontoverbindungen, Formatregeln bei Kennzeichen und Wertebereiche bei Statusfeldern.
Die dritte Hürde wird am häufigsten unterschätzt: die Verteilung. Wenn alle Kunden nach der Ersetzung in derselben Stadt wohnen oder alle Namen dieselbe Länge haben, ändert sich das Verhalten der Datenbank. Die Statistiken sehen anders aus, der Optimizer wählt andere Pläne, und ein Test, der die Geschwindigkeit prüfen soll, misst etwas anderes als das Produktivsystem. Für Lasttests gehören deshalb Häufigkeitsverteilungen erhalten, auch wenn die einzelnen Werte ausgetauscht sind.
Zuletzt die Stellen, an denen die Daten das Schema verlassen: Freitextfelder, Anhänge in Dokumententabellen, Protokoll- und Historientabellen, die alte Werte mitschreiben, sowie Spalten, in die eine Anwendung strukturierte Daten als JSON oder XML ablegt. Alle vier enthalten regelmäßig genau die Angaben, die man an anderer Stelle sorgfältig ersetzt hat.
Werkzeuge, und ein verbreiteter Irrtum
Der Irrtum betrifft die Maskierungsfunktionen, die die Hersteller mitliefern. Dynamische Datenmaskierung im SQL Server und Data Redaction in Oracle verändern die gespeicherten Daten nicht, sie verändern nur die Anzeige für bestimmte Konten. Microsoft weist ausdrücklich darauf hin, dass die dynamische Maskierung den unmittelbaren Zugriff auf die Datenbank nicht verhindert und kein Ersatz für den Schutz der Daten selbst ist. Für eine Kopie, die als Datei weitergegeben wird oder auf der jemand mit ausreichenden Rechten arbeitet, taugt beides nicht.
Was dauerhaft verändert, ist etwas anderes. Oracle bietet dafür Data Masking and Subsetting als Zusatzpaket zum Enterprise Manager an, mit Regeln je Spalte und einer Auswahlfunktion für Teilbestände; ob es in eurem Vertrag enthalten ist, steht in der Lizenzdokumentation und gehört vor dem ersten Einsatz geklärt. Für PostgreSQL gibt es die Erweiterung PostgreSQL Anonymizer, die Maskierungsregeln über SECURITY LABEL FOR anon an Spalten hängt und daraus entweder eine dauerhaft geänderte Kopie oder einen maskierten Auszug erzeugt. MySQL liefert Maskierungsfunktionen in der Enterprise-Ausgabe mit, in der Community-Ausgabe schreibt man die Ersetzung als Skript.
Für die meisten Häuser ist das eigene Skript der realistische Weg, und es ist weniger Arbeit, als es klingt. Der Kern besteht aus einer Tabelle mit Regeln je Spalte, einem Satz Funktionen für die gängigen Feldarten und einem Ablauf, der beides zusammenführt. Der Aufwand steckt nicht in der Technik, sondern in der Entscheidung, welche Spalte welche Regel bekommt, und diese Entscheidung nimmt einem kein Werkzeug ab.
Den Vorgang so bauen, dass ihn niemand vergisst
Der Ablauf hat vier Stufen, und die Reihenfolge ist entscheidend. Zuerst wird der Abzug in eine abgeschottete Zwischeninstanz zurückgespielt, auf die nur der Betrieb Zugriff hat. Dort läuft die Anonymisierung. Danach folgt die Prüfung. Und erst danach wird die Kopie in Richtung Test und Entwicklung freigegeben. Wer diese Reihenfolge umdreht und auf dem Testsystem anonymisiert, hat den ungeschützten Bestand bereits dort liegen, und sei es nur für zwanzig Minuten.
Die wirksamste Einzelmaßnahme ist ein Abgleich gegen den Systemkatalog. Das Skript liest alle Spalten der Datenbank und vergleicht sie mit der Regelliste. Findet es eine Spalte, für die keine Regel hinterlegt ist, bricht der Lauf ab. Damit ist die häufigste Fehlerquelle geschlossen, nämlich die neue Spalte aus dem letzten Auslieferungspaket, an die beim Anonymisieren niemand gedacht hat. Regeln und Schema wandern so gemeinsam durch die Versionsverwaltung.
Dazu kommt die Gegenprobe am fertigen Ergebnis. Eine Handvoll bekannter Werte aus der Produktion, etwa der Name einer Person aus dem eigenen Haus und eine bekannte Kundennummer, wird in der fertigen Kopie gesucht, einschließlich der Freitextfelder. Findet die Suche etwas, geht die Kopie nicht heraus. Das kostet im Ablauf wenige Minuten und ist der einzige Nachweis, der im Zweifel zählt.
Dazu passende Kurse
Weil die Entscheidung je Spalte fällt und nicht je Werkzeug, lohnt sich der geführte Durchgang, und dafür gibt es bei cmt Schulungen zum Umgang mit sensiblen Datenbeständen .
Wer den Abzug samt Ersetzungen als Ablaufpaket bauen will, findet den passenden Einstieg in die Kurse rund um Datenintegration im SQL Server .
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Super Schulung, in der der Trainer auch auf eigene Fragestellungen eingegangen ist.
Super Grundlagenschulung mit allen wichtigen Punkten und hilfreichen Tipps!
Schön, sich 5 Tage ungestört mit Postgres beschäftigen zu können.
Häufige Fragen
Reicht es, Namen und E-Mail-Adressen zu ersetzen?
Können wir nicht gleich synthetische Daten erzeugen?
Muss die anonymisierte Kopie trotzdem geschützt werden?
Wie halten wir die Testkopie aktuell, ohne jedes Mal von vorn zu beginnen?
Passt thematisch dazu
Warum eine Kopie mit aufbewahrtem Schlüsselwert weiterhin dasselbe Schutzniveau braucht wie das Produktivsystem, begründet die Abgrenzung von Pseudonymisierung und Anonymisierung nach Artikel 32 .
Der Abzug, mit dem dieser Ablauf beginnt, taugt nur etwas, wenn er anwendungskonsistent entstanden ist, und wie du Sicherungen für PostgreSQL und MySQL entsprechend aufsetzt, beschreibt ein Sicherungskonzept mit anwendungskonsistenten Datenbankdumps .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Datenbanken-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Eine Kopie, mit der sich arbeiten lässt, ohne sie zu bewachen
Wie du Regeln je Spalte aufbaust, Beziehungen erhältst und den Ablauf automatisierst, lässt sich bei cmt an einem echten Schema durchspielen.