Is Transparent Data Encryption useful ? What practical intrusion does it protect against?

  • We have a large VMWare environment with HP SAN, and 2 datacenters - primary and DR, with SAN based replication between them.

    We also backup databases to tape via Commvault and send them off-site using a vendor.

    TDE protects data at 'rest', meaning, (that if it wasn't implemented, and) if someone got a hold of our physical .mdf/.ldf files, or our .bak's, or tapes, they could recover the data.

    I'm curious, has there been a real-life example where it actually helped prevent hackers ?

    If someone is able to gain physical access to these files, isn't there a bigger problem at hand ?

  • sqld-_-ba (10/12/2015)


    We have a large VMWare environment with HP SAN, and 2 datacenters - primary and DR, with SAN based replication between them.

    We also backup databases to tape via Commvault and send them off-site using a vendor.

    TDE protects data at 'rest', meaning if someone got a hold of our physical .mdf/.ldf files, or our .bak's, or tapes, they could recover the data.

    I'm curious, has there been a real-life example where it actually helped prevent hackers ?

    If someone is able to gain physical access to these files, isn't there a bigger problem at hand ?

    They could not recover the data. Well, they would have to attempt to decrypt it.

    I don't know of any real world examples but it's another layer of security on top of already existing security procedures. As with all security, you don't want to simply enable TDE and say, "good enough". If someone can gain physical access then yes, you have a massive problem but if it's encrypted with TDE it will be extremely difficult to obtain any usable information. However, if someone is actually able to log into your server and access the DB because of slack security procedures, you're hosed.

    Edit: Keep in mind that TDE isn't exactly super efficient so prepare for some headaches and large backup sizes. The main thing you want to protect is extremely secret info, like Socials, credit cards, combinations of credit card numbers, addresses, etc. TDE isn't enough encryption and you should either use SQL's field level encryption techniques or use third party or proprietary code to encrypt each of those records.

  • If nothing else, TDE protects IT from the intrusion of nosy compliance auditors. However, as you know, there are other options for implementing data at rest encryption that might work better for your situation.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • I could see a scenario where new hardware is purchased for the database server, and the old hardware ends up donated to the Development team or for sale on the web without first being wiped down. It could also be a smash and grab style burglary. In any event, if an unauthorized person ends up holding the data drives, then without some type of at rest encryption, the authentication and authorization process normally used to protect the data when online no longer applies.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • @josh, i meant to say if that TDE isn't implemented, they could recover it.

    Commvault uses its own deduplication algo for databases, which massively reduces backup size, and I don't know if TDE conflicts with that.

    @eric - what method does your company use (don't say Dell Data Encryption :)), or have seen other companies use, which are practically sound?

  • sqld-_-ba (10/12/2015)


    @josh, i meant to say if that TDE isn't implemented, they could recover it.

    Commvault uses its own deduplication algo for databases, which massively reduces backup size, and I don't know if TDE conflicts with that.

    @eric - what method does your company use (don't say Dell Data Encryption :)), or have seen other companies use, which are practically sound?

    I don't know much about commvault but any database backup with sql or redgate compression is almost the same size as the database file size.

  • sqld-_-ba (10/12/2015)


    TDE protects data at 'rest', meaning if someone got a hold of our physical .mdf/.ldf files, or our .bak's, or tapes, they could recover the data.

    TDE protects data at rest meaning they cannot just pick up the mdf\ldf files or the backup file, these are useless without the certificate that encrypts the database.

    sqld-_-ba (10/12/2015)


    If someone is able to gain physical access to these files, isn't there a bigger problem at hand ?

    Yes, you should also be securing your servers NTFS filesystem to prevent users picking these files up, but as i said if you have implemented TDE the files alone are useless, they must have the certificate that encrypts the database.

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

Viewing 7 posts - 1 through 6 (of 6 total)

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