Restricting Access to HR/Payroll Data

[Former Member]

We have a number of internal and external users in our production system who have SAP_ALL. This is the legacy of a difficult implementation last year. We wish to remove this without seriously damaging our ability to provide effective operational support. In particular we wish to block access to HR and Payroll data. I am happy we can use standard Roles to block access to HR/Payroll transactions but I am less clear how we block access via SE16 to the tables holding HR/Payroll data. For support purposes, we use SE16 very frequently. I am aware that we can use S_TABU_DIS to authorise tables a user CAN access - what I don't understand is how we specify those a user CANNOT access. Would we need to list every authorisation group but those applying to HR/Payroll tables? How would we know which groups are in use for HR/Payroll tables? Any suggestions would be gratefully received.

[Former Member]

In order to restrict what they cannot access, you have to exclude the HR/PA tables from the values in S_TABU_DIS.

I suggest looking at all the authorization group (found via txn code SE54), and then creating applicable ranges to exclude the HR groups. You can't just exclude P* since some PM and PP tables are secured in the PM and PP authorization groups.

By not including the authorization groups in S_TABU_DIS, you will prevent them from looking at any tables in the HR group. Also make sure that appropriate postive and negative testing is executed.

Of course, any tables that aren't secured should be secured (i.e. the &NC& auth group, blank). Tables that aren't secured can be found via table TDDAT. This table lists the tables and their authorization groups. Any roles that would be affected by subsequent auth group restrictions for the tables would have to be updated as well.

[Former Member]

Peter,

I just left a client that had the very same requirement that you mentioned. I created a range that excluded all HR tables (minus those that are NC). If you would like I could forward that information to you. Send me your email address.

[Former Member]

Thank you for your reply Julie - much appreciated - I guess it's the volume of tables that worries me. I think I also picked up from somewhere else that a determined programmer could use debug to circumvent these controls but then you have someone who is deliberately trying to see something they are not allowed to see through normal circumstances.

[Former Member]

Thanks for your very helpful reply Michael - not sure how to get my email to you in confidence though

[Former Member]

Hi Michael - you said you could email me some table selections for S_TABU_DIS - I have included an email address in my business card if it's possible for you to do this - I would be very grateful for your help.

[Former Member]

MIchael

I have the same problem at my current company. Is there a way I can contact you?

[Former Member]

Hello Peter,

Only protecting S_TABU_DIS from a role based on SAP_ALL or providing developer type access, is not enough to protect sensitive data in tables or files. What about all the P* objects, S_RFC, S_DEVELOP, S_DATASET, access in other clients of the same system, Excel files containing the data for calculations, or circulating in emails, or system users with that access, RFC desinations with that access, G/L account reclassifications with long texts,...?

While it may be that a determined programmer will often find a way to break your security, it is no reason not to make it difficult for such persons to do so or force them to leave some traces when they "jump the wall" (SM21, ST22, SM20, etc.)

Regarding email, you can share your email address or an alternate email address in your SDN Business Card. Posting it here is not advisable, and will be removed again. Also note that if you go "offline" in sharing documents, and that document contains some baloney, then there will be no one other than you to spot it...

Take care,

Julius

[Former Member]

Hi peter,

If you really want to learn what are the things that you have to restrict then search for SOX compliance on net for SAP system.

As for example you can restrict the users in the following way:

(1) find out the way you are creating the customizd programs for HR..if so then give the T-code to individual programs.....and assign that T-codes to the respected person only.(This is what we did oin our project)

(2)you also have to implement "Authority check" syntax in each and every Hr customized program so only authorized person only will run the program....

(3) you have to take care for access of Tables and for that you will create one authorization group and assgin the the users....(SE54 or SU54)....

(4) Also take care the BASIS access that will not be available to any developer.....

(5) implement the suggestion given by the moderator...so it is not one day activity...it will take 3-4 month time to stream line the path.

Anything else then let us know...

Regards,

kamlesh

[Former Member]

No further responses

[Former Member]

The comment field when closing threads is not mandatory... so you dont have to bump all old threads to the top of the forum again.

Cheers,

Julius