IAM Intermediário #1: Anatomia de uma policy JSON — Effect, Action, Resource e Condition

Posted by on

Primeiro post do Nível Intermediário da série AWS IAM. Chegou a hora de abrir o “motor” das permissões: a policy JSON. Depois deste post, aquele documento cheio de chaves e colchetes vai fazer todo o sentido — e você vai conseguir ler e escrever permissões com intenção, não por tentativa e erro.

📚 O que você vai aprender neste post:

  • A estrutura de uma policy e seus Statements;
  • Os elementos-chave: Effect, Action, Resource, Principal e Condition;
  • Como ler e montar um ARN;
  • Um exemplo prático de refinar uma permissão ampla demais;
  • A regra de ouro Allow x Deny e como testar antes de aplicar.

A estrutura de uma policy

Uma policy é um documento JSON com um campo Version (use sempre "2012-10-17", a versão atual da linguagem) e um ou mais Statements (declarações). Cada statement é uma regra independente e responde a algumas perguntas essenciais. Veja um exemplo completo:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PermitirLeituraBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::relatorios-financeiro",
        "arn:aws:s3:::relatorios-financeiro/*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

Os elementos-chave

  • Sid (opcional) — um identificador para você organizar e referenciar o statement.
  • Effect — Allow (permitir) ou Deny (negar). É o veredito do statement.
  • Action — quais operações, no padrão serviço:Operação, como s3:GetObject ou ec2:StartInstances. Aceita curingas (s3:Get*), mas use com parcimônia.
  • Resource — sobre quais recursos, identificados pelo ARN. Delimita onde a ação vale.
  • Principal — quem (usado em policies baseadas em recurso e em trust policies; não aparece em policies de identidade).
  • Condition (opcional) — sob quais circunstâncias. No exemplo, só permite se a origem for uma faixa de IP específica.

Entendendo o ARN

O ARN (Amazon Resource Name) é o endereço único de um recurso na AWS. Sua estrutura geral é:

arn:aws:servico:regiao:conta:recurso

Alguns serviços (como o S3) omitem região e conta, porque o nome do bucket já é globalmente único. Repare, no exemplo anterior, que precisamos de dois ARNs para o S3: um para o bucket (arn:aws:s3:::relatorios-financeiro, usado por s3:ListBucket) e outro para os objetos dentro dele (.../*, usado por s3:GetObject). Confundir os dois é um erro clássico. Dominar ARNs é o que permite restringir permissões a recursos específicos, em vez de liberar tudo.

Allow, Deny e a regra de ouro

  • Tudo é negado por padrão (implicit deny).
  • Um Allow explícito libera a ação.
  • Um Deny explícito sempre vence, sobrepondo qualquer Allow.

Guardaremos essa lógica para aprofundar no nível especialista, mas já vale internalizá-la: quando duas regras entram em conflito, o Deny prevalece — sempre.

🛠️ Mão na massa: do “amplo demais” ao menor privilégio

Imagine que um desenvolvedor pediu “acesso ao S3” e alguém aplicou a permissão mais preguiçosa possível:

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

Isso concede todas as ações do S3 em todos os buckets da conta — incluindo apagar dados de produção. Sabendo que o dev só precisa ler um bucket específico, refinamos para:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::app-uploads",
        "arn:aws:s3:::app-uploads/*"
      ]
    }
  ]
}

Mesma necessidade atendida, risco drasticamente menor. Esse exercício de “estreitar” Action e Resource é o coração do trabalho diário com policies.

⚠️ Erros comuns

  • Usar "Resource": "*" sem necessidade — libera a ação em todos os recursos.
  • Abusar de curingas em Action (s3:*) quando bastariam duas ou três ações.
  • Esquecer o /* no ARN do S3 — permissões sobre o bucket e sobre os objetos são coisas diferentes.
  • Copiar policies da internet sem revisar — muitas são propositalmente permissivas para “só funcionar”.

💡 Resumo dos pontos-chave

Uma policy é um JSON com Statements. Cada um define Effect, Action, Resource e, opcionalmente, Condition. O ARN endereça o recurso — cuidado com bucket vs. objetos. E lembre: negado por padrão, Allow libera, Deny sempre vence. Sempre teste no IAM Policy Simulator antes de aplicar.

Múltiplos statements e ordem de leitura

Uma policy pode conter vários statements, e é comum combiná-los: um que concede um conjunto amplo de leituras e outro que nega explicitamente uma ação sensível. A ordem em que você escreve os statements não importa para a avaliação — a AWS considera todos e aplica a regra de que o Deny sempre vence. O que muda é a legibilidade para humanos, então mantenha uma organização clara, use Sid descritivos e agrupe statements por intenção.

Outro ponto útil: variáveis de política, como ${aws:username}, permitem escrever regras genéricas que se adaptam a cada identidade — por exemplo, dar a cada usuário acesso apenas à sua própria “pasta” dentro de um bucket. É um recurso avançado que economiza dezenas de policies quase idênticas.

No próximo post

Vamos comparar políticas gerenciadas vs. inline: quando usar cada tipo, as vantagens das gerenciadas pela AWS e como organizar permissões de forma sustentável. Até lá!

Informações sobre o autor

Dennis Silva

Dennis Silva atua com Segurança da Informação e Cibersegurança há +18 anos e iniciou sua carreira em uma das Big Four em auditoria de sistemas.

Atualmente, atua como Consultor de Cibersegurança no time de Professional Services da AWS na América Latina (Brasil), função que exerce há mais de 4 anos, com foco no atendimento a instituições financeiras.

Trabalhou como Coordenador de Segurança da Informação na maior empresa de desenvolvimento de software na América Latina. Anteriormente, atuou como consultor de Segurança da Informação, com foco em identificar e avaliar os riscos inerentes ao negócio e validar os controles existentes por meio de testes de invasão em infraestrutura interna/externa, aplicações Web e ERPs como SAP e TOTVS.

Foi responsável pela implementação da certificação ISO/IEC 27001:2013 na maior empresa de desenvolvimento de software da América Latina, potencializando a principal oferta de comercialização de software como serviço (SaaS) em datacenter próprio.

Posted in Cloud  ·