The SAP system is based on tables. Most of the transactions that users use in their day-to-day work draw on data from tables. However, while table authorizations are necessary, they are also a security risk. That’s why we’re going to take a closer look at how you can authorize table access optimally.
One user wants to instruct salaries, another calls up a query and a third orders material from a supplier. Each of them accesses tables in the SAP system because the employees’ address and bank data, the data displayed by the query and the vendor master data are all stored in tables. Almost all users therefore need authorization to access tables.
At the same time, however, this sometimes sensitive data should only be accessible to those users who actually need it for their work. This is not just a data protection issue. If the wrong users gain access to bank and address data or payment transaction data, for example, there is also a real economic risk for your company.
That’s why you, as the authorizer, have to manage the balancing act here too: On the one hand, users should be able to work as smoothly as possible. On the other hand, you must protect the data and ensure that only the authorizations that are necessary are distributed.
How are tables authorized in SAP?
There are different ways of accessing tables. Most users do not even realize that they are doing this because they are working with transactions that only pull data from tables in the background. However, it is also possible to access tables directly. The transactions for this are considered critical in most companies. However, the assignment only becomes really risky if the underlying authorization objects are not properly defined.
Direct table access via transactions
You can call up tables directly using the following transactions:
- SE16 Data Browser
- SE17 General Table Display
- SM30 Standard Table Maintenance
- SM34 Viewcluster Maintenance
- SM31 Enhanced Table Maintenance
In order for the system to actually display data from the tables that you want to call up, you also need authorizations via the corresponding authorization objects.
Access via authorization objects
S_TABU_CLI
The object S_TABU_CLI has only one field: CLIIDMAINT. If this has the value “X”, the user is authorized to maintain tables across clients. S_TABU_CLI works in conjunction with S_TABU_DIS or S_TABU_NAM, which each regulate which tables the user is specifically authorized to edit. This authorization can be helpful for basic or technical users, for example. You should deactivate S_TABU_CLI in the roles for normal dialog users.
S_TABU_DIS
S_TABU_DIS allows or prohibits access to tables via table authorization groups. Many tables are already combined in such groups in the SAP standard system. To avoid having to authorize each table individually, you can use S_TABU_DIS to allow access to all tables in a group. You have two options here: You can assign pure display rights or allow editing of the tables (field: ACTVT).
Good to know: You can see which tables are in the individual table groups in the TDDAT table.
Even if the use of S_TABU_DIS seems convenient at first, it is often problematic. Standard table groups contain several 100 or even several 1000 tables. Nobody can really be sure whether the users need all these tables or what the risks are if you allow all these tables to be edited.
How you can still use S_TABU_DIS sensibly and safely is explained below.
S_TABU_NAM
S_TABU_NAM allows access directly at the level of individual tables. You can use this object to control exactly which tables users can see and which they can edit. The object offers two fields for this purpose: ACTVT (02 for edit and 03 for display) and TABLE (enter the names of the tables here).
S_TABU_LIN
If your company works with organizational criteria, the authorization object S_TABU_LIN may also be of interest to you. This allows you to release individual lines for the user rather than entire tables.
Good to know: S_TABU_LIN only applies if the organizational criteria you want to authorize are activated in the client in which you are working.
The object has 10 fields:
- ORGKRIT
- ACTVT
- ORG_FIELD1
- ORG_FIELD2
- ORG_FIELD3
- ORG_FIELD4
- ORG_FIELD5
- ORG_FIELD6
- ORG_FIELD7
- ORG_FIELD8
The ORG_FIELD fields contain the key fields from the table rows that the users are allowed to see. In the ORGKRIT field, enter the organizational criterion that you want to use for authorization. And ACTVT again allows the values 02 for edit and 03 for display.
You can find more detailed information on the use of S_TABU_LIN directly from SAP.
Secure table access
So now you know which transactions and authorization objects you need to check to find out how table accesses are authorized in your system. But how can you optimize the authorizations now?
Consider tables in the role concept
Before you think about the characteristics of the objects, you need a sensible concept. In the authorization and role concept, define which roles should be given the authorization to edit tables and which should only contain view authorizations. Specify which tables are required in which role. And, if necessary, differentiate between normal users and key users.
An example: Employees in HR need access to various PA tables. All HR roles receive display authorizations for these tables. However, you differentiate between the editing authorizations. For example, you only provide change authorizations for the PA0003 (payroll status) and PA0008 (basic pay) tables for payroll accounting employees.
Tip: If you are not sure which tables are required, trace relevant users for a specific time period (STUSERTRACE). You can also restrict the trace to the objects S_TABU_DIS and S_TABU_NAM. In this way, you can see exactly which tables the user accesses in their day-to-day work and can assign the roles accordingly.
Restrict table authorizations
As already mentioned, table accesses are primarily authorized via the objects S_TABU_DIS and S_TABU_NAM. Authorization via S_TABU_NAM is generally preferable. In any case, you should be cautious about assigning change authorizations and only include them in roles where they are actually needed.
Good to know: If you still want to work with table groups, create customer-specific groups and only add the tables that are really needed to them. Then authorize your own table groups instead of the standard ones.
You can also combine S_TABU_NAM and S_TABU_DIS. To take up our example from above: You could assign display authorizations for the “PA” table group to all employees in the HR department via the S_TABU_DIS object. This would allow the users to view more than 2000 tables that are summarized in this group. Because you have no way of estimating how great the risk would be with this quantity if the users also had change authorizations for this table group, you must find another way to do this. You could now use a trace to identify which tables are specifically required and release them for editing (ACTVT: 02) via the object S_TABU_NAM.
Convert table access to transaction
Customer-specific transaction codes are a particularly secure method of regulating table access. You can use transaction SE93 to create your own transaction codes for individual tables, but also for queries, for example. Users can then use these transactions to call up the tables.
The table authorization objects must also be set up accordingly in the background. However, you do not need to assign potentially critical transactions such as SE16.