Zero Trust e IAM Avançado na AWS: Como Reduzir a Superfície de Ataque na Nuvem

Eduardo Souza | CEO Dominit

A maioria das violações de segurança na nuvem não acontece porque um invasor “quebrou” a AWS — acontece porque alguém, em algum momento, deu a uma aplicação ou usuário mais permissão do que ele realmente precisava. Zero Trust é a resposta arquitetural a esse problema: parar de confiar implicitamente em qualquer identidade, dentro ou fora do perímetro de rede, e verificar explicitamente cada solicitação de acesso. Neste guia avançado, você vai entender o que Zero Trust significa na prática dentro da AWS, como estruturar IAM seguindo o princípio do menor privilégio, e os erros de permissão mais comuns que uma auditoria de segurança revela.

O Que Zero Trust Significa na Prática, Não Só como Conceito

Zero Trust não é um produto que se compra — é um modelo arquitetural definido formalmente pelo NIST que parte de uma premissa simples: nenhuma solicitação de acesso é confiável por padrão, independente de estar “dentro” ou “fora” da rede corporativa. Cada solicitação precisa ser autenticada, autorizada e continuamente validada, não apenas verificada uma vez na entrada.

Na prática dentro da AWS, isso significa abandonar o modelo antigo de “tudo dentro da VPC é confiável” e passar a verificar identidade e contexto (quem está pedindo, de onde, com qual dispositivo, para fazer o quê) em cada camada — não só na borda da rede.

O Princípio do Menor Privilégio: a Base de Qualquer Estratégia Zero Trust

O princípio do menor privilégio é simples de enunciar e difícil de manter na prática: cada identidade (usuário, aplicação, serviço) deve ter apenas a permissão mínima necessária para realizar sua função, nada além disso. O problema não é a teoria — é que sob pressão de prazo, é sempre mais rápido dar permissão ampla (“AdministratorAccess”, por exemplo) do que desenhar uma política granular específica, e essa permissão ampla raramente é revisada depois que o prazo passa.

Ferramentas nativas da AWS ajudam a fechar essa lacuna: IAM Access Analyzer identifica recursos compartilhados com entidades externas à conta e gera políticas de menor privilégio com base no uso real observado; Access Advisor mostra quais permissões concedidas a uma role ou usuário realmente foram usadas nos últimos meses, revelando o que pode ser removido com segurança.

AWS IAM Identity Center: Identidade Centralizada em Ambientes Multi-Conta

Empresas com múltiplas contas AWS enfrentam um problema adicional de identidade: gerenciar usuários e permissões separadamente em cada conta não escala e cria inconsistência de segurança entre elas. O AWS IAM Identity Center resolve isso centralizando autenticação e concedendo acesso temporário e federado a múltiplas contas a partir de uma única identidade — em vez de credenciais de longa duração espalhadas por dezenas de contas.

Isso também viabiliza integração com um provedor de identidade corporativo já existente (Azure AD, Okta, Google Workspace), permitindo que o controle de acesso à AWS siga o mesmo ciclo de vida de identidade usado para o resto dos sistemas da empresa — quando alguém sai da empresa, o acesso à AWS expira junto com o resto, sem depender de um processo manual separado.

Roles Temporárias vs Credenciais de Longa Duração

Um dos indicadores mais confiáveis de maturidade de segurança em uma conta AWS é a proporção entre credenciais de longa duração (access keys de usuário IAM, que não expiram sozinhas) e roles temporárias (que expiram automaticamente após um período curto):

Credenciais de longa duração — permanecem válidas até serem revogadas manualmente, o que significa que uma chave vazada continua sendo um risco até alguém perceber e agir. São o tipo de credencial mais frequentemente encontrado em repositórios de código por engano, exatamente por não expirarem sozinhas.

Roles temporárias (via STS) — geram credenciais que expiram automaticamente em minutos ou horas, reduzindo drasticamente a janela de exposição em caso de vazamento acidental. É o modelo recomendado para aplicações, pipelines de CI/CD e qualquer acesso automatizado.

A migração de credenciais de longa duração para roles temporárias, sempre que tecnicamente possível, é uma das mudanças de maior impacto por esforço relativo numa auditoria de segurança — muitas vezes mais eficaz do que adicionar camadas adicionais de monitoramento sobre credenciais que não deveriam existir daquela forma.

Segmentação e Guardrails: Zero Trust Além do IAM

Zero Trust não se limita a permissões de identidade — segmentação de rede e guardrails organizacionais são a outra metade da equação:

Service Control Policies (SCPs) — aplicadas via AWS Organizations, definem o teto máximo de permissão possível para todas as contas de uma unidade organizacional, independente do que uma política IAM individual permita — uma camada de guardrail que nenhuma configuração local de conta consegue contornar.

Segmentação de rede alinhada a domínios de confiança — a arquitetura de VPC e Transit Gateway de uma empresa deveria refletir domínios de confiança diferentes (produção, desenvolvimento, dados sensíveis), não assumir que tudo dentro da mesma rede corporativa merece o mesmo nível de acesso.

Autenticação multifator obrigatória — especialmente para ações privilegiadas (mudança de política IAM, acesso a dados sensíveis), reduzindo o risco de uma única credencial comprometida resultar em acesso irrestrito.

Erros Comuns de IAM Que uma Auditoria de Segurança Revela

Os mesmos padrões de permissão excessiva aparecem repetidamente, independente do porte da empresa:

Uso de políticas gerenciadas amplas em vez de políticas customizadas — políticas como “PowerUserAccess” concedidas por conveniência, quando a aplicação real usa uma fração pequena dessas permissões.

Roles compartilhadas entre múltiplas aplicações — quando uma role é usada por várias cargas de trabalho diferentes, revogar ou ajustar sua permissão vira uma operação arriscada, porque ninguém tem certeza de tudo que depende dela.

Ausência de revisão periódica de acesso — permissões concedidas para um projeto específico que nunca são removidas depois que o projeto termina, acumulando superfície de ataque desnecessária ao longo do tempo.

Permissões amplas em clusters de containers — o mesmo problema que já cobrimos no guia de Amazon EKS: pods herdando a permissão do nó inteiro em vez de uma permissão granular por aplicação via IRSA ou Pod Identity.

Uma revisão Well-Architected no pilar de Segurança é o mecanismo formal mais indicado para capturar sistematicamente esse tipo de dívida técnica antes que ela seja explorada.

Como Estruturar uma Transição para Zero Trust Sem Parar a Operação

Migrar uma conta AWS já em produção para um modelo mais próximo de Zero Trust é um processo gradual, não uma mudança de uma vez:

Comece pelo inventário real de permissões concedidas, usando IAM Access Analyzer e Access Advisor para entender o que existe hoje antes de decidir o que remover.

Priorize identidades com maior superfície de risco — credenciais de longa duração com permissão ampla, especialmente as menos usadas, antes de tentar refinar toda política granularmente de uma vez.

Implemente SCPs como guardrail antes de refinar políticas individuais — um guardrail organizacional amplo reduz risco imediatamente, enquanto o refinamento de políticas específicas acontece em paralelo, sem bloquear operação.

Trate isso como processo contínuo, não como projeto com data de término — permissão excessiva se acumula naturalmente ao longo do tempo; revisão periódica precisa ser rotina, não evento único.

Perguntas Frequentes Sobre Zero Trust e IAM na AWS

Zero Trust significa não confiar em nenhum usuário da empresa?

Não é sobre desconfiar de pessoas — é sobre não conceder acesso por padrão só porque uma solicitação vem de “dentro” da rede corporativa. Cada solicitação de acesso é verificada com base em identidade e contexto, não em localização de rede.

Qual a diferença entre AWS IAM tradicional e AWS IAM Identity Center?

IAM tradicional gerencia usuários e permissões dentro de uma única conta; IAM Identity Center centraliza identidade e acesso federado através de múltiplas contas AWS, essencial para ambientes com AWS Organizations.

Por que credenciais de longa duração são mais arriscadas?

Porque permanecem válidas indefinidamente até serem revogadas manualmente — se vazarem (por exemplo, em um repositório de código), o risco persiste até alguém perceber, ao contrário de credenciais temporárias que expiram sozinhas.

O que são Service Control Policies e por que importam?

São guardrails aplicados no nível organizacional via AWS Organizations, definindo o teto máximo de permissão possível para contas inteiras — nenhuma política IAM local pode ultrapassar esse limite, o que os torna uma proteção mais forte que políticas individuais.

Por onde uma empresa deve começar a implementar Zero Trust na AWS?

Pelo inventário real de permissões concedidas versus permissões realmente usadas, usando ferramentas nativas como IAM Access Analyzer — a maior parte do ganho de segurança vem de eliminar acesso excessivo já existente, antes de adicionar controles novos.

Zero Trust Como Prática Contínua de Redução de Superfície de Ataque

Zero Trust na AWS não é uma configuração que se aplica uma vez e se considera resolvida — é uma disciplina contínua de questionar constantemente se cada identidade, aplicação e conexão de rede realmente precisa do acesso que tem. O princípio do menor privilégio é simples de entender e trabalhoso de manter, exatamente por isso a maioria das contas AWS acumula permissão excessiva ao longo do tempo, não por decisão consciente, mas por acúmulo silencioso.

As empresas que tratam revisão de IAM como rotina — não como reação a um incidente de segurança — são as que efetivamente reduzem sua superfície de ataque, em vez de apenas documentá-la.