Hacker News Reader

Comment by kirillzubovsky | Hacker News Reader

Potentially because it was spun 10 years ago while permissions were basic/different/even harder to track, and has since fallen off the wagon?

It seems this incident has reminded Twilio to audit all their access right, which is a net positive.

Actually, imagine you were an employee who wanted to get this done, but couldn't get management approval? This is one way to fix things ... :)

View on HN

For such an important bucket, they should have

a. adopted the resource into a Cloudformation stack & a1. Enabled drift detection.

b. Use an AWS config rule to monitor (appropriate) s3 buckets for any public access.

1. Drift detection is a relatively new feature. 2. CloudFormation was so basic for so long that most AWS professionals don't use it. They use Terraform or a similar, non AWS product.

You're absolutely right, and I think most of us have a hard time a. learning about all of the new features and b. justifying going back and fixing up stuff to adopt the new features, but IMO for such a critical piece of infrastructure it should have been done and the engineers/architects should have been adding that sort of stuff to the backlog or requesting training or asking for resources, etc. For me, that sort of stuff is the only way I can get the green light to go back and refactor.

CloudFormation didn't support importing existing resources until last November. For years you had to let it recreate everything you need, if you hadn't used it from day one. That's a big part of what kept us on Terraform.

> because it was spun 10 years ago while permissions were basic/different/even harder to track, and has since fallen off the wagon?

That's not a AWS problem. That's a "our team failed to manage the service" problem.

This includes monitoring a publicly accessible bucket.

I remember there are AWS settings to set at account level that override permissive bucket level policies

Reply on news.ycombinator.com