Background

Segregation of Duties (‘SoD’) is an important component of internal controls for any organization and needs to be managed for every IT system.  SAP ERP is often the crown jewel application for organizations using it and by its very nature, SoD is especially very important to enforce in SAP ERP system. However, SoD management in SAP ERP is unique due to the dynamic nature of the ‘SAP roles’. Let’s understand this:

1. SoD refers to ensuring that users do not have a combination of conflicting access (for example, creating vendor and processing invoice)
2. In most systems, these will be controlled through ‘system entitlements.
3. IGA solutions like SailPoint allows organization to define SoD policy as combination of ‘system entitlements’. Then these can be checked during access request (preventive controls) or reviewed/ reported (detective control).
4. IGA solutions treat ‘SAP roles’ as ‘system entitlements’ in SAP ERP system.
5. However, ‘SAP roles’ are dynamic and insufficient level to check SoD. For example, it is possible to create a SAP role called ‘Invoice Processing’ with access to create vendor.
6. In SAP, the access is managed at transaction code (tcode) and authorization (objects and field value). So, the SoD need to be managed at tcode and authorizations rather than ‘SAP role’ level.
7. Traditional tools such as SAP GRC Access Control has this ability, but traditional IGA solutions did not have this capability.

This blog will explain how an organization can use SailPoint to manage the SoD at granular tcode and authorization level. SailPoint has an add-on module Access Risk Management (‘ARM’, Access risk management – Products) to manage SAP SoD at tcode and authorization level.

But let’s first understand what tcode, authorization and roles mean in SAP.

SAP tcode and authorizations

Any function in SAP is performed through a ‘Transaction Code’. For example,

• ME21 – Create Purchase Order
• FB01 – Create Accounting Document
• XK06 – Delete Vendor Master
• VA03 – Display Sales Order

There is a large number of transaction codes in SAP. Additionally, organizations can also ‘develop’ their own transaction codes and these are referred as customized transaction codes.

While users execute these tcode to perform various tasks in SAP, SAP actually uses a concept of ‘authorization objects’ to control user access. Authorization checks based on authorization objects are embedded in SAP and protect various functions SAP. The SAP authorization model consists of the following components:

• Authorization Object
• Authorization
• Profile
• Role

Authorization Object is essentially the BUILDING BLOCK of access in SAP and access to a large number of tcodes are controlled using a very small number of authorization objects. They are used to create ‘Authorizations’, which are grouped together to provide specific access to users.

Please also note that users can ONLY be assigned Roles and/ or Profiles (and not tcode or authorizations directly).

SoD – role level or tcode/ authorization level?

What really matters in SAP is what ‘Authorizations’ users have. Roles (and Profiles) are just means to assign Authorization to the users. Therefore, checking what Role users have, is irrelevant. What really matters is what ‘Authorizations’ users have.

Note: Access to transaction code is also managed through a special Authorization Object S_TCODE.

And therefore, SoD need to be managed at authorization (and tcode) level rather than at Role level.

ISC Policy Management vs ARM

SailPoint Identity Security Cloud (‘ISC’) has a SoD functionality under Policy Management. It is possible to define combination of entitlements which cause SoD conflict. And this can be defined for entitlements within or across IT systems.

However, in SAP context, ISC recognizes SAP Roles as entitlements. And we just saw that SoD should be managed at authorization level. Therefore, ISC Policy Management function is generally insufficient to address SAP SoD requirements (except for very simple and basic setups!).

SailPoint positions a combination of ISC and ARM as recommended solution specifically to address this unique SoD requirement.

ARM provides multiple specific functionalities for access controls in SAP, which is illustrated below.

From SoD perspective, it provides granular SoD management at tcode and authorization level. It can be used both in preventive as well as detective approach:

1. Preventive approach: The access request are raised using the self service access request feature in ISC and the request includes access to SAP system, it is forwarded to ARM for SoD checks
2. Detective approach: ARM provides comprehensive reporting capabilities to identify users with SoD conflicts in SAP

Conclusion

Managing SoD in SAP  is unique and requires a focussed approach. It is important to align access management in SAP with rest of the enterprise IT systems instead of managing it in silo.

SailPoint provides this through the ARM add on module for ISC platform.