The use of critical transactions is one of the most frequent items to be found on the lists of deficiencies prepared by auditors. And rightly so, since accessing SAP tables and ABAP programs with these kinds of transactions is unfortunately often associated with major security risks.
So how can you protect yourself from critical transaction accesses while ensuring your users have the permissions they need? Find out with our best practice tip.
The problem is of course not to be found in accesses to SAP tables or ABAP programs as such, but in the use of transaction calls such as SE16/SM30 or SA38. Particularly since these are all too rarely restricted to access to specific tables or ABAP programs.
The object S_TABU_NAM offers one option for setting restrictions to specific tables with its TABLE field. Note that the use of the conventional object S_TABU_DIS and field DICBERCLS has an additive effect, however. This means that if a user owns both objects with different definitions, this user is ultimately able to access a whole series of tables and the intended restriction disappears into thin air. It is astonishing how often we see this setup in practice. Table groups often have hundreds of tables assigned to them.
One possible approach for this example would be using S_TABU_NAM to authorize by specific table name. The same applies for the S_PROGNAM object with its P_PROGNAM field and counterpart S_PROGRAM. These can be used to restrict the execution of specific ABAP programs and program groups.
The securest way to authorize tables and ABAP programs, however, is to utilize a parameter transaction or report transaction – and these transactions are already provided by standard SAP for many tables and ABAP programs. If these are not available, you have the option of creating a new parameter transaction or report transaction with the help of SAP Basis transaction SE93 (maintain transaction codes).
This offers you the advantage of being able to create transactions for specific programs and tables, and easily authorize them for users via roles. And, on the other hand, completely avoid all use of the powerful – and therefore critical – transactions SE16/SM30 and SA38.
As a next step after creating a transaction, we recommend the parallel maintenance of the authorization default values (SUS24) with the specific object definitions S_TABU_NAM and S_PROGNAM. This ensures that the correct default values are always offered for future role maintenance work.
The SAST SUITE naturally offers you a more user-friendly way to automatically secure critical transactions. And the same applies for the one-click creation of a large number of transactions plus SU24 updates.
Talk to use today – we look forward to helping you: knowhow@akquinet.de
Or attend one of our webinars: these are a time-saving way to find out more about these and other current topics in SAP security and compliance – live and designed to provide answers to your questions.
