SAP Authorizations Define S_RFC permissions using usage data - SAP Basis

Direkt zum Seiteninhalt
Define S_RFC permissions using usage data
Evaluate Permission Traces across Application Servers
For table logging, it must be ensured that SAP® Note 112388 (tables requiring logging) is fully implemented and that all tables containing financially relevant data are also included in the logging. Of course, this also applies to all Z-tables! As last point of the important parameter settings are those for the definition of the password settings. Here, it should be ensured that the parameters are also set up in accordance with the company's specifications. However, the check should not only focus on the global settings that are valid for all users, but should also include all those users who have been assigned their own security policies. Especially for these, an appropriate justification must be available in writing.

A careless handling of the permissions with sensitive employee data can go quite nicely in the pants. Prevent uncontrolled and extensive reporting access to your HCM data by properly using the P_ABAP authorization object. In many companies, the correct use of P_ABAP is not known. As a result, there are often false expressions that, in the worst case, allow uncontrolled reporting access to all data in the logical database PNPCE (or PNP). This way, you can again erase your access restrictions, which were previously painstakingly defined in a permission concept. Therefore, it is necessary to test the use of P_ABAP in individual cases and to use the existing limitations. In the following we describe the logic behind this authorization object and what it is important to avoid.
Assignment of roles
However, the authorization trace is not active by default, but must be explicitly activated via the profile parameter "auth/authorization_trace". In transaction RZ11 you can easily and quickly check if the parameter is already set. The profile parameter is set in transaction RZ10. By default, the profile parameter is active in SAP systems (profile parameter transport/systemtype = SAP) and inactive in customer systems (profile parameter transport/systemtype = CUSTOMER).

If you only want to translate the description of the role, it is recommended to record the PFCG transaction and to change the source language of the role using the Z_ROLE_SET_MASTERLANG report before the LSMW script runs through. The report on how to change the source language can be found in SAP Note 854311. Similarly, you can use the SECATT (Extended Computer Aided Test Tool, eCATT) transaction to perform the translation instead of the LSMW transaction. Furthermore, automation is possible with the help of a customer-specific ABAP programme. To do this, you should take a closer look at the AGR_TEXTS table. The table contains the different text blocks in different languages. Here we show you a section of the table with our example role Z_SE63. Short texts are assigned a value of 00000 in the column LINE, and long texts are assigned a value of 00001 to 0000x. The language keys are displayed in the SPRAS column. An ABAP programme now allows you to write the counterparts for the text fields in the target language into the fields in the tables.

However, if your Identity Management system is currently not available or the approval path is interrupted, you can still assign urgently needed authorizations with "Shortcut for SAP systems".

We have not found the simplification that only a user without permissions can definitely not have illegal permissions.

You cannot also map transactions manually if you created a role directly from a project or project view.
Zurück zum Seiteninhalt