Zero-trust não é produto — é uma decisão de design

Zero-trust virou marketing. Toda ferramenta de segurança agora é "zero-trust ready". Isso é um problema — porque zero-trust não é uma categoria de produto. É uma decisão arquitetural que afeta como você escreve cada linha de código que toca autenticação, autorização e acesso a dados.

O que zero-trust realmente significa

O princípio original de John Kindervag (2010): nunca confie, sempre verifique. Nenhuma rede é inerentemente confiável — nem a sua rede interna. Um usuário dentro do VPN não está automaticamente autorizado. Um serviço interno não confia automaticamente em outro serviço interno.

Como zero-trust se manifesta no código

• Cada API endpoint valida token — não assume que "veio de dentro" é seguro
• Service-to-service authentication com mTLS ou SPIFFE/SPIRE — sem "chamada interna implicitamente confiável"
• Principle of least privilege: cada serviço tem exatamente as permissões que precisa, nada mais
• Short-lived credentials: tokens com expiração de minutos, não horas
• Auditoria de todos os acessos: quem, o que, quando, de onde — sem exceções

O erro comum: tratar zero-trust como camada adicional

A maioria das empresas tenta adicionar zero-trust por cima de uma arquitetura existente. Coloca um API gateway, adiciona um SIEM, assina um serviço de "zero-trust network access". Isso é maquiagem — a arquitetura continua implicitamente confiando em contextos, serviços internos e redes.

Design zero-trust para uma nova API

// Middleware que aplica zero-trust em cada request
// Sem exceções para "chamadas internas" ou "serviços conhecidos"

export async function withZeroTrust(
  request: Request,
  handler: (req: Request, identity: VerifiedIdentity) => Promise<Response>
): Promise<Response> {
  // 1. Verificar token em TODA request — nunca assumir autenticado por contexto
  const token = request.headers.get("Authorization")?.replace("Bearer ", "");
  if (!token) return unauthorized("Missing token");

  // 2. Verificar criptograficamente (não apenas decodificar JWT)
  const identity = await verifyToken(token);
  if (!identity) return unauthorized("Invalid token");

  // 3. Verificar expiração rigorosa — sem "grace period"
  if (Date.now() > identity.exp * 1000) return unauthorized("Token expired");

  // 4. Verificar escopo específico para ESTE endpoint
  const requiredScope = getRequiredScope(request);
  if (!identity.scopes.includes(requiredScope)) return forbidden("Insufficient scope");

  // 5. Logar acesso — todos, sem exceção
  await auditLog({ identity, request, timestamp: Date.now() });

  return handler(request, identity);
}

Quando zero-trust complica demais

Zero-trust add overhead operacional real. Para um sistema interno sem dados sensíveis ou compliance regulatório, pode ser overkill. A decisão de adotar zero-trust deve ser baseada no modelo de ameaça — não no buzzword do trimestre.

• Zero-trust é obrigatório se: dados financeiros, dados de saúde, compliance regulatório (PCI-DSS, LGPD sensível)
• Zero-trust é recomendado se: múltiplos times com acesso ao mesmo sistema, dados de usuários em escala
• Zero-trust pode ser opcional se: sistema interno sem dados sensíveis, equipe pequena com controle físico do ambiente

A decisão que importa

A pergunta certa não é "qual produto zero-trust comprar". É: em cada ponto do meu sistema onde um request chega, eu estou verificando explicitamente identidade, autorização e escopo — ou estou confiando implicitamente em algum contexto? Cada trust implícito é uma vulnerabilidade em potencial.