# Planejador de Bypass SSL do ZIA > Cole uma lista de ativos e receba um plano determinístico de inspeção TLS: o que inspeciona, o que ganha uma regra Do Not Inspect, o que precisa de bypass no Client Connector — cada um com raciocínio referenciado, um livro-razão de pontos cegos e a checklist de salvaguardas. - Tool: https://ronutz.com/pt-BR/tools/zscaler-ssl-bypass-planner - Family: Segurança e WAF --- # Planejador de Bypass SSL do ZIA ## O que ele faz Cole uma lista de aplicações ou destinos - um por linha, numa gramática de quatro campos - e receba um plano determinístico de inspeção TLS. Cada ativo recebe um de três vereditos: **Inspecionar** (o padrão, que alimenta todos os engines de conteúdo), **Do Not Inspect via regra de política** (a isenção no Edge para categorias de governança e para aplicações com pinning em caminhos que nenhum agente controla), ou **bypass no Client Connector** (a isenção mais limpa para aplicações com pinning onde o ZCC controla o caminho - o tráfego nunca entra no túnel, pareada com uma regra de política como defesa em profundidade). Todo veredito carrega seu raciocínio referenciado; todo bypass carrega um livro-razão de pontos cegos nomeando o que deixa de ver este fluxo; e sempre que algo fica sem inspeção, o plano anexa a checklist de salvaguardas externas - a ação de Untrusted Server Certificates, OCSP via stapling, o piso de Minimum TLS Version e o Block No-SNI. ## A gramática Um ativo por linha, quatro campos separados por barra vertical; linhas começando com `#` são comentários: ``` | pinned|clean | regulated|general | agent|no-agent ``` `pinned` marca uma aplicação com certificate pinning (ela não aceita um certificado regenerado sob a CA de inspeção e falha fechada sob interceptação). `regulated` marca uma categoria de governança que política ou lei exige manter selada. `agent` marca um caminho que o Zscaler Client Connector controla. ## Lendo o plano O resumo conta os vereditos; os cartões percorrem o raciocínio de cada ativo; a nota de ordenação carrega a doutrina de que as exceções Do Not Inspect pertencem à ordem alta, acima do corpo de Inspect, porque as regras da política SSL avaliam em ordem crescente com primeira correspondência. Quando todos os ativos inspecionam, não há livro-razão de bypass nem dívida de salvaguardas - e o plano diz isso. ## Honestidade A gramática é um subconjunto de ensino deliberado: o planejamento real de bypass também escopa regras por usuários, grupos e localidades, e pesa especificidades de aplicação que este planejador não modela. A lógica de decisão - pinning força uma isenção, governança sela uma categoria, todo o resto inspeciona, e cada bypass é um ponto cego com preço - é a parte durável. Todo o cálculo é local; os nomes dos seus ativos nunca saem da página. ## Fontes Fundamentado na documentação de inspeção SSL da Zscaler (Configuring the SSL/TLS Inspection Policy; About SSL Inspection) e na arquitetura de referência de Data Protection, data de acesso 2026-07-21. O artigo Learn pareado é *Inspeção SSL no ZIA: Política e Bypasses*. ## Standards and references - [Zscaler Help: Configuring the SSL/TLS Inspection Policy](https://help.zscaler.com/zia/configuring-ssltls-inspection-policy) - Inspect / Do Not Inspect rules evaluating in ascending order, first match; destination and category scoping of exemptions; the criteria dimensions - [Zscaler Help: About SSL Inspection](https://help.zscaler.com/zia/about-ssl-inspection) - interception via certificates regenerated under the inspection CA; certificate-pinning applications failing under interception and requiring exemption; the outside backstops for uninspected flows (Untrusted Server Certificates action with TCP-reset block, OCSP via stapling, Minimum TLS Version, Block No-SNI) - [Zscaler Reference Architecture: Data Protection with Secure Internet and SaaS Access (ZIA)](https://help.zscaler.com/downloads/zia/reference-architecture/data-protection-secure-internet-and-saas-access/Data-Protection-with-Secure-Internet-and-SaaS-Access-ZIA-Reference-Architecture.pdf) - the share of outbound traffic that is encrypted and the platform's full-TLS-inspection posture; the content engines (CASB, DLP) that only operate on inspected traffic - the price of every bypass ## Related reading - [Inspeção TLS no ZIA: a Política, os Bypasses e a Conta](https://ronutz.com/pt-BR/learn/zia-ssl-inspection-policy-and-bypasses.md): A inspeção TLS do ZIA é o padrão de interceptação por forward proxy rodando como política: regras avaliadas em ordem crescente decidem Inspect ou Do Not Inspect, uma CA da Zscaler ou do cliente assina os certificados regenerados, e cada bypass é um ponto cego deliberado. A anatomia das regras, os anteparos de certificado não confiável e TLS mínimo, por que aplicações com pinning precisam de isenção, e o que um fluxo não inspecionado ainda custa.