In many organizations, the access to the sensitive SAP T-Code SU01 is much wider than needed. Let’s explore why.
SU01 is used for different purposes, most commonly to create new user accounts, reset users’ passwords and Lock/Unlock user accounts. System Administrators use SU01 to create users and change user’s details, and the helpdesk team uses SU01 to unlock users and reset passwords (because most of them have just forgotten their passwords).
Using SU01 Widely Ensures Unhappy Auditors
What’s the problem? The main problem is that there are a lot of sensitive possibilities within this T-Code and that the actions done within SU01 are finite and not documented. You don’t need to provide an explanation or be pre-approved in order to create a new user account in the production system using SU01, you don’t have to explain anything to anyone if you want to unlock an inactive user account through SU01. Most organizations will implement such procedures on paper, but this isn’t reliable enough – in order to enforce procedures you can’t just count on luck – you need a compensating control. You can understand what a gap it leaves, and what a hassle it is, for the System Administrator to maintain paperwork for every time a new account is opened or for the help desk team to have to keep a call-log that provides evidence of users that have asked to be unlocked. I get a headache just thinking about it.
Be Smart. Take the Secure Way: Replace SU01 with a Portal!
Instead of using sensitive T-Code SU01, use a portal and put the most common tasks in it. Then, remove most everyone’s access from SU01 and take a break – you’ve just averted some major risks.
First implement the most used tasks:
- Creating Users – Establish a pre-configured workflow starting with the HR request (or an event from the HR system about a new employee), continuing on with approval by a Security Manager, and ending in automatically creating the user. The final step is to send an email letting stakeholders know that a user was created.
The benefits? There’s no manual work, no option to abuse the process and create fake users, no option for unattended licenses, and most importantly – a documented, secured workflow process that auditors can easily inspect.
- Unlock Users – Create a self-request screen for the user to fill out, then configure the system to perform reasonability checks, such as examining recent activity and access from allowed IP addresses, and viola!, the user is unlocked.
The benefits? 70% less hassle for the help desk team, a secured process with reasonability checks built in, a well documented procedure for auditors.
Ah yes, alternates to the pitfalls of SAP T-Code SU01. What a lifesaver. But how will you get these workflows in place? We’ll help you