Produktionsdaten anonymisieren fürs Staging (ohne DSGVO-Risiko)

Der Drang, Produktion ins Staging zu klonen, ist nachvollziehbar. Echte Volumen, echte Sonderfälle, echte Verteilungen, alles geschenkt. Das Problem ist, was mitkommt: echte Namen, echte E-Mails, echte Adressen, jetzt in einer Umgebung, die niemand so absichert wie die Produktion.

Warum „einfach Prod kopieren" ein Risiko ist

• Jeder mit Staging-Zugriff hat jetzt die PII deiner Kunden. Entwickler, externe Dienstleister, das Analytics-Tool, das du „nur zum Testen" ans Staging gehängt hast. Das ist Verarbeitung personenbezogener Daten zu einem Zweck, dem der Kunde nie zugestimmt hat.
• Staging ist das weichere Ziel. Schwächere Auth, Debug-Endpunkte, gesprächige Logs, Backups in irgendeinem S3-Bucket. Ein Leck im Staging ist trotzdem ein Leck produktionswertiger personenbezogener Daten.
• Es besteht kein Audit. Nach DSGVO brauchen personenbezogene Daten auch außerhalb der Produktion eine Rechtsgrundlage und dieselben Schutzmaßnahmen nach Artikel 32. „Ist doch nur Staging" ist keine Kategorie, die die Verordnung kennt.

Die Lösung ist, dafür zu sorgen, dass die Daten im Staging gar nicht erst personenbezogen sind. Drei Wege dorthin, von „Prod sicher wiederverwenden" bis „Prod nie anfassen".

Variante A: die PII direkt in der DB ersetzen

Du hast eine Kopie der Datenbank und willst dieselben Zeilen, abzüglich der personenbezogenen Teile. Zeig SeedBase die Verbindung und ersetze die sensiblen Spalten durch realistische, erfundene Werte:

# erst Vorschau, nichts schreiben
seedbase mask <connection> --table customers --columns email,name,phone --dry-run

# anwenden
seedbase mask <connection> --table customers --columns email,name,phone

Die Werte ändern sich, die Schlüssel nicht. customers.email wird zu einer glaubhaften Fälschung, aber die orders, die auf diesen Kunden verweisen, lösen weiter auf dieselbe Zeile auf. Die DB bleibt joinbar und ladbar. Weg ist nur die Verbindung zu einer echten Person.

Variante B: erst einen sicheren Subset ziehen

Produktion ist 400 GB und Staging braucht nicht alles. Nimm eine fremdschlüssel-konsistente Scheibe, bei der zu jeder referenzierten Zeile ihre Eltern und Kinder mitkommen, und anonymisiere die:

seedbase pull subset --from-database <connection> --rows 5000 --out staging.sql

Du bekommst einen kleinen Datensatz, der sich weiter wie der echte verhält, keine baumelnden Referenzen, keine verwaisten Zeilen, in einer Größe, die ein Laptop in Sekunden lädt.

Variante C: die Produktion nie verlassen lassen

Die stärkste Haltung ist die, bei der keine echte Zeile überhaupt kopiert wird. Erzeuge einen synthetischen Datensatz direkt aus deinem Schema, mit realistischen Verteilungen und jedem aufgelösten Fremdschlüssel, und lade den ins Staging. Nichts zu anonymisieren, weil nichts Echtes da war. Das ist der Weg, zu dem wir standardmäßig greifen, und Anonymisieren ist der Rückfall, wenn du wirklich die exakte Form und das Volumen der Produktion brauchst.

Anonym, nicht nur pseudonym

Dieser Unterschied ist unter der DSGVO das ganze Spiel. Erwägungsgrund 26 sagt, dass die Verordnung für wirklich anonyme Daten nicht gilt, also Informationen, die sich keiner Person mehr zuordnen lassen. Pseudonymisierung, bei der sich das Original mit einem Schlüssel wiederherstellen lässt, bleibt voll im Anwendungsbereich.

Eine E-Mail zu hashen ist Pseudonymisierung: gleiche Eingabe, gleicher Hash, sie identifiziert und verknüpft also weiter. Sie durch eine erfundene Adresse zu ersetzen und keine Zuordnung zu behalten, ist Anonymisierung. SeedBase macht das Zweite, und genau das nimmt die Daten aus dem Anwendungsbereich. Die synthetischen Werte behalten dabei das richtige Format, deine Validierung und Tests laufen also weiter durch.

FAQ