SAP-Testdaten anonymisieren: Methoden im Überblick

Anonymisierung, Pseudonymisierung, Maskierung, Scrambling

Keine Rechtsberatung. Dieser Artikel beschreibt technische Verfahren. Ob eine Maßnahme in Ihrem Fall ausreicht und ob das Ergebnis anonym oder pseudonym ist, bewerten Ihr Datenschutzbeauftragter und Ihre Rechtsberatung.

Warum Produktivdaten im Testsystem ein Datenschutzthema sind, beschreibt der Artikel Personenbezogene Daten in SAP-Testsystemen. Hier geht es um die Umsetzung. Vorab die Begriffe, denn sie werden oft vermischt:

Anonymisierung: Anonyme Informationen beziehen sich nach Erwägungsgrund 26 DSGVO nicht oder nicht mehr auf eine identifizierbare Person. Maßstab sind die Mittel, die nach allgemeinem Ermessen wahrscheinlich genutzt werden, bemessen etwa an Kosten, Zeitaufwand und Stand der Technik. Für anonyme Informationen gelten die Grundsätze des Datenschutzes nicht.
Pseudonymisierung: Nach Art. 4 Nr. 5 DSGVO lassen sich die Daten ohne zusätzliche Informationen, etwa eine Zuordnungstabelle, keiner bestimmten Person mehr zuordnen. Diese Informationen werden gesondert aufbewahrt und geschützt. Pseudonymisierte Daten bleiben personenbezogene Daten.
Maskierung: Kein Rechtsbegriff, sondern ein Sammelbegriff für Verfahren, die Werte verändern oder verbergen. Ob das Ergebnis anonym oder pseudonym ist, hängt vom Verfahren und vom Gesamtbild der Daten ab.
Scrambling (Datenverfremdung): Der im SAP-Umfeld gängige Begriff, etwa in SAP TDMS. Daten werden verfremdet, bevor Tester und Entwickler sie im Nicht-Produktivsystem zu sehen bekommen. Gemeint ist dasselbe wie mit Maskierung.

Ein brauchbares Prüfraster stammt von der Artikel-29-Datenschutzgruppe, einem früheren Beratungsgremium der EU. Sie misst Anonymisierungstechniken an drei Fragen: Lässt sich eine Person weiterhin herausgreifen? Lassen sich Datensätze zu ihr verknüpfen? Lassen sich Informationen über sie ableiten? Pseudonymisierung ist danach keine Anonymisierungstechnik, sie verringert nur die Verknüpfbarkeit mit der wahren Identität.

SAP-Daten maskieren: sechs Methoden im Vergleich

Werkzeuge für die Datenverfremdung kombinieren wenige Grundtechniken. SAP TDMS etwa kennt Scrambling-Typen wie Wert löschen, Festwert, manuelle 1:1-Zuordnung, Nummernumsetzung und Zufallswerte aus Listen oder Zeiträumen. Sechs Methoden lassen sich unterscheiden:

Methode	So funktioniert es	Stärke	Schwäche
Ersetzen (Substitution)	Der echte Wert wird durch einen erfundenen ersetzt, aus einer Werteliste oder nach einer Regel.	Realistische Daten, Formate und Längen bleiben erhalten.	Wertelisten müssen gepflegt werden. Eine aufbewahrte Zuordnung von alt zu neu ist umkehrbar.
Vertauschen (Shuffling)	Werte werden innerhalb einer Spalte zwischen Datensätzen getauscht.	Verteilung und Wertebereich bleiben exakt erhalten.	Jeder Wert bleibt echt. Einzeln getauschte Felder passen nicht mehr zu zusammenhängenden Feldern.
Zeichenmaskierung	Teile eines Werts werden durch Platzhalter ersetzt, etwa alle Stellen bis auf die letzten vier.	Einfach umzusetzen, Werte bleiben unterscheidbar.	Restzeichen können identifizieren. Prüfziffern und Formatprüfungen schlagen fehl.
Datumsverschiebung	Datumswerte werden um einen festen oder zufälligen Zeitraum verschoben.	Bei gleichem Versatz je Person oder Vorgang bleiben Abstände und Reihenfolgen erhalten.	Ein fester Versatz ist rückrechenbar, sobald ein echtes Datum bekannt ist. Zufällige Einzelwerte zerstören Abläufe.
Generierung	Werte werden künstlich erzeugt, etwa Namen, Adressen oder IBANs mit gültiger Prüfziffer.	Kein Bezug zum Originalwert.	Aufwendig: Formate, Länderregeln und Abhängigkeiten müssen stimmen.
Löschen oder Leeren	Der Feldinhalt wird geleert oder auf einen festen Wert gesetzt.	Einfach und gründlich für Felder, die kein Test braucht.	Ungeeignet für Schlüssel- und Pflichtfelder.

Vereinfachte Einordnung. Welche Methode passt, hängt vom Feld, vom Testzweck und von den Vorgaben Ihres Datenschutzes ab.

Zwei Punkte entscheiden über die Qualität. Erstens: zufällig oder deterministisch. Deterministisch heißt, derselbe Ursprungswert ergibt immer denselben Ersatz, auch im nächsten Refresh und in anderen Systemen. Für Schnittstellentests ist das oft nötig. Bleibt dafür eine Zuordnungstabelle erhalten, entspricht das dem Bild der Pseudonymisierung. SAP ordnet in seinen Datenschutzhinweisen zu TDMS die manuelle 1:1-Zuordnung ausdrücklich der Pseudonymisierung zu.

Zweitens: Keine Methode genügt allein. Vertauschen etwa gewährleistet laut Artikel-29-Datenschutzgruppe für sich keine Anonymisierung und sollte mit dem Entfernen offensichtlicher Merkmale kombiniert werden. Zusammenhängende Merkmale gehören gemeinsam vertauscht, sonst lässt sich die Vertauschung unter Umständen rückgängig machen.

Was das Anonymisieren in SAP schwierig macht

Die Methoden sind schnell erklärt. In SAP liegt die Arbeit in den Details:

Konsistenz: Ein Geschäftspartner steht in Stammdaten, Adressen, Belegen und Zahlungsdaten. Alle Stellen brauchen denselben Ersatzwert. SAP zeigt das in der TDMS-Anleitung an der Adresstabelle ADRC: Name, Straße und Ort werden über die Adressnummer als Schlüssel einheitlich ersetzt, mit einer globalen Zuordnung auch über mehrere Regeln hinweg. Dasselbe gilt über Systeme hinweg: Wird ein Kunde in S/4HANA anders ersetzt als im angebundenen CRM- oder BW-System, passen Schnittstellentests nicht mehr.
Stimmige Ersatzwerte: Eine Ersatzadresse muss zu Land, Region und Postleitzahl passen. Der TDMS-Leitfaden zeigt das an Land und Region: Wechselt das Land, muss die Region mitwechseln.
Suchhilfen und Matchcodes: SAP speichert manche Werte doppelt, damit die Suche funktioniert. Im Debitorenstamm etwa setzt das System Name und Ort in Stellvertreterfelder in Großbuchstaben um, MCOD1 für NAME1 und MCOD3 für ORT01. Wer nur das Namensfeld ersetzt, lässt den echten Namen im Suchfeld stehen. Frei gepflegte Suchbegriffe enthalten oft ebenfalls Namen oder Kürzel.
Freitexte und Anhänge: Feldregeln erfassen keine Langtexte, Notizen oder angehängten PDFs. Meist bleibt nur, sie zu leeren oder gar nicht erst zu kopieren. Mehr dazu unter Grenzen der Maskierung.
Prüfziffern: Die IBAN enthält zwei Prüfziffern. Ein zufällig veränderter Wert ist in aller Regel ungültig, und Prüfungen in Stammdatenpflege, Zahlungsverkehr oder Schnittstellen können daran scheitern. Ersatz-IBANs brauchen deshalb eine neu berechnete Prüfziffer.
Testbarkeit: SAP beschreibt den Zielkonflikt in seinen TDMS-Datenschutzhinweisen selbst: Je nach Art der Anonymisierung, etwa einer Adresse, laufen Folgeprozesse nicht mehr, weil logische Zusammenhänge verloren gehen. Umgekehrt scheitert die Anonymisierung, wenn der Bezug zur Person erkennbar bleibt.

Daraus folgt eine Faustregel: Formate, Schlüssel und Beziehungen erhalten, die Inhalte verändern, die eine Person erkennbar machen. Bei Personaldaten aus SAP HCM lohnt vorher die Frage, ob sie überhaupt ins Testsystem gehören.

Wann maskieren: während der Kopie oder danach?

Neben dem Wie zählt der Zeitpunkt. Grundsätzlich gibt es zwei Wege:

Nach der Kopie im Zielsystem: Die System- oder Mandantenkopie läuft wie gewohnt, danach verändert ein Programm die Daten. Das passt in bestehende Abläufe. Bis der Lauf fertig ist, liegen die Daten aber im Klartext im Testsystem, unter Umständen auch in Protokollen und Sicherungen. Bei großen Tabellen kostet der Lauf zudem Zeit im Downtime-Fenster.
Während der Kopie: Die Daten werden beim Export in der Quelle oder beim Import verändert, bevor sie in die Zieldatenbank geschrieben werden. Der Klartext erreicht das Testsystem dann nicht. SAP empfiehlt in seinen Datenschutzhinweisen zu TDMS, die Daten schon vor der Übertragung ins Nicht-Produktivsystem zu verfremden. System- und Standard-Mandantenkopie bieten dafür keine Funktion.

Wer nach der Kopie maskiert, sollte das Zielsystem bis zum Abschluss geschlossen halten: Benutzer gesperrt, Schnittstellen und Jobs angehalten. Die Maskierung gehört dann als eigener Punkt auf die Checkliste für die Nacharbeiten nach einer Mandantenkopie, vor der Freigabe an die Tester.

Nach der Kopie maskieren

ProduktionPersonenbezogene Daten im Klartext
System- oder MandantenkopieLäuft wie gewohnt.
Testsystem im KlartextBis der Maskierungslauf fertig ist, unter Umständen auch in Protokollen und Sicherungen.Klartext im Testsystem
MaskierungslaufKostet bei großen Tabellen Zeit im Downtime-Fenster.
Testsystem maskiert

Beim Kopieren maskieren

ProduktionPersonenbezogene Daten im Klartext
Maskierung beim Export oder ImportBevor die Daten in die Zieldatenbank geschrieben werden.
Testsystem maskiertkein Klartext im Testsystem

Wer nach der Kopie maskiert, hat bis zum Abschluss Klartext im Testsystem. Beim Kopieren maskiert, erreicht er das Testsystem nicht. System- und Standard-Mandantenkopie bieten für die Maskierung während der Kopie keine Funktion.

Abgrenzung: Maskierung in der Oberfläche

Nicht jede Maskierung verändert Daten. UI Data Protection Masking for SAP S/4HANA schützt sensible Feldwerte in der Oberfläche: Benutzer ohne Berechtigung sehen den Wert maskiert, leer oder gar nicht, berechtigte Benutzer sehen den Originalwert. Laut SAP-Dokumentation lässt sich das unter anderem für SAP GUI, Web Dynpro ABAP und SAP Fiori einrichten, gesteuert über Rollen oder Attribute.

Die Oberflächenmaskierung regelt also, wer einen Wert sieht. Gespeichert bleibt der Originalwert, in der Datenbank und damit auch in Sicherungen und Kopien. Scrambling verändert dagegen, was gespeichert ist. Für ein Testsystem, das aus der Produktion befüllt wird, ersetzt das eine das andere nicht.

SAP-Testdaten anonymisieren in fünf Schritten

Daten finden. Erfassen Sie, welche Tabellen und Felder personenbezogene Daten enthalten, einschließlich Erweiterungen, kundeneigener Tabellen, Suchfelder, Langtexte und Anhänge. Die Fachbereiche kennen die Sonderfälle. Ergebnis ist ein Feldkatalog.
Regeln festlegen. Wählen Sie je Feld eine Methode: löschen, was kein Test braucht, ersetzen, was eine Person erkennbar macht, Formate, Prüfziffern und Schlüssel erhalten. Legen Sie fest, welche Werte über Tabellen und Systeme hinweg gleich ersetzt werden, und stimmen Sie das Ergebnis mit dem Datenschutz ab.
Testen. Erproben Sie die Regeln zuerst an einem kleinen Bestand, etwa in einem eigenen Testmandanten. Laufen die wichtigen Prozesse samt Schnittstellen und Formularen noch? Taucht der Klartext noch irgendwo auf, etwa in Suchfeldern, Änderungsbelegen oder IDocs?
Wiederholbar machen. Die Maskierung gehört in jeden Refresh. Automatisieren Sie den Lauf, versionieren Sie die Regeln und ziehen Sie neue Felder aus Erweiterungen und Releasewechseln nach. Auch die Artikel-29-Datenschutzgruppe betont, dass Anonymisierung keine einmalige Aufgabe ist und die Risiken regelmäßig neu bewertet werden sollten.
Dokumentieren. Halten Sie Feldkatalog, Regeln, Freigaben und jeden Lauf fest. Wer die Regeln kennt, weiß auch, wie die Daten verändert wurden. SAP nennt in seinen Datenschutzhinweisen zu TDMS deshalb ein Berechtigungskonzept und Verschwiegenheitsvereinbarungen für alle Beteiligten.

Oft ist die wirksamste Maskierung, Daten gar nicht erst zu kopieren. Welche Alternativen es gibt, von der Teilkopie per Zeitscheibe bis zu synthetischen Daten, zeigt der Artikel Testdaten für S/4HANA.

Maskierung im Refresh mit Data Protect

Der Data Refresh Operator (DRO) setzt beim Zeitpunkt an. Er kopiert eine Zeitscheibe statt der kompletten Historie, zum Beispiel die letzten 90 Tage plus alle abhängigen Objekte, und bindet die Maskierung mit Data Protect in den Lauf ein:

Data Protect hilft, maskierungswürdige Daten zu finden.
Die Regeln pflegen Sie an einer Stelle, im zentralen Control-System.
Angewendet werden sie beim Export oder beim Import. Beim Export verlassen die Daten die Produktion bereits maskiert.
Die Maskierung ist ein Schritt im Lauf und lässt sich in Playbooks einplanen. Simulation vorab und Audit-Trail machen nachvollziehbar, was kopiert wurde.

Welche Felder wie maskiert werden und ob das Ergebnis für Ihren Zweck ausreicht, legen Sie mit Ihrem Datenschutz fest. DRO liefert das Werkzeug, die Bewertung bleibt bei Ihnen. DRO läuft ab SAP S/4HANA 2023 und ersetzt die Mandantenkopie, nicht die Systemkopie. Mehr zur Funktion auf der Seite SAP-Testdaten anonymisieren mit Data Protect. Im Vorstellungstermin zeigen wir Data Protect live und besprechen Ihre Anforderungen an Testdaten.

SAP-Testdaten anonymisieren: Maskierung und Scrambling