* IAM policies for deployed applications should be kept with those applications * Use a feature like GitHub's CODEOWNERS to make sure that the service's IAM po

* IAM policies for deployed applications should be kept with those applications * Use a feature like GitHub's CODEOWNERS to make sure that the service's IAM policies "belong" to your infosec team. Any PRs that attempt to change the IAM policy are then reviewed and approved by infosec. * Set up monitoring that alerts when IAM policy is deployed that is too broad (i.e. wildcards). * Eventually, recognize that many of your applications are pretty similar, and move to a smarter deployment model which maps a type of service to the correct IAM policy to be deployed with it. Then, what's stored in the service's code repository is which kind of application it is, and the IAM policies are factored out into a common repository owned by infosec. Look, IAM isn't hard. Allow, deny, verbs, resources, it's all pretty simple. Not so different from firewall rules we've had for decades now. What's difficult is managing, not IAM rules specifically, but anything at scale. Managing security at scale is hard, because managing anything at scale is hard. What's more difficult is taking legacy setups which already exist at scale, are poorly secured because they weren't set up with the correct tooling to manage them at scale, and migrating them to a standards-based approach that makes it possible to manage them at scale. What makes it difficult isn't the technology but the organizational politics that comes with it. If you build it too early, you're over-engineering and focusing on the wrong thing when there's more "important" stuff to focus on. If you build it too late, then you need to migrate stuff onto it, stuff which "just worked", whose stakeholders ascertain too much risk to the transition, in environments which generally undervalue security work. What makes it difficult is politics.