Should DBAs Be the Protectors of Data?

  • Comments posted to this topic are about the item Should DBAs Be the Protectors of Data?

    Brad M. McGehee
    DBA

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

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

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

  • 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?

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

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

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

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

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • 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

  • Great article Brad.

    ______________________________________
    Dilbert: What color do you want the database?

  • 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?

  • You have to trust your administrators. You can contract with them, bond them, have them liable for things, but ultimately you must trust them

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

  • 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

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

  • 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