In the first few days of the new year, AWS enabled Amazon S3 encryption at rest as a default setting. The announcement sparked excitement and a few articles that laud the move. I’ll agree that, yeah, this feature is a nice-to-have. But S3 encryption at rest isn’t doing what a lot of well-intentioned but sadly mistaken commentators believe that it does.
Let’s ratchet down the enthusiasm and set the record straight about what security protections you actually get from S3 encrypting data at rest.
The 3 places where data encryption can happen
There are a few places encryption can happen as I go about putting data into S3. Let’s say I want to stuff the text string platypus in an S3 bucket because, I don’t know, I want to pay the ~millionth of a cent a month to AWS for the privilege of storing the name of a monotreme that’s near and dear to my heart. I have three options.
1. Encrypting data locally
I could encrypt my platypus text string locally before sending it off to the bit barn in the sky. Unless you don’t believe in math or there’s a serious flaw in our current understanding of modern cryptography, AWS cannot decrypt that data — full stop.
Most people don’t locally encrypt data; it has a way of limiting how useful the data can be. But for some use cases (that generally round to “I don’t trust my cloud provider”), local encryption isn’t only a good idea, it’s required. I’m not here to judge.
2. Encrypting data in transit
I could choose to encrypt my platypus data in transit. This is the S in “https” URLs. Hypertext Transfer Protocol Secure uses encryption to ensure that at no point can anything between your web browser (or whatever client you’re using) and wherever SSL/TLS terminates on the other side (often a load balancer, web server, or similar) see your data. Not your ISP, not other people on your Wi-Fi network, not even the networking stack of your operating system’s kernel. Nothing.
A majority of traffic on the internet operates this way. Increasingly, some browsers are treating unencrypted connections as a failure state. (As an aside, you can transfer data out of S3 via unencrypted means by use of the HTTP website endpoint for S3, but if you’re doing such things, you’re either in for a world of hurt or else sharing out things like “static assets for websites (which will throw warning flags in modern browsers and web page performance testing tools about mixed schemes)” and you don’t hugely care about people intercepting them along the way. I sure hope you’re OK with bad actors potentially changing the contents of your assets in flight, but that’s a problem for another day.)
3. Encrypting the data at rest
I could encrypt my platypus text string data at rest. When your data lives on a hard drive, it can be stored in plain text or it can be encrypted. If it’s encrypted, anything that wants to read that data has to decrypt it.
This is what S3 has enabled as the default setting for all uploads on or after Jan. 5, 2023.
What S3 accomplishes by encrypting data at rest by default
Encrypting the data at rest solves precisely two problems.
The first is it renders the data useless in the event that a hard drive leaves an AWS facility without being properly sanitized first. Let me be clear: This does not happen–should you know otherwise, this is a screaming red flag that would damage AWS’s security positioning irreparably.
Sure, it may happen in your crappy data center with a security guard who’s sound asleep at 3 a.m. and the back door left unlocked by mistake, but this is AWS we’re talking about. It attests in multiple places and has had third parties validate that disks and other media do not leave AWS facilities without being sanitized in accordance with NIST 800-88 guidelines. For anything that isn’t designed to be reused, like a Snowball Edge device, drives do not leave an AWS facility without being either incinerated or shredded.
The second problem that encryption at rest solves is, quite simply, checking the compliance box. Don’t misunderstand me: there are many scenarios where encryption at rest isn’t useless! Data being encrypted on disk is extremely important for your phone, tablet, or laptop. If someone snatches your device from a coffee shop, you want them to have gained the physical computer only; the data contained within should be completely inaccessible.
This is moderately important in most traditional data center environments. It’s uncommon, but someone could always cut through a facility wall, pistol whip the security guard, and steal drives, or they could dress up as police officers to subdue and tie up your staff, then steal equipment out the front door of the facility, or your data center could even hire somebody who steals hard drives to resell. These things happen! But AWS isn’t a random data center operator. My position is that if someone can get a hard drive out of an AWS facility without being arrested or killed, they’ve basically earned it.
But making that argument to your auditor is time-consuming and leads to escalating games of “what if,” so it’s always been easier to check the box and get on with things. That’s what this AWS change to S3 does: It automatically checks the box for you. No less, but also no more.
What S3 doesn’t accomplish by encrypting at rest by default
What this change absolutely does not do, and what a number of folks are getting dangerously wrong, is solving in any way, shape, or form the S3 Bucket Negligence problem. If you configure an S3 bucket to be world readable, then yes, the data is going to be encrypted on disk. But when someone requests a copy of that data from the S3 bucket, the S3 service will happily grab the encrypted data from disk, decrypt the encryption key used to encrypt it, use that key to decrypt the data, and return the data to whomever’s asking for it.
Simmer down and stay vigilant
Amazon S3’s default setting for encryption at rest is, at best, a nice-to-have feature for folks who have to deal with compliance regimes and InfoSec policies that don’t take “hyperscale cloud” into account. At worst, it’s something you absolutely do not care about in the slightest — but that’s OK, because it comes to you at no performance or financial penalty.
But it is absolutely not a panacea for data breaches, a solution to misconfigurations in cloud service providers, or, frankly, a change that’s worth even a tenth of the attention that it’s gotten.
