Escalada de privilégios no AWS IAM: defesa em camadas
A escalada de privilégios no AWS IAM ocorre quando um atacante que comprometeu uma credencial de baixo privilégio combina permissões IAM mal configuradas para assumir controle administrativo da conta. Pesquisa da Rhino Security Labs documentou 21 métodos de escalada de privilégios no AWS IAM que permitem a um invasor elevar-se de uma conta comprometida de baixo privilégio para privilégios administrativos totais, e a maioria depende apenas de permissões legítimas concedidas em excesso. A defesa efetiva combina três controles aplicados em camadas: SCPs no AWS Organizations, permission boundaries no IAM e Block Public Access no S3. Em ambientes multi-conta, a falta dessas camadas torna um único vazamento de credencial um incidente de conta inteira.
Como nasce a escalada IAM
Escalada de privilégios não exige vulnerabilidade de software; depende de permissões concedidas em excesso e encadeadas sem intenção. Um atacante com a permissão iam:CreatePolicyVersion pode criar uma nova versão de uma política IAM com permissões administrativas e marcá-la como padrão usando o flag –set-as-default, sem precisar da permissão iam:SetDefaultPolicyVersion. O resultado é controle total da conta a partir de uma única permissão aparentemente banal. Esse padrão se repete em dezenas de ações IAM: a permissão isolada parece inofensiva, mas vira trampolim quando combinada com outra.
Os caminhos de escalada mais explorados
A Rhino Security Labs lista vetores que vão da criação de chaves de acesso de terceiros ao sequestro de funções via EC2. O caminho que combina iam:PassRole com ec2:RunInstances permite que um atacante crie uma instância EC2, anexe um instance profile alheio e extraia credenciais temporárias do metadata service, herdando todas as permissões da função anexada. Outro vetor recorrente envolve perfis de login: um atacante com iam:CreateLoginProfile pode criar senha de console para qualquer usuário sem perfil. Com iam:UpdateLoginProfile, pode redefinir a senha de usuários já existentes, assumindo identidades privilegiadas pela interface web sem precisar de credenciais de API. Há ainda o vetor iam:CreateAccessKey, que gera um novo par de credenciais para um usuário privilegiado.
Guardrails que limitam permissões
O AWS oferece dois guardrails que reduzem o impacto de uma credencial comprometida. As Service Control Policies do AWS Organizations definem o teto máximo de permissões para usuários e funções das contas membro; a documentação oficial é categórica ao afirmar que as SCPs não concedem permissões, apenas estabelecem o limite máximo que a política baseada em identidade pode outorgar. As permissões efetivas resultam da interseção lógica entre o permitido pelo SCP e pelas políticas baseadas em identidade e em recurso, o que significa que mesmo uma política permissiva não ultrapassa o guardrail. Há uma ressalva operacional importante: as SCPs não afetam usuários ou funções da conta de gerenciamento, o que significa que o root administrativo da organização permanece fora do guardrail e exige proteção separada. No nível da entidade, as permission boundaries agem como segundo teto: uma política gerenciada atrelada ao usuário ou função define o máximo que ele pode efetivamente fazer, mesmo que uma política baseada em identidade autorize mais. A regra de avaliação final é que uma negação explícita em qualquer tipo de política resulta na negação do pedido, o que torna permission boundaries uma trava confiável contra escalada.
Bloqueando a exposição de buckets S3
O S3 é alvo clássico porque erros de configuração expõem dados sem precisar de credencial. A AWS introduziu o recurso S3 Block Public Access para inverter o problema: por padrão, novos buckets, access points e objetos não permitem acesso público. O recurso sobrepõe políticas de bucket, permissões de objeto e políticas de access point. É possível gerenciar Block Public Access em múltiplos níveis: organização via AWS Organizations, conta, bucket e access point, garantindo que buckets criados por qualquer desenvolvedor já nasçam blindados. Como controle complementar, o Amazon Macie descobre dados sensíveis, oferece visibilidade sobre riscos de segurança de dados e permite automatizar a proteção contra esses riscos.
Roteiro de hardening do IAM
A AWS recomenda não anexar SCPs à raiz da organização sem testar o impacto primeiro; o caminho seguro é criar uma OU de teste, mover contas em pequenos lotes e usar o dado de serviço acessado por último no IAM e o CloudTrail para validar antes de expandir. O roteiro prático abaixo aplica essa lógica a uma conta que precisa blindar IAM e S3:
- Ative SCPs no AWS Organizations e crie uma OU piloto antes de aplicar na raiz.
- Defina um SCP de deny list que bloqueie iam:CreatePolicyVersion, iam:SetDefaultPolicyVersion, iam:CreateLoginProfile e iam:CreateAccessKey fora de papéis administrativos.
- Anexe permission boundaries a todas as funções de aplicação, limitando o escopo de serviços e recursos.
- Ative S3 Block Public Access no nível da organização para que buckets novos já nasçam protegidos.
- Revise permissões com IAM Access Analyzer, que oferece visibilidade e recomendações para remediar acessos não usados.
| Controle | Escopo | O que bloqueia |
|---|---|---|
| SCP | Organização e contas membro | Teto máximo de ações por serviço |
| Permission boundary | Entidade IAM | Excesso concedido por política de identidade |
| S3 Block Public Access | Conta, bucket e access point | Exposição pública de objetos |
Para aprofundar o modelo de menor privilégio, consulte o guia de IAM best practices; para fechar o ciclo de descoberta de dados expostos, leia sobre DSPM. Nenhuma camada resolve o problema sozinha: SCPs limitam o teto organizacional, permission boundaries travam a entidade e Block Public Access elimina o vetor mais barato de exposição de dados.