Der ultimative Leitfaden zur Funktionstrennung (SoD): Von der Richtlinie zur Durchsetzung auf Berechtigungsebene
Ein vollständiger SoD-Leitfaden: Definition, toxische Kombinationen, Framework-Mapping (SOC 2, ISO 27001, SOX, PCI DSS), die Konfliktmatrix und warum rollenbasierte SoD die eigentlichen Verstöße übersieht, die sich in weitreichenden Berechtigungen verbergen.
12 Min. Lesezeit · Zuletzt aktualisiert Juli 2026
Die meisten SoD-Programme scheitern nicht, weil die Richtlinie falsch ist, sondern weil die Durchsetzung auf der falschen Ebene endet. Teams definieren Rollen, ordnen sie einer Konfliktmatrix zu und betrachten die Sache als erledigt - während sich die eigentlichen toxischen Kombinationen still und leise innerhalb dieser Rollen ansammeln, unsichtbar für jede vierteljährliche Überprüfung per Tabellenkalkulation.
Dieser Leitfaden deckt alles ab: Was SoD ist, warum es existiert, die klassischen toxischen Kombinationen, nach denen Auditoren suchen, wie es auf die Frameworks abbildet, gegen die Sie geprüft werden - und, entscheidend, warum rollenbasierte SoD ein notwendiger, aber unzureichender Ausgangspunkt ist.
Was ist Funktionstrennung?
Funktionstrennung (auch Aufgabentrennung oder englisch Segregation of Duties) ist das Prinzip, dass keine einzelne Person die vollständige Kontrolle über einen kritischen Prozess haben sollte. Sie umfasst die systematische Aufteilung von Verantwortlichkeiten, sodass eine einzelne Person nicht dieselbe Tätigkeit sowohl ausführen als auch kontrollieren darf.
Die Logik ist einfach: Wenn für eine schädliche Handlung die Zusammenarbeit zweier Personen erforderlich ist, steigt die Hürde für Betrug oder Fehler erheblich. Eine Person kann einen Fehler machen oder böswillig handeln; zwei Personen, die gemeinsam konspirieren, ist schwerer aufrechtzuerhalten und leichter zu entdecken.
SoD wirkt auf drei Ebenen:
- Autorisierung - wer eine Aktion genehmigen darf
- Ausführung - wer sie durchführen darf
- Überprüfung/Audit - wer verifizieren darf, dass sie korrekt erfolgt ist
Wenn dieselbe Identität zwei oder mehr dieser Rollen innerhalb desselben Prozesses innehat, liegt ein Konflikt vor.
Warum SoD existiert: Betrug, Fehler und die Zahlen dahinter
Der ACFE-Bericht zu Wirtschaftskriminalität 2024 analysierte 1.921 Fälle in 138 Ländern mit einem Gesamtschaden von über 3,1 Milliarden US-Dollar. CFEs schätzen, dass Unternehmen jährlich rund 5 % ihres Umsatzes durch Betrug verlieren.
Das sind keine abstrakten Risiken. Fast 29 % der von Betrug betroffenen Unternehmen hatten keine internen Kontrollen über die Kreditorenbuchhaltung. SoD ist die grundlegende Kontrolle, die diese Lücke schließt - nicht indem sie Betrug unmöglich macht, sondern indem sie sicherstellt, dass keine einzelne Identität ihn sowohl begehen als auch verbergen kann.
SoD deckt auch unbeabsichtigte Fehler auf. Ein Entwickler, der seinen eigenen Code in die Produktionsumgebung deployt, hat keine unabhängige Prüfung seiner Arbeit. Ein Administrator, der sowohl Zugriffsrechte vergibt als auch zertifiziert, hat keinen externen Reviewer. Das Fehlen eines zweiten Augenpaars ist ein Risiko, selbst wenn die Absicht völlig gutartig ist.
Klassische toxische Kombinationen
Toxische Kombinationen bei SoD bezeichnen widersprüchliche Zugriffsberechtigungen, die es einem User ermöglichen, innerhalb eines Geschäftsprozesses unvereinbare Aktionen durchzuführen - und damit Möglichkeiten für Betrug, nicht autorisierte Transaktionen oder Datenmanipulation schaffen.
Hier sind die Kombinationen, die am häufigsten in Audit-Befunden auftauchen:
Finanz-SoD
| Widersprüchliche Berechtigungen | Risiko |
|---|---|
| Lieferantendatensatz anlegen + Zahlung an Lieferanten genehmigen | Betrügerische Lieferantenanlage und Selbstauszahlung |
| Überweisung initiieren + Überweisung autorisieren | Nicht autorisierte Geldtransfers |
| Gehaltsdaten erfassen + Gehaltsauszahlung durchführen | Geistermitarbeiter-Betrug |
| Buchungssatz erfassen + Buchungssatz genehmigen | Manipulation von Finanzberichten |
Einer der häufigsten SoD-Konflikte tritt auf, wenn ein User sowohl Lieferantendatensätze anlegen als auch ausgehende Zahlungen genehmigen kann - ein direktes Betrugsrisiko, da betrügerische Lieferanten hinzugefügt und bezahlt werden können, ohne dass eine unabhängige Prüfung stattfindet.
IT-SoD
| Widersprüchliche Berechtigungen | Risiko |
|---|---|
| Anwendungscode schreiben + In Produktion deployen | Nicht autorisierte Code-Änderungen unter Umgehung der QA |
| Zugriff beantragen + Eigenen Zugriffsantrag genehmigen | Privilege Escalation ohne Aufsicht |
| User-Accounts verwalten + User-Zugriff zertifizieren | Selbstzertifizierung übermäßiger Berechtigungen |
| Sicherheitsrichtlinien konfigurieren + Compliance mit diesen Richtlinien prüfen | Verbergen von Kontrollversagen |
Der Entwickler, der den Code schreibt, sollte nicht derjenige sein, der ihn in Produktion deployt; die Person, die Zugriff beantragt, sollte nicht diejenige sein, die ihn genehmigt; der Administrator, der Zugriffsrechte verwaltet, sollte nicht gleichzeitig derjenige sein, der sie prüft.
Die IT-Liste ist der Bereich, in dem die meisten SaaS-lastigen Unternehmen die größte Angriffsfläche haben. Wenn ein einzelner Entwickler sowohl repo:write auf einer Produktions-Codebase als auch Zugriff auf die Deployment-Pipeline hat, bricht die gesamte Change-Management-Kontrolle zusammen - unabhängig davon, was das Rollen-Richtliniendokument besagt.
Präventive vs. detektive SoD
SoD-Kontrollen fallen in zwei Kategorien, und Sie benötigen beide:
Präventive SoD ist in den Provisionierungs-Workflow integriert. Wenn ein User Zugriff beantragt, prüft das System, ob die Gewährung einen Konflikt mit seinen bestehenden Berechtigungen erzeugen würde - und blockiert oder eskaliert den Antrag, bevor der Konflikt entsteht. SoD ist primär eine präventive Kontrolle, die in die Rollenarchitektur und den Provisionierungs-Workflow eingebettet ist, um zu verhindern, dass widersprüchliche Berechtigungen gleichzeitig bestehen.
Detektive SoD identifiziert bereits bestehende Verstöße. Detektive Kontrollen wie Access-Review-Kampagnen, Audit-Log-Überprüfungen und Berechtigungsmonitoring identifizieren Verstöße, die sich im Laufe der Zeit angesammelt haben.
Die meisten Unternehmen verlassen sich fast ausschließlich auf detektive Kontrollen - periodische Access-Reviews, vierteljährliche Zertifizierungen, jährliche Audits. Das Problem: Wenn ein Verstoß entdeckt wird, kann er bereits seit Monaten bestehen. Präventive Kontrollen verhindern, dass der Konflikt überhaupt erst entsteht.
Der Goldstandard ist Konfliktprüfung zum Zeitpunkt der Anfrage: Jeder Zugriffsantrag wird gegen das vollständige Berechtigungsbild geprüft, bevor er gewährt wird - nicht sechs Monate später im Rahmen einer Zertifizierungskampagne.
Die SoD-Konfliktmatrix
Eine SoD-Konfliktmatrix ist das strukturierte Raster, das Berechtigungen (oder Rollen) gegeneinander abbildet, um unvereinbare Paarungen aufzudecken. Die Matrix dient sowohl als Designreferenz für die Rollenkonfiguration als auch als Audit-Referenz, die belegt, dass eine SoD-Richtlinie formal definiert ist.
Eine minimale Matrix sieht so aus:
| Entitlement A | Entitlement B | Domain | Risk Level | Compensating Control (if unavoidable) |
|---|---|---|---|---|
| Create Vendor | Approve Payment | Finance | Critical | Dual authorization + transaction log review |
| Initiate Wire | Authorize Wire | Finance | Critical | Out-of-band approval + daily reconciliation |
| Enter Payroll | Disburse Payroll | Finance | High | Manager sign-off + payroll audit |
| Code Commit (Prod) | Deploy to Production | IT | Critical | Mandatory peer review + immutable deploy log |
| Request Access | Approve Own Access | IT | High | Secondary approver + access log review |
| Manage User Accounts | Certify User Access | IT | High | Independent reviewer for certification |
| Configure Security Policy | Audit Security Policy | IT | High | Third-party or internal audit independence |
| Accounts Receivable | Accounts Payable | Finance | Medium | Periodic reconciliation by controller |
Die Matrix ist ein lebendes Dokument. Viele Unternehmen entwickeln individuelle Matrizen nach Geschäftsprozessbereichen und enden mit 40, 50, 60 oder sogar mehr als 100 SoD-Matrizen, die alle ständig überprüft und aktualisiert werden müssen, wenn sich Geschäftsprozesse oder Risikoniveaus ändern. Das ist das Tabellenkalkulationsproblem in aller Kürze.
SoD im Kontext der Compliance-Frameworks
Jedes wichtige Framework, das Auditoren verwenden, enthält eine SoD-Anforderung. Hier die Zuordnung:
| Framework | Relevant Control | What It Requires | Evidence Auditors Expect |
|---|---|---|---|
| SOC 2 | CC6.3 | Restrict logical access to authorized users; separate incompatible functions | Access provisioning logs, role assignments, conflict matrix, certification records |
| ISO 27001:2022 | A.5.3 + A.8.2 | Segregate conflicting duties; control privileged access rights | Policy doc, RBAC screenshots, access review evidence, exception log |
| SOX (Section 404) | ITGC / ICFR | Document and test internal controls over financial reporting; SoD is a primary ITGC category | Role-level access reports, conflict remediation evidence, auditor-tested samples |
| PCI DSS v4.0 | Req. 7 + Req. 8 | Restrict access to cardholder data by business need; enforce least privilege and unique IDs | Access control policy, user access reviews, privilege escalation logs |
Einige framework-spezifische Hinweise, die es wert sind, bekannt zu sein:
SOC 2 CC6.3 erwartet, dass der logische Zugriff auf autorisierte User beschränkt ist und dass unvereinbare Funktionen getrennt werden. Auditoren ziehen Stichproben und verfolgen sie von Anfang bis Ende - ein Richtliniendokument allein ist kein ausreichender Nachweis.
ISO 27001:2022 A.5.3 (aktualisiert von A.6.1.2 in der Version von 2013) verlangt, dass widersprüchliche Pflichten und Verantwortungsbereiche getrennt werden. Auditoren, die ISO-27001-Kontrolle 5.3 bewerten, erwarten sowohl Dokumentation auf Richtlinienebene als auch operative Nachweise, dass die Trennung aktiv durchgesetzt wird - nicht nur beschrieben. A.8.2 fügt die Anforderung hinzu, privilegierte Zugriffsrechte gezielt zu verwalten.
SOX Section 404 behandelt SoD als primäre IT-General-Controls-Kategorie. Gemäß Section 404 des Sarbanes-Oxley Act müssen börsennotierte Unternehmen interne Kontrollen, die eine zuverlässige Finanzberichterstattung unterstützen, dokumentieren, bewerten und testen - und SoD ist eine der am stärksten geprüften ITGC-Kontrollkategorien. SOX Section 404 betrachtet eine unzureichende Funktionstrennung als häufige Ursache für wesentliche Schwächen bei internen Kontrollen.
PCI DSS v4.0 (ab dem 31. März 2025 vollständig verpflichtend) verlangt Least-Privilege-Zugriff auf Karteninhaberdaten-Umgebungen, eindeutige User-IDs und strikte rollenbasierte Zugriffskontrollen. PCI DSS v4.0 führte 64 neue Anforderungen ein und wechselte von einem präskriptiven Checklisten-Modell zu einem flexibleren, risikobasierten Ansatz.
Das Kernproblem: Rollenbasierte SoD übersieht Konflikte auf Berechtigungsebene
Hier ist die unbequeme Wahrheit, der die meisten SoD-Programme ausweichen: Konflikte auf Rollenebene zu definieren ist nicht dasselbe wie sie auf Berechtigungsebene durchzusetzen.
Betrachten Sie ein häufiges Szenario. Ihre SoD-Richtlinie besagt, dass "Entwickler" und "Production Deployer" widersprüchliche Rollen sind. Sie stellen sicher, dass niemand beide Rollen gleichzeitig innehat. Sauber, oder?
Außer dass Ihre "Entwickler"-Rolle in GitHub environment:production-Schreibzugriff enthält, der von einer Legacy-Berechtigungsgruppe geerbt wurde. Ihre "Release Engineer"-Rolle in Ihrem CI/CD-Tool enthält die Möglichkeit, Produktions-Deploys auszulösen. Ein User, dem technisch gesehen nur die "Entwickler"-Rolle zugewiesen ist, hat durch Berechtigungsvererbung beide Seiten des Konflikts - und Ihre rollenbasierte Matrix deckt das nie auf.
Toxische Kombinationen in IAM und IGA entstehen durch veraltete Systeme, fragmentierte Rollenstrukturen und menschliche Fehler bei Rollenzuweisungen - ein Mangel an strukturierten Berechtigungsrichtlinien und unzureichende Governance verschärfen das Problem zusätzlich.
Das Akkumulationsproblem macht dies noch schlimmer. Wenn ein User dem Unternehmen beitritt, wird er mit rollenangemessenem Zugriff provisioniert; wenn er in ein neues Team oder eine neue Funktion wechselt, wird neuer Zugriff hinzugefügt, aber alte Berechtigungen werden selten im selben Schritt entfernt. Im Laufe der Zeit kann eine einzelne Identität die Restberechtigungen jeder Rolle angesammelt haben, die sie je innehatte - und so toxische Kombinationen erzeugen, die kein einzelnes Provisionierungsereignis jemals absichtlich geschaffen hat.
Die Lücke auf Berechtigungsebene: Ein Benutzer kann zwei konfliktbehaftete Berechtigungen besitzen, ohne zwei konfliktbehaftete Rollen innezuhaben. SoD-Richtlinien auf Rollenebene erfassen die offensichtlichen Fälle. Die Erkennung auf Berechtigungsebene erfasst die tatsächlichen — die Konflikte, die in breiten Rollen, vererbten Berechtigungsgruppen und angesammelten Zugriffsrechten aus früheren Tätigkeitsbereichen verborgen sind.
Manuelle SoD-Prozesse können diese Lücke nicht schließen. Manuelle SoD-Prozesse basieren auf einer statischen Momentaufnahme - in der Regel einer Tabellenkalkulation, die mit exportierten Zugriffsberichten abgeglichen wird - und dieses Modell versagt, wenn die widersprüchlichen Berechtigungen in verschiedenen Systemen liegen, da jede Admin-Konsole nur ihre eigene Anwendung sieht. Sobald sich Zugriffsrechte schneller ändern als der Review-Rhythmus, ist die Konfliktmatrix veraltet, bevor sie verwendet wird.
Aufbau und Pflege einer SoD-Richtlinie
Ein funktionsfähiges SoD-Programm hat fünf Komponenten:
Erfassen Sie die kritischen Kombinationen, die für Ihr Unternehmen relevant sind — Finanzen, IT und alle bereichsspezifischen Prozesse. Ordnen Sie diese Ihren Frameworks zu (SOC 2, ISO 27001, SOX, PCI DSS), sodass jede Regel eine Compliance-Begründung hat. Beginnen Sie mit den risikoreichsten Paaren: Lieferantenanlage + Zahlungsfreigabe, Code-Commit + Produktions-Deployment, Zugriffsantrag + Zugriffsgenehmigung.
Bleiben Sie nicht bei Rollen stehen. Ordnen Sie Konflikte den tatsächlichen Berechtigungen innerhalb jeder Rolle zu — den spezifischen GitHub-Berechtigungen, dem Jira-Projektzugriff, den ERP-Transaktionscodes. Genau hier enden die meisten Programme zu früh — und genau hier verbergen sich die meisten tatsächlichen Verstöße.
Integrieren Sie die Konflikterkennung in Ihren Zugriffsanfrage-Workflow. Wenn ein Benutzer eine neue Berechtigung beantragt, sollte das System diese gegen das vollständige bestehende Berechtigungsprofil des Benutzers prüfen — über alle verbundenen Anwendungen hinweg — bevor sie gewährt wird. Konflikte blockieren oder eskalieren, bevor sie entstehen.
Kleine Teams werden unvermeidliche Konflikte haben. Das ist akzeptabel — aber nur, wenn die Ausnahme dokumentiert, zeitlich begrenzt und mit einer kompensierenden Kontrolle verknüpft ist: erweitertes Logging, unabhängige Nachprüfung von Transaktionen, obligatorische Zwei-Personen-Autorisierung ab einem Risikoschwellenwert oder regelmäßige Freigabe durch den Vorgesetzten. Eine undokumentierte Ausnahme ist ein Auditbefund, der nur darauf wartet, entdeckt zu werden.
Zugriffsrechte ändern sich ständig. Joiner-Mover-Leaver-Ereignisse, Notfallzugriffsgewährungen, Rollenaktualisierungen und Änderungen an App-Berechtigungen schaffen zwischen den Überprüfungszyklen stets neue Konfliktmöglichkeiten. Kontinuierliches Entitlement-Monitoring — keine vierteljährlichen Tabellenkalkulations-Reviews — ist der einzige Weg, um ein aktuelles Bild aufrechtzuerhalten.
SoD für kleine Teams: Kompensierende Kontrollen sind keine Hintertür
Der häufigste Einwand gegen SoD von schlanken IT-Teams lautet: "Wir haben nicht genug Personal, um jede Aufgabe zu trennen." Das ist eine echte Einschränkung, keine Ausrede - und die Frameworks erkennen das an.
Wo die Personalstärke begrenzt ist, können kompensierende Kontrollen wie detaillierte Aktivitätsprotokolle und unabhängige Management-Reviews die Lücke füllen - entscheidend ist jedoch, zu dokumentieren, wo eine Trennung nicht möglich ist, und dem Auditor zu zeigen, dass man sich damit auseinandergesetzt hat.
Praktische kompensierende Kontrollen für kleine Teams:
- Manipulationssichere Protokollierung, die von jemandem außerhalb des Prozesses überprüft wird (auch ein Vorgesetzter, kein dedizierter Auditor)
- Zeitlich begrenzter Ausnahmezugriff, der automatisch abläuft und eine Überprüfung auslöst
- Verpflichtende Peer-Reviews für Code-Änderungen vor dem Deployment, auch wenn dieselbe Person technisch deployen kann
- Out-of-Band-Genehmigung für hochwertige Transaktionen (z. B. eine Bestätigung über einen zweiten Kanal von einer zweiten Person, bevor eine Überweisung ausgeführt wird)
- Automatisierte Anomalieerkennung, die markiert, wenn eine einzelne Identität beide Seiten eines sensiblen Prozesses abschließt
Entscheidend ist, dass kompensierende Kontrollen dokumentiert und getestet sein müssen. Eine mündliche Vereinbarung, dass "der Vorgesetzte immer prüft", ist keine kompensierende Kontrolle - sondern eine nicht überprüfbare Behauptung.
Warum kontinuierliche, automatisierte Erkennung periodische Reviews schlägt
Die Zugriffsüberprüfung per Tabellenkalkulation ist der häufigste SoD-Durchsetzungsmechanismus und der am wenigsten effektive. Hier ist der Grund:
- Es ist eine Momentaufnahme. Zugriff, der am Tag nach der Überprüfung gewährt wird, wird erst im nächsten Zyklus erfasst - möglicherweise sechs oder zwölf Monate später.
- Es ist anwendungsgebunden. Jede Admin-Konsole exportiert ihre eigenen Daten. Anwendungsübergreifende Konflikte - bei denen eine Seite der toxischen Kombination in GitHub und die andere in Ihrem ERP liegt - erfordern eine manuelle Korrelation, die so gut wie nie stattfindet.
- Es skaliert umgekehrt zur Komplexität. Je mehr Apps Sie betreiben, desto mehr Berechtigungen existieren, desto mehr Kombinationen müssen geprüft werden, und desto unrealistischer wird eine manuelle Überprüfung.
Automatisierte SoD-Erkennung auf Berechtigungsebene löst alle drei Probleme. Sie nimmt Berechtigungsdaten aus jeder verbundenen Anwendung auf, bewertet jede Identität kontinuierlich gegen definierte Konfliktregeln und zeigt Verstöße auf, sobald sie auftreten - nicht Monate später. Sie erkennt auch anwendungsübergreifende Konflikte, die keine einzelne App-Admin-Konsole sehen kann.
Einen tieferen Einblick, warum tabellenkalkulationsbasierte Access-Reviews den Anforderungen an Audit-Belege nicht standhalten, finden Sie in unserem Beitrag über den Wechsel von Tabellenkalkulationen zur kontinuierlichen Zugangszertifizierung.
Und wenn Sie sich auf ein SOC-2- oder ISO-27001-Audit vorbereiten, deckt das Identity Evidence Playbook genau das ab, wonach Auditoren fragen - einschließlich der SoD-Belege, die sie erwarten.
Wie Iden SoD umsetzt
Idens agentische IGA-Plattform setzt SoD auf Berechtigungsebene durch - über Ihren gesamten App-Stack hinweg, einschließlich Apps ohne SCIM oder APIs. Das bedeutet:
- Konfliktprüfung zum Zeitpunkt der Anfrage: Jeder Zugriffsantrag wird gegen das vollständige Berechtigungsbild des Antragstellers geprüft, bevor er gewährt wird - über alle 175+ verbundenen Apps hinweg
- Anwendungsübergreifende Konfliktsichtbarkeit: Konflikte, bei denen eine Seite in GitHub und die andere in Ihrem ERP liegt, werden als einzelner Verstoß angezeigt - nicht als zwei unverbundene Befunde
- Kontinuierliches Monitoring: Berechtigungsänderungen lösen eine sofortige Neubewertung gegen Ihr Konfliktregelwerk aus - kein Warten auf die nächste vierteljährliche Überprüfung
- Feingranulare Kontrolle: Konflikte werden auf Berechtigungsebene erkannt (Channel, Repo, Projekt, Umgebung), nicht nur auf Rollenebene - und schließen damit die Lücke, die rein rollenbasierte SoD offen lässt
SoD-Bereitschafts-Checkliste
Nutzen Sie dies als Ausgangspunkt für Ihre eigene SoD-Programmüberprüfung:
Finanz-SoD - wichtige Fragen:
- Ist Ihre Konfliktmatrix auf Berechtigungsebene definiert, nicht nur auf Rollenebene?
- Sind Lieferantenanlage und Zahlungsgenehmigung für jeden User getrennt?
- Werden Gehaltserfassung und Gehaltsauszahlung von verschiedenen Identitäten durchgeführt?
- Sind Buchungssatzerfassung und Buchungssatzgenehmigung getrennt?
- Sind Ausnahmen mit kompensierenden Kontrollen dokumentiert und zeitlich begrenzt?
- Gibt es einen unabhängigen Reviewer für Zugangszertifizierungen im Finanzbereich?
IT-SoD - wichtige Fragen:
- Sind Code-Commit- und Produktions-Deploy-Rechte auf Berechtigungsebene getrennt?
- Wird die Genehmigung von Zugriffsanträgen an jemand anderen als den Antragsteller weitergeleitet?
- Werden Konto-Provisionierung und Zugangszertifizierung von verschiedenen Identitäten durchgeführt?
- Sind Sicherheitsrichtlinien-Konfiguration und Sicherheits-Audit-Rollen getrennt?
- Ist eine anwendungsübergreifende Konflikterkennung vorhanden (nicht nur pro App)?
- Werden Berechtigungsänderungen kontinuierlich überwacht, nicht nur bei der vierteljährlichen Überprüfung?
- Sind Notfallzugriffe automatisch zeitlich begrenzt und protokolliert?
- Wird Ihre SoD-Konfliktmatrix aktualisiert, wenn sich Rollen oder Apps ändern?
Das Fazit
SoD ist keine Richtlinienübung - es ist ein Durchsetzungsproblem. Die Richtlinie ist der einfache Teil. Der schwierige Teil besteht darin, Konflikte auf Berechtigungsebene zu erkennen, über jede App in Ihrem Stack hinweg, bevor sie entstehen - und nicht Monate nach der Tatsache.
Rollenbasierte SoD gibt Auditoren etwas, worauf sie zeigen können. SoD auf Berechtigungsebene verhindert tatsächlich Betrug und Fehler. Die Lücke zwischen beiden ist der Ort, an dem die meisten Verstöße leben - und wo die meisten Programme aufhören zu suchen.
Beginnen Sie mit Ihren risikoreichsten toxischen Kombinationen, erstellen Sie Ihre Konfliktmatrix auf Berechtigungsebene, setzen Sie zum Zeitpunkt der Anfrage durch und überwachen Sie kontinuierlich. Für alles, was Ihre Tabellenkalkulation nicht sehen kann, ist das der Bereich, in dem automatisiertes IGA seinen Platz verdient.