1. O problema: privilégio excessivo é a norma, não a exceção

Nos dois artigos anteriores desta série, vimos como evitar que segredos vazem em texto puro e como bloquear recursos inseguros antes do apply com Policy as Code. Fechamos a série com um problema mais silencioso, porque não gera erro nem alerta: permissões de IAM concedidas com mais alcance do que o necessário. Uma role de aplicação com s3:* quando só precisa de s3:GetObject em um bucket específico. Um usuário de CI com AdministratorAccess porque "assim resolve na hora e ninguém precisa pedir mais permissão depois". Nada disso quebra nada — até o dia em que uma credencial é comprometida, e o raio de ação do atacante é exatamente do tamanho da permissão que ninguém restringiu.

2. Erros comuns de permissão excessiva

  • Actions com wildcard: "Action": "s3:*" ou "Action": "*" em vez de listar exatamente as operações necessárias (s3:GetObject, s3:PutObject).
  • Resources com wildcard: "Resource": "*" quando a intenção real era restringir a um bucket ou prefixo específico.
  • Roles compartilhadas entre serviços diferentes: uma única role "backend-role" usada por várias Lambdas/serviços com necessidades distintas, acumulando permissões de todos ao longo do tempo porque é mais fácil reaproveitar do que criar uma nova.
  • Credenciais de longa duração: access keys de usuário IAM sem rotação, em vez de roles assumidas temporariamente (via sts:AssumeRole) ou identidades federadas (OIDC em pipelines de CI).
  • Permissões concedidas e nunca revisadas: um acesso liberado para resolver um incidente pontual ("dá acesso de admin no S3 pra debugar isso rápido") que nunca é removido depois.

3. Desenhando políticas mínimas: metodologia

Least privilege na prática raramente é "acertar de primeira" — é um processo iterativo:

  1. Comece restritivo, não permissivo. Ao criar uma role nova, liste apenas as actions que o código efetivamente chama, mesmo que isso signifique testar e ajustar algumas vezes até funcionar.
  2. Use os logs de acesso reais para calibrar. Ferramentas como o IAM Access Analyzer (AWS) geram recomendações de política baseadas no uso real registrado em CloudTrail — em vez de adivinhar quais actions são necessárias, você vê quais foram efetivamente chamadas em um período.
  3. Restrinja por Resource, não só por Action. Permitir s3:GetObject em * ainda é privilégio excessivo se a aplicação só precisa de um bucket. Sempre que a API do serviço suportar, especifique o ARN exato.
  4. Adicione condições (Condition) quando possível. Restringir por IP de origem, exigir MFA, ou limitar por tag do recurso são camadas adicionais que reduzem o impacto de uma credencial vazada.

4. Exemplo prático: de permissivo a mínimo

Política de partida, comum em código copiado de um tutorial genérico:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": "*" } ] }

Versão com least privilege, depois de identificar que a aplicação só lê objetos de um bucket específico, sob um prefixo específico:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::app-uploads-prod", "arn:aws:s3:::app-uploads-prod/incoming/*" ], "Condition": { "StringEquals": { "aws:PrincipalTag/environment": "production" } } } ] }

Em Terraform, o mesmo desenho, evitando reescrever o JSON manualmente:

data "aws_iam_policy_document" "app_uploads_read" { statement { effect = "Allow" actions = [ "s3:GetObject", "s3:ListBucket", ] resources = [ aws_s3_bucket.app_uploads.arn, "${aws_s3_bucket.app_uploads.arn}/incoming/*", ] condition { test = "StringEquals" variable = "aws:PrincipalTag/environment" values = ["production"] } } } resource "aws_iam_policy" "app_uploads_read" { name = "app-uploads-read-only" policy = data.aws_iam_policy_document.app_uploads_read.json }

5. Automatizando a auditoria de acessos

Desenhar a política mínima na criação não é suficiente — permissões tendem a acumular ao longo do tempo, e é preciso um processo contínuo para detectar isso:

  • IAM Access Analyzer identifica automaticamente recursos acessíveis por entidades externas à conta (buckets, roles, chaves KMS) e também gera relatórios de "permissões concedidas versus permissões usadas nos últimos 90 dias", apontando o que pode ser removido: 
aws accessanalyzer list-findings \ --analyzer-arn arn:aws:access-analyzer:us-east-1:123456789012:analyzer/default \ --filter '{"status": {"eq": ["ACTIVE"]}}'
  • cloudsplaining, uma ferramenta open source, escaneia políticas IAM de uma conta AWS inteira e sinaliza padrões arriscados (wildcards, privilege escalation, ausência de resource constraints) em um relatório HTML: 
pip install cloudsplaining cloudsplaining download --profile production cloudsplaining scan --input-file default.json --output results/
  • Integrando com o pipeline de IaC: o mesmo conftest/OPA visto no artigo anterior desta série pode avaliar documentos de política IAM gerados pelo Terraform antes do apply, bloqueando qualquer "Resource": "*" combinado com uma action de escrita, por exemplo: 
package terraform.iam deny[msg] { resource := input.resource_changes[_] resource.type == "aws_iam_policy" statement := resource.change.after.policy.Statement[_] statement.Effect == "Allow" statement.Resource == "*" msg := sprintf( "política '%s' usa Resource=\"*\" — restrinja ao ARN específico", [resource.address], ) }

6. Rotação e identidades temporárias

Além de restringir o que uma credencial pode fazer, reduzir por quanto tempo ela é válida limita ainda mais o impacto de um vazamento:

  • Prefira roles assumidas via sts:AssumeRole a usuários IAM com access key fixa sempre que possível.
  • Em pipelines de CI, use OIDC federation (GitHub Actions, GitLab CI já suportam nativamente) para que o pipeline assuma uma role temporária sem nenhuma credencial de longa duração armazenada como secret: 
# GitHub Actions assumindo uma role via OIDC, sem access key fixa permissions: id-token: write contents: read steps: - uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: arn:aws:iam::123456789012:role/github-actions-deploy aws-region: us-east-1

7. Conclusão da série

Segredos guardados corretamente, recursos validados por política antes do apply e permissões desenhadas com o mínimo privilégio necessário são três frentes independentes, mas que se reforçam: um segredo vazado importa menos se a credencial associada tem alcance limitado; uma política de IAM bem desenhada é, ela mesma, um alvo natural de checagem via Policy as Code. Nenhuma automação de infraestrutura está completa sem tratar segurança e governança como parte do pipeline, não como uma revisão manual que acontece (ou não) antes de ir para produção.

Imagem de capa: Logo oficial da HashiCorp, mantenedora do Vault — Wikimedia Commons

Referências:

  1. AWS IAM — Grant Least Privilege
  2. AWS IAM Access Analyzer
  3. cloudsplaining — Documentation