SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


No DBAs allowed access to Production DB Servers...


No DBAs allowed access to Production DB Servers...

Author
Message
Mike Dominick
Mike Dominick
SSC Veteran
SSC Veteran (265 reputation)SSC Veteran (265 reputation)SSC Veteran (265 reputation)SSC Veteran (265 reputation)SSC Veteran (265 reputation)SSC Veteran (265 reputation)SSC Veteran (265 reputation)SSC Veteran (265 reputation)

Group: General Forum Members
Points: 265 Visits: 33

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.

Thanks





Jeff Hachmann
Jeff Hachmann
SSC Veteran
SSC Veteran (264 reputation)SSC Veteran (264 reputation)SSC Veteran (264 reputation)SSC Veteran (264 reputation)SSC Veteran (264 reputation)SSC Veteran (264 reputation)SSC Veteran (264 reputation)SSC Veteran (264 reputation)

Group: General Forum Members
Points: 264 Visits: 1
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.



Dave Poole
Dave Poole
SSCoach
SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)

Group: General Forum Members
Points: 17358 Visits: 3403

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.



LinkedIn Profile
www.simple-talk.com
Dan Hare
Dan Hare
SSC Journeyman
SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)

Group: General Forum Members
Points: 84 Visits: 1

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
Penrhos
SSC Rookie
SSC Rookie (34 reputation)SSC Rookie (34 reputation)SSC Rookie (34 reputation)SSC Rookie (34 reputation)SSC Rookie (34 reputation)SSC Rookie (34 reputation)SSC Rookie (34 reputation)SSC Rookie (34 reputation)

Group: General Forum Members
Points: 34 Visits: 13

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
EdVassie
SSChampion
SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)

Group: General Forum Members
Points: 14873 Visits: 3905
Cool !!!

Original author: SQL Server FineBuild 1-click install and best practice configuration of SQL Server 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005. 14 Mar 2017: now over 40,000 downloads.Disclaimer: All information provided is a personal opinion that may not match reality.Quote: 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
stonemw
Valued Member
Valued Member (74 reputation)Valued Member (74 reputation)Valued Member (74 reputation)Valued Member (74 reputation)Valued Member (74 reputation)Valued Member (74 reputation)Valued Member (74 reputation)Valued Member (74 reputation)

Group: General Forum Members
Points: 74 Visits: 73
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
Mike Dominick
SSC Veteran
SSC Veteran (265 reputation)SSC Veteran (265 reputation)SSC Veteran (265 reputation)SSC Veteran (265 reputation)SSC Veteran (265 reputation)SSC Veteran (265 reputation)SSC Veteran (265 reputation)SSC Veteran (265 reputation)

Group: General Forum Members
Points: 265 Visits: 33

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
Dan Hare
SSC Journeyman
SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)

Group: General Forum Members
Points: 84 Visits: 1

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
Calvin Lawson
SSCrazy
SSCrazy (2.2K reputation)SSCrazy (2.2K reputation)SSCrazy (2.2K reputation)SSCrazy (2.2K reputation)SSCrazy (2.2K reputation)SSCrazy (2.2K reputation)SSCrazy (2.2K reputation)SSCrazy (2.2K reputation)

Group: General Forum Members
Points: 2160 Visits: 102

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.

cl



Signature is NULL
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search