Solution approaches for efficient authorizations
Deletion of change documents
Since developer authorizations correspond to full authorization, they should only be assigned restrictively. This applies above all to the authorization for "debugging with replace" (see "Law-critical authorizations"). The risk of incorrectly assigned developer authorizations has also increased due to the elimination of additional protection via developer and object keys in S/4 HANA systems (see, among other things, SAP Note 2309060). Developer authorizations for original SAP objects should therefore only be granted here upon request in order to avoid unauthorized modifications. If developer keys are still relevant in the existing SAP release, the existing developer keys in table DEVACCESS should first be checked and compared with the users intended for development.
Our example role MODELING makes it clear that it is possible to assign different types of privilege to a role. The SAP HANA Studio shows you in the administration interface which user (the so-called grantor) has assigned the respective privilege to this role (granted). By filtering and sorting, you can optimise the appearance of the role content. Depending on the type of privilege, you will be presented with the appropriate details by selecting an entry.
Check for permissions on the old user group when assigning a new user group to a user
To help you better find your own tables in the future, check your development policy to see if the storage is adequately described. If the development guidelines are not complete, you should supplement them. For example content for a development policy, see the DSAG Web site under Guides. Now go to https://www.dsag.de/go/leitfäden and search for "Best Practice Guide Development".
At www.sap-corner.de you will also find a lot of useful information on the subject of SAP authorizations.
Do you want to keep track of what changes have been made to the Central User Management configuration or the distribution parameters for the User Master's Care? You can manage the change documents centrally. The Central User Administration (ZBV) is used to create users, assign roles and distribute them to the respective subsidiary systems. For this, the ZBV has to be configured initially. These include defining the ZBV landscape, i.e. defining the central system and subsidiary systems, adjusting the distribution parameters and transferring users from the subsidiary systems to the central system. You can also configure the ZBV afterwards. For example, you can add subsidiary systems or release them from the ZBV. In the transaction, you can modify SCUM to change the field allocation properties so that fields that were originally globally distributed across the ZBVs are also locally maintainable. All this information about the changes to the ZBV configuration has not been centrally logged.
Secure your go-live additionally with "Shortcut for SAP systems". You can assign necessary SAP authorizations quickly and easily directly in the system.
A permission concept is only as good as the code that performs the permission checks.
A note box in which data of all kinds can be quickly filed and retrieved. This is what Scribble Papers promises. At first, the program looks very spartan. But once a small structure is in place, you realise the great flexibility of this little helper.
The identification of the required functional components is often considered to be too burdensome and the risks from a lack of limitation are considered to be too low.