Раз в полгода у меня повторяется один и тот же разговор, и я уже могу отыграть в нём обе роли: ИТ-директор компании человек на восемьдесят сходил на вебинар, послушал полтора часа про то, что периметр умер, вернулся к себе и спрашивает — наш VPN это уже прошлый век, нам срочно нужен ZTNA?
Честный ответ на вебинарах не звучит, он плохо продаётся. Нет. Не срочно.
И скорее всего не нужен вообще — по крайней мере в том виде, в каком его продают. Но закончить на этом было бы дешёвым приёмом. Критика периметровой модели, из которой выросла идея нулевого доверия, справедлива, и я с ней не спорю: проблема настоящая, я сам разгребал последствия. Путей два. Купить платформу. Или привести в порядок то, за что вы уже платите. Первый лучше смотрится в презентации, второй чаще доходит до конца.
Как устроен классический VPN: периметр и доверие внутри
Модель родилась во времена, когда все сидели в офисе, а сервер стоял за железной дверью, и логика была прозрачная: внутренняя сеть доверенная, внешний мир нет, между ними межсетевой экран, и ответственность на нём одном. VPN тут — дверь в стене. Сотрудник из дома поднимает туннель, получает адрес из внутренней подсети и ведёт себя как машина в офисе: тот же шлюз, те же маршруты.
Формула простая: строгая проверка на входе, доверие внутри.
Работало прекрасно ровно до тех пор, пока внутри действительно было всё, а теперь посмотрите на свою инфраструктуру: почта в одном облаке, CRM в другом, 1С на своём железе, бэкапы у хостера, подрядчик по сайту подключается непонятно откуда. Периметр расплылся. Спорить, впрочем, не с чем.
Но у старой модели есть достоинство, которое почему-то не попадает в сравнительные таблицы, — понятность: админ рисует схему на салфетке за минуту, и все в комнате понимают, кто куда ходит. С нулевым доверием так выходит реже, и я видел внедрения, где через полгода никто не мог объяснить, почему человек не попадает в конкретный сервис.
[Изображение: схема «периметровая модель против нулевого доверия» — слева стена с одной дверью и свободное пространство внутри, справа проверка перед каждым ресурсом]
Главная слабость периметра: вошёл один раз — и ты везде
Вот здесь, по-моему, начинается предметный разговор.
Типовая настройка выдаёт подключившемуся маршрут в подсеть целиком. Не к серверу 1С — к 10.0.5.0/24. Так быстрее и проще. И никто не приходит спрашивать, почему у менеджера по продажам есть доступ к управляющему интерфейсу коммутатора. Я и сам так делал, когда удалёнку надо было поднять за выходные. Неправильным это стало через год, когда к конфигу никто не вернулся.
Дальше очевидное: аутентификация происходит ровно один раз, а прав после неё заметно больше, чем человеку нужно для работы. Это и есть главная слабость классического VPN. Сценарий разворачивается сам. У бухгалтера увели ноутбук с сохранённым профилем, или человек кликнул не туда, или пароль лежал в слитой базе форума и совпал с рабочим. Тот, кто оказался на другом конце, поднимает туннель и попадает внутрь. Сканирует подсеть, находит открытые RDP, шары с правами на запись, NAS без пароля. Дальше по обстоятельствам. Обстоятельства обычно заканчиваются шифровальщиком.
Аналогия грубая, но я ей пользуюсь на переговорах: пропуск на завод. Турникет проверяет строго, а дальше по территории вы гуляете свободно.
И сразу оговорюсь, потому что на презентациях это проглатывают. Такое поведение — не свойство VPN как технологии. Это свойство ленивой конфигурации.
ZTNA и нулевое доверие: что это простыми словами
Сначала разведём два понятия, которые путают даже те, кто их продаёт.
Zero Trust — принцип, а не коробка. Сеть сама по себе не даёт никаких прав, то, что пакет пришёл из офисной подсети, ничего не доказывает, и каждый запрос проверяется отдельно: кто пользователь, с какого устройства, в каком оно состоянии, к чему лезет и имеет ли право прямо сейчас.
ZTNA (Zero Trust Network Access) — реализация принципа для удалённого доступа. Между пользователем и ресурсами ставится брокер, и в сеть пользователь не попадает вообще: он приходит к брокеру, тот сверяет его с политикой и проксирует соединение до приложения, а всего остального для него будто нет.
Побочный эффект, который нравится мне даже больше самой идеи: приложения перестают торчать наружу. Коннектор сам открывает исходящее соединение к брокеру, входящих портов на периметре не остаётся. Кстати, именно ради этого, а не ради красивой политики, я бы и рассматривал ZTNA.
Чем ZTNA отличается от VPN: разница в одной фразе
Коротко: VPN даёт вам адрес в сети, ZTNA даёт соединение до приложения. Всё остальное растёт отсюда.
Боковое перемещение. Учётка открывает ровно то, что разрешено политикой: ни подсети, ни соседних серверов.
Язык описания прав — для меня разница даже более существенная, потому что в VPN это звучит как «Иванову маршрут в 10.0.5.0/24», и на аудите вы переводите строчку на человеческий минут двадцать. В ZTNA — «Иванову доступ к 1С Бухгалтерия с корпоративного ноутбука в рабочее время».
Непрерывность проверки. Туннель поднимают один раз, и он живёт сутками, а брокер переспрашивает постоянно: устройство ушло из домена, антивирус отключён, человек подключается из другой страны — сессия закрывается.
А теперь неприятное, о чём, я замечал, говорят скороговоркой. Для веб-приложений всё это работает отлично, для SSH и RDP более-менее. Но половина корпоративных ресурсов — не веб. Сетевые шары, принтеры, SIP-телефония, сервер лицензий, толстый клиент 1С. Часть этого ZTNA умеет с оговорками, часть не умеет вовсе. И тогда туннель рядом всё равно остаётся, а платите вы за две системы.
VPN и ZTNA: сравнение по восьми параметрам
Ладно, к делу. Без оценок «лучше — хуже», просто по свойствам.
| Параметр | Классический VPN | ZTNA |
|---|---|---|
| Что получает пользователь | Адрес и маршрут в сегмент сети | Соединение до конкретного приложения |
| Модель доверия | Проверка на входе, доверие внутри | Проверка при каждом обращении |
| Риск бокового перемещения | Высокий при плоской сети, низкий при сегментации | Низкий по архитектуре |
| Гранулярность прав | Подсети, адреса, порты | Пользователь, приложение, устройство, контекст |
| Не-веб протоколы и старое ПО | Работает со всем, что ходит по IP | Зависит от реализации, часто с ограничениями |
| Сложность внедрения | Низкая, поднимается за день | Средняя и выше: инвентаризация, политики, агенты |
| Стоимость владения | Сервер плюс администрирование | Подписка на пользователя плюс проект внедрения |
| Что нужно, чтобы взлетело | Понимание своей сети | Порядок в каталоге пользователей и список всех ресурсов |
Последняя строка, если честно, решает больше всех предыдущих вместе: проект, начатый без списка ресурсов и без порядка в учётках, разваливается независимо от того, что написано на коробке.
Стоимость и сложность: где ZTNA откровенно избыточен
Лицензии считают на пользователя в месяц, и обходятся они дороже туннеля. Но главная статья не эта.
Главная — проект. Нельзя раздать доступ к приложениям, не имея их списка, а списка обычно нет. Есть 1С, есть файловый сервер, и есть ещё девять сервисов, про которые помнит один человек в отпуске. Инвентаризация и политики — недели работы, и делает их не вендор. Второе условие — порядок в учётных записях. Если уволенных вычищают раз в год перед проверкой, платформа перенесёт бардак в дорогой интерфейс. Сначала политика доступа и регламент, потом инструмент. Наоборот не выходит, я пробовал.
Оправдан ZTNA, на моей памяти, там, где сотни сотрудников и много подрядчиков, инфраструктура размазана по облакам, а служба ИБ — не админ на полставки.
Избыточен — там, где людей от пятнадцати до сотни, офис один, а всё ИТ это один администратор.
Для второй группы zero trust в чистом виде — покупка архитектуры под задачу, которой нет. Дешевле выходит корпоративный VPN со вторым фактором, нарезанными маршрутами и журналами. И да, я понимаю, как это звучит от человека, который продаёт как раз VPN.
Про ZTNA в России спрашивают всегда, поэтому коротко: часть зрелых решений зарубежные, с понятными вопросами по оплате и доступности завтра, отечественные развиваются, сравнивать их по именам я не буду, но к цене лицензии добавляется риск того, что поставщик перестанет вас обслуживать.
Гибрид: VPN под инфраструктуру, ZTNA под приложения
Компании, дошедшие до темы всерьёз, почти никогда не мигрируют целиком. Они смешивают, и это, по моему опыту, единственный сценарий, доживающий до второго года.
Туннель остаётся там, где нужен именно сетевой доступ: администраторы к железу, связка офисов и складов между собой, оборудование, которое про брокеров не слышало. Ставится это на выделенный сервер, чтобы не делить логи с посторонними.
Брокер накрывает то, чем пользуется много людей и что живёт по HTTPS: порталы, вики, заявки.
Правильная последовательность — не «мигрировать», а добавлять. Сначала привести в порядок туннель. Потом, если останется боль, закрыть её брокером точечно. Не наоборот.
[Изображение: схема гибридной архитектуры — туннель к инфраструктурному сегменту и брокер доступа перед веб-приложениями]
Как усилить обычный VPN и получить большую часть эффекта
Самый практичный раздел, и если вы дочитали сюда ради одного куска — вот он. Кстати, всё перечисленное делается без нового бюджета.
Второй фактор. Обязательно, без вариантов. Он закрывает главный сценарий — вход по украденному паролю, — и без него, если честно, остальные меры работают вполсилы. Как внедрить его без бунта бухгалтерии, я разбирал отдельно: двухфакторная аутентификация для VPN.
Сегментация и маршруты по группам. Вот это и есть замена доброй половины ZTNA, причём бесплатная. Бухгалтерия получает маршрут к серверу 1С и к своей шаре — не к подсети, а к адресам и портам. Разработчики к своему сегменту, администраторы к управляющему. Плоская сеть чинится конфигом за один скучный вечер, и я понимаю, что для проблемы, вокруг которой выросла индустрия, это звучит подозрительно просто.
Минимальные права на ресурсах. Сетевой доступ и права в системе — разные вещи, их путают постоянно. Шифровальщик зашифрует ровно то, к чему у учётки есть доступ на запись.
Журналирование и, что важнее, внимание к журналам. Кто, когда, откуда, как долго. Подключение бухгалтера в три часа ночи из региона, где у вас никого нет, — это повод позвонить ему домой, а не строчка в логе, которую никто не открывал. Подробности — в материале про мониторинг VPN-подключений, реализация — на странице мониторинга.
Привязка к устройству. Мой любимый пункт: сертификат лежит на конкретном ноутбуке и не утекает вместе с паролем.
Ревизия раз в квартал. Открыть список тех, у кого есть доступ, и пройти по строкам с двумя вопросами: он ещё работает? ему это ещё нужно? Находится всегда. У меня не было ревизии, которая закончилась бы словами «всё в порядке».
Это не нулевое доверие, скажем так. Это периметр, приведённый в чувство. Но разрыв с ZTNA по закрытым рискам сокращается в разы, а по деньгам остаётся кратным.
Чек-лист: что выбрать под ваш размер и зрелость ИТ
- До 30 человек, один офис. Туннель с 2FA и нарезанными маршрутами, про zero trust почитать и забыть. Базовый вариант — VPN для офиса.
- 30–100 человек, есть удалённые. То же плюс сегментация, журналы и письменный регламент — удалённый доступ, выстроенный по-взрослому.
- 100–300 человек, несколько площадок. Туннель для инфраструктуры плюс единая точка входа и SSO для веб-сервисов; разговор про брокер уже по делу.
- Больше 300, служба ИБ, много подрядчиков. ZTNA осмыслен, но начинать с инвентаризации и порядка в учётках, а не с выбора вендора.
И вопрос, который стоит задать раньше выбора архитектуры, раньше сравнения вендоров и раньше бюджета: у нас есть актуальный список тех, у кого прямо сейчас есть доступ? Если ответа нет, никакая архитектура не спасёт.
[Изображение: чек-лист выбора по размеру компании — четыре строки с рекомендацией напротив каждой]
Что из этого забрать
ZTNA — не пустышка, принцип рабочий, и через десять лет мы, подозреваю, будем жить в основном в нём. Но продают его чаще, чем он нужен.
Для малого и среднего бизнеса связка «туннель плюс второй фактор плюс сегментация плюс живые журналы» закрывает основную массу угроз — не потому, что VPN совершеннее, а потому, что внедрённая простая мера работает, а недовнедрённая сложная не работает вообще.
Если у вас до сих пор один общий конфиг на всех и маршрут во всю подсеть, то риск, думаю, именно там. Не в отсутствии ZTNA.
Корпоративный VPN с контролем доступа и мониторингом разворачивается за день, тест идёт без карты. Посмотрите на своих людях, прежде чем обсуждать архитектуры на миллион.
Частые вопросы
Что такое ZTNA?
Способ организовать удалённый доступ, при котором пользователь получает соединение до приложения, а не адрес во внутренней сети. Между ним и ресурсами стоит брокер, проверяющий каждый запрос.
Чем ZTNA лучше VPN?
Главное — резко ограниченное боковое перемещение: украденная учётка открывает только то, что разрешено политикой, и права описаны в терминах, понятных бизнесу. Взамен цена выше, внедрение дольше, совместимость со старым не-веб софтом хуже.
Нужен ли ZTNA малому бизнесу?
Как правило нет: компании до сотни человек закрывают тот же набор рисков через VPN со вторым фактором, сегментацией маршрутов и журналированием — быстрее и в разы дешевле. Разговор про zero trust осмыслен, когда пользователей сотни, а инфраструктура распределена.
Как усилить безопасность VPN?
По убыванию эффекта: включить 2FA, нарезать маршруты по группам вместо доступа ко всей подсети, ограничить права на ресурсах, настроить журналы с оповещениями, раз в квартал делать ревизию. Плюс привязка к устройству сертификатом и вынос сервиса на выделенный сервер.
