O Zero Trust Exchange é um proxy, e um proxy protege exatamente o tráfego que chega até ele, nada além disso. Por isso o encaminhamento do tráfego (traffic forwarding) é a decisão estrutural de toda implantação do Zscaler Internet Access (): antes que qualquer política possa fazer diferença, alguma coisa precisa mandar o tráfego, de propósito, para um . A própria documentação (o guia de métodos de encaminhamento, conferido em 2026-07-21) oferece um cardápio pequeno, e a arte está em saber o que cada item cobre, o que ele não enxerga e como os itens se combinam.

Método um: o agente no dispositivo

O Zscaler Client Connector () coloca a decisão de encaminhamento no próprio endpoint (o dispositivo do usuário). O agente autentica o usuário, observa a rede em que o dispositivo está e encaminha o tráfego para o Service Edge mais próximo pelo dele. A cobertura é o dispositivo inteiro (todo navegador, todo atualizador, toda ferramenta de linha de comando) e vai junto com ele: o laptop no aeroporto é encaminhado exatamente como o laptop na matriz. É a resposta para quem está em trânsito (roaming) e, cada vez mais, a resposta padrão; a mecânica de perfis do ZCC merece um artigo só para ela. O limite é a instalação: o agente cobre dispositivos gerenciados, e só eles.

Método dois: o túnel a partir da localidade

Quando é o tráfego de um site inteiro que precisa ser encaminhado (redes de visitantes, impressoras, servidores, hardware não gerenciado, tudo o que fica atrás do roteador de borda), a própria localidade se conecta ao Exchange por um túnel ou . O equipamento de borda encapsula o tráfego rumo a um Service Edge primário (com um secundário em outro data center, para failover), e todo mundo atrás dele fica coberto sem que se mexa em nenhum endpoint. A escolha entre os dois encapsulamentos, as capacidades publicadas por túnel e as contas de dimensionamento são o assunto inteiro do artigo sobre os tipos de túnel, e o seletor de túnel calcula essa decisão de forma interativa. O limite é o espelho do limite do agente: o túnel da localidade conhece o site, não o usuário, então a identidade precisa chegar por outro caminho; e, assim que o laptop sai do prédio, este método nunca mais o vê.

Método três: o arquivo PAC

Um arquivo de Proxy Auto-Configuration diz aos navegadores e às aplicações que entendem qual proxy usar para cada URL; aqui, o proxy apontado é o ZIA. Não precisa de túnel nem de agente, o que faz do PAC a resposta leve quando a cobertura gira em torno do navegador e um instrumento preciso para exceções: a lógica do PAC pode mandar alguns destinos direto, sem proxy, e o resto para a nuvem. Os limites são os de sempre de um arquivo PAC: só obedecem a ele os clientes que respeitam PAC, o tráfego que não vem de navegador em geral o ignora, e o próprio arquivo vira uma pequena peça de infraestrutura para versionar e servir. Na prática da Zscaler, os arquivos PAC também aparecem dentro dos outros métodos (direcionando o encaminhamento do ZCC ou limitando o que um túnel de localidade carrega), e é por isso que entendê-los vale em dobro.

Método quatro: o encadeamento a partir de um proxy existente

Organizações que têm um proxy local (on-premises) ou um appliance de borda podem encadeá-lo ao ZIA, o chamado proxy chaining: o equipamento local encaminha o tráfego para a nuvem em vez de mandá-lo para a internet, o que preserva a arquitetura de saída existente e acrescenta a inspeção do Exchange. É o método dos ambientes brownfield (os que já estão em produção). É pragmático durante migrações e não esconde o seu limite: dois proxies no caminho são dois hops (duas passagens por equipamentos intermediários) acumulando latência, e dois lugares para depurar.

Como os métodos se combinam, e a fronteira entre on-net e off-net

Os projetos reais usam esses métodos em camadas. Um desenho clássico: os túneis da localidade levam o site (e cobrem o que não dá para gerenciar), o ZCC cobre os dispositivos gerenciados aonde quer que eles vão, e a lógica do PAC trata as exceções; o ZCC fica configurado para perceber quando está dentro de uma rede que já passa por túnel e ajustar o próprio comportamento, para que o tráfego não seja encaminhado duas vezes. Essa noção de estar dentro ou fora da rede (on-network/off-network) é exatamente o que a detecção de rede confiável nos perfis do Client Connector existe para automatizar, e é aí que o encaminhamento deixa de ser quatro métodos separados e vira um projeto único e coerente.

O resumo para quem opera: escolha pelo domínio de cobertura, não pela moda. Dispositivos que você gerencia recebem o agente, sites que são seus recebem túneis, navegadores sobre os quais você só tem influência recebem PAC, e bordas que você já opera podem encadear. E deixe explícitas as fronteiras entre um método e outro, porque toda brecha no encaminhamento é uma brecha na inspeção, só que disfarçada.

Esta série, em ordem

Este artigo abre a série Zscaler Internet Access. Um proxy em nuvem só protege o que chega até ele, então a série começa pela decisão de encaminhamento; depois, as partes acompanham uma requisição pelas políticas do ZIA, na ordem em que elas atuam (de onde a requisição vem, se ela é descriptografada, quais sites e aplicações, quais portas, quais arquivos e que dados), e terminam nos campos de log que registram tudo isso.

  1. Localidades e sublocalidades: como ensinar à nuvem onde ficam os seus sites. Um site que a plataforma reconhece pelos túneis ou pelos endereços de saída, e a política por site que esse reconhecimento torna possível.
  2. Inspeção TLS no ZIA: a política, os bypasses e a conta. A interceptação do forward proxy aplicada como política: inspecionar ou não inspecionar, os bypasses e o que eles custam.
  3. URL Filtering e Cloud App Control: duas políticas, uma regra de precedência. Destinos julgados pela categoria e aplicações pela identidade: duas políticas e a única regra de precedência entre elas.
  4. Cloud Firewall do ZIA: a ordem das regras é o jogo inteiro. Uma máquina de first match (vale a primeira regra que bate), com uma regra padrão que não pode ser apagada lá no fim da lista: é a ordem das regras que decide tudo.
  5. File Type Control e Cloud Sandbox: os dois juízes do download. Dois juízes para cada download: que tipos de arquivo podem circular, e o que um arquivo desconhecido faz quando é executado.
  6. Data Loss Prevention no ZIA: dicionários, engines e os tiers de fingerprint. Dicionários com confiança e proximidade, engines que os combinam e os tiers de fingerprint para dados exatos e indexados.
  7. Campos de log do ZIA: o vocabulário em que as investigações são escritas. Os campos de que um feed de log é feito, e qual deles traz o que uma investigação precisa.