6 Replies Latest reply: Oct 4, 2010 10:08 AM by Baig Mirza RSS

User making direct changes to PRD system

Msoro Msororaji
Currently Being Moderated

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

  • Re: User making direct changes to PRD system
    Tim Alsop
    Currently Being Moderated

    I posted in wrong thread - so removed my comment

     

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

  • Re: User making direct changes to PRD system
    Dipesh Dutta
    Currently Being Moderated

    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

  • Re: User making direct changes to PRD system
    Nathan Cole
    Currently Being Moderated

    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,

  • Re: User making direct changes to PRD system
    Baig Mirza
    Currently Being Moderated

    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;

    • Re: User making direct changes to PRD system
      David Berry
      Currently Being Moderated

      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

      • Re: User making direct changes to PRD system
        Baig Mirza
        Currently Being Moderated

        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;

Actions