Security Automation for HR Authorizations
Dialogue user
First of all, represent your organisation. Map the business processes (if necessary only at the generic level of applications such as MM or CO) across the organisation. On this basis, determine which organisational characteristics (organisational levels, but also cost centres, organisational units, etc.) represent which parts of the organisation. Define (if necessary, only in detail in accounting, otherwise at the level of applications) which functions must necessarily remain separate. If you have a running system, evaluate the use of the last 13 months (see Tip 26, "Use usage data for role definition"). Set up a new system and make sure that processes are always documented to the level of transactions. In such a case, it is also best to collect the business risks directly in the process description.
Do you want to keep track of what changes have been made to the Central User Management configuration or the distribution parameters for the User Master's Care? You can manage the change documents centrally. The Central User Administration (ZBV) is used to create users, assign roles and distribute them to the respective subsidiary systems. For this, the ZBV has to be configured initially. These include defining the ZBV landscape, i.e. defining the central system and subsidiary systems, adjusting the distribution parameters and transferring users from the subsidiary systems to the central system. You can also configure the ZBV afterwards. For example, you can add subsidiary systems or release them from the ZBV. In the transaction, you can modify SCUM to change the field allocation properties so that fields that were originally globally distributed across the ZBVs are also locally maintainable. All this information about the changes to the ZBV configuration has not been centrally logged.
Trace after missing permissions
The first step to eliminating sprawl in permissions is to prevent it. To do this, administrators should obtain an overview and the assigned authorizations should be checked regularly. This helps to identify problems and incorrectly assigned authorizations at an early stage. The workload monitor can help here. This shows which authorizations users are actually using. The use of authorizations can be analyzed selectively and exported to tables. This also helps to improve existing roles and to create new roles for the authorization model in SAP.
Let's say that a user - we call her Claudia - should be able to edit the spool jobs of another user - in our example Dieter - in the transaction SP01. What do you need to do as an administrator? Each spool job has a Permission field; By default, this field is blank. If Claudia wants to see a Dieter spool job, the system will check if Claudia has a specific spool job permission with a value of DIETER. Claudia does not need additional permissions for its own spool jobs that are not protected with a special permission value.
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.
The second line with PATH = /tmp allows read and write access for all files starting with /tmp, similar to a permission value /tmp*, as an exception to the access ban defined in the first line for all files and paths.
At www.sap-corner.de you will also find a lot of useful information on the subject of SAP authorizations.
Once you have determined that you want to add more fields to your check, assign your authorization object to the AAAA object class and create a new authorization object.