«Античит-система, это модель мира, где ты по умолчанию враждебен, пока не доказал обратное. И доказывать приходится постоянно, а не один раз при входе. В корпоративной IT-реальности это не про игру, а про каждую команду PowerShell, каждый HTTP-запрос, каждую попытку запустить что-то с флешки. Доверие здесь — переменная величина, которая может обнулиться в любой момент. И это не паранойя, а новая норма.»
Как устроена проверка «клиента» в корпоративной сети
Термин Endpoint Detection and Response (EDR) давно превратился в общее название для агента, который живёт на устройстве и никогда не спит. Его нельзя отключить, его нельзя игнорировать. Это не сканер, который запускается по расписанию. Это постоянно действующий инспектор, который оценивает среду выполнения в реальном времени. Он сродни гипервизору, но на уровне процессов и поведения операционной системы.
Установка агента, это не финальная точка, а начало непрерывного диалога между устройством и центром управления. Этот диалог строится на оценке сотен параметров, которые сводятся в единый показатель — динамический уровень доверия. Состояние шифрования диска, актуальность загрузчика UEFI, версия антивирусных баз, наличие работающего экрана блокировки, статус последних обновлений ОС — всё это не просто «чек-лист». Это живые сигналы, вес которых меняется. Например, устаревший на три месяца патч безопасности не просто снижает общий балл, а может перекрыть доступ к системам, работающим с персональными данными — по требованиям 152-ФЗ, доступ к ним должен быть защищён максимально.
Контекст аутентификации собирается из десятков источников. Геолокация по IP — лишь один из них. Современные системы анализируют поведенческие паттерны: с какого устройства обычно работает бухгалтер Петров (корпоративный ноутбук Dell), в какое время (9:00–18:00 по московскому времени), какой софт запускает (1С, Excel, Outlook). Попытка входа Петрова в полночь с IP из Таиланда с использованием неизвестного устройства, это не просто красный флаг. Это событие, которое не блокирует доступ сразу, но резко снижает кредит доверия, запуская каскад дополнительных проверок, например, обязательную многофакторную аутентицию через доверенный канал.
Анализ процессов, это не просто просмотр списка в диспетчере задач. EDR-агент строит граф выполнения. Он отслеживает родительско-дочерние связи: какой процесс кого породил, с какими библиотеками работает, к каким файлам обращается, какие сетевые соединения устанавливает. Стандартный системный процесс svchost.exe, который внезапно начинает делать DNS-запросы к доменам в зоне .top и параллельно запускает certutil.exe для декодирования бинарного файла из временной папки,, это триггер высочайшего уровня риска. Такие техники — основа для обхода классических сигнатурных систем.
Оценка распространяется даже на, казалось бы, безопасные действия. Процесс текстового редактора, который начинает делать HTTP-запросы на внутренний API отдела кадров, — аномалия. Даже если у пользователя есть права на этот API, сам факт такого поведения, не характерного для его роли, становится поводом для изоляции запроса и отправки алерта в SOC. Система учится не на правилах «разрешено/запрещено», а на паттернах «типично/аномально». Если инженер из отдела разработки, который никогда не работал с финансовыми отчётами, внезапно массово скачивает PDF-файлы с платёжными поручениями, это отклонение будет вычислено и остановлено до момента эксфильтрации.
Важно, что этот расчёт не статичен. Уровень доверия может понижаться или повышаться. Успешное обновление системы или подтверждение действия через MFA повышает балл. Обнаружение подозрительной активности в фоновом режиме — понижает. Для операций с максимальным уровнем секретности, таких как работа с гостайной или персональными данными по 152-ФЗ, политика может требовать проверки состояния устройства перед каждым запросом, даже в рамках активной сессии. Это исключает сценарии, когда устройство компрометируется уже после успешного входа в систему.
Техническая сторона: что стоит между пользователем и данными
Архитектурно доступ организуется через микросервисную сегментацию, основанную не на сетевых адресах, а на логических границах приложений. Пользователь получает не доступ «в сеть», а разрешение на выполнение конкретного действия — например, вызов метода POST /api/invoices. Попытка обратиться к соседнему методу GET /api/invoices будет отклонена, даже если технически эндпоинт существует. Это реализуется через декларативные политики, привязанные к идентичности пользователя, его роли и текущему контексту сессии.
Сетевая инфраструктура в этой модели перестаёт быть средой для прямой маршрутизации. Она становится транспортом для зашифрованных туннелей между клиентским агентом и специализированными шлюзами доступа. Эти шлюзы, размещённые на периметре или в облаке, выступают в роли единственных разрешённых точек входа для приложений. Клиент подключается к шлюзу, а шлюз, в свою очередь, — к целевому приложению. Прямые соединения извне внутрь периметра исключены.
Роль шлюза доступа
Шлюз работает по принципу «не пропускать ничего без глубокой проверки». Он анализирует трафик на прикладном уровне (L7). Первым делом проверяется наличие и валидность токена доступа (OAuth 2.0, JWT). Токен расшифровывается, извлекаются утверждения (claims): идентификатор пользователя, роль, область действия (scope), время жизни. Затем эти данные сверяются с актуальными политиками доступа. Токен может содержать роль manager, но политика для доступа к бюджетным отчётам может требовать дополнительного атрибута department: finance.
Если хотя бы одно условие не выполнено, соединение не устанавливается. Шлюз не перенаправляет запрос дальше, а сразу возвращает клиенту ошибку авторизации (например, HTTP 403). Это исключает возможность «прощупать» систему на наличие других уязвимых путей. Даже если злоумышленник завладеет действующим токеном, но попытается использовать его с устройства, не прошедшего проверку (например, без установленного EDR-агента), шлюз отклонит запрос.
Динамические политики и контекст
Политики доступа динамичны и могут пересчитываться для каждого запроса. Через несколько минут после успешного входа система SIEM может получить информацию о новой критической уязвимости в браузере, который использует сотрудник. Уровень доверия к его устройству мгновенно падает, и последующий запрос к защищённому приложению будет заблокирован, несмотря на валидный токен.
Окончательное решение о доступе принимается на основе агрегированной оценки из множества источников:
- EDR: состояние операционной системы, наличие активных угроз.
- IAM (Управление идентификацией и доступом): роль, группа, членство в проектах.
- NDR (Обнаружение сетевых угроз): аномалии в сетевом поведении (тип, объём, частота трафика).
- Шлюз доступа: геолокация, «здоровье» соединения, время суток.
Система сравнивает текущий профиль активности с эталонным для данной роли и пользователя. Если бухгалтер, обычно работающий с 5-10 документами в день, внезапно инициирует сотни запросов к системе отчётности за минуту, это вызовет срабатывание анализа аномалий. Реакция может варьироваться от запроса повторной аутентификации до полной блокировки сессии и оповещения службы безопасности.
Языки политик и их исполнение
В основе архитектуры ZTNA (Zero Trust Network Access) лежит принцип «запрещено по умолчанию». Каждое разрешение, это явно описанное исключение. Это полная противоположность модели VPN, где после подключения разрешено всё, что явно не запрещено правилами. Политики формулируются на специализированных языках, например, Rego для Open Policy Agent (OPA).
Такие правила обрабатываются высокопроизводительными движками политик, такими как OPA. Правила компилируются в оптимизированный код для выполнения за микросекунды. При изменении политики в центральном репозитории все шлюзы получают обновления практически мгновенно, что обеспечивает согласованность политик в распределённой инфраструктуре.
Почему старые VPN похожи на отключённый античит
В классической модели VPN пользователь проходит аутентификацию один раз. После успешного входа ему присваивается IP-адрес внутри корпоративной сети, и он получает возможность взаимодействовать с другими системами в этой сети. Это аналогично тому, как игрок, прошедший проверку при входе на сервер, далее может свободно перемещаться по игровому миру без дополнительных проверок. Такая модель неявно предполагает, что внутренняя сеть, это «безопасная зона», а все, кто в неё попал, заслуживают доверия.
Это фундаментально противоречит философии Zero Trust, где доверие никогда не предоставляется неявно и должно постоянно перепроверяться. Если устройство внутри VPN-туннеля скомпрометировано (например, через фишинговую атаку), оно становится плацдармом для атак на другие внутренние системы. Злоумышленник может сканировать сеть, искать уязвимые службы и перемещаться между системами (техника lateral movement). Традиционные межсетевые экраны часто плохо защищают от такого трафика внутри сети, так как сконфигурированы в первую очередь для фильтрации входящего и исходящего трафика.
VPN плохо масштабируются в современных условиях. Для каждого нового филиала, партнёра или облачного сервиса требуются новые туннели и сложные правила маршрутизации. Учётные записи для внешних подрядчиков часто создаются с избыточными правами — проще дать доступ «ко всему», чем тратить время на тонкую настройку.
Zero Trust устраняет саму концепцию «внутренней сети» как единого периметра. Каждое приложение изолировано, и доступ к нему предоставляется исключительно через шлюз. Устройство подключается напрямую к шлюзу, не получая IP-адрес во внутренней подсети. Это радикально упрощает сетевую архитектуру: отпадает необходимость в сложной маршрутизации между дата-центрами и синхронизации VLAN. Приложения могут находиться где угодно — в облаке, у хостинг-провайдера или в локальном ЦОДе — шлюз обеспечивает к ним единообразный доступ.
Единственной точкой принятия решения становится шлюз. Он обладает полным контекстом: кто запрашивает, с какого устройства, откуда и куда направлен запрос. Это позволяет применять контекстно-зависимую авторизацию. Например, доступ к системе управления персоналом с личного смартфона, не прошедшего проверку на соответствие политикам, может быть ограничен только чтением справочной информации.
Кроме того, в модели Zero Trust пользователь лишён возможности прямой разведки инфраструктуры. Он не может запустить сканер портов, потому что его трафик не маршрутизируется во внутренние подсети — он идёт только до шлюза, который сам решает, как обработать запрос. Это лишает атакующих критически важного этапа сбора информации о топологии сети и уязвимых службах.
переход с VPN на ZTNA, это не просто замена одного технологического решения на другое. Это смена парадигмы безопасности: от защиты периметра к защите каждого отдельного ресурса на основе непрерывной оценки доверия.
Редкие детали, о которых не пишут в маркетинговых брошюрах
Лавина событий и ложные срабатывания
Одна из скрытых проблем внедрения Zero Trust — лавина событий и ложных срабатываний. Агенты EDR, сетевые сенсоры, шлюзы и системы IAM генерируют огромные объёмы телеметрии. Некоторые агенты отправляют данные каждые несколько секунд. Это создаёт нагрузку на каналы связи, особенно для удалённых сотрудников, и перегружает системы анализа (SIEM/SOC). Но главная сложность — в ложных positives.
Например, легитимный скрипт автоматизации тестирования, запускающий PowerShell для развёртывания стенда, может быть классифицирован как подозрительная активность, похожая на действия вредоносного ПО. Система генерирует алерт, уровень доверия к устройству падает, и в следующий момент сотрудник не может получить доступ к критическому приложению. Для разблокировки требуется ручное вмешательство администратора и добавление исключения в политику. Со временем таких исключений накапливается десятки, что размывает первоначальную строгость политик и снижает общую эффективность защиты.
Решение заключается не в отключении проверок, а во внедрении механизмов адаптивного обучения и «белых списков» на основе машинного обучения. Если определённое поведение повторяется регулярно в штатном режиме и не приводит к инцидентам, система должна постепенно повышать его «репутационный балл». Однако это требует тщательной настройки и глубокого понимания бизнес-процессов.
Зависимость от вендора (vendor lock-in)
Другая значимая проблема — зависимость от одного вендора. Многие комплексные решения ZTNA предлагают «закрытую экосистему»: собственный агент, шлюз, систему управления политиками и панель мониторинга. Если вы используете агент вендора А, а шлюз вендора Б, полная синхронизация контекста безопасности (например, уровня доверия устройства) может быть невозможна из-за несовместимых форматов данных и API.
Это привязывает организацию к одному поставщику на долгий срок. Выбрав платформу, вы теряете гибкость. Попытка интегрировать в эту экосистему стороннюю SIEM-систему или EDR-решение другого производителя часто наталкивается на ограничения. Вендор не заинтересован в предоставлении открытого доступа ко всем внутренним механизмам оценки. В итоге вы получаете «чёрный ящик», эффективность которого сложно оценить независимо.
Уязвимость ядра системы — IAM
Третий, и наиболее уязвимый элемент всей архитектуры — система управления идентификацией и доступом (IAM). Она становится центральным мозгом, который все остальные компоненты безоговорочно слушаются. Если злоумышленник получает контроль над IAM (через компрометацию учётной записи привилегированного администратора, уязвимость в системе или фишинг MFA), он может создавать легитимные сессии от имени любого пользователя.
В этом случае вся многоуровневая защита Zero Trust может оказаться бесполезной, потому что:
- Созданные злоумышленником токены будут криптографически подписаны.
- «Устройства» (под контролем атакующего) могут имитировать наличие доверенного агента.
- Шлюзы доступа, проверяя валидные токены и сигналы от поддельных агентов, будут применять политики и предоставлять доступ.
Компрометация IAM сводит на нет все остальные защитные механизмы. Поэтому именно к этому компоненту должны применяться максимальные меры защиты: физическая и логическая изоляция административного доступа, обязательная многофакторная аутентификация с использованием аппаратных токенов для привилегированных учётных записей, строгий аудит всех изменений и принцип наименьших привилегий. На практике же IAM-системы часто остаются слабым звеном, так как основное внимание уделяется более «видимым» элементам, таким как шлюзы и клиентские агенты.
Требования ФСТЭК и 152-ФЗ в контексте Zero Trust
При внедрении подхода Zero Trust в российских организациях, особенно госсектора или операторов персональных данных, возникают нюансы, не очевидные с первого взгляда. Многие требования ФСТЭК, например, из документов серии «Защита информации», построены на классической модели с чётким выделением периметра сети, сегментацией и использованием средств защиты, имеющих сертификаты соответствия.
Подход «доверяй, но проверяй» (Zero Trust) может вступать в концептуальное противоречие с некоторыми трактовками требований, основанных на «доверенной внутренней зоне». Например, требование о контроле съёмных носителей может быть реализовано в EDR-агенте, но сам агент должен быть сертифицированным средством защиты информации (СЗИ). Использование иностранных платформ для управления идентификацией (IAM) или анализа угроз (UEBA) может быть ограничено требованиями о локализации данных и резидентности.
С точки зрения 152-ФЗ, подход Zero Trust может служить эффективным техническим механизмом для реализации принципа минимально необходимых прав доступа к персональным данным. Однако необходимо обеспечить, чтобы все журналы событий (аутентификация, авторизация, доступ к данным) хранились на территории РФ в соответствии с требованиями закона, а системы их обработки были внесены в реестр Роскомнадзора.
внедрение не отменяет необходимости проходить процедуры аттестации и соблюдать отраслевые стандарты. Наоборот, оно требует более тщательного согласования с регуляторами, чтобы новая архитектура была признана соответствующей установленным требованиям. Часто это приводит к созданию гибридных моделей, где классические сертифицированные средства (например, межсетевые экраны) работают в паре с новыми решениями ZTNA.