Datenmaskierung: Testdaten nutzen, ohne Personen preiszugeben

© KI-generiert (TenMedia)

Datenmaskierung: Echtdaten außerhalb der Produktion schützen

Bei der Berliner Datenschutzbeauftragten gingen 2025 1.462 Meldungen über unbefugte Offenlegungen oder Zugriffe ein, im Schnitt vier am Tag. Maskieren heißt, echte Angaben so zu verfremden, dass sie weiter echt aussehen, aber keine Person mehr verraten.

Datenmaskierung ersetzt personenbezogene oder vertrauliche Werte in einem Datenbestand durch fiktive, realistisch wirkende Werte. So lassen sich Tests, Entwicklung, Fehleranalyse und Schulung durchführen, ohne echte Daten offenzulegen. Format, Struktur und die Verknüpfungen zwischen den Tabellen bleiben erhalten. Je nach Verfahren ist das Ergebnis pseudonymisiert und damit weiter personenbezogen, oder anonymisiert und damit außerhalb der DSGVO.

Jede Kopie echter Daten außerhalb des Produktivsystems ist eine Stelle mehr, an der ein solcher Vorfall entstehen kann.

Wann Testdaten mit Personenbezug zulässig sind

Ein generelles Verbot von Echtdaten im Softwaretest gibt es nicht. Der BSI-Baustein OPS.1.1.6 zu Software-Tests und Freigaben verlangt aber als Basisanforderung, dass Testdaten mit Personenbezug mindestens pseudonymisiert und wo möglich anonymisiert werden. Lässt sich aus ihnen ein Personenbezug ableiten, ist die oder der Datenschutzbeauftragte hinzuzuziehen. Art. 32 DSGVO nennt die Pseudonymisierung ausdrücklich als technische Schutzmaßnahme. Maskierte Testdaten setzen zugleich den Grundsatz der Datenminimierung aus Art. 5 DSGVO um. Verantwortlich für die Kopie bleibt die Behörde, die sie herausgibt. Seit 2022 verlangt zusätzlich ISO 27001 Anhang A 8.11 die Maskierung ausdrücklich, und daraus ergeben sich die Unterlagen für eine Prüfung.

Testdatenmanagement beginnt vor der ersten Kopie

Daten maskieren heißt nicht, einmal eine Kopie zu verfremden, sondern bei jeder neuen Bereitstellung. Testdatenmanagement bezeichnet den geregelten Weg, auf dem diese Daten entstehen, aktualisiert und wieder gelöscht werden. Im IT-Sicherheitsmanagement einer Behörde braucht dieser Weg einen eigenen Prozess, weil Echtdaten an mehreren Stellen die Produktion verlassen:

• Testumgebungen für Updates und neue Funktionen
• Entwicklungsumgebungen beim externen Dienstleister
• Kopien zur Analyse eines gemeldeten Fehlers
• Schulungssysteme für neue Beschäftigte
• Auswertungen außerhalb des Fachverfahrens
• Datenübergaben bei der Ablösung eines Altsystems

Für jede dieser Stellen fällt eine eigene Entscheidung, ob pseudonymisierte Daten genügen. Sie hängt an Zweck und Dauer der Nutzung. Diese Entscheidung festzuhalten ist eine Nachweispflicht der IT-Compliance und keine Frage der Technik allein.

Anonymisierung und Pseudonymisierung beim Maskieren

Maskierte Daten sind nicht automatisch anonym. Ob eine Kopie weiter unter die DSGVO fällt, hängt daran, ob sich die Personen dahinter mit vertretbarem Aufwand wieder bestimmen lassen. Anonymisierung und Pseudonymisierung beschreiben die beiden möglichen Ergebnisse einer Datenmaskierung. Nur die Anonymisierung personenbezogener Daten nimmt die Kopie aus dem Gesetz heraus. Für eine Testumgebung entscheidet dieser Unterschied über Auftragsverarbeitung, Zugriffsregeln und Löschpflichten.

Sind maskierte Daten noch personenbezogen?

In den meisten Fällen ja. Nach Art. 4 Nr. 5 DSGVO sind Daten pseudonymisiert, wenn sie ohne zusätzliche Informationen keiner Person mehr zugeordnet werden können und diese Informationen getrennt und geschützt aufbewahrt werden. Die Leitlinien 01/2025 des Europäischen Datenschutzausschusses halten fest, dass pseudonymisierte Daten personenbezogen bleiben. Solange ein Rückweg zur Person existiert, gilt die DSGVO weiter. Verboten sind pseudonymisierte Testdaten deshalb nicht. Die Pseudonymisierung nach DSGVO verlangt nur dieselben Voraussetzungen wie im Produktivsystem, also Rechtsgrundlage, Schutzmaßnahmen und bei einem externen Dienstleister einen Auftragsverarbeitungsvertrag.

Pseudonymisierte Daten und die Zuordnungstabelle

Beim Pseudonymisieren entsteht meist eine Zuordnungstabelle, die jedes Pseudonym mit dem echten Datensatz verknüpft. Sie ist die zusätzliche Information im Sinne der DSGVO und braucht mehr Schutz als die Testdaten selbst. Die Tabelle gehört deshalb zur Behörde und nicht in die Testumgebung.

Ab wann Daten wirklich anonym sind

Eine Anonymisierung im Sinne der DSGVO liegt erst vor, wenn sich niemand mehr mit vertretbarem Aufwand identifizieren lässt, auch nicht über eine Kombination mehrerer Merkmale. Postleitzahl, Geburtsjahr und ein seltenes Aktenzeichen können in einem kleinen Bestand genügen, um eine Person wiederzufinden, obwohl kein Name mehr dasteht. Das Maß k-Anonymität beschreibt, mit wie vielen anderen Datensätzen jeder Eintrag in solchen Merkmalen übereinstimmt. Bevor ein Bestand als anonym gilt, helfen vier Prüffragen:

❓ Existiert noch eine Zuordnungstabelle oder ein Schlüssel?
❓ Lassen sich Personen über seltene Merkmale erkennen?
❓ Stehen in Freitexten oder Anhängen noch Namen?
❓ Liegt in derselben Umgebung eine unmaskierte Kopie?

Lautet eine Antwort ja, sind die Daten pseudonymisiert und nicht anonymisiert.

Statische und dynamische Datenmaskierung im Vergleich

Datenmaskierung gibt es in zwei Grundformen, die sich im Zeitpunkt unterscheiden. Die statische Form verändert eine Kopie dauerhaft, bevor sie die Produktion verlässt. Die dynamische Form lässt die gespeicherten Daten unverändert und blendet Werte erst bei der Anzeige aus, abhängig von den Rechten der angemeldeten Person. Beide lösen verschiedene Probleme.

Statische Datenmaskierung für Test und Entwicklung

Bei der statischen Datenmaskierung entsteht eine eigene, dauerhaft veränderte Kopie des Datenbestands. Echte Werte verlassen das Produktivsystem nicht, weil die Maskierung vor der Übergabe läuft. Diese Form passt überall dort, wo Dritte oder Testsysteme arbeiten, also bei Entwicklung, Abnahme und Schulung. Ein einfaches Beispiel für Datenmaskierung ist die Meldeadresse, die in der Testkopie durch eine erfundene Adresse im selben Postleitzahlgebiet ersetzt wird. Nur in dieser Form finden Anonymisierung und Pseudonymisierung überhaupt statt, denn die dynamische Variante verändert keine gespeicherten Daten.

Warum dynamische Maskierung keine Grenze zieht

Dynamische Datenmaskierung ändert nichts am gespeicherten Bestand. Die Datenbank zeigt einer Sachbearbeitung, der im Berechtigungsmanagement das passende Recht fehlt, etwa nur die ersten Zeichen einer E-Mail-Adresse. Microsoft stellt in der Dokumentation zu SQL Server selbst klar, dass die Funktion vor versehentlicher Offenlegung schützt, aber nicht vor gezielten Abfragen, mit denen sich maskierte Werte erschließen lassen. Für Kopien außerhalb der Produktion ist die dynamische Variante deshalb keine Lösung. Sinnvoll ist sie als zusätzliche Schicht in der Absicherung von Anwendungen, etwa für Rollen ohne Bedarf an Bankdaten.

Techniken, mit denen Werte ersetzt werden

Die Norm ISO/IEC 27002 nennt in der Maßnahme 8.11 zur Datenmaskierung neben Anonymisierung und Pseudonymisierung mehrere Einzeltechniken. Welche davon greift, entscheidet das einzelne Feld. Gebräuchlich sind vor allem diese:

• Ersetzen durch plausible Werte im gleichen Format
• Vertauschen von Werten innerhalb einer Spalte
• Schwärzen einzelner Zeichen, etwa bei Kontonummern
• Leeren von Feldern ohne Testbedarf
• Verschieben von Datumsangaben um einen Zufallswert
• Tokenisierung mit getrennt verwahrtem Originalwert
• Verschlüsselung mit getrennt verwahrtem Schlüssel

Tokenisierung und Verschlüsselung lassen sich umkehren und ergeben deshalb immer pseudonymisierte Daten. Welche Technik ein Feld verträgt, hängt außerdem an seinen fachlichen Regeln. Eine IBAN mit zufällig ersetzten Ziffern fällt durch jede Prüfziffernkontrolle, und der Test der Zahlungsfunktion scheitert dann aus dem falschen Grund.

Synthetische Daten als dritter Weg

Synthetische Daten werden künstlich erzeugt und gehen auf keinen echten Datensatz zurück, sie enthalten also keinen Personenbezug. Ihre Grenze liegt dort, wo ein Fehler nur mit gewachsenen Beständen auftritt. Doppelte Einträge aus einer früheren Migration, Sonderzeichen in Namen oder Akten mit widersprüchlichem Status kennt ein Generator nicht. Für solche Fälle bleibt die Datenmaskierung echter Bestände der verlässlichere Weg.

Nachweis und Aufwand in gewachsenen Fachanwendungen

Für Datenschutz und Informationssicherheit zählt, was sich belegen lässt. Den Nachweis bestimmen zwei Fragen, nämlich welche Norm die Maßnahme verlangt und ob die Datenmaskierung in der konkreten Anwendung vollständig greift. In älteren Fachverfahren liegt dort auch der größte Teil des Aufwands im Testdatenmanagement, weil Daten an Stellen stehen, die kein Feldschema erfasst.

Was verlangt ISO 27001 Anhang A 8.11?

Seit der Revision von 2022 führt ISO/IEC 27001 die Datenmaskierung als eigene Maßnahme im Anhang A, in der englischen Fassung unter dem Titel Data Masking. Die Maßnahme 8.11 verlangt, Daten nach der eigenen Richtlinie zur Zugangssteuerung, den fachlichen Anforderungen und den geltenden Gesetzen zu maskieren. Laut der Deutschen Akkreditierungsstelle mussten alle Zertifikate bis Ende Oktober 2025 auf diese Fassung umgestellt sein. Seitdem steht 8.11 in jeder Erklärung zur Anwendbarkeit, entweder als umgesetzt oder mit begründetem Ausschluss. Datenmaskierung nach ISO 27001 lässt sich damit prüfen wie jede andere Maßnahme. Für die Prüfung einer Testumgebung taugen vor allem diese Unterlagen aus dem Testdatenmanagement:

• Maskierungsregeln je Tabelle und Feld
• Einstufung jeder Umgebung als pseudonymisiert oder anonym
• Aufbewahrungsort der Zuordnungstabelle
• Löschfristen für Testbestände
• Protokoll jeder Bereitstellung
• Auftragsverarbeitungsvertrag mit dem Dienstleister

Testdatenmanagement in gewachsenen Fachanwendungen

Den größten Aufwand verursacht selten das Ersetzen eines Namens. Schwieriger ist die referenzielle Integrität, also dass Schlüssel über alle Tabellen hinweg zusammenpassen. In einer relationalen Datenbank verweist eine Akte auf eine Person, ein Bescheid auf die Akte und eine Zahlung auf den Bescheid. Wird eine Personennummer an einer Stelle anders ersetzt als an der anderen, zerfallen diese Verknüpfungen, und der Test findet Fehler, die es im Betrieb nicht gibt. Gutes Testdatenmanagement ersetzt jeden Wert überall auf dieselbe Weise.

Freitexte, Anhänge und Protokolle

Personenbezogene Angaben können in älteren Fachverfahren auch außerhalb der dafür vorgesehenen Felder, etwa in Bemerkungen, eingescannten Schreiben, E-Mail-Anhängen oder Protokolldateien stehen. Eine Maskierung von Daten, die nur Spalten kennt, übersieht sie, und ein übersehener Freitext macht Anonymisierung und Pseudonymisierung gleichermaßen wirkungslos. Solche Stellen bestimmen den Aufwand stärker als die Zahl der Tabellen. Besonders heikel ist das bei sensiblen Daten, wie sie eine Plattform für das Pre-Employment-Screening für Identitätsprüfungen verarbeitet. Eine Bestandsaufnahme vor dem ersten Lauf zeigt, wie viele solcher Stellen eine Anwendung enthält.