Leitfaden Datenschutz SAP ERP 6.0

Transcription

Leitfaden Datenschutz SAP ERP 6.0
Deutschsprachige SAP ® Anwendergruppe
DSAG ARBEITSGRUPPE DATENSCHUTZ
STAND 30. MAI 2008
DSAG Arbeitskreis Revision / Risikomanagement
ERARBEITET IN DER ARBEITSGRUPPE DATENSCHUTZ
LEITFADEN DATENSCHUTZ SAP ERP 6.0
STAND 30. MAI 2008
Seite 2
DSAG e. V.
Deutschsprachige SAP-Anwendergruppe
Seite 3
IN MEMORIAM
THOMAS BARTHEL
(1950 – 2007)
Einleitung
Der vorliegende Leitfaden Datenschutz SAP ERP Release 6.0 soll Datenschutzbeauftragten der SAPAnwender 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 Datenschutzvorschriften verbleibt somit
bei der Leitung der verantwortlichen Stelle (Unternehmen / Behörde).
Für das Studium dieses Leitfadens werden Grundkenntnisse der SAP-Systeme sowie Kenntnisse der
handels- und steuerrechtlichen Grundlagen 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 modulspezifische 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 umfasst den ABAP-Stack, die Version für den JAVA-Stack ist in Planung.
SAP ERP ist als international eingesetzte Standardsoftware konzipiert. Der Leitfaden berücksichtigt die
EU-Richtlinie 95 / 46 / EG und die deutsche Datenschutzgesetzgebung.
Die Autoren sind Mitglieder der Arbeitsgruppe DATENSCHUTZ im DSAG Arbeitskreis Revision und stellen
hiermit ihre Erfahrungen zur Verfügung.
© COPYRIGHT 2008 DSAG E.V.
DIE AUTOREN:
Herr T. Barthel †
Herr I. Carlberg
Herr V. Lehnert
Herr H. Miller
Herr T. Müthlein
Seite 4
Frau A. Otto
Herr S. Pieper
Herr K. Redling
Herr A. Reschke
Herr P. Schiefer
Herr H.-J. Schwab
Herr G. Siebert
Herr G. Voogd
FORBIT GmbH / CArO GmbH, Hamburg
BIT e.V., Bochum
SAP Deutschland AG & Co.KG, Walldorf
Geberit Deutschland GmbH, Pfullendorf
DMC Datenschutz Management & Consulting
GmbH & Co.KG Frechen / GDD e.V. Bonn
Deloitte & Touche GmbH, Frankfurt
Rechtsanwaltskanzlei Reschke, Wiesbaden
Bayer AG, Leverkusen
SAP AG, Walldorf
Forba Partnerschaft, Berlin
FORBIT GmbH / CArO GmbH, Hamburg
Herr V. Ahrend
Herr R. Anhorn
Frau C. Bonni
Herr W. Kilian
Herr A. Lenz
Herr S. Dierschke
Herr W. Geesmann
Herr R. Glagow
Herr F. Glaß
Herr T. Glauch
Herr J. Heck
Herr G. Hohnhorst
Herr W. Hornberger
Herr A. Kirk
Herr K. Lorenz
Herr Dr. Pötschat
Herr E. Schmidt
Herr A. von der Stein
Herr U. Ueberschar
Frau G. Zibulski
Bosch Telecom GmbH, Frankfurt
Robert Bosch GmbH, Stuttgart
Lausitzer Braunkohle AG, Senftenberg
RWE Energie Aktiengesellschaft, Essen
Rheinbraun AG, Köln
BASF AG-Zok, Ludwigshafen
KPMG Deutsche Treuhand-Gesellschaft, Düsseldorf
PWC Deutsche Revision AG, Düsseldorf
PWC Deutsche Revision AG, Düsseldorf
Brau und Brunnen AG, Dortmund
SAP AG, Walldorf
Ruhrgas AG, Essen
Deutsche Bausparkasse Badenia AG, Karlsruhe
BASF AG, Ludwigshafen
Philip Morris GmbH, München
RWE Systems AG, Dortmund
Mannesmann Arcor AG & Co., Eschborn / Köln
SAP AG, Walldorf
LEITFADEN DATENSCHUTZ FÜR SAP ERP 6.0 STAND 30.05.2008, © DSAG e. V.
AN DER 1. / 2. AUFLAGE WIRKTEN AUSSERDEM MIT:
Die Verantwortung für den Inhalt tragen die Autoren. Die redaktionelle Bearbeitung und das Layout liegen
bei der SAP AG und der DSAG.
HINWEIS:
Die vorliegende Publikation ist urheberrechtlich geschützt (Copyright). Alle Rechte liegen, soweit nicht
ausdrücklich anders gekennzeichnet, bei:
DEUTSCHSPRACHIGE SAP® ANWENDERGRUPPE E.V.
Altrottstraße 34 a
69190 Walldorf
Deutschland
Jedwede unerlaubte Verwendung ist nicht gestattet. Dies gilt insbesondere für die Vervielfältigung,
Verbreitung, Übersetzung oder die Verwendung in elektronischen Systemen / digitalen Medien.
Die Autoren des LEITFADEN 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üfungserfahrungen.
Um dem Leser das Antworten zu erleichtern, ist auf der folgenden Seite ein Formular eingefügt.
Seite 5
1 Z. B. HGB, AO, GDPdU, GoB / GoBS
An die Autoren der
Arbeitsgruppe Datenschutz
DSAG-Geschäftsstelle
Altrottstr. 34a
69190 Walldorf
E-Mail: [email protected]
Fax: +49 (0) 62 27 – 358 09 59
ABSENDER
Name
Funktion
Abteilung
Firma
Anschrift
Telefon
Telefax
ERGÄNZENDE INFORMATION(EN) ZUM LEITFADEN DATENSCHUTZ SAP ERP
Ich möchte der Arbeitsgruppe zu folgendem Themenkreis Informationen geben (bitte ankreuzen):
(
(
(
(
)
)
)
)
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):
Seite 6
( ) Ja
( ) Nein
1.1 Anforderungen des BDSG an SAP ERP
1.1.1 Erhebung, Verarbeitung oder Nutzung von personenbezogenen Daten
1.1.2 Übermittlung von personenbezogenen Daten
1.1.3 Abrufverfahren
1.1.4 Besondere Zweckbindung
1.1.5 Auftragsverarbeitung
1.1.6 Unterrichtung des Betroffenen
1.1.7 Rechte des Betroffenen
1.1.8 Auskunft an jedermann
1.1.9 Meldepflicht
1.1.10 Verpflichtung der Mitarbeiter auf das Datengeheimnis
1.1.11 Schulung
1.1.12 Maßnahmen zur Datensicherheit
1.1.13 Übersichten gem. §§ 4e, 4g und §18 Abs. 2 (BDSG-Übersichten)
1.1.14 Vorabkontrolle
1.1.15 SAP Solution Manager als unterstützendes Tool im Einführungsprozess
1.2 Mitwirken des Datenschutzbeauftragten bei der Einführung von SAP ERP
1.2.1 Datenschutzbeauftragter – Mitglied des SAP-Projektteams
1.2.2 Information des Datenschutzbeauftragten zu den „Meilensteinen“
1.2.3 Informationsmöglichkeiten für den Datenschutzbeauftragten
1.3 SAP-Fakten
1.3.1 Customizing und ASAP-Vorgehensmodell
1.3.2 Berechtigungskonzept
1.3.3 Change Transport System / Change Transport Organizer (CTS / CTO)
1.3.4 Schnittstellenverarbeitung
1.3.4.1 Datenübernahme
1.3.4.2 PC-Verarbeitung
1.3.4.3 Kommunikationsschnittstellen
1.3.4.4 SAP-Automation
1.3.5 Job-Auftragsverfahren und -Dokumentation
1.4 Risiken
1.4.1 Nichteinschaltung des Datenschutzbeauftragten bzw. der Arbeitnehmervertreter
1.4.2 Nichtbeachtung der SAP-Empfehlungen
1.4.3 Nichtberücksichtigung bzw. verspätete Erstellung des Berechtigungskonzeptes
1.4.4 Nicht ordnungsgemäße Anwendung eines Datenverarbeitungsprogramms
1.5 Prüfungshandlungen im Rahmen der Einführung / Checkliste
2 AUFGABEN DES DATENSCHUTZBEAUFTRAGTEN
2.1 Überwachung der ordnungsgemäßen Programmanwendung (§ 4g Abs. 1 BDSG)
2.1.1 Einbeziehung des DSB vor und während der Programmentwicklung und -anpassung
2.1.2 Prüfung der Datenerhebung und Datennutzung auf Rechtmäßigkeit
2.1.3 Auswertung der Protokollierung
2.1.4 Prüfung der Verfahrensdokumentation
2.1.5 Mitwirkung bei der Festlegung und Überprüfung des Berechtigungskonzeptes
11
11
11
12
12
13
13
13
13
14
14
14
15
15
15
15
15
16
17
17
17
19
19
20
21
21
21
22
22
22
23
23
23
23
23
24
27
29
29
29
29
30
31
Seite 7
1 EINFÜHRUNGSPROZESS
Gliederung
Gliederung
2.1.6 Mitwirkung bei der Festlegung des Betriebskonzeptes und der Betreiberorganisation
2.1.7 Abfassung einer Datenschutzerklärung
2.1.8 Überwachung des Korrektur- und Transportwesens unter SAP ERP
2.1.9 Kontrollen im laufenden Betrieb
2.2 Schulung der Anwender mit Verpflichtung auf das Datengeheimnis (§§ 4g und 5 BDSG)
2.2.1 Personenkreis, der geschult und verpflichtet werden muss
2.2.2 Inhalt der Anwenderschulungen
2.2.3 Abbildung der Anwenderschulung im SAP
2.2.3.1 Anwenderschulung über Infotypen „Belehrungen“ oder „Qualifizierungen“
2.2.3.2 Anwenderschulung über das Veranstaltungsmanagement
2.3 Führen von Übersichten (§ 4g Abs. 2 / §18 Abs. 2 BDSG)
2.3.1 Informationen zur verantwortlichen Stelle
2.3.2 Zweckbestimmungen der Datenerhebung, -verarbeitung oder -nutzung
2.3.3 Beschreibung der betroffenen Personengruppen und der diesbezüglichen Daten
oder Datenkategorien
2.3.4 Empfänger oder Kategorien von Empfängern
2.3.5 Regelfristen für Löschung
2.3.6 Geplante Übermittlung in Drittstaaten
2.3.7 Maßnahmen zur Gewährleistung der Sicherheit
2.3.8 Zugriffsberechtigte Personen
2.3.9 Beispiel Melderegister
2.4 Systemunterstützung
2.4.1 Auswertungen zur Tabellen- und Feldanalyse
2.4.2 Techniken zum Auffinden personenbezogener Daten
2.4.3 Prüfung der Zugriffsberechtigungen
3 RECHTE DER BETROFFENEN UND VON JEDERMANN
Seite 8
3.1 Benachrichtigung und Auskunft
3.1.1 Rechtliche Anforderungen
3.1.2 SAP-Fakten
3.1.3 Anforderungen an die Organisation des Datenschutzes
3.2 Berichtigung, Löschung und Sperrung
3.2.1 Rechtliche Anforderungen
3.2.2 SAP-Fakten
3.2.3 Anforderungen an die Organisation des Datenschutzes
32
33
33
34
34
34
35
35
35
36
36
40
40
40
43
44
51
52
52
53
55
56
58
60
62
62
62
63
63
66
66
66
67
4 UMSETZUNG DER ANFORDERUNGEN AUS § 9 BDSG UND ANLAGE:
TECHNISCH-ORGANISATORISCHE MASSNAHMEN
68
4.1 Anforderungen
4.1.1 Gesetzliche Anforderungen aus § 9 BDSG
4.1.2 SAP-Funktionalität zur Abdeckung der gesetzlichen Anforderungen
4.2 SAP-Fakten, Risiken und Maßnahmen
4.2.1 ABAP-Fakten, Risiken und Maßnahmen
4.2.1.1 Identifizierung und Authentifizierung
4.2.1.1.1
SAP-Fakten
4.2.1.1.2
Risiken und zu ergreifende Maßnahmen
68
68
69
71
72
72
72
75
4.2.1.4
4.2.1.5
4.2.1.6
4.2.1.7
75
75
76
76
77
77
77
77
77
78
79
79
79
80
80
81
81
82
82
82
83
83
83
84
84
84
85
85
85
86
86
87
87
88
88
88
89
89
90
90
90
90
91
92
92
4.2.1.3
Standardbenutzer
4.2.1.2.1
SAP*
4.2.1.2.2
SAPCPIC
4.2.1.2.3
DDIC
4.2.1.2.4
EarlyWatch
4.2.1.2.5
Batch User
4.2.1.2.6
Benutzerberechtigungskonzept: ausgewählte Berechtigungsobjekte
4.2.1.3.1
Berechtigungsobjekte im HCM
4.2.1.3.2
Berechtigungsobjekt P_ABAP
4.2.1.3.3
Berechtigungsobjekt P_TCODE
4.2.1.3.4
Berechtigungsobjekt S_TCODE
4.2.1.3.5
Tabelle TSTCA
4.2.1.3.6
Umwandlung von Reports in Transaktionen
4.2.1.3.7
Berechtigungsobjekt S_TABU_DIS, S_TABU_CLI und S_TABU_LIN
4.2.1.3.8
Berechtigungsobjekt S_TOOLS_EX
4.2.1.3.9
Berechtigungsobjekt S_SCD0
4.2.1.3.10 Objekte zur Benutzer- und Berechtigungspflege (S_USER_xxx)
4.2.1.3.11 Berechtigungsobjekt S_GUI und XXL-Listviewer
4.2.1.3.12 Risiken und zu ergreifende Maßnahmen
Benutzerberechtigungskonzept: ausgewählte Profile
4.2.1.4.1
Profil SAP_ALL
4.2.1.4.2
Profil SAP_NEW
4.2.1.4.3
Profil P_BAS_ALL
4.2.1.4.4
Sonstige S_xxx-Profile
4.2.1.4.5
Rollen mit kritischen Berechtigungen
4.2.1.4.6
Besonderheiten bei der Berechtigungsprüfung
4.2.1.5.1
Ausschaltung / Modifikation von Berechtigungsprüfungen
4.2.1.5.2
Authority-Check bei ABAP-Programmen
(Standardprogramm oder Eigenentwicklungen)
4.2.1.5.3
Berechtigungshauptschalter HR (Tabelle T77S0; GRPID „AUTSW“)
4.2.1.5.4
Report Berechtigungsgruppen
4.2.1.5.5
Benutzeradministration
4.2.1.6.1
Konzeption der zentralen Benutzeradministration
4.2.1.6.2
Konzeption der dezentralen Benutzeradministration
4.2.1.6.3
Benutzeradministration mit dem Profilgenerator
4.2.1.6.4
Veraltete Benutzeradministration mit Profilen
4.2.1.6.5
Änderungen am Produktivsystem
4.2.1.7.1
Change and Transport System
4.2.1.7.2
Tabellenprotokollierung / Customizing
4.2.1.7.3
Systemänderbarkeit
4.2.1.7.4
Protokolle
Seite 9
4.2.1.2
Gliederung
4.2.1.7.5
Schutz der Tabelle T000
92
4.2.1.7.6
93
4.2.1.8 Systemschnittstellen
93
4.2.1.8.1
Batch-Input
93
4.2.1.8.2
RFC, ALE, BAPI
93
4.2.1.8.3
PC-Download
94
4.2.1.8.4
ABAP-Listviewer
94
4.2.1.8.5
94
4.2.1.9 Auditing und Logging
95
4.2.1.9.1
Security Audit Log
95
4.2.1.9.2
System Log
96
4.2.1.9.3
Transaktionsprotokollierung STAD (CCMS)
97
4.2.1.9.4
Workflow-Protokollierung
97
4.2.1.9.5
Report-Protokollierung im HCM
97
4.2.1.9.6
Ad-Hoc-Query-Protokollierung zur Kontrolle der Zweckbindung 97
4.2.1.9.7
98
4.2.1.10 Komplexe Suchhilfe
98
4.2.1.11 Zusammenfassung zentraler Risiken
99
4.3 Zusammenfassung der Prüfungshandlungen
100
5 AUFTRAGSDATENVERARBEITUNG UND KONZERNINTERNER
DATENAUSTAUSCH
Seite 10
5.1 Abgrenzungen beim Thema Outsourcing und Datenschutz
5.2 Vertragsgestaltung zwischen Auftragnehmer und Auftraggeber
5.2.1 Pflichten des Auftraggebers und Auftragnehmers
5.2.2 Umfang der Datenverarbeitung / Weisungen
5.2.3 Technische und organisatorische Maßnahmen
5.2.4 Wahrung der Rechte der Betroffenen
5.2.5 Datengeheimnis
5.2.6 Kontrollen durch den Auftraggeber
5.2.7 Datenschutzbeauftragter des Auftragnehmers
5.2.8 Unterauftragnehmer
5.2.9 Verarbeitung im Ausland
5.2.10 Wartung und Pflege
5.3 SAP-Fakten
5.3.1 Ausgangssituation
5.3.2 SAP-Administration
5.3.3 SAP-spezifische Maßnahmen
5.3.3.1 Systemadministration
5.3.3.2 Change and Transport Organizer (CTO / CTS)
5.3.3.3 Fernwartung und Services
5.3.3.4 RFC und ALE
5.3.3.5 Job-Abwicklung
5.3.3.6 PC-Download
5.3.3.7 Datenbank- und LAN-Umgebung
103
103
104
105
105
106
106
106
107
107
107
107
108
109
109
110
111
111
111
112
112
113
113
113
5.4 Risiken
6 BESONDERE THEMEN
6.1 Auditwerkzeuge: Audit Information System und Benutzerinformationssystem
6.1.1 Audit Information System (AIS)
6.1.2 Benutzerinformationssystem (SUIM)
6.2 SOS-Report (Security Optimization Service)
6.3 SAP GRC (Governance, Risk and Compliance)
6.3.1 SAP GRC Access Control
6.3.1.1 Risk Analysis and Remediation (vormals Compliance Calibrator)
6.3.1.2 Enterprise Role Management (bisher bekannt als Virsa Role Expert)
6.3.1.3 Superuser Privilege Management
(bisher bekannt als Virsa FireFighter for SAP)
6.3.1.4 Compliant User Provisioning (bisher bekannt als Virsa Access Enforcer)
6.3.2 SAP GRC Process Control
7 GLOSSAR
113
114
114
116
116
116
118
118
119
120
121
122
122
122
122
124
Mandantenübergreifende Funktionen
SAP-Protokolle
Seite 11
5.3.3.8
5.3.3.9
1 Einführungsprozess
Die Voraussetzung für die Anwendung des Bundesdatenschutzgesetzes (BDSG) ist beim Einsatz von SAP
ERP2 erfüllt, da in allen Modulen personenbezogene Daten automatisiert verarbeitet werden (vgl. §1 BDSG
in Verbindung mit §§12 oder 27 BDSG). Deshalb sind das Bundesdatenschutzgesetz und andere Rechtsvorschriften zum Datenschutz, z. B. in einer Landesverwaltung das jeweilige Landesdatenschutzgesetz, zu
beachten. Dieser Leitfaden gilt für den öffentlichen und den nicht öffentlichen Bereich. Auf die Besonderheiten der Landesdatenschutzgesetze wird in diesem Leitfaden nicht eingegangen.
Da SAP ERP als international eingesetzte Standardsoftware unter betriebswirtschaftlichen Aspekten
konzipiert ist, kann ein Anwender nicht ohne Weiteres davon ausgehen, dass für alle angebotenen Datenfelder die Rechtsgrundlagen im Sinne der deutschen Datenschutzvorschriften gegeben sind.
Es ergibt sich damit die Notwendigkeit zu überprüfen, ob SAP ERP in der beim Anwender vorgesehenen
Ausprägung den Anforderungen des Bundesdatenschutzgesetzes und ggf. anderer Vorschriften über den
Datenschutz genügt.
Der Datenschutzbeauftragte (DSB) 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 zu beachten.
1.1 ANFORDERUNGEN DES BDSG AN SAP ERP
Das BDSG spricht ein grundsätzliches Verbot der Erhebung, Verarbeitung und Nutzung personenbezogener
Daten aus und erlaubt die Datenverarbeitung nur, wenn die im BDSG definierten 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 Rechtsvorschriften angemessen berücksichtigt wurden. Entsprechendes gilt auch für Änderungen im laufenden Betrieb.
1.1.1 ERHEBUNG, VERARBEITUNG ODER NUTZUNG VON PERSONENBEZOGENEN
DATEN
Grundsätzlich ist die Erhebung, Verarbeitung oder Nutzung von personenbezogenen Daten gemäß § 4 BDSG
verboten, es sei denn,
> das BDSG erlaubt bzw. verlangt die Verarbeitung oder
> eine andere vorrangige Rechtsvorschrift erlaubt bzw. verlangt die Verarbeitung oder
> es liegt eine schriftliche Einwilligung des Betroffenen vor.
Die Zulässigkeitskriterien für die Erhebung, Verarbeitung oder Nutzung ergeben sich aus § 4 BDSG in
Verbindung mit §11 BDSG und
> §§13 und 14 BDSG für die öffentlichen Stellen
> §§ 28 bis 30 BDSG für nicht öffentliche Stellen.
Die Beweislast für die Zulässigkeit trägt die verantwortliche Stelle.
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 differenziert
gestaltet und müssen geprüft bzw. geschaffen werden (z. B. Einwilligung, Vertrag, Betriebsvereinbarung).
> Die organisatorischen und technischen Maßnahmen zur Nutzung von SAP ERP sind so zu gestalten,
dass NUR DIE ERFORDERLICHEN personenbezogenen Daten gespeichert werden. Dabei ist zu
Seite 12
2
Im Folgenden umfasst der Begriff SAP ERP im Sinne dieses Leitfadens auch die ABAP-Komponenten von SAP NetWeaver
>
>
>
1.1.2 ÜBERMITTLUNG VON PERSONENBEZOGENEN DATEN
Grundsätzlich ist die Übermittlung von personenbezogenen Daten verboten. Die Zulässigkeitskriterien für
Übermittlungen ergeben sich aus § 4b BDSG in Verbindung mit den §§15, 16, 28, 29, 30 BDSG. Es ist sicherzustellen, dass die Zweckbindung der übermittelten Daten auch vom Empfänger eingehalten wird. Hierzu
ist der Empfänger auf die Zweckbindung hinzuweisen.
Daraus ergibt sich die Notwendigkeit, alle REGELMÄSSIGEN oder ANLASSBEZOGENEN Übermittlungen
auf ihre Rechtmäßigkeit zu prüfen!
>
beachten, dass im Auslieferungszustand der Software technische Maßnahmen nur im geringen
Umfang ausgeprägt sind.
Abhängig vom Zweck der Verarbeitung ist mit den Möglichkeiten des Berechtigungskonzeptes und
anderer Sicherungsmaßnahmen sicherzustellen, dass die Daten nur IM RAHMEN DER ZULÄSSIGEN
ZWECKE verarbeitet werden können. Für unterschiedliche Zwecke erhobene Daten 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 erforderlich 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 erforderliche Zeit zu begrenzen,
entsprechend festzulegen und für die Löschung der Daten zu sorgen (z. B. von Bewerberdaten oder
Festlegung der Speicherungsdauer nach dem Vertragsende und anschließende Löschung).
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 Datensicherheit bei den beteiligten
Stellen erforderlich.
> Insbesondere muss die verantwortliche Stelle gewährleisten, dass mittels geeigneter Stichproben die
Rechtmäßigkeit der Übermittlung personenbezogener Daten festgestellt werden kann3.
1.1.4 BESONDERE ZWECKBINDUNG
Werden zu Zwecken des Datenschutzes, der Datensicherung oder zur Sicherstellung eines ordnungsgemäßen Betriebes personenbezogene Daten gespeichert (z. B. Logfile oder Accounting-Informationen), sieht das
BDSG in § 31 eine besondere Zweckbindung für diese Kontrollinformationen vor.
> Es ist zu klären, welche Aufzeichnungen im SAP ERP hierzu gehören und welche Funktionen / 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.
Der Regierungsentwurf vom September 2007 sieht in §§ 29 eine Verschärfung der Regelung zur
Stichprobenkontrolle vor
Seite 13
3
> Der Auftragnehmer ist sorgfältig auszuwählen.
> Dem Auftragnehmer sind vertragliche Auflagen zur Verwendung der Daten und zur Datensicherheit
zu machen.
> Der Auftraggeber muss sich von der Einhaltung der getroffenen Maßnahmen beim Auftragnehmer
überzeugen.
Die vorgenannten Ausführungen gelten auch für die Prüfung und Wartung automatisierter Verfahren oder
von Datenverarbeitungsanlagen (Wartung und Prüfung ist Auftragsverarbeitung!), wenn dabei ein Zugriff auf
personenbezogene Daten nicht ausgeschlossen werden kann.
1.1.6 UNTERRICHTUNG DES BETROFFENEN
Der Betroffene ist über den Umgang mit seinen personenbezogenen Daten zu unterrichten. Hierauf 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. durch Ankauf von
Adressen oder Übermittlung durch ein Konzernunternehmen, ist er unter den Voraussetzungen des § 33
BDSG zu benachrichtigen, wenn
> 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 richtige personenbezogene Daten gespeichert werden. Entscheidungen, die für
den Betroffenen eine rechtliche Folge nach sich ziehen oder ihn erheblich beeinträchtigen, dürfen nicht
ausschließlich auf der Basis einer automatisierten Verarbeitung getroffen werden4.
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, 34, 35 BDSG sind zu beachten.
> Die verantwortliche Stelle muss in der Lage sein, zur Auskunftserteilung alle personenbezogenen
Daten des Betroffenen zuverlässig zu ermitteln! Diese Anforderung korrespondiert mit der
Anforderung zur Führung einer Übersicht gemäß § 4g Abs. 2 BDSG (Verfahrensverzeichnis).
> Eine automatisierte Einzelfallentscheidung ist gem. § 6a BDSG nur in bestimmten Ausnahmefällen
zulässig. Werden diese Ausnahmefälle in Anspruch genommen, sind sie entsprechend zu
dokumentieren5.
Die Voraussetzungen, unter denen Sperrungen erforderlich werden, sind zu definieren. Die Verwendung
gesperrter Daten ist zu regeln.
1.1.8 AUSKUNFT AN JEDERMANN
Seite 14
Gemäß § 4g Abs. 2 Satz 2 BDSG hat der Datenschutzbeauftragte jedermann auf Antrag Einsicht in das
4
5
Der Regierungsentwurf vom September 2007 sieht in § 6a eine Ausweitung der Regelung vor
Der Regierungsentwurf vom September 2007 sieht zusätzliche Anforderungen in § 28 für alle
Scoring-Verfahren vor
1.1.9 MELDEPFLICHT
Unter den Voraussetzungen des § 4d BDSG sind automatisierte Verarbeitungen vor ihrer Inbetriebnahme 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äß § 4d 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 oder Nutzung der Zweckbestimmung eines Vertragsverhältnisses oder vertragsähnlichen Vertrauensverhältnisses mit dem Betroffenen dient.
1.1.10 VERPFLICHTUNG DER MITARBEITER AUF DAS DATENGEHEIMNIS
Das BDSG fordert, dass alle Personen, die mit personenbezogenen Daten umgehen, 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 hinzugezogen
werden, ihre Mitarbeiter auf das Datengeheimnis verpflichtet haben.
Verfahrensverzeichnis zu gewähren. Ist kein Datenschutzbeauftragter bestellt, dann hat die Geschäftsleitung dies sicherzustellen.
1.1.11 SCHULUNG
Der Datenschutzbeauftragte hat die Mitarbeiter gemäß § 4g Abs. 1 Nr. 2 BDSG mit dem BDSG sowie anderen
Vorschriften über den Datenschutz und über innerbetriebliche Regelungen, die sich aus dem Gesetz
ergeben, vertraut zu machen.
> Der Datenschutzbeauftragte hat die Projektmitglieder und Anwender, die an der Einführung von SAP
ERP beteiligt sind, mit den Anforderungen des BDSG vertraut zu machen.
> Die durchgeführten Schulungen sind zu dokumentieren.
1.1.12 MASSNAHMEN ZUR DATENSICHERHEIT
Personenbezogene Daten dürfen nur erhoben, verarbeitet oder genutzt werden, wenn angemessene 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 zu treffen und mit dem Datenschutzbeauftragten
abzustimmen.
> Gegebenenfalls kann zur Verbesserung des Datenschutzes und der Datensicherheit das INSTALLIERTE
System einem IT-Sicherheitsaudit unterworfen werden6.
1.1.13 ÜBERSICHTEN GEM. §§ 4E, 4G UND §18 ABS. 2 (BDSG-ÜBERSICHTEN)
Die ÖFFENTLICHEN STELLEN entsprechend zweitem Abschnitt BDSG führen gemäß §18 BDSG Abs. 2
ein Verzeichnis der eingesetzten DATENVERARBEITUNGSANLAGEN und haben die Angaben gemäß § 4e
Der Regierungsentwurf vom September 2007 sieht ein Audit-Gesetz vor, das durch VO konkretisiert werden
muss. Hierin ist z. Zt. explizit der Bezug zur IT-Sicherheit ausgeschlossen
Seite 15
6
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.14 VORABKONTROLLE
Unabhängig von der Verpflichtung der verantwortlichen Stelle, den Datenschutzbeauftragten bei der Verfahrenseinführung / -änderung zu beteiligen, sind Verfahren automatisierter Verarbeitung mit besonderen
Risiken für die Rechte und Freiheiten der Betroffenen, insbesondere die Verarbeitung besonderer Daten
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. Eine schriftliche Dokumentation zur
Vorabkontrolle ist zu empfehlen.
1.1.15 SAP SOLUTION MANAGER ALS UNTERSTÜTZENDES TOOL IM
EINFÜHRUNGSPROZESS
Der SAP Solution Manager ist die Service- und Supportplattform der SAP, die bei der Einführung und
Implementierung von SAP-Projekten eine durchgängige Unterstützung bietet. Sofern der Solution Manager
genutzt wird, sollte der Datenschutzverantwortliche auf die darin befindlichen Dokumente zur Beurteilung
des Systems zurückgreifen7.
Alle Systeme
Alle Geschäftsprozesse
Alle Schulungsinformationen
Sämtliche Testinformationen
Die gesamte
Dokumentation
SAP
SOLUTION
MANAGER
Alle Informationen
zu Serviceplanung,
Auslieferung und
Follow-up
Sämtliche Änderungsinformationen
Alle Service-LevelInformationen
Seite 16
7
M. Schäfer, M. Melich: SAP Solution Manager . Galileo Press, Bonn 2006
Sämtliche Testinformationen
Alle Kundenentwicklungen und
funktionalen
Erweiterungen
Sämtliche
Informationen
zu Vorfällen und
Problemen
Sämtliche Überwachungsdaten
Das BDSG verlangt in § 4g Abs. 1 Nr. 1 BDSG die rechtzeitige Einschaltung des Datenschutzbeauftragten bei
Vorhaben der automatisierten Verarbeitung personenbezogener Daten. Hierzu gehören auch die Einführung
und der Releasewechsel von SAP ERP.
> Wird SAP ERP in einem Unternehmen eingeführt, ist der Datenschutzbeauftragte frühzeitig zu beteiligen.
> Der Datenschutzbeauftragte hat dabei zu überprüfen, ob das Customizing und die Implementierung des
SAP ERP den Anforderungen des BDSG genügt.
> 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.
> Bei einem Releasewechsel hat sich der Datenschutzbeauftragte auch von der datenschutzkonformen
Durchführung des Wechsels zu überzeugen.
1.2.1 DATENSCHUTZBEAUFTRAGTER − MITGLIED DES SAP-PROJEKTTEAMS
Die sachgerechte Beratung der Projektleitung und -mitarbeiter und die Überprüfung der ordnungsgemäßen
Anwendung (Customizing) durch den Datenschutzbeauftragten, die im § 4g Abs. 1 Nr. 1 BDSG vorgesehen
ist, können effektiv erreicht werden, wenn er Projektmitglied ist. Wird SAP ERP in einem Unternehmen
eingeführt, ist der Datenschutzbeauftragte daher vom Projektbeginn an zu beteiligen.
1.2 MITWIRKEN DES DATENSCHUTZBEAUFTRAGTEN BEI DER
EINFÜHRUNG VON SAP ERP
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 Zielsetzungen 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 Festlegungen 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 Datenschutzbeauftragtem abstimmen
1.2.3 INFORMATIONSMÖGLICHKEITEN FÜR DEN DATENSCHUTZBEAUFTRAGTEN
Seite 17
Der Datenschutzbeauftragte sollte 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
> 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 Standardtools 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 SAP-Prüfleitfaden Revision (z. Zt. Release 3.0D vom 20.02.97): http://www.sap.de/revis
> Die SAP Sicherheitsleitfäden werden von SAP zur Verfügung gestellt. Bitte beachten Sie den SAPHinweis 39267 ‚Verfügbarkeit des SAP Sicherheitsleitfadens’
> Die SAP-Hilfe (Dokumentations-CD) (http://www.sap.com/germany/aboutSAP/shop/)
> 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 Information System“
beschrieben. Es hat z. Zt. im System-Auditteil und Datenschutzteil einen Stand, der R/3 4.6c
entspricht.
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’
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. Aufgrund der
komplexen Tabellenstrukturen von SAP ERP stellt SAP systemseitig ein Vorgehensmodell und Einführungsleitfäden (Grundstrukturen zur Einführung) zur Verfügung. Diese sind auch Bestandteil der
SAP-Online-Dokumentation.
Seite 18
> Das ASAP-Vorgehensmodell bildet zum einen den methodischen Rahmen für den Einführungsund Releasewechselprozess, zum anderen ist es ein operatives Werkzeug zur Unterstützung in
jeder Phase der Einführung.
> Die Projektleitfäden für das SAP ERP Customizing als unternehmensspezifische Untermenge des
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
> Stammdaten festlegen
> Berichtswesen festlegen
> Informationsfluss personenbezogener Daten bei Anwendungsschnittstellen, insbesondere zu
anderen Programmen, untersuchen
> Informationsfluss der vorgesehenen Berichte und Auswertungen auf Datenschutzgesichtspunkte 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
Vorgehensmodells listen alle Aktivitäten für die Einführung des SAP-Systems auf und unterstützen
die Steuerung und Dokumentation der Einführung.
Das SAP-Standard-Vorgehensmodell und allgemeine Hinweise hierzu finden Sie auf der Dokumentations-CD oder dem SAP Marketplace; http://service.sap.com.
Empfehlungen zu Beteiligungsthemen des Datenschutzbeauftragten entlang des ASAP-Vorgehensmodells stehen in Anlage 3.
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 System über den
Menüpfad zu finden:
Werkzeuge → Customizing → IMG → Projektbearbeitung (SPRO); Schaltfläche ‚SAP-Referenz-IMG’
Seite 19
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 Schaltflä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 Datenschutzgesichtspunkten 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, Kenntnisnahme,
Übermittlung und Nutzung, dem Schutz der Daten vor unberechtigter, auch versehentlicher
Änderung oder Löschung
> der Gewährleistung des zweckgebundenen Gebrauchs der Daten
> der Nachvollziehbarkeit und Zweckgebundenheit des Zugriffs auf personenbezogene Daten
SAP liefert einen Set von Standardrollen aus, die der Kunde als Vorlage benutzen und hinsichtlich der
Zuständigkeiten und organisatorischen Ausprägungen an seine individuellen Bedürfnisse anpassen
kann. Der Umfang dieser Rollen ist aus Funktionssicht definiert, die Rollen sind zwingend auf die
Sicherheitsbedürfnisse (Funktionstrennung, kritische Berechtigungen) der Organisation anzupassen.
Mit jeder Vorlage erhält man ein individuelles Benutzermenü. 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, einfach 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 wesentlicher Bestandteil des
Zugriffsschutzes anzusehen. Es muss daher organisatorisch definiert, revisionsfähig gestaltet sowie
ausreichend getestet und spätestens zum Produktionsbeginn verfügbar sein.
Seite 20
Schließlich muss darauf geachtet werden, dass Rollen und ggf. auch Aktivitätsgruppen, Berechtigungen
und Profile im Testsystem neu angelegt, geändert oder gelöscht werden und anschließend mittels CTS /
CTO (Change Transport System / Change Transport Organizer) über das Qualitätssicherungssystem in
die Produktionsumgebung übernommen werden.
SAP empfiehlt, in einem produktiven System grundsätzlich keine Änderungen vorzunehmen bzw. zuzulassen. Alle Änderungen sind daher aus der Test- oder Qualitätssicherungsumgebung mit dem sog.
Korrektur- und Transportwesen8 in das produktive System zu übernehmen. Das gesicherte Korrekturund Transportwesen ist somit wesentlicher Bestandteil eines sicheren und ordnungsgemäßen SAP
ERP-Systems.
Unter Datenschutzaspekten stehen dabei folgende Zielsetzungen im Vordergrund:
> die Registrierung und Dokumentation einschließlich der geordneten Übergabe der Systementwicklungsumgebungsobjekte (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ültigkeit
besitzen, ist zwingend erforderlich, dass mindestens zwei physisch getrennte SAP ERP-Systeme
implementiert werden müssen (Test- und Produktivsystem), wenn personenbezogene Daten aus der
Produktivumgebung (z. B. für Massentests) in der Testumgebung verwendet werden, sind diese dort
nach Möglichkeit entweder zu anonymisieren oder zu pseudonymisieren. 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 Testumgebung 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 Daten enthalten.
1.3.3 CHANGE TRANSPORT SYSTEM / CHANGE TRANSPORT ORGANIZER (CTS / CTO)
1.3.4 SCHNITTSTELLENVERARBEITUNG
1.3.4.1 DATENÜBERNAHME
8 M. Schäfer, M. Melich: SAP Solution Manager, Galileo Press, Bonn 2006
9 siehe hierzu ergänzende Hinweise in Kapitel 6 Prüfleitfaden Revision
10 siehe hierzu ergänzende Hinweise in den SAP-Sicherheitsleitfäden
Seite 21
SAP bietet die LSMW (Legacy System Migration Workbench) als Datenübernahmeverfahren. Dieses Tool
ist speziell für die Altdatenübernahme konzipiert worden und bedient sich der BAPI- oder Batch-InputSchnittstelle (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 Datenkonsistenz) durch geeignete
organisatorische Maßnahmen sicherzustellen, um möglichen Manipulationen vorzubeugen.
Für die Datenübernahme wird im SAP ERP auch das Batch-Input-Verfahren9 herangezogen. Hierbei wird
durch ein Schnittstellenprogramm eine sog. Batch-Input-Mappe erzeugt, die dabei 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 -Download10. 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.3)
1.3.4.3 KOMMUNIKATIONSSCHNITTSTELLEN
Die datenorientierte Schnittstelle Remote Function Call (RFC) ermöglicht SAP- und Nicht-SAPAnwendungen, SAP-Funktionsbausteine über Rechnergrenzen aufzurufen.
Business Application Programming Interfaces (BAPIs) sind von externen Programmen aufrufbare 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 geografische Datenverarbeitung
organisieren und durchführen kann.
Mit ALE / WEB lassen sich verteilte Geschäftsprozesse über das Netz quasi zum Geschäftspartner
verlagern.
Im Rahmen von ALE werden BAPIs für die Integration verteilter Geschäftsprozesse eingesetzt.
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 personenbezogene
Daten ausgetauscht bzw. übermittelt werden und wer die regelmäßigen Empfänger sind.
1.3.5 JOB-AUFTRAGSVERFAHREN 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. Bei
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
Seite 22
Bei der Einführung von SAP ERP-Systemen bzw. -Projekten bestehen aufgrund der oben geschilderten
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 negative Folgewirkungen für die vorzusehenden
technischen und organisatorischen Maßnahmen.
Werden der Datenschutzbeauftragte und − soweit vorhanden − die Mitbestimmungsorgane (Arbeitnehmervertretung) nicht rechtzeitig sowohl bei der Einführung als auch bei allen nachfolgenden Änderungen eingeschaltet, besteht das Risiko, dass datenschutzrechtliche Anforderungen (u. a. Vorabkontrolle,
unzulässige Datenspeicherung und -übermittlung) und Mitbestimmungsrechte 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 Implementation
Guides (IMGs)
> unzureichende Dokumentation und Erläuterungen der Customizing-Einstellungen
> unzureichende Schnittstellendokumentation (Batch-Input, PC-Download, ggf. Systemerweiterungen,
Archivierungssysteme)
1.4.1 NICHTEINSCHALTUNG DES DATENSCHUTZBEAUFTRAGTEN BZW. DER
ARBEITNEHMERVERTRETER
1.4.3 NICHTBERÜCKSICHTIGUNG BZW. VERSPÄTETE ERSTELLUNG DES
BERECHTIGUNGSKONZEPTES
Während der Einführungsphase des SAP ERP sowie neuer Komponenten ist ein betriebswirtschaftliches
Berechtigungskonzept zu erstellen. Dies dient als Grundlage u. a. für den Aufbau von Rollen, mit denen
manuell oder mittels des Profilgenerators dann die benutzerspezifischen 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änkend geändert werden. Bei
einem unzureichenden bzw. zu spät eingesetzten Berechtigungskonzept besteht die Gefahr, dass den
Benutzern zu weit reichende Berechtigungen vergeben werden.
1.4.4 NICHT ORDNUNGSGEMÄSSE ANWENDUNG EINES DATENVERARBEITUNGSPROGRAMMS
Seite 23
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 Datenschutzaspekten
folgende Risiken möglich:
> Unzureichende Datenmodellierung aufgrund unterlassener Vorabkontrolle bei Verwendung 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 Sensibilisierung / Schulung der
Projektmitglieder / Anwender
> Unzureichende Dokumentation der personenbezogenen Daten, um den Rechten der Betroffenen
(Auskunft, Berichtigung, Sperrung und Löschung) und der Verpflichtung zur Benachrichtigung
nachzukommen
> Nichtbeachtung des 4-Augen-Prinzips im Rahmen des CTS (Change and Transport System).
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 unzureichende
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
Die Einschränkung der vorgenannten Risiken dient auch dazu, das Risiko der Unternehmensleitung
(Straftaten, Ordnungswidrigkeiten und Schadenersatz im Sinne des BDSG §§ 7, 8, 43, 44) zu reduzieren.
1.5 PRÜFUNGSHANDLUNGEN IM RAHMEN DER EINFÜHRUNG / CHECKLISTE
Seite 24
Zur Hilfestellung für den Datenschutzbeauftragten und die Projektmitarbeiter ist die nachfolgende
Checkliste (ohne Anspruch auf Vollständigkeit!) erstellt worden. Wesentliche Fragestellungen sind
aufgenommen worden. Es wird jedoch empfohlen, diese Checkliste projektbezogen 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 SAPProjektes 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 (regelmäß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 personenbezogener Daten
(z. B. Vertrag, Einwilligung, Dienst- / Betriebsvereinbarung) vor?
10 Soll die Möglichkeit eines automatisierten Abrufes von personenbezogenen Daten realisiert
werden?
– Wenn ja: Wie sollen die Anforderungen zur Sicherstellung des rechtmäßigen Abrufes und der
Datensicherheit realisiert werden?
11 Werden automatisierte Einzelfallentscheidungen vorgenommen?
– Wenn ja: Sind die Voraussetzungen des § 6a Abs. 2 BDSG gegeben?
12 Welche Schnittstellen bestehen zu anderen DV-Anwendungen?
Seite 25
13 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)?
14 Wie soll die Zweckbindung gemäß § 31 BDSG eingehalten werden?
15 Welche Dauer der Datenspeicherung ist für die einzelnen Datengruppen unter Berücksichtigung der
jeweiligen Rechtsgrundlage vorgesehen?
16 Welches Löschungskonzept soll realisiert werden?
17 Wie wird sichergestellt, dass aufbewahrungspflichtige Daten (z. B. Zehnjahresfrist aus steuerlichen Gründen) nur zweckgebunden zur Verfügung stehen?
18 Besteht die Notwendigkeit, Personen zu benachrichtigen?
– Wenn ja: Wie und mit welchen Formulierungen soll der Betroffene benachrichtigt werden?
19 Wie ist das Sicherheitskonzept gestaltet?
20 Sind die Berechtigungen nach dem Prinzip der geringsten Berechtigung vergeben?
21 Sind die SAP-Sicherheitsleitfäden abgearbeitet worden?
22 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 werden) und ggf.
verschlüsselt gespeichert (dies ist eine Funktion der Datenbank, nicht des SAP ERP)?
23 Auf welcher Hardware und an welchen Standorten soll SAP ERP installiert werden?
24 Welches DV-Netz soll genutzt werden?
25 Werden beim Einsatz von Internet / Intranet-Techniken entspr. Firewall-Systeme eingesetzt?
26 Werden alle eingesetzten DV-Systeme zum Betrieb des SAP ERP-Systems dokumentiert?
27 Wenn ja: Welche organisatorischen Lösungen sind vorgesehen, um dem Datenschutzbeauftragten
eine Übersicht zur Verfügung zu stellen?
28 Wird dem Datenschutzbeauftragten eine Verfahrensübersicht zur Verfügung gestellt werden?
29 Welche organisatorischen Lösungen sind vorgesehen?
30 Sind alle neu hinzugefügten Tabellen, Domänen, Datenfelder und Reports entsprechend dokumentiert und ausreichend geschützt?
31 Sind alle Personen, die Zugriff auf personenbezogene Daten erlangen können, auf das Datengeheimnis verpflichtet?
32 Wird der Datenschutzbeauftragte bei System-Upgrades bzw. Releasewechseln zeitnah eingeschaltet?
33 Gibt es in Referenztabellen kritische Auswahlfelder mit ggf. unzulässigen Inhalten (z. B. Angaben
zur Konfession im Infotyp 0002, Angaben zum Familienstand oder Kindern)?
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) zur Bearbeitung einzelner Themenfelder denkbar.
Um die Vorabkontrolle, die Begleitung des Customizing und die erforderlichen Prüfungshandlungen
möglichst umfassend durchführen zu können, ist eine ausreichende Ausbildung des Datenschutzbeauftragten
in der Nutzung der relevanten SAP ERP-Funktionen notwendig.
Im SAP ERP wird eine Vielzahl von Auditor-Rollen ausgeliefert, die insbesondere den verschiedenen
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 Transaktionsrollen (definieren ‚nur’ das Benutzermenü) und Berechtigungsrollen
(beinhalten die Berechtigungen)11.
In der folgenden Tabelle wird eine Auswahl der von SAP angebotenen Standardrollen dargestellt, die für
den Datenschutzbeauftragten relevant sind:
ROLLE
BESCHREIBUNG
FUNKTIONSUMFANG
SAP_AUDITOR_A
AIS-Zentrale
Berechtigungen
Die Berechtigungen der Rolle sind zentral für das
kaufmännische Audit und das Datenschutzaudit
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 Dateiregister zu
personenbezogenen Daten
SAP_AUDITOR_DS_A
AIS-Datenschutz
(Berechtigungen)
Die Rolle beinhaltet Berechtigungen für das
Datenschutzaudit
SAP_AUDITOR_BA_
HR
AIS-HumanResources
Das Menü der Rolle bietet Funktionalitäten zum
kaufmännischen Audit (Einzelabschluss) und zur
Personalwirtschaft (HR / HCM)
SAP_AUDITOR_SA
AIS-System Audit
Das Menü der Rolle enthält Funktionen zum
System Audit, insbesondere Systemkonfiguration,
Transportverbund, Entwicklung und Customizing
SAP_CA_AUDITOR_
SYSTEM_DISPLAY
AIS-Berechtigungen für
System Audit (Anzeige)
Die Berechtigungen der Rolle ermöglichen
einen Zugang zum System Audit (Vorsicht:
entgegen der SAP-Dokumentation keine reinen
Leserechte)
SAP_AUDITOR_SA_
CCM _USR
AIS-System Audit
-Benutzer und
-Berechtigungen
Das Menü der Rolle bietet Funktionen zur
Benutzerverwaltung: Benutzer, Berechtigungen,
Profile und Rollen
Seite 26
11 Siehe hierzu auch die SAP-Hinweise 754273 und 451960
Die SAP-Auditor-Rollen sind sehr spezifisch auf einzelne AIS-Funktionen hin definiert.
Die Rolle SAP_AUDITOR_DS beinhaltet als Menü zunächst nur die AIS-Funktionen zum ‚Dateiregister’.
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ätigkeit eines
Datenschutzbeauftragten im Rahmen der SAP-Prüfung zu unterstützen.
Die von SAP ausgelieferten Rollen müssen sorgfältig im Unternehmen analysiert und entsprechend
angepasst werden. Die explizite ‚Datenschutzrolle’ SAP_AUDITOR_DS bietet lediglich den Menüpunkt
‚Dateiregister (Übersichten)’ des AIS. Die Rolle SAP_CA_AUDITOR_SYSTEM_ DISPLAY enthält kritische
Berechtigungen, die über eine reine Anzeige hinausgehen.
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 Datenschutzrollen (z. B eine
Rolle mit reinen Leserechten) sowie Hinweise zur Ausprägung liefert die Diplomarbeit „Entwicklung von
Datenschutzrollen für das Audit Information System im SAP ERP“12
Die Rollen sind wie folgt zu finden:
Menüpfad:
Werkzeuge → Administration → Benutzerpflege → Rollenverwaltung (PFCG)
2.1 ÜBERWACHUNG DER ORDNUNGSGEMÄSSEN PROGRAMMANWENDUNG
(§ 4G ABS. 1 BDSG)
Der Beauftragte für den Datenschutz wirkt auf die Einhaltung des BDSG und anderer Vorschriften über den
Datenschutz hin. ... Er hat insbesondere die ordnungsgemäße Anwendung der Datenverarbeitungsprogramme,
mit deren Hilfe personenbezogene Daten verarbeitet werden sollen, zu überwachen; ...
12 Otto, Anna: Entwicklung von Datenschutzrollen für das AIS im SAP ERP, VDM Verlag, Saarbrücken 2008
http://www.forbit.de/allgemein/arbeitspapiere.html
Seite 27
Dabei sind speziell folgende Punkte von Relevanz:
> Zulässigkeit der Datenverarbeitung unter Beachtung des Grundsatzes der Datenvermeidung und
Datensparsamkeit (§ 3a BDSG)
> Sicherstellung der Rechte der Betroffenen (§§19 ff bzw. §§ 34 ff BDSG)
> Verpflichtung auf das Datengeheimnis (§ 5 BDSG)
> besondere technisch-organisatorische Vorkehrungen zur Gewährleistung des Datenschutzes. Für den
Fall, dass besondere Risiken für die Rechte der Betroffenen bestehen, ist eine Vorabkontrolle zwingend
erforderlich (§ 4d Abs. 5 BDSG)
Aus diesem gesetzlichen Auftrag sind die folgenden Verpflichtungen für den DSB bei Einsatz des SAP ERPSystems 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 seitens der Projektleitung in
die Projekte eingebunden wird. Außerdem sind dem DSB Programmmodifikationen und Programmschnittstellen offen zu legen. Testverfahren sind gemeinsam abzustimmen.
Bereits beim Fachkonzept kann dann die Prüfung auf datenschutzrelevante Aspekte und entsprechende
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 Verwendung in Programmen liefert das ABAP Dictionary (TransaktionSE12) 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ÄSSIGKEIT
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 konkreten Datenverarbeitung zu prüfen.
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 Sicherstellung eines
ordnungsgemäßen Betriebes zur Verfügung stehen sollten, aufgelistet (Hinweis: Ein Nachvollzug
wesentlicher Protokolleinträge ist mit dem Audit Information System (System Audit, Systemprotokolle und
Statusanzeigen möglich). Details sind in Kapitel 4.2.1.9 beschrieben:
> das Security Audit Log, Transaktion SM20N (Filtereienstellungen SM19)
> 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 RSTBHIST 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
Seite 28
Zur Überwachung der Programmanwendung durch den DSB ist eine aussagefähige Verfahrensdokumentation erforderlich, die insbesondere über folgende Punkte Auskunft geben soll:
> Aufgabenstellung der Anwendung (i.S. der Zweckbindung), insbesondere mit Hinweisen auf
Der DSB ist an der Erarbeitung eines organisatorischen Rahmens zur Ausgestaltung des Berechtigungskonzeptes 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)
> 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 einschließlich der Übernahme in die Produktion)
> die fachlich-organisatorische Ausgestaltung des rollenspezifischen Konzeptes
> möglichst arbeitsplatzbezogene und nur in begründeten Ausnahmefällen individuelle Ausgestaltung
> funktionaler Aufbau
> Prinzip der minimalen bzw. adäquaten Berechtigungsvergabe
> Kontrollierbarkeit im Sinne des BDSG und Revisionsfähigkeit
> Umsetzung der Anforderungen an die Zweckbindung (§ 31 BDSG) und der Datensicherung im Sinne
des § 9 BDSG und seiner Anlage
> die systemtechnische Ausgestaltung
> Grundsätze zur Nutzung der zentralen Benutzerverwaltung
> Umgang mit (Standard-) Rollen und Standardprofilen (Hinweis: keine Verwendung von
Standardprofilen (= Auslieferungsprofile)
> Festlegung von Restriktionen einzelner Berechtigungen (Hinweis: Berücksichtigung aller
relevanter Systeme und Mandanten)
> Realisierung des dazugehörigen organisatorischen Konzepts
> Trennung von kritischen und unkritischen Transaktionen
> die Anforderungen an eine dem Zweckbindungsprinzip angemessene Abbildung der Unternehmensorganisation(en) auf die SAP-Struktur / Organisationsebene von Systemen, Mandanten, Buchungskreisen, Werken, Personalbereiche etc.
2.1.5 MITWIRKUNG BEI DER FESTLEGUNG UND ÜBERPRÜFUNG DES
BERECHTIGUNGSKONZEPTES
Seite 29
datenschutzrelevante Elemente
> Technisch-organisatorische Maßnahmen gemäß § 9 BDSG bzw. Anlage
> Zugriffsberechtigungen nach Art und Umfang auf personenbezogene Objekte
(z. B. Daten, Programme, Berichte)
> Verwendungsnachweis der personenbezogenen Objekte in Programmen
> Berechtigte interne und externe Empfänger der von den Anwendungsprogrammen erzeugten Daten
nach Art und Umfang
> Darstellung der Programmabläufe. Sicherung der Datenbestände und der verwendeten Programme
> 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 Abschnitten 2.3.3 ff und 2.4.
> ein Verfahren zur Klassifikation und Pflege von Berechtigungsgruppen von ABAP-Reports und Tabellen
> 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 unterschiedliche Rollen wie Lese-Rollen,
Rollen mit Zugriff auf bestimmte Organisationseinheiten, Transaktionsrollen etc.
> 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
> 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)
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 Angemessenheit der vergebenen
Berechtigungen durch die Datenverantwortlichen vorzusehen.
> Die Benutzerverwaltung ist möglichst nahe beim Benutzer wahrzunehmen.
> Die Administration des Berechtigungsverfahrens sollte auf mehrere Stellen, Organisationseinheiten oder
Mitarbeiter verteilt und entsprechend dokumentiert werden (Funktionstrennung zwischen Erstellen,
Zuordnen und Kontrollieren / Prüfen).
> Die Vergabe von Nutzerkennungen hat nachvollziehbar zu erfolgen (Vergabe von Berechtigungen im
System ausschließlich nach schriftlicher 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 erhalten, die sie für
ihre Aufgaben zwingend benötigen.
> Die Berechtigungen privilegierter Benutzer sollten fachlich und zeitlich eingegrenzt werden (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 protokollieren.
> 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 Sicherheitsleitfaden).
> Anwendungsbezogene Berechtigungen für Entwickler sind grundsätzlich auf die Entwicklungssysteme
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
Seite 30
Der DSB sollte rechtzeitig an der Erarbeitung eines organisatorischen Rahmens zur Ausgestaltung des
Betriebskonzeptes beteiligt werden. Unter einem Betriebskonzept wird hier die grundlegende Einrichtung
des SAP-Systems auf einem oder mehreren Servern und unter Einbeziehung der Kommunikationseinrichtungen, der Netzwerke, des Betriebssystems und des Datenbankmanagements verstanden.
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öheren Abstimmung der gesellschaftsübergreifenden Aktivitäten und operativen übergreifenden Fragestellungen sowie ein tendenziell
höherer Personalbedarf als in einem rein zentralen Ansatz gegenüber.
> Bei einem zentralen Ansatz ist eine eindeutige Kompetenzregelung mit klarer Organisationsstruktur und
schneller Entscheidung bei Konfliktfällen möglich. Allerdings kann die Flexibilität der über das SAPSystem abgewickelten Unternehmen / Behörden eingeschränkt bzw. die Durchsetzung von gesellschaftsindividuellen Anforderungen bei übergreifenden 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.
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 liegenden Schichten
(wie etwa der Datenbank selbst oder dem Betriebssystem) zugegriffen wird. Ansonsten könnte der SAPBerechtigungsschutz umgangen werden.
> Es darf nur ein sehr eng begrenzter Kreis von Administratoren Zugriff auf Datenbanktabellen und SAPDaten auf Betriebssystemebene erhalten.
2.1.7 ABFASSUNG EINER DATENSCHUTZERKLÄRUNG
Seite 31
Sofern Dritten ein Internet-Zugang auf das SAP-System gewährt wird, ist der DSB an der Erstellung einer
Datenschutzerklärung zu den anfallenden Geschäftsprozessen zu beteiligen.
Die Nutzer sind zu Beginn des Nutzungsvorgangs über Art, Umfang und Zwecke der Erhebung sowie die
Verwendung personenbezogener Daten und deren Verarbeitung zu unterrichten, sofern eine solche
Unterrichtung nicht bereits erfolgt ist (§13 Abs. 1 Satz 1 TMG).
Diese Erklärung ist als vertrauensbildende Maßnahme zu verstehen und soll den Geschäftspartner in
verständlicher Form über getroffene Standardmaßnahmen zum Schutz seiner Privatsphä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 verschiedene
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 verbunden. Eine Beschreibung der hierbei zu
ergreifenden Schutzmaßnahmen findet sich in den SAP-Sicherheitsleitfäden.
Beispielsweise wird darauf hingewiesen, dass – zur Vermeidung von unbefugtem Einschleusen von
Programmen oder Daten über das SAP ERP-Transportsystem in das Produktivsystem – eine Abschottung
gegenüber Test- und Entwicklungssystemen erforderlich ist. Es wird empfohlen, 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 vorgelagerten Systemen in das
Produktivsystem gelangen, ohne inhaltlich abgestimmt zu sein.
Hinweis: Hierbei ist ein datenschutzgerechtes Entsorgungskonzept für Test- bzw. nicht mehr benötigten
Produktiv-Output (z. B. Papier, Datenträger) festzulegen (z. B. DIN 32 757 bzw. DIN 33 858).
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 notwendigen Funktionstrennungen
und die Handhabung des Zugriffsberechtigungskonzeptes und auch die Auswertung der Logfiles. Vergleiche
hierzu auch die Bemerkungen zu den Zugriffsrechten des DSB zum Security Audit Log (Kapitel 4.2.1.9.1) und
zum Audit Information System in Kapitel 6.
2.2 SCHULUNG DER ANWENDER MIT VERPFLICHTUNG AUF DAS DATENGEHEIMNIS (§§ 4G UND 5 BDSG)
2.2.1 PERSONENKREIS, DER GESCHULT UND VERPFLICHTET WERDEN MUSS
Seite 32
Bei Aufnahme der Tätigkeit sind die bei der Erhebung, Verarbeitung und Nutzung personenbezogener Daten
tätigen Personen zu schulen (§ 4g Abs. 1 Nr. 2 BDSG) und auf das Datengeheimnis zu verpflichten (§ 5 BDSG).
Dabei handelt es sich im Wesentlichen um folgenden Personenkreis:
> Mitarbeiter in allen Bereichen, in denen PCs im Einsatz sind
> Mitarbeiter in Rechenzentren / IT-Mitarbeiter
> Mitarbeiter in Fachabteilungen mit personenbezogenen Daten, z. B.
> Personalabteilung, Lohn- und Gehaltsabrechnung, Zeitwirtschaft
> Verkauf, Marketing, Werbung
> Einkauf
> Controlling
> Boten
> Projektmitglieder
Zu verpflichten sind auch Teilzeitkräfte und Auszubildende / Praktikanten. Betriebsratsmitglieder fallen
ebenfalls unter § 5 BDSG.
Mitarbeiter von Fremdfirmen, z. B. externe Berater, die Zugriff zu personenbezogenen Daten haben, müssen
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 Anwenderschulung soll allgemeine
Informationen zum Datenschutzrecht und auf den jeweiligen Tätigkeitsbereich abgestimmte Hinweise
geben, insbesondere zu Datensicherheit und Ordnungsmäßigkeit der Datenverarbeitung. Ziel der Schulung
ist es, den Einzelnen für datenschutzgerechtes Verhalten am Arbeitsplatz zu befähigen.
Für Schulungszwecke können auch PC-gestützte Anwenderschulungen verwendet werden, die die
Schulung des Datenschutzbeauftragten nicht ersetzen, sondern zur Vertiefung des Wissens beitragen
sollten.
Nach erfolgter Schulung sind die Teilnehmer auf das Datengeheimnis schriftlich zu verpflichten. Diese Verpflichtungserklärung (Anlage 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 2) auszuhändigen.
Als Beispiel kann der SAP-Hinweis 35493 ‚Verpflichtung Datenschutz und Geheimhaltung‘, dienen.
auf das Datengeheimnis verpflichtet sein. Der Datenschutzbeauftragte kann die Verpflichtung dieser
Mitarbeiter nicht selbst vornehmen, er sollte sich aber die Verpflichtung vertraglich zusichern lassen und
deren Einhaltung kontrollieren.
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 Datenschutz
folgendermaßen eingetragen werden:
Menüpfad:
Personal → Personalmanagement → Administration → Personalstamm → Pflegen (PA30).
Verwendet werden kann der Infotyp 0035 (Belehrungen) oder die Qualifikation im Profil einer 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 → laufende Einstellungen
→ Qualifikationskatalog bearbeiten (OOQA)
Seite 33
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 verpflichtet ist und an welchen Schulungen er teilgenommen hat. Der Report bietet auch die
Möglichkeit, nach Organisationseinheiten auszuwerten. Ein Vergleich zwischen Mitarbeitern einer Abteilung
(z. B. Personal-Abt., EDV-Abt. usw.) mit den verpflichteten Personen zeigt die Differenzen auf. Ein besonderes
Augenmerk ist auf Neueinstellungen bzw. Umsetzungen von Mitarbeitern zu richten.
Empfehlung: Unternehmen, die nicht das HCM-Organisationsmanagement und die HCM-Personalentwicklung einsetzen, sollten den Infotyp 0035 (Belehrungen) benutzen. Alle anderen können auch den oben
beschriebenen Weg über die Qualifizierungen im Profil einer Person verwenden.
2.2.3.2 ANWENDERSCHULUNG ÜBER DAS VERANSTALTUNGSMANAGEMENT
Für Anwender, die das Veranstaltungsmanagement nutzen, empfiehlt es sich, mit diesem Instrument 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 Fall wirkt der DSB aktiv an der Umsetzung datenschutzrechtlicher Anforderungen mit.
Für die effektive Wahrnehmung seiner Aufgaben benötigt der DSB nach den §§ 4e und 4g Abs. 2 BDSG
folgende Unterlagen:
§ 4G ABS. 2 AUFGABEN DES BEAUFTRAGTEN FÜR DEN DATENSCHUTZ
Dem Beauftragten für den Datenschutz ist von der verantwortlichen Stelle eine Übersicht über die in §4e
Satz 1 genannten Angaben sowie über zugriffsberechtigte Personen zur Verfügung zu stellen. Der
Beauftragte für den Datenschutz macht die Angaben nach § 4e Satz 1 Nr. 1 bis 8 auf Antrag jedermann in
geeigneter Weise verfügbar.
Seite 34
§ 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 Verfassung des
Unternehmens berufene Leiter und die mit der Leitung der Datenverarbeitung beauftragten Personen
3 Anschrift der verantwortlichen Stelle
4 Zweckbestimmungen der Datenerhebung, -verarbeitung oder -nutzung
5 eine Beschreibung der betroffenen Personengruppen und der diesbezüglichen Daten 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 angemessen sind
§18 ABS. 2 DURCHFÜHRUNG DES DATENSCHUTZES IN DER BUNDESVERWALTUNG
Die öffentlichen Stellen führen ein Verzeichnis der eingesetzten Datenverarbeitungsanlagen. Für ihre
automatisierten Verarbeitungen haben sie die Angaben nach § 4e sowie die Rechtsgrundlage der
Verarbeitung schriftlich festzulegen. Bei allgemeinen 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 zusammengefasst 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-Norm 27001 im
Unternehmen zurückgreifen. Dort wird u. a. eine Erhebung der IT-Systeme und eine Liste der ITAnwendungen (Software, Anwendungsprogramme, Geschäftsprozesse) sowie weitere Angaben
(zuständige Administratoren, personenbezogene Daten) gefordert. Dies bietet die Grundlage für das
betriebsinterne Verfahrensverzeichnis.
Die öffentlichen Stellen haben nach §18 Abs. 2 BDSG inhaltlich weitgehend ähnliche Angaben zu machen,
sind aber per Gesetzestext auf die schriftliche Dokumentation verpflichtet.
VERANTWORTLICHKEITEN
Im Rahmen der Novellierung des BDSG im Jahr 2001 wurde die Aufgabenteilung zwischen der DVAbteilung und dem DSB der Realität angepasst: Die speichernde Stelle wurde in verantwortliche 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 personenbezogenen
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 Voraussetzungen als Ordnungswidrigkeit oder Straftatbestand verfolgt werden.
Seite 35
Es bietet sich an, diese Klarstellung den Verantwortlichen mit der Aufforderung zur Erstellung der
Übersichten zukommen zu lassen.
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. Hierfü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 zugriffsberechtigten
Personen.
Es muss zu folgenden Zwecken dem DSB von der verantwortlichen Stelle zur Verfügung gestellt 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 vorzunehmen.
> Der DSB benötigt die Übersichten, um die ordnungsgemäße Verarbeitung personenbezogener Daten
nach § 4g Abs. 1 Nr. 1 BDSG zu überwachen.
> Benachrichtigung des Betroffenen nach den §§19a 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 Satz 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 Absatz 2 in Verbindung mit
§ 4e, Ziffer 1-8 BDSG und ein betriebsinternes Verfahrensverzeichnis – indem darüber hinaus die Angaben
gemäß § 4e Ziffer 9 und § 4g, Absatz 2 enthalten sind – zu unterteilen, die verschiedene Funktionen erfüllen.
Eine gesetzliche Verpflichtung betreffend eine Aufspaltung in ein öffentliches Melderegister und ein betriebsinternes Verfahrensverzeichnis besteht jedoch nicht.
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 allgemeine 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 Landeszentrums für
Datenschutz Schleswig-Holstein beispielhaft zeigt (vgl. 2.3.9).
Seite 36
DAS BETRIEBSINTERNE VERFAHRENSVERZEICHNIS
Das betriebsinterne Verfahrensverzeichnis dagegen dient dem Datenschutzbeauftragten darüber hinaus zur
internen Prüfung, der Vorabkontrolle, der Identifizierung der zugriffsberechtigten Personen gemäß § 4g
Abs. 2 Satz 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 herangezogen 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 Speicherung von Gesundheits- oder
Leistungsdaten.
> Bei Überwachung der datenschutzgerechten Verarbeitung muss der DSB mit Unterstützung 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, Kategorien 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 Verarbeitung sind
detaillierte Angaben über die gespeicherten Daten und deren Verarbeitungszwecke erforderlich.
Aus dieser Zusammenstellung ist ersichtlich, dass auch Auskunft und Benachrichtigung sich auf Punkte
der Übersichten beziehen.
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.
Seite 37
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 ggf. bis auf das sensitive Datum selbst herunterbrechen, z. B. Felder
im Infotyp 0002 (Daten zur Person; Datenfeld Konfession), Infotyp 0008 (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 personenbezogenen 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.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 InternetDarstellung in einer Art Impressum.
2.3.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 Daten – 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 bereichsspezifische Gesetze, Tarifverträge,
Betriebsvereinbarungen, Einwilligungen oder im Fall des § 28 Absatz 1 Satz 1 Nummer 1 BDSG die verschiedensten Vertragsverhältnisse in Frage kommen.
Die Angabe der Geschäftszwecke muss im Unternehmen aus Sicht der Fachabteilung definiert werden, z. B.
Finanzbuchhaltung, Personalabrechnung, Bewerberverwaltung, Reisekostenabrechnung.
2.3.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 auszugehen und nicht vom EDVtechnischen 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 unten).
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.
Seite 38
Im Audit Information System findet sich eine Dokumentationsmöglichkeit für Daten bzw. Tabellen des ABAP
Dictionary bestimmter Personengruppen. Dort wird nach folgenden Personengruppen differenziert:
> Mitarbeiterdaten (HCM-Daten)
> Bewerberdaten (HCM-Daten)
> Lieferantendaten
> Kundendaten
AUSLEGUNG DER GESETZLICHEN ANFORDERUNG IN BEZUG AUF SAP ERP:
§ 4g BDSG in Verbindung mit § 4e Ziffer 5 BDSG verlangt von der verantwortlichen Stelle, dem Datenschutzbeauftragten u. a. eine Beschreibung der betroffenen Personengruppen und der diesbezüglichen
Daten oder Datenkategorien zur Verfügung zu stellen.
> 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 Personengruppen verwendeten
Tabellen können direkt im AIS angezeigt werden.
Allerdings basiert das AIS noch auf der Sprachregelung des ‚alten BDSG’, verwendet Begrifflichkeiten wie
‚Dateiregister’ und bietet bisher keinerlei Informationen über die personenbezogenen Daten in der JAVAWelt. 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 Dokumentation / Beschreibung von Daten
(z. B. im ABAP Dictionary), die im Abschnitt 2.4 detaillierter dargestellt werden.
Es stellt sich die Frage, wie genau die Personengruppen und die diesbezüglichen Daten dokumentiert
werden müssen. Das BDSG überlässt es der verantwortlichen Stelle, sodass sowohl 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 Ziffer 9 in § 4 e BDSG eine Beschreibung, auf deren Grundlage eine Beurteilung 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 Mitarbeiterdaten. 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 VERSCHIEDENEN
„ROLLEN“ auftauchen, z. B. im Rahmen der Gehaltsabrechnung oder als Buchhaltungssachbearbeiter.
Die im Audit Information System getroffene Unterscheidung verschiedener Personengruppen bzw. „Rollen“
ist durchaus geeignet, die entsprechenden Anforderungen des BDSG zu erfüllen.
Seite 39
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 Mitarbeiterdaten sind dies die entsprechenden
Infotypen.
Die Personalstammdaten (Tabellen PA0*) unterscheiden sich i. d. R. hinsichtlich Zweckbestimmung,
Zugriffsberechtigung und regelmäßigen Empfängern oder lassen sich zumindest in Gruppen aufteilen.
Die Infotypen im HCM-Modul sind zudem bereits überwiegend nach personalwirtschaftlich-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 Tabellen sinnvollerweise
zusammengefasst werden sollten, entfällt, und die zusätzlichen Angaben der Übersichten nach § 4 BDSG
können den im System definierten Tabellen direkt zugeordnet werden. Auch aus Praktikabilitätsgründen
bietet sich diese einheitliche und systemnahe Dokumentation an, denn dabei kann auf einfache Weise auf
die im System hinterlegten Informationen 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 beachten. In der Customizing-Phase bietet
es sich an, eine erste Version der Übersichten zu erstellen.
Auch BENUTZERDATEN sind personenbezogene Daten und daher in die Übersichten mit aufzunehmen.
Dazu zählen
> Sachbearbeiterkennzeichen, z. B. im Rahmen des Moduls FI
> Protokolldaten, z. B. in der Workload Analysis (STAD)
> Verwaltungsdaten, z. B. Berechtigungen der SAP-Benutzer
> Daten von Dritten, z. B. bestellender Sachbearbeiter eines Kunden
Personenbezogene Daten, die ausschließlich Zwecken der Datenschutzkontrolle, der Datensicherung oder
der Sicherstellung eines ordnungsgemäßen Betriebs einer Datenverarbeitungsanlage dienen, unterliegen
nach § 31 BDSG einer besonderen Zweckbindung, was insbesondere 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 personenbezogenes 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 werden. Es sollte daher für das SAP ERP-System ausreichen, alle Tabellen, die
Sachbearbeiterkennzeichen enthalten, aufzulisten und gemeinsam zu dokumentieren.
Auch PROTOKOLLDATEIEN (siehe hierzu auch Abschnitt 2.3.5) sind in die Übersichten aufzunehmen.
Da es sich im Allgemeinen um Mitarbeiterdaten handelt, unterliegt die Verarbeitung dieser Daten der Mitbestimmung nach § 87 Abs. 1 Satz 6 BetrVG bzw. § 75 Abs. 3 Satz 17 BPersVG.
2.3.4 EMPFÄNGER ODER KATEGORIEN VON EMPFÄNGERN
Seite 40
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 gesetzlichen Grundlagen (Sozialversicherung, Finanzamt, DEÜV usw.).
WELCHE HILFEN BIETET SAP AN, UM DIE REGELMÄSSIGEN EMPFÄNGER ZU ERMITTELN?
> Technische Verbindungen
Transaktion SM59 (RFC-Destination), Basis-Services (BC-SRV) und SM54 (CPIC-Destination); weitere
Verbindungen (SAP NetWeaver Exchange Infrastructure, SAP XI (Nachfolger: SAP NetWeaver Process
Integration, PI)) überprüfen
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 findet man sie im Lieferantenstamm
(LFBK) oder im Modul HCM im Infotyp 0009 (Bankverbindung, 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 organisatorisch 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 übergreifenden Zugriffsrechten erfolgen.
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.
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 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 Transaktion ST03N;
ein mittelbarer Rückschluss über die Verwendung ist möglich)
> Genutzte Datentabellen
Transaktion ST10
> Object Navigator (SE84)
Seite 41
Menüpfad:
Werkzeuge → ABAP Workbench → Übersicht → Infosystem → ABAP Dictionary → Datenbanktabelle
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.5 REGELFRISTEN FÜR LÖSCHUNG13
Einleitend ist zunächst zu bemerken, dass die nachfolgend angesprochenen Fristen – betreffend die
Löschung von personenbezogenen Daten – sich explizit an den hierzu einschlägigen gesetzlichen
Regelungen der Bundesrepublik Deutschland und an denen von der Rechtsprechung hierzu ergangenen
Vorgaben orientieren. Technische Hinweise und Anmerkungen gelten 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 Bestimmungen.
Gemäß § 3a Bundesdatenschutzgesetz (BDSG) haben sich Gestaltung und Auswahl von Datenverarbeitungssystemen an dem Ziel auszurichten, 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öglichkeiten 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ältnismäßig großen Aufwand an
Zeit, Kosten und Arbeitskraft einer bestimmten oder bestimmbaren 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 Identifikationsmerkmale 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 Kapitel mit
bestehenden Rechtsvorschriften, insbesondere betreffend Regelfristen für Löschungs- und Mindestaufbewahrungsfristen, von personenbezogenen Daten auseinander. Da das BDSG jedoch ein sogenanntes
Auffanggesetz ist, gehen spezielle Rechtsvorschriften vor. Erst wenn solche bereichsspezifischen
vorrangigen Bestimmungen keine rechtlichen Regelungen beinhalten, kommt das BDSG zum Tragen
(Lex specialis vor Lex generalis).
Aufgrund der in der Vergangenheit bereits stattgefundenen – damit auch zukünftig zu erwartenden –
Schaffung von neuen gesetzlichen Bestimmungen, wie z. B. des Allgemeinen Gleichbehandlungsgesetzes
(AGG) aus dem Jahr 2006 muss darauf hingewiesen werden, dass Regelungen des Gesetzgebers,
Seite 42
13 Diesem Abschnitt liegen folgende Quellen zugrunde: Abel, Datenschutz, Band 2, Teil 6
Im BDSG werden die sogenannten Regelfristen für Löschungen – gemäß § 4e Nr. 7 BDSG – genannt. Die
Legaldefinition des § 3 Abs. 4 Nr. 5 BDSG versteht unter löschen „das Unkenntlichmachen gespeicherter
personenbezogener Daten“, womit das unwiederbringliche Tilgen der Daten, ungeachtet der dabei
verwendeten Verfahren, gemeint ist14.
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 öffentliche Stellen des Bundes
(was hierunter im Einzelnen gemeint ist, ergibt sich aus der Legaldefinition 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ändigkeit 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 Aufbewahrungsfristen
entgegenstehen,
2 Grund zu der Annahme besteht, dass durch eine Löschung schutzwürdige Interessen des
Betroffenen beeinträchtigt würden, oder
3 eine Löschung wegen der besonderen Art der Speicherung nicht oder nur mit unverhältnismäßig hohem Aufwand möglich ist.
Gemäß dem Grundsatz Lex specialis vor Lex generalis (das besondere Gesetz geht dem allgemeinen
Gesetz vor) nachfolgend einige Beispiele für vorrangige bereichsspezifische Löschungsfristen der
öffentlichen Stellen:
betreffend Löschung und Mindestaufbewahrung, in der Praxis einer Ausgestaltung – aufgrund von aktueller
Rechtsprechung – bedürfen. Eine Vielzahl bestehender Rechtsprechung zu Löschungs- und Mindestaufbewahrungsfristen ist bereits ergangen. Weitere gerichtliche Entscheidungen werden noch folgen, sodass auf
die vorliegende Thematik stets ein „juristisches Auge zu werfen ist“.
> BERUFSGENOSSENSCHAFTEN, spezielle gesetzliche berufsgenossenschaftliche Aufbewahrungspflichten bestehen grundsätzlich nicht, dennoch empfehlen die Berufsgenossenschaften in ihrem BGBlatt B36, Ausgabe Oktober 2005, dass für Unterweisungen zur Arbeitssicherheit 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),
> 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 Aufgaben nicht
mehr benötigen, sind diese dem Bundesarchiv oder in bestimmten Fällen dem zuständigen Landes-
Seite 43
14 siehe BDSG Kommentar Gola / Schomerus, §§ 3 Rn. 40
>
>
>
>
archiv zur Überlassung anzubieten (§ 2 Abs. 1), dabei bleiben Rechtsvorschriften betreffend die Vernichtung (§ 2 Abs.7) bzw. Rechtsansprü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äftsstellen der
Prüfungsausschüsse sind, abhängig von der jeweiligen Art der Daten, nach einer 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, 15 oder 20 Jahren getilgt (§ 46 Abs. 1 BZRG),
VERKEHRSZENTRALREGISTER („Verkehrssünderkartei“), im Register gespeicherte Eintragungen
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 Regelfristen für die
Löschung von personenbezogenen Daten für öffentliche Stellen Anwendung finden.
Allein im Bereich der sogenannten sozialen Sicherung haben etwa die gesetzlichen Krankenkassen
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 Sozialversicherung (SRVwV)
und der
> Risikostruktur-Ausgleichsverordnung (RSAV)
ergeben. Dabei variieren die anzuwendenden Aufbewahrungsfristen zwischen zwei und zehn Jahren.
Die nach § 284 Abs. 1 Satz 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 organisierte Personen, Personengesellschaften und nicht rechtsfähige Vereine, die sich an die Verarbeitungsregelungen der §§ 28 ff BDSG
halten müssen. Ausgenommen sind somit sogenannte 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) sowie privatrechtlich organisierte Vereinigungen von öffentlichen Stellen des
Bundes und der Länder gemäß den besonderen Vorgaben des § 2 Abs. 3 BDSG.
Seite 44
§ 35 Abs. 2 BDSG enthält eine ganze Reihe von Löschungsvorschriften. Demnach sind personenbezogene
Daten zu löschen, wenn
1 ihre Speicherung unzulässig ist
2 es sich um Daten über die rassische oder ethnische Herkunft, politische Meinungen, religiöse oder
philosophische Überzeugungen oder die Gewerkschaftszugehörigkeit, über Gesundheit oder das
Sexualleben, strafbare Handlungen oder Ordnungswidrigkeiten handelt und ihre Richtigkeit von der
Den Löschungsfristen auf der einen Seite stehen sogenannte MINDESTAUFBEWAHRUNGSFRISTEN
auf der anderen Seite entgegen. Diesbezüglich gibt es eine ganze Reihe von Bestimmungen, die explizite
Regelungsgehalte aufweisen, welche nachfolgend – nicht abschließend – aufgeführt sind. Wichtige Eckpunkte sind:
> Aufbewahrung nach Handels- und Steuerrecht (z. B. Buchführung, Kundendaten, Lageberichte,
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)
verantwortlichen Stelle nicht bewiesen werden kann
3 sie für eigene Zwecke verarbeitet werden, sobald ihre Kenntnis für die Erfüllung des Zweckes der
Speicherung nicht mehr erforderlich ist
4 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
ARBEITS- UND SOZIALRECHT, BERUFSORDNUNGEN
Die Aufbewahrungsvorschriften erstrecken sich aufgrund gesetzlicher Vorgaben von
zwei Jahre
Arbeitszeitnachweise (§16 ArbZG), Jugendarbeitsschutzunterlagen (§ 50 Abs. 2 JArbSchG),
fünf Jahre
Nachweise der Beitragsabrechung und Beitragszahlung an Sozialversicherungsträger
(§ 28f Abs. 1 i. V. m. § 28p Abs. 1 SGB IV, Handakten von Rechtsanwälten (§ 50 Abs. 2 BRAO),
sechs Jahre Betriebliche Alterversorgung (§11 Abs. 2 BetrAVG), Identifizierungspflicht 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.
Seite 45
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, Konvertierungsprotokolle15,
drei Jahre
Systemdateien (drei Generationen), Standardsoftware16
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, soweit für die Nachvollziehbarkeit von
nachweispflichtigen Aufträgen erforderlich (Rechnungslegungsrelevante Tabellen).
DATENVERARBEITUNG IN BESONDEREN FÄLLEN
PROTOKOLLDATEIEN
Eine besondere Problematik besteht hinsichtlich der Speicherung von sogenannten Protokolldateien mit
Hilfe von automatisierten DV-Anlagen. Dabei handelt es sich zum einen um Protokolle 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 Sinne 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 Daten. Einzelne Inhalte
bestehender bzw. gespeicherter Log-Files können – ohne großen Aufwand – natürlichen Personen
zugeordnet werden. Dabei sind gerade bei der Verwendung von SAP-Anwendungen Log-Files und Protokolle – im Zusammenhang mit Tabellenzugriffen – weit verbreitet, sodass hier nicht nur datenschutzrechtliche Normen, sondern auch betriebsverfassungsrechtliche Aspekte tangiert sind. Da den meisten SAPAnwendern und selbst Basis-Administratoren nicht immer im Einzelnen klar ist was, wie und wo mittels
Log-Files geloggt 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 Darmstadt17 und des LG Darmstadt ist zu entnehmen, dass selbst
dynamische IP-Adressen geeignet sind, einen Personenbezug herzustellen und deshalb einer datenschutzrechtlichen und ggf. einer mitbestimmungsrechtlichen Beurteilung bedürfen. Damit hat auch bei der
Erhebung bzw. Verarbeitung von Log-Files der Grundsatz der Datenvermeidung und Datensparsamkeit –
i. S. d. § 3 a BDSG − im Vordergrund zu stehen.
Seite 46
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 normiert § 28 Abs. 1 Ziffer 2 BDSG:
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,
soweit es zur Wahrung berechtigter Interessen der verantwortlichen Stelle erforderlich 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 werden, sodass es stets zu
einer Interessensabwägung kommen muss. Leider hat es der Gesetzgeber in § 28 Abs. 1 Nr. 2 BDSG verabsäumt, konkrete Anhaltspunkte zu formulieren, die eine Interessensabwägung vereinfachen würden.19
Demnach hat eine solche Interessensabwägung im Zuge einer sogenannten 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 Betroffenen bemessen werden.
Eine sinnvolle Maßnahme, die eine datenschutzkonforme Nutzung gerade von Log-Files ermöglichen
würde, wäre der Einsatz von Tools, welche automatisch personenbezogene bzw. personenbeziehbare Daten
in Log-Files anonymisieren (z. B. Anonlog, Pseudo / Core). Damit wäre nur noch bei wenigen abrechnungsund steuerrelevanten Vorgängen die Verwendung von klassischen, d. h. nicht anonymen Protokollen
notwendig.
15 siehe Abel, Datenschutz, Band 2, Teil 6 / 2.4.1.4
16 siehe Abel, Datenschutz, Band 2, Teil 6 / 2.4.1.4
Anders verhält es sich dagegen bei Protokolldateien (Änderungsbelege), welche aufgrund handels- bzw.
steuerrechtlicher Grundsätze zu führen sind, beispielsweise muss stets erkennbar sein, welcher „SAPUser“ eine Rechnung storniert hat. Gerade in diesen Fällen ist eine Protokollierung schon zur Revisionssicherheit unumgänglich.
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 Fallkonstellation –
insbesondere Betriebsräte, Datenschutzbeauftragte, Sachverständige und Systemadministratoren sein.
Freilich sollten auch deren Zugriffe – trotz ihrer besonderen Vertrauenspositionen − 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 LogFiles möglich).
BEWERBUNGSUNTERLAGEN
Das Bundesarbeitsgericht stellte in seinem Urteil vom 6. Juni 1984 fest, dass eine längerfristige Aufbewahrung von Personalbögen bzw. Bewerbungsunterlagen eines erfolglos gebliebenen Stellenbewerbers das
verfassungsmäßige Persönlichkeitsrecht des Bewerbers verletzt. Auch hier greift insoweit der Grundsatz
der Datenvermeidung und Datensparsamkeit i. S. d. § 3 a 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
Bewerber in §15 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 Beweislastpflicht 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 zu addieren
und zusätzlich mit einer Karenzzeit von einem Monat zu versehen 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
Seite 47
19 Simitis, Kommentar BDSG, S. 1030 Rn. 162
Speicherung nicht erforderlich ist“. Eine Erforderlichkeit, ü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öschfristen einhalten (§ 915g Abs. 1 i. V. m. § 915a Abs. 1 ZPO, §15 SchuVVO – Schuldnerverzeichnisverordnung). 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 Datenvermeidung und Datenspeicherung dringend
geboten.
Bei relationalen Datenbanken, wie sie in SAP-Anwendungen verwendet werden, hat der Anwender jedoch
keinen Einfluss auf die physikalische Speicherung. Löschung bedeutet Sperrung aller weiteren Zugriffe,
ohne dass die Daten unbedingt zu 100 % gelöscht werden. Theoretisch wären sie durch Datenbank-Spezialisten (Administratoren) wieder einsehbar. Eine Datenbank-Reorganisation würde die Wahrscheinlichkeit
erhöhen, dass die „gelöschten“ Daten physikalisch eliminiert werden.
Es empfiehlt sich, unerlaubt gespeicherte oder falsche bzw. angezweifelte Daten als Datensatz – soweit
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.
Anstelle einer Löschung kann ggf. eine Sperrung in Frage kommen, wenn wegen der besonderen 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 organisatorische Maßnahmen einzufordern, da diese Stelle die Verantwortlichkeit für die Umsetzung der vorgeschriebenen Aufbewahrungsund Löschfristen trägt (der Datenschutz ist hier nur ein Aspekt). Desweiteren sind zu den Löschfristen im
betriebsinternen Verfahrensverzeichnis detaillierte Informationen anzugeben.
Ein Anspruch zur Löschung von Daten besteht nicht:
> bei gesetzlichen, vertragsmäßigen oder vertragsrechtlichen Aufbewahrungsvorschriften
> wenn ein Grund zu der Annahme besteht, dass durch eine Löschung schutzwürdige Interessen des
Betroffenen beeinträchtigt werden.
2.3.6 GEPLANTE ÜBERMITTLUNG IN DRITTSTAATEN
Dieser Punkt ergänzt die unter § 4e BDSG zu nennenden Empfänger um die geplanten Übermittlungen 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 kann.
Als Ausnahmen sind neben der Einwilligung und der Übermittlung zur Erfüllung eines Vertrages insbeson-
Seite 48
20 Az: 5 AZR 286 / 81, Urteil vom 6. Juni 1984
2.3.7 MASSNAHMEN ZUR GEWÄHRLEISTUNG DER SICHERHEIT
Das BDSG (§ 4e Ziffer 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 angemessen sind.
Die Beurteilung der Datensicherungsmaßnahmen hängt u. a. davon ab, welche personenbezogenen Daten
im Einzelnen verarbeitet werden. Für das betriebsinterne Verfahrensverzeichnis 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, Benutzeradministration, Berechtigung
und Autorisierung werden hier ausführlich behandelt.
dere Garantien aus Vertragsklauseln oder verbindliche Unternehmensregelungen (Binding Corporate Rules
oder Codes of Conduct) möglich21. Die EU-Kommission selbst bietet Standardvertragsklauseln für spezielle
Übermittlungen von personenbezogenen Daten in unsichere Drittländer an. Diese Standardvertragsklauseln
sind eigenen Verträgen vorzuziehen, 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 Harbor) ein
angemessenes Schutzniveau nachweisen. Die aktuelle Mitgliederliste wird im Internet veröffentlicht22.
Es empfiehlt sich, die Datenkategorien getrennt nach dem jeweiligen Drittland und den jeweiligen
Empfängern anzugeben.
Auch die im Rahmen des Offshoring in Drittländer übermittelten Daten sind in das Verfahrensverzeichnis
aufzunehmen. Dazu zählt auch eine Datenbank- / Serverbetreuung durch Administratoren anderer
Konzerngesellschaften in Drittländern. Details zur Auftragsdatenverarbeitung sind in Kapitel 5 dargestellt.
2.3.8 ZUGRIFFSBERECHTIGTE PERSONEN
21 Siehe Arbeitsunterlage: Übermittlungen personenbezogener Daten an Drittländer:
Anwendung von Artikel 25 und 26 der Datenschutzrichtlinie der EU (WP12)
22 Link: http://www.export.gov/safeharbor/shlist.nsf/webPages/safe harbor list
Seite 49
Zugriffsberechtigungen auf die Daten von Einzelpersonen bzw. Personengruppen werden über Rollen bzw.
Profile im SAP ERP vergeben und administriert. Die Rollen bzw. Profile erlauben bzw. verwehren i. d. R. über
Berechtigungsobjekte das Lesen oder Ändern von betriebswirtschaftlichen oder technischen Objekten.
Die im SAP ERP-System definierten Rollen bzw. Profile können direkt Personen oder Gruppen 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
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.9 BEISPIEL MELDEREGISTER
Seite 50
Die Aufsichtsbehörden verlangen, die Meldepflicht auf jeden einzelnen Verarbeitungsvorgang zu beziehen.
In folgendem Beispiel für ein Melderegister sind die Vorschläge des Unabhängigen Landeszentrums für
Datenschutz Schleswig-Holstein und weiterer Aufsichtsbehörden als Grundlagen enthalten23.
Wenn man Standardsoftware im Unternehmen einsetzt, sollte man auch auf diese verweisen, da dort ggf.
bestimmte Verfahrensbeschreibungen und Abläufe allgemein zugänglich dokumentiert sind.
23 www.datenschutzzentrum.de und Zusammenstellung im GDD-Praktiker-Workshop
„Das neue BDSG im Betrieb“ vom 1.3.2001, Register 4
Name / Firma verantwortliche Stelle
Inhaber, Vorstände, Leiter DV
Anschrift der verantwortlichen Stelle
Zweckbestimmungen der Datenerhebung,
-verarbeitung oder -nutzung
SAP ERP HCM: Personaladministration, Personalabrechnung, Organisationsmanagement, Zeitwirtschaft,
Personalbeschaffung, Personalbetreuung (Vergütung,
Arbeitgeberleistungen, Altersvorsorge), strategische
Personalplanung
SAP for Healthcare: Patientenmanagement, Patientenabrechnung, klinische Auftragsabwicklung (Partner),
medizinische Dokumentation
SAP EH&S: Gesundheitsdienst, Arbeitsschutz
SAP ERP FI: Pflege und Service für Kunden und
Lieferanten
SAP CRM: Marketingplanung und Kampagnenmanagement, Telemarketing, Kontaktmanagement, Kundenservice Interaction Center, Internet Customer Self-Service,
Servicemanagement, Einsatzplanung
Betroffene Personengruppen und
diesbezügliche Datenkategorien
PERSONEN: Mitarbeiter, Bewerber, Kunden, Lieferanten,
Versicherungsnehmer, Patienten
ÖFFENTLICHER TEIL
Empfänger oder Kategorien von Empfängern
Vertragspartner, Banken, Bausparkassen, Versicherungen, Finanzamt, Krankenkassen, Versorgungsanstalten,
Auftragsdatenverarbeiter
Regelfristen für die Löschung der Daten
Allgemein: Periodische Löschung nach Ablauf der
gesetzlichen Aufbewahrungsfristen
Detailliert:
> unterschiedliche Löschfristen für einzelne
Datenarten
> Frist oder Zeitpunkt für die Überprüfung der
Erforderlichkeit der Datenbestände
Geplante Datenübermittlung in Drittstaaten
Datenkategorien unterteilt nach Drittstaaten und
Empfänger
Seite 51
DATEN: Mitarbeiter-, Bewerber-, Kunden-, Lieferantendaten nach Standard SAP ERP HCM, SAP ERP FI und
SAP CRM;
Besondere Arten personenbezogener Daten nach § 3
Abs.9 BDSG, z. B.:
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
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 MASSNAHMEN
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 Änderungsberechtigungen 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), SECURINFO for SAP (www.securinfo.com), ZRPDINF01 (www.forba.de) oder CheckAud (www.
check-aud.de), die insbesondere zur Analyse von Berechtigungskonzepten eingesetzt werden. Der DSB
sollte sich diesbezüglich mit anderen Abteilungen bzw. der IT in Verbindung setzen, um die Verfügbarkeit
im Unternehmen zu verifizieren.
Seite 52
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
Im Folgenden werden Hinweise gegeben, wie die verantwortliche Stelle dem Datenschutzbeauftragten mit
SAP-technischen Mitteln die erforderlichen Übersichten gemäß BDSG erstellen 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ängigen 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
PA2*
Zeitdaten
PB0*
Stammdaten Bewerber
PB4*
Bewerberdaten
PCL*
Clustertabellen (HCM)
KN*
Kundenstamm
LF*
Lieferantenstamm
SADR* Adressverwaltung
2.4.1 AUSWERTUNGEN ZUR TABELLEN- UND FELDANALYSE
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 oder Felder
bearbeitet werden.
Wir empfehlen, die Berechtigung über den Tabellenzugriff auf die personalwirtschaftlichen Tabellen nur
Sachbearbeitern mit detaillierten HCM-Kenntnissen zu erteilen.
DATEN DES PERSONALWIRTSCHAFTSBEREICHS (HCM / HR)
Im HCM werden die Daten als INFOTYPEN und Infosubtypen verarbeitet. Die Personalstammdaten und
Zeitdaten sind in den Tabellen PAxxxx abgelegt. Eine Tabelle PAxxxx enthält neben 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).
Seite 53
Folgende Reports bieten einen Überblick über die Infotypen:
Infotypen und Subtypen (Report RPDSHOWI) listet die Infotypen und Subtypen mit Angabe 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 Infotyp-Übersicht für einen Mitarbeiter (Report RPLINFC0) die für einen bestimmten
Mitarbeiter belegten Infotypen.
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, Vorsorgeuntersuchungen. Die einzelnen
Verknüpfungsarten bzw. Subtypen sind in Tabelle T778V verzeichnet. Alle Verknüpfungsdaten werden
zentral in der Tabelle HRP1001 abgelegt.
Für einzelne Verknüpfungsarten (vgl. Tabelle T77AR) werden darüber hinaus noch Zusatzdaten in Tabellen
der Form HRPAD* (vgl. Tabelle T77AD) gespeichert.
Eine Darstellung der einzelnen Tabellen (HRP1001, HRPAD*) liefert neben dem ABAP Dictionary auch der
Report RHDDIC00.
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
Seite 54
BENUTZERDATEN 3 (PROTOKOLLDATEN)
Protokolldaten befinden sich u. a. im Accounting, Systemlog (SM21) und in den Protokolldateien.
Die Accountingdaten werden über die Abrechnungsnummern im Benutzerstamm identifiziert.
Die Auswertung des Accounting bzw. der Statistiksätze wird in der Transaktion des Workload Monitors
durchgeführt.
Menüpfad:
Werkzeuge → Administration → Monitor → Performance → Systemlast → Aggregierte
Statistiksätze (ST03N / ST03G) → (STAD)
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 Betriebsbzw. 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 Customizing 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 entsprechenden
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 Strukturname angezeigt wird, ist die zugrunde liegende
Datenbanktabelle über den Verwendungsnachweis zum angezeigten Datenelement zu bestimmen.
In der Systemlogdatei (SM21) wird der Benutzername festgehalten:
Feldname: Benutzer
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 → Datenelemente mit
Auswahl BANKN → Hilfsmittel → Verwendungsnachweis → indirekte Verwendung (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.
Name des Anforderers in der Bestellanforderung
Bewerbernummer
Bewerbernummer
Identifikation des Aufrufers
Disponent
Einkaufsgruppe
Kundennummer
Kontonummer des Lieferanten
Name eines Partners
Seite 55
Wichtige Domänen:
AFNAM
APLNO
APLNR
CATSXT_CALLER_ID
DISPO
EKGRP
KUNNR
LIFNR
NAME
FALNR
PATNR
PERSNO
PERNR
VKGRP
Fallnummer (im IS-H)
Patientennummer (im IS-H)
Personalnummer
Personalnummer
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 ebenfalls Personenbezug haben (Domäne: RI_Rolle).
Um mit Hilfe des Reports RSCRDOMA aus dem Audit Information System ein firmenspezifisches Verfahrensregister zu erhalten, sind die oben genannten personenidentifizierenden Domänen zu überprüfen und
ggf. zu ergänzen (AIS-Funktion: Dateiregister zu personenbezogenen Daten).
Dokumentation von Datenfeldern
Im ABAP Dictionary stehen Funktionen zur Verfügung, um bis auf die Einzelfelder von Tabellen verzweigen
zu können:
> Anzeigen bzw. Drucken von Tabellen und Feldern (auch als Tabellenhandbuch mit RSSDOCTB druckbar)
Menüpfad:
Werkzeuge → ABAP Workbench → Übersicht → Infosystem → ABAP Dictionary → Felder →
Strukturfelder (SE84) P000* Drucken
Seite 56
> Verwendungsnachweis von Tabellen, Datenelementen und Domänen
Über das ABAP Dictionary können Informationen zu Tabellen, Strukturen, Feldnamen, Datenelementen und
Domänen sowie deren Verwendung in Programmen, Dynpros und Tabellen ermittelt werden.
2.4.3 PRÜFUNG DER ZUGRIFFSBERECHTIGUNGEN
Das BENUTZERINFORMATIONSSYSTEM bietet eine maschinelle Unterstützung, um die Zugriffsberechtigungen 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 identifiziert werden. Siehe
hierzu auch Kapitel 4.3 bzw. 6.1.
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 System.
Menüpfad:
Werkzeuge → ABAP Workbench → Entwicklung → Dictionary mit Auswahl Domänen und Objektname
‚PERSNO‘ für Personalnummer → Hilfsmittel → Verwendungsnachweis → indirekte Verwendung
(SE12): verweist z. B. auf DB-Tabellen, Programme oder Dynpros.
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 SUIMBerichtsbaum und im AIS über die Schaltfläche Änderungsbelege aufrufbar (Reports RSUSR100, RSUSR101,
RSUSR102, RSSCD100_PFCG).
Die Protokollanzeige der Zentralen Benutzerpflege kann mit dem Report RSUSRLOG erfolgen.
Gezielte Selektionen zur Analyse eines SAP-Berechtigungskonzeptes können insbesondere 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*.
Seite 57
TAANA TABELLENANALYSE
Mit dem Transktionscode 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ässt
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 gleichem 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 vorhandenen Sätze mit
gleichem 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 Benutzerauswertung)
→ 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
Seite 58
Weitere Reports:
RSUSRSUIM
RHUSERRELATIONS
RSUSR000
RSUSR003
RSUSR005
RSUSR006
RSUSR012
RSUSR060OBJ
RSUSR200
Benutzerinformationssystem
Benutzerzuordnungen anzeigen (für HCM-Berechtigungsobjekte)
Aktive Benutzer
In allen Mandanten die Kennwörter der Standard-Benutzer prüfen
Liste der Benutzer mit kritischen Berechtigungen
Gesperrte Benutzer und Benutzer mit Falschanmeldungen
Suche Berechtigungen, Profile und Benutzer mit bestimmten Objektwerten
Verwendungsnachweis Berechtigungsobjekt in Programmen und Transaktionen
Liste der Benutzer nach Anmeldedatum und Kennwortänderung
Seite 59
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 wesentlichen Umstände des
Umgangs mit seinen Daten zu informieren (§ 4 Abs. 3 BDSG). Soweit diese Information nicht bereits bei der
Datenerhebung erfolgt ist oder Betroffene später weitere Informationen anfordern, besteht die Verpflichtung
der verantwortlichen Stelle zur Benachrichtigung der Betroffenen gem. § 33 BDSG und gem. § 6 Abs. 1 zur
Beachtung der unabdingbaren Rechte des Betroffenen auf Auskunft (§§19, 34 BDSG) sowie auf Berichtigung,
Löschung oder Sperrung (§§ 20, 35 BDSG).
Ausdrücklich hingewiesen sei in diesem Zusammenhang darauf, dass im BDSG eine vorsätzlich oder
fahrlässig nicht erfolgte, nicht richtige oder nicht vollständige Benachrichtigung des Betroffenen eine
Ordnungswidrigkeit darstellt. Diese kann mit einer Geldbuße bis zu EUR 25.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 Satz 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 Satz 2 BDSG wieder. Hier ist der Beauftragte für den Datenschutz zuständig,
jedermann – auf Antrag – die Angaben gem. § 4e Satz 1 Nr. 1-8 BDSG in geeigneter Weise verfügbar zu
machen.
Zusammenfassend ist festzuhalten, dass das Informations- und Transparenzgebot von der verantwortlichen
Stelle, dem Beauftragten für den Datenschutz und der Aufsichtsbehörde zu gewährleisten ist.
Allerdings sind 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 Auskunftsrecht,
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 erhoben, 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.
Seite 60
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 Benachrichtigungspflicht 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).
3.1.2 SAP-FAKTEN
Es gibt im SAP-Standard keinen Report, der sozusagen auf Knopfdruck alle zu einer Person gespeicherten
Daten für die Auskunftserteilung oder zur Benachrichtigung 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.1),
wobei die Funktionalitäten im Rahmen der Übersichten (Dateiregister24 zu personenbezogenen Daten)
grundsätzliche Informationen über die verwendeten Tabellen / Domänen mit Personenbezug liefern.
Für SAP ERP HCM (Personalwirtschaft) steht die Funktion „Infotypübersicht für einen Mitarbeiter“ zur
Verfügung (Personal → Personalmanagement → Administration → Personalstamm → Anzeigen), mit der
alle für einen Mitarbeiter tatsächlich belegten Infotypen angezeigt werden. Mit der entsprechenden
Transaktion des SAP ERP HCM (PA20, ‚Personalstammdaten anzeigen’) können im zweiten Schritt die Daten
der belegten Infotypen für eine Auskunftserteilung ausgedruckt werden25.
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 Daten. Dabei sind dem
Betroffenen die konkreten Daten in verständlicher Form mitzuteilen.
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 nachzukommen26, 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 Auskunftsersuchen
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 Auskunft 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 Betroffenen
aufgrund seiner Rolle enthalten sein können.
24 Eine Anpassung der Terminologie an die aktuelle Rechtslage des BDSG durch die SAP steht bislang aus.
25 Hierzu steht auch eine allgemein verfügbare Auswertung (Z_RPDINF001) zur kostenlosen Bestellung
unter www.forba.de zur Verfügung
Seite 61
Extraktion der Daten aus dem System: Da es für diesen Schritt (mit Ausnahme der o. a. geschilderten
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:
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 verweisen (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 Browser (Transaktion SE17) eine Datenanzeige für alle der Auskunft unterliegenden Datenfelder 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 Volltext 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 bestimmen, 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 entfernen, wenn die Hardcopys im Original
weitergegeben werden sollen. Einschlägige Anzeigetransaktionen 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, sodass man,
je nach Anfrage des Betroffenen, ggf. nacharbeiten muss.
Seite 62
ÜBER QUERYS
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 Tabellen und Datenfelder bei
der Erstellung einschlägiger Sachgebiete ermittelt wurden.
26 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.
FAZIT:
> Alle aufgezeigten Möglichkeiten sind – außer im SAP ERP HCM – recht arbeitsaufwendig, sodass 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 oder Stellen, an
die die Daten übermittelt werden. Diese Angaben können u. U. dem Verfahrensverzeichnis gemäß § 4d
BDSG entnommen und müssen der Auskunft beigefügt werden. Zuletzt ist der datenschutzgerechte
Versand der erstellten Dokumente zu organisieren.
Je nach Query-Werkzeug (SAP-Query, Ad-hoc-Query und Qick-Viewer) sind unterschiedliche 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 unterschiedliche Berechtigungen für das Ausführen der Query-Funktion
benötigt. Bei Auswahl oder der Auswahlmöglichkeit von Tabellen oder Tabellen-Joins / Views sind Tabellenberechtigungen (Berechtigungsobjekt: S_TABU_DIS) erforderlich.
Queries müssen als kritische Berechtigung eingestuft werden, da die Tabellenberechtigungsgruppen
regelmäßig nicht detailliert auf das Kundensystem und die Sicherheitsanforderungen des Kunden
abgestimmt sind, Sie sind durch vordefinierte Reports, die in Transaktionen umgesetzt werden, zu
ersetzen. Davon kann abgesehen werden, wenn es ein detailliertes und dokumentiertes Berechtigungskonzept für Tabellen gibt, das auf Datensatz- / Datenfeldebene die Risiken bewertet.
3.2 BERICHTIGUNG, LÖSCHUNG UND SPERRUNG
3.2.1 RECHTLICHE ANFORDERUNGEN
Die verantwortliche Stelle hat gemäß §§ 20 bzw. 35 BDSG personenbezogene Daten von Betroffenen zu
berichtigen, wenn sie unrichtig sind. Ggf. sind Daten zu löschen; z. B. dann, wenn ihre Speicherung
unzulässig ist. In gewissen Fällen tritt an die Stelle einer Löschung die Sperrung der personenbezogenen
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. Sperrungsanspruch?
> Welches Verfahren ist bei Rücksicherungen / Sicherungskopien vorgesehen, wenn gesperrte 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 Definition der Zeitbindung der
Infotypen in der Tabelle T582A)?
Seite 63
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. Infotyp 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.
Allerdings bietet das SAP ERP-System hinsichtlich der Berichtigung von Daten in den verschiedenen
Anwendungsmodulen die Möglichkeit, mit den Standard-Pflegetransaktionen unrichtige 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, beschränkt – auch wenn alle
buchhalterischen Abschlusstätigkeiten erledigt sind.
Auch die Löschung von Daten kann mit dieser Pflegetransaktion vorgenommen werden, wobei darauf zu
achten ist, dass eine tatsächliche Löschung erst mit der physischen Reorganisation der Datenbank erfolgt
(eventuell ist der kritisierte Dateninhalt noch in Protokollen vorhanden). Die unrichtigen Daten sind
außerdem nach wie vor Bestandteil des Änderungsprotokolls für Infotypen, der mit dem Report RPUAUD00
angezeigt werden kann.
Explizite Funktionen zur Sperrung von Daten einzelner Personen sind im SAP ERP-System z. Zt. 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 gesamten 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 Archivierungskonzeptes wie
auch eines Datenlöschungskonzeptes einzubeziehen und organisatorische Vorkehrungen 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 organisatorisches 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?
Seite 64
Diese Anforderungen an die Organisation des Datenschutzes lassen sich auch im GRC Process Control
(kostenpflichtige Komponente, vgl. Kap. 6) abbilden. Es besteht die Möglichkeit, Prozesse (wie z. B. zur
Seite 65
fristgerechten Löschung von Daten, Reorganisation der DB) zu definieren / 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 Verarbeitung personenbezogener Daten und deren Prüfungen behandelt. Die Anforderungen sind allgemein, d. h. insbesondere
auch bei der Verarbeitung außerhalb des Geltungsbereichs nationaler Gesetze, zu erfüllen.
Diese Vorschriften beziehen sich nicht alleine auf Produktivsysteme, sondern auch auf vorgelagerte
Systeme, soweit dort personenbezogene Daten zugreifbar sind oder dort Einstellungen vorbereitet werden,
die später in die Produktionsumgebung transportiert werden.
Aufgrund 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 (Ziffer 7: Verfügbarkeitskontrolle) und die andererseits die
Zweckbindung der Verarbeitung gewährleisten (Ziffer 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 gewä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 organisatorischen als auch auf der technischen Ebene
greifen. Die Maßnahmen sollen unzulässige und zweckwidrige Verarbeitung personenbezogener Daten
verhindern und − soweit erforderlich / 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 organisatorische Maßnahmen
fehlen. Beispielhaft für einen solchen Fall kann die fehlende organisatorische Umsetzung der Möglichkeiten
des SAP-Berechtigungskonzeptes sein, die trotz der vielfältigen Schutzmöglichkeiten keinen solchen bietet,
etwa weil viele Anwender mit umfassenden Berechtigungen ausgestattet wurden. Ebenso wirkungslos
können vielfach organisatorische 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
Seite 66
Die nachfolgende Abbildung listet in der linken Spalte die acht Anforderungen aus der Anlage zu § 9 BDSG
auf und stellt in der mittleren Spalte ausgewählte Ansatzpunkte zur Umsetzung der Anforderungen im SAP
ERP-System daneben. Es folgen in der rechten Spalte Hinweise auf weiterführende Literatur zu diesem
Thema.
ANSATZPUNKTE AUFSEITEN
DES SAP ERP-SYSTEMS
1) den Unbefugten der Zutritt zu
Datenverarbeitungsanlagen, mit
denen personenbezogene Daten
verarbeitet oder genutzt werden,
zu verwehren
(ZUTRITTSKONTROLLE)
nicht einschlägig und deshalb
keine Unterstützung seitens der
SAP-Software
2) zu verhindern, dass Datenverarbeitungssysteme von Unbefugten genutzt werden können
(ZUGANGSKONTROLLE)
personenbezogenes Anmeldeverfahren (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 SAP NetWeaver und SAP
ERP Central Component
Sicherheitsleitfäden27
Auto-Logoff nach einer
vorgegebenen Zeit;
Bildschirmschoner mit Kennwortschutz;
SAP NetWeaver
Sicherheitsleitfaden
Single-Sign-On-Ergänzung und
Anschlussmöglichkeiten für
Chipkarten
SAP NetWeaver
innerhalb des SAP NetWeaver
mit Hilfe eines angepassten Berechtigungskonzeptes für den
ABAP-Stack und den JAVAStack, welches den Anforderungen von SAP, des Revisionsleitfadens und des Datenschutzes
gerecht wird;
außerhalb des SAP NetWeaver:
Verschlüsselung im Netz, restriktive Vergabe von Berechtigungen
auf SAP-Dateien und Tabellen auf
der Ebene der Datenbank und
des Betriebssystems;
SAP-Dokumentation
SAP-NetWeaver (help.sap.com)
Download
Frank Off / Mario Linkies,
„Sicherheit und Berechtigungen
in SAP Systemen“, Gallileo
Verlag 2005
DSAG Prüfleitfaden FISAP
NetWeaver Sicherheitsleitfaden
SAP GRC Access Control:
Analyse und Administration
von SAP-Berechtigungskonzepten (siehe Kapitel 6)
SAP-Hinweise 28777 und
210733
27 Die Sicherheitsleitfäden stehen unter help.sap.com zur Verfügung, Suchbegriff „Sicherheitsleitfäden“
unter SAP ERP Central Component und SAP NetWeaver
Seite 67
3) zu gewährleisten, dass die zur
Benutzung eines Datenverarbeitungssystems Berechtigten ausschließlich auf die ihrer Zugriffsberechtigung unterliegenden
Daten zugreifen können und dass
personenbezogene Daten bei der
Verarbeitung, Nutzung und nach
der Speicherung nicht unbefugt
gelesen, kopiert, verändert oder
entfernt werden können
(ZUGRIFFSKONTROLLE)
WEITERFÜHRENDE HINWEISE
ZIELE DER GESETZLICHEN
ANFORDERUNGEN:
Es ist laut Anlage zu § 9 BDSG
4 Umsetzung der Anforderungen aus §9 BDSG und Anlage:
technisch-organisatorische Maßnahmen
ZIELE DER GESETZLICHEN
ANFORDERUNGEN:
Es ist laut Anlage zu § 9 BDSG
ANSATZPUNKTE AUFSEITEN
DES SAP ERP-SYSTEMS
WEITERFÜHRENDE HINWEISE
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)
innerhalb des SAP ERP mit Hilfe
eines angepassten Berechtigungskonzeptes für ABAP und
JAVA;
außerhalb des SAP Systems:
Verschlüsselung im Netz
(LAN / WAN) und auf sonstigen
Datenträgern;
zur Downloadfunktion und zum
XXL-Listviewer siehe Ziffer 3.
Bei Internet-Anbindung:
Firewall-Konzept und SAPRouter;
Einstellungen der Berechtigungen;
SAP-Systemdokumentation
5) zu gewährleisten, dass
nachträglich überprüft und
festgestellt werden kann, OB UND
VON WEM personenbezogene
Daten in Datenverarbeitungssysteme eingegeben, VERÄNDERT
ODER ENTFERNT worden sind
(EINGABEKONTROLLE)
durchgängig in allen Modulen,
bei allen SAP-Objekten und bei
allen Daten mit automatischer
Erfassung von Erfasser / Änderer,
Datum und Uhrzeit realisiert;
in den einzelnen Modulen stehen
neben den Anzeigetransaktionen
z. T. zusätzliche Reports für die
Anzeige von Änderungsbelegen
zur Verfügung;
ggf. Konfiguration der zu
schreibenden Änderungsbelege
SAP-Systemdokumentation,
SAP-Sicherheitsleitfäden
Im Standard ist keine besondere
Unterstützung vorgesehen.
Die Kontrolle der Auftragsdatenverabeitung kann durch den
Einsatz der SAP GRC Process
Control (zusätzliche Software)
detailliert geplant, dokumentiert
und ausgewertet werden.
vgl. Kapitel 5.2.2 und 5.2.6
dieses Leitfadens
Seite 68
6) zu GEWÄHRLEISTEN, dass
personenbezogene Daten, die im
Auftrag verarbeitet werden, nur
entsprechend den Weisungen des
Auftraggebers verarbeitet werden
können
(AUFTRAGSKONTROLLE)
der geforderte Nachweis gem.
§10 Abs.4 BDSG wird nicht
unterstützt.
SAP NetWeaver
ggf. Stichproben über Trace
Funktionen zur Anzeige der
Änderungsbelege in den
jeweiligen Fachfunktionen
Empfehlungen der SAPSicherheitsleitfäden
GRC Process Control (siehe
Kapitel 6)
SAP-Systemdokumentation
siehe die allgemeinen Empfehlungen der SAP-Sicherheitsleitfäden bzgl. Datensicherung
8) ZU GEWÄHRLEISTEN, DASS
ZU UNTERSCHIEDLICHEN
ZWECKEN ERHOBENE DATEN
GETRENNT VERARBEITET
WERDEN KÖNNEN.
Realisierung über Trennung der
Systeme der Mandanten;
innerhalb eines Mandanten durch
entsprechende Einrichtung des
Berechtigungskonzeptes, insbesondere hinsichtlich der Anzeige
und Auswertung der Daten.
Innerhalb eines Mandanten ist
sicherzustellen, dass Zugriffe auf
die personenbezogenen Daten
außerhalb 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 Verhaltensauswertungen führen. Insbesondere
kostenrechnungsrelevante und
produktionsbezogene Daten sind
besonders zu betrachten.
vgl. Prüfleitfäden des DSAG AK
Revision und Dokumentation
Empfehlungen der SAP-Sicherheitsleitfäden
regelmäßige Datensicherung auf
der Ebene der Datenbank;
Datensicherungskonzept
an die Aufgaben angepasste
Berechtigungen;
Protokollierung der wichtigsten
Datenänderungen;
angemessene Schulung der
Anwender
Seite 69
7) zu gewährleisten, dass personenbezogene Daten gegen zufällige Zerstörung oder Verlust
geschützt sind
(Verfügbarkeitskontrolle)
4.2 SAP-FAKTEN, RISIKEN UND MASSNAHMEN
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-Sicherheitsmaßnahmen
treten müssen. Dies trifft im besonderen Maße auch für die § 9-Maßnahmen, nämlich die Authentifizierung
der Benutzer, die Autorisierung und die Protokollierung zu. Die folgende Abbildung verdeutlicht diese
Parallelität insbesondere für die Berechtigungsprüfungen:
Presentation Layer
JAVA
ABAP
Web
Dynpro
Web
Dynpro
Business Layer
FM /
BAPI
EJB
JCo
Persistence
Open
SQL
Open
SQL
ABAP-Schema
JAVA-Schema
recommended
Connectivity between
ABAP and JAVA
NOT recommended
Connectivity between
ABAP and JAVA
Business relevant
authority check based
on ABAP roles
Business relevant
authority check based
on UME roles
THE BEST-RUN BUSINESSES RUN SAP
Seite 70
© SAP AG 2004, RFC Sicherheit/[email protected]/32
4.2.1 ABAP-FAKTEN, RISIKEN UND MASSNAHMEN
Die Abbildung verdeutlicht, dass Zugriffe von der JAVA-Präsentationsschicht (links) auf die ABAP-Daten
über die ABAP-Berechtigungsprüfungen (rechts) umgeleitet werden können. Dies ist typischerweise bei
Zugriffen auf die ABAP-Daten über ein Portal der Fall. Folgender Fall soll die rechtliche Relevanz verdeutlichen: Im Portal können etwa über iViews auf dieser Ebene Verknüpfungen von zwei separaten 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 Personaldaten zweier
Firmen wäre jedoch rechtlich anders zu beurteilen und nicht mehr durch ein reines Auftragsdatenverhältnis
zweier Firmen an einen gemeinsamen Dienstleister gedeckt.
Auf der JAVA-Ebene können jedoch auch eigene Datenbestände verwaltet werden, für die auch auf JAVAEbene adäquate Berechtigungsprüfungen im Sinne der Ziffern 2 − 4 der Anlage zu § 9 BDSG vorgesehen
werden müssen (dies betrifft den linken Zweig von der JAVA-Präsentationsebene über den Business Layer
und die Persistenzschicht auf das JAVA-Schema).
Das nachfolgende Kapitel 4.2.1 befasst sich mit den ABAP-spezifischen § 9-Maßnahmen. Zu einem späteren
Zeitpunkt ist ein separater NetWeaver-JAVA-Leitfaden vorgesehen, der sich mit den JAVA-spezifischen
technisch-organisatorischen Maßnahmen beschäftigen soll.
4.2.1.1 IDENTIFIZIERUNG UND AUTHENTIFIZIERUNG
4.2.1.1.1 SAP-FAKTEN
Bevor ein SAP ERP-Benutzer auf die Informationen und Funktionen im ERP-System zugreifen 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 System 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) 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 Erfahrungswerte. Dabei ist zu
beachten, dass die Parameter-Werte in Abhängigkeit von der Sicherheitspolitik in jedem Unternehmen
durchaus unterschiedlich definiert werden können.
Seite 71
> 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 6.
> ZUSAMMENSETZUNG DES KENNWORTES
Die Parameter login / min_password_letters, login / min_password_digits, und login / min_password_
specials erlauben bis einschließlich SAP NetWeaver 6.40 eine Festlegung 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: „1“ (Die Mindestanzahl von Zeichen, Ziffern und
>
>
>
>
>
>
>
>
Seite 72
>
Sonderzeichen beträgt 1 Stelle.) ACHTUNG: bei internationalen Installationen ist wegen der unterschiedlichen Tastaturbelegungen ggf. auf die Anforderung an ein Sonderzeichen zu verzichten.
MINDESTANZAHL KLEINER UND / ODER GROSSER 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 login / 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 vergangenen
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 login / password_history_size die Kennworthistorie auf
eine Übereinstimmung mit den letzten 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 login / 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: „3“
KOMPATIBILITÄT EINES KENNWORTES ZU EINER GEÄNDERTEN KENNWORTREGEL
Ab SAP NetWeaver 6.40 kann mit dem Parameter login / password_compliance_to_current_policy
festgelegt werden, dass ein in Gebrauch befindliches 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 Kennwortwechsel bei
Dialoganmeldung und ITS-Services, die die Flowlogic verwenden.
Empfohlener Parameter-Wert: „90“ oder weniger.
(Nach maximal 90 Tagen muss der Benutzer 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 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: „8“
VERBOTENE KENNWÖRTER
Über die genannten Einstellungen hinaus können in der Tabelle USR40 Kennwörter definiert werden, die
von der Benutzung ausgeschlossen werden (z. B. Ausschluss von Trivialkennwörtern oder
Tastaturkombinationen).
> WEITERE ANMELDEVARIANTEN
Je nach Releasestand gibt es neben der kennwortbasierten Anmeldung weitere Anmeldevarianten,
wie z. B.:
> Zertifikationsanmeldungen über den Browser und den Webserver
> SAP-Anmeldeticket (z. B. bei Nutzung des SAP NetWeaver Portals)
> NT-Domainanmeldung (NTLM)
> PAS (Pluggable Authentication Services)
> Single Sign On
> BEENDEN DER SAP-SITZUNG
Der Parameter login / fails_to_session_end steuert, nach wie vielen Fehlversuchen der Anmeldung 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 gesperrt.)
> 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 entsperrt.
Empfohlener Parameter-Wert: „0“ (Es erfolgt kein automatisches Entsperren um Mitternacht.)
> 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 gehen nicht gespeicherte Daten
verloren, sodass 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 SAPfremder Bildschirmschutz mit Kennwort normalerweise nach 15 Minuten aktiviert werden.)
Seite 73
Wie der Vorgang der Anmeldung am System durch Parameter gesteuert wird, ist auch die Berechtigungsprüfung bei der Arbeit mit dem SAP ERP-System von der Einstellung in Profilparametern 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 unterdrü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 Berechtigungsprüfungen deaktiviert wurden.
Hierzu kann die Tabelle USOBX_C und das Vorgehen gemäß Kapitel 4.2.1.5.5 verwendet werden.
> Berechtigungsprüfung bei RFC
Durch den Parameter auth / rfc_authority_check wird festgelegt, ob Berechtigungsprüfungen bzgl.
Remote Function Call (RFC) gegen das Berechtigungsobjekt S_RFC erfolgen.
Empfohlener Parameter-Wert: „1“ (Die Berechtigungsprüfung für RFC ist aktiv.)
> BERECHTIGUNGSPRÜFUNG ZU ABAP-SPRACHELEMENTEN
Durch den Parameter auth / system_access_check_off können automatische Berechtigungsprüfungen
bei bestimmten ABAP-Sprachelementen ausgeschaltet werden. Diese Sprachelemente sind z. B. Dateioperationen, Aufruf von Kernelfunktionen oder CPIC-Aufrufe.
Empfohlener Parameter-Wert: „0“ (Die Berechtigungsprüfung zu ABAP-Sprachelementen ist aktiv.)
4.2.1.1.2 RISIKEN UND ZU ERGREIFENDE MASSNAHMEN
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 Instrumente 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 Hilfe 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 ERPSystem eingebunden ist – weitere und auch externe Sicherheitsprodukte empfehlenswert. Solche sind
z. B. SNC (Secure Network Communications – Authentication) oder bei der Verwendung von WebFrontends sogenannte X.509 Client Certificates. Für SNC steht auf dem Service-Marktplatz
( http://www.service.sap.com/swdc ) → Download → SAP Cryptographic 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.
4.2.1.2.1 SAP*
Seite 74
Der Benutzer SAP* ist der von SAP fest codierte Initialuser und somit für die Installationsphase mit allen
Rechten ausgestattet. Nach erstmaliger Anmeldung (Initialkennwort vgl. SAP NetWeaver Sicherheitsleitfaden) im SAP-System muss ein neuer Benutzer (eindeutige namentliche Zuordnung) mit umfassenden
Berechtigungen angelegt werden, der für die weiteren 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 Benutzerstammsatz 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. Weiterhin sollte SAP* der Benutzergruppe „SUPER“ zugeordnet werden, um zu verhindern, dass dieser User leichtfertig gelöscht werden kann.
4.2.1.2.2 SAPCPIC
Der Benutzer SAPCPIC ist ein eingerichteter Standarduser der SAP. Er kann nicht zur Anmeldung im Dialog
verwendet werden, erlaubt aber den Aufruf einiger Programme und Funktionsbausteine im SAP ERPSystem. 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.
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.
Werden die vorgenannten Maßnahmen nicht ergriffen, kann eine Neuanmeldung über folgenden 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.
4.2.1.2.3 DDIC
Neben SAP* ist der Benutzer DDIC durch SAP definiert. Der Benutzer DDIC wird für die Pflege des ABAP
Dictionary und der Softwarelogistik verwendet. Daher sind auch für diesen Benutzer weitreichende Systemrechte hinterlegt, die über die in Benutzerprofilen definierten Rechte hinausgehen.
DDIC wird im Rahmen der Installation nur in den Mandanten 000 und 001 erstellt (Initialkennwort vgl. SAP
NetWeaver Sicherheitsleitfaden). Für andere Mandanten muss der Benutzer 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 Aktivitäten.
Auch für den Benutzer DDIC ist das Profil SAP_ALL aus Datenschutzsicht nicht zulässig. Zur Ausübung der
erforderlichen Aktivitäten (z. B. Starten und Stoppen von Tasks im Rahmen des Systemmonitorings) 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 Upgrades, für die Softwarelogistik
und das ABAP Dictionary benötigt. Das Löschen von DDIC führt zu Funktionsverlusten in diesen Bereichen.
4.2.1.2.4 EARLYWATCH
Seite 75
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 EarlyWatch-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 Nutzung dieses Benutzers vorgesehen sind.
4.2.1.2.5 BATCH USER
Batch User sind grundsätzlich als technische User einzurichten. Sie sind sämtlichen relevanten 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 begegnen, sind
spezielle technische und organisatorische Maßnahmen zu ergreifen, über die sichergestellt ist, dass eine
unberechtigte Kenntnisnahme, bzw. versehentliche / absichtliche Manipulation von Daten unterbunden wird.
Dies gilt auch und vor allem in Bezug auf Sonderbenutzer.
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
> 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.
4.2.1.3.1 BERECHTIGUNGSOBJEKTE IM HCM
Seite 76
Das Berechtigungsobjekt P_ORGIN (HR: Stammdaten) wird im Rahmen der Berechtigungsprüfung für
Personaldaten (Stamm- und Zeitdaten) verwendet. Eine Prüfung findet grundsätzlich statt, wenn HR-Infotypen bearbeitet werden sollen. Wesentlich sind hierbei die organisatorische Zuordnung des Mitarbeiterstammes, die Sicht auf Daten (Infotypen) und der Berechtigungslevel.
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 Dokumentation 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 direkt 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
> P_ORGXX
HR: stammdatenerweiterte Prüfung
> P_ORGXXCON
HR: stammdatenerweiterte Prüfung mit Kontext
> 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 T77UA. 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 (Personalstamm pflegen), erforderlich.
Außerdem ist zu berücksichtigen, dass ggf. weitere Berechtigungsobjekte (bspw. HR: Bewerber oder FI:
Reiseplanung) zu Prüfzwecken herangezogen werden sollten (für weitere Details siehe Dokumentation der
SAP-Berechtigungsobjekte).
4.2.1.3.2 BERECHTIGUNGSOBJEKT P_ABAP
Seite 77
Für den Schutz des Zugriffs auf Reports sind in SAP zwei Berechtigungsobjekte vorgesehen. Zum einen das
Objekt S_PROGRAM (ABAP: Programmablaufprüfungen, Objektklasse BC_C) und zum anderen das Objekt
HR: Reporting P_ABAP.
Über das Objekt S_PROGRAM wird zunächst grundsätzlich gesteuert, ob und auf welche Reports zugegriffen werden kann, sofern der Benutzer eine Zugriffsberechtigung zu der Berechtigungsgruppe des Reports
(siehe unten unter Kapitel 4.2.1.5.4) besitzt. Über das Objekt P_ABAP wird gesteuert, auf welche Weise die
Objekte:
> HR: Stammdaten (P_ORGIN)
> HR: stammdatenerweiterte Prüfung – (P_ORGXX)
> strukturelle Berechtigungsprüfung in spezifischen Reports
zur Prüfung der Berechtigungen für HCM-Infotypen verwendet werden. Durch eine entsprechende Aussteuerung der Felder:
> REPID (Reportname)
> COARS (Vereinfachungsgrad der Berechtigungsprüfung)
können v. a. Infotypberechtigungen übersteuert, d. h. aus der Prüfung herausgenommen werden.
Hintergrund für die Erstellung dieses Berechtigungsobjektes durch die SAP ist eine erhöhte Verarbeitungs-
geschwindigkeit durch die „Ausschaltung“ von weiteren Berechtigungsprüfungen.
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.
4.2.1.3.3 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 jeder HCM-Transaktion genutzt wird, sodass zusätzlich
das Objekt S_TCODE verwendet werden muss.
Als Anhaltspunkt, welche Transaktionen über die Ausprägung des Objektes P_TCODE geschü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.
4.2.1.3.4 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 Berechtigungsobjekt ist das Feld Transaktionscode (TCD) definiert.
Durch eine funktionsbezogene Ausprägung dieses Berechtigungsobjektes ist es somit auf einer ersten
Stufe möglich, Zugriffschutzmaßnahmen abzubilden. Sofern eine differenzierte Ausprägung dieses Objektes
nicht vorgenommen wird, werden im weiteren Verlauf von Berechtigungsprü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 dass eine Prüfung auf eine entsprechende Berechtigung erfolgt.
Dies kann über die in Abschnitt 4.2.1.5.4 beschriebenen Schutzmaßnahmen verhindert werden.
Die Transaktion sub % sollte nicht an Benutzer vergeben werden. Mit dieser Transaktion lassen 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.
4.2.1.3.5 TABELLE TSTCA
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 werden, den
Mechanismen des CTS / CTO (Change Transport System / Change Transport Organizer).
Seite 78
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
4.2.1.3.6 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 durchnummeriert (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.
a Aus datenschutzrechtlicher Sicht ist in diesem Zusammenhang eine Konzeption zum Schutz der
einzelnen Reports zu erarbeiten (Berechtigungskonzept S_PROGRAM, Verwaltungsreport RSCSAUTH)
und
b zu hinterfragen, ob und inwieweit über die dargestellten Möglichkeiten ggf. Berechtigungsprüfungen
unterlaufen werden können.
Objekte ausgeschaltet werden, dies gilt aber nicht für HCM und Basisobjekte.
Zu beachten ist, dass Zugriffsberechtigungsprüfungen umgangen werden können, indem der AuthorityCheck (Berechtigungsprüfung) in den der Transaktion zugrunde liegenden ABAP-Programmen ausgeschaltet wird.
Berechtigungen für die Transaktionen SA38 (ABAP Programmausführung) und SE38 (ABAP Editor) 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 Benutzermenü zu ermöglichen (Berechtigungsobjekt S_TCODE).
4.2.1.3.7 BERECHTIGUNGSOBJEKT S_TABU_DIS, 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 Berechtigungsobjekt S_TABU_CLI ist der Zugriff
auf die mandantenübergreifende Tabellenpflege gesteuert. Zusätzlich zu einer entsprechenden Ausprägung
dieser genannten Objekte sind Transaktionsberechtigungen zur Tabellenpflege (vgl. S_TCODE) erforderlich.
Das Berechtigungsobjekt S_TABU_DIS besteht aus den Feldern Aktivität und Berechtigungsgruppe. Über
die Ausprägung des Feldes Aktivität kann die Art des Zugriffs auf Tabellen (anzeigen oder ändern) gesteuert
werden. Das Feld Berechtigungsgruppe dient zur Einschränkung des Zugriffs auf bestimmte Tabellen.
Das Berechtigungsobjekt S_TABU_CLI besteht aus dem Feld Kennzeichen für mandantenunabhängige
Pflege.
Seite 79
Das Berechtigungsobjekt S_TABU_LIN definiert Berechtigungen für die Anzeige oder Pflege 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 →
Zeilenbezogene Berechtigungen → Organisationskriterien definieren) definiert.
Eine Berechtigung auf Zeilenebene wirkt nur dann, wenn das zugehörige Organisationskriterium im
betreffenden Mandanten eingeschaltet ist (Basis → Systemadministration → Benutzer und Berechtigungen
→ Zeilenbezogene Berechtigungen → Organisationskriterien aktivieren).
An dieser Stelle wird empfohlen, die Transaktionen SE16 / SE17 nur sehr eingeschränkt an Benutzer zu
vergeben.
Falls eine Vergabe erfolgt, ist aus datenschutzrechtlicher Sicht darauf zu achten, dass zur Vermeidung eines
unzulässigen Zugriffs auf personenbezogene Daten mittels der Tabellenanzeige SE16 / SE17 auf eine
restriktive Vergabe des Zugriffs auf Berechtigungsgruppen solcher Tabellen (z. B. den Infotypen in den PATabellen) geachtet wird.
Eine Zuordnung von Tabellen zu Berechtigungsgruppen kann über die Transaktion SE17 und Angabe der
Tabelle TDDAT abgerufen werden.
4.2.1.3.8 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 Monitoring-Tools dienen.
Dabei enthält dieses Objekt ein Feld (AUTH), über das Berechtigungsnamen vergeben werden 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 Berechtigung
besonders zu beachten.
4.2.1.3.9 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), Änderungsbelege und -objekte zu pflegen
(= zu verändern) bzw. zu löschen und somit direkten Einfluss auf die Protokollierung zu nehmen.
Die Mitbestimmungsrechte der Arbeitnehmervertretung sind bei der Vergabe der Berechtigung zum
Anzeigen der Änderungsbelege besonders zu beachten.
4.2.1.3.10 OBJEKTE ZUR BENUTZER- UND BERECHTIGUNGSPFLEGE (S_USER_XXX)
Seite 80
Die Berechtigungsobjekte zur Benutzer- und Berechtigungspflege (vgl. im Einzelnen unter Kapitel 4.2.1.6.1)
erlauben eine differenzierte Gestaltung des Prozesses der Benutzereinrichtung, -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 Zugriff bekommen, die hierzu
autorisiert werden sollen.
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 weitere Berechtigungsprü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.
4.2.1.3.11 BERECHTIGUNGSOBJEKT S_GUI UND XXL-LISTVIEWER
Seite 81
Um dem Risiko eines unberechtigten Zugriffs auf personenbezogene Datenbestände vorzubeugen, ist es
erforderlich, über die Ausprägung der vorgenannten Berechtigungsobjekte sicherzustellen, dass lediglich
die Daten gelesen bzw. gepflegt werden können, die im Aufgabengebiet des entsprechenden Arbeitsplatzes
liegen.
Beim Einsatz von HCM ist somit über eine entsprechende Ausprägung des Benutzerberechtigungskonzeptes sicherzustellen, dass der Zugriff auf die o. g. Objekte sowie alle anderen Objekte der Klasse Personalwesen restriktiv und unter Funktionstrennungsgesichtspunkten erfolgt. 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 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 funktionsbezogenen Zugriff auf
Daten ermöglicht
> Zweckentfremdung der Daten über Download und / oder XXL-Listviewer und anschließende Verarbeitung
zu datenschutzrechtlich nicht zulässigen Zwecken sowie unter unzulässigen Bedingungen (wie etwa
mangelnder Prüfbarkeit) ausgeschlossen wird
> Tabellenanzeige- und -pflegeberechtigungen über die Ausprägung des Feldes Berechtigungsgruppe
hinreichend eingeschränkt werden
> der Zugriff bzgl. Änderungsmöglichkeiten zu Transaktionen und Programmen äußerst restriktiv
gehandhabt bzw. durch organisatorische Regeln unterbunden wird (inkl. Erstellung einer Organisationsanweisung bzgl. der Verfahrensdokumentation bei durchzuführenden Pflegemaßnahmen)
> das Löschen von Änderungsbelegen grundsätzlich im Produktivsystem (Ausnahme Notfall-User)
unterbunden wird bzw. nur durch die vorgesehenen Archivierungs- bzw. Reorganisationsprogramme
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 aufeinander abgestimmt
sind
Sollte aufgrund der vorhandenen Personalstärke eine differenzierte, an Funktionstrennungsgesichtspunkten orientierte Ausprägung verschiedener vorgenannter 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önnen, sind sog.
Systemadministratoren einzurichten. Diese verfügen dabei naturgemäß über weitreichende Berechtigungen.
SAP sieht hierzu im Standard i. d. R. zur Nutzung im Testsystem 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 umfassenden
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.
4.2.1.4.1 PROFIL SAP_ALL
Mit diesem Profil sind nahezu uneingeschränkte Zugriffe auf das gesamte System (inkl. Anwendungen)
möglich. Dies beinhaltet v. a. auch den Zugriff auf die Werkzeuge der Anwendungsentwicklung. Somit kann
bei der Nutzung verschiedener, in diesem Profil enthaltener Berechtigungen die BDSG-konforme Datenspeicherung und -verarbeitung genauso gefährdet werden wie die Ordnungsmäßigkeit der Buchführung.
Das Profil kann bei Bedarf vom Kunden neu erzeugt werden.
4.2.1.4.2 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 releasebezogen 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 Anwender zugeordnet werden.
4.2.1.4.3 PROFIL P_BAS_ALL
Seite 82
Auch für den Bereich HCM werden seitens SAP Standardprofile für ein Testsystem ausgeliefert. Über das
Profil P_BAS_ALL (Alle Berechtigungen für Personendaten) ist ein umfassender Zugriff auf personenbezo-
4.2.1.4.4 SONSTIGE S_XXX-PROFILE
Nachfolgend genannte Profile stellen auch lediglich Muster dar. Grundsätzlich ist es erforderlich, die in
diesen Profilen vorliegende Ausprägung der einzelnen Berechtigungsobjekte funktionsbezogen 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 Benutzeradministration enthalten.
S_A.ADMIN
Dieses für den Systemoperator vorgesehene Profil beinhaltet die Berechtigungen zur
Anwendungsentwicklung, zur Administration 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.
gene Daten möglich. Darüber hinaus können auch über die Funktionalitäten der allgemeinen Tabellenanzeige Inhalte aus anderen Anwendungen angezeigt werden. Dieses Profil sollte in Produktivsystemen nicht
verwendet werden.
4.2.1.4.5 ROLLEN MIT KRITISCHEN BERECHTIGUNGEN
Rollen können über das Benutzerinformationssystem (Transaktion SUIM28) nach verschiedenen Kriterien
analysiert werden, z. B:
‚Rollen’ → ‚nach Berechtigungsobjekt’ (z. B. P_ORGIN, HR: Stammdaten). 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, Berechtigungen oder Profilen gesucht werden.
‚Benutzer’ → ‚mit kritischen Berechtigungen’ (z. B. Variante SAP_RSUSR009) → Rollenname eingeben. 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 Berechtigungen aus
technischer Sicht. Zur optimalen Nutzung dieser Reports sind die „kritischen Berechtigungen“ unbedingt
kundenseitig nachzupflegen.
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.
28 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; wenn im Profil das
Objekt S_TCODE manuell ergänzt wurde, kann diese Transaktion in der SUIM nur über eine Suche über
Objekt S_TCODE ausgewertet werden.
Seite 83
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 Instrumente 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 Berechtigungen u. a. in SAP_ALL)
> Verletzung der Datenschutzanforderungen durch ein nicht angepasstes Berechtigungskonzept
> Umgehung des Zugriffschutzes des SAP ERP-Systems mit Hilfe von Entwicklerrechten (insbesondere
Umgehung bzw. Ausschalten des Authority-Checks)
> Veränderung des Systemzustandes, z. B.:
> Vergabe von Zugriffsberechtigungen an einen unberechtigten Benutzer oder für unzulä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 Tabellenprotokollierung.
Dies erfordert aber Zugriff auf die Profilparameter, die Tabellenaktivierungsberechtigung oder die
Entwicklerberechtigung
> Umgehung von Zugriffsberechtigungsprüfung durch Ausschaltung der Berechtigungsprüfung
Grundsätzlich ist es erforderlich, die von SAP ausgelieferten „Musterprofile“ funktionsbezogen an die
Anforderungen des Unternehmens anzupassen, um so einen adäquaten und den unterschiedlichen
rechtlichen Anforderungen entsprechenden Zugriffsschutz zu gewährleisten.
Ausnahme von der dargestellten Anforderung kann die Zulässigkeit der Vergabe eines weitreichenden
Profils an Notfall-User sein. Ein Beispiel hierfür könnte das von SAP ausgelieferte Profil SAP_ALL sein,
das um die Berechtigung zum Löschen oder Deaktivieren von Protokollierungen reduziert werden sollte
(Objekt S_SCD0).
4.2.1.5 BESONDERHEITEN BEI DER BERECHTIGUNGSPRÜFUNG
4.2.1.5.1 AUSSCHALTUNG / MODIFIKATION VON BERECHTIGUNGSPRÜFUNGEN
Wie in Kapitel 4.2.1.1 (Identifizierung und Authentifizierung) dargestellt, können Berechtigungsprü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 lassen sich auf diese Weise nicht global ausschalten).
Die Berechtigungsprüfungen des JAVA-Stacks (UME29-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 Berechtigungsobjekten’ 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:
> 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 Berechtigungsprü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 Berechtigungsobjekten erlaubt
sein soll, ist mindestens die folgende Empfehlung aus der SAP-Dokumentation zu befolgen:
„Zum Sichern bzw. Aktivieren von deaktivierten Berechtigungsprüfungen zu Berechtigungsobjekten wird
eine Berechtigung zum Objekt S_USER_OBJ benötigt. Aus Sicherheitsgründen sollten Sie die Berechtigungen für das Sichern und das Aktivieren von deaktivierten Berechtigungsprüfungen zu Berechtigungsobjek-
Seite 84
29 UME (User Management Engine)
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 vorgeschlagen
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 Organisation mit an
Sicherheit grenzender Wahrscheinlichkeit ausschließen kann, dass das Objekt (und / oder die Applikation) genutzt wird.
4.2.1.5.2 AUTHORITY-CHECK BEI ABAP-PROGRAMMEN
ten verschiedenen Benutzern zuordnen. Es ist sinnvoll, wenn das Deaktivieren von Berechtigungsprüfungen
nach dem 4-Augen-Prinzip stattfindet.“
(Standardprogramm oder Eigenentwicklungen)
Der Zugriffsschutz baut bei SAP ERP-Systemen im Wesentlichen auf maschinellen Kontrollen 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 Berechtigungen 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.
4.2.1.5.3 BERECHTIGUNGSHAUPTSCHALTER HR (TABELLE T77S0; GRPID „AUTSW“)
Seite 85
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 Berechtigungen (Schalter ORGPD) systemseitig
verprobt werden, ist von Customizing-Einstellungen abhä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 nicht. Hier kann die Prüfung auf der
Ebene der Einzelberechtigung eines Benutzers mit dem Report RHUSERRELATIONS erfolgen. Um den
Prüfaufwand zu verringern, kann die ausschließliche Nutzung der kontextsensitiven Berechtigungen und
die Definition kritischer struktureller Profile in Verbindung mit den entsprechenden Berechtigungsobjekten
(PLOG_CON, P_ORGINCON, P_ORGXXCON) als „kritische Berechtigung“ oder „kritische Berechtigungskombination“ wirksam genutzt werden. Dabei müssen Struktur- und Funktionsinformationen zusammengebracht und bewertet werden. Hier empfiehlt sich der Einsatz von Zusatztools (s. Kap. 6).
4.2.1.5.4 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 TransaktionscodeZuordnung ist sicherzustellen, dass Benutzer Reports ausschließlich über eine eigens zugeordnete
Transaktion aufrufen können. Der allgemeine Aufruf über Transaktionen wie SA38 (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 verwendete Reports sollten einer
Berechtigungsgruppe ‚Gesperrt‘, allgemeinzugängliche einer Berechtigungsgruppe ‚Allgemein‘ zugeordnet
werden. Die Zuweisung kann über den Report RSCSAUTH vorgenommen werden. Korrespondierend sind
im Berechtigungskonzept die Berechtigungen zu dem Objekt S_PROGRAM (ABAP: Programmablaufprüfungen) zu definieren. Da im Regelfall die SAP-Standardreports ohne Zuordnung zu einer Berechtigungsgruppe
ausgeliefert werden, muss dieser Schutzmechanismus vom Anwenderbetrieb realisiert werden.
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üfung30 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, Berechtigungsgruppen für Reports sowie
Test-, Freigabe- und Dokumentationsanforderungen festzulegen.
> Für SAP ERP-Standardprogramme sollten entsprechende SAP-Hinweise (SAP Service Marketplace;
http://service.sap.com/notes) beachtet werden, um bei bekannten Lücken bzw. notwendigen Korrekturen
die Authority-Checks in den Programmen ergänzen oder korrigieren zu können.
In Bezug auf den Berechtigungshauptschalter HR sind die Einstellungen für die aktiven Berechtigungsobjekte im Anwenderbetrieb als Soll-Werte festzulegen. In regelmäßigen Abständen sollten die im SAP ERPSystem 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.
Seite 86
30 Die Authority-Checks im Programmcode der Reports werden weiterhin ausgeführt, sofern sie vorhanden sind.
4.2.1.6.1 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 sicherheitssensible 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 Aktivierungsadministrators.
Die Aufgaben des Benutzeradministrators beziehen sich auf die Anlage und Pflege von Benutzerstammsätzen.
Der Rollenadministrator pflegt die Elemente des Berechtigungskonzeptes. Dies sind je nach konzeptionellem Vorgehen Rollen, Profile bzw. Berechtigungen.
Der Aktivierungsadministrator ist für die Verwendbarkeit der Elemente des Berechtigungskonzeptes
zuständig. Auch hier sind die Aufgaben von dem konzeptionellen Vorgehen abhängig. Sie bestehen in einer
Aktivierung von Berechtigungen bzw. Profilen, die der Rollenadministrator in der Pflegeversion erstellt hat.
Alternativ bestehen sie in der Durchführung des Benutzerabgleichs. Dabei werden die Rollen mit den darin
hinterlegten Profilen und Berechtigungen 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 Berechtigungsobjekt
S_USER_SAS ist eine Weiterentwicklung der Objekte S_USER_AGR, S_USER_PRO und S_USER_GRP
Die oben genannten Berechtigungsobjekte werden ebenfalls bei der Verwendung des Profilgenerators
(Transaktion PFCG) geprüft.
4.2.1.6 BENUTZERADMINISTRATION
Seite 87
Bezüglich der Report-Berechtigungsgruppen sollte im Rahmen des Berechtigungskonzeptes definiert
werden, mit welchen Maßnahmen Reports vor unzulässigem Zugriff geschützt werden. 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 Berechtigungsgruppen neu installiert wird.
4.2.1.6.2 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 Benutzergruppe gesteuert
werden. Über korrespondierende Berechtigungen zu dem Berechtigungsobjekt S_USER_GRP (Benutzerstammpflege: Benutzergruppen) besteht die Möglichkeit, die organisatorische Zuständigkeit systemseitig
abzubilden.
4.2.1.6.3 BENUTZERADMINISTRATION MIT DEM PROFILGENERATOR
Rollen enthalten die Berechtigungen, mit denen ein Benutzer auf die im Menü enthaltenen Funktionen
(Transaktionen, Berichte / Reports, webgestü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 Rollenzuordnungen erfasst
werden (befristete Vergabe von Berechtigungen).
Umgekehrt können auch die Benutzerstammsätze den Rollen zugeordnet werden. Hierfür steht auch die
Transaktion PFUD bzw. der Report RHAUTUPD_NEW (Abgleich Benutzerstammsatz) zur Verfügung.
4.2.1.6.4 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 SAPSystem wirksam.
Die Nutzung von manuell erzeugten Profilen kann zu einer nicht mehr kontrollierbaren Pflege von
Berechtigungen führen.
Seite 88
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 Zugriffsrechten 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 Funktionstrennungsgesichtspunkte 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-Augen-Prinzip)
nicht realisierbar sein, empfiehlt es sich, zumindest eine zweistufige Funktionstrennung zu implementieren
(Benutzeradministration mit Rollenzuordnung einerseits und Berechtigungsadministration mit Rollen- und
Aktivierungsadministration andererseits).
Änderungen, die im produktiven SAP-System vorgenommen werden, unterliegen zu Nachweiszwecken der
eingesetzten Verfahren bestimmten Protokollierungsanforderungen. Diese Anforderung ergibt sich aus
§ 238 HGB ff.
Zur Sicherstellung der Protokollierung von Änderungen sind verschiedene Systemeinstellungen zu treffen
oder grundsätzliche Schutzmechanismen zu aktivieren, die unerlaubte Änderungen von vornherein unterbinden.
4.2.1.7.1 CHANGE AND TRANSPORT SYSTEM
Begriffsabgrenzung
CTO
Der Change and Transport Organizer (CTO) stellt Funktionen zur Erzeugung, Dokumentation und Freigabe
von Änderungsaufträgen im Rahmen des Customizings zur Verfügung.
TMS
Über das Transport Management System (TMS) werden u. a. die Organisation und der Transport von diesen
Aufträgen unterstützt.
Grundsätzlich sieht SAP im Rahmen der Anwendungsentwicklung und des Customizings vor, dass drei
voneinander unabhängige SAP-Systeme – ENTWICKLUNGSSYSTEM, QUALITÄTSSICHERUNGSSYSTEM
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 konfigurieren, 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 personenbezogene
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.
4.2.1.7 ÄNDERUNGEN AM PRODUKTIVSYSTEM
4.2.1.7.2 TABELLENPROTOKOLLIERUNG / CUSTOMIZING
Seite 89
Im Rahmen der Einführung von SAP sowie im laufenden Betrieb wird eine Vielzahl von Tabellen 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 Einstellung ON ist nicht zulässig.
Wenn der Parameter REC / CLIENT eingeschaltet ist, werden Änderungsprotokollsätze für diejenigen
Tabellen geschrieben, die bei den technischen Einstellungen das entsprechende Kennzeichen gesetzt
haben. Selbst erstellte 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 nicht im Produktivsystem vorgenommen werden, um ein erforderliches Test-, Abnahme- und Freigabeverfahren nicht zu unterlaufen und sicherzustellen, dass die
vorgenommenen Einstellungen anforderungsgerecht vorgenommen wurden.
Zu berücksichtigen ist in diesem Zusammenhang, dass bei der Nutzung des TMS sicherzustellen ist,
dass auch bei Transporten von Customizing-Änderungen im Zielsystem eine Protokollierung der
Tabellen erfolgt. Hierzu ist es erforderlich, den Parameter RECCLIENT (Parameter 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 Produktivsystem zu unterscheiden.
4.2.1.7.3 SYSTEMÄNDERBARKEIT
Über die Transaktion SE06 kann gesteuert werden, ob Objekte des Repository und des mandantenunabhä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 Auswirkungen auf
mandantenabhängige Customizing-Änderungen.
Diesbezüglich werden entsprechende Sicherheitsmechanismen über die Mandantensteuerung (vgl. Schutz
der Tabelle T000) festgelegt.
4.2.1.7.4 PROTOKOLLE
Seite 90
Wenn in SAP Änderungen an Objekten / Tabellen vorgenommen werden, wird – entsprechende 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.
Ü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 SM30. 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 Produktivsystem nicht
möglich sind.
Sollte es erforderlich werden, das System hinsichtlich Änderungsmöglichkeiten zu öffnen, ist sicherzustellen, dass keine unkontrollierten Änderungen vorgenommen werden – entsprechende Dokumentationsunterlagen sollten erstellt werden – und dass nach den vorgenommenen Einstellungen der Änderbarkeitsstatus wieder zurückgesetzt wird.
Zur Sicherstellung der ordnungsmäßigen Programmanwendung und zum Schutz vor unberechtigter
Kenntnisnahme oder versehentlicher / absichtlicher Manipulation von Daten ist sicherzustellen, 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 Protokollierung von
Tabellen getroffen werden, um sowohl die gesetzlichen Anforderungen erfüllen zu können als auch dem
Risiko der bewussten oder unbewussten Manipulation von Datenbeständen vorzubeugen sowie den
Anforderungen, die sich an den Schutz personenbezogener 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.7.5 SCHUTZ DER TABELLE T000
4.2.1.8 SYSTEMSCHNITTSTELLEN
Für die Kommunikation innerhalb eines SAP ERP-Systems, dem Informationsaustausch zwischen
verschiedenen SAP ERP-Systemen oder der Kommunikation zwischen SAP ERP- und Fremdsystemen
stellt SAP verschiedene Schnittstellenmethoden zur Verfügung.
4.2.1.8.1 BATCH-INPUT
Seite 91
Bei dem Batch-Input-Verfahren werden Daten in einer sogenannten Batch-Input-Mappe gespeichert. 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 Abspielen die entsprechenden Berechtigungs- und
Plausibilitätsprüfungen.
4.2.1.8.2 RFC, ALE, BAPI
Der Remote Function Call (RFC) dient der Kommunikation zwischen verteilten Programmen in einer SAPSystemlandschaft. Mit Hilfe von RFC können Funktionsbausteine in einem fremden SAP-System aufgerufen
werden und die Ergebnisse an das aufrufende System zurückgegeben werden.
Die Technik von RFC bildet auch die Grundlage für weitere SAP-spezifische Schnittstellenmethoden wie
Application Link Enabling (ALE) und Business Application Program Interface (BAPI).
Eine besondere Fragestellung wirft die Übergabe von HCM-Daten in ein separates Logistiksystem auf. SAP
bietet hierzu im Customizing Standard ALE Schnittstellen an, die immer vollständige Infotypen an das
angeschlossene Logistiksystem weitergeben (siehe in der Transaktion SPRO (→ SAP Referenz-IMG) →
SAP NetWeaver → Application Server → Application Link Enabling → Geschäftsprozesse modellieren →
vordefinierte ALE-Geschäftsprozesse → 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 Verarbeitung in der
Logistik fehlen. Hier ist durch gesonderte Maßnahmen in der Berechtigungsverwaltung sicherzustellen,
dass eine zweckentfremdete Nutzung ausgeschlossen wird (vgl. Anlage zu § 9 Ziffer 8 BDSG).
Auch bei anderen Schnittstellen des HCM, z. B. in das Controlling oder zur Arbeitszeiterfassung (CATS bzw.
CATSXT), ist die Einhaltung der Zweckbindung zu beachten.
4.2.1.8.3 PC-DOWNLOAD
SAP bietet die Möglichkeit, die unterschiedlichsten Auswertungen per Download aus der „gesicherten SAPUmgebung“ 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 verschiedene Berechtigungsobjekte
zur Verfügung.
4.2.1.8.4 ABAP-LISTVIEWER
Über den häufig verwendeten ABAP-Listviewer können angezeigte Daten ohne weitere Berechtigungsprüfung oder Protokollierung per „Kopieren“ und „Einfügen“ in ein beliebiges anderes Programm übernommen
werden. Siehe Abschnitt 4.2.1.3.11.
Nach jedem Datenexport in Fremdsysteme können innerhalb der SAP-Umgebung Zweckbindung,
Löschfristen und andere datenschutzrechtliche Anforderungen nicht mehr gewährleistet werden.
Seite 92
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
> 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önnen. Die Zugriffe werden über
Berechtigungen zu dem Berechtigungsobjekt S_BDC_MONI (Batch-Input Berechtigungen) bestimmt.
> In Bezug auf die RFC-Technologie (Remote Function Call) sind die Sicherheitseinstellungen der RFCDestinationen (Transaktion SM59 – Konfiguration der RFC-Verbindungen) zu beachten. Deren Pflege
wird über das Berechtigungsobjekt S_ADMI_FCD (Systemberechtigungen) gesteuert. Ob bei RFC überhaupt Berechtigungsprü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 Sicherheitsgründen
ist die Aktivierung der Berechtigungsprüfung für RFC unbedingt zu empfehlen. 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.
> 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 realisierbar, z. B. die Unterbindung der Cut-and-Paste-Funktion.
Diesen Risiken ist durch geeignete Maßnahmen zu begegnen. Als organisatorische Maßnahme 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 Zusammenspiel der
Kontrollen, vorzunehmen und regelmäßig zu überwachen ist. Als zentrale technische Maßnahmen sind
folgende Aspekte zu nennen:
4.2.1.9 AUDITING UND LOGGING
Es ist zu beachten, dass die Konfiguration und die Auswertung der nachfolgenden Protokolle neben ITSecurity, Revision und Wirtschaftsprüfern auch mit dem Datenschutzbeauftragten abzustimmen ist und die
Mitbestimmungsrechte der Arbeitnehmervertretungen beachtet werden.
Für Auditing und Logging ist ein Einsatzkonzept erforderlich, in dem die Anforderungen der einzelnen
Bereiche bezüglich der Einstellungen, der Einsichtnahme und der Aufbewahrungsdauer festzulegen sind.
Die benötigten IT-Ressourcen (z. B. zusätzlicher Speicherbedarf) sind dafür bereitzustellen.
4.2.1.9.1 SECURITY AUDIT LOG
Seite 93
Aus Datenschutzsicht ist zu empfehlen, Benutzer mit weitreichenden, kritischen Berechtigungen einer
Protokollierung mit dem Security Audit Log zu unterwerfen. Da eingerichtete Notfall-User 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 betrieblichen
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 Verfügung. In
mehreren Filtern können in verschiedenen ‚Auditklassen’ unkritische, schwerwiegende 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 Downloads 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 Logs 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 Profilparameter 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 Organisation Ihres
Notfallbetriebes mehrere Notfallbenutzer einrichten wollen. Sie können damit die Protokollierung der
Benutzer NOTFALL1, NOTFALL2, NOTFALL3 durch die Konfiguration eines gemeinsamen Filters für
NOTFALL* erreichen.
Die Verwendung einer generischen Selektion ist ab SAP NetWeaver 6.40 möglich, und für ältere 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 Datei Security Audit Log 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 kommen. Siehe
hierzu auch den SAP-Hinweis 664058.
Seite 94
Die Transaktion SM20 / SM20N ermöglicht eine Auswertung der mit Hilfe des Security Audit Logs
erzeugten Protokolle.
Das SAP ERP protokolliert in Systemprotokollen (Syslog auf Anwendungsebene) unterschiedliche
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 datenschutzrechtlicher Sicht v. a.
Transaktionen aus dem Bereich PA und PD zu nennen.
Syslog-Dateien sind in der Länge begrenzt und werden bei Erreichen der Maximallänge überschrieben.
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).
4.2.1.9.2 SYSTEM LOG
4.2.1.9.3 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 Center 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. Report 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 bereitstellt),
sollte aus Datenschutzgründen restriktiv geregelt werden.
4.2.1.9.4 WORKFLOW-PROTOKOLLIERUNG
Die Workflow-Komponente (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 Workflow-Komponente 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.
4.2.1.9.5 REPORT-PROTOKOLLIERUNG IM HCM
Seite 95
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 protokollierungspflichtig definiert sind.
Sofern über die vorgenommenen Einstellungen sichergestellt ist, dass Protokolle erzeugt werden, 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.
4.2.1.9.6 AD-HOC-QUERY-PROTOKOLLIERUNG ZUR KONTROLLE DER ZWECKBINDUNG
Das SAP System bietet die Möglichkeit, die Erstellung und die Ausführung von Querys 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 Stelle 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. Hilfsweise 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 Zweckbindung 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 Erstellung einer Query
zu dem in Frage stehenden Infoset haben und / oder
> in dem Infoset Daten besonderer Art gemäß § 3 Absatz 9 enthalten sind.
In diesen Fällen empfiehlt es sich, im Rahmen interner Kontrollen die Einhaltung der Zweckbindung laufend
zu kontrollieren.
Die Ad-hoc-Query-Protokollierung wirkt nicht für die anderen SAP-Query-Werkzeuge, nämlich SAPQuery und Quick-Viewer.
Seite 96
Bei den vorgenannten Punkten ist zwischen Auswertungen zu unterscheiden, die nachgelagerte Kontrollen
im Sinne eines Internen Kontroll Systems (IKS) oder aktivitätsbezogene Kontrollen und damit Leistungsund Verhaltenskontrollen ermöglichen.
Wird die Workflow-Komponente, z. T. das System Log oder das CCMS (STAD) genutzt, stehen somit Auswertungsmöglichkeiten bzgl. des Benutzerverhaltens (z. B. Anzahl der bearbeiteten Vorgänge etc.) zur
Verfügung. Die Nutzung dieser Auswertungen kann über das Berechtigungskonzept gezielt eingeschränkt
werden. Diesbezüglich ist eine Prüfung der im jeweiligen Unternehmen ausgeprägten Berechtigungen
notwendig. Dazu bietet das Audit Information System einen Ansatzpunkt.
Die Nutzung des Security Audit Logs halten wir zur Nachvollziehbarkeit der von speziell eingerichteten
Notfall-Usern 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 hinausgehend organisatorische Rahmenbedingungen
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 Arbeitnehmervertretung erfolgen.
TREX (Text Retrieval and Extraction Machine), Knowledge Management (KM) und Search Engine Services
(SES) stellen gemeinsam eine integrierte SAP-Suchtechnologie für die unternehmensweite 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 alle 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 Personalnummern, 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.
geschaffen werden müssen, über die die Verwaltung und die Zurücksetzung der Kennwörter der NotfallUser sowie die Archivierung und Kontrolle der erzeugten Protokolle sichergestellt ist.
4.2.1.11 ZUSAMMENFASSUNG ZENTRALER RISIKEN
Nachfolgend werden als Übersicht die in der Praxis am häufigsten auftretenden Risiken dargestellt. Diese
sind u. a.:
Seite 97
> Fehlende Prüfbarkeit und Nachvollziehbarkeit durch
> mangelnde Dokumentation der kundenspezifischen Anpassungen und Ausprägung des SAPSystems (Customizing, Tabellenpflege, Anwendungsentwicklung etc.)
> vergessene Report-Berechtigungsgruppenpflege
> nachlässige Handhabung des Berechtigungskonzeptes
> nicht eingehaltene Empfehlungen (z. B. ausgeschaltetes Tabellenprotokoll, zugelassene Programmierung im Produktivsystem)
> Umgehung des Zugriffschutzes des SAP ERP-Systems mittels der Programmiermöglichkeiten
(insbesondere Umgehung des Authority-Checks)
> Umgehung des Zugriffschutzes des SAP ERP-Systems mittels RFC-fähiger Funktionsbausteine, 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 unzulässigen Bedingungen (wie etwa
mangelnder Prüfbarkeit)
> Verletzung der Datenschutzanforderungen durch ein nicht angepasstes Berechtigungskonzept
> Verletzung der Datenschutzanforderungen durch zusätzliche Auswertungsprogramme, z. B.:
nicht vereinbarte Nutzung eines flexiblen Auswertungssystems, ABAP Reports oder Querys, d. h.
Verarbeitung von Daten ohne Rechtsgrundlage
> Ändern / Erweitern des Funktionsumfangs von ursprünglich genehmigten Programmen / ABAPs /
Querys
> Zugriff der Programmierabteilung auf Echtdaten des Personalwesens
> die Programmierung eigener Auswertungen außerhalb einer datenschutzrechtlich geprüften
SAP-Anwendung, die auf SAP-Daten zugreifen können (z. B. mittels Datenbank-Tools, d. h. also auch
unter Umgehung der Empfehlungen der SAP-Sicherheitsleitfäden)
> Veränderung des Systemzustandes, z. B.:
> Vergabe von Zugriffsberechtigungen an einen unberechtigten Benutzer oder für unzulässige
Programme
> Einrichtung nicht vereinbarter Dateien, Datenfelder oder Werteverzeichnisse
> 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 Servicerechenzentrum) 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 Tabellenprotokollierung.
Dies erfordert aber Zugriff auf die Profilparameter, die Tabellenaktivierungsberechtigung oder die
Entwicklerberechtigung
> Umgehung von Zugriffsberechtigungsprüfung durch Ausschaltung der Berechtigungsprü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 Anforderungen sind in der
allgemeinen Literatur (vgl. hierzu das Literaturverzeichnis im Anhang) nachzulesen.
Die Umsetzung der erforderlichen organisatorisch-technischen Maßnahmen zur Gewährleistung der
Anforderungen des Datenschutzes sowie die Prüfbarkeit der Installation sind zwingende Zulässigkeitsvoraussetzungen bei der Verarbeitung personenbezogener Daten. Die Prüfung, welche organisatorischtechnischen Maßnahmen jedoch erforderlich sind, muss individuell 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).
Seite 98
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 Prinzips der Datenvermeidung, der
Datensparsamkeit, der Anonymisierung, der Pseudonymisierung oder eine Prüfung der Zulässigkeit der
Verarbeitung, z. B. der Übermittlung personenbezogener Daten ins Ausland. Solche Fragen sollten in der
In der Checkliste sind die verschiedenen Prüfungsfelder aus diesem Kapitel in drei Kategorien unterteilt,
nämlich nach
> Anforderungen an die Prüfbarkeit
> ggf. 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 gewü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 ergänzend zur Hilfe zu nehmen.
Zusammengefasst bedeutet dies: Was im Einzelfall erforderlich oder angemessen ist, damit auch die Frage
nach der Zulässigkeit bestimmter Verarbeitungsformen, ist in allen nachfolgend 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 vollumfänglich bei der verantwortlichen Stelle.
Seite 99
Regel im Rahmen der Vorabkontrolle, also einer einmaligen Prüfung vor Inbetriebnahme eines betreffenden
Systems, erfolgen.
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 oder extern), die Schaffung
globaler Prozesse mit einer gesellschaftsübergreifenden Verarbeitung personenbezogener Daten oder die
Nutzung externer Dienstleister (klassisches Outsourcing).
Es muss im Konzern / Unternehmensverbund klar definiert sein, wer ‚Herr der Daten’ ist, denn nach dem
BDSG muss jede rechtlich selbstständige Einheit (Legal Entity) ab verantwortliche Stelle, beispielsweise bei
einem Auskunftsbegehren des Betroffenen, Auskunft geben können über den Datenfluss und die unterschiedlichen zugriffsberechtigten Personenkreise.
5.1 ABGRENZUNGEN BEIM THEMA OUTSOURCING UND DATENSCHUTZ
Grundsätzlich ist zwischen internem und externem Outsourcing zu unterscheiden. Beim internen Outsourcing wird die Datenverarbeitung von einer rechtlich unselbststä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 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
> Auslagerung von Aufgaben der Systemadministration bzw. des Rechnerbetriebs an verschiedene
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 Provider
> Verlagerung von Dienstleistungen ins Ausland (EU / EWR / Drittländer)
Seite 100
ZUR ABGRENZUNG DER BEGRIFFE AUFTRAGSDATENVERARBEITUNG UND FUNKTIONSÜBERTRAGUNG:
Die Auftragsdatenverarbeitung ist dadurch gekennzeichnet, dass Auftraggeber und Auftragnehmer – und
dies gilt auch für zwei Konzernunternehmen − voneinander rechtlich unabhängige und selbstständige
Unternehmen sind. Es gilt aber die Privilegierung, dass Auftraggeber und Auftragnehmer rechtlich einheitlich als eine einzige verantwortliche Stelle gesehen werden (vgl. § 3 Abs. 8 BDSG). Dies resultiert daraus,
dass der Auftragnehmer dem Auftraggeber lediglich bei der Verlagerung von Verfahren oder Verfahrensschritten weisungsgebundene Unterstützung leistet. Datenerhebung, -verarbeitung oder -nutzung werden
hierbei lediglich in ihrer Hilfsfunktion für die Erfüllung der Aufgaben und Geschäftszwecke der verantwortlichen Stelle ausgelagert.
Rechtlich anders behandelt werden soll der Fall, wenn der Auftragnehmer – im Falle des Outsourcings als
Outsourcingnehmer − mehr als nur weisungsgebundene Funktionen wahrnimmt. Dies ist dann der Fall,
wenn dem Outsourcingnehmer daneben weitere Aufgaben oder Funktionen 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 Zusammenhang 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 Outsourcingnehmer eine bestimmte vertraglich geschuldete Leistung in eigener
Verantwortlichkeit 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 eigenverantwortlich wahrnimmt. Es wird also der Auftrag zur Erbringung einer Leistung erteilt, deren Bestandteil auch die Erhebung,
Verarbeitung oder Nutzung personenbezogener Daten ist, die der Outsourcinggeber zur Verfügung stellt.
Man spricht hier von einer sogenannten Funktionsübertragung.
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 übernommenen Aufgabe eigene Datenherrschaft,
z. B. dadurch, dass er eigenständig über die Weitergabe von Daten oder Auswertungen im Konzern entscheiden kann, spricht dies für eine Funktionsübertragung.
Wenn innerhalb eines Konzerns Outsourcing betrieben wird, sind die anzuwendenden Rechtsvorschriften
nicht anders zu interpretieren als bei einem Outsourcing zwischen sonstigen fremden Unternehmen.
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 Vertragsgestaltungen aus datenschutzrechtlicher Sicht kann in Fachbüchern nachgelesen werden (siehe [Müthlein / Heck]31). Diesem Buch sind auch
wesentliche Teile der in diesem Unterkapitel aufgeführten Texte entnommen.
Dabei ist zu beachten, dass es im öffentlichen Bereich unterschiedliche Anforderungen der Landesdatenschutzgesetze an die Vertragsgestaltung und Information bei Auftragsdatenverarbeitung (im Sinne des §11
BDSG) gibt. Die landesspezifischen Anforderungen sind für öffentliche Stellen unbedingt zu beachten.
Für besonders sensible Bereiche wie z. B. Krankenhäuser und Sozialversicherungsträger gelten weitere,
z. T. strengere Regelungen zum Outsourcing.
5.2.1 PFLICHTEN DES AUFTRAGGEBERS UND AUFTRAGNEHMERS
31 T. Müthlein, J. Heck: Outsourcing und Datenschutz. Vertragsgestaltung aus datenschutzrechtlicher Sicht,
3. neu überarb. Auflage, 2006, Datakontext Fachverlag
Seite 101
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 verantwortlich 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 datenschutzrechtlichen Kontrolle. Der Auftragnehmer
ist unter Prüfung der Eignung der angebotenen technischen und organisatorischen Maßnahmen sorgfältig
auszuwählen (kaufmännische Sorgfaltspflicht). Zwingend ist die schriftliche Festlegung der Datenerhebung / -verarbeitung / -nutzung, der technischen und organisatorischen Maßnahmen und etwaiger Unterauftragsverhältnisse. Es ist zu regeln, dass nur nach den Weisungen des Auftraggebers verfahren 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. zu Verfügbarkeit, Recovery oder Virenschutz. In diesen Fällen
reicht in der Datenschutzvereinbarung ein Verweis auf die SLAs aus.
Der Auftraggeber hat die Pflicht, sich gemäß §11 Abs. 1 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.
Der Auftragnehmer muss intern sicherstellen, dass die Datenerhebung, -verarbeitung bzw. -nutzung nur
nach den festgelegten Weisungen erfolgt und die technischen und organisatorischen 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, Umfang) vom Auftragnehmer verwaltet und welche Verfahren darauf angewendet werden sollen (ergibt sich i. d. R. aus dem SLA,
s. o.). Da sich die konkrete Ausgestaltung des Auftragsverhältnisses ändern kann, ist es sinnvoll, solche
Sachverhalte, die sich während der Vertragslaufzeit ändern können (z. B. Wechsel von Personen), als Anlage
zum SLA oder der Datenschutzvereinbarung 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 andere Sicherungsmaßnahmen)
> Berechtigung bzw. Pflicht zum Transport / Versand von Dateien, Datenträgern, Belegen oder Listen
> Sonderanforderungen an den Auftragnehmer (dazu berechtigte Personen des Auftraggebers,
Ansprechpartner beim Auftragnehmer)
> Festlegung der Zuständigkeit für die Archivierung (Aufbewahrungsfristen) und Löschung
(siehe auch Kapitel 2.3.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 Auftraggeber weitergehende
Weisungsrechte, sind diese gesondert auszuhandeln und vertraglich festzulegen.
5.2.3 TECHNISCHE UND ORGANISATORISCHE MASSNAHMEN
Seite 102
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
betrieblichen Datenschutzbeauftragten des Auftraggebers bei der Wahrnehmung seiner Kontrollrechte 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
5.2.4 WAHRUNG DER RECHTE DER BETROFFENEN
Die Rechte des Betroffenen sind gegenüber dem Auftraggeber geltend zu machen. Das bedeutet 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.
5.2.5 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.
§ 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 sind, müssen hier nicht mehr wiederholt
werden.
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.
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 zeitlichen Vorlauf er solche
Prüfungen anmelden muss. Außerdem sollte er sich – soweit erforderlich – vertraglich ein besonderes
Einsichtsrecht beim Auftragnehmer durch eigene Mitarbeiter (z. B. betrieblicher Datenschutzbeauftragter)
oder beauftragte Dritte vorbehalten.
Kontrollen können auch durch Einsicht in Prüfberichte / Zertifikate anderer Institutionen (z. B. durch Wirtschaftsprüfer / Aufsichtsbehörden / BSI) erfolgen. Hierbei sind Datenschutz- / Geheimhaltungsbedürfnisse
des Auftragnehmers selbst und seiner anderen Kunden zu beachten.
5.2.7 DATENSCHUTZBEAUFTRAGTER DES AUFTRAGNEHMERS
Seite 103
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 Datenschutzbeauftragten des Auftragnehmers
benennen lassen und sich das Recht über die Information bei einem Wechsel des Datenschutzbeauftragten
des Auftragnehmers zusichern lassen.
5.2.8 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 Erfassung oder Archivierung von
Daten, die Delegation von Arbeiten auf Ausweichrechenzentren in Fällen von Überkapazitäten oder Zusammenbrüchen). Auch hier sind die gleichen Voraussetzungen 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
Verantwortlichkeiten gegenüber denen des Auftragnehmers abzugrenzen.
Daneben sollte geregelt werden, ob dem Auftragnehmer grundsätzlich das Recht zugesprochen werden
soll, künftige Unterauftragsverhältnisse abzuschließen. Sollte dies bejaht werden, ist ein Verfahren zu
bestimmen, das 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.
5.2.9 VERARBEITUNG IM AUSLAND
Bei einer Auftragsvergabe innerhalb der Europäischen Union (EU) / des Europäischen Wirtschaftsraums
(EWR) wird hinsichtlich des Auftragnehmers keine Unterscheidung getroffen zwischen einer Datenverarbeitung in Deutschland oder in einem Staat innerhalb der EU / des EWR.
Bei der Vergabe in ein Drittland (also außerhalb der EU / des EWR) soll nach bisheriger Auffassung, 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 Standardvertragsklauseln zur Auftragsdatenverarbeitung in Drittländern gestützt. Insofern ist auch
eine Auftragsdatenverarbeitung 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.).
Für eine entsprechende Auftragsvergabe sind u. a. folgende Punkte zu prüfen:
> Es ist zu prüfen, ob eine positive oder negative Entscheidung der EU-Kommission in Bezug auf ein
angemessenes Schutzniveau in diesem Drittland existiert. Dies gilt beispielsweise für die Schweiz,
Kanada und Argentinien.
> Ggf. sind die EU-Standard-Vertragsklauseln zugrunde zu legen.
> Durch individuelle Vertragsklauseln, genehmigt durch die Aufsichtsbehörde, können ausreichende
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. Beispiele: Wenn der Betroffene
eingewilligt hat oder ein Vertrag mit dem Betroffenen vorliegt. Der Hinweis auf die Zweckbindung ist auf
jeden Fall zu geben.
Seite 104
In den USA können sich Unternehmen zur Beachtung der Safe-Harbor-Erklärung verpflichten. Diese USFirmen wollen durch Einhaltung dieser Vorschriften ein angemessenes Datenschutz-Niveau gewährleisten
(www.export.gov/safeharbor). Die Regelung in §11 Abs. 2 BDSG besagt, dass der Auftraggeber sich auch bei
einem Auftragnehmer im Ausland von der Einhaltung der getroffenen technischen und organisatorischen
Maßnahmen zu überzeugen hat.
5.2.10 WARTUNG UND PFLEGE
Per Definition sind gemäß §11 Absatz 5 BDSG auf die Erbringung von Wartungsarbeiten oder von vergleichbaren Unterstützungsdienstleistungen die Regelungen der Auftragsdatenverarbeitung im Sinne des
Bundesdatenschutzgesetzes entsprechend anzuwenden, wenn dabei ein Zugriff 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
Aufgrund der Besonderheiten des BDSG sind bei Nutzung von Vertragsmustern zur Auftragsdatenverarbeitung hinsichtlich der Benennung des Datenschutzbeauftragten des Auftragnehmers und der Verpflichtung
auf das Datengeheimnis nach § 5 BDSG Anpassungen erforderlich. Statt des Datenschutzbeauftragten sollte
der Auftragnehmer einen von ihm zu bestimmenden Datenschutzverantwortlichen benennen.
Die Verpflichtung nach § 5 BDSG kann durch eine vom BDSG losgelöste wortgleiche individuelle Verpflichtung der Mitarbeiter des Auftragnehmers ersetzt werden.
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 differenzieren. Sie kommt
regelmäßig nur dann in Betracht, wenn sich die Wartung auf Anwendungsdaten mit Personenbezug
erstreckt.
Seite 105
In allen Fällen obliegt es dem Auftraggeber der Wartung selbst, die Tätigkeiten dem Einzelfall entsprechend
freizugeben und zu kontrollieren.
Im Hinblick auf den Schutz personenbezogener Daten gegenüber unautorisierter Kenntnisnahme 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 heruntergeladen
werden.
> Bei Fernwartungsmaßnahmen via Remote Access ist das Prinzip der geringsten Rechtevergabe zu
beachten. Zugriffe auf produktive Rechnersysteme 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 Anwesenheit.
Im Rahmen regelmäßiger, systematischer Wartungszugriffe über Remote Access, die häufig – wie im Fall
SAP – dazu dienen, Systemumgebungen zu aktualisieren, sind von der Systemadministration des Auftraggebers Zugriffsrechte nur auf besondere Anfrage des Auftragnehmers zu erteilen.
Die SAP hat für ihre Wartungstätigkeit ein Sicherheitskonzept in diesem Sinne erstellt, das auf Anforderung
dem Kunden zur Verfügung gestellt wird.
5.3 SAP-FAKTEN
5.3.1 AUSGANGSSITUATION
Seite 106
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 verantwortliche 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 buchungskreisübergreifenden Funktionen, mit dessen Hilfe sowohl komplexe Konzernstrukturen als auch mehrere, voneinander unabhängige Unternehmen in einem SAP-System nebeneinander 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 vergeben (z. B. keine mandantenunabhängige Tabellenzugriffe, 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 achten, dass die
Zugriffsrechte die gesellschaftsrechtlichen Abgrenzungen abbilden. Abweichungen hiervon sind durch die
beteiligten Gesellschaften selbst untereinander datenschutzkonform 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 Arbeitszeitregelungen.
Im Hinblick auf die Vertraulichkeit von Personaldaten empfiehlt sich dann eine entsprechende Einschränkung der Berechtigungen.
Da das BDSG kein Konzernprivileg kennt, ist unter Datenschutzaspekten auch innerhalb eines Mandanten
das Augenmerk auf die sichere Datenverarbeitung je Buchungskreis als kleinste bilanzierungsfähige bzw.
rechtlich selbststä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 (Bereitstellung von SAPSystemen) die unternehmensspezifische Pflege der SAP-Anwendungen, des Basissystems und der
Betriebssystemkomponenten mehr oder weniger auf den Auftragnehmer verlagern.
Aufgrund der Tatsache, dass Dienstleistungsrechenzentren i. d. R. für verschiedene Auftraggeber tätig sind,
hat der Auftragnehmer hinsichtlich der realisierten Zugriffsschutzmechanismen besondere Sorgfalt walten
zu lassen, um personenbezogene Daten unterschiedlicher Anwender zu trennen bzw. vertraulich zu
behandeln.
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öglich). 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 (weitere Informationen zu Berechtigungsobjekten und -profilen s. Kap. 4).
5.3.3 SAP-SPEZIFISCHE MASSNAHMEN
5.3.2 SAP-ADMINISTRATION
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 Umsetzung der Anforderungen aus § 9
BDSG und Anlage: Technisch-organisatorische Maßnahmen) besondere Bedeutung zu, da sie u. U. voneinander getrennte Zuständigkeitsbereiche betreffen.
Besonders hervorzuheben sind die nachfolgenden Punkte:
5.3.3.1 SYSTEMADMINISTRATION
Es ist sorgfältig zu prüfen, in welchem Umfang umfassende bzw. weitreichende Berechtigungen 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 keinerlei Berechtigungen verfügen (Ausnahme: Mandant 000 und ggf. 066). Für Notfälle ist ein spezieller Notfall-User durch
den Auftraggeber zu definieren und temporär freizuschalten.
5.3.3.2 CHANGE AND TRANSPORT ORGANIZER (CTO / CTS)
Seite 107
Falls die SAP-Anwendungsentwicklung bzw. die Berechtigung zum Ändern von Entwicklungsobjekten auf
den Auftragnehmer verlagert wird, ist bei diesem sicherzustellen, dass Testdaten (häufig handelt es sich
um Originaldaten des Produktivsystems für Integrationstests) nur den jeweiligen rechtlich selbstständigen
Einheiten (Buchungskreisen) als „Dateneigentümer“ bzw. beauftragten Dritten zur Verfügung stehen.
Grundsätzlich dürfen zur Erhaltung der Sicherheit der Datenbestände, zum Schutz vor unberechtigter
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 Serviceleistungen diese
der Auftragsdatenverarbeitung gleichgestellt sind, sollten entsprechende Regelungen ü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. Dies wird i. d. R. lediglich auf Anforderungen 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 erstellen.
Zum Schutz dieser Benutzer vor unberechtigtem Zugriff sind die Initial-Kennwörter 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 Nutzung eines solchen Benutzers vorgesehen sind.
Zur Kontrolle der von der SAP durchgeführten Maßnahmen des Benutzers Earlywatch kann beispielsweise
das Security Audit Log genutzt werden. Weiterhin ist zu empfehlen, dass dieser Benutzer 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 Funktionsbausteine in einem fremden
NetWeaver-basierten System aufgerufen werden und die Ergebnisse an das aufrufende NetWeaverbasierte System zurückgegeben werden.
Die Technik von RFC bildet auch die Grundlage für weitere NetWeaver-basierten spezifische Schnittstellenmethoden wie Application Link Enabling (ALE) und Business Application Programming 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 technische sowie organisatorische
Maßnahmen zu ergreifen, über die sichergestellt wird, dass ein dem BDSG entsprechendes Datenschutzniveau aufrechterhalten wird.
5.3.3.5 JOB-ABWICKLUNG
Seite 108
Zwischen Auftraggeber und Auftragnehmer sind die Verantwortlichkeiten bezüglich Job-Auftrag, JobDurchführung und Job-Überwachung klar schriftlich zu definieren (z. B. Personalabrechnungslauf,
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ützen.
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) Daten von der
Anzeige zu kopieren. Hierfür müssen beim Auftragnehmer geeignete organisatorische Rahmenbedingungen geschaffen werden, die verhindern, dass personenbezogene Daten ohne Wissen des Auftraggebers
beim Auftragnehmer anderweitig nutzbar gemacht werden.
Mahnlauf). Diese Verfahrensanweisungen sollten sowohl den Fachabteilungen 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 mindestens 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 selbstständigen Einheiten ausgedruckten
Listen, die personenbezogene Daten enthalten, ist sicherzustellen.
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 entsprechende 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
Seite 109
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. umfassen.
Die Aufbewahrungsfristen könnten an die handels- und steuerrechtlichen Vorschriften angelehnt werden.
Zu beachten ist, dass Protokolle zum Teil keine auftraggeberspezifische Auswertung erlauben. Dies gilt
insbesondere für Logdateien, sofern die Daten mehrerer Auftraggeber auf demselben System, in demselben Mandanten oder in denselben Organisationsstrukturen (Buchungskreis, Werk / Personalbereich etc.)
verarbeitet werden.
Zur eindeutigen Zuordnung bedarf es ggf. zusätzlich implementierter Filter für die Auswertung der Protolle,
die im SAP-Standard nicht vorhanden sind. Ein solcher Filter kann z. B. anhand der Benutzerkennungen des
Auftraggebers erfolgen.
5.4 RISIKEN
Seite 110
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 beachtet.
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 überzeugen.
Gleichzeitig ist der Auftragnehmer verpflichtet, unter Beachtung des Datenschutzes die sorgfä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 Kontrollsystem verantwortlich.
Seite 111
6 Besondere Themen
6.1 AUDITWERKZEUGE: AUDIT INFORMATION SYSTEM
UND BENUTZERINFORMATIONSSYSTEM
6.1.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 Dokumentation, Prüfungsauswertungen und Download von Prüfungsdaten.
Grundsätzlich gliedert sich das AIS in die Bereiche kaufmännisches Audit und System Audit. Das kaufmännische Audit beinhaltet neben organisatorischen Übersichten auch bilanzorientierte und prozessorientierte
Funktionen. Damit lassen sich z. B. Informationen über Kunden, Lieferanten, die Finanzbuchhaltung und
Steuerbelange gewinnen.
Das System Audit des AIS ist in verschiedene Bereiche unterteilt: u. a. allgemeine Systemprü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 u. a. das „Infosystem Benutzer & Berechtigungen“ verwendet werden, mit dem z. B. verschiedene Auswertungen über Benutzer, Rollen oder Änderungsbelege (Protokollierung der Benutzer- / Rollenverwaltung) erstellt werden können.
Das AIS bietet aber auch dem Datenschutzbeauftragten Hilfestellungen bei seinen Aufgabenstellungen.
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.
Seite 112
Ab dem SAP Release 4.6C wurde das AIS von der bisherigen Menütechnik auf eine rollenbasierte Pflegeumgebung umgestellt. Jeder AIS-Benutzer benötigt je nach seiner Aufgabenstellung Rollen, die in seinem
Weitere Informationen entnehmen Sie bitte der Dokumentation des Audit Information System bzw. den
SAP-Hinweisen 754273 und 451960.
Allerdings ist das AIS im Hinblick auf den Datenschutz nicht mehr aktuell. Seit Jahren werden die Datenschutzfunktionalitäten im AIS nicht mehr von SAP gepflegt oder verbessert. Das drückt sich einmal in veralteten
Begriffen (wie Dateiregister) aus. Aber auch darin, dass Anregungen zur Weiterentwicklung des AIS bisher
seitens SAP nicht aufgegriffen wurden.
So formulierten Mitglieder der AG Datenschutz bereits im September 2005 detaillierte Anforderungen zur
Verbesserung des AIS32 etwa zum Menüpunkt Datenschutz:
> Die bisherige Funktion zum ‚Dateiregister’ muss dem Sprachgebrauch des BDSG angepasst
und um weitere Domänen mit Personenbezug erweitert werden (z. B. EKGRP).
> Es sollten Funktionalitäten zur Anzeige von Daten besonderer Art (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 Funktion für die Verpflichtung auf das Datengeheimnis (Infotyp Belehrungen) geben.
> Eine Funktion zur Auskunftserteilung an Mitarbeiter (bisher: in der Mappe ‚Personaldaten’, Funktion‚
Infotypübersicht für einen Mitarbeiter) sollte im Menüpunkt ‚Datenschutz’ integriert werden.
Benutzerstamm hinterlegt werden. SAP liefert 71 Standardrollen für die Arbeit mit dem AIS aus (Selektion
SAP*AUDITOR*).
Eine Übersicht über die für den Datenschutzbeauftragten relevanten AIS-Standardrollen findet sich am
Anfang des Kapitels 2 (Aufgaben des Datenschutzbeauftragten). Hier werden auch Empfehlungen zur
Rollenvergabe an den DSB sowie weiterführende Literaturhinweise gegeben.
Diese Verbesserungsvorschläge beziehen sich neben dem Datenschutz auch auf die Funktionalitäten zur
Personalwirtschaft (HCM), auf die Analyse von Berechtigungskonzepten und des Systemzustandes sowie
auf die Protokollierungsmöglichkeiten im SAP ERP.
Unklar ist derzeit, welche Strategie SAP mit dem AIS verfolgt. Ob und wie eine Weiterentwicklung erfolgt
oder ob andere Tools an die Stelle des AIS treten sollen, ist derzeit nicht ersichtlich.
6.1.2 BENUTZERINFORMATIONSSYSTEM (SUIM)
Das Benutzerinformationssystem (Transaktion SUIM) kann als Analyseinstrument für das Berechtigungskonzept eines SAP ERP-Systems verwendet werden. Es hilft dem Auditor, einen Ü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.33
32 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
33 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.“
Seite 113
Mit dem Benutzerinformationssystem kann allerdings bisher nur das Berechtigungskonzept der ‚klassischen ABAP-Welt’ analysiert werden. Die im Rahmen der JAVA-Umgebung vergebenen Berechtigungen
6 Besondere Themen
(z. B. für Portale) und die sogenannten ‚strukturellen Berechtigungen’ können nicht mit dem Benutzerinformationssystem überprüft werden. In speziellen SAP Systemen, wie z. B. SAP CRM für das Kundenbeziehungsmanagement, kommen ggf. weitere Instrumente 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 Benutzerinformationssystem integriert
und die bestehenden ‚Anwendungslücken’ dokumentiert.
6.2 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 Sicherheitseinstellungen 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, mittlere 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 eingebundenen SMSystem (Solution Manager) zur Aufbereitung und Sichtung sowie Bearbeitung zur Verfügung gestellt (SMTransaktion: 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 Berechtigungen aus dem
Benutzerinformationssystem eine Vielzahl von Auswertungen zu allen Gebieten 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 Administrationsrechten können in
einem Fragefilter (Questionaire) angegeben und so von der Listung und risikomäß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 verbundenen, benötigten sicherheitskritischen Berechtigungen. 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 vorhandenen Berechtigungen wird sehr deutlich angesprochen.
Der Security Optimization Service liefert eine Orientierung über den Sicherheitsstatus des SAP-Betriebes
und sollte in jedem Falle eine Methode der Überprüfung sein, ob das aus der betrieblichen Sicherheits- und
Risikoanalyse sich ergebende Schutzniveau bezüglich der technischen Maßnahmen umgesetzt und eingehalten wird.
Seite 114
Der Dienst steht nur in englischer Sprache zur Verfügung. Weiteres kann im SAP-Marketplace nachgelesen
werden (http://service.sap.com/sos).
Die SAP GRC Suite umfasst Lösungen zum Risikomanagement, zur Dokumentation des internen Kontrollsystems, zur Zugriffs- und Berechtigungssteuerung sowie für den globalen Handel und den Umwelt-,
Gesundheits- und Arbeitsschutz. Die Anwendungen der SAP GRC Suite sind zusätzliche Software, die im
Standard nicht verfügbar ist. Daher ist ihr Einsatz mit weiteren Lizenzkosten verbunden.
Mit diesen Anwendungen für Governance, Risk und Compliance können wichtige Vorschriften besser
eingehalten, Governance-Aspekte berücksichtigt und Transparenz über die unternehmensweiten Risiken
hergestellt werden.
Technologische Grundlage für den Einsatz der GRC-Lösungen ist die Integrations- und Applikationsplattform SAP NetWeaver.
Die GRC Suite besteht u. a. aus:
> SAP GRC Access Control, Zugriffs- und Berechtigungssteuerung
> SAP GRC Process Control, Lösung zur Dokumentation des internen Kontrollsystems
> SAP GRC Risk Management, Risikoidentifikation und -analyse
Darüber hinaus sorgen weitere GRC-Lösungen für die Beachtung von Bestimmungen in zahlreichen
Branchen.
6.3 SAP GRC (GOVERNANCE, RISK AND COMPLIANCE)
SAP SOLUTIONS FOR GRC
INDUSTRIY-SPECIFIC GRC
CROSS-INDUSTRY GRC
Risk Management
Acess Control
Process Control
SAP
NetWeaver
Global Trade
EH&S
BUSINESS PROCESS PLATTFORM
BUSINESS APPLICATIONS
ORACLE
PEOPLE SOFT
…
Seite 115
SAP
6 Besondere Themen
6.3.1 SAP GRC ACCESS CONTROL
SAP GRC Access Control dient der Zugriffs- und Berechtigungssteuerung in Echtzeit. Die Anwendung
analysiert und bewertet Risiken auf Basis von aktuellen Daten und kann so Konflikte in Bezug auf die Funktionstrennung und die kritischen Zugriffe sofort nach ihrem Entstehen erkennen.
Bevor Berechtigungen vergeben werden, ist eine Risikosimulation möglich, um potenzielle Regelverstöße
aufzudecken.
Die Funktionstrennung wird durch eine umfangreiche Datenbank mit entsprechenden Regeln für ERP-Systeme
realisiert, auf deren Basis das Berechtigungskonzept analysiert wird. Access Control analysiert die
Zugriffskontrolle unternehmensübergreifend für die ERP-Systeme von SAP, Oracle, PeopleSoft, JD Edwards
und Hyperion.
Die Einführung von Access Control erfolgt in mehreren Schritten.
Der erste Schritt dient der Identifizierung und Behebung von Risiken in der Zugriffsverwaltung. Innerhalb
der Unternehmensanwendungen werden anhand von Regeln kritische Transaktionen und Konflikte in Bezug
auf die Funktionstrennung erkannt (risk analysis and remediation).
Danach wird die Rollendefinition und -verwaltung mithilfe von Access Control (Enterprise Role Management) standardisiert und zentralisiert.
Kritische Berechtigungen werden dann über eine Zugriffssteuerung für Superuser / privilegierte Benutzer
aus den eigentlichen Rollen ausgelagert (superuser privilege management).
Wenn die Rollendefinition und -verwaltung zentralisiert ist, definiert man mit Access Control (Compliant
User Provisioning) sichere Prozesse zur regelkonformen Rollenvergabe. Dazu wird festgelegt, wer per
Workflow über Anträge auf Berechtigungen zu informieren ist. Geben diese Personen ihre Zustimmung,
wird die Rolle automatisch an den Anfragenden vergeben.
SPRINTPHASE
(„sauber werden“)
Indentifizierung
und Behebung
von Risiken
Rollenverwaltung
ENTERPRISE ROLE
MANAGEMENT
Rollendefinition
und -verwaltung
MARATHONPHASE
(„sauber bleiben“)
Zugriffssteuerung
für Superuser
SUPERUSER
PRIVILEGE
MANAGMENT
Zugangskontrolle für
privilegierte Benutzer
Prävention
COMPLIANT USER
PROVISIONING
Sichere Prozesse zur
regelkonformen
Berechtigungs- und
Zugriffsvergabe
Seite 116
RISK ANALYSIS AND REMEDIATION
Risikoanalyse, Erkennung und Behebung von Risiken und Schwachstellen
im Zusammenhang mit Zugangs- und Berechtigungskontrolle
6.3.1.1 RISK ANALYSIS AND REMEDIATION (VORMALS COMPLIANCE CALIBRATOR)
Risk Analysis and Remediation ermöglicht es, kritische Transaktionen und Konflikte in Bezug auf die
Funktions-trennung innerhalb von Rollen oder Profilen aufzudecken. Ein „Rule-Set“ mit Regeln 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.
Risk Analysis and Remediation erkennt damit automatisch vorhandene und entstehende Risiken der
Zugriffskontrolle. Außerdem ist es möglich, selbst Regeln zu definieren oder kritische Transaktionen zu
identifizieren.
In der Anwendung werden Reports zur Auswertung der Risiken nach Benutzern, Benutzergruppen, Rollen,
Profilen und kritischen Transaktionen bereitgestellt.
Mithilfe von Risk Analysis and Remediation 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.
Der Datenschutzbeauftragte kann durch SAP GRC Access Control das Berechtigungskonzept wesentlich
leichter überprüfen, da nicht jedes Berechtigungsobjekt / jede Transaktion einzeln ausgewertet werden
muss. Es besteht außerdem die Möglichkeit, eigene Regeln zu definieren (z. B. zu P_ORGIN) oder Transaktionen (z. B. PA30) als kritisch einzustufen. Mit dem Superuser Privilege Management wird insbesondere die
Problematik der Notfallbenutzer datenschutzkonform gelöst.
Ein wichtiger Bestandteil des Datenschutzes ist die Kontrolle des Zugriffs auf Daten, die Nutzung kritischer
Transaktionen und im HR der Zugriff auf Infotypen und Subtypen. Durch die präzise Definition des Zugriffsrisikos und Hinterlegung im System werden die Risiken rollen- und benutzerbezogen auswertbar.
6.3.1.2 ENTERPRISE ROLE MANAGEMENT (BISHER BEKANNT ALS VIRSA ROLE EXPERT)
Enterprise Role Management zentralisiert und standardisiert die Anlage und Verwaltung von Rollen im
Unternehmen. Führungskräfte können funktionsabhängige Rollen festlegen, während IT-Verantwortliche die
entsprechenden technischen Berechtigungen definieren. Durch eine flexible Prozessabbildung und eine
auto-matisierte hierarchische Rollengenerierung ist es einfach, Rollen anzulegen und zu pflegen.
Die Anwendung reduziert damit die Gefahr von Fehlern und erleichtert die einheitliche Realisierung bewährter Verfahren.
Enterprise Role Management ist in den Profilgenerator integriert, daher können einmal definierte Rollen
automatisch im SAP-System erzeugt werden.
6.3.1.3 SUPERUSER PRIVILEGE MANAGEMENT
(BISHER BEKANNT ALS VIRSA FIREFIGHTER FOR SAP)
Seite 117
Superuser Privilege 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 Systemzugriff. Dabei beobachtet, überwacht und
6 Besondere Themen
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 Voraus wird festgelegt, welche Benutzer einer Superuser-ID zugeordnet werden. Daher
gibt es keine Verzögerungen im Notfall.
6.3.1.4 COMPLIANT USER PROVISIONING
(BISHER BEKANNT ALS VIRSA ACCESS ENFORCER)
Compliant User Provisioning ermöglicht eine ordnungsgemäße Erteilung von Zugriffsrechten. Dynamische
Workflows automatisieren die Genehmigungsprozesse, indem jede Anfrage an die verantwortlichen Personen (z. B. per E-Mail) weitergeleitet wird. Diese werden über bereits vorhandene Berechtigungen des
Antragstellers (und ggf. entstehende Risiken durch eine Erweiterung) informiert und können dann zustimmen oder ablehnen. Falls eine Zustimmung erteilt ist, wird die Rolle automatisch erzeugt, sofern sie zuvor
mithilfe des Enterprise Role Management definiert wurde.
Außerdem wird es den Benutzern mit Compliant User Provisioning ermöglicht, ihre Passwörter selbstständig zurückzusetzen.
6.3.2 SAP GRC PROCESS CONTROL
FREIGABE
Die Anwendung SAP GRC Process Control 2.5 (kurz Process Control) dient zur Dokumentation des internen
Kontrollsystems. 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
MONITOR
BESCHEINIGUNG UND FREIGABE
(302, DESIGNS, …)
ÜBERPRÜFUNG
VON AUSNAHMEN
AUTOMATISCHE KONTROLLTESTS
TEST
Geschäftsprozesse
SAP
ORACLE
PEOPLE SOFT
SCHWACHSTELLENBEHEBUNG
MANUELLE
KONTROLLTESTS
DURCHFÜHRUNG
VON SELFASSESSMENTS
…
Seite 118
DOKUMENT
IT-Infrastruktur
PROZESS-KONTROLLE-ZIEL-RISIKO
Der Status der Kontrollen, Tests, Prozesse und Organisationen kann eingefroren werden, indem ein Sign-off
durchgeführt wird. Dabei müssen die verantwortlichen Benutzer die Dokumentation der Prozesse und die
Wirksamkeit der Kontrollen bestätigen.
Es ist möglich den Status der Process-Control-Stammdaten zu einem bestimmten Zeitpunkt zu betrachten
und Unterschiede zwischen verschiedenen Zeitpunkten zu erkennen.
Bewerten und Testen der Kontrollen sowie die Steuerung und Überwachung der Behebung von Kontrollschwächen unterstützt.
Die Struktur des Unternehmens kann in einer Organisationshierarchie abgebildet werden.
Für das ganze Unternehmen werden Prozesse und Subprozesse definiert. Einem Prozess / Subprozess
können Kontrollen zugeordnet werden, die Risiken abdecken.
Die Kontrollen können regelmäßig über geplante Testläufe ausgewertet werden. Dabei unterscheidet man
in Process Control zwischen automatischen, semiautomatischen und manuellen Kontrollen. Die automatischen Kontrollen liefert SAP mit Process Control 2.5 aus.
In der Applikation besteht die Möglichkeit, eigene manuelle und semiautomatische Kontrollen zu den Prozessen zu definieren. Dazu können z. B. Querys erstellt oder Reports (SAP-Standardreports und Kundenreports) eingeplant werden, die Process Control automatisch auf dem ERP-System startet. Die Ergebnisse
werden dann per Workflow an den zuständigen Benutzer zur Auswertung weitergeleitet.
Seite 119
Im Rahmen des Datenschutzes kann Process Control z. B. eingesetzt werden, um Datenverarbeitungsprozesse zu definieren und zu dokumentieren. Außerdem kann die Bereitstellung von detaillierten Anleitungen
und genehmigten Vorlagen Mitarbeitern manuelle Prüfungsaufgaben erleichtern.
Dies trägt dazu bei, dass z. B.
> die Rechte der Mitarbeiter über ihre persönlichen Daten gewahrt werden,
> die Einhaltung von Löschfristen kontrolliert werden kann und Datenbankreorganisationen
transparent sind,
> die Vorgaben für eine Auftragsdatenverarbeitung eingehalten werden (Dokumentation / Kontrolle
der Anforderungen)
Falls bei den Kontrollen Unstimmigkeiten auftauchen oder sich Prozesse verändern, kann automatisch der
Datenschutzbeauftragte (bzw. der zuständige Mitarbeiter) benachrichtigt werden (Workflow).
7 Glossar
http://help.sap.com/
http://www.sap.info/de/glossary/A.html
Seite 120
http://www.sap.info/en/glossary/A.html
Seite 121
Copyright © 2008 DSAG e. V.
Alle Rechte vorbehalten.
Namen von Produkten und Dienstleistungen sind Marken der jeweiligen Firmen.
Deutschsprachige SAP ® Anwendergruppe e. V.
Altrottstraße 34 a
69190 Walldorf
Deutschland
Fon: +49 (0) 62 27 – 358 09 58
Fax: +49 (0) 62 27 – 358 09 59
E-Mail: [email protected]
Internet: www.dsag.de

Leitfaden Datenschutz SAP ERP 6.0

Transcription

Similar documents

Empfehlungsschreiben der DVGW

Solution Send Report List

SPK-0251 - öffentliches Verfahrensregister - Sparkasse Gera

Hauptkatalog

CeBIT Sonderheft 2004

Lebenslauf - Jürgen Rauen

Einwilligungserklärung zur Nutzung von Lernplattformen

AIS TaxAudit 2013 R1

Datenschutzerklärung

SAP Hacking

Gateway E-Mail - Anwenderdokumentation - BAG

HOMMEL TESTER T1000 wave TURBO DATAWIN

Fachbereich Physik - Moodle am Schulzentrum Odenthal