Voice of the DBA

Tag: security

  • Data Freedom and Regulation

    HIPAA creates a floor, not a ceiling.
    HIPAA creates a floor, not a ceiling.

    The HIPAA laws passed in the US to provide for better privacy an security of medical information seem to be a joke in many of the situations in which I’ve dealt with medical providers. It almost seems like signing a HIPAA acknowledgment form is a formality and as patients, we should understand that HIPAA provides for standard requirements and protections for our data. However I’m not sure that’s the case.

    This article talks about the HIPAA laws being a floor, not a ceiling, and a patchwork of laws in various states superceed what HIPAA requires. However in doing so, they create inconsistent regulations and rules that people struggle to understand, and with which technology cannot keep up. I’d take issue with the comment that “Digital systems to move information need simplicity”. It’s not true. Our digital systems are very adept at handling exceptions and variable routing and security when they are programmed to do so. The problem is ensuring the people writing the code understand all of the rules for the exceptions.

    The article talks about the approach Hawaii has taken, in scrapping older laws and simplifying them to comply and expand the HIPAA requirements so that providers and patients can understand how to handle data. I suspect that few governments will take this approach, but it’s precisely what’s needed, in all fields, for those of us working with data to build systems that can not only comply with the laws, but also protect data in a secure manner.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Granting Permission to Grant Permissions

    I’ve never felt the need to allow this, but I saw someone ask the questions recently. Suppose you had a view and you wanted to allow a user to grant permissions to this view to other users.

    It’s not a weird edge case, but it’s just not one I’ve normally bothered with. I manage by groups, always, and never want a user to be granting permissions to a specific view. I inherently see users as fragile in the lifetime of an application (administrators as well)  and don’t like the idea of allowing them permissions.

    If you need to do this, however, there is a way. Let’s examine a basic scenario. I want to allow Bill to grant permissions on the view “MonthlySales”, which I’ve created in AdventureWorks. If I want to allow Bill to use this view, I need to do this:

    GRANT SELECT ON MonthlySales TO Bill

    If I log into the server as Bill and execute 

    SELECT * FROM MonthlySales

    I get this:

    grant1

    Simple stuff.

    However if I want Bill to be able to allow other people in his department to see this view, what can I do?

    If I examine the BOL page for GRANT, I see there is an option that can help here. The WITH GRANT option allows the person specified in the statement to grant the existing permissions to others.

    Let’s assume I have another user Sue. If I log in as Sue, and I execute the same SELECT that Bill ran above, I get this:

    Msg 229, Level 14, State 5, Line 1

    The SELECT permission was denied on the object ‘MONTHLYSALES’, database ‘AdventureWorks’, schema ‘dbo’.

    I could easily manage permissions as the DBA, and I prefer this, but for when you have some data that a user can manage, and you are in an environment where things change quickly, perhaps you want to delegate some permissions to users.

    Now, let’s change the initial permission I set up for Bill to this:

    GRANT SELECT ON MonthlySales TO Bill
 WITH GRANT OPTION

    Bill can still see the view and the data. However Bill can now run this:

    GRANT SELECT ON MonthlySales TO Sue

    Once he does this, Sue can see the view.

  • Encryption Not Restriction

    Encryption will be more important in cloud computing
    Encryption will be more important in cloud computing

    I believe in encryption. I have an encryption talk that delivers the very basics of what encryption options exist in SQL Server, and I would think that most data professionals that develop or manage databases should understand encryption and how to enable it. I find lots of people don’t understand, and I’m glad that I can try to teach them a few things about when encryption is and how it works in SQL Server.

    Cloud computing use is growing, and while we don’t have a good definition for what a cloud computing means, more and more organizations are considering looking at moving some of their applications, and data, to the cloud. As we move this data, many DBAs have concerns over the security of the data they are supposed to protect. These are valid concerns, and they should be at the forefront of your mind if you plan on moving anything to any type of service provider.

    One interesting point brought up in this op-ed is that customers ought to have their data encrypted, but the keys used for the encryption should be controlled by the customer, not the service provider. That’s sound business strategy, and it should be the case with all your data, not just data sent to the cloud. If you use a service to rotate and store your tape backups, you ought to have encryption on those tapes, with keys managed by your company. Just as you ought to have the keys inside your company if you use locks on the shipping containers holding the tapes.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Serious Security

    I almost long for days when security was this simple.
    I almost long for days when security was this simple.

    There’s an interesting piece at Wired on hackers and their impact on security. Despite the constant hacks and cracks of passwords, the regular lectures and pieces written on the subject, many people refuse to use separate passwords on every site, or choose long passphrases, or implement many of the best practices that are published on security. Some of that might be a lack of knowledge, but much of it is likely explained by behavioral economics.

    Most people are never hacked and don’t have issues. Even if they do experience some problem, they can often recover fairly easily. Lots of hacks are just annoying, like using your email account to send SPAM, akin to random vandalism. As a result, many people don’t bother to change their habits. It might also be a tendency that’s hard-wired in our personalities. I’ve educated friends on passwords and given them Password Safe. A few use it religiously, but others keep forgetting, preferring to keep regenerating and changing passwords or re-using them.

    To solve some of these issues and create the behavior that we want, there are suggestions in the article for software designers. One is requiring stronger mechanisms up front, another suggests perhaps changing from alphanumeric pass-phrases to image based ones. One poses the idea of enforcing penalties on users. These might be ways in which we can convince software users to take security more seriously. If it’s true that software is eating the world, then perhaps the designers and developers should do their part to help make sure security is a part of the new world.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.