[AWS engineer here] You're right. It's encryption at rest. The article reads like it's been written by someone who doesn't understand how those leaks occurred, what encryption means, or what has been launched here.

I'd recommend changing from this article to the official announcement from AWS.

https://aws.amazon.com/blogs/aws/amazon-s3-encrypts-new-obje...

Actually, looks like they understand how the leaks occurred. Just not that AWS automatically decrypts the files, making it unable to protect against those types of breaches.

I don't think you are off the mark.

(from https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingE...) > Server-Side Encryption – Request Amazon S3 to encrypt your object before saving it on disks in its data centers and then decrypt it when you download the objects.

Yes it looks like it's at rest. It automatically decrypts if you go through S3 APIs to access the objects. The big leaks were due to S3 buckets being public which I believe means that this new encryption on by default won't actually help.

The only thing Encryption at rest gives you is comfort in knowing if Amazon servers get compromised - not if your servers that have permissions to pull the data get compromised.

With that said, it is a good step in the right direction. And additional security added helps address at least some use cases.

No, I think you're right. The author conflates Amazon's own access to data encrypted at rest, which is what this appears to be about, with other security issues. This will help prevent, say, old hard drives being disposed of improperly, concerns around AWS employees easily viewing your data, etc..

Nothing will help if the credentials that grant access to read the encrypted data are what's compromised.

If decryption takes place on a different machine than the stored data, there's plenty you can do to separate how those are accessed. It's not a perfect system, but it is a legitimate extra layer of security.

I'm unsure which point you're following up on.

Yes, it's a legitimate extra layer of security if you do what you're suggesting, but that's not what's occurring here, though it may be what's happening within AWS's own data centers. But again, let's not conflate the two.

From a customer's perspective: calling AWS will return the data unencrypted regardless of if this flag is on because AWS will decrypt before returning it, seamlessly. If the credentials allow access to the S3 bucket, that's that, and your data will still be compromised regardless if this feature is on or off.

No, you are correct. The author seems to be confused about how EAR works.

What you and others replying to you, seem to be missing, is that there are several flavors of Server Side Encryption, and where the control layer is concerning the access to the key when you ask for decryption. The article did not explain it well, and in any case the automatic option being enabled here, will not achieve this additional control level.

If the leak was due to credentials leak would not help. But if the leak was because somebody accidentally made a server side object public AND you are using a KMS customer key then you have an additional layer of control required.

You can easily see that, if you make a server side encrypted object on S3 public, but you are using a KMS customer key, you will get a different message from the default decryption of the object granted by this new default...

You will get something like this

<Error>

<Code>InvalidArgument</Code>

<Message>

Requests specifying Server Side Encryption with AWS KMS managed keys require AWS Signature Version 4.

</Message>

<ArgumentName>Authorization</ArgumentName>

<ArgumentValue>null</ArgumentValue>

<RequestId>B24FYZDV760J6TK0</RequestId>

<HostId>

Xi2fLZvfHxu5VopeLIrP292lg7WMV5ubVaBVpFdlynjL6V08IbdEFWYJuYwQZdLP/cZF2USWdNg=

</HostId>

</Error>

This blog might help:

"How to use KMS and IAM to enable independent security controls for encrypted data in S3" - https://aws.amazon.com/de/blogs/security/how-to-use-kms-and-...