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 123»»»

Should DBAs Be the Protectors of Data? Expand / Collapse
Author
Message
Posted Saturday, July 3, 2010 10:56 AM


SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Thursday, October 16, 2014 10:06 AM
Points: 176, Visits: 728
Comments posted to this topic are about the item Should DBAs Be the Protectors of Data?

Brad M. McGehee
DBA
Post #947221
Posted Saturday, July 3, 2010 11:22 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 6:45 AM
Points: 35,366, Visits: 31,902
I agree with your mentor. So far as I'm concerned, a DBA's only job is to protect the data. Anything and everything else a DBA does is in support of that single job.

--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #947233
Posted Saturday, July 3, 2010 11:33 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 6:53 PM
Points: 31,177, Visits: 15,623
You absolutely have to protect the data, which means many things.

However I'm not sure you need to move it all into SQL Server databases. What you should do is help the person who uses it determine how to protect it and ensure it is useable. That might be making sure copies are on network shares through an automated process, or a copy to a db using OPENROWSET.

As you protect data, you can't also make it unavailable or interrupt business processes.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #947242
Posted Saturday, July 3, 2010 11:47 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, August 13, 2013 12:38 PM
Points: 6, Visits: 65
I can understand the impetus and I agree that it is a process that should be applied, however with moderation. Not all data in the organization should be classified as mission critical. Some of these less structured efforts and data stores are outgrowths of staff and departments finding ways of architecting better, simpler supporting processes. This is actually an indicator that the established systems do not meet all the needs, access to the database platform is not distributed, and additional training is needed at the department levels.

The DBA would need to share db space, architecture and time to train many other non-DBA's. Locking down, improving data quality, ensuring data accessibility and securing are worthwhile goals but not at the expense of stifling and slowing responsiveness. Bottlenecks will be formed one way or the other and we should be mindful of the kind of bottleneck we are, sponsoring, etc.

All applications and reports that are relied upon daily by key stakeholders should be targeted for 'protection'. Those applications and reports that are used by more than two departments are clearly important and should be included in the 'protection' net. Additionally any non daily applications that are relied upon by a large number of users should also be targeted for 'protection'. Most of the Homegrown applications require time to mature and can be ignored until they too are used by either key stakeholders or large number of users.

'Protection' in my view should be measured, used as an indicator for more training, inclusion of other parties but not as a means of controlling development of prototypes and 'glue' integration solutions. Instead use the discovery of these innovations as the opportunity to ask why it was needed and how can that be addressed?
Post #947246
Posted Saturday, July 3, 2010 11:57 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 6:45 AM
Points: 35,366, Visits: 31,902
Heh... I do find it amazing that certain types of data are considered to be NOT mission critical... that is, until it's lost.

--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #947248
Posted Saturday, July 3, 2010 12:27 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, August 13, 2013 12:38 PM
Points: 6, Visits: 65
Jeff:

thus systems have to have 100% uptime, people can't get sick or go on vacation, and nothing fills the round file. yet the world keeps spinning, and todays frenzy is forgotten by next week.
Post #947256
Posted Saturday, July 3, 2010 1:46 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 6:45 AM
Points: 35,366, Visits: 31,902
Sean Josiah-454849 (7/3/2010)
Jeff:

thus systems have to have 100% uptime, people can't get sick or go on vacation, and nothing fills the round file. yet the world keeps spinning, and todays frenzy is forgotten by next week.


I can't tell... are you bragging or complaining?


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #947259
Posted Saturday, July 3, 2010 1:57 PM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Saturday, October 11, 2014 8:18 PM
Points: 831, Visits: 1,588
So (sorry for sounding dumb) how do you handle situations where the data has a significant level of sensitivity and you want the DBA to manage it, but not read it, and certainly never change it? Is this where encrypting columns etc comes into it? Would it be fair to say that this falls into the "Too Hard" basket a lot of the time, and the CEO, through ignorance of the technology, basically ends up placing more faith in the DBA's goodwill than is necessary or desirable? How many CEOs would really know what their DBAs have access to?



One of the symptoms of an approaching nervous breakdown is the belief that one's work is terribly important.
Bertrand Russell
Post #947262
Posted Sunday, July 4, 2010 3:31 PM


SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Thursday, September 11, 2014 9:42 AM
Points: 118, Visits: 312
Great article Brad.

______________________________________
Dilbert: What color do you want the database?
Post #947339
Posted Sunday, July 4, 2010 4:39 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 10:00 PM
Points: 7,105, Visits: 15,443
GPO (7/3/2010)
So (sorry for sounding dumb) how do you handle situations where the data has a significant level of sensitivity and you want the DBA to manage it, but not read it, and certainly never change it? Is this where encrypting columns etc comes into it? Would it be fair to say that this falls into the "Too Hard" basket a lot of the time, and the CEO, through ignorance of the technology, basically ends up placing more faith in the DBA's goodwill than is necessary or desirable? How many CEOs would really know what their DBAs have access to?


It's an interesting question, but it's ultimately a "damned if you do and damned if you don't" kind of scenario. If you were to devise a scenario allowing you to store data so that NOONE else can get to it, then you and you alone would be responsible for that data, which would put the company at a severe disadvantage if you to leave/be fired/step in front of the proverbial bus etc.... All of those aspects surrounding safeguarding the data (access/encryption/backups, auditing) would then need to fall on the end-user rather than any centralized role.

Someone ultimately needs to be able to retrieve your info in any of those scenarios or have access to the keys that unlock the access to said data (encryption keys, etc....), so someone has to be trusted with it. While at that point it might be desirable to break that up among several people, once you're at that point, it's really more a matter of knowing WHO has the access. It's funny - in many industries having someone in that role would actually be required, since pretty much anyone falling under Sarbanes/Oxley would need to functionally be able to retrieve sensitive data to turn over for review.

I'd say it's actually a little safer to presume that anyone in those few positions (DBA, domain admins, storage admins, etc...) will by nature have access to sensitive data, and should be trained and hired with these concerns in mind. This then kind of ties back into Brad's initial question: DBA's (and others) then become guardians of the data for the corporation.



----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Post #947352
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse