Tim Lipphardt
Head of Consulting
Alle Blogartikel
Segregation of Duties: Funktionstrennung richtig umsetzen
Konflikte entstehen zwischen Systemen
Bei Segregation of Duties reicht es nicht, jede Anwendung einzeln zu prüfen. Gefährlich wird es, wenn Berechtigungen aus zwei Systemen bei einer Person zusammenkommen, meistens nach einem Abteilungswechsel.
Risiken vor Rechten
Eine gute SoD-Matrix startet mit der Frage, was im Unternehmen schiefgehen kann. Erst danach übersetzt du das in technische Berechtigungen.
Blocken, prüfen, dokumentieren
Kritische Regeln greifen schon beim Antrag, der Rest über regelmäßige Analysen. Wo Trennung nicht machbar ist, hilft eine dokumentierte Ausnahme mit Ablaufdatum.
Funktionstrennung
Zwei harmlose Rechte, ein echtes Problem
Stell dir einen erfahrenen Admin vor, der in Entra ID neue Konten anlegt. Weil er sich gut auskennt, pflegt er nebenbei auch die Alarmregeln im SIEM, also dem System, das sicherheitsrelevante Ereignisse sammelt und auswertet.
Jedes Recht für sich ist völlig in Ordnung. Wenn beide zusammenkommen, kann er allerdings ein Konto anlegen, damit auf sensible Daten zugreifen und den passenden Alarm vorher stummschalten. Aufgefallen wäre das niemandem, denn die beiden Rechte liegen in zwei Systemen, die nichts voneinander wissen.
Und genau hier kommt Segregation of Duties ins Spiel. Dabei wird Funktionstrennung pro Identität gedacht und nicht pro Anwendung.
Grundlagen
Was ist Segregation of Duties?
Segregation of Duties (SoD), auf Deutsch Funktionstrennung, verteilt die kritischen Schritte eines Prozesses auf verschiedene Personen. So kann niemand allein Schaden anrichten oder Fehler vertuschen.
Oft wird in dem Zusammenhang das Vier-Augen-Prinzip genannt. Der Unterschied: Vier Augen kontrollieren einen einzelnen Vorgang, zum Beispiel eine Überweisung. SoD regelt grundsätzlich, welche Rollen eine Person überhaupt gleichzeitig haben darf.
Beides ergänzt sich, ersetzt sich aber nicht. Welche klassischen Konflikte es im Finanzprozess gibt, findest du in unserem Artikel zum Berechtigungskonzept.
Das Problem
Warum entstehen SoD-Konflikte zwischen Systemen?
Jedes System prüft nur sich selbst
Viele Anwendungen bringen eigene SoD-Prüfungen mit. Das ERP erkennt Konflikte im ERP, das Banking-Tool im Banking-Tool, und GitHub verhindert, dass du deinen eigenen Pull Request freigibst. Das ist schon mal ein guter Mechanismus, reicht aber oft nicht aus.
Denn den Konflikt zwischen zwei Systemen sieht keine dieser Prüfungen. Dafür brauchst du eine übergreifende Sicht auf alle Rechte einer Identität. Genau das liefert eine IGA-Lösung (Identity Governance and Administration), die Berechtigungen aus allen angebundenen Systemen zusammenführt.
Vier Konflikte aus der Praxis
Das Muster ist immer gleich: Zwei Rechte, oft in zwei Systemen, ergeben zusammen einen Prozess, den niemand mehr kontrolliert.
Der Mover als häufigste Ursache
Die meisten Konflikte entstehen nicht durch Absicht, sondern schleichend. Jemand wechselt aus dem Einkauf ins Controlling, bekommt die neuen Rechte und behält die alten „noch für die Übergabe“. Ein halbes Jahr später hat er beide.
Wie du Abteilungswechsel sauber abbildest, liest du in unserem Beitrag zum Identity Lifecycle Management.
Praxis
Wie baust du eine SoD-Matrix auf?
Die SoD-Matrix ist dein Regelwerk. Sie legt fest, welche Funktionen nicht bei einer Person zusammenkommen dürfen. So erstellst du sie:
1. Mit Geschäftsrisiken starten
Frag zuerst, was in deinem Unternehmen wirklich schiefgehen kann: Betrug, Datenabfluss, manipulierte Protokolle. Wer mit einer Liste von 5.000 Einzelrechten loslegt, verliert sich im Detail.
2. Risiken in fachliche Funktionen übersetzen
Beschreibe Funktionen so, dass der Fachbereich sie versteht, also „Benutzerkonten anlegen“ statt „User Administrator in Entra ID“. So bleiben die Regeln nachvollziehbar, auch wenn sich Systeme ändern.
3. Funktionen den technischen Rechten zuordnen
Jetzt verknüpfst du jede Funktion mit den konkreten Rechten in allen Systemen. Das klappt nur mit sauberen Stammdaten, sonst prüfst du Identitäten, die es so gar nicht gibt. Mehr dazu in unserem Artikel zur Datenqualität im IAM.
4. Regeln nach Kritikalität einstufen
Nicht jeder Konflikt ist gleich schlimm. Die Einstufung in hoch, mittel und niedrig entscheidet später, ob IGA blockt oder nur meldet.
So kann ein Ausschnitt aussehen:
| Funktion A | Funktion B | Risiko | Kritikalität |
|---|---|---|---|
| Personalstammdaten pflegen | Gehaltslauf freigeben | Fiktive Mitarbeiter | Hoch |
| Bestellung anlegen | Wareneingang bestätigen | Zahlung ohne Lieferung | Hoch |
| Benutzerkonten anlegen | SIEM-Alarmregeln pflegen | Verdeckter Zugriff | Hoch |
Unser Expertenrat: Fang mit 10 bis 15 Regeln an, die wirklich kritisch sind. Eine schlanke Matrix, die gelebt wird, ist sinnvoller als eine Excel-Liste mit 300 Zeilen, die niemand pflegt.
Wenn du schon ein Rollenmodell hast, hinterlegst du die Regeln direkt auf Rollenebene.
Prüflogik
Präventiv oder detektiv: Wann sollte IGA blocken?
Eine SoD-Matrix bringt nur etwas, wenn jemand sie auch prüft. Dafür gibt es zwei Wege:
- Präventiv: Das IGA-Tool prüft schon beim Antrag. Entsteht ein kritischer Konflikt, blockt es oder eskaliert an eine zweite Instanz.
- Detektiv: Regelmäßige Analysen finden Altlasten und Konflikte, die über Umwege entstanden sind, etwa durch verschachtelte Gruppen oder direkte Zuweisungen am System vorbei. Die Ergebnisse fließen in die Rezertifizierung.
Kurz gesagt: Kritische Regeln prüfst du präventiv, den Rest detektiv. Wer alles blockt, erzeugt Frust und Workarounds, und am Ende teilen sich Kollegen doch wieder Accounts.
Ausnahmen
Was tun, wenn die Trennung nicht geht?
Das kennt jeder Mittelständler: Das IT-Team besteht aus drei Leuten, eine ordentliche Trennung ist schlicht nicht drin. Das ist aber kein Grund, SoD aufzugeben.
Du brauchst dann eine kompensierende Kontrolle, also eine zusätzliche Prüfung, die das Risiko auf anderem Weg abfängt. Das bedeutet konkret:
- eine nachgelagerte Prüfung, zum Beispiel ein monatliches Review aller neu angelegten Admin-Konten
- eine dokumentierte Ausnahme mit Begründung, Verantwortlichem und Ablaufdatum
- befristete Rechte statt Dauerzugriff, etwa über Just-in-Time-Zugriffe aus dem Privileged Access Management
Läuft die Ausnahme ab, muss jemand sie aktiv verlängern. So schläft keine Sonderregel einfach ein.
Unterstützung gefällig?
Wir helfen dir, eine schlanke SoD-Matrix aufzubauen und sie in deinem IGA-Prozess durchzusetzen.
Audit
Was wollen Prüfer bei SoD sehen?
- ein dokumentiertes, aktuelles SoD-Regelwerk
- Belege, welche Konflikte erkannt und wie sie behoben wurden
- eine Übersicht aller genehmigten Ausnahmen mit Laufzeit
Wenn dein IGA-Tool das alles protokolliert, ziehst du die Nachweise auf Knopfdruck, statt sie vor jedem Audit zusammenzusuchen.
Fazit
Fazit: Funktionstrennung ist eine Sache der Identität, nicht des Systems
SoD-Konflikte entstehen schleichend zwischen den Systemen und oft nach einem Abteilungswechsel, den niemand ordentlich abgeschlossen hat.
Das nimmst du mit:
- Prüfe Funktionstrennung pro Identität, nicht pro Anwendung.
- Starte mit den Risiken, die dich wirklich treffen würden, nicht mit tausend Einzelrechten.
- Lass kritische Regeln beim Antrag greifen und finde den Rest über regelmäßige Analysen.
- Dokumentiere Ausnahmen sauber und mit Ablaufdatum.
Das Ergebnis? Ein Audit, in dem du Nachweise zeigst, statt Ausreden zu suchen. Wenn du Bedarf bei dem Thema hast, schreib uns gerne eine Nachricht.
FAQ
Häufige Fragen zu Segregation of Duties
Was ist der Unterschied zwischen Segregation of Duties und dem Vier-Augen-Prinzip?
Das Vier-Augen-Prinzip kontrolliert einen einzelnen Vorgang durch eine zweite Person. Segregation of Duties legt grundsätzlich fest, welche Rollen eine Person nicht gleichzeitig haben darf.
Was ist ein SoD-Konflikt?
Ein SoD-Konflikt liegt vor, wenn eine Person zwei Berechtigungen besitzt, mit denen sie einen kritischen Prozess allein steuern kann, etwa Benutzerkonten anlegen und die zugehörigen Alarme abschalten.
Wie erstelle ich eine SoD-Matrix?
Du startest mit Geschäftsrisiken, übersetzt sie in fachliche Funktionen, ordnest diese den technischen Rechten in allen Systemen zu und stufst jede Regel nach Kritikalität ein.
Braucht man SoD auch außerhalb von SAP?
Ja. Viele Konflikte entstehen gerade zwischen Systemen, etwa zwischen Identity Provider, Ticketsystem und Cloud-Plattform. Eine Prüfung nur im ERP übersieht sie.
Dieser Beitrag entstand mit KI-Unterstützung. Veröffentlicht von amiconsult GmbH, fachlich geprüft von Sina Ruland.
