News for hackers. Stuff that matters.
Re:Why Amazon S3 server side encryption (SSE-S3) is misleading by theteapot on Monday January 16, 2023 @03:08PM (#34404912)
> If you don't have access to the key, then reading the S3 object doesn't work.

I'm still not convinced. Just seem like theater. S3 has its own access control. If you don't have access to the S3 object then reading the S3 object doesn't work ... Requiring additional access to the key seems redundant - theater.

P.S. I'm not arguing against encryption at rest. I'll take it, but using my own key doesn't seem to offer too much over using one of AWS's rel low level access.

Re:Why Amazon S3 server side encryption (SSE-S3) is misleading by colmmacc on Monday January 16, 2023 @04:03PM (#34405430)
AWS isn't monolithic internally and we use permissions boundaries between systems like S3 and KMS (in fact they are mediated by IAM). There's some more detail in my talk from re:Invent - https://www.youtube.com/watch?v=kNbNWxVQP4w .

For a case like this, the upshot of it is that with permissions on the KMS key, S3 is effectively locked out and can't fetch it. KMS is a hermetic system with no operator access with HSMs at its root, so that provides a pretty meaningful difference. It also means that controls can be handled by different customer teams, and that a single change on a shared CMK can render an unbounded number of S3 objects inaccessible quickly.

Re:Why Amazon S3 server side encryption (SSE-S3) is misleading by theteapot on Monday January 16, 2023 @05:16PM (#34406181)
Useful. Thanks.

> KMS is a hermetic system with no operator access with HSMs at its root, so that provides a pretty meaningful difference.

So, if I don't use a CMK (Customer Managed Key), what am I getting instead? Assumed (perhaps naively) KMS would still be used under the hood.

> a single change on a shared CMK can render an unbounded number of S3 objects inaccessible quickly.

I feel like you could achieve that with an IAM policy. I guess the key can apply to a wide range of unrelated AWS services so act like a ~meta policy. Seems useful.

Re:Why Amazon S3 server side encryption (SSE-S3) is misleading by colmmacc on Monday January 16, 2023 @07:24PM (#34407494)
If you use the default AWS managed key rather than a CMK, it's largely the same levels of protection and the main difference is that you don't control the rotation schedule of the top-level key.

And yep, a CMK can span many services and still give you a single point of control.

But compliance is still the major thing. Many regulators, auditors and compliance authorities are just happier with KMS being the point of control. Even though AWS operates KMS, and the services, KMS is a neat compartmentalized hermetic system with HSMs at its root. So it's quicker and neater to evaluate its surface area, TCB, and so on and it's a familiar pattern to finance and health regulators especially.

Re:Why Amazon S3 server side encryption (SSE-S3) is misleading by aborsy on Tuesday January 17, 2023 @02:29AM (#34410010)
Default keys don’t allow policies if I recall. No access control.
Re:Why Amazon S3 server side encryption (SSE-S3) is misleading by paranoidrobot on Wednesday January 18, 2023 @12:54AM (#34423837)
You can't set a Key policy, but you control access via the IAM Policy associated with the caller.
Re:Why Amazon S3 server side encryption (SSE-S3) is misleading by paranoidrobot on Monday January 16, 2023 @05:04PM (#34406063)
It's protection against mistakes where you've accidentally granted more access than was intended.

For instance, if someone does a wildcard resource "acme-prod-widget-*" for a new policy, but forgets that widget also has (say) a customer-pii bucket, too.

Well, if acme-prod-widget-customer-pii is encrypted with a customer-pii specific KMS key, then there's no accidental leak of that data.