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
Edited by: Andale J on Sep 29, 2010 12:10 PM
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'.
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
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.
Edited by: David Berry on Oct 3, 2010 8:30 PM
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.