Microsoft Word - SAP Sicherheitsleitfaden_Endfassung.doc
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
__________________________________________________________________________
Sicherheitsleitfaden fr SAP-Verfahren
- Security Guide Line -
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
einschlielich der Universittsmedizin Gttingen Medizinische Fakultt und Universittsklinikum
Endfassung: 24. Oktober 2007
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 2 von 67
Inhaltsverzeichnis
1. Zielsetzung 8
1.1 Einfhrung 8
1.2 Zielgruppe 9
2. Geltungsbereich dieser Richtlinie 9
3. Gewhrleistung einer sicheren IT-Landschaft 10
3.1 Rahmenwerk fr Informationssicherheit 10
3.2 Verantwortlichkeiten fr die Einhaltung der Richtlinien 10
3.2.1 Kontrollprozesse 11
3.2.2 Eskalationsverfahren 11
3.3 Management von IT-Risiken 11
3.4 Einschrnkung des Zugangs zu SAP-Systemen durch ein Berechtigungskon-zept
12
3.5 Funktionale und organisatorische Zugriffsrechte 12
3.6 Klassifikation einzelner Abschnitte der Richtlinie 13
4. Funktionen und Verantwortlichkeiten 14
4.1 Systembetreiber 14
4.2 Geschftsprozessinhaber (Information Owner) 14
4.3 Anwendungseigner 14
4.4 Anwendungsbetreuer/Application Support (IT-Abteilung) 14
4.5 Anwendungsbetreuer (Fachabteilung) 14
4.6 Key-User 14
4.7 Endanwender 14
4.8 Helpdesk/Hotline 14
4.9 Support-Benutzer 14
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 3 von 67
Fortsetzung Inhaltsverzeichnis
5. Benutzer- und Kennwortverwaltung 15
5.1 Identifizierung und Authentifizierung 15
5.1.1 Benutzerkennungen 15
5.1.2 Mandanten 000 und 001 16
5.1.3 Mandant 066 17
5.1.4 Kennwortverwaltung 18
5.1.5 Weitere Systemprofilparameter 21
5.1.6 SAP-Standardbenutzer 23
5.2 Benutzerverwaltung 26
5.2.1 Organisatorische Anforderungen 26
5.2.2 SAP-Benutzergruppen 26
5.2.3 Zugang zur Systemlandschaft 27
5.2.4 Entwicklungssysteme 27
5.2.5 Durchfhrung der Benutzerverwaltung 29
5.3 Berechtigungsverwaltung 36
5.3.1 Verwendung von Rollen und Profilen 36
5.3.2 Organisatorische Einschrnkungen von Rollen 36
5.3.3 Rollenverwaltung Grundlegende Prinzipien 37
5.3.4 Anlage neuer Rollen 38
5.3.5 nderung bestehender Rollen 38
5.3.6 Lschung von Rollen 39
5.3.7 Sammelrollen 39
5.3.8 Berechtigungen fr Projekte und Business Requests 40
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 4 von 67
Fortsetzung Inhaltsverzeichnis
5.4 Einsatz von Notfallbenutzern 40
5.5 Funktionstrennung 41
5.6 Kritische/Sensitive Berechtigungen 41
6. Schnittstellen 42
6.1 Remote Communications (RFC & CPIC) 42
6.2 Hintergrundverarbeitung 44
6.3 Batch / Fast / Direct Input 44
6.4 BAPI 45
6.5 Legacy Systems Migration Workbench (LSMW) 46
6.6 CATT 46
6.7 Transfer-Verzeichnisse 47
7. Systemlandschaft 48
7.1 Systemkonzept 48
7.2 Mandantenkonzept 48
8. Change Management 50
8.1 Software-Logistik 51
8.1.1 Tabellenprotokollierung 52
8.1.2 Protokolle 52
8.2 Laufende Einstellungen 53
8.3 Entwicklungsrichtlinien 53
8.4 Systemffnung fr Customizing / Entwicklung 54
8.5 Remote-Zugriff fr den SAP-Support 54
8.6 Namenskonventionen 55
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 5 von 67
Fortsetzung Inhaltsverzeichnis
9. Schutz des Produktivsystems 55
9.1 Schutz von Tabellen 55
9.2 Schutz von Programmen 56
9.3 Logische Systemkommandos 56
9.4 Sperrung von Transaktionen 57
9.5 Queries 57
10. berwachung des Systemzugangs und von Systemaktivitten 58
10.1 Systemprotokoll 58
10.2 berwachung spezieller Benutzerkennungen 58
10.3 Datenintegritt Verbuchungsabbrche 59
10.4 Anforderungen an eine Dokumentation 59
11. Betriebssystem- und Netzwerksicherheit 59
12. Ausnahmen 59
13. Sicherstellung der Einhaltung dieser Richtlinie 60
14. Salvatorische Klausel 60
15. Inkrafttreten 60
Anhang SAP - HR 61
Anlagen
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 6 von 67
Anhang SAP-HR
5.1.1.3 Funktionale und mehrfach verwendete Benutzerkennungen
5.2.4.1 Qualittssicherungssysteme
5.2.4.2 Produktivsysteme
8.1.1 Tabellenprotokollierung
Anlagen
A1 Namenskonvention GAU (Georg-August-Universitt)
A2 Namenskonvention fr Benutzer/innen (HR-spezifisch)
A3 Transport und Genehmigung von Auftrgen/Aufgaben
A4 Formulare fr den HR-Zugang
A5 Beteiligte Personen und Aufgaben (HR-spezifisch)
A6 Mitglieder des internen SAP-Prfteams
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 7 von 67
Abkrzungen
ABAP Advanced Business Application Programming
BAPI Business Application Programming Interfaces
CATT Computer Aided Test Tool
CCMS Computing Center Management System
CPIC Common Programming Interface-Communication
CTO Change and Transport Organizer
DDIC Data Dictionary
IDOC Intermediate Document
IS Information Services
ITS Internet Transaction Server
LSMW Legacy System Migration Workbench
Q/A Quality Assurance
RFC Remote Function Call
SAP Systems, Applications, Products in Data Processing
SoD Segregation of Duty
TMS Transport Management System
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 8 von 67
1. Zielsetzung
1.1 Einfhrung
Um die
Vertraulichkeit,
Integritt,
Verfgbarkeit und
Authentizitt
der Daten innerhalb der SAP-Anwendungen der Universitt Gttingen sicherzustellen, mssen alle
Zugriffe auf wichtige Informationsbestnde kontrolliert und nachvollziehbar erfolgen.
Diese Richtlinie definiert ein Rahmenwerk fr Informations- und Systemsicherheit, in dem
die zugrunde liegenden Regeln,
die dafr notwendigen Prozesse,
die anschlieenden Kontrollen fr die Zugriffsrechte innerhalb eines SAP-Systems und
die hierbei zu bercksichtigenden Funktionen und Verantwortlichkeiten
erlutert werden.
Diese Richtlinie bestimmt die Standards und Minimalanforderungen an die Sicherheitseinstellungen
eines SAP-Systems gegen unberechtigten/inkorrekten Zugriff und Verletzungen des Prinzips der
minimalen Berechtigung.
Es ist nicht Aufgabe dieser Richtlinie, auf einer detaillierten, systemspezifischen Ebene die Konzepti-
on und Erstellung konkreter Berechtigungen bzw. SAP-Rollen zu beschreiben. Dies muss vom An-
wendungseigner, Geschftsprozessinhaber und Anwendungsbetreuer (s. Kapitel 4) des jeweiligen
SAP-Systems in Form konkreter, systemspezifischer Berechtigungskonzepte, die auf dieser globalen
Richtlinie aufbauen, durchgefhrt werden. Der Geschftprozessinhaber ist verantwortlich fr die Er-
stellung dieser systemspezifischen Berechtigungskonzepte, in denen alle notwendigen Prozesse zu
dokumentieren sind.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 9 von 67
Der Geschftsbereich Informationstechnologie der Universittsmedizin (G3-7), die Stabsstelle Daten-
verarbeitungsangelegenheiten der Universitt (Stabsstelle DV) und die Anwendungseigner haben
sicherzustellen, dass die in dieser Richtlinie beschriebenen Regeln innerhalb aller SAP-Module imp-
lementiert werden. Die Kontrolle der Einhaltung dieser Regeln im laufenden Betrieb unterliegt sowohl
den internen Kontrollinstanzen des G3-7/IT, der Stabsstelle DV und des jeweiligen Geschftprozess-
inhaber als auch der Kontrolle der Internen Revision (IR) im Rahmen der vorgegebenen Prfaufga-
ben.
1.2 Zielgruppe
Die Richtlinie wendet sich an den folgenden Personenkreis:
1. Prsidium der Universitt und Vorstand der Universittsmedizin
2. Leitung der Geschftsbereiche/Abteilungen und SAP-Anwendungsbetreuung
3. Leitung und die an den SAP-Geschftsprozessen beteiligten Sachgebiets-
leiter/-innen des Geschftsbereichs Informationstechnologie (G3-7)
4. Leitung und die an den SAP-Geschftsprozessen beteiligten Abteilungsleiter/-innen
der Stabsstelle DV
5. Interne Revision, Datenschutzbeauftragte der Universitt und der Universittsmedizin
6. Endanwender (insbesondere 5.1.4, sofern keine gesonderten Regelungen existieren)
7. Externe SAP-Nutzer [Akademie der Wissenschaften (AdW), Studentenwerk Gttingen (STW),
Gemeinsamer Bibliotheksverbund (GBV), Gttinger Experimentallabor fr junge Leute
e. V.(XLAB)]
8. Support Benutzer
2. Geltungsbereich dieser Richtlinie
Die aktuelle Sicherheitsrichtlinie ist fr alle Bereiche der Georg-August-Universitt Gttingen, die
SAP-Anwendungen bereitstellen oder nutzen, bindend.
Sie gilt uneingeschrnkt fr das Produktivsystem und fr das Konsolidierungssystem, soweit dieses
eine 1:1-Kopie des Produktivsystems ist. Abweichungen sind zu dokumentieren.
Die Richtlinie gilt nicht fr das Testsystem, da sich in diesem nur anonymisierte Daten befinden dr-
fen.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 10 von 67
3. Gewhrleistung einer sicheren IT-Landschaft
Die Gewhrleistung der IT-Sicherheit ist ein wesentliches strategisches IT-Ziel der Universitt Gttin-
gen Stiftung ffentlichen Rechts. Im Rahmen dieses Leitfadens wird daher auf die entsprechenden
Strategiepapiere des Prsidiums der Universitt Gttingen und des Vorstands der Universittsmedizin
verwiesen.
3.1 Rahmenwerk fr Informationssicherheit
Der SAP-Sicherheitsleitfaden ist ein Teil des Rahmenwerks fr Informationssicherheit. Als weitere
Komponenten dieses Rahmenwerks sind Policies, Direktiven, Richtlinien und Leitfden erforderlich.
Fr die Universitt Gttingen existiert folgendes Rahmenwerk zur IT-Sicherheit:
Organisationsrichtlinie zur IT-Sicherheit der Georg-August-Universitt Gttingen,
Sicherheitsrahmenrichtlinie der Georg-August-Universitt Gttingen.
Globale Komponenten (vornehmlich Policies, bergeordnete Richtlinien und Direktiven) des Rah-
menwerks werden jeweils durch die entsprechenden Gremien der Universitt bzw. durch die Gremien
der Universittsmedizin verabschiedet. Die Verabschiedung lokaler Komponenten des Rahmenwerks
hat in gegenseitiger Abstimmung mit den Leitungsgremien auf der Ebene der jeweiligen Organisati-
onseinheit zu erfolgen, es sei denn, dieser Sicherheitsleitfaden regelt ein besonderes Verfahren.
3.2 Verantwortlichkeiten fr die Einhaltung der Richtlinien
Die Verantwortlichkeit fr die Einhaltung der Richtlinien liegt bei den jeweiligen Geschftsberei-
chen/Abteilungen bzw. Organisationseinheiten.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 11 von 67
3.2.1 Kontrollprozesse
Die Leitung des G3-7, Informationstechnologie, bzw. die Leitung der Stabsstelle DV ist verpflichtet
sicherzustellen, dass die Regeln, die in diesem Rahmenwerk fr Informationssicherheit beschrieben
sind, umgesetzt werden. Sie richten darber hinaus regelmig auszufhrende Kontrollprozesse ein,
um die Umsetzung dieser Regeln nachzuweisen und stellt ein Frhwarnsystem zur rechtzeitigen Er-
kennung und Vermeidung von IT-Risiken zur Verfgung. Diese Kontrollprozesse bedingen sowohl
technische Lsungen (z. B. Nagios, SAP-CCMS) als auch organisatorische Manahmen (regelmi-
ge Besprechungen, Audits).
3.2.2 Eskalationsverfahren
Eskalationsverfahren mssen eingeleitet werden, wenn das Problem mit der Standardvorgehenswei-
se nicht gelst werden kann. Die Einleitung erfolgt ber den festgelegten Dienstweg. Die an der Eska-
lation beteiligten Mitarbeiter fertigen in diesem Fall Abschlussberichte an, in denen die fr andere
Stellen relevanten Probleme, vorgenommenen Handlungen, Ergebnisse dieser Handlungen und so-
weit erforderlich, empfohlenen weitere Schritte zusammengefasst werden. Weiterhin geht ein Bericht
an das Prsidium der Universitt bzw. an den Vorstand der Universittsmedizin. Der Datenschutzbe-
auftragte ist zu informieren, wenn das Eskalationsverfahren in Zusammenhang mit der Verarbeitung
personenbezogener Daten steht.
3.3 Management von IT-Risiken
Um IT-Risiken zu kontrollieren, haben die Systembetreiber (s. Kapitel 4) angemessene Manahmen
zur positiven nderung der Risikosituation an der Universitt Gttingen unter Bercksichtigung einer
ausgewogenen Kosten-Nutzen-Relation, zu ergreifen. Dies geschieht unter anderem durch
Minimierung von Risiken Bestehende Risiken werden durch die Umsetzung entsprechender Sicherheitsmanahmen
minimiert. Hierzu gehren u. a. Zutrittskontrollen, Betrieb eines Ausfallrechenzentrums, Back-
up, dezentrale Datenarchivierung und Netzwerksicherheit (Virenschutz, Firewall etc.).
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 12 von 67
Akzeptanz von Risiken Ein vorhandenes Risiko, das weder minimiert noch ausgeschaltet werden kann, wird durch
die verantwortliche Organisationseinheit formal anerkannt. Als Folge hiervon mssen diese
bekannten und akzeptierten Risiken periodisch und mglichst zeitnah berwacht (z. B. durch
regelmig zu erstellende Berichte) und damit weitestgehend eingeschrnkt werden.
bertragung von Risiken In diesem Fall wird das Risiko an einen Dritten, z. B. die Umsetzung bestimmter Prozesse des
Rahmenwerks fr Informationssicherheit an einen Dienstleister durch Service Level Agree-
ments, bertragen. Die Verantwortlichkeit fr die korrekte Umsetzung der Sicherheitsstan-
dards und fr die entsprechenden Kontrollen kann nicht delegiert werden.
3.4 Einschrnkung des Zugangs zu SAP-Systemen durch ein Berechtigungskonzept
Die Einschrnkung des Zugangs zu Anwendungen, IT-Systemen und zur gesamten IT-Infrastruktur ist
eine der wichtigsten Manahmen, um einen unberechtigten Zugriff auf Geschftsdaten und in dessen
Folge deren Manipulation zu verhindern. Das in dieser Richtlinie beschriebene globale SAP-
Berechtigungskonzept beschreibt die allgemein gltigen Grundlagen an alle SAP-Plattformen und
-Applikationen, die von der Universitt Gttingen betrieben werden. Dies sind Minimalanforderungen,
welche notwendig sind, um den in den Folgekapiteln beschriebenen, unterschiedlichen Funktionen
und Verantwortlichkeiten gerecht zu werden.
3.5 Funktionale und organisatorische Zugriffsrechte
Die Tatsache, dass ein Endanwender ber die Rechte zur Ausfhrung von Funktionen innerhalb eines
SAP-Systems verfgt, bedeutet nicht zwangslufig, dass er auch die vergleichbaren organisatori-
schen Rechte besitzt. Aus diesem Grund muss sichergestellt werden, dass die innerhalb des Systems
vergebenen Zugriffsrechte die entsprechenden organisatorischen Rechte nicht berschreiten. Ausge-
nommen hiervon sind die Anwendungsbetreuer auf der Technik- und Verfahrensebene, die organisa-
tionsbergreifend ttig sind.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 13 von 67
3.6 Klassifikation einzelner Abschnitte der Richtlinie
Die in dieser Richtlinie gemachten Vorgaben sind prinzipiell bindend, insbesondere fr alle produkti-
ven SAP-Systeme. Systemspezifische Anforderungen knnen in Teilen Abweichungen notwendig
machen, die von den zustndigen Leitungsgremien der Universitt Gttingen und der Universittsme-
dizin genehmigt werden mssen. Hierbei mssen Integritt und Konsistenz der Daten, die Nachvoll-
ziehbarkeit und Transparenz der eingesetzten Verfahren gewhrleistet sein.
Alle Abschnitte dieser Richtlinie werden entsprechend den folgenden Definitionen klassifiziert:
Verbindlich Diejenigen Abschnitte der Richtlinie, die als verbindlich gekennzeichnet sind, mssen fr alle
Bereiche der Universitt Gttingen, die SAP-Anwendungen bereitstellen oder nutzen, ent-
sprechend der gemachten Vorgaben umgesetzt werden. Abweichungen hiervon sind nicht er-
laubt. Die internen Kontrollinstanzen des Systembetreibers sowie die Interne Revision prfen
regelmig bzw. im Rahmen eines Prfauftrags (betr. Interne Revision) die Einhaltung dieser
Abschnitte der Richtlinie.
Ausdrcklich empfohlen Systemspezifische Anforderungen knnen Abweichungen in einzelnen Punkten dieser Richt-
linie notwendig machen. Die Notwendigkeit solcher Abweichungen mssen vom Anwen-
dungseigner oder Geschftprozessinhaber gegenber den zustndigen Leitungsgremien
nachgewiesen und von diesen genehmigt, nachvollziehbar dokumentiert und archiviert wer-
den.
Empfohlen Diejenigen Abschnitte dieser Richtlinie, die als empfohlen gekennzeichnet sind, sind nicht
bindend, aber die zugrunde liegenden Problemfelder mssen in systemspezifischen Konzep-
ten behandelt werden.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 14 von 67
4. Funktionen und Verantwortlichkeiten
Fr alle SAP-Systeme sind Rollen und Verantwortlichkeiten festzulegen, die sich an dem folgenden
Organisationsschema orientieren knnen:
4.1 Systembetreiber Geschftsbereich G3-7, Informationstechnologie
4.2 Geschftsprozessinhaber (Information Owner) Abteilungsleitung/Sachgebietsleitung
4.3 Anwendungseigner - Sachgebietsleitung/Abteilungsleitung, die fr das SAP-Modul zustndig ist
- SAP-Basisbetreuung in den IT-Abteilungen
4.4 Anwendungsbetreuer/Application Support (IT-Abteilung) Kontaktperson fr Probleme der Anwendungsbetreuer in der Fachabteilung.
4.5 Anwendungsbetreuer (Fachabteilung) SAP-Anwendungsbetreuer in der Fachabteilung ist Kontaktperson fr Probleme der Endan-
wender, die vom Key-User nicht gelst werden knnen.
4.6 Key-User Erste Kontaktperson fr Endanwender innerhalb einer Organisationseinheit fr Probleme, die
im tglichen Routinebetrieb auftreten.
4.7 Endanwender
4.8 Helpdesk/Hotline
4.9 Support-Benutzer Fernwartung
Die Zuordnung der oben genannten Funktionen an die bestehende Organisationsstruktur sowie die
zugehrigen Verantwortlichkeiten sind in Anlagen geregelt.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 15 von 67
5. Benutzer- und Kennwortverwaltung
Der Zugang von Benutzern und die Kennwortverwaltung muss grundstzlich durch entsprechende
Regelungen zur Nutzung der IT-Infrastruktur und eine Sicherheitsrichtlinie Kennwortschutz festge-
legt werden. Diese werden durch folgende Anforderungen ergnzt, falls es in den geforderten Regel-
werken hierfr keine gesonderten Festlegungen gibt.
5.1 Identifizierung und Authentifizierung
Ein SAP-Anwender muss sich an einem SAP-System mittels einer eindeutigen Benutzerkennung und
dem zugehrigen Kennwort anmelden. Dies kann auch ber ein Single-Sign-on-Verfahren erfolgen.
Indem er diese Daten eingibt, identifiziert sich der Benutzer gegenber dem SAP-System, welches
anschlieend prft, ob der Benutzer fr eine Arbeit mit dem System autorisiert ist.
5.1.1 Benutzerkennungen
5.1.1.1 Vertraulichkeit der Benutzerkennungen
Jeder Anwender ist verpflichtet, die Daten seines Benutzerkontos, besonders das Kennwort, vertrau-
lich zu behandeln und diese Daten keinem Dritten zugnglich zu machen.
5.1.1.2 Namenskonventionen fr Benutzerkennungen
Fr die Namenskonventionen der Benutzerkennungen gelten die folgenden, allgemeinen Regeln:
Benutzerkennungen fr Dialogbenutzer mssen eindeutig sein.
Jeder Benutzer darf nur ber eine einzige, ihm zuordenbare, Benutzerkennung verfgen.
Fr jede Benutzerkennung ist ein Verantwortlicher festzulegen, auch wenn die Benutzerken-
nung nicht fr eine interaktive Anmeldung verwendet wird.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 16 von 67
Alle Benutzerkennungen mssen regelmig vom Anwendungsbetreuer (Verfahrensebene) auf die
Einhaltung der Namenskonventionen berprft werden. Abweichungen von den Namenskonventionen
sind zu klren und unverzglich zu korrigieren.
Fr einzelne Bereiche (ZUV) existieren Namenskonventionen (s. Anlage A2).
5.1.1.3 Funktionale und mehrfach verwendete Benutzerkennungen ( s. Anhang HR)
Aufgrund der SAP-Lizenzvereinbarungen ist die gleichzeitige Verwendung einer Benutzerkennung
durch mehrere Anwender grundstzlich verboten. ber diese vertragliche Regelung hinaus drfen
keine funktionalen bzw. anonymisierten Benutzerkennungen im Rahmen dieser Richtlinie verwendet
werden, um eine eindeutige Identifikation von Benutzern und die Nachvollziehbarkeit von deren Aktivi-
tten (z. B. die Ausfhrung von Transaktionen, Programmen, Hintergrundjobs) innerhalb der Anwen-
dungen und IT-Systeme zu gewhrleisten.
Ausnahmen aufgrund spezieller technischer Voraussetzungen oder Anforderungen aus (operativen)
Geschftsprozessen mssen vom hierfr zustndigen Anwendungsbetreuer (Verfahrensebene) ge-
nehmigt werden.
Fr die Hintergrund- und/oder Schnittstellenverarbeitung (s. a. Kapitel 6) knnen funktionale und ge-
meinsam verwendete Benutzerkennungen genutzt werden, da Systemdaten verarbeitet werden. Die-
se Verarbeitung von Systemdaten darf nicht von einer bestimmten Person bzw. deren Benutzerken-
nung abhngig sein.
Die Verwaltung von Benutzerkennungen fr die Hintergrund- bzw. Schnittstellenverarbeitung ist auf
einen bestimmten Personenkreis, der vom Anwendungseigner genehmigt werden muss, einzuschrn-
ken.
Administrative Prozesse, die sich ber den gesamten Lebenszyklus einer Benutzerkennung erstre-
cken, mssen vom Anwendungsbetreuer (Verfahrensebene) eingefhrt und regelmig berwacht
werden.
5.1.2 Mandanten 000 und 001
Der Mandant 000 und meist auch der Mandant 001 sind Referenzmandanten. Aus diesem Grund
mssen die Zugriffe auf diese beiden Mandanten eingeschrnkt werden.
Vom Anwendungseigner muss eine Liste der Benutzer und ihrer Benutzerkennungen, die innerhalb
der Mandanten 000 und 001 definiert sind, zur Verfgung gestellt werden.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 17 von 67
Die Benutzerkennungen in den Mandanten 000 und 001 werden regelmig vom internen Prfteam
(s. Anlage A6) geprft. Hierbei wird die Liste der genehmigten Benutzerkennungen mit den tatschlich
vorhandenen Benutzerkennungen verglichen. Werden Abweichungen festgestellt, mssen die Ursa-
chen hierfr bestimmt und der in der Dokumentation festgelegte Stand wieder hergestellt werden. Die
Prfungsergebnisse und alle Berichte mssen dem Anwendungseigner zur Besttigung bersandt
und archiviert werden.
5.1.3 Mandant 066
Innerhalb des Mandanten 066 sind standardmig die SAP-Benutzerkennungen
EARLYWATCH und
SAP*
vorhanden.
Fr die Ausfhrung von Ttigkeiten innerhalb der SAP-Basis kann es notwendig sein, in Abstimmung
mit dem Anwendungseigner eine dritte Benutzerkennung einzurichten.
Die Benutzerkennungen in den Mandanten 066 werden regelmig vom internen Prfteam geprft.
Hierbei wird die Liste der genehmigten Benutzerkennungen mit den tatschlich vorhandenen Benut-
zerkennungen verglichen. Werden Abweichungen festgestellt, mssen die Ursachen hierfr bestimmt
und der in der Dokumentation festgelegte Stand wieder hergestellt werden. Die Prfungsergebnisse
und alle Berichte mssen dem Anwendungseigner zur Besttigung bersandt und archiviert werden.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 18 von 67
5.1.4 Kennwortverwaltung
5.1.4.1 Grundlegende Kennwortregeln
Neben den kundenseitig einstellbaren Kennwortregeln (s. a. Kapitel 5.1.4.2) gibt es eine Reihe durch
SAP systemseitig vordefinierten Kennwortregeln, die nicht gendert werden knnen (s. a. aktuelle
SAP Hinweise):
Das Kennwort kann nicht lnger als 8 Zeichen lang sein.
Das erste Zeichen eines Kennworts darf kein Ausrufezeichen, Fragezeichen oder Leerzei-
chen sein.
Die ersten drei Zeichen drfen in ihrer Reihenfolge nicht in der Benutzerkennung vorkommen
(diese Regel wird nur bis SAP R/3 4.6D angewendet).
Die ersten drei Zeichen des Kennworts und der Benutzerkennung drfen nicht identisch sein.
Keines der ersten drei Zeichen darf ein Leerzeichen sein.
Dass Kennwort darf nicht PASS oder SAP* lauten.
Sofern der Benutzer sein Kennwort selbst ndern kann, muss dieses Kennwort von den letz-
ten fnf verwendeten Kennwrtern unterschiedlich sein. Im Gegensatz hierzu kann ein Admi-
nistrator ein Kennwort whlen, welches mit einem der letzten fnf Kennwrter des Benutzers
identisch ist. Diese Ausnahme ist notwendig, da ein Administrator die Kennwrter eines Be-
nutzers nicht kennen (sollte). Der Benutzer wird bei der ersten interaktiven Anmeldung sys-
temseitig zur nderung des Initialkennworts aufgefordert.
Das Kennwort kann von einem Benutzer nach dessen korrekter Eingabe gendert werden.
Ein Benutzer kann sein Kennwort maximal einmal tglich ndern; ein Administrator kann das
Kennwort eines Benutzers beliebig oft ndern.
Beim Kennwort wird nicht in Gro- und Kleinschreibung unterschieden.
nderungen der Kennwortregeln (z. B. ber eine nderung der Eintrge der Tabelle USR40)
betreffen nicht bereits vorhandene Kennwrter. Die Kennwortregeln werden nur bei der nde-
rung eines Kennworts bercksichtigt.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 19 von 67
5.1.4.2 nderbare Kennwortregeln
ber diese systemseitig vorgegebenen Kennwortregeln hinaus gibt es die Mglichkeit, nderbare
Kennwortregeln zu verwenden und somit an kundenspezifische Anforderungen anzupassen. Die Ein-
stellung der folgenden Parameter auf die genannten Werte wird ausdrcklich empfohlen.
Mindestlnge eines Kennworts Der Parameter LOGIN/MIN_PASSWORD_LNG bestimmt die Mindestanzahl von Zeichen, die
ein Kennwort enthalten muss. Der Mindestwert ist 8, was bedeutet, dass das Kennwort 8
Zeichen enthalten muss.
Gltigkeitszeitraum eines Kennworts Der Parameter LOGIN/PASSWORD_EXPIRATION_TIME bestimmt den Zeitraum, nach dem
das Kennwort eines Dialogbenutzers oder eines ITS-Services, der die sog. Flow Logic ver-
wendet, gendert werden muss. Der Wert dieses Systemprofilparameters muss mindestens
90 betragen (ein Benutzer muss sein Kennwort nach maximal 90 Tagen ndern).
Beendigung einer SAP-Session: Der Parameter LOGIN/FAILS_TO_SESSION_END legt fest, wie viele Anmeldeversuche mg-
lich sind, bevor die SAP-Session systemseitig beendet wird. Dieser Vorgang wird als misslun-
gener Anmeldeversuch protokolliert.
Der Wert dieses Parameters muss 3 sein (die SAP-Session wird nach 3 fehlgeschlagenen
Anmeldeversuchen beendet).
Anzahl mglicher Anmeldeversuche: Der Parameter LOGIN/FAILS_TO_USER_LOCK bestimmt, wie viele fehlgeschlagene Anmel-
deversuche erlaubt sind, bevor der Benutzer systemseitig gesperrt wird.
Der Wert dieses Parameters darf 6 nicht berschreiten (der Benutzer wird nach 6 fehlge-
schlagenen Anmeldeversuchen gesperrt).
Entsperrung einer Benutzerkennung um Mitternacht: Der Parameter LOGIN/FAILED_USER_AUTO_UNLOCK muss auf den Wert 0 gesetzt wer-
den, damit Benutzer, die aufgrund fehlgeschlagener Anmeldeversuche gesperrt wurden, um
Mitternacht nicht automatisch entsperrt werden.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 20 von 67
Automatische Abmeldung: Der Parameter RDISP/GUI_AUTO_LOGOUT legt fest, nach welchem Zeitraum in Sekunden
ein inaktiver Benutzer systemseitig abgemeldet wird. Hierbei werden nicht gesicherte Daten
(z. B. in den Eingabemasken) gelscht, wodurch es bei dieser erzwungenen Abmeldung zu
einem Datenverlust kommen kann.
Der Wert dieses Parameters darf 3600 nicht berschreiten (das SAP-System meldet einen
inaktiven Benutzer nach maximal 3600 Sekunden = 60 Minuten automatisch ab).
Der Anwendungseigner vergleicht regelmig die eingestellten Parameter mit den definierten, doku-
mentierten Werten. Abweichungen mssen identifiziert, die Ursachen hierfr ermittelt und die definier-
ten Einstellungen wieder hergestellt werden.
5.1.4.3 Tabelle der verbotenen Kennwrter
Neben den bereits dargestellten Einstellungen ber Systemprofilparameter, knnen in der Tabelle
USR40 unzulssige Kennwrter (z. B. triviale Kennwrter oder einfache Zeichenkombinationen) defi-
niert werden. Diese Liste muss in jedem System erstellt und gepflegt werden. Sie muss mindestens
Wochentage,
Monate,
Lnder,
Feiertage,
Jahreszeiten,
hufig verwendete Vornamen,
Automarken,
wichtige Stdte usw.
enthalten.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 21 von 67
5.1.4.4 Initialkennwrter
Initialkennwrter werden bei der Anlage einer Benutzerkennung oder nach der Rcksetzung eines
Benutzerkennworts erzeugt. Bei der ersten oder einer erneuten Anmeldung des Benutzers muss die-
ser das Initialkennwort durch ein benutzerdefiniertes Kennwort ersetzen.
Fr die Erzeugung von Initialkennwrtern sollte nur der in SAP vorhandene Kennwort-Assistent ver-
wendet werden.
5.1.5 Weitere Systemprofilparameter
Neben den Systemprofilparametern, die bereits in Kapitel 5.1.4.2 dargestellt wurden, gibt es weitere
Einstellungen, welche fr das Mindestma an Sicherheit eines SAP-Systems notwendig sind. Sys-
temspezifische Gegebenheiten knnen unterschiedliche Einstellungen, insbesondere fr Qualittssi-
cherungs- und Entwicklungssysteme, erfordern.
Die folgenden Einstellungen sind verbindlich:
Deaktivierung von Berechtigungsprfungen ber die Transaktionen SU25 oder AUTH_SWITCH_OBJECTS knnen Berechtigungspr-
fungen fr bestimmte Berechtigungsobjekte global deaktiviert werden. Um dies zu verhindern,
muss der Systemprofilparameter AUTH/OBJECT_DISABLING_ACTIVE auf den Wert N ge-
setzt werden.
Berechtigungsprfungen knnen ber den Systemprofilparameter
AUTH/NO_CHECK_IN_SOME_CASES unterdrckt werden. Die Anzahl der Berechtigungs-
prfungen, die seitens SAP vorgeschlagen werden, knnen ber die Transaktion SU24 ver-
ringert werden. Dies setzt voraus, dass der Systemprofilparameter den Wert Y fr die Deak-
tivierung von Berechtigungsprfungen annimmt.
Sofern der Profilgenerator (PFCG) eingesetzt wird, muss der Wert auf Y gesetzt werden.
Aus diesem Grund darf die Transaktion SU24 nur an einen vorher genau definierten Kreis an
Personen vergeben werden.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 22 von 67
Berechtigungsprfungen fr Remote Function Calls (RFCs) Der Systemprofilparameter AUTH/RFC_AUTHORITY_CHECK steuert, ob whrend Remote
Function Calls (RFCs) Berechtigungsprfungen auf das Berechtigungsobjekt durchgefhrt
werden. Der Wert dieses Systemprofilparameters muss auf 1 gesetzt werden, d. h. die Be-
rechtigungsprfung fr RFC-Aufrufe ist aktiv.
Die folgenden Einstellungen werden ausdrcklich empfohlen:
Mehrfachanmeldungen von Dialogbenutzern mit
einer einzigen Benutzerkennung verhindern Ein Benutzer sollte sich ber einen SAPGUI an einem SAP-System grundstzlich nur einmal
anmelden knnen. Gleiches gilt fr die Mehrfachanmeldung von einem Frontend-Rechner
aus, wobei der Benutzer immer noch die Mglichkeit hat, whrend einer Anmeldung mehrere
SAP-Sessions zu ffnen. Deshalb muss der Systemprofilparameter
LOGINDISABLE_MULTI_GUI_
LOGIN auf den Wert 1 gesetzt werden (mehrfache Dialoganmeldungen werden dadurch ver-
hindert). Sollten aus bestimmten Grnden fr genau definierte Benutzer Mehrfachanmeldun-
gen notwendig sein, knnen diese ber den Systemprofilparameter
LOGIN/MULTI_LOGIN_USERS gesetzt werden.
Keine automatische Erzeugung des Benutzers SAP* Der Parameter LOGIN/NO_AUTOMATIC_USER_SAPSTAR sollte auf den Wert 1 gesetzt
werden (s. a. Kapitel 5.1.6.1).
Systemprofilparameter fr die berwachung und Protokollierung von Tabellen-
nderungen (s. a. Kapitel 8.1.1 ff): rec/client
RECCLIENT
Die folgenden Einstellungen werden empfohlen:
Berechtigungsprfung fr ABAP/4-Sprachbefehle Der Systemprofilparameter AUTH/SYSTEM_ACCESS_CHECK_OFF ermglicht es, Berechtigungs-
prfungen fr bestimmte ABAP-Sprachbefehle, z. B. den Aufruf von Kernel-Funtionen oder CPI-C-
Aufrufe zu deaktivieren.
Der empfohlene Parameterwert ist 0 (die Berechtigungsprfung fr bestimmte ABAP-Sprachbefehle
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 23 von 67
ist aktiv).
Fr alle in dieser Richtlinie genannten (Systemprofil-)Parameter mssen die notwendigen Einstellun-
gen definiert und dokumentiert werden. Vom Anwendungseigner mssen Prozesse fr nderungen
an diesen Einstellungen konzipiert und umgesetzt werden. Der Anwendungseigner berwacht regel-
mig die in dieser Richtlinie beschriebenen Systemprofilparameter und deren Werte. Werden Abwei-
chungen in den vorgeschriebenen Einstellungen entdeckt, mssen die notwendigen Werte wieder
hergestellt und die Ursachen hierfr bestimmt werden. Darauf aufbauend mssen Manahmen einge-
leitet werden, die eine nochmalige, unautorisierte nderung dieser Einstellungen verhindern. Alle Do-
kumente, die whrend der berwachung der Einstellungen erzeugt werden, mssen vom Anwen-
dungseigner archiviert werden.
5.1.6. SAP-Standardbenutzer
Es gibt mindestens vier SAP-Standardbenutzer in einem SAP-System, deren Funktionen im Folgen-
den beschrieben werden. Diese Standardbenutzer mssen im Rahmen technischer und organisatori-
scher Manahmen vor einem unautorisierten Zugriff geschtzt werden.
Der Anwendungseigner ist verpflichtet, ein Konzept fr den Schutz vor unautorisierten Zugriffen auf
diese SAP-Standardbenutzer zu erstellen. Die Umsetzung der unten genannten Anforderungen wird
ausdrcklich empfohlen, wobei Abweichungen in Qualittssicherungs- und Entwicklungssystemen
mglich sind.
Die weiter unten angefhrten Einstellungen mssen vom Anwendungseigner regelmig berprft
werden. Abweichungen von diesen Einstellungen mssen untersucht und fr die Wiederherstellung
der Einstellungen entsprechende Manahmen eingeleitet werden. Eine bersicht dieser Einstellun-
gen und soweit verfgbar der eingeleiteten Manahmen muss vom Anwendungseigner dokumen-
tiert werden.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 24 von 67
5.1.6.1 SAP*
Zum Schutz des SAP-Standardbenutzers SAP* mssen die folgenden Manahmen ergriffen werden:
Fr den Benutzer SAP* muss ein Benutzerstammsatz angelegt werden.
Fr den Benutzer SAP* drfen keine Rollen/Profile vergeben werden.
Fr den Benutzer SAP* muss ein nicht-triviales Kennwort vergeben und an den entsprechend
autorisierten Personenkreis bermittelt werden.
Der Benutzer SAP* muss einer administrativen Benutzergruppe zugeordnet werden.
Der Benutzer SAP* ist zu sperren.
Darber hinaus muss die automatische Anlage nach der Lschung des Benutzerstammsatzes durch
Setzen des Systemprofilparameters LOGIN/NO_AUTOMATIC_USER_SAPSTAR auf den Wert 1
verhindert werden (der automatische Benutzer SAP* wird dadurch deaktiviert, s. a. Kapitel 5.1.5).
Sofern entgegen der oben genannten Regelungen ein Einsatz des SAP-Standardbenutzers SAP*
notwendig ist, muss vom Anwendungseigner ein Prozess fr einen geregelten, autorisierten Einsatz
des Benutzers SAP* (z. B. bei der Installation von Support Packages) eingefhrt werden, welche ins-
besondere die folgenden Punkte bercksichtigen:
Die Vergabe der SAP Standardprofile SAP_ALL und SAP_NEW an den Benutzer SAP* ist er-
laubt.
Dem Benutzer SAP* zugeordnete Rollen/Profile sind nach einem Einsatz zeitnah zu entzie-
hen.
Der Benutzer SAP* ist unmittelbar nach der Beendigung seiner Aktivitten zu sperren.
Die Verwendung des Benutzers SAP* ist zu dokumentieren.
5.1.6.2 SAPCPIC
Der Benutzer SAPCPIC wird bei der Installation als SAP-Standardbenutzer angelegt und kann nicht
fr Dialoganmeldungen genutzt werden. Er wird von einigen Programmen und Funktionsbausteinen
fr die Systemkommunikation verwendet.
Um diesen Benutzer zu schtzen, wird das bekannte Standardkennwort dieses Benutzers gendert.
Sollte die Benutzerkennung gesperrt werden, muss vor dieser Umsetzung die aktuelle Version des
SAP Hinweises #29276 auf eventuelle Einschrnkungen bzw. Auswirkungen hin geprft werden.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 25 von 67
5.1.6.3 DDIC
Der SAP-Standardbenutzer DDIC wird fr weite Bereiche des ABAP Dictionary und des TMS bentigt.
Aus diesem Grund bentigt dieser Benutzer umfangreiche Systemrechte, die ber die in den Benut-
zerprofilen hinterlegten Rechte hinausgehen. Die Verwendung der SAP-Standardprofile SAP_ALL und
SAP_NEW fr diesen Benutzer wird ausdrcklich empfohlen.
Um diese Benutzerkennung zu schtzen, muss ein nicht-triviales Kennwort vergeben und einem hier-
fr berechtigten Personenkreis bermittelt werden. Die Benutzerkennung muss einer administrativen
Benutzergruppe zugeordnet und vom Anwendungseigner ein Konzept fr die Verwendung dieser
Benutzerkennung entworfen, implementiert und regelmig berwacht werden.
Die Verwendung der Benutzerkennung DDIC sollte sowohl systemseitig protokolliert als auch ber
organisatorische Manahmen geregelt werden. Die Benutzerkennung DDIC darf nicht fr Notfallbe-
nutzereinstze verwendet werden (s. a. Kapitel 5.4).
5.1.6.4 Early Watch
Der Benutzer EARLYWATCH ist ein Dialogbenutzer, der von SAP fr den Early Watch Service im
Rahmen der Performance-berwachung genutzt wird.
Um diese Benutzerkennung vor einem unautorisierten Zugriff zu schtzen, muss deren bekanntes
Standardkennwort gendert werden. Der Benutzer ist zu sperren und nur auf Anforderung fr die
Dauer des Systemszugriffs durch SAP wieder zu entsperren. Nach einem solchen Zugriff muss ein
neues Kennwort vergeben und die Benutzerkennung wieder gesperrt werden.
5.1.6.5 WF-BATCH
Dieser Standardbenutzer wird fr das automatische Workflow-Customizing bentigt.
Dieser Benutzer hat entsprechend den Empfehlungen der SAP den Benutzertyp System und die
SAP-Standardprofile "SAP_ALL" und "SAP_NEW". Es gelten die gleichen Absicherungen wie fr die
brigen Standardbenutzer.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 26 von 67
5.2 Benutzerverwaltung
5.2.1 Organisatorische Anforderungen
Zur Gewhrleistung einer Funktionstrennung und der Anforderungen der internen/externen Revision
muss der Geschftprozessinhaber/Anwendungsbetreuer ein Konzept fr die Benutzerverwaltung
erstellen, welches mindestens die folgenden Punkte beinhaltet:
Benutzer drfen sich nicht selbst verwalten.
Die Verantwortlichkeiten fr die Benutzeradministration mssen transparent sein.
Die Nachvollziehbarkeit der Benutzeradministration muss sichergestellt werden.
Besondere Manahmen mssen fr die Verwaltung spezieller Benutzer (DDIC, SAP* oder Notfallbe-
nutzer) und der Benutzeradministratoren selbst ergriffen werden. Der Geschftprozessinha-
ber/Anwendungsbetreuer muss unter Bercksichtigung organisatorischer Strukturen und operativer
Anforderungen ein Konzept fr die Verwaltung aller SAP-Anwender erstellen, welches die oben ge-
nannten Anforderungen erfllt. Dabei hat der Geschftprozessinhaber/Anwendungsbetreuer einen
begrenzten Personenkreis zu bestimmen, dem die Verwaltung von Benutzern erlaubt ist.
5.2.2 SAP-Benutzergruppen
ber Benutzergruppen kann kontrolliert werden, fr welche Benutzerstammstze ein Administrator
verantwortlich ist. Benutzerkennungen, denen keine Benutzergruppe zugeordnet ist, knnen von allen
Administratoren verwaltet werden. Aus diesem Grund muss jedem Benutzer eine Benutzergruppe
zugeordnet werden. Der Anwendungseigner ist verantwortlich fr die Erstellung eines Konzepts fr
den Einsatz von Benutzergruppen. Als Minimalanforderung muss ein solches Konzept die folgenden
Benutzergruppen enthalten:
Dialogbenutzer
Technische Benutzer (Hintergrundjobs, Kommunikationsschnittstellen etc.)
Super-User (DDIC, SAP* oder Notfallbenutzer)
Benutzeradministratoren
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 27 von 67
Jedem der genannten Benutzertypen muss mindestens eine Benutzergruppe zugeordnet werden. Die
Vergabe weiterer Benutzergruppen an die gleiche Benutzerkennung ist, abhngig von organisatori-
schen oder operativen Anforderungen, erlaubt. In einem solchen Fall knnen Benutzergruppen fr die
Klassifikation spezieller Benutzer (Entwickler, Benutzer mit Customizing-Rechten etc.) innerhalb des
Reportings genutzt werden.
5.2.3 Zugang zur Systemlandschaft
Die Umsetzung der folgenden Manahmen, die den Zugang zur Systemlandschaft betreffen, wird
nachdrcklich empfohlen.
5.2.4 Entwicklungssysteme
Der Zugang zu Entwicklungssystemen muss auf die folgenden Personenkreise eingeschrnkt sein:
IT (Entwickler, Benutzer mit Customizing-Rechten etc.)
Projekt-Teams
Key-User
Endanwender drfen keinen Zugang zum Entwicklungssystem erhalten.
Fr Entwicklungssysteme mssen vom Anwendungseigner Zugangsregeln erstellt werden, in denen
die Risiken, Regeln und Verantwortlichkeiten mglicher Zugnge klar definiert sind.
Diese Regeln mssen vom Anforderer, bevor ihm Zugang zum System und/oder Zugriffsrechte ber
SAP-Rollen gewhrt werden, durch einen Antrag gegengezeichnet werden. Der Anwendungseigner
muss diese unterschriebenen Regeln so archivieren, dass alle lokalen Anforderungen erfllt werden.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 28 von 67
5.2.4.1 Qualittssicherungssysteme ( s. Anhang HR)
Der Zugang zu Q/A-Systemen (Qualittssicherungssystemen) muss auf die folgenden Personenkrei-
se eingeschrnkt sein:
IT (Entwickler, Benutzer mit Customizing-Rechten etc.)
Support-Benutzer (Fernwartung)
Projekt-Teams
Key-User
Key-User und Anwendungsbetreuer drfen das Q/A-System zu Testzwecken verwenden. Fr diese
Key-User und Anwendungsbetreuer finden dieselben organisatorischen Einschrnkungen wie in ei-
nem produktiven System Anwendung.
Endanwender sollten grundstzlich keinen Zugang zum Q/A-System, auer zu Testzwecken, erhal-
ten.
5.2.4.2 Produktivsysteme ( s. Anhang HR)
Grundstzlich ist der Zugang zu einem Produktivsystem nicht auf einen bestimmten Personenkreis
eingeschrnkt. Es mssen jedoch funktionale und organisatorische Einschrnkungen entsprechend
den definierten Aufgaben des Benutzers vorgenommen werden.
IT-Benutzer (Entwickler, Anwender mit Customizing-Rechten etc.) besitzen innerhalb des Produktiv-
systems nur Leserechte. Ausnahmen sind in Kapitel 8.4 ber das Change-Mangagement beschrie-
ben.
End-Anwender drfen in einem Produktivsystem nicht die folgenden Rechte besitzen:
Programmierung,
nderung von Feldinhalten whrend des Programmablaufs,
Transportberechtigungen.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 29 von 67
5.2.5 Durchfhrung der Benutzerverwaltung
Der Geschftprozessinhaber/Anwendungsbetreuer ist verpflichtet, fr alle Phasen der Benutzerver-
waltung entsprechende Prozesse zu definieren.
Zu diesem Zweck muss vom Anwendungseigner, Geschftprozessinhaber und Anwendungsbetreuer
ein angemessenes Berechtigungskonzept erstellt werden. Der Anwendungsbetreuer des Benutzers
muss sicherstellen, dass nach dem Prinzip der minimalen Berechtigung dieser nur diejenigen
Zugriffsrechte erhlt, die er fr die Ausbung seiner Ttigkeiten/Funktion bentigt.
Fr Hintergrund- und Schnittstellenbenutzer (Systembenutzer) knnen Prozesse, die sich von denen
im Folgenden unterscheiden, angewendet werden. Der Anwendungseigner muss fr diese Benutzer-
kennung passende Prozesse erstellen, welche die Anforderungen an Dokumentation, Nachvollzieh-
barkeit und Autorisierung erfllen.
5.2.5.1 Dokumentation der Benutzerverwaltung
Der Anwendungsbetreuer ist zur Einfhrung und Dokumentation von Prozessen aller Stufen des Be-
nutzer-Lebenszyklus (Anlage, nderung oder Lschung einer Benutzerkennung) verpflichtet. Durch
diese Prozesse muss gewhrleistet werden, dass jeder Benutzerantrag, genauso wie alle Genehmi-
gungen, entsprechend dokumentiert und archiviert werden.
Diese Prozesse mssen Anforderungen unterschiedlicher Systemtypen innerhalb einer SAP-
Systemlandschaft (Entwicklungs-, Q/A- und Produktivsystem) und unterschiedlicher Benutzertypen
(z. B. Dialogbenutzer, Hintergrundbenutzer) bercksichtigen.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 30 von 67
5.2.5.2 Anlage von Benutzerkennungen
Whrend der Anlage einer Benutzerkennung mssen die folgenden Angaben gemacht werden:
Eine der Namenskonvention entsprechende Benutzerkennung (s. a. Kapitel 5.1.1.2)
Eine Benutzergruppe entsprechend dem Konzept fr Benutzergruppen (s. a. Kapitel 5.2 und
Namenskonvention der Georg-August-Universitt fr SAP)
Lizenzdaten entsprechend den Lizenzvereinbarungen
Berechtigungen (SAP-Rollen), die vom Benutzer entsprechend seiner definierten Funktionen
bentigt werden
Stammdaten des Benutzers
Da der Prozess der Benutzeranlage stark mit der Anforderung von Berechtigungen zusammenhngt,
wird fr weitere Vorgaben auf das Kapitel 5.2.5.3 verwiesen.
5.2.5.3 Zuweisung von Rollen zu Dialog-Benutzern
Der Anwendungsbetreuer ist verantwortlich dafr, Dokumentationen und Kontrollprozesse und/oder
Tools fr die Zuweisung von Rollen an Dialogbenutzer zur Verfgung zu stellen. Es mssen formale
und gut dokumentierte, IS-basierte Prozesse fr die Rollenzuweisung entsprechend der Stellenbe-
schreibung des Benutzers eingefhrt werden.
Alle Rollenantrge fr Dialogbenutzer mssen vom entsprechenden Anwendungsbetreuer gestellt
werden, da nur dieser die SAP-Rollen kennt, die ein Endanwender zur Durchfhrung seiner Aufga-
ben/Funktionen bentigt.
Der Anwendungsbetreuer muss auf die Einhaltung der Funktionstrennung achten. In der Regel kann
der Versto gegen eine Funktionstrennung nur dann akzeptiert werden, wenn die Berechtigungen zur
Durchfhrung der Aufgaben/Funktionen eines Benutzers unbedingt notwendig sind. Der Vorgesetzte
des Benutzers muss in regelmigen Abstnden die bekannte Verletzung der Funktionstrennung
berprfen und entscheiden, ob diese fr die Funktionen/Aufgaben des Benutzers nach wie vor not-
wendig ist.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 31 von 67
Der Vorgesetzte des Benutzers ist verantwortlich fr die berprfung und Genehmigung des doku-
mentierten Benutzerantrags.
Die Genehmigung eines Rollenantrags muss mindestens einem 4-Augen-Prinzip folgen:
Im ersten Schritt muss jeder Antrag vom Vorgesetzten des Benutzers, welcher fr die Kontrol-
le und Genehmigung der dokumentierten Zutrittsanforderungen des Benutzers zustndig ist,
geprft und genehmigt werden.
Die zweite Genehmigung muss vom Geschftsprozessinhaber der angeforderten Rolle(n)
durchgefhrt werden. Fr den Fall, dass Buchungskreis-bergreifende Zugriffe angefordert
werden, muss die Abteilungsleitung/Geschftsbereichsleitung informiert werden.
Der Geschftprozessinhaber ist fr als kritisch definierte Rollen verantwortlich (s. a. Kapitel 5.3.3) und
muss entsprechend am Genehmigungsprozess beteiligt werden.
Erst nachdem alle notwendigen Genehmigungen und alle Kontrollprozesse fr eine Funktionstren-
nung ausreichend dokumentiert sind, wird die Rolle der Benutzerkennung zugewiesen.
5.2.5.4 Zuweisung von Rollen zu nicht Dialogbenutzern ( s. Anhang HR)
Fr nicht Dialogbenutzer ist ein Verantwortlicher festzulegen. Weitere Einzelheiten s. Kapitel 5.2.5.3.
5.2.5.5 Zugang externer Mitarbeiter/Dienstleister
Alle Antrge von Mitarbeitern fr den externen Zugang zu einer SAP-Anwendung mssen von folgen-
den Instanzen genehmigt werden:
Systembetreiber
Geschftsprozessinhaber
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 32 von 67
Hierzu ist bei neu einzurichtenden Zugngen ein schriftlicher Antrag erforderlich. Weiterhin gelten
folgende Regelungen:
Bei Beratern in laufenden Projekten wird der Zugang (bei bereits bestehender Genehmigung)
dokumentiert.
Der Zugang fr den SAP-Support ist grundstzlich gesperrt. Die Entsperrung ist durch den
Veranlasser zu dokumentieren.
Zugriffe auf das Konsolidierungs- und Produktivsystem sind nur in dokumentierten Ausnah-
mefllen zeitlich befristet zulssig. Weiterhin ist eine bergeordnete Freigabe durch den An-
wendungseigner erforderlich.
Der Zugriff auf personenbezogene Daten ist zuvor mit dem Datenschutzbeauftragten abzustimmen.
5.2.5.6 Sperrung von Benutzerkennungen
Eine Benutzerkennung wird gesperrt, wenn die folgenden Voraussetzungen gegeben sind:
Im Allgemeinen wird die Sperrung eines Benutzers von einem Key-User durchgefhrt, wenn
ein vom hierfr zustndigen Anwendungsbetreuer initiierter Antrag auf Basis genderter HR-
Daten vorliegt.
Eine Sperrung kann aufgrund von Falschanmeldungen vorkommen. Dies hngt von den Ein-
stellungen der in Kapitel 5.1.5 genannten Systemprofilparametern ab.
Der Anwendungseigner - in Absprache mit dem Anwendungsbetreuer - ist dazu verpflichtet,
dass Benutzerkennungen, unter denen sich innerhalb eines bestimmten Zeitraums keine Dia-
logbenutzer angemeldet haben, gesperrt werden. Es wird ausdrcklich empfohlen, dass eine
Benutzerkennung maximal 90 Tage nach der letzten Anmeldung gesperrt wird. An den Be-
nutzer muss eine entsprechende Benachrichtigung ber die Sperrung gesendet werden.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 33 von 67
Die Sperrung der Benutzerkennungen erfolgt durch den Key-User oder durch den Anwendungsbe-
treuer (Verfahrensebene). Bei Unregelmigkeiten kann die Sperrung auch vom Anwendungseig-
ner/Anwendungsbetreuer (Technikebene) vorgenommen werden.
Um den Betrieb des Systems nicht zu gefhrden, gelten diese Regeln nicht fr die folgenden
Benutzer oder Benutzergruppen:
- Benutzer fr die Schnittstellenkommunikation,
- Benutzer fr Hintergrundprozesse (Jobnetz).
Fr (System-)Administratoren muss ein entsprechend angepasster Prozess eingefhrt und
angewendet werden.
Sofern das letzte Anmeldedatum mindestens 90 Tage zurck liegt, muss die betroffene Sach-
gebiets- bzw. Abteilungsleitung informiert werden, die darber entscheidet, ob die Benutzer-
kennung gesperrt wird oder nicht. Die Liste der Systemadministratoren muss mit dem Anwen-
dungseigner abgestimmt werden.
5.2.5.7 Entsperrung von Benutzerkennungen
Es gibt zwei Mglichkeiten, warum eine Benutzerkennung in einem SAP-System gesperrt sein kann:
Sperrung aufgrund ungltiger Anmeldeversuche und
Sperrung durch einen Key-User (individuelle Sperrung, Massensperrung).
Sofern ein Benutzer durch einen Key-User gesperrt wurde, muss ein formloser Antrag auf Entsper-
rung gestellt werden (Ausnahme: Massensperrung).
Falls eine Benutzerkennung aufgrund ungltiger Anmeldeversuche gesperrt wurde, muss der Anwen-
der den Key-User/Benutzerverwalter fr eine Entsperrung seiner Kennung bzw. fr die Erstellung
eines neuen Initialkennworts kontakten. Der Key-User/Benutzerverwalter berprft die Identitt des
Benutzers und der Benutzerkennung, basierend auf den Prozessen, die vom Anwendungseigner hier-
fr eingefhrt wurden.
Sofern der Anforderer als der Besitzer der Benutzerkennung identifiziert wurde, wird die Sperre auf-
grund ungltiger Anmeldeversuche aufgehoben und ein neues Initialkennwort erzeugt. Dieses Initial-
kennwort muss an die E-Mail-Adresse, die in den Benutzerstammdaten enthalten ist, geschickt wer-
den.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 34 von 67
In dieser E-Mail wird der Benutzer aufgefordert, das Initialkennwort umgehend zu ndern und ber
mgliche Folgen einer verzgerten nderung informiert1. Falls ein E-Mail Versand des Initialkennwor-
tes nicht mglich ist, wird dem Benutzer das Initialkennwort persnlich ausgehndigt.
5.2.5.8 Lschung von Benutzerkennungen
Fr die Lschung von Benutzerkennungen, die nicht lnger bentigt werden, muss vom Anwen-
dungsbetreuer ein entsprechender Prozess eingefhrt werden. Bevor eine Benutzerkennung aus ei-
nem SAP-System physikalisch gelscht wird, muss sicher gestellt werden, dass
- eine Historie der Benutzerkennungen und der dazugehrigen Benutzer/Personen, welche alle
lokalen Anforderungen erfllt, einen angemessenen Zeitraum zur Verfgung steht.
- die Nachvollziehbarkeit der Business-Transaktionen (wer hat was angelegt, gendert etc.),
zumindest ber einen bestimmten Zeitraum (in der Regel 10 Jahre), gewhrleistet ist.
Diese Manahmen stellen die Transparenz, Nachvollziehbarkeit der eingesetzten Verfahren und Ein-
haltung von Prfungsanforderungen sicher.
5.2.5.9 Aktualitt von Benutzerstammdaten
Der Geschftsprozessinhaber muss Prozesse einfhren, um die Aktualitt von Benutzerstammdaten
zu gewhrleisten. Diese Prozesse mssen insbesondere die nderungen von Funktionen oder Orga-
nisationsebenen des Benutzers abdecken, da dieses im Allgemeinen zu nderungen der Berechti-
gungen des Benutzers fhrt.
Obwohl hierfr Tools zur automatisierten Aktualisierung verwendet werden knnen, ist es die Aufgabe
des Anwendungsbetreuers, zu dessen Organisationseinheit der Benutzer gehrt, dafr zu sorgen,
dass die Stammdaten, genauso wie die zugewiesenen Rollen, aktuell sind.
1 Textvorschlag. Bitte ndern Sie umgehend das Initialkennwort. Beachten Sie hierbei bitte die fr das SAP-System gltigen Kennwortregeln. Bei einer verzgerten nderung des Initialkennwortes sind Sie fr alle Aktionen verantwortlich, die unter die-sem Kennwort durchgefhrt wurden.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 35 von 67
Sobald ein Benutzer seine Organisationseinheit wechselt, sind die Anwendungsbetreuer sowohl der
alten als auch der neuen Organisationseinheit verpflichtet zu prfen, ob die bislang vergebenen Be-
rechtigungen noch bentigt und/oder innerhalb eines bestimmten Zeitraums entzogen/eingeschrnkt
werden mssen.
Die Aktualitt von Benutzerstammdaten wird durch folgendes Verfahren berprft:
Die Fachabteilungen haben eine jhrliche Prfung zu gewhrleisten. Hierzu haben die Kostenstellen-
verantwortlichen die Angaben zu den Benutzerstammdaten zu besttigen oder zu ndern und dies
durch Unterschrift zu besttigen.
5.2.5.10 Rcksetzung von Kennwrtern
Sofern ein Benutzer ein neues Kennwort fr seine Benutzerkennung bentigt, findet der Prozess fr
die Entsperrung eines Benutzers Anwendung (s. a. Kapitel 5.2.5.7).
5.2.5.11 Technische Benutzerkennungen
Technische Benutzerkennungen (z. B. Benutzerkennungen fr die Hintergrundverarbeitung, Schnitt-
stellen etc.) mssen eindeutig von den Benutzerkennungen fr Dialogbenutzer, genauso wie von an-
deren Benutzertypen, unterschieden werden knnen. Dies muss durch
eine entsprechende Namenskonvention,
Benutzergruppen und
Rollen
gewhrleistet sein.
Fr jede Benutzerkennung muss ein Verantwortlicher definiert werden, auch wenn die betroffene Be-
nutzerkennung nicht fr eine interaktive Anmeldung verwendet wird.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 36 von 67
5.3 Berechtigungsverwaltung
Vom Anwendungseigner, Geschftprozessinhaber und Anwendungsbetreuer mssen gemeinsam fr
alle Phasen der Berechtigungsverwaltung Prozesse definiert werden.
5.3.1 Verwendung von Rollen und Profilen
Um Geschftsdaten und -funktionen vor unberechtigten Zugriffen zu schtzen, werden SAP-
Transaktionen und Programme durch Berechtigungsprfungen geschtzt. Um eine Berechtigungspr-
fung erfolgreich zu durchlaufen, bentigt ein Benutzer die entsprechenden Berechtigungen. Berechti-
gungen werden dem Benutzer ber Rollen oder Profile, die im Benutzerstammsatz eingetragen sind,
zugewiesen.
Die Verwendung von Rollen wird ausdrcklich empfohlen. Rollen und Profile, die von SAP ausgeliefert
werden, drfen nur in gut dokumentierten Ausnahmefllen und mit Zustimmung des Anwendungseig-
ners vergeben werden. Es wird ausdrcklich empfohlen, fr den Zugriff auf SAP-Systeme kundenei-
gene Rollen fr den Zugriff auf allgemeine Funktionen/Aktivitten zu erstellen. Die gleichzeitige Ver-
wendung kundeneigener Rollen und Profile verringert die bersichtlichkeit und sollte deshalb vermie-
den werden.
5.3.2 Organisatorische Einschrnkungen von Rollen
Damit kontrolliert und berwacht werden kann, welche Benutzer die Mglichkeit fr einen Zugriff auf
ihre Daten innerhalb ihrer Organisationseinheit haben, mssen Rollen auf diese einzelnen Bereiche
beschrnkt sein. Eine Unterteilung in Organisationsebenen muss im Einzelfall vom Geschftprozess-
inhaber und den betroffenen Bereichen der Universitt definiert, umgesetzt und kontrolliert werden.
Die Akkumulation von Rollen innerhalb von Benutzerstammstzen ber verschiedene Geschftsbe-
reiche/Abteilungen hinweg ist prinzipiell mglich, wobei in einem solchen Fall die Genehmigung aller
betroffenen Organisationseinheiten notwendig ist.
Sofern Rollen Berechtigungen beinhalten, die fr mehrere Bereiche der Universitt notwendig sind
(z. B. fr den Systemsupport), knnen diese nur mit Zustimmung des Anwendungseigners und den
betroffenen Bereichen erstellt und vergeben werden.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 37 von 67
5.3.3 Rollenverwaltung Grundlegende Prinzipien ( s. Anhang HR)
Es wird ausdrcklich empfohlen, dass die Anlage und nderung von Rollen nur im Entwicklungssys-
tem durchgefhrt wird. Die Rollen mssen innerhalb des Q/A-Systems durch den Key-
User/Anwendungsbetreuer, unter Bercksichtigung unterschiedlicher Geschftsvorflle, getestet wer-
den. Hierbei sind sowohl Positivtests (=Funktionserfllung) als auch Negativtests
(=Funktionstrennung) notwendig. Nach den Tests und einer Genehmigung werden die Rollen ber
das Transport Management System (TMS) in das Produktivsystem transportiert.
In Notfllen ist die Anlage oder nderung einer Rolle durch die Berechtigungsadministration im Pro-
duktivsystem zulssig, sofern der Anwendungseigner zugestimmt hat. Alle nderungen werden da-
nach per Down- und Upload in das Entwicklungssystem verbracht und anschlieend ber die blichen
Mechanismen des TMS in das Produktivsystem transportiert. Der Anwendungsbetreuer hat sicherzu-
stellen, dass die Rollen entsprechend den folgenden Richtlinien angelegt werden.
Alle Rollen mssen beschrieben und dokumentiert werden. Innerhalb einer Beschreibung mssen alle
durch die jeweilige Rolle zugnglichen Menpunkte und Transaktionen definiert werden. Ebenso ms-
sen mgliche Einschrnkungen dargestellt werden. Fr jede Rolle muss ein Verantwortlicher definiert
werden, der fr den Inhalt (Transaktionen, Berechtigungsobjekte, organisatorische Einschrnkungen)
und die Zuweisung der Rolle verantwortlich ist.
Fr alle Rollennderungen mssen ausreichende Dokumentationen angelegt werden.
Innerhalb einer Einzelrolle drfen keine Probleme bezglich einer Funktionstrennung auftreten.
Eine Rolle darf grundstzlich keine Berechtigungen oder Berechtigungskombinationen enthalten, die
durch den Anwendungsbetreuer kritisch oder sensitive (s. a. Kapitel 5.6) definiert wurden, sofern dies
vom Anwendungseigner nicht explizit genehmigt wurde. Eine Rolle, die kritische/sensitive Berechti-
gungen enthlt, wird automatisch als kritisch/sensitiv angesehen.
Der Geschftsprozessinhaber muss kritische/sensitive Berechtigungen und die Zuordnung der Rollen
in regelmigen Abstnden berprfen und entscheiden, ob diese immer noch bentigt werden. Ein
Bericht ber diese Untersuchungen ist an den Anwendungseigner zur Archivierung zu senden.
Einzelheiten, welche die Rollenverwaltung und den Rolleninhalt betreffen, mssen vom Geschftspro-
zessinhaber in einem spezifischen Konzept definiert werden.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 38 von 67
Spezielle Zugriffsrechte mssen auf den Personenkreis beschrnkt sein, welcher fr das System, das
Netzwerk oder das Anwendungsmanagement und/oder die Sicherheit zustndig ist.
5.3.4 Anlage neuer Rollen
Bevor eine neue Rolle angelegt wird, muss geprft werden, ob die notwendigen Funktionalitten nicht
durch bereits vorhandene Rollen zur Verfgung gestellt werden knnen.
Antrge fr die Neuanlage einer Rolle mssen mindestens einem 4-Augen-Prinzip folgen. Der erste
Genehmiger ist der Anwendungsbetreuer der Fachabteilung. Der zweite Genehmiger ist der Ge-
schftsprozessinhaber. Sofern die nderung einer Rolle mindestens eine weitere Rolle betrifft (z. B.
bei Ableitungen), mssen die Geschftsprozessinhaber aller betroffenen Rollen ber diese nderung
informiert werden.
Vor der Neuanlage einer Rolle muss der verantwortliche Anwendungsbetreuer oder das Projektteam
zuerst den Antrag prfen, um anschlieend die eigentliche Rollenerstellung anzustoen. Der Initiator
muss eine Funktionstrennung (Segregation of Duty - SoD) und kritische/sensitive Berechtigungen
bercksichtigen.
Mssen kritische/sensitive Berechtigungen vergeben werden, entscheidet der Anwendungsbetreuer
gemeinsam mit dem Geschftsprozessinhaber, ob diese kritischen/sensitiven Berechtigungen in der
Rolle bentigt werden.
Der Anwendungsbetreuer muss die Anforderung genehmigen und besttigen, dass er/sie sich enthal-
tener kritischer/sensitiver Transaktionen bewusst ist. Die Anforderung fr die Aufnahme kritischer oder
sensitiver Berechtigungen in eine Rolle muss vom Anwendungseigner explizit genehmigt werden.
5.3.5 nderung bestehender Rollen
Antrge fr die nderung einer Rolle mssen mindestens einem 4-Augen-Prinzip folgen. Der erste
Genehmiger ist der Anwendungsbetreuer der Fachabteilung. Der zweite Genehmiger ist der Ge-
schftsprozessinhaber. Sofern die nderung einer Rolle mindestens eine weitere Rolle betrifft (z. B.
bei Ableitungen), mssen die Geschftsprozessinhaber aller betroffenen Rollen ber diese nderung
informiert werden.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 39 von 67
Sofern die nderung einer Rolle aufgrund bestimmter Geschftsanforderungen notwendig ist, muss
der verantwortliche Anwendungsbetreuer oder das Projektteam den Rollennderungsprozess ansto-
en. Hierbei mssen Funktionstrennung (SoD) und kritische/sensitive Berechtigungen bercksichtigt
werden.
Mssen kritische/sensitive Berechtigungen vergeben werden, entscheidet der Anwendungsbetreuer
gemeinsam mit dem Anwendungseigner, ob diese kritischen/sensitiven Berechtigungen in der betrof-
fenen Rolle bentigt werden.
Der Anwendungsbetreuer muss die Anforderung genehmigen und besttigen, dass er sich enthalte-
ner kritischer/sensitiver Transaktionen bewusst ist. Die Anforderung fr die Aufnahme kritischer oder
sensitiver Berechtigungen in eine Rolle muss vom Anwendungseigner explizit genehmigt werden.
5.3.6 Lschung von Rollen
Fr die Lschung von Rollen, die nicht lnger bentigt werden, muss vom Geschftprozessinhaber
ein Prozess definiert werden. Bevor eine Rolle physisch aus einem SAP-System gelscht werden
kann, muss sichergestellt werden, dass die Nachvollziehbarkeit ihres Inhalts und die Zuordnung zu
Benutzerkennungen ber einen Zeitraum, der allen Anforderungen einer Revision erfllt, gegeben ist.
Es wird empfohlen, von zu lschenden Rollen mit den entsprechenden SAP-Funktionen einen Down-
load zu erstellen. Die Aufbewahrungsfrist betrgt 10 Jahre.
Rollen mssen im Entwicklungssystem gelscht und die Lschung auf dem blichen Weg, der im
Change Management Prozess definiert wird, transportiert werden. Diese Manahme stellt die Trans-
parenz, Nachvollziehbarkeit und Einhaltung von Prfungsanforderungen sicher.
5.3.7 Sammelrollen
Sammelrollen bestehen aus mehreren Einzelrollen. Benutzern, denen eine solche Sammelrolle zuge-
wiesen wurde, werden automatisch die entsprechenden Einzelrollen zugewiesen. Die Sammelrollen
selbst enthalten keine Berechtigungsdaten.
Bei der Verwendung von Sammelrollen finden alle bereits gemachten Regelungen fr Einzelrollen
Anwendung.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 40 von 67
5.3.8 Berechtigungen fr Projekte und Business Requests
Sobald ein Projekt definiert und genehmigt wurde, muss durch den Projektleiter das Projektteam fest-
gelegt und dokumentiert werden sowie die fr dieses Projektteam notwendigen Berechtigungen defi-
niert werden. Fr diese Berechtigungen finden alle weiter oben gemachten Regeln und Prozesse (z.
B. kritische Transaktionen, SoD) Anwendung. Fr den Zugriff eines Mitglieds des Projektteams auf
das Entwicklungssystem ist die Genehmigung des betroffenen Anwendungseigners notwendig.
Projektberechtigungen drfen nur an die bekannten Mitglieder des Projektteams und nur fr die Dauer
des Projekts selbst vergeben werden. Projektrollen drfen nicht innerhalb eines Produktivsystems
verwendet werden.
Fr tgliche Arbeiten, die innerhalb des Produktivsystems notwendig sind, mssen whrend des Pro-
jekts entsprechende Berechtigungen definiert werden.
5.4 Einsatz von Notfallbenutzern
Fr Notflle knnen eine begrenzte Anzahl spezieller Benutzerkennungen mit umfassenden Basis-
oder Funktionsberechtigungen zur Verfgung gestellt werden:
Definition eines Notfalls:
Betrifft nicht den tglichen Betrieb,
Kommt nicht periodisch vor,
Betrifft kritische Systemkomponenten.
Alle Anforderungen fr die Verwendung einer Notfallbenutzerkennung mssen dokumentiert werden.
Diese Dokumentation muss den Grund fr den Notfalleinsatz und die notwendigen Aktivitten, die im
SAP-System durchgefhrt werden sollen, enthalten.
Die Aktivitten von Notfallbenutzern mssen systemseitig protokolliert werden.
Der Anwendungseigner muss regelmig die Effektivitt dieses Prozesses berwachen.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 41 von 67
5.5 Funktionstrennung
Vom Geschftprozessinhaber/Anwendungsbetreuer muss eine Liste von Berechtigungen/Trans-
aktionen, die inkompatible Aufgaben und/oder Verantwortlichkeiten reprsentieren und nicht in einer
Rolle oder einem Benutzerstammsatz gemeinsam vorkommen drfen, definiert werden. Fr die Erstel-
lung einer solchen Liste inkompatibler Funktionen und Berechtigungen werden Anforderungen aus
den Geschftsprozessen und anderen Quellen bercksichtigt.
Der Geschftsprozessinhaber hat mit den entsprechenden SAP-Reports zu prfen, ob an die Benut-
zer kritische Berechtigungen/Berechtigungskonstellationen vergeben wurden.
Die Funktionstrennung untersttzt dabei die Transparenz von Geschftsprozessen zur Vermeidung
von Unregelmigkeiten, Betrug und anderer strafbarer Tatbestnde.
Aus diesem Grund muss bei jeder Rollennderung oder bei der Zuweisung von Rollen zu Benutzer-
kennungen die Einhaltung der Funktionstrennung geprft werden. Fr die Handhabung dieser Funkti-
onstrennung bei der Berechtigungs- oder Benutzerverwaltung wird auf die entsprechenden Kapitel
verwiesen.
Eine Rolle, welche eine Funktionstrennung nicht realisiert, muss vom Anwendungseigner gesondert
betrachtet werden.
Der Geschftsprozessinhaber muss regelmig innerhalb seiner Anwendung prfen, ob bislang un-
dokumentierte Probleme in Verbindung mit der Funktionstrennung vorhanden sind.
5.6 Kritische/Sensitive Berechtigungen
Neben dem Problemkreis der Funktionstrennung knnen auch einzelne Transaktionen oder Berechti-
gungen, genauso wie Transaktionskombinationen, als kritisch oder sensitive betrachtet werden. Eine
Liste kritischer/sensitiver Berechtigungen muss vom Geschftsprozessinhaber definiert werden.
Hierbei wird unterschieden nach:
Kritische Berechtigungen sind nur innerhalb der Rollen fr die Administration oder fr Notflle
erlaubt.
Sensitive Berechtigungen sind in Rollen fr spezielle Zwecke erlaubt.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 42 von 67
Fr jede dieser Kategorien mssen angemessene Verpflichtungserklrungen vom Geschftsprozess-
inhaber eingefhrt werden.
Eine Rolle, die kritische/sensitive Berechtigungen enthlt, wird automatisch als kritisch/sensitive be-
trachtet.
Sofern Berechtigungen, die in diesen Kategorien aufgefhrt sind, in Rollen eingetragen werden sollen,
mssen vom Geschftsprozessinhaber angemessene Manahmen fr ein Risiko-Management einge-
fhrt werden.
6. Schnittstellen
Es gibt eine Vielzahl von Schnittstellen fr die Kommunikation mit SAP-Systemen. Vom Anwendungs-
eigner mssen Prozesse fr die Implementierung und Verwaltung solcher Schnittstellen erstellt wer-
den. Diese Prozesse mssen sicherstellen, dass
fr jede Schnittstelle eine Dokumentation vorhanden ist und weitergefhrt wird,
fr jede Schnittstelle ein Verantwortlicher bestimmt wird. Die Aufgaben eines solchen Schnitt-
stellen-Verantwortlichen beinhalten die Genehmigung der Verwendung dieser Schnittstelle
durch weitere Anwendungen und, falls notwendig, die Verwaltung von Benutzerkennungen
und Kennworten, die fr diese Schnittstelle verwendet werden.
6.1 Remote Communications (RFC & CPIC)
Fr die Kommunikation zwischen SAP- und externen Systemen oder Funktionsbausteinen werden der
Remote Function Call (RFC) und die CPIC-Schnittstelle verwendet. RFC ermglicht es, Anwendungen
und/oder Funktionsbausteine, die auf einem anderen System vorhanden sind, aufzurufen. Die CPIC-
Schnittstelle dient der Programm-Programm-Kommunikation zwischen einem SAP-System und einem
externen Programm oder System.
Es muss sichergestellt werden, dass sog. Schnittstellenbenutzer oder CPIC-Benutzer nur ber
diejenigen Berechtigungen verfgen, welche sie fr die Ausfhrung der Schnittstellen-Programme
bentigen. Daraus folgt, dass CPIC-Benutzern ausschlielich funktionsbezogene Rollen/Profile zuge-
ordnet werden, auch wenn dieser Benutzer nicht fr eine Dialoganmeldung verwendet werden kann.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 43 von 67
Zustzlich mssen fr die RFC- und CPIC-Kommunikation mit einem SAP-System die folgenden
Manahmen vorgenommen werden:
Die Berechtigungen zur Verwaltung von RFC-Verbindungen mssen eingeschrnkt werden.
Nur die hierfr zustndigen Administratoren drfen ber entsprechende Berechtigungen ver-
fgen.
Es drfen nur Informationen ber Systembenutzer, nicht ber Dialogbenutzer, gespeichert
werden. RFC-Verbindungen werden im SAP-System mit den Standard-Kennwort-
mechanismen geprft. Aus diesem Grund muss sich ein Benutzer, welcher eine RFC-
Verbindung aufbauen mchte, am entfernten System mit einer gltigen Benutzerkennung und
einem Kennwort anmelden. Entweder werden diese Informationen mit der RFC-Verbindung
gepflegt (fr Systembenutzer) oder der Benutzer wird bei der Anmeldung zur Eingabe seiner
Benutzerkennung und seines Kennworts aufgefordert. Fr Dialogbenutzer drfen keinerlei In-
formationen in den RFC-Verbindungen gespeichert werden. Benutzer mit gespeicherten An-
meldedaten drfen im Zielsystem nur ber die zur Ausfhrung ihrer Ttigkeiten notwendigen,
minimalen Berechtigungen verfgen.
Der Zugang zur Tabelle RFCDES muss eingeschrnkt sein, da die fr eine RFC-Verbindung
notwendigen Informationen, einschlielich der Benutzerkennung und des Kennworts, in dieser
Tabelle hinterlegt werden.
Alle fr die Remote-Kommunikation verwendeten Benutzerkennungen mssen vom Benutzertyp
Kommunikation sein und einer speziellen Benutzergruppe zugewiesen werden.
Fr Schnittstellen-Benutzer sind grundstzlich spezielle, funktionsbezogene Rollen zu erstellen, die
insbesondere nicht an Dialogbenutzer vergeben werden drfen. Sofern technisch und organisatorisch
mglich, drfen diese Rollen nur diejenigen Berechtigungen enthalten, welche fr die Ausfhrung aller
notwendigen Aktivitten der Schnittstelle bentigt werden.
In bestimmten Fllen kann es notwendig sein, dass diesen Benutzern umfangreichere Rechte zur
Verfgung gestellt werden mssen. In einem solchen Fall muss der Anwendungseigner die Verwen-
dung solcher umfangreicherer Rollen genehmigen.
Bezglich des SAP Standardbenutzers SAPCPIC wird auf das Kapitel 5.1.6.2 verwiesen.
Vom Anwendungseigner muss ein Konzept fr die Zuordnung von Berechtigungen fr die Definition
und die Ausfhrung von Schnittstellen erstellt werden.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 44 von 67
6.2 Hintergrundverarbeitung
Hintergrundprozesse werden fr die Automatisierung immer wieder kehrender Routineaufgaben ver-
wendet und helfen dabei, SAP-System-Ressourcen zu optimieren. Die Hintergrundverarbeitung wird
immer dann verwendet, wenn zeit- und/oder ressourcenintensive Programme whrend einer geringen
Systemlast ausgefhrt und die Aufgabe des Anstartens von Reports oder Programmen an das Sys-
tem delegiert werden sollen.
Benutzerkennungen, die fr die Hintergrundverarbeitung verwendet werden, mssen als Systembe-
nutzer (nicht Dialogbenutzer!) definiert werden und verfgen nur ber die fr die Ausfhrung von Pro-
grammen notwendigen Berechtigungen.
Fr Schnittstellen-Benutzer sind grundstzliche spezielle, funktionsbezogene Rollen zu erstellen, die
insbesondere nicht an Dialogbenutzer vergeben werden drfen. Sofern technisch und organisatorisch
mglich, drfen diese Rollen nur diejenigen Berechtigungen enthalten, welche fr die Ausfhrung aller
notwendigen Jobsteps bentigt werden.
In bestimmten Fllen kann es notwendig sein, dass diesen Benutzern umfangreichere Rechte zur
Verfgung gestellt werden mssen. In einem solchen Fall muss der Anwendungseigner die Verwen-
dung solcher umfangreicherer Rollen genehmigen.
Vom Anwendungseigner muss ein Konzept fr die Zuordnung von Berechtigungen fr die Jobdefiniti-
on und die Jobausfhrung erstellt werden.
6.3 Batch / Fast / Direct Input
Batch-Input und Fast-Input sind Standardtechniken fr die bertragung groer Datenmengen in ein
SAP-System. Eine typische Anwendung ist die periodische bertragung von Daten eines externen
Systems. Innerhalb eines Batch-Input werden alle innerhalb einer Transaktion fr die Datenintegritt
implementierten Prfungen durchgefhrt.
Da durch Batch-Inputs Daten von einem externen System in ein SAP-System importiert werden, ms-
sen alle notwendigen Manahmen ergriffen werden, um das SAP-System vor unberechtigten nde-
rungen zu schtzen.
Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen
Stand: 24.10.2007 Seite 45 von 67
Wird ein Batch-Input im Rahmen der Hintergrundverarbeitung ausgefhrt, wird fr die Verarbeitung
diejenige Benutzerkennung bzw. deren Berechtigungen verwendet, welche durch das die Batch-Input-
Mappe erzeugende Programm definiert wurde. Findet die Verarbeitung im Dialogmodus statt, sind
dies die Berechtigungen des aktuell angemeldeten Dialogbenutzers.
Alle Eingabedateien, die fr einen Batch-Input verwendet werden, mssen vor einem unberechtigten
Zugriff geschtzt werden.
Es wird ausdrcklich empfohlen, Batch-Input Benutzer vo