"Критикуя наивный Zero Trust, забываешь, что его главный противник — не пользователь, а тот, кто продаёт тебе безопасность"
Настоящая проблема Zero Trust не в сложности его внедрения, а в нежелании признать, что слепая вера в вендоров противоречит самой его сути. Мы выстраиваем тотальное недоверие к своим сотрудникам и устройствам, но без вопросов принимаем «чёрные ящики» от поставщиков, внутри которых могут быть любые учётные записи, открытые порты или скрытый майнер. Безопасность не может быть избирательной.
Что сломалось в старой модели «крепости и рва»
Модель защиты по периметру строилась на логике фортификации: внешние стены — неприступны, а внутри — безопасно. Но эта архитектура игнорировала, что угрозы давно стали перемещаться легитимными маршрутами. Компрометация одной учётной записи — даже рядового сотрудника — позволяла злоумышленнику свободно перемещаться по сети, словно по коридорам открытого здания, потому что внутренние перегородки не проверяли его права повторно.
Внедрение облачных сервисов, удалённая работа и корпоративные BYOD-политики окончательно стёрли понятие границы. Трафик к критическим системам идёт через публичные сети, а сами активы могут находиться в разных юрисдикциях. Сетевая сегментация, привязанная к физическим свитчам и IP-подсетям, стала нефункциональной — она не может динамически адаптироваться под виртуальные машины и контейнеры, которые создаются и удаляются за минуты. Защита превратилась в ритуал, не связанный с реальными рисками.
Главный уязвимостью оставалось избыточное доверие после успешного входа. Права доступа выдавались надолго и по принципу «про запас». Администратор получал права на всё, чтобы быстро решить инцидент. Разработчик — доступ к продакшену, чтобы оперативно развернуть исправление. Когда такие привилегии со временем множились и не отзывались, возникала внутренняя «тень», которая становилась идеальной мишенью для атак. Итогом становились инциденты, когда злоумышленник месяцами использовал забытые учётные записи сервисов или API-ключи.
Но фундаментальнее была ошибка восприятия: считалось, что главная угроза — снаружи. Это позволяло закрывать глаза на риски внутри самой инфраструктуры, в том числе исходящие от доверенного стороннего ПО и оборудования. Пока все усилия тратились на отражение внешних атак, в системе могли годами работать компоненты с известными уязвимостями или скрытым функционалом, поставленные «проверенными» партнёрами. Это и было слепым доверием в чистом виде.
Zero Trust: принципы вместо слепой вери
Я не доверяю ни одному запросу, даже если он приходит из доверенной зоны. Каждый запрос на доступ проходит многофакторную проверку, где пароль — только один из элементов. Контекст запроса анализируется в реальном времени: насколько поведение пользователя или системы соответствует обычным паттернам, не отклоняется ли геолокация, соответствует ли устройство политикам безопасности. Если контекст вызывает вопросы — например, попытка доступа к финансовой системе в нерабочее время с нового IP — доступ не блокируется сразу, но переводится в режим повышенной проверки с запросом дополнительной аутентификации.
Права выдаются по принципу минимальной достаточности и на строго ограниченное время. Никаких постоянных административных доступов «на всякий случай». Если специалисту нужно выполнить задачу в продакшен-среде, он запрашивает временный доступ через автоматизированный портал. Система проверяет необходимость, согласовывает его с ответственным и выдаёт права ровно на срок выполнения задачи, после чего автоматически их отзывает. Это резко сокращает «время жизни» привилегий, доступных для компрометации.
Архитектура проектируется исходя из предположения, что сеть уже скомпрометирована. Это меняет фокус с «не пустить» на «ограничить ущерб». Шифрование применяется ко всем каналам связи, включая трафик внутри одного сегмента. Рабочие нагрузки изолируются друг от друга с помощью микросегментации, так что компрометация одного сервиса не означает автоматический доступ к соседним. Данные защищаются на уровне приложения с помощью систем предотвращения утечек. Таким образом, даже получив начальный доступ, злоумышленник оказывается в лабиринте, где каждый следующий шаг требует новой проверки.
В основе лежит постоянный мониторинг и анализ всех действий. Собираются и анализируются логи аутентификаций, сетевые потоки, действия пользователей и систем. Это позволяет строить поведенческие профили и выявлять аномалии, которые не являются прямыми атаками, но указывают на потенциальный риск. Например, массовая выгрузка данных, к которым сотрудник раньше не обращался, или нехарактерные сетевые соединения между сервисами.
Как выглядит доступ в Zero Trust на практике
Доступ предоставляется не к сети, а напрямую к конкретному приложению или сервису. Пользователь через браузер или клиентское приложение обращается к прокси-шлюзу. Этот шлюз является единственной точкой входа и выполняет все проверки: аутентификацию пользователя, оценку состояния и соответствия устройства, анализ контекста сессии. После успешной проверки устанавливается зашифрованное соединение непосредственно с целевым приложением, минуя прямое подключение к внутренней сети. Пользователь не видит и не может сканировать другие ресурсы. Доверие — динамическая величина, а не статичный статус. Сессия постоянно переоценивается. Если во время работы система фиксирует подозрительную активность — например, попытку доступа к новому типу ресурсов, скачивание большого массива данных или изменение местоположения, — она может потребовать повторной аутентификации, временно ограничить функциональность или уведомить администратора. Сессия, открытая утром с рабочего ноутбука, не гарантирует неограниченного доверия вечером.
Устройство становится полноправным субъектом безопасности. Его состояние — версия ОС, наличие шифрования диска, активность антивируса, статус в системе управления мобильными устройствами — напрямую влияет на уровень доступа. Устройство, не соответствующее политикам, либо не получает доступ к чувствительным данным вовсе, либо получает его в сильно ограниченном режиме. Это правило едино для корпоративных и личных устройств, используемых для работы.
Защита данных не заканчивается на их передаче. Используются такие технологии, как защита от утечек, которые контролируют действия с информацией уже после получения доступа: запрещают копирование в буфер обмена, запись на съёмные носители, печать без разрешения. Конфиденциальные документы могут открываться только в защищённых просмотрщиках без возможности сохранения. Таким образом, даже если злоумышленник получил доступ к сессии, извлечь ценную информацию оказывается крайне сложно.
Без чего Zero Trust останется декларацией
Единая система управления идентификацией и доступом (IAM), это фундамент. Все субъекты — люди, сервисы, устройства, API — должны быть зарегистрированы в едином каталоге с чётко определёнными ролями. Без этого невозможно централизованно управлять политиками доступа, обеспечивать своевременный их отзыв при изменении статуса и строить контекст для принятия решений. Ручное управление правами в условиях тысяч сущностей обречено на провал.
Микросегментация реализуется не на сетевом уровне маршрутизаторов, а на уровне политик, привязанных к рабочим нагрузкам. Политики определяют, какой микросервис к какому может обращаться, по какому протоколу и порту, независимо от того, в одном они дата-центре или в разных облаках. Это создаёт «клеточную» изоляцию, которая останавливает горизонтальное перемещение внутри инфраструктуры.
Автоматизация жизненно необходима. Политики доступа должны настраиваться и применяться автоматически на основе тегов, ролей и данных систем мониторинга. Например, при создании новой виртуальной машины с тегом «БД_финансы» к ней автоматически применяется строгий набор правил микросегментации и политик доступа. Ручная настройка для каждого нового ресурса делает модель неработоспособной.
Полная видимость (Visibility), это условие, а не опция. Необходимо собирать, агрегировать и анализировать данные со всех компонентов: журналы аутентификации, сетевые потоки, действия пользователей в приложениях, метрики устройств. Без целостной картины невозможно построить точные поведенческие профили и выявлять аномалии. Zero Trust вслепую, это оксюморон.
Чего не хватает для полной картины: скрытые элементы
Самая большая брешь в Zero Trust, это то, что остаётся вне его поля зрения. Часто это доверенное стороннее ПО: оборудование, предустановленное на серверах, фирменные библиотеки, закрытые API вендоров, сервисные аккаунты, созданные для интеграции. Они получают неявный, ничем не ограниченный доступ, потому что считаются частью «доверенной» поставки. Первый шаг — полная и постоянная инвентаризация. Необходимо автоматически обнаруживать и каталогизировать все активы: не только виртуальные машины и контейнеры, но и устройства IoT, сетевое оборудование, учётные записи сервисов и API-ключи. Особое внимание — к «теневому IT» и компонентам, поставленным вендорами. Без полного списка субъектов выстраивать политики доверия бессмысленно.
Контекст для принятия решений должен обогащаться данными из внешних систем. Интеграция IAM с кадровой системой позволяет мгновенно отключать доступ уволенным сотрудникам. Подключение к SOC и системам киберразведки позволяет учитывать актуальные данные об угрозах: если IP-адрес устройства внесён в чёрный список, доступ должен быть заблокирован или ужесточён автоматически.
Стоит обратить внимание на DNS как на источник контекста. Анализ DNS-запросов позволяет обнаруживать аномалии на ранней стадии — например, когда устройство пытается связаться с доменами, связанными с ботнетами или фишингом, ещё до установления вредоносного соединения.
Если система Zero Trust создаёт излишние сложности для легитимных пользователей, они начнут её обходить. Поэтому пользовательский опыт критически важен. Процессы аутентификации должны быть быстрыми и понятными, а в случае отказа в доступе система должна давать внятное объяснение причин. Без баланса между безопасностью и удобством модель обречена на саботаж изнутри.
Почему мы слепо доверяем вендорам, требуя Zero Trust от пользователей
Здесь возникает главное противоречие. Организация может выстраивать сложнейшую модель Zero Trust для сотрудников, но при этом безоговорочно доверять вендорам, чьё ПО имеет прямой доступ к ядру инфраструктуры. Причины этого носят не технический, а организационный и психологический характер.
Перекладывание ответственности. Заключая контракт с крупным вендором, компания формально делегирует ему часть ответственности за безопасность. Создаётся иллю>зия, что риски принял на себя поставщик. Гораздо проще требовать MFA от бухгалтера, чем проводить глубокий аудит кода или конфигурации поставляемого брандмауэра.
Техническая закрытость. Многие решения поставляются как «чёрные ящики». Исходный код недоступен, внутренняя архитектура не документирована, а модификация конфигураций может привести к потере поддержки. Проверить, не оставил ли вендор скрытые учётные записи для технической поддержки, становится практически невозможно. Недоверие в таких условиях требует огромных усилий.
Стоимость смены вендора (Vendor Lock-in). Внедрение сложной инфраструктурной системы вроде ERP или промышленного SCADA связывает компанию с поставщиком на годы. Требования к безопасности собственных изменений в таком ПО часто запрещены лицензией или технически нереализуемы. Организация попадает в зависимость и вынуждена принимать правила игры вендора, включая его подход к безопасности.
Культурный нарратив о «надёжности». Крупные, давно существующие на рынке вендоры создают вокруг себя ореол безусловной надёжности. Их имена ассоциируются с безопасностью, и подвергать сомнению их продукты начинает казаться почти ересью. В то же время собственные сотрудники воспринимаются как самый ненадёжный элемент, что подпитывает парадокс.
Управленческое непонимание. Для руководства, далёкого от технических деталей, вендорское решение, это «галочка» в чек-листе выполненных работ. Факт покупки лицензии у известного поставщика сам по себе считается мерой безопасности. Глубокий аудит, требующий специальных компетенций и времени, часто выпадает из поля зрения, пока не случится инцидент.
Таким образом, требование Zero Trust к пользователям, это относительно простой, контролируемый процесс, который можно измерить и автоматизировать. А применение тех же принципов к вендорам сталкивается с юридическими, финансовыми, техническими и культурными барьерами, которые часто кажутся непреодолимыми. В результате модель Zero Trust остаётся половинчатой, оставляя огромные бреши в самом основании инфраструктуры.
С чего начать путь, если кажется, что всё сложно
Начинать нужно не со всей инфраструктуры, а с одного критически важного актива — «короны». Это система, остановка или утечка данных из которой нанесёт максимальный ущерб. Вокруг этого актива и строится первый, максимально жёсткий контур Zero Trust. Определяются все субъекты, которые к нему обращаются (люди, сервисы), внедряется строгая аутентификация, микросегментация, шифрование и мониторинг. Это даёт быстрый и измеримый результат.
Выберите один управляемый сценарий для пилота. Например, доступ к системе электронного документооборота для удалённых юристов. Внедрите для этого сценария полный цикл: прокси-доступ, проверку устройства, политики минимальных прав, мониторинг сессий. Успех этого пилота станет доказательством концепции и образцом для дальнейшего масштабирования.
Помните, что Zero Trust должен распространяться и на нечеловеческие сущности. Сервисные аккаунты, API-ключи, боты — всё это должно быть зарегистрировано в IAM, их доступ должен быть ограничен по времени и объёму, а их действия — мониториться. Часто именно они становятся целью атак из-за слабого контроля.
Внедряйте Zero Trust как эволюцию, а не как «зелёное поле». Используйте возможности существующих систем: настройте политики Conditional Access в IAM, используйте возможности микросегментации в вашем гипервизоре или облачной платформе, подключите прокси для доступа к веб-приложениям. Постепенное ужесточение политик снижает риски и сопротивление.
И главное — расширяйте область недоверия. После настройки базовых процессов для пользователей поднимите вопрос о вендорах. Внесите в процедуры закупок требования по безопасности: обязательный аудит конфигураций, запрет на скрытые учётные записи, предоставление документации по архитектуре. Начинайте с новых контрактов, постепенно пересматривая отношения с существующими поставщиками. Без этого шага Zero Trust так и останется красив