I have been working with customers on SAP security related projects since 2005. After switching to my new internal role I feel it might be a good idea to do a kind of a "brain dump" of things that I have come across in several of these projects and might be helpful for others.
Nearly all those projects had some basic steps in common. Most of the time it started with information gathering, which was often a tedious excercise, as the information was either not available or outdated. So I thought I'd come up with the idea of a basic SAP Security Inventory which - if present - might accelerate security related projects significantly.
Identity Crisis
Lots of SAP security related activities involve users. This is most obvious in authorization related topics: if you want to make sure people have the right kind of access you need to be able to identify them consistently.
User IDs: Users need access to all kinds of systems. In an infrastructure that has grown for a few years this sometimes leads to issues related to user ID management.
- Enforce a single common User ID. Even if applications have different options for what kind of user ID they will support (some use the full eMail address, others use an 8 character ID) it is advisable to make sure you agree on the lowest common denominator. This will allow users to login to every system with the same ID, and it will allow IT to identify users quickly without going through mapping excercises.
- Have a central user repository. Quite often this can be your Active Directory managing your Windows domain, or any other directory or HR system. Whatever it is, try to make sure there is ONE system that you can reply on to tell you the truth: who is that user, is he/she still active, what is the correct communications data (email address, phone number). This does not have to lead into a full fledged identity management project, just make sure all your user related activities make sure this gets updated properly.
- Enforce a ONE USER, ONE ID concept. If you ever need to find every access related to one user you'll be really happy you did that. Also, I have seen many cases where users where collecting several user IDs to accumulate excess authorizations which they would not be receiving for a single user - which often goes undetected.
User source: Try to avoid replicating user data if in any way possible. In ABAP systems the CUA can help you manage user attributes in one place, Java systems can connect to LDAP directories and access user data from there.
For any new system in your landscape make sure it can use any one existing user source instead of creating a new one.
Passwords: They're a pain. You might want to implement Single SignOn (SSO) if possible, but if you can't you still need to cope with passwords. As with user IDs, try to come up with a consistent policy (length, complexity, validity) so that users can cope more easily.
Have a password reset policy that makes sure people have a way to identify to the help desk, otherwise everybody will be able to reset the CEO's password, which you probably don't want to do.
Authorizations Management
This is probably the one area with the highest potential of wasting time and effort if not done right. OK, so it’s complex, but that’s just one more argument that tells you you’d better do it properly.
Whodunnit: Now that we know it’s complicated we need to make sure not everybody can do it :wink:
If you have too many people creating and changing roles and assigning them to users you are going to have a mess. Believe me, I’ve been there, and it took me a long time to fix. And it’s not fun.
So: Create a proper process with clearly defined responsibilities, and stick to it. No exceptions. Never. No “can you quickly add this TCode to the role?” phone calls. They’ll come back and bite you.
What’s in a name: Come up with a consistent :!: naming system that makes it easy for everyone to identify a role by its name. Make it as clear as possible, and do take the time to fill the role description and notes in PFCG. I don’t care what kind of naming scheme you come up with, it needs to work for you.
Technical excellence: Stick to the process when ‘fixing’ a role. Don’t throw in manual objects until it works, go through the proper procedures (SU24 is your friend) to keep the role maintenance friendly. When the next upgrade comes and SU25 barfs at you you’ll know why you should have done it. I highly recommend Julius' s blog (Part 1, Part 2)
Tame the consultant: You will use help in your implementations, but these guys need to play according to the same rules. Make sure they don’t quickly throw in new roles (“I’ll clean them up later!”), have your authorizations expert (you do have one, right?) perform oversight. Once crap goes in it never comes out again.
It’s just a report: Custom reports are great, aren’t they? How many do you have - 100? 1000? OK, now for the bad question: do you know what each of them does? You’d be the first.
I know you’re probably never going to catch up with that, but start with a simple Excel sheet that has the name of the reports that are assigned to users and write a short text indicating what they’re supposed to do.
Oh, you don’t know which ones are being used...? <sigh> Look into your transaction logs (which I’m sure you’re keeping for at least a year, they’re a huge help in authorization design) and make a Z-transaction for each of them. Then remove SA38 and wait until people start complaining :wink:
If you can’t do that, run the analysis for a while and convert the ones that people are using, assign them to roles with proper authorizations and incrementally do the cleanup.
Technical Security
Even though this is the place where security experts focus their efforts I have not come across many customers that care too much about this.
What's that RFC: It is a really good idea to keep a list of all your RFC connections, and the reasons why they exist. Also, you do want to control access to these connections through properly defined users with limited authorizations.
Who plans your jobs: Background jobs are also worth documenting. I would advice to use specific background job users as well. I have often seen issues where user accounts of people that are no longer in the company are kept alive because "there may be a few jobs that breaks if we delete him".
So much for a start. I don’t want to dive too deep into the rathole of authorizations, I just wanted to outline a few basic issues that few customers get right immediately. They should be easy enough to fix and have long-term benefits.
What is your experience - are there similar issues that you have come across? Or have you even met customer that do all this already...? :wink:
