In the years between 2000 and 2010 I have worked in an SAP R/3 environment as a developer of simple applications based on ABAP as well as forms with SAPscript. SAP developers require, apart from knowledge of programming, economic knowledge and they must be familiar with the processes of the company they work for so that they can write useful application for the business.
Back then, IT Security was not the biggest of all topics, even though there was sensitive data contained in SAP systems. Implemented security was limited to management of roles and the assignment thereof as well as permission objects. A possibility is to divide these roles into groups such as HR, Finances or Sales/Acquisitions. However, there is one group of users that doesn’t really fit: developers. They need not only permission to develop programs but also access to the data that they need to analyse. Apart from the challenge to assign the right permission objects to the developers, there’s another difficulty that has a massive impact on systems security: To hinder a user from bypassing the controls that are put in place.
Most programs in SAP R/3 are based on ABAP and therefore, the R/3 system has an extensive developer environment, complete with code editor and debugging. A SAP system topology is usually divided in three layers:
A program is created in the Developer System and is being transported to the other systems using the transport system (transaction code STMS). A developer needs extensive permissions in the Developer System but should have few rights as possible in the Production System.
In SAP, a program can be interrupted and debugged during runtime using breakpoints. By entering
/h in the command window, the debugger can be started during runtime of a transaction. This is a useful feature to analyse programs and should be used for testing purposes. However, the debugger can be used to circumvent security checks.
Critical data and functions should be protected from unauthorized access. In SAP’s concept, there are permission objects. During definition of such an object, SAP uses permission fields to direct permissions. Let’s create an object called
Z_FIRMA with the fields ACTVT@ and
ACTVT controls activity such as read or write.
ZFRMID controls access to various companies (ID of the companies). A developer can use
AUTHORITY-CHECK and the permission object
Z_FIRMA to check the permissions of users in his program. The code to do this could look as follows:
REPORT Z_SCIP_TEST. PARAMETERS p_zfrmid TYPE scarr-carrid DEFAULT 'SC'. AUTHORITY-CHECK OBJECT 'Z_FIRMA' ID 'ZFRMID' FIELD p_zfrmid ID 'ACTVT' FIELD '03'. IF sy-subrc = 0. SELECT ... ENDIF.
Before the program executes the data request, symbolised with
SELECT ..., it checks if the user has permission to execute that request. It checks in the userbase if the user has the permission object with the required activity as well as the company ID assigned to him. If the permission check using
AUTHORITY-CHECK comes back positive, then the system variable
sy-subrc carries the value 0. If the check is negative, the value is different.
This check can be bypassed using the debugger. For each call to
AUTHORITY-CHECK, there can be a breakpoint. This means that the program is being halted before each check of permissions so that the user can control the flow of the program. The user executes the function and can manipulate the value of
sy-subrc and set it to 0. This tells the program that he does indeed have the right to view data. Therefore every user with debug rights has the option to bypass implemented authorization checks. Especially in Production Systems the debug rights should be handed out very carefully.
Apart from confidentiality, the integrity of data is an essential component of a system’s security. SAP R/3 systems have a changelog for base data in order to record changes as well as being able to trace them. If, for example, the name of transaction MM02 is being changed, the system generates an entry in the changelog that contains the ID of the user that changed it as well as other data. This way, changes can be monitored.
Using transaction SE16N the content of database tables can be displayed. Entering
&SAP_EDIT in the command window within the transaction, a user can activate the edit functionality and change data on the table level. If a user opens the table MARA and changes the name of the material using
&SAP_EDIT then there’s no changelog entry. Therefore, rights to use
&SAP_EDIT should not be handed out in a Production System.
These two examples show that it’s immensely important to have a well thought-out permission concept and have it implemented just as well. Each user, even privileged user groups such as developers or administrator, should only have the immediately necessary rights. These right should vary from system to system (Development, Production). A developer doesn’t need developer or debug rights in a Production System. These tasks can be completed in the systems designed for these functions. This is true for not only SAP systems but all other IT systems as well.
Our experts will get in contact with you!
Our experts will get in contact with you!
Further articles available here