allabout compliance · 2020. 2. 4. · grundlagen der prüfung ... und wurde auf einem...

ALLABOUTCOMPLIANCEDatenschutzkonformität von SAP Testsystemen

WHITEPAPER

Whitepaper: Datenschutzkonformität von SAP Testsystemen

2

Inhalt

1. Hinweise ............................................................................................................................................... 3

2. Ausgangslage ........................................................................................................................................ 3

2.1 Ziele und Hintergrund ..................................................................................................................... 3

3. Grundlagen der Prüfung ......................................................................................................................... 4

3.1 Prüfauftrag / Prüfer / Prüfzeitraum / Prüfprodukt ............................................................................. 4

3.2 Hintergründe zum Test Data Anonymization (TDA) .......................................................................... 4

3.3 Abgrenzung (Scope) ....................................................................................................................... 5

4. Rechtliche und technische Anforderungen an die Umsetzung ................................................................ 5

4.1 Datenschutzrechtliche Abgrenzung ................................................................................................ 5

4.1.1 Das Bundesdatenschutzgesetz ........................................................................................... 5

4.1.2 Landesdatenschutzgesetze ................................................................................................. 5

4.1.3 Datenschutz bei den Kirchen ............................................................................................... 5

4.2 Datenschutzrechtliche Anforderungen ............................................................................................ 6

4.2.1 Anonymisierung und Pseudonymisierung von Daten ............................................................ 6

4.3 Anforderungen aus § 9 BDSG ........................................................................................................ 7

4.3.1 Zutrittskontrolle .................................................................................................................... 7

4.3.2 Zugangskontrolle ................................................................................................................. 7

4.3.3 Zugriffskontrolle ................................................................................................................... 8

4.3.4 Weitergabekontrolle ............................................................................................................. 9

4.3.5 Eingabekontrolle .................................................................................................................. 9

4.3.6 Auftragskontrolle ................................................................................................................ 13

4.3.7 Verfügbarkeitskontrolle....................................................................................................... 13

4.3.8 Trennungsgebot................................................................................................................. 13

5. Zusätzliche Funktionen des TDA .......................................................................................................... 13

5.1 Eingabemaske .............................................................................................................................. 13

5.2 Schutz von Projekten ................................................................................................................... 15

5.3 Weiterentwicklungen und Updates ............................................................................................... 15

6. Bewertung 16

6.1 Datenschutz ................................................................................................................................. 16

6.2 Datensicherheit ............................................................................................................................ 17

7. Fazit .................................................................................................................................................. 18

8. Nachweis der Compliance-Festigkeit ................................................................................................... 18

9. Kontakt / Autor .................................................................................................................................... 19

1. Hinweise

ALLABOUT ist seit 2006 eine Whitepaper-Reihe, die von PRW Rechtsanwälte herausgegeben wird. Sie befasst sich mit ausgewählten Themen aus dem Bereich IT-Compliance.

In dieser Ausgabe wird das Produkt Test Data Anonymization (TDA) der NATUVION GmbH auf seine Daten-schutz konformität bei der Anonymisierung / Pseudonymisierung von Testsystemen geprüft.

Aus Gründen der sprachlichen Vereinfachung wurde auf die geschlechterspezifische Sprachform verzichtet, stellvertretend auch für die weibliche wurde die männliche Form gewählt.

Die Markenrechte an SAP stehen allein SAP zu. Der Umgang mit dieser Marke erfolgt im Hinblick auf diese Publikation lediglich redaktionell.

Wir weisen darauf hin, dass das vorliegende Gutachten mit größter Sorgfalt durchgeführt wurde und die Einschätzung auf unserer persönlichen rechtlichen Bewertung basiert. Ungeachtet dessen besteht bei derartigen Rechtsfragen und Begutachtungen stets die Möglichkeit einer anderen Auffassung, zumal höchstrichterliche Entscheidungen von Gerichten zu einer Vielzahl der aufgeworfenen Bereiche bislang fehlen. Zudem besteht bei derartigen Prüfungen grundsätzlich immer die Möglichkeit, dass sich die Rechtslage aufgrund von überarbeiteten Gesetzen, Verordnungen und Vereinbarungen verändert.

Dieser Prüfbericht stellt zudem keine Rechtsberatung dar und kann eine solche auch keinesfalls ersetzen. Wir empfehlen stets, sich bei informations- oder datenschutzrechtlichen Fragen von Spezialisten individuell rechtlich beraten zu lassen.

2. Ausgangslage

2.1 Ziele und Hintergrund

Das Thema Datenschutz hat in den letzten Jahren deutlich an Relevanz gewonnen. Seien es die Abhörskandale oder die Entscheidung des EuGH zum Thema Safe Harbor. Zugenommen hat auch der Awareness-Faktor zum Thema Imageschaden durch Datenschutzverletzungen. Ziel dieses Papers ist es, den Datenschutzbeauftragten und IT-Verantwortlichen in den Unternehmen eine Hilfestellung zu geben beim datenschutzrechtlichen Umgang mit Testdaten in SAP Systemen.

Die Erhebung, Verarbeitung und Nutzung von personenbezogenen Daten unterliegt den Anforderungen der unterschiedlichen Datenschutzgesetze1. Die unterschiedlichen Datenschutzgesetze gehen dabei unter anderem von einer sogenannten Zweckbindung bei der Datenhaltung und Verarbeitung aus. Diese Zweckbindung besteht in der Regel nur für das Produktivsystem und nicht für hieraus abgeleitete Testsysteme, die mit Echtdaten befüllt sind.

Aufgrund der Zweckbindung ist die Verarbeitung von personenbezogenen Daten in einem Testsystem, nur mit Hilfe einer expliziten Einwilligung der betroffenen Person möglich. Diese Einwilligung ist jedoch nur mit einem enormen Aufwand zu erhalten und kann jederzeit von der betroffenen Person widerrufen werden. Ziel des hier geprüften Produkts Test Data Anonymization (TDA) soll es sein, Testsysteme so zu gestalten, dass sie datenschutzkonform einsetzbar sind.

Unternehmen, die ihre Testsysteme entgegen den datenschutzrechtlichen Anforderungen betreiben, sollten beachten, dass hierauf von den zuständigen Behörden hohe Geldbußen (von bis zu 300.000,00 EUR pro Fall und in Zukunft noch höher) verhängt werden können. Hinzu kommt die Löschanordnung der Testsysteme. Die sich daraus ergebenden Konsequenzen mag sich jeder selbst vorstellen.

31 Siehe Kapitel 4.1.


4

Im Wesentlichen wurde somit geprüft, ob das Produkt Test Data Anonymization (TDA) eine vollständige Anonymisierung oder Pseudonymisierung von Testsystemen ermöglicht und somit ein datenschutzkonformer Betrieb von Testsystemen möglich ist.

Obwohl die Geschichte von Cloud Computing noch nicht so weit zurückreicht (die ersten Websites mit Cloud Computing-Services für Unternehmen und Verbraucher gingen 1999 online), ist die Geschichte dieser Technologie von Beginn an mit datenschutzrechtlichen Bedenken behaftet gewesen. Zu Unrecht sagen diejenigen, die die gesetzlichen Grundlagen kennen und ihre Vorgaben beachten.

3. Grundlagen der Prüfung

3.1 Prüfauftrag / Prüfer / Prüfzeitraum / Prüfprodukt

Der Prüfauftrag wurde von der NATUVION GmbH, Altrottstraße 31, in 69190 Walldorf gemeinsam mit der INTENSE AG, Ludwigstraße 20, in 97070 Würzburg am 17.08.2015 erteilt.

Das Prüferteam bestand aus Anwälten der auf den IT-Bereich spezialisierten Anwaltskanzlei PRW Rechts-anwälte in München, aus Datenschützern und Technik Consultants der auf IT-Compliance spezialisierten PRW Consulting GmbH in München sowie aus Beratern der Smart Security GmbH aus Basel. Die Koordination oblag dabei der PRW Consulting GmbH.

Der Prüfzeitraum erstreckte sich vom 01.09.2015 bis zum 28.10.2015. Sämtliche angeforderten Unterlagen, Dokumentationen, Hintergrundinformationen sowie das TDA und das DCS Benutzerhandbuch wurden von der NATUVION GmbH bereitgestellt.

Produktname Test Data Anonymization (TDA)

Produktversion 2.0

Applikationstyp Addon für SAP Data Conversion Server (DCS)

Hersteller NATUVION GmbH Altrottstraße 31 69190 Walldorf

Fachlicher Partner INTENSE AG Ludwigstraße 20 97070 Würzburg

3.2 Hintergründe zum Test Data Anonymization (TDA)

Das Test Data Anonymization (TDA) ist ein Addon für den Data Conversion Server (DCS) der NATUVION GmbH und wurde auf einem Systemverbund von SAP ERP 6.0 inklusive SAP IS-U, SAP HCM und SAP CRM entwickelt und erprobt. TDA ist ein systemübergreifendes Anonymisierungsprogramm.

Eine Anonymisierung der personenbezogenen Daten würde bedeuten, dass auch Schlüsselfelder und technische Daten (z. B. Geschäftspartner, Mitarbeiter, etc.) durch synthetische Daten ersetzt werden, was dem Sinn der jeweiligen Systeme zur Analyse von Fehlersituationen und der Sicherstellung produktiver Abläufe ent-gegen stehen würde.

Darum führt das TDA eine Pseudonymisierung der Daten durch. Die Pseudonymisierung erfüllt hier die Anforderungen des BDSG unter Beibehaltung der Systemnutzbarkeit. Die echten personenbezogenen Daten werden identifiziert, dann auf Feldebene beschrieben und durch pseudonymisierte Ersatzwerte ausgetauscht. Hierzu wurde ein Fachkonzept erarbeitet und vorgelegt.

Die Ersatzwerte aus Name und Adresse stellen keine in der Realität vorkommende Datenkonstellation dar. Kommunikationsdaten wie Telefonnummern und ähnliches werden durch synthetische Daten ausgetauscht.

5

Bankdaten werden durch Ersatzwerte überschrieben, die zu der Kombination Name und Anschrift keinerlei Bezug haben. Technische Daten, beispielsweise Daten zum Anschlussobjekt, werden nicht ersetzt. Diese Daten sind für Fehleranalysen im Systembetrieb notwendig und können zur Nutzung des Systems nicht geändert werden.

3.3 Abgrenzung (Scope)

Gegenstand des vorliegenden Berichts ist die datenschutzrechtliche Prüfung der „Test Data Anonymization“ (TDA) Applikation der NATUVION GmbH. Mit dieser Bewertung wird nur die Applikation betrachtet und nicht die Infrastruktur, in der die Applikation betrieben wird. Es wird jedoch auf Randbedingungen verwiesen, die notwendig sind, um einen datenschutzkonformen Betrieb zu gewährleisten.

Neben der datenschutzrechtlichen Betrachtung der Applikation werden auch die datenschutzrechtlichen Anforderungen an Testsysteme betrachtet, damit ein ganzheitlicher Einblick in die Problematik von Testsystemen entsteht.

Das Dokument enthält keine Handlungsempfehlungen für Prozesse rund um Systemupdates bzw. Kopien. Hierzu sollte bei möglicher Verwendung des TDA ein eigenes Projekt initiiert werden.

4. Rechtliche und technische Anforderungen an dieUmsetzung

4.1 Datenschutzrechtliche Abgrenzung

4.1.1 Das Bundesdatenschutzgesetz

Das Bundesdatenschutzgesetz regelt den Umgang mit personenbezogenen Daten durch öffentliche Stellen des Bundes. Darüber hinaus gilt es für nicht-öffentliche Stellen, soweit sie personenbezogene Daten unter Einsatz von Datenverarbeitungsanlagen verarbeiten, nutzen oder dafür erheben oder die Daten in oder aus automatisierten Dateien verarbeiten, nutzen oder dafür erheben. Daneben gibt es bereichsspezifische Vorschriften in anderen Gesetzen. Die Datenschutzgesetze des Bundes und der Länder dienen teilweise der Umsetzung der EU-Richtlinien zum Datenschutz in deutsches Recht.

4.1.2 Landesdatenschutzgesetze

Landesdatenschutzgesetze sind die in den 16 Bundesländern verabschiedeten landesrechtlichen Pendants zum Bundesdatenschutzgesetz. Die Landesdatenschutzgesetze regeln den Umgang mit personenbezogenen Daten durch die Behörden und sonstigen öffentlichen Stellen des Landes, der Gemeinden und Gemeinde-verbände sowie der sonstigen der Aufsicht des Landes unterstehenden juristischen Personen des öffentlichen Rechts. Eine Übersicht der Landesdatenschutzgesetze findet sich auf der Website www.datenschutz.de. Die Vorschriften nach den jeweiligen LDSG und dem BDSG sind in vielen Bereichen inhaltsgleich. Häufig wird in den landesdatenschutzrechtlichen Vorschriften auf das Bundesdatenschutzgesetz verwiesen.

4.1.3 Datenschutz bei den Kirchen

Öffentlich-rechtliche Religionsgemeinschaften der katholischen und evangelischen Kirche haben das Recht, ihre Angelegenheiten selbstständig innerhalb der Schranken, der für alle geltenden Gesetze zu ordnen und zu verwalten. Eine dieser Schranken ist das Recht auf informationelle Selbstbestimmung, welches dem Selbstverwaltungsrecht Grenzen setzt. Infolge dessen müssen die öffentlich-rechtlichen Religions-gemeinschaften, auch den Datenschutz in ihrem Zuständigkeitsbereich selbst regeln. Dies ist geschehen. Hierbei wurde Anleihe an das Bundesdatenschutzgesetz genommen.

Zum einfachen Verständnis wird nachfolgend immer einheitlich auf die Vorschriften des Bundesdatenschutz-gesetzes (BDSG) verwiesen.

http://www.datenschutz.de


6

4.2 Datenschutzrechtliche Anforderungen

Der Rahmen für die Erhebung, Verarbeitung und Nutzung von personenbezogenen Daten ist in § 4 Abs. 1 BDSG konkretisiert und wird oftmals als „Verbot mit Erlaubnisvorbehalt“ beschrieben.2 Gemäß § 4 Abs. 1 BDSG ist jede Erhebung, Verarbeitung und Nutzung von personenbezogenen Daten verboten, solange sie nicht durch eine gesetzliche Ermächtigungsgrundlage oder durch die explizite Einwilligung der betroffenen Person gestützt ist.

Die beiden häufigsten Ermächtigungsgrundlagen, im Bereich der Verwendung von personenbezogenen Daten auf eigenen Systemen, sind die §§ 28 und 32 BDSG. Der § 28 BDSG erlaubt die Erhebung, Verarbeitung und Nutzung von personenbezogenen Daten für die Erfüllung von eigenen Geschäftszwecken, z. B. für die Durchführung oder Beendigung eines rechtsgeschäftlichen oder rechtsgeschäftsähnlichen Schuldverhältnisses mit dem Betroffenen. Für die Erhebung, Verarbeitung und Nutzung von personenbezogenen Daten im Beschäftigungsverhältnis ist § 32 BDSG die bereichsspezifische Regelung.3 Welche dieser Bestimmungen einschlägig ist, hängt davon ab, welcher Zweck für das Unternehmen bei der Überprüfung betroffen ist.

Beide Ermächtigungsgrundlagen erlauben jedoch nicht die Erhebung, Verarbeitung und Nutzung personen-bezogener Daten für andere Geschäftszwecke, als für die Speicherung der Daten im Produktivsystem. Eine Verwendung dieser personenbezogenen Daten in Testsystemen ist aufgrund des Zweckbindungsgrundsatzes des BDSG nicht statthaft.

Eine Verarbeitung der personenbezogenen Daten zu einem anderen als dem ursprünglich festgelegten Zweck, ist nur aufgrund einer erneuten gesetzlichen Grundlage oder mit einer Einwilligung der betroffenen Person zulässig. Wie zuvor erwähnt, wird die Einwilligung der Betroffenen nur mit großem Aufwand zu erhalten sein. Somit muss eine sogenannte Interessenabwägung nach § 28 BDSG vorgenommen werden. Ein Bestandteil dieser Interessenabwägung ist, dass die Verwendung der personenbezogenen Daten im Testsystem das mildeste Mittel sein muss. Oder anders ausgedrückt, wenn es möglich ist, dass Systeme auch ohne echte personenbezogene Daten getestet werden können, dann muss dies als das mildeste Mittel angesehen werden. Mithin ist eine Verwendung von personenbezogenen Daten in Testsystemen dann nicht mehr zulässig, wenn auch anonymisierte oder pseudonymisierte Daten für diesen Zweck ausreichend sind.4

4.2.1 Anonymisierung und Pseudonymisierung von Daten

Maßgebend für die Begriffe der Anonymisierung und Pseudonymisierung sind § 3 Abs. 6 BDSG und § 3 Abs. 6a BDSG.

Die Definition der Anonymisierung in § 3 Abs. 6 BDSG hat ihren Ursprung in § 31 Abs. 1 Nr. 2 BDSG von 1977.5

Anonymisieren ist das Verändern personenbezogener Daten derart, dass die Einzelangaben über persönliche oder sachliche Verhältnisse nicht mehr oder nur mit einem unverhältnismäßig großen Aufwand an Zeit, Kosten und Arbeitskraft einer bestimmten oder bestimmbaren natürlichen Person zugeordnet werden können.

Die Definition der Pseudonymisierung wurde im Jahr 2001 in § 3 Abs. 6a in das BDSG mit aufgenommen.6

Pseudonymisieren ist das Ersetzen des Namens und anderer Identifikationsmerkmale durch ein Kennzeichen zu dem Zweck, die Bestimmung des Betroffenen auszuschließen oder wesentlich zu erschweren.

2 Vgl. Sokol, Simitis, BDSG § 4 Rn. 3.3 Vgl. Seifert, Simitis, BDSG § 32 Rn. 4.4 Gemäß § 3a BDSG ist ein Unternehmen verpflichtet personenbezogene Daten zu anonymisieren oder zu pseudonymisieren,

wenn der Zweck der Datenverwendung trotz dieser Erschwernis erreicht werden kann.5 Vgl. Dammann, Simitis, BDSG § 3 Rn. 196.6 Vgl. Scholz, Simitis, BDSG § 3 Rn. 212.

7

Bei der Pseudonymisierung werden personenbezogene Daten durch ein Pseudonym ersetzt. Grundsätzliche Anforderung an eine Pseudonymisierung ist, dass nicht nur ein Datensatz in einer Datenbank ersetzt wird, sondern alle identifizierenden Angaben über eine natürliche Person.7 Eine weitere Eigenschaft der Pseudonymisierung ist es, dass der Personenbezug der Datensätze mit Hilfe eines Schlüssels wieder herstellbar ist und somit der Datenschutz nur „ausgesetzt“ wird.

Wie zuvor beschrieben verwendet die Applikation des Unternehmens NATUVION GmbH eine Pseudonymisierung der personenbezogenen Daten.

Im folgenden Dokument wird nun speziell auf die Umsetzung der Anforderungen aus dem BDSG mit dem Addon TDA eingegangen.

4.3 Anforderungen aus § 9 BDSG

Öffentliche und nicht-öffentliche Stellen, die selbst oder im Auftrag personenbezogene Daten erheben, verarbeiten oder nutzen, haben die technischen und organisatorischen Maßnahmen zu treffen, die erforderlich sind, um die Ausführung der Vorschriften dieses Gesetzes, insbesondere die in der Anlage zu diesem Gesetz genannten Anforderungen, zu gewährleisten. Erforderlich sind Maßnahmen nur, wenn ihr Aufwand in einem angemessenen Verhältnis zu dem angestrebten Schutzzweck steht.

4.3.1 Zutrittskontrolle

Anforderung:Unbefugten ist der Zutritt zu Datenverarbeitungsanlagen, mit denen personenbezogene Daten verarbeitet oder genutzt werden, zu verwehren. Hierbei geht es um den unmittelbaren Zutritt zu Datenverarbeitungsanlagen.

Umsetzung:Die Umsetzung dieser Anforderung betrifft jedoch nicht die Applikation selbst, sondern muss von jedem Unternehmen eigenständig umgesetzt werden.

4.3.2 Zugangskontrolle

Anforderung:Der Zugang auf Systeme, die Informationen mit besonderem Schutzbedarf enthalten, muss generell mit Maßnahmen zur Feststellung der Identität des Benutzers abgesichert werden. Dies geschieht, indem der Benutzer dem System bei der Anmeldung Informationen liefert, die mit dem betreffenden Benutzer verknüpft sind. Der Zugang zum System bzw. auf das TDA darf nur für autorisierte Anwender möglich sein. Diese müssen sich über ihre Benutzerkennung und das Passwort identifizieren, um Zugriff zu erhalten. Das Passwort muss ausreichend sicher sein, d. h. es darf nicht leicht zu erraten sein und muss regelmäßig geändert werden.

Umsetzung:Durch die Integration in das SAP Standardberechtigungskonzept ist sichergestellt, dass nur autorisierte Benutzer Zugang auf die Anwendung besitzen. Die Umsetzung und Einbettung in die Berechtigungsverwaltung ist grundlegende Voraussetzung während der Installation/Einführungsphase. Die Zugangskontrolle des TDA oder der DCS Konsole wird durch das Rollen- und Rechtemanagement der SAP Infrastruktur durchgeführt, an dem sich der Benutzer zuvor angemeldet hat.

7 Vgl. Scholz, Simitis, BDSG § 3 Rn. 214.


8

4.3.3 Zugriffskontrolle

Anforderung:Die Vergabe von Zugriffsrechten auf die Applikation muss nach dem „Need-to-know“-Prinzip erfolgen. Die Administration der Applikation darf nur in den Händen weniger Administratoren liegen, die aufgabengebundenen Zugriff auf das System haben. Die Anzahl der berechtigten Benutzer muss zudem möglichst klein gehalten werden, ohne jedoch den ordnungsgemäßen Betrieb, bei Ausfall eines Mitarbeiters, zu gefährden. Nicht mehr benötigte Rechte müssen zeitnah entzogen werden. Des Weiteren muss eine zeitliche Begrenzung der Berechtigungen möglich sein, die vor Ablauf verlängert werden kann. Die Berechtigungen dürfen nur durch Zuordnung einer oder mehrerer Rollen zu einem Anwender oder durch die Zuordnung eines Anwenders zu einer Gruppe vergeben werden. Eine direkte Zuordnung einer Berechtigung zu einem Anwender ist nicht erlaubt. Dies ist durch ein Rollen- und Rechtekonzept sicherzustellen.

Umsetzung:Durch die Identifikation des Benutzers kann dieser am TDA nur Funktionen nutzen, die ihm zuvor durch die Zuweisung einer Rolle, z. B. „TDA Standarduser“, zugewiesen wurde. Damit ist das „Need-to-know“-Prinzip eingehalten. Das TDA nutzt das Rollen- und Rechtekonzept, welches von der SAP Infrastruktur angeboten wird. Beim Einsatz des TDA hat der Betrieb darauf zu achten, dass diese Anforderungen umgesetzt sind, sonst ist ein datenschutzkonformer Betrieb des Produktes nicht möglich.

Die TDA Applikation bindet sich in das bestehende Rollen- und Rechtekonzept ein und stellt hierfür 3 Benutzer gruppen zur Verfügung. Der SAP Systemadministrator hat bei technischer Kenntnis des TDA deutliche Eingriffsmöglichkeiten. Seine Veränderungen werden durch das SAP System selbst protokolliert (z. B. Systemlog SM21).

Rolle Transaktionen Einschränkung

TDA Administrator/Superuser /NA2/DCS; /NA2/JOB; /NA2/TDA; SE80 Lesen und schreiben

TDA Standarduser /NA2/TDA Nur ausführen

Datenschutzbeauftragter, Revision, Auditor

/NA2/DCS; /NA2/TDA; SE80 Nur lesen

Benutzer Rolle Profil Berechtigung Objekt

Benutzer 1

TDA Super

Rolle 1

R_TDA_1

Profil 1

TDA_1

Berechtigung 1

Transaktion/NA2/TDA

Job Steuerung/NA2/JOB

Customizing/NA2/DCS

Objekt 1

Ändern

Benutzer 2

TDA Anwender

Rolle 2

R_TDA_2

Profil 2

TDA_1

Profil 3

TDA_2

Berechtigung 2 Objekt 2

Ändern

Berechtigung 2 Objekt 3

Ändern

Abbildung 1: Berechtigungskonzept

4.3.4 Weitergabekontrolle

Anforderung:Bei der elektronischen Verarbeitung von vertraulichen Informationen oder personenbezogener Daten sind generell Maßnahmen zur Verschlüsselung, sowohl bei der Übertragung als auch beim Zwischenspeichern, vorzusehen. Eine Verschlüsslung sichert die Vertraulichkeit und die Integrität der übertragenen Daten zu. Hierzu ist ein anerkanntes Verschlüsselungsverfahren zu verwenden. Es ist sicherzustellen, dass die zur Entschlüsselung benötigten Parameter (z. B. Schlüssel) in der Weise geschützt sind, dass kein Unbefugter Zugang zu diesen Daten besitzt (z. B. mit einer TLS-Verschlüsselung).

Daten mit eindeutigem Bezug sind Daten, die ohne jede weitere Zusatzinformation auf eine natürliche Person zurückzuführen sind. Dies kann z. B. die IBAN-Nummer, die Steuer-Identifikationsnummer oder die Sozial-versicherungs nummer sein. Eine einfache Verwürfelung der Adressdaten würde nicht genügen. Das Datum muss auch in sich verändert werden.

Umsetzung:Das TDA erzeugt selbst keine Schnittstellen zur Übertragung von Daten, deshalb ist darauf zu achten, dass die Schnittstellen der eigenen Infrastruktur die konzeptionellen Anforderungen zum datenschutzkonformen Betrieb selbst einhalten.

Das TDA bietet mehrere Möglichkeiten zur Lösung dieser Anonymisierungsaufgabe:• Ersetzung mit einem Festwert• Synthetisieren durch einen vorgegebenen Algorithmus• Ersetzung aus einem mitgelieferten Testdatenpool, z. B. IBAN-Nummer• Ersetzung aus Adressdaten von nicht natürlichen Personen

Die Methode muss zum Testablauf passen, da es sonst vorkommen kann, dass Testabläufe nicht durchlaufen, weil die Daten, z. B. durch Prüfsummenermittlung nicht akzeptiert werden.

Der Hashcache eines Anonymisierungsprojektes wird mit SHA-256 Bit verschlüsselt und ist damit, selbst mit weitgehenden Administrationsrechten, nicht lesbar. Der Schutz der Schlüssel im SAP System muss durch die SAP Infrastruktur selbst sichergestellt sein.

4.3.5 Eingabekontrolle

Anforderung:Das TDA muss Funktionen zur Beweissicherung, unter Berücksichtigung der betrieblichen und datenschutz-rechtlichen Anforderungen des Unternehmens, bereitstellen. Dabei ist darauf zu achten, dass die Funktionalität eine Verwendbarkeit vor Gericht nicht ausschließt und eine lückenlose Beweissicherung ermöglicht wird. Hierbei müssen sowohl sicherheitskritische Aktionen der Administratoren (Import von Daten, Vergabe von Zugriffsrechten, etc.) als auch der Benutzer (z. B. Ausdruck vertraulicher Informationen) betrachtet werden. Sicherheitskritische Aktionen müssen revisionssicher protokolliert und die dabei anfallenden Protokolldateien in geschützter Form hinterlegt werden, sodass nachträgliche Manipulationen nicht möglich sind.

Umsetzung:Das Protokoll der TDA Anonymisierung dokumentiert die Anzahl der anonymisierten Geschäftspartner sowie die Anzahl der geänderten Adress- und Bankverbindungen. Für eine detailliertere Auskunft steht das Logging im DCS zur Verfügung. Auf Projektebene wird über die Reiter Schlüsselübersicht und Tabellenlog für einen Anonymisierungslauf genau ausgegeben, wie viele Schlüssel typisiert wurden, wann die jeweiligen Tasks liefen und wie viele Datensätze pro Tabelle gelesen und verändert wurden.

9


10

Auf der Startseite des TDA Laufes im DCS werden der Benutzer und das Datum angezeigt, der diesen TDA Lauf angelegt hat. Hier als Beispiel vom Benutzer WINTEMA am 28.07.2015:

Abbildung 2: Projektübersicht

In der Schlüsselübersicht ist ersichtlich, wie viele Daten verändert wurden:

Abbildung 3: Schlüsselübersicht

11

Im Tabellenlogging ist verzeichnet, wie viele Datensätze pro Tabelle verändert wurden:

Abbildung 4: Quantitatives Tabellenlog

Im DCS wird des Weiteren detailliert Auskunft darüber gegeben, wann ein Anonymisierungslauf gestartet wurde und von welchem Benutzer:

Abbildung 5: Logging Detailinformation 1

12


Abbildung 6: Logging Detailinformation 2

Zusätzlich wird geloggt, wann welche Tabellen gelesen, bearbeitet und geschrieben wurden. Was sich hinter der jeweiligen Task-Nummer verbirgt, ist im DCS sichtbar:

Abbildung 7: Laufzeiten der einzelnen Veränderungen

Ein Logging auf Datensatzebene, also eine Änderungshistorie, in welchem Tabellenfeld welcher alte Wert auf welchen neuen Wert geändert wurde, wird explizit nicht weggeschrieben. Dies würde dem Grundsatz des BDSG widersprechen, da somit eine Rückverfolgung gegeben wäre. Sämtliche hier genannten Log-Informationen können über das TDA (und auch über das DCS) nicht gelöscht oder verändert werden.

13

4.3.6 Auftragskontrolle

Anforderung:Es muss gewährleistet werden, dass personenbezogene Daten, die im Auftrag verarbeitet werden, gemäß den Weisungen des Unternehmens verarbeitet werden.

Umsetzung:Auch diese Anforderung muss nicht durch die Applikation selbst erbracht werden, sondern ist eine Anforderung an Unternehmen generell. Unternehmen müssen dafür sorgen, falls Serviceleistungen von externen Unter-nehmen erbracht werden, dass die nötigen datenschutzrechtlichen Ergänzungsverträge mit dem Dienstleister abgeschlossen wurden (Auftragsdatenverarbeitungsvertrag gemäß § 11 BDSG).

4.3.7 Verfügbarkeitskontrolle

Anforderung:Eine weitere Anforderung ist die Verfügbarkeit von personenbezogenen Daten. Personenbezogene Daten müssen gegen zufällige Zerstörung oder Verlust geschützt werden.

Umsetzung:Die Verfügbarkeitskontrolle ist wiederum eine Anforderung an eine Organisation und wird nicht von der Applikation verlangt.

4.3.8 Trennungsgebot

Anforderung:Bei der Erhebung von personenbezogenen Daten ist sicherzustellen, dass Daten, die zu unterschiedlichen Zwecken erhoben wurden auch getrennt verarbeitet werden (z. B. Produktivsystem und Testsystem).

Umsetzung:Genau bei dieser Anforderung kann das TDA helfen, da ein Personenbezug im Testsystem mit Hilfe der Applikation nun nicht mehr möglich ist.

5. Zusätzliche Funktionen des TDA

5.1 Eingabemaske

Anforderung:Für die Ausgestaltung einer Eingabemaske gibt es keine besondere Anforderung aus dem BDSG. Dennoch ist die Eingabemaske logisch und benutzerfreundlich zu gestalten, um Fehleingaben zu vermeiden.

Umsetzung:Folgende zwei Möglichkeiten der Anonymisierung stehen dem Nutzer zur Verfügung:

One-Click-Anonymisierung:Die Transaktion /NA2/ONE_CLICK_ANO startet das Programm zur Generierung eines Anonymisierungs-projektes. Sie ist sowohl für DCS Experten als auch für Keyuser aus den Fachbereichen gedacht.

Anonymisierungslauf:• Auswahl von Geschäftspartnern zur Anonymisierung• Projekt im Vordergrund ausführen für einzelne Geschäftspartner• Projekt im Hintergrund ausführen für Massenläufe

14


Abbildung 8: Standard-Selektionsbild für die One-Click-Anonymisierung

Expertenmodus:Der Expertenmodus wird nur bei der Installation des TDA gebraucht und genutzt. Nach der Installation kann diese Maske über eine Berechtigung wieder abgeschaltet werden. Die Abschaltung des Expertenmodus ist insbesondere deswegen wichtig, da für Testzwecke die Löschung des Hashcache unterdrückt ist.

Abbildung 9: TDA Expertenmodus (Shift + F2 )

15

5.2 Schutz von Projekten

Innerhalb des DCS werden alle Änderungen an einem Projekt (Customizing) erfasst und gespeichert. Diese Änderungen können jederzeit über das Datenmodell sowie über die Oberfläche eingesehen werden. Darüber hinaus kann ein Projekt, z. B. Anonymisierung Master für HR, mit einem Passwort geschützt werden:

Abbildung 10: DCS Projektmaske

5.3 Weiterentwicklungen und Updates

Release:Das TDA wird in einem halbjährlichen Release-Zyklus verbessert und aktualisiert.

Kompatibilität:

Unterstützende Basis

Mindestens ERP ECC 7.0 EHP 1 (aufwärtskompatibel)

Sonderrelease für SAP ERP 4.7 auf Anfrage möglich

16


6. Bewertung

6.1 Datenschutz

Die folgenden datenschutzrechtlichen Anforderungen können mit der Anwendung umgesetzt werden:

Anforderung Datenschutz

1. Datenschutzrechtliche Ermächtigungsgrundlage Damit personenbezogene Daten in einem Testsystem verarbeitet werden können, benötigt man eine Ermächtigungsgrundlage. Diese Ermächtigungsgrundlage (explizite Einwilligung) ist in der Praxis nur schwer zu erhalten. Die Applikation erleichtert diese Anforderung, indem sie die Anwendung des Datenschutzes mit der Pseudonymisierung unterbricht.

2. Datensparsamkeit Die Verarbeitung personenbezogener Daten ist von dem Grundsatz geprägt, so wenig Daten wie möglich zu verarbeiten. Die Applikation kann diese Anforderung von Unter-nehmen erfüllen, indem sie personenbezogene Daten pseudonymisiert.

3. Transparenz Die Applikation einschließlich ihrer Komponenten ist klar und verständlich angelegt und ermöglicht es dem Kunden bei Bedarf, dem Betroffenen und Aufsichtsbehörden zu erläutern, dass in Testsystemen keine datenschutzwidrigen Daten vorhanden sind.

4. Zweckbindungsgrundsatz Der Zweckbindungsgrundsatz der personenbezogenen Daten wird nicht verletzt, da in Testsystemen nur pseudonymisierte Daten vorhanden sind.

5. Erforderlichkeitsgrundsatz Der Erforderlichkeitsgrundsatz ist gewahrt, wenn die Art und Qualität der Datenverar-beitung in einem angemessenen Verhältnis zum Zweck des Schutzes der IT-Infrastruktur des Unternehmens steht. Dies ist der Fall.

6. Audit und Protokollierung Eine Protokollierung, Auswertung und Bewertung der verarbeiteten Daten zum Zwecke der (internen) Revision ist gegeben.

17

6.2 Datensicherheit

Die Anforderungen an die Datensicherheit in Bezug auf die Verarbeitung von personenbezogenen Daten wurden anhand folgender Kriterien geprüft:

Anforderung Datensicherheit

1. Unbefugten den Zutritt zu Datenverarbeitungsanlagen, mit denen personenbezogene Daten verarbeitet oder genutzt werden, zu verwehren (Zutrittskontrolle) – ist vom Nutzer umzusetzen.

2. Es ist zu verhindern, dass Datenverarbeitungssysteme von Unbefugten genutzt werden können (Zugangskontrolle) – ist vom Nutzer umzusetzen, die Applikation kann nur Hilfestellung hierzu leisten.

3. Das TDA gewährleistet, dass die zur Benutzung des Systems Berechtigten ausschließlich auf die ihrer Zugriffsberechtigung unterliegenden Daten zugreifen und, dass personen-bezogene Daten bei der Verarbeitung, Nutzung und nach der Speicherung nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können (Zugriffskontrolle).

4. Das TDA erzeugt selbst keine Schnittstellen zur Übertragung von Daten, deshalb ist darauf zu achten, dass die Schnittstellen im eigenen System immer verschlüsselt erfolgen. Der Hashcache des TDA wird jedoch mit SHA-256 Bit verschlüsselt (Weitergabekontrolle).

5. Das TDA gewährleistet, dass nachträglich überprüft und festgestellt werden kann, ob und von wem personenbezogene Daten in Datenverarbeitungssysteme eingegeben, verändert oder entfernt worden sind (Eingabekontrolle).

6. Es ist zu gewährleisten, dass personenbezogene Daten, die im Auftrag verarbeitet werden, nur entsprechend den Weisungen des Auftraggebers verarbeitet werden können (Auftragskontrolle) – ist vom Nutzer umzusetzen.

7. Es ist zu gewährleisten, dass personenbezogene Daten gegen zufällige Zerstörung oder Verlust geschützt sind (Verfügbarkeitskontrolle) – ist vom Nutzer umzusetzen.

8. Das TDA gewährleistet, dass zu unterschiedlichen Zwecken erhobene Daten getrennt verarbeitet werden können (Trennungskontrolle).

18


7. Fazit

Die beschriebene Applikation der NATUVION GmbH – Test Data Anonymization (TDA) hilft bei der Umsetzung datenschutzrechtlicher Anforderungen. Die NATUVION GmbH hat zudem umfangreiche Maßnahmen im Bereich der Datensicherheit ergriffen.

Zusammenfassend kann daher festgestellt werden, dass IT-Entscheidern in SAP IT-Landschaften, in denen mit personenbezogenen Daten in Testsystemen gearbeitet werden muss, empfohlen wird, sich mit dem Test Data Anonymization (TDA) der NATUVION GmbH zu befassen, um datenschutzrechtlichen Anforderungen zu entsprechen.

8. Nachweis der Compliance-Festigkeit

Wer Wert darauf legt, die beschriebene Software in seine Organisation einzubinden, dem wird als Vorgehens-weise das T/O/R®-Prinzip empfohlen.Diese Orientierung nach Technik, Organisation und Recht stellt eine Abdeckung des gesamten Unternehmens-bereiches sicher. Somit ist eine umfassende Behandlung des Themas Compliance gewährleistet.

„Compliance-Festigkeit“ wird somit durch folgendes Vorgehen erreicht:• Angemessene und bezahlbare Technologie• Gesicherte Integration in die Organisation• Unbedenklichkeitserklärung zur Rechtslage

Die Praxis hat gezeigt, dass eine hauseigene Beschreibung des Vorgehens vielfach für die Wirtschaftsprüfer nicht ausreicht. Begründung: Eine solche Beschreibung informiert weder über die Qualität der Maßnahmen, noch kann nachvollzogen werden, wie der Verfasser seine Stellungnahme begründet hat. In solchen Fällen empfiehlt sich die Durchführung eines speziellen Datenschutz-Compliance Audits durch einen unabhängigen Dritten, der die drei T/O/R® Dimensionen im Hinblick auf die beschriebenen Applikationen durchdrungen hat und die Datenschutzkonformität durch ein belastbares Testat bestätigt.

Im Falle einer datenschutzrechtlichen Überprüfung steht dem Auftraggeber auch nach Abschluss der Prüfung eine unentgeltliche Datenschutzhotline zur Test Data Anonymization (TDA) Software zur Verfügung.

19

9. Kontakt / Autor

PRW Consulting GmbHLeonrodstraße 54 D-80636 MünchenTelefon: +49 89 210977-70Telefax: +49 89 210977-77E-Mail: [email protected]: www.prw-consulting.de

Rechtsanwalt Wilfried Reiners, MBAStudium der Rechts- und Wirtschaftswissenschaften in München und San Diego (MBA).Nach einer mehrjährigen Tätigkeit für eine internationale Unternehmensberatung ist er seit 1989 zur Anwalt-schaft zugelassen. Wilfried Reiners ist heute Managing Partner von PRW Rechtsanwälte in München und Geschäftsführer der PRW Consulting GmbH. RA Reiners ist auf die Beratung im IT-Umfeld spezialisiert und hat zahlreiche Veröffentlichungen zum Recht in der IT publiziert.

mailto:[email protected]://www.prw-consulting.de

Whitepaper: Datenschutzkonformität von SAP Testsystemen. Stand November 2015

PRW Consulting GmbHLeonrodstraße 54 D-80636 MünchenTelefon: +49 89 210977-70Telefax: +49 89 210977-77E-Mail: [email protected]: www.prw-consulting.de

mailto:[email protected]://www.prw-consulting.de

allabout compliance · 2020. 2. 4. · grundlagen der prüfung ... und wurde auf einem...

Documents