For those that don't know SAP's authorization aspects this title might be just a tongue-twister.

On the contrary for those who manage authorizations in SAP these are very well-known authorization objects. How should you go about managing them?

Table protection in SAP

Hundreds of thousands of tables are defined in SAP. You can see them from the table's table, DD02L (this table contains all tables defined in SAP)

Direct access to tables should not be allowed to end users, this being said, it's frequent for transaction or functionalities (even standard ones) to need access to tables to work, when the user is operating on specific functions.

An example?

Exhange rates and posting periods. These tables are normally given to end users for management. Therefore, whoever needs to access those needs a proper authorization to them.

Until 2010 it was not possible to authorize to a single table in SAP. It was necessary to base the authorization on SAP tables authorization groups.

Every SAB table was (and still is) classified based on an authorization group. In one authorization group there can be many different tables.

To identify in which group a certain table is, you can use transaction SE54. By pressing on display, in the latest releases, it's possible to insert a table (or a number of tables) and check inside which groups they are. Usually the authorization groups are created by the developer.

MARA table (General Material Data) is inside MA group (which contains more than six hundred tables)

There is also a standard group called &NC& (Not Classified) where SAP inserted all the tables that are not considered critical. If a table is not classified, this group is checked anyway.

Which authorization objects exist for the protection of data in SAP?

They are many, even though the most known ones are the one listed in the title of this post. The complete list is the following:

• S_TABU_CLI Cross-Client Table Maintenance
• S_TABU_DIS Table Maintenance (using standard tools such as SM30)
• S_TABU_LIN Authorization for Organizational Unit
• S_TABU_NAM Table Access by Generic Standard Tools
• S_TABU_RFC Client Comparison and Copy: Data Export with RFC
• S_TABU_SQL Authorization object for SQL Command Editor

The most important is S_TABU_DIS, used to protect the display and writing of SAP tables, based on an authorization group (as mentioned above)

The DICBERCLS field contains the tables authorization group, while the ACTVT field contains the allowed activity, in this case:

• 02 Edit
• 03 Display (even this activity can be critical from a GDPR standpoint)
• BD in case the lock for customizing distribution must be ignored

The second object, introduced recently is S_TABU_NAM, which is the object that protects the access to tables (display, maintain or edit), cascading from S_TABU_DIS.

This object is made of two fields:

• ACTVT
• Table

In this case it's possible to specify the individual table/tables to authorize, without authorizing the whole group called for by S_TABU_DIS.

Keep in mind that from release SAP_BASIS 7.50 the check order is inverted: S_TABU_NAM is checked first, followed by S_TABU_DIS (3077347 - Replace S_TABU_DIS with VIEW_AUTHORITY_CHECK)

SAP also introduced a new report for easily understanding to which tables a certain user has access to

SUSR_TABLES_WITH_AUTH

With transaction SU24_S_TABU_NAM it's also possible to verify how the objects are managed inside transaction SU24

Keep in mind: if you defined an SoD Matrix, you could need to also update that in case object S_TABU_NAM is present

What should you use between the two?

It depends on some factors:

1. Are you installing a new system or are you in an existing one?
2. What level of segregation do you want to reach?

If you are in a new system you could start by only using S_TABU_NAM, but be careful: in some SAP transactions only the S_TABU_DIS object is present (in the transaction/authorization object link, in SU24) so you should first fix that, which can be a significant effort.

Once you start managing S_TABU_NAM you should always be consistent.

In systems that have been active for a long time, it might take a lot of time to convert DIS to NAM

You can also decide to manage the two objects at the same time: S_TABU_DIS generally, and S_TABU_NAM in specific cases.

Other objects linked to tables that are less frequently used

S_TABU_CLI object is used to authorize the change of a cross-client table. It's usually assigned to system admins

S_TABU_RFC object is used in the source system to test access via RFC to tables on other systems.

S_TABU_LIN object is used to segregate to the line level a table. It can be used to limit visibility to a table based on configurated criteria, for example the company code. 

S_TABU_SQL object is used when command execution functionalities via SQL are used, for example system transaction DB02

• S_TABU_SQL
• ACTVT 33
• DBSID LOCAL
• TABLE USR02
• TABOWNER SAPSR3

Blog post originally translated from https://www.aglea.com/blog/s_tabu_nam-s_tabu_dis-in-sap