They also default to encrypting objects now.<p><a href="https://aws.amazon.com/blogs/aws/amazon-s3-encrypts-new-objects-by-default/" rel="nofollow">https://aws.amazon.com/blogs/aws/amazon-s3-encrypts-new-obje...</a>
I wrote a blog detailing what this change means on S3 ACLs and Block Public Access on by default: <a href="https://www.cloudquery.io/blog/finding-enabled-s3-acls-and-disabled-s3-block-public-access" rel="nofollow">https://www.cloudquery.io/blog/finding-enabled-s3-acls-and-d...</a>
What is the alternative to ACLs? Or is reading from users / roles in the same project supported by default, provided the user / role has the required permissions?
Thankfully I’ve never been charged with keeping any serious PII in an S3 bucket, because the permissions have always worried me, and I’d probably be considered an expert with IAM policies.<p>Thankfully with S3 it’s getting easier and easier to do the right thing. I’m glad for the S3 team moving in this direction.
What is funny is that although they have been phasing out S3 ACLs for years, they are still using it for their own products. For example, Control Tower uses S3 ACLs to secure access to S3 buckets with logs.
Given how many major data breaches have been the result of unintentional public access to orgaanizations' data on S3, I almost think Amazon should remove all public access to buckets and objects from the entire S3 product.<p>Instead make all access to S3 be through credentialed access or signed URLs. If users need to expose an entire bucket to the public Internet, make them go to the effort to put a service in front of the bucket.<p>Yes, this would be a huge change. But playing with the default values for S3 seems like too little, too late.