O Zscaler (ZTE) é mais fácil de entender pelo que ele não é: não é um perímetro mudado para a nuvem. É uma central telefônica globalmente distribuída - uma arquitetura de proxy em que cada conexão termina num ponto de aplicação de política da Zscaler, é identificada e inspecionada, e então completada adiante como uma conexão nova. As origens conectam-se ao Exchange; o Exchange conecta-se aos destinos. Nada atravessa; tudo é intermediado. Guarde essa frase e o resto da plataforma deixa de ser uma lista de produtos e vira uma lista de consequências.

O ponto de aplicação: o Public Service Edge

O operário da arquitetura é o - o nome atual da Zscaler para os nós de aplicação implantados em seus data centers pelo mundo (material antigo diz ZEN, Zscaler Enforcement Node; a renomeação importa ao ler documentação). Um Service Edge termina a sessão do usuário ou da localidade, aplica identidade, aplica política, e origina a conexão adiante. A documentação da Zscaler é específica sobre a postura operacional: os dados dos pacotes ficam em memória para inspeção e são encaminhados ou descartados por política - Service Edges nunca gravam payload em disco - enquanto os logs de transação são comprimidos, tokenizados e transmitidos por TLS para a infraestrutura de logging. O mesmo conceito de Service Edge existe também em forma privada: instâncias single-tenant que a organização hospeda no próprio site ou nuvem, gerenciadas pela Zscaler - a mesma aplicação de política, trazida para mais perto.

Proxy, não roteador - e o que isso compra

Como cada sessão é terminada em vez de roteada através, o Exchange enxerga transações de aplicação completas em vez de pacotes em trânsito. É isso que faz da interceptação TLS um recurso de primeira classe em vez de um acessório: o Service Edge se posiciona como man-in-the-middle por projeto, decifrando onde a política manda, inspecionando o texto claro uma vez, e aplicando cada engine habilitado àquele único fluxo decifrado - filtragem de URL, análise de malware, proteção de dados - antes de recifrar adiante. Uma terminação, uma inspeção, muitos vereditos. É também o que torna o modelo de escala horizontal: as sessões são independentes por nó, então capacidade se adiciona adicionando edges, e os usuários são simplesmente direcionados ao mais próximo saudável.

A postura de proxy tem uma segunda consequência que molda projetos: o Exchange é alcançado por encaminhamento, não por tabelas de roteamento. O tráfego precisa ser enviado a ele deliberadamente - por um agente no dispositivo, por um túnel da localidade, por uma configuração de proxy - e é exatamente por isso que a decisão de métodos de encaminhamento é a primeira conversa real de projeto em qualquer implantação.

Três serviços, uma central

Os nomes de produto são assentos na mesma central. O Zscaler Internet Access () é o assento de saída: usuários e localidades conectam-se ao Exchange, e o Exchange conecta-se à internet e ao SaaS em nome deles, aplicando no caminho o secure web gateway, o firewall e os engines de proteção de dados. O Zscaler Private Access () é o assento de entrada-sem-entrada: aplicações privadas nunca são expostas; em vez disso, App Connectors ao lado das aplicações discam para fora até o Exchange, os usuários discam para dentro, e o Exchange costura as duas conexões de saída, por aplicação, por sessão. O Zscaler Digital Experience () é o assento de medição: com o caminho de dados intermediado pelo Exchange, os mesmos pontos de observação medem a experiência - saúde do dispositivo, da rede e da aplicação - de ponta a ponta.

A tese de zero trust vive no modelo de conexão do ZPA mais do que em qualquer outro lugar: um usuário é conectado a uma aplicação para a qual está autorizado, nunca colocado numa rede. Não existe um interior plano para atravessar lateralmente, porque não existe interior - só fios intermediados, por sessão. Uma VPN estende a rede até o usuário; o Exchange inverte isso, não estendendo nada e intermediando tudo.

Lendo a arquitetura como um operador

Três hábitos decorrem. Primeiro, identidade é a tabela de roteamento: a política pende de quem e do que conectou, então a integração de identidade é infraestrutura, não acessório. Segundo, o Service Edge é o ponto de observação: ao diagnosticar, pense em duas pernas - origem até o Edge, Edge até o destino - porque é literalmente assim que a conexão existe. Terceiro, fronteiras de 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 é uma dessas consequências examinada de perto.