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

Authorisation group for a custom table.

SAP Security

Moderators: Snowy, thx4allthefish, jurjen

Authorisation group for a custom table.

Postby KaY-MaN on Mon Nov 22, 2004 4:09 pm

Hi everybody,

I wan to restrict access to the table maintenance of a custom table. For this, I've created an authorization group and assigned it to a custom table. The fact is I don't know what's the next step. What steps do I need to follow to allow some users to use the table maintenance but not for all the users? How can I assign users to this authorization group?


Thanks in advance!

KaY-MaN
 

Postby Guest on Mon Nov 22, 2004 7:27 pm

I am assuming you are talking about using Transactions such as SE16, and SM30 in a production client?

If so, then the correct method for protecting the table is to use the Authorization Object S_TABU_DIS in the user's role.

To do this you would create a role in PFCG and assign the transaction in the menu tab, such as SM30, then when you select the Authorization tab, you will find that S_TABU_DIS is one of the objects that has been "suggested" by the PFCG tool that may be necessary when the SM30 transaction is executed by the user.

You would assign the activity 02 (change) to this authorization object S_TABU_DIS and then restrict the authorization group field that you see here under S_TABU_DIS, to the group you assigned to the table.

That will do it. However you do need to read up on all the "gotchas" involved in allowing SM30 in production, and how to make sure you are not giving someone access to tables that you would never change in a prd client etc. As long as you know what you are doing this can be secured, the problem is that few security administrators have a handle on this much less anyone else, and so it is often suggested that you do not use SM30, SE16 in prd at all, but rather create a transaction variant with SE93 or some other method, as you are going to find that you are always having to justify the use of SM30/31 SE16/17 SE38/37 to every auditor and since they also do not know how to secure it, they will report it as a problem even if you have it locked down tight.


Nevertheless you should know how to secure tables with S_TABU_DIS in production for display as well as change, because there are cases where it has to be given access, and this is the SAP supported method for securing tables.

When you are working with PFCG and are in the authorization tab you can highlight any authorization object and press F1 and the Authorization Object (S_TABU_DIS in this case) Documentation will be presented. It is necessary to read the documentation on every authorization object if you want to know how to secure SAP. Of course you don't have to do this all at one time, but sooner or later you HAVE TO READ THE DOCUMENTATION on the authorization object if you want to know what values protect what. Print all the Basis object documentation and place in a binder, then take it with you on your next vacation. Read it while soaking up a Caribbean tan. Of course that will completely destroy any chance of vacation romance with your significant other, but it will enable you to clearly get a handle on your security weaknesses in production when you get back to work, which is where you may be spending alot more time after your significant other dumps you for being such a bore. :)

Good Luck and Happy Table Securing,
Guest
 

Postby Al. on Tue Nov 23, 2004 3:21 am

Anonymous wrote:Iit is often suggested that you do not use SM30, SE16 in prd at all, but rather create a transaction variant with SE93 or some other method, as you are going to find that you are always having to justify the use of SM30/31 SE16/17 SE38/37 to every auditor and since they also do not know how to secure it, they will report it as a problem even if you have it locked down tight.


Problem is that at the most, only 5% of implementations giving table display/maint access to end users get anywhere near securing table access. This is why it is picked up during an audit. The auditors are looking for the risks around access to large amounts of data to be mitigated. By appropriate restriction this risk is mitigated and they must accept that. Once you have shown them once, and as long as nothing changes you should be fine subsequently.
There is nothing wrong with auditors reporting problems if you can prove that they are not.
Al.
 
Posts: 3040
Joined: Tue Feb 25, 2003 5:35 am
Location: London

Postby Gary Morris on Tue Nov 23, 2004 7:42 pm

(reposting same with my login for search engine)

I am assuming you are talking about using Transactions such as SE16, and SM30 in a production client?

If so, then the correct method for protecting the table is to use the Authorization Object S_TABU_DIS in the user's role.

To do this you would create a role in PFCG and assign the transaction in the menu tab, such as SM30, then when you select the Authorization tab, you will find that S_TABU_DIS is one of the objects that has been "suggested" by the PFCG tool that may be necessary when the SM30 transaction is executed by the user.

You would assign the activity 02 (change) to this authorization object S_TABU_DIS and then restrict the authorization group field that you see here under S_TABU_DIS, to the group you assigned to the table.

That will do it. However you do need to read up on all the "gotchas" involved in allowing SM30 in production, and how to make sure you are not giving someone access to tables that you would never change in a prd client etc. As long as you know what you are doing this can be secured, the problem is that few security administrators have a handle on this much less anyone else, and so it is often suggested that you do not use SM30, SE16 in prd at all, but rather create a transaction variant with SE93 or some other method, as you are going to find that you are always having to justify the use of SM30/31 SE16/17 SE38/37 to every auditor and since they also do not know how to secure it, they will report it as a problem even if you have it locked down tight.


Nevertheless you should know how to secure tables with S_TABU_DIS in production for display as well as change, because there are cases where it has to be given access, and this is the SAP supported method for securing tables.

When you are working with PFCG and are in the authorization tab you can highlight any authorization object and press F1 and the Authorization Object (S_TABU_DIS in this case) Documentation will be presented. It is necessary to read the documentation on every authorization object if you want to know how to secure SAP. Of course you don't have to do this all at one time, but sooner or later you HAVE TO READ THE DOCUMENTATION on the authorization object if you want to know what values protect what. Print all the Basis object documentation and place in a binder, then take it with you on your next vacation. Read it while soaking up a Caribbean tan. Of course that will completely destroy any chance of vacation romance with your significant other, but it will enable you to clearly get a handle on your security weaknesses in production when you get back to work, which is where you may be spending alot more time after your significant other dumps you for being such a bore.

Good Luck and Happy Table Securing,
Gary Morris
SAP Security Consultant
garydavidmorris@gmail.com
Gary Morris
 
Posts: 392
Joined: Sun Oct 20, 2002 10:42 pm
Location: San Antonio, Texas

Postby Ned on Tue Nov 23, 2004 9:02 pm

Al. wrote:There is nothing wrong with auditors reporting problems if you can prove that they are not.


I feel confident that most auditors will believe you when you say that one needs a developer key to change a table.

Rattle off a couple more technical jagons, like sync the SAP directory with a Windows 95 installation disc, or do BDF on CNN and they back off quick enough.

Salut,
Ned
Ned
 


Return to SAP Security

Who is online

Users browsing this forum: No registered users and 8 guests



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