# Playbook: Zero-Trust na AWS do Zero — 6 Passos que Cabem num Sprint

Zero-trust não é um produto nem um projeto de seis meses — é um conjunto de decisões de arquitetura que você pode começar a implementar hoje. Este playbook apresenta seis passos concretos e priorizados para eliminar confiança implícita na AWS, reduzir blast radius e construir auditoria contínua, sem paralisar entregas.

- URL: https://fernando.moretes.com/studies/playbook-zero-trust-na-aws-em-6-passos

- Markdown: https://fernando.moretes.com/studies/playbook-zero-trust-na-aws-em-6-passos/study.md?lang=pt

- Type: Playbook

- Domain: AWS / Segurança

- Date: 2025-03-08

- Tags: zero-trust, aws-security, iam, privatelink, cloudtrail, identity, least-privilege, microsegmentation

- Reading time: 11 min

---

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

- Entender por que 'estar na VPC' não é credencial e o que substituí-la
- Implementar federação OIDC e credenciais efêmeras eliminando chaves estáticas
- Escrever políticas IAM com menor privilégio real — por função, sem asterisco
- Segmentar rede por serviço com Security Groups e PrivateLink em vez de flat network
- Ativar criptografia ponta a ponta (TLS interno + KMS) sem overhead operacional excessivo
- Montar pipeline de auditoria contínua com CloudTrail + detecção automatizada

## 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:

1. **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.

2. **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 de `s3:GetObject` em um ARN específico. A diferença entre os dois é a diferença entre um incidente contido e uma exfiltração completa.

3. **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
| Critério | 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_ID` em 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: '*'` ou `Resource: '*'` 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 usar `aws:PrincipalTag/Environment` como 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 com `Condition: { "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-sg` que cobre todos os microserviços, crie `payments-service-sg`, `orders-service-sg` etc. 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 `DescribeInstances` em 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.

### 👤 Identity Layer

- Human User IdP + MFA (user)
- Workload EKS Pod / Lambda (compute)
- CI/CD Pipeline GitHub Actions (ci)

### 🔑 Auth & Token Layer

- IAM Identity Center SSO Federation (security)
- OIDC Provider IRSA / GitHub OIDC (security)
- AWS STS AssumeRole Ephemeral Creds (security)

### 📋 Policy & Context Layer

- IAM Policy Least-Privilege + Conditions (security)
- SCP Org Guardrails (security)
- ABAC Session Tags + Resource Tags (security)

### 🔒 Network & Service Layer

- Security Groups Per-Service No flat network (network)
- PrivateLink VPC Endpoints No internet path (network)
- Target Service S3 / RDS / SQS + KMS Encrypted (data)
- AWS KMS CMK Encrypt at rest (security)

### 🔍 Audit & Detection Layer

- CloudTrail All regions Org trail (security)
- GuardDuty Anomaly detection All accounts (security)
- Security Hub Unified findings CIS + FSBP (security)
- EventBridge + Lambda Auto-remediation (security)

### Fluxos

- human -> idc: SAML/OIDC + MFA
- workload -> oidc: OIDC token (IRSA)
- cicd -> oidc: OIDC token
- idc -> sts: AssumeRole
- oidc -> sts: AssumeRoleWithWebIdentity
- sts -> iam: credencial efêmera
- iam -> scp: guardrail check
- iam -> abac: session tags
- iam -> sg: autorizado → acessa rede
- sg -> pl: tráfego privado
- pl -> svc: endpoint policy check
- svc -> kms: encrypt/decrypt
- sts -> ct: API call logged
- svc -> ct: data access logged
- ct -> gd: análise contínua
- gd -> sh: findings
- sh -> eb: HIGH severity
- eb -> sts: revoke session

## 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.

> **Minha Perspectiva: O Que Eu Faço na Prática:** 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

- **security**: 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.
- **reliability**: 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.
- **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.

## Referências

- [AWS — Zero Trust on AWS](https://aws.amazon.com/security/zero-trust/)
- [AWS — IAM Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
- [AWS — AWS PrivateLink](https://aws.amazon.com/privatelink/)
- [AWS — AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
- [AWS — IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
- [AWS — Amazon GuardDuty](https://aws.amazon.com/guardduty/)
- [AWS — AWS Security Hub](https://aws.amazon.com/security-hub/)
- [AWS — IAM Roles for Service Accounts (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html)

## Fontes do caso

- [AWS — Zero Trust on AWS](https://aws.amazon.com/security/zero-trust/)
- [AWS — IAM best practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
- [AWS — AWS PrivateLink](https://aws.amazon.com/privatelink/)
- [AWS — AWS CloudTrail](https://aws.amazon.com/cloudtrail/)