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.
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.
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.
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.
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.
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.
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...
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.