Security within the development system
Law-critical authorizations
Today we come to the error analysis with authorizations. The best thing that can happen is the error of the type: "I don't have authorization to do this and that!" (CASE1). Worse is the case that someone has too many permissions, i.e. the type: "User xy should not have this permission anymore" (CASE2). How to proceed? First of all we come to case 1 This case, that someone has no authorization for something, supports the system excellently! The code word is SU53! If a transaction encounters an authorization error, then this error is written to a memory area that can be displayed. For this there is once the transaction SU53 or the menu selection "System/Utilities/Anc authorization check". With this function, the system outputs information showing which authorization objects are missing for the user.
RFC connections are interfaces for many local and global system processes, but also a security-relevant source of errors for many companies. The RFC interfaces and associated system users often have too strong authorizations and can quickly be misused by unauthorized persons to view sensitive company data. It is therefore important to always keep these system connections in the focus of global monitoring and to check which RFC destinations lead where and what they do. For this purpose there is the program RSRFCCHK which allows you to perform specific tests for your RFC system landscape. On the one hand the content of the RFCDES table is checked and on the other hand the corresponding user properties of the system users are displayed as an overview. Consequently, important parameters such as the target machine, the client, the background user or also the password property can be checked in an overview.
Unclear objectives and lack of definition of own security standards
The context-dependent authorizations combine the general and structural authorizations and avoid situations like in the example above. The context-dependent authorizations can be separated so finely that a separation of functions can be made possible without any gaps. Basically, with context-dependent authorizations, the authorization objects are supplemented by structural authorization profiles. This means that authorizations are no longer assigned generally, but only for the objects in the authorization profile. The use of context-dependent authorizations means that the familiar P_ORGIN authorization objects are replaced by P_ORGINCON and P_ORGXX by P_ORGXXCON. The new authorization objects then contain a parameter for the authorization profile.
With "Shortcut for SAP systems" you can automate the assignment of roles after a go-live.
At "www.sap-corner.de" you will also find a lot of useful information on the subject of SAP authorizations.
Since developer authorizations correspond to full authorization, they should only be assigned restrictively.