Deutschsprachige SAP-Anwendergruppe e.V.

SAP® GRC Access Control 10.0 Best-Practice-Leitfaden

zur Einführung der SAP-GRC-Lösungen

VERSION 1.0 STAND 27. APRIL 2015

2

SAP® GRC Access Control 10.0 Best-Practice-Leitfadenzur Einführung der SAP-GRC-Lösungen

VERSION 1.0STAND 27. APRIL 2015

DSAG e. V.Deutschsprachige SAP-Anwendergruppe

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

3

© COPYRIGHT 2015 DSAG E.V.

HINWEIS:Die vorliegende Publikation ist urheberrechtlich geschützt (Copyright). Alle Rechte liegen, soweit nicht ausdrücklich anders gekennzeichnet, bei:

DEUTSCHSPRACHIGE SAP® ANWENDERGRUPPE E.V.Altrottstraße 34 a69190 WalldorfDeutschlandFon +49 (0) 6227 – 358 09 58Fax +49 (0) 6227 – 358 09 59 www.dsag.de I info@dsag.de

Jede Verwertung außerhalb der engen Grenzen des Urheberrechts ist ohne Zustimmung der Urheber unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen / digitalen Medien.

Die Autoren des vorliegenden Best-Practice-Leitfadens sind für Verbesserungs- sowie Änderungs- und Ergänzungswünsche dankbar. Dies gilt sowohl für Vorschläge zur Vertiefung der einzelnen Kapitel als auch für die Nennung von Beispielen aus konkreten Projekt- oder Prüfungserfahrungen.

Die Autoren des Prüfleitfadens sind für Kritik, Änderungs- und Ergänzungswünsche dankbar (bitte als Beitrag im DSAGNet unter „Arbeitsgruppe GRC“ veröffentlichen).

Wir weisen ausdrücklich darauf hin, dass das vorliegende Dokument nicht jeglichen Regelungs-bedarf sämtlicher DSAG-Mitglieder in allen Geschäftsszenarien antizipieren und abdecken kann. Insofern müssen die angesprochenen Themen und Anregungen naturgemäß unvollständig bleiben. Die DSAG und die beteiligten Autoren können bezüglich der Vollständigkeit und Erfolgsgeeignetheit der Anregungen keine Verantwortung übernehmen. Sämtliche Überlegungen, Vorgehensweisen und Maßnahmen hinsichtlich des Verhaltens gegenüber SAP verbleiben in der individuellen Eigen-verantwortung jedes DSAG-Mitglieds. Insbesondere kann dieser Leitfaden nur allgemeine Anhalts-punkte zu vertragsrechtlichen Themen geben und keinesfalls eine individuelle Rechtsberatung bei der Verhandlung und Gestaltung von Verträgen durch IT-rechtliche Experten ersetzen.

4

INHALTSVERZEICHNIS

1. EINLEITUNG 7 2. ÜBERBLICK 8

3. GRC IM REGULATORISCHEN UMFELD 11 3.1. Deutscher Corporate Governance Kodex 12 3.2. Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) 13 3.3. IDW RS FAIT 1 14 3.4. IDW RS FAIT 2 15 3.5. IDW RS FAIT 3 16 3.6. IDW Prüfungsstandard PS 261 n.F. (u.a. internes Kontrollsystem) 16 3.7 IDW PS 330 18 3.8 IDW PS 980 19 3.9 Bundesdatenschutzgesetz (BDSG) 20 3.10 Bilanzrechtsmodernisierungsgesetz (BilMoG) 21 3.10.1 Lagebericht (§§ 289, 315 HGB n.F.) 21 3.10.2 Pflichten des Aufsichtsrates 21 3.10.3 Handlungsfelder für den Vorstand 22 3.11 Basel II 23 3.12 Basel III 24 3.13 Sarbanes-Oxley Act (SOX) 24 3.14 Normen (DIN ISO/IEC) 25 3.14.1 ISO/IEC 27001 25 3.14.2 ISO 27002 (vorher ISO 17799) 25 3.14.3 ISO 27005 25 3.14.4 Weitere Standards der ISO 2700x Reihe 25 3.14.5 Zertifizierung nach ISO 27001 auf Basis von IT-Grundschutz 26

4. RAHMENBEDINGUNGEN FÜR EIN ERFOLGREICHES GRC-PROJEKT 27 4.1 Zugriffsschutz ist Chefsache 27 4.1.1 Mittelstand 27 4.1.2 Großunternehmen / Konzerne 28 4.2 Motivation zum Einsatz von SAP GRC Access Control 30 4.3 Rahmenbedingungen / Erfolgsfaktoren 32 4.3.1 Top-Management 32 4.3.2 Betriebsrat 32 4.3.3 Wirtschaftsprüfer 33 4.3.4 Interne Revision 33 4.3.5 Internal Control / Risk Management 33 4.3.6 Compliance Officer 33 4.3.7 SAP-Basisbetreuung 34 4.3.8 SAP-Berechtigungsadministratoren 34 4.3.9 Organisationsabteilung 34 4.3.10 Schlüsselpersonen aus den Fachbereichen 35 4.3.11 Endanwender 35

5 FUNKTIONALER UND TECHNOLOGISCHER VERGLEICH ZU SAP GRC ACCESS CONTROL 5.3 36 5.1 Komponentenstruktur und Namensgebung 36 5.2 Neue technologische Plattform 38 5.3 Vereinheitlichte Stammdaten, Architektur (auch bzgl. Process Control etc.) 39 5.4 Funktionale Änderungen und Erweiterungen 40 5.5 Bewertung 42

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

5

INHALTSVERZEICHNISINHALTSVERZEICHNIS

6 EINFÜHRUNGSMANAGEMENT (ROLLOUT INKL. USERTRAINING) 43 6.1 PHASE: Projektvorbereitung („Strategie & Planung“) 44 6.1.1 Risikobasiertes Berechtigungsmanagement 44 6.1.2 Abgrenzung von Verantwortungsbereichen 45 6.1.3 Change Management Policy + Risikopolicy 48 6.1.4 Reporting / Monitoring 50 6.1.4.1 Reporting der Risikoanalyse 51 6.1.4.2 Berichte der Zugriffsanforderung 51 6.1.4.3 EAM-Verwaltungsberichte 51 6.1.5 Operative Einzelaufgaben und Projektplanung 51 6.2 PHASE Sollkonzeption („Business Blueprint und Design“) 57 6.2.1 Organisatorisch/technischer Betrieb 57 6.2.2 Architektur & Technologie: 58 6.2.2.1 Harmonisierte Konfigurations- und Stammdatenverwaltung 59 6.2.2.2 Vereinheitlichtes User Interface & Bedienung 59 6.2.3 Risikoanalyse und Bereinigung 59 6.2.4 Unternehmensweites Rollenkonzept 61 6.2.4.1 Gesetzeskonformes Benutzermanagement (User Lifecycle Management) 66 6.2.5 Notfallzugriff (Emergency Access Management) 66 6.2.6 Testvorbereitung für alle Komponenten 68 6.2.6.1 Festlegung der Testskripte 71 6.3 PHASE Realisierung („Implementierung“) 72 6.3.1 Architektur & Technologie 72 6.3.2 Risikoanalyse und Bereinigung 72 6.3.3 Unternehmensweites Rollenkonzept 73 6.3.4 Notfallzugriff (Emergency Access Management) 74 6.3.5 Testdurchführung 75 6.3.6 Fachbereichs-Training 76 6.4 PHASE Produktionsvorbereitung („Rollout“) 78 6.5 PHASE Produktivstart („Support“) 79 6.6 Implementierungsszenario 80

7 WEITERFÜHRENDE DOKUMENTATION 82

8 PRAXISBERICHT THYSSENKRUPP AG 83

9 ANHANG: 88 9.1 Migration von SAP GRC Access Control 5.3 88 9.2 Integration GRC Access Control/Identity Management 91 9.3 Ausblick SAP GRC Access Control 10.1 98 9.4 Dezentrales Notfallbenutzerverfahren, Aufnahme des DBTABLOGs 102 9.5 Funktionen für HANA-Applikationen 102

6

ABBILDUNGSVERZEICHNIS:

Abbildung 1: Die GRC 10.0 Anwendungslandschaft 8Abbildung 2: SAP GRC Access Control Applikationen 9Abbildung 3: SAP GRC Access Control Komponenten 10Abbildung 4: Elemente des internen Kontrollsystems 17Abbildung 5: Einstiegsbild GRC Access Control 37Abbildung 6: Customizing mit dem SAP Implementation Guide 39Abbildung 7: Anforderungen an ein Berechtigungssystem 52Abbildung 8: Aggregierung von Einzelrollen zu Sammelrollen (Arbeitsplätze) 65Abbildung 9: Beispiel Testskript 70Abbildung 10: Fehlerklassifizierung 75Abbildung 11: Zielarchitektur einer zentralen Risikoanalyseplattform mit dezentralen Teams in den lokalen Einheiten 84Abbildung 12: Vorgehen zum Aufbau des GRC Access Control Competence Centers – Zusammenarbeit mit Piloten 84Abbildung 13: Programmplanung mit Pilotunternehmen 85Abbildung 14: Datenmigrationsapplikation in AC5.3 SP13 (Java) 88Abbildung 15: Integrationsbild der verschiedenen Funktionen von SAP GRC Access Control und einem Identity Management-System am Beispiel SAP NetWeaver Identity Management 92Abbildung 16: Sandwich-Architektur 94Abbildung 17: Beispiel einer Tail-Architektur 95Abbildung 18: Beispiel für ein einblendbares Side-Panel 98Abbildung 19: Vereinfachter Antrag 100Abbildung 20: Root Cause Analysis mit Drill-Down hinunter auf Berechtigungswerebene und Simluation eines Rollenentzugs 101Abbildung 21: Beispiel einer Risikoanalyse von HANA-Privilegien 102

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

7

1. EINLEITUNG

Aufgrund der umfangreichen Neuerungen bei SAP GRC Access Control 10.0 war es notwendig, den DSAG Best-Practice-Leitfaden zu GRC Access Control 5.3 umfassend zu aktualisieren.

Dieser Leitfaden geht auf die einzelnen Komponenten von SAP GRC Access Control ein und stellt insbesondere die Möglichkeiten zur Einführung innerhalb der Unternehmensorganisation einschließ-lich des hierfür erforderlichen Projektmanagements im Sinne von Best-Practice-Empfehlungen vor.

Die Best-Practice-Empfehlungen erheben keinen Anspruch auf Vollständigkeit, sondern geben die Projekt- und Praxiserfahrung der Autoren wieder. Insofern ist das Autorenteam auch dankbar für jede Art von Anregungen und Hinweisen zur weiteren Vervollständigung und Verbesserung des Leitfadens.

Dieser Leitfaden soll insbesondere den Unternehmen eine Hilfestellung bieten, die sich mit ver-schiedensten Anforderungen gesetzlicher, fachlicher und organisatorischer Art bei der Gestaltung der Zugriffskontrollen auf ihre Programme und Daten konfrontiert sehen. Hinzuweisen ist hier insbesondere auf die Anforderungen des Bilanzrechtmodernisierungsgesetzes (BilMoG) mit der Gestaltung und Überwachung von internen Kontroll- und Risikomanagementsystemen, die Min-destanforderungen an das Risikomanagement von Finanzinstituten und Versicherungen (MaRisk) sowie generell auf Anforderungen eines modernen Compliance Managements bei der Sicherstel-lung von wirksamen Funktionstrennungsprinzipien innerhalb der Unternehmensorganisation.

Die Autoren sind Mitglieder der Arbeitsgruppe Governance, Risk Management, Compliance (GRC - www.dsag.de/AG-GRC) innerhalb des DSAG-Arbeitskreises "Revision/Risikomanagement (www.dsag.de/AK-Revision). Die Verantwortung für den Inhalt tragen die Autoren. Die redaktionelle Bearbeitung und das Layout liegen bei der DSAG.

@ Copyright 2015 der Autoren:

› Siegfried Filla PricewaterhouseCoopers AG WPG

› Marco Geisenberger Protiviti GmbH

› Rolf-Udo Gilbert dobis GmbH & Co. KG

› Markus Griem SAP Deutschland SE & Co. KG

› Matthias Middrup ThyssenKrupp AG

› Birger Tödtmann SAP Deutschland SE & Co. KG

› Dr. Alexander Ziesemer ThyssenKrupp AG

ABBILDUNGSVERZEICHNIS:

8

SAP hat die Standardsoftwarelösungen für Governance, Risk Management und Compliance (GRC) in der SAP GRC Suite gebündelt (siehe Abb. 1).

2. ÜBERBLICK

Abbildung 1: Die GRC 10.0 Anwendungslandschaft

Die GRC-Suite der SAP umfasst Anwendungen zur Sicherstellung einer unternehmensweiten Governance. Sie sollen die Zugriffssicherheit der Unternehmensdaten verbessern, Risiken der Geschäftstätigkeit besser erkennen und steuern sowie alle Voraussetzungen zur Erreichung einer unternehmensweiten Governance und Compliance schaffen.

Die GRC-Suite umfasst folgende Applikationen:› SAP Access Control› SAP Access Approver Mobile App› SAP Global Trade Services› SAP Process Control› Mobile App SAP GRC Policy Survey› SAP Risk Management› SAP Environment, Health & Safety Management› SAP Sustainability Performance Management

Recommended for GTS/SPL

Required for GTS

Required for Nota Fiscal E.

optional

SAP NetWeaver 7.02 Search/Classification

GRC Search

SAP NW7.02Adobe Document

Services

SAP NetWeaver PI

Nota Fiscal Content

Identity Management Solutions

(SAP or Non-SAP) SAP GRC Suite 10.0

AC, PC & RM (Software Component: GRCFND_A)

GTS (Software Component: SLL-LEG)

Nota Fiscal Eletronica (Software Component: SLL-NFE)

Content Lifecycle Management (CLM)

SAP NetWeaver AS ABAP 7.02

Front End Client

Adobe Flash Player

SAP GUI 7.10

Web Browser CRA*

optional

optional

optional

SAP NetWeaver 7.02 Search/Classification

GRC Search

SAP ERP (4.6C – 7.1)

NW Fuction Modules (Plug-in: GRCPINW)

HR Function Modules PC Automated Cntris Plug-in: GRCPIERP)

GTS Plug-in (Plug-in: SLL-PI)

Non-SAP Business Applications

optional

SAP NW Portal 7.02

GRC Portal Content

RFC

RFC

RFC

RFC

RFC

http

webservices Adapter

http DIAG

*Crystal Reports Adapter and Active Component Framework – needed for viewing GRC Crystal Reports

GRC 10.0 Landscape Synopsis

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

9

Abbildung 2: SAP GRC Access Control Applikationen

SAP GRC Access Control ermöglicht eine präventive Zugriffskontrolle zur Sicherstellung der Funk-tionstrennung in SAP- und Non-SAP-Systemen (z.B. Oracle und PeopleSoft). Kritische Berechtigun-gen können rasch entdeckt und eingeschränkt bzw. kontrolliert werden. Darüber hinaus wird ein standardisiertes und transparentes Berechtigungsmanagement unterstützt. Mit dieser Anwendung kann somit eine ordnungsmäßige und sichere Zugriffskontrolle organisiert werden, wobei die nach-folgend aufgeführten Module zunehmend integriert eingesetzt werden:

SAP GRC Access Control 10.0 ist mit den einzelnen Komponenten in der folgenden Abbildung dargestellt.

optional

optional

optional

SAP NetWeaver BI 7.06 (target)

GRC BI Content

SAP NetWeaver AS JAVA 7.02

Adobe Document Server

SAP NetWeaver 7.02 Search/Classification

SAP NetWeaver PI

GRC Search

Nota Fiscal Content SAP GRC Application 10.0

AC, PC & RM (Software Component: GRCFND_A)

Global Trade Services (Software Component: SLL-LEG)

Nota Fiscal Eletronica (Software Component: SLL-NFE)

Content Lifecycle Management (Software Comonent: POASBC)

SAP NetWeaver AS ABAP 7.02

Front End Client

Adobe Flash Player

SAP GUI 7.10

Web Browser

NWBC 3.0

optional

optional

SAP ERP (4.6C – ECC 6.0)

NW Fuction Modules (Plug-in: GRCPINW)

HR Function Modules PC Automated Ctris Plug-in: GRCPIERP)

GTS Plug-in (Plug-in: SLL-PI)

Non-SAP Business Applications

optional

SAP NW Portal 7.02

GRC Portal Content (Business Package)

Nota Fiscal Eletronica (eSignature)

Content Lifesycle Management (CLM)

RFC

RFC

RFC

http

Adapter

http DIAG

10

Die folgende Abbildung zeigt eine Übersicht der Kernelemente von SAP GRC Access Control im Zeitablauf der verschiedenen SAP-Lösungen:

Abbildung 3: SAP GRC Access Control Komponenten

› Access Risk Analysis (ARA) Diese Software unterstützt eine sog. „Real-Time Compliance“ mit dem Ziel, Sicherheits- und Kontrollverletzungen zu verhindern, bevor sie auftreten. Grundlage ist eine Bibliothek mit Funk- tionstrennungsregeln (segregation of duties) für SAP und zum Teil auch Non-SAP Systeme.Durch einen sog. „Audit Trail“ und verbesserte Optionen zur Risikominimierung will man schnellere und effizientere Reaktionen der Kontrollinstanzen ermöglichen.

› Emergency Access Management (EAM) Das Notfalluser-Management kann zentral durchgeführt werden. Mittels eines standardisierten Workflows können die Logeinträge der Notfalluser-Aktivitäten kontrolliert werden.

› Access Request Management (ARM) Ermöglicht eine ordnungsmäßige Benutzeradministration mit automatisierten Antrags- und Genehmigungsprozessen innerhalb einer Real-Time-Risikoüberwachung.

› Business Role Management(BRM) BRM ermöglicht ein standardisiertes, unternehmensweites Rollenmanagement. Geschäfts- prozess-Owner können funktionale Rollen vorgeben, die dann von der IT-Benutzeradministration technisch umgesetzt werden können. Der gesamte Änderungsdienst wird aufgezeichnet und ist prüfbar.

VIRSA/SAP (2005) GRC Access Control 5.3 GRC Access Control 10.0

Compliance Calibrator Risk Analysis and Remediation (RAR)

Access Risk Analysis (ARA)

Firefighter Superuser Privilege Management (SPM)

Emergency Access Management (EAM)

Access Enforcer Compliant User Provisioning (CUP)

Access Request Management (ARM)

Role Expert Enterprise Role Management (ERM)

Business Role Management (BRM)

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

11

3. GRC IM REGULATORISCHEN UMFELD

In Deutschland haben sich Gesetzgeber, das Institut der Wirtschaftsprüfer in Deutschland (IDW) sowie das DRSC schon seit vielen Jahren mit den Themen Governance, Risk Management und Compliance beschäftigt. Hervorzuheben sind dabei die Regelungen zum Deutschen Corporate Governance Kodex1, zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG2), zum internen Kontrollsystem von Unternehmen3 und zum Bilanzrechtsmodernisierungsgesetz (BilMoG4)

Den Maßstab für die Umsetzung regulatorischer Anforderungen in deutschen Unternehmen bilden im Rahmen der Prüfung der Finanzberichterstattung durch Wirtschaftsprüfer im Wesentlichen folgende gesetzliche Regelungen und Prüfungsstandards des Instituts der Wirtschaftsprüfer (IDW):

› die handels- und steuerrechtlichen Vorschriften zur Ordnungsmäßigkeit der Buchführung (§§ 238 f. und 257 HGB sowie §§ 145 bis 147 AO),

› die IDW-Stellungnahme zur Rechnungslegung „Grundsätze ordnungsmäßiger Buchführung bei Einsatz von Informationstechnologie“ (IDW RS FAIT 1, Stand: 24. September 2002),

› die IDW-Stellungnahme zur Rechnungslegung „Grundsätze ordnungsmäßiger Buchführung bei Einsatz von Electronic Commerce“ (IDW RS FAIT 2, Stand: 29. September 2003)

› der IDW Prüfungsstandard „Feststellung und Beurteilung von Fehlerrisiken und Reaktionen des Abschlussprüfers auf die beurteilten Fehlerrisiken“ (IDW PS 261 n.F., Stand 01.03.2012),

› der IDW-Prüfungsstandard zur „Abschlussprüfung bei Einsatz von Informationstechnologie“ (IDW PS 330, Stand: 24. September 2002) sowie

› die von der Arbeitsgemeinschaft für Wirtschaftliche Verwaltung e.V. erarbeiteten „Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS)“ sowie das dazu ergangene Schreiben des Bundesministers der Finanzen vom 7. November 1995.

Die vorgenannten gesetzlichen Vorschriften und fachlichen Stellungnahmen sind generell zu beach- tende Anforderungen und beziehen sich überwiegend auf rechnungslegungsrelevante Sachverhalte. Gleichwohl sind sie aufgrund gleicher Kontrollziele geeignet, auch Aussagen zur Ordnungsmäßigkeit bei Fragestellungen außerhalb der Buchführung zu treffen.

Darüber hinaus können im Einzelfall weitere Prüfungsstandards anzuwenden sein (z.B. für Dienst-leistungsunternehmen oder Shared Service Center, die administrative Aufgaben u.a. im Bereich der Benutzeradministration und des Zugriffsschutzes übernommen haben (z.B. der IDW-Prüfungs-standard zur „Prüfung des internen Kontrollsystems bei Dienstleistungsunternehmen für auf das Dienstleistungsunternehmen ausgelagerte Funktionen“ (IDW PS 951, Stand: 19. September 2007).

1Deutscher Corporate Governance Kodex (DCGK Juni 2014)2Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) 1. Mai 19983IDW-Prüfungsstandard „Feststellung und Beurteilung von Fehlerrisiken und Reaktionen des Abschlussprüfers auf die

beurteilten Fehlerrisiken“ (IDW PS 261, Stand 6. September 2006). 4Bilanzrechtsmodernisierungsgesetz (BilMoG) vom 25. Mai 2009 (BGBl. I S. 1102)

12

Dieser GRC Best-Practice-Leitfaden möchte lediglich in Kurzform auf wesentliche zu beachtende regulatorische Anforderungen insbesondere in jüngerer Zeit eingehen und erhebt deshalb auch keinen Anspruch auf Vollständigkeit der hier vorgestellten Regelungen. Wer sich intensiver mit diesem Thema beschäftigen möchte kann dies u.a. in folgenden Büchern nachlesen:

› SAP® Access Control, 2008, ISBN 978-3-8362-1141-3› Governance, Risk und Compliance mit SAP, 2008, ISBN 978-3-8362-1140-6› SOX Compliance with SAP Treasury and Risk Management, 2008, ISBN 978-1-59229-200¬4› CobiT und der Sarbanes-Oxley Act, 2007, ISBN 978-3-8362-1013-3› Sicherheit und Berechtigungen in SAP-Systemen, 2005, ISBN 978-3-89842-670-1

Als ergänzende Lektüre empfehlen wir den DSAG-Datenschutzleitfaden SAP ERP 6.0 sowie den Prüfleitfaden SAP ERP 6.0 (beide im Mitgliederportal DSAGNet).

Alle DSAG-Leitfäden finden Sie unter folgendem Link: www.dsag.de/Handlungsempfehlungen

3.1. DEUTSCHER CORPORATE GOVERNANCE KODEX

Die Themen Risikomanagement und Compliance sind im DCGK in folgenden Abschnitten wie folgt angesprochen:

› Abschnitt 3 „Zusammenwirken von Vorstand und Aufsichtsrat“ Der Vorstand informiert den Aufsichtsrat regelmäßig, zeitnah und umfassend über alle für das Unternehmen relevanten Fragen der Planung, der Geschäftsentwicklung, der Risikolage, des Risikomanagements und der Compliance.

› Abschnitt 4 „Vorstand“ Der Vorstand hat für die Einhaltung der gesetzlichen Bestimmungen und der unternehmens- internen Richtlinien zu sorgen und wirkt auf deren Beachtung durch die Konzernunternehmen hin (Compliance). Der Vorstand sorgt für ein angemessenes Risikomanagement und Risikocontrolling im Unter- nehmen.

› Abschnitt 5 „Aufsichtsrat“ Der Aufsichtsratsvorsitzende soll mit dem Vorstand, insbesondere mit dem Vorsitzenden bzw. Sprecher des Vorstands, regelmäßig Kontakt halten und mit ihm Fragen der Strategie, der Planung, der Geschäftsentwicklung, der Risikolage, des Risikomanagements und der Compliance des Unternehmens beraten.

› Abschnitt 5.3 „Bildung von Ausschüssen“ Der Aufsichtsrat soll einen Prüfungsausschuss (Audit Committee) einrichten, der sich ins- besondere mit der Überwachung des Rechnungslegungsprozesses, der Wirksamkeit des internen Kontrollsystems, des Risikomanagementsystems und des internen Revisions- systems, der Abschlussprüfung …… sowie der Compliance, befasst.

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

13

3.2. GESETZ ZUR KONTROLLE UND TRANSPARENZ IM UNTERNEHMENS- BEREICH (KONTRAG)

Kern des KonTraG ist eine Vorschrift, die Unternehmensleitungen dazu zwingt, ein unternehmens- weites Früherkennungssystem für Risiken (Risikofrüherkennungssystem) einzuführen und zu be-treiben sowie Aussagen zu Risiken und zur Risikostruktur des Unternehmens im Lagebericht des Jahresabschlusses der Gesellschaft zu veröffentlichen.

Die Einrichtung eines Risikomanagementsystems (RMS) ist unmittelbar nur für Aktiengesellschaften gesetzlich vorgeschrieben. Das RMS muss demnach gewährleisten, dass die das Unternehmen möglichen bedrohenden Risiken vollständig erfasst (KonTraG – Erfassung der Risiken), beherrscht und gesteuert werden. Dies heißt konkret, dass das RMS Maßnahmen festlegen muss, die eine effiziente Identifikation, Analyse und Bewertung der Risiken ermöglichen (Risikostrategie).

Schließlich lässt sich hieraus die weitere inhaltliche Anforderung ableiten, dass es einer unterstüt-zenden zielorientierten Koordination von Risikostrategie, Informationsversorgung, Überwachung und Steuerung durch ein Controlling oder spezieller ein sog. „Risikocontrolling“ bedarf, denn dies bildet eine unabdingbare Voraussetzung für die Errichtung und Erhaltung der Reaktionsfähigkeit und Koordinationsfähigkeit des Unternehmens und ist daher als Element eines Risikomanagement-systems und eines Überwachungssystems unverzichtbar.

5 IDW-Stellungnahme zur Rechnungslegung „Grundsätze ordnungsmäßiger Buchführung bei Einsatz von

Informationstechnologie“ (IDW RS FAIT 1, Stand: 24. September 2002).

14

3.3. IDW RS FAIT 15

IDW RS FAIT 1 definiert u.a. Sicherheitsanforderungen an rechnungslegungsrelevante Daten. Im Einzelnen werden gefordert:

IT-Systeme haben daher die folgenden Sicherheitsanforderungen zu erfüllen:

› Vertraulichkeit verlangt, dass von Dritten erlangte Daten nicht unberechtigt weitergegeben oder veröffentlicht werden. Organisatorische und technische Maßnahmen – wie bspw. Verschlüsse- lungstechniken – umfassen u.a. Anweisungen zur Beschränkung der Übermittlung personen- bezogener Daten an Dritte, die verschlüsselte Übermittlung von Daten an berechtigte Dritte, die eindeutige Identifizierung und Verifizierung des Empfängers von Daten oder die Einhaltung von Löschfristen gespeicherter personenbezogener Daten.

› Integrität von IT-Systemen ist gegeben, wenn die Daten und die IT-Infrastruktur sowie die IT- Anwendungen vollständig und richtig zur Verfügung stehen und vor Manipulation und ungewollten oder fehlerhaften Änderungen geschützt sind. Organisatorische Maßnahmen sind geeignete Test- und Freigabeverfahren. Technische Maßnahmen sind z.B. Firewalls und Virenscanner. Die Ord- nungsmäßigkeit der IT-gestützten Rechnungslegung setzt voraus, dass neben den Daten und IT-Anwendungen auch die IT-Infrastruktur nur in einem festgelegten Zustand eingesetzt wird und nur autorisierte Änderungen zugelassen werden.

› Verfügbarkeit verlangt zum einen, dass das Unternehmen zur Aufrechterhaltung des Geschäfts- betriebs die ständige Verfügbarkeit der IT-Infrastruktur, der IT-Anwendungen sowie der Daten gewährleistet. Zum anderen müssen die IT-Infrastruktur, die IT-Anwendungen und Daten sowie die erforderliche IT-Organisation in angemessener Zeit funktionsfähig bereitstehen. Daher sind z.B. geeignete Back-up-Verfahren zur Notfallvorsorge einzurichten. Maßnahmen zur Sicherung der Verfügbarkeit sind erforderlich, um den Anforderungen nach Lesbarmachung der Buchfüh- rung gerecht zu werden.

› Autorisierung bedeutet, dass nur im Voraus festgelegte Personen auf Daten zugreifen können (autorisierte Personen) und dass nur sie die für das System definierten Rechte wahrnehmen können. Diese Rechte betreffen das Lesen, Anlegen, Ändern und Löschen von Daten oder die Administration eines IT-Systems. Dadurch soll ausschließlich die genehmigte Abbildung von Geschäftsvorfällen im System gewährleistet werden. Geeignete Verfahren hierfür sind physische und logische Zugriffsschutzmaßnahmen (z.B. Passwortschutz). Organisatorische Regelungen und technische Systeme zum Zugriffsschutz sind die Voraussetzung zur Umsetzung der erfor- derlichen Funktionstrennungen. Neben Identitätskarten werden zukünftig biometrische Zugriffsgenehmigungsverfahren an Bedeutung gewinnen.

5 IDW-Stellungnahme zur Rechnungslegung „Grundsätze ordnungsmäßiger Buchführung bei Einsatz von Informationstech-

nologie“ (IDW RS FAIT 1, Stand: 24. September 2002).

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

15

› Authentizität ist gegeben, wenn ein Geschäftsvorfall einem Verursacher eindeutig zuzuordnen ist. Dies kann bspw. über Berechtigungsverfahren geschehen. Beim elektronischen Datenaustausch bieten sich für eine Identifizierung des Partners bspw. digitale Signatur- oder passwortgestützte Identifikationsverfahren an.

› Unter Verbindlichkeit wird die Eigenschaft von IT-gestützten Verfahren verstanden, gewollte Rechtsfolgen bindend herbeizuführen. Transaktionen dürfen durch den Veranlasser nicht abstreitbar sein, weil bspw. der Geschäftsvorfall nicht gewollt ist.

3.4. IDW RS FAIT 26

Risiken können sich innerhalb des E-Commerce insbesondere aus der fehlenden Kontrolle über den Datentransfer im Internet ergeben:

› Unzureichender Schutz vor Verfälschung (Verlust der Integrität)› Unsichere Datenverschlüsselung (Verlust der Vertraulichkeit)› Gefährdung der Verfügbarkeit (Verlust der Verfügbarkeit)› Unwirksame Authentisierungsmechanismen (Verlust der Authentizität)› Unauthorisierte Zugriffe mit Hilfsprogrammen (Verlust der Autorisierung)› Unzureichende Protokollierung der Transaktionsdaten (Verlust der Verbindlichkeit)

Mangelnde Authentizität und Autorisierung bewirken bspw., dass Geschäftsvorfälle inhaltlich un- zutreffend abgebildet werden (Verletzung des Grundsatzes der Richtigkeit). Die Autorisierung soll insbesondere sicherstellen, dass keine unberechtigten bzw. keine fiktiven Geschäftsvorfälle in das System eingehen. Es ist festzulegen, wann, wie und durch wen die Autorisierung erfolgt.

Autorisierungsverfahren sind Teil der Verfahrensdokumentation und für zehn Geschäftsjahre auf- bewahrungspflichtig.

Im Rahmen des durch den Anwender zu erstellenden Sicherheitskonzeptes sind auch für E-Com-merce- Anwendungen Sicherungsmaßnahmen abzuleiten, die physische Sicherungsmaßnahmen und logische Zugriffskontrollen sowie Datensicherungs- und Auslagerungsvefahren umfassen.

6IDW-Stellungnahme zur Rechnungslegung „Grundsätze ordnungsmäßiger Buchführung bei Einsatz von Informations-

technologie“ (IDW RS FAIT 1, Stand: 24. September 2002).

16

3.5 IDW RS FAIT 37

Diese IDW Stellungnahme zur Rechnungslegung konkretisiert die aus § 257 HGB resultierenden Anforderungen an die Archivierung aufbewahrungspflichtiger Unterlagen und veranschaulicht die in der IDW Stellungnahme zur Rechnungslegung: Grundsätze ordnungsmäßiger Buchführung beim Einsatz von Informationstechnologie (IDW RS FAIT 1, Tz. 60 ff.)2 dargestellten Aufbewahrungs-pflichten beim Einsatz von elektronischen Archivierungssystemen.

Technische und organisatorische Risiken aus dem Einsatz von Archivierungsverfahren können die Sicherheit und Ordnungsmäßigkeit der Rechnungslegung beeinträchtigen:

› Unzureichende organisatorische Festlegungen und Verfahrensanweisungen können die Nach- vollziehbarkeit und Anwendbarkeit der Archivierungsverfahren gefährden.› Mangelhafte Zugriffskontrollen innerhalb des Archivierungssystems ermöglichen die miss- bräuchliche oder unauthorisierte Einsichtnahme der archivierten Dokumente und Daten.

› Durch Veränderungen, Manipulationen oder Löschung der archivierten Daten und Dokumente wird deren Integrität, Authentizität oder Verfügbarkeit verletzt.

3.6 IDW PRÜFUNGSSTANDARD PS 261 N.F. (U.A. INTERNES KONTROLLSYSTEM)

Der vorgenannte Prüfungsstandard wurde am 01.03.2012 verabschiedet und ersetzt den IDW Prüfungsstandard 261 „Feststellung und Beurteilung von Fehlerrisiken und Reaktionen des Abschlussprüfers auf die beurteilten Fehlerrisiken“ (IDW PS 261) i.d.F. vom 09.09.2009.

Gem. IDW PS 261 n.F. werden unter einem internen Kontrollsystem die vom „Management im Unternehmen eingeführten Grundsätze, Verfahren und Maßnahmen (Regelungen) verstanden, die gerichtet sind auf die organisatorische Umsetzung der Entscheidungen des Managements

› zur Sicherung der Wirksamkeit und Wirtschaftlichkeit der Geschäftstätigkeit (hierzu gehört auch der Schutz des Vermögens, einschließlich der Verhinderung und Aufdeckung von Vermögens- schädigungen),› zur Ordnungsmäßigkeit und Verlässlichkeit der internen und externen Rechnungslegung sowie › zur Einhaltung der für das Unternehmen maßgeblichen rechtlichen Vorschriften.“8

7IDW Stellungnahme zur Rechnungslegung: Grundsätze ordnungsmäßiger Buchführung beim Einsatz elektronischer

Archivierungsverfahren (IDW RS FAIT 3) 8 IDW PS 261 n.F., Tz. 19

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

17

9 IDW PS 261 n.F., Tz. 20

Als organisatorische Sicherungsmaßnahmen sind z.B. definiert „laufende, automatische Einrich-tungen… Sie umfassen fehlerverhindernde Maßnahmen, die sowohl in die Aufbau- als auch die Ablauforganisation eines Unternehmens integriert sind und ein vorgegebenes Sicherheitsniveau gewährleisten sollen (z.B. Funktionstrennung, Zugriffsbeschränkungen im IT-Bereich, Zahlungs-richtlinien).“9

Damit sind u.a. alle im Rahmen von Zugriffsberechtigungen getroffenen Maßnahmen Teil des internen Kontrollsystems und damit auch wesentlicher Bestandteil der Umsetzung der Compliance-Anfor-derungen durch das Management eines Unternehmens.

Abbildung 4: Elemente des internen Kontrollsystems

Die Regelungsbereiche des internen Kontrollsystems werden lt. IDW PS 261 n.F. wie folgt definiert:Neben den o.g. organisatorischen Sicherungsmaßnahmen sind auch Kontrollen prozessintegrierte Überwachungsmaßnahmen, wie z.B. die Überprüfung der Vollständigkeit und Richtigkeit verarbeite-ter Daten (u.a. Änderungen von Berechtigungen und Benutzerprofilen).

Internes Kontrollsystem(IKS)

Internes Überwachungssystem

Prozessunabhängige Überwachungsmaßnahmen

Prozessintegrierte Überwachungsmaßnahmen

Organisatorische Sicherungsmaß-

nahmen Kontrollen

Interne Revision Sonstige

Internes Steuerungssystem

18

3.7 IDW PS 33010

Dieser Prüfungsstandard beschäftigt sich im Wesentlichen mit den Anforderungen an ordnungs-mäßige und sichere Rechnungslegungssysteme und der Sicherstellung der Vollständigkeit, Richtig-keit, der in diesen System erfassten, verarbeiteten und ausgegebenen Daten.

In diesem Zusammenhang werden u.a. folgende Risiken des IT-Einsatzes hervorgehoben:

› IT-Anwendungsrisiken (fehlende oder nicht aktuelle Verfahrensregelungen und -beschreibungen, unzureichende Zugriffsberechtigungskonzepte und Zugriffskontrollsysteme)

› IT-Geschäftsprozessrisiken (u.a. unzureichende Transparenz der Datenflüsse, unzureichende Integration der Systeme oder mangelhafte Abstimm- und Kontrollverfahren in Schnittstellen zwischen Teilprozessen mit der Gefahr, dass IT-Kontrollen bspw. Zugriffsrechte, Datensiche- rungsmaßnahmen, nur hinsichtlich der Teilprozesse, jedoch nicht hinsichtlich der Gesamt- prozesse wirksam werden.)

› IT-Geschäftsprozessrisiken (u.a. unzureichende Transparenz der Datenflüsse, unzureichende Integration der Systeme oder mangelhafte Abstimm- und Kontrollverfahren in Schnittstellen zwischen Teilprozessen mit der Gefahr, dass IT-Kontrollen bspw. Zugriffsrechte, Datensiche- rungsmaßnahmen, nur hinsichtlich der Teilprozesse, jedoch nicht hinsichtlich der Gesamtpro- zesse wirksam werden.)

Wesentliches Beurteilungsobjekt sind im Hinblick auf SAP GRC Access Control die logischen Zugriffskontrollen.

Logische Zugriffskontrollen sind wesentliche Elemente der Datensicherheit und des Datenschut-zes und Voraussetzung zur Gewährleistung der Vertraulichkeit. Die Sicherheitsanforderungen Autorisierung und Authentizität bedingen zwingend logische Zugriffskontrollen:

› Implementierung eines organisatorischen Verfahrens zur Beantragung, Genehmigung und Einrichtung von Benutzerberechtigungen in IT-Systemen › Berechtigungen auf Betriebssystemebene (Anmeldung gegenüber Rechnern in einem Netzwerk) › Rechte zur Ausführung von Transaktionen in einer IT-Anwendung.

Zugriffskontrollen sind als angemessen zu beurteilen, wenn sie geeignet sind sicherzustellen, dass die Berechtigungsverwaltung und die eingerichteten Systemrechte den Festlegungen im Sicherheits- konzept entsprechen und damit unberechtigte Zugriffe auf Daten sowie Programmabläufe zur Veränderung von Daten ausgeschlossen sind. Zudem müssen Zugriffskontrollen so ausgestaltet sein, dass sie die Identität des Benutzers eindeutig feststellen und nicht autorisierte Zugriffsver-suche abgewiesen werden.

10 IDW-Prüfungsstandard zur „Abschlussprüfung bei Einsatz von Informationstechnologie“

(IDW PS 330, Stand: 24. September 2002)

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

19

3.8 IDW PS 98011

Am 11. März 2011 wurde vom Institut der Wirtschaftsprüfer (IDW) der Prüfungsstandard „Grundsätze ordnungsmäßiger Prüfung von Compliance-Management-Systemen“ verabschiedet. Dieser Standard ist erstmals für Prüfungen anzuwenden, die nach dem 30. September 2011 durchgeführt werden. Dabei handelt es sich um freiwillige Prüfungen, d.h., es besteht derzeit keine Prüfungspflicht. Man kann jedoch davon ausgehen, dass sich zunehmend Unternehmen einer Prüfung ihres CMS unter-ziehen, um zumindest von Aufsichtsrats- oder Vorstandsseite nachzuweisen, dass alle Aufsichts-pflichten erfüllt worden sind und man sich z.B. kein pflichtwidriges Verhalten nach § 93 Absatz 1 AktG vorzuwerfen hat.

Der Prüfungsstandard legt einen einheitlichen Rahmen für Compliance-Management-Systeme (CMS) fest. Damit gibt es jetzt erstmalig in Deutschland ein seitens der Wirtschaftsprüfung definier-tes Rahmenkonzept mit Leitlinien und Vorgaben für Unternehmen, die sich zur Verbesserung ihrer Compliance mit der Einrichtung eines Compliance-Management-Systems oder ähnlichen Strukturen beschäftigen oder dies bereits weitgehend umgesetzt haben. Damit ist davon auszugehen, dass durch diesen Prüfungsstandard auch eine zunehmende Standardisierung der Compliance-Organi-sation erzielt wird und die Compliance-Aufgaben innerhalb der Corporate Governance deutscher Unternehmen wirksam und nachhaltig erfüllt werden können.

Nachfolgend sind einige Kernelemente der Prüfung des Compliance-Management-Systems nach dem Prüfungsstandard IDW PS980 dargestellt.

Audit Compliance-Management (nach IDW PS 980)

› Compliance-Management-System (CMS) ist ein Teilbereich des Risikomanagementsystems (RMS)

› IDW PS 980 ersetzt nicht › die Prüfung des Risikofrüherkennungssystems nach § 317 Abs. 4 HGB (IDW PS 340) › die Beurteilung des Risikomanagements von Kreditinstituten im Rahmen der Abschlussprüfung (IDW EPS 525)

› Auftrags-(Prüfungs-)typen › Prüfung der Konzeption des CMS › Prüfung von Angemessenheit und Implementierung des CMS › Prüfung von Angemessenheit, Implementierung und Wirksamkeit des CMS

› Prüfungsgebiete (Aufbau- und Funktionsprüfung abhängig vom Auftragstyp) › Compliance-Kultur - Grundlagen für die Angemessenheit und Wirksamkeit des CMS - Grundeinstellung und Verhaltensweisen des Managements (Tone from the Top)

11 DW Prüfungsstandard: Grundsätze ordnungsmäßiger Prüfung von Compliance-Management-Systemen

(IDW PS 980, Stand: 11.03.2011)

20

› Compliance-Ziele - Festlegung wesentlicher Ziele, die mit dem CMS erreicht werden sollen - Festlegung wesentlicher Teilbereiche und in den Teilbereichen einzuhaltender Regeln › Compliance-Organisation - Rollen und Verantwortlichkeiten - Aufbau- und Ablauforganisation - Ressourcenplanung › Compliance-Risiken - Identifikation von wesentlichen Compliance-Risiken - Systematische Risikoerkennung mit Risikobeurteilung › Compliance-Programm - Auf Grundlage der identifizierten Risiken werden Grundsätze und Maßnahmen eingeführt, die risikominimierend wirken › Compliance-Kommunikation - Betroffene Mitarbeiter und ggfs. Dritte werden über das Compliance-Programm sowie Rollen/ - Verantwortlichkeiten informiert - Festlegung eines Berichtsweges über identifizierte Risiken, festgestellte Regelverstöße sowie - eingehende Hinweise › Compliance-Überwachung und Verbesserung - Überwachung der Angemessenheit und Wirksamkeit (inkl. Reporting) - Voraussetzung: ausreichende Dokumentation - Management trägt Verantwortung

Mittlerweile gibt es eine ganze Reihe namhafter Unternehmen, die entweder den vorgenannten Standard als Orientierung für die Ausgestaltung ihres Compliance-Management-Systems nutzen oder bereits ihr CMS nach diesem Standard zertifizieren lassen.

3.9 BUNDESDATENSCHUTZGESETZ (BDSG)

Gemäß § 9 BDSG sind zur Sicherstellung des Datenschutzes bei personenbezogenen Daten tech- nische und organisatorische Maßnahmen erforderlich. Hinsichtlich der Zugriffskontrollen wird gefordert, dass die zur Benutzung eines Datenverarbeitungssystems Berechtigten ausschließlich auf die ihrer Zugriffsberechtigung unterliegenden Daten zugreifen können und dass personenbe-zogene Daten bei der Verarbeitung, Nutzung und nach der Speicherung nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können (Zugriffskontrolle).

Ferner ist zu gewährleisten, dass personenbezogene Daten bei der elektronischen Übertragung oder während ihres Transports oder ihrer Speicherung auf Datenträger nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können und dass überprüft und festgestellt werden kann, an welchen Stellen eine Übermittlung personenbezogener Daten durch Einrichtungen zur Daten-übertragung vorgesehen ist (Weitergabekontrolle).

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

21

Gem. Ziff. 5 der Anlage zu § 9 BDSG ist zu gewährleisten, dass nachträglich überprüft und fest-gestellt werden kann, ob und von wem personenbezogene Daten in Datenverarbeitungssysteme eingegeben, verändert oder entfernt worden sind (Eingabekontrolle).

Weiterhin ist lt. Ziff. 7 zu gewährleisten, dass personenbezogene Daten gegen zufällige Zerstörung oder Verlust geschützt sind (Verfügbarkeitskontrolle).

Einzelheiten zum Datenschutz im SAP-Umfeld können Sie im DSAG Datenschutzleitfaden nachlesen.12

3.10 BILANZRECHTSMODERNISIERUNGSGESETZ (BILMOG)

Die neuen Bilanzierungsregelungen sind verpflichtend für Geschäftsjahre ab dem 1.1.2010 anzu-wenden. Sie sind anzuwenden durch kapitalmarktorientierte (Konzern-)unternehmen im Sinne des § 264d HGB n.F.

Sie können freiwillig bereits für den Abschluss 2009 angewendet werden, jedoch nur als Gesamtheit.

Neben einer Vielzahl neuer HGB-Regelungen zur Bilanzierung und Bewertung innerhalb der Rechnungslegung eines Unternehmens werden mit dem BilMoG auch wesentliche Vorgaben aus EU-Recht (8. EU-Richtlinie) umgesetzt.

Auch das interne Kontrollsystem und das Risikomanagementsystem rücken durch BilMoG stärker in den Blickpunkt von Vorständen und Aufsichtsräten und insofern stehen in den Unternehmen die entsprechenden aufbau- und ablauforganisatorischen Fragestellungen (auch zu Themen wie Funk-tionstrennung und sichere Berechtigungskonzepte und -systeme) im Fokus.

3.10.1 LAGEBERICHT (§§ 289, 315 HGB N.F.)

Im Lagebericht sind die wesentlichen Merkmale des rechnungslegungsbezogenen internen Kontroll- (IKS) und Risikomanagementsystems (RMS) zu beschreiben.

3.10.2 PFLICHTEN DES AUFSICHTSRATES

Der Aufsichtsrat hat die Verpflichtung zur Überwachung folgender Bereiche:

› Rechnungslegungsprozess› internes Kontrollsystem (IKS)› Risikomanagementsystem (RMS)› internes Revisionssystem (Interne Revision)

12 Leitfaden Datenschutz SAP ERP 6.0 (Stand 20. September 2009), Download über DSAGNet

22

Diese Überwachungspflichten werden dazu führen, dass sich Aufsichtsräte entsprechende Be-richtswege mit wirksamen Überwachungsstrukturen einrichten und dies auch Auswirkungen auf effiziente und effektive Kontrollen insbesondere in solchen Unternehmensbereichen haben wird, die Daten zur Finanzberichterstattung beisteuern (insbesondere Rechnungs- u. Finanzwesen, Personalwesen, Materialwirtschaft, Produktion, Vertrieb).

3.10.3 HANDLUNGSFELDER FÜR DEN VORSTAND

Der Vorstand trägt die Verantwortung für Einrichtung, angemessene Ausgestaltung und den Nachweis der Wirksamkeit u.a. des IKS und des RMS. Dies erfordert eine Bestandsaufnahme der vorhandenen Instrumente zum IKS/RMS:

› Systematische Aufnahme vorhandener wesentlicher Instrumente (u.a. Softwareunterstützung) und deren Verzahnung› Analyse der Angemessenheit, insbesondere der „Nachweisfähigkeit“› Maßnahmen zur Verbesserung des IKS/RMS

Darüber hinaus ist ein Nachweis der Wirksamkeit von IKS/RMS zu führen:

› Externe Zertifizierung der internen Revision (IR)› Etablierung eines Regelprozesses zum Monitoring der Wirksamkeit (Self Assessment, Prüfungsplanung der IR, Prüfung durch Externe, Konsolidierung der Überwachungsergebnisse)› Initiierung von Verbesserungsmaßnahmen bei festgestellten Schwächen› Berichterstattung an den Aufsichtsrat

Durch eine möglichst integrierte Steuerung und Überwachung der Risiken und Kontrollen innerhalb für das Unternehmen besonders kritischer Geschäftsabläufe mit Hilfe von SAP GRC Access Control, Process Control und Risk Management kann ein effektives und effizientes Management der Risiken und Kontrollen erreicht werden. Dies ist eine wesentliche Voraussetzung für die praktische Umset-zung der BilMoG-Anforderungen an Vorstand und Aufsichtsrat im Rahmen der Überwachung des internen Kontrollsystems und internen Risikomanagementsystems.

Eine der wesentlichen Maßnahmen zur Verbesserung des internen Kontrollsystems ist die Beseiti- gung von Risiken aufgrund von fehlender oder unzureichender Funktionstrennung beim Daten- und Programmzugriff (Stichwort: Segregation of Duties) und damit dem unkontrollierten, umfassenden Zugriff auf wesentliche IT-Systeme zur Abwicklung wesentlicher finanzkritischer Geschäftsprozesse. Eine unter IKS-Gesichtspunkten wirksame Funktionstrennung in der Ablauforganisation eines Unternehmens lässt sich durch ein entsprechendes Benutzerkonzept mit auf den Arbeitsplatz zuge-schnittenen Benutzerberechtigungen erreichen. SAP GRC Access Control ist das hierfür genutzte Instrument innerhalb der SAP-und Non-SAP-Welt.

Der geschilderte Handlungsbedarf gilt übrigens nicht nur für große börsennotierte Unternehmen, sondern ist auch für kapitalmarktorientierte Mittelstandsunternehmen verpflichtend, die ein funk-tionierendes internes Kontrollsystem sicherstellen wollen.

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

23

3.11 BASEL II

Unter dem Begriff Basel II werden die Eigenkapitalvorschriften für Kreditinstitute zusammengefasst, die vom Basler Ausschuss für Bankenaufsicht in den letzten Jahren vorgeschlagen wurden. Auf der Grundlage der EU-Richtlinien 2006/48/EG und 2006/49/EG erfolgte in Deutschland die Umsetzung mit Wirkung ab 1. Januar 2007 durch das Kreditwesengesetz, die Solvabilitätsverordnung und die MaRisk (Mindestanforderungen an das Risikomanagement).

Die Rahmenvereinbarung von Basel II basiert auf den drei „Säulen“

› Mindestkapitalvorschriften (Berechnung einer angemessenen Eigenkapitalausstattung)› aufsichtsrechtliche Überprüfungsverfahren › Marktdisziplin (höheres Maß an Transparenz bei der Offenlegung von Informationen der Bank. Sie verlangt die Offenlegung quantitativer und qualitativer Aspekte der von der Bank verwendeten Methoden für das Management ihrer Eigenkapitalanforderungen.)

Kreditinstitute müssen zu jedem einzelnen Risikobereich (z.B. Kredit-, Markt-, operationelles Risiko, Zinsänderungsrisiko des Anlagebuchs und Beteiligungspositionen) die internen Ziele und Grundsätze des Risikomanagements beschreiben. Dazu gehören:

1. Strategien und Prozesse 2. Struktur und Organisation der relevanten Risikomanagement-Funktion 3. Art und Umfang der Risikomeldungen und/oder -messsysteme 4. Grundsätze der Absicherung und/oder Minderung von Risiken sowie Strategien und Prozesse zur Überwachung der fortgesetzten Effektivität dieser Absicherungen/Risikominderungen

Innerhalb der Mindestanforderungen an das Risikomanagement (MaRisk) ist hinsichtlich der internen Kontrollverfahren festgelegt, dass Adressausfallrisiken, Marktpreisrisiken, Zinsänderungs-risiken, Liquiditätsrisiken und operationelle Risiken anhand wirksamer Risikosteuerungs- und Controllingprozesse zu überwachen sind und darüber zu berichten ist. Im Zusammenhang mit Basel III als Nachfolgeregelung von Basel II hat die BaFin am 14.12.2012 eine Überarbeitung der MaRisk veröffentlicht (umzusetzen bis 31.12.2013). Erstmalig werden u.a. Governance-Regelungen innerhalb eines Liquiditätstransferpreissystems gefordert (z.B. Funktionstrennung, Genehmigungs-verfahren). Darüber hinaus wird die Risikocontrollingfunktion gestärkt und die Compliance-Funktion aufgewertet.

24

3.12 BASEL III

Basel III ist ein auf Basel II aufbauendes, am 16.12.2010 final veröffentlichtes Regelwerk mit dem Ziel, die Stabilität des Bankensektors durch verschiedene im Verhältnis zu Basel II verschärfte Maßnahmen wesentlich zu verbessern:

1. Wesentlich höhere Anforderungen an Qualität und Quantität der Risikodeckungsmassen2. Umfassendere Abdeckung von insbesondere Kapitalmarktrisiken3. Erfüllung umfassender Liquiditätsanforderungen

Entscheidend für die organisatorische Umsetzung eines umfassenden Risikomanagements und Controllings im Bankenbereich sind jedoch die bereits an anderer Stelle erläuterten Mindestan-forderungen an das Risikomanagement (MaRisk), die spätestens bis zum 31.12.2013 durch die Banken umzusetzen sind.13

3.13 SARBANES-OXLEY ACT (SOX)

SOX ist ein Oberbegriff für gesetzliche Anforderungen an interne Kontrollen der Finanzberichter-stattung und betrifft alle an US-Börsen gelisteten Unternehmen. Insofern fallen auch deutsche Unternehmen unter dieses US-Gesetz von 2002, sofern ihre Wertpapiere an einer US-Börse gelistet sind. Unternehmen müssen gem. SOX nachweisen, dass wirksame interne Kontrollen (unterneh-mensweite Kontrollen und Geschäftsprozesskontrollen) zur Sicherstellung einer zutreffenden und vertrauenswürdigen Finanzberichterstattung eingerichtet sind. Dieser Nachweis ist durch das Management gegenüber der amerikanischen Börsenaufsicht (SEC) zu erbringen und durch einen Wirtschaftsprüfer zu bestätigen. Die mit der Überwachung der Einhaltung von SOX befasste amerikanische Aufsichtsbehörde ist die PCAOB (Public Company Accounting Oversight Board). Ein von der SEC und dem PCAOB empfohlener Standard zur Einrichtung und Überwachung inter- ner Kontrollen ist das sog. COSO-Framework14, das detaillierte Kontrollstrukturen und Umset-zungsvorschläge enthält, und in Deutschland in der Regel auch Maßstab für die Umsetzung der US-amerikanischen Anforderungen ist. Zur Umsetzung der SOX-Anforderungen auf Kontrollen im IT-Bereich hat sich das CoBiT-Rahmenwerk als hilfreich erwiesen. Eine entsprechende Gegenüber-stellung von COSO-Regelungen zu den Kontrollempfehlungen von CoBiT wurde vom amerikani-schen IT Governance Institute (ITGI) mit dem Leitfaden IT Control Objectives for Sarbanes-Oxley15

erstellt.

13 Siehe auch MaRisk-Novelle 2012 - Veröffentlichung der Endfassung „Anschreiben an die Verbände, Geschäftszeichen

BA 54-FR 2210-2012/0002, Bonn/Frankfurt a. M., 14. Dezember 2012“14 COSO (Committee of Sponsoring Organizations of the Treadway Commission). Entsprechende Informationen und

Detailbeschreibungen des Internal Control Framework nach COSO sind u.a. über folgenden Link verfügbar:

http://www.coso.org/guidance.htm.15 IT Control Objectives for Sarbanes-Oxley, The Role of IT in the Design and Implementation of Internal Control over Financial

Reporting, 2nd edition, Sept. 2006: http://www.itgi.org

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

25

3.14 NORMEN (DIN ISO/IEC)

3.14.1 ISO/IEC 27001

Die ISO/IEC 27001:2005 wurde aus dem britischen Standard BS 7799-2:2002 entwickelt und als in-ternationale Norm erstmals am 15. Oktober 2005 veröffentlicht. Mit Ausgabe 9.2008 liegt die Norm auch als DIN-Norm DIN ISO/IEC 27001 vor.

Der ISO-Standard 27001 „Information technology – Security techniques – Information security manage- ment systems requirements specification“ ist der erste internationale Standard zum Informations-sicherheitsmanagement, der auch eine Zertifizierung ermöglicht. ISO 27001 gibt auf ca. 10 Seiten allgemeine Empfehlungen. In einem normativen Anhang wird auf die Controls aus ISO/IEC 27002 verwiesen. Die Leser erhalten aber keine Hilfe für die praktische Umsetzung.

3.14.2 ISO 27002 (VORHER ISO 17799)

Das Ziel von ISO/IEC ISO 27002 „Information technology – Code of practice for information security management“ ist es, ein Rahmenwerk für das Informationssicherheitsmanagement zu definieren. ISO 27002 befasst sich daher hauptsächlich mit den erforderlichen Schritten, um ein funktionie-rendes Informationssicherheitsmanagement aufzubauen und in der Organisation zu verankern. Die erforderlichen Informationssicherheitsmaßnahmen werden kurz auf den ca.100 Seiten des ISO-Standards ISO/IEC 27002 angerissen. Die Empfehlungen sind auf Management-Ebene und enthalten kaum konkrete technische Hinweise. Ihre Umsetzung ist eine von vielen Möglichkeiten, die Anforderungen des ISO-Standards 27001 zu erfüllen.

3.14.3 ISO 27005

Dieser ISO-Standard „Information security risk management“ enthält Rahmenempfehlungen zum Risikomanagement für Informationssicherheit. Unter anderem unterstützt er bei der Umsetzung der Anforderungen aus ISO/IEC 27001. Hierbei wird allerdings keine spezifische Methode für das Risikomanagement vorgegeben. ISO/IEC 27005 löst den bisherigen Standard ISO 13335-2 ab. Dieser Standard, ISO 13335 „Management of information and communications technology security, Part 2: Techniques for information security risk management“, gab Anleitungen zum Management von Informationssicherheit.

3.14.4 WEITERE STANDARDS DER ISO 2700X REIHE

Die Normenreihe ISO 2700x wird voraussichtlich langfristig aus den ISO-Standards 27000 –27019 und 27030-27044 bestehen. Alle Standards dieser Reihe behandeln verschiedene Aspekte des Sicherheitsmanagements und beziehen sich auf die Anforderungen der ISO 27001. Die weiteren Standards sollen zum besseren Verständnis und zur praktischen Anwendbarkeit der ISO 27001 beitragen. Diese beschäftigen sich bspw. mit der praktischen Umsetzung der ISO 27001, also der Messbarkeit von Risiken oder mit Methoden zum Risikomanagement.

26

3.14.5 ZERTIFIZIERUNG NACH ISO 27001 AUF BASIS VON IT-GRUNDSCHUTZ

Das Bundesamt für Sicherheit in der Informationstechnik bietet seit Januar 2006 die ISO 27001- Zertifizierung auf der Basis von IT-Grundschutz an. Hierüber kann nachgewiesen werden, dass in einem Informationsverbund die wesentlichen Anforderungen ISO 27001 unter Anwendung der IT- Grundschutz-Vorgehensweise (BSI-Standard 100-2) und ggfs. einer ergänzenden Risikoanalyse (BSI-Standard 100-3) umgesetzt wurden.

Nach Umsetzung aller für die Zertifizierung relevanten Maßnahmen kann die Institution einen beim BSI lizenzierten ISO 27001-Auditor beauftragen, den Informationsverbund gemäß dem Prüfschema des BSI zu überprüfen. Die Ergebnisse dieser unabhängigen Prüfung werden in einem Auditreport festgehalten. Ein ISO 27001-Zertifikat auf der Basis von IT-Grundschutz kann zusammen mit der Einreichung des Auditreports beim BSI beantragt werden. Nach Prüfung des Reportes durch Experten des BSI erteilt die Zertifizierungsstelle das Zertifikat, das ebenso wie die Auditor-Testate vom BSI veröffentlicht wird. Alle zertifizierungsrelevanten Informationen wie das Zertifizierungsschema und die Namen der lizenzierten Auditoren sind öffentlich verfügbar und können unter www.bsi.bund.de/gshb/zert eingesehen werden.

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

27

4.1 ZUGRIFFSSCHUTZ IST CHEFSACHE

Insbesondere aufgrund zunehmend heterogener Systemlandschaften in den Unternehmen mit den neuen Herausforderungen durch mobile Endgeräte und dem Thema Cloud-Computing haben die Risiken des Datenmissbrauchs weiter zugenommen. Zugriffssicherheit bei Anwendungen und Daten ist insofern in allen Unternehmensgrößen eines der Prio-Themen innerhalb der IT-Sicherheit und des Datenschutzes.

Leider gilt dies anscheinend noch nicht für die Mittelstandsunternehmen. Nach einer europäischen Studie der PricewaterhouseCoopers AG16 machen nur 13 % der befragten Firmen das Thema Infor-mationssicherheit zur Chefsache. Datensicherheitsrisiken werden demnach vom Management noch weitgehend ignoriert. Darüber hinaus gehen die Unternehmen das Thema technologisch an mit der Prämisse, dass man Informationssicherheit allein mit dem Einsatz geeigneter Tools lösen kann. Dies gelingt aber in der Regel nicht, da vielfach mit den Fachbereichen abgestimmte Einsatzkon-zepte fehlen.

Nachstehend einige „Best-Practice-Hinweise“ der Unternehmen, die in der Studie gut abgeschnitten haben:

› Die Unternehmensführung kümmert sich selbst um das Thema Datensicherheit.› Teams mit Mitarbeitern aus verschiedenen Abteilungen arbeiten laufend an einer Optimierung.› Es besteht eine IT-Sicherheitsstrategie, deren Erfolg laufend überprüft wird.

Insofern ist insbesondere der Mittelstand aufgerufen, Informationssicherheit ernster zu nehmen, auch im Hinblick auf die zunehmende Bedrohung durch Industriespionage.

4.1.1 MITTELSTAND

Mittelständische Unternehmen – mit eigenverantwortlicher IT-Infrastruktur – sind oftmals gesell-schaftlich vernetzt und somit an die Vorschriften der Mutter oder der zentralen Revision gehalten; diese hat i.d.R. bereits unternehmensweite Governance-Richtlinien erstellt. Hier stellt sich nicht die Frage, „ob“, sondern eher „wann“ die Umsetzung und in welcher Form durchzuführen ist.

Mittelständische Unternehmen sind oftmals Zulieferer für Konzerne oder deren Vertriebspartner. Diese Konzerne achten verstärkt darauf, dass auch die Partner ihre Regelwerke akzeptieren und – vielleicht nicht in vollem Umfang – implementieren und einhalten.

Fast jedes größere mittelständische Unternehmen ist international aufgestellt und definiert für die Zentrale wie auch für die nationalen Gesellschaften ein internes Kontrollsystem und ein Risikoma-nagement, um das Zusammenwirken auf eine einheitliche, nachvollziehbare Geschäftsgrundlage zu stellen.

4. GRC IM REGULATORISCHEN UMFELD

16 Beyond cyber threats: Europe’s First Information Risk Maturity Index; March 2012,

A PwC report in conjunction with Iron Mountain

28

Der globale Wettbewerb zwingt zur Spezialisierung und damit – zunehmend als Wettbewerbs- vorteil – auch zu einer Zertifizierung der Produkt und Abläufe; sensible Produktionsverfahren und geschäftskritische Rezepturen sind in mittelständischen Unternehmen genauso verbreitet wie in Großunternehmen und existenziell zu schützen. Eine Zertifizierung ohne sichere IT-Geschäftspro- zesse und ausreichenden Datenschutz ist nicht mehr zu erlangen und hierzu gehört als wesentli-cher Bestandteil ein risikofreies/risikoreduziertes Rechtewesen und ein zentrales Benutzer- management mit Transparenz und Nachvollziehbarkeit. Prüfungsgesellschaften sind verpflichtet, die Sicherheit von IT-Abläufen mit in ihre Prüfverfahren aufzunehmen und zu bewerten. Da der Mittelstand sich in nicht unerheblichem Maße über Kredite finanziert, ist gelebte IT-Sicherheit und damit ein gutes Audit-Ergebnis mit Ausschlag für die Kreditvergabe der Banken und Investoren. Die Liste lässt sich beliebig fortsetzen; es gibt viele Gründe für die Einführung von SAP GRC Access Control auch bei mittelständischen Unternehmen.

Aus der Beratungserfahrung kann man ableiteten, dass heute bereits Unternehmen ab 500 ERP- User sich mit dem Gedanken tragen, ein IT-gestütztes Online-Risikomanagement einzuführen – und dies bei überschaubarem Aufwand und Kosten. Meistens beginnt man mit der Analyse der Berechtigungseinstellungen; durch die Implementierung von Access Risk Analysis aus der SAP GRC Produktlinie ist der Status quo einfach zu ermitteln. Sind die Berechtigungen anhand der ARA-Ergebnisse (Access Risk Analysis) danach überarbeitet, bietet es sich an, diese Funktionalität auch weiterhin zu nutzen, um Veränderungen in den Berechtigungseinstellungen IT-gestützt zu kontrollieren und qualitätszusichern. Ergänzt mit einem Notfall-User-Konzept (Emergency Access Management) könnte so für mittelständische Unternehmen ein praktikabler und bezahlbarer Weg als sinnvolle erste Ausbaustufe mit GRC AC beschritten werden.

4.1.2 GROSSUNTERNEHMEN / KONZERNE

Eine wirksame und effiziente Corporate Governance zur Sicherstellung einer verantwortungsbe-wussten, transparenten und risikominimierenden Unternehmensführung steht heutzutage ganz oben auf der Prioritätenliste der börsennotierten deutschen Unternehmen. Danach hat der Vorstand „für die Einhaltung der gesetzlichen Bestimmungen und der unternehmensinternen Richtlinien zu sorgen und wirkt auf deren Beachtung durch die Konzernunternehmen hin (Compliance).“17 Die operative Umsetzung der Corporate Governance erfolgt durch ein unternehmensweites Compliance- Management. Compliance-Verstöße können Schadensersatzforderungen, Geldbußen, Strafverfahren und bleibende Imageschäden nach sich ziehen.

Mit der Einführung des Bilanzrechtsmodernisierungsgesetzes (BilMoG) wurden insbesondere Prüfungsausschüsse, bzw. Aufsichtsräte, dazu verpflichtet, Compliance-Elemente wie internes Kontrollsystem, internes Risikomanagementsystem sowie das interne Revisionssystem zu über- wachen. Diese Regelung verstärkt die bisher schon bestehenden Empfehlungen des Deutschen Corporate Governance Kodex, wonach der Aufsichtsrat einen Prüfungsausschuss (Audit Committee) einrichten soll, der sich u.a. mit Fragen des Risikomanagements und der Compliance beschäftigen soll.18

17 Deutscher Corporate Governance Kodex, Abschnitt 4.1.3 in der Fassung vom 24. Juni 201418 Deutscher Corporate Governance Kodex, Abschnitt 5.3.2 in der Fassung vom 24. Juni 2014

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

29

Ein wesentlicher Schutz- und Kontrollbereich im Rahmen des Compliance-Managements ist der Zugriff auf Programme und Daten innerhalb der Informationstechnologie (IT). Aufgrund der Kom- plexität und Vielfalt der eingesetzten Programme und verwendeten Datenbestände sind unter-stützende Tools mit präventiven und detektivischen Schutzmechanismen erforderlich. Ideal sind unternehmensweite, integrierte Lösungen mit einem breiten Anwendungsspektrum. Gerade in Großunternehmen und Konzernen mit mehreren tausend SAP-Anwendern ist ein wirksames, pro- aktives Identitäts- und Zugriffsmanagement insbesondere auch zur Sicherstellung notwendiger Funktionstrennungsprinzipien nur mit Softwareunterstützung umzusetzen. Insofern ist zumindest für die SAP-Anwendungslandschaft, wie hauptsächlich der Business Suite, die Lösung SAP GRC Access Control ein wesentlicher Grundbaustein innerhalb eines unternehmensweiten Compliance- Konzeptes für den Bereich Identity & Access Management eines Konzerns.

Damit die oftmals erforderlichen risikoeindämmenden Kontrollen im Berechtigungsumfeld, wie z.B. der Abgleich von angelegten Kontenstammsätzen von Zuliefern mit kritischen Kontendaten, auch Bestandteil des internen Kontrollsystems werden, empfiehlt es sich zudem, diese Kontrollen in die Lösung SAP GRC Process Control zu übernehmen. Dies kann per elektronischem Interface oder aber auch einmalig manuell erfolgen. Für die Identitätssteuerung (also Registrierung, Abtei-lungswechsel etc.) ist zudem eine Integration der Steuerungs-Workflows mit einem eher technisch orientierten Identity-Management-Produkt, wie z.B. SAP NetWeaver Identity Management, ratsam.

30

4.2 MOTIVATION ZUM EINSATZ VON SAP GRC ACCESS CONTROL

Die Notwendigkeit, SAP GRC Access Control einzuführen, ist in aller Regel getrieben von der Not-wendigkeit eines effektiven und effizienten Identitäts- und Zugriffsmanagements in Verbindung mit der Umsetzung der vorgenannten Compliance-Anforderungen.

Der Einsatz von SAP GRC Access Control lässt sich in verschiedene Kategorien unterteilen.

Gestiegene Anforderungen:

1. Einige Unternehmen setzen, initiiert durch den IT-Bereich, SAP GRC Access Control ein, weil derzeit kein Berechtigungskonzept vorhanden ist und das Verständnis für die Notwendigkeit, auch von der Fachseite, fehlt.

Aufgrund einer ersten Risikoanalyse mit dem von SAP ausgelieferten Regelwerk können den Fachbereichen und dem verantwortlichen Management die vorhandenen Risiken transparent gemacht werden. Die Transparenz dieser Risiken kann zu verschiedensten Einführungsszenarien führen.

Eine Einführung des Emergency Access Managements (EAM) kann schon erste Beanstandungen hinsichtlich der Profile SAP_ALL und SAP_NEW hinfällig machen. Auch weitere Anforderungen an andere Superuser für die Fachbereiche und die IT können damit abgedeckt werden.

In dieser Kategorie der Implementierung von SAP GRC Access Control ist die Risikoanalyse, wie so oft, der zentrale Baustein, d.h., das Unternehmen wird sich zur weiteren Sicherstellung der Compliance dem Ausarbeiten des Regelwerkes widmen. Nach Erstellung/Ausprägung des Regelwerkes erfolgt die Einrichtung der Workflows für das Benutzerantragsverfahren mit integ- rierter Risikoanalyse, Beantragung von Superuser-Berechtigungen usw. Als letzte Komponente wird man sich dann dem Business Role Management zuwenden.

2. Bei anderen Unternehmen sind eingeführte Prozesse für die Themen Benutzer- und Rollen- verwaltung vorhanden. Die Lücken in diesen Unternehmen offenbaren sich in der geringen Überprüfbarkeit der Funktionstrennungsrisiken. Eventuell kommt noch erschwerend eine dezentrale Benutzer- und Rollenverwaltung hinzu.

In diesen Fällen sind auch die Benutzeranträge dezentral (im schlechtesten Fall in Papierform) abgelegt. Eine Nachvollziehbarkeit, welche Benutzeränderung aufgrund welchen Antrages durchgeführt wurde, wird damit erheblich erschwert.

Um diesen Missstand zu beheben, kann hier das Einführungsszenario so aussehen, dass zuerst das Benutzerantragsverfahren ohne Risikoanalyse eingeführt wird. Erst in einem weiteren Schritt kommen die Komponenten EAM, ARA und BRM hinzu.

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

31

3. Unternehmen, die aufgrund von Prüfungsergebnissen der internen Revision oder der Wirtschafts- prüfung tätig werden und sich u.a. auch deshalb für präventive Risikoanalysen mit SAP GRC Access Control entscheiden.4. Eine andere Kategorie von Unternehmen hat ausgearbeitete Berechtigungskonzepte und gelebte Prozesse implementiert. Lediglich die Dokumentation für das IKS ist verbesserungswürdig. In diesen Fällen erlaubt das Reporting von SAP GRC Access Control den entsprechenden Nachweis und somit die Sicherstellung der Compliance.

Die Implementierung von SAP GRC Access Control erfolgt hier oft in der Reihenfolge ARA und EAM, ARM und BRM.

Kostendruck:

1. Grundsätzlich sind die meisten der gestiegenen Anforderungen durch die Benutzer- und Berech- tigungsverwalter eines jeden betroffenen Systems (SAP und Non-SAP) umsetzbar. Allerdings ist dies mit einem erheblichen zusätzlichen Personalaufwand verbunden. Daher ist der Einsatz von SAP GRC Access Control als zentrale Lösung sinnvoll, da sich hierdurch eine bessere Effizienz erreichen lässt.

2. Einige der Anforderungen lassen sich in den SAP-Business-Anwendungen und auch in vielen Non-SAP-Systemen standardmäßig nicht umsetzen und wurden daher bisher bei vielen Anwendern durch Eigenentwicklungen gelöst. Die Pflege und Weiterentwicklung dieser Eigenentwicklungen ist sehr zeitaufwendig und kostenintensiv. Prominente Beispiele wären die Änderungsdokumen- tation von Benutzerrollen, das gesamte Antragswesen, Workflows, manuelle Notfalluser-Rege- lungen, Massenableitungen von Rollen. Insgesamt ist dies auch ein Entscheidungsgrund für SAP GRC Access Control, das diese Funktionen anbietet.

Weitere unterschiedliche Ausprägungen sind denkbar, würden aber den Rahmen dieses Leitfadens sprengen.

Zusammenfassend lässt sich feststellen, dass sich die Verwendung von SAP GRC Access Control in den meisten Fällen von einem reaktiven Ansatz – wenn nur die Risikoanalyse zum Einsatz kommt - zu einem präventiven Ansatz mit allen Komponenten wandelt.

32

4.3 RAHMENBEDINGUNGEN / ERFOLGSFAKTOREN

Die im Folgenden dargestellten Rahmenbedingungen und Erfolgsfaktoren für ein GRC-Access- Control-Projekt basieren auf den Erfahrungen durchgeführter Implementierungsprojekte bei Unter- nehmen aus unterschiedlichen Branchen und unterschiedlicher Unternehmensgrößen. Dabei hat sich gezeigt, dass Projekte dieser Art als übergreifend anzusehen sind und nicht von der IT alleine durchgeführt werden können. Aus diesem Grund ist es notwendig, alle Interessensgruppen frühzeitig einzubinden (z.B. Verantwortliche aus den Fachbereichen sowie der IT und von Internal sowie External Audit).

Für eine erfolgreiche Projektdurchführung muss das Top-Management die Verantwortung tragen und das Projekt bei notwendigen Entscheidungen begleiten. Dabei hat sich als vorteilhaft erwiesen, frühzeitig die Einführungsstrategie festzulegen.

Ein Einführungsprojekt setzt sich grundsätzlich aus unterschiedlichen Projektbeteiligten zusammen. Das Projektteam besteht dabei in der Regel aus Vertretern des Fachbereiches und aus Vertretern des IT-Bereiches. Sofern es sich aber um Projekte im Umfeld von Mitarbeiter-Berechtigungen und dem zugrunde liegenden Change-Management-Prozess handelt, reicht diese einfache Organisati-onsstruktur innerhalb eines Projektes nicht aus.

In diesem Zusammenhang werden Fragestellungen zum Datenschutz, zu Möglichkeiten einer Mit-arbeiterüberwachung, den regulatorischen Anforderungen und Verantwortlichkeiten aufgeworfen, die nur durch eine intensive Einbeziehung einzelner Gruppen bereits in einer frühen Projektphase beantwortet werden können. Die Bedeutung und Erläuterung dieser These ergibt sich aus den folgenden Beschreibungen der einzelnen Aufgabengebiete.

4.3.1 TOP-MANAGEMENT

Das Top-Management als Projekt-Owner muss die notwendigen Entscheidungen zeitnah her-beiführen und die Umsetzung unterstützen. Dabei werden auch organisatorische Veränderungen entstehen, für die die Fachbereiche motiviert werden müssen. Zur Sicherstellung einer nachhalti-gen Zielerreichung des GRC-Access-Control-Projektes sollte das Top-Management auch ein sog. Konsequenzenmanagement sicherstellen (insbes. Eskalationsfunktion, Budgetbereitstellung, klare verbindliche Zielvorgaben, Erfolgscontrolling).

4.3.2 BETRIEBSRAT

Der Betriebsrat hat nach § 87 Abs. 1 Nr. 6 BetrVG ein Mitbestimmungsrecht, wenn es um die Ein-führung und Anwendung von Einrichtungen geht, die das Verhalten der Arbeitnehmer überwachen können. Grundsätzlich betrifft dies z.B. den Einsatz des Emergency Access Management (EAM; vormals Firefighter) und dessen Protokoll-Datei. Es empfiehlt sich, den Betriebsrat frühzeitig als vertrauensbildende Maßnahme über das Projekt zu informieren und in die Entscheidungsprozesse zur Produktivsetzung einzubeziehen.

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

33

4.3.3 WIRTSCHAFTSPRÜFER

Eine wesentliche Aufgabe des Wirtschaftsprüfers im Rahmen der Prüfung des Jahresabschlusses ist die Einschätzung der sog. Kontrollrisiken, d.h. die Beurteilung der Wirksamkeit des internen Kontrollsystems hinsichtlich der durchzuführenden Prüfungshandlungen. Die Einhaltung von Funktionstrennungsprinzipien u.a. durch ein wirksames Benutzerberechtigungskonzept und des-sen organisatorische Umsetzung ist dabei ein wesentlicher Prüfungsbereich. Aufgrund seiner profunden Kenntnisse des internen Kontroll- und Risikomanagementsystems des geprüften Unter-nehmens und seiner skizzierten Prüfungspflichten sollte der Wirtschaftsprüfer bereits frühzeitig in entsprechende Einführungsprojekte von SAP GRC Access Control einbezogen werden. Projekt-begleitend kann er wesentliche Hinweise zur Sicherstellung eines ordnungsmäßigen und sicheren Benutzermanagements geben und damit einen wertvollen Beitrag auch im Sinne einer projektbe-gleitenden Qualitätssicherung leisen.

4.3.4 INTERNE REVISION

Die interne Revision ist Teil des internen Kontrollsystems einer Organisation, ist unabhängig und der obersten Leitung unterstellt. Das Aufgabengebiet besteht vor allem aus organisationsinternen Prüfungen und unterstützt mit Lösungsvorschlägen. So kann die interne Revision dafür zuständig sein, Empfehlungen für ein neues Berechtigungskonzept abzugeben, für den Produktiveinsatz freizugeben und auch entsprechende Prüfungen der ordnungsgemäßen Umsetzung vorzunehmen.

4.3.5 INTERNAL CONTROL / RISK MANAGEMENT

Zunehmend werden in größeren Unternehmen Abteilungen eingerichtet, die sich mit der Ausge-staltung und Steuerung des internen Kontrollsystems befassen. Das interne Kontrollsystem sollte im Projekt bei der Definition der Risiken und SoD-Konflikte sowie bei der Auflösung von Risiken zur Identifizierung der relevanten Kontrollen einbezogen werden.

4.3.6 COMPLIANCE OFFICER

Der Compliance Officer ist zuständig für alle Arten der Wirtschaftskriminalität. Compliance Officer entwickeln Verhaltenskodizes, Richtlinien und Trainingsmaßnahmen, damit Mitarbeitende die Regeln und Normen einhalten, die ein Unternehmen oder eine Organisation selbst festgelegt hat. Die Regeln sind aus gesetzlichen Anforderungen abgeleitet und stehen im Einklang mit dem Wertesystem des Unternehmens. Compliance-Verantwortliche implementieren diese im Unternehmen, optimieren sie und überwachen deren Einhaltung. Im Fokus stehen dabei vor allem die Prävention und die Aufdeckung von Verstößen.

Das Aufgabengebiet des Compliance Officers ist nach Ansicht des Bundesgerichtshofs weit gefasst. „So stehe die Verhinderung von Rechtsverstößen, insbesondere auch von Straftaten, die aus dem Unternehmen heraus begangen werden, im Vordergrund. Derartige Beauftragte treffe regelmäßig eine strafrechtliche Garantenpflicht. Denn dem Compliance Officer seien Obhutspflichten für eine bestimmte Gefahrenquelle übertragen worden. Daraus folge die besondere Verantwortlichkeit für diesen Bereich.“( BGH-Urteil vom 17.07.2009; Az 5 StR 394/08).

34

Der Compliance Officer hat damit eine ganz wesentliche Funktion bei der Gestaltung und Imple-mentierung von Compliance- und Risikomanagementsystemen im Unternehmen und insbesondere auch beim Thema der Zugriffskontrollen.

4.3.7 SAP-BASISBETREUUNG

Die Rolle und Aufgabe der SAP-Basisbetreuung im Umfeld von Berechtigungen im SAP-Umfeld ist ganz vielschichtiger Art. Sie differiert selbst zwischen einzelnen Unternehmen, je nach Größe und interner Organisation. Die SAP-Basisbetreuung kann durch eine eigene IT-Service-Einheit oder durch eine externe IT-Service-Organisation durchgeführt werden. Ihre Aufgabe sollte dagegen aber prinzipiell ähnlich sein.

Die SAP-Basisbetreuung ist neben vielen weiteren Aufgaben im Umfeld der SAP-Berechtigungen in der Regel zuständig für folgende Aufgaben:

› Neuanlage von Usern im SAP-System› Verwaltung von Benutzergruppen› Zurücksetzen von Passwörtern› Sperren und Entsperren von Benutzern› häufig auch: Zuweisen und Erweitern von Berechtigungsrollen

Durch Einführung von SAP GRC Access Control ändert sich das Aufgabengebiet der SAP-Basis- betreuung. Viele bislang manuell durchgeführte Arbeitsschritte werden nun automatisiert.

4.3.8 SAP-BERECHTIGUNGSADMINISTRATOREN

In größeren Organisationen wird bzw. sollte die Benutzer- und Berechtigungsverwaltung getrennt werden (4-Augen-Prinzip). Diese Administratoren sind dabei für Erstellung, Anpassung und Zuweisung der Berechtigungsrollen zuständig. Sie arbeiten eng mit den jeweiligen Fachbereichen zusammen und verstehen die Rollen auch fachinhaltlich, um diese entsprechend dem Aufgaben- gebiet des Mitarbeiters zuweisen zu können.

4.3.9 ORGANISATIONSABTEILUNG

Eine Organisationsabteilung ist oft bei größeren Unternehmen zu finden. Diese unterstützt u.a. bei der Erstellung von Berechtigungsvergabeprozessen. Diese Prozesse und deren Dokumentationen sind notwendig für einen geordneten und nachvollziehbaren Ablauf der Vergabe von Berechtigungen.

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

35

4.3.10 SCHLÜSSELPERSONEN AUS DEN FACHBEREICHEN

Die Schlüsselpersonen aus den Fachbereichen spielen eine vermittelnde Rolle zwischen dem Endanwender und den Berechtigungsadministratoren. Über Sie wird oft die Berechtigungsan-forderung der Endanwender kanalisiert und spezifiziert. Sie unterstützen bei der Definition von Rolleninhalten und Arbeitsplatzbeschreibungen und können einschätzen, ob ein Anwender eine Berechtigung für sein Aufgabengebiet benötigt. Sie haben zudem den Überblick und können die Relevanz der Zugriffsrisiken einschätzen.

4.3.11 ENDANWENDER

Endanwender haben im Wesentlichen Testaufgaben wahrzunehmen, da der Fachbereich innerhalb des Projektes durch die Schlüsselpersonen vertreten ist. Insbesondere sollten sie mitwirken beim Usability-Test. Darüber hinaus sind die Endanwender als die wesentlich Betroffenen der Systemein-führung (Prozessänderungen, Antragswesen) durch eine frühzeitige und nachhaltige Kommunikation mit dem Ziel einer möglichst hohen Akzeptanz in allen Projektphasen einzubinden.

Eine frühzeitige Einbeziehung vermeidet auch nicht zielführende Fehlentwicklungen bei der Kon-zeption und dem Go-Live von SAP GRC Access Control, die dann möglicherweise auch dazu führen können, dass zusätzliche Prüfungshandlungen im Rahmen einer Prüfung des Jahresabschlusses erforderlich werden und unter Umständen die Wirksamkeit des internen Kontrollsystems nur mit Einschränkungen bestätigt werden kann.

36

Nach dem Erwerb von Virsa Inc. und deren GRC-Produktpalette im Jahr 2006 hatte SAP das anfangs noch unter ABAP laufende GRC Access Control 4.0 zunächst auf seine Java-Plattform portieren lassen, auf der die Versionen 5.2 und 5.3 basieren. Andere Applikationen wie etwa Process Control verblieben hingegen noch in der ABAP-Variante. Mit GRC10.0 wurden von SAP nun alle GRC-Produkte (GRC Access Control, Process Control, Risk Management usw.) auf eine einheitliche technische Basis gebracht, und zwar zurück in die ABAP- basierten Plattformen: SAP GRC Access Control 10.0 hat als Installationsvoraussetzung den NetWeaver ABAP 7.02. Dies bringt gegenüber den früheren Versionen erhebliche Verbesserungen bei Betrieb, Integration sowie User-Handling der verschiedenen Applikationen.

5.1 KOMPONENTENSTRUKTUR UND NAMENSGEBUNG

SAP hat im Rahmen des neuen Releases den einzelnen Komponenten neue Namen gegeben, die deren Funktionalität besser umreißen und sich auch sinnvoller in die gesamte GRC-Suite samt Process Control und Risk Management einordnen lassen:

› Risk Analysis and Remediation heißt nun Access Risk Analysis (ARA)› Compliant User Provisioning heißt nun Access Request Management (ARM)› Enterprise Role Management heißt nun Business Role Management (BRM)› Superuser Privilege Management heißt nun Emergency Access Management (EAM)

Alle Komponenten werden in einer neuen, Webdynpro-ABAP-basierten Benutzeroberfläche in verschiedene Kategorien bzw. Navigationsgruppen eingeordnet. So gibt es nicht mehr dedizierte Einstiegspunkte etwa für ARM oder BRM, sondern einzelne Funktionspunkte wie etwa „Zugriffs-risikoanalyse – Benutzerebene“ (ARA) und Zugriffsanforderung – Vorlagenbasierte Anforderung“ (ARM) unter der Navigationsgruppe „Zugriffsverwaltung“.

5. FUNKTIONALER UND TECHNOLOGISCHER VERGLEICH ZU SAP GRC ACCESS CONTROL 5.3

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

37

Abbildung 5: Einstiegsbild GRC Access Control

38

5.2 NEUE TECHNOLOGISCHE PLATTFORM

Im Gegensatz zu den Java-Versionen, die sich jeweils durch eine schmale, gekapselte und funktional fokussierte Architektur auszeichneten, verwendet GRC10.0 den NW ABAP als Integrationsplattform und nutzt dessen technische Vielseitigkeit durch Wiederverwendung bekannter Komponenten:

› Für den Betrieb aller Konnektoren – irrespektive ihrer jeweiligen Nutzung in den GRC-Access- Control-Komponenten – wird die RFC-Verwaltung aus der SM59 verwendet. Ein Konnektor- Framework sorgt für die Interpretation der Daten in die einzelnen Applikationen.

› Für eine Vielzahl von organisatorischen Objekten wird das Standard-Organisationsmanagement des ABAP-Systems wiederverwendet. So sind z.B. mindernde Kontrollen als spezielle Objekttypen im OM gespeichert.

› Für die Workflows in allen GRC-Komponenten werden die MSMP-Workflows des ABAP-Systems verwendet.

› Bei einer feineren Ausarbeitung von Regeln innerhalb der Workflows, z.B. etwa um eine Genehmigerbestimmung anzupassen, kommt der ABAP-Standard für Business-Regeln BRF+ zum Einsatz.

› Der Betrieb der Applikation folgt nun den üblichen ABAP-Standards: Hintergrundjobs, Jobver- waltung, Scheduling usw. können durch die üblichen Funktionen SM36, SM37 wahrgenommen werden. Externe Jobscheduler wie Redwood und andere sind nun ebenfalls einsatzbar.

› Wie bereits oben im Screenshot angedeutet, wird als Benutzeroberfläche Webdynpro ABAP verwendet. Dabei erfolgt das eigentliche Customizing der Komponenten ganz analog zum ABAP-Standard im IMG (Transaktion SPRO) über die SAPGUI, die Stammdateneinrichtung und die Businessfunktionen jedoch werden grundsätzlich per Browser oder NWBC durchgeführt, dabei ist auch eine Portalintegration möglich. (Einzige Ausnahme: Der Emergency Access erfolgt wie üblich direkt per SAPGUI.)

› GRC10.0 ist mittels der ABAP-Basis komplett mandantenfähig. Nur wenige Strukturen wie etwa die SM59-Verbindungen werden mandantenübergreifend verwendet, alle anderen Appli- kationsdaten sind mandantenabhängig, was einen verteilten Betrieb auf einer zentralen Instanz ermöglicht.

› Anders als im NetWeaver Java gibt es nun die Möglichkeit, Vorabkorrekturen einzuspielen. Dies ist insbesondere vor dem Hintergrund der von SAP geforderten Synchronizität der SP-Level wichtig.19

19 Mit SP10 wurde diese Restriktion aufgehoben: SP-Level der Zentralkomponente und der Plug-ins in den Satellitensystemen

dürfen nun voneinander abweichen.

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

39

5.3 VEREINHEITLICHTE STAMMDATEN, ARCHITEKTUR (AUCH BZGL. PROCESS CONTROL ETC.)

SAP hat die Haupt-Applikationen der GRC-Suite, SAP GRC Access Control, Process Control und Risk Management einem kompletten Redesign unterzogen mit verstärktem Fokus auf die bessere Inte-gration der Applikationen ineinander sowie die verstärkte Nutzung von Standards und gemeinsamen Konfigurationseinstellungen und Komponenten. So wird das bereits oben erwähnte Konnektor- Framework von allen Applikationen und Komponenten gemeinsam verwendet, aber auch das Orga-nisationsmodell und darin enthaltene Objekte wie etwa Kontrollen oder Prozesse und Organisati-onseinheiten. Einen guten Eindruck bekommt man von dieser harmonisierten Informations- und Funktionsbasis, wenn man sich den Baum der Konfigurationspunkte im IMG ansieht:

Abbildung 6: Customizing mit dem SAP Implementation Guide

40

Auch werden etwa Workflow-Items aus allen Applikationen und Komponenten im Navigationspunkt „Meine Startseite“ in einer gemeinsamen Arbeitsvorratsliste gehalten und sind dort für den Endan-wender wesentlich besser abarbeitbar, da er sich nicht mehr in verschiedenen Applikationen oder Komponenten bewegt und jeweils dort nach entsprechenden Elementen suchen müsste.

5.4 FUNKTIONALE ÄNDERUNGEN UND ERWEITERUNGEN

Grundsätzlich stand für SAP zunächst der technologische Umbau von GRC 10.0 gegenüber den Vorgängerversionen der Suite im Fokus dieser Releases. Daher wurden – mit wenigen Ausnah-men – alle in Process Control 3.0 und Risk Management 3.0 sowie Access Control 5.3 vorhandenen Funktionen auch in GRC 10.0 abgebildet. Zwar ergeben sich aufgrund der nun verwendeten Techno-logie Unterschiede in der Benutzeroberfläche, der Konfiguration und dem Handling verschiedener Funktionen, erhebliche Erweiterungen wurden jedoch nur vereinzelt vorgenommen. So gibt es im Wesentlichen einige kleinere Verbesserungen, u.a:

› Im ARA können nun besser Massenänderungen vorgenommen werden

› Mindernde Kontrollen auf Konnektorebene sind nun möglich

› Die Analyse von Sammelrollencontainern aus der ZBV

› Im ARM werden – neben einer erheblichen Flexibilisierung der Konfiguration über BRF+ – erweiterte Möglichkeiten von Vorlagen zu Anforderungen und konfigurierbare Antragsformulare angeboten

› Ebenfalls im ARM gibt es erweiterte Suchmöglichkeiten nach Rollen und Benutzern

› Es können im ARM nun verschiedene Risikoregelwerke geprüft werden

› Das BRM wurde erheblich verbessert um Ableitungen, Sammelrollen und das Mapping zu technischen Einzelberechtigungen optimiert zu unterstützen

› Rollenvergleiche wurden optimiert bzgl. Änderungen in den Backendsystemen

› Über das ABAP-basierte Berechtigungswesen und die intensive Nutzung von entsprechenden Berechtigungsobjekten können nun Zugriffe auf die Applikation wesentlich feingranularer ausgesteuert werden, als dies bei den Vorversionen der Fall war. So können z.B. einzelne Namensräume bestimmter Funktionen oder Risiken selektiv berechtigt werden. Dies ermög- licht einen verteilten Betrieb sogar innerhalb ein und desselben Mandanten.

› Konfigurationen können nun über das Standardtransportwesen in Folgesysteme übertragen werden (dies trifft jedoch nur in sehr eingeschränktem Maß auf Stammdaten zu)

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

41

Die Benutzeroberfläche wiederum bietet in den immer wieder verwendeten ALV-Listen auch Vor-selektionen und Query-Speicherungen, Personalisierungen und jederzeit Download-Möglichkeiten in Excel, außerdem können bei vielen Funktionen jeweils neue Fenster parallel geöffnet werden, damit sind inhaltliche Vergleiche wesentlich effizienter durchzuführen als in der Vorversion.Neben den erwähnten signifikanten Änderungen durch den Plattformumbau und die stark verän- derte Benutzeroberfläche gibt es allerdings noch eine erhebliche funktionale Änderung im Design beim Emergency Access Management (EAM): Der Betrieb des EAM erfolgt statt wie vorher dezentral in den jeweiligen Backends (in der Version 5.3 war nur die Einsicht in die Logs zentral möglich) nun zentral über die Frontendplattform GRC Access Control 10.0. Hierbei wurde auch die Konfiguration des EAM mit Kontrolleuren und FF-ID-Ownern zentralisiert. Bis einschließlich SP9 mussten im EAM darüber hinaus selbst die FireFighter immer über das zentrale GRC-Access-Control-System für ihre Reparaturarbeiten einsteigen, was es erforderlich machte, alle potenziellen FireFighter- UserIDs im Zentralsystem als User anzulegen. Ab SP10 gibt es allerdings auch die Möglichkeit eines dezentralen, also wieder wie unter 5.3, lokalen FireFighter-Einsatzes. Die UserID muss nicht im Zentralsystem vorgehalten werden. Allerdings bleibt die Konfiguration und Logeinsicht zentral.

42

5.5 BEWERTUNG

Aus den bisher bekannten produktiv gesetzten AC10.0-Projekten sind – mit wenigen Ausnahmen, bei denen sehr spezielle Features nicht ähnlich genug wie in GRC Access Control 5.3 abgebildet waren – überwiegend positive Rückmeldungen zu verzeichnen. Insbesondere der verbesserte technologische Unterbau (mit z.B. erheblich kürzeren Analyseläufen als noch in der Java-Version) und das wesentlich vereinfachte Handling haben viele Administratoren, Compliance-Teams und Endanwender überzeugt.

Nachvollziehbare Schwierigkeiten gibt es vor allem in zwei Bereichen: Zum einen gibt es wegen der verwendeten Technologie keinen direkten Upgradepfad, sondern nur eine Migration von 5.3 nach 10.0. Dabei werden nicht alle Informationen übernommen, z.B. gibt es keine Möglichkeit, historische Analyseergebnisdaten zu migrieren, außerdem müssen komplexere Workflows neu abgebildet werden. Darüber hinaus wird der RTA aus AC5.3 vom Plug-in (neuer Name für RTA) von AC10.0 grundsätzlich immer überschrieben. Ein Parallelbetrieb von RTA und Plug-in ist im Backend aus technisch-organisatorischen Gründen nicht möglich. Da allerdings das Plug-in auch Process Control und Risk Management umfasst, wäre dann auch ein Parallelbetrieb etwa von Process Control 10.0 und GRC Access Control 5.3 zunächst nicht möglich, wenn dieselben Backends dabei genutzt werden. Allerdings hat sich SAP hierzu eine Lösung einfallen lassen – diese wird im Kapitel zur Migration näher beschrieben.

Allgemein stellt jedoch aus den vorstehend genannten Gründen die Migration von einer Version 5.x nach 10.0, auch wegen ggf. parallel laufender Systeme, durchaus eine Herausforderung dar, insbesondere in den Bereichen ARM und BRM.

Bis SP9 war der nun durchgehend zentralisierte Notfalluser-Mechanismus (EAM) für bestimmte Szenarien nachteilig. Insbesondere ist in großen, verteilt strukturierten Organisationen ein zentraler Plattformbetrieb erheblich erschwert worden, weil nun im Gegensatz zum vorherigen SPM-Design auch alle EAM-Anwender (also diejenigen Mitarbeiter, die potenziell eine Notfallreparatur durch-führen würden) in dem zentralen GRC10.0-System vorgehalten werden müssten, da sie hierüber ihre EAM-Session starten müssen. Damit wurden an dieses zentrale System sofort erweiterte An-forderungen gestellt wie etwa ein ausgedehnter Support (z.B. für Benutzereinrichtung, vergessene Passwörter, falls kein SSO benutzt wird, etc.) als auch möglicherweise Hochverfügbarkeit – denn wenn im zentralen EA die GRC10.0-Plattform ausfällt, sind sofort keine Notfallreparaturen mehr möglich. Mit der Einführung des dezentralen Einstiegs für EAM-Anwender ab SP10 ist diese Proble-matik behoben und wieder die vorherige Flexibilität erreicht.

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

43

6. EINFÜHRUNGSMANAGEMENT (ROLLOUT INKL. USERTRAINING)

Gemäß der SAP-ASAP-Methodik („Accelerated SAP“), die für die Implementierung und den Rollout von SAP-ERP-Anwendungen vor Jahren schon entwickelt wurde, lässt sich ein SAP-Einführungs-projekt in folgende Hauptphasen einteilen (siehe auch „GRC Implementation Roadmap“ verfügbar auf dem SAP Service-Marketplace: http://service.sap.com/roadmaps):

› Projektvorbereitung („Strategie & Planung“): In dieser ersten Phase legen die Entscheidungs- träger klare Projektziele und eine effiziente Vorgehensweise zur Entscheidungsfindung fest. Es wird das genaue Projektteam und dessen Kommunikation mit den Fachbereichen festgelegt. Speziell bei einem Einführungsprojekt für SAP GRC Access Control ist die Kommunikations- strategie mit den Verantwortlichen aus den Fachbereichen für den Gesamtprojekterfolg von großer Bedeutung. Zudem wird der Projektplan in Abhängigkeit von einer ersten Analyse des bestehenden Berechtigungskonzepts für SAP, des Systemumfangs, des bestehenden Identity Lifecycle Managements und anderen Abhängigkeitsfaktoren festgelegt.

› Sollkonzeption („Business Blueprint und Design“): In dieser Phase werden die in der Strategie- phase festgelegten High-Level-Prinzipien, wie z.B. die technische Architektur für SAP GRC Access Control, das eventuell notwendige Reengineering des bestehenden SAP-Rollenkonzepts und des Designs des Risikomanagements mit den notwendigen Provisionierungsworkflows, der Festlegung der Zugriffsrisiken (also „Segregation of Duties“-Konflikte und kritische Transaktionen) in ein Feindesign überführt. Zudem wird auch ein detailliertes Rollendesign für die Steuerung von SAP GRC Access Control selbst festgelegt.

› Realisierung („Implementierung“): Hauptziel dieser Phase ist die eigentliche Konfiguration des SAP GRC Access Control Systems (Customizing), um zu einer integrierten und dokumentierten, das Risikomanagement und legale Anforderungen erfüllenden Lösung zu gelangen.

› Produktionsvorbereitung („Rollout“): In der Phase Produktionsvorbereitung erfolgt die endgültige Vorbereitung des Systems auf die Produktionsphase. Dazu gehören beispielsweise intensive Tests der eventuell überarbeiteten Berechtigungseinstellungen und der Provisionierungswork- flows sowie intensive Schulung der Fachbereiche zu Genehmigungsaktivitäten und des Notfall- benutzerverfahrens.

› Produktivstart („Support“): Nach dem Abschluss des sog. Go-live, bei dem das System in den Produktivzustand gesetzt wird, konzentriert sich das Projektteam auf die Unterstützung der Benutzer, deren Schulung möglicherweise noch nicht abgeschlossen ist. Es ist gleichermaßen notwendig, Verfahren und Maßstäbe zu entwickeln, anhand derer die Applikation regelmäßig betriebsbegleitend überprüft wird. Es wird zudem ein Know-how-System mit aufgetretenen Fehlern und entsprechenden Lösungen aufgebaut und an den Help Desk für den First Level Support und auch Second Level Support übergeben.

Die ASAP-Methodik sollte entsprechend auch für SAP GRC Access Control angewendet werden, wodurch sich die nachfolgend aufgeführten Projektphasen ergeben.

44

6.1 PHASE: PROJEKTVORBEREITUNG („STRATEGIE & PLANUNG“)

6.1.1 RISIKOBASIERTES BERECHTIGUNGSMANAGEMENT

Das Hauptziel eines Unternehmens, das SAP GRC Access Control einführt, sollte speziell der Aufbau einer risikobasierten Vergabe von SAP-Berechtigungen sein. Eine Berechtigungssteuerung nach dem sog. „Need to know“ -Prinzip, das viele Sicherheitsstandards, wie z.B. auch ISO 27001/2, fordert, ist in der Praxis eigentlich nicht umsetzbar und führt in der Regel immer zum gleichen Resultat, dass speziell Fachbereiche genau „Need to know“ für die Beantragung von Berechtigun-gen für die Durchführung von Geschäftsprozessschritten für sich selbst beanspruchen und daher meist kein adäquates Instrument zur Steuerung der Berechtigungsvergabe darstellt.

Besser ist die Steuerung der Berechtigungsvergabe über vorher mit den Fachbereichen bzw. der Organisation festgelegte fachbereichsspezifische Business-Funktionen und Geschäftsprozessrisiken, wie sie z.B. das fehlende Vier-Augen-Prinzip, kritische Funktionalitäten (SAP T-Codes) oder auch der Zugriff auf kritische Unternehmensdaten (die mit Hilfe von Anzeigeberechtigungen gesteuert werden können) darstellen. Dabei sollte zuvor eine eindeutige Risikodefinition mit den Fachberei-chen, basierend auf einer unternehmensweiten Richtlinie, festgelegt werden, die die Risikostufen (bspw. niedrig, mittel und hoch) vorgibt.

SAP GRC Access Control liefert eine Risikomatrix auf Basis eines Best-Practice-Ansatzes aus, der aber nicht einfach „blind“ übernommen werden sollte, sondern der mit den einzelnen zustän-digen Fachbereichen abgestimmt und ergänzt bzw. reduziert werden muss. Zudem sollten mit Fachbereichsverantwortlichen (z.B. Rechnungswesen) oder auch Geschäftsprozesseignern (z.B. Vertriebsprozess) ein Risikoverantwortlicher festgelegt werden. Der Risikoverantwortliche ist befugt, die Risikodefinitionen einschließlich der Risikostufen in Absprache mit dem Compliance Officer oder auch Risikomanagern des Unternehmens ändern zu dürfen. Dies bedeutet, dass der Änderungsprozess für Risikodefinitionen oder der SoD-Matrix einem genau festgelegten Ände-rungsmanagementprozess unterliegen muss. Bei der erstmaligen Festlegung der Risikomatrix mit den Fachbereichen bei der Einführung von SAP GRC Access Control muss eine Abnahme der Risikodefinitionen durch die verantwortlichen Fachbereiche erfolgen, da ansonsten später im Betrieb (d.h. bei der Provisionierung von Benutzern und Berechtigungen) wieder „Diskussionen“ über die Risikoklassifizierung erfolgen könnten, falls es bei der Zustimmung für Berechtigungen zu Risikoidentifikationen kommen könnte.

Daher ist ebenfalls eine entsprechende verbindliche Richtlinie festzulegen, die den im Provisionie- rungsprozess beteiligten Personen eine eindeutige Handlungsanweisung im Falle von hohen, mittleren und niedrigen Risiken zur Hand gibt. Auf diese Weise erfolgt die Zuordnung von Berechti-gungen zu den Benutzern nicht mehr auf dem „Need to know“-Prinzip und den damit allseits verbundenen Diskussionen, was nun wirklich „Need to know“ darstellt, sondern auf Basis von ein- deutig definierten Funktionen und Zugriffsrisiken, welcher ein Berechtigungsantrag eines Anwen-ders inhärent beinhalten könnte. Auf diese Weise wird ein klarer Risikomanagementprozess für die Berechtigungsvergabe festgelegt, der Berechtigungsnotwendigkeit („Need to know“ aus dem Geschäftsprozess heraus) und Berechtigungsrisiken miteinander abwägt.

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

45

Wichtig ist es in diesem Kontext, auch angemessene und funktionsfähige, kompensierende Kon-trollen festzulegen, die, falls ein Zugriffsrisiko nicht vermeidbar ist, die Auswirkung des Risikos kompensieren. Dieses könnte z.B. eine manuelle Kontrolle sein oder aber auch eine automatische Kontrolle, die im SAP-System durch eine Konfiguration eingestellt werden könnte. Kompensierende Kontrollen müssen dabei einem Verantwortlichen zugeordnet werden, der den Inhalt der Kontrolle und auch den Durchführenden der Kontrolle festlegt. Die Festlegung von Kontrollen muss ebenfalls einem Änderungsmanagementprozess folgen. Da kompensierende Kontrollen einen nachgelagerten Ansatz verfolgen und daher meist in der Ausführung und Dokumentation aufwendig sind, sollte die Anzahl gering gehalten werden, da jede Kontrolle in das interne Kontrollsystem des Unternehmens aufgenommen werden sollte. Denn Ausnahmen, sprich Irregularitäten, müssen schnell durch den Fachbereich und auch den Risikomanager erkannt werden und entsprechend Gegenmaßnahmen eingeleitet werden können. Das entsprechende Änderungsmanagement für die Risikofestlegung und auch die kompensierenden Maßnahmen kann ebenfalls mit SAP GRC Access Control eingeführt werden. Hierfür wird mit Hilfe des Compliant User Managements und des darin enthaltenen Work-flow-Systems auch der Workflow zur Steuerung der Risikodefinition und der hierfür notwendigen kompensierenden Kontrollen festgelegt.

Eine häufig verwendete kompensierende Kontrolle ist das Superuser-Access-Management. In die-sem Fall wird dem Anwender temporär eine höhere Berechtigung zugeordnet, welche er mit einem hierfür festgelegten Beantragungsprozess und einer notwendigen Begründung beantragen kann. Der Verantwortliche einer Superuser-ID kann den Antrag genehmigen, wenn die Notwendigkeit aus dem Geschäftsprozess heraus gegeben ist. In diesem Fall werden aber mit Hilfe eines verbesserten Monitoring im System die Aktivitäten des Anwenders im System mitgeloggt und später durch einen definierten Controller ausgewertet werden, wenn der Zugriff mittels der Superuser-Berechtigung beendet ist. Das Ergebnis sollte in der festgelegten kompensierenden Kontrolle dokumentiert und so in das interne Kontrollsystem einfließen. Insgesamt erhält man auf diese Weise ein „rundes“ Risikomanagementkonzept, mit dessen Hilfe das sog. „Need to know“-Prinzip eindeutiger und besser umgesetzt werden kann.

6.1.2 ABGRENZUNG VON VERANTWORTUNGSBEREICHEN

Um den Risikomanagementprozess für das Berechtigungsmanagement in einem Unternehmen erfolgreich einzuführen, müssen die Aufgaben und Verantwortungsbereiche für die am Provisio-nierungsprozess für die Berechtigungsvergabe beteiligten Personen klar voneinander abgegrenzt werden. Zudem müssen die Fachbereiche in diesen Prozess einbezogen werden, da sie ansonsten ihre Verantwortung nicht akzeptieren werden und entsprechend, wie in der Vergangenheit gesche-hen, das Berechtigungsmanagement komplett als Aufgabe dem Informationstechnologiebereich (IT) übertragen. Indes sollte die IT nur eine unterstützende Verantwortung übernehmen und nicht eine, die die Entscheidung für die „Zuordnung“ von Berechtigungen trägt. Denn der IT-Bereich hat im Normalfall keine genaue Kenntnis über die Geschäftsprozesse und kann daher die Vertraulich-keit von Informationen und auch mögliche Geschäftsprozessrisiken nicht einschätzen, geschweige denn die entsprechende Entscheidung fällen.

46

Folgende im Unternehmen existierende Positionen sollten dabei die folgenden Aufgaben und Verantwortungen übernehmen:

Compliance Officer/IKS-Verantwortlicher:

Aufgaben:

› Mitarbeit und Freigabe der Prozesse, die durch GRC Access Control in das Unternehmen eingeführt werden.› Zustimmung bei Änderungen an der SoD-Matrix/Zugriffsrisiken.› Freigabe von kompensierenden Kontrollen in Hinblick auf die Angemessenheit der Kontrolle, d.h. „eignet sich die Kontrolle, um das Zugriffsrisiko zu kompensieren“.› Abnahme des Notfallbenutzer/-rollen-Verfahrens.

Zentrales Risikomanagement:

Aufgaben:

› Festlegung der Zugriffsrisiken in Übereinstimmung mit der konzernweiten Richtlinienvorgabe: Definition der Zugriffsrisiken, Bestimmung der Risikostufe und des Risikoverantwortlichen. Falls im Unternehmen ein Risikomanager verankert ist (Anmerkung: oftmals übernimmt dieser auch die Funktion des Compliance Officers), so ist es dessen Aufgabe, die genaue Risikobewertung für das Berechtigungsmanagement in Übereinstimmung mit der konzernweiten Richtlinien- vorgabe festzulegen. Hierzu gehören die Bewertungsschemata für die Festlegung der Vertrau- lichkeit, Verfügbarkeit und Integrität von Geschäftsinformationen und Ableitung der Risiko- definitionen und Risikolevel. Diese Vorgaben müssen bei der Bewertung der Risiken von SAP GRC Access Control und bei der Festlegung eigener Risiken durch die Risikoeigner der Fach- bereiche berücksichtigt werden. Im späteren operativen Betrieb kann der Risikomanager als überwachende Institution in den Provisionierungsprozess mit eingebunden werden. Er sollte dann überwachen, dass die Risikobewertungen durch die Fachbereiche im Provisionierungs- prozess und auch im Rollenänderungsmanagement entsprechend der Richtlinie durchgeführt werden.

Risikoverantwortliche:

Pro Fachbereich oder auch Geschäftsprozess (Anmerkung: dies hängt von der Strukturierung des Unternehmens ab) können Risikoverantwortliche für die Risiken des Fachbereichs festgelegt werden. Dieser muss die Befugnis bekommen, die Risikolevel und auch Risikodefinitionen im Namen des Fachbereichsvorstands oder Geschäftsprozesseigners festlegen zu dürfen. Hierfür benötigt er die Unterschriftsberechtigung. Auch muss der Risikoeigner später bei jedweder Beantragung zur Änderung einer bestehenden Risikodefinition seine Genehmigung erteilen.

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

47

Kontrollverantwortliche:

Auch bei der Festlegung von kompensierenden Kontrollen zur Eindämmung des Risikos, falls Benutzer auf Grund ihrer Berechtigungen als kritisch einzustufen sind, muss ein Eigner zur Festle-gung der Kontrolle aus dem betroffenen Fachbereich oder Geschäftsprozessbereich festgelegt werden. Der Eigner muss dabei nicht selbst die notwendigen Kontrollschritte durchführen, sondern muss die Inhalte, Dokumentationspflichten und den Kontrollausführenden festlegen. Der Eigner hat Sorge zu tragen, dass die Kontrolle zudem in der vorgesehenen Frequenz durchgeführt wird. Zudem muss er die Ergebnisse kontrollieren und bei entsprechender Identifikation von Verstößen oder Irregularitäten die entsprechenden Schritte zur Auflösung der Irregularität einleiten. Hierzu muss zudem ein klarer Eskalationsweg festgelegt werden. Es ist möglich, dass die Position Risiko- eigner und Eigner einer hierfür notwendigen kompensierenden Kontrolle durch eine Person über-nommen wird. Wieder ist es notwendig, dass bei einer Neuanlage einer kompensierenden Kontrolle oder auch bei der Änderung einer bestehenden Kontrolle der Eigner des Fachbereichs involviert wird und dieser zustimmt.

Rollenverantwortlicher/Datenverantwortlicher:

Eine sehr wichtige Voraussetzung für den Einsatz von SAP GRC Access Control ist die Bestimmung von Rollenverantwortlichen aus den Fachbereichen, die bei entsprechender Anfrage einer Rolle durch einen Anwender um Zustimmung gefragt werden. Die Rollenverantwortlichen werden in der Regel auf Basis der Datenverantwortlichkeit festgelegt. Der Rollenverantwortliche muss bei jedem Antrag entscheiden, ob der angeforderte Benutzer Zugriff auf die Daten erhält oder nicht.

Interne Revision:

Aufgaben:

› Überprüfung der kompensierenden Kontrollen in Hinblick auf Angemessenheit, Funktions- fähigkeit und somit Wirksamkeit.

Die interne Revision sollte bei der finalen Abnahme der Risikomatrix beteiligt werden. Zudem muss die Einhaltung der Prozesse und Änderungsbelege durch Internal Audit überprüft und überwacht werden.

Informationstechnologie (SAP Competence Center):

Das-SAP Berechtigungsteam, das früher vor allem ausführende Befugnis hatte, wird durch den Einsatz von SAP GRC Access Control in eine mehr beratende und überwachende Funktion zurück-

48

gedrängt. Es ist Aufgabe des SAP-Berechtigungsmanagement-Teams, das „Funktionieren“ der Pro-zesse sicherzustellen und auch beratend für die Fachbereiche tätig zu sein. Zudem sollten nach wie vor das Berechtigungsdesign und die dafür notwendigen technischen SAP-Rollen in der ersten Implementierung durch Enterprise Role Management in der Führung bleiben. Es sollten hierzu die fachlichen Anforderungen aus den Fachbereichen aufgenommen werden und anhand des vor- gegebenen Rollenkonzepts in eine technische Umsetzung überführt werden. Bei entsprechender Änderung einer bestehenden Rolle oder Aufsetzung einer neuen Rolle muss aber auf jeden Fall der Rolleneigner des Fachbereichs zustimmen und entsprechend auf Vorhandensein eines Risikos hin überprüfen. Auch muss der SAP-Betrieb die notwendigen technischen Änderungen für die Lösung selbst durchführen und wie bei jeder anderen SAP-Software selbst die technische Überwachung durchführen und somit den Betrieb sicherstellen.

6.1.3 CHANGE MANAGEMENT POLICY + RISIKOPOLICY

Durch die Einführung von SAP GRC Access Control werden Prozesse wie Benutzermanagement-prozess, Rollenmanagementprozess und Superuser-Managementprozess in das Unternehmen eingeführt. Des Weiteren müssen noch zusätzlich die Prozesse zur Verwaltung des Regelwerks und der Zugriffsrisiken sowie die Verwaltung der kompensierenden Kontrollen festgelegt werden.Sowohl die Aufbauorganisation als auch die Ablauforganisation und relevante Vorgaben sollten in einer Richtlinie dokumentiert werden.

Die Richtlinie sollte Vorgaben hinsichtlich der Aufnahme und Festlegung von Zugriffsrisiken bein- halten, d.h., wann wird ein Risiko mit welcher Risikostufe im System aufgenommen und welche verantwortlichen Bereiche müssen zustimmen.

Vorgaben für Risikostufen:

Als Grundlage für die Festlegung von Risiken könnte beispielsweise eine Bewertung der im Ge- schäftsprozess verarbeiteten Informationen vorgenommen werden, die auf Basis von Vertraulich-keits-, Integritäts- und Verfügbarkeitsanforderungen bewertet werden. Dadurch könnte bereits ein Zugriffsrisiko bei der Anzeige von Stücklisten für ein Unternehmen existieren, falls diese Information einen bedeutenden Wettbewerbsvorteil für das Unternehmen darstellt. Auch bei Finanztransaktions- daten kann es aufgrund der hohen Integritätsanforderung notwendig sein, dass ein Vier-Augen- Prinzip bei der Weiterbearbeitung erforderlich ist, um betrügerischen Handlungen oder auch einfach „fahrlässigen“ Freigaben entgegenzuwirken.

Risiken, die durch betrügerische Handlungen oder einfach durch Fahrlässigkeit begründet sind und die demnach einen direkten hohen materiellen und/ oder finanziellen Schaden nach sich ziehen können, sollten als hoch eingestuft werden. Risiken, die zu einem Reputationsschaden führen können oder die z.B. auch durch die Verletzung der Vertraulichkeit von Informationen (Preisinformationen, Materialstammdaten, spezifische Stück-listeninformationen, Gehaltsdaten etc.) hervorgerufen werden, sollten als hoch eingestuft werden. Zu dieser Klasse sollten auch Risiken in Hinblick auf Betrug zugeordnet werden, die nicht zu einem

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

49

direkten materiellen oder finanziellen Verlust führen können, wie z.B. fiktive Kundengeschäfte zur „Steigerung“ des Unternehmenswertes.

Zu den mittleren und niedrigen Risiken gehören Risiken wie bspw. das Kontieren von Kosten auf eine falsche Kostenstelle, was jedoch keine Auswirkungen auf die Gesamtbilanz hat.

Zusammengefasst ist es bei der Einführung von SAP GRC Access Control wichtig, dass Vorgaben in Form einer Richtlinie den später im Änderungsmanagement von Rolleninhalten (also letztend-lich den SAP-Berechtigungen) und Rollenzuordnungen zu Endanwendern beteiligten Entscheidern (hauptsächlich Rolleneigner, Risikomanager und Linienvorgesetzte) hilft, die Entscheidungen auf Basis einer klaren Richtlinie und nicht auf Grund von „Gefühlen“ zu treffen.

Das Gleiche gilt indes auch für die Definition der Risiken durch Risikoverantwortliche bzw. das Risikomanagement. Hier sollten Vorgaben existieren, in welchem Fall ein Risiko als hoch, mittel oder niedrig einzustufen ist.

Vorgaben für die Kompensierung von Zugriffsrisiken:

Im Benutzermanagementprozess werden im Betrieb Berechtigungen für Benutzer von SAP- und/ oder Nicht-SAP-Systemen beantragt. Im Falle, dass ein Antrag Risikoverletzungen beinhaltet, müssen Vorgaben existieren, wie mit den Risiken basierend auf ihren Stufen umgegangen werden muss. Beispielsweise könnte es die Vorgabe geben, dass hohe Risiken niemals eingegangen werden dürfen und somit der Antrag immer abgelehnt werden müsste. Im Falle von mittleren Risiken müsste zumindest eine kompensierende Kontrolle zugeordnet werden und niedrige Risiken dürfen eingegangen werden.

Prozessdefinitionen:

Des Weiteren sollte die Richtlinie die folgenden Prozesse basierend auf den implementierten Komponenten von GRC Access Control definieren, wobei mit Verwaltung immer das Anlegen, Ändern oder Löschen des entsprechenden Geschäftsobjekts gemeint ist:

› ARA: Verwaltung der Zugriffsrisiken› ARA: Verwaltung der kompensierenden Kontrollen› BRM: Verwaltung der Rollen der angebundenen Systeme› ARM: Verwaltung der Benutzer der angebundenen Systeme› EAM: Superuser-Management: Für welche Szenarien wird das Superuser-Management eingesetzt.› EAM: Superuser-Management: Verwaltung der Notfallbenutzer, Verantwortlichen und Kontrolleur für ein entsprechendes Szenario

6.1.4 REPORTING / MONITORING

Einer der wichtigsten Vorteile, der durch den Einsatz von SAP GRC Access Control gegenüber traditionellen SAP-Tools (PFCG, SU01 etc.) entsteht, ist die Möglichkeit, für alle durchgeführten

50

Änderungen an Rollen und Rollenvergaben Änderungsprotokolle zu führen, die für einen späteren Audit die entsprechende Evidenz bereitstellen (Audit Trail). Durch die Änderungsbelege werden die gesetzlichen Vorgaben und auch die Ziele der internen Kontrolle effizienter erreicht. Zudem können auch freiwillige Compliance-Vorgaben für Security-Normen, wie z.B. der ISO 27001/2-Norm, einfacher erfüllt werden.

Eine weitere und sehr wichtige Funktion von SAP GRC Access Control ist aber durch die geordnete Protokollierung von Aktivitäten und durchgeführten Änderungen im SAP-System gegeben, wodurch ein Superuser-Management erreicht werden kann. In diesem Fall werden höhere Berechtigungen nur temporär an Antragsteller vergeben und der Antragsteller muss auch eine Begründung angeben, warum sie/er die höheren Berechtigungen für den Geschäftsprozess benötigt. Diese Begründung ist ebenfalls als Auditevidenz später verwendbar. Zudem wird bei der Annahme der höherwertigen Berechtigungen auch die Protokollierung im SAP-System gestartet und die Aktivitäten des Benut-zers mit protokolliert. Diese Änderungsbelege müssen dann durch den Eigner der Superuser-Id im Nachgang ausgewertet werden und bei entdeckten Unregelmäßigkeiten müssen die Gegenmaß-nahmen über die Eskalationswege ausgelöst werden.

Folgende Grundregeln sollten bei der Einführung eines Superuser-Access-Managements berück-sichtigt werden, bzw. in der Richtlinie festgehalten werden:

1. Das Superuser-Access-Management darf nur für den Notfall verwendet werden, da ansonsten die Gefahr besteht, dass die höherwertigen Berechtigungen für das Tagesgeschäft verwendet werden und nicht für den Notfall. Das eigentliche Berechtigungskonzept würde auf diese Weise unterlaufen werden.

2. Den Superuser-IDs sollten keine SAP_ALL-Berechtigungen zugeordnet werden, sondern wirklich nur höherwertige Berechtigungen beinhalten, die für den jeweiligen Fachbereich im Notfall notwendig sind. So z.B. für den IT-Bereich die Berechtigung „Öffnen des Mandanten“ in einer dedizierten Superuser-ID. Das Gleiche z.B. für den Fachbereich Finanzen und Cont- rolling, wie z.B. „Kontenplan anpassen“.

3. Die Eigner der jeweiligen Superuser-IDs müssen verpflichtet sein, die Änderungsbelege nach deren Gebrauch durch einen Antragsteller zu reviewen und nach entsprechenden Unregel- mäßigkeiten zu untersuchen. Bei einer entsprechenden Identifikation einer solchen Unregel- mäßigkeit sind die Eigner verpflichtet, über einen vorgegebenen Eskalationspfad Gegenmaß- nahmen einzuleiten.

4. Bei jeder Beantragung einer Superuser-ID sollte eine nachvollziehbare Begründung durch den Antragsteller gegeben werden.

5. Das Recht, eine bestimmte Superuser-ID für den Notfall verwenden zu dürfen, sollte nur auf Zeit vergeben werden und nicht auf Dauer.

6.1.4.1 Reporting der Risikoanalyse

Eine wichtige Eigenschaft von SAP GRC Access Control ist die Möglichkeit des Reportings auf

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

51

verschiedenen Managementebenen. Aus grafisch aufbereiteten zusammenfassenden Berichten für das obere Management besteht die Möglichkeit, im Drill-down-Verfahren bis auf Detailberichte zu navigieren. Berechtigungsadministratoren werden durch Detailberichte der Benutzer-, Rollen- und Profilanalyse in ihrer täglichen Arbeit unterstützt. Das Authorisierungskonzept im SAP GRC Access Control ermöglicht dabei die Strukturierung der Zugriffsebenen. Die Reportingstrukturen werden durch spezielle Risikoanalysen der Hintergrundverarbeitung (BRA – Batch Risk Analysis) gefüllt und stehen dann bis zum nächsten BRA-Lauf unverändert zur Verfügung. Die Daten des letzten BRA-Laufes eines Monats werden festgeschrieben und stehen anschließend für historische Auswertungen und Vergleichsanalysen sowie für Trendanalysen zur Verfügung.

6.1.4.2 Berichte der Zugriffsanforderung

Die Aktivitäten der Benutzer- und Berechtigungsadministration im Bereich des GRC AC Access Request Management werden lückenlos protokolliert und stehen insbesondere für Auditierungs-zwecke zur Verfügung. Benutzer- und Rollenanforderungen werden mit Hilfe des SAP Standard Workflow prozessiert, wobei jeder Anforderungs- und Genehmigungsschritt protokolliert wird und detailliert ausgewertet werden kann. Die üblichen formularbasierten oder ticketbasierten Protokollierungsverfahren sind somit obsolet oder dienen bei einem möglichen Ausfall des GRC- AC-Systems als Ausnahmeverfahren. Für den Fall von auftredenden Risiken bei der Rollenvergabe werden die Aktivitäten zur möglichen Mitigierung des Riskos ebenfalls protokolliert und stehen dem Reporting zur Verfügung.

6.1.4.3 EAM-Verwaltungsberichte

SAP GRC Access Control ab Version 10.0 stellt ein zentrales Verfahren zur Einrichtung, Verwaltung und zur Auswertung des Emergency Access Management (EAM, FireFighter) zur Verfügung. Die zentrale Zuweisung von Benutzern zu FireFightern, die Nutzung von FireFightern und die Prozes-sierung der Protokolle können im Reporting nachverfolgt und belegt werden. Gleiches gilt für die Nutzung des rollenbasierten EAM.

6.1.5 OPERATIVE EINZELAUFGABEN UND PROJEKTPLANUNG

› Projektplan-Entwurf: Wie für jedes andere Projekt auch muss in der Strategie & Planungsphase ein detaillierter Projektplan inkl. des Projektteams festgelegt werden. Ganz wichtig ist die Einbe- ziehung der Fachbereiche in die Kommunikation und deren Unterstützung, da diese später Veränderungsprozesse mitinitiieren (Rolleneigner). Themen des Projektplans sind Rollenkonzept (inkl. Umgang mit den neuen Business Roles) und auch die Festlegung der Risikomatrix.

› Projekt-Kick-off: In einem initialen Meeting werden nochmals die genauen Ziele des Projektes, der vorgesehene Zeitplan, die zu erarbeitenden Arbeitsergebnisse und das Team selbst vorgestellt.

› Analyse des bestehenden SAP-Berechtigungskonzepts: Mit Hilfe einer sorgfältigen Analyse muss der derzeitige Status quo des SAP-Rollenkonzepts, Informationseigentümerprinzip, Rollenstruktur, Vererbung, existierendes Beantragungswesen, Prozesse der Rollen- und

52

Berechtigungspflege und -administration sowie eventuell bestehende Risikomatrix und Risiko- managementprozesse evaluiert werden. Ziel ist festzustellen, inwieweit der „Reifegrad“ für die Einführung von SAP GRC Access Control in der Organisation vorhanden ist.

Das Berechtigungskonzept in einer IT-Landschaft ist die Basis für die Benutzerzuordnung und damit für ein Identity-Management (IdM), für die Steuerung von Abläufen und Prozessen, für Audits und Compliance, für das interne Kontrollsystem mit Risikomanagement, um nur einige aufzuzählen. Dabei lauten die Anforderungen:

› sichere Zugriffe auf Funktionen und Daten › Risikoüberwachung mit Funktionstrennung oder Kontrollen › Flexibilität bei Rollenanpassung (z.B. bei organisatorischen Änderungen) und Transparenz für die Fachbereiche (z.B. für die Beantragung) › klare Verantwortlichkeit für die Rechte (Rolleneigner) › einfache Bearbeitung, Change-Management und kontinuierliche Qualitätssicherung

Abbildung 7: Anforderungen an ein Berechtigungssystem

Prozesse Abläufe

Benutzer- verwaltung

Audits Compliance

IKS / Risiko-MGmt

Lizenzierung Programm- Navigation

e SOA

› Risikoüberwachung / Funktionstrennung› Flexibilität und Transparenz› klare Verantwortlichkeit (Data-Owner-Konzept) › einfache Bearbeitung, Change-Managment und Qualitätssicherung› Investitionsschutz und Wirtschaftlichkeit

› Unternehmensleitung › Organisation› Wirtschaftsprüfer › interne Revision› Gesetze und Verordnungen › ...

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

53

Allerdings ist es selbst bei einem zunächst sehr stringent aufgebauten Berechtigungswesen durch- aus typisch, dass sich mit der Zeit Rechteanhäufungen ergeben. Ursache hierfür sind die normalen Änderungsprozesse der funktionalen Rollen und Aufgaben im Unternehmen, die sich über Jahre hinweg durch diverse Einflüsse (Upgrade, neue Organisationseinheiten, geänderte Prozesse, neue Module, externe User) ergeben. SAP-ERP (ABAP-Stack) besitzt ein sehr umfangreiches Berechti- gungs- und Rollensystem, durch das es möglich wird, beinahe alle Belange von Zugriffen einzu-schränken und auch sehr selektiv Daten schützen zu können. Diese vielfältigen Möglichkeiten brin-gen jedoch zwangsläufig auch eine Komplexität mit sich, die ab einem gewissen Verflechtungsgrad von Rollen, Profilen und Berechtigungsobjekten kaum noch durchschaubar ist. Aus diesem Grund ist eine genaue Analyse des Zustands des Berechtigungswesens zwingend erforderlich: Entweder ergibt sich aus dieser als Ergebnis ein falsches Design (bzw. die Anforderung an einen mehr oder minder vollständigen Neubau des Berechtigungswesens) oder lediglich eine überschaubare Anhäufung von Verletzungen von Funktionstrennungsanforderungen mit der Möglichkeit einer einfa-chen Bereinigung. Für beide Situationen kann dann GRC Access Control mittels der Risikoanalyse- Komponente unterstützend eingesetzt werden.

Die Ergebnisse der Bewertung (Redesign oder Bereinigung) fließen dann entsprechend in die endgültige Projektplanung ein.

Unterstützend sollte in dieser Phase GRC Access Control als Werkzeug bereits zum Einsatz kommen. Dabei reicht die Installation eines Entwicklungssystems oder ggf. sogar eine Sandbox-Installation, da lediglich die Risikoanalyse verwendet wird.

Die Strategiephase muss die technische Installation von SAP GRC Access Control berücksichtigen. Dort wird das bestehende SAP-Rollenkonzept hinsichtlich seines „Reifegrades“ bezüglich beste- hender Risiken (Segregation of Duties, kritischer Transaktionen) überprüft und auch das Kernpro-jektteam hinsichtlich der Verwendung der Lösungskomponenten von SAP GRC Access Control geschult. Zu diesem Zweck sollte die Lösung auf einer Entwicklungsumgebung installiert werden und mit dem entsprechenden SAP-Backendsystem (am besten demjenigen, in dem die Hauptge-schäftsprozesse implementiert sind) verbunden werden. Dieses Backendsystem sollte das Rollen-konzept der Produktionsumgebung beinhalten.

Zwei Möglichkeiten zur Durchführung der ersten Risikoanalyse bieten sich an:› man verwendet die mitgelieferten umfangreichen Standardprüfregeln (Normalfall) oder› man erstellt – ggf. auf Basis des mitgelieferten Standards – unternehmensindividuelle Prüfregeln.

Welche Variante auch immer gewählt wird: Das Ergebnis wird eine Vielzahl von potenziellen Risiken liefern, unabhängig davon, ob „nur“ auf Berechtigungsebene oder auch auf Benutzerebene (mit oder ohne Einbeziehung der Berechtigungsobjekte) analysiert wird.

54

Die mitgelieferten Prüfregeln innerhalb von SAP GRC Access Control sind vollumfänglich für große Unternehmen vorgefertigt und enthalten eine Vielzahl von Risiken mit kritischen Funktionskombi-nationen – abgeleitet aus den Erfahrungen einer Vielzahl von Revisionsprüfungen. Jede dieser dort beschriebenen Funktionen besteht aus einer bis zu mehreren Transaktionen. Bei der Analyse werden diese Funktionen in ihre Transaktionen – und ggf. auch in die Berechtigungsobjekte – aufgelöst, was die Risikomatrix erheblich vergrößert. Sollte jedoch dieser Ansatz gewählt werden, empfiehlt es sich, ggf. gleich noch einige sehr kritische Funktionen (keine SoD-Konflikte) im Basis- umfeld mit aufzunehmen. Dies sind insbesondere die Berechtigungen zum Debugging mit Replace, die Berechtigungen zum Import von Transportaufträgen, die Berechtigungen zum Einstellen von System- und Mandantenänderbarkeit sowie die Berechtigungen zum elektronischen Radieren (Löschen von Änderungsbelegen, Version etc). Diese sind im SAP-Standardregelwerk in der Form nicht enthalten.

Ein erster Durchlauf von ARA ergibt oft Risikoberichte mit Risikoverletzungen im fünf- und mehr-stelligen Bereich. Dies sollte nicht abschrecken, denn solche Ergebnisse sind typisch und bei einem gewachsenen Berechtigungswesen durchaus normal, selbst wenn dieses augenscheinlich gut ge-pflegt sein sollte. Insbesondere SAP_ALL-Zuweisungen oder die Zuweisung ähnlich umfangreicher Rollen und Profile ergeben eine erhebliche Anzahl von Risikoverletzungen, die aber mit einfachen Mitteln dann auch schnell verringert werden können mittels Reduzierung des Rollenumfangs oder Anpassung der Benutzer. Allerdings erschweren diese Ergebnisse, die ja zunächst nur für eine Bewertung von Redesign vs. Bereinigung verwendet werden sollen, zunächst entsprechende Schluss- folgerungen. Daher sollte dieser Ansatz mit Umsicht gewählt werden.

Grundsätzlich muss das Ergebnis dieser Risikoanalyse zuallererst so reduziert werden, dass eine diskussionsfähige Auswertung nur noch die Risiken aufweist, die für IT, internes Audit und Fachbereiche verständlich, bewertbar und entscheidungsfähig sind. Erst im weiteren Verlauf des Projektes kann dann die Kontrollmatrix auf die Governance-Anforderungen des eigenen Unter-nehmens angepasst werden, damit daraus letztendlich saubere, überschaubare und transparente Funktionstrennungsvorschriften bzw. kompensierende Kontrollen ableitbar sind.

Die ersten umfänglichen Risikoanalyseergebnisse sollten nach folgender Methode überarbeitet werden:

› Schritt Benutzer ausklammern: mögliche Poweruser (mit Administration- und Notfallrechten) aus der Analyse ausschließen, da diese später sowieso mit Kontrollen versehen werden. Ebenso die User ausschließen, die später keine Rolle mehr spielen (z.B. spezielle Notfalluser!).

› Schritt Transaktionsgleichheit: die Risiken nachbearbeiten bzw. löschen, in denen rechts und links dieselbe Transaktion als Konflikt steht (dabei ggf. Berechtigungsausprägung beachten!).

› Schritt Kreuzkonflikte: die Kreuz-Risiken nachbearbeiten bzw. löschen, wo im Risiko (a) TR1 mit TR2 im Konflikt und im Risiko (b) TR2 mit TR1 im Konflikt stehen (dabei ggf. Berechtigungs- ausprägung beachten!).

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

55

› Schritt prozessualer Verbund: Separierung der Transaktionen in unterschiedliche Einzelrollen, wenn eine Trennung dieses Transaktionspaares operational unschädlich ist (der Prozessdurchlauf dadurch nicht behindert wird!).

Ein weiterer Durchlauf der Risikoanalyse – nach Überarbeitung der Prüfregeln – wird den Erfolg zeigen; ggf. muss dieses Verfahren ein weiteres Mal (iterativ) durchgeführt werden, um zum gewünschten diskutablen Ergebnis zu gelangen.

Das geschilderte Verfahren bezieht sich auf die Standard-Transaktionen. Zusätzliche Risiken können sich wegen der Nutzung eigenentwickelter Transaktionen ergeben. Hier hilft ein meist nur mittel-fristig realisierbares Konzept der Analyse dieser Y-/Z-Transaktionen. Dabei erkennbare kritische eigenentwickelte Transaktionen müssen in die Risiko- und Funktionsdefinition mit aufgenommen werden, um später eine umfassende, unternehmensweite Kontrolle durchführen zu können.

Sind bei einem erneuten ARA-Durchlauf dieser dann „überarbeiteten und gefilterten“ Analyse immer noch zu viele Risiken übrig geblieben und nicht mehr einfach aufzulösen (Anzahl sowie Art), muss entschieden werden, ob das bestehende Rollenkonzept ggf. komplett neu entworfen werden soll.

Darüber hinaus sind folgende Risikomanagement-Richtlinien festzulegen:

› Verantwortung für die Definition von Risikoregeln wie Funktionstrennungsrisiken, kritische Transaktionen und kritische Leseberechtigungen,› Verantwortungen für die Definition von kompensierenden Kontrollen,› Festlegung der Risikolevel und Bewertung der bestehenden Risiken,› Festlegung der Richtlinie für die Ablehnung/Zustimmung mit kompensierenden Kontrollen für Berechtigungsanfragen,› Festlegung einer Richtlinie für den Superuser-Zugriff („Firefighter-Konzept“),› Festlegung der Rollen im Risikomanagementprozess wie z.B. Compliance Management, Risikoeigner und Verantwortlicher von kompensierenden Kontrollen.

Im Zusammenhang mit SAP GRC Access Control muss festgelegt werden, ob SAP GRC Access Control das führende (zentrale) Benutzermanagement-System sein soll, das die weitere Provi-sionierung der Identitäten in die Zielsysteme durchführt. Hierzu muss untersucht werden, ob SAP GRC Access Control eventuell auch an ein bestehendes oder neu einzuführendes Identity-Manage- ment-System angeschlossen werden soll. Ziel dieses Arbeitspakets ist es, die bestehenden Identity- Management-Prozesse und Genehmigungs-Workflows für die Verwendung von SAP GRC Access Control anzupassen.

Für SAP GRC Access Control muss ein Architekturkonzept in Abhängigkeit der gewünschten oder vorgeschriebenen Systemarchitektur, z.B. „Drei Systemlandschaft“ wie Entwicklung, Qualitäts-sicherung und Produktion, festgelegt werden. In Abhängigkeit der gewählten Systemlandschaft müssen die Verfahren für technische Änderungen an der Lösung, Rollen- und Risikomatrixände-rungen sowie Benutzermanagement definiert werden (wo wird getestet, wo wird genehmigt/verteilt und mit was für Ständen).

56

Es ist ratsam, schon in der Strategiephase ein erstes Training für das Kernteam aller Komponenten von SAP-GRC Access Control durchzuführen. Dies ermöglicht, die Übertragung der Konzepte auf die Anforderungen der SAP-GRC-Lösung zu erleichtern.

Strategischer Meilenstein für Neuentwicklung Rollenkonzept oder Adaption des bestehenden Konzeptes: Ein wichtiger Meilenstein ist die Entscheidung für die eventuell komplette Neuentwick-lung des Rollenkonzeptes oder dessen sanfte Anpassung. Auf Grund des Resultats der initialen Risikoanalyse mit dem bestehenden Rechtesystem und der Anzahl und Art von aufgetretenen Risiken, der genauen Zuordnung von Rollen zu einem eindeutigen Rolleneigner und der Rollen- struktur muss entschieden werden, ob eine komplette Überarbeitung des SAP-Rollenkonzeptes zur Einführung von SAP GRC Access Control sinnvoll, machbar und wirtschaftlich vertretbar ist. Sind die bestehenden Konflikte eher gering und können eindeutige Rolleneigner aus den Fachbereichen zugeordnet werden, so kann das Rollenkonzept auch entsprechend durch einfacheres „Splitten“ von den Konflikten bereinigt werden. Falls sehr viele Konflikte vorhanden sind, kann mit einem Reverse-Business-Engineering-Ansatz oder mit einem funktionsorientierten ReDesign-Ansatz das SAP-Rollenkonzept recht effektiv auf die Anforderungen von SAP GRC Access Control angepasst werden.

Es ist nicht einfach, den Ressourcenbedarf für Anpassung oder Überarbeitung bzw. Neuerstellung bei hohem Sicherheits- und Qualitätsanspruch, Erfüllung der Vorschriften sowie einer sehr guten Transparenz (verständliche revisionsgerechte Dokumentation) zu quantifizieren. Zwingend ist jedoch, diese Zahlen zu ermitteln und miteinander zu vergleichen, das Für und Wider abzuwägen und sich dann für einen der Wege festzulegen. Für das Reverse Business Engineering und auch für das funktionsorientierte Redesign existieren auf dem Markt Werkzeuge und Methoden, die das Projekt erleichtern und auch zeitlich deutlich verkürzen. „Nur“ eine einfache Überarbeitung der betroffenen Rollen stellt sich bei komplexen Berechtigungskonzepten aus Erfahrung immer als schwieriger und langwieriger dar als gedacht.

Finalisierung des Projektplanes: In Abhängigkeit von den getroffenen strategischen Entscheidun-gen und Konzepten muss der Projektplan angepasst werden. Der Aufwand sollte neu evaluiert und festgelegt werden, zudem muss der Zeitplan nochmals abgestimmt und verabschiedet werden. Danach ist die Strategiephase abgeschlossen.

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

57

6.2 PHASE SOLLKONZEPTION („BUSINESS BLUEPRINT UND DESIGN“)

In der Business-Blueprint-Phase werden die getroffenen strategischen Konzepte weiter verfeinert und im Detail festgelegt. Dies kann nun im Wesentlichen für die vier Hauptkomponenten von SAP GRC Access Control „Risikoanalyse und Beseitigung“, „Unternehmensweites Rollenmanagement“, „Management von Superuser-Berechtigungen“ sowie „Regel- und gesetzeskonforme Berechti-gungsvergabe“ durchgeführt werden, wobei übergeordnete Aspekte wie technische Architektur und auch Risikomanagementprozessdesign und Organisation (Definition von Rollen für die Verwendung von SAP GRC Access Control selbst) für alle Komponenten betrachtet werden müssen. Auch sollte in dieser Phase schon ein entsprechendes Testkonzept der Prozesse und Integrationsabläufe fest-gelegt werden.

Die folgenden Hauptarbeitspakete sollten pro Komponente betrachtet werden.

6.2.1 ORGANISATORISCH/TECHNISCHER BETRIEB

Zunächst sollte festgelegt werden, ob auf einer zentralen Plattform ggf. ein verteilter Betrieb in der Organisation notwendig ist und wie stark die jeweilige Separation der Anwendergruppen und Daten im System ausgeprägt sein muss, ohne umfangreich administrativ doppelt Pflegetätigkeiten ausüben zu müssen. Ergebnis dieser Überlegungen sollte sein:

› Werden ein oder mehrere Produktivsysteme benötigt? (Ggf. immer wieder Replikationen eines Risikomatrix-Standards notwendig, dafür aber evtl. der Patch-Prozess auch einfacher)› Werden bei einem Produktivsystem mehrere Mandanten benötigt?› Kann ggf. mit einem Produktivsystem und einem Mandanten (und entsprechend gemeinsamen Daten) gearbeitet werden mit reiner Aussteuerung der gewünschten Separation über das Berechtigungswesen im SAP GRC Access Control?

Zur Bewertung dieser Punkte empfiehlt es sich auch, den Security Guide zu SAP GRC Access Control zurate zu ziehen, um die Möglichkeiten bei der Berechtigungsaussteuerung abschätzen zu können. Grundsätzlich muss hier auch bei der gewünschten organisatorischen Separation eine Abwägung mit den Kosten der jeweiligen Lösung durchgeführt werden.

Ein wichtiger Punkt, den es dabei besonders zu berücksichtigen gilt, ist der von der SAP festgesetzte Kopplungsbetrieb mit den in den Backends installierten Plug-ins: Bis SAP GRC Access Control 10.0 SP9 arbeiten die jeweiligen Frontend-SPs nur mit ausgewählten Backend-SPs zusammen, eine Abwärtskompatibilität wurde nicht zugesichert. Dies hat insbesondere bei einer höheren Anzahl von angeschlossenen Backends ganz erhebliche Auswirkungen auf die Patch-Strategie und Wartungsfenster für die Applikation, da gerade bei großen verteilten Organisationen kaum ein ge- meinsames Patch-Wochenende gefunden werden kann.Daher müssen bei AC5.3 und bei AC10.0 mit Patchständen kleiner SP10 vorab ggf. umfangreiche Tests mit SP-Kombinationen durchgeführt werden, deren Kombinations-Betrieb die SAP nicht zusichert. Hierzu ist eine genaue Betrachtung des Hinweises 1352498 („SAP GRC Access Control: Support-Package-Nummerierung“) ratsam. Zu beachten gilt aber auch hier die Möglichkeit der Einspielung von Vorabkorrekturen, die diese Problematik einigermaßen abschwächt.

58

6.2.2 ARCHITEKTUR & TECHNOLOGIE:

› Detaillierter Blueprint der technischen Architektur: In der Designphase sollte der Blueprint der technischen Architektur festgelegt werden. Es sollte zudem ein Staging-Konzept inklusive Entwicklungs-, Qualitätssicherungs- und Produktionsumgebung für die Lösung SAP GRC Access Control festgelegt werden. Dies sollte auch die Änderungsmanagementprozesse für die Rollen und technische Upgrades berücksichtigen. So sollte betrachtet werden, dass z.B. Rollen- änderungsprozesse auf der Entwicklungsumgebung stattfinden und entsprechend nach Freigabe über das Transportwesen in die Produktionsumgebung über den Schritt Qualitätssicherung transportiert werden. Die Provisionierung zu den Anwendern kann in der Produktionsumgebung erfolgen. Zudem muss der führende Benutzerspeicher festgelegt werden, von welchem aus die Provisionierung in die Zielsysteme stattfinden kann. Diese Aspekte sind maßgebende Einfluss- faktoren für die technische Architektur. Des Weiteren muss die Integrationsarchitektur mit einem möglichen Identity & Access Management System (z.B. SAP NetWeaver Identity Management) festgelegt werden. Hierzu müssen die technischen Schnittstellen und Konnektoren für die Directory Services im Detail ausgewählt werden.

Sollen Non-SAP-Systeme mit angebunden werden, so stehen beispielsweise für Oracle Finan- cials, JD Edwards, Peoplesoft entsprechende Plug-ins zur Verfügung. Bei Anbindung einer ande- ren Software sind ggf. eigenentwickelte Konnektoren zu verwenden. Bei den eigenentwickelten Konnektoren ist das Matching der einzelnen Berechtigungselemente des Non-SAP Systems zu den Feldern von SAP GRC Access Control zu beachten. Aufbauend auf diesem Matching ist auch das Regelwerk entsprechend zu erstellen.

› Design der notwendigen Batchprozesse: Auch für SAP GRC Access Control müssen entspre- chende Batchprozesse festgelegt werden, die z.B. den Abgleich der Berechtigungsvorschlags- werte und Objekte aus den Zielsystemen regeln. Dies sollte entsprechend im Blueprint festgelegt werden.

› Installations-, Konfigurations- und Betriebsmanual: Für die technische Installation und Konfiguration muss ein kundenspezifisches Dokument erstellt werden, welches die notwendigen Hauptschritte zur Installation und Konfiguration entsprechend dokumentiert. Dieses dient zudem als Basis für ein Betriebshandbuch, das zum späteren Betrieb von SAP GRC Access Control notwendig ist. Hier sollten z.B. die notwendigen Schritte zur Fehlerbehandlung und die Upgrade- strategie (z.B. im Fall eines Upgrades auf einen neuen Regelsatz) festgelegt sein.

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

59

6.2.2.1 Harmonisierte Konfigurations- und Stammdatenverwaltung

Grundsätzlich bietet GRC Access Control eine vereinheitlichte Konfiguration und Stammdatenbasis für alle Komponenten und Applikationen an. Hierzu ist daher in der Konzeptionsphase wichtig, zu entscheiden, welche Komponenten und Applikationen ggf. gleichzeitig in einem Mandanten ver-wendet werden. So ist z.B. zu beachten, dass bei einer gleichzeitigen Verwendung von GRC Access Control und Process Control ggf. dasselbe Organisationsmanagement verwendet wird. Darüber hinaus sind einige Schalter und auch Workflow-Elemente nur zentral konfigurierbar. Dies hat einerseits Vorteile (keine Doppeltpflege), schränkt aber ggf. die Flexibilität ein.

6.2.2.2 Vereinheitlichtes User Interface & Bedienung

Die Einstiegspunkte und Funktionen der Komponenten (EAM, ARA usw.) sind auf einer für den NWBC designten Oberfläche strukturiert und angeordnet. Über das Berechtigungswesen des ABAP-Sys-tems gibt es hier umfangreiche Möglichkeiten, hier sowohl einzelne Einstiegslinks als auch ganze Navigationsgruppen sichtbar oder unsichtbar (und damit nicht ausführbar) zu konfigurieren. Diese Aussteuerung erfolgt dann rollenbasiert, d.h. je nach Rolle, die ein Anwender bekommt (SU01), kann er Funktionen sehen und verwenden oder nicht. Dies sollte beim Design der Anwendergruppen und der Benutzeroberflächengestaltung für diese berücksichtigt werden. Die zusätzlichen Bedienungs- merkmale der Webdynpro-ABAP-Oberfläche sowie die Verwendung von personalisierten Queries und ALV-Listen sollte in Trainingshandbücher für Endanwender mitaufgenommen werden, da sie die Arbeit im SAP GRC Access Control erheblich vereinfachen und effizienter gestalten.

6.2.3 RISIKOANALYSE UND BEREINIGUNG

Bestimmung der wichtigsten Informationswerte der Geschäftsbereiche als Grundlage für die Risikobewertung:

Eine wichtige Grundlage zur Bestimmung von Geschäftsrisiken, die durch betrügerische Hand-lungen (wegen fehlender Funktionstrennung), kritische Transaktionen oder auch unberechtigte Informationseinsicht hervorgerufen werden, ist die Bestimmung des Wertes der Informationen, die in den Geschäftsprozessen verarbeitet werden. So sollte eine Vertraulichkeits-, Integritätsbe-darfs- und Verfügbarkeitsklassifikation unter Mitwirkung der Fachbereiche festgelegt sein, die entsprechend den Risikolevel bestimmen. Zum Beispiel kann auch schon die Einsicht in Konstruk-tionsdaten in einem Maschinenbauunternehmen zu einem Risiko führen, wenn durch diese ein bedeutender Wettbewerbsvorteil am Markt erzielt wird. Dieses Arbeitspaket wird empfohlen, ist aber nicht unbedingt zwingend erforderlich, wenn das Unternehmen oder eine Organisation andere Policies zur Risikobewertung eingeführt hat.

60

Festlegung der Zugriffsrisiken (kritische Displayrechte, Transaktionen und Betrugsrisiken durch fehlende Funktionstrennung):

SAP GRC Access Control wird standardmäßig mit einem umfangreichen Satz an Prüfregeln aus- geliefert, die ein Best-Practice-Katalog von Risiken darstellt. Viele Unternehmen übernehmen diesen Risikoregelsatz direkt in ihren eigenen Risikokatalog. Trotzdem ist es sehr wichtig, dass diese Risiken auf Grund der Bewertung der wichtigen Informationswerte und eigenen Geschäfts-prozesse entsprechend mit den Fachbereichen auf deren Gültigkeit und auch des vorgegebenen Risikolevels hin überprüft werden. Wird diese Risikobewertung nicht durchgeführt, ist oftmals die Akzeptanz der Fachbereiche für die gewählten Risiken eher niedrig. Zudem sollten die Prüfregeln durch kritische Berechtigungen und auch Displayrechte (welche über bestimmte Berechtigungsob-jekte gesteuert werden können) sowie eigenerstellte Transaktionen ergänzt werden.

Die Festlegung der Risiken und Levels muss auf jeden Fall mit den Fachbereichen zusammen geschehen. Zudem ist es von Vorteil, wenn ein Risikomanager die entsprechenden Workshops leitet. Auch die Abteilung „Internal Audit“ sollte vor einer ersten Produktivsetzung die festgelegten Risikodefinitionen akzeptieren.

Die Definition von Zugriffsrisiken muss als fortlaufender Compliance-Prozess innerhalb des Unter-nehmens gesehen werden und fester Bestandteil des Gesamtrisikomanagements werden. Dies ist dadurch begründet, dass sich Unternehmensprozesse ständig ändern und auch neue Funktionen in SAP ERP, neue selbsterstelle Programme und andere Anwendungen ständig hinzukommen.

Festlegung von kompensierenden Kontrollen:

Für die im obigen Schritt festgelegten Risiken müssen entsprechende kompensierende Kontrollen festgelegt werden, falls sich das Zugriffsrisiko z.B. durch Funktionstrennung (Trennung der SAP- Rollen) oder auch durch entsprechenden Entzug der Berechtigungen nicht vermeiden lässt. Die kompensierenden Kontrollen definieren dann die notwendigen detektivischen Maßnahmen, die durchgeführt werden müssen, um z.B. betrügerische Handlungen schnell erkennen und entspre-chend eindämmen zu können. Diese Kontrollen können teilweise manuell sein, wie z.B. die Durch-führung einer Inventur des Lagerbestandes, oder aber auch mit Hilfe von SAP Reports, mit welchen schnell analysiert werden kann, ob z.B. verdächtige Kontodaten bei Kreditoren eingepflegt wurden. Die Durchführung von kompensierenden Kontrollen müssen einem Verantwortlichen zugeordnet werden, der dafür Sorge trägt, dass die Kontrolle im vorgesehenen zeitlichen Intervall durchgeführt und das Ergebnis der Kontrolle auch dokumentiert wird.

Die Ausarbeitung der kompensierenden Kontrollen sollte wiederum mit den Fachbereichen und unter Beteiligung des Risiko-Managers erfolgen. Auch muss in diesem Zusammenhang eine Richtlinie definiert werden, die genau in Abhängigkeit vom Risikolevel festlegt, ob ein Risiko im Provisionierungsworkflow akzeptiert werden darf oder unbedingt mit einer kompensierenden Kontrolle versehen werden muss.

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

61

Festlegung des Rollenkonzeptes für die Lösung SAP GRC Access Control selbst:

Auch für die produktive Anwendung der Lösung SAP GRC Access Control müssen über dessen ABAP-basiertes Berechtigungswesen entsprechende Rollen definiert werden – siehe hierzu auch die Anmerkungen oben zu ggf. gewünschten organisatorischen Separationen. Dies können z.B. technischer Administrator, Risikomanager (Festlegung der Risikomatrix inkl. Level und kompensie-renden Kontrollen), Approver (ist am Workflow z.B. beim Approval der Rollenzuordnung beteiligt) und Auditor (Auswertung von Logs und Überprüfung der Einhaltung der Prozesse) sein. Bei einer fein ausdifferenzierten Verteilung von Tätigkeiten bzw. Auftrennung von Organisationsbereichen muss ein Namenskonzept z.B. für Risiken, Funktionen, Rollen, Regelwerke, mindernde Kontrollen, Konnektoren usw. ein integraler Bestandteil des Berechtigungskonzeptes werden (z.B. Risikoad-ministratoren aus Untergesellschaft A dürfen nur Risiken, die mit A* beginnen, pflegen und diese nur an Regelwerke, beginnend mit A*, zuweisen). Die Rollen sollten entsprechend dokumentiert werden.

6.2.4 UNTERNEHMENSWEITES ROLLENKONZEPT

› Definition des Sollprozesses für die Änderung von Rollen: Der Prozessablauf von Änderungen existierender Rollen sowie Erstellung neuer Rollen muss festgelegt werden, insbesondere mit Hinblick auf die folgenden Fragestellungen:

I. Veränderungsmanagement: Wer kann Rollenänderungen beantragen / freigeben, wie geschieht dies (z.B. über das Change Request Management des SAP Solution Managers)?

b. Abstraktionsebenen: Welche Rollentypen kommen zum Einsatz? I. Einzelrollen II. Masterrollen / Rollenableitungen III. (SAP) Sammelrollen IV. Businessrollen (nur mit externem Tool möglich – z.B. ID Mgmt oder BRM)

c. Rollendefinition: Wie ist die Namenskonvention für die Erstellung neuer Rollen, wer definiert und klassifiziert die Rollen, welche Rollenattribute sind erforderlich / optional?

d. Berechtigungspflege: Wer führt die angeforderten Änderungen durch? Soll es möglich sein, mithilfe des Business Role Management auf hinterlegte Funktionen zuzugreifen, die gleich- artige Transaktionen zusammenfassen und auch im Rahmen der Risikoanalyse zum Einsatz kommen?

e. Zugriffsrisikoanalyse: Welche Regeln gelten für die Risikoanalyse? Muss jede Einzelrolle / Sammelrolle / Business Rolle konfliktfrei sein? Inwieweit kann die Risikoanalysesimulation effektiv genutzt werden (Was für einen Impact hätte diese Rollenänderung auf Zugriffsrisiken in der Produktivumgebung)?

f. Zugriffe auf Organisationen: Definition und Veränderungsmanagement für die Organisations- sets, welche die Funktionen innerhalb der Rollen auf bestimmte Teilbereiche des Unter- nehmens eingrenzen

62

g. Genehmigung: Muss die Rollenänderungen überprüft bzw. genehmigt werden? Durch wen?

h. Test: Welche Rollenänderungen müssen getestet werden? Wie sind die Dokumentations- vorgaben?

i. Regelmäßige Überprüfung: In welchen Abständen müssen die Rollen überprüft werden? Durch wen?

› Überprüfung verschiedener Funktionen des Business Role Management auf Mehrwerte im Rahmen administrativer Prozesse / im Rahmen von Rollouts; Überprüfung der Funktionen

a. Massenpflege von Rollen

b. Massensynchronisation von Rollen

c. Massenableitung von Rollen

d. „Role Mining“

e. Verschiedene Reportingfunktionen I. Beziehungen zwischen Stamm- und abgeleiteten Rollen (Vererbung) II. Beziehung von Einzel- zu Sammelrolle III. Rollen nach Generierungsdatum IV. Transaktionen in Rollen V. Transaktionen in Rollenmenü und produktive Berechtigung vergleichen VI. Berechtigungen in Rollen zählen VII. Änderungshistorie der Rollen (bis auf Feldebene) VIII. Rollenvergleich (von 2 bestimmten Rollen – auch für Backend-Systeme ohne Synchronisierung).

› Design des neuen Rollenkonzeptes für die Erfordernisse der Komponente „Unternehmensweites Rollenmanagement“ (BRM): In Abhängigkeit des in der Strategiephase festgelegten Konzeptes zum „Bereinigen“ der Risiken im Rollenkonzept können folgende Varianten in Betracht gezogen werden:

Variante A: Das bestehende Rollenkonzept wird in seiner Struktur so belassen und später in der Implementierungsphase entsprechend mit Hilfe von sukzessiv durchgeführten Risikoanalysen (auf Grund der vorher festgelegten Risikomatrix) in risikofreie Rollen aufgeteilt. Für die spätere, vollumfängliche Nutzung des BRMs müssen in der Designphase technische sowie organisatori- sche Voraussetzung geprüft / geschaffen werden:

› Eine eindeutige Namenskonvention muss definiert werden › Verantwortliche für den Inhalt der Rolle müssen definiert werden › Die erforderlichen organisatorischen Zugriffe („Org Sets“) müssen pro Referenzrolle definiert sein

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

63

Variante B: Falls eine große Anzahl von Risiken im bestehenden Konzept identifiziert wurden, bietet sich ein Reengineering des Rollenkonzeptes mit Hilfe eines Reverse-Business-Engineering- Konzeptes an. In diesem Fall wird durch entsprechendes „Tracing“ der Anwender festgestellt, welche SAP-Funktionen von diesen wirklich benötigt werden und welche eigentlich nicht. Die Erfahrung zeigt, dass durch dieses Verfahren ca. 50 – 70 % der bestehenden Risiken reduziert werden können. Bei dieser Variante sollten folgende Arbeitspakete angewandt werden:

1. Analyse des Organisations-Charts mit der Identifikation der Positionen und deren Zuordnung zu bestehenden SAP-Anwendern im System.

2. Analyse von eigenentwickelten Z-Transaktionen und deren Dokumentation (falls nicht schon vorhanden).

3. Zuordnung aller SAP-Transaktionen zu Informationseignern der Fachbereiche, die später entsprechend auch die Rolleneignerschaft übernehmen.

4. Durchführung der Reverse-Business-Engineering-Analyse im SAP-System zur Identifikation anhand der gruppierten Positionen tatsächlich verwendeter SAP-Transaktionen im System und deren Zuordnung zu entsprechenden Informationseignern. Ableitung des Rollenkonzeptes basierend auf Hauptarbeitsplatzrollen plus zusätzlicher Aufgabenrollen, die entsprechend innerhalb der Informationseignerbereiche gebildet werden können. Vorteil dieses Verfahrens ist, dass im ersten Ansatz den bestehenden Anwendern keine Funktionalität entzogen wird, welche sie tatsächlich in ihrer tagtäglichen Arbeit benötigen. Damit kann das Rollout-Risiko der Lösung minimiert werden.

5. Festlegung der notwendigen organisatorischen und funktionalen Ausprägungseinschränkungen (wie z.B. Company Code, Verkaufsorganisation etc.), welche später dann in der Rollenaus- prägung benötigt werden. Dies muss mit den jeweiligen Fachbereichen erfolgen oder ist als Dokumentation vom bestehenden Konzept noch vorhanden und kann entsprechend über- tragen werden.

Variante C: Eine große Anzahl von Risiken im bestehenden Konzept wurde identifiziert. Die existierenden Rollen sind i.d.R. über Jahre gewachsen, unstrukturiert und sehr mächtig geworden und – wie analysiert – mit vielen Funktionstrennungskonflikten behaftet; dann bietet sich eine Neustrukturierung (ReDesign) anhand von betrieblich exakt abgegrenzten Funktionsbausteinen an. Die daraus ableitbaren Einzelrollen lassen sich später einfach zu Sammelrollen aggregieren und mittels des ORG-Managements (HR) den Arbeitsplätzen zuordnen; darauf kann dann das IdM und ARM sinnvoll aufsetzen.

Nach der Konzeption und Definition der im Unternehmen erforderlichen betrieblichen Funktions- bausteine kommt man im nächsten Schritt zur Technikebene und zur Umsetzung in Einzelrollen. Hierzu bieten sich sowohl der BRM (Business Role Management) wie auch der PFCG (Profil- generator) an oder aber ein toolunterstütztes Vorgehen auf Basis bereits vorgefertigter Funkti- onsbausteine. BRM hat den Vorteil, die Rollen nach der Erstellung sofort auf Funktionstrennungs- anforderungen (SOD) verproben zu können und über einen Freigabeprozess auch genehmigen zu

64

lassen. Arbeitet man mit geeigneten – am Markt erhältlichen – bereits konfliktfreien Best- Practice-Bausteinen, können die Einzelrollen aus diesen Funktionsbausteinen mit Hilfe von Werkzeugen direkt abgeleitet und die Organisationsdaten zugesteuert werden.

Eine Namenskonvention der Einzel- und Sammelrollen sowohl im Kurz- wie auch im Lang- namen ist verpflichtend. Der Kurznamen enthält Modulbereiche (wie SD, PP …), die betriebliche Funktion und eine eindeutige Nummerierung. Wichtiger ist der Langname; dieser sollte immer und durchgehend 3-teilig aufgebaut sein:

1. Modulkennzeichen und betriebliche Funktion 2. Funktionstyp mit Bearbeiten, Anzeigen… 3. Organisationsebene wie Buchungskreis, Sparte..., Kostenstelle

Eine betriebliche Funktion (Einzelrolle) ist nur dann hinreichend und vollständig beschrieben, wenn sie alle benötigten Transaktionen und auch ihre zugehörigen abgrenzungsrelevanten Organisationsdaten (Berechtigungsobjekte / Felder / Werte) beinhaltet. Teilfunktionale Rollen, Rollen ohne Transaktionen oder Org-Werte, Rollen mit Transaktionsbandbreiten, Rollen mit „Aktivitätscode*“ sollten nicht zugelassen werden. Hat man eine starke Verästelung mit vielen Sparten, Kostenstellen etc. im Unternehmen, die eigens abgegrenzt werden müssen, entstehen sehr wohl einige Kopien dieser Bausteine, die jedoch funktional identisch bleiben und sich nur in der Organisationsausprägung unterscheiden. Ob später mit oder ohne Vererbung gearbeitet werden soll, ist beim Design zu berücksichtigen. Bei eigenentwickelten Transaktionen ist eine Prüfung unerlässlich, ob diese nach dem SAP- Authorization-Check-Verfahren programmiert sind, ggf. eigene Berechtigungsobjekte besitzen oder Standardtransaktionen aufrufen und welche davon überhaupt noch verwendet werden. Kommt man zu dem Ergebnis, dass hier kritische oder unbekannte bzw. nicht dokumentierte Eigenentwicklungen vorliegen und auch noch eingesetzt werden, empfiehlt es sich, diese in eigene Einzelrollen – nach Modulgruppen getrennt – abzulegen und speziell zu benennen. Eine Vermischung zwischen Standard- und den eigenen Y-/Z-Transaktionen sollte vermieden werden, da diese später schwierig zu handhaben sind („die findet man fast nie mehr!“).

Zum Schluss ergänze man die so erstellten Rollen um die sog. Notfallrollen, d.h. Rollen zum Customizing sowie zur Entwicklung im Produktivsystem, die Rollen für die Berater, WPs und Steuerprüfer/Finanzamt, den Datenschutzbeauftragen etc. Notfallrollen sollen modulweise abgegrenzt und eingeschränkt werden und die Verwendung nur über den SPM erfolgen.

Die Hauptarbeit eines Rollendesigns ist der Aufbau der Einzelrollen; nach Beendigung sind alle betrieblichen Funktionen – unabhängig, wie und wo sie eingesetzt und verwendet werden – vollumfänglich umgesetzt. Am besten beginnt man mit der größten Funktionsbreite einer Einheit (Hauptgeschäftsprozesse), um ggf. später im Rollout-Verfahren davon neue Einheiten abzu- leiten und anzupassen. Hier bieten sich dann zur Arbeitserleichterung Massenkopierverfahren an.

Arbeitsplätze sind in Arbeitsplatzfunktionen aufgeteilt; eine Arbeitsplatzfunktion ist die Aggre- gierung (Zusammenfassung) betrieblicher Funktionen (Einzelrollen) z.B. in der Abteilung Vertrieb der Vertriebsaußendienst für Deutschland. Wenn man alle Einzelrollen in einer Spalte (z.B. Excel) aufführt und horizontal zusammen mit den Fachbereichsverantwortlichen die Arbeits-

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

65

platzfunktionen definiert, können die Arbeitsplätze einfach durch Ankreuzen zusammengestellt werden. Das Excel dient später auch zur Transparenz und beschreibt im Detail die Inhalte dieser Arbeitsplätze mit ihren einzelnen Funktionen. Organisationsänderungen sind leicht und ohne großen Aufwand umzusetzen, wenn sich Funktionen innerhalb der Organisation verschieben; dies bedeutet ein Umhängen der Einzelrollen - die Funktion selbst bleibt i.d.R. innerhalb des Unternehmens unverändert. Bei dieser Vorgehensweise sind Benutzern immer nur Sammel- rollen oder Business-Rollen zugewiesen und möglichst keine Einzelrollen. Fachbereiche kennen somit nur eine in sich überschaubare Anzahl ihrer Sammelrollen und dadurch ist eine durch- gängige Transparenz und effiziente Handhabung geschaffen.

Abbildung 8: Aggregierung von Einzelrollen zu Sammelrollen (Arbeitsplätze)

Dieser Redesign-Prozess ist aufwendig und bindet nicht nur die Ressourcen der IT, sondern auch die der Key-User aus den Fachabteilungen. Deshalb ist es wichtig, nach Freigabe und Produk- tivsetzung der neu gewonnenen Rollen jede Veränderung durch einen Genehmigungsprozess zu initiieren und diese mit Zeitstempel zu dokumentieren – nicht nur aus Revisionssicht, sondern auch aus Investitionsschutz!

ArbeitsplatzAP1 AP2 AP3 AP4 AP5 AP...

x x

x x x

x

x x x

ER1

ER2

ER3

ER4

ER5

ER...

Einz

elro

lle

Lokation 1 Lokation 2

› Bankbuchhaltung › Bestandsführung › Wareneingang

› Debitorenbuchhaltung › Debitorenbuchhaltung › Bankbuchhaltung

› Rechnungsprüfung › Anfragen / Angebote › Bestandsführung

› Anfragen / Angebote

66

6.2.4.1 Gesetzeskonformes Benutzermanagement (User Lifecycle Management)

In diesem Arbeitspaket müssen die wichtigsten Änderungsmanagementprozesse zusammen mit den Fachbereichen und dem Compliance Management festgelegt werden:

› Beantragung von Rollen und Berechtigungen durch die Fachbereichsanwender. Der Benutzer- management-Workflow sollte hinsichtlich folgender Instanzen entworfen werden:

› Antragsteller › Genehmigung durch Rollenverantwortliche und Fachbereichsverantwortliche › IT-Administrationsstufen › Risikomanagement, falls durch neue Rechte neue Risiken entstehen › Einbindung von HR

› Passwort-Änderungs- oder-Rücksetzungsantrag› Festlegung einer neuen Risikodefinition (in ARA) oder Änderung bzw. Löschung einer bestehen- den Risikodefinition› Zuordnung einer kompensierenden Kontrolle zu „risikobehafteten“ Anwendern, falls dies nicht schon im Rollenbeantragungsprozess durchgeführt wurde› Änderung oder Neuanlage bzw. Löschung von kompensierenden Kontrollen im bestehenden Katalog› Workflow für Superuser-Zugriff› Abstimmung erforderlicher Integrationsszenarien (z.B. HCM, HCM-Org-Management, IDM, CUA) unter Berücksichtigung des führenden Systems.

Durch die Einführung von SAP GRC Access Control muss es im Benutzermanagementprozess einen Schritt zur Analyse der Zugriffsrisiken und deren Kompensierung geben. Insbesondere muss entschieden werden, wer sich um die Zugriffsrisiken und deren Kompensierung kümmert.

6.2.5 NOTFALLZUGRIFF (EMERGENCY ACCESS MANAGEMENT)

Auch hier starten die Aktivitäten zunächst mit der Definition des Sollprozesses zusammen mit den Fachbereichen. Dabei muss zunächst eine grundlegende Designfrage geklärt werden: Soll das Emergency Access Management (EAM) rollenbasiert agieren oder User-ID-basiert?

Zur Erläuterung: Im rollenbasierten Modus weist das EAM den Benutzern Zusatzrechte über weitere Rollen für den genehmigten Zeitraum zu. Technisch werden dabei weitere Rollen in den Benut-zerstamm gelegt, nach Datum abgegrenzt. Der Benutzer kann dann, wenn der Gültigkeitszeitraum erreicht ist, unter seiner eigenen User-ID die notwendigen Arbeiten verrichten.

Im User-basierten Modus hingegen werden vorab spezielle User-IDs mit erweiterten Rechten an-gelegt (normale Useranlage über die SU01), die sog. „FireFighter-IDs“. Im genehmigten Zeitraum können Anwender über das EAM-Cockpit dann nach Angabe eines Grundes und der Beschreibung der durchzuführenden Tätigkeiten auf die genehmigte FireFighter-ID wechseln. D.h., die dann folgenden Tätigkeiten werden unter dieser speziellen, oftmals weitreichend berechtigten User-ID durchgeführt. Nach Beendigung der Arbeiten verlässt der Anwender den Modus der FireFighter-ID und die Notfallsession wird geschlossen.

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

67

Eine Aufstellung der wesentlichen Unterschiede sieht wie folgt aus:

Rollenbasiert

› Die User-ID des durchführenden Benutzers ist direkt in den Belegen (FI-Korrekturen, Programm- reparaturen etc.) gegeben und muss nicht über die EAM-Logs nachgeschlagen werden› Die zusätzlichen Privilegien gelten nicht sessionbasiert, sondern durchgehend für den genehmigten Zeitraum und lassen sich tagesgenau abgrenzen› Ein gesonderter Notfallvorgang ist für den Anwender nicht notwendig

ID-basiert

› Für jeden Einsatz gibt es eine konkrete Session mit Angabe des Ursachencodes. Hier muss der Anwender auch im Dialog zunächst eingeben, was er tun will. Es entsteht eine dokumentierte Notfallsitzung mit entsprechender zeitlicher Abgrenzung und der Möglichkeit, bei Sessionende bzw. fallbezogen Mails an den Überwacher/Verantwortlichen zu verschicken › Die Aktivitäten werden mit der FireFighter-User-ID durchgeführt, nicht mit der des Anwenders› Überwacher können jeweils gezielt über die Session-Details schauen, auch selektiert nach Ursachencode› Die eigene User-ID des Benutzers bekommt keine weiteren Berechtigungen zugewiesen, bringt ihn damit aber später auch nicht in Erklärungsnot › Es gibt in den Aufzeichnungen des Systems keine Vermengung von normalen, typischen Aktivitäten des Benutzers und Notfallaktivitäten, wenn der Benutzer diese am selben Tag ausführt. Damit werden auch Datenschutzbedenken bei der Überprüfung der Logs besser abgedeckt› Risikoanalyen auf die User-IDs der Benutzer während der Gültigkeit der Notfallverfahrenszu- ordnung sehen nach wie vor unkritisch aus, sofern sie es vorher auch waren

Erfahrungen mit vielen Unternehmen zeigen, dass derzeit der Einsatz der ID-basierten Variante wesentlich häufiger ist als der Einsatz des rollenbasierten Verfahrens. Hintergrund ist, dass insbe- sondere bei der Interaktion mit Prüfern (Interne Revision, Wirtschaftsprüfer) dieser Ansatz ganz erheblich die Diskussionen unter den Beteiligten reduziert, weil die Sondernutzung jeweils wesentlich klarer abgegrenzt ist. Daher kann die User-ID-basierte Verfahrensweise als Best Practice gelten, wenn ein ordentliches Notfallverfahren aufgebaut werden soll. Soll das EAM hingegen vordringlich dazu verwendet werden, zum Berechtigungswesen eine flexible Zusatzrollenmechanik abzubilden, d.h. Anwendern bei ansonsten eher statischen, positionsbasierten Zuordnungen von Rollen eine flexible, dynamische Möglichkeit zu bieten, temporär und kontrolliert weitere Berechtigungen zu erhalten, dann kann hier die rollenbasierte Variante stark unterstützen. In diesem Umfeld wird sie auch gerne von Unternehmen eingesetzt.

Zu Klärung der Frage rollen- vs. User-ID-basierter Nutzung des EAM ist es also zunächst notwendig zu entscheiden, ob ein Notfalluserverfahren oder ein Zusatzberechtigungsverfahren gewünscht wird. Allerdings wird in Unternehmen wiederum oftmals von verschiedenen Stellen Unterschiedliches in dieser Hinsicht gefordert: Abteilungen aus dem SAP-Basis-Umfeld und Bereiche, die viel mit Prüf-situationen beschäftigt werden, benötigen ein stabiles und klar abgrenzbares Notfalluserverfahren. Fachbereiche mit besonderen Berechtigungsanforderungen hingegen wünschen sich oft ein flexibles Erweiterungs- oder Zusatzberechtigungsmanagement. Wichtig vor diesem Hintergrund ist: Es ist

68

leider derzeit nicht möglich, beide Verfahren parallel zu betreiben, da dies ein globaler Customizing- Schalter im GRC Access Control steuert. Daher muss hier als Erstes eine klare Entscheidung vor den oben beschriebenen Einschränkungen der jeweiligen Variante getroffen werden (wir geben hierbei auch zu bedenken, dass SAP diesem Werkzeug den Namen „Emergency Access Management“ und nicht „Flexible Auxiliary Role Assignment Management“ gegeben hat).

Nachdem die Entscheidung bezüglich des verwendeten technischen Verfahrens vorliegt, muss dann in Zusammenarbeit mit den Fachbereichen eine Richtlinie für den Zugriff auf höher berechtigte Notfallbenutzer oder Zusatzberechtigungen (siehe Diskussion Rollen vs. User-ID-basiert) entworfen werden. Der Zugriff sollte in der Tat nur für den jeweiligen begrenzten Einsatzweck erlaubt werden und nicht für den Regelfall, da ansonsten das eigentlich definierte Berechtigungskonzept nach und nach unterwandert wird.

Festzulegen ist dabei auch, ob bei der Verwendung der ID-basierten Variante die FireFighter-IDs einzelnen Benutzern permanent zugeordnet werden oder ob für die jeweilige Nutzung einer ent-sprechenden ID das Benutzerantragsverfahren genutzt werden soll.

Abschließende erfolgt das detaillierte Design des Emergency Access mit SAP GRC Access Control: Die Richtlinie wird als Prozess-Blueprints entworfen und entsprechend die Eigner für die Superuser- IDs / Zusatzrollen festgelegt. Zudem müssen die entsprechenden höherwertigen Berechtigungen pro Superuser-ID oder Zusatzrolle bestimmt werden. Dies muss wiederum zusammen mit den Fach-bereichen erfolgen. Auch die Reviewer bzw. Kontrolleure, die im Nachgang einer Verwendung die Änderungsprotokolle auszuwerten haben, müssen pro Fachbereich festgelegt werden. Zudem sind klare Vorgaben zur Auswertung festzulegen. Bei einer Identifikation von Unregelmäßigkeiten in den Änderungsprotokollen müssen zudem die notwendigen reaktiven Schritte festgelegt werden.

In größeren, verteilt arbeitenden Organisationen muss geprüft und konzeptionell erarbeitet werden, wer im zentralen GRC-Access-Control-System die Administrationsarbeiten auf die jeweilligen Genehmiger durchführen darf.

6.2.6 TESTVORBEREITUNG FÜR ALLE KOMPONENTEN

Die Durchführung von Tests ist ein wichtiger Bestandteil einer jeden Software-Einführung, um die Implementierung der Anforderungen im Blueprint zu überprüfen und eine hohe Qualität der Soft-ware sicherzustellen. Fehler, die erst im späteren Betrieb der Software festgestellt werden, können zur Beeinträchtigung der Akzeptanz der Systeme führen. An dieser Stelle muss einschränkend fest- gehalten werde, dass auch ein erfolgreich abgeschlossener Abnahmetest keine Garantie für die grundsätzliche Fehlerfreiheit der Software abliefern kann. Der Grund liegt in der Tatsache, dass ein vollständiger Test in der Regel wenig wirtschaftlich oder auch nicht realisierbar ist. In der Design- phase sollte mit der Vorbereitung der Tests begonnen werden. Unter Testing wird der Benutzerak-zeptanztest oder auch Abnahmetest verstanden. Unit-Tests finden bereits bei der Implementierung/ Konfiguration der Funktion durch den Entwickler statt. Ein erster wichtiger Bestandteil der Testvor- bereitung ist die Festlegung der Testorganisation, d.h. die Festlegung der Personen, die die Tests durchführen, sowie der Person, die die Tests als Testleiter verantwortet. Bei der Testdurchführung bieten sich die zukünftigen Key-User aus den Fachbereichen an, die auch bei der Aufnahme der Anforderungen innerhalb des Blueprints mitgearbeitet haben. Dies hat zwei Vorteile: die Key-User

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

69

kennen bereits die Anforderungen an das System. Des Weiteren kann der Test auch als Schulungs-maßnahme für die Key-User betrachtet werden. Weitere wichtige Rollen in der Testorganisation sind die Testleitung / -verantwortliche sowie ein Fehlermanager, der später die Lösung von festgestellten Fehlern vorantreibt. Je nach Einbindung der Mitbestimmungsseite und der internen Revisionsorga-nisation kann es Sinn machen, Vertreter in die Testabläufe einzubinden. Als Beispiel wäre hier die Kontrolle von Logdateien des Notfallmanagements zu betrachten (Revision) oder die Kontrolle von Risikoanalyse-Ergebnissen auf Freiheit von Mechanismen der Verhaltenskontrolle (Nutzung von Transaktionen). Nachdem die Testorganisation festgelegt wurde, sollten basierend auf den An-forderungen im Blueprint die Testfälle festgelegt werden, welche später in Testskripten detailliert ausgearbeitet werden. Die Testfälle sollten nach den Komponenten SAP GRC Access Control gruppiert werden. Die Testfälle der einzelnen Komponenten sollten die folgenden Aspekte berücksichtigen, welche anhand von Beispielen für die SAP GRC AC erklärt werden:

› Überprüfung von Eingabemasken: › Inhalt: Die benötigten Eingabemasken sollten hinsichtlich des Designs überprüft werden. Sind die Felder vorhanden, die benötigt werden, die ausgeblendet, die nicht benötigt werden und / oder ggf. zusätzlich benötigte Felder konfiguriert worden.

› Beispiel: Beinhaltet die Eingabemaske für einen Benutzerantrag die geforderten Eingabefelder? › Sind zusätzlich gecustomizte Felder vorhanden?

› Überprüfung von Workflows: › Inhalt: Workflows, die speziell im Benutzerantragswesen spezifiziert wurden, sollten hinsichtlich des Routings der Anträge überprüft werden.

› Beispiel: Erhalten die Benutzer den Workflow in der jeweiligen Genehmigungsstufe, welche für die Genehmigung spezifiziert wurden? Funktionieren Workflow-Gabelungen, d.h., der Antrag soll aufgrund einer Entscheidung den einen oder den anderen Weg nehmen.

› Überprüfung von Funktionen: › Inhalt: Überprüfung der Funktion der einzelnen Funktionen (= Menüeinträge) innerhalb des SAP-GRC-Menüs.

› Beispiel: Wird bei der Selektion des Menüs „Zugriffsrisiken“ die Verwaltung der Zugriffsrisiken geöffnet und ist es mit den Funktionen innerhalb dieses Menus möglich, ein Zugriffsrisiko anzulegen, zu ändern und zu löschen.

› Überprüfung der Berechtigungen und Menüs: › Inhalt: Da Benutzer des Systems unterschiedliche Rollen einnehmen, sollte jede Rolle hin- sichtlich der definierten Berechtigungen überprüft werden. Es muss zum einen überprüft werden, ob die Rolle die Berechtigungen bietet, die definiert wurden, aber auch alle anderen Berechtigungen unterbindet / ausschließt.

› Beispiel: Ein Genehmiger innerhalb des Benutzermanagementworkflows sollte Workflow- aufgaben für seine Genehmigungsstufe empfangen und bearbeiten können, sollte aber nicht in der Lage sein, das Regelwerk und Zugriffsrisiken zu bearbeiten.

70

› Überprüfung der Reports und Dashboards: › Inhalt: Die benötigten Reports sollten überprüft werden, ob die benötigten Selektionskriterien zur Verfügung stehen, sowie die erwarteten Daten mit den entsprechenden Attributen (= Datenfeldern) dargestellt werden.

› Beispiel: Wird im Report für Benutzeranträge eine Suchfunktion via „Antragsnummer“ zur Verfügung gestellt und im Ergebnisbereich der Anträge der „Antragsteller“ angezeigt.

› Batch-Prozesse: › Inhalt: Überprüfung von benötigten Batchjobs, die im System ad hoc oder regelmäßig benötigt werden.

› Beispiel: Zur Erstellung der Management-Dashboards wie „Risikoüberschreitung“ müssen im System verschiedene Batchjobs in der richtigen Reihenfolge eingeplant und abgespielt werden.

› Schnittstellen: › Inhalt: Überprüfung der Funktionsweise von Schnittstellen zu angebundenem System.

› Beispiel: Erhalten Benutzer eine E-Mail-Benachrichtigung durch das Workflowsystem oder wird ein Benutzer am Ende des Benutzermanagementworkflows im angebundenen SAP-ECC- System mit den richtigen Daten angelegt.

Nach der Festlegung der Testfälle, sollten diese mit Hilfe von detaillierten Testskripten abgeleitet werden, mit deren Hilfe dann in der Implementierungsphase die Tests durchgeführt werden können.

Abbildung 9: Beispiel Testskript

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

71

Die Testfälle und -skripte können sowohl in MS Microsoft Excel dokumentiert werden oder in einer Softwarelösung zur Verwaltung von Softwaretests. In vielen Unternehmen kommt hier der SAP Solution Manager zum Einsatz.

Zu berücksichtigen ist insbesondere, dass die Testszenarien sowohl das zentrale GRC-Access- Control-System betreffen, aber auch das angeschlossene Backend-System. Für den Fall, dass die FireFighter-funktionaliät aus der Version 5.3 (dezentraler FireFighter) genutzt wird, muss die korrekte Funktionsweise ausschließlich im Backend-System getestet werden. Die fehlerfreie Synchronisation der Benutzer-, Rollen- und Profildaten sowohl im inkrementellen Modus als auch in der vollen Synchronisation muss getestet werden.

6.2.6.1 Festlegung der Testskripte

Das Testskript beschreibt die tatsächlich zu testende Funktionalität und bestimmt die Eingabepa-rameter und die zu erwartenden Ausgabeparameter.

Diese Testskripte lehnen sich an die im Business Blueprint definierten Prozesse an und bedienen sich der Stammdaten in den Backend-Systemen und der zentralen Plattform. Vor allem die im User Acceptance Test (UAT) genutzten Skripte benötigen eine detaillierte Ablaufbeschreibung und fehler-freie Bereitstellung von notwendigen Stammdaten. Nicht durchführbare Testfälle im UAT aufgrund von fehlenden oder fehlerhaften Stammdaten führen zu schweren Akzeptanzverlusten bei den Testbenutzern und sollten unbedingt vermieden werden.

Komplexe Workflowszenarien bei der Benutzeranlage und Rollenzuweisung einschließlich der Miti-gierungsprozesse erfordern eine Vielzahl von Testskripen. Jeder Zweig im Prozessablaufdiagramm muss hier mit einem Testfall versehen und durchlaufen werden.

72

6.3 PHASE REALISIERUNG („IMPLEMENTIERUNG“)

In der Realisierungsphase werden nun die detaillierten Konzepte und Designs entsprechend in die Entwicklungsumgebung implementiert und getestet. Dies kann wieder teilweise für die einzelnen Komponenten parallel durchgeführt werden. Aber speziell ein mögliches notwendiges Neuerstellen der Rollen muss mit der Risikoanalyse integriert bzw. teilweise auch iterativ durchgeführt werden.

Im Einzelnen sollten die folgenden Arbeitspakete angegangen werden.

6.3.1 ARCHITEKTUR & TECHNOLOGIE

1. Technische Installation aller SAP-GRC-Access-Control-Komponenten Entsprechend des technischen Designs werden nun alle Komponenten für die vorgesehene Systemlandschaft installiert. Dabei kann zum Teil die in der Strategiephase bereits installierte Sandbox zur Entwicklungslandschaft weiter entwickelt werden. Je nach Design wird die Entwick- lungslandschaft mit einer Qualitätssicherungslandschaft und finalen Produktion erweitert. Zudem müssen die notwendigen Plug-ins, je nach gewählter GRC-Access-Control-Version und Zielsystem- version auf den Backend-Systemen installiert werden.

Wird vor dem Hintergrund einer bestehenden Implementierung von GRC Access Control 5.3- installiert, so sollte das Migrationskapitel beachtet werden. Zwar ist der AC5.3-Code in den neuen Plug-ins enthalten, es ergeben sich jedoch ggf. kleinere Unterschiede über ein mögli- cherweise mittelbar enthaltenes Anheben der AC5.3-SPs auf den Satellitensystemen.

Wenn geplant ist, GRC Access Control 10.0 auf einem Solution Manager System zu betreiben, sollten die Hinweise 1583125 („Installation SAP GRC Access Control auf SAP Solution Manager“) und 1658621 („Menu item tree for user is empty“) beachtet werden – bei letzterem wird die technische Grundlage für den NWBC-Betrieb von GRC Access Control im Solution Manager gelegt.

2. Finale technische Konfiguration Nach erfolgter technischer Installation werden die notwendigen Verbindungen zu den Zielsystemen konfiguriert und zudem die notwendigen Batchjobs für die Berechtigungsdatensynchronisation (USOBX_C und USOBT_C) etc. definiert. Zudem muss ggf. für die Risikoanalyse die Verwendung der Workflow-Engine bei der Verwaltung von Zugriffsrisiken angeschaltet werden. Auch die Transportmechanismen von Entwicklung zu Produktion für die Risikoregeln werden entsprechend konfiguriert und spezifiziert.

6.3.2 RISIKOANALYSE UND BEREINIGUNG

1. Umsetzung der definierten Risiken und Zuordnung der kompensierenden Kontrollen im System: Die in der Blueprint & Design-Phase definierten Risiken und die dazu korrespondierenden kompensierenden Kontrollen werden entsprechend im Entwicklungssystem angelegt und in die Produktionsumgebung transportiert.

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

73

Alternativ können Risiken und Kontrollen auch direkt in Produktion gepflegt werden, wenn dies in der Blueprint-Phase beschlossen wurde – hierbei sollten dann aber Genehmigungsworkflows für die Wahrung des 4-Augen-Prinzips eingesetzt werden. Abschließend müssen die regulär laufenden Synchronisationsjobs eingeplant werden.

2. Einführung des Rollenkonzepts für SAP GRC Access Control: Die definierten Rollen für SAP werden entsprechend in der Berechtigungsverwaltung des darunter laufenden SAP-NetWeaver- ABAP-Systems umgesetzt (siehe auch den Security-Guide zu SAP GRC Access Control 10.0.).

Test der Risikoanalyse mit Beispielrollen: Mit speziellen Testrollen, die z.B. schon „wissentlich“ Risiken enthalten, werden Testrollen vorbereitet, mit deren Hilfe die implementierten Risiken getestet werden.

6.3.3 UNTERNEHMENSWEITES ROLLENKONZEPT

1. Implementierung des Sollprozesses im Business Role Management: Die relevanten Prozess- schritte müssen nun im Business Role Management umgesetzt werden.

a. Integration mit Change Management System: Eine (teil-)automatisierte Integration mit einem Change Management System ist im Standard nicht vorgesehen. Es besteht aber die Möglichkeit, im BRM bei jeder Rollenänderung die Eingabe eines Tickets obligatorisch einzufordern. Alternativ wäre eine kundenspezifische Entwicklung einer entsprechenden Schnittstelle denkbar.

b. Scope: Für verschiedene Systemlandschaften / Rollentypen müssen im BRM ggf. verschiedene Verfahren hinterlegt werden. Dies geschieht mithilfe von sog. BRF+-Regeln.

c. Rollendefinition: Hierfür muss neben den jeweiligen Rollenklassifizierungen (z.B. die verschiedenen Kritikalitätsstufen einer Rolle), die im Customizing zu hinterlegen sind, auch die automatisch generierte Namenskonvention hinterlegt werden. Hier ist es wichtig zu wissen, dass die jeweils festgelegten Zeichen z.B. für das Modul oder die Ableitung an eine fest definierte Position gesetzt werden (z.B. Ableitung: Zeichen 27-30),Variablen können hier im Standard nicht hinterlegt werden. Dies muss bei der Wahl der entsprechenden Namenskonvention berücksichtigt werden.

d. Berechtigungspflege: Hier wird ein Absprung in die PFCG durchgeführt. Eine Pflege innerhalb des BRM ist nur mithilfe der Funktionen vorgesehen und sollte bei Nicht-Nutzung abgeschaltet werden. e. Risikoanalyse: Das generelle Verbieten von Risiken bzw. das Erzwingen von Risikoanalysen sollte wohlüberlegt sein. Die vielfache Risikoanalyse umfangreicher Entwickler / Customizing / Testrollen kann zu Performanceproblemen führen und ist von überschaubarem Mehrwert

f. Rollenableitung: Hier ist es die Hauptaufgabe, die Organisationssets zu ermitteln und im Rollen- management zu hinterlegen.

g. Genehmigung: Mithilfe von BRF+-Regeln kann der Genehmiger einer Rollenänderung z.B. Abhängig vom Geschäftsprozess ermittelt werden. Die manuelle Pflege eines Genehmigers, welche danach von demselben genehmigt wird, macht natürlich wenig Sinn.

74

Variante A:

2. Synchronisation der Backend-Rollen und sukzessive „Bereinigung“: Die bestehenden Backend- Rollen werden entsprechend in SAP GRC Access Control hochgeladen und auf bestehende Risiken analysiert. Beim Hochladen werden entsprechend die Rolleneignerattribute und weitere Attribute wie organisatorische Zuordnungsinformationen (Division, Abteilung, Vertreter etc.) zugeordnet. Bei der Analyse werden die Rollen in weitere Teilrollen (falls Funktionstrennungs- konflikte bestehen) getrennt.

3. Notwendige Nachpflege der organisatorischen und sonstigen Berechtigungsreichweiten: Organisatorische Berechtigungen (Buchungskreis, Kostenstellen etc.) plus weitere Berechtigungen müssen mit Hilfe der Komponente „Unternehmensweites Rollenkonzept“ nachgepflegt werden.

Variante B und C:

2. Implementierung des neuen Rollenkonzepts: Die in der Designphase neu erstellten Rollen werden entsprechend mit der Komponente „Unternehmensweites Rollenkonzept“ implementiert und Rolleneigner und die weiteren organisatorischen Attribute (wie in Variante A) zugeordnet. Mit Hilfe der Risikoanalyse werden, falls notwendig, bestehende Konflikte im Rollendesign weiter bereinigt. Entsprechend wird auch nochmals das Rollendesign angepasst.

3. Notwendige Pflege der organisatorischen und sonstigen Berechtigungsreichweiten: Organisa- torische Berechtigungen (Buchungskreis, Kostenstellen etc.) plus weitere Berechtigungen müssen dann mit Hilfe der Komponente „Unternehmensweites Rollenkonzept“ oder im „Rollout- Verfahren“ nachgepflegt werden.

6.3.4 NOTFALLZUGRIFF (EMERGENCY ACCESS MANAGEMENT)

Implementierung des Notfallzugriffs: Die definierte Richtlinie – Rollen- oder ID-basierter Ansatz, Pflege als globaler Schalter im Customizing – und die entsprechenden Genehmiger, Kontrolleure und Superuser-IDs (falls notwendig) werden mit Hilfe der Komponente Emergency Access umge-setzt. Die entsprechenden Benutzer werden benannt und im System angelegt. Abhängig davon, ob die Anlage von Zuweisungen von FireFightern zu Notfall-IDs (oder Rollen) direkt erfolgt oder per Workflow, werden die entsprechenden Mechanismen eingerichtet und die Endanwenderrollen für die Belegung des UIs entsprechend ausgearbeitet – siehe Security Guide zu SAP GRC Access Control. Bei zu verwendenden Workflows müssen diese über das MSMP eingerichtet werden.

Darüber hinaus wird im Customizing hinterlegt, ob die FireFighter über das Zentralsystem arbeiten oder über die jeweiligen Satelliten einsteigen. Falls ein zentraler Einstieg gewünscht wurde, müssen alle potenziellen FireFighter im Zentralsystem angelegt werden. Abschließend müssen die Ursachen- codes gepflegt und die Hintergrundjobs für die Einsammlung der FireFighteraktivitäten eingeplant werden.

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

75

Allgemein ist für die Anbindung der Satellitensysteme zu beachten, dass das EAM hier Verbindun-gen mit TrustedRFC erwartet. Die entsprechenden Vertrauensstellungen (Transaktion SMT1) und Berechtigungen (Berechtigungsobjekt S_RFCACL – nicht Bestandteil von SAP_ALL, daher müssen Notfalluser-IDs mit SAP_ALL noch eine zusätzliche Rolle bekommen) müssen daher vorab korrekt hinterlegt werden.

6.3.5 TESTDURCHFÜHRUNG

In der Testdurchführung werden die Testfälle und Testskripts durch die festgelegten Personen in der Testorganisation durchgeführt. Die Testergebnisse werden in den entsprechenden Testformularen dokumentiert. Neben der Koordination der Testdurchführung ist die wichtigste Aufgabe in diese Phase das Fehlermanagement, d.h., die festgestellten Fehler zu klassifizieren und für eine zeitnahe Lösung der Fehler zu sorgen. Diese Aufgabe kann entweder durch die Testleitung oder durch einen Fehlermanager durchgeführt werden.

Bei der Klassifizierung der Fehler bietet sich eine 3-stufige Skala an, wie beispielhaft in der folgenden Abbildung dargestellt:

Abbildung 10: Fehlerklassifizierung

Schwerer Fehler Der Produktivstart ist gefährdet. Die Fortsetzung des Tests ist nicht möglich. Die Behebung des Fehlers erfolgt sofort. Beispiel: Die Eingabe von Daten ist nicht möglich. Berichte werden nicht ausgegeben. Eine Schnittstelle geht nicht.

Mittelschwerer Fehler Die Fortsetzung des Test ist mit Hilfe eines Workaround (Zwischenlösung) möglich. Die Behebung des Fehlers erfolgt spätestens innerhalb von einer Woche nach Produktivstart. Beispiel: ein Pausenzustand ist nicht erreichbar; Zwischenlösunge: Wahl eines anderen Pausenzustands

Leichter Fehler Die Durchführung des Tests ist nicht behindert. Die Behebung des Fehlers muss zwei Wochen nach Produktivstart erfolgt sein. Beispiel: Rechtschreibfehler im Dialog

A

B

C

76

Die Fehler sollten in einer zentralen Liste durch die Testleitung / Fehlermanager verwaltet werden. Die Hauptaufgabe ist es nun, die Fehlerbehebung und den Wiederholungstest zu koordinieren.

Am Ende der Phase der Testdurchführung sollten alle Fehler entsprechend ihrer Fehlerklasse vor oder nach Produktivstart behoben sein.

Fazit:

Keine Software und kein auf Software basierendes System funktioniert von vornherein genau so, wie es auf Basis seiner Spezifikation entwickelt wurde. Im Laufe der Konfiguration geschehen immer Fehler, und je komplexer ein System ist, desto größer und gravierender sind die zu erwartenden Fehler. Erfolgreiche Abnahmetests sind daher eine wesentliche Grundlage für den stabilen und weitestgehend störungsfreien Produktivbetrieb einer Softwarelösung.

6.3.6 FACHBEREICHS-TRAINING

Das Training der verschiedenen Fachbereiche sollte auf unterschiedlichen Trainingsmethoden auf-gebaut werden, die je nach Zielgruppe zum Einsatz kommen. Administratoren werden in Präsenz-schulungen intensiv mit der Funktionsweise der Software vertraut gemacht. Schlüsselbenutzer werden ebenfalls in Präsenzschulungen unterrichtet, wobei die Möglichkeit bestehen sollte, diese mit Hilfe von Online-Webschulungen, bei denen ein Trainer in direktem Kontakt mit den Benutzern steht, zu unterrichten. Gerade bei weltweit ausgerollten Projekten ist diese Art der Schulung zweck- mäßig, um Reisekosten und Reisezeiten zu minimieren. Für Endbenutzer, Genehmiger, Kontrol-leure und deren Stellvertreter ist es sinnvoll, aufgezeichnete Online-Schulungen für klar definierte Prozesse anzubieten. Diese sollten jederzeit über ein Schulungsportal abgerufen werden können. Das Anbieten von regelmäßigen WebSessions mit einem persönlichen Trainer in Form von Frage- und Antwortrunden hat sich in vielen Unternehmen als sinnvoll erwiesen.

Trainingsdurchführung für Administratoren: Die Administratoren der Anwendung SAP GRC Access Control werden in Präsenzschulungen von fachlichen Spezialisten (ggf. Softwarelieferant) geschult. Vermittelt wird die Funktionsweise der Software in ihren verschiedenen Modulen in einer Detailtiefe, dass ein Second-Level-Support geliefert werden kann. Die täglichen Wartungsarbeiten zur fehlerfreien Funktion der Anwendung und zur regelmäßigen Bereitstellung von Reportingdaten (Batch-Risk-Analyse, BRA) sowie die Sicherstellung von funktionierenden Schnittstellen zu den angeschlossenen Kundensystemen muss ebenfalls trainiert werden. Ein gut geschultes Team von Administratoren kann neue Mitarbeiter(innen) im „Training on the job“ in die Aufgaben einweisen.

Trainingsdurchführung für Schlüsselbenutzer: Die Schlüsselbenutzer aus den Fachbereichen sollten nun entsprechend in der Verwendung der neuen Lösungen geschult und eingeführt werden. Hierzu sind vorher auf die Organisation abgestimmte Schulungsunterlagen zu erstellen, die die Unternehmensspezifika abdecken. Das Training kann als „Train the Trainer“-Konzept ausgerollt werden, um in späteren Phasen den neu ausgebildeten Trainern die Ausbildung der weiteren Anwender zu übertragen. Auf diese Weise kann das „Buy In“ von Seiten der Fachbereiche gestärkt werden. Schlüsselbenutzer erfüllen in vielen Organisationen eine wichtige Funktion als First- Level-Support. Daher ist es von besonderer Bedeutung, diese Benutzergruppe, möglichst in Prä-

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

77

senzschulungen, intensiv mit der Applikation vertraut zu machen. Hierbei hat es sich als sinnvoll erwiesen, die Schlüsselbenutzer auch in den Grundlagen von GRC Access Control zu unterrichten (was ist ein Risko, was ist eine Funktion, wie funktionieren Risikoanalysen, was ist eine Mitigierende Kontrolle…).

Trainingsdurchführung für Endanwender: Endanwender führen definierte Teilprozesse der GRC- Access-Control-Anwendung durch. Für Endanwender sollte eine Schulungsunterlage entwickelt werden, die jederzeit über ein Unternehmensportal abgerufen werden kann. Dieses kann in Form von beschreibenden Dokumenten (Word, Visio…) oder in Form von Offline-Aufzeichnungen des Prozesses, die interaktiv abgearbeitet werden können, bereitgestellt werden. Hier sollten die pro-jektleitenden Einheiten die Verfahren mitnutzen, die in den sonstigen ERP-Projekten zur Verfügung gestellt werden. Regelmäßige Frage- und Antwortrunden, die in Web-Sessions mit einem Trainer durchgeführt werden, haben sich als wertvoll erwiesen.

Training sonstiger Zielgruppen: Die interne Revision sollte an den Schulungen für Schlüsselbe-nutzer teilnehmen. Hier wird die wesentliche Funktionsweise der Anwendung erläutert und die Prozesse zur Risikoanalyse und zu den Benutzer- und Rollenprovisionierungen werden tiefgehend trainiert. Zusätzlich sollte die interne Revision im Umgang mit Reporting- und Auswertungsme-chanismen geschult werden. Die Mitbestimmungsgremien sollten ebenfalls in den grundlegenden Funktionen der Anwendung unterwiesen werden. Dieses schafft Vertrauen und Akzeptanz bei den Fragestellungen zur Verhaltens- und Leistungskontrolle.

78

6.4 PHASE PRODUKTIONSVORBEREITUNG („ROLLOUT“)

In der Rollout-Phase wird nun ein Pilot für den User-Acceptance-Test ausgeführt und dann SAP GRC Access Control in der Fläche ausgerollt. Hier stehen die Optionen „sukzessiver Rollout“ bzw. „Big Bang“, deren Vor- bzw. Nachteile unten skizziert werden, als Alternativen zur Verfügung. Auch werden in dieser Phase der spätere Support und der Betrieb der Lösung vorbereitet. Das für den Support und den Betrieb der Lösung vorgesehene Team sollte dabei den User-Acceptance-Test schon begleiten und entsprechend eigenständig eigenes Wissen aufbauen.

Die folgenden Arbeitspakete sollten nun durchgeführt werden:

1. Durchführung Pilot und User-Acceptance-Test: Nach erfolgreicher Implementierung aller Risiken, Workflows und auch neu definierten Rollen müssen diese einem großen Kreis von Fachbereichsteilnehmern, z.B. aus dem Finance & Controlling-Bereich zugeordnet werden. Diese müssen dann anhand der definierten Testfälle und Testskripte die entsprechenden Tests mit Begleitung des Supportteams durchführen.

Bei einem positiven Test kann dann eine Abnahme des Systems durch das Projektleitungs- komitee erfolgen und die weiteren Rollouts angegangen werden.

2. Rollout-Vorbereitung: In der Vorbereitung des Rollouts müssen nun sämtliche notwendigen Attribute der Benutzer (Rollenzuordnung), alle Rolleneigner, organisatorischen Ausprägungen etc. erfasst werden und für die Rollouts dokumentiert werden.

Beim Start in die Produktion muss sichergestellt sein, dass störende Altprozesse nicht mehr bedient werden. Die Abschaltung dieser Verfahren muss vorbereitet und kommuniziert werden.

3. Vorbereitung der Support- und Betriebsphase: Auf Grund der Erfahrungen des durchgeführten Piloten und des Trainings werden der Support der Lösung und auch der Betrieb vorbereitet. Hierzu wird der Helpdesk geschult und eine Knowledge-Datenbank aufgebaut.

4. Rollout der Lösung in die weitere Organisation:

Variante A: Sukzessiver Rollout: Hierbei wird schrittweise vorgegangen und die Lösung entweder für weitere Systeme oder weitere Fachbereiche und Geographien ausgerollt. Hierzu werden weitere Trainings und Schulungen durchgeführt.

Variante B: Big-Bang-Rollout: Hierbei wird für alle Systeme, Fachbereiche und Geographien ein Rollout z.B. über ein Wochenende durchgeführt. Der Aufbau aller notwendigen Rollenzuordnungen, Rolleneignerausprägungen etc. wird zuvor vorbereitet.

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

79

6.5 PHASE PRODUKTIVSTART („SUPPORT“)

Nach erfolgtem Rollout und offizieller Abnahme der eingeführten SAP-GRC-Access-Control-Lösung, kann nun das System offiziell in die Support und Betriebsphase überführt werden.

Hierzu wird entsprechend der Helpdesk instruiert und das technische Supportteam überwacht die Batchprozesse und Änderungsmanagementprozesse. Zudem überwacht das Risikomanagement die Einhaltung der eingeführten Zugriffssteuerungsprozesse.

Insbesondere sollte in der Anfangsphase kontrolliert werden, ob E-Mails in Workflows korrekt zuge- stellt werden und Workflows nicht überlang offenbleiben – letzteres wäre ein Indiz für eine Fehler-situation, weil evtl. ein Workflow-Adressat diesen nicht zugestellt bekommen hat. Allgemein sollten exklusive Workflow-Empfänger vermieden (mind. zwei Empfänger) und Delegationen geschult werden, um die Zahl „hängende“ Workflows zu begrenzen, auch der Einsatz von Escape-Routes ist zu empfehlen.

Beim Produktivstart ist es darüber hinaus wichtig, vor den ersten Access Requests, Rollenpflege-aktionen etc. die Altverfahren stillzulegen. D.h., ggfs. muss bei bestimmten ehemaligen Benutzer-verwaltergruppen der Zugriff auf die SU01 oder ähnlichen Transaktionen eingeschränkt werden (nur lesen, SU01D usw.). Gleiches gilt ggfs. für Zugriffe auf die PFCG statt dem BRM. Anträge – offline oder online – aus Altverfahren sollten archiviert und dokumentiert abgelegt werden für spätere Nachfragen von Revision und Wirtschaftsprüfern. Kontrollaktivitäten über Security Audit Log (SM20) sind ggf. zu beenden, wenn hier das EAM übernimmt. Hierbei ist allerdings nicht unbedingt gleich die Abschaltung des Security Audit Logs zu empfehlen. Es hat sich als gewinnbringend gezeigt, wenn das SAL weiterläuft für spätere Rückfragen und noch später reduzierte Audit-Klassen/Stufen.Für das EAM ist es darüber hinaus wichtig, nachzuhalten, ob die Kontrolleure ihren Tätigkeiten nach- kommen. Während Genehmiger typischerweise wegen der Natur der Notfälle schnell „gefunden“ werden, ist die Prüfung der durchgeführten Tätigkeiten kein attraktives Thema. Hier empfiehlt sich auch der Einsatz von Workflows zur Abzeichnung von Protokollen.

Abschließend sollte die zuständige Projektleitung den Produktivstart dokumentieren; gut ist dabei immer die Erhebung von Messwerten über die Zahl der Access Requests und Notfallprozeduren, die ohne Papierweg und oft innerhalb kürzester Zeit realisiert wurden.

80

6.6 IMPLEMENTIERUNGSSZENARIO

Wie im vorigen Kapitel dargestellt, kann die Einführung von SAP GRC Access Control in die gesamte Organisation eines Unternehmens schrittweise, in definierten Phasen oder über einen Big Bang erfolgen. In beiden Fällen sollte eine entsprechende Vorbereitung mit der Strategie-, Design- und Implementierungsphase des Piloten erfolgen.

Bei der schrittweisen Einführung in die Gesamtorganisation sollten folgende Faktoren zunächst betrachtet und evaluiert werden:

› Auswahl der wichtigsten Geschäftsprozesse und der dabei involvierten Fachbereiche: Meist bietet sich in der ersten Phase ein wichtiger Nebenprozess an, wie z.B. der Einkaufsprozess von Gebrauchsgütern.

› Danach müssen die für diesen Geschäftsprozess notwendigen SAP- oder Nicht-SAP-Systeme ausgewählt werden. Im optimalen Fall sollte dies nur ein System umfassen, um die Komplexität nicht zu erhöhen.

› Auch müssen die Ländergesellschaften ausgewählt werden, die bei der ersten Ausrollphase involviert sein sollen. Auch hier bietet sich an, dass zunächst mit einem Land begonnen wird. Dies hängt vor allem davon ab, ob die Geschäftsprozesse harmonisiert worden sind und nicht zu viele Ausnahmen existieren. Sind die Prozesse harmonisiert, so können auch mehrere Länder in den Rollout einbezogen werden. Ein limitierender Faktor ist die Teamgröße des zur Verügung stehenden Rollout-Supportteams, da eventuell an verschiedenen Standorten parallel Unterstützung angeboten werden muss.

› Ein weiterer Faktor, der bei der schrittweisen Methode betrachtet werden muss, ist das Vor- handensein eines SAP-Rollenkonzeptes, das schon zu einem hohen Maß harmonisiert ist und für das eindeutig die organisatorischen Attribute und Rolleneigner zugeordnet werden können. Ist dies nicht der Fall, so müssen die Abhängigkeiten des Rollendesigns mit anderen Geschäfts- prozessen und Fachbereichen analysiert werden. Ist das Rollenkonzept auf Basis von Aufgaben- rollen und nicht auf positionsbasierten Rollen aufgebaut, die auch Funktionalitäten und Berech- tigungen anderer Fachbereiche angrenzender Geschäftsprozesse umfassen, so lässt sich ein schrittweiser Rollout einfacher durchführen, da sich in diesem Fall der Umfang der zu migrie- renden Rollen und auch die Organisationseinheiten leichter eingrenzen lassen. Die gegenseitigen Abhängigkeiten sind somit geringer, sodass die notwendigen Abstimmungsaufwände zwischen den Fachbereichen kleiner sind.

Wie der Name schon symbolisiert, werden bei einer Big-Bang-Einführung alle neuen Workflows inklusive dem Risikomanagement und eventuell auch neu definierten Berechtigungen für alle Geschäftsprozesse und daran beteiligten Fachbereiche, sowie SAP- und Nicht-SAP-Systeme z.B. über einen definierten, kurzen Zeitraum (z.B. Wochenende) eingeführt. Alle Schritte der Imple-mentierungsphase müssen durchlaufen und auch ein erfolgreicher Pilot durchgeführt sein. Die Einführung kann speziell bei einem notwendigen Reengineering des Rollenkonzepts auch parallel zum bestehenden Berechtigungskonzept erfolgen, wenn über einen gewissen Zeitraum von z.B. zwei Wochen den Anwendern das neue bereinigte Rollenkonzept parallel zum bestehenden zugeordnet wird und dann später die alten Rollen entzogen werden. Der limitierende Faktor bei einer Big-Bang-

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

81

Einführung stellt in der Regel der notwendige Support dar, der normalerweise unmittelbar nach einer Einführung notwendig ist.

Folgende Vor- und Nachteile sind bei beiden Einführungsszenarien zu beachten.

Vorteile einer schrittweisen Einführung:

› Das gesamte Einführungsrisiko ist geringer, da erst nach einer Stabilisierung eines Geschäfts- prozessbereichs mit dem nächsten begonnen werden kann. Zudem kann zunächst mit Geschäftsbereichen begonnen werden, die für das Unternehmen weniger kritisch sind, wenn eventuell Ausfallzeiten des SAP Systems auftreten würden oder einzelne Mitarbeiter ihre geschäftskritischen Arbeiten nicht ausführen könnten.

› Es könnte ebenfalls zunächst mit einem weniger geschäftskritischen SAP-System begonnen werden.

› Das Projektteam muss für den notwendigen Support nach dem Rollout nur einen überschaubaren Fachbereich betreuen und nicht eine gesamte Organisation, z.B. eine Länderorganisation. Es muss daher das Rollout-Team nicht verstärkt werden.

› Der Schulungsbedarf kann auf wenige Schlüsselanwender begrenzt werden.

Nachteile einer sukzessiven Einführung:

› Die Abgrenzung der Geschäftsprozesse und Bereiche sowie deren Abbildung auf die SAP-Systeme können sich bei komplexen Organisationen schwierig gestalten.

› Speziell die Risikomatrixfestlegung muss schon für alle Geschäftsprozesse durchgeführt werden, da die kritischen Funktionstrennungsprobleme auch quer zu parallel verlaufenden Geschäftsprozessen auftreten können.

› Auch bei einer notwendigen Einführung eines überarbeiteten Rollenkonzepts lässt sich die Abgrenzung zwischen den Geschäftsbereichen oftmals schwierig gestalten, sodass das Reen- gineering eigentlich für die wichtigsten Geschäftsprozesse parallel durchgeführt werden müsste, da auch Funktionstrennungskonflikte übergreifend zu Geschäftsprozessen vorhanden sind, falls die Anwender (wie im Normalfall) in mehreren Prozessen involviert sind.

› Nach dem Ausrollen eines Fachbereichs ist es eigentlich noch nicht möglich, die entsprechenden Workflows und Self-Services gesamtheitlich live zu schalten, da ansonsten in den betroffenen SAP-Systemen eventuell eine nicht handhabbare Mixtur aus Alt- und Neukonzepten entsteht. Die Änderungen in den ausgerollten Fachbereichen sollten daher minimal sein.

Die Vor- und Nachteile eines Big-Bang-Rollouts stellen sich gerade umgekehrt dar. In der Regel kann in den meisten Fällen nur ein schrittweiser Rollout durchgeführt werden, da bei einem Big Bang die notwendige Support- und Schulungsunterstützung nicht im Einführungsteam verfügbar ist. Auch ist die Rollou-Koordination bei einem Big Bang nur mit entsprechend hohen Aufwänden realisierbar.

82

Die Standard-Produkt-Dokumentation (Installation, Konfiguration, Master etc.) befindet sich auf SAP Service Marketplace unter http://service.sap.com/instguides -> Analytics -> Governance, Risk, and Compliance -> GRC Access Control. Ein Sizing Guide befindet sich auf http://service.sap.com/sizing -> Sizing Guidelines -> Analytics. SAP veröffentlicht auch zusätzlich eine große Anzahl von „How-to Guides“, auf die wir an dieser Stelle hinweisen möchten. Diese befinden Sie unter http://www.sdn.sap.com/irj/bpx/grc -> Key Topics -> SAP GRC Access Control. Hier möchten wir im Speziellen auf folgende How-to Guides hinweisen:

› GRC 10.0 Pre-Installation › GRC 10.0 Post-Installation› AC 10.0 Post-Installation› AC 10.0 - Installation Checklist › SAP GRC Access Control 10.0 and NetWeaver Identity Management Die Anwenderdokumentation befindet sich unter auf http://help.sap.com/grc.

Ein wichtiger Hinweis zur Kompatibilität von Plugins / RTAs zum Zentralsystem ist der Hinweis 1352498. Ab SAP GRC10.0 SP10 wird eine Abwärtskompatibilität ermöglicht.

7. WEITERFÜHRENDE DOKUMENTATION

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

83

8. PRAXISBERICHT THYSSENKRUPP AG

ThyssenKrupp ist ein Technologiekonzern mit hoher Werkstoffkompetenz. Bei ThyssenKrupp arbeiten über 160.000 Mitarbeiter in rund 80 Ländern mit Leidenschaft und hoher Kompetenz an Produktlösungen für nachhaltigen Fortschritt. Ihre Qualifikation und ihr Engagement sind die Basis für unseren Erfolg. ThyssenKrupp erwirtschaftete im Geschäftsjahr 2012/2013 einen Umsatz von rund 39 Mrd. EUR.

Innovationen und technischer Fortschritt sind für ThyssenKrupp Schlüsselfaktoren, um das globale Wachstum und den Einsatz begrenzter Ressourcen nachhaltig zu gestalten. Mit unserer Ingenieur- kompetenz in den Anwendungsfeldern „Material“, „Mechanical“ und „Plant“ ermöglichen wir unseren Kunden, sich Vorteile im weltweiten Wettbewerb zu erarbeiten sowie innovative Produkte wirtschaftlich und ressourcenschonend herzustellen.

ThyssenKrupp hat sich im Rahmen einer ausführlichen Produktauswahl im Jahr 2008 für SAP GRC Access Control als Lösung zur Kontrolle von kritischen Berechtigungsvergaben im Geschäftsan-wendungsumfeld entschieden. Zusammen mit einem im Anschluss ausgewählten Implementie-rungspartner wurde ein Programm zur konzernweiten Einführung der Lösung aufgesetzt. Dieses hatte im Kern zunächst vordringlich folgende Ziele:

1. Einführung der Komponente „Risk Analysis and Remediation“ (RAR). Je nach lokalem Bedarf wird ggf. die Komponente „Superuser Privilege Management“ eingeführt.2. Erstellung eines einheitlichen Regelwerks zur Abbildung der Risiken im Berechtigungswesen von ERP-Systemen und möglicher Kompensierungsmechanismen. 3. Erarbeitung eines Rahmenkonzeptes für den Betrieb der Analyseplattform und den Change- Prozess bei der Regelwerkspflege. 4. Aufbau eines Competence Centers für die Risikoanalyse mit SAP GRC Access Control.5. Erstellung eines Roll-Out-Plans zum Anschluss der ERP-Systeme der Konzernunternehmen (Priorität zunächst auf SAP-basierte Systeme).

Zu diesem allgemeinen Vorhaben, das letztlich die Produktivsetzung einer kompetent geführten, konzerneinheitlichen Risikoanalyse auf ERP-Berechtigungen zum Ziel hat, kam eine Reihe von wichtigen Nebenbedingungen hinzu: › Es soll ein zentrales, konzerneinheitliches Regelwerk verpflichtend Verwendung finden, aller- dings mit der Möglichkeit von Erweiterungen durch die einzelnen Konzernunternehmen.

› Die Risikoanalyse soll auf einer konzernweit zentralen Plattform betrieben werden, mehrere dezentrale Installationen sind nicht vorgesehen.

› Im Rahmen der konzernweiten Einführung soll das Programm etabliert werden mit der grund- sätzlichen Pflicht aller Konzernunternehmen, ihre ERP-Systeme an die Risikoanalyse anzu- schließen, wobei hinreichend Übergangsfristen für die Anschlusstätigkeiten, die ersten Analysen, Bewertungen, Planungen und die anschließende Bereinigung vorzusehen sind.

› Eine verteilte Struktur für das Change Management der Regelwerke ist aufzubauen, die den Konzernunternehmen die Möglichkeit einräumt, an den Analysevorgaben und Risikodefinitionen mitzuwirken, um so von Anfang an die Akzeptanz im Konzern zu erhöhen.

84

Abbildung 11: Zielarchitektur einer zentralen Risikoanalyseplattform mit dezentralen Teams in den lokalen Einheiten

Nach der erfolgreichen Programminitiierung wurden für den Aufbau der notwendigen Kenntnisse und Erfahrungen für das Competence Center und die Prüfung möglicher Alternativen beim Betrieb und der Regelwerkspflege zunächst einige Pilotunternehmen im Konzern gewonnen, mit denen erste Versuche einer zentralen Risikoanalyse durchgeführt wurden. Dabei wurden sowohl technische Erfordernisse (RTA-Installation) getestet als auch fachliche Diskussionen zum zentralen Risikokatalog geführt. Darüber hinaus konnten die Pilotunternehmen die Erstellung individueller Regelwerke und Mitigationen testen.

Abbildung 12: Vorgehen zum Aufbau des GRC Access Control Competence Centers - Zusammenarbeit mit Piloten

Zentrale Risikoanalyse- plattform

Risikoverantwortlicher Berechtigungen Fachverantwortlicher

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

85

März April Mai Juni Juli August September Oktober November

Im Rahmen dieses Zusammenarbeitsmodells in der Pilotphase konnten so einerseits die Erfor-dernisse im Betrieb festgestellt werden, andererseits konnten im neu gegründeten zentralen Competence Center wichtige Erfahrungen mit der Lösung und dem Umgang der Problematik im Konzern gesammelt werden.

Abbildung 13: Programmplanung mit Pilotunternehmen

Ein weiteres wichtiges Element bei der Einführung war die Etablierung einer Programmstruktur und des Change Managements. Bereits bei der Produktsuche und Auswahl waren bei ThyssenKrupp die Bereiche Zentrales Rechnungswesen, Internal Auditing und IT gleichermaßen beteiligt, diese stellten innerhalb der Programmstruktur auch den Lenkungskreis als maßgebliches Entscheidungsgre-mium. Durch die damit erfolgte indirekte Einbindung der Fachbereiche wurde ein wesentlicher Baustein für die Akzeptanz einer Risikoanalyse auf Berechtigungen im ERP-Umfeld geschaffen.Innerhalb der Programmstruktur wurden für das Change Management der Regelwerksinhalte für die einzelnen Business Areas von ThyssenKrupp sog. Risikokoordinatoren benannt. Hierbei wurden nicht dezidierte Positionen, aber Aufgaben geschaffen, um einerseits die Kommunikation zwischen dem zentralen Competence Team und den Konzernunternehmen zu bündeln und andererseits effiziente Feedback- und Entscheidungswege zu ermöglichen. Wenn etwa ein Konzernunternehmen eine Risikodefinition und die Prüfsemantik aus dem zentral verbindlichen Master-Regelwerk anpassen möchte, so müssen die Änderungen vor Produktivsetzung von den Risikokoordinatoren gesichtet und letztendlich vom Lenkungskreis genehmigt werden. Diese können die Änderungen vorab in ihren jeweiligen Business Areas und den dortigen Konzernunternehmen auf etwaige Nebeneffekte prüfen.

Start-up Kickoff MR 1st Draft MR validiert

MR-Draft

Projektteamgeschult

Rahmen- konzept (Entwurf)

Rahmenkonzept

Anpassungen AG

Anpassungen KU 1

Anpassungen KU 2

Rollout Feinplan

Aufbau Masterregelwerk (MR) Validierung

Technische Architektur

Schulung Projekt-team

Aufbau Risikokatalog

86

Um den konzernweiten Rollout sowohl inhaltlich als auch vom Anschluss- und Betreuungsaufwand her in einem akzeptablen Rahmen zu halten und um die Fachorganisation nicht mit umfangreichen Änderungen im Berechtigungswesen zu überfordern, wurde ein Rollout-Plan in inhaltlichen und regionalen Phasen entwickelt. Zum einen wurden zunächst nicht alle ERP-Komponenten mit einem Risikokatalog und entsprechendem Master-Regelwerk zur Prüfung versehen, sondern nur der Einkaufsprozess, also Teile von FI/CO und MM. Auch hiermit konnte die Akzeptanz maßgeblich gesteigert werden, insbesondere weil Risiken im Einkaufsprozess wohlbekannt und seit vielen Jahren von Wirtschaftsprüfern begutachtet werden (Standardbeispiel: Die Stammdatenpflege von Kreditoren sollte nicht zusammen mit der Pflege von Belegen, etwa Rechnungen, vergeben werden). Zum anderen wurde die Anschluss- und Bereinigungspflicht zunächst nur für inländische Konzern- unternehmen vorgesehen, außerdem standen nur SAP-Systeme im Fokus, also noch keine Non- SAP-Systeme.

Für die formale Einordnung der Risikoanalyse von Berechtigungen in ERP-Systemen in die konzern- internen Vorgaben, etwa zum Betrieb von IT-Verfahren, wurde eine Konzernrichtlinie erstellt und verabschiedet, die den phasengesteuerten Rollout, die Verpflichtung der Teilnahme und den dazu- gehörigen Zeitrahmen definiert: Alle inländischen ERP-Systeme, die einen Einkaufsprozess abwi-ckeln, mussten sich – vom Beginn der Gültigkeit der Richtlinie an – innerhalb von zwei Jahren an die zentrale Risikoanalyseplattform anschließen. Nach Anschluss hatten die Unternehmen jeweils ein Jahr Zeit, ihr Berechtigungswesen von aufgezeigten Konflikten zu bereinigen – dies konnte so-wohl in Form von Berechtigungsüberarbeitungen als auch durch die Einstellung von mitigierenden Kontrollen durchgeführt werden.

Der so initiierte Rollout wurde darüber hinaus begleitet durch Kommunikationsmaterial, vorab geführte Gespräche mit Datenschutz und Betriebsrat. Für jedes Konzernunternehmen wurden – nach einer ersten Analyse – Workshops zur Interpretation der Ergebnisse durchgeführt und weiter- führende Schulungen der Fachbereiche und Berechtigungsteams zur Bedienung der Werkzeuge angeboten.

Als Programmergebnisse waren nach fast vier Jahren – in diesem Zeitraum kamen noch die Regel-werke zu Basis und HR/Datenschutz und Verkauf dazu – folgende zu verzeichnen:

1. Risikokataloge bzw. Masterregelwerke für Einkauf, Basis, HR/Datenschutz und Verkauf

› Erarbeitung eines Risikokatalogs für den Einkauf› Erstellung Masterregelwerk im Analysesystem› Anpassung und Validierung mit drei Piloten: Masterregelwerk war abgestimmt und kann nun im Rollout verwendet werden

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

87

2. Erarbeitung eines Risikokatalogs für Basis, HR/Datenschutz und Verkauf

Rahmenkonzept zur Risikoanalyse

› Analyse der organisatorischen Rahmenbedingungen bei ThyssenKrupp› Erarbeitung der Aufgabenverteilung zentrales GRC Access Control Team vs. dezentraler Fachverantwortlicher und Berechtigungsteams in den Konzernunternehmen › Entwurf geeigneter Support- und Change-Management-Prozesse› Verortung der Aufgabenverteilung in der Organisation von ThyssenKrupp› Abstimmung mit ThyssenKrupp IT Service GmbH, dem internen IT-Dienstleister, und den Konzernunternehmen › Abstimmung mit Datenschutz und Betriebsrat› Abstimmung mit Wirtschaftsprüfern Programmverortung sichergestellt, Organisation des Changemanagement verabschiedet und produktiv3. Anschlussplanung und -durchführung

› Planung der Teilnahmereihenfolge in Absprache mit den Konzernunternehmen ist erfolgt› Anschlüsse der Konzerunternehmen durchgeführt (sofern bereits Anschlusszeitpunkt erreicht)› Analyseworkshops und Schulungen durchgeführt› Konzernunternehmen bereinigen Berechtigungskonflikte planungsgemäß Produktiver Betrieb der zentralen Plattform ist erfolgt

Vor diesem Hintergrund wurde die gesamte Programmdurchführung 2008 – 2012 als erfolgreich angesehen, die zentrale Risikoanalyse auf Berechtigungen in ERP-Systemen war inländisch etab-liert und Teil der Gesamtstrategie.

Im Rahmen einer bei ThyssenKrupp ab 2012 erfolgten Reorganisierung des Konzerns wurden einige der oben beschriebenen Programmelemente organisatorisch verlagert und umbenannt.

88

Im Folgenden werden die Migration von SAP GRC Access Control 5.3 nach 10.0 sowie die Integration von SAP GRC Access Control und Identity Management am Beispiel von SAP NetWeaver Identity Management einschließlich möglicher Synergieeffekte dargestellt.

9.1 MIGRATION VON SAP GRC ACCESS CONTROL 5.3

Während GRC Access Control 5.3 primär eine Java-Applikation ist, läuft GRC Access Control 10.0 auf einem ABAP-basierten System. Daher gibt es keinen Upgradepfad von einer Version zur anderen, sondern nur die Möglichkeit einer Migration. Dabei wird ein Großteil der Konfigurationen und Daten aus dem 5.3er-System exportiert und in das 10.0er-System wieder importiert. Hierfür stellt SAP ab 5.3 SP 13 eine entsprechende Migrationsapplikation zur Verfügung, die einen strukturierten Export der Daten erlaubt.

Dieses Migrationstool findet sich auf dem Servicemarketplace der SAP unter SAP GRC Access Control 10.0, wird aber auf dem Java-Stack der AC-5.3-Installation eingespielt:

9. ANHANG:

Abbildung 14: Datenmigrationsapplikation in AC5.3 SP13 (Java)

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

89

Beim Superuser Privilege Management wiederum wird über das GRC10.0-Plug-in für die ange-schlossenen Backend-Systeme ein Migrationswerkzeug zur Verfügung gestellt, mit dem sich die lokale FireFighter-Konfiguration exportieren und dann in das zentrale System wieder einspielen lässt.

Folgende Daten können mittels dieser beiden Werkzeuge übernommen werden:

Der Migrationsprozess sollte daher mit einem Schritt beginnen, der berücksichtigt, welche Daten überhaupt übernommen werden, sollen und können und wie jeweils mit anderen Daten zu verfahren ist. So muss beachtet werden, dass die Workflows mit der ABAP-basierten Workflow-Engine nach- gebaut werden müssen. Historische Daten wie Antragsgenehmigungen / Audit Trails oder Manage-mentberichte sind nicht übertragbar und sollten passend archiviert werden. Hier ist zu empfehlen, von den Management-Berichten evtl. Screenshots anzufertigen und die Daten früherer Anträge aus der Datenbank zu exportieren und etwa als PDF abzulegen für zukünftige Anfragen von Prüfern.

Als weiterer Vorbereitungsschritt wird die Installation des Migrationswerkzeugs benötigt. Hierfür muss die AC5.3-Version auf SP13 angehoben werden. Das Migrationstool wird separat im Java-Stack deployt. Die 10.0er-Plug-ins müssen überall eingespielt werden für den Export der SPM-Daten.

Anschließend müssen im 10.0er-Zentralsystem die Benutzer für die Genehmiger, Kontrolleure etc. angelegt werden sowie die kundenindividuellen Felder, die im CUP verwendet werden. Bevor die eigentlich Migration beginnt, müssen die 5.3er-Aktivitäten eingestellt werden, damit nicht weitere Produktivdaten nach Export anfallen. Der Enduser-Zugriff sollte daher ebenfalls geschlossen werden.

RAR EPM CUP SPM

› Regelwerk (SoDs, kritische Aktionen / Berechtigungen)› Kritische Rollen und Profile› Organisationsregeln› Genehmiger› Mindernde Kontrollen› Kontrollzuweisungen

› Konfigurationsdaten› Rollenattribute› Organisationswert- zuordnungen› Rollen› Pflegevorgänge› Zuordnung von Rollen zu Pflege- schritten

› Konfigurationsdaten› Workflowtypen› Genehmiger› Stages und Pfade› Eskalationskonfi- gurationen und -Ausnahmerouting› Rollen

› FireFighter-Tabellen› Verantwortliche› Kontrolleure› Ursachencodes

90

Der Ablauf der Migration selbst sieht dann folgendermaßen aus:› Datenexport relevanter Inhalte von AC5.3 und lokalen SPM-Konfigurationen› Kopie der Datendateien in einen Importordner auf dem GRC10.0-System› Import der Konfigurationsdaten› Konnektoren- und Konnektorengruppenpflege im GRC10.0-System› Organisationseinheit anlegen für die mindernden Kontrollen› Import der Applikationsdaten für die Komponenten

Nach der Datenmigration müssen die nicht übertragbaren Konfigurationen im GRC10.0-System nachgezogen bzw. neu aufgebaut werden. So müssen insbesondere für ARM für jeden Initiator und Approver Determinator und für BRM für jede Konditionengruppen und Genehmigerkriterien jeweils die dazugehörigen BRF+-Regeln (oder Funktionsbausteine) erstellt werden. Dann müssen ggf. noch die E-Mail-Templates angelegt werden, wenn in AC5.3 welche verwendet wurden. Abschließend müssen die Daten und die Funktionsweise der Workflows geprüft und intensiv getestet werden. Da der Umstieg auf SAP GRC Access Control 10.0 ein völlig verändertes Benutzerinterface mit sich bringt, sind Anwenderschulungen durchzuführen und ggf. noch User Acceptance Tests einzuplanen.

Ist die Migration erfolgreich durchgeführt worden, sollten die oben angeführten Archivierungs-vorgänge auf Managementberichte und Audit-Trails / Altanträge durchgeführt werden, bevor das AC5.3-System aus dem Betrieb genommen wird.

Weitere Tipps für die Go-live-Strategie im Rahmen einer Migration von GRC Access Control 5.3: Wenn die Plug-ins für 10.0 auf die Satellitensysteme eingespielt werden, werden die RTAs (Kompo-nenten VIRSA*) dabei gelöscht. Dennoch können die jeweiligen Backends weiter im AC5.3-Szenario betrieben werden. Dies funktioniert, weil der Code der 5.3er-RTAs in den 10.0er-Plug-ins enthalten ist. Allerdings muss dabei beachtet werden, dass die 10.0er Plug-ins hier immer einen bestimmten 5.3er-SP-Level enthalten. Prüfen Sie daher unbedingt den Zentralhinweis 1680268 („Kompatibilität von Paketen zu SAP GRC Access Control“) und die darin referenzierten Einzelhinweise.

Der Vorteil des Verfahrens besteht dann allerdings darin, dass die Namensräume AC5.3 vs. AC10.0 getrennt sind und beide Szenarien vollkommen parallel betrieben werden können. Dies vereinfacht den Rollout der Migration: Systeme können bereits Monate vorher mit der Software bestückt werden, werden dann aber nur in Teilrollouts von einem Verfahren auf das andere umgestellt. Hier muss allerdings im Vorfeld genau überlegt werden, ob etwa Workflows über zwei verschiedene Verfahren angeboten werden sollen, dies hängt stark von der Differenzierung der Verfahren in der Organisation ab.

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

91

9.2 INTEGRATION GRC ACCESS CONTROL/IDENTITY MANAGEMENT

Schon unter SAP GRC Access Control 5.3 gab es die Möglichkeit, die Provisionierungsmechanik von CUP mit anderen Identity-Management-Systemen zu verknüpfen. Hierfür stellt GRC Access Control Webservices zur Verfügung, die von diesen anderen Systemen zur Datenübergabe gerufen werden können, etwa um eine Risikoanalyse durchzuführen. GRC Access Control wiederum kann aktiv einen Workflow in ein anderes Identity-Management-System übergeben.

Die Gründe für die Kopplung von GRC Access Control mit solchen Systemen sind vielfältig. SAP GRC Access Control 5.3 fehlte im Vergleich zu guten Identity-Management-Produkten die Flexibilität im Workflow-Betrieb, hier konnten neben dem Standard kaum kundenindividuelle Anpassungen vorge- nommen werden. Darüber hinaus war die Anzahl der Non-SAP-Konnektoren vergleichsweise über-schaubar. Während diese Argumente bei SAP GRC Access Control 10.0 an Gewicht verlieren – hier ermöglicht die BRF+-Workbench die Formulierung komplexer Auswertungen und Bedingungen für die Workflowsteuerung, außerdem sind mehr Non-SAP-Konnektoren verfügbar und über das Konnektor- Framework auch selbst herstellbar – bleiben weitere Gründe nach wie vor erhalten:

› Oft werden in Unternehmen bereits Identity-Management-Systeme im Non-SAP-Umfeld betrie- ben, die nicht abgelöst werden können oder sollen, dennoch will man für die SAP-Systeme Gebrauch von der Risikoanalyse und dem Notfallbenutzerverfahren von SAP GRC Access Control machen, die Provisionierung jedoch aus dem übergreifenden Identity Management steuern.

› Mitunter sind auch die organisatorischen Strukturen, die solche Plattformen betreiben, nach Applikationsumfeld unterschiedlich und eine einheitliche Werkzeugauswahl im Großkonzern- bereich weder einfach herstellbar noch anstrebenswert: Die Einführung eines einzigen, einheitlich übergreifend über alle Applikationsbereiche hinweg arbeitenden Identity-Management-Produktes ist hochkomplex, dauert typischerweise Jahre, ein durchgehender Projekterfolg ist selten. Gerade im Großunternehmensumfeld hat es sich daher bewährt, eher mehrere bereichsweit agierende Identity-Management-Systeme miteinander zu verbinden, als einen Monolithen aufzubauen.

› Die Integration von HCM-Merkmalen (Position, Abteilungszuordnung, Integration des Org- Managements usw.) ist bei Identity-Management-Systemen teilweise besser gelöst und stellt mehr Auswertungsmöglichkeiten zur Verfügung als bei SAP GRC Access Control. Hier gilt es, noch einmal darauf hinzuweisen, dass die Benutzer- und Rollenprovisionierung über SAP GRC Access Control rein antragsbasiert erfolgt. Eine komplexe interne Identitätsdatenbank etwa mit HCM-Merkmalen an Mitarbeitern wird nicht vorgehalten.

92

› Wenn man sich nun zu dem Schritt entschieden hat, ein vorhandenes oder zukünftiges Identity- Management-System mit SAP GRC Access Control zu verbinden, stellen sich zunächst einige allgemeine Fragen, die maßgeblich für die Lösungsarchitektur sind:

› In welchem Werkzeug sollen Endanwender die Anträge stellen? Es ist immer davon abzuraten, Endanwender für die Beantragung von Benutzern und Berechtigungen verschiedener Applikationen auf unterschiedliche Antragsverfahren zu schicken. Dies stiftet nur Verwirrung, führt zu Akzeptanz- problemen und beim Helpdesk zu erheblichen Mehraufwänden bei der Anleitung der Anwender.

Abbildung 15: Integrationsbild der verschiedenen Funktionen von SAP GRC Access Control und einem Identity-Manage-ment-System am Beispiel SAP NetWeaver Identity Management

SCM Java Portal

DB OS

Legacy

Email

Web App

HCM ERP

SAP Access Control (GRC-Suite

Identity-Mgmt.Monitoring & Audit

Konformitäts- prüfung durch GRC

SAP Business Suite Integration

RegelbasierteZuweisung von Businessrollen

Passwort-management Provisionierung an SAP-

und Non-SAP-Systeme

Genehmigungen

Identity-Virtualisierung und Identity-Servise

Zentraler Identity-Store

SAP NetWeaverIdentity Management

HCM

z.B. Neueinstellungen

z.B. Order2Cash

Geschäftsprozess benötigt korrekte Benutzeranlagen und Rollenzuweisungen in Systemen

IDM angestoßen durch HR-Prozesse und Daten

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

93

› In welchem Werkzeug sollen Genehmigungen durchgeführt werden? Hier ergeben sich ähnliche Probleme wie beim ersten Punkt. Die Menge der Genehmiger ist allerdings typischerweise kleiner als die der Endanwender und ggf. auch disjunkt, d.h., Genehmiger können ggf. jeweils auf „ihr“ Werkzeug geschult werden und müssen nur selten zwei oder drei verschiedene benutzen. Darüber hinaus werden Genehmiger oft über E-Mail-Benachrichtigungen in die Workflows eingebunden und müssen „das richtige“ System nicht erst suchen.

› Welche technischen Restriktionen gibt es ggf. bei der Kopplung, die bestimmte Szenarien erschweren? Welche Konnektorentypen sind notwendig und können von welchem Produkt am besten geliefert werden?

› Wie komplex sind der Betrieb und die Fehlerdiagnose bei bestimmten Lösungsarchitekturen? Ist der Aufbau noch mit vertretbarem Aufwand zu warten?

Grundsätzlich gibt es drei verschiedene Lösungsarchitekturen bei der Integration von GRC Access Control mit einem anderen Identity-Management-System: Head-, Tail- oder Sandwich-Aufbau:

1. Beim Head-Verfahren steht SAP GRC Access Control „vorne“ und dient als Einstiegspunkt den Endanwendern für die Antragsstellung zur Verfügung. Es baut den dazugehörigen Workflow auf und erstellt die Risikoanalyse, sofern Benutzer oder Berechtigungen für SAP-Applikationen beantragt werden (ggf. auch für Non-SAP-Applikationen, wenn die Risikoanalyse hierfür möglich ist), die Analyseergebnisse kann der Genehmiger dann zur Entscheidungsfindung verwenden. Wurde der Antrag genehmigt, wird der Workflow an das Identity-Management-System zur Weiter- vermittlung in die SAP- und Non-SAP-Backendsysteme übergeben. Eine Untervariante ist hierbei, dass nur die Non-SAP-Workflows übergeben werden und die SAP-Workflows die SAP-Systeme direkt provisionieren.

Dieser Ansatz wird auch als AC-Driven-Integration bezeichnet und erfordert die vollständige Synchronisation des IDM-Systems durch SAP GRC Access Control.

2. Bei der Sandwich-Variante steht SAP GRC Access Control in der Mitte und wird für die Risiko- analyse eingeschleift, d.h., die Antragsstellung erfolgt im Identity-Management-System, die abschließende Provisionierung ebenfalls. Innerhalb des Workflows wird entschieden, ob eine Risikoanalyse erforderlich ist, diese wird dann mit SAP GRC Access Control durchgeführt.

94

Wenn im Sandwich-Verfahren jedoch auch Workflows für Non-SAP-Systeme ohne die Einschlei-fung von SAP GRC Access Control verwendet werden, stellt sich wieder die eingangs erwähnte Frage, ob die Gruppen der Genehmiger im IDM und im SAP GRC Access Control disjunkt sind oder ob den Genehmigern zwei verschiedene Werkzeuge zumutbar sind.

Im Sandwich-Verfahren ist sowohl ein Polling des Status der Anträge im SAP GRC Access Control durch das IDM möglich als auch ein Callback vom SAP GRC Access Control in das IDM, wenn der Workflow im SAP GRC Access Control beendet wurde.

3. Beim Tail-Verfahren steht SAP GRC Access Control „hinten“ und führt hier nur die Provisionie- rung in die SAP-Systeme durch. Dies wird zum einen dort betrieben, wo das Identity-Manage- ment-Produkt keinen guten SAP-Konnektor besitzt, zum anderen kann hier noch eine Risiko- analyse eingeschleift werden (wobei sich dann das Problem der Genehmiger von Workflows einstellt). Ein Nachteil dieses Verfahrens ist, dass das Identity-Management-System typischer- weise immer noch an die einzelnen Backend-Systeme angeschlossen werden muss, um Schiefstände zwischen den letztlich in die Systeme provisionierten Daten und ggf. sogar lokal vorgenommenen Änderungen (z.B. nach Systemkopie) zu vermeiden und den korrekten Daten- stand im Identity-Management-System sichtbar zu machen.

Abbildung 16: Sandwich-Architektur

Anlage eines Rollenzuweisungsantrags im Identity Management

Vorverarbeitung des Antrags im Identity Management

Antragsverarbeitung & Risikoanalyse in Access Control

Identity Management liest Antragsstatus

Automatisch (regelbasiert, ggf. über HCM)

Zuweisung erfordert Risikoprüfung

Risikoverletzung gefunden

Manuell (Endbenutzerantrag)

Zuweisung erfordert keine weitere Prüfung

Keine Risikoverletzung gefunden

Antragsumleitung in manuelle Genehmigung

abgelehnt

Keine Provisionierung

angenommen

Identity Management startet Provisionierung

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

95

Abbildung 17: Beispiel einer Tail-Architektur

Grundsätzlich besteht die Komplexität des Aufbaus darin, dass keines der Systeme die Datenkon-sistenz bezüglich der Benutzer und Rollen verlieren darf, um weiterhin korrekte Abläufe durchführen zu können. Hierbei müssen manuelle Korrekturen an Benutzerstämmen, Rollenpflegeaktivitäten in den Backends – mit Synchronisation von Rollenänderungen in den jeweiligen Rollenshop des IDM- Systems und von SAP GRC Access Control – oder etwa Systemkopien berücksichtigt werden. Die einzelnen Provisionierungsschritte und Workflows müssen auch den Ausnahme- bzw. Fehlerfall abdecken. Dies ist bei einer Architektur mit zwei Benutzer- bzw. Rollenprovisionierungswerkzeugen wesentlich schwieriger einzuhalten. Ein Beispiel: Wenn bei der Benutzerpflege ein technischer Fehler passiert – etwa weil der Benutzerstamm im Zielsystem aus nicht bekannten Gründen gegen Änderungen gesperrt ist –, so muss dieser Fehler an alle beteiligten Systeme zurückvermittelt werden. Komplexer wird dieser Vorgang, wenn nicht nur eine Änderung durchgeführt werden soll, sondern mehrere. Ein Beispiel hierzu etwa ist die Ausnahmebehandlung bei der Risikoanalyse. So kann ein Endanwender auch mehrere Rollen, z.B. fünf gleichzeitig, in einem Antrag anfragen. Wird von diesen Rollen allerdings eine vom Genehmiger abgelehnt wegen zu hohem Risiko, so ist nur diese eine betroffen, nicht die anderen vier. Diese geänderte Provisionierungslogik muss dann bei

Anlage eines Rollenzuweisungsantrags im Identity Management

Vorverarbeitung des Antrags im Identity Management

Antragsverarbeitung & Risikoanalyse in Access Control

Identity Management liest Antragsstatus

Automatisch (regelbasiert, ggf. über HCM)

Zuweisung erfordert Risikoprüfung

Risikoverletzung gefunden

Manuell (Endbenutzerantrag)

Zuweisung erfordert keine weitere Prüfung

Keine Risikoverletzung gefunden

Antragsumleitung in manuelle Genehmigung

abgelehnt

Identity Management sichert Datenkonsistenz

angenommen

CUP startet Provisionierung

IDM startet Provisionierung

96

einer zweistufigen Lösung auch dem Antragserfassungswerkzeug zurückgemeldet werden. Eine weitere Komplikation kann entstehen, wenn der Genehmiger eine Rolle ablehnt, aber stattdessen eine andere alternativ in den Antrag aufnimmt. Hier gibt es oft Unzulänglichkeiten in den Mecha-nismen der IDM-Systeme, die ein solches Verhalten nicht erwarten. Daher sollte das IDM-Produkt vorab auf entsprechende Features hin geprüft werden.

Diese Schilderung soll nicht die Möglichkeit der Integration eines Identity-Management-Systems mit SAP GRC Access Control diskreditieren. Allerdings sollte die Komplexität der Use Cases und die der möglichen Sonderfälle im Workflow nicht unterschätzt werden. Inzwischen haben etliche SAP- Kunden erfolgreich entsprechende Integrationsszenarien produktiv laufen, daher ist der Betrieb durchaus beherrschbar. Bekannte Produkte, mit denen dies gelungen ist, stammen dabei von SAP (NetWeaver Identity Management), Novell (Identity Manager), IBM (Tivoli).

Die Liste der von SAP GRC Access Control 10.0 angebotenen Webservices für die Integration umfasst etliche nützliche Services, die hier einmal zur Bewertung aufgelistet werden:

Schnittstelle Beschreibung Technischer Name

Abrufservice Nachschlagen von möglichen Aufrufswerten zu Schnittstellen, z.B. Werte für den Antragsstatus

GRAC_LOOKUP_WS

Rollensuche Suche nach Rollen vor Antrags-stellung im GRC Access Control

GRAC_SEARCH_ROLES_WS

Rollendetails Gibt Details der Rollenbeschrei-bung und der Attribute einer Rolle zurück

GRAC_ROLE_DETAILS_WS

Applikationsauswahl Gibt die konfigurierten Applika-tionen (Konnektoren, Systeme) zurück

GRAC_SELECT_APPL_WS

FireFighter Liste der FireFighter-IDs und Owner

GRAC_FIRE_FIGHTER_WS

Benutzerzuweisungen Gibt die derzeitigen Rollen eines Benutzers zurück

GRAC_USER_EXISTING_ASS-GN_WS

Provisionierung Webservice zum Start einer Provisionierung

GRAC_USER_ACCES_WS

Risikoanalyse (mit Antragsnummer)

Durchführung einer Risikoanalyse mit Antragsreferenz

GRAC_RISK_ANALYSIS_WITH_NO_WS

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

97

Schnittstelle Beschreibung Technischer Name

Orgsanisationszuwei-sungsantrag

Zuweisung von Rollen an OIM-Objekte wie Stellen, OUs etc.

GRAC_ORG_ASSGN_REQUEST_WS

Provisionierungslog Gibt die Daten zum Stand eines Benutzers zurück (wann ange-legt, durch wen, mit welchen Rollen etc.)

GRAC_PROV_LOGS_WS

Antragsstatus Gibt den Status eines Antrags zurück

GRAC_REQUEST_STATUS_WS

Auditlog Gibt Workflowdaten über Genehmiggsstufen, -pfade und Genehmigerentscheidungen zurück sowie die Provisionie-rungsresultate

GRAC_AUDIT_LOGS_WS

Antragsdetails Antragsdetails mit Risikoanaly-seergebnis

GRAC_REQUEST_DETAILS_WS

Risikoanalyse (ohne Antragsnummer)

Rollen- und Benutzeranalyse GRAC_RISK_ANALYSIS_WOUT_NO_WS

Provisionierungsaus-gang

Service, der vom IDM gerufen wird, um AC über das Ergebnis eines Requests zu informieren

GRAC_EXIT_FROM_IDM_WS

98

9.3 AUSBLICK SAP GRC ACCESS CONTROL 10.1

Die Version 10.1 von SAP GRC Access Control bringt im Wesentlichen ein verbessertes User Interface mit: SAP GRC Access Control 10.1 nutzt das neue UI5-Framework des NetWeaver 7.40, das auch Voraussetzung für die Installation ist. UI5 ermöglicht es Endanwendern, mit der verfügbaren Client- Technologie – NetWeaver Business Client 4 oder etwa Internet Explorer 9 oder 10 – noch interaktiver mit den Applikationen zu agieren, Drag-&-Drop-Vorgänge direkter durchzuführen und Kontextmenüs mit Side-Panels flexibel einzusteuern.

Abbildung 18: Beispiel für ein einblendbares Side-Panel

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

99

Darüber hinaus bringt SAP GRC Access Control 10.1 eine Reihe von Verbesserungen und Erweite-rungen für einzelne Komponenten mit:

Übergreifend: Berechtigungen für Reporting & Dashboards

Zum einen wurden hier weitere Berechtigungsprüfungen eingeführt, die es ermöglichen, Dashboard- Sichten und Reports voneinander abzugrenzen. Kann ein Teil der Ergebnismenge eines Berichtes wegen fehlender Berechtigungen nicht in den Bericht integriert werden, wird dies nun eindeutig mit einer Meldung angezeigt. Zum anderen gibt es nun die Möglichkeit für den Endanwender, sich die konkret fehlenden Berechtigungswerte im Folgenden anzeigen zu lassen. Dieses Verhalten ist konfigurierbar.

BRM/ARM: Umgebungskontext

Im BRM gibt es mit SAP GRC Access Control 10.1 die Möglichkeit, Systeme zu Umgebungsgruppen zusammenzufassen. So können Rollen system- und landschaftsübergreifend bezogen auf einen bestimmten Kontext erstellt werden. Z.B. können die Entwicklungssysteme eines ERP-Landschafts-verbunds zur Umgebung „Entwicklung“ zusammengefasst werden, während die Produktivsysteme zur Umgebung „Produktion“ zusammengefasst werden. Auf beiden Gruppen lassen sich dann Rollen pflegen, aber auch die Zuweisung im ARM steuern.

100

Abbildung 19: Vereinfachter Antrag

ARM: Konfiguration der Attribute bei der Rollensuche

Für die Beantragung von Rollen im ARM ist es nun möglich, die Suchfelder für die Endanwender vorab besser einzustellen. So können Kriterien komplett ausgeschaltet werden und andere dafür verpflichtend gemacht werden.

ARM: Vereinfachter Antrag

Sowohl bei der Auflistung der offenen Work Items in der Inbox als auch für die Beantragung von Benutzeranlagen, -änderungen und Rollenzuweisungen wird nun eine vereinfachte Ansicht anboten. Dabei kann die Anzahl der sichtbaren Felder erheblich reduziert werden (konfigurierbar) sowie Standardfelder für die Anzeige umbenannt werden. Für die Antragsgründe können Textbausteine zur Auswahl voreingestellt und per Drop-Down zur Verfügung gestellt werden. Diese Maßnahmen können den Zugang zur Applikation für den allgemeinen Endanwender erheblich vereinfachen.

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

101

Root Cause Analysis & Remediation

Für eine gezieltere Risikoanalyse können vorab kundenindividuelle Benutzergruppen erstellt werden, auf die die Analyse durchgeführt wird. Im nun verfügbaren UI5-Interface der Risikoanaly-seergebnisse können per einfachem Drill-Down sowohl die Analysedetails eingeblendet werden als auch über eine direkte Was-wäre-Wenn-Simulation die Ursache einer Risikoverletzung festgestellt werden. So kann die direkte Simulation auf einer Risikoverletzung etwa der Entzug einer Rolle sein, aber auch die Erstellung einer mindernden Kontrolle.

Abbildung 20: Root Cause Analysis mit Drill-Down hinunter auf Berechtigungsebene und Simulation eines Rollenentzugs

Systemspezifische Organisationsregelanalyse und Organisationsregel-Assistent

Organisationsregeln können in SAP GRC Access Control 10.1 nun systemspezifisch angegeben werden. Darüber hinaus unterstützt ein Schritt-für-Schritt-Assistent mit Organisationsregeln bei deren Erstellung: Zunächst wird das Zielsystem ausgewählt und dann die für dieses System geltenden Organisationsebenen und -werte. Dabei werden zunächst auch Organisationsebenen angeboten, bei denen bereits Risikoverletzungen vorliegen. Die Bündelung dieser Features macht die Handhabung dieser eher komplexen Technik wesentlich überschaubarer.

102

9.4 DEZENTRALES NOTFALLBENUTZERVERFAHREN, AUFNAHME DES DBTABLOGS

Die in der Version 10.0 SP10 eingeführte Möglichkeit, sowohl zentral über die GRC-Applikation als auch dezentral im zu reparierenden System in die Notfallbenutzerverwendung einzusteigen, wird fortgeführt. Außerdem werden Tabellenänderungsprotokolle aus dem DBTABLOG nun in der Proto-kollierung der Notfallbenutzertätigkeiten verfügbar gemacht.

9.5 FUNKTIONEN FÜR HANA-APPLIKATIONEN

Mit SAP GRC Access Control 10.1 können nun Benutzeranlagen und -änderungen sowie Rollenzu-weisungen in HANA-Systemen durchgeführt werden. Darüber hinaus können HANA-Privilegien mit der Risikoanalyse auf kritische Berechtigungen und SoD-Verletzungen hin geprüft werden.

Abbildung 21: Beispiel einer Risikoanalyse von HANA-Privilegien

SAP

® G

RC

AC

CES

S C

ON

TRO

L 10

.0 B

EST-

PR

ACTI

CE-

LEIT

FAD

EN Z

UR

EIN

FÜH

RU

NG

DER

SAP

-GR

C-L

ÖSU

NG

EN V

ERSI

ON

1.0

, 27.

AP

RIL

201

5 ©

DSA

G e

. V.

103

© DSAG e. V.

DSAG – Deutschsprachige SAP® Anwendergruppe e. V.Altrottstraße 34a69190 WalldorfDeutschlandFon: +49 (0) 6227 – 358 09 58Fax: +49 (0) 6227 – 358 09 59www.dsag.de I info@dsag.de