Custom requirements
Detect critical base permissions that should not be in application roles
Due to the complexity of an SAP® authorization concept, it is necessary that all essential aspects are set down in a written documented authorization concept. This should describe the essential processes, but also how to handle the assignment of authorizations via roles. In particular, the nomenclature of specially created roles must be clearly defined. It should therefore be checked whether all changes since the last audit have been documented in the written authorization concept. After all, this document serves the auditor as a template for the so-called target/actual comparison. This means that the auditor compares the document with the actual status in the SAP® system for the main topics relevant to the audit. Any discrepancy can lead to a finding that must be avoided.
You can implement the first request for additional verifications when performing document transactions by using document validation. In this example, we assume that the document is posted through an interface and that you want to check permissions for custom authorization objects and/or certain data constellations. There are different dates for document validation. The complete document can always be validated, if only the information from document header (time 1) or document position (time 2) is available to you, this can also be sufficient depending on the scenario. In such cases, you need to create validation at the appropriate times. Before you can write a User-Exit in a validation, you have to make some preparations.
Maintain permission values using trace evaluations
The advantage of this feature is that administrators can parse failed permission checks regardless of end users. End users can save their unsuccessful checks to the database using the Save ( ) button. As an administrator, you can also back up failed permission checks from other users. The Saved Checks button also gives you access to this information afterwards. The automatic storage carried out when the old transaction SU53 was called is omitted because it overwrote the last recording. You can also load the results into an Excel file to allow a more comfortable evaluation.
An alternative to using the S_TABU_LIN authorization object is to create custom table views that make organisational delimitation easier to achieve. To do this, create a new view in the SE11 transaction and add the table to which the constraint will apply on the Tables/Join Conditions tab. The Selection Conditions tab allows you to specify your restrictive organisational condition in the form of a field and a field value. You then authorise all relevant users to access the view, which contains only data for your organisational restriction.
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
Understanding the structure and functioning of the system is especially important for IT administration. It is not for nothing that "SAP Basis Administrator" is a separate professional field. On the page www.sap-corner.de you will find useful information on this topic.
In the context of upgrades, the correct permissions must be determined and integrated into the corresponding permission roles.
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.
You can set the validity period only if the maintenance is set to Local in the settings of the Central User Management (this setting is set in the SCUM transaction).