SAP authorizations: Recommendations for setting up, monitoring and controlling
Custom Permissions
Optional: S_PATH authorization object: If the test identifies 3 additional permissions checks for individual paths for the S_PATH authorization object, these are checked in the fourth step. The access type and the permission group stored in the SPTH table are checked.
The specific SAP_NEW authorization object imprints are provided via the SAP_BASIS component. Therefore, an SAP_NEW profile is always bound to a specific base release. Proceed as follows: With the transaction SU02, you remove all old, individual profiles from the SAP_NEW composite profile, including the profile that belongs to the start release of your upgrade. Now assign the reduced SAP_NEW permission profile to all users in the upgrade preparation system, ensuring that all users can work as usual. This step can be omitted if you are following another method to identify missing permissions. Now check all permissions in all remaining profiles within the SAP_NEW summary profile that have a higher release level than the SAP_BASIS upgrade start release. Map all required permissions to all productive roles in your permission concept. You can do this for each intermediate release individually. The next step is to adjust the permissions in your productively used roles in the PFCG transaction, and then remove the corresponding permissions from the SAP_NEW profile using the SU02 transaction. Repeat steps 3 through 4 until the SAP_NEW permission profile is empty. Work in a development system during the role adjustment phase and transport the adjustments made to your eligibility roles to your quality assurance system. After successful acceptance test, you transport them to the production system. Now you can remove the SAP_NEW profile from all users. You can then proceed with role follow-up as part of the release change in the SU25 transaction (see also Tip 43, "Customise Permissions After an Upgrade").
Define a user group as mandatory field in the user root
If you have defined the roles to the extent that the essential processes are depicted, then you will technically check which organisational features they contain (organisational levels, but also cost centres, organisational units, etc.). You then compare the technical result with the result from the consideration of the structure organisation and the business role description. A likely result is that you do not have to use all technical organisational features for differentiation. A possible result is that you want to add fields such as the cost centre to the organisation level.
Define critical permission combinations that cannot be assigned in the monitored systems. A whitelist allows you to specify which users (such as emergency users) you want to exclude from the evaluation. Identify vulnerabilities in the configuration of your RFC interfaces, i.e. RFC connections, where users with extensive permissions (e.g., the SAP_ALL profile) are registered. These RFC connections can be used for the so-called RFC-Hopping, where access to an SAP system is made via such an extensively authorised RFC connection.
Authorizations can also be assigned via "Shortcut for SAP systems".
Another option, Delete Flags for applications with modified data, is offered to apply the new changes only if Step 2a is executed selectively.
If you want to know more about SAP authorizations, visit the website www.sap-corner.de.
Although it is possible to create profiles manually, it is recommended to work with the profile generator.