RSUSRAUTH
Use SU22 and SU24 transactions correctly
In general, you should note that not all relevant change documents of a system are present in the user and permission management. As a rule, authorisation administration takes place in the development system; Therefore, the relevant proof of amendment of the authorisation management is produced in the development systems. By contrast, you will find the relevant user administration change documents in the production systems; Therefore, you should note that when importing roles and profiles in the production systems, no change documents are written. Only transport logs are generated that indicate that changes have been made to the objects. For this reason, the supporting documents of the development systems' authorisation management are relevant for revision and should be secured accordingly.
Don't simplify your entitlement concept before you know all the requirements, but first ask yourself what you need to achieve. So first analyse the processes (if possible also technically) and then create a concept. Many of the authorisation concepts we found in customers were not suitable to meet the requirements. Some of these were "grown" permission concepts (i.e., requests were repeatedly added) or purchased permission concepts. Many of these concepts had in common that they had been oversimplified, not simply. A nice example is permission concepts that summarise all organisational levels in value roles or organisational roles. There are few examples, such as the role manager of the industry solution SAP for Defence and Security, in which the result of a value role concept is still useful and appropriate for the user. The assumption that you "sometimes" separate all the authorization objects that contain an organisational level is simple, but not useful. We have not found the simplification that only a user without permissions can definitely not have illegal permissions. However, there was always the case that users had far too many permissions and the system was therefore not compliant.
Use Central User Management change documents
Use the RSUSR003 standard report (or RSUSR003 transaction) to validate the default users for initial passwords and ensure the security policies associated with those users. You can define and use your own layout on the home page. After the report is executed, you will be presented with an overview of the existing standard users in the different companies. This includes the password status, a lock flag, the reasons for the lock, the number of false logins, the user validity periods and the security policies associated with the users. The security policy appears to help you understand whether these users are subject to special login or password rules.
To store all the information on the subject of SAP - and others - in a knowledge database, Scribble Papers is suitable.
SAP Note 1707841 ships an extension to the system trace in the STAUTHTRACE transaction, which enables the permission trace to be used on all or on specific application servers. To select the application servers on which to start the trace, click the System Trace button. Now select the application servers in the list on which you want to run the system trace and start the trace with a click on Trace. In the evaluation of the Permission trace, an additional column named Server Name appears, showing you the name of the application server on which the respective permission checks were logged.
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
At least one separate file is created for each day.
Custom programmes should be protected with permissions, just like standard applications.