Leitfaden Datenschutz SAP ERP 6.0

Deutschsprachige SAP® Anwendergruppe

Leitfaden Datenschutz SAP ERP 6.0DSAG ARBEITSGRUPPE DATENSCHUTZ

STAND 30. MAI 2008

ERARBEITET IN DER ARBEITSGRUPPE DATENSCHUTZLEITFADEN DATENSCHUTZ SAP ERP 6.0 STAND 30. MAI 2008

DSAG e. V.Deutschsprachige SAP-Anwendergruppe

DSAG Arbeitskreis Revision / Risikomanagement

Seite

2

IN MEMORIAMTHOMAS BARTHEL

(1950 – 2007)

Seite

3

Der vorliegende Leitfaden Datenschutz SAP ERP Release 6.0 soll Datenschutzbeauftragten der SAP-Anwender Anhaltspunkte für die Vorgehensweise bei der Umsetzung der Anforderungen der Datenschutz-vorschriften 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 † FORBIT GmbH / CArO GmbH, HamburgHerr I. Carlberg BIT e.V., BochumHerr V. Lehnert SAP Deutschland AG & Co.KG, WalldorfHerr H. Miller Geberit Deutschland GmbH, PfullendorfHerr T. Müthlein DMC Datenschutz Management & Consulting GmbH & Co.KG Frechen / GDD e.V. BonnFrau A. Otto SAP Deutschland AG & Co.KG, WalldorfHerr S. Pieper Deloitte & Touche GmbH, Frankfurt Herr K. Redling SAP Deutschland AG & Co.KG, WalldorfHerr A. Reschke Rechtsanwaltskanzlei Reschke, Wiesbaden Herr P. Schiefer Bayer AG, LeverkusenHerr H.-J. Schwab SAP AG, WalldorfHerr G. Siebert Forba Partnerschaft, BerlinHerr G. Voogd FORBIT GmbH / CArO GmbH, Hamburg

EinleitungSe

ite 4

AN DER 1. / 2. AUFLAGE WIRKTEN AUSSERDEM MIT:Herr V. Ahrend Bosch Telecom GmbH, Frankfurt Herr R. Anhorn Robert Bosch GmbH, StuttgartFrau C. Bonni Lausitzer Braunkohle AG, SenftenbergHerr W. Kilian RWE Energie Aktiengesellschaft, EssenHerr A. Lenz Rheinbraun AG, KölnHerr S. Dierschke BASF AG-Zok, LudwigshafenHerr W. Geesmann KPMG Deutsche Treuhand-Gesellschaft, DüsseldorfHerr R. Glagow PWC Deutsche Revision AG, DüsseldorfHerr F. Glaß PWC Deutsche Revision AG, Düsseldorf Herr T. Glauch KPMG Deutsche Treuhand-Gesellschaft, DüsseldorfHerr J. Heck Brau und Brunnen AG, DortmundHerr G. Hohnhorst KPMG Deutsche Treuhand-Gesellschaft, DüsseldorfHerr W. Hornberger SAP AG, WalldorfHerr A. Kirk Ruhrgas AG, EssenHerr K. Lorenz Deutsche Bausparkasse Badenia AG, KarlsruheHerr Dr. Pötschat BASF AG, LudwigshafenHerr E. Schmidt Philip Morris GmbH, MünchenHerr A. von der Stein RWE Systems AG, DortmundHerr U. Ueberschar Mannesmann Arcor AG & Co., Eschborn / KölnFrau G. Zibulski SAP AG, Walldorf

Die Verantwortung für den Inhalt tragen die Autoren. Die redaktionelle Bearbeitung und das Layout liegen bei der SAP AG und der DSAG.

HINWEIS: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 a69190 WalldorfDeutschlandJedwede 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.

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

Seite

5LE

ITFA

DEN

DAT

ENSC

HU

TZ F

ÜR

SA

P ER

P 6.

0 ST

AN

D 3

0.05

.200

8, ©

DSA

G e

. V.

An die Autoren der Arbeitsgruppe Datenschutz DSAG-GeschäftsstelleAltrottstr. 34a69190 WalldorfE-Mail: [email protected]

Fax: +49 (0) 62 27 – 358 09 59

ABSENDERName

Funktion

Abteilung

Firma

Anschrift

Telefon Telefax

ERGÄNZENDE INFORMATION(EN) ZUM LEITFADEN DATENSCHUTZ SAP ERPIch 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 AUFLeitfaden Datenschutz SAP ERP, Kapitel:.....................................................................................................................SAP ERP, Release:...........................................................................................................................................................

MEINE INFORMATION LAUTET:

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

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

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

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

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

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

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

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

ZUR WEITEREN ERLÄUTERUNG SIND ANLAGEN BEIGEFÜGT (BITTE ANKREUZEN):( ) Ja( ) Nein

Seite

6

1 EINFÜHRUNGSPROZESS 11 1.1 Anforderungen des BDSG an SAP ERP 11 1.1.1 Erhebung, Verarbeitung oder Nutzung von personenbezogenen Daten 11 1.1.2 Übermittlung von personenbezogenen Daten 12 1.1.3 Abrufverfahren 12 1.1.4 Besondere Zweckbindung 13 1.1.5 Auftragsverarbeitung 13 1.1.6 Unterrichtung des Betroffenen 13 1.1.7 Rechte des Betroffenen 13 1.1.8 Auskunft an jedermann 14 1.1.9 Meldepflicht 14 1.1.10 Verpflichtung der Mitarbeiter auf das Datengeheimnis 14 1.1.11 Schulung 15 1.1.12 Maßnahmen zur Datensicherheit 15 1.1.13 Übersichten gem. §§ 4e, 4g und §18 Abs. 2 (BDSG-Übersichten) 15 1.1.14 Vorabkontrolle 15 1.1.15 SAP Solution Manager als unterstützendes Tool im Einführungsprozess 15 1.2 Mitwirken des Datenschutzbeauftragten bei der Einführung von SAP ERP 16 1.2.1 Datenschutzbeauftragter – Mitglied des SAP-Projektteams 17 1.2.2 Information des Datenschutzbeauftragten zu den „Meilensteinen“ 17 1.2.3 Informationsmöglichkeiten für den Datenschutzbeauftragten 17 1.3 SAP-Fakten 19 1.3.1 Customizing und ASAP-Vorgehensmodell 19 1.3.2 Berechtigungskonzept 20 1.3.3 Change Transport System / Change Transport Organizer (CTS / CTO) 21 1.3.4 Schnittstellenverarbeitung 21 1.3.4.1 Datenübernahme 21 1.3.4.2 PC-Verarbeitung 22 1.3.4.3 Kommunikationsschnittstellen 22 1.3.4.4 SAP-Automation 22 1.3.5 Job-Auftragsverfahren und -Dokumentation 1.4 Risiken 23 1.4.1 Nichteinschaltung des Datenschutzbeauftragten bzw. der Arbeitnehmervertreter 23 1.4.2 Nichtbeachtung der SAP-Empfehlungen 23 1.4.3 Nichtberücksichtigung bzw. verspätete Erstellung des Berechtigungskonzeptes 23 1.4.4 Nicht ordnungsgemäße Anwendung eines Datenverarbeitungsprogramms 23 1.5 Prüfungshandlungen im Rahmen der Einführung / Checkliste 24

2 AUFGABEN DES DATENSCHUTZBEAUFTRAGTEN 27 2.1 Überwachung der ordnungsgemäßen Programmanwendung (§ 4g Abs. 1 BDSG) 29 2.1.1 Einbeziehung des DSB vor und während der Programmentwicklung und -anpassung 29 2.1.2 Prüfung der Datenerhebung und Datennutzung auf Rechtmäßigkeit 29 2.1.3 Auswertung der Protokollierung 29 2.1.4 Prüfung der Verfahrensdokumentation 30 2.1.5 Mitwirkung bei der Festlegung und Überprüfung des Berechtigungskonzeptes 31

Gliederung

Seite

7LE

ITFA

DEN

DAT

ENSC

HU

TZ F

ÜR

SA

P ER

P 6.

0 ST

AN

D 3

0.05

.200

8, ©

DSA

G e

. V.

2.1.6 Mitwirkung bei der Festlegung des Betriebskonzeptes und der Betreiberorganisation 32 2.1.7 Abfassung einer Datenschutzerklärung 33 2.1.8 Überwachung des Korrektur- und Transportwesens unter SAP ERP 33 2.1.9 Kontrollen im laufenden Betrieb 34 2.2 Schulung der Anwender mit Verpflichtung auf das Datengeheimnis (§§ 4g und 5 BDSG) 34 2.2.1 Personenkreis, der geschult und verpflichtet werden muss 34 2.2.2 Inhalt der Anwenderschulungen 35 2.2.3 Abbildung der Anwenderschulung im SAP 35 2.2.3.1 Anwenderschulung über Infotypen „Belehrungen“ oder „Qualifizierungen“ 35 2.2.3.2 Anwenderschulung über das Veranstaltungsmanagement 36 2.3 Führen von Übersichten (§ 4g Abs. 2 / §18 Abs. 2 BDSG) 36 2.3.1 Informationen zur verantwortlichen Stelle 40 2.3.2 Zweckbestimmungen der Datenerhebung, -verarbeitung oder -nutzung 40 2.3.3 Beschreibung der betroffenen Personengruppen und der diesbezüglichen Daten oder Datenkategorien 40 2.3.4 Empfänger oder Kategorien von Empfängern 43 2.3.5 Regelfristen für Löschung 44 2.3.6 Geplante Übermittlung in Drittstaaten 51 2.3.7 Maßnahmen zur Gewährleistung der Sicherheit 52 2.3.8 Zugriffsberechtigte Personen 52 2.3.9 Beispiel Melderegister 53 2.4 Systemunterstützung 55 2.4.1 Auswertungen zur Tabellen- und Feldanalyse 56 2.4.2 Techniken zum Auffinden personenbezogener Daten 58 2.4.3 Prüfung der Zugriffsberechtigungen 60

3 RECHTE DER BETROFFENEN UND VON JEDERMANN 62 3.1 Benachrichtigung und Auskunft 62 3.1.1 Rechtliche Anforderungen 62 3.1.2 SAP-Fakten 63 3.1.3 Anforderungen an die Organisation des Datenschutzes 63 3.2 Berichtigung, Löschung und Sperrung 66 3.2.1 Rechtliche Anforderungen 66 3.2.2 SAP-Fakten 66 3.2.3 Anforderungen an die Organisation des Datenschutzes 67

4 UMSETZUNG DER ANFORDERUNGEN AUS § 9 BDSG UND ANLAGE: TECHNISCH-ORGANISATORISCHE MASSNAHMEN 68

4.1 Anforderungen 68 4.1.1 Gesetzliche Anforderungen aus § 9 BDSG 68 4.1.2 SAP-Funktionalität zur Abdeckung der gesetzlichen Anforderungen 69 4.2 SAP-Fakten, Risiken und Maßnahmen 71 4.2.1 ABAP-Fakten, Risiken und Maßnahmen 72 4.2.1.1 Identifizierung und Authentifizierung 72 4.2.1.1.1 SAP-Fakten 72 4.2.1.1.2 Risiken und zu ergreifende Maßnahmen 75

GliederungSe

ite 8

4.2.1.2 Standardbenutzer 75 4.2.1.2.1 SAP* 75 4.2.1.2.2 SAPCPIC 76 4.2.1.2.3 DDIC 76 4.2.1.2.4 EarlyWatch 77 4.2.1.2.5 Batch User 77 4.2.1.2.6 Risiken und zu ergreifende Maßnahmen 77 4.2.1.3 Benutzerberechtigungskonzept: ausgewählte Berechtigungsobjekte 77 4.2.1.3.1 Berechtigungsobjekte im HCM 77 4.2.1.3.2 Berechtigungsobjekt P_ABAP 78 4.2.1.3.3 Berechtigungsobjekt P_TCODE 79 4.2.1.3.4 Berechtigungsobjekt S_TCODE 79 4.2.1.3.5 Tabelle TSTCA 79 4.2.1.3.6 Umwandlung von Reports in Transaktionen 80 4.2.1.3.7 Berechtigungsobjekt S_TABU_DIS, S_TABU_CLI und S_TABU_LIN 80 4.2.1.3.8 Berechtigungsobjekt S_TOOLS_EX 81 4.2.1.3.9 Berechtigungsobjekt S_SCD0 81 4.2.1.3.10 Objekte zur Benutzer- und Berechtigungspflege (S_USER_xxx) 82 4.2.1.3.11 Berechtigungsobjekt S_GUI und XXL-Listviewer 82 4.2.1.3.12 Risiken und zu ergreifende Maßnahmen 82 4.2.1.4 Benutzerberechtigungskonzept: ausgewählte Profile 83 4.2.1.4.1 Profil SAP_ALL 83 4.2.1.4.2 Profil SAP_NEW 83 4.2.1.4.3 Profil P_BAS_ALL 84 4.2.1.4.4 Sonstige S_xxx-Profile 84 4.2.1.4.5 Rollen mit kritischen Berechtigungen 84 4.2.1.4.6 Risiken und zu ergreifende Maßnahmen 85 4.2.1.5 Besonderheiten bei der Berechtigungsprüfung 85 4.2.1.5.1 Ausschaltung / Modifikation von Berechtigungsprüfungen 85 4.2.1.5.2 Authority-Check bei ABAP-Programmen 86 (Standardprogramm oder Eigenentwicklungen) 86 4.2.1.5.3 Berechtigungshauptschalter HR (Tabelle T77S0; GRPID „AUTSW“) 87 4.2.1.5.4 Report Berechtigungsgruppen 87 4.2.1.5.5 Risiken und zu ergreifende Maßnahmen 88 4.2.1.6 Benutzeradministration 88 4.2.1.6.1 Konzeption der zentralen Benutzeradministration 88 4.2.1.6.2 Konzeption der dezentralen Benutzeradministration 89 4.2.1.6.3 Benutzeradministration mit dem Profilgenerator 89 4.2.1.6.4 Veraltete Benutzeradministration mit Profilen 90 4.2.1.6.5 Risiken und zu ergreifende Maßnahmen 90 4.2.1.7 Änderungen am Produktivsystem 90 4.2.1.7.1 Change and Transport System 90 4.2.1.7.2 Tabellenprotokollierung / Customizing 91 4.2.1.7.3 Systemänderbarkeit 92 4.2.1.7.4 Protokolle 92

Seite

9LE

ITFA

DEN

DAT

ENSC

HU

TZ F

ÜR

SA

P ER

P 6.

0 ST

AN

D 3

0.05

.200

8, ©

DSA

G e

. V.

4.2.1.7.5 Schutz der Tabelle T000 92 4.2.1.7.6 Risiken und zu ergreifende Maßnahmen 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 Risiken und zu ergreifende Maßnahmen 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 Risiken und zu ergreifende Maßnahmen 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 103

5.1 Abgrenzungen beim Thema Outsourcing und Datenschutz 103 5.2 Vertragsgestaltung zwischen Auftragnehmer und Auftraggeber 104 5.2.1 Pflichten des Auftraggebers und Auftragnehmers 105 5.2.2 Umfang der Datenverarbeitung / Weisungen 105 5.2.3 Technische und organisatorische Maßnahmen 106 5.2.4 Wahrung der Rechte der Betroffenen 106 5.2.5 Datengeheimnis 106 5.2.6 Kontrollen durch den Auftraggeber 107 5.2.7 Datenschutzbeauftragter des Auftragnehmers 107 5.2.8 Unterauftragnehmer 107 5.2.9 Verarbeitung im Ausland 107 5.2.10 Wartung und Pflege 108 5.3 SAP-Fakten 109 5.3.1 Ausgangssituation 109 5.3.2 SAP-Administration 110 5.3.3 SAP-spezifische Maßnahmen 111 5.3.3.1 Systemadministration 111 5.3.3.2 Change and Transport Organizer (CTO / CTS) 111 5.3.3.3 Fernwartung und Services 112 5.3.3.4 RFC und ALE 112 5.3.3.5 Job-Abwicklung 113 5.3.3.6 PC-Download 113 5.3.3.7 Datenbank- und LAN-Umgebung 113

GliederungSe

ite 10

5.3.3.8 Mandantenübergreifende Funktionen 113 5.3.3.9 SAP-Protokolle 114 5.4 Risiken 114

6 BESONDERE THEMEN 116 6.1 Auditwerkzeuge: Audit Information System und Benutzerinformationssystem 116 6.1.1 Audit Information System (AIS) 116 6.1.2 Benutzerinformationssystem (SUIM) 118 6.2 SOS-Report (Security Optimization Service) 118 6.3 SAP GRC (Governance, Risk and Compliance) 119 6.3.1 SAP GRC Access Control 120 6.3.1.1 Risk Analysis and Remediation (vormals Compliance Calibrator) 121 6.3.1.2 Enterprise Role Management (bisher bekannt als Virsa Role Expert) 122 6.3.1.3 Superuser Privilege Management (bisher bekannt als Virsa FireFighter for SAP) 122 6.3.1.4 Compliant User Provisioning (bisher bekannt als Virsa Access Enforcer) 122 6.3.2 SAP GRC Process Control 122

7 GLOSSAR 124

Seite

11LE

ITFA

DEN

DAT

ENSC

HU

TZ F

ÜR

SA

P ER

P 6.

0 ST

AN

D 3

0.05

.200

8, ©

DSA

G e

. V.

1 Einführungsprozess

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

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 Rechtsvor-schriften 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 Besonder-heiten 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 Daten-felder 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 einzube-ziehen, wobei die Projektverantwortung für die ordnungsgemäße Einführung von SAP ERP der Projekt-leitung 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 ERPDas 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. Entspre-chendes 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, Betriebsverein- barung).> 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

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.2 ÜBERMITTLUNG VON PERSONENBEZOGENEN DATENGrundsä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 sicher-zustellen, 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!

1.1.3 ABRUFVERFAHRENEin 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 ZWECKBINDUNGWerden 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 AUFTRAGSVERARBEITUNGWerden 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.

3 Der Regierungsentwurf vom September 2007 sieht in §§ 29 eine Verschärfung der Regelung zur Stichprobenkontrolle vor

Seite

13LE

ITFA

DEN

DAT

ENSC

HU

TZ F

ÜR

SA

P ER

P 6.

0 ST

AN

D 3

0.05

.200

8, ©

DSA

G e

. V.

> 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 BETROFFENENDer 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 BETROFFENENEs 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 Anforderun-gen 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 JEDERMANNGemäß § 4g Abs. 2 Satz 2 BDSG hat der Datenschutzbeauftragte jedermann auf Antrag Einsicht in das

4 Der Regierungsentwurf vom September 2007 sieht in § 6a eine Ausweitung der Regelung vor5 Der Regierungsentwurf vom September 2007 sieht zusätzliche Anforderungen in § 28 für alle Scoring-Verfahren vor

1 EinführungsprozessSe

ite 14

Verfahrensverzeichnis zu gewähren. Ist kein Datenschutzbeauftragter bestellt, dann hat die Geschäfts-leitung dies sicherzustellen.

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 Betroffe- nen vorliegt oder die Erhebung, Verarbeitung oder Nutzung der Zweckbestimmung eines Vertragsver- hältnisses oder vertragsähnlichen Vertrauensverhältnisses mit dem Betroffenen dient.

1.1.10 VERPFLICHTUNG DER MITARBEITER AUF DAS DATENGEHEIMNISDas BDSG fordert, dass alle Personen, die mit personenbezogenen Daten umgehen, auf das Datengeheim-nis 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.

1.1.11 SCHULUNGDer 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 DATENSICHERHEITPersonenbezogene Daten dürfen nur erhoben, verarbeitet oder genutzt werden, wenn angemessene tech-nische 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

6 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

15LE

ITFA

DEN

DAT

ENSC

HU

TZ F

ÜR

SA

P ER

P 6.

0 ST

AN

D 3

0.05

.200

8, ©

DSA

G e

. V.

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 zugriffsbe-rechtigten 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 VORABKONTROLLEUnabhängig von der Verpflichtung der verantwortlichen Stelle, den Datenschutzbeauftragten bei der Ver-fahrenseinfü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ÜHRUNGSPROZESSDer 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.

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

Alle Geschäftsprozesse

Die gesamte Dokumentation

Alle Kunden-entwicklungen undfunktionalen Erweiterungen

Sämtliche Informationenzu Vorfällen undProblemen

Sämtliche Überwachungsdaten

Sämtliche Test-informationen

Alle Systeme

Alle Schulungs-informationen

Alle Informationenzu Serviceplanung,

Auslieferung undFollow-up

Sämtliche Änderungs-informationen

Alle Service-Level-Informationen

Sämtliche Test-informationen

SAPSOLUTIONMANAGER

SAPSOLUTIONMANAGER


ite 16

1.2 MITWIRKEN DES DATENSCHUTZBEAUFTRAGTEN BEI DER EINFÜHRUNG VON SAP ERPDas 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-PROJEKTTEAMSDie 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.2 INFORMATION DES DATENSCHUTZBEAUFTRAGTEN ZU DEN „MEILENSTEINEN“Es liegt in der Verantwortung des Datenschutzbeauftragten zu entscheiden, wann und wie er die ordnungs-gemäß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-Vorgehensmodell2.6 Geschäftsprozessdefinition2.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 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

Seite

17LE

ITFA

DEN

DAT

ENSC

HU

TZ F

ÜR

SA

P ER

P 6.

0 ST

AN

D 3

0.05

.200

8, ©

DSA

G e

. V.

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 SAP- Hinweis 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-VORGEHENSMODELLDas 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 Ein-führungsleitfäden (Grundstrukturen zur Einführung) zur Verfügung. Diese sind auch Bestandteil der SAP-Online-Dokumentation.

> Das ASAP-Vorgehensmodell bildet zum einen den methodischen Rahmen für den Einführungs- und 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


ite 18

Vorgehensmodells listen alle Aktivitäten für die Einführung des SAP-Systems auf und unterstützen die Steuerung und Dokumentation der Einführung.

Die ordnungsmäßige SAP-Einführung hängt wesentlich von der sachgerechten Nutzung der SAP-Ein-fü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

Das SAP-Standard-Vorgehensmodell und allgemeine Hinweise hierzu finden Sie auf der Dokumenta-tions-CD oder dem SAP Marketplace; http://service.sap.com.Empfehlungen zu Beteiligungsthemen des Datenschutzbeauftragten entlang des ASAP-Vorgehensmo-dells stehen in Anlage 3.Die einzelnen Themen sollten bei der Planung einer Beteiligung des Datenschutzbeauftragten durchge-gangen 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’

Die Zuordnung der Customizing-Aktivitäten der modulbezogenen Einführungsleitfäden zum Vorgehens-modell 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.

Seite

19LE

ITFA

DEN

DAT

ENSC

HU

TZ F

ÜR

SA

P ER

P 6.

0 ST

AN

D 3

0.05

.200

8, ©

DSA

G e

. V.

Suchen Sie sich die einschlägigen Aktivitäten aus den Leitfäden heraus, die Sie unter Daten- schutzgesichtspunkten bearbeiten müssen, und identifizieren Sie die modulspezifischen Ein- stellungen. 3 Nehmen Sie Kontakt mit den modulbezogenen Projektgruppen auf und sprechen Sie Ihre Aktivitäten mit ihnen ab.

1.3.2 BERECHTIGUNGSKONZEPTEin 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 DatenSAP 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.

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.


ite 2

0

1.3.3 CHANGE TRANSPORT SYSTEM / CHANGE TRANSPORT ORGANIZER (CTS / CTO)SAP empfiehlt, in einem produktiven System grundsätzlich keine Änderungen vorzunehmen bzw. zu-zulassen. Alle Änderungen sind daher aus der Test- oder Qualitätssicherungsumgebung mit dem sog. Korrektur- und Transportwesen8 in das produktive System zu übernehmen. Das gesicherte Korrektur- und 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 Systement- wicklungsumgebungsobjekte (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 werdenAus 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 personen-bezogene Daten enthalten.

1.3.4 SCHNITTSTELLENVERARBEITUNG

1.3.4.1 DATENÜBERNAHMESAP 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-Input-Schnittstelle (siehe auch Transaktion LSMW).Da die Konvertierung aus dem Alt- bzw. Vorsystem mit Programmen außerhalb des SAP ERP-Umfeldes erfolgt, ist die ordnungsgemäße Umsetzung der Daten (d. h. die 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.

8 M. Schäfer, M. Melich: SAP Solution Manager, Galileo Press, Bonn 2006 9 siehe hierzu ergänzende Hinweise in Kapitel 6 Prüfleitfaden Revision10 siehe hierzu ergänzende Hinweise in den SAP-Sicherheitsleitfäden

Seite

21

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

1.3.4.2 PC-VERARBEITUNGUp- / Download in der Anwendung (vgl. hierzu u. a. Kapitel 4.2.1.8.3)

1.3.4.3 KOMMUNIKATIONSSCHNITTSTELLENDie datenorientierte Schnittstelle Remote Function Call (RFC) ermöglicht SAP- und Nicht-SAP-Anwendungen, 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 -DOKUMENTATIONBeim 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 RISIKENBei 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.


ite 2

2

1.4.1 NICHTEINSCHALTUNG DES DATENSCHUTZBEAUFTRAGTEN BZW. DER ARBEITNEHMERVERTRETERWerden der Datenschutzbeauftragte und − soweit vorhanden − die Mitbestimmungsorgane (Arbeitneh-mervertretung) nicht rechtzeitig sowohl bei der Einführung als auch bei allen nachfolgenden Änderun-gen 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-EMPFEHLUNGENDie 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 ordnungs-gemäß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.3 NICHTBERÜCKSICHTIGUNG BZW. VERSPÄTETE ERSTELLUNG DES BERECHTIGUNGSKONZEPTESWä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 DATENVERARBEITUNGS- PROGRAMMSDie 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

Seite

23

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

> 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. Beliefe- rungssysteme) 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 Produktiv- umgebung> Wird das CTS nicht oder falsch eingesetzt, können nicht autorisierte Programme / Objekte zur unzu- lässigen Nutzung oder Verarbeitung personenbezogener Daten führenDie 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 / CHECKLISTEZur 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 SAP- Projektes rechtzeitig berücksichtigt?5 Sind dem Datenschutzbeauftragten rechtzeitig ausreichende Unterlagen, insbesondere für die Vorabkontrolle, zur Verfügung gestellt worden?6 Ist der Datenschutzbeauftragte in die Projektarbeit angemessen eingebunden?7 Welche personenbezogenen Daten sollen gespeichert werden?8 Welche personenbezogenen Daten sollen an externe Empfänger aus welchem Grund (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?


ite 2

4

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 steuer- lichen 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 Daten- geheimnis 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)?

Seite

25

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

2 Aufgaben des DatenschutzbeauftragtenDa der DSB in der Regel kein SAP-Spezialist ist, wird er mit unterschiedlichen Mitarbeitern des Unterneh-mens zusammenarbeiten. Er wird sich im Rahmen seiner Tätigkeit sowohl mit Anwendern der Fachabtei-lungen als auch mit DV-Mitarbeitern austauschen. Ebenso ist eine Kooperation mit anderen Organisations-einheiten 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-Standard-rollen 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-Human-Resources

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öglicheneinen 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

11 Siehe hierzu auch die SAP-Hinweise 754273 und 451960

Seite

26

Die Rollen sind wie folgt zu finden: Menüpfad: Werkzeuge → Administration → Benutzerpflege → Rollenverwaltung (PFCG)

Die SAP-Auditor-Rollen sind sehr spezifisch auf einzelne AIS-Funktionen hin definiert. Die 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

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; ...

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 ERP-Systems abzuleiten.

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

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

2 Aufgaben des Datenschutzbeauftragten2.1.1 EINBEZIEHUNG DES DSB VOR UND WÄHREND DER PROGRAMMENTWICKLUNG UND -ANPASSUNGDie 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 Programmschnitt-stellen 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 Program-men 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ÄSSIGKEITDie Ü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 PROTOKOLLIERUNGIn 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 VERFAHRENSDOKUMENTATIONZur Überwachung der Programmanwendung durch den DSB ist eine aussagefähige Verfahrensdokumen-tation erforderlich, die insbesondere über folgende Punkte Auskunft geben soll:> Aufgabenstellung der Anwendung (i.S. der Zweckbindung), insbesondere mit Hinweisen auf

Seite

28

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 System-funktionen finden sich insbesondere in den Abschnitten 2.3.3 ff und 2.4.

2.1.5 MITWIRKUNG BEI DER FESTLEGUNG UND ÜBERPRÜFUNG DES BERECHTIGUNGSKONZEPTESDer DSB ist an der Erarbeitung eines organisatorischen Rahmens zur Ausgestaltung des Berechtigungs-konzeptes 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 Unternehmens- organisation(en) auf die SAP-Struktur / Organisationsebene von Systemen, Mandanten, Buchungs- kreisen, Werken, Personalbereiche etc.

Seite

29

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

2 Aufgaben des Datenschutzbeauftragten> 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 nachweis- pflichtige 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 BETREIBERORGANISATIONDer 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 Kommunikationseinrich-tungen, der Netzwerke, des Betriebssystems und des Datenbankmanagements verstanden.

Seite

30

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 SAP- Berechtigungsschutz umgangen werden.> Es darf nur ein sehr eng begrenzter Kreis von Administratoren Zugriff auf Datenbanktabellen und SAP- Daten auf Betriebssystemebene erhalten.

Für den Betrieb eines SAP ERP-Systems wird im Regelfall eine Betreiberorganisation (BO, verantwortlich für die spezifische Administration des SAP ERP-Systems) notwendig werden, die insbesondere an Gewicht gewinnt, wenn mehrere Unternehmen / Behörden über ein System abgewickelt werden sollen. Die Betreiberorganisation kann dabei zentral oder dezentral oder durch eine Kombination von beiden Alternativen organisiert werden. > Den Vorteilen einer dezentralen Betreiberorganisation wie die Nähe zum Anwender und die flexible organisatorische Zuordnung der BO in den Unternehmen / Behörden oder die Gewährleistung der Harmonisierung der Arbeitsabläufe stehen die Nachteile einer hö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 SAP- System abgewickelten Unternehmen / Behörden eingeschränkt bzw. die Durchsetzung von gesellschafts- individuellen Anforderungen bei übergreifenden Einstellungen schwierig sein. Auch können Interessen- konflikte 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.

2.1.7 ABFASSUNG EINER DATENSCHUTZERKLÄRUNG 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

Seite

31

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

2.1.8 ÜBERWACHUNG DES KORREKTUR- UND TRANSPORTWESENS UNTER SAP ERPUm 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 BETRIEBZur Ü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 DATEN- GEHEIMNIS (§§ 4G UND 5 BDSG)

2.2.1 PERSONENKREIS, DER GESCHULT UND VERPFLICHTET WERDEN MUSSBei 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 > ProjektmitgliederZu 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 Aufgaben des DatenschutzbeauftragtenSe

ite 3

2

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.2 INHALT DER ANWENDERSCHULUNGENDer 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 Ver-pflichtungserklä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.

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 Daten-geheimnis 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)

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.

Seite

33

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

Ü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-Personalentwick-lung 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 VERANSTALTUNGSMANAGEMENTFü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 Veranstaltun-gen 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.

§ 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 Daten- kategorien 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


ite 3

4

Die öffentlichen Stellen haben nach §18 Abs. 2 BDSG inhaltlich weitgehend ähnliche Angaben zu machen, sind aber per Gesetzestext auf die schriftliche Dokumentation verpflichtet.

§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 einge- schrä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 öffent-lichen 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 IT-Anwendungen (Software, Anwendungsprogramme, Geschäftsprozesse) sowie weitere Angaben (zuständige Administratoren, personenbezogene Daten) gefordert. Dies bietet die Grundlage für das betriebsinterne Verfahrensverzeichnis.

VERANTWORTLICHKEITENIm Rahmen der Novellierung des BDSG im Jahr 2001 wurde die Aufgabenteilung zwischen der DV-Abteilung 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 arbeits- rechtliche Konsequenzen nach sich ziehen als auch bei Vorliegen der Voraussetzungen als Ordnungs- widrigkeit oder Straftatbestand verfolgt werden.

Es bietet sich an, diese Klarstellung den Verantwortlichen mit der Aufforderung zur Erstellung der Übersichten zukommen zu lassen.

Seite

35

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

FORM DER DOKUMENTATIONWä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 be-triebsinternes Verfahrensverzeichnis besteht jedoch nicht.

DAS ÖFFENTLICHE MELDEREGISTERDas ö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 Trans-parenz 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).

DAS BETRIEBSINTERNE VERFAHRENSVERZEICHNISDas 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ägi-gen SAP-Funktionalitäten (z. B. ABAP Dictionary, AIS) zur Unterstützung herangezogen werden können.


ite 3

6

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.

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 Ver- antwortlichen 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.

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, Konfessi-onsschlüssel oder Veteran Status). In Abschnitt 2.4 wird dargestellt, wie man zum Inhalt und zur Dokumen-tation 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.

Seite

37

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

2.3.1 INFORMATIONEN ZUR VERANTWORTLICHEN STELLEHier werden die Punkte eins bis drei des öffentlichen Melderegisters zusammengefasst. Die Informationen über den Firmennamen, die Anschrift und die Geschäftsleitung eignen sich am besten zu einer Internet-Darstellung in einer Art Impressum.

2.3.2 ZWECKBESTIMMUNGEN DER DATENERHEBUNG, -VERARBEITUNG ODER -NUTZUNGANFORDERUNG:§ 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 verschie-densten 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 DATENKATEGORIENANFORDERUNG: Alle betroffenen Personengruppen und deren Daten oder Datenkategorien sind aufzuführen. Dabei ist von dem datenschutzrechtlichen Begriff der automatisierten Verarbeitung auszugehen und nicht vom EDV-technischen Dateibegriff. Die Beziehung zu den Bezeichnungen auf Datenbank- oder Betriebssystemebene sollte nachvollziehbar sein, muss aber nicht zwingend in die Übersicht mit aufgenommen werden. Benutzerdaten sind auch aufzunehmen (siehe 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.

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


ite 3

8

> Partnerdaten > Sachbearbeiterdaten > Verkäufergruppendaten > Patientendaten > SAP-Benutzer (Stammdaten der Benutzerverwaltung)Diese Personengruppen sind in verschiedenen Report-Varianten in der Mappe ‚Dateiregister zu personen-bezogenen 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 JAVA-Welt. Die bekannten Domänen mit Personenbezug sind im AIS nicht vollständig abgebildet.Außerdem bietet das SAP ERP-System weitere Funktionen für die Dokumentation / Beschreibung von Daten (z. B. im ABAP Dictionary), die im Abschnitt 2.4 detaillierter dargestellt werden.

AUSLEGUNG DER GESETZLICHEN ANFORDERUNG IN BEZUG AUF SAP ERP: § 4g BDSG in Verbindung mit § 4e Ziffer 5 BDSG verlangt von der verantwortlichen Stelle, dem Daten- schutzbeauftragten u. a. eine Beschreibung der betroffenen Personengruppen und der diesbezüglichen Daten oder Datenkategorien zur Verfügung zu stellen.

Es stellt sich die Frage, wie genau die Personengruppen und die diesbezüglichen Daten 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 (Dokumentati-ons- / 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 gespei-chert. 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.

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.

Seite

39

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

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 Daten-schutzbeauftragten 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 Mit-bestimmung nach § 87 Abs. 1 Satz 6 BetrVG bzw. § 75 Abs. 3 Satz 17 BPersVG.

2.3.4 EMPFÄNGER ODER KATEGORIEN VON EMPFÄNGERNGrundsä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 (Sozialversi-cherung, Finanzamt, DEÜV usw.).


ite 4

0

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 Projekt-dokumentation 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.

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

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)

Menüpfad: Werkzeuge → ABAP Workbench → Übersicht → Infosystem → ABAP Dictionary → Datenbanktabelle bzw. Programmbibliothek → Programme / Teilobjekte zu Programmen → Dynpros

Seite

41

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

> 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 personen-bezogenen 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ücksichti-gung lokaler Bestimmungen.Gemäß § 3a Bundesdatenschutzgesetz (BDSG) haben sich Gestaltung und Auswahl von Datenverarbeitungs-systemen 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 zugeord-net 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 Mindestauf-bewahrungsfristen, 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,

2 Aufgaben des Datenschutzbeauftragten

13 Diesem Abschnitt liegen folgende Quellen zugrunde: Abel, Datenschutz, Band 2, Teil 6

Seite

42

betreffend Löschung und Mindestaufbewahrung, in der Praxis einer Ausgestaltung – aufgrund von aktueller Rechtsprechung – bedürfen. Eine Vielzahl bestehender Rechtsprechung zu Löschungs- und Mindestaufbe-wahrungsfristen ist bereits ergangen. Weitere gerichtliche Entscheidungen werden noch folgen, sodass auf die vorliegende Thematik stets ein „juristisches Auge zu werfen ist“.

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 STELLENDie 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ältnis- mäß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:

> BERUFSGENOSSENSCHAFTEN, spezielle gesetzliche berufsgenossenschaftliche Aufbewahrungs- pflichten bestehen grundsätzlich nicht, dennoch empfehlen die Berufsgenossenschaften in ihrem BG- Blatt B36, Ausgabe Oktober 2005, dass für Unterweisungen zur Arbeitssicherheit und zum Gesundheits- schutz eine Aufbewahrungsfrist von mindestens zwei, besser fünf Jahren in Betracht gezogen werden sollte,> ERZIEHUNGSREGISTER, Maßnahmen nach dem Jugendgerichtsgesetz, Verfügungen des Vormund- schaftsgerichts; 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-

14 siehe BDSG Kommentar Gola / Schomerus, §§ 3 Rn. 40

Seite

43

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

archiv zur Überlassung anzubieten (§ 2 Abs. 1), dabei bleiben Rechtsvorschriften betreffend die Vernich- tung (§ 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 STELLENWas 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, Personenge-sellschaften 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.

§ 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


ite 4

4

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

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 Eck-punkte 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 STEUERRECHTsechs Jahre (§ 257 Abs. 4 HGB, §147 Abs. 3 AO)zehn Jahre (§ 257 Abs. 4 HGB, §147 Abs. 3 AO)

ARBEITS- UND SOZIALRECHT, BERUFSORDNUNGENDie Aufbewahrungsvorschriften erstrecken sich aufgrund gesetzlicher Vorgaben vonzwei 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 Finanztrans- aktionen (§ 9 Abs. 3 GwG),zehn Jahre Jugendarbeitsschutz-Unterlagen – ärztlicher Untersuchungsbogen – (§ 4 Abs. 2 JArbSchUV),

Des Weiteren gibt es noch spezielle Aufbewahrungsvorschriften eingeteilt nach Kategorien und Bereichen wie z. B.:> für die Dauer des Arbeitsverhältnisses bis Anfang eines jeden Jahres,> bis zum Ausscheiden eines Arbeitnehmers,> bis zum Ablauf des auf die letzte Prüfung folgenden Kalenderjahres,> bis zum Ablauf des Kalenderjahres, das auf das Jahr der Anlegung von Listen folgt.

AUFBEWAHRUNGSVORSCHRIFTEN IN DER DATENVERARBEITUNG (§ 9 BDSG UND ANLAGE ZU § 9 BDSG, §147 ABS. 5 AO, § 257 ABS. 3 HGB)ein Jahr Job-Accounting, Netzwerkdaten, Systemnachrichten, Begleitpapiere und Protokolle über Datenträgertransport und -verwaltung, 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).

Seite

45

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

DATENVERARBEITUNG IN BESONDEREN FÄLLENPROTOKOLLDATEIENEine 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, Warnmel-dungen 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 Inhaltebestehender 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 Proto-kolle – im Zusammenhang mit Tabellenzugriffen – weit verbreitet, sodass hier nicht nur datenschutzrecht-liche Normen, sondern auch betriebsverfassungsrechtliche Aspekte tangiert sind. Da den meisten SAP-Anwendern 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 datenschutz-rechtlichen 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.

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 ver-absä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 Proto-kollen 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 abrechnungs- und steuerrelevanten Vorgängen die Verwendung von klassischen, d. h. nicht anonymen Protokollen notwendig.


15 siehe Abel, Datenschutz, Band 2, Teil 6 / 2.4.1.416 siehe Abel, Datenschutz, Band 2, Teil 6 / 2.4.1.4

Seite

46

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 Datensiche-rung 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 Log-Files möglich).

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 „SAP-User“ eine Rechnung storniert hat. Gerade in diesen Fällen ist eine Protokollierung schon zur Revisions- sicherheit unumgänglich.

BEWERBUNGSUNTERLAGENDas Bundesarbeitsgericht stellte in seinem Urteil vom 6. Juni 1984 fest, dass eine längerfristige Aufbewah-rung 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 abgeschlos-sen 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 SCHULDNERVERZEICHNISSENHandels- 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

19 Simitis, Kommentar BDSG, S. 1030 Rn. 162

Seite

47

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

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 – Schuldnerver-zeichnisverordnung). Eine Eintragung im Schuldnerverzeichnis wird nach Ablauf von drei Jahren gelöscht. Für Schuldnerdaten, die nach § 26 Abs. 2 InsO – aufgenommen wurden, gilt eine Löschungsfrist von fünf Jahren.

FAZITIm 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-Spezia-listen (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 einzu-fordern, da diese Stelle die Verantwortlichkeit für die Umsetzung der vorgeschriebenen Aufbewahrungs- und 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 DRITTSTAATENDieser 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-kon-formen 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-


20 Az: 5 AZR 286 / 81, Urteil vom 6. Juni 1984

Seite

48

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.7 MASSNAHMEN ZUR GEWÄHRLEISTUNG DER SICHERHEITDas 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 Zusam-menhang 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 Umset-zungsmöglichkeiten im SAP ERP. Insbesondere Authentifizierung, Benutzeradministration, Berechtigung und Autorisierung werden hier ausführlich behandelt.

2.3.8 ZUGRIFFSBERECHTIGTE PERSONEN Zugriffsberechtigungen auf die Daten von Einzelpersonen bzw. Personengruppen werden über Rollen bzw. Profile im SAP ERP vergeben und administriert. Die Rollen bzw. Profile 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 zugriffs-berechtigten Personen im SAP ERP-System.

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

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

2 Aufgaben des DatenschutzbeauftragtenBeispiel 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 Berechtigungs-konzept 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 MELDEREGISTERDie 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

Seite

50

ÖFFENTLICHER TEIL

Name / Firma verantwortliche Stelle

Inhaber, Vorstände, Leiter DV

Anschrift der verantwortlichen Stelle

Zweckbestimmungen der Datenerhebung, -verarbeitung oder -nutzung

SAP ERP HCM: Personaladministration, Personalab-rechnung, Organisationsmanagement, Zeitwirtschaft, Personalbeschaffung, Personalbetreuung (Vergütung, Arbeitgeberleistungen, Altersvorsorge), strategische PersonalplanungSAP for Healthcare: Patientenmanagement, Patientenab-rechnung, klinische Auftragsabwicklung (Partner), medizinische DokumentationSAP EH&S: Gesundheitsdienst, ArbeitsschutzSAP ERP FI: Pflege und Service für Kunden und Lieferanten SAP CRM: Marketingplanung und Kampagnenmanage-ment, Telemarketing, Kontaktmanagement, Kundenser-vice Interaction Center, Internet Customer Self-Service, Servicemanagement, Einsatzplanung

Betroffene Personengruppen und diesbezügliche Datenkategorien

PERSONEN: Mitarbeiter, Bewerber, Kunden, Lieferanten, Versicherungsnehmer, Patienten

DATEN: Mitarbeiter-, Bewerber-, Kunden-, Lieferanten-daten 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

Empfänger oder Kategorien von Empfängern Vertragspartner, Banken, Bausparkassen, Versicherun-gen, Finanzamt, Krankenkassen, Versorgungsanstalten, Auftragsdatenverarbeiter

Regelfristen für die Löschung der Daten Allgemein: Periodische Löschung nach Ablauf der gesetzlichen AufbewahrungsfristenDetailliert: > 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

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

2 Aufgaben des DatenschutzbeauftragtenNICHT Ö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ÜTZUNGIm 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 Verwendungsnach-weis 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.

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

Seite

52

2.4.1 AUSWERTUNGEN ZUR TABELLEN- UND FELDANALYSEIm 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* PersonalstammdatenHRP1* PersonalplanungsdatenPA2* Zeitdaten PB0* Stammdaten BewerberPB4* BewerberdatenPCL* Clustertabellen (HCM)KN* KundenstammLF* LieferantenstammSADR* Adressverwaltung

Menüpfad: Werkzeuge → ABAP Workbench → Entwicklung → Dictionary (SE12): Objektname PA0* als Datenbanktabelle: Anzeigen oder Drucken

Mit Hilfe dieser Übersichten können über das ABAP Dictionary gezielt einzelne Tabellen 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).

Folgende Reports bieten einen Überblick über die Infotypen:Infotypen und Subtypen (Report RPDSHOWI) listet die Infotypen und Subtypen mit Angabe der Infotyp-struktur 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.

Seite

53

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

2 Aufgaben des DatenschutzbeauftragtenAuß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 ÄnderungAS4USER Autor der letzten ÄnderungBNAME Benutzername BUSAB Nummer des Buchhaltungs-SachbearbeitersDDUSER Dictionary: letzter ändernder BenutzerDWNAM Name des zuständigen SachbearbeitersRALDB_NAME Name des Erstellers / Änderers der VarianteSACHA Sachbearbeiter Abrechnung / Personal / ZeiterfassungUNAME BenutzernameUBNAME BenutzernamenUSERNAME Benutzername (SAP-Benutzer) USNAM Name des BenutzersXUBNAME Benutzername im Benutzerstamm XUSER Benutzername

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)

Seite

54

In der Systemlogdatei (SM21) wird der Benutzername festgehalten:Feldname: Benutzer

2.4.2 TECHNIKEN ZUM AUFFINDEN PERSONENBEZOGENER DATEN VARIANTE 1: BEI PROJEKTEINFÜHRUNG In der Einführungsphase werden vom Projektteam mit dem Datenschutzbeauftragten und dem Betriebs- bzw. Personalrat die zulässigen personenbezogenen Daten festgelegt und deren Auswertungen überprüft.Hierbei werden die entsprechenden Transaktionen, Dynpros und Reports analysiert.

Durch Sperren von Transaktionen und Reports sowie durch Dynprovariationen im 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 Infor-mationen, 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.

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 SystemTabellen mit Personenbezug sind im SAP-System nicht als solche bezeichnet, können aber mit dem ABAP Dictionary über Domänen ermittelt werden.

Wichtige Domänen: AFNAM Name des Anforderers in der BestellanforderungAPLNO BewerbernummerAPLNR BewerbernummerCATSXT_CALLER_ID Identifikation des AufrufersDISPO DisponentEKGRP EinkaufsgruppeKUNNR KundennummerLIFNR Kontonummer des LieferantenNAME Name eines Partners

Seite

55

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

2 Aufgaben des DatenschutzbeauftragtenFALNR Fallnummer (im IS-H)PATNR Patientennummer (im IS-H)PERSNO PersonalnummerPERNR PersonalnummerVKGRP Verkäufergruppe

Folgende Domänen haben ebenfalls Namensbezug:BDEUNAME Benutzer im DASSCYFC_NAME Name des Erstellers / Änderers einer AblaufsteuerungDOKU_USER BenutzernameHIER_USER BenutzernameI_PARNR Partner (Partnerpflege PM)J_1BPARID Partneridentifikation (Kunde, Lieferant, Branch)KUNDE Partnernummer (KUNNR, LIFNR, PERNR, PARNR)NA_PARNR PartnernummerQPRUEFER Name des PrüfersRFC_TC_ID Benutzername des persönlichen Talentberaters SC_OWNER Benutzername (Terminkalender)SPARTNR PartnernummerSO_ADRNAM SAPoffice: Adressname eines OfficebenutzersSO_SADRNAM SAPoffice: abgekürzter Adressname STAT_USER Statistik, AccountTDUSER TDIC UserUDUSER AutorXUAUTH BerechtigungsnameXUNAME1 Name des Benutzers (Adresse)

Das Datenelement GPART Geschäftspartner (z. B. Ärzte im SAP for Healthcare) kann ebenfalls Personen-bezug haben (Domäne: RI_Rolle).Um mit Hilfe des Reports RSCRDOMA aus dem Audit Information System ein firmenspezifisches Verfah-rensregister 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 DatenfeldernIm 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

> 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.

Seite

56

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.

2.4.3 PRÜFUNG DER ZUGRIFFSBERECHTIGUNGENDas BENUTZERINFORMATIONSSYSTEM bietet eine maschinelle Unterstützung, um die Zugriffsberechti-gungen 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.

Welche Benutzer (mit Adressdaten) gibt es im SAP-System?SUIM-Berichtsbaum anzeigen (siehe oben) Menüpfad: Infosystem → Benutzer → Benutzer nach Adressdaten → Liste erzeugen →* zeigt alle Benutzer an ÄNDERUNGSBELEGE für Benutzer, Profile, Berechtigungen und Rollen sind direkt aus dem SUIM-Berichtsbaum und im AIS über die Schaltfläche Änderungsbelege aufrufbar (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*.

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.

Seite

57

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

2 Aufgaben des Datenschutzbeauftragten Ü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 Buchungs- kreis, 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_NEWRollen RSUSR070, RSSCD100_PFCGProfile RSUSR020Berechtigungsobjekte RSUSR030, RSUSR040Berechtigungen RSUSR030 Transaktionen RSUSR010Vergleiche RSUSR050Verwendungsnachweise RSUSR002, RSUSR020, RSUSR030, RSUSR070 (SAP-Hinweis 608661), RSUSR060OBJÄnderungsbelege RSUSR100, RSUSR101, RSUSR102, RSSCD100_PFCG

Weitere Reports:RSUSRSUIM BenutzerinformationssystemRHUSERRELATIONS Benutzerzuordnungen anzeigen (für HCM-Berechtigungsobjekte)RSUSR000 Aktive Benutzer RSUSR003 In allen Mandanten die Kennwörter der Standard-Benutzer prüfenRSUSR005 Liste der Benutzer mit kritischen BerechtigungenRSUSR006 Gesperrte Benutzer und Benutzer mit Falschanmeldungen RSUSR012 Suche Berechtigungen, Profile und Benutzer mit bestimmten Objektwerten RSUSR060OBJ Verwendungsnachweis Berechtigungsobjekt in Programmen und TransaktionenRSUSR200 Liste der Benutzer nach Anmeldedatum und Kennwortänderung

Seite

58

Seite

59

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

3 Rechte der Betroffenen und von jedermannRECHTE DER BETROFFENENGrundlage 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 JEDERMANNEine 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 Betroffe-nen 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 ANFORDERUNGENIn der Regel werden personenbezogene Daten in SAP ERP-Systemen nur auf Basis einer (vor-)vertraglichen Grundlage (z. B. Arbeitsvertrag, Kaufvertrag) gespeichert. Daher wird die Benachrichtigungspflicht in der Regel durch die Information bei der Erhebung (§ 4 BDSG) verdrängt (zu Ausnahmen bei CRM-Systemen s. Leitfaden hierzu). Daher sind Benachrichtigungen und die Beantwortung von Auskunftsersuchen (Antrag des Betroffenen erforderlich) individuell zu behandeln.

Bei der Benachrichtigung sind Angaben zu einer konkreten Verarbeitung in allgemeiner Form zu machen, z. B. Datenkategorien, Kategorien möglicher Empfänger. Die Frage, ob eine Benachrichtigungs- pflicht 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).

Seite

60

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.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 Arbeitneh-mer, 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.

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. datenschutz-rechtlich 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 Auskunfts- erteilung 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.

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:

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

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

3 Rechte der Betroffenen und von jedermannABAP 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 (Transak- tion 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 Feldbezeich- nung zu schreiben. 5 Schritt 3 und 4 sind für alle in Frage kommenden Tabellen zu wiederholen.

SONSTIGE MÖGLICHKEITENEs 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 FACHMODULEEs 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 Sachbearbei-tern 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 (Bereichs-menüpflege Transaktion SE43N) dem Endbenutzer zur Verfügung gestellt werden.

ÜBER REPORTSZu 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.

ÜBER QUERYSSind 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.

Seite

62

Je nach Query-Werkzeug (SAP-Query, Ad-hoc-Query und Qick-Viewer) sind unterschiedliche Berechtigun-gen 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 Tabellen-berechtigungen (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 Berechtigungs- konzept für Tabellen gibt, das auf Datensatz- / Datenfeldebene die Risiken bewertet.

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.

3.2 BERICHTIGUNG, LÖSCHUNG UND SPERRUNG

3.2.1 RECHTLICHE ANFORDERUNGENDie 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)?

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)?

Seite

63

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

3 Rechte der Betroffenen und von jedermann3.2.2 SAP-FAKTENEs 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 DATENSCHUTZESAuß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?

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

64

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.

Seite

65

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

4 Umsetzung der Anforderungen aus §9 BDSG und Anlage: technisch-organisatorische Maßnahmen4.1 ANFORDERUNGENIn diesem Abschnitt werden die technisch-organisatorischen Anforderungen an die Verarbeitung personen-bezogener 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 ANFORDERUNGENDie 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.

Seite

66

ZIELE DER GESETZLICHEN ANFORDERUNGEN:Es ist laut Anlage zu § 9 BDSG

ANSATZPUNKTE AUFSEITEN DES SAP ERP-SYSTEMS

WEITERFÜHRENDE HINWEISE

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 Datenver-arbeitungssysteme von Unbefug-ten genutzt werden können(ZUGANGSKONTROLLE)

personenbezogenes Anmelde-verfahren (problematisch bei mehreren Benutzern an einem Gerät; dann müssen zusätzliche Hilfsmittel (wie Chipkarten und PC-Sicherheitssysteme sicher-stellen, dass die Anwender ohne Belastung zwischen ihren An-meldungen wechseln können);

Auto-Logoff nach einer vorgegebenen Zeit; Bildschirmschoner mit Kenn-wortschutz;

Single-Sign-On-Ergänzung und Anschlussmöglichkeiten für Chipkarten

Die SAP NetWeaver und SAP ERP Central Component Sicherheitsleitfäden27

SAP NetWeaver Sicherheitsleitfaden

SAP NetWeaver Sicherheitsleitfaden

3) zu gewährleisten, dass die zur Benutzung eines Datenverarbei-tungssystems Berechtigten aus-schließlich auf die ihrer Zugriffs-berechtigung 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)

innerhalb des SAP NetWeaver mit Hilfe eines angepassten Be-rechtigungskonzeptes für den ABAP-Stack und den JAVA-Stack, welches den Anforderun-gen von SAP, des Revisionsleitfa-dens und des Datenschutzes gerecht wird;außerhalb des SAP NetWeaver: Verschlüsselung im Netz, restrik-tive Vergabe von Berechtigungen auf SAP-Dateien und Tabellen auf der Ebene der Datenbank und des Betriebssystems;

Download

SAP-Dokumentation SAP-NetWeaver (help.sap.com)

Frank Off / Mario Linkies, „Sicherheit und Berechtigungen in SAP Systemen“, Gallileo Verlag 2005DSAG Prüfleitfaden FISAP NetWeaver SicherheitsleitfadenSAP GRC Access Control: Analyse und Administration von SAP-Berechtigungskon-zepten (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

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

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 ÜBER-TRAGUNG oder während ihres Transports oder ihrer SPEICHE-RUNG 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 PERSONENBE-ZOGENER DATEN DURCH EIN-RICHTUNGEN ZUR DATENÜBER-TRAGUNG VORGESEHEN IST(WEITERGABEKONTROLLE)

innerhalb des SAP ERP mit Hilfe eines angepassten Berechti-gungskonzeptes 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 SAP-Router;Einstellungen der Berechtigungen;

der geforderte Nachweis gem. §10 Abs.4 BDSG wird nicht unterstützt.

SAP-Systemdokumentation

SAP NetWeaver Sicherheitsleitfadenggf. Stichproben über Trace

5) zu gewährleisten, dass nachträglich überprüft und festgestellt werden kann, OB UND VON WEM personenbezogene Daten in Datenverarbeitungssyste-me 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

Funktionen zur Anzeige der Änderungsbelege in den jeweiligen Fachfunktionen

Empfehlungen der SAP-Sicherheitsleitfäden

6) zu GEWÄHRLEISTEN, dass personenbezogene Daten, die im Auftrag verarbeitet werden, nur entsprechend den Weisungen des Auftraggebers verarbeitet werden können (AUFTRAGSKONTROLLE)

Im Standard ist keine besondere Unterstützung vorgesehen. Die Kontrolle der Auftragsdaten-verabeitung 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

GRC Process Control (siehe Kapitel 6)

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

Seite

68

7) zu gewährleisten, dass perso-nenbezogene Daten gegen zu-fällige Zerstörung oder Verlust geschützt sind (Verfügbarkeitskontrolle)

regelmäßige Datensicherung auf der Ebene der Datenbank;Datensicherungskonzeptan die Aufgaben angepasste Berechtigungen;Protokollierung der wichtigsten Datenänderungen;angemessene Schulung der Anwender

SAP-Systemdokumentationsiehe die allgemeinen Empfeh-lungen der SAP-Sicherheits-leitfä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, insbe-sondere 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 Verhaltensaus-wertungen führen. Insbesondere kostenrechnungsrelevante und produktionsbezogene Daten sind besonders zu betrachten.

vgl. Prüfleitfäden des DSAG AK Revision und Dokumentation

Empfehlungen der SAP-Sicher-heitsleitfäden

Seite

69

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

4.2 SAP-FAKTEN, RISIKEN UND MASSNAHMENMit 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:

© SAP AG 2004, RFC Sicherheit/[email protected]/32

THE BEST-RUN BUSINESSES RUN SAP

OpenSQL

EJB

WebDynpro

OpenSQL

FM /BAPI

WebDynpro

JAVA-Schema

ABAP-Schema

JCo

JAVAPresentation Layer ABAP

Persistence

Business Layer

Business relevantauthority check basedon UME roles

recommendedConnectivity betweenABAP and JAVA

NOT recommendedConnectivity betweenABAP and JAVA

Business relevantauthority check basedon ABAP roles


Seite

70

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 verdeutli-chen: Im Portal können etwa über iViews auf dieser Ebene Verknüpfungen von zwei separaten Datenbe-stä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 JAVA- Ebene 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 ABAP-FAKTEN, RISIKEN UND MASSNAHMEN

4.2.1.1 IDENTIFIZIERUNG UND AUTHENTIFIZIERUNG

4.2.1.1.1 SAP-FAKTENBevor 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 Startparame-tern 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.

> 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

71

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

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än- derten 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 Verfalls- dauer 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).


Seite

72

> 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 SAP- fremder Bildschirmschutz mit Kennwort normalerweise nach 15 Minuten aktiviert werden.)

Wie der Vorgang der Anmeldung am System durch Parameter gesteuert wird, ist auch die Berechtigungs-prü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 Trans- aktion 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.

Seite

73

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

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. Datei- operationen, 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 MASSNAHMENUm 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 Berechtigungs-konzept 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 ERP-System eingebunden ist – weitere und auch externe Sicherheitsprodukte empfehlenswert. Solche sind z. B. SNC (Secure Network Communications – Authentication) oder bei der Verwendung von Web-Frontends sogenannte X.509 Client Certificates. Für SNC steht auf dem Service-Marktplatz ( http://www.service.sap.com/swdc ) → Download → SAP Cryptographic Software die Cryptographic Library zum Download zur Verfügung, dabei ist auch der SAP-Hinweis 397175 zu beachten.

4.2.1.2 STANDARDBENUTZEREs 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 Standard-benutzer besonders zu schützen.

4.2.1.2.1 SAP*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 Sicherheitsleit-faden) 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 Benutzer-gruppe „SUPER“ zugeordnet werden, um zu verhindern, dass dieser User leichtfertig gelöscht werden kann.


Seite

74

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.2 SAPCPICDer 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 ERP-System. Er wird benötigt, um Performance-Daten zu sammeln, externe Hintergrundprogramme zu starten und Werte für das Computer Center Management System (CCMS) zurückzuliefern.Als Schutzmaßnahme kann neben der Änderung des Standardkennworts auch die Sperrung des Benutzers erwogen werden. Bei Durchführung dieser Maßnahmen sollte SAP-Hinweis 29276 beachtet werden.Grundsätzlich sollten CPIC-Benutzer, auch wenn eine Anmeldung im Dialog nicht möglich ist, über funk-tionsbezogenen Rollen / Profile verfügen.

4.2.1.2.3 DDICNeben 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 System-rechte 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 Anforderun-gen 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 EARLYWATCHDer 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.

Seite

75

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

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 USERBatch 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.

4.2.1.2.6 RISIKEN UND ZU ERGREIFENDE MASSNAHMENUm 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 BERECHTIGUNGSOBJEKTEIm 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 (Transak-tion SUIM) zu erhalten.

4.2.1.3.1 BERECHTIGUNGSOBJEKTE IM HCM 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-Info-typen bearbeitet werden sollen. Wesentlich sind hierbei die organisatorische Zuordnung des Mitarbeiter-stammes, die Sicht auf Daten (Infotypen) und der Berechtigungslevel. Das Berechtigungsobjekt besteht aus folgenden Feldern:AUTHC Berechtigungslevel INFTY InfotypSUBTY SubtypPERSA PersonalbereichPERSG MitarbeitergruppePERSK MitarbeiterkreisVDSK1 Organisationsschlüssel Weiterhin sind hinsichtlich des Berechtigungslevels (vgl. bzgl. weiteren Details die Dokumentation des


Seite

76

Berechtigungsobjekts) u. a. folgende Werte von Bedeutung:R LesenW SchreibenM 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 schreibenD ändern des Sperrkennzeichens* alle OperationenNeben 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üfungDie 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 Stammda-tenpflege 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_ABAPFü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 zugegrif-fen 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 Reportszur Prüfung der Berechtigungen für HCM-Infotypen verwendet werden. Durch eine entsprechende Aus-steuerung 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-

Seite

77

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

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_TCODEDas 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 Trans-aktionscode (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 Berechtigungs-gruppe 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).

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


Seite

78

Objekte ausgeschaltet werden, dies gilt aber nicht für HCM und Basisobjekte. Zu beachten ist, dass Zugriffsberechtigungsprüfungen umgangen werden können, indem der Authority- Check (Berechtigungsprüfung) in den der Transaktion zugrunde liegenden ABAP-Programmen ausgeschaltet wird.

4.2.1.3.6 UMWANDLUNG VON REPORTS IN TRANSAKTIONENSAP 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 be-sitzt. 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.

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.

Das Berechtigungsobjekt S_TABU_LIN definiert Berechtigungen für die Anzeige oder Pflege von Tabellen-inhalten. 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 Berech-tigungsobjekts ist die Existenz von Organisationskriterien. Organisationskriterien stehen für betriebswirt-schaftliche 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 →

Seite

79

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

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 PA-Tabellen) 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_SCD0Das 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 Berechtigungs-objektes 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)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.


Seite

80

4.2.1.3.11 BERECHTIGUNGSOBJEKT S_GUI UND XXL-LISTVIEWERSAP 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 Berech-tigungen am Bildschirm angezeigt werden, auch auf den PC übertragbar. Die Funktionen des XXL-List-viewers 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 Berechtigungs-prü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.12 RISIKEN UND ZU ERGREIFENDE MASSNAHMENUm 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 Benutzerberechtigungskonzep-tes sicherzustellen, dass der Zugriff auf die o. g. Objekte sowie alle anderen Objekte der Klasse Personal-wesen 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 Organisations- anweisung 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

Seite

81

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

> eine restriktive Ausprägung des Feldes Berechtigungslevel im Hinblick auf den Zugriff auf HCM-Info- typen erfolgt> die Ausprägungen der Berechtigungsobjekte P_TCODE und S_TCODE sinnvoll aufeinander abgestimmt sind Sollte aufgrund der vorhandenen Personalstärke eine differenzierte, an Funktionstrennungsgesichtspunk-ten 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 PROFILEUm 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 Berechti-gungen 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_ALLMit 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 Daten-speicherung 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_ALLAuch 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-


Seite

82

gene Daten möglich. Darüber hinaus können auch über die Funktionalitäten der allgemeinen Tabellenan-zeige Inhalte aus anderen Anwendungen angezeigt werden. Dieses Profil sollte in Produktivsystemen nicht verwendet werden.

4.2.1.4.4 SONSTIGE S_XXX-PROFILENachfolgend genannte Profile stellen auch lediglich Muster dar. Grundsätzlich ist es erforderlich, die in diesen Profilen vorliegende Ausprägung der einzelnen Berechtigungsobjekte funktionsbezogen einzu-schrä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 durchzu- führen. S_A.DEVELOP Dieses Profil ist für Anwendungsentwickler vorgesehen und mit entsprechenden Programmierberechtigungen versehen.

4.2.1.4.5 ROLLEN MIT KRITISCHEN BERECHTIGUNGENRollen 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 vordefinier-ten Regeln identifiziert, siehe hierzu Kapitel 6.

4.2.1.4.6 RISIKEN UND ZU ERGREIFENDE MASSNAHMENUm 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 Berechtigungs-konzept 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)

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

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

> 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üfungGrundsä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ÜFUNGENWie 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 Profilgene-rators’ 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 Berechtigun-gen für das Sichern und das Aktivieren von deaktivierten Berechtigungsprüfungen zu Berechtigungsobjek-

29 UME (User Management Engine)


Seite

84

ten verschiedenen Benutzern zuordnen. Es ist sinnvoll, wenn das Deaktivieren von Berechtigungsprüfungen nach dem 4-Augen-Prinzip stattfindet.“

PRÜFKENNZEICHEN IN DER SU22 / SU24 Für die Prüfkennzeichen eines Berechtigungsobjektes sind folgende Werte vorgesehen. U Prüfkennzeichen wurde nicht spezifiziert – Berechtigungsobjekt wird geprüft (wie bei ‚P‘) N Berechtigungsobjekt wird unter Transaktion nicht geprüft P Berechtigungsobjekt wird unter Transaktion geprüft PP Berechtigungsobjekt wird unter Transaktion geprüft und im Profilgenerator werden die angegebenen Feldwerte vorgeschlagen

Der Wert „N“ ist prüfungsrelevant und nur nach genauer Prüfung und Dokumentation der Prüfungser- gebnisse 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 Applika- tion) genutzt wird.

4.2.1.5.2 AUTHORITY-CHECK BEI ABAP-PROGRAMMEN (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 Programmie-rung 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“)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 struk-turellen 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

Seite

85

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

(PLOG_CON, P_ORGINCON, P_ORGXXCON) als „kritische Berechtigung“ oder „kritische Berechtigungskom-bination“ wirksam genutzt werden. Dabei müssen Struktur- und Funktionsinformationen zusammenge-bracht und bewertet werden. Hier empfiehlt sich der Einsatz von Zusatztools (s. Kap. 6).

4.2.1.5.4 REPORT BERECHTIGUNGSGRUPPENDer Zugriff auf sensible Reports kann neben der skizzierten Verwendung von Authority-Checks über Transaktionscode-Zuordnungen oder Berechtigungsgruppen geschützt werden. Bei der Transaktionscode-Zuordnung ist sicherzustellen, dass Benutzer Reports ausschließlich über eine eigens zugeordnete Transaktion aufrufen können. Der allgemeine Aufruf über Transaktionen wie SA38 (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üfun-gen) 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.

4.2.1.5.5 RISIKEN UND ZU ERGREIFENDE MASSNAHMENDas 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 deaktiviertSchutzmaß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 Berechtigungsob-jekte im Anwenderbetrieb als Soll-Werte festzulegen. In regelmäßigen Abständen sollten die im SAP ERP-System vorgenommenen Ist-Einstellungen (Tabelle T77S0) überwacht werden. Ferner sind Maßnahmen zu definieren, wie z. B. der Zeilenschutz für die Tabellenadministration über das Berechtigungsobjekt S_TABU_LIN, um eine Manipulation des Berechtigungshauptschalters durch unberechtigte Benutzer auszuschließen.

30 Die Authority-Checks im Programmcode der Reports werden weiterhin ausgeführt, sofern sie vorhanden sind.


Seite

86

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-Standardpro-grammen auch deren Einstellung in Berechtigungsgruppen neu installiert wird.

4.2.1.6 BENUTZERADMINISTRATION

4.2.1.6.1 KONZEPTION DER ZENTRALEN BENUTZERADMINISTRATIONDer 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 Hinter-legung, die Pflege der Zugriffsrechte im Benutzerstammsatz, bietet das SAP-System verschiedene organi-satorische 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 Benutzerstamm-sätzen. Der Rollenadministrator pflegt die Elemente des Berechtigungskonzeptes. Dies sind je nach konzeptionel-lem 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_GRPDie oben genannten Berechtigungsobjekte werden ebenfalls bei der Verwendung des Profilgenerators (Transaktion PFCG) geprüft.

Seite

87

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

4.2.1.6.2 KONZEPTION DER DEZENTRALEN BENUTZERADMINISTRATIONBei 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 (Benutzer-stammpflege: Benutzergruppen) besteht die Möglichkeit, die organisatorische Zuständigkeit systemseitig abzubilden.

4.2.1.6.3 BENUTZERADMINISTRATION MIT DEM PROFILGENERATORRollen 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üfunktio-nen 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 PROFILENBei der veralteten Benutzeradministration erfolgt die Zuweisung unmittelbar über Profile (Einzel- oder Sammelprofile) im Benutzerstammsatz. Pflegt der Benutzeradministrator einen Benutzerstammsatz, so ist die Änderung für den entsprechenden Anwender unmittelbar bei seiner nächsten Anmeldung am SAP-System wirksam.Die Nutzung von manuell erzeugten Profilen kann zu einer nicht mehr kontrollierbaren Pflege von Berechtigungen führen.

4.2.1.6.5 RISIKEN UND ZU ERGREIFENDE MASSNAHMENIn 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 verstan-dene Funktionstrennung abgebildet werden. Da bei den SAP-Standardprofilen bzw. Standard-Rollen bezüglich des Datenschutzes Funktionstrennungs-gesichtspunkte 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).


Seite

88

4.2.1.7 ÄNDERUNGEN AM PRODUKTIVSYSTEMÄ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 unter-binden.

4.2.1.7.1 CHANGE AND TRANSPORT SYSTEM BegriffsabgrenzungCTODer 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änderungBerechtigungen 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 Berechtigun-gen 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 vorgenom-menen Einstellungen sichergestellt werden. Auf Protokolle über durchgeführte Transporte, vorgenommene Änderungen etc. kann aus den Transaktio-nen STMS oder SE03 heraus zugegriffen werden.

4.2.1.7.2 TABELLENPROTOKOLLIERUNG / CUSTOMIZING 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.

Seite

89

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

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 Auslieferungsman- danten (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 erforder- liches 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 Tabellen- protokollierung 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 mandantenunab-hängigen Customizings änderbar sind. Dabei können einzelne Objekte, wie z. B: > Kundenentwicklungen > SAP-Basiskomponente > Development Workbenchspezifisch 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 PROTOKOLLEWenn in SAP Änderungen an Objekten / Tabellen vorgenommen werden, wird – entsprechende Systemein-stellungen 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.


Seite

90

4.2.1.7.5 SCHUTZ DER TABELLE T000Über entsprechende Einstellungen der Tabelle T000 ist es möglich, Änderungen am SAP-System grundsätz-lich 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 Vergleichstoolsgetroffen 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 sicherzu-stellen, dass keine unkontrollierten Änderungen vorgenommen werden – entsprechende Dokumentations-unterlagen sollten erstellt werden – und dass nach den vorgenommenen Einstellungen der Änderbarkeits-status wieder zurückgesetzt wird.

4.2.1.7.6 RISIKEN UND ZU ERGREIFENDE MASSNAHMENZur 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.8 SYSTEMSCHNITTSTELLENFü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 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.

Seite

91

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

4.2.1.8.2 RFC, ALE, BAPIDer Remote Function Call (RFC) dient der Kommunikation zwischen verteilten Programmen in einer SAP-Systemlandschaft. Mit Hilfe von RFC können Funktionsbausteine in einem fremden SAP-System aufgerufen werden und die Ergebnisse an das aufrufende System 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-DOWNLOADSAP bietet die Möglichkeit, die unterschiedlichsten Auswertungen per Download aus der „gesicherten SAP-Umgebung“ auf den PC zu übertragen und dort ohne zusätzliche Kontrollen weiterzuverarbeiten. Dabei bezieht sich der Download z. B. auf jede Art von Listausgaben, die auf den PC übertragen werden können. Menüpfad: System → Liste → Sichern → Lokale DateiUm 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.

4.2.1.8.5 RISIKEN UND ZU ERGREIFENDE MASSNAHMENNach jedem Datenexport in Fremdsysteme können innerhalb der SAP-Umgebung Zweckbindung, Löschfristen und andere datenschutzrechtliche Anforderungen nicht mehr gewährleistet werden.

Bei jeder Form der Schnittstellenverarbeitung liegen die Risiken vorrangig in > der unvollständigen bzw. fehlerhaften Verarbeitung > der Manipulation während der Datenübertragung bzw. des Programmablaufs > der unzulässigen Einsichtnahme in personenbezogene Daten > der unkontrollierten Weitergabe dieser Daten


Seite

92

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:

> 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 RFC- Destinationen (Transaktion SM59 – Konfiguration der RFC-Verbindungen) zu beachten. Deren Pflege wird über das Berechtigungsobjekt S_ADMI_FCD (Systemberechtigungen) gesteuert. Ob bei RFC über- haupt 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 Berechti- gungsobjekt 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ächen- funktionen 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 Erweite- rung 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 Unter- bindung der Cut-and-Paste-Funktion.

4.2.1.9 AUDITING UND LOGGING Es ist zu beachten, dass die Konfiguration und die Auswertung der nachfolgenden Protokolle neben IT-Security, Revision und Wirtschaftsprüfern auch mit dem Datenschutzbeauftragten abzustimmen ist und die Mitbestimmungsrechte der Arbeitnehmervertretungen beachtet 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 LOGAus 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

Seite

93

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

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 ausgeschaltet1 = 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 Release-stä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.

Die Transaktion SM20 / SM20N ermöglicht eine Auswertung der mit Hilfe des Security Audit Logs erzeugten Protokolle.


Seite

94

4.2.1.9.2 SYSTEM LOG 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 (Transaktions-code) 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.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-PROTOKOLLIERUNGDie 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 Bearbeitungs-schritte 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 Funktionali-tät und deren Vergabe ist aus Datenschutzgesichtspunkten einer kritischen Betrachtung zu unterziehen.

4.2.1.9.5 REPORT-PROTOKOLLIERUNG IM HCM Um nachgelagerte Kontrollen bzgl. des Starts von „kritischen“ Personalwirtschaftsreports zu implementie-ren, besteht die Möglichkeit, diese in die Tabelle T599R einzupflegen. Mit der Transaktion SM30_V_T599R

Seite

95

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

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 Fehlzeitenaus-wertungen, die RPTABSxx-Reports.

4.2.1.9.6 AD-HOC-QUERY-PROTOKOLLIERUNG ZUR KONTROLLE DER ZWECKBINDUNGDas 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 SAP- Query und Quick-Viewer.

4.2.1.9.7 RISIKEN UND ZU ERGREIFENDE MASSNAHMENBei den vorgenannten Punkten ist zwischen Auswertungen zu unterscheiden, die nachgelagerte Kontrollen im Sinne eines Internen Kontroll Systems (IKS) oder aktivitätsbezogene Kontrollen und damit Leistungs- und Verhaltenskontrollen ermöglichen. Wird die Workflow-Komponente, z. T. das System Log oder das CCMS (STAD) genutzt, stehen somit Aus-wertungsmö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 Kompo-nente eines umfassenden Sicherheitsmanagements dar. Zu beachten ist in diesem Zusammenhang, dass über die dargestellten technischen Maßnahmen hinausgehend organisatorische Rahmenbedingungen


Seite

96

geschaffen werden müssen, über die die Verwaltung und die Zurücksetzung der Kennwörter der Notfall-User sowie die Archivierung und Kontrolle der erzeugten Protokolle sichergestellt ist.

4.2.1.10 KOMPLEXE SUCHHILFE Im SAP ERP sind komplexe Suchwerkzeuge an verschiedenen Stellen verfügbar. In vielen Modulen, wie z. B. dem HCM, stellen sie eigene Informationssysteme dar. Die angebotenen Suchhilfen können über Customizingfunktionen eingeschränkt werden. Die Definition der verwendeten Suchhilfen sollte im Projekt unter Hinzuziehung des DSB und ggf. der 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 Datenschutzgesichtspunk-ten, 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.

4.2.1.11 ZUSAMMENFASSUNG ZENTRALER RISIKENNachfolgend werden als Übersicht die in der Praxis am häufigsten auftretenden Risiken dargestellt. Diese sind u. a.:

> Fehlende Prüfbarkeit und Nachvollziehbarkeit durch > mangelnde Dokumentation der kundenspezifischen Anpassungen und Ausprägung des SAP- Systems (Customizing, Tabellenpflege, Anwendungsentwicklung etc.) > vergessene Report-Berechtigungsgruppenpflege > nachlässige Handhabung des Berechtigungskonzeptes > nicht eingehaltene Empfehlungen (z. B. ausgeschaltetes Tabellenprotokoll, zugelassene Program- mierung 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)

Seite

97

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

> 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 Servicerechen- zentrum) 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ÜFUNGSHANDLUNGENNeben 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ässigkeitsvor-aussetzungen bei der Verarbeitung personenbezogener Daten. Die Prüfung, welche organisatorisch-technischen 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. hier-zu die Ausführungen im Kapitel 1 dieses Leitfadens).

So vielfältig die Fragen einer Prüfung auch erscheinen mögen, es gibt einige Prüfungsfragen, die an dieser Stelle nicht aufgegriffen worden sind. Hierzu zählt etwa die Prüfung des 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


Seite

98

Regel im Rahmen der Vorabkontrolle, also einer einmaligen Prüfung vor Inbetriebnahme eines betreffenden Systems, erfolgen.

Zusammengefasst bedeutet dies: Was im Einzelfall erforderlich oder angemessen ist, damit auch die Frage nach der Zulässigkeit bestimmter Verarbeitungsformen, ist in allen 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 verant-wortlichen Stelle.

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.

Seite

99

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

5 Auftragsdatenverarbeitung und konzerninterner DatenaustauschIm Kapitel 5 wird auf unterschiedliche Formen der Auftragsdatenverarbeitung eingegangen, z. B. die Ver-gabe 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 unter-schiedlichen zugriffsberechtigten Personenkreise.

5.1 ABGRENZUNGEN BEIM THEMA OUTSOURCING UND DATENSCHUTZGrundsätzlich ist zwischen internem und externem Outsourcing zu unterscheiden. Beim internen Out-sourcing 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 Betroffe-nen 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 Dienst- leistungszentren (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)

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 einheit-lich 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 Verfahrens-schritten 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 verantwort-lichen 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 Entscheidungs-kompetenzen in Bezug auf die genutzten personenbezogenen Daten übertragen werden. Durch die

Seite

100

Ü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 wahr-nimmt. 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 Ver-lagerung 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, Entscheidungs-bäumen oder im Bereich einfacher Sachbearbeitungen arbeiten, spricht dies für die Auftragsdatenverarbei-tung. 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 ent-scheiden 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 AUFTRAGGEBERIm Folgenden werden – aufgrund der vielfältigen Fragestellungen in diesem Zusammenhang − ausge-wählte, grundsätzliche Punkte, die bei Überlegungen zur Vertragsgestaltung zwischen Auftraggeber und Auftragnehmer zu beachten sind, behandelt. Ausführliches zu Vertragsgestaltungen aus datenschutzrechtli-cher 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 Landesdaten-schutzgesetze 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 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 Datenerhe-bung / -verarbeitung / -nutzung, der technischen und organisatorischen Maßnahmen und etwaiger Unter-auftragsverhä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

31 T. Müthlein, J. Heck: Outsourcing und Datenschutz. Vertragsgestaltung aus datenschutzrechtlicher Sicht, 3. neu überarb. Auflage, 2006, Datakontext Fachverlag

Seite

101

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

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 Verschwiegenheitsverpflich-tung 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 Verfahrens-verzeichnis 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 Auftrag-nehmer 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 Sicherungs- maß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 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 Auftragsdatenverarbeitung und konzerninterner Datenaustausch

Seite

102

§ 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.4 WAHRUNG DER RECHTE DER BETROFFENENDie 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 DATENGEHEIMNISFü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 Daten-verarbeitung (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 er-fordert es, diesen Punkt sowie zusätzlich die Regelung über die Wahrung von Geschäftsgeheimnissen im Vertrag zu regeln.

5.2.6 KONTROLLEN DURCH DEN AUFTRAGGEBERDer 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 Wirt-schaftsprüfer / Aufsichtsbehörden / BSI) erfolgen. Hierbei sind Datenschutz- / Geheimhaltungsbedürfnisse des Auftragnehmers selbst und seiner anderen Kunden zu beachten.

5.2.7 DATENSCHUTZBEAUFTRAGTER DES AUFTRAGNEHMERSUm sich eines kompetenten Ansprechpartners für Datenschutzfragen im Unternehmen des Auftragneh-mers 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.

Seite

103

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

5.2.8 UNTERAUFTRAGNEHMERFür einzelne Tätigkeitsbereiche der Erhebung, Verarbeitung bzw. Nutzung kann es notwendig sein, Unter-auftragnehmer 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 Zusam-menbrü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 Unter-auftragsverhä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 AUSLANDBei einer Auftragsvergabe innerhalb der Europäischen Union (EU) / des Europäischen Wirtschaftsraums (EWR) wird hinsichtlich des Auftragnehmers keine Unterscheidung getroffen zwischen einer Datenverarbei-tung 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übermitt-lung 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.

In den USA können sich Unternehmen zur Beachtung der Safe-Harbor-Erklärung verpflichten. Diese US-Firmen 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.


Seite

104

Aufgrund der Besonderheiten des BDSG sind bei Nutzung von Vertragsmustern zur Auftragsdatenverarbei-tung 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 Verpflich-tung der Mitarbeiter des Auftragnehmers ersetzt werden.

5.2.10 WARTUNG UND PFLEGEPer Definition sind gemäß §11 Absatz 5 BDSG auf die Erbringung von Wartungsarbeiten oder von vergleich-baren 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

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 Anwen-dungsdaten 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.

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ßnah-men 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

Seite

105

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

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 Auftrag-gebers 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 AUSGANGSSITUATIONDie 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 ver-traglichen 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über-greifenden Funktionen, mit dessen Hilfe sowohl komplexe Konzernstrukturen als auch mehrere, voneinan-der 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 Berechtigun-gen 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än-kung 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 SAP-Systemen) 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.


Seite

106

5.3.2 SAP-ADMINISTRATIONDie 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 beispiels-weise 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 Informatio-nen zu Berechtigungsobjekten und -profilen s. Kap. 4).

5.3.3 SAP-SPEZIFISCHE MASSNAHMENIm 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. von-einander 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 buchungs-kreisü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 Berechti-gungen 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) 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

Seite

107

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

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 SERVICESWartungs- 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 vorgese-hen 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 NetWeaver- basierte System zurückgegeben werden. Die Technik von RFC bildet auch die Grundlage für weitere NetWeaver-basierten spezifische Schnittstellen-methoden 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 ausge-fü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 Datenschutz-niveau aufrechterhalten wird.

5.3.3.5 JOB-ABWICKLUNG Zwischen Auftraggeber und Auftragnehmer sind die Verantwortlichkeiten bezüglich Job-Auftrag, Job-Durchführung und Job-Überwachung klar schriftlich zu definieren (z. B. Personalabrechnungslauf,


Seite

108

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 Auftrag-nehmer 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.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 Rahmenbedingun-gen geschaffen werden, die verhindern, dass personenbezogene Daten ohne Wissen des Auftraggebers beim Auftragnehmer anderweitig nutzbar gemacht werden.

5.3.3.7 DATENBANK- UND LAN-UMGEBUNG Seitens der SAP werden im SAP NetWeaver Security Guide grundsätzliche Empfehlungen zur Installation in Bezug auf die Datenbank und das Netzwerk gegeben. Bei einer Auftragsdatenverarbeitung ist zu prüfen, ob je Auftraggeber eigene Mandanten oder Systeme eingesetzt werden sollen.

5.3.3.8 MANDANTENÜBERGREIFENDE FUNKTIONEN Beim Kopieren von Mandanten zwischen zwei Systemen, z. B. mit den Transaktionen SCC1 (über Transport-auftrag), 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 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 Nachkontrol-len 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 dem-selben Mandanten oder in denselben Organisationsstrukturen (Buchungskreis, Werk / Personalbereich etc.) verarbeitet werden.

Seite

109

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

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 RISIKENWerden personenbezogenen Daten im Auftrag durch eine andere datenverarbeitende Stelle verarbeitet oder genutzt, besteht die Gefahr, dass der Auftragnehmer der DV-Dienstleistung datenschutzrechtliche Anforde-rungen 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 Hand-habung 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

110

Seite

111

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

6 Besondere Themen6.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üfungs-funktionen 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än-nische 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 & Berechtigun-gen“ verwendet werden, mit dem z. B. verschiedene Auswertungen über Benutzer, Rollen oder Änderungs-belege (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.

Ab dem SAP Release 4.6C wurde das AIS von der bisherigen Menütechnik auf eine rollenbasierte Pflege-umgebung umgestellt. Jeder AIS-Benutzer benötigt je nach seiner Aufgabenstellung Rollen, die in seinem

Seite

112

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.

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 Datenschutz-funktionalitä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.

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 Berechtigungs-konzept 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

Mit dem Benutzerinformationssystem kann allerdings bisher nur das Berechtigungskonzept der ‚klassi-schen ABAP-Welt’ analysiert werden. Die im Rahmen der JAVA-Umgebung vergebenen Berechtigungen

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.200533 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.“ Se

ite 11

3LE

ITFA

DEN

DAT

ENSC

HU

TZ F

ÜR

SA

P ER

P 6.

0 ST

AN

D 3

0.05

.200

8, ©

DSA

G e

. V.

(z. B. für Portale) und die sogenannten ‚strukturellen Berechtigungen’ können nicht mit dem Benutzerinfor-mationssystem überprüft werden. In speziellen SAP Systemen, wie z. B. SAP CRM für das Kundenbeziehungs-management, 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 SM-System (Solution Manager) zur Aufbereitung und Sichtung sowie Bearbeitung zur Verfügung gestellt (SM-Transaktion: Solution_Manager). Er kann auch periodisch vom SM-System angefordert und bereitgestellt werden.

Der Report liefert nach dem bekannten Muster des SAP_Reports zu den kritischen Berechtigungen aus dem Benutzerinformationssystem eine Vielzahl von Auswertungen zu allen Gebieten der üblichen Sicherheits-einstellungen, 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 ausge-nommen 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 einge-halten wird.

Der Dienst steht nur in englischer Sprache zur Verfügung. Weiteres kann im SAP-Marketplace nachgelesen werden (http://service.sap.com/sos).

6 Besondere ThemenSe

ite 11

4

6.3 SAP GRC (GOVERNANCE, RISK AND COMPLIANCE)Die SAP GRC Suite umfasst Lösungen zum Risikomanagement, zur Dokumentation des internen Kontroll-systems, 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 Applikationsplatt-form 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 -analyseDarüber hinaus sorgen weitere GRC-Lösungen für die Beachtung von Bestimmungen in zahlreichen Branchen.

SAP SOLUTIONS FOR GRC

INDUSTRIY-SPECIFIC GRC

CROSS-INDUSTRY GRC

Risk Management

Acess Control Process Control Global Trade EH&S

SAPNetWeaver BUSINESS PROCESS PLATTFORM

BUSINESS APPLICATIONS

SAP ORACLE …PEOPLE SOFT

Seite

115

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

6.3.1 SAP GRC ACCESS CONTROLSAP 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 Funktions-trennung 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 Manage-ment) 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.

6 Besondere Themen

COMPLIANT USER PROVISIONING

Zugriffssteuerung für Superuser

Prävention

ENTERPRISE ROLE MANAGEMENT

SUPERUSER PRIVILEGE

MANAGMENT

Rollendefinition und -verwaltung

Zugangskontrolle für privilegierte Benutzer

Sichere Prozesse zur regelkonformen

Berechtigungs- und Zugriffsvergabe

SPRINTPHASE („sauber werden“)

MARATHONPHASE („sauber bleiben“)

RISK ANALYSIS AND REMEDIATIONRisikoanalyse, Erkennung und Behebung von Risiken und Schwachstellen

im Zusammenhang mit Zugangs- und Berechtigungskontrolle

RollenverwaltungIndentifizierung und Behebung

von Risiken

Seite

116

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 Transaktio-nen (z. B. PA30) als kritisch einzustufen. Mit dem Superuser Privilege Management wird insbesondere die Problematik der Notfallbenutzer datenschutzkonform gelöst.

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.

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 Zugriffs-risikos 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 be-wä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)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

Seite

117

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

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 Per-sonen (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 zustim-men 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 selbst-ständig zurückzusetzen.

6.3.2 SAP GRC PROCESS CONTROLDie 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

6 Besondere Themen

PROZESS-KONTROLLE-ZIEL-RISIKO

DO

KU

MEN

TTE

ST

SCHWACHSTELLEN-BEHEBUNG

ÜBERPRÜFUNG VON AUSNAHMEN

BESCHEINIGUNG UND FREIGABE(302, DESIGNS, …)

MO

NIT

OR

FREI

GA

BE

AUTOMATISCHE KONTROLLTESTS MANUELLE KONTROLLTESTS

DURCHFÜHRUNGVON SELF-

ASSESSMENTS

IT-Infrastruktur

Geschäftsprozesse

SAP ORACLE …PEOPLE SOFT

Seite

118

Bewerten und Testen der Kontrollen sowie die Steuerung und Überwachung der Behebung von Kontroll-schwä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 automa-tischen Kontrollen liefert SAP mit Process Control 2.5 aus. In der Applikation besteht die Möglichkeit, eigene manuelle und semiautomatische Kontrollen zu den Pro-zessen zu definieren. Dazu können z. B. Querys erstellt oder Reports (SAP-Standardreports und Kunden-reports) 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.

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.

Im Rahmen des Datenschutzes kann Process Control z. B. eingesetzt werden, um Datenverarbeitungspro-zesse 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).

Seite

119

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

7 Glossarhttp://help.sap.com/

http://www.sap.info/de/glossary/A.html

http://www.sap.info/en/glossary/A.html

Seite

120

Seite

121

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

LEIT

FAD

EN D

ATEN

SCH

UTZ

FÜ

R S

AP

ERP

6.0

STA

ND

30.

05.2

008,

© D

SAG

e. V

.

Deutschsprachige SAP ® Anwendergruppe e. V.Altrottstraße 34 a69190 WalldorfDeutschland

Fon: +49 (0) 62 27 – 358 09 58Fax: +49 (0) 62 27 – 358 09 59E-Mail: [email protected]: www.dsag.de

Copyright © 2008 DSAG e. V.

Alle Rechte vorbehalten. Namen von Produkten und Dienstleistungen sind Marken der jeweiligen Firmen.

Documents

Leitfaden Datenschutz SAP ERP 6.0