O jeito mais fácil de entender o Zscaler (ZTE) é pelo que ele não é: ele não é um perímetro levado para a nuvem. É uma espécie de central telefônica distribuída pelo mundo, uma arquitetura de proxy em que cada conexão termina num ponto de aplicação de política (enforcement point) da Zscaler, é identificada e inspecionada e só então é completada até o destino como uma conexão nova. As origens se conectam ao Exchange; o Exchange se conecta aos destinos. Nenhum tráfego passa direto; tudo passa por um intermediário. Guarde essa frase e o resto da plataforma deixa de ser uma lista de produtos e passa a ser uma lista de consequências.
O ponto de aplicação de política: o Public Service Edge
Quem faz o trabalho nessa arquitetura é o , o nome atual que a Zscaler dá aos nós de aplicação de política instalados nos data centers dela pelo mundo (o material mais antigo fala em ZEN, Zscaler Enforcement Node; vale saber da troca de nome ao ler a documentação). Um Service Edge termina a sessão do usuário ou da localidade (location), verifica a identidade, aplica a política e abre a conexão até o destino. A documentação da Zscaler é precisa sobre o funcionamento: os dados dos pacotes ficam em memória para inspeção e depois são encaminhados ou descartados conforme a política (os Service Edges nunca gravam em disco o payload, ou seja, o conteúdo do tráfego), enquanto os logs de transação são comprimidos, tokenizados e enviados por TLS para a infraestrutura de logs. O mesmo conceito de Service Edge existe também numa versão privada: instâncias single-tenant (exclusivas de uma organização) que a organização hospeda no próprio site ou na própria nuvem, gerenciadas pela Zscaler. É a mesma aplicação de política, só que mais perto.
Proxy, não roteador: o que se ganha com isso
Como cada sessão termina no Service Edge, em vez de ser roteada através dele, o Exchange enxerga transações de aplicação completas, e não pacotes soltos em trânsito. É por isso que a interceptação de TLS é um recurso central, e não um acessório pendurado depois: o Service Edge é, de propósito, um , que decifra o tráfego onde a política manda, inspeciona uma única vez o conteúdo em claro e aplica cada engine habilitado a esse único fluxo decifrado (filtragem de URL, análise de malware, proteção de dados), antes de cifrar de novo e seguir até o destino. Uma terminação, uma inspeção, vários vereditos. É também isso que torna a escala da plataforma horizontal: em cada nó, as sessões não guardam estado (são stateless), então a capacidade cresce com mais edges, e os usuários são simplesmente direcionados ao edge saudável mais próximo.
Ser um proxy tem uma segunda consequência, que molda os projetos: o Exchange é alcançado por encaminhamento (forwarding), e não por tabelas de roteamento. O tráfego precisa ser mandado até ele de propósito, por um agente no dispositivo, por um túnel saindo da localidade ou por uma configuração de proxy, e é exatamente por isso que a decisão sobre os métodos de encaminhamento é a primeira conversa de projeto de verdade em qualquer implantação.
Três serviços, uma central
Os nomes dos produtos são posições diferentes na mesma central. O Zscaler Internet Access () cuida da saída: usuários e localidades se conectam ao Exchange, e o Exchange se conecta à internet e ao SaaS em nome deles, aplicando no caminho os engines de secure web gateway, de firewall e de proteção de dados. O Zscaler Private Access () cuida do acesso de entrada sem abrir nenhuma conexão de entrada: as aplicações privadas nunca ficam expostas; em vez disso, os App Connectors instalados ao lado das aplicações abrem conexões de saída até o Exchange, os usuários se conectam ao Exchange do lado deles, e o Exchange costura as duas conexões de saída, por aplicação e por sessão. O Zscaler Digital Experience () cuida da medição: como o caminho dos dados passa pelo Exchange, os mesmos pontos de observação medem a experiência (a saúde do dispositivo, da rede e da aplicação) de ponta a ponta.
A promessa de zero trust está no modelo de conexão do ZPA mais do que em qualquer outro lugar: o usuário é conectado a uma aplicação que ele está autorizado a usar, e nunca é colocado numa rede. Não existe uma rede interna plana por onde se mover lateralmente, porque não existe lado de dentro: só conexões intermediadas, uma por sessão. Uma VPN (rede privada virtual) estende a rede até o usuário; o Exchange faz o contrário: não estende nada e intermedeia tudo.
A arquitetura vista por quem opera
Daí saem três hábitos. Primeiro: a identidade é a tabela de roteamento. A política depende de quem e do que se conectou, então a integração de identidade é infraestrutura, e não acessório. Segundo: o Service Edge é o ponto de observação. No troubleshooting, pense em dois trechos, da origem até o Edge e do Edge até o destino, porque é literalmente assim que a conexão existe. Terceiro: as fronteiras da criptografia são decisões de política. O que o Exchange pode decifrar, ele pode inspecionar; o que ele não deve decifrar, ele só consegue julgar por fora. Cada artigo seguinte desta série examina de perto uma dessas consequências.
Esta série, em ordem
Este artigo abre a série O Zero Trust Exchange da Zscaler. Ele coloca o ZIA, o ZPA e o ZDX numa mesma central; as partes seguintes acompanham a plataforma de fora para dentro e de volta para fora: como o tráfego chega lá, como o endpoint decide e como fazer o troubleshooting dele, o que o estado do dispositivo acrescenta, a visão do SaaS, a nota de experiência, os logs e quem mudou o quê, os relatórios que a diretoria lê, e três cenários que juntam tudo: um alerta de exfiltração, uma plataforma que muda sozinha e uma fusão.
- Tipos de túnel Zscaler: Z-Tunnel, GRE e IPsec, com os números. para dispositivos, e para sites: três túneis que não são intercambiáveis, com os números.
- Perfis do Client Connector: onde o endpoint decide como encaminhar o tráfego. O comportamento vem de dois documentos de configuração, e um deles, o , decide como o tráfego sai do dispositivo em cada estado de rede.
- Troubleshooting do Client Connector: o menu de diagnóstico e as quatro primeiras verificações. Os estados de conexão, os logs exportados e as quatro primeiras verificações quando um usuário não consegue acessar a internet.
- Postura e confiança do dispositivo: como deixar o estado do dispositivo votar. A identidade diz quem está pedindo; a postura diz de que dispositivo: as condições do dispositivo votando nas decisões de acesso.
- CASB no Exchange: inline, fora de banda, e a postura do próprio SaaS. O cloud access security broker visto de dois pontos de observação: inline, sobre os dados em movimento, e fora de banda, sobre os dados armazenados.
- O score ZDX: o que os probes medem e como o número é feito. Como se chega a uma nota de 1 a 100: o que medem os probes web e os probes de caminho.
- Nanolog, NSS, Cloud NSS e LSS: como tirar os logs de lá. O armazenamento de logs do lado da nuvem e os três caminhos de entrega que trazem os logs para casa.
- O audit log de administradores: quem mudou o quê, de onde, com que resultado. Cada ação administrativa, feita pelo console ou pela API, registrada com quem mudou o quê, de onde e com que resultado.
- Relatórios e sumários executivos: como transformar o Nanolog em frases que a liderança lê. A camada de relatórios entre o fluxo bruto de logs e o slide que vai para a diretoria.
- O alerta de exfiltração: um passo a passo do sinal à resposta de postura. Um alerta de suspeita de exfiltração acompanhado desde o sinal até a resposta de postura: a série inteira convergindo num único cenário.
- Atualizações e gestão de mudanças: como operar a mudança numa plataforma que também muda sozinha. Três fluxos de mudança (a nuvem do fornecedor, a sua frota de agentes, a sua política), e só dois deles você mesmo agenda.
- Fusões e aquisições no Exchange: acesso no dia um sem fundir redes. Acesso desde o primeiro dia para as pessoas de uma empresa adquirida, sem fundir as redes.