Criticality
Change management
For an authorization concept, a clear goal must first be defined that is to be achieved with the help of the concept. This should list which regulatory requirements the respective SAP system must fulfill and the associated authorization concept must take into account. In this way, the legal framework conditions are defined. In addition, uniform naming conventions should be used because, on the one hand, many things cannot be changed after the initial naming and, on the other hand, this ensures searchability in the SAP system. Clearly defined responsibilities ensure the effectiveness of a concept. Specific persons must be named or at least roles defined in a separate section. A chapter should be dedicated to the process for user management. Here, it must be described how users obtain existing SAP authorizations, how new users are integrated into the SAP system, and who is responsible for approving authorizations. The chapter on the process for authorization management defines who is allowed to create and edit which roles and who is responsible for the development of various related processes. The chapter on special authorizations describes processes and special features in the area of non-dialog operations. These include job management and interface convention. Other administrative authorizations can also be described. The chapter on role concept explains how business requirements are transferred to a technical role. The role concept takes on a special significance, since it describes the actual mapping of business roles to the technical roles and thus to the authorizations in SAP.
We therefore recommend that you schedule a background job on the PFUD transaction, which performs a regular user comparison (see Trick 17, "Schedule PFUD transaction on a regular basis"). By the way, did you know that the auth/tcodes_not_checked profile parameter enables you to disable the transaction startup permissions for the SU53 and SU56 transactions? To do this, enter the value SU53, SU56, or SU53 SU56 for the profile parameter. This means that the end user no longer needs the permissions to run these transaction codes from the S_TCODE authorization object.
Permissions and User Root Sets Evaluations
Custom programmes should be protected with permissions, just like standard applications. What rules should you follow? Introductory projects usually produce a large number of customised programmes without being subjected to a permission check when they are executed. For your programmes, you should create custom permissions checks by default and manage them accordingly.
So much information... how can you keep it so that you can find it again when you need it? That's what Scribble Papers is great for.
On the other hand one can call the system trace over the transaction ST01. Here it is possible to set individual filters for the checks. In addition, you can switch off the trade via the "Trace off" button or the F8 key and switch the trace back on via the "Trace on" button that is then displayed or the F7 key. If you click on the button "Evaluation" or the F2 key, you can display the evaluation.
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
This is preferable to a black list for security reasons.
Before starting to read the data from the database, a DUMMY check can be used to quickly determine whether the user is authorized to access part of the data.