Use SAP Code Vulnerability Analyser
Set up login locks securely
System trace - Transaction: ST01 or STAUTHTRACE - There is also a system trace for an evaluation. Unlike the authorization trace, a system trace is mainly designed for short periods of time. My preferred variant to call the system trace is via the transaction STAUTHTRACE. Here you can filter the evaluation directly and get a better evaluation representation. Over the individual Buttons one can switch directly the Trace on or off and display the result of the Trace.
When you mix roles, either after upgrading or during role menu changes, changes are made to the permission values. You can view these changes as a simulation in advance. As described in Tip 43, "Customising Permissions After Upgrading," administrators may see some upgrade work as a black box. You click on any buttons, and something happens with the permissions in their roles. For example, if you call step 2c (Roles to be reviewed) in the SU25 transaction, all roles will be marked with a red light, which requires mixing based on the changed data from the SU24 transaction. Once you call one of these roles and enter the Permissions Care, the permission values change immediately. Using the Alt, New, or Modified update status, you can see where something has changed, but you cannot see the changed or deleted values. A simple example of how to play this behaviour without an upgrade scenario is changing the role menu. Delete a transaction from a test role and remix that role. You are aware that certain authorization objects have now been modified and others have even been completely removed, but can't all changes at the value level be replicated? Thanks to new features, this uncertainty is now over.
User administration (transaction SU01)
Even more critical is the assignment of the comprehensive SAP® standard profile SAP_ALL, which contains almost all rights in the system. Therefore, it should be assigned to a so-called emergency user at most. The handling of the emergency user should also be specified in the authorization concept, which should be documented in writing. In any case, the activities of the emergency user should be logged and checked regularly. Therefore, it is essential in preparation for the annual audit to check the current, as well as the historical, assignments of SAP_ALL. It is therefore not sufficient to simply quickly remove the SAP_ALL profile from users in the run-up to the annual audit. It must also be proven that the SAP_ALL profile was not briefly assigned for a few days over the audit period. If SAP_ALL assignments did occur, ideally these have already been documented and checked. If this is not the case, it is essential to create documentation that cannot be changed, in which it is proven why the assignment was necessary and that the user has not carried out any critical actions beyond this (filing and review of logging).
With "Shortcut for SAP systems" you can automate the assignment of roles after a go-live.
At "www.sap-corner.de" you will also find a lot of useful information on the subject of SAP authorizations.
In integrated data flows in SAP ERP, the sending application usually does not check the authorization objects of the receiving application.