Funktionstrennung in 2026:
SAP S/4HANA, KI-Agenten und die Zukunft des Zugriffsmanagements

1.1 Das Kernprinzip

Funktionstrennung ist die Praxis, kritische Geschäftsprozessschritte auf mindestens zwei verschiedene Personen aufzuteilen, sodass keine einzelne Person eine Transaktion sowohl initiieren als auch abschließen kann, die zum Verlust von Geld, Daten oder Vermögenswerten führt. Das Ziel ist einfach: Wenn kein einzelner Mensch den gesamten Zyklus kontrolliert, wird Betrug oder Fehler erheblich schwieriger, ohne Erkennung zu begehen.

Eine gute Illustration ist der Beschaffungsprozess. Die Person, die eine Bestellanforderung anlegt, sollte nicht dieselbe Person sein, die sie genehmigt, die Ware empfängt, die Lieferantenrechnung bucht und die Zahlung ausführt. Jeder dieser Schritte stellt einen Entscheidungspunkt dar. Durch die Verteilung dieser Entscheidungen auf verschiedene Personen schafft die Organisation natürliche Checks and Balances. Veruntreuung würde mindestens zwei Personen in Kollusion erfordern, was die Kosten und das Risiko von Betrug erheblich erhöht.

Wenn ein einzelner Mitarbeiter den gesamten Beschaffungszyklus kontrolliert und eine enge Beziehung zu einem Lieferanten unterhält, sind die Bedingungen für Fehlverhalten gegeben. Der Lieferant hat alle Anreize, diese Beziehung zu pflegen - durch Boni, Weihnachtsgeschenke, Reisen, Einladungen zu Sportveranstaltungen oder Bargeld. Aus Sicht des Lieferanten erleichtert es alles, diesen Mitarbeiter als internen Verbündeten zu behalten: Aufträge ohne echten Wettbewerb gewinnen, zu überhöhten Preisen abrechnen, für nicht gelieferte Waren oder Dienstleistungen abrechnen - und das alles unentdeckt zu halten, solange der Mitarbeiter den Prozess kontrolliert.

Daten aus dem ACFE Occupational Fraud 2024: A Report to the Nations, basierend auf 1.921 realen Betrugsfällen in 138 Ländern, bestätigen, wie exponiert die Beschaffungsfunktion ist. Laut Bericht bleiben Rechnungssysteme einer der häufigsten Betrugsarten bei Ausgaben mit einem Medianverlust von 100.000 USD pro Fall; Korruption, einschließlich Bestechung und Kickbacks von Lieferanten, wird in 48% aller Fälle erwähnt, und der Medianverlust durch Beschaffungsbetrug beträgt 200.000 USD - unter den höchsten aller Kategorien.

In modernen Top-ERP-Systemen wie SAP S/4HANA wird SoD durch das Berechtigungsmodell durchgesetzt und kontrolliert, welche Transaktionen, Anwendungen und Stammdatenobjekte ein Benutzer aufrufen kann. Ein gut gestaltetes Modell weist Rollen auf Basis der Arbeitsfunktion zu und integriert Einschränkungen, die verhindern, dass eine Person eine Kombination von Berechtigungen besitzt, die einen SoD-Konflikt erzeugt. Diese technische Kontrollarchitektur ist offensichtlich das Fundament.

Die praktische Herausforderung besteht darin, dass Organisationen selten bei Null anfangen. Die meisten SAP-Umgebungen wurden vor Jahren konfiguriert, Rollen wurden eher für Funktionalität als für Kontrolle entworfen, und die Zugriffslandschaft wuchs organisch mit neuen Benutzern, Integrationen und Geschäftsfällen. Im Laufe der Zeit akkumulieren Rollen Berechtigungen, für die sie nie vorgesehen waren, und Verantwortlichkeiten wandern zwischen Abteilungen auf Weisen, die im ursprünglichen Rollendesign nicht berücksichtigt wurden.

Das Ergebnis ist ein System, in dem theoretische SoD in Richtliniendokumenten existiert, der tatsächliche Zugriff aber eine ganz andere Geschichte erzählt. Und diese Herausforderung beschleunigt sich 2026. Jede Fiori-App-Aktivierung, jede neue länderspezifische Konfigurationsvariable, jede S/4HANA-Iteration schafft neue potenzielle Konfliktkombinationen. Organisationen, die ausschließlich auf statische, auf den ursprünglichen ECC-Designs basierende SoD-Matrizen vertrauen, managen tatsächlich Risiken aus sechs Jahren. Die Best Practice liegt anderswo.

1.2 Warum SoD-Programme in der Praxis scheitern

1. Zugriff geprägt von Dringlichkeit, nicht von Design. Unter Go-Live-Druck verschiebt sich die Priorität davon, Dinge richtig zu machen, hin zum Live-Schalten. Benutzer erhalten Zugriff basierend auf dem, was sie zum Entsperren benötigen, und Berechtigungen werden schnell genehmigt, um den Schwung beizubehalten. Was vorübergehend sein sollte, wird dauerhaft. Ein kompromittiertes Berechtigungsmodell wird zur institutionalisierten Drift, und niemand hat Zeit, es zu bereinigen.

Aber unter der Dringlichkeit liegt ein tieferes Problem. Selbst wenn Zeit und gute Absicht vorhanden sind, kann niemand klar beantworten, welcher Zugriff für eine bestimmte Rolle erforderlich ist. HR-Stellenbeschreibungen arbeiten auf einer zu hohen Ebene. Funktionale Spezialisten beschreiben, was Menschen prozessbezogen benötigen, nicht in Bezug auf Berechtigungsobjekte. IT-Teams müssen zwischen diesen beiden Welten übersetzen, oft ohne klare Antworten von beiden Seiten. Das Ergebnis ist, dass Zugriff auf Vermutungen basiert zugewiesen wird.

Innerhalb von Wochen werden diese Vermutungen zur neuen Baseline. Wenn eine neue Person dem gleichen Team beitritt, wird sie so provisioniert, dass sie zu ihrem Vorgänger passt, und erbt Zugriff, der von Anfang an nie korrekt war, plus alle zusätzlichen Berechtigungen, die in der Zwischenzeit gesammelt wurden. Was als vorübergehender Workaround begann, wird zum permanenten Rollenmodell.

2. Copy-Paste oder Make-Like Onboarding. Wenn ein neuer Benutzer beitritt, ist der Weg des geringsten Widerstands, jemanden im gleichen Team zu finden und seine Rollen zu kopieren. Es dauert Minuten, der neue Benutzer ist sofort produktiv, und der Manager ist glücklich. Aber das Quellkonto hat seinen Zugriff ebenfalls über dieselbe Methode geerbt, wahrscheinlich viele Iterationen zurück.

Das Quellkonto wird selten überprüft, bevor es geklont wird. Aber selbst wenn jemand es überprüfen wollte, würde er schnell auf dasselbe Problem stoßen, das in Punkt 1 beschrieben wurde. Niemand weiß mit Sicherheit, welche Berechtigungen eine bestimmte Position haben sollte. Also setzt sich das Kopieren fort, und jede Generation fügt ihre eigene Schicht hinzu.

Mit der Zeit verschlimmert sich das Problem leise. Das Zugriffsprofil der Abteilung driftet mit jeder Einstellung weiter von jedem beabsichtigten Design ab, aber weil jeder einzelne Schritt vernünftig aussieht, hebt niemand eine Flagge. Rollen-Kompromittierung manifestiert sich nicht als deutliches Problem - sie manifestiert sich als sich aufbauendes Rauschen in der SoD-Matrix und sich wiederholende Audit-Findings, die jedes Jahr schwieriger zu erklären werden.

Bis ein Audit oder eine Sicherheitsüberprüfung das Problem ans Licht bringt, ist es nahezu unmöglich, nachzuvollziehen, was schief gegangen ist. Die ursprünglichen Referenzkonten existieren möglicherweise nicht mehr. Die Personen, die die Provisioning-Entscheidungen getroffen haben, sind möglicherweise nicht mehr im Unternehmen. Die Geschäftslogik, die diese Zuweisungen einst rechtfertigte, ist längst verloren.

3. Das SoD-Risikoframework, das niemandem gehört. Die meisten Organisationen behandeln die SoD-Risikomatrix als technisches Deliverable - etwas, das das Sicherheitsteam oder externe Berater während des Implementierungsprozesses erstellen, formelle Sign-Offs erhalten und dann auf einem Shared Drive archivieren, bis Audit-Zeit kommt. Dieser Ansatz missversteht grundlegend, was die Matrix sein sollte.

Die Matrix ist nicht nur eine Liste konfligierender Transaktionscodes. Sie ist die Antwort auf eine Reihe geschäftlicher Fragen, über die jemand sich hinsetzen und gründlich nachdenken muss. Was würde passieren, wenn dieselbe Person einen Lieferanten anlegen und freigeben könnte? Was würde passieren, wenn sie sowohl Bestellungseingabe als auch Wareneingang kontrollieren würde? Diese Szenarien haben keine eindeutigen Antworten - sie hängen vom Risikoprofil des Geschäfts, vom Sektor, von Regulierungen und der Toleranz der Organisation gegenüber Risiko ab.

Wenn diese Gesprächsführung gut läuft, tut sie mehr als nur ein Dokument zu produzieren. Sie verändert die Art und Weise, wie Business Owner über Zugriff denken. Sie hören auf, Systemberechtigungen als technische Angelegenheit für IT zu sehen, und beginnen, sie als Spiegelbild dessen zu sehen, wie das Geschäft operiert. Dieser Mentalitätswandel verwandelt SoD von einer Compliance-Aufgabe in einen lebendigen Teil des Geschäftsprozessmanagements.

In der Praxis findet dieses Gespräch selten in der Tiefe statt, in der es sollte. Was die meisten Projekte stattdessen tun, ist, eine Baseline-Regelset von einer früheren Implementierung, einer Standard-SAP-Vorlage oder manchmal einer GRC-Tool-Regelbibliothek zu nehmen, ein paar Dinge anzupassen und es als erledigt zu bezeichnen. Die technische Arbeit wird erledigt, aber die zugrundeliegende Geschäftsarbeit - das Mappen, wie dieses spezielle Geschäft operiert und welche Kombinationen tatsächlich Risiko darstellen - wird kaum berührt.

Dieses Fehlen von Eigentümerschaft ist es, was das Wartungsproblem unvermeidlich macht. Das System entwickelt sich nach dem Go-Live kontinuierlich weiter. Neue Fiori-Anwendungen werden bereitgestellt, Z-Transaktionen werden für lokale Anforderungen erstellt, der Beschaffungsprozess wird neu strukturiert, und eine Fusion bringt eine neue Tochtergesellschaft in das ROK-Rollenmodell ein. Jede dieser Veränderungen verändert potenziell, welche Zugriffskombinationen riskant sind. Aber wenn niemand die Matrix aus geschäftlicher Sicht besitzt, finden diese Änderungen nie ihren Weg zurück zu den Regeln.

4. Überlastung durch Mitigationen. Wenn ein SoD-Konflikt nicht schnell gelöst werden kann - weil seine Behebung Rollendesign, Prozessänderung oder ein Gespräch erfordert, das niemand führen will - ist die Standardreaktion, eine kompensierende Kontrolle hinzuzufügen und es als erledigt zu bezeichnen. Die Matrix wird aktualisiert, das Risiko wird als mitigiert dokumentiert, und das Team geht zum nächsten Problem über.

Das Register kompensierender Kontrollen wächst auf Hunderte von Einträgen. Jede Kontrolle erfordert einen verantwortlichen Eigentümer und eine regelmäßige Wirksamkeitsprüfung, aber wenn die Liste wächst, werden die Überprüfungen zu einem Häkchen-Übung. Einige Kontrollen werden dokumentiert, aber in der Praxis nie ausgeführt. Andere verweisen auf Berichte oder Workflows, die längst nicht mehr existieren. Das Register sieht auf dem Papier solide aus, aber seine tatsächliche Effektivität sinkt mit jedem Quartal.

5. Nur audit-getriebene Berechtigungsprüfungen. Der Zugriffsüberprüfungszyklus wird vom externen Auditkalender festgelegt, nicht vom Risikoprofil des Systems. Einmal jährlich, typischerweise in den Wochen vor dem Finanzaudit, startet das Sicherheitsteam eine periodische Überprüfung. Business Manager erhalten Excel-Berichtslisten mit Hunderten von Benutzern und Rollen, werden gebeten, jeden zu genehmigen oder abzulehnen, und alle beeilen sich, den Zyklus vor dem Auditorbesuch abzuschließen.

Der Auditprozess selbst fügt eine weitere Komplexitätsebene hinzu. Auditoren kommen oft mit ihrer eigenen SoD-Regelmenge an, einer, die nicht für dieses Geschäft, diese Systemkonfiguration oder diese SAP-Version gebaut wurde. Sie eröffnen eine Liste von Findings basierend auf ihrer Matrix, die die Organisation verteidigen oder beheben muss - oft ohne Kontext darüber, warum diese spezifische Kombination in dieser Umgebung ein Problem darstellt oder nicht.

Und doch, trotz all seiner Einschränkungen, macht das Audit etwas Wichtiges. Es bringt Zugriff und SoD-Risiken auf die Agenda. Es schafft einen Moment, in dem das Senior Management aufmerksam wird, in dem das Thema von einer technischen Angelegenheit zu einer Managementangelegenheit übergeht. Ohne diesen externen Druck würden viele Organisationen SoD überhaupt keine laufende Aufmerksamkeit schenken.

6. Während des Projekts beheben oder für immer tragen. Es gibt einen grundlegenden Unterschied zwischen dem Beheben des Zugriffsprofils eines Benutzers und dem Beheben des Rollenkonzepts, auf dem die gesamte Organisation läuft. Die Zugriffsprofile einzelner Benutzer in Konformität zu bringen, ist zu jedem Zeitpunkt möglich - man kann konkrete Benutzer mit Konflikten identifizieren, ihre Manager einbeziehen und problematische Berechtigungen entfernen. Die Reparatur der Rollenarchitektur selbst ist eine Größenordnung schwieriger.

Wie in den Punkten 1 und 2 beschrieben, ist das Fundament oft bereits vor dem Go-Live kompromittiert. Aber selbst wenn man die Qualität individueller Zugriffsentscheidungen beiseite lässt, trägt die Rollenarchitektur selbst ihr eigenes Erbe. Rollen, die um technische Funktionen statt um Geschäftsfunktionen herum entworfen wurden. Breitgefächerte Rollen, die für Projektkomfort statt für operative Präzision entworfen wurden. Rollen, die über Jahre Berechtigungen ansammelten, ohne Designüberprüfung.

Wenn das Geschäft auf einem Rollenkonzept läuft, schafft jeder Bereinigungsversuch sofortiges operatives Risiko. Das Entfernen eines Berechtigungsobjekts bricht eine Transaktion, von der jemand abhängt. Eine Rolle zu teilen bedeutet, dass jemand, der alles hatte, jetzt zwei neue Rollen statt einer benötigt, und ein Manager muss das neue Provisioning genehmigen. Diese Störungen werden aus dem Projektbudget bezahlt, sodass Organisationen in die Falle tappen: Technisch erfordert die Lösung des Konflikts einen konkreten Weg, aber der Weg verursacht Schmerzen für das Geschäft.

7. SoD als Dokumentation für Auditoren, nicht als Designprinzip. In Organisationen ohne dedizierte GRC-Funktion hat SoD zwischen Auditzyklen keinen Eigentümer. Es gibt kein Team, das für die Pflege der Risikomatrix zwischen Iterationen verantwortlich ist, kein dauerhaftes Konfliktmonitoring, keine zeitliche Trendverfolgung. Die Matrix existiert in einem Ordner, zu dem die Leute im März oder Oktober zurückkehren, wenn der Auditor erscheint.

Wenn Auditoren ankommen, performt die Organisation. Daten werden extrahiert, Beweise werden gepackt, Mitigationen werden dokumentiert, und Findings werden mit Dringlichkeit behandelt. Es sieht aus wie eine funktionierende Kontrollumgebung. Aber wenn das Audit beendet ist, werden die Daten wieder verpackt, und die Aufmerksamkeit der Organisation wendet sich anderen Prioritäten bis zum nächsten Mal zu.

Das tiefere Problem ist, was dieses Muster mit dem Verständnis der Organisation für ihr eigenes Risiko macht. Wenn SoD durch Auditfristen statt durch Geschäftseigentümerschaft angetrieben wird, sind die gestellten Fragen immer eng - haben wir Beweise für X-Kontrollen? - und nicht weit: Spiegelt unser Zugriffsmodell wider, wie dieses Geschäft tatsächlich operiert?

Etwas geht auch verloren in der Art und Weise, wie SoD kommuniziert wird. Audit-Findings gehen als Compliance-Probleme an das Senior Management, präsentiert in Audit-Sprache, gemessen an Audit-Kriterien und gelöst aus der Mentalität des Audit-Managements. Das Gespräch konzentriert sich darauf, das Finding zu schließen, nicht darauf, zu ändern, wie das Geschäft operiert. Was nicht verloren geht, ist etwas, das das Finding überhaupt erst verursacht hat.

8. Überhaupt kein SoD-Programm. Die meisten Organisationen haben die Zutaten. Es gibt eine Risikomatrix, auch wenn veraltet. Es gibt Mitigation-Aufzeichnungen, auch wenn niemand sie überprüft. Es gibt Zugriffsüberprüfungen, auch wenn nur jährlich. Die Leute, die für die verschiedenen Teile verantwortlich sind, kennen ihre Namen.

Was fehlt, ist die Architektur, die diese Teile zu etwas verbindet, das tatsächlich funktioniert. Eine definierte Risikobereitschaft, die der Organisation sagt, welches Niveau des Zugriffsrisikos akzeptabel ist und was Eskalation erfordert. Ein Governance-Forum, in dem Zugriff und Risiko regelmäßig auf Exekutivebene diskutiert werden. Ein Zyklus, der Risikoidentifikation mit Remediation, Monitoring und Richtlinienverbesserung verbindet.

Ohne diese lebt jede Komponente in ihrem eigenen Silo. Die Risikomatrix ist nicht mit dem Überprüfungszyklus verbunden. Der Überprüfungszyklus ist nicht mit dem Remediation-Prozess verbunden. Die Mitigation-Aufzeichnungen werden nicht gegen Systemänderungen überwacht. Jedes Team führt seinen Teil aus, aber das Ganze arbeitet nicht zusammen. Das ist der Moment, in dem SoD aufhört, ein Programm zu sein und zu einer Serie isolierter Aktivitäten wird.

9. Excel statt eines dedizierten GRC-Tools. Die in Tabellen verwaltete SoD-Analyse schafft eine strukturelle Lücke zwischen dem Anschein der Kontrolle und ihrer Realität. Rollenexporte werden manuell aus dem System gezogen, mit der Risikomatrix in Excel quervernetzt und als Kontrollstatus präsentiert. Positive Ergebnisse werden dokumentiert. Negative werden diskutiert und entweder mitigiert oder als akzeptiert abgeschrieben.

10. Niemand will die Person sein, die Nein sagt. SoD-Programme scheitern aus technischen, prozessualen und Governance-Gründen. Aber unter vielen dieser Misserfolge liegt ein einfacheres und menschlicheres Problem. Nein zu Zugriff zu sagen, kostet. Es verursacht Konflikt mit dem Manager, der gefragt hat. Es verlangsamt das Projekt, das der Manager gerade versprochen hat. Es schafft den Ruf, eine Person zu sein, die Dinge blockiert.

Diese Dynamik ist selten in Audit-Findings oder Risikoregistern sichtbar. Sie erscheint nicht als Kontrollversagen in irgendeinem formellen Sinn. Aber sie prägt jede Entscheidung im Zugriffsverwaltungsprozess. Rollendesignentscheidungen begünstigen Breite vor Präzision. Genehmigende genehmigen, weil Ablehnung unbequem ist. Mitigationen werden zur Matrix hinzugefügt, anstatt Konflikte an der Quelle zu beheben, weil die Behebung ein schwieriges Gespräch erfordern würde.

Den Aufbau eines funktionierenden SoD-Programms bedeutet, diese Dynamik direkt anzuerkennen. Es bedeutet, den Personen, die für die Zugriffskontrolle verantwortlich sind, organisatorische Rückendeckung zu geben, um Nein zu sagen, Eskalationspfade, um Bedenken zu äußern, wenn das Management nicht zustimmt, und einen Governance-Rahmen, der den Prozess vor kurzfristigem Druck schützt. Ohne dies werden selbst die fortschrittlichsten SoD-Matrizen und die besten GRC-Tools keinen Unterschied machen.

1.3 Die geschäftlichen Kosten von SoD-Versagen

Regulierungsbehörden und Auditoren haben SoD-Verletzungen lange als signifikantes Kontrolldefizit behandelt. Unter Sarbanes-Oxley Section 404 können ungelöste SoD-Konflikte in Finanzsystemen zu einer Material Weakness eskalieren - einem Status, der eine öffentliche Offenlegung erfordert und sich auf die Aktienbewertung des Unternehmens auswirken kann. Das PCAOB identifiziert konsequent IT General Controls-Schwächen, einschließlich SoD, als unter den häufigsten Audit-Findings in SAP.

Die Betrugsdaten machen den Einsatz konkret. Die ACFE schätzt, dass Organisationen 5% ihrer jährlichen Einnahmen durch Beschäftigungsbetrug verlieren, mit einem durchschnittlichen Verlust pro Fall von 1,7 Millionen USD. Diese Zahl wird weithin als Benchmark zitiert, verbirgt aber ein viel größeres Bild: Die meisten Betrugsfälle werden nie entdeckt oder extern gemeldet. Der ACFE Report to the Nations zeigt konsistent, dass Anti-Betrugs-Kontrollen in fast allen Fällen abwesend sind oder umgangen werden. SoD ist zentral in diesem Bild.

Über das Betrugsrisiko hinaus sind die operativen Kosten eines schlechten SoD-Managements für sich genommen erheblich. Organisationen, die auf jährliche manuelle Überprüfungen angewiesen sind, verbringen typischerweise drei bis sechs Wochen pro Überprüfungszyklus - Personenwochen, die in das Ziehen von Exports, das Normalisieren von Daten, das Identifizieren von Konflikten, das Eskalieren an Business Manager, das Verfolgen von Sign-Offs und das Verpacken von Beweisen für den Auditor gezogen werden. Das ist ein wiederkehrender, ineffizienter Kostenfaktor, der schlechter als linear skaliert, wenn die Organisation wächst.

Das Muster, das die ACFE-Daten beschreiben - Kontrollen abwesend oder übergangen, Betrug, der monatelang unentdeckt läuft, Verluste, die erst nach der Tat entdeckt werden - ist kein abstraktes Risiko. Es ist das vorhersagbare Ergebnis von SoD-Programmen, die mehr für Compliance als für Handlung entworfen werden.

1.4 Die unsichtbaren Kosten

Wenn von Kosten gesprochen wird, denken die meisten Manager an direkte Auswirkungen - Audit-Findings, Geldstrafen, Betrugsverluste. Aber die tatsächlichen Kosten eines schlecht funktionierenden SoD-Programms sind viel weiter verbreitet und oft unsichtbar in Standard-Finanzberichten.

Verlorene operative Geschwindigkeit. Organisationen mit chaotischer Zugriffsstruktur reagieren langsamer auf Geschäftsveränderungen. Eine neue Akquisition, eine Reorganisation, eine neue Produkteinführung - jede dieser Veränderungen erfordert Anpassungen am Zugriffsmodell. Wenn das Modell unklar ist, dauert jede dieser Anpassungen Wochen statt Tage. Multiplizieren Sie das mit Dutzenden von Änderungsanfragen pro Quartal, und der Compound-Effekt auf die Agilität wird signifikant.

Niedrigere Mitarbeiterproduktivität. Wenn der Zugriffsprovisionierungsprozess langsam und undurchsichtig ist, warten neue Mitarbeiter Tage oder Wochen auf den vollen Zugriff. In dieser Zeit arbeiten sie mit eingeschränkten Berechtigungen und müssen Kollegen mit umfassenderem Zugriff um Hilfe bitten. Dies erzeugt zwei Probleme: Der neue Mitarbeiter ist unterproduktiv, und der erfahrene Mitarbeiter, der hilft, wird von seiner eigentlichen Arbeit abgelenkt.

Höhere Lizenz- und Wartungskosten. Schlechte Zugriffsverwaltung führt oft zu unnötigen Lizenzkosten. Wenn die Organisation nicht klar sehen kann, wer was nutzt, weist sie tendenziell mehr Lizenzen zu als nötig. Bei SAP-Systemen kann dies auf die Einstufung von Benutzern als Professional User wirken, wenn sie tatsächlich als Self-Service oder Limited User klassifiziert werden sollten. Die jährliche Wirkung kann signifikant sein.

Beziehungskosten. Wenn jedes Audit Findings produziert, die das Geschäft als unfair empfindet, verschlechtert sich die Beziehung zwischen IT-Security, GRC-Team und Geschäftseinheiten. IT wird als Hindernis gesehen, Audit als Ärger, und SoD als Bürokratie. Diese Wahrnehmung macht jede zukünftige Verbesserungsinitiative schwerer zu starten, weil sie auf einer Basis bereits beschädigten Vertrauens beginnt.

Strategische Kosten. Auf der höchsten Ebene begrenzt schlechtes SoD-Management die Optionen der Organisation. Eine geplante Cloud-Migration wird komplexer, wenn das aktuelle Zugriffsmodell unklar ist. Ein neuer GRC-Anbieter wird schwerer zu integrieren, wenn die aktuelle Konfiguration nicht dokumentiert ist. Eine Akquisition wird mit zusätzlichem Risiko belastet, wenn die SoD-Compliance des Ziels nicht überprüft werden kann. Jede dieser Reibungen reduziert die strategische Beweglichkeit.

1.5 Was funktioniert

Effektive SoD-Programme teilen mehrere Schlüsseleigenschaften, die sie von compliance-getriebenen Versuchen unterscheiden. Sie beginnen mit klarem Geschäftskontext - Verständnis dafür, welche Prozesse tatsächlich Risiko bergen, wie sie in dieser spezifischen Organisation funktionieren und welche Kontrollen sinnvoll sind. Sie verlassen sich nicht ausschließlich auf generische Branchen-Templates.

Sie haben Geschäftseigentümerschaft. Jeder kritische Prozess hat einen klaren Eigentümer, der für SoD-bezogene Entscheidungen in diesem Bereich verantwortlich ist. Diese Eigentümer verstehen, dass Zugriffskontrolle Teil des Risikomanagements ihres Geschäfts ist, nicht ein technisches Detail, das von IT verwaltet wird.

Sie sind in Geschäftsprozesse eingebettet. Joiner-Mover-Leaver-Prozesse werden mit SoD-Bewusstsein im Design entworfen, nicht als nachträgliche Überlegung. Wenn eine Person eine Rolle wechselt, werden ihre alten Berechtigungen evaluiert und gegebenenfalls entfernt - nicht einfach zu den neuen hinzugefügt.

Sie verwenden Technologie als Hebel, nicht als Ersatz für Disziplin. Ein gutes GRC-Tool macht das Programm effizienter, aber es ersetzt nicht die Notwendigkeit für klare Eigentümerschaft, gute Prozesse und Senior Management-Engagement. Die fortschrittlichste Software macht in einer Organisation ohne diese Grundlagen keinen Unterschied.

Sie haben einen kontinuierlichen Verbesserungsrhythmus. Die SoD-Matrix wird mindestens jährlich überprüft, oder häufiger, wenn das Geschäft sich erheblich ändert. Konfliktmuster werden über Zeit verfolgt - nicht nur ihre absoluten Anzahlen, sondern auch ihre Trends. Wenn Konflikte zunehmen, fragt das Programm, warum, und nicht nur, wie sie zu schließen sind.

Sie kommunizieren in der Sprache des Geschäfts. Die Reporting an das Senior Management wird nicht in technischer Audit-Sprache präsentiert, sondern in geschäftlichen Begriffen: welche Risiken sind ausgesetzt, was sind die wahrscheinlichsten Schäden, wie reagieren wir? Diese Übersetzung ist entscheidend, um Engagement und kontinuierliche Investitionen zu erhalten.

1.6 Setting für die folgenden Kapitel

Die folgenden Kapitel bauen auf diesen grundlegenden Konzepten auf. Kapitel 2 untersucht, wie SAP-Berechtigungen tatsächlich funktionieren - was Berechtigungsobjekte sind, wie Rollen aufgebaut sind und welche Implikationen das Modell für SoD hat. Kapitel 3 vertieft die spezifischen Herausforderungen von S/4HANA und Fiori. Kapitel 4 untersucht, wie GRC-Tools (sowohl SAP GRC AC als auch Alternativen) die Risikoanalyse-Arbeit automatisieren können.

Kapitel 5 untersucht die Geschäftslogik von SoD-Risiken - wie die Risikomatrix konstruiert wird, was sie umfassen sollte und wie sie über Zeit gepflegt wird. Kapitel 6 untersucht den Lifecycle-Ansatz - wie Zugriffsanfragen verwaltet, periodische Überprüfungen durchgeführt und Konfliktmuster verfolgt werden. Kapitel 7 untersucht spezialisierte Themen wie kompensierende Kontrollen, Notfallzugriff und kritische Berechtigungen.

Kapitel 8 untersucht das Reifegradmodell und wie eine Organisation ihren aktuellen Stand bewertet und einen Verbesserungspfad definiert. Kapitel 9 untersucht Best Practices und häufige Fallstricke aus realen Implementierungen. Kapitel 10 schließt mit einer Diskussion über die Zukunft von SoD im Kontext aufkommender Technologien wie KI, autonomer Agenten und sich entwickelnder regulatorischer Rahmenbedingungen.

2.1 Berechtigungsobjekte und Felder

Das SAP-Berechtigungsmodell basiert auf Berechtigungsobjekten, die die atomare Einheit der Zugriffskontrolle sind. Ein Berechtigungsobjekt ist ein Container, der aus mehreren Berechtigungsfeldern besteht, jedes davon mit bestimmten Werten gefüllt. Diese Kombination definiert, welche bestimmten Aktionen ein Benutzer mit bestimmten Daten durchführen kann.

Nehmen wir das Berechtigungsobjekt F_BKPF_BUK als Beispiel. Es kontrolliert den Zugriff auf Belegkopf für Buchhaltungsbelege auf Buchungskreisebene. Es enthält zwei Felder: BUKRS (Buchungskreis) und ACTVT (Aktivität). Das Feld BUKRS kann konkrete Buchungskreiswerte enthalten, wie 1000, 2000 oder ein Wildcard *. Das Feld ACTVT kann Aktivitätscodes wie 01 (anlegen), 02 (ändern) oder 03 (anzeigen) enthalten.

Eine Berechtigung ist eine spezifische Instanziierung eines Berechtigungsobjekts mit konkreten Feldwerten. Zum Beispiel: F_BKPF_BUK mit BUKRS=1000 und ACTVT=03 erlaubt dem Benutzer, Belege im Buchungskreis 1000 anzuzeigen. Eine andere Berechtigung für dasselbe Objekt mit BUKRS=* und ACTVT=01,02,03 würde dem Benutzer erlauben, Belege in allen Buchungskreisen anzulegen, zu ändern und anzuzeigen.

Es gibt ungefähr 3.000 Berechtigungsobjekte in einem Standard-SAP-System, mit Branchen- und Erweiterungslösungen, die noch mehr hinzufügen. Jedes Berechtigungsobjekt hat eine spezifische Bedeutung im Kontext des Geschäftsprozesses, den es kontrolliert. Die Komplexität des Modells ergibt sich aus der Anzahl der Objekte, ihren miteinander verbundenen Auswirkungen und der spezifischen Konfiguration jeder Implementierung.

2.2 Rollen und Profile

Die Berechtigungen werden Benutzern nicht direkt zugewiesen, sondern über Rollen. Eine Rolle ist eine Sammlung von Berechtigungen, die typischerweise eine bestimmte Geschäftsfunktion oder einen Subprozess unterstützen. Wenn ein Benutzer eine Rolle zugewiesen bekommt, erbt er alle Berechtigungen, die diese Rolle enthält.

Es gibt zwei Hauptarten von Rollen: Einzelrollen und Sammelrollen. Eine Einzelrolle enthält eine Liste von Berechtigungen mit ihren spezifischen Feldwerten. Eine Sammelrolle ist eine Sammlung anderer Rollen (entweder Einzelrollen oder andere Sammelrollen). Wenn einem Benutzer eine Sammelrolle zugewiesen wird, erbt er die Berechtigungen aller darin enthaltenen Rollen.

Profile sind die technische Implementierung von Berechtigungen. Wenn eine Rolle generiert wird, wird gleichzeitig auch ein Profil generiert, das die Berechtigungen in einer Form enthält, die das System bei der Berechtigungsprüfung verwenden kann. Profile haben Namen, die mit einem Präfix beginnen, das sie als zu einer bestimmten Rolle gehörend identifiziert.

Es gibt auch Standard-SAP-Profile, die direkt durch den Customizing zugewiesen werden können. Das bekannteste davon ist SAP_ALL, das praktisch volle Zugriff auf alles im System gewährt, und SAP_NEW, das alle neuen Berechtigungen erhält, die in nachfolgenden Releases hinzugefügt werden. Diese Profile sollten in produktiven Systemen niemals normalen Benutzern zugewiesen werden - ihre Existenz ist auf Notfallszenarien und das technische Postinstallation-Setup beschränkt.

2.3 Berechtigungsprüfung in der Praxis

Wenn ein Benutzer versucht, eine Aktion in SAP durchzuführen, führt das System eine Berechtigungsprüfung durch. Diese Prüfung erfolgt typischerweise über den ABAP-Befehl AUTHORITY-CHECK. Beim Aufruf des Befehls untersucht das System die dem Benutzer zugewiesenen Berechtigungen und prüft, ob mindestens eine davon den Zugriff auf das spezifische angeforderte Berechtigungsobjekt mit den entsprechenden Feldwerten erlaubt.

Der Schlüssel zum Verständnis ist, dass Berechtigungen additiv sind - wenn ein Benutzer mehrere Rollen hat und eine davon Zugriff erlaubt, hat er Zugriff. Es gibt keinen Mechanismus für 'explizite Verweigerung' in der gleichen Weise wie in einigen anderen Sicherheitssystemen. Wenn ein Benutzer also eine Rolle hat, die den Zugriff auf F_BKPF_BUK in Buchungskreis 1000 erlaubt, und eine andere, die ihn in Buchungskreis 2000 erlaubt, hat der Benutzer effektiv Zugriff auf beide.

Diese Tatsache hat tiefgreifende Auswirkungen auf SoD. Wenn die SoD-Risikomatrix definiert, dass die Kombination von 'Lieferanten anlegen' und 'Zahlungslauf ausführen' einen Konflikt darstellt, geht es nicht nur um die Suche nach einer einzelnen Rolle, die beide Berechtigungen hat. Es geht darum, alle möglichen Kombinationen zugewiesener Rollen zu prüfen, die zusammen diese Berechtigungen erteilen würden. Bei einem Benutzer mit zehn Rollen ist die Anzahl möglicher Kombinationen sehr hoch.

Aus diesem Grund ist die SoD-Analyse auf der Benutzerebene immer additiv und auf alle aktiven Berechtigungen über alle Rollen bezogen. Sie kann nicht durch die Analyse einzelner Rollen durchgeführt werden - obwohl die Analyse von Rollendesigns auch wichtig ist, um Konfliktquellen zu verstehen und das Modell zu verbessern.

2.4 PFCG: Das Werkzeug, das alles definiert

Das Hauptwerkzeug für die Verwaltung von Rollen in SAP ist die Transaktion PFCG (Profilgenerator). PFCG ist der zentrale Ort, an dem Sicherheitsadministratoren Rollen anlegen, modifizieren und ihre Berechtigungen verwalten. Das Verständnis seiner Funktionen ist entscheidend für jeden, der mit dem SAP-Berechtigungsmodell arbeitet.

PFCG hat mehrere Tabs, die verschiedene Aspekte der Rolle steuern. Der Menü-Tab definiert, welche Transaktionen und Anwendungen Teil dieser Rolle sind. Wenn Transaktionen zum Menü hinzugefügt werden, schlägt PFCG automatisch die Berechtigungsobjekte vor, die sie verwenden, basierend auf den Daten in der SU24-Tabelle (die die Beziehung zwischen Transaktionen und Berechtigungsobjekten definiert).

Der Tab Berechtigungen zeigt alle Berechtigungsobjekte, die die Rolle hat, und ermöglicht ihre detaillierte Konfiguration. Sicherheitsadministratoren können Werte für jedes Berechtigungsfeld setzen - entweder spezifische Werte, Wertebereiche oder Wildcards (*). Hier wird die Granularität der Kontrolle eingestellt.

Der Tab Benutzer zeigt, welche Benutzer dieser Rolle zugewiesen sind. Hier können Administratoren Rollen direkt einzelnen Benutzern oder einer Gruppe von Benutzern zuweisen oder entfernen. In ausgereifteren Implementierungen erfolgt diese Zuweisung jedoch über GRC-Tools mit Workflow-Genehmigung, nicht direkt in PFCG.

Eine wichtige PFCG-Funktion ist die Rollenverknüpfung mit Organisationsebenen wie Buchungskreis oder Werk. Mit dieser Verknüpfung kann die gleiche Rolle Zugriff auf verschiedene organisatorische Einheiten erteilen, je nachdem, welche Organisationsebenen für einen bestimmten Benutzer definiert sind. Dies ist ein leistungsstarker Mechanismus, der das Rollendesign vereinfacht, kann aber auch eine Quelle der Komplexität sein, wenn er falsch implementiert wird.

2.5 Transaktionen und ihre Beziehung zu Berechtigungen

In ECC und früheren Versionen war der Transaktionscode (T-Code) die primäre Einheit, durch die Benutzer mit dem System interagierten. Jede T-Code repräsentierte eine bestimmte Geschäftsaktion - wie ME21N für die Erstellung einer Bestellung oder FB01 für die manuelle Buchhaltungsbuchung. Der T-Code ist auch eine wichtige Einheit für SoD-Zwecke, weil viele SoD-Regeln historisch in Form von T-Code-Kombinationen ausgedrückt wurden.

Die Beziehung zwischen einer Transaktion und ihren erforderlichen Berechtigungen ist nicht trivial. Eine einzelne Transaktion kann Dutzende von Berechtigungsobjekten überprüfen, abhängig davon, welche spezifischen Aktionen der Benutzer innerhalb dieser Transaktion ausführt. Wenn ein Benutzer beispielsweise ME21N startet, prüft das System Berechtigungen wie M_BEST_BSA (Bestellanforderung), M_BEST_WRK (Bestellanforderung pro Werk), M_BEST_EKO (Bestellanforderung pro Einkaufsorganisation) und mehr.

Die Tabelle SU24 ist der Ort, an dem diese Beziehungen definiert werden. Sie enthält Standard-SAP-Mappings, die zeigen, welche Berechtigungsobjekte mit welchen Transaktionen verbunden sind, und ob die Berechtigung ein 'Default' (vorgeschlagen, wenn die T-Code zur Rolle hinzugefügt wird) oder optional ist. Diese Tabelle kann nach den lokalen Bedürfnissen einer Organisation angepasst werden, was eine leistungsstarke aber gleichzeitig komplexe Möglichkeit ist.

In S/4HANA gibt es viele Transaktionen immer noch als Backend-Implementierung, aber Benutzer interagieren oft mit ihnen über Fiori-Anwendungen, die ein modernes UI bereitstellen. Eine einzelne Fiori-App kann mehrere zugrunde liegende Transaktionen kombinieren oder völlig neue Funktionalität bereitstellen, die in der klassischen Transaktionsverbindung nicht existiert. Dies komplettiert das SoD-Mapping erheblich.

2.6 Stammdaten und Customizing

Stammdaten sind ein besonders sensibler Aspekt aus SoD-Sicht. Stammdaten wie Lieferanten, Kunden, Materialien oder Mitarbeiter sind die Grundlage, auf der Transaktionen aufgebaut werden. Wer Stammdaten anlegen oder modifizieren kann, hat indirekten Einfluss auf Transaktionen, die diese Daten verwenden.

Klassisches SoD-Beispiel: Lieferantenstammdaten anlegen und die Zahlungsbearbeitung zur gleichen Zeit. Eine Person, die einen neuen Lieferanten anlegen kann (mit eigenen Bankdaten) und auch die Zahlung an diesen Lieferanten autorisieren kann, hat die volle Kontrolle darüber, Gelder an einen scheinbar legitimen, aber tatsächlich kontrollierten Lieferanten zu lenken. Dies ist eines der häufigsten Betrugsszenarien in SAP-Systemen.

Customizing-Berechtigungen sind eine weitere Hauptkategorie. Customizing bezieht sich auf die Konfiguration des SAP-Systems selbst - Definition von Buchungskreisen, Werken, Materialarten, Belegarten und Tausenden anderer Parameter, die das Systemverhalten steuern. Customizing-Berechtigungen sollten extrem restriktiv sein und nur kleinen Teams (typischerweise im Funktionsbereich und IT) gewährt werden, die für die Wartung der Systemkonfiguration verantwortlich sind.

In produktiven Systemen sollte Customizing in der Regel nur über Transporte aus Entwicklung und Test eingeführt werden, nicht direkt durch Benutzer im Produktivsystem konfiguriert. Direktes Customizing in Produktion ist ein klassisches Audit-Finding und kann ein signifikantes Kontrollproblem darstellen, insbesondere für Buchhaltungsbelange unter SOX.

2.7 Implikationen für SoD-Programme

Das technische Verständnis des SAP-Berechtigungsmodells hat mehrere direkte Implikationen für die Gestaltung von SoD-Programmen. Erstens kann die SoD-Analyse nicht nur auf der Ebene der Transaktionscodes durchgeführt werden - sie muss bis auf die Ebene der Berechtigungsobjekte und Feldwerte hinabsteigen. Eine Rolle, die in PFCG den ME21N-Transaktionscode hat, aber dessen Berechtigungsobjekt M_BEST_BSA mit einem leeren Wert konfiguriert ist, gewährt dem Benutzer nicht effektiv den Zugriff auf die Bestellung von Aufträgen.

Zweitens muss die Analyse die Organisationsebenen berücksichtigen. Eine Rolle, die SoD-Konflikt auf der Berechtigungsobjektebene zeigt, kann in der Praxis kein Risiko darstellen, wenn die Organisationsebenen so eingeschränkt sind, dass der Benutzer in der Praxis nicht beide Aktionen für dieselbe organisatorische Einheit durchführen kann. Diese Subtilität wird häufig in der frühen SoD-Analyse übersehen.

Drittens muss die Analyse alle Berechtigungsquellen berücksichtigen, einschließlich expliziter Berechtigungen, die Rollen umgehen. In legacy SAP-Systemen ist es nicht ungewöhnlich, Benutzer mit Berechtigungen zu finden, die direkt zugewiesen sind (anstatt durch Rollen), oder Profile, die direkt zugewiesen sind. Diese Quellen können in einer rollenbasierten SoD-Analyse übersehen werden, wenn die Tools die Analyse auf der Ebene aller aktiven Berechtigungen nicht durchführen.

Viertens müssen wir die Tatsache berücksichtigen, dass Rollen, einmal entworfen, häufig im Laufe der Zeit modifiziert werden. Eine Rolle, die in einem bestimmten Moment SoD-konform war, kann nach mehreren Modifikationen nicht mehr konform sein. Daher muss SoD-Monitoring kontinuierlich sein, nicht einmalig.

Schließlich impliziert die Komplexität des SAP-Berechtigungsmodells, dass GRC-Tools für seine effektive Analyse fast unverzichtbar sind. Manuelle Analysen können einfache Fälle erkennen, kämpfen aber mit Skalierung, dem Mappen organisatorischer Ebenen und kontinuierlichem Monitoring. Wir werden GRC-Tools im nächsten Kapitel detaillierter untersuchen.

3.1 Was ist Fiori und warum ist es wichtig

SAP Fiori ist die moderne UX-Schicht für SAP-Anwendungen, basierend auf Web-Technologien (HTML5, CSS, JavaScript) und entworfen, um eine moderne, intuitive Benutzeroberfläche zu liefern, die auf verschiedenen Geräten (Desktop, Tablet, Smartphone) konsistent funktioniert. Aus der Sicht eines Endbenutzers ist Fiori die primäre Möglichkeit, mit S/4HANA zu interagieren.

Architektonisch sind Fiori-Anwendungen unabhängige Apps, die spezifische Geschäftsfunktionen ausführen. Jede App hat einen klar definierten Bereich - zum Beispiel 'Bestellung anlegen', 'Lieferantenrechnung anzeigen' oder 'Wareneingang erfassen'. Apps sind nach Rollen und Funktionsbereichen organisiert und über das Fiori Launchpad zugänglich, das als personalisierte Startseite für jeden Benutzer dient.

Im Vergleich zur klassischen ECC-Welt, in der Benutzer über T-Code-Suche oder über Menüs navigierten, präsentiert Fiori dem Benutzer nur das, was für seine Rolle relevant ist. Dies ist sowohl gut als auch herausfordernd. Auf der einen Seite verbessert es die Benutzerproduktivität und reduziert den Schulungsbedarf. Auf der anderen Seite schafft es eine zusätzliche Schicht der Berechtigungsverwaltung - es reicht nicht aus, dass ein Benutzer Zugriff auf die zugrunde liegende Funktion hat; er muss auch Zugriff auf die spezifische Fiori-App haben, die sie ausführt.

Aus SoD-Sicht ist die Fiori-Anwendung eine neue Risikoeinheit. Eine Konfliktmatrix, die in Form klassischer T-Code-Kombinationen definiert ist, kann viele potenzielle Konflikte verfehlen, die jetzt in Form von Fiori-App-Kombinationen aufkommen. Die SoD-Methodik muss dies durch das Inventarisieren aller relevanten Fiori-Apps und ihre korrekte Klassifizierung in der Risikomatrix berücksichtigen.

3.2 OData Services und Berechtigungen

Die Hintergrundarchitektur von Fiori basiert auf OData-Services - REST-ähnlichen Webservices, die Daten und Geschäftsfunktionen über HTTP bereitstellen. Jede Fiori-App kommuniziert mit dem Backend über einen oder mehrere OData-Services. Diese Services sind technische Endpunkte, die Datenzugriff und Operationen wie Lesen, Erstellen, Aktualisieren und Löschen unterstützen.

Aus Sicherheitssicht stellen OData-Services eine neue Schicht dar, die ihre eigenen Berechtigungen benötigt. Diese Berechtigungen werden über das Berechtigungsobjekt S_SERVICE und die SICF-Konfiguration (Transaktion für Internet-Services) gesteuert. Ein Benutzer muss Zugriff sowohl auf den OData-Service als auch auf die zugrunde liegenden Berechtigungsobjekte haben, die seine spezifischen Operationen steuern.

Diese Schichtung schafft Komplexität in der SoD-Analyse. Theoretisch könnte ein Benutzer Zugriff auf die Fiori-App haben, aber ohne Zugriff auf die zugrunde liegenden Berechtigungen wäre er nicht in der Lage, eine Aktion auszuführen. Umgekehrt könnte ein Benutzer Zugriff auf die zugrunde liegenden Berechtigungen haben, aber ohne Zugriff auf die Fiori-App wäre seine Fähigkeit, sie auszuführen, eingeschränkt (es sei denn, es gibt einen alternativen Pfad wie eine klassische T-Code oder einen externen OData-Aufruf).

In der Praxis bedeutet dies, dass eine umfassende SoD-Analyse alle Pfade berücksichtigen muss: klassische Transaktionen, Fiori-Apps, OData-Services und auch externe Aufrufe (zum Beispiel über API-Integrationen). Tools, die SoD nur auf einer dieser Ebenen analysieren, riskieren, signifikante Risikoquellen zu übersehen.

3.3 Standardrollen und Business Catalogs

SAP liefert eine umfangreiche Bibliothek von Standardrollen und Business Catalogs für S/4HANA. Diese sind als Ausgangspunkt für Organisationen entworfen, die SoD-bewusste Rollendesigns implementieren wollen. Theoretisch sollten Standardrollen Anwendungsbereiche abdecken, in denen Funktionstrennung im Design eingebaut ist.

In der Praxis ist die Verwendung von Standardrollen ohne wesentliche Anpassung selten praktisch. Standardrollen sind oft zu breit (mehr Berechtigungen als nötig) oder zu eng (sie spiegeln nicht spezifische lokale Prozesse wider). Organisationen erstellen typischerweise ihre eigenen kundenspezifischen Rollen, die auf Standardrollen basieren oder von Grund auf neu entworfen werden.

Business Catalogs sind eine neuere Funktion, die in S/4HANA eingeführt wurde. Sie sind Sammlungen von Fiori-Apps, die nach Geschäftsbereich gruppiert sind und als Bausteine zum Konstruieren von Rollen verwendet werden können. Business Catalogs vereinfachen das Rollendesign, indem sie eine vorgefertigte Gruppierung verwandter Apps bereitstellen. Ihre Anpassung ist jedoch ebenfalls fast immer notwendig.

Eine wichtige Best Practice in der Welt von S/4HANA ist die Trennung der Rollen in zwei Ebenen: Berechtigungsrollen (die zugrunde liegende SAP-Berechtigungen enthalten) und Business Role Catalogs (die Fiori-Anwendungen enthalten). Diese Trennung erleichtert die Wartung und ermöglicht eine flexiblere Verwaltung. Sie erhöht jedoch auch die Komplexität der SoD-Analyse, da Konflikte über beide Ebenen analysiert werden müssen.

3.4 S/4HANA-spezifische Risiken

Mehrere Klassen von SoD-Risiken werden in der S/4HANA-Welt prominenter oder neu. Erstens, Fiori-Apps, die end-to-end-Prozesse konsolidieren. Eine App wie 'Bestellungen verwalten' kann mehrere klassische Transaktionen kombinieren - Erstellen, Genehmigen, Modifizieren, Anzeigen. Eine SoD-Analyse, die diese App nicht korrekt klassifiziert, kann verfehlen, dass ein Benutzer mit Zugriff auf diese App effektiv die volle Kontrolle über den Bestellungs-Lifecycle hat.

Zweitens, In-App-Berechtigungen und Variantenkonfigurationen. Einige Fiori-Apps haben interne Konfigurationsmöglichkeiten, die das Berechtigungsmodell beeinflussen können. Zum Beispiel kann eine Genehmigungs-App so konfiguriert werden, dass sie einem Benutzer ermöglicht, seine eigenen Anfragen zu genehmigen (was ein offensichtliches SoD-Versagen wäre). Diese Konfigurationsoptionen werden oft in der grundlegenden Berechtigungsanalyse übersehen.

Drittens, embedded analytics und KPI-Dashboards. S/4HANA integriert nativ analytische Funktionen, die Echtzeit-Datenzugriff bieten. Diese Funktionen können sensible Geschäftsinformationen offenlegen, die historisch über separate BI-Systeme mit eigenen Zugriffskontrollen verwaltet wurden. SoD-Programme müssen explizit Risiken berücksichtigen, die mit unbeabsichtigter Offenlegung sensibler Daten verbunden sind.

Viertens, Side-by-Side-Erweiterungen mit SAP BTP. S/4HANA wird häufig mit kundenspezifischen Erweiterungen erweitert, die auf der SAP Business Technology Platform laufen. Diese Erweiterungen haben ihre eigenen Berechtigungsmodelle und können auf S/4HANA-Daten über APIs zugreifen. Ein vollständiges SoD-Programm muss diese externen Komponenten im Risikobereich abdecken.

3.5 Migrationsstrategien und SoD

Organisationen, die von ECC zu S/4HANA migrieren, haben mehrere Strategien zur Verfügung: Brownfield (System-Conversion mit erhaltener Konfiguration und Daten), Greenfield (Neuimplementierung von Grund auf) oder Selective Data Transition (selektive Auswahl, was übertragen wird). Jede dieser Strategien hat unterschiedliche Auswirkungen auf das SoD-Programm.

Bei der Brownfield-Migration werden bestehende Rollen und Berechtigungen typischerweise erhalten, mit zusätzlichen Berechtigungen für neue Fiori-Apps. Dies ist die schnellste Strategie, hat aber den Nachteil, dass alle vorhandenen SoD-Probleme in das neue System übertragen werden. Es ist auch eine verpasste Gelegenheit, das Rollenmodell neu zu gestalten, indem die neuen Möglichkeiten von S/4HANA berücksichtigt werden.

Bei der Greenfield-Implementierung kann die Organisation das Rollenmodell von Grund auf neu gestalten. Dies ist eine bedeutende Gelegenheit, ein SoD-konformes Modell von Anfang an zu konstruieren. Sie erfordert jedoch erhebliche Anstrengungen und gute Disziplin, um zu vermeiden, dass die Implementierungsteams aus operativen Gründen zu denselben kompromittierten Mustern zurückkehren, die in Kapitel 1 beschrieben wurden.

Selective Data Transition befindet sich in der Mitte. Die Organisation kann wählen, welche Aspekte zu erhalten und welche neu zu gestalten sind. Dies kann ein guter Ansatz sein, um die SoD-Architektur in den problematischsten Bereichen neu zu gestalten, ohne den vollen Umfang einer Greenfield-Implementierung zu übernehmen.

Unabhängig von der Strategie sollte das SoD-Programm aktiv an der Migrationsplanung beteiligt sein, nicht reaktiv. Dies bedeutet, dass die SoD-Risikomatrix gegen den neuen Systemumfang abgebildet, das Rollendesign überprüft und Geschäftsprozessverantwortliche in Diskussionen über Zugriffskontrollen während der Migrationsphase einbezogen werden.

4.1 SAP GRC Access Control: Übersicht

SAP GRC Access Control (AC) ist das Flaggschiff-GRC-Tool von SAP und für viele Organisationen mit großem SAP-Footprint die Standardwahl. Es besteht aus mehreren integrierten Modulen: Access Risk Analysis (ARA) für SoD-Analyse, Emergency Access Management (EAM) für die Verwaltung temporärer privilegierter Zugriffe, Business Role Management (BRM) für das Rollendesign-Management und Access Request Management (ARM) für Workflow-basierte Zugriffsanfragen.

Die Stärke von SAP GRC AC ist die tiefe Integration mit dem SAP-Ökosystem. Es kennt das Berechtigungsmodell intim, kann komplexe Analysen über organisatorische Ebenen durchführen und unterstützt eine breite Palette von SAP-Systemen (ECC, S/4HANA, BW, SCM und andere). Für Organisationen mit großen, komplexen SAP-Implementierungen ist diese Tiefe schwer zu erreichen.

Die Schwäche von SAP GRC AC liegt in seiner Komplexität und Wartungslast. Die Implementierung erfordert dedizierte Berater, die Wartung erfordert spezialisierte Fähigkeiten, und die typische Konfiguration kann monatelange Anstrengung in Anspruch nehmen, bevor signifikante Ergebnisse erzielt werden. Aus der Sicht eines Endbenutzers ist die Benutzererfahrung oft als veraltet und nicht intuitiv beschrieben, insbesondere im Vergleich zu modernen SaaS-GRC-Plattformen.

Eine andere Frage ist die Skalierung der Lizenzkosten. SAP GRC AC wird typischerweise nach Benutzeranzahl lizenziert, was bei größeren Organisationen die Gesamtkosten erheblich erhöhen kann. Die Total Cost of Ownership umfasst auch Wartungskosten, Schulungen, Anpassungen und periodische Upgrades, die alle nicht-trivial sind.

4.2 Was SAP GRC AC gut macht

Trotz seiner Einschränkungen liefert SAP GRC AC in mehreren spezifischen Bereichen echten Wert. Erstens, die Tiefe der Analyse. Das ARA-Modul kann komplexe SoD-Analysen über alle aktiven Berechtigungen, organisatorische Ebenen und Stammdaten durchführen. Es bietet Visualisierungen und Drill-Down-Funktionen, die das Verständnis der Wurzelursachen erleichtern.

Zweitens, das EAM-Modul ist ein leistungsfähiger Mechanismus für die Verwaltung temporärer privilegierter Zugriffe (oft als Firefighter Access bezeichnet). Es unterstützt strukturierte Anfrage-Genehmigungs-Workflows, vollständiges Logging der durchgeführten Aktivitäten und periodische Überprüfungen. Für Organisationen mit großen IT-Operationen und vielen Notfallsituationen ist dies eine signifikante Funktionalität.

Drittens, die Integration mit anderen SAP-Tools und -Prozessen. SAP GRC AC arbeitet nativ mit SAP HR (für Mitarbeiterdaten), SAP Identity Management und anderen SAP-Komponenten zusammen. Es kann die Identitätshierarchien und organisatorischen Strukturen direkt nutzen, was die Workflow-Konfiguration vereinfacht.

Viertens, die etablierte Wissensbasis und Berater-Community. Es gibt eine bedeutende Anzahl von Beratern mit jahrelanger Erfahrung in SAP GRC AC, was die Implementierung und Wartung einfacher macht als bei selteneren Tools. Diese Community ist auch eine wertvolle Quelle für Best Practices und Problemlösungen.

4.3 Die Grenzen klassischer GRC-Tools

Trotz der oben beschriebenen Stärken stoßen klassische GRC-Tools auf grundlegende Einschränkungen, die in der modernen Geschäftsrealität immer relevanter werden. Erstens, ihr Modell ist primär für SAP-Welten entworfen. Organisationen, die SAP zusammen mit anderen Plattformen verwenden (Oracle, Workday, Salesforce, ServiceNow, kundenspezifische Anwendungen) finden, dass klassische SAP-GRC-Tools keinen vollständigen Blick auf das Risiko über das gesamte Anwendungsportfolio liefern.

Zweitens, die Geschwindigkeit der Veränderung. Klassische GRC-Tools wurden in einer Ära entworfen, in der die SAP-Konfiguration relativ stabil war und Änderungen seltener und vorhersehbarer waren. In der heutigen Welt der kontinuierlichen Bereitstellung neuer Fiori-Apps, agiler S/4HANA-Releases und schneller Anpassungen an Geschäftsanforderungen müssen GRC-Tools ebenso schnell reagieren können. Klassische Tools kämpfen häufig damit, mit dem Tempo der Veränderung Schritt zu halten.

Drittens, die Benutzererfahrung. Geschäftsbenutzer, einschließlich Geschäftsprozessverantwortliche und Manager, die Zugriffsanfragen genehmigen und periodische Überprüfungen durchführen müssen, erwarten eine moderne, intuitive Schnittstelle. Klassische GRC-Tools liefern oft Schnittstellen, die schwer zu erlernen sind und das Engagement der Geschäftsbenutzer einschränken.

Viertens, die Datenanalyse und Berichterstattung. Klassische Tools liefern standardisierte Berichte, aber moderne Organisationen wollen oft tiefere Analysen - Trendanalysen über die Zeit, Korrelationen mit anderen Geschäftsereignissen, vorhersagende Modellierung. Diese Funktionalitäten erfordern typischerweise zusätzliche BI-Tools und Datenintegrationen, die die Komplexität erhöhen.

4.4 Die Welle agiler GRC-Plattformen

Als Reaktion auf die oben beschriebenen Einschränkungen ist in den letzten Jahren eine neue Welle von GRC-Plattformen entstanden, die als 'agile GRC' oder 'modern GRC' bezeichnet werden. Diese Plattformen werden typischerweise als SaaS angeboten, haben moderne UIs und sind so konzipiert, dass sie schnell in mehreren Umgebungen eingesetzt werden können.

Funktionen, die diese Plattformen oft auszeichnen, umfassen: cloudnative Architektur, die schnelle Updates und Skalierung ermöglicht; intuitive Schnittstellen für Geschäftsbenutzer; integrierte Workflow-Engines, die für moderne agile Geschäftsprozesse entworfen sind; eingebaute Analysen und Visualisierungen; und Open-APIs für Integration mit anderen Tools.

Im SoD-Kontext bringen agile GRC-Plattformen mehrere Innovationen. Erstens, kontinuierliche Risikoanalyse - statt periodischer Batch-Analysen werden Risiken laufend neu berechnet, wenn sich Berechtigungen ändern. Zweitens, kontextbezogene Genehmigungsworkflows, die zusätzlichen Geschäftskontext liefern, anstatt nur die Berechtigungen aufzulisten, die genehmigt werden müssen. Drittens, eingebettete Schulungen und Risikobewusstsein im Genehmigungsprozess.

Aber moderne Plattformen haben auch Einschränkungen. Die Tiefe der SAP-Integration ist oft weniger ausgereift als bei SAP GRC AC. Die Methodik der Risikoanalyse kann weniger umfassend sein, insbesondere für komplexe Szenarien mit organisatorischen Ebenen und mehreren Berechtigungsquellen. Und für Organisationen mit großem SAP-Footprint kann der Übergang von SAP GRC AC zu einer agilen Plattform eine signifikante Migrations-Anstrengung sein.

4.5 Wie man wählt: SAP GRC AC vs. agile Plattformen

Die Wahl zwischen klassischem SAP GRC AC und einer agilen Plattform hängt von mehreren Faktoren ab. SAP GRC AC ist tendenziell die richtige Wahl, wenn die Organisation: einen großen, komplexen SAP-Footprint hat; bereits in SAP GRC AC oder anderen SAP-Tools investiert ist; tiefe Analyse über organisatorische Ebenen und komplexe Berechtigungsstrukturen benötigt; und über das Budget und die Fähigkeiten für die Wartung eines komplexen Tools verfügt.

Eine agile Plattform ist tendenziell die richtige Wahl, wenn die Organisation: ein heterogenes Anwendungsportfolio über SAP hinaus hat; eine starke Benutzererfahrung und schnelle Wertschöpfung priorisiert; nach schnellerer Bereitstellung und niedrigeren Total Cost of Ownership sucht; und ein moderneres, agileres GRC-Programm implementieren möchte.

In der Praxis wählen viele Organisationen einen hybriden Ansatz. SAP GRC AC kann für die tiefe SoD-Analyse innerhalb der SAP-Welt verwendet werden, während eine agile Plattform für übergreifende GRC-Funktionen wie Risikomanagement, Compliance-Tracking und Geschäftsprozesskontrollen verwendet wird. Dieser Ansatz kann das Beste beider Welten liefern, erhöht aber die Komplexität der Architektur und erfordert eine gute Integration zwischen den Tools.

Eine wichtige Frage, die bei der Wahl zu berücksichtigen ist, ist die langfristige Strategie. Wo wird die Organisation in 3-5 Jahren sein? Welche Anwendungen werden im Kernportfolio sein? Wie wird sich die SAP-Roadmap entwickeln (insbesondere SAP S/4HANA Cloud)? Die Wahl, die heute richtig ist, kann in einigen Jahren weniger optimal sein, daher ist es wichtig, eine Plattform zu wählen, die mit den langfristigen Bedürfnissen der Organisation übereinstimmt.

5.1 Was eine Risikomatrix wirklich ist

Eine SoD-Risikomatrix ist eine strukturierte Sammlung von Risikoregeln, von denen jede eine Kombination von Geschäftsaktionen definiert, die zusammen ein Betrugs- oder Fehlerrisiko darstellen. Eine Risikoregel hat typischerweise: eine eindeutige ID, einen beschreibenden Namen, eine Beschreibung des geschäftlichen Risikos, ein zugewiesenes Risikolevel (typischerweise hoch, mittel, niedrig) und eine Liste der konfligierenden Funktionen (oft als 'Risk Functions' bezeichnet).

Risk Functions sind Bausteine der Matrix. Eine Risk Function repräsentiert eine bestimmte Geschäftsaktion - zum Beispiel 'Lieferanten anlegen', 'Zahlungslauf ausführen' oder 'Wareneingang erfassen'. Jede Risk Function ist mit einer Reihe von SAP-Berechtigungen (Transaktionscodes, Fiori-Apps, Berechtigungsobjekte) verbunden, die ihre technische Implementierung darstellen.

Eine Risikoregel verbindet typischerweise zwei oder mehr Risk Functions. Zum Beispiel: 'Lieferanten anlegen + Zahlungslauf ausführen' ist eine Regel, die identifiziert, dass eine Person mit beiden Funktionen einen klassischen Betrugsmechanismus durchführen könnte. Wenn ein Benutzer effektiven Zugriff auf beide Risk Functions hat (über eine oder mehrere Rollen), wird er als in Konflikt stehend identifiziert.

Die Risikomatrix in einer typischen Organisation kann von Dutzenden bis zu mehreren Hundert Risikoregeln enthalten. Die Größe selbst ist kein Indikator für Qualität - eine Matrix mit 500 Regeln ist nicht unbedingt besser als eine mit 100. Was wichtig ist, ist, dass die enthaltenen Regeln tatsächliche Geschäftsrisiken widerspiegeln, korrekt auf SAP-Berechtigungen abgebildet sind und über die Zeit gewartet werden.

5.2 Geschäftliche Logik vs. technische Implementierung

Eine fundamentale Spannung im SoD-Matrix-Design ist das Gleichgewicht zwischen geschäftlicher Logik und technischer Implementierung. Auf der einen Seite muss die Matrix tatsächliche Geschäftsrisiken widerspiegeln - die Risiken, die ein Geschäftsbesitzer als bedeutsam und behandlungsbedürftig erkennt. Auf der anderen Seite muss sie auf die spezifische SAP-Konfiguration abgebildet werden, die für die Risikoanalyse technisch durchführbar sein muss.

Wenn diese Spannung gut gehandhabt wird, ist die Matrix sowohl für Geschäftsbenutzer als auch für technische Implementierer sinnvoll. Wenn sie schlecht gehandhabt wird, ist die Matrix entweder zu hochgradig (gut für Geschäftsbenutzer, aber technisch nicht durchführbar) oder zu technisch (technisch präzise, aber bedeutungslos für Geschäftsbenutzer).

Die übliche Falle ist, dass die Matrix als technisches Artefakt erstellt wird, ohne ausreichendes Engagement von Geschäftsbenutzern. Das Ergebnis ist eine Matrix, die Konflikte korrekt identifiziert, aber wenn ein Konflikt einem Geschäftsbenutzer zur Lösung präsentiert wird, fragt der Benutzer 'Warum ist das ein Problem?' und das technische Team kann diese Frage in geschäftlicher Sprache nicht beantworten. Das Vertrauen in das Programm sinkt, und die Lösungen werden oberflächlich (Mitigationen ohne tiefes Verständnis).

Die effektive Praxis ist, dass die Matrix in einer iterativen Diskussion zwischen den Geschäftsbesitzern und dem GRC-Team entworfen wird. Die Geschäftsbesitzer beschreiben die Geschäftsrisiken in ihrer Sprache. Das GRC-Team übersetzt diese in SAP-Berechtigungen und bestätigt die technische Durchführbarkeit. Anschließend werden die Risiken mit der Matrix gegen tatsächlich aktive Zugriffsdaten validiert, um zu sehen, ob die Regeln in der Praxis sinnvolle Ergebnisse liefern.

5.3 Risikolevel und Priorisierung

Nicht alle SoD-Konflikte sind gleich. Eine Risikomatrix sollte ein klares System zur Priorisierung haben - typischerweise drei oder vier Risikolevel (kritisch/hoch/mittel/niedrig oder ähnliche Konventionen). Diese Levels helfen Geschäftsbesitzern und GRC-Teams, ihre Aufmerksamkeit auf das zu konzentrieren, was wirklich wichtig ist.

Die Kriterien für die Risikobewertung umfassen typischerweise mehrere Faktoren: das potenzielle finanzielle Auswirkungspotenzial des Risikos, die Wahrscheinlichkeit, dass es ausgenutzt wird, das Vorhandensein anderer Kontrollen, die das Risiko mildern können, und regulatorische Implikationen. Ein Konflikt, der einen direkten Geldverlust ermöglichen kann (zum Beispiel Lieferanten anlegen + Zahlungslauf ausführen), wird typischerweise als kritisch eingestuft. Ein Konflikt, der hauptsächlich Reporting-Risiken darstellt, kann als niedriger eingestuft werden.

Die Priorisierung ist wichtig für mehrere praktische Gründe. Erstens, ressourcenbasierte. GRC-Teams und Geschäftsbesitzer haben begrenzte Zeit, um Konflikte zu lösen. Wenn alle Konflikte gleich behandelt werden, werden die wirklich wichtigen oft im Rauschen verloren gehen. Zweitens, regulatorisch. Bei SOX-Audits sind kritische Konflikte diejenigen, die das Audit-Team genau prüft, und ihre Lösung ist besonders wichtig. Drittens, geschäftlich. Einige Konflikte können vollständig akzeptabel sein, wenn andere Kontrollen vorhanden sind, während andere unabhängig von zusätzlichen Kontrollen eine Lösung erfordern.

Eine wichtige Best Practice ist, dass Risikolevel über die Zeit überprüft werden. Was vor fünf Jahren als kritisch eingestuft war, ist heute aufgrund veränderter Geschäftskontexte, neuer Bedrohungslandschaften oder regulatorischer Änderungen möglicherweise weniger kritisch (oder umgekehrt). Die Überprüfung der Risikolevel sollte Teil des periodischen Matrix-Wartungszyklus sein.

5.4 Mapping auf SAP-Berechtigungen

Sobald die Risk Functions in geschäftlicher Sprache definiert sind, müssen sie auf SAP-Berechtigungen abgebildet werden. Dies ist sowohl eine technische als auch eine analytische Arbeit. Sie erfordert ein tiefes Verständnis der SAP-Konfiguration, des Berechtigungsmodells und der Geschäftsprozesse.

Das Mapping erfolgt typischerweise auf drei Ebenen. Erstens, auf der Ebene der Transaktionscodes. Welche T-Codes ermöglichen die Ausführung dieser Risk Function? Dies ist die einfachste Ebene und für die meisten klassischen ECC-Risiken ausreichend.

Zweitens, auf der Ebene der Fiori-Apps. Welche Fiori-Apps ermöglichen die Ausführung dieser Risk Function in S/4HANA? Dies erfordert ein Inventar der bereitgestellten Fiori-Apps und ihre Verbindung zu den zugrunde liegenden Geschäftsfunktionen.

Drittens, auf der Ebene der Berechtigungsobjekte und Feldwerte. Für präzisere Analysen, insbesondere für Risiken, die mit der Stammdatenverwaltung oder dem Customizing verbunden sind, muss das Mapping bis auf die Ebene spezifischer Berechtigungsobjekte und ihrer Feldwerte hinabsteigen. Zum Beispiel: 'Lieferanten anlegen' ist nicht nur die XK01-Transaktion, sondern auch spezifische Werte des F_LFA1_BEK-Berechtigungsobjekts und ähnliche.

Eine wichtige technische Frage ist das Vorhandensein von Z-Transaktionen - kundenspezifische Transaktionen, die typischerweise mit dem Z- oder Y-Präfix benannt werden. Diese Transaktionen werden oft im SoD-Mapping übersehen, da sie nicht in den Standard-Templates erscheinen. Aber sie können den Zugriff auf riskante Funktionen ermöglichen - manchmal sogar geschickter konstruiert, um Standardkontrollen zu umgehen. Ein vollständiges SoD-Mapping muss diese kundenspezifischen Transaktionen umfassen.

Die ständige Herausforderung ist die Vollständigkeit. SAP ist eine extrem reichhaltige Umgebung mit Tausenden von Transaktionen, und für jede Risk Function gibt es typischerweise mehrere Pfade, durch die ein Benutzer sie ausführen kann. Vollständige Pfade zu finden ist eine schwierige analytische Arbeit, und einige Pfade werden in den ersten Analysen immer fehlen. Daher sollte das Mapping als kontinuierlich verbessert angesehen werden, mit periodischen Überprüfungen und Updates basierend auf realer Datenanalyse und neu entdeckten Pfaden.

5.5 Wartung und Evolution der Matrix

Eine SoD-Matrix ist niemals fertig. Sie muss kontinuierlich weiterentwickelt werden, wenn sich das Geschäft, die SAP-Konfiguration und die regulatorische Landschaft ändern. Eine gut gepflegte Matrix wird mindestens jährlich überprüft und häufiger aktualisiert, wenn signifikante Änderungen auftreten.

Auslöser für Matrix-Updates umfassen: SAP-Releases (insbesondere große S/4HANA-Updates, die neue Fiori-Apps einführen); Akquisitionen oder Veräußerungen, die das Geschäftsportfolio verändern; Geschäftsprozessreorganisationen, die die Organisationsstruktur ändern; neue regulatorische Anforderungen oder Audit-Findings, die zusätzliche Risiken hervorheben; und kundenspezifische Entwicklungen, die neue Z-Transaktionen oder kundenspezifische Fiori-Apps einführen.

Der Wartungsprozess sollte klar definierte Eigentümer haben. Wer ist verantwortlich für das Hinzufügen neuer Regeln? Wer überprüft die bestehenden Regeln? Wer entscheidet über Änderungen der Risikolevel? In gut funktionierenden Programmen ist dies typischerweise ein gemeinsames Eigentum zwischen dem GRC-Team und den Geschäftsprozessverantwortlichen, mit klaren Eskalationspfaden bei Meinungsverschiedenheiten.

Eine spezifische Praxis ist die periodische Validierung der Matrix gegen aktuelle SoD-Konfliktdaten. Wenn eine Regel niemals einen Konflikt produziert, bedeutet das, dass sie effektiv obsolet ist oder dass das Mapping unvollständig ist? Wenn eine Regel zu viele Konflikte produziert, ist sie zu breit definiert oder spiegelt sie ein echtes systemisches Problem im Rollendesign wider? Diese Fragen können die Matrix-Wartung in eine kontinuierliche Verbesserung umwandeln.

6.1 Zugriffsanforderungs-Workflow mit SoD-Prüfungen

Der erste Verteidigungspunkt im SoD-Lifecycle ist der Zugriffsanforderungsprozess. Wenn ein Benutzer einen neuen Zugriff (für sich selbst oder eine andere Person) anfordert, sollte das System diese Anfrage gegen die SoD-Matrix überprüfen, bevor er gewährt wird. Wenn die Anfrage einen Konflikt erstellen würde, sollte sie blockiert oder in einen Eskalations-Workflow gesendet werden.

Diese Voraus-Prüfung verhindert die Akkumulation von Konflikten an der Quelle. Das ist viel effektiver als reaktive Bereinigungen, bei denen Konflikte erst nach ihrer Entstehung identifiziert werden. Die organisatorische Disziplin, alle Zugriffsanfragen durch einen kontrollierten Workflow zu leiten, ist eine grundlegende Voraussetzung dafür.

In der Praxis erfordert dies Engagement von Geschäftsmanagern, die typischerweise eine Genehmigungsrolle in Workflows haben. Wenn die Anfrage einen potenziellen Konflikt aufweist, sollte das System dem Manager klare geschäftliche Informationen über das Risiko und mögliche Lösungen liefern: Den vorgeschlagenen Zugriff modifizieren, eine kompensierende Kontrolle hinzufügen, an einen höherrangigen Genehmigenden eskalieren oder die Anfrage ablehnen.

Die effektive Praxis ist, dass die Workflow-Informationen für Manager so präsentiert werden, dass sie sinnvoll sind. Statt einer technischen Auflistung von Berechtigungsobjekten sollte der Manager sehen: 'Dieser Zugriff würde einen Konflikt mit dem aktuellen Zugriff des Benutzers darstellen, da er sowohl Lieferanten anlegen als auch Zahlungen genehmigen könnte. Dies ist ein kritisches Risiko, weil...' Diese geschäftliche Übersetzung ist es, was Manager dazu bringt, fundierte Entscheidungen zu treffen.

6.2 Periodische Überprüfungen

Trotz der besten Workflow-Disziplin werden im Laufe der Zeit SoD-Konflikte akkumulieren. Manager können während des Rauschens routinemäßiger Genehmigungen Risiken übersehen. Mitarbeiter können die Rollen wechseln, ohne dass alte Berechtigungen entfernt werden. Geschäftsprozesse können sich ändern, sodass zuvor akzeptierte Kombinationen jetzt problematisch sind. Aus diesen Gründen sind periodische Überprüfungen notwendig.

Eine effektive periodische Überprüfung hat mehrere Merkmale. Erstens, sie ist gut definiert. Es ist klar, welche Population überprüft wird, wer der Überprüfer ist, welche Informationen ihnen präsentiert werden und welche Aktionen sie ausführen können (genehmigen, ablehnen, akzeptieren mit Mitigation). Zweitens, sie ist risikofokussiert. Die Aufmerksamkeit der Überprüfer ist auf die Bereiche mit dem höchsten Risiko fokussiert, nicht gleichmäßig über alle Berechtigungen verteilt.

Drittens, sie ist kontinuierlich, nicht ein jährliches Megaprojekt. Statt einer jährlichen Überprüfung aller Berechtigungen in einer dreiwöchigen Übung können Überprüfungen über das Jahr verteilt werden - zum Beispiel ein Quartal pro Geschäftsbereich, oder kontinuierliche Rolling-Reviews mit kleineren Stichproben. Dies reduziert die Spitzen-Arbeitsbelastung und führt zu größerer Aufmerksamkeit pro Überprüfung.

Viertens, sie ist mit dem Remediation-Prozess verbunden. Wenn ein Manager einen Zugriff in der Überprüfung ablehnt, sollte das System automatisch einen Remediation-Workflow zur Entfernung dieses Zugriffs auslösen. Wenn der Manager den Zugriff akzeptiert, aber eine Mitigation anwendet, sollte diese Mitigation in das Mitigation-Register hinzugefügt werden. Diese Verbindungen sind es, die Überprüfungen wirklich aktionierbar machen.

6.3 Kompensierende Kontrollen

Nicht alle SoD-Konflikte können vollständig durch Rollen-Anpassungen beseitigt werden. Es gibt Geschäftsszenarien, in denen die Funktionstrennung praktisch nicht möglich ist - zum Beispiel in einem kleinen Team, wo eine Person mehrere Rollen ausführt. In diesen Fällen sind kompensierende Kontrollen die Antwort.

Eine kompensierende Kontrolle ist eine sekundäre Kontrolle, die das mit einem SoD-Konflikt verbundene Risiko mildert. Beispiele umfassen: detaillierte Audit-Trail-Überprüfungen für betroffene Transaktionen; obligatorische Vier-Augen-Genehmigung für bestimmte Aktionen; periodische Geschäftsabstimmungen, die Anomalien identifizieren; oder Sieben-für-Sieben-Reporting an höhere Manager.

Die Effektivität einer kompensierenden Kontrolle hängt von ihrer korrekten Konzeption und Ausführung ab. Eine schlecht konzipierte Kontrolle - zum Beispiel eine 'Überprüfung von Berichten', die niemand tatsächlich liest - bietet die Illusion von Schutz ohne tatsächliche Risikominderung. Eine gut konzipierte Kontrolle hat einen klaren Eigentümer, regelmäßige Ausführung, dokumentierte Beweise und periodische Wirksamkeitsprüfungen.

Die größte Falle im Management kompensierender Kontrollen ist die Akkumulation. Wenn jeder ungelöste Konflikt eine kompensierende Kontrolle hinzufügt, kann die Liste über Hunderte von Einträgen wachsen, von denen jeder seine eigenen Eigentümer, Ausführungsfrequenz und Wirksamkeitsprüfungen erfordert. Aus diesem Grund sollte das Hinzufügen einer kompensierenden Kontrolle die Ausnahme sein, nicht die Standardlösung. Die erste Wahl sollte immer die Behebung der Rolle sein. Eine kompensierende Kontrolle sollte hinzugefügt werden, wenn die Behebung nicht praktisch ist und das Risiko-Mitigation echte geschäftliche Aktion erfordert.

6.4 Notfallzugriff und Privilegmanagement

Eine spezifische Klasse des Zugriffs, die spezielle Behandlung benötigt, ist der Notfallzugriff - die Möglichkeit, vorübergehend privilegierte Zugriffe zu erlangen, um operative Notfälle zu lösen. Klassische Beispiele umfassen die Behebung eines fehlerhaften Job in der Produktion, die Lösung eines kritischen Geschäftsproblems außerhalb der Geschäftszeiten oder die Notfallunterstützung während eines Systemausfalls.

Notfallzugriff ist eine inhärente Spannung im SoD-Programm. Auf der einen Seite ist es eine geschäftliche Notwendigkeit - es wird Notfälle geben, und das Geschäft braucht eine schnelle Lösung. Auf der anderen Seite ist privilegierter Zugriff per Definition ein hohes Risiko und sollte streng kontrolliert werden. Wie löst man diese Spannung?

Die Standardpraxis ist die Implementierung eines 'Firefighter'-Mechanismus mit drei Hauptkomponenten. Erstens, ein vordefinierter Pool von Firefighter-IDs mit privilegiertem Zugriff, der vorab konfiguriert ist und Standard-Benutzern nicht zugewiesen ist. Zweitens, ein strukturierter Anfrage-Genehmigungs-Workflow, durch den ein Benutzer einen Firefighter-ID-Anschluss vorübergehend anfordern kann, mit dokumentierter Geschäftsbegründung. Drittens, vollständiges Logging und Überprüfung der während der Firefighter-Sitzung durchgeführten Aktionen.

Die Effektivität dieses Mechanismus hängt von der Disziplin des Überprüfungsprozesses ab. Wenn niemand die Firefighter-Logs überprüft, wird privilegierter Zugriff effektiv ohne Kontrolle ausgenutzt. Effektive Programme haben designierte Überprüfer (typischerweise Geschäftsprozessverantwortliche oder GRC-Team), die innerhalb eines klar definierten Zeitraums (typischerweise wenige Tage) nach der Firefighter-Sitzung die durchgeführten Aktionen überprüfen, bestätigen, dass sie der vorgesehenen Geschäftsbegründung entsprachen, und alle Anomalien melden.

7.1 Kritische Berechtigungen und sensible Funktionen

Über klassische SoD hinaus, die zwei oder mehr Funktionen vergleicht, gibt es eine Klasse von Berechtigungen, die unabhängig von Kombinationen so kritisch sind, dass ihr Besitz strenge Kontrolle erfordert. Diese werden typischerweise 'kritische Berechtigungen' oder 'Critical Authorizations' genannt.

Beispiele umfassen: SAP-Berechtigungen, die das Berechtigungsmodell selbst ändern können (PFCG, SU01); Berechtigungen, die das Customizing in der Produktion ermöglichen (SE16N mit Schreibzugriff, SM30); Berechtigungen, die Stammdaten direkt ändern können (Tabellenpflege mit Schreibzugriff); Berechtigungen, die direkten Datenbankzugriff bieten (S_TABU_DIS mit Schreibzugriff in sensiblen Tabellen); und Berechtigungen, die transaktionale Kontrollen umgehen können (Debug-Berechtigungen, RFC-Berechtigungen).

Die Kontrolle dieser Berechtigungen ist oft strenger als die klassische SoD. Sie können nur für sehr begrenzte Nutzergruppen verfügbar sein, sie erfordern oft persönliche Genehmigung durch das Senior Management und ihre Nutzung wird oft auf Sitzungsebene überwacht. In SAP GRC AC und ähnlichen Tools werden sie typischerweise als separate Kategorie von SoD-Konflikten verwaltet (mit dem Begriff 'Critical Action Conflicts').

Eine wichtige Frage in S/4HANA ist die Identifizierung kritischer Fiori-Apps. Standard-SAP-Vorlagen umfassen Listen kritischer T-Codes, aber diese werden oft nicht in äquivalente Fiori-Apps übersetzt. Organisationen müssen ihre eigene Liste kritischer Fiori-Apps konstruieren, indem sie die zugrunde liegenden Funktionen analysieren, die diese Apps ausführen.

7.2 Z-Transaktionen und kundenspezifische Entwicklung

Z-Transaktionen sind kundenspezifische Entwicklungen, die typischerweise mit dem Z- oder Y-Präfix benannt werden, um sie von Standard-SAP-Funktionalitäten zu unterscheiden. Sie werden für eine Vielzahl von Zwecken erstellt: Anpassungen an spezifische Geschäftsanforderungen, Integration mit anderen Systemen, lokale regulatorische Anforderungen und manchmal als Workaround für Standardlimitationen.

Aus SoD-Sicht sind Z-Transaktionen oft ein blinder Fleck. Die meisten Standard-SoD-Templates konzentrieren sich auf Standard-SAP-Transaktionen, ohne kundenspezifische Z-Transaktionen abzudecken. Aber Z-Transaktionen können die gleiche oder größere Geschäftsfähigkeit haben - eine schlecht entworfene Z-Transaktion kann zum Beispiel Standard-SAP-Berechtigungsobjekte umgehen oder mehrere geschäftliche Funktionen kombinieren, die getrennt sein sollten.

Die Best Practice ist die regelmäßige Inventarisierung aller Z-Transaktionen und ihrer Klassifizierung im SoD-Mapping. Für jede Z-Transaktion sollten folgende Fragen beantwortet werden: Welche Geschäftsfunktion führt sie aus? Welche Standard-SAP-Berechtigungsobjekte überprüft sie? Welche Risk Functions in der SoD-Matrix sollte sie repräsentieren? Diese Analyse erfordert die Zusammenarbeit zwischen dem GRC-Team und den ABAP-Entwicklungs- und Funktions-Teams.

Eine ähnliche Frage ist die kundenspezifische Fiori-App-Entwicklung. S/4HANA ermöglicht die Erstellung kundenspezifischer Fiori-Apps, die auf benutzerdefinierten OData-Services basieren. Diese Apps können sehr leistungsstark sein, aber sie erfordern dieselbe Analyse wie Standard-Apps - welche Geschäftsfunktion sie ausführen und wie sie in der SoD-Matrix klassifiziert werden sollten.

7.3 RFC-Verbindungen und Service-Konten

RFC (Remote Function Call) ist ein Mechanismus, den SAP für die Kommunikation zwischen Systemen verwendet - zwischen SAP-Systemen, zwischen SAP und externen Anwendungen oder zwischen SAP-Komponenten. RFC-Verbindungen verwenden typischerweise Service-Konten (technische Benutzer), die spezielle Berechtigungen haben, um die Kommunikation zu ermöglichen.

Service-Konten sind aus mehreren Gründen eine SoD-Sicherheitsherausforderung. Erstens haben sie oft sehr breite Berechtigungen - manchmal SAP_ALL oder ähnliche Profile - um sicherzustellen, dass die Integration nicht aufgrund von Berechtigungsproblemen ausfällt. Zweitens werden ihre Passwörter selten geändert und können von mehreren Mitarbeitern bekannt sein. Drittens werden sie nicht in standardmäßigen Benutzer-orientierten SoD-Analysen abgedeckt, weil sie keine 'normalen' Benutzer sind.

Best Practices für Service-Konten umfassen: Konfiguration der Konten als 'System' oder 'Service'-Benutzertyp, um menschliche Anmeldungen zu verhindern; Einschränkung der RFC-Berechtigungen auf nur die Funktionen, die für die Integration erforderlich sind, statt SAP_ALL zu verwenden; regelmäßige Passwortrotation oder noch besser, Wechsel zu zertifikatbasierter Authentifizierung; und Erweiterung der SoD-Analyse, um Service-Konten als separate Population zu umfassen.

RFC-Berechtigungen selbst sind ebenfalls eine SoD-Komponente. Die Möglichkeit, RFC-Aufrufe zu autorisieren (S_RFC, S_RFCACL Berechtigungsobjekte) kann verwendet werden, um Funktionen aus einem externen System auszuführen, das die ursprünglichen Berechtigungen des Benutzers umgeht. Strenge Kontrolle der RFC-Berechtigungen ist Teil eines guten SoD-Programms.

8.1 Das Fünf-Stufen-Reifegradmodell

Wir definieren ein Fünf-Stufen-Reifegradmodell für SoD-Programme: Initial (Stufe 1), Compliance-Driven (Stufe 2), Strukturiert (Stufe 3), Integriert (Stufe 4) und Optimiert (Stufe 5). Jede Stufe hat charakteristische Merkmale in vier Dimensionen: Governance, Prozess, Technologie und Kultur.

Stufe 1 - Initial: Es gibt kein formales SoD-Programm. Es gibt keine dokumentierte SoD-Matrix oder sie ist veraltet und unbenutzt. Zugriffsanfragen werden ad-hoc ohne strukturierte Genehmigung verwaltet. Periodische Überprüfungen werden nicht durchgeführt oder werden nur als Reaktion auf Audit-Findings durchgeführt. Die SoD-Risiken werden vom IT-Team verwaltet, ohne Engagement vom Geschäft.

Stufe 2 - Compliance-Driven: Es gibt eine SoD-Matrix, die hauptsächlich für Compliance-Zwecke gepflegt wird. Periodische Überprüfungen erfolgen jährlich, typischerweise vor externen Audits. Es gibt einen formalen Zugriffsanfrage-Genehmigungsprozess, aber er ist primär auf das Bearbeiten von Anfragen ausgerichtet, nicht auf Risikomanagement. Das GRC-Team ist klein, und die Verantwortlichkeit liegt hauptsächlich bei IT.

Stufe 3 - Strukturiert: Es gibt ein formales SoD-Programm mit definierten Rollen und Verantwortlichkeiten. Die SoD-Matrix ist gut definiert und regelmäßig gepflegt. GRC-Tools werden für die Risikoanalyse und das Workflow-Management verwendet. Periodische Überprüfungen werden quartalsweise oder häufiger durchgeführt. Geschäftsmanager sind in den Genehmigungsprozess involviert und verstehen ihre Verantwortlichkeit für Zugriffsrisiken.

Stufe 4 - Integriert: SoD ist in Geschäftsprozesse integriert. Die SoD-Matrix wird kontinuierlich basierend auf realen Risikomustern weiterentwickelt. Es gibt eine starke Geschäftseigentümerschaft der Risiken. Die Zugriffsanfragen umfassen integrierte Risikobewertungen, die in geschäftlicher Sprache präsentiert werden. Die periodischen Überprüfungen sind kontinuierlich und risikofokussiert. Trends und Muster werden über die Zeit verfolgt und in Strategiegespräche integriert.

Stufe 5 - Optimiert: Das SoD-Programm ist ein strategisches Werkzeug für das Geschäft. Risikoeinblicke aus dem SoD-Programm beeinflussen Geschäftsprozessdesigns. Es gibt eine starke Verbindung zwischen SoD und anderen GRC-Disziplinen (operatives Risiko, Compliance, Internal Audit). Fortgeschrittene Analysen wie KI-basierte Anomaliedetektion werden zur Identifizierung neuer Risiken verwendet. Die SoD-Reife wird als Wettbewerbsvorteil betrachtet.

8.2 Wie man Reife bewertet

Die Bewertung der Reife sollte über alle vier Dimensionen erfolgen: Governance, Prozess, Technologie und Kultur. Ein gemeinsamer Fehler besteht darin, sich nur auf die technische Dimension zu konzentrieren - wenn die Organisation SAP GRC AC implementiert hat, glauben Sie, sie ist auf Stufe 4 oder 5. Aber die Technologie selbst ist nur eine der Dimensionen.

Die Governance-Bewertung umfasst Fragen wie: Gibt es einen formalen Eigentümer für das SoD-Programm? Gibt es ein Governance-Forum, das das Programm überwacht? Sind die Rollen und Verantwortlichkeiten klar definiert? Wie wird das Programm in der Organisationshierarchie verbunden?

Die Prozessbewertung umfasst Fragen wie: Welche Prozesse sind definiert (Zugriffsanfragen, periodische Überprüfungen, Konfliktbehandlung)? Wie regelmäßig werden sie ausgeführt? Wie werden Ausnahmen behandelt? Wie werden Ergebnisse gemessen und berichtet?

Die Technologiebewertung umfasst Fragen wie: Welche GRC-Tools werden verwendet? Wie breit ist ihre Abdeckung über das Anwendungsportfolio? Wie integriert sind sie mit anderen Geschäftssystemen? Wie automatisiert sind die Schlüsselprozesse?

Die Kulturbewertung umfasst Fragen wie: Wie verstehen Geschäftsmanager die SoD-Risiken? Wie wichtig ist das Senior Management das Programm? Was ist das Bewusstsein bei normalen Mitarbeitern? Wie reagiert die Organisation, wenn Konflikte oder Risiken identifiziert werden?

Die Beantwortung dieser Fragen kann durch Selbstbewertungs-Workshops, Mitarbeiterinterviews, Dokumentenüberprüfung und Geschäftsleistungs-Analyse erfolgen. Das Ergebnis ist eine ehrliche Bewertung des aktuellen Standes, die als Grundlage für die Verbesserungsplanung dient.

8.3 Der Pfad zur Reife

Der Übergang zwischen den Reifestufen erfolgt nicht von Nacht auf Tag. Typischerweise erfordert der Übergang von einer Stufe zur nächsten 12-24 Monate fokussierter Anstrengung mit konsequenter Senior-Management-Unterstützung. Versuche, mehrere Stufen gleichzeitig zu überspringen, scheitern in der Regel.

Der Übergang von Stufe 1 zu Stufe 2 erfordert hauptsächlich die Einführung formaler Strukturen: Erstellung einer dokumentierten SoD-Matrix, Definition formaler Zugriffsanfrage-Prozesse, Einführung jährlicher Überprüfungen. Dies ist oft durch Audit-Findings oder regulatorische Anforderungen motiviert.

Der Übergang von Stufe 2 zu Stufe 3 erfordert tiefere Strukturierung: Implementierung eines GRC-Tools, Erweiterung der periodischen Überprüfungsfrequenz, Engagement der Geschäftsmanager im Genehmigungsprozess. Dies erfordert oft eine Investition in dedizierte GRC-Team-Ressourcen.

Der Übergang von Stufe 3 zu Stufe 4 erfordert eine fundamentale Veränderung in der Art und Weise, wie das Programm wahrgenommen wird - von einer technischen Aktivität zu einer Geschäftsdisziplin. Dies erfordert kulturelle Veränderung, intensives Engagement der Geschäftsleitung und Reframing des Programms in geschäftlicher Sprache.

Der Übergang von Stufe 4 zu Stufe 5 ist die anspruchsvollste und involviert die Integration des Programms in die breitere Geschäftsstrategie. Dies ist ein Niveau, das wenige Organisationen erreichen, und in der Regel erfordert mehrere Jahre konsequenter Reife auf Stufe 4 vor diesem Übergang.

9.1 Was funktioniert

Starten Sie mit den höchsten Risiken. Wenn das Programm neu ist, versuchen Sie nicht, alle Risiken auf einmal zu adressieren. Konzentrieren Sie sich auf die kritischen Konflikte - typischerweise die direkten Geld- und Betrugsrisiken. Sobald diese unter Kontrolle sind, erweitern Sie schrittweise auf mittlere und dann niedrigere Risiken.

Engagieren Sie die Geschäftsleitung von Anfang an. SoD ist keine technische Disziplin - es ist eine Geschäftsdisziplin. Wenn das Programm als technisch wahrgenommen wird, wird es schwer sein, das nötige Engagement und die Ressourcen zu erhalten. Frame das Programm in geschäftlicher Sprache: Risikomanagement, Verlustprävention, regulatorische Compliance.

Investieren Sie in die Übersetzung von Risikoregeln in Geschäftssprache. Eine SoD-Regel, die in technischer Sprache präsentiert wird, ist für Geschäftsmanager bedeutungslos. Wenn Sie einen Konflikt zur Lösung präsentieren, sagen Sie: 'Wir haben festgestellt, dass [Benutzer] sowohl Lieferantenkonten anlegen als auch Zahlungen genehmigen kann. Dies ist ein Risiko, weil [konkrete geschäftliche Konsequenz]. Wir empfehlen [konkrete Maßnahme].'

Bauen Sie das Programm iterativ auf. Versuchen Sie nicht, das perfekte Programm von Anfang an zu entwerfen. Beginnen Sie mit einer einfachen, aber funktionierenden Version, sammeln Sie Erfahrung, identifizieren Sie Probleme und verbessern Sie sie. Iterative Verbesserung ist effektiver als der Versuch, die perfekte Lösung im ersten Schritt zu entwerfen.

Konzentrieren Sie sich auf die Wurzelursachen, nicht auf die Symptome. Wenn dieselben Konflikte wiederholt aufkommen, gibt es ein systemisches Problem im Rollendesign oder im Geschäftsprozess. Adressieren Sie die Wurzelursache, nicht nur die Symptome. Dies erfordert oft tiefere Geschäftsgespräche, ist aber langfristig viel effektiver.

9.2 Was schief geht

Übermäßige Abhängigkeit von Templates. Standard-SoD-Templates können ein guter Ausgangspunkt sein, aber sie spiegeln nicht die spezifischen Risiken Ihrer Organisation wider. Wenn die Matrix unverändert aus dem Template übernommen wird, ohne organisatorische Spezifika zu integrieren, wird sie irrelevante Konflikte identifizieren und tatsächliche Risiken verfehlen.

Mitigationen als Standardlösung. Wenn die Standardantwort auf Konflikt 'kompensierende Kontrolle hinzufügen' ist, wächst das Mitigationen-Register außer Kontrolle, und tatsächliche Lösungen werden nie angegangen. Mitigationen sollten die Ausnahme sein, nicht die Norm.

Berichterstattung in technischer Sprache an das Management. Wenn der Senior Management berichten Sie technische Metriken (Anzahl der Konflikte pro System, Anzahl der gelösten Konflikte), wird das Programm als technische Aktivität wahrgenommen. Berichten Sie in geschäftlicher Sprache: welche Geschäftsrisiken bestehen, welche reduziert wurden, welche Geschäftsereignisse zu Veränderungen geführt haben.

Übersehen kundenspezifischer Entwicklungen. Z-Transaktionen und kundenspezifische Fiori-Apps sind häufige Risikoquellen, die in standardmäßigen SoD-Analysen übersehen werden. Bauen Sie regelmäßige Prüfungen kundenspezifischer Entwicklungen in den SoD-Wartungsprozess ein.

Behandlung der Migration als reines IT-Projekt. S/4HANA-Migrationen sind eine signifikante Gelegenheit, das Rollenmodell zu überprüfen und SoD-konform zu gestalten. Wenn die Migration als reines IT-Projekt durchgeführt wird, ohne SoD-Beteiligung, werden Sie wahrscheinlich am Ende ein Modell haben, das die alten SoD-Probleme widerspiegelt.

10.1 Die Auswirkungen der KI

Künstliche Intelligenz - sowohl in Form klassischer Machine-Learning-Modelle als auch in Form generativer KI - verändert das GRC-Bild auf mehrere Arten. Erstens kann KI verwendet werden, um SoD-Analyse zu verbessern. Anomalieerkennungsmodelle können ungewöhnliche Berechtigungsmuster identifizieren, die menschliche Reviewer möglicherweise übersehen würden. Vorhersagemodelle können identifizieren, welche Benutzer am wahrscheinlichsten in Zukunft Konflikte erzeugen werden.

Zweitens verbessert KI die Risikobewertung. Eine traditionelle Risikomatrix bewertet Risiken basierend auf der Berechtigungskombination, aber sie berücksichtigt nicht den Geschäftskontext - wie viele Transaktionen führt der Benutzer aus, mit welchen Werten, an welchen Tagen und Stunden. KI-Modelle können diesen Kontext einfließen lassen und einen viel präziseren Risiko-Score generieren.

Drittens verändert KI die geschäftliche Realität, die wir schützen müssen. Autonome Agenten - KI-Systeme, die Geschäftsentscheidungen ohne menschliches Eingreifen treffen - werden in den kommenden Jahren bedeutsamer werden. Diese Agenten benötigen ihre eigenen Berechtigungen, und ihre Aktionen müssen aus SoD-Sicht bewertet werden. Was bedeutet 'Funktionstrennung', wenn der 'Funktionsausführer' ein KI-Modell ist? Wie überwachen wir das KI-Verhalten? Dies sind Fragen, denen sich SoD-Programme in den kommenden Jahren stellen müssen.

10.2 Cloud und SaaS

Der Übergang zur Cloud verändert das SoD-Bild auf mehrere Arten. Erstens verbreitert sich das Anwendungsportfolio. Eine moderne Organisation kann SAP S/4HANA Cloud, Workday, Salesforce, ServiceNow, Microsoft 365, Zoom, Slack und Dutzende anderer Cloud-Anwendungen verwenden. Jede dieser Anwendungen hat ihr eigenes Berechtigungsmodell und kann SoD-Risiken darstellen.

Zweitens beschleunigt sich die Geschwindigkeit der Veränderung. Cloud-Anwendungen erhalten häufig Aktualisierungen - manchmal monatlich oder häufiger. Diese Aktualisierungen können neue Funktionen, neue Berechtigungen und potenziell neue SoD-Risiken einführen. SoD-Programme müssen schnell genug sein, um damit Schritt zu halten.

Drittens verändert die Cloud das traditionelle Modell der internen Kontrolle. Im On-Premise-Modell hat die Organisation die volle Kontrolle über die Anwendungskonfiguration. Im SaaS-Modell ist die Konfiguration teilweise vom Anbieter kontrolliert, und die Organisation kann sie nicht immer nach ihren Vorlieben modifizieren. Dies erfordert ein Umdenken bei einigen Kontrollannahmen.

Schließlich öffnet die Cloud neue Identitätsmanagement-Modelle - Identity Federation, Single Sign-On, mit privilegiertem Zugriff verbundene SaaS-Plattformen. Diese können SoD-Bemühungen erleichtern (durch Zentralisierung von Identitäten und Bereitstellung einer einzigen Datenquelle) oder erschweren (durch Erweiterung der Komplexität des Berechtigungsmodells). Wie diese Tools eingesetzt werden, wird der Schlüssel zur Effektivität des SoD-Programms in der Cloud-Welt sein.

10.3 Regulatorische Evolution

Die regulatorische Landschaft entwickelt sich weiter zu strengeren Anforderungen für Zugriffskontrollen und SoD. Sarbanes-Oxley, das in den USA seit 2002 dominiert, hat sich gegen die anhaltende Aufsicht der SEC und des PCAOB konsequent weiterentwickelt. Europa hat seinen eigenen Rahmen - die Bilanzierungsrichtlinien, DORA (Digital Operational Resilience Act) für den Finanzsektor und die kommende Corporate Sustainability Reporting Directive.

Ein neuer Trend ist die regulatorische Aufmerksamkeit für KI-Systeme - der EU AI Act, ähnliche Initiativen in den USA und anderen Jurisdiktionen. Diese werden Auswirkungen auf SoD haben, insbesondere für autonome Agenten und KI-gesteuerte Geschäftsprozesse. Welche Kontrollen müssen für ein KI-Modell vorhanden sein, das Finanzentscheidungen trifft? Wie überwachen Sie sein Verhalten? Dies sind Fragen, die sich in den kommenden Jahren formalisieren werden.

Datenschutz und Datenschutz - GDPR, CCPA und ähnliche - haben auch Auswirkungen auf SoD. Wer Zugriff auf personenbezogene Daten hat, ist eine SoD-Frage. Die Trennung zwischen denen, die Daten verwalten, und denen, die sie analysieren, ist eine Form von SoD. Programme müssen diese Privacy-Dimensionen integrieren, anstatt sie separat zu behandeln.

Schließlich beobachten wir eine globale Konvergenz der Anforderungen. Während die spezifischen regulatorischen Rahmenbedingungen variieren, ähneln sich die zugrunde liegenden Erwartungen zunehmend: dokumentierte Kontrollen, Beweis ihrer Wirksamkeit, periodische Berichterstattung und schnelle Reaktion auf identifizierte Probleme. Organisationen, die ihre SoD-Programme aufbauen, um diese gemeinsamen Anforderungen zu erfüllen, sind in einer guten Position für die nächste Welle regulatorischer Veränderungen.

10.4 Was kommt als Nächstes

Wenn wir auf die kommenden Jahre blicken, sehen wir mehrere Schlüsseltrends, die SoD-Programme prägen werden. Erstens, kontinuierliche Risikoanalyse statt periodischer Überprüfungen. Statt einer jährlichen oder vierteljährlichen Überprüfung werden Risiken kontinuierlich neu bewertet, basierend auf realen Verhaltensdaten und Konfigurationsänderungen.

Zweitens, integrierte GRC-Plattformen. Statt separater Tools für SoD, operatives Risiko, Compliance und Internal Audit werden wir die Konsolidierung in einheitliche Plattformen sehen, die ein ganzheitliches Bild des Risikos bieten. Dies wird neue Möglichkeiten der Querkorrelation und tieferer Einblicke schaffen.

Drittens, Geschäftsmanager als primäre Risikomanager. Die Verschiebung der Verantwortung von zentralen GRC-Teams zu Geschäftsmanagern wird sich beschleunigen. Tools werden so entworfen, dass sie Managern ohne formale GRC-Schulung Risiken in geschäftlicher Sprache zugänglich machen.

Viertens, KI als Co-Pilot für GRC. KI-Modelle werden die Arbeit von GRC-Analysten erweitern, indem sie Routineanalysen automatisieren, Anomalien hervorheben und sogar Lösungen vorschlagen. Dies wird GRC-Teams freisetzen, sich auf strategische und komplexe Probleme zu konzentrieren.

Fünftens, eine Reifeprüfung der Branche selbst. Wir glauben, dass die nächsten Jahre eine breite Reflexion darüber bringen werden, was tatsächlich in SoD-Programmen funktioniert und was nicht. Organisationen, die in dieser Reflexion vorne dabei sind, werden in der Lage sein, Programme zu bauen, die echten geschäftlichen Wert liefern, statt einfach nur die Audit-Pflichten zu erfüllen.

Letztendlich geht SoD nicht um Technologie oder Compliance. Es geht darum, geschäftliches Vertrauen aufzubauen - das Vertrauen, dass Aktionen, die im Namen des Unternehmens unternommen werden, von autorisierten Personen aus den richtigen Gründen mit angemessener Aufsicht durchgeführt werden. Während sich die Mittel ändern, bleibt das Ziel das gleiche. Diejenigen, die das verstehen und ihre Programme um dieses Ziel herum aufbauen, werden sowohl die regulatorischen Anforderungen erfüllen als auch echten Wert für ihre Organisationen schaffen.