Encrypting IaaS storage is a hot topic, but it’s time to drop the esoterica and provide some technical details. I will use a lot of terminology from last week’s post on IaaS storage options, so you should probably read that one first if you haven’t already.
Within the cloud you have all the same data storage options as in traditional infrastructure – from the media layer all the way up to the application. To keep this post from turning into a white paper, we will limit ourselves to volume storage, such as Amazon Elastic Block Storage (EBS), OpenStack volumes, and Rackspace RAID volumes. We’ll cover object storage and database/application options in future posts.
Before we delve into the technology we should cover the risk/use cases. Volume encryption is very interesting, because it highlights some key differences between cloud and traditional infrastructure. In your non-cloud environment the only way for someone to steal an entire drive is to walk in and yank it from the rack, or plug in a second drive, make a byte-level copy, and walk out with that. I’m simplifying a bit, but for the most part they would need some type of physical access to get the entire drive.
In the cloud it’s very different. Anyone with access to your management plane (with sufficient rights) can snapshot a volume and move it around. It only takes 2-3 command lines to snapshot a drive off to object storage, make it public, and then load it up in a hostile environment. So IaaS encryption:
- Protects volumes from snapshot cloning/exposure.
- Protects volumes from being explored by the cloud provider (and private cloud admins).
- Protects volumes from being exposed by physical loss of drives (more for compliance than a real-world security issue).
Personally I worry much more about management plane/snapshot abuse than a malicious cloud admin.
Now let’s delve into the technology. The key to evaluating data at rest encryption is to look at the locations of the three main components:
- The data (what you are encrypting).
- The encryption engine (the code/hardware that encrypts).
- The key manager.
For example, our entire Understanding and Selecting a Database Encryption or Tokenization Solution paper is about figuring out where these bits to satisfy your requirements.
IaaS volume encryption is very similar to media encryption in physical infrastructure. It’s a coarse control designed to encrypt entire ‘drives’, which in our case are virtual instead of physical. Whenever you mount a cloud volume to an instance it appears as a drive, which actually makes our lives easier. This protects against admin abuse, because the only way to see the data is to go through a running instance. It protects against snapshot abuse, because cloning only gets encrypted data.
Today there are three main models:
- Instance-managed encryption: The encryption engine runs within the instance, and the key is stored in the volume but protected by a passphrase or public/private keypair. We use this model in the CCSK cloud security training – the volume is encrypted with the standard Linux
dm-crypt(managed by thecryptsetuputility), with the key protected by a SHA-256 passphrase on the volume. This is great for portability – you can detach and move the volume anywhere you need, or even snapshot it, and can only open it if you have the passphrase. The passphrase should only be in volatile memory in your instance, which isn’t recorded during a snapshot. The downside is that if you want to automatically mount volumes (say as you spin up additional instances or if you need to reboot) you must either embed the passphrase/key in the instance (bad) or rely on a manual process (which can be automated withcloud-init, but that’s another big risk). You also can’t really build in integrity checking (which we will discuss in a moment). This method isn’t perfect but is well suited to many use cases. I don’t know of any commercial options, but this is free in many operating systems. - Externally managed encryption The encryption engine runs in the instance, but the keys are managed externally and issued to the instance on request. This is more suitable for enterprise deployments because it scales far better and provides better security. One great advantage is that if your key manager is cloud aware, you can run additional integrity checks via the API and get quite granular in your policies for issuing keys. For example, you can automate key issuance if the instance was launched from a certain account, has an approved instance ID, or other criteria. Or you can add a manual check into the process where the instance requests the key and a security admin has to approve it, providing excellent separation of duties. The key manager can run in any of 3 locations: as dedicated hardware/server, as an instance, or as a service. The dedicated hardware or server needs to be connected to your cloud and is used only in private/hybrid clouds – its appeal is higher security or convenient extension of an existing key management deployment. Vormetric, SafeNet, and (I believe) Voltage offer this. Running in an instance is more convenient and likely relatively secure if you don’t need FIPS-140 certified hardware, and trust the hypervisor it’s running on. No one offers this yet, but it should be on the market later this year. Lastly, you can have a service manage your keys, like Trend SecureCloud.
- Proxy encryption In this model you connect the volume to a special instance or appliance/software, and then connect your instance to the encryption instance. The proxy handles all crypto operations, and may keep keys either onboard or in an external manager. This model is similar to the way many backup encryption tools work. The advantage is that even the engine runs (hopefully) in a more secure environment. Porticor is an option here.
This should give you a good overview of the different options. One I didn’t mention, since I don’t know of any commercial or freeware options, is hypervisor-managed encryption. Technically you could have the crypto operations handled in the hypervisor, but I think there are a fair few technical and security issues.
If I missed anything let me know, but these are some great real-world options for most volume encryption scenarios…
Reader interactions
8 Replies to “How to Encrypt IaaS Volumes”
Rich,
the on-premise feature was a/the main feature added in 1.1 which was publicly released mid-February. Version 1.0 was SaaS-only indeed.
Udo,
I wasn’t sure if the on-prem version of the product was generally available yet.
Trend Micro’s SecureCloud can be obtained as a service (as you wrote) or as an “on-premise” solution (running on a dedicated server). The actual location of the Key Management Server should of course be disjoint from the cloud(s) hosting the instances of course.
Well.. perhaps I’m not seeing what you mean. With SED the BIOS or OS needs the keys to the drive, which means they would be no more secure in a VM than handling everything through software encryption.
BUt I’m not familiar with JBOD… what’s that? And could be missing something else…
So you think it’s too difficult to retain the keys?
I’m curious how SEDs would work in a BIOSless JBOD.
Rich,
Thank you for the insightful article!
With regards to item #1, and generally speaking; Porticor have developed the Virtual Key Management system for this exact purpose: Creating encrypted disks (manually or automatically) while eliminating the need to store the actual keys/passphrase in the instance. For further details see: http://www.porticor.com/2011/05/cloud-key-management-and-master-keys-for-encryption-in-cloud/
No one that I know of is doing that, but it really isn’t much of a security advantage over the options I lay out. If you control the key yourself, they would have to crack your instance to get to the volume. With a SED you would be more exposed since your provider would need the key to get the drives plugged in in the first place.
Is it possible to send SEDs (self-encrypting disks) to an IaaS cloud provider and retain the keys?
If any IaaS providers will let you use your own disks, this could certainly be an advantage. It might not prevent the FBI, Secret Service, or other LE from pulling your disks—but it would prevent other tenants (and the cloud administration staff) from accessing your disks in any way.