Implementation Super Admin Rights. 1888



  • Hi,%0AThis is my first query in this group. Currently, for going live for a client, we need to have a SuperAdmin (our end; who has 100% access to the client’s system) as a part of the Client’s Organization.%0AThis means that we create an Organization and a SuperAdmin, assign the SuperAdmin to the Organization and then login and do other stuff. My question is; is this per compliance guidelines?%0AThanks.



  • a suggestion would be to log the Super Admin id, as the first step of the go-live, and subsequently review( or weekly review) the activities performed by the Admin ID. This can give some control…



  • Hi and welcome to the forums 🙂
    As a starting point, ADMIN accounts are something that can’t be realistically stopped as folks need to respond to emergency conditions via dial-in (24x7 coverage) or to manage remote sites. You need the best level of controls, accountability, and safeguards when implementing ADMIN accounts.
    NC offers great advice on logging ADMIN account activity. Below are a few more ideas:

    1. You might find some ideas here and the 1st site has a great related article:
      Please add www and paste to browser
      google.com/search?hl=en-and-q=SOX administrator account controls
    2. Use best related security practices, including: strong passwords, periodic password rotations, and effective logging (what I’m saying here is to log the most sensitive security events, otherwise you can have ‘too much data’ and it’s meaningless)
    3. If it’s not too expensive and can be done, I like 2-factor authentication.
    4. It’s always good to touch base with audit (Internal or external SOX auditors for their recommendations)
    5. As COBIT standards (4.0 preferably) are used as SOX compliancy benchmarks, you might search here and the Internet on related links and possible controls.


  • Review should be performed by client management and not by someone on your side.
    Some more suggestions:
    The use of ID should be uniquely traced to an individual or person. for ex if its root account then let user use SU to switch. User list in this case should match with individuals authorized by the client.
    If you need the ID for just few things then u can create the ID and lock the account. Open it with approval from the client management and lock it after the activity. If its needs to be used extensively then you can’t do this.
    Set an expiry on the account for the day the migration is supposed to complete. After that you need approval from the client to open it again.
    It doesn’t voilates the compliance unless you have understood the risk and put controls to prevent it.
    Calvin


Log in to reply