Zero Trust: проверка каждого запроса вместо доверия периметру

Переосмысление периметра: уход от «замка и рва»

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

Это отображает новую реальность: корпоративные данные всё чаще размещаются вне ЦОДа, штат сотрудников гибко переключается между офисом и удалёнкой, а поставщики, подрядчики, клиенты регулярно участвуют во внутренних бизнес-процессах. Каждый новый канал доступа влечёт дополнительные риски. Периметр становится условным: разрозненные компоненты, сервисы, облака, мобильные устройства создают непредсказуемый ландшафт, в рамках которого невозможно поддерживать «доверенный контур».

Zero Trust возник из необходимости сделать ставку не на окружение в целом, а на верификацию и контроль каждого отдельного взаимодействия с ресурсом, приложения, сервисом — без предположения о надежности среды, в которой работает пользователь. Именно кардинальный отказ считать “внутреннее” безопасным и “внешнее” враждебным и составляет основу этой философии.

В фокусе Zero Trust оказываются два аспекта: идентификация каждого субъекта (пользователь, процесс, устройство) и минимизация зоны потенциального вреда в случае компрометации. Классические ИБ-подходы в современных инфраструктурах уже не работают: недостаточно выставить межсетевой экран на периметре и надежно делегировать всё доверие внутрь — теперь доверяют не локации, а только подтверждённой идентичности в нужном контексте.

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

Почему традиционный периметр потерял актуальность

В классической архитектуре предприятия вся ИТ-инфраструктура разделялась на “доверенную” зону (та, что находится внутри сетевого периметра: офис, ЦОД, защищённые филиалы) и “опасную” внешнюю сеть — интернет или сегменты с неуправляемым доступом. Предполагалось, что если грамотно выстроен периметр — используя межсетевые экраны, VPN, IDS/IPS — то внутренняя сеть становится практически зоной доверия. Все угрозы, по логике старой модели, приходят извне, а “свои” всегда надежны.

Однако развитие ИТ привело к тому, что атаки, прокравшиеся внутрь (через скомпрометированные устройства, поддельные VPN или фишинг), оставались практически незамеченными. Ни одна сетевая стена не способна уловить движение злоумышленника внутри “доверенного периметра”, если тот действует под видом легитимного пользователя или устройства.

Так, реальный вектор риска сместился из классического «снаружи-внутрь» к «горизонтальному» перемещению внутри. Злоумышленник после первого проникновения получает полный доступ к ресурсу и может двигаться между внутренними сервисами: почтой, документооборотом, базами данных, HR-системами и даже критичными бухгалтерскими контурами. Большинство современных инцидентов связано не с внешним взломом, а с дальнейшей эксплуатацией уже действующего канала или сессии доверенного субъекта.

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

Эти изменения делают старую границу условной — она перестала быть достаточной. Атаки становятся сложнее: фишинг, кража учётных данных, social engineering, эксплуатация доверенных каналов связи, вредоносное ПО на легитимных устройствах. Всё это превращает современную инфраструктуру в зону постоянного риска даже внутри “надежного” сегмента.

Растёт зависимость от облачных сервисов и внешней инфраструктуры, что размывает границы.
Мобильность сотрудников приводит к частой смене “внутреннего” и “внешнего” статуса устройств.
Внутренние угрозы (компрометация аккаунтов, инсайдеры) становятся основной проблемой, а не исключением из правил.
Горизонтальное перемещение злоумышленника по внутренней сети не встречает барьеров из-за отсутствия достаточной сегментации и контроля.
Появились новые типы конфигурационных ошибок: случайная экспозиция сервисов, неавторизованный доступ через унаследованные VPN или публичные облака.

[ИЗОБРАЖЕНИЕ: Схема, сопоставляющая традиционную модель («доверенная внутренняя сеть» vs «ненадёжная внешняя сеть») и Zero Trust («доверие ни к кому», доступ к каждому ресурсу по отдельности)]

Основы Zero Trust: от доверия — к контролю

Zero Trust — это не просто новый набор инструментов или “модная” терминология, это полностью иная парадигма. Ключевые элементы концепции:

Явная проверка для каждого запроса. Доверие к каждому субъекту, даже если он уже находится в корпоративном сегменте, не устанавливается автоматически. Каждый раз, хотите ли вы получить доступ к базе данных, облачному сервису или внутреннему приложению, ваш запрос проходит полный спектр проверки: от аутентификации, анализа состояния устройства, до контекстуальных факторов (география, время, используемая сеть, прошлое поведение).
Принцип минимальных прав (Least Privilege). Каждый пользователь, сервис и даже скрипт внутри инфраструктуры получает не “базовый набор полномочий”, а только строго необходимое для совершения задач. Это означает: нет универсальных учётных записей “для всех” и запрещён наследуемый доступ, если нет явного подтверждения потребности.
Микросегментация сети и ресурсов. Вместо крупных, доверенных зон внедряются многочисленные микросегменты: обмен между ними через специально настроенные шлюзы/прокси, каждое соединение контролируется и регистрируется. Даже внутри “одного” приложения могут быть выделены микросегменты по ролям, функционалу, уровню доступа.
Постоянное предположение о компрометации. Модель работает с установкой, что взлом уже случился или может произойти в любой момент. Надёжность любого компонента сомнительна, поэтому безопасность строится на постоянной аналитике, мониторинге и реагировании, а не на доверии к текущему статусу сегмента.
Прозрачный аудит и трекинг событий. Любое действие пользователя или приложения логируется и анализируется в реальном времени. Возникает подозрительная активность — например, скачивание множества документов вне графика или смена географии за короткий срок — она автоматически отслеживается и приводит к доразрешению, блокировке или дополнительной проверке.

Главное отличие Zero Trust от традиционного подхода — в точке проверки: если раньше, попав за VPN, сотрудник получал права на доступ ко многим ресурсам, то теперь весь дальнейший доступ строится на конкретных политиках и управлении привилегиями. Каждый доступ к ресурсу требует заново доказать свою “авторизованность”. Такая модель существенно снижает потенциальные риски от компрометации одного устройства или аккаунта.

Zero Trust — это движение от доверия к постоянному контролю и анализу, где важнее не локация, а подтверждённые атрибуты, статусы, поведения и минимизация зон влияния.

Сравнение моделей: традиционный периметр и Zero Trust

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

Аспект	Традиционная модель (Периметр)	Zero Trust
Базовый принцип	Доверие внутренней сети, защита на входе	Проверка каждого запроса, доверие отсутствует по умолчанию
Граница защиты	Сетевая граница (ЦОД, офис, филиал)	В каждый отдельный объект инфраструктуры — сегмент, сервис, приложение
Доступ пользователей	Попав в сеть через VPN — сотрудник видит всё доступное внутри	Каждый запрос к ресурсу — новая точка принятия решения, нет универсальных доступов
Работа с внутренними угрозами	Перемещение по сети часто не контролируется, инциденты внутри остаются незаметными	Микросегментация, ограничения доступа, постоянное логирование и анализ активности
Типичная среда	Офис, ЦОД, минимум облаков и мобильных сотрудников	Облака, SaaS-приложения, удалёнка, DevOps, перемешанная инфраструктура
Ключевые инструменты	NGFW, VPN, классические антивирусы, IDS/IPS	SASE/SSE, IAM, прокси доступа, сегментаторы SDN, сервис-меши
Риски компрометации	Попадание злоумышленника внутрь быстро приводит к распространению по сети	Даже при компрометации одного компонента масштаб инцидента ограничен политиками доступа
Соответствие современным требованиям	Трудности с контролем облаков, SaaS, мобильных, подрядчиков	Гибкое управление доступом к разноплановым ресурсам и пользователям

Итог: Zero Trust не исключает необходимость периметровых средств (особенно для защищённых сегментов влиятельных систем, АСУ ТП и промышленных сетей), но делает их лишь одним, вспомогательным уровнем, акцентируя внимание на контроле каждого запроса.

Технологические основы Zero Trust

Zero Trust не реализуется покупкой одного “волшебного” продукта. Это комплексная архитектура, в которой сочетаются технологии, процессы и организации. Основные технологические элементы:

Идентификация и управление доступом (IAM). Центральный элемент: вся логика опирается на одноразовые токены, усиленную (многофакторную) аутентификацию, контроль по десяткам факторов — от атрибутов устройства до местоположения и активности во времени. При изменении контекста доступа политика может требовать экстренной проверки или полного блокирования сессии.
Платформы условного доступа (ZTA/ZTNA, SASE, SSE, SDP). Такие инструменты позволяют выносить политики доступа ближе к самим приложениям, а не к сетевым границам. Сотрудник, подключаясь к корпоративному сервису, проходит не через общий VPN, а через специальный шлюз, который проверяет каждый отдельный запрос.
Микросегментация сети и сервисов. Сеть делится на минимальные изолированные части, для “путешествия” между которыми требуется отдельное разрешение. Чаще всего реализуется программно-определяемыми решениями (SDN), агентами или прокси.
Прокси, шлюзы, точки концентрации политик. Функция проста: ни один субъект не может выйт на приложение или сервер напрямую. Все запросы проходят через управляемое звено (шлюз или прокси), где происходит сверка с политиками, а трафик шифруется. Внешнему миру внутренняя инфраструктура становится “невидимой”.
Непрерывный мониторинг и анализ событий. Большой поток событий собирается и проходит через SIEM, SOAR, UEBA — системы для анализа поведения, корреляций и автоматического обнаружения отклонений норм. Отдельные блоки отслеживают попытки несанкционированного перемещения, массовый выгруз данных, подозрительную активность.
Автоматизированное управление политиками. Правила задаются централизованно, базируются на “сценариях” и “роли”, что позволяет гибко изменять контроль доступа под реальные рабочие потребности, а не только по административному принципу.
Шифрование и токенизация данных на каждом уровне. Даже если злоумышленник получает доступ к отдельному сегменту или сервису, экспортировать ценные данные — непросто: всё защищено шифрованием, токенами, а ключи управления хранятся отдельно.

[ИЗОБРАЖЕНИЕ: Диаграмма потока Zero Trust: пользователь → шлюз доступа (проверка идентификатора, устройства, контекста) → подключение только к подтверждённому приложению]

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

Немаловажно и то, что архитектура Zero Trust органично встраивается в современные DevOps-процессы — она допускает автоматическое изменение политик при релизах, подстраивается под временные команды и сценарии по принципу Just-in-time Access. В результате украденный аккаунт или похищенное устройство перестают означать мгновенную потерю всех данных — масштаб ущерба определяется привилегиями и эффективностью детекции инцидентов.

Практическая реализация Zero Trust требует изменения культуры работы с ИТ: больше автоматизации, больше прозрачности, меньше принципа “по умолчанию разрешено” — и постоянная готовность к новым сценариям атак.

Zero Trust в России: требования ФСТЭК и 152-ФЗ

В регуляторном поле России вопросы информационной безопасности традиционно решались жёстким управлением периметром (ГОСТ, ФСТЭК, обособленные сегменты, контроль каналов связи, ЧЗВ). Ключевые документы (Приказы ФСТЭК №17, №21, ГОСТы по защите персональных данных, 152-ФЗ «О персональных данных») исходят из предположения, что ИС — это система с определённой границей, за которой размещаются средства защиты — межсетевые экраны типа NGFW, VPN, DLP и пр. Однако на практике реалии изменились: мультиоблачные среды, гибридные архитектуры, массовое внедрение SaaS и переход крупного бизнеса на микросервисные приложения не укладываются в такую простую концепцию.

В последние годы положение постепенно меняется. Рекомендации ФСТЭК (в том числе новая редакция методических документов) и толкование 152-ФЗ допускают сценарии Zero Trust. Но при этом подчёркивается: любая модель контроля — включая отказ от “жёсткого” периметра — должна быть полноценно обоснована и задокументирована. Главные задачи:

Прозрачно и детализировано описать процессы управления доступом: как удостоверяются субъекты, как разделяются роли, как принимаются решения об одобрении или отказе в доступе.
Использовать отечественные сертификатные средства защиты информации, в том числе для криптографической защиты каналов связи, токенизации, журналирования событий.
Обеспечить локализацию и описание маршрутов данных персональных данных в любой точке обработки — неизменно актуально для соответствия 152-ФЗ. Применяется как для on-premise систем, так и для облаков.
Вести не только технический, но и организационный аудит всех процессов в системе: чтобы каждый доступ, каждая попытка получить права, каждый выход за пределы “белых” сценариев фиксировались и могли быть реконструированы в случае проверки/инцидента.
Документировать все политики (RBAC, ABAC, context-aware), использовать специальные механизмы контроля доступа (например, отказ по условию “нестандартного места выхода”, ограничение прав для внешних подрядчиков и т.д.).

На российском рынке уже присутствуют отечественные SASE, IAM, продукты для микросегментации сети, реализующие логику Zero Trust в правовом поле РФ. Иностранные платформы, напротив, постепенно вытесняются, либо интегрируются через шлюзы сертифицированных производителей. Важно: все данные, подлежащие защите по 152-ФЗ, могут обрабатываться только внутри доверенной территории, с использованием сертифицированных криптосредств. Компании, использующие Zero Trust, получают ряд преимуществ: упрощается контроль раздельных сегментов доступа, усиливается логирование и аутентификация, быстрее проводится аудит при проверках, эффективнее строятся гибкие сценарии взаимодействия с подрядчиками и пользователями.

Следовательно, при грамотной проработке политики Zero Trust не только не противоречит российским требованиям, но и фактически облегчает процесс внедрения сложных моделей разграничения по ролям, сценариям, времени, источнику и даже “поведению” пользователя.

Модель внедрения: гибридный подход и сценарии

Полный переход организации на Zero Trust невозможен одномоментно и не требуется всем подряд. Более того, во многих случаях правильнее выбрать гибридную стратегию, когда классический периметр защищает критичные внутренние службы, а доступ к облачным сервисам, сторонним приложениям и пользовательским рабочим станциям реализуется через Zero Trust. Такой подход позволяет минимизировать затраты и снизить риски организационных ошибок.

Когда нужен Zero Trust:

Дистанционный доступ сотрудников и мобильных команд к корпоративным приложениям и данным (например, инженер у партнёра, сотрудник в разъездах или на удалёнке).
Защита применения SaaS, офисных облачных пакетов, CRM и внутренних сервисов документооборота без выделенного корпоративного контура.
Гибкое распределение прав доступа для подрядчиков, дочерних организаций, временных специалистов — разрешение только на конкретные сегменты или приложения, трекинг всех действий.
Мультирегиональные структуры, филиалы, где централизовать защиту явно невозможно, а перемещения между сегментами опасны (например, розничные сети, транспорт).
DevOps-команды, работающие со staging/production окружениями: разграничение по приложениям и временным токенам, выдача “джаст-ин-тайм” доступа к сервисам, автоматизация создания и отзыва ключей.
Быстрая интеграция новых рабочих процессов, сервисов, бизнес-партнёров — с упором на автоматизированные проверки и минимальные временные привилегии.
Использование облачных инфраструктур как для основной, так и для резервной обработки (DRaaS, BaaS, backup) — чтобы ограничить доступ только тем субъектам, которым это действительно необходимо, и с детализацией, кто и когда что выгружал.

Где остаётся традиционный периметр:

Критичные и изолированные промышленные сети (АСУ ТП, КИИ), где минимальное количество интерфейсов внешнего доступа, а любая “сквозная” политика может привести к неуправляемому риску.
Офисные сегменты с устаревшими приложениями, невозможностью интеграции современных IAM или средств микросегментации.
Серверные площадки с жёсткими требованиями атак класса L2–L3, где проще поставить мощный NGFW, чем развёртывать полноценную многоуровневую логику доступа.
Гиперизолированные зоны хранения данных, резервные ЦОД, где основное требование — физическая недоступность для всех кроме узкого круга инженеров под контролем прямого руководителя.
“Тяжёлые” монолитные системы, не позволяющие дробить приложения и пользователей на отдельные сегменты.

Переход к Zero Trust — процесс, занимающий не месяцы, а несколько лет. Первый этап — анализ рисков: какие данные и сервисы наиболее ценны и подвержены угрозам, какие сценарии доступа нуждаются в детальном разграничении. Далее — внедрение пилотных решений (например, микросегментация в одном облаке, Zero Trust Access к CRM), выработка политик по ролям, мониторинг и реагирование на инциденты. После этапа “пилота” охват Zero Trust расширяется — подключаются внутренние сегменты, строятся шлюзы для управления доступом к ядру инфраструктуры, выстраиваются процессы автоматизации доступа.

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

В долгосрочной перспективе в организации формируется многоуровневая, гибкая схема управления угрозами, позволяющая быстро адаптироваться под появление новых каналов доступа, технологий, типов пользователей и изменений бизнес-процессов. Такой подход позволит значительно снизить количество успешных инцидентов, повысить прозрачность аудита для регулятора и усилить доверие к IT как ядру современного бизнеса. Zero Trust перестаёт быть “маркетинговым словом” или зарубежной прихотью, становясь обязательным элементом зрелой инфраструктуры.

Инфраструктура с Zero Trust устойчивее к ошибкам конфигурации, перемещениям сотрудников и сторонних подрядчиков, облачным миграциям. Даже если что-то случается — последствия инцидента будут минимальны: сложности горизонтального перемещения, суженный контур компрометации, постоянный мониторинг и быстрый аудит позволяют быстро локализовать проблему. Организации, вовремя перешедшие на такой режим, защищают не только серверы и данные — но и бизнес-репутацию, и валидность перед контролирующими органами.

Zero Trust, особенно в условиях неизбежных требований по 152-ФЗ, локализации данных и регуляторного давления ФСТЭК, становится не только инструментом технологической безопасности, но и фактором стратегической устойчивости: рост гибкости, сокращение убытков, уменьшение человеческого фактора и политик “оверпрайвилидж”. Стоит начинать этот путь как можно раньше: не чтобы “модничать”, а чтобы соответствовать новым реалиям цифровой экономики.