Bypass Excel-based Permissions Traps
User Management
Armed with this information, it goes to the conceptual work. Describe which employee groups, which organisational units use which applications and define the scope of use. In the description, indicate for which organisational access (organisational level, but also cost centres, organisational units, etc.) the organisational unit per application should be entitled; So what you're doing is mapping out the organisation. It is also important to note which mandatory functional separation must be taken into account. This gives you a fairly detailed description, which in principle already indicates business roles (in relation to the system).
Every action of the emergency user must be traceable, which requires the appropriate configuration of logging components such as the Security Audit Log. After the event, all log files are always evaluated and all details are recorded in documentation. It is also possible to specify in the concept that, in the event of an emergency, extended authorization may be granted to other selected users; this is up to the company to decide.
Note the maintenance status of permissions in roles and their impact
In a redesign, we follow the principle of job-related workstation roles to technically map the job profile of the employees. To minimize the effort for the same job profiles with different organizational affiliations, the organizational units are inherited via an additional role. The separation of technical and organizational requirements greatly simplifies role development and modification. If certain people, such as team leaders, require extended authorizations, key user roles are developed for them, which extend the existing job role.
An essential aspect in the risk assessment of a development system is the type of data available there. Normally, at least a 3-system landscape is used (development, test and production system). One of the purposes of this is to ensure that (possibly external) developers do not have access to productive or production-related data. Since developers with the required developer authorizations have access to all data in all clients of the system concerned, there should be no production-related data in a development system. Even a division into a development and a test client (with the sensitive data) within the system does not protect against unauthorized data access for the reasons mentioned above. In the following, it is assumed that no production-related data exists on the development system. Otherwise, extended authorization checks must be carried out in the modules and access to production-related data must be approved beforehand with respect to the production system by the respective data owners. Since developers, as described, have quasi full authorization through their developer rights, revoking the authorizations listed below can raise the inhibition threshold for performing unauthorized activities, but ultimately cannot prevent them.
For the assignment of existing roles, regular authorization workflows require a certain minimum of turnaround time, and not every approver is available at every go-live. With "Shortcut for SAP systems" you have options to assign urgently needed authorizations anyway and to additionally secure your go-live.
The Central User Administration (ZBV) is used to create users, assign roles and distribute them to the respective subsidiary systems.
At www.sap-corner.de you will also find a lot of useful information on the subject of SAP authorizations.
The call is made through the transaction SE37.