SAP Authorizations SAP license optimization - SAP Basis

Direkt zum Seiteninhalt
SAP license optimization
Deleting table change logs
The user administration process, i.e. user creation, modification and deactivation, should on the one hand be available in written documented form, either as a separate document or as part of the authorization concept documented in writing, and on the other hand also be carried out in accordance with the documentation. Therefore, a reconciliation should be performed on two levels: on the one hand, it should be ensured that the documentation is up to date and, on the other hand, it should be checked whether the process was also followed in the fiscal year to be audited. Possible deviations should already be prepared argumentatively, special cases can always occur that deviate from the actual process. However, these should be documented in a comprehensible manner so that an external auditor, such as the auditor's IT auditor, can check the plausibility. All documentation should be provided with the essential information (creator, date, version, etc.) and be in a format that cannot be changed (usually PDF). Additional documentation can also be output from the ticket system, provided that the process is consistently documented via the ticket system.

For a long time, SAP authorization consultants and ABAP developers have disagreed on how to implement authorization object characteristics in the coding. There are two positions: On the one hand, consultants advise never to test for the signal word DUMMY, the constant space or the literal ' '. These tests only superficially check for the existence of an authorization object and do not react to settings in the field specification in the profile of the roles. Moreover, the literal ' ' is then authorized because it is displayed in the transaction STAUTHTRACE. On the other hand, there are situations where development uses these superficial tests to save the user time and the machine resources. If the program determines early on that the user does not have the necessary objects in the user buffer, it may abort before the first SELECT and issue an appropriate error message. Both positions contain a kernel of truth. Let's look at the effects of different programming on a simplified example. The role(s) have only the authorization object S_DEVELOP with the field value DEVCLASS "Z*".
Use timestamp in transaction SU25
To calculate the recommendations, you can filter the SAP notes by their productive system, by the SAP solution, and by the applications and components, by the technical system name, and by the time of publication. The recommendation is issued in the following categories: Security-relevant SAP information, information on performance optimisation, HotNews, information on changes in legal regulations, and notes on corrections in the ABAP system.

The specific SAP_NEW authorization object imprints are provided via the SAP_BASIS component. Therefore, an SAP_NEW profile is always bound to a specific base release. Proceed as follows: With the transaction SU02, you remove all old, individual profiles from the SAP_NEW composite profile, including the profile that belongs to the start release of your upgrade. Now assign the reduced SAP_NEW permission profile to all users in the upgrade preparation system, ensuring that all users can work as usual. This step can be omitted if you are following another method to identify missing permissions. Now check all permissions in all remaining profiles within the SAP_NEW summary profile that have a higher release level than the SAP_BASIS upgrade start release. Map all required permissions to all productive roles in your permission concept. You can do this for each intermediate release individually. The next step is to adjust the permissions in your productively used roles in the PFCG transaction, and then remove the corresponding permissions from the SAP_NEW profile using the SU02 transaction. Repeat steps 3 through 4 until the SAP_NEW permission profile is empty. Work in a development system during the role adjustment phase and transport the adjustments made to your eligibility roles to your quality assurance system. After successful acceptance test, you transport them to the production system. Now you can remove the SAP_NEW profile from all users. You can then proceed with role follow-up as part of the release change in the SU25 transaction (see also Tip 43, "Customise Permissions After an Upgrade").

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".

You may have special requirements that are necessarily to be included in the naming convention, such as when you define template roles in a template project that can be customised locally.

Therefore, a reconciliation should be performed on two levels: on the one hand, it should be ensured that the documentation is up to date and, on the other hand, it should be checked whether the process was also followed in the fiscal year to be audited.
SAP BASIS
Zurück zum Seiteninhalt