Leitfaden Datenschutz SAP ERP - DSAG · Leitfaden Datenschutz Stand Autor Seite für SAP-ERP 31.12.2013 AG Datenschutz 3 Einleitung Der vorliegende Leitfaden Datenschutz SAP ERP soll

DSAG Arbeitskreis Revision

DSAG Arbeitsgruppe Datenschutz

Leitfaden Datenschutz

SAP ERP

Stand 31. Dezember 2013

http://www.sap.de/revis

SAP® AG Dietmar-Hopp-Allee 16 D-69190 Walldorf

Änderungen und Ergänzungen vorbehalten

Leitfaden Datenschutz Stand Autor Seite

für SAP-ERP 31.12.2013 AG Datenschutz 2

IN MEMORIAM

THOMAS BARTHEL

(1950 – 2007)



Einleitung

Der vorliegende Leitfaden Datenschutz SAP ERP soll Datenschutzbeauftragten der SAP-

Anwender Anhaltspunkte für die Vorgehensweise bei der Umsetzung der Anforderungen der

Datenschutzvorschriften bei Einsatz der SAP-Software geben.

Der Leitfaden ist als "Empfehlung" gedacht, nicht aber als "Verbindliche Richtlinie" oder

"Norm". Jegliche Verantwortung für Art, Umfang und Ergebnis der Umsetzung der Daten-

schutzvorschriften verbleibt somit bei der Leitung der verantwortlichen Stelle (Unterneh-

men/Behörde).

Für das Studium dieses Leitfadens werden Grundkenntnisse der SAP-Systeme sowie Kennt-

nisse der handels- und steuerrechtlichen Grundlagen1 und des Bundesdatenschutzgesetzes

(BDSG) vorausgesetzt. Der Leitfaden Datenschutz behandelt Fragestellungen, die bereits in

den SAP Sicherheitsleitfäden oder in anderen Prüfleitfäden des DSAG AK-Revision enthalten

sind, insbesondere aus datenschutzrechtlicher Sicht. In dieser Version wird z.T. auch auf mo-

dulspezifische Besonderheiten, z.B. HCM eingegangen.

Mit SAP ERP wird die klassische ABAP-Welt (ABAP Stack) um die JAVA-Welt (JAVA

Stack) ergänzt. Dieser Leitfaden bezieht sich auf den ABAP-Stack, eine Behandlung der

technisch organisatorischen Maßnahmen und Kontrollen für den JAVA-Stack ist nicht Ge-

genstand dieses Leitfadens.

SAP ERP ist als international eingesetzte Standardsoftware konzipiert. Der Leitfaden berück-

sichtigt die EU Richtlinie 95/46/EG und die deutsche Datenschutzgesetzgebung.

Die Autoren sind Mitglieder der Arbeitsgruppe DATENSCHUTZ im DSAG Arbeitskreis Re-

vision und stellen hiermit ihre Erfahrungen zur Verfügung.

© Copyright 2013 der Autoren:

Herr I. Carlberg FORBIT GmbH., Hamburg

Herr G. Hübner SAP AG, Walldorf

Herr V. Lehnert SAP AG, Walldorf

Frau A. Lichter SAP AG, Walldorf

Herr T. Müthlein GDD e.V. Bonn / DMC Datenschutz Management & Consulting

GmbH & CoKG, Frechen

Frau A. Otto SAP Deutschland AG & CoKG

Herr S. Pieper Kivala-HR Deutschland GmbH

Herr C. Radick K+S IT Services GmbH

Herr K. Redling SAP Deutschland AG & CoKG

Herr A. Reschke Rechtsanwaltskanzlei Reschke, Wiesbaden

Herr T. Rosinsky Robert Bosch GmbH, Stuttgart

Herr P. Schiefer Bayer AG, Leverkusen

Herr H.-J. Schwab SAP AG, Walldorf

1 Z.B. HGB, AO, GDPdU, GoB/GoBS



Herr G. Siebert Forba Partnerschaft, Berlin

Herr G. Voogd FORBIT GmbH/CArO GmbH, Hamburg

Frau Wellner RWE Service GmbH, Dortmund

Herr Dr. M. Wulf SAP AG, Walldorf

An der 1. bzw. 2. Auflage wirkten außerdem mit:

Herr V. Ahrend Bosch Telecom GmbH, Frankfurt

Herr R. Anhorn Robert Bosch GmbH, Stuttgart

Herr T. Barthel FORBIT GmbH/CArO GmbH, Hamburg

Frau C. Bonni Lausitzer Braunkohle AG, Senftenberg

Herr W. Kilian RWE Energie Aktiengesellschaft, Essen

Herr A. Lenz Rheinbraun AG, Köln

Herr S. Dierschke BASF AG-Zok, Ludwigshafen

Herr W. Geesmann KPMG Deutsche Treuhand-Gesellschaft, Düsseldorf

Herr R. Glagow PWC Deutsche Revision AG, Düsseldorf

Herr F. Glaß PWC Deutsche Revision AG, Düsseldorf

Herr T. Glauch KPMG Deutsche Treuhand-Gesellschaft, Düsseldorf

Herr J. Heck Brau und Brunnen AG, Dortmund

Herr G. Hohnhorst KPMG Deutsche Treuhand-Gesellschaft, Düsseldorf

Herr W. Hornberger SAP AG, Walldorf

Herr A. Kirk Ruhrgas AG, Essen

Herr K. Lorenz Deutsche Bausparkasse Badenia AG, Karlsruhe

Herr H. Miller Geberit Deutschland GmbH, Pfullendorf

Herr Dr. Pötschat BASF AG; Ludwigshafen

Herr E. Schmidt Philip Morris GmbH, München

Herr A. von der Stein RWE Systems AG, Dortmund

Herr U. Ueberschar Mannesmann Arcor AG & Co., Eschborn / Köln

Frau G. Zibulski SAP AG, Walldorf

Die Verantwortung für den Inhalt tragen die Autoren. Die redaktionelle Bearbeitung und das

Layout liegen bei der SAP AG und der DSAG.

Hinweis: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen

Grenzen des Urheberrechts ist ohne Zustimmung der Urheber unzulässig und strafbar. Das gilt insbesondere für Vervielfälti-

gungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.

Die Autoren des Leitfadens Datenschutz sind für Kritik, Änderungs- und Ergänzungswünsche dankbar. Dies gilt sowohl

für Vorschläge zur Vertiefung der einzelnen Kapitel als auch für die Nennung von Beispielen aus konkreten Prüfungserfah-

rungen.

Um dem Leser das Antworten zu erleichtern, ist auf der folgenden Seite ein Formular einge-

fügt.



An die Autoren der

Arbeitsgruppe Datenschutz FAX: +49 / 6227 / 358 0 959

DSAG Geschäftsstelle

Altrottstr. 34a

69190 Walldorf

Email: [email protected]

Absender: Name: ...........................................................................................

Funktion: ...........................................................................................

Abteilung: ...........................................................................................

Firma: ...........................................................................................

Anschrift: ...........................................................................................

...........................................................................................

Telefon: ................................... Fax: ............................................

Betr.: Ergänzende Information(en) zum Leitfaden Datenschutz SAP ERP

Ich möchte der Arbeitsgruppe zu folgendem Themenkreis Informationen geben (bitte ankreu-

zen):

( ) Kritische Tabellen/Customizing-Einstellungen

( ) Kritische Objekte

( ) Kritische SAP-Fakten

( ) Beispiele für konkrete Umsetzungsmaßnahmen und Prüfungshandlungen

Ich beziehe mich auf

Leitfaden Datenschutz SAP ERP, Kapitel: ................................................

SAP ERP, Release: ....................................................

Meine Information lautet:

....................................................................................................................................

....................................................................................................................................

....................................................................................................................................

....................................................................................................................................

....................................................................................................................................

....................................................................................................................................

....................................................................................................................................

....................................................................................................................................

.............................................................................................................................

Zur weiteren Erläuterung sind Anlagen beigefügt (bitte ankreuzen):

( ) Ja ( ) Nein

mailto:[email protected]



Inhaltsangabe

1 Einführungsprozess ............................................................................................. 10

1.1 Anforderungen des BDSG an SAP ERP ................................................................ 10

1.1.1 Erhebung, Verarbeitung, Nutzung und Löschung oder Sperrung von personenbezogenen Daten..................................................................................... 10

1.1.2 Übermittlung von personenbezogenen Daten ....................................................... 12

1.1.3 Abrufverfahren ...................................................................................................... 12

1.1.4 Besondere Zweckbindung ..................................................................................... 13

1.1.5 Auftragsverarbeitung ............................................................................................. 13

1.1.6 Unterrichtung des Betroffenen .............................................................................. 13

1.1.7 Rechte des Betroffenen ......................................................................................... 14

1.1.8 Auskunft an jedermann (externes Verfahrensverzeichnis) ................................... 14

1.1.9 Meldepflicht .......................................................................................................... 14

1.1.10 Informationspflicht bei Datenverlusten ................................................................. 15

1.1.11 Verpflichtung der Mitarbeiter auf das Datengeheimnis ........................................ 15

1.1.12 Schulung ................................................................................................................ 15

1.1.13 Maßnahmen zur Datensicherheit ........................................................................... 16

1.1.14 BDSG-Übersichten (Verzeichnis der Verarbeitung / internes Verfahrensverzeichnis) ......................................................................................... 16

1.1.15 Vorabkontrolle ...................................................................................................... 16

1.1.16 SAP Solution Manager als unterstützendes Tool im Einführungsprozess ............ 17

1.2 Mitwirken des Datenschutzbeauftragten bei der Einführung von SAP ERP ......... 17

1.2.1 Datenschutzbeauftragter - Mitglied des SAP-Projektteams .................................. 18

1.2.2 Information des Datenschutzbeauftragten zu den „Meilensteinen“ ...................... 18

1.2.3 Informationsmöglichkeiten für den Datenschutzbeauftragten .............................. 19

1.3 SAP-Fakten ............................................................................................................ 20

1.3.1 Customizing und ASAP-Vorgehensmodell .......................................................... 20

1.3.2 Berechtigungskonzept ........................................................................................... 21

1.3.3 Change Transport System/Change Transport Organizer (CTS/CTO) .................. 22

1.3.4 Schnittstellenverarbeitung ..................................................................................... 23

1.3.5 Job-Auftrags-Verfahren - und Dokumentation ..................................................... 24

1.4 Risiken ................................................................................................................... 25

1.4.1 Nichteinschaltung des Datenschutzbeauftragten bzw. der Arbeitnehmervertreter 25

1.4.2 Nichtbeachtung der SAP-Empfehlungen .............................................................. 25

1.4.3 Nichtberücksichtigung bzw. verspätete Erstellung des Berechtigungskonzeptes . 25

1.4.4 Nicht ordnungsgemäße Anwendung eines Datenverarbeitungsprogramms ......... 26

1.5 Prüfungshandlungen im Rahmen der Einführung / Checkliste ............................. 26



2 Aufgaben des Datenschutzbeauftragten ............................................................ 29

2.1 Überwachung der ordnungsgemäßen Programmanwendung (§ 4g Abs. 1

BDSG) .................................................................................................................... 31

2.1.1 Einbeziehung des DSB vor und während der Programmentwicklung und -anpassung .............................................................................................................. 31

2.1.2 Prüfung der Datenerhebung und Datennutzung auf Rechtmäßigkeit .................... 31

2.1.3 Auswertung der Protokollierung ........................................................................... 32

2.1.4 Prüfung der Verfahrensdokumentation ................................................................. 32

2.1.5 Mitwirkung bei der Festlegung und Überprüfung des Berechtigungskonzeptes .. 33

2.1.6 Mitwirkung bei der Festlegung des Betriebskonzeptes und der Betreiberorganisation ............................................................................................ 35

2.1.7 Abfassung einer Datenschutzerklärung ................................................................. 36

2.1.8 Überwachung des Korrektur- und Transportwesens unter SAP ERP ................... 36

2.1.9 Kontrollen im laufenden Betrieb ........................................................................... 37

2.2 Schulung der Anwender mit Verpflichtung auf das Datengeheimnis (§§ 4g

und 5 BDSG) .......................................................................................................... 37

2.2.1 Personenkreis, der geschult und verpflichtet werden muss ................................... 37

2.2.2 Inhalt der Anwenderschulungen ............................................................................ 38

2.2.3 Abbildung der Anwenderschulung im SAP .......................................................... 38

2.3 Führen von Übersichten (§ 4g Abs. 2 / § 18 Abs. 2 BDSG) .................................. 39

2.3.1 Verantwortlichkeiten ............................................................................................. 40

2.3.2 Form der Dokumentation ...................................................................................... 41

2.3.3 Das öffentliche Melderegister ............................................................................... 42

2.3.4 Das betriebsinterne Verfahrensverzeichnis ........................................................... 42

2.3.5 Beispiel Melderegister ........................................................................................... 58

2.4 Systemunterstützung .............................................................................................. 60

2.4.1 Auswertungen zur Tabellen- und Feldanalyse ...................................................... 61

2.4.2 Techniken zum Auffinden personenbezogener Daten .......................................... 63

2.4.3 Prüfung der Zugriffsberechtigungen ..................................................................... 65

3 Rechte der Betroffenen und von jedermann ..................................................... 68

3.1 Benachrichtigung und Auskunft ............................................................................. 69

3.1.1 Rechtliche Anforderungen .................................................................................... 69

3.1.2 SAP-Fakten ........................................................................................................... 69

3.1.3 Anforderungen an die Organisation des Datenschutzes ........................................ 70

3.2 Berichtigung, Löschung und Sperrung .................................................................. 72

3.2.1 Rechtliche Anforderungen .................................................................................... 72

3.2.2 SAP-Fakten ........................................................................................................... 73



3.2.3 Anforderungen an die Organisation des Datenschutzes ........................................ 74

4 Umsetzung der Anforderungen aus § 9 BDSG und Anlage: Technisch-organisatorische Maßnahmen ............................................................................ 76

4.1 Anforderungen ....................................................................................................... 76

4.1.1 Gesetzliche Anforderungen aus § 9 BDSG ........................................................... 76

4.1.2 SAP-Funktionalität zur Abdeckung der gesetzlichen Anforderungen .................. 77

4.2 SAP-Fakten, Risiken und Maßnahmen .................................................................. 82

4.2.1 ABAP-Fakten, Risiken und Maßnahmen .............................................................. 83

4.3 Zusammenfassung der Prüfungshandlungen ....................................................... 115

4.3.1 Anforderungen an die Prüfbarkeit ....................................................................... 116

4.3.2 Prüfung spezieller Regelungen aus vorrangigen Rechtsvorschriften (z.B. aus geltenden Betriebsvereinbarungen zu organisatorisch-technischen Maßnahmen) ............................................................................................................................. 125

4.3.3 Prüfung der Datenschutzmaßnahmen gemäß § 9 BDSG und der Anlage ........... 125

5 Auftragsdatenverarbeitung und konzerninterner Datenaustausch .............. 136

5.1 Abgrenzungen beim Thema Outsourcing und Datenschutz ................................. 136

5.2 Vertragsgestaltung zwischen Auftragnehmer und Auftraggeber ......................... 138

5.2.1 Pflichten des Auftraggebers und Auftragnehmers .............................................. 139

5.2.2 Umfang der Datenverarbeitung / Weisungen ...................................................... 139

5.2.3 Wer erteilt die Weisungen von Seiten des Auftraggebers und an wen sind die Weisungen beim Dienstleister zu richten, in welcher Form erfolgen die Technische und organisatorische Maßnahmen ................................................... 141

5.2.4 Wahrung der Rechte der Betroffenen .................................................................. 142

5.2.5 Pflichten des Auftragnehmers nach § 11 Abs. 4 BDSG, insbesondere die von ihm vorzunehmenden Kontrollen ............................................................................... 142

5.2.6 Kontrollen durch den Auftraggeber .................................................................... 143

5.2.7 Unterauftragnehmer ............................................................................................ 144

5.2.8 Mitzuteilende Verstöße des Auftragnehmers ...................................................... 145

5.2.9 Rückgabe überlassener Datenträger .................................................................... 145

5.2.10 Verarbeitung im Ausland .................................................................................... 146

5.2.11 Wartung und Pflege ............................................................................................. 148

5.3 SAP-Fakten .......................................................................................................... 149

5.3.1 Ausgangssituation ............................................................................................... 149

5.3.2 SAP-Administration ............................................................................................ 150

5.3.3 SAP-spezifische Maßnahmen ............................................................................. 150

5.4 Risiken ................................................................................................................. 153

6 Besondere Themen ............................................................................................ 155

6.1 Datenschutzkonformes Löschen mit dem SAP NetWeaver Information



Lifecycle Management (ILM) .............................................................................. 155

6.1.1 Datenschutzkonformes Löschen in der Personalwirtschaft (SAP HCM) ........... 155

6.2 Read Access Logging ........................................................................................... 158

6.3 Auditwerkzeuge: Audit Information System und Benutzerinformationssystem ... 159

6.3.1 Audit Information System (AIS) ......................................................................... 159

6.3.2 Benutzerinformationssystem (SUIM) ................................................................. 161

6.4 SOS-Report ( Security Optimization Service ) ..................................................... 162

6.5 SAP GRC (Governance, Risk and Compliance) .................................................. 162

6.5.1 SAP GRC Access Control ................................................................................... 163

6.5.2 SAP GRC Process Control .................................................................................. 165

6.6 SAP TDMS (Test Data Migration Server) ........................................................... 166

7 Glossar ................................................................................................................ 168



1 Einführungsprozess

Die Voraussetzung für die Anwendung des Bundesdatenschutzgesetzes (BDSG) ist beim Ein-

satz von SAP ERP2 erfüllt, da in allen Modulen personenbezogene Daten automatisiert verar-

beitet werden (vgl. § 1 BDSG in Verbindung mit §§ 12 oder 27 BDSG). Deshalb sind das

Bundesdatenschutzgesetz und andere Rechtsvorschriften zum Datenschutz, z.B. in einer Lan-

desverwaltung das jeweilige Landesdatenschutzgesetz zu beachten. Dieser Leitfaden gilt für

den öffentlichen und den nicht-öffentlichen Bereich. Auf die Besonderheiten der Landesda-

tenschutzgesetze wird in diesem Leitfaden nicht eingegangen.

Da SAP ERP als international eingesetzte Standardsoftware unter betriebswirtschaftlichen

Aspekten konzipiert ist, kann ein anwendendes Unternehmen nicht ohne weiteres davon aus-

gehen, dass für alle angebotenen Datenfelder die Rechtsgrundlagen im Sinne der deutschen

Datenschutzvorschriften gegeben sind.

Es ergibt sich damit die Notwendigkeit für die verantwortliche Stelle (anwendendes Unter-

nehmen) zu überprüfen, ob SAP ERP in der bei ihr vorgesehenen Ausprägung den Anforde-

rungen des Bundesdatenschutzgesetzes und ggf. anderer Vorschriften über den Datenschutz

genügt.

Der Datenschutzbeauftragte (DSB) in seiner Hinwirkungfunktion als auch gegebenenfalls in

seiner Vorabkontrollfunktion sowie Betriebsrat/Personalrat sind daher in die Projektarbeit

einzubeziehen, wobei die Projektverantwortung für die ordnungsgemäße Einführung von SAP

ERP der Projektleitung obliegt.

Auch wenn das BDSG den Anforderungen des harmonisierten Datenschutzrechts in der EU

entspricht, sind die lokalen Besonderheiten der einzelnen EU-Mitgliedsstaaten in Rahmen der

Länder-Rollouts im Rahmen der Projektarbeit in Verantwortung der Projektleitung zu prüfen

und zu beachten.

1.1 Anforderungen des BDSG an SAP ERP

Das BDSG spricht ein grundsätzliches Verbot der Erhebung, Verarbeitung und Nutzung per-

sonenbezogener Daten aus und erlaubt die Datenverarbeitung nur, wenn die im BDSG defi-

nierten Voraussetzungen erfüllt sind. Dieser Grundsatz führt dazu, dass mit der Einführung

des SAP ERP überprüft werden muss, ob die Anforderungen des BDSG und anderer Rechts-

vorschriften angemessen berücksichtigt wurden. Entsprechendes gilt auch für Änderungen im

laufenden Betrieb.

1.1.1 Erhebung, Verarbeitung, Nutzung und Löschung oder Sperrung

von personenbezogenen Daten

Grundsätzlich ist die Erhebung, Verarbeitung oder Nutzung von personenbezogenen Daten

gemäß § 4 BDSG verboten (Erlaubnisvorbehaltsprinzip), es sei denn,

das BDSG erlaubt bzw. verlangt die Verarbeitung oder

2 Im Folgenden umfasst der Begriff SAP ERP im Sinne dieses Leitfadens auch die ABAP-

Komponenten von SAP NetWeaver



eine andere vorrangige Rechtsvorschrift erlaubt bzw. verlangt die Verarbeitung oder

es liegt eine schriftliche Einwilligung des Betroffenen vor (basierend auf der freien Ent-

scheidung des Betroffenen § 4a BDSG)3.

Die Zulässigkeitskriterien für die Erhebung, Verarbeitung oder Nutzung ergeben sich aus § 4

BDSG in Verbindung mit

§§ 13 und 14 BDSG für die öffentlichen Stellen

§§ 28 bis 32 BDSG für nicht-öffentliche Stellen.

Die Beweislast für die Zulässigkeit trägt die verantwortliche Stelle (das/ die einführende(n)

Unternehmen).4

Der Grundsatz der Datenvermeidung und Datensparsamkeit gem. § 3a BDSG mit dem Ziel,

keine oder so wenig personenbezogene Daten wie möglich zu erheben, zu verarbeiten oder zu

nutzen, ist zu beachten.

Die Rechtsgrundlagen für die Erhebung, Verarbeitung und Nutzung sind im BDSG dif-

ferenziert gestaltet und müssen geprüft bzw. geschaffen werden (z.B. gesetzliche Grund-

lage, Vertrag (etwa Arbeitsvertrag, Betriebsvereinbarung, ...), freiwillige, schriftliche

Einwilligung oder Interessensabwägung).

Die organisatorischen und technischen Maßnahmen zur Nutzung von SAP ERP sind so zu

gestalten, dass nur die erforderlichen personenbezogenen Daten gespeichert und verar-

beitet werden. Dabei ist zu beachten, dass im Auslieferungszustand der Software techni-

sche Maßnahmen nur im geringen Umfang ausgeprägt sind und die organisatorischen

Maßnahmen definiert werden müssen und umzusetzen sind.

Abhängig vom Zweck der Verarbeitung ist mit den Möglichkeiten des Berechtigungskon-

zeptes und anderer Sicherungsmaßnahmen sicherzustellen, dass die Daten nur im Rah-

men der zulässigen Zwecke verarbeitet werden können. Besonderes Augenmerk ist dabei

auch auf das Berechtigungskonzept zu legen, da auch Anzeige-, Download- oder Export-

rechte eine Zweckänderung bedingen können. Für unterschiedliche Zwecke erhobene Da-

ten müssen durch technisch-organisatorische Maßnahmen getrennt verarbeitet werden

können.

Es dürfen nur die Daten vorgehalten werden, die zur Erfüllung der Aufgabenstellung er-

forderlich sind (Verbot der Vorratsdatenspeicherung).

Abhängig vom Zweck der Datenspeicherung (z.B. Abwicklung eines Vertrages) sind die

benötigten Datenfelder festzulegen und im Customizing einzustellen.

Zusätzlich ist die Dauer der Datenspeicherung auf die dem Nutzungszweck entspre-

chende Zeit zu begrenzen, entsprechend festzulegen und für die Löschung der Daten (sie-

he unten 6.1), oder die Sperrung gem. § 35 BDSG zu sorgen (z.B. von Bewerberdaten

oder Festlegung der Speicherungsdauer nach dem Vertragsende und anschließende Lö-

schung). Dabei ist zwischen dem operativen Zweck und weiteren Zwecken (wie gesetzli-

chen Aufbewahrungsfristen, Produkthaftung) zu unterscheiden. Sollten verschiedene

3 Einwilligung im Rahmen des Beschäftigungsverhältnisses sind kritisch zu prüfen, da die

Rechtskommentare die Anwendbarkeit grundsätzlich verneinen

4 Das BDSG kennt kein „Konzernprivileg“, jede beteiligte Rechtseinheit hat die Beweislast für die

Zulässigkeit zu tragen



Speicherdauern für operative und weitere Zwecke vorliegen sind die Daten nach Entfall

des operativen Zwecks zu sperren. Dies kann über eine Archivierung mit Beschränkung

der Zugriffsrechte geschehen. Eine Aufgliederung der Löschfristen je Personengruppe und

Datenkategorie ist anzustreben, genauso wie prozessuale Vorgaben zur routinemäßigen

Löschung (entsprechend Löschfrist) und adhoc Löschung (wie etwa bei Widerruf der

Einwilligung). Das Löschkonzept besteht dann aus der Übersicht der Löschfristen je Per-

sonengruppe und Datenkategorie, prozessualen Vorgaben zur Durchführung der Löschung

und Verantwortlichen für die Umsetzung und Durchführung der Löschung.5

1.1.2 Übermittlung von personenbezogenen Daten

Grundsätzlich ist die Übermittlung von personenbezogenen Daten verboten. Die Zulässig-

keitskriterien für Übermittlungen ergeben sich aus § 4 b BDSG in Verbindung mit den §§ 15,

16 BDSG für öffentliche Stellen, §§ 28, 28a, 29, 30, 32 BDSG für nicht-öffentliche Stellen.

Es ist sicherzustellen, dass die Zweckbindung der übermittelten Daten auch vom Empfänger

eingehalten wird. Hierzu ist der Empfänger auf die Zweckbindung hinzuweisen. Im Sinn des

BDSG ist auch eine Einsichtnahme/ das Lesen durch eine Person eine Übermittlung. (Auch

die technischen Funktionen zum Markieren, Ausschneiden und Einfügen, zur Bildschirmko-

pie, zum Download und zum Remote-Access (z.B. per TeamViewer oder über MS Lync) sind

unter dem Aspekt der Übermittlung zu betrachten, genauso der Wartungszugriff durch Dienst-

leister mit Sitz in Staaten, die nicht Mitgliedstaaten der Europäischen Union und nicht andere

Vertragsstaaten des Abkommens über den Europäischen Wirtschaftsraum sind. Gleiches gilt

für den sogenannten pdf-Drucker, da er einen eigenständigen Datenträger darstellt.

Das empfangende System muss den gleichen Datenschutzanforderungen genügen und eben-

falls den für den Datenschutz geltenden Vorgehensweisen und Meldeverfahren unterworfen

werden. Ob sich bei der Übermittlung eine Benachrichtigungspflicht des Betroffenen ergibt,

ist zu prüfen.

Daraus ergibt sich die Notwendigkeit, alle regelmäßigen oder anlassbezogenen Übermittlun-

gen auf ihre Rechtmäßigkeit zu prüfen. Insbesondere bei der Übermittlung von Daten der be-

sonderen Art an Staaten, die nicht Mitgliedstaaten der Europäischen Union und nicht andere

Vertragsstaaten des Abkommens über den Europäischen Wirtschaftsraum sind, spricht das

BDSG für übliche Zwecke im Firmenkontext ein Verbot aus.

1.1.3 Abrufverfahren

Ein Abrufverfahren darf nur eingerichtet werden, wenn die Voraussetzungen des § 10 BDSG

erfüllt sind.

Sollen personenbezogene Daten von Dritten abgerufen werden können, sind zusätzliche

Maßnahmen zur Sicherstellung der Rechtmäßigkeit des Abrufes und der Datensicher-

heit bei den beteiligten Stellen erforderlich.

5 DIN Deutsches Institut für Normung e.V. "Leitlinie zur Entwicklung eines Löschkonzepts mit

Ableitung von Löschfristen für personenbezogene Daten"

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Hilfsmittel/Extern/Leitlinie_z

ur_Entwicklung_eines_Loeschkonzepts.html

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Hilfsmittel/Extern/Leitlinie_zur_Entwicklung_eines_Loeschkonzepts.html

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Hilfsmittel/Extern/Leitlinie_zur_Entwicklung_eines_Loeschkonzepts.html



Insbesondere muss die verantwortliche Stelle gewährleisten, dass mittels geeigneter

Stichproben die Rechtmäßigkeit der Übermittlung personenbezogener Daten festgestellt

werden kann.

1.1.4 Besondere Zweckbindung

Werden zu Zwecken des Datenschutzes, der Datensicherung oder zur Sicherstellung eines

ordnungsgemäßen Betriebes personenbezogene Daten gespeichert (z.B. über UI-

Protokollierung (User-Interface Protokollierung), Logfiles wie System Log oder Security Au-

dit Log oder Accounting-Informationen), sieht das BDSG in § 31 eine besondere Zweckbin-

dung für diese Kontrollinformationen vor.

Es ist zu klären, welche Aufzeichnungen im SAP ERP hierzu gehören und welche Funkti-

onen / Stellen diese Informationen benötigen und die Kontrollfunktionen ausüben.

1.1.5 Auftragsverarbeitung

Werden personenbezogene Daten im Auftrag durch andere Stellen erhoben, verarbeitet oder

genutzt, ist der Auftraggeber für die Einhaltung des BDSG und anderer Vorschriften über den

Datenschutz gemäß § 11 BDSG verantwortlich und muss sicherstellen, dass vor Aufnahme

der Verarbeitung ein schriftlicher Vertrag mit den angemessenes Schutzmaßnahmen beim

Auftragnehmer vorliegt. Der Auftraggeber muss sich von der Einhaltung dieser vertraglich

vereinbarten technisch organisatorischen Maßnahmen beim Auftraggeber vor Beginn der

Überarbeitung sowie danach periodisch überzeugen. Als Hilfestellung kann der Datenschutz-

beauftragte den Auftraggeber auffordern eine Prozessbeschreibung für diesen regelmäßigen

Kontrollprozess inklusive Prüfhandlungen organisatorisch zu verankern.6

Die Einzelheiten und diesbezüglichen Besonderheiten finden sich im Kapitel 5.

Unter dem Aspekt des Cloud Computing oder auch Software as a Service (SaaS) ist beson-

derer Wert auf die Interoperabilitätsvorgaben im Rahmen des vertraglichen Vereinbarungen

und der Prüfbarkeit der Löschung zu legen.

1.1.6 Unterrichtung des Betroffenen

Der Betroffene ist über den Umgang mit seinen personenbezogenen Daten zu unterrichten,

bei der Verwendung der Adressdaten zur Scorewertberechnung ist gemäß § 28b BDSG die

Unterrichtung zu dokumentieren. Auf die Unterrichtung kann nur dann verzichtet werden,

wenn ihm die gesetzlich genannten Umstände bereits bekannt sind.

Grundsätzlich soll die Information bei der Datenerhebung beim Betroffenen erfolgen, z. B. im

Rahmen des Vertragsabschlusses.

Erfolgt die Datenerhebung nicht beim Betroffenen sondern bei einem Dritten, z. B. Übermitt-

lung durch ein Konzernunternehmen, ist er unter den Voraussetzungen des § 33 BDSG zu be-

nachrichtigen, wenn

6 Speicherfristen und Löschkonzept müssen auch mit eventuellen Auftragnehmern vor Auftragsbeginn

kommuniziert und umgesetzt sein



erstmalig personenbezogene Daten über ihn gespeichert bzw. übermittelt werden oder

von ihm bei öffentlichen Stellen Daten ohne seine Kenntnis gemäß § 19a BDSG erhoben

werden oder

bei nicht-öffentlichen Stellen gemäß § 33 BDSG erstmalig Daten über ihn gespeichert

bzw. übermittelt werden.

Falls demnach eine Benachrichtigung erforderlich wird, muss das Verfahren entsprechend

festgelegt werden.

1.1.7 Rechte des Betroffenen

Es dürfen nur zulässige und inhaltlich korrekte personenbezogene Daten gespeichert werden.

Entscheidungen, die für den Betroffenen eine rechtliche Folge nach sich ziehen oder ihn er-

heblich beeinträchtigen, dürfen nicht ausschließlich auf der Basis einer automatisierten Ver-

arbeitung getroffen werden.

Die Datenspeicherung soll für den Betroffenen transparent sein. Deshalb hat der Betroffene

ein Recht auf Auskunft sowie auf Berichtigung, Löschung, Sperrung und Widerspruch.

Die Anforderungen des § 6 BDSG in Verbindung mit §§ 19, 20, 28b, 34, 35 BDSG sind zu

beachten.

Die verantwortliche Stelle muss in der Lage sein, zur Auskunftserteilung alle personenbe-

zogenen Daten des Betroffenen zuverlässig zu ermitteln! Diese Anforderung korrespon-

diert mit der Anforderung zur Führung einer Übersicht gemäß § 4g Abs. 2 BDSG (Ver-

fahrensverzeichnis).

Eine automatisierte Einzelfallentscheidung, die für den Betroffenen eine rechtliche Folge

nach sich ziehen oder den Betroffenen erheblich beeinträchtigen, ist gem. § 6a BDSG nur

in bestimmten Ausnahmefällen zulässig. Werden diese Ausnahmefälle in Anspruch ge-

nommen, sind sie entsprechend zu dokumentieren.

Die Voraussetzungen, unter denen Sperrungen erforderlich werden, sind zu definieren. Die

Verwendung gesperrter Daten ist zu regeln.

Der Betroffene kann eine Zustimmung zur Verarbeitung seiner personenbezogenen Daten je-

derzeit widerrufen. Da die Zulässigkeit der Verarbeitung auf einer Zustimmung des Betroffe-

nen beruht und diese mit Widerruf entfallen ist, sind die Daten zu löschen (oder zu sperren).

1.1.8 Auskunft an jedermann (externes Verfahrensverzeichnis)

Gemäß § 4g Abs. 2 S. 2 BDSG hat der Datenschutzbeauftragte jedermann auf Antrag Einsicht

in das (externe) Verfahrensverzeichnis zu gewähren. Ist kein Datenschutzbeauftragter bestellt,

dann hat die Geschäftsleitung dies sicher zu stellen.

1.1.9 Meldepflicht

Unter den Voraussetzungen des § 4d BDSG sind automatisierte Verarbeitungen vor ihrer In-

betriebnahme der zuständigen Aufsichtsbehörde zu melden.

Die Meldepflicht entfällt gemäß § 4d Abs. 2 BDSG, wenn die verantwortliche Stelle einen

Beauftragten für den Datenschutz bestellt hat. Stattdessen sind diese Informationen dem



Datenschutzbeauftragten zur Führung des Verfahrensverzeichnisses zur Verfügung zu

stellen.

Sie entfällt auch gemäß § 4 d Abs. 3 BDSG, wenn personenbezogene Daten für eigene

Zwecke erhoben, verarbeitet oder genutzt werden, hierbei höchstens neun Personen mit

der Erhebung, Verarbeitung oder Nutzung der personenbezogenen Daten beschäftigt UND

entweder eine Einwilligung der Betroffenen vorliegt oder die Erhebung, Verarbeitung o-

der Nutzung der Zweckbestimmung eines Vertragsverhältnisses oder vertragsähnlichen

Vertrauensverhältnisses mit dem Betroffenen dient.

1.1.10 Informationspflicht bei Datenverlusten

Unter den Voraussetzungen des § 42a BDSG ergeben sich bei unrechtmäßiger Kenntniserlan-

gung bestimmter Kategorien personenbezogener Daten unterschiedliche Informationspflich-

ten gegenüber Aufsichtsbehörden und Betroffenen. Dies umfasst nicht nur die im SAP Sys-

tem gespeicherten Daten, sondern alle aus diesen Systemen extrahierten und auf andere Art

und Weise verarbeiteten Daten (z.B. Listen, Office-Dokumente, Mail Attachments). Zusätz-

lich zu den in § 3 Abs. 9 BDSG definierten besonderen Arten personenbezogener Daten –

beispielsweise Schwerbehinderung oder Religionszugehörigkeit – zählen dazu auch Angaben

zu Bank- und Kreditkartenkonten.

1.1.11 Verpflichtung der Mitarbeiter auf das Datengeheimnis

Das BDSG fordert, dass alle Personen, die mit personenbezogenen Daten umgehen7, auf das

Datengeheimnis gemäß § 5 BDSG zu verpflichten sind.

Die Verpflichtung auf das Datengeheimnis ist pro Mitarbeiter zu dokumentieren.

Es ist sicherzustellen, dass beauftragte Firmen, die bei der Einführung von SAP ERP hin-

zugezogen werden, ihre Mitarbeiter auf das Datengeheimnis verpflichtet haben.

1.1.12 Schulung

Der Datenschutzbeauftragte hat die Mitarbeiter gemäß § 4g Abs. 1 Nr. 2 BDSG mit dem

BDSG sowie anderen Vorschriften über den Datenschutz und über innerbetrieblichen Rege-

lungen, die sich aus dem Gesetz ergeben, vertraut zu machen.

Der Datenschutzbeauftragte hat die Projektmitglieder und Anwender, die an der Einfüh-

rung von SAP ERP beteiligt sind, mit den Anforderungen des BDSG vertraut zu machen.

Wesentliche Inhalte der Schulung sind neben der datenschutzkonformen Anwendung des

Verfahrens in SAP ERP auch die Sensibilisierung der Anwender auf Vertraulichkeit bei

der Verarbeitung von personenbezogenen Daten

o am Arbeitsplatz (Einsicht durch am Verfahren Unbeteiligte ist durch geeignete

Gestaltung des Arbeitsplatz, wie Platzierung des Monitors, zu verhindern)

7 Üblicherweise sind die zu verpflichtenden Personengruppen „Personal“, „Vertrieb“, „Marketing“,

„IT“, „Vorgesetzte“, „Sekretariat“



o auf mobilen Endgeräten (Einsicht durch am Verfahren Unbeteiligte ist durch ge-

eignete Auswahl des Arbeitsorts, der Schutz vor Einsicht bietet sicherzustellen)

o mittels Apps (Einsicht und Mitlesen durch am Verfahren Unbeteiligte ist durch

geeignete Auswahl des Arbeitsorts und des Übertragungswegs, der Schutz vor

Einsicht und Mithören bietet sicherzustellen).

Die durchgeführten Schulungen sind zu dokumentieren.

1.1.13 Maßnahmen zur Datensicherheit

Personenbezogene Daten dürfen nur erhoben, verarbeitet oder genutzt werden, wenn ange-

messene technische und organisatorische Maßnahmen zur Datensicherheit getroffen wurden.

Die Anforderungen der einzelnen Zielsetzungen ergeben sich aus § 9 BDSG und Anlage.

Es sind angemessene Maßnahmen zur Datensicherheit (wie Aktivierung der verschlüssel-

ten Übertragung – SNC Secure Network Communication) zu treffen und mit dem Daten-

schutzbeauftragten abzustimmen.

Gegebenenfalls kann zur Verbesserung des Datenschutzes und der Datensicherheit das in-

stallierte System einem IT-Sicherheitsaudit unterworfen werden.

1.1.14 BDSG-Übersichten (Verzeichnis der Verarbeitung / internes

Verfahrensverzeichnis)

Die öffentlichen Stellen entsprechend zweitem Abschnitt BDSG führen gemäß § 18 Abs. 2

BDSG ein Verzeichnis der eingesetzten Datenverarbeitungsanlagen und haben die Angaben

gemäß § 4e BDSG sowie die Rechtsgrundlagen der Verarbeitung schriftlich festzulegen. Die

verantwortlichen nicht-öffentlichen Stellen entsprechend drittem Abschnitt BDSG haben

dem Datenschutzbeauftragten gemäß § 4g Abs. 2 BDSG eine Übersicht über die in § 4e

BDSG genannten Angaben sowie die zugriffsberechtigten Personen zur Verfügung zu stellen.

Die Wege und Möglichkeiten, mit denen die erforderlichen Übersichten erstellt werden

können, sind festzulegen.

1.1.15 Vorabkontrolle

Unabhängig von der Verpflichtung der verantwortlichen Stelle, den Datenschutzbeauftragten

bei der Verfahrenseinführung /-änderung zu beteiligen, sind Verfahren automatisierter Verar-

beitung mit besonderen Risiken für die Rechte und Freiheiten der Betroffenen, insbesondere

die Verarbeitung besonderer Arten personenbezogener Daten gem. § 3 Abs. 9 BDSG

und/oder Daten zur Leistungs- und Verhaltenskontrolle, gemäß § 4d Abs. 5 BDSG unter den

dort genannten Voraussetzungen vor Beginn der Verarbeitung einer datenschutzrechtlichen

Prüfung zu unterwerfen. Zuständig für die Vorabkontrolle ist der Datenschutzbeauftragte. Ei-

ne schriftliche Dokumentation zur Vorabkontrolle ist zu empfehlen.



1.1.16 SAP Solution Manager als unterstützendes Tool im

Einführungsprozess

Der SAP Solution Manager ist die Service- und Supportplattform der SAP, die bei der Ein-

führung und Implementierung von SAP Projekten eine durchgängige Unterstützung bietet.

Sofern der Solution Manager genutzt wird, sollte der Datenschutzverantwortliche auf die da-

rin befindlichen Dokumente zur Beurteilung des Systems zurückgreifen8.

1.2 Mitwirken des Datenschutzbeauftragten bei der Einführung von SAP ERP

Das BDSG verlangt in § 4g Abs. 1 S. 4 Nr. 1 BDSG die rechtzeitige Einschaltung des Daten-

schutzbeauftragten bei Vorhaben der automatisierten Verarbeitung personenbezogener Daten.

Hierzu gehören auch die Einführung, Erweiterung um zusätzliche Module/ Funktionen und

der Releasewechsel von SAP ERP.

Wird SAP ERP in einem Unternehmen eingeführt, ist der Datenschutzbeauftragte frühzei-

tig zu beteiligen, damit er die unter 1.1 aufgeführten Punkte mit beraten kann (wie rechtli-

che Grundlagen in den Verträgen oder Datenlöschkonzept).

8 M. Schäfer, M. Melich: SAP Solution Manager . Galileo Press, Bonn 2006



Der Datenschutzbeauftragte hat dabei darauf hinzuwirken, dass das Customizing und die

Implementierung des SAP ERP den Anforderungen des BDSG genügt und gegebenenfalls

eine Vorabkontrolle durchzuführen.

Insbesondere dem Grundsatz der Datenvermeidung und Datensparsamkeit gemäß § 3a

BDSG kommt im Rahmen einer SAP ERP-Einführung große Bedeutung zu. Hier kann der

Datenschutzbeauftragte ggf. direkten Einfluss auf die Gestaltung des Systems nehmen.

Über Review des Schulungskonzepts kann der Datenschutzbeauftragte Einfluss auf die

Datenschutz-Sensibilisierung der Anwender nehmen.

Durch Einfordern des Verfahrensverzeichnisses ist die verfahrensverantwortliche Stelle

die das SAP ERP einführt in der Verantwortung zu den relevanten Fragestellungen des

DBSG unter Berücksichtigung des konkreten Verfahrens eine Dokumentation vorzuneh-

men, s. oben 1.1.14.

Bei einem Releasewechsel oder einer funktionalen Erweiterungen hat sich der Daten-

schutzbeauftragte auch von der datenschutzkonformen Durchführung zu überzeugen.

1.2.1 Datenschutzbeauftragter - Mitglied des SAP-Projektteams

Die sachgerechte Beratung der Projektleitung und -mitarbeiter und die Überprüfung der ord-

nungsgemäßen Anwendung (Customizing) durch den Datenschutzbeauftragten, die im § 4g

Abs. 1 S. 4 Nr. 1 BDSG vorgesehen ist, können effektiv erreicht werden, wenn er in der Pro-

jektorganisation in einer beratenden, weisungsfreien Funktion aufgeführt ist.

Wird SAP ERP in einem Unternehmen eingeführt, ist der Datenschutzbeauftragte daher vom

Projektbeginn an zu beteiligen.

1.2.2 Information des Datenschutzbeauftragten zu den „Meilensteinen“

Es liegt in der Verantwortung des Datenschutzbeauftragten zu entscheiden, wann und wie er

die ordnungsgemäße Anwendung von SAP ERP überprüft und welche Unterlagen er hierfür

benötigt. Die Abstimmung, welche Unterlagen er benötigt und wann die Fragestellungen aus

dem BDSG zu beantworten sind, lässt sich nur angemessen unter Berücksichtigung der Ziel-

setzungen und Projektentwicklung festlegen.

Der Datenschutzbeauftragte sollte zu den „Meilensteinen“ die erforderlichen Absprachen mit

dem Projektteam zu den einzelnen Modulen treffen bzw. überprüfen, ob die getroffenen Fest-

legungen den Anforderungen des BDSG genügen.

Die datenschutzrelevanten Projektschritte sind im ASAP-Vorgehensmodell definiert.

Ein Beispiel: ASAP-Vorgehensmodell

2.6 Geschäftsprozessdefinition

2.6.3.1 Anforderungen zu Geschäftsprozessen bestimmen...

2.6.3.3. Anforderungen zum Berichtswesen bestimmen und mit Datenschutzbeauftragten

abstimmen



1.2.3 Informationsmöglichkeiten für den Datenschutzbeauftragten

Der Datenschutzbeauftragte sollte über Zugriff auf Ressourcen mit folgenden Kenntnissen

verfügen oder sich einen angemessenen Kenntnisstand über folgende Elemente des SAP ERP-

Systems aneignen:

Das Berechtigungskonzept und den Profilgenerator

Die Tabellenverwaltung

Die SAP Programmiersprache ABAP und ABAP Query

ABAP - Advanced Business Application Programming, JAVA

Das SAP ABAP Dictionary

Im ABAP Dictionary sind alle Datenfelder des SAP-Referenzmodells dokumentiert. Eine

Übersicht über die Verwendung eines einzelnen Feldes in der SAP-Datenwelt erhalten Sie

über die Funktion Verwendungsnachweis.

Verfahrensweise bei Extraktion und Auswertung von Daten aus SAP ERP mit Stan-

dardtools wie z.B. Microsoft Excel.

Hilfsmittel zur Gestaltung von Bildschirmmasken (Screen & Menue Painter)

Zur sachgerechten Beratung und Prüfung der ordnungsgemäßen Anwendung von SAP ERP

benötigt der Datenschutzbeauftragte darüber hinaus Unterlagen und Informationen.

Folgende Unterlagen sollten dem Datenschutzbeauftragten generell zur Verfügung stehen:

Komplette SAP ERP-Dokumentation (Doku-CD, Begleitbriefe, Release-Informationen

mit Transaktion SO99, http://help.sap.com)

Der SAP-Einführungsleitfaden und das ASAP-Vorgehensmodell

Der DSAG Prüfleitfaden des AK Revision/AG Audit Roadmap SAP ERP 6.0,(Stand März

2009): http://www.dsag.de

Die SAP Sicherheitsleitfäden werden von SAP zur Verfügung gestellt. Bitte beachten Sie

den SAP-Hinweis 39267 ‚Verfügbarkeit des SAP Sicherheitsleitfadens’

Die SAP-Hilfe (Dokumentations-CD) (http://www.sap.com/germany/aboutSAP/shop/)

Die SAP Dokumentation im Internet (http://help.sap.com)

Zugriff auf den SAP Service Marketplace für die Hinweise und zusätzliche Informationen

(http://service.sap.com) . Der Datenschutzbeauftragte sollte sich alle Dokumente unter den

Stichworten „Datenschutz“, „Datensicherheit und „Sicherheit“ ansehen.

IDES Schulungssystem (IDES - Internet Demo and Evaluation System)

Audit Information System. Das Audit Information System (AIS) ist als Arbeitsmittel für

den Auditor und den Datenschutzbeauftragten gedacht und wird im Kapitel 6.1 „Audit In-

formation System“ beschrieben.

Bitte beachten Sie den SAP-Hinweis 77503 ‚Audit Information System (AIS)’.

SAP-Hinweis 23611 ‚Sicherheit in SAP-Produkten’

SAP-Hinweis 30724 ‚Datenschutz und Sicherheit in SAP Systemen’

SAP Press „Datenschutz in SAP-Systemen“, Galileo Verlag, ISBN 978-3-8362-1421-6

http://help.sap.com/

http://www.dsag.de/

http://www.sap.com/germany/aboutSAP/shop/


http://service.sap.com/

Leitfaden Datenschutz Autor Seite

für SAP-ERP AG Datenschutz 20

1.3 SAP-Fakten

1.3.1 Customizing und ASAP-Vorgehensmodell

Das Customizing wurde in eine Transaktion für die Projektverwaltung (SPRO_ADMIN) und

in eine Transaktion für die Projektbearbeitung (SPRO) aufgeteilt.

Das Customizing dient der unternehmensspezifischen Einstellung des SAP-Systems. Auf-

grund der komplexen Tabellenstrukturen von SAP ERP stellt SAP systemseitig ein Vorge-

hensmodell und Einführungsleitfäden (Grundstrukturen zur Einführung) zur Verfügung. Die-

se sind auch Bestandteil der SAP-Online-Dokumentation.

Das ASAP-Vorgehensmodell bildet zum einen den methodischen Rahmen für den Einfüh-

rungs- und Releasewechselprozess, zum anderen ist es ein operatives Werkzeug zur Un-

terstützung in jeder Phase der Einführung.

Die Projektleitfäden für das SAP ERP-Customizing als unternehmensspezifische Unter-

menge des Vorgehensmodells listen alle Aktivitäten für die Einführung des SAP-Systems

auf und unterstützen die Steuerung und Dokumentation der Einführung.

Die ordnungsmäßige SAP-Einführung hängt wesentlich von der sachgerechten Nutzung der

SAP-Einführungsleitfäden (Implementation Guide - IMG) ab.

Das ASAP-Vorgehensmodell beinhaltet für den Datenschutzbeauftragten wesentliche Punkte,

bei denen er projektspezifisch festlegen sollte, wie er in die Projektentwicklung einzubeziehen

ist.

Beispiele für die Einbeziehung des Datenschutzbeauftragten sind:

Datenschutzrelevante Geschäftsprozesse ermitteln und festlegen

Lifecycle der personenbezogenen Daten ermitteln und Lösch- / Sperrkonzept festlegen

Stammdaten festlegen

Berichtswesen festlegen

Informationsfluss personenbezogener Daten bei Anwendungsschnittstellen, insbesondere

zu anderen Programmen, untersuchen

Informationsfluss der vorgesehenen Berichte und Auswertungen auf Datenschutzgesichts-

punkte hin untersuchen

Datenschutzspezifische Freigabe zu Projektphasen (Meilensteinen) festlegen

Berechtigungskonzept unter Datenschutz- und Datensicherheitsgesichtspunkten beurteilen

Archivierungskonzept, insbesondere im Hinblick auf die Löschungsfristen, beurteilen

(siehe Kapitel 2.3.5 Regelfristen für Löschung)

Testkonzept beurteilen

Datenschutzspezifische Schulungsinhalte und -zeitpunkte festlegen



Dokumentationsinhalte hinsichtlich datenschutzrelevanter Fragen festlegen

Migration und Altdatenübernahme definieren

Programmanpassungen ermitteln und genehmigen

Das SAP-Standard-Vorgehensmodell und allgemeine Hinweise hierzu finden Sie auf der Do-

kumentations-CD oder dem SAP Marketplace; service.sap.com.

Die einzelnen Themen sollten bei der Planung einer Beteiligung des Datenschutzbeauftragten

durchgegangen und für die Festlegung des eigenen Vorgehens verwendet werden.

Der SAP ERP Customizing Einführungsleitfaden (Implementation Guide (IMG)) ist im Sys-

tem über den Menüpfad zu finden:

Werkzeuge Customizing IMG Projektbearbeitung (SPRO); Schaltfläche

‚SAP-Referenz-IMG’

Die Zuordnung der Customizing-Aktivitäten der modulbezogenen Einführungsleitfäden zum

Vorgehensmodell ermitteln Sie durch die Zuschaltung der Anzeige. Gehen Sie folgenderma-

ßen vor:

1. Rufen Sie die angelegten Projektleitfäden auf:

Menüpfad:

Werkzeuge Customizing IMG Projektbearbeitung

durch Doppelklick auf das jeweilige Projekt und anschließendes Klicken auf die Schalt-

fläche ‚Projekt-IMG’ erhalten Sie den zugehörigen Projektleitfaden angezeigt.

2. Öffnen Sie die jeweiligen Customizing-Aktivitäten bis auf die Ebene der ausführbaren

Funktionen.

Suchen Sie sich die einschlägigen Aktivitäten aus den Leitfäden heraus, die Sie unter Da-

tenschutzgesichtspunkten bearbeiten müssen und identifizieren Sie die modulspezifischen

Einstellungen.

3. Nehmen Sie Kontakt mit den modulbezogenen Projektgruppen auf und sprechen Sie Ihre

Aktivitäten mit ihnen ab.

1.3.2 Berechtigungskonzept

Ein Zugriffsschutzsystem und die Möglichkeit zur Vergabe individueller Berechtigungen

dient unter Datenschutzaspekten im Wesentlichen folgenden Zielen:

dem Schutz vertraulicher Daten vor unberechtigter Erhebung, Speicherung, Kenntnisnah-

me, Übermittlung und Nutzung, dem Schutz der Daten vor unberechtigter, auch verse-

hentlicher Änderung oder Löschung

der Gewährleistung des zweckgebundenen Gebrauchs der Daten

der Nachvollziehbarkeit und Zweckgebundenheit des Zugriffs auf personenbezogene Da-

ten

SAP liefert einen Set von Standardrollen aus, die der Kunde als Vorlage benutzen und hin-

sichtlich der Zuständigkeiten und organisatorischen Ausprägungen an seine individuellen Be-

dürfnisse anpassen kann. Der Umfang dieser Rollen ist aus Funktionssicht definiert, die Rol-

len sind zwingend auf die Sicherheitsbedürfnisse (Funktionstrennung, kritische Berechtigun-

gen) der Organisation anzupassen. Mit jeder Vorlage erhält man ein individuelles Benutzer-



menü. Die Rollenvorlagen sind integrativer Bestandteil der anwendungsübergreifenden

Workplace und Enterprise Portal/Portal-Rollen.

Dem Administrator steht eine erweiterte Funktionsauswahl in der Einstiegstransaktion SAP

Easy Access zur Verfügung. Mit dieser erweiterten Funktionsauswahl ist es ihm möglich, ein-

fach eine der vielen Benutzerrollen einem Benutzer zuzuweisen. Dieser Benutzer erhält bei

der Anmeldung am System automatisch das für seine tägliche Arbeit typische Benutzermenü

sowie die Berechtigungen, die er für diese Arbeit benötigt.

Die hohe Flexibilität des SAP-Berechtigungs- und Benutzerverwaltungskonzepts kann daher

bei unsachgemäßer Anwendung bereits im Rahmen der Einführungsphase zu erheblichen

Verletzungen des Datenschutzes führen. Statt des weit gefassten Standards bei ausgelieferten

Rollen und Profilen etc. muss daher unbedingt unternehmensspezifisch nach dem Prinzip der

minimalen Berechtigung eingegrenzt und angepasst werden.

Da die Ordnungsmäßigkeit des SAP ERP-Systems unmittelbar durch das Verfahren zur

Vergabe von Berechtigungen beeinflusst wird, ist auch das Vergabeverfahren selbst als we-

sentlicher Bestandteil des Zugriffsschutzes anzusehen. Es muss daher organisatorisch defi-

niert revisionsfähig gestaltet sowie ausreichend getestet und spätestens zum Produktionsbe-

ginn verfügbar sein.

Schließlich muss darauf geachtet werden, dass Rollen und ggf. auch Aktivitätsgruppen, Be-

rechtigungen und Profile im Testsystem neu angelegt, geändert oder gelöscht werden und an-

schließend mittels CTS/CTO (Change Transport System/Change Transport Organizer) über

das Qualitätssicherungssystem in die Produktionsumgebung übernommen werden.

1.3.3 Change Transport System/Change Transport Organizer (CTS/CTO)

SAP empfiehlt, in einem produktiven System grundsätzlich keine Änderungen vorzunehmen

bzw. zuzulassen. Alle Änderungen sind daher aus der Test- oder Qualitätssicherungsumge-

bung mit dem sog. Korrektur- und Transportwesen9 in das produktive System zu übernehmen.

Das gesicherte Korrektur- und Transportwesen ist somit wesentlicher Bestandteil eines siche-

ren und ordnungsgemäßen SAP ERP-Systems.

Unter Datenschutzaspekten stehen dabei folgende Zielsetzungen im Vordergrund:

die Registrierung und Dokumentation einschließlich der geordneten Übergabe der Syste-

mentwicklungsumgebungsobjekte (EUO) zwischen den unterschiedlichen SAP ERP-

Systemen oder unterschiedlichen Mandanten innerhalb eines SAP ERP-Systems

die Sicherstellung, dass ausschließlich genehmigte Systemänderungen vorgenommen und

entsprechend nachvollziehbar dokumentiert werden

Aus den vorgenannten Zielen und aus der Tatsache, dass EUO in der Regel systemweite Gül-

tigkeit besitzen, ist zwingend erforderlich, dass mindestens zwei physisch getrennte SAP

ERP-Systeme implementiert werden müssen (Test- und Produktivsystem), wenn personenbe-

zogene Daten aus der Produktivumgebung (z.B. für Massentests) in der Testumgebung ver-

wendet werden, sind diese dort nach Möglichkeit entweder zu anonymisieren oder zu pseudo-

nymisieren. Hierzu kann man sich ggf. geeignete Anonymisierungs-Tools von Drittanbietern

beschaffen. Sollte dies nicht möglich sein, sind auch für das Testsystem und die Testumge-

5 M. Schäfer, M. Melich: SAP Solution Manager . Galileo Press, Bonn 2006



bung angemessene Maßnahmen zur Datensicherheit zu ergreifen (z.B. zeitliche Begrenzung

der Berechtigungen im Testsystem). Das Berechtigungskonzept ist auf alle Systeme, auch

Entwicklungs- und Testsysteme anzuwenden, insbesondere wenn sie personenbezogene Da-

ten enthalten.

1.3.4 Schnittstellenverarbeitung

Durch die zunehmende Vernetzung von SAP ERP mit anderen Systemen und Plattformen be-

kommt die Schnittstellenverarbeitung eine erweiterte Bedeutung. Neben der technischen Di-

mension ist auch die Überprüfung des Zwecks der Verarbeitung zu hinterfragen. Die Mög-

lichkeiten der Integration von sozialen Plattformen (wie Facebook, Xing, Twitter, …) über

Schnittstellen erfordert eine erneute Prüfung des Zwecks, da die sozialen Plattformen übli-

cherweise nicht für den Betroffenen erkennbar die Daten für die Verarbeitung in SAP ERP

erheben und somit eine Zweckänderung anzunehmen ist, deren Zulässigkeit zu prüfen ist.

1.3.4.1 Datenübernahme

Im Sinne der Datensparsamkeit ist zu entscheiden, welche Daten zu übernehmen sind. Für

diese Daten bietet SAP die LSMW (Legacy System Migration Workbench) als Datenüber-

nahmeverfahren. Dieses Tool ist speziell für die Altdatenübernahme konzipiert worden und

bedient sich der BAPI- oder Batch-Input-Schnittstelle (siehe auch Transaktion LSMW).

Da die Konvertierung aus dem Alt- bzw. Vorsystem mit Programmen außerhalb des SAP

ERP-Umfeldes erfolgt, ist die ordnungsgemäße Umsetzung der Daten (d. h. die Datenkonsis-

tenz) durch geeignete organisatorische Maßnahmen sicherzustellen, um möglichen Manipula-

tionen vorzubeugen.

Für die Datenübernahme wird im SAP ERP auch das Batch-Input-Verfahren10 herangezogen.

Hierbei wird durch ein Schnittstellenprogramm eine sog. Batch-Input-Mappe erzeugt, die da-

bei die Online-Eingabe von Transaktionscodes und Daten simuliert und beim Abspielen die

entsprechenden Berechtigungs- und Plausibilitätsprüfungen durchläuft.

Neben dem Batch-Input-Verfahren bestehen weitere Möglichkeiten der Datenübernahme, z.B.

Remote Function Call (RFC), Internet-Schnittstellen oder PC-Upload und Download11. Diese

werden i.d.R. für Datenübernahmen im lfd. Betrieb (aus vor- oder nachgelagerten Systemen)

eingesetzt.

Alle Schnittstellen sind im Falle der Übermittlung/Weitergabe entsprechend dem § 4e BDSG

zu dokumentieren.

1.3.4.2 PC-Verarbeitung

Up-/Download in der Anwendung (vgl. hierzu u.a. Kapitel 4.2.1.8)

SAP-GUI Scripting ermöglicht es dem Anwender große Datenmengen schnell zu bearbeiten

(einzugeben, ändern) in Form von makro-ähnlich ablaufenden Skripten auf dem PC, damit

vergleichbar zu Job-Auftrag-Verfahren durch Anwender (vgl. hierzu u.a. Kapitel 1.3.5)

10 siehe hierzu ergänzende Hinweise in Kapitel 6 Prüfleitfaden Revision

11 siehe hierzu ergänzende Hinweise in den SAP-Sicherheitsleitfäden



1.3.4.3 Kommunikationsschnittstellen

Die datenorientierte Schnittstelle Remote Function Call (RFC) ermöglicht SAP- und Nicht-

SAP-Anwendungen, SAP Funktionsbausteine über Rechnergrenzen aufzurufen.

Die Schnittstelle trusted Remote Function Call (tRFC) ermöglicht logische SAP-

Anwendungen über Grenzen von Mandaten und Systemen aufzubauen.

Business Application Programming Interfaces (BAPIs) sind von externen Programmen auf-

rufbare und direkt ausführbare Methodenaufrufe von Business-Objekten.

Diese geschäftsprozessorientierten Standardschnittstellen sind auf eine Dialogkommunikation

ausgerichtet. Sie ermöglichen die Ergänzung des SAP ERP-Kernsystems um Anwendungen,

die speziell im Internet und Intranet entwickelt werden.

BAPIs werden SAP ERP-intern als Funktionsbausteine realisiert, die über RFC aufrufbar

sind.

Application Link Enabling (ALE) ermöglicht die Verteilung von Daten des SAP ERP-

Systems. Über Musterlösungen wird beschrieben, wie ein Unternehmen seine geographische

Datenverarbeitung organisieren und durchführen kann.

Mit ALE/Web lassen sich verteilte Geschäftsprozesse über das Netz quasi zum Geschäfts-

partner verlagern.

Im Rahmen von ALE werden BAPIs für die Integration verteilter Geschäftsprozesse einge-

setzt.

1.3.4.4 SAP-Automation

Mit dieser Schnittstelle lassen sich alternative Oberflächen statt dem SAP GUI einsetzen.

Neben der Kommunikationssicherheit ist zu prüfen, ob über diese Schnittstellen personenbe-

zogene Daten ausgetauscht bzw. übermittelt werden und wer die regelmäßigen Empfänger

sind.

1.3.5 Job-Auftrags-Verfahren - und Dokumentation

Beim Job-Auftragsverfahren steht unter Datenschutzaspekten der Schutz und die Integrität der

Unternehmensdaten und der personenbezogenen Daten im Vordergrund.

Jobs, die ein Operating benötigen und deshalb nicht ausschließlich im Aktionsbereich der

Fachabteilung durchgeführt werden, müssen besonders beachtet werden. Insbesondere bei

diesen Jobs darf keine Ausführung ohne schriftlichen Auftrag erfolgen. Auftraggeber ist i.d.R.

die Fachabteilung.

Bei Jobs, die vom SAP-System generiert werden, wird die Dokumentation automatisch mit

generiert. Beim von Anwendern selbst generierten Jobs (z.B. Batch-Input-Mappen) muss

auch die Dokumentation durch den Anwender selbst erfolgen. Diese Dokumentation sollte

nach einem einheitlichen Schema erfolgen.

Jobs werden nicht über das Korrektur- und Transportwesen vom Test- ins Produktivsystem

übergeben. Sie werden im Produktivsystem neu erstellt.



1.4 Risiken

Bei der Einführung von SAP ERP-Systemen bzw. -Projekten bestehen aufgrund der oben ge-

schilderten SAP-Fakten auch unter Datenschutzaspekten besondere Risiken.

Neben dem Risiko der unsachgemäßen SAP-Einführung durch Fehler beim Customizing und

der Benutzung bzw. Handhabung des Korrektur- und Transportwesens ergeben sich auch aus

Fehlern bei der Erstellung eines Zugriffsberechtigungskonzepts, eines fehlenden Löschkon-

zepts oder einer unvollständigen Datenschutzschulung der Benutzer negative Folgewirkungen

für die vorzusehenden technischen und organisatorischen Maßnahmen oder den Ruf des Un-

ternehmens.

1.4.1 Nichteinschaltung des Datenschutzbeauftragten bzw. der

Arbeitnehmervertreter

Werden der Datenschutzbeauftragte und - soweit vorhanden - die Mitbestimmungsorgane

(Arbeitnehmervertretung) nicht rechtzeitig sowohl bei der Einführung als auch bei allen nach-

folgenden Änderungen eingeschaltet, besteht das Risiko, dass datenschutzrechtliche Anforde-

rungen (u.a. Vorabkontrolle, unzulässige Datenspeicherung und -übermittlung) und Mitbe-

stimmungsrechte bei der Projektarbeit nicht hinreichend beachtet werden.

1.4.2 Nichtbeachtung der SAP-Empfehlungen

Die Nichtbeachtung der SAP-Empfehlungen, insbesondere der SAP ERP-Sicherheitsleitfäden

und die SAP NetWeaver Security Guides (s. http://help.sap.com) kann eine unsachgemäße

und nicht ordnungsgemäße Systemeinführung zur Folge haben.

Hier bestehen insbesondere folgende Risiken:

Zugriffsmöglichkeiten auf Betriebssystem-, Datenbank- und Netzwerkebene

unsachgemäßes Abweichen beim Customizing vom Vorgehensmodell bzw. den Imple-

mentation Guides (IMGs)

unzureichende Dokumentation und Erläuterungen der Customizing-Einstellungen

unzureichende Schnittstellendokumentation (Batch-Input, PC-Download, ggf. Systemer-

weiterungen, Archivierungssysteme)

1.4.3 Nichtberücksichtigung bzw. verspätete Erstellung des

Berechtigungskonzeptes

Während der Einführungsphase des SAP ERP sowie neuer Komponenten ist ein betriebswirt-

schaftliches Berechtigungskonzept zu erstellen. Dies dient als Grundlage u.a. für den Aufbau

von Rollen, mit denen manuell oder mittels des Profilgenerators dann die benutzerspezifi-

schen Berechtigungsprofile erstellt werden.

Das Berechtigungskonzept muss konsequent und konsistent eingesetzt werden. Der jeweils

aktuelle Stand der zugelassenen Benutzer und deren Zugriffsrechte sind zu dokumentieren.

Beim Customizing müssen u.a. SAP-Vorgaben (z.B. Rechte, Startparameter etc.) einschrän-

kend geändert werden. Beim Zugriff auf Tabellen mit dem Data Browser müssen u.a. der Zu-

griff durch die Fachabteilung vermieden werden. Bei einem unzureichenden bzw. zu spät ein-




gesetztem Berechtigungskonzept besteht die Gefahr, dass den Benutzern zu weit reichende

Berechtigungen vergeben werden.

1.4.4 Nicht ordnungsgemäße Anwendung eines

Datenverarbeitungsprogramms

Die Voraussetzung für den ordnungsgemäßen Einsatz von SAP ERP ist u.a. die Beachtung

der Auflagen des BDSG. Konkret sind bei der Einführung eines SAP ERP-Systems unter Da-

tenschutzaspekten folgende Risiken möglich:

Unberechtigtes Mitlesen von Daten auf dem Übertragungsweg

Unberechtigtes Einsehen von Daten auf Grund unzureichender Schutzmaßnahmen am Ar-

beitsplatz oder beim mobilen Arbeiten (RAS) oder Arbeiten über Apps

Unzureichende Datenmodellierung aufgrund unterlassener Vorabkontrolle bei Verwen-

dung von Daten besonderer Art nach § 3 Abs. 9 BDSG

Unzulässige bzw. leichtfertige Handhabung von personenbezogenen Originaldaten im

Testsystem

Fehlende Verpflichtung auf das Datengeheimnis bzw. unzureichende Sensibilisie-

rung/Schulung der Projektmitglieder/Anwender

Unzureichende Dokumentation der personenbezogenen Daten, um den Rechten der Be-

troffenen (Auskunft, Berichtigung, Sperrung und Löschung) und der Verpflichtung zur

Benachrichtigung nachzukommen

Nichtbeachtung des 4-Augen-Prinzips im Rahmen des CTS (Change and Transport Sys-

tem). Unzureichende Festlegung der Transportschichten (Integrations-, Konsolidierungs-

bzw. Belieferungssysteme) in den Tabellen TCENTRAL und TCEDELI innerhalb des

CTS

Unzureichende Absicherung des Transportprogramms (tp, bzw. R3trans) sowie unzu-

reichende Aufbewahrung des Transportprotokolls

Ggf. fehlende Historienführung bei der Übertragung von Programmen bzw. Tabellen in

die Produktivumgebung

Wird das CTS nicht oder falsch eingesetzt, können nicht autorisierte Programme/Objekte

zur unzulässigen Nutzung oder Verarbeitung personenbezogener Daten führen

Unrechtmäßige Kenntniserlangung bei bestimmten Kategorien von personenbezogenen

Daten führt zu unterschiedliche Informationspflichten gegenüber den Betroffenen und der

Aufsichtsbehörde

Die Einschränkung der vorgenannten Risiken dient auch dazu, das Risiko der Unternehmens-

leitung (Straftaten, Ordnungswidrigkeiten und Schadenersatz im Sinne des BDSG §§ 7, 8,

42a, 43, 44) zu reduzieren.

1.5 Prüfungshandlungen im Rahmen der Einführung / Checkliste

Zur Hilfestellung für den Datenschutzbeauftragten und die Projektmitarbeiter ist die nachfol-

gende Checkliste (ohne Anspruch auf Vollständigkeit!) erstellt worden. Wesentliche Frage-



stellungen sind aufgenommen worden. Es wird jedoch empfohlen, diese Checkliste projektbe-

zogen zu überarbeiten und zu ergänzen. (Weitere Details zu Prüfungshandlungen s. Kap. 4)

Folgende Fragen sind pro SAP ERP-Komponente von der Projektleitung zu beantworten:

1. Welche Aufgabenstellungen soll die SAP ERP-Komponente abdecken?

2. Über welche Personengruppen (z.B. Bewerber, Mitarbeiter, Angehörige von Mitarbeitern,

Debitoren, Kreditoren, Fremdfirmenmitarbeiter etc.) sollen Daten gespeichert werden?

3. Welche Geschäftsprozesse sind betroffen?

4. Werden durch die Ausgestaltung der Projektorganisation datenschutzrechtliche Aspekte

des SAP-Projektes rechtzeitig berücksichtigt?

5. Sind dem Datenschutzbeauftragten rechtzeitig ausreichende Unterlagen, insbesondere für

die Vorabkontrolle zur Verfügung gestellt worden?

6. Ist der Datenschutzbeauftragte in die Projektarbeit angemessen eingebunden?

7. Welche personenbezogenen Daten sollen gespeichert werden?

8. Welche personenbezogenen Daten sollen an externe Empfänger aus welchem Grund (re-

gelmäßig, anlassbezogen) übermittelt werden? Liegt bei Empfängern außerhalb der EU

ein angemessenes Datenschutzniveau vor?

9. Liegen die Rechtsgrundlagen zur Erhebung, Verarbeitung und Nutzung personenbezoge-

ner Daten (z.B. gesetzliche Grundlage, Vertrag (etwa Arbeitsvertrag, Betriebsvereinba-

rung, ...), freiwillige, schriftliche Einwilligung oder Interessensabwägung ) vor?

10. Werden Externe mit der Verarbeitung von personenbezogenen Daten beauftragt, bis wann

liefert die verfahrensverantwortliche Stelle dem Datenschutzbeauftragten den Vertrags-

entwurf mit dem Externen, der die technischen und organisatorischen Maßnahmen zur

Einhaltung des Datenschutz beinhaltet?

11. Soll die Möglichkeit eines automatisierten Abrufes von personenbezogenen Daten reali-

siert werden?

- Wenn ja: Wie sollen die Anforderungen zur Sicherstellung des rechtmäßigen Abrufes

und der Datensicherheit realisiert werden?

12. Werden automatisierte Einzelfallentscheidungen vorgenommen?

- Wenn ja: Sind die Voraussetzungen des § 6a Abs. 2 BDSG gegeben?

13. Welche Schnittstellen bestehen zu anderen DV-Anwendungen?

14. Welche Logfiles sind vorgesehen, und wie sollen sie verwendet werden? (z.B. Report-

Protokolldatei in SAP ERP HCM, Tabelle V_T599R und Erstellung des Security Audit

Logs).

15. Wie soll die Zweckbindung gemäß § 31 BDSG eingehalten werden?

16. Welche Dauer der Datenspeicherung ist für die einzelnen Datengruppen unter Berücksich-

tigung der jeweiligen Rechtsgrundlage vorgesehen?

17. Welches Löschungskonzept soll realisiert werden?

18. Wie wird sichergestellt, dass aufbewahrungspflichtige Daten (z.B. 10-Jahresfrist aus steu-

erlichen Gründen) nur zweckgebunden zur Verfügung stehen?

19. Besteht die Notwendigkeit, Personen zu benachrichtigen?



- Wenn ja: Wie und mit welchen Formulierungen soll der Betroffene benachrichtigt

werden?

20. Wie ist das Sicherheitskonzept gestaltet?

21. Sind die Berechtigungen nach dem Prinzip der geringsten Berechtigung vergeben?

22. Sind die SAP-Sicherheitsleitfäden abgearbeitet worden?

23. Werden personenbezogene Daten verschlüsselt übertragen (dies ist für die SAPGUI- und

die SAPLPD-Verbindung mit SNC möglich; RFC-Verbindungen können gesichert wer-

den) und ggf. verschlüsselt gespeichert (dies ist eine Funktion der Datenbank, nicht des

SAP ERP)?

24. Auf welcher Hardware und an welchen Standorten soll SAP ERP installiert werden?

25. Welches DV-Netz soll genutzt werden?

26. Werden beim Einsatz von Internet/Intranet-Techniken entspr. Firewall-Systeme einge-

setzt?

27. Werden alle eingesetzten DV-Systeme zum Betrieb des SAP ERP Systems dokumentiert?

28. Wenn ja: Welche organisatorischen Lösungen sind vorgesehen, um dem Datenschutzbe-

auftragten eine Übersicht zur Verfügung zu stellen?

29. Wann ist dem Datenschutzbeauftragten von der verfahrensverantwortlichen Fachabteilung

eine Verfahrensübersicht zur Verfügung zu stellen?

30. Welche organisatorischen Lösungen zum Datenschutz sind vorgesehen?

31. Sind alle neu hinzugefügten Tabellen, Domänen, Datenfelder und Reports entsprechend

dokumentiert und ausreichend geschützt?

32. Sind alle Personen, die Zugriff auf personenbezogene Daten erlangen können, auf das Da-

tengeheimnis verpflichtet?

33. Wird der Datenschutzbeauftragte bei Systemerweiterungen, System-Upgrades bzw. Re-

leasewechseln zeitnah eingeschaltet?

34. Gibt es in Referenztabellen oder Suchhilfen Auswahlfelder mit ggf. kritischen Inhalten

(z.B. Angaben zur Konfession im Infotyp 0002, Angaben zum Familienstand oder Kin-

dern)?



2 Aufgaben des Datenschutzbeauftragten

Da der DSB in der Regel kein SAP-Spezialist ist, wird er mit unterschiedlichen Mitarbeitern

des Unternehmens zusammenarbeiten. Er wird sich im Rahmen seiner Tätigkeit sowohl mit

Anwendern der Fachabteilungen als auch mit DV-Mitarbeitern austauschen. Ebenso ist eine

Kooperation mit anderen Organisationseinheiten des Unternehmens (z.B. interne Revision,

Compliance oder IT-Sicherheit ) zur Bearbeitung einzelner Themenfelder denkbar.

Um die Vorabkontrolle, die Begleitung des Customizing und die erforderlichen Prüfungs-

handlungen möglichst umfassend durchführen zu können, ist eine ausreichende Ausbildung

des Datenschutzbeauftragten in der Nutzung der relevanten SAP ERP-Funktionen notwendig.

Dies gilt im besonderen Maße für die Programmüberwachung.

Im SAP ERP wird eine Vielzahl von Auditor-Rollen ausgeliefert, die insbesondere den ver-

schiedenen Funktionsbereichen des Audit Information Systems (AIS) zugeordnet sind. Diese

Standardrollen sind nur als Vorlage für die unternehmensspezifischen Rollen des jeweiligen

Anwenderbetriebes gedacht und müssen noch an die betrieblichen Strukturen angepasst bzw.

ausgeprägt werden. Die ausgelieferten AIS-Standardrollen sind unterteilt in Transaktionsrol-

len (definieren ‚nur’ das Benutzermenü) und Berechtigungsrollen (beinhalten die Berechti-

gungen)12.

In der folgenden Tabelle wird eine Auswahl der von SAP angebotenen Standardrollen darge-

stellt die für den Datenschutzbeauftragten relevant sind:

Das Audit Information „Cockpit“ steht kurz vor der Auslieferung; siehe Hinweis 1860243:

AIS_Pilotauslieferung

Rolle Beschreibung Funktionsumfang

SAP_AUDITOR_A AIS - Zentrale

Berechtigungen

Die Berechtigungen der Rolle sind zentral

für das kaufmännische Audit und das Da-

tenschutzaudit

SAP_AUDITOR_ADMIN AIS-

Administration

Diese Rolle beinhaltet Funktionalitäten für

die Administration des AIS

SAP_AUDITOR_DS AIS-Datenschutz Das Menü der Rolle enthält das Dateiregis-

ter zu personenbezogenen Daten

SAP_AUDITOR_DS_A AIS-Datenschutz

(Berechtigungen)

Die Rolle beinhaltet Berechtigungen für das

Datenschutzaudit

SAP_AUDITOR_BA_HR AIS-Human

Ressources

Das Menü der Rolle bietet Funktionalitäten

zum kaufmännischen Audit (Einzelab-

schluss) und zur Personalwirtschaft

(HR/HCM)

SAP_AUDITOR_SA AIS-System Das Menü der Rolle enthält Funktionen zum

System Audit, insbesondere Systemkonfigu-

12 Siehe hierzu auch die SAP Hinweise 754273 und 451960



Rolle Beschreibung Funktionsumfang

Audit ration, Transportverbund, Entwicklung und

Customizing

SAP_CA_AUDITOR_SY

STEM_DISPLAY

AIS-

Berechtigungen

für System Audit

(Anzeige)

Die Berechtigungen der Rolle ermöglichen

einen Zugang zum System Audit

(Vorsicht: entgegen der SAP Dokumentati-

on keine reinen Leserechte)

SAP_AUDITOR_SA_CC

M _USR

AIS-System

Audit-Benutzer

und

Berechtigungen

Das Menü der Rolle bietet Funktionen zur

Benutzerverwaltung: Benutzer, Berechti-

gungen, Profile und Rollen

Die Rollen sind wie folgt zu finden:

Menüpfad:

Werkzeuge -> Administration -> Benutzerpflege -> Rollenverwaltung (PFCG)

Die SAP-Auditor-Rollen sind sehr spezifisch auf einzelne AIS-Funktionen hin definiert. Die

von SAP ausgelieferten Rollen sind daher im Unternehmen sorgfältig zu analysieren und ggf.

entsprechend anzupassen.

Die explizite „Datenschutzrolle SAP_AUDITOR_DS beinhaltet als Menü zunächst nur die

AIS-Funktionen zum ‚Dateiregister’ des AIS. Eine Kombination mit weiteren Rollen (z.B.

SAP_AUDITOR_DS_A, SAP_AUDITOR_A, SAP_AUDITOR_HR oder

SAP_CA_AUDITOR_SYSTEM_DISPLAY) ist daher mindestens notwendig, um die Tätig-

keit eines Datenschutzbeauftragten im Rahmen der SAP-Prüfung zu unterstützen.

Die Rolle SAP_CA_AUDITOR_SYSTEM_ DISPLAY enthält lt. Beschreibung von 2009

keine Zugriff mehr auf kritische Berechtigungen, die über eine reine Anzeige hinausgehen.

Bei Bedarf ist der zuständige Administrator um Unterstützung zu bitten.

Es wird empfohlen, die SAP-Auditor-Rollen unternehmensspezifisch anzupassen.

Der Datenschutzbeauftragte hat über die für eine Datenschutzsystemprüfung erforderlichen

umfassenden Leserechte im Audit Information System (vgl. Kapitel 6) sowie den direkten

Aufruf der entsprechenden Transaktionen und Reports zu verfügen, allerdings ohne Zugriff

auf Mitarbeiterdaten.

Darüber hinaus kann dem Datenschutzbeauftragten für Echtdatenprüfungen eine zweite auf

die individuellen Zuständigkeiten geschaffene Rolle zugeteilt werden. Letztere ist ggf. zeitlich

befristet zu erteilen.

Eine Bewertung der von SAP ausgelieferten Rollen, eine Neukonzeption von Datenschutzrol-

len (z.B. eine Rolle mit reinen Leserechten) sowie Hinweise zur Ausprägung liefert die Dip-

lomarbeit ‘Entwicklung von Datenschutzrollen für das Audit Information System im SAP

ERP’ 13

13 Otto, Anna: Entwicklung von Datenschutzrollen für das AIS im SAP ERP, VDM Verlag, Saarbrücken

2008 Download der Datenschutzrollen unter: http://www.forbit.de/allgemein/arbeitspapiere.html



2.1 Überwachung der ordnungsgemäßen Programmanwendung (§ 4g Abs. 1 BDSG)

Der Beauftragte für den Datenschutz wirkt auf die Einhaltung des BDSG und anderer Vor-

schriften über den Datenschutz hin. ... Er hat insbesondere die ordnungsgemäße Anwendung

der Datenverarbeitungsprogramme, mit deren Hilfe personenbezogene Daten verarbeitet

werden sollen, zu überwachen; ....

Dabei sind speziell folgende Punkte von Relevanz:

Zulässigkeit der Datenverarbeitung unter Beachtung des Grundsatzes der Datenvermei-

dung und Datensparsamkeit (§ 3a BDSG). Der ausgelieferte SAP-Standard umfasst auch

Felder und Feldwerte, die je nach Unternehmen, Branche und Anforderung auf ihre Erfor-

derlichkeit zu prüfen sind.

Sicherstellung der Rechte der Betroffenen (§ 6 BDSG in Verbindung mit §§ 19 ff bzw.

§§ 34 ff BDSG)

Verpflichtung auf das Datengeheimnis (§ 5 BDSG)

besondere technisch-organisatorische Vorkehrungen zur Gewährleistung des Datenschut-

zes. Für den Fall, dass besondere Risiken für die Rechte der Betroffenen bestehen, ist eine

Vorabkontrolle zwingend erforderlich (§ 4d Abs. 5 BDSG)

Arbeitnehmerdatenschutz (§ 32 BDSG)

Aus diesem gesetzlichen Auftrag sind die folgenden Verpflichtungen für den DSB bei Einsatz

des SAP ERP-Systems abzuleiten.

2.1.1 Einbeziehung des DSB vor und während der

Programmentwicklung und -anpassung

Die Aufgaben des DSB beziehen sich neben dem Schutz personenbezogener Daten auch auf

die Sicherheit des Gesamtsystems. Hierzu ist es erforderlich, dass der DSB von Beginn an sei-

tens der Projektleitung in die Projekte eingebunden wird. Außerdem sind dem DSB Pro-

grammmodifikationen und Programmschnittstellen offen zu legen. Testverfahren sind ge-

meinsam abzustimmen.

Bereits beim Fachkonzept kann dann die Prüfung auf datenschutzrelevante Aspekte und ent-

sprechende Festlegung der verwendeten Objekte erfolgen.

Das dem Fachkonzept folgende DV-Konzept sollte einen Abschnitt über personenbezogene

Daten enthalten.

Weitere Informationen zu Tabellen, Feldnamen und Datenelementen sowie deren Verwen-

dung in Programmen liefert das ABAP Dictionary (Transaktion SE12) bzw. das Repository

Infosystem (Object Navigator, Transaktion SE84); zu weiterer Systemunterstützung vgl.

Kapitel 2.4.

2.1.2 Prüfung der Datenerhebung und Datennutzung auf Rechtmäßigkeit

Die Überwachungstätigkeit des DSB beschränkt sich nicht nur auf die Verarbeitung (§ 3 Abs.

4 BDSG). Sie umfasst auch das Erheben (§ 3 Abs. 3 BDSG) und das Nutzen (§ 3 Abs. 5

BDSG) personenbezogener Daten. In diesem Sinne ist zunächst die Zulässigkeit der konkre-



ten Datenverarbeitung zu prüfen. Für abhängig Beschäftigte beispielsweise, ob die Erhebung

und Nutzung der Daten für die verschiedenen Phasen eines Arbeitsverhältnisses erforderlich

sind (§ 32 BDSG).

2.1.3 Auswertung der Protokollierung

In SAP ERP stehen eine Vielzahl von Protokollen zu unterschiedlichen Zwecken zur Verfü-

gung (ausführliche Beschreibungen finden sich in den SAP-Sicherheitsleitfäden).

Im Folgenden sind die wesentlichen Protokolle, die dem DSB zur Kontrolle und zur Sicher-

stellung eines ordnungsgemäßen Betriebes zur Verfügung stehen sollten, aufgelistet (Hinweis:

Ein Nachvollzug wesentlicher Protokolleinträge ist mit dem Audit Information System (Sys-

tem Audit, Systemprotokolle und Statusanzeigen möglich). Details sind in Kapitel 4.2.1.9 be-

schrieben:

das Security Audit Log, Transaktion SM20N (Filtereinstellungen SM19)

das Read Access Log (siehe Kapitel 6.2)

Systemprotokoll Syslog, SM21

den Workloadmonitor des CCMS mit Transaktion STAD und ST03N

im Anwendungslog (Transaktionen SLG0 und SLG1)

Business Workflow (Transaktionen SWI2_* und SWI5).

Änderungen betriebswirtschaftlicher Objekte (Transaktion SCDO).

Customizing-Objekte und Tabellenaufzeichnungen (Transaktion SCU3; Reports RST-

BHIST und RSVTPROT)

SQL-Audit (vgl. SAP-Hinweis 115224).

SAP Query-Protokollierung (siehe Abschnitt 4.2.1.9.6)

Protokoll der Reportstarts HCM, Report RPUPROTD

Änderungsbelege HCM-Infotypen, Report RPUAUD00

Eingabeprotokoll Kundendaten (z.B. Batch-Input-Protokolle, Job-Protokolle)

2.1.4 Prüfung der Verfahrensdokumentation

Zur Überwachung der Programmanwendung durch den DSB ist eine aussagefähige Verfah-

rensdokumentation erforderlich, die insbesondere über folgende Punkte Auskunft geben soll:

Aufgabenstellung der Anwendung (i.S. der Zweckbindung), insbesondere mit Hinweisen

auf datenschutzrelevante Elemente

Organisatorische Struktur des Unternehmens mit verantwortlicher Stelle sowie eine even-

tuellen Auftragsdatenverarbeitung bzw. Funktionsübertragung

Technisch-organisatorische Maßnahmen gemäß Anlage zu § 9 S. 1 BDSG

Zugriffsberechtigungen nach Art und Umfang auf personenbezogene Objekte (z.B. Daten,

Programme, Berichte)



Verwendungsnachweis der personenbezogenen Objekte in Programmen, insbesondere für

Daten der besonderen Art § 3 Abs. 9 BDSG

Berechtigte interne und externe Empfänger der von den Anwendungsprogrammen erzeug-

ten Daten nach Art und Umfang und unter dem Aspekt der Datentrennung.

Darstellung der Programmabläufe. Sicherung der Datenbestände und der verwendeten

Programme. Aufstellung der aktivierten BAdI-Erweiterungen.

Lösch- und Sperrkonzept sowie die Archivierung (Abgrenzung von operativer Nutzung

und ‚Aufbewahrungs-Nutzung’)

Seitens SAP werden Hilfestellungen zur Verfahrensdokumentation bereitgestellt. Mit dem

Report RSCRDOMA können im Audit Information System z.B. die ‚Dateiregister-

Funktionalitäten’ zur Analyse der verwendeten personenbezogenen Domänen genutzt werden.

Ausführliche Hinweise zu weiteren Systemfunktionen finden sich insbesondere in den Ab-

schnitten 2.3.3 ff und 2.4.

2.1.5 Mitwirkung bei der Festlegung und Überprüfung des

Berechtigungskonzeptes

Der DSB ist an der Erarbeitung eines organisatorischen Rahmens zur Ausgestaltung des Be-

rechtigungskonzeptes beratend zu beteiligen. Diese Beteiligung kann dazu beitragen, den spä-

ter notwendigen Aufwand bei einer Vorabkontrolle zu reduzieren.

Das Berechtigungsrahmenkonzept hat verbindliche Aussagen zu enthalten über

den Geltungsbereich (verantwortliche Stelle/n)

ein System- und Mandantenkonzept für den genutzten SAP-Verbund

die Rahmenbedingungen; u.a. Verantwortungen für die Wartung und Pflege des SAP-

Systems einschließlich Festlegung der Customizing-Aufgaben und der hierfür benötigten

Berechtigungen XE "Berechtigungen" ; Regelungen zur Änderung von Systemobjekten,

wie insbesondere Repositoryobjekte (Änderungs-, Test- und Freigabeverfahren ein-

schließlich der Übernahme in die Produktion)

die fachlich-organisatorische Ausgestaltung des rollenspezifischen Konzepts

- möglichst arbeitsplatzbezogene und nur in begründeten Ausnahmefällen individu-

elle Ausgestaltung

- funktionaler Aufbau

- Prinzip der minimalen bzw. adäquaten Berechtigungsvergabe

- Kontrollierbarkeit im Sinne des BDSG und einer Revisionsfähigkeit

- Umsetzung der Anforderungen an die Zweckbindung (§ 31 BDSG) und Vertrau-

lichkeit für die besondere Art von Daten (§ 3 Abs. 9 BDSG) und der Datensiche-

rung im Sinne des § 9 BDSG und seiner Anlage

- Regelung für die Kommunikation über RFC-Bausteine und die ALE-Funktion

- Umsetzung der Vertraulichkeit im Druckerkonzept sowie Nutzung der Download-

Funktion und des Druckens in .pdf-Dokumente mit Versand per email.

die systemtechnische Ausgestaltung

- Grundsätze zur Nutzung der zentralen Benutzerverwaltung



- Regelungen für das Deaktivieren der Berechtigungsprüfung, für die Pflege der

HR-Berechtigungsobjekte, für die Nutzung von Funktionsbausteinen, die die Be-

rechtigungsprüfung deaktivieren und für Zugriffe auf die Datentabellen an den Be-

rechtigungsprüfungen in den „logischen Datenbanken“ vorbei. Regelung für die

Nutzung des Berechtigungsobjektes P_ABAP, das für Programme die HR-

Berechtigungen reduziert bzw. ausschaltet.

- Umgang mit (Standard-) Rollen und Standardprofilen (Hinweis: keine Verwen-

dung von Standardprofilen (=Auslieferungsprofile)

- Festlegung von Restriktionen einzelner Berechtigungen bezüglich der SOD (Seg-

regation of Duties und der Datentrennung (Hinweis: Berücksichtigung aller rele-

vanter Systeme und Mandanten)

- Realisierung des dazugehörigen organisatorischen Konzepts

- Trennung von kritischen und unkritischen Transaktionen

die Anforderungen an eine dem Zweckbindungsprinzip angemessene Abbildung der Un-

ternehmensorganisation(en) auf die SAP-Struktur/Organisationsebene von Systemen,

Mandanten, Buchungskreisen, Werken, Personalbereiche etc. Die Nutzung eines Mandan-

ten für mehrere Unternehmen ist eine Auftragsdatenverarbeitung und erfordert zusätzliche

Aufwendungen in den datenschutzkonformen Betrieb und in die Datentrennung.

ein Verfahren zur Klassifikation und Pflege von Berechtigungsgruppen von ABAP-

Reports und Tabellen und von Query-Benutzergruppen

die Namenskonventionen; Konventionen zur Benennung von Benutzerstammsätzen (keine

Namen ohne Personenbezug), Benutzergruppen, Rollen sowie anderer relevanter SAP-

Objekte (einschließlich Beschreibung begründeter Ausnahmen); Namensregeln für unter-

schiedliche Rollen wie Lese-Rollen, Rollen mit Zugriff auf bestimmte Organisationsein-

heiten, Transaktionsrollen etc..

Die Pflege der strukturellen Berechtigungen und der Zuordnung der Benutzerkennung zur

Personalnummer ( ITY 0105 und STY 001)

die Einrichtung von Notfall-Usern

die Festlegung der Berechtigungen für Externe und deren Kontrolle

der Umgang mit Sonder-Usern wie SAP*, DDIC, SAPCPIC, EarlyWatch, TMSADM,

SAPSUPPORT, WF-BATCH.

den Aufbau der Dokumentation; u.a. eindeutige Verantwortlichkeiten für die Veränderung

des Konzeptes bei notwendig werdenden organisatorisch-funktionalen Anpassungen

Konventionen für Nicht-Produktivsysteme, die Testdaten mit echten Daten oder wichtige

nachweispflichtige Dokumentationsbestandteile enthalten

Regelung für die Vergabe von Profilen (ohne Profilgenerator)

Regelungen für Berechtigungsprüfung bei der Nutzung von BAdI’s; insbesondere auch

für die BAdI’s, die die Wirkung der HR-Berechtigungsobjekte ändern.

Es lassen sich folgende Grundsätze ableiten:

Die Fachabteilungen/-bereiche sind für die Sicherheit ihrer Daten und daher auch für den

wirksamen Zugriffsschutz verantwortlich. Es sind regelmäßige Kontrollen der Angemes-

senheit der vergebenen Berechtigungen durch die Datenverantwortlichen vorzusehen.



Die Benutzerverwaltung ist möglichst nahe beim Benutzer wahrzunehmen.

Die Administration des Berechtigungsverfahrens sollte auf mehrere Stellen, Organisati-

onseinheiten oder Mitarbeiter verteilt und entsprechend dokumentiert werden (Funktions-

trennung zwischen Erstellen, Zuordnen und Kontrollieren/Prüfen).

Die Vergabe von Nutzerkennungen hat nachvollziehbar zu erfolgen (Vergabe von Berech-

tigungen im System ausschließlich nach Freigabe durch die Verantwortlichen), und es

müssen zeitnahe Kontrollen bzgl. der Gültigkeit von Benutzerkennungen vorgenommen

werden.

Benutzer dürfen auf Basis des fachlichen Rollenkonzeptes nur die Berechtigungen erhal-

ten, die sie für ihre Aufgaben zwingend benötigen.

Die Berechtigungen privilegierter Benutzer sollten fachlich und zeitlich eingegrenzt wer-

den (s. Kap. 4.2). Notfall-User sind nur in Notsituationen zu aktivieren, deren Gebrauch

ist mit dem Security Audit Log (SM20) oder anderen entsprechenden Tools zu protokol-

lieren.

Für Betriebsfremde und befristet Beschäftigte wie auch für den Remote Support sind die

Rechte und der Gültigkeitszeitraum angemessen zu begrenzen (vgl. SAP NetWeaver Si-

cherheitsleitfaden).

Anwendungsbezogene Berechtigungen für Entwickler sind grundsätzlich auf die Entwick-

lungssysteme zu beschränken.

Um bestehende Berechtigungskonzepte zu überprüfen und insbesondere Regeln für die

Vergabe von kritischen Berechtigungen zu definieren, können SAP Lösungen wie das Audit

Information System oder GRC Access Control verwendet werden (Details siehe Kapitel 6).

2.1.6 Mitwirkung bei der Festlegung des Betriebskonzeptes und der

Betreiberorganisation

Der DSB sollte rechtzeitig an der Erarbeitung eines organisatorischen Rahmens zur Ausge-

staltung des Betriebskonzeptes beteiligt werden. Unter einem Betriebskonzept wird hier die

grundlegende Einrichtung des SAP-Systems auf einem oder mehreren Servern und unter Ein-

beziehung der Kommunikationseinrichtungen, der Netzwerke, des Betriebssystems und des

Datenbankmanagements verstanden.

Dazu sollte der DSB frühzeitig Empfehlungen abgeben, die den Sicherheitsstandard auf den

verschiedenen Ebenen festlegen, der notwendig ist, Manipulationen und ungerechtfertigte

Zugriffe auf personenbezogene Daten zu verhindern.

Hierzu könnten Empfehlungen zu ausgewählten System- und Profilparametern ebenso gehö-

ren wie die Mitwirkung des DSB bei der Festlegung des Sicherheitsmanagements, z.B. bei

Prozessdefinitionen für Sicherheits- und Datenschutzanforderungen.

Eine ausführliche Beschreibung der hierbei relevanten Themen findet sich in den SAP-

Sicherheitsleitfäden. Hierbei wird z.B. folgendes Thema beschrieben:

Alleiniger Nutzer der Datenbank ist das SAP-System

Es ist darauf zu achten, dass auf die Datenbank nicht von unter dem SAP-System liegen-

den Schichten (wie etwa der Datenbank selbst oder dem Betriebssystem) zugegriffen

wird. Ansonsten könnte der SAP Berechtigungsschutz umgangen werden.



Es darf nur ein sehr eng begrenzter Kreis von Administratoren Zugriff auf Datenbankta-

bellen und SAP-Daten auf Betriebssystemebene erhalten.

Für den Betrieb eines SAP ERP-Systems wird im Regelfall eine Betreiberorganisation (BO,

verantwortlich für die spezifische Administration des SAP ERP-Systems) notwendig werden,

die insbesondere an Gewicht gewinnt, wenn mehrere Unternehmen/Behörden über ein System

abgewickelt werden sollen.

Die Betreiberorganisation kann dabei zentral oder dezentral oder durch eine Kombination von

beiden Alternativen organisiert werden.

Den Vorteilen einer dezentralen Betreiberorganisation wie die Nähe zum Anwender und

die flexible organisatorische Zuordnung der BO in den Unternehmen/Behörden oder die

Gewährleistung der Harmonisierung der Arbeitsabläufe stehen die Nachteile einer höhe-

ren Abstimmung der gesellschaftsübergreifenden Aktivitäten und operativen übergreifen-

den Fragestellungen sowie ein tendenziell höherer Personalbedarf als in einem rein zentra-

len Ansatz gegenüber.

Bei einem zentralen Ansatz ist eine eindeutige Kompetenzregelung mit klarer Organisati-

onsstruktur und schneller Entscheidung bei Konfliktfällen möglich. Allerdings kann die

Flexibilität der über das SAP-System abgewickelten Unternehmen/Behörden einge-

schränkt bzw. die Durchsetzung von gesellschaftsindividuellen Anforderungen bei über-

greifenden Einstellungen schwierig sein. Auch können Interessenkonflikte bei der Leitung

der BO nicht ausgeschlossen werden.

Der DSB hat insbesondere darauf zu achten, dass durch die Betreiberorganisation die Belange

des Datenschutzes hinsichtlich Vertraulichkeit und Sicherheit von personenbezogenen Daten

gewährleistet bleiben und bei einem zentralen Ansatz vertragliche Regelungen zwischen der

BO und den Unternehmen/Behörden den Datenschutzanforderungen genügt – bspw. die in §

11 BDSG verlangten Vertragsinhalte und Nachweise für die Auftragsdatenverarbeitung.

2.1.7 Abfassung einer Datenschutzerklärung

Sofern Dritten ein Internet-Zugang auf das SAP-System gewährt wird, ist der DSB an der Er-

stellung einer Datenschutzerklärung zu den anfallenden Geschäftsprozessen zu beteiligen.

Die Nutzer sind zu Beginn des Nutzungsvorgangs über Art, Umfang und Zwecke der Erhe-

bung sowie die Verwendung personenbezogener Daten und deren Verarbeitung zu unterrich-

ten, sofern eine solche Unterrichtung nicht bereits erfolgt ist (§ 13 Abs. 1 S. 1 TMG).

Diese Erklärung ist als vertrauensbildende Maßnahme zu verstehen und soll den Geschäfts-

partner in verständlicher Form über getroffene Standardmaßnahmen zum Schutz seiner Pri-

vatsphäre (Vertraulichkeit, Integrität, Authentizität) informieren. Eine Hilfestellung bietet der

OECD Privacy Statement Generator unter folgender URL:

http://www.oecd.org/sti/privacygenerator

2.1.8 Überwachung des Korrektur- und Transportwesens unter SAP

ERP

Um Integrität und Verfügbarkeit des Produktivsystems zu schützen, ist eine Trennung in ver-

schiedene Systeme notwendig, wobei unter Sicherheitsaspekten mindestens eine Dreiteilung

in Entwicklungs-, Integrations- und Produktivsystem zu empfehlen ist. Die drei Systeme sind

über das Korrektur und Transportsystem (Change & Transport System) miteinander verbun-

http://www.oecd.org/sti/privacygenerator



den. Eine Beschreibung der hierbei zu ergreifenden Schutzmaßnahmen findet sich in den SAP

Sicherheitsleitfäden.

Beispielsweise wird darauf hingewiesen, dass - zur Vermeidung von unbefugtem Einschleu-

sen von Programmen oder Daten über das SAP ERP-Transportsystem in das Produktivsystem

- eine Abschottung gegenüber Test- und Entwicklungssystemen erforderlich ist. Es wird emp-

fohlen, den produktiven Applikations- und Datenbankrechner ausschließlich der SAP ERP-

Anwendung zuzuordnen und aus Sicht des Netzwerkes über ein eigenes Transportsystem zu

verfügen.

Der DSB hat darauf zu achten, ob/wie Kopien von personenbezogenen Daten in Nicht-

Produktivsysteme transportiert werden bzw. Benutzer- und Berechtigungswerte aus vorgela-

gerten Systemen in das Produktivsystem gelangen, ohne inhaltlich abgestimmt zu sein.

Hinweis: Hierbei ist ein Datenschutz gerechtes Entsorgungskonzept für Test- bzw. nicht mehr

benötigten Produktiv-Output (z.B. Papier, Datenträger) festzulegen (z.B. DIN 66399).

2.1.9 Kontrollen im laufenden Betrieb

Zur Überwachungsaufgabe des DSB gehören sowohl regelmäßige als auch unangemeldete

Kontrollen und Stichproben im Hinblick auf die Organisation des Betriebsablaufes, die not-

wendigen Funktionstrennungen und die Handhabung des Zugriffsberechtigungskonzeptes als

auch die Auswertung der Logfiles. Vergleiche hierzu auch die Bemerkungen zu den Zugriffs-

rechten des DSB zum Security Audit Log (Kapitel 4.2.1.9.1) und zum Audit Information Sys-

tem in Kapitel 6.Schulung der Anwender mit Verpflichtung auf das Datengeheimnis (§§ 4g

und 5 BDSG).

2.2 Schulung der Anwender mit Verpflichtung auf das Datengeheimnis (§§ 4g und 5 BDSG)

2.2.1 Personenkreis, der geschult und verpflichtet werden muss

Bei Aufnahme der Tätigkeit sind die bei der Erhebung, Verarbeitung und Nutzung personen-

bezogener Daten tätigen Personen zu schulen (§ 4g Abs. 1 S. 4 Nr. 2 BDSG) und auf das Da-

tengeheimnis zu verpflichten (§ 5 BDSG). Dabei handelt es sich im Wesentlichen um folgen-

den Personenkreis:

Mitarbeiter in Rechenzentren / IT-Mitarbeiter

Mitarbeiter in Fachabteilungen mit personenbezogenen Daten, z.B.

- Personalabteilung, Lohn- und Gehaltsabrechnung, Zeitwirtschaft

- Verkauf, Marketing, Werbung

- Einkauf

- Controlling

- Compliance

- Boten

- Projektmitglieder



Zu verpflichten sind auch Teilzeitkräfte und Auszubildende / Praktikanten. Betriebsratsmit-

glieder fallen ebenfalls unter das Datengeheimnis des § 5 BDSG.

Mitarbeiter von Fremdfirmen, z.B. externe Berater, die Zugriff zu personenbezogenen Daten

haben, müssen auf das Datengeheimnis verpflichtet sein. Der Datenschutzbeauftragte kann

die Verpflichtung dieser Mitarbeiter nicht selbst vornehmen, er sollte sich aber die Verpflich-

tung vertraglich zusichern lassen und deren Einhaltung kontrollieren.

2.2.2 Inhalt der Anwenderschulungen

Der Anwender soll durch die Schulung mit den Vorschriften des BDSG und allen für die

Fachaufgabe einschlägigen Datenschutzvorschriften vertraut gemacht werden. Die Anwen-

derschulung soll allgemeine Informationen zum Datenschutzrecht und auf den jeweiligen Tä-

tigkeitsbereich abgestimmte Hinweise geben, insbesondere zu Datensicherheit und Ord-

nungsmäßigkeit der Datenverarbeitung. Ziel der Schulung ist es, den einzelnen für daten-

schutzgerechtes Verhalten am Arbeitsplatz zu befähigen.

Neben oder als Ergänzung zu Präsenz-Schulungen können auch PC-gestützte oder Web-

basierte Anwenderschulungen verwendet werden, , beispielsweise als Basis-Schulung oder

auch zur Vertiefung des Wissens.

Nach erfolgter Schulung sind die Teilnehmer auf das Datengeheimnis schriftlich zu verpflich-

ten. Diese Verpflichtungserklärung (Anlage 8.1) sollte Bestandteil der Personalakte werden.

Empfehlenswert ist es, jedem Schulungsteilnehmer die entsprechenden Auszüge aus dem

BDSG sowie ein Merkblatt zum Umgang mit personenbezogenen Daten (Anlage 8.2) auszu-

händigen.

Als Beispiel kann der SAP-Hinweis 35493, Verpflichtung Datenschutz und Geheimhaltung,

dienen.

2.2.3 Abbildung der Anwenderschulung im SAP

2.2.3.1 Anwenderschulung über Infotypen “Belehrungen” oder

“Qualifizierungen”

Für HCM-Anwender besteht die Möglichkeit, die Anwenderschulung mit Verpflichtung auf

das Datengeheimnis im SAP ERP-System im Personalstammsatz zu hinterlegen.

Vom Datenschutzbeauftragten bzw. von der Personalabteilung kann die Schulung zum Daten-

schutz folgendermaßen eingetragen werden:

Menüpfad:

Personal -> Personalmanagement -> Administration -> Personalstamm -> Pflegen

(PA30).

Verwendet werden kann der Infotyp 0035 (Belehrungen) oder die Qualifikation im Profil ei-

ner Person in der Personalentwicklung (durch Aufruf Infotyp 0024; Achtung: hierzu muss im

Customizing der Schalter PLOGI APPRA in der Tabelle T77S0 auf 1 stehen).

Der Infotyp “Qualifikationen” greift auf den Qualifikationskatalog zurück. Darin muss dann

im Rahmen des Customizing die Anwenderschulung aufgenommen werden.

Menüpfad:



Personal -> Personalmanagement -> Personalentwicklung -> Einstellungen -> lau-

fende Einstellungen -> Qualifikationskatalog bearbeiten (OOQA)

Der Qualifikationskatalog hat eine Baumstruktur. Die Datenschutzschulung kann z.B. unter

dem Zweig “rechtliche Grundlagen” angelegt werden.

Mit dem Report RHSTRU00 erfolgt die Strukturauswertung des Qualifikationskataloges.

Über den Report RHXQALIF (Qualifikation eines/mehrerer Teilnehmer) lässt sich leicht

auswerten, wer bereits auf die Einhaltung des Datenschutzes verpflichtet ist und an welchen

Schulungen er teilgenommen hat. Der Report bietet auch die Möglichkeit, nach Organisati-

onseinheiten auszuwerten. Ein Vergleich zwischen Mitarbeitern einer Abteilung (z.B. Perso-

nal-Abt., EDV-Abt. usw.) mit den verpflichteten Personen zeigt die Differenzen auf. Ein be-

sonderes Augenmerk ist auf Neueinstellungen bzw. Umsetzungen von Mitarbeitern zu rich-

ten.

Empfehlung: Unternehmen, die nicht das HCM-Organisationsmanagement und die HCM-

Personalentwicklung einsetzen, sollten den Infotyp 0035 (Belehrungen) benutzen. Alle ande-

ren können auch den oben beschriebenen Weg über die Qualifizierungen im Profil einer Per-

son verwenden.

2.2.3.2 Anwenderschulung über das Veranstaltungsmanagement

Für Anwender, die das Veranstaltungsmanagement nutzen, empfiehlt es sich, mit diesem In-

strument die gesamte Organisation der Anwenderschulungen abzuwickeln.

Über das Veranstaltungsmanagement kann die Planung, Durchführung und Verwaltung von

Veranstaltungen organisiert werden. So können z.B. die Teilnehmer der Schulung, Ort und

Zeit, Referenten usw. geplant und abgerechnet werden.

2.3 Führen von Übersichten (§ 4g Abs. 2 / § 18 Abs. 2 BDSG)

In der Phase des Customizings wird festgelegt, welche Daten erfasst und gespeichert werden

sollen. In diesem Falle wirkt der DSB aktiv an der Umsetzung datenschutzrechtlicher Anfor-

derungen mit.

Für die effektive Wahrnehmung seiner Aufgaben benötigt der DSB nach den §§ 4e und 4g

Abs. 2 BDSG folgende Unterlagen:

§ 4g Aufgaben des Beauftragten für den Datenschutz

(2) Dem Beauftragten für den Datenschutz ist von der verantwortlichen Stelle eine

Übersicht über die in § 4e S. 1 genannten Angaben sowie über zugriffsberechtigte

Personen zur Verfügung zu stellen. Der Beauftragte für den Datenschutz macht die

Angaben nach § 4e S. 1 Nr. 1 bis 8 BDSG auf Antrag jedermann in geeigneter Weise

verfügbar.

§ 4e Inhalt der Meldepflicht

Sofern Verfahren automatisierter Verarbeitungen meldepflichtig sind, sind folgende

Angaben zu machen:

1. Name oder Firma der verantwortlichen Stelle



2. Inhaber, Vorstände, Geschäftsführer oder sonstige gesetzliche oder nach der Ver-

fassung des Unternehmens berufene Leiter und die mit der Leitung der Datenver-

arbeitung beauftragten Personen

3. Anschrift der verantwortlichen Stelle

4. Zweckbestimmungen der Datenerhebung, -verarbeitung oder -nutzung

5. eine Beschreibung der betroffenen Personengruppen und der diesbezüglichen Da-

ten oder Datenkategorien

6. Empfänger oder Kategorien von Empfängern, denen die Daten mitgeteilt werden

können

7. Regelfristen für die Löschung der Daten

8. eine geplante Datenübermittlung in Drittstaaten

9. eine allgemeine Beschreibung, die es ermöglicht, vorläufig zu beurteilen, ob die

Maßnahmen nach § 9 zur Gewährleistung der Sicherheit der Verarbeitung ange-

messen sind

Die öffentlichen Stellen haben nach § 18 Abs. 2 BDSG inhaltlich weitgehend ähnliche Anga-

ben zu machen, sind aber per Gesetzestext auf die schriftliche Dokumentation verpflichtet.

§ 18 Durchführung des Datenschutzes in der Bundesverwaltung

(2) Die öffentlichen Stellen führen ein Verzeichnis der eingesetzten Datenverarbei-

tungsanlagen. Für ihre automatisierten Verarbeitungen haben sie die Angaben nach

§ 4e sowie die Rechtsgrundlage der Verarbeitung schriftlich festzulegen. Bei allge-

meinen Verwaltungszwecken dienenden automatisierten Verarbeitungen, bei welchen

das Auskunftsrecht des Betroffenen nicht nach § 19 Abs. 3 oder 4 eingeschränkt wird,

kann hiervon abgesehen werden. Für automatisierte Verarbeitungen, die in gleicher

oder ähnlicher Weise mehrfach geführt werden, können die Festlegungen zusammen-

gefasst werden.

Wegen der weitgehend identischen Anforderungen im öffentlichen Bereich des Bundes und

nicht-öffentlichen Bereich orientieren sich die folgenden Ausführungen an den Aufgaben des

DSB nach § 4g BDSG.

In diesem Zusammenhang sei auch auf die EU-Richtlinie 95/46/EG (Abschnitt IX, Artikel 18

ff) verwiesen, in der fast wortgleiche Anforderungen gestellt werden.

Wenn der DSB im o.a. Zusammenhang auch die Ressourcen der IT-Sicherheit in Anspruch

nehmen will, kann er ggf. auf die Prüfung des IT-Sicherheitsmanagements im Rahmen der

ISO/IEC 27001 im Unternehmen zurückgreifen. Dort wird u.a. eine Erhebung der IT-Systeme

und eine Liste der IT-Anwendungen (Software, Anwendungsprogramme, Geschäftsprozesse)

sowie weitere Angaben (zuständige Administratoren; personenbezogene Daten) gefordert.

Dies bietet die Grundlage für das betriebsinterne Verfahrensverzeichnis.

2.3.1 Verantwortlichkeiten

Im Rahmen der Novellierung des BDSG im Jahre 2001 wurde die Aufgabenteilung zwischen

der DV-Abteilung und dem DSB der Realität angepasst: Die speichernde Stelle wurde in ver-

antwortliche Stelle umbenannt. Des Weiteren hat der DSB nunmehr auf die Einhaltung der

Befolgung der Gesetze und Vorschriften zum Datenschutz hinzuwirken (§ 4g Abs. 1 S. 1

BDSG). Für jeden Mitarbeiter, insbesondere aber für die Verantwortlichen der DV-Systeme

gilt:



Die Betreiber der Systeme (Anwendungs- und Systemverantwortliche) sind für die Einhaltung

der Gesetze und Vorschriften zum Datenschutz und zur Datensicherung verantwortlich. Die

verantwortliche Stelle hat u.a. Maßnahmen zu treffen, dass die Daten

- nur rechtsmäßig und zweckgebunden verarbeitet werden

- sachlich richtig und aktuell sind

- nicht länger als für den Zweck erforderlich aufbewahrt werden

- vor unerlaubtem Zugriff und Manipulationen geschützt werden

- nicht ohne ihre vorherige Zustimmung an Dritte weitergeleitet werden

Des Weiteren ist jeder Einzelne dafür verantwortlich, dass die ihm anvertrauten personenbe-

zogenen Daten nur im Rahmen seiner Aufgabenstellung verarbeitet und genutzt werden.

Jeder Missbrauch, jede unzulässige Weitergabe dieser Daten ist verboten und kann sowohl

arbeitsrechtliche Konsequenzen nach sich ziehen als auch bei Vorliegen der Vorrausetzungen

als Ordnungswidrigkeit oder Straftatbestand verfolgt werden.

Es bietet sich an, diese Klarstellung den Verantwortlichen mit der Aufforderung zur Erstel-

lung der Übersichten zukommen zu lassen.

2.3.2 Form der Dokumentation

Während der Inhalt der Übersichten in den §§ 4e und 4g BDSG detailliert beschrieben ist,

wird zur Form der Dokumentation im Gesetzestext keine Aussage getroffen. Für das SAP

ERP-System ist eine Kombination von schriftlichen Übersichten (z.B. Aktenvermerken) und

Verweisen auf die elektronische Dokumentation (z.B. ABAP Dictionary, AIS) sinnvoll. Hier-

für bietet sich an, die Dynamik des SAP-Systems zu nutzen und sich einzelne Details dann zu

besorgen, wenn sie benötigt werden. Die vom Gesetzgeber vorgeschriebenen Mindestinhalte

müssen allerdings stets in aktueller Form vorliegen.

Im Zentrum der Dokumentation stehen die Meldedaten nach § 4e BDSG, ergänzt um die zu-

griffsberechtigten Personen.

Es muss zu folgenden Zwecken dem DSB von der verantwortlichen Stelle zur Verfügung ge-

stellt werden:

Angaben zum Inhalt der Meldepflicht nach § 4e BDSG

Auf Antrag muss der DSB die Angaben 1 bis 8 nach § 4g Abs. 2 BDSG Jedermann

verfügbar machen.

Die Vorabkontrolle ist bei besonderen Risiken nach Empfang der Übersichten vorzu-

nehmen.

Der DSB benötigt die Übersichten, um die ordnungsgemäße Verarbeitung personen-

bezogener Daten nach § 4g Abs. 1 S. 4 Nr. 1 BDSG zu überwachen.

Benachrichtigung des Betroffenen nach den §§ 19a, 28b und 33 BDSG

Unterrichtung der Betroffenen bei Erhebung nach § 4 Abs. 3 BDSG

Auskunft an Betroffene nach den §§ 19 und 34 BDSG

Auskünfte gegenüber der Aufsichtsbehörde gemäß § 38 Abs. 3 S. 1 BDSG

Der Inhalt der Übersichten muss sich nach dem Verwendungszweck richten. Aus diesem

Grund ist es sinnvoll, die Übersichten in ein öffentliches Melderegister auf der Basis von § 4g



Abs. 2 BDSG in Verbindung mit § 4e S. 1 Nr. 1-8 BDSG und ein betriebsinternes Verfah-

rensverzeichnis - indem darüber hinaus die Angaben gemäß § 4e S. 1 Nr. 9 und § 4g Abs. 2

BDSG enthalten sind - zu unterteilen, die verschiedene Funktionen erfüllen. Eine gesetzliche

Verpflichtung betreffend eine Aufspaltung in ein öffentliches Melderegister und ein betriebs-

internes Verfahrensverzeichnis besteht jedoch nicht.

2.3.3 Das öffentliche Melderegister

Das öffentliche Melderegister ist die Grundlage für die Auskunft an Jedermann und, soweit

notwendig, die Meldung an die Aufsichtsbehörde.. Das öffentliche Melderegister soll allge-

meine gesellschaftliche Transparenz gewährleisten, um im Vorfeld von Auskunftsansprüchen

Orientierungswissen darüber zu geben, wer welche Daten speichert.

Meldungen sollten kurz und verständlich sein, wie die Darstellung des unabhängigen Landes-

zentrums für Datenschutz Schleswig-Holstein beispielhaft zeigt (vgl. 2.3.5).

Detaillierungsgrad

Die Informationen sind dem DSB als Übersichten von der verantwortlichen Stelle zur Verfü-

gung zu stellen. Auch die Begriffe Personengruppen, Datenkategorien und Kategorien von

Empfängern lassen darauf schließen, dass detaillierte Beschreibungen in diesen Übersichten

nicht notwendig sind. Da das öffentliche Melderegister auch jedermann in geeigneter Weise

verfügbar gemacht werden muss, ist eine genaue Beschreibung von Einzeldaten, Personen

oder Empfängern für die Außendarstellung nicht angebracht. Schließlich zeigt der Ausschluss

der ergriffenen Sicherungsmaßnahmen in § 4g Abs. 2 BDSG, dass die Offenbarung der Daten

nicht zu einem Risiko für das verarbeitende Unternehmen werden darf.

2.3.4 Das betriebsinterne Verfahrensverzeichnis

Das betriebsinterne Verfahrensverzeichnis dagegen dient dem Datenschutzbeauftragten dar-

über hinaus zur internen Prüfung, der Vorabkontrolle, der Identifizierung der zugriffsberech-

tigten Personen gemäß § 4g Abs. 2 S. 1 BDSG sowie der Prüfung der Angemessenheit der

Maßnahmen nach § 9 S. 2 BDSG und ist Grundlage zu speziellen Auskunftsanforderungen

von betroffenen Personen. Speziell bei sensiblen Daten nach § 3 Abs. 9 BDSG wie Angaben

über Gesundheit ist eine detailliertere Übersicht erforderlich.

In vielen Fällen muss dabei Detailwissen zur Person zur Verfügung gestellt werden, wobei die

einschlägigen SAP-Funktionalitäten (z.B. ABAP Dictionary, AIS) zur Unterstützung heran-

gezogen werden können.

Die Übersichten müssen auf der anderen Seite für den DSB ein geeigneter Ansatz sein, um für

verschiedene Zwecke eine Detailanalyse vornehmen zu können:

Bei der Vorabkontrolle benötigt der DSB in vielen Fällen neben der Tabellen-/Info-

/Subtypbeschreibung auch Einblick in die Beschreibung der Datenfelder z.B. bei Speiche-

rung von Gesundheits- oder Leistungsdaten.

Bei Überwachung der datenschutzgerechten Verarbeitung muss der DSB mit Unterstüt-

zung der Verantwortlichen und/oder auf Grundlage der Dokumentation im Einzelfall bis

auf Feldebene vordringen können.

Die Benachrichtigung umfasst die Identität des Verarbeiters, die Zweckbestimmung, Ka-

tegorien von Empfängern und die Art der Daten.



Die Betroffenen sind bei Erhebung über die Identität der verantwortlichen Stelle, die

Zweckbestimmung der Erhebung und die Kategorien von Empfängern zu unterrichten,

wenn sie nicht bereits auf andere Weise Kenntnis erlangt haben.

Die Auskunft verlangt exakte Informationen über die zu einer Person gespeicherten Daten

und deren Herkunft, die Empfänger und den Zweck der Speicherung

Zur Beurteilung der § 9 BDSG-Maßnahmen zur Gewährleistung der Sicherheit der Verar-

beitung sind detaillierte Angaben über die gespeicherten Daten und deren Verarbeitungs-

zwecke erforderlich.

Aus dieser Zusammenstellung ist ersichtlich, dass auch Auskunft und Benachrichtigung sich

auf Punkte der Übersichten beziehen.

Zur Tabellen- oder Feldanalyse kann im SAP ERP das ABAP Dictionary genutzt werden. Der

Umgang mit Domänen, Tabellen, Reports und Verwendungsnachweisen erfordert vom DSB

handwerkliches Geschick. Wegen der Vorabkontrolle muss man gegebenenfalls bis auf das

sensitive Datum selbst herunterbrechen, z.B. Felder im Infotyp 0002 (Daten zur Person; Da-

tenfeld Familie, Anzahl der Kinder Konfession), Infotyp 0004 (Behinderung), Infotyp 0028

(Werksärztlicher Dienst), oder Infotyp 0077 (zusätzliche Daten zur Person, mit ethnischer

Herkunft, Konfessionsschlüssel oder Veteran Status). In Abschnitt 2.4 wird dargestellt, wie

man zum Inhalt und zur Dokumentation von Feldern und Prüftabellen kommt.

Es ist zu beachten, dass nicht alle erforderlichen Angaben elektronisch im SAP ERP-System

vorhanden sind. Der pauschale Verweis auf das ABAP Dictionary bzw. das AIS-

‚Dateiregister’ etwa greift zu kurz, wenn nicht ergänzende schriftliche Unterlagen vorhanden

sind. So gibt es z.B. keine Kennzeichnung für Tabellen bzw. Datenfelder mit personenbezo-

genen Daten. Zweckbestimmung, Empfänger oder zugriffsberechtigte Personen werden in der

Regel auch nicht im Zusammenhang mit der Beschreibung von Daten oder Datenkategorien

im SAP ERP dokumentiert.

2.3.4.1 Informationen zur verantwortlichen Stelle

Hier werden die Punkte eins bis drei des öffentlichen Melderegisters zusammengefasst. Die

Informationen über den Firmennamen, die Anschrift und die Geschäftsleitung eignen sich am

besten zu einer Internet-Darstellung in einer Art Impressum.

2.3.4.2 Zweckbestimmungen der Datenerhebung, -verarbeitung oder -

nutzung

Anforderung:

§ 4e BDSG verlangt eine Angabe zu den Zweckbestimmungen der Datenerhebung, -

verarbeitung oder -nutzung.

Auslegung der gesetzlichen Anforderung in Bezug auf SAP ERP:

Auch wenn das BDSG davon ausgeht, dass die Rechtsgrundlage der Verarbeitung für alle Da-

ten - d.h. für jedes einzelne Datenfeld - gegeben sein und auch insofern vor der Verarbeitung

geprüft werden muss, so kann daraus nicht gefolgert werden, dass auch die Dokumentation

feldbezogen zu erfolgen hat.

Die Frage, ob zusätzlich die Rechtsgrundlage direkt mit in die Übersicht aufzunehmen ist,

wird sehr unterschiedlich beantwortet.



Vom Hersteller des SAP ERP-Systems darf der Anwenderbetrieb keine allgemeingültigen

Angaben zu den Rechtsgrundlagen erwarten, da im Einzelfall verschiedene bereichsspezifi-

sche Gesetze, Tarifverträge, Betriebsvereinbarungen, Einwilligungen oder im Falle des § 28

Abs. 1 S. 1 Nr. 1 BDSG die verschiedensten Vertragsverhältnisse in Frage kommen.

Die Angabe der Geschäftszwecke muss im Unternehmen aus Sicht der Fachabteilung defi-

niert werden, z.B. Finanzbuchhaltung, Personalabrechnung, Bewerberverwaltung, Reisekos-

tenabrechnung.

2.3.4.3 Beschreibung der betroffenen Personengruppen und der

diesbezüglichen Daten oder Datenkategorien

Anforderung:

Alle betroffenen Personengruppen und deren Daten oder Datenkategorien sind aufzuführen.

Dabei ist von dem datenschutzrechtlichen Begriff der automatisierten Verarbeitung auszuge-

hen und nicht vom EDV-technischen Dateibegriff. Die Beziehung zu den Bezeichnungen auf

Datenbank- oder Betriebssystemebene sollte nachvollziehbar sein, muss aber nicht zwingend

in die Übersicht mit aufgenommen werden. Benutzerdaten sind auch aufzunehmen (siehe un-

ten).

SAP-Fakten:

SAP ERP baut bei der Datenhaltung auf den Diensten relationaler Datenbanksysteme auf.

Über relationale Verknüpfungen von Tabellen können Daten auf unterschiedlichen Ebenen

aggregiert und zu neuen Aussagen verknüpft werden.

Im Audit Information System findet sich eine Dokumentationsmöglichkeit für Daten bzw.

Tabellen des ABAP Dictionary bestimmter Personengruppen. Dort wird nach folgenden Per-

sonengruppen differenziert:

Mitarbeiterdaten (HCM-Daten)

Bewerberdaten (HCM -Daten)

Lieferantendaten

Kundendaten

Partnerdaten

Sachbearbeiterdaten

Verkäufergruppendaten

Patientendaten

SAP-Benutzer (Stammdaten der Benutzerverwaltung)

Diese Personengruppen sind in verschiedenen Report-Varianten in der Mappe ‚Dateiregister

zu personenbezogenen Daten’ (Report RSCRDOMA) zusammengefasst. Die für diese Perso-

nengruppen verwendeten Tabellen können direkt im AIS angezeigt werden.

Allerdings basiert das AIS noch auf der Sprachregelung des ‚alten BDSG’, verwendet Be-

grifflichkeiten wie ‚Dateiregister’ und bietet bisher keinerlei Informationen über die perso-

nenbezogenen Daten in der Java-Welt. Die bekannten Domänen mit Personenbezug sind im

AIS nicht vollständig abgebildet.



Außerdem bietet das SAP ERP-System weitere Funktionen für die Dokumentati-

on/Beschreibung von Daten (z.B. im ABAP Dictionary), die im Abschnitt 2.4 detaillierter

dargestellt werden.

Auslegung der gesetzlichen Anforderung in Bezug auf SAP ERP:

§ 4g BDSG in Verbindung mit § 4e S. 1 Nr. 5 BDSG verlangt von der verantwortlichen Stel-

le, dem Datenschutzbeauftragten u.a. eine Beschreibung der betroffenen Personengruppen

und der diesbezüglichen Daten oder Datenkategorien zur Verfügung zu stellen.

Es stellt sich die Frage, wie genau die Personengruppen und die diesbezüglichen Daten do-

kumentiert werden müssen. Das BDSG überlässt es der verantwortlichen Stelle, so dass so-

wohl die Bildung von Datenkategorien als auch die Auflistung einzelner Datenfelder möglich

ist. Was nötig ist, muss im Einzelfall entschieden werden und sollte davon abhängig gemacht

werden, zu welchem (Dokumentations-/Auskunfts-) Zweck die Angaben verwendet werden

sollen.

Allerdings erfordert § 4e S. 1 Nr. 9 BDSG eine Beschreibung, auf deren Grundlage eine Beur-

teilung von Sicherheitsmaßnahmen ermöglicht werden soll. Diese Beurteilung macht z.B. im

HCM eine Betrachtung der Daten bis auf die Ebene des einzelnen Infotyps (bzw. der Data

Dictionary-Tabelle) erforderlich.

Personenbezogene Daten werden in unterschiedlichen Zusammenhängen im SAP ERP-

System gespeichert. Im Rahmen der Personalwirtschaft (HCM) finden sich die Mitarbeiterda-

ten. Sachbearbeiter- bzw. Benutzerdaten werden in vielfachen Anwendungszusammenhängen

verwendet und auch Kunden-/Lieferanten-Daten werden hinterlegt.

Im SAP ERP-System können Daten über eine Person im Zusammenhang mit deren verschie-

denen „Rollen“ auftauchen, z.B. im Rahmen der Gehaltsabrechnung oder als Buchhaltungs-

sachbearbeiter. Die im Audit Information System getroffene Unterscheidung verschiedener

Personengruppen bzw. „Rollen“ ist durchaus geeignet, die entsprechenden Anforderungen des

BDSG zu erfüllen.

Die zu einer Personengruppe gehörigen Daten können im AIS unter der jeweiligen Rubrik

abgefragt werden, wobei auf Wunsch eine Liste nicht leerer Tabellen mit Kennzeichnung der

abgefragten Domäne angezeigt wird. Eine Liste nicht leerer Tabellen ist gleichzusetzen mit

tatsächlich verwendeten Tabellen eines konkreten Systems. Im Zusammenhang mit den Mit-

arbeiterdaten sind dies die entsprechenden Infotypen.

Die Personalstammdaten (Tabellen PA0*) unterscheiden sich i.d.R. hinsichtlich Zweckbe-

stimmung, Zugriffsberechtigung und regelmäßigen Empfängern oder lassen sich zumindest in

Gruppen aufteilen. Die Infotypen im HCM-Modul sind zudem bereits überwiegend nach per-

sonalwirtschaftlich-fachlichen Kriterien (z.B. Anschriften, Darlehen, DEÜV) strukturiert.

Daher spricht einiges dafür, die Tabellen des SAP ERP-Systems weiterhin als Grundlage der

Dokumentation zu wählen. Diese Vorgehensweise hat Vorteile, denn die Prüfung, welche Ta-

bellen sinnvollerweise zusammengefasst werden sollten, entfällt, und die zusätzlichen Anga-

ben der Übersichten nach § 4 BDSG können den im System definierten Tabellen direkt zuge-

ordnet werden. Auch aus Praktikabilitätsgründen bietet sich diese einheitliche und systemna-

he Dokumentation an, denn dabei kann auf einfache Weise auf die im System hinterlegten In-

formationen zurückgegriffen werden.

Im SAP ERP-Einführungsprojekt ist zu Beginn der Customizing-Phase unter Einbeziehung

des Datenschutzbeauftragten festzulegen, welche personenbezogenen Daten zulässig sind.

Hierbei sind insbesondere auch die Beteiligungsrechte von Betriebs- und Personalräten zu be-

achten. In der Customizing-Phase bietet es sich an, eine erste Version der Übersichten zu er-

stellen.



Auch Benutzerdaten sind personenbezogene Daten und daher in die Übersichten mit aufzu-

nehmen. Dazu zählen

Sachbearbeiterkennzeichen, z.B. im Rahmen des Moduls FI

Protokolldaten, z.B. in der Workload Analysis (STAD)

Verwaltungsdaten, z.B. der anlegende, ändernde SAP-Benutzer

Daten von Dritten, z.B. bestellender Sachbearbeiter eines Kunden

Personenbezogene Daten, die ausschließlich Zwecken der Datenschutzkontrolle, der Datensi-

cherung oder der Sicherstellung eines ordnungsgemäßen Betriebs einer Datenverarbeitungs-

anlage dienen, unterliegen nach § 31 BDSG einer besonderen Zweckbindung, was insbeson-

dere der Verstärkung des Schutzes der Betroffenen dienen soll.

Bei Verwendung von Sachbearbeiterkennzeichen ist nur die Tatsache der Verarbeitung,

nicht der Inhalt des verarbeiteten Datensatzes ein personenbezogenes Datum. Wenn z.B. ein

Sachbearbeiter die Adresse eines Kunden eingibt und dabei sein Sachbearbeiterkennzeichen

(z.B. ein Namenskürzel) gespeichert wird, so ist das personenbezogene Datum “Mitarbeiter A

hat am 3. Februar den Datensatz X ergänzt“. Die Adresse des Kunden ist kein personenbezo-

genes Datum des Sachbearbeiters. Da nur die Tatsache der Verarbeitung (und nicht der Inhalt

der Datensätze) entscheidend ist, muss auch nur dies in den Übersichten dokumentiert wer-

den. Es sollte daher für das SAP ERP-System ausreichen, alle Tabellen, die Sachbearbeiter-

kennzeichen enthalten, aufzulisten und gemeinsam zu dokumentieren.

Auch Protokolldateien (siehe hierzu auch Abschnitt 2.3.4.5) sind in die Übersichten aufzu-

nehmen. Da es sich im Allgemeinen um Mitarbeiterdaten handelt, unterliegt die Verarbeitung

dieser Daten der Mitbestimmung nach § 87 Abs. 1 Nr. 6 BetrVG bzw. § 75 Abs. 3 Nr. 17

BPersVG.

2.3.4.4 Empfänger oder Kategorien von Empfängern

Grundsätzlich sind von der verantwortlichen Stelle im Verfahrensverzeichnis die Empfänger

oder Kategorien von Empfängern im SAP ERP-System zu nennen. Empfänger ergeben sich

aus Verträgen mit Mitarbeitern, Lieferanten und Kunden (Bankverbindung) sowie aus gesetz-

lichen Grundlagen (Sozialversicherung, Finanzamt, DEÜV usw.).

Informationen über theoretisch zu erreichende Empfänger im SAP ERP sind an vielen Stellen

verteilt. Bankverbindungen sind z.B. im Bankenstamm (Tabelle BNKA) hinterlegt (siehe

auch SAP-Prüfleitfaden R/3 FI, Kapitel Rechnungsprüfung und Zahlungslauf). Weiterhin fin-

det man sie im Lieferantenstamm (LFBK) oder im Modul HCM im Infotyp 0009 (Bankver-

bindung, Tabelle PA0009).

Im Einführungsprojekt sind die erlaubten Schnittstellen mit dem DSB abzusprechen und in

der Projektdokumentation festzuhalten. Ob und wie diese Empfänger erreicht werden, ist or-

ganisatorisch in einem Datenflussplan festzuhalten.

Übermittlungen im Sinne des BDSG können SAP-technisch auf sehr unterschiedliche Weise

realisiert werden.

In einer Ein-Mandanten-Installation für einen Konzern kann die Übermittlung bereits durch

die Erteilung von Buchungskreis bzw. Personalbereich übergreifenden Zugriffsrechten erfol-

gen, da Regelungen zur Datentrennung nicht wirksam werden können.



Eine Übermittlung kann aber auch durch die Übersendung von Daten von einem System zu

einem anderen System erfolgen, beispielsweise wenn beide Systeme zu unterschiedlichen

verantwortlichen Stellen gehören.

Abhängig von der jeweiligen technischen Realisierung gibt es unterschiedliche Wege, die

technische Realisierung nachzuvollziehen. Diese sind im Folgenden beispielhaft aufgeführt.

Welche Hilfen bietet SAP an, um die regelmäßigen Empfänger zu ermitteln?

Technische Verbindungen

Transaktion SM59 (RFC-Destination), Transaktion BD64 (Verteilungsmodellpflege), Ba-

sis-Services (BC-SRV) und SM54 (CPIC-Destination); weitere Verbindungen (SAP

NetWeaver Exchange Infrastructure, SAP XI (Nachfolger: SAP NetWeaver Process In-

tegration, PI)) überprüfen

Welchen Überblick bietet SAP ERP über Systeme und Komponenten an?

Verzeichnis der verfügbaren SAP-Systeme mit den entsprechenden Transportschichten

(SE17, Tabelle TSYST oder AIS/Transport Management System)

Tabelle Logische Systeme (Mandanten; Tabelle TBDLS)

Übersicht zu Mandanten und Benutzern eines SAP-Systems

Programm: RFAUDI06: Anzahl Benutzer je Mandant

Übersicht Mandanten

Tabelle T000 (SCC4)

Kostenrechnungskreise

Tabelle TKA01

Übersicht Buchungskreise

Tabelle T001

Personalbereiche

Tabelle T500P

Komponentenhierarchie (SB01 bzw. HIER)

Systemlastmonitor Transaktion ST03N (Genutzte Komponenten - Monatssicht in Trans-

aktion ST03N; ein mittelbarer Rückschluss über die Verwendung ist möglich)

Genutzte Datentabellen

Transaktion ST10

Object Navigator (SE84)

Menüpfad:

Werkzeuge -> ABAP Workbench -> Übersicht -> Infosystem -> ABAP Dictionary -> Da-

tenbanktabelle bzw. Programmbibliothek -> Programme /Teilobjekte zu Programmen ->

Dynpros

Data Browser (SE17)

Menüpfad:

Werkzeuge -> ABAP Workbench-> Übersicht -> Data Browser -> Tabellenname



Object Navigator (SE80)

Menüpfad:

Werkzeuge -> ABAP Workbench -> Übersicht -> Object Navigator

Über das Dictionary und die dort aufrufbaren Verwendungsnachweise kann die Verwendung

von personenbezogenen Daten bis auf Programmebene nachvollzogen werden.

2.3.4.5 Regelfristen für Löschung14

Einleitend ist zunächst zu bemerken, dass die nachfolgend angesprochenen Fristen - betref-

fend die Löschung von personenbezogenen Daten - sich explizit an den hierzu einschlägigen

gesetzlichen Regelungen der Bundesrepublik Deutschland und an denen von der Rechtspre-

chung hierzu ergangenen Vorgaben orientieren. Technische Hinweise und Anmerkungen gel-

ten dagegen grundsätzlich übergreifend, d.h. auch über das Staatsgebiet der Bundesrepublik

Deutschland hinaus. Gleichwohl bedürfen diese einer spezifischen Umsetzung in Form eines

länder- bzw. projektspezifischen Customizings unter Berücksichtigung lokaler Bestimmun-

gen.

Gemäß § 3a BDSG haben sich die Erhebung, Verarbeitung und Nutzung personenbezogener

Daten und die Gestaltung und Auswahl von Datenverarbeitungssystemen an dem Ziel auszu-

richten, keine oder so wenig personenbezogene Daten wie möglich zu erheben, zu verarbeiten

oder zu nutzen. Dieser Grundsatz der Datenvermeidung und Datensparsamkeit ist einer der

elementaren Bestandteile des Datenschutzrechts. Deshalb ist insbesondere von den Möglich-

keiten der Anonymisierung und der Pseudonymisierung Gebrauch zu machen.

Unter Anonymisierung wird verstanden

„… das Verändern personenbezogener Daten derart, dass die Einzelangaben über

persönliche oder sachliche Verhältnisse nicht mehr oder nur mit einem unverhältnis-

mäßig großen Aufwand an Zeit, Kosten und Arbeitskraft einer bestimmten oder be-

stimmbaren natürlichen Person zugeordnet werden können.“ (§ 3 Abs. 6 BDSG)

Ein solcher Aufwand muss demnach im Verhältnis zum angestrebten Zweck stehen. Eine

Abwägung hat somit explizit im Zuge einer Verhältnismäßigkeitsprüfung zu erfolgen.

„Pseudonymisieren ist das Ersetzen des Namens und anderer Identifikationsmerkma-

le durch ein Kennzeichen zu dem Zweck, die Bestimmung des Betroffenen auszuschlie-

ßen oder wesentlich zu erschweren.“ (§ 3 Abs. 6a BDSG)

Unter Berücksichtigung der zuvor gemachten Ausführungen setzt sich das nachfolgende Ka-

pitel mit bestehenden Rechtsvorschriften, insbesondere betreffend Regelfristen für Lö-

schungs- und Mindestaufbewahrungsfristen, von personenbezogenen Daten auseinander. Da

das BDSG jedoch ein so genanntes Auffanggesetz ist, gehen spezielle Rechtsvorschriften vor.

Erst wenn solche bereichsspezifischen vorrangigen Bestimmungen keine rechtlichen Rege-

lungen beinhalten, kommt das BDSG zum Tragen (lex specialis vor lex generalis).

Aufgrund der in der Vergangenheit bereits stattgefundenen - damit auch zukünftig zu erwar-

tenden - Schaffung von neuen gesetzlichen Bestimmungen, wie z.B. des Allgemeinen Gleich-

behandlungsgesetzes (AGG) aus dem Jahre 2006, muss darauf hingewiesen werden, dass Re-

gelungen des Gesetzgebers, betreffend Löschung und Mindestaufbewahrung, in der Praxis ei-

14 Diesem Abschnitt liegen folgende Quellen zugrunde: Abel, Datenschutz, Band 2, Teil 6



ner Ausgestaltung - aufgrund von aktueller Rechtsprechung - bedürfen. Eine Vielzahl beste-

hender Rechtsprechung zu Löschungs- und Mindestaufbewahrungsfristen ist bereits ergangen.

Weitere gerichtliche Entscheidungen werden noch folgen, so dass auf die vorliegende Thema-

tik stets ein „juristisches Auge zu werfen ist“.

Im BDSG werden die so genannten Regelfristen für Löschungen - gemäß § 4e S. 1 Nr. 7

BDSG - genannt. Die Legaldefinition des § 3 Abs. 4 S. 2 Nr. 5 BDSG versteht unter löschen

„das Unkenntlichmachen gespeicherter personenbezogener Daten“, womit das unwieder-

bringliche Tilgen der Daten, ungeachtet der dabei verwendeten Verfahren, gemeint ist15. SAP

benutzt den Begriff der „Vernichtung“ von Daten.

Datenverarbeitung der öffentlichen Stellen

Die Datenverarbeitung der öffentlichen Stellen der Länder richtet sich insbesondere nach den

jeweiligen Landesdatenschutzgesetzen. Soweit diese einschlägig sind kommt das BDSG nicht

zum Tragen. Die Thematik Löschung bzw. Sperrung von personenbezogenen Daten durch öf-

fentliche Stellen des Bundes (was hierunter im Einzelnen gemeint ist, ergibt sich aus der Le-

galdefinition des § 2 Abs. 1 BDSG) ist in § 20 BDSG geregelt. Demnach gilt:

(2) Personenbezogene Daten, die automatisiert verarbeitet oder in nicht-

automatisierten Dateien gespeichert sind, sind zu löschen, wenn

1. ihre Speicherung unzulässig ist oder

2. ihre Kenntnis für die verantwortliche Stelle zur Erfüllung der in ihrer Zuständig-

keit liegenden Aufgaben nicht mehr erforderlich ist.

(3) An die Stelle einer Löschung tritt eine Sperrung, soweit

1. einer Löschung gesetzliche, satzungsmäßige oder vertragliche Aufbewahrungsfris-

ten entgegenstehen,

2. Grund zu der Annahme besteht, dass durch eine Löschung schutzwürdige Interes-

sen des Betroffenen beeinträchtigt würden, oder

3. eine Löschung wegen der besonderen Art der Speicherung nicht oder nur mit un-

verhältnismäßig hohem Aufwand möglich ist.

Gemäß dem Grundsatz lex specialis vor lex generalis (das besondere Gesetz geht dem allge-

meinen Gesetz vor) nachfolgend einige Beispiele für vorrangige bereichsspezifische Lö-

schungsfristen der öffentlichen Stellen:

Berufsgenossenschaften, spezielle gesetzliche berufsgenossenschaftliche Aufbewah-

rungspflichten bestehen grundsätzlich nicht, dennoch empfehlen die Berufsgenossenschaf-

ten in ihrem BG-Blatt B36, Ausgabe Oktober 2005, dass für Unterweisungen zur Arbeits-

sicherheit und zum Gesundheitsschutz eine Aufbewahrungsfrist von mindestens zwei,

besser fünf Jahren, in Betracht gezogen werden sollte,

Erziehungsregister, Maßnahmen nach dem Jugendgerichtsgesetz, Verfügungen des

Vormundschaftsgerichts; solche Eintragungen werden entfernt wenn der Betroffene das

24. Lebensjahr vollendet hat (§ 63 Abs. 1 BZRG),

15 siehe BDSG Kommentar Gola/Schomerus, §§ 3 Rn. 40



Gewerbezentralregister, Eintragungen werden - abhängig von der Höhe der Verhängung

einer Geldbuße - nach einer Frist von drei oder fünf Jahren getilgt (§ 153 Abs. 1 Nr. 1 und

2 GewO),

Öffentliche Archive, sofern Behörden Unterlagen zur Erfüllung ihrer öffentlichen Auf-

gaben nicht mehr benötigen, sind diese dem Bundesarchiv oder in bestimmten Fällen dem

zuständigen Landesarchiv zur Überlassung anzubieten (§ 2 Abs. 1 BArchG), dabei blei-

ben Rechtsvorschriften betreffend die Vernichtung (§ 2 Abs. 7 BArchG) bzw. Rechtsan-

sprüche Betroffener auf Vernichtung der sie betreffenden personenbezogenen Angaben (§

4 Abs. 1 BArchG) unberührt,

Schuldnerverzeichnis, Eintragungen sind nach Ablauf von drei Jahren, seit dem Ende

des Jahres in dem eine eidesstattliche Versicherung abgegeben wurde, zu löschen (§ 915 a

ZPO, § 284 AO),

Sozialrecht, Daten bei Krankenkassen, kassenärztlichen Vereinigungen und Geschäfts-

stellen der Prüfungsausschüsse sind, abhängig von der jeweiligen Art der Daten, nach ei-

ner Frist von vier oder zehn Jahren zu löschen (§ 304 SGB V, § 107 SGB XI, § 84 SGB

X),

Strafregister, Eintragungen werden, in Abhängigkeit der Schwere der Tatbegehung, nach

Ablauf von fünf, zehn, fünfzehn oder zwanzig Jahren getilgt (§ 46 Abs. 1 BZRG),

Verkehrszentralregister („Verkehrssünderkartei“), im Register gespeicherte Eintragun-

gen werden in Abhängigkeit der Schwere der Tat nach einer Frist von zwei, fünf oder

zehn Jahren getilgt (§ 29 Abs. 1 StVG).

Wie sich schon aus der Formulierung „Beispiel“ ergibt kann an dieser Stelle nur exemplarisch

angerissen werden, welche bereichsspezifischen Löschvorschriften existieren und welche Re-

gelfristen für die Löschung von personenbezogenen Daten für öffentliche Stellen Anwendung

finden.

Allein im Bereich der so genannten sozialen Sicherung haben etwa die gesetzlichen Kranken-

kassen Regelfristen für Löschungen zu beachten, die sich aus den

Sozialgesetzbüchern (SGB I - IX) sowie der

Sozialversicherungs-Rechnungsverordnung (SVRV)

allgemeinen Verwaltungsvorschriften über das Rechnungswesen in der Sozialversiche-

rung (SRVwV) und der

Risikostruktur-Ausgleichsverordnung (RSAV)

ergeben. Dabei variieren die anzuwendenden Aufbewahrungsfristen zwischen zwei und zehn

Jahren.

Die nach § 284 Abs. 1 S. 4 und § 304 Abs. 1 SGB V vorgegebene Verpflichtung zur Lö-

schung bestimmter Daten (Datenlöschung sobald diese für die vorgesehenen Zwecke nicht

mehr benötigt werden, spätestens jedoch nach zehn Jahren) geht der Löschfrist nach § 84

SGB X vor.

Datenverarbeitung der nicht-öffentlichen Stellen

Was im Einzelnen unter dem Begriff „nicht-öffentliche Stelle“ gemeint ist, folgt aus § 2

Abs. 4 BDSG. Demnach fallen hierunter alle natürlichen Personen, privatrechtliche organi-

sierte Personen, Personengesellschaften und nicht rechtsfähige Vereine die sich an die Verar-

beitungsregelungen der §§ 28 ff BDSG halten müssen. Ausgenommen sind somit so genannte

beliehene Unternehmen (natürliche oder juristische Personen des Privatrechts, die hoheitliche



Funktionen im eigenen Namen oder im Auftrag des Staates ausüben, wie z. B. der TÜV) so-

wie privatrechtlich organisierte Vereinigungen von öffentlichen Stellen des Bundes und der

Länder gemäß den besonderen Vorgaben des § 2 Abs. 3 BDSG.

§ 35 Abs. 2 BDSG enthält eine ganze Reihe von Löschungsvorschriften. Demnach sind per-

sonenbezogene Daten zu löschen, wenn

ihre Speicherung unzulässig ist

es sich um Daten über die rassische oder ethnische Herkunft, politische Meinungen, reli-

giöse oder philosophische Überzeugungen oder die Gewerkschaftszugehörigkeit, über Ge-

sundheit oder das Sexualleben, strafbare Handlungen oder Ordnungswidrigkeiten handelt

und ihre Richtigkeit von der verantwortlichen Stelle nicht bewiesen werden kann

sie für eigene Zwecke verarbeitet werden, sobald ihre Kenntnis für die Erfüllung des

Zweckes der Speicherung nicht mehr erforderlich ist

sie geschäftsmäßig zum Zwecke der Übermittlung verarbeitet werden und eine Prüfung

jeweils am Ende des vierten Kalenderjahres beginnend mit ihrer erstmaligen Speicherung

ergibt, dass eine länger währende Speicherung nicht erforderlich ist

Den Löschungsfristen auf der einen Seite stehen so genannte Mindestaufbewahrungsfristen

auf der anderen Seite entgegen. Diesbezüglich gibt es eine ganze Reihe von Bestimmungen

die explizite Regelungsgehalte aufweisen, welche nachfolgend - nicht abschließend - aufge-

führt sind. Wichtige Eckpunkte sind:

Aufbewahrung nach Handels- und Steuerrecht (z. B. Buchführung, Kundendaten, Lagebe-

richte, Personaldaten),

Aufbewahrungsbestimmungen zum Arbeits- und Sozialrecht, Berufsordnungen,

Aufbewahrungsvorschriften in der DV.

Handels- und Steuerrecht

sechs Jahre (§ 257 Abs. 4 HGB, § 147 Abs. 3 AO)

zehn Jahre (§ 257 Abs. 4 HGB, § 147 Abs. 3 AO)

Arbeits- und Sozialrecht, Berufsordnungen

Die Aufbewahrungsvorschriften erstrecken sich aufgrund gesetzlicher Vorgaben auf

zwei Jahre Arbeitszeitnachweise (§ 16 ArbZG), Jugendarbeitsschutzunterlagen (§ 50

Abs. 2 JArbSchG),

fünf Jahre Nachweise der Beitragsabrechnung und Beitragszahlung an Sozialversiche-

rungsträger (§ 28f Abs. 1 i. V. m. § 28p Abs. 1 SGB IV, Handakten von

Rechtsanwälten (§ 50 Abs. 2 BRAO),

sechs Jahre Betriebliche Altersversorgung (§ 11 Abs. 2 BetrAVG), Identifizierungs-

pflicht bei Finanztransaktionen (§ 9 Abs. 3 GwG),

zehn Jahre Jugendarbeitsschutz-Unterlagen - ärztlicher Untersuchungsbogen - (§ 4 Abs.

2 JArbSchUV),

Des Weiteren gibt es noch spezielle Aufbewahrungsvorschriften eingeteilt nach Kategorien

und Bereichen wie z. B.:

für die Dauer des Arbeitsverhältnisses bis Anfang eines jeden Jahres,

bis zum Ausscheiden eines Arbeitnehmers,



bis zum Ablauf des auf die letzte Prüfung folgenden Kalenderjahres,

bis zum Ablauf des Kalenderjahres, das auf das Jahr der Anlegung von Listen folgt.

Aufbewahrungsvorschriften in der Datenverarbeitung (§ 9 BDSG und Anlage zu § 9

BDSG, § 147 Abs. 5 AO, § 257 Abs. 3 HGB)

ein Jahr Job-Accounting, Netzwerkdaten, Systemnachrichten, Begleitpapiere und

Protokolle über Datenträgertransport und -Verwaltung, Konvertierungspro-

tokolle16,

drei Jahre Systemdateien (drei Generationen), Standardsoftware17

sechs Jahre Terminpläne, Schichtprotokolle, Arbeitsaufträge

zehn Jahre Anwenderprogramme einschließlich aller Unterlagen über die Übernahme

in die Produktion; Systemnachrichten; Protokolle über DV-Aktivitäten, so-

weit für die Nachvollziehbarkeit von nachweispflichtigen Aufträgen erfor-

derlich (für die Rechnungslegung relevante Tabellen).

Datenverarbeitung in besonderen Fällen

Protokolldateien

Eine besondere Problematik besteht hinsichtlich der Speicherung von sogenannten Protokoll-

dateien mit Hilfe von automatisierten DV-Anlagen. Dabei handelt es sich zum einen um Pro-

tokolle im Sinne eines „kaufmännischen“ Audits betreffend der inhaltlichen Änderungen an

Belegen (z.B. wer hat wann, was, gebucht, verändert) und zum anderen um Log-Files im Sin-

ne des System Logs oder des Security Audit Logs (z.B. Anmeldeversuche die zur Sperrung

führen können, abgebrochene Verarbeitungen, Warnmeldungen und sonstige Probleme; siehe

hierzu weitere Einzelheiten in Kapitel 4.2.1.9 des Leitfadens).

Die Log-Files und Protokolle beinhalten sowohl Informationen über alle oder nur bestimmte

Aktionen von Prozessen auf einem DV-Anwendungssystem, als auch personenbeziehbare Da-

ten. Einzelne Inhalte bestehender bzw. gespeicherter Log-Files können - ohne großen Auf-

wand - natürlichen Personen zugeordnet werden. Dabei sind gerade bei der Verwendung von

SAP-Anwendungen Log-Files und Protokolle - im Zusammenhang mit Tabellenzugriffen -

weit verbreitet, so dass hier nicht nur datenschutzrechtliche Normen, sondern auch betriebs-

verfassungsrechtliche Aspekte tangiert sind. Da den meisten SAP-Anwendern und selbst Ba-

sis-Administratoren nicht immer im Einzelnen klar ist was, wie und wo mittels Log-Files ge-

loggt oder mittels Verwendung von Protokollen protokolliert wird, ist hierauf ein besonderer

Augenmerk zu richten. Denn auch Gerichte haben längst die datenschutzrechtliche Brisanz

von Log-Files entdeckt. Aus den Urteilen des AG Darmstadt18, des LG Darmstadt19 20 und des

EuGH (24. November 2011, Rechtssache C-70/10) ist zu entnehmen, dass selbst dynamische

IP-Adressen geeignet sind, einen Personenbezug herzustellen und deshalb einer datenschutz-

rechtlichen und ggf. einer mitbestimmungsrechtlichen Beurteilung bedürfen. Damit hat auch

16 siehe Abel, Datenschutz, Band 2, Teil 6/2.4.1.4

17 siehe Abel, Datenschutz, Band 2, Teil 6/2.4.1.4

18 Az.: 300 C 397/04, vom 30.06.2005

19 Az.: 25 S 118/2005, vom 25.01.2006

20 Az.: 25 S 118/2005, vom 25.01.2006



bei der Erhebung bzw. Verarbeitung von Log-Files der Grundsatz der Datenvermeidung und

Datensparsamkeit - i. S. d. § 3a BDSG - im Vordergrund zu stehen.

Im Einzelfall kann es jedoch sein, dass der Arbeitgeber oder der Dienstherr ein berechtigtes

Interesse an der Erhebung und Speicherung von Log-Files und Protokollen hat. Hierzu nor-

miert § 28 Abs. 1 S. 1 Nr. 2 BDSG:

(1) Das Erheben, Speichern, Verändern oder Übermitteln personenbezogener Daten

oder ihre Nutzung als Mittel für die Erfüllung eigener Geschäftszwecke ist zulässig,

…

2. soweit es zur Wahrung berechtigter Interessen der verantwortlichen Stelle er-

forderlich ist und kein Grund zu der Annahme besteht, dass das schutzwürdige

Interesse des Betroffenen an dem Ausschluss der Verarbeitung oder Nutzung

überwiegt. …

Im Zuge dieser Bestimmung darf jedoch das schutzwürdige Interesse des Betroffenen, an dem

Ausschluss der Verarbeitung oder der Nutzung solcher Daten, nicht außer Acht gelassen wer-

den, so dass es stets zu einer Interessensabwägung kommen muss. Leider hat es der Gesetz-

geber in § 28 Abs. 1 S. 1 Nr. 2 BDSG verabsäumt, konkrete Anhaltspunkte zu formulieren,

die eine Interessensabwägung vereinfachen würden.21 Demnach hat eine solche Interessens-

abwägung im Zuge einer so genannten Verhältnismäßigkeitsprüfung stattzufinden, die unter

Berücksichtigung der Vorgaben des BDSG aber auch im Rahmen der gesetzlich normierten

Mitbestimmungsrechte der Arbeitnehmervertretungen durchgeführt werden muss.

In der Praxis könnte das wie folgt aussehen: Je mehr personenbezogene Daten in Log-Files

oder Protokollen erfasst werden, umso höher muss das schutzwürdige Interesse des Betroffe-

nen bemessen werden. Eine sinnvolle Maßnahme, die eine datenschutzkonforme Nutzung ge-

rade von Log-Files ermöglichen würde, wäre der Einsatz von Tools, welche automatisch per-

sonenbezogene bzw. personenbeziehbare Daten in Log-Files anonymisieren (z. B. Anonlog,

Pseudo/Core). Damit wäre nur noch bei wenigen abrechnungs- und steuerrelevanten Vorgän-

gen die Verwendung von klassischen, d.h. nicht anonymen Protokollen notwendig.

Lässt sich eine automatisierte Anonymisierung von Log-Files - aus welchen Gründen auch

immer - nicht durchführen, muss zwingend der Grundsatz der Zweckbindung (welcher aus §

31 BDSG folgt) beachtet und eingehalten werden. Demgemäß dürfen Log-Files „zu Zwecken

der Datenschutzkontrolle, der Datensicherung oder zur Sicherstellung eines ordnungsgemä-

ßen Betriebes einer Datenverarbeitungsanlage gespeichert werden“. Damit sind solche Daten

einer strikten Zweckbindung unterworfen, was auch in der Parallelregelung des § 14 Abs. 4

BDSG - für den öffentlichen Bereich - zum Ausdruck kommt. Daraus folgt, dass der Zugriff

auf Log-Files nur durch diejenigen Personen und Stellen erfolgen darf, die solche Daten für

die Erfüllung ihrer konkreten Aufgaben zwingend benötigen. Dies können – je nach Fallkons-

tellation – insbesondere Betriebsräte, Datenschutzbeauftragte, Sachverständige und Sys-

temadministratoren sein. Freilich sollten auch deren Zugriffe - trotz ihrer besonderen Vertrau-

enspositionen - auch nachträglich nachvollziehbar sein. Hierzu bietet sich insbesondere ein

„moderates“ Logging an, wobei sich hier die Frage einer Anonymisierung ernsthaft nicht

stellt (aufgrund der geringen Anzahl der diesbezüglich in Frage kommenden Personen bzw.

eingrenzbaren Stellen, ist grundsätzlich in jedem Fall, eine Zuordnung der Log-Files mög-

lich).

21 Simitis, Kommentar BDSG, S. 1030 Rn. 162



Anders verhält es sich dagegen bei Protokolldateien (Änderungsbelege), welche aufgrund

handels- bzw. steuerrechtlicher Grundsätze zu führen sind, beispielsweise muss stets erkenn-

bar sein, welcher „SAP-User“ eine Rechnung storniert hat. Gerade in diesen Fällen ist eine

Protokollierung schon zur Revisionssicherheit unumgänglich.

Bewerbungsunterlagen

Das Bundesarbeitsgericht stellte in seinem Urteil vom 6. Juni 198422 fest, dass eine längerfris-

tige Aufbewahrung von Personalbögen bzw. Bewerbungsunterlagen, eines erfolglos gebliebe-

nen Stellenbewerbers das verfassungsmäßige Persönlichkeitsrecht des Bewerbers verletzt.

Auch hier greift insoweit der Grundsatz der Datenvermeidung und Datensparsamkeit i. S. d.

§ 3a BDSG. Sofern die Bewerbungsphase abgeschlossen ist, bestehen grundsätzlich keine

Gründe, die es erforderlich machen, dass die Bewerbungsunterlagen weiterhin aufgehoben

werden müssen. Durch Inkrafttreten des AGG - im Jahr 2006 - wurde jedoch für den Bewer-

ber in § 15 AGG eine Rechtsgrundlage geschaffen, die es ihm erlaubt Entschädigung und

Schadensersatz, etwa bei der vorgetragenen Benachteiligung während der Bewerbung, binnen

einer Frist von zwei Monaten nach Zugang der Ablehnung, geltend zu machen. In diesem Fall

besteht seitens des Arbeitgebers eine Beweislast gemäß § 22 AGG. Aufgrund dieser Beweis-

lastpflicht, muss es dem Arbeitgeber möglich sein, die Unterlagen für einen Zeitraum von

mindestens zwei Monaten aufzubewahren, um seiner Nachweis- und Dokumentationspflicht

nachzukommen. Eine Klage auf Entschädigung und Schadensersatz muss gemäß § 61b Abs. 1

ArbGG i. V. m. § 15 AGG innerhalb von drei Monaten, nachdem der Anspruch schriftlich

geltend gemacht worden ist, erhoben werden. Daraus folgt, dass die beiden zuvor genannten

Fristen zusammen zu addieren und zusätzlich mit einer Karenzzeit von einem Monat zu ver-

sehen sind. Zusammenfassend kann somit festgestellt werden, dass für den Arbeitgeber eine

Aufbewahrungsfrist von insgesamt sechs Monaten gegeben ist.

Daten aus Schuldnerverzeichnissen

Handels- und Wirtschaftsauskunfteien wie etwa die SCHUFA erhalten in der Regel von den

Gerichten unmittelbar Daten aus dem Schuldnerverzeichnis (§ 915d Abs. 1, § 915e Abs. 1

Buchst. b ZPO). Das BDSG sieht in § 35 Abs. 2 Nr. 4 vor, dass personenbezogene Daten zu

löschen sind, wenn „sie geschäftsmäßig zum Zweck der Übermittlung verarbeitet werden und

eine Prüfung jeweils am Ende des vierten Kalenderjahres beginnend mit ihrer erstmaligen

Speicherung ergibt, dass eine länger währende Speicherung nicht erforderlich ist“. Eine Er-

forderlichkeit, über den Zeitpunkt von vier Jahren hinaus, ist in jedem Einzelfall zu prüfen.

Die Empfänger von Daten aus dem Schuldnerverzeichnis müssen die gesetzlichen Löschfris-

ten einhalten (§ 915g Abs. 1 i. V. m. § 915a Abs. 1 ZPO, § 15 SchuVVO - Schuldnerver-

zeichnisverordnung). Eine Eintragung im Schuldnerverzeichnis wird nach Ablauf von drei

Jahren gelöscht. Für Schuldnerdaten, die nach § 26 Abs. 2 InsO - aufgenommen wurden, gilt

eine Löschungsfrist von fünf Jahren.

Fazit

Im Datenschutzrecht besteht nach Ablauf der Aufbewahrungsvorschriften eine Löschpflicht.

Hierbei sind die Daten unwiderruflich zu entfernen, d.h. zu vernichten. Ein reines Sperren des

Zugriffspfads oder eine Archivierung in nicht mehr produktiven Systemen wären nach diesen

Normen nicht erlaubt. Eine solche Löschpflicht ist bereits aufgrund des Grundsatzes der Da-

tenvermeidung und Datenspeicherung dringend geboten.

22 Az: 5 AZR 286/81, Urteil vom 6. Juni 1984



Bei relationalen Datenbanken, wie sie in SAP-Anwendungen verwendet werden, hat der An-

wender jedoch keinen Einfluss auf die physikalische Speicherung. Löschung bedeutet Sper-

rung aller weiteren Zugriffe, ohne dass die Daten unbedingt zu 100% gelöscht werden. Theo-

retisch wären sie durch Datenbank-Spezialisten (Administratoren) wieder einsehbar. Es emp-

fiehlt sich, unerlaubt gespeicherte oder falsche bzw. angezweifelte Daten als Datensatz - so-

weit EDV-technisch möglich - unmittelbar zu löschen oder zu sperren Daten, die nicht mehr

zur Erfüllung des Zweckes benötigt werden oder deren Aufbewahrungsvorschrift abgelaufen

ist, sollten in periodischen Abständen gelöscht werden. Anschließend sollte die Datenbank -

soweit zeitlich und technisch möglich - reorganisiert werden.

SAP-Verfahren. Vernichtung von HCM-Daten

Eine regelmäßige Löschung von SAP HCM Datenbeständen kann über das Information-

Lifecycle-Management (ILM) realisiert und umgesetzt werden. Die reine Datenlöschungs-

möglichkeit ist in der Basis-Lizenz des HCM enthalten. ILM erlaubt eine Verwaltung der

„Retention Time“ (Aufbewahrungsfristen) an einer Stelle. Dabei sind die Regeln, nach denen

die Retention Time bestimmt wird, abhängig von der jeweiligen Anwendung. So lassen sich

unterschiedliche Löschfristen für verschiedene Datenkategorien, etwa für An- und Abwesen-

heitszeiten, für Gehaltsdaten oder Bewerbungsdaten, als auch für verschiedene Mitarbeiter-

gruppen, etwa für Beamte oder Angestellte, definieren. Mit der Datenlöschung wird auch der

mögliche Rückrechnungszeitraum entsprechend angepasst. ILM erlaubt eine Löschung (=

Vernichtung) der Daten unabhängig davon, ob die Daten schon archiviert wurden oder ob sich

die Daten noch im produktiven System befinden. Soweit für eine Anwendung sinnvoll, kann

über ILM auch eine Archivierung weiterer personenbezogener Daten ermöglicht werden, dies

ist allerdings nicht in der Basis Lizenz von HCM enthalten.

Die Vernichtung der Daten bedarf der Abstimmung zwischen der zuständigen Fachabteilung,

dem Datenschutzbeauftragten sowie der IT und ist über das Customizing-System einzurich-

ten. Die Durchführung kann sowohl über Programme - etwa als eingeplanter jährlicher Lösch-

lauf – als auch individuell über ein „Zwei-Schritt-Verfahren“ (Setzen eines Löschkennzei-

chens und anschließendes physische Datenlöschung) und unter Beachtung der bestehenden

Berechtigungen erfolgen. Das Setzen des Löschkennzeichens bewirkt im Grunde zunächst ei-

ne Sperrung der betroffenen Daten, damit werden sie über die normalen Transaktionen und

Reports nicht mehr angezeigt. Bis zur Durchführung der Löschung - die innerhalb eines Zeit-

raums von maximal 2 Monaten erfolgen sollte - ist eine Stornierung des Vorgangs möglich.

An Stelle einer Löschung kann ggf. eine Sperrung in Frage kommen, wenn wegen der beson-

deren Art der Speicherung eine Löschung nur mit unverhältnismäßig hohem Aufwand möglich

ist.

Der Datenschutzbeauftragte hat die Aufgabe, die verantwortliche Stelle auf die Einhaltung der

einschlägigen Aufbewahrungs- und Löschfristen hinzuweisen sowie entsprechende organisa-

torische Maßnahmen einzufordern, da diese Stelle die Verantwortlichkeit für die Umsetzung

der vorgeschriebenen Aufbewahrungs- und Löschfristen trägt (der Datenschutz ist hier nur ein

Aspekt). Des Weiteren sind zu den Löschfristen im betriebsinternen Verfahrensverzeichnis

(siehe Kap. 2.3.4) detaillierte Informationen anzugeben.

Ein Anspruch zur Löschung von Daten besteht nicht:

bei gesetzlichen, vertragsmäßigen oder vertragsrechtlichen Aufbewahrungsvorschriften

wenn ein Grund zur der Annahme besteht, dass durch eine Löschung schutzwürdige Inte-

ressen des Betroffenen beeinträchtigt werden.



2.3.4.6 Geplante Übermittlung in Drittstaaten

Dieser Punkt ergänzt die unter § 4e BDSG zu nennenden Empfänger um die geplanten Über-

mittlungen an Drittstaaten. Hier sind insbesondere die Empfänger in Staaten außerhalb der

EU mit einem nicht EU-konformen Datenschutzstandard aufzuführen. Die verantwortliche

Stelle muss sich hier insbesondere nach den §§ 4b und 4c BDSG richten. Eine Übermittlung

muss unterbleiben, wenn ein angemessenes Schutzniveau nicht vorhanden ist und somit die

berechtigten Interessen des Betroffenen zum Schutz seiner Daten nicht gewährleitstet werden

können.

Als Ausnahmen sind neben der Einwilligung und der Übermittlung zur Erfüllung eines Ver-

trages insbesondere Garantien aus Vertragsklauseln oder verbindliche Unternehmensregelun-

gen (Binding Corporate Rules oder Codes of Conduct) möglich23. Die EU-Kommission selbst

bietet Standardvertragsklauseln für spezielle Übermittlungen von personenbezogenen Daten

in unsichere Drittländer an. Diese Standardvertragsklauseln sind eigenen Verträgen vorzuzie-

hen, da letztere nicht nur von der Aufsichtsbehörde zu genehmigen sind, sondern die erteilten

Genehmigungen nach Art 26 Abs. 3 EU-Richtlinie an die EU-Kommission und die anderen

Mitgliedsländer mitzuteilen sind. Diese Gremien können ihrerseits Widerspruch einlegen und

die Kommission zu geeigneten Maßnahmen über ein Ausschussverfahren drängen.

In den USA können einzelne Firmen durch eine Art Selbstzertifizierung (Stichwort Safe Har-

bor) ein angemessenes Schutzniveau nachweisen. Die aktuelle Mitgliederliste wird im Inter-

net veröffentlicht24.

Es empfiehlt sich, die Datenkategorien getrennt nach dem jeweiligen Drittland und den jewei-

ligen Empfängern anzugeben.

Auch die im Rahmen des Offshoring in Drittländer übermittelten Daten sind in das Verfah-

rensverzeichnis aufzunehmen. Dazu zählt auch eine Datenbank-/Serverbetreuung durch Ad-

ministratoren anderer Konzerngesellschaften in Drittländern. Details zur Auftragsdatenverar-

beitung sind in Kapitel 5 dargestellt.

2.3.4.7 Maßnahmen zur Gewährleistung der Sicherheit

Das BDSG (§ 4e S. 1 Nr. 9) fordert hier

… eine allgemeine Beschreibung, die es ermöglicht, vorläufig zu beurteilen, ob die

Maßnahmen nach § 9 zur Gewährleistung der Sicherheit der Verarbeitung angemes-

sen sind. …

Die Beurteilung der Datensicherungsmaßnahmen hängt u.a. davon ab, welche personenbezo-

genen Daten im Einzelnen verarbeitet werden. Für das betriebsinterne Verfahrensverzeichnis

(siehe Kap. 2.3.4) sind in diesem Zusammenhang detaillierte Angaben erforderlich bzw. mit

den SAP-Hilfsmitteln (vgl. Kap. 2.4) zu beschaffen.

Im Kapitel 4 widmen wir uns ausführlich den Anforderungen aus § 9 BDSG nebst Anlage

und den Umsetzungsmöglichkeiten im SAP ERP. Insbesondere Authentifizierung, Benut-

zeradministration, Berechtigung und Autorisierung werden hier ausführlich behandelt.

23 Siehe Arbeitsunterlage: Übermittlungen personenbezogener Daten an Drittländer: Anwendung von

Artikel 25 und 26 der Datenschutzrichtlinie der EU (WP12)

24 Link: http://web.ita.doc.gov/safeharbor/shlist.nsf/webPages/safe harbor list

http://web.ita.doc.gov/safeharbor/shlist.nsf/webPages/safe%20harbor%20list



2.3.4.8 Zugriffsberechtigte Personen

Zugriffsberechtigungen auf die Daten von Einzelpersonen bzw. Personengruppen werden

über Rollen bzw. Profile im SAP ERP vergeben und administriert. Die Rollen bzw. Profile er-

lauben bzw. verwehren i. d. R. über Berechtigungsobjekte das Lesen oder Ändern von be-

triebswirtschaftlichen oder technischen Objekten.

Die im SAP ERP-System definierten Rollen bzw. Profile können direkt Personen oder Grup-

pen zugeordnet werden. Über die vergebenen Rollen bzw. Profile können Zugriffsberechtigte

kategorisiert werden.

Das Benutzerinformationssystem (Transaktion SUIM) ermöglicht die Anzeige bzw. Analyse

der zugriffsberechtigten Personen im SAP ERP-System.

Beispiel aus der Personalwirtschaft (SAP HCM):

Verwaltungssachbearbeiter Arbeitgeberleistungen

Vergütungsmanagement

Organisationsmanagement

Fachvorgesetzter /

Disziplinarischer Vorgesetzter

Arbeitgeberleistungen

für Vergütungsmanagement

Organisationsmanagement

Personaladministration

Personalkostenplanung

Beurteilungssystem

Personalentwicklung

Raum Reservierungen

Veranstaltungsmanagement

Sachbearbeiter Leistungslohn

Zeiterfassung

Einsatzplanung

Abrechnung

Für weitergehende Erläuterungen zum Zugriffsschutz und Berechtigungskonzept wird auf

Kapitel 4.2 verwiesen.



Hinweise zur Verwendung des SAP Audit Information System und des ABAP Dictionary

werden im Abschnitt 2.4 Systemunterstützung gegeben.

2.3.5 Beispiel Melderegister

Die Aufsichtsbehörden verlangen, die Meldepflicht auf jeden einzelnen Verarbeitungsvor-

gang zu beziehen. In folgendem Beispiel für ein Melderegister sind die Vorschläge des Unab-

hängigen Landeszentrums für Datenschutz Schleswig-Holstein und weiterer Aufsichtsbehör-

den als Grundlagen enthalten25

Wenn man Standardsoftware im Unternehmen einsetzt, sollte man auch auf diese verweisen,

da dort ggf. bestimmte Verfahrensbeschreibungen und Abläufe allgemein zugänglich doku-

mentiert sind.

Öffentlicher Teil

Name/Firma verantwortliche

Stelle

Inhaber, Vorstände, Leiter DV

Anschrift der verantwortlichen

Stelle

Zweckbestimmungen der Da-

tenerhebung, -verarbeitung oder

–nutzung

SAP ERP HCM: Personaladministration, Personalabrech-

nung, Organisationsmanagement, Zeitwirtschaft, Personal-

beschaffung, Personalbetreuung (Vergütung, Arbeitgeber-

leistungen, Altersvorsorge), strategische Personalplanung

SAP for Healthcare: Patientenmanagement, Patientenab-

rechnung, klinische Auftragsabwicklung (Partner), medizi-

nische Dokumentation

SAP EH&S: Gesundheitsdienst, Arbeitsschutz

SAP ERP FI: Pflege und Service für Kunden und Lieferan-

ten

SAP CRM: Marketingplanung und Kampagnenmanage-

ment, Telemarketing, Kontaktmanagement, Kundenservice

Interaction Center, Internet Customer Self-Service, Ser-

vicemanagement, Einsatzplanung,

Betroffene Personengruppen

und diesbezügliche Datenkate-

gorien

Personen: Mitarbeiter, Bewerber, Kunden, Lieferanten,

Versicherungsnehmer, Patienten

Daten: Mitarbeiter-, Bewerber-, Kunden-, Lieferantendaten

nach Standard SAP ERP HCM, SAP ERP FI und SAP

25 www.datenschutzzentrum.de und Zusammenstellung in GDD-Ratgeber „Datenschutz im

Unternehmen“ 7. Aufl. 2010, S. 213 ff

http://www.datenschutzzentrum.de/



CRM;

Besondere Arten personenbezogener Daten nach § 3 Abs.9

BDSG, zum Beispiel:

Patientendaten nach Standard SAP for Healthcare;

betriebliche Gesundheits- bzw. Arbeitsschutzdaten nach

Standard SAP EH&S;

Daten zur Gewerkschaftszugehörigkeit, ethnische Herkunft,

Religionszugehörigkeit, nach Standard SAP ERP HCM

Empfänger oder Kategorien von

Empfängern

Vertragspartner, Banken, Bausparkassen, Versicherungen,

Finanzamt, Krankenkassen, Versorgungsanstalten, Auf-

tragsdatenverarbeiter

Regelfristen für die Löschung

der Daten

Allgemein: Periodische Löschung nach Ablauf der gesetzli-

chen Aufbewahrungsfristen

Detailliert:

unterschiedliche Löschfristen für einzelne Datenarten

Frist oder Zeitpunkt für die Überprüfung der Erforder-

lichkeit der Datenbestände

Geplante Datenübermittlung in

Drittstaaten

Datenkategorien unterteilt nach Drittstaaten und Empfän-

gern



Nichtöffentlicher Teil

Allgemeine Beschreibung zur

Beurteilung der Angemessenheit

der Schutzmaßnahmen nach § 9

BDSG

Vorlage eines gesonderten Sicherheitskonzepts

Vorgesehene Protokollauswertungen

Systemumgebung: Systemsoftware (Betriebssystem, DB,

Netzwerk), Anwendungssoftware (SAP ERP;

www.sap.com), Sicherungssoftware (Antivirus, Firewall,

Kryptographie, ...)

Technisch-organisatorische Maßnahmen nach § 9

BDSG

Kontrolle Maßnahmenbeispiele

Zutritt Gesicherte Gebäude und Räume

Zugang PC-Sperre, Kennwortregeln

Zugriff Rollen, Berechtigungen

Weitergabe Kryptographie, digitale Signatur

Eingabe Protokollierung, Belege

Auftrag Vertragsregelungen, Prüfung

Verfügbarkeit DB-Recovery, Sicherungskopien außer

Haus

Trennung Systemtrennung, Mandanten

2.4 Systemunterstützung

Im SAP-System ist das ABAP Dictionary zur Verwaltung aller im System verwendeter Daten

vorgesehen. Das ABAP Dictionary gibt Auskunft über Tabellen, Domänen und Felder und

kann als Verwendungsnachweis in Reports, Dynpros oder weiteren Tabellen herangezogen

werden.

In diesem Abschnitt wollen wir einen kurzen Einblick in Techniken zur Erstellung einer

Übersicht über Daten und Datenkategorien für die Verfahrensbeschreibung sowie die Prüfung

von Zugriffsberechtigungen geben. Die vorgestellten Funktionen können auch Änderungsbe-

rechtigungen beinhalten, dies ist bei der Rollendefinition zu beachten.

Hilfreiche Systemunterstützung bieten dem DSB auch Werkzeuge wie z.B. SAP GRC Access

Control (siehe Kapitel 6.5 SAP GRC (Governance, Risk and Compliance)), SECURINFO for

SAP (www.securinfo.com), ZRPDINF01 (www.forba.de) oder CheckAud (www.check-

aud.de) (siehe auch Akquinet.de), die insbesondere zur Analyse der genutzte

personenbezogenen Daten und der Umsetzung der Sicherheitsmaßnahmen sowie von

Berechtigungskonzepten eingesetzt werden. Der DSB sollte sich diesbezüglich mit anderen

http://www.check-aud.de/

http://www.check-aud.de/



Abteilungen bzw. der IT in Verbindung setzen, um die Verfügbarkeit im Unternehmen zu

verifizieren.

Hinweis: Zum besseren Verständnis der benutzten Transaktionen lassen sich die technischen

Namen wie folgt in die Menüs einblenden:

Menüpfad:

Zusätze -> Einstellungen -> Technische Namen anzeigen

2.4.1 Auswertungen zur Tabellen- und Feldanalyse

Im Folgenden werden Hinweise gegeben, wie die verantwortliche Stelle dem Datenschutzbe-

auftragten mit SAP-technischen Mitteln die erforderlichen Übersichten gemäß BDSG erstel-

len kann.

Die folgende Aufzählung aller Tabellen mit personenbezogenen Daten des SAP-Standards

kann nicht vollständig sein, da hier die kundenspezifischen Erweiterungen, Modifikationen

oder Löschungen nicht berücksichtigt sein können.

Mit Hilfe des ABAP Dictionary kann dynamisch eine Tabellenübersicht erzeugt werden, die

den aktuellen Kundenstand wiedergibt.

Im Einzelfall können Verwendungsnachweise von Domänen oder Datenelementen zu abhän-

gigen Reports, Dynpros und Tabellen ermittelt werden.

Grober Überblick:

In einer Tabellenübersicht kann eine Kurzbeschreibung der Infotypen bzw. Tabellen erstellt

werden. Beispiele:

PA0* Personalstammdaten

HRP1* Personalplanungsdaten, -entwicklungsdaten

PA2* Zeitdaten

PB0* Stammdaten Bewerber

PB4* Bewerberdaten

PCL* Clustertabellen (HCM)

TRV* Reiseplanung und Reisekostenabrechnung

KN* Kundenstamm

LF* Lieferantenstamm

SADR* Adressverwaltung

Menüpfad:

Werkzeuge -> ABAP Workbench -> Entwicklung -> Dictionary (SE12): Objektname PA0*

als Datenbanktabelle: Anzeigen oder Drucken

Mit Hilfe dieser Übersichten können über das ABAP Dictionary gezielt einzelne Tabellen o-

der Felder bearbeitet werden.

Wir empfehlen, die Berechtigung für den Zugriff auf Tabellen mit personenbezogenen Daten

nur im Ausnahmefall und befristet zur fachlichen Betreuung und Fehleranalyse zu erteilen.



Daten des Personalwirtschaftsbereichs (HCM / HR)

Im HCM werden die Daten als Infotypen und Infosubtypen verarbeitet. Die Personalstamm-

daten und Zeitdaten sind in den Tabellen PAxxxx abgelegt. Eine Tabelle PAxxxx enthält ne-

ben systemspezifischen Einträgen wie z.B. Schlüssel nur die Daten des jeweiligen Infotyps

xxxx.

Eine ausführliche Darstellung der einzelnen Tabellen erhält man über das ABAP Dictionary

(SE12) bzw. das Repository Infosystem (Object Navigator, SE84).

Folgende Reports bieten einen Überblick über die Infotypen:

Infotypen und Subtypen (Report RPDSHOWI) listet die Infotypen und Subtypen mit An-

gabe der Infotypstruktur auf.

Infotypen und Subtypen mit DB-Statistik (Report RPDINF01) bietet zusätzlich noch eine

Datenbankstatistik der tatsächlich in der vorliegenden SAP-Installation verwendeten Info-

und Subtypen an. Außerdem dokumentiert die Infotyp-Übersicht für einen Mitarbeiter

(Report RPLINFC0) die für einen bestimmten Mitarbeiter belegten Infotypen, die mit dem

Report RPLERDX0: Auskunft mitarbeiterbezogener Daten(s. Hinweis 1569378) angezeigt

werden können.

Im Audit Information System sind die obigen Reports auch verfügbar.

In der Personalplanungskomponente werden personenbezogene Daten über Infotyp 1001 mit

einer Person verknüpft, wie z.B. Seminare, Qualifikationen, Karrierepfade, Vorsorgeuntersu-

chungen. Die einzelnen Verknüpfungsarten bzw. Subtypen sind in Tabelle T778V verzeich-

net. Alle Verknüpfungsdaten werden zentral in der Tabelle HRP1001 abgelegt.

Für einzelne Verknüpfungsarten (vgl. Tabelle T77AR) werden darüber hinaus noch Zusatzda-

ten in Tabellen der Form HRPAD* (vgl. Tabelle T77AD) gespeichert.

Eine Darstellung der einzelnen Tabellen (HRP1001, HRPAD*) liefert neben dem ABAP Dic-

tionary auch der Report RHDDIC00:Tabellenfelder aus dem DataDictionary.

Benutzerdaten 1 (Benutzerverwaltung)

Welche Tabellen gibt es im SAP-System, die Benutzerwerte speichern?

Tabellenname: US*

Domäne: XUBNAME Benutzername im Benutzerstamm

Benutzerdaten 2 (Sachbearbeiterkennzeichen)

Domänen:

AENUS Username der letzten Änderung

AS4USER Autor der letzten Änderung

BNAME Benutzername

BUSAB Nummer des Buchhaltungs-Sachbearbeiters

DDUSER Dictionary: Letzter ändernder Benutzer

DWNAM Name des zuständigen Sachbearbeiters

RALDB_NAME Name des Erstellers/Änderers der Variante

SACHA Sachbearbeiter Abrechnung/Personal/Zeiterfassung

UNAME Benutzername



UBNAME Benutzernamen

USERNAME Benutzername (SAP-Benutzer)

USNAM Name des Benutzers

XUBNAME Benutzername im Benutzerstamm

XUSER Benutzername

Benutzerdaten 3 (Protokolldaten)

Protokolldaten befinden sich u.a. im Accounting, Systemlog (SM21) und in den Protokollda-

teien.

Die Accountingdaten werden über die Abrechnungsnummern im Benutzerstamm identifiziert.

Die Auswertung des Accounting bzw. der Statistiksätze wird in der Transaktion des Work-

load Monitors durchgeführt.

Menüpfad:

Werkzeuge -> Administration -> Monitor -> Performance -> Systemlast -> Aggregierte Sta-

tistiksätze (ST03N/ST03G) oder Statistik-Einzelsätze (STAD)

In der Systemlogdatei (SM21) wird der Benutzername festgehalten:

Feldname: Benutzer

2.4.2 Techniken zum Auffinden personenbezogener Daten

Variante 1: Bei Projekteinführung

In der Einführungsphase werden vom Projektteam mit dem Datenschutzbeauftragten und dem

Betriebs- bzw. Personalrat die zulässigen personenbezogenen Daten festgelegt und deren

Auswertungen überprüft.

Hierbei werden die entsprechenden Transaktionen, Dynpros und Reports analysiert.

Durch Sperren von Transaktionen und Reports sowie durch Dynprovariationen im Customi-

zing kann die Eingabe der nicht zulässigen personenbezogenen Daten verhindert werden. Das

hätte den Vorteil, dass Variante 2 nur noch für zusätzliche Kontrollen benötigt würde.

Über die F1-Hilfe ist es möglich, aus den Dynpros das Dynprofeld zu ermitteln mit den ent-

sprechenden Namen von Tabelle, Feld, Datenelement und Domäne. Das ABAP Dictionary

ermöglicht mit diesen Informationen, Verwendungsnachweise in Programmen, Dynpros und

Tabellen der Einzelfelder zu ermitteln. Sofern hierbei kein Tabellenname sondern ein Struk-

turname angezeigt wird, ist die zugrunde liegende Datenbanktabelle über den Verwendungs-

nachweis zum angezeigten Datenelement zu bestimmen.

Beispiel: Transaktion PA20 mit Infotyp Bankverbindung:

F1-Hilfe liefert unter technischer Info bei Bankkonto:

Dynprofeld P0009-BANKN

Tabellenname P0009

Datenelement BANKN

Feldname BANKN



Menüpfad:

Werkzeuge -> ABAP Workbench -> Übersicht -> Infosystem-> ABAP Dictionary -> Daten-

elemente mit Auswahl BANKN -> Hilfsmittel -> Verwendungsnachweis -> indirekte Verwen-

dung (SE12)

Verweist z.B. auf Tabellen, Programme oder Dynpros.

Variante 2: Im aktiven System

Tabellen mit Personenbezug sind im SAP-System nicht als solche bezeichnet, können aber

mit dem ABAP Dictionary über Domänen ermittelt werden.

Wichtige Domänen:

AD_PERSNUM Personennummer (Adresse)

AFNAM Name des Anforderers in der Bestellanforderung

APLNO Bewerbernummer

APLNR Bewerbernummer

CATSXT_CALLER_ID Identifikation des Aufrufers

DISPO Disponent

EKGRP Einkaufsgruppe

KUNNR Kundennummer

LIFNR Kontonummer des Lieferanten

NAME Name eines Partners

FALNR Fallnummer (im IS-H)

PATNR Patientennummer (im IS-H)

PERSONAL_NUMBER Personalnummer

PERSNO Personalnummer

PERSONID Personennummer

PERNR Personalnummer

VKGRP Verkäufergruppe

Folgende Domänen haben ebenfalls Namensbezug:

BDEUNAME Benutzer im DASS

CYFC_NAME Name des Erstellers/Änderers einer Ablaufsteuerung

DOKU_USER Benutzername

HIER_USER Benutzername

I_PARNR Partner (Partnerpflege PM)

J_1BPARID Partneridentifikation (Kunde, Lieferant, Branch)

KUNDE Partnernummer (KUNNR,LIFNR,PERNR,PARNR)

NA_PARNR Partnernummer

QPRUEFER Name des Prüfers

RFC_TC_ID Benutzername des persönlichen Talentberaters



SC_OWNER Benutzername (Terminkalender)

SPARTNR Partnernummer

SO_ADRNAM SAPoffice: Adressname eines Officebenutzers

SO_SADRNAM SAPoffice: abgekürzter Adressname

STAT_USER Statistik, Account

TDUSER TDIC User

UDUSER Autor

XUAUTH Berechtigungsname

XUNAME1 Name des Benutzers (Adresse)

Das Datenelement GPART Geschäftspartner (z.B. Ärzte im SAP for Healthcare) kann eben-

falls Personenbezug haben (Domäne: RI_Rolle).

Um mit Hilfe des Reports RSCRDOMA aus dem Audit Information System ein firmenspezi-

fisches Verfahrensregister zu erhalten, sind die oben genannten Personen identifizierenden

Domänen zu überprüfen und ggf. zu ergänzen (AIS-Funktion: Dateiregister zu personenbezo-

genen Daten).

Dokumentation von Datenfeldern

Im ABAP Dictionary stehen Funktionen zur Verfügung, um bis auf die Einzelfelder von Ta-

bellen verzweigen zu können:

Anzeigen bzw. Drucken von Tabellen und Feldern (auch als Tabellenhandbuch mit RSS-

DOCTB druckbar)

Menüpfad:

Werkzeuge -> ABAP Workbench -> Übersicht -> Infosystem -> ABAP Dictionary -> Fel-

der -> Strukturfelder (SE84) P000* Drucken

Verwendungsnachweis von Tabellen, Datenelementen und Domänen

Über das ABAP Dictionary können Informationen zu Tabellen, Strukturen, Feldnamen, Da-

tenelemente und Domänen, sowie deren Verwendung in Programmen, Dynpros und Tabellen

ermittelt werden.

Menüpfad:

Werkzeuge -> ABAP Workbench -> Entwicklung -> Dictionary mit Auswahl Domänen und

Objektname 'PERSNO' für Personalnummer -> Hilfsmittel -> Verwendungsnachweis -> indi-

rekte Verwendung (SE12): verweist z.B. auf DB-Tabellen, Programme oder Dynpros.

2.4.3 Prüfung der Zugriffsberechtigungen

Das Benutzerinformationssystem bietet eine maschinelle Unterstützung, um die Zugriffsbe-

rechtigungen zu überprüfen.

Das Benutzerinformationssystem ist als Berichtsbaum über die Transaktion SUIM aufrufbar.

Hiermit können z.B. Benutzer mit bestimmten Berechtigungen, Rollen oder Profilen identifi-

ziert werden. Siehe hierzu auch Kapitel 4.3 bzw. 6.3.

Menüpfad:

Werkzeuge -> Administration -> Benutzerpflege -> Infosystem.



Wer ist im System aktiv?

SM04 (Benutzerliste) bzw. AL08 (Liste aller angemeldeten Benutzer)

Anzeigen der aktiven Benutzer in einem definierten Mandanten bzw. im gesamten Sys-

tem.

Welche Benutzer (mit Adressdaten) gibt es im SAP-System?

SUIM Berichtsbaum anzeigen (siehe oben)

Menüpfad:

Infosystem -> Benutzer -> Benutzer nach Adressdaten -> Liste erzeugen -> * zeigt alle

Benutzer an

Änderungsbelege für Benutzer, Profile, Berechtigungen und Rollen sind direkt aus dem

SUIM-Berichtsbaum und im AIS über die Schaltfläche Änderungsbelege aufrufbar (Re-

ports RSUSR100, RSUSR101, RSUSR102, RSSCD100_PFCG).

Die Protokollanzeige der Zentralen Benutzerpflege kann mit dem Report RSUSRLOG er-

folgen.

Gezielte Selektionen zur Analyse eines SAP-Berechtigungskonzeptes können insbesonde-

re auch über den Schalter Benutzer nach komplexen Selektionskriterien für Benutzer mit

bestimmten Berechtigungen, Profilen, Rollen und Transaktionscodes erfolgen. Hierbei ist

auch eine Selektion nach Feldwerten in Berechtigungsobjekten möglich.

Welche Tabellen gibt es im SAP-System, die Benutzerwerte speichern?

SE16 und SE16N Data Browser

Tabellenname: USR* Anzeige aller Tabellen mit aktuellen Benutzerdaten

Tabellenname: USH* Anzeige aller Tabellen mit Benutzeränderungsbelegen

Sowie die Tabellen UST* und USL*.

TAANA Tabellenanalyse

Mit dem Transaktionscode TAANA: Tabellenanalyse aus dem Arbeitsfeld Archivierung

kann eine Detailsicht der vorhandenen personenbezogenen Daten vor allem für große und

für nicht indexierte Datentabellen erstellt werden. Es wird die Anzahl der Datensätze für

eine bestimmte Feldauswahl ermittelt und abgespeichert. Die Auswahl läßt sich temporär

( ad-hoc) eingeben und ausführen.

Über den Transaktionscode TAANA_AV: Tabellenanalyse_Analysevarianten kann die

Analyse dauerhaft anlegt werden und dann mit TAANA angestartet werden.

Die Feldauswahl BUKRS, VORGN, PERNR, GJAHR zeigt z.B. für die Tabelle BSEG:

Belegsegment_Buchhaltung die Anzahl der für eine Person vorhandenen Sätze mit glei-

chen Buchungskreis, Geschäftsjahr und betriebswirtschaftlichem Vorgangsschlüssel an.

Die Feldauswahl BUKRS, PERNR, PERNR, GJAHR, VRGNG zeigt z.B. für die Tabelle

COEP: CO-Objekt Einzelposten periodenbezogen die Anzahl der für eine Person vorhan-

denen Sätze mit gleichen Buchungskreis, Geschäftsjahr und betriebswirtschaftlichem

Vorgangsschlüssel an.

Welche Reports (ABAP) gibt es für die Benutzerverwaltung?

SA38 ABAP Reporting

Menüpfad:



System -> Dienste -> Reporting -> Programm RSUSR* (alle Programme zur Benutzer-

auswertung) -> F4-Suchhilfe -> Ausführen -> Programmnamen selektieren -> Auswählen

(= Ausführen)

Viele wichtige Reports werden im Rahmen des Benutzerinformationssystems zur Verfü-

gung gestellt, die auch separat über das ABAP Reporting (SA38) gestartet werden können:

Benutzer RSUSR002, RSUSR008, RSUSR009,

RSUSR008_009_NEW

Rollen RSUSR070, RSSCD100_PFCG

Profile RSUSR020

Berechtigungsobjekte RSUSR030, RSUSR040

Berechtigungen RSUSR030

Transaktionen RSUSR010

Vergleiche RSUSR050

Verwendungsnachweise RSUSR002, RSUSR020, RSUSR030, RSUSR070 (SAP-

Hinweis 608661), RSUSR060OBJ

Änderungsbelege RSUSR100, RSUSR101, RSUSR102, RSSCD100_PFCG

Weitere Reports:

RSUSRSUIM Benutzerinformationssystem

RHUSERRELATIONS Benutzerzuordnungen anzeigen (für HCM Berechtigungs-

objekte); frühere Transaktion OOAC, aktuell: Transaktion

HRAUTH (mit Reiter: „Benutzerspezifisch“)

RSUSR000 Aktive Benutzer

RSUSR003 In allen Mandanten die Kennwörter der Standard-Benutzer

prüfen

RSUSR005 Liste der Benutzer mit kritischen Berechtigungen

RSUSR006 Gesperrte Benutzer und Benutzer mit Falschanmeldungen

RSUSR012 Suche Berechtigungen, Profile und Benutzer mit bestimm-

ten Objektwerten

RSUSR060OBJ Verwendungsnachweis Berechtigungsobjekt in Program-

men und Transaktionen

RSUSR200 Liste der Benutzer nach Anmeldedatum und Kennwortände-

rung



3 Rechte der Betroffenen und von jedermann

Rechte der Betroffenen

Grundlage für die Rechte der Betroffenen ist das Transparenzgebot des BDSG. Danach ist der

Betroffene bereits bei der Erhebung seiner Daten, z. B. beim Vertragsabschluss, über die

Zweckbestimmung und die wesentlichen Umstände des Umgangs mit seinen Daten zu infor-

mieren (§ 4 Abs. 3 BDSG). Gemäß § 28b Nr. 4 BDSG ist beim Scoring (Berechnung des

Wahrscheinlichkeitswertes) sogar die Unterrichtung zu dokumentieren, wenn dazu Adressda-

ten verwendet werden. Soweit die Information nicht bereits bei der Datenerhebung erfolgt ist

oder Betroffene später weitere Informationen anfordern, besteht die Verpflichtung der ver-

antwortlichen Stelle zur Benachrichtigung der Betroffenen gem. § 33 BDSG und gem. § 6

Abs. 1 BDSG zur Beachtung der unabdingbaren Rechte des Betroffenen auf Auskunft (§§ 19,

34 BDSG) sowie auf Berichtigung, Löschung oder Sperrung (§§ 20, 35 BDSG). Hierzu gibt

es einige ergänzende Informationspflichten:

§ 28 Abs. 3 BDSG verlangt, dass bei einer Verwendung von Adressdaten zu eigenen Werbe-

zwecken, wenn diese von Dritten stammen - die Stelle, die die Daten erstmalig erhoben hat,

aus der Werbung eindeutig hervorgeht.

§ 42a BDSG verlangt eine unverzügliche Information der zuständigen Aufsichtsbehörde und

des Betroffenen, wenn eine nicht öffentliche oder öffentliche Stelle feststellt, dass bei ihr Da-

ten nach Satz 1 Nummern 1. – 4. des § 42a BDSG unrechtmäßig übermittelt oder auf sonstige

Weise Dritten unrechtmäßig zur Kenntnis gelangt sind, und schwerwiegende Beeinträchti-

gungen der Rechte und der schutzwürdigen Interessen der Betroffenen drohen.

Ausdrücklich hingewiesen sei in diesem Zusammenhang darauf, dass nach § 43 BDSG eine

vorsätzlich oder fahrlässig nicht erfolgte, nicht richtige oder nicht vollständige Benachrichti-

gung des Betroffenen eine Ordnungswidrigkeit darstellt. Diese kann im Fall des § 43 Abs. 1

BDSG mit einer Geldbuße bis zu EUR 50.000,- und im Fall des Absatzes 2 mit einer Geldbu-

ße bis zu EUR 300.000 geahndet werden.

Rechte von jedermann

Eine weitere Umsetzung des Transparenzgebotes findet sich im § 38 Abs. 2 BDSG wieder.

Danach kann das von der Aufsichtsbehörde geführte Register nach § 4e S. 1 Nr. 1-8 BDSG

von jedem (Recht von jedermann) eingesehen werden.

Das Recht von jedermann von der verantwortlichen Stelle etwas über die gespeicherten Daten

zu erfahren, findet sich ferner im § 4g Abs. 2 S. 2 BDSG wieder. Hier ist der Beauftragte für

den Datenschutz zuständig – auf Antrag – jedermann die Angaben gem. § 4e S. 1 Nr. 1-8

BDSG in geeigneter Weise verfügbar zu machen.

Zusammenfassend ist festzuhalten, dass das Informations- und Transparenzgebot von der ver-

antwortlichen Stelle, dem Beauftragten für den Datenschutz und der Aufsichtsbehörde zu ge-

währleisten ist.

Allerdings ist der Umfang und die konkrete Umsetzung dieser Rechte zwischen dem Recht

der Betroffenen und jedermann zu differenzieren.

Bei dem Recht der Betroffenen handelt es sich um ein detailliertes Informations- und Aus-

kunftsrecht, welches die Inhalte jedes einzelnen Datums zu seiner Person umfasst.

Beim Jedermannrecht ist in der Regel dem Informations- und Auskunftsrecht genüge getan,

wenn die Struktur der Dateien bzw. die Tatsache, dass überhaupt personenbezogene Daten er-

hoben, verarbeitet und genutzt werden, bekannt gegeben werden.



3.1 Benachrichtigung und Auskunft

3.1.1 Rechtliche Anforderungen

In der Regel werden personenbezogene Daten in SAP ERP-Systemen nur auf Basis einer

(vor-) vertraglichen Grundlage (z. B. Arbeitsvertrag, Kaufvertrag) gespeichert. Daher wird die

Benachrichtigungspflicht in der Regel durch die Information bei der Erhebung (§ 4 BDSG)

verdrängt (zu Ausnahmen bei CRM-Systemen s. Leitfaden hierzu).

Daher sind Benachrichtigungen und die Beantwortung von Auskunftsersuchen (Antrag des

Betroffenen erforderlich) individuell zu behandeln.

Bei der Benachrichtigung sind Angaben zu einer konkreten Verarbeitung in allgemeiner Form

zu machen, z. B. Datenkategorien, Kategorien möglicher Empfänger. Die Frage, ob eine Be-

nachrichtigungspflicht für konkrete Verarbeitungsprozesse besteht, und die Organisation der

Benachrichtigung inklusive ihrer Dokumentation sind bereits zu Beginn der Verarbeitung /

Verfahrenseinführung zu klären (s. a. Kap. 1, Kap. 2.3).

Dagegen hat der Betroffene im Rahmen des Auskunftsrechts einen Anspruch auf vollständige

Auskunft über alle der verantwortlichen Stelle zu seiner Person zur Verfügung stehenden Da-

ten. Dabei sind dem Betroffenen die konkreten Daten in verständlicher Form mitzuteilen.

3.1.2 SAP-Fakten

Es gibt im SAP-Standard keinen zusammenfassenden Report, der sozusagen auf Knopfdruck

alle zu einer Person gespeicherten Daten für die Auskunftserteilung oder zur Benachrichti-

gung eines Betroffenen anzeigt oder ausdruckt.

Diese Feststellung trifft auch für einzelne Module zu, in denen ein Betroffener in seiner Rolle

als Arbeitnehmer, als Kunde, Patient, Lieferant, Geschäftspartner oder ähnliches gespeichert

ist. Gleichwohl gibt es in einzelnen Modulen Anzeige- und Druckmöglichkeiten, mit denen

einzelne Aspekte eines Datensatzes zu einer Person ausgegeben werden können.

Als Hilfsmittel im SAP ERP-System bietet sich das Audit Information System (AIS) an (vgl.

hierzu Kap. 6.3), wobei die Funktionalitäten im Rahmen der Übersichten (Dateiregister26 zu

personenbezogenen Daten) grundsätzliche Informationen über die verwendeten Tabel-

len/Domänen mit Personenbezug liefern.

Im ERP steht für kundenbezogene Daten das Customer Fact Sheet zur Verfügung.

Transaktion VC/2 (Programm RVKUSTA1). Das Kundenstammblatt kann auch aus

verschiedenen ERP Transaktionen heraus aufgerufen werden, z. B. VA01, VC01N.

Das Kundenstammblatt kann ausgedruckt werden: Programm SD_CFS_PRINT01

Für SAP ERP HCM (Personalwirtschaft) steht die Funktion „Infotypübersicht für einen Mit-

arbeiter“ zur Verfügung (Personal Personalmanagement Administration Personal-

stamm Anzeigen), mit der alle für einen Mitarbeiter tatsächlich belegten Infotypen ange-

zeigt werden. Mit der entsprechenden Transaktion des SAP ERP HCM (PA20, ‚Personal-

26 Eine Anpassung der Terminologie an die aktuelle Rechtslage des BDSG durch die SAP steht bislang

aus.



stammdaten anzeigen’) können im zweiten Schritt die Daten der belegten Infotypen für eine

Auskunftserteilung ausgedruckt werden27.

Der Report RPLERDX0 „Auskunft mitarbeiterbezogener Daten“ (s. Hinweis 1569378) gibt

Auskunft über die im System gespeicherten Daten zu einem Mitarbeiter und zeigt alle zu sei-

ner Person in den verschiedenen Infotypen des HCM gespeicherten Daten an. Die Informatio-

nen werden am Bildschirm dargestellt und können über die Drucktaste – etwa zur Beantwor-

tung eines Auskunftsersuchens – angedruckt und dem Antragsteller ausgehändigt werden. Je-

de Ausführung dieses Reports wird protokolliert, da hier zum Teil sehr sensible Informatio-

nen angezeigt werden. Dabei werden der entsprechende Benutzername, das Datum und die

Zeit der Ausführung, der Ausgabebereiche sowie der Grund der Ausführung in einer entspre-

chenden Tabelle gespeichert.

Zur detaillierten Konfiguration gibt es das Kapitel „Auskunft mitarbeiterbezogener Daten“ im

IMG unter Personalmanagement Personaladministration

3.1.3 Anforderungen an die Organisation des Datenschutzes

Da es keine universelle Unterstützung des SAP-Systems gibt, die es dem Anwender (i.d.R.

datenschutzrechtlich verantwortliche Stelle oder DSB bzw. dessen Hilfspersonal) erleichtert,

den Anforderungen des BDSG in Bezug auf die Auskunftspflicht nachzukommen28, muss sich

der Anwender einen Arbeitsplan erstellen, in dem festgehalten wird, wie im konkreten Fall

das Auskunftsersuchen eines Betroffenen mit den vorhandenen Mitteln befriedigt werden

kann.

Ein systematisches Vorgehen bei der Organisation der technischen Umsetzung von Aus-

kunftsersuchen kann folgende Elemente enthalten:

Eine rechtliche Prüfung, auf welche Rechtsgrundlage sich das Auskunftsersuchen eines

Betroffenen stützt, ob es sich um eine auskunftsberechtigte Person handelt, ob eine Aus-

kunft ggf. nicht erforderlich ist usw.

Bestimmung der Rolle, in der der Betroffene zur verantwortlichen Stelle steht, um

dadurch die zu untersuchenden Datenbereiche eingrenzen zu können. Eventuell kann man

einem Auskunftssuchenden Hilfsmittel anbieten, um seine Daten “näher zu bezeichnen“,

falls das für die Abwicklung der Auskunftserteilung hilfreich sein sollte.

Bestimmung der Module, die im Unternehmen in Einsatz sind und in denen Daten des Be-

troffenen aufgrund seiner Rolle enthalten sein können.

Extraktion der Daten aus dem System: Da es für diesen Schritt (mit Ausnahme der o.a. ge-

schilderten Funktion für die Personalwirtschaft) keine speziellen Hilfsmittel gibt, muss man

versuchen, ihn mit den vorhandenen Möglichkeiten zu bewältigen. Mögliche Ansätze sind:

27 Hierzu steht auch eine allgemein verfügbare Auswertung (Z_RPDINF001) zur kostenlosen Bestellung

unter www.forba.de zur Verfügung

28 SAP bietet inzwischen mit TREX / SES eine Suchmaschine an, die auch Datentabellen durchsuchen

kann und daher zum Suchen nach Namen bzw. personenbezogenen Daten geeignet ist. Die Nutzung

der TREX/SES-Funktionen bedarf allerdings der exakten beschränkenden Regelungen, da

Suchmaschinen immer die Gefahr beinhalten, jede Zweckbindung und die erforderliche

Vertraulichkeiten personenbezogener Daten aufzuheben.

http://www.forba.de/



ABAP Dictionary

Ein systematisches Vorgehen über das ABAP Dictionary mit der Transaktion SE11 bzw.

SE12. kann z.B. folgende Schritte umfassen:

1. Bestimmung der Domänen, die in diesem Fall auf personenidentifizierende Daten verwei-

sen (z.B. PERSNO (Personalnummer) im SAP ERP HCM, PATNR (Patientennummer)

und FALNR (Fallnummer) im SAP for Healthcare (IS-H), USNAM (Name des Benutzers

bei Benutzerdaten)

2. Anschließend sind für alle beteiligten Domänen die betroffenen Tabellen nachzuweisen

3. Zu sämtlichen betroffenen Tabellen sind über das ABAP Dictionary oder den Data Brow-

ser (Transaktion SE17) eine Datenanzeige für alle der Auskunft unterliegenden Datenfel-

der aufzurufen. Enthält die Tabelle tatsächlich Daten über den Betroffenen, dann sind die

Daten per Hardcopy, per Download in ein Textverarbeitungsprogramm oder per Ausdruck

auszugeben.

4. Zur Aufbereitung der Auskunft in einer verständlichen Form sind Schlüsselfelder im Voll-

text auszugeben und unverständliche Datenfeldbezeichnungen im Klartext neben die

technische Feldbezeichnung zu schreiben.

5. Schritt 3. und 4. sind für alle in Frage kommenden Tabellen zu wiederholen.

Sonstige Möglichkeiten

Es sind noch weitere Möglichkeiten denkbar, die in Frage kommenden Tabellen zu bestim-

men, z.B. über die Anwendungshierarchie (Transaktion SE81) oder das Repository-

Infosystem (Transaktion SE84).

Über die Anzeigetransaktionen und ABAP-Programme der Fachmodule

Es müssten alle einer jeweiligen Rolle zugehörigen (Anzeige-) Transaktionen und Dynpros

ermittelt und diese vollständig per Hardcopy dokumentiert werden. Nicht zu beauskunftende

Daten (z.B. Name des erfassenden Sachbearbeiters) sind aus den Ausdrucken ggf. zu entfer-

nen, wenn die Hardcopies im Original weitergegeben werden sollen. Einschlägige Anzeige-

transaktionen können den bearbeitenden Sachbearbeitern auch im Benutzermenü zur Verfü-

gung gestellt werden. (Zur Einrichtung von Favoriten siehe die SAP ERP-Dokumentation).

Einschlägige Reports können durch die Ergänzung in Bereichsmenüs (Bereichsmenüpflege

Transaktion SE43N) dem Endbenutzer zur Verfügung gestellt werden.

Über Reports

Zu einzelnen Themen gibt es Reports oder Transaktionen, die einen Teil der gespeicherten

Daten ausgeben.

Beispiele aus dem SAP ERP HCM:

Personalstammblatt (Aufruf mit dem Report RPPSTM00)

Die Personalakte zeigt alle Stammdaten einer Person an.

Menüpfad:

Personal Personalmanagement Administration Personalstamm Personalakte

(PA10)

Infotypübersicht für einen Mitarbeiter im Audit Information System (AIS) oder direkt mit

dem zugrunde liegenden Report RPDINF01.

Es werden aber nicht die gespeicherten Daten ausgegeben, sondern nur die Datenstruktur, so

dass man, je nach Anfrage des Betroffenen, ggf. nacharbeiten muss.



Über Queries

Sind entsprechende Sachgebiete eingerichtet, dann können die geforderten Auskünfte auch

mit ABAP Query erzeugt werden. Voraussetzung dafür ist jedoch, dass die betroffenen Tabel-

len und Datenfelder bei der Erstellung einschlägiger Sachgebiete ermittelt wurden.

Je nach Query-Werkzeug (SAP-Query, Ad-Hoc-Query und Qick-Viewer) sind unterschiedli-

che Berechtigungen zum Anlegen/ Pflegen der Query-Funktion und zum Ausführen der

Query-Funktion erforderlich. Abhängig von der ausgewählten Datenquelle (Tabellen-

Join/View, Sachgebiet/SAP Query InfoSet, Tabelle, Logische Datenbank) werden unter-

schiedliche Berechtigungen für das Ausführen der Query-Funktion benötigt.’ Bei Auswahl

oder der Auswahlmöglichkeit von Tabellen oder Tabellen-Joins/Views sind Tabellenberechti-

gungen (Berechtigungsobjekt: S_TABU_DIS) erforderlich.

Queries müssen als kritische Berechtigung eingestuft werden, da die Tabellenberechtigungs-

gruppen regelmäßig nicht detailliert auf das Kundensystem und die Sicherheitsanforderungen

des Kunden abgestimmt sind, Sie sind durch vordefinierte Reports, die in Transaktionen um-

gesetzt werden, zu ersetzen. Davon kann abgesehen werden, wenn es ein detailliertes und do-

kumentiertes Berechtigungskonzept für Tabellen gibt, das auf Datensatz-/feldebene die Risi-

ken bewertet.

Fazit :

Alle aufgezeigten Möglichkeiten sind - außer im SAP ERP HCM - recht arbeitsaufwen-

dig, so dass es bei häufiger auftretenden Auskunftsersuchen sinnvoll sein kann, spezielle

Reports programmieren zu lassen.

Zur Auskunft nach § 34 BDSG gehören auch Zweck der Speicherungen und Personen o-

der Stellen, an die die Daten übermittelt werden. Diese Angaben können u.U. dem Ver-

fahrensverzeichnis gemäß § 4d BDSG entnommen und müssen der Auskunft beigefügt

werden. Zuletzt ist der datenschutzgerechte Versand der erstellten Dokumente zu organi-

sieren.

3.2 Berichtigung, Löschung und Sperrung

3.2.1 Rechtliche Anforderungen

Die verantwortliche Stelle hat gemäß §§ 20 bzw. 35 BDSG personenbezogene Daten von Be-

troffenen zu berichtigen, wenn sie unrichtig sind. Ggf. sind Daten zu löschen; zum Beispiel

dann, wenn ihre Speicherung unzulässig ist oder die ursprüngliche Zweckbindung weggefal-

len ist. In gewissen Fällen tritt an die Stelle einer Löschung die Sperrung der personenbezo-

genen Daten. Im Zusammenhang mit der Berichtigung, Löschung und Sperrung von Daten

sind im Vorwege gewisse Fragen zu klären:

a) Zum Inhalt der Berichtigung, Löschung oder Sperrung

Auf welche Daten / Tabellen bezieht sich der Berichtigungs-/Löschungs- bzw. Sper-

rungsanspruch?

Welches Verfahren ist bei Rücksicherungen/Sicherungskopien vorgesehen, wenn ge-

sperrte Daten betroffen sind?



Sind die systemtechnischen Voraussetzungen für eine Löschung konform mit den

rechtlichen Anforderungen definiert (z.B. im SAP ERP HCM durch die geeignete De-

finition der Zeitbindung der Infotypen in der Tabelle T582A)?

b) Besonderheiten für spezielle Datenarten

Wie soll/kann mit Protokolldaten verfahren werden?

Welche Vorgehensweise ist bei Änderung/Löschung von Zugriffsberechtigungen und

anderen Benutzerstammdaten angebracht?

Wie wirksam sind Lösch- bzw. Sperrvermerke bei Daten mit Doppelbezug (z.B. Info-

typ 0021 Familie/Bezugsperson)?

3.2.2 SAP-Fakten

Es gibt keine speziellen SAP ERP-Funktionen - etwa Transaktionen oder Reports -, die die

Anforderungen der §§ 20 bzw. 35 BDSG gewährleisten.

Datenschutzkonformes Löschen

In SAP HCM gibt es verschiedene Möglichkeiten des datenschutzkonformen Löschens.

Löschen von nicht mehr benötigten Daten der Mitarbeiter für die Aufbewahrungsfristen

abgelaufen sind. Hierzu finden sich Details im Kapitel 6.1.1 Datenschutzkonformes Lö-

schen in der Personalwirtschaft (SAP HCM); Verfügbar für Releases ab ERP 6.0 Enhan-

cement Package 4

Löschen von Abwesenheiten für Release vor ERP 6.0 Enhancement Package 4. Details in

diesem Kapitel

Löschen aller Daten zu einem Mitarbeiter. Details in diesem Kapitel

Korrektur falscher Daten für einzelne Mitarbeiter. Details in diesem Kapitel

Löschen von Abwesenheiten

RPUDESTROY_ABSENCE löschen / vernichtet die Abwesenheiten von Personalnummern

bis zu einem festgelegten Stichtag. Der Report kann ausschließlich bei deutschen Personalfäl-

len die Abwesenheiten löschen. Sollen Personalfälle von der Löschung der Abwesenheiten

ausgenommen werden, erfolgt dies über eine spezielle Datumsart im Infotyp 41.

Löschen aller Daten zu einem Mitarbeiter

Vollständige Löschung eines Personalfalls, zur Sicherstellung eines Vier-Augen-Prinzip mit

den Rollen "Löschbeantrager" und "Löscher", durch folgende zwei Reports (SAP Hinweis

989664):

RPUDELPP Vorbereitung der Löschung

RPUDELPN Durchführung der vollständigen Löschen von Personalnummern

Es werden alle Infotypen einer Personalnummer gelöscht.

Es werden alle personalnummernabhängigen Cluster, die für diese Personalnummer ange-

legt worden sind, gelöscht.

- Tabelle Zuordnung von Werten zu Objekten (T52B5)

- Cluster TX aus der Tabelle RP-Cluster PCL1.

Es wird die Tabelle der Zeitereignisse (TEVEN) gelöscht.



Es werden Daten über Aktivitäten mit Abrechnungsergebnissen/Buchungen (Überleitung

FI) gelöscht:

- Aktivitäten pro Abrechnungsergebnis (PCALAC)

- Index Abrechnungsergebniszeile -> Buchungszeile) (PPOIX)

- Index alte <-> neue Belegzeile für 'P'-Ergebnisse (PPOPX)

Es werden die zu den zu löschenden Personalnummern existierenden Einträge aus folgen-

den Tabellen gelöscht:

- Übernahme Lohnkonto alt (T558A)

- Übernahme Lohnkonto: Abrechnungsperioden (T558B)

- Übernahme Lohnkonto: Lohnarten alt (T558C)

- Übernahme Lohnarten mit Splitterkennzeichen (T558D)

Es werden Integrationsdaten (Organisationsmanagement) und Buchungen im Veranstal-

tungsmanagement gelöscht.

Gelöschte Daten sind endgültig gelöscht / vernichtet!

Korrektur falscher Daten für einzelne Mitarbeiter

Das SAP ERP-System bietet allerdings hinsichtlich der Berichtigung von Daten in den ver-

schiedenen Anwendungsmodulen die Möglichkeit, mit den Standard-Pflegetransaktionen un-

richtige Daten zu korrigieren, soweit diese noch im Onlinezugriff sind. Im Rahmen des SAP

ERP HCM bietet sich hierfür z.B. die Transaktion PA30 ‚Personalstamm pflegen’ an.

Es gibt keine Standardfunktion, die den Zugriff auf historische Daten mit personenbezogenen

Angaben, die nur noch aus Gründen der Aufbewahrungspflichten gespeichert werden, be-

schränkt - auch wenn alle buchhalterischen Abschlusstätigkeiten erledigt sind.

Auch die Löschung von Daten kann mit dieser Pflegetransaktion vorgenommen werden, wo-

bei darauf zu achten ist, dass eine tatsächliche Löschung erst mit der physischen Reorganisa-

tion der Datenbank erfolgt (eventuell ist der kritisierte Dateninhalt noch in Protokollen vor-

handen). Die unrichtigen Daten sind außerdem nach wie vor Bestandteil des Änderungsproto-

kolls für Infotypen, der mit dem Report RPUAUD00 angezeigt werden kann.

Sperren

Explizite Funktionen zur Sperrung von Daten einzelner Personen sind im SAP ERP-System

z.Z.. nicht vorhanden. So lassen sich etwa inkriminierte Daten eines Betroffenen im SAP ERP

HCM nicht auf einfache Weise sperren, weil u. a. das entsprechende Berechtigungsobjekt

P_ORGIN (Stammdaten) die Zulässigkeit des Zugriffs lediglich bis auf die Ebene des gesam-

ten Infotyps, nicht aber bezogen auf das einzelne Datenfeld prüft.

3.2.3 Anforderungen an die Organisation des Datenschutzes

Außer zu den unter Kapitel 3.2.1. genannten Fragen sind Grundsatzfragen des Archivierungs-

konzeptes wie auch eines Datenlöschungskonzeptes einzubeziehen und organisatorische Vor-

kehrungen ggf. in folgender Hinsicht zu treffen:

a) Organisation der Sperrung:

Da eine Sperrung einzelner Daten zur Person als technische Funktion im SAP ERP-

System explizit nicht vorgesehen ist, muss die verantwortliche Stelle ein adäquates orga-



nisatorisches Verfahren entwickeln. Übergangsweise könnte die verantwortliche Stelle

statt einer Sperrung von Daten ihre datenschutzgerechte Dokumentation/ Archivierung in

Kombination mit einer vorübergehenden Löschung vornehmen.

b) Form der Löschung:

Wie erfolgt die Löschung aus dem aktuellen Datenbestand? (manuell?)

Wie erfolgt die Löschung aus dem archivierten Datenbestand? (manuell?)

c) Aufbewahrungsfristen (vgl. hierzu Abschnitt 2.3.5)

Wer ist für die Festlegung der Aufbewahrungsfristen zuständig?

(Wo) sind die Aufbewahrungsfristen und ihre Rahmenbedingungen im SAP ERP -

System dokumentiert?

Wie erfolgt die Löschung von Daten nach Ablauf formeller Aufbewahrungsfristen?

Diese Anforderungen an die Organisation des Datenschutzes lassen sich auch im GRC Pro-

cess Control (kostenpflichtige Komponente, vgl. Kap. 6) abbilden. Es besteht die Möglichkeit

Prozesse (wie z.B. zur fristgerechten Löschung von Daten, Reorganisation der DB) zu defi-

nieren/dokumentieren und diesen Prozessen manuelle Kontrollen zu zuordnen. Auf diese

Weise kann eine regelmäßige Überprüfung gewährleistet und dokumentiert werden.



4 Umsetzung der Anforderungen aus § 9

BDSG und Anlage: Technisch-

organisatorische Maßnahmen

4.1 Anforderungen

In diesem Abschnitt werden die technisch-organisatorischen Anforderungen an die Verarbei-

tung personenbezogener Daten und deren Prüfungen behandelt. Die Anforderungen sind all-

gemein, d.h. insbesondere auch bei der Verarbeitung außerhalb des Geltungsbereichs nationa-

ler Gesetze, zu erfüllen.

Diese Vorschriften beziehen sich nicht alleine auf Produktivsysteme, sondern auch auf vorge-

lagerte Systeme, soweit dort personenbezogene Daten zugreifbar sind oder dort Einstellungen

vorbereitet werden, die später in die Produktionsumgebung transportiert werden.

Auf Grund der EU-Richtlinie 95/46/EG ist die Ausweitung der erforderlichen technisch-

organisatorischen Maßnahmen auf solche erfolgt, die einerseits Schutz gegen die zufällige

oder unrechtmäßige Zerstörung und den zufälligen Verlust der Daten bieten (Nr. 7: Verfüg-

barkeitskontrolle) und dass andererseits die zu unterschiedlichen Zwecken erhobenen Daten

getrennt verarbeitet werden können (Nr. 8).

4.1.1 Gesetzliche Anforderungen aus § 9 BDSG

Das Bundesdatenschutzgesetz und, in vergleichbarer Form, die Landesdatenschutzgesetze,

verlangen von der verantwortlichen Stelle zwingend, dass technisch-organisatorische Maß-

nahmen ergriffen werden, um sicherzustellen, dass die Anforderungen des Datenschutzes ge-

währleistet werden können. Insbesondere sind Maßnahmen zur Einhaltung der in der Anlage

zum BDSG aufgeführten acht Anforderungen zu treffen.

Für die dort aufgeführten Anforderungen sind im Rahmen des SAP-Einführungsprojektes

aufeinander abgestimmte, geeignete und erforderliche Maßnahmen auf der technischen und

der organisatorischen Ebene zu identifizieren und umzusetzen. Hierzu sind projektbezogen

Risikoanalysen vorzunehmen sowie Maßnahmen zu implementieren, die sowohl auf der or-

ganisatorischen als auch auf der technischen Ebene greifen. Die Maßnahmen sollen unzuläs-

sige und zweckwidrige Verarbeitung personenbezogener Daten verhindern und - soweit er-

forderlich/möglich – auch Missbrauch nachträglich feststellbar machen. Auf die einschlägigen

Projektschritte, an die insbesondere im Rahmen der Vorabkontrolle angeknüpft werden soll,

ist im Kapitel 1 hingewiesen worden.

Die aufeinander abgestimmte Form der technischen und organisatorischen Maßnahmen soll

verhindern, dass technische Maßnahmen wirkungslos bleiben, weil entsprechende organisato-

rische Maßnahmen fehlen. Beispielhaft für einen solchen Fall kann die fehlende organisatori-

sche Umsetzung der Möglichkeiten des SAP-Berechtigungskonzeptes sein, die trotz der viel-

fältigen Schutzmöglichkeiten keinen solchen bietet, etwa weil viele Anwender mit umfassen-

den Berechtigungen ausgestattet wurden. Ebenso wirkungslos können vielfach organisatori-

sche Maßnahmen sein, denen es an einer technischen Unterstützung fehlt. Ein Beispiel hierfür

ist der vergebliche Versuch der Sicherstellung einer Zweckbindung, wenn ein Abfluss der

personenbezogenen Daten aus SAP ERP mittels Download nicht technisch unterbunden wird.



4.1.2 SAP-Funktionalität zur Abdeckung der gesetzlichen

Anforderungen

Die nachfolgende Abbildung listet in der linken Spalte die acht Anforderungen aus der Anla-

ge zu § 9 BDSG auf und stellt in der mittleren Spalte ausgewählte Ansatzpunkte zur Umset-

zung der Anforderungen im SAP ERP-System daneben. Es folgen in der rechten Spalte Hin-

weise auf weiterführende Literatur zu diesem Thema.

Ziele der gesetzlichen

Anforderungen

Ansatzpunkte auf Seiten des SAP

ERP-Systems Weiterführende Hinweise

Es ist – laut Anlage zu

§ 9 BDSG –

1) den Unbefugten der

Zutritt zu Daten-

verarbeitungsanla-

gen, mit denen per-

sonenbezogene Da-

ten verarbeitet oder

genutzt werden, zu

verwehren

(Zutrittskontrolle)

nicht einschlägig und deshalb keine Un-

terstützung seitens der SAP-Software

2) zu verhindern, dass

Datenverarbei-

tungssysteme von

Unbefugten genutzt

werden können

(Zugangskontrolle)

Personenbezogenes Anmeldever-

fahren (problematisch bei mehreren

Benutzern an einem Gerät; dann

müssen zusätzliche Hilfsmittel (wie

Chipkarten und PC-

Sicherheitssysteme sicherstellen,

dass die Anwender ohne Belastung

zwischen ihren Anmeldungen

wechseln können);

Die Verwaltung der Zugangskon-

trolle kann über ein SAP

NetWeaver Identity Management

erfolgen.

Die Verschlüsselung der

SAP_GUI<>Anwendungsserver-

Kommunikation über das DIAG-

Protokoll ist mit SNC möglich.

Damit ist dem unsicheren Transport

der Passwort-„Hash“s abgeholfen

(„Password-Sniffing“).

Die SAP NetWeaver

und SAP ERP Central

Component Sicherheits-

leitfäden

Prüfen Sie die VPN-

Zugriffe! Was ist bei

APPs und Notebooks

und BOYD und mit der

Nutzung außerhalb von

Räumen des Unterneh-

mens?

Auto-Logoff nach einer vorgegebe- SAP NetWeaver Si-




Anforderungen




§ 9 BDSG –

nen Zeit; Bildschirmschoner mit

Kennwortschutz;

cherheitsleitfaden

Single Sign-On Ergänzung und An-

schlussmöglichkeiten für Chipkar-

ten

SAP NetWeaver Si-

cherheitsleitfaden

3) zu gewährleisten,

dass die zur Benut-

zung eines Daten-

verarbeitungssys-

tems Berechtigten

ausschließlich auf

die ihrer Zugriffs-

berechtigung unter-

liegenden Daten

zugreifen können,

und dass personen-

bezogene Daten bei

der Verarbeitung,

Nutzung und nach

der Speicherung

nicht unbefugt ge-

lesen, kopiert, ver-

ändert oder entfernt

werden können

(Zugriffskontrolle)

innerhalb des SAP NetWeaver mit

Hilfe eines angepassten Berechti-

gungskonzeptes für den ABAP-

Stack und den Java-Stack, welches

den Anforderungen von SAP, des

Revisionsleitfadens und des Daten-

schutzes gerecht wird;

Die Verwaltung der Zugriffskon-

trolle kann über ein SAP

NetWeaver Identity Management

erfolgen.

Die Verwaltung von externen Zu-

griffen kann mit dem Konzept Uni-

fied Connectivity (UCON) erfolgen.

SAP Dokumentation

SAP NetWeaver

(help.sap.com)

Lehnert / Stelzner /

John / Otto, SAP-

Berechtigungswesen,

Galileo Press Bonn

2013

Lehnert / Otto / Stelz-

ner, Datenschutz in

SAP-Systemen, Galileo

Press Bonn 2011

Linkies / Karin, „Si-

cherheit und Risikoma-

nagement für SAP-

Systeme“, Galileo Press

Bonn 2010

Esch / Junold / Klüßen-

dorf, Berechtigungen in

SAP ERP HCM, Gali-

leo-Press Bonn 2012

DSAG Prüfleitfaden FI

UCON SAP Help:

http://help.sap.com/saph

elp_nw74/helpdata/de/a

b/35e1c69f744d69a4fcf

4ca93284e0c/content.ht

m?frameset=/de/69/f70a

cfd3424c74809634c85b

3c02e5/frameset.htm

UCON SAP Help:

http://help.sap.com/saph

http://www.sap-press.de/katalog/buecher/titel/autoren/gp/titelID-2971?GalileoSession=65256566A6RhK7ln1zg#1834










Anforderungen




§ 9 BDSG –

elp_nw74/helpdata/de/a

1/18cb4e3cd04ffdb57d2

d602e3da1b9/content.ht

m?frameset=/de/69/f70a

cfd3424c74809634c85b

3c02e5/frameset.htm

SAP Insider Artikel:

http://sapinsider.wispub

s.com/Assets/Articles/2

014/January/SPI_Colum

n_Secure-Your-System-

Communications-with-

Unified-Connectivity

RFC-BLOG:

http://scn.sap.com/com

muni-

ty/security/blog/2010/12

/05/how-to-get-rfc-call-

traces-to-build-

authorizations-for-srfc-

for-free

außerhalb des SAP NetWeaver:

Verschlüsselung im Netz, restrikti-

ve Vergabe von Berechtigungen auf

SAP-Dateien und Tabellen auf der

Ebene der Datenbank und des Be-

triebssystems;

Einsatz der SAP-RAL-Funktion

(Read_Access_Logging), siehe Ka-

pitel 6.2

SAP NetWeaver Si-

cherheitsleitfaden

SAP GRC Access Con-

trol: Analyse und Ad-

ministration von SAP-

Berechtigungskonzep-

ten (siehe Kapitel 6)

die Download-Funktion könnte per

Kundenerweiterung mit einer Be-

rechtigungsprüfung auf Transaktion

und Programm verfeinert und pro-

tokolliert werden

SAP-Hinweise 28777

und 210733

Angebot der Akqui-

net.de: SAST Download

Observer


dass personenbe- innerhalb des SAP ERP mit Hilfe

eines angepassten Berechtigungs-

SAP-

Systemdokumentation




Anforderungen




§ 9 BDSG –

zogene Daten bei

der elektronischen

Übertragung oder

während ihres

Transports oder ih-

rer Speicherung auf

Datenträger nicht

unbefugt gelesen,

kopiert, verändert

oder entfernt wer-

den können, und

dass überprüft und

festgestellt werden

kann, an welche

Stellen eine Über-

mittlung personen-

bezogener Daten

durch Einrichtun-

gen zur Datenüber-

tragung vorgesehen

ist

(Weitergabekon-

trolle)

konzeptes für ABAP und Java;

außerhalb des SAP Systems: Ver-

schlüsselung im Netz (LAN/WAN)

und auf sonstigen Datenträgern;

zur Downloadfunktion und zum

XXL/ALV-Listviewer siehe Ziffer

3.

Druckerkonzept

Kritisch: .pdf-Dokumente erzeugen

und ablegen bzw. mailen

Bei Internet-Anbindung:

Firewall-Konzept und SAP-Router;

SAP NetWeaver Si-

cherheitsleitfaden

Einstellungen der Berechtigungen; SAP NetWeaver Si-

cherheitsleitfaden

Zum geforderten Nachweis zur

Überprüfbarkeit gem. § 10 Abs.4

BDSG (Einrichtung automatischer

Abrufverfahren) können Hinweise

dem Read Access Log entnommen

werden (siehe Kapitel 6.2).

ggf. Stichproben über

Trace


dass nachträglich

überprüft und fest-

gestellt werden

kann, ob und von

wem personenbe-

zogene Daten in

Datenverarbei-

tungssysteme ein-

gegeben, verändert

oder entfernt wor-

den sind

(Eingabekontrolle)

durchgängig in allen Modulen, bei

allen SAP Objekten und bei allen

Daten mit automatischer Erfassung

von Erfasser/Änderer, Datum und

Uhrzeit realisiert;

SAP-

Systemdokumentation,

SAP-

Sicherheitsleitfäden

in den einzelnen Modulen stehen

neben den Anzeigetransaktionen

z.T. zusätzliche Reports für die An-

zeige von Änderungsbelegen zur

Verfügung;

Funktionen zur Anzeige

der Änderungsbelege in

den jeweiligen Fach-

funktionen

ggf. Konfiguration der zu schrei-

benden Änderungsbelege

Empfehlungen der SAP-





Anforderungen




§ 9 BDSG –


dass personenbe-

zogene Daten, die

im Auftrag verar-

beitet werden, nur

entsprechend den

Weisungen des

Auftraggebers ver-

arbeitet werden

können

(Auftragskontrolle)

Im Standard ist keine besondere

Unterstützung vorgesehen.

vgl. Kapitel 5.2.2 und

5.2.6 dieses Leitfadens

Die Kontrolle der Auftragsdaten-

verarbeitung kann durch den Ein-

satz der SAP GRC Process Control

(zusätzliche Software) detailliert

geplant, dokumentiert und ausge-

wertet werden.

GRC Process Control

(siehe Kapitel 6.5)


dass personenbe-

zogene Daten ge-

gen zufällige Zer-

störung oder Ver-

lust geschützt sind

(Verfügbarkeits-

kontrolle)

regelmäßige Datensicherung auf der

Ebene der Datenbank;

Datensicherungskonzept;

an die Aufgaben angepasste Be-

rechtigungen;

Protokollierung der wichtigsten Da-

tenänderungen;

angemessene Schulung der Anwen-

der

SAP-

Systemdokumentation

siehe die allgemeinen



bzgl. Datensicherung


dass zu unter-

schiedlichen Zwe-

cken erhobene Da-

ten getrennt verar-

beitet werden kön-

nen

(Trennungsgebot).

Realisierung über Trennung: der

Systeme, der Mandanten und inner-

halb eines Mandanten durch ent-

sprechende Einrichtung des Berech-

tigungskonzeptes, insbesondere hin-

sichtlich der Anzeige und Auswer-

tung der Daten.

SAP-Broschüre zum Multi-Client-

Betrieb:

http://help.sap.com/bp_bniv2604/B

NI_DE/Documentation/Multi_Clien

t_System_Cookbook_EN.pdf

Die bereitgestellten InfoSets für

Query oder flexible Abgrenzungen

dürfen keine zu unterschiedlichen

Zwecken erhobenen Daten für die

Verarbeitung bzw. Nutzung bereit-

vgl. Prüfleitfäden des

DSAG AK Revision

und Dokumentation



http://help.sap.com/bp_bniv2604/BNI_DE/Documentation/Multi_Client_System_Cookbook_EN.pdf






Anforderungen




§ 9 BDSG –

stellen.

Innerhalb eines Mandanten ist si-

cherzustellen, dass Zugriffe auf die

personenbezogenen Daten außer-

halb des HR/HCM von den

HR/HCM Zugriffen so weit wie

möglich getrennt werden. Die

Kombination der Daten könnte zu

detaillierten personenbezogenen

Leistungs- und Verhaltensauswer-

tungen führen.

Insbesondere kostenrechnungsrele-

vante und produktionsbezogene Da-

ten sind besonders zu betrachten.

Bei Auswertungen von Konzernda-

ten in einem Mandanten mit Perso-

nenbezug (z.B. in einem Shared-

Service-Center) ist zu beachten,

dass eine unternehmensübergrei-

fende Auswertung nur durch eine

entsprechende Rechtsgrundlage le-

gitimiert werden kann.

Das BDSG weist im Anhang zum § 9 auf die Möglichkeit von Verschlüsselungsverfahren hin.

SAP bietet Funktionen zur Verschlüsselung von Transportwegen, näheres findet sich in den

Sicherheitsleitfäden.

4.2 SAP-Fakten, Risiken und Maßnahmen

Mit SAP ERP wird die klassische ABAP-Welt (ABAP Stack) um die JAVA-Welt (JAVA

Stack) ergänzt. Das bedeutet, dass neben die klassischen ABAP-Sicherheitsmaßnahmen nun

die JAVA Sicherheitsmassnahmen treten müssen. Dies trifft im besonderen Maße auch für die

§ 9 BDSG Maßnahmen, nämlich die Authentifizierung der Benutzer, die Autorisierung und

die Protokollierung zu. Die Aktivierung des JAVA-Stacks erfolgt mit dem Instanzparameter:

rdisp/j2ee_start = 1.

Zugriffe von der JAVA Präsentationsschicht können auf die ABAP Daten über die ABAP-

Berechtigungsprüfungen umgeleitet werden. Dies ist typischerweise bei Zugriffen auf die

ABAP-Daten über ein Portal der Fall. Folgender Fall soll die rechtliche Relevanz verdeutli-

chen: Im Portal können etwa über iViews auf dieser Ebene Verknüpfungen von zwei separa-

ten Datenbeständen (etwa denen von Personaldaten zweier Firmen) vorgenommen werden,



die jeder für sich rechtlich zulässig ist (etwa bei dem Zugriff eines Shared Service Centers).

Die Verknüpfung der Personal-Daten zweier Firmen wäre jedoch rechtlich anders zu beurtei-

len und nicht mehr durch ein reines Auftragsdatenverhältnis zweier Firmen an einen gemein-

samen Dienstleister gedeckt.

Auf der JAVA Ebene können jedoch auch eigene Datenbestände verwaltet werden, für die

auch auf JAVA Ebene adäquate Berechtigungsprüfungen im Sinne der Nummern 2-4 der An-

lage zu § 9 BDSG vorgesehen werden.

NWBC (NetWeaverBusinessClient) als Webclient auf der Basis von WebDynproABAP

(WDA).

Alternativ zum Enterprise-Portal (EP) in einem JAVA-Stack und als Ablösung der ITS-

Funktion (Internet Transaction Server) bietet SAP den NWBC an, der über das Internet kom-

muniziert und vom Anwender als HTML-Code im Browser ausgeführt wird. Eine sichere

Konfiguration der Internet-Verbindung ist erforderlich und zu überprüfen

Das nachfolgende Kapitel 4.2.1 befasst sich mit den ABAP spezifischen § 9 BDSG Maßnah-

men.

4.2.1 ABAP-Fakten, Risiken und Maßnahmen

4.2.1.1 Identifizierung und Authentifizierung

SAP-Fakten

Bevor ein SAP ERP-Benutzer auf die Informationen und Funktionen im ERP-System zugrei-

fen kann, muss er sich über das SAP-Logon mittels einer Benutzer-ID und einem Kennwort

anmelden. Durch die Eingabe dieser Daten identifiziert sich der Anwender gegenüber dem

SAP ERP-System und das System kontrolliert, ob der Benutzer berechtigt ist, mit dem Sys-

tem zu arbeiten. In Bezug auf das Kennwort gelten hierbei, sofern keine Änderungen in der

konkreten Installation vorgenommen worden sind, die in den Startparametern getroffenen

Einstellungen. Diese bei der Installation gesetzten Parameterwerte sind für ein Testsystem

vorgesehen und müssen für das Produktivsystem neu eingestellt werden. Für die Verwaltung

der Parameter stehen die Transaktionen RZ10 (Verwaltung von Instanzenprofilen) und RZ11

(Pflege von Profilparametern) oder TU02 (mit Historie) zur Verfügung.

Die für die Benutzeridentifizierung relevanten Parameter werden im Folgenden erläutert. Die

ebenfalls angegebenen Empfehlungen beziehen sich auf einen Grundschutz und Erfahrungs-

werte. Dabei ist zu beachten, dass die Parameter-Werte in Abhängigkeit von der Sicherheits-

politik in jedem Unternehmen durchaus unterschiedlich definiert werden können.

SAP hat die Funktionen mit SAP NW 7.40 erweitert und lässt nun für Benutzer unterschiedli-

che Einstellungen / Policys der Login-Parameter etc. zu, die in der SU01-Benutzerpflege im

Reiter LOGON_DATA im Feld Security_policy einzurichten sind. (siehe Dokument:

20130617_Identity_Security__SAP_NW 7.40_Whats NEW on Security 05.2013)

Mindestlänge des Kennwortes

Der Parameter login/min_password_lng bestimmt die Mindestanzahl der Stellen, die das

Kennwort besitzen muss. Ab SAP NetWeaver 6.40 ist der System-Defaultwert 8.

Zusammensetzung des Kennwortes

Die Parameter login/min_password_letters, login/min_password_digits, und lo-

gin/min_password_specials erlauben bis einschließlich SAP NetWeaver 6.40 eine Festle-



gung der Mindestanzahl von alphabetischen Zeichen, Ziffern und Sonderzeichen im

Kennwort. Groß- und Kleinschreibung ist dabei unbedeutend. Nach SAP NetWeaver 6.40

können alle Unicode Zeichen verwendet werden und das System berücksichtigt dabei

auch Groß-/Kleinschreibung.

Empfohlene Parameter-Werte für die drei Parameter: jeweils “1” (Die Mindestanzahl von

Zeichen, Ziffern und Sonderzeichen beträgt 1 Stelle.) ACHTUNG: bei internationalen In-

stallationen ist wegen der unterschiedlichen Tastaturbelegungen ggf. auf die Anforderung

an ein Sonderzeichen zu verzichten.

Mindestanzahl kleiner und/oder großer Zeichen im Kennwort

Über die Parameter login/min_password_lowercase und login/min_password_uppercase

kann ab SAP NetWeaver 6.40 die Mindestanzahl der kleinen und/oder großen Zeichen im

Kennwort gesteuert werden.

Empfohlene Parameter-Werte für login/min_password_lowercase und lo-

gin/min_password_uppercase:“1“

Wartezeit für einen Kennwortwechsel

Bis einschließlich SAP NetWeaver 6.40 konnte ein Benutzer nur einmal am Tag sein

Kennwort wechseln. Danach kann mit dem Parameter login/password_change_waittime

die Wartezeit auf mehr Tage erhöht werden.

Empfohlene Parameter-Wert für login/password_change_waittime:“1“

Kennworthistorie

Bis SAP NetWeaver 6.40 prüft das SAP System, ob ein neues Kennwort mit den 5 ver-

gangenen Kennwörtern des Benutzers identisch ist. Ist dies der Fall weist das System das

neue Kennwort ab. Ab SAP NetWeaver 6.40 kann über den Parameter lo-

gin/password_history_size die Kennworthistorie auf eine Übereinstimmung mit den letz-

ten 100 Kennworten erweitert werden.

Empfohlene Parameter-Wert für login/password_history_size: “12“

Mindestunterschied zum vorherigen Kennwort

Ab Web AS 6.10 hat der Sicherheitsadministrator die Möglichkeit über den Parameter lo-

gin/min_password_diff festzulegen, wie viel Zeichen sich vom alten zum neuen Kennwort

unterscheiden müssen.

Empfohlene Parameter-Wert für login/min_password_diff: “4“

Kompatibilität eines Kennwortes zu einer geänderten Kennwortregel

Ab SAP NetWeaver 6.40 kann mit dem Parameter lo-

gin/password_compliance_to_current_policy festgelegt werden, dass ein in Gebrauch be-

findliches Kennwort auf die Verträglichkeit mit den geänderten Kennwortregeln überprüft

und ggf. eine Kennwortänderung erzwungen wird..

Empfohlene Einstellung: 1 (Aktivieren)

Verfallsdauer des Kennwortes

Der Parameter login/password_expiration_time bestimmt das Intervall für den Kenn-

wortwechsel bei Dialoganmeldung und ITS-Services, die die Flowlogic verwenden.

Empfohlener Parameter-Wert: “60” oder weniger (Nach maximal 60 Tagen muss der Be-

nutzer sein Kennwort ändern.)



Verfallsdauer eines nicht gebrauchten Kennwortes

Ab SAP NetWeaver 6.40 kann mit dem Parameter login/password_max_idle_productive

die Verfallsdauer eines vom Benutzer vergebenen Kennworts in Tagen festgelegt werden.

Empfohlener Parameter-Wert für login/password_max_idle_productive : “30“

Verfallsdauer eines Initialkennwortes

Ab SAP NetWeaver 6.40 kann mit dem Parameter login/password_max_idle_initial die

Verfallsdauer eines vom Administrator vergebenen Initialkennwortes in Tagen festgelegt

werden.

Empfohlener Parameter-Wert login/password_max_idle_initial: “3“

Verbotene Kennwörter

Über die genannten Einstellungen hinaus können in der Tabelle USR40 Kennwörter defi-

niert werden, die von der Benutzung ausgeschlossen werden (zum Beispiel Ausschluss

von Trivialkennwörtern oder Tastaturkombinationen). Zu erwarten sind 15-40 Einträge

Weitere Anmeldevarianten

Je nach Releasestand gibt es neben der kennwortbasierten Anmeldung weitere Anmelde-

varianten, wie z.B.:

- Zertifikationsanmeldungen über den Browser und den Webserver

- SAP Anmeldeticket (z.B. bei Nutzung des SAP NetWeaver Portals)

- Single Sign On

Siehe dazu auch die Komponente SAP NetWeaver Identity Management, die als selbstän-

dige Anwendung die SAP-Landschaftsweite Verwaltung der Benutzer und ihrer Rollen

unterstützt.

Beenden der SAP-Sitzung

Der Parameter login/fails_to_session_end steuert, nach wie vielen Fehlversuchen der An-

meldung die SAP-Session beendet wird. Das automatische Beenden der Sitzung wird als

ein fehlgeschlagener Anmeldeversuch registriert.

Empfohlener Parameter-Wert: “3” (Nach 3 Fehlversuchen wird die Sitzung beendet.)

Mögliche Anmeldeversuche

Der Parameter login/fails_to_user_lock steuert, nach wie vielen Anmeldeversuchen der

Benutzer gesperrt wird.

Empfohlener Parameter-Wert: “5” (Nach 5 Anmeldeversuchen wird der Benutzer ge-

sperrt.)

Entsperrung um Mitternacht

Ist der Wert für den Parameter login/failed_user_auto_unlock auf “1” gesetzt, so werden

Benutzer, die aufgrund von Falschanmeldungen gesperrt wurden, um Mitternacht ent-

sperrt.

Empfohlener Parameter-Wert: “0” (Es erfolgt kein automatisches Entsperren um Mitter-

nacht.)



Der Datenfluß zwischen SAP-GUI und Anwendungsserver ist mit SNC zu verschlüsseln,

das das Kennwort des Anwenders über das DIA-Protokoll nur ge“HASH“t übertragen

wird (SAP-Hinweis#: 1237762).

Automatisches Abmelden bei Inaktivität

Der Parameter rdisp/gui_auto_logout steuert, nach welcher Zeitspanne in Sekunden ein

automatisches Abmelden erfolgt. Bei der automatischen Abmeldung eines Benutzers ge-

hen nicht gespeicherte Daten verloren, so dass das Risiko des Datenverlustes bei einem

“harten” Abmelden besteht.

Empfohlener Parameter-Wert: “0” (Es erfolgt kein automatisches Abmelden durch das

SAP ERP-System. Anstatt der SAP-seitigen automatischen Abmeldung mit dem Risiko

des Datenverlustes sollte ein SAP-fremder Bildschirmschutz mit Kennwort normalerweise

nach 15 Minuten aktiviert werden.)

Wie der Vorgang der Anmeldung am System durch Parameter gesteuert wird, ist auch die Be-

rechtigungsprüfung bei der Arbeit mit dem SAP ERP-System von der Einstellung in Profilpa-

rametern abhängig. Die nachfolgend aufgeführten empfohlenen Einstellungen beziehen sich

wiederum auf einen Grundschutz. Folgende zentrale Parameter sind hier zu nennen:

Ausschalten von Berechtigungsprüfungen

Durch den Parameter auth/no_check_in_some_cases können Berechtigungsprüfungen un-

terdrückt werden. Die von SAP vorgeschlagene Anzahl von Berechtigungsprüfungen kann

mit Hilfe der Transaktion SU24 reduziert werden. Dies setzt voraus, dass der Parameter

mit “Y” für das Ausschalten von Berechtigungsprüfungen eingestellt ist. Bei Verwendung

des Profilgenerators wird der Wert „Y“ gefordert.

Empfohlener Parameter-Wert: “N” bzw. “Y“ bei Verwendung des Profilgenerators

(Berechtigungsprüfungen werden mit „N“ nicht ausgeschaltet. Bei der Einstellung „Y“

sollte zur Wahrung des Zugriffsschutzes regelmäßig überwacht werden, ob Berechti-

gungsprüfungen deaktiviert wurden. Hierzu kann die Tabelle USOBX_C und das Vorge-

hen gemäß Kapitel 0 verwendet werden.

Berechtigungsprüfung bei RFC

Durch den Parameter auth/rfc_authority_check wird festgelegt, ob Berechtigungsprüfun-

gen bzgl. Remote Function Call (RFC) gegen das Berechtigungsobjekt S_RFC erfolgen.

Empfohlener Parameter-Wert: “1” (Die Berechtigungsprüfung für RFC ist aktiv.)

Grundsätzlich soll die RFC-Berechtigung auf der Ebene der Funktionsbausteine erfolgen.

Siehe Report ZRFC_STATRECS_SECURITY im BLOG:

http://wiki.sdn.sap.com/wiki/display/Snippets/Show+RFC+Workload+Statistic+to+build+

authorizations+for+authorization+object+S_RFC

Berechtigungsprüfung zu ABAP-Sprachelementen

Durch den Parameter auth/system_access_check_off können automatische Berechtigungs-

prüfungen bei bestimmten ABAP-Sprachelementen ausgeschaltet werden. Diese Spra-

chelemente sind z.B. Dateioperationen, Aufruf von Kernelfunktionen oder CPIC-Aufrufe.

Empfohlener Parameter-Wert: “0” (Die Berechtigungsprüfung zu ABAP-

Sprachelementen ist aktiv.)

http://wiki.sdn.sap.com/wiki/display/Snippets/Show+RFC+Workload+Statistic+to+build+authorizations+for+authorization+object+S_RFC

http://wiki.sdn.sap.com/wiki/display/Snippets/Show+RFC+Workload+Statistic+to+build+authorizations+for+authorization+object+S_RFC



Risiken und zu ergreifende Maßnahmen

Um dem Risiko der unzulässigen Zugriffe auf das SAP ERP-System zu begegnen und die

grundsätzlichen Schutzmechanismen der im SAP ERP-System zur Verfügung gestellten In-

strumente zum Berechtigungskonzept zu aktivieren, sind folgende Maßnahmen geeignet:

Definition der Soll-Werte für die Profilparameter und der “verbotenen” Kennwörter auf

der Basis eines unternehmensindividuellen Sicherheitskonzeptes

Anpassen der Werte zu den Profilparametern (Transaktionen RZ10, RZ11)

Pflege der Tabelle der “verbotenen” Kennwörter (Tabelle USR40)

Regelmäßige Überwachung der Parametereinstellungen (Report RSPARAM oder mit Hil-

fe des Audit Information Systems; Transaktion TU02 zur Anzeige der Änderungen)

Regelmäßige Überwachung der Tabelle der “verbotenen Kennwörter” (Transaktion SE17

(Data Browser) für die Tabelle USR40 oder mit Hilfe des Audit Information Systems )

Ergänzend oder alternativ sind - in Abhängigkeit von der gesamten IT-Architektur, in die ein

SAP ERP-System eingebunden ist – weitere und auch externe Sicherheitsprodukte empfeh-

lenswert. Solche sind z.B. SNC (Secure Network Communications - Authentication) oder bei

der Verwendung von Web-Frontends sogenannte X.509 Client Certificates. Für SNC steht auf

dem Service Marktplatz (http://www.service.sap.com/swdc -> Download -> SAP Cryptogra-

phic Software) die Cryptographic Library zum Download zur Verfügung, dabei ist auch der

SAP-Hinweis 397175 zu beachten..

4.2.1.2 Standardbenutzer

Es gibt im SAP ERP-System insgesamt vier Standardbenutzer, deren Funktion im Folgenden

vorgestellt werden. Im Rahmen der zu ergreifenden organisatorisch-technischen Maßnahmen

sind diese Standardbenutzer besonders zu schützen.

SAP*

Der Benutzer SAP* ist der von SAP fest codierte Initialuser und somit für die Installations-

phase mit allen Rechten ausgestattet. Nach erstmaliger Anmeldung (Initialkennwort vgl. SAP

NetWeaver Sicherheitsleitfaden) im SAP-System muss ein neuer Benutzer (eindeutige na-

mentliche Zuordnung) mit umfassenden Berechtigungen angelegt werden, der für die weite-

ren Administrationsaufgaben verantwortlich ist.

Auch wenn weiterführende Aktivitäten des Benutzers SAP* nicht erforderlich sind, darf

SAP* nicht gelöscht werden, da ansonsten, sofern keine weiteren technischen Maßnahmen

ergriffen werden, jeder andere Benutzer sich als SAP* mit dem Standardkennwort anmelden

kann. Bei dieser Anmeldung erhält SAP* dann auch wieder die mit diesem Benutzerstamm-

satz verbundenen besonderen Systemrechte.

Daher empfiehlt SAP, aus Sicherheitsgründen dem Benutzer SAP* alle Berechtigungen zu

entziehen bzw. die Berechtigungen auf reine Anzeigefunktionalitäten zurückzusetzen. Wei-

terhin sollte SAP* der Benutzergruppe "SUPER" zugeordnet werden, um zu verhindern, dass

dieser User leichtfertig gelöscht werden kann. SAP* kann nämlich physisch nicht gelöscht

werden. Wenn jemand z.B. über die SU01 SAP* löscht, erscheint dieser zwar nicht mehr in

der Benutzerliste, existiert aber trotzdem noch weiter im System. D.h. mit einer Anmeldung

als SAP* und dem bekannten Kennwort kann sich in diesem Fall jeder einen SAP_ALL-

Zugang verschaffen.

http://www.service.sap.com/swdc



Werden die vorgenannten Maßnahmen nicht ergriffen, kann eine Neuanmeldung über folgen-

den Parameter unterbunden werden:

LOGIN/NO_AUTOMATIC_USER_SAPSTAR mit dem Wert „1“

(automatischer Benutzer SAP* ist deaktiviert)

Ab SAP NetWeaver 7.0 wurde der Defaultwert des Profilparameters auf 1 geändert, damit ist

der Benutzer SAP* automatisch deaktiviert.

SAPCPIC

Der Benutzer SAPCPIC ist ein eingerichteter Standarduser der SAP. Er kann nicht zur An-

meldung im Dialog verwendet werden, erlaubt aber den Aufruf einiger Programme und Funk-

tionsbausteine im SAP ERP-System. Er wird benötigt, um Performance-Daten zu sammeln,

externe Hintergrundprogramme zu starten und Werte für das Computer Center Management

System (CCMS) zurückzuliefern.

Als Schutzmaßnahme kann neben der Änderung des Standardkennworts auch die Sperrung

des Benutzers erwogen werden. Bei Durchführung dieser Maßnahmen sollte SAP-Hinweis

29276 beachtet werden.

Grundsätzlich sollten CPIC-Benutzer, auch wenn eine Anmeldung im Dialog nicht möglich

ist, über funktionsbezogenen Rollen/Profile verfügen.

DDIC

Neben SAP* ist der Benutzer DDIC durch SAP definiert. Der Benutzer DDIC wird für die

Pflege des ABAP-Dictionaries und der Softwarelogistik verwendet. Daher sind auch für die-

sen Benutzer weitreichende Systemrechte hinterlegt, die über die in Benutzerprofilen definier-

ten Rechte hinausgehen.

DDIC wird im Rahmen der Installation nur in den Mandanten 000 und 001 erstellt (Initial-

kennwort vgl. SAP NetWeaver Sicherheitsleitfaden). Für andere Mandanten muss der Benut-

zer DDIC, sofern erforderlich, angelegt werden.

Da es sich bei DDIC auch um einen Benutzer handelt, der Sonderrechte besitzt und bei dem

eine eindeutige personenbezogene Zuordnung i.d.R. erschwert ist, unterliegt seine Nutzung

auch besonderen Anforderungen hinsichtlich der Nachvollziehbarkeit der durchgeführten Ak-

tivitäten.

Auch für den Benutzer DDIC ist das Profil SAP_ALL aus Datenschutzsicht nicht zulässig. Es

wird nur in den Mandanten 000 und 001 benötigt und sollte nur bei Bedarf freigeschaltet wer-

den. Zur Ausübung der erforderlichen Aktivitäten (z.B. Starten und Stoppen von Tasks im

Rahmen des System-Monitorings) sollten funktionsbezogene Profile/Rollen erstellt werden.

Weiterhin sind organisatorische Festlegungen zu treffen, über die eine personenbezogene

Nutzung (Eindeutigkeit der Verantwortung) sichergestellt werden kann.

Um den Benutzer DDIC zu schützen, muss sein Standardkennwort geändert werden. Er muss

gesperrt werden, solange er nicht benutzt wird. Allerdings darf weder der Benutzer noch seine

Profile gelöscht werden. DDIC wird für bestimmte Aufgaben bei der Installation und bei Up-

grades, für die Softwarelogistik und das ABAP Dictionary benötigt. Das Löschen von DDIC

führt zu Funktionsverlusten in diesen Bereichen.

TMSADM

Für den automatisch angelegten System/Batch-Benutzer TMSADM für das Transportma-

nagement-System ist das Standardkennwort zu ändern:



Siehe:

http://help.sap.com/saphelp_nw73/helpdata/de/e7/c5066e05034f4a9cbcf9c84b513b7b/

frameset.htm und den Hinweis # 761637.

EarlyWatch

Der User EARLYWATCH ist der Dialogbenutzer für den Earlywatch-Service im Mandanten

066. Mit diesem Benutzer arbeiten die EarlyWatch-Experten der SAP; er wird für die Early-

Watch-Funktionen (Monitoring und Performance) benötigt.

Zum Schutz dieses Benutzers vor unberechtigtem Zugriff ist das Initialkennwort zu ändern.

Weiterhin sollten auch hier technische und organisatorische Maßnahmen ergriffen werden,

über die sichergestellt ist, dass ausschließlich Funktionen ausgeführt werden, die für die Nut-

zung dieses Benutzers vorgesehen sind.

Batch User / WF-BATCH

Batch User sind grundsätzlich als technische User einzurichten. Sie sind sämtlichen relevan-

ten Verfahren zuzuordnen. Zusätzlich sind diese jeweils auf die notwendigen Berechtigungen

einzuschränken.


Um grundsätzlich dem Risiko der unzulässigen Zugriffe auf das SAP ERP-System zu begeg-

nen, sind spezielle technische und organisatorische Maßnahmen zu ergreifen, über die sicher-

gestellt ist, dass eine unberechtigte Kenntnisnahme, bzw. versehentliche/absichtliche Manipu-

lation von Daten unterbunden wird. Dies gilt auch und vor allem in Bezug auf Sonderbenut-

zer.

Folgende Maßnahmen sollten ergriffen werden:

Erstellung funktionsbezogener Rollen/Profile für die o. g. Benutzer

Sperrung von Benutzern, die im Tagesgeschäft nicht benötigt werden, bzw. nicht aktiv

sind

Setzen der Systemparameter (vgl. z.B. Unterbindung der Anmeldung mit dem Benutzer

SAP*) zur Unterbindung unzulässiger Anmeldungen

Regelmäßige Überwachung der Aktivitäten der vorgenannten Benutzer, z.B: bezüglich

der Kennungen etc. mit dem Report RSUSR003.

Festlegung/Erstellung von Verfahrensanweisungen zur Handhabung der Sonderbenutzer

zur Unterstützung der technischen Maßnahmen

4.2.1.3 Benutzerberechtigungskonzept: ausgewählte

Berechtigungsobjekte

Im Folgenden werden wichtige Berechtigungsobjekte aus dem Modul HCM und der Basis

behandelt. Die komplette Dokumentation der Berechtigungsobjekte ist im Profilgenerator

(PFCG) durch Doppelklick auf das Berechtigungsobjekt, mit der Transaktion SU03 bzw. über

das Benutzerinformationssystem (Transaktion SUIM) zu erhalten.

Berechtigungsobjekte im HCM

Das Berechtigungsobjekt P_ORGIN (HR: Stammdaten) wird im Rahmen der Berechtigungs-

prüfung für Personaldaten (Stamm- und Zeitdaten) verwendet. Eine Prüfung findet grundsätz-

lich statt, wenn HR-Infotypen bearbeitet werden sollen. Wesentlich sind hierbei die organisa-

http://help.sap.com/saphelp_nw73/helpdata/de/e7/c5066e05034f4a9cbcf9c84b513b7b/frameset.htm

http://help.sap.com/saphelp_nw73/helpdata/de/e7/c5066e05034f4a9cbcf9c84b513b7b/frameset.htm



torische Zuordnung des Mitarbeiterstammes, die Sicht auf Daten (Infotypen) und der Berech-

tigungslevel.

Das Berechtigungsobjekt besteht aus folgenden Feldern:

AUTHC Berechtigungslevel

INFTY Infotyp

SUBTY Subtyp

PERSA Personalbereich

PERSG Mitarbeitergruppe

PERSK Mitarbeiterkreis

VDSK1 Organisationsschlüssel

Weiterhin sind hinsichtlich des Berechtigungslevels (vgl. bzgl. weiteren Details die Doku-

mentation des Berechtigungsobjekts) u.a. folgende Werte von Bedeutung:

R Lesen

W Schreiben

M Lesen bei Eingabehilfen (Matchcode) (Empfehlung: Man sollte

nie nur W oder nur R vergeben; sonst erhalten die Anwender

keine Suchhilfe (früher Matchcodesuche) und müssen immer di-

rekt die Personalnummer eingeben.)

S gesperrt schreiben, entsperren, sofern der letzte Änderer des

Satzes nicht der aktuelle Benutzer ist.

E gesperrt schreiben

D ändern des Sperrkennzeichens

* alle Operationen

Neben dem Berechtigungsobjekt P_ORGIN gibt es noch 4 weitere Berechtigungsobjekte die

ggf. zusätzlich oder alternativ beim fachseitigen Zugriff auf Personalstammdaten geprüft

werden. Diese sind:

P_ORGINCON HR: Stammdaten mit Kontext prüfung auf ein strukturelles Be-

rechtigungsprofil

P_ORGXX HR: Stammdaten–erweiterte Prüfung

P_ORGXXCON HR: Stammdaten–erweiterte Prüfung mit Kontext prüfung auf

ein strukturelles Berechtigungsprofil

P_PERNR HR: Stammdaten-Personalnummernprüfung

Die Berechtigungsobjekte P_ORGINCON und P_ORGXXCON erlauben die zusätzliche Prü-

fung eines strukturellen Berechtigungsprofils aus der Tabelle T77PR. Damit ist die Differen-

zierung / Datentrennung bezogen auf den Anwender möglich.

Dagegen ist das Berechtigungsobjekt P_PERNR speziell zur Einschränkung des Zugriffs auf

eine Personalnummer (im Falle der ESS Szenarien) oder des Ausschlusses der Pflege einer

Personalnummer (um die Pflege der eigenen Daten zu untersagen).

Zusätzlich zu den oben genannten Berechtigungsobjekten für die HCM Stammdaten ist für

die Stammdatenpflege eine Berechtigung für die jeweilige Transaktion, z.B. PA30 (Personal-

stamm pflegen), erforderlich.



Außerdem ist zu berücksichtigen, dass ggf. weitere Berechtigungsobjekte (bspw. HR:Bewer-

ber oder FI:Reiseplanung) zu Prüfzwecken herangezogen werden sollten (für weitere Details

siehe Dokumentation der SAP-Berechtigungsobjekte).

Berechtigungsobjekt P_ABAP

Für den Schutz des Zugriffs auf Reports ist im SAP ein Berechtigungsobjekt vorgesehen, das

Objekt S_PROGRAM (ABAP: Programmablaufprüfungen, Objektklasse BC_C).

Über das Objekt S_PROGRAM wird grundsätzlich gesteuert, ob und auf welche Reports mit

den Transaktionen SA38, SE38 und START_REPORT zugegriffen werden kann, sofern der

Benutzer eine Zugriffsberechtigung zu der Berechtigungsgruppe des Reports (siehe Details

unter Kapitel 4.2.1.5.4) besitzt.

Im HCM steuert zusätzlich das Berechtigungsobjekt P_ABAP (HR: Reporting) die Berechti-

gungsprüfungen während der Reportausführung. Für die Ausführung der Reports sind keine

Berechtigungen für das Objekt erforderlich, stattdessen soll es die die Performance bei der

Ausführung verbessern, bzw. Berechtigungen für die Ausführung bestimmter Reports ertei-

len, die über die vorhandenen Berechtigungen nicht möglich wären. Der zweite Fall kommt

häufiger vor, z.B. bei den Reports der Reisekostenabrechnung, oder der Zahlungsträgerpro-

gramme des Rechnungswesens.

Über das Objekt P_ABAP wird gesteuert, auf welche Weise die Objekte:

HR: Stammdaten (P_ORGIN/P_ORGINCON)

HR: Stammdaten - erweiterte Prüfung – (P_ORGXX/P_ORGXXCON)

strukturelle Berechtigungsprüfung in spezifischen Reports

zur Prüfung der Berechtigungen für HCM-Infotypen verwendet bzw. reduziert werden. Durch

eine entsprechende Aussteuerung der Felder:

REPID (Reportname) < auch generisch >

COARS (Vereinfachungsgrad der Berechtigungsprüfung)

1 = Zusätzliche Berechtigungen werden ebenfalls berücksichtigt

2 = während der Reportausführung findet keine Berechtigungsprüfung statt.

können Berechtigungsprüfungen übersteuert werden. Eine genaue Erläuterung zur richtigen

Ausprägung des Berechtigungsobjekts P_ABAP finden Sie in SAP-Hinweis 138526.

Hintergrund für die Erstellung dieses Berechtigungsobjektes durch die SAP ist eine erhöhte

Verarbeitungsgeschwindigkeit durch die “Ausschaltung” von weiteren Berechtigungsprüfun-

gen.

Das Berechtigungskonzept sollte eine Sondergenehmigung für die Nutzung der P_ABAP-

Berechtigungsprüfung vorsehen.

Grundsätzlich ist somit die Ausprägung dieses Berechtigungsobjektes kritisch zu hinterfragen,

um sicherzustellen, dass keine unberechtigte Kenntnisnahme personenbezogener Daten über

das Reporting erfolgen kann. Immer wieder wird auch das Programm SAPDBPNP: Logische

Datenbank PNP im P_ABAP in das Feld REPID eingetragen. Dies hat zur Folge, dass im Re-

porting keine HCM-Berechtigungsprüfung mehr stattfindet.

Berechtigungsobjekt P_TCODE

Das Berechtigungsobjekt P_TCODE stellt ein anwendungsspezifisches Berechtigungsobjekt

dar, das ein Vorläufer des Berechtigungsobjektes S_TCODE war. Über die Ausprägung des

Berechtigungsobjektes P_TCODE (HR: Transaktionscode) kann der Zugriff auf verschiedene



HCM-Transaktionen geschützt werden. Dabei ist zu beachten, dass dieses Objekt nicht bei je-

der HCM-Transaktion genutzt wird, so dass zusätzlich das Objekt S_TCODE verwendet wer-

den muss.

Als Anhaltspunkt, welche Transaktionen über die Ausprägung des Objektes P_TCODE ge-

schützt werden, können die Tabellen USOBT und USOBX verwendet werden. Sie werden mit

der Transaktion SE17 und der Angabe „P_TCODE“ für das Objekt ausgewertet.

Berechtigungsobjekt S_TCODE

Über das Berechtigungsobjekt S_TCODE wird beim Aufruf von Transaktionen geprüft, ob

der Benutzer zur Ausführung der angewählten Funktion berechtigt ist. Zu diesem Berechti-

gungsobjekt ist das Feld Transaktionscode (TCD) definiert.

Durch eine funktionsbezogene Ausprägung dieses Berechtigungsobjektes ist es somit auf ei-

ner ersten Stufe möglich, Zugriffschutzmaßnahmen abzubilden. Sofern eine differenzierte

Ausprägung dieses Objektes nicht vorgenommen wird, werden im weiteren Verlauf von Be-

rechtigungsprüfungen die modul-, bzw. funktionsspezifischen Objekte herangezogen.

Eine entsprechende Ausprägung aller miteinander korrespondierenden Objekte ist demzufolge

erforderlich, um sicherzustellen, dass die Anforderungen des BDSG hinreichend abgedeckt

sind.

Mithilfe der Transaktionen SE38, SA38 und START_REPORT ist es möglich die meisten im

Standard verfügbaren Reports auszuführen ohne das eine Prüfung auf eine entsprechende Be-

rechtigung erfolgt. Dies kann über die in Abschnitt 4.2.1.5.4 beschrieben Schutzmaßnahmen

verhindert werden.

Die Transaktion sub% sollte nicht an Benutzer vergeben werden. Mit dieser Transaktion las-

sen sich beliebige Transaktionen durch den Benutzer starten. Dabei wird nicht überprüft, ob

der Benutzer über die Berechtigungen zum Starten der entsprechenden Transaktionen verfügt

(siehe SAP-Hinweis 842915). Mit der sub% lassen sich auch Reports ausführen, allerdings

findet hier die Prüfung auf die Berechtigungsgruppe statt.

Tabelle TSTCA Transaktion SE93

In der Tabelle TSTCA sind sämtliche Transaktionen mit zusätzlichen Prüfobjekten hinterlegt.

Die Tabelle kann mit Hilfe der Transaktion SE17 ausgewertet werden.

Die Pflege der Tabelle unterliegt, da hier mandantenunabhängige Eintragungen gepflegt wer-

den, den Mechanismen des CTS/CTO (Change Transport System/Change Transport Organi-

zer).

In der Tabelle wird die „Eingangsprüfung hinterlegt“. Dabei wird kontextfrei geprüft ob das

Objekt mit den ausgeprägten Werten im Benutzerpuffer vorhanden ist. Eine sachverhaltliche

Prüfung (Aktivität in Bezug auf ein Merkmal) findet im Programmlauf statt. In der Tabelle

USOBT kann die Prüfung für Objekte ausgeschaltet werden, dies gilt aber nicht für HCM und

Basisobjekte.

Zu beachten ist, dass Zugriffsberechtigungsprüfungen umgangen werden können, indem der

Authority-Check (Berechtigungsprüfung) in den der Transaktion zugrunde liegenden ABAP-

Programmen ausgeschaltet wird.

Umwandlung von Reports in Transaktionen

SAP bietet die Möglichkeit, auf zwei verschiedene Arten Reports Transaktionen zuzuordnen.

Die erste wird automatisch durchgeführt, wenn der Report in ein Bereichsmenü oder in das

Menü einer Rolle eingegliedert wird. Allerdings besteht zwischen dem Report und dem

Transaktionsnamen keine sprechende Verbindung, da SAP die Transaktionen laufend durch-



nummeriert (Aufbau S_XXX_xxxxxxxx). Daher bietet sich die zweite Art an: Reports werden

dabei bei einer eigenerstellten Transaktion hinterlegt und durch den Aufruf dieser Transaktion

gestartet. Bei beiden Methoden ist zu beachten, dass der Benutzer die Reports auch weiterhin

über das “normale” Reporting starten kann, wenn er Rechte für die Transaktionen wie SA38

oder SE38 besitzt. Das Starten ist auch indirekt aus SE80 und SE84 und verschiedenen

weiteren Transaktionen möglich.

Aus datenschutzrechtlicher Sicht ist in diesem Zusammenhang

a) eine Konzeption zum Schutz der einzelnen Reports zu erarbeiten (Berechtigungskonzept

S_Program, Verwaltungsreport RSCSAUTH) und

b) zu hinterfragen, ob und in wie weit über die dargestellten Möglichkeiten ggf. Berechti-

gungsprüfungen unterlaufen werden können.

Berechtigungen für die Transaktionen SA38 (ABAP Programmausführung), SE38 (ABAP

Editor) und START_REPORT sollten an die Benutzer der Fachabteilungen nicht vergeben

werden. Stattdessen empfiehlt es sich, für die freigegebenen Reports Transaktionscodes zu

generieren. Den einzelnen Benutzern ist der Zugriff auf diese Transaktionscodes über das Be-

nutzermenü zu ermöglichen (Berechtigungsobjekt S_TCODE).

Berechtigungsobjekt S_TABU_DIS, S_TABU_NAM S_TABU_CLI und S_TABU_LIN

Über das Berechtigungsobjekt S_TABU_DIS ist der Zugriff auf die Tabellenpflege – mit

Transaktionen wie z.B. SE16, SE16N, SE17, SM30 bis SM34 - und über das Berechtigungs-

objekt S_TABU_CLI ist der Zugriff auf die mandantenübergreifende Tabellenpflege gesteu-

ert. Zusätzlich zu einer entsprechenden Ausprägung dieser genannten Objekte sind Transakti-

onsberechtigungen zur Tabellenpflege (vgl. S_TCODE) erforderlich.

Das Berechtigungsobjekt S_TABU_DIS besteht aus den Feldern Aktivität und Berechti-

gungsgruppe. Über die Ausprägung des Feldes Aktivität kann die Art des Zugriffs auf Tabel-

len (anzeigen oder ändern) gesteuert werden. Das Feld Berechtigungsgruppe dient zur Ein-

schränkung des Zugriffs auf bestimmte Tabellen.

Das Berechtigungsobjekt S_TABU_NAM mit dem Feld: TABLE: Tabellenname bezieht

sicht immer auf eine einzelne Tabelle und ersetzt für spezifische Tabellen das Berechtigungs-

objekt S_TABU_DIS, wenn die Tabellenberechtigungsgruppen eine zu weite und nicht ge-

wollte Zugriffsberechtigungen ermöglichen. Das Objekt wird nur dann geprüft, wenn die Berechti-

gungsprüfung auf das Objekt S_TABU_DIS fehlgeschlagen ist.

Das Berechtigungsobjekt S_TABU_CLI besteht aus dem Feld Kennzeichen für mandanten-

unabhängige Pflege.

Das Berechtigungsobjekt S_TABU_LIN definiert Berechtigungen für die Anzeige oder Pfle-

ge von Tabelleninhalten. Das Objekt ergänzt die Berechtigungsobjekte S_TABU_DIS und

S_TABU_CLI:

Während S_TABU_DIS auf der Ebene von Customizing-Tabellen oder Pflegeviews wirkt,

kann man mit S_TABU_LIN den Zugriff auf einzelne Tabellenzeilen regeln. Voraussetzung

für die Verwendung des Berechtigungsobjekts ist die Existenz von Organisationskriterien.

Organisationskriterien stehen für betriebswirtschaftliche organisatorische Einheiten (z.B. ein

Land oder ein Werk) und stellen eine Verbindung zwischen Tabellen-Schlüsselfeldern und

den Berechtigungsfeldern von S_TABU_LIN her. Sie werden innerhalb des Customizings

(IMG-Pfad Basis -> Systemadministration -> Benutzer und Berechtigungen -> Zeilenbezoge-

ne Berechtigungen -> Organisationskriterien definieren) definiert.



Eine Berechtigung auf Zeilenebene wirkt nur dann, wenn das zugehörige Organisationskrite-

rium im betreffenden Mandanten eingeschaltet ist (Basis -> Systemadministration -> Benutzer

und Berechtigungen -> Zeilenbezogene Berechtigungen -> Organisationskriterienaktivieren).

An dieser Stelle wird empfohlen die Transaktionen SE16/SE16N/SE17 nur sehr eingeschränkt

an Benutzer zu vergeben. Die fachliche Zugriffsbegrenzung und die Datentrennung ist nicht

mehr gewährleistet. Wir empfehlen dem Datenschutzbeauftragten jede Verwendung kritisch

zu hinterfragen.

Falls eine Vergabe erfolgt, ist aus datenschutzrechtlicher Sicht darauf zu achten, dass zur

Vermeidung eines unzulässigen Zugriffs auf personenbezogene Daten mittels der Tabellenan-

zeige SE16/SE17 auf eine restriktive Vergabe des Zugriffs auf Berechtigungsgruppen sol-

cher Tabellen (z.B. den Infotypen in den PA-Tabellen) geachtet wird.

Eine Zuordnung von Tabellen zu Berechtigungsgruppen kann über die Transaktion SE17 und

Angabe der Tabelle TDDAT oder die Transaktion SE53: Generieren Tabellenpflegedialog

abgerufen werden.

Berechtigungsobjekt S_TOOLS_EX

Über das Berechtigungsobjekt S_TOOLS_EX (Objektklasse BC_A) können Berechtigungen

vergeben werden, die zur Anzeige fremder Statistikaufzeichnungen bei der Nutzung von Mo-

nitoring-Tools dienen.

Dabei enthält dieses Objekt ein Feld (AUTH), über das Berechtigungsnamen vergeben wer-

den können. Durch den Eintrag S_TOOLS_EX_A wird der Zugriff auf fremde Statistiken

möglich.

Um zu verhindern, dass hier eine Leistungs- und Verhaltenskontrolle ermöglicht wird, sollte

dieser Zugriff nur äußerst restriktiv vergeben werden. Auswertungen über Benutzerverhalten

sind nur in begründeten und abgestimmten Ausnahmefällen zulässig.

Die Mitbestimmungsrechte der Arbeitnehmervertretung sind bei der Vergabe dieser Berechti-

gung besonders zu beachten.

Berechtigungsobjekt S_SCD0

Das Berechtigungsobjekt S_SCD0 (Änderungsbelege, Objektklasse BC_Z) ermöglicht den

Zugriff auf Änderungsbelege und Änderungsbelegobjekte. Änderungsbelege werden z.B. bei

Stammdaten- und Benutzerstammsatzänderungen erzeugt.

Änderungsbelege (Stammdaten) gehören zu den nach § 257 HGB aufbewahrungspflichtigen

Unterlagen (Dauerbelege). Im SAP besteht die Möglichkeit über die entsprechende Ausprä-

gung des Berechtigungsobjektes S_SCD0 (vgl. Benutzerberechtigungskonzept), Änderungs-

belege und -objekte zu pflegen (= verändern) bzw. zu löschen und somit direkten Einfluss auf

die Protokollierung zu nehmen.

Die Mitbestimmungsrechte der Arbeitnehmervertretung sind bei der Vergabe der Berechti-

gung zum Anzeigen der Änderungsbelege besonders zu beachten.

Objekte zur Benutzer- und Berechtigungspflege (S_USER_xxx)

Die Berechtigungsobjekte zur Benutzer- und Berechtigungspflege (vgl. im Einzelnen unter

Kapitel 4.2.1.6.1) erlauben eine differenzierte Gestaltung des Prozesses der Benutzereinrich-

tung, -pflege usw. sowie der Vergabe der gewünschten Berechtigungen an die Benutzer.

Unter datenschutzrechtlichen Gesichtspunkten ist besonders darauf zu achten, dass deren

Ausprägungen sorgfältig vorgenommen werden und ausschließlich diejenigen Personen Zu-

griff bekommen, die hierzu autorisiert werden sollen.



Berechtigungsobjekt S_GUI und XXL-Listviewer

SAP bietet die Möglichkeit, die unterschiedlichsten Auswertungen per Download oder den

XXL-Listviewer aus der ”gesicherten SAP-Umgebung” auf den PC zu übertragen und dort

ohne zusätzliche Kontrollen weiterzuverarbeiten. Grundsätzlich sind alle Daten, die aufgrund

der an den Benutzer vergebenen Berechtigungen am Bildschirm angezeigt werden, auch auf

den PC übertragbar. Die Funktionen des XXL-Listviewers können derzeit nur eingeschränkt

über das Berechtigungsobjekt S_OLE_CALL geschützt werden

Zum Schutz der Downloadfunktionalität sieht SAP das Berechtigungsobjekt S_GUI vor. Zu

diesem Objekt ist derzeit das Feld “Aktivität” definiert. Der Wert “61” berechtigt dazu, alle

Listen, die man am Bildschirm anzeigen kann, als lokale Datei zu sichern. Es lassen sich über

einen User-Exit (EXIT_SAPLGRAP_001 mit dem Include ZXFILU01)weitere Berechti-

gungsprüfungen (z.B. auf gestartete Reports oder Transaktionen) hinzufügen.

Siehe auch SAP-Hinweise 28777, 210733 und 510399.

Berechtigungsobjekt S_SPO_DEV

Über das Berechtigungsobjekt S_SPO_DEV können die Berechtigungen zum Drucken auf

namentlich vorgegebenen Druckern vergeben werden. Durch eine generische Vergabe von

Druckernamen kann auf diese Art und Weise z.B. festgelegt werden, dass ein Benutzer des

HCM-Moduls ausschließlich auf Druckern der Personalabteilung drucken kann. Risiken birgt

das Drucken auf Druckern, die nicht in Sichtweite stehen, bzw. für die kein SECURE-PRINT-

Verfahren zum Einsatz kommt.

Berechtigungsobjekt S_ADMI_FCD

Mit der Berechtigung S_ADMI_FCD kann die Mandantengrenze überschritten werden; d.h.

Spool- und TemSe-Druck- und Datenobjekte können in anderen Mandanten verwaltet und

administriert werden, wenn die Systemadministrationsfunktion: SPAD: Berechtigung zur

mandantenübergreifenden Spooladministration bzw. SPTD: Berechtigung zur mandanten-

übergreifenden TemSe-Administration in der Berechtigung enthalten sind.


Um dem Risiko eines unberechtigten Zugriffs auf personenbezogen Datenbestände vorzubeu-

gen, ist es erforderlich, über die Ausprägung der vorgenannten Berechtigungsobjekte sicher-

zustellen, dass lediglich die Daten gelesen, bzw. gepflegt werden können, die im Aufgaben-

gebiet des entsprechenden Arbeitsplatzes liegen.

Beim Einsatz von HCM ist somit über eine entsprechende Ausprägung des Benutzerberechti-

gungskonzeptes sicherzustellen, dass der Zugriff auf die o.g. Objekte sowie alle anderen Ob-

jekte der Klasse Personalwesen restriktiv und unter Funktionstrennungsgesichtspunkten er-

folgt. Weiterhin sollte der Zugriff auf alle Infotypen äußerst restriktiv gehandhabt werden.

Somit ist insbesondere sicherzustellen, dass:

technische und organisatorische Maßnahmen geschaffen werden, die den ändernden und

löschenden Zugriff auf Änderungsbelege verwehren. Hier sind v.a. auch unerwünschte

Zugriffsmöglichkeiten über Reports, z.B. RSCDOK99: Löschen von Änderungsbelegen

zu verhindern

der Download von Daten nur in zulässiger Weise erfolgt, d.h. es muss sichergestellt sein,

dass eine hinreichende Ausprägung des Berechtigungskonzeptes lediglich einen funkti-

onsbezogenen Zugriff auf Daten ermöglicht



Zweckentfremdung der Daten über Download und/oder XXL-/ ALV-Listviewer und an-

schließende Verarbeitung zu datenschutzrechtlich nicht zulässigen Zwecken sowie unter

unzulässigen Bedingungen (wie etwa mangelnder Prüfbarkeit) ausgeschlossen wird.

der Ausdruck in .pdf-Dokumente mit einer Ablage im Verzeichnis-Baum und einem

Mailversand nicht möglich ist.

Tabellenanzeige- und -pflegeberechtigungen über die Ausprägung des Feldes Berechti-

gungsgruppe hinreichend eingeschränkt werden

der Zugriff bzgl. Änderungsmöglichkeiten zu Transaktionen und Programmen äußerst

restriktiv gehandhabt, bzw. durch organisatorische Regeln unterbunden wird (inkl. Erstel-

lung einer Organisationsanweisung bzgl. der Verfahrensdokumentation bei durchzufüh-

renden Pflegemaßnahmen)

das Löschen von Änderungsbelegen grundsätzlich im Produktivsystem (Ausnahme Not-

falluser) unterbunden wird, bzw. nur durch die vorgesehenen Archivierungs- bzw. Reor-

ganisationsprogramme durchgeführt wird

eine restriktive Ausprägung des Feldes Berechtigungslevel im Hinblick auf den Zugriff

auf HCM Infotypen erfolgt

die Ausprägungen der Berechtigungsobjekte P_TCODE und S_TCODE sinnvoll aufei-

nander abgestimmt sind

Sollte aufgrund der vorhandenen Personalstärke eine differenzierte, an Funktionstrennungsge-

sichtspunkten orientierte Ausprägung verschiedener der vorgenannten Berechtigungsobjekte

nicht realisierbar sein, empfiehlt es sich, über Organisationsanweisungen die Nutzung von

nachgelagerten Kontrollen festzulegen. Deren Einhaltung gilt es in regelmäßigen Abständen

von einer neutralen Stelle zu kontrollieren.

4.2.1.4 Benutzerberechtigungskonzept: ausgewählte Profile

Um die notwendigen Aufgaben in Bezug auf die Systemadministration durchführen zu kön-

nen, sind sog. Systemadministratoren einzurichten. Diese verfügen dabei naturgemäß über

weitreichende Berechtigungen. SAP sieht hierzu im Standard i.d.R. zur Nutzung im Testsys-

tem die nachfolgenden Auslieferungsprofile vor, die jedoch unbedingt den Anforderungen im

Unternehmen entsprechend angepasst werden müssen.

In Notfällen, bzw. bei Put- oder Releasewechseln, muss ggf. temporär eine Vergabe von um-

fassenden Berechtigungen (Profilen oder Rollen) erfolgen. Dabei ist zu beachten, dass die

Vergabe dieser Berechtigungen durch eine andere Person erfolgt (4-Augen-Prinzip) und eine

Deaktivierung dieser Nutzer bzw. Berechtigungen außerhalb der erforderlichen Nutzungszeit

gewährleistet ist.

Notfallzugriffe mit kritischen Usern stellen ein zentrales Problem der Administration dar. Die

Überwachung sollte neben dem Vier-Augen-Prinzip und dem Einschalten des Security Audit

Logs auch ein einschlägiges Genehmigungsverfahren und eine detaillierte nachfolgende

Auswertung umfassen. Die GRC Access Control (kostenpflichtige Komponente s. Kapitel 6)

stellt eine entsprechende Super User Management Lösung bereit.

Profil SAP_ALL

Mit diesem Profil sind nahezu uneingeschränkte Zugriffe auf das gesamte System (inkl. An-

wendungen) möglich. Dies beinhaltet v.a. auch den Zugriff auf die Werkzeuge der Anwen-

dungsentwicklung. Somit kann bei der Nutzung verschiedener in diesem Profil enthaltenen

Berechtigungen die BDSG-konforme Datenspeicherung und -verarbeitung genauso gefährdet



werden wie die Ordnungsmäßigkeit der Buchführung. Des öfteren werden die SAP_ALL-

Berechtigungen unter anderem Namen versteckt. Hilfreich ist hier der Check des SOSS-

Reports auf Benutzer mit besonders vielen Berechtigungen. Check 0027 zeigt Benutzer mit

„*“ (Wildcards) in den Berechtigungswerten; Check 0028 zeigt die Benutzer mit den meisten

Rollen und Check 0029 zeigt die Benutzer mit den meisten Profilen.

Das Profil kann bei Bedarf vom Kunden neu erzeugt werden.

Profil SAP_NEW

Über das Profil SAP_NEW werden Berechtigungen für neue Berechtigungsobjekte zu bereits

vorhandenen Funktionen zur Verfügung gestellt. Dabei sind die einzelnen Felder der im Profil

SAP_NEW enthaltenen Objekte i.d.R. mit umfassenden Werten (*) ausgeprägt. SAP_NEW

wird dabei jeweils Release bezogen mit ausgeliefert.

Da die Ausprägung der in SAP_NEW enthaltenen Objekte ggf. in Verbindung mit dem im

Unternehmen implementierten Berechtigungskonzept zu unerwünschten Erweiterungen der

Berechtigungen führt, sollte dieses Profil in einem produktiven SAP-System keinem Anwen-

der zugeordnet werden.

Profil P_BAS_ALL

Auch für den Bereich HCM werden seitens SAP Standardprofile für ein Testsystem ausgelie-

fert. Über das Profil P_BAS_ALL (Alle Berechtigungen für Personendaten) ist ein umfassen-

der Zugriff auf personenbezogene Daten möglich. Darüber hinaus können auch über die

Funktionalitäten der allgemeinen Tabellenanzeige Inhalte aus anderen Anwendungen ange-

zeigt werden. Dieses Profil sollte in Produktivsystemen nicht verwendet werden.

Sonstige S_xxx-Profile

Nachfolgend genannte Profile stellen auch lediglich Muster dar. Grundsätzlich ist es erforder-

lich, die in diesen Profilen vorliegende Ausprägung der einzelnen Berechtigungsobjekte funk-

tionsbezogen einzuschränken.

S_A.SYSTEM Dieses Profil ist für den zentralen Systemverwalter vorgesehen.

Hierüber werden alle Basis-Berechtigungen vergeben (ohne

Module). In diesem Profil sind auch die Berechtigungen zur Be-

nutzeradministration enthalten.

S_A.ADMIN Dieses für den Systemoperator vorgesehene Profil beinhaltet die

Berechtigungen zur Anwendungsentwicklung, zur Administrati-

on der Benutzergruppe SUPER und zur Pflege der Profile der

Gruppe S:A.

S_A.CUSTOMIZ Dieses Profil beinhaltet die Berechtigungen Customizing-

Einstellungen durchzuführen.

S_A.DEVELOP Dieses Profil ist für Anwendungsentwickler vorgesehen und mit

entsprechenden Programmierberechtigungen versehen.

Rollen mit kritischen Berechtigungen

Rollen können über das Benutzerinformationssystem (Transaktion SUIM29) nach verschiede-

nen Kriterien analysiert werden, z.B:

29 Abhängig von der Pflegequalität der Rollen kann die SUIM irreführend sein. In den

Rollenauswertungen werden nur die Transaktionen ausgewertet, die über das Menü vergeben wurden,



‚Rollen’ ‚nach Berechtigungsobjekt’ (z.B. P_ORGIN, HR: Stammda-

ten)

Es erfolgt eine Anzeige der Rollen mit Berechtigungen für die

HR-Stammdaten (über das Berechtigungsobjekt P_ORGIN).

Ebenso kann nach Rollen mit (kritischen) Transaktionen, Be-

rechtigungen oder Profilen gesucht werden.

‚Benutzer’ ‚mit kritischen Berechtigungen’

es erfolgt u.a. eine Anzeige der kritischen Berechtigung und der

dieser Rolle zugeordneten Benutzer (Report

RSUSR008_009_NEW).

Anmerkung: Die SAP Vorschläge zu kritischen Berechtigungen fokussieren kritische Berech-

tigungen aus technischer Sicht. Zur optimalen Nutzung dieses Reports sind die „kritischen

Berechtigungen“ unbedingt kundenseitig nachzupflegen.

Über den Solution-Manager kann jederzeit der SOSS-Report (Security Optimization Self Ser-

vice) erzeugt und abgerufen werden. Diese bietet einen Überblick über vorhandene und als

kritisch eingeschätzte Berechtigungen. Die Checks des SOSS können vom Kunden auch er-

gänzt werden.

Mit SAP GRC Access Control (kostenpflichtige Komponente) ist es möglich, die im SAP-

System vergebenen Rollen und Berechtigungen zu analysieren. Kritische Berechtigungen

werden auf der Basis von vordefinierten Regeln identifiziert, siehe hierzu Kapitel 6.


Um dem Risiko der unzulässigen Zugriffe auf das SAP ERP-System zu begegnen und die

grundsätzlichen Schutzmechanismen der im SAP ERP-System zur Verfügung gestellten In-

strumente zum Berechtigungskonzept zu aktivieren, sollten die o.g. Profile grundsätzlich in

einem Produktivsystem nicht vergeben werden. Dies ist v.a. aufgrund folgender Sachverhalte

erforderlich:

Fehlende Prüfbarkeit und Nachvollziehbarkeit, z.B. durch die Nutzung der Replace-

Funktion im Debugging oder dem Löschen von Änderungsbelegen (Bestandteil der Be-

rechtigungen u.a. in SAP_ALL)

Verletzung der Datenschutzanforderungen durch ein nicht angepasstes Berechtigungskon-

zept

Umgehung des Zugriffschutzes des SAP ERP-Systems mit Hilfe von Entwicklerrechten

(insbesondere Umgehung bzw. Ausschalten des Authority Checks)

Umgehung der für die logischen Datenbanken benötigten Zugriffsrechte durch das direkte

Lesen der transparenten Tabellen z.B. durch Zugriff auf die Tabellen des Personalstamms

(PAxxxx). Durchsuchen Sie die Reportsourcen mit RS_ ABAP_SOURCE_SCAN_nach

direkten Zugriffen auf kritische Tabellen ohne Berechtigungsprüfung (z.B: nach dem Pro-

grammcode „SELECT PA0001“ suchen).

Umgehung der Mandantentrennung durch Verwendung von ABAP-Select Befehlen mit

dem Zusatz CLIENT-SPECIFIED, Prüfung wie oben.

wenn im Profil die das Objekt S_TCODE manuell ergänzt wurde, kann diese Transaktion in der

SUIM nur über eine Suche über Objekt S_TCODE ausgewertet werden.



Reduzieren und auch Ausschalten der HR-Berechtigungsprüfung mit dem Berechtigungs-

objekt P_ABAP oder dem Funktionsbaustein

HR_READ_INFOTYPE_AUTHC_DISABLE: Berechtigungsprüfung für

HR_READ_INFOTYPE abschalten der Funktionsgruppe HRAC: HR-

Berechtigungsprüfung.

Veränderung des Systemzustandes, z.B.:

- Vergabe von Zugriffsberechtigungen an einen unberechtigten Benutzer oder für unzu-

lässige Programme

- Einrichtung nicht vereinbarter Dateien, Datenfelder oder Schlüssel

Vertuschen von Verstößen durch Änderung der Systemparameter, z.B. durch:

- Verfälschen der Protokolldateien z.B. durch zeitweiliges Ausschalten der Tabellenpro-

tokollierung. Dies erfordert aber Zugriff auf die Profilparameter, die Tabellenaktivie-

rungsberechtigung oder die Entwicklerberechtigung

- Umgehung von Zugriffsberechtigungsprüfung durch Ausschaltung der Berechtigungs-

prüfung

Grundsätzlich ist es erforderlich, die von SAP ausgelieferten “Musterprofile” funktionsbezo-

gen an die Anforderungen des Unternehmens anzupassen um so einen adäquaten und den un-

terschiedlichen rechtlichen Anforderungen entsprechenden Zugriffschutz zu gewährleisten.

Ausnahme von der dargestellten Anforderung kann die Zulässigkeit der Vergabe eines weit-

reichenden Profils an Notfall-User sein. Ein Beispiel hierfür könnte das von SAP ausgeliefer-

te Profil SAP_ALL sein, das um die Berechtigung zum Löschen oder Deaktivieren von Pro-

tokollierungen reduziert werden sollte (Objekt S_SCD0).

4.2.1.5 Besonderheiten bei der Berechtigungsprüfung

Ausschaltung/Modifikation von Berechtigungsprüfungen

Wie in Kapitel 4.2.1.1. (Identifizierung und Authentifizierung) dargestellt, können Berechti-

gungsprüfungen durch entsprechende Parametereinstellungen ausgeschaltet werden.

Außerdem ist es möglich, die Prüfung zu einzelnen Berechtigungsobjekten im SAP ERP-

System global mit Hilfe der Transaktionen SU24, SU25, SU26 auszuschalten (Ausnahme:

Berechtigungsobjekte der Basis und des HCM-Moduls (beginnend mit S_xxx und P_xxx las-

sen sich auf diese Weise nicht global ausschalten). Die Berechtigungsprüfungen des Java-

Stacks (UME30 -Rollen) werden durch diese Transaktionen nicht global ausgeschaltet.

Die Transaktionen SU25 und SU26 umfassen verschiedene Aktivitäten wie z.B. ‚Installation

des Profilgenerators’ oder ‚Transport von Kundentabellen’. Das ‚globale Ausschalten von Be-

rechtigungsobjekten’ in der SU25/SU26 wird mit Hilfe der Transaktion

AUTH_SWITCH_OBJECTS durchgeführt.

Das globale Ausschalten von Berechtigungsobjekten ist aus Datenschutzsicht problematisch.

Folgende Schutzmaßnahmen können ergriffen werden:

30 UME (User Management Engine)



Sperren der Transaktion AUTH_SWITCH_OBJECTS mit Hilfe der Transaktion SM01

(Transaktionscodes Sperren/Entsperren)

Profilparameter ‚auth/object_disabling_active’ auf den Wert "N" setzen (um Berechtigungs-

prüfungen für bestimmte Berechtigungsobjekte zu unterdrücken, muss der Profilparameter

auth/object_disabling_active auf den Wert "Y" gesetzt werden).

Für den Fall, dass ausnahmsweise das globale Ausschalten von einzelnen Berechtigungsob-

jekten erlaubt sein soll, ist mindestens die folgende Empfehlung aus der SAP-Dokumentation

zu befolgen:

„Zum Sichern bzw. Aktivieren von deaktivierten Berechtigungsprüfungen zu Berechti-

gungsobjekten wird eine Berechtigung zum Objekt S_USER_OBJ benötigt. Aus Si-

cherheitsgründen sollten Sie die Berechtigungen für das Sichern und das Aktivieren

von deaktivierten Berechtigungsprüfungen zu Berechtigungsobjekten verschiedenen

Benutzern zuordnen. Es ist sinnvoll, wenn das Deaktivieren von Berechtigungsprüfun-

gen nach dem 4-Augen-Prinzip stattfindet.“

Prüfkennzeichen in der SU22/SU24

Für die Prüfkennzeichen eines Berechtigungsobjektes sind folgende Werte vorgesehen.

U Prüfkennzeichen wurde nicht spezifiziert - Berechtigungsobjekt

wird geprüft (wie bei 'P')

N Berechtigungsobjekt wird unter Transaktion nicht geprüft

P Berechtigungsobjekt wird unter Transaktion geprüft

PP Berechtigungsobjekt wird unter Transaktion geprüft und im

Profilgenerator werden die angegebenen Feldwerte vorgeschla-

gen

Der Wert N ist prüfungsrelevant und nur nach genauer Prüfung und Dokumentation der Prü-

fungsergebnisse zu setzen. Dieser Wert sollte nur in dem Fall gesetzt werden, in dem die Or-

ganisation mit an Sicherheit grenzender Wahrscheinlichkeit ausschließen kann, dass das Ob-

jekt (und / oder die Applikation) genutzt wird.

Die P_ABAP-Berechtigung ist nur einzuräumen, wenn diese nachweislich im Programmcode

(der Funktionen für die Buchungssatzübernahme für Gehalts- und Reisekostenbuchenen) bei

AUTHORITY-CHECK angefordert wird.

Authority Check bei ABAP-Programmen (Standardprogramm oder Eigenentwicklun-

gen)

Der Zugriffsschutz baut bei SAP ERP-Systemen im Wesentlichen auf maschinellen Kontrol-

len auf, die in den Programmen hinterlegt sind. Dabei handelt es sich um das ABAP-

Sprachelement “Authority Check”, welches in den Programmen hinterlegt werden kann. Bei

Ausführung eines Programms erfolgt durch diesen Authority Check die Kontrolle, ob die Be-

rechtigungen des aufrufenden Benutzers ausreichend sind. Im positiven Fall wird der Zugriff

auf die Informationen zugelassen; im negativen Fall ist das Programm so zu gestalten, dass

der Zugriff ausgeschlossen ist.

Ein zuverlässiger Zugriffsschutz kann nur sichergestellt werden, wenn die Authority Checks

technisch und inhaltlich sachgerecht programmiert sind. Dies betrifft sowohl SAP-

Standardprogramme als auch kundeneigene Reports.

Es wird empfohlen in einer Programmierrichtlinie die technische und inhaltlich sachgerechte

Programmierung detailliert festzulegen. Dabei ist die inhaltliche Richtigkeit in Verbindung

mit dem bestehenden Berechtigungskonzept und dem Schutzanliegen zu definieren.



Es empfiehlt sich, beim Lesen und Ausprobieren der folgenden Hinweise die mySAP HR

Spezial-Dokumentation vom SMP (Service Market Place (service.sap.com) Suchbegriffe: hr

special documentation) bereitzustellen und zu lesen.

Berechtigungshauptschalter HR (Tabelle T77S0; GRPID „AUTSW“)

Wie dargestellt, kommt dem Berechtigungsobjekt P_ORGIN (HR: Stammdaten) im Rahmen

des Zugriffs auf personenbezogene Informationen eine besondere Bedeutung zu. Ob dieses

Berechtigungsobjekt und weitere HCM-Berechtigungsobjekte oder strukturelle Berechtigun-

gen (Schalter ORGPD) systemseitig verprobt werden, ist von Customizing-Einstellungen ab-

hängig. Die Einstellung erfolgt in der Tabelle T77S0 (Systemtabelle). Dort wird über sog.

Semantische Kürzel festgelegt, ob die Berechtigungsobjekte überhaupt für Berechtigungsprü-

fungen aktiv sind.

Eine systematische Überprüfungsmethode für die vergebenen HCM-Berechtigungen inklusive

der strukturellen Berechtigungen mit dem Benutzerinformationssystem gibt es nur teilweise.

Die Prüfung auf der Ebene der Einzelberechtigung eines Benutzers kann mit der Transaktion

HRAUTH_ Berechtigungs-Workbench (Programm; RHANALYSIS_TOOL; Hinweise:

902000 – Analyse von HR-Berechtigungen) erfolgen. (Es fehlt bisher ein Reiter für die rever-

se Funktion: Wer alles hat auf einen Infotyp einer bestimmten Person welche Berechtigun-

gen?)

Um den Prüfaufwand zu verringern, kann die ausschließliche Nutzung der kontextsensitiven

Berechtigungen und die Definition kritischer struktureller Profile in Verbindung mit den ent-

sprechenden Berechtigungsobjekten (PLOG_CON, P_ORGINCON, P_ORGXXCON) als

„kritische Berechtigung“ oder „kritische Berechtigungskombination“ wirksam genutzt wer-

den. Dabei müssen Struktur- und Funktionsinformationen zusammengebracht und bewertet

werden. Hier empfiehlt sich der Einsatz von Zusatztools (s. Kap. 6).

Die Nutzung der HR-Berechtigungs-BAdIs:

HRPAD00AUTH_CHECK: Kundenindividuelle Berechtigung einrichten,

HRPAD00AUTH_TIME: Kundenindividuelle Zeitlogik zusätzlich einrichten,

HRBAS00_STRUAUTH: Strukturelle Berechtigungen

HRBAS00_RHBAUS00: (Index für Strukturberechtigung)

HRBAS00_GET_PROFL: Kundenindividuelle Bestimmung der strukturellen Profile

ist im Berechtigungskonzept zu begründen und fundiert zu prüfen, da die durch die BAdI-s

vorgenommen Berechtigungsprüfung die Prüfung durch die HR-Berechtigungsobjekte teil-

weise ersetzt.

Die in den BAdIs:

HRBAS00INFTY: (Verbucher bei PBO, PAI, vor Update und während Update)

HRPAD00INFTY: (Verfahren für Infotypen PBO, PAI und während Update)

per Auslieferung zur Verfügung gestellten Funktionen sind zu überprüfen und als kundenei-

gene Funktionen zu dokumentieren bzw. zu deaktivieren.

Report Berechtigungsgruppen

Der Zugriff auf sensible Reports kann neben der skizzierten Verwendung von Authority-

Checks über Transaktionscode-Zuordnungen oder Berechtigungsgruppen geschützt werden.

Bei der Transaktionscode-Zuordnung ist sicherzustellen, dass Benutzer Reports ausschließlich

über eine eigens zugeordnete Transaktion aufrufen können. Der allgemeine Aufruf über



Transaktionen wie SA38, SE38, START_REPORT (ABAP Reporting) ist in diesem Fall

auszuschließen.

Alternativ kann ein Schutz über Berechtigungsgruppen realisiert werden. Dabei sollte jeder

relevante Report einer spezifischen Berechtigungsgruppe zugeordnet werden. Nicht verwen-

dete Reports sollten einer Berechtigungsgruppe ‚Gesperrt‘, allgemeinzugängliche einer Be-

rechtigungsgruppe ‚Allgemein‘ zugeordnet werden. Die Zuweisung kann über den Report

RSCSAUTH vorgenommen werden. Korrespondierend sind im Berechtigungskonzept die Be-

rechtigungen zu dem Objekt S_PROGRAM (ABAP: Programmablaufprüfungen) zu definie-

ren. Da im Regelfall die SAP Standardreports ohne Zuordnung zu einer Berechtigungsgruppe

ausgeliefert werden, muss dieser Schutzmechanismus vom Anwenderbetrieb realisiert wer-

den.

Aus den oben genannten Gründen ist die SA38 nur sehr restriktiv an Benutzer zu vergeben.

Jeder Report der keiner Berechtigungsgruppe zugeordnet ist, kann mit der SA38 ohne weitere

Prüfung31 ausgeführt werden.


Das Ausschalten von Berechtigungsprüfungen ist mit erheblichen Risiken verbunden, da im

SAP-Standard vorgesehene Zugriffsschutzmechanismen dadurch außer Kraft gesetzt werden

können. Neben der Kontrolle des Parameters AUTH/NO_CHECK_IN_SOME_CASES dient

folgendes Vorgehen zur Überwachung:

Anzeigen der Tabelle USOBX_C (Checktabelle zu Tabelle USOBT_C) mit Hilfe der

Transaktion SE17 (Allg. Tabellenanzeige)

Analyse, ob die Tabelle Einträge mit OKFLAG = N enthält. Die Berechtigungsprüfung zu

entsprechenden Berechtigungsobjekten ist transaktionsbezogen deaktiviert

Schutzmaßnahmen gegen das globale Ausschalten von Berechtigungsobjekten (Transaktionen

AUTH_SWITCH_OBJECTS, SU25, SU26) sind in Abschnitt 4.2.1.5.1 beschrieben.

In Bezug auf die Verwendung von Authority-Checks bilden folgende Maßnahmen geeignete

Ansatzpunkte zur Gewährleistung des Datenschutzes:

Aufbau einer Entwicklungsrichtlinie bei der Programmierung von kundeneigenen ABAPs.

In dieser Richtlinie sind z.B. die Verwendung von Authority-Checks, Berechtigungsgrup-

pen für Reports sowie Test-, Freigabe- und Dokumentationsanforderungen festzulegen.

Für SAP ERP-Standardprogramme sollten entsprechende SAP-Hinweise (SAP Service

Marketplace; service.sap.com/notes) beachtet werden, um bei bekannten Lücken bzw.

notwendigen Korrekturen die Authority-Checks in den Programmen ergänzen oder korri-

gieren zu können.

In Bezug auf den Berechtigungshauptschalter HR sind die Einstellungen für die aktiven Be-

rechtigungsobjekte im Anwenderbetrieb als Soll-Werte festzulegen. In regelmäßigen Abstän-

den sollten die im SAP ERP-System vorgenommenen Ist-Einstellungen (Tabelle T77S0)

überwacht werden. Ferner sind Maßnahmen zu definieren, wie z.B. der Zeilenschutz für die

Tabellenadministration über das Berechtigungsobjekt S_TABU_LIN, um eine Manipulation

des Berechtigungshauptschalters durch unberechtigte Benutzer auszuschließen.

31 Die Authority Checks im Programmcode der Reports werden weiterhin ausgeführt, sofern sie

vorhanden sind.



Bezüglich der Report-Berechtigungsgruppen sollte im Rahmen des Berechtigungskonzeptes

definiert werden, mit welchen Maßnahmen Reports vor unzulässigem Zugriff geschützt wer-

den. Werden hierzu Berechtigungsgruppen verwendet, sind die Zuordnungen von Reports zu

Berechtigungsgruppen periodisch zu überwachen. Insbesondere ist bei Releasewechseln zu

beachten, dass mit neuen SAP-Standardprogrammen auch deren Einstellung in Berechti-

gungsgruppen neu installiert wird.

4.2.1.6 Benutzeradministration

Konzeption der zentralen Benutzeradministration

Der Benutzer identifiziert sich gegenüber dem SAP-System durch Eingabe seiner Benutzer-

ID und seines Kennwortes. Im Benutzerstammsatz sind die Zugriffsrechte des Anwenders

hinterlegt. Für diese Hinterlegung, die Pflege der Zugriffsrechte im Benutzerstammsatz, bietet

das SAP-System verschiedene organisatorische Alternativen, die im Folgenden beschrieben

werden.

Bei der zentralen Benutzerpflege ist eine zentrale Stelle für die Pflege aller Benutzerstamms-

ätze zuständig. Die Rollen- oder Profilzuordnung kann zentral oder auch dezentral – über das

Customizing bis auf Berechtigungsobjekt- und Feldebene einstellbar – erfolgen.

Da die Benutzeradministration sowie die Administration der Zugriffsrechte sicherheitssensib-

le Aktivitäten darstellen, besteht im SAP-System die Möglichkeit, ein organisatorisches

Mehr-Augen-Prinzip abzubilden.

Dabei spricht SAP die Empfehlung aus, eine Funktionstrennung zu gewährleisten, z.B. durch

Einrichtung eines Benutzeradministrators, eines Rollenadministrators und eines Aktivierungs-

administrators.

Die Aufgaben des Benutzeradministrators beziehen sich auf die Anlage und Pflege von Be-

nutzerstammsätzen.

Der Rollenadministrator pflegt die Elemente des Berechtigungskonzeptes. Dies sind je nach

konzeptuellem Vorgehen Rollen, Profile bzw. Berechtigungen.

Der Aktivierungsadministrator ist für die Verwendbarkeit der Elemente des Berechtigungs-

konzeptes zuständig. Auch hier sind die Aufgaben von dem konzeptionellen Vorgehen ab-

hängig. Sie bestehen in einer Aktivierung von Berechtigungen bzw. Profilen, die der Rollen-

administrator in der Pflegeversion erstellt hat. Alternativ bestehen sie in der Durchführung

des Benutzerabgleichs. Dabei werden die Rollen mit den darin hinterlegten Profilen und Be-

rechtigungen den Benutzerstammsätzen zugeordnet.

Um diese Trennung der unterschiedlichen Administrationsaufgaben zu ermöglichen, hat SAP

in der Objektklasse “Basis-Administration” u.a. die folgenden Berechtigungsobjekte definiert:

Benutzerstammpflege: Benutzergruppen (S_USER_GRP)

Benutzerstammpflege: Berechtigungen (S_USER_AUT)

Benutzerstammpflege: Berechtigungsprofil (S_USER_PRO)

Berechtigungswesen: Prüfung für Rollen (S_USER_AGR)

Berechtigungswesen: Transaktionen in Rollen (S_USER_TCD)

Berechtigungswesen: Feldwerte in Rollen (S_USER_VAL)

Adminfunktion für Benutzer/Berechtigungsverwaltung (S_USER_ADM)



Benutzerstammpflege: Systemspezifische Zuordnungen (S_USER_SAS) Das Berechti-

gungsobjekt S_USER_SAS ist einer Weiterentwicklung der Objekte S_USER_AGR,

S_USER_PRO und S_USER_GRP

Die oben genannten Berechtigungsobjekte werden ebenfalls bei der Verwendung des Profil-

generators (Transaktion PFCG) geprüft.

Konzeption der dezentralen Benutzeradministration

Bei dieser Form der Administration können die Pflegeaufgaben auf mehrere Stellen verteilt

werden. Für welche Benutzerstammsätze ein Administrator zuständig ist, kann über die Be-

nutzergruppe gesteuert werden. Über korrespondierende Berechtigungen zu dem Berechti-

gungsobjekt S_USER_GRP (Benutzerstammpflege: Benutzergruppen) besteht die Möglich-

keit, die organisatorische Zuständigkeit systemseitig abzubilden.

Benutzeradministration mit dem Profilgenerator

Rollen enthalten die Berechtigungen, mit denen ein Benutzer auf die im Menü enthaltenen

Funktionen (Transaktionen, Berichte/Reports, web-gestützten Anwendungen usw.) zugreifen

kann. Rollen werden im Benutzerstammsatz hinterlegt.

Mit dem Werkzeug zur Rollenpflege, dem Profilgenerator, werden auf der Basis ausgewählter

Menüfunktionen Berechtigungen bzw. Profile automatisch erzeugt und zur Nachbearbeitung

angeboten. Darüber hinaus bietet der Profilgenerator eine Integration mit dem HR-

Organisationsmanagement.

Im Gegensatz zu der konventionellen Benutzerpflege können zeitabhängige Rollenzuordnun-

gen erfasst werden (befristete Vergabe von Berechtigungen).

Umgekehrt können auch die Benutzerstammsätze den Rollen zugeordnet werden. Hierfür ste-

hen auch die Transaktion PFUD bzw. der Report RHAUTUPD_NEW (Abgleich Benutzer-

stammsatz) zur Verfügung.

Veraltete Benutzeradministration mit Profilen

Bei der veralteten Benutzeradministration erfolgt die Zuweisung unmittelbar über Profile

(Einzel- oder Sammelprofile) im Benutzerstammsatz. Pflegt der Benutzeradministrator einen

Benutzerstammsatz, so ist die Änderung für den entsprechenden Anwender unmittelbar bei

seiner nächsten Anmeldung am SAP-System wirksam.

Die Nutzung von manuell erzeugten Profilen kann zu einer nicht mehr kontrollierbaren Pflege

von Berechtigungen führen.


In Bezug auf die dargestellte Benutzeradministration liegt das Risiko in Zugriffen auf das

SAP-System durch unbefugte Benutzer sowie in unzulässigen bzw. zu umfangreichen Zu-

griffsrechten der angelegten Benutzerstammsätze. Diesen Risiken ist durch organisatorische

Maßnahmen, z.B. Mehr-Augen-Prinzip, und deren technische Abbildung im SAP-System zu

begegnen.

Hierzu stehen die im Kapitel 4.2.1.6.1 dargestellten Berechtigungsobjekte zur Verfügung.

Über die für die entsprechenden Administratoren notwendige Ausprägung dieser Objekte

kann eine im o.g. Sinne verstandene Funktionstrennung abgebildet werden.

Da bei den SAP-Standardprofilen bzw. Standard-Rollen bezüglich des Datenschutzes Funkti-

onstrennungsgesichtspunkte häufig unzureichend berücksichtigt sind (vgl. u.a. S_A.SYSTEM

oder SAP_BC_USER_ADMIN), ist es erforderlich, unternehmensspezifisch eigene Elemente



zu erstellen. Hierbei sind die in 4.2.1.6.1 genannten Berechtigungsobjekte entsprechend den

sich stellenden Anforderungen auszuprägen.

Sollte aufgrund der vorhandenen Personalstärke eine dreistufige Funktionstrennung (6-

Augenprinzip) nicht realisierbar sein, empfiehlt es sich, zumindest eine zweistufige Funkti-

onsrennung zu implementieren (Benutzeradministration mit Rollenzuordnung einerseits und

Berechtigungsadministration mit Rollen- und Aktivierungsadministration andererseits).

4.2.1.7 Änderungen am Produktivsystem

Änderungen, die im produktiven SAP-System vorgenommen werden, unterliegen zu Nach-

weiszwecken der eingesetzten Verfahren bestimmten Protokollierungsanforderungen. Diese

Anforderung ergibt sich aus § 238 HGB ff.

Zur Sicherstellung der Protokollierung von Änderungen sind verschiedene Systemeinstellun-

gen zu treffen oder grundsätzliche Schutzmechanismen zu aktivieren, die unerlaubte Ände-

rungen von vornherein unterbinden.

Change and Transport System

Begriffsabgrenzung

CTO Der Change and Transport Organizer (CTO) stellt Funktionen

zur Erzeugung, Dokumentation und Freigabe von Änderungs-

aufträgen im Rahmen des Customizings zur Verfügung.

TMS Über das Transport Management System (TMS) wird u.a. die

Organisation und der Transport von diesen Aufträgen unter-

stützt.

Grundsätzlich sieht SAP im Rahmen der Anwendungsentwicklung und des Customizings vor,

dass drei voneinander unabhängige SAP-Systeme - Entwicklungssystem, Qualitätssicherungs-

system und Produktivsystem - genutzt werden sollen.

Daher sollten wegen

Einhaltung der Sicherheit der Datenbestände

Schutz vor unberechtigter Kenntnisnahme von personenbezogenen Daten

Nachvollziehbarkeit der Systemänderung

Berechtigungen zur Anwendungsentwicklung und zum Customizing in einem produktiven

SAP-System nicht vergeben werden. Um für die drei o.g. Systeme die Transportwege zu kon-

figurieren, sind Berechtigungen zur Administration (Objekt S_CTS_ADMIN) erforderlich.

Änderungen sollten zunächst grundsätzlich im Entwicklungssystem erfolgen und mit Hilfe

des TMS in das Qualitätssicherungssystem transportiert werden.

Nach Durchlaufen eines entsprechenden Test-, Abnahme-, und Freigabeverfahrens erfolgt

wiederum über das TMS die Einstellung in die Produktionsumgebung.

Je nach Konfiguration und Datenbestand können vom Datenschutzrecht geschützte personen-

bezogene Daten in allen Systemen vorkommen.

Über die bei der Nutzung des TMS erstellten Protokolle kann dabei die Nachvollziehbarkeit

der vorgenommenen Einstellungen sichergestellt werden.

Auf Protokolle über durchgeführte Transporte, vorgenommene Änderungen etc. kann aus den

Transaktionen STMS oder SE03 heraus zugegriffen werden.



Tabellenprotokollierung / Customizing

Im Rahmen der Einführung von SAP sowie im laufenden Betrieb wird eine Vielzahl von Ta-

bellen den Anforderungen des Unternehmens entsprechend angepasst.

Da Änderungen an Tabellen in der Regel mit Programmänderungen gleichgesetzt werden

können, sind vorgenommene Änderungen ab Produktivstart zu protokollieren. Die Tabellen-

änderungsprotokolle sind entsprechend den gesetzlich geforderten Aufbewahrungsfristen (10

Jahre) vorzuhalten.

Im Auslieferungsstandard sieht SAP die Protokollierung von Tabellenänderungen aufgrund

der notwendigen Customizing-Maßnahmen nicht vor.

Für das Testsystem ist der Parameter - rec/client - auf OFF gestellt. Diese Einstellung muss

zum Beginn der Customizing-Arbeiten im Entwicklungssystem und nach Produktivstart im

Produktivsystem durch Ändern des Systemprofils (DEFAULT.PFL) dahingehend geändert

werden, dass entweder alle Tabellenänderungen im System protokolliert werden (ALL) oder

zumindest die des Auslieferungsmandanten (000) und des/der Produktivmandanten. Die Ein-

stellung ON ist nicht zulässig.

Wenn der Parameter rec/client eingeschaltet ist, werden Änderungsprotokollsätze für diejeni-

gen Tabellen geschrieben, die bei den technischen Einstellungen das entsprechende Kennzei-

chen gesetzt haben. Selbsterstellte Tabellen (T9, X, Y oder Z) müssen ggf. vom Kunden als

protokollierungspflichtig gekennzeichnet werden.

Die Pflege des Protokollierungskennzeichens von Tabellen wird mit der Transaktion SE13

durchgeführt.

Customizing-Einstellungen sollten i.d.R. nicht im Produktivsystem vorgenommen werden,

um ein erforderliches Test-, Abnahme- und Freigabeverfahren nicht zu unterlaufen und si-

cherzustellen, dass die vorgenommenen Einstellungen anforderungsgerecht vorgenommen

wurden.

Zu berücksichtigen ist in diesem Zusammenhang, dass bei der Nutzung des TMS sicherzustel-

len ist, dass auch bei Transporten von Customizing-Änderungen im Zielsystem eine Protokol-

lierung der Tabellen erfolgt. Hierzu ist es erforderlich, den Parameter RECCLIENT (Para-

meter für die Tabellenprotokollierung beim Transport) zu setzen (off: keine Protokollierung;

all: die Protokollierung erfolgt für alle Mandanten; xxx: für die aufgeführten Mandanten wird

protokolliert). Dieser Parameter ist von rec/client bzgl. der Tabellenprotokollierung im Pro-

duktivsystem zu unterscheiden.

Systemänderbarkeit

Über die Transaktion SE06 kann gesteuert werden, ob Objekte des Repository und des man-

dantenunabhängigen Customizings änderbar sind.

Dabei können einzelne Objekte, wie z.B:

Kundenentwicklungen

SAP-Basiskomponente

Development Workbench

spezifisch geschützt werden. Über eine dieser Transaktion zugeordneten Schaltfläche lassen

sich entsprechende Änderungsprotokolle auswerten.

Über die in dieser Transaktion festgelegten Schutzmechanismen ergeben sich keine Auswir-

kungen auf mandantenabhängige Customizing-Änderungen.



Diesbezüglich werden entsprechende Sicherheitsmechanismen über die Mandantensteuerung

(vgl. Schutz der Tabelle T000) festgelegt.

Protokolle

Wenn in SAP Änderungen an Objekten/Tabellen vorgenommen werden, wird – entsprechen-

de Systemeinstellungen vorausgesetzt – ein Eintrag in einer Änderungsprotokolldatei erzeugt.

Dieser ist in dem Datei-/Datenbanksystem des SAP-Systems abgelegt. Jede SAP-Installation

besitzt ihre eigene Datenbank und somit ein eigenes Datei-/Datenbanksystem. Ausnahmen

gelten für Transportprotokolle, da diese in einem gemeinsamen Transportverzeichnis abgelegt

werden.

Schutz der Tabelle T000: Mandanten

Über entsprechende Einstellungen der Tabelle T000 ist es möglich, Änderungen am SAP-

System grundsätzlich oder für bestimmte Teilbereiche zu unterbinden. Um entsprechende

Einstellungen anzuzeigen oder zu pflegen dient die Transaktion SCC4: Mandantenver-

waltung. Es können verschiedene Einstellungen bzgl.

Änderungen für Transporte und mandantenabhängige Objekte

Änderungen an mandantenübergreifenden Objekten

Schutz bzgl. Mandantenkopier- und Vergleichstools

getroffen werden.

Grundsätzlich sollten die Einstellungen so gewählt werden, dass Änderungen im Produk-

tivsystem nicht möglich sind.

Sollte es erforderlich werden, das System hinsichtlich Änderungsmöglichkeiten zu öffnen, ist

sicherzustellen, dass keine unkontrollierten Änderungen vorgenommen werden – entspre-

chende Dokumentationsunterlagen sollten erstellt werden – und das nach den vorgenomme-

nen Einstellungen der Änderbarkeitsstatus wieder zurückgesetzt wird.


Zur Sicherstellung der ordnungsmäßigen Programmanwendung und zum Schutz vor unbe-

rechtigter Kenntnisnahme oder versehentlicher/absichtlicher Manipulation von Daten ist si-

cherzustellen, dass über die getroffenen Systemeinstellungen ein hinreichender Systemschutz

vor Veränderungen gegeben ist und erforderliche Änderungsprotokolle erstellt werden. In

diesem Zusammenhang sollte sichergestellt werden, dass

eindeutige und verbindliche Regelungen bzgl. der Pflege, der Kontrolle und der Protokol-

lierung von Tabellen getroffen werden, um sowohl die gesetzlichen Anforderungen erfül-

len zu können als auch dem Risiko der bewussten oder unbewussten Manipulation von

Datenbeständen vorzubeugen sowie den Anforderungen, die sich an den Schutz personen-

bezogener Daten stellen, gerecht zu werden

die entsprechenden Systemparameter hinsichtlich des TMS, der Transaktion SE06 und der

Einstellungen bzgl. der Tabelle T000 getroffen sind

die erzeugten Protokolle gemäß den gesetzlichen Aufbewahrungsfristen vorgehalten und,

sofern erforderlich, wieder lesbar gemacht werden können.

Eine regelmäßige Kontrolle der getroffenen Einstellungen bzw. nachgelagerte Kontrollen der

erzeugten Änderungsbelege ist ebenfalls geboten.



4.2.1.8 Systemschnittstellen

Für die Kommunikation innerhalb eines SAP ERP-Systems, dem Informationsaustausch zwi-

schen verschiedenen SAP ERP-Systemen oder der Kommunikation zwischen SAP ERP- und

Fremdsystemen stellt SAP verschiedene Schnittstellenmethoden zur Verfügung.

Batch-Input

Bei dem Batch-Input-Verfahren werden Daten in einer sogenannten Batch-Input-Mappe ge-

speichert. Die Übernahme der Daten erfolgt durch das Abspielen der Batch-Input-Mappe. Sie

simuliert die Online-Eingabe von Transaktionscodes und Daten und durchläuft beim Abspie-

len die entsprechenden Berechtigungs- und Plausibilitätsprüfungen.

RFC, ALE, BAPI

Der Remote Function Call (RFC) dient der Kommunikation zwischen verteilten Programmen

in einer SAP-Systemlandschaft. Mit Hilfe von RFC können Funktionsbausteine in einem

fremden SAP-System aufgerufen werden und die Ergebnisse an das aufrufende System zu-

rückgegeben werden.

Die Technik von RFC bildet auch die Grundlage für weitere SAP spezifische Schnittstellen-

methoden, wie Application Link Enabling (ALE) und Business Application Program Interface

(BAPI).

Eine besondere Fragestellung wirft die Übergabe von HCM-Daten in ein separates Logistik-

system auf. SAP bietet hierzu im Customizing Standard ALE Schnittstellen an, die immer

vollständige Infotypen an das angeschlossene Logistiksystem weiter geben (siehe in der

Transaktion SPRO ( SAP Referenz-IMG) SAP NetWeaver Application Server Ap-

plication Link Enabling Geschäftsprozesse modellieren vordefinierte ALE Geschäfts-

prozesse Personalwirtschaft HR <->LO). Das bedeutet, dass bei der Übermittlung des

Infotyps 0002 im Standard auch das Datenfeld „Nationalität“ und „Konfession“ übergeben

werden. Datenfelder, denen mit hoher Wahrscheinlichkeit die Rechtsgrundlagen zur Verarbei-

tung in der Logistik fehlen. Hier ist durch gesonderte Maßnahmen in der Berechtigungsver-

waltung sicherzustellen, dass eine zweckentfremdete Nutzung ausgeschlossen wird (vgl. An-

lage zu § 9 Nr. 8 BDSG).

Auch bei anderen Schnittstellen des HCM, z.B. in das Controlling oder zur Arbeitszeiterfas-

sung (CATS bzw. CATSXT), ist die Einhaltung der Zweckbindung zu beachten.

PC-Download

SAP bietet die Möglichkeit, die unterschiedlichsten Auswertungen per Download aus der ”ge-

sicherten SAP-Umgebung” auf den PC zu übertragen und dort ohne zusätzliche Kontrollen

weiterzuverarbeiten. Dabei bezieht sich der Download z.B. auf jede Art von Listausgaben, die

auf den PC übertragen werden können.

Menüpfad:

System -> Liste -> Sichern -> Lokale Datei

Um dem Risiko der Übertragbarkeit von personenbezogenen Daten und einem möglichen

Missbrauch bei deren Weiterverarbeitung zu begegnen, stehen im SAP ERP-System ver-

schiedene Berechtigungsobjekte zur Verfügung.

ABAP-Listviewer (ALV)

Über den häufig verwendeten ABAP-Listviewer können angezeigte Daten ohne weitere Be-

rechtigungsprüfung oder Protokollierung per "Kopieren" und "Einfügen" in ein beliebiges an-

deres Programm übernommen werden. Siehe Abschnitt 4.2.1.3.11.




Nach jedem Datenexport in Fremdsysteme können innerhalb der SAP-Umgebung Zweckbin-

dung, Löschfristen und andere datenschutzrechtliche Anforderungen nicht mehr gewährleistet

werden.

Bei jeder Form der Schnittstellenverarbeitung liegen die Risiken vorrangig in

der unvollständigen bzw. fehlerhaften Verarbeitung

der Manipulation während der Datenübertragung bzw. des Programmablaufs

der unzulässigen Einsichtnahme in personenbezogene Daten

der unkontrollierten Weitergabe dieser Daten

Diesen Risiken ist durch geeignete Maßnahmen zu begegnen. Als organisatorische Maßnah-

me sollten grundsätzlich alle Schnittstellendateien und die genutzten Verfahren entsprechend

den Anforderungen des BDSG dokumentiert werden (§ 4g BDSG, Stichwort “Überwachung

der ordnungsgemäßen Anwendung”, § 4e BDSG, Stichwort “Beschreibung der Daten oder

Datenkategorien”).

An technischen Maßnahmen stehen im SAP ERP-System verschiedene interne Kontrollstufen

zur Verfügung, bei denen eine ordnungsgemäße Einstellung, insbesondere auch in dem Zu-

sammenspiel der Kontrollen, vorzunehmen und regelmäßig zu überwachen ist. Als zentrale

technische Maßnahmen sind folgende Aspekte zu nennen:

In Bezug auf das Batch-Input-Verfahren kann über das Berechtigungskonzept festgelegt

werden, welche Benutzer Batch-Input-Mappen z.B. erstellen, abspielen und löschen kön-

nen. Die Zugriffe werden über Berechtigungen zu dem Berechtigungsobjekt

S_BDC_MONI (Batch-Input Berechtigungen) bestimmt.

In Bezug auf die Remote Function Call-Technologie (RFC) sind die Sicherheitseinstel-

lungen der RFC-Destinationen (Transaktion RSRSDEST - Ausgabe Systemübersicht für

remote submit) zu beachten. Deren Pflege wird über das Berechtigungsobjekt

S_ADMI_FCD (Systemberechtigungen) gesteuert. Ob bei RFC überhaupt Berechtigungs-

prüfungen erfolgen, ist von der Einstellung des Profilparameters auth/rfc_authority_check

abhängig. Er kann z.B. mittels des Reports RSPARAM überwacht werden. Aus Sicher-

heitsgründen ist die Aktivierung der Berechtigungsprüfung für RFC unbedingt zu empfeh-

len. Ist die grundsätzliche Aktivierung eingestellt, so greifen die Zugriffsschutzkontrollen

durch das Berechtigungsobjekt S_RFC (Berechtigungsprüfung beim RFC-Zugriff).

In Bezug auf Application Link Enabling (ALE) sind das Verteilungsmodell sowie die

ALE-Berechtigungen zu pflegen. Um auf entsprechende Funktionalitäten zugreifen zu

können, kann die Transaktion SALE genutzt werden. Die darin enthaltenen Transaktionen

und Reports sind dann entsprechend zu schützen.

In Bezug auf den PC-Download steht für die Kontrolle zum generischen Listen-Download

das Berechtigungsobjekt S_GUI (Berechtigung für GUI-Aktivitäten) zur Verfügung. Zu-

sätzlich besteht die Möglichkeit ein kundeneigenes Berechtigungsobjekt anzulegen, um

die Downloadsteuerung zu differenzieren. Die Vorgehensweise zur Anlage eines solchen

Berechtigungsobjekt wird im SAP-Hinweis 28777 (PC Download: Protokollierung, Be-

rechtigungsprüfung) beschrieben. Ein solches Objekt bietet etwa die Möglichkeit, den

Download für bestimmte, problematische Transaktionen zu sperren. Um dieses kundenei-

gene Berechtigungsobjekt (z.B.: Z_DOWNLD) einsetzen zu können, wird im SAP-

System der User-Exit „EXIT_SAPLGRAP_001“ bzw. der Include „ ZXFILU01“ verwen-

det.



In Bezug auf den ABAP-Listviewer können in kritischen Programmen die entsprechenden

Oberflächenfunktionen durch Programmergänzung ausgeblendet werden, etwa über den

Parameter IT-EXCLUDE im Funktionsbaustein REUSE_ALV_GRID_DISPLAY. Über

einen User-Exit können als kundeneigene Erweiterung die Downloadberechtigungen auf

die Transaktion oder den Reportnamen differenziert werden.

Weitere SAP-unabhängige Lösungen sind in speziellen CITRIX-Umgebungen realisier-

bar, z.B. die Unterbindung der Cut and Paste Funktion.

4.2.1.9 Auditing und Logging

Es ist zu beachten, dass die Konfiguration und die Auswertung der nachfolgenden Protokolle

neben IT-Security, Revision und Wirtschaftsprüfern auch mit dem Datenschutzbeauftragten

abzustimmen ist und die Mitbestimmungsrechte der Arbeitnehmervertretungen beachtet wer-

den.

Für Auditing und Logging ist ein Einsatzkonzept erforderlich, in dem die Anforderungen der

einzelnen Bereiche bezüglich der Einstellungen, der Einsichtnahme und der Aufbewahrungs-

dauer festzulegen sind. Die benötigten IT-Ressourcen (z.B. zusätzlicher Speicherbedarf) sind

dafür bereitzustellen.

Security Audit Log

Aus Datenschutzsicht ist zu empfehlen, Benutzer mit weit reichenden, kritischen Berechti-

gungen einer Protokollierung mit dem Security Audit Log zu unterwerfen. Da eingerichtete

Notfall-User i.d.R. mit umfassenden Berechtigungen ausgestattet sind, ist es den rechtlichen

Anforderungen entsprechend erforderlich, einen Nachweis der ausgeführten Aktivitäten zu

erbringen.

Die erforderlichen Einstellungen des Security Audit Logs sind vor allem im Rahmen eines be-

trieblichen Sicherheits- und Datenschutzkonzeptes zu betrachten. Dabei sind auch weitere

rechtliche Anforderungen (z.B. GoBS, HGB, Sarbanes-Oxley-Act) zu berücksichtigen.

Das Security Audit Log steht als ‚erweitertes Sicherheitsprotokoll’ in SAP-Systemen zur Ver-

fügung. In mehreren Filtern können in verschiedenen ‚Auditklassen’ unkritische, schwerwie-

gende und kritische Ereignisse für die Protokollierung eingestellt werden.

Über die Transaktion SM19 kann instanzen-, mandanten-, und benutzerbezogen festgelegt

werden, welche Ereignisse protokolliert werden sollen. Auch die Protokollierung von Down-

loads kann vorgenommen werden.

Um das Security Audit Log zu nutzen, ist eine entsprechende Parametrisierung vorzunehmen.

Im SAP Hinweis 539404 werden die häufigsten Fragen zur Konfiguration und Anwendung

des Security Audit Logs beantwortet.

Damit Protokolle aber überhaupt erzeugt werden, muss über die o.g. Einstellungen hinaus in

den Profilparametern der Eintrag rsau/enable auf 1 gesetzt werden.

Mit dem Profilparameter rsau/selection_slots legen Sie fest, wie viele Filter (Slots) Sie bei

der Konfiguration des Security Audit Log zur Verfügung haben. Der Systemdefaultwert ist 2,

seit Release 4.6 sind maximal 10 unterschiedliche Filter konfigurierbar.

In der Transaktion SM19 sind die Felder ‚Benutzer’ und ‚Mandant’ ab SAP NetWeaver 6.40

mit generischen Werten pflegbar. Zur Aktivierung der Funktion wurde der neue Profilparame-

ter rsau/userselection eingeführt, der folgende Werte annehmen kann:

0 = generische Selektion ausgeschaltet



1 = generische Selektion eingeschaltet.

Es ist empfehlenswert von dieser Option Gebrauch zu machen, wenn Sie z.B. für die Organi-

sation Ihres Notfallbetriebes mehrere Notfallbenutzer einrichten wollen. Sie können damit die

Protokollierung der Benutzer NOTFALL1, NOTFALL2, NOTFALL3 durch die Konfigurati-

on eines gemeinsamen Filters für NOTFALL* erreichen. Gleiches gilt auch für mehrere in-

terne wie externe Basis-Administratoren.

Die Verwendung einer generischen Selektion ist ab SAP NetWeaver 6.40 möglich und für äl-

tere Releasestände steht sie für bestimmte Kernelpatches zur Verfügung. Hierbei sind die

technischen Anweisungen aus den SAP Hinweisen 574914 und 539404 zu beachten.

Die maximale Größe der Security Audit Log-Datei wird im Profilparameter

rsau/max_diskspace/local definiert (Defaultwert = 1 MB).

Das Security Audit Log sichert die Protokolle täglich in eine entsprechende Audit-Datei. SAP

empfiehlt, diese Dateien regelmäßig zu archivieren und die Originaldateien nach Bedarf zu

löschen (Transaktion SM18).

Durch eine höhere Anzahl von Filtern (Slots) kann es zu Problemen mit dem Speicher kom-

men. Siehe hierzu auch den SAP-Hinweis 664058.

Die Transaktion SM20/SM20N ermöglicht eine Auswertung der mit Hilfe des Security Audit

Logs erzeugten Protokolle.

System Log

Das SAP ERP protokolliert in Systemprotokollen (Syslog auf Anwendungsebene) unter-

schiedliche Fehlersituationen, wie z.B.

Anmeldeversuche, die zur Sperrung führen

abgebrochene Verarbeitungen

sonstige Probleme und Warnmeldungen

Nutzung der Replace Funktion im Debugger

Das Syslog ist über die Transaktion SM21 aufrufbar.

Wird das Syslog aufgerufen, kann man mit Hilfe der Suchfunktion v.a. über die Spalte Tcod

(Transaktionscode) nach auffälligen Aktivitäten bzw. Fehlern suchen. Hier sind aus daten-

schutzrechtlicher Sicht v.a. Transaktionen aus dem Bereich PA und PD zu nennen.

Aufgezeichnet werden die Ausführung des Programms RSUSR003: Prüfung der StandartUser

auf Passworte und das Ändern von Daten über die DEBUG-Funktion.

Syslog-Dateien sind in der Länge begrenzt und werden bei Erreichen der Maximallänge über-

schrieben. Das Syslog ist daher nur eingeschränkt anwendbar, um auffällige Systemaktivitä-

ten bzw. durchgeführte Verstöße gegen unterschiedliche Bestimmungen zu prüfen.

Es sollte deshalb eine Organisationsanweisung zur regelmäßigen Kontrolle der aufgeführten

Meldungen vorliegen, oder dem Syslog ein größerer Speicherplatz zugewiesen werden (SAP-

Hinweise 4063 und 548624).

Transaktionsprotokollierung STAD (CCMS)

SAP bietet die Möglichkeit, alle ablaufenden Aktivitäten transaktions- und benutzerabhängig

für die jeweils im Einsatz befindlichen Anwendungsserver über das CCMS (Computing Cen-

ter Management System) zu protokollieren. Für jeden Benutzer können statistische Daten auf



täglicher, wöchentlicher und monatlicher Basis erzeugt werden (Transaktion STAD bzw. Re-

port RSSTAT26).

Zur Anzeige der statistischen Daten bzgl. der Benutzer sind die SAP-Berechtigungsobjekte

S_TOOLS_EX (Feld AUTH, Wert S_TOOLS_EX_A) und S_ADMI_FCD (Feld

S_ADMI_FCD, Wert ST0R) erforderlich.

Sicherheitsverletzende Ereignisse können im CCMS auf der Rechenzentrumskonsole als

Alerts dargestellt werden.

Die Nutzung der Transaktion STAD und des Systemmonitors ST03N (der die Daten für die

STAD bereit stellt), sollte aus Datenschutzgründen restriktiv geregelt werden.

Workflowprotokollierung

Die Workflowkomponente (SAP Business Workflow) stellt Werkzeuge zur automatischen

Steuerung und Bearbeitung von anwendungsübergreifenden Abläufen bereit. Hierüber wird es

möglich, alle Bearbeitungsschritte der einzelnen Benutzer (Zeit der Ausführung, Dauer etc.)

automatisch zu protokollieren. Hierfür stehen z.B. die Transaktionen SWU9 (Workflow-Trace

anzeigen), SWI2_xxx (Workitem-Analyse) oder SWI5 (Workload-Analyse) zur Verfügung.

Wird die Workflowkomponente genutzt, stehen somit Auswertungsmöglichkeiten hinsichtlich

des Benutzerverhaltens (z.B. Anzahl der bearbeiteten Vorgänge) zur Verfügung. Die Nutzung

dieser Funktionalität und deren Vergabe ist aus Datenschutzgesichtspunkten einer kritischen

Betrachtung zu unterziehen.

Report-Protokollierung im HCM

Um nachgelagerte Kontrollen bzgl. des Starts von “kritischen” Personalwirtschaftsreports zu

implementieren, besteht die Möglichkeit, diese in die Tabelle T599R einzupflegen. Mit der

Transaktion SM30_V_T599R kann überprüft werden, welche Reports als protokollierungs-

pflichtig definiert sind.

Sofern über die vorgenommenen Einstellungen sichergestellt ist, dass Protokolle erzeugt wer-

den, kann eine Auswertung mit dem Report RPUPROTD durchgeführt werden.

Aus Datenschutzsicht empfehlenswert ist mindestens eine Protokollierung der Nutzung von

flexiblen Auswertungen, wie den Reports RPLICO10 und RPLMIT00, sowie die Nutzung der

flexiblen Fehlzeitenauswertungen, die RPTABSxx Reports.

AdHoc-Query Protokollierung zur Kontrolle der Zweckbindung

Das SAP System bietet die Möglichkeit, die Erstellung und die Ausführung von Queries für

ausgewählte InfoSets (Auswahl von Infotypen bzw. Datenfeldern aus der HCM-Datenbank)

protokollieren zu lassen. Die Protokollierung muss im Customizing mit der Transaktion

SPRO ( SAP Referenz-IMG) SAP NetWeaver Application Server SAP Query

Protokollierung Infosets für Protokollierung festlegen) aktiviert werden. An derselben Stel-

le werden die protokollierten Daten gelöscht.

Die Protokollsätze werden in die Tabelle AQPROT geschrieben, die durch entsprechende

Maßnahmen und Berechtigungen vor Manipulation geschützt werden muss.

Die Protokollierungsdaten können über die Benutzergruppe /SAPQUERY/SQ und das InfoSet

/SAPQUERY/QUERY_LOGGING (im globalen Arbeitsbereich) ausgewertet werden. Hilfs-

weise sind die Protokolle auch mit der Tabellenanzeige (SE17) anzeigbar.

Aus datenschutzrechtlicher Sicht empfiehlt sich die Nutzung der Queryprotokollierung, wenn



die Daten eines betreffenden Infosets von ihrem Charakter die Einhaltung der Zweckbin-

dung fraglich erscheinen lassen (etwa wenn das betreffende Infoset eine große Zahl von

Datenfeldern beinhaltet),

eine große Zahl von Nutzern Zugriff auf die Möglichkeit der Erstellung einer Query zu

dem in Frage stehenden Infoset haben,

datenschutzrechtlich gering qualifizierten Nutzern Zugriff auf die Möglichkeit der Erstel-

lung einer Query zu dem in Frage stehenden Infoset haben und/oder

in dem Infoset Daten besonderer Art gemäß § 3 Abs. 9 BDSG enthalten sind.

In diesen Fällen empfiehlt es sich im Rahmen interner Kontrollen die Einhaltung der Zweck-

bindung laufend zu kontrollieren.

Die Ad-HocQuery-Protokollierung wirkt nicht für die anderen SAP-Query Werkzeuge, näm-

lich SAP-Query und Quick-Viewer. Allerdings lassen sich die SAP-Standard-Queries über

die Funktionen des Ad-Hoc-Query aufrufen und damit protokollieren.


Bei den vorgenannten Punkten ist zwischen Auswertungen zu unterscheiden, die nachgelager-

te Kontrollen im Sinne eines Internen Kontroll Systems (IKS) oder aktivitätsbezogene Kon-

trollen und damit Leistungs- und Verhaltenskontrollen ermöglichen.

Wird die Workflowkomponente, z.T. das System Log oder das CCMS (STAD) genutzt, ste-

hen somit Auswertungsmöglichkeiten bzgl. des Benutzerverhaltens (z.B. Anzahl der bearbei-

teten Vorgänge etc.) zur Verfügung. Die Nutzung dieser Auswertungen kann über das Be-

rechtigungskonzept gezielt eingeschränkt werden. Diesbezüglich ist eine Prüfung der im je-

weiligen Unternehmen ausgeprägten Berechtigungen notwendig. Dazu bietet das Audit In-

formation System einen Ansatzpunkt.

Die Nutzung des Security Audit Log halten wir zur Nachvollziehbarkeit der von speziell ein-

gerichteten Notfallusern durchgeführten Aktivitäten zwangsläufig für geboten. Dieses Log

stellt eine aktive Komponente eines umfassenden Sicherheitsmanagements dar. Zu beachten

ist in diesem Zusammenhang, dass über die dargestellten technischen Maßnahmen hinausge-

hend organisatorische Rahmenbedingungen geschaffen werden müssen, über die die Verwal-

tung und die Zurücksetzung der Kennwörter der Notfalluser sowie die Archivierung und Kon-

trolle der erzeugten Protokolle sichergestellt ist.

4.2.1.10 Komplexe Suchhilfe

Im SAP ERP sind komplexe Suchwerkzeuge an verschiedenen Stellen verfügbar. In vielen

Modulen, wie z.B. dem HCM, stellen sie eigene Informationssysteme dar. Die angebotenen

Suchhilfen können über Customizingfunktionen eingeschränkt werden. Die Definition der

verwendeten Suchhilfen sollte im Projekt unter Hinzuziehung des DSB und ggf. der Arbeit-

nehmervertretung erfolgen.

TREX (Text Retrieval and Extraction Machine), Knowledge Management (KM) und Search

Engine Services (SES) stellen gemeinsam eine integrierte SAP-Suchtechnologie für die un-

ternehmensweite Suche in unstrukturierten wie strukturierten Daten zur Verfügung. Die SAP-

Suchtechnologie kann mit verschiedenen Werkzeugen (TREX-Monitor im KM, TREX-

Admin-Tool und TREX-Alert-Monitor) administriert und überwacht werden.

TREX ermöglich z.B. eine Volltextrecherche über alle Dokumente in einer elektronischen

Personalakte. SAP hat die TREX/SES-Funktionen z.B. in die in der e-Recruiting-Anwendung

(Administration Bewerber etc.) bereitgestellten Funktionen eingebaut. Die Nutzung dieser



Funktionalität ist aus Datenschutzgesichtspunkten, z.B. dem Grundsatz der Zweckbindung,

unbedingt einer kritischen Betrachtung zu unterziehen.

Freie Suche und Freie Abgrenzungen

SAP stellt bei der Administration von Infotypen eine „Freie Suche“ zur Verfügung, die auf al-

le Datenfelder aller Infotypen zugreifen kann aber keiner Protokollierung unterliegt.

Ebenfalls erlaubt die Funktion „Freie Abgrenzungen“ bei der Report-Selektion einen Zugriff

auf die Datenfelder aller Infotypen und stellt das Ergebnis, nämlich die ausgewählten Perso-

nalnummern für den Report bereit. Auch hier kann keine Protokollierung erfolgen.

Die Funktionen „Freie Suche“ und „Freie Abgrenzungen“ können abgeschaltet bzw. durch

Änderung des Suchknotens eingeschränkt und den betrieblichen Erforderlichkeiten angepasst

werden.

4.2.1.11 Zusammenfassung zentraler Risiken

Nachfolgend werden als Übersicht die in der Praxis am häufigsten auftretenden Risiken dar-

gestellt. Diese sind u.a.:

Fehlende Prüfbarkeit und Nachvollziehbarkeit durch

mangelnde Dokumentation der kundenspezifischen Anpassungen und Ausprägung des SAP-

Systems (Customizing, Tabellenpflege, Anwendungsentwicklung etc.),

vergessene Report-Berechtigungsgruppenpflege

nachlässige Handhabung des Berechtigungskonzeptes

nicht eingehaltene Empfehlungen (z.B. ausgeschaltetes Tabellenprotokoll, zugelassene Pro-

grammierung im Produktivsystem)

Umgehung des Zugriffschutzes des SAP ERP-Systems mittels der Programmiermöglich-

keiten (insbesondere Umgehung des Authority-Checks)

Umgehung des Zugriffschutzes des SAP ERP-Systems mittels RFC-fähiger Funktions-

bausteine, die aus einem ungeschützten SAP ERP-System oder von externen Programmen

heraus aufgerufen werden

Zweckentfremdung der Daten über Download und/oder XXL-Listviewer und anschlie-

ßende Verarbeitung zu datenschutzrechtlich nicht zulässigen Zwecken sowie unter unzu-

lässigen Bedingungen (wie etwa mangelnder Prüfbarkeit)

Verletzung der Datenschutzanforderungen durch ein nicht angepasstes Berechtigungskon-

zept

- Verletzung der Datenschutzanforderungen durch zusätzliche Auswertungsprogramme,

z.B.:

- nicht vereinbarte Nutzung eines flexiblen Auswertungssystems, ABAP Reports oder

Queries, d.h. Verarbeitung von Daten ohne Rechtsgrundlage

- Ändern/Erweitern des Funktionsumfangs von ursprünglich genehmigten Programmen

/ ABAPs/ Queries

- Zugriff der Programmierabteilung auf Echtdaten des Personalwesens

- die Programmierung eigener Auswertungen außerhalb einer datenschutzrechtlich ge-

prüften SAP-Anwendung, die auf SAP Daten zugreifen können (z.B. mittels Daten-



bank-Tools, d.h. also auch unter Umgehung der Empfehlungen der SAP Sicherheits-

leitfäden)

Veränderung des Systemzustandes, z.B.:

- Vergabe von Zugriffsberechtigungen an einen unberechtigten Benutzer oder für unzu-

lässige Programme

- Einrichtung nicht vereinbarter Dateien, Datenfelder oder Werteverzeichnissen

- Aufbau unkontrollierter Schnittstellen der Personaldatenbanken zu anderen Systemen

(z.B. Controlling)

- Unsachgemäße Festlegung des Produktivsystem (z.B. Status „Änderbar“)

Missbrauch von Datenträgern, z.B.:

- Datenträger mit Personaldaten auf einer anderen SAP-Installation (z.B. einem Service-

rechenzentrum) oder auf anderen PCs auswerten

- Zweckentfremdung von Sicherheitskopien

- Vertuschen von Verstößen durch Änderung der Systemparameter, z.B. durch:

- Verfälschen der Protokolldateien, z.B. durch zeitweiliges Ausschalten der Tabellen-

protokollierung. Dies erfordert aber Zugriff auf die Profilparameter, die Tabellenakti-

vierungsberechtigung oder die Entwicklerberechtigung

- Umgehung von Zugriffsberechtigungsprüfung durch Ausschaltung der Berechtigungs-

prüfung

Umgehung von Zugriffsberechtigungsprüfung und Protokollierungssystemen durch PC-

Download und Auswertung außerhalb funktionierender Sicherheitsmechanismen.

4.3 Zusammenfassung der Prüfungshandlungen

Neben den oben angesprochenen SAP-Themen sind im Folgenden weitergehende Prüfungen

genannt, die allgemeiner die Thematik der Datenschutzanforderungen betreffen. Solche An-

forderungen sind in der allgemeinen Literatur (vgl. hierzu das Literaturverzeichnis im An-

hang) nachzulesen.

Die Umsetzung der erforderlichen organisatorisch-technischen Maßnahmen zur Gewährleis-

tung der Anforderungen des Datenschutzes sowie die Prüfbarkeit der Installation sind zwin-

gende Zulässigkeitsvoraussetzungen bei der Verarbeitung personenbezogener Daten. Die Prü-

fung, welche organisatorisch-technischen Maßnahmen jedoch erforderlich sind, muss indivi-

duell von jedem Anwenderbetrieb für jede Verarbeitungsform und jeden Verarbeitungszweck

bei der Planung eines Systems geprüft werden (vgl. hierzu die Ausführungen im Kapitel 1

dieses Leitfadens).

So vielfältig die Fragen einer Prüfung auch erscheinen mögen, es gibt einige Prüfungsfragen,

die an dieser Stelle nicht aufgegriffen worden sind. Hierzu zählt etwa die Prüfung des Prin-

zips der Datenvermeidung, der Datensparsamkeit, der Anonymisierung, der Pseudonymisie-

rung oder eine Prüfung der Zulässigkeit der Verarbeitung, z.B. der Übermittlung personenbe-

zogener Daten ins Ausland. Solche Fragen sollten in der Regel im Rahmen der Vorabkontrol-

le, also einer einmaligen Prüfung vor Inbetriebnahme eines betreffenden Systems erfolgen.



Zusammengefasst bedeutet dies: Was im Einzelfall erforderlich oder angemessen ist, damit

auch die Frage nach der Zulässigkeit bestimmter Verarbeitungsformen, ist in allen nachfol-

gend genannten Punkten von Fall zu Fall zu prüfen.

In diesem Kontext ist die folgende Checkliste nicht als Instrument für eine abschließende und

vollständige Prüfung, sondern als Orientierung zu verstehen. Die Verantwortung bleibt voll-

umfänglich bei der verantwortlichen Stelle.

In der Checkliste sind die verschiedenen Prüfungsfelder aus diesem Kapitel in drei Katego-

rien unterteilt, nämlich nach

Anforderungen an die Prüfbarkeit

gegebenenfalls gesonderten technisch-organisatorischen Anforderungen aus vorrangigen

Rechtsvorschriften z.B. aus Betriebs- oder Dienstvereinbarungen

Anforderungen der Datenschutzmaßnahmen gemäß § 9 BDSG und der Anlage zu § 9

BDSG

Die Fragen wurden so beschrieben, dass sich der gelegentliche Benutzer am System die ge-

wünschten Einsichten in das System verschaffen kann. Hierbei verweist die Darstellung

mehrfach auf das Audit Information System und seine Funktionen. Aus diesem Grund wird

empfohlen, sich die Dokumentation des Systemaudits bei der Vorbereitung der Prüfungen er-

gänzend zur Hilfe zu nehmen

4.3.1 Anforderungen an die Prüfbarkeit

4.3.1.1 JAVA-Stack aktiv ?

Prüfen sie mit den Reports RSPARAM bzw. RSPFPAR oder mit den Transaktionen RZ10

bzw. TU02 den Instanzparameter rdisp/j2ee_start:

Bei Wert: 0 ist der JAVA-Stack nicht aktiv und bedarf keiner weiteren Beachtung.

Bei Wert:1 ist der JAVA-Stack aktiv und die JAVA-Engine kann von entsprechenden Pro-

grammen gestartet und genutzt werden. In diesem Fall sind weitere Prüfungen erforderlich,

um das geforderte Datenschutz- und Sicherheitsniveau des Netweaver JAVA-Stacks sicherzu-

stellen. (Diese Prüfungen sind nicht Gegenstand dieser Checkliste bzw. des Datenschutzleit-

fadens SAP ERP 6.0 30.5.2008. )

Betrachten sie mit TU02 auch die Historie der Aktivierungs-Einstellung des JAVA-Stacks.

4.3.1.2 Hardware

Ist jeweils aktuell dokumentiert,

auf welchen Rechnern (Applikationsservern/Arbeitsstationen/Terminals usw.) SAP relevante

Datenverarbeitung (einschließlich der Daten die von SAP-Systemen abgegeben werden bzw.

für SAP-Systeme bereitgestellt werden z.B. Zeiterfassungssysteme) erfolgt?

auf welchen Rechnern die SAP Entwicklungs-, Qualitätssicherungs- und Produktivsysteme

laufen?

Stimmen diese Angaben mit dem SYSTEM --> STATUS und den Tabellen TSYST (Anzeige

über SM31, bzw. SE16) überein? / T000 und T001



mit welchem Betriebssystem diese Rechner betrieben werden?

vgl. SYSTEM --> STATUS in den verschiedenen Systemen.

um welche Rechnersysteme es sich handelt (ob etwa Windows-, UNIX-, IBM iSeries-

Rechner als Server verwendet werden, welche Client-Rechner in Betrieb sind)?

welche Netzwerkkomponenten (z.B. Router) eingesetzt werden?

wer für die Aufrechterhaltung des Rechnerbetriebs zuständig ist?

bestehen Service Level Agreements (SLA)? Mit welchen Vereinbarungen zum Themenbe-

reich Datenschutz wurden diese abgeschlossen?

Liegt eine aktuelle Netzübersicht in grafischer und/oder schriftlicher Form vor?

Liegt dafür eine aktuelle Konfigurationsübersicht und/oder eine Netzbeschreibung vor?

4.3.1.3 Betriebssystem und systemnahe Software

Ist dokumentiert,

welche Betriebssysteme (mit Angabe der Versionsnummer) eingesetzt werden? Vgl. mit ".ys"

im OK-Code oder SYSTEM --> STATUS in den verschiedenen Systemen

welche Datenbanksysteme oder Datenverwaltungssysteme (Angabe des Release-Standes) ge-

nutzt werden? Vgl. mit SYSTEM --> STATUS in den verschiedenen Systemen.

welches Netzwerkbetriebssystem gefahren wird?

welche Netzwerkdienste in der Server-Domain aktiv sind und welche deaktiviert wurden?

welche Router und Firewall-Systeme die SAP-Server Domain und das SAP-Netz von anderen

Netzen (insbesondere externen Netzen) abschotten?

Wird Netzwerkverschlüsselung eingesetzt und auf welchen Strecken? Wenn ja,

zwischen Applikationsservern

zwischen Applikationsservern und Clients

zwischen Applikationsservern und Druckern

welche Wartungszugänge, insbesondere für Fernwartung (Hard- oder Softwarewartung) vor-

gesehen sind?

werden bzw. welche SAP Verschlüsselungstechniken werden eingesetzt (SNC/SSF)? (SNC =

Secure Network Communication / SSF = Secure Store & Forward )

werden digitale Signaturen genutzt?

Welche Zugriffrechte sind (für wen) auf der SAP ERP Datenbank eingerichtet?

Besteht für die vergebenen Zugriffsrechte auf der Ebene der Betriebssysteme und der Netzwerk-

ebenen der betroffenen Server ein Benutzer- und Berechtigungskonzept in Bezug auf SAP-

Objekte?

Besteht außer für die Systemverwalter Zugriff auf die SAP ERP Tabellen und die SAP ERP Da-

tenbank von der Betriebssystemebene aus?



Ist eine Datenbank-Query-Sprache auf der SAP ERP Datenbank im Einsatz?

Wenn ja, gefährden die Zwecke die Integrität und die Prüfbarkeit des SAP-Systems?

Wird diese Query-Sprache uneingeschränkt genutzt (z.B. auch für die Veränderung der Datenba-

sis)?

4.3.1.4 Programmiertechnik

Existieren verbindliche Programmrichtlinien?

Ist festgelegt,

1. welche Programmiersprachen außerhalb SAP verwendet werden und deren Programme auf

SAP zugreifen dürfen (z.B. SQL, JAVA...)?

2. welche Programmgeneratoren oder sonstige Software-Engineering-Werkzeuge in den SAP-

Systemen eingesetzt werden (ABAP Query, Report Writer, etc.)?

In welchen Systemen/Mandanten darf/kann programmiert / entwickelt werden?

1. Überprüfe die Einstellungen der Systemänderbarkeit (inkl.Aufzeichnungspflichtigkeit) in

Tabelle T000 der in Frage kommenden Systeme

2. Überprüfe die Einstellungen der Mandantenänderbarkeit (inkl.Aufzeichnungspflichtigkeit) in

Tabelle T000 der in Frage kommenden Systeme

3. Prüfe die vergebenen Berechtigungen für das Objekt S_DEVELOP mit Aktivität 01 (anle-

gen) und Aktivität 02 (ändern) sowie Objekttyp PROG

4. Überprüfe die vergebenen Entwicklerschlüssel für die in Frage kommenden Systeme / Man-

danten in der Tabelle DEVACCESS

In welchen Systemen/Mandanten dürfen/können Customizing-Einstellungen geändert werden?

1. Überprüfe die Mandanteneinstellungen in der Tabelle T000 in den in Frage kommenden Sys-

temen.

2. Prüfe die vergebenen Berechtigungen für das Objekt S_TABU_DIS Aktivität 02;

S_TABU_CLI „X“.

Ist das Verfahren für Änderung in den Produktivsystemen schriftlich festgelegt?

Wer hat welche Berechtigungen im Change and Transporting System (CTS)? Analysiere die

vergebenen Berechtigungen zum Berechtigungsobjekt S_TRANSPRT mit dem Benutzerinfor-

mationssystem SUIM Benutzer nach Berechtigungswert.

Gibt es Customizing-Aufträge und Programme ohne ausreichende Dokumentation und Bezeich-

nung?

Wird bei allen wesentlichen Änderungen und bei Releasewechsel auf die Vollständigkeit der

Dokumentation und die Revisionsfähigkeit geachtet?

Analysiere insbesondere mit dem CTS Informationssystem (Transaktion SE03) die transportier-

ten eigenen Objekte auf eine ausreichende und verständliche Dokumentation.



Werden geschützte personenbezogene Daten aus dem produktiven SAP ERP-System in ein Data

Warehouse ((SAP Business Warehouse) SAP NetWeaver Business Intelligence) zur allgemeinen

Auswertung übertragen?

Programmtest und Test von Customizing-Einstellungen

Werden für das Qualitätssicherungssystem eigene Testdaten erstellt (z.B. mit Anonymisie-

rungstools)?

Werden Testläufe mit den eigens dafür erstellten Testdaten oder mit Produktivdaten durchge-

führt?

Analysiere die Daten stichprobenartig (z.B. durch Aufruf der entsprechenden Stamm- und Be-

wegungsdaten in den betroffenen Modulen) im Qualitätssicherungssystem / -mandanten im Qua-

litätssicherungssystem.

Ist sichergestellt, dass ein Testlauf mit echten Daten grundsätzlich nur in folgenden Fällen

durchgeführt wird:

mit den Berechtigungen die die Tester auch im Produktivsystem haben? Analysiere die Be-

rechtigungen im Qualitätssicherungs(test-)system mit dem Benutzerinformationssystem

(Aufruf über die Transaktion: SUIM).

im Rahmen des 4-Augenprinzips, sofern über die Rolle der Testenden (Programmierer, Qua-

litätssicherer, Fachabteilung) hinaus weitergehende Rechte auf die Daten vergeben werden

(z.B. alle Rechte für den Personalchef)?

unter der Beteiligung der Fachabteilung, die Eigner der Daten ist?

Ist eine sichere Vernichtung des nicht anonymisierten Testmaterials mit Ausnahme der zu do-

kumentierenden Testdaten gewährleistet?

Werden Testhilfen (etwa die SAP eigenen Computer-Aided Test-Tools (CATT)) eingesetzt und

von wem?

Analysiere die Benutzerstammsätze mit dem Benutzerinformationssystem (Aufruf über die

Transaktion: SUIM).

Ist festgelegt,

welche Daten für den Programmtest und welche für den Abschlusstest in den der Produktion

vorgelagerten Systemen und Mandanten verwendet werden dürfen? Prüfe die SOLL-

Vorgaben (eines notwendigen Testkonzeptes) auf Übereinstimmung mit den durchgeführten

Transporten ins Qualitätssicherungssystem (Testsystem) und dessen Mandanten (Transaktion

SE03 oder mit der AIS-Funktion Report RSWBO040).

wer geeignete Testdaten zur Verfügung stellt?

welche Anonymisierungsverfahren verwendet werden?

ob anonymisierte Testdaten verwendet werden müssen?

welche Stelle für die Formulierung des Programmier- und Änderungsauftrages zuständig ist?

Wird beim Programmtest und für die Programmpflege Fremdpersonal eingesetzt?

Gibt es spezielle Vorgaben einzuhaltender Sicherheitsmaßnahmen (etwa zum Schutz der Doku-



mentation vor Überschreiben bei Mandantenkopien)?

Untersuche insbesondere die Belieferungs- und Transportwege und die vergebenen Berechtigun-

gen in den zu Tests verwendeten Mandanten.

Programmdokumentation

Wird die maschinell unterstützte Dokumentation bei der Entwicklung eigener Objekte genutzt?

Inspiziere mit der Transaktion SA38 (SPRINGEN --> DOKUMENTATION) oder ggf. mit SE38

die Z- und Y-Reports sowie mit der SE11 die Tabellendokumentation der T9-, Z- und Y-

Tabellen.

Beschreibt die Dokumentation,

welches Programm welche anderen Programme aufruft

welche Tabellen verarbeitet werden

welche Berechtigungsprüfungen vorgesehen sind

welche zulässigen Eingabewerte es gibt

aus welchen weiteren Komponenten das Objekt besteht?

Ist sichergestellt, dass durch restriktive Vergabe der Berechtigungen (Objekt S_TRANSPRT)

und durch entsprechende Einstellungen der Systeme und Mandanten alle Programmänderungen

und Änderungen an programmsteuernden Tabellen aufgezeichnet werden?

Ist durch eine entsprechende Rechtevergabe sichergestellt, dass die Dokumentation geschützt ist?

Welche Personen haben Entwicklerrechte (z.B.: S_CTS_DEVELO), wer Verwalterrechte

(z.B.:das Profil S_CTS_ALL) und wer Projektleiterrechte (z.B. das Profil S_CTS_PROJEC)

bzw. vergleichbare Rechte? Untersuche das Berechtigungsobjekt S_TRANSPRT mit SUIM

(Standardberechtigungen).

Oder kann ggf. jede/r auf Grund von Generalberechtigungen (etwa mit dem Profil SAP_ALL) al-

le Transporte freigeben und durchführen?

Werden die Dateien des CTS auf Betriebssystemebene ausreichend geschützt?

Prüfe die Zugriffsberechtigungen zu den SAP-Transportdateien im Verzeichnis \usr\sap\trans auf

Betriebssystemebene.

Ist für jedes Programm eine Programmdokumentation erstellt worden, die zumindest folgende

Teile enthalten sollte?

Anwendungsbereiche des Programms

Programmgliederung und -beschreibung

Prozessbeschreibungen (soweit erforderlich)

Datenflussplan

Beschreibung der Prüftabellen, bzw. des View-Aufbaus

Beschreibung der Integrationsbeziehungen

Dynpros, verwendete Formulare



Programmliste der neuesten Fassung

Protokoll des Abschlusstests und Unterzeichnung des Abnahmeprotokolls

verwendete Testdaten

Bedienungsanleitung für die Arbeitsvorbereitung und -nachbehandlung

Rufe dazu die Onlinedokumentation (SE38 ANZEIGE Dokumentation) auf, bzw. untersuche die

Programmakten der selbst entwickelten Programme.

Gibt es ein Bedienungshandbuch, das alle für die Benutzung des angepassten SAP ERP-Systems

notwendigen Hinweise enthält und die Bedeutung der geforderten Eingabedaten ausreichend er-

klärt?

Prüfe die Benutzer-, bzw. Anwender- und Schulungshandbücher.

Sind die Systeme (Tabelle TSYST) und Mandanten (Tabelle T000) und die Belieferungswege

(Tabellen TASYS), Konsolidierungswege (Tabelle TWSYS) sowie Transportschichten (Tabelle

DEVL) ausreichend dokumentiert und ist deren Einhaltung durch Systemeinstellungen (z.B. Sys-

temänderbarkeit in Tabelle T000) gewährleistet?

Sind die RFC-Schnittstellen ausreichend dokumentiert und gesichert?

Welche Berechtigungen sind für das Objekt S_RFC vergeben, und welche Benutzer haben

diese Berechtigungen?

Prüfe mit dem Report RSPARAM die entsprechend relevanten Systemparameter.

Systemparameter: auth/rfc_authority_check = 1 oder 2,

Systemparameter: snc/accept_insecure_r3int_rfc = ungleich 1

Systemparameter: snc/accept_insecure_rfc = 0

Analysiere das RFC-Protokoll mit Transaktion SM58 auf undokumentierte RFC-Aufrufe

Sind die ALE-Schnittstellen ausreichend dokumentiert und gesichert?

Welche Berechtigungen sind für die Objekte B_ALE* vergeben, und welche Benutzer haben

diese Berechtigungen?

Sind alle ALE-Benutzer als CPIC-Benutzer deklariert?

Sind die Batch-Input-Schnittstellen ausreichend dokumentiert und gesichert?

Welche Batch-Input Benutzer sind für welche Aufgaben angelegt?

Untersuche die Benutzerstämme mit SUIM auf unbekannte Batch-Input Benutzer

Freigabeverfahren

Ist zur Freigabe von neuen oder geänderten Funktionen zur Verarbeitung geschützter personen-

bezogener Daten ein organisatorisches Verfahren entwickelt und durch entsprechende Zugriffs-

rechte im CTS abgesichert worden? Sind die Belange der Datensicherung und des Datenschutzes

dabei ausreichend berücksichtigt worden? Prüfe, ob organisatorische Regelungen durch die ent-

sprechende Vergabe der Berechtigungen zum Objekt S_TRANSPRT umgesetzt wurden.

Ist dokumentiert,



wer für die datenschutzrechtliche Programmfreigabe, und hier insbesondere für die Prüfung

der Rechtsgrundlagen, die notwendigen technisch-organisatorischen Maßnahmen (speziell

Berechtigungsprüfungen) und die Dokumentation, verantwortlich ist?

Prüfe dies gegen die Vergabe der Berechtigungen zum Objekt S_TRANSPRT.

wer die Daten für den Programmablauf zur Verfügung stellt?

Wird ein Freigabeprotokoll angefertigt?

Prüfe die dokumentierenden Texte zu Aufträgen mit Transaktion SE03, Report RSWBOSSR.

Ist die Übernahme freigegebener Objekte in den Produktionsmandanten festgelegt?

Prüfe die Vergabe der Berechtigungen zum Objekt S_TRANSPRT: Wer kann entsprechende

Transporte durchführen?

Sind die Testroutinen und -abläufe für die Überprüfung der ordnungsgemäßen Verfahrensinstal-

lation und des fehlerfreien Programmablaufs ausreichend dokumentiert?

Anwendungsentwicklung

Ist dokumentiert,

welche Personen für die ABAP/Query/Ad hoc Query -Entwicklung zuständig sind?

welche Personen für die Releasewechsel und Wartung des SAP-Verfahrens zuständig sind?

welche Teile des Verfahrens mit eigenem Personal und welche im Auftrag von einem Soft-

warehaus entwickelt wurden?

Ist ausreichend dokumentiert,

seit wann sich die einzelnen SAP-Verfahren im Produktionseinsatz befinden?

wann das Verfahren wesentliche Änderungen erfahren hat, wann neue Module, Funktionen

und Anwendungen hinzugekommen sind?

wer für die Anordnung von Verfahrensänderungen zuständig ist?

wie solche Änderungen im Regelfall und wie im Notfall abzulaufen haben?

Liegt eine Zusammenstellung und Kurzbeschreibung der zu unterschiedlichen Zeitpunkten ein-

gesetzten SAP-Verfahren vor?

Benutzerservice/Systemadministration

Ist festgelegt,

wer für den Rechnerbetrieb verantwortlich ist (Systemverwaltung)?

wer für die Verfahrensadministration verantwortlich ist?

Prüfe die Angaben gegen die Benutzerberechtigungen über das Benutzerinformationssystem

(Transaktion SUIM).

Werden die Aktionen der Systemverwaltung ausreichend protokolliert?

Ist festgelegt, wer wann dieses Protokoll zu welchen Zwecken auswerten soll/darf?



Prüfe die Verwendung und Auswertung der Protokolle.

Werden alle Verfahrensänderungen ausreichend (im CTS und durch Änderungsprotokolle) ma-

schinell protokolliert?

Prüfe insbesondere die Aufzeichnungspflichtigkeit in den betreffenden Mandanten (Tabelle

T000) sowie die Vollständigkeit der Protokollierung im CTS mit SE03.

Sind diese Protokolle ausreichend manipulationssicher aufbewahrt?

Prüfe die vergebenen Zugriffsrechte auf die Dateien des CTS, wer die Protokolle auf SAP- und

auf Betriebssystemebene (SCD0 Aktion 06) archivieren und/oder löschen kann.

Ist außerhalb des SAP ERP-Systems dokumentiert,

welche Personen die Berechtigungsverwaltung (Angabe der Personen) einschließt?

auf welche Daten der Benutzerservice Zugriff hat, bzw. wer einen Trace (Transaktion

ST01) durchführen kann?

welche Daten bei solchen Zugriffen protokolliert werden?

Überprüfe diese Angaben über das Benutzerinformationssystem (Transaktion SUIM)..

Werden Störungen und entsprechende Maßnahmen zu deren Behebung in einem Störungslog-

buch außerhalb des SAP ERP Systems revisionsfähig (Datum, Uhrzeit) dokumentiert?

Ist der Ablauf der Benutzer- und Berechtigungsverwaltung (Einrichten, Kennwortvergabe, Rech-

tevergabe, Löschen/Ändern bei Versetzung oder Ausscheiden) ausreichend dokumentiert und

ausreichend zeitnah organisiert?

Werden hierfür die Möglichkeiten des SAP ERP HCM (Personaladministration und Organisati-

onsmanagement) genutzt?

Rechenzentrumsbetrieb

Ist die Systemkonsole in einem gesicherten Bereich untergebracht und gegen missbräuchliche

Benutzung gesichert?

Kann das Tagesdatum geändert werden?

Gibt es Zwangsprotokollierungen für alle Änderungen am DV-System und an den Systempro-

grammen, auf denen die SAP-Software läuft?

Wird das Systemverwalterkennwort für die betreffenden Systeme regelmäßig geändert und in

geeigneter Weise geheim gehalten?

Ist Accounting

im SAP ERP-System im Einsatz?

außerhalb von SAP ERP im Einsatz?

Ist das Verfahren der Auswertung geregelt?

Gibt es ein RZ-Berichtswesen zur Kontrolle der festgestellten Sicherheitsverstöße?



Werden diese Berichte von der Revision und/oder dem Datenschutzbeauftragten regelmäßig

ausgewertet?

Liegen Operatoranweisungen vor, wie auf Systemmeldungen zu reagieren ist (Bedienungsanlei-

tung)?

Findet eine Schichtprotokollierung statt und gibt es Regelungen für

Führung?

Auswertung?

Aufbewahrung?

Gibt es Aufbewahrungs- und Löschungsfristen für die RZ-Dokumentationen (Protokolle,

Schichtpläne u.ä.)?

Liegen Dokumentationen für den Notfall vor?

Sind für etwaige Benutzung einer Ausweichanlage die Abläufe geklärt?

Ist die Vergabe von Benutzerberechtigungen für die etwaige Benutzung einer Ausweichanlage

geregelt?

Sind im Rechnerraum in der Regel zwei Mitarbeiter je Schicht anwesend?

Gibt es in sensiblen Bereichen eine Funktionssteuerung?

4.3.1.5 Verfahrensanwendung

Prüfe zusätzlich die Maßnahmen zur Datensicherung gemäß § 9 BDSG im Abschnitt 3 der

Checklisten.



4.3.2 Prüfung spezieller Regelungen aus vorrangigen

Rechtsvorschriften (z.B. aus geltenden Betriebsvereinbarungen zu

organisatorisch-technischen Maßnahmen)

Anhang zu Benutzerberechtigungen

Ist der Anhang aktuell geführt?

Wird der Anhang manuell oder mit Hilfe des Systems geführt?

Bei maschineller Erzeugung Kontrolle durch die entsprechende Funktion:

mit dem Report RSUSR002 Übersicht über die Benutzer und die zugeordneten Profile

mit dem Report RSUSR002 Auswertung für ein bestimmtes Objekt, wenn nur Benutzer mit

Zugriff auf bestimmte Berechtigungsobjekte gesucht werden

mit dem Report RSUSR003 Prüfung der Standardbenutzer

mit dem Report RSUSR008, RSUSR009 und RSUSR008_009_NEW Prüfung der Benutzer

mit kritischen Berechtigungen.

Vergleiche - abhängig von der Form der Anlage - die Auflistung mit dem aktuellen Stand der

Tabellen (mittels SA38 und den entsprechenden RSUSR* Reports).

Vergleiche ggf. den SOLL- und den IST-Stand der Anhänge in Form von PC-Dateien im .dbf

oder .xls Format durch eine entsprechende MS Query SQL Abfrage.

Vergleiche auch die weitergehenden Prüfungen zum Zugriffsschutz unter der Rubrik 'Prüfung

von Datenschutz- und Datensicherungsmaßnahmen gem. § 9 BDSG'.

4.3.3 Prüfung der Datenschutzmaßnahmen gemäß § 9 BDSG und der

Anlage

Bei der Prüfung der getroffenen technischen und organisatorischen Maßnahmen nach § 9

BDSG und seiner Anlage folgt die Darstellung der Systematik der Anlagennummerierung -

auch wenn dies im Einzelfall zur doppelten Nennung einzelner Prüfungspunkte führt. Es wer-

den auch hier wieder nur die Punkte weiter ausgeführt, die einen Bezug zu der SAP-Software

haben. Hierbei fallen allen voran die Punkte “Zutrittskontrolle", “Auftragskontrolle" und

“Verfügbarkeitskontrolle” ins Auge, die Themenkomplexe ansprechen, die mit anderen tech-

nischen oder organisatorischen Mitteln außerhalb des SAP ERP-Systems gelöst werden müs-

sen. Soweit es sinnvoll erschien, sind hier auch für solche Fälle einige Prüfungen aufgenom-

men.

4.3.3.1 Nummer 1: Zutrittskontrolle

Laut Nummer 1 ist 'Unbefugten der Zutritt zu Datenverarbeitungssystemen, mit denen perso-

nenbezogene Daten verarbeitet oder genutzt werden, zu verwehren (Zutrittskontrolle)'.

Diese Anforderung ist innerhalb SAP ERP nicht einschlägig.



4.3.3.2 Nummer 2: Zugangskontrolle

Bei Nummer 2 der Anlage zu § 9 BDSG ist 'zu verhindern, dass Datenverarbeitungsanlagen

durch Unbefugte genutzt werden können (Zugangskontrolle)'

Authentifizierung

Ist gewährleistet, dass jeder SAP-Benutzer über einen eigenen Benutzerstammsatz verfügt?

Prüfe stichprobenartig, ob alle Anwender in den betroffenen Abteilungen in der Liste der zu-

gelassenen Benutzer (Report RSUSR002) stehen.

Untersuche weiter mit RSUSR002 die Liste der Benutzer auf ggf. angelegte personenunab-

hängige Benutzer (z.B. 'Lager' oder 'Personalsachbearbeiter' oder ähnliche)

Existieren Vorgaben für sichere Kennwörter? Sind die verbotenen Kennwörter in der Ta-

belle USR40 ausreichend gepflegt?

Welche Einstellungen zur Mindestkennwortlänge gibt es?

Untersuche mit RSPARAM den Systemparameter login/min_password_lng

Welche Einstellungen zum Aufbau von Kennwörtern gibt es?

Untersuche mit RSPARAM die Systemparameter:

- Minimale Anzahl von Zahlen - login/min_password_digits

- Minimale Anzahl von Buchstaben - login/min_password_letters

- Minimale Anzahl von Sonderzeichen - login/min_password_specials

Wird der Kennwortwechsel maschinell erzwungen?

Welche Einstellungen zum Kennwortwechsel gibt es? (Empfehlung 60 oder 90 Tage). Un-

tersuche mit RSPARAM den Systemparameter login/password_expiration_time

Erfolgt ein Abbruch der Verbindung nach einer bestimmten Anzahl von Fehlversuchen

(3)?

Untersuche mit RSPARAM den Systemparameter login/fail_to_session_end und log-

in/fail_to_user_lock

Ist das automatische Anlegen des Benutzers SAP* ausgeschaltet?

Untersuche mit RSPARAM den Systemparameter login/no_automatic_user_sapstar

(Wert sollte bei abgeschaltetem Benutzer 1 sein).

Werden inaktive Benutzer automatisch abgemeldet?

Untersuche mit RSPARAM den Systemparameter rdisp/gui_auto_logout (Achtung! Ge-

tätigte Eingaben werden nicht gespeichert, daher ist der Einsatz eines Bildschirmschoners

mit automatischer Aktivierung nach Zeitlimit und Kennwortschutz zu bevorzugen)

Wurden die Standardbenutzer SAP*, DDIC, SAPCPIC und EARLYWATCH ausreichend

geschützt?

Prüfe mit dem Report RSUSR003 den Status der Benutzerstammsätze (Kennwortände-

rung, -qualität / Sperrung)

Prüfe mit dem Report RSUSR200 inaktive User mit Initialkennworten.



Erfolgt eine Authentifikation am Frontend-Rechner durch andere Mittel, z.B. Chipkarte, wenn

der Rechner in mehr oder weniger öffentlich zugänglichen Räumen steht?

Kann der Benutzer seinen Bildschirm, ohne sich abzumelden, über die Software sperren?

(Einsatz Bildschirmschoner)

Ist der Kennwortschutz (für Bildschirmschoner) insbesondere an Arbeitsplätzen mit Publi-

kumsverkehr, auf der Ebene des PC-Betriebssystems aktiviert?

Erfolgt eine Dunkelschaltung des Bildschirms bei längerer Inaktivität? Nach wie vielen Minu-

ten?

Prüfe insbesondere öffentlich zugängliche Rechner.

Wird für die Gewährleistung der Datensicherheit auf den PCs eine spezielle Sicherheitssoft-

ware eingesetzt?

Wird von der Verschlüsselung der SAP-Daten mittels Secure Store & Forward (SSF) oder

Secure Network Communications (SNC - data privacy protection) Gebrauch gemacht und

in Bezug auf welche Daten?

Ist sichergestellt, dass geschützte Daten aus dem SAP ERP-System nicht per Download

und/oder Mail auf ungeschützte Systeme abfließen können?

Prüfe die vergebenen Berechtigungen zu dem Objekt S_GUI.

Prüfe den Zugang zu Programmen mit XXL-Listviewer-Funktionen.

Ist sichergestellt, dass zur Fernwartung (im Mandant 066) nur zugegriffen werden kann, wenn

die Fernwartung ausdrücklich angefordert wird?

Sind die eingerichteten Benutzerstammsätze für den Rest der Zeit gesperrt?

Wird während der Fernwartung die Protokollierung aktiviert (Transaktion SM19, Security

Audit Log)?

Wird das Protokoll anschließend ausgewertet?

Wer besitzt Berechtigungen zum Anlegen von RFC Verbindungen (SM59) um sich über den

Mandanten 066 hinaus Zugang zu Daten zu ermöglichen?

4.3.3.3 Nummer 3: Zugriffskontrolle

Es ist 3. zu gewährleisten, dass die zur Benutzung eines Datenverarbeitungssystems Berech-

tigten ausschließlich auf die ihrer Zugriffsberechtigung unterliegenden Daten zugreifen kön-

nen, und dass personenbezogene Daten bei der Verarbeitung, Nutzung und nach der Speiche-

rung nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können (Zugriffskon-

trolle).

Zugriffsschutz

Ist eine Zuordnung Benutzer/Funktionen/Befugnisse vorhanden?

Gibt es neben der Benutzerübersicht im Report RSUSR002 eine Tabelle, die auf aktuellem Stand



Benutzer und Berechtigungen ausweist?

Ist die Benutzergruppe im Berechtigungsstammsatz differenziert, d.h. abteilungsweise oder kos-

tenstellenbezogen gepflegt?

Analysiere mit RSUSR002 Anzeige aller Benutzer 'Andere Sicht' die Benutzergruppen.

Sind die umfassenden Generalberechtigungen (wie das Profil SAP_ALL) auf besonders geschütz-

te (und zwangsprotokollierte) Notfallbenutzer beschränkt?

Bestehen für diese umfassenden Generalberechtigungen ergänzende Schutzmassnahmen (z.B.

durch organisatorische Regelungen)

Prüfe mit dem Benutzerinformationssystem (Transaktion SUIM), wer das Profil SAP_ALL und

vergleichbar umfassende Berechtigungen besitzt.

Prüfe, ob die Zwangsprotokollierung für diese Benutzer in der Produktivumgebung über das

Security Audit Log eingeschaltet ist (mit Transaktion SM19).

Untersuche die Protokolle in der Produktivumgebung auf Zuteilung und Nutzung der weitgehen-

den Berechtigungen (z.B. SAP_ALL)

Sind die sensiblen Tabellen durch Tabellenberechtigungen ausreichend geschützt?

Analysiere die Tabellenklassen in der Tabelle TDDAT für das Berechtigungsobjekt

S_TABU_DIS.

Prüfe anschließend mit dem Benutzerinformationssystem (Transaktion SUIM) --> Benutzer nach

komplexen Selektionskriterien für das Berechtigungsobjekt S_TABU_DIS, welche Benutzer auf

diese Tabellenklassen Zugriff haben.

Sind die sensiblen Programme durch Reportklassen ausreichend geschützt?

Analysiere die zugeordneten Reportklassen mit dem Report RSCSAUTH für die zu schützenden

Reports.

Sind alternativ für den Endbenutzer nur Reportbäume zugänglich?

Analysiere, ob die Benutzung der Transaktion SA38 geschützt ist.

Sind alle zu schützenden Transaktionen entweder gesperrt (Ansicht mit dem Report RSAU-

DITC) oder mit einer Berechtigungsprüfung gegen das Objekt S_TCODE versehen?

Analysiere die Tabelle TSTC oder benutze die Transaktion SE93.

Ist gegebenenfalls die Berechtigungsprüfung in kritischen Transaktionen vom Umfang verrin-

gert?

Prüfe den Systemparameter auth/no_check_in_some_cases.

Hat er den Wert Y, prüfe, welche Prüfungen mit SU24 ausgeschaltet/verändert wurden.

Ist das 4-Augenprinzip bei der Pflege und Aktivierung von Berechtigungen und Profilen sowie

bei der Benutzerpflege gewährleistet?

Prüfe die Organisation und die Einstellungen zu den Objekten:

S_USER_GRP (hier insbesondere: Wer kann welche Benutzergruppen pflegen?)

S_USER_PRO



S_USER_AUT

S_USER_ADM

S_USER_SAS

Ist die Betriebssystemebene für die Anwender gesperrt?

Untersuche den Systemparameter rdisp/call_system mit dem Report RSPARAM.

Wenn der Wert nicht 0 ist, kann aus SAP ERP heraus auf das Betriebssystem zugegriffen werden.

Besteht eine organisatorische Trennung zwischen Anwendungsentwicklung, Arbeitsvorbereitung

und -nachhandlung, Dateneingabe, Operating und Archivverwaltung? Analysiere insbesondere

die Vergabe der Berechtigungen zum Objekt S_TRANSPRT.

War der Programmschalter ORGPD zur Nutzung der strukturellen Berechtigung jederzeit ent-

sprechend der Festlegungen eingestellt?

Prüfe die Nutzung des Programmschalters für strukturelle Berechtigungen ORGPD im Modul

HCM in Tabelle T77S0 (Berechtigungshauptschalter HR).

Prüfe die Nutzung der Programmschalters für kontextsensitive BerechtigungenINCON und

XXCON im Modul HCM in Tabelle T77S0 (Berechtigungshauptschalter HR) Gruppe AUTSW.

Ist das Berechtigungskonzept vor der Inbetriebnahme ausreichend getestet worden?

Bedieneroberfläche

Werden die Benutzer durch einen entsprechenden Eintrag im Benutzerstammsatz gezielt auf das

für sie einschlägige Untermenü durchgeschaltet?

Rufe den Report RSUSR002 auf, erzeuge eine Liste aller in Frage kommenden Benutzer, drücke

zweimal den Knopf 'andere Sicht' und untersuche die Spalte 'Startmenü'.

Ist durch das Customizing gewährleistet, dass der Anwender nur Zugriff auf solche Daten hat, die

er zur Erfüllung seiner Aufgaben benötigt?

Prüfe die Masken (DYNPROs) im Zugriff einzelner Benutzer z.B. Mit PA20 in der Personalwirt-

schaft.

Prüfe die Customizing-Einstellungen zu dem Stichwort: "Anpassung der Oberflächen".

Protokollierung

Werden auf Betriebssystemebene die Benutzerdaten protokolliert, so dass erkennbar ist, wer

wann außerhalb von SAP ERP mit welchen Ressourcen wie auf welche SAP ERP-Daten zu-

gegriffen hat?

Ist im Rahmen des Security Audit Log die Protokollierung des Downloads eingeschaltet?

Wird die Protokollierung des Downloads mit der SM20 unter Datenschutzgesichtspunkten regel-

mäßig ausgewertet?



4.3.3.4 Nummer 4: Weitergabekontrolle

Es ist 4. zu gewährleisten, dass personenbezogene Daten bei der elektronischen Übertragung

oder während ihres Transports oder ihrer Speicherung auf Datenträger nicht unbefugt gelesen,

kopiert, verändert oder entfernt werden können, und dass überprüft und festgestellt werden

kann, an welche Stellen eine Übermittlung personenbezogener Daten durch Einrichtungen zur

Datenübertragung vorgesehen ist (Weitergabekontrolle).

Zugriffsschutz

Ist eine Zuordnung

im Berechtigungsstammsatz differenziert, d.h. abteilungsweise oder kostenstellenbezogen Benut-

zer/Funktionen/Befugnisse vorhanden?

Gibt es neben der Benutzerübersicht im RSUSR002 eine Tabelle, die auf aktuellem Stand Benut-

zer und Berechtigungen ausweist?

Ist die Benutzergruppe gepflegt? Analysiere mit RSUSR002 >Anzeige aller Benutzer> 'Andere

Sicht' die Benutzergruppen.

Datenübermittlung

Wird eine Übersicht/Liste über diejenigen Stellen geführt, an die Datenübermittlungen pro-

grammgesteuert stattfinden können?

Prüfe über das Audit Information System in SYSTEM AUDIT: SYSTEM KONFIGURATION

SYSTEM und KOMMUNIKATIONSARTEN R/3 für RFC, CPIC und ALE Verbindungen.

Prüfe ggf. auch Zugriffsberechtigungen von rechtlich Dritten (z.B. externe Beratungsunterneh-

men/System-Wartung)

Das System Audit ist ein Bestandteil der SAP ERP Basis Component. Damit ist seine Funktionali-

tät auch in mySAP™ Systemen, in denen die Komponente Financials nicht aktiv ist (zum Beispiel

reine Human Capital Management-Systeme), verfügbar.

Informationen über Systemeinstellungen, Berechtigungen sowie über das Tabellenwerk sind we-

sentliche Elemente des Audit Information System - System Audit.

Gibt es eine aktuelle Dokumentation der für die selbsttätige Übermittlung einzusetzenden Pro-

gramme gemäß § 10 Abs. 4 BDSG außerhalb des SAP ERP?

Erfolgt außerhalb von SAP ERP eine revisionssichere Protokollierung der programmgesteuerten

Übermittlungen durch Aufzeichnung von

übermittelnder Benutzer

Empfänger

Daten

Datum

Uhrzeit?



Erfolgt eine Verschlüsselung der Daten durch Secure Network Communicatins (SNC) oder Secure

Store & Forward (SSF) auf den Übertragungsstrecken?

Wenn ja, zwischen welchen Instanzen?

SAP GUI und Applikationsserver

Applikationsserver und Drucker?

etc.

Outputmanagement

Ist dokumentiert, welche Ausgaben auf PCs umgelenkt werden können?

Prüfe die Vergabe der Berechtigungen zum Objekt S_GUI (Aktivität = 61).

Erfolgt die Ausgabe der Druckerzeugnisse bei Personaldatenverarbeitung benutzerbezogen?

Sind die Druckerberechtigungen abteilungs- bzw. benutzerbezogen eingerichtet, oder kann es pas-

sieren, dass Ausdrucke versehentlich in ganz fremden Abteilungen/Standorten/Ländern gemacht

werden?

(arbeitsplatznahes Drucken)

Prüfe die Berechtigungen zum Objekt S_SPO_DEV und deren Zuordnung zu Benutzern über Rol-

len oder Profile

Prüfen Sie die Möglichkeit zum PDF-Drucken und zur Ablage und zum Versand der erzeugten

Dokumente.

4.3.3.5 Nummer 5: Eingabekontrolle

Es ist 5. zu gewährleisten, dass nachträglich überprüft und festgestellt werden kann, ob und

von wem personenbezogene Daten in Datenverarbeitungssysteme eingegeben, verändert o-

der entfernt worden sind (Eingabekontrolle).

Protokolleinstellungen

Welche Benutzer werden automatisch protokolliert?

Überprüfe die Definition der Protokollierungsfilter im Security Audit Log über die Transaktion

SM19,

Prüfe mit dem Report RSPARAM ob die Grundeinstellung für die Protokollierung über den

Systemparameter rsau/enable = 1 gegeben ist

Ist die Protokollierung der Tabellenänderungen eingeschaltet?

Prüfe den Systemparameter rec/client mit Report RSPARAM sowie RECCLIENT der TP-

Parameter.

Ist für alle wichtigen Tabellenänderungen (vor allem System- und Schlüsseltabellen) die Proto-

kollierung über die technischen Eigenschaften der Tabellen “eingeschaltet“?

Stelle alle in Frage kommenden Tabellen zusammen und prüfe die Einstellungen (Transaktion

SCU3 oder Anzeige der Tabelle DD09L)



Erfolgt eine revisionssichere Protokollierung der Eingabe in einer Protokolldatei für alle rele-

vanten SAP-Objekte durch Aufzeichnung von

eingebendem Benutzer (Name)

Datum und Uhrzeit der Erfassung

erfassten Daten

Prüfe die eingestellten Änderungsbelege für alle in Frage kommenden Objekte mit Transaktion

SCD0.

Besitzt niemand die Berechtigung zum Löschen der Änderungsbelege?

Prüfe mit dem Benutzerinformationssystem (Transaktion: SUIM), bzw. über den Report

RSUSR002, welcher Benutzer zu dem Objekt S_SCD0 die Aktivität 06 besitzt.

Protokollauswertungen

Welche Protokollierung ist im SAP ERP aktiviert?

Welche Protokollierungsergebnisse des SAP ERP-Systems werden von wem und zu welchen

Zwecken genutzt?

Ist das Security Audit Log aktiviert und wozu? Prüfe Transaktion SM19 und den Parameter

rsau/enable (Wert muss 1 sein) mit dem Report RSPARAM.

Untersuche das Systemlog auf Falschanmeldungen (Transaktion SM21).

Wird ggf. die Tagesstatistik (Transaktion STAD) genutzt? Vgl. den Parameter stat/level = 1.

Welche Anwendungsprotokolle sind eingeschaltet? Vgl. die Konfiguration SLG0 für die

SLG1 (Transaktionen).

Wer kann die Protokollierung der Workflows (der Transaktionen SWI2_xxx und SWI5) nut-

zen und zu welchem Zweck?

Für welche betriebswirtschaftlichen Objekte ist die Protokollierung eingeschaltet? (Transakti-

on SCD0)

Tabellenprotokollierung (Transaktion SCU3)

Untersuche die benutzer-, profil- und berechtigungsbezogenen Änderungsprotokolle (Trans-

aktion SUIM)

4.3.3.6 Nummer 6: Auftragskontrolle

Es ist 6. zu gewährleisten, dass personenbezogene Daten, die im Auftrag verarbeitet werden,

nur entsprechend den Weisungen des Auftraggebers verarbeitet werden können (Auftrags-

kontrolle).



Zugriffsschutz

Ist eine Zuordnung Benutzer/Funktionen/Befugnisse beim Auftragnehmer vorhanden?

Gibt es neben der Benutzerübersicht im RSUSR002 eine Tabelle, die auf aktuellem Stand Benut-

zer und Berechtigungen beim Auftragnehmer ausweist?

Ist die Benutzergruppe der Benutzer beim Auftragnehmer im Berechtigungsstammsatz differen-

ziert, d.h. abteilungsweise oder funktionsbezogen gepflegt? Analysiere mit RSUSR002 Anzei-

ge aller Benutzer 'Andere Sicht' die Benutzergruppen.

Sind die Berechtigungen der Auftragnehmer auf ein Minimum beschränkt?

Ist sichergestellt, dass ausreichende Kontrollen die Risiken weitgehender Berechtigungen beim

Auftragnehmer abdecken?

4.3.3.7 Nummer 7: Verfügbarkeitskontrolle

Es ist 7. zu gewährleisten, dass personenbezogene Daten gegen zufällige Zerstörung oder

Verlust geschützt sind (Verfügbarkeitskontrolle).

Zugriffsschutz

Sind ausreichend regelmäßige Sicherungsläufe vorgesehen?

Ist auf der Ebene des Betriebssystems sichergestellt, dass keine versehentliche Löschung der

SAP-Dateien erfolgen kann? Sind die Zugriffsrechte auf Betriebssystemebene entsprechend der

SAP-Empfehlungen restriktiv vergeben? Werden die vorhandenen Zugriffsrechte regelmäßig

überprüft?

Ist auf der Ebene des Datenbanksystems sichergestellt, dass keine versehentliche Löschung der

SAP-Dateien erfolgen kann? Sind die Zugriffsrechte auf Datenbankebene entsprechend der SAP-

Empfehlungen restriktiv vergeben? Werden die vorhandenen Zugriffsrechte regelmäßig über-

prüft?

Ist der Zugang zu den archivierten Daten und Datenträgern ausreichend geschützt? Prüfen Sie die

entsprechende Organisation.

Ist sichergestellt, dass die Datenverarbeitungsanlagen und die Datenträger ausreichend gegen

Einwirkungen von Feuer, Wasser, Stromausfall und -schwankungen geschützt sind?

Ist sichergestellt, dass die Datenträger ausreichend gegen Einwirkungen von Materialermüdung

geschützt sind? Prüfen Sie, ob es ausreichende Stichproben gibt.

4.3.3.8 Nummer 8: Gewährleistung der Zweckbindung

Es ist 8. zu gewährleisten, dass zu unterschiedlichen Zwecken erhobene Daten getrennt verar-

beitet werden können.



Zugriffsschutz

Ist auf der Ebene des Zugriffsschutzes eine ausreichend strikte Zuordnung Benut-

zer/Funktionen/Befugnisse zu zulässigen Zwecken vorhanden?

Prüfe für einzelne Benutzergruppen die Zugänglichkeit

der Programmbibliothek

weiterer Funktionalitäten wie ABAP Query und Ad-hoc Query

der Programmierwerkzeuge

der Administrationsfunktionen

des ABAP-Listviewers in Auswertungsprogrammen für personenbezogene Daten

insbesondere der Protokolle und Änderungsbelege

Sonstige Maßnahmen

Ist auf der Ebene der einzelnen SAP ERP-Systeme, Mandanten und Buchungskreise eine ausrei-

chende Abgrenzung der Benutzer/Berechtigungen nach ihren Funktionen/Befugnisse vorhanden?

Sind die verbleibenden Risiken durch entsprechende Schulung der Benutzer in den Fachabteilun-

gen, der Programmierung und der Systemverwaltung abgedeckt?

4.3.3.9 Sonstige Prüfungen

Der Einleitungssatz der Anlage zu § 9 BDSG fordert weiter, 'die innerbehördliche oder inner-

betriebliche Organisation so zu gestalten, dass sie den besonderen Anforderungen des Daten-

schutzes gerecht wird‘. Diese Anforderung sollte durch folgende Untersuchungen abgeprüft

werden:

Allgemeine Richtlinien

Existieren Richtlinien für die Datensicherheit (allgemein oder speziell für das DV-Verfahren) und

sind diese auf einem aktuellen Stand?

Werden diese Richtlinien allen Beteiligten in geeigneter Weise bekannt gemacht?

Gibt es Auswertungen nach Sicherheitsverstößen?

Welche Protokolle sind von wem?

Ist durch das Verfahren sichergestellt, dass Mängel an den technisch-organisatorischen Maßnah-

men oder Datenschutzverstöße umgehend an den betrieblichen Datenschutzbeauftragten weiter-

geleitet werden und mit diesem zusammen Abhilfe geschaffen wird?

Wurde eine Risiko- und Schwachstellenanalyse durchgeführt?



Zugriffsverwaltung und Protokollauswertungen

Werden die Zugriffsberechtigungen eines ausscheidenden oder zu versetzenden Benutzers sofort

gelöscht? Gibt es ggf. einen automatisch ablaufenden Workflow zum Löschen eines Benutzers?

Ist die maschinelle Verwaltung und Pflege der Benutzerstammsätze, Berechtigungen, Profile und

ggf. Rollen ausreichend und zeitnah geregelt?

Prüfe das Berechtigungsrahmenkonzept und die organisatorische Abwicklung der Benutzeradmi-

nistration sowie die Pflege von Profilen, Berechtigungen und Rollen.

Wird dabei auf die Revisionsfähigkeit der Zugriffsberechtigungen geachtet?

Wird durch das interne Kontrollsystem regelmäßig die Einhaltung des Berechtigungskonzepts

geprüft? Wie häufig finden solche Untersuchungen statt?

Gibt es Sanktionen für erkannte Missbräuche und Missbrauchsversuche?

Wird die Protokollierung der Benutzer nach Anmeldedatum und Kennwortänderung (Report

RSUSR006), regelmäßig überprüft?

Ist die Weitergabe der Druckerausgaben an die Anwender geregelt, sofern diese keinen Arbeits-

platzdrucker haben?

Sind die Berechtigungen, auf Drucker zuzugreifen, ausreichend beschränkt?

Ist das Sicherungsverfahren auf Datenbankebene schriftlich dokumentiert?

Wurde beachtet, dass die Sicherungsdateien zu schützen sind, etwa durch ein Kennwort oder

Freigabedatum?

Werden die eingerichteten Schutzmaßnahmen regelmäßig einem eingehenden Test unterzogen,

um festzustellen, ob sie noch den gewünschten Schutzzweck erfüllen?



5 Auftragsdatenverarbeitung und

konzerninterner Datenaustausch

Im Kapitel 5 wird auf unterschiedliche Formen der Auftragsdatenverarbeitung eingegangen,

z.B. die Vergabe einfacher oder operativer Aufgaben an ein Shared Service Center (intern o-

der extern), die Schaffung globaler Prozesse mit einer gesellschaftsübergreifenden Verarbei-

tung personenbezogener Daten oder die Nutzung externer Dienstleister (klassisches Outsour-

cing).

Es muss im Konzern/Unternehmensverbund klar definiert sein, wer ‚Herr der Daten’ ist, denn

nach dem BDSG muss jede rechtlich selbständige Einheit (Legal Entity, also jedes selbstän-

dige Unternehmen des Konzerns) als verantwortliche Stelle, beispielsweise bei einem Aus-

kunftsbegehren des Betroffenen Auskunft geben können über den Datenfluss, die -kategorien

und die unterschiedlichen zugriffsberechtigten Personenkreise.

Seit der Novellierung des § 11 BDSG in 2009 hat sich bei einer Auftragsdatenverarbeitung

der Auftraggeber „vor Beginn der Datenverarbeitung und sodann regelmäßig von der Einhal-

tung der beim Auftragnehmer getroffenen technischen und organisatorischen Maßnahmen zu

überzeugen. Das Ergebnis ist zu dokumentieren.“

Die Einhaltung der seitdem stark formalisierten Auftragsgestaltung sowie der Kontrollpflich-

ten sind bußgeldbewährt.

5.1 Abgrenzungen beim Thema Outsourcing und Datenschutz

Grundsätzlich ist zwischen internem und externem Outsourcing zu unterscheiden. Beim inter-

nen Outsourcing wird die Datenverarbeitung von einer rechtlich unselbständigen Abteilung

innerhalb der verantwortlichen Stelle übernommen. Es liegt aus Sicht des BDSG also DV für

eigene Zwecke vor. Beim externen Outsourcing hingegen findet die Erhebung, Verarbeitung

und/oder Nutzung der personenbezogenen Daten des Betroffenen bei einer anderen rechtlich

eigenständigen Stelle statt. Es ist hier anhand des konkreten Einzelfalles zu untersuchen, ob

dies sich noch im Rahmen einer Auftragsdatenverarbeitung im Sinne des § 11 BDSG bewegt

oder ob der Outsourcingnehmer die personenbezogenen Daten des Betroffenen im Rahmen

einer Übermittlung zur eigenständigen Erhebung, Verarbeitung bzw. Nutzung (Funktions-

übertragung) erhält.

Als Beispiele für die Auslagerung von Dienstleistungen sind zu nennen:

Auslagerung der System-/Netzwerkadministration und des Rechnerbetriebs an ein anderes

(Konzern-)Unternehmen im Rahmen eines Service Vertrages

Auslagerung der Systemwartung und –pflege an ein anderes Unternehmen (z.B. (Fern-)

Wartung durch SAP im Rahmen des Softwarepflegevertrags)

Auslagerung von Aufgaben der Systemadministration bzw. des Rechnerbetriebs an ver-

schiedene Unternehmen

Wahrnehmung von Aufgaben zum Umgang mit personenbezogenen Daten durch externe

Dienstleistungszentren (Shared-Service-Center, Call Center)

Übertragung der Bereitstellung von E-Business-/Internet-Diensten an einen Service Pro-

vider



Verlagerung von Dienstleistungen ins Ausland (EU/EWR/Drittländer)

Cloud-Dienste (z.B. Success Factors)

Zur Abgrenzung der Begriffe Auftragsdatenverarbeitung und Funktionsübertragung:

Die Auftragsdatenverarbeitung ist dadurch gekennzeichnet, dass Auftraggeber und Auftrag-

nehmer - und dies gilt auch für zwei Konzernunternehmen - voneinander rechtlich unabhän-

gige und selbständige Unternehmen sind. Es gilt aber die Privilegierung, dass Auftraggeber

und Auftragnehmer rechtlich einheitlich als eine einzige verantwortliche Stelle gesehen wer-

den (vgl. § 3 Abs. 8 BDSG). Dies resultiert daraus, dass der Auftragnehmer dem Auftragge-

ber lediglich bei der Verlagerung von Verfahren oder Verfahrensschritten weisungsgebunde-

ne Unterstützung leistet. Datenerhebung, -verarbeitung oder -nutzung werden hierbei ledig-

lich in ihrer Hilfsfunktion für die Erfüllung der Aufgaben und Geschäftszwecke der verant-

wortlichen Stelle ausgelagert.

Rechtlich anders behandelt werden soll der Fall, wenn der Auftragnehmer - im Falle des Out-

sourcings als Outsourcingnehmer - mehr als nur weisungsgebundene Funktionen wahrnimmt.

Dies ist dann der Fall, wenn dem Outsourcingnehmer daneben weitere Aufgaben oder Funkti-

onen mit eigenen Entscheidungskompetenzen in Bezug auf die genutzten personenbezogenen

Daten übertragen werden. Durch die Übertragung dieser Aufgaben und Funktionen ändert

sich der Charakter der datenschutzrechtlichen Rechtsbeziehung. Die in diesem Zusammen-

hang verwendeten Daten dienen dann nicht mehr dem Geschäftszweck, diese im Auftrag für

den Outsourcinggeber gemäß seiner Weisungen zu verarbeiten, sondern dazu, dass der Out-

sourcingnehmer eine bestimmte vertraglich geschuldete Leistung in eigener Verantwortlich-

keit erarbeiten und erbringen möchte, zu deren Erfüllung er diese Daten benötigt. In diesem

Fall wird eine ganze Aufgabe an den Outsourcingnehmer übertragen, die er eigenverantwort-

lich wahrnimmt. Es wird also der Auftrag zur Erbringung einer Leistung erteilt, deren Be-

standteil auch die Erhebung, Verarbeitung oder Nutzung personenbezogener Daten ist, die der

Outsourcinggeber zur Verfügung stellt. Man spricht hier von einer so genannten Funktions-

übertragung.32

Die Abgrenzung von Auftragsdatenverarbeitung und Funktionsübertragung ist insbesondere

bei der Verlagerung von Aufgaben in Shared Service Center oder Call Center anhand der

oben genannten Kriterien im Einzelfall vorzunehmen.

Soweit die Shared Service Center oder Call Center nach definierten Weisungen, Checklisten,

Entscheidungsbäumen oder im Bereich einfacher Sachbearbeitungen arbeiten, spricht dies für

die Auftragsdatenverarbeitung. Erhält der Dienstleister allerdings im Rahmen der übernom-

menen Aufgabe eigene Datenherrschaft, z. B. dadurch, dass er eigenständig über die Weiter-

gabe von Daten oder Auswertungen im Konzern entscheiden kann, spricht dies für eine Funk-

tionsübertragung.

Wenn innerhalb eines Konzerns Outsourcing betrieben wird, sind die anzuwendenden

Rechtsvorschriften nicht anders zu interpretieren als bei einem Outsourcing zwischen sonsti-

gen fremden Unternehmen.

32 Zur Differenzierung zwischen „für die Verarbeitung Verantwortlicher“ und „Auftragsverarbeiter“ im

Hinblick auf die EU-Datenschutz-Richtlinie 95/46/EG s. WP 169: „Stellungnahme 1/2010 zu den

Begriffen „für die Verarbeitung Verantwortlicher“ und „Auftragsverarbeiter““ der ARTIKEL-29-

DATENSCHUTZGRUPPE, http://ec.europa.eu/justice/data-protection/article-

29/documentation/opinion-recommendation/index_en.htm#h2-2

http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/index_en.htm#h2-2

http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/index_en.htm#h2-2



5.2 Vertragsgestaltung zwischen Auftragnehmer und Auftraggeber

Im Folgenden werden - aufgrund der vielfältigen Fragestellungen in diesem Zusammenhang -

ausgewählte, grundsätzliche Punkte, die bei Überlegungen zur Vertragsgestaltung zwischen

Auftraggeber und Auftragnehmer zu beachten sind, behandelt. Ausführliches zu Vertragsge-

staltungen aus datenschutzrechtlicher Sicht kann in Fachbüchern nachgelesen werden (siehe

[Müthlein/Heck]33). Diesem Buch sind auch wesentliche Teile der in diesem Unterkapitel auf-

geführten Texte entnommen.

Mit der Novelle 2009 des § 11 BDSG sind insbesondere folgende Punkte im Auftrag zwi-

schen Auftraggeber und Auftragnehmer verbindlich zu regeln (zu den Änderungen der Novel-

le 2009 s. [GDD]34, zu weiteren Vorschlägen zu Vertragsmustern z. B. [Bitkom]35 und [ LfD

Hessen]36):

1. der Gegenstand und die Dauer des Auftrags,

2. der Umfang, die Art und der Zweck der vorgesehenen Erhebung, Verarbeitung oder Nut-

zung von Daten, die Art der Daten und der Kreis der Betroffenen,

3. die nach § 9 BDSG zu treffenden technischen und organisatorischen Maßnahmen,

4. die Berichtigung, Löschung und Sperrung von Daten,

5. die nach Absatz 4 bestehenden Pflichten des Auftragnehmers, insbesondere die von ihm

vorzunehmenden Kontrollen,

6. die etwaige Berechtigung zur Begründung von Unterauftragsverhältnissen,

7. die Kontrollrechte des Auftraggebers und die entsprechenden Duldungs- und Mitwir-

kungspflichten des Auftragnehmers,

8. mitzuteilende Verstöße des Auftragnehmers oder der bei ihm beschäftigten Personen ge-

gen Vorschriften zum Schutz personenbezogener Daten oder gegen die im Auftrag ge-

troffenen Festlegungen,

9. der Umfang der Weisungsbefugnisse, die sich der Auftraggeber gegenüber dem Auftrag-

nehmer vorbehält,

10. die Rückgabe überlassener Datenträger und die Löschung beim Auftragnehmer gespei-

cherter Daten nach Beendigung des Auftrags.

Dabei ist zu beachten, dass es im öffentlichen Bereich unterschiedliche Anforderungen der

Landesdatenschutzgesetze an die Vertragsgestaltung und Information bei der Auftragsdaten-

verarbeitung (im Sinne des § 11 BDSG) gibt. Die landesspezifischen Anforderungen sind für

öffentliche Stellen unbedingt zu beachten.

33 Th. Müthlein, J. Heck: Outsourcing und Datenschutz. Vertragsgestaltung aus datenschutzrechtlicher

Sicht, 3. neu überarb. Auflage, 2006, Datakontext Fachverlag

34 GDD, Neue Anforderungen an die Auftragsdatenverarbeitung nach § 11 BDSG, Sonderbeilage zu

RDV 5/2009 https://www.gdd.de/nachrichten/news/neues-gdd-muster-zur-

auftragsdatenverarbeitunggemas-a7-11-bdsg

35 http://www.bitkom.org/de/publikationen/38336_45940.aspx

36 http://www.datenschutz.hessen.de/mustervereinbarung_auftrag.html

https://www.gdd.de/nachrichten/news/neues-gdd-muster-zur-auftragsdatenverarbeitunggemas-a7-11-bdsg

https://www.gdd.de/nachrichten/news/neues-gdd-muster-zur-auftragsdatenverarbeitunggemas-a7-11-bdsg

http://www.bitkom.org/de/publikationen/38336_45940.aspx

http://www.datenschutz.hessen.de/mustervereinbarung_auftrag.html



Für besonders sensible Bereiche wie z.B. Krankenhäuser und Sozialversicherungsträger gel-

ten weitere, z.T. strengere Regelungen zum Outsourcing.

5.2.1 Pflichten des Auftraggebers und Auftragnehmers

Als „Herr der Daten” ist der Auftraggeber für die Einhaltung der Vorschriften des BDSG und

der anderen Vorschriften über den Datenschutz verantwortlich. Insbesondere ist er verant-

wortlich für die Zulässigkeit der Erhebung/Verarbeitung/Nutzung der Daten, für die Wahrung

der Rechte des Betroffenen, für die Haftung ihm gegenüber und für die Einhaltung der daten-

schutzrechtlichen Kontrolle. Der Auftragnehmer ist unter Prüfung der Eignung der angebote-

nen technischen und organisatorischen Maßnahmen sorgfältig auszuwählen (kaufmännische

Sorgfaltspflicht). Zwingend ist insbesondere37 die schriftliche Festlegung der Datenerhebung/-

verarbeitung/-nutzung, der technischen und organisatorischen Maßnahmen und etwaiger Un-

terauftragsverhältnisse. Es ist zu regeln, dass nur nach den Weisungen des Auftraggebers ver-

fahren wird.

Häufig wird man auf eine ausführliche Beschreibung der Datenerhebung/-verarbeitung/-

nutzung in einer Datenschutzvereinbarung mit dem Dienstleister verzichten können, da diese

Aspekte im Allgemeinen in den Service Level Agreements (SLA) definiert werden. Neben

den eigentlichen Leistungen beinhalten die SLAs häufig auch Sicherheitsaspekte, z. B. zur

Verfügbarkeit, Recovery oder Virenschutz. Insoweit reicht in der Datenschutzvereinbarung

ein Verweis auf die SLAs aus.

Der Auftraggeber hat die Pflicht, sich gemäß § 11 Abs. 1, 2 S. 3 BDSG von der Einhaltung

der technischen und organisatorischen Maßnahmen beim Auftragnehmer zu überzeugen. Die

Pflicht zur Überwachung erstreckt sich auf Betriebsabläufe, DV-Systeme und Räumlichkeiten

und unterliegt der Verschwiegenheitsverpflichtung bezüglich der erlangten Kenntnisse. Das

Ergebnis der Überprüfung, die schon vor Beginn der Datenverarbeitung zu erfolgen hat, ist zu

dokumentieren. Dabei sollte auch der Zeitrahmen für die Folgeuntersuchungen– abhängig von

der Sensitivität der verarbeiteten Daten- festgelegt werden. Zur Vereinfachung eines Nach-

weises sollte diese Unterlage dem Vertrag beigefügt werden.

Der Auftragnehmer muss intern sicherstellen, dass die Datenerhebung, -verarbeitung bzw. -

nutzung nur nach den festgelegten Weisungen erfolgt und die technischen und organisatori-

schen Maßnahmen (gemäß Anlage zu § 9 BDSG) eingehalten werden. Seine Mitarbeiter sind

auf das Datengeheimnis zu verpflichten.

Die Aufnahme der Verfahren, die auf den Auftragnehmer übertragen werden, ist weiterhin im

Verfahrensverzeichnis des Auftraggebers zu führen.

5.2.2 Umfang der Datenverarbeitung / Weisungen

Es ist zu vereinbaren, wie der Leistungsumfang sein soll, welche Datenbestände (Art, Um-

fang) vom Auftragnehmer verwalten und welche Verfahren darauf angewendet werden sollen

(ergibt sich i. d. R. aus dem SLA, s.o.). Da sich die konkrete Ausgestaltung des Auftragsver-

hältnisses ändern kann, ist es sinnvoll, solche Sachverhalte, die sich während der Vertrags-

37 s. im einzelnen Katalog des § 11 Abs. 2 BDSG



laufzeit ändern können (z. B. Wechsel von Personen) als Anlage zum SLA oder der Daten-

schutzvereinbarung festzulegen. Hierzu gehören z. B.:

Ort, Zeitpunkte und ggf. Reihenfolge der Erhebung, Verarbeitung bzw. Nutzung

Verfahren der Datenübertragung (Datenumfang, Leitungsweg, Verschlüsselung oder an-

dere Sicherungsmaßnahmen)

Berechtigung bzw. Pflicht zum Transport/Versand von Dateien, Datenträgern, Belegen

oder Listen

Sonderanforderungen an den Auftragnehmer (dazu berechtigte Personen des Auftragge-

bers, Ansprechpartner beim Auftragnehmer)

Festlegung der Zuständigkeit für die Archivierung (Aufbewahrungsfristen) und Löschung

(siehe auch Kapitel 2.3.4.5)

Die vertraglichen Vereinbarungen können daneben durch Weisungen im Einzelfall ergänzt

werden, z. B. in Form eines Auftragsscheins. Die Weisungen können dabei aber nicht über die

in den Verträgen festgelegten Rechte der Parteien hinausgehen und erlauben keine einseitige

Vertragsänderung.

Der Weisungsvorbehalt des BDSG bezieht sich auf den Umgang mit den Daten. Hierüber zu

bestimmen ist allein das Recht des Auftraggebers als „Herr der Daten“. Möchte der Auftrag-

geber weitergehende Weisungsrechte, sind diese gesondert auszuhandeln und vertraglich fest-

zulegen. Zu den Regelungsaspekten nach § 11 Abs. 2 S. 1 Nr. 1 (Gegenstand und die Dauer

des Auftrags) und Nr. 2 BDSG (Umfang, die Art und der Zweck der vorgesehenen Erhebung,

Verarbeitung oder Nutzung von Daten, die Art der Daten und der Kreis der Betroffenen) gibt

das Bayerische Landesamt für Datenschutzaufsicht38 folgende Hinweise:

1. der Gegenstand und die Dauer des Auftrags,

Erläuterungen:

a) Gegenstand:

Wie Lohnberechnung, Adressenverarbeitung, Datenerhebung, DV-System-Betreuung,

Wartung/Fernwartung, Datenträgerentsorgung, usw.

b) Dauer:

einmalig, befristet bis ..., unbefristet mit Kündigungsmöglichkeit ab ...

2. der Umfang, die Art und der Zweck der vorgesehenen Erhebung, Verarbeitung oder Nut-

zung von Daten, die Art der Daten und der Kreis der Betroffenen,

Erläuterungen:

a) Umfang, Art, Zweck

Welche Leistungen sind im Einzelnen zu erbringen (Leistungsverzeichnis, Pflich-

tenheft).

Auftragsdatenverarbeitung nur im Inland, auch im EU-/EWR-Bereich oder auch in

Drittstaaten.

38 Auftragsdatenverarbeitung nach § 11 BDSG - Gesetzestext mit Erläuterungen; Stand: Mai 2013,

http://www.lda.bayern.de/lda/datenschutzaufsicht/lda_daten/auftragsdatenverarbeitung.pdf

http://www.lda.bayern.de/lda/datenschutzaufsicht/lda_daten/auftragsdatenverarbeitung.pdf



Welche Leistungsphasen sollen außer Haus gegeben werden.

Vorübergehende oder dauernde Speicherung von Daten beim Dienstleister.

Welche Menge an Daten, Datensätzen, Datenträgern.

Umfang und Dauer einer Videoüberwachung.

b) Art der Daten

Personaldaten, Vertragsdaten/Bestelldaten, Werbedaten, Werbewidersprüche, Befra-

gungsergebnisse, Gesundheitsdaten, Videoaufzeichnungsdaten, Nutzungsdaten aus Te-

lemediendiensten oder Telekommunikationsdiensten, Telefongesprächsaufzeichnun-

gen, DV-Protokollierungsdaten,

c) Kreis der Betroffenen

Mitarbeiter, Stellenbewerber, Kunden, Interessenten, Lieferanten, Werbekontakte, Be-

sucher/Gäste, Passanten, Systemnutzer usw..

Zu den Regelungsaspekten nach § 11 Abs. 2 S. 1 Nr. 9 BDSG (der Umfang der Weisungsbe-

fugnisse, die sich der Auftraggeber gegenüber dem Auftragnehmer vorbehält) gibt das Baye-

rische Landesamt für Datenschutzaufsicht folgende Hinweise:

Erläuterungen:

Einzelweisungen zur Auftragserledigung, zu (zusätzlichen) Sicherheitsmaßnahmen,

zum Vorgehen bei Datenschutzverstößen

Weisungen zur Gestaltung bzw. Beendigung von Subunternehmerverhältnissen

Wer erteilt die Weisungen von Seiten des Auftraggebers und an wen sind die Weisun-

gen beim Dienstleister zu richten, in welcher Form erfolgen die Weisungen

usw..

5.2.3 Wer erteilt die Weisungen von Seiten des Auftraggebers und an

wen sind die Weisungen beim Dienstleister zu richten, in welcher

Form erfolgen die Technische und organisatorische Maßnahmen

Die technischen und organisatorischen Maßnahmen gemäß Anlage zu § 9 BDSG sind zur

Konkretisierung der Auswahlkriterien im schriftlichen Vertrag zu fixieren. Dadurch wird die

Transparenz der Erhebung, Verarbeitung bzw. Nutzung erhöht und eine Kontrolle erleichtert.

Eine solche Beschreibung dient auch dem Auftraggeber bei der Wahrnehmung seiner Kon-

trollrechte im Rahmen der Auftragskontrolle nach Nr. 6 der Anlage zu § 9 BDSG gegenüber

dem Auftragnehmer. Außerdem ist sie für den Auftraggeber im Falle der Beweisführung bei

der Haftung gegenüber dem Betroffenen hilfreich.

Die Maßnahmen sollten möglichst detailliert beschrieben werden, eine bloße Wiederholung

der Anlage zu § 9 BDSG reicht in keinem Fall aus. Es empfiehlt sich, diese Maßnahmen in

einer separaten Beschreibung zu dokumentieren, auf die im Vertrag hingewiesen wird. Dies

hat den Vorteil, dass bei Anpassungen der Maßnahmen an den neusten technischen Standard

nur die Anlage zum Vertrag geändert werden muss. Sicherheitsmaßnahmen, die bereits in den

SLAs beschrieben oder Gegenstand anerkannter gültiger Zertifikate wie ISO 2700x sind,

müssen hier nicht mehr wiederholt werden. Hier kann ein Verweis auf diese ausreichen.

Bei einem Outsourcing im Konzern mit bestehenden, festgeschriebenen Sicherheitsstandards

kann der Verweis auf diese ausreichen.



Für Details wird auf gesonderte Kapitel des Datenschutzleitfadens verwiesen.

Zu den Regelungsaspekten nach § 11 Abs. 2 S. 1 Nr. 3 BDSG (nach § 9 BDSG zu treffenden

technischen und organisatorischen Maßnahmen) gibt das Bayerische Landesamt für Daten-

schutzaufsicht folgende Hinweise:

Erläuterungen:

Vgl. im Einzelnen die Anlage zu § 9 Abs. 1 BDSG, wobei die Maßnahmen konkret sach-

verhaltsbezogen anzusprechen sind, z. B.

Festlegung der Transportwege und -verfahren für die Daten (manuell, elektronisch)

mit den dabei zu treffenden Sicherheitsmaßnahmen

Technische Vorsorgemaßnahmen zur Ausfallsicherheit (Ersatzrechenzentrum, Notfal-

leinrichtungen)

Verfahrensweise zur Trennung der Daten verschiedener Auftraggeber

Festlegungen zu Protokollierungen der Verarbeitungen beim Dienstleister und zu Si-

cherheits-speicherungen/Backup, sichere Lagerung solcher Datenträger

Festlegungen zur Aufbewahrung der zu entsorgenden Datenträger und der Sicher-

heitsstufe für die Löschung/Vernichtung

Regelungen zum Technik-Einsatz in Callcentern zum Schutz vor Datenunterschlagun-

gen.

5.2.4 Wahrung der Rechte der Betroffenen

Die Rechte des Betroffenen sind gegenüber dem Auftraggeber geltend zu machen. Das bedeu-

tet für das Auftragsverhältnis, dass der Auftraggeber auch alle notwendigen Informationen

und Mittel zur Wahrung dieser Rechte auf Benachrichtigung, Auskunft, Sperrung und Lö-

schung durch den Auftragnehmer erhalten muss. Es ist insoweit eine Unterstützungspflicht

vorzusehen.

Zu den Regelungsaspekten nach § 11 Abs. 2 S. 1 Nr. 4 BDSG (Berichtigung, Löschung und

Sperrung von Daten) gibt das Bayerische Landesamt für Datenschutzaufsicht in der Regie-

rung von Mittelfranken folgende Hinweise:

Erläuterungen:

Sperrung oder Löschung von Daten nach Abarbeitung von Einzel-Dienstleistungen,

sichere Löschverfahren

Mitwirkung des Dienstleisters bei Anträgen von Betroffenen an den Auftraggeber nach

§ 34 oder § 35 BDSG

5.2.5 Pflichten des Auftragnehmers nach § 11 Abs. 4 BDSG,

insbesondere die von ihm vorzunehmenden Kontrollen

Zu den Regelungsaspekten nach § 11 Abs. 2 S. 1 Nr. 5 BDSG (Pflichten des Auftragnehmers

nach § 11 Abs. 4 BDSG, insbesondere die von ihm vorzunehmenden Kontrollen) gibt das

Bayerische Landesamt für Datenschutzaufsicht folgende Hinweise:



Erläuterungen:

Aus § 11 Abs. 4 BDSG sind insoweit folgende Vorschriften relevant:

§ 5 BDSG – Datengeheimnis

§ 9 BDSG – Datensicherheit

§ 4f, § 4g BDSG – Datenschutzbeauftragter

Beispiele:

Verpflichtung der Beschäftigten des Dienstleisters auf das Datengeheimnis (ein-

schließlich entsprechender Belehrung) und Bestellung eines Datenschutzbeauftragten

beim Dienstleister, Name und Kontaktdaten des Datenschutzbeauftragten

Kontrollmaßnahmen beim Dienstleister (dessen Revision, dessen Datenschutzbeauf-

tragter, externe Auditierungen) zur Einhaltung des Datenschutzes und der Datensi-

cherheit, Prüfungsberichte

Kontrolle der Arbeitsergebnisse durch den Dienstleister

Kontrollen des Dienstleisters bei Subunternehmen

Datengeheimnis

Für die beim Auftragnehmer beschäftigten Personen gilt das Datengeheimnis gemäß § 5

BDSG, sofern sie bei der Erhebung, Verarbeitung bzw. Nutzung personenbezogener Daten in

einer der Phasen der Datenverarbeitung (Speicherung, Übermittlung, Veränderung, Löschung

oder Sperrung) oder bei der Nutzung tätig sind. Insbesondere die gesetzliche Verpflichtung

der sorgfältigen Auswahl des Auftragnehmers erfordert es, diesen Punkt sowie zusätzlich die

Regelung über die Wahrung von Geschäftsgeheimnissen im Vertrag zu regeln.

Datenschutzbeauftragter des Auftragnehmers

Um sich eines kompetenten Ansprechpartners für Datenschutzfragen im Unternehmen des

Auftragnehmers versichern zu können und hiermit ein Mittel zu haben, der Verantwortung als

”Herr der Daten” effektiv nachkommen zu können, sollte sich der Auftraggeber den Daten-

schutzbeauftragten des Auftragnehmers benennen lassen und sich das Recht über die Informa-

tion bei einem Wechsel des Datenschutzbeauftragten des Auftragnehmers zusichern lassen.

5.2.6 Kontrollen durch den Auftraggeber

Der Auftraggeber sollte sich zur Wahrnehmung seiner Kontrollpflichten vertraglich zusichern

lassen, welche Kontrollen er beim Auftragnehmer durchführen darf und mit welchem zeitli-

chen Vorlauf er solche Prüfungen anmelden muss. Außerdem sollte er sich – soweit erforder-

lich – vertraglich ein besonderes Einsichtsrecht beim Auftragnehmer durch eigene Mitarbeiter

(z.B. betrieblicher Datenschutzbeauftragter) oder beauftragte Dritte vorbehalten. Zu beachten

ist dabei, dass die Unterlassung der Prüfung vor Beginn der Verarbeitung bußgeldbewährt ist.

Zur Durchführung von Kontrollen kann sich der Auftraggeber auch Prüfberichte / Zertifikate

anderer Institutionen (z. B. durch Wirtschaftsprüfer / Aufsichtsbehörden / BSI) zu Eigen ma-

chen, soweit hierdurch sein Auftrag abgedeckt wird. Im Rahmen der Kontrolle sind Daten-

schutz- / Geheimhaltungsbedürfnisse des Auftragnehmers selbst und seiner anderen Kunden

zu beachten.



Zu den Regelungsaspekten nach § 11 Abs. 2 S. 1 Nr. 7 BDSG (Kontrollrechte des Auftragge-

bers und die entsprechenden Duldungs- und Mitwirkungspflichten des Auftragnehmers) gibt

das Bayerische Landesamt für Datenschutzaufsicht folgende Hinweise:

Erläuterungen:

Umfang der Kontrollrechte, mit bzw. ohne Vorankündigung

Insoweit vom Dienstleister einzuräumende Duldungs- und Mitwirkungspflichten

Kontrollen vor Ort beim Dienstleister und auch bei eventuellen Subunternehmen

Wer führt welche Kontrollen von Seiten des Auftraggebers durch (Fachbereiche, Revi-

sion, Datenschutzbeauftragter, externe Sachverständige) und wer wirkt beim Dienst-

leister mit (Ansprechpartner)

Einsichtsrechte des Auftraggebers in DV-Protokolle, in Berichte der Revision und des

Datenschutzbeauftragten des Dienstleisters, in externe Audits für den Dienstleister

Mitlesen am Kontrollbildschirm bei Fernwartung

Kontrolle des Opt-In bei Werbemaßnahmen

Zutrittsrechte in Privatwohnungen bei Telearbeit/Heimarbeit

usw.

5.2.7 Unterauftragnehmer

Für einzelne Tätigkeitsbereiche der Erhebung, Verarbeitung bzw. Nutzung kann es notwendig

sein, Unterauftragnehmer einzuschalten (z. B. für den Transport, die Vernichtung, die Erfas-

sung oder Archivierung von Daten, die Delegation von Arbeiten auf Ausweichrechenzentren

in Fällen von Überkapazitäten oder Zusammenbrüchen). Auch hier sind die gleichen Voraus-

setzungen zu beachten wie für das Vertragsverhältnis im Falle der Auftragsdatenverarbeitung.

Im Vertrag zwischen Auftraggeber und Auftragnehmer sind die Unterauftragsverhältnisse

festzulegen, die entsprechenden Unterauftragnehmer genau zu bezeichnen und ihre Verant-

wortlichkeiten gegenüber denen des Auftragnehmers abzugrenzen.

Daneben sollte geregelt werden, ob dem Auftragnehmer grundsätzlich das Recht zugespro-

chen werden soll, künftige Unterauftragsverhältnisse abzuschließen. Sollte dies bejaht wer-

den, ist ein Verfahren zu bestimmen, dass den Bestimmungen des § 11 BDSG gerecht wird

und der Beteiligung des Auftraggebers unterliegt. Dazu ist festzulegen, dass der Vertrag mit

dem Unterauftragnehmer nach entsprechender Zustimmung auch Vertragsinhalt des Vertrages

zwischen Auftraggeber und Auftragnehmer wird. Ein Beispiel zur Einbindung von Unterauf-

tragnehmern bietet der EU Standardvertrag Controller – Prozessor. Hiernach kann ein Unter-

auftragnehmer durch Zeichnung des Vertrags zwischen Auftraggeber und Auftragnehmer die-

sem beitreten.39

39 BESCHLUSS DER KOMMISSION vom 5. Februar 2010 über Standardvertragsklauseln für die

Übermittlung personenbezogener Daten an Auftragsverarbeiter in Drittländern nach der Richtlinie 95/46/EG

des Europäischen Parlaments und des Rates (Bekannt gegeben unter Aktenzeichen K(2010) 593) im

Amtsblatt der Europäischen Union L 39/5 vom 12.02.2010 (de) s. dort im Vertragsmuster Klausel 11 Abs. 1



Zu den Regelungsaspekten nach § 11 Abs. 2 S. 1 Nr. 6 BDSG (etwaige Berechtigung zur Be-

gründung von Unterauftragsverhältnissen) gibt das Bayerische Landesamt für Datenschutz-

aufsicht folgende Hinweise:

Erläuterungen:

Subunternehmerbeauftragungen unzulässig bzw. unter welchen Bedingungen und nach

vorheriger Genehmigung durch den Auftraggeber zulässig, Namhaftmachung der

Subunternehmer

Subunternehmer nur aus dem Inland, auch aus dem EU-/EWR-Raum oder auch aus

Drittstaaten

Subunternehmer für welche Zwecke, in welchem Fall, in welchem Umfang, auch Sub-

Subunternehmer

5.2.8 Mitzuteilende Verstöße des Auftragnehmers

Zu den Regelungsaspekten nach § 11 Abs. 2 S. 1 Nr. 8 BDSG (mitzuteilende Verstöße des

Auftragnehmers oder der bei ihm beschäftigten Personen gegen Vorschriften zum Schutz per-

sonenbezogener Daten oder gegen die im Auftrag getroffenen Festlegungen) gibt das Bayeri-

sche Landesamt für Datenschutzaufsicht folgende Hinweise:

Erläuterungen:

Unterrichtung des Auftraggebers wegen dessen Verpflichtung aus § 42a BDSG (Informa-

tionspflicht bei unrechtmäßiger Kenntniserlangung von Daten).

Beispiele:

Welche Art, welcher Grad von Verstößen ist mitzuteilen (Fehlversendungen, verloren-

gegangene Datenträger, unterschlagene Daten, Datenhacking, Zugangsberechti-

gungs-/Passwortoffenlegungen usw.)

Nicht nur Verstöße des Auftragnehmers und seiner Beschäftigten, sondern auch

rechtswidrige Handlungen von Dritten (Subunternehmer, Hacker, Einbrecher)

5.2.9 Rückgabe überlassener Datenträger

Zu den Regelungsaspekten nach § 11 Abs. 2 S. 1 Nr. 10 BDSG (Rückgabe überlassener Da-

tenträger und die Löschung beim Auftragnehmer gespeicherter Daten nach Beendigung des

Auftrags) gibt das Bayerische Landesamt für Datenschutzaufsicht folgende Hinweise:

Erläuterungen:

Was ist wann zurückzugeben und was ist wie zu löschen bzw. zu vernichten (elektroni-

sche Datenträger, Papierunterlagen)

Weitere Verwendung von elektronischen Datenträgern

usw.



5.2.10 Verarbeitung im Ausland

Bei einer Auftragsvergabe innerhalb der Europäischen Union (EU) / des Europäischen Wirt-

schaftsraums (EWR) wird hinsichtlich des Auftragnehmers keine Unterscheidung getroffen

zwischen einer Datenverarbeitung in Deutschland oder in einem Staat innerhalb der EU / des

EWR. Das heißt, hier sind die jeweiligen nationalen Regelungen des Auftraggebers für die

Beauftragung zu Grunde zu legen, also z. B. für einen deutschen Auftraggeber ein Auftrag

nach § 11 BDSG abzuschließen.

Bei der Vergabe in ein Drittland (also außerhalb der EU / des EWR) soll nach bisheriger Auf-

fassung, die bei der Novellierung des BDSG 2001 nicht neuerlich diskutiert wurde, immer der

Tatbestand der Datenübermittlung gegeben sein. Diese Auffassung wird jedoch weder durch

die EU-Datenschutzrichtlinie gefordert, noch durch nachfolgende Äußerungen der EU-

Kommission, z. B. durch Äußerungen in den FAQ zu Safe Harbor oder die Standardvertrags-

klauseln zur Auftragsdatenverarbeitung in Drittländern gestützt. Insofern ist auch eine Auf-

tragsdatenverarbeitung in Drittländern möglich (vgl. auch [Müthlein/Heck], S. 69 ff.; so auch

im Ergebnis die Aufsichtsbehörden für den Datenschutz, wenn auch mit einschränkenden

Anmerkungen, Beschluss der obersten Aufsichtsbehörden für den nicht-öffentlichen Bereich

am 19./20.4. 2007 in Hamburg, Hillenbrand-Beck in RDV 2007, S. 231 ff.).

Allerdings ist bei einer Auftragsvergabe an einen Dienstleister in einem Drittland neben einer

Vereinbarung nach § 11 BDSG unstreitig sicher zu stellen, dass sich durch die Verarbeitung

im Drittland das Datenschutzniveau für den Betroffenen nicht verschlechtert (s. § 4b, § 4c

BDSG).

Daher sind für eine entsprechende Auftragsvergabe u. a. folgende Punkte zu prüfen:

Es ist zu prüfen, ob eine positive oder negative Entscheidung der EU-Kommission in Be-

zug auf ein angemessenes Schutzniveau in diesem Drittland existiert. Dies gilt beispiels-

weise für die CH- Schweiz, CA- Kanada (Sonderfall Passenger Name Records = PNR-

Daten), AU- Australien (Sonderfall PNR-Daten) und AR- Argentinien. Weitere gelistete

Drittländer sind AD- Andorra, FO- Faeroe Islands, GG- Guernsey, IL- State of Israel, IM-

Isle of Man, JE- Jerseey, US- United States (Sonderfall PNR-Daten), NZ- New Zealand,

US- United States (Safe Harbor) und UY- Eastern Republic of Uruguay. Ggf. sind die

EU-Standard-Vertragsklauseln zugrunde zu legen.40

Durch individuelle Vertragsklauseln, genehmigt durch die Aufsichtsbehörde, können aus-

reichende Garantien festgelegt werden.

In § 4c BDSG sind Ausnahmen genannt, in denen Übertragungen in Drittländer auch dann

zulässig sind, wenn ein angemessenes Datenschutz-Niveau nicht gewährleistet ist. Bei-

spiele: Wenn der Betroffene eingewilligt hat oder ein Vertrag mit dem Betroffenen vor-

liegt. Der Hinweis auf die Zweckbindung ist auf jeden Fall zu geben.

In den USA können sich Unternehmen zur Beachtung der Safe-Harbor-Erklärung verpflich-

ten. Diese US-Firmen wollen durch Einhaltung dieser Vorschriften ein angemessenes Daten-

schutz-Niveau gewährleisten (www.export.gov/safeharbor). Dabei ist jedoch zu beachten,

dass durch den Beitritt des jeweiligen Auftragnehmers in den USA zum Safe Harbor-

40 BESCHLUSS DER KOMMISSION vom 5. Februar 2010 über Standardvertragsklauseln für die

Übermittlung personenbezogener Daten an Auftragsverarbeiter in Drittländern nach der Richtlinie

95/46/EG des Europäischen Parlaments und des Rates (Bekannt gegeben unter Aktenzeichen K(2010)

593) im Amtsblatt der Europäischen Union L 39/5 vom 12.02.2010 (de)



Abkommen die Frage des angemessenen Schutzniveaus geklärt ist. Dennoch besteht weiter-

hin die Verpflichtung zum Abschluss einer Vereinbarung nach § 11 BDSG. Auch wenn dies

in der Praxis von US-Auftragnehmern häufig bestritten wird, ergibt sich dies nicht zu Letzt

aus FAQ 10 zu Safe Harbor41:

„FAQ 10 – Datenverarbeitung im Auftrag (Artikel 17 der Datenschutzrichtlinie)

F: Wenn Daten aus der EU in den USA im Auftrag verarbeitet werden sollen, muss

dafür ein Vertrag geschlossen werden unabhängig davon, ob der Auftragsverar-

beiter der Vereinbarung zum sicheren Hafen beigetreten ist oder nicht?

A: Ja. Werden Daten lediglich zur Verarbeitung im Auftrag übermittelt, muss der in

Europa für die Verarbeitung Verantwortliche darüber stets einen Vertrag

schließen, gleich ob die Verarbeitung in oder außerhalb der EU stattfindet. Der

Vertrag soll die Interessen des für die Verarbeitung Verantwortlichen schützen,

also der natürlichen oder juristischen Person, die Mittel und Zweck der Verar-

beitung bestimmt und die gegenüber der (den) betroffenen Person(en) voll ver-

antwortlich bleibt. Im Vertrag wird festgehalten, welche Arbeiten genau auszu-

führen sind und mit welchen Vorkehrungen für die Sicherheit der Daten zu sor-

gen ist.

Eine amerikanische Organisation, die der Vereinbarung zum „sicheren Hafen“

beigetreten ist und personenbezogene Daten aus der EU zur Verarbeitung im

Auftrag übermittelt bekommt, braucht bei diesen Daten die Grundsätze nicht an-

zuwenden, denn die Verantwortung dafür gegenüber der betroffenen Person

liegt nach den geltenden EU-Rechtsvorschriften (die strenger sein können als

die Grundsätze des „sicheren Hafens“) weiterhin bei dem für die Verarbeitung

Verantwortlichen.

Da die dem „sicheren Hafen“ angehörenden Organisationen einen angemesse-

nen Schutz gewähren, ist bei reinen Verarbeitungsverträgen mit dem „sicheren

Hafen“ angehörenden Organisationen keine vorherige Genehmigung erforder-

lich (oder die Genehmigung wird von dem jeweiligen Mitgliedstaat automatisch

erteilt), wie sie bei Verträgen mit Empfängern, die sich nicht auf die Grundsätze

des sicheren Hafens verpflichtet haben bzw. nicht auf andere Weise einen ange-

messenen Schutz bieten, erforderlich wäre.“

Die Regelung in § 11 Abs. 2 BDSG besagt, dass der Auftraggeber sich auch bei einem Auf-

tragnehmer im Ausland von der Einhaltung der getroffenen technischen und organisatorischen

Maßnahmen zu überzeugen hat.

Aufgrund der Besonderheiten des BDSG sind bei Nutzung von Vertragsmustern zur Auf-

tragsdatenverarbeitung insbesondere hinsichtlich der Benennung des Datenschutzbeauftragten

des Auftragnehmers und der Verpflichtung auf das Datengeheimnis nach § 5 BDSG Anpas-

sungen erforderlich. Statt des Datenschutzbeauftragten sollte der Auftragnehmer einen von

ihm zu bestimmenden Datenschutzverantwortlichen benennen.

41 Amtsblatt der Europäischen Gemeinschaften L 215/7 (de) vom 25.08.2000 ENTSCHEIDUNG DER

KOMMISSION vom 26. Juli 2000 gemäß der Richtlinie 95/46/EG des Europäischen Parlaments und

des Rates über die Angemessenheit des von den Grundsätzen des „sicheren Hafens“ und der

diesbezüglichen „Häufig gestellten Fragen“ (FAQ) gewährleisteten Schutzes, vorgelegt vom

Handelsministerium der USA (Bekannt gegeben unter Aktenzeichen K(2000) 2441)



Die Verpflichtung nach § 5 BDSG kann durch eine vom BDSG losgelöste wortgleiche indivi-

duelle Verpflichtung der Mitarbeiter des Auftragnehmers ersetzt werden.

Als internationales Standardvertragsmuster für Auftragsverhältnisse außerhalb der EU/EWR

bietet sich die Verwendung des EU-Standardvertrags Controller-Processor42 an, der, wie eine

Aufstellung der Datenschutz-Aufsichtsbehörden zeigt43, auch die die erforderlichen Inhalte

einer Vereinbarung nach § 11 BDSG weitgehend abdeckt.

5.2.11 Wartung und Pflege

Per Definition sind gemäß § 11 Abs. 5 BDSG auf die Erbringung von Wartungsarbeiten oder

von vergleichbaren Unterstützungsdienstleitungen die Regelungen der Auftragsdatenverarbei-

tung im Sinne des Bundesdatenschutzgesetzes entsprechend anzuwenden, wenn dabei ein Zu-

griff auf personenbezogene Daten nicht ausgeschlossen werden kann.

Die Wartung und Pflege von Systemen kann beispielsweise folgende Tätigkeiten beinhalten:

Installation und Pflege von Netzwerken, Hardware und Software u.a. (Betriebssysteme,

Middleware, Anwendungen)

Parametrisieren von Software

Programmentwicklungen/-anpassungen/-umstellungen

Durchführung von Migrationen im Produktivsystem

Wartungsmaßnahmen können direkt vor Ort oder per Fernwartung durchgeführt werden.

Die Wartungsmaßnahmen beim Einsatz von SAP-Systemen können alle Ebenen des DV-

Einsatzes betreffen (z. B. Hardware, Betriebssystem- und Datenbankebene, Netzwerk). Dabei

können System- oder Anwendungsdaten betroffen sein, wobei personenbezogene Daten nur

bei letzteren von Bedeutung sind.

Dementsprechend ist für die Anwendung des BDSG bei Wartungstätigkeiten zu differenzie-

ren. Sie kommt regelmäßig nur dann in Betracht, wenn sich die Wartung auf Anwendungsda-

ten mit Personenbezug erstreckt.

In allen Fällen obliegt es dem Auftraggeber der Wartung selbst, die Tätigkeiten dem Einzel-

fall entsprechend freizugeben und zu kontrollieren.

Im Hinblick auf den Schutz personenbezogener Daten gegenüber unautorisierter Kenntnis-

nahme und/oder Weiterverwendung durch externe Systembetreuer/ Wartungspersonal sind

geeignete Sicherheitsmaßnahmen einzurichten:

Art und Umfang der Wartung sind schriftlich zu vereinbaren.

Das Wartungspersonal ist durch den Auftragnehmer schriftlich zur Verschwiegenheit zu

verpflichten (“Datengeheimnis”). Dieses gilt auch für Fernwartungsarbeiten (“Remote

Access”).

Personenbezogene Daten des Produktivsystems dürfen nicht auf andere Systeme herun-

tergeladen werden.

42 S.o.

43 http://www.lda.bayern.de/lda/datenschutzaufsicht/lda_daten/Abgleich_Standardvertragsklauseln-11.pdf

http://www.lda.bayern.de/lda/datenschutzaufsicht/lda_daten/Abgleich_Standardvertragsklauseln-11.pdf



Bei Fernwartungsmaßnahmen via Remote Access ist das Prinzip der geringsten Rechte-

vergabe zu beachten. Zugriffe auf produktive Rechnersystem und Anwendungen sind im

Einzelfall zu autorisieren.

Entsprechende systemseitige Protokollierungen der durchgeführten Wartungsmaßnahmen

an Programmen und Datenbeständen sind vom Systemadministrator unverzüglich und in

zeitlicher Nähe zur Durchführung der Wartung sachgerecht vorzunehmen.

Personenbezogene Daten sind vor direkten Zugriffen des Wartungspersonals zu schützen

(z.B. über separate Partitionen); soweit im Notfall Zugriffe auf personenbezogene Daten

notwendig werden, hat der Systemadministrator geeignete Maßnahmen zur Überwachung

des (Fern-)Wartungspersonals zu veranlassen, letztlich bis hin zur persönlichen Anwesen-

heit.

Im Rahmen regelmäßiger, systematischer Wartungszugriffe über Remote Access, die häufig –

wie im Fall SAP – dazu dienen, Systemumgebungen zu aktualisieren, sind von der Sys-

temadministration des Auftraggebers Zugriffsrechte nur auf besondere Anfrage des Auftrag-

nehmers zu erteilen.

Die SAP hat ihre Abläufe in der Wartung von externen Auditoren beurteilen und zertifizieren

lassen. Kunden der SAP können die aktuellen Zertifikate und zusätzliche Informationen auf

dem SAP Service Marketplace abrufen:www.service.sap.com/certificates-> Security Certifi-

cates -> Datenschutz Managementsystem.

5.3 SAP-Fakten

5.3.1 Ausgangssituation

Die Verlagerung von DV-Funktionen an Dritte (sog. Auftragsdatenverarbeitung i.S.d. § 11

BDSG) ist ein - auch und gerade beim Einsatz von SAP - häufig anzutreffender Sonderfall

des BDSG. Im Sinne des BDSG werden Auftraggeber und Auftragnehmer zusammen als ver-

antwortliche Stelle betrachtet. Dabei ist der Auftragnehmer gegenüber dem Auftraggeber im

Hinblick auf die Erhebung, Verarbeitung und Nutzung der Daten weisungsgebunden. Die

technisch organisatorischen Maßnahmen dagegen unterliegen der vertraglichen Regelung.

Umgekehrt hat der Auftragnehmer den Auftraggeber darauf aufmerksam zu machen, wenn

dessen Weisungen nicht mit den Anforderungen des BDSG im Einklang stehen.

Bei SAP ERP handelt es sich um ein mandantenfähiges System mit mandanten- und bu-

chungskreisübergreifenden Funktionen, mit dessen Hilfe sowohl komplexe Konzernstrukturen

als auch mehrere, voneinander unabhängige Unternehmen in einem SAP-System nebeneinan-

der abgebildet werden.

Soweit die Unternehmen voneinander unabhängig sind und keinerlei Konsolidierungsbedarf

besteht, empfiehlt sich die Nutzung getrennter Systeme bzw. zumindest unterschiedlicher

Mandanten. Im letzten Fall ist darauf zu achten, dass Mitarbeiter der Auftraggeber keine

mandantenübergreifenden Berechtigungen (z. B. keine mandantenunabhängige Tabellenzu-

griffe, keine Systemberechtigungen). Bei besonders sensiblen Daten ist eine solche Trennung

ggf. ebenfalls geboten.

Eine Trennung in Buchungskreise bietet sich im Konzernverbund an. Hier ist darauf zu ach-

ten, dass die Zugriffsrechte die gesellschaftsrechtlichen Abgrenzungen abbilden. Abweichun-

gen hiervon sind durch die beteiligten Gesellschaften selbst untereinander datenschutzkon-

form zu regeln und dem Auftragnehmer vorzugeben.



Eine weitere Trennung in Werke und/oder Personalbereiche ist datenschutzrechtlich nicht

zwingend vorgegeben. Sie resultiert eher aus unterschiedlichen Tarif- und Arbeitszeitregelun-

gen.

Im Hinblick auf die Vertraulichkeit von Personaldaten empfiehlt sich dann eine entsprechen-

de Einschränkung der Berechtigungen.

Da das BDSG keine speziellen Regelungen für Konzerne kennt, ist unter Datenschutzaspek-

ten auch innerhalb eines Mandanten das Augenmerk auf die sichere Datenverarbeitung je Bu-

chungskreis als kleinste bilanzierungsfähige bzw. rechtlich selbständige Einheit zu legen.

Der Umfang der an den Auftragnehmer übertragenen DV-Aufgaben wird naturgemäß je nach

Auftrag variieren. Beispielsweise kann der Auftraggeber zusätzlich zum Rechnerbetrieb (Be-

reitstellung von SAP-Systemen) die unternehmensspezifische Pflege der SAP-Anwendungen,

des Basissystems und der Betriebssystemkomponenten mehr oder weniger auf den Auftrag-

nehmer verlagern.

Aufgrund der Tatsache, dass Dienstleistungsrechenzentren i.d.R. für verschiedene Auftragge-

ber tätig sind, hat der Auftragnehmer hinsichtlich der realisierten Zugriffsschutzmechanismen

besondere Sorgfalt walten zu lassen, um personenbezogene Daten unterschiedlicher Anwen-

der zu trennen bzw. vertraulich zu behandeln.

5.3.2 SAP-Administration

Die Kontrolle der Berechtigungsadministration (Festlegung,. wer darf mit welchen Daten und

welchen Funktionen was machen) muss beim Auftraggeber bleiben.

Dagegen ist die Systemadministration Aufgabe des Auftragnehmers (Ausnahmen hiervon

sind beispielsweise bei der Nutzung eines Systems mit einem produktiven Mandanten mög-

lich). Allerdings ist der Zugriff auf personenbezogene Daten des Auftraggebers durch die

Administratoren im Rahmen des Auftrags restriktiv zu regeln.

SAP-spezifische Aufgaben, Zuständigkeiten und Verantwortlichkeiten (z.B. SAP-Benutzer-,

Berechtigungs-, Aktivierungsadministrator, SAP-Systemadministrator etc.) sollten daher in

einer Anlage zum Vertrag eindeutig festgelegt werden. Die Berechtigungsobjekte

„Benutzerstammpflege: Benutzergruppen“ (S_USER_GRP)

„Benutzerstammpflege: Berechtigungen“ (S_USER_AUTH)

„Benutzerstammpflege: Berechtigungsprofil“ (S_USER_PRO)

sind entsprechend den Vereinbarungen bei Auftragnehmer bzw. Auftraggeber einzurichten.

Analoges gilt für den Aufbau einer technischen sowie fachlichen Betreiberorganisation (wei-

tere Informationen zu Berechtigungsobjekten und -profilen s. Kap. 4).

5.3.3 SAP-spezifische Maßnahmen

Im Falle der Auftragsdatenverarbeitung kommt den technischen und organisatorischen Maß-

nahmen i.S.d. § 9 BDSG und deren SAP-spezifischen Ausprägungen (vgl. Kapitel 4 Umset-

zung der Anforderungen aus § 9 BDSG und Anlage: Technisch-organisatorische Maßnah-

men) besondere Bedeutung zu, da sie u.U. voneinander getrennte Zuständigkeitsbereiche be-

treffen.

Besonders hervorzuheben sind die nachfolgenden Punkte:



5.3.3.1 Systemadministration

Es ist sorgfältig zu prüfen, in welchem Umfang umfassende bzw. weitreichende Berechtigun-

gen bzw. Rollen an Benutzer des oder der Auftraggeber vergeben werden, da auf diese Weise

mandanten- und buchungskreisübergreifende Funktionen wahrgenommen werden können.

Beispielsweise können u.U. personenbezogene Daten des Buchungskreises "xxxx" Benutzern

des Buchungskreises "yyyy" zugänglich sein.

Auf der anderen Seite ist sorgfältig zu prüfen, inwiefern Administratoren des Auftragnehmers

Zugriffsrechte auf personenbezogene Daten des Auftraggebers erhalten.

Systemadministratoren sollen auf den produktiven Mandanten des Auftraggebers über keiner-

lei Berechtigungen verfügen (Ausnahme: Mandant 000 und ggf. 066). Für Notfälle ist ein

spezieller Notfalluser durch den Auftraggeber zu definieren und temporär freizuschalten.

5.3.3.2 Change and Transport Organizer (CTO/CTS)

Falls die SAP-Anwendungsentwicklung bzw. die Berechtigung zum Ändern von Entwick-

lungsobjekten auf den Auftragnehmer verlagert wird, ist bei diesem sicherzustellen, dass

Testdaten (häufig handelt es sich um Originaldaten des Produktivsystems für Integrations-

tests) nur den jeweiligen rechtlich selbständigen Einheiten (Buchungskreisen) als "Datenei-

gentümer" bzw. beauftragten Dritten zur Verfügung stehen.

Grundsätzlich dürfen zur Erhaltung der Sicherheit der Datenbestände, zum Schutz vor unbe-

rechtigter Kenntnisnahme von personenbezogenen Daten und zur Nachvollziehbarkeit der

Buchführung die Berechtigung zur Anwendungsentwicklung in einem produktiven SAP-

System nicht vergeben werden. Wenn Notfall-User mit diesen Berechtigungen existieren,

muss organisatorisch sichergestellt werden, dass alle Tätigkeiten dieser Benutzer inhaltlich

dokumentiert werden.

5.3.3.3 Fernwartung und Services

Wartungs- und Pflegeaktivitäten via Datenleitung erfolgen bei SAP-Systemen z. B über

SAP-EarlyWatch Check

Going-Live-Check

SAP Upgrade Assessment

Da auch bei einem Zugriff der SAP oder auch anderer Dienstleister im Rahmen von Service-

leistungen diese der Auftragsdatenverarbeitung gleichgestellt sind, sollten entsprechende Re-

gelungen über Art, Umfang und Zulässigkeit der Pflegemaßnahmen getroffen werden. Die

SAP stellt ihren Kunden hierzu auf Anforderung das Dokument „Security and Data Protection

at SAP“ zur Verfügung.

Der User Earlywatch ist der Dialogbenutzer für den SAP-EarlyWatch Check im Mandanten

066. Er wird nur für den Performance Monitor benötigt. I.d.R. wird dies lediglich auf Anfor-

derungen der entsprechenden Gesellschaft durchgeführt. Grundsätzlich sollte dieser Benutzer

nicht über das Profil SAP_ALL verfügen, da ansonsten u. a. auch die Pflege von mandanten-

übergreifenden Tabellen möglich ist. Somit sind auch hier aktivitätsbezogene Rollen zu er-

stellen.

Zum Schutz dieser Benutzer vor unberechtigtem Zugriff sind die Initial-Kennwörter zu än-

dern. Weiterhin sollten auch hier technische und organisatorische Maßnahmen ergriffen wer-



den, über die sichergestellt ist, dass ausschließlich Funktionen ausgeführt werden, die für die

Nutzung eines solchen Benutzers vorgesehen sind.

Zur Kontrolle der von der SAP durchgeführten Maßnahmen des Benutzers Earlywatch kann

bspw. das Security Audit Log genutzt werden. Weiterhin ist zu empfehlen, dass dieser Benut-

zer nur gemäß einem beschriebenen Verfahren temporär entsperrt wird.

5.3.3.4 RFC und ALE

Der Remote Function Call (RFC) dient der Kommunikation zwischen verteilten Programmen

in einer Netweaver basierten-Systemlandschaft. Mit Hilfe von RFC können Funktionsbaustei-

ne in einem fremden Netweaver basierten -System aufgerufen werden und die Ergebnisse an

das aufrufende Netweaver basierten -System zurückgegeben werden.

Die Technik von RFC bildet auch die Grundlage für weitere Netweaver basierte/spezifische

Schnittstellenmethoden wie Application Link Enabling (ALE) und Business Application Pro-

gramming Interface (BAPI).

Wenn externe Systeme angebunden werden oder eine Wartung/ Pflege über RFC erfolgt, sind

die ausgeführten Funktionalitäten, da es sich hier ggf. wiederum um Datenverarbeitung im

Auftrag durch fremde Dritte handelt, anforderungsgerecht zu definieren. Zusätzlich sind tech-

nische sowie organisatorische Maßnahmen zu ergreifen, über die sichergestellt wird, dass ein

dem BDSG entsprechendes Datenschutzniveau aufrechterhalten wird.

5.3.3.5 Job-Abwicklung

Zwischen Auftraggeber und Auftragnehmer sind die Verantwortlichkeiten bezüglich Job-

Auftrag, Job-Durchführung und Job-Überwachung klar schriftlich zu definieren (z.B. Perso-

nalabrechnungslauf, Mahnlauf). Diese Verfahrensanweisungen sollten sowohl den Fachabtei-

lungen des Auftraggebers als auch den EDV-Zuständigen des Auftragnehmers vorliegen.

Die im SAP-System generierten Job-Protokolle weisen nach, mit welchen Parametern ein Job

gelaufen ist. Sie sind daher entsprechend zu schützen. I.d.R. wird für die Aufbewahrung der

Job-Protokolle der Auftragnehmer zuständig sein.

Die handelsrechtlichen Aufbewahrungsfristen für die Job-Dokumentation betragen mindes-

tens 10 Jahre. Sie muss innerhalb dieses Zeitraums also auch für den DSB verfügbar sein.

Die vertrauliche Handhabung der für die jeweiligen rechtlich selbständigen Einheiten ausge-

druckten Listen, die personenbezogene Daten enthalten, ist sicherzustellen.

5.3.3.6 PC-Download

Die Übertragung von SAP-Daten aus der "gesicherten SAP-Umgebung" per PC-Download ist

seit 4.0 über das Berechtigungsobjekt „Berechtigung für GUI-Aktivitäten“ (S_GUI) zu schüt-

zen.

In Releases ab 3.0C kann über Download-Funktionsbausteine der Download unterbunden

bzw. protokolliert werden (siehe hierzu SAP-Hinweis 28777 „PC Download: Protokollierung,

Berechtigungsprüfung“).

Auf einem PC hat der Benutzer die Möglichkeit durch Bildschirmabgriff (Cut and Paste) Da-

ten von der Anzeige zu kopieren. Hierfür müssen beim Auftragnehmer geeignete organisato-

rische Rahmenbedingungen geschaffen werden, die verhindern, dass personenbezogene Daten

ohne Wissen des Auftraggebers beim Auftragnehmer anderweitig nutzbar gemacht werden.



5.3.3.7 Datenbank- und LAN-Umgebung

Seitens der SAP werden im SAP NetWeaver Security Guide grundsätzliche Empfehlungen

zur Installation in Bezug auf die Datenbank und das Netzwerk gegeben.

Bei einer Auftragsdatenverarbeitung ist zu prüfen, ob je Auftraggeber eigene Mandanten oder

Systeme eingesetzt werden sollen.

5.3.3.8 Mandantenübergreifende Funktionen

Beim Kopieren von Mandanten zwischen zwei Systemen, z.B. mit den Transaktionen SCC1

(über Transportauftrag), SCC9 (remote) bzw. SCCL (lokal), ist vom Auftragnehmer entspre-

chende Sorgfalt anzuwenden. Gegebenenfalls sind entsprechende Weisungen von dem oder

den Auftraggebern einzuholen.

Dieses gilt selbstverständlich auch für die Transaktion SCC5 Mandanten löschen

5.3.3.9 SAP-Protokolle

Unter Datenschutz- und Haftungsaspekten hat der Auftragnehmer archivierte SAP-Protokolle

als Nachweis für die Ausführung der Datenverarbeitung i.S.d. vertraglichen Vereinbarungen

und möglichen Nachkontrollen aufzubewahren. Die Auftragskontrolle kann Job-Protokolle,

Terminpläne, Sonderarbeitennachweise, Customizing-Aufträge, Transportaufträge etc. umfas-

sen.

Die Aufbewahrungsfristen könnten an die handels- und steuerrechtlichen Vorschriften ange-

lehnt werden.

Zu beachten ist, dass Protokolle zum Teil keine auftraggeberspezifische Auswertung erlau-

ben. Dies gilt insbesondere für Logdateien, sofern die Daten mehrerer Auftraggeber auf dem-

selben System, in demselben Mandanten, oder in denselben Organisationsstrukturen (Bu-

chungskreis, Werk/Personalbereich etc.) verarbeitet werden.

Zur eindeutigen Zuordnung bedarf es ggf. zusätzlich implementierter Filter für die Auswer-

tung der Protokolle, die im SAP-Standard nicht vorhanden sind. Ein solcher Filter kann z.B.

anhand der Benutzerkennungen des Auftraggebers erfolgen.

5.4 Risiken

Werden personenbezogenen Daten im Auftrag durch eine andere datenverarbeitende Stelle

verarbeitet oder genutzt, besteht die Gefahr, dass der Auftragnehmer der DV-Dienstleistung

datenschutzrechtliche Anforderungen oder vertragliche Vereinbarungen nicht hinreichend be-

achtet.

Letztlich ist jedoch die Unternehmensleitung des Auftraggebers gegenüber den Betroffenen

und den Aufsichtsbehörden verantwortlich.

Aufgrund dieses Sachverhalts resultiert die Verpflichtung des Auftraggebers, sich von der

sachgerechten Einhaltung der datenschutzrechtlichen und vertraglichen Vorgaben zu über-

zeugen.

Gleichzeitig ist der Auftragnehmer verpflichtet, unter Beachtung des Datenschutzes die sorg-

fältige Handhabung personenbezogener Daten verschiedener Auftraggeber (SAP-Anwender)

zu gewährleisten und die unautorisierte Übermittlung solcher Daten zu verhindern.



Der Auftragnehmer ist insofern für die angemessene organisatorische Einbindung der für die

Verarbeitung personenbezogener Daten eingesetzten SAP-Systeme in das eigene interne Kon-

trollsystem verantwortlich.

Im Rahmen der Auftragsdatenverarbeitung sind folgende in der Verantwortung des Auftrag-

gebers liegende Tatbestände bußgeldbewährt (§ 43 Abs. 1 Nr. 2b BDSG):

wer vorsätzlich oder fahrlässig …

entgegen § 11 Absatz 2 Satz 2 einen Auftrag nicht richtig, nicht vollständig oder nicht

in der vorgeschriebenen Weise erteilt oder

entgegen § 11 Absatz 2 Satz 4 sich nicht vor Beginn der Datenverarbeitung von der

Einhaltung der beim Auftragnehmer getroffenen technischen und organisatorischen

Maßnahmen überzeugt, …

Zertifizierungen können den Prüfaufwand sowohl auf Seiten des Auftraggebers wie des Auf-

tragnehmers erheblich, aber in der Regel nicht vollkommen auf Null, reduzieren. Der Auf-

traggeber hat nicht abstrakt den Status der IT-Sicherheit beim Auftragnehmer zu überprüfen

sondern die ordnungsmäßige Ausführung des – individuell – vereinbarten Auftrags. Daher

muss ein vom Auftragnehmer vorgelegtes „… Testat … die verantwortliche Stelle in den

Stand versetzen können, selbst zu beurteilen, ob der Auftrag ordnungsgemäß durchgeführt

wird.“44. Erst ein hierauf ausgerichteter Abgleich mit den Anforderungen des Auftrags kann

das Haftungsrisiko des Auftraggebers hinsichtlich seiner Kontrollpflicht reduzieren.

44 Bayerisches Landesamt für Datenschutzaufsicht, Tätigkeitsbericht 2009/2010, S. 36 ff



6 Besondere Themen

6.1 Datenschutzkonformes Löschen mit dem SAP NetWeaver Information Lifecycle Management (ILM)

Das SAP NetWeaver Information Lifecycle Management (ILM) ist die grundlegende Anwen-

dung für das datenschutzkonforme Löschen von personenbezogenen Daten in SAP-Systemen.

Mit Hilfe des ILM können anhand von Regeln die Daten identifiziert werden, die aus der

SAP-Datenbank gelöscht werden sollen.

Das SAP NetWeaver Information Lifecycle Management bietet die folgenden Funktionen:

Definition von Regeln für die Aufbewahrungsfristen der personenbezogenen Daten.

Einplanen automatischer Abläufe, um die Datensätze, die anhand der definierten Aufbe-

wahrungsregeln ermittelt wurden, zu. vernichten.

Sie müssen das SAP NetWeaver Information Lifecycle Management aktivieren, um die Ar-

chivierungs- und Datenvernichtungsfunktionen des SAP NetWeaver ILM nutzen zu können.

Damit steht Ihnen das in das ILM integrierte Information Retention Management (IRM), zur

Verfügung, das eine Erweiterung zur Archivadministration (Transaktion SARA) ist.

Mit dem Retention Management (Transaktion IRMPOL) legen Sie die Aufbewahrungsregeln

für die personenbezogenen Daten fest. Wenn Sie einen Datenvernichtungslauf für ein durch

ILM erweitertes Archivierungsobjekt starten, prüft das System für alle Datenobjekte des Ar-

chivierungsobjekts die vorhandenen Aufbewahrungsregeln und bestimmt so, ob die Aufbe-

wahrungsfrist der Geschäftsdaten abgelaufen ist.

Das Retention Management erfordert im Customizing grundlegende mandantenübergreifende

Einstellungen. Die ILM-Regelwerke, die Sie im IRM in Abhängigkeit von den geltenden ge-

setzlichen Aufbewahrungsfristen definieren, sind dagegen mandantenspezifisch (siehe hierzu

auch die Ausführungen im Abschnitt 6.1.1 dieses Leitfadens).

Zusätzlich können Sie je nach Archivierungsobjekt über Reportselektionen in der Archivad-

ministration (Transaktion SARA) bestimmen, für welche Daten des Archivierungsobjekts die

Regeln angewandt werden sollen (z.B. durch Angabe eines Selektionsdatums). Mit diesen

Einstellungen können Sie dann automatisch in regelmäßigen Abständen die Daten vernichten,

indem Sie entsprechende Jobs einplanen.

Für bestimmte Daten kann optional eine Archivierung durchgeführt werden. In diesem Fall

wird der weitere Lebenszyklus der Daten über das ILM verwaltet. Sollen Archivdaten ver-

nichtet werden, entspricht dies dem zweiten Schritt der direkten Datenvernichtung, es gibt al-

so keinen zweistufigen Prozess.

6.1.1 Datenschutzkonformes Löschen in der Personalwirtschaft (SAP

HCM)

In allen Anwendungen der Personalwirtschaft stehen Ihnen Archivierungsobjekte zur Verfü-

gung, mit denen Sie die personenbezogenen Anwendungsdaten nach Ablauf einer dafür fest-

gelegten Aufbewahrungsdauer vernichten können. Wir haben uns im HCM dafür entschieden



für das datenschutzkonforme Löschen den Begriff Vernichtung zu benutzen um Verwechs-

lungen mit dem Löschen in der Stammdatenpflege, bzw. dem Schritt Löschen in der Archi-

vierung zu vermeiden.

Eine Übersicht über die im SAP HCM verfügbaren Archivierungsobjekte finden Sie im SAP

Help Portal unter Archivierung und Datenvernichtung in der Personalwirtschaft und im Hin-

weis 1559133 Datenschutzkonformes Löschen personenbezogener Daten im HCM (ein-

schließlich der darin referenzierten Hinweise)

Prozess der Datenvernichtung

Die Datenvernichtung umfasst folgende Prozessschritte:

Vorlauf (optional)

Archivierungsobjekte, für die ein Vernichtungsbeleg oder eine Anlegesperre für den Ver-

nichtungszeitraum erforderlich ist, verfügen über ein Vorlaufprogramm. Dies ist bei-

spielsweise bei Archivierungsobjekten für die Vernichtung von abrechnungsrelevanten

Daten (z.B. Abwesenheiten) der Fall.

In der Vorlaufphase finden die vorbereitenden Schritte zur Datenvernichtung wie Durch-

führung der erforderlichen Prüfungen, Vorselektion der zu vernichtenden Datensätze und

das Anlegen von Vernichtungsbelegen statt.

In der Vorlaufphase werden nur zusätzliche Information in der Datenbank gespeichert.

Die Daten selber werden nicht verändert.

Nach dem Schritt Vorlauf ist aber eine Änderung der Daten nicht mehr möglich.

Schreiben

Wenn ein Vorlauf stattgefunden hat, übernimmt das Schreibprogramm die Selektion der

Daten über eine ID in Selektionsbild aus dem Vorlaufprogramm: Ansonsten erfolgt die

Selektion der Daten hier analog zum Vorlaufprogramm.

In beiden Fällen erstellt das System danach aus den selektierten Datensätzen eine tempo-

räre Archivdatei mit allen zu vernichtenden Datensätzen.

In der Schreibphase werden keine Änderungen auf der Datenbank vorgenommen.

Löschen

Das Löschprogramm liest die temporäre Archivdatei. Jeder Satz, der in der Archivdatei

enthalten ist, wird aus der Datenbank gelöscht. Am Ende wird zusätzlich noch die Ar-

chivdatei selber aus dem Filesystem gelöscht. Sofern ein Vernichtungsbeleg geschrieben

wurde, erhält dieser jetzt den Status Vernichtet.

Da der Prozess der Datenvernichtung irreversibel ist, erfolgt dieser im Standard in zwei

Schritten.

Bei Archivierungsobjekten mit Vorlaufprogramm erfolgt in einem ersten Schritt der Vor-

lauf. In einem zweiten Schritt starten Sie die Schreibphase, auf die automatisch die

Löschphase folgt.

Bei Archivierungsobjekten ohne Vorlaufprogramm erfolgt zunächst die Schreibphase und

anschließend die Löschphase. Das Löschprogramm muss immer manuell gestartet wer-

den.

Diese Gliederung in einen zweistufigen Prozess ermöglicht Ihnen eine zwischenzeitlich Prü-

fung der zu vernichtenden Daten und die Unterstützung eines 4-Augen Prinzips.



Das SAP HCM stellt Ihnen für die Datenvernichtung folgende zusätzliche Funktionen zur

Verfügung:

Vernichtungsbeleg

Für vernichtete personenbezogene Daten aus Infotypen der Personalwirtschaft können au-

tomatisch Vernichtungsbelege erzeugt werden. Vernichtungsbelege werden im Vorlauf-

programm eines Archivierungsobjekts geschrieben. Nach dem Vorlauf hat dieser Vernich-

tungsbeleg (Infotyp Archivierung/Datenvernichtung 0283) den Status Vorbereitet zur Da-

tenvernichtung. Nach dem Löschen erhält der Vernichtungsbeleg automatisch den Status

Vernichtet.

Vernichtungssperre

Auf Grund von nicht abgeschlossenen rechtlichen Vorgängen kann es sein, dass Daten für

einzelne Mitarbeiter länger aufbewahrt werden müssen, auch wenn deren Aufbewahrungs-

frist bereits abgelaufen ist und die Daten aus Datenschutzgründen vernichtet werden

müssten. Durch das Anlegen einer Vernichtungssperre (Infotyp Vernichtungssperre 3246)

können Sie sicherstellen, dass die für einen Rechtsfall relevanten Daten nicht vernichtet

werden können. Wenn der Rechtsfall entschieden ist, können die Daten wieder normal

vernichtet werden, sobald die Vernichtungssperre entfernt wurde.

Archivierungsteilobjekte

In einigen Archivierungsobjekten kann es kundenindividuell nötig sein die Datenobjekte

zu gruppieren. Dies erfolgt über die Archivierungsteilobjekte, dies können neue Gruppie-

rungen sein (z.B. bei Abwesenheiten), bzw. bestehende (Subtypen von Infotypen). Falls

hierzu ergänzenden Customizing nötig ist, erfolgt dies über den IMG.

Vernichtung von Abrechnungsdaten

Die Komponenten Personalzeitwirtschaft, Reisemanagement und Personalabrechnung

können integriert eingesetzt werden. Dabei fließen die Abrechnungsdaten aus dem Reise-

management und der Personalzeitwirtschaft in die Personalabrechnung ein. Um zu ge-

währleisten, dass keine Daten vernichtet werden, die noch für die Personalabrechnung be-

nötigt werden und um Dateninkonsistenzen zu vermeiden, müssen die Abhängigkeiten der

Datenobjekte der Archivierungsobjekte dieser drei Komponenten gemeinsam festgelegt

werden.

Mit Hilfe von Archivierungsgruppen können Archivierungsobjekte und Personalnummern

zusammengefasst werden, deren Abrechnungsdaten gemeinsam archiviert oder vernichtet

werden sollen. Die Transkation PU22 dient hierbei als gemeinsames Vorprogramm für al-

le drei Archivierungsobjekte.

Die eigentliche Vernichtung von Abrechnungsdaten erfolgt dann auch über Schreib- und

Löschprogramme individuell pro Archivierungsobjekt.

Zurücknehmen eines Vorlaufs zur Datenvernichtung

Wenn Sie nach erfolgter Vorlaufphase für ein Archivierungsobjekt (für Infotypen) fest-

stellen, dass eine Aufbewahrungsregel geändert werden soll oder bestimmte länderspezifi-

sche Daten oder die Daten einer oder mehrerer Personalnummern weiterhin aufbewahrt

werden sollen, können Sie diesen Vorlauf rückgängig machen. Mit dem Report Rücknah-

me Vorlauf zur Datenvernichtung (RP_PA_ROLLBACK) werden alle in der Vorlaufpha-

se für ein Archivierungsobjekt durchgeführte Änderungen zurückgenommen.

Die Lizenz zur Nutzung von SAP NetWaver ILM ist in Ihrer HCM bzw. E-Recruiting Lizenz

enthalten, solange sie das ILM nur zur Datenvernichtung einsetzen.



6.2 Read Access Logging

Um sensitive Daten zu schützen und den Verstoß gegen Sicherheitsrichtlinien zu erkennen hat

SAP mit dem SAP Netweaver Application Server (AS) ABAP 7.40 Read Access Logging

(RAL) eingeführt. Read Access Logging wird ebenfalls mit SAP Netweaver Application

Server (AS) ABAP 7.31 SP9 ausgeliefert.

Kunden können mittels Read Access Logging identifizieren und verfolgen wer zu welchem

Zeitpunkt Zugriff auf welche sensitiven Informationen hatte. Daten können von Kunden nach

ihren Richtlinien als sensitiv deklariert werden.

Beispiele für Fragestellungen, die durch Einsatz von Read Access Logging beantwortet wer-

den können sind unter anderem:

Wer hatte Zugang zu einer Geschäftseinheit, beispielsweise einem Bankkonto?

Wer hatte Zugang zu Adressdaten, zum Beispiel eines Geschäftspartners?

Wer hatte Zugang zu persönlichen Informationen, beispielsweise Religionszugehörigkeit

eines Mitarbeiters?

Technisch bedeutet dies, dass Remote APIs und Benutzerschnittstellen, die Zugriff auf solche

sensitiven Daten erlauben, protokolliert werden müssen.

RAL erlaubt zurzeit das Protokollieren folgender Kanäle:

NW 740 SP0: Web Services

NW 740 SP2: Remote Function Calls (sRFC, aRFC, tRFC, qRFC, bgFRC)

NW 740 SP2: Web Dynpro

NW 740 SP4: ABAP Dynpro

Mit der Transaktion SRALMANAGER startet man eine Web Dynpro Anwendung im Brow-

ser, die es erlaubt sowohl Verwaltungsfunktionen aufzurufen als auch erfasste Vorgänge ein-

zusehen. Um RAL nutzen zu können muss man zuerst Konfigurationen anlegen.

RAL Konfigurationen legen fest welche Form von Zugang unter welchen Bedingungen für

welchen Zweck aufgezeichnet werden muss.

Eine Konfiguration benötigt einen Verwendungszweck (Logging Purpose), der den Grund der

Aufzeichnung beschreibt. Dies könnte beispielsweise der Zugriff auf Gehaltsdaten von Vor-

ständen sein.

Des Weiteren wird es empfohlen Log-Domains zu verwenden, die die semantische Bedeutung

der aufgezeichneten Daten definieren. Log Domains erlauben es dem Kunden für semantisch

gleiche oder verbundene Felder eine einheitliche Beschreibung festzulegen. Zum Beispiel

können Finanzkontodaten in den verschiedenen anderen Schnittstellen in unterschiedlicher

Repräsentation, als Integer oder Text, etc., vorkommen. Diese Beschreibung erleichtert den

Auditoren das spätere Verständnis der Aufzeichnungen.

Um Informationen aufzuzeichnen die in einer Benutzerschnittstelle (UI) angezeigt werden,

muss man die gewünschten Felder in einer Aufnahme markieren. Dazu startet man einen Re-

corder über den Administration Tab im SRALMANAGER. Je nach UI Technologie wählt

man einen entsprechenden Aufnahmekanal, beispielsweise Web Dynpro, aus. Nach Eingabe

eines Namens und einer optionalen Beschreibung startet man die Aufnahme. Nun kann man

das aufzunehmende UI starten und über das Kontextmenü jedes gewünschte Feld zu der Auf-

nahme hinzufügen.



Nach dem Aufzeichnen kann man die Felder bei der eigentlichen Log Konfiguration auswäh-

len und den davor definierten Log Domains zuordnen.

Mit Hilfe des Verwendungszwecks, der Log Domain, sowie der Felderaufnahme, kann nun

eine Konfiguration angelegt werden, die den Lesezugriff, in dem zuvor ausgewählten Kanal

und der entsprechenden UI Technologie, spezifiziert.

Schlussendlich, wenn die Konfiguration abgeschlossen ist, kann das Read Access Logging

aktiviert werden.

Die gesamten Konfigurationsdateien können unter Zuhilfenahme des integrierten Transport

Managers (Transaktion SRAL_TRANS) in die verschiedenen, zu beobachtenden Systeme

transportiert werden. Dort können die Konfigurationen pro Mandant aktiviert oder deaktiviert

werden.

Es besteht die Möglichkeit spezielle Benutzer, zum Beispiel technische Benutzer, vom Proto-

kollieren auszunehmen.

Es besteht weiterhin die Möglichkeit Daten die mit Read Access Logging erfasst wurden mit-

tels des Information LifeCycle Management (ILM) zu archivieren oder zu löschen.

Die Log Ergebnisse können über die Monitorfunktionalität in der Transaktion SRALMANA-

GER von den Administratoren betrachtet werden. Es ist möglich Logeinträge nach Kanal,

Zeit, Benutzer und anderen Parametern zu durchsuchen. Eine detaillierte Beschreibung und

Best Practices können in folgendem SAP Insider Artikel zu Read Access Logging nachgele-

sen werden:

http://scn.sap.com/docs/DOC-44006.

6.3 Auditwerkzeuge: Audit Information System und Benutzerinformationssystem

6.3.1 Audit Information System (AIS)

Das AIS ist als Arbeitsmittel für die Auditierung des SAP-Systems konzipiert und richtet sich

vor allem an Systemauditoren, Revisoren und Wirtschaftsprüfer. Es wird im Standardumfang

des SAP ERP mitgeliefert und führt laut Dokumentation zu „einer Verbesserung der Prü-

fungsqualität und einer Rationalisierung des Prüfungsablaufes“. Das AIS beinhaltet eine

Sammlung, Strukturierung und Voreinstellung von Prüfungsfunktionen inklusive Dokumenta-

tion, Prüfungsauswertungen und Download von Prüfungsdaten. Es ermöglicht die Protokollie-

rung der Auditaktivitäten und unterstützt das Reporting über erstellte Auditprotokolle.

Grundsätzlich gliedert sich das AIS in die Bereiche kaufmännisches Audit und System Audit.

Das kaufmännische Audit beinhaltet neben organisatorischen Übersichten auch bilanzorien-

tierte und prozessorientierte Funktionen. Damit lassen sich zum Beispiel Informationen über

Kunden, Lieferanten, die Finanzbuchhaltung und Steuerbelange gewinnen.

Das System Audit des AIS ist in verschiedene Bereiche unterteilt: u. a. allgemeine Sys-

temprüfungen, Analyse der Benutzer und Berechtigungen sowie die Prüfung des Repository

und der Tabellen. Damit bietet es einem Auditor umfangreiche Funktionen zur Überprüfung

des Systemzustandes, wie z.B. von Systemparametern oder dem Transportwesen.

Für die Analyse eines SAP-Berechtigungskonzeptes kann unter anderem das "Infosystem Be-

nutzer & Berechtigungen" verwendet werden, mit dem z. B. verschiedene Auswertungen über

http://scn.sap.com/docs/DOC-44006



Benutzer, Rollen oder Änderungsbelege (Protokollierung der Benutzer-/Rollenverwaltung)

erstellt werden können.

Das AIS bietet aber auch dem Datenschutzbeauftragten Hilfestellungen bei seinen Aufgaben-

stellungen. Dieser kann das AIS insbesondere nutzen für

Datenschutzprüfungen (siehe Kapitel 2.1 und 4.3)

Auskunftsersuchen von Betroffenen (siehe Kapitel 3.1)

das Erstellen von Übersichten (siehe Kapitel 2.3).

Folgende Auswertungen bietet das AIS für die Erstellung der Übersichten gemäß § 4 BDSG

(Dateiregister) an:

Verwendungsnachweis von Domänen zu nicht leeren DB-Tabellen

Dateiregister für Mitarbeiterdaten

Dateiregister für Bewerberdaten

Dateiregister für Lieferantendaten

Dateiregister für Kundendaten

Dateiregister für Partnerdaten

Dateiregister für Sachbearbeiterdaten

Dateiregister für Verkäufergruppendaten

Dateiregister für Patientendaten

Dateiregister für R/3 Benutzer.

Ab dem SAP Basis Release 7.02 SP 14 wurde das AIS wieder auf themenbezogene Audi-

tstrukturen auf Basis von Bereichsmenus umgestellt, dass „AIS-Cockpit“ (Transaktion SAIS).

Damit können Sie die Auditstrukturen wieder direkt benutzen und individuell erweitern. Dies

erfolgt durch die Erstellung eines Bereichsmenus mit der SE43, die auch die Einbindung von

(externen) Dokumenten ermöglicht.

Die Protokollierung des Audits erfolgt zu jeder Prüfungsaktivität, dabei werden im Proto-

kollmodus der Applikation das Ausführungsdatum, der Durchführende, ein Prüfstatus sowie

einen Beschreibung der Prüfungshandlung (Textfeld) gespeichert. Diese Informationen lassen

sich später jederzeit wieder anzeigen und es besteht die Möglichkeit einen fortlaufenden

Kopftext je Auditstruktur zu pflegen.

Die von Ihnen definierten Auditstrukturen dienen dann als Vorlage für Rollen mit lokalen

Vorschlagswerten, dazu importieren Sie das Bereichsmenu in das Menu der Rolle und gene-

rieren die Berechtigungen aus den Vorschlagswerten. Zusätzlich können Sie über das Berech-

tigungsobjekt S_SAIS die Auditstrukturen und Prüfnummern abgrenzen.

Details zum „AIS-Cockpit“ finden Sie im Hinweis 1856125 (FAQ Optimale Nutzung des

Audit Information System), Details zur Auslieferung stehen im Hinweis 1763089. Das „AIS-

Cockpit“ befindet sich zurzeit noch in der Pilotauslieferung ohne SAP-Default-

Auditstrukturen, sobald diese verfügbar sind werden sie im Hinweis 1856125 referenziert.



Damit wurde die einhellige Forderung nach einer Menu Struktur in AIS von SAP wieder um-

gesetzt. Allerdings sind einige Anforderungen zur Verbesserung des AIS45 , die bereits im

September 2005 von Mitgliedern der AG Datenschutz formuliert wurden, weiterhin offen:

Die bisherige Funktion zum ‚Dateiregister’ muss dem Sprachgebrauch des BDSG ange-

passt und um weitere Domänen mit Personenbezug erweitert werden (z.B. EKGRP).

Es sollten Funktionalitäten zur Anzeige von Daten besonderer Art (SAP Standard und

kundeneigene Infotypen) für die Unterstützung einer Vorabkontrolle angeboten werden.

Der ‚Lebenszyklus von (personenbezogenen) Daten’ sollte angezeigt werden können, um

z.B. die Dauer der Speicherung zu bewerten oder einen Wegfall der Zweckbestimmung

beurteilen zu können.

Es sollte eine Reportingfunktion über die Verpflichtung auf das Datengeheimnis (Infotyp

Belehrungen) geben.

Diese Verbesserungsvorschläge beziehen sich neben dem Datenschutz auch auf die Funktio-

nalitäten zur Personalwirtschaft (HCM), auf die Analyse von Berechtigungskonzepten und

des Systemzustandes sowie auf die Protokollierungsmöglichkeiten im SAP ERP.

Eine Übersicht über die für den Datenschutzbeauftragten relevanten AIS-Standardrollen der

rollenbasierten Pflegeumgebung ab Release 4.6C findet sich am Anfang des Kapitels 2 (Auf-

gaben des Datenschutzbeauftragten). Hier werden auch Empfehlungen zur Rollenvergabe an

den DSB sowie weiterführende Literaturhinweise gegeben.

Weitere Informationen zum rollenbasierten AIS ab Release 4.6C entnehmen Sie bitte der Do-

kumentation des Audit Information System bzw. den SAP Hinweisen 754273 und 451960.

6.3.2 Benutzerinformationssystem (SUIM)

Das Benutzerinformationssystem (Transaktion SUIM) kann als Analyseinstrument für das

Berechtigungskonzept eines SAP ERP-Systems verwendet werden. Es hilft dem Auditor, ei-

nen Überblick über die Benutzerverwaltung zu erlangen, z.B. über

die Benutzer und ihre Zugriffsberechtigungen

die im System vorhandenen Rollen, Profile und Berechtigungen

die von SAP definierten Berechtigungsobjekte sowie

alle Änderungsbelege (Protokolle) zu Benutzern, Rollen, Profilen etc. 46

Mit dem Benutzerinformationssystem kann allerdings bisher nur das Berechtigungskonzept

der ‚klassischen ABAP-Welt’ analysiert werden. Die im Rahmen der Java-Umgebung verge-

benen Berechtigungen (z.B. für Portale) und die so genannten ‚strukturellen Berechtigungen’

können nicht mit dem Benutzerinformationssystem überprüft werden. In speziellen SAP Sys-

temen, wie z.B. SAP CRM für das Kundenbeziehungsmanagement, kommen ggf. weitere In-

45 I. Carlberg / G. Siebert / G. Voogd: Anforderungen an die Veränderung des Audit Info Systems (AIS):

SAP R/3 Enterprise, Version 4.7, WEB AS 6.20, Patch-Level 44; Stand: 26.9.2005

46 Zur Anwendung des Benutzerinformationssystems vergleiche die einschlägigen SAP-Hinweise sowie

Abschnitt 4.2.1.4.5 (Rollen mit kritischen Berechtigungen): „Abhängig von der Pflegequalität der

Rollen kann die SUIM irreführend sein.“



strumente für die Berechtigungsverwaltung hinzu (vgl. ‚Leitfaden Datenschutz für mySAP

CRM’, Abschnitt 2.5.2).

Es wäre wünschenswert, dass SAP derartige Funktionalitäten in das Benutzerinformationssys-

tem integriert und die bestehenden ‚Anwendungslücken’ dokumentiert.

6.4 SOS-Report ( Security Optimization Service )

SAP stellt remote und jetzt auch für den Kunden automatisiert und kostenfrei einen Service

zur Verfügung (ST14: Anwendungsanalyse, > Security Optimization), der die Sicherheitsein-

stellungen für den ABAP-Stack analysiert und eine Bewertung nach Risiken in Ampelform

vornimmt. Er ist ähnlich dem EWA-Dienst (Early Watch Alert) angelegt und gibt hohe, mitt-

lere und geringe Risiken (nach Definition der SAP) für einen sicheren Systembetrieb aus.

Der SOS-Report wird auf dem aktiven System erzeugt und dem in den Systemverbund einge-

bundenen Solution-Manager (SM)-System zur Aufbereitung und Sichtung sowie Bearbeitung

zur Verfügung gestellt (SM-Transaktion: Solution_Manager). Er kann auch periodisch vom

SM-System angefordert und bereitgestellt werden.

Der Report liefert nach dem bekannten Muster des SAP_Reports zu den kritischen Berechti-

gungen aus dem Benutzerinformationssystem eine Vielzahl von Auswertungen zu allen Ge-

bieten der üblichen Sicherheitseinstellungen z.B. zur System- und Mandanteneinstellung, zur

Benutzeradministration, zum Login, zum Security Audit Log und zu bestimmten HCM-

Berechtigungen.

SAP-Administratoren oder Benutzer mit hohen fachlich-spezialisierten Administrationsrech-

ten können in einem Fragefilter (Questionnaire) angegeben und so von der Listung und risi-

komäßiger Bewertung ausgenommen werden.

Der SOS-Report liefert einen guten Überblick zu den einzelnen Sicherheitseinstellungen des

ABAP-Stacks und ist gleichzeitig ein Maßstab für eine Zuständigkeits- und Arbeitsteilung bei

sicherheitskritischen Aufgaben und den damit verbunden benötigten sicherheitskritischen Be-

rechtigungen. Z.B. wird der betriebliche Umgang mit dem SAP_ALL Profil aufgezeigt und in

Frage gestellt. Die Problematik der wirklich benötigten und der tatsächlich vorhanden Berech-

tigungen wird sehr deutlich angesprochen.

Der Security Optimization Service liefert eine Orientierung über den Sicherheitsstatus des

SAP-Betriebes und sollte in jedem Falle ein Methode der Überprüfung sein, ob das sich aus

der betrieblichen Sicherheits- und Risikoanalyse ergebende Schutzniveau bezüglich der tech-

nischen Maßnahmen umgesetzt und eingehalten wird.

Der Dienst steht nur in englischer Sprache zur Verfügung. Weiteres kann im SAP-

Marketplace nachgelesen werden (http://service.sap.com/sos)

6.5 SAP GRC (Governance, Risk and Compliance)

Die SAP GRC Suite umfasst Lösungen zum Risikomanagement, zur Dokumentation des In-

ternen Kontrollsystems, zur Zugriffs- und Berechtigungssteuerung sowie für den globalen

Handel und den Umwelt-, Gesundheits- und Arbeitsschutz.

Mit diesen Anwendungen für Governance, Risk und Compliance können wichtige Vorschrif-

ten eingehalten, Governance-Aspekte berücksichtigt und Transparenz über die unterneh-

mensweiten Risiken hergestellt werden.

http://service.sap.com/sos



Technologische Grundlage für den Einsatz der GRC-Lösungen ist die Integrations- und Ap-

plikationsplattform SAP NetWeaver.

Im Sinne des vorliegenden Konzeptes, ist die SAP GRC Suite die umfassende Lösung, um

den Anforderungen des Datenschutzes wirksam, nachhaltig und vor allem effizient nachzu-

kommen.

Die GRC Suite besteht unter anderem aus:

SAP GRC Access Control, Zugriffs- und Berechtigungssteuerung,

SAP GRC Process Control, Lösung zur Dokumentation des internes Kontrollsystems

SAP GRC Risk Management, Risikoidentifikation und -analyse

Darüber hinaus sorgen weitere GRC-Lösungen für die Einhaltung von Bestimmungen in zahl-

reichen Branchen.

Die Anwendungen der SAP GRC Suite sind zusätzliche Software die im Standard nicht ver-

fügbar ist. Daher ist ihr Einsatz mit weiteren Lizenzkosten verbunden.

6.5.1 SAP GRC Access Control

Das SAP GRC Access Control dient der Zugriffs- und Berechtigungssteuerung in SAP-

Systemen, es besteht aus den folgenden Komponenten:

Access Risk Analysis, (ARA) zur Analyse von kritischen Berechtigungen und deren

Kombinationen in Rollen, Profilen und Benutzern

Business Role Management (BRM), für die zentralisierte Verwaltung von Berechtigungs-

rollen

Emergency Access Management (EAM), für temporären Zugriff mit erweiterten Berech-

tigungen

User Access Management (UAM), für ein automatisiertes Antragsverfahren über Work-

flow mit anschließender Zuordnung der Berechtigungen

Access Control besteht aus einem zentralen System, welches seit der Version 10.0 auf ABAP

basiert. Die an das Access Control angeschlossenen Systeme benötigen ein PlugIn, damit die

Analyse von Risiken, die Verwaltung von Rollen, der Notfallbenutzerzugriff und die Zuord-

Business Process Platform

SAP Solutions for GRC

Cross-Industry GRC

Access Control Process Control Trade

Global Trade EH&S

Risk Management

Industry-Specific GRC

Business Applications



nung von Berechtigungen aus dem Antragsverfahren aus dem zentralen Access Control Sys-

tem erfolgen kann.

6.5.1.1 Access Risk Analysis

Access Risk Analysis ermöglicht es kritische Transaktionen und Konflikte in Bezug auf die

Funktionstrennung innerhalb von Rollen oder Profilen aufzudecken. Ein Regelwerk mit Re-

geln für die Funktionstrennung in den ERP-Systemen von SAP, Oracle und PeopleSoft, JD

Edwards und Hyperion wird in Echtzeit mit den vorhandenen Berechtigungen verglichen.

Access Risk Analysis erkennt damit automatisch vorhandene und entstehende Risiken der

Zugriffskontrolle. Außerdem ist es möglich selbst Regeln zu definieren oder kritische Trans-

aktionen zu identifizieren.

In der Anwendung werden Reports zur Auswertung der Risiken nach Benutzern, Benutzer-

gruppen, Rollen, Profilen und kritischen Transaktionen bereitgestellt.

Mithilfe von Access Risk Analysis wird

bestimmt, ob eine Sammlung von Berechtigungen und Aktivitäten eines Benutzers, einer

Rolle oder eines Profils Risiken beinhaltet,

bestimmt, ob Risiken entstehen, indem einem Benutzer weitere Aktivitäten, Rollen oder

Profile zugeordnet werden (Simulation),

ein Alert generiert, falls eine kritische Transaktion ausgeführt wird.

Ein signifikanter Bestandteil des Datenschutzes ist die Kontrolle des Zugriffs auf Daten, in

Bezug auf SAP ERP die Nutzung bestimmbarer Transaktionen mit bestimmbaren Berechti-

gungen, im HR die Nutzung bestimmbarer Transaktionen mit bestimmbaren Infotypen und

Subtypen. Durch die präzise Definition des Zugriffsrisikos, werden die Risiken rollen- und

benutzerbezogen auswertbar. Fallweise kann man einstellen, dass Access Risk Analysis eine

Warnung ausgibt, sofern die kritischen Berechtigungen oder Kombinationen von Berechti-

gungen vergeben wurden.

6.5.1.2 Business Role Management

Business Role Management zentralisiert und standardisiert die Anlage und Verwaltung von

Rollen im Unternehmen. Führungskräfte können funktionsabhängige Rollen festlegen, wäh-

rend IT-Verantwortliche die entsprechenden technischen Berechtigungen definieren. Durch

eine flexible Prozessabbildung und eine automatisierte hierarchische Rollengenerierung ist es

einfach Rollen anzulegen und zu pflegen.

Die Anwendung reduziert damit die Gefahr von Fehlern und erleichtert die einheitliche Reali-

sierung bewährter Verfahren.

Business Role Management ist in den Profilgenerator integriert, daher können einmal defi-

nierte Rollen automatisch im SAP-System erzeugt werden.

6.5.1.3 Emergency Access Management

Emergency Access Management ermöglicht es Benutzern, außerhalb ihrer sonstigen Rollen in

einer kontrollierten und für die Revision transparenten Umgebung (Notfall-) Maßnahmen

durchzuführen. Dem Benutzer wird ein temporäres Benutzerprofil (Superuser-ID) zugeordnet.

Dieses bietet Zugriff auf z.B. kritische Transaktionen, oder sogar einen umfassenden System-



zugriff. Dabei beobachtet, überwacht und protokolliert die Anwendung jede Aktivität und

Verwendung der Superuser-ID. Die verantwortlichen Personen erhalten eine automatische

Meldung über den Einsatz der Superuser-ID und die entsprechenden Protokolldateien. Im Vo-

raus wird festgelegt, welche Benutzer einer Superuser-ID zugeordnet werden. Daher gibt es

keine Verzögerungen im Notfall.

6.5.1.4 User Access Management

User Access Management ermöglicht eine ordnungsgemäße Erteilung von Zugriffsrechten.

Dynamische Workflows automatisieren die Genehmigungsprozesse indem jede Anfrage an

die verantwortlichen Personen (z.B. per Email) weitergeleitet wird. Diese werden über bereits

vorhandene Berechtigungen des Antragstellers (und ggf. entstehende Risiken durch eine Er-

weiterung) informiert und können dann zustimmen oder ablehnen. Falls eine Zustimmung er-

teilt ist, wird die Rolle automatisch dem Benutzer zugeordnet.

Außerdem wird es den Benutzern mit User Access Management ermöglicht ihre Passwörter

selbstständig zurückzusetzen.

6.5.2 SAP GRC Process Control

Die Anwendung SAP GRC Process Control dient zur Dokumentation des internen Kontroll-

systems. Process Control unterstützt die Durchführung und Überwachung von Kontrollen in

Bezug auf Geschäftsprozesse und die unternehmensweite IT-Infrastruktur. Dabei wird die

Dokumentation, das Bewerten und Testen der Kontrollen sowie die Steuerung und Überwa-

chung der Behebung von Kontrollschwächen unterstützt.

So wird gewährleistet, dass Vorschriften zur Rechnungslegung wie z.B. der Sarbanes-Oxley

Act eingehalten werden.



Die Struktur des Unternehmens kann in einer Organisationshierarchie abgebildet werden.

Für das ganze Unternehmen werden Prozesse und Subprozesse definiert. Einem Pro-

zess/Subprozess können Kontrollen zugeordnet werden, die Risiken abdecken.

Die Kontrollen können regelmäßig über geplante Testläufe ausgewertet werden. Dabei unter-

scheidet man in Process Control zwischen automatischen, semi-automatischen und manuellen

Kontrollen. SAP liefert vordefinierte automatische Kontrollen mit Process Control aus, zu-

sätzlich haben Kunden die Möglichkeit mit Hilfe eines Rahmenwerks eigene automatische

Kontrollen zu konfigurieren. Diese automatischen Tests sind regelbasierte Prüfungen der

Kontrollwirksamkeit.

In der Applikation besteht zusätzlich die Möglichkeit eigene manuelle und semi-automatische

Kontrollen zu den Prozessen zu definieren. Dazu können z.B. Queries erstellt oder Reports

(SAP Standardreports und Kundenreports) eingeplant werden, die Process Control automa-

tisch auf dem ERP-System startet. Die Ergebnisse werden dann per Workflow an den zustän-

digen Benutzer zur Auswertung weitergeleitet.

Es ist möglich den Status der Process Control Stammdaten zu einem bestimmten Zeitpunkt zu

betrachten und Unterschiede zwischen verschiedenen Zeitpunkten zu erkennen.

Im Rahmen des Datenschutzes kann Process Control z.B. eingesetzt werden, um Datenverar-

beitungsprozesse zu definieren und zu dokumentieren. Außerdem kann die Bereitstellung von

detaillierten Anleitungen und genehmigten Vorlagen Mitarbeitern die manuellen Prüfungs-

aufgaben erleichtern.

Regelmäßige Kontrollen können sicherstellen, dass z.B.

die Mitarbeiter ihre persönlichen Daten bestätigen/korrigieren (Recht auf Berichtigung),

die Einhaltung der Löschfristen kontrolliert wird und Datenbankreorganisationen gestartet

werden,

die Auftragsdatenverarbeitung den rechtlichen und vertraglichen Vorgaben entsprechend

durchgeführt wird (Dokumentation/Kontrolle der Anforderungen) die seit der Novellie-

rung des BDSG (01.09.2009) bestehenden Kontrollpflichten des Auftraggebers bei der

Auftragsdatenverarbeitung können ebenfalls eingeplant und dokumentiert werden. Dies

gilt natürlich auch für die Auftragnehmer Seite

Falls bei den Kontrollen Unstimmigkeiten auftauchen oder sich Prozesse verändern, kann au-

tomatisch der Datenschutzbeauftragte (bzw. der zuständige Mitarbeiter) benachrichtigt wer-

den (Workflow).

6.6 SAP TDMS (Test Data Migration Server)

Der SAP Test Data Migration Server dient der Übernahme von relevanten Anwendungsdaten

aus dem SAP Produktivsystem in andere Systeme der Systemlandschaft, wie dem Entwick-

lungs-, Test-, Qualitätssicherungs- oder Schulungssystem. Dies ermöglicht nicht nur ein

schlankes, konsistentes nicht produktives System, sondern auch die Möglichkeit sensible Da-

ten vor der Datenmigration zu verschlüsseln. Dazu wird der mit dem TDMS bereitgestellte

Anonymisierungs-Content verwendet oder kundeneigene Scrambling-Regeln erstellt. Wäh-

rend der Nutzung des TDMS wird der Anwender über die Datenschutzproblematik informiert

und auf die Details des Daten-Scramblings hingewiesen. Sollte der Anwender die Daten ohne

Scrambling transferieren wollen, erhält er zusätzlich noch eine Warnung.



Bei der Übernahme von Daten wird nach Zeit, Organisationseinheit oder Geschäftsprozess

ausgewählt und festgelegt, ob alle vorhandenen Anwendungsdaten in einem Mandanten er-

setzt werden sollen, oder die Daten in einem bestehenden Mandanten um weitere Daten er-

gänzt werden. Das SAP TDMS bietet u.a. die folgenden Migrationslösungen:

Zeitbasiert werden alle mandantenabhängigen Anwendungsdaten innerhalb einer angege-

benen Zeitscheibe übernommen, dies kann zusätzlich auf Buchungskreise eingeschränkt

werden.

Übernahme der Stammdaten und des Customizings, aber keine Bewegungsdaten.

Ergänzung der geschäftsprozessspezifische Daten (z.B. Kundenaufträge) aus dem ERP-

Produktivmandanten

Übernahme von Daten für HCM, die anhand von Kriterien herausgefiltert wurden.

Kopiert Repository-Informationen und mandantenübergreifendes Customizing aus dem

Produktivsystem ohne Anwendungsdaten.

Verschlüsselung sensibler Daten in einem nicht produktiven System ohne systemübergrei-

fende Datenübernahme.

SAP TDMS ist für die folgenden Anwendungen verfügbar:

SAP ERP Central Component

SAP Business Warehouse

SAP Business Suite: SAP HCM, SAP CRM, SAP SCM und SAP SRM

SAP-Branchenlösungen: Utilities, Banking, Retail, Apparel and Footwear, Discrete Indus-

tries and Mill Products, Oil and Gas (Downstream) und Healthcare

Die Anwendungen von TDMS sind zusätzliche Softwarekomponenten, daher ist ihr Einsatz

mit weiteren Lizenzkosten verbunden. SAP TDMS ist ein wesentliche Bestandteil der Build-

und Testphase des SAP Application Lifecycle Management (ALM).

Die TDMS Lösung ist zertifiziert im EuroPriSe Verfahren: EuroPriSe ist eine von der EU ge-

förderte Initiative des ULD, die unter Beteiligung von acht weiteren europäischen Partnern

ein europäisches Datenschutz-Gütesiegel entwickelt hat. Das Vertrauens-Siegel wird von ei-

ner unabhängigen Stelle verliehen. Einem IT-Produkt oder einer IT-basierten Dienstleistung

wird bestätigt, dass es die strengen Vorgaben der europäischen Datenschutz-Richtlinien vor-

bildlich erfüllt. (https://www.european-privacy-seal.eu/about-europrise/fact-

sheet/EuroPriSe%20Fact%20Sheet-de-20100826.pdf)



7 Glossar


http://www.sap.info/de/glossary/A.html

http://www.sap.info/en/glossary/A.html


http://www.sap.info/de/glossary/A.html

http://www.sap.info/en/glossary/A.html

Documents

Leitfaden Datenschutz SAP ERP - DSAG · Leitfaden Datenschutz Stand Autor Seite für SAP-ERP 31.12.2013 AG Datenschutz 3 Einleitung Der vorliegende Leitfaden Datenschutz SAP ERP soll