Handbook

English

Deutsch

English

Deutsch

Appearance

Segregation of duties (SoD) ​

Segregation of duties (SoD) is meant to prevent an identity from combining entitlements that must stay separate – for example creating vendors and posting payments. For this, Nova checks SoD rules. Two add-on modules extend the check for SAP.

SoD rules ​

An SoD rule describes a conflicting pair: two entitlements or business roles (“Side A” and “Side B”) that the same identity should not hold. Each rule has a “Severity” – “Critical”, “High”, “Medium” or “Low” – and can be deactivated. Administrators maintain the rules under “Compliance” → “Risk Analysis” in the “SoD Rules” section. SoD rules are part of Nova and need no add-on module.

Nova takes into account all of an identity's assignments valid on the day of the check: direct entitlements, business roles and the entitlements received through business roles.

When Nova checks ​

OccasionWhat is checkedResult
new access requestexisting access of the target identity plus the requested roles; only conflicts the request contributes to“Risk findings” on the request
scanexisting access of all identities except disabled and deleted ones“SoD Violations” register
recertificationexisting access of the identities in scope“SoD conflict” flag on the item

Assignments that do not arise from an access request – for example those made directly by administrators or through org units – are not checked in advance. The scan picks up conflicts from such assignments.

Nova shows findings for a request already in the “New request” form, then in the list of requests and, within the request, next to the affected role.

Response to access requests ​

The “Risk policy” under “Risk Analysis” defines how Nova responds to findings. The default is “Warn only”.

“Risk policy”Effect
“Warn only”Nova shows the findings on the request.
“Require SoD review step”If a requested role has findings and its workflow contains no “SoD Review” step, Nova appends such a step.
“Block request”If there are findings, Nova does not create the request. Administrators can still submit it with an “Override justification”.
  • An “SoD Review” step is decided by identities holding the “SoD Reviewer” or “Security” entitlement. Whoever approves it despite open findings must enter a comment; the findings then count as overridden. If such a step is already part of the approval workflow, it becomes active under “Warn only” as well as soon as there are findings; without findings Nova skips it.
  • Administrators can override individual findings in the request with “Override” and a justification. “Approve (admin)” also requires a comment when findings are open.
  • Nova logs overrides with person and justification.
  • With the “SoD rules” and “GRC plugin” switches, administrators define which sources the check includes.
  • If a check fails for technical reasons, Nova still creates the request and logs the error.

SoD violations register ​

“Run scan” under “Risk Analysis” or the background job “SoD Violation Scan” compares existing access with the active rules; Nova does not create the job by itself. The result is kept in the “SoD Violations” register:

  • New conflicts appear as “Open”.
  • Administrators set a violation to “Accepted” or “Mitigated” – both only with a justification – or reopen it.
  • If a scan no longer finds an open or accepted violation, Nova sets it to “Resolved”. If a resolved conflict reappears, Nova reopens it.
  • If administrators delete a rule, Nova also removes its register entries, including the justifications. When a rule is deactivated, the entries are kept.

Add-on modules for SAP ​

Both modules are switched off out of the box. Administrators switch them on under “Administration” → “Plugins”.

“SoD-Analyse (SAP ABAP)” checks SAP ABAP roles internally: for critical single permissions and for combinations that should not occur together in one role. It works on the role's authorisation values (table AGR_1251), which Nova reads from the SAP system via RFC. Administrators trigger reading and checking; neither runs automatically. If an SoD finding on an access request involves a role checked this way, Nova stores that role's results with the finding as technical evidence.

When switched on, the module takes over the supplied default rule set – a YAML file – provided no rules exist yet. A rule in it looks like this:

yaml
rules:
  - key: vendor_create_and_payment   # stable key
    name: "Kreditor anlegen UND Zahlung buchen"
    risk: critical                   # critical | high | medium | low
    type: conflict_combo             # or critical_single
    requires_all:                    # all conditions must match
      - { auth_object: F_LFA1_APP, field: ACTVT, values: ["01", "02"] }
      - { auth_object: F_BKPF_BUK, field: ACTVT, values: ["01"] }

A rule of type critical_single names a single condition under match instead of requires_all. values: ["*"] matches any value of the field.

“GRC-Berechtigungsanalyse (SAP Access Control)” reads the rule set (risks and functions) as well as the assignments of roles to accounts from an existing SAP GRC Access Control. Nova then also reports, on access requests, the risks that the requested SAP roles would newly add for the target identity. At request time, Nova does not access SAP for this but uses the data read beforehand.

Nova IAM