This website is not affiliated with, sponsored by, or approved by SAP AG.

Securing SE16 tables in to roles

SAP Security

Moderators: Snowy, thx4allthefish, jurjen

Securing SE16 tables in to roles

Postby styleforce » Tue May 29, 2012 3:28 am

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
styleforce
 
Posts: 2
Joined: Mon Apr 30, 2012 2:12 am

Re: Securing SE16 tables in to roles

Postby waltersen » Wed May 30, 2012 2:53 am

Hello,

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.

Bye
waltersen
 
Posts: 251
Joined: Wed Oct 13, 2004 7:03 am
Location: Hamburg, Germany

Re: Securing SE16 tables in to roles

Postby Sharpshooter » Wed May 30, 2012 6:35 am

waltersen wrote:Hello,

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.

Bye


And, unfortunately, any table with no authorisation group will be accessible to all :(
Good luck!
Sharpshooter
 
Posts: 1171
Joined: Wed Mar 17, 2010 12:01 pm
Location: In the dark

Re: Securing SE16 tables in to roles

Postby waltersen » Wed May 30, 2012 7:25 am

Hello,

ä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
waltersen
 
Posts: 251
Joined: Wed Oct 13, 2004 7:03 am
Location: Hamburg, Germany

Re: Securing SE16 tables in to roles

Postby styleforce » Mon Jun 04, 2012 1:27 am

Thanks.

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.
styleforce
 
Posts: 2
Joined: Mon Apr 30, 2012 2:12 am

Re: Securing SE16 tables in to roles

Postby Gary Morris » Thu Aug 02, 2012 12:34 pm

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.
Gary Morris
SAP Security Consultant
garydavidmorris@gmail.com
Gary Morris
 
Posts: 399
Joined: Sun Oct 20, 2002 10:42 pm
Location: San Antonio, Texas


Return to SAP Security

Who is online

Users browsing this forum: No registered users and 10 guests





loading...


This website is not affiliated with, sponsored by, or approved by SAP AG.