# Design Doc: Zero Trust na AWS para Acesso a Serviços Internos

Este documento propõe uma arquitetura Zero Trust na AWS onde identidade, contexto e postura do dispositivo substituem o perímetro de rede como mecanismo primário de controle de acesso. O design cobre segmentação de workloads, acesso adaptativo via IAM Identity Center e Verified Access, e instrumentação de auditoria contínua. O objetivo é eliminar a confiança implícita baseada em localização de rede sem introduzir fricção operacional excessiva.

- URL: https://fernando.moretes.com/studies/design-doc-zero-trust-on-aws

- Markdown: https://fernando.moretes.com/studies/design-doc-zero-trust-on-aws/study.md?lang=pt

- Type: Design Doc / RFC

- Company: Zero Trust (cenário)

- Domain: Segurança

- Date: 2026-02-10

- Tags: zero-trust, aws, iam, security, identity, segmentation, access-control, compliance

- Reading time: 11 min

---

Perímetro de rede não é mais garantia de segurança. Este RFC define como redesenhar o acesso a serviços internos na AWS usando identidade como novo perímetro — com menor privilégio, segmentação granular e decisões de acesso baseadas em contexto em tempo real.

## O Problema: Confiança Implícita Como Superfície de Ataque

A maioria das arquiteturas corporativas na AWS ainda opera com um modelo de confiança baseado em localização de rede: se um recurso está dentro da VPC ou conectado via VPN, ele recebe acesso implícito a outros serviços internos. Esse modelo foi razoável quando os limites de rede eram bem definidos e estáticos. Hoje, ele é uma dívida arquitetural.

O problema se manifesta de formas concretas. Engenheiros com acesso SSH a um bastion host dentro da VPC conseguem alcançar bancos de dados de produção que não têm relação com sua função. Serviços com roles IAM overprovisionadas — criadas durante um sprint de pressa — acumulam permissões que nunca são revogadas. Workloads em contas diferentes se comunicam via peering sem qualquer inspeção de tráfego ou validação de identidade. Quando um atacante compromete qualquer ponto dentro desse perímetro, o movimento lateral é trivial.

O cenário que este documento aborda é representativo de organizações em estágio de escala: múltiplas contas AWS organizadas via AWS Organizations, times de engenharia com acesso federado via SSO corporativo, workloads mistas (ECS, Lambda, EC2), e um conjunto crescente de APIs internas que precisam ser acessíveis a desenvolvedores, pipelines de CI/CD e outros serviços — mas não a todos, não sempre, e não sem rastreabilidade.

A solução não é adicionar mais VPNs ou mais regras de Security Group. É repensar o modelo de confiança do zero: nenhuma entidade — humana ou de máquina — recebe acesso por padrão. Todo acesso é explicitamente autorizado, minimamente privilegiado, contextualmente validado e auditado de forma contínua. Isso é Zero Trust aplicado de forma pragmática, não como buzzword.

## Objetivos e Não-Objetivos

- ✅ OBJETIVO: Eliminar confiança implícita baseada em localização de rede para acesso humano e de serviços
- ✅ OBJETIVO: Implementar menor privilégio verificável e auditável para todas as identidades (IAM roles, usuários federados, workloads)
- ✅ OBJETIVO: Introduzir controle de acesso adaptativo baseado em contexto: postura do dispositivo, localização, horário e risco da sessão
- ✅ OBJETIVO: Garantir rastreabilidade completa de quem acessou o quê, quando e de onde — integrada ao SIEM
- ✅ OBJETIVO: Segmentar workloads por domínio de negócio com controles de acesso inter-serviço explícitos
- ❌ NÃO-OBJETIVO: Substituir controles de segurança de aplicação (autenticação de usuário final, WAF, input validation)

## Contexto do Cenário

- **Tipo de documento:** Design Doc / RFC — cenário representativo
- **Domínio:** Segurança de infraestrutura cloud — Zero Trust
- **Escala assumida:** 50–500 engenheiros, 10–50 contas AWS, dezenas de serviços internos
- **Stack principal:** AWS IAM Identity Center, Verified Access, VPC Lattice, CloudTrail, Security Hub, GuardDuty, AWS Organizations
- **Modelo de identidade:** Federação via IdP externo (Okta / Azure AD) + IAM Roles for workloads
- **Regulatório relevante:** Alinhado com NIST SP 800-207 (Zero Trust Architecture) e AWS Well-Architected Security Pillar
- **Status do RFC:** Proposto

## Design Proposto: Identidade Como Perímetro

O design se organiza em quatro camadas complementares que, juntas, implementam os princípios Zero Trust sem exigir uma reescrita completa da infraestrutura existente.

**Camada 1 — Identidade Centralizada e Federada.** O AWS IAM Identity Center torna-se o ponto único de entrada para acesso humano a todas as contas AWS. A federação com o IdP corporativo (Okta ou Azure AD) garante que autenticação multifator, políticas de senha e ciclo de vida de identidades sejam gerenciados no sistema de registro da empresa. Permission Sets no Identity Center são mapeados a grupos no IdP, e o princípio de menor privilégio é aplicado por função: um engenheiro de backend não recebe, por padrão, acesso a contas de produção de dados. Acesso elevado (ex: break-glass para produção) é concedido via fluxo de aprovação com TTL máximo de 4 horas e notificação automática ao time de segurança.

**Camada 2 — Acesso Adaptativo para Desenvolvedores.** O AWS Verified Access substitui a VPN para acesso de desenvolvedores a ferramentas internas (dashboards, APIs de administração, consoles de observabilidade). Cada solicitação de acesso é avaliada em tempo real contra três sinais: identidade verificada pelo IdP (com MFA), postura do dispositivo via integração com o agente MDM/EDR existente, e contexto da sessão (horário, localização, anomalias detectadas pelo GuardDuty). Não existe uma sessão VPN persistente que, uma vez estabelecida, concede acesso amplo. Cada request é uma nova decisão de autorização.

**Camada 3 — Comunicação Inter-Serviço com VPC Lattice.** Para comunicação service-to-service, o VPC Lattice provê um plano de controle unificado que aplica políticas de autorização baseadas em identidade de workload (IAM roles) independente de topologia de rede. Um serviço de pagamentos em uma conta pode chamar um serviço de notificações em outra conta somente se a IAM role do caller for explicitamente autorizada na resource policy do serviço destino. Não há regras de Security Group abertas entre VPCs. O tráfego é autenticado por assinatura SigV4 em cada chamada. Serviços que ainda não suportam VPC Lattice usam VPC endpoints com resource policies restritivas como camada de transição.

**Camada 4 — Auditoria Contínua e Detecção.** CloudTrail com Data Events habilitado em todas as contas, centralizado em uma conta de segurança dedicada via AWS Organizations. Security Hub agrega findings de GuardDuty, IAM Access Analyzer, e Config Rules em um painel unificado. IAM Access Analyzer roda continuamente para detectar permissões excessivas e acesso externo não intencional. Um conjunto de Config Rules customizadas verifica invariantes de segurança: nenhuma IAM role com `*:*`, nenhum Security Group com 0.0.0.0/0 em portas sensíveis, nenhum bucket S3 público em contas de produção. Findings críticos disparam automação via EventBridge para revogação automática de sessões suspeitas.

## Arquitetura Zero Trust: Fluxo de Acesso e Controles

Diagrama mostra os três planos de acesso (humano, serviço-a-serviço, auditoria) e como cada um é controlado por identidade e contexto, não por localização de rede.

### 👤 Identidade & Acesso Humano

- IdP Corporativo Okta / Azure AD (security)
- IAM Identity Center SSO + Permission Sets (security)
- AWS Verified Access Access por Request (security)
- Desenvolvedor + Dispositivo Gerenciado (user)

### 🔐 Controle de Acesso & Políticas

- SCPs AWS Organizations (security)
- IAM Access Analyzer Detecção Contínua (security)
- AWS Config Config Rules (security)
- GuardDuty Detecção de Ameaças (security)

### ⚙️ Workloads & Serviços Internos

- Serviço A ECS / Lambda (Conta Prod) (compute)
- Serviço B ECS / Lambda (Conta Data) (compute)
- VPC Lattice Service Network (network)
- VPC Endpoints Resource Policies (network)
- RDS / Aurora IAM Auth Habilitado (data)

### 📋 Auditoria & Resposta

- CloudTrail Data Events (Org) (security)
- Security Hub Findings Agregados (security)
- EventBridge Automação de Resposta (messaging)
- SIEM Externo S3 + Kinesis (external)

### Fluxos

- dev -> idp: Autenticação MFA
- idp -> iic: Federação SAML/OIDC
- iic -> svcA: Role temporária (STS)
- dev -> va: Request + postura do dispositivo
- va -> idp: Verificação de identidade
- va -> svcA: Acesso autorizado por request
- scp -> iic: Guardrails de org
- svcA -> lattice: SigV4 + IAM Role
- lattice -> svcB: Autorização por resource policy
- svcA -> vpce: Serviços legados
- svcB -> rds: IAM Database Auth
- iaa -> sh: Findings de permissão
- gd -> sh: Findings de ameaça
- cfg -> sh: Compliance findings
- ct -> siem: Logs para SIEM
- sh -> eb: Findings críticos
- eb -> iic: Revogação de sessão

## Decisões de Design e Trade-offs Principais

**VPC Lattice vs. Service Mesh (Istio/App Mesh).** A escolha pelo VPC Lattice para comunicação inter-serviço é deliberada e merece justificativa. Um service mesh como Istio oferece controle mais granular de tráfego (circuit breaking, retry policies, traffic splitting), mas introduz um plano de controle complexo que a maioria dos times de plataforma não tem capacidade de operar com segurança. O VPC Lattice delega a complexidade operacional para a AWS e integra nativamente com IAM — o que significa que as políticas de autorização de serviço são expressas na mesma linguagem que todas as outras políticas AWS, são auditadas pelo CloudTrail, e são analisadas pelo IAM Access Analyzer. O trade-off é menos flexibilidade de tráfego em troca de muito menos superfície operacional. Para a maioria dos casos de uso de segurança Zero Trust, esse é o trade-off correto.

**Verified Access vs. VPN Corporativa.** VPNs criam sessões persistentes com acesso de rede amplo. Uma vez conectado, um desenvolvedor (ou um atacante que comprometeu suas credenciais) tem alcance de rede a todos os recursos na VPC. O Verified Access avalia cada request individualmente, o que significa que uma sessão comprometida não concede automaticamente acesso a todos os recursos. O custo é latência adicional por request (tipicamente 5–15ms, estimativa baseada em características do serviço) e necessidade de integração com o agente de postura de dispositivo. Para ferramentas internas de baixa frequência (dashboards, consoles de admin), esse custo é aceitável. Para APIs internas de alta frequência entre serviços, VPC Lattice é o mecanismo correto — não Verified Access.

**IAM Database Authentication vs. Credenciais Estáticas.** Habilitar IAM Auth no RDS/Aurora elimina a necessidade de gerenciar senhas de banco de dados. A autenticação é feita via token temporário gerado pelo STS, válido por 15 minutos. O trade-off é que cada conexão nova ao banco requer uma chamada ao STS para gerar o token, o que tem implicações para pools de conexão. A solução é usar um proxy (RDS Proxy) que mantém o pool de conexões e renegocia autenticação IAM de forma transparente. Esse padrão elimina completamente a classe de vulnerabilidade de credenciais de banco de dados vazadas em código ou variáveis de ambiente.

**SCPs como Guardrails vs. IAM Policies como Controles.** Service Control Policies no nível de Organizations são guardrails que definem o máximo possível — elas não concedem acesso, apenas limitam o que pode ser concedido. IAM Policies são os controles reais. A combinação correta é: SCPs restringem regiões não autorizadas, serviços não aprovados, e ações de alto risco (ex: desabilitar CloudTrail, remover MFA de root) para toda a organização; IAM Policies implementam menor privilégio específico por workload. Tentar fazer tudo via SCPs resulta em políticas enormes e frágeis. Tentar fazer tudo via IAM sem SCPs deixa brechas que um administrador de conta pode explorar.

## Alternativas para Acesso de Desenvolvedor a Ferramentas Internas

### VPN Corporativa (modelo atual)

**Pros**
- Familiar para equipes de operações
- Sem latência adicional por request após conexão estabelecida

**Cons**
- Acesso de rede amplo após autenticação — movimento lateral trivial
- Sem avaliação de postura de dispositivo por request
- Sessão persistente não revogada imediatamente em caso de comprometimento
- Logs de acesso granulares difíceis de correlacionar com ações específicas

**Verdict:** Rejeitado para novos acessos. Mantido apenas como fallback de emergência com MFA adicional.

### AWS Verified Access

**Pros**
- Avaliação de identidade + postura de dispositivo por request
- Sem sessão de rede persistente — zero lateral movement implícito
- Integração nativa com IAM Identity Center e IdPs externos
- Logs de acesso detalhados no CloudTrail

**Cons**
- Latência adicional por request (estimativa: 5–15ms)
- Requer agente de postura de dispositivo integrado
- Custo por hora de endpoint ativo

**Verdict:** Selecionado. Melhor relação segurança/operação para acesso humano a ferramentas internas.

### Bastion Host com Session Manager

**Pros**
- Sem porta SSH exposta — acesso via AWS Systems Manager
- Sessões auditadas no CloudTrail
- Custo baixo

**Cons**
- Ainda concede acesso de rede a partir do bastion após autenticação
- Sem avaliação de contexto ou postura de dispositivo
- Não escala para acesso a aplicações web internas

**Verdict:** Aceito apenas para acesso de emergência a instâncias EC2 específicas, não como solução geral.

## Decisão: VPC Lattice como Plano de Controle Inter-Serviço

**Status:** proposed

**Contexto**

Serviços em múltiplas contas AWS precisam se comunicar de forma autenticada e autorizada. As opções são: peering de VPC com Security Groups (modelo atual), service mesh gerenciado pelo time (Istio/App Mesh), ou VPC Lattice gerenciado pela AWS.

**Decisão**

Adotar VPC Lattice como plano de controle para comunicação inter-serviço. Políticas de autorização baseadas em IAM roles. SigV4 para autenticação de cada request. Migração gradual: novos serviços usam Lattice por padrão; serviços existentes migram por domínio de negócio.

**Consequências**
- Elimina regras de Security Group entre VPCs para comunicação de serviços
- Toda comunicação inter-serviço é auditada via CloudTrail automaticamente
- Times precisam aprender a escrever resource policies para serviços VPC Lattice
- Custo adicional por request processado no Lattice (avaliar impacto para serviços de alto volume)

## Plano de Rollout em Fases

1. **Fase 0 — Fundação (Semanas 1–4)** — Habilitar CloudTrail com Data Events em todas as contas via Organizations. Ativar GuardDuty e Security Hub com agregação na conta de segurança. Executar IAM Access Analyzer em todas as contas e documentar findings existentes (linha de base). Implementar SCPs de guardrail: bloquear regiões não autorizadas, exigir MFA para ações sensíveis, impedir desativação de serviços de auditoria. Nenhuma mudança de acesso ainda — apenas visibilidade.

2. **Fase 1 — Identidade Centralizada (Semanas 5–8)** — Configurar IAM Identity Center com federação ao IdP corporativo. Mapear grupos existentes do IdP a Permission Sets com menor privilégio. Migrar acesso humano para SSO — eliminar usuários IAM com credenciais de longa duração para pessoas. Implementar fluxo de acesso elevado com aprovação e TTL de 4 horas. Comunicar mudanças aos times de engenharia com documentação e período de transição de 2 semanas.

3. **Fase 2 — Acesso Adaptativo (Semanas 9–14)** — Implantar AWS Verified Access para ferramentas internas prioritárias (dashboards de observabilidade, consoles de administração). Integrar com agente MDM/EDR existente para avaliação de postura de dispositivo. Definir políticas de acesso por ferramenta: identidade + MFA + dispositivo gerenciado. Descomissionar acesso VPN para as ferramentas migradas. Manter VPN apenas como fallback de emergência com MFA adicional e alerta automático.

4. **Fase 3 — Segmentação de Serviços (Semanas 15–24)** — Habilitar VPC Lattice na conta de rede compartilhada. Migrar novos serviços para usar Lattice por padrão. Migrar serviços existentes por domínio de negócio, começando pelos de menor risco operacional. Habilitar IAM Database Authentication no RDS/Aurora com RDS Proxy. Remover regras de Security Group inter-VPC à medida que serviços migram. Validar com IAM Access Analyzer que nenhuma permissão residual permanece.

5. **Fase 4 — Automação e Maturidade (Semanas 25–32)** — Implementar automação de resposta via EventBridge: revogação automática de sessões com score de risco alto no GuardDuty, quarentena de IAM roles com comportamento anômalo. Implementar revisão periódica automatizada de permissões (Access Reviews) com relatório para gestores de time. Integrar findings do Security Hub com SIEM corporativo. Estabelecer processo de revisão trimestral de SCPs e Permission Sets. Documentar runbooks de resposta a incidentes para os cenários Zero Trust.

> **Riscos Críticos e Mitigações:** **Risco 1: Lockout acidental durante migração de identidade.** A migração de usuários IAM para SSO é o momento de maior risco operacional. Um erro de mapeamento de grupo pode deixar times inteiros sem acesso a contas de produção. Mitigação: manter usuários IAM de emergência (break-glass) com credenciais armazenadas no AWS Secrets Manager, acessíveis apenas com aprovação dupla e alerta automático. Testar cada Permission Set em ambiente de staging antes de aplicar em produção.

**Risco 2: Regressão de performance com VPC Lattice.** Serviços de alto volume (>10k req/s) podem sentir impacto de latência e custo com a adição de autenticação SigV4 por request. Mitigação: benchmarking obrigatório antes de migração de serviços críticos. Para serviços onde o custo é proibitivo, avaliar VPC endpoints com resource policies como alternativa de menor custo.

**Risco 3: Resistência cultural dos times de engenharia.** Zero Trust adiciona fricção real ao fluxo de trabalho de desenvolvimento. Desenvolvedores acostumados a acessar qualquer recurso da VPC via SSH vão resistir. Mitigação: investir em tooling que torne o acesso correto mais fácil que o acesso incorreto. CLI wrapper para SSO, documentação de onboarding atualizada, e champions de segurança em cada time.

**Risco 4: Falso senso de segurança.** Zero Trust na camada de infraestrutura não protege contra vulnerabilidades de aplicação, injeção de código, ou comprometimento de credenciais do IdP corporativo. Se o IdP for comprometido, toda a cadeia de confiança é comprometida. Mitigação: Zero Trust é uma camada, não uma solução completa.

## AWS Well-Architected: Avaliação do Design

- **security**: Forte. Identidade como perímetro primário, menor privilégio verificável, auditoria contínua, detecção automatizada. Alinhado com todos os design principles do Security Pillar: implementar uma base de identidade forte, habilitar rastreabilidade, aplicar segurança em todas as camadas, automatizar boas práticas.
- **reliability**: Moderado. VPC Lattice e Verified Access são serviços gerenciados com SLAs da AWS. O risco é dependência de disponibilidade do IdP externo para acesso humano — mitigado com break-glass IAM. Testar cenários de falha do IdP é obrigatório.
- **sustainability**: Neutro. Eliminação de bastion hosts reduz instâncias EC2 idle. Sem impacto significativo de sustentabilidade.

## Métricas de Sucesso e Targets

- **Usuários IAM com credenciais de longa duração (pessoas):** Target: 0 (exceto break-glass, monitorado)
- **IAM roles com permissões *:*:** Target: 0 — detectado automaticamente por Config Rule
- **Cobertura de CloudTrail Data Events:** Target: 100% das contas de produção
- **Serviços internos com comunicação via VPC Lattice ou VPC Endpoint:** Target: 100% ao final da Fase 3
- **Tempo médio de detecção de permissão excessiva (MTTD):** Target: <24h via IAM Access Analyzer contínuo
- **Tempo de resposta a finding crítico do GuardDuty:** Target: <5 min para revogação automática via EventBridge
- **Acesso humano a ferramentas internas via Verified Access:** Target: 100% das ferramentas internas ao final da Fase 2
- **Duração do rollout completo (estimativa):** 32 semanas (8 meses) para organização de 50–200 engenheiros

> **Minha Perspectiva: O Que Eu Faria de Diferente:** Depois de trabalhar em sistemas financeiros onde o custo de uma brecha é existencial, aprendi que Zero Trust não é uma arquitetura que você implementa de uma vez — é uma postura que você adota incrementalmente, começando pelos controles de maior impacto com menor fricção.

O erro mais comum que vejo é times tentando implementar tudo de uma vez e travando na resistência cultural. Minha abordagem: comece pela visibilidade (Fase 0), não pela restrição. Você precisa entender o estado atual antes de mudar qualquer coisa. IAM Access Analyzer em modo de descoberta vai revelar permissões que ninguém sabia que existiam. Esse dado é seu aliado político para justificar as mudanças que vêm depois.

Sobre VPC Lattice: eu o adotaria, mas com uma ressalva importante. Para serviços existentes de alto volume, eu mediria o custo real antes de migrar. O modelo de pricing do Lattice (por request + por GB) pode ser surpreendente para serviços chatty. Em alguns casos, VPC endpoints com resource policies restritivas entregam 80% do benefício de segurança a 10% do custo. Não deixe o perfeito ser inimigo do bom.

Sobre Verified Access: é genuinamente bom para o problema que resolve, mas o sucesso depende quase inteiramente da qualidade da integração com o agente de postura de dispositivo. Se o MDM/EDR corporativo não consegue reportar postura de forma confiável, você vai acabar com políticas que não avaliam dispositivo de verdade — o que é pior do que admitir a limitação. Seja honesto sobre o que você consegue verificar.

A lição mais importante: Zero Trust falha quando vira projeto de segurança is

## Veredicto

Zero Trust na AWS não é uma feature que você liga — é uma mudança de modelo mental que se traduz em escolhas de arquitetura específicas. O design proposto aqui é pragmático: usa serviços gerenciados da AWS (Identity Center, Verified Access, VPC Lattice) para entregar os princípios Zero Trust sem exigir que o time opere infraestrutura de segurança complexa. O trade-off é custo adicional e latência marginal em troca de eliminação de confiança implícita, rastreabilidade completa e menor privilégio verificável.

O rollout em quatro fases é deliberadamente conservador. Segurança que interrompe operações não é segurança — é um incidente. Começar com visibilidade antes de restrição, migrar por domínio de negócio, e manter caminhos de fallback durante transições são práticas que a maioria dos times ignora na pressa de mostrar progresso.

O que este design não resolve: vulnerabilidades de aplicação, comprometimento do IdP corporativo, e ameaças internas de pessoas com acesso legítimo. Zero Trust reduz a superfície de ataque e o raio de explosão de um comprometimento, mas não elimina o risco. É uma camada necessária, não uma solução completa. Qualquer arquiteto que te vender Zero Trust como 

## Referências

- [AWS Security, Identity & Compliance Architecture Center](https://aws.amazon.com/architecture/security-identity-compliance/)
- [AWS IAM Identity Center — User Guide](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)
- [AWS Verified Access — User Guide](https://docs.aws.amazon.com/verified-access/latest/ug/what-is-verified-access.html)
- [Amazon VPC Lattice — User Guide](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html)
- [AWS IAM Access Analyzer — Documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
- [NIST SP 800-207: Zero Trust Architecture](https://csrc.nist.gov/publications/detail/sp/800-207/final)
- [AWS Well-Architected Framework — Security Pillar](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)
- [AWS Service Control Policies — Best Practices](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_best-practices.html)

## Fontes do caso

- [AWS — Security, Identity & Compliance](https://aws.amazon.com/architecture/security-identity-compliance/)