sicherheitsleitfaden für sap-verfahren (security guide line)

Microsoft Word - SAP Sicherheitsleitfaden_Endfassung.doc

Georg-August-Universitt Gttingen Stiftung ffentlichen Rechts

__________________________________________________________________________

Sicherheitsleitfaden fr SAP-Verfahren

- Security Guide Line -


einschlielich der Universittsmedizin Gttingen Medizinische Fakultt und Universittsklinikum

Endfassung: 24. Oktober 2007


________________________________________________________________________

_______________________________________________________________________ SAP - Sicherheitsleitfaden der Stiftung Universitt Gttingen

Stand: 24.10.2007 Seite 2 von 67

Inhaltsverzeichnis

1. Zielsetzung 8

1.1 Einfhrung 8

1.2 Zielgruppe 9

2. Geltungsbereich dieser Richtlinie 9

3. Gewhrleistung einer sicheren IT-Landschaft 10

3.1 Rahmenwerk fr Informationssicherheit 10

3.2 Verantwortlichkeiten fr die Einhaltung der Richtlinien 10

3.2.1 Kontrollprozesse 11

3.2.2 Eskalationsverfahren 11

3.3 Management von IT-Risiken 11

3.4 Einschrnkung des Zugangs zu SAP-Systemen durch ein Berechtigungskon-zept

12

3.5 Funktionale und organisatorische Zugriffsrechte 12

3.6 Klassifikation einzelner Abschnitte der Richtlinie 13

4. Funktionen und Verantwortlichkeiten 14

4.1 Systembetreiber 14

4.2 Geschftsprozessinhaber (Information Owner) 14

4.3 Anwendungseigner 14

4.4 Anwendungsbetreuer/Application Support (IT-Abteilung) 14

4.5 Anwendungsbetreuer (Fachabteilung) 14

4.6 Key-User 14

4.7 Endanwender 14

4.8 Helpdesk/Hotline 14

4.9 Support-Benutzer 14


________________________________________________________________________



Fortsetzung Inhaltsverzeichnis

5. Benutzer- und Kennwortverwaltung 15

5.1 Identifizierung und Authentifizierung 15

5.1.1 Benutzerkennungen 15

5.1.2 Mandanten 000 und 001 16

5.1.3 Mandant 066 17

5.1.4 Kennwortverwaltung 18

5.1.5 Weitere Systemprofilparameter 21

5.1.6 SAP-Standardbenutzer 23

5.2 Benutzerverwaltung 26

5.2.1 Organisatorische Anforderungen 26

5.2.2 SAP-Benutzergruppen 26

5.2.3 Zugang zur Systemlandschaft 27

5.2.4 Entwicklungssysteme 27

5.2.5 Durchfhrung der Benutzerverwaltung 29

5.3 Berechtigungsverwaltung 36

5.3.1 Verwendung von Rollen und Profilen 36

5.3.2 Organisatorische Einschrnkungen von Rollen 36

5.3.3 Rollenverwaltung Grundlegende Prinzipien 37

5.3.4 Anlage neuer Rollen 38

5.3.5 nderung bestehender Rollen 38

5.3.6 Lschung von Rollen 39

5.3.7 Sammelrollen 39

5.3.8 Berechtigungen fr Projekte und Business Requests 40


________________________________________________________________________




5.4 Einsatz von Notfallbenutzern 40

5.5 Funktionstrennung 41

5.6 Kritische/Sensitive Berechtigungen 41

6. Schnittstellen 42

6.1 Remote Communications (RFC & CPIC) 42

6.2 Hintergrundverarbeitung 44

6.3 Batch / Fast / Direct Input 44

6.4 BAPI 45

6.5 Legacy Systems Migration Workbench (LSMW) 46

6.6 CATT 46

6.7 Transfer-Verzeichnisse 47

7. Systemlandschaft 48

7.1 Systemkonzept 48

7.2 Mandantenkonzept 48

8. Change Management 50

8.1 Software-Logistik 51

8.1.1 Tabellenprotokollierung 52

8.1.2 Protokolle 52

8.2 Laufende Einstellungen 53

8.3 Entwicklungsrichtlinien 53

8.4 Systemffnung fr Customizing / Entwicklung 54

8.5 Remote-Zugriff fr den SAP-Support 54

8.6 Namenskonventionen 55


________________________________________________________________________




9. Schutz des Produktivsystems 55

9.1 Schutz von Tabellen 55

9.2 Schutz von Programmen 56

9.3 Logische Systemkommandos 56

9.4 Sperrung von Transaktionen 57

9.5 Queries 57

10. berwachung des Systemzugangs und von Systemaktivitten 58

10.1 Systemprotokoll 58

10.2 berwachung spezieller Benutzerkennungen 58

10.3 Datenintegritt Verbuchungsabbrche 59

10.4 Anforderungen an eine Dokumentation 59

11. Betriebssystem- und Netzwerksicherheit 59

12. Ausnahmen 59

13. Sicherstellung der Einhaltung dieser Richtlinie 60

14. Salvatorische Klausel 60

15. Inkrafttreten 60

Anhang SAP - HR 61

Anlagen


________________________________________________________________________



Anhang SAP-HR

5.1.1.3 Funktionale und mehrfach verwendete Benutzerkennungen

5.2.4.1 Qualittssicherungssysteme

5.2.4.2 Produktivsysteme

8.1.1 Tabellenprotokollierung

Anlagen

A1 Namenskonvention GAU (Georg-August-Universitt)

A2 Namenskonvention fr Benutzer/innen (HR-spezifisch)

A3 Transport und Genehmigung von Auftrgen/Aufgaben

A4 Formulare fr den HR-Zugang

A5 Beteiligte Personen und Aufgaben (HR-spezifisch)

A6 Mitglieder des internen SAP-Prfteams


________________________________________________________________________



Abkrzungen

ABAP Advanced Business Application Programming

BAPI Business Application Programming Interfaces

CATT Computer Aided Test Tool

CCMS Computing Center Management System

CPIC Common Programming Interface-Communication

CTO Change and Transport Organizer

DDIC Data Dictionary

IDOC Intermediate Document

IS Information Services

ITS Internet Transaction Server

LSMW Legacy System Migration Workbench

Q/A Quality Assurance

RFC Remote Function Call

SAP Systems, Applications, Products in Data Processing

SoD Segregation of Duty

TMS Transport Management System


________________________________________________________________________



1. Zielsetzung

1.1 Einfhrung

Um die

Vertraulichkeit,

Integritt,

Verfgbarkeit und

Authentizitt

der Daten innerhalb der SAP-Anwendungen der Universitt Gttingen sicherzustellen, mssen alle

Zugriffe auf wichtige Informationsbestnde kontrolliert und nachvollziehbar erfolgen.

Diese Richtlinie definiert ein Rahmenwerk fr Informations- und Systemsicherheit, in dem

die zugrunde liegenden Regeln,

die dafr notwendigen Prozesse,

die anschlieenden Kontrollen fr die Zugriffsrechte innerhalb eines SAP-Systems und

die hierbei zu bercksichtigenden Funktionen und Verantwortlichkeiten

erlutert werden.

Diese Richtlinie bestimmt die Standards und Minimalanforderungen an die Sicherheitseinstellungen

eines SAP-Systems gegen unberechtigten/inkorrekten Zugriff und Verletzungen des Prinzips der

minimalen Berechtigung.

Es ist nicht Aufgabe dieser Richtlinie, auf einer detaillierten, systemspezifischen Ebene die Konzepti-

on und Erstellung konkreter Berechtigungen bzw. SAP-Rollen zu beschreiben. Dies muss vom An-

wendungseigner, Geschftsprozessinhaber und Anwendungsbetreuer (s. Kapitel 4) des jeweiligen

SAP-Systems in Form konkreter, systemspezifischer Berechtigungskonzepte, die auf dieser globalen

Richtlinie aufbauen, durchgefhrt werden. Der Geschftprozessinhaber ist verantwortlich fr die Er-

stellung dieser systemspezifischen Berechtigungskonzepte, in denen alle notwendigen Prozesse zu

dokumentieren sind.


________________________________________________________________________



Der Geschftsbereich Informationstechnologie der Universittsmedizin (G3-7), die Stabsstelle Daten-

verarbeitungsangelegenheiten der Universitt (Stabsstelle DV) und die Anwendungseigner haben

sicherzustellen, dass die in dieser Richtlinie beschriebenen Regeln innerhalb aller SAP-Module imp-

lementiert werden. Die Kontrolle der Einhaltung dieser Regeln im laufenden Betrieb unterliegt sowohl

den internen Kontrollinstanzen des G3-7/IT, der Stabsstelle DV und des jeweiligen Geschftprozess-

inhaber als auch der Kontrolle der Internen Revision (IR) im Rahmen der vorgegebenen Prfaufga-

ben.

1.2 Zielgruppe

Die Richtlinie wendet sich an den folgenden Personenkreis:

1. Prsidium der Universitt und Vorstand der Universittsmedizin

2. Leitung der Geschftsbereiche/Abteilungen und SAP-Anwendungsbetreuung

3. Leitung und die an den SAP-Geschftsprozessen beteiligten Sachgebiets-

leiter/-innen des Geschftsbereichs Informationstechnologie (G3-7)

4. Leitung und die an den SAP-Geschftsprozessen beteiligten Abteilungsleiter/-innen

der Stabsstelle DV

5. Interne Revision, Datenschutzbeauftragte der Universitt und der Universittsmedizin

6. Endanwender (insbesondere 5.1.4, sofern keine gesonderten Regelungen existieren)

7. Externe SAP-Nutzer [Akademie der Wissenschaften (AdW), Studentenwerk Gttingen (STW),

Gemeinsamer Bibliotheksverbund (GBV), Gttinger Experimentallabor fr junge Leute

e. V.(XLAB)]

8. Support Benutzer

2. Geltungsbereich dieser Richtlinie

Die aktuelle Sicherheitsrichtlinie ist fr alle Bereiche der Georg-August-Universitt Gttingen, die

SAP-Anwendungen bereitstellen oder nutzen, bindend.

Sie gilt uneingeschrnkt fr das Produktivsystem und fr das Konsolidierungssystem, soweit dieses

eine 1:1-Kopie des Produktivsystems ist. Abweichungen sind zu dokumentieren.

Die Richtlinie gilt nicht fr das Testsystem, da sich in diesem nur anonymisierte Daten befinden dr-

fen.


________________________________________________________________________


Stand: 24.10.2007 Seite 10 von 67

3. Gewhrleistung einer sicheren IT-Landschaft

Die Gewhrleistung der IT-Sicherheit ist ein wesentliches strategisches IT-Ziel der Universitt Gttin-

gen Stiftung ffentlichen Rechts. Im Rahmen dieses Leitfadens wird daher auf die entsprechenden

Strategiepapiere des Prsidiums der Universitt Gttingen und des Vorstands der Universittsmedizin

verwiesen.

3.1 Rahmenwerk fr Informationssicherheit

Der SAP-Sicherheitsleitfaden ist ein Teil des Rahmenwerks fr Informationssicherheit. Als weitere

Komponenten dieses Rahmenwerks sind Policies, Direktiven, Richtlinien und Leitfden erforderlich.

Fr die Universitt Gttingen existiert folgendes Rahmenwerk zur IT-Sicherheit:

Organisationsrichtlinie zur IT-Sicherheit der Georg-August-Universitt Gttingen,

Sicherheitsrahmenrichtlinie der Georg-August-Universitt Gttingen.

Globale Komponenten (vornehmlich Policies, bergeordnete Richtlinien und Direktiven) des Rah-

menwerks werden jeweils durch die entsprechenden Gremien der Universitt bzw. durch die Gremien

der Universittsmedizin verabschiedet. Die Verabschiedung lokaler Komponenten des Rahmenwerks

hat in gegenseitiger Abstimmung mit den Leitungsgremien auf der Ebene der jeweiligen Organisati-

onseinheit zu erfolgen, es sei denn, dieser Sicherheitsleitfaden regelt ein besonderes Verfahren.

3.2 Verantwortlichkeiten fr die Einhaltung der Richtlinien

Die Verantwortlichkeit fr die Einhaltung der Richtlinien liegt bei den jeweiligen Geschftsberei-

chen/Abteilungen bzw. Organisationseinheiten.


________________________________________________________________________


Stand: 24.10.2007 Seite 11 von 67

3.2.1 Kontrollprozesse

Die Leitung des G3-7, Informationstechnologie, bzw. die Leitung der Stabsstelle DV ist verpflichtet

sicherzustellen, dass die Regeln, die in diesem Rahmenwerk fr Informationssicherheit beschrieben

sind, umgesetzt werden. Sie richten darber hinaus regelmig auszufhrende Kontrollprozesse ein,

um die Umsetzung dieser Regeln nachzuweisen und stellt ein Frhwarnsystem zur rechtzeitigen Er-

kennung und Vermeidung von IT-Risiken zur Verfgung. Diese Kontrollprozesse bedingen sowohl

technische Lsungen (z. B. Nagios, SAP-CCMS) als auch organisatorische Manahmen (regelmi-

ge Besprechungen, Audits).

3.2.2 Eskalationsverfahren

Eskalationsverfahren mssen eingeleitet werden, wenn das Problem mit der Standardvorgehenswei-

se nicht gelst werden kann. Die Einleitung erfolgt ber den festgelegten Dienstweg. Die an der Eska-

lation beteiligten Mitarbeiter fertigen in diesem Fall Abschlussberichte an, in denen die fr andere

Stellen relevanten Probleme, vorgenommenen Handlungen, Ergebnisse dieser Handlungen und so-

weit erforderlich, empfohlenen weitere Schritte zusammengefasst werden. Weiterhin geht ein Bericht

an das Prsidium der Universitt bzw. an den Vorstand der Universittsmedizin. Der Datenschutzbe-

auftragte ist zu informieren, wenn das Eskalationsverfahren in Zusammenhang mit der Verarbeitung

personenbezogener Daten steht.

3.3 Management von IT-Risiken

Um IT-Risiken zu kontrollieren, haben die Systembetreiber (s. Kapitel 4) angemessene Manahmen

zur positiven nderung der Risikosituation an der Universitt Gttingen unter Bercksichtigung einer

ausgewogenen Kosten-Nutzen-Relation, zu ergreifen. Dies geschieht unter anderem durch

Minimierung von Risiken Bestehende Risiken werden durch die Umsetzung entsprechender Sicherheitsmanahmen

minimiert. Hierzu gehren u. a. Zutrittskontrollen, Betrieb eines Ausfallrechenzentrums, Back-

up, dezentrale Datenarchivierung und Netzwerksicherheit (Virenschutz, Firewall etc.).


________________________________________________________________________


Stand: 24.10.2007 Seite 12 von 67

Akzeptanz von Risiken Ein vorhandenes Risiko, das weder minimiert noch ausgeschaltet werden kann, wird durch

die verantwortliche Organisationseinheit formal anerkannt. Als Folge hiervon mssen diese

bekannten und akzeptierten Risiken periodisch und mglichst zeitnah berwacht (z. B. durch

regelmig zu erstellende Berichte) und damit weitestgehend eingeschrnkt werden.

bertragung von Risiken In diesem Fall wird das Risiko an einen Dritten, z. B. die Umsetzung bestimmter Prozesse des

Rahmenwerks fr Informationssicherheit an einen Dienstleister durch Service Level Agree-

ments, bertragen. Die Verantwortlichkeit fr die korrekte Umsetzung der Sicherheitsstan-

dards und fr die entsprechenden Kontrollen kann nicht delegiert werden.

3.4 Einschrnkung des Zugangs zu SAP-Systemen durch ein Berechtigungskonzept

Die Einschrnkung des Zugangs zu Anwendungen, IT-Systemen und zur gesamten IT-Infrastruktur ist

eine der wichtigsten Manahmen, um einen unberechtigten Zugriff auf Geschftsdaten und in dessen

Folge deren Manipulation zu verhindern. Das in dieser Richtlinie beschriebene globale SAP-

Berechtigungskonzept beschreibt die allgemein gltigen Grundlagen an alle SAP-Plattformen und

-Applikationen, die von der Universitt Gttingen betrieben werden. Dies sind Minimalanforderungen,

welche notwendig sind, um den in den Folgekapiteln beschriebenen, unterschiedlichen Funktionen

und Verantwortlichkeiten gerecht zu werden.

3.5 Funktionale und organisatorische Zugriffsrechte

Die Tatsache, dass ein Endanwender ber die Rechte zur Ausfhrung von Funktionen innerhalb eines

SAP-Systems verfgt, bedeutet nicht zwangslufig, dass er auch die vergleichbaren organisatori-

schen Rechte besitzt. Aus diesem Grund muss sichergestellt werden, dass die innerhalb des Systems

vergebenen Zugriffsrechte die entsprechenden organisatorischen Rechte nicht berschreiten. Ausge-

nommen hiervon sind die Anwendungsbetreuer auf der Technik- und Verfahrensebene, die organisa-

tionsbergreifend ttig sind.


________________________________________________________________________


Stand: 24.10.2007 Seite 13 von 67

3.6 Klassifikation einzelner Abschnitte der Richtlinie

Die in dieser Richtlinie gemachten Vorgaben sind prinzipiell bindend, insbesondere fr alle produkti-

ven SAP-Systeme. Systemspezifische Anforderungen knnen in Teilen Abweichungen notwendig

machen, die von den zustndigen Leitungsgremien der Universitt Gttingen und der Universittsme-

dizin genehmigt werden mssen. Hierbei mssen Integritt und Konsistenz der Daten, die Nachvoll-

ziehbarkeit und Transparenz der eingesetzten Verfahren gewhrleistet sein.

Alle Abschnitte dieser Richtlinie werden entsprechend den folgenden Definitionen klassifiziert:

Verbindlich Diejenigen Abschnitte der Richtlinie, die als verbindlich gekennzeichnet sind, mssen fr alle

Bereiche der Universitt Gttingen, die SAP-Anwendungen bereitstellen oder nutzen, ent-

sprechend der gemachten Vorgaben umgesetzt werden. Abweichungen hiervon sind nicht er-

laubt. Die internen Kontrollinstanzen des Systembetreibers sowie die Interne Revision prfen

regelmig bzw. im Rahmen eines Prfauftrags (betr. Interne Revision) die Einhaltung dieser

Abschnitte der Richtlinie.

Ausdrcklich empfohlen Systemspezifische Anforderungen knnen Abweichungen in einzelnen Punkten dieser Richt-

linie notwendig machen. Die Notwendigkeit solcher Abweichungen mssen vom Anwen-

dungseigner oder Geschftprozessinhaber gegenber den zustndigen Leitungsgremien

nachgewiesen und von diesen genehmigt, nachvollziehbar dokumentiert und archiviert wer-

den.

Empfohlen Diejenigen Abschnitte dieser Richtlinie, die als empfohlen gekennzeichnet sind, sind nicht

bindend, aber die zugrunde liegenden Problemfelder mssen in systemspezifischen Konzep-

ten behandelt werden.


________________________________________________________________________


Stand: 24.10.2007 Seite 14 von 67

4. Funktionen und Verantwortlichkeiten

Fr alle SAP-Systeme sind Rollen und Verantwortlichkeiten festzulegen, die sich an dem folgenden

Organisationsschema orientieren knnen:

4.1 Systembetreiber Geschftsbereich G3-7, Informationstechnologie

4.2 Geschftsprozessinhaber (Information Owner) Abteilungsleitung/Sachgebietsleitung

4.3 Anwendungseigner - Sachgebietsleitung/Abteilungsleitung, die fr das SAP-Modul zustndig ist

- SAP-Basisbetreuung in den IT-Abteilungen

4.4 Anwendungsbetreuer/Application Support (IT-Abteilung) Kontaktperson fr Probleme der Anwendungsbetreuer in der Fachabteilung.

4.5 Anwendungsbetreuer (Fachabteilung) SAP-Anwendungsbetreuer in der Fachabteilung ist Kontaktperson fr Probleme der Endan-

wender, die vom Key-User nicht gelst werden knnen.

4.6 Key-User Erste Kontaktperson fr Endanwender innerhalb einer Organisationseinheit fr Probleme, die

im tglichen Routinebetrieb auftreten.

4.7 Endanwender

4.8 Helpdesk/Hotline

4.9 Support-Benutzer Fernwartung

Die Zuordnung der oben genannten Funktionen an die bestehende Organisationsstruktur sowie die

zugehrigen Verantwortlichkeiten sind in Anlagen geregelt.


________________________________________________________________________


Stand: 24.10.2007 Seite 15 von 67

5. Benutzer- und Kennwortverwaltung

Der Zugang von Benutzern und die Kennwortverwaltung muss grundstzlich durch entsprechende

Regelungen zur Nutzung der IT-Infrastruktur und eine Sicherheitsrichtlinie Kennwortschutz festge-

legt werden. Diese werden durch folgende Anforderungen ergnzt, falls es in den geforderten Regel-

werken hierfr keine gesonderten Festlegungen gibt.

5.1 Identifizierung und Authentifizierung

Ein SAP-Anwender muss sich an einem SAP-System mittels einer eindeutigen Benutzerkennung und

dem zugehrigen Kennwort anmelden. Dies kann auch ber ein Single-Sign-on-Verfahren erfolgen.

Indem er diese Daten eingibt, identifiziert sich der Benutzer gegenber dem SAP-System, welches

anschlieend prft, ob der Benutzer fr eine Arbeit mit dem System autorisiert ist.

5.1.1 Benutzerkennungen

5.1.1.1 Vertraulichkeit der Benutzerkennungen

Jeder Anwender ist verpflichtet, die Daten seines Benutzerkontos, besonders das Kennwort, vertrau-

lich zu behandeln und diese Daten keinem Dritten zugnglich zu machen.

5.1.1.2 Namenskonventionen fr Benutzerkennungen

Fr die Namenskonventionen der Benutzerkennungen gelten die folgenden, allgemeinen Regeln:

Benutzerkennungen fr Dialogbenutzer mssen eindeutig sein.

Jeder Benutzer darf nur ber eine einzige, ihm zuordenbare, Benutzerkennung verfgen.

Fr jede Benutzerkennung ist ein Verantwortlicher festzulegen, auch wenn die Benutzerken-

nung nicht fr eine interaktive Anmeldung verwendet wird.


________________________________________________________________________


Stand: 24.10.2007 Seite 16 von 67

Alle Benutzerkennungen mssen regelmig vom Anwendungsbetreuer (Verfahrensebene) auf die

Einhaltung der Namenskonventionen berprft werden. Abweichungen von den Namenskonventionen

sind zu klren und unverzglich zu korrigieren.

Fr einzelne Bereiche (ZUV) existieren Namenskonventionen (s. Anlage A2).

5.1.1.3 Funktionale und mehrfach verwendete Benutzerkennungen ( s. Anhang HR)

Aufgrund der SAP-Lizenzvereinbarungen ist die gleichzeitige Verwendung einer Benutzerkennung

durch mehrere Anwender grundstzlich verboten. ber diese vertragliche Regelung hinaus drfen

keine funktionalen bzw. anonymisierten Benutzerkennungen im Rahmen dieser Richtlinie verwendet

werden, um eine eindeutige Identifikation von Benutzern und die Nachvollziehbarkeit von deren Aktivi-

tten (z. B. die Ausfhrung von Transaktionen, Programmen, Hintergrundjobs) innerhalb der Anwen-

dungen und IT-Systeme zu gewhrleisten.

Ausnahmen aufgrund spezieller technischer Voraussetzungen oder Anforderungen aus (operativen)

Geschftsprozessen mssen vom hierfr zustndigen Anwendungsbetreuer (Verfahrensebene) ge-

nehmigt werden.

Fr die Hintergrund- und/oder Schnittstellenverarbeitung (s. a. Kapitel 6) knnen funktionale und ge-

meinsam verwendete Benutzerkennungen genutzt werden, da Systemdaten verarbeitet werden. Die-

se Verarbeitung von Systemdaten darf nicht von einer bestimmten Person bzw. deren Benutzerken-

nung abhngig sein.

Die Verwaltung von Benutzerkennungen fr die Hintergrund- bzw. Schnittstellenverarbeitung ist auf

einen bestimmten Personenkreis, der vom Anwendungseigner genehmigt werden muss, einzuschrn-

ken.

Administrative Prozesse, die sich ber den gesamten Lebenszyklus einer Benutzerkennung erstre-

cken, mssen vom Anwendungsbetreuer (Verfahrensebene) eingefhrt und regelmig berwacht

werden.

5.1.2 Mandanten 000 und 001

Der Mandant 000 und meist auch der Mandant 001 sind Referenzmandanten. Aus diesem Grund

mssen die Zugriffe auf diese beiden Mandanten eingeschrnkt werden.

Vom Anwendungseigner muss eine Liste der Benutzer und ihrer Benutzerkennungen, die innerhalb

der Mandanten 000 und 001 definiert sind, zur Verfgung gestellt werden.


________________________________________________________________________


Stand: 24.10.2007 Seite 17 von 67

Die Benutzerkennungen in den Mandanten 000 und 001 werden regelmig vom internen Prfteam

(s. Anlage A6) geprft. Hierbei wird die Liste der genehmigten Benutzerkennungen mit den tatschlich

vorhandenen Benutzerkennungen verglichen. Werden Abweichungen festgestellt, mssen die Ursa-

chen hierfr bestimmt und der in der Dokumentation festgelegte Stand wieder hergestellt werden. Die

Prfungsergebnisse und alle Berichte mssen dem Anwendungseigner zur Besttigung bersandt

und archiviert werden.

5.1.3 Mandant 066

Innerhalb des Mandanten 066 sind standardmig die SAP-Benutzerkennungen

EARLYWATCH und

SAP*

vorhanden.

Fr die Ausfhrung von Ttigkeiten innerhalb der SAP-Basis kann es notwendig sein, in Abstimmung

mit dem Anwendungseigner eine dritte Benutzerkennung einzurichten.

Die Benutzerkennungen in den Mandanten 066 werden regelmig vom internen Prfteam geprft.

Hierbei wird die Liste der genehmigten Benutzerkennungen mit den tatschlich vorhandenen Benut-

zerkennungen verglichen. Werden Abweichungen festgestellt, mssen die Ursachen hierfr bestimmt

und der in der Dokumentation festgelegte Stand wieder hergestellt werden. Die Prfungsergebnisse

und alle Berichte mssen dem Anwendungseigner zur Besttigung bersandt und archiviert werden.


________________________________________________________________________


Stand: 24.10.2007 Seite 18 von 67

5.1.4 Kennwortverwaltung

5.1.4.1 Grundlegende Kennwortregeln

Neben den kundenseitig einstellbaren Kennwortregeln (s. a. Kapitel 5.1.4.2) gibt es eine Reihe durch

SAP systemseitig vordefinierten Kennwortregeln, die nicht gendert werden knnen (s. a. aktuelle

SAP Hinweise):

Das Kennwort kann nicht lnger als 8 Zeichen lang sein.

Das erste Zeichen eines Kennworts darf kein Ausrufezeichen, Fragezeichen oder Leerzei-

chen sein.

Die ersten drei Zeichen drfen in ihrer Reihenfolge nicht in der Benutzerkennung vorkommen

(diese Regel wird nur bis SAP R/3 4.6D angewendet).

Die ersten drei Zeichen des Kennworts und der Benutzerkennung drfen nicht identisch sein.

Keines der ersten drei Zeichen darf ein Leerzeichen sein.

Dass Kennwort darf nicht PASS oder SAP* lauten.

Sofern der Benutzer sein Kennwort selbst ndern kann, muss dieses Kennwort von den letz-

ten fnf verwendeten Kennwrtern unterschiedlich sein. Im Gegensatz hierzu kann ein Admi-

nistrator ein Kennwort whlen, welches mit einem der letzten fnf Kennwrter des Benutzers

identisch ist. Diese Ausnahme ist notwendig, da ein Administrator die Kennwrter eines Be-

nutzers nicht kennen (sollte). Der Benutzer wird bei der ersten interaktiven Anmeldung sys-

temseitig zur nderung des Initialkennworts aufgefordert.

Das Kennwort kann von einem Benutzer nach dessen korrekter Eingabe gendert werden.

Ein Benutzer kann sein Kennwort maximal einmal tglich ndern; ein Administrator kann das

Kennwort eines Benutzers beliebig oft ndern.

Beim Kennwort wird nicht in Gro- und Kleinschreibung unterschieden.

nderungen der Kennwortregeln (z. B. ber eine nderung der Eintrge der Tabelle USR40)

betreffen nicht bereits vorhandene Kennwrter. Die Kennwortregeln werden nur bei der nde-

rung eines Kennworts bercksichtigt.


________________________________________________________________________


Stand: 24.10.2007 Seite 19 von 67

5.1.4.2 nderbare Kennwortregeln

ber diese systemseitig vorgegebenen Kennwortregeln hinaus gibt es die Mglichkeit, nderbare

Kennwortregeln zu verwenden und somit an kundenspezifische Anforderungen anzupassen. Die Ein-

stellung der folgenden Parameter auf die genannten Werte wird ausdrcklich empfohlen.

Mindestlnge eines Kennworts Der Parameter LOGIN/MIN_PASSWORD_LNG bestimmt die Mindestanzahl von Zeichen, die

ein Kennwort enthalten muss. Der Mindestwert ist 8, was bedeutet, dass das Kennwort 8

Zeichen enthalten muss.

Gltigkeitszeitraum eines Kennworts Der Parameter LOGIN/PASSWORD_EXPIRATION_TIME bestimmt den Zeitraum, nach dem

das Kennwort eines Dialogbenutzers oder eines ITS-Services, der die sog. Flow Logic ver-

wendet, gendert werden muss. Der Wert dieses Systemprofilparameters muss mindestens

90 betragen (ein Benutzer muss sein Kennwort nach maximal 90 Tagen ndern).

Beendigung einer SAP-Session: Der Parameter LOGIN/FAILS_TO_SESSION_END legt fest, wie viele Anmeldeversuche mg-

lich sind, bevor die SAP-Session systemseitig beendet wird. Dieser Vorgang wird als misslun-

gener Anmeldeversuch protokolliert.

Der Wert dieses Parameters muss 3 sein (die SAP-Session wird nach 3 fehlgeschlagenen

Anmeldeversuchen beendet).

Anzahl mglicher Anmeldeversuche: Der Parameter LOGIN/FAILS_TO_USER_LOCK bestimmt, wie viele fehlgeschlagene Anmel-

deversuche erlaubt sind, bevor der Benutzer systemseitig gesperrt wird.

Der Wert dieses Parameters darf 6 nicht berschreiten (der Benutzer wird nach 6 fehlge-

schlagenen Anmeldeversuchen gesperrt).

Entsperrung einer Benutzerkennung um Mitternacht: Der Parameter LOGIN/FAILED_USER_AUTO_UNLOCK muss auf den Wert 0 gesetzt wer-

den, damit Benutzer, die aufgrund fehlgeschlagener Anmeldeversuche gesperrt wurden, um

Mitternacht nicht automatisch entsperrt werden.


________________________________________________________________________


Stand: 24.10.2007 Seite 20 von 67

Automatische Abmeldung: Der Parameter RDISP/GUI_AUTO_LOGOUT legt fest, nach welchem Zeitraum in Sekunden

ein inaktiver Benutzer systemseitig abgemeldet wird. Hierbei werden nicht gesicherte Daten

(z. B. in den Eingabemasken) gelscht, wodurch es bei dieser erzwungenen Abmeldung zu

einem Datenverlust kommen kann.

Der Wert dieses Parameters darf 3600 nicht berschreiten (das SAP-System meldet einen

inaktiven Benutzer nach maximal 3600 Sekunden = 60 Minuten automatisch ab).

Der Anwendungseigner vergleicht regelmig die eingestellten Parameter mit den definierten, doku-

mentierten Werten. Abweichungen mssen identifiziert, die Ursachen hierfr ermittelt und die definier-

ten Einstellungen wieder hergestellt werden.

5.1.4.3 Tabelle der verbotenen Kennwrter

Neben den bereits dargestellten Einstellungen ber Systemprofilparameter, knnen in der Tabelle

USR40 unzulssige Kennwrter (z. B. triviale Kennwrter oder einfache Zeichenkombinationen) defi-

niert werden. Diese Liste muss in jedem System erstellt und gepflegt werden. Sie muss mindestens

Wochentage,

Monate,

Lnder,

Feiertage,

Jahreszeiten,

hufig verwendete Vornamen,

Automarken,

wichtige Stdte usw.

enthalten.


________________________________________________________________________


Stand: 24.10.2007 Seite 21 von 67

5.1.4.4 Initialkennwrter

Initialkennwrter werden bei der Anlage einer Benutzerkennung oder nach der Rcksetzung eines

Benutzerkennworts erzeugt. Bei der ersten oder einer erneuten Anmeldung des Benutzers muss die-

ser das Initialkennwort durch ein benutzerdefiniertes Kennwort ersetzen.

Fr die Erzeugung von Initialkennwrtern sollte nur der in SAP vorhandene Kennwort-Assistent ver-

wendet werden.

5.1.5 Weitere Systemprofilparameter

Neben den Systemprofilparametern, die bereits in Kapitel 5.1.4.2 dargestellt wurden, gibt es weitere

Einstellungen, welche fr das Mindestma an Sicherheit eines SAP-Systems notwendig sind. Sys-

temspezifische Gegebenheiten knnen unterschiedliche Einstellungen, insbesondere fr Qualittssi-

cherungs- und Entwicklungssysteme, erfordern.

Die folgenden Einstellungen sind verbindlich:

Deaktivierung von Berechtigungsprfungen ber die Transaktionen SU25 oder AUTH_SWITCH_OBJECTS knnen Berechtigungspr-

fungen fr bestimmte Berechtigungsobjekte global deaktiviert werden. Um dies zu verhindern,

muss der Systemprofilparameter AUTH/OBJECT_DISABLING_ACTIVE auf den Wert N ge-

setzt werden.

Berechtigungsprfungen knnen ber den Systemprofilparameter

AUTH/NO_CHECK_IN_SOME_CASES unterdrckt werden. Die Anzahl der Berechtigungs-

prfungen, die seitens SAP vorgeschlagen werden, knnen ber die Transaktion SU24 ver-

ringert werden. Dies setzt voraus, dass der Systemprofilparameter den Wert Y fr die Deak-

tivierung von Berechtigungsprfungen annimmt.

Sofern der Profilgenerator (PFCG) eingesetzt wird, muss der Wert auf Y gesetzt werden.

Aus diesem Grund darf die Transaktion SU24 nur an einen vorher genau definierten Kreis an

Personen vergeben werden.


________________________________________________________________________


Stand: 24.10.2007 Seite 22 von 67

Berechtigungsprfungen fr Remote Function Calls (RFCs) Der Systemprofilparameter AUTH/RFC_AUTHORITY_CHECK steuert, ob whrend Remote

Function Calls (RFCs) Berechtigungsprfungen auf das Berechtigungsobjekt durchgefhrt

werden. Der Wert dieses Systemprofilparameters muss auf 1 gesetzt werden, d. h. die Be-

rechtigungsprfung fr RFC-Aufrufe ist aktiv.

Die folgenden Einstellungen werden ausdrcklich empfohlen:

Mehrfachanmeldungen von Dialogbenutzern mit

einer einzigen Benutzerkennung verhindern Ein Benutzer sollte sich ber einen SAPGUI an einem SAP-System grundstzlich nur einmal

anmelden knnen. Gleiches gilt fr die Mehrfachanmeldung von einem Frontend-Rechner

aus, wobei der Benutzer immer noch die Mglichkeit hat, whrend einer Anmeldung mehrere

SAP-Sessions zu ffnen. Deshalb muss der Systemprofilparameter

LOGINDISABLE_MULTI_GUI_

LOGIN auf den Wert 1 gesetzt werden (mehrfache Dialoganmeldungen werden dadurch ver-

hindert). Sollten aus bestimmten Grnden fr genau definierte Benutzer Mehrfachanmeldun-

gen notwendig sein, knnen diese ber den Systemprofilparameter

LOGIN/MULTI_LOGIN_USERS gesetzt werden.

Keine automatische Erzeugung des Benutzers SAP* Der Parameter LOGIN/NO_AUTOMATIC_USER_SAPSTAR sollte auf den Wert 1 gesetzt

werden (s. a. Kapitel 5.1.6.1).

Systemprofilparameter fr die berwachung und Protokollierung von Tabellen-

nderungen (s. a. Kapitel 8.1.1 ff): rec/client

RECCLIENT

Die folgenden Einstellungen werden empfohlen:

Berechtigungsprfung fr ABAP/4-Sprachbefehle Der Systemprofilparameter AUTH/SYSTEM_ACCESS_CHECK_OFF ermglicht es, Berechtigungs-

prfungen fr bestimmte ABAP-Sprachbefehle, z. B. den Aufruf von Kernel-Funtionen oder CPI-C-

Aufrufe zu deaktivieren.

Der empfohlene Parameterwert ist 0 (die Berechtigungsprfung fr bestimmte ABAP-Sprachbefehle


________________________________________________________________________


Stand: 24.10.2007 Seite 23 von 67

ist aktiv).

Fr alle in dieser Richtlinie genannten (Systemprofil-)Parameter mssen die notwendigen Einstellun-

gen definiert und dokumentiert werden. Vom Anwendungseigner mssen Prozesse fr nderungen

an diesen Einstellungen konzipiert und umgesetzt werden. Der Anwendungseigner berwacht regel-

mig die in dieser Richtlinie beschriebenen Systemprofilparameter und deren Werte. Werden Abwei-

chungen in den vorgeschriebenen Einstellungen entdeckt, mssen die notwendigen Werte wieder

hergestellt und die Ursachen hierfr bestimmt werden. Darauf aufbauend mssen Manahmen einge-

leitet werden, die eine nochmalige, unautorisierte nderung dieser Einstellungen verhindern. Alle Do-

kumente, die whrend der berwachung der Einstellungen erzeugt werden, mssen vom Anwen-

dungseigner archiviert werden.

5.1.6. SAP-Standardbenutzer

Es gibt mindestens vier SAP-Standardbenutzer in einem SAP-System, deren Funktionen im Folgen-

den beschrieben werden. Diese Standardbenutzer mssen im Rahmen technischer und organisatori-

scher Manahmen vor einem unautorisierten Zugriff geschtzt werden.

Der Anwendungseigner ist verpflichtet, ein Konzept fr den Schutz vor unautorisierten Zugriffen auf

diese SAP-Standardbenutzer zu erstellen. Die Umsetzung der unten genannten Anforderungen wird

ausdrcklich empfohlen, wobei Abweichungen in Qualittssicherungs- und Entwicklungssystemen

mglich sind.

Die weiter unten angefhrten Einstellungen mssen vom Anwendungseigner regelmig berprft

werden. Abweichungen von diesen Einstellungen mssen untersucht und fr die Wiederherstellung

der Einstellungen entsprechende Manahmen eingeleitet werden. Eine bersicht dieser Einstellun-

gen und soweit verfgbar der eingeleiteten Manahmen muss vom Anwendungseigner dokumen-

tiert werden.


________________________________________________________________________


Stand: 24.10.2007 Seite 24 von 67

5.1.6.1 SAP*

Zum Schutz des SAP-Standardbenutzers SAP* mssen die folgenden Manahmen ergriffen werden:

Fr den Benutzer SAP* muss ein Benutzerstammsatz angelegt werden.

Fr den Benutzer SAP* drfen keine Rollen/Profile vergeben werden.

Fr den Benutzer SAP* muss ein nicht-triviales Kennwort vergeben und an den entsprechend

autorisierten Personenkreis bermittelt werden.

Der Benutzer SAP* muss einer administrativen Benutzergruppe zugeordnet werden.

Der Benutzer SAP* ist zu sperren.

Darber hinaus muss die automatische Anlage nach der Lschung des Benutzerstammsatzes durch

Setzen des Systemprofilparameters LOGIN/NO_AUTOMATIC_USER_SAPSTAR auf den Wert 1

verhindert werden (der automatische Benutzer SAP* wird dadurch deaktiviert, s. a. Kapitel 5.1.5).

Sofern entgegen der oben genannten Regelungen ein Einsatz des SAP-Standardbenutzers SAP*

notwendig ist, muss vom Anwendungseigner ein Prozess fr einen geregelten, autorisierten Einsatz

des Benutzers SAP* (z. B. bei der Installation von Support Packages) eingefhrt werden, welche ins-

besondere die folgenden Punkte bercksichtigen:

Die Vergabe der SAP Standardprofile SAP_ALL und SAP_NEW an den Benutzer SAP* ist er-

laubt.

Dem Benutzer SAP* zugeordnete Rollen/Profile sind nach einem Einsatz zeitnah zu entzie-

hen.

Der Benutzer SAP* ist unmittelbar nach der Beendigung seiner Aktivitten zu sperren.

Die Verwendung des Benutzers SAP* ist zu dokumentieren.

5.1.6.2 SAPCPIC

Der Benutzer SAPCPIC wird bei der Installation als SAP-Standardbenutzer angelegt und kann nicht

fr Dialoganmeldungen genutzt werden. Er wird von einigen Programmen und Funktionsbausteinen

fr die Systemkommunikation verwendet.

Um diesen Benutzer zu schtzen, wird das bekannte Standardkennwort dieses Benutzers gendert.

Sollte die Benutzerkennung gesperrt werden, muss vor dieser Umsetzung die aktuelle Version des

SAP Hinweises #29276 auf eventuelle Einschrnkungen bzw. Auswirkungen hin geprft werden.


________________________________________________________________________


Stand: 24.10.2007 Seite 25 von 67

5.1.6.3 DDIC

Der SAP-Standardbenutzer DDIC wird fr weite Bereiche des ABAP Dictionary und des TMS bentigt.

Aus diesem Grund bentigt dieser Benutzer umfangreiche Systemrechte, die ber die in den Benut-

zerprofilen hinterlegten Rechte hinausgehen. Die Verwendung der SAP-Standardprofile SAP_ALL und

SAP_NEW fr diesen Benutzer wird ausdrcklich empfohlen.

Um diese Benutzerkennung zu schtzen, muss ein nicht-triviales Kennwort vergeben und einem hier-

fr berechtigten Personenkreis bermittelt werden. Die Benutzerkennung muss einer administrativen

Benutzergruppe zugeordnet und vom Anwendungseigner ein Konzept fr die Verwendung dieser

Benutzerkennung entworfen, implementiert und regelmig berwacht werden.

Die Verwendung der Benutzerkennung DDIC sollte sowohl systemseitig protokolliert als auch ber

organisatorische Manahmen geregelt werden. Die Benutzerkennung DDIC darf nicht fr Notfallbe-

nutzereinstze verwendet werden (s. a. Kapitel 5.4).

5.1.6.4 Early Watch

Der Benutzer EARLYWATCH ist ein Dialogbenutzer, der von SAP fr den Early Watch Service im

Rahmen der Performance-berwachung genutzt wird.

Um diese Benutzerkennung vor einem unautorisierten Zugriff zu schtzen, muss deren bekanntes

Standardkennwort gendert werden. Der Benutzer ist zu sperren und nur auf Anforderung fr die

Dauer des Systemszugriffs durch SAP wieder zu entsperren. Nach einem solchen Zugriff muss ein

neues Kennwort vergeben und die Benutzerkennung wieder gesperrt werden.

5.1.6.5 WF-BATCH

Dieser Standardbenutzer wird fr das automatische Workflow-Customizing bentigt.

Dieser Benutzer hat entsprechend den Empfehlungen der SAP den Benutzertyp System und die

SAP-Standardprofile "SAP_ALL" und "SAP_NEW". Es gelten die gleichen Absicherungen wie fr die

brigen Standardbenutzer.


________________________________________________________________________


Stand: 24.10.2007 Seite 26 von 67

5.2 Benutzerverwaltung

5.2.1 Organisatorische Anforderungen

Zur Gewhrleistung einer Funktionstrennung und der Anforderungen der internen/externen Revision

muss der Geschftprozessinhaber/Anwendungsbetreuer ein Konzept fr die Benutzerverwaltung

erstellen, welches mindestens die folgenden Punkte beinhaltet:

Benutzer drfen sich nicht selbst verwalten.

Die Verantwortlichkeiten fr die Benutzeradministration mssen transparent sein.

Die Nachvollziehbarkeit der Benutzeradministration muss sichergestellt werden.

Besondere Manahmen mssen fr die Verwaltung spezieller Benutzer (DDIC, SAP* oder Notfallbe-

nutzer) und der Benutzeradministratoren selbst ergriffen werden. Der Geschftprozessinha-

ber/Anwendungsbetreuer muss unter Bercksichtigung organisatorischer Strukturen und operativer

Anforderungen ein Konzept fr die Verwaltung aller SAP-Anwender erstellen, welches die oben ge-

nannten Anforderungen erfllt. Dabei hat der Geschftprozessinhaber/Anwendungsbetreuer einen

begrenzten Personenkreis zu bestimmen, dem die Verwaltung von Benutzern erlaubt ist.

5.2.2 SAP-Benutzergruppen

ber Benutzergruppen kann kontrolliert werden, fr welche Benutzerstammstze ein Administrator

verantwortlich ist. Benutzerkennungen, denen keine Benutzergruppe zugeordnet ist, knnen von allen

Administratoren verwaltet werden. Aus diesem Grund muss jedem Benutzer eine Benutzergruppe

zugeordnet werden. Der Anwendungseigner ist verantwortlich fr die Erstellung eines Konzepts fr

den Einsatz von Benutzergruppen. Als Minimalanforderung muss ein solches Konzept die folgenden

Benutzergruppen enthalten:

Dialogbenutzer

Technische Benutzer (Hintergrundjobs, Kommunikationsschnittstellen etc.)

Super-User (DDIC, SAP* oder Notfallbenutzer)

Benutzeradministratoren


________________________________________________________________________


Stand: 24.10.2007 Seite 27 von 67

Jedem der genannten Benutzertypen muss mindestens eine Benutzergruppe zugeordnet werden. Die

Vergabe weiterer Benutzergruppen an die gleiche Benutzerkennung ist, abhngig von organisatori-

schen oder operativen Anforderungen, erlaubt. In einem solchen Fall knnen Benutzergruppen fr die

Klassifikation spezieller Benutzer (Entwickler, Benutzer mit Customizing-Rechten etc.) innerhalb des

Reportings genutzt werden.

5.2.3 Zugang zur Systemlandschaft

Die Umsetzung der folgenden Manahmen, die den Zugang zur Systemlandschaft betreffen, wird

nachdrcklich empfohlen.

5.2.4 Entwicklungssysteme

Der Zugang zu Entwicklungssystemen muss auf die folgenden Personenkreise eingeschrnkt sein:

IT (Entwickler, Benutzer mit Customizing-Rechten etc.)

Projekt-Teams

Key-User

Endanwender drfen keinen Zugang zum Entwicklungssystem erhalten.

Fr Entwicklungssysteme mssen vom Anwendungseigner Zugangsregeln erstellt werden, in denen

die Risiken, Regeln und Verantwortlichkeiten mglicher Zugnge klar definiert sind.

Diese Regeln mssen vom Anforderer, bevor ihm Zugang zum System und/oder Zugriffsrechte ber

SAP-Rollen gewhrt werden, durch einen Antrag gegengezeichnet werden. Der Anwendungseigner

muss diese unterschriebenen Regeln so archivieren, dass alle lokalen Anforderungen erfllt werden.


________________________________________________________________________


Stand: 24.10.2007 Seite 28 von 67

5.2.4.1 Qualittssicherungssysteme ( s. Anhang HR)

Der Zugang zu Q/A-Systemen (Qualittssicherungssystemen) muss auf die folgenden Personenkrei-

se eingeschrnkt sein:

IT (Entwickler, Benutzer mit Customizing-Rechten etc.)

Support-Benutzer (Fernwartung)

Projekt-Teams

Key-User

Key-User und Anwendungsbetreuer drfen das Q/A-System zu Testzwecken verwenden. Fr diese

Key-User und Anwendungsbetreuer finden dieselben organisatorischen Einschrnkungen wie in ei-

nem produktiven System Anwendung.

Endanwender sollten grundstzlich keinen Zugang zum Q/A-System, auer zu Testzwecken, erhal-

ten.

5.2.4.2 Produktivsysteme ( s. Anhang HR)

Grundstzlich ist der Zugang zu einem Produktivsystem nicht auf einen bestimmten Personenkreis

eingeschrnkt. Es mssen jedoch funktionale und organisatorische Einschrnkungen entsprechend

den definierten Aufgaben des Benutzers vorgenommen werden.

IT-Benutzer (Entwickler, Anwender mit Customizing-Rechten etc.) besitzen innerhalb des Produktiv-

systems nur Leserechte. Ausnahmen sind in Kapitel 8.4 ber das Change-Mangagement beschrie-

ben.

End-Anwender drfen in einem Produktivsystem nicht die folgenden Rechte besitzen:

Programmierung,

nderung von Feldinhalten whrend des Programmablaufs,

Transportberechtigungen.


________________________________________________________________________


Stand: 24.10.2007 Seite 29 von 67

5.2.5 Durchfhrung der Benutzerverwaltung

Der Geschftprozessinhaber/Anwendungsbetreuer ist verpflichtet, fr alle Phasen der Benutzerver-

waltung entsprechende Prozesse zu definieren.

Zu diesem Zweck muss vom Anwendungseigner, Geschftprozessinhaber und Anwendungsbetreuer

ein angemessenes Berechtigungskonzept erstellt werden. Der Anwendungsbetreuer des Benutzers

muss sicherstellen, dass nach dem Prinzip der minimalen Berechtigung dieser nur diejenigen

Zugriffsrechte erhlt, die er fr die Ausbung seiner Ttigkeiten/Funktion bentigt.

Fr Hintergrund- und Schnittstellenbenutzer (Systembenutzer) knnen Prozesse, die sich von denen

im Folgenden unterscheiden, angewendet werden. Der Anwendungseigner muss fr diese Benutzer-

kennung passende Prozesse erstellen, welche die Anforderungen an Dokumentation, Nachvollzieh-

barkeit und Autorisierung erfllen.

5.2.5.1 Dokumentation der Benutzerverwaltung

Der Anwendungsbetreuer ist zur Einfhrung und Dokumentation von Prozessen aller Stufen des Be-

nutzer-Lebenszyklus (Anlage, nderung oder Lschung einer Benutzerkennung) verpflichtet. Durch

diese Prozesse muss gewhrleistet werden, dass jeder Benutzerantrag, genauso wie alle Genehmi-

gungen, entsprechend dokumentiert und archiviert werden.

Diese Prozesse mssen Anforderungen unterschiedlicher Systemtypen innerhalb einer SAP-

Systemlandschaft (Entwicklungs-, Q/A- und Produktivsystem) und unterschiedlicher Benutzertypen

(z. B. Dialogbenutzer, Hintergrundbenutzer) bercksichtigen.


________________________________________________________________________


Stand: 24.10.2007 Seite 30 von 67

5.2.5.2 Anlage von Benutzerkennungen

Whrend der Anlage einer Benutzerkennung mssen die folgenden Angaben gemacht werden:

Eine der Namenskonvention entsprechende Benutzerkennung (s. a. Kapitel 5.1.1.2)

Eine Benutzergruppe entsprechend dem Konzept fr Benutzergruppen (s. a. Kapitel 5.2 und

Namenskonvention der Georg-August-Universitt fr SAP)

Lizenzdaten entsprechend den Lizenzvereinbarungen

Berechtigungen (SAP-Rollen), die vom Benutzer entsprechend seiner definierten Funktionen

bentigt werden

Stammdaten des Benutzers

Da der Prozess der Benutzeranlage stark mit der Anforderung von Berechtigungen zusammenhngt,

wird fr weitere Vorgaben auf das Kapitel 5.2.5.3 verwiesen.

5.2.5.3 Zuweisung von Rollen zu Dialog-Benutzern

Der Anwendungsbetreuer ist verantwortlich dafr, Dokumentationen und Kontrollprozesse und/oder

Tools fr die Zuweisung von Rollen an Dialogbenutzer zur Verfgung zu stellen. Es mssen formale

und gut dokumentierte, IS-basierte Prozesse fr die Rollenzuweisung entsprechend der Stellenbe-

schreibung des Benutzers eingefhrt werden.

Alle Rollenantrge fr Dialogbenutzer mssen vom entsprechenden Anwendungsbetreuer gestellt

werden, da nur dieser die SAP-Rollen kennt, die ein Endanwender zur Durchfhrung seiner Aufga-

ben/Funktionen bentigt.

Der Anwendungsbetreuer muss auf die Einhaltung der Funktionstrennung achten. In der Regel kann

der Versto gegen eine Funktionstrennung nur dann akzeptiert werden, wenn die Berechtigungen zur

Durchfhrung der Aufgaben/Funktionen eines Benutzers unbedingt notwendig sind. Der Vorgesetzte

des Benutzers muss in regelmigen Abstnden die bekannte Verletzung der Funktionstrennung

berprfen und entscheiden, ob diese fr die Funktionen/Aufgaben des Benutzers nach wie vor not-

wendig ist.


________________________________________________________________________


Stand: 24.10.2007 Seite 31 von 67

Der Vorgesetzte des Benutzers ist verantwortlich fr die berprfung und Genehmigung des doku-

mentierten Benutzerantrags.

Die Genehmigung eines Rollenantrags muss mindestens einem 4-Augen-Prinzip folgen:

Im ersten Schritt muss jeder Antrag vom Vorgesetzten des Benutzers, welcher fr die Kontrol-

le und Genehmigung der dokumentierten Zutrittsanforderungen des Benutzers zustndig ist,

geprft und genehmigt werden.

Die zweite Genehmigung muss vom Geschftsprozessinhaber der angeforderten Rolle(n)

durchgefhrt werden. Fr den Fall, dass Buchungskreis-bergreifende Zugriffe angefordert

werden, muss die Abteilungsleitung/Geschftsbereichsleitung informiert werden.

Der Geschftprozessinhaber ist fr als kritisch definierte Rollen verantwortlich (s. a. Kapitel 5.3.3) und

muss entsprechend am Genehmigungsprozess beteiligt werden.

Erst nachdem alle notwendigen Genehmigungen und alle Kontrollprozesse fr eine Funktionstren-

nung ausreichend dokumentiert sind, wird die Rolle der Benutzerkennung zugewiesen.

5.2.5.4 Zuweisung von Rollen zu nicht Dialogbenutzern ( s. Anhang HR)

Fr nicht Dialogbenutzer ist ein Verantwortlicher festzulegen. Weitere Einzelheiten s. Kapitel 5.2.5.3.

5.2.5.5 Zugang externer Mitarbeiter/Dienstleister

Alle Antrge von Mitarbeitern fr den externen Zugang zu einer SAP-Anwendung mssen von folgen-

den Instanzen genehmigt werden:

Systembetreiber

Geschftsprozessinhaber


________________________________________________________________________


Stand: 24.10.2007 Seite 32 von 67

Hierzu ist bei neu einzurichtenden Zugngen ein schriftlicher Antrag erforderlich. Weiterhin gelten

folgende Regelungen:

Bei Beratern in laufenden Projekten wird der Zugang (bei bereits bestehender Genehmigung)

dokumentiert.

Der Zugang fr den SAP-Support ist grundstzlich gesperrt. Die Entsperrung ist durch den

Veranlasser zu dokumentieren.

Zugriffe auf das Konsolidierungs- und Produktivsystem sind nur in dokumentierten Ausnah-

mefllen zeitlich befristet zulssig. Weiterhin ist eine bergeordnete Freigabe durch den An-

wendungseigner erforderlich.

Der Zugriff auf personenbezogene Daten ist zuvor mit dem Datenschutzbeauftragten abzustimmen.

5.2.5.6 Sperrung von Benutzerkennungen

Eine Benutzerkennung wird gesperrt, wenn die folgenden Voraussetzungen gegeben sind:

Im Allgemeinen wird die Sperrung eines Benutzers von einem Key-User durchgefhrt, wenn

ein vom hierfr zustndigen Anwendungsbetreuer initiierter Antrag auf Basis genderter HR-

Daten vorliegt.

Eine Sperrung kann aufgrund von Falschanmeldungen vorkommen. Dies hngt von den Ein-

stellungen der in Kapitel 5.1.5 genannten Systemprofilparametern ab.

Der Anwendungseigner - in Absprache mit dem Anwendungsbetreuer - ist dazu verpflichtet,

dass Benutzerkennungen, unter denen sich innerhalb eines bestimmten Zeitraums keine Dia-

logbenutzer angemeldet haben, gesperrt werden. Es wird ausdrcklich empfohlen, dass eine

Benutzerkennung maximal 90 Tage nach der letzten Anmeldung gesperrt wird. An den Be-

nutzer muss eine entsprechende Benachrichtigung ber die Sperrung gesendet werden.


________________________________________________________________________


Stand: 24.10.2007 Seite 33 von 67

Die Sperrung der Benutzerkennungen erfolgt durch den Key-User oder durch den Anwendungsbe-

treuer (Verfahrensebene). Bei Unregelmigkeiten kann die Sperrung auch vom Anwendungseig-

ner/Anwendungsbetreuer (Technikebene) vorgenommen werden.

Um den Betrieb des Systems nicht zu gefhrden, gelten diese Regeln nicht fr die folgenden

Benutzer oder Benutzergruppen:

- Benutzer fr die Schnittstellenkommunikation,

- Benutzer fr Hintergrundprozesse (Jobnetz).

Fr (System-)Administratoren muss ein entsprechend angepasster Prozess eingefhrt und

angewendet werden.

Sofern das letzte Anmeldedatum mindestens 90 Tage zurck liegt, muss die betroffene Sach-

gebiets- bzw. Abteilungsleitung informiert werden, die darber entscheidet, ob die Benutzer-

kennung gesperrt wird oder nicht. Die Liste der Systemadministratoren muss mit dem Anwen-

dungseigner abgestimmt werden.

5.2.5.7 Entsperrung von Benutzerkennungen

Es gibt zwei Mglichkeiten, warum eine Benutzerkennung in einem SAP-System gesperrt sein kann:

Sperrung aufgrund ungltiger Anmeldeversuche und

Sperrung durch einen Key-User (individuelle Sperrung, Massensperrung).

Sofern ein Benutzer durch einen Key-User gesperrt wurde, muss ein formloser Antrag auf Entsper-

rung gestellt werden (Ausnahme: Massensperrung).

Falls eine Benutzerkennung aufgrund ungltiger Anmeldeversuche gesperrt wurde, muss der Anwen-

der den Key-User/Benutzerverwalter fr eine Entsperrung seiner Kennung bzw. fr die Erstellung

eines neuen Initialkennworts kontakten. Der Key-User/Benutzerverwalter berprft die Identitt des

Benutzers und der Benutzerkennung, basierend auf den Prozessen, die vom Anwendungseigner hier-

fr eingefhrt wurden.

Sofern der Anforderer als der Besitzer der Benutzerkennung identifiziert wurde, wird die Sperre auf-

grund ungltiger Anmeldeversuche aufgehoben und ein neues Initialkennwort erzeugt. Dieses Initial-

kennwort muss an die E-Mail-Adresse, die in den Benutzerstammdaten enthalten ist, geschickt wer-

den.


________________________________________________________________________


Stand: 24.10.2007 Seite 34 von 67

In dieser E-Mail wird der Benutzer aufgefordert, das Initialkennwort umgehend zu ndern und ber

mgliche Folgen einer verzgerten nderung informiert1. Falls ein E-Mail Versand des Initialkennwor-

tes nicht mglich ist, wird dem Benutzer das Initialkennwort persnlich ausgehndigt.

5.2.5.8 Lschung von Benutzerkennungen

Fr die Lschung von Benutzerkennungen, die nicht lnger bentigt werden, muss vom Anwen-

dungsbetreuer ein entsprechender Prozess eingefhrt werden. Bevor eine Benutzerkennung aus ei-

nem SAP-System physikalisch gelscht wird, muss sicher gestellt werden, dass

- eine Historie der Benutzerkennungen und der dazugehrigen Benutzer/Personen, welche alle

lokalen Anforderungen erfllt, einen angemessenen Zeitraum zur Verfgung steht.

- die Nachvollziehbarkeit der Business-Transaktionen (wer hat was angelegt, gendert etc.),

zumindest ber einen bestimmten Zeitraum (in der Regel 10 Jahre), gewhrleistet ist.

Diese Manahmen stellen die Transparenz, Nachvollziehbarkeit der eingesetzten Verfahren und Ein-

haltung von Prfungsanforderungen sicher.

5.2.5.9 Aktualitt von Benutzerstammdaten

Der Geschftsprozessinhaber muss Prozesse einfhren, um die Aktualitt von Benutzerstammdaten

zu gewhrleisten. Diese Prozesse mssen insbesondere die nderungen von Funktionen oder Orga-

nisationsebenen des Benutzers abdecken, da dieses im Allgemeinen zu nderungen der Berechti-

gungen des Benutzers fhrt.

Obwohl hierfr Tools zur automatisierten Aktualisierung verwendet werden knnen, ist es die Aufgabe

des Anwendungsbetreuers, zu dessen Organisationseinheit der Benutzer gehrt, dafr zu sorgen,

dass die Stammdaten, genauso wie die zugewiesenen Rollen, aktuell sind.

1 Textvorschlag. Bitte ndern Sie umgehend das Initialkennwort. Beachten Sie hierbei bitte die fr das SAP-System gltigen Kennwortregeln. Bei einer verzgerten nderung des Initialkennwortes sind Sie fr alle Aktionen verantwortlich, die unter die-sem Kennwort durchgefhrt wurden.


________________________________________________________________________


Stand: 24.10.2007 Seite 35 von 67

Sobald ein Benutzer seine Organisationseinheit wechselt, sind die Anwendungsbetreuer sowohl der

alten als auch der neuen Organisationseinheit verpflichtet zu prfen, ob die bislang vergebenen Be-

rechtigungen noch bentigt und/oder innerhalb eines bestimmten Zeitraums entzogen/eingeschrnkt

werden mssen.

Die Aktualitt von Benutzerstammdaten wird durch folgendes Verfahren berprft:

Die Fachabteilungen haben eine jhrliche Prfung zu gewhrleisten. Hierzu haben die Kostenstellen-

verantwortlichen die Angaben zu den Benutzerstammdaten zu besttigen oder zu ndern und dies

durch Unterschrift zu besttigen.

5.2.5.10 Rcksetzung von Kennwrtern

Sofern ein Benutzer ein neues Kennwort fr seine Benutzerkennung bentigt, findet der Prozess fr

die Entsperrung eines Benutzers Anwendung (s. a. Kapitel 5.2.5.7).

5.2.5.11 Technische Benutzerkennungen

Technische Benutzerkennungen (z. B. Benutzerkennungen fr die Hintergrundverarbeitung, Schnitt-

stellen etc.) mssen eindeutig von den Benutzerkennungen fr Dialogbenutzer, genauso wie von an-

deren Benutzertypen, unterschieden werden knnen. Dies muss durch

eine entsprechende Namenskonvention,

Benutzergruppen und

Rollen

gewhrleistet sein.

Fr jede Benutzerkennung muss ein Verantwortlicher definiert werden, auch wenn die betroffene Be-

nutzerkennung nicht fr eine interaktive Anmeldung verwendet wird.


________________________________________________________________________


Stand: 24.10.2007 Seite 36 von 67

5.3 Berechtigungsverwaltung

Vom Anwendungseigner, Geschftprozessinhaber und Anwendungsbetreuer mssen gemeinsam fr

alle Phasen der Berechtigungsverwaltung Prozesse definiert werden.

5.3.1 Verwendung von Rollen und Profilen

Um Geschftsdaten und -funktionen vor unberechtigten Zugriffen zu schtzen, werden SAP-

Transaktionen und Programme durch Berechtigungsprfungen geschtzt. Um eine Berechtigungspr-

fung erfolgreich zu durchlaufen, bentigt ein Benutzer die entsprechenden Berechtigungen. Berechti-

gungen werden dem Benutzer ber Rollen oder Profile, die im Benutzerstammsatz eingetragen sind,

zugewiesen.

Die Verwendung von Rollen wird ausdrcklich empfohlen. Rollen und Profile, die von SAP ausgeliefert

werden, drfen nur in gut dokumentierten Ausnahmefllen und mit Zustimmung des Anwendungseig-

ners vergeben werden. Es wird ausdrcklich empfohlen, fr den Zugriff auf SAP-Systeme kundenei-

gene Rollen fr den Zugriff auf allgemeine Funktionen/Aktivitten zu erstellen. Die gleichzeitige Ver-

wendung kundeneigener Rollen und Profile verringert die bersichtlichkeit und sollte deshalb vermie-

den werden.

5.3.2 Organisatorische Einschrnkungen von Rollen

Damit kontrolliert und berwacht werden kann, welche Benutzer die Mglichkeit fr einen Zugriff auf

ihre Daten innerhalb ihrer Organisationseinheit haben, mssen Rollen auf diese einzelnen Bereiche

beschrnkt sein. Eine Unterteilung in Organisationsebenen muss im Einzelfall vom Geschftprozess-

inhaber und den betroffenen Bereichen der Universitt definiert, umgesetzt und kontrolliert werden.

Die Akkumulation von Rollen innerhalb von Benutzerstammstzen ber verschiedene Geschftsbe-

reiche/Abteilungen hinweg ist prinzipiell mglich, wobei in einem solchen Fall die Genehmigung aller

betroffenen Organisationseinheiten notwendig ist.

Sofern Rollen Berechtigungen beinhalten, die fr mehrere Bereiche der Universitt notwendig sind

(z. B. fr den Systemsupport), knnen diese nur mit Zustimmung des Anwendungseigners und den

betroffenen Bereichen erstellt und vergeben werden.


________________________________________________________________________


Stand: 24.10.2007 Seite 37 von 67

5.3.3 Rollenverwaltung Grundlegende Prinzipien ( s. Anhang HR)

Es wird ausdrcklich empfohlen, dass die Anlage und nderung von Rollen nur im Entwicklungssys-

tem durchgefhrt wird. Die Rollen mssen innerhalb des Q/A-Systems durch den Key-

User/Anwendungsbetreuer, unter Bercksichtigung unterschiedlicher Geschftsvorflle, getestet wer-

den. Hierbei sind sowohl Positivtests (=Funktionserfllung) als auch Negativtests

(=Funktionstrennung) notwendig. Nach den Tests und einer Genehmigung werden die Rollen ber

das Transport Management System (TMS) in das Produktivsystem transportiert.

In Notfllen ist die Anlage oder nderung einer Rolle durch die Berechtigungsadministration im Pro-

duktivsystem zulssig, sofern der Anwendungseigner zugestimmt hat. Alle nderungen werden da-

nach per Down- und Upload in das Entwicklungssystem verbracht und anschlieend ber die blichen

Mechanismen des TMS in das Produktivsystem transportiert. Der Anwendungsbetreuer hat sicherzu-

stellen, dass die Rollen entsprechend den folgenden Richtlinien angelegt werden.

Alle Rollen mssen beschrieben und dokumentiert werden. Innerhalb einer Beschreibung mssen alle

durch die jeweilige Rolle zugnglichen Menpunkte und Transaktionen definiert werden. Ebenso ms-

sen mgliche Einschrnkungen dargestellt werden. Fr jede Rolle muss ein Verantwortlicher definiert

werden, der fr den Inhalt (Transaktionen, Berechtigungsobjekte, organisatorische Einschrnkungen)

und die Zuweisung der Rolle verantwortlich ist.

Fr alle Rollennderungen mssen ausreichende Dokumentationen angelegt werden.

Innerhalb einer Einzelrolle drfen keine Probleme bezglich einer Funktionstrennung auftreten.

Eine Rolle darf grundstzlich keine Berechtigungen oder Berechtigungskombinationen enthalten, die

durch den Anwendungsbetreuer kritisch oder sensitive (s. a. Kapitel 5.6) definiert wurden, sofern dies

vom Anwendungseigner nicht explizit genehmigt wurde. Eine Rolle, die kritische/sensitive Berechti-

gungen enthlt, wird automatisch als kritisch/sensitiv angesehen.

Der Geschftsprozessinhaber muss kritische/sensitive Berechtigungen und die Zuordnung der Rollen

in regelmigen Abstnden berprfen und entscheiden, ob diese immer noch bentigt werden. Ein

Bericht ber diese Untersuchungen ist an den Anwendungseigner zur Archivierung zu senden.

Einzelheiten, welche die Rollenverwaltung und den Rolleninhalt betreffen, mssen vom Geschftspro-

zessinhaber in einem spezifischen Konzept definiert werden.


________________________________________________________________________


Stand: 24.10.2007 Seite 38 von 67

Spezielle Zugriffsrechte mssen auf den Personenkreis beschrnkt sein, welcher fr das System, das

Netzwerk oder das Anwendungsmanagement und/oder die Sicherheit zustndig ist.

5.3.4 Anlage neuer Rollen

Bevor eine neue Rolle angelegt wird, muss geprft werden, ob die notwendigen Funktionalitten nicht

durch bereits vorhandene Rollen zur Verfgung gestellt werden knnen.

Antrge fr die Neuanlage einer Rolle mssen mindestens einem 4-Augen-Prinzip folgen. Der erste

Genehmiger ist der Anwendungsbetreuer der Fachabteilung. Der zweite Genehmiger ist der Ge-

schftsprozessinhaber. Sofern die nderung einer Rolle mindestens eine weitere Rolle betrifft (z. B.

bei Ableitungen), mssen die Geschftsprozessinhaber aller betroffenen Rollen ber diese nderung

informiert werden.

Vor der Neuanlage einer Rolle muss der verantwortliche Anwendungsbetreuer oder das Projektteam

zuerst den Antrag prfen, um anschlieend die eigentliche Rollenerstellung anzustoen. Der Initiator

muss eine Funktionstrennung (Segregation of Duty - SoD) und kritische/sensitive Berechtigungen

bercksichtigen.

Mssen kritische/sensitive Berechtigungen vergeben werden, entscheidet der Anwendungsbetreuer

gemeinsam mit dem Geschftsprozessinhaber, ob diese kritischen/sensitiven Berechtigungen in der

Rolle bentigt werden.

Der Anwendungsbetreuer muss die Anforderung genehmigen und besttigen, dass er/sie sich enthal-

tener kritischer/sensitiver Transaktionen bewusst ist. Die Anforderung fr die Aufnahme kritischer oder

sensitiver Berechtigungen in eine Rolle muss vom Anwendungseigner explizit genehmigt werden.

5.3.5 nderung bestehender Rollen

Antrge fr die nderung einer Rolle mssen mindestens einem 4-Augen-Prinzip folgen. Der erste

Genehmiger ist der Anwendungsbetreuer der Fachabteilung. Der zweite Genehmiger ist der Ge-

schftsprozessinhaber. Sofern die nderung einer Rolle mindestens eine weitere Rolle betrifft (z. B.

bei Ableitungen), mssen die Geschftsprozessinhaber aller betroffenen Rollen ber diese nderung

informiert werden.


________________________________________________________________________


Stand: 24.10.2007 Seite 39 von 67

Sofern die nderung einer Rolle aufgrund bestimmter Geschftsanforderungen notwendig ist, muss

der verantwortliche Anwendungsbetreuer oder das Projektteam den Rollennderungsprozess ansto-

en. Hierbei mssen Funktionstrennung (SoD) und kritische/sensitive Berechtigungen bercksichtigt

werden.

Mssen kritische/sensitive Berechtigungen vergeben werden, entscheidet der Anwendungsbetreuer

gemeinsam mit dem Anwendungseigner, ob diese kritischen/sensitiven Berechtigungen in der betrof-

fenen Rolle bentigt werden.

Der Anwendungsbetreuer muss die Anforderung genehmigen und besttigen, dass er sich enthalte-

ner kritischer/sensitiver Transaktionen bewusst ist. Die Anforderung fr die Aufnahme kritischer oder

sensitiver Berechtigungen in eine Rolle muss vom Anwendungseigner explizit genehmigt werden.

5.3.6 Lschung von Rollen

Fr die Lschung von Rollen, die nicht lnger bentigt werden, muss vom Geschftprozessinhaber

ein Prozess definiert werden. Bevor eine Rolle physisch aus einem SAP-System gelscht werden

kann, muss sichergestellt werden, dass die Nachvollziehbarkeit ihres Inhalts und die Zuordnung zu

Benutzerkennungen ber einen Zeitraum, der allen Anforderungen einer Revision erfllt, gegeben ist.

Es wird empfohlen, von zu lschenden Rollen mit den entsprechenden SAP-Funktionen einen Down-

load zu erstellen. Die Aufbewahrungsfrist betrgt 10 Jahre.

Rollen mssen im Entwicklungssystem gelscht und die Lschung auf dem blichen Weg, der im

Change Management Prozess definiert wird, transportiert werden. Diese Manahme stellt die Trans-

parenz, Nachvollziehbarkeit und Einhaltung von Prfungsanforderungen sicher.

5.3.7 Sammelrollen

Sammelrollen bestehen aus mehreren Einzelrollen. Benutzern, denen eine solche Sammelrolle zuge-

wiesen wurde, werden automatisch die entsprechenden Einzelrollen zugewiesen. Die Sammelrollen

selbst enthalten keine Berechtigungsdaten.

Bei der Verwendung von Sammelrollen finden alle bereits gemachten Regelungen fr Einzelrollen

Anwendung.


________________________________________________________________________


Stand: 24.10.2007 Seite 40 von 67

5.3.8 Berechtigungen fr Projekte und Business Requests

Sobald ein Projekt definiert und genehmigt wurde, muss durch den Projektleiter das Projektteam fest-

gelegt und dokumentiert werden sowie die fr dieses Projektteam notwendigen Berechtigungen defi-

niert werden. Fr diese Berechtigungen finden alle weiter oben gemachten Regeln und Prozesse (z.

B. kritische Transaktionen, SoD) Anwendung. Fr den Zugriff eines Mitglieds des Projektteams auf

das Entwicklungssystem ist die Genehmigung des betroffenen Anwendungseigners notwendig.

Projektberechtigungen drfen nur an die bekannten Mitglieder des Projektteams und nur fr die Dauer

des Projekts selbst vergeben werden. Projektrollen drfen nicht innerhalb eines Produktivsystems

verwendet werden.

Fr tgliche Arbeiten, die innerhalb des Produktivsystems notwendig sind, mssen whrend des Pro-

jekts entsprechende Berechtigungen definiert werden.

5.4 Einsatz von Notfallbenutzern

Fr Notflle knnen eine begrenzte Anzahl spezieller Benutzerkennungen mit umfassenden Basis-

oder Funktionsberechtigungen zur Verfgung gestellt werden:

Definition eines Notfalls:

Betrifft nicht den tglichen Betrieb,

Kommt nicht periodisch vor,

Betrifft kritische Systemkomponenten.

Alle Anforderungen fr die Verwendung einer Notfallbenutzerkennung mssen dokumentiert werden.

Diese Dokumentation muss den Grund fr den Notfalleinsatz und die notwendigen Aktivitten, die im

SAP-System durchgefhrt werden sollen, enthalten.

Die Aktivitten von Notfallbenutzern mssen systemseitig protokolliert werden.

Der Anwendungseigner muss regelmig die Effektivitt dieses Prozesses berwachen.


________________________________________________________________________


Stand: 24.10.2007 Seite 41 von 67

5.5 Funktionstrennung

Vom Geschftprozessinhaber/Anwendungsbetreuer muss eine Liste von Berechtigungen/Trans-

aktionen, die inkompatible Aufgaben und/oder Verantwortlichkeiten reprsentieren und nicht in einer

Rolle oder einem Benutzerstammsatz gemeinsam vorkommen drfen, definiert werden. Fr die Erstel-

lung einer solchen Liste inkompatibler Funktionen und Berechtigungen werden Anforderungen aus

den Geschftsprozessen und anderen Quellen bercksichtigt.

Der Geschftsprozessinhaber hat mit den entsprechenden SAP-Reports zu prfen, ob an die Benut-

zer kritische Berechtigungen/Berechtigungskonstellationen vergeben wurden.

Die Funktionstrennung untersttzt dabei die Transparenz von Geschftsprozessen zur Vermeidung

von Unregelmigkeiten, Betrug und anderer strafbarer Tatbestnde.

Aus diesem Grund muss bei jeder Rollennderung oder bei der Zuweisung von Rollen zu Benutzer-

kennungen die Einhaltung der Funktionstrennung geprft werden. Fr die Handhabung dieser Funkti-

onstrennung bei der Berechtigungs- oder Benutzerverwaltung wird auf die entsprechenden Kapitel

verwiesen.

Eine Rolle, welche eine Funktionstrennung nicht realisiert, muss vom Anwendungseigner gesondert

betrachtet werden.

Der Geschftsprozessinhaber muss regelmig innerhalb seiner Anwendung prfen, ob bislang un-

dokumentierte Probleme in Verbindung mit der Funktionstrennung vorhanden sind.

5.6 Kritische/Sensitive Berechtigungen

Neben dem Problemkreis der Funktionstrennung knnen auch einzelne Transaktionen oder Berechti-

gungen, genauso wie Transaktionskombinationen, als kritisch oder sensitive betrachtet werden. Eine

Liste kritischer/sensitiver Berechtigungen muss vom Geschftsprozessinhaber definiert werden.

Hierbei wird unterschieden nach:

Kritische Berechtigungen sind nur innerhalb der Rollen fr die Administration oder fr Notflle

erlaubt.

Sensitive Berechtigungen sind in Rollen fr spezielle Zwecke erlaubt.


________________________________________________________________________


Stand: 24.10.2007 Seite 42 von 67

Fr jede dieser Kategorien mssen angemessene Verpflichtungserklrungen vom Geschftsprozess-

inhaber eingefhrt werden.

Eine Rolle, die kritische/sensitive Berechtigungen enthlt, wird automatisch als kritisch/sensitive be-

trachtet.

Sofern Berechtigungen, die in diesen Kategorien aufgefhrt sind, in Rollen eingetragen werden sollen,

mssen vom Geschftsprozessinhaber angemessene Manahmen fr ein Risiko-Management einge-

fhrt werden.

6. Schnittstellen

Es gibt eine Vielzahl von Schnittstellen fr die Kommunikation mit SAP-Systemen. Vom Anwendungs-

eigner mssen Prozesse fr die Implementierung und Verwaltung solcher Schnittstellen erstellt wer-

den. Diese Prozesse mssen sicherstellen, dass

fr jede Schnittstelle eine Dokumentation vorhanden ist und weitergefhrt wird,

fr jede Schnittstelle ein Verantwortlicher bestimmt wird. Die Aufgaben eines solchen Schnitt-

stellen-Verantwortlichen beinhalten die Genehmigung der Verwendung dieser Schnittstelle

durch weitere Anwendungen und, falls notwendig, die Verwaltung von Benutzerkennungen

und Kennworten, die fr diese Schnittstelle verwendet werden.

6.1 Remote Communications (RFC & CPIC)

Fr die Kommunikation zwischen SAP- und externen Systemen oder Funktionsbausteinen werden der

Remote Function Call (RFC) und die CPIC-Schnittstelle verwendet. RFC ermglicht es, Anwendungen

und/oder Funktionsbausteine, die auf einem anderen System vorhanden sind, aufzurufen. Die CPIC-

Schnittstelle dient der Programm-Programm-Kommunikation zwischen einem SAP-System und einem

externen Programm oder System.

Es muss sichergestellt werden, dass sog. Schnittstellenbenutzer oder CPIC-Benutzer nur ber

diejenigen Berechtigungen verfgen, welche sie fr die Ausfhrung der Schnittstellen-Programme

bentigen. Daraus folgt, dass CPIC-Benutzern ausschlielich funktionsbezogene Rollen/Profile zuge-

ordnet werden, auch wenn dieser Benutzer nicht fr eine Dialoganmeldung verwendet werden kann.


________________________________________________________________________


Stand: 24.10.2007 Seite 43 von 67

Zustzlich mssen fr die RFC- und CPIC-Kommunikation mit einem SAP-System die folgenden

Manahmen vorgenommen werden:

Die Berechtigungen zur Verwaltung von RFC-Verbindungen mssen eingeschrnkt werden.

Nur die hierfr zustndigen Administratoren drfen ber entsprechende Berechtigungen ver-

fgen.

Es drfen nur Informationen ber Systembenutzer, nicht ber Dialogbenutzer, gespeichert

werden. RFC-Verbindungen werden im SAP-System mit den Standard-Kennwort-

mechanismen geprft. Aus diesem Grund muss sich ein Benutzer, welcher eine RFC-

Verbindung aufbauen mchte, am entfernten System mit einer gltigen Benutzerkennung und

einem Kennwort anmelden. Entweder werden diese Informationen mit der RFC-Verbindung

gepflegt (fr Systembenutzer) oder der Benutzer wird bei der Anmeldung zur Eingabe seiner

Benutzerkennung und seines Kennworts aufgefordert. Fr Dialogbenutzer drfen keinerlei In-

formationen in den RFC-Verbindungen gespeichert werden. Benutzer mit gespeicherten An-

meldedaten drfen im Zielsystem nur ber die zur Ausfhrung ihrer Ttigkeiten notwendigen,

minimalen Berechtigungen verfgen.

Der Zugang zur Tabelle RFCDES muss eingeschrnkt sein, da die fr eine RFC-Verbindung

notwendigen Informationen, einschlielich der Benutzerkennung und des Kennworts, in dieser

Tabelle hinterlegt werden.

Alle fr die Remote-Kommunikation verwendeten Benutzerkennungen mssen vom Benutzertyp

Kommunikation sein und einer speziellen Benutzergruppe zugewiesen werden.

Fr Schnittstellen-Benutzer sind grundstzlich spezielle, funktionsbezogene Rollen zu erstellen, die

insbesondere nicht an Dialogbenutzer vergeben werden drfen. Sofern technisch und organisatorisch

mglich, drfen diese Rollen nur diejenigen Berechtigungen enthalten, welche fr die Ausfhrung aller

notwendigen Aktivitten der Schnittstelle bentigt werden.

In bestimmten Fllen kann es notwendig sein, dass diesen Benutzern umfangreichere Rechte zur

Verfgung gestellt werden mssen. In einem solchen Fall muss der Anwendungseigner die Verwen-

dung solcher umfangreicherer Rollen genehmigen.

Bezglich des SAP Standardbenutzers SAPCPIC wird auf das Kapitel 5.1.6.2 verwiesen.

Vom Anwendungseigner muss ein Konzept fr die Zuordnung von Berechtigungen fr die Definition

und die Ausfhrung von Schnittstellen erstellt werden.


________________________________________________________________________


Stand: 24.10.2007 Seite 44 von 67

6.2 Hintergrundverarbeitung

Hintergrundprozesse werden fr die Automatisierung immer wieder kehrender Routineaufgaben ver-

wendet und helfen dabei, SAP-System-Ressourcen zu optimieren. Die Hintergrundverarbeitung wird

immer dann verwendet, wenn zeit- und/oder ressourcenintensive Programme whrend einer geringen

Systemlast ausgefhrt und die Aufgabe des Anstartens von Reports oder Programmen an das Sys-

tem delegiert werden sollen.

Benutzerkennungen, die fr die Hintergrundverarbeitung verwendet werden, mssen als Systembe-

nutzer (nicht Dialogbenutzer!) definiert werden und verfgen nur ber die fr die Ausfhrung von Pro-

grammen notwendigen Berechtigungen.

Fr Schnittstellen-Benutzer sind grundstzliche spezielle, funktionsbezogene Rollen zu erstellen, die

insbesondere nicht an Dialogbenutzer vergeben werden drfen. Sofern technisch und organisatorisch

mglich, drfen diese Rollen nur diejenigen Berechtigungen enthalten, welche fr die Ausfhrung aller

notwendigen Jobsteps bentigt werden.

In bestimmten Fllen kann es notwendig sein, dass diesen Benutzern umfangreichere Rechte zur

Verfgung gestellt werden mssen. In einem solchen Fall muss der Anwendungseigner die Verwen-

dung solcher umfangreicherer Rollen genehmigen.

Vom Anwendungseigner muss ein Konzept fr die Zuordnung von Berechtigungen fr die Jobdefiniti-

on und die Jobausfhrung erstellt werden.

6.3 Batch / Fast / Direct Input

Batch-Input und Fast-Input sind Standardtechniken fr die bertragung groer Datenmengen in ein

SAP-System. Eine typische Anwendung ist die periodische bertragung von Daten eines externen

Systems. Innerhalb eines Batch-Input werden alle innerhalb einer Transaktion fr die Datenintegritt

implementierten Prfungen durchgefhrt.

Da durch Batch-Inputs Daten von einem externen System in ein SAP-System importiert werden, ms-

sen alle notwendigen Manahmen ergriffen werden, um das SAP-System vor unberechtigten nde-

rungen zu schtzen.


________________________________________________________________________


Stand: 24.10.2007 Seite 45 von 67

Wird ein Batch-Input im Rahmen der Hintergrundverarbeitung ausgefhrt, wird fr die Verarbeitung

diejenige Benutzerkennung bzw. deren Berechtigungen verwendet, welche durch das die Batch-Input-

Mappe erzeugende Programm definiert wurde. Findet die Verarbeitung im Dialogmodus statt, sind

dies die Berechtigungen des aktuell angemeldeten Dialogbenutzers.

Alle Eingabedateien, die fr einen Batch-Input verwendet werden, mssen vor einem unberechtigten

Zugriff geschtzt werden.

Es wird ausdrcklich empfohlen, Batch-Input Benutzer vo

sicherheitsleitfaden für sap-verfahren (security guide line)

Documents