NOTE: This article originally appeared on LinkedIn.
By now, I’m sure most of you have seen the recent article on TechCrunch related to public EBS snapshots. If you haven’t let me sum it up for you - like S3 if you do silly things, your data may end up in the wrong hands.
In the article, the security researcher - Ben Morris - estimates that there “…could be as many as 1,250 exposures across all Amazon cloud regions.”
Before talking about some simple strategies you can use to avoid an unexpected data breach, let’s make some estimates of our own.
A few years back during his Re: Invent keynote Andy Jassy gave us a glimpse of the number of active customers on the AWS platform. The number he shared was one million-plus.
Based on how we see our customers using AWS, I’ll assume that each of these customers is running multiple AWS accounts. While some of our customers run dozens (and dozens) of accounts, let’s keep the math simple and say on average each customer has 5 AWS accounts.
Also using averages from our customers, let’s say that in each of those AWS accounts there is an average of 25 EBS volumes, each with a single EBS snapshot. Since we all follow best practice, we know that we’re going to have more than just one snapshot for each EBS volume - right? But this number will make our math easy.
Let’s recap - we have 1 million AWS customers, each of those customers has 5 AWS accounts, and each of those AWS accounts has 25 EBS snapshots … by now, I hope you see where this is going…
If we do some simple math, we can estimate - I use that term loosely - that there are approximately 125 million EBS snapshots on the AWS platform. If we use Ben’s number of 1,250 potential exposures, then we can say that about 0.0001% of all EBS snapshots are exposed.
Before moving on, let me clarify. I am not saying you shouldn’t be aware of these types of issues. Ben shed light on a potential problem that I believe not many people have considered - it seems that S3 gets the majority of the bad press. Let’s keep this perspective; it’s a concern, but not a cause for panic.
I think that understanding the potential risk in your environment is essential, so let’s talk about how you can ensure you don’t find yourself in this position.
I’m regularly surprised when customers are not aware of this critical document. Here’s a quick recap. AWS is responsible for the security “OF” the cloud - you as a customer are responsible for security “IN” the cloud.
Protecting your data falls into the customer end of things.
In the past, I’ve written about the AWS Shared Responsibility Model.
One of the easiest things you can do to protect yourself against accidental data exposure is encrypting your data. EBS volumes support encryption, and AWS recently announced default encryption at the account level. Do yourself a favour and require all data at rest (and in transit) be encrypted.
Another overlooked, but essential service is AWS Config. This service discovers and monitors supported resources in your AWS account. I describe it as a CMDB for your AWS deployment.
At a minimum, enable AWS Config in the AWS regions you’re actively using - want to go further? Then turn it on in all regions.
Once enabled, you can ensure compliance by using AWS provided (or custom) config rules. I would suggest creating a custom rule to monitor for public EBS snapshots - as well as unencrypted EBS Volumes.
So there you have it - three simple things you can do this week to avoid the accidental exposure of data on your EBS snapshots.
Like what you read? Why not subscribe to the weekly Orbit newsletter and get content before everyone else?