Сравнение ZTNA-продуктов: UX, логи, сегментация, MFA/SSO

Зачем вообще сравнивать ZTNA и что именно болит

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

Проблема в том, что «VPN работает» часто означает только одно: туннель поднимается. А дальше начинаются ежедневные боли: логины по несколько раз в день, странные разрывы, медленная работа приложений. У ИБ при этом нет ясной картины, кто куда ходил и почему доступ вообще был разрешен. Еще хуже, когда через VPN пользователь фактически попадает «в сеть», и одно ошибочное правило дает больше прав, чем планировалось.

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

Хороший ориентир: ZTNA должен давать доступ не «в сеть», а к конкретным приложениям и только при выполнении условий (пользователь, устройство, контекст, политика). И при этом не превращать обычный рабочий день в борьбу с подключением.

Перед пилотом и расчетом бюджета соберите ожидания бизнеса и ИБ. Достаточно короткого набора вопросов: кто подключается (сотрудники, подрядчики, филиалы) и к каким приложениям; что считается нормальным опытом (время входа, число шагов, частота повторной аутентификации); какие инциденты вы реально расследуете и какие поля обязаны быть в логах; где проходит граница доступа (по ролям, по приложениям, по данным, по сегментам); какие SSO/MFA у вас сейчас и что критично при интеграции.

Если вы работаете с интегратором, который внедряет разные платформы, полезно сразу зафиксировать критерии успеха пилота. Тогда выбор будет не «по ощущениям», а по проверяемым сценариям. В проектах по инфраструктуре и ИБ такой подход применяют и команды уровня GSE.kz, и это обычно экономит время на спорных трактовках результатов.

Опыт пользователя: как проверить без субъективщины

Пользовательский опыт в ZTNA легко испортить мелочами: лишний шаг входа, непонятная ошибка, задержка на старте сессии. Чтобы сравнение ZTNA-продуктов не превратилось в спор «мне кажется», заранее договоритесь о сценариях и о том, что именно измеряете.

Мини-набор сценариев

Возьмите 4-6 задач, которые люди делают каждый день, и прогоните их на каждом решении одинаково. Хорошо, если участвуют разные роли: бухгалтер, инженер, админ, сотрудник поддержки.

Обычно хватает такого набора: вход во внутреннее веб-приложение (портал, CRM, внутренний сайт), подключение по RDP (Windows-сервер или VDI), подключение по SSH (Linux-хост или оборудование), доступ к файловому ресурсу (SMB/файловый сервер) или корпоративному хранилищу, а также день, где смешаны «SaaS плюс внутренний ресурс», чтобы увидеть поведение SSO и политик.

Фиксируйте одинаковые условия: один и тот же ноутбук, один и тот же аккаунт, одинаковые политики. Иначе вы сравните не продукты, а разные настройки.

Как фиксировать впечатления цифрами

Собирайте простые измерения, которые можно повторить, а не только отзывы. Удобно попросить тестировщиков записать экран и заполнить короткую форму после каждого сценария.

Что имеет смысл мерить: сколько шагов до начала работы (от клика до открытого приложения), время до первой «полезной» картинки (страница загрузилась, открылся рабочий стол, появился терминал), сколько раз за день запросили повторную аутентификацию, насколько понятны ошибки (ясно ли, что делать дальше), насколько стабилен клиент (зависания, разрывы сессий, навязчивые обновления и уведомления).

Отдельно проверьте смену сети: офисный Wi‑Fi, домашний интернет, мобильный хотспот. Нормальный ZTNA переживает переключение без «магии»: сессия либо аккуратно восстанавливается, либо честно просит повторный вход и объясняет причину.

Практический тест: сотрудник уходит с ноутбуком из офиса, по дороге открывает RDP, затем дома продолжает работу. Если клиент бесконечно переподключается или каждый раз требует MFA «просто потому что», в реальной жизни начнутся обходные пути и жалобы в ИТ.

Если пилот ведет интегратор, попросите заранее включить «тихий режим» там, где это возможно: минимум уведомлений и обновлений в рабочее время. Это часто влияет на принятие решения не меньше, чем скорость.

Журналы и расследования: что должно быть видно ИБ

Логи в ZTNA нужны не для галочки. Когда сотрудник не может открыть сервис, когда подозрительно меняется география входов или когда регулятор просит отчет, вы должны быстро понять: кто пытался попасть, куда именно, по каким правилам и почему получилось (или нет). В любом сравнении ZTNA-продуктов этот пункт быстро отделяет удобные решения от тех, где расследование превращается в квест.

Хороший уровень начинается с того, что каждое подключение оставляет понятный след: пользователь, приложение, ресурс, время, результат и политика. Важно, чтобы данные были единообразны для веб-приложений, RDP/SSH, внутренних API и нестандартных портов.

На пилоте стоит требовать минимум полей: кто (учетная запись, группа/роль, ID сессии), куда (приложение/коннектор, целевой хост, порт, метод для веб), когда и как долго (старт, длительность, тайм-ауты), с какого устройства (тип, OS, идентификатор, управляемость, IP и гео), по какой политике (имя правила, условия, итог allow/deny).

Критично, насколько быстро вы можете искать инциденты. Проверьте не просто «есть ли фильтры», а можно ли собрать цепочку событий по ID сессии, пользователю и приложению, а затем выгрузить данные в удобном формате для расследования или хранения. Отдельно оцените корреляцию шагов: аутентификация, проверка устройства, применение политики, установление туннеля или прокси-сессии.

Самая болезненная ситуация - отказ в доступе без объяснений. При deny должна быть видна конкретная причина и место, где «сломалось»: не пройдена MFA, не та группа в IdP, устройство не соответствует требованиям, нет маршрута к коннектору, приложение не опубликовано, сертификат не доверен. Хороший признак - когда в логе отражено точное условие, которое не совпало, а не абстрактное «policy denied».

Для аудита важны отчеты не только по доступам, но и по изменениям. Попросите показать, кто и когда менял политики, коннекторы, группы приложений и исключения, и можно ли восстановить историю. В организациях с повышенными требованиями (госструктуры, финсектор, медицина) это часто важнее «красивого дашборда».

Сегментация доступа: как не получить новый VPN под другим именем

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

При сравнении ZTNA-продуктов полезно сначала описать не роли, а приложения. Не «доступ в офис», а «доступ к CRM», «к бухгалтерии», «к админке сервера», «к RDP на конкретные хосты». Чем точнее описание, тем меньше соблазн выдать широкий доступ «на всякий случай».

Как описывать приложения, чтобы политика была управляемой

На практике приложение почти всегда определяется набором признаков: FQDN, IP, порт и тип трафика. Начинайте с того, как пользователь реально подключается, и фиксируйте это в политике. Для веб-приложения обычно достаточно FQDN и HTTPS. Для администрирования чаще нужен RDP/SSH к ограниченному списку хостов.

Проверьте, умеет ли решение аккуратно работать в «серых» случаях: одно приложение на нескольких доменах, разные окружения (prod/test), старые системы без понятного DNS, а также приложения, которые внезапно обращаются «внутрь» к дополнительным сервисам.

Микросегментация без боли для поддержки

Микросегментация в жизни - это «минимум прав плюс понятные исключения». Рабочая логика простая: доступ дается к приложению, а не к подсети; редкие задачи оформляются как временные доступы; добавляется контекст (управляемое устройство, актуальный агент, нужный регион, базовые требования); «пользовательский» и «админский» доступ разделяются разными политиками; боковые перемещения ограничиваются конкретными хостами и портами.

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

Интеграция с MFA и SSO: что проверить на практике

SSO и MFA в ZTNA часто выглядят одинаково на презентациях, но в пилоте быстро всплывают детали: как проходит вход, где ломаются сценарии и кто потом будет это поддерживать. В сравнении ZTNA-продуктов здесь важно не «есть ли галочка», а как ведет себя связка IdP, каталоги и политики доступа.

Сначала определите, какая модель SSO вам нужна. Если у вас уже есть единый провайдер учетных записей, проверьте поддержку SAML или OIDC именно в том виде, как это принято у вас (разные домены, несколько организаций, федерация с партнерами). Важно и то, как решение работает с заявками на доступ: можно ли привязать доступ к приложению к группе, роли или атрибуту пользователя, а не к ручному списку.

Практические проверки в пилоте

Попросите 5-10 реальных пользователей пройти одинаковые сценарии входа и зафиксируйте, что происходит на каждом шаге. Например: вход с корпоративного ноутбука и с личного устройства (где включается SSO, где требуется повторная авторизация), поведение MFA (как часто спрашивает второй фактор, можно ли «запомнить устройство» и на каких условиях), восстановление доступа при потере телефона/токена (кто подтверждает и сколько времени занимает), смена роли (когда реально меняются права в ZTNA после обновления групп или атрибутов), доступ к нескольким приложениям подряд (будет ли единый вход или постоянные запросы MFA).

После этого отдельно разберите интеграцию с каталогами. Хороший признак - когда политики можно строить на динамических атрибутах (подразделение, должность, тип сотрудника), а не только на статических группах. Если источников идентичности несколько, заранее уточните, как будут жить дубли, временные учетные записи и сервисные аккаунты.

Гости и подрядчики без боли

Подрядчики и гостевые пользователи обычно ломают «идеальную» схему. Проверьте, сможете ли вы выдавать доступ на ограниченный срок и без лишних прав, а потом гарантированно отзывать его одним действием. Важно, чтобы был понятный процесс согласования и чтобы в журналах оставались следы: кто запросил доступ, кто утвердил, что именно было выдано и когда отозвано.

Простой пример: в больнице или вузе, где используется парк рабочих мест и серверов, подрядчик приходит на проект на две недели. В пилоте должно быть ясно, как вы выдадите доступ ровно к одному внутреннему сервису, с MFA, только в рабочие часы, и как убедитесь, что после завершения работ доступ исчезнет везде, включая активные сессии. Если параллельно закупается или обновляется «железо», удобнее, когда поставщик и интегратор могут закрыть обе части: например, GSE.kz производит компьютеры и серверы в Казахстане и при этом оказывает услуги системной интеграции и поддержки.

Устройства и контекст: кому давать доступ и на каких условиях

ZTNA часто выбирают как замену VPN, но реальный выигрыш появляется только тогда, когда решение учитывает контекст устройства. Иначе вы переносите «плоский» доступ в новую оболочку. В сравнение ZTNA-продуктов обязательно включайте тесты с разными типами устройств и ролей.

Первое, что стоит проверить, - какие именно проверки устройства доступны и что происходит при несоответствии. Обычно смотрят на версию ОС и патчи, наличие антивируса или EDR и их актуальность, шифрование диска, состояние фаервола и базовые политики безопасности, принадлежность устройства (корпоративное или личное).

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

Дальше - разделение корпоративных устройств и BYOD. На корпоративном ноутбуке логично требовать больше (агент, EDR, шифрование, управляемые настройки). Для личных устройств разумнее ограничивать доступ: давать только браузерные приложения, включать изоляцию сессии, запрещать доступ к внутренним файловым ресурсам и админ-консолям.

Доступ без агента выглядит заманчиво, но у него обычно меньше сигналов о состоянии устройства. Его часто оставляют для узких сценариев (порталы, внутренние веб-системы, разовые подрядчики). Для RDP/SSH и чувствительных сегментов агент чаще всего обязателен.

Проверьте онбординг: насколько быстро человек начинает работать и сколько шагов нужно ИТ. На пилоте удобно замерить время установки и первого входа, число обращений в поддержку, поведение обновлений клиента, работу в роуминге (дом, офис, мобильный интернет) и возможность «починить» доступ без переустановки.

Небольшой сценарий для теста: бухгалтерия работает с финансовой системой, а подрядчику нужен доступ только к одному сервису на две недели. Корпоративным ПК с включенным шифрованием и актуальными патчами дайте полный доступ по роли. Подрядчика пустите только через браузер и только к нужному приложению, без возможности перейти в другие сегменты. Если это сложно настроить или поддерживать, в проде будет еще тяжелее.

Производительность и надежность: как не испортить рабочий день

Производительность ZTNA ощущается не в отчете, а в мелочах: сколько времени проходит от клика до открытия приложения, как часто «подвисает» вход и что происходит при сбое на маршруте. Для сравнения решений важно измерять одно и то же, в одинаковых условиях.

Задержки обычно появляются в трех местах. Первое - авторизация: цепочка IdP -> MFA -> политики доступа -> выдача сессии может добавить лишние секунды, особенно если устройство не «узнано» или включены проверки соответствия. Второе - первое открытие приложения: если коннектор далеко от приложения или маршрут до точки присутствия неудачный, старт будет медленным даже при хорошем канале. Третье - интерактивные сессии (RDP/VDI): там заметны не средние значения, а микрозадержки и потери пакетов, из-за которых «липнет» курсор и рвется звук.

Для филиалов и удаленных регионов решают не обещанные мегабиты, а география и резервирование. Проверьте, куда реально уходит трафик, есть ли близкие точки присутствия и что будет при проблеме у одного провайдера. Пример: головной офис в Астане, филиал в Уральске, приложение в локальном дата-центре. Один продукт может вести филиал через ближайший узел и держать стабильный RDP, а другой - уводить трафик по более дальнему маршруту, и пользователи начнут жаловаться.

Надежность - это понятные сценарии отказа. Заранее разыграйте ситуации: IdP недоступен, MFA временно не отвечает, пропала связь с одной точкой присутствия, отвалился коннектор рядом с приложением. Важно понять, что увидит пользователь (внятную ошибку или бесконечную загрузку) и что увидит ИБ (понятную причину отказа и место, где она возникла).

Чтобы оценить емкость и рост, меряйте не «в среднем», а в пиковые часы и на реальных сценариях: время до доступа (первая авторизация и повторный вход после паузы), время открытия (веб и толстый клиент, если есть), качество RDP (задержка, джиттер, обрывы за 30-60 минут), поведение при отказах (IdP/MFA/канал/коннектор), запас по нагрузке (сколько одновременных сессий в 9:00-11:00 и что будет при росте на 20-30%).

Если вы проводите пилот с интегратором, фиксируйте метрики заранее и тестируйте одинаковые маршруты и филиалы. Тогда «быстро» и «медленно» перестанут быть мнением и станут цифрами.

Пошаговый план пилота: как сравнить решения за 2-4 недели

Пилот ZTNA легко превратить в спор вкусов, если заранее не договориться, что именно вы меряете. Хороший пилот отвечает на простой вопрос: сможет ли обычный сотрудник работать без лишних действий, а ИБ - получить контроль и доказательства доступа.

1) Подготовка (2-4 дня)

Выберите небольшой, но показательный набор: 3-5 критичных приложений и 2-3 типовые роли. Например: бухгалтерия (1С или веб-сервис), служба поддержки (портал и RDP/SSH к админ-хосту), врач или оператор колл-центра (тонкий клиент, внутренний веб).

Дальше зафиксируйте критерии успеха так, чтобы их можно было проверить фактами: время до первого доступа (от открытия ноутбука до входа в приложение), сколько раз пользователь вводит пароль и подтверждает MFA за день, сколько обращений в поддержку и по каким причинам, что видит ИБ в логах (кто, куда, когда, с какого устройства, по какой политике), сколько времени нужно администратору, чтобы выдать и отозвать доступ.

2) Настройка пилота (3-5 дней)

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

Параллельно включите журналирование и базовые отчеты. Не ограничивайтесь «есть события». Проверьте, что вы можете быстро ответить на вопросы расследования: почему доступ был разрешен, какое правило сработало, были ли попытки обхода, чем все закончилось.

Также настройте базовую сегментацию: не «доступ ко всей сети», а доступ только к конкретным приложениям и только нужным ролям. Если продукт вынуждает давать широкие подсети ради удобства, это сигнал риска.

3) Проведение пилота (2-4 недели)

Запустите пилот на живых пользователях, но ограничьте масштаб (например, 20-50 человек) и назначьте ответственных от ИТ, ИБ и бизнеса. Еженедельно снимайте метрики и короткую обратную связь.

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

В конце оформите выводы в одном документе: что получилось без компромиссов, где потребовались обходные решения, что будет стоить дороже всего в поддержке. Такой отчет помогает честно сравнить Zscaler ZPA, Palo Alto Prisma Access, Fortinet ZTNA и аналоги по реальной работе, а не по демо.

Типовые ошибки при выборе и внедрении ZTNA

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

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

Третья ошибка - не прогнать сценарии отказов. ZTNA завязан на цепочку: IdP (SSO), MFA, агент или клиент, точки присутствия провайдера, DNS, сеть. Если одно звено падает, важно понимать, что увидит пользователь и что увидит ИБ. Проверьте это заранее, иначе инцидент будет выглядеть как «у всех все зависло», а причина останется неясной.

Перед выбором и перед запуском полезно пройтись по короткому набору проверок: раздельно протестировать доступ к веб, RDP, SSH и админским консолям (в том числе из нестабильных сетей); убедиться, что политики можно делать точными (по приложению, роли, устройству, состоянию безопасности и времени); оценить логи (кто, куда, как прошел MFA, почему отказано, можно ли быстро собрать цепочку событий); прогнать отказ IdP, отказ агента, смену сети (офис, домашний Wi‑Fi, мобильная точка), истечение сессии; посчитать полную стоимость на 1-3 года (лицензии, хранение логов, внедрение, обучение, поддержка).

Отдельно часто недооценивают админские задачи. Пилот делают на одном веб-приложении, а потом выясняется, что критичные операции идут через RDP/SSH, есть jump-хосты, сервисные аккаунты и нужны другие правила и другой уровень аудита. Если вы протестировали только веб, вы еще не проверили самое рискованное.

Если рядом есть команда интеграторов, которая привыкла запускать пилоты «под ключ», попросите заранее описать негативные сценарии и критерии приемки. В проектах, которые ведут интеграторы уровня GSE.kz, это обычно сокращает недели споров уже после запуска, когда пользователи ждут доступа, а ИБ - понятных логов и управляемых политик.

Короткий чеклист и следующие шаги

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

Держите один чеклист для всех кандидатов: сценарии и роли (3-5 задач и кто к чему должен иметь доступ), устройства и контекст (управляемые и неуправляемые ПК, корпоративные и личные, требования к ОС и состоянию устройства), SSO и MFA (вход через ваш IdP, поведение при смене пароля, сбоях MFA, отключении пользователя), логи и аудит (кто вошел, к какому приложению, с какого устройства, какое решение приняла политика, что было заблокировано), сегментация и отказоустойчивость (принцип «только нужное», работа при падении узла или канала, понятные сообщения пользователю).

По итогам пилота у вас должны остаться артефакты, а не только впечатления: матрица доступа (роли -> приложения/сервисы -> условия), отчет по UX (время первого входа, число шагов, типовые ошибки, обращения в поддержку), примеры логов для расследований (успешные входы, отказы, попытки обхода, изменения политик), карта сегментации (какие приложения опубликованы, какие порты и протоколы разрешены, где остались «широкие» правила), список рисков и допущений (что не проверили, зависимости от провайдеров, где нужны компенсирующие меры).

Внедрение планируйте поэтапно: сначала 1-2 приложения с понятной ценностью (например, корпоративный портал и один внутренний сервис), затем расширение на группы и филиалы. Заранее подготовьте инструкции для пользователей, шаблоны ответов для поддержки и правила на случай сбоя MFA или недоступности IdP.

Следующий шаг после пилота - короткая сессия по архитектуре и дизайну политик с интегратором, который поможет увязать ZTNA с сетью, IdP, журналированием и требованиями ИБ. Если параллельно нужна инфраструктура под отказоустойчивость (серверы, рабочие станции, площадка для сервисов, поддержка 24/7), это можно закрывать в одном контуре: например, через GSE.kz как системного интегратора и поставщика аппаратной базы под заданные требования.