topic Re: Authorization group changes for Security reason in Application Development and Automation Discussions

Authorization group changes for Security reason

Former Member — Thu, 11 Dec 2014 15:13:11 GMT

In Production sometimes I have to give access to "table" transaction like SM30 in modification.

When the authorization group is restricted to few tables, I can give access.

But some transactions are linked to views with LARGE authorization group like &NC& or VC.

So if I give access in change on S_TABU_DIS in &NC& or VC or others standards authorizations group, I potentially give the change access to others tables, so Ineed to restrict the access to SAP tables...

What do your recommend? What is the SAP best practices on this issue?

--> Change the standard authorization group to a specific one?

--> Create a specific view with a specific authorization group and Create a specific transaction in this view?

Thanks a lot in advance for your answer.

Mélanie

Re: Authorization group changes for Security reason

Colleen — Thu, 11 Dec 2014 15:26:55 GMT

Hi Melanie

Another option is to avoid granting SM30/SM31/SM34 in Production by building a custom transaction code to access the table or view that skips the SM30 screen. Also, check if such a transaction already exists for the table you want to maintain (table TSTCP contains the parameter defs).

If not, see if you can use S_TABU_NAME instead of S_TABU_DIS (if you search marketplace or SCN you will find notes and information relating to this object). However, you would need to clean up the use of S_TABU_DIS

Regards

Colleen

Re: Authorization group changes for Security reason

Former Member — Thu, 11 Dec 2014 15:39:41 GMT

Thanks Colleen. It's works for ECC6 version.

But for 4.7 version... ? There are a SAP note to add this authorization object S_TABU_NAM ?

Re: Authorization group changes for Security reason

Colleen — Thu, 11 Dec 2014 15:43:38 GMT

4.7 is too old for that object. You would need to look at Z transaction code instead so you can avoid granting SM30 (pretty sure but haven't been on a 4.7 system recently to confirm).

Re: Authorization group changes for Security reason

Jelena_Perfiljeva — Thu, 11 Dec 2014 16:29:50 GMT

We don't give SM30 authorization to the business users at all and found that using custom transactions that allow for additional authorization checks (e.g. by an organization code) works better for us. I wrote on this a while ago and there are also more recent blogs on SCN on using maintenance views. In some cases we have one program call maintenance view for several Z tables. Although the best approach is to avoid direct table maintenance altogether, I think.

Re: Authorization group changes for Security reason

Former Member — Wed, 24 Dec 2014 07:47:16 GMT

Hi Melanie,

You can create a customized T-code like ZSM30 where in you can specify authorization fields similar to S_TABU_DIS with an additional field which will have the table name under the customized authorization object linked to this T-code. So whenever a user executes the T-code ZSM30 the logic should work in such a way that it should first check the custmoized Authorization object and see if user has access to work on the particular table and then it checks for the S_TABU_DIS object with the required authorization values. In this way you can restrict the user.

Hope this helps.

Thanks.

Deepak grover

Re: Authorization group changes for Security reason

Former Member — Thu, 08 Jan 2015 12:54:30 GMT

Thanks a lot for your answer Colleen.

SAP has sent to me this OSS Note Number.

1634305 - Advance implementation of authorization concept S_TABU_NAM

I will see if it's ok in my SAP system.

Thanks to all.

Mélanie