Grant permissions for SAP background processing
Full verification of user group permissions when creating the user
Cybersecurity is a broad field. Starting with the technical infrastructure of companies and extending to the business processes in SAP systems. Such projects must be well planned and prepared. We have already seen some negative examples of companies that wanted too much at once and then "got it wrong." When it comes to securing business processes in particular, it is important to ensure that the employees affected are picked up and involved. Therefore, use a risk analysis to select the topics and processes that should be at the top of the list when securing.
This list in the AGR_1252 table contains both the organisational fields that are shipped in the standard and the fields that you have collected for organisational fields. Unfortunately, the list does not indicate what kind of organisation field it is. But you can find out: Open the PFCG_ORGFIELD_DELETE programme via transaction SA38. The Organisation Level Value Helper (Orgebene) provides a list of all customer-specific organisation fields, because only these can be converted back to normal Permissions Object Fields. Note the implications if you want to actually run this programme.
Integrate S_TABU_NAM into a Permission Concept
Entry into role maintenance requires the transport permission (S_USER_AGR, ACTVT = 02) in addition to the modification permission (S_USER_AGR, ACTVT = 21). If role recording requires creating new transport jobs or tasks, you need permissions to the transport objects (e.g. S_TRANSPRT with TTYPE = CUST or TASK and ACTVT = 02).
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.
"Shortcut for SAP systems" is a tool that enables the assignment of authorizations even if the IdM system fails.
You can also find some useful tips from practice on the subject of SAP authorizations on the page www.sap-corner.de.
If a user has a permission issue, a ticket is usually displayed at support.
Set up a new system and make sure that processes are always documented to the level of transactions.