Restrict HR tables

[Former Member]

Hi

Could you pls tell me How to restrict HR tables in S_TABU_DIS and display all other

thanks in Advance

[Former Member]

1. Identify all HR tables that need restriction (lots of them begin with P, there are some that are T, some that are D, some that are H) Involve your HR team and get them to make a definitive list.

2. Once you have an agreed list of tables, use table TDDAT to see what auth groups are placed on them and ensure that no non-HR users have access to those auth groups in S_TABU_DIS. Where the table has auth group &NC&, change it via SUCU or SE54 to something more meaningful and as before ensure no non-HR users have access to it.

This may give you reasonable control over accessing the data via SE16, SM30 etc, but you still have the problem of the data being accessed programatically so you will be wanting to remove access to debug (so the developers can't hobble the check when retrieving the data from tables.

Note: this and many more steps are required depending on how badly you want to restrict access to HR data. It will probably annoy the developers too (I'm assuming we are in a non-production environment)

Message was edited by:

Alex Ayers

[Former Member]

Hi Alex

thanks for your reply

i wnat to restrict in S_TABU_DIS auth.obj.for this can i select all except HR tables (H* and P*).is going to be enough in Production system

[Former Member]

Hi Prasad,

As I said, identify all the authorisation groups placed on the HR tables and make sure that these are <i>not</i> included in S_TABU_DIS for the normal users.

Your HR team will tell you exactly which tables contain sensitive data. All the tables that don't have an authorisation group assigned to them (you can see this in table TDDAT) should have an authorisation group assigned against them. Not all HR tables are just in the H* and P* name spaces so you need to get the input from someone who properly understands the tables (you may be able to find a list somewhere here: )

This way you can split table access between Non-HR (They don't have any HR relevant table auth groups in S_TABU_DIS field DICBERCLES) and HR (They have access to the restricted auth groups).

It's not a straightforward piece of work as access to tables via SE16 etc (I assume that's why you need to protect the data) is not designed for granular access without a considerable amount of additional work being involved.

I hope that answers your question

[Former Member]

This P* Auth Groups should be ok to give access to:-

PMTC

PSC

PSFP

PSIC

PSR1

PSS

PSSR

Please check with HR before you give access to this Auth Group.