S 4.264 Restricting direct table changes in SAP systems

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

The entire data of an SAP system is stored in the database tables of the SAP system. The tables are changed when the system is used, for example by the transactions, programs, or RFC modules called.

Restricting authorisations to table access transactions

In an SAP system, it is possible to access the content of the tables directly with read or modify privileges. Access to tables and the content of tables may be obtained using various transactions. Examples of such transactions include the SE16 Data Browser, SE80 Workbench, SE84 Repository Browser, SM30 Extended Table Maintenance, SM31 Table Maintenance, SE11 Data Dictionary, and SQVI Quick Viewer transactions.

Depending on the version of the SAP system and which additional applications and modules are installed, there may also be additional transactions or reports available that allow direct access to the tables.

Access to the transactions listed above should at least be restricted so that only authorised administrators or users can call them. The list of transactions to which access should be restricted for this reason must be expanded depending on how the local system is used. Access is configured using authorisation object S_TCODE.

It is recommended to check regularly which users are able to access transactions considered critical in this sense. To check this, you can use the user information system (transaction SUIM), for example, which can be used to search for users based on search criteria.

Transaction S_BCE_68001398 can be used to list the users who have access to a certain transaction. This transaction can be used to check individual users.

Configuring the table access authorisations

When direct access to the tables by the transactions cannot be restricted, it is still possible to control access to the tables directly using authorisations for the tables. The authorisation objects used for this purpose are S_TABU_DIS, S_TABU_CLI, and S_TABU_LIN. The authorisation object S_TABU_DIS can be used to assign authorisations to client-based table groups. These groups are defined in the TBRG table and divide the individual tables into groups. A corresponding authorisation group is defined for each table group using the TDDAT table. The names of the table authorisation groups are used as values in the DIBERCLS parameter to control access to the tables. The operations allowed are controlled using the ACTVT parameter. Similarly, authorisation object S_TABU_CLI can be used to assign authorisations to client-independent table groups.

It is absolutely necessary to use the S_TABU_DIS and S_TABU_CLI authorisation objects to control access to the tables if it is impossible to rule out the possibility of a transaction accessing the tables directly.

S_TABU_LIN can be used to assign authorisations to individual rows in a table. This mechanism requires the specification of additional customisation settings, though. In this case, organisational criteria must be defined and activated. Due to the complexity involved in defining the ranges of such authorisations, this object is seldom used in practical applications.

One commonly used method for permitting access to certain tables is to define parameter transactions. Parameter transactions are transactions that call other transactions with predefined values for the parameters. In the present case, transaction SE16 would be called directly with the desired table name. The table name is then defined as a suggested value for the "DATABROWSE-TABLENAME" parameter. Parameter transactions are defined using transaction SE93. When using this method, it must be noted that the access authorisations still need to be assigned for the tables using S_TABU_DIS, since parameter transactions are not suitable for being uses as an access control mechanism.

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

Review questions:

• Are only authorised SAP administrators or SAP users granted direct access to table transactions?
• Are regular checks performed as to which SAP users may access critical table transactions?