Playbook: Zero-Trust na AWS do Zero: 6 Passos que Cabem num Sprint
cerca de 11 min · áudio gerado ao tocar
A maioria das brechas em ambientes AWS não começa por falha criptográfica, começa por confiança implícita: 'está na VPC, então pode'. Este playbook desmonta essa premissa em seis passos executáveis num único sprint, entregando identidade forte, menor privilégio real e auditoria que detecta antes de virar incidente.
O que você vai conseguir decidir e fazer
Contexto do Playbook
- Domínio
- AWS / Segurança de Plataforma
- Tipo
- Playbook acionável, guia de decisão e passo a passo
- Escopo
- Workloads AWS em qualquer estágio, startups a enterprise
- Premissa de tempo
- Passos 1 e 2 em 1–3 dias; todos os 6 em um sprint de 2 semanas
- Serviços AWS centrais
- IAM, IAM Identity Center, STS, KMS, PrivateLink, VPC Security Groups, CloudTrail, GuardDuty, Security Hub
- Custo estimado de baseline
- CloudTrail (trilha de eventos de gestão): gratuito para primeira trilha por região; GuardDuty: ~$1–4/GB de logs analisados (estimativa); KMS: $1/chave/mês + $0,03/10k requisições
- Quando NÃO aplicar este playbook inteiro de uma vez
- Ambientes de sandbox/experimentação sem dados sensíveis, o overhead de governança não compensa
O modelo mental que desbloqueia tudo: autentique a requisição, não a rede
O modelo de segurança de perímetro tradicional pressupõe que tudo dentro da rede é confiável. Na AWS, isso se traduz em: 'está na mesma VPC, então pode chamar esse serviço'. Esse pressuposto é o vetor de ataque mais explorado em ambientes cloud, não porque a VPC seja insegura, mas porque ela nunca foi projetada para ser o único controle de acesso.
Zero-trust inverte a lógica: a rede é hostil por definição. Cada requisição precisa provar identidade, ser autorizada por política explícita e ser registrada. A VPC vira um detalhe de roteamento, não uma fronteira de segurança.
Na prática, isso significa três mudanças de mentalidade:
- Identidade substitui localização de rede. Um pod Kubernetes, uma função Lambda ou uma instância EC2 não é confiável porque está num subnet privado, é confiável porque apresentou uma credencial verificável (token OIDC, role IAM assumida via STS) e essa credencial foi autorizada por política explícita.
- Menor privilégio não é 'remover o admin'. É modelar o que cada identidade precisa fazer e nada além. Um serviço que lê objetos do S3 não precisa de
s3:*, precisa des3:GetObjectem um ARN específico. A diferença entre os dois é a diferença entre um incidente contido e uma exfiltração completa.
- Auditoria não é compliance, é detecção. CloudTrail registrando tudo sem ninguém lendo não é zero-trust, é teatro de segurança. O valor está em fechar o loop: log → análise → alerta → resposta automatizada.
Esses três princípios se traduzem diretamente nos seis passos deste playbook. A ordem importa: identidade e menor privilégio primeiro porque têm o maior retorno por hora investida. Criptografia e auditoria amplificam o que você já construiu.
Perímetro Tradicional vs. Zero-Trust na AWS
| Dimensão | Perímetro Tradicional | Zero-Trust na AWS |
|---|---|---|
| Modelo de confiança | Confia na rede (VPC/subnet) | Confia na identidade verificada por requisição |
| Credencial de acesso | Chave de acesso estática (IAM user key) | Credencial efêmera via STS AssumeRole / OIDC |
| Blast radius de comprometimento | Alto, acesso lateral livre dentro da VPC | Baixo, limitado ao escopo da role comprometida |
| Controle de acesso a serviços internos | Security Group + NACL (baseado em IP/porta) | IAM policy + VPC endpoint policy + SG por serviço |
| Tráfego de rede interna | Frequentemente não criptografado (confia no perímetro) | TLS obrigatório mesmo dentro da VPC; KMS para dados em repouso |
| Auditoria | Logs de fluxo de rede (VPC Flow Logs), quem falou com quem | CloudTrail API-level, quem fez o quê, com qual identidade, em qual contexto |
| Detecção de anomalia | Reativa, detecta após movimento lateral | Proativa: GuardDuty detecta credencial comprometida antes do dano |
| Custo de implementação inicial | Baixo (configuração de rede existente) | Médio, requer refatoração de IAM e pipelines de identidade |
Por que a ordem dos passos importa: retorno por esforço
Engenheiros frequentemente querem começar pelo que é visível, diagrama de rede, segmentação, firewalls. Mas em zero-trust na AWS, o maior retorno por hora investida está nos dois primeiros passos: identidade forte e menor privilégio no IAM.
O raciocínio é direto: se você eliminar chaves estáticas e garantir que cada identidade tem apenas o que precisa, você reduziu o blast radius de qualquer comprometimento futuro antes mesmo de saber que ele vai acontecer. Microssegmentação sem identidade forte é um castelo de areia, você limitou o movimento de rede mas não o movimento lógico via credencial roubada.
A sequência que recomendo tem lógica de dependência:
- Passos 1 e 2 (Identidade + Menor Privilégio) são independentes e têm impacto imediato. Podem ser feitos em paralelo por duas pessoas em 1–3 dias.
- Passo 3 (Acesso Adaptativo) depende de identidade forte estabelecida, você não pode adicionar contexto de sessão sem saber quem é a sessão.
- Passo 4 (Microssegmentação) depende de menor privilégio: Security Groups por serviço só fazem sentido se as identidades já estão bem definidas.
- Passo 5 (Criptografia) pode ser feito em paralelo com 3 e 4, mas depende de KMS keys bem governadas (que dependem do IAM do passo 2).
- Passo 6 (Auditoria Contínua) é o fechamento do loop, só é útil se os outros passos estão no lugar, porque os logs precisam ter contexto de identidade para serem acionáveis.
Essa sequência não é dogma, é otimização de risco por sprint. Se você só tiver uma semana, faça os passos 1 e 2. Se tiver duas, adicione 4 e 6. O importante é não começar pelo fim.
Os 6 Passos: Zero-Trust na AWS num Sprint
- 1
Passo 1: Identidade Forte: Federação, OIDC e Credenciais Efêmeras
Objetivo: Eliminar chaves de acesso estáticas (IAM user access keys) de workloads e pipelines. Toda identidade não-humana deve assumir roles via STS; toda identidade humana deve usar federação. Ações concretas: 1. Habilite IAM Identity Center (SSO) com seu IdP (Okta, Azure AD, Google Workspace). Configure MFA obrigatório para todos os usuários. 2. Para workloads em EKS: configure IRSA (IAM Roles for Service Accounts): cada pod assume uma role específica via OIDC, sem credencial no ambiente. 3. Para workloads em EC2/ECS: use Instance Profile / Task Role: nunca coloque
AWS_ACCESS_KEY_IDem variável de ambiente ou arquivo de configuração. 4. - 2
Passo 2: Menor Privilégio no IAM: Por Função, Sem Asterisco
Objetivo: Cada role IAM autoriza exatamente o que a função precisa, nem mais, nem menos. Nenhuma policy de produção com
Action: ''ouResource: ''sem justificativa documentada. Ações concretas: 1. Use IAM Access Analyzer para identificar acessos não utilizados:aws accessanalyzer create-analyzer→ gere findings de acesso externo e não utilizado. 2. Para novas roles: use IAM Access Advisor para ver quais serviços foram realmente acessados nos últimos 90 dias, remova o resto. 3. Implemente permission boundaries para roles criadas por pipelines de automação (CDK, Terraform), limite o teto de permissão mesmo que o código tente criar uma role mais permissiva. 4. - 3
Passo 3: Acesso Adaptativo: Contexto e Metadados de Sessão na Política
Objetivo: A política de acesso considera não apenas 'quem' mas 'de onde', 'quando' e 'com qual contexto', e pode negar mesmo uma identidade válida se o contexto for anômalo. Ações concretas: 1. Use session tags no STS AssumeRole para propagar contexto:
aws sts assume-role --tags Key=Environment,Value=prod Key=Team,Value=payments. Policies podem então usaraws:PrincipalTag/Environmentcomo condição. 2. Configure IAM condition keys de contexto:aws:MultiFactorAuthPresent(exija MFA para operações destrutivas),aws:SourceIp(restrinja console access a IPs corporativos),aws:RequestedRegion. 3. Para acesso humano sensível (console de produção, operações de delete): exija MFA comCondition: { "Bool": { "aws:MultiFactorAuthPresent": "true" } }. 4. - 4
Passo 4: Microssegmentação: Security Groups por Serviço e PrivateLink
Objetivo: Eliminar a flat network onde qualquer recurso na VPC pode alcançar qualquer outro. Cada serviço tem seu próprio perímetro de rede, e tráfego para serviços AWS nunca sai para a internet pública. Ações concretas: 1. Security Group por serviço, não por tier: Em vez de um SG
backend-sgque cobre todos os microserviços, criepayments-service-sg,orders-service-sgetc. Regras de ingress referenciam o SG de origem, não um CIDR. 2. Elimine regras de egress abertas: O default de SG permite todo egress, restrinja explicitamente. Um serviço que só chama o RDS não precisa de egress para a internet. 3. VPC Endpoints (PrivateLink) para serviços AWS: S3, DynamoDB, SQS, SNS, KMS, Secrets Manager, todos devem ser acessados via endpoint privado. - 5
Passo 5: Criptografia Ponta a Ponta: TLS Interno e KMS
Objetivo: Dados em trânsito e em repouso são criptografados independentemente da rede, porque a rede não é confiável por definição. Ações concretas: 1. TLS obrigatório mesmo dentro da VPC: Configure ALBs internos com certificados ACM. Para comunicação serviço-a-serviço (service mesh), use AWS App Mesh com TLS mútuo (mTLS) ou Envoy com certificados gerenciados. 2. KMS para dados em repouso: Habilite encryption at rest com CMKs (Customer Managed Keys) em S3, RDS, DynamoDB, EBS, Secrets Manager. Evite AWS-managed keys para dados sensíveis: CMKs permitem auditoria de uso via CloudTrail e revogação. 3. Secrets Manager em vez de variáveis de ambiente: Nunca coloque segredos em env vars ou parâmetros SSM sem criptografia.
- 6
Passo 6: Auditoria Contínua: CloudTrail + Detecção Automatizada
Objetivo: Fechar o loop, toda ação com identidade é registrada, analisada e, se anômala, gera alerta ou resposta automatizada antes de virar incidente. Ações concretas: 1. CloudTrail multi-region, multi-account: Habilite uma trilha de organização via AWS Organizations, cobre todas as contas e regiões automaticamente. Envie para um bucket S3 centralizado em uma conta de segurança dedicada com MFA Delete habilitado. 2. CloudTrail Insights: Habilite para detectar anomalias em volume de chamadas de API, identifica credencial comprometida fazendo reconnaissance (ex: 1000 chamadas
DescribeInstancesem 5 minutos). 3. GuardDuty habilitado em todas as contas: Analisa CloudTrail, VPC Flow Logs e DNS logs.
Arquitetura Zero-Trust na AWS: Identidade → Política Adaptativa → Serviço Segmentado → Auditoria
Fluxo completo de uma requisição num ambiente zero-trust: desde a autenticação da identidade (humana ou de workload) até a execução no serviço segmentado e o registro auditável. Cada camada é um controle independente, comprometer uma não compromete as outras.
- Human User · IdP + MFA
- Workload · EKS Pod / Lambda
- CI/CD Pipeline · GitHub Actions
- IAM Identity Center · SSO Federation
- OIDC Provider · IRSA / GitHub OIDC
- AWS STS · AssumeRole · Ephemeral Creds
- IAM Policy · Least-Privilege · + Conditions
- SCP · Org Guardrails
- ABAC · Session Tags · + Resource Tags
- Security Groups · Per-Service · No flat network
- PrivateLink · VPC Endpoints · No internet path
- Target Service · S3 / RDS / SQS · + KMS Encrypted
- AWS KMS · CMK · Encrypt at rest
- CloudTrail · All regions · Org trail
- GuardDuty · Anomaly detection · All accounts
- Security Hub · Unified findings · CIS + FSBP
- EventBridge · + Lambda · Auto-remediation
O que zero-trust não resolve, e onde você ainda precisa de outras camadas
Zero-trust é uma filosofia de controle de acesso, não uma solução de segurança completa. Há classes de problemas que ele não cobre diretamente:
Vulnerabilidades de aplicação: Zero-trust autentica e autoriza a requisição, mas se o código da aplicação tem uma SQL injection ou um SSRF, a requisição autenticada pode ser usada para explorar a vulnerabilidade. WAF (AWS WAF), análise estática de código (SAST) e testes de penetração são complementares, não substituídos.
Insider threat sofisticado: Um usuário legítimo com acesso legítimo que exfiltra dados lentamente dentro do escopo de sua role é difícil de detectar só com zero-trust. Aqui entram DLP (Data Loss Prevention), análise comportamental (Amazon Macie para dados sensíveis em S3) e revisões periódicas de acesso.
Supply chain attacks: Se uma dependência de terceiro no seu código é comprometida, ela roda com a identidade e permissões do seu serviço. Zero-trust não resolve isso, você precisa de análise de dependências (Amazon Inspector, Dependabot), imagens base verificadas e SBOM.
Custo operacional real: Implementar zero-trust corretamente aumenta a complexidade operacional. Debugging de problemas de conectividade fica mais difícil quando há múltiplas camadas de controle (IAM policy + SCP + endpoint policy + SG). Você precisa de boa observabilidade e runbooks claros para não trocar risco de segurança por risco de disponibilidade.
A conclusão prática: zero-trust é necessário mas não suficiente. Ele reduz drasticamente o blast radius e elimina vetores de ataque comuns, mas precisa ser parte de uma estratégia de defesa em profundidade, não a estratégia completa.
Anti-Padrões: Onde Zero-Trust Morde em Produção
1. 'Estar na VPC' como credencial implícita
O anti-padrão mais comum: Security Groups que permitem tráfego de qualquer instância no mesmo subnet, sem verificação de identidade. Um atacante que compromete qualquer instância na VPC herda esse acesso. Corrija: SG por serviço com referência a SG de origem, não CIDR.
**2. IAM com Action: '' ou Resource: '' em produção
Políticas de wildcard são o equivalente de dar a chave do datacenter para cada desenvolvedor. Frequentemente surgem de 'era só pra testar' que nunca foi revertido. Corrija: IAM Access Analyzer + Config rule iam-no-inline-policy + revisão trimestral de policies.
3. Chaves de acesso estáticas em variáveis de ambiente ou código
Ainda o vetor mais frequente de comprometimento de contas AWS. Chaves em .env, em repositórios Git, em imagens Docker. Corrija: IRSA/Task Role para workloads, OIDC para CI/CD, Secrets Manager para segredos de aplicação. Monitore com git-secrets e GuardDuty.
4. CloudTrail habilitado mas sem ninguém lendo
Security theater. Logs sem análise são apenas custo de storage. Corrija: GuardDuty + Security Hub + pelo menos uma EventBridge rule de resposta automatizada.
5. Implementar todos os 6 passos ao mesmo tempo sem testes**
Zero-trust mal implementado pode derrubar serviços em produção (SG muito restritivo, endpoint policy bloqueando acesso legítimo). Corrija: implemente em ambientes de staging primeiro, use aws iam simulate-principal-policy para testar policies antes de aplicar, e habilite CloudTrail antes de qualquer mudança para ter rollback auditável.
Regra de Bolso
Comece por identidade + menor privilégio. Sempre. Se você só puder fazer dois passos desta semana, faça os passos 1 e 2: elimine chaves estáticas e remova wildcards do IAM. Esses dois passos reduzem o blast radius de qualquer comprometimento futuro, antes mesmo de você saber que ele vai acontecer. Microssegmentação sem identidade forte é decoração. Auditoria sem menor privilégio é ruído. Identidade + menor privilégio é a fundação, tudo o mais amplifica o que você já construiu.
Depois de 16 anos construindo sistemas financeiros e plataformas de dados, o padrão que mais me custou aprender é este: segurança não é uma feature que você adiciona no final, é uma propriedade emergente de decisões de arquitetura que você toma desde o primeiro sprint.
Na prática, quando entro em um projeto novo ou faço revisão de arquitetura, as primeiras perguntas que faço não são sobre performance ou custo, são: 'Quem é essa identidade e como ela prova quem é?' e 'O que essa role pode fazer que ela não deveria poder?'. Essas duas perguntas revelam mais sobre a postura de segurança de um sistema do que qualquer pentest.
O que eu faço concretamente:
- Nunca aprovo uma PR que adiciona uma chave de acesso estática em código, variável de ambiente ou secret de CI/CD sem OIDC como alternativa documentada. Chave estática é dívida técnica de segurança com juros compostos.
- Uso aws iam simulate-principal-policy como parte do pipeline de CI para testar policies antes de deploy, é como unit test para IAM.
- Habilito GuardDuty e Security Hub no dia zero de qualquer conta nova, mesmo que seja sandbox. O custo é mínimo; o valor de ter baseline de detecção desde o início é enorme.
- Trato endpoint policies de PrivateLink como tão importantes quanto IAM policies: muita gente configura o endpoint mas deixa a policy como Allow , o que anula o controle.
- Faço revisão trimestral de IAM Access Advisor para identificar permissões não usadas. Permissão não usada é superfície de ataque que você está pagando para manter.
O que eu não* faço: não implemento tudo de uma vez em produção sem staging. Já vi zero-trust mal implementado derrubar serviços críticos por SG muito restritivo. A sequência importa, e testar antes de aplicar não é opcional.
Zero-Trust e o AWS Well-Architected Framework
Segurança
Zero-trust é a implementação direta dos princípios de segurança do WAF: identidade forte (SEC 2), menor privilégio (SEC 3), proteção de dados (SEC 8/9) e detecção (SEC 4). Os 6 passos mapeiam diretamente para as melhores práticas do pilar de segurança.
Confiabilidade
Microssegmentação e menor privilégio reduzem blast radius de falhas, um serviço comprometido não pode cascatear para outros. Porém, SGs muito restritivos podem criar pontos de falha de conectividade: teste em staging antes de produção.
Eficiência de performance
TLS interno e PrivateLink têm latência negligível em workloads modernos. KMS adiciona ~1-5ms por operação de envelope encryption, aceitável para a grande maioria dos casos de uso.
Veredicto
Zero-trust na AWS não é um projeto de transformação de seis meses, é uma sequência de seis decisões de arquitetura que você pode tomar num sprint. A ordem importa: identidade forte e menor privilégio primeiro, porque reduzem blast radius antes de qualquer comprometimento acontecer. Microssegmentação e criptografia amplificam o que você já construiu. Auditoria fecha o loop. O que separa um ambiente zero-trust real de security theater é simples: cada requisição prova quem é, é autorizada por política explícita e é registrada de forma que você possa detectar anomalia antes de virar incidente. Se você não consegue responder 'qual identidade fez essa chamada de API e ela estava autorizada a fazê-la?', você ainda está no modelo de perímetro, independentemente de quantos firewalls tem. Comece hoje. Passos 1 e 2. O resto vem no próximo sprint.
Continue lendo
Post-mortems, ADRs e deep dives de arquitetura no seu email, do jeito que um arquiteto lê.
Sem spam · cancele quando quiser
Pergunte ao Fernando sobre isto
Uma resposta focada sobre este estudo, do meu assistente de IA, baseada no meu trabalho.
Participe da conversa
Entre para comentar
Confirme seu e-mail para participar, você também recebe a newsletter. Sem senha.