Business processes need to be safe, compliant, and efficient to ensure streamlined business operations. In SAP, Segregation of Duties (SoD) is a key principle in making this possible.
Typical SoDException Scenarios
Responsibilities and privileges which pose a conflict of interest may, at times, be assigned to a user. It may be that an employee is part of a small department or that security clearance prevents others from being involved. Irrespective of the reason, this user needs the ability to handle multiple steps in a business process, and an exception is made.
Here’s where things can get tricky. If a SoD exception is made, the standard preventive controls are no longer effective. This is a significant shortcoming of static, role-based SAP access controls.
You must now compile logs of access, root out false positives and, finally, send them to the appropriate control holders for review and sign-off. Detective controls, in addition to the extra overhead of manual checks and approvals, build room for human error and expand the dwelling time before red flags are caught.
SAP SoD Control: The Limitations
Preventive measures are a non-starter, lacking the logical capacity to decipher potential breaches from actual breaches. Preventive SAP access controls assess permissions based on two things: 1) a user’s role, and 2) the role-associated permissions. Although this works in the vast majority of cases, it takes controls with more granularity to incorporate SoD.
Real Violation OfSoD
The entire purpose of SoD is to remove conflicts of interest in business processes. However, conflicting transactions, unless the subject matter is the same, do not necessarily constitute a conflict of interest. For example, to create and approve multiple purchase orders, a user conducts the transactions. Looking at the transactions themselves, this process has the potential for infringement. Looking deeper into the PO data, you can see that the user never produced and acknowledged the same PO, so no infringement was made.
SAP will show you 1) the user and function, and 2) the executed transactions, but the third part is missing. And it is the field-level values in the PO itself. This lack of visibility into attributes is what makes preventive controls a non-starter and clutters SoD audit logs with false positives when exceptions have been created.
SoD Policy Enforcement: The Role Of Attribute-Based Access Controls
In authorization decisions, attribute-based access controls (ABAC) use “attributes.” These features may be anything from user details, such as a user’s location, department, nationality, or even the level of security clearance. In addition, access context such as IP address, location, time, device, and transaction history, can be taken into account. And most importantly, data attributes can now be used for SoD in authorization logic. This means that it is possible to leverage SAP field-level values to determine whether a transaction should be blocked or approved, and this information can be used for reporting activities.
The combination of SAP role-based access controls (RBAC) with the attribute-based access controls (ABAC) solution offers a wide range of business advantages for granular control and visibility.
A New Solution: RBAC + ABAC Hybrid Approach
The RBAC + ABAC hybrid approach opens up the possibility of applying preventive controls in SoD exception situations. By doing so, you can give users the flexibility that an exemption provides while still preventing any specific violations from happening.
Together, this hybrid approach (RBAC + ABAC) enables a dynamic SoD model to deter violations while allowing flexibility to delegate overlapping roles and enhancing role-based policies to address over-provisioning.