Permission implementation
Check and refresh the permission buffer
The role concept provides that each user can only process the tasks to which he is authorized. It is developed across departments and must protect sensitive data from unauthorized access. A clear role concept enables a modular structure of authorizations without having to create separate roles for each user.
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. If you want to add your own checks to standard applications, you must first find the appropriate place to implement the check. To develop without modification, SAP offers user-exits or business add-ins (BAdIs) for such cases. Some SAP applications also have their own frameworks in place that allow customisation-free implementation of their own permission checks, such as the Access Control Engine (ACE) in SAP CRM.
Authorization roles (transaction PFCG)
Critical permissions are permissions that allow you to view or modify security-related configurations in the SAP system, or perform activities that are critical from a legal or business perspective. This also includes access to sensitive data, which are e.g. personal. Critical permissions are really critical in themselves and pose a risk only if they get into the wrong hands. In any case, when using critical permissions, you should observe the principle of restricting rights. There are no general definitions of risk; Therefore, each company should define the compliance requirements for itself. Identifying critical SAP permissions is an important task and should be performed in every company. Particular attention should be paid not only to the award of transactions but also to the value characteristics of each of the eligible objects. It is important to mention that preventive regular inspections do not have to be burdensome. However, they will lead to greater transparency and security.
Create a report transaction for the report that is called in the background job. Set up the report transaction in the transaction SE93 and assign the report RHAUTUPD_NEW as a programme. Start the authorisation trace by setting the auth/ authorisation_trace profile parameter to Y or F if you want to work with filters (see tip 38, "Use the SU22 and SU24 transactions correctly"). Now run the job to collect permission checks on the permission trace. Your permission checks should now be visible in the STUSOBTRACE transaction. Now maintain the permission proposal values for your report transaction in transaction SU24 by entering the transaction code in the appropriate field. You will find that no values are maintained. Now switch to Change Mode. You can add your permission suggestions from the trace using the Object > Insert objects from Permissions Trace > Local (see Tip 40, "Use Permission Trace to Determine Suggest Values for Custom Developments"). Add the suggestion values for each displayed authorization object. Now create a PFCG role that includes the report transaction permission and maintain the open permission fields. Then test whether the job can be run with the permissions from the PFCG role.
During go-live, the assignment of necessary authorizations is particularly time-critical. The "Shortcut for SAP systems" application provides functions for this purpose, so that the go-live does not get bogged down because of missing authorizations.
On the other hand, there are situations where development uses these superficial tests to save the user time and the machine resources.
There is a very practical occasion: We have too often found a "broken" authorisation system with SAP customers, caused by the incorrect application of additional programmes.