IAM - identidade e acesso

IAM (Identity and Access Management) é o sistema que decide quem existe no seu ambiente cloud, o que cada um pode fazer e em quais condições. Em vez de um firewall na borda, o controle se distribui por cada chamada de API: cada request carrega uma identidade, e essa identidade é avaliada contra políticas antes de tocar qualquer recurso.

Três peças sustentam tudo: o principal (humano, serviço, workload), a ação que ele quer fazer (s3:GetObject, ec2:TerminateInstance) e o recurso alvo (bucket, instância, função). A resposta é sempre sim ou não, e o motor registra quem pediu o quê, quando e como.

Usuários são identidades persistentes atreladas a alguém (ou a um segredo estático). Roles são identidades assumíveis: em vez de senha, alguém troca de papel via AssumeRole e ganha credenciais temporárias por minutos ou horas. Para workloads, quase sempre é assim: nada de usuário fixo, tudo via role.

Policies são documentos JSON que descrevem permissões. Há três tipos que você encontra o tempo todo: identity policies (anexadas ao principal), resource policies (anexadas ao recurso, como uma bucket policy) e session policies (limites adicionais durante AssumeRole). A avaliação combina todas elas, e basta um único deny explícito para bloquear a ação.

Quando tudo é uma policy, dá para revisar, versionar e testar o acesso como código. Quando metade é um clique no console e a outra metade é um JSON colado no Slack, o caos aparece no primeiro incidente.

A política abaixo é o anti-padrão clássico: admin com tudo para qualquer recurso. Aparece toda semana em algum workshop e em metade dos incidentes de bucket público da internet.

Mesmo um job simples raramente precisa de tudo. Esta política concede apenas a leitura do bucket certo, na região certa, com um condition que limita a origem a uma role específica:

Toda role tem duas pontas. A primeira é a trust policy, que define quem pode chamar sts:AssumeRole. A segunda é a permission policy, que define o que o assumir ganha. Misturar as duas é onde nascem os incidentes de escalonamento: a role permite s3:* em qualquer lugar, e a trust aceita Principal: "*", então qualquer conta autenticada entra.

A boa trust policy nomeia contas, serviços e até condições externas (MFA, hora do dia, federated provider). Quando você vê "Principal": "*" sem Condition explícita, vale parar e perguntar por quê.

Permission boundaries funcionam como um teto: a permissão efetiva de um principal é a interseção entre o que a boundary permite e o que a identity policy permite. É a ferramenta padrão para dar autonomia a times sem abrir mão do controle central.

Na prática, você define uma boundary por equipe ou ambiente (produção, staging) e deixa o time escrever as identity policies dentro desse envelope. O desenvolvedor pode abrir o leque o quanto quiser, mas nunca passa do teto.