Нередко внедрение концепции Zero Trust ограничивается связкой из MFA и базовой сегментации сети. Однако подлинная безопасность нулевого доверия заключается не в разовой проверке при авторизации, а в архитектурном подходе, при котором решение о доступе пересматривается непрерывно. Разберем, как устроена эта модель по стандарту NIST SP 800-207, из чего складывается показатель trust score и почему IdP, ZTNA и SIEM по отдельности не формируют полноценную систему защиты.
Разбор понятий: Zero Trust, ZTA и ZTNA
В ИТ-индустрии эти термины часто используют как синонимы, что создает путаницу. Для точного понимания архитектуры разделим их:
- Zero Trust: концепция и базовый принцип безопасности, который формулируется как «никому не доверяй по умолчанию, проверяй каждый запрос». Это не готовый продукт, а подход к организации ИТ-доступа.
- ZTA (Zero Trust Architecture): архитектура реализации данной концепции. Она описывает, как принципы нулевого доверия раскладываются на конкретные компоненты и логику их взаимодействия. Именно эту модель фиксирует стандарт NIST SP 800-207, на который мы опираемся.
- ZTNA (Zero Trust Network Access): одна из технологий внутри общей архитектуры, которая решает локальную задачу: управление сетевым доступом пользователей к конкретным приложениям. Это важный инструмент, но он представляет собой лишь часть экосистемы.
Иерархия простая: общая концепция (Zero Trust) определяет архитектурные правила (ZTA), а конкретные технологии (ZTNA) выступают элементами их реализации.
Почему классический периметральный подход требует пересмотра
Рассмотрим стандартный сценарий: в 9:00 пользователь проходит аутентификацию с помощью MFA и получает токен доступа на стандартные 8 часов. В 11:30 на его рабочей станции происходит запуск вредоносного вложения из фишингового письма, и злоумышленник получает контроль над устройством. Вплоть до окончания рабочего дня система может расценивать действия атакующего как легитимные, поскольку сессия активна, а SSO и MFA уже успешно пройдены. К моменту реагирования ИБ-аналитиков важные коммерческие данные могут оказаться под угрозой.
Проблема кроется не в надежности MFA, которая отработала корректно. Причина в том, что решение о доступе принимается один раз на старте и больше не пересматривается. Между входом в систему и истечением срока действия токена нет контрольных точек для проверки изменившегося контекста.
Чтобы повысить защищенность инфраструктуры, мы рекомендуем внедрить два изменения:
- Дифференцированный порог доверия для ресурсов: например, низкий для внутренней базы знаний и максимальный для панели администрирования.
- Непрерывная оценка: интеграция компонента, который постоянно анализирует текущий уровень доверия к пользователю и сравнивает его с требованиями конкретного ресурса.
Эту роль выполняет Policy Engine, который и трансформирует классическую модель безопасности в полноценную систему Zero Trust.
Архитектура Zero Trust по стандарту NIST
Базовый документ в этой области, стандарт NIST SP 800-207, описывает архитектуру через взаимодействие трех ключевых элементов:
- Policy Enforcement Point (PEP): узел, через который физически проходит сетевой трафик. PEP не принимает самостоятельных решений, он только исполняет инструкции: запрашивает решение у управляющего центра и в зависимости от ответа пропускает или блокирует пакеты. В современных средах роль PEP обычно выполняет ZTNA-шлюз.
- Policy Decision Point (PDP): центр принятия решений, который включает в себя два логических модуля: Policy Engine (PE) для сбора сигналов и расчета trust score, а также Policy Administrator (PA) для передачи команд шлюзу PEP. На практике они часто объединены в один сервис.
- Policy Information Points (PIP): источники сигналов, откуда Policy Engine берет данные для анализа.
Trust Score: принципы измерения доверия
Trust score представляет собой числовой показатель текущего уровня доверия системы к сессии пользователя. Обычно используют шкалу от 0 до 100.
Policy Engine агрегирует сигналы от систем аутентификации, сетевых шлюзов и мониторинга, где каждому событию присвоен определенный вес (положительный или отрицательный). Веса калибруются на основе реального поведения пользователей внутри компании, помогая снизить количество ложных блокировок. Каждая организация настраивает эти параметры под свои бизнес-процессы.
Для критических инцидентов, например, при выявлении подтвержденной компрометации устройства, обычного сложения весов недостаточно. В таких сценариях мы применяем правила override: критический сигнал мгновенно обнуляет trust score и блокирует доступ, независимо от успешно пройденной ранее аутентификации.
Обеспечение непрерывности на практике
Показатель доверия пересчитывается динамически. Если SIEM фиксирует подозрительную активность и передает сигнал в Policy Engine, trust score снижается. При этом пользователя не обязательно полностью отключать от сети, но доступ к критически важным базам данных или админ-панелям закроется автоматически за несколько секунд.
Три слоя сигналов для Policy Engine
- IdP (Identity Provider) определяет личность пользователя и уровень надежности аутентификации. Современные решения (Keycloak, Okta, Microsoft Entra ID) интегрируются со службами каталогов (Active Directory) и передают расширенный набор атрибутов через протокол OIDC. Сигналы включают ID пользователя, тип фактора MFA (SMS, TOTP, аппаратный ключ) и время сессии, а также риск-ориентированные маркеры: нетипичную геопозицию или время входа.
- ZTNA (Zero Trust Network Access) проверяет параметры устройства и контекст подключения. Технология создает защищенный канал к конкретному приложению и валидирует рабочую станцию при каждом запросе. В архитектуре ZTA этот компонент совмещает роли исполнителя (PEP) и источника данных (PIP). Он передает статус обновлений ОС, шифрования дисков, IP-адрес и длительность сессии.
- SIEM (Security Information and Event Management) анализирует общую картину безопасности в реальном времени. Если IdP и ZTNA срабатывают в моменты логина или подключения, то SIEM поставляет алерты от систем EDR и сетевых анализаторов на протяжении всей сессии. Это обеспечивает непрерывность процесса контроля.
Механизмы передачи сигналов
Эффективность архитектуры зависит не только от состава сигналов, но и от способов их доставки:
- IdP передает данные через OIDC-токены, механизмы event listener (модель push) или через API по запросу (модель pull).
- ZTNA чаще работает по модели pull, когда Policy Engine запрашивает статус через API.
- SIEM должен передавать данные исключительно по модели push (например, через вебхуки) в момент срабатывания правила, чтобы обеспечить мгновенную реакцию.
Уровни интеграции Policy Engine и ZTNA
После расчета trust score управляющий узел передает команду на исполнение в ZTNA. Мы выделяем три уровня такой интеграции:
- Уровень 1. Переключение политик. В ZTNA заранее настраивают политики разной строгости, а Policy Engine активирует их через API. Применяется для управления общими правилами доступа.
- Уровень 2. Динамическое перемещение по группам. Пользователи распределяются между доверенными и карантинными группами через API в зависимости от изменения trust score. Это оптимальный вариант для старта, обеспечивающий точечную гранулярность без усложнения архитектуры.
- Уровень 3. Авторизация каждого запроса (per-request). Проверка происходит при каждом отдельном соединении. Метод обеспечивает максимальную динамику, но требует поддержки внешней авторизации со стороны ZTNA или прокси-слоя.
Мы рекомендуем начинать с первого или второго уровня интеграции на базе штатных API. Переходить к per-request авторизации стоит после того, как логика оценки доверия будет полностью отлажена, а сигналы начнут поступать стабильно и без ложных срабатываний.
Заключение
Построение архитектуры Zero Trust представляет собой переход от разовых проверок к непрерывному анализу контекста безопасности. Отдельные инструменты (IdP, ZTNA, SIEM) работают максимально эффективно, когда выступают поставщиками данных для центрального элемента: Policy Engine. Именно он обеспечивает гибкость и своевременную реакцию ИТ-инфраструктуры на возникающие риски.
Чтобы проект развивался успешно, мы советуем двигаться итеративно: избегать избыточно жестких ограничений на старте, использовать асинхронный обмен данными через кэширование и внедрять сложные уровни интеграции постепенно. Такой подход позволит выстроить прозрачную, надежную и удобную для пользователей систему защиты, адаптированную к реальным задачам вашего бизнеса.