История Zscaler и Джея Чаудри: как облачная модель, Zero Trust и ставка на партнёрские продажи помогли выстроить крупного игрока в энтерпрайзе.
Zscaler — удобный пример того, как за несколько лет изменились правила игры в корпоративной информационной безопасности. Это не просто «ещё один вендор», а история о том, почему привычный периметр (VPN, межсетевые экраны на границе, «внутри доверяем — снаружи защищаемся») перестал соответствовать реальности: облака, удалённая работа, подрядчики, SaaS и постоянные изменения инфраструктуры.
Джей Чаудри — предприниматель, который строил компании в ИБ и сетях задолго до того, как Zero Trust стал модным термином. Здесь важна не биография ради биографии, а управленческий вывод: успех Zscaler вырос из последовательных продуктовых ставок и дисциплины в продажах на энтерпрайз‑рынке. Это кейс про стратегию, а не про «счастливый момент».
Zscaler показал, что безопасность можно вынести ближе к пользователю и приложению, а не привязывать к офису и сети. Такой поворот меняет многое: архитектуру доступа, модель внедрения, закупку (CAPEX → OPEX), требования к партнёрам и язык, которым ИБ объясняет ценность бизнесу.
В этой статье мы разложим кейс на три слоя:
Материал ориентирован на ИТ‑руководителей, CISO и команды ИБ, специалистов по закупкам и партнёров/интеграторов. Цель — дать практичную рамку: какие решения стоят за ростом Zscaler и какие вопросы полезно задать, планируя свою стратегию защиты доступа.
Ещё недавно корпоративная безопасность строилась вокруг простой идеи: «всё важное — внутри офиса и дата‑центра». Трафик сотрудников шёл в штаб‑квартиру, там стояли шлюзы, прокси и системы фильтрации, а наружу выпускали только «проверенное». Это работало, пока приложения и данные действительно жили внутри.
С ростом SaaS (почта, CRM, документооборот), удалённой работы и мобильности маршруты перевернулись. Сотрудник в командировке или дома чаще обращается не к серверу в офисе, а к облачному сервису. Если при этом компания заставляет «гнать всё через периметр», появляется эффект «шланга через офис»: лишние задержки, перегруз каналов, ухудшение качества видеосвязи и постоянные жалобы бизнеса.
Периметр перестал быть единым местом контроля. Десятки филиалов, тысячи устройств, подрядчики и временные доступы — всё это плохо стыкуется с VPN и классической моделью доверия «внутри — можно, снаружи — нельзя», когда пользователь и приложение постоянно меняют локацию.
Проблемы стали не только в скорости, но и в рисках:
Логика «поставим ещё один appliance» упирается в масштабы: оборудование нужно закупать, обновлять, настраивать в каждом узле, а политики начинают расходиться между офисами. В итоге безопасность становится лоскутной — дорогой, сложной и при этом не всегда эффективной.
Облачная безопасность как сервис — это когда «точка контроля» находится не в вашей серверной и не в наборе коробок на периметре, а в облачной платформе провайдера. Пользователь подключается к ближайшему узлу сервиса, трафик проверяется по единым правилам, и только затем получает доступ к интернету или корпоративным приложениям.
В классической модели компания покупает устройства (шлюзы, прокси, VPN, фильтры), ставит их в нескольких дата‑центрах, обновляет и масштабирует сама. В облачной модели вы покупаете не железо, а функцию: безопасный доступ, инспекцию трафика, политики, отчётность — всё это работает как единая услуга.
Ключевое отличие не в том, где стоит прокси, а в том, как устроены управление и масштабирование:
Именно это стало рыночным переломом: безопасность перестала быть цепочкой разрозненных устройств, которые сложно синхронизировать, и стала сервисом, который проще расширять на новые регионы и сценарии работы.
Задержки. Обычно опасаются, что облачная проверка «замедлит интернет». На практике решают география узлов (ближайшая точка присутствия) и корректная маршрутизация.
Контроль. Важно понимать, кто управляет политиками и как выглядит аудит: какие журналы доступны, как настраиваются роли, как быстро можно расследовать инцидент.
Соответствие требованиям. Заказчики спрашивают про хранение логов, сертификации, шифрование и разделение данных между клиентами. Хороший сервис заранее даёт понятные ответы и документы, чтобы безопасность не упиралась в бюрократию.
Zero Trust часто звучит как модный ярлык, но по сути это простой принцип управления доступом: никому не доверять по умолчанию и проверять всегда. Не «поверить один раз при входе», а постоянно подтверждать, что запрос уместен и безопасен.
В классическом подходе безопасность строилась вокруг идеи «внутри сети — свои». Zero Trust меняет акцент: важен не факт, что пользователь «внутри», а может ли он прямо сейчас получить доступ к конкретному ресурсу.
Здесь полезно разделять понятия:
Zero Trust стремится заменить второе первым: доступ выдаётся точечно, по правилам.
Чтобы «проверять всегда», нужна связка нескольких вещей:
Это не «один продукт», не магическая кнопка и не синоним VPN‑замены. Также это не тотальный запрет всего: цель — дать доступ быстро, но минимально необходимый и контролируемый.
Самая опасная ловушка — формально объявить Zero Trust, но оставить старые привычки:
Zero Trust работает, когда правила становятся конкретнее, а исключения — временными, измеримыми и объяснимыми.
Изначальная ставка на веб‑трафик и облачные приложения выглядела не «модной», а прагматичной: у сотрудников и подрядчиков всё больше рабочих сценариев уходило из корпоративной сети в браузер и SaaS. Там, где раньше хватало фильтрации на выходе в интернет, появились десятки внешних сервисов, прямые подключения из дома и мобильных сетей, а также постоянные попытки обойти правила.
В этой логике безопасный веб‑шлюз и прокси становятся не просто «фильтром сайтов». Это точка, где можно централизованно применять политику и проводить инспекцию трафика: кто именно подключается, к какому приложению, что именно передаётся, нет ли вредоносного содержимого или утечек данных.
Ценность в том, что правила живут не на разрозненных устройствах по офисам, а в одном месте — и одинаково работают для пользователя в штаб‑квартире, в командировке или дома.
Дальше подход закономерно расширился: если контроль уже вынесен ближе к пользователю и интернету, его можно применить не только к веб‑сайтам, но и к доступу к внутренним системам, частным приложениям, API и корпоративным сервисам.
Так продуктовая идея эволюционирует от «защиты выхода в интернет» к платформе безопасного доступа: единые политики, единая видимость, единый опыт подключения — независимо от того, где находится ресурс и как к нему приходит пользователь.
У облачного подхода есть уязвимые места, о которых важно говорить заранее. Во‑первых, зависимость от качества связи: если канал нестабилен, страдает пользовательский опыт и иногда приходится продумывать резервные маршруты.
Во‑вторых, интеграции: реальная ценность платформы раскрывается, когда она связана с вашим управлением идентификациями, каталогами пользователей, журналированием и процессами реагирования. Недооценка объёма интеграционных работ — частая причина разочарования (обычно не в продукте, а во внедрении).
Крупным компаниям сложнее всего поддерживать безопасность «равномерно»: офисы, филиалы, подрядчики, гибридная инфраструктура и тысячи устройств постоянно меняют картину. Облачная модель безопасности решает это не отдельными коробками в каждом месте, а единым сервисом, который видит пользователей и трафик там, где они реально работают.
Ключевая ценность для энтерпрайза — единая политика, которая применяется одинаково к сотруднику в штаб‑квартире, в командировке или на удалёнке. Правила привязываются не к «месту в сети», а к идентичности и контексту: кто пользователь, какое устройство, какой риск, к какому приложению идёт запрос.
Это снижает хаос «локальных исключений», когда филиалы живут по своим правилам, а безопасность превращается в набор разрозненных договорённостей.
Когда безопасность доставляется как облачная услуга, отпадает необходимость проектировать и поддерживать сложные цепочки: VPN‑концентраторы, региональные прокси, отдельные точки выхода в интернет, разный стек в каждом офисе.
Практический эффект для операционных затрат:
Консолидация — это когда несколько функций (например, безопасный веб‑шлюз, контроль доступа к SaaS, сегментация доступа) управляются из одной консоли и живут в одной политике. Для ИТ‑директора это означает меньше поставщиков, меньше интеграций, меньше «стыков», где теряются логи и ответственность.
Доступ к SaaS: сотрудник получает доступ по принципу наименьших привилегий, а политика одинаково применима из офиса и из дома.
Интернет‑доступ филиалов: трафик не нужно «тащить» в центральный дата‑центр ради проверки — политика применяется ближе к пользователю.
Удалённые сотрудники: вместо перегруженного VPN — контролируемый доступ к конкретным приложениям, с учётом устройства и риска.
Продавать ИБ‑платформу напрямую почти всегда дорого: длинные циклы согласований, пилоты, безопасность как «нефункциональное требование» и десятки стейкхолдеров — от ИБ до сетевиков и закупок. У вендора быстро появляется потолок: чтобы закрывать больше сделок, нужно пропорционально наращивать пресейл, архитекторов, поддержку и ресурсы на внедрение.
Канал обычно собирается из нескольких типов партнёров, и каждый закрывает свой кусок пути клиента:
Для крупных компаний самое сложное — не покупка, а переход: миграция трафика, разделение пользователей по политикам, настройка исключений, обучение и поддержка. Партнёр с опытом делает это предсказуемым: предлагает типовые сценарии, план миграции «волнами», берёт на себя коммуникации между ИБ и ИТ и помогает дойти до измеримых результатов (например, снижение инцидентов, ускорение доступа).
Канал может и навредить, если не управлять качеством:
Сильные вендоры строят партнёрскую программу так, чтобы партнёрам было выгодно продавать результат, а не только лицензии: обучение, сертификации, совместные кейсы и прозрачные правила регистрации сделок.
Большинство корпоративных закупок ИБ «ломается» не на технологии, а на коммуникации. Когда команда продавца начинает разговор со слов Zero Trust, SASE или «безопасный веб‑шлюз», часть аудитории слышит маркетинг и выключается. Работает обратный подход: сначала — конкретная боль и сценарий, потом — как облачная безопасность закрывает его на практике.
В Go‑to‑market важно упаковать одно и то же решение в разные обещания результата:
Важно говорить не «мы про Zero Trust», а «мы убираем неуправляемый доступ к приложениям и данным — даже когда сотрудники вне офиса».
Пилот должен отвечать на вопрос «что изменится через 2–4 недели» и иметь измеримые показатели. Хорошая практика — заранее согласовать, какие данные считаются успехом:
Кстати, на этом этапе часто не хватает скорости в подготовке артефактов: описаний сценариев, матриц доступа, планов пилота, чек‑листов интеграций. Для такой «упаковки изменений» удобно использовать TakProsto.AI: в режиме чата быстро собрать структуру пилота, согласовать формулировки политик и подготовить черновики документов для ИБ/ИТ/закупок — с возможностью вернуться к снапшотам и откатиться к предыдущей версии.
Страх продаёт плохо в энтерпрайзе: он вызывает спор о вероятностях. Лучше продавать через сценарии: безопасный доступ подрядчиков, защита SaaS, контроль BYOD, сегментация доступа к критичным приложениям. Термины (Zero Trust, SASE) остаются в презентации, но не становятся главным аргументом — им становится измеримый результат.
Переход к Zero Trust редко бывает «большим переключателем». Чаще это серия небольших, управляемых шагов, которые постепенно заменяют привычный периметр (VPN и сетевые исключения) на доступ по идентичности, контексту и политике.
На практике многие компании застревают в гибридном состоянии: старые VPN остаются для «сложных» пользователей, параллельно появляются облачные политики, а для критичных систем выдаются исключения. Такая смесь повышает риск по трём причинам.
Во‑первых, растёт количество путей доступа: один и тот же сервис можно открыть через VPN, через прокси‑политику и через прямой интернет — контролировать это сложно.
Во‑вторых, исключения становятся «тихими дырами»: они редко пересматриваются, но активно наследуются при изменениях.
В‑третьих, пользователи получают разный опыт доступа, что провоцирует обходные решения и сопротивление изменениям.
Инвентаризация: приложения, типы пользователей, устройства, маршруты трафика, текущие правила и исключения.
Сегментация: разделите доступ по группам (офисные/удалённые, подрядчики, привилегированные роли) и по чувствительности приложений.
Политики доступа: определите минимально необходимый доступ (least privilege) с учётом роли, состояния устройства и уровня риска.
Миграция трафика: переносите потоки постепенно — начните с веб‑доступа и некритичных SaaS, затем внутренние приложения, и только потом «тяжёлые» случаи.
Лучший подход — пилоты на добровольцах и «тихой» группе, измерение задержек и частоты запросов на доступ, а затем расширение. Важно заранее подготовить поддержку: понятные инструкции, быстрый процесс выдачи прав и режим отката для критичных задач.
Чтобы политики работали стабильно, обычно подключают:
Так Zero Trust становится не «проектом безопасности», а управляемым процессом: понятные правила, постепенная миграция и измеримый результат.
Покупка облачной платформы безопасности — это не «выбрать бренд», а убедиться, что решение закрывает ваши реальные сценарии доступа и при этом не усложняет жизнь пользователям. Ниже — практичный набор проверок, который помогает вести переговоры и проводить пилот без самообмана.
Сначала перечислите, что именно вы защищаете: доступ в интернет, доступ к SaaS, доступ к внутренним приложениям, удалённые сотрудники, подрядчики, филиалы, BYOD.
Попросите поставщика показать, как каждый сценарий реализуется «из коробки» и что потребует доработок: агенты, прокси‑настройки, коннекторы, изменения в DNS, исключения для приложений.
Отдельно проверьте поддержку: SLA, часы работы, язык, выделенный инженер, скорость эскалаций. В крупных внедрениях качество поддержки часто важнее списка функций.
Составьте список систем, с которыми решение должно дружить: IdP/SSO, MFA, EDR, SIEM/SOAR, DLP, MDM, сервис‑деск.
Важно не «галочка в презентации», а уровень интеграции: какие атрибуты пользователя доступны для политик, как передаются события, насколько удобно расследование.
Задайте прямые вопросы:
Пилотируйте на «сложных» группах: удалённые сотрудники, приложения с чувствительной задержкой, тяжёлые SaaS.
Согласуйте метрики заранее: задержка, скорость открытия страниц, процент ошибок, стабильность агента, количество исключений, нагрузка на службу поддержки.
Сравнивайте решения по единому набору требований и одинаковым тестам. В TCO учитывайте не только лицензии, но и эксплуатацию: время админов, поддержку пользователей, стоимость трафика/коннекторов, обучение.
И главное — оцените риски миграции: сколько политик переносится автоматически, как откатиться назад, что будет с видимостью в SIEM, и сколько времени займёт переход по этапам. Если поставщик не готов зафиксировать план пилота и критерии успеха письменно, это сигнал остановиться и уточнить ожидания.
Переход на облачную модель безопасности и Zero Trust часто воспринимают как «включил сервис — и всё защищено». Это опасная иллюзия: облако меняет инструменты и архитектуру, но качество защиты по‑прежнему определяется настройками, дисциплиной и зрелостью процессов.
Облачный сервис может убрать часть рутины (железо, обновления, масштабирование), но не принимает за вас решения о том, кому, что и при каких условиях разрешать. Ошибки в модели доступа в облаке обычно распространяются быстрее: политика применяется централизованно — и так же централизованно может «сломать» безопасность или бизнес‑процессы.
Самые частые промахи связаны не с «дырами», а с логикой доступа:
Технология не заменяет операционку. Нужны понятные правила:
Слишком жёсткие ограничения подталкивают команды к обходным путям: личные почты, теневые файлообменники, «временные» админские права. Рабочая практика — вводить контроль поэтапно, измерять влияние на пользователей и договариваться о допустимом уровне риска — иначе вы получите не Zero Trust, а недоверие к ИБ.
История Zscaler ценна не брендом и не набором модных терминов, а тем, как последовательно решалась одна и та же бизнес‑проблема: безопасный доступ к приложениям и данным при постоянных изменениях (облака, удалённая работа, подрядчики, слияния).
Главный урок: перенос «точки контроля» ближе к пользователю и приложению часто даёт больший эффект, чем бесконечное укрепление периметра. Второй урок: Zero Trust — это не продукт, а набор правил доступа, которые можно внедрять поэтапно, измеряя результат. Третий: успех зависит от операционной модели — кто владеет политиками, кто отвечает за исключения и как быстро меняются правила.
Составьте список критичных приложений и потоков данных (хотя бы топ‑10) и укажите, кто и откуда к ним ходит.
Опишите минимальные требования доступа: устройство, контекст, роль, MFA, география.
Выберите один пилотный сценарий (например, доступ подрядчиков или офис→SaaS) и зафиксируйте критерии успеха.
Наведите порядок в идентификациях: группы, роли, жизненный цикл учёток, процесс выдачи/отзыва.
Подготовьте план отказа от устаревших подходов: какие VPN/пробросы портов/исключения должны исчезнуть первыми и почему.
Смотрите на три метрики: (1) покрытие политиками — доля пользователей и приложений, которые проходят через единые правила; (2) качество доступа — сколько запросов обрабатывается по «стандартному пути» без ручных исключений; (3) снижение зависимости от наследия — сколько сервисов перестало требовать постоянного VPN и статических сетевых допусков.
Какие риски для бизнеса мы закрываем в первую очередь? Где граница приемлемого трения для пользователей? Кто утверждает политики и исключения, и за какой срок? Как будет организована поддержка и реагирование на инциденты при новой модели доступа? Какие этапы миграции и критерии «готово» мы фиксируем в контракте и проектном плане?
Лучший способ понять возможности ТакПросто — попробовать самому.
