How to manage Basis Transactions?

[Former Member]

Hello all,

Post AC 5.3 go live, we've taken on the painstaking task of re-engineering many of our SAP ECC Security roles. Our goal was to be SOD violations free at the Role level, and then put the ownership on the Business to decide what violations at the User level were warranted (requiring mitigation), or else a change would have to occur on the Business Process (BP) side.

We are struggling with the assignment of certain Basis categorized transactions such as SM36, SM37, SE16. The majority of our BPs are very batch processing oriented, which require our users to have batch processing authorization. However, if we included SM37, for example, into any role RAR comes back with a HIGH risk message.

I'd like to know how other AC shops are dealing with these types of transactions/authorizations? We have an upcoming audit in March and would like to have something in place before then.

Thansk in advance,

Jose Garcia

Edited by: Jose Garcia on Dec 2, 2011 12:32 PM

[Former Member · Accepted solution]

Hola Jose,

Users should be able to schedule their own jobs, but the mustn't be able to run the job on behalf other user:

If you have periodical background jobs, take this into account:

and check what Julius said

Regarding SE16, users mustn't use it in PRD.

Basis roles will always contain Critical actions. Change other user's job is a critical action, but It's part of Basis activities, so if you grant this auth only to Basis team, you shouldn't have problems with auditors. Note that This is NOT a SoD conflict but a Critical Action. Not the same!.

Regarding Basis SoD conflicts, well... Mantain roles and assign roles to users generate a SoD conflict. If you have SU01 and PFCG in the same role you should create different roles. I've been working on this and I'll give you an example of SoD free roles as a starting point to you:

- CLIENT_MANAGEMENT (client Admin tools such as SCC4)

- ROLE_ADMINISTRATOR (Role admin such as PFCG)

- TRANSPORT_ADMIN (STMS)

- USERS_ADMINISTRATION (such as SU01)

Anyway you'll find much better replies in the security forum.

Regarding SM37 and RAR: If the authorizations in the role are restricted as Sunny suggested and the rules are OK, RAR doesn't show SM37 as a Critical Action.

Cheers

Diego.

Edited by: Diego I. Yaryura on Dec 2, 2011 8:13 PM

[sunny_pahuja2]

Hi,

Critical Transaction like SE16, SM36, SE16n etc. should be used with the help of Firefighter and these transaction access should be avoided in daily routine access. But transaction like SM37 can be given in daily access but with controlled access like SM37 only to view jobs history and logs etc. and other access in SM37 should be removed like deleting of jobs etc. This can be controlled with the help of authorization objects.

Thanks

Sunny

[Former Member]

Thanks Sunny, but my questions was more on the RAR side. For example, we've done exactly what you've described in the SM37 example (display only, etc), but RAR still flags these as High - Critical transactions. I think I'm going to have to add a rule to RAR that excludes this transaction, but I hate doing that becuase then I lose visibility.

Jose

[sunny_pahuja2]

Hi,

I would suggest you to check in RAR on which activity value for authorization object, it is giving risk then based on that you can decide whether it is critical or not.

Also, If you need some Basis t-codes in your daily activities that are not much critical then you can assign to your user id and mitigate that risk on user level instead of role level. But you should have valid reason to use that t-code so that you should have valid reasons for your auditors.

Thanks

Sunny