As we mentioned in our last post, there are three options for encrypting entire storage volumes:
We will start with the first two today, then cover proxy encryption and some deeper details on cloud key managers (including SaaS options) next.
This is the least secure and manageable option; it is generally only suitable for development environments, test instances, or other situations where long-term manageability isn’t a concern.
Here is how it works:
- The encryption engine runs inside the instance. Examples include TrueCrypt and the Linux
- You connect a second new storage volume.
- You log into your instance, and using the encryption engine you encrypt the new storage volume. Everything is inside the instance except the raw storage, so you use a passphrase, file-based key, or digital certificate for the key.
- You can also use this technique with a tool like TrueCrypt and create and mount a storage volume that’s really just a encrypted large file stored on your boot volume.
Any data stored on the encrypted volume is protected from being read directly from the cloud storage (for instance if a physical drive is lost or a cloud administrator tries to access your files using their native API), but is accessible from the logged-in instance while the encrypted volume is mounted. This protects you from many cloud administrators, because only someone with actual access to log into your instance can see the data, which is something even a cloud administrator can’t do without the right credentials.
This option also protects data in snapshots. Better yet, you can snapshot a volume and then connect it to a different instance so long as you have the key or passphrase. Instance-managed encryption also works well for public and private cloud.
The downside is that this approach is completely unmanageable. The only moderately secure option is to use a passphrase when you mount the encrypted volume, which requires manual intervention every time you reboot the instance or connect it (or a snapshot) to a different instance. For security reasons you can’t store the key (or passphrase) in a file in the instance, or use a stored digital certificate, because anything stored on the unencrypted boot volume of the instance is exposed. Especially since, as of this writing, we know of no options to use this to encrypt a bootable instance – it only works for ‘external’ storage volumes.
In other words this is fine for test and development, or to exchange data with someone else by whole volumes, but should otherwise be avoided.
Externally-managed encryption is similar to instance-managed, but the keys are handled outside the instance in a key management server or Hardware Security Manager (HSM). This is an excellent option for most cloud deployments.
With this option the encryption engine (typically a client/agent for whatever key management tool you are using) connects to an extermal key manager or HSM. The key is provided subject to the key manager’s security checks, and then used by the engine or client to access the storage volume. The key is never stored on disk in the instance, so the only exposure is in RAM (or snapshots of RAM). Many products further reduce this exposure by overwriting keys’ memory when the keys aren’t in active use.
As with instance-managed encryption, storage volumes and snapshots are protected from cloud administrators. But using an external key manager offers a wealth of new benefits, such as:
- This option supports reboots, autoscaling, and other cloud operations that instance-managed encryption simply cannot. The key manager can perform additional security checks, which can be quite in-depth, to ensure only approved instances access keys. It can then provide keys automatically or alert a security administrator for quick approval.
- Auditing and reporting are centralized, which is essential for security and compliance.
- Keys are centrally managed and stored, which dramatically improves manageability and resiliency at enterprise scale.
- Externally-managed encryption supports a wide range of deployment options, such as hybrid clouds and even managing keys for multiple clouds.
- This approach works well for both public and private clouds.
- A new feature just becoming available even you to encrypt a boot volume, similar to laptop full disk encryption (FDE). This isn’t currently possible with any other volume encryption option, and it is only available in some products.
There are a few downsides, including:
- The capital investment is greater – you need a key management server or HSM, and a compatible encryption engine.
- You must install and maintain a key management server or HSM that is accessible to your cloud infrastructure.
- You need to ensure your key manager/HSM will scale with your cloud usage. This isn’t less an issue of how many keys it stores than how well it performs in a cloud, or when connecting to a cloud (perhaps due to network latency).
This is often the best option for encrypting volume storage, but our next post will dig into the details a bit more – there are many deployment and feature options.