S_TABU_DIS and &NC&

[Former Member]

Hello,

We have some users with u2018&NC& authorization group and 01/02 activity value with SE16 and S_TABU_DIS authorization object.

The auditors have mentioned this is a security risk because they may have access to update more tables than they need. I am doing some research online and I find that the auth. group u2018&NC&u2019 should be removed from users and if the users need access to tables for the t-codes to work, the tables should instead be assigned to a reasonable authorization group

Can someone tell me if my understanding is correct? Also, is there any credible resources that provides best practice on this as I am not able to find?

Dave

Edited by: toosunneo on Jul 20, 2011 12:11 AM

[Former Member]

Hi Dave,

This type of queries should be posted to Netweaver--Security forum.

Yes Auditors concern and your understanding is correct. Any tables and reports which a user may need to access or change, should be assigned to a Auth Group and a User should be given the access to only those Auth groups he is intended to have.

&NC& is a group which contains all tables and reports which are not otherwise categorized including SAP Tables. It's auth should be prevented in Prod system.

If you search, you will find details on how to assign and control auth group access.

Regards,

Sabita

[Former Member]

Hi Dave,

&NC& is a group where you will see 2000+ tables. However, as long as you are restricting the authorization correctly, there should not be any risk. Here are my recommendations:

1. Don't give access to SE16, SM30 to any end/business users in Production system. Keep it with the support guys.

2. Assign the critical FI tables (or any tables that you feel critical) to a custom table authorization group. (You can create custom groups manually using SE54 transaction code).

3. Make use of S_TABU_NAM (New authorization object that was introduced) Refer note 1481950, 1522661 and 1516880 for more information.

4. Create custom transaction codes where table maintenance is required and give access to a specific tables (don't give SM30 access).

5. Use S_TABU_LIN (Line items) to restrict the authorization further in the table data.

Hope this helps.

Regards,

Raghu

[koehntopp]

This question has been answered extensively before - sometimes it's helpful to use the search function

Frank.

[Former Member]

&NC& is a group where you will see 2000+ tables. 

This is not complete. &NC& is all tables and views which have the value '&NC&' AND all those not listed at all in table TDDAT.

In an ECC system you are looking at about 18 thousand "not classified" objects. If you add other components then the number quickly grows.

Cheers,

Julius

[Former Member]

Hi Julius,

New point Noted down.. Thanks for your explanation.

Regards,

Raghu

[Former Member]

Thanks everyone for the response. I really appreciate it. I have a couple of follow-up questions.

1. This was one of my original question, is there any credible resources that provides best practice on S_TABU_DIS table security for &NC&? I have searched online and provide some helpful information on other forums, but I wanted to see if there is any credible source such as from SAP that provides some guidance on this topic? I realize this topic might be too specific, but it might be helpful if I can present this to our management as removing S_TAB_DIS with value of &NC& will take significant time for our Security staff.

2. Is it true that if the SAP production client is locked/non-modifiable and SCC4 is strictly controlled, this would prevent a user from making changes to tables using SE16, S_TABU_DIS value of 01/02 and &NC& auth. group? Can someone provide perspective on whether this can reduce the risk?

Dave

[Former Member]

You can also ask yourself: Why would a view or table requiring maintenance not be classified?

1) Once you have handed out &NC& it is nearly impossible to reign it back in again. S_TABU_NAM is a better option (use the search for it).

2) SCC4 helps but is not complete because of "current settings". See transaction SOBJ.

So... it depends on which tables are not classified but require the access.

To some extent it also depends on how generic the application lets the user choose the table and how determined they are to access the data, but neither of those are "water tight".

Cheers,

Julius