Warum eine Berechtigungsprüfung durchführen? Diese eine Schlüsselfrage verliert nie an Bedeutung: Wer hat Zugriff auf welche Daten in SAP?
SAP-Berechtigungsprüfungen helfen bei der Beantwortung einer wichtigen Frage: Inwieweit spiegeln die einem Benutzer im System zugewiesenen Rollen und Transaktionen seine tatsächlichen Verantwortlichkeiten wider? Dies ist keine leichte Aufgabe, da es in der Praxis oft schwierig ist, genau zu bestimmen, wofür ein Mitarbeiter wirklich zuständig ist, insbesondere da sich seine Rollen und Zuständigkeiten im Laufe der Zeit ändern.
Um den Einsatz neuer Mitarbeiter zu vereinfachen, kopieren Unternehmen oft die Berechtigungen eines anderen Benutzers. Diese Praxis beschleunigt zwar die Vergabe von Zugriffsrechten, führt aber auch zu einem Verlust der Kontrolle darüber, wer auf was Zugriff hat, insbesondere wenn die Berechtigungsstruktur im System komplex ist und Benutzern Dutzende oder sogar Hunderte von Rollen gleichzeitig zugewiesen werden. Mit der Zeit wird die Zugriffsstruktur unübersichtlich und schwer zu verwalten. An diesem Punkt entsteht die Notwendigkeit einer Privilegienüberprüfung, deren Zweck es ist, die oft falsch zugewiesenen Privilegien zu überprüfen.
Hier kommen die Wirtschaftsprüfer ins Spiel.
Fehlende Zugangskontrollen treten meist im Tagesgeschäft zutage – zum Beispiel, wenn ein Mitarbeiter ein Dokument an ein Unternehmen geschickt hat, dem er formal nicht zugewiesen ist, oder wenn er Waren ohne ordnungsgemäße Genehmigung zwischen Standorten verschoben hat. Solche Vorfälle werden zwar in der Regel schnell korrigiert, sind aber selten der Anstoß für tiefgreifende Veränderungen. Es herrscht der weit verbreitete Glaube, dass es besser ist, „zu viel als zu wenig“ Befugnisse zu haben, und die Notwendigkeit, Unterstützung zu gewähren, überwiegt oft das Prinzip der Minimierung des Zugriffs.
Finanzprüfer sehen das Thema jedoch anders – durch das Prisma des Prinzips der minimalen Privilegien, demzufolge Benutzer nur Zugang zu den Funktionen haben sollten, die sie für ihre Arbeit benötigen.
Aus Sicht der Finanzprüfung besteht das Ziel darin, zu bestätigen, dass die im ERP-System (z.B. SAP) generierten Daten zuverlässig sind und dass Unbefugten kein Zugang zu Funktionen gewährt wurde, die sich auf die finanzielle Leistung auswirken. Die Prüfer bewerten die Einhaltung des Prinzips der Aufgabentrennung (Segregation of Duties – SoD) und überprüfen den Zugang zu sensiblen Funktionen wie der Zahlungsabwicklung, der Bearbeitung von Lieferantenbankdaten oder der Änderung von Kunden- und Lieferantenstammdaten. Eine gut vorbereitete SoD-Matrix und eine Liste mit kritischen Zugriffsrechten bietet dem Unternehmen einen praktischen Ausgangspunkt für die Überprüfung und einen Rahmen für die Bewertung der aktuellen Rollen und Berechtigungen.
Eine gut vorbereitete SoD-Matrix und eine Liste mit kritischen Zugriffsrechten bietet einer Organisation einen praktischen Ausgangspunkt für die Überprüfung und einen Rahmen für die Bewertung der aktuellen Rollen und Berechtigungen. Anstatt die Frage zu stellen, welchen Zugriff ein Benutzer haben sollte (was eine Analyse der Verantwortlichkeiten, Aufgaben und Erfahrungen erfordert), ist es viel einfacher und schneller festzustellen, welchen Zugriff er nicht haben sollte – vor allem, wenn ein Prüfer eine vorgefertigte Liste von Risiken und sensiblen Aktivitäten zur Verfügung stellt oder wenn eine solche Best-Practice-Liste bereits in einem Zugriffsrisikomanagement-Tool (GRC-Klasse) verfügbar ist.
1. Die Prüfung von Ansprüchen bringt auch greifbare geschäftliche Vorteile:
- Besseres Verständnis von Prozessen und Zuständigkeiten – hilft zu klären, wer wofür verantwortlich ist und wo es möglicherweise „Grauzonen“ bei der Entscheidungsfindung gibt.
- Verbesserte operative Sicherheit – die Einschränkung von übermäßigem Zugriff ist eine der einfachsten und effektivsten Formen der Prävention.
- Vorbereitung auf Veränderungen – gut organisierte Berechtigungen machen Migrationen, Upgrades und den Übergang zu Cloud-Umgebungen viel einfacher.
- Geringeres Risiko von Fehlern und Missbrauch durch die Beseitigung von Rollenkonflikten und kritischen Zugriffskombinationen.
- Unterstützung für interne und externe Audits – transparente Berichte und eine klare Risikomatrix beschleunigen die Auditprozesse erheblich.
Es ist wichtig zu wissen, dass die meisten Unternehmen bei der Implementierung eines ERP-Systems keine Zeit haben, über das Berechtigungsmodell nachzudenken. Testen, Stammdaten, Zeitplanung und einfach nur die Inbetriebnahme des Systems sind in der Regel die wichtigsten Dinge. Die Zugriffsrechte werden oft in letzter Minute festgelegt – in der Regel durch Kopieren von Benutzern oder Rollen – ohne die tatsächlichen Bedürfnisse und Risiken zu analysieren. Das Ergebnis ist, dass das System zwar aus der Sicht der Prozesse gut funktioniert, aber zu viele Sicherheits- und Kontrolllücken aufweist.
Es lohnt sich daher, nach der Stabilisierung eine Prüfung der Berechtigungen durchzuführen, um den Zugang zu strukturieren und die Sicherheit und Compliance des Unternehmens zu verbessern.
Wie Sie eine SAP-Zugriffsprüfung in der Praxis durchführen.
Jetzt, wo wir verstehen, warum Zugangsprüfung wichtig ist und welche Vorteile sie bringt, ist die logische Frage: Wie führen wir sie in der Praxis durch? Unternehmen haben mehrere Möglichkeiten – von der manuellen Analyse von SAP-Tabellen bis zur Verwendung verschiedener Tools zur Unterstützung der SoD-Risikobewertung. Die Wahl hängt von verschiedenen Faktoren ab, wie z.B.:
- die Anzahl der Benutzer und die Komplexität der IT-Umgebung (z.B. ob sie hauptsächlich SAP-basiert ist oder domänenspezifische Systeme umfasst), ist eine manuelle Prüfung von mehr als 100 Benutzern fast unmöglich, vollständig und genau durchzuführen
- Ressourcen und Kompetenz des internen Teams, werden technische Spezialisten mit SUIM in SAP beginnen und Ergebnisse weitergeben, die für die Geschäftsteams schwer zu verstehen sind
- Druck und Erwartungen interner oder externer Prüfer in Bezug auf SoD und Zugriffskontrollen auf sensible Daten,
- und ob es sich bei der Prüfung um eine einmalige Überprüfung oder eine zyklische Aktivität handelt.
Viele Unternehmen beginnen damit, SUIM-Berichte herunterzuladen, Daten aus Tabellen zu exportieren und manuell in Excel zu analysieren. Nachdem sie Wochen damit verbracht haben, die rohen Systemdaten abzugleichen, wenden sie sich oft an externe Wirtschaftsprüfer, um sich beraten zu lassen – nur um dann festzustellen, dass ihr Ansatz von Anfang an falsch war. Wirtschaftsprüfungsgesellschaften, insbesondere die Big Four, bieten nicht nur ausgefeilte Tools (wie ACE von PwC), sondern auch strukturierte Methoden, die sich auf Risiken, den geschäftlichen Kontext und Wiederholbarkeit konzentrieren. Sie beschränken sich jedoch nicht auf die Identifizierung von Risiken. Sobald ein Konflikt bei der Aufgabentrennung aufgedeckt wird, gehen die Prüfer tiefer und fragen, ob der Zugriff genutzt wurde, ob Risiken eingetreten sind und welche Daten geändert oder beeinflusst wurden. Der Nachweis, dass der umfassende Zugriff auf kritische Ressourcen nicht missbraucht wurde, kann eine zeit- und ressourcenintensive Aufgabe sein, insbesondere wenn es kein System zur Verfolgung der Nutzung oder einen kontextbezogenen Prüfpfad gibt. Daher liegt die wahre Stärke nicht nur im Tool, sondern in der Kombination der richtigen Technologie mit der richtigen Methodik, die mit den Risiken und den geschäftlichen Anforderungen beginnt und nicht mit rohen Transaktionen oder Listen kritischer Zugriffstransaktionen.
Viele IT-Fachleute glauben, dass die Implementierung eines GRC-Tools automatisch ihre Probleme bei der Zugriffsverwaltung lösen wird. Dies ist jedoch eine klassische Falle: Wenn das Problem nicht klar definiert ist, wird das Tool es auch nicht lösen. Die eigentliche Frage lautet oft nicht „Fehlt uns ein GRC-Tool?“, sondern vielmehr: „Verstehen wir wirklich, wer Zugriff auf was hat und warum?“. Ohne diese Klarheit wird auch die beste Lösung keine aussagekräftigen Ergebnisse liefern. Eine bekannte Lösung in diesem Bereich ist SAP GRC Access Control 12.0 (für On-Premises-Umgebungen). SAP bietet auch eine Cloud-basierte Version – SAP IAG – an, die sowohl On-Premise (über SAP Connector) als auch Cloud-native Systeme (z.B. SuccessFactors) unterstützt.
GRC Hack #2
Die Vor-Ort-Implementierung von SAP GRC Access Control dauert in der Regel zwischen drei und sechs Monaten. Wenn die Zeit drängt, kann eine Cloud-basierte Version von IAG eine schnellere Implementierung ermöglichen – oder Sie können alternative SaaS-Lösungen in Betracht ziehen.
Tatsächlich werden alternative Zugangskontrolllösungen immer beliebter – insbesondere solche, die sich auf Flexibilität, Integration mit Nicht-SAP-Systemen, schnellere Bereitstellung und vereinfachte Wartung konzentrieren. Ein Beispiel dafür ist smartGRC , das sowohl als On-Premise- als auch als Cloud-Modell erhältlich ist und erste Ergebnisse in nur 1 Monat liefern kann.
Ist ein einmaliger Audit-Service eine Alternative zum GRC-System?
Das Management stellt oft die Frage:„Brauche ich wirklich ein komplettes GRC-System, um zu verstehen, wer Zugriff auf was hat?“
Es gibt zwei Hauptansätze:
- Einmalige Prüfung durch ein externes Unternehmen – schnell, kostengünstig und nützlich, um sich ein aktuelles Bild zu verschaffen (z.B. vor einer Finanzprüfung).
- Die Implementierung eines GRC-Systems – die ideale Lösung für Unternehmen, die eine kontinuierliche Kontrolle, Unabhängigkeit und Skalierbarkeit benötigen.
GRC Hack #3
Eine einmalige Prüfung ist nur eine Momentaufnahme. In dynamischen SAP-Umgebungen ändern sich die Zugriffsrisiken ständig. Ohne kontinuierliche Überwachung werden wiederholte Audits notwendig.
Wenn keine häufigen Audits erforderlich sind, kann Outsourcing immer noch die beste Option sein. Für Unternehmen, die die Flexibilität schlanker GRC-Lösungen suchen, bieten sie jedoch einen kosteneffizienten Kompromiss – vor allem, wenn der Prüfungsumfang auch Nicht-SAP-Systeme umfasst, die in der Regel mehr Zeit für die Vorbereitung und Überprüfung der Aufgabentrennung benötigen.
Aktionsplan – Durchführung einer SAP-Anspruchsprüfung – wo soll man anfangen?
Eine SAP-Berechtigungsprüfung mit der Identifizierung von Transaktionscodes (t-codes) zu beginnen, ist ein häufiger Fehler, insbesondere bei technischen Teams. Bei diesem Ansatz wird ein entscheidender erster Schritt verpasst: das Verständnis der Geschäftsprozesse, Rollen und Risiken, die die Zugriffsanforderungen bestimmen. Ohne diesen Kontext ist die T-Code-Analyse so, als würde man eine Stadt nur anhand von Laternenpfählen kartieren – sie ist zwar technisch korrekt, aber strategisch blind.
GRC Hack #4
Beginnen Sie nicht mit T-Codes! Beginnen Sie mit Geschäftsprozessen und Risikobereichen – und ordnen Sie diese erst dann den Transaktionen zu. Wenn Sie direkt zu den technischen Fragen übergehen, verlieren Sie das Gesamtbild aus den Augen.
2. Entwicklung einer Matrix zur Aufgabentrennung (SoD) und einer Liste sensibler Zugriffe
Dies ist die Grundlage für jede Überprüfung der Zugriffskontrolle. In dieser Phase identifiziert die Organisation die Geschäftsprozesse, die potenziellen Verstößen ausgesetzt sind, und stellt Konflikte bei der Aufgabentrennung fest – z.B. die Buchung einer Journalbuchung und die Genehmigung einer Zahlung. Das Projektteam identifiziert zusammen mit den Geschäftsbereichsverantwortlichen eine Liste von so genannten Geschäftsaktivitäten, die innerhalb desselben Prozesses auftreten können. Jedem Risiko wird eine Wichtigkeitsstufe zugewiesen – z.B. niedrig, mittel, hoch. Jedes GRC-Tool bietet diese Funktionalität, aber es lohnt sich, ein paar Nuancen zu beachten.
GRC Hack #5
Die größte Herausforderung bei der Erstellung einer SoD-Matrix besteht darin, im gesamten Unternehmen ein gemeinsames Verständnis der Risikodefinition zu gewährleisten. Ohne dies hat die Diskussion keinen wirklichen Wert. Es gibt bereits Lösungen auf dem Markt, wie z.B. smartGRC, die die Integration von künstlicher Intelligenz ermöglichen, die Benutzer unterstützen, indem sie risikoreiche Kombinationen von Aktionen vorschlagen, Beispiele für das Eintreten von Risiken zeigen und auf spezifische SAP-Transaktionen oder Fiori-Anwendungen verweisen. Dies reduziert die Workshop-Zeit und verbessert die Qualität der Matrix.
2. technische Abbildung der SoD-Matrix
Sobald die SoD-Risikomatrix und die Liste der sensiblen Zugriffe fertiggestellt und mit dem Unternehmen abgestimmt sind, besteht der nächste Schritt darin, sie technisch im GRC-System abzubilden. Dies ist der Punkt, an dem Risiken auf Prozessebene in tatsächliche Berechtigungen in IT-Systemen – meist in SAP – umgesetzt werden.
In diesem Stadium wird jede Geschäftsaktivität einem bestimmten Satz von SAP-Transaktionen, Fiori-Anwendungen oder anderen technischen Elementen (z.B. Programme, Berichte, Funktionen) zugeordnet. Anschließend werden Beziehungen zwischen Transaktionen und Berechtigungsobjekten hergestellt – Elemente des SAP-Systems, die den Umfang des Benutzerzugriffs steuern.
Für jedes Paar von Geschäftsaktivitäten werden Konfliktbedingungen definiert – z.B. ob ein Benutzer Zugriff hat, um ein Dokument sowohl zu erstellen als auch zu genehmigen. Das Ergebnis ist ein komplettes Regelwerk mit zugeordneten technischen Definitionen von Aktivitäten und Konfliktregeln.
GRC Hack #6
In diesem Stadium ist es sinnvoll, ein Tool zu verwenden, mit dem Sie Systeme jenseits von SAP S/4HANA einfach abbilden können. SmartGRC (smartgrc.eu) ermöglicht beispielsweise die Erstellung von technischen Definitionen im XML-Format unter Verwendung einer zusammengesetzten und atomaren Struktur, mit der jedes beliebige Berechtigungskonzept modelliert werden kann. Das System prüft automatisch die Korrektheit des Imports und weist auf Probleme wie fehlende Atome in zusammengesetzten Rollen oder Atome, die nicht existierenden Benutzern zugewiesen sind, hin. Dies beschleunigt nicht nur die Implementierung, sondern trägt auch dazu bei, die Qualität des Berechtigungskonzepts im Ausgangssystem zu verbessern.
3. Bericht über die Eröffnungsbilanz.
Dies ist die Phase, in der das System die tatsächlichen Benutzerrechte analysiert und feststellt, wo SoD-Risiken und sensible Zugriffe auftreten. Die Berichte berücksichtigen organisatorische Ebenen – zum Beispiel, ob Konflikte innerhalb desselben Buchungskreises auftreten.
Je nach Tool kann ein Bericht Tausende von Einträgen enthalten, so dass Transparenz, Filterung und Aggregation der Ergebnisse entscheidend sind. Fortschrittlichere Lösungen bieten auch Trendanalysen über einen längeren Zeitraum, so dass Unternehmen beurteilen können, ob sich die Situation verbessert oder verschlechtert. Die Daten werden in der Regel in intuitiven Dashboards dargestellt.
GRC Hack #7
Es ist wertvoll, wenn der Bericht die tatsächliche Nutzung risikobezogener Fiori-Transaktionen und -Anwendungen zeigt – dies hilft festzustellen, ob das Risiko nur theoretisch oder aktiv ist, d.h. vom Benutzer im Tagesgeschäft genutzt wird.
GRC Hack #8
Noch besser ist es, wenn der Bericht nicht nur eine „statische Liste“ ist, sondern eine interaktive Aufgabenliste, die Aktionen wie die Zuweisung von Objekten an Geschäftsverantwortliche, das Hinzufügen von Abhilfemaßnahmen oder die Weiterleitung zur Genehmigung oder Aufhebung des Zugriffs ermöglicht.
4. Entwickeln Sie einen Wiederherstellungsplan.
Dies ist die Phase, in der auf der Grundlage des Berichts konkrete Entscheidungen getroffen werden. Das Sicherheitsteam oder die Prozessverantwortlichen bestimmen:
- welche Ansprüche gestrichen werden sollten,
- welche Aktivitäten blockiert oder umorganisiert werden sollten
- und welche Änderungen an den Benutzerrollen vorgenommen werden müssen.
Auf dieser Grundlage wird eine technische Spezifikation für Systemadministratoren erstellt – einschließlich einer Liste von Transaktionen, Rollen und Benutzern, die aktualisiert werden müssen. Je nach Tool können die Empfehlungen in großen Mengen erstellt werden oder eine individuelle Analyse erfordern.
GRC Hack #9
Dies ist eine kritische Phase des gesamten Projekts – es lohnt sich, im Vorfeld ausreichend Zeit und Ressourcen zu investieren. Bevor Sie einzelnen Benutzern den Zugriff entziehen, ist es besser, zunächst die Rollen und das gesamte Berechtigungsmodell zu verfeinern – dadurch werden die Änderungen dauerhafter, logischer und in Zukunft leichter zu pflegen.
5. aktuelle Risiken überwachen.
Eine Zugangsprüfung endet nicht mit einer einmaligen Analyse – die Risiken sollten kontinuierlich überwacht werden. Sobald Änderungen implementiert wurden, ist es wichtig, dass:
- überprüfen Sie regelmäßig neue Berechtigungen und Rollenänderungen,
- neue Konflikte und Nutzeraktivitäten in sensiblen Bereichen erkennen,
- und analysieren Sie Trends – nimmt die Zahl der Risiken zu, nimmt sie ab oder bleibt sie konstant?
Fortschrittlichere Tools ermöglichen die Planung wiederkehrender Analysen, die Automatisierung der Berichterstattung und automatische Benachrichtigungen an die Prozessverantwortlichen.
Dies ist auch die Phase, in der die Implementierung eines GRC-Tools den größten Return on Investment bietet – es ermöglicht eine kontinuierliche Überwachung ohne die Notwendigkeit wiederholter manueller Audits, was Zeit und Ressourcen spart.
GRC Hack #10
Der größte Nutzen ergibt sich aus der kontinuierlichen Überwachung – statt einmal im Jahr Audits durchzuführen, ist es viel effektiver, Risiken vierteljährlich oder monatlich zu überwachen. Das GRC-System ermöglicht es, wiederkehrende Analysen zu planen und Risiken im Laufe der Zeit zu visualisieren, um zu beurteilen, ob die Korrekturmaßnahmen tatsächlich greifen.
Eine SAP-Berechtigungsprüfung ist ein wichtiger Schritt zur Gewährleistung der Compliance, Sicherheit und Integrität von Finanzdaten. Unabhängig davon, ob Sie Wirtschaftsprüfer, Prozessverantwortlicher oder IT-Spezialist sind, erhalten Sie durch das Durchlaufen der fünf Schlüsselphasen der Prüfung ein klares Bild von der Zugriffsstruktur Ihres Unternehmens:
- Definition der SoD-Matrix und der sensiblen Zugriffsliste
- Abbildung auf das System (technische Abbildung)
- Ausführung des Berichts über die Eröffnungsbilanz
- Formulierung konkreter Empfehlungen
- Risiken im Laufe der Zeit überwachen
GRC-Tools ermöglichen es Unternehmen, Audits schneller, kostengünstiger und effizienter durchzuführen und gleichzeitig hohe Kontroll- und Compliance-Standards einzuhalten. Sie müssen nicht auf ein bestimmtes Tool festgelegt sein. Es gibt Alternativen, die Sie in Betracht ziehen können – vor allem, wenn Zeit, Flexibilität und Budget von entscheidender Bedeutung sind.
Die Wahl des GRC-Ansatzes und des GRC-Tools hat einen erheblichen Einfluss auf die Effektivität der einzelnen Phasen. Komplexe, aber oft kompliziert zu wartende Lösungen (wie SAP GRC Access Control) können ein Projekt mit technischer Komplexität überfordern. Alternative Lösungen wie SmartGRC hingegen konzentrieren sich auf Einfachheit, Transparenz und die Zusammenarbeit mit Geschäftsanwendern. Mit Funktionen wie:
- Schnelle Implementierung und benutzerfreundliche Oberfläche
- Integration mit OpenAI
- Umgang mit Nicht-SAP-Systemen über XML
- Aktive Berichterstattung und Trendanalyse
Zusammenfassung.
GRC-Tools können nicht nur bei der Risikoüberwachung helfen, sondern auch bei den Arbeitsabläufen der Zugriffsgewährung und der Gestaltung von Rollen – aber ihre Wirksamkeit hängt von den Inhalten ab, auf denen sie basieren. Deshalb ist es so wichtig, von Anfang an eine klare und gut strukturierte SoD-Matrix und Risikodefinitionen zu erstellen. Ohne solide Inhalte wird auch das beste Tool nicht den erwarteten Nutzen bringen.
