System Configurator Role

[Former Member]

Hello All,

I am in creating security on my SCM sandbox, I manged to create a role for System configurators and Ba's( which do not have most of the Basis auth. and critical HR auth.). I tailored this role from SAP_ALL, however some of the basis auth. still working.

I wonder how other companies or Sec. Admins deal this issue. how you guys create role which have no system authorization on brand new system (keeping in mind that the config. guys should have most of the access except critical sys. auth.)..

One work around is " to check what auth. objects these system tcodes are using and then disable it, I found about 50 objects, I think if I disable all these auth. obj's than I may face issues with tcodes which share these objects"-----I feel this method have lot of flaws.

On the other side, if I give ranges I am successful in restricting few system tcodes and not all...

Any thoughts guys/gurus of Security...!

Thanks All...!

[Former Member]

there's no out-of-the box answer to your issue. i think every sec-admin has her/his own ways of doing it.

i personally do it in mostly the same way as you: i create a role, put all the sap_* profiles in it and then i start 'hacking things off'.

from long years of experience i 'know' what objects have to stay put in order to grant your consultants access to everything they need without them snooping around in SM59 and accessing other systems. but this is experience and there's no rule to it.

a tipp may be: do create two roles for them, one with basis access and one with functional things, the reason being: at least the basis-role you can transport around to new systems (even those of other functions such as BI, APO ...) without having to adapt them much since the core-basis is mostly the same ... every now and then i will look for new objects and add/adjust them.

much more difficult with the functional part, granted. you would have to learn about the objects that are particular to the application and that's much work if you do it for the first time. i haven't found any better way though ... i still use the most powerful profiles for my roles and have fun for a whole day with inactivating suspect objects ...

i test those roles on the latest external consultant to have arrived in the company - they tend to tell you what they need instead of running to your superiors complaining about your restrictions

[Former Member]

Hi Mylene,

Thanks alot for your suggestion, it made my confidence boosted up. I was on the same page as you are...however I will try to implement your tip..lets see if it works for me....Thanks Again..

[Former Member]

Hi Anil,

I take a different approach to Mylene and believe that it is difficult decent control over what funkies do if you start with SAP_ALL

Get them to ID which transactions and functions they need and start to build roles from there based on what your setup is like. If they say they need everything except basis then ask them to list 10% of the 10000+ tx there are in the system. They won't be able to. It may be that team leaders can create transports and team members can add tasks to existing transports

Your roles will take a while to develop but will be more secure than working with ranges (would be OK if there weren't a fair number of duplicate transactions - check out OY21 & OY22 and tell me if they look familiar) and removing a few auth objects (which are easily hobbled by debug access).

There are lots of ways of doing things and each approach has it's merits. This one is more pain to start with but in my opinion will give better security and you can adapt the roles more easily to create versions for use in prod.

[Former Member]

Of course, you can also differentiate between the role of a funkie in PROD, QAS and DEV.

You also do not need to transport the DEV funkie role to PROD if there is no documented reason for it to be there...

They are special in the sence that QAS (or a virtual machine) access to the application objects is usefull when the business users are too dizzy to even try solve a problem.

Regarding SM59, you can in higher releases use the group concept to protect certain destinations with specified activity settings. A funkie might be responsible to testing some connections, but should not be able to put their own UID/PW into it... which might trigger some postings 300 days later (again)...

Cheers,

Julius

[Former Member]

>

> If they say they need everything except basis then ask them to list 10% of the 10000+ tx there are in the system.

that would be 84756 in our system (z-ones included). while i agree with your way of doing things, i can't go that way. there's no time to develop roles for every funkie in her/his own application - my boss won't tolerate any delay when 15 sap-employees are queueing up at the front door and start costing money ... and i'm much faster starting with S_TCODE * and then proceed as i described above.

and believe me, alex, them sap-pers know their transactions ...

[Former Member]

>

> >

> > If they say they need everything except basis then ask them to list 10% of the 10000+ tx there are in the system.

>

> that would be 84756 in our system (z-ones included). while i agree with your way of doing things, i can't go that way. there's no time to develop roles for every funkie in her/his own application - my boss won't tolerate any delay when 15 sap-employees are queueing up at the front door and start costing money ... and i'm much faster starting with S_TCODE * and then proceed as i described above.

>

> and believe me, alex, them sap-pers know their transactions ...

Hi Mylene,

S_TCODE = * is effectively removing one layer of security (transaction start) and you are relying on an authorisation mechanism which in all but a few cases (HR for example) is easily bypassed, constituting a potentially serious lack of control to save a few hours here and there. Ultimately your boss is making a call over the (relatively low) cost of developing secure roles and the percieved risk of giving what amounts to far wider access.

I know that those sap-pers know their tx, but someone who can list 2000 or 8000 of them? without starting counting S_ALR_8nnnnnn I doubt they will know (or more importantly use) that many

Cheers

Alex

[Former Member]

what kind of security-layer is the use of t-codes with a consultant who is granted SE38, SE19, SE37 ... ?

in and end-user, o. k. but in a funkie who can destroy your database by using the wrong EXEC SQL statement in an abap?

[Former Member]

>

> what kind of security-layer is the use of t-codes with a consultant who is granted SE38, SE19, SE37 ... ?

>

> in and end-user, o. k. but in a funkie who can destroy your database by using the wrong EXEC SQL statement in an abap?

Hi Mylene

S_TCODE check is a kernel check and requires more effort to work around. That moves being careless or stupid (such as rubbish code) into the realms of being willful. From a risk management perspective that is a big difference. In an environment with implementation partners, contractors, outsourced support etc then it is important to make this differentiation. The access that we give devs and funkies is but one method of control.

Just because a funkie or dev has the facility to cause damage in one way, doesn't mean that we relinquish control over other areas which are relatively easy to restrict and in my opinion add an extra layer of control. Reducing ways in which someone can screw up your system is never a bad thing. Look back a few years ago and it was generally accepted that Basis would have SAP_ALL in prod. Fortunately opinion (apart from that of basis admins) is changing.

We all have ways of doing things and do them for our own reasons. I've seen enough devs or funkies abuse roles solely based on auth object restrictions that for me this method doesn't provide the control I require.

[Former Member]

Hey Folks,

It was a pretty good ideas flowing on, I have a good take aways from the discussion..I still have to look into OY21 & OY22.

thanks guys for posting your thoughts..!

[Former Member]

Hi Anil,

there are always loads of ways of doing things. Do what you are most comfortable with (time, understanding of auth concept & auth objects) etc as you have to support it!

OY21/2 were only indications to show that you can play with t-code ranges but there are often other tcodes which do the same. Restricting at auth level will control stuff like user admin, but also loads of different basis functions share common authorisations.