locked
Encrypting SQL Server Data at Rest- Self Encrypting Drives (Hardware) vs. TDE (Software) RRS feed

  • Question

  • TDE seems to be a solid solution for encrypting SQL Server 2008 R2 databases (and TempDb), but it does present quite a few cons such as losing backup compression, losing instant file initialization, requiring Enterprise Edition, requiring careful key/certificate management across all SQL instances, and adding some degree of CPU overhead.

    Does anyone have an opinion regarding TDE vs. doing this lower in the stack at the hardware/storage level with self encrypting drives?  Doing this lower in the stack at the hardware/storage level with self encrypting drives seems to make a lot of sense to me, because the OS and SQL Server don't care/know (completely abstracted) and all the cons associated with TDE mentioned previously would no longer apply.


    Bill Thacker

    Wednesday, March 27, 2013 11:40 PM

Answers

  • Hi Bill,

    TDE, in a scenario where the physical media (such as drives or backup tapes) are stolen, a malicious party can just restore or attach the database and browse the data. One solution is to encrypt the sensitive data in the database and protect the keys that are used to encrypt the data with a certificate. This prevents anyone without the keys from using the data, but this kind of protection must be planned in advance.

    Other solution, you may use Self-Encryption Drives, refer to Top Ten Reasons to Buy Self-Encrypting Drives (SEDs): http://www.storagereview.com/top_ten_reasons_to_buy_selfencrypting_drives_seds.

    If you have any feedback on our support, please click here.

    Thanks.

                                              

    Maggie Luo
    TechNet Community Support

    • Marked as answer by Maggie Luo Thursday, April 4, 2013 9:00 AM
    Thursday, March 28, 2013 6:33 AM

All replies

  • Hi Bill,

    TDE, in a scenario where the physical media (such as drives or backup tapes) are stolen, a malicious party can just restore or attach the database and browse the data. One solution is to encrypt the sensitive data in the database and protect the keys that are used to encrypt the data with a certificate. This prevents anyone without the keys from using the data, but this kind of protection must be planned in advance.

    Other solution, you may use Self-Encryption Drives, refer to Top Ten Reasons to Buy Self-Encrypting Drives (SEDs): http://www.storagereview.com/top_ten_reasons_to_buy_selfencrypting_drives_seds.

    If you have any feedback on our support, please click here.

    Thanks.

                                              

    Maggie Luo
    TechNet Community Support

    • Marked as answer by Maggie Luo Thursday, April 4, 2013 9:00 AM
    Thursday, March 28, 2013 6:33 AM
  • Hi Bill,

    I’m writing to follow up with you on this post. Was the problem resolved?

    If you are satisfied with our solution, I’d like to mark this issue as "Answered". Please also feel free to unmark the issue, with any new findings or concerns you may have.  

    Thanks


    Maggie Luo
    TechNet Community Support

    Thursday, April 4, 2013 9:00 AM
  • Maggie- This is one of those debates that never gets completely resolved, but I'm fine with marking this one "Answered". I was hoping for more participation/conversation, but that doesn't happen all the time.

    My opinion is that doing this lower in the stack at the hardware/storage level with self encrypting drives is the better choice, so I was hoping to see if others agreed or not.


    Bill Thacker

    Thursday, April 4, 2013 2:14 PM
  • I also hope others would also involve in this conversation.

    Maggie Luo
    TechNet Community Support

    Friday, April 5, 2013 1:54 AM