Uma análise prática de como Jay Chaudhry e a Zscaler usaram segurança na nuvem, zero trust e canais de distribuição para construir uma empresa líder em segurança empresarial.
Isto não é uma biografia de Jay Chaudhry. É uma história prática sobre como a Zscaler ajudou a remodelar a segurança empresarial — e por que suas escolhas (técnicas e comerciais) importaram.
Você aprenderá duas coisas em paralelo:
Segurança empresarial moderna é o conjunto de controles que permite aos funcionários usar a internet e apps internos com segurança, sem assumir que algo é seguro só porque está “dentro” da rede corporativa. Trata-se menos de construir um muro maior em torno de um data center e mais de verificar quem está se conectando, o que estão acessando e se a conexão deve ser permitida — sempre.
Ao final, você conseguirá explicar a aposta central da Zscaler em uma frase, reconhecer onde o zero trust substitui o pensamento da era VPN e ver por que a estratégia de distribuição pode importar tanto quanto o design do produto.
Jay Chaudhry é um empreendedor em série mais conhecido como fundador e CEO da Zscaler, uma empresa que ajudou a empurrar a segurança empresarial de “proteger a rede corporativa” para “proteger usuários e apps onde quer que estejam”. Antes da Zscaler, ele construiu e vendeu múltiplas startups de segurança, o que lhe deu visão direta sobre como o comportamento dos atacantes e a TI empresarial mudavam rapidamente.
O foco de Chaudhry com a Zscaler era direto: à medida que trabalho e aplicações se moviam para fora da rede corporativa (para a internet pública e serviços de nuvem), o antigo modelo de rotear tudo por um data center central para inspeção começou a se quebrar.
Essa mudança criou um trade-off doloroso para times de TI:
A premissa fundadora da Zscaler foi que a segurança precisava seguir o usuário, não o prédio.
O que se destaca é como a visão do fundador influenciou a estratégia da empresa cedo:
Isso não foi um ajuste de marketing; influenciou decisões de produto, parcerias e como a Zscaler explicava o “porquê” a compradores empresariais conservadores. Com o tempo, essa clareza ajudou a transformar “segurança entregue pela nuvem” e “zero trust” de ideias em linhas orçamentárias — algo que grandes empresas podiam comprar, implantar e padronizar.
Por anos, a segurança empresarial foi construída em torno da ideia simples: manter o “que é valioso” dentro da rede corporativa e colocar um muro ao redor. Esse muro era geralmente uma pilha de appliances on‑premises — firewalls, proxies web, prevenção de intrusão — em alguns data centers. Funcionários remotos acessavam via VPN, que efetivamente “estendia” a rede interna para onde quer que estivessem.
Quando a maioria dos apps vivia em data centers da empresa, isso funcionava razoavelmente bem. O tráfego web e de apps fluía pelos mesmos pontos de estrangulamento, onde as equipes de segurança podiam inspecionar, registrar e bloquear.
Mas o modelo pressupunha duas coisas que começaram a deixar de ser verdade:
À medida que empregados ficaram mais móveis e a adoção de SaaS acelerou, os padrões de tráfego inverteram. Pessoas em cafeterias precisavam de acesso rápido ao Office 365, Salesforce e dezenas de ferramentas baseadas no navegador — muitas vezes sem tocar um data center corporativo.
Para continuar aplicando políticas, muitas empresas “backhaulavam” o tráfego: enviar as requisições de internet e SaaS do usuário via sede, inspecionar e depois reenviar. O resultado foi previsível: desempenho lento, usuários insatisfeitos e pressão crescente por abrir exceções nos controles.
A complexidade explodiu (mais appliances, mais regras, mais exceções). VPNs ficaram sobrecarregadas e arriscadas quando davam acesso de rede amplo. E cada nova filial ou aquisição significava outro rollout de hardware, mais planejamento de capacidade e arquitetura mais frágil.
Esse hiato — a necessidade de segurança consistente sem forçar tudo por um perímetro físico — criou a oportunidade para a segurança entregue pela nuvem que segue o usuário e o aplicativo, não o prédio.
A aposta definidora da Zscaler foi simples de dizer, mas difícil de executar: entregar segurança como um serviço em nuvem, posicionado perto dos usuários, em vez de appliances dentro da rede da empresa.
Neste contexto, “segurança em nuvem” não significa proteger apenas servidores em nuvem. Significa que a própria segurança roda na nuvem — então um usuário em uma filial, em casa ou em mobile se conecta a um ponto de presença (PoP) próximo, e a política é aplicada ali.
“Inline” é como roteamento do tráfego por um checkpoint de segurança no caminho até o destino.
Quando um funcionário acessa um site ou um app em nuvem, a conexão dele é direcionada pelo serviço primeiro. O serviço inspeciona o que pode (com base em políticas), bloqueia destinos arriscados, escaneia por ameaças e então encaminha o tráfego permitido. O objetivo é que os usuários não precisem “estar na rede corporativa” para obter proteção de nível corporativo — a segurança viaja com o usuário.
A segurança entregue pela nuvem muda a realidade cotidiana para TI e times de segurança:
Esse modelo também se alinha a como as empresas realmente funcionam hoje: o tráfego frequentemente vai direto para SaaS e a internet pública, não “de volta à sede” primeiro.
Colocar um terceiro inline levanta preocupações reais que as equipes devem avaliar:
A aposta central, portanto, não é só técnica — é confiança operacional de que um provedor de nuvem pode aplicar políticas de forma confiável, transparente e em escala global.
Zero trust é um princípio simples: nunca assumir que algo é seguro só porque está “dentro da rede corporativa”. Em vez disso, verifique sempre quem é o usuário, qual é o dispositivo e se ele deve acessar um app ou dado específico — toda vez que isso for relevante.
O pensamento tradicional de VPN é como dar a alguém um crachá que abre todo o prédio depois que passam pela porta. Depois que a VPN conecta, muitos sistemas tratam esse usuário como “interno”, o que pode expor mais do que o pretendido.
Zero trust inverte esse modelo. É mais como dar a alguém acesso a uma sala para uma tarefa. Você não “entra amplamente na rede”; você só alcança o app para o qual foi aprovado.
Um contratado precisa acessar uma ferramenta de gerenciamento de projetos por dois meses. Com zero trust, ele pode receber acesso a esse único app — sem, acidentalmente, abrir caminho para sistemas de folha de pagamento ou ferramentas administrativas internas.
Um funcionário usa BYOD (seu próprio laptop) enquanto viaja. Políticas de zero trust podem exigir checagens de login mais fortes ou bloquear acesso se o dispositivo estiver desatualizado, sem criptografia ou mostrando sinais de comprometimento.
Trabalho remoto fica mais fácil de securar porque a decisão de segurança segue o usuário e o app, não uma rede física.
Zero trust não é um produto único que você compra e “liga”. É uma abordagem de segurança implementada por meio de ferramentas e políticas.
Também não significa “não confiar em ninguém” de forma hostil. Na prática, significa que a confiança é conquistada continuamente através de checagens de identidade, postura do dispositivo e princípio do privilégio mínimo — assim erros e invasões não se propagam automaticamente.
A Zscaler é mais fácil de entender como um “ponto de controle” em nuvem que fica entre pessoas e o que elas tentam alcançar. Em vez de confiar em um limite de rede corporativo, ela avalia cada conexão com base em quem é o usuário e como está a situação, aplicando então a política adequada.
A maioria das implantações pode ser descrita com quatro peças simples:
Conceitualmente, a Zscaler divide o tráfego em duas pistas:
Essa separação importa: uma pista trata do uso seguro da internet; a outra trata de acesso preciso a sistemas internos.
Decisões não são baseadas em um IP de escritório confiável. Baseiam-se em sinais como quem é o usuário, saúde do dispositivo (gerenciado vs. não gerenciado, atualizado vs. desatualizado) e onde/como ele está se conectando.
Feito bem, essa abordagem reduz a superfície de ataque exposta, limita o movimento lateral se algo der errado e transforma o controle de acesso em um modelo de políticas mais simples e consistente — especialmente à medida que o trabalho remoto e stacks de apps cloud‑first se tornam padrão.
Quando se fala de “segurança empresarial”, muitas vezes se imagina apps privados e redes internas. Mas grande parte do risco está no lado da internet aberta: funcionários consultando sites de notícias, clicando em links de e‑mail, usando ferramentas baseadas no navegador ou fazendo uploads para apps web.
Um Secure Web Gateway (SWG) é a categoria criada para tornar esse acesso cotidiano à internet mais seguro — sem forçar o tráfego de cada usuário a dar a volta pelo escritório central.
Simplificando, um SWG atua como um ponto de controle entre usuários e a web pública. Em vez de confiar em qualquer coisa que um dispositivo alcance, o gateway aplica políticas e inspeção para reduzir exposição a sites maliciosos, downloads arriscados e vazamento acidental de dados.
Proteções típicas incluem:
O movimento ganhou força à medida que o trabalho saiu de escritórios fixos e foi para SaaS, navegadores e dispositivos móveis. Se os usuários e apps estão em todo lugar, backhauling de tráfego para um perímetro corporativo adiciona latência e cria pontos cegos.
O SWG entregue pela nuvem combinou com a nova realidade: a política segue o usuário, o tráfego pode ser inspecionado mais perto de onde ele se conecta e as equipes de segurança obtêm controle consistente entre sedes, filiais e trabalho remoto — sem tratar a internet como exceção.
VPNs foram construídas para uma época em que “estar na rede” era o mesmo que “conseguir alcançar os apps”. Esse modelo mental se fragmenta quando apps vivem em várias nuvens, SaaS e um conjunto cada vez menor de sistemas on‑prem.
O acesso centrado em apps inverte o padrão. Em vez de colocar um usuário na rede interna (e então esperar que as políticas de segmentação funcionem), o usuário é conectado apenas a uma aplicação específica.
Conceitualmente, funciona como uma conexão intermediada: o usuário prova quem é e o que pode usar, e então é criada uma rota curta e controlada para aquele app — sem publicar faixas de IP internas na internet e sem dar ao usuário ampla visibilidade “interna”.
A segmentação de rede é poderosa, mas frágil em organizações reais: fusões, VLANs planas, apps legados e exceções tendem a se acumular. A segmentação por app é mais fácil de raciocinar porque mapeia a intenção do negócio:
Isso reduz confiança implícita e torna políticas de acesso auditáveis: você pode revisá‑las por aplicação e grupo de usuários em vez de rastrear rotas e sub‑redes.
A maioria das equipes não troca a VPN da noite para o dia. Um rollout prático costuma ser:
Quando o acesso centrado em apps é bem feito, os ganhos aparecem rápido: menos chamados relacionados à VPN, regras de acesso mais claras que segurança e TI conseguem explicar, e melhor experiência do usuário — especialmente para funcionários remotos e híbridos que só querem que o app funcione sem “conectar na rede” primeiro.
Ótimos produtos de segurança não viram automaticamente padrões corporativos. Na prática, “distribuição” em segurança empresarial significa os canais que um fornecedor usa para alcançar, vencer e implantar com sucesso dentro de grandes organizações — frequentemente por meio de outras empresas.
Em segurança, distribuição normalmente abrange:
Isso não é opcional. São os canos que ligam o fornecedor a orçamentos, decisores e capacidade de implementação.
Grandes empresas compram com cautela. Parceiros oferecem:
Para uma plataforma como a Zscaler, a adoção muitas vezes depende de trabalho real de migração — mover usuários de padrões legados de VPN, integrar identidade e ajustar políticas. Parceiros tornam essa mudança gerenciável.
A entrega em nuvem transforma o negócio de instalações pontuais para assinatura, expansão e renovações. Isso muda a distribuição: parceiros deixam de ser apenas “fechadores de negócio”. Eles podem ser parceiros contínuos de rollout, com incentivos alinhados aos resultados do cliente — se o programa for bem desenhado.
Observe atentamente incentivos dos parceiros, a qualidade do enablement (treinamento, playbooks, suporte de co‑selling) e o quão limpos são os handoffs de customer success após a assinatura do contrato. Muitas implantações falham não porque o produto é fraco, mas porque a responsabilidade entre fornecedor, parceiro e cliente fica confusa.
Compras de segurança raramente começam com “precisamos de melhor segurança”. Geralmente começam com uma mudança de rede que quebra as antigas suposições: mais apps migram para SaaS, filiais adotam SD‑WAN, ou o trabalho remoto se torna permanente. Quando o tráfego não flui mais por um escritório central, o modelo de “proteger tudo na sede” vira conexões lentas, exceções e pontos cegos.
A Zscaler é frequentemente mencionada nas mesmas conversas que SASE e SSE porque esses rótulos descrevem uma mudança em como a segurança é entregue:
O real “benefício traduzido” não é o acrônimo — é operações mais simples: menos caixas on‑prem, atualizações de política mais fáceis e acesso direto a apps sem hairpin no data center.
Uma empresa normalmente avalia abordagens estilo SSE/SASE quando:
Quando esses gatilhos aparecem, a categoria “chega” naturalmente — porque a rede já mudou.
Comprar uma plataforma Zero Trust geralmente é a parte fácil. Fazer ela funcionar em redes bagunçadas, aplicações herdadas e com pessoas reais é onde projetos vencem — ou empacam.
Apps legados são o recorrente problema nº1. Sistemas antigos podem presumir “dentro da rede = confiável”, depender de allowlists de IPs fixas ou quebrar quando o tráfego é inspecionado.
Outros atritos são humanos: gestão de mudança, redesenho de políticas e debates sobre “quem é dono do quê”. Mudar de acesso amplo por rede para regras precisas por app força times a documentar como o trabalho realmente acontece — e isso pode expor lacunas ignoradas por longo tempo.
Rollouts fluem melhor quando segurança não tenta operar sozinha. Espere coordenar com:
Comece com um grupo de baixo risco (por exemplo, um único departamento ou subset de contratados) e defina métricas de sucesso desde o início: menos chamados de VPN, acesso a apps mais rápido, redução mensurável da superfície de ataque exposta, ou visibilidade melhorada.
Rode o piloto em iterações: migre uma categoria de app por vez, ajuste políticas e então expanda. O objetivo é aprender rápido sem transformar a empresa inteira em um ambiente de testes.
Planeje logging e troubleshooting desde o primeiro dia: onde os logs ficam, quem pode consultá‑los, quanto tempo são retidos e como alertas se ligam ao response a incidentes. Se usuários não conseguem ajuda quando “o app está bloqueado”, a confiança cai rápido — mesmo que o modelo de segurança esteja certo.
Um acelerador prático (e muitas vezes negligenciado) aqui são ferramentas internas: portais simples para pedidos de exceção, revisões de acesso, inventário de apps, acompanhamento de rollouts e relatórios. Times cada vez mais constroem esses “apps de cola” internamente em vez de esperar por um roadmap do fornecedor. Plataformas como Koder.ai podem ajudar equipes a prototipar e lançar essas ferramentas web internas rapidamente via fluxo guiado por chat — útil quando você precisa de um painel em React com backend Go/PostgreSQL, além de iterações rápidas conforme políticas e processos amadurecem.
Mover controles de segurança de appliances que você possui para uma plataforma em nuvem pode simplificar operações — mas também muda em que você aposta. Uma boa decisão é menos sobre “Zero Trust vs. legado” e mais sobre entender os novos modos de falha.
Se uma plataforma fornece segurança web, acesso a apps privados, aplicação de políticas e logging, você reduz o espalhamento de ferramentas — mas também concentra risco. Uma disputa contratual, mudança de preços ou lacuna de produto pode ter raio de impacto maior do que quando essas peças estavam distribuídas.
Segurança em nuvem adiciona uma etapa extra entre usuários e apps. Quando funciona bem, os usuários mal percebem. Quando uma região tem queda, problema de roteamento ou capacidade, a “segurança” pode parecer “a internet caiu”. Isso é menos sobre um fornecedor específico e mais sobre depender de conectividade sempre disponível.
Zero Trust não é um escudo mágico. Políticas mal definidas (muito permissivas, muito restritivas ou inconsistentes entre grupos) podem aumentar exposição ou interromper trabalho. Quanto mais flexível o motor de políticas, mais disciplina é necessária.
Rollouts faseados ajudam: comece com um caso de uso claro (por exemplo, um subset de usuários ou uma categoria de apps), meça latência e resultados de acesso e então expanda. Defina políticas em linguagem clara, implemente monitoramento e alertas cedo e planeje redundância (roteamento multi‑região, acesso break‑glass e caminhos de fallback documentados).
Saiba que tipos de dados você protege (regulados vs. gerais), alinhe controles às necessidades de conformidade e agende revisões recorrentes de acesso. O objetivo não é comprar por medo — é garantir que o novo modelo falhe de forma segura e previsível.
A lição repetida da Zscaler é foco: mover a aplicação de políticas de segurança para a nuvem e tornar o acesso baseado em identidade. Ao avaliar fornecedores (ou construir um), faça uma pergunta simples: “Qual é a aposta arquitetural única que torna todo o resto mais simples?” Se a resposta for “depende”, espere que a complexidade apareça depois em custo, tempo de rollout e exceções.
“Zero trust” funcionou porque se traduziu em uma promessa prática: menos suposições de confiança implícita, menos encanamento de rede e melhor controle à medida que apps saem do on‑prem. Para times, isso significa comprar resultados, não buzzwords. Escreva seus resultados desejados (por exemplo, “sem acesso inbound”, “privilégio mínimo para apps”, “política consistente para usuários remotos”) e mapeie cada um para capacidades concretas que você pode testar.
A segurança empresarial se espalha por redes de confiança: revendedores, GSIs, MSPs e marketplaces de nuvem. Fundadores podem copiar isso construindo um produto pronto para parceiros cedo — empacotamento claro, margens previsíveis, playbooks de implantação e métricas compartilhadas. Líderes de segurança também podem usar parceiros: empregue‑os para gestão de mudança, integração de identidade e migrações faseadas em vez de tentar capacitar toda equipe internamente de uma vez.
Comece com um caso de alto volume (frequentemente acesso à internet ou um app crítico), meça antes/depois e expanda.
Perguntas-chave de rollout:
Não venda apenas “segurança” — venda um caminho de migração. A história vencedora costuma ser: dor → primeiro passo mais simples → vitória mensurável → expansão. Construa onboarding e relatórios que tornem o valor visível em 30–60 dias.
Um padrão amigável ao fundador é complementar o produto central com apps companheiros fáceis de construir (workflows de avaliação, trackers de migração, calculadoras de ROI, portais para parceiros). Se quiser criar esses sem refazer um pipeline dev legado, Koder.ai é projetado para “vibe‑coding” de apps full‑stack a partir de chat — útil para colocar ferramentas internas ou voltadas ao cliente em produção rapidamente e depois iterar conforme sua motion de distribuição evolui.
Se quiser se aprofundar, veja /blog/zero-trust-basics e /blog/sase-vs-sse-overview. Para ideias de empacotamento, visite /pricing.
Zero trust é uma abordagem em que decisões de acesso são tomadas a cada requisição com base na identidade, postura do dispositivo e contexto, em vez de assumir que algo é seguro por estar “dentro da rede”. Na prática, isso significa:
Uma VPN tradicional frequentemente coloca o usuário “na rede”, o que pode expor sistemas além do necessário. O acesso centrado em aplicações inverte esse modelo:
“Inline” significa que o tráfego é roteado por um ponto de verificação de segurança antes de chegar à internet ou a um app na nuvem. No modelo entregue pela nuvem, esse ponto fica em um point of presence (PoP) próximo ao usuário, permitindo que o provedor:
O objetivo é segurança consistente sem forçar o tráfego a voltar ao escritório central.
O backhaul envia o tráfego web e SaaS de um usuário remoto a um data center central para inspeção, e depois de volta à internet. Isso costuma falhar porque:
Um Secure Web Gateway (SWG) protege usuários enquanto navegam na internet e usam apps SaaS. Capacidades comuns de um SWG incluem:
É especialmente útil quando grande parte do tráfego é direcionada à internet e os usuários não estão atrás de um único firewall corporativo.
A segurança entregue pela nuvem pode simplificar operações, mas muda as dependências. Principais compensações a avaliar:
Um piloto de baixo risco costuma ter mais sucesso quando é bem delimitado e mensurável:
O objetivo é aprender rápido sem transformar a empresa inteira em um ambiente de testes.
A má configuração é comum porque a transição de “acesso por rede” para “acesso por app/política” força as equipes a definir intenção com precisão. Para reduzir o risco:
SSE são controles de segurança entregues pela nuvem (como SWG e acesso a apps privados) entregues “na borda”, perto dos usuários. SASE combina esse modelo de segurança com a parte de rede (frequentemente SD-WAN), então conectividade e segurança são planejadas juntas.
Em termos de compra:
Grandes empresas frequentemente compram via parceiros e precisam de capacidade de implementação. Parceiros de canal, SIs e MSPs ajudam ao:
Um ecossistema de parceiros forte pode determinar se uma plataforma vira padrão ou estagna após uma implantação pequena.
