This website is not affiliated with, sponsored by, or approved by SAP AG.
6 posts • Page 1 of 1
In our company table navigation through SE16/SE16N is a useful tool for those who works with support. Our security team dont find it necessary that they have unlimited acess to tables and have demanded that they have their acess restricted.
We have identified certain options.
1) Create Z-transactions to each to table needed. Each Z-transaction will be merged to specified single roles.
This option requires maintenance and will require a lot of transactions.
How is this question being solved at your companies? Any help is appreciated
what about a authorization group for tables? You create one like ZSUP. Then in the role you customize S_TABU_DIS with 03 (show) and your new group.
Of course you must put your tables to the group first.
And, unfortunately, any table with no authorisation group will be accessible to all
Ã¤h, seems sharpshooter is right, I had that not in mind.
So you could use a negative aproach: But sensible tables in a group and do not assign the group.
I found also something else: Look at SAP note 1481950, there is a new object called S_TABU_NAM. You can put in the allowed tables, but you must disable S_TABU_DIS first, because that has a higher priority.
Maybe that is a solution for you
But tables should always be put in to table groups, customized tables created by developers should be have a table group associated. SAP standard tables have a table group as well?
The problem is that we dont have any good logic what considers table and table groups for securing them in to roles. So its to late to put them in to table groups without going trough all tables that used.
Is it possible to allocate a table in to one or more table groups? Got an idea to create a new table group in SE54 and assign all the needed table in a certain group and to build roles with this group.
I will look up the new object in that SAP note, thanks.
It is common to remove SE16 and create Z tcodes that call only the table needed. It is probably the best option.
If you allow SE16 and rely on auth groups, which is also common, you will be able to do a good job of protecting sensitive tables.
However documentation on what tables are sensitive to your company is the key to getting a high audit rating because it shows that you know what is critical and have implemented some sort of review on these tables and auth groups and have a strategy to protect them. In which case SE16 will not be flagged by auditors. With no documentation it will be flagged.
The down side of SE16 and auth groups is that you have tables that have no group. In this case the group is &NC&. Whenever this occurs in an SU53 don't add it to a role or you open up access to many tables without auth group assignments. Instead assign the table a group. It is probably not going to be a critical table that has &NC& but unless you have documentation it will be assumed by auditors that you have no idea whether a table with &NC& is critical and they will tell you that you should not allow &NC& in any of your roles.
SAP Security Consultant
6 posts • Page 1 of 1
Who is online
Users browsing this forum: No registered users and 3 guests