IAM Especialista #1: A lógica de avaliação de policies — como um pedido é permitido ou negado

Posted by on

Primeiro post do Nível Especialista da série AWS IAM. Vamos abrir a “caixa-preta”: como a AWS decide, para cada requisição, se ela é permitida ou negada? Entender essa lógica em profundidade é o que separa quem configura por tentativa e erro de quem projeta acesso com intenção — e diagnostica um “Access Denied” em minutos.

📚 O que você vai aprender neste post:

  • A ordem de avaliação de uma requisição na AWS;
  • As três regras de ouro (deny padrão, Allow, Deny explícito);
  • Onde a maioria erra ao combinar controles;
  • Um exemplo prático de diagnóstico de “Access Denied”;
  • O poder das Conditions (ex.: exigir MFA).

A ordem de avaliação

Quando uma requisição chega, a AWS reúne todas as políticas aplicáveis (de identidade, de recurso, boundaries, SCPs) e as avalia segundo uma ordem bem definida. De forma simplificada:

  1. Deny explícito? Se qualquer política contém um Deny aplicável, a requisição é negada imediatamente. Fim.
  2. SCPs (Organizations) permitem a ação? Se não, negado.
  3. Resource-based policy concede? Pode permitir por si só em certos casos.
  4. Permission boundary permite? Se existir e não permitir, negado.
  5. Identity-based policy concede um Allow? Se sim, permitido.
  6. Se ninguém concedeu Allow → deny implícito (negado por padrão).

As três regras de ouro

  • Negação por padrão — nada é permitido até que algo conceda explicitamente.
  • Allow explícito — concede a ação (dentro dos limites de boundaries e SCPs).
  • Deny explícito sempre vence — não importa quantos Allow existam, um único Deny aplicável derruba tudo.

Onde muita gente erra

O ponto que mais confunde: uma permissão pode estar concedida na identity-based policy e ainda assim ser bloqueada por uma SCP, uma permission boundary ou uma resource-based policy com Deny. Todos esses “filtros” precisam estar alinhados. A permissão efetiva é a interseção de todos eles, menos qualquer Deny explícito. Quando um acesso que “deveria funcionar” é negado, quase sempre há uma dessas camadas silenciosamente barrando.

🛠️ Mão na massa: diagnosticando um “Access Denied”

Um desenvolvedor jura que tem s3:PutObject na policy, mas recebe “Access Denied”. Roteiro de investigação, na ordem da avaliação:

  1. Há Deny explícito? Procure por statements Deny nas policies da identidade e do recurso (ex.: uma bucket policy que nega quem não usa TLS).
  2. Alguma SCP bloqueia? Verifique as SCPs da conta/OU — talvez o S3 esteja restrito.
  3. Há permission boundary? Se a identidade tiver uma, ela precisa permitir s3:PutObject.
  4. A resource-based policy interfere? A bucket policy pode exigir uma condição (ex.: criptografia).
  5. Rode o IAM Policy Simulator — ele aponta exatamente qual política decidiu.

Na maioria dos casos reais, o culpado é um Deny com Condition (como exigir MFA ou TLS) que o dev não havia notado. Seguir a ordem de avaliação transforma um mistério em um checklist.

O poder das Conditions

As condições refinam a avaliação com contexto: IP de origem, se há MFA, horário, tags do recurso, VPC de origem e muito mais. Um exemplo poderoso — negar qualquer ação que não venha com MFA:

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {
      "aws:MultiFactorAuthPresent": "false"
    }
  }
}

O uso de BoolIfExists aqui é intencional: ele cobre também os casos em que a chave de MFA não está presente no contexto. Combinar Deny com Conditions é uma das técnicas mais elegantes para impor “guardrails” sem microgerenciar cada Allow.

💡 Resumo dos pontos-chave

A AWS avalia cada pedido numa ordem: Deny explícito derruba tudo; depois SCPs, resource-based, boundary e identity-based. Sem Allow, é deny implícito. Use Conditions para guardrails contextuais. Para diagnosticar, siga a ordem de avaliação e use o IAM Policy Simulator.

Explicit deny com condição: o guardrail favorito

Como o Deny explícito vence tudo, ele é a ferramenta preferida para impor regras inegociáveis em toda a organização. Exemplos poderosos incluem negar qualquer ação sem MFA, negar acesso que não venha de uma VPC específica (aws:SourceVpc), negar requisições sem TLS (aws:SecureTransport) ou fora de uma faixa de horário. Como esses Deny “furam” qualquer Allow, eles funcionam como leis que ninguém na conta consegue contornar.

O contraponto é o cuidado: um Deny amplo e mal escrito pode travar operações legítimas de forma difícil de diagnosticar. Por isso, teste no Policy Simulator, use condições precisas e prefira negar comportamentos específicos (sem MFA, sem TLS) a negar serviços inteiros sem necessidade.

Session policies e o quadro completo

Além das camadas já citadas, existe mais um refinamento: as session policies, passadas no momento em que uma role é assumida. Elas reduzem ainda mais as permissões daquela sessão específica, funcionando como um teto temporário. Ferramentas de acesso “just-in-time” usam esse mecanismo para conceder poderes elevados por poucos minutos e, ao final, tudo volta ao normal automaticamente.

O quadro completo da avaliação, então, considera: SCPs, resource-based policies, permission boundaries, identity-based policies e session policies — todas precisam permitir, e nenhum Deny explícito pode existir. Visualizar essas camadas é o que torna o diagnóstico de acessos algo metódico, e não adivinhação.

No próximo post

Vamos falar de Service Control Policies (SCPs) e governança com AWS Organizations — os guardrails que valem para contas inteiras. 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  ·