SAP_ALL on Sandbox

[Former Member]

Hi All,

We have a brand new sand box for SCM-APO which was built 2 weeks back, few SAP consultants are working on the box with SAP_ALL profile.

Is it OK, to give SAP_ALL on sandbox, as technical and functional consultants are doing R&D work on it. Or should I be stuborn on restricting users even on sandbox.

Please correct me if I am wrong, I think its consultant/User responsbility to define me the role or TCodes which they need on the box right! instead of assigning SAP_ALL.

Being a Security consultant, could I be stuborn on not giving SAP_ALL and ask them to define me the role or responsibilty if they need access on the system.

I will appreciate forum thoughts on this or suggest me on what responsibilities I should be tight.

Going forward I will own these boxes....! So I want to take no chances be clear and transparent...

My Manager want me to own the boxes and take my decision..!

your thoughts..!

Thanks in Advance..

Anil.

[Former Member]

First of all, your thoughts are right even in a Sandbox SAP_ALL is dangerous. So try to avoid this kind of access as much as possible.

One reason the sandbox stands in the same landscape as your other systems so RFC connections can be made! and someone with SAP_ALL can control this without you knowing!

and an other Yes it is the responsibility of consultants to tell you what access they need.List of TRX

Normally i create area menu's (adding all trx form an area in a single role giving them full access to that area)

remember as long as you are carefull with S (system) TRX not much harm can be done, also most companies that give wide access give no garantee on the quality of the sandbox.

Besides as i hope no one is stupid enough to have prod data in the sandbox there is non need for SoD etx.

Let's all play there!!!

[Former Member]

Even in SandBox neither do I give SAP_ALL, my design here is I given the person the businesses need in his particular area.

But to answer your question NO SAP_ALL to anybody in Any box ! of course you will be under presuure to give them from business heads.

Thanks

[Former Member]

Friends,

Why not SAP_ALL.

Sandbox is a place where you can actually get your hands in mud and try making pot. If you are going to restrict the SBX then its like defeating the purpose of SBX.

I would definitely give SAP_ALL.

For the SM59 connections that can be made to other boxes, you need to supply the SM59 with user credentials in Logon/Security screen.

So do you still think giving SAP_ALL is vulberable.

Thanks.

Note : Roles in SBX one more added responsibility for User Admin in bigger landscape.

Regards,

Muthu Kumaran KG

Edited by: Muthukumaran Krishnan Govindan on Mar 11, 2008 6:33 PM

[Former Member]

> For the SM59 connections that can be made to other boxes, you need to supply the SM59 with user credentials in Logon/Security screen.

The users might try to enter themselves into the RFC connections; but then again they could also bring their own SAP system into the network if they really wanted to...(or at least the client network).

Cheers,

Julius

[Former Member]

True. Given the fact the SM59 is restricted well for the business users in D,Q & P using the own user ID may not help unless the user is Technical team guy in which case that should be fine.

Regards,

Muthu Kumaran KG

[Former Member]

Muthu,

More than vulnerablity --its the business practice that needs to be up held.

I can tell you a great %of the user doesnot even know what sap_all contains --> they dont know what they can do --> but this is no reason to give them SAP_ALL in any box.

To the business heads --. I tackel them this way : depending on the business area --> fiance for example --> I ask them the followin gqueistions;

1. How many folks can sign a check ? can all in your deptt sign ?? ---

Such questions when you put forth to the business heads they understand.

Thanx

[Former Member]

SM59 is just one.....does the person in the warehouse need to create a check?? or even use that functioanlity ? no ..then why assign him --give him an all encompassing in warehouse --that is good enough

[Former Member]

George,

The SBX is a play area, learning area.,

Let me ask you the same question.,

What if the person in the warehouse need to create a check ???

Do you want him try practice how to's in D,Q or P.

Lets take security example.,

Say you want to create some Auth Object., will you try do that once in SBX before you actually try do it in landscape.

SBX is a place to....

When you are not bothered about SOD and SOX in SBX then why not SAP_ALL.

Regards,

Muthu Kumaran KG

[Former Member]

>

>

> When you are not bothered about SOD and SOX in SBX then why not SAP_ALL.

Hi Muthu,

SAP_ALL will allow someone to trash the system & as a result I still pull certain S_ auths from users to reduce the risk slightly. The role is still very wide, just some barriers to hosing the instance are put up (though they will still not stop a determined person but then again I'm not that fussed about the sandbox).

[Former Member]

That was some really interesting views about this topic.

As long as the client is ready to buy SAP_ALL for SBX then its fine.

Creating a similar SAP_ALL with all auth's but S_* would be a good idea.

I have heard of customers who got SAP_ALL in production (probably they may not have heard about SOX and SOD)

Thanks.

Regards,

Muthu Kumaran KG

[Former Member]

My question is not exactly pertaining to this topic but somewhat related.

Speaking about SOX and SOD, I have been told by many Basis Admins that the same person should not be managing both Security and Basis in Prod. But what about smaller Organizations (like mine). We don't have a huge SAP team. Our Basis team consists of 2 people (including me) and I manage the Security as well.

So all the roles in Prod are currently created and transported by me. I have sap_all which I plan to change in the next couple of days and we are planning to Go Live in 3 weeks.

Does having just 1 person for both Basis and Security risk the chances of failing SOX audit ? Or are the SOD rules a bit lenient for smaller Organizations like ours ? Can you guys give me some tips to what I can do if you foresee trouble.

Thanks,

Kunal

[Former Member]

Welll if he wants it ..GIVE IT ! I woudl readliy give it ..but again its far less than SAP_ALL --!!

[Former Member]

Well, obviously basis admins should not do security stuff. Its a definite conflict.

Some big installations have separate team for change management and transports.

Even SAP recommends Dual and Treble concept in User and Role administration.

These things are no quite possible in small installations.

Whether it will pass a audit or not it's a auditor's call.

First of all.,

1. Is the company private owned or public listed

2. Is it federally regualted (energy, defence, health etc industries are federally regulated)

Whenever there is a risk there are 2 options.,

1. You live with it with mitigation defined for it

2. You control by removing it

What a risk in one business might not be the same in another business.

The levels of mitigation cannot be defined and depends on nature of the business. (Definitely SAP_ALL in PRD is not mitigation by any means)

This is quite difficult topic to give specific answers. It requires a complete understanding of business.

Work with internal auditors to sort this out.

Thanks.

Regards,

Muthu Kumaran KG

[Former Member]

Oh Yes - You guys are correct, I have pressure from business heads saying that its only a sand box so they can have sap_all...they say that we cannot tie their hands on sandbox.

What ever the scenario may be, if they come across any error they point security team...but yes even I was thinking the same as you guys...wanted to make sure before implementing...as before I was only a admin.....now I have lots of responsibility as I own the boxes.

And I have to back up my words and actions....

Thanks Guys..Appreciate your ideas...!

[Former Member]

That was a great thoughts, for some reason even I dont like to give SAP_ALL on any systems. I tailored SAP_ALL by removing S* auth's, it took long time for me to define ranges I am just waiting to watch what kind of auth issues will flow in.

As I saw many of the SCM tcodes start like /scmapo/, /***/ and so on. And also I saw my consultants roaming around the system which I really do not think they should be doing.

I dont want to tie their hands, however you know human tendency they get used to the things

Thanks All.

[Former Member]

Anil,

I did the same thing on Dev and QA. However, you would need to give them access to certain Basis Tcodes especially since it is SBX. I guess it is okay to give them these

ST22, SM21, SM36, SM37, AL08, SU01d, AL11, SE38, SP02, SM50(maybe). Also, I guess its okay to give them S_TABU_DIS with 03 activity. Limiting all S_* objects might be a bit too much for SBX.

Kunal