Funktionstrennung (SoD)

Funktionstrennung (Segregation of Duties, SoD) soll verhindern, dass eine Identität Berechtigungen kombiniert, die getrennt bleiben müssen – etwa Kreditoren anlegen und Zahlungen buchen. Nova prüft dazu SoD-Regeln. Zwei Zusatzmodule erweitern die Prüfung für SAP.

SoD-Regeln

Eine SoD-Regel beschreibt ein Konfliktpaar: zwei Berechtigungen oder Business-Rollen („Seite A“ und „Seite B“), die nicht dieselbe Identität halten soll. Jede Regel hat einen „Schweregrad“ – „Kritisch“, „Hoch“, „Mittel“ oder „Niedrig“ – und lässt sich deaktivieren. Administratoren pflegen die Regeln unter „Compliance“ → „Risikoanalyse“ im Bereich „SoD-Regeln“. Die SoD-Regeln sind Teil von Nova und brauchen kein Zusatzmodul.

Nova bewertet dabei alle am Prüftag gültigen Zuweisungen einer Identität: direkte Berechtigungen, Business-Rollen und die Berechtigungen, die sie über Business-Rollen erhält.

Wann Nova prüft

Anlass	Geprüft wird	Ergebnis
neuer Antrag	Bestand der Ziel-Identität plus beantragte Rollen; nur Konflikte, zu denen der Antrag beiträgt	„Risiko-Befunde“ am Antrag
Scan	Bestand aller Identitäten außer deaktivierten und gelöschten	Register „SoD-Verstöße“
Rezertifizierung	Bestand der Identitäten im Scope	Hinweis „SoD-Konflikt“ am Eintrag

Zuweisungen, die nicht über einen Antrag entstehen – etwa direkt durch Administratoren oder über Org-Einheiten –, prüft Nova nicht vorab. Konflikte daraus erfasst der Scan.

Befunde zu einem Antrag zeigt Nova schon im Formular „Neue Anfrage“, danach in der Liste der Anfragen und in der Anfrage bei der betroffenen Rolle.

Reaktion bei Anträgen

Die „Risiko-Policy“ unter „Risikoanalyse“ legt fest, wie Nova auf Befunde reagiert. Voreingestellt ist „Nur warnen“.

„Risiko-Policy“	Wirkung
„Nur warnen“	Nova zeigt die Befunde am Antrag.
„SoD-Prüfschritt erzwingen“	Hat eine beantragte Rolle Befunde und enthält ihr Ablauf keinen Schritt „SoD-Prüfung“, hängt Nova einen solchen Schritt an.
„Antrag blockieren“	Bei Befunden legt Nova den Antrag nicht an. Administratoren können ihn mit einer „Übersteuerungs-Begründung“ trotzdem stellen.

• Einen Schritt „SoD-Prüfung“ entscheiden Identitäten mit der Berechtigung „SoD Reviewer“ oder „Security“. Wer ihn trotz offener Befunde genehmigt, muss einen Kommentar angeben; die Befunde gelten dann als übersteuert. Steht ein solcher Schritt ohnehin im Genehmigungsablauf, wird er auch bei „Nur warnen“ aktiv, sobald Befunde vorliegen; ohne Befunde überspringt Nova ihn.
• Administratoren können einzelne Befunde in der Anfrage mit „Übersteuern“ und einer Begründung übersteuern. Auch „Genehmigen (Admin)“ verlangt bei offenen Befunden einen Kommentar.
• Übersteuerungen protokolliert Nova mit Person und Begründung.
• Mit den Schaltern „SoD-Regeln“ und „GRC-Plugin“ legen Administratoren fest, welche Quellen die Prüfung einbezieht.
• Scheitert eine Prüfung technisch, legt Nova den Antrag trotzdem an und protokolliert den Fehler.

Register der SoD-Verstöße

„Scan starten“ unter „Risikoanalyse“ oder der Hintergrundjob „SoD-Verstoß-Scan“ gleicht den Bestand mit den aktiven Regeln ab; den Job legt Nova nicht selbst an. Das Ergebnis steht im Register „SoD-Verstöße“:

• Neue Konflikte erscheinen als „Offen“.
• Administratoren setzen einen Verstoß auf „Akzeptiert“ oder „Mitigiert“ – beides nur mit Begründung – oder öffnen ihn wieder.
• Findet ein Scan einen offenen oder akzeptierten Verstoß nicht mehr, setzt Nova ihn auf „Aufgelöst“. Taucht ein aufgelöster Konflikt wieder auf, öffnet Nova ihn erneut.
• Löschen Administratoren eine Regel, entfernt Nova auch deren Einträge im Register samt Begründungen. Beim Deaktivieren bleiben die Einträge erhalten.

Zusatzmodule für SAP

Beide Module sind ab Werk ausgeschaltet. Administratoren schalten sie unter „Administration“ → „Plugins“ ein.

„SoD-Analyse (SAP ABAP)“ prüft SAP-ABAP-Rollen in sich: auf kritische Einzelberechtigungen und auf Kombinationen, die nicht gemeinsam in einer Rolle vorkommen sollen. Grundlage sind die Berechtigungswerte der Rolle (Tabelle AGR_1251), die Nova per RFC aus dem SAP-System liest. Einlesen und Prüfen stoßen Administratoren an; beides läuft nicht automatisch. Betrifft ein SoD-Befund eines Antrags eine so geprüfte Rolle, speichert Nova deren Ergebnisse als technischen Nachweis mit dem Befund.

Beim Einschalten übernimmt das Modul das mitgelieferte Standard-Regelwerk – eine YAML-Datei –, sofern noch keine Regeln existieren. Eine Regel darin sieht so aus:

rules:
  - key: vendor_create_and_payment   # stabiler Schlüssel
    name: "Kreditor anlegen UND Zahlung buchen"
    risk: critical                   # critical | high | medium | low
    type: conflict_combo             # oder critical_single
    requires_all:                    # alle Bedingungen müssen zutreffen
      - { auth_object: F_LFA1_APP, field: ACTVT, values: ["01", "02"] }
      - { auth_object: F_BKPF_BUK, field: ACTVT, values: ["01"] }

Eine Regel vom Typ critical_single nennt statt requires_all eine einzelne Bedingung unter match. values: ["*"] trifft auf jeden Wert des Felds zu.

„GRC-Berechtigungsanalyse (SAP Access Control)“ liest das Regelwerk (Risiken und Funktionen) sowie die Zuordnungen von Rollen zu Konten aus einem vorhandenen SAP GRC Access Control. Bei Anträgen meldet Nova dann zusätzlich die Risiken, die die beantragten SAP-Rollen für die Ziel-Identität neu hinzufügen würden. Zur Antragszeit greift Nova dafür nicht auf SAP zu, sondern nutzt die zuvor gelesenen Daten.