Basis recomended authorizations

[Former Member]

Hello all,

Does anybody knows what is the recommended sap role\profile for the basis team ?

Thanks,

Julia.

[Former Member]

Hi Julia,

with any authorisation design, best approach is to go with least privilege. The basis team should be able to provide you what they are required to access. the access should also fall in to two buckets.

1. Daily monitoring support (day to day access)

2. Exceptional support (fire fighter access)

A starting point you can go is list out the transactions in the following range and discuss with the basis team on which ones they need and any other specific transactions that are required.

Transactions

AL*

DB*

RZ*

SC*

SE*

SM*

SP*

ST*

SW*

WE*

Pay special attention to the auth objects in the following object classes

AAAB

BC_A

BC_C

BC_Z

For Java, look in to roles with

*NWA*

*admin*

as starting points.

Regards,

John

[OttoGold]

Hello.

IMO John is right. You need to gather a list of transactions first, then merge the authorizations from SU24 data, get some values (not * everywhere) for the open fields and then ideally identify what is still critical there. Not everyone can afford SoD, but to some extent everyone should segregate the most critical tasks. If not technically possible (two basis users in the whole company etc.) then you need to list the risks at least, make others aware of it and ask the admins to be nice.

Now seriously: what I am trying to say that I learn most of the things I need to know about the company, the basis jobs, the people and the processes when I am building the roles. Which means there are no shortcuts if you want to do a good job.

cheers Otto

p.s.: About Steve's post below: I would be very careful about distinguishing between the prodcutive client and other clients in the same system. I have seen customer systems with amazing level of security in the productive client and the door wide open in the "basis client". Even standard passwords unchanged etc. Basis are your friends, but you must keep an eye on them.

[Former Member]

Re: Basis clients

I absolutely agree that you need to be very careful. Maybe a little less careful that with a production client, since you can't get to transactional data, but for sure without some level of control a basis client can still be a big security hole. You don't want to permit a free-for-all!

There are some things, though, that can be done in 000 that are harder to allow safely in a productive client. And Basis folks will need access to client 000 anyway for some admin tasks, so you do have to (a) allow it, and (b) think about it.

[former_member518118]

Hi Julia,

For the basis administrator and basis people contain SAP_ALL and SAP_NEW in the profile for all type of activities can be perform by administrator

Regards

Naveen

[Colleen]

No! No! No! Especially in Production, No!

Segregation of Duties and access risks just to begin with. Basis do not need end user access nor debug change and so on to support the system. Have fun with justifying this to the auditors.

Support users are no more special than any other type of user when it comes to designing and build security. Support Users are just another category of end users with a different job to do. You should complete your access mapping exercise and identify their access requirements and then build accordingly.

Have a look at the SAP_BC* roles as starting point for access as well as the SAP standard menu for Administration

Regards

Colleen

[Former Member]

Hi Naveen,

That is really, really not a good idea.  No-one needs SAP_ALL and SAP_NEW (why would you need SAP_NEW anyway if SAP_ALL is up to date?).

[former_member518118]

HI

SAP_ALL- Which is a composite profile, normally assigned to administrators

and

SAP_NEW authorization have,

like access to newly created customized objects

Never recommended to assign sap_all to any end users.

Regards

Naveen

[Colleen]

Basis do not need SAP_ALL

What do you mean by SAP_ALL having newly built 'customised' objects?

You might find the following article beneficial..

Regards

Colleen

[Former Member]

Seconding to Colleen's and Alex's suggestions, would like to add:

You are proposing solution to cause a serious security and Audit breach.

This should never be recommended to anyone regardless of the environment.

Better design the roles based on the activities to be performed by Basis Administrators, based on SOX.

Regards,

Ameet

[former_member518118]

Hi Colleen,

Thanks for the article and have one query.

All the roles are mention that is

1. SAP_BC_BASIS_ADMIN

2. SAP_BC_BASIS_MONITORING

3. SAP_WPS_BC_BASIS_ADMIN

have the authorization of TR import in Productive system?

Thanks to all.....

Regards

Naveen

[Colleen]

Hi Naveen

Okay, they all have the access but what is your query?

Glad to hear you found the article useful  - I learned a lot from it as well.

Regards

Colleen

[OttoGold]

Just to add an important point about SAP roles... The recommendation is to use them as a template, not to generate profiles and use them directly (unless it is some hardcoded SolMan role name which is generated by the SAP themselves) or copy them into your namespace and pretend you've built them yourself. Just saying.

cheers Otto

[OttoGold]

Be careful, pal. This is a public forum. This can cost you a job

[Colleen]

Hi Otto

Yes - I did mean to use the SAP* roles as a starting point to see what access is required. Unless a Solman (got into a bit debate with a SAP Basis on whether you use the SAP* roles or build ZSAP* roles for Solman) or J2EE role I always build my own

Regards

Colleen

[Former Member]

Where to start...?

First, and most important, nobody has SAP_ALL in the production client. Not even Basis. Nobody. No exceptions. Well, there are exceptions, but they are, rare. The only time anybody here has SAP_ALL in production is during upgrade weekends.

Second, every site's Basis job role is different. Some of the standard SAP-provided roles might be close to what you need. None of them will be exactly right. You are much better starting with an empty role and adding transactions as needed.

While doing this, don't blindly believe Basis when they say they need a particular transaction. They don't need SE38/SA38, or SE16, for example. Not on a permanent basis anyway. Maybe on rare occasions to implement an OSS note or similar. Think carefully about each request and what it will allow them to do. If you don't use a GRC application to automatically check for unfortunate combinations of transactions, think very carefully about each request.

Finally, notice I said above Production client. You will typically have one production client in your system, along with client 000. You may find it acceptable to give Basis more access in client 000 than you'd be comfortable giving them in the production client, since they don't have access to transactional data. Much of what Basis needs to do is client independent, so this works quite well.

This stuff isn't easy. There are no simple answers, and no simple solutions. Think about it carefully or your auditors will ultimately give you a hard time, and for good reason.

Hope some of that helps.

Steve.

[Former Member]

Hi Julia,

A copy of 2. below will do, just check further to ensure it's DISPLAY only, you could create a display version of 1. and 3. as well if required.

1. SAP_BC_BASIS_ADMIN

2. SAP_BC_BASIS_MONITORING

3. SAP_WPS_BC_BASIS_ADMIN

This is the simple solution.