«Суть Zero Trust не в красивых презентациях с картинками и не в громких словах. Это инженерная дисциплина, где безопасность становится результатом непрерывного вычисления, а не результатом абстрактного ‘веры’. Нет доверия по умолчанию, есть доверие как итог: каждый запрос собирает доказательства, каждый ресурс требует свои доказательства.»
Почему Zero Trust вызывает разочарование на практике
Причина разочарования в глубоком несоответствии маркетинговых обещаний и архитектурных ограничений реальных систем. Продавцы предлагают ‘решение’ как конечный продукт — шлюз или платформу. Но модель радикального изменения логики доступа не устанавливается как коробочный продукт. Она требует пересмотра самой логики работы систем.
Основная проблема — совмещение идеи с legacy-инфраструктурой. Корпоративные базы данных, ERP, системы планирования построены на предположении, что внутренний сетевой трафик безопасен. Их архитектура предполагает фиксированные IP-адреса, статические учетные записи и простые ACL. Перевод таких систем на модель постоянной верификации, это не установка шлюза перед ними, это переписывание их логики доступа. Часто требуется изменение кода приложения, чтобы оно могло принимать не только IP и логин-пароль, но и контекстуальные атрибуты (токены с информацией о устройстве, геолокацию). Этот этап дорог, длителен и не создаёт видимого эффекта для руководства, поэтому его стараются избежать.
Маркетинг создаёт иллюзию, что двухфакторная аутентификация или VPN с ‘умным’ контролем уже соответствуют Zero Trust. Это неточность. Ключевое отличие — постоянство проверки. Вход в VPN — единичное событие. После него весь трафик считается доверенным. В Zero Trust каждый запрос внутри этой VPN-сессии, даже к внутреннему сервису, должен быть верифицирован отдельно, с учетом текущего состояния устройства, времени и объекта запроса. Если этого нет, это просто усиленный контроль периметра, а не переосмысление доверия.
Отсутствие четкого стандарта добавляет хаос. Российские регуляторы, включая ФСТЭК, говорят о необходимости построения систем защиты информации, основанных на современных принципах, но не дают точных технических требований к Zero Trust. Западные стандарты (NIST SP 800-207) часто не адаптированы к российским инфраструктурам, где распространены отечественные решения и специфические требования 152-ФЗ. Это приводит к ситуациям, где под одним термином скрываются микросегментация сети на уровне VLAN, усиленная аутентификация или просто сплошное шифрование трафика. Все эти элементы полезны, но не заменяют целостную архитектуру.
Что скрывается за термином: инженерная сущность доступа
Техническая суть модели, это превращение доверия в вычисляемую величину. Система не доверяет по умолчанию ни сети, ни пользователю, ни устройству. Она собирает доказательства для каждого запроса и вычисляет ответ.
Это требует структурированного контекста. Аутентификация (например, по токену) — лишь первый входной параметр. Система должна оценивать состояние устройства: не просто ‘устройство известно’, но ‘устройство соответствует политике’. Это включает проверку версии ОС, наличие обязательных обновлений безопасности, состояние шифрования диска, регистрацию в системе управления (MDM/EMM). Устройство с устаревшей ОС или без шифрования может быть заблокировано, даже если пользователь аутентифицирован корректно.
Контекст сессии — второй критичный параметр. Геолокация, время, тип сети. Запрос к критичной финансовой системе из публичной Wi-Fi сети в нерабочее время требует повышенного внимания, даже если все другие параметры в норме.
Третий параметр — сам объект доступа. Политика должна быть привязана к данным или сервису. Попытка скачать полный архив клиентской базы, это операция с высоким уровнем риска, даже если пользователь имеет право читать отдельные записи. Попытка изменить конфигурацию сетевого оборудования — другая операция. Система должна знать уровень чувствительности объекта и требовать соответствующие доказательства.
Архитектурно это означает декомпозицию периметра. Вместо единой ‘внутренней сети’ появляются сотни микропериметров вокруг каждого сервиса, базы данных или API. Доступ к каждому микропериметру контролируется независимо. Зоной доверия становится не сеть, а конкретная транзакция: ‘пользователь А на устройстве Б в состоянии В может выполнить операцию С над объектом Д’.
Реализация требует конкретных, часто уже существующих технологий:
- Механизмы взаимной аутентификации (mTLS), где сервер также проверяет клиента по сертификату.
- Сервисные меши (service mesh) для микросервисных архитектур, где каждый сервис проверяет соседа.
- Системы динамического тегирования данных, которые присваивают метки конфиденциальности файлам и их копиям на основе содержимого.
- Централизованные контроллеры политик (Policy Decision Point), которые принимают решение на основе данных из IAM, MDM, SIEM и других систем.
Именно эти компоненты, их интеграция и настройка политик составляют реальную работу, а не абстрактные ‘принципы’.
Как выглядит реальный Zero Trust-запрос изнутри
Рассмотрим типичный сценарий в российской корпоративной среде: сотрудник пытается получить доступ к внутреннему каталогу документов на портале.
1. Идентификация. Система проверяет токен SSO (например, на основе отечественного решения). Проверяется не только его валидность, но и метаданные: был ли он получен с доверенного устройства, соответствует время выдачи обычному графику работы.
2. Проверка устройства. Агент на устройстве (или данные из системы управления, например, ‘Kaspersky Security Center’ или аналоги) предоставляет статус: версия операционной системы (например, актуальная сборка Astra Linux или Windows с последними патчами), состояние шифрования диска (например, проверка наличия и активности ‘CryptoPro’ или аналоги), список установленных и разрешенных приложений. Если устройство не соответствует политике Compliance (например, отсутствует обязательное ПО для шифрования), запрос отклоняется на этом этапе.
3. Контекст сессии. Система оценивает: IP-адрес (внутренний корпоративный или внешний), геолокацию (определяется по IP), время запроса. Попытка доступа в 3 часа ночи из региона, где нет бизнес-активности компании, повышает балл риска.
4. Анализ поведения. Система сравнивает текущий запрос с историей пользователя. Обычно сотрудник обращается к каталогу для просмотра 1-2 документов в рабочее время. Попытка массового скачивания всех документов категории ‘Конфиденциально’ или использование нестандартного клиента (например, curl вместо браузера) будет флагом аномалии.
5. Оценка объекта. Что именно запрашивается? Система знает метки документов. Доступ к документу с меткой ‘Общедоступный’ требует минимальных проверок. Доступ к документу ‘Для внутреннего использования’ требует подтверждения состояния устройства. Доступ к документу ‘Строго конфиденциальный’ требует, помимо всего вышеперечисленного, возможно, второго фактора аутентификации в момент запроса (например, подтверждение через приложение).
6. Принятие решения. Все данные (1-5) поступают в Policy Decision Point. Он не просто проверяет правило ‘пользователь X имеет роль Y’. Он вычисляет совокупный балл риска на основе всех сигналов. Решение может быть: ‘Разрешить’, ‘Разрешить с записью в аудит для повышенного внимания’, ‘Заблокировать’, ‘Запросить дополнительную верификацию (2FA)’.
7. Логирование и адаптация. Каждая транзакция фиксируется не как ‘доступ разрешен’, а как полный протокол проверки: какие факторы были проверены, их статус, итоговый балл риска, принятое решение. Эти данные используются для аудита (в соответствии с требованиями 152-ФЗ о регистрации событий) и для обучения системы. Например, через месяц система узнает, что пользователь регулярно работает из домашнего IP в вечернее время, и такие запросы не считаются высокорисковыми.
Практические шаги без маркетинговой шелухи
Первый шаг — не покупка ПО, а инвентаризация и классификация. Нужен точный каталог цифровых активов: какие данные есть, где хранятся (локальные серверы, отечественные облака, файловые хранилища), кто владелец, уровень чувствительности. Без этого политики доступа будут либо слишком грубыми, либо неэффективными. Процесс классификации должен быть непрерывным, с автоматическим сканированием новых данных на ключевые фразы, шаблоны (например, паспортные данные) и присвоением меток.
Второй шаг — поэтапное внедрение, начинающееся с ‘чистого поля’. Не пытайтесь сразу внедрить модель на legacy ERP. Начните с нового облачного сервиса, современного API или внутреннего портала, разработанного с учетом современных стандартов (OAuth 2.0, OpenID Connect, поддержка mTLS). Здесь можно построить полноценный микропериметр, настроить политики, оценить влияние на производительность и подготовить команду.
| Этап | Цель | Пример действий |
|---|---|---|
| Инвентаризация и классификация | Создать базу для политик | Сканирование файловых хранилищ, присвоение меток конфиденциальности (публичный, внутренний, конфиденциальный, строго конфиденциальный). |
| Пилот на новом сервисе | Отработать технологию и политики | Внедрение контроллера доступа (например, шлюз) перед новым API, требование mTLS и проверки состояния устройства. |
| Интеграция с legacy | Расширить контроль без переписывания | Обрамление legacy-системы шлюзом верификации, который перехватывает запросы, выполняет проверки и затем проксирует их в систему. |
| Централизация управления политиками | Унифицировать правила для всей инфраструктуры | Развертывание центрального Policy Decision Point, интеграция с источниками данных (IAM, MDM, SIEM). |
Третий шаг — укрепление идентификации. Логин и пароль недостаточны. Идентификатор должен быть связан с устройством и его состоянием. Это требует инфраструктуры PKI для выпуска сертификатов устройств, интеграции с системами доверенной загрузки (например, отечественные решения) и развертывания систем управления устройствами (MDM/EMM) для постоянного мониторинга их состояния.
Критерии успеха должны быть практическими и измеряемыми:
- Время, необходимое для получения доступа к критичным данным (не должно увеличиваться катастрофически).
- Количество прямых обращений к базам данных минуя контрольные шлюзы (должно снижаться).
- Процент запросов, которые были автоматически отклонены или потребовали дополнительной верификации из-за аномалий (должен расти, показывая работу системы).
- Количество инцидентов, выявленных благодаря анализу контекста доступа (например, попытка доступа с устройства, не прошедшего Compliance).
Успех, это не количество приобретенных лицензий, а улучшение этих метрик.
Чего не хватает в типовых описаниях архитектуры
Баланс безопасности и удобства пользователя часто игнорируется. Система, требующая двухфакторной аутентификации для каждого открытия почтового клиента, быстро столкнется с сопротивлением сотрудников. Решение — градация требований. Для высокорисковых операций (доступ к финансовой отчетности, изменение конфигурации) — жесткие проверки. Для повседневных (чтение внутреннего портала) — прозрачная верификация, основанная на предварительно проверенном состоянии устройства и сети, без дополнительных действий пользователя. Система должна быть умной и работать в фоне.
Производительность — критичный аспект для российской практики, где высоконагруженные внутренние системы (биржевые, транзакционные) не терпят больших задержек. Добавление многоступенчатой верификации создает латентность. Решение включает оптимизацию: кэширование результатов проверки состояния устройства, использование локальных прокси, которые выполняют часть проверок, предварительную аттестацию сессии. Без этого система не масштабируется на тысячи запросов в секунду.
Интеграция физического и цифрового контекста — слабое место большинства проектов. События физического мира (вход в серверную комнату, подключение к порту в сети) должны влиять на цифровой уровень доверия. Например, если сотрудник физически находится в охраняемом датацентре, его цифровой запрос к системе управления этим центром может иметь сниженный уровень риска. Обратно, попытка удаленного административного доступа из неизвестного региона должна вызывать повышенную проверку, даже если цифровые токены валидны. Эти системы часто разрознены.
Отказоустойчивость системы верификации обязательна. Если центральный Policy Decision Point или система оценки риска отключатся, весь доступ может быть заблокирован. Необходимы планы аварийного режима: возможность временного перехода на политики, основанные только на базовой аутентификации, резервные каналы управления, жестко контролируемые оффлайн-ключи для разблокировки критичных сервисов. Без этого внедрение создает риск для непрерывности бизнеса.
Будущее за защитой транзакций, а не за модным словом
Термин ‘Zero Trust’ уже сильно размыт маркетингом. Его реальное содержание — Continuous Adaptive Risk and Trust Assessment (CARTA), то есть непрерывная и адаптивная оценка риска и доверия. Это более точное название: система не просто ‘не доверяет’, она постоянно вычисляет уровень доверия на основе меняющегося контекста и адаптирует политики.
Следующий логический шаг — Confidential Computing, защита данных ‘в обработке’. Это уже не только о контроле доступа, но о защите самого процесса вычислений. Использование технологий Trusted Execution Environment (TEE) позволяет выполнять код в изолированной, зашифрованной области памяти, недоступной даже для администратора ОС или гипервизора. Для российского рынка это означает совмещение требований регуляторов о локализации обработки данных с технической возможностью их защиты на аппаратном уровне даже в облачных средах.
Финальная цель — сделать процесс верификации невидимым и непрерывным, подобно проверке цифровой подписи. Каждая транзакция в системе должна автоматически и незаметно проверяться на основе совокупности доказательств: кто, на чем, в каком состоянии, что пытается сделать, с каким объектом. Никакого предварительного доверия по умолчанию. Доверие, это всегда результат, вычисленный системой в момент запроса.
Для российского IT и регуляторики это означает переход от проверки ‘периметра’ и ‘статуса сотрудника’ к проверке каждой операции. Это сложнее, но ближе к реальной цели защиты информации, как она формулируется в 152-ФЗ: обеспечение конфиденциальности и целостности данных при их обработке.