Практический разбор того, как Джей Чаудри и Zscaler использовали облачную безопасность, Zero Trust и партнёрскую дистрибуцию, чтобы создать ведущую корпоративную платформу безопасности.
Это не биография Джея Чаудри. Это практическая история о том, как Zscaler помог переосмыслить безопасность предприятий — и почему его технические и коммерческие решения имели значение.
Вы параллельно узнаете две вещи:
Современная корпоративная безопасность — это набор контролей, который позволяет сотрудникам безопасно пользоваться интернетом и внутренними приложениями, не предполагая, что что‑то безопасно только потому, что оно «внутри» корпоративной сети. Речь уже не о том, чтобы вырастить большую стену вокруг дата‑центра, а о проверке кто подключается, к чему он подключается и должен ли быть разрешён этот доступ — каждый раз.
К концу вы сможете объяснить основную ставку Zscaler в одном предложении, понять, где zero trust заменяет мышление эпохи VPN, и увидеть, почему стратегия дистрибуции может быть не менее важна, чем дизайн продукта.
Джей Чаудри — серийный предприниматель, наиболее известный как основатель и CEO Zscaler, компании, которая помогла перенести фокус корпоративной безопасности с «защищать корпоративную сеть» на «защищать пользователей и приложения, где бы они ни находились». До Zscaler он создал и продал несколько стартапов в сфере безопасности, что дало ему фронт‑ро опыт быстрого изменения поведения атакующих и ИТ‑ландшафта компаний.
Фокус Чаудри с Zscaler был прост: по мере того как работа и приложения уходили с корпоративной сети (в сторону публичного интернета и облаков), старая модель маршрутизации всего трафика через центральный дата‑центр для инспекции начала давать сбои.
Этот переход создал болезненный компромисс для команд ИТ:
Исходная предпосылка Zscaler была такова: безопасность должна следовать за пользователем, а не за зданием.
Особенно выделяется то, как продуктовая визия основателя повлияла на раннюю стратегию компании:
Это было не маркетинговое изменение; оно определило продуктовые решения, партнёрства и то, как Zscaler объяснял «почему» консервативным корпоративным покупателям. Со временем эта ясность помогла превратить «доставляемую из облака безопасность» и «zero trust» из идей в бюджетные строки — то, что крупные компании могли купить, развернуть и стандартизировать.
Долгое время корпоративная безопасность строилась вокруг простой идеи: держать «ценное» внутри сети и возвести вокруг него стену. Эта стена обычно представляла стек локальных устройств — фаерволы, веб‑прокси, системы предотвращения вторжений — размещённые в нескольких дата‑центрах. Удалённые сотрудники подключались через VPN, который фактически «продлевал» внутреннюю сеть туда, где они находились.
Когда большинство приложений размещалось в дата‑центрах компании, это работало довольно неплохо. Веб‑ и приложенческий трафик шёл через одни и те же узкие места, где команды безопасности могли инспектировать, логировать и блокировать.
Но модель исходно предполагала две вещи, которые стали постепенно терять актуальность:
По мере усиливающейся мобильности сотрудников и ускоренной адаптации SaaS‑сервисов паттерны трафика перевернулись. Людям в кофейнях нужен быстрый доступ к Office 365, Salesforce и десяткам браузерных инструментов — зачастую без касания корпоративного дата‑центра.
Чтобы продолжать применять политики, многие компании стали «обратно прокидывать» трафик: отправлять интернет‑и SaaS‑запросы пользователя через HQ, инспектировать, а затем отправлять обратно. Результат был предсказуем: медленная работа, недовольные пользователи и рост давления ради обходов.
Сложность взлетела (больше устройств, больше правил, больше исключений). VPN‑ы перегружались и становились рискованными, когда давали широкий сетевой доступ. А каждое новое отделение или поглощение означало ещё один развёрнутый железный узел, больше планирования мощностей и более хрупкую архитектуру.
Этот разрыв — необходимость последовательной безопасности без принудительной маршрутизации через физический периметр — и создал нишу для облачно‑доставляемой безопасности, которая могла следовать за пользователем и приложением, а не за зданием.
Ключевая ставка Zscaler была проста в формулировке, но сложна в исполнении: доставлять безопасность как облачный сервис, позиционируя её близко к пользователям, а не как коробки внутри сети компании.
В этом контексте «облачная безопасность» не означает лишь защиту облачных серверов. Это значит, что сама безопасность работает в облаке — пользователь в филиале, дома или на мобильном подключается к ближайшей точке присутствия (PoP), и там применяются политики.
«Inline» похоже на пропускной пункт безопасности по пути к месту назначения.
Когда сотрудник обращается к сайту или облачному приложению, его соединение направляется через сервис. Сервис инспектирует то, что может (в соответствии с политикой), блокирует рискованные адреса, сканирует на угрозы и затем пересылает разрешённый трафик дальше. Цель — чтобы пользователям не нужно было «быть в корпоративной сети», чтобы получить корпоративную защиту — безопасность следует за пользователем.
Облачная доставка безопасности меняет повседневную реальность для ИТ и команд безопасности:
Эта модель также соответствует тому, как компании реально работают сейчас: трафик часто идёт напрямую в SaaS и публичный интернет, а не «через HQ».
Помещение третьей стороны inline создаёт реальные вопросы, которые команды должны оценить:
Таким образом, ставка не только техническая — это операционная уверенность, что облачный провайдер сможет надёжно, прозрачно и в глобальном масштабе применять политики.
Zero trust — простой принцип: никогда не считать объект безопасным только потому, что он «внутри корпоративной сети». Вместо этого всегда проверяйте, кто пользователь, на каком устройстве он, и должен ли он получать доступ к конкретному приложению или данным — каждый раз, когда это важно.
Традиционное мышление VPN похоже на выдачу бейджа, который открывает всё здание после входа. После подключения по VPN многие системы трактуют пользователя как «внутреннего», что может привести к излишним экспозициям.
Zero trust меняет модель. Это скорее как дать человеку доступ в одну комнату для одной задачи. Вы не «вступаете» в сеть широко; вам разрешён доступ только к тому приложению, на которое вы имеете право.
Подрядчику нужен доступ к системе управления проектом на два месяца. С zero trust ему разрешают только это приложение — без побочных путей к зарплатным системам или административным консольям.
Сотрудник использует BYOD в поездке. Политики zero trust могут требовать более строгой проверки входа или блокировать доступ, если устройство устарело, не зашифровано или выглядит скомпрометированным.
Удалённая работа становится проще в защите, потому что решение по безопасности следует за пользователем и приложением, а не за физической офисной сетью.
Zero trust — это не один продукт, который вы купили и «включили». Это подход к безопасности, реализуемый с помощью инструментов и политик.
И это не означает «никому не доверять» в враждебном смысле. На практике это значит, что доверие постоянно зарабатывается через проверки идентичности, состояние устройств и принцип минимально необходимого доступа — чтобы ошибки и утечки не распространялись автоматически.
Zscaler проще всего понять как облачную «точку контроля», стоящую между людьми и тем, к чему они пытаются добраться. Вместо доверия корпоративному сетевому периметру она оценивает каждое соединение по тому, кто пользователь и какие условия наблюдаются, а затем применяет соответствующую политику.
Большинство развёртываний можно описать четырьмя простыми компонентами:
Концептуально Zscaler разделяет трафик на две линии:
Это разделение важно: одна полоса отвечает за безопасное использование интернета, другая — за точный доступ к внутренним системам.
Решения больше не основаны на доверии к IP‑адресу офиса. Они опираются на сигналы вроде кто пользователь, состояние устройства (управляемое vs. неуправляемое, патчено vs. устарело) и откуда/как выполняется подключение.
При грамотном исполнении такой подход сокращает поверхность атаки, ограничивает латеральное распространение при инцидентах и превращает контроль доступа в более простую, последовательную модель политики — особенно когда удалённая работа и облачно‑первичные стеки приложений становятся нормой.
Когда говорят об «корпоративной безопасности», часто представляют внутренние приложения и сети. Но большая часть риска лежит на стороне открытого интернета: сотрудники читают новости, кликают ссылки в письмах, пользуются браузерными инструментами или загружают файлы в веб‑сервисы.
Secure Web Gateway (SWG) — категория решений, созданная, чтобы сделать этот повседневный доступ к интернету безопаснее — без необходимости прокидывать трафик каждого пользователя через центральный офис.
Проще говоря, SWG действует как контролируемый пропускной пункт между пользователями и публичным вебом. Вместо того чтобы доверять всему, к чему подключается устройство, шлюз применяет политику и инспекцию, чтобы сократить риск перехода на вредоносные сайты, загрузки небезопасных файлов и случайной утечки данных.
Типичные защиты включают:
Поворотный момент наступил, когда работа ушла из фиксированных офисов и сместилась в сторону SaaS, браузеров и мобильных устройств. Если пользователи и приложения повсюду, то обратная прокачка трафика в единый корпоративный периметр добавляет задержки и создаёт слепые зоны.
Облачный SWG соответствовал новой реальности: политика следует за пользователем, трафик можно инспектировать ближе к месту подключения, и команды безопасности получают последовательный контроль по всем локациям — без превращения интернета в исключение.
VPN создавались для времени, когда «быть в сети» означало «иметь доступ к приложениям». Эта модель рушится, когда приложения живут в разных облаках, SaaS и число локальных систем сокращается.
Ориентированный на приложение доступ меняет дефолт. Вместо того чтобы помещать пользователя в внутреннюю сеть (с надеждой, что политики сегментации сработают), создаётся соединение только к конкретному приложению.
Концептуально это работает как брокерское подключение: пользователь доказывает, кто он и к чему имеет право, затем создаётся короткий контролируемый путь к этому приложению — без публикации внутренних IP‑диапазонов в интернете и без широкого доступа к «внутренней» видимости.
Сетевые сегменты мощны, но на практике хрупки: слияния, плоские VLAN, старые приложения и исключения накапливаются. Сегментация по приложениям проще для понимания, потому что она соответствует бизнес‑намерениям:
Это снижает имплицитное доверие и делает политики доступов понятными: их можно проверять по приложению и группе пользователей, а не по маршрутам и подсетям.
Большинство команд не выключают VPN одномоментно. Практический план часто выглядит так:
При правильном внедрении выигрыши проявляются быстро: меньше запросов в поддержку по VPN, понятные правила доступа, которые легко объяснить сотрудникам, и более гладкий пользовательский опыт — особенно для удалённых и гибридных сотрудников, которым просто нужно, чтобы приложение работало без «подключения к сети» сначала.
Отличные продукты по безопасности сами по себе не становятся стандартами в корпоративной среде. На практике «дистрибуция» означает набор путей, которыми вендор добирается до бюджетов, принятия решений и успешного развёртывания в крупных организациях — часто через другие компании.
В сфере безопасности дистрибуция обычно охватывает:
Это не опционные дополнения. Это трубы, соединяющие вендора с бюджетами, лицами, принимающими решения, и ресурсами внедрения.
Крупные предприятия покупают осторожно. Партнёры дают:
Для платформы вроде Zscaler принятие часто зависит от реальной миграционной работы — перевода пользователей с унаследованных паттернов VPN, интеграции идентичности и настройки политик. Партнёры делают эту работу управляемой.
Облако переводит бизнес от одноразовых установок к подписке, расширению и продлениям. Это меняет роль партнёров: они становятся не только «закрывателями сделок», но и долгосрочными партнёрами по развёртыванию, чьи стимулы могут быть выровнены с результатами клиента — при условии правильно построенной партнёрской программы.
Внимательно смотрите на стимулы партнёров, качество обучения партнёров (тренинги, плейбуки, поддержка совместных продаж) и насколько чисто происходит передача ответственности по customer success после подписания контракта. Многие развёртывания терпят неудачу не из‑за слабого продукта, а из‑за неясности ответственности между вендором, партнёром и заказчиком.
Покупка безопасности редко начинается с лозунга «нам нужна лучшая безопасность». Чаще она стартует из‑за сетевого изменения, которое ломает старые допущения: больше приложений уходит в SaaS, филиалы переходят на SD‑WAN, или удалённая работа становится постоянной. Когда трафик перестаёт идти через центральный офис, модель «защищать всё в HQ» превращается в медленные соединения, громоздкие исключения и слепые зоны.
Zscaler часто упоминают в контексте SASE и SSE, потому что эти ярлыки описывают сдвиг в том, как доставляется безопасность:
Реальная «прибыль» от этих концепций — не в аббревиатуре, а в упрощении операций: меньше локальных коробок, проще обновления политик и более прямой доступ к приложениям без обратной прокачки трафика через дата‑центр.
Компания обычно рассматривает SSE/SASE, когда:
Когда эти триггеры появляются, категория «приходит» естественно — потому что сеть уже изменилась.
Купить платформу Zero Trust обычно проще, чем заставить её работать в разрозненных сетях, с наследуемыми приложениями и реальными людьми.
Повторяющийся виновник — унаследованные приложения. Старые системы могут полагать, что «внутри сети = доверие», полагаться на статические IP‑списки или ломаться при инспекции трафика.
Другие трения — человеческие: управление изменениями, переработка политик и споры о владении функциями. Переход от широкого сетевого доступа к чётким правилам по приложениям требует документирования реальных рабочих процессов — и это обычно обнаруживает давно игнорируемые пробелы.
Развёртывания проходят легче, когда безопасность не действует в одиночку. Ожидайте координации с:
Начните с группы с низким риском (например, один отдел или часть подрядчиков) и заранее определите метрики успеха: меньше тикетов по VPN, быстрее доступ к приложениям, измеримое сокращение экспонированной поверхности атаки или улучшенная видимость.
Проводите пилот итеративно: мигрируйте одну категорию приложений, настроите политики, затем расширяйте. Цель — быстро учиться без превращения всей компании в испытательный полигон.
Планируйте логирование и отладку с первого дня: где хранятся логи, кто может их запрашивать, сроки хранения и как алерты интегрируются в инцидент‑реакцию. Если пользователи не получают помощи при «блокировке приложения», доверие падает быстро — даже если модель безопасности верна.
Практичный и часто недооценённый ускоритель — внутренние инструменты: простые порталы для запросов исключений, ревью доступов, инвентаря приложений, трекинга развёртываний и отчётности. Команды всё чаще создают такие лёгкие «склеивающие» приложения сами, не ожидая дорожной карты вендора. Платформы типа Koder.ai помогают быстро прототипировать и выводить внутренние веб‑инструменты через чат‑ориентированные рабочие процессы — полезно, когда нужен React‑дашборд с бекендом на Go/PostgreSQL и быстрыми итерациями по мере зрелости политик и процессов.
Перенос контролей безопасности из ваших коробок в облачную платформу может упростить операции — но он меняет то, на что вы ставите. Хорошее решение не в выборе «Zero Trust vs. наследие», а в понимании новых сценариев отказа.
Если одна платформа обеспечивает веб‑безопасность, доступ к приватным приложениям, применение политик и логирование, вы сокращаете число инструментов — но также концентрируете риск. Спор по контракту, изменение ценообразования или функциональный пробел могут иметь широкий радиус воздействия по сравнению с распределённым набором инструментов.
Облачная безопасность добавляет дополнительный шаг между пользователями и приложениями. Когда всё работает, пользователи едва это замечают. Когда в регионе случается сбой, маршрутизация или дефицит ёмкости, «безопасность» может выглядеть как «интернет не работает». Это касается не только конкретного вендора, а общей зависимости от всегда‑доступного соединения.
Zero Trust — не волшебный щит. Неправильно настроенные политики (слишком разрешающие, слишком жёсткие или непоследовательные) могут либо увеличить риск, либо нарушить работу. Чем гибче движок политик, тем больше дисциплины требуется.
Фазированные развёртывания помогают: начните с понятного кейса (например, часть пользователей или одна категория приложений), измерьте задержки и результаты доступа, затем расширяйте. Описывайте политики простым языком, внедряйте мониторинг и алерты с самого начала и планируйте резервирование (маршрутизация по нескольким регионам, процедуры аварийного доступа и документированные пути отката).
Понимайте, какие типы данных вы защищаете (регулируемые vs. общие), соотнесите контроли с требованиями соответствия и планируйте регулярные ревью доступов. Цель не в страхе — а в том, чтобы новая модель падала безопасно и предсказуемо.
Повторяющийся урок Zscaler — фокус: переместить применение политик в облако и сделать доступ управляемым идентичностью. При оценке вендоров или построении продукта задайте простой вопрос: «Какая одна архитектурная ставка упрощает всё остальное?» Если ответ «зависит», готовьтесь увидеть сложность в стоимости, сроках развёртывания и исключениях.
«Zero trust» сработал потому, что он переводил идею в практическое обещание: меньше имплицитного доверия, меньше сетевой обвязки и лучший контроль по мере ухода приложений в облако. Для команд это значит покупать результаты, а не маркетинг. Запишите желаемые результаты (например, «нет входящих подключений», «минимально необходимые привилегии к приложениям», «единая политика для удалённых пользователей») и соотнесите каждую цель с конкретными возможностями, которые можно протестировать.
Корпоративная безопасность распространяется через сети доверия: реселлеры, GSIs, MSP и облачные маркетплейсы. Основатели могут перенять это, сделав продукт готовым к партнёрству с ранних этапов — чёткая упаковка, предсказуемые маржи, плейбуки по развёртыванию и общие метрики. Лидеры безопасности тоже могут использовать партнёров: привлекать их для управления изменениями, интеграции идентичности и фазированных миграций, вместо попыток прокачать все команды внутри компании одновременно.
Начните с одного кейса с высоким объёмом (часто интернет‑доступ или одно критическое приложение), измерьте до/после и расширяйте.
Ключевые вопросы для развёртывания:
Не просто «продавайте безопасность» — продавайте путь миграции. Побеждающая история обычно: боль → самый простой первый шаг → измеримый успех → расширение. Постройте онбординг и отчётность, которые показывают ценность за 30–60 дней.
Один из шаблонов для основателя — дополнить основной продукт быстрыми компаньон‑приложениями (оценочные рабочие процессы, трекеры миграции, калькуляторы ROI, партнёрские порталы). Если не хочется строить весь стек разработки, Koder.ai предназначен для «vibe‑coding» полноценных full‑stack приложений из чата — полезно для быстрого вывода внутренних или клиентских инструментов в продакшен с последующей итерацией по мере развития дистрибуции.
Если хотите углубиться, см. /blog/zero-trust-basics и /blog/sase-vs-sse-overview. Для идей по упаковке посетите /pricing.
Zero Trust — это подход, при котором решения об доступе принимаются для каждого запроса на основе идентичности, состояния устройства и контекста, а не на предположении, что что‑то безопасно просто потому, что «внутри сети». На практике это значит:
Традиционный VPN часто помещает пользователя «внутрь сети», что может непреднамеренно открывать доступ к лишним системам. Подход, ориентированный на приложения, меняет модель:
«Inline» означает, что трафик проходит через контрольную точку безопасности перед тем, как достичь интернета или облачного приложения. В модели облачной доставки эта контрольная точка располагается в ближайшей точке присутствия (PoP), поэтому провайдер может:
Цель — обеспечить последовательную защиту без необходимости возвращать трафик в головной офис.
Схема с обратной прокачкой отправляет веб- и SaaS‑трафик удалённого пользователя в центральный дата‑центр для проверки, а затем обратно в интернет. Она обычно даёт такие проблемы:
Защитный веб‑шлюз (Secure Web Gateway, SWG) защищает пользователей при серфинге в интернете и при работе с SaaS‑приложениями. Обычные функции SWG включают:
Это особенно полезно, когда основной трафик уходит в интернет, а пользователи не находятся за единым корпоративным фаерволом.
Облачная доставка безопасности может упростить операции, но меняет набор зависимостей. Основные компромиссы, которые нужно оценивать:
Успешный пилот обычно узко сфокусирован и измерим:
Цель — быстро учиться, не превращая всю компанию в тестовую площадку.
Ошибки конфигурации остаются главной угрозой, потому что переход от «доступа к сети» к «доступу к приложениям/политикам» заставляет команды чётко формулировать намерения. Чтобы снизить риск:
SSE — это облачно доставляемые контролы безопасности (например, SWG и доступ к приватным приложениям) на «краю», близко к пользователям. SASE объединяет эту модель безопасности с сетевыми функциями (обычно SD‑WAN), чтобы планировать коннективность и безопасность вместе.
В терминах покупки:
Крупные компании часто покупают через партнёров и нуждаются в ресурсах внедрения. Канальные партнёры, SI/МСP и альянсы помогают:
Сильная партнёрская экосистема часто определяет, станет ли платформа стандартом или застрянет после небольшой пилотной фазы.
