Controlling file access permissions
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.
When defining the development policy, you should ensure that the appropriate attention is paid to access security. Customised programmes or customisations in the SAP Code Inspector ensure that all developers working in the company comply with these guidelines. Verification of compliance with the development directives should be an essential part of quality assurance before the programmes are used productively. The SE38 and SA38 transactions should not be allocated in the productive system and custom programmes should be included in own transaction codes. Permissions are then set up only for these transactions.
Optimise trace analysis
In principle, all eligibility fields can be upgraded to the organisational level; there are, however, technical exceptions and fields where this is not useful. Technically, the fields that are in the context of testing the startup capability of an application are excluded, i.e. the fields of the S_TCODE, S_START, S_USER_STA, S_SERVICE, S_RFC, S_PROGRAM and S_USER_VAL authorization objects. In addition, you cannot elevate the ACTVT field to the organisation level. Only the fields that can be assigned a value range within a role are meaningful. This must of course be considered across the board for the authorisation concept. For example, fields that have more than one meaning, such as the Authorisation Group (BEGRU), are not suitable for material management. The PFCG_ORGFIELD_CREATE report allows you to define a permission field as an organisation level. The report enters the field in the USORG table, changes the permission proposal values to that field, and performs all the roles that have a shape in the field.
Other dangers include admins simply copying user roles, not having control processes for permission assignments, or not following the processes over time. In this context, two things should be clarified: Which SAP user is allowed to access which data? How do the roles differ (especially if they are similar)?
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".
The status of the mixing mode can be checked by clicking the button Mixing mode for PFCG: Enquire On/Off.
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.
After all authorizations are maintained, the role must be saved and generated and a user comparison must be performed.