Tables with auth group &NC&

[Former Member]

Hi,

We use S_TABU_DIS and S_TABU_NAME to restrict access to tables. Howeve, in an Internal Audit Report, it was noted that we have active tables with authorization group &NC& (from TDDAT). They recommend that we remove &NC& and replace it with relevant auth grp/s.

What are the advantages and disavantages on doing this? Can you please advise what's the best practice on securing tables?

thanks

Jennifer

[Former Member]

Hi,

&NC& is the default authorisation group for tables unless another specific group has been defined. When you look in table TDDAT, you may see the following:

1. Tables assigned to specific auth groups (both standard and custom)

2. Tables assigned to group &NC&

3. Tables assigned to NO auth group.

The tables that are assigned to no auth group are in fact effectively assigned to &NC&, since the authority check will default to this auth group when a user tries to access the table. You will see that a huge number of SAP standard tables are not assigned to any auth group, and if / when a user tries to access these, the authority check will look for S_TABU_DIC DICBERCLS &NC&.

This means that a user with &NC& can potentially access tens of thousands of SAP standard tables, hence audit noting the point.

As for the pros and cons of replacing &NC&, I would consider the following:

1. Generally, you should only be looking at bespoke tables - if an SAP standard table is assigned either no auth group or &NC&, it is usually because the table is not intended to be displayed or updated directly, and therefore the lack of specific auth group is legitimate.

2. If you were to decide to change all of the standard tables to different auth groups, two things would happen. Firstly, you would reach retirement age before you finished, and secondly, people and things would stop working on your system.

3. If some or many of your roles already contain S_TABU_DIS with the &NC& value, you are going to have some problems on your hands, particularly if any of your users also have access to SM30, SE16 etc. Because they will have gotten used to accessing tables which they will suddenly lose when you change the auth groups.

4. One thing you can do immediately is to ensure that your developer standards document is updated to ensure that all new customer tables are assigned to an appropriate auth group (it is worth stating explicitly that &NC& is not appropriate - I have seen developers simply assume that this was appropriate based on the fact that it was "good enough" for tens of thousands of SAP standard tables).

5. In contradiction to my point 1, I have also seen standard SAP transactions for which the SAP standard auth defaults are maintained in SU24 to include S_TABU_DIS with &NC&. This mainly applies to old (almost obsolete) transactions, but I have seen similar on newer niche transactions. If you come across any of these, raise a message with SAP and consider adding a post to the blog post maintained by Otto Gold on incorrect SU24 defaults so that other people can benefit from it.

6. Hopefully after some extensive research and planning you will end up with a fairly long list of tables for which you are comfortable changing the auth group. At this stage you can give the list to your developers, and choose to either:

• tell them that it is possible to assign multiple tables to one auth group simultaneously
• not tell them this, and have a good laugh as they spend many weeks doing them one at a time.

7. Obviously you'll need to adjust the relevant roles to ensure that the new auth groups are provided to the people who need them.

I hope that's of some help - I'm sure there is a lot more to consider, but that's the best my Friday head can do for now

[Former Member]

Try to switch to S_TABU_NAM and at most give selective S_TABU_DIS in (display mode) to customizing groups of tables / views / clusters which only contain customizing data.

That might bring the auditor reports based in S_TABU_DIS into a very green state and you will still have a granular control.

Cheers,

Julius

[Former Member]

Hi Julius

I suggested using S_TABU_NAM and a very capable security chap countered with the fact that this then produces a high maintenance approach as users will initially identify an obvious requirement but then spend weeks complaining that additional access is needed.

I suppose it's 'For the Greater Good' in the long run but a fair point nevertheless...

Cheers

David

[Former Member]

I would counter-counter (how many of these do you think we can chain together) that they should be picking this stuff up in testing 🙂

[Former Member]

Hi DB,

Tell your security chap that if it is know what the transaction does (the tables of the views, clusters, etc) - and it is known to the system... then you can programmatically work our which table and view names should go into S_TABU_NAM for which transaction (except for SE16, SM30, SM34 themselves...) and in that case you can transfer it to SU24 automatically as well.

Works like a charm and can be done before tracing / testing even starts. You can do the same for a lot of objects like S_PROGRAM, S_DATASET, S_ARCHIVE... etc... (all the buggers..)

Cheers,

Julius

[Former Member]

Hi guys,

Very helpful inputs indeed. We can make a plan out of what you have suggested.

BTW, how can I determine that a table is "not intended to be displayed or updated directly"?

1. Generally, you should only be looking at bespoke tables - if an SAP standard table is assigned either no auth group or &NC&, it is usually because the table is not intended to be displayed or updated directly, and therefore the lack of specific auth group is legitimate.

Many thanks

Jennifer

[Former Member]

Hi Jennifer,

Thanks for the points, but I would say that Julius' answer is actually the correct one, and that mine is just a helpful one.

S_TABU_NAM gives you a huge amount of potential control over your table access policy, and I definitely should have mentioned it. But I did say I had a Friday head on