A ideia por baixo

O modelo antigo era um perímetro: prove quem você é uma vez na fronteira e, lá dentro, você é confiável. Ele falhou por razões hoje óbvias - o lado de dentro é onde o atacante acaba chegando de todo jeito, a fronteira deixou de existir quando as aplicações foram para o datacenter dos outros, e um notebook comprometido herdava a confiança do prédio inteiro.

O zero trust é a resposta e, tirada a linguagem de fabricante, é uma frase: nenhuma requisição é confiável por causa de onde veio. Toda decisão de acesso é tomada por requisição, contra a identidade, o dispositivo e o contexto, independentemente da posição na rede.

Duas consequências decorrem e são fáceis de perder.

Estar na rede corporativa deixa de ser credencial. É esse o ponto inteiro, e é também por que a adoção é difícil: uma quantidade enorme de comportamento legado pressupõe que a localização na rede concede acesso.

O ponto de decisão de política vira infraestrutura crítica. Você não removeu a confiança; você a mudou de lugar, da fronteira de rede para o sistema de identidade e o motor de política. Eles agora decidem tudo, o que os torna o alvo do atacante e aquilo cuja queda para todo o trabalho.

Origens: a ideia é mais velha que o slogan

O vocabulário é recente; o argumento não é.

O Jericho Forum e a desperimetrização (2004). Um grupo de diretores de segurança de grandes empresas argumentou publicamente que o perímetro endurecido já estava falhando - terceirização, extranets e trabalho móvel tinham tornado a fronteira sem sentido - e que a proteção precisava migrar para o dado e para a transação. Estavam descrevendo zero trust antes de a expressão existir, e foram em boa parte ignorados porque não havia nada a comprar.

O termo (2010). Um analista de mercado batizou o modelo de zero trust e enunciou a regra que ainda o define: nunca confie, sempre verifique. O batismo importou mais que a novidade, porque deu categoria de compra a um argumento de arquitetura.

BeyondCorp (de 2014 em diante). Depois de uma invasão ligada a um Estado, o Google publicou um programa de vários anos para remover por completo o status privilegiado de sua rede corporativa: cada requisição autenticada e autorizada por dispositivo e usuário, sem e sem sub-rede confiável. É a primeira implementação crível em larga escala, e é a razão de o modelo ter deixado de ser teoria - uma organização demonstrou que dava para operar.

SP 800-207 (2020). A arquitetura ganhou definição neutra de fabricante: um motor de política decide, um administrador de política executa, e um ponto de aplicação de política fica no caminho do tráfego. Essa decomposição é o que vale guardar, porque todo produto do setor é algum arranjo desses três, e nomeá-los permite comparar ofertas que usam linguagens de marketing incompatíveis.

A inflexão do trabalho remoto (2020). Quando forças de trabalho inteiras saíram do prédio, o modelo de perímetro falhou operacionalmente, e não filosoficamente, e o orçamento veio atrás. A maioria das implantações atuais data desse momento, o que vale lembrar ao avaliar alegações de maturidade.

O que o ZTNA (acesso à rede zero trust) de fato é

O é a categoria concreta de produto: em vez de pôr o usuário na rede com uma VPN (rede privada virtual) e deixá-lo alcançar tudo o que as rotas permitirem, um intermediário autentica usuário e dispositivo e então o conecta a uma aplicação específica.

A melhoria genuína não é a criptografia, que a VPN já tinha. É a ausência de movimento lateral. Uma sessão comprometida alcança as aplicações para as quais aquela sessão foi autorizada, e não consegue varrer a sub-rede, porque nunca esteve na sub-rede. Esse é um ganho arquitetural real e é a razão de a categoria existir.

Duas propriedades que vale entender antes de comprar:

As aplicações ficam invisíveis, e não apenas protegidas por firewall. A maioria das implementações faz o conector discar para fora, em direção ao intermediário, então não há porta de entrada a ser encontrada. Isso remove uma classe inteira de exposição - não se ataca o que não responde.

O intermediário enxerga tudo. Todo acesso passa por ele, o que é excelente para registro e é uma concentração genuína de risco e de dependência. Se o intermediário cai, o trabalho para; se é comprometido, tudo o que ele fronteia fica exposto.

O que o SASE (borda de serviço de acesso seguro) de fato é

O não é uma tecnologia. É o empacotamento de funções de rede e de segurança - gateway web seguro, corretor de acesso à nuvem, ZTNA, firewall, às vezes (rede de longa distância definida por software) - entregues a partir dos pontos de presença de um provedor, em vez de caixas suas.

A descrição honesta é que o SASE é um modelo de compra e de operação. As funções são as que você já tinha; o que muda é que rodam na borda de outra pessoa, são cobradas por assinatura, e são geridas num console só.

Os benefícios reais são reais: política consistente para usuários que já não estão em escritórios, menos hardware a renovar, e um lugar único para expressar regras que antes moravam em quatro produtos.

Os custos reais são igualmente reais, e são os que os diagramas omitem. Seu tráfego agora atravessa a infraestrutura de um provedor, então a queda dele é a sua queda e a jurisdição dele é a sua jurisdição. A portabilidade de política entre fabricantes é ruim, então o custo de troca é alto por construção. E isso é risco de concentração em estado puro: você tornou um fornecedor dependência de cada conexão de cada usuário.

A arquitetura, nos termos do padrão

O motor de política avalia uma requisição contra identidade, estado do dispositivo, sensibilidade do recurso e contexto, e devolve uma decisão. É o cérebro, e é tão bom quanto os sinais que recebe.

O administrador de política transforma essa decisão em instrução - estabelecer a sessão, emitir o token, derrubá-la.

O ponto de aplicação de política é o componente no caminho que de fato permite ou bloqueia: um intermediário, um proxy, um agente no endpoint, ou um sidecar ao lado da carga de trabalho.

Três consequências decorrem, e importam na operação.

A confiança é mudada de lugar, não removida. O motor e o provedor de identidade viram os sistemas mais críticos que você opera, e o alvo mais valioso do parque.

Toda decisão precisa de sinal. Postura de dispositivo, garantia de identidade, classificação de recurso e contexto comportamental precisam vir de algum lugar, e cada fonte é uma dependência com exatidão e perfil de queda próprios.

A colocação do ponto de aplicação decide o que você consegue proteger. Um intermediário na frente das aplicações não policia tráfego que nunca passa por ele, e é por isso que as implantações terminam com uma lista de exceções de tudo que não pôde ser posto atrás do ponto de aplicação.

Modelo de sessão e a questão da interoperabilidade

Sessões, não perímetros. As decisões são por requisição em princípio e por sessão na prática, então os parâmetros de segurança reais são duração da sessão, frequência de reavaliação, e o que acontece quando a postura muda no meio dela. Tokens de vida longa reintroduzem em silêncio o modelo que você estava substituindo.

Os protocolos envolvidos são padrão, e a política não é. Autenticação e federação se apoiam em padrões bem estabelecidos - OpenID Connect e para identidade, TLS mútuo para identidade de carga de trabalho, e cada vez mais credenciais resistentes a phishing por baixo. Expressão de política, sinais de postura de dispositivo e pontuação de risco são proprietários em todo produto, então as partes difíceis de escrever são exatamente as que não portam entre fabricantes. Essa assimetria é o custo de troca, e raramente está no slide.

O cenário de fabricantes, por categoria

  • Plataformas centradas em identidade - Okta, Microsoft Entra, Ping. O motor de política mora junto da identidade, o que é arquiteturalmente coerente porque identidade é o sinal que mais importa; você está consolidando num provedor de identidade e deveria precificar as consequências disso.
  • Nuvens de rede e segurança - Zscaler, Netskope, Cloudflare, Cisco, Palo Alto, Fortinet. Aplicação na borda do provedor, entregando ZTNA ao lado de controles de web e de aplicações em nuvem - o formato prático que a maioria das compras de SASE assume.
  • Substitutos de acesso remoto - fabricantes posicionados principalmente contra a VPN. Os mais rápidos a mostrar valor, os de escopo mais estreito; o risco é um projeto que para no acesso remoto e se reporta como zero trust.
  • Microssegmentação e identidade de carga de trabalho - Illumio, service meshes e similares, aplicando entre cargas em vez de na borda do usuário. Complementares aos anteriores, e não concorrentes, e as duas metades com frequência são compradas por equipes diferentes que nunca reconciliam a política.
  • Padrões abertos e construção própria - SPIFFE e SPIRE para identidade de carga, um provedor de identidade mais um proxy para acesso de usuário. Trabalho de verdade, sem licença, e portabilidade completa das partes que são padronizadas.

A pergunta estrutural a fazer a qualquer um deles é a mesma: onde fica o ponto de aplicação, o que acontece com o tráfego que não consegue passar por ele, e como fica a sua política no dia em que você sair?

O que nada disso resolve

Diga esta parte sem rodeio, porque o marketing não diz.

Uma sessão válida continua sendo uma sessão válida. Se um atacante rouba credenciais por phishing e completa a autenticação, o zero trust o admite - corretamente, pela própria lógica dele. É por isso que a questão da autenticação resistente a phishing fica embaixo da arquitetura inteira; um motor de política só pode ser tão bom quanto a afirmação de identidade que recebe.

Postura de dispositivo é alegação, não fato. Os sinais vêm de um agente rodando numa máquina que pode já estar comprometida, e um endpoint comprometido consegue se reportar saudável.

Falhas de camada de aplicação seguem intocadas. Se a aplicação tem um bug de injeção, o usuário perfeitamente autorizado chega até ele perfeitamente.

O legado continua legado. Os sistemas que não falam identidade moderna - o controlador industrial, o appliance antigo, a coisa que ninguém vai recertificar - acabam numa exceção, e as exceções são para onde o risco migra. Toda implantação real tem as suas, e a pergunta útil a um fabricante não é como o produto dele funciona, e sim o que acontece com as suas exceções.

Adotando sem teatro

  • Comece por um inventário de aplicações e de quem deve alcançá-las. Esse inventário é o projeto de verdade; o produto é a parte fácil.
  • Faça identidade primeiro. Zero trust sobre autenticação fraca move a confiança para um lugar igualmente fácil de derrotar.
  • Espere a lista de exceções, e trate-a como um registro com donos e datas, não como nota de rodapé.
  • Planeje para o intermediário cair, já que você converteu uma dependência de rede numa dependência de serviço.
  • Trate SASE como decisão de fornecedor, com as perguntas que se faz a qualquer fornecedor: caminho de saída, jurisdição, histórico de quedas, e como fica a sua política no dia em que você sair.

O enquadramento que vale guardar

Zero trust é um bom princípio mal servido pelo próprio vocabulário. O princípio - decidir por requisição, e não por localização - está certo, e o setor seria mais saudável se ele fosse discutido como arquitetura com trocas em vez de produto com selo.

A troca é a mesma que atravessa este site inteiro: você não eliminou a confiança, concentrou-a em algum lugar mais novo e mais visível. Em geral isso é melhoria, porque confiança concentrada pode ser monitorada, versionada e auditada de um jeito que a confiança ambiente da rede nunca permitiu. Mas é uma mudança de lugar, e a primeira pergunta sobre qualquer dependência mudada de lugar é o que acontece quando ela falha.