Uma empresa usa o AWS Organizations e planeja adicionar cerca de 1.000 contas a mais. Atualmente, apenas a equipe central de segurança pode criar funções do IAM. Para reduzir gargalos, as equipes de aplicação precisam provisionar suas próprias funções do IAM, mas as funções devem ter escopo restrito e não devem permitir escalonamento de privilégios. Qual é a solução com o menor overhead operacional?

A solução correta, criar uma SCP e um IAM permissions boundary, é a que oferece menor overhead operacional. A SCP, anexada à OU raiz, pode exigir que todas as novas funções do IAM tenham um permissions boundary específico anexado. Este permissions boundary, por sua vez, restringe as permissões máximas que a função pode ter, impedindo escalonamento de privilégios. Isso permite que as equipes de aplicação criem suas próprias funções de forma autônoma, sem a necessidade de aprovação manual da equipe de segurança para cada criação, reduzindo gargalos. As outras opções são menos eficientes: Criar grupos e usuários IAM para cada equipe e usar RBAC não resolve o problema de escalonamento de privilégios e ainda exige que a equipe de segurança crie e gerencie esses recursos. Delegar a criação de funções com revisões trimestrais ainda introduz um gargalo e não garante a conformidade em tempo real. Colocar cada conta em sua própria OU com SCPs para serviços permitidos é uma boa prática de segurança, mas não aborda diretamente a restrição de permissões para funções IAM criadas pelas equipes de aplicação, nem o problema de escalonamento de privilégios de forma granular como um permissions boundary.