SE38/SE80 Access in Production

[former_member598019]

I pointed out to a client that access to SE38 and SE80 access in production is not best practices. They asked me if there is an SAP document from SAP suggesting that this is an audit risk.

Does anyone who has worked in Security know of any documents or WIKI's that describe the risks of granting SE38 and/or SE80 directly in production?

I have told them that you can't limit the access to execute programs individually and that we can add the programs that they do need to run to a menu, but users are giving pushback and any documention and/or opinions would be appreciated.

[Colleen]

Hi Paul

Note: I have told them that you can't limit the access to execute programs individually and that we can add the programs that they do need to run to a menu - this depends on product version. Previously you could only restrict to program authorisation group. I have mentioned S_PROGNAM as a way to restrict to specific programs but if the user receives S_PROGRAM or S_PROGNAM execution level access (And the program can be executed) then they will get access via SA38. Ofcourse, if the program has additional authorisation checks then the user would need to be authorised for the program to run successfully.

SE38/SA38/SE80 in production is considered critical access but it can be managed depending on the use case requirements. I’ve worked at many customers over the years where the design position was to build a customer transaction code to access the specific program - noone was allowed this access. Part of this was due to the granularity of the permissions (could only give out authorisation group to programs and not specific programs). The other aspect was building security roles and leveraging SU24 for additional authorisations. I've also been the support user frustrated that I cannot compare and view code in production as part of troubleshooting.

SAP delivers programs to use in support/system activities quite a bit. I found myself in debates with functional teams as to how they can quickly get access to a program that doesn’t have a transaction: bit of an effort to constantly build transaction codes for each item.

My approach to this access

• End user – I try not to grant any of these items (and in S/4HANA with Fiori as a front end you want a title for them)

Support Users –

• Name user they may need read/display access to valid code issues but I will ensure that
• They don’t’ have execute unless they associated transaction code or program gives it to them
• They don’t have debug access (via S_DEVELOP)
• Usually, I get them a technical display role
• Support Users execution – comes down to the overall role design, etc and how access it to be granted for cross-functional access (tables, spool, periodic jobs, batch jobs, programs, etc)
• Determine approach for job selection variant maintenance (SA38 variants) as they may need to update these. The usually can be done via menu hopping in SM37 or the program where the variant is defined.
• Consider FF Roles with SA38 execution and either use FF ID concept or temporary role assignment
• Decide which roles can have program execution and use object S_PROGNAM instead of S_PROGRAM. Each program should be assessed to ensure it has adequate authorisation checks.

The risk here is if the program does not have an additional check then the user has access – many system utility programs, etc may not have the additional checks in them. Also, you can a higher chance of cross-inheritance of permission if users get transaction in one role and then an open authorisation in another as the object wasn’t restricted.

The other bit, sometimes the change document will show SA38 as the transaction when it be easier to interpret if they had a specific transaction.

Finally, in an S/4HANA system the developers and technical teams may not be in SE80 but in Eclipse tools and accessing the code/content from there.

Some useful documentation to read:

SAP Note: 2253549 - The SAP Security Baseline Template - https://launchpad.support.sap.com/#/notes/0002253549 (SAP Security Baseline Template – search for S_PROGRAM/S_PROGNAM as it is listed as critical authorisations)

On the way to granularity (section of S_PROGNAM): https://blogs.sap.com/2014/10/16/on-the-way-to-granularity/ (great write up by a community member discussing granularity of checks - this is where checks can now apply at program level instead of authorisation group)

1946079 - Initial Authorization Check in Function SUBMIT_REPORT - SAP Note: https://launchpad.support.sap.com/#/notes/1946079

Regards

Colleen

[former_member598019]

Colleen,

Thank you so much for taking the time to provide such a detailed explanation. You state the follow: "SE38/SA38/SE80 in production is considered critical access".

Would you agree that it is still best practice to not assign those transaction codes to functional support roles outside of the FireFighter ID's? Do auditors usually flag access to those transactions as an issue?

[Colleen]

In my experience audits flag deviation from documented procedures as a non-adherence to the control

But yes, if I had a FF solution then I would look to use it as FF. It makes reviewing of audit logs and other activities easier (as well as revoking access if required).

I don't think there will be a definition "best practice position" except that it's flagged as critical and is recommended to limit number of users with access. It's then up to the customer to decide what their limit is. S_PROGNAM does help though.