Sicherheitsleitfaden für SAP-Verfahren · SAP-Systems verfügt, bedeutet nicht zwangsläufig, dass...

Georg-August-Universität Göttingen Stiftung Öffentlichen Rechts

__________________________________________________________________________

Sicherheitsleitfaden für SAP-Verfahren

- Security Guide Line -


einschließlich der Universitätsmedizin Göttingen Medizinische Fakultät und Universitätsklinikum

Endfassung: 24. Oktober 2007


________________________________________________________________________

_______________________________________________________________________

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


________________________________________________________________________

_______________________________________________________________________


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


________________________________________________________________________

_______________________________________________________________________


Stand: 24.10.2007 – Seite 4 von 67


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


________________________________________________________________________

_______________________________________________________________________


Stand: 24.10.2007 – Seite 5 von 67


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


________________________________________________________________________

_______________________________________________________________________


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


________________________________________________________________________

_______________________________________________________________________


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


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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:


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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:


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


________________________________________________________________________

_______________________________________________________________________


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.


_______________________________________________________________________

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



_______________________________________________________________________


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


_______________________________________________________________________


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


_______________________________________________________________________


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


_______________________________________________________________________


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:


Zugang Abgang Änderung

Anrede: Titel:

Name: Vorname:

Raumnummer: Gebäude:

Telefon: Fax:

E-Mail:

Gültig ab: bis:




Beamte Beschäftigte Auszubildende stud. / wiss. Hilfskräfte Lektoren Emeriti Verw./Vertr.-Beauftragte Gastarzt/-wissensch.

Organisationseinheiten: Bei Änderung/Abgang den vorhandenen Benutzernamen angeben:


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:



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*





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:


[ ] 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:




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:


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:



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*


Anlegen Verknüpfung PT


Benachrichtigung Benutzer *Nichtzutreffendes bitte streichen


_______________________________________________________________________


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


_______________________________________________________________________


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)


_______________________________________________________________________


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



_______________________________________________________________________


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


_______________________________________________________________________


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:


[ ] 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


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*





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


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


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


_______________________________________________________________________


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

Sicherheitsleitfaden für SAP-Verfahren · SAP-Systems verfügt, bedeutet nicht zwangsläufig, dass...

Documents

Transcript of Sicherheitsleitfaden für SAP-Verfahren · SAP-Systems verfügt, bedeutet nicht zwangsläufig, dass...