Permissions and User Root Sets Evaluations
System Users
Unlike the EWA, the SOS is able to list users that require extensive permissions. So you can maintain a whitelist. We recommend that you deal with the results of the SOS as follows: Verify that all identified users require critical permission. Complete the users who need this permission in the whitelist. Remove this permission from other users.
It is best if the persons responsible for the system develop role descriptions with their departments in advance and document them outside SAP SuccessFactors (e.g., as in Fig. 2). In case of queries, they can use this basis to explain exactly why someone has been given a certain authorization. The role descriptions and the report help to work in a DSGVO-compliant manner. Since the report updates automatically, companies have no additional effort to document the changes - one less unloved (and often "forgotten") task.
Centrally review failed authorisation checks in transaction SU53
Manual addition of authorization objects to roles is sometimes necessary. However, the start authorizations for actions should be generated into the role exclusively via the role menu. For the following evaluations the table AGR_1251 is used, in which to the roles the authorization objects with their values are stored.
Roles reflect access to data depending on the legitimate organisational values. This information should be part of the naming convention, as these roles differ only in their organisational but not in their functional form.
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
At www.sap-corner.de you will also find a lot of useful information on the subject of SAP authorizations.
The checks are performed on the permissions associated with the roles and profiles assigned to the reference user.
All transaction codes are added from the IMG project to the Role menu.