Restricting SE16 and SE16N access to certain tables using table ranges

[Former Member]

We would like to have access to SE16 and SE16N changed so certain tables with sensitive information CANNOT be viewed.

Our plan was to implement this by specifying a range of tables that CAN be accessed!

Nevertheless, we are struggling to find a way to have this done properly... tried creating new authorization group (DICBERCLS) but could not associate a range of table to it...???

Please make any possible suggestions and share any ideas!

THANK YOU!!!

[Former Member]

The best way to secure access to your tables is to not give access to SE16 at all. Make the business identify the tables that need to be viewed and use a table maintenence transaction instead. That way you know exactly which tables are being access by each role. You can also populate SU24 for the new table maintenance transaction with S_TABU_DIS and the right auth group for each transaction.

If a user cannot tell you which table that he needs to view in SE16, then he probably doesn't need it. You'll always have people give you the "I need it just in case..." argument, but that is why you have support roles ready or some type of fire fight access that can be granted for a short period of time.

If you go ahead and give access to SE16, you can specify a range for auth group in S_TABU_DIS and exclude the sensitive auth groups (like PA), but keep in mind that not all tables belong to an auth group. If it turns out later that there is some data within the table that you want to restrict (i.e. you want to restrict access to Company Code 1234), you can't do it. It's all or nothing in SE16.

As you found out, you can't assign an auth group to a range of tables; you have to list them out individually.

I know it's difficult to remove access to SE16, especially if the users are used to having it. We're going through that painful process right now. But in the long run, you be glad you did.

[Former Member]

Thank you David!

I believe that our superiors have deemed the creation of custom table display transactions very time consuming for the development team. Do you have your Sec Admins create these custom table display / maintain tcodes or do you have your ABAPers do it?

You wrote: "If you go ahead and give access to SE16, you can specify a range for auth group in S_TABU_DIS and exclude the sensitive auth groups (like PA), but keep in mind that not all tables belong to an auth group."

Question: I don't see a way to do this and make it work since I need to restrict access to one table in several different auth groups... Any ides??

You wrote: "If it turns out later that there is some data within the table that you want to restrict (i.e. you want to restrict access to Company Code 1234), you can't do it. It's all or nothing in SE16."

Question: How could I restrict access by Company Code if I don't allow SE16??

Thank yo so much! You've enlightened a passionate SAP Security rookie!

[Former Member]

I always have the ABAPers create the table maintenance transactions.

You said "I need to restrict access to one table in several different auth groups." First you should understand that a table can only belong to one auth group. Using SE16 you are restricting access using authorization object S_TABU_DIS. You populate the DICBERCLS field with the table authorization groups to which you want to provide access. Unfortunately, there is no way to list tables out individually. You either give access to all tables in the auth group or none.

If you have a need to restrict access to certain Company Codes (or anything else for that matter) within a table, then you are looking at custom code. Standard SE16 cannot accommodate this. You would have to create a table maintenance transaction to view the table, then perform an authorization check after the selection criteria is entered. If the user is authorized to view the requested records then let it proceed. If the user is attempting to view restricted data for which he does not have authorization then the transaction can either give him a hard failure or just filter out the data that he isn't authorized to see (warn him though). This isn't an easy solution and you wouldn't want to do this for many tables, but if the business really wants it then this will do it.

Hope this helps.

[Former Member]

Short answer DO NOT use SE16.

have abapers create custom reports for this kind of requests.

If management does not allow that let them take the heat when you are sabled down during the first audit!!!

As no auditor will let this kind of thing pass!!

[Former Member]

What do I need to worry about, transports wise, once I create a new Authorization Group using SE54 and associate some tables with it?

Please advise, and if possible, specify the transport steps.

Thank you!

[Former Member]

Hi David,

after collecting table data,how to analyse access for users in scope.i e. where do we put the new transactions.

Thanks

Khaisere

[Former Member]

Thank you!!!

I will share your thoughts with the rest of the Basis team!

I appreciate your help!

Regards,

Ivan

[Former Member]

Hi Ivan.

You can assign tables to authorization groups with transaction SUCU. The relationship is stored in table TDDAT.

If you want to show tables with SE16, but only a few tables, you can create a transaction for each table. Each transaction calls SE16 with tablename as a parameter. It is a safe way to give access to tables with the SE16 layout.

If you also want to use SE16 to give access to a table, - but for example only for CompanyCode 0001, - then you create a new table view, that uses the first table. In this call, - you insert the parameter CompanyCode=0001. Then create a transaction that calls your new table view.

Br. Ivan Rønnengart.

[former_member1329783]

Will the restrictions made to the tables impact the standard (transaction) functionality?

[anne-petteroe]

Hello,

While we're happy that you've come to SAP Community to get an answer to your question, you posted your question as an answer in an old thread.I've converted your answer to a comment, but even so -- posting in older threads is not the best way to get guidance.If you're looking for help, you should ask a new question: https://answers.sap.com/questions/ask.html.Here are some tips to help you craft an effective question for our community: https://community.sap.com/resources/questions-and-answers, https://developers.sap.com/tutorials/community-qa.html, https://groups.community.sap.com/t5/welcome-corner-discussions/advice-from-sap-champions-questions-a... encourage you to follow this guidance, as I'd really like to see you get a solution to your problem.

I hope you find this advice useful!

Best regards,
Anne