Was ist Funktionstrennung (SoD)? Definition und Beispiele

Ein einzelner Mitarbeiter, der einen Lieferantendatensatz erstellen und dann die Rechnung dieses Lieferanten genehmigen kann, braucht keine Hilfe von anderen, um eine unzulässige Zahlung durchzusetzen. Keine Absprache ist erforderlich, und nichts muss gefälscht werden: Ein Login mit zu viel Reichweite reicht allein aus. Funktionstrennung (SoD) ist die Kontrolle, die diese Lücke schließt. Sie teilt einen sensiblen Prozess in Schritte auf, die verschiedene Personen ausführen müssen, sodass keine einzelne Person eine Transaktion von Anfang bis Ende unkontrolliert abwickeln kann.

Das Prinzip liegt den meisten internen Kontrollrahmenwerken in den Bereichen Finanzen, IT und Sicherheitsbetrieb zugrunde. Prüfer fragen gezielt danach. Regulierungsbehörden zitieren es in spezifischen Klauseln. Und die Kosten für das Auslassen steigen weiter: Der Median bei Fällen von Betrug am Arbeitsplatz betrug 104.000 $ im Jahr 2026, und der durchschnittliche Fall lief etwa 12 Monate, bevor ihn jemand entdeckte, laut dem Bericht ACFE's Occupational Fraud 2026: A Report to the Nations.

Kernpunkte

SoD trennt Autorisierung, Verwahrung und Aufzeichnung auf verschiedene Personen, sodass ein einzelnes Konto einen sensiblen Prozess nicht allein abschließen kann.
Es unterscheidet sich von Least Privilege und RBAC. Least Privilege begrenzt, wie viel Zugriff eine Person hat, RBAC ist der Mechanismus, und SoD ist die Designregel, die entscheidet, welche Rollenkombination ein einzelnes Konto innehaben darf.
Der Median bei Fällen von Betrug am Arbeitsplatz betrug 104.000 $ im Jahr 2026 und lief etwa 12 Monate, bevor ihn jemand entdeckte (ACFE).
NIST AC-5, ISO 27001 Annex A 5.3 und NIS2 Art. 21(2)(i) erwarten alle dokumentierte SoD-Kontrollen, obwohl das rechtliche Gewicht je nach Branche variiert.
Teams ohne dedizierte Identity Governance and Administration (IGA)- oder Governance, Risk, and Compliance (GRC)-Plattform können SoD durch kompensierende Kontrollen umsetzen: nicht entfernbare Admin-Rollen, Genehmigungsrouting, Audit-Protokollierung und regelmäßige Überprüfung.

Was ist Funktionstrennung (SoD)?

Funktionstrennung (SoD) ist eine interne Kontrolle, die einen sensiblen Prozess in Phasen unterteilt — typischerweise Autorisierung, Verwahrung oder Ausführung und Aufzeichnung oder Abstimmung — und jede Phase einer anderen Person zuweist. Keine einzelne Person initiiert und genehmigt dieselbe Transaktion oder handhabt einen Vermögenswert und erfasst dessen eigene Bewegung. Das Ziel ist es, Betrug oder Fehler so zu gestalten, dass sie Absprache statt nur Gelegenheit erfordern.

SoD ist nicht dasselbe wie ein Organigramm. Eine Berichtslinie zeigt, wer wen führt, sagt aber nichts darüber aus, wer einen Lieferanten erstellen, dessen Zahlung genehmigen und das Hauptbuch abstimmen kann, ohne dass jemals eine zweite Person die Transaktion prüft. Zwei Personen können demselben Manager unterstellt sein und trotzdem SoD erfüllen, solange keine von beiden den vollständigen Prozess allein abschließen kann. Das Vier-Augen-Prinzip — das mindestens zwei Personen für die Freigabe einer sensiblen Aktion erfordert — ist der einfachste Ausdruck dieser Idee.

Funktionstrennung vs. Least Privilege vs. RBAC

SoD ist nicht Least Privilege, und Least Privilege ist nicht RBAC. Least Privilege begrenzt, wie viel Zugriff eine Person hat. SoD begrenzt, ob eine Person einen gesamten sensiblen Prozess allein abschließen kann, selbst innerhalb ihres erlaubten Zugriffs. RBAC (Role-Based Access Control) ist der Mechanismus, der normalerweise beides durchsetzt, indem er Berechtigungen an Rollen statt an Einzelpersonen bindet.

Die drei Konzepte versagen unterschiedlich, wenn sie allein angewendet werden. Least Privilege ohne SoD erlaubt immer noch, dass ein eng begrenztes Konto sowohl denselben Datensatztyp erstellt als auch genehmigt, weil eng nicht isoliert bedeutet. RBAC ohne SoD kann stillschweigend einer Person zwei Rollen zuweisen, die nie überlappen sollten — wie ein Kreditorenbuchhalter, der während einer Urlaubswoche für einen Genehmiger einspringt. Die Rollendefinitionen sehen sauber aus, die Kombination hebelt die Kontrolle aus.

Nichts davon macht RBAC überflüssig. Es ist das Werkzeug, das SoD in großem Maßstab durchsetzbar macht. Siehe wie RBAC Zugriff nach Rolle zuweist für das zugrunde liegende Modell: Anstatt individuelle Berechtigungen zu verfolgen, definiert ein Administrator Rollen, und SoD-Regeln entscheiden, welche Rollen ein einzelnes Konto gleichzeitig innehaben darf.

Prinzip	Was es kontrolliert	Versagt ohne es
Least Privilege	Wie viel Zugriff ein Konto hat	Konten sammeln im Laufe der Zeit ungenutzte, risikoreiche Berechtigungen an
RBAC	Wie Zugriff auf Jobfunktionen abgebildet wird	Berechtigungen werden ad hoc, inkonsistent und pro Person zugewiesen
Funktionstrennung	Ob ein Konto einen sensiblen Prozess allein abschließen kann	Ein einzelnes kompromittiertes oder nachlässiges Konto kann Betrug begehen oder Schaden verursachen, ohne dass eine zweite Partei involviert ist

Häufige Funktionstrennungskonflikte (mit Beispielen)

Ein Funktionstrennungskonflikt besteht immer dann, wenn ein Konto oder eine Person zwei Rollen innehat, die kombiniert ermöglichen, einen sensiblen Prozess ohne Beteiligung einer zweiten Partei abzuschließen. Die deutlichsten Beispiele finden sich in Finanzen und Beschaffung, aber dasselbe Fehlermuster zeigt sich in DevOps-Pipelines, HR-Systemen und Credential-Tresoren.

Formalisierte SoD-Anforderungen lassen sich auf die Buchhaltungsskandale bei Enron und WorldCom Anfang der 2000er Jahre zurückführen, die direkt zum Sarbanes-Oxley Act und seinem Section 404 Internal-Controls-Mandat führten. Diese Geschichte prägt noch heute, wie Prüfer die Kontrolle angehen: SoD existiert, weil informelles Vertrauen ab einer bestimmten Unternehmensgröße nicht mehr skaliert.

Wenn eine Person sowohl einen Lieferanten erstellen als auch dessen Zahlung genehmigen kann, erfordert Betrug überhaupt keine Absprache.

Bereich	Konfligierende Aufgaben	Was es ermöglicht, wenn kombiniert
Finanzen	Lieferanten erstellen + dessen Rechnung genehmigen	Fiktive Lieferantenzahlungen ohne zweiten Prüfer
Beschaffung	Einkauf anfordern + Bestellung genehmigen	Unautorisierte Ausgaben unter Umgehung von Budgetkontrollen
IT / DevOps	Code bereitstellen + Bereitstellung genehmigen	Ungeprüfter Code erreicht Produktion, einschließlich Hintertüren
HR	Gehaltssatz eines Mitarbeiters festlegen + Gehaltsabrechnung verarbeiten	Unautorisierte Gehaltsänderungen, die niemand anderes verifiziert
Credential-Management	Tresor erstellen + eigene Admin-Rechte gewähren	Ein Konto, das Geheimnisse speichert und kontrolliert, wer sie sehen kann, ohne unabhängige Aufsicht
IT-Administration	Benutzerkonten bereitstellen + Zugriffsanfragen genehmigen	Konten, die von derselben Person erstellt und genehmigt werden, unter Umgehung der Prüfung

Wenn eine Zeile in dieser Tabelle beschreibt, wie Ihr Tresor heute funktioniert, ist diese Lücke behebbar. Testen Sie Passwork kostenlos und sehen Sie, wie Tresor-Richtlinien sie schließen.

Wie man eine Funktionstrennungsmatrix erstellt

Eine Funktionstrennungsmatrix bildet Rollen gegen die Aktionen ab, die diese Rollen ausführen können, sodass Konflikte sichtbar werden, bevor sie ein Problem verursachen. Die Erstellung erfordert fünf Schritte.

Identifizieren Sie die kritischen Prozesse. Beginnen Sie mit allem, was Geld bewegt, Zugriff ändert oder Produktion betrifft: Lieferantenzahlungen, Gehaltsänderungen, Code-Bereitstellung, Credential- und Tresor-Administration.
Listen Sie jede beteiligte Rolle auf. Schließen Sie Jobtitel-Rollen (Kreditorenbuchhalter, DevOps-Engineer) und Systemrollen (Tresor-Administrator, Genehmiger) nebeneinander ein.
Ordnen Sie Rollen Aktionen zu. Erstellen Sie ein Raster mit Rollen auf einer Achse und Aktionen — wie Erstellen, Genehmigen, Ausführen und Aufzeichnen — auf der anderen. Markieren Sie jede Aktion, die jede Rolle derzeit ausführen kann.
Kennzeichnen Sie die Überschneidungen. Jede Rolle, die denselben Prozess sowohl initiieren als auch genehmigen kann oder sowohl ausführen als auch aufzeichnen kann, ist ein Konflikt.
Lösen Sie jeden Konflikt. Weisen Sie die Rolle neu zu, teilen Sie den Prozess auf zwei Rollen auf, oder dokumentieren Sie — wo eine Neuzuweisung nicht praktikabel ist — eine kompensierende Kontrolle.

Ein kleines Arbeitsbeispiel — drei Rollen gegen drei Aktionen in einem Kreditorenprozess:

Rolle	Lieferant erstellen	Zahlung genehmigen	Hauptbuch abstimmen
Kreditorenbuchhalter	Ja	Nein	Nein
Finanzmanager	Nein	Ja	Nein
Prüfer	Nein	Nein	Ja

Keine einzelne Zeile kann jede Spalte abhaken. Das ist die Matrix, die wie beabsichtigt funktioniert.

Präventive vs. detektive SoD-Kontrollen (und kompensierende Kontrollen für kleine Teams)

Präventive SoD-Kontrollen stoppen eine konfligierende Zuweisung, bevor sie passiert — normalerweise durch Blockieren einer Rollenkombination im Zugriffssystem selbst. Detektive Kontrollen erkennen Konflikte im Nachhinein durch Audit-Trails und regelmäßige Zugriffsüberprüfung. Kompensierende Kontrollen ersetzen beide, wenn ein Team zu klein ist, um einen Prozess vollständig zu trennen.

Präventive Kontrollen sind die stärksten, weil sie die Gelegenheit vollständig beseitigen. Ein Rollensystem, das einem Konto nicht erlaubt, gleichzeitig „Genehmiger" und „Antragsteller" für denselben Workflow zu sein, lässt den Konflikt gar nicht erst entstehen.

Detektive Kontrollen akzeptieren, dass eine gewisse Überschneidung unvermeidlich ist, und erkennen sie stattdessen. Ein Audit-Trail, der aufzeichnet, wer einen Datensatz erstellt hat, wer ihn genehmigt hat und wer danach darauf zugegriffen hat, lässt einen Prüfer einen Konflikt während einer Zugriffszertifizierung erkennen, selbst wenn das System ihn zugelassen hat.

Die meisten SoD-Richtlinien setzen eine dedizierte Identity Governance and Administration (IGA)- oder GRC-Plattform voraus, die kontinuierliche Konfliktprüfungen durchführt. Kleine IT-Teams haben selten dieses Budget, und die meisten Richtlinien überspringen, was stattdessen zu tun ist.

Vier kompensierende Kontrollen decken den größten Teil der Lücke ab. Nennen Sie es die Vier-Kontrollen-SoD-Basis:

Trennen Sie Rollen, wo immer die Personalstärke es erlaubt
Leiten Sie alles, was nicht getrennt werden kann, durch einen zweiten Genehmiger
Protokollieren Sie jede privilegierte Aktion in einem exportierbaren Audit-Trail
Überprüfen Sie den Zugriff nach einem festen Zeitplan statt nie

Keine der vier erfordert eine GRC-Plattform. Alle vier erfordern jemanden, der den Zeitplan verantwortet.

Funktionstrennung und Compliance-Rahmenwerke

Funktionstrennung erscheint namentlich oder als Anforderung in den meisten großen Compliance-Rahmenwerken, obwohl das rechtliche Gewicht je nach Branche und Rechtsordnung variiert. SOX bindet sie an Kontrollen für die Finanzberichterstattung, NIST und ISO rahmen sie als allgemeine Sicherheitskontrolle, und NIS2 integriert sie in die Anforderungen an Zugriffskontrollrichtlinien für wesentliche und wichtige Einrichtungen in der EU.

Keines dieser Rahmenwerke liefert eine fertige SoD-Matrix. Sie verlangen, dass die Organisation eine hat und zeigen kann, wie Konflikte gelöst werden.

Rahmenwerk	Was es verlangt	Verweis
SOX	Dokumentierte interne Kontrollen für die Finanzberichterstattung, einschließlich Zugriffskontrollen, die verhindern, dass eine Person bestimmte Transaktionen allein abschließt	SOX Section 404, SEC Small-Business Guide
NIST SP 800-53 Rev. 5	Organisationen definieren und dokumentieren individuelle Aufgaben und konfigurieren dann den Systemzugriff so, dass keine Aufgabenkombination einem Konto ermöglicht, einen sensiblen Prozess allein abzuschließen	NIST AC-5, Kontrolle AC-5
ISO/IEC 27001:2022	Funktionstrennung als benannter Kontrollbereich, der abdeckt, wie konfligierende Aufgaben und Verantwortlichkeiten getrennt werden	ISO/IEC 27001:2022, Annex A Kontrolle 5.3
NIS2-Richtlinie	Wesentliche und wichtige Einrichtungen implementieren Maßnahmen, die Personalressourcensicherheit, Zugriffskontrollrichtlinien und Asset-Management abdecken	NIS2-Richtlinie, Artikel 21, Art. 21(2)(i)

Das Section-404-Mandat von SOX ist dasjenige, auf das die meisten compliance-getriebenen SoD-Programme reflexartig verweisen, obwohl es spezifisch für die Finanzberichterstattungskontrollen börsennotierter Unternehmen gilt, nicht für jedes Rahmenwerk in dieser Tabelle. Ob SoD für eine bestimmte Organisation rechtlich erforderlich ist, hängt von Branche, Rechtsordnung und den anwendbaren Rahmenwerken ab. Ein Compliance- oder Rechtsteam ist die richtige Quelle für diese Bestimmung. Diese Tabelle ist eine Übersicht, keine Rechtsberatung.

Wie Passwork Funktionstrennung im Tresor durchsetzt

Passwork integriert Funktionstrennung über vier Mechanismen in den Tresor: nicht entfernbare Admin-Rollen, benutzerdefinierte RBAC-Rollen, AD/LDAP-Gruppensynchronisation und einen exportierbaren Audit-Trail. Zusammen trennen sie, wer einen Tresor erstellt, von dem, wer ihn dauerhaft kontrolliert, und verwandeln die Zugriffsüberprüfung von einer manuellen Nachverfolgung in einen geplanten Export.

Tresor-Richtlinien weisen Administratoren auf Tresor-Typ-Ebene zu, nicht demjenigen, der den Tresor zufällig erstellt. Eine Tresor-Richtlinie definiert, welche Unternehmensadministratoren automatischen, nicht entfernbaren Zugriff auf jeden Tresor dieses Typs erhalten, sodass die Person, die einen neuen Abteilungstresor erstellt, später nicht stillschweigend die Aufsicht entfernen kann. Das ist eine präventive Kontrolle: Der Konflikt zwischen „Ersteller" und „dauerhafter Admin" bekommt nie die Chance, sich zu bilden.

Rollenverwaltung in Passwork

Benutzerdefinierte RBAC-Rollen trennen Konto- und Benutzerverwaltung vom täglichen Tresorzugriff. Passwork bietet drei integrierte Rollen — Besitzer, Administrator und Mitglied — und unterstützt unbegrenzte benutzerdefinierte Rollen mit Geltungsbereich über Kontoeinstellungen, Tresorverwaltung, Benutzerverwaltung, Authentifizierungsmethoden und API-Zugriff. Siehe Entwurf einer Enterprise-RBAC-Richtlinie für die Strukturierung von Rollen vor dem Rollout. Eine für einen Helpdesk-Techniker erstellte Rolle benötigt keine Tresor-Richtlinien-Berechtigung und muss sie auch nicht tragen.

AD/LDAP-Gruppensynchronisation setzt die präventive Kontrolle in großem Maßstab durch. Anstatt dass ein Administrator manuell überprüft, wer zu welcher Passwork-Gruppe gehört, steuert die Verzeichnisgruppenmitgliedschaft dies. Wenn HR jemanden in Active Directory in ein anderes Team versetzt, folgt der Passwork-Zugriff automatisch, und das Entziehen konfligierender Zugriffsrechte bei Rollenwechseln hängt nicht mehr davon ab, dass jemand daran denkt, ein Ticket zu erstellen.

Aktivitätsprotokoll in Passwork

Das Aktivitätsprotokoll ist die detektive Schicht. Es zeichnet Tresor-, Ordner-, Passwort- und Kontoebenen-Ereignisse auf, filterbar nach Datum, Benutzer und Aktionstyp und exportierbar nach Syslog, Windows Event Viewer oder ein SIEM. Für einen Prüfer, der Nachweise einer Zugriffsüberprüfung sehen möchte, ist ein exportierbares Protokoll der Unterschied zwischen einer echten Antwort und einem Versprechen. Vollständige Details zu Passworks Zugriffsverwaltungsfunktionen zeigen, wie diese Teile zusammenpassen.

Checkliste für Funktionstrennung

Verwenden Sie diese Checkliste, um von einer Ad-hoc-Zugriffskonfiguration zu einem dokumentierten Funktionstrennungsprogramm zu gelangen — mit oder ohne dedizierte GRC-Plattform.

Erfassen Sie jeden kritischen Prozess, der Geld bewegt, Zugriff ändert oder Produktion betrifft.
Erstellen Sie eine Funktionstrennungsmatrix und kennzeichnen Sie jede Rolle, die dieselbe Aktion sowohl initiieren als auch genehmigen kann.
Weisen Sie nicht entfernbare Administratoren pro Tresor- oder Richtlinientyp zu, sodass die Aufsicht nicht davon abhängt, wer die Ressource erstellt hat.
Aktivieren Sie die AD/LDAP-Gruppensynchronisation, damit Zugriffsänderungen Verzeichnisaktualisierungen folgen statt manuellen Tickets.
Aktivieren Sie exportierbare Audit-Protokollierung für jede privilegierte Aktion.
Planen Sie regelmäßige Zugriffsüberprüfungen — häufiger für Hochrisiko-Rollen als für Standard-Rollen.
Dokumentieren Sie kompensierende Kontrollen überall dort, wo eine strikte Trennung nicht machbar ist, und erfassen Sie, wer für jede verantwortlich ist.

Das Fazit

Funktionstrennung funktioniert als fortlaufende Designdisziplin: Jedes Mal, wenn sich eine Rolle ändert, ein Tresor erstellt wird oder eine neue Pipeline in Produktion geht, ist die Frage dieselbe. Kann ein Konto dies allein abschließen? Wenn ja, ist das ein Konflikt, der auf einen Vorfall wartet, der ihn aufdeckt.

Die Matrix und die Compliance-Verweise sind wichtig, aber die tägliche Arbeit ist operativ: nicht entfernbare Admins, synchronisierte Gruppen, ein Audit-Trail, den tatsächlich jemand liest. Dort hält SoD — oder hört stillschweigend auf, relevant zu sein.

Beginnen Sie damit, Ihren sensibelsten Tresor aufzurufen und zu prüfen, wer dort unkontrolliert erstellen, genehmigen und den Zugriff prüfen kann.

Wenn ein Admin in diesem Tresor unkontrolliert erstellen, genehmigen und den Zugriff prüfen kann, beheben Sie das, bevor ein Audit es für Sie findet. Starten Sie eine kostenlose Testversion von Passwork und richten Sie Tresor-Richtlinien ein, die diese Rollen von Anfang an trennen.

Häufig gestellte Fragen zur Funktionstrennung

Ist Funktionstrennung dasselbe wie Least Privilege?

Nein. Least Privilege begrenzt, wie viel Zugriff eine Person hat. Funktionstrennung stellt sicher, dass keine einzelne Person einen gesamten sensiblen Prozess allein abschließen kann, selbst innerhalb ihres erlaubten Zugriffs. Ein eng begrenztes Konto kann SoD immer noch verletzen, wenn es das einzige Konto ist, das sowohl an der Autorisierung als auch an der Ausführung einer Transaktion beteiligt ist.

Gilt Funktionstrennung für Maschinen- und Dienstkonten?

Ja. Automatisierungsskripte und Dienstkonten können konfligierende Berechtigungen genauso wie Menschen haben — zum Beispiel eine Pipeline, die sowohl Code bereitstellt als auch ihre eigene Bereitstellung genehmigt. SoD-Überprüfungen sollten Dienstkonten und Automatisierungsidentitäten neben menschlichen Konten einschließen, insbesondere da CI/CD-Pipelines und KI-Agenten mehr privilegierte Aktionen unbeaufsichtigt übernehmen.

Ist Funktionstrennung rechtlich vorgeschrieben?

Das hängt vom Rahmenwerk und der Branche ab. SOX Section 404 bindet sie an Finanzberichterstattungskontrollen für börsennotierte Unternehmen. NIST, ISO 27001 und NIS2 behandeln sie als erwartete Sicherheitskontrolle und nicht als eigenständiges rechtliches Mandat. Prüfen Sie, welche Rahmenwerke für Ihre Organisation gelten, bevor Sie einen einzelnen Verweis als pauschale Anforderung behandeln.

Wie setzen kleine Teams SoD ohne dedizierte GRC-Plattform durch?

Durch kompensierende Kontrollen: Rollen trennen, wo immer die Personalstärke es erlaubt, unvermeidbare Überschneidungen durch einen zweiten Genehmiger leiten, jede privilegierte Aktion in einem exportierbaren Audit-Trail protokollieren und Zugriff nach einem festen Zeitplan überprüfen. Nichts davon erfordert Identity-Governance-Software, obwohl dennoch jemand den Zeitplan verantworten muss.

Wie oft sollte eine Funktionstrennungsmatrix überprüft werden?

Überprüfen Sie Hochrisiko-Rollen wie Tresor- oder Systemadministratoren monatlich. Mittleres Risiko kann einen vierteljährlichen Zyklus haben. Überprüfen Sie auch sofort nach jeder Rollenänderung, da dann am häufigsten neue Konflikte entstehen.