ISO 27001: Funktionstrennung (SoD) in hybriden IT-Umgebungen

Stellen Sie sich eine Szene im Audit vor: Der Prüfer fragt, ob Ihr Entwickler Code in die AWS-Produktivumgebung deployen, gleichzeitig neue Benutzer im Active Directory anlegen und sich selbst erweiterte Rechte in Salesforce zuweisen kann. Plötzlich herrscht Stille im Raum.

In einer hybriden IT-Landschaft aus lokalen Servern, Cloud-Diensten und SaaS-Anwendungen ist genau das der Kern einer der größten Compliance-Herausforderungen. Klassische Modelle der Funktionstrennung stoßen an ihre Grenzen, wenn Berechtigungen über drei, vier oder fünf Systeme verteilt sind. Dieser Leitfaden zeigt, wie Sie die Anforderungen der ISO 27001 an die Funktionstrennung (Maßnahme A.5.3) in Ihrer hybriden Umgebung umsetzen und die nächste Audit-Frage souverän beantworten.

Was ist Funktionstrennung (SoD) nach ISO 27001?

Funktionstrennung (Segregation of Duties, SoD) ist ein Kontrollprinzip, das die ISO 27001 in Maßnahme A.5.3 fordert. Es stellt sicher, dass keine einzelne Person die alleinige Kontrolle über einen kritischen Prozess hat. Ziel ist es, Betrug, vorsätzliche Manipulationen und unbeabsichtigte Fehler zu verhindern. Die Norm formuliert die Anforderung bewusst offen: Aufgaben und Verantwortungsbereiche, bei denen ein Interessenkonflikt entstehen kann, müssen getrennt werden.

Das zugrunde liegende Prinzip ist das Vier-Augen-Prinzip, angewendet auf IT-Prozesse. Ein kritischer Vorgang wird in drei Phasen zerlegt: Initiierung (jemand beantragt eine Aktion), Genehmigung (eine unabhängige Person prüft den Antrag) und Ausführung (eine dritte Instanz führt die Aktion durch). Wenn alle drei Phasen in der Hand einer Person liegen, fehlt jede Kontrolle. Auditoren prüfen daher nicht nur, ob Rollen getrennt sind, sondern ob die Trennung auch technisch durchgesetzt wird.

In der Praxis heißt das: Es reicht nicht, im Organigramm unterschiedliche Zuständigkeiten auszuweisen. Die Systeme müssen so konfiguriert sein, dass eine Person physisch nicht in der Lage ist, alle drei Phasen allein zu durchlaufen. Genau hier wird es in hybriden IT-Umgebungen schwierig.

Für Auditoren ist die Funktionstrennung ein Kernpunkt bei der Überprüfung der Zugriffskontrolle. Sie suchen gezielt nach "segregated duties" und erwarten nachvollziehbare Prozesse. Die ISO 27001 ist dabei bewusst technologie-neutral: Sie schreibt nicht vor, wie die Trennung technisch realisiert wird (über Rollen, Workflows oder manuelle Freigaben), nur dass sie wirksam sein muss. Das macht SoD zu einer Management-Aufgabe, nicht nur zu einer technischen Konfiguration.

Das größte Missverständnis: "Wenn wir organisatorisch trennen, ist SoD erfüllt." Das ist falsch. Eine Trennung auf dem Papier ist nutzlos, wenn die technische Realität eine andere zeigt. Ein Mitarbeiter, der faktisch drei Zuständigkeiten in einem System bündeln kann, verstößt gegen SoD, unabhängig davon, wie das Organigramm aussieht.

Warum hybride IT die Funktionstrennung verkompliziert

Das Vier-Augen-Prinzip klingt simpel, solange alle Systeme unter einem Dach laufen. In der Realität sieht die IT-Landschaft der meisten Unternehmen aber anders aus: On-Premise-Systeme wie Active Directory und SAP, Cloud-Plattformen wie AWS oder Azure mit extrem granularen Berechtigungssystemen und SaaS-Anwendungen wie Salesforce oder Microsoft 365 mit jeweils eigenen, isolierten Rollenmodellen.

Das Problem: Ein Benutzer ist nicht mehr nur ein Benutzer. Er hat eine Identität im Active Directory, eine IAM-Rolle in AWS und ein Profil in Salesforce. Ohne eine einheitliche Sichtweise ist es unmöglich zu erkennen, ob die Kombination dieser Berechtigungen einen toxischen Konflikt erzeugt. In hybriden Umgebungen entstehen die meisten SoD-Konflikte an genau diesen Schnittstellen zwischen Systemen, weil jedes System seine Berechtigungen isoliert verwaltet.

Ein konkretes Beispiel: Ein IT-Administrator hat im Active Directory die Berechtigung, neue Benutzerkonten anzulegen. In AWS hat dieselbe Person eine IAM-Rolle, die den Zugriff auf Produktivdatenbanken erlaubt. Einzeln betrachtet sind beide Berechtigungen plausibel. In Kombination kann diese Person Konten anlegen und sich damit selbst Zugriff auf sensible Daten verschaffen. Klassische SoD-Prüfungen, die nur ein System betrachten, übersehen diesen Konflikt.

Hinzu kommt das Shared Responsibility Model der Cloud-Anbieter: Der Provider sichert die Infrastruktur, aber Sie sind für die korrekte Zuweisung von Rollen verantwortlich. AWS stellt Ihnen IAM-Rollen zur Verfügung. Ob diese Rollen ohne Interessenkonflikte zugewiesen werden, liegt allein bei Ihnen. Details zur Abgrenzung des ISMS-Geltungsbereichs in Cloud-Umgebungen finden Sie in unserem Artikel zum ISO 27001 Scope in Cloud-Umgebungen.

Der kritische Fehler tritt auf, wenn Unternehmen nicht verstehen, dass sie ihre Verantwortung nicht an die Cloud abwälzen können. Die Plattformen bieten die Tools (IAM, Rollen, Policies), aber nicht die Intelligenz, zu erkennen, dass eine bestimmte Rollenkombination riskant ist. Ein Beispiel aus der Praxis: Ein Entwickler, der vollständige AWS EC2-Rechte hat UND gleichzeitig Zugriff auf AWS Secrets Manager, kann sich selbst Passwörter für beliebige Systeme auslesen. Für AWS ist das völlig legitim. Für Ihr ISMS ist es ein Verstoß gegen A.5.3.

Deshalb ist ein zentrales Berechtigungsaudit über die Systemgrenzen hinweg die einzige Lösung. Sie müssen regelmäßig prüfen: Wer hat wo welche Rechte, und ergibt die Summe aller Rechte eines Nutzers einen Interessenkonflikt? Diese Übersicht entsteht nicht von selbst. Sie muss aktiv gebaut und regelmäßig aktualisiert werden.

SoD-Framework für hybride Umgebungen: 3 Kontrollbereiche

Um die Funktionstrennung in einer hybriden Welt auditsicher umzusetzen, brauchen Sie einen einheitlichen Ansatz, der alle Umgebungen abdeckt. Statt für jedes System eigene SoD-Regeln zu definieren, empfiehlt sich ein Framework, das On-Premise, Cloud und SaaS nach denselben Prinzipien behandelt. Die drei Kontrollbereiche spiegeln die typische IT-Landschaft wider.

Diese drei Bereiche sind nicht unabhängig. In einer hybriden Umgebung beobachten wir häufig folgendes Szenario: Ein Systemadministrator hat im Active Directory Rechte zur Benutzerverwaltung. Gleichzeitig sitzt er in einer Azure AD-Gruppe, die ihm Contributor-Rechte in Azure gibt. Drittens ist er ein Power User in mehreren SaaS-Applikationen. Einzeln: normal. Kombiniert: Er kann neue User anlegen, denen sofort Cloud-Resourcen zuweisen, dann deren Zugriff in SaaS-Tools freischalten, alles ohne externe Prüfung.

Das Paradoxe: Je "benutzerfreundlicher" moderne Cloud-Plattformen werden (One-Click-Provisioning, Self-Service-Portale), desto größer wird das SoD-Risiko, weil die Geschwindigkeit der Berechtigung überhaupt nicht abgestimmt ist mit der notwendigen Kontrolle. Eine Plattform wie SECJUR, die alle Systeme überblickt, ist deshalb nicht optional, sondern notwendig, um die Risiken überhaupt zu erkennen.

Für eine detaillierte Übersicht aller Zugriffskontroll-Maßnahmen nach ISO 27001 empfehlen wir unseren Artikel zur Zugriffskontrolle (Annex A.9).

SoD-Matrix erstellen: 5-Schritte-Anleitung für das Audit

Eine SoD-Matrix ist das zentrale Werkzeug, um Konflikte sichtbar zu machen und Auditoren eine nachvollziehbare Dokumentation zu liefern. Die folgende Anleitung führt Sie von der Identifikation kritischer Prozesse bis zur laufenden Überwachung.

Die praktische Erfahrung zeigt: Eine einmalige SoD-Analyse ist schnell überholt. In aktiven Organisationen entstehen ständig neue Berechtigungszuweisungen. Ein Mitarbeiter wechselt die Abteilung, seine alten Rollen werden vergessen. Ein neues Cloud-Projekt wird gestartet, ad-hoc werden Entwicklern administrative Rechte gegeben, "weil es schnell gehen muss". Nach einem Jahr ist die sorgfältig erstellte Matrix obsolet. Deshalb ist der fünfte Schritt kritisch: kontinuierliche Überwachung mit technischer Unterstützung. Manuell ist das nicht zu schaffen.

Eine typische SoD-Matrix für ein mittelständisches Unternehmen umfasst 50–100 kritische Prozesse, 200–500 Rollen und 2.000–5.000 Berechtigungszuweisungen. Jede Änderung potenziell kritisch. Eine Compliance-Plattform durchsucht diese Komplexität automatisiert, während Sie sich auf die strategischen Fragen konzentrieren: Ist die Kontrolle angemessen? Lässt sich das Risiko reduzieren?

Diese Prinzipien des Zugriffsmanagements sind auch für andere Regularien relevant. Das Risikomanagement nach ISO 27001 liefert die Grundlage, um die richtigen Prozesse für die SoD-Analyse zu priorisieren.

SoD-Compliance mit SECJUR automatisieren

Die manuelle Pflege einer SoD-Matrix über mehrere Systeme hinweg ist fehleranfällig und zeitaufwendig. Bei jedem Personalwechsel, jeder neuen Cloud-Rolle und jedem SaaS-Onboarding muss die Matrix aktualisiert werden. ISMS-Plattformen wie SECJUR Digital Compliance Office automatisieren die Definition von SoD-Richtlinien, die Überwachung von Berechtigungen über Systemgrenzen hinweg und die Erstellung von Audit-Nachweisen. Das reduziert den internen Aufwand erfahrungsgemäß um bis zu 50 %, weil Rollenmatrix, Kontrollnachweise und Berechtigungsreviews zentral auf der Plattform liegen.

Wichtig: Verlassen Sie sich nicht allein auf die vordefinierten Rollen Ihres Cloud-Anbieters. Sie sind dafür verantwortlich, wie diese Rollen zugewiesen und kombiniert werden. Eine Rolle wie "Contributor" in Azure ist mächtig und erlaubt weitreichende Änderungen an Ressourcen. Dokumentieren und begründen Sie jede einzelne Zuweisung. Auditoren erwarten, dass Sie erklären können, warum eine Person genau diese Kombination von Berechtigungen hat.

"Der häufigste Audit-Befund bei der Funktionstrennung: Unternehmen trennen Rollen organisatorisch, vergessen aber die technische Durchsetzung in der Cloud. Eine SoD-Matrix auf dem Papier reicht nicht, wenn die IAM-Konfiguration in AWS oder Azure diese Trennung nicht abbildet."

Amin Abbaszadeh, Informationssicherheitsexperte bei SECJUR

Fazit: Von der Komplexität zur Kontrolle

Die Funktionstrennung in hybriden IT-Umgebungen ist komplex, aber kein unlösbares Problem. Der wichtigste Schritt ist der Wechsel vom isolierten Systemdenken zu einem einheitlichen Framework: eine zentrale SoD-Matrix, die On-Premise, Cloud und SaaS zusammenbringt.

Drei Hebel machen den Unterschied. Erstens: Eine zentrale Sicht auf die kombinierten Berechtigungen eines Benutzers über alle Systeme hinweg. Zweitens: Technische Kontrollen (PIM, Just-in-Time-Zugriff, automatisierte Pipelines) statt rein organisatorischer Trennungen. Drittens: Regelmäßige Überprüfung der SoD-Matrix, idealerweise automatisiert.

Wer diese drei Hebel umsetzt, verwandelt ein potenzielles Audit-Risiko in einen Nachweis für robuste Governance. Die Anforderungen der ISO 27001 (A.5.3) sind dann kein Stressfaktor mehr, sondern ein Qualitätsmerkmal Ihrer IT-Organisation. Der Aufwand lohnt sich: Eine saubere Funktionstrennung reduziert nicht nur Audit-Befunde, sondern senkt auch das reale Risiko von Insider-Bedrohungen und Konfigurationsfehlern.