Do you give SAP_ALL and SAP_NEW to developer in Dev and QA environtment?

[Former Member]

Is it a normal practice to give SAP_ALL and SAP_NEW profile to ABAP Developer in Development and QA Environtment? Would you share what do you have form your Developer in these environtment? Thanks in advance

regards,

Marjan

[jurjen_heeck]

It shouldn't be, but in practice it often is. I'd like to disadvise it but have to admit I've never found a proper set of alternatives in time not to frustrate development. You're still dealing with other people's toolset........

SAP_NEW is highly overrated. If SAP_ALL is generated on your system after installation there's no added value in SAP_NEW.

[Former Member]

I think we should not only distinguish between SAP_ALL (not directly all authorizations for "the system" anyway) and SAP_NEW (usefull during SPs and upgrades), but also between Development and QA systems:

Within the "Development" environment, it might also make sense to distinguish between the source of the development (for example the "project" or the "package") and the integration system, via which this development is introduced to the QA system of the local target (PRD). It normally does not make sense to change something while in transit!

Certainly, the authorizations for the change & transport tool can be relevant (S_CTS_ADMI) and if your QA steps use the client specific management approval (S_TRANSPRT) then you can tune it further to implement release mechanisms in the QA system. Authorizations in QAS should ideally be the same as PRD anyway (so who has SAP_ALL in PRD clients...?), bar a few key (end) users for testing in QA and some access to analysis tools for testing purposes (e.g. display access to debugging).

You might also want to maintain some roles for restricting development classes / packages of objects in your local "integration system" (often Z* objects), and other more or less important roles for access to objects from global development systems (sometimes, the namespace Y* is used for this, or you can register your own '/.../' space).

If "developers" (defined as those with developer type access to something...) can change aspects of PFCG, SU24, SU22, SE11, SE38, SE30, SE37, SE80, etc etc... in a system, then the bigger picture of the landscape becomes inconsistent, unless they are in their own "private system" with SAP_ALL which cannot transport or load those objects into an incorrect development system of the whole project, such as SAP_ALL in a "local" QAS...

Restricting developer's access, is primarily a measure to mirror organizational responsibilities. The main objects to tune are the fields of:

- S_DEVELOP...

- S_CTS_ADMI...

- S_TRANSPRT...

- S_DATASET...

- S_ADMI_FCD...

- S_RFC_ADM...

...

and

- S_USER*... (multiple objects)

- S_TCODE...

- S_RFC

....

and

- S_RFCACL (of other users...)

- S_CARRID...

On the other hand... somebody with "developer type" access would often be able to hobble a security concept anyway; but restricting their access can be sensible to prevent them from accidental or careless "clicks", and raise the hurdle for bypassing organizational controls such that "noise" is required.... Restricting their access also protects them, as my "hacker instinct" tells me that if I were to want to hobble a production system, I would first target the developers in the development system...

Finally, here is a thread about building a role with developer tcodes: https://forums.sdn.sap.com/click.jspa?searchID=9336171&messageID=4066039

Kind regards,

Julius

[Former Member]

Thanks guys, points has been reward accordingly :). I'm still waiting for more input until I put this thread as "answered".

[Former Member]

It is dangerous to give SAP_ALL in any system. As there are many implementations that do not want to spend money on developing roles for the project team it is unfortunately very often that SAP_ALL and SAP_NEW are given on dev and mostly in sandpits.

But these systems stand in the same landscape as the PROD system so it is very dangerous to give that wide access.

The only way to bring a proper solution I have used has two options:

Give the users a specific role for their tasks (good/experienced functional consultants can give you a list of TRX they need access to)

secondly either give them access to the profile generator to let them quickly change their own access in DEV (in a separte role that can be taken away quickly as well)

Or be prepared to change their access yourselve immediatley when requested. Especially the reponse timing is important, if you help them ASAP you will keep them onboard

[jurjen_heeck]

>

> secondly either give them access to the profile generator to let them quickly change their own access in DEV (in a separte role that can be taken away quickly as well)
> Or be prepared to change their access yourselve immediatley when requested. Especially the reponse timing is important, if you help them ASAP you will keep them onboard

Response timing is the biggest threat to DEV security. As soon as you fail to solve your developers' authorization issues timely they'll use any workaround they know. Get your service levels in order and the developers will accept reasonable restrictions.