Encryption in SQL 2008 Standard Edition 64 Bit

  • There is a partial resolution which I don't like either.. But you encrypt the data fully at the front-end and only the encrypted data is stored in the database and snet over the wire. Then however your developers are more likely to have access to the data.

    So it still comes down to who do you trust more? And honestly I am all for accountability but at some point you have to trust someone. And all you can do is make it harder to breach, it is simply not possible to completely prevent a breach from EVER happening..

    CEWII

  • Exactly. I agree.

    One problem here seems to be differentiating between users/hackers and inside staff and the security measures taken to protect the data from each. Personally, I am of the opinion that "if you don't trust me, why am I here".

    These are two distinct issues, and the fixes for one may not be a fix for the other.

    As for the inside staff, there are only two real things you can do:

    1) Have a policy stating that they can't use the information for personal gain, and they are not allowed to devulge the information to anyone that doesn't have a direct and business need to know it. Have them sign it.

    2) Limit the people that have access to it to a bare minimum. Two people at most (back-up for vacations, etc.).

    Your suggestions above are great ways to thwart users/hackers so that they don't get the keys.

    Like I say, two distinct issues..........

  • As far as item #1, I think that is included in most employee handbooks under conflicts of interests and ethical behaviors. Also I believe that for some of the information I know that legally I am still effectively under non-disclosure 10-15 years later.

    But the fact is who do you trust and a DBA is a highly trusted individual and he (or she) should act like it.

    CEWII

Viewing 3 posts - 16 through 17 (of 17 total)

You must be logged in to reply to this topic. Login to reply