Arquitetura Zero Trust

Resumo curto

Zero Trust (ZT) é um modelo de segurança em que o perímetro de rede já não é considerado uma área de confiança. Cada solicitação (user→app, service→service, device→network) é autenticada, autorizada e criptografada de acordo com os sinais contextuais (identidade, estado do dispositivo, localização, risco, comportamento). O objetivo é minimizar o blast radius, reduzir o risco de movimento lateral e simplificar a complacência.

Princípios Básicos Zero Trust

1. Não há confiança clara: a confiança não é herdada da rede/VPN/ASN.
2. O acesso é mínimo, a política «fornecer apenas o que você precisa agora».
3. Verificação contínua: sessões e tokens são regularmente superestimados por risco e contexto.
4. Suposição de comprometimento: segmentação, observabilidade, containment rápido e rotação de chaves.
5. Criptografia em todo o lado: TLS 1. 2+/1. 3 e mTLS dentro de dados-planos protegidos por DNS, segredos em KMS/HSM.

Paisagem de destino e domínios de controle

Identidade: pessoas (IdP: SSO, MFA, passkeys/FIDO2), máquinas (SPIFFE/SVID, x509/mTLS).
Dispositivos: conformidade com políticas (MDM/EDR, disco encriptado, patches, jailbreak/root - proibido).
Rede: Microssegmentação L3/L7, ZTNA/SDP, serviço-mesh (Envoy/Istio/Linkerd).
Aplicativos/API: mTLS, OIDC/JWT, assinaturas de consulta (HMAC), rate limits, DLP/camuflagem.
Dados: Classificação (Público/Confidential/Restricted), toquenização/criptografia em campos.
Observabilidade: logs centralizados de autenticação/autorização, analista comportamental, SLO/SLA.

Arquitetura de arbitragem (no corte de planos)

Controle Plane: IdP/CIAM, PDP/PEP (OPA/Envoy), diretórios de políticas, PKI/CA, certificação de dispositivos.
Data Plane: Acesso proxy (ZTNA), sidecar-proxy (Envoy) para mTLS e política L7, hall de serviço/API GW.
Management Plane: catálogo de serviços, CMDB, CI/CD, gestão de segredo (Vault/KMS), auditoria centralizada.

1. Identificação (SSO + phishing-resistant MFA) → 2) Avaliação de dispositivo (MDM posture) → 3) O proxy ZTNA estabelece uma mTLS ao aplicativo → 4) PDP (políticas) para decidir com base em atributos (ABAC/RBAC) → 5) uma reavaliação contínua de risco (tempo, geo, anomalias).

Identidade e autorização

IdP/SSO: OIDC/SAML, MFA padrão, preferencialmente FIDO2 (passkeys).
RBAC/ABAC: rol + atributos de contexto (status do dispositivo, departamento, perfil de risco).
Acesso Just-In-Time (JIT): privilégios temporários com revogação automática; break-glass - regulado.
mTLS para máquinas: SPIFFE/SVID ou PKI interno com certificados de curta duração; edição rotativa automática.

Dispositivos e contexto

Verificação de conformidade (posture): versão OS/EDR, disco encriptado incluído, firewall; não-compliant → acesso ao mínimo ou bloco.
Avaliação: device identity + signed attestations (MDM/Endpoint).
Restrições de rede: unidade de túneis de terceiros, DNS corporativo forçado, proteção contra vazamentos DNS/WebRTC.

Rede e microssegmentação

Rejeição de VLAN plano: em vez disso, segmentos/ERRF e política em L7.
Serviço Mesh: sidecar-proxy fornece mTLS, permissão de política (OPA/EnvoyFilter), telemetria.
ZTNA/SDP: acesso a um aplicativo específico, não à rede; kliyent↔broker↔app, política no PDP.
Remote Access: Substituindo o VPN «gordo» por app proxy; túneis fallback limitados por rotas/portas.

Políticas e motores de solução

PDP/PEP: Policy Decision Point (OPA/Styra, Cedar и пр.) + Policy Enforcement Point (Envoy/Istio/Gateway).
Modelo de política: regras declaratórias (Rego/Cedar), atributos estáticos e contextuais, avaliação de risco.

rego package access. http

default allow = false

allow {
input. user. role == "support"
input. request. path == "/admin/tickets"
input. device. compliant == true time. now_hh >= 8 time. now_hh <= 20
}

Traçar soluções: logue 'input '/' result'/' explain' para a auditoria.

Criptografia e confiança padrão

TLS 1. 2+/1. 3 em todo o lado, criptografados rigorosos, HSTS, OCSP stapling.
mTLS dentro: servis↔servis apenas com certificados mútuos; chaves curtas (relógios/dias).
Segredos: KMS/HSM, Confidenciais Dinamic (Vault), TTL curtos, least-private para aplicativos.

Observabilidade, SLO e resposta

• Autenticação e autorização (%), p95 tempo de decisão PDP, p95 TLS-handshake.
• Porcentagem de pedidos bloqueados pela política (anomalias/falsas).
• Disponibilidade de corretores ZTNA e controlador Mesh.
• Proporção de dispositivos e tendências compliant.

• "Disponibilidade ZTNA ≥ 99. 95 %/m; p95 authZ decision ≤ 50 мс».
• "Taxa de solicitação de mTLS ≥ 99. 9%».
• "Não mais do que 0. 1% de falhas falsas de acesso/dia".

Alarting: picos de deny, degradação p95 apertos de mão, cadeias de nevalida, queda da proporção de dispositivos compliant, anomalias geográficas/ASN.

Transição do perímetro para Zero Trust: mapa de trânsito

1. Inventário: Aplicações, fluxos de dados, consumidores, sensibilidade (PII/cartões/pagamentos).
2. Identidade e MFA: SSO e phishing-resistant MFA para todos.
3. Contexto de dispositivos: MDM/EDR, políticas básicas de conformidade, bloco não-compliant.
4. Microssegmentação de rotas prioritárias: pagamentos, back office, adminka; digitar mTLS.
5. ZTNA para acesso ao usuário: publicar aplicativos via proxy, remover «VPN amplo».
6. Políticas ABAC: PDP centralizado, regras declaratórias, auditoria.
7. Extensão para serviço-mesh: S2S mTLS, política L7, telemetria.
8. Automação e SLO: alerting, testes de política (CI político), dias de game "e se IdP não estiver disponível? ».

Especificidades para iGaming/Fintech

Segmentação rígida de domínios: pagamentos/PII/antifrod/conteúdo - perímetros e políticas individuais; acessível apenas pelo ZTNA.
Interação com PSP/bancos: allow-list por ASN/faixa, mTLS a endpoentes PSP, monitoramento do Time-to-Wallet e falhas de authZ.
Provedores de conteúdo e parceiros: disponibilidade temporária JIT para API, tokens com TTL curto, auditoria de integrações.
Complacência: PCI DSS/GDPR - Minimização de dados, DLP/pseudonimização, registro de acessibilidade a tabelas sensíveis.

Segurança das cadeias de fornecimento e CI/CD

Assinaturas de artefatos (SLSA/Provenance): assinaturas de contêineres (cosign), política de admissão em K8s.
SBOM e vulnerabilidade: geração de SBOM (CycloneDX), policy-gate em pipline.
Segredos em CI: Federação OIDC para KMS na nuvem; proibição de chaves estáticas.
Rotações: frequentes, automáticas; revoke forçado em incidentes.

Erros típicos e anti-pattern

«ZTNA = novo VPN»: publicar uma rede em vez de aplicativos - não Zero Trust.
Não há verificação de dispositivos: MFA está disponível, mas dispositivos infectados/rodados são acessados.
Um único super usuário não tem JIT ou papéis separados.
Políticas de código de serviço: impossibilidade de auditoria/atualização centralizada.
parcial: parte dos serviços sem é um caminho «buraco».
Zero UX: excesso de solicitações MFA, falta de SSO; resultado: resistência aos comandos.

Mini-hyde para escolha de tecnologia

Acesso dos usuários: Corretor ZTNA/SDP + IdP (OIDC, FIDO2 MFA).
Segurança Interna: Serviço-mesh (Istio/Linkerd) + OPA/Envoy authZ.
PKI: SPIFFE/SVID ou Vault PKI com TTL curto.
Políticos: OPA/Rego ou Cedar; armazenar em Git, verificar em CI (policy-tests).
Logi e telemetria, OpenTelemetry → análise centralizada, detecção de anomalias.

Exemplos de configuração (fatias)

Envoy (mútual-TLS entre os serviços)

yaml static_resources:
listeners:
- name: listener_https filter_chains:
- filters:
- name: envoy. filters. network. http_connection_manager typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. network. http_connection_manager. v3. HttpConnectionManager route_config: { name: local_route, virtual_hosts: [] }
transport_socket:
name: envoy. transport_sockets. tls typed_config:
"@type": type. googleapis. com/envoy. extensions. transport_sockets. tls. v3. DownstreamTlsContext common_tls_context:
tls_params: { tls_minimum_protocol_version: TLSv1_2 }
tls_certificates:
- certificate_chain: { filename: /certs/tls. crt }
private_key: { filename: /certs/tls. key }
validation_context:
trusted_ca: { filename: /certs/ca. crt }
require_signed_certificate: true

OPA/Rego: acesso a relatórios apenas a partir de «finance», a partir de dispositivos compliant, durante o horário de trabalho

rego package policy. reports

default allow = false

allow {
input. user. dept == "finance"
input. device. compliant == true input. resource == "reports/profit"
time. now_hh >= 8 time. now_hh <= 21
}

Folha de cheque da implementação do Zero Trust

1. Incluir SSO e FIDO2 MFA para todos os usuários e almirantes.
2. Digite device posture (MDM/EDR) bloqueado não-compliant.
3. Traduzir acesso do usuário para ZTNA (per-app), deixar VPN apenas para canais S2S estreitos.
4. No interior, é padrão + certificados de curta duração.
5. Centralizar políticas (PDP/OPA), armazenar em Git, testar em CI.
6. Segmentar domínios sensíveis (pagamentos/PII/back office) e limitar east-west.
7. Ajustar telemetria, SLO e alerting para auth/authZ, mTLS, sinais posturais.
8. Realizar «game days» (falha de IdP, fuga de chaves, queda de corretor) e fixar SOP/reversão.

FAQ

O Zero Trust substitui o VPN por completo?
Para o acesso do usuário, sim, a favor do ZTNA. Para as estradas S2S, o VPN/IPsec pode permanecer, mas com políticas mTLS e rigorosas.

A ZT pode piorar o UX?
Se não for inteligente. Com SSO + FIDO2, MFA adaptável e per-app de acesso UX geralmente melhora.

É necessário implementar o serviço de mesh?
Nem sempre. Mas para um grande ambiente de microsserviço, mesh simplifica radicalmente a mTLS/política/telemetria.

Resultado

Zero Trust não é um produto, mas uma disciplina arquitetônica: identidade como novo perímetro, contexto de dispositivos, acesso de aplicativos (ZTNA), microssegmentação e mTLS em todo o lado, políticas centralizadas e confiabilidade mensurável. Seguindo o mapa e a folha de cheque, você reduz a superfície do ataque, acelere a auditoria e obtenha segurança sustentável sem «confiança padrão».