S 4.262 Configuration of additional SAP authorisation checks

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

An SAP system allows you to change the preconfigured authorisation checks (see S 2.342 Planning of SAP rights). Authorisation checks may be disabled. Additional authorisation checks may also be performed. These capabilities must be taken into consideration within the framework of authorisation planning. In general, consideration should be given to the following when changing the authorisation checks:

Disabling authorisation checks

Disabling existing authorisation checks may pose a threat to the security of the SAP system, since this also disables access controls. The effects of disabling a check on the security of the system must be examined carefully before disabling the check.

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

Creating transactions to start programs or generate reports

Programs can be started and reports generated using transaction SE38 (ABAP Editor), for example. Not every program or report is assigned a transaction code, though. If users are to be provided with certain programs or reports, it is recommended to make them available using a transaction. The advantage is that access to the transaction and therefore to the program or report can be protected using S_TCODE type authorisations. In addition, access to transaction SE38 can be blocked, since it can be used to execute any code in principle.

It must also be considered when using this method that the authorisations created by the Profile Generator to call programs or reports must be maintained continuously. For this, the authorisations derived from the S_PROGRAM authorisation object must be modified in the role authorisation profiles according to the authorisation plan.

Use of parameter transactions

Parameter transactions can be created to define values or ranges of values for the call parameters regarding transactions. Access to the newly created parameter transactions (transaction SU93) can then be restricted using custom authorisations (authorisation object S_TCODE).

Here, it is important to take into consideration that parameter transactions are not suitable for being used as a security method for restricting access to the functions of the transaction or to data. In general, access to programs, reports, or tables, for example, always needs to be restricted using the corresponding authorisation object (S_PROGRAM for programs and reports, S_TABU_DIS for tables).

Modifying the ABAP authorisation groups

So-called authorisation groups can be defined for programs, reports, and tables. This allows grouping of authorisations so that access to the programs, reports, or tables of a group can be controlled using a single authorisation object.

The following must be taken into consideration when using ABAP authorisation groups:

• Access is always regulated for all objects in a group.
• The authorisation group represents an additional type of check. The normal authorisation checks conducted by the program or report are not affected by the authorisation groups.
• If authorisation groups are used, it is possible to roughly divide the authorisations into groups, for example through individual applications or modules, during the planning phase. These groups can then be further refined according to the protection requirements desired.
• The planners and administrators must be familiar with the exact method of operation of authorisation groups and with their administration.

References to additional information on the configuration of authorisation groups can be found in S 2.346 Use of the SAP documentation.

Additional custom authorisation objects

If the company or government agency has developed its own (ABAP) programs or has modified the program code of existing programs, authorisation checks may also be enabled for the new authorisation objects defined by the company or government agency. In order for the Profile Generator to take into account these new authorisation objects, their check indicators must be defined and modified accordingly using transaction SU24. Such changes may only be made within the framework of the change management processes.

Documenting changes

All changes to authorisation checks must be documented.

Review questions:

• Are authorisation checks only disabled after careful examination?
• Are the authorisations for calling programs or reports generated with the help of the SAP Profile Generator maintained according to the authorisation plan?
• Are the planners and administrators familiar with the exact method of operation of SAP authorisation groups and with their administration?