What to do when the auditor comes - Part 1: Processes and documentation
Unclear responsibilities, especially between business and IT
If business partners are deposited to the user IDs, the standard evaluation paths lead to a dead end. Adjust it so that the indirect role mapping works anyway. In SAP CRM, you can set up an organisation management, as in SAP HCM. You can maintain organisational units and posts and assign business partners with their user IDs. In SAP CRM, however, there is the specificity that user IDs are not directly assigned to a job, but are usually indirectly assigned by the associated business partner. All persons and organisations involved in business processes are represented as business partners in SAP CRM.
Even more critical is the assignment of the comprehensive SAP® standard profile SAP_ALL, which contains almost all rights in the system. Therefore, it should be assigned to a so-called emergency user at most. The handling of the emergency user should also be specified in the authorization concept, which should be documented in writing. In any case, the activities of the emergency user should be logged and checked regularly. Therefore, it is essential in preparation for the annual audit to check the current, as well as the historical, assignments of SAP_ALL. It is therefore not sufficient to simply quickly remove the SAP_ALL profile from users in the run-up to the annual audit. It must also be proven that the SAP_ALL profile was not briefly assigned for a few days over the audit period. If SAP_ALL assignments did occur, ideally these have already been documented and checked. If this is not the case, it is essential to create documentation that cannot be changed, in which it is proven why the assignment was necessary and that the user has not carried out any critical actions beyond this (filing and review of logging).
Check for permissions on the old user group when assigning a new user group to a user
You can adjust these evaluation methods in the table T77AW or in the transaction OOAW. To do this, select the respective evaluation path by selecting it, and click on the evaluation path (individual maintenance) in the menu on the left. The table that appears defines the relationships between the objects. For SAP CRM only the objects Organisational Unit (O), Headquarters (S), Central Person (CP) and User (US) play a role. For simplicity, you can now copy the lines that use the Person (P) object. Enter a new number here and replace the object P with the object CP.
After successful implementation of your permission check, the new authorization object for your application must be maintained in transaction SU24. If your solution is distributed in other system landscapes, the authorisation proposals in the transaction SU22 are maintained. In addition, with the permission proposal value maintenance, you can make sure that the new authorization object is not forgotten in a role system, because it is now loaded automatically into the PFCG role when the application is called up via the role menu. In the final step, the permission administrator can create the PFCG role or must remix the existing PFCG roles.
If you get into the situation that authorizations are required that were not considered in the role concept, "Shortcut for SAP systems" allows you to assign the complete authorization for the respective authorization object.
SAP Basis is the foundation of any SAP system. You can find a lot of useful information about it on this page: www.sap-corner.de.
now come into play, however, this means a large number of authorization roles, namely a separate one for each manager.
So much information... how can you keep it so that you can find it again when you need it? Scribble Papers is a "note box" that makes this very easy.
The SAP authorization concept must generally be created in two versions: for the ABAP stack and for the Java stack.