DMZ для удалённых: как уменьшить blast radius когда VPN-шлюз скомпрометирован

На этой неделе вышли совместные рекомендации НКЦКИ и ФСТЭК по организации удалённого доступа. Документ небольшой, но один пункт в нём стоит того, чтобы остановиться: регуляторы прямым текстом указывают на необходимость разделять сегмент удалённого доступа и внутренние корпоративные сети. VPN-концентратор не должен стоять в одном сегменте с файловыми серверами и контроллерами домена.

Звучит как очевидность. На практике у большинства компаний, которых мы видим, это именно так и устроено - в одной плоской сети.

Почему это проблема

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

Пока всё тихо - это работает. Проблема возникает когда VPN-шлюз компрометируют. Атакующий получает не просто точку входа - он получает позицию внутри сети с прямой видимостью на всё. Lateral movement становится тривиальной задачей: контроллер домена доступен напрямую, сканирование внутренних хостов ничто не мешает, эксплуатация уязвимостей во внутренних сервисах - вперёд.

Мы видели похожую картину несколько недель назад в контексте инцидентов с ransomware - компрометированный RDP как точка входа и полная свобода движения внутри. VPN отличается от открытого RDP, но принцип тот же: если компрометация внешней точки входа даёт прямой доступ ко внутреннему периметру, blast radius огромный.

Что предлагает схема с сегрегацией

Идея простая: VPN-концентратор живёт в своём отдельном сегменте - назовём его DMZ удалённого доступа. Из этого сегмента во внутреннюю сеть выхода нет напрямую. Весь трафик - только через firewall с явно прописанными правилами.

[Интернет]
    |
[VPN-концентратор] -- [DMZ удалённого доступа]
    |
[Firewall (политики)]
    |
[Внутренние сегменты: офис, серверная, КИИ]

Что меняется при компрометации VPN-шлюза: атакующий оказывается в DMZ-сегменте, а не внутри корпоративной сети. Он видит только то, что firewall явно разрешает пропускать из этого сегмента. Всё остальное - закрыто.

NPS в схеме и зачем он тут

Отдельный момент - RADIUS-аутентификация через NPS (Network Policy Server). В типичной конфигурации VPN-концентратор аутентифицирует пользователей через AD, и для этого ему нужна видимость до контроллера домена. Это классическое «а нам надо дотянуться до DC, поэтому разрешим из DMZ в корпоративный сегмент» - и вот уже дыра в сегрегации.

Решение - NPS-сервер в том же сегменте DMZ. Он принимает RADIUS-запросы от VPN-концентратора локально, а сам общается с контроллером домена через NPS Proxy или напрямую - но это уже один целевой порт в одну сторону, который можно чётко прописать в firewall. Концентратор не ломится напрямую к DC.

Схема в итоге выглядит так:

VPN-концентратор принимает входящие соединения снаружи, терминирует туннели. NPS-сервер в том же сегменте - принимает RADIUS от концентратора, аутентифицирует через AD. Firewall - единственная точка выхода из DMZ во внутренние сегменты, с явными allow-правилами.

Что прописывать в правилах firewall

Тут начинается реальная работа - инвентаризация что именно нужно разрешить. Типовой набор:

• RDP/SSH к конкретным jump-хостам внутри корпоративного сегмента, а не ко всей подсети.
• Доступ к конкретным бизнес-приложениям по портам - не «вся сеть 10.0.0.0/8», а конкретные адреса и порты.
• RADIUS от NPS к DC - один порт, один адрес.
• DNS - только к корпоративным DNS-серверам, которые разрешены.
• NTP - синхронизация времени, про которую часто забывают и потом удивляются почему Kerberos не работает.

Всё остальное - deny. Не «разрешить всё кроме» - а «запретить всё, разрешить явно перечисленное». Это принципиально разные подходы с точки зрения того, что происходит когда что-то идёт не по плану.

Как это выглядело у нас на практике

На одном из объектов, которым мы занимаемся в рамках управляемого сопровождения, развернули схему с сегрегацией несколько недель назад - ещё до выхода официальных рекомендаций, просто потому что задача формулировалась как «уменьшить радиус поражения при компрометации VPN». Теперь рекомендации регуляторов это ещё и зафиксировали формально.

Несколько моментов из процесса, которые стоит иметь в виду:

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

NPS требует внимания к репликации и отказоустойчивости. Если NPS-сервер один и он упал - VPN-аутентификация встала для всех. На продакшне нужно минимум два NPS с балансировкой на стороне концентратора. Концентраторы умеют опрашивать несколько RADIUS-серверов - это нужно настраивать явно.

Пользователи замечают только то, что сломалось. Когда схема заработала - никто ничего не заметил, что правильно. Пять звонков во время первого дня тестирования от людей у которых «VPN не пускает» - это нормальная рабочая часть, пока правила донастраивались.

Где сейчас

Схема работает. Регуляторы теперь официально рекомендуют именно такой подход, что для объектов КИИ означает не «хорошая практика», а ожидание соответствия при следующей проверке.

Для клиентов без КИИ-статуса - это просто разумная архитектура, которая уменьшает риски в ситуации когда удалённый доступ из временной меры превратился в постоянную практику. Плоская сеть с VPN-шлюзом посередине - это выбор, который стоит переосмыслить, пока его не переосмыслили за вас.