Una mirada práctica a cómo Jay Chaudhry y Zscaler usaron seguridad en la nube, Zero Trust y distribución por partners para construir una empresa líder en seguridad empresarial.
Esto no es una biografía de Jay Chaudhry. Es una historia práctica sobre cómo Zscaler ayudó a remodelar la seguridad empresarial —y por qué sus decisiones (técnicas y comerciales) importaron.
Aprenderás dos cosas en paralelo:
La seguridad empresarial moderna es el conjunto de controles que permite a los empleados usar Internet y aplicaciones internas de forma segura, sin asumir que algo es seguro solo porque está “dentro” de la red corporativa. Se trata menos de construir un muro más grande alrededor de un centro de datos y más de comprobar quién se conecta, a qué se conecta y si esa conexión debe permitirse—cada vez.
Al final, podrás explicar la apuesta central de Zscaler en una frase, reconocer dónde Zero Trust reemplaza el pensamiento de la era VPN y ver por qué la estrategia de distribución puede importar tanto como el diseño del producto.
Jay Chaudhry es un emprendedor en serie conocido por ser el fundador y CEO de Zscaler, una compañía que ayudó a empujar la seguridad empresarial desde “proteger la red corporativa” hacia “asegurar usuarios y apps dondequiera que estén”. Antes de Zscaler, fundó y vendió varias startups de seguridad, lo que le dio una visión directa de cómo cambiaban rápidamente el comportamiento de los atacantes y la TI empresarial.
El enfoque de Chaudhry con Zscaler fue sencillo: a medida que el trabajo y las aplicaciones se movían fuera de la red corporativa (hacia Internet público y servicios en la nube), el viejo modelo de enrutar todo a través de un centro de datos central para inspección empezó a fallar.
Ese cambio creó un dilema doloroso para los equipos de TI:
La premisa fundacional de Zscaler fue que la seguridad debía seguir al usuario, no al edificio.
Lo que destaca es cómo la visión del producto liderada por el fundador influyó en la estrategia desde el inicio:
Esto no fue un cambio de marketing; impulsó decisiones de producto, alianzas y la forma en que Zscaler explicaba el “por qué” a compradores corporativos conservadores. Con el tiempo, esa claridad ayudó a convertir “seguridad entregada desde la nube” y “Zero Trust” de ideas a partidas presupuestarias—algo que las grandes empresas podían comprar, desplegar y estandarizar.
Durante años, la seguridad empresarial se construyó alrededor de una idea simple: mantener “las cosas buenas” dentro de la red corporativa y poner un muro alrededor. Ese muro solía ser una pila de appliances on‑premise—firewalls, proxies web, prevención de intrusiones—colocados en unos pocos centros de datos. Los empleados remotos entraban por VPN, que efectivamente “extendía” la red interna a dondequiera que estuvieran.
Cuando la mayoría de las apps vivían en los centros de datos de la compañía, esto funcionaba razonablemente bien. El tráfico web y de aplicaciones fluía por los mismos puntos de estrangulamiento, donde los equipos de seguridad podían inspeccionar, registrar y bloquear.
Pero el modelo asumía dos cosas que empezaron a no ser ciertas:
A medida que los empleados se volvieron más móviles y la adopción de SaaS se aceleró, los patrones de tráfico se invirtieron. Personas en cafeterías necesitaban acceso rápido a Office 365, Salesforce y decenas de herramientas basadas en navegador—a menudo sin tocar nunca un centro de datos corporativo.
Para seguir aplicando políticas, muchas empresas "backhauleaban" el tráfico: enviar las solicitudes de Internet y SaaS de un usuario a la sede primero, inspeccionarlas y luego reenviarlas. El resultado fue previsible: bajo rendimiento, usuarios insatisfechos y una presión creciente para abrir excepciones en los controles.
La complejidad se disparó (más appliances, más reglas, más excepciones). Las VPN se sobrecargaron y se volvieron riesgosas cuando otorgaban acceso amplio a la red. Y cada nueva sucursal u adquisición significaba otro despliegue de hardware, más planificación de capacidad y una arquitectura más frágil.
Ese hueco—necesitar seguridad consistente sin obligar a que todo pase por un perímetro físico—creó la oportunidad para la seguridad entregada desde la nube que pudiera seguir al usuario y a la aplicación, no al edificio.
La apuesta definitoria de Zscaler era simple de decir pero difícil de ejecutar: entregar seguridad como un servicio en la nube, posicionado cerca de los usuarios, en lugar de como cajas dentro de la red de la empresa.
En este contexto, “seguridad en la nube” no significa proteger solo servidores en la nube. Significa que la propia seguridad se ejecuta en la nube—de modo que un usuario en una sucursal, en casa o en móvil se conecta a un punto de presencia (PoP) cercano, y la política se aplica allí.
“Inlining” es como redirigir el tráfico por un punto de control de seguridad en el camino hacia su destino.
Cuando un empleado visita un sitio web o una app en la nube, su conexión se dirige primero al servicio. El servicio inspecciona lo que puede (según la política), bloquea destinos riesgosos, escanea en busca de amenazas y luego reenvía el tráfico permitido. La meta es que los usuarios no necesiten “estar en la red corporativa” para obtener protección de nivel corporativo—la seguridad viaja con el usuario.
La seguridad entregada desde la nube cambia la realidad diaria para los equipos de TI y seguridad:
Este modelo también se alinea con cómo trabajan las empresas hoy: el tráfico a menudo va directo a SaaS y a Internet público, no “de vuelta a la sede” primero.
Poner a un tercero en línea plantea preocupaciones reales que los equipos deben evaluar:
La apuesta central, entonces, no es solo técnica: es la confianza operativa de que un proveedor en la nube puede aplicar políticas de forma fiable, transparente y a escala global.
Zero Trust es un principio simple: nunca asumas que algo es seguro solo porque está “dentro de la red de la empresa.” En su lugar, verifica siempre quién es el usuario, en qué dispositivo está y si debe acceder a una app o dato específico—cada vez que importe.
El pensamiento tradicional de VPN es como dar a alguien una tarjeta que abre todo el edificio una vez pasado el control. Tras la conexión VPN, muchos sistemas tratan al usuario como “interno”, lo que puede exponer más de lo deseado.
Zero Trust invierte ese modelo. Es más como dar acceso a una sala para una tarea. No te "unirás a la red" de forma amplia; solo podrás alcanzar la app para la que estás aprobado.
Un contratista necesita acceso a una herramienta de gestión de proyectos por dos meses. Con Zero Trust, se le permite esa única app—sin dejarle una vía hacia nóminas o herramientas administrativas internas.
Un empleado usa su propio portátil (BYOD) mientras viaja. Las políticas Zero Trust pueden exigir comprobaciones de inicio de sesión más fuertes o bloquear el acceso si el dispositivo está desactualizado, no cifrado o muestra signos de compromiso.
El trabajo remoto se vuelve más fácil de asegurar porque la decisión de seguridad sigue al usuario y a la app, no a la oficina física.
Zero Trust no es un producto único que compras y “enciendes”. Es un enfoque de seguridad implementado mediante herramientas y políticas.
Tampoco significa “no confiar en nadie” de forma hostil. En la práctica, significa que la confianza se gana continuamente mediante comprobaciones de identidad, postura del dispositivo y el principio de mínimo privilegio—así los errores y brechas no se propagan automáticamente.
Zscaler es más fácil de entender como un “punto de control” en la nube que se sitúa entre las personas y lo que intentan alcanzar. En lugar de confiar en un límite de red corporativa, evalúa cada conexión según quién es el usuario y cómo es la situación, y aplica la política adecuada.
La mayoría de los despliegues se describen con cuatro piezas simples:
Conceptualmente, Zscaler divide el tráfico en dos carriles:
Esa separación importa: un carril trata del uso seguro de Internet; el otro, del acceso preciso a sistemas internos.
Las decisiones no se basan en una dirección IP de oficina confiable. Se basan en señales como quién es el usuario, salud del dispositivo (gestionado vs. no gestionado, parcheado vs. desactualizado) y desde dónde/cómo se conectan.
Si se hace bien, este enfoque reduce la superficie de ataque expuesta, limita el movimiento lateral si algo sale mal y convierte el control de acceso en un modelo de políticas más simple y consistente—especialmente cuando el trabajo remoto y las pilas de apps cloud‑first son el estándar.
Cuando la gente habla de “seguridad empresarial”, a menudo imagina apps privadas y redes internas. Pero gran parte del riesgo está en el lado abierto de Internet: empleados visitando sitios de noticias, haciendo clic en enlaces de correo, usando herramientas basadas en navegador o subiendo archivos a apps web.
Una Secure Web Gateway (SWG) es la categoría creada para hacer ese acceso cotidiano a Internet más seguro—sin obligar a que todo el tráfico del usuario pase por una oficina central.
En lo más simple, una SWG actúa como un punto de control entre los usuarios y la web pública. En lugar de confiar en lo que el dispositivo alcanza, la pasarela aplica políticas e inspección para reducir la exposición a sitios maliciosos, descargas riesgosas y fugas accidentales de datos.
Protecciones típicas incluyen:
El impulso vino cuando el trabajo se alejó de oficinas fijas hacia SaaS, navegadores y dispositivos móviles. Si los usuarios y las apps están en todas partes, reenviar tráfico a un perímetro corporativo añade latencia y crea puntos ciegos.
La SWG entregada desde la nube encajó con la nueva realidad: la política sigue al usuario, el tráfico se inspecciona cerca de donde se conectan y los equipos de seguridad obtienen control consistente en sedes, sucursales y trabajo remoto—sin tratar a Internet como una excepción.
Las VPN se diseñaron cuando “estar en la red” equivalía a “poder alcanzar las apps”. Ese modelo mental se rompe cuando las apps viven en múltiples nubes, SaaS y en una base cada vez menor on‑prem.
El acceso centrado en la app invierte la predeterminación. En lugar de colocar a un usuario dentro de la red interna (y luego confiar en que la segmentación funcione), el usuario se conecta solo a una aplicación específica.
Conceptualmente, funciona como una conexión intermediada: el usuario demuestra quién es y qué puede usar, y entonces se crea un camino corto y controlado hacia esa app—sin publicar rangos de IP internos en Internet y sin dar al usuario visibilidad amplia “interna”.
La segmentación de red es potente, pero en organizaciones reales suele ser frágil: fusiones, VLANs planas, apps legacy y excepciones se acumulan. La segmentación por app es más fácil de razonar porque se mapea a la intención del negocio:
Esto reduce la confianza implícita y hace que las políticas de acceso sean legibles: puedes auditar por aplicación y grupo de usuarios en vez de rastrear rutas y subredes.
La mayoría de los equipos no reemplazan la VPN de la noche a la mañana. Un despliegue práctico suele verse así:
Cuando el acceso centrado en apps se hace bien, las ganancias aparecen rápido: menos tickets por VPN, reglas de acceso más claras que seguridad y TI pueden explicar, y una experiencia de usuario más fluida—especialmente para empleados remotos e híbridos que solo quieren que la app funcione sin “conectarse a la red” primero.
Los grandes productos de seguridad no se vuelven estándares empresariales por sí solos. En la práctica, “distribución” en seguridad empresarial significa las rutas que un proveedor usa para llegar, ganar y desplegar con éxito dentro de organizaciones grandes—a menudo a través de otras empresas.
En seguridad, la distribución típicamente abarca:
Estos no son complementos opcionales. Son las tuberías que conectan a un proveedor con presupuestos, decisores y capacidad de implementación.
Las grandes empresas compran con cautela. Los partners proporcionan:
Para una plataforma como Zscaler, la adopción a menudo depende del trabajo real de migración—mover usuarios fuera de patrones legacy de VPN, integrar identidad y afinar políticas. Los partners pueden hacer que ese cambio parezca manejable.
La entrega en la nube transforma el negocio de instalaciones únicas a suscripción, expansión y renovaciones. Eso cambia la distribución: los partners dejan de ser solo “cerradores de tratos”. Pueden ser socios de despliegue continuo cuyos incentivos se alinean con los resultados del cliente—si el programa está bien diseñado.
Fíjate en los incentivos a partners, la calidad de la capacitación a partners (formación, playbooks, soporte de co‑venta) y cómo funcionan las transferencias de customer success una vez firmado el contrato. Muchos despliegues fallan no porque el producto sea débil, sino porque la propiedad entre proveedor, partner y cliente queda difusa.
La compra de seguridad rara vez empieza con “necesitamos mejor seguridad”. Normalmente arranca con un cambio en la red que rompe las antiguas suposiciones: más apps migran a SaaS, sucursales adoptan SD‑WAN o el trabajo remoto se vuelve permanente. Cuando el tráfico ya no fluye por una oficina central, el modelo de “proteger todo en la sede” se transforma en conexiones lentas, excepciones desordenadas y puntos ciegos.
A Zscaler a menudo se le menciona en las mismas conversaciones que SASE y SSE porque esas etiquetas describen un cambio en cómo se entrega la seguridad:
El verdadero “beneficio traducido” no es la sigla—es operaciones más simples: menos cajas on‑prem, actualizaciones de políticas más fáciles y acceso directo a apps sin reenviar tráfico por un centro de datos.
Una compañía típicamente evalúa enfoques estilo SSE/SASE cuando:
Cuando esos desencadenantes aparecen, la categoría “llega” de forma natural—porque la red ya cambió.
Comprar una plataforma Zero Trust suele ser la parte fácil. Hacerla funcionar sobre redes desordenadas, aplicaciones heredadas y gente real es donde los proyectos triunfan—o se estancan.
Las apps legacy son la ofensa recurrente. Los sistemas antiguos pueden asumir “dentro de la red = confiable”, depender de listas de IP hardcoded o fallar cuando el tráfico se inspecciona.
Los otros frenos son humanos: gestión del cambio, rediseño de políticas y debates sobre “quién posee qué”. Pasar de acceso amplio a reglas precisas por app obliga a los equipos a documentar cómo se trabaja realmente—y eso puede sacar a la luz brechas largamente ignoradas.
Los despliegues van mejor cuando seguridad no intenta operar sola. Espera coordinar con:
Comienza con un grupo de bajo riesgo (por ejemplo, un solo departamento o un subconjunto de contratistas) y define métricas de éxito por adelantado: menos tickets de VPN, acceso más rápido a apps, reducción medible en la superficie de ataque expuesta o mayor visibilidad.
Ejecuta el piloto por iteraciones: migra una categoría de apps a la vez, afina políticas y luego expande. La meta es aprender rápido sin convertir a la empresa entera en un entorno de pruebas.
Planea el logging y la resolución de problemas desde el día uno: dónde viven los logs, quién puede consultarlos, cuánto tiempo se retienen y cómo las alertas se integran en la respuesta a incidentes. Si los usuarios no pueden obtener ayuda cuando “la app está bloqueada”, la confianza cae rápido—aunque el modelo de seguridad sea sólido.
Un acelerador práctico (y a menudo pasado por alto) son herramientas internas: portales simples para solicitudes de excepciones, revisiones de acceso, inventarios de apps, seguimiento de despliegues e informes. Los equipos cada vez más construyen estas "apps glue" ligeras internamente en lugar de esperar la roadmap del proveedor. Plataformas como Koder.ai pueden ayudar a prototipar y lanzar estas herramientas web internas rápidamente vía flujos de trabajo impulsados por chat—útil cuando necesitas un dashboard React con backend en Go/PostgreSQL y iteraciones rápidas según maduran políticas y procesos.
Mover controles de seguridad de appliances que posees a una plataforma en la nube puede simplificar operaciones—pero también cambia los modos de falla que estás asumiendo. Tomar una buena decisión no es tanto “Zero Trust vs. legado” como entender los nuevos modos de fallo.
Si una plataforma provee seguridad web, acceso a apps privadas, aplicación de políticas y logging, reduces el número de herramientas—pero también concentras el riesgo. Una disputa contractual, un cambio de precios o una carencia de producto puede tener un radio de impacto mayor que cuando esas piezas están repartidas.
La seguridad en la nube añade un salto extra entre usuarios y apps. Cuando funciona bien, los usuarios casi no lo notan. Cuando una región tiene una caída, problema de enrutamiento o capacidad, la “seguridad” puede parecer “Internet caído”. Esto es menos sobre un proveedor y más sobre depender de conectividad siempre disponible.
Zero Trust no es un escudo mágico. Políticas mal acotadas (demasiado permisivas, demasiado restrictivas o inconsistentes) pueden aumentar la exposición o interrumpir el trabajo. Cuanto más flexible sea el motor de políticas, más disciplina se requiere.
Los despliegues por fases ayudan: comienza con un caso de uso claro (p. ej., un subconjunto de usuarios o una categoría de apps), mide latencia y resultados de acceso y luego expande. Define políticas en lenguaje claro, implementa monitorización y alertas desde el inicio y planifica redundancia (enrutamiento multi‑región, accesos break‑glass y rutas de fallback documentadas).
Sabe qué tipos de datos proteges (regulados vs. generales), alinea controles a necesidades de cumplimiento y programa revisiones periódicas de acceso. La meta no es comprar por miedo—es asegurarse de que el nuevo modelo falle de forma segura y predecible.
La lección repetible de Zscaler es foco: mover la aplicación de políticas de seguridad a la nube y hacer que el acceso dependa de la identidad. Al evaluar proveedores (o construir uno), haz una pregunta simple: “¿Cuál es la apuesta arquitectónica que simplifica todo lo demás?” Si la respuesta es “depende”, espera que la complejidad aparezca luego en costo, tiempo de despliegue y excepciones.
“Zero Trust” funcionó porque se tradujo en una promesa práctica: menos suposiciones de confianza implícita, menos enredos de red y mejor control a medida que las apps se movían fuera del local. Para los equipos, esto significa comprar resultados, no palabras de moda. Escribe tus resultados deseados (por ejemplo, “sin acceso entrante”, “mínimo privilegio a apps”, “política consistente para usuarios remotos”) y mapea cada uno a capacidades concretas que puedas probar.
La seguridad empresarial se difunde por redes de confianza: revendedores, GSIs, MSPs y marketplaces de nube. Los fundadores pueden copiar esto construyendo un producto listo para partners desde temprano—empaquetado claro, márgenes previsibles, playbooks de despliegue y métricas compartidas. Los líderes de seguridad también pueden aprovechar partners: úsalos para la gestión del cambio, integración de identidad y migraciones por fases en lugar de intentar capacitar a todos los equipos internamente.
Comienza con un caso de uso de alto volumen (a menudo acceso a Internet o una app crítica), mide antes/después y expande.
Preguntas clave de despliegue:
No te limites a “vender seguridad”—vende una ruta de migración. La historia ganadora suele ser: dolor → primer paso más simple → victoria medible → expansión. Construye el onboarding y los informes que hagan visible el valor en 30–60 días.
Un patrón amigo del fundador es complementar el producto core con apps compañeras rápidas de construir (flujos de evaluación, trackers de migración, calculadoras de ROI, portales para partners). Si quieres crearlas sin rehacer una pila legacy, Koder.ai está pensado para “vibe‑coding” de aplicaciones full‑stack desde chat—útil para llevar herramientas internas o para clientes a producción rápido y luego iterar conforme evoluciona la distribución.
Si quieres profundizar, ve a /blog/zero-trust-basics y /blog/sase-vs-sse-overview. Para ideas de empaquetado, visita /pricing.
Zero Trust es un enfoque en el que las decisiones de acceso se toman por solicitud basándose en la identidad, la postura del dispositivo y el contexto, en lugar de asumir que algo es seguro porque está “dentro de la red”. En la práctica, significa:
Una VPN tradicional suele colocar al usuario “en la red”, lo que puede exponer sistemas innecesarios. El acceso centrado en la aplicación invierte el modelo:
“Inline” significa que el tráfico se enruta a través de un punto de control de seguridad antes de llegar a Internet o a una app en la nube. En un modelo entregado desde la nube, ese punto de control vive en un punto de presencia (PoP) cercano, por lo que el proveedor puede:
El objetivo es tener seguridad consistente sin forzar que todo el tráfico pase por la sede central.
El reenvío (backhauling) manda el tráfico web y SaaS de un usuario remoto a un centro de datos central para inspección y luego lo vuelve a enviar a Internet. Suele fallar porque:
Una Secure Web Gateway (SWG) protege a los usuarios mientras navegan por Internet y usan aplicaciones SaaS. Capacidades comunes de una SWG:
Es especialmente útil cuando la mayor parte del tráfico va a Internet y los usuarios no están detrás de un único firewall corporativo.
La seguridad entregada desde la nube puede simplificar operaciones, pero cambia de qué dependes. Intercambios clave a evaluar:
Un piloto de bajo riesgo suele triunfar cuando está estrechamente acotado y es medible:
El objetivo es aprender rápido sin convertir a toda la empresa en un entorno de pruebas.
La mala configuración sigue siendo frecuente porque pasar de “acceso a red” a “acceso por app/política” obliga a las organizaciones a definir la intención con precisión. Para reducir el riesgo:
SSE son controles de seguridad entregados desde la nube (como SWG y acceso a apps privadas) en el “edge”, cerca de los usuarios. SASE combina ese modelo de seguridad con la parte de redes (a menudo SD-WAN) para que conectividad y seguridad se diseñen juntos.
En términos de compra:
Las grandes empresas suelen comprar con cautela y a través de partners; socios y alianzas ayudan porque:
Un ecosistema de partners sólido puede determinar si una plataforma se convierte en un estándar o se queda en pequeñas implementaciones.
