SAP Authorizations Checking at Program Level with AUTHORITY-CHECK - SAP Basis

Direkt zum Seiteninhalt
Checking at Program Level with AUTHORITY-CHECK
WHY ACCESS CONTROL
Applications use the ABAP statement AUTHORITY-CHECK in the source code of the program to check whether the user has the appropriate authorizations and whether these authorizations are defined appropriately, that is, whether the user administrator has assigned the values required by the programmer for the fields. In this way, you can also protect transactions that are indirectly accessed by other programs. AUTHORITY-CHECK searches the profiles specified in the user master record for authorizations for the authorization object specified in the AUTHORITY-CHECK statement. If one of the determined authorizations matches one of the specified values, the check was successful.

You should not grant large permissions for the SCC4 and SE06 transactions to internal and external auditors, just so that they can see the system modifiability. We present the report, which only requires the permissions a auditor usually has to view the system modifiability. There are several people who want to view the system modifiability settings in your system for specific reasons. These can be internal auditors, auditors or developers. The display of these settings, e.g. via the SCC4 or SE06 transactions, is not in itself critical; However, this has previously required permissions that are not usually assigned to the group of people just described. Since SAP NetWeaver 7.0, there is also a report that shows the system modifiability settings. This report requires only viewing permissions that can be assigned to the above-described group without any concerns. We present the application of this report and the required permissions here.
Trace after missing permissions
The specific SAP_NEW authorization object imprints are provided via the SAP_BASIS component. Therefore, an SAP_NEW profile is always bound to a specific base release. Proceed as follows: With the transaction SU02, you remove all old, individual profiles from the SAP_NEW composite profile, including the profile that belongs to the start release of your upgrade. Now assign the reduced SAP_NEW permission profile to all users in the upgrade preparation system, ensuring that all users can work as usual. This step can be omitted if you are following another method to identify missing permissions. Now check all permissions in all remaining profiles within the SAP_NEW summary profile that have a higher release level than the SAP_BASIS upgrade start release. Map all required permissions to all productive roles in your permission concept. You can do this for each intermediate release individually. The next step is to adjust the permissions in your productively used roles in the PFCG transaction, and then remove the corresponding permissions from the SAP_NEW profile using the SU02 transaction. Repeat steps 3 through 4 until the SAP_NEW permission profile is empty. Work in a development system during the role adjustment phase and transport the adjustments made to your eligibility roles to your quality assurance system. After successful acceptance test, you transport them to the production system. Now you can remove the SAP_NEW profile from all users. You can then proceed with role follow-up as part of the release change in the SU25 transaction (see also Tip 43, "Customise Permissions After an Upgrade").

System trace - Transaction: ST01 or STAUTHTRACE - There is also a system trace for an evaluation. Unlike the authorization trace, a system trace is mainly designed for short periods of time. My preferred variant to call the system trace is via the transaction STAUTHTRACE. Here you can filter the evaluation directly and get a better evaluation representation. Over the individual Buttons one can switch directly the Trace on or off and display the result of the Trace.

Authorizations can also be assigned via "Shortcut for SAP systems".

For us, it has proven itself, in the name of the new function block, the name BTE and the number of the template (here: 1650).

Obsolete but critical functions are disabled by some security precautions; in such cases, you do not need application testing.
SAP BASIS
Zurück zum Seiteninhalt