Zero Trust e mTLS: verificar sempre, nunca confiar na rede
⏱ 12 min·⭐ 55 XP
Pré-requisitos (0/1)0%
- ⬜📦 Supply chain: SBOM, sigstore e dependency confusion(Security Engineering)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Castelo + fosso vs Zero Trust
Modelo tradicional: firewall perimetral; dentro da VPC tudo é "confiável". Problema: uma vez dentro (VPN comprometida, insider, pod hackeado), atacante tem acesso lateral pleno. Exemplos: Target 2013 (vendor HVAC → POS), Capital One 2019 (SSRF → metadata → IAM).
Modelo antigo
Perímetrodentro é confiável, fora não é
Serviços internosconversam sem autenticar entre si
Movimento lateralquem entra alcança tudo
Confiança zero
Identidade por carga de trabalhocada serviço tem certificado próprio
Autenticação mútuaos DOIS lados provam quem são
Políticao serviço A pode chamar B? — decidido a cada chamada
Registroquem chamou quem, sempre
Serviços
Serviço A
Serviço B
- → autoriza
- Segurança e identidade
- Compute
- Conceito de arquitetura
- Gestão e governança
A mudança de fundo é uma pergunta: se um invasor já estiver dentro da rede, o que ele consegue fazer? No modelo de perímetro, tudo. Com identidade por carga de trabalho, apenas o que aquela identidade específica podia.
- 1 · O perímetro pressupõe que a rede define confiança. Estar dentro era credencial suficiente. Isso funcionava quando "dentro" era um prédio — e deixou de funcionar com nuvem, terceiros e trabalho remoto.
- 2 · O modo de falha é o movimento lateral. Uma máquina comprometida alcança tudo o mais, porque nada mais pergunta quem ela é. O estrago não fica contido no ponto de entrada.
- 3 · A confiança passa a ser da identidade, não do endereço. Cada serviço recebe uma identidade criptográfica própria. Estar na mesma rede deixa de significar qualquer coisa.
- 4 · Mútua significa que os dois lados provam. No modelo comum da web só o servidor apresenta certificado. Aqui o cliente também — é isso que impede um serviço qualquer de se passar por outro.
- 5 · Autenticar não é autorizar. Saber que é o serviço A não diz se A pode chamar B. A política é uma segunda decisão, e é ela que contém o estrago quando uma identidade é comprometida.
- 6 · Para time pequeno, a versão viável é parcial. Malha de serviços completa é caro. Começar por autenticação entre serviços críticos, rotação curta de credencial e registro de chamadas já muda o patamar.
Zero Trust: cada request é tratada como se viesse da internet hostil, independente de origem. Identidade + autorização explícita em cada hop.
Os 3 pilares (NIST)
- Verify explicitly: autenticar e autorizar cada request com máximo de contexto (identidade, device, localização, behavior).
- Least privilege: permissões mínimas pelo menor tempo (just-in-time access, just-enough-access).
- Assume breach: minimize blast radius com segmentação, criptografia end-to-end, logging granular.
mTLS em service mesh
# Istio — mTLS STRICT em todo namespace
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: default
namespace: prod
spec:
mtls:
mode: STRICT # Só aceita mTLS
# Authorization: service A pode falar com service B
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: b-from-a-only
namespace: prod
spec:
selector: { matchLabels: { app: service-b } }
rules:
- from:
- source:
principals: ["cluster.local/ns/prod/sa/service-a"]💡
Istio/Linkerd injetam sidecar (Envoy) que cuida de TLS termination + cert rotation. App não vê complexidade. Linkerd é mais leve; Istio mais features.
Quiz rápido
Qual é a premissa que o modelo de confiança zero abandona?
Alternativas práticas pra dev/time menor
- Tailscale: WireGuard + identidade via OIDC. Dev acessa prod read-only só com Google/GitHub login, ACL via tags, auto-expira.
- Cloudflare Zero Trust (Access + Warp): proteger apps internos sem VPN. User autentica via IdP; Access valida; sem VPN.
- AWS VPC Lattice / PrivateLink: comunicação entre VPCs sem IGW, com IAM authz.
- Teleport: bastion + identity-aware SSH/kubectl.
Checklist Zero Trust-ish pra time pequeno
- ☐ VPN empresarial → Tailscale (identidade em cada device).
- ☐ Bastion SSH → Teleport ou AWS SSM Session Manager.
- ☐ Acessos admin → Just-in-time elevation com aprovação (ex: JIRA+PR).
- ☐ Serviço-pra-serviço → mTLS via service mesh ou proxy.
- ☐ Secrets → Vault/AWS SM (sem long-lived em env).
- ☐ Audit log de TODA admin action, replicado imutável.
- ☐ Device trust check (MFA + device posture).
Perguntas frequentes
❓ O que confiança zero muda na prática?
Substitui a suposição de que a rede interna é confiável por verificação em cada requisição: identidade, dispositivo e permissão avaliados sempre. A consequência arquitetural é que estar dentro do perímetro deixa de ser autorização, e é isso que contém movimento lateral.
❓ Para que serve autenticação mútua entre serviços?
Para os dois lados provarem quem são, e não só o servidor — o que impede um serviço comprometido se passar por outro. Combinada com identidade de carga de trabalho de curta duração, ela substitui credencial estática entre serviços, que é o item mais difícil de rotacionar.
❓ Confiança zero exige malha de serviço?
Não exige. Ela é um conjunto de princípios; a malha é uma forma de implementar parte deles sem tocar em cada aplicação. Com poucos serviços, biblioteca compartilhada e portal de entrada bem configurado entregam o essencial com muito menos operação.
Fixando
Quiz rápido
O que a autenticação mútua entre serviços acrescenta em relação ao canal cifrado comum?
Quiz rápido
Qual alternativa prática existe para equipes pequenas que não vão operar uma malha de serviços?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…