Security Change Management

[Former Member]

Hello security gurus I need your help.

SYSTEMS:

CRM 2007

BI 2007

Solution Manager 7

EP 6.0

I am planning on creating a group called SAP System Users in which I will assign all users with user type:

System

Service

Communication

This is to exclude this group when our CRMD_UI_ROLE_ASSIGN job runs. We have had problems with these users finding their way into the Org Model. When the job runs it removes their current roles/profiles and wreaks havoc.

My question is this:

Do we or should we follow a change manamgent process for creating this group and assigning these users to it? My company have very little in the way of defined policies and procedures. To me this is simple user admin and doesn't require a change request.

Can someone please advise if this is necassary? My company is now talking about requiring a change request for creating any users which I feel is ridiculous.

Thanks!

Todd

[Former Member]

I changed the order of the questions a bit

> My company is now talking about requiring a change request for creating any users which I feel is ridiculous.

I don't think that user management in general should be subject to (system) change controls.

> Do we or should we follow a change manamgent process for creating this group and assigning these users to it?

SAP's forsight does not offer a direct transport option, so from that you can perhaps conclude that it is not subject to change controls of the TMS.

Perhaps designed it in such a way that the groups should be setup system specifically, and then locked down, but without a requirement for the system (change) pipeline to be in sync.

But there are some arguments for cases where you might want to consider it (e.g. USR41 entries, PRGN_CUST settings, available user groups... etc.. where these can be considered "customizing" although there might not be a transport request - nor easy possibility).

> I am planning on creating a group called SAP System Users in which I will assign all users with user type:

> System

> Service

> Communication

I don't think there is anything specifically wrong in this case, although one should ideally set this up during the project phase ("right first time"...) and then protect changes to it. These generic technical user types are typically associated with programmed interfaces, jobs, services, etc and those (programs) would normally be subject to change controls.

So once you have secured them in a user group for non-human user ID's and secured the administrator access to them, and their tailored roles to run those jobs, interfaces, services, etc... then you would probably not want anyone to just change them or their roles at will or by accident... in the same way as you would not want someone to at will or by accident change a complex batch job in production, or a variant used by a program in such a job, or reset their password, or change or use their dedicated roles, or change a program in production.

My recommendation: Make it subject to change controls and secure it, but include an short emergency access procedure to administrate the users (in that user group) when something does happen. It is advisable that folks with such (emergency) access are very well trained, as it might look like a user (admin) problem, but actually be a faulty customizing config, badly programmed exits, master data inconsistencies, probing... That way people very familiar with the user ID's and what they are actually used for have some flexibility which they are trained to support, but others do not.

> Can someone please advise if this is necassary?

If your system is setup well, you should not have a problem with this IMO if the folks who make the changes and those who approve them know their stuff.

Hopefully it should not happen on a day-to-day basis (outside of patching, upgrades, adding new functionality, mergers, roll-in's, roll-out's, normal project stuff, surprise projects, audits, etc etc....:-)

Cheers,

Julius

[Former Member]

Thank you Julius for the great advise. I started here about 8 months into the implementation as the only internal SAP Security person. The lack of anyone on the company side has led to many things including policies, procedures and configurations not being completed. This has caused us a great deal of problems and headaches.

Todd

[Former Member]

I think many eaasily implementable security blunders can be traced back to this...

> The lack of anyone on the company side has led to many things including policies, procedures and configurations not being completed. This has caused us a great deal of problems and headaches.

If you don't define standards, rules and naming conventions (and change controls) from the start, then short-cuts will be taken.

You can control a lot of things via the authorization concept (not just locking the client down), which can make your life and support easier and system more secure.

If you restrict your support team's access carefully then they will see the sense in it and have a better understanding of how the whole system (landscape) works. Forget about t-codes to a large extent.

Give them display access to SU21 to display object S_USER_GRP documentation etc. That way, when they stumble over programs, they will understand them (and some of the wizards and how to protect access to them.

I also moderate the ABAP forums here at SDN. I am sure many of the contributors work with SAP_ALL because they miss so much.....

Cheers,

Julius