Funktionstrennung (SoD) im IAM: Zugriffskonflikte verhindern

Dieser Leitfaden richtet sich an IT- und Security-Verantwortliche in Unternehmen mit 50 bis 500 Mitarbeitenden, die gerade von einem Auditor oder von einem Enterprise-Kunden nachweisen sollen, dass niemand einen Zugriff gleichzeitig beantragen und genehmigen kann. Wenn Sie Funktionstrennung in der Kreditorenbuchhaltung oder im Beschaffungsprozess suchen, ist dies nicht die richtige Seite.

Funktionstrennung im IAM ist die Massnahme, die verhindert, dass eine Person eine Kombination von Berechtigungen hält, mit der sie einen sensiblen Prozess allein abschliessen kann, etwa einen Lieferanten anlegen und dessen Zahlung freigeben, oder einen Zugriff beantragen und selbst genehmigen. In einer SaaS-Umgebung im Mittelstand liegt der Konflikt selten in einer einzelnen Anwendung: Er verteilt sich auf das HR-System, das Finanztool, das Code-Repository und den Identity Provider, weshalb eine manuelle Prüfung ihn übersieht. Umsetzen heisst: festhalten, welche Berechtigungspaare verboten sind, erkennen, wer sie aktuell im gesamten angebundenen und nicht angebundenen Bestand hält, und einem Auditor nachweisen, dass Sie sie gefunden und behoben haben. Rollenbasierte Zugriffskontrolle und geplante Zugriffsüberprüfungen sind die Mittel dafür.

Was ist Funktionstrennung im IAM, und ist das dasselbe wie Aufgabentrennung?

Ja, es ist dieselbe Massnahme, und der Unterschied liegt in der Begriffstradition, nicht in der Sache. Das Glossar des Computer Security Resource Center des NIST führt SoD als Abkürzung für separation of duty und definiert sie unter Verweis auf NIST SP 800-192 als das Prinzip, dass kein Benutzer genügend Rechte erhalten soll, um das System im Alleingang zu missbrauchen. Die ISO/IEC 27001:2022 nennt dieselbe Idee segregation of duties in Anhang-A-Massnahme 5.3. Im deutschen Sprachgebrauch stehen Funktionstrennung und Aufgabentrennung nebeneinander, und das BSI löst die Frage elegant, indem es beide in den Titel einer einzigen Anforderung schreibt. An der Wortwahl hängt nichts, und wer Ihnen einen inhaltlichen Unterschied verkauft, verkauft einen Unterschied, den die Normungsgremien nicht machen.

Woran allerdings etwas hängt, ist der Abstand zwischen der buchhalterischen und der IAM-Variante der Massnahme. Sie teilen ein Prinzip und in der Umsetzung fast nichts.

Das NIST liefert ausserdem die beiden Durchsetzungsarten, nach denen Sie gefragt werden. Statische Durchsetzung definiert Rollen im Konflikt, die derselbe Benutzer nicht ausführen kann, wodurch der Konflikt konstruktiv unmöglich wird. Dynamische Durchsetzung greift zum Zeitpunkt des Zugriffs, und ihre bekannteste Form ist das Vier-Augen-Prinzip, bei dem der zweite Genehmigende jeder autorisierte Benutzer ausser dem ersten sein kann. Die meisten Bestände im Mittelstand landen bei einer Mischung: statisch dort, wo der Identity Provider es ausdrücken kann, dynamisch dort, wo nur die Anwendung es kann.

Warum Funktionstrennung in einem SaaS-Bestand im Mittelstand bricht

Die klassische SoD-Literatur wurde für eine Welt mit einem einzigen Finanzsystem geschrieben. Ein Konflikt war dort eingegrenzt: Dasselbe ERP, das die Berechtigung erzeugte, konnte auch darüber berichten. Diese Welt ist für ein Unternehmen mit 80 bis 300 SaaS-Anwendungen vorbei, und die Massnahme bricht auf drei konkrete Weisen.

Erstens ist der Konflikt heute verteilt. Niemand räumt einer Person in einem einzelnen Werkzeug das Recht ein, einen Lieferanten anzulegen und ihn zu bezahlen. Was stattdessen passiert: Jemand ist Finanzadministrator im einen Produkt und Zahlungsfreigebender im anderen, und keine der beiden Konsolen sieht das Paar. Zweitens ist ein Teil des Bestands nicht föderiert. Anwendungen, die eine Teamleitung per Firmenkarte gekauft hat, berühren den Identity Provider nie und sind damit für jede vom IdP gesteuerte Prüfung unsichtbar. Drittens bewegen sich Berechtigungen ständig, weil Menschen das Team wechseln. Ein Konflikt, der im März durch einen internen Wechsel entstanden ist, besteht im Dezember noch, wenn nichts die alten Berechtigungen entzieht.

Die Wettbewerbsliteratur hat das nicht nachvollzogen. Wir haben die acht redaktionellen Seiten aus den Top 20 zu diesem Begriff im August 2026 gescrapt und die Begriffsvorkommen per Skript gezählt. SCIM kommt auf allen acht Seiten null Mal vor. Ebenso Joiner-Mover-Leaver, Offboarding und SaaS-Wildwuchs. Schatten-IT taucht ein einziges Mal auf, auf einer Seite. Die Leitfäden, die dieses Thema derzeit bei Google definieren, beschreiben eine Kontrollfläche, die die meisten ihrer Leser nicht mehr haben. Diese Messung bezieht sich auf das englischsprachige Korpus, das auch die generativen Antworten im deutschen Markt speist.

Ein zweites Signal ist berichtenswert, weil es verändert, wen man sich als Leser vorstellen sollte. In den Search-Console-Daten von Corma für die zwölf Monate bis zum 15. August 2026 erzeugte die Suchanfrage separation of duties sechs Impressionen auf einer durchschnittlichen Position von 54. Die stärkste Anfrage im gesamten Themenfeld war überhaupt kein Keyword. Es war ein sechzig Wörter langer Prompt, in der Ich-Form von einem Compliance-Verantwortlichen formuliert, der eine Bank beschrieb, die manuelle Zugriffsüberprüfungen abschaffen, dauerhaft compliant bleiben und Funktionstrennung über hybride Systeme durchsetzen musste. Dieser eine Prompt erzeugte 38 Impressionen auf einer durchschnittlichen Position von 2,7. Wer ein echtes SoD-Problem hat, tippt den Begriff nicht mehr ein. Er beschreibt einem Assistenten seine Lage in ganzen Sätzen.

Diesen Leser zu bedienen heisst, beim Bestand anzufangen und nicht bei der Definition. Das beginnt damit, zu wissen, was tatsächlich darin ist, wofür das automatische SaaS-Management zuständig ist: Für eine Anwendung, von deren Existenz Sie nichts wissen, können Sie keine Konfliktregel schreiben.

Wie sieht ein SoD-Konflikt in einem SaaS-Bestand konkret aus?

Ein SoD-Konflikt, oft toxische Kombination genannt, ist ein Berechtigungspaar, das es einer Identität erlaubt, einen sensiblen Prozess ohne zweites Augenpaar zu Ende zu bringen. Drei der rankenden Seiten fordern Sie auf, eine Matrix dieser Paare zu bauen. Keine davon zeigt eine für Softwareanwendungen. Die einzige in den Top 20 veröffentlichte Matrix bildet Bestellanforderungen und Bestellungen ab, was nützlich ist, wenn Sie den Einkauf verantworten, und nutzlos, wenn Sie die IT verantworten.

Hier die Fassung, die wir nirgends gefunden haben, ausgedrückt in den Anwendungen, die ein Mittelständler tatsächlich betreibt. Als Ausgangsmenge zum Anpassen zu verstehen, nicht als Standard.

Lesen Sie die letzte Spalte noch einmal, darum geht es in der ganzen Tabelle. Jeder dieser Konflikte ist aus dem Inneren beider Anwendungen unsichtbar. Das ist kein Disziplin- und kein Richtlinienproblem. Es ist ein Datenproblem, und es ist der Grund, warum die Massnahme in der Praxis scheitert, lange bevor jemand nachlässig wird.

Es lohnt sich auch, zu benennen, was das Risiko inzwischen ist. Die klassische SoD-Literatur ist um Bilanzbetrug herum gebaut, und zwei der Paare oben sind genau das: der erfundene Lieferant und das umgeleitete Gehalt. Die anderen fünf nicht. Sie sind Rechteausweitung, nicht protokollierte Änderung und Karteileichen mit Zugriff, also Sicherheits- und keine Buchhaltungsfehler. Diese Verschiebung hat eine organisatorische Folge: Ein SoD-Programm, das vollständig im Finanzbereich hängt, fängt die zwei Konflikte ab, die Finance ohnehin versteht, und verfehlt die fünf, die in der IT leben.

Wie setzt man SoD mit einem Zwei-Personen-IT-Team um?

Das ist die Frage, um die die rankenden Leitfäden herumschreiben, und es ist die Frage, die tatsächlich gestellt wird. In Administratorenforen fragt ein Administrator, der ein Zwei-Personen-Team für rund 160 Nutzer betreibt, wie er Konten strukturieren soll, um Funktionstrennung überhaupt zu erfüllen. In einem anderen Thread berichtet ein kleiner Dienstleister im SOC-2-Typ-II-Audit, dass die SoD-Erwartungen seines Kunden in seiner Grösse kaum erfüllbar sind. Keiner der beiden Threads bekommt eine klare Antwort, und die acht gemessenen Seiten verwenden die Wörter Mittelstand, KMU oder mid-market kein einziges Mal.

Die ehrliche Antwort lautet, dass Sie nicht jede Aufgabe trennen können, und die Regelwerke wissen das bereits. Die Trust Services Criteria von 2017 hinter SOC 2 tragen unter dem Kriterium zu Kontrollaktivitäten einen Point of Focus, wonach das Management unvereinbare Aufgaben trennt und, wo diese Trennung nicht praktikabel ist, alternative Kontrollmassnahmen auswählt und entwickelt. Das Regelwerk selbst liefert Ihnen den Ausweg. Die Auditfrage lautet deshalb nicht, ob Sie alles getrennt haben. Sie lautet, ob Sie identifiziert haben, was Sie nicht trennen konnten, diese Entscheidung dokumentiert und eine detektierende Massnahme dahintergesetzt haben.

Praktisch sind das vier Schritte. Halten Sie fest, welche Konflikte Sie akzeptieren und warum, und benennen Sie die Einschränkung, statt sie zu verdecken. Ersetzen Sie Prävention durch Detektion, wo keine zweite Person da ist, etwa durch eine monatliche Durchsicht aller mit einem privilegierten Konto ausgeführten Aktionen statt einer Regel, die sie blockiert. Verlagern Sie die Genehmigung überall dort aus der IT heraus, wo es einen fachlichen Verantwortlichen gibt, damit die Finanzleitung Finanzberechtigungen genehmigt statt der Systemadministrator seine eigenen. Und machen Sie das Restrisiko nach oben sichtbar, denn ein akzeptiertes Risiko, das die Geschäftsführung nie gesehen hat, ist kein akzeptiertes Risiko.

Der Reorganisationsaufwand ist real, und er fällt zuerst beim On- und Offboarding an. Adrien Guichard, CEO von Citel, einem französischen Industrieunternehmen mit 400 Mitarbeitenden, gegründet 1937, beschreibt das angestrebte Ergebnis seines Teams in der Fallstudie IT-Governance bei CITEL Guichard: On- und Offboarding verschlanken und zugleich die Sicherheit über feingranulare Zugriffskontrollen erhöhen, aus einem einheitlichen System heraus. Feingranular ist das entscheidende Wort. Ein Berechtigungspaar lässt sich nicht mit einer Rolle durchsetzen, die vierzig Dinge auf einmal gewährt.

SoD mit RBAC, Zugriffsanträgen und Zugriffsüberprüfungen durchsetzen

Die Umsetzung ist eine Abfolge, und das Überspringen eines Schritts ist der Grund, warum die meisten SoD-Vorhaben beim Richtliniendokument stehen bleiben. Diese Reihenfolge funktioniert.

1. Den Bestand inventarisieren, auch das nicht Föderierte. Jede Anwendung ausserhalb des Identity Providers liegt ausserhalb der Massnahme. Die Erkennung muss erfassen, was im Browser und auf den Geräten eingeführt wurde, nicht nur, was einen SSO-Konnektor hat.
2. Die Konfliktregeln vor den Rollen schreiben. Nehmen Sie die Matrix oben, streichen Sie, was nicht passt, ergänzen Sie, was fehlt. Zehn gut gewählte Paare schlagen hundert aus einer ERP-Vorlage geerbte.
3. Alles statisch abbilden, was sich statisch abbilden lässt. Hier zahlt sich rollenbasierte Zugriffskontrolle aus: Können zwei Berechtigungen nie zusammen bestehen, dürfen sie nie in derselben Rolle liegen. Definieren Sie Rollen fein genug, dass ein Konflikt überhaupt ausdrückbar ist.
4. Den Rest über eine Genehmigung zum Antragszeitpunkt führen. Dynamische Durchsetzung heisst, dass der Antrag an jemanden geht, der nicht der Antragsteller ist. Automatische Zugriffsanfragen im Self-Service verhindern, dass die informelle Slack-Nachricht zum Genehmigungsnachweis wird.
5. Die nicht verhinderten Konflikte planmässig erkennen. Das ist die Zugriffsüberprüfung, und sie ist der einzige Schritt, der Konflikte aus internen Wechseln, aus nicht föderierten Anwendungen oder aus nachträglich geschriebenen Regeln aufdeckt.
6. Mit Entzug und Nachweis schliessen. Eine Prüfung, die einen Konflikt findet und nichts entzieht, erzeugt eine Auditfeststellung, statt sie zu verhindern.

An Schritt fünf bricht der manuelle Ansatz zusammen, und die Praktiker sagen das unumwunden. Alex Reintjes, IT Support Engineer bei Robovision, beschreibt den Gewinn der Automatisierung in gesparter Zeit für manuelle Aufgaben wie Zugriffsüberprüfungen, nicht in Sicherheitsniveau. Das ist die ehrliche Rahmung: Die Massnahme ist nicht schwer zu verstehen, sie ist mit einem kleinen Team schwer regelmässig durchzuhalten. Sie auf automatisierte und sichere Access Reviews umzustellen, macht aus einem jährlichen Kraftakt eine Massnahme, die tatsächlich läuft.

Was BSI IT-Grundschutz, ISO 27001, SOC 2, NIS2 und die DSGVO wirklich verlangen

Fast jeder Leitfaden zu diesem Thema behauptet, SoD werde von SOX, ISO 27001, SOC 2 und, in mindestens einem von uns geprüften Fall, von der DSGVO gefordert. Die letzte Behauptung ist falsch. Die Verordnung fordert in Artikel 32 geeignete technische und organisatorische Massnahmen und enthält die Begriffe Funktionstrennung und Aufgabentrennung an keiner Stelle.

Im deutschen Markt gibt es dafür eine Quelle, die deutlicher ist als alle anderen und die in der englischsprachigen Literatur schlicht nicht vorkommt. Im IT-Grundschutz-Kompendium des BSI trägt der Baustein ORP.4 Identitäts- und Berechtigungsmanagement die Anforderung ORP.4.A4 mit dem Titel Aufgabenverteilung und Funktionstrennung, ergänzt durch ORP.1.A4 zur Funktionstrennung zwischen unvereinbaren Aufgaben im Baustein Organisation. Beide sind Basis-Anforderungen, also die Stufe, die für jede IT-Grundschutz-Konformität erfüllt sein muss, und nicht Kann-Empfehlungen. Der Umsetzungshinweis zu ORP.4 formuliert es unmissverständlich: Ein Identitäts- und Berechtigungsmanagement muss den Ansatz verfolgen, Aufgaben und Funktionen und damit auch Berechtigungen geeignet zu trennen.

Lesen Sie die erste Spalte mit Blick auf Ihr eigenes Unternehmen. Sind Sie ein europäisches Unternehmen mit 50 bis 500 Mitarbeitenden, gilt SOX mit hoher Wahrscheinlichkeit nicht für Sie, während BSI IT-Grundschutz, ISO/IEC 27001, SOC 2 und NIS2 sehr wohl greifen. Das ist beinahe die Umkehrung der Gewichtung, die Sie in den meisten Leitfäden finden, die mit SOX öffnen, weil die Literatur für börsennotierte US-Unternehmen geschrieben wurde. Für den grösseren Blick auf die Governance-Ebene behandelt unser Überblick der besten IGA-Lösungen für den Mittelstand die Plattformseite derselben Frage, und die Seite compliant bleiben und SaaS-Apps managen für Sicherheitsteams die operative Seite.

SoD-Nachweise erzeugen, die Ihr Auditor akzeptiert

Ein Auditor bewertet nicht Ihre Absichten, er bewertet Artefakte. Vier davon tragen eine SoD-Massnahme, und jedes hat eine Schwachstelle, die man kennen sollte.

• Das Konfliktregister. Ihre benannte Liste verbotener Berechtigungspaare, mit Verantwortlichem und Datum. Typischer Fehler: Es existiert als Folie und nicht als gepflegtes Dokument.
• Das Register akzeptierter Konflikte. Konflikte, die Sie nicht trennen können, jeweils mit Einschränkung, kompensierender Massnahme und Genehmigendem. Typischer Fehler: Schweigen, das als unerkannte Lücke gelesen wird statt als akzeptiertes Risiko.
• Prüfnachweise mit Ergebnis. Wer welche Berechtigungen wann geprüft hat und was daraufhin entzogen wurde. Typischer Fehler: eine Prüfung mit hundert Prozent Genehmigungsquote, die Auditoren als Abnicken lesen.
• Die Änderungshistorie. Jede Erteilung, Änderung und jeder Entzug, mit Zeitstempel, idealerweise nicht veränderbar durch die Person, die die Änderung vorgenommen hat. Typischer Fehler: Protokolle in genau der Anwendung, deren Administrator geprüft wird.

Beachten Sie, dass drei der vier Artefakte Nachweise über die Wirksamkeit im Zeitverlauf sind und keine Beschreibungen der Massnahme. Das ist der häufigste Grund, warum ein erstes SOC-2- oder ISO-27001-Audit beim Thema Zugriffe schlecht läuft: Die Richtlinie ist in Ordnung, und es gibt nichts, was zeigt, dass jemand sie angewendet hat.

Wie Corma Sie bei der Funktionstrennung unterstützt

Corma ist eine europäische Plattform für SaaS-Management und Identitäts-Governance für Unternehmen mit 50 bis 500 Mitarbeitenden, so gebaut, dass die Zugriffsverwaltung und das Anwendungsinventar im selben System liegen. Für SoD ist das entscheidend, weil die Konflikte aus der Matrix oben erst sichtbar werden, wenn beide Hälften des Paares in derselben Ansicht stehen.

Konkret baut Corma ein fortlaufend aktualisiertes Inventar von Anwendungen, Identitäten und Berechtigungen auf, das föderierte, nicht föderierte und Schatten-IT-Anwendungen umfasst, damit Konfliktregeln auch Anwendungen erreichen, die den Identity Provider nie berühren. Corma leitet Zugriffsanträge an einen anderen Genehmigenden als den Antragsteller, das ist die dynamische Hälfte der Massnahme. Corma führt Anträge auf das Prinzip der geringsten Rechte zurück und setzt rollenbasierte Zugriffskontrolle durch, das ist die statische Hälfte. Corma automatisiert die Änderungen im Joiner-Mover-Leaver-Prozess, was verhindert, dass ein interner Wechsel still einen Konflikt erzeugt. Und Corma führt geplante Zugriffsüberprüfungen mit dem Berechtigungskontext durch, den Prüfende brauchen, und erzeugt dabei die Prüfnachweise und die Änderungshistorie, die ein Auditor verlangt. Corma ist nach ISO/IEC 27001:2022 zertifiziert und in der Europäischen Union gehostet, was dieselbe Nachweisfrage eine Ebene höher ist.

Wie die Bausteine zusammenspielen, sehen Sie auf der Seite Identity Governance and Administration, und die kurze Definition der Massnahme steht in unserem Glossareintrag zur Funktionstrennung. Wenn Sie Ihre eigenen Konflikte sehen wollen statt einer generischen Matrix, fordern Sie eine Demo an und wir gehen Ihren Bestand gemeinsam durch.

Häufige Fragen

Was ist der Unterschied zwischen Funktionstrennung und Aufgabentrennung?

Inhaltlich keiner. Beide Begriffe bezeichnen dieselbe Massnahme, die verhindert, dass eine Person genügend Rechte hält, um einen sensiblen Prozess allein abzuschliessen. Das BSI führt beide sogar im Titel einer einzigen Anforderung zusammen, ORP.4.A4 Aufgabenverteilung und Funktionstrennung. Im Englischen stehen separation of duties beim NIST und segregation of duties bei ISO nebeneinander.

Was fordert der BSI IT-Grundschutz zur Funktionstrennung?

Der Baustein ORP.4 Identitäts- und Berechtigungsmanagement enthält mit ORP.4.A4 Aufgabenverteilung und Funktionstrennung eine Basis-Anforderung, ergänzt um ORP.1.A4 zur Funktionstrennung zwischen unvereinbaren Aufgaben. Als Basis-Anforderungen sind beide für jede IT-Grundschutz-Konformität verbindlich und nicht optional.

Was sind die zentralen Prinzipien der Funktionstrennung?

Keine Identität hält ein Berechtigungspaar im Konflikt. Konflikte werden vorab definiert statt während eines Audits entdeckt. Prävention greift dort, wo die Systeme sie ausdrücken können, Detektion dort, wo sie es nicht können. Und jeder Konflikt, der nicht getrennt werden kann, wird dokumentiert und mit einer kompensierenden Massnahme versehen.

Kann ein kleines Unternehmen Funktionstrennung umsetzen?

Ja, aber nicht vollständig, und die Regelwerke sehen das vor. Die Trust Services Criteria halten fest, dass das Management dort, wo die Trennung nicht praktikabel ist, alternative Kontrollmassnahmen auswählt und entwickelt. Ein kleines Team besteht ein Audit, indem es dokumentiert, welche Aufgaben es nicht trennen kann, und diese Tätigkeiten überwacht, nicht indem es eine Trennung vortäuscht.

Fordert ISO 27001 die Funktionstrennung?

Ja. Die ISO/IEC 27001:2022 führt sie als Anhang-A-Massnahme 5.3, mit Umsetzungshinweisen in ISO/IEC 27002 unter derselben Nummer. Ob sie für Sie gilt, hängt von Ihrer Anwendbarkeitserklärung ab, und ein Ausschluss erfordert eine dokumentierte Begründung.

Wie setzt man SoD über viele SaaS-Anwendungen hinweg durch?

Indem man Berechtigungen über den gesamten Bestand hinweg auswertet statt Anwendung für Anwendung, weil die konfligierenden Berechtigungen meist in zwei verschiedenen Produkten liegen. Das setzt ein Inventar voraus, das nicht föderierte und Schatten-IT-Anwendungen einschliesst, Konfliktregeln auf Berechtigungsebene, und geplante Prüfungen, die Entzugsnachweise erzeugen.