ZTNA против VPN: почему компании уходят от классических VPN
Классический VPN строился вокруг модели доверенного периметра: подключился туннелем — оказался «внутри» и получил доступ к сети целиком. По мере роста удалённой работы, облаков и подрядчиков такая модель стала уязвимой: один скомпрометированный аккаунт или устройство открывает злоумышленнику горизонтальное перемещение по плоской сети. ZTNA (Zero Trust Network Access) меняет принцип: доступ выдаётся не к сети, а к конкретному приложению, и только после проверки пользователя, устройства и контекста. **Если коротко:** VPN никуда не исчезает, но перестаёт быть универсальным решением. Для сценариев с подрядчиками, BYOD, множеством SaaS и распределёнными командами выигрывает ZTNA с принципом минимальных привилегий. Где-то оба подхода сосуществуют. Ниже — чем именно различаются модели, по каким критериям сравнивать и когда мигрировать. Сравнить поставщиков по подтверждённым сигналам можно в [рейтинге VPN и ZTNA](/rating/vpn-ztna-remote-access).
Визуальный контекст исследования
Изображение помогает быстро считать тему материала: инфраструктура, данные, доступы и контрольные точки, которые важно проверить перед выбором решения.
Рейтинги подрядчиков по теме исследования
Если после чтения нужен короткий список исполнителей, начните с профильных рейтингов cyber-index.ru: в них видны компании, кейсы, интервью, категории экспертизы и доверительный индекс.
Как проверять выводы исследования
Используйте материал как основу для shortlist: сопоставьте выводы с профилями компаний, связанными рейтингами, кейсами, интервью клиентов и источниками. Если в статье есть список источников, начинайте проверку с него; если источников мало, дополнительно запросите у подрядчика методику, baseline и примеры работ.
Авторы и проверка материала
У каждого исследования есть персональные авторы, профиль экспертизы, дата публикации, список источников и редакционная проверка выводов.
author
Антон Смирнов
Старший редактор исследований ИБ-рынка
Ведет исследования по категориям ИБ, публичным источникам и критериям выбора поставщиков.
- 7 лет в SEO-аналитике и редакционных B2B-исследованиях
- Специализация: ИБ-категории, entity-based SEO и факторы E-E-A-T
author
Полина Лебедева
Исследователь рынка ИБ-поставщиков
Собирает и сравнивает данные по подрядчикам, услугам, публичным кейсам, ценовым диапазонам и рыночным сегментам.
- 5 лет в market research, digital-аналитике и конкурентных обзорах
- Специализация: ИБ-поставщики, сервисные категории, прайс-анализ и case review
Авторы закреплены по теме исследования и опираются на практические разборы страниц, кейсов, источников и рыночных выборок.
В профиле автора указаны зона экспертизы, роль в редакции, регалии и темы, за которые он отвечает.
Материалы связаны с методологией cyber-index.ru, внутренними рейтингами, карточками компаний и источниками.
Позиции не продаются, выводы отделены от рекламы, а проверяемые утверждения поддержаны источниками и датами обновления.
Почему классический VPN перестаёт устраивать
VPN решал задачу своего времени: дать удалённому сотруднику защищённый канал «внутрь» корпоративной сети. Но сама логика «подключился — значит свой» сегодня работает против безопасности.
Три фундаментальные проблемы периметровой модели:
- **Плоский доступ.** После установления туннеля пользователь чаще всего видит сегмент сети целиком, а не только нужные ему приложения. Избыточные разрешения копятся годами. - **Доверие к периметру.** Модель исходит из того, что внутри сети — безопасно. Но скомпрометированный ноутбук подрядчика или украденные учётные данные превращают это доверие в открытую дверь. - **Риск горизонтального перемещения.** Получив одну точку входа, атакующий перемещается по сети к ценным активам, потому что внутренние сегменты слабо изолированы, а VPN не контролирует, к чему именно обращается сессия.
Добавьте к этому рост числа подрядчиков, BYOD-устройств и SaaS-приложений за пределами периметра — и становится понятно, почему «расширять периметр» туннелями больше не масштабируется.
VPN и ZTNA: коротко в цифрах
VPN пускает в сегмент сети, ZTNA — к конкретному ресурсу
ZTNA реализует модель Zero Trust
ZTNA учитывает состояние устройства и контекст сессии
Подключение каталога, политик и первых приложений
Что такое ZTNA и на каких принципах он работает
ZTNA (Zero Trust Network Access) — это подход к удалённому доступу, реализующий модель Zero Trust: «никогда не доверяй, всегда проверяй». Вместо того чтобы пускать пользователя в сеть, ZTNA посредник (брокер доступа) устанавливает соединение между конкретным пользователем и конкретным приложением — и только если выполнены условия политики.
Ключевые принципы, которыми ZTNA отличается от VPN:
- **Доступ к приложению, а не к сети.** Пользователь получает доступ к разрешённым ресурсам поимённо. Остальная инфраструктура для него невидима — нет «сети», по которой можно перемещаться. - **Проверка устройства и контекста.** Решение о доступе учитывает не только логин и пароль, но и состояние устройства (антивирус, шифрование диска, версия ОС), геолокацию, время, поведение. Контекст проверяется на входе и в ходе сессии. - **Минимальные привилегии.** По умолчанию запрещено всё; разрешается только то, что явно нужно роли. Это резко сужает поверхность атаки и блокирует горизонтальное перемещение. - **Сокрытие инфраструктуры.** Приложения не публикуются наружу напрямую; они скрыты за брокером, что уменьшает площадь сканирования и эксплуатации.
Чем ZTNA отличается от VPN на практике
Оба подхода дают удалённый доступ, но архитектурно решают разные задачи. Таблица ниже — ориентир, как сместить мышление с «периметра» на «приложение». Это не рейтинг: места и подтверждённые сигналы смотрите в [рейтинге категории](/rating/vpn-ztna-remote-access).
| Критерий | Классический VPN | ZTNA (Zero Trust) |
|---|---|---|
| Объект доступа | Сегмент сети | Конкретное приложение |
| Модель доверия | Доверие после подключения | Непрерывная проверка |
| Привилегии | Часто избыточные, «плоские» | Минимальные, по роли |
| Видимость инфраструктуры | Сеть видна изнутри | Ресурсы скрыты за брокером |
| Учёт устройства/контекста | Обычно нет | Да, на входе и в сессии |
| Горизонтальное перемещение | Возможно | Затруднено по дизайну |
| Подрядчики и BYOD | Сложно ограничить | Гранулярно по политике |
Готовность подходов по критериям удалённого доступа
Усреднённая редакционная оценка соответствия подхода критерию (0–100) по открытым данным. Это не вендорский бенчмарк и не заменяет пилот в вашей инфраструктуре.
Когда оставаться на VPN, а когда мигрировать на ZTNA
ZTNA — не «кнопка отключения VPN». Есть сценарии, где классический туннель уместен, и сценарии, где периметровая модель становится тормозом.
**Оставаться на VPN разумно, когда:**
- нужен полноценный сетевой доступ на уровне L3 (например, администрирование по широкому набору протоколов, legacy-системы без веб-интерфейса); - инфраструктура небольшая, доверенная и стабильная, а число подрядчиков минимально; - уже есть сертифицированный ГОСТ-VPN под требования регулятора, и доступ нужен «сеть-в-сеть».
**Мигрировать на ZTNA стоит, когда:**
- много внешних подрядчиков, BYOD и временных пользователей, которым нельзя давать сеть целиком; - приложения распределены между ЦОД и облаками/SaaS, и периметр размывается; - нужно ограничить горизонтальное перемещение и сократить избыточные привилегии; - регулятор или внутренняя политика требуют учёта состояния устройства и контекста доступа.
На практике многие компании идут гибридным путём: оставляют VPN для узких L3-сценариев и переводят основной доступ к приложениям на ZTNA.
Чек-лист перехода на ZTNA
План перехода с VPN на ZTNA: 6 шагов
-
01
Инвентаризация доступа
Зафиксируйте, кто, к каким приложениям и зачем подключается сегодня через VPN.
-
02
Сегментация по ролям
Сгруппируйте пользователей и приложения, опишите политики минимальных привилегий.
-
03
Интеграция аутентификации
Подключите каталог и IdP, включите MFA, задайте критерии доверия к устройству.
-
04
Пилот на приложениях
Переведите 2–3 неконфликтных приложения и узкую группу пользователей на ZTNA-доступ.
-
05
Параллельный режим
Дайте ZTNA и VPN работать одновременно, сверяйте события и обкатывайте политики.
-
06
Расширение и вывод VPN
Поэтапно переводите остальные приложения, оставляя VPN только для нужных L3-сценариев.
Как мы оцениваем поставщиков
cyber-index.ru не продаёт места в рейтинге. Поставщики сравниваются по проверяемым сигналам: подтверждённые внедрения и кейсы, отзывы и интервью клиентов, внешняя репутация, специализация, прозрачность и свежесть данных. Поэтому статью стоит читать в связке с [рейтингом VPN и ZTNA](/rating/vpn-ztna-remote-access): здесь — модели и критерии, там — сравнение конкретных компаний по подтверждённым фактам.
Следующий шаг
Разобрались с моделями — переходите к сравнению поставщиков: **[рейтинг VPN и ZTNA для удалённого доступа →](/rating/vpn-ztna-remote-access)**. Полезно прочитать рядом: [российские решения удалённого доступа 2026](/research/rossiyskie-resheniya-udalennogo-dostupa-reyting-2026), [чем заменить Cisco AnyConnect и Zscaler](/research/zamena-cisco-anyconnect-zscaler-alternativy) и [удалённый доступ к КИИ: требования и ГОСТ](/research/udalennyy-dostup-kii-trebovaniya-gost).
Частые вопросы
Чем ZTNA отличается от VPN простыми словами?
VPN пускает вас «внутрь сети» и дальше доверяет. ZTNA соединяет вас с конкретным приложением только после проверки пользователя, устройства и контекста — и не даёт видеть остальную сеть. Поэтому при компрометации одного доступа злоумышленнику некуда перемещаться.
ZTNA полностью заменяет VPN?
Не всегда. Для гранулярного доступа к приложениям, подрядчиков и BYOD ZTNA сильнее. Но для отдельных L3-сценариев и legacy-систем VPN остаётся уместным. Многие компании работают в гибриде: ZTNA для приложений, VPN для узких сетевых задач.
Нужно ли менять инфраструктуру целиком ради ZTNA?
Нет, переход обычно поэтапный. Сначала инвентаризация и политики, затем пилот на 2–3 приложениях, параллельная работа с VPN и постепенное расширение. Это снижает риск простоя.
Что важнее при выборе — сертификация или функциональность?
Зависит от задачи. Для значимых объектов КИИ и госсектора наличие в реестре отечественного ПО и сертификат ФСТЭК — входной барьер; дальше решают зрелость политик, интеграция с каталогом и поддержка нужных сценариев доступа.
Где сравнить конкретных поставщиков между собой?
В рейтинге VPN и ZTNA для удалённого доступа — там компании ранжированы по подтверждённым сигналам, а не по рекламе.
Источники и метод проверки
Классический VPN строился вокруг модели доверенного периметра: подключился туннелем — оказался «внутри» и получил доступ к сети целиком. По мере роста удалённой работы, облаков и подрядчиков такая модель стала уязвимой: один скомпрометированный аккаунт или устройство открывает злоумышленнику горизонтальное перемещение по плоской сети. ZTNA (Zero Trust Network Access) меняет принцип: доступ выдаётся не к сети, а к конкретному приложению, и только после проверки пользователя, устройства и контекста. **Если коротко:** VPN никуда не исчезает, но перестаёт быть универсальным решением. Для сценариев с подрядчиками, BYOD, множеством SaaS и распределёнными командами выигрывает ZTNA с принципом минимальных привилегий. Где-то оба подхода сосуществуют. Ниже — чем именно различаются модели, по каким критериям сравнивать и когда мигрировать. Сравнить поставщиков по подтверждённым сигналам можно в [рейтинге VPN и ZTNA](/rating/vpn-ztna-remote-access).