What You Need to Know About Amazon’s New Volume Storage Encryption
Amazon Web Services dropped a security bomb this week when they announced the immediate availability of volume storage encryption. With one click, for free, you can encrypt any EBS (Elastic Block Storage) volume in AWS. For those who aren’t familiar with AWS, they are effectively virtual hard drives you attach to a running instance (virtual machine). I missed this one, but Contributing Analyst Gal Shpantzer picked it up and mailed it to us internally. I’m on a plane so I’ll keep this short and to the point: Encrypting a volume is a simple as checking a box when you create it, or making an API call. You cannot encrypt a boot volume. You can only encrypt additional volumes (extra “hard drives”, not the one you boot your operating system from). Amazon manages the keys for you. There are currently no provisions to manage your own key. Encrypting the volume protects it in snapshots, and as you make copies and move them around. This is similar to AWS encryption for S3, which has been out for a while. Here’s the context: Werner Vogels, Amazon’s CTO, has pretty much said the cloud is moving to encryption by default. This is another step in that direction. This is awesome for compliance. Technically it means Amazon (and thus a government) can see your data. However, Amazon has extremely strict segregation of duties internally and I strongly suspect it is nearly impossible, or even effectively impossible, for an employee to gain access to your key. But we cannot know this for sure until Amazon releases more details, and this does not protect you in case AWS receives a legal court order to access your data. The only real assurance you can have about complete control (privacy) for your data is control of your own keys (I consider CloudHSM a solid option, even though it is hosted in AWS). Before going too crazy with this… experiment with performance and file system requirements. My previous research showed there are always tradeoffs. They are pretty much always manageable, but only once you learn your way around the land mines. This will hurt some of the existing cloud encryption market, but not a lot. Many organizations encrypt to maintain high assurance, and this does not provide that. It does, however, knock out some compliance concerns; it also provides excellent basic data security if you don’t mind that Amazon could technically get your data in an extreme situation (such as legal discovery). It also doesn’t help with boot volumes. From now on I suggest you check this box by default once you complete performance testing. Where is this headed? Hard to tell. AWS allows customers to manage their own keys (using CloudHSM) for some services including RedShift and RDS. But they have yet to enable it for S3, even though that has been around for a while. In the long run I suspect AWS to enable CloudHSM management of S3 and EBS keys, but I have no idea of timing. Boot volume encryption is likely much further down the road, beyond the event horizon for analyst predictions. The cloud encryption market won’t take too much of a hit for a while. At the low end no one pays for encryption anyway. Above that, customer needs are beyond this. If you use AWS this is your easiest encryption option, but make sure you know what it provides: compliance, snapshot protection, and protection from single-point-of-failure access to your storage volumes. You will need to look at commercial alternatives if you want to encrypt boot volumes, manage keys consistently in hybrid or multiple-cloud deployments, assure Amazon can never see your data, or keep governments out. As always, hit me up with questions in the comments. Share: