Did you know that the denial of transaction SA38 does not reliably prevent SAP reports from being executed?
In our practical tip, read how you can best prevent “Workarounds”.
To restrict the use of SAP reports, it is common practice to withdraw authorization for transaction “SA38”. It’s generally the right thing to do, but doesn’t completely lead you to your goal, because there are several ways to start ABAP programs in SAP Systems.
- End user reporting with SA38 and variants of SA38.
In this combination, SAP checks the authorization for S_TCODE SA38 and, if applicable, S_REPORT, if the program to be started has an authorization group. In more recent systems, object S_REPORT is also checked. - Developer tools SE80, SE84, SE38, and approx. 50 other transactions.
In our Security Monitoring Center, we see again and again that users use alternative transactions such as SE38, SE80, SE84 etc. to start programs as reports or, worse, use tricks to call up SE16N. In this constellation, S_TCODE is checked for SE84 and object S_DEVELOP ACTVT 03. S_PROGRAM is never checked.In many authorization concepts, object S_DEVELOP ACTVT 03 (Display), in particular, is classed as non-critical and is therefore assigned to users without hesitation. But in many systems, this means that such workarounds are available to a large number of users.
Our tip:
Only assign transactions from the development environment in combination S_DEVELOP ACTVT 03 to emergency users, so that the use of SA38 and SE16N via workarounds is prevented. Create a transaction for each SA38 report, and only give assignment for reports via transactions. Your customer-specific programs should of course execute other functional authorization checks and you must check and extend the coding as required.
