S 2.342 Planning of SAP rights

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Head of IT, Administrator

Explanation of the most important terms

The authorisations in an SAP system control the access capabilities of its users. For this reason, the security of the business data depends directly on the authorisation settings. The authorisation settings must therefore be planned and assigned carefully to reach the desired level of security.

The functions of an SAP system (e.g. the programs, reports, and in general, the applications in the SAP system) are called via transactions that are then able to execute different operations or perform different actions on data (e.g. read, write, or delete data). When called, the applications started by transactions check whether or not the user calling the application has the authorisations necessary to execute the operation requested on the data used by the application.

The check mechanism is based on the authorisation objects, which in turn contain authorisation fields. A specific authorisation can be understood as a version of an authorisation object with certain authorisation fields filled in. When starting a transaction, the SAP kernel first checks if the user has the authorisation to start the transaction. The transaction can also conduct additional authorisation checks after it has been started. In this case, the transaction checks whether or not the user requesting access has an authorisation that is derived from the authorisation object needed. If this is the case, the authorisation fields of the authorisation are checked to see if they contain the required values or combinations of values. A transaction can check for several authorisations in this case. The authorisations checked are specified in the program code. When a transaction is started, the SAP kernel always checks for the S_TCODE authorisation object. When an application is started, it checks for the S_PROGRAM authorisation object. The actual check is always performed by the kernel of the SAP system, even if the check was triggered by the program code of the transaction.

From the point of view of the applications, the authorisation fields of authorisation objects that need to be implemented as so-called organisational levels are particularly important. These fields authorise a role to execute a certain transaction, for example a transaction for the specified accounting code (which often refers to a contiguous business unit of a company, e.g. a subsidiary of the company).

Authorisations are assigned to users by assigning so-called roles to the users. Roles define which transactions are allowed to be executed by a user assuming the corresponding role. Since each transaction checks certain authorisation objects specified in the program code, an authorisation profile (i.e. a set of authorisations) can be derived for each role that contains all authorisation objects generally needed to execute the transactions. The process of creating the authorisation profile for a role and the transactions it contains can be automated using the Profile Generator (transaction PFCG).

Check indicators for transactions can be used to control which authorisation objects to be checked by a transaction are actually checked by the SAP kernel. As a result, it is possible using the check indicators to prevent certain authorisation objects from being checked when a transaction is called. In this case, the Profile Generator will not create any authorisation for the objects in the authorisation profile generated. The check indicators are administrated using transaction SU24; the values of the individual authorisation fields of the authorisation objects entered by the Profile Generator in the authorisations generated for the profiles are also administrated here. However, these values are only suggested values. The profiles created by the Profile Generator may still need to be edited manually under some circumstances.

Steps when planning the authorisation assignments

The authorisations in an SAP system are assigned in a multi-stage process. First, the roles needed must be defined. In doing so, it is important that the roles ultimately describe workplaces or positions in the company or government agency. The roles should not be based on an individual employee because this will result in such a large number of roles that they become too complex and unmanageable. The success or failure of an authorisation concept depends on whether or not the roles defined were defined carefully.

Once the roles are defined, the corresponding authorisation profiles must be created by the Profile Generator. The scope of the authorisations created in the role profiles is affected by the configuration of the check indicators. The check indicator configuration must also be planned carefully, since disabling a check always leads to a certain loss of security. The profiles created and the authorisations they contain must be checked and modified, if necessary.

After that, the authorisations are assigned to users by assigning a role to each user, which then triggers the so-called user comparison. The authorisations contained in the authorisation profile of the role are stored in the user master record when the user comparison is triggered.

Authorisation concept

Two versions of the authorisation concept for an SAP system must be created: for the ABAP stack and for the Java stack. Here, it must be taken into consideration that the authorisation system of the Java stack is fundamentally different from that of ABAP stack. The same questions need to be examined, though, in terms of their concepts. These questions include, amongst other questions:

It must be ensured that processes are defined and that the processes are fully specified for all operations arising in the context of authorisations. In addition, the corresponding responsibilities must be completely specified. This prevents security gaps from arising due to ambiguous assignments of responsibility or incompletely defined processes.

On the one hand, the roles and the corresponding authorisations must be defined based on the requirements of the organisation; on the other hand, the requirements resulting from general legal conditions such as the Control and Transparency in Business Act (KontrAG), the Generally Accepted Accounting Principles in Computer-Assisted Accounting Systems (GoBS), and the Federal Data Protection Act (BDSG) must also be taken into consideration. For this reason, detailed planning is essential. The more details are known about the requirements of the roles, the easier it is later to assign the authorisations. However, the necessary separation between the roles must be taken into account. It is recommended to adapt the roles, and therefore the authorisations, to the internal organisational hierarchy and the jobs and positions existing in the hierarchy. For example, it is possible to ensure that employees will not be able to use their old authorisations any more after changing positions.

It is also important to assign persons in charge of information and processes in the company or government agency (information owners and/or people in charge of procedures). These people are then responsible for a certain database of the organisation. For example, the Head of the Finance department (Chief Financial Officer, CFO) is responsible for the fields of finance and controlling. The persons responsible for each area absolutely must be involved when planning the roles, authorisations, and processes needed, since they are the only ones with the technical knowledge needed to plan the roles. Administrators are generally not able to plan the roles and authorisations at the application level themselves.

The following must also be specified within the framework of planning the authorisations:

Additional information on defining critical authorisations can be found in S 4.261 Secure handling of critical SAP rights.

The details of the concepts for the ABAP stack and the Java stack differ greatly. For the ABAP stack, authorisation management must be performed using the Profile Generator and should not be performed manually. In general, it is strongly recommended to refrain from manual administration, since manual administration often leads to incorrect authorisation configurations. Using the Profile Generator ensures that the users will only be granted the authorisations necessary to execute the transactions assigned to the users through the roles. For this reason, it is particularly important to produce concepts, processes, and procedures allowing for the use of the Profile Generator.

There is no choice, though, for the JAVA stack since the authorisation mechanism of the Java 2 Enterprise Edition (J2EE) specification must be used. It must be taken into consideration that the User Management Engine (UME) offers options that extend beyond the default options.

Additional information can be found in S 4.260 Rights management for SAP systems, in S 4.262 Configuration of additional SAP authorisation checks, and in S 4.268 Secure configuration of rights for the SAP Java Stack.

References to SAP documentation that can be used when planning the authorisation concept can be found in S 2.346 Use of the SAP documentation.

Planning authorisation management

Administration management must be planned and the desired administration concept must be defined. The most important thing to consider when planning the authorisation management process is which authorisation management tasks will be performed by whom. For this, it is recommended to use a role-based approach (see also S 4.260 Rights management for SAP systems) so that the roles defined can be assigned later to specific users and therefore to specific persons. It must be ensured in this case that no users are assigned two different, incompatible roles (separation of functions). Since there are a number of roles defined implicitly in an organisation for authorisation management, these roles must be modelled accordingly.

For example, there is generally never just one administrator role and the administrator role is instead usually divided into roles such as the user administrator, role administrator, authorisation administrator, developer, Help Desk employee, or transport manager. As a result, the predefined roles available in SAP normally should not be used without any adaptations.

Review questions:

© Federal Office for Information Security. All rights reserved.