Page 1 of 2 12 LastLast
Results 1 to 15 of 17
  1. #1
    Join Date
    Oct 2003
    Location
    now in UAE, i am an INDIAN.
    Posts
    16

    Unanswered: Protect data from DBA

    Hi all,

    We have sql server 2000 on Windows server 2003.
    Is there anyway in sql server 2000 to protect some crucial data, even from the DBA.

    Thanks in advance...
    TEAM (Together Everybody Achieve More)

  2. #2
    Join Date
    Jul 2007
    Posts
    96
    If you don't trust your DBA fire him. Also, if the data is that sensitive it should already be encrypted when it arrives SQL Server, unless some other secure communication channel is in place.

    So, in short, the answer is yes unless there are dummy ways to reverse every single encryption mechanism supported by SQL Server

  3. #3
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    What do you mean by "protect"? Prevent reading? Exporting? Changing\ adding\ deleting?

  4. #4
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    Diabolic hit the nail on the head, if you don't trust your DBA then you can't trust any of your data... The sensitivity doesn't even factor into that equation.

    The best way to "protect" data from your DBA is to avoid storing that data. If you need to store the data and protect it from your DBA, you have a serious problem. There may be a solution for your problem, but I'd need to spend at least half an hour with you to work out if there was a solution, and it might take even longer to devise the solution itself.

    If you can't trust your DBA with your data, can you trust your users with it?

    -PatP

  5. #5
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    I wonder if this is a "technical" trust.... ya know - how many times do we get people on here asking how to restore a database with no backup.

    If you guys are on the right track then like you say - this is not a technical problem. NDA anyone?

  6. #6
    Join Date
    Jul 2007
    Posts
    96
    Quote Originally Posted by Pat Phelan
    Diabolic hit the nail on the head, if you don't trust your DBA then you can't trust any of your data... The sensitivity doesn't even factor into that equation.

    The best way to "protect" data from your DBA is to avoid storing that data. If you need to store the data and protect it from your DBA, you have a serious problem. There may be a solution for your problem, but I'd need to spend at least half an hour with you to work out if there was a solution, and it might take even longer to devise the solution itself.

    If you can't trust your DBA with your data, can you trust your users with it?

    -PatP
    Pat what I was thinking was this:

    If you encrypt the data with a certificate in your business logic and then send it for the data engine to store it you should be DBA safe. However, dispite the fact that in this case you would need to trust de developer instead of the DBA, you would have serious problems searching the encrypted data.

    I never tried it but it sounds possible, doesn't it?. Being possible different than functional

  7. #7
    Join Date
    Jan 2003
    Location
    Massachusetts
    Posts
    5,800
    Provided Answers: 11
    Considering the trust level associated with the DBA, either the original poster's signature, or the DBA must be changed.

  8. #8
    Join Date
    Nov 2005
    Posts
    122
    Quote Originally Posted by Diabolic
    If you encrypt the data with a certificate in your business logic and then send it for the data engine to store it you should be DBA safe.
    And who would you trust to keep backups of the certificate?

  9. #9
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    Quote Originally Posted by Diabolic
    If you encrypt the data with a certificate in your business logic and then send it for the data engine to store it you should be DBA safe.
    DBA safe, and query proof. Sounds like throwing out the baby with the bathwater to me.
    Quote Originally Posted by Diabolic
    I never tried it but it sounds possible, doesn't it?. Being possible different than functional
    Yes, it sounds possible, but why? If you don't trust your DBA with the data, I certainly wouldn't trust users with it!

    Until we hear more from the OP (ipmurali), we are just guessing about what they really want. Until I understand the question better, I'm not going to offer 10,000 suggestions that might not have anything to do with solving the problem.

    -PatP

  10. #10
    Join Date
    Nov 2003
    Posts
    2,934
    Provided Answers: 12
    Quote Originally Posted by MCrowley
    Considering the trust level associated with the DBA, either the original poster's signature, or the DBA must be changed.
    What about legal reasons where the company has to make sure that e.g. payroll, tax, legal or stock relevant information must not be misused?
    I do think there are situations where it's absolutely acceptable to do something like that. But I apart from encrypting the relevant parts in the table I can't think of a different solution as well.
    Quote Originally Posted by MCrowley
    And who would you trust to keep backups of the certificate?
    You don't necessarily need that. The encryption could be based on a user's password or something similar, so that each user is responsible for securing "his/her" data.

  11. #11
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Quote Originally Posted by shammat
    What about legal reasons where the company has to make sure that e.g. payroll, tax, legal or stock relevant information must not be misused?
    I do think there are situations where it's absolutely acceptable to do something like that. But I apart from encrypting the relevant parts in the table I can't think of a different solution as well.
    I've signed NDAs. I've never been asked to close my eyes whenever I execute a query. At some point some people have to be trusted with the data - whatever that data is - and one of those people has to be the DBA even if it simply is only the most senior DBA.

  12. #12
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Heh - not picking on you honets
    Quote Originally Posted by shammat
    You don't necessarily need that. The encryption could be based on a user's password or something similar, so that each user is responsible for securing "his/her" data.
    Seriously dude - you would trust the existance of your data on a user remembering their password? If the data is that important surely this is the last thing you would do. That's bowel looseningly scary. Have you ever implemented a solution along these lines?

  13. #13
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    Quote Originally Posted by Pat Phelan
    ...if you don't trust your DBA then you can't trust any of your data...
    A DBA is kind of a combination of your priest and your dentist.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  14. #14
    Join Date
    Nov 2004
    Location
    on the wrong server
    Posts
    8,835
    Provided Answers: 6
    Quote Originally Posted by blindman
    A DBA is kind of a combination of your priest and your dentist.
    puhleeeze. this is a little self serving egotism and I have worked with a couple of DBAs that I would not trust to guard a cup of warm pee.

    one of the last applications I wrote while I was transitioning to being a DBA, encrypted credit card data at the client and stored it and there is absolutely nothing wrong with this. no one (including the lead dba) had the keys except for the CIO and myself and there is really no legitimate reason for anyone else to have this data. if someone needed a decrypted number, they can use the secured application to get it. If the application broke, the cipher we used was widely used, publicly available and everything was recoverable.
    “If one brings so much courage to this world the world has to kill them or break them, so of course it kills them. The world breaks every one and afterward many are strong at the broken places. But those that will not break it kills. It kills the very good and the very gentle and the very brave impartially. If you are none of these you can be sure it will kill you too but there will be no special hurry.” Earnest Hemingway, A Farewell To Arms.

  15. #15
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    Quote Originally Posted by Thrasymachus
    puhleeeze. this is a little self serving egotism and I have worked with a couple of DBAs that I would not trust to guard a cup of warm pee.
    Was it your CHOICE to work with them? Did you HIRE them? Would you HIRE them?
    Just because someone else values their soul or their teeth less than a fresh glass of urine does not make it a wise choice.
    My analogy stands....
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •