Zwo, eins, kein Risiko: Vereinfachte Risikoprüfung mit SAP IdM

Das eigentliche SAP-Tool für die Risikoprüfung ist SAP Access Control. Aber auch SAP Identity Management (SAP IdM) eignet sich für diese Aufgabe – zumindest in vereinfachter Form. Von Haus aus kümmert sich SAP IdM um die Verwaltung von Berechtigungen und Identitäten sowie um deren Provisionierung. Die Software versorgt Anwender also mit allen erforderlichen Zugriffen und Konten für verschiedene Systeme. Im Vergleich dazu beschäftigt sich SAP Access Control mit anderen Funktionalitäten. Hier reicht das Spektrum von der Risikoprüfung über das Abbilden von Notfallprozessen bis hin zum Rollenmanagement.

Je nach Anforderungen auswählen

Festzuhalten bleibt: Bei SAP Identity Management und SAP Access Control handelt es sich um zwei unterschiedliche Tools, die verschiedene Funktionen erfüllen und separate Prozesse abbilden. Unternehmen sollten das für sie geeignete Tool anhand der jeweiligen Anforderungen sorgfältig auswählen. In vielen Fällen dürfte SAP IdM mit seinen grundlegenden Funktionen der Risikoprüfung ausreichend sein. Ein lukrativer Vorteil: Wenn Unternehmen SAP IdM ohnehin im Einsatz haben und die Software die Anforderungen hinsichtlich der Risikoprüfung abdeckt, sparen sich die Unternehmen die Anschaffung eines weiteren Tools und damit zusätzliche Lizenzkosten.

SoD-Prüfung in SAP IdM

Eine wichtige Aufgabe im Rahmen der Risikoprüfung ist die Funktionstrennung (Segregation of Duties = SoD) bei der Benutzerrechteverwaltung. Die Herausforderung besteht darin, die SoD-Matrix übersichtlich und benutzerfreundlich, aber gleichzeitig auch performant in der Verwendung zu gestalten. Die Benutzerfreundlichkeit wird erreicht, indem man ein spezielles Datenmodell definiert. Dieses ermöglicht eine bessere Übersicht im User Interface des SAP IdM-Standards und die Möglichkeit einer Massenverarbeitung der SoD-Matrix.

Die Risikoprüfung ist direkt in den Antragsworkflow integriert. Das heißt, die Berechtigungen werden beim Bestellvorgang gegen die SoD-Matrix geprüft. Außerdem ist es jederzeit möglich, Systemanalysen zu starten, um den aktuellen Stand der Benutzer und ihrer Berechtigungen im System gegen die definierte SoD-Matrix zu prüfen. Es lassen sich sowohl einzelne Identitäten als auch das Gesamtsystem, sprich: alle Identitäten, prüfen.

Theoretischer Aufbau

Um eine gute Usability und eine hohe Leistungsfähigkeit der SoD-Matrix zu realisieren, ist eine saubere Rollenhierarchie im Unternehmen und im SAP IdM-Tool die Voraussetzung. Es muss eine einfache Kombination von Berechtigungen oder Fachrollen geben, eine komplexe Verschachtelung darf nicht bestehen. Der theoretische Aufbau der vereinfachten Risikoprüfung sieht so aus: Rolle A in Kombination mit Rolle B ergibt ein bestimmtes Risikolevel. Dieses kann kritisch oder toxisch sein, sodass entweder zumindest Vorsicht bei der Genehmigung geboten ist oder aber die Kombination von Rollen in dieser Form nicht erlaubt ist. Je nach Risikolevel sind dann auch die Oberflächen im entsprechenden Workflow-Schritt für die Endanwender unterschiedlich gestaltet.

Angesichts des beschriebenen theoretischen Aufbaus bietet sich als Designidee eine flache Tabelle an. Um diese benutzerfreundlich administrieren zu können, ist ein eigener Entrytype (Objekt mit eigenen Attributen) im SAP Identity Management empfehlenswert. Weil die Attribute in der Datenbank nicht spalten-, sondern zeilenbasiert angezeigt werden, lassen sie sich flexibel erweitern (gekipptes Datenmodell). Zudem können administrative Oberflächen für die Verwaltung erstellt werden, um beispielsweise die SoD-Konfigurationsobjekte anzulegen, zu ändern oder zu löschen. Ein weiterer Vorteil ist, dass diese Objekte mit der REST API des IdM-Tools genutzt und in UI5-Lösungen integriert werden können. Allerdings macht das gekippte Datenmodell, bei dem jedes Attribut in einer eigenen Zeile dargestellt wird, die für die Risikoprüfung notwendigen SQL-Abfragen komplexer, wodurch die Laufzeiten länger sind.

Datenbank-Views und Standard-Oberflächen

Eine Möglichkeit, die Komplexität der SQL-Abfragen zu reduzieren, ist die Entwicklung einer Datenbank-View, welche die Daten in Echtzeit selektiert, oder – noch besser – einer Materialized-View, welche die Daten statisch anzeigt. Das Risikolevel lässt sich anhand einer Datenbank-View leichter abfragen. Dabei hat die Reihenfolge der Rollen eine wichtige Bedeutung, da die Prüfung bei falscher Reihenfolge nicht korrekt erfolgt. Ein Search-Pattern sorgt für die richtige Reihenfolge und die Kombination der Rollen in beide Richtungen. Wird ein solches Search-Pattern in das Datenmodell integriert, ist das Ergebnis eine finale Datenbank-View, die dieselbe Konfiguration in zwei Zeilen darstellt. Das kommt daher, dass nun eine Rollenkombination in beide Richtungen in der Datenbank-View angezeigt wird.

Wenn der Anwender nicht auf Datenbankebene arbeiten muss, sondern die administrativen Standard-Oberflächen nutzen kann, wirkt sich das positiv auf die Usability aus. Mit ihnen ist es möglich, die vorhandenen Konfigurationsobjekte anzuzeigen, zu ändern und zu löschen sowie neue Konfigurationsobjekte anzulegen. Dabei gilt es, die Pflichtfelder zu beachten sowie die passende Auswahl der Berechtigungen und Fachrollen vorzunehmen. Das Risikolevel lässt sich idealerweise als Drop-down-Menü auswählen. Die administrativen Oberflächen bieten eine einfache Möglichkeit, die Objekte zu managen, ohne dafür auf die Datenbanktabellen und die SQL-Statements zugreifen zu müssen. Somit ist die Pflege solcher Objekte einfacher und sicherer.

Ablauf einer Risikoprüfung

Die Risikoprüfung ist in den Workflow (Antrag auf Berechtigungen) integriert. Das Skript prüft die bestellte Kombination von Berechtigungen und die bestellten Berechtigungen gegen die bereits zugewiesenen Berechtigungen des Empfängers. Der Genehmiger erhält das Ergebnis der Prüfung und entscheidet, wie damit umzugehen ist. Während der Anwender ein kritisches SoD-Prüfungsergebnis genehmigen oder ablehnen kann, muss er ein toxisches Ergebnis zwingend ablehnen. Jedes Risikoergebnis wird mit einem eigenen Attribut am Antrag dokumentiert und im User Interface in der Historie dargestellt. Zusätzlich wird jedes Risikoergebnis in ein eigenes Attribut am Antrag geschrieben.