I have a new requirement to encrypt the data inside an sql database while it is at rest.
So far I've looked at Bitlocker (see below), and other commercial products (I won't name because I'm not looking for this product is best answers). I've also looked at SQL Transparent Data Encryption.
TDE seems to be the fairly easy option, but given the pricing for sql is very high when looking at using 6 cores. I've been asked to find other options.
The primary question I have is regarding Bitlocker and its use inside a hyper-v guest and on the hyper-v host.
Firstly can Bitlocker be used inside a hyper-v guest, 50% of posts I've found say it isn't supported the others say it is?
Also should I use it at the hyper-v host level? Here is where things get a little fuzzy for me. If I enable on the boot volume then yes the host can't be booted without a start up password (one option) but that doesn't encrypt the data on the shared storage, and I assume I can't encrypt the iSCSI volumes because they are shared between multiple nodes in our hyper-v cluster. Which then makes it pointless because if someone steals the storage device they can read the data.
BitLocker can be enabled at the host level. The host can start without intervention provided that the server has a TPM chip (any decent server hardware in the last five years has a TPM chip). Microsoft added BitLocker support for CSV volumes in Windows Server 2012.
BitLocker in a guest is currently not supported by Microsoft. It is possible, but to enable automatic startup without intervention requires storing the Startup Key (not the same as the Recovery Key) on a local partition. This also is not as secure as required in some scenarios because if the host is compromised, the guest could be started and the encryption keys attacked in memory (or from a memory dump of the guest).
It may be worth mentioning that Hyper-V 2016 will finally provide a Virtual TPM feature.
How to Configure BitLocker Encrypted Clustered Disks in Windows Server 2012
http://blogs.msdn.com/b/clustering/archive/2012/07/20/10332169.aspx