User making direct changes to PRD system

[Former Member]

My enviroment is ERP 6 ABAP /Oracle 10G/Solaris 10

Some of my superusers are fond of making direct changes to PRD (as opposed to DEV & then transport via the landscape) though changes in PRD system have been restricted through client change options SCC4 & system change option SE06

I suspect the said users have ROLE with powerful authorizations that they ought not to have.

Kindy advice what I should look for the users roles or how I can go about to harden PRD system aganist direct changes

Thanks

Edited by: Andale J on Sep 29, 2010 12:10 PM

[tim_alsop]

I posted in wrong thread - so removed my comment

Edited by: Tim Alsop on Sep 29, 2010 10:15 AM

[Former Member]

Hi Andale,

You can provide only display access for DEBUGGING to the users. You can restrict the ACTVT : 03 for Object : S_DEVELOP ; OBJTYPE: DEBUG.

Hope this answers your question.

Regards,

Dipesh

[Former Member]

hi andale,

please note that once you select 'no changes allowed' option in SCC4 then system will not allow any user to make the changes to both client-specific and cross-client functionality. any action to change will result in a message saying client is locked.

so the 'superusers' in your case are accessing 'SCC4' and changing the options i presume.the first thing u should do is to escalate this within your department or u should probably lock the transaction 'SCC4' using 'sm01'.

regards,

[Former Member]

As a best practice always work with Security Matrix designed at the time of Implemenation :

Just keep this below points:

1) Create Roles / Authorizations only with specific job function / job roles (PP,MM,SD,FI,CO,PM,PS etc)

2) Study about the Job function User level (on Organization level) and assigned only roles / authorization ex Purchase dept - MM roles, Production dept - PP roles , Finance dept - FI roles It may be possible that a user may be responsible to run cross function modules (MM,SD,PS,FI)

3) Before finalizing the roles always check for BC* object responsible for BASIS activites and deactivate it

4) As a best practice for handling critical / authorizations create seperate role like - Transports,Table / program access only display this can help you to handle this cetrall rather than going each roles

Regards;

[Former Member]

Hi BAIGSA

Creation of roles is down to the security policy already in place unless you are lucky enough to be in at the beginning and can define how all roles are to be built in future.

Mostly, you arrive at a client's site and have to adapt to their authorisation concept.

You may find that function (module based) roles are inplace or that job roles (either multiple singles assigned directly or via composites or a one role does all) has been set up.

Remediation of module based roles can be a really pain if they were built with too many transactions included - user group/job roles are far easier to remediate but this depends on the policies in place - inactive objects etc)

I haven't enough information to understand what the changes are that have been made in prod to help - you need to review those changes and formulate a strategy which the business agrees to to resolve.

Kind regards

David

Edited by: David Berry on Oct 3, 2010 8:30 PM

[Former Member]

Hi Dave,

I think documenting & updation of matrix (module based or any roles) with new authorization or changes at org level help to remember and planned like on those tricky part where we have to decide to add missing or additional authorization to the role with specific to user only or based on job function this will also help to stick on the companys approved matrix policy rather than creating new roles with new matrix.

It's difficult for sometime to understand the existing env. of any company untill we study it from begining so if we have above documentation ready (matrix - role,values,org values,user mapping etc.,) so it will definelty help to undersand quickly with update information and continue to work without choosing other way this help to stick on companys policy & making our audit more transparent.

Regards;