Zero Trust não é produto, é processo: implementando autenticação e autorização granular em microservices

O problema real não é autenticar, é autorizar

A maioria dos incidentes de segurança em arquiteturas de microservices não acontece na borda. Acontece no interior. Um serviço de notificações comprometido consegue ler dados de clientes porque ninguém restringiu o que ele pode acessar, só se ele é autenticado.

Esse é o erro fundamental: confundir autenticação (quem é você?) com autorização (o que você pode fazer?). Zero Trust exige que você trate cada uma dessas perguntas separadamente e que a resposta seja sempre contextual.

A arquitetura que funciona em produção

A implementação que vou descrever é a que rodou em um cliente com 23 microservices, 14 equipes e um volume de 40 milhões de requisições por dia. Não é teoria.

Camada 1: Identidade de workload com SPIFFE/SPIRE

Cada serviço precisa de uma identidade criptográfica, não só um segredo compartilhado. SPIFFE (Secure Production Identity Framework for Everyone) resolve isso gerando X.509 SVIDs (SPIFFE Verifiable Identity Documents) automaticamente, com rotação a cada 24 horas.

helm install spireserver spire/spireserver n spire \
  set spireConfig.serverDataDir=/opt/spire/data \
  set tetenantagent.enabled=false

# Agent (em cada nó)
helm install spireagent spire/spireagent n spire \
  set spireConfig.serverAddress=spireserver.spire.svc.cluster.local

# Registrar um workload
kubectl exec n spire spireagentxxx c spireagent  \
  /opt/spire/bin/spireagent entry create \
  spiffeID spiffe://dominio.com/ns/sre/sa/servicopagamentos \
  parentID spiffe://dominio.com/ns/spire/node/sre \
  selector k8s:ns_label:sre:true

O resultado prático: cada pod tem um certificado X.509 rotacionado automaticamente. Nenhum secret no Git, nenhum token hardcoded. Se um workload é comprometido, o certificado é revogado em minutos pelo SPIRE Server.

Camada 2: mTLS automático via service mesh

Com SPIFFE emitindo identidades, o service mesh (Linkerd ou Istio) aplica mTLS (mutual TLS) entre todos os serviços sem configuração manual por par. O tráfego entre serviços é criptografado por padrão.

# Linkerd: policy para permitir apenas tráfego autenticado
externallyAuthenticatedIngress:
  namespaceSelector:
    matchExpressions:
       key: mesh.inbound.authorization
        operator: In
        values:
           paymentprocessor
  authenticationRefs:
     kind: ServiceAccount
      name: paymentsservice
     kind: ServiceAccount
      name: frauddetection

Tradeoff real: mTLS adiciona latência. Em benchmarks com Linkerd 2.14, o overhead é de 0.5ms a 2ms por hop. Em caminhos críticos de latência (transações, pagamentos), você vai sentir. Mitigação: segmentação estratégica, mTLS everywhere, mas com circuit breakers bem configurados para degradação gradual.

Camada 3: Autorização granular com OPA e Rego

Aqui está onde a maioria falha. Autorização não é só "tem token válido?"; é "este serviço, neste contexto, com este recurso, pode fazer esta ação?"

OPA (Open Policy Agent) permite policy as code, versionado no Git, testável em CI, e com semântica declarativa.

# policy/authz_payments.rego
package payments.authz

default allow := false

# Regra principal: serviço interno autenticado pode ler transações
allow if {
    input.source.spiffe_id == "spiffe://dominio.com/ns/payments/sa/paymentreader"
    input.action == "read"
    input.resource.type == "transaction"
    input.resource.customer_id == input.subject.customer_id
}

# Serviço de antifraude pode inspecionar, mas não modificar
allow if {
    input.source.spiffe_id == "spiffe://dominio.com/ns/fraud/sa/fraudanalyzer"
    input.action == "inspect"
    input.resource.type == "transaction"
    count(input.resource.fraud_score) == 0  # Não pode escrever score
}

# Bloquear crosstenant access
allow if {
    input.resource.tenant_id != input.subject.tenant_id
    not input.source.spiffe_id in {
        "spiffe://dominio.com/ns/admin/sa/platformadmin",
        "spiffe://dominio.com/ns/audit/sa/auditlogger"
    }
}

# Deployment do OPA como sidecar (formato Kubernetes)
spec:
  containers:
     name: opa
      image: openpolicyagent/opa:0.61.0
      args:
         "run"
         "server"
         "configfile=/config/policy/authz_payments.rego"
         "tlscertfile=/certs/tls.crt"
         "tlsprivatekeyfile=/certs/tls.key"
         "authentication=mtls"
         "authorization=off"
      ports:
         containerPort: 8181
      volumeMounts:
         name: policy
          mountPath: /config/policy
          readOnly: true
     name: paymentsservice
      image: paymentsservice:v2.3.1
      env:
         name: OPA_URL
          value: "http://localhost:8181"

Os números que importam

Em 11 meses de operação, esta arquitetura entregou:

Métrica	Antes (secrets compartilhados)	Depois (Zero Trust completo)
Tempo médio de detecção de comprometimento de workload	72 horas	8 minutos
Incidentes de acesso não autorizado entre serviços	3/mês	0
Tempo de onboarding de novo serviço	2 dias	45 minutos
Revogação de acesso (exemplo: desligamento de equipe)	4 horas	Imediato
Overhead de latência por requisição	0	1.2ms (p99)

O overhead de 1.2ms parece contraintuitivo, mas é aceitável quando você considera o que não gastou em incidentes. Um único vazamento de dados na LGPD custa, em média, R$ 500 mil a R$ 2 milhões em multas e remediação.

Armadilhas comuns que você vai encontrar

"Fazemos Zero Trust com só o API Gateway": Zero Trust não é um produto de borda. Se o tráfego entre serviços usa secrets compartilhados ou sem TLS, você não tem Zero Trust.

Policy explosion: Começar com 50 regras de autorização para cada serviço gera complexidade impalatável. Comece com denybydefault e libere apenas o caminho crítico (golden path).

Múltiplos identity providers: Se cada equipe escolhe seu IdP (Auth0, Okta, Cognito, Keycloak), você termina com federations complexas e auditabilidade zero. Padronize em um IdP corporativo com SPIFFE como identidade de workload.

Testes de policy em produção: OPA permite unit tests com opa test. Não suba policies sem cobertura de teste.

# Teste sua policy antes do deploy
opa test ./policy/authz_payments.rego v

# Saída esperada:
# PASS: authz_payments (authz_payments_test)
#   ✓ allow with valid paymentreader  (3ms)
#   ✓ deny with invalid tenant         (1ms)

Checklist de implementação

• Inventariar todas as chamadas entre serviços (saída: matriz de comunicação)
• Substituir secrets compartilhados por SPIFFE SVIDs
• Habilitar mTLS no service mesh (preferencialmente Linkerd, menor overhead)
• Definir policy de autorização por domínio (pagamentos, usuários, dados)
• Implementar OPA como sidecar nos serviços críticos
• Escrever testes de policy para cada regra Rego
• Configurar rotação automática de certificados (SPIRE: 24h default)
• Instrumentar métricas: latência de auth, taxa de deny, uso de SVIDs
• Implementar circuit breakers para degradação gradual quando OPA está indisponível
• Definir processo de emergência para revogação instantânea (SPIRE supports bundle revocation)

Zero Trust não é um projeto que termina. É uma postura operacional. A arquitetura que descrevi não é bala de prata, é um framework que você adapta ao ritmo da sua organização. O fundamental é começar pela identidade de workload (SPIFFE) porque sem identidade confiável, nada do resto funciona.

---

Se sua empresa está migrando para microservices ou revisando a postura de segurança entre serviços, posso apresentar em 30 minutos como estruturamos isso na Eficify, sem compromisso.

Fale com um especialista da Eficify