I invite you to consider the possibility that even though that’s the case, it’s Amazon’s fault for this design choice and one that can be critiqued especially since metadata disclosure can be paired with other exploits. For example, if I know a bucket name then I know the bucket’s domain name since buckets are by default created open to the public.
There’s no inherent reason for treating metadata as less sensitive and there would be fewer problems if it were treated with the same sensitivity as normal data.
Said another way, some users expect the metadata to be treated sensitively and Amazon’s subversion of this is an Amazon problem not a user problem since this user expectation is rather reasonable.
> Said another way, some users expect the metadata to be treated sensitively and Amazon’s subversion of this is an Amazon problem not a user problem since this user expectation is rather reasonable.
It's an Amazon problem to the extent that they lose business over it. But if people choose to use AWS, despite having different requirements for data security than AWS provides, that is a user problem. At some point the onus is on the user to understand what a tool does and doesn't do, and not choose a tool that doesn't meet their requirements.
S3 buckets were never public by default. From the link you posted:
"...Amazon S3 buckets are and always have been private by default. Only the bucket owner can access the bucket or choose to grant access to other users..."
The feature and announcement you linked was about making active an additional safety feature that would block them becoming public. Even if you intentionally ( or accidentally ) configured them with public access.
The well known accidents in the past, of Facebook or the Pentagon having private data in public S3 buckets, I can only attribute to the modern practices of self-paced learning, skipping videos on Udemy courses or deciding formal training is no longer necessary because I can Google it...
The globally unique names of S3 could be problematic with just the metadata of name.
You could figure out how a company names their S3 buckets. It's subtle, but you could create a bunch of typo'd variants of the buckets and sit around waiting for s3 server logs/cloudtrail to tell you when someone hits one of the objects.
When that happens, you could get the accessing AWS Account # (which isn't inherently private, but something that you wouldn't want to tell the world about), IAM user accessing object, and which object was attempted to be accessed.
Say the IAM user is a role with terribly insecure assume role policy... Or one could put an object where the misconfigured service was looking and it'd maybe get processed.
This kind of attack is preventable but I doubt most people are configuring SCPs to the level of detail you'd need to completely prevent this.
That’s why Amazon recommends the use of the expected owner parameter for S3 operations.
ISTR it’s also possible to apply an SCP that limits S3 reads and writes outside your organization. If not via an SCP then via a permission boundary at the least.
Yep, an SCP can restrict what S3 buckets you can access via IAM.
If you're using a VPC you can deploy a VPC S3 Gateway Endpoint which has a policy document on it, this will restrict which buckets the whole VPC can access no matter what their IAM policy says. This also has the benefit of blocking access using non-IAM methods, like signed URLs or public buckets.
I know because it was one of the key decisions we made with R2 and pushed this point in the community.
The majority of S3 buckets, especially valuable ones, remain created back when it was the default and thus the metadata sensitivity with bucket names remains (and that isn’t the only metadata issue).
There’s no inherent reason for treating metadata as less sensitive and there would be fewer problems if it were treated with the same sensitivity as normal data.
Said another way, some users expect the metadata to be treated sensitively and Amazon’s subversion of this is an Amazon problem not a user problem since this user expectation is rather reasonable.