Старая модель безопасности выстраивала надёжный периметр и доверяла всему, что было внутри. В мире облаков, удалённой работы и BYOD эта сделка перестала работать — периметра больше нет. Сотрудник авторизуется по wi-fi из кафе, сервис обращается к сервису через глобальный интернет, а критичные данные лежат в чужих дата-центрах. Как только злоумышленник попадает «внутрь», он движется по сети почти беспрепятственно.
Ответ индустрии — модель Zero Trust, построенная на принципе «никогда не доверяй, всегда проверяй». Эта статья — о том, как пройти путь правильно: выстроить доступ по принципам нулевого доверия и при этом не парализовать рабочие процессы компании.
Что такое Zero Trust — и чем он точно не является
Главное заблуждение, с которого начинаются почти все провальные проекты: представление о Zero Trust как о продукте, который можно купить и пользоваться «из коробки». Это не так. Zero Trust — это стратегия и подход к архитектуре, а не конкретный софт от одного вендора.
Суть подхода в том, что доверие никогда не выдаётся неявно. Каждый запрос на доступ — от пользователя, устройства или сервиса — рассматривается как потенциально враждебный, независимо от того, откуда он пришёл: из внутренней сети или извне. Система проверяет личность запрашивающего и состояние его устройства (актуальность ОС, шифрование диска, отсутствие известных угроз), сверяет запрос с политиками и только потом выдаёт доступ — причём минимально необходимый и часто на ограниченное время.
Из этого вытекают ключевые выгоды: сокращается поверхность атаки, блокируется горизонтальное перемещение злоумышленника внутри сети, появляется детальная видимость того, кто и к чему обращается.
Архитектура: из чего собирается Zero Trust в облаке
Каркасом для большинства внедрений служит стандарт NIST SP 800-207. Он выделяет два ядровых компонента:
-
Policy Decision Point (PDP) — «мозг» системы. Внутри он делится на две части: Policy Engine, который на основании действующих политик выносит само решение «доступ или отказ», и Policy Administrator, который это решение исполняет — настраивает канал связи и выдаёт сессионные учётные данные.
-
Policy Enforcement Point (PEP) — «руки» в плоскости данных. Фактически пропускает или блокирует трафик по команде PDP.
Отдельно стандарт выделяет «зону неявного доверия» — область, где компоненты общаются до прохождения проверки. Задача архитектора — свести эту зону к минимуму.
На практике эти абстракции собираются из конкретных механизмов: централизованного управления идентичностями (IdP) с обязательной многофакторной аутентификацией (MFA), Zero Trust Network Access (ZTNA), микросегментации сети и взаимной аутентификации сервисов по mTLS.
Отдельно стоит остановиться на сетевом контроле — он в Zero Trust двухуровневый. Микросегментация отвечает за «горизонтальный» трафик между рабочими нагрузками (east-west): сеть дробится на изолированные зоны со своими правилами, чтобы угроза, проникнув в одну, не расползлась по остальным. В экосистеме VMware NSX это задача распределённого межсетевого экрана (Distributed Firewall), а на уровне сервисов похожую роль играет Istio, управляя обменом данными между микросервисами. Второй уровень — контроль «вертикального» трафика на границе периметра (north-south): маршрутизация, NAT, VPN, балансировка и фильтрация входящих подключений. За него отвечает периметровый шлюз — например, NSX Edge (VMware) в облаке Cloud4Y, который контролирует доступ к группам виртуальных машин и защищает доступ к унаследованным приложениям, не требуя вмешательства в их код. Вместе эти два уровня и образуют ту самую среду, где принцип «нулевого доверия» работает и снаружи, и внутри сети.
Как выглядят политики доступа
Именно политики доступа — то место, где Zero Trust перестаёт быть теорией. Хорошая политика опирается не на сетевой адрес, а на контекст: кто запрашивает доступ, с какого устройства, в какое время, насколько рискованной выглядит сессия.
В отличие от старой схемы, где сотруднику выдавали широкие права «на всякий случай», здесь работает принцип наименьших привилегий. Условный подрядчик получает роль с доступом ровно к одному ресурсу на одну неделю — и этот доступ отзывается автоматически, без правки сетевых конфигов. Сессия может прерваться сама, если уровень риска вырос или задача завершена.
Технически это реализуется через краткоживущие сертификаты и токены: сервисы получают цифровую идентичность (например, через SPIFFE/SPIRE), а пользователи аутентифицируются по OIDC. Важная деталь, которую часто упускают: политики стоит описывать как код (Infrastructure as Code, например через Terraform) — тогда их можно версионировать, ревьюить и единообразно раскатывать по мере роста инфраструктуры.
Чтобы это не звучало абстрактно, вот как выглядит логика типовой политики на словах. Доступ к базе с платёжными данными разрешается только сервису биллинга, только с подтверждённой через mTLS идентичностью, только из заданного сегмента и только если токен сервиса не старше пяти минут (по истечении срока он автоматически обновляется через механизм ротации). Любое отклонение — запрос из другого namespace, устройство без актуального шифрования диска, попытка в нерабочее время от пользователя из группы поддержки — переводит сессию в отказ или требует дополнительной проверки. Заметьте: ни одно из условий не опирается на «сервис уже внутри сети» — именно это и отличает политику Zero Trust от классического правила firewall.
Пошаговое внедрение: фазовый подход
Самая частая стратегическая ошибка — попытка внедрить всё и сразу, рассчитывая мгновенно получить идеальную модель. На деле это почти гарантированный путь к сорванным срокам и неконтролируемым процессам со стороны команд. Рабочий подход — поэтапный, начиная с наименее критичных сервисов и постепенно расширяя охват. Ниже — типичная дорожная карта на полгода.
Фаза 1 (1–2 месяца): фундамент. Настройте централизованный Identity Provider с MFA для всех пользователей и ролей. Внедрите базовую микросегментацию. Запустите одно пилотное приложение, на котором проверите связку PDP/PEP в боевых условиях. Цель фазы — не охват, а отработка механики на безопасном участке.
Фаза 2 (3–4 месяца): расширение. Подключайте основные бизнес-приложения. Вводите продвинутые политики — контекстный и ролевой доступ. Параллельно настройте централизованный сбор логов и алертинг с интеграцией в SIEM: без единой точки наблюдения Zero Trust слепнет.
Фаза 3 (5–6 месяцев): зрелость. Оптимизируйте производительность, внедряйте продвинутые механизмы (например, проверку подлинности контейнеров) и переходите к непрерывному контролю соответствия — автоматической проверке того, что политики не «расползлись».
Как не сломать бизнес-процессы
Это и есть главный риск проекта. Безопасность, которая мешает людям работать, не выживает: её обходят, отключают или тихо саботируют. Три зоны напряжения, за которыми нужно следить особенно внимательно.
Производительность и задержки. Каждый запрос теперь проходит дополнительные проверки аутентификации и авторизации, а это потенциально увеличивает время отклика. При неправильной реализации в системе из сотен микросервисов задержки накапливаются. Лечится это архитектурно: кэширование статики на CDN ближе к краю сети, автомасштабирование агентов и прокси под нагрузкой, постоянные keep-alive-соединения между сервисами вместо частых TLS-рукопожатий. Грамотно собранный ZTNA на современных протоколах при правильной архитектуре может не уступать классическому VPN, а нередко и опережать его — за счёт того, что не гоняет весь трафик через единый концентратор.
Legacy-системы. Это, пожалуй, самое дорогое препятствие. Многие компании держатся на критичных приложениях, написанных до появления современных методов аутентификации, и втиснуть их в Zero Trust напрямую невозможно. Решение — не переписывать бизнес-логику, а «оборачивать» такие сервисы: подключать их через sidecar-прокси (канонический пример — Envoy) для поддержки mTLS, использовать TCP-forwarding через прокси доступа или поэтапно заводить их за периметровый шлюз без изменений в коде. Именно такой шлюз, о котором шла речь выше, даёт зону контроля вокруг унаследованных систем, с которой можно постепенно двигаться к полноценной модели Zero Trust.
Люди. Недооценка человеческого фактора — классическая причина провала. Сотрудники привыкли к периметровой модели, и новые проверки воспринимаются как помеха. Поэтому команду нужно вовлекать и обучать заранее, а DevOps- и SecOps-специалистам — давать время освоить новые инструменты. Безопасность не должна стоять стеной между человеком и его работой; она должна быть незаметным фоном.
Типичные ошибки и российская специфика
Индустрия уже накопила болезненный опыт. Сведём самые частые промахи в чек-лист, чтобы было что проверить перед стартом:
-
Zero Trust как продукт, а не стратегия. Покупка дорогой «коробки» даёт лишь иллюзию защиты.
-
«Всё и сразу». Попытка развернуть все компоненты разом вместо фазового подхода.
-
Изолированные компоненты. MFA и сегментация внедрены, но работают независимо, не складываясь в единый сценарий безопасности.
-
Отсутствие единого центра событий ИБ. Без централизованного сбора и анализа логов система неуправляема.
-
Недооценка человеческого фактора. Сотрудников не обучили и не вовлекли.
Для российских компаний есть отдельный пласт требований, который западные руководства игнорируют. Zero Trust не может стоять над законом: внедрение должно укладываться в нормативные рамки — прежде всего 152-ФЗ, 187-ФЗ и 149-ФЗ, особенно если вы работаете с госсектором или объектами критической информационной инфраструктуры (КИИ). Решение, которое технически безупречно, но не проходит проверку регулятора или аудита, бесполезно. Добавьте к этому ограничения на используемые вендорские продукты и необходимость учитывать импортозамещение — и станет понятно, почему российское внедрение требует своей дорожной карты, а не копирования чужой.
С чего начать
Если свести всё к практике, рабочий старт выглядит так. Проведите честную оценку текущей инфраструктуры и процессов. Определите 1–2 наименее критичных сервиса для пилота. Включите централизованный IdP с MFA. Опишите первые политики как код. И сразу заложите централизованный сбор логов — наблюдаемость пригодится с первого дня.
Четыре фактора отличают успешные проекты от провальных: тщательное планирование зон доверия и ролей до старта, фазовый rollout от простого к критичному, непрерывный мониторинг и обучение команды. Zero Trust — это марафон, а не спринт. Но пройденный поэтапно, он даёт то, чего периметровая модель не способна дать в принципе: безопасность, которая масштабируется вместе с бизнесом, а не против него.
