S 4.261 Secure handling of critical SAP rights

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

Authorisations allowing operations that are considered critical in terms of security or for legal or business reasons are referred to as "critical authorisations" by SAP. Such operations include, for example, operations that can be used to commit fraud or used to read or modify important data and configurations.

Critical SAP authorisations generally need to be assigned with great care. For this reason, a plan for handling critical SAP authorisations must be drawn up in advance. Organisational and technical safeguards as well as processes must be implemented to ensure that the desired level of security is reached. The following text deliberately does not contain a list specifying the critical SAP authorisations, since such a list is always incomplete and would give administrators a false sense of security. In general, administrators will not check the list or add items to it in this case. However, the identification of SAP authorisations considered critical in terms of the specific use of the SAP system is an important step that must be performed in any case.

Identifying critical SAP authorisations, profiles, and roles

Due to the SAP authorisation concept, the criticality of an SAP authorisation also depends on the fields and field values of the authorisation objects. This applies especially to authorisations used in applications or modules and which therefore must be considered critical from a business perspective. It is therefore recommended to identify which authorisation object fields are critical in order to identify the critical authorisation objects. This is the only way to ensure they can be checked later, and knowledge of the critical authorisation objects is required to automate these checks. Examples of critical fields in authorisation objects are the fields called cost centre, company code, profit centre, or plant.

Critical SAP authorisations also include all authorisations used within the framework of SAP system administration. All such authorisations are derived from authorisation objects and start with the prefix "S_".

In addition to critical authorisations, it is also possible to identify critical profiles and roles contained in the default configuration of the SAP system. All profiles ending with "_ALL" must be considered critical, since these profiles are generally granted all authorisations relevant to a subsection of the system, an application, or a module. All roles containing the string "ADM" must be considered critical, since this string is generally used in the names of administrative roles.

When identifying the critical SAP authorisations, profiles, and roles, it must be noted that SAP provides a suggested naming concept, but that the names used by applications or by software developed in-house do not always comply with this concept. For this reason, it is also possible for critical authorisations, profiles, and roles to exist that do not conform to the SAP naming scheme.

In general, it is difficult to identify critical SAP authorisations. However, there are tools available for this purpose from SAP and third party manufacturers that can check for critical authorisations automatically. In this case, the SAP authorisations considered critical are generally defined by the manufacturer of the tool.

References to SAP documentation relating to authorisation checks can be found in S 2.346 Use of the SAP documentation. The identification of critical authorisations requires appropriate knowledge of the underlying authorisation checks.

Customising critical SAP authorisations, profiles, and roles

Once the critical SAP authorisations, profiles, and roles have been identified, they should be modified according to the authorisation plan. In particular, it is necessary when modifying profiles and roles used for system administration to take into account the effects of these changes on system functions. After customising, it is necessary to check the system to ensure it responds as desired and to see whether errors occur in the system. This customisation process may be complex and time-consuming when major changes are made to the predefined authorisations, profiles, or roles and should not be performed on the productive system.

Restricting the use of critical SAP system authorisations

Within the framework of authorisation planning, it is necessary to specify the rules for handling critical SAP authorisations, profiles, and roles. The following recommendations must be considered in this regard:

References to additional information on this subject can be found in S 2.346 Use of the SAP documentation.

Maintaining a list of critical SAP authorisations

Once the critical SAP authorisations have been identified, it is recommended to maintain a list of these critical SAP authorisations in the SAP system. The list can then be used to automatically check which users have been granted critical SAP authorisations. The list of critical SAP authorisations is maintained using transaction SU96. Report "RSUSR009" can be used to display which users possess at least one of the critical SAP authorisations.

Certain combinations of non-critical SAP authorisations may also be critical, because a certain combination allows a user to call one or more transactions identified as critical, for example. Here, an SAP system offers functionality for automatically searching for users possessing the authorisations necessary to call certain combinations of transactions. To use this functionality, it is necessary to maintain a list of critical combinations using transaction SU98 (maintain table SUKRI). Report "RSUSR008" can then be used to identify those users possessing a critical combination of SAP authorisations.

In newer SAP systems (version 6.20 and higher), report RSUSR008_009_new should be used, which replaces the functionality offered by report RSUSR008 and report RSUSR009.

The default lists of critical SAP authorisations and combinations of transactions contained in the SAP system should only be considered an example of such lists and should not be used to actually perform the checks. The lists must be created and maintained in-house. These lists may also be examined during audits performed in the context of the Sarbanes Oxley Act.

For the NetWeaver platform, SAP offers the SAP GRC Access Control tool at additional cost to perform the corresponding checks so that the corresponding risks can be detected automatically. Tools for such checks are also available from third party manufacturers.

Review questions:

© Federal Office for Information Security. All rights reserved.