Джей Чаудри и Zscaler: как Zero Trust и облако дали рост

Зачем разбирать кейс Zscaler сегодня

Zscaler — удобный пример того, как за несколько лет изменились правила игры в корпоративной информационной безопасности. Это не просто «ещё один вендор», а история о том, почему привычный периметр (VPN, межсетевые экраны на границе, «внутри доверяем — снаружи защищаемся») перестал соответствовать реальности: облака, удалённая работа, подрядчики, SaaS и постоянные изменения инфраструктуры.

Кто такой Джей Чаудри и почему его путь важен

Джей Чаудри — предприниматель, который строил компании в ИБ и сетях задолго до того, как Zero Trust стал модным термином. Здесь важна не биография ради биографии, а управленческий вывод: успех Zscaler вырос из последовательных продуктовых ставок и дисциплины в продажах на энтерпрайз‑рынке. Это кейс про стратегию, а не про «счастливый момент».

Почему Zscaler — маркер смены подхода к «периметру»

Zscaler показал, что безопасность можно вынести ближе к пользователю и приложению, а не привязывать к офису и сети. Такой поворот меняет многое: архитектуру доступа, модель внедрения, закупку (CAPEX → OPEX), требования к партнёрам и язык, которым ИБ объясняет ценность бизнесу.

Три темы, которые разберём

В этой статье мы разложим кейс на три слоя:

• облачный подход к безопасности как продуктовая основа;
• Zero Trust без маркетингового тумана: что реально меняется в доступе;
• дистрибуция и партнёрский канал как способ масштабировать продажи в крупных компаниях.

Для кого эта статья

Материал ориентирован на ИТ‑руководителей, CISO и команды ИБ, специалистов по закупкам и партнёров/интеграторов. Цель — дать практичную рамку: какие решения стоят за ростом Zscaler и какие вопросы полезно задать, планируя свою стратегию защиты доступа.

Проблема, которую «периметр» перестал решать

Ещё недавно корпоративная безопасность строилась вокруг простой идеи: «всё важное — внутри офиса и дата‑центра». Трафик сотрудников шёл в штаб‑квартиру, там стояли шлюзы, прокси и системы фильтрации, а наружу выпускали только «проверенное». Это работало, пока приложения и данные действительно жили внутри.

Как изменился трафик

С ростом SaaS (почта, CRM, документооборот), удалённой работы и мобильности маршруты перевернулись. Сотрудник в командировке или дома чаще обращается не к серверу в офисе, а к облачному сервису. Если при этом компания заставляет «гнать всё через периметр», появляется эффект «шланга через офис»: лишние задержки, перегруз каналов, ухудшение качества видеосвязи и постоянные жалобы бизнеса.

Почему «всё через офис» стало тормозом

Периметр перестал быть единым местом контроля. Десятки филиалов, тысячи устройств, подрядчики и временные доступы — всё это плохо стыкуется с VPN и классической моделью доверия «внутри — можно, снаружи — нельзя», когда пользователь и приложение постоянно меняют локацию.

Какие риски усилились

Проблемы стали не только в скорости, но и в рисках:

• фишинг и вредоносные ссылки в вебе и почте;
• компрометация учётных записей и «тихое» перемещение злоумышленника по внутренней сети;
• утечки данных в облачные хранилища и сторонние приложения.

Почему «добавим ещё коробку» не помогает

Логика «поставим ещё один appliance» упирается в масштабы: оборудование нужно закупать, обновлять, настраивать в каждом узле, а политики начинают расходиться между офисами. В итоге безопасность становится лоскутной — дорогой, сложной и при этом не всегда эффективной.

Облачная безопасность: идея, которая изменила рынок

Облачная безопасность как сервис — это когда «точка контроля» находится не в вашей серверной и не в наборе коробок на периметре, а в облачной платформе провайдера. Пользователь подключается к ближайшему узлу сервиса, трафик проверяется по единым правилам, и только затем получает доступ к интернету или корпоративным приложениям.

Простыми словами: что именно становится «облачным»

В классической модели компания покупает устройства (шлюзы, прокси, VPN, фильтры), ставит их в нескольких дата‑центрах, обновляет и масштабирует сама. В облачной модели вы покупаете не железо, а функцию: безопасный доступ, инспекцию трафика, политики, отчётность — всё это работает как единая услуга.

Чем архитектура отличается от набора локальных устройств

Ключевое отличие не в том, где стоит прокси, а в том, как устроены управление и масштабирование:

• Единая политика: правила задаются один раз и действуют для филиалов, удалённых сотрудников и облачных приложений.
• Масштабирование по спросу: рост нагрузки не требует срочно закупать и устанавливать новые «коробки».
• Обновления без проектов: сигнатуры, модели детектирования и новые функции включаются платформой, а не через долгие окна обслуживания.

Именно это стало рыночным переломом: безопасность перестала быть цепочкой разрозненных устройств, которые сложно синхронизировать, и стала сервисом, который проще расширять на новые регионы и сценарии работы.

Типовые вопросы заказчиков: задержки, контроль, соответствие

1. Задержки. Обычно опасаются, что облачная проверка «замедлит интернет». На практике решают география узлов (ближайшая точка присутствия) и корректная маршрутизация.

2. Контроль. Важно понимать, кто управляет политиками и как выглядит аудит: какие журналы доступны, как настраиваются роли, как быстро можно расследовать инцидент.

3. Соответствие требованиям. Заказчики спрашивают про хранение логов, сертификации, шифрование и разделение данных между клиентами. Хороший сервис заранее даёт понятные ответы и документы, чтобы безопасность не упиралась в бюрократию.

Zero Trust без жаргона: что это и чем не является

Zero Trust часто звучит как модный ярлык, но по сути это простой принцип управления доступом: никому не доверять по умолчанию и проверять всегда. Не «поверить один раз при входе», а постоянно подтверждать, что запрос уместен и безопасен.

Что такое Zero Trust на практике

В классическом подходе безопасность строилась вокруг идеи «внутри сети — свои». Zero Trust меняет акцент: важен не факт, что пользователь «внутри», а может ли он прямо сейчас получить доступ к конкретному ресурсу.

Здесь полезно разделять понятия:

• «Доступ» — строго ограниченное разрешение на конкретное действие (например, открыть определённое приложение).
• «Нахождение внутри сети» — широкое присутствие в среде, которое исторически тянет за собой лишние возможности.

Zero Trust стремится заменить второе первым: доступ выдаётся точечно, по правилам.

Типовые элементы: из чего состоит модель

Чтобы «проверять всегда», нужна связка нескольких вещей:

• Идентичность: кто делает запрос (пользователь, устройство, сервисная учётная запись).
• Контекст: откуда и как подключаются (местоположение, состояние устройства, тип сети, время, риск).
• Политика: понятные правила «кому/чему/куда можно» — желательно в терминах бизнеса.
• Непрерывная проверка: пересмотр доверия по ходу сессии, а не только на входе.

Что Zero Trust не означает

Это не «один продукт», не магическая кнопка и не синоним VPN‑замены. Также это не тотальный запрет всего: цель — дать доступ быстро, но минимально необходимый и контролируемый.

Частые ошибки внедрения

Самая опасная ловушка — формально объявить Zero Trust, но оставить старые привычки:

• слишком широкие права «на всякий случай»;
• «вечные» исключения для VIP‑пользователей, подсетей или приложений;
• редкий пересмотр политик и отсутствие контроля состояния устройств.

Zero Trust работает, когда правила становятся конкретнее, а исключения — временными, измеримыми и объяснимыми.

От безопасного доступа к платформе: эволюция продукта

Изначальная ставка на веб‑трафик и облачные приложения выглядела не «модной», а прагматичной: у сотрудников и подрядчиков всё больше рабочих сценариев уходило из корпоративной сети в браузер и SaaS. Там, где раньше хватало фильтрации на выходе в интернет, появились десятки внешних сервисов, прямые подключения из дома и мобильных сетей, а также постоянные попытки обойти правила.

Прокси/шлюз как единая точка контроля

В этой логике безопасный веб‑шлюз и прокси становятся не просто «фильтром сайтов». Это точка, где можно централизованно применять политику и проводить инспекцию трафика: кто именно подключается, к какому приложению, что именно передаётся, нет ли вредоносного содержимого или утечек данных.

Ценность в том, что правила живут не на разрозненных устройствах по офисам, а в одном месте — и одинаково работают для пользователя в штаб‑квартире, в командировке или дома.

От «веб‑шлюза» к платформе доступа

Дальше подход закономерно расширился: если контроль уже вынесен ближе к пользователю и интернету, его можно применить не только к веб‑сайтам, но и к доступу к внутренним системам, частным приложениям, API и корпоративным сервисам.

Так продуктовая идея эволюционирует от «защиты выхода в интернет» к платформе безопасного доступа: единые политики, единая видимость, единый опыт подключения — независимо от того, где находится ресурс и как к нему приходит пользователь.

Честные ограничения и риски

У облачного подхода есть уязвимые места, о которых важно говорить заранее. Во‑первых, зависимость от качества связи: если канал нестабилен, страдает пользовательский опыт и иногда приходится продумывать резервные маршруты.

Во‑вторых, интеграции: реальная ценность платформы раскрывается, когда она связана с вашим управлением идентификациями, каталогами пользователей, журналированием и процессами реагирования. Недооценка объёма интеграционных работ — частая причина разочарования (обычно не в продукте, а во внедрении).

Как облачный подход упрощает ИБ для крупных компаний

Крупным компаниям сложнее всего поддерживать безопасность «равномерно»: офисы, филиалы, подрядчики, гибридная инфраструктура и тысячи устройств постоянно меняют картину. Облачная модель безопасности решает это не отдельными коробками в каждом месте, а единым сервисом, который видит пользователей и трафик там, где они реально работают.

Единая политика для пользователей и устройств

Ключевая ценность для энтерпрайза — единая политика, которая применяется одинаково к сотруднику в штаб‑квартире, в командировке или на удалёнке. Правила привязываются не к «месту в сети», а к идентичности и контексту: кто пользователь, какое устройство, какой риск, к какому приложению идёт запрос.

Это снижает хаос «локальных исключений», когда филиалы живут по своим правилам, а безопасность превращается в набор разрозненных договорённостей.

Упрощение архитектуры и влияние на операционные затраты

Когда безопасность доставляется как облачная услуга, отпадает необходимость проектировать и поддерживать сложные цепочки: VPN‑концентраторы, региональные прокси, отдельные точки выхода в интернет, разный стек в каждом офисе.

Практический эффект для операционных затрат:

• меньше железа и обновлений на местах;
• меньше ручной настройки и «пожарных» изменений;
• быстрее подключение нового филиала или компании после M&A;
• проще масштабирование под пиковые нагрузки.

Консолидация инструментов: почему это важно ИТ‑директорам

Консолидация — это когда несколько функций (например, безопасный веб‑шлюз, контроль доступа к SaaS, сегментация доступа) управляются из одной консоли и живут в одной политике. Для ИТ‑директора это означает меньше поставщиков, меньше интеграций, меньше «стыков», где теряются логи и ответственность.

Типовые сценарии, где это заметно

Доступ к SaaS: сотрудник получает доступ по принципу наименьших привилегий, а политика одинаково применима из офиса и из дома.

Интернет‑доступ филиалов: трафик не нужно «тащить» в центральный дата‑центр ради проверки — политика применяется ближе к пользователю.

Удалённые сотрудники: вместо перегруженного VPN — контролируемый доступ к конкретным приложениям, с учётом устройства и риска.

Дистрибуция и партнёры: как строится масштаб продаж

Продавать ИБ‑платформу напрямую почти всегда дорого: длинные циклы согласований, пилоты, безопасность как «нефункциональное требование» и десятки стейкхолдеров — от ИБ до сетевиков и закупок. У вендора быстро появляется потолок: чтобы закрывать больше сделок, нужно пропорционально наращивать пресейл, архитекторов, поддержку и ресурсы на внедрение.

Кто входит в канал и почему это важно

Канал обычно собирается из нескольких типов партнёров, и каждый закрывает свой кусок пути клиента:

• Системные интеграторы — берут на себя обследование, дизайн целевой архитектуры и интеграции (SSO, прокси, DLP, SIEM).
• MSP/MSSP — превращают продукт в услугу: мониторинг, управление политиками, реагирование.
• Реселлеры и дистрибьюторы — помогают с закупочной процедурой, финансированием, доступностью лицензий и расширением присутствия в регионах.

Как партнёры снижают барьеры внедрения

Для крупных компаний самое сложное — не покупка, а переход: миграция трафика, разделение пользователей по политикам, настройка исключений, обучение и поддержка. Партнёр с опытом делает это предсказуемым: предлагает типовые сценарии, план миграции «волнами», берёт на себя коммуникации между ИБ и ИТ и помогает дойти до измеримых результатов (например, снижение инцидентов, ускорение доступа).

Риски канала: что нужно контролировать

Канал может и навредить, если не управлять качеством:

• Качество услуг: «кривое» внедрение часто выглядит как проблема продукта.
• Конкуренция внутри сети: несколько партнёров в одной сделке создают конфликт и демпинг.
• Контроль ценности: если партнёр продаёт только скидку, клиент не понимает, за что платит — и легко уходит при продлении.

Сильные вендоры строят партнёрскую программу так, чтобы партнёрам было выгодно продавать результат, а не только лицензии: обучение, сертификации, совместные кейсы и прозрачные правила регистрации сделок.

Go-to-market: почему сообщение важнее терминов

Большинство корпоративных закупок ИБ «ломается» не на технологии, а на коммуникации. Когда команда продавца начинает разговор со слов Zero Trust, SASE или «безопасный веб‑шлюз», часть аудитории слышит маркетинг и выключается. Работает обратный подход: сначала — конкретная боль и сценарий, потом — как облачная безопасность закрывает его на практике.

Ценность для разных ролей: один продукт — разные «выигрыши»

В Go‑to‑market важно упаковать одно и то же решение в разные обещания результата:

• ИБ (CISO/служба безопасности): единая политика доступа, меньше «слепых зон», контроль теневых обходов.
• Сеть/инфраструктура: проще маршрутизация удалённого доступа, меньше точек отказа и ручных настроек.
• Финансы: предсказуемые затраты, сокращение поддержки разрозненных средств, понятная экономия на эксплуатации.
• Бизнес‑владельцы: быстрее запуск новых филиалов/подрядчиков, меньше простоев из‑за инцидентов.

Важно говорить не «мы про Zero Trust», а «мы убираем неуправляемый доступ к приложениям и данным — даже когда сотрудники вне офиса».

Быстрые пилоты и метрики, которые можно защитить на комитете

Пилот должен отвечать на вопрос «что изменится через 2–4 недели» и иметь измеримые показатели. Хорошая практика — заранее согласовать, какие данные считаются успехом:

• снижение обходов и «серых» путей доступа (например, прямой выход в интернет мимо политики);
• консолидация: сколько правил и систем политики удалось свести в одну;
• время реакции: обнаружение подозрительного поведения и блокировка (MTTD/MTTR);
• рост видимости: доля пользователей/приложений, по которым есть прозрачная телеметрия.

Кстати, на этом этапе часто не хватает скорости в подготовке артефактов: описаний сценариев, матриц доступа, планов пилота, чек‑листов интеграций. Для такой «упаковки изменений» удобно использовать TakProsto.AI: в режиме чата быстро собрать структуру пилота, согласовать формулировки политик и подготовить черновики документов для ИБ/ИТ/закупок — с возможностью вернуться к снапшотам и откатиться к предыдущей версии.

Как избегать «страшилок»

Страх продаёт плохо в энтерпрайзе: он вызывает спор о вероятностях. Лучше продавать через сценарии: безопасный доступ подрядчиков, защита SaaS, контроль BYOD, сегментация доступа к критичным приложениям. Термины (Zero Trust, SASE) остаются в презентации, но не становятся главным аргументом — им становится измеримый результат.

Переход к Zero Trust: типовой путь внедрения

Переход к Zero Trust редко бывает «большим переключателем». Чаще это серия небольших, управляемых шагов, которые постепенно заменяют привычный периметр (VPN и сетевые исключения) на доступ по идентичности, контексту и политике.

Почему опасна «смешанная» среда

На практике многие компании застревают в гибридном состоянии: старые VPN остаются для «сложных» пользователей, параллельно появляются облачные политики, а для критичных систем выдаются исключения. Такая смесь повышает риск по трём причинам.

Во‑первых, растёт количество путей доступа: один и тот же сервис можно открыть через VPN, через прокси‑политику и через прямой интернет — контролировать это сложно.

Во‑вторых, исключения становятся «тихими дырами»: они редко пересматриваются, но активно наследуются при изменениях.

В‑третьих, пользователи получают разный опыт доступа, что провоцирует обходные решения и сопротивление изменениям.

Пошаговый план внедрения

1. Инвентаризация: приложения, типы пользователей, устройства, маршруты трафика, текущие правила и исключения.

2. Сегментация: разделите доступ по группам (офисные/удалённые, подрядчики, привилегированные роли) и по чувствительности приложений.

3. Политики доступа: определите минимально необходимый доступ (least privilege) с учётом роли, состояния устройства и уровня риска.

4. Миграция трафика: переносите потоки постепенно — начните с веб‑доступа и некритичных SaaS, затем внутренние приложения, и только потом «тяжёлые» случаи.

Как внедрять, не ломая работу пользователей

Лучший подход — пилоты на добровольцах и «тихой» группе, измерение задержек и частоты запросов на доступ, а затем расширение. Важно заранее подготовить поддержку: понятные инструкции, быстрый процесс выдачи прав и режим отката для критичных задач.

Типовые точки интеграции

Чтобы политики работали стабильно, обычно подключают:

• IdP/SSO для единой идентичности и многофакторной аутентификации;
• EDR для сигнала о компрометации или подозрительной активности на устройстве;
• MDM для проверки соответствия требованиям (шифрование, пароль, версия ОС);
• SIEM для централизованных логов, корреляции и расследований.

Так Zero Trust становится не «проектом безопасности», а управляемым процессом: понятные правила, постепенная миграция и измеримый результат.

Критерии выбора: что проверить, прежде чем покупать

Покупка облачной платформы безопасности — это не «выбрать бренд», а убедиться, что решение закрывает ваши реальные сценарии доступа и при этом не усложняет жизнь пользователям. Ниже — практичный набор проверок, который помогает вести переговоры и проводить пилот без самообмана.

1) Покрытие сценариев и границы ответственности

Сначала перечислите, что именно вы защищаете: доступ в интернет, доступ к SaaS, доступ к внутренним приложениям, удалённые сотрудники, подрядчики, филиалы, BYOD.

Попросите поставщика показать, как каждый сценарий реализуется «из коробки» и что потребует доработок: агенты, прокси‑настройки, коннекторы, изменения в DNS, исключения для приложений.

Отдельно проверьте поддержку: SLA, часы работы, язык, выделенный инженер, скорость эскалаций. В крупных внедрениях качество поддержки часто важнее списка функций.

2) Интеграции, которые реально понадобятся

Составьте список систем, с которыми решение должно дружить: IdP/SSO, MFA, EDR, SIEM/SOAR, DLP, MDM, сервис‑деск.

Важно не «галочка в презентации», а уровень интеграции: какие атрибуты пользователя доступны для политик, как передаются события, насколько удобно расследование.

3) Приватность, логи и соответствие требованиям

Задайте прямые вопросы:

• Где физически хранятся логи и метаданные? Можно ли выбрать регион?
• Что именно логируется по умолчанию (URL, DNS, содержимое, идентификаторы)?
• Как устроены сроки хранения, удаление, экспорт и доступ администраторов?
• Какие сертификаты/аудиты есть, и распространяются ли они на ваш регион и тип данных?

4) Пилот: производительность и опыт пользователей

Пилотируйте на «сложных» группах: удалённые сотрудники, приложения с чувствительной задержкой, тяжёлые SaaS.

Согласуйте метрики заранее: задержка, скорость открытия страниц, процент ошибок, стабильность агента, количество исключений, нагрузка на службу поддержки.

5) Честное сравнение: требования, тесты, TCO и риски миграции

Сравнивайте решения по единому набору требований и одинаковым тестам. В TCO учитывайте не только лицензии, но и эксплуатацию: время админов, поддержку пользователей, стоимость трафика/коннекторов, обучение.

И главное — оцените риски миграции: сколько политик переносится автоматически, как откатиться назад, что будет с видимостью в SIEM, и сколько времени займёт переход по этапам. Если поставщик не готов зафиксировать план пилота и критерии успеха письменно, это сигнал остановиться и уточнить ожидания.

Ограничения и риски: где можно ошибиться

Переход на облачную модель безопасности и Zero Trust часто воспринимают как «включил сервис — и всё защищено». Это опасная иллюзия: облако меняет инструменты и архитектуру, но качество защиты по‑прежнему определяется настройками, дисциплиной и зрелостью процессов.

Почему «облако» не равно автоматической безопасности

Облачный сервис может убрать часть рутины (железо, обновления, масштабирование), но не принимает за вас решения о том, кому, что и при каких условиях разрешать. Ошибки в модели доступа в облаке обычно распространяются быстрее: политика применяется централизованно — и так же централизованно может «сломать» безопасность или бизнес‑процессы.

Главные технические риски: политики, привилегии, идентификация

Самые частые промахи связаны не с «дырами», а с логикой доступа:

• Неправильные политики: слишком широкие правила «для удобства», отсутствие разделения по приложениям/группам, исключения, которые стали нормой.
• Чрезмерные привилегии: доступ «на всякий случай», общие учётки, редкая ревизия прав. В Zero Trust особенно важно регулярно проверять, что права соответствуют роли.
• Слабая идентификация: если удостоверение личности ненадёжно, Zero Trust превращается в декорацию. Риски усиливаются при отсутствии многофакторной аутентификации, плохой гигиене устройств и слабом контроле сессий.

Роль обучения и процессов

Технология не заменяет операционку. Нужны понятные правила:

• как оформляются и пересматриваются исключения;
• как проходят изменения политик (тестирование, откат, «двойной контроль»);
• как обрабатываются инциденты (кто принимает решения, какие логи и сигналы обязательны, как быстро отключать доступ точечно).

Баланс безопасности и удобства

Слишком жёсткие ограничения подталкивают команды к обходным путям: личные почты, теневые файлообменники, «временные» админские права. Рабочая практика — вводить контроль поэтапно, измерять влияние на пользователей и договариваться о допустимом уровне риска — иначе вы получите не Zero Trust, а недоверие к ИБ.

Выводы: уроки Zscaler для вашей стратегии ИБ

История Zscaler ценна не брендом и не набором модных терминов, а тем, как последовательно решалась одна и та же бизнес‑проблема: безопасный доступ к приложениям и данным при постоянных изменениях (облака, удалённая работа, подрядчики, слияния).

Практические выводы, применимые почти в любой организации

Главный урок: перенос «точки контроля» ближе к пользователю и приложению часто даёт больший эффект, чем бесконечное укрепление периметра. Второй урок: Zero Trust — это не продукт, а набор правил доступа, которые можно внедрять поэтапно, измеряя результат. Третий: успех зависит от операционной модели — кто владеет политиками, кто отвечает за исключения и как быстро меняются правила.

С чего начать уже на этой неделе: 5 первых шагов

1. Составьте список критичных приложений и потоков данных (хотя бы топ‑10) и укажите, кто и откуда к ним ходит.

2. Опишите минимальные требования доступа: устройство, контекст, роль, MFA, география.

3. Выберите один пилотный сценарий (например, доступ подрядчиков или офис→SaaS) и зафиксируйте критерии успеха.

4. Наведите порядок в идентификациях: группы, роли, жизненный цикл учёток, процесс выдачи/отзыва.

5. Подготовьте план отказа от устаревших подходов: какие VPN/пробросы портов/исключения должны исчезнуть первыми и почему.

Как измерять прогресс

Смотрите на три метрики: (1) покрытие политиками — доля пользователей и приложений, которые проходят через единые правила; (2) качество доступа — сколько запросов обрабатывается по «стандартному пути» без ручных исключений; (3) снижение зависимости от наследия — сколько сервисов перестало требовать постоянного VPN и статических сетевых допусков.

Вопросы для обсуждения с руководством и партнёрами

Какие риски для бизнеса мы закрываем в первую очередь? Где граница приемлемого трения для пользователей? Кто утверждает политики и исключения, и за какой срок? Как будет организована поддержка и реагирование на инциденты при новой модели доступа? Какие этапы миграции и критерии «готово» мы фиксируем в контракте и проектном плане?