19,99 €
Mehr erfahren.
- Herausgeber: Espresso Tutorials
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Deutsch
- Veröffentlichungsjahr: 2019
Dieser Praxisleitfaden hilft Ihnen, Beantragungs- und Änderungsprozesse von Benutzer-Zugriffsberechtigungen mit SAP GRC Access Control revisionssicher zu organisieren. Unabdingbare Basis dafür ist das Wissen um bestehende Risiken, deren Auswirkungen und die Wahl der passenden Reaktion. Fachliches und technisches Herzstück ist der Risikokatalog, dessen Struktur und Verständlichkeit maßgeblich für eine effiziente Nutzung der Risikoanalyse ist.
Die Autorin vermittelt Ihnen ein tieferes Verständnis für das Ineinandergreifen der verschiedenen Funktionselemente von SAP GRC Access Control. Sie beschreibt die diversen Analyseoptionen wie die Ad-hoc-Analyse, Batchanalyse oder den Risk Terminator sowie deren korrekte Interpretation. Profitieren Sie von den praktischen Tipps aus dem Projektgeschäft sowie vom kreativen Umgang mit den technischen Möglichkeiten des Standards einer risikominimierten Vergabe von Zugriffsberechtigungen.
Das Buch unterstützt Sie, wenn Sie einen unternehmensindividuellen Risikokatalog erstellen oder anpassen, ein Projekt zur Risikobereinigung leiten oder coachen oder Sie verantwortlich sind für die regelmäßige Risikoanalyse und Abarbeitung der Ergebnisse. Vorerfahrungen mit GRC Access Control und dem SAP-Berechtigungswesen sind erwünscht.
- Design und Ausprägung eines Risikokatalogs
- Wartung und Erweiterung des Regelwerks
- Risikoanalysen interpretieren
- Best-Practice-Ansätze zur Risikobereinigung
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 131
Ähnliche
Bianca Folkerts
Praxishandbuch für die Risikoanalyse mit SAP® GRC Access Control
Bianca FolkertsPraxishandbuch für die Risikoanalyse mit SAP® GRC Access Control
ISBN: 978-3-96012-569-3 (E-Pub)
Lektorat: Anja Achilles
Korrektorat:Stefan Marschner
Coverdesign:Philip Esch
Coverfoto: iStockphoto.com © elfart – Nr. 482954057
Satz & Layout:Johann-Christian Hanke
Alle Rechte vorbehalten
1. Auflage 2019
© Espresso Tutorials GmbH, Gleichen 2019
URL:www.espresso-tutorials.de
Das vorliegende Werk ist in allen seinen Teilen urheberrechtlich geschützt. Alle Rechte vorbehalten, insbesondere das Recht der Übersetzung, des Vortrags, der Reproduktion und der Vervielfältigung. Espresso Tutorials GmbH, Bahnhofstr. 2, 37130 Gleichen, Deutschland.
Ungeachtet der Sorgfalt, die auf die Erstellung von Text und Abbildungen verwendet wurde, können weder der Verlag noch Autoren oder Herausgeber für mögliche Fehler und deren Folgen eine juristische Verantwortung oder Haftung übernehmen.
Feedback:Wir freuen uns über Fragen und Anmerkungen jeglicher Art. Bitte senden Sie diese an: [email protected].
Inhaltsverzeichnis
Willkommen bei Espresso Tutorials!
Unser Ziel ist es, SAP-Wissen wie einen Espresso zu servieren: Auf das Wesentliche verdichtete Informationen anstelle langatmiger Kompendien – für ein effektives Lernen an konkreten Fallbeispielen. Viele unserer Bücher enthalten zusätzlich Videos, mit denen Sie Schritt für Schritt die vermittelten Inhalte nachvollziehen können. Besuchen Sie unseren YouTube-Kanal mit einer umfangreichen Auswahl frei zugänglicher Videos: https://www.youtube.com/user/EspressoTutorials.
Kennen Sie schon unser Forum? Hier erhalten Sie stets aktuelle Informationen zu Entwicklungen der SAP-Software, Hilfe zu Ihren Fragen und die Gelegenheit, mit anderen Anwendern zu diskutieren: http://www.fico-forum.de.
Eine Auswahl weiterer Bücher von Espresso Tutorials:
Bernd Klüppelberg:
Techniken im SAP-Berechtigungswesen
Maxim Chuprunov:
SAP GRC – Governance, Risk und Compliance im Dienste der Korruptions- und Betrugsbekämpfung
Christoph Kretner, Jascha Kanngießer:
Berechtigungen in SAP BW, HANA und BW/4HANA
Andreas Prieß:
SAP-Berechtigungen für Anwender und Einsteiger
Sebastian Mayer, Martin Metz:
Schnelleinstieg in SAP GRC – Access Control
Julian Harfmann, Sabrina Heim, Andreas Dietrich:
Compliant Identity Management mit SAP IdM und GRC AC
Vorwort
Es gibt viele hilfreiche Bücher über SAP GRC Access Control, etliche Blogs, Whitepapers, und die Dokumentationen der SAP sind mittlerweile inhaltlich auf einem guten Stand.
In diesen Schriften sind meist auch Kapitel über die Risikoanalyse – Access Risk Analysis oder Access Risk Management – zu finden. Dort liest man zum Beispiel: »Automatisierte Prüfung von Benutzerzugriffen«. Aber prüfen wogegen? »Gegen einen Risikokatalog« heißt es dann ganz schlicht. Oder gar »gegen die Risikomatrix«. Oder auch »gegen das Regelwerk«. Ausführlich beschrieben wird in aller Regel die Konfiguration der Workflows und Notfallbenutzer sowie der Auswertungen in diesen Bereichen. Erläutert werden zumeist auch die Elemente eines Risikokatalogs und wie man sie anlegt bzw. pflegt. Aber: Welche Zusammenhänge bestehen, wenn ein Design ggf. empfindliche Auswirkungen auf die Performance und/oder Benutzerfreundlichkeit hat, und wie man die Möglichkeiten des GRC Access Control kreativ nutzen kann, um es noch effektiver zu nutzen … – Fehlanzeige! Dies herauszufinden, bleibt dem geneigten Anwender meist selbst überlassen.
Im Auslieferungsumfang von GRC Access Control ist bereits ein relativ ausführlicher Risikokatalog enthalten. Dagegen kann man natürlich prüfen. Der Katalog ist inhaltlich recht gut, wurde von der SAP in den letzten Jahren immer wieder aktualisiert und funktioniert technisch einwandfrei. Fraglich ist jedoch, ob Anwender dieser Lösung mit den Analyseergebnissen zurechtkommen. Die Risiko- und Funktionsbeschreibungen sind oft recht gewöhnungsbedürftig und schwer verständlich – insbesondere in der deutschen Übersetzung. Fakt ist, dass im SAP-Standard-Risikokatalog einerseits natürlich die kundeneigenen Transaktionen und Risiken in Bezug auf eigene Anwendungen fehlen, andererseits von der SAP (hoffentlich!) einige Customizing-Einstellungen vorgenommen wurden, die bestimmte Risiken bereits technisch kompensieren sollen.
Die Erweiterung des bestehenden Risikokatalogs um kundenindividuelle Zugriffsrisiken oder gar die Erstellung neuer Kataloge stellt viele Kunden vor große Herausforderungen.
Außerdem stellt erfahrungsgemäß die korrekte Interpretation der Risikoanalysen eine hohe Hürde dar. So können z.B. fehlerhafte Selektionen bei der Ausführung der Analyse oder nicht korrekt gesetzte Filter eine Analyse im Ergebnis völlig unverständlich machen oder zumindest zu wenig zielführenden Schlussfolgerungen führen.
Die Effizienz einer Risikoanalyse inkl. Validität der entsprechenden Reaktionen steht und fällt zudem mit der Passgenauigkeit und Verständlichkeit des Risikokatalogs. Und daran hängt schlussendlich zu einem ganz erheblichen Teil die Akzeptanz eines implementierten GRC Access Control.
Wie kommt man zu einem passenden Risikokatalog? Wie bleibt dieser stets auf dem aktuellen Stand? Und wie wird überhaupt das Ergebnis einer Analyse richtig gelesen?
Und wann und wie führt man einen (neuen) Risikokatalog ein? Was ist die beste Reihenfolge bei der Aktivierung der Komponenten?
Das vorliegende Praxishandbuch möchte Antworten auf diese und weitere Fragen geben und helfen, die Möglichkeiten des GRC Access Controls zur Erhöhung der Zugriffssicherheit optimal einzusetzen. Es richtet sich an Mitarbeiter, die
einen unternehmensindividuellen Risikokatalog erstellen oder anpassen,
ein Projekt zur Risikobereinigung leiten oder coachen,
verantwortlich sind für die regelmäßige Risikoanalyse und die Abarbeitung der Ergebnisse.
Dieses Handbuch ist kein Leitfaden für das Customizing von GRC Access Control. Es will vielmehr ein tieferes Verständnis für die Zusammenhänge zwischen den verschiedenen Elementen und deren Einsatzmöglichkeiten vermitteln. Daher kann es gelegentlich sein, dass die Kapitel zu den einzelnen Schritten im GRC Access Control nicht in der Reihenfolge stehen, in der die dazugehörigen Einstellungen im System vorzunehmen sind.
Ich gehe davon aus, dass der Leser dieses Handbuches bereits Erfahrung mit GRC Access Control und dem SAP-Berechtigungswesen hat. Insbesondere die Kenntnisse der Elemente und Strukturen des Berechtigungskonzeptes bilden die Grundlage zum Umgang mit dem Risikokatalog und der Analyse. Zudem verzichte ich auf die Erläuterung der generellen Notwendigkeit von Berechtigungskonzepten, des Zugriffsmanagements und der Risikoanalyse sowie rechtlicher Hintergründe.
Soweit möglich, habe ich Pfade zu den verschiedenen Einstellungen und Funktionalitäten angegeben. Da jedoch die Darstellung der NWBC-Oberfläche kundenindividuell über die Launchpads definiert ist, kann es sein, dass die Angaben nicht auf jedes System passen. Die Screenshots stammen überwiegend aus einem GRC Version 11 SP16.
Leser aus den Fachbereichen mögen mir zudem verzeihen, dass ich versucht habe, Beispiele und Erläuterungen aus einem Fachgebiet möglichst auch für »die andere Seite«, sprich die Basis, verständlich zu formulieren. Das mag an der einen oder anderen Stelle etwas oberflächlich oder sehr stark vereinfacht erscheinen. Die für das hier behandelte Thema relevanten Aussagen sollten jedoch erfasst sein.
Danksagung
Eine lange und intensive Beschäftigung mit dem Thema »Risikoanalyse« in vielen Projekten von unterschiedlichstem Umfang, mit Menschen jeglicher Ausprägungen von Zu- oder Abneigung für oder gegen das Thema und viele »Aha«-Erlebnisse waren nötig, um dieses Buch zu schreiben. Danke daher an alle Kunden, Kollegen und befreundeten Berater, mit denen ich in dieser Zeit zusammenarbeiten durfte und hoffentlich weiterhin darf. Aus jeder einzelnen Diskussion und insbesondere aus den kontroversen Auseinandersetzungen habe ich viel gelernt.
Ein besonderer Dank geht an meinen langjährigen Kollegen Tobias Sieg, der sich die Mühe gemacht hat, das Skript zu diesem Buch zu lesen und mit hilfreichen Anmerkungen beizutragen.
Im Text verwenden wir Kästen, um wichtige Informationen besonders hervorzuheben. Jeder Kasten ist zusätzlich mit einem Piktogramm versehen, das diesen genauer klassifiziert:
Hinweis
Hinweise bieten praktische Tipps zum Umgang mit dem jeweiligen Thema.
Beispiel
Beispiele dienen dazu, ein Thema besser zu illustrieren.
Achtung
Warnungen weisen auf mögliche Fehlerquellen oder Stolpersteine im Zusammenhang mit einem Thema hin.
Die Form der Anrede
Um den Lesefluss nicht zu beeinträchtigen, wird im vorliegenden Buch bei personenbezogenen Substantiven und Pronomen zwar nur die gewohnte männliche Sprachform verwendet, stets aber die weibliche Form gleichermaßen mitgemeint.
Hinweis zum Urheberrecht
Sämtliche in diesem Buch abgedruckten Screenshots unterliegen dem Copyright der SAP SE. Alle Rechte an den Screenshots hält die SAP SE. Der Einfachheit halber haben wir im Rest des Buches darauf verzichtet, dies unter jedem Screenshot gesondert auszuweisen.
1 Risikokatalog
Der Risikokatalog stellt das fachliche und technische Herzstück von SAP GRC Access Control dar. In ihm werden die Zugriffsrisiken zu einem System technisch (»Welche Berechtigungsobjekte und Werte definieren ein Risiko?«) und fachlich (»Worin besteht das Risiko; was passiert ggf., wenn es eintritt?«) definiert. Eingebunden in den Änderungsworkflow für Benutzer und Rollen sowie im Risikoterminator kommt fast jeder Anwender des GRC Access Control mit dem Risikokatalog in Berührung. Seine Struktur und Verständlichkeit für jeden damit befassten Anwender sind maßgeblich für eine effiziente Nutzung der Risikoanalyse.
Gleich vorweg: Ich nutze bewusst den Begriff Risikokatalog und nicht Risikomatrix. Das mag viele Anwender von GRC Access Control zunächst verwirren. Den Begriff Risikomatrix (oder nur Matrix) halte ich jedoch für irreführend und nur für einen Teil der Risiken korrekt. Eine Matrix bildet immer die Kombination von mindestens zwei Themen (in diesem Fall von Transaktionen) ab. Ein Risikokatalog enthält dagegen in aller Regel nicht nur Risiken aufgrund von Transaktionskombinationen. Oft sind auch einzelne Transaktionen oder gar Ausprägungen von Berechtigungsobjekten bereits ein Risiko. Die korrekte Verwendung der Begrifflichkeiten bildet die Basis einer erfolgreichen Zusammenarbeit im Projekt, da sie ein einheitliches Verständnis der Sachverhalte gewährleistet. Mehr zu diesem Thema lesen Sie in Abschnitt 1.2.
Natürlich können in GRC Access Control auch Fiori-Apps und andere (Non-SAP-)Risiken definiert werden. Für die S/4HANA-on-premise-Systeme bietet SAP sogar ein BC-Set zum Import des Standard-Regelwerkes an. Ich beschränke mich jedoch im Weiteren auf die altbekannten ABAP-Berechtigungen, um die Komplexität des Themas nicht noch weiter zu erhöhen.
In aller Regel wird der Risikokatalog durch einen Berechtigungs-Administrator in der IT angelegt und gepflegt. Er ist damit aber nicht allein verantwortlich; seine Aufgabe ist in erster Linie, stets eine Verbindung zwischen Technik und Business im Access Risk Analysis zu gewährleisten. Daher sollten beim Design und der Ausprägung unbedingt Mitarbeiter der jeweiligen Fachbereiche einbezogen werden. Wie hierbei effizient vorgegangen werden kann, wird in Kapitel 2 ausführlich beschrieben. Außerdem sollte auch hier auf eine Funktionstrennung bzw. ein Vier-Augen-Prinzip bzgl. Rollenpflege und Risiko-Administration geachtet werden (siehe Abschnitt 2.3.2).
In diesem Kapitel gehe ich zunächst auf die einzelnen technischen Elemente des Risikokatalogs ein. Diese insbesondere im Zusammenhang sowie hinsichtlich ihrer Auswirkungen auf die spätere Risikoanalyse zu verstehen, ist für alle am Design beteiligten Personen grundlegend. Wie im Vorwort bereits erwähnt, gehe ich davon aus, dass der Leser grundsätzlich weiß, was ein Berechtigungsobjekt ist und wie eine Funktion oder ein Risiko angelegt wird bzw. was zu customizen ist, um Access Risk Analysis lauffähig zu machen. Darauf aufbauend werde ich Ihnen die Auswirkungen verschiedener Design-Elemente verdeutlichen. Dabei verweise ich explizit auf Punkte, die in der Konzeption mit spezieller Sorgfalt erledigt werden sollten.
Im Zuge dessen weiche ich teilweise und aus gutem Grund von der herkömmlichen Reihenfolge der Erläuterungen ab. Um das Regelwerk zu verstehen, ist das Wissen um die Zusammenhänge zwischen den verschiedenen Elementen essenziell. Daher erkläre ich als Erstes – abweichend vom üblichen Ansatz, zuerst das Regelwerk vorzustellen – die »Funktion« und komme erst dann über das Risiko hin zum Regelwerk und zu weiteren Stammdaten.
1.1 Die Funktion
Die Funktion ist das technische Kernstück eines Risikokatalogs. Fachlich ist sie am ehesten gleichzusetzen mit einem Geschäftsprozessschritt. Sie entspricht also einer einzelnen Funktionalität im SAP-System. Innerhalb einer Funktion werden alle möglichen Formen der Zugriffsgewährung auf bestimmte Aktivitäten im SAP-System hinterlegt.
Technisch beinhaltet die Funktion demnach neben diversen Attributen im Wesentlichen die Berechtigungen, die zur Durchführung des Geschäftsprozessschrittes oder der Funktionalität notwendig sind. Oft wird z.B. vergessen, dass ein Zugriff nicht nur über Transaktionen möglich ist, sondern auch über die dahinterstehenden Reports oder über eine direkte Tabellenpflege.
Beschreibungen erhöhen die Benutzerfreundlichkeit
Bei der Anlage von Funktionen sollte darauf geachtet werden, dass die späteren Anwender der Risikoanalyse – also die Fachbereiche und Auditoren – alle notwendigen Informationen in für sie verständlicher Sprache vorfinden. Legen Sie also sehr viel Wert auf die sorgfältige Ausprägung der Beschreibung. Erfahrungsgemäß ist es immer gut, jegliche Beschreibungen von den zuständigen Fachbereichen formulieren oder zumindest abnehmen zu lassen.
Das technische Design der Funktionen trägt außerdem maßgeblich zur späteren Performance der Analysen bei. Der Struktur der Konnektoren bzw. insbesondere Konnektorgruppen kommt daher eine besondere Bedeutung zu.
Design der Konnektorgruppen ist performancerelevant
Die Funktion sowie insbesondere die Struktur und Auswahl der Konnektoren und Konnektorgruppen bestimmen die Anzahl der generierten Regeln (siehe auch Abschnitt 1.2.2). Bei ungünstigem Design der Konnektorgruppen werden viele überflüssige Regeln generiert. Die Anzahl der Regeln hat maßgeblichen Einfluss auf die Performance zahlreicher Reports (Details hierzu siehe Abschnitt 1.1.4).
1.1.1 Der Funktionskopf
Der Kopf einer Funktion beinhaltet vier Attribute (siehe Abbildung 1.1):
Funktions-ID
,
Geschäftsprozess
,
Analyseumfang
und
Beschreibung
.
Diese Attribute dienen sowohl der Einteilung der Risikoanalyse nach verschiedenen Sichtweisen (z.B. Finanzwesen, Datenschutz, Basis, in einem System oder systemübergreifend) als auch der besseren Lesbarkeit der Analyseergebnisse.
Abbildung 1.1: Der Funktionskopf
Funktions-ID – Namenskonventionen sind Gold wert
Wie in allen Bereichen der IT tragen auch im GRC durchdachte Namenskonventionen erheblich zur Benutzerfreundlichkeit bei. Zudem werden über die Funktions-ID die Berechtigungen für den Zugriff (Anzeige, Pflege, Löschung etc.) im Berechtigungsobjekt GRAC_FUNC gesteuert.
Die IDs der von SAP ausgelieferten Funktionen sind vierstellig (ein Relikt aus Zeiten von GRC 5.3), das Feld ist technisch jedoch achtstellig (was für eine sprechende Namenskonvention noch immer recht kurz ist).
Aufgrund der Kürze des Feldes und der möglichen Anforderung, den Zugriff auf die Stammdaten der Funktionen zu steuern, empfehle ich bei der Definition einer Konvention die in Tabelle 1.1 dargestellte Struktur des Namens.
Tabelle 1.1: Namenskonvention für Funktionen und Risiken
Namenskonventionen in Shared-Service-Systemen
In GRC-Access-Control-Systemen, die als Shared-Service-Systeme genutzt werden, empfiehlt es sich, an Stelle 2–3 zunächst ein Kunden- oder Systemkürzel einzufügen, gefolgt von der Applikation (Stelle 4–5) und der laufenden Nummer (Stelle 6–8). Hat man z.B. einen Kunden K1 und einen Kunden K2, würde dies für die Funktion aus unserem Beispiel in Abbildung 1.1 wie folgt aussehen:
ZK1FI001 (für System K1), ZK2FI001 (für System K2).
Geschäftsprozess – Gruppierungsmerkmal
Das Attribut Geschäftsprozess wird sowohl in der Funktion als auch im Risiko (siehe Abschnitt 1.2) und in der Kontrolle (siehe Abschnitt 4.5.2) genutzt. Es dient jeweils zur besseren Gliederung und Gruppierung der Stammdaten. Außerdem kann über dieses Attribut eine logische Zuordnung zu einem verantwortlichen Bereich erfolgen. Einen technischen Zusammenhang zwischen den Geschäftsprozessen in den verschiedenen Stammdaten gibt es nicht.
Die gültigen Geschäftsprozesse müssen zunächst im Customizing des GRC Access Control definiert werden (siehe Abbildung 1.2). Diese sind dann für alle Stammdaten (Funktion, Risiko und Kontrolle) verwendbar.
Abbildung 1.2: Customizing der Geschäftsprozesse und -teilprozesse in der SPRO
Im Gegensatz zu den Attributen in Kontrollen kennt die Funktion (leider) keinen Geschäftsteilprozess. Wünschen Sie trotzdem eine Unterteilung der Applikationen, müssen Sie sich ein Namenskonzept überlegen (Vorschlag siehe Tabelle 1.2) und dokumentieren.
Die Geschäftsprozess-ID ist technisch 4-stellig.
Tabelle 1.2: Namenskonventionen Geschäftsprozesse
Namenskonventionen für Haupt- und Teilprozess
In der Funktion gibt es keine Teilprozesse. Eine Gliederung nach Haupt- und Teilprozess kann über eine entsprechende Namenskonvention (siehe Tabelle 1.2) abgebildet werden.
Umgesetzt für die Funktion aus unserem Beispiel in Abbildung 1.1 würde das wie folgt aussehen:
FIXX, also FI für das Hauptmodul Finanzbuchhaltung und XX für alle.Für eine Funktion »Stammdaten Kreditoren pflegen« wäre richtig:
FIAP, also FI für Finanzbuchhaltung und AP für Kreditorenbuchhaltung.Analyseumfang – single oder cross?
Als Analyseumfang
