«Работаешь удалённо, подключаешься к корпоративным сервисам, а ощущение такое, что сидишь в локальной сети. Где проходит граница безопасности? Её нет — она везде, вокруг каждого конкретного приложения или пользователя. Классический VPN мертв для защищённого доступа. Теперь важен контекст — кто ты, откуда и что хочешь сделать, а не просто факт подключения. ZTNA это про то, чтобы каждое подключение было самодостаточным, изолированным и проверенным заново. И про то, почему в эпоху гибридной работы модель нулевого доверия перестала быть опцией для «избранных» и стала минимально необходимой гигиеной».
От периметра к нулю: смена парадигмы защиты
Традиционная модель сетевой безопасности строилась на идее замкнутого периметра. Внутри него — доверенные пользователи и ресурсы, снаружи — недоверенный интернет. Файерволы, VPN-шлюзы и системы обнаружения вторжений охраняли эту границу. Эта модель была эффективна, когда активы компании, сотрудники и рабочие процессы были сосредоточены в одной локации.
Сегодня эта картина рассыпается. Сотрудники работают из дома, кафе и других стран. Данные и приложения мигрируют из корпоративных ЦОД в облачные сервисы. Само понятие «внутри сети» теряет смысл — пользователь может быть физически где угодно, а ресурс — находиться в публичном облаке. Периметр как единая линия обороны перестал существовать.
ZTNA — Zero Trust Network Access (сетевой доступ с нулевым доверием), это ответ на эту эволюцию. Она переворачивает старую модель с ног на голову. В основе лежит принцип: «никому не доверяй, проверяй всегда». Доверие не предоставляется по умолчанию на основании местоположения внутри сети. Оно должно постоянно подтверждаться на основе контекста — кто пользователь, с какого устройства, какое приложение запрашивает, каковы текущие риски.
Сердце ZTNA: как работает модель нулевого доверия
В отличие от VPN, который после аутентификации предоставляет доступ ко всей сети, ZTNA работает на более тонком уровне. Вместо «туннеля ко всему» создаются микросегменты доступа к конкретным приложениям или даже их отдельным компонентам.
Работает это через два ключевых архитектурных компонента:
- Контроллер политик (Policy Decision Point): Центральный мозг системы. Он принимает решение о предоставлении доступа, основываясь на политиках безопасности, контексте соединения и данных из других систем (например, SIEM, IAM).
- Шлюз доступа (Policy Enforcement Point): Распределённый элемент, который стоит непосредственно перед защищаемым приложением (или является его частью). Именно он выполняет решение контроллера — разрешает или блокирует соединение.
Пользователь никогда не устанавливает прямое сетевое соединение с приложением. Все запросы проходят через шлюз, который запрашивает решение у контроллера. Это позволяет скрыть приложение от интернета, оставив видимым только сам шлюз — принцип, известный как «темная сеть».
Чем ZTNA отличается от VPN на практике
Разницу можно почувствовать на конкретных примерах. Предположим, бухгалтер подключается к 1С из дома.
По старой схеме: сотрудник запускает VPN-клиент, проходит аутентификацию (например, по паролю или сертификату). После этого его устройство получает корпоративный IP-адрес и становится, с точки зрения сети, «внутренним». Теперь он может обращаться не только к серверу 1С, но и ко всем другим ресурсам внутри периметра — файловым хранилищам, камерам наблюдения, системам управления. Риск: если устройство скомпрометировано, злоумышленник получает широкий простор для манёвра.
По схеме ZTNA: сотрудник открывает браузер и переходит на портал корпоративных приложений или использует специальный агент. Происходит многофакторная аутентификация. Агент или портал запрашивают у контроллера политик доступ к конкретному приложению «Веб-интерфейс 1С». Контроллер оценивает контекст: пользователь подтверждён, но его устройство не соответствует последней политике безопасности (например, не установлено критическое обновление ОС). Вместо полного доступа пользователю предоставляется ограниченная сессия — например, только на просмотр данных без возможности их изменения. Прямого доступа к внутренней сети у его устройства нет.
Ключевые технические преимущества ZTNA
| Аспект | Традиционный VPN | ZTNA |
|---|---|---|
| Гранулярность доступа | Доступ к сети (широкий) | Доступ к конкретному приложению/сервису (микросегментированный) |
| Видимость ресурсов | Приложения видны в сети после подключения | Приложения скрыты («темная сеть»), видны только через шлюз |
| Оценка риска | Чаще статическая (на момент входа) | Динамическая, непрерывная (на основе контекста устройства, поведения) |
| Сетевая архитектура | Требует сложной маршрутизации, проброса портов | Работает поверх существующего интернет-соединения, не создаёт сложных туннелей |
| Масштабируемость | Зависит от пропускной способности VPN-шлюза | Распределённая, легко масштабируется в облаке |
ZTNA и российская регуляторика: точки пересечения
Внедрение подхода, основанного на нулевом доверии, не является прямым требованием таких нормативных документов, как 152-ФЗ или приказы ФСТЭК. Однако принципы ZTNA идеально ложатся на ряд ключевых требований защиты информации.
Например, требование о разграничении доступа (принцип минимальных привилегий) реализуется в ZTNA нативно. Пользователь по умолчанию не имеет доступа ни к чему, а получает его только к конкретному ресурсу на основе своей роли и текущего контекста. Это значительно снижает риски горизонтального перемещения злоумышленника в случае компрометации одной учётной записи.
Подход с постоянной проверкой доверия и оценкой состояния устройства (наличие актуального ПО, антивируса) также перекликается с требованиями по обеспечению безопасности технических средств. ZTNA-системы могут интегрироваться с решениями для управления мобильными устройствами (MDM/UEM) или агентами безопасности, получая от них данные для принятия решения.
Важный нюанс для российского рынка — вопросы локализации и сертификации. ZTNA-решение, используемое для защиты информации, составляющей государственную тайну, или персональных данных в государственных информационных системах, должно соответствовать требованиям регуляторов. Это означает необходимость выбора решений, входящих в реестр отечественного ПО, или прошедших необходимые процедуры оценки соответствия в ФСТЭК и ФСБ.
Архитектурные модели: агентская и сервисная
Существует два основных подхода к реализации ZTNA, выбор между которыми зависит от инфраструктуры и потребностей организации.
Агентская модель (Endpoint-Initiated). На устройство пользователя устанавливается лёгкий агент. Он отвечает за аутентификацию, сбор контекста (версия ОС, наличие вредоносного ПО) и установку зашифрованного туннеля к ближайшему шлюзу ZTNA. Эта модель хорошо подходит для доступа с управляемых корпоративных устройств (ноутбуков, смартфонов), так как даёт максимальный контроль и информацию о конечной точке.
Сервисная модель (Service-Initiated). Для доступа не требуется установка агента. Пользователь подключается через стандартный браузер или клиент. Агент или connector устанавливается не на устройство пользователя, а в той же сети, что и защищаемое приложение (например, в облаке или ЦОД). Он инициирует исходящее безопасное соединение с облачной платформой ZTNA. Пользователь затем подключается к этой платформе, которая проксирует трафик к connector’у. Эта модель идеальна для сценариев BYOD («принеси своё устройство») или доступа к приложениям со сторонних, неподконтрольных устройств.
С чего начать внедрение?
Переход к ZTNA редко бывает одномоментным. Это эволюционный процесс, который лучше начинать с пилотных проектов.
- Инвентаризация и классификация. Составьте список критичных приложений, к которым необходим удалённый доступ. Определите группы пользователей и их минимально необходимые права для работы.
- Выбор сценария. Начните с самого низкорискового, но показательного сценария. Например, предоставление доступа внешним подрядчикам к одной конкретной веб-системе. Это позволит отработать процессы без воздействия на основную массу сотрудников.
- Интеграция с существующей инфраструктурой. Убедитесь, что выбранное ZTNA-решение может работать с вашими системами аутентификации (Active Directory, FreeIPA, RADIUS), возможно, получать данные из SIEM или систем управления уязвимостями.
- Поэтапный переход. Не выключайте VPN сразу. Предоставьте доступ к части приложений через ZTNA, оставив VPN как запасной канал или для доступа к унаследованным системам, которые невозможно адаптировать. Постепенно мигрируйте потоки.
ZTNA — не просто ещё одна технология безопасности. Это фундаментально иной способ организации защищённого доступа в мире, где периметр исчез. Он требует переосмысления не только технологий, но и политик, и процессов. Однако результат — гибкая, адаптивная и значительно более устойчивая к современным угрозам среда — стоит этих усилий.