SAP security for all T_code

[Former Member]

i need help with making a role that has all possible t_code which has display authorization only

[Former Member]

Hi Naimesh,

We used a hard way fo rthis during the creation of a display all role. In the S_Tcode we use ranges so that all tcodes are covered under their ambit. Then the value of the ACTVT has been changed to 03 so that only display role is active,..also note, the Tocdes shd not have sensitive tcodes and basis transactions and hence there the ranges comeinto place. i remember in earlier versions there used to be Display all role in SAP. as tandrd display role and we used to base the new role after modifying the same.

But now its the harder way...

Br,

Sri

Award points if this info is helpful...

[Former Member]

hopefully someone gives a better method for this activity so that i benefits me aswelll...

TIA

Sri

[Former Member]

If you are working on version below 4.6c you can find

SAP_ALL_DISPLAY role.

otherwise you got to spend time pulling SAP_ALL,SAP_NEW

and changing the actvities under objects to 03.

[Former Member]

I can't find role sap_all_display or sap_all or sap_new

in the activity field do i have to manually change to value to 03 or is there a easy way to change all of them

[Former Member]

until R/3 4.6c SAP used to deliver SAP_ALL_DISPLAY.

i guess they removed it from 4.7 enterprise.

SAP_ALL, SAP_NEW are delivered profiles.

goto PFCG-->authorizations tab.

either you can choose SAP_ALL template or goto edit

insert authorizations--> full authorizations.

now you have to maintain ACVT=03 and probably 07 for some objects. this will take lot of time.and you have to be careful with lot other objects.

other option,if you have time you can try finding a way to clubb copies of all SAP delivered 'display' roles.

Message was edited by: Keerti Vemulapalli

Message was edited by: Keerti Vemulapalli

[Former Member]

Option 1 : create a Composite role with copies of all singular standard display roles provided by SAP. (still lot of work to be done)

Option 2 : Download SAP display all from 4.6 to ur desktop and upload it into 4.7 a small trick used by me initially...and then modify this role accordingly by adding the new Auth objects that exist in 4.7 and higher versions. (unconventional way to do this action but it worked at tht time)

Option 3: SAP_All & SAP_NEW areprofiles and not roles.

Create a new role from PFCG and you have options inthe menu ( Insert authorizations from profile ) there input this profiule and you would get all the auth objects into this role. Then change many things to in ACTVT to 03,16 and 07 and 09 in many cases after checking all the actions. It wd take time but this role is very handy and can be assigned to many non buisness users and developers in Prd environment.

Hope this answer has some inputs for you and points for me

Br,

Sri

[koehntopp]

This is a baaaad idea for so many reasons, I don't even know where to begin

- NOBODY needs ALL TCodes

- There are many TCodes that can't be restricted by activity

- There are many transactions where even display will have to be considered harmful (HR, conditions, configuration, ...)

- The auditors will KILL you

If you need display roles, copy them from the functional roles you have assigned to the workplaces, then check for activities.

Also, this will save you a lot of time because the functional roles will have a LOT less objects to maintain.

You really should re-consider your authorizations concept...

Kind regards,

Frank.

[Former Member]

<i>"The auditors will KILL you ;)"</i>

The chances are very good that this role is <b>for</b> the auditors. They will LOVE you!

(Try take SA38 / SE38 away from an auditor! Their working papers grind to a screaching standstill)

[koehntopp]

If this is the case - there are pre-configured roles for auditors that do the trick.

I definitely wouldn't want an auditor with an all-TCode role in my system...

[Former Member]

Hi Frank,

Although I principally agree with you... I disagree with you in all other respects. Sorry.

Out there in the wild the general problem with the auditors and s_tcode is:

a) there are many of both of them,

b) they look at different things in different ways,

c) it is difficult to know what their entry point is going to be for that which they are going to look at.

So, in a similar way to how you cannot predict or dictate what an auditor can and cannot look at, you have the same difficulty in S_TCODE most of the time. You are left with even less choice because the accounting companies have audit programs which have "type /nSE38 into the window" etc all over the place and you get harrassed until you give it to them.

Where I also disagree is using the pre-configured role approach (AIS). It limits the auditor to that which SAP "releases" for auditors to look at. Personally I would never accept that.... which may sound nice at first, but at a closer look there are sometimes equally or more hazardous problems lurking there. (E.g. SAP_CA_AUDITOR_SYSTEM -> Post to the G/L? Change SM59 settings? Debug other user's processes? Execute (virtually) any program or c-function? They might give themselves SAP_ALL even if you take all the tcodes away...)

Perhaps you could add a message type "Warning: Transaction & has not been released to be audited"

Cheers,

Julius

[koehntopp]

Julius:

good points. If that is the case (to be honest - I haven't checked the roles in that detail...), we need to look into that. This should probably not be the default setting.

The point I was trying to make was that there is a better starting point than SAP_ALL. In my opinion, anything that starts by modifying SAP_ALL is doomed from the beginning

If you're giving auditors SE38, how do you control that in your environment?

Cheers,

Frank.

[Former Member]

Hi Frank,

I would like to add that I do find the AIS usefull for finding helpfull reports and transactions which I didn't know about!

I can only comment on what I have seen out there in the past years (about 500 SAP systems) which is also the suboptimal starting point you referred to => Copy SAP_ALL, set the many activity controlling fields to display, remove or restrict a few nasty other objects and range around some naughty tcodes and then give it to the auditors. Given the alternatives, I would say that this is fit-to-purpose. (PS also take a look at the *_display role in the AIS).

Regarding SE38, please understand that I do not "have an environment" so I have not controlled this. If I had one, then I would give them SA38 and keep an eye on the reports they are running. When (if) things like RS_TESTFRAME_CALL start turning up then I would move it into a more secure authorization group.

I would also give them SE16 and keep an eye on the tables they are visiting (might even learn a thing or two).

There is anyway no substitute for security monitoring, right? And a good auditor should also check that I am doing this!

Regards,

Julius

[Frank_Buchholz]

Summary concerning SAP predefined authorization roles for auditors (see note <a href="https://service.sap.com/sap/support/notes/77503">77503</a> for details)

The role SAP_CA_AUDITOR_SYSTEM contains authorizations which are needed to access all security related basis functions which might be useful for an system auditor. The role does not contain development authorizations or application authorizations. However, the role contains several other critical authorizations enabling the auditor to change some important system settings. Why? Well, some security related settings are only visible in change mode. You assign this role if you trust the system auditor that he does not misuse his authorizations by accident or knowingly.

On the other hand we deliver the reduced role SAP_CA_AUDITOR_SYSTEM_DISPLAY which contain only these authorizations which offer display-only functionality. A system auditor having this role will be able to perform most system audit steps by himself, but for some areas he will have to ask the system administrators to produce the required reports.

Conclusion: Depending on your requirements you can choose the appropriate role.

[Former Member]

Dear Julius,

being an auditor:

I need access to report RSABAPSC - to check source codes for authorization calls.

I need access to S_DEVELOP / DISPLAY for the same reason.

Taking that starting point into account:

If I don't get all the other T-CODEs I need, you will find me using RS_TESTFRAME_CALL a lot

(BTW: Standard use of RSABAPSC of course is to see whether RS_TESTFRAME_CALL has been patched ) On our systems it has been now - but only because we auditors were stupid enough to ask for it. )

The end-result of the whole line of thought is:

If your system is bullet-proof - you will have a lot of work with tight authorizations for the auditors ))

So I agree:

There is a point where the preventive power of authorizations stops and you have to go for detective measures. And monitoring the auditors is not a bad idea at all.

Regards,

Ralf

[Former Member]

Hi there Ralf,

What do you mean by auditors were stupid enough?

Thanks for RSABAPSC. I used to use RPR_ABAP_SOURCE_SCAN but the bother is that it does not analyze the commented out text or coding.

Kind regards,

Julius

[Former Member]

Well, if using SAP_ALL is not a good start. How about SAP_ALL_RESTRICTED? Without BC, CA, HR, modify the ACTVT to Display, it should satisfy most needs and without jeopardizing security issues, isn't it?