Zero Trust
Проверенный рецепт защиты корпоративной сети стал гораздо менее эффективен. Оградить периметр межсетевым экраном, а удаленный доступ выдавать через VPN-сервер стало и сложно, и опасно: в повседневной работе трудно настраивать сценарии взаимодействия пользователей и облачных сервисов, а во время кибератак VPN-сервер теперь является приоритетной мишенью. По данным страховщиков из At-Bay, почти три четверти успешных атак при помощи программ-вымогателей, вошедших в анализ за 2025 год, начались именно со взлома VPN.
Чтобы одновременно повысить и защищенность сети, и эффективность бизнес-процессов, компаниям нужно пересмотреть саму модель удаленного доступа. Конечной целью является защищенное подключение сотрудника к рабочим ресурсам. Из этого вовсе не следует, что сотруднику (или человеку, который им притворяется) нужно предоставлять полный доступ к корпоративной сети.
Что демонстрируют недавние атаки на VPN
Сама по себе технология VPN не устарела фатально, если рассматривать ее как способ шифрования и туннелирования трафика. Проблема кроется в наиболее распространенной архитектуре применения: пользователь проходит проверку на входе, получает доступ в сеть компании, а дальше ограничения (если они вообще есть) зависят от сегментации, межсетевых экранов и защиты отдельных систем. Внутри сети, за VPN-шлюзом, можно обращаться к широкому спектру внутренних сервисов с минимальными ограничениями. Очень часто сам VPN-шлюз является привилегированным устройством, и при его успешной компрометации атакующим открываются широкие возможности для захвата сети.
Например, в атаках на шлюзы Ivanti Connect Secure в октябре 2026 злоумышленники из APT UTA0576 использовали цепочку из трех уязвимостей нулевого дня, скомпрометировав полностью обновленное устройство. Получив права root, они использовали легитимный сервисный аккаунт самого VPN для запросов к контроллеру домена, собирая пароли и ключи восстановления BitLocker.
Чуть раньше по похожему сценарию эксплуатировались уязвимости в шлюзах Check Point и SonicWall; последняя активность проводилась вымогателями Akira.
Удаленная работа, VPN и украденные данные
Сейчас, в зависимости от страны, от 12% до 30% сотрудников полностью или частично работают из дома. Для РФ этот показатель равен 25%. Это значительно повысило требования к тому, как много ИТ-систем должно быть доступно вне сети организации, зачастую с личных устройств. Последние гораздо чаще, чем корпоративная техника, оказываются заражены инфостилерами. В результате черный рынок полон предложений о продаже корпоративных учетных данных, украденных с таких компьютеров — это 30% всего ассортимента брокеров первоначального доступа.
Строго сегментированная сеть даже через VPN может открывать лишь очень ограниченный доступ. Но на практике за годы эксплуатации накапливаются исключения: подрядчику понадобился доступ в целую подсеть, администратору — «временно все», старому приложению — еще несколько портов. Особенно быстро эти исключения накапливались в пандемию COVID-19. В результате украденная учетная запись часто открывает доступ не к одному сервису, а ко всей инфраструктуре.
Накладные расходы администрирования VPN
Чтобы корпоративный доступ через VPN работал полноценно и безопасно, настраивать один лишь VPN-шлюз обычно недостаточно: приходится отдельно настраивать MFA, проверку состояния устройств, сетевую сегментацию и сбор журналов. Затем все это нужно согласовать между собой. Новый сотрудник или приложение могут потребовать изменений сразу в нескольких системах. Каждая по отдельности работает правильно, но правила расходятся, и разбор вопроса «почему у пользователя нет доступа» превращается в путешествие по пяти консолям.
Что меняет переход на сетевой доступ в модели Zero Trust
ZTNA (Zero Trust Network Access) меняет в первую очередь саму модель доступа и ее базовую учетную единицу. Вместо подхода «этот пользователь имеет права доступа к этой подсети» система ZTNA принимает решения вида «этот пользователь, работая с этого устройства, находящегося в такой локации и пройдя такие-то уровни проверки, имеет право доступа к конкретному приложению».
Решение учитывает комбинацию факторов (личность, устройство и так далее), предусмотренную политикой. Право работать с системой заявок или базой клиентов не должно автоматически давать возможность подключаться к файловому серверу или контроллеру домена.
В зависимости от политик, «за кулисами» система ZTNA может открывать доступ к нужному ресурсу комбинацией способов: специализированный VPN-туннель до конкретного внутреннего сервера, обратное соединение из корпоративного приложения в частном облаке и другие. Легитимному пользователю об этом знать не нужно, а вот возможности злоумышленника перемещаться по сети и атаковать новые сервисы будут сильно ограничены.
Стоит помнить, что ZTNA — это конкретный инструмент, часть более широкой архитектуры нулевого доверия. Покупка одного продукта не означает, что компания воплотила Zero Trust.
Преимущества ZTNA при переходе с обычного VPN
Грамотно внедренная система ZTNA в первую очередь снижает потенциальный ущерб (blast radius), если часть инфраструктуры или чьи-то учетные данные будут скомпрометированы. Но также при внедрении ощутимо сужается свобода маневра атакующего.
Снижение рисков атаки на шлюз
VPN-шлюз обычно принимает любые подключения из Интернета. Прежде чем проверить пользователя, он подробно анализирует входящие соединения, криптографические сообщения, запросы к порталу управления и аутентификации. Уязвимость шлюза позволяет атакующему на этом этапе подробно разведать систему и обойти аутентификацию целиком.
Некоторые архитектуры ZTNA уменьшают эту экспозицию. Внутренний коннектор сам устанавливает исходящее соединение с облачным брокером. Пользователь подключается к брокеру отдельно, а доступ к приложению открывается после необходимых проверок. В такой системе открывать собственный шлюз для удаленного доступа вообще не нужно.
Для архитектуры ZTNA, в которой брокер размещен в инфраструктуре самой организации, «перенести риск» к провайдеру ZTNA не получится. Но ряд решений ZTNA значительно сокращает поверхность атаки и для брокера on-premise, используя, например, технологию Single Packet Authorization. Брокер не обрабатывает никакие запросы, пока не получит корректно сформированный зашифрованный пакет, которым клиент первоначально доказывает свою аутентичность.
Уменьшение последствий компрометации учетных данных и рабочих компьютеров
ZTNA позволяет связать доступ не только с паролем, но и с состоянием устройства: управляется ли оно организацией, действует ли его сертификат, обновлена ли ОС и актуальны ли базы защитного решения, нет ли признаков компрометации. Более того, решение может по-разному аутентифицировать одного и того же пользователя для разных задач. Нужно почитать новости на внутреннем портале и компьютер, с которого входит пользователь, ранее известен? Достаточно пароля. Пользователь входит в репозиторий ПО, чтобы изменять исходный код приложений, или открывает бюджетное планирование? Потребуется пройти устойчивую к фишингу аутентификацию, например с аппаратным ключом (YubiKey, Rutoken и тому подобную). Если используемый вид подключения или другие параметры соединения изменились, потребуется даже повторная аутентификация.
Примерив эту картину к инфостилерам, легко увидеть, как усложняется гипотетическая атака. Недостаточно просто украсть пароль или сессию из браузера. Попытка применить их на новом устройстве приведет к обрыву соединения.
Функции ZTNA здесь отчасти пересекаются с тем, что делают агенты EDR и MDM/EMM на устройстве. Поэтому ряд производителей предлагает объединять эти возможности в едином агентском приложении. При этом ZTNA ограничивает последствия атаки, но не заменяет защиту конечных точек. Если атакующий использует не инфостилер, а трояна удаленного доступа (RAT) и непосредственно управляет устройством сотрудника, агент ZTNA может и не различить эти ситуации.
Улучшение наблюдаемости (observability) и ускоренное обнаружение аномалий
При работе сотрудника из дома через VPN межсетевые экраны, веб-фильтры и SIEM/XDR часто получают лишь поверхностную сетевую телеметрию. Из-за этого, например, действия вымогателей Qilin, эксплуатировавших уязвимость аутентификации в Palo Alto GlobalProtect (CVE-2026-0257), были трудноотличимы от легитимных действий сотрудников.
ZTNA позволяет связывать события доступа с конкретными пользователями, устройствами и приложениями (identity). В зависимости от реализации, SOC могут быть доступны журналы соединений, а для поддерживаемых протоколов — отдельные запросы к конкретным приложениям.
При такой детальности журналов и при наличии соответствующих правил в SIEM аномалии быстро привлекают внимание аналитиков SOC.
Упрощение администрирования доступов
«Гостевой» и «временный» VPN-доступ — вечная головная боль команд ИТ и ИБ. Учетные записи подрядчиков создаются как временные, но остаются работать годами. Через такой плохо контролируемый доступ в 2026 году была взломана крупная европейская финансовая организация. ZTNA позволяет внедрить концепцию доступа Just-in-Time (JIT). Инженер техподдержки подрядчика получает доступ исключительно к веб-интерфейсу одного нужного ему сервера, и этот доступ автоматически отключается через выбранное время (например, через два часа, или двое суток).
Снижение регуляторных и страховых рисков
К более строгому управлению доступами подталкивают и регуляторы, и рынок киберстрахования. В апреле 2026 агентство CISA прямо назвало постоянный VPN-доступ подрядчиков одной из критических угроз для промышленных сетей. Страховые компании также реагируют на этот тренд: организации с устаревшими конфигурациями VPN все чаще сталкиваются с растущими страховыми премиями.
Краткий план перехода с VPN на ZTNA
В первом приближении план миграции таков.
- Проведите инвентаризацию удаленного доступа: VPN, серверы RDP, шлюзы поставщиков, сервисные аккаунты, настроенные исключения в межсетевых экранах.
- Спроектируйте и подробно опишите структуру доступов по приложениям и ролям, а не по привычным подсетям.
- Проверьте и по необходимости доработайте детальную систему идентификации пользователей, устройств и приложений (identity management), поскольку на ней основана эффективная работа ZTNA. Включите устойчивую к фишингу MFA, настройте политики восстановления доступа, проверки состояния и отзыва сессий.
- Опишите изолированный, относительно легко воплотимый, но не тривиальный сценарий пилота. Например, начните с доступа подрядчиков к нескольким приложениям.
- Постепенно масштабируйте решение, включая новые группы сотрудников и сервисов.
- После каждого этапа миграции отключайте или значительно ограничивайте ставшие неактуальными способы входа. Для оставшихся VPN применяйте строгую сегментацию и мониторинг.
Некоторым устаревшим приложениям, промышленным системам и межсетевым соединениям VPN понадобится еще долгое время. Цель не в том, чтобы любой ценой удалить три буквы из инфраструктуры, а в том, чтобы серверы VPN перестали быть легкой мишенью и эффективной стартовой площадкой для атаки на вашу сеть.
Советы