top of page

So funktioniert durchgängige Anwendungsdaten-Anonymisierung in SAP

  • Writer: Ben Ramhofer
    Ben Ramhofer
  • Apr 27
  • 7 min read


SAP-Landschaften enthalten hochsensible Personendaten: Kundenstammdaten, Mitarbeiterinformationen, Vertragsdaten, Zahlungsinformationen. Sobald diese Produktionsdaten in Test-, Schulungs- oder Entwicklungsumgebungen kopiert werden, entsteht ein massives DSGVO-Risiko. Artikel 25 DSGVO fordert Privacy by Design. Doch viele Unternehmen scheitern an der technischen Umsetzung durchgängiger Anwendungsdaten-Anonymisierung in SAP-Landschaften.


Die Folge: Personenbezogene Daten in ungeschützten Nicht-Produktivsystemen. Zugriff durch Entwickler, externe Dienstleister, Testteams. Keine Rechtsgrundlage nach DSGVO. Bußgeldrisiko bis zu 20 Millionen Euro oder 4 % des weltweiten Jahresumsatzes (Art. 83 Abs. 5 DSGVO).


Dieser Artikel erklärt, warum herkömmliche Ansätze scheitern, welche Datenschutzrisiken ohne durchgängige Anonymisierung entstehen und wie technische Anonymisierung für SAP-Testdatenmanagement funktioniert.


Warum scheitern viele Unternehmen bei der Datenanonymisierung?


1. Manuelle Maskierung ist nicht skalierbar

Viele Unternehmen versuchen, personenbezogene Daten manuell zu maskieren. SQL-Skripte werden geschrieben, um Namen, Adressen oder E-Mail-Adressen in Standardtabellen zu überschreiben. Dieser Ansatz funktioniert nicht für SAP-Landschaften mit Tausenden Tabellen, kundenspezifischen Z-Tabellen und komplexen Datenbeziehungen.


Das Ergebnis: Unvollständige Anonymisierung. Personenbezogene Daten bleiben in Logfiles, Archivtabellen, Customizing-Tabellen oder Freitextfeldern zurück. Unvollständige Anonymisierung bedeutet: Das Nicht-Produktivsystem enthält weiterhin personenbezogene Daten. Damit greifen sämtliche DSGVO-Pflichten, von der Rechtsgrundlage über Zugriffskontrollen bis zur Meldepflicht bei Datenpannen.


2. Inkonsistente Regeln über mehrere Systeme

System-Landschaften bestehen selten aus einem einzelnen System. ECC, S/4HANA, BW, CRM, Ariba, externe Datenbanken (Oracle, PostgreSQL, SQL Server), alle enthalten personenbezogene Daten. Werden Anonymisierungsregeln nicht systemübergreifend konsistent angewendet, entstehen Lücken.


Beispiel: Kundenummer 12345 wird in SAP ECC anonymisiert, bleibt aber in SAP BW unverändert. Cross-Referenzen ermöglichen Re-Identifikation.


3. Zerstörte referenzielle Integrität

Anonymisierung verändert Daten. Werden Werte nicht korrekt behandelt, bricht die referenzielle Integrität. Transaktionen schlagen fehl. Geschäftsprozesse laufen nicht durch. Das anonymisierte System ist nicht mehr nutzbar.


Viele Unternehmen stehen vor der Wahl: Entweder funktionsfähige Testsysteme mit echten Personendaten oder anonymisierte, aber unbrauchbare Kopien. Beides ist keine Lösung.


4. Fehlende Automatisierung

SAP-Systeme werden regelmäßig aktualisiert. Neue Daten fließen nach. Test- und Entwicklungsumgebungen benötigen wiederkehrende Refreshes. Ohne Automatisierung wird jede Anonymisierung zum manuellen Projekt. Der Aufwand ist nicht tragbar.


Was verursacht Datenschutzrisiken ohne durchgängige Anonymisierung?


Datenlecks durch erweiterte Zugriffsrechte: Entwickler, Testteams und externe Dienstleister benötigen Zugriff auf Nicht-Produktivsysteme. In Produktionsumgebungen gelten strenge Zugriffskontrollen. In Test- und Entwicklungsumgebungen oft nicht. Personenbezogene Daten sind damit einem deutlich größeren Personenkreis zugänglich.


Rechtsgrundlage nach DSGVO kaum begründbar: Die Rechtsgrundlage für die Verarbeitung echter personenbezogener Daten in Test- und Entwicklungsumgebungen ist in der Regel schwer zu begründen. Insbesondere dürfte eine Interessenabwägung nach Art. 6 Abs. 1 lit. f DSGVO regelmäßig zugunsten der betroffenen Personen ausfallen, wenn anonymisierte Daten den Zweck ebenso erfüllen können.


Verstoß gegen Privacy by Design (Art. 25 DSGVO): Artikel 25 DSGVO verpflichtet Unternehmen, technische und organisatorische Maßnahmen zu implementieren, die Datenschutzgrundsätze wirksam umsetzen. Das Kopieren von Produktionsdaten ohne Anonymisierung widerspricht diesem Grundsatz.


Meldepflicht bei Datenpannen: Kommt es in einer Testumgebung mit echten Personendaten zu einem Sicherheitsvorfall, greift die Meldepflicht nach Artikel 33 DSGVO. Unternehmen müssen den Vorfall innerhalb von 72 Stunden der Aufsichtsbehörde melden. Betroffene Personen müssen nach Art. 34 DSGVO informiert werden, wenn die Datenpanne voraussichtlich ein hohes Risiko für ihre Rechte und Freiheiten zur Folge hat. Der Reputationsschaden ist erheblich.


Erwägungsgrund 26 DSGVO stellt klar: Anonymisierte Daten fallen nicht in den Anwendungsbereich der DSGVO.


Voraussetzung nach Erwägungsgrund 26 DSGVO: Unter Berücksichtigung aller objektiven Faktoren, einschließlich Kosten, Zeitaufwand und zum Zeitpunkt der Verarbeitung verfügbarer Technologie, darf eine Identifizierung der betroffenen Person nach allgemeinem Ermessen nicht mehr wahrscheinlich sein. Pseudonymisierung (z. B. Verschlüsselung mit Schlüssel) reicht hierfür nicht aus, da die Daten weiterhin als personenbezogen gelten (ErwGr. 26, 28 DSGVO). AppSafe setzt DSIT-Algorithmen ein, die auf die Erfüllung dieses Maßstabs ausgelegt sind.


So funktioniert durchgängige Anwendungsdaten-Anonymisierung Schritt für Schritt


Durchgängige Datenanonymisierung in Anwendungen erfordert einen systematischen Prozess. AppSafe™ von Maya Data Privacy setzt diesen Prozess wie folgt um:


Schritt 1: Verbindung zu Quellsystemen

AppSafe wird als containerisierte Lösung (Docker) bereitgestellt und verbindet sich direkt mit den Quellsystemen: SAP S/4HANA, SAP ECC, SAP HANA, SAP BW, Oracle, PostgreSQL, SQL Server und alle JDBC-zugänglichen Datenbanken. Die Verarbeitung erfolgt in-system. Personenbezogene Daten werden dabei nicht außerhalb der Quellsysteme gespeichert, ein Prinzip, das als Zero-Storage-Architektur bezeichnet wird. Das bedeutet: Keine Zwischenkopien, keine temporären Dateien mit Echtdaten, kein zusätzliches Speicherrisiko.


Schritt 2: KI-gestützte PII-Erkennung

Personenbezogene Daten befinden sich nicht nur in Standardtabellen. Kundenspezifische Z-Tabellen, Freitextfelder, Logfiles, Customizing-Tabellen: überall können personenbezogene Informationen (PII) enthalten sein.


AppSafe nutzt KI-gestützte PII-Erkennung, um alle Tabellen automatisch zu scannen. Der Algorithmus identifiziert Namen, Adressen, E-Mail-Adressen, Telefonnummern, Bankverbindungen, und weitere sensible Informationen, auch in nicht dokumentierten Feldern. Für SAP-Verantwortliche bedeutet das: Der manuelle Aufwand der PII-Identifikation in komplexen Landschaften mit Tausenden Tabellen entfällt.


Schritt 3: PET-basierte Anonymisierung mit DSIT-Algorithmen

Nach der Identifikation erfolgt die Anonymisierung mit DSIT (Data Safe Intelligent Transformation). DSIT setzt Privacy-Enhancing Technologies (PET) ein, um Daten so zu anonymisieren, dass eine Re-Identifikation mit allen nach allgemeinem Ermessen wahrscheinlich genutzten Mitteln nicht mehr möglich ist.


Anonymisierung unterscheidet sich grundlegend von Maskierung. Maskierung ersetzt sensible Werte durch Platzhalter (z. B. „XXXXX") oder blendet sie bei der Ausgabe aus, die Daten verlieren dabei ihren Nutzwert für Tests, Entwicklung oder Analysen. DSIT hingegen transformiert Daten in realistische, konsistente Substitute: Die Werte sind fiktiv, aber strukturell und semantisch plausibel.


Beispiel: Aus „Max Mustermann" wird nicht „XXXXX", sondern ein synthetischer, aber glaubwürdiger Name wie „Lars Bergmann", inklusive passend transformierter Adresse, Bankverbindung und E-Mail-Adresse. Referenzielle Integrität und Systemfunktionalität bleiben vollständig erhalten.


Schritt 4: Vollständig funktionsfähige anonymisierte Kopie

Das Ergebnis ist eine vollständig funktionsfähige anonymisierte Kopie des Produktionssystems. Benutzer können sich anmelden. Transaktionen laufen durch. Geschäftsprozesse funktionieren End-to-End, von Order-to-Cash über Procure-to-Pay bis Hire-to-Retire. Der Unterschied: Alle personenbezogenen Daten wurden so anonymisiert, dass eine Re-Identifikation nach dem Maßstab des Erwägungsgrundes 26 DSGVO mit verhältnismäßigen Mitteln nicht mehr möglich ist.


Konsistente Anonymisierung über mehrere SAP-Systeme

SAP-Landschaften sind heterogen. ECC und S/4HANA laufen parallel. BW zieht Daten aus mehreren Quellen. CRM, Ariba, externe Datenbanken (Oracle, PostgreSQL) sind integriert.

Durchgängige Anwendungsdaten-Anonymisierung in SAP erfordert systemübergreifende Konsistenz. Dieselben Anonymisierungsregeln müssen zentral definiert und auf alle Systeme angewendet werden.


AppSafe ermöglicht dies durch:

  • Zentrale Regelverwaltung: Anonymisierungsregeln werden einmal definiert und auf alle verbundenen Systeme angewendet.

  • Cross-System-Konsistenz: Kundennummer 12345 wird in SAP ECC, S/4HANA, BW und Oracle identisch anonymisiert. Re-Identifikation durch Cross-Referenzen wird verhindert.

  • Erhalt der referenziellen Integrität: Beziehungen zwischen Systemen bleiben funktionsfähig. Datenflüsse zwischen ECC und BW funktionieren nach der Anonymisierung weiterhin.


Diese Konsistenz ist entscheidend für die Umsetzung von DSGVO-Anforderungen. Erwägungsgrund 26 fordert, dass anonymisierte Daten "nicht mehr einer bestimmten betroffenen Person zugeordnet werden können". Inkonsistente Anonymisierung über mehrere Systeme erfüllt diese Anforderung nicht.


Wie technische Anonymisierung DSGVO-Konformität unterstützt


Erwägungsgrund 26: Anonymisierte Daten fallen nicht unter die DSGVO


Erwägungsgrund 26 DSGVO stellt klar: Anonymisierte Daten fallen nicht in den Anwendungsbereich der DSGVO. Voraussetzung nach Erwägungsgrund 26 DSGVO: Unter Berücksichtigung aller objektiven Faktoren, einschließlich Kosten, Zeitaufwand und zum Zeitpunkt der Verarbeitung verfügbarer Technologie, darf eine Identifizierung der betroffenen Person nach allgemeinem Ermessen nicht mehr wahrscheinlich sein. Pseudonymisierung reicht nicht aus, da pseudonymisierte Daten weiterhin als personenbezogene Daten gelten (ErwGr. 26, 28 DSGVO). Auch einfache Maskierungsverfahren, bei denen eine Re-Identifikation mit verhältnismäßigem Aufwand möglich bleibt, erfüllen nicht die Anforderungen an eine wirksame Anonymisierung.


Artikel 25: Privacy by Design und Privacy by Default


Artikel 25 DSGVO verpflichtet Unternehmen, technische Maßnahmen zu implementieren, die Datenschutzgrundsätze wirksam umsetzen. Durchgängige Datenanonymisierung in Anwendungen unterstützt diese Anforderung.


Statt sich ausschließlich auf organisatorische Kontrollen (Zugriffsrechte, Schulungen, Richtlinien) zu verlassen, wird das Risiko technisch adressiert. Selbst bei einem Sicherheitsvorfall in der Testumgebung sind keine personenbezogenen Daten betroffen.


Artikel 5 Absatz 1 Buchstabe c: Datenminimierung


Artikel 5 Absatz 1 Buchstabe c DSGVO fordert, dass personenbezogene Daten "dem Zweck angemessen und erheblich sowie auf das für die Zwecke der Verarbeitung notwendige Maß beschränkt" sein müssen.


Für Test-, Schulungs- und Entwicklungszwecke sind echte Personendaten in der Regel nicht erforderlich. Die Verarbeitung echter Daten zu diesen Zwecken lässt sich daher nur schwer mit dem Grundsatz der Datenminimierung (Art. 5 Abs. 1 lit. c DSGVO) vereinbaren.


Wichtig: Der Einsatz von Datenanonymisierung-Software kann die Einhaltung des Datenminimierungsgrundsatzes unterstützen, ersetzt jedoch nicht die rechtliche Bewertung durch Datenschutzbeauftragte oder Rechtsabteilungen. Unternehmen sollten die Wirksamkeit der eingesetzten Anonymisierung durch ihre DPOs validieren lassen.


Worauf Sie bei der Auswahl einer Datenanonymisierung-Software achten sollten


Nicht jede Datenanonymisierung-Software ist für SAP-Testdatenmanagement geeignet. Achten Sie auf folgende Kriterien:


1. In-System-Verarbeitung statt Export-Import

Legacy-Ansätze exportieren Daten, verarbeiten sie extern und importieren sie zurück. Dieser Ansatz verdoppelt Speicherbedarf, verlängert Verarbeitungszeiten und erweitert die Angriffsfläche. Moderne Lösungen wie AppSafe verarbeiten Daten in-system. Keine Kopien personenbezogener Daten werden außerhalb der Quellsysteme gespeichert (Zero-Storage-Architektur).


2. KI-gestützte PII-Erkennung

SAP-Landschaften enthalten Tausende Tabellen. Manuelle Identifikation personenbezogener Daten ist nicht praktikabel. KI-gestützte PII-Erkennung scannt automatisch alle Tabellen, einschließlich kundenspezifischer Z-Tabellen.


3. Systemübergreifende Konsistenz

Prüfen Sie, ob die Lösung mehrere Systeme unterstützt: SAP ECC, S/4HANA, BW, HANA DB, Oracle, PostgreSQL, SQL Server. Anonymisierungsregeln müssen zentral definiert und konsistent angewendet werden.


4. Erhalt der referenziellen Integrität

Die anonymisierte Kopie muss vollständig funktionsfähig sein. Benutzer müssen sich anmelden, Transaktionen ausführen und Geschäftsprozesse durchlaufen können. Automatische Integritätsprüfungen sind unverzichtbar.


5. SAP-Zertifizierung

SAP-zertifizierte Lösungen wurden von SAP validiert. AppSafe ist über den SAP Store verfügbar und SAP-zertifiziert.


6. Containerisierte Bereitstellung

Moderne Architekturen setzen auf containerisierte Lösungen, da sich diese schnell bereitstellen lassen, skalieren und in bestehende Infrastrukturen integriert werden können (onPrem).


7. Technisch irreversible Anonymisierung

Prüfen Sie, ob die Lösung Anonymisierung (irreversibel) oder Pseudonymisierung (reversibel) einsetzt. Nur eine Anonymisierung, die nach dem Maßstab des Erwägungsgrundes 26 DSGVO eine Re-Identifikation mit verhältnismäßigen Mitteln ausschließt, führt dazu, dass die Daten nicht mehr in den Anwendungsbereich der DSGVO fallen.


Fazit: Durchgängige Anonymisierung als technische Notwendigkeit


Durchgängige Anwendungsdaten-Anonymisierung in SAP ist keine optionale Maßnahme. Artikel 25 DSGVO fordert Privacy by Design. Artikel 5 Absatz 1 Buchstabe c fordert Datenminimierung. Erwägungsgrund 26 bietet einen Ausweg: Daten, die so anonymisiert wurden, dass eine Identifizierung nach allgemeinem Ermessen nicht mehr wahrscheinlich ist, fallen nicht unter die DSGVO.


Herkömmliche Ansätze (manuelle Maskierung, inkonsistente Regeln, fehlende Automatisierung) scheitern an der Komplexität moderner SAP-Landschaften. Moderne Datenanonymisierung-Software wie AppSafe ermöglicht durchgängige, systemübergreifende Anonymisierung mit KI-gestützter PII-Erkennung, PET-basierten DSIT-Algorithmen und einer Anonymisierung im Unternehmensnetzwerk.

Das Ergebnis: Vollständig funktionsfähige Test-, Schulungs- und Entwicklungsumgebungen ohne Datenschutzrisiko. Schnellere SAP-Projekte. Reduziertes Bußgeldrisiko. Wirksame Umsetzung von Privacy by Design.


Möchten Sie mehr über durchgängige Datenanonymisierung für Ihre SAP-Landschaft erfahren? Informieren Sie sich über AppSafe im SAP Store oder kontaktieren Sie Maya Data Privacy für eine technische Evaluierung.

 

Rechtlicher Hinweis: Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Rechtsberatung dar. Die Bewertung der DSGVO-Konformität spezifischer Anonymisierungsmaßnahmen sollte durch Datenschutzbeauftragte oder Rechtsberater erfolgen. Maya Data Privacy übernimmt keine Haftung für Entscheidungen, die auf Grundlage dieses Artikels getroffen werden.

 
 
 
bottom of page