Sind Sie compliant oder testen Sie trotzdem?

Doch wie sieht der Umgang mit personenbezogenen und anderen unternehmenskritischen Daten auf nicht produktiven Systemen aus? Wenn nicht gerade ein striktes Berechtigungsmanagement analog den Produktivsystemen den Zugriff auch auf Sandboxes und QA-Systeme klar strukturiert, ist den technischen Möglichkeiten eines ungewollten Datenabflusses nach wie vor Tür und Tor geöffnet.

Das Berechtigungswesen

Unsere Erfahrung zeigt, dass interne wie externe Entwickler oft verhältnismäßig einfach Zugriff auf QA-Systeme erhalten, meist mit wesentlich umfangreicheren Berechtigungen, als sie im produktiven Umfeld je erhalten würden.

Schließlich soll mit vollumfänglichen Echtdaten getestet werden. Denn reduzierte, aber logisch konsistente Datenbestände lassen eine funktionale Durchgängigkeit, die auch alle realen Sonderfälle abdeckt sowie verlässliche Performanceaussagen trifft, nur bedingt zu.

Zudem sind sie auch nur mit umfassenden Konfigurationsarbeiten zu erreichen und bedürfen darüber hinaus relativ langer Export-/Import-Durchlaufzeiten.

Kopie und Klon

Daher setzen viele Unternehmen auf die homogene Systemkopie oder den Systemklon. Denn nie wurden Systemkopien einfacher, häufiger und schneller durchgeführt als heute. QA- und Testsysteme werden auf den sprichwörtlichen Knopfdruck aufgebaut und/oder aktualisiert, gerade auch in Verbindung mit vergleichsweise günstigen und „einfach beschaffbaren“ Cloudumgebungen.

Das ist generell eine gute Sache. Jedoch stehen dadurch vollständige Datenbestände inklusive personenbezogener und anderer unternehmenskritischer Daten zunehmend auch durch Unberechtigte im Zugriff. Wenn diese Systeme dazu auch noch unter dem Radar der Datenschutzbeauftragten und der DSGVO (Stichwort:

Recht auf Auskunft, oder: „in welchen Systemen liegen welche meiner personenbezogenen Daten?“) laufen, finden sich im Zweifelsfall gleich mehrere Verstöße gegen aktuelle Gesetze und interne wie externe Compliance-Vorgaben.

Um dies in den Griff zu bekommen, gibt es nur wenige Möglichkeiten. Erstens strikte Limitierung der Systemanzahlen und konsequentes Löschen personenbezogener und anderer kritischer Daten – aus unserer Sicht klar entgegen der Zielsetzung dieser Systeme.

Zweitens striktes Umsetzen von Berechtigungskonzepten analog der produktiven Umgebungen – und damit einhergehend Beschränkung der Arbeits­fähigkeit und -effizienz von Entwicklern, Beratern, Testern.

Drittens durch persistente Datenanonymisierung dafür sorgen, dass solche Systeme eben keine sensiblen und unternehmenskritischen Daten mehr anbieten – aus unserer Sicht der Königsweg, sofern die „logische Arbeitsbefähigung“ der Daten weiter gewährleistet ist.

Damit ist gemeint, dass diese Systeme keine kritischen Echtdaten mehr führen, aber weiterhin Datensätze anbieten, die echt aussehen und logisch konsistent sind. Altersstrukturen sollen generell ähnlich bleiben, Regionalverteilungen genauso wie sonstige Clusterungen/Segmentierungen.

Finanzdatensätze, IBAN oder Checksummen für Kreditkarten sollen genauso korrekt berechnet sein, wie Straßenadressen korrekten PLZ zugeordnet sind. Und einige weitere kritische Fälle.

All diese logischen Abhängigkeiten sollten bei einer Anonymisierung initial bedacht werden, und zwar nicht nur innerhalb eines Systems in der Geschäftsprozesskette, sondern über alle Systeme und Datenbanken des gesamten Geschäftsprozesses hinweg. Dass dabei mitunter neben SAP-Systemen auch andere Applikationsplattformen mitspielen, sollte ebenfalls mehr als nur im Hinterkopf bleiben.

Templates für alle

Das Gute dabei: Die Datenmodelle der meisten großen Applikationshersteller sind bekannt. Und somit haben Anbieter wie wir mit Libelle DataMasking reife Tem­plates mit an Bord, die bereits einen Großteil dieser Anforderungen umfassen. Out of the box verfügbar, sofort einsetzbar und auch schrittweise erweiterbar.

Im gesamten Themengebiet der Compliance lässt sich somit die Baustelle „kritische Daten in nicht produktiven Systemen“ hinsichtlich interner wie externer Vorgaben vergleichsweise einfach und schnell regeln, ohne die Arbeitsfähigkeit von Beratern und Entwicklern einzuschränken.