Zugriffsüberprüfungen und Funktionstrennung

Was hat sich geändert

Jede Inhaltsänderung wird versioniert. Wählen Sie eine Version, um sie mit der vorherigen zu vergleichen.

Version 5 → 6

Aktualisierung

Anhand der Produktdokumentation neu geschrieben. Diese Funktionen gehören zu Monosign, daher wurde der Kurs dorthin verschoben. Automatischer Widerruf, Framework-Berichte und die alten Durchsetzungsnamen wurden entfernt; stattdessen werden manuelle Behebung und die bekannten Lücken der Funktionstrennung behandelt.

1 Lektion aktualisiert

Inhaltliche Aktualisierung. Eingeschriebene Lernende wurden benachrichtigt.

Präventive Funktionstrennung

**Funktionstrennung (SoD)** verhindert, dass eine Person eine Kombination von Rechten hält, mit der sie einen Fehler oder Betrug begehen und verbergen kann, etwa einen Lieferanten anlegen und seine Zahlung genehmigen. ### Wo Regeln liegen Regeln sind **Trigger**, die in Monosign unter **Workflows → Triggers → Add New** erstellt werden. Setzen Sie **Category** auf **Segregation of Duties**, beschreiben Sie die toxische Kombination unter **Rules** mit Bedingungen wie `User.Permission`, `User.Role` oder `User.Group`, und begrenzen Sie unter **Scope**, wann sie gilt. Die ältere Maske **Security → Segregation of D.** ist nicht mehr erreichbar. ::diagram sar-sod-enforce-detect ### Durchsetzung und Erkennung sind getrennt Die **Decision** setzt die Regel im Moment einer Änderung durch: - **Allow** führt die Aktionen aus. - **Block (Veto)** lehnt das Ereignis ab. - **Require approval** leitet es an einen Genehmiger weiter, dessen Warteschlange der Tab **Approvals** unter **Triggers** ist. - **Allow & notify** erlaubt es, benachrichtigt aber und verlangt eine Begründung. Treffen mehrere Regeln zu, gewinnt das restriktivste Ergebnis. Löst die Auswertung einen Fehler aus, lautet das Ergebnis Ablehnung. **Category** wählt die Regel für den **erkennenden Scan** aus, der nach Personen sucht, die die Kombination bereits halten. Ergebnisse erscheinen unter **Identity → Visibility** als KPI **SoD violations** und als SoD-Chip. Das eine stellt das andere nicht ein; konfigurieren Sie also beides. > Tipp: Genehmigungen von Zugriffspaketen durchlaufen die SoD-Trigger nicht, daher hält eine Block (Veto)-Regel eine Kombination nicht auf, die über ein Zugriffspaket vergeben wird. Beziehen Sie auch Zugriffspakete in Ihr SoD-Design ein: Prüfen Sie, was jedes Paket vergibt, und kontrollieren Sie die Inhaber mit dem erkennenden Scan. Der Scan erfasst höchstens 3.000 Inhaber pro Trigger. ### Was zu tun ist - Der Scan läuft bei jedem Neuaufbau des Identity-Visibility-Graphen. Prüfen Sie seine Ergebnisse regelmäßig und teilen Sie den Trigger-Umfang, wenn eine Regel Tausende von Inhabern hat. - Prüfen Sie Definitionen von Zugriffspaketen von Hand auf toxische Kombinationen. - Muss ein Konflikt aus geschäftlichen Gründen bleiben, dokumentieren Sie eine kompensierende Kontrolle, etwa die Prüfung der Aktivität durch einen Vorgesetzten. > Tipp: Beginnen Sie mit wenigen Kombinationen, nach denen Ihre Prüfer bereits fragen, statt mit einer großen Matrix, die niemand pflegt.