Implementing Permissions Concept Requirements
Protect Passwords
In practice, the main problem is the definition of content: The BMF letter remains very vague here with the wording "tax relevant data". In addition, there is the challenge of limiting access to the audited financial years.
The authorization check for the authorization objects PS_RMPSORG and PS_RMPSOEH runs as follows following a user entry: The system determines the organizational unit to which the user is assigned. Starting from this organizational unit, the system creates a list of all organizational units that are superior to the organizational unit determined in the first step in the hierarchy. The system determines the set (M1) of all organizational objects that are assigned to these organizational units. The system determines the organizational unit to which the object to be processed is assigned (corresponds to the lead organizational unit in the attributes of the object to be processed). Starting from this lead organizational unit, the system creates a list of all organizational units that are superior to the determined organizational unit within the hierarchy. The system determines the set (M2) of all organizational objects assigned to these organizational units. The system forms the intersection (from M1 and M2) of the matching organizational objects of the user and the object to be processed. The system determines the organizational levels that match for the user and the object being processed. Once a matching organizational level is found, the system performs the authorization check for the other fields of the authorization object (e.g., type of object or activity); if the system cannot determine a common organizational level, processing is rejected. If the user is allowed to perform the requested activity, processing is allowed; otherwise, the system rejects processing.
Security in development systems
With the introduction of security policy, it is now possible to define your own security policy for System or Service users. This way you can ensure that backward-compatible passwords are still used for these users. This eliminates the reason that password rules were not valid for System/Service type users; Therefore, the rules for the content of passwords now apply to users of these types. Password change rules are still not valid for System or Service type users. If you are using security policy in your system, you can use the RSUSR_SECPOL_USAGE report to get an overview of how security policy is assigned to users. This report can be found in the User Information System (transaction SUIM). In addition, the user information system reports have added selected security policies to the user selection. This change was provided through a support package; For details, see SAP Note 1611173.
How do I compare roles (RSUSR050)? With the report RSUSR050 you can compare users, roles or authorizations within an SAP system or across systems. To do this, start transaction SE38 and run the above report.
Assigning a role for a limited period of time is done in seconds with "Shortcut for SAP systems" and allows you to quickly continue your go-live.
Although it is possible to send an encrypted e-mail with a fake sender address, in this case the initial passwords in the system would not work.
You can also find some useful tips from practice on the subject of SAP authorizations on the page www.sap-corner.de.
In transaction PFUD, which provides for the user comparison, the evaluation paths US_ACTGR and SAP_TAGT are used.