When you are a SAP security person, responsible for managing access control for all employees in the organization, you hold a very powerful position. In comparison to programmers who have a lot of control over their specific work, the authorization manager, most of the time, does not have to obey by any rules or adhere to change controls. While programmers need to open change requests, release the changes in the development system and then get a managers’ approval to move them to the production environments, you will see that authorization managers are commonly making the changes to authorizations directly in the production system. Therefore, a lot of pressure is on the authorization manager’s shoulders not to make any mistakes.
There are three common areas that the authorization manager operates in: user lifecycle management (the creation and deletion of user accounts), changes in the assignment of authorization roles to users, and changes in the structure itself of the authorization role. The latter is the least common, since changes to roles are the most dangerous activity and there is a lot of potential to create damage if not done carefully. This is the reason that role re-engineering projects are so rare and when they are done, most organizations use tools such as ProfileTailor Dynamics.
In order to maintain good practices as an authorization manager, procedures should be defined to help in lowering the risk of making mistakes in the production system. Here are a few examples:
In user lifecycle management, NEVER delete a user account. We have found that many organizations move the user accounts that should be deleted to a dedicated user group (e.g. “DELETED_USERS”), remove and/or lock all their authorizations and leave them. Majority of the time, organizations will not really delete the user accounts. Using the “delete” function in T-Code SU01 deletes the user account from the user table including ALL their details, which is different than in other areas of SAP. A company should always think ahead to potential situations where that critical information may come in handy. For example, you never know when you’ll suddenly find a suspicious record or invoice that was created by a deleted user. In this case you would need to access the specific details of the past user.
Moral of the story – Don’t delete users!
Another important piece of advice for user lifecycle management is when creating new user accounts – do not copy them from another user. Although it’s the easiest possible way to create user accounts, we already discussed why it’s the worst method.
The key to changing authorization roles, is to “NEVER change anything in the production environment directly!” First, make the change in the development system, test it in QA and only then, if it looks and functions right, transport it to production. This is good practice even if SAP doesn’t enforce it (hint: you can download a role from the development system and upload it directly to production). Always remember – you are in charge, you have the power to make changes but you also have the responsibility to try and prevent possible mistakes!
Last but not least, if you’re using a tool like “Role Splitter” to split authorization roles according to real usage and to avoid Segregation of Duties, you should always direct the system to create the roles in a development system first. Although the tool is very powerful, it is still very risky to perform the split in the production environment. As we said in the beginning – with great power comes great responsibility – and it is all on your shoulders!