RDP или VPN: что на самом деле нужно вашим серверам

Сравнение, которое людям кажется, что они делают

«RDP или VPN» звучит как выбор между двумя технологиями удалённого доступа. Это не так: VPN не заменяет RDP, он решает, кому позволено до него дотянуться. В конце вы всё равно пользуетесь Remote Desktop. Настоящий вопрос в том, слушает ли служба RDP весь интернет или частную сеть, дверью в которую распоряжаетесь вы.

В такой формулировке сравнение по безопасности даже не близкое. VPN убирает открытость; прямой RDP ею управляет. Любое серьёзное руководство по харденингу говорит «используйте VPN», и любое серьёзное руководство право.

И тем не менее огромное число продакшн-серверов открыты напрямую, и держат их люди, эти руководства читавшие. К этому стоит отнестись всерьёз, а не отмахнуться, потому что причины обычно настоящие.

Что VPN реально меняет

Поставьте VPN впереди — и служба RDP перестаёт быть доступной из интернета. Один этот факт убирает целую категорию проблем:

• Сканеры перестают вас находить. Объём неудачных входов падает практически до нуля, и журнал безопасности снова становится читаемым.
• Уязвимости в самом RDP, срабатывающие до аутентификации, перестают быть срочными. Если до службы не может дотянуться никто неаутентифицированный, следующая CVE в RDP — это патч, который вы планируете, а не инцидент, который вы разгребаете.
• Атакам на учётные данные сначала нужно пройти аутентификацию VPN — это ещё одно место, где можно потребовать второй фактор, и ещё один журнал для просмотра.
• Вы получаете единую точку входа с аудитом вместо службы, открытой на каждом сервере по отдельности.

Во что обходится эксплуатация

Причина, по которой VPN рекомендуют, но не внедряют, в том, что издержки эксплуатационные, а не финансовые, и ложатся они на людей, а не на бюджет.

Каждому, кому нужен доступ, нужен клиент, учётные данные и работающая конфигурация — включая подрядчика, пришедшего на две недели, коллегу с телефона и того, кто дежурит в три часа ночи из гостиничной сети, блокирующей порт VPN.

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

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

Когда прямой RDP — обоснованный выбор

Это не уступка: есть ситуации, где он действительно лучшее инженерное решение.

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

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

Когда доступ должен работать откуда угодно и немедленно. Гостиничные и корпоративные сети блокируют VPN-протоколы достаточно часто, чтобы «я не могу подключиться» во время инцидента было реальным операционным риском.

В этих случаях честная позиция такая: служба открыта, и ей нужны компенсирующие меры, которые действительно на месте, — MFA на каждой учётке, NLA, актуальные патчи и автоматический бан источников с повторяющимися отказами. Эта связка заметно сильнее, чем VPN, который половина команды обходит.

Варианты посередине

Выбор не бинарный, и именно в середине оказывается большинство хорошо управляемых парков.

• Remote Desktop Gateway — туннелирует RDP поверх HTTPS на 443, поэтому работает из сетей, блокирующих всё остальное, и даёт одну аутентифицированную точку входа с журналом. По пользе ближе к VPN, по эксплуатационным издержкам — к RDP.
• Бастион или jump-хост — открыта одна укреплённая, плотно наблюдаемая машина; всё остальное доступно только с неё. Концентрирует риск там, где вы можете позволить себе смотреть внимательно.
• Session-менеджеры облачных провайдеров — доступ через браузер или агент вообще без входящего порта. Отлично там, где ваши серверы живут у провайдера, который это предлагает, и недоступно там, где нет.
• Zero-trust network access — доступ по приложениям с учётом личности, без туннеля на сетевом уровне. Направление, куда движется отрасль, с соответствующей подпиской и стоимостью внедрения.
• RDP с ограничением источников — никакого туннеля, просто фаервол, пускающий небольшой список известных адресов. Самая дешёвая настоящая мера, и работает ровно до того момента, как кто-то уехал.

Как выбрать

В большинстве случаев вопрос решают два уточнения. Может ли каждый, кому нужен доступ, надёжно дотянуться до VPN из каждой сети, откуда он работает? И есть ли у вас человек, который будет держать этот VPN пропатченным и под мониторингом?

Два «да» — используйте VPN и на этом остановитесь. Это более сильная конструкция, и её стоимость вы потянете.

Хотя бы одно «нет» — признайте, что служба открыта, и постройте компенсирующие меры как следует, а не внедряйте VPN, который будут обходить. Это означает MFA везде, включённый NLA, актуальные патчи, отключённую встроенную запись Administrator и автоматический бан источников с повторяющимися отказами.

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