ITIL
Time window for batch jobs becomes smaller and environments more complex
A clearly structured and secure authorization management is very important to avoid errors and prevent access by unauthorized persons. These services are part of our authorization management:
A well-cared-for emergency user concept enables the audit-proof allocation of extended permissions in combination with the assurance of daily operations in your company. This article first addresses the fundamental issues that require an emergency user approach. It then briefly explains how such a concept works in general and how we implement it. An Emergency User is normally used when tasks are temporarily taken over outside the initial field of activity. I described the different scenarios of when such a user can be used and how to deal with them in this blog post for you. Why is an emergency user approach important? There are several scenarios in which the use of an emergency user with extended rights is useful: In urgent cases, it is often necessary to be able to quickly make changes to the system that are outside the user's actual field of activity. A key user who has the necessary permissions is on vacation and needs a representation. The same user suffers short-term illness and his/her representative must take over his/her duties to ensure the operation. We recommend developing a concept for the short-term allocation of the additional permissions. This will ensure the implementation of the above scenarios. How does an emergency user approach work? An emergency user concept in SAP works fundamentally via a temporary assignment of additional rights to a specific user. After the tasks have been completed, the user is deprived of the rights. The tasks performed with the extended permissions are logged and can then be evaluated by an auditor. However, there are a few things to keep in mind: A process for granting special rights should be defined. It must be specified which users can get special rights. The time period for which users can request an emergency user should be limited.
STMS_IMPORT Import queue
The second component of the application layer is the message server. It acts as a kind of "mediator" between the services and the applications.
In order for Fiori applications to be displayed according to the calling users, appropriate Fiori permissions must be maintained in the PFCG. There are several points to consider. This article discusses the permissions required to launch a Fiori application. In addition, a short explanation is given, how the displayed tiles can be configured in the Fiori launchpad via reels. To run Fiori applications from the launchpad and the permission queries defined in the OData services, the corresponding Fiori permission objects must also be maintained in the PFCG. Here the start permissions for the application's OData service in the backend system as well as permission objects are relevant for the business logic of the OData services used in the application. In general, it is important to know that if Fiori is implemented correctly, permissions must be maintained in the front-end server (call Launchpad, start the tile, etc.) as well as permissions in the back-end server (call the OData services from the backend). This article explains this in more detail.
"Shortcut for SAP Systems" makes many tasks in the area of the SAP basis much easier.
In addition, it is possible to approve activities with special rights after an evaluation.
For this reason, various vendors provide solutions to automate the verification of the permission system with regard to critical permissions and segregation of duties using tool support.