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.
Reader interactions
9 Replies to “What You Need to Know About Amazon’s New Volume Storage Encryption”
Are there any “HSM as a Service” alternatives to AWS’s CloudHSM where a customer wouldn’t be subject to AWS holding all the eggs in one basket but the customer wouldn’t need to deploy their own HSM hardware?
Hi Rich
I am very interested in the issue of HSM encryption as protection against a government warrant, more precisely making it impossible for AWS to comply with a US governement SCA warrant in Europe as in the Microsoft/Dublin case. This is what AWS people are saying in Europe.Paraphrase “Don’t worry, with HSM we can’t comply”!
I leave aside the legal complications (I wouldn’t want, personally, to tell a federal judge that I helped set up a warrant non compliance protection system), but do you think it could work technically? In any case AWS would have to turn over the encrypted data and an unopened copy of the HSM system. Can a governement with lots of resources (ex:US) break today’s encryption by “brute force”? Either on the data or the HSM ?
Thanks
Thanks for writing on this one, Rich. I’ve read the announcement of this offering with interest and I’m still confused what threat scenario this really protects against. With the keys managed by AWS and auto-presented to any EC2 or other service that needs them, this seems to only provide checkbox compliance assurance without any real increase in your posture. If AWS can always read my encrypted volumes, what does this new option give us that we didn’t have before?
A couple options:
1. Compliance checkbox, as you say.
2. A storage admin can’t read your stuff. Someone needs access to both your key and your data. That’s tough, knowing the AWS internal controls (well, some of them at least).
3. Protects snapshots since they are encrypted. That’s the bigger one I think.
For (3), aren’t the snapshots automagically decrypted to anyone who asks for them? To put it differently, how would someone access a snapshot and _not_ have AWS cheerfully decrypt the snapshot for the requester?
No- the key is tied to *your* AWS account. This means you can’t accidentally make a snapshot public or share it with another account. But yes, any authorized user *in* your account can get to it.
Ah so! Light bulb illuminated. Thanks for the clarification, Rich.
AWS should publish their threat model for this feature. I suspect it will always rely on their internal processes which you have no visibility of. Regulators beware.
AWS should publish their threat model for this feature. I suspect it will always rely on their internal processes which you have no visibility of. Regulators beware.