Segundo post do Nível Intermediário da série AWS IAM. Você já sabe ler uma policy. Agora vêm as perguntas práticas: onde ela “mora”? Como reaproveitá-la? Como não transformar suas permissões em um emaranhado impossível de manter? Vamos entender os tipos de políticas e quando usar cada um.
📚 O que você vai aprender neste post:
- A diferença entre políticas gerenciadas e inline;
- Quando usar cada tipo, na prática;
- A distinção entre políticas identity-based e resource-based;
- Um exemplo de organização de permissões por função de trabalho;
- Boas práticas para manter tudo sustentável.
Políticas gerenciadas x inline
A primeira grande divisão é sobre como a política existe e é anexada:
🏢 Gerenciada pela AWS
Criada e mantida pela AWS. Prática para começar, mas costuma ser ampla demais.
👤 Gerenciada pelo cliente
Criada por você. Reutilizável, versionada e sob medida. O melhor equilíbrio.
📎 Inline
Incorporada a uma única identidade (1 para 1). Some junto se a identidade for apagada.
As gerenciadas (pela AWS ou pelo cliente) são objetos independentes, com ARN próprio, que podem ser anexados a vários usuários, grupos e roles ao mesmo tempo. Já as inline vivem “dentro” de uma única identidade e não existem fora dela.
Qual usar?
- Na maioria dos casos, use gerenciadas pelo cliente. São reutilizáveis, têm histórico de versões (dá para reverter) e centralizam a manutenção — mude em um lugar, reflete em todos.
- Use as gerenciadas pela AWS para prototipar rápido ou em cenários muito padrão, sempre revisando se não concedem mais do que o necessário.
- Reserve inline para permissões estritamente exclusivas de uma identidade, que não devem, por design, existir em nenhuma outra.
Identity-based x Resource-based
Há uma segunda divisão, sobre onde a política é anexada e a qual pergunta ela responde:
- Identity-based — anexadas a usuários, grupos ou roles. Respondem “o que esta identidade pode fazer?”.
- Resource-based — anexadas diretamente a um recurso (um bucket S3, uma fila SQS, uma chave KMS). Respondem “quem pode acessar este recurso?” e trazem um elemento
Principal. Aprofundaremos no nível avançado, no contexto de acesso entre contas.
🛠️ Mão na massa: permissões por função de trabalho
Suponha uma equipe com três perfis: quem faz deploy, quem só lê logs e quem administra bancos. Uma organização sustentável seria:
- Criar 3 políticas gerenciadas pelo cliente:
deploy-app,leitura-logseadmin-bancos, cada uma com o mínimo necessário. - Criar 3 grupos correspondentes e anexar cada política ao seu grupo.
- Adicionar cada pessoa ao(s) grupo(s) do seu papel.
Quando uma permissão do deploy mudar, você edita uma política e todos do grupo são atualizados automaticamente. Quando alguém troca de função, você só muda os grupos. Nada de reescrever permissões pessoa por pessoa.
✅ Boas práticas de organização
- Crie políticas por função de trabalho e anexe a grupos ou roles.
- Evite anexar permissões diretamente a usuários individuais — prefira grupos.
- Aproveite o versionamento das políticas gerenciadas pelo cliente para reverter mudanças com segurança.
- Revise periodicamente e remova permissões não utilizadas (o Access Analyzer ajuda — tema do nível especialista).
💡 Resumo dos pontos-chave
Prefira políticas gerenciadas pelo cliente, anexadas a grupos/roles por função de trabalho. Reserve inline para o que é exclusivo. Entenda se a política é identity-based (o que a identidade faz) ou resource-based (quem acessa o recurso). Organização hoje é manutenção fácil amanhã.
Limites e higiene de políticas
A AWS impõe alguns limites que influenciam a organização: por padrão, você pode anexar até 10 políticas gerenciadas a uma identidade, e cada policy tem um tamanho máximo em caracteres. Esses limites não são obstáculos — são um empurrão em direção a boas práticas. Se você está esbarrando neles, geralmente é sinal de que as permissões estão fragmentadas demais ou amplas demais, e merecem ser consolidadas em políticas bem pensadas por função.
Uma dica de higiene: nomeie as políticas com um padrão claro (por exemplo, time-ambiente-função, como dados-prod-leitura) e documente o propósito de cada uma na descrição. Meses depois, você e sua equipe vão agradecer por não precisarem abrir o JSON para lembrar o que cada política faz.
Descobrindo permissões realmente usadas
Um aliado precioso na organização de políticas é o IAM Access Advisor (dados de “último acesso a serviços”). Ele mostra, para cada identidade, quais serviços foram de fato acessados e quando. Com essa informação, você identifica permissões concedidas mas nunca utilizadas — fortes candidatas a serem removidas. É a forma mais objetiva de aproximar suas políticas do menor privilégio, sem depender de suposições sobre “o que a pessoa talvez precise”.
Combine isso com revisões periódicas: a cada trimestre, cruze o Access Advisor com as políticas ativas e apare o excesso. Permissões acumulam com o tempo (o chamado “permission creep”), e essa faxina recorrente é o que mantém o ambiente enxuto e auditável.
Políticas como código
Por fim, trate suas políticas como código. Em vez de editá-las manualmente no console, mantenha-as em ferramentas de infraestrutura como código (Terraform, CloudFormation ou CDK), versionadas em repositório e submetidas a revisão por pares. Isso traz histórico completo de mudanças, facilita reverter um ajuste problemático e permite aplicar a mesma política de forma idêntica em várias contas. Gerenciar permissões “no clique” pode ser rápido no início, mas não escala nem deixa rastro auditável — dois requisitos inegociáveis em ambientes sérios.
No próximo post
Fecharemos o Nível Intermediário mostrando, na prática, como usar roles para serviços e aplicações — dando permissões a EC2, Lambda e afins sem nunca expor chaves de acesso. 🚀
Informações sobre o autor
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.