Compliant Identity Management mit SAP IdM und GRC AC

2.1 SAP GRC Access Control

Bevor wir mit der eigentlichen Vorstellung von SAP GRC Access Control beginnen, wollen wir im ersten Schritt ein paar Worte zur Architektur des Systems sowie zu den technischen Voraussetzungen verlieren, die notwendig sind, um die Anbindung von Zielsystemen zu ermöglichen.

Prinzipiell erfolgt die Anbindung von SAP-Systemen an das AC-System per Remote Function Call (RFC) über die Transaktion SM59. Eine Ausnahme stellt das SAP Identity Management dar, das per HTTP (Hypertext Transfer Protocol) und SPML (Service Provisioning Markup Language) mit dem GRC verbunden wird. Zusätzlich dazu ist eine Aktivierung der Webservices notwendig, um später die Integration zwischen SAP IdM und SAP GRC AC erfolgreich durchführen zu können. Die Aktivierung der relevanten GRC-Webservices erfolgt mithilfe der Transaktion SOAMANAGER.

Auf die einzelnen Schritte, die zur Konfiguration des Compliant Identity Managements notwendig sind, werden wir in Abschnitt 4.3 noch zu sprechen kommen. Einen prinzipiellen Überblick über die GRC-Architektur bietet Ihnen Abbildung 2.1.

Abbildung 2.1: GRC-Architektur

Vor dem Anschluss der Zielsysteme sind auf deren Seite sowie im GRC noch einige Voraussetzungen zu erfüllen. Für den erfolgreichen Austausch von Daten zwischen SAP GRC AC und dem jeweiligen Satellitensystem müssen zunächst verschiedene Plug-ins installiert werden. Dazu gehören:

• für GRC Access Control die in Abbildung 2.2 umrahmten Plug-ins,

Abbildung 2.2: Plug-ins für GRC Access Control

• sowie für das Zielsystem das in Abbildung 2.3 markierte Plug-in.

Abbildung 2.3: Plug-in für Zielsystem

Bei der Installation der Plug-ins ist darauf zu achten, dass diese vom Releasestand auch zu den anderen Komponenten des jeweiligen Systems passen. Dies gilt im Speziellen für das GRCPINW auf dem Zielsystem. Überdies bestehen gewisse Abhängigkeiten zum SAP GRC AC (z.B. Fiori UI zur Nutzung der GRC-Genehmiger-App), auf die an dieser Stelle nicht im Einzelnen eingegangen werden soll, die aber im SAP-Konfigurationsleitfaden für GRC nachgelesen werden können.

Nach diesem kurzen Abriss zur Architektur und zu den technischen Voraussetzungen können wir an dieser Stelle mit der Kurzvorstellung der Komponenten von SAP GRC Access Control beginnen, bevor wir im Verlauf des Kapitels einen detaillierteren Einblick in die vielfältigen Konfigurationsmöglichkeiten der Workflows im Kontext von SAP GRC AC geben. Diese Workflows sind für die Benutzeradministration hinsichtlich der Antrags- und Genehmigungsprozesse sowie einer integrierten Risikoprüfung für das SAP GRC Access Control unerlässlich.

Neben den von SAP standardmäßig ausgelieferten werden unternehmensspezifisch eingerichtete Workflows vorgestellt und deren Konfiguration wird im Kontext der Workflowinstrumente MSMP (Multi-Stage-Multi-Path) und BRF+ (Business Rule Framework) näher betrachtet.

Ein besonderer Stellenwert kommt hier den einzelnen Prozessschritten der Provisionierung im Kontext des Compliant Identity Managements zu.

2.1.1 Kurzvorstellung der Komponenten im AC-Kontext

Access Risk Analysis (ARA)

Access Risk Analysis (ARA), zu Deutsch »Analyse der Zugriffsrisiken«, ist die zentrale Komponente von SAP GRC Access Control. Sie ermöglicht es, teilautomatisierte Analysen auf Benutzer-, Rollen- und Profilebene durchzuführen und so ein Echtzeitbild der Risiken in der Systemlandschaft zu erhalten. Aus den gewonnen Erkenntnissen können Maßnahmen zur Bereinigung oder Mitigierung der identifizierten Risiken abgeleitet werden. Die Risiken werden in der sogenannten Segregation-of-Duties(SoD)-Matrix abgebildet und so dem Anwender für Analysen zugänglich gemacht.

Business Role Management (BRM)

Das Business Role Management (BRM) ist der Bestandteil von AC, der sich mit der Pflege und Weiterentwicklung von Rollen bzw. Privilegien in der Systemlandschaft beschäftigt. Mithilfe des BRM lassen sich sämtliche Änderungen an den Berechtigungen dokumentieren und revisionssicher nachvollziehen. Des Weiteren ist es möglich, dedizierte und unternehmensspezifische Workflows zu hinterlegen, die bei Modifikationen an den Berechtigungen zu durchlaufen sind. Die Funktionen des Business Role Managements ermöglichen es, den gesamten Prozess der Pflege und Weiterentwicklung von Berechtigungen innerhalb eines Tools zu steuern und abzubilden.

User Access Management (UAM)

Die Komponente User Access Management (UAM) wird für die Erstellung und Änderung von Benutzern verwendet. Hierzu stehen im UAM Genehmigungsworkflows bereit, sodass die Prozesse revisionssicher dokumentiert sind und zu jedem Zeitpunkt nachvollzogen werden können. Für einzelne Workflows sind Risikoprüfungen etabliert, die Berechtigungskonflikte zur Laufzeit sichtbar machen.

In Abschnitt 1.2 werden wir uns detaillierter die einzelnen Möglichkeiten im Kontext der verschiedenen Provisionierungsfunktionen ansehen.

Emergency Access Management (EAM)

Das Emergency Access Management (EAM), besser bekannt unter den Namen »Firefighter«, ermöglicht es, kritische (z.B. Replace und Debug) sowie nicht häufig verwendete Berechtigungen (z.B. Jahresabschluss) aus dem gewöhnlichen Benutzerstammsatz auszulagern. Diese werden einem Benutzer mit weiter reichenden Berechtigungen zugeordnet, genannt Firefighter. Der Vorteil des EAM liegt in der Protokollierung sämtlicher Tätigkeiten, die mit dem Firefighter ausgeführt werden. Durch die Protokollierung und spätere Prüfung der erzeugten Firefighter-Protokolle ist den Audit-Anforderungen genüge getan

Der Lifecycle im SAP GRC Access Control (siehe Abbildung 2.4) zeigt das Zusammenspiel der oben erwähnten AC-Komponenten auf; er erstreckt sich von der »Get-clean«- bis zur »Stay-clean«-Phase. Der skizzierte Zyklus zeigt die zu durchlaufenden Phasen auf und untermauert die in Abschnitt 1.1 getroffenen Aussagen bezüglich der Berechtigungskonzepte.

Abbildung 2.4: SAP GRC AC, Lifecycle

2.1.2 Workflows in Access Control – technische Grundlagen

Die Workflows in AC sind Teil der Komponente UAM, die im Kontext des Account- und Access-Managements (= Anlage und Änderung von Benutzern) innerhalb der SAP-Systemlandschaft eingesetzt wird. Prozessual lassen sich bei der Implementierung des User Access Managements im Access Control die in Abbildung 2.5 gezeigten Phasen identifizieren, die jeder Workflow durchlaufen sollte, um bei der späteren Produktivsetzung nicht auf Probleme zu stoßen.

Abbildung 2.5: MSMP-Prozessphasen

In den letzten Jahren haben die Anforderungen an die im System abzubildenden Szenarien hinsichtlich der automatisierten Antrags- und Genehmigungsprozesse spürbar zugenommen. Inzwischen reicht es für externe und interne Audits nicht mehr, einen Workflow zur Anlage oder Änderung von Benutzern im System bereitzustellen. Vielmehr ist es heutzutage notwendig, schon während der Neuanlage bzw. Änderung von Benutzern aufzeigen zu können, welche Risiken mit der Beantragung der Berechtigungen einhergehen, um möglichst frühzeitig Maßnahmen (z.B. mitigierende Kontrollen) einleiten zu können.

Die SAP hat zu diesem Zweck Standardworkflows zur Verfügung gestellt, welche rudimentär die Ansprüche der Audits erfüllen. Wir werden Ihnen im Folgenden diese Standardworkflows vorstellen und einen Einblick geben, wie sie an die Anforderungen der verschiedenen Organisationen angepasst werden können.

Doch zuvor muss im ersten Schritt die technische Seite des Workflowinstruments MSMP (Multi-Stage-Multi-Path) näher betrachtet werden. Das grundsätzliche Verständnis für die MSMP-Prozessimplementierung ist gerade für die später folgenden Ausführungen unabdingbar.

MSMP – technische Grundlagen

Die MSMP-Workflows lassen sich im GRC Access Control unter dem Menüpunkt »Maintain MSMP Workflows« finden. Der Aufruf des Menüpunkts erfolgt über den Pfad SPRO • IMG • Governance, Risk and Compliance • Access Control • Workflows for Access Control • Maintain MSMP Workflows oder alternativ direkt über die Transaktion GRFNMW_CONFIGURE_WD.

Der prinzipielle Aufbau der MSMP-Prozessworkflows erstreckt sich über sieben Schritte, die wie folgt lauten:

1. Process Global Settings,

2. Maintain Rules,

3. Maintain Agents,

4. Variables & Templates,

5. Maintain Paths,

6. Maintain Route Mapping,

7. Generate Versions.

Im Folgenden wird näher auf die einzelnen Schritte der MSMP-Prozessworkflows eingegangen.

Schritt 1: Process Global Settings

Dieser erste Teilschritt des MSMP-Prozessworkflows stellt eine Übersicht über die standardmäßig ausgelieferten Prozess-IDs im SAP GRC AC dar (siehe Abbildung 2.6).

Abbildung 2.6: MSMP, Prozess-IDs

Hierzu gehören beispielsweise die folgenden Prozess-IDs, auf die wir im Verlauf der Ausführungen noch genauer eingehen werden:

• Access Request Approval Workflow,
• Function Approval Workflow,
• Risk Approval Workflow.

Jede dieser Prozess-IDs stößt konkrete Aktivitäten des zugehörigen Workflows an, wie beispielsweise das Account- und Access-Management sowie die Pflege der SoD-Matrix und das Management von Berechtigungen.

Des Weiteren ist es in diesem Workflowschritt möglich, globale Einstellungen vorzunehmen, die anschließend für alle Workflows gelten, die der entsprechenden Prozess-ID zugewiesen sind. Als Beispiel kann hier die Aktivierung einer Eskalation (Enable Escalation) herangezogen werden. Das bedeutet im Einzelnen, dass alle Anträge, die zu einem Stichtag unbearbeitet sind bzw. noch nicht abgeschlossen wurden, an eine entsprechend definierte Person oder Gruppe weitergeleitet werden, die diese Anträge dann zu bearbeiten hat.

Schritt 2: Maintain Rules

Die Maintain Rules beinhalten eine Liste verfügbarer Regeln, die im Zuge der Konfiguration der Workflows genutzt werden können. Die ausgelieferten Regeln untergliedern sich nochmals in Rule Types und Rule Kinds (siehe Abbildung 2.7).

Abbildung 2.7: Rule Types und Rule Kinds

Vier verschiedene Rule Types sind verfügbar. Dazu gehören im Einzelnen:

• BRFplus Rule
  Wird innerhalb der BRF+-Anwendung definiert, um eine Übersicht aller Regelergebnisse abhängig von den Regel-Bedingungen zu erhalten.
• Function Module Based Rule
  Der Funktionsbaustein dient zur Ausgabe der Regelergebnisse.
• ABAP Class Based Rule
  Die Klassenmethode wird ebenfalls zur Ausgabe der Regelergebnisse genutzt.
• BRFplus Flat Rule (Line-Item by Line-Item)
  Im Gegensatz zur oben genannten BRFplus Rule gibt die BRFplus Flat Rule die Regelergebnisse einzeln, auf Basis der Line Items, aus.

Auch von den Rule Kinds werden im Standard vier Regeln mitgeliefert:

• Initiator Rule
  Sie legt den Genehmigungspfad fest, den ein Antrag zu durchlaufen hat, bevor die Provisionierung erfolgen kann.
• Agents Rule
  Diese Regel bestimmt den Verantwortlichen der jeweiligen Genehmigungsstufe.
• Routing Rule
  Die Routing Rule kann dazu genutzt werden, einen alternativen Genehmigungspfad im Workflow anzusprechen. Dessen Aufruf erfolgt auf der Grundlage von Attributen. Als populäres Beispiel kann hier die Differenzierung von Pfaden anhand der Existenz von SoD-Risiken herangezogen werden.
• Notification Variables Rule
  Hiermit bestimmen Sie die Variablenwerte zur Laufzeit, die in den Benachrichtigungs-Mails verwendet werden können.

Schritt 3: Maintain Agents

In diesem Teilschritt der MSMP-Workflow-Konfiguration werden die Genehmiger (z.B. Manager, Role Owner) hinterlegt, die im Kontext der Anträge als verantwortliche Personen agieren (siehe Abbildung 2.8).

Abbildung 2.8: GRC-Genehmiger

Neben der Festlegung der Genehmiger muss ebenfalls die Art der Benachrichtigungsmail festgelegt werden. Hierbei ist die Frage zu klären, ob es sich nur um eine Hinweismail (Notification) handelt oder aber um eine E-Mail, die eine Bearbeitung (Approval) des Antrags zur Folge hat.

Es ist außerdem möglich, dynamische Genehmiger zu hinterlegen, die durch eines der folgenden vier Attribute identifiziert werden können:

• Directly Mapped Users
  Benutzer dieser Gruppe werden aus dem Kreis der im GRC Access Control hinterlegten Genehmiger selektiert. Dieses Attribut eignet sich für statische Genehmigergruppen, die einer geringen Fluktuation unterworfen sind.
• PFCG Roles
  Der Genehmiger des Workflows wird anhand der zugeordneten PFCG-Rolle durch das GRC ermittelt.
• PFCG User Groups
  Eine PFCG User Group wird einem dedizierten Benutzer zugewiesen. Dabei könnte es sich beispielsweise um einen Prozesseigner handeln.
• GRC API Rules
  Die GRC API Rules dienen dazu, die Genehmiger anhand von Regeln zu ermitteln. Sie beziehen sich auf einen der zuvor beschriebenen vier Rule Types (BRFplus Rule, Function Module, ABAP Class oder BRF Flat Rule). Die GRC API Rules können im Standard genutzt oder den Anforderungen entsprechend angepasst werden.

Schritt 4: Variables & Templates

Templates dienen als Grundlage für die E-Mails, die innerhalb der Workflows an die jeweiligen Genehmiger (z.B. Manager, Role Owner) versendet werden (siehe Abbildung 2.9). Sie bestehen wiederum aus Bausteinen, den sogenannten Variables, die im späteren Verlauf beim Versand der entsprechenden E-Mail aufgelöst werden (siehe Abbildung 2.10).

Abbildung 2.9: E-Mail-Templates

Abbildung 2.10: E-Mail-Variables

Schritt 5: Maintain Paths

Dieser Schritt ist im Kontext der MSMP-Workflow-Konfiguration als wahrscheinlich wichtigster anzusehen. Hier werden den Genehmigungspfaden die entsprechenden Genehmigungsstufen (z.B. Manager, Role Owner) zugewiesen, d.h. im Klartext: die im dritten Schritt als Maintain Agents hinterlegten verantwortlichen Genehmiger.

Nicht nur das Mapping zwischen Genehmigungspfad und -stufe wird an dieser Stelle der Workflow-Konfiguration durchgeführt; ebenso können spezielle Eskalationspfade eingebaut und Routing Rules hinterlegt werden, oder man kann den Schalter für die Risikoanalyse in den einzelnen Stufen individuell setzen.

Schritt 6: Maint Route Mapping

Das Maint Route Mapping dient zur Verlinkung der MSMP-Prozess-IDs mit den jeweilig definierten Pfaden.

Schritt 7: Generate Versions

Vor der eigentlichen Generierung des MSMP-Workflows ist es empfehlenswert, eine Simulation des Workflows durchzuführen und so zu prüfen, ob dieser ggf. noch Fehler enthält.

Erst mit der erfolgreichen Generierung der Workflows können Benutzer- und Rollenanträge in den Systemen durchlaufen werden

Mit Abschluss der technischen Grundlagen im Kontext der MSMP-Workflows widmen wir uns nun den SAP-Standardworkflows.

2.1.3 Einführung SAP-Standardworkflows

Wie bereits dargestellt, werden die SAP-Standardworkflows durch die MSMP-Prozess-IDs zur Verfügung gestellt, welche die einzelnen Workflows beinhalten.

An dieser Stelle soll im ersten Schritt genauer auf die MSMP-Prozess-ID SAP_GRAC_ACCESS_REQUEST eingegangen werden. Diese umfasst zentrale Standardworkflows, die in jedem Workflowszenario von Bedeutung sind.

Dazu gehört beispielweise der Workflow New Account, der SAP-seitig als dreistufiger Genehmigungsprozess (Manager, Role Owner und Security) ausgeliefert wird. Dieser dient zur Anlage von Benutzern und Zuordnung der entsprechenden Berechtigungen in Systemen. Der Manager entscheidet durch seine Genehmigung oder Ablehnung, ob für den Mitarbeiter ein Benutzerstammsatz im System angelegt werden darf. Bei Ablehnung des Antrags durch den Manager endet der Workflow umgehend und muss bei Bedarf seitens des Mitarbeiters durch Neubeantragung abermals gestartet werden. Mit der Genehmigung des Antrags durch den Manager durchläuft der Prozess die beiden nachfolgenden Stufen (»Role Owner« und »Security«), bis es schließlich zur Zuteilung der Berechtigungen kommt. Der dritten Genehmigungsstufe »Security« kann eine aktive oder auch passive Rolle im Prozess zugedacht werden. Das bedeutet, sie fungiert lediglich als Kontrollorgan – oder der Ausführende kann den Antrag noch aktiv verändern und Berechtigungen ablehnen.

Neben der Neuanlage zählt auch die Änderung von Benutzern zu den wichtigsten Prozessen. Dafür liefert die SAP den Standard des Change Account aus. Dieser dient der Anpassung von Benutzer-Berechtigungen im System und kann auf zwei Arten erfolgen:

1. Zuordnung neuer Berechtigungen,

2. Entzug von Berechtigungen.

Im Gegensatz zum vorher beschriebenen New Account, besteht der Change-Account-Workflow lediglich aus einer Genehmigungsstufe: dem »Role Owner«. Nicht die Notwendigkeit des Benutzers, sondern lediglich dessen Berechtigungen stehen hier zur Diskussion.

Neben diesen beiden Workflow-Varianten, welche vorwiegend für die Steuerung des Account- und Access-Managements verantwortlich sind, liefert die SAP weitere Standards aus, auf die an dieser Stelle noch kurz eingegangen werden soll.

Dazu gehört zum einen der sogenannte Emergency User Access, der die workflowgesteuerte Zuordnung von Firefightern zu Dialogbenutzern unterstützt. Standardmäßig ist hier als verantwortlicher Genehmiger der sogenannte Firefighter Owner hinterlegt, der das Mapping des Dialog-Benutzers auf den Firefighter-Benutzer abzusegnen hat. Der Firefighter Owner ist im Allgemeinen die für einen bestimmten Firefighter verantwortliche Person. Diese Verantwortung erstreckt sich vom Design (beispielsweise Namenskonvention) bis zur inhaltlichen Ausprägung des Firefighters hinsichtlich der durch den Firefighter genutzten Berechtigungen. Somit lässt sich festhalten, dass der Firefighter Owner bei missbräuchlichem Gebrauch des Firefighters genauso zur Verantwortung gezogen werden kann wie der Anwender, der den Firefighter tatsächlich genutzt hat.

Die drei beschriebenen Workflows gehören zu den im Kontext der MSMP-Prozess-ID am häufigsten eingesetzten Workflow-Szenarien.

Wir setzen unsere Ausführungen bezüglich der Standard-Workflows mit den MSMP-Prozess-IDs SAP_GRAC_RISK_APPR und SAP_GRAC_FUNC_APPR fort. Hinter diesen beiden genannten IDs verbirgt sich die Pflege der SoD-Matrix. Die Matrix ist im Kontext interner und externer Auditanforderungen ständigen Änderungen unterworfen. Die Workflows ermöglichen es, Risiken und Funktionen zu pflegen, welche die Grundlage der SoD-Matrix bilden, und die Änderungen lückenlos für das Audit zu dokumentieren. Jedem Risiko und jeder Funktion muss eine Person zugewiesen sein, die die Verantwortung wahrnimmt und auch prozessual in der Lage ist, Inhalte der Risiken und Funktionen valide zu beurteilen.

Die kurz gezeigten, von der SAP als Standard ausgelieferten Workflows können aus unserer Sicht lediglich als Grundlage dienen. Möchte ich die Genehmigungspfade individuell, an meiner Organisation ausgerichtet implementieren, reichen sie aber oftmals nicht aus. Nach unseren Erfahrungen aus vielen Kundenprojekten sind die Anforderungen weit umfangreicher als das, was die ausgelieferten Prozesse ermöglichen. Auf Beispiele von Kundenanforderungen, die an uns in den letzten Jahren herangetragen wurden, werden wir im Verlauf der Ausführungen noch näher eingehen. Eines sei allerdings vorweggesagt: Um individuelle Kundenwünsche zu erfüllen, reicht MSMP alleine nicht aus. Hier muss auf das zweite Workflowinstrument, das BRF+, verwiesen werden, in das wir Ihnen im Folgenden einen kurzen Einblick geben.

Technische Grundlagen zum BRF+

Aufgrund der Komplexität und des großen Funktionsumfangs werden wir im Rahmen dieses Buches BRF+ lediglich im Kontext von AC und der für GRC relevanten Workflowszenarien beleuchten.

Als erster Schritt bei der Einrichtung des Business Rule Frameworks (kurz BRF) muss eine sogenannte Rule angelegt werden. Dieser Punkt lässt sich unter dem folgenden Pfad finden: SPRO • IMG • Governance, Risk and Compliance • Access Control • Workflows for Access Control • Define Workflow-Related MSMP Rules.

Bei Anlage der Rule müssen Rule Kind sowie Rule ID mitgegeben werden, siehe Abschnitt 2.1.2.

Die definierte Rule stellt die Grundlage für die individuelle Einrichtung der BRF-Applikation dar. Der Aufruf der BRF+-Anwendung erfolgt über die Transaktion BRF+ (siehe Abbildung 2.11).

Abbildung 2.11: Definition MSMP Rule

2.1.4 Unternehmensspezifische Workflows

An dieser Stelle möchten wir zwei unternehmensspezifische Workflows näher betrachten, die wir im Rahmen der gemeinsamen Nutzung von MSMP und BRF+ in den letzten Jahren vermehrt implementiert haben.

Abbildung 2.12: BRF+-Loop

Die beiden vorgestellten Workflows sind nur Beispiele für die Vielfalt der umsetzbaren Szenarien, wenn die beiden »Werkzeuge« (MSMP und BRF+) sinnvoll eingesetzt werden.