S3 is encrypted in transit (like most data nowadays)
S3 can also be encrypted at rest. The encryption can be performed client-side or server-side [0]. Nowadays, AWS performs server-side encryption by default, unless you disable it.
Thereby proving that checkbox security is pointless.
What threat models does AWS server-side at-rest encryption protect against? Someone breaking into an S3 data center and walking off with a box of hard drives? AWS reselling obsolete hardware on eBay and forgetting to wipe a disk?
And yet what does it not protect against at all? A misconfigured load balancer that can access 169.254.169.254 and dump your AWS access key straight to an attacker, who can then use it to ask AWS to politely decrypt all of your data.
What does it really not protect again? The US.gov issuing a National Security Letter to Bezos threatening jail time if they don't decrypt and hand over the data.
To reach the spirit of the "data must be encrypted at rest" laws, I believe you should encrypt the data using your own keys which are maintained in an HSM that AWS cannot access. This means that you cannot run your entire stack on one cloud, which would be a huge driver of cost and complexity.
> What threat models does AWS server-side at-rest encryption protect against?
A lot of threats. A rogue employee sucking up data. Malware on AWS servers.
Not likely, but certainly possible. Server-side encryption is useful, but if you want to be _certain_ that your data is safe, then client-side encryption does exactly what you're asking for.
Client-side encryption can use a local key, or a key in KMS.
Yeah I generally have a pretty negative take about tech regulations, especially security ones. They are often written by people who don't understand either the technology or the threats, and are often implemented by people who don't really care about the threats, just about compliance.
Client-side encryption is a lot better. If the regulations were drafted in a technology and security aware way, maybe they would include something more detailed than "data must be encrypted at rest" which would require such practices. As it stands today, you can be in compliance without actually gaining much in the way of practical security improvement.
> A lot of threats. A rogue employee sucking up data. Malware on AWS servers.
IMO server-side encryption-at-rest does not protect against either of these, although there might be some edge cases where it does. For example, malware on the S3 gateway would see the data decrypted. A rogue employee with very limited access may be stopped by this, but I would guess that most rogue employees would be abusing the support impersonation processes or would deploy evil code that can access the data after decryption.
Client-side encryption would prevent both of these threats as well as the more common ones like losing access to your AWS keys somehow. As long as the method that leaked the AWS key didn't just leak your client-side encryption key as well.
All security evaluations should start with a threat model. If you're trying to protect yourself against APTs or nation states, you have a very different challenge than if you're trying to protect against drive-by ransomware.
