SAP authorizations: Recommendations for setting up, monitoring and controlling
Check and refresh the permission buffer
The permission check for the S_PATH object is performed as described only for files corresponding to a path with a permission group in the SPTH table. In our example, you should grant permission for the S_PATH object with the value FILE in the FS_BRGRU field to access files with the path /tmp/myfiles*. Note that the authorization object only distinguishes two types of access. These two values summarise the access types of the S_DATASET authorization object. The value Modify corresponds to the values Delete, Write, and Write with Filter; the value View corresponds to Read and Read with Filter.
The IF_IDENTITY interface of the CL_IDENTITY class provides various methods for maintaining the fields of the user master record. As a template for the implementation of the BAdIs, you can use the CL_EXM_IM_IDENTITY_SU01_CREATE implementation example, which automatically populates the SU01 transaction's surname, space number, phone, email address, user group, billing number, and cost centre fields. This example implementation does not provide an external data source; the user name is set as the last name and fixed values are used for the other fields. At this point, you must complete the implementation, depending on your requirements. There are several possible data sources for the user master data that you can access from the BAdI.
SIVIS as a Service
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.
You can also find some useful tips from practice on the subject of SAP authorizations on the page "www.sap-corner.de".
You can greatly facilitate the maintenance of permissions in controlling by defining the RESPAREA field as the organisational level, and thus using your cost centre and profit centre hierarchies.