AWS IAM (Roles, Policies, Users)

O AWS IAM (Identity and Access Management) é o serviço que responde, para toda chamada de API na nuvem, duas perguntas: quem está pedindo e o que essa identidade pode fazer. Em produção moderna, a identidade substitui o perímetro de rede como fronteira primária, porque credenciais vazadas atravessam redes privadas sem tocar um único security group. O IAM define usuários, grupos, roles e políticas, e a avaliação combinada desses elementos decide cada requisição, desde o primeiro acesso de um desenvolvedor até o papel assumido por um serviço em runtime. O custo de errar é concreto: uma chave de acesso estática em um repositório público ou uma policy com Action "*" transformam um bug operacional em incidente de segurança com dados expostos. Dominar o modelo de entidades e o algoritmo de avaliação do IAM é, portanto, pré-requisito para operar qualquer carga em AWS com risco controlado.

Identidade como perímetro

Cada chamada de API na AWS carrega um principal: um usuário, uma role assumida ou um serviço agindo em nome de um recurso. A autenticação prova quem é o principal, e a autorização decide se a ação sobre o recurso é permitida. Quando o perímetro físico e de rede é reduzido, como acontece em nuvem, o controle migra para a identidade: o que importa é a credencial, não o endereço de origem. Essa inversão é o fundamento de tudo que o módulo trata depois, do menor privilégio à federação OIDC.

Consequência operacional direta: gestão de identidade é trabalho de engenharia contínua, e não um cadastro feito uma vez. Contas de pessoas entram e saem, serviços nascem e morrem, e toda essa dinâmica precisa refletir no IAM em dias, não em trimestres. Times que tratam o IAM como configuração estática acumulam permissões órfãs que viram o vetor de ataque mais barato de explorar.

Entidades fundamentais

Quatro entidades compõem o modelo e se confundem com frequência entre quem começa:

• User: identidade de uma pessoa ou sistema com credencial permanente, como senha de console ou par de chaves de acesso; deve ser exceção em produção, não regra.
• Group: coleção de users que recebe políticas em comum; permissões nunca devem ser anexadas diretamente ao user quando um group serve.
• Role: identidade assumível e temporária, sem credencial permanente, que qualquer principal confiável pode assumir por meio do STS com credenciais de curta duração.
• Policy: documento JSON que define permissões com Effect, Action, Resource e Condition; é o único lugar onde autorização de fato acontece.

A distinção essencial é entre quem possui credencial e quem a recebe temporariamente. Users autenticam com segredo estático e de longa duração; roles entregam credenciais rotativas assumidas por um principal já autenticado. Policies são o contrato: entities recebem políticas, mas são as políticas que dizem o que é possível.

Role assumível versus credencial estática

A role é o mecanismo central de segurança do IAM moderno. Em vez de gravar uma Access Key em um arquivo de configuração, o workload assume uma role e recebe credenciais temporárias que expiram sozinhas, em minutos ou horas. A troca elimina a classe inteira de incidentes causados por chave estática vazada: não existe segredo de longa duração para vazar, e a rotação é automática pelo STS.

O mecanismo que decide quem pode assumir é a trust policy, um documento separado da permissão que define o principal confiável. Essa separação cria o modelo de delegação: uma role em produção declara que só a pipeline de deploy pode assumi-la, e qualquer outro pedido é negado antes mesmo das permissões serem avaliadas. Em cross-account, o mesmo princípio governa acessos entre contas sem replicar usuários.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SomentePipelineDeDeployPodeAssumir",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:role/deploy-ci" },
      "Action": "sts:AssumeRole"
    },
    {
      "Sid": "ExigeMFAQuandoHumanoAssume",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:role/humano-base" },
      "Action": "sts:AssumeRole",
      "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
    }
  ]
}

Credencial estática sobrevive em poucos cenários legítimos, como integrações legadas de terceiros que não suportam federação. Nesses casos, ela exige rotação agendada, escopo mínimo e vigilância de uso, porque a chave que ninguém revoga é a que aparece vazada em meses seguintes.

Avaliação de uma requisição

Toda chamada passa por um algoritmo determinístico, e conhecê-lo evita horas de depuração de Access Denied:

1. Rejeição por ausência de autenticação: sem principal válido, a chamada termina antes da autorização.
2. Deny explícito vence: se qualquer política em vigor nega a ação, a resposta é negada, sem importar quantos Allows existam.
3. Sem Allow explícito, nega: o modelo é deny por padrão; não existem permissões por omissão.
4. Allow entra em vigor: com ao menos um Allow e nenhum Deny, a ação é permitida.
5. Condições são avaliadas: IPs, MFA, tags, horário e região restringem o Allow dentro da mesma política.

A ordem importa para o desenho: o deny explícito é o instrumento de proteção forte, usado para blindar recursos críticos contra erros de Allow em políticas amplas. Já o deny por omissão significa que adicionar permissão exige ação consciente, o que torna o IAM auditável por natureza.

Permission boundaries

A permission boundary é um teto declarado para a soma de todas as permissões que uma identidade pode receber. A autorização final é a interseção entre as políticas anexadas e a boundary: o que estiver fora dela nunca é permitido, mesmo que alguém anexe uma policy com Action "*". O uso clássico é delegar criação de roles para times de produto sem permitir que esse time se autoconceda acesso a dados sensíveis.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "TetoParaRolesDeTimeDeProduto",
      "Effect": "Allow",
      "Action": ["s3:*", "dynamodb:*", "sqs:*", "logs:*"],
      "Resource": "*"
    }
  ]
}

Anexada como boundary, essa política permite que o time crie quantas roles quiser, mas nenhuma delas alcançará IAM sensível ou KMS de outra aplicação. É o mecanismo que transforma o menor privilégio de princípio aspiracional em limite técnico imposto pelo lado central da plataforma.

Tipos de política e onde vivem

O IAM tem famílias de políticas que se combinam na avaliação, e confundi-las gera decisões erradas de desenho:

• Identity-based: anexadas a user, group ou role, definem o que essa identidade pode fazer; são o tipo mais comum e a base do controle por função.
• Resource-based: anexadas ao recurso, como a policy de um bucket S3 ou de uma chave KMS, definem quem pode agir sobre aquele recurso de qualquer origem.
• Permission boundary: teto para as permissões de uma identidade, avaliado em interseção com as identity-based.
• SCP (Service Control Policy): teto de conta ou OU na organização, avaliado antes de tudo; nada dentro da conta ultrapassa um SCP.
• Session policy: escopo passado no momento do assume-role, que estreita a sessão ainda mais que a role base.

A regra mental para depuração é que os tetos nunca concedem, apenas limitam: SCP e boundary não somam permissão a ninguém, apenas recortam o que as identity-based concederam. Diante de um Access Denied inesperado, a ordem de investigação é SCP, depois boundary, depois deny explícito, depois ausência de Allow.

Aplicação prática e ferramentas

# Simula o que a role da aplicação pode fazer antes de aplicar mudanças
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/api-producao \
  --action-names s3:GetObject s3:PutObject \
  --resource-arns arn:aws:s3:::dados-faturamento/consolidado/*

# Lista políticas anexadas e embutidas de uma role para revisão de acesso
aws iam list-attached-role-policies --role-name api-producao
aws iam list-role-policies --role-name api-producao

# Verifica quando cada credencial estática foi usada pela última vez
aws iam get-credential-report

# Exige MFA para operações sensíveis com negação condicional na policy
aws iam create-policy \
  --policy-name ExigeMFAOperacoesCriticas \
  --policy-document file://exige-mfa.json

O comando simulate-principal-policy é a ferramenta de teste unitário do IAM: ele responde Allowed ou Denied por ação e recurso, inclusive com contexto de condição, antes de a mudança ir para produção. Incorporá-lo ao pipeline de IaC transforma revisão de permissão em teste automatizado em vez de leitura manual de JSON.

Erros comuns

• Root no dia a dia: usar a conta raiz para operações rotineiras; a raiz deve ter MFA de hardware, sem chaves de acesso, e existir apenas para tarefas que só ela executa.
• Usuário por serviço: criar IAM user com chave estática para cada aplicação; o correto é role por workload, com a credencial entregue pelo ambiente de execução.
• Wildcards por preguiça: Action "" e Resource "" em produção para resolver um erro de permissão; o conserto deveria ser a ação exata que faltou.
• Trust policy ampla: aceitar qualquer principal da conta ao criar role, abrindo escalada lateral; o principal confiável deve ser nomeado e condição deve restringir o contexto.
• Permissões sem dono: roles e users de times que saíram continuando ativas; ciclo de vida de identidade precisa estar amarrado ao RH e ao inventário de serviços.
• Ignorar o log de avaliação: operar sem CloudTrail de data events e sem revisão de uso torna impossível apertar permissões com evidência.

Boas práticas em produção

Substitua usuários e chaves estáticas por roles em toda a superfície possível: serviços assumem roles nativamente, humanos assumem roles com MFA e pipelines usam federação, e o IAM vira um sistema de concessões temporárias auditáveis. Organize permissões por função de trabalho em grupos e políticas gerenciadas por time, com número limitado de variantes, para que revisão seja viável.

Aplique boundaries em toda role criada por delegação e exija MFA por condição nas operações destrutivas, como exclusão de recursos e alteração de políticas. Monitore o uso real com CloudTrail e Access Analyzer para encontrar permissões não utilizadas, e agende revisões trimestrais com remoção por padrão. Por fim, teste mudanças de política com simulate-principal-policy no CI, porque permissão errada em produção não falha no deploy: falha na madrugada, quando o incidente já começou.