Personenbezogene Daten in SAP-Testsystemen: worauf es ankommt

Warum Produktivdaten im Testsystem ein Datenschutzthema sind

In der Produktion schützen Berechtigungskonzepte, Protokollierung und eingespielte Prozesse die personenbezogenen Daten. Eine Kopie ins Testsystem nimmt die Daten mit, diesen Schutz aber nur teilweise:

• Breitere Berechtigungen: Entwickler, Berater und Key User arbeiten im Testsystem oft mit weitreichenden Rechten, damit sie testen und Fehler analysieren können. Auch Daten, die in der Produktion wegen Ende des Zwecks gesperrt und nur mit besonderer Berechtigung sichtbar sind, werden so leichter zugänglich.
• Externe Dienstleister: Implementierungspartner und AMS-Teams haben auf Testsysteme oft leichter Zugriff als auf die Produktion. Greifen Teams aus Ländern außerhalb der EU und des EWR zu, kommen die Regeln für Übermittlungen in Drittländer hinzu (Kapitel V DSGVO).
• Mehr Kopien: QS, Test, Sandbox, Schulung, Projektsysteme, dazu Exportdateien und Sicherungen jedes Systems. Jede Kopie ist ein weiterer Ort, an dem die Daten liegen.
• Längere Aufbewahrung: Was in der Produktion gesperrt oder gelöscht wird, bleibt in einer älteren Kopie bis zum nächsten Refresh erhalten. Bei seltenen Refreshs kann das Monate dauern.

Das BSI beschreibt dieses Risiko im IT-Grundschutz ausdrücklich: Bei Tests mit Produktivdaten könnten vertrauliche Daten von Unbefugten eingesehen werden, auch von Dritten, die mit dem Test beauftragt sind.

Was die DSGVO grundsätzlich verlangt

Keine Rechtsberatung. Dieser Artikel ordnet Grundsätze und technische Ansätze ein. Ob und welche Maßnahmen in Ihrem Fall ausreichen, bewerten Ihr Datenschutzbeauftragter und Ihre Rechtsberatung.

Eine eigene Regel für Testsysteme enthält die DSGVO nicht. Es gelten die allgemeinen Grundsätze aus Art. 5 Abs. 1, darunter:

• Zweckbindung (lit. b): Daten werden für festgelegte, eindeutige und legitime Zwecke erhoben und dürfen nicht in einer damit unvereinbaren Weise weiterverarbeitet werden.
• Datenminimierung (lit. c): Daten müssen auf das für den Zweck notwendige Maß beschränkt sein. Für Testsysteme stellt sich damit die Frage, welche Daten ein Test wirklich braucht.
• Speicherbegrenzung (lit. e): Personen dürfen nur so lange identifizierbar sein, wie es für den Zweck erforderlich ist.
• Integrität und Vertraulichkeit (lit. f): Eine angemessene Sicherheit, einschließlich Schutz vor unbefugter oder unrechtmäßiger Verarbeitung.

Nach Art. 25 trifft der Verantwortliche geeignete technische und organisatorische Maßnahmen, um diese Grundsätze wirksam umzusetzen. Als Beispiel nennt der Artikel ausdrücklich die Pseudonymisierung. Art. 32 führt Pseudonymisierung und Verschlüsselung unter den Maßnahmen für ein dem Risiko angemessenes Schutzniveau auf. Und nach Art. 5 Abs. 2 muss der Verantwortliche die Einhaltung der Grundsätze nachweisen können. In der Praxis heißt das: festhalten, welche Daten in welche Systeme kopiert und wie sie dort geschützt werden.

Konkreter wird der IT-Grundschutz des BSI. Enthalten Produktivdaten für Tests personenbezogene Informationen, müssen sie nach Anforderung OPS.1.1.6.A11 mindestens pseudonymisiert werden. Wo möglich, sollen sie vollständig anonymisiert werden. Lässt sich ein Personenbezug weiterhin ableiten, ist der Datenschutzbeauftragte hinzuzuziehen, unter Umständen auch die Personalvertretung.

Anonymisieren, pseudonymisieren, maskieren: die Begriffe

Anonymisierung hebt den Personenbezug so auf, dass er nicht oder nur mit unverhältnismäßigem Aufwand an Zeit, Kosten und Arbeitskraft wiederhergestellt werden kann. So beschreibt es der Bundesdatenschutzbeauftragte (BfDI) in einem Positionspapier. Für anonyme Informationen gelten die Grundsätze des Datenschutzes nicht (Erwägungsgrund 26 DSGVO). Der BfDI weist aber auch darauf hin, dass eine absolute Anonymisierung häufig nicht möglich ist, dass nicht vorschnell von einer hinreichenden Anonymisierung ausgegangen werden darf und dass das Anonymisieren selbst eine Verarbeitung personenbezogener Daten ist, die eine Rechtsgrundlage braucht.

Pseudonymisierung (Art. 4 Nr. 5 DSGVO) verarbeitet Daten so, dass sie ohne zusätzliche Informationen keiner bestimmten Person mehr zugeordnet werden können. Diese Zusatzinformationen, etwa eine Zuordnungstabelle, werden getrennt aufbewahrt und geschützt. Pseudonymisierte Daten bleiben personenbezogene Daten.

Maskierung ist kein Rechtsbegriff, sondern ein technischer Sammelbegriff: Werte werden ersetzt, verfremdet, gekürzt oder geleert. Ein Name wird durch einen erfundenen ersetzt, eine IBAN durch eine Test-IBAN mit gültiger Prüfziffer. Ob das Ergebnis anonym oder nur pseudonym ist, entscheidet nicht das einzelne Feld, sondern das Gesamtbild der Daten. Eine umkehrbare Maskierung mit Zuordnungstabelle ist eine Pseudonymisierung.

Wo in SAP personenbezogene Daten stecken

Personenbezogene Daten finden sich in SAP nicht nur in den offensichtlichen Stammdaten. Typische Fundstellen:

Geschäftspartner, Kunden, Lieferanten

Namen, Anschriften, Telefonnummern, E-Mail-Adressen und Ansprechpartner. In S/4HANA zentral im Geschäftspartner (z. B. BUT000) und in der Adressverwaltung (ADRC, ADR2, ADR6), dazu in Kunden- und Lieferantenstämmen (KNA1, LFA1).

Bankverbindungen und Zahlungen

IBAN und Kontoinhaber im Geschäftspartner (BUT0BK) sowie in Kunden- und Lieferantenstämmen (KNBK, LFBK), dazu die Daten der Zahlungsläufe (z. B. REGUH).

Belege

Auch Belege tragen Personendaten, etwa abweichende Anschriften oder die Daten von Einmalkunden und -lieferanten (BSEC).

Personaldaten

Wo SAP HCM im selben System läuft, kommen Personalstamm und Abrechnungsergebnisse hinzu. Darunter können besondere Kategorien nach Art. 9 DSGVO sein, etwa Angaben zur Religionszugehörigkeit oder zur Gesundheit.

Versteckte Stellen

Änderungsbelege (CDHDR, CDPOS) mit alten und neuen Feldwerten, Langtexte und Notizen, IDocs, Anwendungs-Logs, Spool- und Sendeaufträge, Anhänge und die Benutzerstämme selbst.

Welche Felder in Ihrem System betroffen sind, hängt von Modulen, Erweiterungen und kundeneigenen Tabellen ab. Bei Personaldaten lohnt die Frage besonders, ob sie überhaupt ins Testsystem gehören. Eine Bestandsaufnahme steht deshalb am Anfang jedes Maskierungskonzepts.

Vier Ansätze für SAP-Testdaten mit Personenbezug

• Gar nicht kopieren: Entwicklungs- und Schulungssysteme kommen oft ohne Produktivdaten aus. Das Customizing ist dort ohnehin vorhanden oder kommt per Transport, Testdaten werden manuell oder per Skript angelegt. Welche Wege es gibt, zeigt der Artikel Testdaten für S/4HANA.
• Weniger kopieren: Eine Teilkopie per Zeitscheibe bringt nur die letzten Monate statt der gesamten Historie ins Testsystem. Je nach Werkzeug lassen sich ganze Bereiche, etwa Personaldaten, ausnehmen.
• Beim Kopieren maskieren: Greift die Maskierung, bevor die Daten in die Zieldatenbank geschrieben werden, erreicht der Klartext das Testsystem nicht. Wird erst nach der Kopie maskiert, liegen die Klardaten bis dahin im Zielsystem, unter Umständen auch in dessen Log-Sicherungen.
• Berechtigungen begrenzen: Rollen auch im Testsystem pflegen, weitreichende Profile nur gezielt vergeben, Zugriffe externer Dienstleister regeln. Berechtigungen ergänzen die anderen Ansätze, ersetzen sie aber selten, weil Tests oft weite Rechte brauchen.

In der Praxis werden die Ansätze kombiniert. Die Maskierung gehört dann fest in den Ablauf jedes Refreshs, wie die übrigen Schritte der Checkliste für die Nacharbeiten nach einer Kopie.

Grenzen der Maskierung

Maskieren klingt nach einem Schalter. In SAP ist es eher ein Konzept, das gepflegt werden will. Vier Stellen machen es schwierig:

• Konsistenz über Tabellen hinweg: Derselbe Geschäftspartner steht in Stammdaten, Adressen, Belegen, Zahlungsläufen, Änderungsbelegen und IDocs. Wird der Name nur an einer Stelle ersetzt, passt der Rest nicht mehr oder verrät den Klartext. Prüfungen in Prozessen und Schnittstellen brauchen außerdem stimmige Ersatzwerte, etwa gültige Prüfziffern.
• Freitexte: Langtexte, Notizen und Kommentarfelder enthalten, was jemand hineingeschrieben hat. Regeln für Felder erkennen solche Inhalte nicht zuverlässig.
• Anhänge: Rechnungen als PDF, gescannte Dokumente oder E-Mails. Je nach Ablage liegen sie in der Datenbank oder auf einem Content Server. Maskieren lassen sie sich kaum, eher ausschließen.
• Wiedererkennbarkeit: Auch ohne Namen kann ein Datensatz auf eine Person verweisen: der einzige Kunde in einem kleinen Ort, ein ungewöhnliches Gehalt, ein Lieferant mit bekanntem Auftragsvolumen. Wer im Testsystem arbeitet, kennt viele Vorgänge zudem aus der Produktion.

Dazu kommt die Pflege. Neue Felder, Erweiterungen und kundeneigene Tabellen müssen in die Regeln aufgenommen werden. Art. 32 DSGVO nennt ausdrücklich ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der Maßnahmen. Ob ein maskierter Testbestand noch personenbezogen ist, bewertet Ihr Datenschutz anhand des Gesamtbilds, nicht anhand einer Feldliste.

Maskierung im Refresh mit DRO

Der Data Refresh Operator (DRO) verbindet zwei der Ansätze. Er kopiert eine Zeitscheibe statt der kompletten Historie, zum Beispiel die letzten 90 Tage plus alle abhängigen Objekte. Ältere Vorgänge ohne Bezug zum gewählten Zeitraum landen gar nicht erst im Testsystem. Die Maskierung ist mit Data Protect integriert:

• 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, keine separate Nacharbeit. 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. Die Grenzen aus dem vorigen Abschnitt gelten auch hier: DRO liefert das Werkzeug, die Bewertung bleibt bei Ihnen. DRO läuft ab SAP S/4HANA 2023. Mehr zur Funktion auf der Seite SAP-Testdaten anonymisieren mit Data Protect. Im Vorstellungstermin zeigen wir, wie Data Protect in Ihrer Landschaft arbeiten würde.

Quellen

• dsgvo-gesetz.de: Art. 5 DSGVO: Grundsätze für die Verarbeitung personenbezogener Daten
• dsgvo-gesetz.de: Art. 25 DSGVO: Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen
• dsgvo-gesetz.de: Art. 32 DSGVO: Sicherheit der Verarbeitung
• dsgvo-gesetz.de: Art. 9 DSGVO: Verarbeitung besonderer Kategorien personenbezogener Daten
• BfDI, Stand 29.06.2020: Positionspapier zur Anonymisierung unter der DSGVO unter besonderer Berücksichtigung der TK-Branche
• BSI, IT-Grundschutz-Kompendium Edition 2023: Baustein OPS.1.1.6 Software-Tests und -Freigaben (Anforderung A11)