Authorization Management

Authorizations in SAP are very complex and are likely to be in a non-transparent device thereby often unsafe. From experience figures show that 40 to 60% of users too much or have incorrect permissions. Do you know the current state of affairs concerning authorizations?

• Is the system easy to maintain?
• Do I pay the appropriate license cost?
• Is clear who, which transactions can perform?
• Is the desired role separation also reflected in the system authorizations?
• Which user has access to which transactions?
• Does the special SAP users have the correct rights?
• Which user has access to which organizational units?
• Do I have the emergency access (emergency access) well regulated?
• Is my documentation in order?
• Do I have the SAP parameters set correctly?

2ARC offers the possibility to perform an authorization scan in 1 day within your company by making a snapshot of the current state of affairs. Interested in this? Please contact us.

l  KNOWLEDGE BASE  l  Also interesting to know …

Change management of authorization roles isn’t waterproof.
It can lead to more SoD conflicts!
– by Jos de Waal –

Authorization management and segregation of duties

When managing SAP authorizations in the production environment it is quite a challenge to ensure that the environment remains free of Segregation of Duties (SoD) conflicts.

Of course, GRC software packages offer tools to do this in a controlled manner. Notably for assigning additional roles to users, concrete solutions are provided for the complex matter of complying with job segregation requirements (SoD issues) within SAP authorizations. It is even more difficult to also control the deployment of role changes to the production system (assuming that such deployment is realized through DTAP^[1] transport route).
Below are some examples of controls that should be considered for changes of authorization roles.

Preventive control capabilities

One way to check this is to run a simulation in advance – that is: before processing the role change based on a request or a solution to an authorization issue in Production – using GRC software.

An alternative way is to perform an offline check based on a matrix of conflicting roles e.g. if single roles need to be added to a composite role. A system simulation can be performed at multiple points in the change process and has the advantage over a conflicting role matrix that accumulation of roles (aggregation of authorizations) is better included in the analysis. As such, a simulation with the help of GRC software provides a more complete and reliable view on the impact of role changes.

Controls not watertight

But either approach has the disadvantage that there is always a time lag between the moment of the check/simulation and the actual deployment in the production environment. Things may have changed in the meantime, so that the previous checks/simulations are no longer valid and therefore unexpected segregation of function conflicts on production may occur. Root causes of this could be that in the meantime transports of role changes have been deployed to the production environment or  users have been assigned other roles.

For a conflict matrix, the time lag is even longer because the matrix will have been drawn up some time before the check is carried out and may therefore at that moment already no longer correspond to the actual situation in the system. For a simulation, it is key that all users assigned to the role(s) to be changed on production, are actually included in the simulation.

Role design is crucial

It is therefore important to take the above into account when setting up the change management process. Two elements are important in the entire set-up anyway. Firstly, the role concept and how roles should be assigned to users (whether or not using composite roles, whether or not directly assigning single roles). Furthermore, the definitions of the SoD conflicts and notably the configuration of rule or function definitions (with the transactions and associated objects) determine which roles are critical for the segregation of duties conflicts. The structure and detailing of those definitions and configurations can complicate matters further.

The perfect solution is that only one composite role will be assigned to a user. All composite roles can then be well controlled in the change management process and finally ensure a clean (SoD free) deployment in production. As soon as more than one role is assigned to a user, the combinations may introduce unexpected segregation risks. The latter is often the case with organizations.

Detective checks always important

In order to keep the production environment as clean as possible, it is advisable to periodically carry out an integral check on SoD’s. The more of these controls, the better.

It doesn’t mean that simulations or the use of a conflict matrix make no sense. After all: prevention is better than cure. The more issues are addressed earlier, the less burden is put on the change management process and the better any extensive remediation processes can be prevented.

Conclusions regarding the change management process of the authorization roles

Good authorization management requires a solid base of preventive controls (role concept, clear SoD rules and change management on role changes). It can prevent occurrence of many unnecessary risks due to combination of functions, but is not waterproof! That is why the detective checks (periodic complete SoD scans) are just as important.

When coordinating the different control measures, the best possible balance should be sought between preventive and detective controls. The result may differ per organization, as it also depends on the organization’s risk profile and corporate culture.

[1] DTAP stands for Development, Test, Acceptance, and Production.

Knowledge Base ● Change management authorization role ● Sept. 2022