Reporting and Documenting
Michael Schneider
SAP and Principle of Least Privilege
time to read: 6 minutes
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.
Bypass Authentication Checks Using the Debugger
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:
- Developer System
- Test System
- Production System
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 ZFRMID. 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.
Data Manipulation on Table Level
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.
The Principle of Least Privilege
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.
About the Author
Links
You need support in such a project?
Our experts will get in contact with you!
×
Introduction of CVSS v4.0
Michael Schneider
Rogue Device
Michael Schneider
Windows LAPS
Michael Schneider
You need support in such a project?
Our experts will get in contact with you!