Critical authorizations and segregation of duties conflicts (SoD conflicts) are part of everyday life for authorizers. However, this does not make dealing with them any less challenging. Especially because different authorizations can be considered critical in every company. We explain how you can identify critical authorizations and how you can minimize the risk.
Roughly speaking, authorizations are considered critical if they endanger either the system itself or the integrity of the data within the system. There are some authorization objects and, above all, authorization combinations that always represent a risk and should therefore only be assigned very restrictively (or not at all – in production systems, for example). However, there are also authorizations that are only classified as critical for certain industries – for example, if industry-specific legislation requires special protection. And finally, every company can and should have its own security and authorization concept that contains individual regulations on critical authorizations.
Critical authorizations: System, user, data
Basically, there are three major gateways for security risks in an SAP system: the system itself, the user administration and the data with which the system operates. The risk of security breaches increases if the wrong users have authorizations with which they can manipulate the system, manage users or change data without an additional control instance (dual control principle).
Important: Even “harmless” authorization objects can become a security risk – if their characteristics or combination with other objects leads to over-authorization.
Critical system authorizations
When it comes to the SAP system itself, authorizations for debugging, developer authorizations, authorizations for managing background jobs, transport authorizations, spool authorizations or authorizations for creating and managing RFC connections are critical. However, this is only a small selection.
Authorization objects that can pose a risk on the system side are for example (exemplary, incomplete list!):
- S_BTCH_ADM
- S_BTCH_JOB
- S_BTCH_NAM
- S_ADMI_FCD
- S_LOG_COM
- S_RZL_ADM
- S_SPO_ACT
- S_SPO_DEV
- S_DEVELOP
- S_DBG
- S_TRANSPRT
Depending on their characteristics, these authorization objects allow changes to the system settings, including the security settings. They should therefore be assigned as rarely and as restricted as possible.
Critical authorizations User administration
Anyone who can create, delete or manage users can theoretically also grant unauthorized persons access to the system and the data processed therein. This is particularly risky if the user not only has rights for user administration but also for role administration. For example, they could give their own user roles that grant them far more rights than they need or should have.
Caution: This also applies to profiles. For example, users could assign themselves and other users the SAP_ALL and SAP_New profiles.
Potentially critical authorizations with regard to user administration are hidden, for example, in the following authorization objects (exemplary, incomplete list!):
- S_USER_AUT
- S_USER_GRP
- S_USER_VAL
- S_USER_PRO
Transaction codes such as SU01 and of course PFCG should also be reserved exclusively for user or authorization administrators.
Here too, the risk often lies in the combination of different characteristics or authorization objects.
Critical data access
System authorizations and user/role administration primarily pose security risks for the availability and integrity of the system. However, it is also important to protect company data and processes.
Anyone with far-reaching table modification rights in the production system, for example, can manipulate company data and possibly cause considerable economic damage. This also applies to authorizations for opening and closing posting periods and the like.
Critical authorizations with regard to data are hidden (in addition to countless subject-specific and module-specific authorization objects), for example in:
- S_TCODE
- S_TABU_DIS
- S_TABU_CLI
- S_TABU_NAM
A good authorization concept is necessary to minimize security risks in this area. This regulates which specific authorizations users need, who is allowed potentially critical access and how this is monitored or mitigated.
Segregation of duties: avoiding SoD conflicts
To ensure a high level of data security, we work with role concepts in the SAP system that provide for clear segregation of duties (SoD). This means, for example: Whoever is allowed to place an order is not allowed to release it. To install control instances for these sensitive functions, the 4- or 6-eyes principle applies. To do this, we build a separate individual role for each function. However, this concept only works if the individual roles are never actually assigned at the same time.
This is important if you are working with composite or business roles. Make sure that no individual roles are combined here whose authorizations in combination could lead to an SoD conflict.
Uncover critical authorizations
So now you know roughly how to identify critical authorizations. But how do you find out whether critical authorizations or combinations of authorizations have been assigned in your system, or which ones and how many? There are several ways to do this:
- Use of external third-party tools
- Analysis via SAP GRC
- Analysis via SUIM or report RSUSR008_009_NEW
However, all three options require that you have defined a set of security rules. This is not necessarily your task as an authorized person. However, it is quite possible that you will be confronted with it. You can consult the DSAG audit guidelines (german) as a basis.
Good to know: You can use the RSUSR_UP_AND_DOWNLOAD_FOR_CA report to download the set of rules from the ABAP system (SUIM), add to it in Excel and upload it again.
Both the third-party tools and the SUIM report now check, either at user or role level, whether the authorizations and authorization combinations defined as critical in the set of rules are currently assigned.
Eliminate or avoid critical authorizations
You now have a detailed evaluation of critical authorizations in your (productive) system. Now it’s time to analyze them. The first step is to compare your evaluation with the existing authorization concept: In the best case scenario, this will define exactly who is allowed to have critical authorizations and authorization combinations. In these cases, you do not need to take any further action.
For all critical authorizations that are not documented in the authorization concept (or a separate security concept), you must take action. Otherwise, these cases will come to your attention during an audit at the latest.
You have the following options for dealing with critical authorizations:
- Extend authorization concept. It is possible that the authorization concept is outdated and does not yet contain any information on new authorization objects. In this case, this needs to be done now.
- Remove roles that lead to SoD conflicts or critical authorization combinations. Check whether the user really needs these roles. Often there is simply no delimitation if the user has taken on a new area of responsibility. This means they have the roles for their new job, but also those for their old job. The latter can easily be withdrawn. If the user still needs individual authorizations from the old roles, you must either create new roles or extend existing ones (compare with the authorization concept) or the user may have to fall back on emergency users (firefighters) whose use is properly documented and controlled.
- Remove authorizations from roles. The same applies here: If the user is actually dependent on the authorizations classified as critical, either the role concept and then the role(s) must be adapted. Or the user must switch to a firefighter.
- Mitigate risks. Your security rules should also contain mitigations in the event that authorizations are classified as critical but are granted deliberately. You can then use guidelines/profiles to mitigate a risk. Example: Debug permissions are considered critical, but with the mitigation rule “only for developers pre-productive” you can install the permissions in a pre-productive developer role.