Multi-tenancy é o vetor de risco favorito de auditores da ANPD e do próprio adversário. Um SaaS jurídico ou de saúde no Brasil hospeda dados de milhares de clientes sob uma mesma infra; um bug de autorização vira reportagem no Fantástico. Zero-trust não é buzzword: é a única postura defensável quando o perímetro é lógico.

Princípios operacionais

Antes da arquitetura, três premissas que qualquer decisão vai retomar:

1. Nenhum tráfego é confiável por origem. Requisições internas passam por autenticação e autorização iguais às externas.
2. Identidade é workload, não IP. IP muda, workload tem identidade criptográfica estável.
3. Isolamento é multi-camada. Se um layer falhar, o próximo deve segurar. Isso significa isolar em rede, em processo, em dados e em criptografia.

Camada 1 — Identidade de workload (mTLS + SPIFFE)

Cada workload recebe um SVID (SPIFFE Verifiable Identity Document) via SPIRE. mTLS entre todos os serviços é obrigatório; nada de "confia no service mesh porque está atrás do LB".

spiffe://varredura.com.br/prod/tenant-svc
spiffe://varredura.com.br/prod/billing-svc

Autorização policy-as-code (OPA/Rego) valida spiffe id + tenant id. Rotação de cert automática a cada 1 hora. Latência adicional média: 3-5ms — aceitável para o ganho.

Camada 2 — Isolamento por tenant

Três padrões, em ordem crescente de isolamento e custo:

• Schema-per-tenant (Postgres): um schema por cliente, mesma DB. Bom até 500-1000 tenants. Isolamento lógico + RLS (Row-Level Security) forçado por policy. Baixo custo, risco de bug de cross-tenant.
• Database-per-tenant: uma DB por cliente. Custo cresce, mas explosão de blast radius zera. Recomendado para setores regulados (saúde, financeiro).
• Cluster-per-tenant: kubernetes ou VPC dedicado. Só para tenants Tier 1 (bancos, governo). Custo alto, isolamento máximo.

Em qualquer padrão: tenant id como claim assinada em cada JWT, validada em cada handler, com RLS de defesa em profundidade.

CREATE POLICY tenant_isolation ON documents
  USING (tenant_id = current_setting('app.tenant_id')::uuid);
ALTER TABLE documents FORCE ROW LEVEL SECURITY;

O FORCE é essencial. Sem ele, o dono da tabela ignora a policy.

Camada 3 — Secrets

• Vault ou AWS Secrets Manager com rotação automática. Secrets em variáveis de ambiente é padrão nível 1 de maturidade.
• Envelope encryption: dados sensíveis do tenant cifrados com DEK, DEK cifrada com KEK por tenant. KEK vive no KMS, DEK cacheada em memória com TTL curto.
• Zero-knowledge de credenciais de terceiro: integrações do cliente com bancos/gateways passam por proxy que decifra just-in-time.

Camada 4 — Egress control

O maior ponto cego de arquiteturas zero-trust é saída. Ninguém audita para onde o servidor está mandando pacote — até virar SSRF e o backend chamar 169.254.169.254.

• Allowlist explícita de domínios externos por workload.
• Egress via proxy com policy em Rego. deny default.
• Metadata endpoint de nuvem só via IMDSv2, com hop limit 1.

Se você não conhece bem esse vetor, revise Anatomia de uma SSRF.

Camada 5 — Observabilidade

Zero-trust sem observabilidade é fé. Logs, métricas e traces estruturados com tenant id, spiffe id, request id como campos indexados. Retenção mínima de 90 dias em cold storage — a ANPD pode pedir prova de acesso.

• Detecção de anomalias comportamentais por tenant (spike de acessos, exfil rate).
• Alertas correlacionados: 10 tentativas de acesso a tenant diferente do JWT = investigação imediata.

Diagrama de fluxo

             ┌──────────────────┐
   cliente → │  API Gateway     │  TLS 1.3, JWT validated
             │  (WAF + rate lim)│
             └────────┬─────────┘
                      │ mTLS + SVID
        ┌─────────────┼─────────────┐
        │             │             │
   ┌────▼────┐   ┌────▼────┐  ┌─────▼─────┐
   │ tenant  │   │ billing │  │  audit    │
   │  svc    │   │  svc    │  │  svc      │
   └────┬────┘   └────┬────┘  └─────┬─────┘
        │ mTLS        │ mTLS        │
        │             │             │
   ┌────▼─────────────▼─────────────▼────┐
   │  Postgres (RLS forced per tenant)   │
   └─────────────────────┬───────────────┘
                         │
                    ┌────▼────┐
                    │  KMS    │  KEK por tenant
                    └─────────┘

  Egress ─────► Proxy (Rego policy, allowlist)
  Secrets ────► Vault (rotação 1h)
  Telemetria ─► OTLP → Loki + Tempo + Grafana

Checklist de implantação (90 dias)

| Semana | Entrega | Owner | |--------|---------|-------| | 1-2 | SPIRE em staging, mTLS entre 2 serviços piloto | Infra | | 3-4 | RLS + FORCE em todas as tabelas com dado de tenant | Backend | | 5-6 | Vault + rotação automática de credenciais críticas | Infra | | 7-8 | Egress proxy com allowlist | SRE | | 9-10 | OPA em todos os handlers, policy-as-code no repo | AppSec | | 11-12 | Observabilidade com tenant id em toda linha de log | SRE | | 13 | Red team focado em cross-tenant | Externo |

Como validar em produção

Arquitetura documentada e arquitetura em produção divergem. Um scanner externo contínuo cruza o comportamento real: tenta cross-tenant enumeration, valida tenant id nos handlers, detecta endpoints sem autenticação e regressões de RLS.

A Varredura testa a superfície da sua plataforma continuamente — inclusive cenários multi-tenant típicos — sem tocar em código-fonte. Rode agora e valide se a arquitetura desenhada é a arquitetura entregue.