Use SAP Code Vulnerability Analyser
System Users
One way of gaining direct access to downstream systems from the development system and possibly performing unauthorized activities there is to use incorrectly configured interfaces. In principle, interfaces within a transport landscape should be avoided with regard to the criticality of the systems "uphill", i.e. from an "unsafe" to a "safe" system (e.g. E system to Q or P system). However, this cannot always be implemented; for example, such interfaces are needed within the transportation system. Without going too deeply into the subject, however, critical interfaces can be characterized by the following properties. Critical interfaces refer to a critical system and a critical client, contain an interface user with critical authorizations in the target client, contain its deposited password.
First and foremost, legal principles must be stated and specific reference must be made to authorizations that are critical to the law and that may not be assigned (or at most may be assigned to emergency users). An example is the authorization "Debugging with Replace", to which the object S_DEVELOP with the values ACTVT = 02 and OBJTYPE = DEBUG legitimizes and over which data can be manipulated by main memory change. However, this would violate § 239 of the German Commercial Code, the so-called "erasure prohibition".
A concept for SAP authorizations prevents system errors and DSGVO violations
To establish an efficient and consistent structure in the area of SAP authorization management, function-related role and authorization assignments are the be-all and end-all. In addition, the existing authorization concept must be constantly analyzed for changes and security-relevant errors through proactive monitoring. This prevents negative and highly security-critical effects on your entire system landscape. To make this task easier for you, Xiting provides you with a comprehensive analysis tool, the Xiting Role Profiler. In addition, you can perform a basic analysis in advance, which will also be the main focus of this blog. The goal is to show you SAP standard methods with which you can already independently optimize your authorization and role administration.
The security policy was introduced with the SAP NetWeaver 7.31 release; for their use you need at least this release. Security policies thus replace the definition of password rules, password changes, and login restrictions via profile parameters. The security policy is assigned to the user in transaction SU01 on the Logon Data tab. Profile parameter settings remain relevant for user master records that have not been assigned a security policy. Some of the profile parameters are also not included in the security policy and therefore still need to be set system-wide. Security policy always includes all security policy attributes and their suggestion values. Of course, you can always adjust the proposed values according to your requirements. You define security policy about the SECPOL transaction. Select the attributes for which you want to maintain your own values and enter the values accordingly. The Descendable Entries button displays the attributes that are not different from the global entries.
If you get into the situation that authorizations are required that were not considered in the role concept, "Shortcut for SAP systems" allows you to assign the complete authorization for the respective authorization object.
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.
If you have created your own applications, we recommend that you always implement your own permission check and do not just rely on application startup permissions such as S_TCODE, S_START, S_SERVICE, and S_RFC.
SAP authorizations control the access options of users in an SAP system, for example to personal data.