For over 15 years I have worked for multiple companies that run their business on SAP software. In each of these companies requirements have dictated that additional custom tables are required to extend SAP functionality for reports or custom processes. Many of these companies also convert transportable tables into tables that are directly maintained in production. Whether the table was delivered by SAP or created custom, the authorization group has been the classic method of controlling access to tables in SAP. However, many application developers never define an authorization group for the table and accept the default value &NC& (Not Classified authorization group). Even SAP leaves many tables in the authorization group &NC& as they may have never been designed for direct table maintenance in a production environment.
When functional requirements direct a security architect to provide SE16/17, SM30/SM31 or other direct table access (SM34) to the authorization group &NC&, what is the risk? In most ECC environments you will find more than 10,000 tables assigned to the authorization group &NC&. Providing a user access to table maintenance transactions and access to the table through authorization object S_TABU_DIS creates excessive risk to potentially sensitive data.
Prior to the authorization object S_TABU_NAM, one of the methods to reduce risk was to create a parameter transaction and skip the initial screen. This allows access to the table but prevents access to other tables within the authorization group. However, if a user receives table maintenance transactions from another role, the parameter transaction protection is now useless. The user will have access to every table in the assigned authorization groups based on the restrictions in the S_TABU_DIS authorization object.
What can you do to reduce the risk of direct table access? The easiest method may be to use SE54 and change the authorization group to a different value. But what value do you use? Do you use an existing group or create a new one? What are the downstream dependencies? If a user needs access, roles and transaction tables will need to be updated. Within programs there may even be required logic changes when an authority check is performed. You move from the data risk of direct table access to potentially unknown side effects within SAP.
I believe there are several right answers to this question. First if you have custom tables that require direct table maintenance in production, the developer should assign a proper authorization group. This will reduce the risk from more than 10,000 tables to the tables within the related group. I believe you should never use the authorization group &NC& for tables maintained outside of a program which requires assigning S_TABU_DIS to the user. With enhancements to the VIEW_AUTHORITY_CHECK function module there is now a hierarchy of authorization checks. With the authorization object S_TABU_NAM you can eliminate the S_TABU_DIS authorization group assignment in many cases. The initial authority check for S_TABU_DIS and the table authorization group will fail. However, SAP then checks authorization object S_TABU_NAM for access to the specific table. With this you have reduced risk from all tables within the group to a single table.
This object alone does not solve all issues for direct table access, but it is a GIANT step in the right direction. SAP is even committed to gradually moving authority checks to S_TABU_NAM as maintenance occurs. I have even been working with SAP Global Support to correct transactions which were defined incorrectly. Rather than implement S_TABU_DIS in the SU22 values, SAP has delivered the correct values through S_TABU_NAM. If you want more details on this subject, check out the SAP Notes 1434284 and 1481950.
