Comment by joshstrange | Hacker News Reader

Comment by joshstrange | Hacker News Reader

> Two notable examples concerning Amazon S3 storage buckets are the leak of data from 123 million households in December 2017 and the leak of 540 million records of Facebook users in April 2019.

> If that data had been encrypted, the leaks wouldn't have had nearly as dire consequences for the exposed individuals, but unfortunately, due to overhead costs, operational complexity, and performance sacrifices, database encryption is commonly avoided.

Ok, I consider myself semi-knowledgeable about these things and I use AWS for professional and personal projects but this confused me. Deciding to encrypt your S3 bucket only means encryption at rest right?. Of course you could encrypt your data before storing it in S3 but that's a different thing. This article seems to think that if encryption was on by default that public buckets wouldn't have leaked. If you set your bucket to public then AWS is going to decrypt your data on the fly when someone goes to ask for it right?

Or am I missing something?

[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.

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-...

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

Reply on news.ycombinator.com