ZTNA (Zero Trust Network Access) — это модель управления доступом (не только удаленным!), которая проверяет каждого пользователя и устройство (включая установленное и работающее на нем ПО) и даёт доступ не к сети в целом, а к конкретным приложениям и ресурсам. Преимуществом реализации концепции ZTNA в NGFW-решении являются прежде всего возможности файрвола следующего поколения по фильтрации трафика и публикации ресурсов. При этом администратором удобно управлять доступом в одном решении, не прибегая к многочисленным интеграциям наложенных средств защиты.
Особенно важно управлять доступом в современных условиях, когда значительная часть успешных взломов российских компаний в 2025 году происходило с помощью атаки на удаленных сотрудников или подрядчиков (supply chain attack). Специалисты по безопасности испытывают особенную “боль” в контроле подрядчиков - не имея доступ к их ИТ-инфраструктуре и возможностей по мониторингу безопасности, применения политик, настроек и средств защиты.
В Ideco NGFW работа с моделью ZTNA реализована через NAC‑клиент (Network Access Control - контроль доступа к сети на уровне подключения устройства.) и тесную интеграцию с межсетевым экраном, что позволяет существенно безопаснее и гибче управлять доступом сотрудников и подрядчиков по сравнению с классическими VPN и периметровой защитой.
Что такое ZTNA по сути
ZTNA реализует принципы Zero Trust: «никогда не доверяй, всегда проверяй», где ни один запрос не считается доверенным по умолчанию, даже если он идёт из «внутренней» сети. Система оценивает идентичность пользователя, состояние устройства, контекст подключения (местоположение, время, риск) и только после этого выдаёт строго ограниченный доступ к нужному приложению, а не ко всей сети.
Ключевой момент: ZTNA разделяет понятия «доступ к сети» и «доступ к приложению» — пользователь может не видеть остальную инфраструктуру и не иметь возможности «гулять» по подсетям, как это обычно бывает при классическом VPN. Такой подход резко снижает риск бокового перемещения злоумышленника и уменьшает площадь атаки, поскольку большая часть ресурсов становится просто невидимой извне.
Критерий | Классическая VPN / защита периметра | ZTNA |
Модель доверия | Доверие после входа в периметр, внутренняя сеть априори более доверенная | «Никогда не доверяй, всегда проверяй» для каждого запроса и вне зависимости от расположения |
Объём доступа | Чаще даётся сетевой доступ в подсеть или целую сеть, пользователь видит множество хостов | Доступ к конкретным приложениям или сервисам, остальная инфраструктура скрыта |
Учет устройства | Обычно проверяются только учётные данные, устройство как таковое почти не оценивается | Анализируется состояние устройства (ОС, патчи, антивирус, настройки) перед выдачей доступа |
Контекст и риск | Политики в основном статичны (IP, сеть, группа), редко учитывают поведенческий риск | Доступ определяется динамической политикой с учётом контекста, поведения и уровня риска |
Боковое перемещение | При компрометации VPN‑учётки злоумышленник часто получает широкие возможности в сети | Микросегментация и доступ per‑session сильно ограничивают боковое перемещение |
Видимость ресурсов | Большая часть сервисов видна по сети (сканируется, зондируется) | Ресурсы «прячутся» за ZTNA‑шлюзом, IP и порты не экспонируются наружу |
ZTNA в задачах удалённого доступа
В условиях массовой удалёнки и активного использования подрядчиков основными рисками становятся утечки через скомпрометированные учётные записи и небезопасные устройства (старые патчи, отключённый антивирус, заражённые процессы). Классический VPN даёт такому устройству почти те же сетевые возможности, что и штатному корпоративному ПК в офисе, что делает любую ошибку валидации критичной.
ZTNA, напротив, постоянно проверяет, кто именно подключается, с какого устройства он заходит и соответствует ли оно требованиям ИБ — вплоть до блокировки или жёсткого ограничения доступа при несоответствии комплаенсу. Для подрядчиков и временных сотрудников это особенно важно: можно выдать им минимально необходимый доступ к одной системе или группе приложений, не открывая лишние сегменты сети.
Архитектура ZTNA в Ideco NGFW
В Ideco NGFW ZTNA реализуется как связка Ideco NAC Client, механизма проверки комплаенса и зонального файрвола (Zone‑Based Firewall), который задаёт политики доступа в зависимости от пользователя, устройства и типа VPN‑подключения. Клиент поддерживается для Windows, macOS и Linux, включая отечественные дистрибутивы, что критично для инфраструктур на базе российских ОС и сценариев происходящего импортозамещения (когда зачастую одновременно используются и западные и отечественные ОС).
Ideco Client умеет проверять соответствие удалённого хоста требованиям ZTNA (профиль комплаенса): это фундамент для реализации Zero Trust, когда доступ выдаётся только доверенным устройствам, и то в рамках минимально необходимого набора ресурсов. Политики файрвола завязаны на VPN‑зоны и могут по‑разному обрабатывать трафик site‑to‑site и client‑to‑site, что позволяет тонко разделять доступ филиалов и индивидуальных пользователей (в том числе в зависимости от геолокации последних).
Аутентификация и многофакторная защита
Ideco ZTNA поддерживает аутентификацию как из внешней сети, так и из локальной, с одинаково строгим подходом к доверию, без разделения на «внутренний» и «внешний» мир. Это означает, что даже сотрудник «в офисе» не получает привилегий только потому, что его источник в локальной подсети: он так же проходит проверку личности и комплаенса, как и удалённый пользователь.
С точки зрения многофакторной аутентификации Ideco позволяет строить двухфакторную схему через интеграцию с SMSAero, сервисом «Мул��тифактор», одноразовыми паролями TOTP и по RADIUS, что даёт возможность встроить ZTNA в уже существующую инфраструктуру аутентификации. Для ИТ и ИБ это прямая ценность: минимизация риска компрометации статических паролей, единое управление политиками входа (разумеется есть интеграция с Microsoft Active Directory, ALD Pro, Samba и FreeIPA) и возможность быстро усиливать требования к факторам аутентификации для чувствительных групп.
Проверка комплаенса устройства и управление зонами доверия
Ideco ZTNA позволяет проверять множество параметров устройства: версию ОС, наличие и статус антивируса, установленные обновления, наличие и состояние персонального фаервола, запущенные процессы и службы (например DLP-агент), а также наличие определённых ключей реестра. Эти проверки используются как для удалённых VPN‑подключений, так и для устройств внутри локальной сети, что полностью соответствует подходу Zero Trust — не доверять даже «внутренним» хостам без проверки.
Администратор может либо полностью запрещать доступ для не соответствующих комплаенсу устройств, либо разделять для них уровни доступа. Например, строгий комплаенс — полный доступ к рабочим приложениям, частичный — только к терминальному серверу, нарушители — только в зону обновления или в карантинную подсеть. Такое разграничение поддерживается в том числе за счёт выдачи IP‑адресов из разных подсетей в зависимости от уровня комплаенса, что позволяет внутренним “простым” файрволам применять правила уже к целым сетям, а не к отдельным пользователям.
Управление устройствами без привязки к пользователю (Device VPN)
Для ряда задач (администрирование серверов, доступ контроллеров домена, систем мониторинга и резервного копирования) важна не столько «личность пользователя», сколько доверенное устройство, которое должно иметь постоянный или сервисный доступ. Для этого в Ideco предусмотрен режим Device VPN — подключение устройств без пользовательского логина, когда доступ привязывается к самому хосту.
Уровень доступа таких подключений по‑прежнему регулируется файрволом Ideco NGFW: для сервисных устройств можно задать минимально необходимые маршруты и правила, исключая доступ к пользовательским сегментам и управляющим контурам. В ближайшей версии (Ideco NGFW Novum 22) к этому добавляется аутентификация по уникальному идентификатору устройства (Machine Certificate), что позволит строить до трёх факторов аутентификации: логин‑пароль, одноразовый код и машинный сертификат. Такой подход значительно усложняет подмену устройства и захват доступа к административным и сервисным каналам удалённого управления.
Сетевые протоколы, маршрутизация и устойчивость
Сетевой слой Ideco ZTNA использует безопасные VPN‑протоколы WireGuard и TLS; использование TLS поверх TCP позволяет обходить случаи, когда провайдер блокирует классические VPN‑протоколы, что особенно актуально для мобильных и региональных подключений. Для бизнеса это означает более предсказуемую доступность удалённых офисов и сотрудников даже в условиях фильтрации трафика провайдерами.
Поддерживается split tunneling — выдача разных маршрутов при подключении, когда через туннель идут только корпоративные ресурсы, а остальной Интернет остаётся локальным. Это снижает нагрузку на магистральные каналы и уменьшает задержки при работе с внешними сервисами, не жертвуя безопасностью критичных ресурсов. Дополнительно возможно резервирование интернет‑каналов для подключений к удалённому офису, что обеспечивает устойчивость к падению одного из провайдеров и повышает отказоустойчивость инфраструктуры.
Для случаев подключения десятков тысяч пользователей возможно настроить автоматическую балансировку подключений к целой “ферме” серверов с Ideco NGFW (обычно на одну “ноду” мы рекомендуем подключать не больше 5000 активных пользователей).
Гранулярный контроль источников и сессий
В настройках авторизации Ideco NGFW позволяет ограничивать источники подключений по геолокации (GeoIP), что даёт возможность, например, запретить вход из стран, с которыми компания не работает, или оставить только российские и соседние регионы. Это важный дополнительный слой защиты, уменьшающий пространство для атак с зарубежных ботнетов и анонимайзеров.
Также можно ограничивать длительность сессии, после чего требуется обязательная повторная аутентификация. Такое принудительное разавторизование уменьшает окно возможностей для злоумышленника при краже сессионных токенов или непосредственно работающих устройств и позволяет жёстко регламентировать длительность удалённой работы подрядчиков и временных сотрудников.
Предоставлять доступ возможно по приложениям, с профилем защиты IPS. Например, разрешив доступ к терминальному серверу, по порту 3389/TCP, с контролем L7 протокола RDP и проверкой сессии IPS с профилем для защиты от атак на RDP-протокол. Таким образом будет заблокировано все, не соответствующее стандарту протокола и использование эксплойтов направленных на взлом сервера.
Кроме того, Ideco Client работает и на самих терминальных серверах Microsoft, позволяя также “гранулярно” управлять доступом и создавать индивидуальную отчетность по пользователям терминальных серверов, абстрагировавшись от общего “железа”.
Планируемые улучшения: Machine Certificate и «защита начинается в DNS»
В релизе Ideco NGFW Novum 22 планируется полноценная аутентификация по уникальному идентификатору устройства (Machine Certificate), что выведет Device VPN и работу с доверенными хостами на новый уровень. Наличие машинного сертификата в связке с логином‑паролем и OTP создаёт трёхфакторную схему аутентификации, где компрометация только пароля или только устройства уже не даёт атакующему полноценного доступа.
Вторая важная новинка — подробное журналирование DNS‑запросов («защита начинается в DNS»). Современные атаки и вредоносное ПО в большинстве случаев завязаны на DNS‑уровень для связи с управляющими серверами и загрузки полезной нагрузки, поэтому детальный лог DNS‑активности позволяет раньше выявлять аномалии, неочевидные домены и утечки данных. В контексте ZTNA такие журналы дополняют картину доступа: администратор видит не только, к каким IP и портам ходит пользователь через туннель, но и какие доменные имена запрашивает его рабочее место, что облегчает расследование инцидентов и настройку проактивных политик блокировок.
Журналирование особенно эффективно в связке с модулем DNS Security, который с помощью алгоритмов машинного обучения выявляет DNS-туннелирование, обращение к командным центрам ботнетов и фишинговым доменам, что организовывает защиту еще до непосредственных подключений.
Преимущества Ideco ZTNA по сравнению с типичными российскими решениями
Российский рынок сетевой безопасности активно движется в сторону SASE и ZTNA, но во многих продуктах функции ZTNA пока ограничиваются усиленным VPN и базовым программно‑определяемым периметром, часто реализованным как надстройка над NGFW. Ideco ZTNA выгодно отличается тем, что ZTNA‑подход встроен непосредственно в Ideco NGFW, без необходимости отдельного ZTNA‑шлюза или облачного сервиса, что упрощает внедрение и снижает стоимость владения.
Сильным конкурентным преимуществом является акцент на проверке комплаенса как удалённых, так и локальных устройств: Ideco проверяет состояние хостов по единой логике и не разделяет «локальный» и «удалённый» доступ с точки зрения требований безопасности. Во многих решениях удалённого доступа основной упор до сих пор делается на аутентификацию пользователя, а состояние устройства учитывается ограниченно или только на уровне наличия агента, тогда как Ideco даёт гибкий механизм проверки ОС, патчей, антивируса, персонального фаервола и даже конкретных процессов и служб.
Отдельно стоит отметить кроссплатформенность с полноценной поддержкой Linux, включая отечественные дистрибутивы и интеграции с Astra Linux и FreeIPA, что критично для госсектора и компаний с политикой импортозамещения. В сочетании с возможностью выдавать разные подсети и маршруты в зависимости от уровня комплаенса это даёт ИБ‑и‑ИТ‑службам удобный инструмент микросегментации и построения сетей с многочисленными «микропериметрами».
Мы позволяем уже не просто строить стену вокруг замка, а можем приставить телохранителя к каждому жителю, для его защиты.
Практические советы по внедрению ZTNA на базе Ideco
Для системных администраторов и специалистов ИБ логичный путь внедрения ZTNA в Ideco NGFW выглядит так: сначала инвентаризировать ресурсы (сервисы, приложения, сегменты), затем классифицировать пользователей и подрядчиков по ролям и критичности и на этой базе определить уровни комплаенса и соответствующие им зоны доступа. На уровне Ideco NGFW это реализуется через профили проверки устройств, разные подсети/IP‑пулы для групп комплаенса, отдельные VPN‑зоны и правила файрвола, которые задают, кому, откуда и к чему можно подключаться.
Следующий шаг — поэтапный перевод пользователей и подрядчиков с чистого VPN на ZTNA‑подход: включать проверку комплаенса, MFA и ограничение сессий для новых групп, одновременно отслеживая журналы доступа и DNS‑логи для выявления аномалий. Для административных и сервисных подключений полезно вынести доступ в Device VPN с машинными сертификатами (после выхода Novum 22) и максимально сузить маршруты и правила доступа в этих зонах. Такой поэтапный сценарий позволяет минимизировать риски «боевого» внедрения и шаг за шагом уходить от устаревшей модели доверительного периметра к гораздо более управляемому ZTNA‑доступу.
