Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12345»»»

No DBAs allowed access to Production DB Servers... Expand / Collapse
Author
Message
Posted Wednesday, May 19, 2004 7:35 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, July 12, 2012 6:43 PM
Points: 175, Visits: 32

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




Post #116604
Posted Wednesday, May 19, 2004 9:46 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Friday, June 22, 2007 8:25 AM
Points: 216, 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.


Post #116642
Posted Thursday, May 20, 2004 1:42 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 12:02 PM
Points: 2,892, Visits: 1,785

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
Newbie on www.simple-talk.com
Post #116774
Posted Thursday, May 20, 2004 2:04 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, December 13, 2005 9:34 AM
Points: 10, 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.

Post #116779
Posted Thursday, May 20, 2004 2:50 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, May 17, 2011 2:25 AM
Points: 16, 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.




Post #116787
Posted Thursday, May 20, 2004 3:25 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 10:28 AM
Points: 2,859, Visits: 3,188
Cool !!!

Original author: SQL Server FineBuild 1-click install and best practice configuration of SQL Server 2014, 2012, 2008 R2, 2008 and 2005. 28 July 2014: now over 30,000 downloads.
Disclaimer: All information provided is a personal opinion that may not match reality.
Concept: "Pizza Apartheid" - the discrimination that separates those who earn enough in one day to buy a pizza if they want one, from those who can not.
Post #116792
Posted Thursday, May 20, 2004 6:12 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, August 9, 2010 5:25 PM
Points: 58, 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.


Post #116819
Posted Thursday, May 20, 2004 7:17 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, July 12, 2012 6:43 PM
Points: 175, Visits: 32

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.

 




Post #116840
Posted Thursday, May 20, 2004 8:29 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, December 13, 2005 9:34 AM
Points: 10, 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...

Post #116871
Posted Thursday, May 20, 2004 3:12 PM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Tuesday, June 21, 2011 10:03 AM
Points: 577, 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
Post #116939
« Prev Topic | Next Topic »

Add to briefcase 12345»»»

Permissions Expand / Collapse