Gerador de AWS IAM Policy

Policies IAM da AWS a fundo: estrutura, conditions e padrões de menor privilégio

Uma policy IAM é um documento JSON que diz para a AWS quem pode (ou não) fazer o quê, em quais recursos, sob quais condições. Toda chamada de API contra a AWS — de s3:GetObject a ec2:RunInstances — é autorizada pelo motor IAM, que avalia a união de todas as policies anexadas ao principal chamador mais qualquer policy de recurso no alvo.

O modelo mental: tudo é negado por default. Um Allow concede permissão; um Deny explícito sempre ganha, mesmo contra um Allow em outro lugar. Isso torna o Deny poderoso para guardrails (ex: "ninguém fora dos IPs corporativos pode desligar o CloudTrail") mas também complica troubleshooting — uma permissão faltando e um deny explícito parecem iguais do lado cliente.

Anatomia de uma policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "LeituraS3",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::meu-bucket",
        "arn:aws:s3:::meu-bucket/*"
      ],
      "Condition": {
        "IpAddress": { "aws:SourceIp": "203.0.113.0/24" },
        "Bool":      { "aws:MultiFactorAuthPresent": "true" }
      }
    }
  ]
}

Version sempre "2012-10-17" (data em que a lógica de avaliação atual entrou — não existe versão mais nova). Sid é rótulo humano opcional. Effect é Allow ou Deny. Action, Resource e Condition descrevem o quê, em quê e quando.

Actions e ARNs de recurso

Actions seguem o formato service:Operation (case-sensitive). Wildcards são suportados: s3:* significa toda action do S3, s3:Get* significa toda leitura. Cuidado — iam:* em uma policy é, na prática, root.

ARNs de recurso seguem arn:aws:service:region:account-id:resource-type/resource-id. Alguns serviços omitem region e account (ex: S3: arn:aws:s3:::nome-bucket/*). Wildcards funcionam nos ARNs também — arn:aws:s3:::meu-bucket/* casa com todo objeto do bucket mas não com o bucket em si, motivo pelo qual actions de nível bucket como s3:ListBucket precisam de um ARN separado sem o /* final.

Conditions: o poder real

• Operadores: StringEquals / StringLike (wildcard), NumericLessThan, DateGreaterThan, IpAddress, ArnLike, Bool — cada um tem variante ...IfExists para condições opcionais.
• Chaves globais: aws:SourceIp, aws:CurrentTime, aws:PrincipalOrgID, aws:MultiFactorAuthPresent, aws:MultiFactorAuthAge, aws:RequestTag/Env, aws:ResourceTag/Owner.
• Chaves de serviço: s3:prefix, ec2:InstanceType, kms:ViaService, etc. — veja a página IAM de cada serviço.

Padrão favorito: "aws:MultiFactorAuthPresent": "true" para exigir MFA em operações sensíveis; "aws:PrincipalOrgID": "o-abcd1234" para limitar uma policy de recurso só à sua AWS Organization.

Tipos de policy — saiba qual usar

• Identity-based: anexada a user, group ou role. O tipo mais comum.
• Resource-based: anexada diretamente a buckets S3, filas SQS, tópicos SNS, funções Lambda, chaves KMS. Inclui um campo Principal que policies identity-based não têm.
• Permissions Boundary: teto sobre o que uma policy identity-based pode conceder. A permissão efetiva é a interseção.
• SCP (Service Control Policy): aplicada no nível AWS Organizations. Deny-list puro — não concede, só restringe, mesmo para o root da conta.
• Session policy: passada para sts:AssumeRole para apertar ainda mais uma sessão temporária. Usada por ferramentas como aws-vault e federação de CI.

Pegadinhas comuns

• NotAction e NotResource significam "tudo menos". Raramente é o que você quer — fácil conceder demais por acidente.
• Deny explícito sempre sobrescreve Allow. Use em SCPs e policies de recurso como guardrail, não no controle de acesso normal.
• StringLike é case-sensitive — "s3:prefix": "Pictures/*" não casa com pictures/foo.jpg.
• Actions de nível bucket vs nível objeto precisam de ARNs diferentes (com e sem /* no final).
• Wildcards dentro do account-id ou resource-id do ARN funcionam; no segmento de partition ou service, não.

Boas práticas e ferramentas

• Comece com managed policies da AWS para padrões comuns (AmazonS3ReadOnlyAccess, AWSLambdaBasicExecutionRole) — são mantidas pela própria AWS.
• Rode o IAM Access Analyzer para detectar permissões não usadas e acessos externos não intencionais.
• Use o Policy Simulator para validar "esse principal pode fazer essa action?" antes de deployar.
• Auditoria open-source: Cloudsplaining, Parliament, iamlive para capturar as permissões realmente usadas.
• Acesso cross-account: prefira sts:AssumeRole a IAM users com chaves de longa duração. No EKS, use IRSA (IAM Roles for Service Accounts).
• Force MFA em actions perigosas via aws:MultiFactorAuthAge < 3600.

FAQ

Policy identity-based vs resource-based? A diferença é onde mora. Identity-based pendura no user/role/group ("Alice pode ler esse bucket"). Resource-based pendura no recurso ("Esse bucket permite a Alice ler") e tem um campo Principal. As duas são avaliadas juntas em acesso cross-account.

Deny explícito sempre vence Allow? Sim, em todos os contextos. Esse é o motivo de existirem SCPs e permissions boundaries — não concedem, só barram.

Quantas policies um user pode ter? 10 managed policies (anexadas por ARN) mais 10 inline policies por default. O tamanho combinado é limitado a 10.240 caracteres para users/roles. Estourou? Consolide, ou mova lógica para uma resource policy.

Qual o jeito mais seguro de começar a escrever uma policy nova? Comece com o conjunto mínimo de actions que sabe que precisa, deploye com Access Analyzer ligado e deixe ele te dizer o que está sobrando. A ferramenta iamlive também intercepta chamadas SDK durante um teste e emite a policy exata que satisfez tudo.

Posso usar wildcard no campo Principal? Sim, "Principal": "*" torna o recurso público — extremamente perigoso em buckets S3. Combine com "Condition": {"StringEquals": {"aws:PrincipalOrgID": "o-..."}} para restringir à sua org.