DSAG Prüfleitfaden ECC 6 - Neu

Prfleitfaden SAP ERP 6.
Best-Practice-Empfehlungen des
DSAG-Arbeitskreises Revision u. Risikomanagement
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
VERSION 2.0
STAND 4.MAI 2015
DSAG e.V.
Deutschsprachige SAP-Anwendergruppe
Wir weisen ausdrcklich darauf hin, dass das vorliegende Dokument nicht jeglichenRegelungsbedarfsmtlicher DSAG-Mitgliederin allen Geschftsszenarien antizipieren und abdecken kann.
Insofern mssen die angesprochenen Themen und Anregungen naturgem unvollstndig bleiben.
Die DSAG und die beteiligten Autoren knnenbezglich derVollstndigkeit und Erfolgsgeeignetheit
der Anregungen keine Verantwortung bernehmen.Smtliche berlegungen, Vorgehensweisen
und Manahmen hinsichtlich des Verhaltens gegenber SAP verbleiben in der individuellen Eigenverantwortung jedes DSAG-Mitglieds. Insbesondere kann dieser Leitfaden nur allgemeine Anhaltspunkte zu vertragsrechtlichen Themengeben und keinesfalls eine individuelle Rechtsberatung bei
der Verhandlung und Gestaltung von Vertrgendurch IT-rechtliche Experten ersetzen.
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 a
69190 Walldorf
Deutschland
Fon +49 (0) 6227 358 09 58
Fax +49 (0) 6227 358 09 59
www.dsag.de I [email protected]
Jedwede unerlaubte Verwendung ist nicht gestattet. Dies gilt insbesondere fr die Vervielfltigung, Bearbeitung, 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).
DSAG-PRFLEITFADEN SAP ERP 6.0 VERSION 2.0, 4. MAI 2015 DSAG e.V.
INHALTSVERZEICHNIS
EINLEITUNG
1. SAP ERP 6.0
6
8
2. PRFERROLLE, BESTANDSAUFNAHME VON SAP-SYSTEM-

LANDSCHAFT, RICHTLINIEN U. ORGANISATIONSWEISUNGEN
2.1. Grundlagen zur Erstellung einer Prferrolle

2.2. Bestandsaufnahme der SAP-Systemlandschaft
2.3. Bestandsaufnahme der Richtlinien des Unternehmens
9
9
10
3. IDENTIFIKATION UND AUTHENTISIERUNG (ABAP-STACK)
11
11
11
11
12
15
18
20
25
3.1. Anmeldekontrollen
3.2. Risiken
3.3. Kontrollziele
3.4. Prfprogramm: Systemparameter fr die Anmeldekontrolle
3.5. Tabelle: Vorschlagswerte fr die Systemparameter der Anmeldekontrolle
3.6. Prfprogramm: Gltigkeitszeitraum von Benutzerkennungen
3.7. Prfprogramm: Sichere Konfiguration besonderer Benutzertypen
3.8. Prfprogramm: berwachung der Wirksamkeit des Zugriffsschutzes
4. AUTORISIERUNG (ABAP-STACK)
28
4.1. Berechtigungsvergabe
4.2. Differenzierungsmodelle fr Berechtigungskonzepte
4.3. Risiken
4.4. Kontrollziele
4.5. Prfprogramm: Dokumentiertes Benutzer- und Berechtigungskonzept
4.6. Prfprogramm: Ordnungsgeme Gestaltung von Rollen
4.7. Prfprogramm: Notfallbenutzerkonzept (ABAP-Stack)
4.8. Prfprogramm: Nutzung kritischer SAP-Standardprofile/-rollen
4.9. Prfprogramm: Ersetzen kritischer Vorschlagswerte im Profilgenerator
4.10. Prfprogramm: Ordnungsmige Berechtigungs- und Benutzerorganisation
4.11. Tabellen: Beispielszenarien der Organisation einer Benutzer- und
Berechtigungsverwaltung

4.11.1. Szenario 1: 4-Augen-Prinzip
4.11.2. Szenario 2: 6-Augen-Prinzip

4.11.3. Szenario 3: 6-Augen-Prinzip, dezentrale Benutzerverwaltung im Produktivsystem
4.12. Prfprogramm: Berechtigungen fr die Benutzer- und Berechtigungsverwaltung
4.13. Prfprogramm: Sicherheitsmechanismen zur Aktivierung der Prfung

von Berechtigungen
28
28
29
30
30
39
41
42
44
48
50
5. SYSTEMINTEGRITT AUF DER ANWENDUNGSEBENE
67
5.1. Prfprogramm: Schutz der Batch-Input-Prozesse
67
6. SYSTEMINTEGRITT MIT DEM SAP JAVA-STACK
71
71
72
72
72
76
79
83
90
94
95
96
6.1. berblick
6.2. Risiken
6.3. Kontrollziele
6.4. SAP AS Java Systemarchitektur
6.5. Prfprogramm: Sichere Konfiguration des SAP Java-Stack
6.6. Prfprogramm: Sicherheit des ICM
6.7. Prfprogramm: Authentisierung und Autorisierung (Java-Stack)
6.8. Tabelle: Vorschlagswerte fr die Systemparameter der UME-Anmeldekontrolle
6.9. Prfprogramm: SAP-Java-Stack-Softwareverteilung
6.10. SAP Enterprise Portal
6.11. Prfprogramm: SAP-Java-Stack-Softwareverteilung
50
54
58
62
65
INHALTSVERZEICHNIS
7. SYSTEMINTEGRITT AUF DER DATENBANKEBENE

102
7.1. Interne und externe Anforderungen

7.2. Risiken
7.3. Kontrollziele
7.4. Prfprogramm: Absicherung von Oracle unter UNIX
7.5. Prfprogramm: Absicherung von Oracle unter Windows
7.6. Prfprogramm: Sicheres Datenbankmanagement mit Oracle
102
102
103
103
106
108
8. SYSTEMINTEGRITT AUF DER BETRIEBSSYSTEMEBENE
110
110
110
111
111
116
8.1. Interne und externe Anforderungen

8.2. Risiken
8.3. Kontrollziele
8.4. Prfprogramm: Systemintegritt von UNIX/Linux
8.5. Prfprogramm: Systemintegritt von Windows
9. RISIKEN AUS DEM EINSATZ VON SAP GRC

9.1. Access Management Prozesse
9.2. Anpassung von Prfungshandlungen beim Einsatz von SAP GRC Access Control 10.X
9.3. Neue Anforderungen an die IT-Prfung

9.3.1. Verlagerung der Risiken im Access Management
9.3.2. Neue Risiken im Access Management

9.3.3. Risikoarten beim Einsatz von SAP GRC
9.4. Prfprogramm beim Einsatz von SAP GRC Access Control

9.4.1. Prfung des Emergency Access Management

9.4.1.1. Prozess Design Emergency Access Management

9.4.1.2. Sicherheitskritische Parameter fr das Emergency

Access Management

9.4.1.3. Kritische Berechtigungen und Funktionstrennung im

Emergency Access Management
9.4.2. Prfung des User Access Management

9.4.2.1. Prozess Design User Access Management

9.4.2.2. Sicherheitskritische Parameter fr das User Access Management

9.4.2.3. Kritische Berechtigungen im User Access Management

9.4.3. Prfung des Business Role Management

9.4.3.1. Prozess Design Business Role Management

9.4.3.2. Sicherheitskritische Parameter fr das Business Role Management

9.4.3.3. Kritische Berechtigungen im Business Role Management

9.4.4. Prfung des Access Risk Analysis

9.4.4.1. Prozess Design Access Risk Analysis

9.4.4.2. Sicherheitskritische Parameter fr Access Risk Analysis

9.4.4.3. Kritische Berechtigungen im Access Risk Analysis
9.5. SoD-Risiken beim Einsatz von SAP GRC Acces Control
10. SAP HANA AUS REVISIONSSICHT

10.1. Risiken
10.2. Kontrollziele
10.3. Prfprogramm: Authentisierung und Autorisierung mit SAP HANA
10.4. Prfprogramm: Sichere Konfiguration der Schnittstellen von SAP HANA
10.5. Prfprogramm: Absicherung von SAP HANA unter Linux
10.6. Prfprogramm: Sicheres Datenbankmanagement mit SAP HANA
10.7. Prfprogramm: berwachung von Sicherheitsverletzungen und regelmige

berprfung potenzieller Sicherheitsschwachstellen der SAP-HANA-Server
122
122
123
126
126
126
127
128
129
129
132
135
138
138
141
144
144
144
148
150
152
152
156
159
163
166
167
168
169
179
181
183
185
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-Anwendungen 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 detaillierten Auseinandersetzung mit der SAP-Architektur verweist das Autorenteam auf die SAP-Online-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 kundenspezifischen 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.
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
Marcus Bhme
Siegfried Filla
Falk Huber
Ralf Kaib
Vojislav Kosanovic
Johannes Liffers
Martin Metz
Christoph Nickel
Jan Stlting
Wolfgang Storm
Karl Ulber
Deloitte & Touche GmbH

T-Systems International GmbH
PricewaterhouseCoopers AG Wirtschaftsprfungsgesellschaft
T-Systems International GmbH
Exagon GmbH
KPMG AG Wirtschaftsprfungsgesellschaft
Protiviti GmbH
PricewaterhouseCoopers AG, Wirtschaftsprfungsgesellschaft
BERSICHT DER VERFFENTLICHTEN KAPITEL:

KAPITEL
TITEL
AUTOR
STAND
Einleitung
Siegfried Filla
01.2015
SAP ERP 6.0
Siegfried Filla
01.2015
Prferrolle, Bestandsaufnahme von

SAP-Systemlandschaft, Richtlinien u.
Organisationsweisungen
Siegfried Filla
01.2015
Identifikation und Authentisierung (ABAPStack)
Ralf Kaib
03.2014
Autorisierung (ABAP-Stack)
Siegfried Filla, Johannes

Liffers, Wolfgang Storm,
Karl Ulber
02.2015
Prfprogramm: Schutz der BatchInput-Prozesse
Ralf Kaib
03.2014
Systemintegritt mit dem SAP Java-Stack
Vojislav Kosanovic
12.2013
Systemintegritt auf der Datenbankebene
Falk Huber
02.2015
Systemintegritt auf der Betriebssystemebene
Christoph Nickel
03.2015
Risiken und Prfung von SAP GRC
Murat Bc, Martin Metz
01.2015
10
SAP HANA aus Revisionssicht
Marcus Bhme,
Jan Stlting
03.2015
5.1
@ Copyright 2015 DSAG e. V.
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 Prozesse 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 HANADatenbanklsung der SAP als SAP HANA Live for ERP angeboten. Im Verbund mit den neuen CloudTechnologien 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 innerhalb von SAP ERP 6.0 beschftigen.
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 Prferrollen 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 Steuerprfung (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 Notfallusers 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 Verbindungen 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?
2. PRFERROLLE, BESTANDSAUFNAHME
VON SAP-SYSTEMLANDSCHAFT, RICHTLINIEN U. ORGANISATIONSWEISUNGEN
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?
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 Verbundwirkung einen angemessenen Zugriffsschutz gewhrleisten. Die gewnschte Kennwortqualitt 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.
3. IDENTIFIKATION UND AUTHENTISIERUNG

(ABAP-STACK)
11
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 SPFPAR
AIS: System Audit Systemkonfiguration Parameter Systemparameter, bersicht mit
Historie
Oder Transaktion TU02
AIS: System Audit Systemkonfiguration Parameter Systemparameter mit Doku.
Oder Transaktion RZ11
Hinweis: 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 Zeichen
Hinweis: 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_password_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)
NR.
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 Initialkennwort 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_valid 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 Benutzer 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 Kennworten

Risiko: Kennworte fremder Benutzerkennungen knnen ber wiederholte Anmeldeversuche 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)
13
14
NR.
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 Mehrfachanmeldungen

Risiko: 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).
3.5. TABELLE: VORSCHLAGSWERTE FR DIE SYSTEMPARAMETER DER

ANMELDEKONTROLLE
NR.
PARAMETER
SAPMGLICHE
WERTE
SAPVOREINSTELLUNG
VORSCHLAGSWERT
1.
H
login/ min_password_lng
6-40
6
(statt 3)
6 (Kennwortmindestlnge)
2.
login/ password_charset
0,1,2
1 (abwrtskompatibel)
3.
H
login/ min_password_letters
0-40
1 (Kennwort muss mindestens einen Buchstabe

enthalten.)
4.
H
login/ min_password_digits
0-40
1 (Kennwort muss mindestens eine Zahl enthalten.)
5.
H
login/ min_password_specials
0-40
1 (Kennwort muss mindestens ein Sonderzeichen

enthalten.)
6.
login/ min_password_lowercase
0-40
optional
7.
login/ min_password_uppercase
0-40
optional
8.
H
login/ min_password_diff
1-40
3 (mindestens die Hlfte der

minimalen Kennwortlnge)
9.
H
login/ password_history_size
1-100
15 Kennworte (bei einem

Wechsel, der alle 90 Tage
erzwungen wird)
10.
H
login/ password_max_idle_
initial
0-24.000
(Tage)
Gltigkeitsdauer fr ein
initiales Kennwort berschreitet nicht 3 Arbeitstage.
11.
H
login/ password_expiration_time
0-999
(Tage)
Erzwungener Wechsel des

Kennworts nach hchstens
90 Tagen.
12.
login/ password_max_idle_
productive
0-24.000
(Tage)
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 (Benutzer muss einen Tag

warten, bis er sein Kennwort
wieder ndern darf.)
15
16
NR.
PARAMETER
14.
VORSCHLAGSWERT
SAPMGLICHE
WERTE
SAPVOREINSTELLUNG
login/ fails_to_session_end
1-99
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_unlock
0 oder 1
0
(statt 1)
1 (automatisches Entsperren des Benutzers ber

Nacht)
17.
login/ disable_multi_gui_login
1 (mehrfache Anmeldung
nicht mglich)
18.
login/ multi_login_users
19.
login/ password_compliance_
to_current_policy
Zweck: Wenn ein bereits
vergebenes Kennwort nicht
mehr den inzwischen genderten Kennwortbildungsregeln entspricht, erzwingt das
System eine nderung des
Kennworts bei der Anmeldung.
0 oder 1
20.
login/ password_downwards_
compatibility
Zweck: Dieser Parameter
spezifiziert den Grad der
Abwrtskompatibilitt z.B.
der untersttzten Passwortlngen zu frheren SAP
Releases. Details sind der
technischen Dokumentation
zu entnehmen.
Siehe SAP
Dokumentation
Liste der Benutzer, fr die

eine Mehrfachanmeldung
mglich ist
0
Optional
Optional
NR.
PARAMETER
21.
Tabelle USR40
Beispieleintragungen:
123456, qwertz, (oder andere
Zeichenfolge auf der Tastatur) oder generisch
*Montag*, *Januar*, *Sommer*, *Passwort*, *Firmennamen*
22.
rdisp/ gui_auto_logout
Definiert die maximale Zeit in
Sekunden bei ausbleibender
Ttigkeit des angemeldeten
Benutzers bis zur automatischen Abmeldung. Dies gilt
nur fr SAP-GUI-Verbindungen.
Wenn der Parameter auf den
Standardwert 0 gesetzt ist,
erfolgt keine automatische
Abschaltung.
Jeder
numerische Wert
23.
login/password_logon_usergroup
Eine
Benutzergruppe
24.
login/ticket_expiration_time
StundenMinuten
SAPMGLICHE
WERTE
SAPVOREINSTELLUNG
VORSCHLAGSWERT
Abfragen auf triviale

Kennworte erbrigen
sich, wenn bereits komplexe Passwortbildungsregeln eingestellt sind.
Optional, aber verpflichtend, wenn keine

automatische FrontendSperre eingerichtet ist
(Bildschirmschoner mit
PC-Sperre).
Benutzer dieser Benutzergruppe knnen sich

weiterhin mit Passwort
anmelden.
8:00
Ablaufzeit fr das Anmeldeticket
17
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 Initialkennwort schon angelegt?
Auswertung nach unbenutzt im Feld Letzte Anmeldung
oder 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?
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.
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 Benutzerkennung 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 Gltigkeitszeitraum eingetragen?
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?
NR.
3.
Kontrollziel: Besondere Zeitrume von Aktivitt oder Inaktivitt werden durch flexible
Handhabung und unternehmensindividuelle Kennzeichnung der Sperrung einer Benutzerkennung 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 Berechtigungen fr einen definierten, aber temporren Auftrag, z.B. fr Aktivitten im Rahmen von
Messeveranstaltungen.
4.
Kontrollziel: Identifikation nicht mehr bentigter Benutzerkennungen

Risiko: Benutzerkennungen ausgeschiedener Benutzer werden nicht gelscht.
4.1.
Welche Benutzer haben sich ber einen lngeren Zeitraum nicht mehr angemeldet?
Benutzer nach Anmeldedatum oder Seit 30 Tagen nicht angemeldet,
Auswertung nach dem Feld Letzte Anmeldung.
nach dem Feld TRDAT, letztes Login-Datum, auswerten.
Abgleich mit Informationen zu den Mitarbeitern, die die Personalabteilung bereitstellt.
Benutzerkennungen ausgeschiedener Mitarbeiter sind zu lschen.
4.2.
Welche Benutzer sind gesperrt?

Benutzer nach Anmeldedatum,
Auswertung nach dem Feld Benutzer gesperrt.
Oder ber Tabelle USR02 ermitteln, Feld UFLAG, User Sperre, mit = <LEER> auswhlen, 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?

Benutzer nach Anmeldedatum,
Auswertung nach dem Feld Gltig Bis.
nach dem Feld GLTB, Gltig Bis, auswerten.
Benutzerkennungen, deren Gltigkeitszeitraum abgelaufen ist, knnen Benutzerkennungen ausgeschiedener Mitarbeiter sein, die zu lschen sind.
19
20
NR.
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?
Benutzer nach Anmeldedatum, Auswertung nach dem Feld Benutzer.
Oder Transaktion SUIM.
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
Benutzer
SAP*
Initiales
Kennwort
Master-Kennwort
wird whrend
der Installation
gesetzt.
Kennwort im
frheren
Release
06071992
Mandant
000/001/alle
neuen Mandanten
Benutzer
SAPCPIC
Initiales
Kennwort
ADMIN
000/001
066
DDIC
EarlyWatch
SAP*
Master-Kennwort wird whrend der Installation gesetzt.
pass
19920706
000
TMSADM
NEUER MANDANT
NR.
SICHERE KONFIGURATION BESONDERER BENUTZERTYPEN
1.
H
Kontrollziel: Schutz der Sonderbenutzer vor nicht autorisiertem Zugriff

Risiko: 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 SAPinterne 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 prfen
SA38 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 Benutzerstammsatz) der systeminterne Benutzer SAP* mit dem unvernderbaren Standardkennwort 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.
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?
nach komplexen Selektionskriterien, Selektion nach Benutzern SAP*, DDIC.
SOS: User SAP* is Not Assigned to the Group SUPER (0044)
21
22
NR.
1.5.
Welche Benutzer- und Berechtigungsadministratoren drfen die Benutzergruppe SUPER

pflegen?
Transaktion SA38 mit dem Report RSUSR002 und den Eingaben:
S_TCODE = SU01
S_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 automatischen 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 Referenzbenutzer

Risiko: Benutzerkennungen vom Typ Referenz haben Berechtigungen, die die Prinzipien
der Berechtigungsvergabe verletzen (Forderung nach geringstem Berechtigungsumfang; Einhaltung der Funktionstrennung).
2.1.
Welche Benutzerkennungen sind Referenzbenutzer (Benutzertyp L)?

Benutzer nach Anmeldedatum, Selektion nach Benutzertyp Referenzbenutzer.
Selektion auf den Benutzertyp Referenzbenutzer einschrnken.
2.2.
Welche Rollen und Profile sind den Referenzbenutzern zugeordnet?

nach komplexen Selektionskriterien, Selektion nach Benutzertyp Referenzbenutzer,
nach Anzeige des Ergebnisses im Auswahlmen Rollen oder Profile anklicken.
Selektion auf den Benutzertyp Referenzbenutzer einschrnken. ber den Benutzernamen 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?

nach komplexen Selektionskriterien, Liste der Referenzbenutzer im Feld Referenzbenutzer eingeben.
Welchen Benutzern sind Nicht-Referenzbenutzer als Referenz zugeordnet?
nach komplexen Selektionskriterien, Selektion auf Nicht gleich LEER im Feld
Referenzbenutzer, in der Ergebnisliste die Nicht-Referenzbenutzer ermitteln.
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)
NR.
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 Service
Risiko: Benutzerkennungen vom Typ Referenz haben Berechtigungen, die die Prinzipien
der Berechtigungsvergabe verletzen (Forderung nach geringstem Berechtigungsumfang; Einhaltung der Funktionstrennung).
3.1.
Welche Benutzerkennungen sind Servicebenutzer (Benutzertyp S)?

Benutzer nach Anmeldedatum, Selektion nach Benutzertyp Servicebenutzer.
Oder Transaktion SUIM oder SA38 mit dem Report RSUSR002, Selektion nach Benutzertyp 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.
Selektion auf den Benutzertyp Servicebenutzer einschrnken. ber den Benutzernamen 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 Benutzergruppe

Risiko: 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 Benutzer 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?

Benutzer nach Anmeldedatum, Selektion auf Gleich <LEER> 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 = SUGR
S_USER_GRP (Benutzerverwaltung) mit Aktivitt * oder 01 (Anlegen) und
Gruppe = * oder = Gruppennamen.
23
24
NR.
4.3.
Wer kann Benutzergruppen ndern?

S_TCODE = SU01
S_USER_GRP (Benutzerverwaltung) mit Aktivitt * oder 02 (ndern) und Gruppe = *
oder = Gruppennamen.
4.4.
Wie sind Benutzergruppen fr Administratoren eingerichtet?

S_TCODE = SU01
S_USER_GRP (Benutzergruppen) mit Aktivitt * oder 02 (ndern) und Gruppe = *
oder = dieselbe Gruppe, die der Benutzeradministrator angehrt
ber die Zuordnung der Benutzergruppe muss verhindert werden, dass ein Administrator 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)
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 sicherheitsrelevanter 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 zurckgegriffen 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 Log
oder Transaktion SM19
SOS: Security Critical Events for End Users Are Not Logged in the Security Audit Log
(0136)
Empfehlung 1:
Kritische Ereignisse bei den folgenden Audit-Klassen
Dialog-Anmeldung
RFC-/CPIC-Anmeldung
RFC-Funktionsaufruf
werden 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 Benutzergruppe SUPER protokolliert.
1.2.
Wer darf das SAP Security Audit Log aktivieren und die Einstellungen dazu ndern?
S_TCODE = SM19
S_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.
25
26
NR.
1.3.
Wer darf die Protokolldateien des SAP Security Audit Log auswerten?
S_TCODE = SM20
S_ADMI_FCD (Systemberechtigung) mit Funktion AUDD (Audit Anzeige)
Diese Berechtigung ist im Produktivsystem nur Systemadministratoren und fr die Mitarbeitern 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?
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_AUDIT, 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?
Benutzer nach Anmeldedatum, Selektion auf Benutzer mit Falschanmeldungen.
2.2.
Welche Benutzerkennungen, die seit langem inaktiv sind, haben eine Sperre wegen
Falschanmeldung?
Benutzer nach Anmeldedatum, Selektion auf Benutzer mit Falschanmeldungen.
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 Login
AUM, Benutzer wurde nach Falschanmeldungen gesperrt
AUN, 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.
NR.
2.4.
Prfung auf Anmeldefehler mit dem Systemlog:

Transaktion SM21, Auswahl Alle entf. SysLogs, von Datum und bis Datum
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.
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
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 empfangen
27
28
4. AUTORISIERUNG (ABAP-STACK)
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 Buchungsperioden im SAP System),
neben der restriktiven Vergabe ist bei der Berechtigungsvergabe darauf zu achten, dass
angemessene Anforderungen an die Funktionstrennung eingehalten werden. Eine Funktionstrennungsregel 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, berwachen 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 Berechtigungskonzepte. Dabei kann der Zugriff auf Sichten und Funktionen fr Daten entweder rollenbasiert (RBAC Role Based Access Control) oder attributbasiert (ABAC Attribute Based Access
Control) erfolgen. Im Rahmen von klassischen SAP-ECC-Systemen werden standardmig rollenbasierte Berechtigungskonzepte systemseitig untersttzt.
Fr die Einrichtung von rollenbasierten Berechtigungskonzepten in SAP-ECC-Systemen stehen
mehrere Modelle zur Abbildung der ablauf- und aufbauorganisatorischen Unternehmensanforderungen 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 aufbauorganisa torische Dimension kombiniert. Eine Rolle eines Kombinations-Rollen-Modells enthlt insofern
immer alle technischen Berechtigungen, die zur Ausfhrung der in der Rolle enthaltenen Aufgaben 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.
29
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 unternehmens internen 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 berck sichtigt.
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
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 Wirksamkeit 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 Schilderung 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 ob
die erforderlichen Compliance-Aspekte im Wesentlichen widerspiegelt werden.
NR.
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 Benutzer- 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 abgenommen? Ist die aktuelle Version an angemessener Stelle publiziert?
Prfung, ob Abnahme fr Dokument vorliegt und ob das Dokument entsprechend publiziert
ist.
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 Beurteilung 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 Organisationsdimensionen pro Prozess und -teilbereich.
31
32
NR.
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.
NR.
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.
Benutzer und Rechte

a) Personalbereiche
3.1.
Ist eine angemessene Organisationsstruktur vorhanden, die Planstellen, Personalbereiche und Personal eines Unternehmens hierarchisch miteinander verbindet.
Aufnahme der fr das Unternehmen verfgbaren Informationen zur Organisationsstruktur (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 Prozessbereichen 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 Personalbereiche 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.).
33
34
NR.
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 Berechtigungen genutzt werden (Vermeidung der Eigenadministration, Differenzierung von personalisierten 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 festgelegt? Wird systemseitig die Eingabe der Mindestinformationen erzwungen? Mindestinformationen 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 (Passwortschutz, 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 Kapitel 4.7 Prfprogramm: Notfallbenutzerkonzept (ABAP-Stack)).
NR.
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 Prfleitfaden entsprechen (weiterfhrende Prfungshinweise siehe Kapitel 3.5 Tabelle: Vorschlagswerte fr die Systemparameter der Anmeldekontrolle).
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 beurteilt sein, ob Funktionstrennungen und die Handhabung sensitiver Funktionen zur Minderung 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 Jahresabschlussinformationen (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.
35
36
NR.
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 verbundenen Risikos vorliegt. Sinnvoll ist hierbei zumindest eine Einteilung in kritische Funktionen, 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 eingeschrnkten 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 Funktionstrennungen 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 verbundenen 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 Kapazitten, 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 Kontrollen definiert, fr welche sensitiven Funktionen und in welchem Umfang diese eine
kompensierende Wirkung entfalten?
Prfung, ob das Unternehmen ein Standardvorgehen fr die Behandlung von Funktionstrennungskonflikten 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 auswirkt? Ist ebenso durch die Namenskonvention vorgegeben, ob es sich bei einer Regel
um eine Regel zur berwachung einer sensitiven Funktion oder um eine Funktionstrennung handelt?
Prfung, ob die Namenskonvention eine durchgngige Kodierung des einheitlich definierten
Prozessbereichs bercksichtigt.
NR.
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.
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 Standardformular oder ein geeignetes Verfahren (Papier, Excel-Liste oder E-Mail) mit Minimalinformationen 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 zustndigen Datenverantwortlichen genehmigt? Der Datenverantwortliche ist hierbei fr die
Beurteilung der Notwendigkeit verantwortlich. Wird, sofern ein Rollenantrag nderungen enthlt, die nicht mit dem Prozessbereich oder der Organisationseinheit einer Rolle
korrespondieren, die Genehmigung des Dateneigners dieses rollenfremden Datenbereichs 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 Freigaben durch den Datenverantwortlichen geprft werden.
5.3.
Werden nderungen im Entwicklungssystem von den zustndigen Berechtigungsadministratoren 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.
37
38
NR.

b) User Lifecycle Management (Benutzeradministration)
5.4.
Ist das Verfahren fr Benutzernderungen (User Lifecycle Management) angemessen 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 Personalverantwortlichen (disziplinarischen Vorgesetzten) bzw. durch den Benutzerverantwortlichen (bei nicht personalisierten Benutzern) ein? Die Genehmigung schliet die
Beurteilung ein, dass der Mitarbeiter die Berechtigungen bentigt und fr deren Anwendung 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 Benutzerverantwortlichen vorsieht und im SAP-System eingehalten wurde.
Die Einhaltung des Verfahrens kann per Aufruf Report RSUSR100 geprft werden (von
Datum und bis Datum Entsprechendes bei Auswertungszeitraum eingeben, Selektion
Angelegte Benutzer unter Selektionskriterien zu genderten Rechten, Auswahl von
Benutzern als Stichprobe, Einsichtnahme in die Dokumentationen und Freigaben zu den
angelegten Benutzern bzw. vergebenen Berechtigungen).
5.6.
Sind fr die Sperrung, das Ungltigsetzen und die Lschung von Benutzern spezifische
Regelungen getroffen worden? Muss der Vorgesetzte diesen Vorgngen immer zustimmen? Dies kann bei Sperrungen jedoch auch nachgelagert erfolgen, wenn die Sperrung
durch automatisierte Verfahren z.B. aufgrund von Triggern aus dem HR-System oder
aufgrund von Automatismen bei Fehlanmeldungen resultiert.
Prfung, ob die speziellen Anforderungen an die Sperrung und Lschung von Benutzern
gesondert geregelt sind.
Selektion von Entsperrungen, bei denen eine manuelle Sperrung oder eine Sperrung aufgrund von Fehlanmeldungen erfolgt ist und Prfung, ob fr die Entsperrung eine Genehmigung durch den Vorgesetzten vorliegt.
Die Einhaltung des Verfahrens kann per Aufruf Report RSUSR100 geprft werden.
5.7.
Wurden fr die Entsperrung und Initialisierung von Benutzern spezifische Regelungen

getroffen, die insbesondere die Genehmigung dieser Vorgnge einschlieen? Erfolgte die
Sperrung gezielt aufgrund von Fehlanmeldungen oder einem Antrag durch Vorgesetzte,
ist immer der Vorgesetzte in die Entscheidung einzubeziehen.
Prfung, ob die speziellen Anforderungen an die Sperrung, Entsperrung und Initialisierung
von Benutzern gesondert geregelt sind.
Selektieren von Entsperrungen, bei denen eine manuelle Sperrung oder eine Sperrung aufgrund von Fehlanmeldungen erfolgt ist und Prfung, ob fr die Entsperrung eine Genehmigung durch den Vorgesetzten vorliegt.
Die Einhaltung des Verfahrens kann per Aufruf Report RSUSR100 geprft werden.
NR.
6

Basis und bergreifende Funktionen
Prfung, ob in den vorliegenden Dokumentationen angemessene Anforderungen
und Verfahren fr folgende bergreifende Funktionen getroffen sind:
Pflege von Tabellen
Pflege von Queries
Ausfhrung von Reporten
Debuggen von Programmen
Berechtigungen auf Batch-Input-Mappen
Berechtigungen auf Spool-Auftrge
Berechtigungen auf TemSe
Berechtigungen auf RFC-Schnittstelle
Berechtigungen auf Application Link Enabling (ALE-Schnittstelle)
Empfehlungen fr die Ausgestaltung der Regelungen zu den oben aufgefhrten
Punkten sind innerhalb des Prfungsleitfadens der DSAG aufgefhrt.
4.6. PRFPROGRAMM: ORDNUNGSGEMSSE GESTALTUNG VON ROLLEN

NR.
ORDNUNGSGEMSSE GESTALTUNG VON ROLLEN

Kontrollziel: Bei der Gestaltung von Rollen werden Mindestanforderungen beachtet.
a) Rollenklarheit: jede Einzel- und Sammelrolle ist eindeutig einem Subprozess/
Prozess und einer Organisationsebene samt Organisationsebenwert zugeordnet
b) Rollentransparenz: der Rollenname und der Rollenbeschreibungstext sind so
gestaltet, dass der Zweck der Rolle fr einen sachkundigen Dritten innerhalb
angemessener Zeit nachvollziehbar ist, ohne dafr die technischen Berechtigungen
der Rolle prfen zu mssen. Ebenso sollte der Zusammenhang einer Sammelrolle
mit einer Einzelrolle erkennbar sein. Zudem sollte nur eine kritische Berechtigung
pro Einzelrolle enthalten sein.
b) Rollenkongruenz: jede Einzelrolle beinhaltet nur die Transaktionen und Berechtigungen, die mit dem Rollennamen, der Rollenbeschreibung, der Einordnung zu
einem Subprozess/Prozess und den angegebenen Organisationsebenen und -werten
bereinstimmen.
b) Regelkonformitt: eine Einzelrolle ist frei von inhrenten Funktionstrennungskonflikten; Sammelrollen besitzen nur beabsichtigte Funktionstrennungskonflikte,
die durch entsprechende Kontrollen kompensiert werden.
Risiko:
Rollen sind in ihrer Funktion, Zweck und Umfang nicht nachvollziehbar, was das
Risiko einer fehlerhaften Zuordnung von Rollen/Berechtigungen an Benutzer steigert
und den Berechtigungsvergabeprozess ineffizient gestaltet.
Beim Design von Rollen werden Funktionstrennungsaspekte nicht beachtet, was zu
inhrenten Funktionstrennungskonflikten in Einzelrollen fhren kann.
39
40
NR.
1
1.1.
ORDNUNGSGEMSSE GESTALTUNG VON ROLLEN

Rollenklarheit
Werden neben dem technischen Namen der Rolle, dem Rollennamen sowie der Rollenbeschreibung zustzlich die folgenden Rollenattribute verwendet?
Prozessdimension: ist der Prozessbereich, zu dem die Rolle gehrt, ersichtlich?
Rollentyp: Ist ersichtlich, ob es sich um eine Einzelrolle oder Sammelrolle in Form
eines Arbeitsplatzes handelt?
Organisationsdimension: Ist die Organisationsebene, nach der die Rolle differenziert
wird (Buchungskreis, Werk usw,), ersichtlich?
Funktion: Sind die Funktion und die Aktivitt (Anzeige-, Pflege oder Entwicklungs-/
Konfigurations-Ttigkeiten) der Rolle in Form der Beschreibung eines betriebswirtschaftlichen Objektes (z.B. Kreditorenstammdaten anzeigen, Materialbelege buchen,
usw.) ersichtlich?
Die im SAP-System vorhandenen Rollen knnen ber die Tabelle AGR_Define eingesehen
werden.
2
5.6.
Rollentransparenz
Werden die Anforderungen der Rollentransparenz eingehalten?
Allgemeines Transparenzgebot (Nachvollziehbarkeit): Sind die im System ausgeprgten Rollen fr einen sachkundigen Dritten innerhalb angemessener Zeit nachvollziehbar? Je weniger der Zusammenhang einer Sammelrolle mit einer Einzelrolle
und der Einzelrolle mit den enthaltenen Berechtigungen erkennbar ist, desto weniger
nachvollziehbar ist das Rollenkonzept.
Nachhaltigkeit: Ist die Gruppierung von Berechtigungen in Rollen so gestaltet, dass
bei prozessualen Reorganisationsmanahmen keine erhhten Anpassungen am
Rollenkonzept notwendig werden? Dies setzt voraus, dass auf Ebene von Einzelrollen
mglichst Aufgaben (Kreditorenstammdaten ndern) und keine Arbeitspltze
(Kreditorenbuchhalter) abgebildet werden.
Die im SAP-System vorhandenen Rollen knnen ber die Tabelle AGR_Define eingesehen
werden.
3
3.1.
Rollenkongruenz
Entsprechen die technischen Berechtigungen der Rollen deren technischen Namen
bzw. dem Beschreibungstext?
Die im SAP-System vorhandenen Rollen knnen samt den pro Rolle verwendeten Transaktionen und ausgeprgten Aktivitten ber die Tabelle AGR_1251 eingesehen werden.
4
4.1.
Regelkonformitt
Werden bei der Gestaltung (mandantenspezifische) Regelwerke fr Funktionstrennungskonflikte und sensitive Funktionen beachtet? Sind Einzelrollen frei von
inhrenten Regelversten?
Prfung, ob entsprechende Regelwerke vorliegen und diese ggf. in das SAP-System
integriert sind.
Die im SAP-System hinterlegten Regelwerke zu kritischen Kombinationen von
Berechtigungen knnen ber den Report RSUSR008_009_NEW eingesehen werden.
4.7. PRFPROGRAMM: NOTFALLBENUTZERKONZEPT (ABAP-STACK)

NR.
NOTFALLBENUTZERKONZEPT
Kontrollziel: Absicherung des Notfallbenutzers
Risiko:
Es gibt keinen Notfallbenutzer: Systemadministratoren arbeiten im Normalbetrieb
unter dem Standardbenutzer SAP* oder zwar unter einem eigens eingerichteten
Benutzer, aber mit der universalen Superuser-Berechtigung SAP_ALL.
Es gibt einen eigenen Notfallbenutzer mit der universalen Superuser-Berechtigung
SAP_ALL, den sich die Systemadministratoren teilen und der jederzeit unkontrolliert
eingesetzt werden kann.
1.1.
Ist fr den Notfall mindestens eine Benutzerkennung eingerichtet,

die nicht der Standardbenutzer SAP* ist,
die die notwendigen weitreichenden Berechtigungen hat,
die mit einem komplexen Kennwort ausgestattet ist,
deren Kennwort an einem sicheren Ort zugriffsgeschtzt aufbewahrt wird,
wobei der Zugriff auf das Kennwort im 4-Augen-Prinzip erfolgen muss.
1.2.
Werden Aktionen unter dem Notfallbenutzer dokumentiert, dann mindestens unter Angabe
des Grundes
des Zeitraums
der darunter ttigen Personen
der Ttigkeiten, die damit durchgefhrt wurden.
1.3.
Werden fr einen Notfallbenutzer ber das SAP Security Audit Log alle Ereignisse aller
Audit-Klassen zwangsprotokolliert?
1.4.
Wird nach der Notfallaktion das Kennwort des Notfallbenutzers gendert?
1.5.
Sind Notfallszenarien definiert und auf diese Notfallszenarien zugeschnittene

Berechtigungen in Form von Rollen implementiert worden? Existiert nicht nur ein
Notfallbenutzer, sondern pro Notfallszenario ein dedizierter Notfallbenutzer, der
die fr das Notfallszenario implementierten Rollen zugeordnet bekommen hat?
41
42
4.8. PRFPROGRAMM: NUTZUNG KRITISCHER SAP-STANDARD PROFILE/-ROLLEN

NR.
NUTZUNG KRITISCHER SAP- STANDARDPROFILE/-ROLLEN
Kontrollziel: Einschrnkung der Nutzung der kritischen universellen SAP-Standardprofile/-rollen

Risiko: Verlust der Vertraulichkeit, Verlust der Integritt der Daten und des SAPSystems, Verlust der Verfgbarkeit.
Auf dem Produktivsystem werden entgegen den eindeutigen Sicherheitsempfehlungen
des Herstellers SAP nach Inbetriebnahme weiterhin die sicherheitskritischen SAPStandardprofile vergeben nach dem Motto Simplicity over Security:
an externe Dienstleister, z.B. fr Beratung, technische Untersttzung, Wartung,
an interne Systemadministratoren,
an Benutzer aus der Fachabteilung.
Damit werden das gesetzlich geforderte unternehmensinterne Interne Kontrollsystem
und das SAP interne Sicherheitskontrollsystem unterlaufen. Ordnungsmigkeitsanforderungen werden verfehlt.
1.1.
An welche Benutzer ist SAP_ALL vergeben?

nach komplexen Selektionskriterien, Selektion nach Profil SAP_ALL.
Wie ist die Vergabe und Nutzung des Standardprofils SAP_ALL organisatorisch
geregelt?
Das Profil SAP_ALL ist im Produktivsystem nicht zulssig. SAP empfiehlt, dieses Profil
nur dem Notfallbenutzer zuzuweisen.
Hinweis 1: Dieses Sammelprofil enthlt alle SAP-Berechtigungen. Ein Benutzer mit
diesem Profil kann im SAP-System alle Aufgaben durchfhren.
Risiko: Benutzer manipulieren unter dem hchst privilegierten SAP-Standardprofil SAP_
ALL beliebige Geschftsdaten, deaktivieren installierte SAP-interne Kontrollen oder
sicherheitsrelevante Systemeinstellungen oder lschen die Systemaufzeichnungen der
Aktivitten, um die Spuren erfolgter Manipulationen zu beseitigen.
Hinweis 2: Anstatt das Profil SAP_ALL zu benutzen, knnen die darin enthaltenen
Berechtigungen auf die entsprechenden Funktionen verteilt werden. Es sollte z.B. dem
Systemadministrator nicht die Berechtigung SAP_ALL zugewiesen werden, sondern nur
die fr die Systemverwaltung erforderlichen Berechtigungen, also die S_*-Berechtigungen. Dies berechtigt ihn zur Verwaltung des gesamten SAP-Systems, er kann damit
jedoch keine Aufgaben in anderen Bereichen, z.B. in Anwendungen, durchfhren.
Hinweis 3: Es ist zu prfen, ob Rollen oder Profile mit Berechtigungsumfngen analog
SAP_ALL existieren.
SOS: Users with the most Full Access Authorizations (* Field Values) (0027)
SOS: Users with the most Roles (0028)
SOS: 20% or max 30% of All Users That Have for the most Profiles (0029)
NR.
NUTZUNG KRITISCHER SAP-STANDARDPROFILE/-ROLLEN
1.2.
An welche Benutzer ist SAP_NEW vergeben?

nach komplexen Selektionskriterien, Selektion nach Profilen der Form SAP_NEW*.
AIS: System Audit Benutzer und Berechtigungen Infosystem Profile Profile nach
Profilnamen, Selektion nach Profilen der Form SAP_NEW*.
Eine lange Liste von SAP_NEW-Profilen, z.B. nach mehreren Upgrades, ist ein Zeichen
dafr, dass das Berechtigungskonzept zu berarbeiten und neu festzusetzen ist.
Wie ist die Vergabe und Nutzung des SAP-Standardprofils SAP_NEW organisatorisch
geregelt?
Das Profil SAP_NEW ist im Produktivsystem nicht zulssig.
SAP empfiehlt, die SAP_NEW_* Profile nach einem Upgrade aufzulsen und die
bentigten Teilberechtigungen zu verteilen sowie SAP_NEW zu lschen.
Hinweis 1: Dieses Sammelprofil enthlt alle Profile, die mit einem Release neu
hinzukommen. Nach jedem Release-Wechsel bentigt man dieses Profil, damit
bestimmte Aufgaben problemlos ablaufen knnen.
Risiko: Benutzer missbrauchen die privilegierten Berechtigungen des SAP-Standardprofils SAP_NEW und fhren nicht autorisierte Aktivitten durch.
SAP empfiehlt im Einzelnen:
nach dem Upgrade die SAP_NEW_*-Profile fr Releases vor der Einfhrung des
Berechtigungskonzepts zu lschen,
die SAP_NEW_*-Profile fr Releases zu lschen, in denen bereits die darin
enthaltenen Profile verteilt worden sind,
den Rest der in den SAP_NEW_*-Rollen enthaltenen Profile an die entsprechenden
Funktionen zu verteilen und ihre Berechtigungswerte zu pflegen,
SAP_NEW zu lschen.
SOS: Users with Profile SAP_NEW (0031)
1.3.
An welche Benutzer sind weitere kritische SAP-Standardprofile vergeben, ggf. noch

aus alten Releasestnden? Beispiele sind:
S_A.SYSTEM (Systemverwalter, Superuser), S_A.ADMIN (Operator), S_A.CUSTOMIZ
(Customizer), S_A.DEVELOP (Alle Berechtigungen fr einen Entwickler)
S_CTS_ALL, u.a. kann damit die Systemnderbarkeit gesetzt werden
S_CTS_PROJECT, u.a. kann damit ein nderungsauftrag eines anderen Benutzers
bernommen werden, indem der Name im nderungsauftrag gendert wird
S_DATASET_AL, S_C_FUNCT_AL, S_TCD_ALL, S_TSKH_ALL
F_BUCH_ALL, Z_ANWEND
nach komplexen Selektionskriterien, Selektion nach Profil.
Sind die Vorgaben von SAP zur Vergabe und Nutzung der kritischen SAP-Standardprofile
bekannt und in eine organisatorische Regelung umgesetzt?
Risiko: Benutzer knnen nach dem Produktivstart oder einem Release-Wechsel diese
weitreichenden SAP-Standardprofile missbrauchen, die SAP nur zur Untersttzung der
Implementierungsphase bereitstellt.
SOS: SAP Standard Roles Are Assigned to Users (0082)
SOS: SAP Standard Profiles Are Assigned to Users (0083)
Empfehlung: ber die Transaktion SUIM oder die Tabellen UST10S/UST12 kann
zustzlich geprft werden, ob Profile mit analogen Inhalten zu den oben aufgefhrten
Profilen existieren.
43
44
4.9. PRFPROGRAMM: ERSETZEN KRITISCHER VORSCHLAGSWERTE

IM PROFILGENERATOR
NR.
ERSETZEN KRITISCHER VORSCHLAGSWERTE IM PROFILGENERATOR
Kontrollziel: Die von SAP standardmig gesetzten und vordefinierten Ausprgungen

von Berechtigungen im Profilgenerator sind auf kritische Setzungen bewertet worden.
Bei der Vergabe von Profilen werden die als kritisch erkannten Vorgaben bercksichtigt und gem den unternehmensspezifischen Sicherheits- und Kontrollanforderungen gendert.
Risiko: Die von SAP gesetzten Vorschlagswerte im Profilgenerator fr die Berechtigungsprfung werden unverndert bernommen, obwohl einige davon nicht den geforderten IT-internen Kontrollen im Produktivsystem gengen.
1.1.
Soll jeder Benutzer auf dem Produktivsystem uneingeschrnkte Entwicklungsberechtigungen erhalten?

S_DEVELOP (ABAP-Workbench) mit Aktivitt * und Paket * und Objektname * und
Objekttyp * und Berechtigungsgruppe * ist sehr kritisch.
Dieses Berechtigungsobjekt darf im Produktivsystem nur mit dem Objekttyp SUSO
(Berechtigungsobjekte) und der Aktivitt 03 Anzeigen ausgeprgt sein.
Risiko: Ausprgungen, die die Aktivitten 01 Anlegen oder 02 ndern zusammen mit
einem der beiden Objekttypen DEBUG oder PROG beinhalten, verstoen im Produktivsystem gegen Grundstze der ordnungsmigen Buchfhrung (Radierverbot).
1.2.
Soll jeder Benutzer die kritische Systemberechtigung zum Auswerten des Syslogs
erhalten?
S_ADMI_FCD (Systemberechtigungen) mit Aktivitt SM21 berechtigt, den Systemlog
auszuwerten.
Dieses Berechtigungsobjekt darf mit der Aktivitt SM21 im Produktivsystem nicht fr
alle Benutzer freigeschaltet werden.
1.3.
Soll jeder Benutzer neue Projekte generieren knnen?

S_PRO_AUTH (Neue Berechtigungen fr Projekte) mit Aktivitt 03 (Anzeigen).
Dieses Berechtigungsobjekt darf im Produktivsystem nur mit der Aktivitt 03
Anzeigen ausgeprgt werden.
1.4.
Welche Adressgruppen knnen fr alle Benutzer freigeschaltet werden?

S_ADRESS1 (Adresstyp1: Organisationsadressen)
mit Aktivitt * und Adressgruppe BC01 (SAP-Benutzeradressen) ist sinnvoll.
Im Produktivsystem ist auf die spezifische Eingabe der Adressgruppe zu achten,
insbesondere nur BC01 (SAP-Benutzeradressen) zulassen. Adressgruppen wie
Geschftspartner, BP, oder EHS-Berichtsempfnger, EHS1, drfen wegen des Prinzips
der geringsten Berechtigungsvergabe und der Gewhrleistung der Vertraulichkeit
nicht grundstzlich an alle Benutzer freigegeben werden.
Risiko: Die Vertraulichkeit von Daten ist unter Umstnden nicht gewhrleistet.
1.5.
Welche Transaktionscodes knnen fr alle Benutzer von HR freigeschaltet werden?

P_TCODE (HR Transaktionscode) mit Transaktionscode: PFCG, SUID oder SU01D ist
sinnvoll.
Dieses Berechtigungsobjekt darf im Produktivsystem nur fr die Transaktionscodes
PFCG, SUID oder SU01D freigeschaltet sein.
Die im Kontext zu den Transaktionen PFCG stehenden Berechtigungsobjekte mssen gem der zugeordneten Aufgabe ausgeprgt sein (Administrations- oder Anzeigefunktion).
NR.
2.
Zugriff auf Tabellen
2.1.
Welche Tabellengruppen drfen von Benutzern nicht gendert werden knnen?

S_TABU_DIS (Tabellenpflege) mit Aktivitt 03 (Anzeigen) und Berechtigungsgruppen
ALE0 oder SS.
Dieses Berechtigungsobjekt darf im Produktivsystem fr die beiden Berechtigungsgruppen ALE0 und SS nur mit Aktivitt 03 Anzeigen ausgeprgt werden.
2.2.
Welche Tabellengruppen drfen von Benutzern gendert werden knnen?

S_TABU_DIS (Tabellenpflege) mit Aktivitt 02 oder 03 und Berechtigungsgruppe SUSR.
Dieses Berechtigungsobjekt darf im Produktivsystem fr die Berechtigungsgruppe
SUSR nur mit den Aktivitten 02 ndern und 03 Anzeigen ausgeprgt werden.
3.
Zugriff auf IDOCS
3.1.
Welcher Zugriff auf IDOCs kann allen Benutzern eingerumt werden?

S_IDOCCTRL (allgemeiner Zugriff auf IDOC-Funktionen)
mit Aktivitt 03 und Transaktionscode * ist applikationsabhngig mglich.
Dieses Berechtigungsobjekt darf im Produktivsystem nur die Aktivitt 03
Anzeigen haben. Empfehlenswert ist auch Einschrnkung auf nicht FIspezifische Transaktionscodes.
Risiko: Ansonsten knnen FI-spezifische IDOCs, die z.B. vertrauliche Daten beinhalten,
von allen Benutzern eingesehen werden.
Hinweis: Unter allen IDOC-Berechtigungsobjekten sollte nur das Berechtigungsobjekt
S_IDOCCTRL an alle Benutzer mit den oben beschriebenen Einschrnkungen berechtigt
werden, falls berhaupt erforderlich.
3.2.
Welcher Zugriff auf IDOCs kann allen Benutzern eingerumt werden, die eine Kontrollfunktion ber IDOCs bentigen?
S_IDOCMONI (Zugriff auf IDOC-Monitoring) mit Aktivitt 03 und Richtung der IDOCbertragung 1 und 2 und Nachrichtentyp CCLONE und USERCLONE und PARTNERNUMMER * und PARTNERART LS und TRANSAKTIONSCODE: * ist applikationsabhngig mglich.
Risiko: Die Aktivitt muss 03 Anzeigen sein. Sonst knnen IDOCs, die auch
nderungsbelege sind, gendert oder gelscht werden.
Hinweis: Die Angabe des Transaktionscodes ist dann unkritisch, wenn die anderen
Felder des Berechtigungsobjekts wie oben gepflegt sind.
4.
Benutzer- und Berechtigungsadministration
4.1.
Welche Administratoren sollen Benutzer und ihre Berechtigungen auf welche Weise
verwalten drfen?
S_USER_AGR (Berechtigungswesen: Prfer fr Rollen)
mit Aktivitt * und Name der Rolle * ist kritisch.
Dieses Berechtigungsobjekt zur Benutzer- und Berechtigungsverwaltung darf im Produktivsystem nur restriktiv gem dem organisatorischen Konzept der Benutzer- und
Berechtigungsadministration belegt werden.
Risiko: Wenn diese von SAP vordefinierten, uneingeschrnkten Freigaben (*) bestehen
bleiben, kann jeder alle Aktivitten durchfhren. Insbesondere kann jeder jede Rolle
anlegen. Das kann nicht gewnscht sein.
Hinweis: Zur Einhaltung des Vieraugenprinzips mssen bei den Feldern Aktivitt und
Name der Rolle die 4 Funktionen Anlegen, ndern, Aktivieren und Zuordnen
entsprechend bercksichtigt werden.
45
46
NR.
4.2.
verwalten drfen?
S_USER_AUT (Benutzerstammpflege: Berechtigungen) mit Aktivitt * und Berechtigungsname in Benutzerstamm * und Berechtigungsobjekt * ist kritisch.
Risiko: Wenn diese von SAP vordefinierten, uneingeschrnkten Freigaben (*) bestehen
bleiben, kann jeder alle Aktivitten durchfhren. Insbesondere kann jeder jede Rolle
anlegen. Das kann nicht gewnscht sein.
Hinweis: Zur Einhaltung des Vieraugenprinzips mssen bei den Feldern Aktivitt und
Name der Rolle die 4 Funktionen Anlegen, ndern, Aktivieren und Zuordnen
Dabei sind auch die Modulverantwortlichen sofern vorgesehen unter den Benutzerund Berechtigungsadministratoren zu bercksichtigen.
4.3.
verwalten drfen?
S_HIERARCH (Berechtigungsprfungen der Hierarchiepflege) mit Aktivitt * und Paket
* und Strukturtyp * ist kritisch.
Dieses Berechtigungsobjekt zur Benutzer- und Berechtigungsverwaltung darf im
Produktivsystem nur restriktiv gem dem organisatorischen Konzept der Benutzerund Berechtigungsadministration belegt werden.
Die Mglichkeit der Einschrnkung auf die verwendete Struktur zur Berechtigungsverwaltung muss genutzt werden.
Dieses Berechtigungsobjekt ermglicht das Arbeiten mit dem allgemeinen Hierarchiepflegetool oder den darauf basierenden Transaktionen. Die Berechtigung muss eingeschrnkt werden ber den Typ der zu bearbeitenden Struktur und ber deren Paket.
4.4.
verwalten drfen?
S_USR_GRP (Benutzerstammpflege: Benutzergruppen)
mit Aktivitt * und Benutzergruppe in Benutzerstamm * ist kritisch.
Risiko: Wenn diese uneingeschrnkten Freigaben (*) bestehen bleiben, kann jeder
alle Aktivitten durchfhren. Dann kann jeder jede Benutzergruppe pflegen, auch sich
selbst. Das kann nicht gewnscht sein.
Hinweis: Zur Einhaltung des 4-Augen-Prinzips mssen bei der Aktivitt und Name der
Benutzergruppe die 4 Funktionen Anlegen, ndern, Aktivieren und Zuordnen
NR.
4.5.
verwalten drfen?
S_USR_PRO (Benutzerstammpflege: Berechtigungsprofil)
Mit Aktivitt * und Berechtigungsprofil im Benutzerstamm * ist kritisch.
Risiko: Wenn diese uneingeschrnkten Freigaben (*) bestehen bleiben, kann jeder
alle Aktivitten durchfhren. Dann kann jeder jedes Benutzerprofil pflegen. Das kann
nicht gewnscht sein.
Hinweis: Zur Einhaltung des 4-Augen-Prinzips mssen bei der Aktivitt und Name
des Berechtigungsprofils die 4 Funktionen Anlegen, ndern, Aktivieren und
Zuordnen entsprechend bercksichtigt werden.
4.6.
verwalten drfen?
S_USER_SAS (Benutzerstammpflege: Systemspezifische Zuordnungen) mit Aktivitt *,
Name der Rolle *, Benutzergruppe *, Berechtigungsprofil im Benutzerstamm und
Empfngersystem ZBV ist kritisch.
Risiko: Bei Vollausprgung kann jeder jede Benutzerausprgung und jede Rolle in
jedem System zuweisen.
Hinweis: Das neue Berechtigungsobjekt S_USER_SAS wird ber den Eintrag mit der
Id CHECK_S_USER_SAS und dem Wert YES in der Tabelle PRGN_CUST aktiviert
(OSS-Hinweis 536101) und ersetzt die Berechtigungsobjekte S_USER_GRP, S_USER_
AGR, S_USER_PRO und S_USER_SYS bezglich der Zuordnung von Rollen oder Profilen
zu Benutzern.
Die Verwendung der erweiterten Berechtigungsprfung ist unabhngig vom Einsatz der
zentralen Benutzerverwaltung.
4.7.
verwalten drfen?
S_USR_SYS (Benutzerstammpflege: System fr zentrale Benutzerpflege) spezifisches
Objekt) mit Aktivitt * und Empfngersystem ZBV ist kritisch.
Risiko: Bei Vollausprgung kann jeder in allen Systemen Rollen zuweisen.
47
48
NR.
4.8.
verwalten drfen?
S_USER_TCD (Berechtigungswesen: Transaktionen in Rollen) mit Transaktionscode *
ist kritisch.
Risiko: Bei Vollausprgung knnen modul- und basisbergreifend alle Berechtigungsobjekte in Rollen aufgenommen werden.
4.9.
verwalten drfen?
S_USER_VAL (Berechtigungswesen: Feldwerte in Rollen)
mit Feldname * und Berechtigungswert * und Berechtigungsobjekt * ist kritisch.
Risiko: Bei Vollausprgung knnen modul- und basisbergreifend alle Berechtigungsobjekte in Rollen aufgenommen werden.
4.10. PRFPROGRAMM: ORDNUNGSMSSIGE BERECHTIGUNGS- UND

BENUTZERORGANISATION
NR.
ORDNUNGSMSSIGE BERECHTIGUNGS- UND BENUTZERORGANISATION
1.
Kontrollziel: Einhaltung der Funktionstrennung, kein Administrator darf die folgenden

drei zu trennenden Aufgaben durchfhren:
1. Benutzer verwalten
2. Berechtigungen pflegen
3. Berechtigungsprofile generieren
Risiko: Die Aufgaben des Benutzer- und Berechtigungsverwalters werden in vollem
Umfang an einen oder mehrere Mitarbeiter vergeben. Eine berwachung der Ttigkeiten
eines Benutzer- und Berechtigungsverwalters gibt es nicht. Die Folgen sind:
nicht autorisierte nderungen sind mglich,
betrgerische Handlungen knnen durchgefhrt und die Spuren dazu zumindest
verschleiert werden.
1.1.
Sind die Mglichkeiten der Funktionstrennung bezogen auf die Ressourcen und
die Sicherheitsanforderungen des Unternehmens umgesetzt?
Beispiele fr die Realisierung eines 4-Augen-Prinzips und eines 6-Augen-Prinzips
sind in den folgenden bersichten aufgefhrt.
NR.
ORDNUNGSMSSIGE BERECHTIGUNGS- UND BENUTZERORGANISATION

Scenario 1: 4-Augen-Prinzip
Zentrale Benutzerverwaltung
Ein Benutzerverwalter fr alle Benutzer.
Unbegrenzte Berechtigungen fr alle Benutzerverwaltungsaufgaben des
Benutzeradministrators.
Zentrale Pflege von Rollen und Profilen
Ein Administrator bernimmt beide Rollen:
Berechtigungsdatenverwalter,
Berechtigungsprofilverwalter.
Scenario 2: 6-Augen-Prinzip
Dezentrale Benutzerverwaltung (Produktivsystem)
Ein Benutzerverwalter fr pro Anwendungsbereich (FI, MM),
berechtigt, um eine bestimmte Benutzergruppe zu pflegen,
berechtigt, um eine bestimmte Menge von Rollen/Profilen zuzuordnen,
keine weiteren Einschrnkungen auf spezifische Benutzerverwaltungsaufgaben.
Trennung der Zustndigkeiten:
Keine weiteren Einschrnkungen auf spezifische Rollen oder Profile.
Scenario 3: 6-Augen-Prinzip, dezentrale Benutzerverwaltung im Produktivsystem
Zentrales Anlegen und Lschen fr alle Benutzer
Ein Benutzerverwalter fr pro Anwendungsbereich (FI, MM),
berechtigt fr nur einige Benutzerverwaltungsaufgaben: ndern, sperren/entsperren,
Kennwort zurcksetzen.
49
50
4.11. TABELLEN: BEISPIELSZENARIEN DER ORGANISATION EINER

BENUTZER- UND BERECHTIGUNGSVERWALTUNG
4.11.1. SZENARIO 1: 4-AUGEN-PRINZIP
Zentrale Benutzerverwaltung
Ein Benutzerverwalter fr alle Benutzer
Unbegrenzte Berechtigungen fr alle Benutzerverwaltungsaufgaben
des Benutzeradministrators
Ein Administrator bernimmt beide Rollen:
Berechtigungsdatenverwalter
Berechtigungsprofilverwalter
A. Ohne Berechtigungsobjekt S_USER_SAS
ENTWICKLUNG
PRODUKTIV
Benutzeradministrator
Berechtigungsdaten- und
Benutzerverwalter
ACTVT
03, 08
CLASS
ACTVT
03, 22
03, 22
ACT_GROUP
Szenario 1
S_USER_GRP
S_USER_AGR
S_USER_TCD
TCD
S_USER_VAL
OBJECT
AUTH_FIELD
AUTH_VALUE
ENTWICKLUNG
PRODUKTIV
Benutzerverwalter
ACTVT
03, 08, 22
03, 08, 22
PROFILE
ACTVT
03, 08
03, 08
OBJECT
AUTH
Szenario 1
S_USER_PRO
S_USER_AUT
Bei aktiver ZBV

S_USER_SYS
ACTVT
03, 78
03, 78
SUBSYSTEM
51
52
B. Mit aktiviertem Berechtigungsobjekt S_USER_SAS
ENTWICKLUNG
Szenario 1
PRODUKTIV
Benutzerverwalter
S_USER_GRP
ACTVT
03, 08
CLASS
S_USER_AGR
ACTVT
ACT_GROUP
S_USER_TCD
TCD
S_USER_VAL
OBJECT
AUTH_FIELD
AUTH_VALUE
S_USER_PRO
ACTVT
PROFILE
S_USER_AUT
ACTVT
03, 08
03, 08
OBJECT
AUTH
ENTWICKLUNG
Szenario 1
PRODUKTIV
Benutzerverwalter
Bei aktiver ZBV

wird zustzlich das
Berechtigungsfeld SUBSYSTEM
gepflegt
S_USER_SAS
ACTVT
22
22
CLASS
SUBSYSTEM
ACT_GROUP
PROFILE
53
54
4.11.2. SZENARIO 2: 6-AUGEN-PRINZIP

Ein Benutzerverwalter pro Anwendungsbereich (FI, MM),
keine weiteren Einschrnkungen auf spezifische Benutzerverwaltungsaufgaben.
ENTWICKLUNG
PRODUKTIV
FIBenutzerverwalter
MMBenutzerverwalter
ACTVT
03, 08
03, 22
CLASS
FI_USER
MM_USER
ACTVT
03, 22
01, 02, 03, 06
03, 64
03, 22
03, 22
ACT_GROUP
Szenario 2
S_USER_GRP
S_USER_AGR
S_USER_TCD
TCD
S_USER_VAL
OBJECT
AUTH_FIELD
AUTH_VALUE
S_USER_PRO
ENTWICKLUNG
Szenario 2
ACTVT
PROFILE
PRODUKTIV
FIBenutzerverwalter
MMBenutzerverwalter
03, 08, 22
01, 02, 03,

06, 08
03, 07, 08
03, 08, 22
03, 08, 22
FI*
MM*
ACTVT
03, 08
01, 02, 03, 06,

08, 22
03, 07, 08
03, 08
03, 08
OBJECT
AUTH
ACTVT
03, 78
03, 78
03, 78
SUBSYSTEM
S_USER_AUT
Bei aktiver
ZBV
S_USER_SYS
55
56
ENTWICKLUNG
ACTVT
03, 08
03, 08
CLASS
ACTVT
01, 02, 03, 06
03, 64
ACT_GROUP
Szenario 2
PRODUKTIV
FIBenutzerverwalter
MMBenutzerverwalter
S_USER_GRP
S_USER_AGR
S_USER_TCD
TCD
S_USER_VAL
OBJECT
AUTH_FIELD
AUTH_VALUE
S_USER_PRO
ACTVT
01, 02, 03,

06, 08
03, 07, 08
PROFILE
S_USER_AUT
ACTVT
03, 08
01, 02, 03, 06,

08, 22
03, 07, 08
03, 08
03, 08
OBJECT
AUTH
ENTWICKLUNG
Szenario 2
PRODUKTIV
FIBenutzerverwalter
MMBenutzerverwalter
Bei aktiver
ZBV wird zustzlich das
Berechtigungsfeld
SUBSYSTEM
gepflegt
S_USER_SAS
ACTVT
22
22
22
CLASS
FI_USER
MM_USER
SUBSYSTEM
ACT_GROUP
FI*
MM*
PROFILE
FI*
MM*
57
58
4.11.3. SZENARIO 3: 6-AUGEN-PRINZIP, DEZENTRALE BENUTZERVERWALTUNG

IM PRODUKTIVSYSTEM
Zentrales Anlegen und Lschen fr alle Benutzer
Ein Benutzerverwalter pro Anwendungsbereich (FI, MM),
berechtigt fr nur einige Benutzerverwaltungsaufgaben: ndern, sperren/entsperren,
Kennwort zurcksetzen.
Keine weiteren Einschrnkungen auf spezifische Rollen oder Profile
ENTWICKLUNG
PRODUKTIV
ACTVT
03, 08
CLASS
ACTVT
ACT_GROUP
Szenario 3
FIBenutzerverwalter
MMBenutzerverwalter
Zentraler
Benutzerverwalter
03, 08
02, 03,
05, 22
02, 03,
05, 22
01, 03, 06,

08
FI_USER
MM_
USER
03, 22
01, 02, 03,

06
03, 64
03, 22
03, 22
S_USER_GRP
S_USER_AGR
S_USER_TCD
TCD
S_USER_VAL
OBJECT
AUTH_FIELD
ENTWICKLUNG
Szenario 3
AUTH_VALUE
PRODUKTIV
FIBenutzerverwalter
MMBenutzerverwalter
Zentraler
Benutzerverwalter
S_USER_PRO
ACTVT
03, 08, 22
01, 02, 03,

06, 08
03, 07, 08
03, 08, 22
03, 08, 22
03, 08
PROFILE
FI*
MM*
ACTVT
03, 08
01, 02, 03,

06, 08, 22
03, 07, 08
03, 08
03, 08
03, 08
OBJECT
AUTH
S_USER_AUT
Bei aktiver
ZBV
S_USER_SYS
ACTVT
03, 78
03, 78
03, 78
03, 78
SUBSYSTEM
59
60
ENTWICKLUNG
ACTVT
03, 08
03, 08
CLASS
ACTVT
01, 02, 03,

06
03, 64
ACT_GROUP
Szenario 3
PRODUKTIV
FIBenutzerverwalter
MMBenutzerverwalter
Zentraler
Benutzerverwalter
S_USER_GRP
S_USER_AGR
S_USER_TCD
TCD
S_USER_VAL
OBJECT
AUTH_FIELD
AUTH_VALUE
S_USER_PRO
ACTVT
01, 02, 03,

06, 08
03, 07, 08
PROFILE
S_USER_AUT
ACTVT
03, 08
01, 02, 03,

06, 08, 22
03, 07, 08
03, 08
03, 08
03, 08
OBJECT
AUTH
ENTWICKLUNG
Szenario 3
PRODUKTIV
FIBenutzerverwalter
MMBenutzerverwalter
Zentraler
Benutzerverwalter
Bei aktiver
ZBV wird
zustzlich
das Berechtigungsfeld
SUBSYSTEM
gepflegt
S_USER_SAS
ACTVT
22
22
22
22
CLASS
FI_USER
MM_
USER
SUBSYSTEM
ACT_GROUP
FI*
MM*
PROFILE
FI*
MM*
61
62
4.12. PRFPROGRAMM: BERECHTIGUNGEN FR DIE BENUTZER- UND

BERECHTIGUNGSVERWALTUNG
NR.
BERECHTIGUNGSVERWALTUNG: BENUTZER
1.
Das Objekt Benutzerstammpflege, Benutzergruppen S_USER_GRP, legt die Benutzergruppen und die zulssigen Aktivitten fest, fr die ein Benutzerverwalter berechtigt
ist. Damit knnen Benutzer angelegt, gepflegt, ge- und entsperrt werden, insbesondere
auch das Kennwort eines Benutzers gendert werden.
Es kann benutzt werden, um bei einer dezentralisierten Verwaltung einem Benutzeradministrator nur die Verwaltung einer bestimmten Benutzergruppe zu ermglichen.
1.1.
Wer kann Benutzer anlegen?

S_TCODE = SU01
S_USER_GRP (Benutzergruppen) mit Aktivitt * oder 01 (Anlegen) und Gruppe = *
1.2.
Wer kann Benutzereigenschaften ndern (auer den Zugriffsrechten)?

S_TCODE = SU01
S_USER_GRP (Benutzergruppen) mit Aktivitt * oder 02 (ndern) und Gruppe = *
1.3.
Wer kann Benutzer sperren oder lschen?

S_TCODE = SU01
S_USER_GRP (Benutzerverwaltung) mit Aktivitt * oder 05 (Sperren) oder 06 (Lschen)
und Gruppe = * oder = Gruppennamen.
2.
Das Objekt Benutzerstammpflege, System fr die zentrale Benutzerpflege S_USER_

SYS, legt fest, auf welches System ein Benutzerverwalter aus der Zentralen Benutzerverwaltung mit welchen zulssigen Aktivitten zugreifen kann.
1.5.
Wer kann aus der Zentralen Benutzerverwaltung Benutzer ndern?

S_TCODE = SU01 oder PFCG
S_USER_SYS (Benutzerpflege) mit Aktivitt * oder 02 (ndern) und SUBSYSTEM = *
oder = Logisches System.
NR.
BERECHTIGUNGSVERWALTUNG: ROLLEN
3.
Das Objekt Berechtigungswesen, Prfung fr Rollen S_USR_AGR legt die Rollennamen und die zulssigen Aktivitten fest, fr die ein Berechtigungsverwalter berechtigt
ist. Damit knnen Rollen angelegt und gepflegt werden.
Es kann benutzt werden, um bei einer dezentralisierten Administration einem Berechtigungsverwalter nur Zugriff auf bestimmte Rollen zugeben, z.B. fr ein Modul oder eine
Organisationseinheit.
3.1.
Wer kann Rollen anlegen (ohne Berechtigungswerte)?

S_TCODE = PFCG
S_USER_AGR (Rollen verwalten) mit Aktivitt *, 01 (Anlegen) und Rolle = * oder =
Rollennamen
NR.
BERECHTIGUNGSVERWALTUNG: ROLLEN
3.2.
Wer kann Rollen ndern (ohne Berechtigungswerte)?

S_TCODE = PFCG
S_USER_AGR (Rollen verwalten) mit Aktivitt * oder 02 (ndern) und Rolle = * oder =
Rollennamen.
4.
Das Objekt Berechtigungswesen, Transaktionen in Rollen S_USR_TCD legt fest, welche

Transaktionen ein Berechtigungsverwalter in eine Rolle aufnehmen darf.
Es kann benutzt werden, um einem Berechtigungsverwalter nur die Aufnahme bestimmter Transaktionen in Rollen zu erlauben und damit die Vergabe kritischer Transaktionen zu verhindern.
4.1.
Wer ist fr S_USER_AGR berechtigt und kann Transaktionen anlegen (ohne Berechtigungswerte)?
S_TCODE = PFCG
S_USER_AGR (Rollen verwalten) mit Aktivitt * oder 01 (Anlegen) oder 02 (ndern) und
Rolle = * oder = Rollennamen.
S_USER_TCD (Transaktionen in Rollen) mit Transaktionscode * oder = Transaktionsname.
5.
Das Objekt Berechtigungswesen, Feldwerte fr Rollen S_USR_VAL legt fest, fr

welche Berechtigungsobjekte und fr welche Felder ein Berechtigungsverwalter welche
Feldwerte in eine Rolle eintragen darf.
Es kann benutzt werden, um einem Berechtigungsverwalter nur die Vergabe bestimmter Berechtigungen in Rollen zu erlauben und damit die Vergabe kritischer Berechtigungen in Rollen zu verhindern.
5.1.
Wer kann Rollen mit allen Berechtigungswerten ndern?

S_TCODE = PFCG
S_USER_AGR (Rollen verwalten) mit Aktivitt * oder 01 (Anlegen), 02 (ndern) und
Rolle = * oder = Rollennamen
S_USER_VAL (Objektverwendung in Rollen) mit * in allen Feldern
NR.
BERECHTIGUNGSVERWALTUNG: PROFILE UND BERECHTIGUNGEN
6.
Das Objekt Benutzerstammpflege, Berechtigungsprofil S_USR_PRO legt die Profilnamen

sowie die zulssigen Aktivitten fest, fr die ein Berechtigungsverwalter berechtigt ist.
Es kann benutzt werden, um bei einer dezentralisierten Benutzerverwaltung einem Benutzerverwalter nur die Zuordnung bestimmter Profile zu ermglichen, z.B. fr ein Modul oder
eine Organisationseinheit.
6.1.
Wer kann Profile anlegen?

S_TCODE = SU02
S_USER_PRO (Profile verwalten) mit Aktivitt * oder 01 (Anlegen) und Profil = * oder
= Profilnamen.
63
64
NR.
BERECHTIGUNGSVERWALTUNG: PROFILE UND BERECHTIGUNGEN
6.2.
Wer kann Profile ndern?

S_TCODE = SU02
S_USER_PRO (Profile verwalten) mit Aktivitt * oder 02 (ndern) und Profil = *
oder = Profilnamen
7.
Das Objekt Benutzerstammpflege, Berechtigungen S_USR_AUT legt die Berechtigungsobjektnamen und die Berechtigungsnamen sowie die zulssigen Aktivitten
fest, fr die ein Berechtigungsverwalter berechtigt ist.
Es kann benutzt werden, um bei einer dezentralisierten Benutzerverwaltung einem
Berechtigungsverwalter nur die Erstellung bestimmter Berechtigungen in Profilen zu
erlauben und damit die Erstellung kritischer Berechtigungen in Profilen zu verhindern.
NR.
BERECHTIGUNGSVERWALTUNG: ROLLEN DEN BENUTZERN ZUORDNEN
8.1.
Wer kann Rollen Benutzern zuordnen?

S_TCODE = PFCG
S_USER_AGR (Rollen verwalten) mit Aktivitt * oder 02 (ndern) und 22 (Zuordnen) und
Rolle = * oder = Rollennamen
S_USER_GRP (Benutzerverwaltung) mit Aktivitt * oder 22 (Zuordnen) und Gruppe = *
8.2.
Wer kann Benutzern Profile zuordnen und entziehen?

S_TCODE = SU01 oder PFCG
S_USER_GRP (Benutzerverwaltung) mit Aktivitt * oder 02 (ndern) und Gruppe = *
oder = Gruppennamen
S_USER_PRO (Profile verwalten) mit Aktivitt* oder 22 (Zuordnen) und Profil = *
oder = Profilnamen.
8.3.
Wer kann Benutzern Rollen oder Profile zuordnen und entziehen?

S_TCODE = SU01
S_USER_GRP (Benutzerverwaltung) mit Aktivitt * oder 02 (ndern) und Aktivitt 22
(Zuordnen) und Gruppe = * oder = Gruppennamen
S_USER_PRO (Profile verwalten) mit Aktivitt * oder 22 (Zuordnen) und Profil = *
oder = Profilnamen
S_USER_AGR (Rollen verwalten) mit Aktivitt * oder 22 (Zuordnen) und Rolle = *
oder = Rollennamen.
4.13. PRFPROGRAMM: SICHERHEITSMECHANISMEN ZUR

AKTIVIERUNG DER PRFUNG VON BERECHTIGUNGEN
1.1.
Berechtigungsverwaltung: Wer kann Berechtigungsobjekte deaktivieren?

S_TCODE = AUTH_SWITCH_OBJECTS
S_USER_OBJ (Objekte verwalten) mit Aktivitt 02 (ndern) und 07 (Aktivieren) und Objekt = * oder = Objektnamen.
Diese Berechtigung ist restriktiv an Systemadministratoren zu vergeben. Das Deaktivieren von Berechtigungsobjekten muss freigegeben und dokumentiert werden.
Hinweis: Mit der Transaktion AUTH_ SWITCH_ OBJECTS knnen Berechtigungsobjekte
global ausgeschaltet werden.
Fr ausgeschaltete Berechtigungsobjekte fgt der Profilgenerator keine
Berechtigungen in die generierten Profile ein.
Beim Wiedereinschalten eines Objektes muss daher eventuell eine groe Anzahl
von Rollen bzw. Profilen bearbeitet werden. Das Abschalten von Objekten wird auch
aus diesem Grund nicht empfohlen.
Berechtigungsobjekte, die mit S_ und P_ beginnen (Bereiche Basis und HR), lassen
sich grundstzlich nicht global ausschalten.
Ein berblick ber global ausgeschaltete Objekte kann mit der Transaktion
AUTH_DISPLAY_OBJECTS angezeigt werden.
Im Anwendungsprotokoll (Transaktion SLG1) wird unter dem Objektnamen
PRGN_LOG_OBJ das globale Ein- und Ausschalten von Objekten protokolliert.
1.2.
Ist der Profilgenerator aktiviert?

AIS: System Audit - Top Ten Security Reports Profilparameter anzeigen (auth/*)
AIS: System Audit Systemkonfiguration Parameter Systemparameter,
bersicht mit Historie
Seit Version 4.6C ist der Profilparameter auth/no_check_in_some_cases auf den
Wert Y (Defaultwert) gesetzt.
1.3.
Wer kann die Prfkennzeichen und Vorschlagswerte des Profilgenerators pflegen?

S_TCODE = SU24
S_DEVELOP (Anwendungsentwicklung) mit Aktivitt 02 (ndern) und Objekttypen
SUSK (Zuordnung Transaktion zu Berechtigungsobjekt im Kundenstamm,
USOBX_C und USOBT_C)
SUST (Zuordnung Transaktion zu Berechtigungsobjekt in SAP-Systemen,
USOBX und USOBT
und Objektname = * (alle Transaktionen) oder = Name einer Transaktion, die zu
bearbeiten ist.
Diese Berechtigung ist restriktiv an Systemadministratoren zu vergeben. Die Pflege
der Prfkennzeichen und Vorschlagswerte des Profilgenerators muss freigegeben und
dokumentiert werden.
65
66
1.4.
Werden indirekte Transaktionsaufrufe einer Berechtigungsprfung unterzogen?

Ist in der Tabelle TCDCOUPLES im Feld OKFLAG bei den aufgefhrten Transaktionspaaren ein X gesetzt?
Hinweis: Wird eine Transaktion indirekt, d.h. von einer anderen Transaktion
aufgerufen, so wird keine Berechtigungsprfung vorgenommen. So werden
z.B. Berechtigungen nicht geprft, wenn eine Transaktion eine andere mit
der Anweisung CALL TRANSACTION aufruft (SAP-Hinweis 358 122).
1.5.
Ist bei Transaktionsaufrufen die Berechtigungsprfung deaktiviert?

Ist in der Tabelle USOBX_C im Feld OKFLAG ein N und im Feld MODIFIED
ein X gesetzt?
Hinweis: Ist die Berechtigungsprfung fr ein Berechtigungsobjekt einer Transaktion
ber die SU24 deaktiviert worden, ist dies in der Tabelle USOBX_C nachvollziehbar.
Fr deaktivierte Berechtigungsobjekte ist zu prfen, ob eine entsprechende Freigabe
vorliegt.
5.1. PRFPROGRAMM: SCHUTZ DER BATCH-INPUT-PROZESSE

NR.
SCHUTZ DER BATCH-INPUT-PROZESSE
1.
Kontrollziel: Die ordnungsmige Verarbeitung der Geschftsdaten und des

Buchungsstoffs ist sichergestellt.
1. Die Vollstndigkeit, Richtigkeit und Zeitgerechtigkeit der Verarbeitung ist
sicherzustellen, insbesondere bei Daten der Buchhaltung.
2. ber Arbeitsanweisungen ist sichergestellt, dass die Vollstndigkeit der Verarbeitung
berwacht wird und die notwendigen Manahmen zur Nachbearbeitung von Belegen
durchgefhrt werden.
3. Das interne Kontrollsystem verlangt eine Funktionstrennung zwischen planender,
ausfhrender und berwachender Stelle.
Risiko: Belege werden nicht verarbeitet. Fehlerhafte oder nicht vollstndige Belege
werden nicht korrigiert. Die gleichen Belege werden mehrfach eingelesen. Belege werden in falscher Reihenfolge bearbeitet, z.B. Stammdatennderungen nach Buchungen,
die diese Stammdatennderungen zur Voraussetzung hatten. Fehler- und Verarbeitungsprotokolle werden gelscht, bevor sie als Hinweise fr notwendige Korrekturen
oder als Nachweise der ordnungsmigen Verarbeitung verwendet worden sind.
1.1.

Gibt es eine bersicht ber alle Batch-Input-Schnittstellen, z.B. mit den folgenden
Angaben: abgebendes Arbeitsgebiet, Dateninhalt, Dateiname, Periode, Mappenname, Verarbeitungsjob, relevante Tabellen, Abstimmkreis, Verantwortlichkeit?
Welche Anwender drfen welche Mappen erstellen, starten, korrigieren oder
lschen?
Gibt es eine bersicht, welche Mappennamen fr welche Abteilung reserviert sind?
Wer stimmt den Buchungsstoff der verarbeiteten Mappen ab?
Wer kontrolliert, dass die Daten aus den Vorsystemen vollstndig, richtig und
zeitgerecht bernommen werden? Wird insbesondere ein mehrfaches Einlesen
der gleichen Belege verhindert? Werden die Dateien nach dem Einlesen gesichert
und gelscht?
Sind die internen Kontrollen zwischen Vorsystemen und dem Zielsystem gewahrt,
in dem die Mappen abgespielt werden?
1.2.
Analyse der Batch-Input-Mappen

AIS: System Audit Hintergrundverarbeitung Batch-Input-Monitoring
Oder Transaktion SM35
1.3.
Wer darf alle Batch-Input-Mappen uneingeschrnkt verwalten?

S_TCODE = SM35
S_BDC_MONI (Batch-Input-Berechtigung) mit Aktivitt * und Mappennamen = *
oder speziell auf alle kritischen Verwaltungsaktionen bezogen:
S_BDC_MONI (Batch-Input-Berechtigung) mit Aktivitten ABTC (Hintergrundverarbeitung), FREE (Freigeben), LOCK (Ent-/Sperren), DELE (Lschen) und REOG (Reorganisieren) und Mappennamen = *.
Diese Berechtigung ist nur an Systemadministratoren zu vergeben.
5. SYSTEMINTEGRITT AUF DER

ANWENDUNGSEBENE
67
68
NR.
1.4.
Wer kann Batch-Input-Mappen freigeben?

S_TCODE = SM35
S_BDC_MONI (Batch-Input-Berechtigung) mit Aktivitt FREE (Mappen freigeben) und
Mappennamen = *.
Hierbei ist die Funktionstrennung (4-Augen-Prinzip) einzuhalten.
1.5.
Wer kann Batch-Input-Mappen und Protokolle analysieren?

S_TCODE = SM35
S_BDC_MONI (Batch-Input-Berechtigung) mit Aktivitt ANAL (Mappen und Protokolle
analysieren) und Mappennamen = *.
1.6.
Wer kann Batch-Input-Mappen im Dialogbetrieb oder im Hintergrund verarbeiten?

S_TCODE = SM35
S_BDC_MONI (Batch-Input-Berechtigung) mit Aktivitt ABTC (Mappen fr die Hintergrundverarbeitung bergeben) oder AONL (Mappen im Dialogbetrieb abspielen) und
Mappennamen = *.
Risiko: Im Dialogbetrieb knnen Werte in Eingabefeldern berschrieben werden.
1.7.
Wer kann Batch-Input-Mappen (ent-)sperren?

S_TCODE = SM35
S_BDC_MONI (Batch-Input-Berechtigung) mit Aktivitt LOCK (Mappen sperren oder
entsperren) und Mappennamen = *.
1.8.
Wer kann Batch-Input-Mappen und Protokolle reorganisieren?

S_TCODE = SM35
S_BDC_MONI (Batch-Input-Berechtigung) mit Aktivitt REOG (Mappen und Protokolle
reorganisieren) und Mappennamen = *.
Risiko: Verarbeitungsnachweise knnen ber einen Reorganisationslauf gelscht
werden.
1.9.
Wer kann Batch-Input-Mappen lschen?

S_TCODE = SM35
S_BDC_MONI (Batch-Input-Berechtigung) mit Aktivitt DELE (Mappen lschen) und
Mappennamen = *.
Risiko: Mappen z.B. mit relevantem Buchungsstoff knnen vor der Weiterverarbeitung
gelscht werden.
1.A
Ist die bergabedatei ber geeignete Dateizugriffsrechte geschtzt?

Transaktion AL11 Attribute der bergabedatei
Risiko: Die bergabedatei kann vor der Verarbeitung manipuliert werden. Eine
Protokollierung findet nicht statt. Die Datenintegritt ber Systemgrenzen ist nicht
mehr gewhrleistet.
NR.
2.
Kontrollziel: Gewhrleistung des ordnungsmigen Programmeinsatzes und der

Datenintegritt, wenn beim Direct-Input-Verfahren die Daten mit reduzierten
Plausibilittsprfungen direkt in die Datenbank geschrieben werden.
Risiko: Es ist mglich, vorhandene Datenbestnde unprotokolliert zu verndern. Bei
einer fehlerhaften Anwendung ist die Datenintegritt des Systems gefhrdet. Auf die
Verwendung der Transaktion LSMW oder den direkten Aufruf der jeweiligen Reports
sollte aus Grnden der Datenintegritt verzichtet werden. Nur die Transaktion bietet
einen Wiederaufsetzmechanismus.
2.1.
Wird das Verfahren des Direct-Input genutzt?

Prfen ber die Transaktion BMV0 (Verwaltung von Datenbernahmen).
2.2.

Ist der Einsatz des Direct-Input-Verfahrens dokumentiert?
Wird der Einsatz eines Direct-Input-Ablaufs vor dem produktiven Einsatz im
Testsystem getestet und nach dem 4-Augen-Prinzip freigegeben?
Gibt es eine Verfahrensanweisung, wie der Prozess des Direct-Input berwacht
und wie fehlerhafte Ablufe behandelt werden?
2.3.1.
Wer kann einen Direct-Input-Job definieren?

S_TCODE = BMV0
S_TABU_DIS mit ACTVT 02 und DICBERCLS SS.
2.3.2.
Wer kann einen Direct-Input-Job definieren?

S_TCODE = SXDA
S_TABU_DIS mit ACTVT 02 und DICBERCLS SS.
S_DX_MAIN mit TCD SXDA und ACTVT 03
S_DX_PROJ mit TCD SXDA und ACTVT 16
2.4.1.
Wer kann einen Direct-Input-Job starten, wiederaufsetzen, verwalten?

S_TCODE = BMV0
S_BDC_MONI mit BDCACTI ABTC oder REOG
S_BTCH_JOB mit Jobaction RELE
S_DATASET mit ACTVT 33 und Program
RMDATIND
RM06EEI0
RM06EEI1
RSTXLITF
RVINVB10
RFBIBL00
RCCLBI03
RAALTD11
RCPTRA02
RM60IN00
RCRAPDX2
RFVIMEDI
RFVIMVDI
RIIBIP00
RSADRLSM02
69
70
NR.
2.4.2.
Wer kann einen Direct-Input-Job starten, wiederaufsetzen, verwalten?

S_TCODE = SXDA
S_BDC_MONI mit BDCACTI ABTC oder REOG
S_BTCH_JOB mit Jobaction RELE
S_DX_MAIN mit TCD SXDA und ACTVT 03
S_DX_PROJ mit TCD SXDA und ACTVT 16 oder 02
RMDATIND
RM06EEI0
RM06EEI1
RSTXLITF
RVINVB10
RFBIBL00
RCCLBI03
RAALTD11
RCPTRA02
RM60IN00
RCRAPDX2
RFVIMEDI
RFVIMVDI
RIIBIP00
RSADRLSM02
2.4.3.
Wer kann einen Direct-Input-Job starten, wiederaufsetzen?

S_TCODE = LSMW
B_LSMW mit ACTVT 16 und TCD LSMW
B_LSMW_PRO mit Project <variabel>
RMDATIND
RM06EEI0
RM06EEI1
RSTXLITF
RVINVB10
RFBIBL00
RCCLBI03
RAALTD11
RCPTRA02
RM60IN00
RCRAPDX2
RFVIMEDI
RFVIMVDI
RIIBIP00
RSADRLSM02
6. SYSTEMINTEGRITT MIT DEM

SAP JAVA-STACK
6.1. BERBLICK
Im Jahr 2004 hat SAP die NetWeaver-Technologie eingefhrt und erstmalig den sogenannten
Java-Stack (SAP AS Java) implementiert. Die Technologieplattform NetWeaver dient als Grundlage fr eine serviceorientierte Architektur, um durchgngige Prozesse mit Anwendungen der SAP
Business Suite zu gewhrleisten. Das aktuelle Release 7.4 kann als eigenstndige Installation
oder im sogenannten Dual-Stack mit einem ABAP-System betrieben werden. SAP stellt den
Java-Stack auf einem Anwendungsserver gem der Spezifikation J2EE (Java 2 Enterprise Edition)
bzw. Java EE Standard bereit. Der Leitfaden zielt auf die Absicherung und Beschreibung von Kontrollen des SAP AS Java sowohl fr eine reine Java-Instanz als auch fr einen parallelen Betrieb mit
dem AS ABAP. Zudem ist eine Mischung von ABAP/Java-Komponenten im AS ABAP mglich, auf
die in diesem Abschnitt nicht eingegangen wird. Risiken bei der Verwendung von Java im AS ABAP
mssen ber Kontrollen im AS ABAP behandelt werden.
SAP GUI
Browser
Internet Communication Manager (ICM)
(ABAP-)Dispatcher
WP
WP
ABAP
VM
ABAP
VM
ABAP
VM
Java
VM
Java
VM
Java
VM
Gateway
WP
Java-Dispatcher
AS
ABAP
SAP Datenbank-Schema
JCo
MessageServer
EnqueueServer
Central
Services
Java
SP
Java
SP
Java
VM
Java
VM
SDM
AS
Java
SAP Datenbank-Schema
71
72
6.2. RISIKEN
Die Sicherheitsanforderungen der Java-Architektur sind nicht bekannt, ermittelt und
umgesetzt.
Schwchen in der Konfiguration ermglichen den unautorisierten Zugriff auf Daten.
Unsichere Passwrter von Standardbenutzern gefhrden die Sicherheit und Integritt
von Daten.
Ein geregeltes Softwarenderungs- und Einsatzverfahren ist nicht umgesetzt. Es besteht
das Risiko, dass schwachstellenbehaftete und nicht autorisierte Java-Anwendungen
betrieben werden. Die Vertraulichkeit, Integritt und Verfgbarkeit von Daten kann nicht
gewhrleistet werden.
6.3. KONTROLLZIELE
Die Sicherheitsempfehlungen von SAP zur sicheren Konfiguration der Java-Architektur sind
umgesetzt.
Standardbenutzer verfgen ber sichere Passwrter. UME-Rollen sind gem IKS Anforderungen eingerichtet.
Die Anforderungen an ein geregeltes Softwarenderungs- und Einsatzverfahren sind
mit den Mitteln von SAP untersttzt (SDM, SPML und CMS).
Portaldienste und Anwendungen sind ausreichend vor Webrisiken abgesichert.
6.4. SAP AS JAVA SYSTEMARCHITEKTUR

Zum Verstndnis der Kontrollen, Risiken und der Durchfhrung der Kontrollhandlungen ist
ein grundlegendes Verstndnis der AS-Java-Architektur notwendig. Folgende Abbildung
stellt relevante Komponenten der Architektur von AS Java dar:
Untrusted
DMZ 1
Server Network
Admin LAN
Visual / Shell
Administrator
SDM Client
P4
SSL
Userpersistant storage
SAP AS JAVA
Cluster
HTTP
SSL
Application
Level Gateway
or Reverse
Proxy
Configtool
ASP GUI
SAP DIAG
SNC
JDBC
SSL
J2EE Dispatcher
ICM
WebBrowser
J2EE-Kernel
LDAP
SSL
SDM Dienst
RFC
SNC
ASP GUI
RFC
SNC
Database
LDAP
SAP Web
AS-ABAP
HTTP
SSL
SAP Web AS
Systems
Webappl.
(SAP, non SAP)
Backend Systems
Die einzelnen Komponenten und AS-Java-Tools werden in den beiden folgenden Tabellen kurz
vorgestellt.
TABELLE 1: SAP-PROGRAMMBESCHREIBUNGEN
PROGRAMM
BESCHREIBUNG
SAP J2EE Engine

(AS Java)
Die SAP J2EE Engine untersttzt unterschiedliche Ablagen zum

Sichern von Benutzerinformationen. Standardmig ist die User
Management Engine (UME) die aktive Benutzerablage; alternativ
dazu kann die J2EE-eigene DBMS-Benutzerablage verwendet
werden.
User Management
Engine (UME )
Die User Management Engine dient allen Java-Applikationen

als Benutzer-Directory und ist fhig, Benutzer aus mehreren
Quellen zu bearbeiten. J2EE SAP Engine der SAP WEB AS Java
integriert die UME als zentralen Benutzer-Manager und kann
UME mithilfe des eigenen Administrationstools warten.
Internet Communication Manager

(ICM)
Der Internet Communication Manager gewhrleistet die Kommunikation zwischen dem SAP-System (SAP Web Application
Server) mit der Auenwelt ber die Protokolle HTTP, HTTPS und
SMTP. In der Serverrolle kann er Anfragen aus dem Internet
bearbeiten, die mit URLs mit der Server/Port-Kombination, auf
die der ICM hrt, ankommen. Abhngig von der URL ruft der ICM
dann den entsprechenden lokalen Handler auf.
73
74
PROGRAMM
BESCHREIBUNG
SAP Web Dispatcher
Der SAP Web Dispatcher steht zwischen dem Internet und dem
SAP-System (SAP Web AS). Er ist der Einstiegspunkt fr HTTP(S)-Request. Als Software-Web-Switch kann er Verbindungen
abweisen oder annehmen und nimmt dann die Request-Verteilung fr eine gleichmige Serverauslastung vor (Lastausgleich).
ICF Modul (Internet

Communication
Framework)
Das Internet Communication Framework (ICF) ist integriert in

den SAP Web Application Server. Es bietet eine Umgebung zur
Behandlung von HTTP Requests in ABAP-Prozessen. ICF dient
als Server oder Client fr SAP WEB AS HTTP Requests.
AS ABAP
ABAP-Anwendungsprogrammewerden in der Programmiersprache ABAP erstellt und laufen in derABAP-Anwendungsschichtdes SAP NetWeaverApplicationServer ABAP.
Service Provisioning
Markup Language
(SPML)
Die Service Provisioning Markup Language (SPML) ist ein

XML-basiertes Framework fr den Austausch von Benutzer-,
Ressourcen- und Service-Provisioning-Informationen zwischen
kooperierenden Organisationen.
Service Provisioning beschreibt generell die Vorbereitung von
bestimmten (IT-) Aktivitten.
Software Deployment Manager

Client (SDM )
Der Software Deployment Manager (SDM) ist ein Werkzeug, mit

dem Softwarepakete, die SAP verteilt, verwaltet und deployed
werden knnen. SDM hat nur einen Benutzer mit einem Passwort.
TABELLE 2: AS JAVA PROGRAMME UND TOOLS
PROGRAMM
BESCHREIBUNG
PORT
SAP NetWeaver
Administrator (NWA)
Nachfolger des Visual Adminstrator Tools

und webbasiertes Werkzeug fr die Administration, Konfiguration und Monitoring der J2EEInstanzen. Nutzt die User Management Engine
(UME). SAP bietet standardmig die folgenden
vordefinierten Rollen innerhalb der UME:
Release 7.0
SAP_JAVA_NWADMIN_LOCAL
SAP_JAVA_NWADMIN_LOCAL_READONLY
SAP_JAVA_NWADMIN_CENTRAL
SAP_JAVA_NWADMIN_CENTRAL_READONLY
Release 7.1
NWA_READONLY
NWA_SUPERADMIN
5
Java_
instance_
number
00
Pfad: http://Host:port/irj/nwapi
PROGRAMM
BESCHREIBUNG
PORT
SAP Enterprise
Config Tool
Eigenstndiges Werkzeug zur Offline-Konfiguration und Administration von Cluster-Elementen

des Web AS Java.
Kann ohne Eingabe eines Passwortes durch

den Administrator gestartet werden und wird
insbesondere dann verwendet, wenn der Visual
Administrator nicht verfgbar ist. Mit dem Config
Tool knnen sowohl lokale als auch globale Konfigurationseinstellungen vorgenommen werden.
Im Gegensatz zum Visual Admin arbeitet das
Config Tool direkt auf der Datenbank.
Verzeichnis der J2EE-Installation
Ordner: SID\Instanzname/j2ee\configtool\
configtool. [sh|bat]
3
Visual Administrator
Der Visual Admin dient als GUI, mit dem alle Cluster-Elemente und alle Module des J2EE Engine
administriert werden knnen. Es kann allgemeine
Informationen ber Services, Manager, Schnittstellen und Libraries des Java-Systems abrufen
sowie Einstellungen und administrative Aufgaben
an den Services, Managern und Schnittstellen
vornehmen. Ebenfalls sind nderungen von globalen Einstellungen des Java Servers mglich.
5
J2EE
instance_
number
04
Pfad (local): \usr\sap\SAPSID\Instanzname/

j2ee\admin\go. [sh|bat]
4
SAP Management
Console (SAP MC)
berwachung, Start, Stopp und Restart

von SAP-Systemen und Instanzen. Anzeige
der SAP-Protokoll- und Trace-Dateien, der
Start-Profile, Instanzparameter, der Systemund SAP-Umgebung und der Statistik des
Internet Communication Manager (ICM).
5
J2EE
instance_
number
13

Pfad: http://Application-server-of-the-SAP-instance:port
5
Shell Administrator
(Telnet)
Fr den Fall, dass der Visual Admin nicht zur

Verfgung steht, ist es mglich, ber Telnet zu
administrieren. Dies ist aus Sicherheitsgrnden
nicht empfohlen.
SDM Client
Tool zum Verwalten des SDM Dienstes.
50008
75
76
6.5. PRFPROGRAMM: SICHERE KONFIGURATION DES

SAP JAVA-STACK
NR.
SICHERE KONFIGURATION DES SAP JAVA-STACK
1.
Kontrollziel: Sichere Konfiguration des SAP Java-Stack

Risiko: Sicherheitsrisiken im Betrieb eines SAP Java-Stacks sind nicht beurteilt und
abgestellt.
Hinweis: Der SAP Java-Stack bleibt in dem ungesicherten Zustand nach erfolgter Standardinstallation.
1.1.
Werden berhaupt Java-basierte Produkte oder Anwendungen eingesetzt?

Hinweis: Falls dies nicht zutrifft, knnen alle Dienste des Java-Stack deaktiviert werden.
1.2.
Sind nicht bentigte Dienste abgeschaltet? Ist der folgende SAP-Hinweis bekannt und
umgesetzt worden?
SAP-Hinweis: 871 394, Dispensable functions with impact on security.
1.3.
Ist der http-Dienst gesichert?

Ist die Verzeichnisanzeige unterbunden?
Sind nicht bentigte Alias deaktiviert?
Ist das Hochladen von Daten ausgeschlossen (http PUT)?
SAP-Hinweis: 604 285, Security vulnerability by unprotected http PUT method.
SOS: HTTP Based Browsing IEX (0780)
SOS: Restriction of HTTP PUT Method IEX (0779)
1.4.
Ist die kryptografische Funktionsbibliothek konfiguriert?

Hinweis 1: Die Datei IAIK_JCE.JAR muss manuell in das Verzeichnis SAPj2eeEngine_
install_dir / admin / lib kopiert oder nachtrglich durch Deployment der SAP
Java Cryptographic Toolkit SDA konfiguriert werden.
Hinweis 2: Per default wird die SAP J2EE Engine nur mit der Exportversion des Sicherheitswerkzeugkastens ausgeliefert. Diese enthlt nur die Funktionen fr die digitale Verschlsselung, nicht aber die Verschlsselungsfunktion, um HTTPS zu untersttzen.
SOS: Installation of the SAPcryptolib IEX (0871)
1.5.
Sind die Betriebssystemdateien mit den streng vertraulichen Anmeldeinformationen

stark verschlsselt?
Hinweis 1: Die J2EE Engine speichert standardmig sichere Daten in der Datei \usr\
sap\SID\SYS\global\security\data\SecStore.properties im Dateisystem. Diese Datei
wird whrend der Installation erstellt und die J2EE Engine benutzt sie, um vertrauliche Verbindungsdaten zu speichern. Diese Verbindungsdaten vom Datenbankbenutzer
SAPSIDDB enthalten z.B. sein Passwort, die Datenbankbasis sowie Informationen
ber den Benutzeradministrator und dessen Passwort. Die Verschlsselung fr SecureStorage-Daten kann mit dem Paramter $internal/mode = z.B. encrypted in der SecStore.
properties geprft werden.
Hinweis 2: Zur Verschlsselung der Passwrter des Datenbankbenutzers SAPSIDDB
und des Administrator-Benutzers sollte die SAP Java Cryptographic Library aktiviert
sein. Wenn die SAP Java Cryptographic Library genutzt wird, werden die Passwrter mit
dem Triple-DES-Verfahren verschlsselt, anstatt mit dem base64-Verfahren codiert.
Hinweis 3: Der Schlssel fr die Datei \usr\sap\SID\SYS\global\security\data\SecStore.
properties befindet sich in \usr\sap\SID\SYS\global\security\data\SecStore.key. Der
Lese- und Schreibzugriff auf beide Dateien sollte stark eingeschrnkt werden.
Hinweis 4: Die Installation der SAP Note 1619539 wird empfohlen.
SOS: Strong Encryption for the Secured Storage in the File System IEX (0882)
NR.
1.6.
Welche Benutzer sind in der Standardbenutzergruppe Administrators?

Hinweis: Benutzer der Gruppe Administrators haben uneingeschrnkte AdministratorPrivilegien auf den Java-Anwendungsserver. Sie haben die Berechtigung, alle anderen
Benutzer zu verwalten, einschlielich anderer Benutzer mit Administrator-Privilegien.
Sie knnen alle Sicherheitseinstellungen verndern. Es gibt auerhalb dieser Gruppe
keine anderen Benutzer, die fr die Benutzer- und Sicherheitsadministration zustndig
sind.
Nur Systemadministratoren drfen in der Standardbenutzergruppe Administrators
sein.
SOS: Users of Standard User Group Administrators IEX (0893)
1.7.
An welche Benutzer ist die Sicherheitsrolle telnet_login vergeben?

Hinweis 1: Sie darf nur an die Administratoren der J2EE Engine vergeben sein.
SOS: J2EE Server Remote Administration with Telnet IEX (0775)
Hinweis 2: Der netzwerkseitige Zugriff auf den Telnet-Dienst kann ber den
Parameter BIND im Configtool auf localhost oder 127.0.0.1 eingeschrnkt
werden. Anmeldungen aus dem Netzwerk werden hierdurch unterbunden.
1.8.
Werden sicherheitsrelevante Java Notes regelmig eingespielt?

Hinweis 1: SAP Notes bzw. Java Notes, die eine hohe Risikoklassifizierung (priority 1
und 2) besitzen, sollten monatlich eingespielt werden. SAP verffentlicht jeden zweiten
Dienstag im Monat neue sicherheitsrelevante Updates (SAP Security Notes).
2.
Kontrollziel: Sichere Einstellung von Security Logs von UME und ICM
Risiko: Die Security Logs vom UME und ICM bieten bei einer unzureichenden
Konfiguration keine ausreichenden Nachweise bei unautorisierten nderungen
oder Zugriffen. Logdateien knnen durch eine nicht revisionssichere Speicherung
unauthorisiert gelscht oder manipuliert werden.
Hinweis: Da die Protokolldateien wichtige Systeminformationen und persnliche Daten
enthalten knnen, muss der Zugriff auf diese Protokolldateien eingeschrnkt werden.
Nur berechtige Benutzer sollten daher Zugriff auf die Dateien erhalten. Eine Auslagerung der Protokolldateien auf einen dedizierten Log-Host kann die Sicherheit erhhen.
Im ICM Security Log werden Incidents aus der Netzwerkkommunikation aufgezeichnet.
Sofern der Zugriffsschutz im UME vom Java-Stack eingerichtet ist, werden sicherheitsrelevante Ereignisse im UME-Security Log aufgezeichnet. Der Zugriff durch die Administratoren sollte daher restriktiv vergeben werden.
2.1.
Werden die eingehenden Verbindungen geloggt?

Hinweis: Parameter ist zu finden unter icm/HTTP/logging_xx.
Bei Anwendungen mit entsprechenden Schutzbedarf zu aktivieren. Hier ist zu beachten,
dass vertrauliche und personenbezogene Daten aufgezeichnet werden knnen und evtl.
datenschutzrechtliche Aspekte beachtet werden mssen.
2.2.
Werden die ausgehenden Verbindungen geloggt?

Hinweis: Parameter ist zu finden unter icm/HTTP/logging_client_xx.
In Absprache mit den Applikationsverantwortlichen sollte geklrt werden, ob eine
berwachung der ausgehenden Daten erforderlich ist. Unter Umstnden kann hier
eine Data-Leakage-Funktionalitt eingebunden werden.
77
78
NR.
2.4.
Sind die Sicherheitslogs von ICM und SAP Web Dispatcher konfiguriert?
Hinweis 1: Parameter icm/security_log kontrolliert die Ausgabe von ICM und SAMP
Web Dispatcher und hat folgenden Einstellungen:
LOGFILE=dev_icm_sec,LEVEL=2, MAXSIZEKB=500
Hinweis 2: Der Trace-Level sollte auf produktiven Systemen nicht den Wert 3 besitzen
und Traces, die fr administrative Zwecke angelegt wurden, mssen nach der Ttigkeit
vom produktiven System entfernt werden.
2.5.
Ist das Sicherheitslog von UME gesichert?

Hinweis: Speicherort im Log Viewer: ./log/system/security.log
Speicherort im Dateisystem: /usr/sap/SID/instance_number/j2ee/cluster/serverX/
log/system/security.log
Diese Datei enthlt alle nderungen an Benutzerstammdaten, Anmeldungen sowie
weitere UME-Meldungen.
Die Berechtigung auf die Dateien ist einzuschrnken. Die Protokolle sollten zyklisch
auf einem zentralen Log-Host abgelegt werden.
6.6. PRFPROGRAMM: SICHERHEIT DES ICM

NR.
PRFPROGRAMM: SICHERHEIT DES ICM
1.
Kontrollziel: Absicherung des ICM

Risiko: Ungesicherte (Web-)Schnittstellen im WebAS- und J2EE-Umfeld knnen
die Vertraulichkeit und Sicherheit von Daten gefhrden.
Hinweis: ICM Web-Anfragen werden vom ICF-Modul (Internet Communication
Framework) verarbeitet. Hierzu werden in einem zentralen Repository alle registrierten
Dienste gespeichert, wodurch der ICF entscheiden kann, an welchen dahinterliegenden
Service er den Web-Request leitet. Anfragen fr den Java-Stack durchlaufen ebenfalls
den ICM. Daher mssen Schnittstellen im ICM angemessen abgesichert und eine
Verschlsselung zum Benutzer und gegebenenfalls zu internen Schnittstellen
eingerichtet werden.
ClienT
(Web Browser)
Message
Server
GUI
Internet
SAP Web AS
for Java
Internet
Communication
Manager
SAP Web AS
for ABAP
Dispatcher
DB
Task Handler
J2EE
Engine
Java
Methods
SAP Java
Connector
(JCo)
RFC
ABAP
Work
Processes
Abbildung 2: Integration des ICM zwischen ABAP- und Java-Stack
Ausnahmen sollten dokumentiert und nur in Abstimmung mit dem Sicherheitsmanagement eingerichtet werden.
1.1.
Werden interne Versionsangaben im Header angezeigt?

Risiko: Angaben ber interne Komponenten liefern Angreifern wertvolle Informationen,
die fr weiterfhrende Angriffsszenarien genutzt werden knnen.
Hinweis: http.properties:UseServerHeader definiert, ob Versionsinformationen in
einem HTTP-Header angezeigt werden. Der Vorschlagswert ist false.
79
80
NR.
1.2.
Ist die maximale Gre von Web-Anfragen eines Benutzers definiert?

Hinweis: Eingehende Anfragen sollten ber den Parameter icm/PROT/max_request_
size_KB auf maximal 2048 KB (2MB) eingeschrnkt werden. Mit diesem
Parameter kann der Applikationsserver vor einer Denial of Service Attacke (DOS)
mit groen Anfragepaketen geschtzt werden.
1.3.
Ist die Administrationsoberflche mithilfe von Verschlsselung geschtzt?

Hinweis: Die Administrationsoberflche ist mit folgenden Parametern zu konfigurieren:
icm/HTTP/admin_xx
Mit xx als
port=https, HOST=interne Admin Rechner
Dabei ist nur auf HTTPS Ports zu setzen icm/server_port_2 yy
Mit yy als
PROT=HTTPS, PORT=443, TIMEOUT=15, PROCTIMEOUT=45, VCLIENT=2
1.4.
Werden HTTP(S) Request gefiltert?

Hinweis: Parameter icm/HTTP/auth_xx sollte geprft werden.
Mit diesem Parameter kann der HTTP-Request anhand von verschiedenen Kriterien abgeblockt werden. Wenn aktiviert, wird dieser Filter bei jedem HTTP(S) Request zum ICM
oder Web Dispatcher durchlaufen, bevor der Request zu einem anderen HTTP-Handler
(Dateizugriff, Cache Administration, Redirect) oder zum Backend-System (ABAP oder
J2EE Engine) weitergeleitet wird. Bei der Benutzung von PERMFILE sollten Whitelists
zum Einsatz kommen. Die Whitelist ist pro Anwendung zu definieren.
1.5.
Ist das Verhalten von ICM im Fehlerfall eingestellt?

Hinweis: Parameter icm/HTTP/error_templ_path soll gesetzt werden.
Der Parameter dient zur Einstellung des ICM im Fehlerfall.
1.6.
Sind die Dateizugriffe auf statische Webinhalte eingeschrnkt?

Hinweis: Parameter icm/HTTP/file_access_xx sollte gesetzt werden.
Dieser Parameter bestimmt, fr welches URL-Prfix statische Dateizugriffe erlaubt
sind und in welchem Verzeichnis die statischen Dateien gespeichert sind.
BROWSEDIR=0 (aus)
DOCROOT darf keine schtzenswerten Inhalte enthalten! Vor jeder Inbetriebnahme
sollte dieses Verzeichnis auf gltige Dateien geprft werden!
1.7.
Ist die Kommunikation des ICM mit der J2EE Engine festgelegt und ist eine
Verschlsselung eingerichtet?
Hinweis: Parameter icm/HTTP/j2ee_xx sollte geprft werden.
Mit diesem Parameter wird die Kommunikation des ICM mit der J2EE Engine
festgelegt.
Syntax: icm/HTTP/j2ee_xx = PREFIX=uri-prefix, [HOST=host,] PORT=port,
CONN=Anzahl Verbindungen [, SSLENC=n>, TYPE=t, CRED=file, SPORT=
HTTPS-port
icm/HTTP/j2ee_0 = PREFIX=/, CONN=0-10, PORT=50000,SPORT=50003, SSLENC=1,
TYPE=2,CRED=Credential.pse
1.8.
Werden Benutzer explizit verifiziert?

Hinweis: Parameter icm/HTTPS/verify_client sollte geprft werden.
Dieser Parameter spezifiziert, ob der Client ein Zertifikat vorweisen muss oder nicht.
Es gibt insgesamt drei Stufen der Verifikation (0-2):
2, wenn Zertifikat erforderlich sein soll;
mindestens 1, wenn keine Client Authentication verwendet werden soll.
NR.
1.9.
Sind der Service/Port und der Keepalive-Timeout spezifiziert?

Hinweis: Service/Port und der Keepalive-Timeout werden mit folgenden Parameter
konfiguriert:
Parameter icm/server_port_xx soll gesetzt werden.
Mit xx=PROT=HTTPS, PORT=HTTPS_Port, TIMEOUT=900, wobei HOST=internes
Interface
1.10.
Ist HTTPS fr den Zugriff auf den Web Dispatcher im Standard eingerichtet?
Hinweis: Der Parameter icm/ssl_config_xx ist nur relevant fr HTTPS-Konfigurationen von ICM bzw. Web Dispatcher (Kommunikation ber HTTPS). Insbesondere beim
Web Dispatcher spielt HTTPS eine groe Rolle, da dieser in der DMZ steht und als
Einstiegspunkt fr Anfragen aus dem Internet dient.
1.11.
Ist die Standardfehlermeldung konfiguriert?

Hinweis: Der Parameter is/HTTP/show_detailed_errors bestimmt die Form der HTTP-Fehlermeldungen, die der Server im Standard erzeugt und an den Client schickt.
is/HTTP/show_detailed_errors sollte auf FALSE gesetzt werden.
1.12.
Ist der Server-Headerfeld Verhalten bei HTTP-Nachrichten konfiguriert?

Hinweis: Der Parameter is/HTTP/show_server_header bestimmt, ob das Server-Headerfeld bei HTTP-Nachrichten eingefgt werden soll oder nicht.
is/HTTP/show_server_header soll auf FALSE gesetzt werden.
1.13.
Ist der Server-Port gesetzt?

Hinweis: Der Parameter ms/https_port ist obselet und sollte nicht mehr benutzt
werden. Benutzen Sie stattdessen den Parameter ms/server_port_xx mit xx als die
Portnummer.
1.14.
Ist die Kommunikation mit dem Message-Server gesichert?

Hinweis: Die Verbindungen zum Message-Server sollten durch HTTPS verschlsselt
werden. Folgende Parameter sollten daher eingestellt werden.
rdisp/mshost=message_server_host
ms/https_port=message_server_HTTPS_Port (wenn Verschlsselung erforderlich ist)
ms/http_port=message_server_HTTP_Port (wenn keine Verschlsselung erforderlich ist)
1.15.
Sind die ausgehenden Verbindungen gesichert?

Hinweis: Die ausgehenden Verbindungen sollen mittels HTTPS verschlsselt werden.
Folgende Parameter sollten eingestellt werden.
wdisp/ssl_encrypt=0,1,2
wdisp/ssl_auth=0,1,2
wdisp/ssl_cred=File_name_of_client_PSE
1.16.
Sind administrative Verbindungen gesichert?

Hinweis: HTTPS fr LDAP unter Global server configuration/configuration/cfg/services/
com.sap.security.core.ume.service.properties und fr P4 unter Global dispatcher configuration/configuration/cfg/services/p4.properties sollten auf TRUE gesetzt sein.
81
82
NR.
2.
Kontrollziel: Sichere Einstellung und Verwendung eines Webfilters

Risiko: Risiko- oder schwachstellenbehaftete Dienste knnen bei einen unautorisierten
Zugriff auf Anwendungen und Daten missbraucht werden. Die Integritt und Vertraulichkeit von Daten ist nicht gewhrleistet.
Hinweis: Um nicht autorisierte Zugriffe auf kritische Funktionalitten (z.B. SPML-Dienste) zu schtzen, sollten Webfilter aktiviert werden. Alternativ kann ein externer Webfilter
(z.B. Web Application Firewall) verwendet werden. Es sollten nur fr Benutzer freigegebene Webseiten freigeschaltet werden. Alle von SAP intern genutzt URLs sind auf dem
produktiven Interface zum Endbenutzer zu filtern. Der SAP Web Dispatcher und das
ICM-Modul knnen als URL-Filter konfiguriert werden. Dazu knnen mittels einer Whitelist nur bestimmte Dienste, die auf den SAP-Systemen angeboten werden, erreichbar
gemacht werden. Auerdem knnen Dienste, die aus dem Internet nicht erreichbar sein
sollen, mittels des Parameters D blockiert werden. Mit Hilfe eines externen Webfilters
(z.B. Web Application Firewall) kann diese Funktionalitt erweitert bzw. ersetzt werden.
2.1.
Sind die Pfade, welche Informationen ber die Infrastruktur und Konfiguration liefern,
gesetzt?
Hinweis 1: Verwenden Sie den Web Dispatcher als URL-Filter mit Whitelists. Folgende
URLs liefern Informationen ber die Infrastruktur und Konfiguration und sollen auf
Parameter wdisp\permission_table = ptabfile gesetzt werden:
D /sap/public/icman/*
D /sap/public/ping
D /sap/public/icf_info/*
Hinweis 2: Den Zugriff auf die interne Infoseite sollte durch folgenden Eintrag in der
URI-Permission-Tabelle gesperrt werden:
D /sap/wdisp/info
2.2.
Ist die Standardprofildatei bei SAP Netweaver 7.1 und hher (siehe Security Note
1616058) konfiguriert?
Hinweis: Der Modification-Handler wird im Standardprofil DEFAULT.PFL festgelegt.
Folgende Parameter mssen gepflegt werden:
icm/HTTP/mod_0 = PREFIX=/,FILE=$(DIR_GLOBAL)/security/data/icm_filter_rules.txt
Filterregeln knnen entsprechend eingesehen und ausgewertet werden.
3.
Kontrollziel: Filterung unsicherer Webservices

Risiko: Risiko- oder schwachstellenbehaftete Dienste knnen bei einen unautorisierten
Zugriff auf Anwendungen und Daten missbraucht werden. Die Integritt und
Vertraulichkeit von Daten ist nicht gewhrleistet.
Hinweis: Unsichere Protokolle bieten keinen ausreichenden Schutz fr die
Vertraulichkeit und Integritt von Daten.
NR.
3.1.
Werden unverschlsselte Dienste fr den Zugriff aus potenziell unsicheren Netzwerken

durch eine Firewall oder Webproxy gesperrt?
Hinweis: Folgende Dienste werden im Betrieb des Java-Stack eingerichtet.
Dienst
HTTP
HTTPS
IIOP Initial context
IIOP over SSL
P4
P4 over HTTP tunneling
P4 over SSL
Internet Inter-Orb Protocol IIOP
Telnet
Java Message Service (JMS)
Server Join Port
Server Debug Port
Port Nummer
5NN00
5NN01
5NN02
5NN03
5NN04
5NN05
5NN06
5NN07
5NN08
5NN10
5NN20 + x 5
5NN21 + x 5
Standard
50000
50001
50002
50003
50004
50005
50006
50007
50008
50010
50020
50021
Range
5000059900
5000159901
5000259902
5000359903
5000459904
5000559905
5000659906
5000759907
5000859908
5001059910
5002059995
50021-59996
Dienste mit SSL oder HTTPS knnen eine Verschlsselung sicherstellen.

3.2.
Sind unverschlsselte Dienste nur auf die Kommunikation im lokalen Netzwerksegment

eingeschrnkt?
6.7. PRFPROGRAMM: AUTHENTISIERUNG UND AUTORISIERUNG

(JAVA-STACK)
NR.
AUTHENTISIERUNG UND AUTORISIERUNG BEI NUTZUNG DES SAP JAVA-STACK
1.
Kontrollziel: Sichere Authentisierung und Autorisierung des SAP Java-Stacks

Risiko: Sicherheitsparameter sind nicht oder fehlerhaft konfiguriert. Die Passwortregeln und Anmeldekontrollen sind nicht, widersprchlich oder unzureichend gesetzt,
dadurch ist eine wirksame Kontrolle von Zugriffen auf Funktionen und Dateien nicht
mglich. Die protokollierten Sicherheitsereignisse aus der Anmeldung oder aus der
Benutzer- und Berechtigungsverwaltung werden nicht regelmig berwacht.
1.1.
Gibt es ein Benutzer- und Berechtigungskonzept speziell fr den SAP Java-Stack?
1.2.
Wie ist der Benutzerpersistenzspeicher konfiguriert?

Hinweis: Es gibt zwei technische Mglichkeiten, um Benutzer und ihre Zugriffsrechte zu
verwalten, entweder ber die Nutzung des J2EE Java Authentication und Authorization
Service (JAAS) oder ber die darauf aufbauende SAP-spezifische User Management
Engine (UME). Die UME lsst wiederum drei Optionen zu, wie die Stamm- und
Anmeldedaten gespeichert werden:
in der eigenen J2EE-Datenbank
in Anbindung an ein LDAP-Verzeichnis
im SAP WEB-Anwendungsserver SAP (ABAP-Stack).
83
84
NR.
1.3.
Wie sind die Authentisierungsmodule konfiguriert?

Hinweis: Es gibt drei technische Mglichkeiten, um die Anmeldung beim Zugriff auf den
Java-Stack zu regeln (Authentisierungsverfahren):
Benutzernamen und Passwort-Verfahren
Zertifikate
Single-Sign-On-Tickets.
Weitere Verfahren knnen aktiviert werden, indem z.B. Bibliotheken von Drittherstellern installiert werden, die dem Java-Standard der JAAS-Schnittstelle gengen.
1.4.
Werden sowohl der J2EE Java Authentication und Authorization Service (JAAS) als
auch die SAP-spezifische User Management Engine (UME) zur Administration von
Benutzern und Berechtigungen eingesetzt?
Risiko: Benutzer- und Berechtigungsadministration erfolgt ber zwei unterschiedliche
Anwendungen, auch wenn UME softwaretechnisch auf JAAS aufgesetzt ist. Nicht
autorisierte oder konkurrierende Einrichtung von Benutzern und deren Berechtigungen
werden dadurch begnstigt.
1.5.
Ist das Java-Stack Single-Sign-On sicher konfiguriert?

Sind der HTTPS Service Provider und das HTTPS Server Zertifikat angegeben?
Ist der startup Modus auf Always gesetzt, sodass der HTTPS-Dienstleister aktiviert ist?
SOS: Start of the SSL Service Provider IEX (0872)
Ist fr CN=localhost das default Server Certificate ersetzt?
SOS: Default SSL Server Certificate IEX (0873)
Hinweis 1: Wird Single-Sign-On ber die Header-Variablen realisiert, muss ber
wirksam konfigurierte Netzwerkfilter oder eine HTTPS-Verbindung zwischen
Authentifizierungs-Server und dem SAP-Portal sichergestellt werden, dass der
Authentifizierungsserver nicht umgangen und eine direkte Verbindung zwischen
Web Clients und SAP Enterprise Portal hergestellt werden kann.
Hinweis 2: Wird die J2EE Engine mit Windows-Authentifizierung genutzt, muss auf
das SPNegoLoginModule umgeschaltet werden.
1.6.
Ist eine verschlsselte bertragung zwischen der UME im Java-Stack und dem
ABAP-System eingerichtet?
Hinweis: Diese Kontrolle betrifft nur die Java-Installationen, die ihre Benutzerverwaltung weitestgehend im ABAP-Stack betreiben. In diesen Fllen kann eine
sichere bertragung von Passwrtern nur mittels SNC erfolgen. Hierbei mssen
folgende Parameter gesetzt werden:
ume.r3.connection.adapterID.snc_mode = 1
ume.r3.connection.adapterID.snc_qop = 3
2.
Kontrollziel: Sicherheit der Standardbenutzer im Java-Stack

Risiko: Sicherheitsparameter sind nicht oder fehlerhaft konfiguriert. Die Passwortregeln und Anmeldekontrollen sind nicht, widersprchlich oder unzureichend gesetzt,
um eine wirksame Kontrolle auf die Zugriffe auszuben. Die protokollierten Sicherheitsereignisse aus der Anmeldung oder aus der Benutzer- und Berechtigungsverwaltung werden nicht regelmig berwacht.
NR.
2.1.
Sind die Standardbenutzer durch sichere Passwrter geschtzt?

Hinweis: Folgende Tabelle stellt alle relevanten Standardbenutzer dar.
Tabelle 3: Standardbenutzer im Java-Stack
Benutzer
SID_ADMIN (Unix)
SAPServiceSID
(Windows)
SIDADM
superdba
SAPSIDDB
Administrator
SDM Administrator
SAPJSF
J2EE_ADMIN
SLDDSUSER
Beschreibung
Betriebssystembenutzer SAP
OS-Benutzer SAP
Local J2EE database user
DB-Benutzer J2EE (intern)
Administrator UME/LDAP
Administrator fr den Zugriff
auf das SDM
Technischer Benutzer
Schnittstellenbenutzer
J2EE - ABAP
Standardkommunikationsuser
fr den Zugriff auf das SLD
Zustndigkeit
Betriebssystem Betrieb
Betriebssystem Betrieb
DBA
DBA
SAP Basis
SAP Basis
SAP Basis
SAP Basis
SAP Basis
SAP Basis
Die Passwrter werden whrend der Installation des SAP-Systems eingerichtet.

Diese sollten den unternehmensweit gltigen Anforderungen an ein sicheres
Administratorenpasswort gengen.
2.2.
Sind Regelungen zum Umgang mit den Passwrtern im Berechtigungskonzept hinterlegt? Sind angemessene Kontrollen, z.B. 4-Augen-Prinzip, bercksichtigt worden?
User Management Engine (UME) Anmeldekontrollen
3.
Kontrollziel: Die Bildung der Benutzerkennung und des Kennworts unterliegt

Komplexittsregeln.
Risiko:
Systemtechnische Benutzerkennungen oder die der Administratoren sind aufgrund
der Funktion, fr die sie eingerichtet werden, leicht zu erraten, sodass Kennwortattacken gezielt auf die erratenen Benutzerkennungen vorgenommen werden knnen.
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.
3.1.
Sind Passwortregeln fr Benutzerkennungen der UME-Benutzer im Java-Stack

konfiguriert?
Hinweis: In Tabelle 2 sind die fr die UME-Benutzer relevanten Passwortrichtlinien
zusammengefasst. Bewerten Sie die aktuellen Einstellungen anhand der Vorschlagswerte bzw. der unternehmensweiten Richtlinien.
3.2.
Sind Passwortregeln fr Benutzerkennungen der ABAP-Benutzer im AS ABAP

konfiguriert?
Hinweis: Benutzer in AS Java knnen im AS ABAP fhrend verwaltet werden. In diesen
Fllen stellt der AS ABAP die Richtlinien fr die Verwaltung der Passwrter fest.
85
86
NR.
AUTHENTISIERUNG UND AUTORISIERUNG BEI NUTZUNG DES SAP-JAVA-STACK
6.
Kontrollziel: Zugriff auf die J2EE-Tokens absichern

Risiko: J2EE-Token werden in der Web-Kommunikation meist in sogenannte Cookies
gespeichert. Es ist sicherzustellen, dass Cookies verschlsselt bertragen werden
und Sicherheitsmerkmale im Browser gesetzt sind (z.B. das secure Flag), um
unautorisierte Zugriffe durch Angreifer zu verhindern.
6.1.
Sind die Sessions IP-beschrnkt?

Hinweis: SessionIPProtectionEnabled sollte TRUE eingestellt sein
(unter Global server configuration/configuration/cfg/services/servlet_jsp.properties),
damit die IP-Beschrnkung von Session IDs eingestellt ist.
6.2.
Sind die J2EE-Token geschtzt?

Hinweis 1: SystemCookiesDataProtection sollte auf TRUE eingestellt sein,
damit die Tokens in den Cookies vor Cross-Site-Scripting geschtzt werden.
Hinweis 2: Der Parameter ume.logon.httponlycookie bewirkt, dass das httpOnly Flag
fr SAP Logon Tickets gesetzt wird. Dadurch kann das Cookie nicht mehr durch
JavaScript ausgelesen werden, wodurch Cross-Site-Scripting Angriffe erschwert
werden.
6.3.
Ist die bertragung von Session-Cookies gesichert?

Hinweis 1: SystemCookiesHTTPSProtection sollte TRUE eingestellt sein
(unter Global server configuration/configuration/cfg/services/http.properties),
damit die bertragung der Cookies verschlsselt ist.
Hinweis 2: Der Parameter ume.logon.security.enforce_secure_cookie bewirkt, dass
das secure Flag fr SAP Logon Tickets gesetzt wird. Dadurch wird dieses Cookie nur
noch ber verschlsselte Verbindungen versendet.
NR.

User Management Engine (UME) Benutzer- und Berechtigungsverwaltung
7.
Kontrollziel: Rollen- und aufgabenspefische Vergabe von Administrationsberechtigungen

Risiko: Derselben Administratorkennung sind unterschiedliche Rollen der Benutzer- und
Berechtigungsverwaltung zugewiesen. Der Grundsatz der Funktionstrennung ist nicht
eingehalten. Administrationsberechtigungen sind auch an nicht autorisierte Benutzer
vergeben, wodurch die Anforderungen gem IKS unterlaufen werden.
Hinweis: Die Vergabe von Rollen und Berechtigungen sollte die IKS-Anforderungen sowie
die jeweils gltigen regulatorischen Anforderungen des untersuchten Systems erfllen.
Super
Administrators
User
Groups
Manage_All
Read_All
UME
Roles
Business Users
Company-Specific
Profile-Specific
Manage_All_Companies
Manage_All_User_
Passwords
Manage_Users
Manage_User_Passwords
Manage_My_Profile
Read_My_Profile
Manage_My_Password
Manage_Groups
Manage_Roles
Specific
Functions
PortalSpecific
Administrators
All
Import and Export

Batch_Admin
Manage_All
AclSuperUser
Self-Registration
Selfregister_User
Manage_Role_
Assignments
UME Actions According to Principal and Role

Abbildung 3: Standard-UME-Rollen
Der Umgang mit privilegierten Benutzern, insbesondere dem Notfallbenutzer, muss im

SAP-Berechtigungskonzept geregelt werden.
7.1.
Welche Benutzer sind der Rolle Administrators zugeordnet (Benutzergruppe im

UME-Benutzerspeicher)?
Hinweis: Der UME Web Admin und der Visual Admin, haben die Administrators- Rolle
zugeordnet. Sie knnen alle Benutzerdaten uneingeschrnkt pflegen.
Nur Benutzer- und Berechtigungsadministratoren drfen in der UME-Benutzergruppe
Administrators sein. Sofern mglich, sollten diese Benutzer nur im Rahmen des
Notfallbenutzerkonzepts verwendet werden.
SOS: Users of UME User Group Administrators IEX (0793)
87
88
NR.
7.2.
Welche der folgenden Administrationsberechtigungen sind an welche

Benutzer vergeben?
Hinweis:
1 UME.Manage_User_Passwords
2 UME.Manage_All
3 UME.Manage_Users
4 UME.Manage_All_Companies
5 UME.Manage_Groups
6 UME.Manage_Roles
7 UME.Batch_Admin.
Diese Administrationsberechtigungen sind restriktiv nur an die zustndigen
Sachbearbeiter zu vergeben. Im Rahmen des IKS sollten angemessene
Funktionstrennungen beachtet werden.
7.3.
Wird das Protokoll ber Sicherheitsereignisse (Security Logging) regelmig

berwacht?
Hinweis: Protokolldatei ber den Log Viewer: ./log/system/security.log
Protokolldatei im Dateisystem: /usr /sap /SID /instance_number /j2ee /cluster /
serverX /log /system /security.log
Diese Protokolldatei enthlt die Aufzeichnung relevanter Sicherheitsereignisse wie
erfolglose Anmeldungen oder das Anlegen oder ndern von Benutzern, Gruppen oder
Rollen.
Im Einzelnen:
user.create und useraccount.create
Benutzer neu angelegt
role.create Anlegen von Rollen
role.modify ndern von Rollen
islocked Benutzer gesperrt/entsperrt
login.error Fehlgeschlagene Anmeldeversuche (IP-Adresse wird mit geloggt.)
7.4.
Sind die Berechtigungen des Kommunikationsbenutzers zwischen der

UME und den angebundenen SAP-Systemen angemessen vergeben?
Hinweis:
Standardmig wird der Benutzer SAPJSF verwendet. SAP liefert die Rollen
SAP_BC_JSF_COMMUNICATION (Schreibrechte auf Benutzerkonten) und
SAP_BC_JSF_COMMUNICATION_RO (Lesezugriff auf Benutzerkonten) aus.
Der Kommunikationsbenutzer muss vom Typ System und darf nicht vom Typ Service
oder Dialog sein, da keine Online-Anmeldung erlaubt ist.
NR.
7.5.
Wird der Java-Benutzer SAP* als Notfallbenutzer eingesetzt?

Hinweis: Der Benutzer SAP* in Java-Systemen ist nicht zu verwechseln mit dem in
klassischen SAP-Systemen. Er verfgt ber volle Administrationsberechtigungen und
wird in der UME als Notfallbenutzer eingesetzt. Er verfgt ber kein Standard-Kennwort. Dieses wird ber eine UME-Eigenschaft gesetzt.
Durch Aktivierung des Benutzers SAP* als Notfallbenutzer werden nach dem Neustart
des Java-Anwendungsservers alle anderen Benutzer deaktiviert.
aktiviert bzw. deaktiviert den Benutzer als Notfallbenutzer
ume.superadmin.activated
TRUE/FALSE)
ume.superadmin.password
enthlt das Kennwort des Notfallbenutzers
Diese Einstellung darf nur in einem tatschlichen Notfall gesetzt werden.

7.6.
An welche Benutzer ist die Sicherheitsrolle telnet_login vergeben?

Hinweis: Sie darf nur an die Administratoren der J2EE Engine vergeben sein.
SOS: J2EE Server Remote Administration with Telnet IEX (0775)
89
90
6.8. TABELLE: VORSCHLAGSWERTE FR DIE SYSTEMPARAMETER

DER UME-ANMELDEKONTROLLE
VORSCHLAGSWERT
PARAMETER
BESCHREIBUNG
ume.logon.security_policy.
auto_unlock_time
Zeitspanne in Minuten, die das System

gesperrt wird, fr den Fall mehrfacher
fehlerhafter Loginversuche.
enforce_policy_at_logon
Das Passwort wird whrend des Anmeldens

gegen die Sicherheitsrichtlinie berprft.
Sollte es nicht mehr ausreichend sein, wird
der Benutzer aufgefordert, ein neues Passwort
zu setzen.
lock_after_invalid_
attempts
Anzahl fehlerhafter Loginversuche, bevor der

Nutzer gesperrt wird.
oldpass_in_newpass_allowed
Definiert, ob das neue Passwort Teile des alten

Passworts enthalten darf. Dafr berprft UME
die Passwrter whrend des nderns.
FALSE
password_alpha_numeric_required
Minimale Anzahl an Buchstaben und Zahlen in

einem Passwort.
password_change_allowed
Definiert, ob Benutzer-Passwrter gendert

werden knnen.
password_expire_days
Zeitspanne in Tagen, die ein Passwort gltig ist.
35
password_history
Die UME kann die Hash-Werte alter Passwrter speichern. Dieses verhindert, das Benutzer
alte Passwrter wiederverwenden.
10
TRUE
Ist diese Zahl z.B. auf 3 gesetzt, muss das

Passwort mindestens drei Buchstaben und drei
Zahlen enthalten.
TRUE
Der Wert legt fest, wie viele alte Passwrter

gespeichert werden.
password_impermissible
Eine durch Kommata getrennte Liste, welche

Ausdrcke und Zeichen enthalten, welche nicht
Teil eines Passworts sein drfen.
password_last_change_
date_default
Wenn ein Benutzer niemals sein Passwort

mithilfe der AS Java verndert hat, zhlt dieses
Datum als Datum der letzten nderung.
Das Format ist MM/DD/YYYY
Siehe auch: ume.logon.security_policy.
password_expire_days
Gem den
Eintrgen aus
der USR40
anzupassen.
VORSCHLAGSWERT
PARAMETER
BESCHREIBUNG
password_max_idle_time
Zeitspanne in Tagen nach dem letzten

erfolgreichen Login mit Benutzer-ID und
Passwort, bevor UME das Passwort sperrt.
password_max_length
Maximale Passwortlnge
password_min_length
Minimale Passwortlnge
password_mix_case_required
Minimale Anzahl an Gro- und Kleinbuchstaben in einem Passwort.

Ist diese Zahl auf 3 gesetzt, muss das
Passwort mindestens drei groe und drei
kleine Buchstaben enthalten.
password_special_char_
required
Minimale Anzahl an Sonderzeichen in einem

Passwort.
ume.r3.connection.adapterID.snc_mode
Wenn die UME mit dem ABAP-System

kommuniziert, sollte SNC zur Verschlsselung
der Zugangsdaten aktiviert werden.
ume.r3.connection.adapterID.snc_qop
Wenn die UME mit dem ABAP-System

kommuniziert, sollte SNC zur Verschlsselung
der Zugangsdaten aktiviert werden.
ume.superadmin.activated
Aktivierung bzw. Deaktivierung des UME Notfallusers SAP*.
FALSE
ume.superadmin.password
Festlegung des Kennworts fr den Notfalluser

SAP*
Im 4-AugenPrinzip bzw. nur

im Rahmen des
Notfalluserkonzepts
anzuwenden.
userid_digits
Minimale Anzahl an Zahlen in einer BenutzerLogin-ID

Value 0: Zahlen sind nicht erlaubt.
Value = 0: Zahlen sind erlaubt.
Value 0: Zahlen sind erforderlich.
userid_in_password_
allowed
Definiert, ob das Passwort Teile der Benutzer,

ID enthalten darf.
FALSE
35
91
92
PARAMETER
BESCHREIBUNG
userid_special_char_required
Minimale Anzahl an Sonderzeichen in einer

Benutzer-Login-ID
Value 0: Sonderzeichen sind verboten.
Value = 0: Sonderzeichen sind erlaubt.
Value 0: Sonderzeichen sind erforderlich
useridmaxlength
Maximale Lnge der Benutzer-ID:

Dieser Wert wird automatisch auf 12 gesetzt,
wenn die Kombination AS Java und AS fr
ABAP installiert ist.
VORSCHLAGSWERT
0
Default
Wenn eine Datenbank als Quelle fr Benutzerdaten verwendet wird, muss dieser Wert
kleiner bzw. gleich 200 sein.
useridminlength
Minimale Lnge der Benutzer-ID.
login/ min_password_lng
Minimale Passwortlnge
login/ password_charset
Das Passwort muss mindestens einen

Buchstaben, eine Zahl und ein Sonderzeichen
enthalten.
login/ min_password_
letters,
Anzahl von Buchstaben in einem Passwort
login / min_password_
digits und login
Anzahl von Zahlen in einem Passwort
min_password_specials,
login
Anzahl von Sonderzeichen in einem Passwort
min_password_lowercase
und login
Anzahl Kleinbuchstaben in einem Passwort
min_password_uppercase
Anzahl Grobuchstaben in einem Passwort
login/ min_password_diff
In wie vielen Zeichen muss sich ein neues von

einem alten Passwort unterscheiden
login/ password_history_
size
Die Hash-Werte alter Passwrter knnen

gespeichert werden. Dieses verhindert, dass
Benutzer alte Passwrter wiederverwendet.
15
Der Wert legt fest, wie viele alte Passwrter

gespeichert werden.
Tabelle USR40
Liste mit unzulssigen Passwrtern
PARAMETER
BESCHREIBUNG
login/ password_max_
idle_initial.
Zeitspanne in Tagen, nach denen das Initialpasswort gendert werden muss.
VORSCHLAGSWERT
3
Hinweis: Dieser Systemparameter ersetzt die

Profilparameter login/ password_max_new_valid 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)
login/ password_ expiration_ time
Zeitspanne in Tagen, nach dem ein Passwort

gendert werden muss.
90
login/ password_max_
idle_ productive
Gltigkeitszeitspanne in Tagen, nach denen ein

nicht benutztes Passwort gesperrt wird. Dieser
Parameter bezieht sich nicht auf die Benutzer
vom Typ Service oder System.
login/ password_change_waittime.
Der Benutzer muss sein Kennwort jederzeit

ndern knnen.
Standard:
einmal am Tag
login/ fails_to_session_
end
Anzahl Login-Fehlversuche bis zum Abbruch

des Vorgangs.
login/ fails_to_user_lock
Anzahl Login-Fehlversuche bis zum Sperren

des Benutzers.
login/ failed_user_auto_
unlock
Automatische Freischaltung der durch LoginFehlversuche gesperrten Benutzer.
1( = Freischaltung ber
Nacht)
login/ disable_multi_
gui_login
Ist die gleichzeitige Anmeldung von

verschiedenen Systeme durch einen
Benuter mglich.
1 ( = mehrfache
Anmeldung ist
nicht mglich)
rdisp/gui_auto_logout
Zeitspanne in Sekunden bei keiner Benutzeraktion bis zum automatischen Abmelden des
Benutzers. Bei o erfolgt kein automatischer
Logout.
login/ password_compliance_ to_current_policy
Wenn ein bereits vergebenes Kennwort nicht

mehr den inzwischen genderten Kennwortbildungsregeln entspricht, erzwingt das System
eine nderung des Kennworts bei
der Anmeldung.
Gltigkeitsdauer eines
nicht benutzten
Kennworts
hher setzen als
die Dauer fr
den erzwungenen Wechsel
des Kennworts
(max. 90 Tage).
93
94
6.9. PRFPROGRAMM: SAP-JAVA-STACK-SOFTWAREVERTEILUNG

NR.
SICHERE ANWENDUNG DER SAPJAVA-STACK-SOFTWAREVERTEILUNG
1.
Kontrollziel: Sichere Konfiguration der SAP-Java-Stack-Softwareverteilung

Risiko: Entwickler importieren ohne Auftrag genderte Software selbst in das
Produktivsystem. Test- und Freigabeschritte sind nicht vorgegeben oder werden
umgangen. Nicht autorisierte nderungen an den Einstellungen des Change Management Service (CMS) und an den Transportdaten selbst sind mglich. Schwchen im
SDM-Service knnen ausgenutzt werden, um kritische Funktionsbausteine unter
Umgehung der systemseitigen Schutzmechanismen aufzurufen.
1.1.
Gibt es ein Konzept fr die SAP-Softwareverteilung, das auf die SAP-Java-StackUmgebung zugeschnitten ist?
1.2.
Sind die getrennten Zustndigkeiten in den Phasen der Entwicklung, des Testens
und der Abnahme geregelt?
1.3.
Wer darf Softwareverteilungen direkt aus einer Entwicklungsumgebung in ein

Produktivsystem vornehmen?
Risiko: Software kann aus der Entwicklungsumgebung unmittelbar in den
Java-Stack geladen werden.
1.4.
Wie ist der Software Deployment Manager SDM-Dienst (Software Deployment Manager)
Dienst konfiguriert?
Ist das Standardkennwort des SDM-Administrators bei der Installation gendert
worden?
Ist das neue Kennwort nach restriktiven Passwortregeln vergeben worden?
Wie vielen Benutzern ist das neue Kennwort zur Erfllung ihrer Aufgaben
mitgeteilt worden?
Wird der Dienst nur whrend des Deployments aktiviert?
Wird das Passwort in Start- und Stop-Skripten gespeichert?
Risiko: Die Rolle der SDM-Administration kann nicht vergeben werden. Nur der SDMAdministrator selbst kann verwendet werden. Ein Zurckverfolgen, wer diesen
Benutzer fr welche Aktivitt genutzt hat, ist erschwert, wenn nicht unmglich.
Nach einem Patch-Upgrade wird systemseitig keine nderung des Kennworts
des SDM-Administrators erzwungen.
1.5.
H
Ist die Netzwerkverbindung zwischen SDM-Client und SDM-Server fr Produktivsysteme gesichert?

Hinweis:
SAP empfiehlt, fr die Softwareverteilung auf produktive Zielsysteme eine gesicherte
VPN-Verbindung oder einen IP-Filter einzurichten und zu nutzen. Beachten Sie hierzu
die SAP Note 1616058.
6.10. SAP ENTERPRISE PORTAL

Das SAP Enterprise Portal stellt Java-Anwendungen gem der J2EE bzw. Java EE als
Standard-Java-Container zur Verfgung. Hierfr werden sogenannte fertige Build-Pakete
durch die Entwicklung erstellt und auf die produktiven Web- und EJB-Container bertragen.
Die Inbetriebnahme von Java-Builds wird auch als Deployment bezeichnet.
Abbildung 4: Mgliche Komponenten einer Portalanwendung
Jedes Build verfgt ber eine Konfigurationsdatei, die vom Java-Container gelesen und fr den
Betrieb des Java-Programms genutzt wird. In SAP-Portalanwendungen knnen Inhalte aus
diversen SAP-Quellen integriert werden. Selbst aus dem ABAP stammende Webkomponenten
(z.B. SAP GUI oder Web Dynpro) knnen ber das Enterprise Portal beliebig zusammengefasst
und dargestellt werden (siehe Abbildung 4). Die hier eingesetzten Komponenten basieren auf
Web-Technologien, die im produktiven Einsatz eine ausreichende Systemhrtung sicherstellen
mssen. Schwachstellen in der Konfiguration knnen die Sicherheit der Anwendung erheblich
beeintrchtigen und alle betriebenen Anwendungen gefhrden. Die in diesem Abschnitt beschriebenen Manahmen sind zwingend umzusetzen, um eine Grundlage fr einen sicheren Betrieb und
die Wirksamkeit eines IKS-Systems fr Java-Anwendungen zu schaffen.
95
96
6.11. PRFPROGRAMM: SAP-JAVA-STACK-SOFTWAREVERTEILUNG

NR.
SICHERE ANWENDUNG DES SAP ENTERPRISE PORTALS
1.
Kontrollziel: Deaktivierung des Invoker Servlets

Risiko: Geschtzte Portalanwendungen und Java-Klassen knnen ohne Authentifizierung aufgerufen werden. Unbefugte Dritte knnen den administrativen Zugang zum
System erlangen und eingerichtete Schutzmechanismen umgehen.
1.1.
H
Ist das Invoker Servlet global deaktiviert?

Risiko: Sollte der genannte Parameter auf TRUE stehen oder nicht vorhanden sein,
besteht ein erhebliches Sicherheitsrisiko. ber schwachstellenbehaftetete Systemschnittstellen, z.B. die CTC-Komponente, kann bspw. ohne Anmeldung auf Systemressourcen zugegriffen werden. Die Vertraulichkeit und Integritt von Daten kann nicht
wirksam gewhrleistet werden.
Hinweis 1: Das Invoker Servlet sollte deaktiviert und kritische Java-Klassen vor
unautorisierten Zugriffen geschtzt werden. Ein globales Abschalten des Invoker
Servlet kann durch ein False im Parameter EnableInvokerServletGlobally in
der Global server configuration/configuration/cfg/services/servlet_jsp.properties
erreicht werden.
Hinweis 2: Die SAP Notes 1467771 und 1445998 beschreiben die versionsabhngigen
Voraussetzungen.
1.2.
H
Ist der Klassenaufruf eines Servlets deaktiviert?

Hinweis: Deaktivieren Sie den Aufruf eines Servlets durch Klassen-Namen unter
Global server configuration/configuration/persistent/servlet_jsp/global-web.xml.
2.
Kontrollziel: Absicherung des Portal-Tokens

Risiko: Portal-Token knnen durch Angreifer ber potenzielle Cross-Site-Scripting
oder Cross-Site-Request-Forgery-Sicherheitslcken kompromittiert werden.
Hierdurch erhalten Angreifer den unautorisierten Zugang zum System.
Hinweis: Analog zum J2EE-Token muss auch das Portal-Token angemessen vor
potenziellen Webrisiken geschtzt werden. Beide Token bilden die zentralen Authentifizierungsmerkmale des Benutzers whrend einer Sitzung fr das J2EE und das
Enterprise Portal.
2.1.
Ist eine maximale Gltigkeit des Tokens bei Inaktivitt gesetzt?

Hinweis: Lebensdauer des Logon Tickets kann unter Global server configuration/
configuration/cfg/services/com.sap.security.core.ume.service.properties ausgewertet
werden. Beachten Sie, dass anwendungsbezogene Tokens eine eigene Laufzeit besitzen
knnen.
2.2.
Ist der Zugriff auf das Cookie mittels Javascript gesperrt?

Hinweis: Bewirkt, dass das httpOnly Flag fr SAP Logon Tickets gesetzt wird.
Dadurch kann das Cookie nicht mehr durch JavaScript ausgelesen werden, wodurch
Cross-Site-Scripting Angriffe erschwert werden.
2.3.
Werden Cookies ausschlielich ber HTTPS bertragen?

Hinweis: Bewirkt, dass das secure Flag fr SAP Logon Tickets gesetzt wird.
Dadurch wird dieses Cookie nur noch ber verschlsselte Verbindungen versendet.
Gngige Browser speichern das Cookie nur im Arbeitsspeicher und erzeugen keine
lokale Kopie im Cache.
NR.
3.
Kontrollziel: Hrtung der Portalanwendungen

Risiko: Das Enterprise Portal stellt umfangreiche Einstellungsmglichkeiten zur
Verfgung, die bei einer nicht sachgerechten Konfiguration Schutzmechanismen
deaktivieren knnen. Angreifern knnen somit Zugriffe auf vertrauliche Daten ohne
Zugangsdaten ermglicht werden.
Hinweis: Webanwendungen verfgen im J2EE ber eine eigene Konfiguration, die im
Zusammenwirken mit globalen Systemeinstellungen funktioniert. Daher mssen die
lokalen Konfigurationsdateien ausreichend sicher implementiert werden, um eine
ausreichende Betriebssicherheit zu gewhrleisten.
3.1.
H
Ist der Schutz vor Cross-Site Request Forgery aktiviert?

Hinweis: Schutz vor Cross-Site Request Forgery (Parameter xsrf.protection.enabled)
unter Global server configuration/configuration/cfg/services/servlet_jsp.properties
aktivieren.
3.2.
Ist die Nutzung von ActiveX im Enterprise Portal unterbunden?

Hinweis: ActiveX kann ber die Parametrisierung a-ra:/applications/com.sap.portal.
ui.uiservice/services/ui deaktiviert werden. Sofern mglich, sollte auf ActiveX generell
verzichtet werden.
3.3.
H
Ist das Directory Listing deaktiviert?

Hinweis: Directory Listing sollte grundstzlich deaktiviert werden. Die Einstellungen
knnen je nach Version wie folgt ausgewertet werden:
SAP J2EE engine 6.20:
DirList=false in server/services/http/properties and server/services/servlet_jsp/properties
SAP J2EE Engine 6.40:
Visual Administrator - ServerID - Services - Http Provider. On the tab Runtime -
Virtual Hosts - General (which is shown by default) there's a check box 'Directory List'
3.4.
H
Sind alle selbst entwickelten Anwendungen mit einer ausreichenden Security Zone
ausgestattet?
Risiko: Verfgen Anwendungen ber die Security Zone No Safety, lassen sie sich direkt
ber die URL aufrufen, z.B. ber /irj/servlet/prt/portal/prtroot/iView_ID.
Je nach Applikation kann unter Umstnden auf vertrauliche Daten zugegriffen werden.
Hinweis: Bewerten Sie Applikationen mit der Security Zone No Safety im Hinblick auf
den Schutzbedarf.
97
98
NR.
3.5.
Werden interne Fehler durch eine eigene Fehlerseite unterdrckt?

Risiko: Fehlertexte liefern Angreifern wertvolle Informationen ber zentrale
Komponenten und Daten. Diese knnen wertvolle Information fr weiterfhrende
Angriffswege liefern. Datenbankfehler knnen Daten direkt in Fehlerseiten ausgeben
und die Vertraulichkeit der Daten gefhrden.
Hinweis: Interne Fehler sollten abgefangen und nicht in den Content der Webseite
weitergegeben werden. In der WEB.XML lsst sich ber den Parameter error-page
das Verhalten bei internen Fehlern konfigurieren. Beispielsweise leitet der folgende
Auszug die Fehlernummer 500 auf eine eigene Fehlerseite um:
error-page
error-code500/error-code
location/path/to/error.jsp/location
/error-page
error-page
exception-typejava.lang.Throwable/exception-type
location/path/to/error.jsp/location
/error-page
3.6.
H
Wenn alle HTTP-Methoden, die nicht bentigt werden, deaktiviert werden, wie unterbindet man dann kritische Handlungen im System?
Risiko 1: Wenn die Methode HEAD erlaubt ist, kann mittels HTTP Verb Tampering
eine Schwachstelle ausgenutzt werden, um zugriffsgeschtzte Funktionen im Portal
ohne Anmeldung auszufhren. Dies kann u.a. zum Anlegen von Benutzern oder zur
Erweiterung von Berechtigungen ausgenutzt werden.
Risiko 2: Die Methode TRACE kann potenzielle Cross-Site-Scripting-Angriffe
begnstigen.
Hinweis 1: Alle HTTP-Methoden, die nicht bentigt werden, sollten in der WEB.XML
explizit deaktiviert werden (lschen aller http-method Eintrge). Zugriff auf kritische
Anwendungen sollte nur mit gltiger Authentifizierung mglich sein (security-constraint).
Hinweis 2: SAP Notes 1503579,1616259,1589525 und 1624450 sollten implementiert sein.
3.7.
H
Wurde die WEB.XML von allen lokalen Invoker Servlet Aktivierungen bereinigt?
Hinweis: Alle paramInvokerServletLocallyEnabled/param mssen aus der WEB.
XML gelscht werden, um ein lokales Aktivieren des Invoker Servlets zu verhindern.
3.8.
Laufen Sitzungen bei Inaktivitt ab?

Hinweis: Sitzungen sollten ber den session-timeout-Parameter in der
WEB.XML gem den Sicherheitsvorgaben fr inaktive Sitzungen eingestellt sein.
3.9.
Wird die bertragung von Session-IDs in der URL verhindert?

Risiko: Die Anzeige der Token oder Session-IDs in der URL kann in diversen Caches
oder Proxy- und Browser-Historien aufgezeichnet werden. Fremde knnen auf diese
gespeicherten Eintrge u.U. zugreifen und die Sitzung eines aktiven Benutzers bernehmen.
Hinweis: Der Parameter tracking-mode sollte auf COOKIE gesetzt werden, um
die Session-ID als Cookie und nicht innerhalb der URL zu bergeben.
NR.
3.10.
Erfordert die Nutzung der Anwendung HTTPS?

Hinweis: Der Parameter transport-guarantee sollte auf CONFIDENTIAL
gestellt sein, um HTTPS zu nutzen.
3.11.
H
Ist der Schutz vor Cross-Site-Scripting-Attacken (XSS) via EPCF eingerichtet?

Hinweis: Beachten Sie die SAP Note 1656549.
3.12.
H
Ist der Schutz vor XML-External-Entity-Attacken (XXE) eingerichtet?

3.13.
H
Wurden die Filter im Knowledge Management aktiviert, um das Hochladen bsartiger Dateien zu verhindern?
Hinweis:
Prfen Sie die Dateierweiterungen in File Extension und Dateigren Filter unter
System Administration > System Configuration > Content Management >
Repository > Filters > Show Advanced Options > File Extension and Size Filter
Prfen Sie die Filter in Malicious Script Filter unter System Administration
> System Configuration > Content Management Repository > Filters > Show
Advanced Options > Malicious Script Filter
Ist der Parameter Forbidden Scripts aktiviert?
Ist die Option Send E-Mail to Administrator aktiviert?
3.14.
H
Wurde die Validierung der Pfade im Knowledge Management System installiert?

Risiko: Wenn nicht erlaubte Pfade akzeptiert werden, knnen Phishing-Angriffe
begnstigt werden.
99
100
NR.
4.
Kontrollziel: Berechtigungsmanagement im Enterprise Portal

Risiko: Wenn Aktionen falsch zugewiesen werden, erhalten Portalbenutzer unautorisierten Zugriff auf geschtzte Anwendungen und Daten. Die Wirksamkeit des IKS und
Berechtigungskonzepts wird somit unterlaufen.
Hinweis: UME setzt auf einen programmatischen Berechtigungskonzeptansatz, indem
der Entwickler Anwendungsrechte (Permissions) in der Anwendung definiert und diese
in der Datei actions.xml zu Aktionen bndelt. Jede Aktion wird gegen eine Rolle im UME
gemappt. Vor diesem Hintergrund muss jede einzelne Aktion im Portal dahingehend untersucht werden, ob die in der UME eingerichtete Rolle sachgerecht zugewiesen wurde.
User aus dem ABAP-System sind als solche in der UME sichtbar und knnen sich am
AS Java authentifizieren.
Zuordnung in
der UME-Konsole
Zuordnung
durch Entwickler
in der Datei actions.xml
Erlaubnis 1
Aktion 1
UME-Rolle 1
Benutzer
Erlaubnis 2
Aktion 2
UME-Rolle 2
Erlaubnis 3
Aktion 3
UME-Rolle 3
Gruppe
Abbildung 5: Abhngigkeit Portal- und UME-Rollen
Die ABAP-Rollen erscheinen in der UME als UME-Gruppen. Im ABAP-System erhlt der
Nutzer seine Berechtigungen aus dem zur Rolle gehrenden Profil. Seine Java-Berechtigungen bekommt er aus der UME-Rolle, die der UME-Gruppe zugeordnet wird.
4.1.
Existiert ein Regelprozess fr die Prfung der actions.xml bei der Einfhrung oder
nderung von Portalanwendungen?
4.2.
Sind die eingerichteten Rollen und Zuweisungen in einem Berechtigungskonzept

definiert?
NR.
4.3.
Sind administrative Rollen (siehe ) in selbstentwickelten Portalanwendungen

gemappt?
Hinweis: Standardrollen sollten nicht in Eigenentwicklungen verwendet werden. Wenn
einzelne administrative Funktionsbausteine bentigt werden, sollten angepasste Rollen
erzeugt und ausgerollt werden.
5.
Kontrollziel: Deaktivieren von nicht bentigten Diensten

Risiko: Aktivierte Funktionsbausteine knnen bei der Verffentlichung von Schwachstellen die Systemsicherheit erheblich gefhrden und wirksame Zugriffsschutzmechanismen umgehen.
Hinweis: In der Auslieferung und Standardinstallation werden einige hundert JavaFunktionsaufrufe installiert. Ein Groteil der Funkionen wird nicht genutzt und muss
explizit durch die Administratoren im VisualAdmin Tool deaktiviert werden. Dieses
Verfahren entspricht dem Vorgehen gem SICF-Transaktion im ABAP-Stack.
5.1.
Existiert ein Standardprozess zum Deaktivieren von Standard-Diensten beim

Einrichten neuer SAP-Instanzen?
5.2.
Entsprechen die aktivierten Dienste den Anforderungen der fachlich bentigten

Services?
Hinweis: Im VisualAdmin kann eine Liste von aktivierten Diensten erzeugt und
geprft werden.
101
102

DATENBANKEBENE
7.1. INTERNE UND EXTERNE ANFORDERUNGEN
Die Daten eines SAP-Systems werden in einer proprietren Datenbank gehalten, z.B. Oracle. Auf
alle Daten eines SAP-Systems kann ber das Datenbanksystem zugegriffen werden. Dabei knnen
auch Daten gendert werden unabhngig vom Zugriffsschutz, der ber die SAP-Anwendungen
realisiert ist.
Die Datenbank ist ein eigenes System, das implementiert, konfiguriert, betrieben, verwaltet und
berwacht werden muss. Dabei sind die allgemeinen Sicherheitsanforderungen zur Gewhrleistung von Verfgbarkeit, Zugriffsschutz, Integritt und Vertraulichkeit umzusetzen.
Spezielle Sicherheitsanforderungen ergeben sich zum einen aus dem SAP-spezifischen Einsatz
der Datenbank, zum anderen aus der proprietren Ausprgung der Funktionen der Datenbank.
Deshalb sind sowohl die Hinweise von SAP zu den Datenbank-Plattformen im SAP NetWeaver
Security Guide zu bercksichtigen als auch die Security White Paper des Herstellers der Datenbank.
Prfungsstandards zum Einsatz von Informationstechnologie fordern insbesondere die Prfung
der Datenbank eines ERP-Systems.
7.2. RISIKEN
Risiken knnen sich zum einen daraus ergeben, dass die Sicherheitsempfehlungen von SAP
nicht umgesetzt sind, zum anderen, dass die Datenbank konkurrierend zur Nutzung durch
SAP genutzt wird:
Die SAP-Systembenutzer, der Datenbank-Systembenutzer oder zustzlich eingerichtete
Administratoren nutzen noch das Initialkennwort des Auslieferungsstandes der Software.
Dies ermglicht auch nicht autorisierten Dritten das unbefugte Anmelden an die Datenbank.
Benutzer aus der Fachabteilung knnen sich an die Datenbank anmelden und sind berech tigt, mit den Funktionen der Datenbank nderungen in den Datenbanktabellen durchzu fhren, die konkurrierend auch von SAP-Benutzern gendert werden.
Angreifer knnen ber nicht bentigte Datenbankbenutzer eine Sicherheitsschwachstelle
im Datenbanksystem nutzen, um privilegierten Zugriff auf die Datenbank zu erlangen.
Die Datenbank lsst beliebige Anmeldeversuche ber das Netz zu.
Anmeldungen an die Datenbank werden nicht protokolliert und berwacht.
Die Daten in der Datenbank sind nicht verschlsselt und werden auch nicht verschlsselt
bertragen.
Sicherheitsempfehlungen des Herstellers der Datenbank sind nicht umgesetzt.
7.3. KONTROLLZIELE
Die Sicherheitsempfehlungen von SAP zur sicheren Konfiguration und zum ordnungsmigen
Betrieb der Datenbank sind umgesetzt.
Eine zur SAP-Anwendung konkurrierende Nutzung der Datenbank ist nicht implementiert,
die nderungen an den gleichen Datenbanktabellen zulsst, die schon SAP verwaltet.
Anmeldungen von beliebigen Clients aus nicht vertrauenswrdigen Netzwerksegmenten an
der Datenbank sind verhindert.
Die technischen Mglichkeiten, dass ein Benutzer sich von seinem Client aus direkt an der
Datenbank anmelden kann, sind entweder ausgeschlossen oder auf den notwendigen Umfang
eingeschrnkt und gegen unbefugte Nutzung abgesichert (ODBC-Zugriff).
Nicht bentigte Datenbankbenutzer sind gesperrt oder gelscht.
Die Funktionen zur Anmeldekontrolle werden genutzt, die das proprietre Datenbanksystem
bereitstellt. Insbesondere werden Fehlversuche bei der Anmeldung protokolliert und
berwacht.
Die Daten in der Datenbank werden entsprechend ihrem Schutzbedarf verschlsselt
gespeichert und bertragen.
Zustzliche Sicherheitsempfehlungen des Herstellers der Datenbank sind umgesetzt.
7.4. PRFPROGRAMM: ABSICHERUNG VON ORACLE UNTER UNIX

NR.
AUTHENTISIERUNG MIT ORACLE UNTER UNIX
1.
Kontrollziel: Angemessene Zugriffskontrolle fr Oracle unter UNIX

Risiko: Beliebige Benutzer knnen sich Remote an der Datenbank unter einem der
Standard-Datenbankbenutzer mit dem Standardkennwort anmelden, knnen alle
Tabelleninhalte einsehen und nicht autorisierte nderungen durchfhren.
1.1.
Welche Benutzer sind in der Datenbank eingerichtet?

SQL> SELECT * FROM all_users;
Klren, welche Benutzer zu welchem Zweck eingerichtet sind.
Nicht bentigte Datenbankbenutzer, z.B. Gast- oder Demo-Benutzer, sind zu sperren
oder zu entfernen.
1.2.
H
Ist der SAP-Datenbankbenutzer SAPR3/SAPSAPSID gegen unbefugten Zugriff

geschtzt?
1. Durch regelmigen Wechsel des Kennworts fr SAPSIDADM?
2. Durch Deaktivieren des Dienstes rlogin?
3. Durch Deaktivieren anderer hostbasierter Authentifizierungen, z.B. ber SSH
(HostbasedAuthentication)?
4. Durch angemessene Nutzung des Valid-Node-Checking-Mechanismus der sqlnet.
ora-Datei, der Quell-IP-Adressen zulsst oder aussperrt? (Siehe 4.1.)
103
104
NR.
1.3.
H
Sind die Standardkennwrter der Standard-Datenbankbenutzer gendert?

- SAPSAPSID oder SAPR3 (Kennwort: SAP)
- SYS (Kennwort: CHANGE_ON_INSTALL)
- SYSTEM (Kennwort: MANAGER).
Sind noch Default-Passwrter der Oracle-Default-Accounts vorhanden?
SQL>select * from dba_users_with_defpwd; (ab 11g)
Austesten, ob eine Anmeldung mit den Standardkennworten bzw. Benutzername=Passwort
mglich ist.
Die Kennwrter sind whrend der Installation zu ndern. Komplexe Kennwrter sind zu
whlen.
1.4.
Werden Systemereignisse wie An- und Abmeldungen an der Datenbank protokolliert?

SQL>select * from DBA_AUDIT_SESSION;
SQL>show parameter audit;
Wird die Protokolldatei regelmig archiviert und gelscht, um zu verhindern, dass es
zu einem berlauf der SYS.AUD$-Tabelle kommt?
Haben nur Systemadministratoren Zugriffsrechte auf die Einstellungen fr die Protokolldatei und auch die Protokolldatei selbst?
2.

werden.
2.1.
Wurde eine Passwort-Policy-Prfungsfunktion fr alle relevanten Nutzerprofile

hinterlegt?
SQL>select * from dba.profiles;
Prfung, ob ein Wert fr PASSWORD_VERIFY_FUNCTION angegeben ist.
Prfung, ob die angegebene Funktion den Anforderungen an sichere Passworte gengt.
2.2.
Ab wie vielen Anmeldeversuchen wird ein Account gesperrt (FAILED_LOGIN_ATTEMPTS)

und wie lange wird ein Account gesperrt (PASSWORD_LOCK_TIME)?
Die Einstellungen mssen einen Brute-Force-Angriff erschweren, drfen aber nicht zu
einer dauerhaften Deaktivierung von Accounts fhren.
2.3.
Sind Passwrter Case-Sensitiv? (ab 11g)

SQL>show parameter sec_case_sensitive_logon;
Sind noch Accounts mit case-insensitivem Passwort vorhanden?
SQL>select username, password_versions from dba.dba_users;
3.
Kontrollziel: Zugriff auf die Datenbank ist exklusiv fr SAP-Anwendungen und gem
den Vorgaben von SAP installiert.
Risiko: Konkurrierende Datenbanknderungen durch weitere Datenbankanwendungen auf den SAP-Tabellen fhren zur Dateninkonsistenz.
3.1.
Sind die Zugriffsrechte fr Oracle-Verzeichnisse und -Dateien unter UNIX so gesetzt,

wie es von SAP vorgesehen ist und bei der Standard-Installation durchgefhrt wird?
Insbesondere die Daten-Dateien, Log- und Trace-Dateien und die KonfigurationsDateien mssen vor dem unbefugten Auslesen oder gar Verndern geschtzt sein.
NR.
3.2.
Nutzt exklusiv das SAP-System die Datenbank oder werden auch andere
Anwendungen auf der Datenbank betrieben?
Auf der Datenbank fr das SAP-System drfen keine anderen Anwendungen ablaufen,
insbesondere drfen keine Verknpfungen zwischen den Tabellen des SAP-Systems
und anderen Datenbanken eingerichtet sein.
3.3.
Ist der Oracle Listener sicher konfiguriert?

Ist ein Kennwort fr den Oracle Listener vergeben?
3.4.
Sind weitere Nutzer in der OS-Gruppe dba auer sidadm und personalisierten
Administratoren?
3.5.
Sind unntige Datenbank-Links definiert?

SQL>select * from dba_db_links;
Sind diese public?
Welchen Schutzbedarf haben die Systeme im Vergleich zum geprften System?
NR.
REDUZIERUNG DER ANGRIFFSFLCHE VON ORACLE UNTER UNIX
4.
Kontrollziel: Um die Angriffsflche zu verringern, drfen nur die notwendigen Services

und Einstiegsmglichkeiten gegeben und erreichbar sein.
Risiko: Mit jeder unntigen Komponente erhht sich die Wahrscheinlichkeit, dass
Schwachstellen im System ausgenutzt werden knnen.
4.1.
H
Knnen sich Benutzer ber eine Client-Software an der Datenbank anmelden?

Ist der Remote-Datenbankzugriff eingeschrnkt und kontrolliert?
Sind in der sqlnet.ora-Datei die IP-Adressen der zugelassenen Clients
(Management-Konsolen) eingetragen (tcp.invited.nodes)?
Ist der Zugriff auf die Datenbank ber eine Firewall geregelt (Oracle Listener auf dem
Port TCP/IP 1521)?
4.2.
Sind Komponenten des Oracle-DBMS aktiv, welche nicht bentigt werden?

Zum Beispiel: Apache-HTTP-Server, Enterprise Manager, APEX, OLAP, Ultrasearch, Java
4.3.
Werden auf der Betriebssysteminstanz weitere Datenbanken oder andere Dienste

betrieben?
Angriffe auf diese zustzlichen Systeme knnen sich auch auf die Datenbank auswirken.
Nur absolut notwendige Dienste sollten auf dem Server betrieben werden.
4.4.
Sind nicht-bentigte externe Prozeduren definiert?

PROGRAM=extproc in der listener.ora
105
106
7.5. PRFPROGRAMM: ABSICHERUNG VON ORACLE UNTER WINDOWS

NR.
AUTHENTISIERUNG MIT ORACLE UNTER WINDOWS
1.
Kontrollziel: Angemessene Zugriffskontrolle fr Oracle unter Windows

Standard-Datenbankbenutzer mit dem Standardkennwort anmelden, knnen alle
Tabelleninhalte einsehen und nicht autorisierte nderungen durchfhren.
1.1.
Welche Benutzer sind in der Datenbank eingerichtet?

SQL> SELECT * FROM all_users;
Klren, welche Benutzer zu welchem Zweck eingerichtet sind.
Nicht bentigte Datenbankbenutzer, z.B. Gast- oder Demo-Benutzer, sind zu sperren
oder zu entfernen.
1.2.
Wird der OPS-Mechanismus korrekt genutzt?

SQL> select * from OPS$<SID>ADM.SAPUSER
SAP empfiehlt, nur OPS$-Benutzer fr die Windows Benutzer zu definieren, die fr
den Betrieb des SAP-Systems erforderlich sind. Normalerweise sind das die Benutzer
SAPServiceSID und SIDADM. Weitere Informationen ber das Anlegen von OPS$Benutzern unter Windows finden sich im SAP-Hinweis 50 088.
1.3.
H
Sind die SAP-Datenbankbenutzer SAPR3/SAPSAPSID und SAPSIDADM gegen

unbefugten Zugriff geschtzt?
1. Durch regelmigen Wechsel des Kennworts fr SAPSIDADM?
2. Durch angemessene Nutzung des Valid-Node-Checking-Mechanismus der sqlnet.
ora-Datei, der Quell-IP-Adressen zulsst oder aussperrt? (Siehe 4.1.)
1.4.
H
Sind die Standardkennwrter der Standard-Datenbankbenutzer gendert?

- SAPSAPSID oder SAPR3 (Kennwort: SAP)
- SYS (Kennwort: CHANGE_ON_INSTALL)
- SYSTEM (Kennwort: MANAGER).
Sind noch Default-Passwrter der Oracle-Default-Accounts vorhanden?
SQL>select * from dba_users_with_defpwd; (ab 11g)
Austesten, ob eine Anmeldung mit den Standardkennworten bzw. Benutzername=Passwort
mglich ist.
Die Kennwrter sind whrend der Installation zu ndern. Komplexe Kennwrter sind zu
whlen.
1.5.
Werden Systemereignisse wie An- und Abmeldungen an der Datenbank protokolliert?

SQL>select * from DBA_AUDIT_SESSION;
SQL>show parameter audit;
Wird die Protokolldatei regelmig archiviert und gelscht, um zu verhindern, dass es
zu einem berlauf der SYS.AUD$-Tabelle kommt?
Haben nur Systemadministratoren Zugriffsrechte auf die Einstellungen fr die Protokolldatei und auch die Protokolldatei selbst?
2.

werden.
2.1.
Wurde eine Passwort-Policy-Prfungsfunktion fr alle relevanten Nutzerprofile

hinterlegt?
Prfung, ob ein Wert fr PASSWORD_VERIFY_FUNCTION angegeben ist.
Prfung, ob die angegebene Funktion den Anforderungen an sichere Passworte gengt.
NR.
AUTHENTISIERUNG MIT ORACLE UNTER WINDOWS
2.2.
Ab wie vielen Anmeldeversuchen wird ein Account gesperrt (FAILED_LOGIN_

ATTEMPTS) und wie lange wird ein Account gesperrt (PASSWORD_LOCK_TIME)?
Die Einstellungen mssen einen Brute-Force-Angriff erschweren, drfen aber nicht zu
einer dauerhaften Deaktivierung von Accounts fhren.
2.3.
Sind Passworter Case-Sensitiv? (ab 11g)

SQL>show parameter sec_case_sensitive_logon;
Sind noch Accounts mit case-insensitivem Passwort vorhanden?
SQL>select username, password_versions from dba.dba_users;
NR.
INTEGRITTSWAHRUNG MIT ORACLE UNTER WINDOWS
3.
Kontrollziel: Zugriff auf die Datenbank ist exklusiv fr SAP-Anwendungen und gem
den Vorgaben von SAP installiert.
Risiko: Konkurrierende Datenbanknderungen durch weitere Datenbankanwendungen auf den SAP-Tabellen fhren zur Dateninkonsistenz.
3.1.
Sind die Zugriffsrechte fr ORACLE-Verzeichnisse und -Dateien unter Windows

so gesetzt, wie es von SAP vorgesehen ist und bei der Standard-Installation
durchgefhrt wird?
Um die ORACLE-Dateien zu schtzen, mssen folgende Zugriffsrechte vergeben sein:
- der lokalen Gruppe SAP_SID_LocalAdmin und dem lokalen Benutzer SYSTEM
mssen die Zugriffsrechte Full control fr alle ORACLE-Dateien zugewiesen sein.
- anderen Gruppen oder Benutzern drfen keine Zugriffsrechte fr die ORACLEDateien vergeben sein.
Die folgende Tabelle gibt die Dateien und die zugehrenden notwendigen
Zugriffsrechte an:
3.2.
ORACLE VERZEICHNISSE
ZUGRIFFSRECHT
BENUTZER ODER GRUPPE
%ORACLE_HOME%
Full Control
SYSTEM, Administrators,
SAP_SAPSID_GlobalAdmin
(domain installation),
SAP_SAPSID_LocalAdmin
(local installation)
drive:\oracle\dbsid
Full Control
SYSTEM, Administrators,
SAP_SAPSID_GlobalAdmin
(domain installation),
SAP_SAPSID_LocalAdmin
(local installation)
Nutzt exklusiv das SAP-System die Datenbank oder werden auch andere
Anwendungen auf der Datenbank betrieben?
Auf der Datenbank fr das SAP-System drfen keine anderen Anwendungen ablaufen,
insbesondere drfen keine Verknpfungen zwischen den Tabellen des SAP-Systems
und anderen Datenbanken eingerichtet sein.
107
108
NR.
INTEGRITTSWAHRUNG MIT ORACLE UNTER WINDOWS
3.3.
H
Ist der Oracle Listener sicher konfiguriert?

Ist ein Kennwort fr den Oracle Listener vergeben?
3.4.
Sind unntige Datenbank-Links definiert?

SQL>select * from dba_db_links;
Sind diese public?
Welchen Schutzbedarf haben die Systeme im Vergleich zum geprften System?
NR.
REDUZIERUNG DER ANGRIFFSFLCHE VON ORACLE UNTER WINDOWS
4.
Kontrollziel: Um die Angriffsflche zu verringern, drfen nur die notwendigen Services

und Einstiegsmglichkeiten gegeben und erreichbar sein.
Risiko: Mit jeder unntigen Komponente erhht sich die Wahrscheinlichkeit, dass
Schwachstellen im System ausgenutzt werden knnen.
4.1.
H
Knnen sich Benutzer ber eine Client-Software an der Datenbank anmelden?

Ist der Remote-Datenbankzugriff eingeschrnkt und kontrolliert?
- Sind in der sqlnet.ora-Datei die IP-Adressen der zugelassenen Clients
(Management-Konsolen) eingetragen (tcp.invited.nodes)?
Ist der Zugriff auf die Datenbank ber eine Firewall geregelt (Oracle Listener auf dem
Port TCP/IP 1521)?
4.2.
Sind Komponenten des Oracle-DBMS aktiv, die nicht bentigt werden?

Zum Beispiel: Apache-HTTP-Server, Enterprise Manager, APEX, OLAP, Ultrasearch,
Java
4.3.
Werden auf der Betriebssysteminstanz weitere Datenbanken oder andere Dienste

betrieben?
Angriffe auf diese zustzlichen Systeme knnen sich auch auf die Datenbank auswirken.
Nur absolut notwendige Dienste sollten auf dem Server betrieben werden.
4.4.
Sind nicht-bentigte externe Prozeduren definiert?

PROGRAM=extproc in der listener.ora
7.6. PRFPROGRAMM: SICHERES DATENBANKMANAGEMENT MIT ORACLE

NR.
DATENBANKMANAGEMENT
1.
Kontrollziel: Implementierung eines Risikomanagement-Prozesses

Risiko: Durch unentdeckte und unbewertete Risiken kann der Sicherheitszustand der
Datenbank nicht definiert werden und somit keine Manahmen getroffen werden.
1.1.
Wurden smtliche Sicherheitsvorgaben konsolidiert und dokumentiert?
1.2.
Wurden anhand von Datenklassifizierung, Infrastruktur und bereits implementierten

Sicherungsmanahmen Risiken erfasst und bewertet?
1.3.
Wurden anhand der fehlenden Umsetzung von Sicherheitsvorgaben und den erfassten
Risiken Manahmen dokumentiert, priorisiert und mit Umsetzungsterminen versehen?
1.4.
Wurden Verantwortliche ernannt, welche den Status der Umsetzung berwachen?
NR.
DATENBANKMANAGEMENT
1.5.
Werden regelmige Konfigurationsprfungen und Bestandsaufnahmen durchgefhrt, um

sicherzustellen, dass die einmal vorgenommenen Hrtungen weiterhin vorzufinden sind?
Werden dabei auch Erkenntnisse aus aktuellen Bedrohungen, Sicherheitsvorfllen und
bekannten Schwachstellen bercksichtigt?
2.
Kontrollziel: Es existiert ein angemessenes und funktionierendes Datenbanksicherungs- und Disaster-Recovery-Konzept

Risiko: Ein nicht funktionsfhiges Datensicherungskonzept knnte zum Verlust von
Daten fhren und damit ggf. die Vollstndigkeit des Buchungsstoffes gefhrden.
2.1.
Besteht ein Datenbanksicherungskonzept und wie ist dieses ausgeprgt?
2.2.
Wie ist sichergestellt, dass keine Daten verloren gehen bzw. unvollstndige Datensicherungen erkannt werden?
2.3.
Besteht ein Disaster-Recovery-Konzept und wie ist dieses ausgeprgt?
2.4.
Liegen Nachweise vor, die die Funktionsfhigkeit des Datenbanksicherungs- und

Disaster-Recovery-Konzeptes belegen?
3.
Kontrollziel: Es besteht ein angemessener und funktionierender Patch ManagementProzess

Risiko: Wesentliche sicherheitsrelevante Patches von Oracle sind nicht installiert,
sodass Angreifer bekannte Sicherheitsschwachstellen ausnutzen knnen.
3.1.
H
Befindet sich die eingesetzte Produktversion in der Premier Support- oder Extended
Support-Phase? Wird die Version also weiterhin mit Sicherheitspatches beliefert?
3.2.
Wird die Datenbank mit von SAP freigegebenen Sicherheits-Patches (CPU critical
patch updates) auf dem neusten Stand gehalten?
3.3.
Gibt es einen geregelten und dokumentierten Prozess zur Freigabe und Installation von
Patches?
4.
Kontrollziel: Wahrung der Vertraulichkeit und Integritt der Daten durch Verschlsselung
Risiko: Sensible Daten knnen aus der Kommunikation mitgelesen und manipuliert
werden. Daten knnen von Systemadministratoren ausgelesen werden.
4.1.
Wird entsprechend der System- und Datenklassifizierung Verschlsselung fr die

Kommunikation und die Datenhaltung in der Datenbank vorgenommen?
4.2.
Ist die Transport-Verschlsselung und Integrittsprfung obligatorisch?

Sqlnet.ora:
SQLNET.ENCRYPTION_CLIENT = required
SQLNET.CRYPTO_CHECKSUM_CLIENT = required
4.3.
Wird entsprechend den aktuellen Crypto-Bewertungen eine sichere

Verschlsselungs- und Hashfunktion verwendet?
Sqlnet.ora:
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT
SQLNET.ENCRYPTION_TYPES_CLIENT
4.4.
Werden fr administrative Zugriffe verschlsselte Kommunikationswege verwendet?

Wenn auf Listener-Verschlsselung verzichtet wird, da die Kommunikation in einem
abgesicherten Netzsegment stattfindet, sollte der administrative Zugriff auf den Listener z.B. nur ber einen SSH-Tunnel stattfinden anstelle von einem unverschlsselten
direkten Zugriff.
109
110

BETRIEBSSYSTEMEBENE
8.1. INTERNE UND EXTERNE ANFORDERUNGEN
Das Betriebssystem bildet die operative Plattform fr ein SAP-System. Auf dem Betriebssystem
werden die Anwendungen von SAP installiert, konfiguriert und betrieben. In diesem Zusammenhang bietet das Betriebssystem diverse Zugriffsmglichkeiten auf Programme und Daten eines
SAP-Systems, die ber die verfgbaren Sicherheitsmanahmen anforderungsgerecht zu kontrollieren sind. Die Sicherheitskontrollen von SAP-Anwendungen haben nur begrenzt Mglichkeiten,
Zugriffe auf das darunterliegende Betriebssystem zu unterbinden. Dabei knnen Programme und
Daten gendert werden unabhngig von dem Zugriffsschutz, der ber die SAP-Anwendungen
eingerichtet ist.
Das Betriebssystem ermglicht den Zugriff auf das SAP-System ber das Netzwerk oder das Dateisystem. Angriffe aus dem Netzwerk zielen auf Sicherheitsschwachstellen in der Konfiguration der
verfgbaren Dienste und auf technische Verwundbarkeiten des Betriebssystems.
Spezielle Sicherheitsanforderungen ergeben sich aus
der SAP-spezifischen Nutzung von Betriebssystemfunktionen,
der proprietren Ausprgung der Sicherheitseinstellungen des jeweiligen Betriebssystems und
den proprietren technischen Schnittstellen zu anderen Anwendungen, z.B. Datenbanken
oder Diensten, die ber das Netzwerk aufrufbar sind.
Es sind sowohl die Hinweise von SAP zu den Betriebssystem-Plattformen im SAP NetWeaver Security Guide zu bercksichtigen als auch die Security Guides der jeweiligen Betriebssystemhersteller.
8.2. RISIKEN
Risiken knnen sich daraus ergeben, dass die Sicherheitsempfehlungen von SAP oder andere
sicherheitsrelevante Einstellungen des Betriebssystems gem den Hinweisen des Herstellers
des Betriebssystems nicht umgesetzt sind:
Die Kennwrter der SAP-Systembenutzer, der Standard-Betriebssystembenutzer oder zustz lich eingerichteter Administratoren sind noch auf dem Standard der Auslieferung oder lassen
sich leicht erraten und ermglichen das unautorisierte Anmelden an das Betriebssystem.
Der Zugriff auf der Ebene des Betriebssystems durch Benutzer oder ber fr sie eigens
eingerichtete Benutzerfunktionen, z.B. File Transfer, ist schlecht konfiguriert und unzu reichend abgesichert.
Aufgrund von unzureichend gesetzten Zugriffsprivilegien knnen beliebige Anwender auf ein
Verzeichnis mit streng vertraulichen Informationen oder ausfhrbaren SAP-Programmen zu greifen, das ber das Netz nur fr eine bestimmte Benutzergruppe bereitgestellt sein soll.
Anmeldungen an das Betriebssystem werden nicht protokolliert und berwacht.
Das Betriebssystem hat eine bekannte Sicherheitsschwachstelle, die ein Angreifer ber
das Netz erkennen und ausnutzen kann. Dieses kann zur Offenlegung von sensiblen Daten
oder der Kompromittierung des Systems fhren.
Eine nicht autorisierte Dritt-Anwendung ist eingerichtet, die einen ungeschtzten Zugriff auf
Dateien und Anwendungen erlaubt.
Die Manipulation eines SAP-Programms oder von systemrelevanten Dateien wird nicht erkannt.
8.3. KONTROLLZIELE
Die Sicherheitsempfehlungen von SAP zur sicheren Konfiguration des Betriebssystems sind
umgesetzt.
Zustzliche Sicherheitsempfehlungen des Herstellers des Betriebssystems sind umgesetzt.
Das Betriebssystem verfgt ber alle aktuellen Sicherheitsaktualisierungen.
Die physische Sicherheit des Systems ist gewhrleistet.
Der Zugriff ber das Netz auf das Betriebssystem ist restriktiv gesetzt und sicher konfiguriert.
Network Shares sind mit restriktiven Zugriffsrechten nur fr die zugelassene Benutzergruppe
gesetzt. Sie werden auf fehlerhafte Zugriffsvergaben (Windows: EVERYONE, UNIX: weltweites
Lese- oder Schreibrecht) berwacht.
Die Funktionen zur Anmeldekontrolle, die das Betriebssystem bereitstellt, werden genutzt.
Insbesondere werden Fehlversuche bei der Anmeldung protokolliert und berwacht.
Nicht autorisierte Anwendungen und Systemdienste wurden entweder deaktiviert oder vom
System entfernt.
Die SAP-Programme und -Dateien unterliegen einem Integrittscheck.
8.4. PRFPROGRAMM: SYSTEMINTEGRITT VON UNIX/LINUX

NR.
PHYSISCHER SCHUTZ
1.
Kontrollziel: Angemessener physischer Schutz des Systems

Nur wenige autorisierte Personen sollten physischen Zugriff zu dem System besitzen.
Das unkontrollierte Neustarten eines Systems sowie das Booten von anderen Medien
(CD, USB Medium etc.) sollte verhindert werden.
Risiko:
Unbefugte Personen knnen Festplatten oder andere Medien stehlen oder die
Hardware des Servers manipulieren bzw. sabotieren.
1.1.
Welche Personen haben physischen Zugang zu dem System? Sind diese Personen fr
den Zugang zu den Rechnerrumen oder Rechenzentren autorisiert?
1.2.
Welche Manahmen wurden gegen eine physische Sabotage oder Manipulation

ergriffen?
1.3.
Werden regelmige Kontrollen zur berprfung der jeweiligen Hardware durchgefhrt?
111
112
NR.
ZUGRIFFSPRIVILEGIEN UND -KONTROLLEN
2.
Kontrollziel: Angemessene Zugriffsprivilegien und -kontrollen auf UNIX/Linux-Ebene

Der Zugriff personenbezogener Benutzer auf das Betriebssystem ist auf wenige
Systemadministratoren beschrnkt.
Benutzer aus Fachabteilungen haben keinen Zugriff auf das Betriebssystem.
Automatisierte Anmeldekontrollen und Passwortbildungsregeln auf der Ebene des
Betriebssystems sind fr die personenbezogenen Benutzer aktiviert.
Die Anmeldungen werden protokolliert und berwacht.
Die Zugriffsrechte sind nach dem Prinzip der minimalen Berechtigung vergeben.
Die fr UNIX/Linux-Systeme spezifischen und verschiedenen technischen Mglichkeiten, Eigentmerrechte auf Verzeichnisse und Dateien zu vergeben, sind kontrolliert eingesetzt.
Risiko:
Personenbezogene Benutzer haben leicht erratbare Kennwrter gewhlt, die keinem
nderungszwang unterliegen.
Versuche, die Kennwrter von Benutzern auszuprobieren, werden nicht protokolliert
und berwacht.
Nicht autorisierte Benutzer knnen Zugriff auf das Betriebssystem erlangen.
Personenbezogenen Benutzern sind Standardumgebungen, z.B. login shell, eingerichtet, die zu weit reichende automatische Rechtevergaben beinhalten. Unbefugte
Aktionen auf der Betriebssystemebene sind mglich. Die Integritt der System- und
Datendateien des SAP-Systems ist gefhrdet.
2.1.
Wird ein sicheres Authentifizierungsverfahren eingesetzt? Nutzt dieses Verfahren

modernste Verschlsselungsverfahren? Werden Zugangsdaten durch ein zentrales
Anmeldesystem verwaltet?
Im Unix besteht die Mglichkeit, sichere Anmeldeverfahren wie z.B. TACAC+ oder LDAP
zu verwenden. Hierdurch knnen Administratoren zentral und systembergreifend
verwaltet werden. Zudem werden schtzenswerte Zugangsdaten zentral abgelegt und
systembergreifend bereitgestellt. Eine lokale Speicherung auf dem Host ist nicht
erforderlich.
2.2.
Welche Benutzer sind auf dem System eingerichtet? Sind neben den Standardsystembenutzern auch personenbezogene Benutzer vergeben? Welche Aufgaben haben diese
eingerichteten personenbezogenen Benutzer?
Die Benutzer root, sidadm und dbsid sollten neben wenigen Spezialsystembenutzern die einzigen Benutzer auf den Anwendungsservern und der Hauptinstanz sein.
Nach der Installation kann dbsid auf den Anwendungsservern gesperrt werden.
Hinweis: Die Standardbenutzer sind in der Systemdokumentation des Herstellers und
von SAP aufgefhrt.
2.3.
Bietet das UNIX/Linux-Betriebssystem eine shadow-Datei, in der die gehashten Passwrter gespeichert sind und auf die nur der Superuser root Zugriff hat? Ist innerhalb
der /etc/passwd bei allen Benutzern im Passwort Feld ein x eingetragen?
Fr die Speicherung der gehashten Passwrter sollte immer die separate shadow-Datei
(/etc/shadow) verwendet werden, da die Datei /etc/passwd fr alle Benutzer lesbar sein
muss. Ein x innerhalb des Passwort-Feldes der Datei /etc/passwd zeigt an, dass das
gehashte Passwort in der /etc/shadow Datei hinterlegt ist.
2.4.
Sind fr alle Benutzer Passwrter vergeben?
2.5.
Welche Gruppen sind auf dem System eingerichtet? Sind neben den Standardgruppen
auch unternehmensspezifische Gruppennamen vergeben? Welche Benutzer sind den
unternehmensspezifischen Gruppen zugeordnet? Welche Rechte wurden den jeweiligen
Gruppen zugeordnet?
Hinweis: Die Standardgruppen sind in der Systemdokumentation des Herstellers aufgefhrt.
NR.
2.6.
Sind Regeln fr die Bildung und nderung des Passwortes aktiviert?

Die Bildung des Kennworts sollte definierten Komplexittsregeln unterliegen, d.h.,
das Kennwort sollte unter anderem eine gewisse Lnge und unterschiedliche Zeichen
(alphanumerisches Zeichen und Sonderzeichen) aufweisen mssen.
Hinweis: Zum Beispiel mittels PAM (Pluggable Authentication Module) oder der
Datei /etc/login.defs knnen Richtlinien bezglich der Passwortkomplexitt umgesetzt
werden. Die Systemdokumentation des Herstellers informiert jedoch darber, welche
Anmelde- und Kennwortkontrollen das betreffende UNIX/Linux-System untersttzt.
2.7.
Werden Anmeldungen von Benutzern, insbesondere fehlerhafte Anmeldungen

automatisch, protokolliert und berwacht?
Bei Linux werden verhaltensrelevante Ereignisse durch den Syslog in sogenannten
Logfiles gespeichert, die meist unter /var/log zu finden sind. Hier sollte vor allem die
Datei auth.log regelmig ausgewertet werden.
Hinweis: Die Systemdokumentation des Herstellers informiert darber, ob und wie das
betreffende UNIX/Linux-System die Protokollierung der Anmeldungen untersttzt.
2.8.
Sind die Zugriffsprivilegien auf die SAP-Datei- und Systemverzeichnisse so gesetzt, wie
es von SAP vorgesehen ist und bei der Installation standardmig durchgefhrt wird?
Hinweis: Folgende Zugriffsprivilegien werden bei der Installation automatisch gesetzt:
2.9.
SAP Verzeichnis oder Datei
Zugriffsrecht
Besitzer
Gruppe
/sapmnt/SAPSID/exe
755
sapsidadm
sapsys
/sapmnt/SAPSID/exe/saposcol
4755
root
sapsys
/sapmnt/SAPSID/global
700
sapsidadm
sapsys
/sapmnt/SAPSID/profile
755
/usr/sap/SAPSID
751
/usr/sap/SAPSID/Instance ID
755
/usr/sap/SAPSID/Instance ID/*
750
sapsidadm
sapsys
/usr/sap/SAPSID/Instance ID/sec
700
sapsidadm
sapsys
/usr/sap/SAPSID/SYS
755
sapsidadm
sapsys
/usr/sap/SAPSID/SYS/*
755
sapsidadm
sapsys
/usr/sap/trans
775
sapsidadm
sapsys
/usr/sap/trans/*
770
sapsidadm
sapsys
/usr/sap/trans/.sapconf
755
sapsidadm
sapsys
home directory of sapsidadm
700
sapsidadm
sapsys
home directory of sapsidadm/*
700
sapsidadm
sapsys
Welche UMASK-Definitionen sind in den relevanten Dateien, z.B. in .login, .cshrc,

.profile, /etc/profile vergeben?
UMASK kann dazu verwendet werden, die Berechtigungen fr neu erstellte Dateien
automatisch zu beschrnken. Zum Beispiel gibt ein UMASK Wert von 0027 an, dass
Dateien mit den Rechten 640 (der Besitzer darf die Dateien lesen sowie verndern und
die Gruppe darf die Dateien lesen) und Ordner mit den Zugriffsrechten 750 (der Besitzer
darf Dateien innerhalb der Ordner erstellen sowie lschen und die Gruppe kann die
Verzeichnisinhalte einsehen) erstellt werden.
Die festgelegten Vorgaben mssen insbesondere fr alle Login-Umgebungen
personenbezogener Benutzer gelten.
113
114
NR.
2.10.
Werden SUID/SGID-Dateien berwacht, insbesondere bei der Installation neuer zustzlicher Software auf dem Betriebssystem?
Hinweis: Dateien, bei denen das SUID oder SGID Bit gesetzt ist, werden mit den Rechten
des Benutzers bzw. der Gruppe ausgefhrt, der diese Datei gehrt. Normalerweise werden
diese Bits bei Dateien verwendet, die als Superuser root ausgefhrt werden mssen, um
auf Systemressourcen, die erweiterte Berechtigungen bentigen, zuzugreifen.
Risiko: Diese Dateien sind beliebte Ziele von Angreifern, um erweiterte Privilegien,
z.B. des Superusers, zu erhalten.
NR.
KONFIGURATION VON DIENSTEN UND NETZWERKZUGRIFFEN
3.
Kontrollziel: Sichere Konfiguration von Diensten und Netzwerkzugriffen

Schwachstellen in der Konfiguration eines Dienstes bzw. innerhalb des Dienstes selber knnen die Sicherheit des Systems erheblich beeintrchtigen. Auf einem System
sollten nur Anwendungen installiert sein, die das System zur Durchfhrung seiner
Aufgabe bentigt. Daher sollte das System auf die Bereitstellung eines Dienstes oder
einer Gruppe gleichartiger Dienste beschrnkt sein. Unterschiedliche Dienste sollten
auf separaten Systemen eingerichtet sein. Die Sicherheitsbewertung und die Gruppierung der Dienste wurden mit dem Sicherheitsbeauftragten abgestimmt.
Risiko: Schwachstellen in Programmen bzw. Diensten knnen zur Offenlegung
von sensiblen Daten bzw. zur Kompromittierung des Systems fhren.
3.1.
Sind die Sicherheitshinweise des UNIX/Linux-Distributors zum Hrten des Systems,

z.B. Hinweise zum Deaktivieren nicht bentigter Dienste, bekannt und umgesetzt?
3.2.
Wird das Betriebssystem mit den vom UNIX/Linux-Distributor freigegebenen

Sicherheits-Patches auf dem neusten Stand gehalten?
3.3.
Wird eine Firewall oder eine Paketfilterung eingesetzt, die nur autorisierten Netzwerkverkehr zulsst?
Hinweis: Eine Liste von Ports, die durch SAP-Software genutzt werden, wird von SAP
bereitgestellt. Eine zentrale, netzwerkbasierte Paketfilterung erhht die Sicherheit der
gesamten SAP-Landschaft und erleichtert die Verwaltung und Wartung der Regelwerke. SAP bietet Zertifizierungen fr Sicherheitslsungen an; eine Liste von zertifizierten
Herstellern knnen im SAP-Portal frei eingesehen werden.
3.4.
Werden zur Wartung des Systems Remote-Werkzeuge eingesetzt? Sind diese sicher
konfiguriert?
Es sollte vermieden werden, Programme/Protokolle wie ftp, telnet oder rlogin/rsh zu
verwenden, da diese die Daten unverschlsselt bertragen und somit ein Abfangen der
Daten ermglichen. Daher wird der Einsatz von sicheren Alternativen wie ssh, scp oder
sftp empfohlen.
Hinweis: Die sicherere Konfiguration des jeweiligen Dienstes kann entsprechenden
Sicherheitshandbchern entnommen werden.
3.5.
Ist das Network Information System (NIS) restriktiv und kontrolliert eingesetzt?
Risiko: NIS erlaubt es jedem UNIX-System, in einem lokalen Netzwerk mit dem Befehl
ypcat passwd die mittels NIS zentral gehaltene Passwortdatei zu lesen und zu
verwenden.
Alternative: Dieser Service wird nur innerhalb eines abgesicherten lokalen Netzwerkes eingesetzt.
NR.
3.6.
Administrative Fernzugriffe auf das Betriebssystem sind durch sichere Verfahren

abzusichern, d.h., sind die Standardkennwrter durch komplexe Kennwrter ersetzt,
wird eine sichere Verschlsselung genutzt und sind Hrtungsmanahmen fr
Web-Schnittstelle getroffen worden? Werden alternative Zugriffsmglichkeiten, wie
z.B. Terminalserver, genutzt?
Risiko: Bei der Installation eines UNIX/Linux-Betriebssysteme kann standardmig
ein Remote-Zugriff der Systemadministratoren implementiert werden, ohne dass dies
bei der Installation bekannt oder wahrgenommen wird. Angreifer aus dem Netzwerk
knnen die dabei vergebenen Standardkennworte oder Sicherheitsschwachstellen in
der Version des betreffenden Web-Servers ausnutzen, um unbefugte Aktionen auf der
Ebene des Betriebssystems auszufhren.
3.7.
Ist der X-Windows Service im Einsatz? Wird er tatschlich bentigt? Ist er gem den
Sicherheitsempfehlungen des UNIX/Linux-Herstellers installiert?
3.8.
Ist das Network Filesystem (NFS) restriktiv und kontrolliert eingesetzt?

ber NFS drfen keine Verzeichnisse mit vertraulichen Daten exportiert werden. ber
NFS drfen keine Home-Verzeichnisse von welchen Benutzern auch immer mit
Schreibberechtigung exportiert werden. Verzeichnisse drfen nur an vertrauenswrdige
Systeme exportiert werden.
Risiko: Die ber NFS exportierten Verzeichnisse knnen vertrauliche Daten, die fr alle
Benutzer im Netz lesbar sind, enthalten. Wird ein fr alle beschreibbares Home-Verzeichnis eines UNIX/Linux-Benutzers exportiert, ist darber ein Angriff auf das UNIX/
Linux-System mglich, der dem Angreifer die bernahme der Privilegien des Superusers root ermglicht.
NR.
SICHERHEITSRICHTLINIEN UND VORGEHENSWEISEN
4.
Kontrollziel: Sicherheitsrichtlinien und Vorgehensweisen

Welche Manahmen sind eingerichtet, um die Integritt sowie den Schutz der
Vertraulichkeit des Systems sicherzustellen und zu berwachen?
Risiko:
Bei unzureichenden Manahmen knnen die Integritt sowie der Schutz der
Vertraulichkeit des Systems nicht ausreichend gewhrleistet sein.
4.1.
Wird das System z.B. durch einen Syslog-Dienst durchgngig berwacht? Ist der
Zugriff auf die Log-Dateien restriktiv vergeben und werden die Log-Dateien revisionssicher auf einem zentralen Loghost gespeichert? Werden regelmige Auswertungen
auf verdchtige Aktivitten durchgefhrt?
Damit die durchgngige Systemfunktionalitt sichergestellt werden kann, muss das
System berwacht und bestimmte Ereignisse protokolliert werden. Da die Protokolldateien wichtige Systeminformationen und persnliche Daten enthalten knnen, muss der
Zugriff auf diese Protokolldateien eingeschrnkt werden. Nur berechtige Benutzer sollten daher Zugriff auf die Dateien erhalten. Eine Auslagerung der Protokolldateien auf
einen dedizierten Log-Server kann die Sicherheit erhhen. Betriebspersonal hat keinen
Zugriff auf die zentralen Log-Dateien. In der Praxis knnen sogenannte SIEM-Systeme
(Security Incident & Event Management Systeme) klassische Log-Hosts ersetzen. Intelligente Abfragen untersttzen dabei die Analyse von verdchtigen Vorgngen.
115
116
NR.
4.2.
Wird ein Back-up des Systems auf einem dedizierten Medium (separater Back-up
Server) durchgefhrt?
Ein Back-up kann einerseits dabei helfen, gelschte oder beschdigte Daten wieder
herzustellen. Andererseits kann es auch dem Abgleich mit vorhandenen Daten dienen,
um so kompromittierte Daten ausfindig zu machen. Es muss jedoch darauf geachtet
werden, dass das Back-up-Medium in einer sicheren Umgebung aufbewahrt wird,
sodass dass es gegen Manipulation geschtzt ist.
4.3.
Untersttzt das UNIX/Linux-Betriebssystem Integrittsprfungen oder sogenannte Host

based Intrusion Detection Software (HIDS) fr Systemdateien? Wird diese Mglichkeit
genutzt?
4.4.
Gibt es eine Richtlinie, wie Daten auf stillgelegten Systemen oder von nicht mehr
verwendeten Datenmedien gelscht werden?
Werden Systeme stillgelegt bzw. Datenmedien nicht mehr verwendet, mssen die darauf
enthaltenen sensiblen Daten so gelscht werden, dass diese nicht wieder hergestellt
werden knnen. Um dieses zu erreichen, knnen sogenannte Wipe Tools eingesetzt
werden.
8.5. PRFPROGRAMM: SYSTEMINTEGRITT VON WINDOWS

NR.
PHYSISCHER SCHUTZ
1.
Kontrollziel: Angemessener physischer Schutz des Systems

Nur wenige autorisierte Personen sollten physischen Zugriff zu dem System besitzen.
Das unkontrollierte Neustarten eines Systems sowie das Booten von anderen Medien
(CD, USB Medium etc.) sollte verhindert werden.
Risiko:
Unbefugte Personen knnen Festplatten oder andere Medien stehlen oder die
Hardware des Servers manipulieren bzw. sabotieren.
1.1.
Welche Personen haben physischen Zugang zu dem System? Sind diese Personen fr
den Zugang zu den Rechnerrumen oder Rechenzentren autorisiert?
1.2.
Welche Manahmen wurden gegen eine physische Sabotage oder Manipulation ergriffen?
1.3.
Werden regelmige Kontrollen zur berprfung der jeweiligen Hardware durchgefhrt?
NR.
2.
Kontrollziel: Angemessene Zugriffsprivilegien und -kontrollen auf Windows-Ebene

Der Zugriff personenbezogener Benutzer auf das Betriebssystem ist auf wenige
Systemadministratoren beschrnkt.
Benutzer aus Fachabteilungen haben keinen Zugriff auf das Betriebssystem.
Automatisierte Anmeldekontrollen und Passwortbildungsregeln auf der Ebene des
Betriebssystems sind fr die personenbezogenen Benutzer aktiviert.
Die Anmeldungen werden protokolliert und berwacht.
Die Zugriffsrechte sind nach dem Prinzip der minimalen Berechtigung vergeben. Die
fr Windows-Systeme spezifischen und verschiedenen technischen Mglichkeiten, Eigentmerrechte auf Verzeichnisse und Dateien zu vergeben, sind kontrolliert eingesetzt.
Risiko:
Personenbezogene Benutzer haben leicht erratbare Kennwrter gewhlt, die
keinem nderungszwang unterliegen.
Versuche, die Kennwrter von Benutzern auszuprobieren, werden nicht
protokolliert und berwacht.
Nicht autorisierte Benutzer knnen Zugriff auf das Betriebssystem erlangen.
Personenbezogenen Usern sind zu weit reichende Rechte vergeben. Unbefugte
Aktionen auf Betriebssystemebene sind mglich. Die Integritt der System- und
Dateien des SAP-Systems ist gefhrdet.
2.1.
Ist das SAP-System auf einem Windows-Domnencontroller installiert?

Hinweis: Ein auf einem Domnencontroller definiertes lokales Benutzerrecht ist auf
allen Domnencontrollern gltig.
SAP empfiehlt, SAP-Systeme nicht auf einem Domnencontroller zu installieren.
2.2.
Werden insbesondere bei groen Systemlandschaften die SAP Systeme durch eine
separate Domne von den Unternehmensdaten getrennt?
SAP empfiehlt, zwei getrennte Domnen fr die SAP-Systeme anzulegen.
In der Unternehmens-Domne sind die Domnenbenutzer, einschlielich der
SAP-Systembenutzer, und der Unternehmens-Domnenadministrator eingerichtet.
In der davon getrennten SAP-Domne sind die SAP-System-Server, Dienste und
Administratoren eingerichtet. Dazu zhlen:
SAP-System-Anwendungsserver und -Datenbankserver
SAP-System- oder Datenbank-Dienste
SAP-Systemadministratoren
Windows-Administratoren
Administratoren der SAP-Domne
2.3.
Welche Vertrauensbeziehungen sind zwischen anderen Windows-Domnen und der

Windows-Domne fr die SAP-Systeme definiert?
Hinweis 1: In den Standard-Installationsvorgehensweisen empfiehlt SAP, getrennte
Domnen einzurichten. Zu beachten ist jedoch, dass bestimmte SAP-spezifische Funktionen und Windowsspezifische Services eine Vertrauensbeziehung zwischen Domnen
erfordern.
Es gibt bestimmte Services, die nur eine einseitige Vertrauensbeziehung erfordern,
z. B. das Drucken im Netzwerk mit dem Print Manager oder die Dateienbertragung
mit Betriebssystembefehlen wie z.B. xcopy oder move.
Einige Services erfordern eine beiderseitige Vertrauensbeziehung, z.B. SingleSign-On ber das Microsoft LAN Manager Security Service Provider Interface
(NTLMSSPI).
Hinweis 2: Wenn das SAP-System standardmig installiert wird, implementiert das
Installationswerkzeug, SAPinst genannt, automatisch alle notwendigen Manahmen, die
relevant sind, um das SAP-System gegen nicht autorisierten Zugriff zu schtzen.
117
118
NR.
2.4.
Welche Gruppen sind auf den SAP-Servern registriert (Windows-Domne)? Sind neben den Standardgruppen auch unternehmensspezifische Gruppennamen vergeben?
Welche Benutzer sind den unternehmensspezifischen Gruppen zugeordnet? Welche
Rechte wurden den jeweiligen Gruppen zugeordnet?
Es sollten keine anderen Gruppen als die Windows-Standardgruppen und die SAPSystem- und Datenbankgruppen definiert sein.
Hinweis 1: Globale Benutzergruppen sind innerhalb einer Windows-Domne gltig,
nicht nur auf einem Server.
SAP empfiehlt, die Domnenbenutzer nach Aufgaben in verschiedenen Aktivittsgruppen
zu bndeln. Der Domnenadministrator kann die Aktivittsgruppen in andere Domnen
exportieren, sodass der entsprechende Benutzer auf alle zur Verwaltung des SAPSystems erforderlichen Ressourcen zugreifen kann.
Hinweis 2: Standardmig ist die globale Gruppe fr SAP-Administratoren als
SAP_SID_GlobalAdmin definiert.
2.5.
Welche Gruppen sind auf den SAP-Servern registriert (lokaler SAP-Server)? Sind neben
den Standardgruppen auch unternehmensspezifische Gruppennamen vergeben? Welche
Benutzer sind den unternehmensspezifischen Gruppen zugeordnet? Welche Rechte
wurden den jeweiligen Gruppen zugeordnet?
Hinweis 1: Lokale Benutzergruppen (und lokale Benutzer) liegen lokal auf einem Server
vor. Bei der Installation werden Benutzerrechte lokalen Benutzern anstelle von Gruppen
zugeordnet. Z.B. erhlt der Benutzer <SID>ADM das Benutzerrecht Logon on as a service.
SAP empfiehlt, um die Benutzerverwaltung zu vereinfachen, Serverressourcen lokalen
Gruppen anstelle von einzelnen Benutzern zuzuordnen. Entsprechende globale Benutzer
und globale Gruppen knnen dann der lokalen Gruppe zugeordnet werden. Dadurch kann
besser kontrolliert werden, wer zu welcher Gruppe gehrt und welche Aufgaben er besitzt.
Hinweis 2: Standardmig ist die lokale Gruppe fr SAP-Administratoren als
SAP_SID_LocalAdmin definiert. Diese lokale Gruppe enthlt die Domnen-Gruppe
SAP_SID_GlobalAdmin.
2.6.
Welche Benutzer sind auf dem System eingerichtet? Sind neben den Standardsystembenutzern auch personenbezogene Benutzer vergeben? Welche Aufgaben haben diese
eingerichteten personenbezogenen Benutzer?
Hinweis: Die Standardbenutzer sind in der Systemdokumentation des Herstellers und
von SAP aufgefhrt.
2.7.
Ist der Benutzeradministrator gesichert?

Hinweis: Der in Windows eingebaute Administrator hat unbeschrnkten Zugriff auf alle
Windows-Ressourcen. Der Administrator kann z.B.
Dateien, Festplatten und Shares anlegen, verwalten und deren Besitzer werden
lokale Benutzer anlegen und ihre Rechte verwalten
Peripheriegerte, Kernel- und Benutzer-Services anlegen und verwalten
SAP empfiehlt, diesen Benutzer zu deaktivieren, um ihn vor unberechtigtem Zugriff
zu schtzen. Der Benutzername muss gendert und das Kennwort geheim gehalten
werden. Fr Verwaltungsaufgaben sollten andere Benutzer angelegt und deren Rechte
auf die Aufgaben, fr die sie verwendet werden, z.B. Benutzeradministrator, Sicherungsund Serveroperatoren, beschrnkt sein.
NR.
2.8.
Ist der Benutzer SIDADM gesichert?

Hinweis 1: SIDADM ist der Windows-Benutzer fr die SAP-Systemverwaltung. Der
Benutzer wird whrend des SAP-Systeminstallationsverfahrens, normalerweise als
Domnenbenutzer fr das SAP-System, angelegt. Der Benutzer kann sich daher an
allen Windows-Rechnern in der Domne anmelden. SIDADM bentigt vollen Zugriff
auf alle instanzspezifischen Ressourcen des SAP-Systems wie Dateien, Shares, Peripheriegerte (z.B. Bandlaufwerke oder Drucker) und Netzwerkressourcen (z.B. den
SAProuter-Service).
Des Weiteren ist SIDADM Mitglied der lokalen Administrations-Gruppe und besitzt
weitreichende Privilegien, um das SAP-System zu administrieren oder zu erweitern.
SAP empfiehlt, die folgenden Manahmen zu ergreifen, um diesen Benutzer vor
unberechtigtem Zugriff zu schtzen:
sein Kennwort regelmig zu ndern.
seine Zugriffsrechte auf instanzenspezifische Ressourcen fr das SAP-System
zu beschrnken.
Hinweis 2: Wenngleich SIDADM auf SAP-System-Dateien zugreifen kann, wird das
SAP-System von einem anderen Benutzer (SAPServiceSID) gestartet.
2.9.
Ist der Benutzer SAPServiceSID gesichert?

Hinweis 1: SAPServiceSID wird bei der Installation des SAP-Systems angelegt. Der
Benutzer wird normalerweise als ein Domnenbenutzer, der das SAP-System ausfhrt
und Datenbankressourcen verwaltet, angelegt. Der Benutzer kann sich lokal auf allen
Windows-Rechnern in der Domne anmelden.
Da das SAP-System selbst dann laufen muss, wenn kein Benutzer an dem lokalen
Windows-Rechner angemeldet ist, luft das SAP-System als Windows-Dienst. Aus
diesem Grund erhlt der Benutzer SAPServiceSID whrend der Installation das Recht
Logon as a service auf dem lokalen Rechner.
Hinweis 2: SAPServiceSID verwaltet auch die SAP-System- und Datenbankressourcen
innerhalb des Computing Center Management System (CCMS). Der Benutzer braucht
daher vollen Zugriff auf alle instanzen- und datenbankspezifischen Ressourcen wie
Dateien, Shares, Peripheriegerte und Netzwerkressourcen.
Hinweis 3: Das Kennwort dieses Windows-Service-Benutzers zu ndern, ist relativ
schwierig, da hierfr der Service somit auch das SAP-System gestoppt werden muss.
SAP empfiehlt, folgende Vorkehrungen treffen, um SAPServiceSID zu schtzen:
das Benutzerrecht Log on locally und Log on through Terminal Services aufzuheben
seinen Zugriff auf instanz- und datenbankspezifische Ressourcen zu beschrnken
2.10.
Ist der Benutzer-Gast gesperrt oder gelscht?
2.11.
Sind fr alle Benutzer Passwrter vergeben?
2.12.
Sind Regeln fr die Bildung und nderung des Passwortes aktiviert?

Die Bildung des Kennworts sollte definierten Komplexittsregeln unterliegen, d.h.,
das Kennwort sollte unter anderem eine gewisse Lnge und unterschiedliche Zeichen
(alphanumerisches Zeichen und Sonderzeichen) aufweisen mssen.
Hinweis: Die Komplexittsvoraussetzungen fr ein Kennwort knnen unter Windows
ber eine sogenannte Kontorichtlinie festgelegt werden. Die Systemdokumentation des
Herstellers informiert jedoch darber, welche Anmelde- und Kennwortkontrollen das
betreffende Windows-System untersttzt.
2.13.
Werden Anmeldungen von Benutzern, insbesondere fehlerhafte Anmeldungen

automatisch, protokolliert und berwacht?
Damit fehlerhafte Logins innerhalb der Ereignisanzeige angezeigt werden, mssen
diese in der berwachungsrichtlinie der lokalen Computerkonfiguration aktiviert sein.
119
120
NR.
2.14.
Wer darf das SAP-System starten oder stoppen?
2.15.
Sind die Zugriffsprivilegien auf die SAP Datei- und Systemverzeichnisse so gesetzt, wie
es von SAP vorgesehen ist und bei der Installation standardmig durchgefhrt wird?
2.16.
Wer hat Zugriff auf das Shared Memory?

Hinweis: Der gemeinsame Speicher wird vom SAP-System-Dispatcher und den Workprozessen fr bestimmte Aktivitten verwendet, z.B. zur Zwischenspeicherung oder fr
den Austausch von Verwaltungsinformationen. Diese Prozesse nutzen die Access Contol
Lists (ACL) ihrer eigenen ausfhrbaren Datei (z.B. fr den Dispatcher: disp+work.exe)
dazu ihre angelegten oder hinzugefgten Shared-Memory-Segmente zu schtzen. Das
bedeutet, Benutzer, die nur die Rechte Read, List Content und Execute besitzen, knnen
keine Shared-Memory-Segmente erzeugen bzw. in sie hineinschreiben.
2.17.
Sind die Schutzmanahmen fr dynamisch erzeugte Dateien wirksam?

Hinweis: Eine von ABAP erstellte Datei erhlt die Zugriffsrechte des Ordners, in dem
sie erstellt wurde. Nur der Besitzer der Dateien oder der Administrator kann diese
Zugriffsrechte ndern. Wenn ABAP-Anweisungen die Dateien anlegen, gehren sie
dem SAP-System (SIDADM oder SAPServiceSID).
NR.
3.
Kontrollziel: Sichere Konfiguration von Diensten und Netzwerkzugriffen

Schwachstellen in der Konfiguration eines Dienstes bzw. innerhalb des Dienstes selber
knnen die Sicherheit des Systems erheblich beeintrchtigen. Auf einem System sollten
nur Pakete installiert sein, die das System zur Durchfhrung seiner Aufgabe bentigt.
Ein Programm oder ein Dienst, welches nicht installiert ist, kann durch einen Angreifer
nicht verwendet werden. Daher sollte das System auf die Bereitstellung eines Dienstes
beschrnkt sein. Unterschiedliche Dienste sollten auf separaten Systemen eingerichtet
sein.
Risiko: Schwachstellen in Programmen bzw. Diensten knnen zur Offenlegung von
sensiblen Daten bzw. zur Kompromitterung des Systems fhren.
3.1.
Sind die Sicherheitshinweise von Microsoft zum Hrten des Systems, z.B. Hinweise
zum Deaktivieren nicht bentigter Dienste, bekannt und umgesetzt?
Hinweis: Als Referenz knnen hier die von Microsoft bereitgestellten Dokumente
Security Guide for SAP on SQL Server 2012 oder SAP Hardening and
PatchManagement Guide for Windows Server dienen.
3.2.
Wird das Betriebssystem mit den von Microsoft freigegebenen Sicherheits-Patches auf
dem neusten Stand gehalten?
3.3.
Wird eine Firewall oder eine Paketfilterung eingesetzt, die nur autorisierten Netzwerkverkehr zulsst?
Hinweis: Eine Liste von Ports, die durch SAP-Software genutzt werden, wird von SAP
bereitgestellt. Eine zentrale, netzwerkbasierte Paketfilterung erhht die Sicherheit der
gesamten SAP-Landschaft und erleichtert die Verwaltung und Wartung der Regelwerke. SAP bietet Zertifizierungen fr Sicherheitslsungen an; eine Liste von zertifizierten
Herstellern knnen im SAP-Portal frei eingesehen werden.
NR.
3.4.
Sind Windows-Freigaben restriktiv und kontrolliert eingesetzt?

Windows-Freigaben sollten keine Full-Control-Rechte fr jedermann aufweisen. Besonders die Rechte auf das Transport-Verzeichnis sollten beschrnkt sein. Zudem sollten
fr eine verstrkte Sicherheit des Systems die dynamisch erzeugten administrativen
Freigaben deaktiviert werden.
3.5.
Administrative Fernzugriffe auf das Betriebssystem sind durch sichere Verfahren abzusichern, d.h., sind die Standardkennwrter durch komplexe Kennwrter ersetzt, wird
eine sichere Verschlsselung genutzt und sind Hrtungsmanahmen fr Web-Schnittstelle getroffen worden? Werden alternative Zugriffsmglichkeiten, wie z.B. Terminalserver, genutzt?
NR.
4.
Kontrollziel: Sicherheitsrichtlinien und Vorgehensweisen

Welche Manahmen sind eingerichtet, um die Integritt sowie den Schutz
der Vertraulichkeit des Systems sicherzustellen und zu berwachen?
Risiko:
Bei unzureichenden Manahmen knnen die Integritt sowie der Schutz der
Vertraulichkeit des Systems nicht ausreichend gewhrleistet sein.
4.1.
Wird das System z.B. durch einen Eventlog-Dienst durchgngig berwacht? Ist der
Zugriff auf die Log-Dateien restriktiv vergeben und werden die Log-Dateien revisionssicher auf einem zentralen Loghost gespeichert? Werden regelmige Auswertungen
auf verdchtige Aktivitten durchgefhrt?
Damit die durchgngige Systemfunktionalitt sichergestellt werden kann, muss das
System berwacht und bestimmte Ereignisse protokolliert werden. Da die Protokolldateien wichtige Systeminformationen und persnliche Daten enthalten knnen, muss der
Zugriff auf diese Protokolldateien eingeschrnkt werden. Nur berechtige Benutzer sollten daher Zugriff auf die Dateien erhalten. Eine Auslagerung der Protokolldateien auf
einen dedizierten Log-Server kann die Sicherheit erhhen. Betriebspersonal hat keinen
Zugriff auf die zentralen Log-Dateien. In der Praxis knnen sogenannte SIEM-Systeme
(Security Incident & Event Management Systeme) klassische Log-Hosts ersetzen. Intelligente Abfragen untersttzen dabei die Analyse von verdchtigen Vorgngen.
4.2.
Wird ein Backup des Systems auf einem dedizierten Medium (separater Back-upServer, Tape) durchgefhrt?
Ein Back-up kann einerseits dabei helfen, gelschte oder beschdigte Daten wieder
herzustellen. Andererseits kann es auch dem Abgleich mit vorhandenen Daten dienen,
um so kompromittierte Daten ausfindig zu machen. Es muss jedoch darauf geachtet werden, dass das Back-up-Medium in einer sicheren Umgebung aufbewahrt wird,
sodass es gegen Manipulation geschtzt ist.
4.3.
Untersttzt das Windows-Betriebssystem Integrittsprfungen oder sogenannte Host

based Intrusion Detection Software (HIDS) fr Systemdateien? Wird diese Mglichkeit
genutzt?
4.4.
Gibt es eine Richtlinie, wie Daten auf stillgelegten Systemen oder von nicht mehr
verwendeten Datenmedien gelscht werden?
Werden Systeme stillgelegt bzw. Datenmedien nicht mehr verwendet, mssen die darauf
enthaltenen sensiblen Daten so gelscht werden, dass diese nicht wieder hergestellt
werden knnen. Um dieses zu erreichen, knnen sogenannte Wipe Tools eingesetzt
werden.
121
122
GOVERNANCE, RISK MANAGEMENT, COMPLIANCE (GRC)
9. RISIKEN AUS DEM EINSATZ VON SAP GRC

Durch die verstrkte Sensibilisierung von Daten und Systemen hinsichtlich der Zugriffsrisiken
haben die meisten vor allem greren Unternehmen bereits Manahmen getroffen, um diesen
entgegenzuwirken. Oftmals ist es unumgnglich, auf bewhrte Compliance-Tools zurckzugreifen,
um Kontrollen zu automatisieren. Diese untersttzen Organisationen bei der Schaffung von
Transparenz, Bewertung und angemessenem Umgang mit Zugriffsrechten. Die Umsetzung und
berwachung von Revisionsaufgaben werden idealerweise von zentralen Stabsstellen umgesetzt.
hnliches gilt auch fr den Einsatz von Compliance-Tools. SAP GRC Access Control ist eines
der Tools, das Unternehmen ganzheitlich in der Sicherstellung von IT-Compliance im Access
Management untersttzt. Da es wesentliche Abweichungen in den unterschiedlichen Releases
des GRC-Tools gibt, beziehen wir uns hier auf die aktuellen SAP GRC Access Control 10.X-Funktionen. Die Annahme zur Beschreibung von Prfungshandlungen fr SAP GRC ist die Nutzung
als Standalone-Lsung, bspw. ohne die Integration von IDM-Systemen.
9.1. ACCESS-MANAGEMENT-PROZESSE
Um ein einheitliches Verstndnis ber IT-Prozesse zu erhalten, die durch den Einsatz von SAP GRC
Access Control 10.X untersttzt werden, soll dies mit der Hilfe folgender Darstellung beschrieben
werden.
UAR
SoDR
R
E
V
I
E
W
BRM
ARA
UAM
EAM
RRec
UAR
SoDR
Role Rec
Benutzerverwaltung (UAM)
Rollenverwaltung (BRM)
Notfallbenutzerprozesse (EAM)
WF-Untersttzung
SoD Compliance
Genehmigungspflicht
Revisionshistorie
RReaf
Rep
Abbildung 1: Access-Management-Prozesse
Im Kontext des IT-Audits hat die Einfhrung von SAP GRC oder hnlichen Tools Auswirkung auf
die Benutzerverwaltung, die Rollenverwaltung und die Notfallbenutzerprozesse (Primrprozesse).
Diese knnen vollstndig ber das GRC-Tool untersttzt werden. Darber hinaus knnen diese
durch Reviewprozesse (Sekundrprozesse) untersttzt werden und gewhrleisten somit ein
Continuous Control im Access-Management. Diese Sekundrprozesse substituieren weniger,
sondern kompensieren primr die Compliance-Prozesse und sollten bei der Gesamtbeurteilung
des IKS bercksichtigt werden. Durch den vollstndigen Einsatz und der adquaten Ausprgung
der Funktionen knnen die Prozesse durch die Workflow-Untersttzung, die SoD Compliance,
die Genehmigungspflichten und Revisionshistorien wesentlich zur IKS-Optimierung beisteuern.
Relevante Komponenten/Funktionen des SAP GRC Access Control 10.X:
User Access Management (UAM)
Business Role Management (BRM)
Emergency Access Management (EAM)
Access Risk Analysis (ARA)
User Access Review (UAR)
SoD Review (SoDR)
Role Recertification (RRec)
Role Reaffirm (RReaf)
Access Risk Reporting (Rep)
9.2. ANPASSUNG VON PRFUNGSHANDLUNGEN BEIM EINSATZ

VON SAP GRC ACCESS CONTROL 10.X
Der Einsatz von GRC-Tools bringt nicht nur Vorteile fr die betroffenen Unternehmen, sondern
erfordert auch ein Umdenken fr die Prfungseinheiten wie externe oder interne Auditoren.
Folgende Aspekte sollen mgliche Eingriffsfelder beim Einsatz der Tools aufzeigen und eine
erste Abwgung fr Auditoren erlauben, in welchem Kontext eine Anpassung der Prfungshandlungen erfolgen muss.
Einflussfelder im Access Management und Auswirkungen auf Prfungshandlungen:

Konsolidierung/Zentralisierung von Kontrollaktivitten

Automatisierung von kritischen Genehmigungs-Workflows

Automatische Ermittlung von adquaten Genehmigern

Prventive Vermeidung von kritischen Zugriffen (Risikoanalyse)

Zentrale Verwaltung von kritischen IT-Prozessen/Stammdaten

Sicherstellung einer lckenlosen Dokumentation (Logs/Pflichtfelder)
123
124
ANFORDERUNG FR PRFUNGSHANDLUNGEN
EINFLUSSFELDER
SAP-GRC-FUNKTIONEN
Konsolidierung/
Zentralisierung von
Kontrollaktivitten
Durch die Einfhrung von

SAP-GRC-Funktionen werden
dezentrale Prozesse wie die
Benutzerprovisionierung
zentralisiert. Hierdurch werden
Kontrollaktivitten effizienter.
Die dezentrale berprfung von

Access-Management-Prozessen
muss wesentlich infrage gestellt
werden, sofern die relevanten
Prozesse zentral gesteuert werden.
Neben Akzeptanzproblemen durch
die geprfte Organisation erzeugt
dies auch eine Ineffizienz in der
Prfungsdurchfhrung. Entscheidend
ist die Identifizierung von Prozessen/
Systemen im Scope, die durch das
zentrale Tool gesteuert werden, und
der Ausschluss der Umgehung dieser
zentralen Prozesse.
Automatisierung
von kritischen
Genehmigungs-WF
SAP GRC ermglicht es fr das

Access Management, Genehmigungs-Workflows zu hinterlegen, sodass o.g. Effizienz in der
Kontrolldurchfhrung realisiert
werden kann. Workflows
knnen dabei in Abhngigkeit
diverser Faktoren wie der SystemID und/oder des Geschftsprozesses variiert werden. Die
Realisierung erfolgt mit Hilfe
der integrierten Komponenten
MSMP und/oder BRF+.
Der Auditor sollte hnlich wie bei

manuell durchgefhrten Prozessen
das Design der Umsetzung auf
Angemessenheit berprfen. Sofern
dieser automatisierte Prozess fr die
Prozesse im Scope nicht umgangen
werden kann, ist eine eingeschrnkte
Funktionsprfung ausreichend.
Automatische
Ermittlung von
adquaten
Genehmigern
In Kombination mit den

Workflow-Komponenten MSMP
und BRF+ knnen AccessManagement-Prozesse soweit
automatisiert werden, dass
selbst die Genehmiger systemseitig ermittelt werden knnen.
Dies erfolgt bspw. ber die
Einbindung von Entscheidungstabellen.
Der Einsatz von Entscheidungstabellen zur systemseitigen Ermittlung von

adquaten Genehmigern ermglicht
es auch dem Prfer durch wenige
Checks, die Angemessenheit der hinterlegten Logik zu verstehen und zu
validieren. Hierbei gibt es technische
Voraussetzungen, die gegeben sein
mssen, die berprft werden sollten. Dabei handelt es sich u.a. um die
gepflegten Access Control Owner im
System (potenzielle Genehmiger) als
auch um Eskalationspfade (Escape
Conditions).
ANFORDERUNG FR PRFUNGSHANDLUNGEN
EINFLUSSFELDER
SAP-GRC-FUNKTIONEN
Prventive
Vermeidung von
kritischen Zugriffen
(Risikoanalyse)
Die Basis fr das SoDManagement und smtlicher

Compliance-Funktionen ist
das hinterlegte SoD-Regelwerk.
Sofern ein technisches Regelwerk systemisch hinterlegt
ist, kann diese Risikoanalyse
ad hoc/detektivisch oder auch
integriert/prventiv verwendet
werden.
Sofern die Risikoanalyse per Design

in die Access-Management-Prozesse
integriert ist, knnen Effizienzen auch
fr die Prfungshandlungen genutzt
werden. Neben der Vollstndigkeit
und Richtigkeit des Regelwerks ist
die Verprobungsart (wie z.B. gewhltes Regelwerk und Risikoart) per
Event und Prozess zu prfen. Eingeschrnkte Ausprgungsmglichkeiten des Tools sind zu beachten.
Zentrale
Verwaltung von
kritischen ITProzessen/Stammdaten
SAP-GRC-Komponenten
ermglichen und erfordern
eine zentrale Pflege von
Stammdaten, die Einfluss
auf die umgesetzten AccessManagement-Prozesse haben.
Hierbei geht es sowohl um die
Bereitstellung von Funktionen
(EAM-Administration) als auch
um die Aussteuerung dieser
(Workflowkonfiguration). Bei
SAP GRC ist zu beachten,
dass Einstellungen sowohl im
Netweaver Business Client als
auch im SAP Customizing (IMG)
umgesetzt werden. Whrend
das Customizing transportierbar ist, mssen Stammdaten
im NWBC pro System gepflegt
werden.
Aufgrund der integrierten NetWeaverTechnologie sollte der Auditor die

Zusammenhnge zwischen dem
GRC-Backend-Customizing und
der Stammdatenpflege im NWBC
kennen. Dies ist nicht nur fr die
Bewertung des Prozess-Designs
erforderlich, sondern auch um das
Change Management der Applikation berprfen zu knnen.
Insbesondere die Berechtigungseinschrnkung in der produktiven
GRC-Umgebung ist kritisch zu
hinterfragen aufgrund der weitreichenden Auswirkung von dolosen
Handlungen auf einem zentralen
System.
Sicherstellung
einer lckenlosen
Dokumentation
Smtliche nderungen an
Stammdaten in der NWBCUmgebung knnen systemseitig und revisionssicher protokolliert werden. Zudem knnen
teilweise auch Applikationskontrollen in Form von Pflichtfeldern hinterlegt werden, um
die Vollstndigkeit der Dokumentation zu untersttzen.
Die Protokollierfunktion von SAP GRC

kann stark variiert sein und muss
explizit aktiviert werden, hnlich wie
es auch bei ERP-Systemen der Fall
ist. Ob und welche Applikationskontrollen fr die Untersttzung der
Revisionssicherheit genutzt werden,
muss ber Prfungshandlungen
verifiziert werden. Die meisten Protokollierfunktionen werden zentral
verwaltet und knnen schnell auditiert werden.
125
126
9.3. NEUE ANFORDERUNGEN AN DIE IT-PRFUNG

9.3.1. VERLAGERUNG DER RISIKEN IM ACCESS MANAGEMENT
Aufgrund des direkten Einflusses der GRC-Komponenten auf rechnungslegungsrelevanten
ITGC-Prozessen, hier: Access-Management-Prozesse, hat die Einfhrung und der Betrieb
eines SAP GRC Access Control (oder hnliche Compliance Tools) eine wesentliche Bedeutung
auf die Prfungsplanung. Insbesondere bei Mittelstndischen wie auch Grounternehmen
bedeutet dies ebenfalls eine Zentralisierung der Prfungshandlungen.
Bspw. wird der Benutzerantragsprozess oder der Rollenpflegeprozess je nach Design der
technischen Realisierung nicht mehr dezentral pro Zielsystem auditiert, sondern zentral
ber das GRC-System. Damit kann sich das Prferteam auf wesentliche Prozessrisiken
fokussieren und profitiert durch die Modernisierung in der IT.
hnlich ist dies auch bei anderen zentralen Instanzen wie dem SolMan hinsichtlich der
Umsetzung des Change Management.
Fr die geprfte Organisation wiederum bedeutet dies, dass Effizienz und dadurch Entlastungen
durch das Audit gewhrleistet wird bzw. gefordert werden kann. Voraussetzung ist in jedem Fall
der Scope der GRC-untersttzten Prozesse und die zentrale (wirksame) Abnahme der Prozesse
und Inhalte.
9.3.2. NEUE RISIKEN IM ACCESS MANAGEMENT

Durch den Einsatz von SAP GRC werden zum einen die Access-Management-Prozesse verlagert,
zum anderen entstehen neue IT-Risiken, die in den Scope des Auditors aufgenommen werden
mssen. Hierbei handelt es sich um die Compliance des GRC-Systems selbst. Whrend die
Zentralisierung der kritischen IT-Prozesse aus Sicht der Anwendung einen Mehrwert schafft,
steigt durch den Single-Point-of-Failure auch das Risikoausma (Business Impact) fr den
GRC-Betrieb.
Unternehmen sind dabei in der Nachweispflicht, fr das SAP GRC als IKS-relevantes System die
Einhaltung der ITGC-Anforderungen zu besttigen. Hierbei handelt es sich u.a. um die Angemessenheit des GRC-Berechtigungskonzeptes hinsichtlich der Einschrnkung von kritischen Zugriffsrechten sowie Trennung von kritischen Funktionen (SoD) und auch um die Angemessenheit des
GRC-Prozessdesigns (z.B. die Provisionierung des GRC-Systems, Administration der Workflows,
Change Management hinsichtlich der Stammdaten).
9.3.3. RISIKOARTEN BEIM EINSATZ VON SAP GRC

Folgende Risikofelder und Prffragen knnen fr ein erstes Scoping in der IT-Prfung
beim Einsatz von SAP GRC verwendet werden:
1. Prozessdesign (Workflow, BRF+/MSMP, Owner)

Welche Access-Management-Prozesse sind im Scope?

Wie ist das Prozessdesign der IKS-relevanten Prozesse?

Welche Zielsysteme (PlugIn-Systeme) sind im Scope, mit welchen Prozessvarianten?

Welche Ausnahmeprozesse gibt es? (Escape Conditions/Escalation Paths)
2. Kritische Zugriffrechte > Berechtigungen

Gibt es eine Risikoeinschtzung hinsichtlich kritischer GRC-Prozesse/-Funktionen?

Wie werden kritische Berechtigungen identifiziert? Gibt es ein GRC-Regelwerk?

In welchen GRC-Prozessen wird das Regelwerk prventiv und integriert verwendet?

GRC-Stammdaten (NWBC)

Wie sieht das Rollenkonzept fr die Stammdatenpflege im GRC aus?

Wie wird die Trennung hinsichtlich der Datenpflege zwischen den organisatorischen
Einheiten sichergestellt?

Wie erfolgt der Change-Prozess zu den Stammdaten?
4. GRC-Konfiguration (SPRO/MSMP/BRF+)

Wie sieht das Rollenkonzept fr die Konfiguration im GRC aus?

Wie wird die Trennung hinsichtlich der Pflege zwischen den organisatorischen Einheiten
sichergestellt?

Wie erfolgt der Change-Prozess zum Customizing? Welche Transportwege sind erlaubt?
5. Kritische Profile/Rollen (Objektebene)

Welche kritischen Standard- und kundeneigenen Profile/Rollen sind identifiziert?

Wie wird das Monitoring hierzu in die Access-Management-Prozesse eingebunden?

Wie wird der Einsatz dieser kritischen Rechte vermieden und/oder berwacht?
6. Kritische Parameter (globale Konfigurationseinstellungen)

Sind die globalen Einstellungen angemessen gesetzt?

Wie ist der Change Prozess zu den kritischen Parametern?
127
128
9.4. PRFPROGRAMM BEIM EINSATZ VON SAP GRC ACCESS CONTROL

Fr den Aufbau des Prfprogramms wurde ein risikoorientierter Prfungsansatz gewhlt, um
ein umfassendes und effizientes Vorgehen in der Auditierung zu gewhrleisten. Orientiert an
den GRC-Komponenten, werden die Risiken der dadurch abgedeckten (Teil-)Prozesse analysiert
(Design Effectiveness). Fr die Wirksamkeitsanalyse werden kritische Parameter wie auch
kritische Zugriffe, die wesentliche Auswirkungen auf die Prozesse haben, detailliert betrachtet
(Operating Effectiveness). Somit ist eine komplette Risikoprfung im Sinne des IKS auf
Applikationsebene mglich.
1.1
GRC
Komponente
Emergency
Access
Management
Risikoart
User Access
Management
2
Business Role
Management
3
Access Risk
Analysis
1.2
1.3
Prozess
Design
Kritische
Parameter
Kritische
Zugriffe
Teilprozess
1
Parameter
Gruppe 1
Stammdaten
Teilprozess
2
Parameter
Gruppe 2
Customizing
Teilprozess
3
Parameter
Gruppe N
Kritische
Profile
Teilbereich
Orientiert an den GRC-Komponenten, werden die Risiken

der dadurch abgedeckten (Teil-)Prozesse analysiert
(Design Effectiveness). Fr die Wirksamkeitsanalyse
werden kritische Parameter wie auch kritische Zugriffe,
die wesentliche Auswirkungen auf die Prozesse haben,
detailliert betrachtet (Operating Effectiveness). Somit
ist eine komplette Risikoprfung im Sinne des IKS auf
Applikationsebene mglich.
4
Abbildung 2: Aufbau des GRC-Prfprogramms - risikoorientierter Prfungsansatz
9.4.1. PRFUNG DES EMERGENCY ACCESS MANAGEMENT

9.4.1.1. Prozess Design Emergency Access Management
Der Einsatz von Notfallbenutzern dient zur speziellen Aufgabenerfllung aufgrund besonderer
Ereignisse, die zwingend und unaufschiebbar in transaktionellen SAP-Systemen durchzufhren
sind. Um zu vermeiden, dass hierbei Manahmen durchgefhrt werden, die weder nachvollziehbar, noch unbegrndet sind, kommt in diesen Fllen das EAM von SAP GRC Access Control
10.X zum Einsatz. Es ermglicht die zentrale Administration von ausnahmebasierten Zugngen
durch die Verwendung von Firefighter-IDs (Benutzer vom Typ Service), die von mehreren Benutzern nicht parallel verwendet oder von Firefighter-Rollen, die diversen Benutzern temporr
zugeordnet werden knnen.
Die komplette Administration dieser zeitlich begrenzten Vergabe kritischer Rechte erfolgt auf der
GRC-Plattform. Wesentlich ist der integrierte Workflow zur Protokollierung und Revision der durch
die Nutzer vorgenommenen Handlungen unter Verwendung der kritischen Berechtigungen. EAM
erfllt die Anforderungen an eine revisionssichere Nachweispflicht zur Verfolgung von privilegierten
Zugriffen fr transaktionale SAP-Systeme.
Aus der Verwendung der Komponente und der temporren Zuweisung kritischer Rechte an
Benutzer ergeben sich dringende Prfungshandlungen, die in dem Prfprogramm bercksichtigt
wurden.
NR.
PRFUNGSHANDLUNGEN FR EIN COMPLIANT EMERGENCY ACCESS MANAGEMENT
1.
Anwendungsbereich des Notfallbenutzerkonzepts mit EAM

Kontrollziel: Das EAM-Szenario deckt alle kritischen Systeme ab und untersttzt den
Schutz systemspezifischer Daten.
Risiko: Es sind nicht alle kritischen Systeme und Daten durch angemessene Kontrollen
gesichert.
1.1.
Gibt es einen berblick ber alle an das GRC-System angebundenen Zielsysteme

(PlugIn-Systeme), fr die EAM angewendet wird?
Check: Transaktion SM59, alle an den produktiven GRC-Mandanten angebundenen
PlugIn-Systeme und ergnzend folgenden Konfigurationspfad.
SPRO > GRC > Gemeinsame Komponenteneinstellungen > Integration Framework >
Verbindungseinstellungen bearbeiten. Prfen Sie das Integration Scenario SUPMG
(Super User Privilege Management), welche Konnektoren hier zugeordnet sind.
Hinweis: Fr die vollstndige Konfiguration von EAM auf spezifizierte Konnektoren sind
weitere Einstellungen erforderlich, allerdings geben o.g. Checks bereits erste Hinweise
darauf, ob ein Zielsystem EAM-relevant ist oder nicht. Auch fr den dezentralen Einsatz
von EAM mssen Konnektoren vorhanden sein.
129
130
NR.
2.
Definition von kritischen Berechtigungen zur Aufnahme in ein dediziertes Notfallbenutzerkonzept

Kontrollziel: Manahmen zur Identifizierung und Beschreibung von kritischen
Berechtigungen sind vorhanden.
Risiko: Kritische Zugriffe werden nicht oder nur unvollstndig durch die EAMFunktionen abgedeckt. Risikobehaftete Zugriffe sind nicht nachvollziehbar und
zuordenbar, gefhrden somit die Integritt der Systemdaten.
2.1.
Sind Verfahrensanweisungen vorhanden, um kritische Berechtigungen aufzudecken

(Risikoanalyse/Regelwerk)? Sind kritische Berechtigungen aus dem Standard in den
Notfallbenutzerprozess mit EAM eingebunden? Gibt es Prozesse zur Neuaufnahme
von neuen FFIDs und die Nominierung von adquaten Eignern (Owner/Controller)?
Hinweis: Es wird empfohlen neben den Firefighter-Szenarien wenige Superuser
weiterhin auf konventionellem Wege beizubehalten, um eine totale Abhngigkeit von
GRC (GRC Shutdown) zu vermeiden. Die Notfallbenutzer sollten synchron mit dem
bergreifenden Disaster-Recovery-Konzept sein.
3.
Einrichtung/nderung von neuen/existierenden Notfallbenutzern (FFIDs )

Kontrollziel: Bei der Anlage von technischen Benutzern, hier FFIDs, und deren
Eignern (hier Owner/Controller) werden Benutzerantragsverfahren verwendet,
die angemessen sind.
Risiko: Unangemessene Anlage und Zuordnung von Notfallbenutzern.
3.1.
Wie werden technische Benutzer, insbesondere FFIDs auf den PlugIn-Systemen

angelegt? Wird die Einrichtung der FFIDs adquat genehmigt? Ist der Benutzerkreis
fr die Beantragung von FFIDs entsprechend der Kritikalitt eingeschrnkt?
Wie erfolgt die Nominierung und Benutzeranlage der FF-Owner?
Fr die Prfung der Benutzer durch GRC selbst bitte Prfungshandlungen
aus 9.4.2.1 UAM beachten.
Gibt es einen Prozess zur regelmigen berprfung der Angemessenheit aller
Notfallbenutzer?
4.
Genehmigung der Notfallbenutzer-Zuordnung

Kontrollziel: Die Benennung von FF-Ownern erfolgt nachvollziehbar und zusammenhngend zu dem Risiko, das sich hinter dem Zugriff verbirgt. Es ist sichergestellt, dass
Firefighter nicht ihre eigene Zuordnung genehmigen.
Risiko: Inadquate Genehmigung des Notfallbenutzerzugriffs kann zu unsachgemem
Einsatz dieser fhren.
4.1.
Welche Verantwortlichen werden in den Nominierungsprozess mit eingebunden?

Gibt es eine Plausibilitt hinter der Genehmigerermittlung?
Fr die berprfung der systemseitigen Funktionstrennung im EAM-Prozess siehe
Konfigurationseinstellungen 4013 und 4014.
Stimmen die FF-Owner im GRC-NWBC mit den freigegebenen (dokumentierten)
Genehmigern berein?
Check: NWBC-Einrichtung > Notfallzugriffszuordnung > Verantwortliche (Owners) und
Notfallzugriffsbearbeitung > Kontrolleure
NR.
4.2.
Wie ist sichergestellt, dass der FF-Owner in den Beantragungsprozess eingebunden

ist? Wird der Genehmigungsworkflow zur Beantragung/Zuordnung von FFIDs in UAM
eingesetzt?
Check: SPRO > GRC > Access Control > Workflow fr Access Control > MSMP Workflows
bearbeiten > ProzessID: SAP_GRAC_ACCESS_REQUEST, Schritt 2 suche nach GRAC_MSMP_
SPM_OWNER_AGENT, Schritt 5 suche nach Firefighter Pfad und berprfe Genehmigerstufen und Genehmiger (Bearbeiter-ID) aus.
Prfen Sie ber NWBC > Zugriffsverwaltung > Zugriffsanforderungsverwaltung >
Anforderungen suchen, die genehmigten EAM-Antrge und validieren die
Angemessenheit der Genehmiger
4.3.
Wie ist der Prozess fr den dezentralen EAM-Ansatz gelst?

Hinweis: Es knnen beide Anstze parallel im Einsatz sein. Die Verwendung ist
abhngig von der Anwendbarkeit im Unternehmen. Zu berprfen ist, ob auf den
dezentralen Systemen die PlugIn-Einstellungen gesetzt sind und entsprechende
Berechtigungen fr FF-Endbenutzer (auf dem Zielsystem) vorhanden sind.
Check: SPRO > GRC PlugIn > Access Control > PlugIn-Konfigurationeinstellungen bearbeiten,
validieren Sie Parameter: 1089, 1090, 4000, 4001, 4008, 4010 auf Angemessenheit
Check: SPRO > GRC PlugIn > Access Control > User-Exits fr PlugIn-Systeme bearbeiten,
validieren Sie den Parameter SAP_EXIT_USERS_SAVE auf Richtigkeit
5.
Review der Firefighter-Logs

Kontrollziel: Der FF-Einsatz ist so konfiguriert, dass Kontrolleure zeitnah ber die
Verwendung informiert werden. Es ist sichergestellt, dass Firefighter nicht ihren
eigenen Zugriff besttigen.
Risiko: Eine unvollstndige oder verzgerte Prfung der FF-Logs kann dazu fhren,
dass dolose Handlungen nicht oder nur versptet aufgedeckt werden.
5.1.
EAM kann systemseitig so konfiguriert werden, dass die Kontrolleure ad hoc beim FFEinsatz per E-Mail informiert werden und zeitnah das Log zum Review erhalten. Hierfr
sind Parameter in den Konfigurationseinstellungen adquat zu setzen. Ebenfalls wird
die Funktionstrennung im EAM-Prozess systemseitig untersttzt. Siehe Konfigurationseinstellungen in Kapitel 2.4.1.2.
Hinweis: Der Versand der Logfiles zur Review durch den Kontrolleur erfolgt in
Abhngigkeit der Taktung des Batchjobs GRAC_SPM_LOG_SYNC_UPDATE. Dieser
sollte 1h nicht bersteigen.
Hinweis: Der Versand von E-Mails ist von weiteren basisrelevanten Einstellungen
abhngig, insbesondere von der SCOT-Verwaltung. Diese sollten ebenfalls beachtet
werden, sind aber unabhngig vom Workflow im GRC zu sehen.
131
132
9.4.1.2. Sicherheitskritische Parameter fr das Emergency Access Management

Die globalen Konfigurationseinstellungen sind mandantenabhngig und haben in Abhngigkeit von
der GRC-Architektur eine kritische Auswirkung auf das Design der technischen GRC-Prozesse.
Diese knnen unter folgendem Pfad validiert werden.
Check: SPRO GRC Access Control Konfigurationseinstellungen
Im Folgenden finden Sie die wesentlichen Konfigurations-Parameter fr das Emergency
Access Management. Neben dem vorkonfigurierten Standardwert wird auch eine BestPractice-Empfehlung gegeben. Selbstverstndlich ist letztere kundenindividuell zu validieren.
PARAMETER-ID
BESCHREIBUNG
1113
Access Control
E-Mail-Absender
4000
Anwendungsart
4001
StandardFirefighterGltigkeitszeitraum
(Tage)
STANDARDWERT
BESTPRACTICEEMPFEHLUNG
KOMMENTAR
WF-BATCH
kundenspezifisch
auszuprgen
Dieser technische
Benutzer verwaltet die
GRC-Workflows und
muss entsprechend
ausreichende Berechtigungen haben.
Der Wert 1 bedeutet,

dass das ID-basierte
Firefighting im Einsatz
ist. Es knnen nicht
beide Varianten parallel
im Einsatz sein. In
Abhngigkeit der Applikationsart entstehen
neue Anforderungen an
die EAM-Prozesse.
blank
Anzahl der Tage fr

die Gltigkeit der FFZuordnung.
Hinweis: Diese Standardeinstellung kann
im FF-Antrag (via UAM)
durch den Antragsteller
oder bei der manuellen
Zuordnung durch den
EAM-Administrator
angepasst werden.
PARAMETER-ID
BESCHREIBUNG
STANDARDWERT
KOMMENTAR
4002
E-Mail sofort
senden
JA
JA
Ad hoc Benachrichtigung
des FF-Kontrolleurs,
dass betroffene FFID im
Einsatz ist.
4003
nderungsprotokoll abrufen
JA
JA
Aktivierung der Abfrage

des Change Logs aus
dem PlugIn-System
4004
Systemprotokoll
abrufen
JA
JA

des System Logs aus
dem PlugIn-System
4005
Revisionsprotokoll
abrufen
JA
JA

des Audit Logs aus dem
PlugIn-System
4006
BS-Befehlsprotokoll abrufen
JA
JA

des O/S Command Log
aus dem PlugIn-System
4007
Benachrichtigung
fr Protokollberichtausfhrung
sofort senden
JA
JA
Sofortige Benachrichtigung des FF-Kontrolleurs zum Review des

Log Files
Hinweis: Fhrend ist
hier die Taktung des
Jobs GRAC_SPM_LOG_
SYNC_UPDATE.
4008
FirefighterBenutzeranmeldebenachrichtigung
senden
JA
JA
Ad hoc Benachrichtigung
des FF-Kontrolleurs,
dass betroffene FFID im
Einsatz ist.
4009
ProtokollberichtausfhrungsBenachrichtigung
JA
JA
Sofortige Benachrichtigung des FF-Kontrolleurs zum Review des

Log Files
Hinweis: Fhrend ist
hier die Taktung des
Jobs GRAC_SPM_LOG_
SYNC_UPDATE.
133
134
PARAMETER-ID
BESCHREIBUNG
STANDARDWERT
SAP_
GRAC_
SMP_FFID
kundenspezifisch
auszuprgen
Die hier definierte Rolle

muss der technischen
Rolle entsprechen, die
auf den PlugIn-Systemen
den FFIDs zugeordnet
wird.
Aufgrund der Sensibilitt der Daten wird
empfohlen, dass das
Log File nur innerhalb
einer eingeschrnkten
Gruppe weitergeleitet
werden kann. Hier bietet
sich die Gruppe der FFKontrolleure an. Die
Weiterleitung kann auch
ausgeschlossen werden.
KOMMENTAR
4010
Firefighter-IDRollenname
4012
Standardbenutzer
fr das Weiterleiten
des Revisionsprotokoll-Workflows
4013
Firefighter-ID-Verantwortlicher kann
Anforderung fr
seine FirefighterID senden
JA
NO
Sicherstellung, dass
eine Funktionstrennung im EAMProzess gewhrleistet
ist.
4014
Firefighter-ID-Verantwortlicher kann
Anforderung fr
kontrollierte Firefighter-ID senden
JA
NO
Sicherstellung, dass
eine Funktionstrennung im EAMProzess gewhrleistet
ist.
4015
Dezentrales Firefighting aktivieren
NO
kundenspezifisch
auszuprgen
Aufgrund der Nutzbarkeit des Access Request

Workflows fr die
genehmigungspflichtige
FFID-Zuordnung wird
das zentrale Firefighting
empfohlen.
Allerdings ist auch der
dezentrale Ansatz zulssig, sofern sichergestellt
ist, dass die Genehmigung und Zuordnung
der FFIDs angemessen
ausgeprgt ist.
9.4.1.3. Kritische Berechtigungen und Funktionstrennung im Emergency Access Management

Die Berechtigungen zur Steuerung der Komponente und deren wesentlicher Funktionen erfolgen ber
eine berschaubare Anzahl von Berechtigungsobjekten und Feldwerten. Die hierin als
kritisch und prfungsrelevant zu .betrachtenden Bereiche werden im Folgenden beschrieben.
Der Bezug zu den in 2.4.1.1 genannten Risiken wird hergestellt.
BERECHTIGUNGSOBJEKT
GRAC_
ASIGN
GRAC_
FFOBJ
FELDWERT
BESCHREIBUNG
MAPPING ZU RISIKO
ACTVT - 01
ACTVT - 02
ACTVT - 06
ACTVT - 70
GRAC_OWN_T FFCR
GRAC_OWN_T FFCU
GRAC_OWN_T FFID
GRAC_OWN_T FFRO
Im NWBC knnen mit der

Funktion Access Control Verantwortliche Mitarbeiter fr
die Ausfhrung von Genehmigungsstufen und Kontrollen
im EAM-Umfeld ernannt
werden. Diese Ernennung ist
verpflichtend, um Mitarbeiter
zu Firefighter-Ownern oder
Firefighter-Kontrolleuren zu
definieren und hierzu konkreten FFIDs zuzuordnen.
Das Berechtigungsobjekt
GRAC_ASIGN steuert aus, zu
welchen Funktionen Mitarbeiter ernannt werden knnen
(bspw. Firefighter-Owner via
GRAC_OWN_T - FFID oder
Firefighter-Kontrolleur via
GRAC_OWN_T - FFCU).
Nr. 2:
Gibt es Prozesse zur
Neuaufnahme von neuen
FFIDs und die Nominierung von adquaten Eignern (Owner/Controller)?"
ACTVT - 01
ACTVT - 02
ACTVT - 06
Das Objekt erlaubt die manuelle Zuordnung von Firefighter-IDs zu Endanwendern,

sofern der Workflow fr die
Beantragung von FFID-Zuordnungen durch die manuelle
Administration ergnzt/untersttzt werden soll.
Nr. 4:
Welche Verantwortlichen
werden in den Nominierungsprozess mit eingebunden? Gibt es eine Plausibilitt hinter der Genehmigerermittlung?
berprfung, welcher
Mitarbeiter ber die
Rechte zur Ernennung
von FF-Ownern und
FF-Kontrolleuren verfgt,
bspw. ber die Transaktion SUIM oder via
GRC-Regelwerk.
Erfolgt die Zuordnung ohne

Workflow, ist zu prfen,
welche Mitarbeiter ber die
Berechtigungen verfgen.
Ein workflowuntersttzter
Vergabeprozess ist klar zu
prferieren.
135
136
BERECHTIGUNGSOBJEKT
GRAC_
FFOWN
FELDWERT
ACTVT - 01
ACTVT - 02
ACTVT - 06
ACTVT - 70
BESCHREIBUNG
Das Objekt erlaubt
die Zuordnung
Verantwortlicher zu
Firefighter-IDs.
MAPPING ZU RISIKO
Nr. 4:
Welche Verantwortlichen werden
in den Nominierungsprozess
mit eingebunden? Gibt es eine
Plausibilitt hinter der Genehmigerermittlung?
Risiko EAM_03: Wie erfolgt die
Nominierung und Benutzeranlage
der FF-Owner?
Nach der Ernennung von Mitarbeitern zu Firefighter-Verantwortlichen erfolgt die konkrete
Zuordnung derer zu Firefighter-IDs mit dieser Berechtigung.
Nur eine stark eingeschrnkte
Gruppe von Mitarbeitern darf ber
das Recht der FFID-Owner-Zuordnung verfgen, um die inadquate
Ernennung von Firefighter-Verantwortlichen zu verhindern.
Prfung, welcher Mitarbeiter ber
die Rechte zur Zuordnung von
FF-Ownern verfgt.
GRAC_
OWNER
ACTVT - 01
ACTVT - 02
ACTVT - 06
ACTVT - 70
ACTVT - 78
Das Objekt erlaubt

die Zuordnung von
Kontrolleuren zu
Firefighter-IDs.
Nr. 4:
Welche Verantwortlichen werden
in den Nominierungsprozess
miteingebunden? Gibt es eine
Plausibilitt hinter der Genehmigerermittlung?
Nach der Ernennung von Mitarbeitern zu Firefighter-Kontrolleuren
erfolgt die konkrete Zuordnung
derer zu Firefighter-IDs mit
dieser Berechtigung. Nur eine
stark eingeschrnkte Gruppe von
Mitarbeitern darf ber das Recht
der FFID-Kontrolleur-Zuordnung
verfgen, um die inadquate
Ernennung von FirefighterKontrolleuren zu verhindern.
Prfung, welcher Mitarbeiter ber
die Rechte zur Zuordnung von
FF-Ownern verfgt.
BERECHTIGUNGSOBJEKT
S_TCODE
FELDWERT
S_TCODE
GRAC_SPM
BESCHREIBUNG
MAPPING ZU RISIKO
Die Berechtigung
erlaubt den Zugriff auf
die Firefighter-Startseite. Von hieraus
erfolgt der Absprung
mittels FFIDs auf die
angebundenen Systeme (zentralisiertes
Firefighting), sofern
der Zugriff auf die
FFID genehmigt wurde
(workflowgesteuerter
Prozess) oder die
FFID dem Benutzer
zugeordnet wurde
(manueller Prozess).
Nr. 3:
Ist der Benutzerkreis fr die
Beantragung von FFIDs entsprechend der Kritikalitt
eingeschrnkt?
Es ist eine Erhebung darber
vorzunehmen, welche Mitarbeiter
den Zugriff auf die Startseite des
Firefighter-Absprungs erhalten
haben (zentralisiertes Firefighting). Da in EAM kritische Berechtigungen vergeben werden, ist
eine beschrnkte Zuordnung des
Zugriffs sicherzustellen.
Hinweis: Allein die Berechtigung
fr die Transaktion GRAC_SPM
erlaubt noch nicht den Absprung
via Firefighter-ID, fungiert jedoch
als Indiz fr den Charakter der
Firefighter-ID-Vergabe im Unternehmen. Erhlt ein groer Anteil
der Mitarbeiter das Recht fr die
Transaktion GRAC_SPM, sind die
EAM-Prozesse im Unternehmen
zu hinterfragen.
137
138
9.4.2. PRFUNG DES USER ACCESS MANAGEMENT

9.4.2.1. Prozess Design User Access Management
Das User Access Management stellt in SAP GRC die zentrale Komponente zur Abbildung von
Antragsprozessen dar. Genauer ermglichen Bestandteile und Funktionen von User Access
Management, Genehmigungsprozesse zu automatisieren. Die Workflows knnen bergreifend
auch von den anderen GRC-Komponenten verwendet werden. Der Fokus hier liegt aber auf der
Prfung des Benutzerantragsprozesses.
NR.
PRFUNGSHANDLUNGEN FR EIN COMPLIANT USER ACCESS MANAGEMENT
6.
Beantragungsprozess
Kontrollziel: Der Zugang auf kritische Systeme oder die Auswahl der Berechtigungen
ist eingeschrnkt auf geeignetes Personal. Alternativ ist jede zu beantragende
Berechtigung systemseitig genehmigungspflichtig, um unberechtigten Zugriff zu
vermeiden.
Risiko: Unberechtigtes Personal erhlt Zugang auf kritischen Systemen, mglicherweise ber die automatische Zuordnung von Standardrollen.
6.1.
Gibt es Prozessbeschreibungen zum Berechtigungsvergabeprozess mittels SAP GRC?

Welche Zielsysteme sind als Konnektoren fr die Provisionierung definiert?
Check: SPRO > GRC > Gemeinsame Komponenteneinstellungen > Integration Framework >
Verbindungseinstellungen bearbeiten. berprfen Sie, welche Zielsysteme (Target Connector)
fr das Integration Scenario Provisioning PROV hinterlegt sind.
Hinweis: Fr die vollstndige Konfiguration von UAM auf spezifizierte Konnektoren
sind weitere Einstellungen erforderlich, allerdings gibt o.g. Check bereits einen ersten
Hinweis darauf, ob ein Zielsystem UAM relevant ist oder nicht.
6.2.
Welche Mglichkeiten gibt es generell, Benutzer (auch technische) auf der Produktion
anzulegen? Welche Ausnahmen gibt es? Grundstzlich sollten keine Dialog-, sondern
nur noch vom GRC-System verwendete RFC-System-Benutzer evtl. noch Notfallbenutzer diese Berechtigung haben. Ausnahmen sollten dokumentiert und nachvollziehbar sein.
Prfen Sie fr das jeweilige Zielsystem (ggf. auch ber GRC mglich), welche Benutzer die
Berechtigung zur Benutzeranlage haben:
Check: Tcode SUIM > Benutzer > Benutzer nach komplexen Selektionskriterien > Benutzer
nach komplexen Selektionskriterien > S_Tcode = SU01
Hinweis: Weitere Spezifizierung der Abfrage im Falle von vorhandenen Ausnahmen
erforderlich.
NR.
7.
Kontrollziel: Der Zugang auf kritische Systeme oder die Auswahl der Berechtigungen ist
eingeschrnkt auf geeignetes Personal. Alternativ ist jede zu beantragende Berechtigung
systemseitig genehmigungspflichtig, um unberechtigten Zugriff zu vermeiden
Risiko: Unberechtigtes Personal erhlt Zugang auf das GRC-System und kann Rollen
ohne Genehmiger oder fehlerhaft beantragen.
7.1.
Wer darf Rollen fr Zielsysteme via SAP GRC beantragen? Wie ist der Zugang auf das
NWBC-Portal eingeschrnkt? Wird das Portal als Selfservice verwendet?
Check: SPRO > GRC > Access Control > Benutzererstellung > Benutzeranmeldung aktivieren.
berprfen und besprechen Sie mit dem zustndigen Administrator, ob das Selfservice fr
das GRC-Beantragungsportal aktiviert ist.
Die Einschrnkung der Antragssteller (Requester) auf geeignetes Personal reduziert die
fehlerhafte Beantragung von Rollen. Grundstzlich muss die Beantragung jedoch nicht
eingeschrnkt sein, sofern sichergestellt ist, dass jeder Antrag genehmigungspflichtig ist.
Bitte beachten Sie auch die Konfigurationsparameter fr UAM 2033. Alle Rollen fr
Anforderer zulassen. Hier kann die Rollenauswahl zustzlich eingeschrnkt werden.
8.
Berechtigungsvergabeprozess
Kontrollziel: Es ist sichergestellt, dass Benutzer ausschlielich ber ein ordnungsgemes Verfahren bereitgestellt werden. Ausnahmeprozesse sind nachvollziehbar
dokumentiert und unterliegen der Genehmigungspflicht.
Risiko: Der Zugriff auf sensible Daten ist nicht angemessen geschtzt. Die Zuordnung von
Berechtigungen an Benutzer erfolgt nicht kontrolliert und durchgehend nachvollziehbar.
8.1.
Wie ist der Genehmigungsprozess zur Rollenvergabe ber SAP GRC? Validieren Sie
Verfahrensbeschreibungen zum Provisionierungsprozess und berprfen Sie die
entsprechende Umsetzung im System.
Check: SPRO > GRC > Access Control > Workflow fr Access Control > MSMP-Workflows
bearbeiten, prfen Sie die Ausprgung der relevanten Prozess-ID (Standard: SAP_GRAC_
ACCESS_REQUEST). Achten Sie dabei auf folgende Ausprgungen:
- Schritt 1: Betroffene Regel-ID: bildet das Mapping zur zugehrigen Regel BRF+.
- Schritt 5: Pfade bearbeiten: bildet die Genehmigungsstufen und -agenten pro Pfad-ID ab.
- Aufgabeneinstellungen: Generelle Einstellungen wie die obligatorische Risikoanalyse,
Kommentierung oder Eskalation sind pro Pfad hinterlegt.
8.2.
BRF+ beinhaltet die betroffene Entscheidungslogik (Standard: Entscheidungstabelle)

zum jeweiligen Genehmigungspfad. Mglicherweise sind Genehmigungsschritte
mindestens vom Zielsystem abhngig, was man hier dann ablesen kann.
Die jeweilige Pfad-ID sowie die Funktions-ID verbinden die Genehmigungsworkflows
im MSMP und die Regel BRF+.
Check 1: Tcode BRF+, Suche die relevante Applikation und berprfe die Funktions-ID
aus der MSMP Prozess-ID auf bereinstimmung.
Check 2: Validiere die Bedingungslogik (evtl. Entscheidungstabelle) ber Applikation >
Verwendungen > Ausdruck > <Entscheidungstabelle>
Jede Zeile bildet eine Bedingung ab, bspw. wenn System X und Anforderungsart Y,
dann initiiere die Pfad-ID (aus MSMP)
139
140
NR.
9.
Genehmigungsprozess
Kontrollziel: Benutzerantrge werden durch geeignetes Personal angemessen
genehmigt. Die Genehmigungspflicht wird systemseitig sichergestellt (erzwungen).
Ausnahmen sind nachvollziehbar dokumentiert.
Risiko: Der Zugriff auf sensible Daten ist nicht angemessen geschtzt. Die Zuordnung
von Berechtigungen an Benutzer erfolgt nicht kontrolliert und durchgehend nachvollziehbar.
9.1.
Welche Genehmigeragenten sind pro Workflow-Pfad hinterlegt?

bearbeiten. berprfen Sie die vorhandenen Bearbeiter-IDs in Schritt 3 sowie die hinterlegten BearbeiterIDs in Schritt 5 fr den relevanten Pfad
Mgliche Standard-Agenten und ihre Ermittlung:
- GRAC_Manager: Vorgesetzte der Begnstigten, die aus HR-Quelldaten oder durch
manuelle Eingabe im Antrag ermittelt werden
- GRAC_Role Owner: Rolleneigner (Role Assignment Approver) fr die Provisionierung, die
an der Rolle hngen und entsprechend gepflegt werden mssen (via Import Funktion oder
BRM Rollenpflege)
- GRAC_Security/GRAC_POINT_CONTACT: Sicherheitsverantwortlicher oder der Ansprechpartner ist eine Gruppe oder Person, die eine sekundre Genehmigung fr Zugriffsanforderungen und Prfungen erteilen kann. Dieser muss ber die Access-ControlVerantwortung im NWBC gekennzeichnet werden.
9.2.
Bitte beachten Sie auch die Auswegsbedingungen (Escape Path) und den dafr hinterlegten Pfad. Dies ist insbesondere wichtig, falls Genehmiger nicht gefunden werden,
bspw. im Falle von fehlenden Rolleninhabern. Hier sollte keine automatische Provisionierung erfolgen!
bearbeiten, Schritt 1, Auswegsbedingungen
Beachten Sie bitte auch den Konfigurationsparameter 2038 Rollen ohne Genehmigende
automatisch genehmigen. Falls der Parameter auf Ja gesetzt ist, sollte berprft
werden, wie die Ermittlung von Genehmigern, bspw. Rolleneigner, sichergestellt wird.
Siehe auch Prfungshandlung 2.4.3.1 fr BRM.
9.4.2.2. Sicherheitskritische Parameter fr das User Access Management

Im Folgenden finden Sie die wesentlichen Konfigurations-Parameter fr das User Access
Management. Neben dem vorkonfigurierten Standardwert wird auch eine Best-PracticeEmpfehlung gegeben. Selbstverstndlich ist letztere kundenindividuell zu betrachten.
PARAMETER-ID
BESCHREIBUNG
STANDARDWERT
KOMMENTAR
1071
Risikoanalyse fr
Formularabgabe
aktivieren
NO
JA
Der Parameter erzwingt

die Ausfhrung der
Risikoanalyse bei
der Beantragung. So
knnen konfliktre
Antrge bereits beim
Beantrager identifiziert
und vermieden werden.
Die Beantragung kann
grundstzlich trotzdem
erfolgen.
1072
Minderung von
kritischem Risiko
vor Genehmigung
von Anforderung
erforderlich
NO
JA
(kundenspezifisch auszuprgen)
Die Kompensierung von

konfliktren Benutzerantrgen sollte grundstzlich systemseitig
ermglicht werden. Ob
dies erzwungen werden
kann, sodass konfliktre
Antrge sonst nicht genehmigt werden knnen,
ist in Abhngigkeit des
Risikoappetits individuell
zu bewerten.
2031
Alle Rollen fr
Genehmigenden
zulassen
JA
JA
Die Genehmigungsfhigkeit von Rollen

sollte weniger zentral
eingeschrnkt, sondern
individuell in Abhngigkeit der Rollenkritikalitt
realisiert werden.
2032
Rolleneinschrnkungsattribut des
Genehmigenden
empty
empty
Falls in 2031 keine

Einschrnkung definiert
wurde, ist dieser
Parameter obsolet.
141
142
PARAMETER ID
BESCHREIBUNG
STANDARDWERT
KOMMENTAR
2033
Alle Rollen fr Anforderer zulassen
JA
kundenspezifisch
auszuprgen
Mit dem Parameter

kann die Beantragung
von spezifischen,
insbesondere kritischen
Rollen entsprechend
des Benutzerkreises
eingeschrnkt werden.
Siehe auch 2034.
2034
Rolleneinschrnkungsattribut des
Anforderers
empty
kundenspezifisch
auszuprgen
Entsprechend der Definition in 2033 wird hier

das Attribut selektiert,
das die Einschrnkung
der Rollenauswahl fr
die Beantragenden
steuert.
2038
Rollen ohne
Genehmigende
automatisch
genehmigen
JA
JA
Der Parameter steuert

die Mglichkeit zur
Definition von Grundrollen (Default Roles), die
Benutzer bei der Beantragung ohne Genehmigung initial erhalten.
Es ist sicherzustellen,
dass eine fehlerhafte
Rollenbereitstellung
ohne Genehmiger ausgeschlossen ist. Siehe
auch Kapitel 2.4.3.1
2040
Zuordnungskommentare
bei Ablehnung
obligatorisch
NO
JA
Eine Ablehnung sollte

im Sinne der vollstndigen und nachvollziehbaren Dokumentation
begrndet werden.
Dies wird durch den
Parameter systemseitig
erzwungen.
Hinweis: Dies kann auch
in den MSMP-Einstellungen in Abhngigkeit
des Workflows gesteuert
werden.
PARAMETER-ID
BESCHREIBUNG
STANDARDWERT
KOMMENTAR
2043
Berechtigungsobjekt fr Rollensuche Rollendefinition und

-zuordnung
BOTH
kundenspezifisch
auszuprgen
Der Parameter ermglicht die Einschrnkung

der Rollenauswahl
in Abhngigkeit der
Berechtigungsobjekte
GRAC_ROLED und/
oder GRAC_ROLEP. Ob
diese Rolleneinschrnkung verwendet wird,
muss kundenspezifisch
bewertet werden. Dies
setzt allerdings voraus,
dass die Beantragenden
einen Benutzer auf dem
GRC-System haben, was
meistens nicht der Fall
sein soll.
Hinweis: Das GRCSystem kann als
Beantragungssystem
mit Benutzerzugang
ohne Berechtigungen
konfiguriert werden.
5021
Prfe Manager-ID
fr die spezifische
User-ID
JA
JA
Im Falle der Genehmigungspflicht durch den

Manager (Vorgesetzten) kann die Pflege
im Benutzerantrag
automatisiert bzw.
mittels Abgleich mit
einem LDAP/Corporate Directory validiert
werden. Somit knnen
Fehler in der manuellen
oder automatischen
Ermittlung von Manager
ausgeschlossen werden.
143
144
9.4.2.3. Kritische Berechtigungen im User Access Management

Da die Compliance-relevante Ausgestaltung der Komponente insbesondere ber die MSMPWorkflows erfolgt, kann unter den kritischen Berechtigungen zur operativen Steuerung oder
Verwendung von UAM nur jene genannt werden, die den Zugriff auf die Antragsfunktion selbst
ermglicht. Hier ist insbesondere die Verwendung der Applikation im Unternehmenskontext zu
betrachten. Je nach Ausgestaltung der Workflows ist es als unkritisch oder kritisch zu betrachten,
wenn Zugriffe beantragt werden knnen.
BERECHTIGUNGSOBJEKT
GRAC_
REQ
FELDWERT
ACTVT 01
ACTVT 02
BESCHREIBUNG
Das Berechtigungsobjekt gewhrt mit
dieser Ausprgung auf
Aktivittsebene einem
Benutzer das Recht,
um Zugriffsantrge
zu stellen.
MAPPING ZU RISIKO
Nr. 7:
Wer darf Rollen fr Zielsysteme
via SAP GRC beantragen?
Die Beantragung von Rollen wird
durch das Berechtigungsobjekt
GRAC_REQ gesteuert.
Je nach Ausprgung
des Workflows fr
den Access Request
(SAP_GRAC_ACCESS_REQUEST) ist
die Berechtigung als
kritisch oder unkritisch
zu bewerten.
9.4.3. PRFUNG DES BUSINESS ROLE MANAGEMENT

9.4.3.1. Prozess Design Business Role Management
Mit dem Rollenbau stehen u.a. die in Kapitel 4.4 genannten Risiken in Verbindung. So ist sicherzustellen, dass kritische Berechtigungen nur bedingt vergeben werden oder wesentliche technische Konzepte, die die Integritt der Anwendung erhhen, verwendet werden (bspw. Berechtigungsgruppen von Tabellen, Konten usw.).
Die GRC-Komponente ermglicht es, Rollen aus mehreren Systemen an einem zentralen Speicherort zu verwalten. Die Rollen knnen erstellt, dokumentiert, hinsichtlich SoD-Verletzungen analysiert, genehmigt und anschlieend automatisch in den Entwicklungssystemen der an GRC angebundenen SAP-Systeme generiert werden. So kann u.a. die Konsistenz bei der Rollendefinition,
-entwicklung, -verwaltung und bei Rollentests standardisiert sichergestellt werden.
NR.
PRFUNGSHANDLUNGEN FR EIN COMPLIANT BUSINESS ROLE MANAGEMENT
10.
Anwendungsbereich fr den Rollenerstellungsprozess

Kontrollziel: Die Ordnungsmigkeit der Rollenerstellung ist durch die Zentralisierung
von Rollenpflegeoptionen sichergestellt
Risiko: Eine zentrale Rollenpflege ist nicht sichergestellt. Somit untersttzen die
zentralen Parameter und Konfigurationen kein effektives IT-IKS zur Absicherung
des eingeschrnkten Datenzugriffs.
10.1.
Wie ist der Gesamtprozess von der Beantragung bis zur produktiven Realisierung zur
Erstellung und nderungen von Rollen definiert. Welche Rollenpflegemglichkeiten gibt
es? Wie sind diese Mglichkeiten eingeschrnkt bzw. welche Ausnahmen gibt es hierzu?
Hinweis: Der Prozess zur Beantragung von Berechtigungen zur Rollenpflege (nicht zur
Rollenzuordnung!) erfolgt standardmig auerhalb der BRM-Komponente. Der Einsatz
von BRM beginnt mit der Rollendefinition und anschlieender technischer Ausprgung.
Im Standard kann ein Genehmigungsworkflow integriert werden, allerdings ist die Rolle
dann bereits im Backend angelegt!
Welche Zielsysteme (Rollenpflegemandanten) sind im Anwendungsbereich fr BRM
hinterlegt?
Check: SPRO > GRC > Gemeinsame Komponenteneinstellungen > Integration Framework >
Verbindungseinstellungen bearbeiten, berprfen Sie, welche Zielsysteme (Target Connector) fr das Integration Scenario Role Management ROLMG hinterlegt sind.
berprfen Sie auch die Kennzeichnung der Standard-Mandanten pro Konnektorgruppe.
Der Absprung aus BRM ist nur auf Standard-Konnektoren systemseitig mglich.
SPRO > GRC > Access Control > Zuordnung fr Aktionen und Konnektorgruppen
bearbeiten. Prfen Sie ber Standardkonnektor der Konnektorgruppe zuordnen,
welche Standardkonnektoren pro Produktionslinie definiert sind.
Welche Einstiegspunkte gibt es zur BRM-Komponente fr die Rollenerstellung (Portal/
NWBC) und wer hat darauf Zugriff? -> Verweis auf kritische Berechtigungen fr die
Rollenpflege plus Hinweis fr PFCG-Berechtigung im SAP-Backend.
berprfen Sie den Parameter 3009 und 3012, dass diese adquat gesetzt sind, sodass
Transportwege nicht umgangen werden knnen.
11.
Rollenbereitstellung fr die Provisionierung

Kontrollziel: Die Rollenbereitstellung fr die Provisionierung erfolgt ausschlielich ber
die Rollenpflege via BRM. Ausnahmen sind nachvollziehbar dokumentiert und werden
nur eingeschrnkt verwendet.
Risiko: Es werden Rollen fr die Benutzerprovisionierung bereitgestellt, die nicht prozesskonform erstellt sind. Dies kann zu kritischen Zugriffen auf sensible Daten fhren.
145
146
NR.
11.1.
Wie erfolgt der Rollenbereitstellungsprozess fr die Provisionierung via UAM

(auch integrativ mit einem IDM zu bercksichtigen)? Grundstzliche Voraussetzungen
fr die Bereitstellung von Rollen ber BRM:
Rollenmethodologie ist vollstndig abgeschlossen, Rolle ist generiert
Der Rollenstatus ist produktiv
Der Batchjob Repository-Objektsynchronisation fr Rollen ist erfolgreich
durchgelaufen
berprfen Sie die Varianten der Rollenmethodologien. Der letzte Schritt sollte grundstzlich die Rollengenerierung sein (in Ausnahmefllen gibt es noch ein Testen). Prfen
Sie hierfr die Methodikprozesse und-schritte ber folgenden Pfad:
Check: SPRO > GRC > Access Control > Rollenverwaltung > Methodikprozesse und Schritte
definieren
Prfen Sie ber Methodikprozesse mit Bedingungsgruppe verbinden, welche Bedingungen
definiert sind, und validieren Sie diese ebenfalls mit der entsprechenden Regel BRF+. Die
entsprechende Anwendung BRF+ knnen Sie ber Bedingungsgruppen den BRFplusFunktionen zuordnen identifizieren (sofern dies angewendet wird).
Check: Tcode BRF+ > Suche kundenspezifische Anwendung und prfen Sie ber Ausdruck,
welche Grundformel (bspw. Entscheidungstabelle) als Geschftsregel hinterlegt ist.
Prfen Sie die Rollenstatus, die das Produktivkennzeichen haben.
Check: SPRO > GRC > Access Control > Rollenverwaltung > Rollenstatus bearbeiten
Prfen Sie die Taktung und Konnektorausprgung des o.g. Batchjobs sowie die Kontrollaktivitt hierzu. Wichtig ist die Synchronitt der Rollen aus dem produktiven Zielsystem in das
produktive GRC-System.
Welche Ausnahmeprozesse gibt es zur Bereitstellung von Rollen fr die Provisionierung?
Wie wird die Rollenimportfunktion verwendet? Prfen Sie auch den Parameter 3005, ob die
Methodologie nach einem Import/Update erzwungen wird.
Hinweis: Die Rollenimportfunktion muss in Ausnahmefllen zur Verfgung stehen, sollte
allerdings sehr restriktiv vergeben werden, da Genehmigungsprozesse und Risikoanalysen umgangen werden knnen.
Wer hat die Berechtigung zur Durchfhrung von Rollen Imports/ Uploads > Siehe auch
9.4.3.3. kritische Berechtigungen fr BRM
12.
Genehmigung in der Rollenpflege

Kontrollziel: Es ist ein Kontrollprozess in die Rollenpflege integriert, sodass adquate
Genehmigungen im Prozess sichergestellt sind, bevor diese zur Provisionierung bereitgestellt werden.
Risiko: Die Rollenerstellung erfolgt nicht sachgem entsprechend den fachlichen
Anforderungen und gem eines 4-Augen-Prinzips zur Vermeidung von Abweichungen
des Minimalprinzips.
NR.
12.1.
Wie ist der Genehmigungsprozesse in die Rollenpflege integriert (soweit dies ber
BRM abgebildet wird)?
berprfen Sie die Varianten der Rollenmethodologien. Grundstzlich sollte der
Genehmigungsschritt integriert sein. Prfen Sie hierfr die Methodikprozesse und
-schritte ber folgenden Pfad:
definieren. Prfen Sie auch hier die Regel BRF+, wie oben beschrieben.
berprfen Sie den Rollengenehmigungsprozess in MSMP und entsprechende Regel BRF+
(sofern dies verwendet wird), welche Genehmigungsstufen vorhanden sind.
bearbeiten, prfen Sie die Prozess ID SAP_GRAC_ROLE_APPR (im Standard) oder kundeneigenen Rollengenehmigungsprozess unter Schritt 5 Pfade bearbeiten, welche Pfade,
Genehmigungsstufen und Bearbeiter hinterlegt sind. Im Standard sollte ein einstufiger
Genehmigungsprozess ber den Rolleneigner (Role Content Approver) umgesetzt sein.
Prfen Sie ebenfalls die dazugehrige Regel BRF+, sofern dies verwendet wird.
Sofern der Standard verwendet wird, prfen Sie, welche Rolleneigner im NWBC (Portal)
hinterlegt sind.
Check1: NWBC > Einrichtung > Zugriffsverantwortliche > Access-Control-Verantwortliche,
prfen Sie im ersten Schritt, welche Benutzer grundstzlich als Rollenverantwortliche
hinterlegt sind.
Check2: NWBC > Einrichtung > Zugriffsverantwortliche > Rollenverantwortliche, wie das
Mapping der Bedingungsgruppen aus BRF+ zu den Rolleneignern umgesetzt ist.
Die Genehmigerermittlung muss lckenlos und adquat sein. Voraussetzung fr die
Durchfhrung von Genehmigeraktionen ist neben der Rolleneignerpflege im NWBC
auch die Zuordnung entsprechender Rollen im GRC-Backend.
13.
Konfliktfreie Rollen in der Rollenpflege und -zuordnung

Kontrollziel: Risiken in der Rollenerstellung werden erkannt und prventiv bereinigt.
Dies erfolgt durch systemseitige Applikationskontrollen, die die Bereitstellung von
konfliktren Rollen fr die Benutzerzuordnung ausschliet.
Risiko: Konflikte in der Rollenpflege werden nicht aufgedeckt bzw. ausgeschlossen,
daher ist die Risikovermeidung in der Rollenzuordnung nicht oder nur schwer mglich.
13.1.
Wie werden Risiken in der Rollenpflege aufgedeckt? Ist die Risikoanalyse in die BRM
Methodik integriert? Wird systemseitig ausgeschlossen, dass risikobehaftete Rollen
fr die Benutzerzuordnung bereitstehen?
definieren. Prfen Sie, ob es eine BRM Methodik gibt, die die Risikoanalyse nicht enthlt. Zu
beachten sind auch die Steuerungselemente ber BRF+, sofern es Methoden ohne Risikoanalysen gibt.
147
148
NR.
13.2.
Wie wird ausgeschlossen, dass SoD konfliktre Rollen fr die Benutzerprovisionierung

zur Verfgung stehen? Welche Manahmen gibt es zur Zulassung von konfliktren
Rollen, bspw. fr technische Benutzer oder Notfallbenutzer?
Systemseitige Applikationskontrollen werden ber die Konfigurationseinstellungen gesteuert.
Prfen Sie entsprechende Parameter 3011 sowie 3014 bis 3018.
Durch die Rollenimport- oder Rollenminderungsfunktion knnen risikobehaftete Rollen
dennoch zugelassen werden. Wer hat diese Berechtigungen? Welche Rollen wurden im
Prfungszeitraum mitigiert?
Check: NWBC > Zugriffsverwaltung > Risikominderung auf Zugriffsebene > Risikominderung
auf Rollenebene
9.4.3.2. Sicherheitskritische Parameter fr das Business Role Management

Im Folgenden finden Sie die wesentlichen Konfigurations-Parameter fr das Business Role
Management. Neben dem vorkonfigurierten Standardwert wird auch eine Best-PracticeEmpfehlung gegeben. Selbstverstndlich ist letztere kundenindividuell zu betrachten.
PARAMETERID
BESCHREIBUNG
STANDARDWERT
Nein
Nein
3005
Bei der nderung

von Rollenattributen
Rollenmethodik
zurcksetzen
3009
Lschen der Rolle vom

Backend zulassen
JA
Nein
3010
Anhngen von Dateien

zur Rollendefinition
zulassen
JA
JA
3011
Risikoanalyse vor
Rollenerzeugung
ausfhren
JA
JA
3012
Rollenerzeugung fr
mehrere Systeme
zulassen
Nein
Nein
KOMMENTAR
PARAMETERID
BESCHREIBUNG
STANDARDWERT
3013
Credentials des angemeldeten Benutzers

fr Rollenerzeugung
verwenden
Nein
JA
3014
Rollenerzeugung mit
Berechtigungsebenenberschreitungen
zulassen
Nein
Nein
3015
Rollenerzeugung mit
kritischen Berechtigungsberschreitungen zulassen
Nein
JA
3016
Rollenerzeugung bei
Verletzung der Aktionsebene zulassen
Nein
Nein
3017
Rollenerzeugung bei
Verletzung der kritischen Aktion zulassen
Nein
JA
3018
Rollenerzeugung bei
Verletzung kritischer
Rollen/Profile
zulassen
Nein
Nein
3019
Risikoanalyseergebnis
einer Einzelrolle bei
Massenrisikoanalyse
berschreiben
Nein
JA
3020
Erinnerungsbenachrichtigung zu Rollenzertifizierung
10
kundenspezifisch
auszuprgen
KOMMENTAR
Empfehlung: Keine SoDRisiken auf Rollenebene

erlauben.
Empfehlung: Keine SoDRisiken auf Rollenebene

erlauben.
Hinweis: Dies erfolgt

individuell pro Rolle,
es werden nicht alle
Rollen automatisch
berschrieben.
149
150
9.4.3.3. Kritische Berechtigungen im Business Role Management

Die Berechtigungen zur Steuerung der Komponente und deren wesentlicher Funktionen erfolgen
ber eine berschaubare Anzahl von Berechtigungsobjekten und Feldwerten. Die hierin als
kritisch und prfungsrelevant zu betrachtenden werden im Folgenden beschrieben. Der Bezug
zu den in 2.4.3.1 genannten Risiken wird hergestellt.
BERECHTIGUNGSOBJEKT
GRAC_
ASIGN
GRAC_
RLMM
FELDWERT
BESCHREIBUNG
MAPPING ZU RISIKO
ACTVT - 01
ACTVT - 02
ACTVT - 06
ACTVT - 70
GRAC_OWN_T
- ROLE
Im NWBC knnen mit der

Funktion Access Control
Verantwortliche Mitarbeiter zu Rollenbeauftragten
ernannt werden. Diese
Ernennung ist verpflichtend,
um Mitarbeiter in BRM als
Verantwortliche spezifischen Rollen zuordnen zu
knnen.
Nr. 10:
Wie ist der Gesamtprozess
von der Beantragung bis zur
produktiven Realisierung zur
Erstellung und nderungen
von Rollen definiert.
Die Berechtigung erlaubt

den Zugriff auf die Massenbearbeitungsfunktionen in
BRM. Die Ausprgung 06
zur Massenrollengenerierung erlaubt die Aktivierung
mehrerer Rollen in Produktion in einem Schritt.
Nr. 11:
Welche Ausnahmeprozesse
gibt es zur Bereitstellung von
Rollen fr die Provisionierung?
Wie wird die Rollenimportfunktion verwendet? Prfen Sie
auch den Parameter 3005, ob
die Methodologie nach einem
Import/Update erzwingen wird.
ACTVT - 38
GRAC_RLMMT
- 01 (Massenrollenimport)
GRAC_RLMMT
- 02
(Massenrollenaktualisierung)
GRAC_RLMMT
- 03
(Massenrollenableitung)
GRAC_RLMMT
- 04
(Massenaktualisierung
abgeleiteter
Rollen)
GRAC_RLMMT
- 06
(Massenrollengenerierung)
Ist der Workflow zur

genehmigungspflichtigen
Bearbeitung von Rollen
(SAP_GRAC_ROLE_APPR)
deaktiviert, so knnen
massenhaft auf ihre Inhalte
hin ungeprfte Rollen in
Produktion begeben (Massenrollengenerierung mit
GRAC_RLMMT - 06) oder
massenhaft nderungen an
Rollen durchgefhrt werden
(GRAC_RLMMT - 02).
Auch sind die Rechte zur
Ausfhrung des Massenrollenimports, der -ableitung
und der Massenaktualisierung abgeleiteter Rollen
restriktiv zu betrachten.
Prfung, welcher Mitarbeiter

ber die Rechte zur Ernennung von Rollenbeauftragten
verfgt.
Hinweis: Die Rollenimportfunktion muss in Ausnahmefllen

zur Verfgung stehen, sollte
allerdings sehr restriktiv vergeben werden, da Genehmigungsprozesse und Risikoanalysen umgangen werden
knnen.
U.a. der Massenimport von
Rollen wird mit der entsprechenden Ausprgung des
Objekts GRAC_RLMM erlaubt.
Eine Prfung auf die Vergabe
von Import-Rechten hat zu
erfolgen. Sind die Berechtigungen im Mae der beschriebenen Ausnahmeprozesse
restriktiv vergeben?
BERECHTIGUNGSOBJEKT
GRAC_
ROLED
FELDWERT
BESCHREIBUNG
MAPPING ZU RISIKO
GRAC_ROLE - *
GRAC_ACTRD
- 01 (Anlage)
GRAC_ACTRD
- 02
(nderung)
GRAC_ACTRD
- 06
(Lschung)
GRAC_ACTRD
- 64
(Generieren)
GRAC_ACTRD
- V7
(Besttigen)
steuert die Rollenadministration im Front-End. Wird BRM
genutzt, erlaubt die Vergabe
der Feldwerte in GRAC_ACTRD
je nach Ausprgung sowohl die
Anlage als auch das Generieren
von Rollen.
Nr. 10:
Wie ist der Gesamtprozess
von der Beantragung bis
zur produktiven Realisierung zur Erstellung und
nderungen von Rollen
definiert.
ber GRAC_ROLE findet die

Aussteuerung statt, fr welche
Rollen die Aktivitten der
Anlage, Bearbeitung, Generierung etc. vorgenommen
werden kann. Dieser Feldwert
eignet sich damit zur organisatorischen Eingrenzung des
Rollenadministrators.
Prfen Sie, ob ausgeschlossen
ist, dass derjenige, der die
Rolle erstellt und bearbeitet,
gleichzeitig als Role Owner
zugeordnet werden kann?
GRAC_
RLMM
ACTVT - 01
(Anlegen)
ACTVT - 02
(ndern)
ACTVT - 06
(Lschen)
ACTVT - 78
(Zuordnen)
Die Berechtigung erlaubt

die Anlage, Bearbeitung und
Zuordnung von Mitigierenden
Kontrollen zu Risiken.
Mit der Berechtigung zur
Bearbeitung und Zuordnung
von Mitigierenden Kontrollen
wird im Kontext von BRM die
Anpassung von Kontrollen
an mglicherweise kritische
Rolleninhalte ermglicht. Dies
gilt, sofern die Workflows
zur genehmigungspflichtigen
nderung von Mitigierenden
Kontrollen (SAP_GRAC_CONTROL_MAINT) und zur genehmigungspflichtigen Zuordnung
von Mitigierenden Kontrollen
(SAP_GRAC_CONTROL_ASGN)
deaktiviert sind.
Die Mglichkeiten von

der Bearbeitung der
Rollen-Meta-Daten
(Prozesse, Projekt, Name,
Beschreibung, Profilname
usw.), das Ableiten der Rolle
bis hin zum Generieren
werden ber die Ausprgungen des Objekts
GRAC_ROLED gesteuert.
Eine Prfung auf Feldwertebene erlaubt Rckschluss
darauf, welcher Mitarbeiter
im Einzelnen bspw. ber
Bearbeitungs-, Lsch- oder
Generierungsrechte verfgt.
Nr. 13:
Welche Manahmen gibt
es zur Zulassung von konfliktren Rollen, bspw. fr
technische Benutzer oder
Notfallbenutzer?
Nachgelagerte Kontrollen
knnen auch im BRM-Kontext direkt Rollen und den
darin aufgedeckten Risiken
zugeordnet und dokumentiert werden. Das Berechtigungsobjekt erlaubt
Rckschlsse ber den
Umfang der Bearbeitungsund Zuordnungs-Rechte von
Mitigierenden Kontrollen.
151
152
9.4.4. PRFUNG DES ACCESS RISK ANALYSIS

9.4.4.1. Prozess Design Access Risk Analysis
ARA bietet die Mglichkeit, mit Hilfe eines zu definierenden Regelwerkes Zugriffsrisiken zu
erkennen und ggf. Kontrollen zur Risikominderung zuzuordnen. Das Regelwerk als zentraler
Bestandteil fr alle Kernfunktionalitten von SAP GRC Access Control bestimmt mageblich,
inwieweit die Compliance technisch untersttzt werden kann.
Folgende Kernfunktionen stehen mit ARA zur Verfgung:

Verwaltung des Regelwerks inklusive aller Regeln und Funktionen/Funktionstrennungsmatrix (SoD-Matrix)

Bereitstellung der Analysefunktion in verschiedenen Bereichen wie z.B. in der Provisionierung,
im Rollenmanagement etc.
Erstellen von Berichten ber aufgetretene Konflikte fr verschiedene Zielgruppen wie z.B.
Management, IT, Audit etc.
Definition von risikomindernden Kontrollen (Mitigation)
Damit ist ARA integraler Bestandteile der drei im Vorhinein vorgestellten Funktionen und Prozesse
der Emergency Access Managements, des User Access Managements und des Business Role
Managements. Die in den Vorkapiteln vorgestellten Prfungshandlungen beziehen damit ARA
bereits im Teil mit ein.
Die im Folgenden speziell fr ARA vorgestellten Prfungshandlungen sind technisch geprgt
und beziehen sich insbesondere auf die Prozesse der Definition, Erstellung und Verwaltung jener
Risiken, Regeln und Kontrollen, die integral fr die Benutzer- und Rollenverwaltung sind.
NR.
PRFUNGSHANDLUNGEN FR DIE ACCESS RISK ANALYSIS
14.
Vernderung von Funktionen des Regelwerks

Kontrollziel: Es ist sicherzustellen, dass Funktionsnderungen nicht ungeprft in der
Produktion erfolgen.
Risiko: Funktionen des Regelwerks werden zulasten der Prfung kritischer Berechtigungen und SoD verndert. Als Folge daraus werden SoD-Risiken und kritische
Berechtigungen in Rollen und Benutzern neu provisioniert und fr bestehende
Provisionierungen nicht mehr erkannt, da die integrierte Kontrolle in BRM sowie
in UAM nicht mglich ist.
14.1.
Jeder Mitarbeiter im GRC, der Inhaber der Rolle zur Funktionsgenehmigung ist (im
Standard: SAP_GRAC_FUNCTION_APPROVER), kann nderungen von Funktionen des
Regelwerks genehmigen. Eine solche Genehmigung hat direkte Auswirkung sowohl auf
den Rollenbau-, den Provisionierungs- als auch den Mitigierungsprozess.
Ist der Prozess des Funktionsbaus aktiviert?
Falls ja:
Wer verfgt ber die Berechtigung zur Genehmigung von Funktionsnderungen (Zuweisung einer Einzelrolle, Auflistung im Rollenkonzept)? Wer genehmigt die nderung welcher
Funktion? berprfung der Funktionsnderungsauftrge in der GRC-Anforderungsbersicht,
Prozess-ID Workflow zur Funktionsgenehmigung. Stichprobenartige berprfung der
konkreten nderungen in der nderungshistorie der Funktion selbst.
Falls nein:
Gibt es ein systemunabhngiges Verfahren fr die Beantragung von Funktionsnderungen?
Wie werden Genehmigungen nachgehalten? berprfung der Vernderungen anhand der
nderungshistorie und Abgleich mit dem systemunabhngigen Papierverfahren zur
Funktionsnderung.
Hinweis: Da es im Standard nicht mglich ist, die Funktionen einzelnen fachlichen
Experten zuzuweisen, sollte die Genehmigungsstufe bei einer zentralen ComplianceInstanz liegen. Die inhaltliche Beurteilung und Freigabe einer etwaigen Funktionsnderung muss auf anderem Wege bspw. in einem Gremium aus Fachbereich, IT und
Compliance erfolgen.
15.
Vernderung von Risiken des Regelwerks

Kontrollziel: Es ist sicherzustellen, dass Risikonderungen nicht ungeprft in der
Produktion erfolgen.
Risiko: Risiken des Regelwerks werden zulasten der Prfung kritischer Berechtigungen und SoD in ihrem Risikolevel herabgestuft oder in der Kombination aus relevanten
Funktionen verndert.
Als Folge daraus werden u.U. SoD-Risiken und kritische Berechtigungen Rollen hinzugefgt und Benutzer mit solchen Risiken provisioniert, da u.U. fr herabgestufte Risiken
geringere Anforderungen an Mitigation und Vermeidung gestellt werden.
153
154
NR.
15.1.
Ist der Workflow der Risikobearbeitung und -genehmigung aktiviert?

Falls ja: Wer ist der zugeordnete Risikoverantwortliche? Wie viele unterschiedliche Risikoverantwortliche gibt es? Wurde ein 4- oder 6-Augen-Prinzip bei der Beantragung und
Freigabe von Risiko-nderungen eingehalten? berprfung der Risikonderungsauftrge
in der GRC-Anforderungsbersicht, Prozess ID Workflow zur Risikogenehmigung.
Falls nein:
Gibt es ein systemunabhngiges Verfahren fr die Beantragung von Risikonderungen?
Wie werden Genehmigungen nachgehalten? berprfung der Vernderungen anhand
der nderungshistorie und Abgleich mit dem systemunabhngigen Papierverfahren zur
Risikonderung.
16.
Lschen des Regelwerks

Kontrollziel: Es ist sicherzustellen, dass nur ausgewhlte Mitarbeiter Zugriff auf die
Upload-Funktion haben. Regelwerksnderungen unterliegen der Dokumentation und
Freigabe.
Risiko: Fr die Pflege des Regelwerks in Produktion gibt es grundstzlich zwei
Mglichkeiten. Entweder erfolgt die Bearbeitung in der Entwicklung mit anschlieendem
Transport bis in die Produktion, oder aber die nderungen erfolgen in der Produktion
direkt durch Nutzung des NWBCs und ggf. der Upload-Funktion in der SPRO.
Ein signifikantes Risiko der Lschung besteht bei Nutzung der Upload-Funktion.
Eine Lschung hat temporr zur Folge, dass kein Regelwerk in Produktion zur
Verfgung steht. Benutzer- und Rollenprfungen im Hinblick auf ihr Rechteset
finden dann nicht statt.
16.1.
Werden Massennderungen im Regelwerk unabhngig vom System bspw. in den

TXT-Details gepflegt und in die Produktion hochgeladen, erfolgt dies durch Nutzung
der Zugriffsberechtigung auf die Transaktion GRAC_UPLOAD_RULES.
Erstellung einer bersicht aller Mitarbeiter mit Zugriff auf die Transaktion GRAC_UPLOAD_
RULES in Produktion. Wird prozessual zwischen kleinteiligen nderungen des Regelwerks
und Massennderungen unterschieden? Gibt es fr Massennderungen einen Prozess unter
Nutzung der Upload-Funktion? Wie wird sichergestellt, dass in Produktion keine berschreibung des Regelwerks mit versehentlicher Lschung der Inhalte erfolgen kann?
Hinweis: Bei Upload des Regelwerks gibt es zwei unterschiedliche Optionen zur Wahl:
Anhngen und berschreiben. Bei ersterem werden die hochgeladenen Regeln dem
bestehenden Set hinzugefgt. Dieses wird erweitert. Bei Auswahl von berschreiben
werden smtliche bereits bestehenden Regeln gelscht, nur die Inhalte der UploadDatei gelangen in die Produktion.
NR.
17.
Zugriff auf die Details der Prfungslogik

Kontrollziel: Es ist sicherzustellen, dass nur ein ausgewhlter Kreis von Mitarbeitern
Zugriff auf diese Funktionen erhlt.
Risiko: SAP GRC stellt eine Funktion zur Verfgung, um das gesamte Regelwerk
und somit die Prflogik aus dem System runterzuladen. Die Detailansicht ermglicht
Rckschlsse darauf, gegen welche Berechtigungsrisiken geprft wird und wie diese
Prfung umgangen werden kann.
Ebenso werden Berichte zur Verfgung gestellt, die Rckschlsse auf die
implementierte Prfungslogik zulassen.
Ein irregulrer Zugriff auf die Prfungsdetails des Systems ist zu verhindern.
17.1.
Jeder Mitarbeiter im GRC, der Zugriff auf die Funktion zum Download des Regelwerks
hat, kann die empfindlichen Informationen beziehen.
Erstellung einer bersicht der Mitarbeiter mit Zugriff auf die Transaktion GRAC_DOWNLOAD_RULES.
18.
Nachgelagerte Kontrolle von Risiken

Kontrollziel: Bekannte und eingegangene Berechtigungsrisiken sind durch
nachgelagerte Kontrollen zu mitigieren.
Risiko: Nachgelagerte Kontrollen dienen der Mitigation von Berechtigungsrisiken,
die u.a. aufgrund der organisatorischen Struktur eingegangen werden.
18.1.
Ist der Workflow der Risiko-Mitigation aktiviert (also der Zuordnung von Mitigierenden
Kontrollen zu Risiken)?
Falls ja: Wie werden die Mitigations-Verantwortlichen ernannt (berprfung der
Kontroll-Zuordnungsauftrge in der GRC-Anforderungsbersicht, Prozess-ID Workflow
fr Kontrollzuordnungsgenehmigung, Export einer bersicht der aktuellen MitigationsVerantwortlichen)? Wie erfolgen Anlage, nderung und Review der Kontrollen bzw. Kontrollinhalte. Finden die Prfaktivitten mit einer geeigneten Frequenz statt (Registerkarte
Berichte innerhalb der Mitigierenden Kontrolle und hierin das Feld Hufigkeit in Tagen.
Der Feldwert 2 bedeutet als Beispiel, dass die Kontrolle alle 2 Tage stattfindet)?
Falls nein: Wie erfolgt die Dokumentation und Beschreibung von Mitigations-Aktivitten?
Wie erfolgt die Ernennung der Verantwortlichen? Mit welcher Frequenz werden die
Kontrollaktivitten durchgefhrt?
19.
nderung nachgelagerter Kontrollen von Risiken

Kontrollziel:
Risiko: Nachgelagerte Kontrollen, die der Mitigation bekannter Berechtigungsrisiken
dienen, werden inhaltlich zu Lasten der Prf-Effektivitt und -Effizienz verhindert.
155
156
NR.
19.1.
Ist der Workflow der Kontroll-Bearbeitung aktiviert (also der prozessgesteuerten

Anlage und nderung von Kontrollen)?
Falls ja: Welche Kontrollnderungen erfolgten im Betrachtungszeitraum? berprfung der
Kontroll-Bearbeitungsauftrge in der GRC-Anforderungsbersicht, Prozess-ID Workflow
zur Bearbeiung der mindernden Kontrolle, Export der Kontrollnderungen.
Wie wurden die Kontrollnderungen dokumentiert und freigegeben?
Falls nein: Wie erfolgt die Beantragung, Durchfhrung und Freigabe von nderungen
an den Kontrollinhalten? Wer ist berechtigt nderungen durchzufhren?
9.4.4.2. Sicherheitskritische Parameter fr das Access Risk Analysis

Im Folgenden finden Sie die wesentlichen Konfigurations-Parameter fr das Access Risk
Analysis. Neben dem vorkonfigurierten Standardwert wird auch eine Best-PracticeEmpfehlung gegeben. Selbstverstndlich ist letztere kundenindividuell zu betrachten.
PARAMETER-ID
BESCHREIBUNG
STANDARDWERT
1001
Funktionsnderungsprotokoll aktivieren
JA
JA
1002
Risikonderungsprotokoll aktivieren
JA
JA
1003
Organisationsregelprotokoll aktivieren
JA
JA
1004
Zusatzregelprotokoll
aktivieren
JA
JA
1005
Protokoll fr kritische
Rolle aktivieren
JA
JA
1006
Protokoll fr kritisches
Profil aktivieren
JA
JA
1007
Regelwerk-nderungsprotokoll aktivieren
JA
JA
1008
Rollennderungsprotokoll aktivieren
JA
JA
KOMMENTAR
PARAMETER-ID
BESCHREIBUNG
STANDARD WERT
1011
Standardablaufzeit
fr Zuordnungen
zu mindernden
Kontrollen
(in Tagen)
365
Kundenspezifisch
auszuprgen
1012
Regel-ID auch fr
Minderungszuordnung bercksichtigen
Nein
JA
1013
System fr Minderungszuordnung
bercksichtigen
Nein
JA
1021
Organisationsregeln fr andere
Anwendungen
bercksichtigen
Nein
JA
1023
Standardberichtsart fr Risikoanalyse
1-4
1024
Standardrisikostufe
fr Risikoanalyse
Alle (*)
1025
Standardregelwerk
fr Risikoanalyse
blank
Kundenspezifisch auszuprgen
1026
Standardbenutzertyp fr Risikoanalyse
1027
Offline-Risikoanalyse aktivieren
Nein
Nein
1028
Abgelaufene Benutzer einschlieen
Nein
Nein
KOMMENTAR
Die Standard-Anzahl an
Tagen bis zum Ablauf
einer Risikomitigation.
Diese Anzahl kann bei
der Zuordnung berschrieben werden.
Um mehr als einen

Eintrag vorzunehmen,
muss der Parameter
mehrfach ausgewhlt
und gepflegt werden
Wenn vorhanden, sollte

das zentrale Regelwerk
als Standard hinterlegt
werden
Erfordert die Aktualisierung von Risikoanalyseergebnissen in Bezug

auf Berechtigungen,
Rollen und Benutzer
157
158
PARAMETER-ID
BESCHREIBUNG
STANDARD WERT
KOMMENTAR
1029
Gesperrte Benutzer
einschlieen
Nein
Nein
1030
Geminderte Risiken
einschlieen
Nein
Nein
1031
Kritische Rollen und

Profile ignorieren
JA
JA
1032
Bei Benutzeranalyse
Referenzbenutzer
einschlieen
JA
JA
1033
Rolle/Profil-mindernde Kontrollen
in Risikoanalyse
einschlieen
JA
JA
1035
E-Mail-Benachrichtigung an berwacher
der aktualisierten
Risikominderung auf
Objektebene senden
JA
JA
1036
Alle Objekte in
der Risikoanalyse
anzeigen
Nein
JA
Diese Einstellung
bezieht sich auf die
SoD-Batch-RiskAnalyse. Zudem
werden bei der Ad-hocAnalyse alle geprften
Objekte mit angezeigt,
unabhngig vom
Ergebnis.
1037
Funktionstrennungsergnzungstabelle
fr die Analyse
verwenden.
JA
JA
Bei Bedarf auszuwhlen
1038
FF-Zuordnungen
in Risikoanalyse
bercksichtigen
JA
Nein
Mitigierte Rollen in
der Benutzeranalyse
9.4.4.3. Kritische Berechtigungen im Access Risk Analysis

Die Berechtigungen zur Steuerung der Komponente und deren wesentlicher Funktionen
erfolgen ber eine berschaubare Anzahl von Berechtigungsobjekten und Feldwerten. Die
hierin als kritisch und prfungsrelevant zu betrachtenden werden im Folgenden beschrieben.
Der Bezug zu den in 2.4.4.1 genannten Risiken wird hergestellt.
BERECHTIGUNGSOBJEKT
GRAC_
REP
FELDWERT
ACTVT - 16
GRAC_REP
- GRAC_SOD_
MIT_CTL_REP
BESCHREIBUNG
Die Berechtigung erlaubt das
Ausfhren des Berichts zu
SoD-Bereinigungen mittels
Mitigierenden Kontrollen im
NWBC.
Der Bericht stellt detaillierte
Informationen zur Prflogik im
Hinblick auf die Mitigation zur
Verfgung.
MAPPING ZU RISIKO
Nr. 17:
Da der Bericht sensible
Informationen darber
enthlt, welche kritischen
Berechtigungen mitigiert
werden, erlaubt der Inhalt
die Ableitung doloser Handlungen, die nicht durch
Kontrollen begleitet werden.
Der Bericht stellt detaillierte Informationen zur
Prflogik im Hinblick auf die
Mitigation zur Verfgung.
Der Zugriff auf diesen
Bericht ist entsprechend
eingeschrnkt zu vergeben.
159
160
BERECHTIGUNGSOBJEKT
S_TCODE
FELDWERT
GRAC_
UPLOAD_
RULES
BESCHREIBUNG
Die Berechtigung erlaubt den
Upload des Regelwerks inklusive
aller Risiken, Funktionen, Bewertungen und Feldwerte.
Fr die Pflege des Regelwerks in
Produktion gibt es grundstzlich
zwei Mglichkeiten. Entweder
erfolgt die Bearbeitung in der
Entwicklung mit anschlieendem
Transport bis in die Produktion,
oder aber die nderungen erfolgen
in der Produktion direkt durch
Nutzung des NWBCs und ggf. der
Upload-Funktion in der SPRO.
MAPPING ZU RISIKO
Nr. 16:
Mit Zugriff auf diese
Transaktion erhlt der
Mitarbeiter die Mglichkeit, den gesamten Regel-Bestand der Produktion per Knopfdruck zu
ndern oder zu lschen.
Temporr stehen hierauf
keine Regelverprobungen
zur Verfgung.
Prfung, welcher Mitarbeiter ber die Rechte
zum Zugriff auf die
Upload-Funktion verfgt.
Ein signifikantes Risiko der Lschung besteht bei Nutzung der

Upload-Funktion, die insbesondere
bei Massennderungen in Frage
kommt. Wird als Upload-Modus
berschreiben gewhlt, wird
die zuvor hinterlegte Prflogik
vollstndig durch die UploadInformationen ersetzt.
Eine Lschung hat temporr zur
Folge, dass kein Regelwerk in
Produktion zur Verfgung steht.
Benutzer- und Rollenprfungen im
Hinblick auf ihr Rechteset finden
dann nicht statt.
GRAC_
FUNC
ACTVT - 01
ACTVT - 02
ACTVT - 06
ACTVT - 16
ACTVT - 78
Die Berechtigung erlaubt die

Anlage und Bearbeitung von
Regelwerks-Funktionen im
NWBC sowie deren Zuordnung
zu Risiken.
Ist der Workflow zur genehmigungspflichtigen nderung von
Funktionen (SAP_GRAC_FUNC_
APPR) deaktiviert, knnen mit
dieser Berechtigung die Prflogik
beliebig verndert und dolose
Handlungen ermglicht werden.
Nr. 14:
Mit der Berechtigung auf
die angefhrten Aktivitten zum Berechtigungsobjekt GRAC_FUNC
wird die Neuanlage und
nderung von Funktionen ermglicht. Damit
kann auf Detailebene
die Prflogik verndert
werden. Der Zugriff auf
diese Berechtigung ist
entsprechend einzuschrnken.
BERECHTIGUNGSOBJEKT
GRAC_
RISK
FELDWERT
ACTVT - 01
ACTVT - 02
ACTVT - 06
ACTVT - 16
ACTVT - 78
BESCHREIBUNG
Die Berechtigung erlaubt die Anlage und Bearbeitung von Regelwerks-Risiken im NWBC sowie die
Ernennung des Risiko-Verantwortlichen.
Ist der Workflow zur genehmigungspflichtigen nderung von Risiken
(SAP_GRAC_RISK_APPR) deaktiviert, knnen mit dieser Berechtigung Risiken in ihrer Kritikalitt, in
ihrer Zuordnung zu Regelwerken
und in ihrer Zusammensetzung aus
SoD-Funktionen verndert werden.
Bewusste Vernderungen der
Risiko-Inhalte, knnen zu Lasten
der Compliance im Hinblick auf
die implementierte Prflogik der
Provisionierungs- oder Rollenpflegeprozesse erfolgen.
GRAC_
MITC
ACTVT - 01
ACTVT - 02
ACTVT - 06
ACTVT - 16
ACTVT - 78
Die Berechtigung erlaubt die Anlage,

Bearbeitung und Zuordnung von Mitigierenden Kontrollen zu Risiken.
Ist der Workflow zur genehmigungspflichtigen nderung von Mitigierenden Kontrollen (SAP_GRAC_CONTROL_MAINT) deaktiviert, erlaubt
die Berechtigung die ungeprfte
nderung von Kontrollinhalten. Ist
der Workflow zur genehmigungspflichtigen Zuordnung von Mitigierenden Kontrollen (SAP_GRAC_CONTROL_ASGN) deaktiviert, erlaubt
die Berechtigung, dass ungeprft
die Zuordnung von nachgelagerten
Kontrollen zu Risiken verndert
werden kann.
Es ist zu bercksichtigen, dass
Mitigierende Kontrollen sowohl den
identifizierten Risiken in der Benutzerprovisionierung als auch zu Rollen
selbst zugeordnet werden knnen.
MAPPING ZU RISIKO
Nr. 15:
Mit der Berechtigung auf
die angefhrten Aktivitten
zum Berechtigungsobjekt
GRAC_RISK wird die Neuanlage und nderung von
Risiken ermglicht. Damit
kann auf bergeordneter
Risiko-Ebene die Prflogik
verndert werden, indem
bspw. relevante Funktionen aus einem definierten SoD-Risiko entfernt
werden. Darber hinaus
ist es mglich, alternative
Risiko-Verantwortliche
zu ernennen, unabhngig
von einem Genehmigungsprozess, sobald der
Risiko-nderungs-Workflow deaktiviert wurde. Der
Zugriff auf diese Berechtigung ist entsprechend
einzuschrnken.
Nr. 18;
Nr. 19:
Die Berechtigung fr das
Objekt GRAC_MITC erlaubt
den bearbeitenden Zugriff
auf Mitigierende Kontrollen. Sind die Workflows
fr Bearbeitung und Zuordnung von Mitigierenden
Kontrollen aktiviert, gengt
die Berechtigung zur
Durchfhrung von Anlage
und nderungen und ist im
Prozess freizugeben. Sind
die Workflows deaktiviert,
kann mit dieser Berechtigung direkt und ungeprft
die nderung der Kontrollen erfolgen.
161
162
BERECHTIGUNGSOBJEKT
GRAC_
ASIGN
FELDWERT
BESCHREIBUNG
ACTVT - 01
ACTVT - 02
ACTVT - 06
ACTVT - 70
GRAC_OWN_T
- MIAP
GRAC_OWN_T
- MIMO
GRAC_OWN_T
- RISK
Im NWBC knnen mit der Funktion Access Control Verantwortliche Mitarbeiter fr die Ausfhrung von Genehmigungsstufen
und Kontrollen im ARA-Umfeld
ernannt werden. Diese Ernennung
ist verpflichtend, um Mitarbeiter
als Verantwortliche den Mitigierenden Kontrollen zuzuordnen
(GRAC_OWN_T-MIAP), sie als Prfungsdurchfhrende Mitigierender
Kontrollen (GRAC_OWN_T-MIMO)
oder als Risikoverantwortliche
(GRAC_OWN_T-RISK) zuordnen zu
knnen.
MAPPING ZU RISIKO
Nr. 18:
Wie werden die Mitigations-Verantwortlichen
ernannt?
wird im Prozess der Zuweisung von Mitarbeitern
zur Kontrolldurchfhrung
bentigt.
9.5. SOD-RISIKEN BEIM EINSATZ VON SAP GRC ACCESS CONTROL

Die in den Vorkapiteln dargestellten, in sich als kritisch zu bewertenden Berechtigungen werden
im Folgenden aus dem Gesichtspunkt der Funktionstrennung heraus betrachtet.
Hierzu sind teilweise die Berechtigungen aus dem Emergency Access Management, dem Business
Role Management sowie der Access Risk Analysis heranzuziehen und funktional zu clustern. Die
Berechtigungen zum User Access Management lsen im Zusammenspiel mit weiteren Rechten
aus GRC keine Funktionstrennungskonflikte aus, da es sich hierbei um eine reine WorkflowKomponente handelt.
Im Wesentlichen werden die vorgestellten kritischen Berechtigungen in nachfolgend aufgelistete
sechs Funktionen geclustert. Die Details zu den ggf. kritischen Ausprgungen der Berechtigungsobjekte sind den jeweiligen Vorkapiteln zu entnehmen.
FUNKTION
INHALTE
BERECHTIGUNGSOBJEKTE
ARA_1
Upload und Download von Regelwerksinhalten, Bearbeitung von Funktionen und

Risiken im Frontend
S_TCODE (mit GRAC_UPLOAD_

RULES und GRAC_DOWNLOAD_RULES)
GRAC_FUNC
GRAC_RISK
ARA_2
Erstellung, nderung und Zuordnung von

Mitigierenden Kontrollen
GRAC_MITC
GRAC_ASIGN
BRM_1
Anlegen und ndern von Rollen
GRAC_ROLED
BRM_2
Administrationsaufgaben, Rollenimport,
Rollenvergleich, Kontrollzuordnung
GRAC_RLMM
GRAC_MITC
GRAC_ASIGN
EAM_1
Zuordnung von FF-Verantwortlichen und

Kontrolleuren in AC-Verantwortliche,
Zuordnung von Verantwortlichen und
Kontrolleuren zu Firefighter-IDs, Ausfhren
des Berichts zu SoD-Bereinigungen mittels
Mitigierenden Kontrollen
GRAC_FFOBJ
GRAC_ASIGN
GRAC_FFOWN
GRAC_OWNER
GRAC_REP
EAM_2
Nutzung der Firefighter-Funktionalitt als

Endanwender
S_TCODE (mit GRAC_SPM oder

/GRCPI/GRIA_EAM; Zentraler
oder Dezentraler Ansatz)
163
164
Die drei Kern-Komponenten BRM, ARA und EAM sind aus Sicht der Berechtigungsvergabe und der
Vermeidung von Funktionstrennungskonflikten inhaltlich in je zwei Funktionen zu unterscheiden.
Jedes der nun aufgefhrten Risiken ist jedoch dezidiert vor dem Hintergrund der organisatorischen
Ausgestaltung und der Verwendung der Konfigurationsparameter zu betrachten. Je nach Aussteuerung kann die Kombination dieser Funktionen zu den in nachfolgender Abbildung dargestellten
Risiken fhren:
SOD MATRIX GRC REGELWERK
ARA_1
ARA_2
ARA_1: Administrationsaufgaben, Upload und Download

von Regelwerksinhalten,
Bearbeitung von Funktionen
und Risiken im Frontend
BRM_2: Administrationsaufgaben, Rollenimport, Role

Mining, Kontrollzuordnung
BRM_2
EAM_1
Mittel
Hoch
Mittel
Hoch
Hoch
EAM_1: Nutzung der Firefighter-Funktionalitt als

Endanwender
EAM_2: Administration:
Zuordnung von FF-Ownern
und Kontrolleuren, Ausfhren
der Berichts- zu SoD-Bereinigungen mittels Mitigierenden
Kontrollen
EAM_2
Hoch
ARA_2: Erstellung, nderung

und Zuordnung von Mitigierenden Kontrollen
BRM_1: Anlegen und ndern

von Rollen
BRM_1
Mittel
Mittel
Abbildung 3: SoD-Risiken im GRC
Die vier wesentlichen Risiken sind auch im Hinblick auf ihr Kritikalittslevel spezifisch im Kontext
des Unternehmens zu betrachten.
NR.
LEVEL
TITEL
BESCHREIBUNG
01
Hoch
ARA-Administration
und Rollenpflege
Die direkte Bearbeitung des definierten Regelwerks und gleichzeitige Vergabe der Berechtigung zur operativen Rollenadministration erlaubt
die Manipulation der Prfroutinen zugunsten der
Implementierung mglicherweise unzulssiger
Rolleninhalte.
02
Mittel
ARA-Kontrollpflege
und Rollenpflege
Die Funktion zur Zuordnung Mitigierender Kontrollen steht neben der Benutzeradministration
auch der Rollenpflege zur Verfgung. Durch die
Zuordnung von Kontrollen werden damit Risiken
aus dem Rollenbau kompensiert. Die gemeinsame Vergabe der Berechtigungen zur Bearbeitung
und Zuordnung solcher Kontrollen einerseits und
der operativen Rollenadministration andererseits
ist eine unzulssige Funktionsberschreitung.
03
Hoch
BRM-Administration
und Rollenadministration
Werden Berechtigungen beider Funktionscluster

zusammen vergeben, erffnen sich administrative
BRM-Prozesse fr operative Rollenadministratoren. Die u.U. erzwungene Risikoanalyse oder
Genehmigung der Rollen kann so vom Rollenadministrator bspw. durch die Nutzung des
Rollenimports umgangen werden. Risikobehaftete
Rollen wrden so nach einer Provisionierung in
das produktive System gelangen.
04
Mittel
EAM-Administration
und FirefighterEndanwender
Findet eine Vermengung administrativer und

operativer Rechte des Emergency Access Managements statt, knnen Kontrollmechanismen
umgangen, mglicherweise unberechtigte Notfallzugriffe ermglicht und inadquate Prfroutinen der durchgefhrten Zugriffe implementiert
werden.
Die gemeinsame Vergabe von Berechtigungen dieser Funktionen ist damit kritisch zu bewerten,
zu hinterfragen und in die Prfprozesse des GRCs mit einzubeziehen.
165
166
SAP HANA
10. SAP HANA AUS REVISIONSSICHT

Neben den Datenbanken anderer Anbieter, wie z.B. Oracle, stellt SAP mit HANA eine eigene
Datenbank fr SAP-Anwendungen zur Verfgung. In-Memory-Technologie und spaltenorientierte
Speichertechniken sorgen fr enorme Geschwindigkeitsvorteile und versprechen gleichzeitig
neue Anwendungsszenarien. SAP HANA bietet letztlich die Chance, wesentlich grere Datenmengen in wesentlich krzerer Zeit zu verarbeiten. Umgekehrt werden mit den technologischen
Mglichkeiten aber auch bestimmte Risiken strker betont.
Grundstzlich lassen sich hnliche bzw. dieselben Risiken wie bei anderen Datenbankmanagementsystemen identifizieren. Darber hinaus sollten beim Einsatz von SAP HANA weitere Risiken
beleuchtet werden. Die Betrachtung der Risiken wird durch zwei wesentliche architektonische
nderungen bestimmt, die sich durch den Einsatz von SAP HANA in der Systemlandschaft ergeben
(siehe Grafik unten). Neben potenziellen schnelleren Verarbeitungszeiten von Transaktionen sorgt
die Speichertechnologie insbesondere fr enorme Geschwindigkeitsvorteile bei analytischen Datenauswertungen. SAP HANA bietet damit die Mglichkeiten, in Echtzeit Analysen auf den transaktionalen Daten der SAP Business Suite durchzufhren. Die klassische Trennung zwischen OnlineAnalytical-Processing-Systemen (OLAP) (wie SAP ECC) und Online-Transaction-Processing-Systemen
(OLTP) (wie SAP Business Objects) wird aufgelst und auf einer Plattform zusammengefhrt. Insgesamt ist es Ziel der SAP, dass SAP HANA als zentrale Datenplattform dient, ber die Unternehmensanwendungen wie die Business Suite, SAP BW, BI-Anwendungen, Office-Anwendungen
integriert werden. Dabei findet die Integration in der Regel schrittweise statt. Unternehmen starten
bspw. mit SAP BW on HANA und sukzessive werden andere SAP-Systeme (und nicht SAP) auf einer
(oder mehreren) zentralen SAP-HANA-Plattform betrieben (siehe exemplarische Abbildung unten).
Die zweite wesentliche architektonische nderung ist, dass die architektonische Trennung
zwischen Datenbank- und Anwendungsschicht (teilweise) aufgelst wird. Die Verarbeitung
und damit auch die Entwicklung wird zunehmend von der Anwendungs- in die DatenbankEbene verlagert, insbesondere um die Geschwindigkeitsvorteile der In-Memory-Technologie
zu nutzen. Im Rahmen des Einsatzes von HANA XS wird die Trennung nahezu komplett aufgehoben, da Anwendungs- und Datenbankserver auf einer HANA-Plattform integriert sind.
Die architektonischen nderungen haben auch entsprechende Implikationen auf die Sicherheit
der Plattform. Wie der Abbildung zuvor zu entnehmen ist, gibt es deutlich mehr Schnittstellen und
Kommunikationswege gegenber einer klassischen SAP-Datenbank. Zudem erfolgt die Entwicklung und Modellierung zunehmend direkt auf der HANA-Plattform. Gleichzeitig greifen neben den
bisher administrativ ttigen Benutzern abhngig vom Anwendungsszenario auch Entwickler oder
Anwender der Fachbereiche, also in der Summe deutlich mehr Anwender, auf die Plattform zu.
Beispielsweise ist es mglich, dass Anwender das ERP-Schema aus HANA in Excel einbinden und
mit den Daten in der lokalen Anwendung arbeiten. Um eine entsprechende Zugriffskontrolle auf
die Daten zu implementieren und bspw. zu verhindern, dass Gehaltsdaten gelesen werden knnen,
muss ein Zugriffsschutz fr die Anwender direkt in SAP HANA implementiert werden. Insgesamt
gelten in einem solchen Szenario dieselben Sicherheitsanforderungen, die bisher eher auf SAPAnwendungsebene gestellt wurden, analog fr SAP HANA. Dies betrifft insbesondere die Zugriffskontrollen, die Transportkette (Entwicklungs-, Qualittssicherungs- und Produktiv-Datenbankserver) sowie das Change-Management-Verfahren von Programmnderungen und Entwicklungen. Es
ist dringend zu empfehlen, zunchst ein Verstndnis ber Zweck und Nutzungsszenarien von SAP
HANA sowie deren Einbettung in die IT-Landschaft zu erlangen, um die beschriebenen Implikationen auf Sicherheit und Compliance zu verstehen, potenzielle Risiken zu identifizieren und daraus
den Prfungsfokus ableiten zu knnen.
10.1. RISIKEN
Standard-Datenbankbenutzer haben noch das Initialkennwort des Auslieferungsstandes des
SAP HANA Hardware Providers. Dies ermglicht auch nicht autorisierten Dritten das unbefugte
Anmelden an der Datenbank mit den bekannten Passwrtern.
Schwachstellen der Anmeldekontrolle ermglichen das unbefugte Anmelden an der Datenbank.
Bei der Rollenkonzeption werden Funktionstrennungskonflikte nicht bercksichtigt.
Endanwender erhalten unautorisierten Zugriff auf Unternehmensinformationen in SAP HANA.
Benutzer besitzen Berechtigungen fr nderungen in der Produktion.
Die Vergabe kritischer Berechtigungen erlaubt es, das interne Kontrollsystem zu umgehen.
Anforderungen.
Technische Schnittstellen-Benutzer sind unzureichend abgesichert und ermglichen
unautorisierte Zugriffe auf SAP HANA.
Die Kommunikation mit SAP HANA ist unzureichend abgesichert und erlaubt das unautorisierte
Lesen oder Manipulieren von Daten im Transfer.
Schwachstellen in der Betriebssystemkonfiguration ermglichen unautorisierte Zugriffe auf die
SAP-HANA-Server.
167
168
Mangelnde Kontrollen im Transportwesen sorgen fr nicht freigegebene nderungen in der

Produktion oder direkte nderungen in der Produktionsumgebung.
Nicht funktionsfhige Datensicherungskonzepte und Disaster-Recovery-Konzepte gefhrden die
Datenintegritt, Vertraulichkeit und Verfgbarkeit der Daten.
Wesentliche sicherheitsrelevante Patches fr SAP HANA sind nicht installiert, sodass Angreifer
bekannte Sicherheitsschwachstellen ausnutzen knnen.
Sicherheitsrelevante Systemereignisse werden nicht protokolliert und berwacht. Angriffe oder
Sicherheitsverletzungen werden nicht erkannt und verfolgt.
Es gibt keine Manahmen, die Sicherheitsschwachstellen identifizieren und beheben.
10.2. KONTROLLZIELE
Die Standard-Datenbankbenutzer sind angemessen abgesichert.
Die Funktionen zur Anmeldekontrolle sind sicher implementiert und werden regelmig
kontrolliert.
Es liegt ein formales und freigegebenes Berechtigungskonzept vor, das gesetzliche und
unternehmensinterne Vorgaben angemessen bercksichtigt.
Die Vergabe von Berechtigungen erfolgt rollen- und aufgabenspezifisch, dabei werden
wesentliche Prinzipien der Funktionstrennung und der minimalen Rechtevergabe beachtet.
Fr Anwender der Fachbereiche sind angemessene Zugriffskontrollen in SAP HANA definiert.
Benutzer haben keine Entwicklungsrechte in der Produktion. Rechte zum ndern der produktiven
Tabellen der SAP-Applikation sollten restriktiv und ausschlielich fr Performancetuning- und
Wartungszwecke vergeben werden.
Die Nutzung kritischer Berechtigungen erfolgt eingeschrnkt und angemessen.
Die Kommunikation mit SAP HANA ist verschlsselt und die Nutzung von Hashverfahren sichert
die Integritt der Daten im Transfer.
Die Schnittstellen-Benutzer sind angemessen abgesichert.
Der Zugriff auf das Betriebssystem ist sicher implementiert.
Es besteht ein ordnungsmiges und sicher implementiertes Software-nderungs- und
Entwicklungs-Verfahren.
Es besteht ein funktionierendes Datenbanksicherungs- und Disaster-Recovery-Konzept.
Es besteht ein funktionsfhiger Patch-Management-Prozess.
Sicherheitsrelevante Ereignisse werden protokolliert und berwacht. Kritische Sicherheitsverste
werden nachverfolgt.
Regelmige Sicherheits-Prfungen der Plattform identifizieren Sicherheitsschwachstellen und
leiten kompensierende Manahmen ein.
10.3. PRFPROGRAMM: AUTHENTISIERUNG UND AUTORISIERUNG

MIT SAP HANA
Prfungshandlungen zur Beurteilung der Angemessenheit der Zugangs- und insbesondere Zugriffskontrollen sind auf das Einsatzszenario, die genutzten Anwendungen zur Kommunikation mit
der Datenbank sowie die unternehmensspezifischen Anforderungen abzustimmen.
Die unten stehende abstrahierende Abbildung veranschaulicht potenzielle Zugriffspfade auf die
SAP-HANA-Datenbank, abhngig vom geplanten Nutzungsszenario (basierend auf SAP HANA SP8
Rev. 82). Wesentliche Erkenntnis ist, dass
a) administrative und technische Schnittstellen-Benutzer
und abhngig vom Einsatzszenario zustzlich Endanwender, also
b) Entwickler und Transportbenutzer zur Steuerung des Transports von nderungen sowie
c) Anwender aus den Fachbereichen
direkt auf die Datenbank zugreifen knnen. Die Implementierung von Zugriffskontrollen fr Endanwender stellt in Abhngigkeit vom Einsatzszenario eine wesentliche zustzliche Sicherheitsanforderung dar und kann aus verschiedenen Grnden notwendig sein. Es besteht der Bedarf, dass
Entwickler Informationsmodelle und andere Entwicklungsobjekte in der SAP-HANA-Datenbank
erstellen, um analytische Auswertungen auf den Daten zu ermglichen oder die Verarbeitung
bestehender Transaktionen und Reports zu beschleunigen. Auch Benutzer der Fachbereiche knnen
direkten Zugriff auf SAP HANA bentigen, bspw. zur Auswertung der Daten mittels geeigneter
Analyse-Tools wie SAP Business Objects oder Microsoft Excel. Im Rahmen dessen kann es sinnvoll
und notwendig sein, die Zugriffskontrollen fr Endanwender direkt in SAP HANA zu implementieren, statt einen technischen Benutzer zur Kommunikation mit SAP HANA zu nutzen und diesen
zu berechtigen. So lsst sich bspw. ber entsprechende Berechtigungen in SAP HANA der Datenzugriff dergestalt steuern, dass Anwender nur auf Daten einer spezifischen Region oder eines
bestimmten Buchungskreises zugreifen knnen. Eine Abbildung entsprechender Zugriffsregeln in
SAP HANA abstrahiert dabei vom zugreifenden System, sodass die Zugriffskontrollen unabhngig
von der zugreifenden Anwendung wirksam sind.
Die Notwendigkeit angemessener Zugriffskontrollen wird umso strker betont, wenn transaktionale
und analytische Systeme die SAP-HANA-Plattform gemeinsam nutzen.
Zusammenfassend ist zu empfehlen, zunchst ein Verstndnis ber die Nutzungsszenarien von
SAP HANA sowie deren Einbettung in die IT-Landschaft zu erlangen, um potenzielle Risiken zu
identifizieren und daraus den Prfungsfokus ableiten zu knnen. Wichtige generelle Fragestellungen, die es vorab zu klren gilt, sind etwa:
Welche Ziele werden mit dem Einsatz von SAP HANA verfolgt?
Welche Nutzungsszenarien kommen zum Einsatz?
Wie bettet sich SAP HANA generell in die Systemlandschaft ein?
Welche Anwendungen kommunizieren mit der Datenbank?
Erfolgt die Benutzeradministration anwendungs-/systembergreifend ber ein zentrales Tool
oder dezentral mittels SAP HANA Studios? Fr welche Zwecke wird das SAP HANA Studio
genutzt?
169
170
NR.
AUTHENTISIERUNG UND AUTORISIERUNG MIT SAP HANA
1.
Kontrollziel: Angemessene Absicherung von Standardbenutzern

Standard-Datenbankbenutzer mit dem Standardkennwort des SAP-HANA-HardwareProviders anmelden, knnen alle Tabelleninhalte einsehen und nicht autorisierte
nderungen durchfhren.
1.1.
Sind die Standardkennwrter des Standard-Datenbankbenutzers SYSTEM entsprechend

den Vorgaben aus dem internen Kontrollsystem und gngigen Best Practices gendert,
Test, ob eine Anmeldung mit den Standardkennworten mglich ist.
Hinweis: Im Betriebsmodell Tailored Data Center werden die Standardkennwrter
durch den Provider der Appliance gesetzt. Leider ist derzeit kein Report verfgbar, der
es ermglicht, die Nutzung von Standard-Passwrtern zu identifizieren. Auch die Definition eines eigenen Reports ist derzeit nicht mglich, da die Passwrter als Hash-Werte
abgespeichert sind und diese Werte sich fr jede HANA-Instanz unterscheiden. Insofern
empfiehlt es sich, nach entsprechenden Richtlinien der Anbieter zu fragen, in denen die
Standardbenutzer und Passwrter beschrieben sind.
Die Kennwrter sollten whrend der Installation gendert und im Key Store hinterlegt werden. Die Passwortwahl sollte sich an gngigen Standards und Empfehlungen
orientieren.
1.2.
Gibt es eine Verfahrensanweisung, die den Umgang mit dem SYSTEM-Benutzer regelt?
2.
Kontrollziel: Die Anmeldekontrolle ber Verfahren sind sicher implementiert.

(Anwendbar beim Einsatz von SSO-Lsungen Single-Sign-On fr die Anmeldekontrolle)
Risiko: Schwachstellen in den genutzten Authentifizierungsmechanismen
ermglichen es, Zugriffskontrollen auszuhebeln.
2.1.
Gibt es Benutzer, die sich parallel mit unterschiedlichen Authentifizierungsmechanismen an der Datenbank anmelden knnen?
SQL> SELECT * FROM "SYS"."USERS"
WHERE LENGTH(IS_PASSWORD_ENABLED\\
IS_KERBEROS_ENABLED \\ IS_SAML_ENABLED\\IS_X509_ENABLED)<19;
Klren, wieso verschiedene Mechanismen genutzt werden.
2.2.
Gibt es unterschiedliche Benutzer mit derselben External ID (Kerberos ID)?

SQL> SELECT * FROM "SYS"."USERS" WHERE EXTERNAL_IDENTITY IN (

SELECT EXTERNAL_IDENTITY FROM "SYS"."USERS"

WHERE EXTERNAL_IDENTITY IS NOT NULL

GROUP BY EXTERNAL_IDENTITY

HAVING COUNT(*)>1
);
Risiko: SAP HANA prft lediglich die External ID. Somit kann sich ein Benutzer mit unterschiedlichen SAP-HANA-Benutzern anmelden und Funktionstrennungen aushebeln.
2.3.
Sind Kontrollen implementiert, die eine Mehrfachzuweisung der External ID fr unterschiedliche Benutzer verhindern oder zumindest erkennen?
NR.
3.
Kontrollziel: Die Bildung des Kennworts unterliegt Komplexittsregeln. (Anwendbar

beim Einsatz von Benutzernamen und Passwort zur Authentisierung und Authentifizierung an der Datenbank)
werden. Der Benutzer verwendet wiederholt dasselbe Kennwort. Er berlistet den
systemseitig erzwungenen Wechsel des Kennworts, wenn keine oder eine zu kurze
Passworthistorie gewhlt ist.
3.1.
Die Kennwortmindestlnge minimal_password_length ist festgelegt.

Vorschlagswert: 810 Zeichen
SQL> SELECT PROPERTY, VALUE FROM M_PASSWORD_POLICY WHERE

LOWER(PROPERTY) = 'minimal_password_length' AND VALUE < '8'(10)
(Das SQL-Statement zeigt einen Versto gegen den Vorschlagswert an.)
3.2.
Das Kennwort unterliegt Bildungsregeln. Der relevante Systemparameter ist

password_layout.
Vorschlagswert: Kennwort sollte mindestens einen Gro- und Kleinbuchstaben, eine
Zahl und ein Sonderzeichen enthalten (A1a$).

LOWER(PROPERTY) = 'password_layout' AND VALUE != 'A1a$'
Hinweis: A1a$ kann variieren, indem andere Werte aus den Bereichen gewhlt
wurden, z.B. Z7x#
3.3.
Die Lnge der Passworthistorie last_used_passwords ist vorbesetzt.

Vorschlagswert: 15 Kennworte bei einem Wechsel, der alle 90 Tage erzwungen wird.

(LOWER(PROPERTY) = 'last_used_passwords' AND VALUE < '15') OR

(LOWER(PROPERTY) = 'maximum_password_lifetime' AND VALUE < '90')
4.
Kontrollziel: Die Gltigkeitsdauer eines Initialkennworts ist beschrnkt. (Anwendbar

beim Einsatz von Benutzernamen und Passwort zur Authentisierung und Authentifizierung an der Datenbank)
Risiko: Das Initialkennwort ist unbegrenzt gltig oder ber einen zu langen Zeitraum.
Das Initialkennwort ist bekannt oder es wird regelmig das gleiche Initialpasswort
genutzt. Neu angelegte Benutzerkonten werden durch einen nicht autorisierten oder
fremden Mitarbeiter genutzt.
4.1.
Die Gltigkeitsdauer maximum_unused_initial_password_lifetime eines initialen

Kennworts ist definiert.
Vorschlagswert: Die Gltigkeitsdauer berschreitet nicht fnf Tage.

LOWER(PROPERTY) = 'maximum_unused_inital_password_lifetime' AND VALUE > '5'
171
172
NR.
4.2.
Der Zeitpunkt fr den Kennwortnderungszwang ist definiert

(maximum_unused_initial_password_lifetime).
Vorschlagswert: Erzwungener Wechsel des Kennworts nach mindestens 90 Tagen.

(LOWER(PROPERTY) = 'maximum_password_lifetime' AND VALUE < '90')
4.3.
Die Gltigkeitsdauer eines nicht benutzten Kennworts ist geregelt

(maximum_unused_productive_password_lifetime).
Hinweis: Dieser Parameter gibt die maximale Frist an, in der ein produktives, vom
Benutzer gewhltes Kennwort gltig bleibt seit dem letzen erfolgreichen Login, 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).
LOWER(PROPERTY) = 'maximum_unused_productive_password_lifetime' AND
VALUE > '180';
4.4.
Der Benutzer muss warten, bis er sein Kennwort wieder ndern kann
(minimum_password_lifetime).
Vorschlagswert: 1, d.h. der Benutzer muss einen Tag warten, bis das Kennwort
wieder durch den Benutzer gendert werden darf.
LOWER(PROPERTY) = 'minimum_password_lifetime' AND VALUE <'1';
5.
Kontrollziel: Erhhung des Zugriffsschutzes durch Benutzersperre nach mehrmaliger

Falscheingabe. (Anwendbar beim Einsatz von Benutzernamen und Passwort zur
Authentisierung und Authentifizierung an der Datenbank)
Risiko: Kennworte fremder Benutzerkennungen knnen ber wiederholte Anmeldeversuche ausprobiert werden.
5.1.
Die maximale Anzahl der Falschanmeldungen bis zur Sperre der Benutzer ist definiert
(maximum_invalid_connect_attempts).
Vorschlagswert: Maximal 3 Passwortfehlversuche bis zur Sperre des Benutzers.
LOWER(PROPERTY) = 'maximum_invalid_connect_attempts' AND VALUE > '3';
NR.
5.2.
Die automatische Freischaltung der Benutzerkennungen ist definiert und fhrt zu einer
automatischen Sperrung des Benutzers (password_lock_time).
Vorschlagswert: maximum_unused_productive_password_lifetime * 1440 Minuten
(erzwingt die faktische Sperrung des Benutzers. Entsprechend der Empfehlung in
4.3 ergibt sich ein Wert von 180*1440 = 259200 Minuten; Vorschlagswert der SAP ist
1440 Minuten, d.h., der Benutzer wird nach einem Tag entsperrt.)
LOWER(PROPERTY) = 'password_lock_time' AND VALUE > '259200';
Hinweis: Aus betrieblichen Grnden kann es eine Notwendigkeit geben, den Wert
runter oder auf 0 zu setzen, um technische Benutzerverbindung im Angriffsfall nicht
zu sperren. Fehlversuche sollten ber kompensierende Kontrollen identifiziert werden.
6.
Kontrollziel: Es liegt ein dokumentiertes Berechtigungskonzept vor, das die

gesetzlichen und unternehmensinternen Anforderungen bercksichtigt.
Risiko:
Es besteht kein formales Konzept.
Anforderungen.
6.1.
Liegt ein formales Berechtigungskonzept fr SAP HANA oder ein Konzept, welches
SAP HANA bercksichtigt, vor?
6.2.
Bercksichtigt das Berechtigungskonzept gesetzliche und unternehmensinterne

Anforderungen?
Dokumentationsstandards
Rollen und Privilegien
Benutzer und Rechte
Risiken und Regeln
Prozesse, Kontrollen und Verantwortlichkeiten
Offizielles Inkrafttreten des Dokuments
6.3.
Sind folgende Informationen der Unternehmensorganisation verfgbar?

Definition der Arbeitspltze und Aufgaben
Definition der Zugriffselemente (Rollen, Profile) und
die Zuordnung von Arbeitspltzen zu Zugriffselementen in Form einer Matrix?
6.4.
Findet in regelmigen Abstnden eine Rezertifizierung der Benutzer und vergebenen

Berechtigungen (Kontrolle) statt und ist diese nachvollziehbar?
173
174
NR.
7.
Kontrollziel: Die Vergabe von Berechtigungen erfolgt rollen- und aufgabenspezifisch,

dabei werden wesentliche Prinzipien der Funktionstrennung und der minimalen
Rechtevergabe beachtet.
Risiko:
Beim Design der Rollen werden wesentliche Grundstze nicht beachtet, wodurch inhrente Funktionstrennungskonflikte resultieren. Administrationsberechtigungen sind
auch an Benutzer der Fachbereiche vergeben. Benutzer besitzen Berechtigungen zur
Entwicklung und Freigabe von nderungen in der Produktion. Der Zugriff auf Daten
ist nicht angemessen eingeschrnkt.
Hinweis: Einen guten Einstiegspunkt fr das Verstndnis sowie die Modellierung
unternehmensspezifischer SAP HANA Rollen bietet das folgende SAP Dokument:
https://scn.sap.com/docs/DOC-53974
7.1.
Sind die Mglichkeiten der Funktionstrennung und zur minimalen Rechtevergabe

umgesetzt?
7.2.
Wie erfolgt der Zugriff von Benutzern auf Schema, Tabellen und Daten?
Hinweis 1: Erfolgt ein direkter Zugriff der Anwender auf die Datenbank, entstehen erweiterte Sicherheitsanforderungen. So ist sicherzustellen, dass Zugriffskontrollen definiert
sind, die den Zugriff der Anwender auf die Datenbank steuern (siehe Einfhrung Kapitel
11.4).
Hinweis 2: Endanwender sollten keine administrativen Berechtigungen (SYSTEM PRIVILEGES) und keine Berechtigung zur nderung an SAP-Anwendungsobjekten haben. Fr
den lesenden Zugriff sind in der Regel analytische Privilegien auf Views, Privilegien auf
_SYS_BI und _SYS_BIC (enthalten Metadaten und Daten ber Views) sowie grundstzliche Rechte fr das Repository notwendig.
7.3.
Wie wird der Zugriff von Administratoren auf die Datenbank gesteuert?
Hinweis: SYSTEM-Privilegien (die in der Regel mit ADMIN enden) sind Berechtigungen
fr den administrativen Zugriff auf die Datenbank. INIFILE ADMIN erlaubt beispielsweise die nderungen der wesentlichen Systemkonfigurationen. Einen generellen
lesenden Zugriff auf die Administrationskonsole ist mit der Berechtigung CATALOG
READ mglich.
NR.
7.4.
Wie erfolgt die Zugriffsteuerung fr Entwicklung, Test, Freigabe und den Transport
von nderungen in die Produktion?
Hinweis 1: Der Transport von Entwicklungsobjekten wird ber Transportartefakte
(Delivery Units) sichergestellt. Diese Objekte mssen zur Nutzung in einer Umgebung
manuell ber das HANA Studio importiert oder ber CTS+ transportiert werden. In der
Regel ist der Import auch gleichzeitig mit einer Aktivierung und damit einer Freigabe fr
die Nutzung der Objekte in der Umgebung verbunden. Zum Zeitpunkt der Erstellung des
Leitfadens hat SAP den SAP HANA Application Lifecycle Manager (HALM) fr den Transport von Entwicklungsobjekten eingefhrt. Mit Hilfe dieses Tools soll der automatische
Import der Transportartefakte zwischen zwei HANA-Systemen mglich sein. Dadurch
sollten auch die bis dato fr die Produktion notwendigen Import (REPO.IMPORT, CREATE SCENARIO) und separaten Aktivierungsrechte (REPO.ACTIVATE_IMPORTED_OBJECTS, REPO.ACTIVATE_NATIVE_OBJECTS) fr das Repository obsolet werden, da das
HALM implizit in den SYS_REPO-Benutzer wechselt und die nderungen vornimmt.
Ein ndernder Zugriff auf das Repository der produktiven Umgebung sollte somit fr
den normalen Betrieb nicht notwendig sein, wodurch sich gleichzeitig das Risiko von
unautorisierten nderungen weiter reduziert. Insofern ist zu vermuten, dass der Einsatz
des HALMs empfehlenswert ist. Inwiefern das Tool ein sicheres und ordnungsmiges
Transportwesen untersttzt, konnte jedoch zum Zeitpunkt der Erstellung des Leitfadens
nicht geprft werden.
Hinweis 2: Wesentliche Entwicklungsberechtigungen sind DEVELOPMENT (vordefinierte
SAP HANA Rolle) oder REPO.EDIT_IMPORTED_OBJECTS, REPO.EDIT_NATIVE_OBJECTS,
REPO.MAINTAIN_IMPORTED_PACKAGES und REPO.MAINTAIN_NATIVE_PACKAGES
sowie Lese-Berechtigungen in den bentigten Schemas. Benutzer zum Import und
Freigabe von Entwicklungsobjekten mssen in allen nachgelagerten Systemen angelegt
sein (auer beim Einsatz des HALM, siehe Hinweis 1). Wesentliche Berechtigungen sind
REPO.IMPORT, CREATE SCENARIO und mglicherweise noch REPO.ACTIVATE_IMPORTED_OBJECTS und REPO.ACTIVATE_NATIVE_OBJECTS fr die nachtrgliche Aktivierung
von Entwicklungsobjekten.
Hinweis 3: In SAP HANA SP8 ist es nicht mglich, den Entwickler auf dedizierte
Repository-Objekte einzuschrnken. So kann dieser sowohl Rollen als auch Schemas
anlegen, ohne ROLE ADMIN und SCHEMA ADMIN Berechtigungen zu besitzen. Entwickler sollten, damit sie sich nicht eigene Rollen erweitern knnen, auf diese keine
REPO.EDIT_*_OBJECTS und auch REPO.ACTIVATE_*_OBJECTS haben.
8.
Kontrollziel: Die Nutzung kritischer Berechtigungen, Standard-Rollen und -Benutzer

erfolgt eingeschrnkt und angemessen.
Risiko: Benutzer besitzen kritische Berechtigungen, die es erlauben. Zugriffskontrollen auszuhebeln.
Eine bersicht aller Berechtigung eines Benutzers und Auflsung der Rollen sind in
dem View
SQL> SELECT *
FROM "SYS"."EFFECTIVE_PRIVILEGES"
WHERE USER_NAME="<USERNAME>";
zu finden.
175
176
NR.
8.1.
Kommt der SYSTEM-Benutzer zum Einsatz und in welchem Kontext?

Hinweis:
Der SYSTEM-Benutzer besitzt nahezu Vollzugriff auf die Datenbank. Insofern sollte die
Nutzung des SYSTEM-Benutzers im Regelbetrieb nicht mglich sein. Den SYSTEMBenutzer bentigt man hchstens im Rahmen der initialen Konfiguration der Datenbank oder bei Datenbank-Upgrades. SAP empfiehlt, den Benutzer zu deaktivieren.
Die letzte Nutzung des Benutzers kann geprft werden ber:
SQL> SELECT LAST_SUCCESSFUL_CONNECT
FROM "PUBLIC"."USERS"
WHERE USER_NAME='SYSTEM';
Die Prfung, ob der Benutzer deaktiviert ist:
SQL> SELECT USER_DEACTIVATED
FROM "PUBLIC"."USERS"
WHERE USER_NAME='SYSTEM';
8.2.
Werden SAP HANA Standard-Rollen an Benutzer vergeben?

SQL> SELECT GRANTEE_TYPE, GRANTEE, PRIVILEGE
FROM "PUBLIC"."GRANTED_PRIVILEGES"
WHERE PRIVILEGE IN ('CONTENT ADMIN')
ORDER BY GRANTEE_TYPE, GRANTEE
SQL> SELECT ROLE_NAME, GRANTEE FROM "PUBLIC"."GRANTED_ROLES"
WHERE ROLE_NAME IN ('MONITORING')
ORDER BY ROLE_NAME, GRANTEE
Hinweis: Es ist kritisch zu hinterfragen, ob vor dem Hintergrund des Prinzips der minimalen Rechtevergabe die Vergabe von SAP HANA Standard-Rollen angemessen ist.
Die Standard-Rollen enthalten vielfach ber den intendierten Nutzungskontext hinausgehende Berechtigungen. SAP empfiehlt deshalb, eigene Rollen zu definieren und
die Standard-Rollen als Orientierungshilfe fr die Ausprgung zu nutzen. Beispiele fr
solche Standard-Rollen bilden MODELING und CONTENT ADMIN zur Erstellung von
Informationsmodellen und MONITORING zur betrieblichen berwachung der Datenbank.
NR.
8.3.
Ist die Berechtigung ROLE ADMIN in der Produktion vergeben?

SQL> SELECT GRANTEE_TYPE, GRANTEE, PRIVILEGE
FROM "PUBLIC"."GRANTED_PRIVILEGES"
WHERE PRIVILEGE IN ('ROLE ADMIN', 'USER ADMIN')
ORDER BY GRANTEE_TYPE, GRANTEE
Hinweis: ROLE ADMIN ermglicht es, Rollen in der Produktion zu erstellen. Die Rollen
knnen zum Zeitpunkt der Speicherung sofort produktiv genutzt werden. Somit knnen
existierende Zugriffskontrollen ausgehebelt werden. Insbesondere da hchstwahrscheinlich fr die Rollenerstellung mittels ROLE ADMIN auch weitergehende Berechtigungen auf Privilegien (mit GRANT OPTION) vergeben sein werden, um die Rollenverwaltung vornehmen zu knnen. Im Endeffekt besteht auch die Gefahr, dass bestehende
und zugewiesene Rollen direkt verndert werden knnen, ohne dass nderungen einer
Kontrolle unterliegen. Anstatt ROLE ADMIN fr die Rollenverwaltung zu nutzen, ist es
empfehlenswert, Rollen als Design-Time-Objekte zu erstellen, sodass ein Transport der
Rollen untersttzt und Funktionstrennungen implementiert werden knnen. Bei einer
konsequenten Rollendefinition als Design-Time-Objekte ist damit die Nutzung von
ROLE ADMIN zur Erstellung von Rollen obsolet. Dies entspricht auch dem empfohlenen
Vorgehen der SAP (siehe: https://scn.sap.com/docs/DOC-53974)
Hinweis 2: Fr die Erstellung von SLT Schemas wird derzeit noch die Berechtigung
ROLE ADMIN bentigt, um die SLT-Standardrollen durch den Hintergrundprozess
erstellen zu lassen. Die Einbindung von SLT-Schemas ist jedoch keine Regelaktivitt.
8.4.
Sind Entwicklungsberechtigungen DEVELOPMENT, REPO.EDIT_IMPORTED_OBJECTS

oder REPO.EDIT_NATIVE_IMPORTED_OBJECTS an Benutzer in der Produktion
vergeben?
Hinweis: REPO.EDIT_IMPORTED_OBJETCS / REPO.EDIT_NATIVE_OBJECTS erlaubt die
nderung von Entwicklungsobjekten z.B. von Informationsmodellen, Stored Procedures
oder Rollen. Benutzer mit diesen Berechtigungen knnen insbesondere ber die SAP
HANA Development-Perspektive ausbrechen und im Kontext eines technischen Benutzers (z.B. _SYS_REPO) beliebige nderungen an Repository-Objekten durchfhren.
8.5.
Ist die Berechtigung DEBUG und ATTACH DEBUGGER an Benutzer in der Produktion
vergeben?
Hinweis: Die Debug-Funktion sollte in der Regel nicht in der Produktion vergeben
werden. Eine zeitlich beschrnkte Verwendung von DEBUG im Produktivsystem sollte
zwingend durch den Einsatz des SAP HANA Auditing protokolliert werden.
8.6.
Ist die Berechtigung SYS_BIC_ALL in der Produktion vergeben?

Hinweis: Die Vergabe der Berechtigung _SYS_BI_CP_ALL in Verbindung mit der Vergabe
von Lese-Berechtigungen auf ein Schema erlaubt es, smtliche Views eines Schemas
auszufhren und damit smtliche Daten in diesem View zu lesen. Somit knnen implementierte Kontrollen zur Beschrnkung des Zugriffs auf einzelne Views ausgehebelt
werden. Insofern ist die Vergabe der Berechtigung kritisch zu hinterfragen.
177
178
NR.
8.7.
Ist die Berechtigung DATA ADMIN in der Produktion vergeben?

Hinweis: Die Berechtigung DATA ADMIN erlaubt es, jegliche Daten in System Views
zu lesen und jegliche DDL-Kommandos (Data Definition Language) in der Datenbank
abzusetzen. Dies ermglicht es, nderungen an wesentlichen Tabellen und Views vorzunehmen. Insofern ist die Vergabe von DATA ADMIN kritisch zu hinterfragen. Notwendige
DDL-Kommandos in der Produktion bspw. zum Reorganisieren von Tabellen knnen
auch ber eigene Rollen explizit auf ein Schema gesetzt werden.
9.
Kontrollziel: Es ist ein formales Notfallbenutzerkonzept definiert. Der Notfallbenutzer

ist angemessen abgesichert.
Risiko:
Es gibt keinen eigenen Notfallbenutzer: Systemadministratoren arbeiten im
Normalbetrieb unter dem Standardbenutzer SYSTEM oder nutzen den Standardbenutzer SYSTEM als Notfallbenutzer.
Es gibt einen eigenen Notfallbenutzer, der nicht angemessen abgesichert ist.
9.1.
Ist fr den Notfall mindestens eine Benutzerkennung eingerichtet,

die nicht der Standardbenutzer SYSTEM ist,
die die notwendigen weitreichenden Berechtigungen hat,
die mit einem komplexen Kennwort ausgestattet ist,
deren Kennwort an einem sicheren Ort zugriffsgeschtzt aufbewahrt wird,
wobei der Zugriff auf das Kennwort im 4-Augen-Prinzip erfolgen muss?
9.2.
Werden Aktionen unter dem Notfallbenutzer dokumentiert mindestens unter Angabe

des Grundes
des Zeitraums
der darunter ttigen Personen
der Ttigkeiten, die damit durchgefhrt wurden?
9.3.
Werden fr einen Notfallbenutzer ber das SAP HANA Auditing alle Ereignisse aller
Audit-Klassen zwangsprotokolliert?
9.4.
Wird nach der Notfallaktion das Kennwort des Notfallbenutzers gendert?
10.4. PRFPROGRAMM: SICHERE KONFIGURATION DER SCHNITT STELLEN VON SAP HANA
NR.
SICHERE KONFIGURATION DER SCHNITTSTELLEN VON SAP HANA
1.
Kontrollziel: Die Kommunikation mit den SAP-HANA-Servern ist verschlsselt und die
Nutzung von Hashverfahren sichert die Integritt der Daten im Transfer.
Risiko: Die Datenbertragung erfolgt unverschlsselt. Ein Angreifer (Man-in-theMiddle) kann die Kommunikation abhren und Passwrter abfangen und/oder
Geschftsdaten lesen und manipulieren.
1.1.
Erfolgt die Kommunikation mit unterschiedlichen Systemen (z.B. SAP HANA Studio,
Replikationsserver, Solution Manager, Business Suite, SAP BI etc.) und der SAP-HANADatenbank sowie innerhalb von HANA-Servern bspw. im Scale-Out-Szenario oder fr
HANA-Disaster-Recovery-Server verschlsselt?
Generelle Einstellung zur verschlsselten Kommunikation.
SQL> SELECT * FROM M_INIFILE_CONTENTS WHERE SECTION=communication AND
FILE_NAME=global.ini
Der Cryptoprovider kann ber den Parameter (KEY) sslcryptoprovider abgeleitet werden,
sslkeystore und ssltrustore geben den Dateinamen und Pfad fr den trust store und key
store auf der HANA appliance an. Ist der Parameter sslenforce (KEY) mit TRUE (VALUE)
gesetzt, akzeptiert SAP HANA ausschlielich verschlsselte Datenbankverbindungen.
Stichprobenprfung der Verbindungseinstellungen von Benutzern im HANA Studio und/
oder mittels einer Abfrage auf die View SYS.M_CONNECTIONS. Diese View fhrt alle
aktiven und ruhenden Verbindungen zum HANA-Server auf.
SQL> SELECT CONNECTION_TYPE, IS_ENCRYPTED, COUNT(*)
FROM "SYS"."M_CONNECTIONS"
GROUP BY CONNECTION_TYPE, IS_ENCRYPTED
ORDER BY IS_ENCRYPTED DESC
Das Ergebnis zeigt, ob und wie viele verschlsselte und unverschlsselte Verbindungen
(aktiv und ruhend) existierten.
Hinweis 1: Jegliche Verbindungen zur Datenbank und XS-Engine lassen sich beispielsweise mittels der Nutzung von OpenSSL oder CommonCrypto (TLS 1.0) verschlsseln.
Insbesondere sollten Verbindungen aus nicht vertrauenswrdigen Netzsegmenten
verschlsselt werden und solche, bei denen die Daten ein hohes Schutzniveau besitzen.
Hinweis 2: Da laut SAP ab Rev74 nur noch die CommonCrypto untersttzt wird, sollte
eine Implementierung entsprechend mit Hilfe dieser von SAP entwickelten Bibliothek
erfolgen.
1.2.
Sind Netzwerkkontrolle implementiert, die die Nutzung von Diensten einschrnkt?

Hinweis: Aus Sicherheitsgrnden empfiehlt es sich, nicht genutzte Ports weitreichend
einzuschrnken.
179
180
NR.
SICHERE KONFIGURATION DER SCHNITTSTELLEN VON SAP HANA
2.
Kontrollziel: Die Schnittstellen-Benutzer sind angemessen abgesichert.

Risiko: Technische Schnittstellen-Benutzer sind unzureichend abgesichert, sodass
Zugriffskontrollen mit den entsprechenden Benutzern ausgehebelt werden knnen.
2.1.
Unterliegt der SAPSID Benutzer, die fr die Kommunikation und den Zugriff von SAP
Anwendungen auf SAP HANA notwendig sind, Passwortkomplexittsregeln?
Hinweis: Der SAPSID Benutzer ist der technische Benutzer zum Zugriff von SAP
Anwendungen wie SAP ECC, SAP BW etc. auf die Datenbank. Die Applikationsebene
implementiert dabei die Zugriffskontrollen auf Applikationsebene. Nichtsdestotrotz
muss der SAPSID Benutzer separat in SAP HANA berechtigt werden. Eine direkte
Anmeldung mit dem Benutzer ist derzeit technisch mglich und kann nicht unterbunden werden (SAP HANA SP7).
2.2.
Erfolgt die Berechtigungsvergabe an den SAPSID Benutzer nach dem Prinzip der
minimalen Rechtevergabe?
2.3.
Welche weiteren technischen Benutzer sind zur Kommunikation mit anderen Systemen in HANA eingerichtet und welche Berechtigungen besitzen diese Benutzer?
Hinweis: Fr die Kommunikation mit anderen Systemen wie etwa dem Solution
Manager oder dem DBA Cockpit liefert SAP Standard-Rollen aus (in diesem Fall die
Rolle DBA-COCKPIT). Deren Angemessenheit sollte jedoch kritisch geprft werden, da
bspw. die Rolle DBACOCKPIT die Konfiguration der Datenbank erlaubt (INIFILE ADMIN).
Es ist mglich, eigene Rollen fr die Benutzer zu definieren. Dies gilt im brigen auch
fr den SAP-OSS-Benutzer. Eine direkte Anmeldung mit diesen Benutzern an der
Datenbank ist mglich. Seit SPS 8 steht ein neuer User Typ Restricted User, der sich
nicht direkt an der Datenbank anmelden kann, sondern nur ber HANA XS, wenn die
entsprechende XS-basierte Applikation ihm entsprechende Rollen zugewiesen hat.
Eine Prfung der Wirksamkeit dieses Mechanismus war im Rahmen der Erstellung
des Leitfadens leider nicht mglich.
10.5. PRFPROGRAMM: ABSICHERUNG VON SAP HANA UNTER LINUX

SAP-HANA-Server werden auf Basis unterschiedlicher Modelle ausgeliefert und betrieben. Das
derzeit gngigste Modell ist das des Tailored Data Centers, d.h., ein zertifizierte Partner liefert
SAP HANA als Appliance aus. Vereinfacht ausgedrckt bedeutet dies, dass Hardware, Betriebssystem und Software vorkonfiguriert durch den Hardware-Lieferanten bereitgestellt werden.Die
folgenden Ausfhrungen in diesem Kapitel beziehen sich lediglich auf dieses Auslieferungsmodell,
da den Autoren keine Erfahrungen mit anderen Auslieferungsmodellen vorliegen.
Fr die Sicherheit der Systeme bedeutet der Betrieb einer Appliance zunchst, dass Hrtungsregeln zur Absicherung des Betriebssystems derzeit nur eingeschrnkt umgesetzt werden knnen.
SAP erlaubt es seinen Kunden zwar, inzwischen Betriebssystemeinstellungen zu ndern es sei
denn, SAP hat eine bestimmte nderung explizit ausgeschlossen (siehe auch SAP Notes: 1730999:
Configuration changes in HANA appliance, 1731000: Unrecommended configuration changes).
Dennoch mssen Unternehmen nderungen von Betriebssystemeinstellungen immer auch mit dem
jeweiligen Hardware-Partner abstimmen. Insofern sind die Unternehmen auch auf die Hrtung
durch den Anbieter angewiesen. Dennoch knnen die Prfungshandlungen zur Prfung der Systemintegritt auf der Betriebssystemebene prinzipiell analog zum Kapitel Systemintegritt auf Betriebssystemebene durchgefhrt werden. Darber hinaus knnen einige weitere Prfungen durchgefhrt werden.
NR.
ABSICHERUNG VON SAP HANA UNTER LINUX
1.
Kontrollziel: Angemessene Zugriffskontrollen unter Linux

Risiko: Schwachstellen in der Betriebssystemkonfiguration ermglichen den
nicht-autorisierten Zugriff auf die SAP-HANA Server.
1.1.
Sind die Standard-Kennwrter des Appliance Providers der Standard-Benutzer des

Betriebssystems nach einer Systeminstallation vor Produktivstellung gendert
worden (root, <SID>adm und weitere Benutzer zur Verwaltung der Hardware/Appliance)?
Test, ob eine Anmeldung mit den Standardkennwrtern mglich ist.
Hinweis 1: Die Standardkennwrter werden durch den Provider der Appliance gesetzt.
Insofern empfiehlt es sich, nach entsprechenden Richtlinien der Anbieter zu fragen, in
denen die Standardbenutzer und Passwrter beschrieben sind.
Die Kennwrter sollten whrend der Installation gendert und im Key Store hinterlegt
werden. Komplexe Passwrter sind zu whlen.
1.2.
Erfolgt die Anmeldung am Betriebssystem personalisiert und mittels starker

Authentisierungsmechanismen?
1.3.
Ist die direkte Nutzung von root und <SID>adm per ssh deaktiviert?
1.4.
Ist der Zugriff auf das HOME-Verzeichnis sowie die Dateien eingeschrnkt?
1.5.
Werden Benutzer-Kennwrter in Skripten zur automatisierten Durchfhrung administrativer Ttigkeiten im Klartext gespeichert oder wird durchgehend auf die Mechanismen
des hdbuserstore zugegriffen?
181
182
NR.
ABSICHERUNG VON SAP HANA UNTER LINUX
1.6.
Sind nicht bentigte Dienste abgeschaltet?

Plausibilisieren der Liste aller offenen Ports
Bash set IID=`cat /usr/sap/${SID}/SYS/global/hdb/install/config/sapprofile.ini | grep
"SAPSYSTEM=" | awk -F "=" '{print $2}'`; \
netstat -apntu \
| egrep -v "(ESTABLISHED|CLOSE_WAIT)" \
| egrep -v "(:3${IID}07|:3${IID}08)" \
| egrep -v "(:3${IID}10)" \
| egrep -v "(:3${IID}01)" \
| egrep -v "(:3${IID}02)" \
| egrep -v "(:3${IID}03|:3${IID}15)" \
| egrep -v "(:3${IID}05|:3${IID}17)" \
| egrep -v "(:64998|:64999|:65000|:80${IID} )" \
| egrep -v "(:5${IID}13)" \
| egrep -v "(:3${IID}00)" \
| egrep -v "(:1128 |:1129 )" \
| egrep -v "(0.0.0.0:22 |:::22 )" \
| egrep -v "(127.0.0.1:25 |::1:25 )" \
| egrep -v "(:123 )" \
| egrep -v "(:111 )" \
| egrep -v "(:199 )" \
| egrep -v "(:161 )" \
| egrep -v "(:80 )" \
| egrep -v "(:2301 |:2381 )" \
| egrep -v "(:25375 |:25376 |:25393)" \
| egrep -v "(:681 )"; \
unset IID
Ergebnis zeigt zustzlich geffnete Ports
1.7.
Die SAP HANA Server sind im Standard gehrtet und garantieren ein quivalentes
Schutzniveau zu den Empfehlungen von SUSE Linux (siehe Link https://www.suse.com/
documentation/sles11/singlehtml/book_hardening/book_hardening.html) bzw. den
unternehmensspezifischen Unternehmen Hrtungsregeln fr SUSE Linux?
10.6. PRFPROGRAMM: SICHERES DATENBANKMANAGEMENT

MIT SAP HANA
NR.
DATENBANKMANAGEMENT
1.
Kontrollziel: Es besteht ein ordnungsmiges und sicher implementiertes

Software-nderungs- und Entwicklungs-Verfahren
Risiko: Die erforderlichen Funktionstrennungen eines geordneten Entwicklungs-,
Tests- und Freigabeverfahrens sind nicht im SAP-System abgebildet. Schwachstellen
bei der Implementierung des Software-Transport-Systems ermglichen ein Umgehen
der internen Kontrollen und gefhrden System- und Datenintegritt.
1.1.
Wird die Datenbank mit von SAP freigebenden Revisionen regelmig auf dem neuesten
Stand gehalten?
1.2.
Gibt es eine Entwicklungsrichtlinie fr die Entwicklung in HANA sowie den sicheren

Transport der Entwicklungsobjekte?
1.3.
Kommt eine Mehrsystemlandschaft fr den ordnungsgemen Transport von

Entwicklungs- und nderungsobjekten zum Einsatz?
1.4.
Welche Mechanismen und Tools werden fr den Transport der Entwicklungsobjekte

genutzt?
Hinweis 1: Grundstzlich gibt es vier verschiedene Mglichkeiten fr den Transport von
Entwicklungsobjekten:
1 Transport mit Hilfe des HANA Studios
2 Transport mit Hilfe von CTS+ zum Transport von ABAP- und NON-ABAPEntwicklungsobjekten
3 Transport mit Hilfe des Solution Managers zum Transport von ABAP-Objekten
(Die Transportartefakte oder Delivery Units werden in diesem Fall einem ABAPObjekt angehngt.)
4 Verwendung des SAP HANA Lifecycle Managers
Hinweis 2: Zum Zeitpunkt der Erstellung des Leitfadens hat SAP den SAP HANA
Application Lifecycle Manager (HALM) fr den Transport von Entwicklungsobjekten
eingefhrt. Mit Hilfe dieses Tools soll der automatische Import der Transportartefakte
zwischen zwei HANA-Systemen mglich sein. Dadurch sollten auch die bis dato
fr die Produktion notwendigen Import (REPO.IMPORT, CREATE SCENARIO) und
separaten Aktivierungsrechte (REPO.ACTIVATE_IMPORTED_OBJECTS, REPO.ACTIVATE_NATIVE_OBJECTS) fr das Repository obsolet werden, da das HALM implizit in den
SYS_REPO-Benutzer wechselt und die nderungen vornimmt. Ein ndernder Zugriff auf
das Repository der produktiven Umgebung sollte somit fr den normalen Betrieb nicht
notwendig sein, wodurch sich gleichzeitig das Risiko von unautorisierten nderungen
weiter reduziert. Insofern ist zu vermuten, dass der Einsatz des HALMs empfehlenswert
ist. Inwiefern das Tool ein sicheres und ordnungsmiges Transportwesen untersttzt,
konnte jedoch zum Zeitpunkt der Erstellung des Leitfadens nicht geprft werden.
1.4.
Wie ist sichergestellt, dass die nderungsobjekte fr die Produktion getestet und
freigeben sind?
1.5.
Ist eine Versionskontrolle bei dem Import von Entwicklungsobjekten vorgesehen?

Hinweis: Falls nicht der HALM im Einsatz ist, erfolgt das Einspielen der Delivery Unit,
in denen die Entwicklungsobjekte zugewiesen sind, i.d.R. manuell. Dementsprechend
ist sicherzustellen, dass die eingespielte Version der freigegebenen entspricht.
183
184
NR.
DATENBANKMANAGEMENT
2.
Kontrollziel: Es ist ein angemessenes und funktionierendes Datenbanksicherungsund Disaster-Recovery-Konzept definiert.

Risiko: Nicht funktionsfhige Datensicherungskonzept und Disaster-RecoveryKonzepte gefhrden die Datenintegritt, Vertraulichkeit und Verfgbarkeit der
Daten. Dies knnte unter anderem zum Verlust von Daten fhren.
2.1.
Besteht ein Datenbanksicherungskonzept und was ist geregelt?
2.2.
Wie ist sichergestellt, dass keine Daten verloren gehen bzw. unvollstndige
Datensicherungen erkannt werden?
2.3.
Besteht ein Disaster-Recovery-Konzept und was ist geregelt?
2.4.
Werden die SAP-Mechanismen zur Datenreplikation eingesetzt, um Disaster-RecoveryFunktionalitten fr SAP HANA bereitzustellen? Sind bei der Nutzung der asynchronen
Replikation kompensierende Manahmen definiert, die die konsistente Datenbertragung sicherstellen?
Hinweis: SAP HANA untersttzt unterschiedliche Replikationsmechanismen zur Datenbertragung, die insbesondere fr den Einsatz von Disaster-Recovery-Funktionalitten
eingesetzt werden. Bei der synchronen Replikation wartet die primre Datenbank mit
der Verarbeitung auf die Verarbeitungsbesttigung der sekundren Datenbank. Im
Rahmen der asynchronen Replikation wartet die primre Datenbank nicht auf die
Verarbeitung in der sekundren Datenbank. Insofern steigt das Risiko des Datenverlustes. Dementsprechend sollten kompensierende Manahmen zur berwachung der
Replikation definiert und wirksam sein.
2.5.
Welche Manahmen sind implementiert, um die Sicherheit der Datenreplikation zu

untersttzen?
Hinweis: Es sind unterschiedliche Manahmen denkbar, die das Risiko vermindern,
dass die Vertraulichkeit, Integritt und/oder Verfgbarkeit der Datenbertragung
durch Angreifer verletzt wird. Beispiele solcher Manahmen knnen genereller Art
sein, wie eine direkte, sichere Glasfaserkabel-Verbindung der beiden Rechenzentren,
oder aber speziell fr das SAP-HANA-Disaster-Recovery-Konzept definiert werden wie
die Verschlsselung des Datentransfers.
2.6.
Liegen Nachweise vor, die die Funktionsfhigkeit des Datenbanksicherungskonzeptes

belegen?
Werden regelmig Datensicherungen durchgefhrt und diese geprft? Werden die
Datensicherungen geschtzt?
2.7.
Liegen Nachweise vor, die die Funktionsfhigkeit des Disaster-Recovery-Konzeptes

belegen?
Hinweis: Es sollte ein periodischer Test des Disaster-Recovery-Konzeptes durchgefhrt
werden, um den Nachweis der Funktionsfhigkeit zu erbringen.
NR.
DATENBANKMANAGEMENT
3.
Kontrollziel: Es besteht ein angemessener und funktionierender Patch-ManagementProzess.

Risiko: Wesentliche sicherheitsrelevante Patches fr die Appliance sind nicht installiert, sodass Angreifer bekannte Sicherheitsschwachstellen ausnutzen knnen.
3.1.
Wird die Datenbank mit von SAP freigegebenen SAP-HANA-Sicherheits-Patches

(im Rahmen der regulren Revisionen) auf dem neuesten Stand gehalten?
Hinweise: Sicherheitshinweise von SAP werden auf
http://service.sap.com/securitynotes
kommuniziert (Filtern auf Komponente HAN*)
3.2.
Gibt es einen geregelten und dokumentierten Prozess zur Freigabe und Installation von
Patches?
3.3.
Gibt es einen gemeinsam geregelten und dokumentierten Prozess zur Freigabe und
Installation von Patches fr das Betriebssystem und Betriebsystem-Diensten/-Programmen zwischen dem Provider der Appliance und dem Unternehmen?
10.7. PRFPROGRAMM: BERWACHUNG VON SICHERHEITSVER LETZUNGEN UND REGELMSSIGE BERPRFUNG POTENZIELLER
SICHERHEITSSCHWACHSTELLEN DER SAP-HANA-SERVER
NR.
BERWACHUNG VON SICHERHEITSVERLETZUNGEN UND REGELMSSIGE

BERPRFUNG VON SICHERHEITSSCHWACHSTELLEN
1.
Kontrollziel: Sicherheitsrelevante Ereignisse werden protokolliert und berwacht.

Kritische Sicherheitsverste werden nachverfolgt.
Risiko: Kritische Sicherheitsverste oder der Missbrauch von Benutzern werden gar
nicht oder zu spt erkannt, sodass keine Gegenmanahmen eingeleitet werden knnen.
Bei dem Verdacht auf Missbrauch kann im Nachhinein nicht mehr auf automatisch
erfolgte Systemaufzeichnungen zurckgegriffen werden, die zur Aufklrung des
Vorgangs oder Verfolgung der Angreifer dienen knnen.
1.1.
Ist die native SAP-HANA-Datenbank-Protokollierung, das sogenannte Auditing,

aktiviert?
SQL> SELECT KEY, VALUE FROM M_INIFILE_CONTENTS WHERE KEY = 'global_auditing_
state' AND VALUE !='true';
185
186
NR.
BERWACHUNG VON SICHERHEITSVERLETZUNGEN UND REGELMSSIGE

BERPRFUNG VON SICHERHEITSSCHWACHSTELLEN
1.2.
Sind SAP-HANA Protokollierungsvorgaben, sogenannte Audit Policies, definiert und

aktiviert, die festlegen, welche sicherheitsrelevanten Ereignisse durch die Datenbank
protokolliert werden?
SQL> SELECT * FROM "SYS"."AUDIT_POLICIES" WHERE IS_AUDIT_POLICY_ACTIVE='TRUE';
Hinweis: Bei der Prfung ist insbesondere darauf zu achten, dass die Audit Policies
auch aktiviert sind. Bei der Protokollierung des SYSTEM-Benutzers ist zu beachten,
dass eine Protokollierung aller Aktivitten dazu fhrt, dass auch Datenbank-interne
Operationen protokolliert werden, da diese im Kontext des SYSTEM-Benutzers erfolgen.
Dies kann zu einer enormen Anzahl an protokollierten Ereignissen fhren und die
Performance des Systems negativ beeinflussen.
1.3.
Sind die Protokolle vor dem ndernden Zugriff von Datenbankadministratoren

geschtzt?
SQL>SELECT * FROM M_INIFILE_CONTENTS WHERE SECTION=auditing configuration;
Hinweis: Um die Protokolle vor dem ndernden Zugriff zu schtzen, bietet es sich bspw.
an, das SYSLOGPROTOCOL als default_audit_trail_type festzulegen. Wird die HANADatenbanktabelle () als audit_trail_type definiert, kann der ndernde Zugriff durch
Datenbankadministratoren technisch unterbunden werden, indem das Privileg AUDIT_
OPERATOR nicht an den Datenbankadministrator vergeben wird.
1.4.
Sind die Protokolle vor dem ndernden Zugriff von Betriebsadministratoren

geschtzt?
Hinweis: Um die Protokolle vor dem ndernden Zugriff zu schtzen, bietet es sich an,
den syslog an einen zentralen Server zu streamen, der auerhalb des Zugriffsbereichs
der SAP-HANA-Betriebssystemadministratoren liegt (falls das SYSLOGPROTOCOL
berhaupt als ein default_audit_trail_type festgelegt ist).
1.5.
Werden die Protokolle regelmig und nachvollziehbar berwacht?
1.6.
Ist definiert und dokumentiert, was eine Sicherheitsverletzungen darstellt und wie
werden diese identifiziert?
1.7.
Gibt es einen dokumentierten Prozess fr die Behandlung von Sicherheitsverletzungen?
2.
Kontrollziel: Regelmige Sicherheitsprfungen der Datenbank durchfhren,

Sicherheitsschwachstellen identifizieren und kompensierende Manahmen einleiten.
Risiko: Bestehende Sicherheitsschwachstellen in den Systemen werden nicht
erkannt und knnen von Angreifern ausgenutzt werden.
2.1.
Gibt es Vorgaben fr die sichere Konfiguration von SAP-HANA-Servern?

Hinweis: Eine Konfigurations-Checkliste kann dem SAP HANA Security Guide entnommen werden. Auf dieser Liste basiert auch der EarlyWatch-Alert fr SAP HANA.
2.2.
Gibt es einen Prozess der regelmig die Datenbank-Server auf SicherheitsSchwachstellen und Einhaltung auf Konfigurationsvorgaben prft?
2.3.
Gibt es einen geregelten Prozess, zur Einleitung von Gegenmanahmen bei der
Identifikation von Schwachstellen oder Fehlkonfigurationen?
187
DSAG Deutschsprachige SAP Anwendergruppe e.V.

Altrottstrae 34a
69190 Walldorf
Deutschland
Fon: +49 (0) 6227 358 09 58
Fax: +49 (0) 6227 358 09 59
www.dsag.de I [email protected]
DSAG e.V.

DSAG Prüfleitfaden ECC 6 - Neu

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

DSAG Prüfleitfaden ECC 6 - Neu

Hochgeladen von

Copyright:

Verfügbare Formate

Prfleitfaden SAP ERP 6.

Prfleitfaden SAP ERP 6.0

COPYRIGHT 2015 DSAG E.V.

2. PRFERROLLE, BESTANDSAUFNAHME VON SAP-SYSTEM-

2.1. Grundlagen zur Erstellung einer Prferrolle

3. IDENTIFIKATION UND AUTHENTISIERUNG (ABAP-STACK)

5. SYSTEMINTEGRITT AUF DER ANWENDUNGSEBENE

5.1. Prfprogramm: Schutz der Batch-Input-Prozesse

6. SYSTEMINTEGRITT MIT DEM SAP JAVA-STACK

7.1. Interne und externe Anforderungen

8. SYSTEMINTEGRITT AUF DER BETRIEBSSYSTEMEBENE

8.1. Interne und externe Anforderungen

9. RISIKEN AUS DEM EINSATZ VON SAP GRC

10. SAP HANA AUS REVISIONSSICHT

HINWEISE ZUR HANDHABUNG DES LEITFADENS:

DIE AUTOREN DER BISHER VERFFENTLICHTEN KAPITEL:

Deloitte & Touche GmbH

BERSICHT DER VERFFENTLICHTEN KAPITEL:

SAP ERP 6.0

Prferrolle, Bestandsaufnahme von

Identifikation und Authentisierung (ABAPStack)

Siegfried Filla, Johannes

Prfprogramm: Schutz der BatchInput-Prozesse

Systemintegritt mit dem SAP Java-Stack

Systemintegritt auf der Datenbankebene

Systemintegritt auf der Betriebssystemebene

Risiken und Prfung von SAP GRC

Murat Bc, Martin Metz

SAP HANA aus Revisionssicht

@ Copyright 2015 DSAG e. V.

1. SAP ERP 6.0

2.1. GRUNDLAGEN ZUR ERSTELLUNG EINER PRFERROLLE

2.2. BESTANDSAUFNAHME DER SAP-SYSTEMLANDSCHAFT

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

Gibt es eine bersicht ber alle eingesetzten SAP-Systeme, SAP-Anwendungen

Auf welchen Betriebssystemen laufen die SAP-Systeme?

Welche Datenbanken untersttzen die SAP-Anwendungen?

Gibt es eine bersicht ber verschlsselte Netzverbindungen?

2.3. BESTANDSAUFNAHME DER RICHTLINIEN DES UNTERNEHMENS

UNTERNEHMENSINTERNE RICHTLINIEN UND IT-PROZESSDOKUMENTATION

Aktuelles, gltiges Berechtigungskonzept?

Identifikation von Benutzern?

Vorgaben zum Passwortschutz?

Festgelegte Zustndigkeiten und Rollen bei der Berechtigungsvergabe?

Zustndigkeiten und Aufgaben der Dateneigentmer sowie der Systembetreiber?

SAP Client am Arbeitsplatz (PC, Notebook)

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

Prozessdokumentationen fr die SAP-Anwendungs- und Systemlandschaft

Betrieb und berwachung?

Change- und Konfigurationsmanagement?

Benutzer- und Berechtigungsverwaltung?

Business Continuity Management?

User Help Desk?

3. IDENTIFIKATION UND AUTHENTISIERUNG

3.4. PRFPROGRAMM: SYSTEMPARAMETER FR DIE ANMELDEKONTROLLE

SYSTEMPARAMETER FR DIE ANMELDEKONTROLLE

Kontrollziel: Die Bildung des Kennworts unterliegt Komplexittsregeln.

Die Kennwortmindestlnge login/ min_password_lng ist festgelegt.

Das Kennwort unterliegt Bildungsregeln.

Die Gre der Passworthistorie ist vorbesetzt, login/ password_history_size.

In der Tabelle USR40 sind unzulssige Kennwrter eingetragen.

SYSTEMPARAMETER FR DIE ANMELDEKONTROLLE

Kontrollziel: Die Gltigkeitsdauer eines Kennworts ist beschrnkt.