Skip to Content

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 😉
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 😉

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…? 😉

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Julius von dem Bussche

    You forgot to mention the era from your former life which you spent researching all of the world’s worste swear words in all languages to be able to add them to table USR40…  🙂

    Hope you enjoy and good luck with your new job!

    Cheers,

    Julius

    (0) 
  2. Indumathy Narayanan

    Hi Frank.

    Nice info. Best wishes.

    Just a humble request please.

    I do agree and understand that SAP security is a vast subject and one can spend a lifetime learning new things on SAP. But Still. When i came into SAP world last year, And started looking at SAP security related work assignments. Unfortunately, i did not find one basic consolidated documentation which would be more practical than theory.

    Though after a while i sort of learnt to understand and meander thro.

    I personally feel : Your documentation in SAP is too vast. And if there could be white papers published on different areas of security from SAP that would be very helpful.

    Basic concepts of each screen each field related tables where entries are recorded. For e.g. SU01 and PA20. Where each entries are getting recorded and how and why and where it is getting used. And how.  And what is the best practice which SAPsuggests. Such knowledge base articles would be very useful.

    Many thanks.

    Kind regards

    indu

    (0) 
    1. ATTA OFORI

      Hi Julius,

      I have been following your excellent contributions regarding SAP SECURITY. I am implementing CONTEXT AUTHORIZATION for a client with the following requirements:

      1. HR associates can view their own IT0008.

      2. HR associates can R/W/M etc all infotypes including IT008 for all associate outside of HR department

      3. HR associates should also be able to R/W/M all other infotypes besides IT0008 for all HR associates.

      I have tried implementing these restrictions as ff:

      1. Built a PD profile for the HR branch structure.

      2. Assign the ALL and my HR PD profile with the “exclusion” button (in OOSB) checked for the HR PD profile to PROFL to the role that allows IT008 ACCESS for all non HR associates

      3. In the second role that excludes IT008, I have also added P_PERNR with PSIGN=I.

      and PROFL= ORGANIZATION(function module)

      When I test the outcome, the user can access all infotypes for non HR associates and can see his own IT0008. However he cannot access any infotype for the HR team.

      When I peek into AUTHORIZATION VIEW (OOSB), I see that the profiles resulting from the function module is NOT excluded. I expected this to grant access to other non IT0008 for the HR team.

      How can I meet all three conditions without creating a PERSA or ORG KEY for the HR team?  The client wants context/pd profile to enforce these restrictions.

      I would appreciate your expertise in these scenarios.

      Thank you

      Atta.

      (0) 

Leave a Reply