No DBAs allowed access to Production DB Servers...

  • Mike Dominick

    Ten Centuries

    Points: 1043

    Our IT Director has come down and said that in order to meet compliance with Sarbox we will need to implement a new policy the removes DBA access from the production database servers. If we need access to any of the servers we will have to submit a request for a “key” and then a user id and password will be sent to us so that we can access the server.

    < ?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> 

    I do not believe this is true and have been unable to convince the director that this could be an unwise course of action. How are we to monitor and respond to issues if we need to request a “key” for everything from adding/modifying database users, re-running a backup job that failed, monitoring performance, etc. This is going to make doing my job, and the “keepers of key” a real burden. The other thing that scares me is that the only system administrator accounts will be SA, SQL service account and the key account.  All which 2 key keepers are responsible for managing the passwords and do not understand SQL Server. The fun part is that we are still responsible for the servers so when the gate keepers to say a service account password change and do it wrong, it will me who has to answer to the exec’s.


    Has anyone else experienced this situation? How has it worked out?


    I believe the director does not realize that the DBA’s role is more a specialized system administrator job. In our company it’s I am move of a hybrid DBA since I do both the Admin side and work as one of the developers. Any thoughts of how to explain this to the director?


    Does anyone have any compelling arguments why this new approach is a bad/good idea.



  • Jeff Hachmann


    Points: 438

    It sounds like your IT Director or Auditors are mis-interpreting this.  As for your question, it's a horrible idea.  How do they expect a DBA to do the job if you don't have access to the machine.  It's not a position I'd want to be in.

  • David.Poole

    SSC Guru

    Points: 75379

    Has Scott Adams drawn a picture of your IT director by any chance?

    I was told by an old sergeant that when officers gives a stupid order you follow that order to the letter, but not the spirit.  You carry it out in the most literal, bloody minded way that makes it appear even more stupid than it already is.

    If the officer doesn't take the hint then their superiors will. 

  • Dan Hare


    Points: 434

    i had a similar situation once when we got involved with german auditors.  basically, tech ppl had to hands off the production server.  it is unworkable in my opinion.

    we insisted that the director who raised it be the password holder for the initial phase, then sent the occasional out of hours request to him (nothing too obvious).

    he then delegated after a week or so, we did the same to his number 2 including a little bit of weekend maintenance (and o/t ), then lo and behold we were the password holders.

    from a cya stance, if you are going to be updating data it is actually helpful to have a procedure so someone oversees it and rubberstamps the change.

  • Penrhos

    SSC Journeyman

    Points: 88

    Been there, done that, picked up the pieces and now have domain and sql passwords....

    We had the same here but they also enforced aged passwords for the domain account that SQL was running under. Funny that when the passwords were changed during month-end and the whole system stopped working and the DBA turned round and said to the Financials Director that nothing could be done as we didn't have any rights - The policy was changed.

  • EdVassie

    SSC Guru

    Points: 60274

    Cool !!!

    Original author: 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.

    When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara

  • stonemw

    SSC Enthusiast

    Points: 184

    I think the higher ups are way off base.  We just completed our S-O audit and we basically have to have an audit of who logged in and documentation of any changes to the databases of any of our financially significant applications.  The auditors realize that the DBA still must be able to do their job.  I would suggest that they have a sit down with the auditors because they are way off base.

  • Mike Dominick

    Ten Centuries

    Points: 1043

    We had a sit down yesterday with the auditor, and boy was it fun

    His stance is that if we specify the person is only a DBA and does no development he can have the access. But if the DBA is also a developer then he can't have access, regaurdless of any auditing or paper trail.  The rational is that developers understand the system to well and know how to go in an manipulate the data. I find it funny that they are this worried about the programmers but yet the person down the hall can request, approve, and sign checks. 

    Even the director turned to our side when the auditor said the "key" idea doesn't doesn't fully meet the requirements and that the only way to fully satisfy the requirments is to make one of us a dedicated DBA or hire one.


  • Dan Hare


    Points: 434

    funny how bean counters change their tune when they hear the magic word 'recruitment'.

    i love the idea of having someone administer an entire complex system who doesnt understand it in depth. you sometimes wonder what planet auditors are on...

  • Calvin Lawson


    Points: 11030

    Not only that, but if the DBA actually DOES learn the system well, is he then not allowed to be DBA anymore? 

    That sort of thinking is screwed, and not standard at all.  I don't know how the auditing company is coming up with these things; I'd guess it has more to do with mis-understanding/mis-representing a valid security concept than with pure stupidity.  But one never knows, I guess.

    Keep us posted, man.


    Signature is NULL

  • marris


    Points: 469

    You should have control and review process in place rather than imposing a blanket ban. You can your director that all logins with sysadmin prvilege will be audited, DBA logins will be added only after approval from a Manager, Audit activities need to be reviewed, DBA's cannot add/modify logins. In other words, securityadmin should be separated by sysadmin. All the best!

  • David.Poole

    SSC Guru

    Points: 75379

    Really, this is a case of the road to hell being paved with good intentions.  You can see the spirit of what the IT Director wanted to do its just that the letter of what he wanted was a right pigs ear!

    I've had a similar instance where we were told to comply with the Data Protection Act (UK) in terms of not retaining data without permission or once its use by date has expired.

    The problem was it was insisted that if that data existed on a backup tape then we would be in breach of the act.  So, run a destructive process on data without a backup..hey wow what a good idea!!!!

  • Slavek Rotkiewicz


    Points: 24

    Half-and-half solution

    1) Only DBA can change data structures, stored procs etc....

    2) Only users can access database via production GUI ( DBA is prevented from

    this via encrypted password that user creates )

    3) Even that DBA has access to every object in DB could not enter a finacial

    transaction without a complete understanding of the schema.

    ( This is for an accounting solution )

  • Madhav Vedula

    SSC Rookie

    Points: 37

    Interesting topic:

    Well I have seen enough bashing of Auditors. I am an IT auditor and yes CISA too working on Sarbanes

    Recently we are auditing a client who is running Solomon on SQL Server and other Oracle Database applications.

    I am working with one of the top risk consulting companies. Our intrepretation of the Sarbanes Oxley act is for IT  - in addition to all other Controls, Segregation of Duties is a key control. That control requires Development and DBA functions be carried out by 2 seperate individuals.

    I am not sure if Keykeeper idea is a good one. However, from complaince perspective, Database Developers cannot access the production environment. The same applies to SDLC- developers cannot QA and certify their own work.

    That is how Sox compliance mandates and we auditors intrepret - The remediation is upto each client and How each company is going ot handle is open.

    Madhav Vedula CISA

    Sr.Internal Auditor





  • stonemw

    SSC Enthusiast

    Points: 184

    This is what happens when people who are clueless make laws.  Many shops have developer and DBA as one in the same.  Why should smaller shops be required to hire a DBA and a developer especially if they can not afford both nor need both.  What SOX is doing is having accountants dictate the way IT does business.  Now you have those responsible for the making of SOX telling us how to do our job.  There are already those in Washington who realize that this law is way off base and are trying to change and/or repeal it. 

Viewing 15 posts - 1 through 15 (of 63 total)

You must be logged in to reply to this topic. Login to reply