Skip to Content
avatar image
Former Member

User making direct changes to PRD system

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

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

4 Answers

  • Best Answer
    avatar image
    Former Member
    Sep 30, 2010 at 09:08 AM

    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;

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member 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;

  • Sep 29, 2010 at 09:14 AM

    I posted in wrong thread - so removed my comment

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

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Sep 29, 2010 at 09:33 AM

    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

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Sep 29, 2010 at 11:43 AM

    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,

    Add comment
    10|10000 characters needed characters exceeded