Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
__________________________________________________________________________
Sicherheitsleitfaden für SAP-Verfahren
- Security Guide Line -
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
einschließlich der Universitätsmedizin Göttingen Medizinische Fakultät und Universitätsklinikum
Endfassung: 24. Oktober 2007
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 2 von 67
Inhaltsverzeichnis
1. Zielsetzung 8
1.1 Einführung 8
1.2 Zielgruppe 9
2. Geltungsbereich dieser Richtlinie 9
3. Gewährleistung einer sicheren IT-Landschaft 10
3.1 Rahmenwerk für Informationssicherheit 10
3.2 Verantwortlichkeiten für die Einhaltung der Richtlinien 10
3.2.1 Kontrollprozesse 11
3.2.2 Eskalationsverfahren 11
3.3 Management von IT-Risiken 11
3.4 Einschränkung 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 Geschäftsprozessinhaber (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-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
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 Durchführung der Benutzerverwaltung 29
5.3 Berechtigungsverwaltung 36
5.3.1 Verwendung von Rollen und Profilen 36
5.3.2 Organisatorische Einschränkungen 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 Löschung von Rollen 39
5.3.7 Sammelrollen 39
5.3.8 Berechtigungen für Projekte und Business Requests 40
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
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 Systemöffnung für Customizing / Entwicklung 54
8.5 Remote-Zugriff für den SAP-Support 54
8.6 Namenskonventionen 55
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
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 Systemaktivitäten 58
10.1 Systemprotokoll 58
10.2 Überwachung spezieller Benutzerkennungen 58
10.3 Datenintegrität – Verbuchungsabbrüche 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-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 6 von 67
Anhang SAP-HR
5.1.1.3 Funktionale und mehrfach verwendete Benutzerkennungen
5.2.4.1 Qualitätssicherungssysteme
5.2.4.2 Produktivsysteme
8.1.1 Tabellenprotokollierung
Anlagen
A1 Namenskonvention GAU (Georg-August-Universität)
A2 Namenskonvention für Benutzer/innen (HR-spezifisch)
A3 Transport und Genehmigung von Aufträgen/Aufgaben
A4 Formulare für den HR-Zugang
A5 Beteiligte Personen und Aufgaben (HR-spezifisch)
A6 Mitglieder des internen SAP-Prüfteams
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 7 von 67
Abkürzungen
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-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 8 von 67
1. Zielsetzung
1.1 Einführung
Um die
Vertraulichkeit,
Integrität,
Verfügbarkeit und
Authentizität
der Daten innerhalb der SAP-Anwendungen der Universität Göttingen sicherzustellen, müssen alle
Zugriffe auf wichtige Informationsbestände kontrolliert und nachvollziehbar erfolgen.
Diese Richtlinie definiert ein Rahmenwerk für Informations- und Systemsicherheit, in dem
die zugrunde liegenden Regeln,
die dafür notwendigen Prozesse,
die anschließenden Kontrollen für die Zugriffsrechte innerhalb eines SAP-Systems und
die hierbei zu berücksichtigenden Funktionen und Verantwortlichkeiten
erläutert 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, Geschäftsprozessinhaber und Anwendungsbetreuer (s. Kapitel 4) des jeweiligen
SAP-Systems in Form konkreter, systemspezifischer Berechtigungskonzepte, die auf dieser globalen
Richtlinie aufbauen, durchgeführt werden. Der Geschäftprozessinhaber ist verantwortlich für die Er-
stellung dieser systemspezifischen Berechtigungskonzepte, in denen alle notwendigen Prozesse zu
dokumentieren sind.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 9 von 67
Der Geschäftsbereich Informationstechnologie der Universitätsmedizin (G3-7), die Stabsstelle Daten-
verarbeitungsangelegenheiten der Universität (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 Geschäftprozess-
inhaber als auch der Kontrolle der Internen Revision (IR) im Rahmen der vorgegebenen Prüfaufga-
ben.
1.2 Zielgruppe
Die Richtlinie wendet sich an den folgenden Personenkreis:
1. Präsidium der Universität und Vorstand der Universitätsmedizin
2. Leitung der Geschäftsbereiche/Abteilungen und SAP-Anwendungsbetreuung
3. Leitung und die an den SAP-Geschäftsprozessen beteiligten Sachgebiets-
leiter/-innen des Geschäftsbereichs Informationstechnologie (G3-7)
4. Leitung und die an den SAP-Geschäftsprozessen beteiligten Abteilungsleiter/-innen
der Stabsstelle DV
5. Interne Revision, Datenschutzbeauftragte der Universität und der Universitätsmedizin
6. Endanwender (insbesondere 5.1.4, sofern keine gesonderten Regelungen existieren)
7. Externe SAP-Nutzer [Akademie der Wissenschaften (AdW), Studentenwerk Göttingen (STW),
Gemeinsamer Bibliotheksverbund (GBV), Göttinger Experimentallabor für junge Leute
e. V.(XLAB)]
8. Support Benutzer
2. Geltungsbereich dieser Richtlinie
Die aktuelle Sicherheitsrichtlinie ist für alle Bereiche der Georg-August-Universität Göttingen, die
SAP-Anwendungen bereitstellen oder nutzen, bindend.
Sie gilt uneingeschränkt für das Produktivsystem und für das Konsolidierungssystem, soweit dieses
eine 1:1-Kopie des Produktivsystems ist. Abweichungen sind zu dokumentieren.
Die Richtlinie gilt nicht für das Testsystem, da sich in diesem nur anonymisierte Daten befinden dür-
fen.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 10 von 67
3. Gewährleistung einer sicheren IT-Landschaft
Die Gewährleistung der IT-Sicherheit ist ein wesentliches strategisches IT-Ziel der Universität Göttin-
gen Stiftung Öffentlichen Rechts. Im Rahmen dieses Leitfadens wird daher auf die entsprechenden
Strategiepapiere des Präsidiums der Universität Göttingen und des Vorstands der Universitätsmedizin
verwiesen.
3.1 Rahmenwerk für Informationssicherheit
Der SAP-Sicherheitsleitfaden ist ein Teil des Rahmenwerks für Informationssicherheit. Als weitere
Komponenten dieses Rahmenwerks sind Policies, Direktiven, Richtlinien und Leitfäden erforderlich.
Für die Universität Göttingen existiert folgendes Rahmenwerk zur IT-Sicherheit:
Organisationsrichtlinie zur IT-Sicherheit der Georg-August-Universität Göttingen,
Sicherheitsrahmenrichtlinie der Georg-August-Universität Göttingen.
Globale Komponenten (vornehmlich Policies, übergeordnete Richtlinien und Direktiven) des Rah-
menwerks werden jeweils durch die entsprechenden Gremien der Universität bzw. durch die Gremien
der Universitätsmedizin 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 für die Einhaltung der Richtlinien
Die Verantwortlichkeit für die Einhaltung der Richtlinien liegt bei den jeweiligen Geschäftsberei-
chen/Abteilungen bzw. Organisationseinheiten.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
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 für Informationssicherheit beschrieben
sind, umgesetzt werden. Sie richten darüber hinaus regelmäßig auszuführende Kontrollprozesse ein,
um die Umsetzung dieser Regeln nachzuweisen und stellt ein Frühwarnsystem zur rechtzeitigen Er-
kennung und Vermeidung von IT-Risiken zur Verfügung. Diese Kontrollprozesse bedingen sowohl
technische Lösungen (z. B. Nagios, SAP-CCMS) als auch organisatorische Maßnahmen (regelmäßi-
ge Besprechungen, Audits).
3.2.2 Eskalationsverfahren
Eskalationsverfahren müssen eingeleitet werden, wenn das Problem mit der Standardvorgehenswei-
se nicht gelöst 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 für andere
Stellen relevanten Probleme, vorgenommenen Handlungen, Ergebnisse dieser Handlungen und so-
weit erforderlich, empfohlenen weitere Schritte zusammengefasst werden. Weiterhin geht ein Bericht
an das Präsidium der Universität bzw. an den Vorstand der Universitätsmedizin. 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 Maßnahmen
zur positiven Änderung der Risikosituation an der Universität Göttingen unter Berücksichtigung einer
ausgewogenen Kosten-Nutzen-Relation, zu ergreifen. Dies geschieht unter anderem durch
Minimierung von Risiken
Bestehende Risiken werden durch die Umsetzung entsprechender Sicherheitsmaßnahmen
minimiert. Hierzu gehören u. a. Zutrittskontrollen, Betrieb eines Ausfallrechenzentrums, Back-
up, dezentrale Datenarchivierung und Netzwerksicherheit (Virenschutz, Firewall etc.).
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
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 müssen diese
bekannten und akzeptierten Risiken periodisch und möglichst zeitnah überwacht (z. B. durch
regelmäßig zu erstellende Berichte) und damit weitestgehend eingeschränkt werden.
Übertragung von Risiken In diesem Fall wird das Risiko an einen Dritten, z. B. die Umsetzung bestimmter Prozesse des
Rahmenwerks für Informationssicherheit an einen Dienstleister durch Service Level Agree-
ments, übertragen. Die Verantwortlichkeit für die korrekte Umsetzung der Sicherheitsstan-
dards und für die entsprechenden Kontrollen kann nicht delegiert werden.
3.4 Einschränkung des Zugangs zu SAP-Systemen durch ein Berechtigungskonzept
Die Einschränkung des Zugangs zu Anwendungen, IT-Systemen und zur gesamten IT-Infrastruktur ist
eine der wichtigsten Maßnahmen, um einen unberechtigten Zugriff auf Geschäftsdaten und in dessen
Folge deren Manipulation zu verhindern. Das in dieser Richtlinie beschriebene globale SAP-
Berechtigungskonzept beschreibt die allgemein gültigen Grundlagen an alle SAP-Plattformen und
-Applikationen, die von der Universität Göttingen 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 Ausführung von Funktionen innerhalb eines
SAP-Systems verfügt, bedeutet nicht zwangsläufig, 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-
tionsübergreifend tätig sind.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
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 für alle produkti-
ven SAP-Systeme. Systemspezifische Anforderungen können in Teilen Abweichungen notwendig
machen, die von den zuständigen Leitungsgremien der Universität Göttingen und der Universitätsme-
dizin genehmigt werden müssen. Hierbei müssen Integrität und Konsistenz der Daten, die Nachvoll-
ziehbarkeit und Transparenz der eingesetzten Verfahren gewährleistet sein.
Alle Abschnitte dieser Richtlinie werden entsprechend den folgenden Definitionen klassifiziert:
Verbindlich
Diejenigen Abschnitte der Richtlinie, die als „verbindlich“ gekennzeichnet sind, müssen für alle
Bereiche der Universität Göttingen, 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 prüfen
regelmäßig bzw. im Rahmen eines Prüfauftrags (betr. Interne Revision) die Einhaltung dieser
Abschnitte der Richtlinie.
Ausdrücklich empfohlen Systemspezifische Anforderungen können Abweichungen in einzelnen Punkten dieser Richt-
linie notwendig machen. Die Notwendigkeit solcher Abweichungen müssen vom Anwen-
dungseigner oder Geschäftprozessinhaber gegenüber den zuständigen 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 müssen in systemspezifischen Konzep-
ten behandelt werden.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 14 von 67
4. Funktionen und Verantwortlichkeiten
Für alle SAP-Systeme sind Rollen und Verantwortlichkeiten festzulegen, die sich an dem folgenden
Organisationsschema orientieren können:
4.1 Systembetreiber Geschäftsbereich G3-7, Informationstechnologie
4.2 Geschäftsprozessinhaber (Information Owner) Abteilungsleitung/Sachgebietsleitung
4.3 Anwendungseigner - Sachgebietsleitung/Abteilungsleitung, die für das SAP-Modul zuständig ist
- SAP-Basisbetreuung in den IT-Abteilungen
4.4 Anwendungsbetreuer/Application Support (IT-Abteilung) Kontaktperson für Probleme der Anwendungsbetreuer in der Fachabteilung.
4.5 Anwendungsbetreuer (Fachabteilung) SAP-Anwendungsbetreuer in der Fachabteilung ist Kontaktperson für Probleme der Endan-
wender, die vom Key-User nicht gelöst werden können.
4.6 Key-User Erste Kontaktperson für Endanwender innerhalb einer Organisationseinheit für Probleme, die
im täglichen 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
zugehörigen Verantwortlichkeiten sind in Anlagen geregelt.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 15 von 67
5. Benutzer- und Kennwortverwaltung
Der Zugang von Benutzern und die Kennwortverwaltung muss grundsätzlich durch entsprechende
Regelungen zur “Nutzung der IT-Infrastruktur“ und eine “Sicherheitsrichtlinie Kennwortschutz“ festge-
legt werden. Diese werden durch folgende Anforderungen ergänzt, falls es in den geforderten Regel-
werken hierfür keine gesonderten Festlegungen gibt.
5.1 Identifizierung und Authentifizierung
Ein SAP-Anwender muss sich an einem SAP-System mittels einer eindeutigen Benutzerkennung und
dem zugehörigen Kennwort anmelden. Dies kann auch über ein „Single-Sign-on“-Verfahren erfolgen.
Indem er diese Daten eingibt, identifiziert sich der Benutzer gegenüber dem SAP-System, welches
anschließend prüft, ob der Benutzer für 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 zugänglich zu machen.
5.1.1.2 Namenskonventionen für Benutzerkennungen
Für die Namenskonventionen der Benutzerkennungen gelten die folgenden, allgemeinen Regeln:
Benutzerkennungen für Dialogbenutzer müssen eindeutig sein.
Jeder Benutzer darf nur über eine einzige, ihm zuordenbare, Benutzerkennung verfügen.
Für jede Benutzerkennung ist ein Verantwortlicher festzulegen, auch wenn die Benutzerken-
nung nicht für eine interaktive Anmeldung verwendet wird.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 16 von 67
Alle Benutzerkennungen müssen regelmäßig vom Anwendungsbetreuer (Verfahrensebene) auf die
Einhaltung der Namenskonventionen überprüft werden. Abweichungen von den Namenskonventionen
sind zu klären und unverzüglich zu korrigieren.
Für 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 grundsätzlich verboten. Über diese vertragliche Regelung hinaus dürfen
keine funktionalen bzw. anonymisierten Benutzerkennungen im Rahmen dieser Richtlinie verwendet
werden, um eine eindeutige Identifikation von Benutzern und die Nachvollziehbarkeit von deren Aktivi-
täten (z. B. die Ausführung von Transaktionen, Programmen, Hintergrundjobs) innerhalb der Anwen-
dungen und IT-Systeme zu gewährleisten.
Ausnahmen aufgrund spezieller technischer Voraussetzungen oder Anforderungen aus (operativen)
Geschäftsprozessen müssen vom hierfür zuständigen Anwendungsbetreuer (Verfahrensebene) ge-
nehmigt werden.
Für die Hintergrund- und/oder Schnittstellenverarbeitung (s. a. Kapitel 6) können 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 abhängig sein.
Die Verwaltung von Benutzerkennungen für die Hintergrund- bzw. Schnittstellenverarbeitung ist auf
einen bestimmten Personenkreis, der vom Anwendungseigner genehmigt werden muss, einzuschrän-
ken.
Administrative Prozesse, die sich über den gesamten Lebenszyklus einer Benutzerkennung erstre-
cken, müssen vom Anwendungsbetreuer (Verfahrensebene) eingeführt und regelmäßig überwacht
werden.
5.1.2 Mandanten 000 und 001
Der Mandant 000 – und meist auch der Mandant 001 – sind Referenzmandanten. Aus diesem Grund
müssen die Zugriffe auf diese beiden Mandanten eingeschränkt werden.
Vom Anwendungseigner muss eine Liste der Benutzer und ihrer Benutzerkennungen, die innerhalb
der Mandanten 000 und 001 definiert sind, zur Verfügung gestellt werden.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 17 von 67
Die Benutzerkennungen in den Mandanten 000 und 001 werden regelmäßig vom internen Prüfteam
(s. Anlage A6) geprüft. Hierbei wird die Liste der genehmigten Benutzerkennungen mit den tatsächlich
vorhandenen Benutzerkennungen verglichen. Werden Abweichungen festgestellt, müssen die Ursa-
chen hierfür bestimmt und der in der Dokumentation festgelegte Stand wieder hergestellt werden. Die
Prüfungsergebnisse und alle Berichte müssen dem Anwendungseigner zur Bestätigung übersandt
und archiviert werden.
5.1.3 Mandant 066
Innerhalb des Mandanten 066 sind standardmäßig die SAP-Benutzerkennungen
EARLYWATCH und
SAP*
vorhanden.
Für die Ausführung von Tätigkeiten innerhalb der SAP-Basis kann es notwendig sein, in Abstimmung
mit dem Anwendungseigner eine dritte Benutzerkennung einzurichten.
Die Benutzerkennungen in den Mandanten 066 werden regelmäßig vom internen Prüfteam geprüft.
Hierbei wird die Liste der genehmigten Benutzerkennungen mit den tatsächlich vorhandenen Benut-
zerkennungen verglichen. Werden Abweichungen festgestellt, müssen die Ursachen hierfür bestimmt
und der in der Dokumentation festgelegte Stand wieder hergestellt werden. Die Prüfungsergebnisse
und alle Berichte müssen dem Anwendungseigner zur Bestätigung übersandt und archiviert werden.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
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 geändert werden können (s. a. aktuelle
SAP Hinweise):
Das Kennwort kann nicht länger als 8 Zeichen lang sein.
Das erste Zeichen eines Kennworts darf kein Ausrufezeichen, Fragezeichen oder Leerzei-
chen sein.
Die ersten drei Zeichen dürfen 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 dürfen 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 fünf verwendeten Kennwörtern unterschiedlich sein. Im Gegensatz hierzu kann ein Admi-
nistrator ein Kennwort wählen, welches mit einem der letzten fünf Kennwörter des Benutzers
identisch ist. Diese Ausnahme ist notwendig, da ein Administrator die Kennwörter 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 geändert werden.
Ein Benutzer kann sein Kennwort maximal einmal täglich ä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 Einträge der Tabelle USR40)
betreffen nicht bereits vorhandene Kennwörter. Die Kennwortregeln werden nur bei der Ände-
rung eines Kennworts berücksichtigt.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 19 von 67
5.1.4.2 Änderbare Kennwortregeln
Über diese systemseitig vorgegebenen Kennwortregeln hinaus gibt es die Möglichkeit, änderbare
Kennwortregeln zu verwenden und somit an kundenspezifische Anforderungen anzupassen. Die Ein-
stellung der folgenden Parameter auf die genannten Werte wird ausdrücklich empfohlen.
Mindestlänge 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.
Gültigkeitszeitraum 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, geändert 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 mög-
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 möglicher 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-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
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) gelöscht, 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 regelmäßig die eingestellten Parameter mit den definierten, doku-
mentierten Werten. Abweichungen müssen identifiziert, die Ursachen hierfür ermittelt und die definier-
ten Einstellungen wieder hergestellt werden.
5.1.4.3 Tabelle der verbotenen Kennwörter
Neben den bereits dargestellten Einstellungen über Systemprofilparameter, können in der Tabelle
USR40 unzulässige Kennwörter (z. B. triviale Kennwörter oder einfache Zeichenkombinationen) defi-
niert werden. Diese Liste muss in jedem System erstellt und gepflegt werden. Sie muss mindestens
Wochentage,
Monate,
Länder,
Feiertage,
Jahreszeiten,
häufig verwendete Vornamen,
Automarken,
wichtige Städte usw.
enthalten.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 21 von 67
5.1.4.4 Initialkennwörter
Initialkennwörter werden bei der Anlage einer Benutzerkennung oder nach der Rücksetzung eines
Benutzerkennworts erzeugt. Bei der ersten oder einer erneuten Anmeldung des Benutzers muss die-
ser das Initialkennwort durch ein benutzerdefiniertes Kennwort ersetzen.
Für die Erzeugung von Initialkennwörtern 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 für das Mindestmaß an Sicherheit eines SAP-Systems notwendig sind. Sys-
temspezifische Gegebenheiten können unterschiedliche Einstellungen, insbesondere für Qualitätssi-
cherungs- und Entwicklungssysteme, erfordern.
Die folgenden Einstellungen sind verbindlich:
Deaktivierung von Berechtigungsprüfungen
Über die Transaktionen SU25 oder AUTH_SWITCH_OBJECTS können Berechtigungsprü-
fungen für bestimmte Berechtigungsobjekte global deaktiviert werden. Um dies zu verhindern,
muss der Systemprofilparameter AUTH/OBJECT_DISABLING_ACTIVE auf den Wert „N“ ge-
setzt werden.
Berechtigungsprüfungen können über den Systemprofilparameter
AUTH/NO_CHECK_IN_SOME_CASES unterdrückt werden. Die Anzahl der Berechtigungs-
prüfungen, die seitens SAP vorgeschlagen werden, können über die Transaktion SU24 ver-
ringert werden. Dies setzt voraus, dass der Systemprofilparameter den Wert „Y“ für die Deak-
tivierung von Berechtigungsprüfungen 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-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 22 von 67
Berechtigungsprüfungen für Remote Function Calls (RFCs) Der Systemprofilparameter AUTH/RFC_AUTHORITY_CHECK steuert, ob während Remote
Function Calls (RFCs) Berechtigungsprüfungen auf das Berechtigungsobjekt durchgeführt
werden. Der Wert dieses Systemprofilparameters muss auf „1“ gesetzt werden, d. h. die Be-
rechtigungsprüfung für RFC-Aufrufe ist aktiv.
Die folgenden Einstellungen werden ausdrücklich empfohlen:
Mehrfachanmeldungen von Dialogbenutzern mit
einer einzigen Benutzerkennung verhindern Ein Benutzer sollte sich über einen SAPGUI an einem SAP-System grundsätzlich nur einmal
anmelden können. Gleiches gilt für die Mehrfachanmeldung von einem Frontend-Rechner
aus, wobei der Benutzer immer noch die Möglichkeit hat, während 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 Gründen für genau definierte Benutzer Mehrfachanmeldun-
gen notwendig sein, können 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 für die Überwachung und Protokollierung von Tabellen-
änderungen (s. a. Kapitel 8.1.1 ff): rec/client
RECCLIENT
Die folgenden Einstellungen werden empfohlen:
Berechtigungsprüfung für ABAP/4-Sprachbefehle Der Systemprofilparameter AUTH/SYSTEM_ACCESS_CHECK_OFF ermöglicht es, Berechtigungs-
prüfungen für bestimmte ABAP-Sprachbefehle, z. B. den Aufruf von Kernel-Funtionen oder CPI-C-
Aufrufe zu deaktivieren.
Der empfohlene Parameterwert ist „0“ (die Berechtigungsprüfung für bestimmte ABAP-Sprachbefehle
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 23 von 67
ist aktiv).
Für alle in dieser Richtlinie genannten (Systemprofil-)Parameter müssen die notwendigen Einstellun-
gen definiert und dokumentiert werden. Vom Anwendungseigner müssen Prozesse für Änderungen
an diesen Einstellungen konzipiert und umgesetzt werden. Der Anwendungseigner überwacht regel-
mäßig die in dieser Richtlinie beschriebenen Systemprofilparameter und deren Werte. Werden Abwei-
chungen in den vorgeschriebenen Einstellungen entdeckt, müssen die notwendigen Werte wieder
hergestellt und die Ursachen hierfür bestimmt werden. Darauf aufbauend müssen Maßnahmen einge-
leitet werden, die eine nochmalige, unautorisierte Änderung dieser Einstellungen verhindern. Alle Do-
kumente, die während der Überwachung der Einstellungen erzeugt werden, müssen 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 müssen im Rahmen technischer und organisatori-
scher Maßnahmen vor einem unautorisierten Zugriff geschützt werden.
Der Anwendungseigner ist verpflichtet, ein Konzept für den Schutz vor unautorisierten Zugriffen auf
diese SAP-Standardbenutzer zu erstellen. Die Umsetzung der unten genannten Anforderungen wird
ausdrücklich empfohlen, wobei Abweichungen in Qualitätssicherungs- und Entwicklungssystemen
möglich sind.
Die weiter unten angeführten Einstellungen müssen vom Anwendungseigner regelmäßig überprüft
werden. Abweichungen von diesen Einstellungen müssen untersucht und für die Wiederherstellung
der Einstellungen entsprechende Maßnahmen eingeleitet werden. Eine Übersicht dieser Einstellun-
gen und – soweit verfügbar – der eingeleiteten Maßnahmen muss vom Anwendungseigner dokumen-
tiert werden.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 24 von 67
5.1.6.1 SAP*
Zum Schutz des SAP-Standardbenutzers SAP* müssen die folgenden Maßnahmen ergriffen werden:
Für den Benutzer SAP* muss ein Benutzerstammsatz angelegt werden.
Für den Benutzer SAP* dürfen keine Rollen/Profile vergeben werden.
Für 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.
Darüber hinaus muss die automatische Anlage nach der Löschung 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 für einen geregelten, autorisierten Einsatz
des Benutzers SAP* (z. B. bei der Installation von Support Packages) eingeführt werden, welche ins-
besondere die folgenden Punkte berücksichtigen:
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 Aktivitäten 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
für Dialoganmeldungen genutzt werden. Er wird von einigen Programmen und Funktionsbausteinen
für die Systemkommunikation verwendet.
Um diesen Benutzer zu schützen, wird das bekannte Standardkennwort dieses Benutzers geändert.
Sollte die Benutzerkennung gesperrt werden, muss vor dieser Umsetzung die aktuelle Version des
SAP Hinweises #29276 auf eventuelle Einschränkungen bzw. Auswirkungen hin geprüft werden.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 25 von 67
5.1.6.3 DDIC
Der SAP-Standardbenutzer DDIC wird für weite Bereiche des ABAP Dictionary und des TMS benötigt.
Aus diesem Grund benötigt dieser Benutzer umfangreiche Systemrechte, die über die in den Benut-
zerprofilen hinterlegten Rechte hinausgehen. Die Verwendung der SAP-Standardprofile SAP_ALL und
SAP_NEW für diesen Benutzer wird ausdrücklich empfohlen.
Um diese Benutzerkennung zu schützen, muss ein nicht-triviales Kennwort vergeben und einem hier-
für berechtigten Personenkreis übermittelt werden. Die Benutzerkennung muss einer administrativen
Benutzergruppe zugeordnet und vom Anwendungseigner ein Konzept für die Verwendung dieser
Benutzerkennung entworfen, implementiert und regelmäßig überwacht werden.
Die Verwendung der Benutzerkennung DDIC sollte sowohl systemseitig protokolliert als auch über
organisatorische Maßnahmen geregelt werden. Die Benutzerkennung DDIC darf nicht für Notfallbe-
nutzereinsätze verwendet werden (s. a. Kapitel 5.4).
5.1.6.4 Early Watch
Der Benutzer EARLYWATCH ist ein Dialogbenutzer, der von SAP für den Early Watch Service im
Rahmen der Performance-Überwachung genutzt wird.
Um diese Benutzerkennung vor einem unautorisierten Zugriff zu schützen, muss deren bekanntes
Standardkennwort geändert werden. Der Benutzer ist zu sperren und nur auf Anforderung für 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 für das automatische Workflow-Customizing benötigt.
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 für die
übrigen Standardbenutzer.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 26 von 67
5.2 Benutzerverwaltung
5.2.1 Organisatorische Anforderungen
Zur Gewährleistung einer Funktionstrennung und der Anforderungen der internen/externen Revision
muss der Geschäftprozessinhaber/Anwendungsbetreuer ein Konzept für die Benutzerverwaltung
erstellen, welches mindestens die folgenden Punkte beinhaltet:
Benutzer dürfen sich nicht selbst verwalten.
Die Verantwortlichkeiten für die Benutzeradministration müssen transparent sein.
Die Nachvollziehbarkeit der Benutzeradministration muss sichergestellt werden.
Besondere Maßnahmen müssen für die Verwaltung spezieller Benutzer (DDIC, SAP* oder Notfallbe-
nutzer) und der Benutzeradministratoren selbst ergriffen werden. Der Geschäftprozessinha-
ber/Anwendungsbetreuer muss unter Berücksichtigung organisatorischer Strukturen und operativer
Anforderungen ein Konzept für die Verwaltung aller SAP-Anwender erstellen, welches die oben ge-
nannten Anforderungen erfüllt. Dabei hat der Geschäftprozessinhaber/Anwendungsbetreuer einen
begrenzten Personenkreis zu bestimmen, dem die Verwaltung von Benutzern erlaubt ist.
5.2.2 SAP-Benutzergruppen
Über Benutzergruppen kann kontrolliert werden, für welche Benutzerstammsätze ein Administrator
verantwortlich ist. Benutzerkennungen, denen keine Benutzergruppe zugeordnet ist, können von allen
Administratoren verwaltet werden. Aus diesem Grund muss jedem Benutzer eine Benutzergruppe
zugeordnet werden. Der Anwendungseigner ist verantwortlich für die Erstellung eines Konzepts für
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-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
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, abhängig von organisatori-
schen oder operativen Anforderungen, erlaubt. In einem solchen Fall können Benutzergruppen für 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 Maßnahmen, die den Zugang zur Systemlandschaft betreffen, wird
nachdrücklich empfohlen.
5.2.4 Entwicklungssysteme
Der Zugang zu Entwicklungssystemen muss auf die folgenden Personenkreise eingeschränkt sein:
IT (Entwickler, Benutzer mit Customizing-Rechten etc.)
Projekt-Teams
Key-User
Endanwender dürfen keinen Zugang zum Entwicklungssystem erhalten.
Für Entwicklungssysteme müssen vom Anwendungseigner Zugangsregeln erstellt werden, in denen
die Risiken, Regeln und Verantwortlichkeiten möglicher Zugänge klar definiert sind.
Diese Regeln müssen vom Anforderer, bevor ihm Zugang zum System und/oder Zugriffsrechte über
SAP-Rollen gewährt werden, durch einen Antrag gegengezeichnet werden. Der Anwendungseigner
muss diese unterschriebenen Regeln so archivieren, dass alle lokalen Anforderungen erfüllt werden.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 28 von 67
5.2.4.1 Qualitätssicherungssysteme ( → s. Anhang HR)
Der Zugang zu Q/A-Systemen (Qualitätssicherungssystemen) muss auf die folgenden Personenkrei-
se eingeschränkt sein:
IT (Entwickler, Benutzer mit Customizing-Rechten etc.)
Support-Benutzer (Fernwartung)
Projekt-Teams
Key-User
Key-User und Anwendungsbetreuer dürfen das Q/A-System zu Testzwecken verwenden. Für diese
Key-User und Anwendungsbetreuer finden dieselben organisatorischen Einschränkungen wie in ei-
nem produktiven System Anwendung.
Endanwender sollten grundsätzlich keinen Zugang zum Q/A-System, außer zu Testzwecken, erhal-
ten.
5.2.4.2 Produktivsysteme ( → s. Anhang HR)
Grundsätzlich ist der Zugang zu einem Produktivsystem nicht auf einen bestimmten Personenkreis
eingeschränkt. Es müssen jedoch funktionale und organisatorische Einschränkungen 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 dürfen in einem Produktivsystem nicht die folgenden Rechte besitzen:
Programmierung,
Änderung von Feldinhalten während des Programmablaufs,
Transportberechtigungen.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 29 von 67
5.2.5 Durchführung der Benutzerverwaltung
Der Geschäftprozessinhaber/Anwendungsbetreuer ist verpflichtet, für alle Phasen der Benutzerver-
waltung entsprechende Prozesse zu definieren.
Zu diesem Zweck muss vom Anwendungseigner, Geschäftprozessinhaber und Anwendungsbetreuer
ein angemessenes Berechtigungskonzept erstellt werden. Der Anwendungsbetreuer des Benutzers
muss sicherstellen, dass nach dem „Prinzip der minimalen Berechtigung“ dieser nur diejenigen
Zugriffsrechte erhält, die er für die Ausübung seiner Tätigkeiten/Funktion benötigt.
Für Hintergrund- und Schnittstellenbenutzer (Systembenutzer) können Prozesse, die sich von denen
im Folgenden unterscheiden, angewendet werden. Der Anwendungseigner muss für diese Benutzer-
kennung passende Prozesse erstellen, welche die Anforderungen an Dokumentation, Nachvollzieh-
barkeit und Autorisierung erfüllen.
5.2.5.1 Dokumentation der Benutzerverwaltung
Der Anwendungsbetreuer ist zur Einführung und Dokumentation von Prozessen aller Stufen des Be-
nutzer-Lebenszyklus (Anlage, Änderung oder Löschung einer Benutzerkennung) verpflichtet. Durch
diese Prozesse muss gewährleistet werden, dass jeder Benutzerantrag, genauso wie alle Genehmi-
gungen, entsprechend dokumentiert und archiviert werden.
Diese Prozesse müssen Anforderungen unterschiedlicher Systemtypen innerhalb einer SAP-
Systemlandschaft (Entwicklungs-, Q/A- und Produktivsystem) und unterschiedlicher Benutzertypen
(z. B. Dialogbenutzer, Hintergrundbenutzer) berücksichtigen.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 30 von 67
5.2.5.2 Anlage von Benutzerkennungen
Während der Anlage einer Benutzerkennung müssen die folgenden Angaben gemacht werden:
Eine der Namenskonvention entsprechende Benutzerkennung (s. a. Kapitel 5.1.1.2)
Eine Benutzergruppe entsprechend dem Konzept für Benutzergruppen (s. a. Kapitel 5.2 und
Namenskonvention der Georg-August-Universität für SAP)
Lizenzdaten entsprechend den Lizenzvereinbarungen
Berechtigungen (SAP-Rollen), die vom Benutzer entsprechend seiner definierten Funktionen
benötigt werden
Stammdaten des Benutzers
Da der Prozess der Benutzeranlage stark mit der Anforderung von Berechtigungen zusammenhängt,
wird für weitere Vorgaben auf das Kapitel 5.2.5.3 verwiesen.
5.2.5.3 Zuweisung von Rollen zu Dialog-Benutzern
Der Anwendungsbetreuer ist verantwortlich dafür, Dokumentationen und Kontrollprozesse und/oder
Tools für die Zuweisung von Rollen an Dialogbenutzer zur Verfügung zu stellen. Es müssen formale
und gut dokumentierte, IS-basierte Prozesse für die Rollenzuweisung entsprechend der Stellenbe-
schreibung des Benutzers eingeführt werden.
Alle Rollenanträge für Dialogbenutzer müssen vom entsprechenden Anwendungsbetreuer gestellt
werden, da nur dieser die SAP-Rollen kennt, die ein Endanwender zur Durchführung seiner Aufga-
ben/Funktionen benötigt.
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
Durchführung der Aufgaben/Funktionen eines Benutzers unbedingt notwendig sind. Der Vorgesetzte
des Benutzers muss in regelmäßigen Abständen die bekannte Verletzung der Funktionstrennung
überprüfen und entscheiden, ob diese für die Funktionen/Aufgaben des Benutzers nach wie vor not-
wendig ist.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 31 von 67
Der Vorgesetzte des Benutzers ist verantwortlich für die Überprüfung 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 für die Kontrol-
le und Genehmigung der dokumentierten Zutrittsanforderungen des Benutzers zuständig ist,
geprüft und genehmigt werden.
Die zweite Genehmigung muss vom Geschäftsprozessinhaber der angeforderten Rolle(n)
durchgeführt werden. Für den Fall, dass Buchungskreis-übergreifende Zugriffe angefordert
werden, muss die Abteilungsleitung/Geschäftsbereichsleitung informiert werden.
Der Geschäftprozessinhaber ist für 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 für 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)
Für nicht Dialogbenutzer ist ein Verantwortlicher festzulegen. Weitere Einzelheiten s. Kapitel 5.2.5.3.
5.2.5.5 Zugang externer Mitarbeiter/Dienstleister
Alle Anträge von Mitarbeitern für den externen Zugang zu einer SAP-Anwendung müssen von folgen-
den Instanzen genehmigt werden:
Systembetreiber
Geschäftsprozessinhaber
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 32 von 67
Hierzu ist bei neu einzurichtenden Zugängen ein schriftlicher Antrag erforderlich. Weiterhin gelten
folgende Regelungen:
Bei Beratern in laufenden Projekten wird der Zugang (bei bereits bestehender Genehmigung)
dokumentiert.
Der Zugang für den SAP-Support ist grundsätzlich gesperrt. Die Entsperrung ist durch den
Veranlasser zu dokumentieren.
Zugriffe auf das Konsolidierungs- und Produktivsystem sind nur in dokumentierten Ausnah-
mefällen zeitlich befristet zulässig. 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 durchgeführt, wenn
ein vom hierfür zuständigen Anwendungsbetreuer initiierter Antrag auf Basis geänderter HR-
Daten vorliegt.
Eine Sperrung kann aufgrund von Falschanmeldungen vorkommen. Dies hängt 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 ausdrücklich 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-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 33 von 67
Die Sperrung der Benutzerkennungen erfolgt durch den Key-User oder durch den Anwendungsbe-
treuer (Verfahrensebene). Bei Unregelmäßigkeiten kann die Sperrung auch vom Anwendungseig-
ner/Anwendungsbetreuer (Technikebene) vorgenommen werden.
Um den Betrieb des Systems nicht zu gefährden, gelten diese Regeln nicht für die folgenden
Benutzer oder Benutzergruppen:
- Benutzer für die Schnittstellenkommunikation,
- Benutzer für Hintergrundprozesse (Jobnetz).
Für (System-)Administratoren muss ein entsprechend angepasster Prozess eingeführt und
angewendet werden.
Sofern das letzte Anmeldedatum mindestens 90 Tage zurück liegt, muss die betroffene Sach-
gebiets- bzw. Abteilungsleitung informiert werden, die darüber 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 Möglichkeiten, warum eine Benutzerkennung in einem SAP-System gesperrt sein kann:
Sperrung aufgrund ungültiger 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 ungültiger Anmeldeversuche gesperrt wurde, muss der Anwen-
der den Key-User/Benutzerverwalter für eine Entsperrung seiner Kennung bzw. für die Erstellung
eines neuen Initialkennworts kontakten. Der Key-User/Benutzerverwalter überprüft die Identität des
Benutzers und der Benutzerkennung, basierend auf den Prozessen, die vom Anwendungseigner hier-
für eingeführt wurden.
Sofern der Anforderer als der Besitzer der Benutzerkennung identifiziert wurde, wird die Sperre auf-
grund ungültiger 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-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 34 von 67
In dieser E-Mail wird der Benutzer aufgefordert, das Initialkennwort umgehend zu ändern und über
mögliche Folgen einer verzögerten Änderung informiert1. Falls ein E-Mail Versand des Initialkennwor-
tes nicht möglich ist, wird dem Benutzer das Initialkennwort persönlich ausgehändigt.
5.2.5.8 Löschung von Benutzerkennungen
Für die Löschung von Benutzerkennungen, die nicht länger benötigt werden, muss vom Anwen-
dungsbetreuer ein entsprechender Prozess eingeführt werden. Bevor eine Benutzerkennung aus ei-
nem SAP-System physikalisch gelöscht wird, muss sicher gestellt werden, dass
- eine Historie der Benutzerkennungen und der dazugehörigen Benutzer/Personen, welche alle
lokalen Anforderungen erfüllt, einen angemessenen Zeitraum zur Verfügung steht.
- die Nachvollziehbarkeit der Business-Transaktionen (wer hat was angelegt, geändert etc.),
zumindest über einen bestimmten Zeitraum (in der Regel 10 Jahre), gewährleistet ist.
Diese Maßnahmen stellen die Transparenz, Nachvollziehbarkeit der eingesetzten Verfahren und Ein-
haltung von Prüfungsanforderungen sicher.
5.2.5.9 Aktualität von Benutzerstammdaten
Der Geschäftsprozessinhaber muss Prozesse einführen, um die Aktualität von Benutzerstammdaten
zu gewährleisten. Diese Prozesse müssen insbesondere die Änderungen von Funktionen oder Orga-
nisationsebenen des Benutzers abdecken, da dieses im Allgemeinen zu Änderungen der Berechti-
gungen des Benutzers führt.
Obwohl hierfür Tools zur automatisierten Aktualisierung verwendet werden können, ist es die Aufgabe
des Anwendungsbetreuers, zu dessen Organisationseinheit der Benutzer gehört, dafür 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 für das SAP-System gültigen Kennwortregeln. Bei einer verzögerten Änderung des Initialkennwortes sind Sie für alle Aktionen verantwortlich, die unter die-sem Kennwort durchgeführt wurden.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
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 prüfen, ob die bislang vergebenen Be-
rechtigungen noch benötigt und/oder innerhalb eines bestimmten Zeitraums entzogen/eingeschränkt
werden müssen.
Die Aktualität von Benutzerstammdaten wird durch folgendes Verfahren überprüft:
Die Fachabteilungen haben eine jährliche Prüfung zu gewährleisten. Hierzu haben die Kostenstellen-
verantwortlichen die Angaben zu den Benutzerstammdaten zu bestätigen oder zu ändern und dies
durch Unterschrift zu bestätigen.
5.2.5.10 Rücksetzung von Kennwörtern
Sofern ein Benutzer ein neues Kennwort für seine Benutzerkennung benötigt, findet der Prozess für
die Entsperrung eines Benutzers Anwendung (s. a. Kapitel 5.2.5.7).
5.2.5.11 Technische Benutzerkennungen
Technische Benutzerkennungen (z. B. Benutzerkennungen für die Hintergrundverarbeitung, Schnitt-
stellen etc.) müssen eindeutig von den Benutzerkennungen für Dialogbenutzer, genauso wie von an-
deren Benutzertypen, unterschieden werden können. Dies muss durch
eine entsprechende Namenskonvention,
Benutzergruppen und
Rollen
gewährleistet sein.
Für jede Benutzerkennung muss ein Verantwortlicher definiert werden, auch wenn die betroffene Be-
nutzerkennung nicht für eine interaktive Anmeldung verwendet wird.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 36 von 67
5.3 Berechtigungsverwaltung
Vom Anwendungseigner, Geschäftprozessinhaber und Anwendungsbetreuer müssen gemeinsam für
alle Phasen der Berechtigungsverwaltung Prozesse definiert werden.
5.3.1 Verwendung von Rollen und Profilen
Um Geschäftsdaten und -funktionen vor unberechtigten Zugriffen zu schützen, werden SAP-
Transaktionen und Programme durch Berechtigungsprüfungen geschützt. Um eine Berechtigungsprü-
fung erfolgreich zu durchlaufen, benötigt 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 ausdrücklich empfohlen. Rollen und Profile, die von SAP ausgeliefert
werden, dürfen nur in gut dokumentierten Ausnahmefällen und mit Zustimmung des Anwendungseig-
ners vergeben werden. Es wird ausdrücklich empfohlen, für den Zugriff auf SAP-Systeme kundenei-
gene Rollen für den Zugriff auf allgemeine Funktionen/Aktivitäten zu erstellen. Die gleichzeitige Ver-
wendung kundeneigener Rollen und Profile verringert die Übersichtlichkeit und sollte deshalb vermie-
den werden.
5.3.2 Organisatorische Einschränkungen von Rollen
Damit kontrolliert und überwacht werden kann, welche Benutzer die Möglichkeit für einen Zugriff auf
ihre Daten innerhalb ihrer Organisationseinheit haben, müssen Rollen auf diese einzelnen Bereiche
beschränkt sein. Eine Unterteilung in Organisationsebenen muss im Einzelfall vom Geschäftprozess-
inhaber und den betroffenen Bereichen der Universität definiert, umgesetzt und kontrolliert werden.
Die Akkumulation von Rollen innerhalb von Benutzerstammsätzen über verschiedene Geschäftsbe-
reiche/Abteilungen hinweg ist prinzipiell möglich, wobei in einem solchen Fall die Genehmigung aller
betroffenen Organisationseinheiten notwendig ist.
Sofern Rollen Berechtigungen beinhalten, die für mehrere Bereiche der Universität notwendig sind
(z. B. für den Systemsupport), können diese nur mit Zustimmung des Anwendungseigners und den
betroffenen Bereichen erstellt und vergeben werden.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 37 von 67
5.3.3 Rollenverwaltung – Grundlegende Prinzipien ( → s. Anhang HR)
Es wird ausdrücklich empfohlen, dass die Anlage und Änderung von Rollen nur im Entwicklungssys-
tem durchgeführt wird. Die Rollen müssen innerhalb des Q/A-Systems durch den Key-
User/Anwendungsbetreuer, unter Berücksichtigung unterschiedlicher Geschäftsvorfälle, getestet wer-
den. Hierbei sind sowohl Positivtests (=Funktionserfüllung) 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 Notfällen ist die Anlage oder Änderung einer Rolle durch die Berechtigungsadministration im Pro-
duktivsystem zulässig, sofern der Anwendungseigner zugestimmt hat. Alle Änderungen werden da-
nach per Down- und Upload in das Entwicklungssystem verbracht und anschließend ü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 müssen beschrieben und dokumentiert werden. Innerhalb einer Beschreibung müssen alle
durch die jeweilige Rolle zugänglichen Menüpunkte und Transaktionen definiert werden. Ebenso müs-
sen mögliche Einschränkungen dargestellt werden. Für jede Rolle muss ein Verantwortlicher definiert
werden, der für den Inhalt (Transaktionen, Berechtigungsobjekte, organisatorische Einschränkungen)
und die Zuweisung der Rolle verantwortlich ist.
Für alle Rollenänderungen müssen ausreichende Dokumentationen angelegt werden.
Innerhalb einer Einzelrolle dürfen keine Probleme bezüglich einer Funktionstrennung auftreten.
Eine Rolle darf grundsätzlich 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 enthält, wird automatisch als kritisch/sensitiv angesehen.
Der Geschäftsprozessinhaber muss kritische/sensitive Berechtigungen und die Zuordnung der Rollen
in regelmäßigen Abständen überprüfen und entscheiden, ob diese immer noch benötigt werden. Ein
Bericht über diese Untersuchungen ist an den Anwendungseigner zur Archivierung zu senden.
Einzelheiten, welche die Rollenverwaltung und den Rolleninhalt betreffen, müssen vom Geschäftspro-
zessinhaber in einem spezifischen Konzept definiert werden.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 38 von 67
Spezielle Zugriffsrechte müssen auf den Personenkreis beschränkt sein, welcher für das System, das
Netzwerk oder das Anwendungsmanagement und/oder die Sicherheit zuständig ist.
5.3.4 Anlage neuer Rollen
Bevor eine neue Rolle angelegt wird, muss geprüft werden, ob die notwendigen Funktionalitäten nicht
durch bereits vorhandene Rollen zur Verfügung gestellt werden können.
Anträge für die Neuanlage einer Rolle müssen mindestens einem “4-Augen-Prinzip” folgen. Der erste
Genehmiger ist der Anwendungsbetreuer der Fachabteilung. Der zweite Genehmiger ist der Ge-
schäftsprozessinhaber. Sofern die Änderung einer Rolle mindestens eine weitere Rolle betrifft (z. B.
bei Ableitungen), müssen die Geschäftsprozessinhaber aller betroffenen Rollen über diese Änderung
informiert werden.
Vor der Neuanlage einer Rolle muss der verantwortliche Anwendungsbetreuer oder das Projektteam
zuerst den Antrag prüfen, um anschließend die eigentliche Rollenerstellung anzustoßen. Der Initiator
muss eine Funktionstrennung (Segregation of Duty - SoD) und kritische/sensitive Berechtigungen
berücksichtigen.
Müssen kritische/sensitive Berechtigungen vergeben werden, entscheidet der Anwendungsbetreuer
gemeinsam mit dem Geschäftsprozessinhaber, ob diese kritischen/sensitiven Berechtigungen in der
Rolle benötigt werden.
Der Anwendungsbetreuer muss die Anforderung genehmigen und bestätigen, dass er/sie sich enthal-
tener kritischer/sensitiver Transaktionen bewusst ist. Die Anforderung für die Aufnahme kritischer oder
sensitiver Berechtigungen in eine Rolle muss vom Anwendungseigner explizit genehmigt werden.
5.3.5 Änderung bestehender Rollen
Anträge für die Änderung einer Rolle müssen mindestens einem “4-Augen-Prinzip” folgen. Der erste
Genehmiger ist der Anwendungsbetreuer der Fachabteilung. Der zweite Genehmiger ist der Ge-
schäftsprozessinhaber. Sofern die Änderung einer Rolle mindestens eine weitere Rolle betrifft (z. B.
bei Ableitungen), müssen die Geschäftsprozessinhaber aller betroffenen Rollen über diese Änderung
informiert werden.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 39 von 67
Sofern die Änderung einer Rolle aufgrund bestimmter Geschäftsanforderungen notwendig ist, muss
der verantwortliche Anwendungsbetreuer oder das Projektteam den Rollenänderungsprozess ansto-
ßen. Hierbei müssen Funktionstrennung (SoD) und kritische/sensitive Berechtigungen berücksichtigt
werden.
Müssen kritische/sensitive Berechtigungen vergeben werden, entscheidet der Anwendungsbetreuer
gemeinsam mit dem Anwendungseigner, ob diese kritischen/sensitiven Berechtigungen in der betrof-
fenen Rolle benötigt werden.
Der Anwendungsbetreuer muss die Anforderung genehmigen und bestätigen, dass er sich enthalte-
ner kritischer/sensitiver Transaktionen bewusst ist. Die Anforderung für die Aufnahme kritischer oder
sensitiver Berechtigungen in eine Rolle muss vom Anwendungseigner explizit genehmigt werden.
5.3.6 Löschung von Rollen
Für die Löschung von Rollen, die nicht länger benötigt werden, muss vom Geschäftprozessinhaber
ein Prozess definiert werden. Bevor eine Rolle physisch aus einem SAP-System gelöscht werden
kann, muss sichergestellt werden, dass die Nachvollziehbarkeit ihres Inhalts und die Zuordnung zu
Benutzerkennungen über einen Zeitraum, der allen Anforderungen einer Revision erfüllt, gegeben ist.
Es wird empfohlen, von zu löschenden Rollen mit den entsprechenden SAP-Funktionen einen Down-
load zu erstellen. Die Aufbewahrungsfrist beträgt 10 Jahre.
Rollen müssen im Entwicklungssystem gelöscht und die Löschung auf dem üblichen Weg, der im
Change Management Prozess definiert wird, transportiert werden. Diese Maßnahme stellt die Trans-
parenz, Nachvollziehbarkeit und Einhaltung von Prüfungsanforderungen 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 für Einzelrollen
Anwendung.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 40 von 67
5.3.8 Berechtigungen für Projekte und Business Requests
Sobald ein Projekt definiert und genehmigt wurde, muss durch den Projektleiter das Projektteam fest-
gelegt und dokumentiert werden sowie die für dieses Projektteam notwendigen Berechtigungen defi-
niert werden. Für diese Berechtigungen finden alle weiter oben gemachten Regeln und Prozesse (z.
B. kritische Transaktionen, SoD) Anwendung. Für den Zugriff eines Mitglieds des Projektteams auf
das Entwicklungssystem ist die Genehmigung des betroffenen Anwendungseigners notwendig.
Projektberechtigungen dürfen nur an die bekannten Mitglieder des Projektteams und nur für die Dauer
des Projekts selbst vergeben werden. Projektrollen dürfen nicht innerhalb eines Produktivsystems
verwendet werden.
Für tägliche Arbeiten, die innerhalb des Produktivsystems notwendig sind, müssen während des Pro-
jekts entsprechende Berechtigungen definiert werden.
5.4 Einsatz von Notfallbenutzern
Für Notfälle können eine begrenzte Anzahl spezieller Benutzerkennungen mit umfassenden Basis-
oder Funktionsberechtigungen zur Verfügung gestellt werden:
Definition eines Notfalls:
Betrifft nicht den täglichen Betrieb,
Kommt nicht periodisch vor,
Betrifft kritische Systemkomponenten.
Alle Anforderungen für die Verwendung einer Notfallbenutzerkennung müssen dokumentiert werden.
Diese Dokumentation muss den Grund für den Notfalleinsatz und die notwendigen Aktivitäten, die im
SAP-System durchgeführt werden sollen, enthalten.
Die Aktivitäten von Notfallbenutzern müssen systemseitig protokolliert werden.
Der Anwendungseigner muss regelmäßig die Effektivität dieses Prozesses überwachen.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 41 von 67
5.5 Funktionstrennung
Vom Geschäftprozessinhaber/Anwendungsbetreuer muss eine Liste von Berechtigungen/Trans-
aktionen, die inkompatible Aufgaben und/oder Verantwortlichkeiten repräsentieren und nicht in einer
Rolle oder einem Benutzerstammsatz gemeinsam vorkommen dürfen, definiert werden. Für die Erstel-
lung einer solchen Liste inkompatibler Funktionen und Berechtigungen werden Anforderungen aus
den Geschäftsprozessen und anderen Quellen berücksichtigt.
Der Geschäftsprozessinhaber hat mit den entsprechenden SAP-Reports zu prüfen, ob an die Benut-
zer kritische Berechtigungen/Berechtigungskonstellationen vergeben wurden.
Die Funktionstrennung unterstützt dabei die Transparenz von Geschäftsprozessen zur Vermeidung
von Unregelmäßigkeiten, Betrug und anderer strafbarer Tatbestände.
Aus diesem Grund muss bei jeder Rollenänderung oder bei der Zuweisung von Rollen zu Benutzer-
kennungen die Einhaltung der Funktionstrennung geprüft werden. Für 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 Geschäftsprozessinhaber muss regelmäßig innerhalb seiner Anwendung prüfen, ob bislang un-
dokumentierte Probleme in Verbindung mit der Funktionstrennung vorhanden sind.
5.6 Kritische/Sensitive Berechtigungen
Neben dem Problemkreis der Funktionstrennung können auch einzelne Transaktionen oder Berechti-
gungen, genauso wie Transaktionskombinationen, als kritisch oder sensitive betrachtet werden. Eine
Liste kritischer/sensitiver Berechtigungen muss vom Geschäftsprozessinhaber definiert werden.
Hierbei wird unterschieden nach:
Kritische Berechtigungen sind nur innerhalb der Rollen für die Administration oder für Notfälle
erlaubt.
Sensitive Berechtigungen sind in Rollen für spezielle Zwecke erlaubt.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 42 von 67
Für jede dieser Kategorien müssen angemessene Verpflichtungserklärungen vom Geschäftsprozess-
inhaber eingeführt werden.
Eine Rolle, die kritische/sensitive Berechtigungen enthält, wird automatisch als kritisch/sensitive be-
trachtet.
Sofern Berechtigungen, die in diesen Kategorien aufgeführt sind, in Rollen eingetragen werden sollen,
müssen vom Geschäftsprozessinhaber angemessene Maßnahmen für ein Risiko-Management einge-
führt werden.
6. Schnittstellen
Es gibt eine Vielzahl von Schnittstellen für die Kommunikation mit SAP-Systemen. Vom Anwendungs-
eigner müssen Prozesse für die Implementierung und Verwaltung solcher Schnittstellen erstellt wer-
den. Diese Prozesse müssen sicherstellen, dass
für jede Schnittstelle eine Dokumentation vorhanden ist und weitergeführt wird,
für 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 für diese Schnittstelle verwendet werden.
6.1 Remote Communications (RFC & CPIC)
Für die Kommunikation zwischen SAP- und externen Systemen oder Funktionsbausteinen werden der
Remote Function Call (RFC) und die CPIC-Schnittstelle verwendet. RFC ermöglicht 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 verfügen, welche sie für die Ausführung der Schnittstellen-Programme
benötigen. Daraus folgt, dass CPIC-Benutzern ausschließlich funktionsbezogene Rollen/Profile zuge-
ordnet werden, auch wenn dieser Benutzer nicht für eine Dialoganmeldung verwendet werden kann.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 43 von 67
Zusätzlich müssen für die RFC- und CPIC-Kommunikation mit einem SAP-System die folgenden
Maßnahmen vorgenommen werden:
Die Berechtigungen zur Verwaltung von RFC-Verbindungen müssen eingeschränkt werden.
Nur die hierfür zuständigen Administratoren dürfen über entsprechende Berechtigungen ver-
fügen.
Es dürfen nur Informationen über Systembenutzer, nicht über Dialogbenutzer, gespeichert
werden. RFC-Verbindungen werden im SAP-System mit den Standard-Kennwort-
mechanismen geprüft. Aus diesem Grund muss sich ein Benutzer, welcher eine RFC-
Verbindung aufbauen möchte, am entfernten System mit einer gültigen Benutzerkennung und
einem Kennwort anmelden. Entweder werden diese Informationen mit der RFC-Verbindung
gepflegt (für Systembenutzer) oder der Benutzer wird bei der Anmeldung zur Eingabe seiner
Benutzerkennung und seines Kennworts aufgefordert. Für Dialogbenutzer dürfen keinerlei In-
formationen in den RFC-Verbindungen gespeichert werden. Benutzer mit gespeicherten An-
meldedaten dürfen im Zielsystem nur über die zur Ausführung ihrer Tätigkeiten notwendigen,
minimalen Berechtigungen verfügen.
Der Zugang zur Tabelle RFCDES muss eingeschränkt sein, da die für eine RFC-Verbindung
notwendigen Informationen, einschließlich der Benutzerkennung und des Kennworts, in dieser
Tabelle hinterlegt werden.
Alle für die Remote-Kommunikation verwendeten Benutzerkennungen müssen vom Benutzertyp
„Kommunikation“ sein und einer speziellen Benutzergruppe zugewiesen werden.
Für Schnittstellen-Benutzer sind grundsätzlich spezielle, funktionsbezogene Rollen zu erstellen, die
insbesondere nicht an Dialogbenutzer vergeben werden dürfen. Sofern technisch und organisatorisch
möglich, dürfen diese Rollen nur diejenigen Berechtigungen enthalten, welche für die Ausführung aller
notwendigen Aktivitäten der Schnittstelle benötigt werden.
In bestimmten Fällen kann es notwendig sein, dass diesen Benutzern umfangreichere Rechte zur
Verfügung gestellt werden müssen. In einem solchen Fall muss der Anwendungseigner die Verwen-
dung solcher umfangreicherer Rollen genehmigen.
Bezüglich des SAP Standardbenutzers SAPCPIC wird auf das Kapitel 5.1.6.2 verwiesen.
Vom Anwendungseigner muss ein Konzept für die Zuordnung von Berechtigungen für die Definition
und die Ausführung von Schnittstellen erstellt werden.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 44 von 67
6.2 Hintergrundverarbeitung
Hintergrundprozesse werden für 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 während einer geringen
Systemlast ausgeführt und die Aufgabe des Anstartens von Reports oder Programmen an das Sys-
tem delegiert werden sollen.
Benutzerkennungen, die für die Hintergrundverarbeitung verwendet werden, müssen als Systembe-
nutzer (nicht Dialogbenutzer!) definiert werden und verfügen nur über die für die Ausführung von Pro-
grammen notwendigen Berechtigungen.
Für Schnittstellen-Benutzer sind grundsätzliche spezielle, funktionsbezogene Rollen zu erstellen, die
insbesondere nicht an Dialogbenutzer vergeben werden dürfen. Sofern technisch und organisatorisch
möglich, dürfen diese Rollen nur diejenigen Berechtigungen enthalten, welche für die Ausführung aller
notwendigen Jobsteps benötigt werden.
In bestimmten Fällen kann es notwendig sein, dass diesen Benutzern umfangreichere Rechte zur
Verfügung gestellt werden müssen. In einem solchen Fall muss der Anwendungseigner die Verwen-
dung solcher umfangreicherer Rollen genehmigen.
Vom Anwendungseigner muss ein Konzept für die Zuordnung von Berechtigungen für die Jobdefiniti-
on und die Jobausführung erstellt werden.
6.3 Batch / Fast / Direct Input
Batch-Input und Fast-Input sind Standardtechniken für die Übertragung großer 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 für die Datenintegrität
implementierten Prüfungen durchgeführt.
Da durch Batch-Inputs Daten von einem externen System in ein SAP-System importiert werden, müs-
sen alle notwendigen Maßnahmen ergriffen werden, um das SAP-System vor unberechtigten Ände-
rungen zu schützen.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 45 von 67
Wird ein Batch-Input im Rahmen der Hintergrundverarbeitung ausgeführt, wird für 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 für einen Batch-Input verwendet werden, müssen vor einem unberechtigten
Zugriff geschützt werden.
Es wird ausdrücklich empfohlen, Batch-Input Benutzer vom Typ „System“ zu definieren. Diese Benut-
zerkennungen dürfen nur über diejenigen Berechtigungen verfügen, die für die Verarbeitung der ent-
sprechenden Sitzung notwendig sind. Sollte dies aus technischen Gründen, z. B. aufgrund der Ver-
wendung von SAP-Standardprogrammen zur Erzeugung von Batch-Input-Mappen, nicht möglich sein,
müssen diese Fälle entsprechend dokumentiert werden.
Vom Anwendungseigner muss ein Konzept für die Zuordnung von Berechtigungen für die Definition
und die Ausführung von Batch-Inputs erstellt werden.
6.4 BAPI
Business Application Programming Interfaces (BAPIs) sind standardisierte Programmschnittstellen,
die einen externen Zugriff auf SAP-Geschäftsprozesse und -Daten ermöglichen. BAPIs werden im
Business Object Repository (BOR) als Methoden von SAP-Business-Objekten oder als SAP-Interface-
Typen definiert. BABIs sind letztlich als RFC-fähige Funktionsbausteine innerhalb des Function Buil-
der der ABAP Workbench implementiert und gespeichert.
Wenn BAPIs als Schnittstellen zu einem SAP-System verwendet werden, wird von der Workbench die
gleiche Technologie wie für einen kontinuierlichen Datentransfer über ALE zwischen SAP-Systemen
oder zwischen einem SAP- und einem Non-SAP-System verwendet. Die Daten müssen im IDoc-
Format vorliegen. Die IDoc-Nummern in der Datei müssen eindeutig sein. Wenn die Schnittstelle ge-
startet wird, werden die IDocs aus der vorgegebenen Eingabedatei gelesen und an das BAPI weiter
geleitet.
Für die Entwicklung von Schnittstellen mit der BAPI-Technologie sind Entwicklerberechtigungen not-
wendig. Aus diesem Grund muss vom Anwendungseigner ein Konzept für die Entwicklung und Aus-
führung von BAPIs erstellt werden, welches insbesondere die Übertragung umfangreicher Datenbe-
stände in das SAP-System berücksichtigt.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 46 von 67
6.5 Legacy Systems Migration Workbench (LSMW)
Die Übernahme von Daten eines Legacy-Systems in ein SAP-System ist entscheidend für den Erfolg
einer SAP-Einführung. Die Legacy System Migration Workbench (LSMW) ist ein Standardtool, wel-
ches diese Übernahme von Legacy-Daten erleichtern soll. Es ermöglicht die Datenübernahme aus
einer Vielzahl von Datenquellen ohne Programmieraufwand.
Nachdem die Regeln für eine Datenübernahme definiert wurden, werden aus diesen Definitionen mit
der LSMW ABAP-Programme generiert. Werden Daten importiert, führt das SAP-System die gleichen
Prüfungen wie bei einer Dialogeingabe aus. Updates auf der Datenbank werden durch Standard-
Batch-Input-Programme, Standard-Direct-Input-Programme, IDoc-Schnittstellen und BAPIs durchge-
führt.
Da umfangreiche Datenbestände in das SAP-System übertragen werden können, muss vom Anwen-
dungseigner ein Berechtigungskonzept für die Nutzung der LSMW erstellt werden.
6.6 CATT
CATT (Computer Aided Test Tool) ist eine SAP-System-Komponente, mit der die Anzahl von Testläu-
fen und der damit verbundenen Testzeiten verringert werden. Darüber hinaus wird die Nachverfol-
gung von Tests und deren Analyse gleichzeitig vereinfacht.
Mit CATT können Testfälle für SAP-Transaktionen entwickelt, einmal aufgezeichnet und dann beliebig
oft ausgeführt werden. Mit Hilfe dieser Testfälle können einzelne Transaktionen oder ganze Ge-
schäftsprozesse getestet werden. Durch die Definition von Testfall-Varianten mit unterschiedlichen
Eingabedaten können Testfälle flexibel definiert werden.
Für die Entwicklung und Aufzeichnung von CATT-Testfällen sind Entwicklungsberechtigungen not-
wendig. Aus diesem Grund muss vom Anwendungseigner ein Konzept für die Entwicklung und Aus-
führung von CATT-Testfällen erstellt werden, welches insbesondere die Übertragung umfangreicher
Datenbestände in das SAP-System berücksichtigt.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 47 von 67
6.7 Transfer-Verzeichnisse
SAP-Prozesse lesen oder schreiben Daten über das Betriebssystem (z. B. bei einem Batch-Input).
Aus diesem Grund muss der Zugriff auf Transfer-Verzeichnisse und die darin enthaltenen Dateien
sowohl innerhalb SAP als auch auf Betriebssystemebene eingeschränkt sein.
Das SAP-System führt bei der Arbeit mit Dateien automatisch Berechtigungsprüfungen (Berechti-
gungsobjekt S_DATASET) aus, bei denen die Berechtigungen sowohl für das ABAP-Programm als
auch für den Dateinamen überprüft werden.
Darüber hinaus wird über die Tabelle SPTH geprüft, ob die Datei für einen Zugriff aus ABAP heraus
registriert ist. Diese Tabelle steuert den Schreib- und Lesezugriff von ABAP-Programmen auf Dateien,
und ob Dateien in Sicherheitsprozesse integriert werden sollen. Über die Tabelle SPTH kann der Le-
se- oder Schreibzugriff für spezielle Dateien, unabhängig vom SAP-Berechtigungskonzept, verhindert
werden. Für alle anderen Dateien (also diejenigen, für welche ein Lese- und Schreibzugriff über einen
Eintrag in der Tabelle SPTH erlaubt ist), kann das SAP-Berechtigungskonzept zur Überprüfung der
Berechtigungen verwendet werden.
Vom Anwendungseigner muss deshalb ein Konzept für den Zugriff auf Transfer-Verzeichnisse von
SAP aus erstellt werden, welches insbesondere die folgenden Punkte berücksichtigt:
Schutz und Pflege der Tabelle SPTH,
Berechtigungen für einen Zugriff auf Transfer Verzeichnisse.
Zusätzlich muss ein Konzept für den Zugriff auf Transfer-Verzeichnisse/das Dateisystem auf Betriebs-
systemebene erstellt werden (s. a. Kapitel 11).
Der Geschäftsprozessinhaber ist dafür verantwortlich, ob und unter welchen Umständen Daten aus
einem SAP-System ausgelagert werden. Hierbei sind bestehende Dienstvereinbarungen bzw. Be-
stimmungen des Datenschutzes sowie etwaige Vorgaben der Internen Revision (IR) zu beachten.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 48 von 67
7. Systemlandschaft
Die Systemlandschaft und die hierfür notwendige Hardware muss in Abhängigkeit von den Anforde-
rungen der Geschäftsprozesse an die einzelnen Anwendungen (z. B. Stabilität, Verfügbarkeit, Perfor-
mance) definiert und eingerichtet werden. Hierbei müssen die in den folgenden Abschnitten genann-
ten Punkte berücksichtigt werden.
7.1 Systemkonzept
Der Anwendungseigner ist zur Erstellung eines Systemkonzepts für alle SAP-Anwendungen verpflich-
tet. Innerhalb dieses Systemkonzepts muss die Rolle jedes einzelnen Systems definiert werden (z. B.
Entwicklung, Qualitätssicherung, Produktion). Darüber hinaus muss ein Prozess für die Änderung von
Einstellungen definiert werden, um unkontrollierte und unautorisierte Änderungen im gesamten oder in
Teilen eines SAP-Systems, ganz besonders in Produktivsystemen, zu verhindern.
Es ist verbindlich, drei unterschiedliche SAP-Systeme für die Entwicklung, Tests und den Produktivbe-
trieb einzusetzen.
7.2 Mandantenkonzept
Der Anwendungseigner ist zur Erstellung eines Mandantenkonzepts für alle SAP-Anwendungen ver-
pflichtet. Innerhalb dieses Mandantenkonzepts müssen die folgenden Punkte festgelegt werden:
Verantwortlichkeiten für den Mandanten,
Rolle des Mandanten (z. B. produktiv, Q/A, Referenz),
Anwendungen und die entsprechenden Anwendungseigner, welche den Mandanten verwen-
den,
Zugriff auf einen Mandanten,
Berechtigungen, welche für die Benutzer in diesem Mandanten benötigt werden und
Einstellungen für die Mandantenänderbarkeit, um allgemeine oder spezielle Änderungen am
Mandanten zu verhindern.
Der Geschäftprozessinhaber muss regelmäßig die im Mandanten vorhandenen Einstellungen mit den
im Mandantenkonzept definierten Einstellungen vergleichen. Sofern Abweichungen vorkommen, müs-
sen die Ursachen hierfür ermittelt und die gewünschten Einstellungen wieder hergestellt werden.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 49 von 67
Falls das System/der Mandant zur Änderung von Einstellungen geöffnet wird, muss sichergestellt
werden, dass keine ungeprüften Änderungen durchgeführt werden. Eine entsprechende Dokumenta-
tion muss erstellt und nach Durchführung der Änderungen der ursprüngliche Status des Mandanten
wieder hergestellt werden.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 50 von 67
8. Change Management
Während des Lebenszyklus eines SAP-Systems sind verschiedene Änderungen notwendig, wie z. B.
laufende Verbesserungen der Services und der Funktionalität, Fehlerbehebungen, Support Packages
und Releasewechsel. Durch ein Change Management muss sichergestellt werden, dass für die effi-
ziente Handhabung aller Änderungen standardisierte Prozesse zur Verfügung stehen. Bevor Ände-
rungen in einem SAP-System vorgenommen werden, muss geprüft werden, ob diese Anpassungen
nicht über SAP Standardfunktionalitäten oder SAP-Hinweise durchgeführt werden können.
Ein Change Management hat die folgenden Vorteile:
Kontinuierliche Optimierung der Servicequalität.
Prüfung der Auswirkungen und Risiken bei Änderungen von Geschäftsprozessen.
Genehmigungsprozesse stellen sicher, dass nur autorisierte Änderungen im System umge-
setzt werden.
Eine nachvollziehbare und den Anforderungen der Revision genügende Dokumentation der
durchgeführten Änderungen, einschließlich einer Änderungshistorie.
Änderungen an einer Anwendungssoftware kann die Integrität oder den Betrieb eines SAP-Systems
beeinflussen. Aus diesem Grund müssen vom Geschäftprozessinhaber passende Prozesse für ein
Change Management erstellt werden, die sicherstellen, dass
alle Transportaufträge in ein Produktivsystem mindestens einem “4-Augen-Prinzip” entspre-
chend genehmigt werden müssen bzw. mit einem dokumentierten und sicherheitstechnisch
gleichwertigem Verfahren erfolgen (s. Anlage A3),
Änderungen in einem Produktivsystem erst nach der Genehmigung durch den Geschäftpro-
zessinhaber/Anwendungsbetreuer durchgeführt werden dürfen,
funktionale und technische Dokumentationen aller Änderungen im Produktivsystem verfügbar
sind,
Änderungen, bevor sie in einem Produktivsystem durchgeführt werden, in einem Q/A-System
ausreichend getestet werden,
durch Prozesse die Einhaltung der Entwicklungsrichtlinien gewährleistet wird.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 51 von 67
Der Geschäftprozessinhaber muss Prozesse zur Verwendung von Verpflichtungserklärungen für Be-
nutzer, die kritische Funktionen innerhalb des Change Management-Prozesses durchführen, definie-
ren, einführen und kontrollieren.
8.1 Software-Logistik
Der Change and Transport Organizer (CTO) stellt Funktionen für die Anlage, Dokumentation und die
Freigabe von Transportaufträgen für das Customizing und die Entwicklung zur Verfügung. Das Trans-
port Management System (TMS) unterstützt die Organisation und den Transport solcher Transportauf-
träge.
Der Geschäftprozessinhaber ist verpflichtet, eine Qualitätssicherung und notwendige Testmaßnah-
men einzuführen, um die Integrität und den Betrieb des Produktivsystems entsprechend einem “4-
Augen-Prinzip” sicherzustellen. Die Verwendung dreier separater SAP-Systeme für die Anwendungs-
entwicklung, die Qualitätssicherung und den Produktivbetrieb ist verbindlich, um
die Datenintegrität sicherzustellen,
persönliche Daten vor einem unautorisierten Zugriff zu schützen und
Änderungen im System nachvollziehen zu können.
Daher dürfen Entwicklungen und/oder Customizing-Einstellungen weder im Qualitätssicherungs- noch
im Produktivsystem durchgeführt werden. Berechtigungen für die Anwendungsentwicklung und/oder
das Customizing dürfen in einem produktiven SAP-System nicht zugewiesen werden. Änderungen
müssen zuerst im Entwicklungssystem durchgeführt und dann mit dem TMS in das Qualitätssiche-
rungssystem transportiert werden.
Erst nachdem ausreichende Tests und entsprechende Genehmigungs- und Freigabeprozesse durch-
geführt wurden, können Entwicklungen und/oder Customizing-Einstellungen mit dem TMS in die Pro-
duktivumgebung transportiert werden. Die innerhalb des TMS erzeugten Protokolle stellen sicher,
dass alle gemachten Einstellungen aufgezeichnet und nachvollzogen werden können.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 52 von 67
8.1.1 Tabellenprotokollierung ( → s. Anhang HR)
Während der Einführung und des Betriebs eines SAP-Systems wird eine große Anzahl von Tabellen
entsprechend den Anforderungen des Unternehmens angepasst. Da Tabellenänderungen prinzipiell
wie Änderungen an Programmen gehandhabt werden, müssen alle (relevanten) Tabellenänderungen,
die seit dem Produktivstart durchgeführt wurden, protokolliert werden. Die Änderungsprotokolle der
Tabellen müssen entsprechend aller gesetzlichen Anforderungen aufbewahrt werden.
In einem Produktivsystem müssen alle Tabellenänderungen (ALL), oder wenigstens die Tabellenän-
derungen im Referenzmandanten (000) und Produktivmandant(en), aufgezeichnet werden.
Sobald der Systemprofilparameter rec/client aktiviert ist, werden Änderungsbelege für diejenigen Ta-
bellen erzeugt, bei denen das entsprechende Protokollflag in den technischen Einstellungen gesetzt
ist. Für kundeneigene Tabellen muss vom Geschäftprozessinhaber festgelegt werden, ob eine Proto-
kollierung notwendig ist oder nicht. Die notwendigen Einstellungen, dass eine Protokollierung notwen-
dig ist, müssen bereits während der Anlage der betroffenen Tabelle vorgenommen werden. Der Chan-
ge Management-Prozess gibt diese Anforderungen wieder.
Sofern Customizing-Einstellungen transportiert werden, muss im Zielsystem sichergestellt werden,
dass diese Änderungen ebenfalls protokolliert werden. Im Konfigurationsprofil des betroffenen Zielsys-
tems muss der Parameter RECCLIENT (Parameter für die Tabellenprotokollierung) zum Importzeit-
punkt gesetzt sein (dieser Parameter darf nicht mit dem Systemprofilparameter rec/client verwechselt
werden).
8.1.2 Protokolle
Werden innerhalb eines SAP-Systems Änderungen an Objekten/Tabellen durchgeführt, wird in Ände-
rungsprotokollen ein Eintrag erzeugt, aus dem das betroffene System und die Einstellungen, die vor-
genommen wurden, hervorgehen.
Der Anwendungseigner hat sicherzustellen, dass diese Protokolle archiviert werden.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 53 von 67
8.2 Laufende Einstellungen
Laufende Einstellungen sind Customizing-Aktivitäten, die in einem produktiven System als Teil des
täglichen Betriebs durchgeführt werden müssen, obwohl Änderungen an Customizing-Aktivitäten im
betroffenen System prinzipiell nicht erlaubt sind.
Um eine Customizing-Aktivität als laufende Einstellung festzulegen, müssen für das betroffene Custo-
mizing-Objekt bestimmte Einstellungen vorgenommen werden. Laufende Einstellungen dürfen nur
unter Berücksichtigung des Change Management-Prozesses, welcher durch den Geschäftprozessin-
haber/Anwendungsbetreuer definiert wurde, durchgeführt werden.
Um im produktiven System laufende Einstellungen zu pflegen, muss durch den Anforderer ein Be-
rechtigungskonzept definiert und vom Geschäftprozessinhaber genehmigt werden. Die Vergabe sol-
cher Berechtigungen muss vom Rollenverantwortlichen regelmäßig überprüft werden.
Es muss zudem regelmäßig eine Liste der Customizing-Aktivitäten, die als laufende Einstellungen
definiert wurden, erstellt und mit dem dokumentierten Stand abgestimmt werden. Abweichungen müs-
sen dem Geschäftprozessinhaber mitgeteilt und angemessene Maßnahmen zur Wiederherstellung
des dokumentierten Stands eingeleitet werden.
8.3 Entwicklungsrichtlinien
Grundsätzlich dürfen Programmentwicklungen nur im Entwicklungssystem durchgeführt werden. Pro-
gramme und Customizing-Einstellungen müssen in das Q/A-System transportiert und dann mit dem
TMS in das Produktivsystem verbracht werden. Programmentwicklungen im Produktivsystem werden
als Notfälle betrachtet und müssen entsprechend gehandhabt werden.
Vom Anwendungseigner muss ein Genehmigungsprozess für die Zuweisung eines Entwicklers zu
einem Benutzer und für die Einrichtung eines Entwicklerschlüssels eingeführt werden. Alle hierfür
notwendigen Anforderungen und Genehmigungen müssen dokumentiert werden.
Ebenso muss vom Anwendungseigner ein spezielles Berechtigungskonzept für das Entwicklungssys-
tem definiert und umgesetzt werden, welches insbesondere die Erstellung von Transportaufträgen
und zugehörigen Aufgaben und deren Freigabe berücksichtigt.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 54 von 67
8.4 Systemöffnung für Customizing / Entwicklung
Bei Notfällen kann es notwendig sein, Änderungen an Customizing-Einstellungen oder Entwicklungen
direkt im Produktivsystem, unter Umgehung des Change Management-Prozesses oder laufender
Einstellungen, vorzunehmen.
In solchen Situationen können die Änderungseinstellungen für das produktive System bzw. den Man-
danten kurzfristig vorgenommen werden. Zu diesem Zweck muss vom Anwendungseigner ein Be-
rechtigungs- und Genehmigungsprozess eingeführt werden. Alle Genehmigungen müssen dokumen-
tiert werden. Aus der Dokumentation müssen die Gründe für den Notfalleinsatz und alle notwendigen
Aktivitäten, die im SAP-System durchgeführt wurden, hervorgehen.
Da kein Standardbenutzer die Berechtigungen für eine Änderung der Customizing-Einstellungen oder
Entwicklungen im Produktivsystem besitzt, wird hierfür ein gesonderter Notfallbenutzer benötigt (s. a.
Kapitel 5.4). Es muss sichergestellt werden, dass alle im produktiven System durchgeführten Ände-
rungen im Entwicklungs- und Q/A-System entsprechend nachvollzogen werden können.
8.5 Remote-Zugriff für den SAP-Support
Um Unterstützung zu leisten (z. B. aufgrund einer Customer Message), kann es notwendig sein, dass
SAP den Zugang zu einem SAP-System benötigt. Aus diesem Grund müssen vom Anwendungseig-
ner eine begrenzte Anzahl Benutzerkennungen, die einer speziellen Benutzergruppe zugeordnet sind,
zur Verfügung gestellt werden. Die Berechtigungen für einen Zugang der SAP zu einem produktiven
System sollen nicht den SAP-Standardprofilen SAP_ALL und/oder SAP_NEW entsprechen.
Prinzipiell soll der Zugriff nicht auf das Produktiv-System erfolgen.
Der Remote-Zugriff ist prinzipiell gesperrt. In Ausnahmefällen, in denen der Fehler/das Problem nicht
im Testsystem simuliert werden kann, wird der Zugriff durch den Anwendungseigner entsperrt. Die
Aktivitäten werden protokolliert. Nach Beendigung der Aktivitäten wird der Remote-Zugriff umgehend
wieder gesperrt.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 55 von 67
8.6 Namenskonventionen
Vom Geschäftprozessinhaber/Anwendungsbetreuer müssen Namenskonventionen definiert werden,
insbesondere für
Benutzergruppen,
Rollen,
Profile,
Hintergrundjobs,
Schnittstellen (RFC-Verbindungen),
Batch-Input und
Repository-Objekte (Programme, Tabellen etc.)
unter Berücksichtigung bereits bestehender Entwicklungs- bzw. Programmierrichtlinien definiert wer-
den.
9. Schutz des Produktivsystems
Der Schutz des Produktivsystems bzw. der produktiven Umgebung findet nicht nur innerhalb des Pro-
duktivsystems selbst statt, sondern hängt wesentlich von den im Change Management-Prozess ge-
nannten Punkten ab (s. a. Kapitel 8).
9.1 Schutz von Tabellen
Der Geschäftprozessinhaber/Anwendungsbetreuer muss ein Konzept für die Verwaltung von Tabel-
len erstellen, innerhalb dessen die Berechtigung zur Verwaltung bestimmter Tabellen nur an einen
bestimmten genau definierten Personenkreis einer Organisationseinheit und/oder der SAP-System-
administration zugewiesen wird.
Sollte in einzelnen Fällen eine direkte Verwaltung von Tabellen notwendig sein, muss der Zugang zu
diesen Tabellen durch die Verwendung von Benutzergruppen geschützt sein. Der Benutzer darf nur
Zugang zu denjenigen Daten erhalten, die für ihn, unter Berücksichtigung seiner Organisationseinheit,
relevant sind.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 56 von 67
Notwendige Tabellenänderungen müssen unter Verwendung
der SAP-Standardtransaktionen,
einem generierten Tabellenpflegedialogs oder
eigener erstellter Pflegetransaktionen
durchgeführt werden.
9.2 Schutz von Programmen
Der Zugriffschutz innerhalb eines SAP-Systems basiert im Wesentlichen auf die systemseitig durch-
geführten Berechtigungsprüfungen in Programmen. Hierfür wird das ABAP/4-Statement AUHTORITY-
CHECK verwendet, welches direkt im Coding von Programmen implementiert wird. Wird ein Pro-
gramm ausgeführt, prüft das ABAP/4-Statement AUTHORITY-CHECK, ob die Berechtigungen des
Benutzers, welcher das Programm ausführt, genügen. Sollte dies der Fall sein, wird der Zugriff auf die
gewünschten Informationen gewährt, wenn nicht, muss das Programm so konfiguriert sein, dass ein
Zugriff verweigert wird. Ein verlässlicher Zugriffschutz kann nur dann sichergestellt werden, wenn eine
Berechtigungsprüfung im Coding der Programme korrekt implementiert wurde.
Die Ausführung von Programmen muss im Rahmen eines Berechtigungskonzepts geregelt sein. Auf
kundeneigene Programme darf prinzipiell nur über einen entsprechenden Transaktionscode zugegrif-
fen werden, wobei der Anwender grundsätzlich nur Zugriff auf diejenigen Daten erhält, die für ihn,
unter Berücksichtigung organisatorischer Einheiten, relevant sind. Diese Anforderungen müssen im
Change-Management-Prozess und/oder in der Entwicklungsrichtlinie definiert werden.
9.3 Logische Systemkommandos
Anwender können über so genannte „Logische System Kommandos“ Betriebssystemkommandos aus
einem SAP-System heraus ausführen. Sowohl die Verwaltung als auch die Ausführung solcher exter-
nen Kommandos muss geschützt werden. Aus diesem Grund muss der Anwendungseigner ein Kon-
zept für die Anlage/Ausführung logischer Betriebssystemkommandos definieren. Im Rahmen dieses
Konzepts muss berücksichtigt werden, dass logische Betriebssystemkommandos sowohl im Dialog
als auch aus Programmen über die Nutzung von Funktionsbausteinen gestartet werden können.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 57 von 67
Der Anwendungseigner muss regelmäßig eine Liste der Benutzer, welche die Berechtigung zur Aus-
führung und/oder Verwaltung logischer Betriebssystemkommandos besitzen, erstellen und mit den
Anforderungen des entsprechenden Konzepts abgleichen.
9.4 Sperrung von Transaktionen
In bestimmten Fällen kann die Sperrung von Transaktionen notwendig sein.
Hierfür muss vom Anwendungseigner im Rahmen des Change Management-Prozesses ein Berechti-
gungs- und Genehmigungsprozess definiert werden. Alle Anforderungen und Genehmigungen müs-
sen dokumentiert werden.
9.5 Queries
SAP-Queries werden zur Erstellung von Berichten, die nicht im SAP-System vorhanden sind, genutzt.
Für die Anlage und/oder Ausführung von Queries muss der Anwendungsbetreuer ein entsprechendes
Konzept erstellen, welches berücksichtigt, dass ein Benutzer nur diejenigen Queries, die für seine
Aufgaben unbedingt notwendig sind, ausführen darf. Aus diesem Grund müssen Berechtigungen so
erstellt werden, dass bestimmte Endanwender einer Benutzergruppe berechtigt sind, Queries zu ver-
walten und auszuführen, während andere Mitglieder dieser Benutzergruppe Queries nur ausführen
dürfen. Es muss sichergestellt werden, dass Benutzer nur Zugriff auf Daten erhalten, die für ihre ei-
gentlichen Aufgaben notwendig sind.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 58 von 67
10. Überwachung des Systemzugangs und von Systemaktivitäten
An die Überwachung des Systemzugangs und der Systemaktivitäten werden die in folgende Abschnit-
te angeführten Anforderungen gestellt.
10.1 Systemprotokoll
Das SAP-System protokolliert unterschiedliche Fehlersituationen in den Systemlogs. Da das System-
protokoll im Allgemeinen in kurzen Abständen gelöscht wird, müssen die Logfiles zur Überprüfung
ungewöhnlicher Systemaktivitäten und im Hinblick auf mögliche Verstöße gegen bestehende Rege-
lungen archiviert werden. Die Überwachung der relevanten Anzeigen im Systemprotokoll sollte an ein
entsprechendes Monitoring-System gekoppelt sein.
Die SAP-Systeme sind am Monitor-System (Nagios) angeschlossen und werden regelmäßig über-
wacht.
10.2 Überwachung spezieller Benutzerkennungen
Für die Überwachung von Benutzern mit übergreifenden Berechtigungen (z. B. Notfalluser, DDIC,
SAP-Remote, Berater, sonstige umfangreiche Berechtigungen), müssen alle SAP-Aktivitäten dieser
Benutzer protokolliert werden. Die Logdateien sind regelmäßig mit den Unterlagen dieser Benutzer zu
überprüfen, in denen der Gebrauch dieser kritischen Berechtigungen dokumentiert ist. Falls Unregel-
mäßigkeiten auftreten, muss ein Eskalationsverfahren vom Anwendungseigner initiiert werden. Die
Logdateien sind zu archivieren und für einen Zeitraum von 10 Jahren aufzubewahren.
Der Geschäftprozessinhaber legt fest, für welche Nutzer diese Überwachung eingesetzt wird.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 59 von 67
10.3 Datenintegrität - Verbuchungsabbrüche
Bei Verbuchungsabbrüchen ist zu dokumentieren, bei welcher Aktivität und durch welchen Anwender
diese entstanden sind. Weiterhin sind die verantwortlichen Administratoren per Express-Mail zu be-
nachrichtigen, um zeitnah reagieren zu können. Soweit buchhaltungsrelevante Transaktionen betrof-
fen sind, muss deren Bearbeitung in einem nachvollziehbaren Verfahren geregelt werden. Die Verbu-
chungsabbrüche müssen, um eine lückenlose Nachvollziehbarkeit der eingesetzten Verfahren ge-
währleisten zu können, zusammen mit den Finanzbuchhaltungsunterlagen entsprechend den gesetz-
lichen Anforderungen aufbewahrt werden. Um eine systemseitige Löschung noch nicht bearbeiteter
Verbucherabbrüche zu verhindern, muss der Wert des Systemprofilparameters rdisp/vbdelete vom
Standardwert 50 auf 0 geändert werden.
10.4 Anforderungen an eine Dokumentation
Alle Prozesse, die durch diese oder weitere Richtlinien oder Direktiven umgesetzt werden, sind zu
dokumentieren. Die zu diesen Prozessen gehörenden Dokumente sind zu archivieren.
11. Betriebssystem- und Netzwerksicherheit
Die Zuständigkeit für die Betriebssystem- und Netzwerksicherheit liegt bei den zuständigen Sachge-
bieten, Abteilungen bzw. Geschäftsbereichen. Die für den Betrieb der Systeme notwendigen Doku-
mentationen sind vorzuhalten.
12. Ausnahmen
Falls aufgrund besonderer technischer oder organisatorischer Anforderungen Ausnahmen von den
verbindlichen Regeln erforderlich sind, sind diese zu dokumentieren und müssen von den zuständi-
gen Leitungsgremien genehmigt werden. Hierbei ist zu beachten, dass in keinem Fall die Revisions-
fähigkeit des Systems gefährdet wird.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 60 von 67
13. Sicherstellung der Einhaltung dieser Richtlinie
Die Sicherstellung der Einhaltung dieser Richtlinie ist wie folgt zu gewährleisten:
Etablierung eines internen Kontrollsystems beim Systembetreiber, Anwendungseigner und
Geschäftsprozessinhaber,
Umsetzung der von externen und internen Prüfern vorgeschlagenen Maßnahmen zur Sicher-
stellung der Revisionsfähigkeit,
Überprüfung der daraus resultierenden Maßnahmen durch die Interne Revision und das Prüf-
team (s. Anlage A6).
14. Salvatorische Klausel:
Sollte eine oder sollten mehrere Bestimmungen dieses Vertrages unwirksam sein oder werden, bleibt
die Wirksamkeit des Vertrages im Übrigen hiervon unberührt. Die Vertragsparteien werden sich be-
mühen, die unwirksamen Bestimmungen durch wirksame Regelungen zu ersetzen, die dem Inhalt der
unwirksamen Bestimmung am nächsten kommen. Entsprechendes gilt für unvorhergesehene Lücken
im Vertrag.
15. Inkrafttreten
Dieser Sicherheitsleitfaden tritt am 1.11.2007 in Kraft.
Für die Universität Göttingen Für die Universitätsmedizin Göttingen Der hauptamtliche Vizepräsident Vorstand Wirtschaftsführung und
Administration
Göttingen, den 8.10.2007 Göttingen, den 9.10.2007
gez. M. Hoppe gez. Dr. S. Freytag
( Dipl. Kfm. Markus Hoppe ) ( Dr. Sebastian Freytag (komm.))
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 61 von 67
Anhang SAP-HR
zu 5.1.1.3 Funktionale und mehrfach verwendete Benutzerkennungen
Aufgrund der SAP-Lizenzvereinbarungen ist die gleichzeitige Verwendung einer Benutzerkennung
durch mehrere Anwender grundsätzlich verboten. Über diese vertragliche Regelung hinaus dürfen
keine funktionalen bzw. anonymisierten Benutzerkennungen im Rahmen dieser Richtlinie verwendet
werden, um eine eindeutige Identifikation von Benutzern und die Nachvollziehbarkeit von deren Aktivi-
täten (z. B. die Ausführung von Transaktionen, Programmen, Hintergrundjobs) innerhalb der Anwen-
dungen und IT-Systeme zu gewährleisten.
Ausnahmen aufgrund spezieller technischer Voraussetzungen oder Anforderungen aus (operativen)
Geschäftsprozessen müssen vom hierfür zuständigen Anwendungsbetreuer (Verfahrensebene) ge-
nehmigt werden.
Für die Hintergrund- und/oder Schnittstellenverarbeitung (s. a. Kapitel 6) können 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 abhängig sein.
Die Verwaltung von Benutzerkennungen für die Hintergrund- bzw. Schnittstellenverarbeitung ist auf
einen bestimmten Personenkreis, der vom Anwendungseigner genehmigt werden muss, einzuschrän-
ken.
Administrative Prozesse, die sich über den gesamten Lebenszyklus einer Benutzerkennung erstre-
cken, müssen vom Anwendungsbetreuer (Verfahrensebene) eingeführt und regelmäßig überwacht
werden.
HR-spezifische Regelung: Für Testzwecke werden folgende Benutzerkennungen verwendet:
Test UMG für Bereich UMG
Test ZUV für Bereich ZUV
Die Benutzerkennungen werden auf Anforderung der Verfahrensbetreuer (Anwendungsebene) bzw.
der Key-User von Anwendungsbetreuer (Technikebene) entsperrt/gesperrt und enthalten unter Name
jeweils den aktuellen Testbenutzer.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 62 von 67
zu 5.2.4.1 Qualitätssicherungssysteme
Der Zugang zu Q/A-Systemen (Qualitätssicherungssystemen) muss auf die folgenden Personenkrei-
se eingeschränkt sein:
IT (Entwickler, Benutzer mit Customizing-Rechten etc.)
Support-Benutzer (Fernwartung)
Projekt-Teams
Key-User.
Key-User und Anwendungsbetreuer dürfen das Q/A-System zu Testzwecken verwenden. Für diese
Key-User und Anwendungsbetreuer finden dieselben organisatorischen Einschränkungen wie in ei-
nem produktiven System Anwendung.
Endanwender sollten grundsätzlich keinen Zugang zum Q/A-System, außer zu Testzwecken, erhal-
ten.
HR-spezifische Regelung: Für die Endanwender werden dieselben organisatorischen Einschränkungen wie im produktiven Sys-
tem angewandt. Ein explizites „freischalten“ von Endanwendern, ist nur mit einem erhöhten personel-
len Aufwand realisierbar.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 63 von 67
zu 5.2.4.2 Produktivsysteme
Grundsätzlich ist der Zugang zu einem Produktivsystem nicht auf einen bestimmten Personenkreis
eingeschränkt. Es müssen jedoch funktionale und organisatorische Einschränkungen 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 dürfen in einem Produktivsystem nicht die folgenden Rechte besitzen:
Programmierung
Änderung von Feldinhalten während des Programmablaufs
Transportberechtigungen.
HR-spezifische Regelung: Gültig für Entwickler/innen:
Bei Anwendern/innen mit Customizing-Rechten nicht anwendbar, weil von den übertragenden Aufga-
ben (z. B. Umsetzung von Massendaten per Batch, Abrechnung) keine Einschränkung möglich ist.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 64 von 67
zu 5.2.5.4 Zuweisung von Rollen zu nicht Dialogbenutzern
Für nicht Dialogbenutzer ist ein Verantwortlicher festzulegen. Weitere Einzelheiten s. Kapitel 5.2.5.3.
HR-spezifische Regelung: Verantwortlicher bei HR: Anwendungseigner
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 65 von 67
zu 5.3.3 Rollenverwaltung – Grundlegende Prinzipien
Es wird ausdrücklich empfohlen, dass die Anlage und Änderung von Rollen nur im Entwicklungssys-
tem durchgeführt wird. Die Rollen müssen innerhalb des Q/A-Systems durch den Key-
User/Anwendungsbetreuer, unter Berücksichtigung unterschiedlicher Geschäftsvorfälle, getestet wer-
den. Hierbei sind sowohl Positivtests (=Funktionserfüllung) 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 Notfällen ist die Anlage oder Änderung einer Rolle durch die Berechtigungsadministration im Pro-
duktivsystem zulässig, sofern der Anwendungseigner zugestimmt hat. Alle Änderungen werden da-
nach per Down- und Upload in das Entwicklungssystem verbracht und anschließend ü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 müssen beschrieben und dokumentiert werden. Innerhalb einer Beschreibung müssen alle
durch die jeweilige Rolle zugänglichen Menüpunkte und Transaktionen definiert werden. Ebenso müs-
sen mögliche Einschränkungen dargestellt werden. Für jede Rolle muss ein Verantwortlicher definiert
werden, der für den Inhalt (Transaktionen, Berechtigungsobjekte, organisatorische Einschränkungen)
und die Zuweisung der Rolle verantwortlich ist.
Für alle Rollenänderungen müssen ausreichende Dokumentationen angelegt werden.
Innerhalb einer Einzelrolle dürfen keine Probleme bezüglich einer Funktionstrennung auftreten.
Eine Rolle darf grundsätzlich 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 enthält, wird automatisch als kritisch/sensitiv angesehen.
Der Geschäftsprozessinhaber muss kritische/sensitive Berechtigungen und die Zuordnung der Rollen
in regelmäßigen Abständen überprüfen und entscheiden, ob diese immer noch benötigt werden. Ein
Bericht über diese Untersuchungen ist an den Anwendungseigner zur Archivierung zu senden.
Einzelheiten, welche die Rollenverwaltung und den Rolleninhalt betreffen, müssen vom Geschäftspro-
zessinhaber in einem spezifischen Konzept definiert werden.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 66 von 67
Spezielle Zugriffsrechte müssen auf den Personenkreis beschränkt sein, welcher für das System, das
Netzwerk oder das Anwendungsmanagement und/oder die Sicherheit zuständig ist.
HR-spezifische Regelung: Für jede Rolle muss ein Verantwortlicher (HR: Key-User bzw. Anwendungsbetreuer (Verfahrensebe-
ne)) definiert werden, der für den Inhalt (Transaktionen, Berechtigungsobjekte, organisatorische Ein-
schränkungen) und die Zuweisung der Rolle verantwortlich ist.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
________________________________________________________________________
_______________________________________________________________________
SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 24.10.2007 – Seite 67 von 67
zu 8.1.1 Tabellenprotokollierung
Während der Einführung und des Betriebs eines SAP-Systems wird eine große Anzahl von Tabellen
entsprechend den Anforderungen des Unternehmens angepasst.
Da Tabellenänderungen prinzipiell wie Änderungen an Programmen gehandhabt werden, müssen alle
(relevanten) Tabellenänderungen, die seit dem Produktivstart durchgeführt wurden, protokolliert wer-
den. Die Änderungsprotokolle der Tabellen müssen entsprechend aller gesetzlichen Anforderungen
aufbewahrt werden.
In einem Produktivsystem müssen alle Tabellenänderungen (ALL), oder wenigstens die Tabellenän-
derungen im Referenzmandanten (000) und Produktivmandant(en), aufgezeichnet werden.
Sobald der Systemprofilparameter rec/client aktiviert ist, werden Änderungsbelege für diejenigen Ta-
bellen erzeugt, bei denen das entsprechende Protokollflag in den technischen Einstellungen gesetzt
ist. Für kundeneigene Tabellen muss vom Geschäftprozessinhaber festgelegt werden, ob eine Proto-
kollierung notwendig ist oder nicht. Die notwendigen Einstellungen, dass eine Protokollierung notwen-
dig ist, müssen bereits während der Anlage der betroffenen Tabelle vorgenommen werden. Der Chan-
ge Management-Prozess gibt diese Anforderungen wieder.
Sofern Customizing-Einstellungen transportiert werden, muss im Zielsystem sichergestellt werden,
dass diese Änderungen ebenfalls protokolliert werden. Im Konfigurationsprofil des betroffenen Zielsys-
tems muss der Parameter RECCLIENT (Parameter für die Tabellenprotokollierung) zum Importzeit-
punkt gesetzt sein (dieser Parameter darf nicht mit dem Systemprofilparameter rec/client verwechselt
werden).
HR-spezifische Regelung: Im HR-System ist die Protokollierung von wichtigen Infotypen eingeschaltet. Welche Tabellen zusätz-
lich zu protokollieren sind, ist fallweise und aufgabenspezifisch mit der Internen Revision (IR) abzu-
stimmen. Das Auslesen von Protokollen ist ausschließlich auf Ebene der Key-User erlaubt.
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
_______________________________________________________________________
Anlagen zum SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 25.09.2007
Anlagen zum
Sicherheitsleitfaden für SAP-Verfahren - Security Guide Line -
Georg-August-Universität Göttingen
Stiftung Öffentlichen Rechts
einschließlich der Universitätsmedizin Göttingen Medizinische Fakultät und Universitätsklinikum
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
_______________________________________________________________________
Anlagen zum SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 25.09.2007
Anlage A1: Namenskonventionen GAU (Georg-August-Universität)
Namenskonvention GAU Anlage A1
Applikati
onFix Bere
ichUnter
ApplRolle
ntypFix Funkti
on 1Funkti
on 2Funkti
on 3Funkti
on 4Fix Org
an.Einsc
hr.1
Organ
.Einschr...
Organ
.Einschr.1
9
1 2 3 4 5 6 7 8 9 10 11 12 .. 30P : Z A E _ S B M V _ BeispielrolleP PersonalS SystemF FinanzenK KostenrechnungM MaterialwirtschaftN IS-HV Vertrieb...
G GemeinsamZ UniU UKGA Akademie d.WissenschaftenS StudentenwerkB GBVX XLabW GWDGY Alle außer UKG
P A AdministrationP Y AbrechnungP D OrganisationsmanagementP T ZeitwirtschaftP E DienstplanungP B BasisP U Benutzer-/Berechtigungsverw.F G Hauptbuchhaltung
Seite 1 von 2
F D DebitorenF R RechtsabteilungF K KreditorenF A AnlagenbuchhaltungF H HaushaltsmanagementF E Elektronischer KontoauszugF _ ÜbergeordnetN U ? IS-HN C Ändern (IS-H)N A Anlegen (IS-H)N Z Anzeigen (IS-H)M D DispositionM E EinkaufM R RechnungsprüfungM W WarenwirtschaftM P PlantmaintenanceM _ ÜbergeordnetV _ Vertrieb
E EinzelrolleZ ZusatzrolleS SammelrolleT Template_ nicht genutzt
S B M V Funktionen_ Freie Namensvergabe
Das 4.+5.Zeichen entfallen bei Benutzergruppen
Seite 2 von 2
Anlage A1
Namensbeispiel Typ BeschreibungP:ZAE_SBMV_GB61 Rolle Uni-Personaladministration:
Sachbearbeiter Mehrarbeitsvergütung im GB61 m. organisatorischer Zuordnung x
P:G_E_ALLE Rolle Gemeinsame Rolle für alle BenutzerP:Z_SBMV Benutzergruppe Sachbearbeiter Mehrarbeitsvergütung im
GB61S:Z_BEVE Benutzergruppe BenutzerverwalterS:ZBE_BEVE Rolle Uni-Berechtigungen: BenutzerverwalterS:ZAE_ALLE Rolle Uni-System: Systemberechtigungen die
alle haben müssenF:U_DEBU Benutzergruppe UKG-Finanzwesen-Debitorenbuchhalter
F:UDE_DEBU_X Rolle UKG-Finanzwesen-Debitorenbuchhalter: Reisekosten für Kostenstelle X
M:UEE_EKTE_X Rolle Einkäufer Technik für die Gesamtuniversität
M:GEE_EKMA Rolle Mitarbeiter im Einkaufsmarketing
Seite 1 von 1
Anlage A1
Benutzer, Benutzergruppe, Funktion, Rolle1. Jeder Benutzer erhält eine Benutzergruppe.2. Die Benutzergruppe entspricht seiner Funktion.3. Rollen enthalten die Funktion.
Namenskonvention für Funktionen1. Funktionenkürzel bestehen aus 4 Zeichen2. Das erste Zeichen ist der Anfangsbuchstabe der Funktionsbeschreibung3. Die weiteren Zeichen sind:a) wenn die Fb aus einem Wort besteht, welches nicht aus 2 Teilen besteht, die ersten 4 Buchstabenb) wenn die Fb aus einem Wort besteht, welches aus 2 Teilen besteht, die ersten beiden Buchstaben der 2 Teilec) wenn die Fb aus 2 Wörtern besteht, abhängig davon ob die Wörter aus 2 Teilen bestehen, der 1. Anfangsbuchstabe der Teile bzw. bei einteiligen Wörtern die ersten beiden Buchstaben.
Namenskonvention Rollen1. Die Namenskonvention für Rollen entspricht der Tabelle im 1.Reiter2. Die Bezeichnung der Rolle enthält zuerst die Funktionsbeschreibung. Durch einen Bindestrich getrennt folgen weitere Informationen.3. Die Funktion ist Bestandteil der Rolle (7.-10.Zeichen).4. Ausnahmen sind die Funktionen ALLE und TEIL, die bei Zusatzrollen genutzt werden können: ALLE beinhaltet Funktionen, die alle Benutzer des Bereichs erhalten sollen, TEIL gilt nur für eine Auswahl der Benutzer des Bereichs
Namenskonvention Profile1. Profile entsprechen bis zum 8.Zeichen den übergeordneten Rollen.2. Das 9.und 10.Zeichen werden, beginnend bei 01, durchnummeriert.3. Bei mehr als 100 Profilen wird das 8.,9. und 10.Zeichen für die Durchnummerierung genutzt (Achtung: Eindeutigkeit der Profilnamen).4. Der Profiltext entspricht der Bezeichnung der Rolle.
Namenskonvention Benutzergruppen1. Benutzergruppen entsprechen bis zum 10.Zeichen den Rollen, wobei auf das 4.+5.Zeichen verzichtet wird.2. Die Bezeichnung der Benutzergruppe enthält die Funktionsbeschreibung.3. Die Funktion ist Bestandteil der Benutzergruppe (5.-8.Zeichen).4. Ausnahme: Infouser mit ausschließlicher Leseberechtigung erhalten die Funktion INFO. Hier entspricht die Funktion nicht der Funktion der Rolle, die z.B: IUCO Infouser Controlling heißen kann.
Seite 1 von 2
Anlage von Rollen1. Jede Rolle hat ein Menü. Ausnahme: Kontextberechtigung (P:GAZ_ALLE_KONTEXT).2. Transaktionen werden ausschließlich über das Menü definiert (nachträgliches Einfügen in S_TCODE ist nicht gestattet; generische Codes sind so nicht möglich). Transaktionen, die nicht im Menü erscheinen sollen, werden über den "Berechtigungsvorschlag" eingepflegt.
3. Template-Rollen dürfen Benutzern nicht zugeordnet werden.4. Template-Rollen dienen der Differenzierung von organisatorischen Unterschieden
Seite 2 von 2
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
_______________________________________________________________________
Anlagen zum SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 25.09.2007
Anlage A2: Namenskonventionen für Benutzer
1. Nachname gleich Benutzer. Eine Umsetzung in Grossbuchstaben erfolgt in SAP automatisch.
2. Die maximale Länge des Benutzers beträgt 12 Stellen. Ist der Nachname länger, so wird er nach 12 Zeichen abgeschnitten.
3. Umlaute und ß werden umgesetzt. D.h. aus "ö" wird "oe"; aus "ß" wird "ss".
4. Doppelnamen: nur den ersten Namen aufnehmen bzw. Benutzer fragen, welcher Namensteil als Benutzer genommen werden soll
5. Mehrfach vorkommende Namen: Der erste bleibt pur. Benutzer gemäß dieser Konvention. Weitere Benutzer erhalten eine lfdNr.
Beispiele
zu 1) Burmeister = BURMEISTER
zu 2) Zimmermannundzimmerfrau = ZIMMERMANNUN
zu 3) Gröling = GROELING
zu 4) Nordhoff-Felis = FELIS (auf Nachfrage)
zu 5) Ahlborn, Klaus = AHLBORN Ahlborn, Karin = AHLBORN1 Ahlborn, Angela = AHLBORN2
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
_______________________________________________________________________
Anlagen zum SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 25.09.2007
Anlage A3: Transport und Genehmigung von Aufträgen
Tranport und Genehmigung von Aufträgen/Aufgaben
G33 G35 VSY G34Test-/Entwicklungssystem Konsolidierungssystem Virtuelles System Produktivsystem08:00 08:12 08:15 08:25 09:011) Auftrag anlegen2) Aufgabe/Auftrag freigeben Import-Queue
3a) Auftrag wird automatischalle 1/2 Stunde importiert (:12 / :42)
oder3b) manueller Import Import-Queue
entspricht dem QA Arbeitsvorrat4) Genehmigung
5)alle genehmigten Aufträge werden alle 1/4 Stunde (:10 / :25 / :40 / :55)aus dem virtuellen System in die Import-Queuedes Produktivsystem umgehängt
Import-Queue6a) alle genehmigten Aufträge werden automatisch jede Stunde importiert (:01)
oder6b) manueller Import
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
_______________________________________________________________________
Anlagen zum SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 25.09.2007
Anlage A4: Formulare für den HR-Zugang
Auskünfte erteilt das Team 511, Personalorganisation, Telefon 14063 bzw. 4227
Version: Dez. 2006
An Bereich 51 Team 511 Im Hause
EINRICHTEN EINES BENUTZERS IM MODUL SAP-HR (PERSONALDATEN)
Einrichtung: Datum:
Leiter/-in der Einrichtung: Tel: Angaben zum Benutzer:
Zugang Abgang Änderung
Anrede: Titel:
Name: Vorname:
Raumnummer: Gebäude:
Telefon: Fax:
E-Mail:
Gültig ab: bis:
1. Tätigkeitsbeschreibung
2. Antragsbegründung
3. Spezifikation des Datenzugriffs Mitarbeiterkreise:
Beamte Beschäftigte Auszubildende stud. / wiss. Hilfskräfte Lektoren Emeriti Verw./Vertr.-Beauftragte Gastarzt/-wissensch.
Organisationseinheiten: Bei Änderung/Abgang den vorhandenen Benutzernamen angeben:
Unterschrift des Leiters/der Leiterin der oben genannten Einrichtung ( Stempel)
Bitte leiten Sie den Antrag an den Bereich 51 – Team 511 - weiter
Version: Dez. 2006
Benutzerantrag Seite 2
1
Fachliche Freigabe durch Team 511 Organisationseinheit:
Kostenstelle:
Rolle:
Profil (Strukturelle Berechtigung):
Anmerkung (z.B. Entwicklung neuer Rolle/Berechtigung):
Datum Unterschrift
Team 511
Personalorganisation
2
Anlegen des Benutzers im SAP-HR System:
Mandant:
R/3-Benutzername:
Benutzergruppe:
Erledigungsvermerke:
Datum Unterschrift
Benutzer in SAP eingetragen/gelöscht/geändert*
Rolle/Berechtigung zugeordnet
SAP-Drucker zugeordnet
Benachrichtigung Benutzer
*Nichtzutreffendes bitte streichen
Auskünfte erteilt das Team 511, Personalorganisation, Telefon 14063 bzw. 4227
Version: Dez. 2006
Absender: An Bereich 51 Team 511 Im Hause
EINRICHTEN EINES BENUTZERS IM MODUL SAP-HR (PERSONALDATEN)
Einrichtung: Datum:
Leiter/-in der Einrichtung: Tel: Angaben zum Benutzer:
Zugang Abgang Änderung
Anrede: Titel:
Name: Vorname:
Raumnummer: Gebäude:
Telefon: Fax:
E-Mail:
Gültig ab: bis:
1. Tätigkeitsbeschreibung
2. Antragsbegründung
3. Spezifikation des Datenzugriffs Mitarbeiterkreise:
Beamte Beschäftigte Auszubildende stud. / wiss. Hilfskräfte Lektoren Emeriti Verw./Vertr.-Beauftragte Gastarzt/-wissensch.
Organisationseinheiten: Bei Änderung/Abgang den vorhandenen Benutzernamen angeben:
Unterschrift des Leiters/der Leiterin der oben genannten Einrichtung ( Stempel)
Bitte leiten Sie den Antrag an den Bereich 51 – Team 511 - weiter
Version: Dez. 2006
Benutzerantrag Seite 2
1
Fachliche Freigabe durch Team 511 Organisationseinheit:
Kostenstelle:
Rolle:
Profil (Strukturelle Berechtigung):
Anmerkung (z.B. Entwicklung neuer Rolle/Berechtigung):
Datum Unterschrift
Team 511
Personalorganisation
2
Anlegen des Benutzers im SAP-HR System:
Mandant:
R/3-Benutzername:
Benutzergruppe:
Erledigungsvermerke:
Datum Unterschrift
Benutzer in SAP eingetragen/gelöscht/geändert*
Rolle/Berechtigung zugeordnet
SAP-Drucker zugeordnet
Benachrichtigung Benutzer
*Nichtzutreffendes bitte streichen
Universitätsmedizin Göttingen Georg-August-Universität Universitätsklinikum · Medizinische Fakultät Geschäftsbereich G3-7 Informationstechnologie
Auskünfte erteilt der Geschäftsbereich G3-76 Service-Center, Help Desk Telefon 8221
Version: 20.08.2007
An den Geschäftsbereich G3-201 Im Hause
EINRICHTEN EINES BENUTZER IM MODUL SAP-HR (PERSONALDATEN)
Einrichtung: Datum:
Leiter/-in der Einrichtung: Tel: Angaben zum Benutzer:
[ ] Zugang [ ] Abgang [ ] Änderung
Anrede: Titel:
Name: Vorname:
Raumnummer: …………………. Ebene: ………….. Gebäude:
Telefon: Fax: E-Mail:
Gültig ab: ………………… bis: …………………….. Haben Sie einen Benutzer-Account in einem anderem SAP-System (z.B. KIS)?
nein ja → Bitte Benutzername angeben:
1. Tätigkeitsbeschreibung
2. Antragsbegründung
3. Spezifikation des Datenzugriffs Mitarbeiterkreise:
10 Beamte 11 Angestellte 12 Arbeiter 14 Angestellte/Arbeiter 16 Angestellte (nR) 17 Arbeiter (nR) 18 Lektoren (nR) 20 wiss.Hilfskr.F +L 21 stud.Hilfskr.F+L 22 stud.Angest. 23 stud.Hilfskr.-Std.lohn 24 wiss.Hilfskr.Bachelor 29 stud.HiWi MTArb 30 Azubi-Angest. 31 Azubi-Arbeit. 36 Azubi-Angest. (nR)
37 Azubi-Arbeit. (nR) 41 Übungsleiter 50 Lektoren 51 Verw./Vertr.-Beauftr. 52 Gastarzt/-wissensch. 53 externe Lehrbeauftr. 54 Prof/Oass/wAss i.A 58 Juniorprof.-Ang. 61 Emeriti 69 Überg.geld-Arbeiter 70 Überg.geld-Angest. 71 Sterbegeldempfänger 95 Einzelzahlungen 72 Übergangsgeld Beamte
Organisationseinheiten: …………………………………………………………………………………………………………………………. …………………………………………………………………………………………………………………………. …………………………………………………………………………………………………………………………. …………………………………………………………………………………………………………………………. Bei Änderung/Abgang den vorhandenen Benutzernamen angeben:
Unterschrift des Leiters/der Leiterin der oben genannten Einrichtung ( Stempel)
Bitte leiten Sie den Antrag an den Geschäftsbereich G3-201 weiter
Universitätsmedizin Göttingen Georg-August-Universität Universitätsklinikum · Medizinische Fakultät Geschäftsbereich G3-7 Informationstechnologie
Version: 20.08.2007
Benutzerantrag Seite 2 1
Fachliche Freigabe durch G3-201 Organisationseinheit: Kostenstelle: Rolle:
Profil (Strukturelle Berechtigung):
Anmerkung (z.B. Entwicklung neuer Rolle/Berechtigung):
Datum Unterschrift
G 3-201
Personalabteilung
2
Anlegen des Benutzers im SAP-HR System: Mandant:
R/3-Benutzername: Benutzergruppe:
Erledigungsvermerke: Datum Unterschrift
Benutzer in SAP eintragen/gelöscht/geändert*
Rolle/Berechtigung zugeordnet
Anlegen Verknüpfung PT
SAP-Drucker zugeordnet
Benachrichtigung Benutzer *Nichtzutreffendes bitte streichen
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
_______________________________________________________________________
Anlagen zum SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 25.09.2007
Anlage A5: Beteiligte Personen und Aufgaben für das Modul HR
Systembetreiber = Herr Rassmann Anwendungseigner = Herr Dr. Juretzka / Herr PD Dr. Pietrzyk Geschätsprozessinhaber/in = Frau Klages / Frau Dr. Tobinsky Anwendungsbetreuer/in (Verfahrensebene) = Frau Schramm-Urbansky / Frau Gaedtke Anwendungsbetreuer (Technikebene) = Herr Wiebersiek / Herr Hochdorfer Key-User/in = Frau Faupel, Frau Freiboth, Frau Otte, Frau Schneider/ Herr Karic´, Herr Schüttler / Herr Beschnitt, Frau Heise, Herr Kreißl, Herr Rothensee
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
_______________________________________________________________________
Anlagen zum SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 25.09.2007
Anlage A6: Mitglieder des internen SAP-Prüfteams Dr. Döler (Datenschutzbeauftragter UMG) Herr Döring (UMG, G3-12, Kaufmännisches Rechnungswesen) Frau Frohne (ZUV /Abteilung Finanzen: Bereich 625: DV-Support/Modulbetreuung) Herr Hochdorfer (ZUV/DV2: Software, Administrative Systeme, Datenbanken)
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
_______________________________________________________________________
Anlagen zum SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 26.02.2008
Anlagen für die SAP-Module FI/CO/PSM zum
Sicherheitsleitfaden für SAP-Verfahren - Security Guide Line -
Georg-August-Universität Göttingen
Stiftung Öffentlichen Rechts
einschließlich der Universitätsmedizin Göttingen Medizinische Fakultät und Universitätsklinikum
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
_______________________________________________________________________
Anlagen zum SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 26.02.2008
Anlage A1: Formulare für den SAP-Zugang (ZUV) 1. Benutzerantrag für einen SAP-Arbeitsplatz 2. Verpflichtungserklärung
Benutzerantrag für einen SAP-Arbeitsplatz
Einrichtung. *
KoSt-Knoten *
zum Datum:
Leiter/in der Einrichtung: Telefon:
Zugang Abmeldung Änderung
Angaben zum Benutzer/in
Benutzer/in ist Vertreter/in: Nein: Ja: / für:
Nachfolge:für:
Anrede:
Name: *
Telefon:
E-Mail: *
Fax:
Vorname:
Titel:
gewünschte Berechtigung bitte makieren
DLZ EBP Berichtswesen SD PM PICA
Personalnr.: *
Bitte leiten Sie das Formural weiter an die Zentralverwaltung, Abteilung 6, Bereich 62 / Rechnungswesen Goßlerstr. 5/7 , 37073 Göttingen
Angaben zum PC
IP-Adresse / Arbeitsplatz Betriebssystem Zugang zu SAP vorhanden?
Um einen Zugang zu den Berichtsdaten zu erhalten, gehen Sie bitte auf den Link Verpflichtungserklärung (http://www.
uni-goettingen.de/de/sh/24827.html ), füllen das Formular aus und geben es ebenfalls an die u.g. Adresse
Datum und Unterschrift des/r Leiters/in der o. g. Einrichtung
Angelegt:
Drucker
SAP-Prod.
EBP-Prod.
Bearbeiter: Datum/Unterschrift:
Die mit einem *) gekennzeichneten Felder sind Pflichtfelder und müssen ausgefüllt werden, da sonst keineBearbeitung erfolgen kann
ja nein
zusätzliche Angaben
Reaktivierung:
Arbeitsverhältnis befristet bis unbefristet
Datengeheimnis gemäß § 5 des Niedersächsischen Datenschutzgesetzes (NDSG):V e r p f l i c h t u n g s e r k l ä r u n g
Angaben zur Person:
Einrichtung:
Berechtigung vorhanden für Knoten:
Auflistung aller Knoten für die gewünschte Berechtigung(auch bereits vorhandene):
Wahrung des Datengeheimnisses nach § 5 NDSG
Ich weiß, dass es untersagt ist, personenbezogene Daten zu einem anderen alsdem zur jeweiligen Aufgabenerfüllung gehörenden Zweck zu verarbeiten oder zuoffenbaren und dass dieses auch für die Zeit nach Beendigung der Tätigkeit gilt.
Ich weiß, dass Verstöße gegen das Datengeheimnis- in den meisten Fällen zugleich eine Verletzung der Amtspflicht bzw. derarbeitsvertraglichen Pflicht zur Verschwiegenheit darstellen können,- auch eine Verletzung spezieller Geheimhaltungsvorschriften bedeuten können,- rechtlich verfolgt und geahndet werden können (insbesondere Freiheits- oderGeldstrafen, disziplinarrechtliche Sanktionen).
Ich erkläre,- meine Pflicht zur Wahrung des Datengeheimnisses und die möglichen Folgen derPflichtverletzung zu kennen,- Datengeheimnisse zu wahren.
Ich erhalte eine Abschrift dieses Protokolls, die Abteilung Finanzen (Bereich 62) derGeorg-August-Universität Göttingen Stiftung Öffentlichen Rechts erhält diesesProtokoll im Original.
Göttingen, den ____________________________
(Vorname, Name des Antragstellers))
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
_______________________________________________________________________
Anlagen zum SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 26.02.2008
Anlage A2: Formulare für den SAP-Zugang und Auswertungen für FI/CO/PSM (UMG) 1. Einrichten eines Benutzers im Modul SAP-FI/CO/PSM 2. Änderung von Nutzerstammdaten 3. Antrag auf Auswertungen für das Rechnungswesen und für das Haushaltsmanagement 4. Änderungsantrag für Auswertungen
Formular Stand: 02.2008 1
An den Geschäftsbereich G3-12 Herrn Döring Telelift 142
Benutzerantrag für einen SAP-Arbeitsplatz im Modul FI/CO/PSM 1. Nutzerdaten
Einrichtung: Datum:
Leiter/-in der Einrichtung: Tel: Angaben zum Benutzer:
[ ] Zugang [ ] Abgang [ ] Änderung
Anrede: Titel:
Name: Vorname:
Raumnummer: …………………. Ebene: ………….. Gebäude:
Telefon: Fax:
E-Mail:
Gültig ab: ………………… bis: ……………………..
2. Hauptfunktion
Berater extern Leiter Haushaltsmanagement Buchhalter Anlagen Leiter Kreditorenbuchhaltung Buchhalter Debitoren Leiter Rechnungswesen Buchhalter Hauptbuch Sacharbeiter Drittmittel Buchhalter Kostenrechnung Sachbearbeiter Controlling Buchhalter Kreditoren mit Zahllauf Sachbearbeiter Haushaltsmanagement Buchhalter Kreditoren ohne Zahllauf Sachbearbeiter Mahnungen Buchhalter Zahlungsverkehr Sachbearbeiter Rechnungsprüfung Infouser (→ Antrag auf Auswertung für das RW) Systembetreuer und Entwickler Koordinator Rechnungswesen Vorstand/Präsidium Leiter Anlagenbuchhaltung Wirtschaftsprüfer/Revisor Leiter Debitorenbuchhaltung Sonstige (Erläuterung unter Punkt 3.) Leiter Finanzbuchhaltung
Formular Stand: 02.2008 2
3. Erläuterung der Funktion/Spezifikation der Rolle, falls Tätigkeit nicht durch Standard- funktionen beschrieben werden kann
Datum, Unterschrift (Vorgesetzter/Key User) Datum, Unterschrift (Leitung G3-11 bzw. G3-12)
4. Weitere Angaben Zugang zu SAP-vorhanden? Wird die Druckfunktion benötigt?
ja nein ja nein
5. Erledigungsvermerke
Anlegen des Benutzers im SAP-FI/CO/PSM System: Mandant:
R/3-Benutzername: Benutzergruppe:
Erledigungsvermerke: Datum Unterschrift
Benutzer in SAP eintragen/gelöscht/geändert*
Rolle/Berechtigung zugeordnet
SAP-Drucker zugeordnet
Benachrichtigung Benutzer
*Nichtzutreffendes bitte streichen
Formular Stand: 02.2008
An den Geschäftsbereich G3-73 Informationstechnologie - Administrative Dienste Telelift 141
Änderung Nutzerstammdaten: ANTRAGSTELLER/IN : Nutzername ist notwendig! ⇒ | | | | | | | | | | | | |
Löschen: Sperren: Ändern: Angaben zu Einrichtung: Zentrum/Abteilung: .......................................................................................................................................
Leiter/in Einrichtung: .......................................................................................................................................
Kostenstelle der Einrichtung: .........................................................................................................................
Angaben Nutzer/in: Name: ................................................................... Vorname: ....................................................
Akad. Titel: ...................................................................
Funktion: ...................................................................
Raum-Nr.: ................................................................... Gebäude: .....................................................
Telefon: ................................................................... Fax: ……...........................................................
Pieper: ..................................................................
E-Mail: .....................................................................................................................................................
alle Eintragungen bitte in Druckbuchstaben Im Hinblick auf den Schutz personenbezogener Daten beachten Sie bitte die Vorgaben des/der Datenschutzbeauftragten im Intranet. ............................................... ............................................... ............................................... Datum Antragsteller/in Leiter/in Einrichtung (Stempel) Bearbeitung G3-7 Informationstechnologie bearbeitet am / durch: ......................................................................................................................................
Formular Stand: 02.2008 1
An den Geschäftsbereich G3-12 Herrn Döring Telelift 142 Angaben zu Einrichtung: Zentrum/Abteilung: .......................................................................................................................................
Leiter/in Einrichtung: .......................................................................................................................................
Kostenstelle der Einrichtung: ......................................................................................................................... Angaben Nutzer/in: Name: .................................................... Vorname: ..........................................................
Akad. Titel: ....................................................
Funktion: ....................................................
Raum-Nr.: .................................................... Gebäude: ...........................................................
Telefon: .................................................... Fax: ...………….........................................
Pieper: ....................................................
E-Mail: .....................................................................................................................................................
alle Eintragungen bitte in Druckbuchstaben
Im Hinblick auf den Schutz personenbezogener Daten beachten Sie bitte die Vorgaben des/der Datenschutzbeauftragten im Intranet. ............................................... ............................................... ............................................... Datum Antragsteller/in Leiter/in Einrichtung (Stempel)
Wichtig: Wenn es den/die Nutzer/in im SAP schon gibt, hier unbedingt den Nutzernamen eintragen! Bearbeitung durch den G3-7 Informationstechnologie
Nutzer/in: | | | | | | | | | | | | | Eingerichtet am / durch: ......................................................................
Formular Stand: 02.2008 2
An den Geschäftsbereich G3-12 Herrn Döring Telelift 142 Auswertungen Kostenstellenrechnung / Haushaltsmanagement ANTRAGSTELLER/IN
Kostenstellen:
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
Sachkosten Personalkosten Anlagegüter / Investitionen .................................. ...................................... ................................................................... Datum Antragsteller/in Leiter/in der Einrichtung (Stempel) RECHNUNGSWESEN Genehmigt: Kostenstellen / Gruppen gemäß Anlage
…………………………………………………………………………………………………………………………..
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................ (Unterschrift für den G3-12) HAUSHALT UND DRITTMITTEL Genehmigt: Finanzstellen / Kostenstellen / Gruppen gemäß Anlage …………………………………………………………………………………………………………………………..
…………………………………………………………………………………………………………………………..
........................................................................................................................................................................
………………………………………………………………………………………………………………………….. (Unterschrift für den G3-11) G3-73 Informationstechnologie - Administrative Dienste
Berechtigungen eingerichtet: ............................................ ....................................................
Nutzer/in eingetr. / PW vergeben: ............................................ ....................................................
Benachrichtigung Nutzer/in: ............................................ ....................................................
Datum Unterschrift
Formular Stand: 02.2008
An den Geschäftsbereich G3-12 Herrn Döring Telelift 142 Auswertungen Kostenstellenrechung / Haushaltsmanagement Hinzufügen Löschen Kostenstellen / Finanzstellen ANTRAGSTELLER/IN Nutzername ist notwendig! ⇒ | | | | | | | | | | | | | Kostenstellen: …………………………………………………………………………………………………………………………
…………………………………………………………………………………………………………………………
…………………………………………………………………………………………………………………………
…………………………………………………………………………………………………………………………
Im Hinblick auf den Schutz personenbezogener Daten beachten Sie bitte die Vorgaben des/der Datenschutzbeauftragten im Intranet. ........................... ............................................ ....................................................................... Datum Antragsteller/in Leiter/in der Einrichtung (Stempel) RECHNUNGSWESEN Genehmigt: Kostenstellen / Gruppen gemäß Anlage
…………………………………………………………………………………………………………………………
…………………………………………………………………………………………………………………………
…………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………… (Unterschrift für den G3-12) HAUSHALT UND DRITTMITTEL Genehmigt: Finanzstellen / Kostenstellen / Gruppen gemäß Anlage
…………………………………………………………………………………………………………………………
…………………………………………………………………………………………………………………………
…………………………………………………………………………………………………………………………
…………………………………………………………………………………………………………………………
(Unterschrift für den G3-11) G3-73 Informationstechnologie - Administrative Dienste
Berechtigungen eingerichtet am: ..................................................................................................................
von: .................................................................................................................
Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts
_______________________________________________________________________
Anlagen zum SAP - Sicherheitsleitfaden der Stiftung Universität Göttingen
Stand: 26.02.2008
Anlage A3: Beteiligte Personen und Aufgaben für das Modul FI/CO/PSM:
Systembetreiber: Herr Rassmann Anwendungseigner: Herr Dr. Juretzka / Herr PD Dr. Pietrzyk Geschätsprozessinhaber/in: UMG: Herr Haack (Herr Döring / Herr Plünnecke) ZUV: Herr Ittemann (Herr Meier) Anwendungsbetreuer/in: UMG: Herr Döring (Verfahrensebene) ZUV: Herr Burmeister Anwendungsbetreuer/in: UMG: Herr Kohlhorst, Herr Degel, Herr Podworny (Technikebene) ZUV: Herr Adamitz Key-User/in: UMG: Herr Döring, Frau Düerkop, Herr Köneke, Herr Kühn, Herr Peters, Herr Semmler - Herr Behrens, Herr Knauf ZUV: Frau Frohne, Frau Krause, Frau Kressing, Herr Krückeberg, Herr Meier, Frau Uhlendorff, Frau Urban, Frau Wegner