Inhalt
Vergangene Woche hat Ihre IT-Abteilung wahrscheinlich eine SAP-Systemkopie erstellt. Für Tests, für Entwicklung, vielleicht für eine Schulung. Ein Standardprozess, den jedes SAP-Team kennt und regelmäßig durchführt.
Was dabei kopiert wurde: sämtliche personenbezogenen Daten aus dem Produktivsystem. Mitarbeiterdaten, Kundendaten, Lieferantenkontakte, Transaktionshistorien, Bankverbindungen.
Dieser Standardprozess kann zu erheblichen Datenschutz- und Compliance-Risiken führen, wenn personenbezogene Daten ungeschützt in Testsystemen verbleiben.
Die SAP-Systemkopie: Standardprozess mit verstecktem DSGVO-Risiko
Systemkopien sind in der SAP-Landschaftsverwaltung unverzichtbar. Entwickler brauchen realistische Daten, um Anpassungen zu testen. QA-Teams brauchen produktionsnahe Szenarien, um Fehler zu finden. Und für Migrationsvorbereitungen sind Testsysteme mit realistischem Datenvolumen die einzige sinnvolle Testgrundlage.
Das Problem entsteht nicht durch den Prozess selbst. Es entsteht durch das, was die Kopie enthält, und durch das, was nach der Kopie nicht passiert.
Eine vollständige Systemkopie enthält alles. Jeden HR-Infotyp mit Name, Adresse, Gehalt und Bankverbindung. Jeder Geschäftspartner mit Kontaktdaten und Kommunikationshistorie. Jede Finanztransaktion mit Kundenreferenz und Zahlungsdetails.
Diese Daten landen auf einem System, das in der Regel schwächer geschützt ist als das Produktivsystem. Breitere Zugriffsrechte. Externe Berater mit Lesezugriff. Manchmal Entwickler mit Debug-Berechtigung auf sensible Tabellen. Keine definierten Löschfristen.
Warum SAP-Testsysteme dieselben DSGVO-Pflichten haben
Für die DSGVO ist entscheidend, dass personenbezogene Daten verarbeitet werden – unabhängig davon, ob dies in einem Produktiv-, Entwicklungs- oder Testsystem geschieht. Die Anforderungen an Zweckbindung, Datensicherheit und Zugriffsschutz gelten deshalb grundsätzlich für alle Systeme, in denen personenbezogene Daten gespeichert oder verarbeitet werden.
SAP-Testsysteme sollten entweder mit anonymisierten oder synthetischen Daten arbeiten oder sehr hohe Datenschutzstandards einhalten. In der Praxis bedeutet das: umfangreiche Zugriffskontrollen, Protokollierung, definierte Löschfristen und eine Begrenzung der Daten auf das für den jeweiligen Test erforderliche Maß.
Ein produktionsgleiches Datenschutzniveau ist für Testsysteme daher selten realistisch. Wer Testsysteme in dieser Form betreiben will, kann ihre Nutzbarkeit so stark einschränken, dass sie schnell ihren Zweck verfehlen. Eine praktikable Lösung ist die konsistente Anonymisierung.
Was Anonymisierung leisten muss
DSGVO-konforme Anonymisierung für SAP-Testsysteme ist kein einfaches „Felder überschreiben“. Die Herausforderung liegt auch in der referenziellen Integrität. Geschäftspartner BP-1234 taucht in Dutzenden von Tabellen auf: Bestellungen, Rechnungen, Zahlungen, Konditionen, Ansprechpartner. Wenn die Anonymisierung BP-1234 zu BP-ANON-5678 macht, muss das in allen Tabellen konsistent geschehen. Sonst bricht die Datenintegrität, und das Testsystem wird unbrauchbar.
Genau daran scheitern einfache Ansätze.
Subsetting
Data Subsetting – also die Übernahme eines gezielt ausgewählten Teils der Produktivdaten – reduziert zwar das Datenvolumen und damit häufig auch die Anzahl personenbezogener Datensätze. Sind die verbleibenden Daten jedoch weiterhin personenbeziehbar, bestehen die datenschutzrechtlichen Anforderungen grundsätzlich fort.
Synthetische Testdaten bilden reale Geschäftsszenarien häufig nur eingeschränkt ab. Ein synthetischer Lieferant hat häufig keine belastbare Bestellhistorie, keine Preisvereinbarungen, keine saisonalen Muster. Für klar abgegrenzte Funktionstests kann das ausreichen – für Integrations- und Performancetests möglicherweise nicht.
Manuelle Maskierung stößt in großen SAP-Landschaften schnell an Grenzen. Bei Systemen mit 10.000, 50.000 oder mehr Tabellen lässt sich kaum sicherstellen, dass sensible Inhalte vollständig und über alle Datenbestände hinweg konsistent ersetzt oder verfremdet werden.
Wie man 70 TB SAP-Daten konsistent anonymisiert – Kundenbeispiel DZ BANK
Die Lösung Smart Data Protection (SDP) von paricon anonymisiert SAP-Systemkopien vollständig und referenzinteger. Das bedeutet: Alle personenbezogenen Daten werden durch konsistente Werte ersetzt, die über sämtliche Tabellen hinweg zusammenpassen. Dabei bleiben relevante Datenbeziehungen und die fachliche Nutzbarkeit des Testsystems erhalten, nur ohne echte Personendaten.
Das ist keine theoretische Aussage: Bei der DZ BANK wurde mithilfe von Smart Data Protection eine ERP-Systemkopie von rund 70 TB anonymisiert. Das Ergebnis: ein Testsystem, das für realistische Tests vollständig nutzbar ist und gleichzeitig DSGVO-konform.
Smart Data Protection läuft SAP-nativ, ohne Datenexport, Clean-Core-konform. Die Lösung erkennt personenbezogene Daten in Standardtabellen und in kundeneigenen Z-Tabellen, unabhängig von der Art des SAP-Systems oder von den SAP-Modulen. Die Anonymisierung ist wiederholbar, sodass jede neue Systemkopie denselben Prozess durchlaufen kann.
Das Timing-Problem
Jede Systemkopie, die ohne Anonymisierung erstellt wird, kann zu einem potenziellen DSGVO-Verstoß führen. Wenn Ihre IT-Abteilung quartalsweise oder monatlich Systemkopien erstellt, entstehen jedes Jahr vier oder zwölf neue Kopien mit personenbezogenen Daten aus dem Produktivsystem – und damit ebenso viele neue potenzielle DSGVO-Risiken.
Das Risiko ist kumulativ. Alte Testsystemkopien, die nicht gelöscht werden, enthalten personenbezogene Daten, die im Produktivsystem möglicherweise längst gelöscht sind. Eine Person, die ihr Recht auf Löschung ausgeübt hat, deren Daten aber in drei Testsystemkopien weiter existieren, hat ein berechtigtes Anliegen – und Ihr Unternehmen hat ein Problem.
Die Lösung liegt nicht darin, weniger Systemkopien zu erstellen – sie sind für Tests und Migrationen unverzichtbar. Die Lösung liegt darin, jede Kopie vor der Nutzung zu anonymisieren.
Standardisiert, automatisiert, vollständig.
Der erste Schritt: Transparenz über Ihre Daten
Viele IT-Leiter unterschätzen den Umfang personenbezogener Daten in ihren Testsystemen, weil sie nur an die offensichtlichen Tabellen denken: HR-Stammdaten, Geschäftspartner, Kundenadressdaten. Aber eine Systemkopie kann auch Änderungsbelege mit historischen Personendaten, Spool-Dateien mit Druckausgaben, Anwendungsprotokolle mit Benutzeraktivitäten und kundeneigene Tabellen enthalten, die oft undokumentiert personenbezogene Inhalte speichern.
Ein systematischer DSGVO-Scan Ihres Testsystems zeigt, welche personenbezogenen Daten tatsächlich vorhanden sind. Nicht auf Basis einer Vermutung, sondern durch eine vollständige Analyse aller Tabellen und Namensräume. Das Ergebnis ist die Grundlage für die Entscheidung: Welche Daten müssen anonymisiert werden? Welche Anonymisierungsregeln gelten für welche Datentypen? Wie integrieren Sie die Anonymisierung in Ihren bestehenden Systemkopie-Prozess?
Mit diesem Wissen wird Anonymisierung vom einmaligen Projekt zum wiederholbaren Standardprozess. Bei jeder Systemkopie. Automatisiert. Ohne manuellen Aufwand.
