Is it? Not hardly. While there's no single security control good enough to protect everything, TDE comes pretty darn close.
With transparent data encryption, rather than having to rewrite applications or craft custom encryption and decryption code, the entire database (MDFs, tempdb, etc.) is decrypted/encrypted during disk reads and writes. In many situations, developers haven't had the option to modify their applications to take advantage of database encryption, so TDE opens up a whole new realm of possibilities.
Another benefit of transparent data encryption is that since the databases are encrypted, database backups are automatically encrypted as well. This is another risk-mitigation benefit. Still, it can increase the storage space required since compressing encrypted data doesn't work all that well. You may experience an additional hit if you transfer data to a cloud backup provider. This is not a big problem, but certainly something to consider.
Another nice enhancement in SQL Server 2008 is extensible key management which allows you to use key third-party management applications already in place to help SQL Server fit right in at the enterprise level.
Handling security at this layer introduces some data recovery risks in the event of a system failure. However, SQL Server 2008 stores the database encryption key (DEK) within the system's boot record which can be subsequently recovered using the database service master key or a hardware security module (HSM) such as a smart card or USB storage device.
So should you move to SQL Server 2008 to take advantage of these new features and be done with this database encryption thing once and for all? Maybe. It's certainly worth considering – especially for smaller shops where upgrading and rolling it out would be less of a burden. Just don't jump into SQL Server encryption head first. It's common knowledge – and Microsoft even admits – that database encryption in SQL Server 2008 can add a lot of processing overhead to the server. Unfortunately, I think it's this very thing that keeps many DBAs from going down the encryption path, which potentially puts us back at square one. Still, it doesn't have to be a problem if you do it the right way, so plan things out and do your homework first.
I think we've about beaten this database encryption horse into the ground. The threats your business faces should provide ample justification to encrypt your business's most prized possession. Fueling the fire are the state breach notification laws in which encrypted data is often exempt. Those laws in and of themselves should be a big motivator to encrypt where it makes reasonable sense.
Database encryption for SQL Server 2008 isn't a silver bullet, but it does offer up a strong layer of protection when all other controls fail. It's certainly worth considering. If not now, then when?
ABOUT THE AUTHOR
Kevin Beaver, is an information security consultant, keynote speaker and expert witness with Atlanta-based Principle Logic LLC. Kevin specializes in performing independent security assessments. Kevin has authored/co-authored seven books on information security, including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator of the Security on Wheels information security audio books and blog providing security learning for IT professionals on the go. Kevin can be reached at firstname.lastname@example.org.
This was first published in January 2010