3 ms·

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 inc

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

lozenge 6y ago
I remember there are AWS settings to set at account level that override permissive bucket level policies
fimbulvetr 6y ago
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.
- stevehawk 6y ago
  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.
  - erik_seaberg 6y ago
    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.
  - fimbulvetr 6y ago
    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.
rumanator 6y ago
> 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.

lozenge 6y ago

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

fimbulvetr 6y ago

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.

stevehawk 6y ago
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.
- erik_seaberg 6y ago
  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.
- fimbulvetr 6y ago
  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.

rumanator 6y ago

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