Что такое ZTNA? Доступ с нулевым доверием вместо VPN

Что такое ZTNA? Zero Trust Network Access (доступ к сети с нулевым доверием) — это модель удалённого доступа, которая подключает пользователя не к сети, а только к тому приложению, на которое у него есть права, и в каждой сессии заново проверяет личность, состояние защищённости устройства и контекст. Она заменяет классический подход VPN «проверить один раз и впустить во всю сеть».

Что такое ZTNA и что означает нулевое доверие?

ZTNA применяет к удалённому доступу принцип «ни пользователю, ни устройству, ни сетевому расположению не доверяют по умолчанию». Сначала пользователь подтверждает личность, затем устройство проходит проверку состояния защищённости, и только после этого открывается соединение с тем единственным приложением, которое разрешает политика, и только на эту сессию. Остальная сеть для пользователя остаётся невидимой.

Нулевое доверие — это не продукт, а архитектурный подход. Эталонное определение дано Национальным институтом стандартов и технологий США в публикации NIST SP 800-207 Zero Trust Architecture. В упрощённом виде её основные принципы таковы:

• Все источники данных и вычислительные сервисы считаются ресурсами; защищать нужно всё — от принтера до сервера ERP.
• Любое взаимодействие защищается независимо от сетевого расположения; запрос из внутренней сети столь же подозрителен, как запрос из интернета.
• Доступ предоставляется на уровне сессии и по принципу минимальных привилегий.
• Решение о доступе принимается на основе динамической политики, которая учитывает личность, приложение, состояние устройства и поведенческие сигналы в совокупности.
• Организация отслеживает целостность и состояние защищённости всех активов, которыми владеет и которые использует.
• Аутентификация и авторизация строго выполняются до предоставления доступа и при необходимости повторяются.
• Собранные данные о сети, активах и трафике используются для постоянного улучшения уровня защищённости.

В том же документе логическая архитектура описывается тремя компонентами: Policy Engine (механизм политик), который принимает решение о доступе; Policy Administrator (администратор политик), который превращает это решение в команду на установление соединения; и Policy Enforcement Point (точка применения политик), которая открывает и закрывает путь между пользователем и ресурсом. ZTNA — это такая архитектура, применённая к удалённым и гибридным сотрудникам. Она решает ту же задачу, что и VPN, — безопасно подключить человека вне офиса к внутреннему приложению, — но на основе другой модели доверия.

Почему классического VPN уже недостаточно?

Классический VPN для удалённого доступа один раз проверяет пользователя и затем делает его участником внутренней сети; доступ выдаётся к сегменту сети, а не к приложению. Такое неявное доверие превращает одну скомпрометированную учётную запись в плацдарм для горизонтального перемещения, а доступный из интернета портал VPN становится постоянной мишенью для атакующих.

VPN несёт в себе допущения эпохи, в которую он создавался: приложения находятся в центре обработки данных, пользователь работает на корпоративном устройстве, а внутри сети безопасно. В современной гибридной модели работы ни одно из этих трёх допущений не выполняется. Чаще всего в проектах мы видим четыре слабых места:

• Слишком широкий доступ: пользователь, которому нужна только бухгалтерская программа, после установления туннеля в большинстве инсталляций видит и весь серверный VLAN.
• Однократная проверка: после входа туннель остаётся открытым, даже если устройство заражено или пользователь перешёл в другую сеть.
• Слепота к устройству: классический VPN не знает, работает ли на подключённом устройстве антивирус, обновлена ли операционная система, зашифрован ли диск.
• Открытая поверхность атаки: портал VPN по определению доступен всем; уязвимость в нём ставит под угрозу всю организацию до выхода исправления.

Эта ситуация изменила и продуктовую стратегию Fortinet. Согласно примечаниям к выпуску Fortinet, начиная с FortiOS 7.6.3 туннельный режим SSL VPN удалён и заменён на IPsec VPN, который может работать в том числе через TCP-порт 443; существующие настройки при обновлении не переносятся. На некоторых моделях начального уровня удаление началось в более ранних версиях, поэтому сверьтесь с примечаниями к выпуску для своей модели. Шаги перехода мы собрали в статье об удалении SSL VPN в FortiOS 7.6 и плане миграции, а наше руководство по настройке VPN на FortiGate остаётся хорошей отправной точкой для понимания текущей конфигурации.

Как работает ZTNA?

В ZTNA решение о доступе зависит не от сетевого расположения, а от трёх входных данных: подтверждённой личности пользователя, текущего состояния защищённости конечного устройства и запрашиваемого приложения. Точка принятия решений формирует политику; точка применения открывает соединение только с целевым приложением, только на эту сессию и закрывает его при изменении условий.

Пошаговый процесс у большинства производителей похож:

1. Запрос: пользователь открывает внутреннее приложение. Агент ZTNA на устройстве или, при доступе через браузер, обратный прокси перехватывает запрос.
2. Аутентификация: пользователь проверяется по корпоративному каталогу (Active Directory, Entra ID, SAML-провайдер); многофакторная аутентификация является стандартной частью этого шага.
3. Состояние устройства: агент сообщает версию операционной системы, статус антивируса, шифрование диска, членство в домене и подобные признаки; из них формируются метки (теги).
4. Решение по политике: если сочетание «пользователь из группы Финансы + актуальное устройство под управлением компании + приложение ERP» соответствует правилу, доступ разрешается, иначе — запрещается.
5. Соединение: трафик передаётся через шлюз приложений только к целевому приложению. Приложение никогда не публикуется напрямую в интернет, а пользователь не может маршрутизировать трафик в остальную сеть.
6. Непрерывная оценка: если состояние устройства ухудшается, например отключается антивирус, метка снимается и сессия завершается в соответствии с политикой.

У такого процесса два следствия. Во-первых, приложения становятся «тёмными»: при внешнем сканировании не видно ни открытого порта, ни страницы входа. Во-вторых, механизмы защиты привязываются к соединению, а не к человеку; один и тот же пользователь с корпоративного ноутбука получает доступ к ERP, а с личного планшета видит только веб-интерфейс почты. В классическом VPN такое разграничение можно построить лишь сложными наборами правил, и обычно не полностью.

Сравнение VPN и ZTNA

Главное различие между VPN и ZTNA — модель доверия: VPN предоставляет доступ к сети и проверяет один раз, ZTNA предоставляет доступ к приложению и проверяет непрерывно. В таблице ниже сопоставлены десять критериев, о которых руководители спрашивают чаще всего; каждая строка отражает типичное поведение, которое мы наблюдаем в проектах.

Таблица показывает, что ZTNA — не «улучшенный VPN», а другая модель доверия. При этом VPN не умер: для туннелей IPsec между филиалами, некоторых устаревших UDP-приложений и сценариев вроде VoIP IPsec VPN по-прежнему остаётся правильным инструментом. В грамотном дизайне оба решения какое-то время сосуществуют: ZTNA обслуживает доступ пользователей, а IPsec — связь между площадками и трафик-исключения.

Архитектура Fortinet ZTNA: FortiClient, EMS и шлюз приложений FortiGate

Архитектура Fortinet ZTNA состоит из трёх компонентов: агента FortiClient ZTNA на конечном устройстве, FortiClient EMS, который превращает личность и состояние устройства в метки, и FortiGate в роли шлюза приложений ZTNA, применяющего решение о доступе. Эта схема появилась в FortiOS 7.0; существующие профили IPS, антивируса и веб-фильтрации FortiGate применяются и к трафику ZTNA.

Распределение ролей между компонентами выглядит так:

В документации Fortinet процесс описан так: FortiGate подключается к EMS через коннектор Security Fabric и автоматически синхронизирует метки ZTNA; EMS мгновенно передаёт изменения меток по постоянному соединению. Метки состояния защищённости основываются на таких проверках, как установлен ли антивирус, какая версия операционной системы, выполнен ли вход устройства в домен, запущен ли определённый процесс, какое значение имеет ключ реестра, каков уровень уязвимости устройства и есть ли на нём известная CVE. FortiGate может использовать эти метки в правилах ZTNA, политиках межсетевого экрана и политиках NAC. Базовые шаги настройки описаны в руководстве администратора FortiOS от Fortinet.

Доступ предоставляется в двух формах. HTTPS access proxy публикует веб-приложения, а также упакованные в HTTPS сессии RDP, SSH и VNC через браузер или агент. TCP forwarding для невеб-приложений клиент-сервер позволяет FortiClient перехватывать запросы к определённым адресам и портам и передавать их на шлюз приложений. Так, например, клиент ERP или инструмент администрирования базы данных работают без сетевого туннеля. Если в ту же модель нужно перевести трафик филиалов и выход в интернет, логичным продолжением этой статьи будет наш материал о SASE и подходе FortiSASE.

Как спланировать переход с VPN на ZTNA?

Переход с VPN на ZTNA — это не переключение за одну ночь, а поэтапная программа из инвентаризации, идентификации, подготовки конечных устройств и пилотного приложения, в течение которой VPN какое-то время работает параллельно. В наших проектах больше всего времени уходит не на технологию, а на выяснение того, какому пользователю какое приложение действительно нужно.

1. Инвентаризация приложений и пользователей: составьте список всех приложений, доступных через VPN, их протоколов (HTTPS, RDP, SSH, базы данных, общие папки) и групп пользователей. Журналы VPN — самый честный источник такой инвентаризации.
2. Инфраструктура идентификации: порядок в каталоге, понятная структура групп и многофакторная аутентификация — обязательные условия ZTNA. Бесхозные учётные записи и группы, в которые входят все, обесценивают любую политику.
3. Подготовка конечных устройств: устанавливается FortiClient EMS, агент сначала распространяется на существующие устройства, метки состояния собираются в режиме наблюдения. Состояние устройства опирается на надёжный слой защиты конечных точек; какой именно слой нужен, мы разобрали в статье о различиях между EDR, XDR и MDR.
4. Пилот: начните с одного-двух веб-приложений и добровольной группы пользователей. Этот этап с низким риском проверяет логику политик и удобство работы.
5. Расширение: с помощью правил TCP forwarding добавьте RDP, SSH и клиент-серверные приложения; для каждого приложения отдельно ответьте на вопрос «кто и с каким состоянием устройства». Для компактного набора правил здесь действуют те же принципы управления политиками FortiGate.
6. Работа с исключениями: для UDP-приложений и устаревших систем, которые ZTNA не покрывает, сохраните IPsec VPN с узкой областью действия.
7. Отключение портала VPN: когда охват пользователей и приложений завершён, отключите старый портал и подключите журналы доступа к централизованному управлению журналами.

Эта последовательность подходит и организациям, которые после FortiOS 7.6 вынужденно отказываются от SSL VPN; единственное отличие в том, что первый шаг обычно совпадает с графиком обновления версии.

Реалистичен ли ZTNA для малого и среднего бизнеса?

ZTNA подходит не только крупным корпорациям. Компания малого или среднего бизнеса с уже установленным FortiGate может, добавив FortiClient и EMS, включить шлюз приложений ZTNA на том же устройстве. Стоимость определяется количеством конечных устройств, тем, будет ли EMS работать в облаке или локально, и тем, нужен ли FortiSASE для трафика филиалов; конкретная сумма появляется только в коммерческом предложении после обследования.

По нашему опыту, в малых и средних компаниях ZTNA особенно полезен в трёх ситуациях. Первая — внешние подрядчики и консультанты по бухгалтерии или праву: выдать им VPN означает открыть всю сеть, а с ZTNA они видят только нужное приложение. Вторая — контроль доступа к персональным данным: минимальные привилегии и подробные журналы доступа соответствуют матрице полномочий и ведению журналов, описанным в Руководстве по безопасности персональных данных турецкого Совета по защите персональных данных (KVKK); при условии, что вы сверитесь с актуальным законодательством и официальным руководством, ZTNA обеспечивает техническую реализацию этих мер. Третья — риск программ-вымогателей: сценарий, при котором злоумышленник входит в сеть под учётной записью VPN и добирается до сервера резервного копирования, в ZTNA исключён самой архитектурой.

Sora Yazılım работает как независимый партнёр по решениям: на ознакомительной встрече мы изучаем ваш текущий FortiGate, профили пользователей и перечень приложений, вместе определяем границы между ZTNA и IPsec, выполняем внедрение и при желании продолжаем сопровождение политик в формате управляемой услуги.

Часто задаваемые вопросы

Полностью ли ZTNA заменяет VPN?

Для удалённого доступа пользователей к приложениям — да; в этом сценарии ZTNA даёт более узкие права и лучшую прозрачность. Для связи между площадками, устаревших UDP-приложений и некоторых сценариев VoIP IPsec VPN остаётся актуальным. В большинстве организаций оба решения какое-то время работают вместе.

Обязательно ли для ZTNA нужен программный агент?

Нет. Для веб-приложений возможен безагентный доступ через браузер; однако для проверки состояния устройства и для невеб-приложений агент необходим. В архитектуре Fortinet это FortiClient, а данные о состоянии превращаются в метки через FortiClient EMS.

Нужна ли дополнительная лицензия для ZTNA на FortiGate?

Шлюз приложений ZTNA — встроенная функция FortiOS. Для конечных устройств нужны лицензии FortiClient, а для центра — FortiClient EMS. Поскольку состав лицензий зависит от версии и пакета, его следует проверить по актуальной документации Fortinet и точно определить на этапе коммерческого предложения.

В чём разница между ZTNA и SASE?

ZTNA — это отдельная функция, регулирующая безопасный доступ пользователей к внутренним приложениям. SASE — более широкая концепция, объединяющая ZTNA с защищённым веб-шлюзом, CASB, межсетевым экраном как услугой и SD-WAN и предоставляющая их из облака. FortiSASE включает ZTNA как часть этого целого.

Как ZTNA помогает соблюдать требования к защите персональных данных?

ZTNA ограничивает доступ к приложениям с персональными данными по личности, устройству и приложению и фиксирует каждое обращение. Это согласуется с матрицей полномочий и ведением журналов из руководства KVKK по безопасности данных; однако соответствие требованиям — это комплекс мер, сверьтесь с актуальным законодательством и официальным руководством.

Будут ли у пользователей простои во время перехода?

При правильном планировании — нет. На пилотном этапе VPN остаётся включённым, пользователи переводятся на ZTNA по одному приложению, а при проблемах могут вернуться к VPN в тот же день. Риск простоя выше всего в проектах, где агент массово распространяют до подготовки инфраструктуры идентификации.

Заключение

ZTNA меняет модель доверия удалённого доступа: приложение вместо сети, непрерывная оценка вместо однократной проверки, невидимые снаружи ресурсы вместо открытого портала. Рамка, заданная NIST SP 800-207, у Fortinet воплощается в связке FortiClient, EMS и шлюза приложений FortiGate; удаление туннельного режима SSL VPN в FortiOS 7.6.3 поставило этот переход в календарь многих организаций. Правильный порядок — инвентаризация, идентификация, конечные устройства, пилот и поэтапное расширение.

Чтобы вместе оценить, как перевести вашу текущую VPN-инфраструктуру на ZTNA, запишитесь на бесплатную ознакомительную встречу; мы подготовим предложение по подходящему объёму FortiClient, EMS и FortiSASE.