July 3, 2010 at 10:56 am
Comments posted to this topic are about the item Should DBAs Be the Protectors of Data?
Brad M. McGehee
DBA
July 3, 2010 at 11:22 am
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
Change is inevitable... Change for the better is not.
July 3, 2010 at 11:33 am
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.
July 3, 2010 at 11:47 am
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?
July 3, 2010 at 11:57 am
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
Change is inevitable... Change for the better is not.
July 3, 2010 at 12:27 pm
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.
July 3, 2010 at 1:46 pm
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
Change is inevitable... Change for the better is not.
July 3, 2010 at 1:57 pm
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 ones work is terribly important.... Bertrand Russell
July 4, 2010 at 3:31 pm
Great article Brad.
______________________________________
Dilbert: What color do you want the database?
July 4, 2010 at 4:39 pm
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?
July 4, 2010 at 5:15 pm
You have to trust your administrators. You can contract with them, bond them, have them liable for things, but ultimately you must trust them
July 5, 2010 at 4:13 am
It's commendable for anybody to be pro active, but I don't think it is the DBA's responsibility. I thought that was why organisations employed Data Managers and CIOs.
July 5, 2010 at 7:15 am
paul s-306273 (7/5/2010)
It's commendable for anybody to be pro active, but I don't think it is the DBA's responsibility. I thought that was why organisations employed Data Managers and CIOs.
It obviously depends on the size and structure of the organization. But knowing human nature, if something goes seriously wrong, isn't it a bit naive not to assume that the the person whose head will roll is the DBA, because (a) they is the person at the operational coalface and hence best placed to protect the data (whether they were explicitly given responsibility for a given DB or not); and (b) because they will be lower in the pecking order than the CIO or data manager?
I think Brad is correct. Looking for critical data to protect is good practice. You could call it due diligence.
Mark Dalley
July 5, 2010 at 10:13 am
I think a DBA reacting to situations like this they encounter is fine. If you learn of critical data being stored in an unsafe way, by all means speak your mind.
But these days with so much information to be kept, and the ubiquity of excel and access, I think this needs to be managed more proactively and I'm not sure that the DBA should be the person to do that.
I think when it comes to going out and finding this type of thing, that is both just easier and a more natural role for an IT manager/CIO to be doing.
July 5, 2010 at 12:15 pm
Your organization is lucky to have someone like him. But moving the data is the easy part... you'll have to coordinate with app dev to get their gui converted over to use the new datasource. Which is much more political and difficult to do. Usually cannot happen unless the guy/gal has some pull in the company.
Viewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply