DSAG Prüfleitfaden ECC 6_neu

Deutschsprachige SAP-Anwendergruppe e.V.

VERSION 2.0 STAND 4. MAI 2015

Prfleitfaden SAP ERP 6.0 Best-Practice-Empfehlungen des

DSAG-Arbeitskreises Revision u. Risikomanagement

2

VERSION 2.0STAND 4.MAI 2015

DSAG e. V.Deutschsprachige SAP-Anwendergruppe

Prfleitfaden SAP ERP 6.0Best-Practice-Empfehlungen des DSAG-Arbeitskreises Revision u. Risikomanagement

DSA

G-P

R

FLEI

TFAD

EN S

AP E

RP

6.0

VER

SIO

N 2

.0, 4

. MAI

201

5

DSA

G e

. V.

3

COPYRIGHT 2015 DSAG E.V.

HINWEIS:Die vorliegende Publikation ist urheberrechtlich geschtzt (Copyright). Alle Rechte liegen, soweit nicht ausdrcklich anders gekennzeichnet, bei:

DEUTSCHSPRACHIGE SAP ANWENDERGRUPPE E.V.Altrottstrae 34 a69190 WalldorfDeutschlandFon +49 (0) 6227 358 09 58Fax +49 (0) 6227 358 09 59 www.dsag.de I [email protected]

Jedwede unerlaubte Verwendung ist nicht gestattet. Dies gilt insbesondere fr die Vervielfltigung, Bear-beitung, Verbreitung, bersetzung oder die Verwendung in elektronischen Systemen/digitalen Medien.

Die Autoren des Prfleitfadens sind fr Kritik, nderungs- und Ergnzungswnsche dankbar (bitte als Beitrag im DSAGNet unter AK Revision & Risikomanagement www.dsag.de/AK-Revision melden).

Wir weisen ausdrcklich darauf hin, dass das vorliegende Dokument nicht jeglichen Regelungs-bedarf smtlicher DSAG-Mitglieder in allen Geschftsszenarien antizipieren und abdecken kann. Insofern mssen die angesprochenen Themen und Anregungen naturgem unvollstndig bleiben. Die DSAG und die beteiligten Autoren knnen bezglich der Vollstndigkeit und Erfolgsgeeignetheit der Anregungen keine Verantwortung bernehmen. Smtliche berlegungen, Vorgehensweisen und Manahmen hinsichtlich des Verhaltens gegenber SAP verbleiben in der individuellen Eigen-verantwortung jedes DSAG-Mitglieds. Insbesondere kann dieser Leitfaden nur allgemeine Anhalts-punkte zu vertragsrechtlichen Themen geben und keinesfalls eine individuelle Rechtsberatung bei der Verhandlung und Gestaltung von Vertrgen durch IT-rechtliche Experten ersetzen.

4

INHALTSVERZEICHNIS

EINLEITUNG 6 1. SAP ERP 6.0 8

2. PRFERROLLE, BESTANDSAUFNAHME VON SAP-SYSTEM- 9 LANDSCHAFT, RICHTLINIEN U. ORGANISATIONSWEISUNGEN 2.1. Grundlagen zur Erstellung einer Prferrolle 9 2.2. Bestandsaufnahme der SAP-Systemlandschaft 9 2.3. Bestandsaufnahme der Richtlinien des Unternehmens 10

3. IDENTIFIKATION UND AUTHENTISIERUNG (ABAP-STACK) 11 3.1. Anmeldekontrollen 11 3.2. Risiken 11 3.3. Kontrollziele 11 3.4. Prfprogramm: Systemparameter fr die Anmeldekontrolle 12 3.5. Tabelle: Vorschlagswerte fr die Systemparameter der Anmeldekontrolle 15 3.6. Prfprogramm: Gltigkeitszeitraum von Benutzerkennungen 18 3.7. Prfprogramm: Sichere Konfiguration besonderer Benutzertypen 20 3.8. Prfprogramm: berwachung der Wirksamkeit des Zugriffsschutzes 25

4. AUTORISIERUNG (ABAP-STACK) 28 4.1. Berechtigungsvergabe 28 4.2. Differenzierungsmodelle fr Berechtigungskonzepte 28 4.3. Risiken 29 4.4. Kontrollziele 30 4.5. Prfprogramm: Dokumentiertes Benutzer- und Berechtigungskonzept 30 4.6. Prfprogramm: Ordnungsgeme Gestaltung von Rollen 39 4.7. Prfprogramm: Notfallbenutzerkonzept (ABAP-Stack) 41 4.8. Prfprogramm: Nutzung kritischer SAP-Standardprofile/-rollen 42 4.9. Prfprogramm: Ersetzen kritischer Vorschlagswerte im Profilgenerator 44 4.10. Prfprogramm: Ordnungsmige Berechtigungs- und Benutzerorganisation 48 4.11. Tabellen: Beispielszenarien der Organisation einer Benutzer- und 50 Berechtigungsverwaltung 4.11.1. Szenario 1: 4-Augen-Prinzip 50 4.11.2. Szenario 2: 6-Augen-Prinzip 54 4.11.3. Szenario 3: 6-Augen-Prinzip, dezentrale Benutzerverwaltung im Produktivsystem 58 4.12. Prfprogramm: Berechtigungen fr die Benutzer- und Berechtigungsverwaltung 62 4.13. Prfprogramm: Sicherheitsmechanismen zur Aktivierung der Prfung 65 von Berechtigungen

5. SYSTEMINTEGRITT AUF DER ANWENDUNGSEBENE 67 5.1. Prfprogramm: Schutz der Batch-Input-Prozesse 67

6. SYSTEMINTEGRITT MIT DEM SAP JAVA-STACK 71 6.1. berblick 71 6.2. Risiken 72 6.3. Kontrollziele 72 6.4. SAP AS Java Systemarchitektur 72 6.5. Prfprogramm: Sichere Konfiguration des SAP Java-Stack 76 6.6. Prfprogramm: Sicherheit des ICM 79 6.7. Prfprogramm: Authentisierung und Autorisierung (Java-Stack) 83 6.8. Tabelle: Vorschlagswerte fr die Systemparameter der UME-Anmeldekontrolle 90 6.9. Prfprogramm: SAP-Java-Stack-Softwareverteilung 94 6.10. SAP Enterprise Portal 95 6.11. Prfprogramm: SAP-Java-Stack-Softwareverteilung 96

DSA

G-P

R

FLEI

TFAD

EN S

AP E

RP

6.0

VER

SIO

N 2

.0, 4

. MAI

201

5

DSA

G e

. V.

5

INHALTSVERZEICHNISINHALTSVERZEICHNIS

7. SYSTEMINTEGRITT AUF DER DATENBANKEBENE 102 7.1. Interne und externe Anforderungen 102 7.2. Risiken 102 7.3. Kontrollziele 103 7.4. Prfprogramm: Absicherung von Oracle unter UNIX 103 7.5. Prfprogramm: Absicherung von Oracle unter Windows 106 7.6. Prfprogramm: Sicheres Datenbankmanagement mit Oracle 108

8. SYSTEMINTEGRITT AUF DER BETRIEBSSYSTEMEBENE 110 8.1. Interne und externe Anforderungen 110 8.2. Risiken 110 8.3. Kontrollziele 111 8.4. Prfprogramm: Systemintegritt von UNIX/Linux 111 8.5. Prfprogramm: Systemintegritt von Windows 116

9. RISIKEN AUS DEM EINSATZ VON SAP GRC 122 9.1. Access Management Prozesse 122 9.2. Anpassung von Prfungshandlungen beim Einsatz von SAP GRC Access Control 10.X 123 9.3. Neue Anforderungen an die IT-Prfung 126 9.3.1. Verlagerung der Risiken im Access Management 126 9.3.2. Neue Risiken im Access Management 126 9.3.3. Risikoarten beim Einsatz von SAP GRC 127 9.4. Prfprogramm beim Einsatz von SAP GRC Access Control 128 9.4.1. Prfung des Emergency Access Management 129 9.4.1.1. Prozess Design Emergency Access Management 129 9.4.1.2. Sicherheitskritische Parameter fr das Emergency Access Management 132 9.4.1.3. Kritische Berechtigungen und Funktionstrennung im Emergency Access Management 135 9.4.2. Prfung des User Access Management 138 9.4.2.1. Prozess Design User Access Management 138 9.4.2.2. Sicherheitskritische Parameter fr das User Access Management 141 9.4.2.3. Kritische Berechtigungen im User Access Management 144 9.4.3. Prfung des Business Role Management 144 9.4.3.1. Prozess Design Business Role Management 144 9.4.3.2. Sicherheitskritische Parameter fr das Business Role Management 148 9.4.3.3. Kritische Berechtigungen im Business Role Management 150 9.4.4. Prfung des Access Risk Analysis 152 9.4.4.1. Prozess Design Access Risk Analysis 152 9.4.4.2. Sicherheitskritische Parameter fr Access Risk Analysis 156 9.4.4.3. Kritische Berechtigungen im Access Risk Analysis 159 9.5. SoD-Risiken beim Einsatz von SAP GRC Acces Control 163

10. SAP HANA AUS REVISIONSSICHT 166 10.1. Risiken 167 10.2. Kontrollziele 168 10.3. Prfprogramm: Authentisierung und Autorisierung mit SAP HANA 169 10.4. Prfprogramm: Sichere Konfiguration der Schnittstellen von SAP HANA 179 10.5. Prfprogramm: Absicherung von SAP HANA unter Linux 181 10.6. Prfprogramm: Sicheres Datenbankmanagement mit SAP HANA 183 10.7. Prfprogramm: berwachung von Sicherheitsverletzungen und regelmige 185 berprfung potenzieller Sicherheitsschwachstellen der SAP-HANA-Server

6

EINLEITUNG

Der vorliegende Prfleitfaden des Arbeitskreises (AK) Revision u. Risikomanagement bezieht sich im Kern auf den Releasestand SAP ERP 6.0, EHP 7, innerhalb der SAP Business Suite. Ergnzt wurde der Leitfaden um Prfungshandlungen innerhalb der GRC Suite sowie bei SAP HANA. Der AK Revision u. Risikomanagement ist Teil der Deutschsprachigen SAP-Anwendergruppe e. V. (DSAG) mit Sitz in Walldorf.

Zielsetzung des Leitfadens ist es, Best-Practice-Empfehlungen fr die Prfungen von SAP-Anwen- dungen zu geben. Er aktualisiert und erweitert den im Jahr 2009 in der Version 1.0 herausgegebenen Prfleitfaden zu SAP ERP 6.0., dessen Teil 2 (Applikationsebene) nach wie vor Gltigkeit besitzt.

Die Prfhinweise in diesem Leitfaden sind als Hinweise fr einen mit SAP vertrauten Prfer gedacht. Sie sind keine verbindliche Richtlinie oder Norm. Jegliche Verantwortung fr Art, Umfang und Ergebnis externer und interner Prfungen verbleibt beim Prfer selbst. In seiner Verantwortung liegt auch die Zuordnung der ausgewhlten Prfungsschwerpunkte zu einschlgigen ISO-Normen, z.B. fr IT-Sicherheit ISO/IEC 27001, zu Rahmenwerken fr die Prfung, z.B. COSO, COBIT oder zu berufsstndischen Prfungsstandards z.B. des Instituts der Wirtschaftsprfer (IDW).

Voraussetzung ist die Erfahrung mit dem SAP-System, insbesondere mit SAP ERP 6.0, SAP GRC, SAP HANA, sowie Kenntnisse der gesetzlichen Vorschriften fr die Rechnungslegung. Zur detail-lierten Auseinandersetzung mit der SAP-Architektur verweist das Autorenteam auf die SAP-On-line-Dokumentation, auf entsprechende Literatur und Schulungskurse.

Die ausgewhlten Prfprogramme vermitteln Handlungen, die dem Prfer die Wahrnehmung der kritischen kundenspezifischen Ausprgungen, der technischen SAP-Konzepte und -Funktionen erleichtern sollen. Der notwendige Prfungsumfang muss jeweils individuell den kundenspezifi-schen organisatorischen Prozessen angepasst werden.

Der Prfleitfaden wird in Versionen fortgeschrieben.

HINWEISE ZUR HANDHABUNG DES LEITFADENS: Eine Prfungshandlung auf fehlerhafte Konfiguration der SAP-Software ist in der linken Spalte mit einem H gekennzeichnet, wenn diese ein hohes Risiko bedeutet. Dies ist als ein Hinweis fr den Prfer gedacht. Der Prfleitfaden bietet allerdings keine systematische Risikobewertung.

Bei Prfungshandlungen, die durch das SAP Audit Informationssystem (AIS) untersttzt werden, ist der betreffende AIS-Menpfad angegeben.

Mit der Einfhrung von SAP Release 4.6C wurde das AIS von einer transaktionsbasierten auf eine rollenbasierte Pflegeumgebung umgestellt. Siehe hierzu SAP-Hinweis 451960. Seit der Aufnahme des AIS in die SAP_BASIS-Komponente ist es in allen SAP-Systemen verfgbar (BW, CRM, SEM, APO etc.). Die von der SAP ausgelieferten Vorlagerollen enthalten ca. 1200 Transaktionen. Selektieren Sie hierfr im SAP-Profilgenerator nach Rollen mit dem Muster SAP*AUDITOR*.

Prfungshandlungen, die der SAP Security Optimization Self-Service untersttzt (http://service.sap.com/SOS), sind mit SOS gekennzeichnet. Text und Nummer der automatisierten Prfung sind angegeben.

DSA

G-P

R

FLEI

TFAD

EN S

AP E

RP

6.0

VER

SIO

N 2

.0, 4

. MAI

201

5

DSA

G e

. V.

7

Die Autoren der einzelnen Kapitel des neuen Leitfadens sind Mitglieder des DSAG-Arbeitskreises Revision u. Risikomanagement. Die Verffentlichung der Kapitel erfolgt jeweils separat in unregelmiger Folge. Die Verantwortung fr den Inhalt tragen die jeweiligen Autoren.

DIE AUTOREN DER BISHER VERFFENTLICHTEN KAPITEL:

Murat Bc Deloitte & Touche GmbHMarcus Bhme T-Systems International GmbHSiegfried Filla PricewaterhouseCoopers AG WirtschaftsprfungsgesellschaftFalk Huber T-Systems International GmbHRalf Kaib Exagon GmbHVojislav Kosanovic KPMG AG WirtschaftsprfungsgesellschaftJohannes Liffers PricewaterhouseCoopers AG WirtschaftsprfungsgesellschaftMartin Metz Protiviti GmbHChristoph Nickel KPMG AG WirtschaftsprfungsgesellschaftJan Stlting KPMG AG WirtschaftsprfungsgesellschaftWolfgang Storm PricewaterhouseCoopers AG, WirtschaftsprfungsgesellschaftKarl Ulber PricewaterhouseCoopers AG Wirtschaftsprfungsgesellschaft

BERSICHT DER VERFFENTLICHTEN KAPITEL:

KAPITEL TITEL AUTOR STAND

Einleitung Siegfried Filla 01.2015

1 SAP ERP 6.0 Siegfried Filla 01.2015

2 Prferrolle, Bestandsaufnahme von SAP-Systemlandschaft, Richtlinien u. Organisationsweisungen

Siegfried Filla 01.2015

3 Identifikation und Authentisierung (ABAP-Stack)

Ralf Kaib 03.2014

4 Autorisierung (ABAP-Stack) Siegfried Filla, Johannes Liffers, Wolfgang Storm, Karl Ulber

02.2015

5.1 Prfprogramm: Schutz der Batch- Input-Prozesse

Ralf Kaib 03.2014

6 Systemintegritt mit dem SAP Java-Stack Vojislav Kosanovic 12.2013

7 Systemintegritt auf der Datenbankebene Falk Huber 02.2015

8 Systemintegritt auf der Betriebs- systemebene

Christoph Nickel 03.2015

9 Risiken und Prfung von SAP GRC Murat Bc, Martin Metz 01.2015

10 SAP HANA aus Revisionssicht Marcus Bhme, Jan Stlting

03.2015

@ Copyright 2015 DSAG e. V.

8

1. SAP ERP 6.0

Nach den Produkten SAP R/1 und SAP R/2 fr die Welt der Mainframes fhrte SAP im Jahr 1992 SAP R/3 fr die neuen Client-Server-Architekturen ein. SAP R/3 umfasste neben spezifischen Industrielsungen die SAP Basis und die verschiedenen SAP Applikationen, wie z.B. Finanzwesen, Controlling, Materialwirtschaft und Personalwirtschaft. SAP R/3 wurde in dieser Systemstruktur bis Release 4.6C ausgeliefert und dann durch das sogenannte SAP R/3 Enterprise Core (R/3 Release 4.70) mit den neuen technischen Mglichkeiten des SAP Web Application Server 6.20 im Jahre 2003 abgelst. Ab 2004 wurde mit "mySAP ERP 2004" und danach mit mySAP ERP 2005 ein ganzes Bndel funktionaler Erweiterungen zur Untersttzung der Unternehmensprozesse eingefhrt (u.a. auch die sogenannte Enterprise Central Component "ECC 5.0" sowie ECC 6.0 mit den Kernmodulen von SAP R/3). Durch die ergnzende Einfhrung von SAP NetWeaver 2004 (aktuell SAP NetWeaver 7.4) konnten jetzt u.a. auch in JAVA programmierte Lsungen eingebunden werden. Darber hinaus dient SAP NetWeaver zur Integration und Weiterentwicklung heterogener Systemlandschaften mit dem Ziel, alle auch auerhalb eines SAP-Systems verarbeiteten Daten zu integrieren und so Pro-zesse systembergreifend zu steuern.

Die nachfolgende Abbildung der SAP vermittelt einen berblick ber die Entwicklung der ERP-Lsungen bis hin zu SAP ERP 6.0 als Prfungsobjekt dieses neuen Leitfadens.

Seit 2009 ist SAP ERP 6.0 Teil der SAP Business Suite und wird aktuell u.a. auch mit der neuen HANA- Datenbanklsung der SAP als SAP HANA Live for ERP angeboten. Im Verbund mit den neuen Cloud- Technologien und mobilen Applikationen ergeben sich aus Prfersicht komplexere Risikoszenarien als noch vor einigen Jahren. Soweit mglich, haben wir diesen Entwicklungen im vorliegenden Leitfaden Rechnung getragen, insbesondere durch das Kapitel SAP HANA aus Revisionssicht.

Aufgrund der Tatsache dass SAP die Wartung fr die Kernapplikationen der SAP Business Suite 7, nmlich SAP ERP 6.0, SAP Customer Relationship Management (SAP CRM) 7.0, SAP Supply Chain Management (SAP SCM) 7.0 und SAP Supplier Relationship Management (SAP SRM) 7.0, genauso wie den Betrieb der SAP Business Suite durch SAP HANA 2013 bis Dezember 2025 verlngert hat, werden wir uns in den nchsten Jahren sicherlich mit weiteren Prfungsherausforderungen inner-halb von SAP ERP 6.0 beschftigen.

DSA

G-P

R

FLEI

TFAD

EN S

AP E

RP

6.0

VER

SIO

N 2

.0, 4

. MAI

201

5

DSA

G e

. V.

9

2. PRFERROLLE, BESTANDSAUFNAHME VON SAP-SYSTEMLANDSCHAFT, RICHT- LINIEN U. ORGANISATIONSWEISUNGEN

2.1. GRUNDLAGEN ZUR ERSTELLUNG EINER PRFERROLLE

Im Rahmen einer Prfung mssen neben den fr das Unternehmen geltenden gesetzlichen Vorgaben auch die internen Compliance-Vorgaben bercksichtigt werden, wobei den gesetzlichen Vorgaben Vorrang zu gewhren ist.

Zur Durchfhrung einer SAP-Systemprfung bentigt der interne bzw. externe Prfer generell alle Anzeigeberechtigungen, die das Prfungsgebiet umfassen. Insofern ist die Einrichtung von Prfer-rollen im Vorfeld anstehender Prfungen empfehlenswert, damit bei Prfungsbeginn nicht unntige Zeit auf Anwender- und Prferseite vertan wird. Die Prferrollen sind in der Form aufzubauen, dass nur die Inhalte der zum Prfungsumfang gehrenden Bereiche angezeigt werden drfen. Dies gilt insbesondere dann, wenn gesetzliche Vorgaben im Kontext des Datenschutzes oder einer Steuer-prfung (DART-Zugriffe) zu erfllen sind.

Ist aus technischer Sicht in den Prferrollen eine nderungsfunktion/nderungstransaktion unumgnglich (z.B. Zugriff auf bestimmte Customizing-Tabellen), ist diese separat nur fr die Dauer des spezifischen Prfungsschrittes zu berechtigen.

Bentigt ein Prfer Berechtigungen (z.B. Zugriff auf Eigenentwicklungen), die denen eines Not-fallusers entsprechen, ist gem dem vorliegenden Notfalluserkonzept zu verfahren.

2.2. BESTANDSAUFNAHME DER SAP-SYSTEMLANDSCHAFT

NR.

1. Gibt es einen z.B. grafischen Gesamtberblick der SAP-Systemlandschaft?

2. Gibt es eine bersicht ber alle eingesetzten SAP-Systeme, SAP-Anwendungen und deren Releasestand?

3. Auf welchen Betriebssystemen laufen die SAP-Systeme?

4. Welche Datenbanken untersttzen die SAP-Anwendungen?

5. Gibt es ein detailliertes Diagramm der SAP-Systemarchitektur, das die Verbindun-gen der SAP-Systeme untereinander, zu den SAP Clients und die Netzverbindung in das Internet darstellt?

6. Welche Instanzen sind fr den SAP-Betrieb eingerichtet? Es ist wichtig, dass jede Instanz einer Prfung unterzogen wird.

Welche SAP-Produkte und Module sind implementiert (Bestandsverzeichnis)?

6. Gibt es eine bersicht ber verschlsselte Netzverbindungen?

10

2.3. BESTANDSAUFNAHME DER RICHTLINIEN DES UNTERNEHMENS

Die Unternehmen sind in der Vorgabe und der Gestaltung von internen Richtlinien frei. Allerdings ben gesetzliche Vorgaben und IT-Standards einen Normierungsdruck auf Inhalte und Ausprgung von IT-bezogenen Richtlinien aus.

Hier sind lediglich diejenigen Vorgaben aufgefhrt, die fr die Prfung von SAP-Systemen relevant sind. Sind sie vorhanden, untersttzt das die Prfung.

NR. UNTERNEHMENSINTERNE RICHTLINIEN UND IT-PROZESSDOKUMENTATION

1. IT-Sicherheitsrichtlinie?

2. Aktuelles, gltiges Berechtigungskonzept?

2.1. Identifikation von Benutzern?

2.2. Vorgaben zum Passwortschutz?

2.3. Festgelegte Zustndigkeiten und Rollen bei der Berechtigungsvergabe?

2.4. Zustndigkeiten und Aufgaben der Dateneigentmer sowie der Systembetreiber?

3. Ist die IT-Sicherheit von spezifischen Systemplattformen geregelt und dokumentiert, z.B. fr:

3.1. SAP Client am Arbeitsplatz (PC, Notebook)

3.2. Netzverbindungen

3.3. MS-Windows-Server

3.4. UNIX-Server

3.5. Datenbank

4. Projektrichtlinie?

5. Vorgaben fr das Software Development Life Cycle (SDLC) Management?

6. Prozessdokumentationen fr die SAP-Anwendungs- und Systemlandschaft

6.1. Customizing?

6.2. Betrieb und berwachung?

6.3. Change- und Konfigurationsmanagement?

6.4. Release-Management?

6.5. Benutzer- und Berechtigungsverwaltung?

6.6. IT-Sicherheits-Management?

6.7. Business Continuity Management?

7. Service Level Agreements zwischen den Betreibern der SAP-Systemlandschaft und den Geschftseinheiten, die die SAP-Anwendungen fr Ihre Geschftsprozesse nutzen?

8. User Help Desk?

DSA

G-P

R

FLEI

TFAD

EN S

AP E

RP

6.0

VER

SIO

N 2

.0, 4

. MAI

201

5

DSA

G e

. V.

11

3. IDENTIFIKATION UND AUTHENTISIERUNG (ABAP-STACK)

3.1. ANMELDEKONTROLLEN

Die Identifikation und Authentisierung mittels Benutzerkennung und Kennwort ist ein bliches und einfaches Verfahren. Das Verhalten des Benutzers bestimmt wesentlich die Wirksamkeit des Verfahrens. Mgliche Schwachstellen sind z.B. einfache, leicht erratbare oder auch anderen Benutzern bekannte Kennworte.

Ein weiteres fr den Benutzer komfortables Verfahren ist die Anmeldung mittels Single-Sign-On. Dabei entfllt die Anmeldung mit Benutzerkennung und Passwort; die Anmeldung erfolgt ber SAP-Anmeldetickets.

Mit zustzlichen automatisierten Regeln kann Einfluss auf die Wahl des Kennworts und auf den Umgang mit dem Kennwort genommen werden. SAP bietet eine Reihe solcher mglichen Regeln ber konfigurierbare Systemparameter an. Das Unternehmen muss diese gem den eigenen Sicherheitsvorgaben anpassen.

3.2. RISIKEN

Risiken ergeben sich vor allem aus der fehlerhaften Konfiguration der Systemeinstellungen fr die Anmeldekontrollen des SAP-Systems:

Die Systemparameter fr die Anmeldekontrollen sind nicht entsprechend dem IT-Sicher- heitskonzept des Unternehmens ausgeprgt. Sie sind unzureichend oder widersprchlich gesetzt, sodass die beabsichtigte Wirkung verfehlt wird. Sicherheitsmechanismen, die SAP zur Untersttzung der Benutzerverwaltung bereitstellt, sind nicht angemessen umgesetzt, z.B.Vorgabe des Gltigkeitszeitraums, Nutzung von Sperrkennzeichen oder von besonderen Benutzertypen und die Zuordnung zu Benutzer- gruppen. Die Sonderbenutzer, fr die SAP im Auslieferungsstand der Software bekannte Standard- kennworte vorgesehen hat, sind bei der Implementierung nicht sicher konfiguriert worden. Sicherheitsereignisse, die ein Unterlaufen der gesetzten Anmeldekontrollen bedeuten, werden nicht erkannt und verfolgt.

3.3. KONTROLLZIELE

Die Systemparameter fr die Anmeldekontrollen sind so gesetzt, dass sie in der Verbund- wirkung einen angemessenen Zugriffsschutz gewhrleisten. Die gewnschte Kennwort- qualitt wird durch automatisierte Vorgaben sichergestellt. Ein Schutz vor Angriffen auf Kennworte wird konfiguriert. Mehrfachanmeldungen werden verhindert. Gltigkeitszeitrume fr Benutzerkennungen sind definiert. Die Sonderbenutzer sind sicher konfiguriert. Sicherheitsmechanismen fr die Verwaltung von Benutzergruppen und fr besondere Benutzertypen sind aktiviert. Die Wirksamkeit der Anmeldekontrollen wird berwacht.

12

3.4. PRFPROGRAMM: SYSTEMPARAMETER FR DIE ANMELDEKONTROLLE

NR. SYSTEMPARAMETER FR DIE ANMELDEKONTROLLE

Die Systemparameter, die fr die Kennwortbildung und Anmeldung relevant sind, werden wie folgt angezeigt: AIS: System Audit Top Ten Security Reports Profilparameter anzeigen (generisch ber login/*)Oder Transaktion SPFPARAIS: System Audit Systemkonfiguration Parameter Systemparameter, bersicht mit HistorieOder Transaktion TU02AIS: System Audit Systemkonfiguration Parameter Systemparameter mit Doku.Oder Transaktion RZ11Hinweis: Die im Folgenden aufgefhrten Vorschlagswerte fr die Anmeldekontrollen sind noch einmal in der Tabelle zusammengefasst, die diesem Prfprogramm folgt.

1. Kontrollziel: Die Bildung des Kennworts unterliegt Komplexittsregeln.Risiko: Das Kennwort ist einfach und kann mit wenigen Anmeldeversuchen erraten werden. Der Benutzer verwendet wiederholt dasselbe Kennwort. Er berlistet den systemseitig erzwungenen Wechsel des Kennworts, wenn keine oder eine zu kurze Passworthistorie gewhlt ist.

1.1.H

Die Kennwortmindestlnge login/ min_password_lng ist festgelegt.Vorschlagswert: 6 ZeichenHinweis: Das SAP-System lsst eine Kennwortlnge von bis zu 40 Zeichen zu.SOS: Minimum Password Length is Too Short (0126)

1.2.H

Das Kennwort unterliegt Bildungsregeln. Die relevanten Systemparameter sind login/ password_charset, login/ min_password_ letters, login / min_password_digits und login/ min_password_specials, login/ min_pass-word_lowercase und login/ min_password_uppercase.Vorschlagswerte: Kennwort muss mindestens einen Buchstaben, eine Zahl und ein Sonderzeichen enthalten.SOS: Required Number of Digits/Letters/Special Characters in Passwords is Too Low (0129, 0130, 0131)

1.3. H

Die Anzahl Zeichen ist geregelt, in denen sich ein neues Kennwort vom alten unterscheiden muss, login/ min_password_diff.Vorschlagswert: 3, d.h. mindestens die Hlfte der vorgeschriebenen Passwortlnge.SOS: Number of Characters in Which Passwords Have to Differ is Too Low (0128)

1.4. H

Die Gre der Passworthistorie ist vorbesetzt, login/ password_history_size.Vorschlagswert: 15 Kennworte bei einem Wechsel, der alle 90 Tage erzwungen wird.

1.5. In der Tabelle USR40 sind unzulssige Kennwrter eingetragen.Hinweis: Wenn bereits ber eine Passwortbildungsregel gefordert ist, dass mindestens ein Sonderzeichen zu whlen ist, brauchen in dieser Tabelle keine Wrter aus dem Duden, auch keine Buchstaben- oder Zahlenkombinationen eingetragen zu werden.SOS: Trivial Passwords Are Not Sufficiently Prohibited (0125)

DSA

G-P

R

FLEI

TFAD

EN S

AP E

RP

6.0

VER

SIO

N 2

.0, 4

. MAI

201

5

DSA

G e

. V.

13


2. Kontrollziel: Die Gltigkeitsdauer eines Kennworts ist beschrnkt.Risiko: Benutzerkennungen verbleiben lange mit Initialkennwort. Der Benutzer kann dasselbe Kennwort monatelang verwenden. Es besteht das Risiko, dass das Initial- kennwort bekannt ist oder dass das Kennwort ausgespht worden ist.

2.1.H

Die Gltigkeitsdauer eines initialen Kennworts ist geregelt, login/ password_max_ idle_initial. Dieser Parameter zieht nicht fr die Benutzer vom Typ Service oder System.Vorschlagswert: Die Gltigkeitsdauer berschreitet nicht drei Arbeitstage.Hinweis: Dieser Systemparameter ersetzt die Profilparameter login/ password_max_new_va-lid und login/ password_max_reset_valid aus dem SAP Web Anwendungsserver 6.20 und 6.40.SOS: Users with Initial Passwords Who Have Never Logged On (0009)

2.2.H

Der Zeitpunkt fr den Kennwortnderungszwang ist vorbestimmt, login/ password_ expiration_ time.Vorschlagswert: Erzwungener Wechsel des Kennworts nach hchstens 90 Tagen.SOS: Interval for Password Change is Too Long (0127)

2.3. Die Gltigkeitsdauer eines nicht benutzten Kennworts ist geregelt, login/ password_max_idle_ productive. Dieser Parameter zieht nicht fr die Benutzer vom Typ Service oder System.Hinweis: Dieser Parameter gibt die maximale Frist an, in der ein produktives vom Benut-zer gewhltes Kennwort gltig bleibt, wenn es nicht benutzt wird. Nachdem diese Frist abgelaufen ist, kann das Kennwort nicht mehr zur Authentifizierung verwendet werden. Der Benutzeradministrator kann die Kennwortanmeldung durch Zuweisen eines neuen Initialkennworts wieder aktivieren.Vorschlagswert: Gltigkeitsdauer eines nicht benutzten Kennworts hher setzen als die Dauer fr den erzwungenen Wechsel des Kennworts (max. 180 Tage).SOS: Users with Reset Passwords Who Have Never Logged On (0140)SOS: Users Who Have Not Logged On for an Extended Period of Time (0010)

2.4. Der Benutzer muss sein Kennwort jederzeit ndern knnen.Gem der SAP-Mindesteinstellung ist dies einmal am Tag (Standardwert: 1) mglich, login/ password_change_waittime.Vorschlagswert: 1, d.h., der Benutzer muss einen Tag warten, bis er sein Kennwort wieder ndern darf.

3. Kontrollziel: Erschweren des Ausprobierens von KennwortenRisiko: Kennworte fremder Benutzerkennungen knnen ber wiederholte Anmelde- versuche ausprobiert werden.

3.1. Die maximale Anzahl der Falschanmeldungen bis zum Abbrechen des Anmeldevorgangs ist definiert, login/ fails_to_session_end.Vorschlagswert: 3 als maximale Anzahl Passwortfehlversuche bis zum Abbruch des Vorgangs.

3.2. H

Die maximale Anzahl der Falschanmeldungen bis zur Sperre der Benutzerkennung ist bestimmt, login/ fails_to_user_lock.Vorschlagswert: 5 als maximale Anzahl Passwortfehlversuche bis Sperre des Benutzers.SOS: Too Many Incorrect Logon Attempts Allowed Before a User is Locked (0133)

14


1.5. Die automatische Freischaltung der Benutzerkennungen, die wegen Falschanmeldung gesperrt wurden, ist auf Mitternacht eingeschaltet, login/ failed_user_auto_unlock (Standardwert 0).Vorschlagswert: 1, d.h. automatisches Entsperren des Benutzers ber Nacht.Hinweis: Wenn es bei dieser Standardeinstellung bleibt, mssen zustzlich die gesperrten Benutzerkennungen mit den Mitteln des SAP Audit Logs auf aufflliges Vorkommen im Zeitverlauf berwacht werden.SOS: User Locks due to Failed Logon Attempts Are Automatically Released at Midnight (0134)

4. Kontrollziel: Verhindern von MehrfachanmeldungenRisiko: Mehrere Benutzer teilen sich eine Benutzerkennung und melden sich getrennt am SAP-System an. Das ist ein Versto gegen die Lizenzbestimmungen von SAP.

4.1. Mehrfachanmeldungen sind ausgeschlossen, login/ disable_multi_gui_login (Standardwert: 1). Vorschlagswert: 1, d.h., mehrfache Anmeldung ist nicht mglich.Hinweis 1: Ausnahmebenutzer wie Administratoren oder Notfallbenutzer, denen eine Mehrfachanmeldung ermglicht werden muss, sind unter dem Systemparameter login/ multi_login_users gelistet.Hinweis 2: Das SAP-System protokolliert Mehrfachanmeldungen in der Tabelle USR41_MLD.SOS: Multiple Logons Using the Same User Id is Not Prevented (0138)

5. Kontrollziel: Die unbefugte Nutzung einer offenen SAP-Sitzung durch einen anderen als den angemeldeten Benutzer wird erschwert.Risiko: Ein Kollege nutzt die Abwesenheit des Benutzers, um an dessen Frontend einer geffneten SAP-Sitzung nicht autorisierte Transaktionen durchzufhren.

5.1. Ist ein passwortgeschtztes Abschalten der Bedienoberflche des Frontend aktiviert?

5.2. Wird die Mglichkeit der automatischen Abmeldung der SAP-Sitzung genutzt?Der Parameter rdisp/gui_auto_logout ist zweckentsprechend (ungleich 0) gesetzt. Er definiert die maximale Zeit in Sekunden bei ausbleibender Ttigkeit des angemeldeten Benutzers bis zum automatischen Abmeldung. Dies gilt nur fr SAP-GUI-Verbindungen.Wenn der Parameter auf den Standardwert 0 gesetzt ist, erfolgt keine automatische Abschaltung.SOS: Interval After Which Inactive Users Are Logged Off is Too Long (0137).

DSA

G-P

R

FLEI

TFAD

EN S

AP E

RP

6.0

VER

SIO

N 2

.0, 4

. MAI

201

5

DSA

G e

. V.

15

3.5. TABELLE: VORSCHLAGSWERTE FR DIE SYSTEMPARAMETER DER ANMELDEKONTROLLE

NR. PARAMETER SAP- MGLICHE

WERTE

SAP- VOREIN-

STELLUNG

VORSCHLAGSWERT

1. H

login/ min_password_lng 6-40 6 (statt 3)

6 (Kennwortmindestlnge)

2. login/ password_charset 0,1,2 1 1 (abwrtskompatibel)

3. H

login/ min_password_letters 0-40 0 1 (Kennwort muss min-destens einen Buchstabe enthalten.)

4.H

login/ min_password_digits 0-40 0 1 (Kennwort muss mindes-tens eine Zahl enthalten.)

5.H

login/ min_password_spe-cials

0-40 0 1 (Kennwort muss min-destens ein Sonderzeichen enthalten.)

6. login/ min_password_lower-case

0-40 0 optional

7. login/ min_password_up-percase

0-40 0 optional

8.H

login/ min_password_diff 1-40 1 3 (mindestens die Hlfte der minimalen Kennwortlnge)

9. H

login/ password_history_size 1-100 5 15 Kennworte (bei einem Wechsel, der alle 90 Tage erzwungen wird)

10. H

login/ password_max_idle_initial

0-24.000(Tage)

0 Gltigkeitsdauer fr ein initiales Kennwort ber-schreitet nicht 3 Arbeitstage.

11. H

login/ password_expirati-on_time

0-999(Tage)

0 Erzwungener Wechsel des Kennworts nach hchstens 90 Tagen.

12. login/ password_max_idle_productive

0-24.000(Tage)

0 Gltigkeitsdauer eines nicht benutzten Kennworts hher setzen als die Dauer fr den erzwungenen Wechsel des Kennworts.

13. login/ password_change_ waittime

1-1000(Tage)

1 1 (Benutzer muss einen Tag warten, bis er sein Kennwort wieder ndern darf.)

16


WERTE

SAP- VOREIN-

STELLUNG

VORSCHLAGSWERT

14. login/ fails_to_session_end 1-99 3 3 (maximale Anzahl Passwortfehlversuche bis Abbruch des Vorgangs)

15. H

login/ fails_to_user_lock 1-99 5(statt 12)

5 (maximale Anzahl Passwortfehlversuche bis Sperre des Benutzers)

16 login/ failed_user_auto_un-lock

0 oder 1 0(statt 1)

1 (automatisches Entsper-ren des Benutzers ber Nacht)

17. login/ disable_multi_gui_lo-gin

1 0 1 (mehrfache Anmeldung nicht mglich)

18. login/ multi_login_users Liste der Benutzer, fr die eine Mehrfachanmeldung mglich ist

19. login/ password_compliance_ to_current_policyZweck: Wenn ein bereits vergebenes Kennwort nicht mehr den inzwischen gen-derten Kennwortbildungsre-geln entspricht, erzwingt das System eine nderung des Kennworts bei der Anmel-dung.

0 oder 1 0 Optional

20. login/ password_downwards_compatibilityZweck: Dieser Parameter spezifiziert den Grad der Abwrtskompatibilitt z.B. der untersttzten Pass-wortlngen zu frheren SAP Releases. Details sind der technischen Dokumentation zu entnehmen.

Siehe SAP Dokumen-

tation

Optional

DSA

G-P

R

FLEI

TFAD

EN S

AP E

RP

6.0

VER

SIO

N 2

.0, 4

. MAI

201

5

DSA

G e

. V.

17


WERTE

SAP- VOREIN-

STELLUNG

VORSCHLAGSWERT

21. Tabelle USR40Beispieleintragungen:123456, qwertz, (oder andere Zeichenfolge auf der Tasta-tur) oder generisch*Montag*, *Januar*, *Som-mer*, *Passwort*, *Firmen-namen*

Abfragen auf triviale Kennworte erbrigen sich, wenn bereits kom-plexe Passwortbildungs-regeln eingestellt sind.

22. rdisp/ gui_auto_logoutDefiniert die maximale Zeit in Sekunden bei ausbleibender Ttigkeit des angemeldeten Benutzers bis zur automati-schen Abmeldung. Dies gilt nur fr SAP-GUI-Verbindun-gen.Wenn der Parameter auf den Standardwert 0 gesetzt ist, erfolgt keine automatische Abschaltung.

Jeder numeri-

sche Wert

0 Optional, aber ver-pflichtend, wenn keine automatische Frontend- Sperre eingerichtet ist (Bildschirmschoner mit PC-Sperre).

23. login/password_logon_user-group

Eine Benutzer-

gruppe

Benutzer dieser Benut-zergruppe knnen sich weiterhin mit Passwort anmelden.

24. login/ticket_expiration_time Stunden-Minuten

8:00 Ablaufzeit fr das An-meldeticket

18

3.6. PRFPROGRAMM: GLTIGKEITSZEITRAUM VON BENUTZERKENNUNGEN

NR. PRFPROGRAMM: GLTIGKEITSZEITRAUM VON BENUTZERKENNUNGEN

Wie viele Benutzer sind im Mandant registriert?AIS: System Audit Benutzer und Berechtigungen Infosystem Benutzerbersicht Anzahl Benutzerstammstze oder Tabelle USR02, keine Auswahl vornehmen, die Anzahl Treffer wird oberhalb der Ergebnisliste zwischen den Kopfzeilen des SAP-Mens angezeigt.

1. Kontrollziel: Kurze Gltigkeitsdauer von Benutzerkennungen mit Initialkennwort.Risiko: Ein Benutzer meldet sich unter einer fremden Benutzerkennung mit bekanntem Initialkennwort an.

1.1. Welche Benutzer haben sich noch nie angemeldet? Wie lange ist der Benutzer mit Initi-alkennwort schon angelegt?AIS: System Audit Benutzer und Berechtigungen Infosystem Benutzerbersicht Auswertung nach unbenutzt im Feld Letzte Anmeldungoder Tabelle USR02, Feld letztes Login-Datum mit = LEER auswhlen. Das entspricht dem Feld TRDAT in der angezeigten Liste.Alternativ kann die Transaktion SUIM oder SA38 mit dem Report RSUSR200 verwendet werden.Benutzer mit Initialkennwort mssen nach Ablauf einer Frist von wenigen Arbeitstagen automatisch gesperrt werden. Dies muss ber den Login-Parameter login/ password_max_ idle_initial erzwungen sein.SOS: Users with Initial Passwords Who Have Never Logged On (0009)SOS: Users with Reset Passwords Who Have Never Logged On (0140)

1.2. Welche Benutzer haben seit lngerer Zeit ihr Passwort nicht gendert?AIS: System Audit Benutzer und Berechtigungen Infosystem Benutzerbersicht Seit 180 Tagen Kennwort nicht gendert, ggf. Voreinstellung im Feld Tage seit Kennwortnderung berschreiben.Oder Transaktion SUIM oder SA38 mit dem Report RSUSR200. Benutzer mssen regelmig ihr Kennwort ndern. Dies muss ber den Login-Parameter login/ password_expiration_time erzwungen sein.SOS: Users Who Have Not Logged On for an Extended Period of Time (0010)

2. Kontrollziel: Alle Benutzer sind mit einem Gltigkeitszeitraum versehen, der dem Zeitraum des notwendigen Zugriffs auf das SAP-System entspricht.Risiko: Nicht mehr bentigte Benutzerkennungen werden nicht rechtzeitig erkannt und gesperrt. Sie sind anderen Benutzern bekannt, die unter dieser fremden Benutzerken-nung auf das SAP-System zugreifen knnen, wenn ihnen das Kennwort auf welche Weise auch immer bekannt geworden ist.

2.1. Fr welche Benutzer ist kein Gltigkeitszeitraum oder ein zu weit gefasster Gltigkeits-zeitraum eingetragen? AIS: System Audit Benutzer und Berechtigungen Infosystem Benutzerbersicht Benutzer nach Anmeldedatum, Auswertung nach Feld Gltig-Bis. Oder Transaktion SUIM oder SA38 mit dem Report RSUSR002.Oder ber die Tabelle USR02 ermitteln, dabei keine Auswahl vornehmen, das Ergebnis nach dem Feld GLTB, Gltig Bis, auswerten.Abgleich mit Informationen zu den Mitarbeitern, die die Personalabteilung bereitstellt.Ist z.B. fr Mitarbeiter, die Auszubildende, temporre oder externe Mitarbeiter sind, ein solches Gltig-Bis-Datum eingetragen, das dem befristeten Arbeitsverhltnis entspricht?

DSA

G-P

R

FLEI

TFAD

EN S

AP E

RP

6.0

VER

SIO

N 2

.0, 4

. MAI

201

5

DSA

G e

. V.

19


3. Kontrollziel: Besondere Zeitrume von Aktivitt oder Inaktivitt werden durch flexible Handhabung und unternehmensindividuelle Kennzeichnung der Sperrung einer Benut-zerkennung kontrolliert.Risiko: Nicht aktive Benutzerkennungen sind anderen Benutzern bekannt. Diese greifen unter dieser fremden Benutzerkennung auf das SAP-System zu, wenn sie das Kennwort ausprobiert oder ausgekundschaftet haben.

3.1. Sind unternehmensindividuelle Varianten der Sperrargumente aktiviert?Tabelle USR02, Feld UFLAG, User Sperre, mit = LEER auswhlen, das Ergebnis nach dem Inhalt von Feld UFLAG auswerten. Sind temporre Sperren aufgrund bekannter befristeter Abwesenheit eines Mitarbeiters oder besondere Sperrkennzeichnungen fr solche Mitarbeiter gesetzt, die selten die Benutzerkennung bentigen. Diese Benutzer haben i.d.R. gleichbleibende Berechtigun-gen fr einen definierten, aber temporren Auftrag, z.B. fr Aktivitten im Rahmen von Messeveranstaltungen.

4. Kontrollziel: Identifikation nicht mehr bentigter BenutzerkennungenRisiko: Benutzerkennungen ausgeschiedener Benutzer werden nicht gelscht.

4.1. Welche Benutzer haben sich ber einen lngeren Zeitraum nicht mehr angemeldet?AIS: System Audit Benutzer und Berechtigungen Infosystem Benutzerbersicht Benutzer nach Anmeldedatum oder Seit 30 Tagen nicht angemeldet,Auswertung nach dem Feld Letzte Anmeldung.Oder Transaktion SUIM oder SA38 mit dem Report RSUSR200.Oder ber die Tabelle USR02 ermitteln, dabei keine Auswahl vornehmen, das Ergebnis nach dem Feld TRDAT, letztes Login-Datum, auswerten.Abgleich mit Informationen zu den Mitarbeitern, die die Personalabteilung bereitstellt.Benutzerkennungen ausgeschiedener Mitarbeiter sind zu lschen.SOS: Users Who Have Not Logged On for an Extended Period of Time (0010)

4.2. Welche Benutzer sind gesperrt?AIS: System Audit Benutzer und Berechtigungen Infosystem Benutzerbersicht Benutzer nach Anmeldedatum,Auswertung nach dem Feld Benutzer gesperrt.Oder Transaktion SUIM oder SA38 mit dem Report RSUSR002.Oder ber Tabelle USR02 ermitteln, Feld UFLAG, User Sperre, mit = aus-whlen, das Ergebnis nach dem Inhalt von Feld UFLAG auswerten.Benutzerkennungen, die seit lngerer Zeit gesperrt sind, knnen Benutzerkennungen ausgeschiedener Mitarbeiter sein, die zu lschen sind.SOS: Profiles on Long Time Locked Users (0089)

4.3. Fr welche Benutzer ist der angegebene Gltigkeitszeitraum abgelaufen?AIS: System Audit Benutzer und Berechtigungen Infosystem Benutzerbersicht Benutzer nach Anmeldedatum,Auswertung nach dem Feld Gltig Bis.Oder Transaktion SUIM oder SA38 mit dem Report RSUSR002.Oder ber die Tabelle USR02 ermitteln, dabei keine Auswahl vornehmen, das Ergebnis nach dem Feld GLTB, Gltig Bis, auswerten.Benutzerkennungen, deren Gltigkeitszeitraum abgelaufen ist, knnen Benutzer- kennungen ausgeschiedener Mitarbeiter sein, die zu lschen sind.

20


5. Kontrollziel: Benutzerkennungen sind bis auf definierte Ausnahmen personenbezogen.Risiko: Benutzerkennungen werden als Sammelbenutzer verwendet. Es gibt keine organisatorische Regelung, die in bestimmten Fllen Sammelbenutzer zulsst, oder es gibt eine organisatorische Regelung fr Benutzerkennungen, der aber in der Ausprgung der Benutzerkennungen nicht gefolgt wird.

5.1. Welche Benutzerkennungen sind nicht aufgrund des Namens eines Benutzers gebildet oder folgen nicht der festgelegten Namenskonvention fr Benutzerkennungen?AIS: System Audit Benutzer und Berechtigungen Infosystem Benutzerbersicht Benutzer nach Anmeldedatum, Auswertung nach dem Feld Benutzer.Oder Transaktion SUIM.Oder ber die Tabelle USR02 ermitteln, dabei keine Auswahl vornehmen, das Ergebnis nach dem Feld BNAME, Benutzername, auswerten.Manuelles Durchsuchen der Liste auf Bezeichnungen wie AZUBI, WERK-STUDENT, LAGER, TEST, TESTUSER, TST.Benutzerkennungen, die nicht der Namenskonvention folgen, knnen z.B. nicht autorisierte Sammelbenutzerkennungen sein.

3.7. PRFPROGRAMM: SICHERE KONFIGURATION BESONDERER BENUTZERTYPEN

bersicht ber initiale Anmeldung fr Sonderbenutzer in SAP-Mandanten:

MANDANT 000/001 000/001 066 NEUER MANDANT

Benutzer SAP* DDIC EarlyWatch SAP*

Initiales Kennwort

Master-Kennwort wird whrend der Installation gesetzt.

Master-Kenn-wort wird wh-

rend der Installa-tion gesetzt.

Master-Kenn-wort wird whrend der Instal-lation gesetzt.

pass

Kenn-wort im frheren Release

06071992 19920706

Mandant 000/001/alle neuen Mandanten

000

Benutzer SAPCPIC TMSADM

Initiales Kennwort

ADMIN Master-Kenn-wort wird wh-

rend der Installa-tion gesetzt.

DSA

G-P

R

FLEI

TFAD

EN S

AP E

RP

6.0

VER

SIO

N 2

.0, 4

. MAI

201

5

DSA

G e

. V.

21

NR. SICHERE KONFIGURATION BESONDERER BENUTZERTYPEN

1. H

Kontrollziel: Schutz der Sonderbenutzer vor nicht autorisiertem ZugriffRisiko: Jeder kann anonym die SAP-Standardbenutzer SAP* und Early Watch ber die bekannten Standardkennwrter aufrufen und darunter nicht autorisierte Aktionen durchfhren. Mit SAP* knnen z.B. SAP-interne Kontrollen unterlaufen und SAP- interne Zwangsprotokolle manipuliert werden.Hinweis: In den Mandanten 000 und 001 wird bei der Installation automatisch ein Benutzerstammsatz erzeugt. Es wird gefordert, ein individuelles Kennwort fr SAP* und DDIC zu vergeben. Das Kennwort beider Standardbenutzer ist nicht mehr automatisch auf das Standardkennwort aus dem Jahr 1992 gesetzt.

1.1. Sind in jedem Mandanten die Standardkennwrter aller SAP-Standardbenutzer gendert?AIS: System Audit Top Ten Security Reports Kennworte der Standardbenutzer prfenSA38 mit Report RSUSR003.Wenn die Prferrolle diesen Report nicht zulsst, muss der Prfer einen der zugelassenen Systemadministratoren in seinem Beisein den Report ausfhren lassen und das Ergebnis sofort prfen.SOS: User EARLYWATCH Has Default Password (0056)

1.2. Ist der Benutzer SAP* gegen unbefugte Nutzung geschtzt (SAP-Hinweise 2 383 und 68 048)?Smtliche Berechtigungen im Benutzerstammsatz SAP* werden gelscht. Der Benutzerstammsatz SAP* wird gesperrt. Der Benutzerstammsatz SAP* wird der Gruppe SUPER zugeordnet. Es wird ber die Setzung des Systemparameters login/ no_automatic_user_sapstar auf den Wert 1 verhindert, dass nach Lschung des Benutzers SAP* (mit Benutzer- stammsatz) der systeminterne Benutzer SAP* mit dem unvernderbaren Standard- kennwort PASS aufgerufen werden kann. Fr die Systemadministration wird ein Notfallbenutzer mit umfassenden Berechtigungen angelegt.SOS: User SAP* is Neither Locked nor Expired (0043)SOS: User SAP* is Not Assigned to the Group SUPER (0044)SOS: Usage of the Hard Coded User SAP* is NOT Disabled (0046)

1.3. Ist der Benutzer SAP* in allen Mandanten ohne Berechtigungen angelegt und gesperrt?AIS: System Audit Benutzer und Berechtigungen Infosystem Benutzer Benutzer nach komplexen Selektionskriterien, Selektion nach Benutzer SAP*, nach Anzeige des Ergebnisses im Auswahlmen Rollen oder Profile anklicken.Oder Transaktion SUIM oder SA38 mit dem Report RSUSR002.SOS: Not All Profiles Are Removed from User SAP* (0042)SOS: User SAP* is Neither Locked nor Expired (0043)

1.4. Sind die Benutzer SAP* und DDIC in allen Mandanten der Benutzergruppe SUPER zugeordnet?AIS: System Audit Benutzer und Berechtigungen Infosystem Benutzer Benutzer nach komplexen Selektionskriterien, Selektion nach Benutzern SAP*, DDIC.Oder Transaktion SUIM oder SA38 mit dem Report RSUSR002.SOS: User SAP* is Not Assigned to the Group SUPER (0044)

22


1.5. Welche Benutzer- und Berechtigungsadministratoren drfen die Benutzergruppe SUPER pflegen?Transaktion SA38 mit dem Report RSUSR002 und den Eingaben:S_TCODE = SU01S_USER_GRP (Benutzerverwaltung) mit Aktivitt 01 (Anlegen), 02 (ndern) oder * und Gruppe = * oder = SUPER.SOS: Unexpected Users Are Authorized to Change a Super User Account (0026)

1.6. Ist der Parameter login/ no_automatic_user_sapstar auf den Wert 1 gesetzt?Hinweis 1: Mit Hilfe diese Parameters kann verhindert werden, dass sich jemand nach dem Lschen des Benutzerstammsatzes fr SAP* dann unter dem systeminternen au-tomatischen Benutzer SAP* mit dem unvernderbaren Kennwort PASS anmelden kann (Wert 1). Wenn es bei der Standardeinstellung (Wert 0) bleibt, ist immer ein erneutes Anmeldung unter diesem systeminternen Benutzer SAP* mglich.Hinweis 2: Soll der systeminterne automatische Benutzer SAP* wieder aktiviert werden, muss erst dieser Parameter zurckgesetzt und das System wieder gestartet werden.SOS: Usage of the Hard Coded User SAP* is not Disabled (0046)SOS: User SAP* Has Been Deleted at Least in One Client (0045).

2. Kontrollziel: Sichere Nutzung des Konzeptes der ReferenzbenutzerRisiko: Benutzerkennungen vom Typ Referenz haben Berechtigungen, die die Prinzipien der Berechtigungsvergabe verletzen (Forderung nach geringstem Berechtigungsum-fang; Einhaltung der Funktionstrennung).

2.1. Welche Benutzerkennungen sind Referenzbenutzer (Benutzertyp L)?AIS: System Audit Benutzer und Berechtigungen Infosystem Benutzerbersicht Benutzer nach Anmeldedatum, Selektion nach Benutzertyp Referenzbenutzer.Oder Transaktion SUIM oder SA38 mit dem Report RSUSR200.Selektion auf den Benutzertyp Referenzbenutzer einschrnken.

2.2. Welche Rollen und Profile sind den Referenzbenutzern zugeordnet?AIS: System Audit Benutzer und Berechtigungen Infosystem Benutzer Benutzer nach komplexen Selektionskriterien, Selektion nach Benutzertyp Referenzbenutzer, nach Anzeige des Ergebnisses im Auswahlmen Rollen oder Profile anklicken.Oder Transaktion SUIM oder SA38 mit dem Report RSUSR200.Selektion auf den Benutzertyp Referenzbenutzer einschrnken. ber den Benutzer- namen kann in die SU01 verzweigt werden.Auch Referenzbenutzer drfen nur Berechtigungen haben, die fr den Arbeitsplatz notwendig sind. Es darf keine Referenzbenutzer mit weit gefassten Berechtigungen, z.B. eines Superusers, geben.

2.3. Welchen Benutzern sind Referenzbenutzer zugeordnet?AIS: System Audit Benutzer und Berechtigungen Infosystem Benutzer Benutzer nach komplexen Selektionskriterien, Liste der Referenzbenutzer im Feld Referenz- benutzer eingeben.Oder Transaktion SUIM oder SA38 mit dem Report RSUSR002.Welchen Benutzern sind Nicht-Referenzbenutzer als Referenz zugeordnet?AIS: System Audit Benutzer und Berechtigungen Infosystem Benutzer Benutzer nach komplexen Selektionskriterien, Selektion auf Nicht gleich LEER im Feld Referenzbenutzer, in der Ergebnisliste die Nicht-Referenzbenutzer ermitteln.Oder Transaktion SUIM oder SA38 mit dem Report RSUSR002.Hinweis: Die Zuordnung eines normalen Benutzers als Referenzbenutzer kann ber einen Eintrag im Customizing grundstzlich verhindert werden (SAP-Hinweis 513 694).SOS: Usage of Normal Users as Reference Users is Not Prohibited (0012)

DSA

G-P

R

FLEI

TFAD

EN S

AP E

RP

6.0

VER

SIO

N 2

.0, 4

. MAI

201

5

DSA

G e

. V.

23


2.4. Wird die Zuordnung von Referenzbenutzern protokolliert?AIS: System Audit Repository/Tabellen Tabellenaufzeichnungen Technische Tabelleneinstellungen, letzte Zeile in der Anzeige zur Tabelle USREFUS.Transaktion SE13 mit Tabelle USREFUS.

3. Kontrollziel: Sichere Nutzung des Konzeptes der Benutzer vom Typ ServiceRisiko: Benutzerkennungen vom Typ Referenz haben Berechtigungen, die die Prinzipien der Berechtigungsvergabe verletzen (Forderung nach geringstem Berechtigungsum-fang; Einhaltung der Funktionstrennung).

3.1. Welche Benutzerkennungen sind Servicebenutzer (Benutzertyp S)?AIS: System Audit Benutzer und Berechtigungen Infosystem Benutzerbersicht Benutzer nach Anmeldedatum, Selektion nach Benutzertyp Servicebenutzer.Oder Transaktion SUIM oder SA38 mit dem Report RSUSR002, Selektion nach Benutzer-typ Servicebenutzer.

3.2. Welche Rollen und Profile sind den Servicebenutzern zugeordnet?AIS: System Audit Benutzer und Berechtigungen - Infosystem Benutzer Benutzer nach komplexen Selektionskriterien, Selektion nach Benutzertyp Referenzbenutzer, nach Anzeige des Ergebnisses im Auswahlmen Rollen oder Profile anklicken.Oder Transaktion SUIM oder SA38 mit dem Report RSUSR200.Selektion auf den Benutzertyp Servicebenutzer einschrnken. ber den Benutzer- namen kann in die SU01 verzweigt werden.Auch Servicebenutzer drfen nur Berechtigungen haben, die fr die Funktion notwendig sind. Es darf keine Servicebenutzer mit weit gefassten Berechtigungen, z.B. eines Superusers, geben.

4. Kontrollziel: Sichere Nutzung des Konzeptes der BenutzergruppeRisiko: Alle Benutzeradministratoren knnen einzelne Benutzer pflegen. Es kann zu nicht autorisierten Berechtigungsvergaben kommen.Hinweis: ber die Zuordnung eines Benutzers zu einer Benutzergruppe kann gesteuert werden, welche Benutzeradministratoren diesen Benutzer pflegen knnen. Wenn dieser Sicherheitsmechanismus genutzt wird, muss darauf geachtet werden, dass alle Benut-zer auch einer Benutzergruppe zugeordnet werden.Hinweis: Eine bersicht ber die existierenden Benutzergruppen geben die Tabellen USGRP(T).

4.1. Welche Benutzerkennungen sind keiner Benutzergruppe zugeordnet?AIS: System Audit Benutzer und Berechtigungen Infosystem Benutzerbersicht Benutzer nach Anmeldedatum, Selektion auf Gleich im Feld Benutzertyp (allgemein).Oder Transaktion SUIM oder SA38 mit dem Report RSUSR002, Selektion auf Gleich LEER fr das Feld Gruppe fr Berechtigung Wenn der Sicherheitsmechanismus der Benutzergruppe konsequent angewendet ist, darf es keine Benutzer ohne eine Benutzergruppe geben.SOS: Users Are NOT Assigned to User Groups (0005)

4.2. Wer kann Benutzergruppen anlegen?Report RSUSR002 mit den Eingaben:S_TCODE = SUGRS_USER_GRP (Benutzerverwaltung) mit Aktivitt * oder 01 (Anlegen) und Gruppe = * oder = Gruppennamen.

24


4.3. Wer kann Benutzergruppen ndern?Report RSUSR002 mit den Eingaben:S_TCODE = SU01S_USER_GRP (Benutzerverwaltung) mit Aktivitt * oder 02 (ndern) und Gruppe = * oder = Gruppennamen.

4.4. Wie sind Benutzergruppen fr Administratoren eingerichtet?Report RSUSR002 mit den Eingaben:S_TCODE = SU01S_USER_GRP (Benutzergruppen) mit Aktivitt * oder 02 (ndern) und Gruppe = * oder = dieselbe Gruppe, die der Benutzeradministrator angehrtber die Zuordnung der Benutzergruppe muss verhindert werden, dass ein Administra-tor dem eigenen Benutzerstammsatz Rollen/Profile zuweisen kann. Auch die nderung der Benutzergruppen Zuweisung darf im eigenen Benutzerstammsatz nicht mglich sein.SOS: User Administrators Are Authorized to Change Their Own User Master Record (0003)

DSA

G-P

R

FLEI

TFAD

EN S

AP E

RP

6.0

VER

SIO

N 2

.0, 4

. MAI

201

5

DSA

G e

. V.

25

3.8. PRFPROGRAMM: BERWACHUNG DER WIRKSAMKEIT DES ZUGRIFFSSCHUTZES

NR. BERWACHUNG DER WIRKSAMKEIT DES ZUGRIFFSSCHUTZES

1. Kontrollziel: Die Zugriffe auf das SAP-System werden regelmig berwacht. Es ist definiert, was auffllige Ereignisse sind. Sicherheitsverste werden bei Verdacht auf Missbrauch untersucht.Risiko: Sicherheitsereignisse, die aufgrund fehlender oder falsch eingestellter sicher-heitsrelevanter Parameter auftreten, werden nicht erkannt. Ein Sicherheitsversto oder Missbrauch eines Benutzers wird nicht zeitnah erkannt. Bei dem Verdacht auf Missbrauch kann im Nachhinein nicht mehr auf automatisch erfolgte Systemaufzeichnungen zurck-gegriffen werden, die zur Aufklrung des Vorgangs oder zur Verfolgung der Tter dienen knnen.

Kontrollfragen zum Prozess: Ist dokumentiert, dass das SAP Security Audit Log aktiviert werden muss und welche Mindesteinstellungen dabei vorgenommen werden mssen? Ist definiert, wer fr die Einrichtung und nderung der Einstellungen des SAP Security Audit Logs und das Lschen der Protokolldateien zustndig ist? Gibt es einen definierten Prozess fr die Auswertung und berwachung der Ereignisse, die ber das SAP Security Audit Log aufgezeichnet werden? Gibt es eine Vorgabe, wie lange die Protokolldateien im System vorgehalten werden mssen, z.B. um nachtrglich noch Recherchen zu Sicherheitsereignissen durchfhren zu knnen, die erst spter und auf anderem Wege bekannt geworden sind?

1.1. Ist das SAP Security Audit Log aktiviert? Welche Benutzer, welche Audit-Klassen, welche Ereignisse werden protokolliert?AIS: System Audit Systemprotokolle und Statusanzeigen Security Audit Logoder Transaktion SM19SOS: Security Critical Events for End Users Are Not Logged in the Security Audit Log (0136)Empfehlung 1: Kritische Ereignisse bei den folgenden Audit-KlassenDialog-AnmeldungRFC-/CPIC-AnmeldungRFC-Funktionsaufrufwerden fr alle Benutzer in allen Mandanten protokolliert.Empfehlung 2: Alle Ereignisse aller Audit-Klassen werden fr alle Notfallbenutzer protokolliert.Empfehlung 3: Alle Ereignisse aller Audit-Klassen werden fr alle Dialogbenutzer in der Benutzer- gruppe SUPER protokolliert.

1.2. Wer darf das SAP Security Audit Log aktivieren und die Einstellungen dazu ndern?Report RSUSR002 mit den Eingaben:S_TCODE = SM19S_ADMI_FCD (Systemberechtigung) mit Funktion AUDA (Audit Administration)S_C_FUNCT (direkter Aufruf von C-Kernel-Funktionen aus ABAP) mit Aktivitt 16 Ausfhren und Programmname SAPLSECU und C-Routine AUDIT_SET_INFO.Diese Berechtigung ist im Produktivsystem nur fr Systemadministratoren zulssig.

26


1.3. Wer darf die Protokolldateien des SAP Security Audit Log auswerten?S_TCODE = SM20S_ADMI_FCD (Systemberechtigung) mit Funktion AUDD (Audit Anzeige)Diese Berechtigung ist im Produktivsystem nur Systemadministratoren und fr die Mit-arbeitern zulssig, die fr die Aufgabe der berwachung und Auswertung der Ereignisse zustndig sind.

1.4. Wer darf die Protokolldateien des SAP Security Audit Log lschen?Report RSUSR002 mit den Eingaben:S_TCODE = SM18 oder SA38 oder SE38 (Report RSAUPURG)S_ADMI_FCD (Systemberechtigung) mit Funktion AUDA (Audit Administration) und ST0R (Auswerten von Traces)S_DATASET (Berechtigung zum Dateizugriff) mit Aktivitt 34 und Programmname SAPLSTUW und Dateiname (Pfad gem der Angabe zu dem Profilparameter DIR_AU-DIT, in dem die Protokolldateien gespeichert sind).Diese Berechtigung ist im Produktivsystem nur fr Systemadministratoren zulssig.

2. Kontrollziel: Aufdecken von Versuchen, das Kennwort einer Benutzerkennung auszuprobieren.Risiko: Ein Benutzer versucht, das Kennwort eines anderen Benutzers systematisch auszuprobieren.

2.1. Zu welchen Benutzerkennungen ist eine hohe Anzahl von Falschanmeldungen registriert?AIS: System Audit Benutzer und Berechtigungen Infosystem Benutzerbersicht Benutzer nach Anmeldedatum, Selektion auf Benutzer mit Falschanmeldungen. Oder Transaktion SUIM oder SA38 mit dem Report RSUSR200.

2.2. Welche Benutzerkennungen, die seit langem inaktiv sind, haben eine Sperre wegen Falschanmeldung?AIS: System Audit Benutzer und Berechtigungen Infosystem Benutzerbersicht Benutzer nach Anmeldedatum, Selektion auf Benutzer mit Falschanmeldungen.Oder Transaktion SUIM oder SA38 mit dem Report RSUSR200.

2.3. Prfung auf Anmeldefehler mit dem SAP Security Audit Log:Transaktion SM20, Auswahl Alle entf. Auditlogs, von Datum und bis Datum eingeben, Wechsel in den Expertenmodus ber den Menpunkt Bearbeiten Expertenmodus, Einschrnkung z.B. auf folgende Meldungen:AU0, AU2, fehlgeschlagenes LoginAUM, Benutzer wurde nach Falschanmeldungen gesperrtAUN, Benutzersperre wegen Falschanmeldungen wurde wieder aufgehoben.Die angezeigten Protokollstze sind auf auffllige zeitliche Hufungen bei einer Benutzerkennung zu untersuchen. Detailinformationen knnen durch Doppelklick auf die Einzelmeldungen angezeigt werden.Hinweis: Die Texte zu allen Meldekennungen sind in der Tabelle TSL1T hinterlegt. Die fr die Protokolldateien des SAP Security Audit Log relevanten Meldekennungen beginnen mit AU.

DSA

G-P

R

FLEI

TFAD

EN S

AP E

RP

6.0

VER

SIO

N 2

.0, 4

. MAI

201

5

DSA

G e

. V.

27


2.4. Prfung auf Anmeldefehler mit dem Systemlog:Transaktion SM21, Auswahl Alle entf. SysLogs, von Datum und bis Datum eingeben, Wechsel in den Expertenmodus ber den Menpunkt Bearbeiten Expertenmodus, ber die Schaltflche Meld.kennungen z.B. auf folgende Meldungen einschrnken: US1 Ein Benutzer wurde auf Grund von Falschanmeldungen gesperrt. US3 Es wurde versucht, sich mit einem gesperrten Benutzer anzumelden.Hinweis: Die Texte zu allen Meldekennungen sind in der Tabelle TSL1T hinterlegt.

3. Kontrollziel: Aufdecken von Versuchen, sich mit einem ungltigen Anmeldeticket anzumelden.Risiko: Ein Benutzer versucht systematisch, sich mit einem ungltigen Anmeldeticket anzumelden.

3.1. Prfung auf Anmeldefehler mit dem Systemlog:Transaktion SM21, Auswahl Alle entf. SysLogs, von Datum und bis Datum eingeben, Wechsel in den Expertenmodus ber den Menpunkt Bearbeiten Expertenmodus, ber die Schaltflche Meld.kennungen z.B. auf folgende Meldungen einschrnken: USD Der Aussteller & A des Anmeldetickets konnte nicht berprft werden USE Der Aussteller & A des Anmeldetickets ist nicht in der ACL USF Es wurde ein nicht interpretierbares Anmeldeticket empfangenHinweis: Die Texte zu allen Meldekennungen sind in der Tabelle TSL1T hinterlegt.

28

4.1. BERECHTIGUNGSVERGABE

Der Zugriff eines Benutzers auf die Funktionen und Daten des SAP-Systems wird ber Berechtigungen freigeschaltet. Dabei gelten nachfolgende Vergabegrundstze:

Grundstzlich sollen die Berechtigungen eines Benutzers nur diejenigen Sichten und Funktionen fr die Daten freigeben, die er zur Erfllung der Ttigkeiten an seinem Arbeitsplatz bentigt. Dies wird als das Prinzip des geringsten Berechtigungsumfangs, im englischen Sprachgebrauch als least privilege bezeichnet, sensitive Funktionen (Sensitive Access SA) drfen nur an einzelne, wenige Personen mit angemessener Erfahrung vergeben werden. Sensitive Funktionen beziehen sich dabei auf Funktionen, die notwendig, aber sensitiv sind (z.B. ffnen und Schlieen von Buchungs- perioden im SAP System), neben der restriktiven Vergabe ist bei der Berechtigungsvergabe darauf zu achten, dass angemessene Anforderungen an die Funktionstrennung eingehalten werden. Eine Funktions- trennungsregel besteht dabei jeweils aus mindestens zwei Funktionen in Kombination, die nicht zusammen vergeben werden drfen. Dieses Prinzip der Funktionstrennung hilft, Fehler und Missbrauch zu verhindern. Im englischen Sprachgebrauch wird es principle of segregation of duties, kurz SoD, genannt.

Fr die Unternehmen leiten sich die Vergabegrundstze aus den Anforderungen an ein internes Kontrollsystem ab. Unternehmen mssen ein internes Kontrollsystem einrichten, warten, ber- wachen und kontinuierlich optimieren.

4.2. DIFFERENZIERUNGSMODELLE FR BERECHTIGUNGSKONZEPTE

Das Berechtigungskonzept samt dessen technischer Umsetzung im SAP-ECC-System muss dazu geeignet sein, die unternehmensspezifischen Anforderungen der Ablauforganisation (Abbildung einzelner Prozessschritte/Aufgaben oder ganzer Arbeitspltze durch Berechtigungen in rollen) und der Aufbauorganisation (organisatorischer/rechtlicher Aufbau des Unternehmens) zu erfllen.

Je nach Unternehmensanforderung existieren verschiedene Differenzierungsmodelle fr Berechti- gungskonzepte. Dabei kann der Zugriff auf Sichten und Funktionen fr Daten entweder rollen- basiert (RBAC Role Based Access Control) oder attributbasiert (ABAC Attribute Based Access Control) erfolgen. Im Rahmen von klassischen SAP-ECC-Systemen werden standardmig rollen-basierte Berechtigungskonzepte systemseitig untersttzt.

Fr die Einrichtung von rollenbasierten Berechtigungskonzepten in SAP-ECC-Systemen stehen mehrere Modelle zur Abbildung der ablauf- und aufbauorganisatorischen Unternehmensanfor-derungen in den Rollen zur Verfgung. Generell kann hierbei zwischen dem Kombinations- und Trennmodell unterschieden werden:

Kombinations-Rollen-Modelle: innerhalb einer Rolle wird die ablauf- und aufbauorganisatorische Dimension kombiniert. Eine Rolle eines Kombinations-Rollen-Modells enthlt insofern

4. AUTORISIERUNG (ABAP-STACK)

DSA

G-P

R

FLEI

TFAD

EN S

AP E

RP

6.0

VER

SIO

N 2

.0, 4

. MAI

201

5

DSA

G e

. V.

29

immer alle technischen Berechtigungen, die zur Ausfhrung der in der Rolle enthaltenen Auf- gaben bentigt werden. Als Beispiel: Rolle Beleg buchen fr Buchungskreis 1. Die entspricht der Ableitungsfunktion des SAP-Profilgenerators. Trenn-Rollen-Modelle: in diesen Modellen werden fr die ablauforganisatorische Dimension einerseits und die aufbauorganisatorische Dimension andererseits eigenstndig getrennte Rollen eingerichtet. Somit bentigt ein Benutzer fr eine Aufgabe immer zwei Rollen, eine fr den prozessualen Teil (Prozessrolle) und eine fr den organisatorisch/funktionalen Teil (Differenzierungsrolle). Als Beispiel: Prozessrolle Beleg buchen und Differenzierungsrolle Buchungskreis 1.

Um ein ordnungsgemes Berechtigungskonzept zu erstellen, sind somit bereits am Anfang entsprechende ablauf- und aufbauorganisatorische Anforderungen zu identifizieren und ein entsprechend geeignetes Differenzierungsmodell zu whlen.

4.3. RISIKEN

Die Risiken liegen in der mangelhaften Umsetzung des geforderten internen Kontrollsystems, das unternehmensindividuell und risikoorientiert ber die Vergabe von Berechtigungen zu realisieren ist. Beispiele fr Risiken sind:

Die Prfbarkeit des Benutzer- und Berechtigungskonzeptes ist nicht gewhrleistet, da es nicht angemessen dokumentiert ist. Das Berechtigungskonzept gengt nicht den gesetzlichen und unternehmensinternen Anforderungen (z.B. da es keine geeigneten Funktionstrennungsregeln beinhaltet). Wesentliche interne Kontrollen fehlen in der Benutzer- und Berechtigungsverwaltung (z.B. Genehmigungsregelungen). Organisatorische oder technische Schwachstellen ermglichen ein Unterlaufen der beabsichtigten internen Kontrollen. Universelle Berechtigungen und sicherheitskritische Systemeinstellungen werden nach dem Produktiveinsatz im SAP-System nicht gendert, obwohl SAP diese nur fr die Phase der Implementierung oder des Release-Wechsels vorgesehen hat. Im Produktivsystem gefhrden diese aber die Systemintegritt und den ordnungsmigen Betrieb. Kritische Berechtigungen, die gegen gesetzliche und unternehmensinterne Regelungen verstoen (internes Kontrollsystem), werden ohne Restriktionen vergeben. Es ist nicht festgelegt worden, welche Berechtigungen als kritisch einzuordnen sind, und die Bedingungen sind nicht festgelegt, unter denen sie vergeben werden drfen. Technische Konzepte, die das SAP-System zur Ausprgung und Prfung von Berechtigungen bereitstellt, werden nicht konsequent genutzt. Beispiele sind Berechtigungsgruppen von Tabellen und Programmen oder Berechtigungsprfungen in selbst entwickelten Programmen. Somit werden Sicherheitslcken in Kauf genommen, die die Manipulation an kritischen Systemeinstellungen oder an Geschftsdaten zulassen. Die eingerichteten Benutzerkennungen und die vergebenen Berechtigungen werden nicht regelmig geprft und besttigt. Mglicher Missbrauch einzelner Benutzerkennungen durch fremde Benutzer oder durch einen Benutzer, der im Zeitlauf mit umfangreichen Berechtigungen ausgestattet wurde, wird nicht verhindert.

30

4.4. KONTROLLZIELE

Die Kontrollziele beziehen sich in der Regel auf die effektive und effiziente Gestaltung der Prozesse der Benutzer- und Berechtigungsverwaltung: Ein dokumentiertes Berechtigungskonzept liegt vor, das die gesetzlichen und unternehmensinternen Anforderungen erfllt. Die Organisation der Benutzer- und Berechtigungsverwaltung ist auch im SAP-System durch angemessene Autorisierung der dafr vorgesehenen Mitarbeiter gewhrleistet. Insbesondere wird die Funktionstrennung im Rahmen der Benutzer- und Berechtigungsverwaltung bercksichtigt. Universelle SAP-Standardprofile, die nur fr die Implementierung und den Release-Wechsel bereitgestellt sind, sind nicht vergeben oder durch unternehmensspezifische Berechtigungen angepasst oder abgelst. Sensitive/kritische Berechtigungen sind identifiziert und die Restriktionen dokumentiert, unter denen sie zu vergeben sind. Sicherheitskritische Funktionen werden nur restriktiv und kontrolliert vergeben. Das in Einzelfllen notwendige Aufheben der von SAP vorgesehenen Sicherheitseinstellungen ist autorisiert und dokumentiert (z.B. Konzept fr Notfallbenutzer). Prozesse zur Ausprgung von Berechtigungsgruppen und zur Prfung von Berechtigungen in Eigenentwicklungen sind definiert und wirksam. Die Benutzer- und Berechtigungsverwaltung wird regelmig berwacht und die Prozesse dazu geprft und optimiert.

4.5. PRFPROGRAMM: DOKUMENTIERTES BENUTZER- UND BERECHTIGUNGSKONZEPT

NR. INHALTE EINES DOKUMENTIERTEN BERECHTIGUNGS- UND BENUTZERKONZEPTES

H Kontrollziel: Die Dokumentation des Berechtigungs- und Benutzerkonzeptes erfllt die Mindestanforderungen.Risiko: Gesetzliche Anforderungen an die Dokumentation, Nachvollziehbarkeit und Prfbarkeit des Berechtigungs- und Benutzerkonzeptes sind nicht erfllt. Die Wirksam-keit eines Berechtigungs- und Benutzerkonzeptes kann nur geprft werden, wenn das Sollkonzept dokumentiert ist.

1. Allgemeine Dokumentationsstandards

1.1. Ist einem sachkundigen Dritten ein angemessener Einstieg in die Dokumentation des Benutzer- und Berechtigungskonzeptes mglich, indem in der Einleitung die Schilde-rung des Inhalts und Gegenstands des Dokumentes dargelegt wird?

Prfung der Einleitung darauf hin, ob Struktur und Inhalt der Dokumentation nachvollziehbar sind.

1.2. Sind die mit dem Dokument erfolgten Ziele geeignet herausgearbeitet?

Prfung des Dokumentes auf eine ausreichende Zielerluterung und obdie erforderlichen Compliance-Aspekte im Wesentlichen widerspiegelt werden.

DSA

G-P

R

FLEI

TFAD

EN S

AP E

RP

6.0

VER

SIO

N 2

.0, 4

. MAI

201

5

DSA

G e

. V.

31


1.3. Sind die Adressaten des Dokumentes ausreichend benannt? Dies sollten zumindest die aus Compliance-Gesichtspunkten relevanten Beteiligten sein.

Prfung des Dokumentes nach einer Erluterung der Adressaten und der mit dem Benut-zer- und Berechtigungskonzept direkt oder indirekt befassten Personen. Beurteilung, ob die genannten Personenkreise mit den aus Compliance-Grnden blicherweise mit dem Benutzer- und Berechtigungskonzept befassten Personen korrespondieren.

1.4. Ist die thematische und zeitliche Gltigkeit des Dokumentes definiert? Diese bezieht sich insbesondere auf die vom Dokument betroffenen Systeme/Mandanten sowie Module/Prozesse.

Prfung des Dokumentes nach einer Identifizierung des Geltungsbereichs der Dokumentation.

1.5. Sind im Dokument externe und insbesondere interne Anforderungen ausreichend bercksichtigt?

Prfung des Dokumentes nach einer Aufstellung der im Rahmen des Benutzer- und Berechtigungskonzeptes zu beachtenden externen Anforderungen (Compliance-Vorgaben) und internen Regelungen.

1.6. Ist im Dokument festgelegt, wer fr die Pflege des Dokumentes verantwortlich ist, wer das Dokument originr abgenommen hat und wie nderungen am Dokument zu genehmigen sind? Sind die am Dokument vorgenommenen nderungen sowie deren Abnahme in einer Dokumentenhistorie festgehalten?

Prfung des Dokumentes auf die Benennung von Dokumentenverantwortlichen und ob diese tatschlich mit den aktuellen Verantwortlichen bereinstimmen.

1.7. Ist die aktuelle Version des Dokumentes durch das zustndige Gremium abgenom-men? Ist die aktuelle Version an angemessener Stelle publiziert?

Prfung, ob Abnahme fr Dokument vorliegt und ob das Dokument entsprechend publiziert ist.

2 Rollen und Berechtigungen

a) Prozessbereiche

2.1. Ist fr alle Prozessbereiche des Unternehmens eine vollstndige und angemessen strukturierte bersicht der Prozessbereiche (Prozessmodell) vorhanden?

Aufnahme der fr das Unternehmen vorhandenen Prozessbereiche; Abgleich und Beur-teilung der Angemessenheit, Vollstndigkeit und Aktualitt der Dokumentation mit den erhobenen Daten.

b) Organisationsdimensionen

2.2. Ist pro Prozess und -teilbereich dargestellt, welche Organisationsdimensionen jeweils relevant sind (rechtliche Einheit, Werk, Kostenrechnungskreis etc.)?

Prfung des Dokumentes auf Auflistung der fr das Unternehmen relevanten Organisations-dimensionen pro Prozess und -teilbereich.

32


2.3. Sind fr jede Organisationseinheit die vorhandenen Ausprgungen aufgefhrt?

Beurteilung der Vollstndigkeit und Richtigkeit der in den Dokumentationen vorhandenen Aufstellungen zur Ausprgung der Organisationsdimensionen. Dies kann auch mit Verweis auf andere Dokumentationen oder direkt auf das System erfolgen. Insbesondere sollte der fr die Organisationsdimensionen strukturgebende Grundgedanke erkennbar werden. ber die SAP-Tabelle AGR_1252 knnen die aktuell verwendeten Organisationsdimensionen pro SAP-Rolle samt Ausprgungen eingesehen werden.

c) Namenskonventionen

2.4. Ist eine eindeutige Festlegung von Namenskonventionen fr Berechtigungen vorhanden?

Beurteilung des Vorhandenseins, der Vollstndigkeit und der Nachvollziehbarkeit der Namenskonvention (Anforderungen an Namenskonvention siehe nchsten Abschnitt).

2.5. Ist in der Namenskonvention kodiert ob es sich um eine Standardrolle handelt, welche im Produktivsystem vergeben werden darf? der Prozessbereich, fr den die jeweilige Rolle berechtigt? die Organisationseinheit, fr die die jeweilige Rolle berechtigt? der Risikogehalt einer Rolle?Weiterfhrende Informationen zur (Auen-)Gestaltung von Rollen sind in Kapitel 4.6 Prfprogramm: Ordnungsgeme Gestaltung von Rollen aufgefhrt.

Prfung, ob die Namenskonvention die o.g. Punkte bercksichtigt; Prfung, ob die im SAP-System vorhandenen Rollen der Namenskonvention laut Berechtigungskonzept entsprechen (die im SAP-System vorhandenen Rollen knnen ber die Tabelle AGR_Define eingesehen werden)

2.6. Ist neben der Konvention fr die technischen Namen ebenfalls eine Minimalkonvention fr die Beschreibung und den Langtext von Rollen vorhanden?

Prfung, ob ebenfalls eine Namenskonvention fr den Text und die Beschreibung von Rollen vorhanden ist.

d) Ausnahmeregelungen

2.7. Werden eigenentwickelte Berechtigungsobjekte verwendet und sind diese in den Dokumentationen angemessen beschrieben? Dies bezieht sich sowohl auf die durch die Berechtigungsobjekte geschtzten betriebswirtschaftlichen Objekte als auch auf die Kriterien, ber die der Zugriff gesteuert wird.

Prfung, ob der Mandant eigene Berechtigungsobjekte erstellt hat.Prfung, ob die Berechtigungsobjekte entweder im System in der Dokumentation oder auerhalb angemessen erlutert werden.

DSA

G-P

R

FLEI

TFAD

EN S

AP E

RP

6.0

VER

SIO

N 2

.0, 4

. MAI

201

5

DSA

G e

. V.

33


2.8. Werden vom Unternehmen Berechtigungsobjekte kundenspezifisch aktiviert und sind diese Einstellungen in den Dokumentationen angemessen beschrieben?

Prfung, ob der Mandant Berechtigungsobjekte abweichend von den Standardeinstellungen aktiviert hat.Prfung, ob die Einstellungen entweder im System in der Dokumentation oder auerhalb angemessen erlutert werden.

e) Verantwortlichkeiten

2.9. Ist jede Rolle (wenn mglich ber die Zuordnung zu einem Prozessbereich und einer Organisationseinheit) eindeutig einem Datenverantwortlichen zugeordnet? Dieser ist fr Einrichtung und nderung der Rollen sowie fr die Genehmigung der Vergabe der Rollen verantwortlich.

Prfung, ob eine eindeutige Zuordnung jeder Rolle zu einem Datenverantwortlichen mglich ist.

2.10. Ist jede Rolle (wenn mglich ber die Zuordnung zu einem Prozessbereich und einer Organisationseinheit) eindeutig einem Keyuser zugeordnet? Dieser untersttzt fachlich den IT-Bereich und den Datenverantwortlichen in Fragen der Pflege und Vergabe von Rollen.

Prfung, ob eine eindeutige Zuordnung jeder Rolle zu einem Keyuser mglich ist.

3 Benutzer und Rechte

a) Personalbereiche

3.1. Ist eine angemessene Organisationsstruktur vorhanden, die Planstellen, Personal- bereiche und Personal eines Unternehmens hierarchisch miteinander verbindet.

Aufnahme der fr das Unternehmen verfgbaren Informationen zur Organisations- struktur (im Idealfall stammt diese aus dem Organisationsmanagement des SAP).Beurteilung, ob die Unterlagen eine eindeutige Zuordnung von Vorgesetzten zu Personalbereichen ermglichen.

3.2. Sind eindeutige Zusammenhnge zwischen den Personalbereichen und den Prozess-bereichen hergestellt? Hierdurch kann die Angemessenheit von Rollen fr Benutzer beurteilt werden.

Prfung, ob eine Zuordnung von Prozessbereichen und Personalbereichen vorgenommen wurde. Sofern nicht Prfung, ob die vorhandenen Strukturen fr Prozessbereiche und Perso-nalbereiche geeignet sind, um einen solchen Zusammenhang herzustellen.

b) Benutzertypen

3.3. Liegt eine strukturierte und vollstndige Definition aller in den SAP-Systemen eines Unternehmens relevanten Benutzertypen vor?

Prfung, ob alle typischerweise vorkommenden Benutzertypen vollstndig und zutreffend definiert sind (Dialogbenutzer, Systembenutzer etc.).

34


3.4. Werden Benutzergruppen verwendet, die angemessen zur Funktionstrennung genutzt werden knnen?

Prfung, welche Benutzergruppen im SAP-System eingerichtet sind. Beurteilung, ob diese in Anlehnung an die Benutzertypen zur Differenzierung der Berechti-gungen genutzt werden (Vermeidung der Eigenadministration, Differenzierung von persona-lisierten Benutzern und Sonderbenutzern etc.). Benutzergruppen knnen ber Tabelle USGRP eingesehen werden.

c) Benutzerkonventionen

3.5. Verfgt jeder Benutzer ber eine eindeutige Benutzer-ID? Eine Person sollte soweit mglich dieselbe Benutzer-ID in allen Systemen haben.

Prfung, ob geeignete Konventionen fr die Benutzer-ID von Personen dokumentiert sind. Benutzer-IDs zu Benutzern knnen ber den Report RSUSR002 eingesehen werden.

3.6. Sind angemessene Mindestinformationen fr die Pflege des Benutzerstamms fest-gelegt? Wird systemseitig die Eingabe der Mindestinformationen erzwungen? Min-destinformationen stellen der Personalbereich zur Ableitung des Vorgesetzten sowie die Benutzergruppe dar. Sind neben den Mindestinformationen auch Festlegungen zu optionalen Informationen getroffen?

Prfung, ob eine angemessene Vorgabe fr Mindestbenutzerinformationen dokumentiert ist. Mindestinformationen zu Benutzern knnen ber den Report RSUSR002 eingesehen werden.

d) Verantwortlichkeiten

3.7. Ist fr jeden Benutzer (intern, extern, nichtpersonalisiert) die Identifizierung eines Verantwortlichen mglich? Dieser ist vollumfnglich fr den Benutzer, seine Daten, seine Berechtigungen und die Verwendung des Benutzers verantwortlich.

Prfung, ob ber die vorhandenen Konventionen fr jeden Benutzer die Identifizierung eines Verantwortlichen mglich ist.

e) Sonder- und Notfallbenutzer

3.8. Sind geeignete Regelungen fr Sonderbenutzer und ihre Berechtigungen (wie z.B. DDIC, CPIC, SAP* etc. bei SAP-Systemen) getroffen?

Prfung, ob Regelungen fr die Berechtigungen von Sondernutzern getroffen worden sind (weiterfhrende Prfungshinweise siehe Kapitel 3.7 Prfprogramm: Sichere Konfiguration besonderer Benutzertypen).

3.9. Sind geeignete Regelungen fr Notfallbenutzer und ihre Berechtigungen (Passwort-schutz, Freigabeverfahren, Protokollierung, Nachkontrolle) getroffen?

Prfung, ob die notwendigen Regelungen fr die Berechtigungen, den Schutz, ein Verfahren zur Freigabe, die Protokollierung der Aktivitten sowie fr die Nachkontrolle der Aktivitten eines Notfallbenutzers getroffen worden sind (weiterfhrende Prfungshinweise siehe Kapi-tel 4.7 Prfprogramm: Notfallbenutzerkonzept (ABAP-Stack)).

DSA

G-P

R

FLEI

TFAD

EN S

AP E

RP

6.0

VER

SIO

N 2

.0, 4

. MAI

201

5

DSA

G e

. V.

35


3.10. Sind u.a. im Zusammenhang mit Sonder- und Notfallbenutzer Vorgaben zur Konfiguration, Nutzung und berwachung des Security Audit Log definiert?

Prfung, ob Regelungen zum Security Audit Log existieren. Das Security Audit Log kann ber die Transaktion SM20 eingesehen werden.

c) Vorgaben Anmeldekontrollen

3.11. Ist definiert, welche Profilparameter fr die Anmeldekontrolle relevant und konfiguriert sind? Sind Angaben fr die konkrete Ausgestaltung der Parameter vorhanden?

Prfung, ob die Profilparameter fr die Anmeldekontrollen mit den Parametern aus dem Berechtigungs- und Benutzerkonzept bereinstimmen. Die Profilparameter sind ber den Report RSPARAM einsehbar. Prfung, ob die definierten Parameter den Mindestanforderungen nach SAP ERP Prfleitfa-den entsprechen (weiterfhrende Prfungshinweise siehe Kapitel 3.5 Tabelle: Vorschlags-werte fr die Systemparameter der Anmeldekontrolle).

4 Benutzer und Rechte

a) Prozess- und Risikobereiche

4.1. Sind die Prozesse des Unternehmens nach den ihnen innewohnenden Risiken in Bezug auf den Jahresabschluss, aber auch ggf. auf operative Risiken bewertet? Hierzu kann auf bereits etablierte Verfahren des Risikomanagements zurckgegriffen werden. Soweit in Prozessbereichen Risiken fr den Jahresabschluss identifiziert wurden, sollte beur-teilt sein, ob Funktionstrennungen und die Handhabung sensitiver Funktionen zur Min-derung der Risiken im Rahmen des internen Kontrollsystems genutzt werden mssen.

Ist dies der Fall, sind Prozesse zur berwachung von sensitiven Funktionen und Funktionstrennungen im Unternehmen fr die betrachteten Systeme und Prozesse zu etablieren.

Prfung, ob Prozesse und Konventionen fr die berwachung sensitiver Funktionen und Funktionstrennungen etabliert sind.

b) Sensitive Funktionen

4.2. Sind Funktionen, die einen erkennbaren Einfluss auf die Integritt der Jahresabschluss- informationen (insbesondere auf deren Vollstndigkeit und Richtigkeit) haben und in den SAP-Systemen gepflegt werden, im Rahmen eines Regelwerks fr Sensitive Funktionen erfasst? Ist innerhalb des Regelwerkes zustzlich definiert, welche Berechtigungen (Transaktionscodes und Berechtigungsobjekte) im betrachteten System zur Ausfhrung der Funktion erforderlich sind?

Prfung, ob fr die als risikorelevant eingestuften Prozessbereiche Regeln fr sensitive Funktionen definiert sind.Prfung, ob die in den Prozessbereichen definierten Regeln vollstndig alle relevanten Funktionen abdecken. Prfung, ob pro Funktion die dafr bentigten Berechtigungen aufgefhrt sind.

36


4.3. Ist in Abhngigkeit des Einflusses der sensitiven Funktionen auf die Datenintegritt (Risiko der Funktionen) eine Risikoeinstufung der Funktionen erfolgt?

Prfung, ob fr die definierten sensitiven Funktionen eine Beurteilung des hiermit verbun-denen Risikos vorliegt. Sinnvoll ist hierbei zumindest eine Einteilung in kritische Funktio-nen, die im jeweils beurteilten System aufgrund Ihres Risikos fr die Integritt von Daten oder System berhaupt nicht vergeben werden sollten und restriktive Funktionen, die zwar grundstzlich vergeben werden knnen, jedoch lediglich an einen mehr oder weniger einge-schrnkten Personenkreis. Hier kann zur Verfeinerung eine Differenzierung in hoch, mittel und gering erfolgen.

c) Funktionstrennung

4.4. Sind sensitive Funktionen im Rahmen eines Regelwerks fr Funktionstrennungen erfasst?

Prfung, ob fr die als risikorelevant eingestuften Prozessbereiche Regeln fr Funktions-trennungen definiert sind. Stellen Sie fest, ob die in den Prozessbereichen definierten Regeln vollstndig alle relevanten Funktionstrennungen abdecken.

4.5. Sind in Abhngigkeit des Einflusses der Funktionstrennungen auf die Datenintegritt (Risiko der Funktionstrennungen) die Funktionstrennungsregeln einer Risikoeinstufung unterzogen worden?

Prfung, ob fr die definierten Funktionstrennungen eine Beurteilung des hiermit verbun-denen Risikos vorliegt. Sinnvoll ist hierbei in hoch, mittel und gering je nach dem direkten Einfluss auf die Integritt von System und Daten.

d) Kompensierende Kontrollen, Namenskonvention und Verantwortung

4.6. Sind geeignete kompensierende Kontrollen etabliert, soweit aufgrund geringer Kapa-zitten, Urlaubsregelungen oder hnlichem eine Funktionstrennung oder restriktive Handhabung sensitiver Funktionen nicht mglich ist? Diese mssen geeignet gestaltet sein, um Risiken von Funktionen zu kompensieren. Sind fr die kompensierenden Kon-trollen definiert, fr welche sensitiven Funktionen und in welchem Umfang diese eine kompensierende Wirkung entfalten?

Prfung, ob das Unternehmen ein Standardvorgehen fr die Behandlung von Funktionstren-nungskonflikten festgelegt hat und ob in Ausnahmefllen Funktionstrennungsverletzungen als zulssig gelten, wenn diese kompensiert werden. Prfung, ob in diesem Fall geeignete Vorgaben existieren, wie kompensierende Kontrollen zu definieren und anzuwenden sind. Prfung, ob Kataloge von Kontrollen als Vorschlagswerte fr die Prozessbereiche vorhanden sind, in denen diese als Lsung fr Risiken aus Regelverletzungen akzeptiert werden.

4.7. Ist in der Namenskonvention einer Regel (sensitiven Funktion oder Funktionstrennung) oder einer Kontrolle der Prozessbereich kodiert, auf den die jeweilige Regel sich aus-wirkt? Ist ebenso durch die Namenskonvention vorgegeben, ob es sich bei einer Regel um eine Regel zur berwachung einer sensitiven Funktion oder um eine Funktionstren-nung handelt?

Prfung, ob die Namenskonvention eine durchgngige Kodierung des einheitlich definierten Prozessbereichs bercksichtigt.

DSA

G-P

R

FLEI

TFAD

EN S

AP E

RP

6.0

VER

SIO

N 2

.0, 4

. MAI

201

5

DSA

G e

. V.

37


4.8. Kann jede Regel und Kontrolle ber die Zuordnung zu einem Prozessbereich eindeutig einem Datenverantwortlichen zugeordnet werden? Dieser ist fr Einrichtung und nderung der Regeln und Kontrollen sowie fr die Auswertung der Regelauswertungen und die Ableitung von Manahmen verantwortlich.

Prfung, ob eine eindeutige Zuordnung jeder Regel und Kontrolle zu einem Datenverantwortlichen mglich ist.

5 Prozesse und Verantwortungen

a) Role Lifecycle Management (Berechtigungsadministration)

5.1. Ist das Verfahren fr Berechtigungsnderungen angemessen dokumentiert, in Kraft gesetzt und publiziert worden? Ist fr die Beantragung von Berechtigungen ein Stan-dardformular oder ein geeignetes Verfahren (Papier, Excel-Liste oder E-Mail) mit Mini-malinformationen definiert worden? Erfolgt die originre Antragsstellung durch einen qualifizierten Mitarbeiter (Keyuser), der sowohl fachliche als auch technische Aspekte der nderung beurteilen kann?

Durchsicht der Dokumente zum Verfahren der Berechtigungsadministration und Beurteilung der Vollstndigkeit und Angemessenheit.

5.2. Werden nderungen an Berechtigungen mittels eines Standardformulars vom zustn-digen Datenverantwortlichen genehmigt? Der Datenverantwortliche ist hierbei fr die Beurteilung der Notwendigkeit verantwortlich. Wird, sofern ein Rollenantrag nderun-gen enthlt, die nicht mit dem Prozessbereich oder der Organisationseinheit einer Rolle korrespondieren, die Genehmigung des Dateneigners dieses rollenfremden Datenbe-reichs eingeholt?

Durchsicht der Dokumente, ob die Funktion eines Datenverantwortlichen benannt und fr alle vorhandenen Prozessbereiche eindeutige Datenverantwortliche identifiziert sind. Die Einhaltung des Verfahrens kann per Aufruf Report RSSCD100_PFCG geprft werden, indem in Stichproben nderungsbelege von Rollen auf Vorhandensein entsprechender Frei-gaben durch den Datenverantwortlichen geprft werden.

5.3. Werden nderungen im Entwicklungssystem von den zustndigen Berechtigungsad-ministratoren implementiert? Wird dabei ein Standardtransportverfahren genutzt? Ist eine eindeutige Zuordnung zwischen Transport und Antrag durch eine gegenseitige Referenzierung mglich?

Werden nderungen vor dem Transport in das Produktivsystem im Testsystem von qualifizierten Keyusern der antragstellenden Fachabteilung getestet?

Erfolgt eine Freigabe der Transportauftrge zum Transport in das Produktivsystem durch die verantwortlichen Transportadministratoren? Erfolgt vor der Freigabe durch die Administratoren die Prfung, ob alle erforderlichen Dokumentationen, Freigaben und Tests vorhanden sind?

Durchsicht Dokumente, ob das Verfahren die o.g. Punkte bercksichtigt. Die Umsetzung des Verfahrens im SAP-System kann anhand des Tabelle E070 nachvollzogen werden.

38


b) User Lifecycle Management (Benutzeradministration)

5.4. Ist das Verfahren fr Benutzernderungen (User Lifecycle Management) angemes-sen dokumentiert, in Kraft gesetzt und publiziert worden? Ist fr die Beantragung von nderungen an Benutzern und der Zuordnung und Entziehung von Berechtigungen ein Standardformular oder ein geeignetes Verfahren (Papier, Excel-Liste oder E-Mail) mit Minimalinformationen definiert worden?

Prfung, ob im Rahmen der Dokumentationen von Benutzernderungen ein geeignetes Antragsformular mit vorgegebenen Minimalinformationen definiert ist.

5.5. Schliet das Verfahren fr Benutzernderungen eine Genehmigung durch den Perso-nalverantwortlichen (disziplinarischen Vorgesetzten) bzw. durch den Benutzerverant-wortlichen (bei nicht personalisierten Benutzern) ein? Die Genehmigung schliet die Beurteilung ein, dass der Mitarbeiter die Berechtigungen bentigt und fr deren Anwen-dung qualifiziert ist. Werden fr einen Benutzer Berechtigungen beantragt, fr die nicht der disziplinarische Vorgesetzte der Dateneigner ist, sollte das Beantragungsverfahren die Einbindung des zustndigen Datenverantwortlichen sicherstellen.

Prfung, ob das Verfahren eine Genehmigung durch einen Personal- bzw. einen Benutzer-verantwortlichen vorsieht und im SAP-System eingehalten wurde. Die Einhaltung des Verfahrens kann per Aufruf Report RSUSR100 gepr

DSAG Prüfleitfaden ECC 6_neu

Documents

Transcript of DSAG Prüfleitfaden ECC 6_neu