Безопасный RDP: шифрование, ограничение IP и двойная аутентификация

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

Ниже — практический порядок настройки для Windows-серверов и рабочих станций с RDP. Я не буду уходить в общие рассуждения: разберём именно шифрование, ограничение по IP и MFA/2FA.

Если вы настраиваете сервер удалённо, сначала убедитесь, что есть запасной способ входа: консоль виртуальной машины, iDRAC/iLO/IPMI, локальный администратор или доступ через коллегу. Ошибка в firewall-правиле может отрезать вас быстрее, чем атака извне.

Что именно нужно закрыть в RDP

У RDP есть три основные зоны риска:

• Перехват или подмена сессии. Пользователь должен подключаться к настоящему серверу, а не к машине злоумышленника в середине соединения.
• Прямой доступ к порту RDP из интернета. TCP/3389 — один из самых заметных портов. Его сканируют постоянно, даже если сервер никому не интересен.
• Кража или подбор пароля. Даже сложный пароль лучше не оставлять единственным барьером. Для админских и бухгалтерских доступов это особенно опасно.

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

Шифрование RDP: включите NLA, TLS и нормальные сертификаты

Современный RDP умеет шифровать сессию, но важно не просто «надеяться, что оно включено», а проверить настройки. На практике я смотрю три параметра: NLA, уровень безопасности RDP и сертификат сервера.

1. Включите Network Level Authentication

NLA — это проверка пользователя до создания полноценной RDP-сессии. Без NLA сервер сначала показывает экран входа, принимает попытки подключения и становится удобной мишенью для подбора паролей. С NLA аутентификация начинается раньше, нагрузка на сервер ниже, а атаковать его напрямую сложнее.

Проверьте так:

• откройте Свойства системы → Удалённый доступ;
• в разделе Remote Desktop выберите режим, где разрешены подключения только с компьютеров, использующих Remote Desktop с NLA;
• если серверов много, задайте это групповой политикой.

В групповых политиках путь обычно такой: Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security. Там нужны политики Require user authentication for remote connections by using NLA и Require use of specific security layer for remote (RDP) connections.

Если старые клиенты не проходят NLA, правильнее обновить клиенты, а не отключать NLA на сервере. Отключение NLA — это шаг назад, особенно если порт RDP хотя бы теоретически доступен извне.

2. Используйте TLS, а не устаревший RDP Security Layer

Для шифрования RDP лучше использовать TLS. В политиках безопасности это обычно настраивается через Require use of specific security layer for remote (RDP) connections. Для современных клиентов ставьте TLS.

Дополнительно проверьте политику Set client connection encryption level. Для обычной рабочей схемы ставьте High. Это не заменяет ограничение IP и MFA, но убирает лишнюю слабость на уровне самой сессии.

Если в организации остались старые терминальные клиенты или специфичное оборудование, не меняйте всё сразу. Сначала проверьте подключение с каждого типа клиента. Но для обычных Windows 10/11 и актуальных Windows Server TLS — нормальный базовый вариант.

3. Не привыкайте нажимать «Продолжить подключение» при предупреждении сертификата

Шифрование защищает трафик, но пользователю ещё нужно понимать, что он подключился именно к своему серверу. Если RDP показывает предупреждение о сертификате, это значит, что клиент не может доверенно проверить сервер.

В маленькой среде часто используют самоподписанный сертификат RDP. Это лучше, чем ничего, но хуже, чем нормальная схема с доверенным сертификатом. Для production-серверов лучше поставить сертификат, которому доверяют клиентские машины: выданный внутренним CA или публичным удостоверяющим центром.

Проверьте два момента:

• имя в сертификате должно совпадать с именем, по которому пользователи подключаются;
• клиенты не должны отключать проверку подлинности сервера.

Если используется RD Gateway, сертификат ставится на шлюз, потому что пользователи сначала подключаются к нему по HTTPS, обычно TCP/443.

Ограничение IP: не открывайте 3389 всему интернету

Самая частая ошибка — оставить RDP доступным по адресу 0.0.0.0/0, то есть «для всех». Даже если пароль сложный, это плохая привычка: порт будут сканировать, пробовать типовые учётные записи, искать уязвимости и собирать информацию о системе.

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

Если у офиса статический IP

Разрешите доступ только с этого адреса. В IPv4 это обычно формат x.x.x.x/32, в IPv6 — x:x:x::x/128. Например, если офис выходит в интернет с одного адреса, нет смысла открывать RDP для всего диапазона провайдера.

Ограничение можно поставить в нескольких местах:

• на облачной группе безопасности: AWS Security Group, Azure NSG, GCP Firewall;
• на внешнем firewall или маршрутизаторе;
• в Windows Firewall на самом сервере;
• на VPN-шлюзе или RD Gateway.

Лучше использовать два уровня: внешний firewall не пускает TCP/3389 из интернета, а Windows Firewall дополнительно ограничивает доступ на уровне сервера. Это не избыточность, а нормальная защита от случайных ошибок и лишних правил.

Если IP у пользователей динамический

Не пытайтесь решить это широким диапазоном провайдера. Так часто делают «для удобства», но в итоге получают почти тот же риск, что и при открытом порту.

Для динамических адресов нормальные варианты такие:

• VPN с двойной аутентификацией, а уже внутри VPN — RDP;
• RD Gateway с MFA;
• bastion-сервер с ограниченным доступом;
• облачный доступ через приватную сеть без публичного IP у серверов.

Если нужен временный доступ подрядчику, выдавайте его на конкретный срок и конкретный адрес, если он известен. После окончания работ правило нужно удалить. Временные firewall-правила имеют неприятное свойство становиться постоянными, если про них забыть.

Двойная аутентификация: где её ставить для RDP

NLA — это не двойная аутентификация. NLA проверяет пользователя до сессии, но обычно всё равно использует один фактор: пароль, смарт-карту или другой механизм входа. MFA/2FA добавляет второй фактор: код из приложения, push-подтверждение, аппаратный ключ, звонок или другой способ.

Для RDP есть несколько рабочих схем.

VPN с MFA — самый простой вариант для небольшой команды

Если у вас 5–20 человек и нет отдельной инфраструктуры RD Gateway, часто разумнее поставить MFA на VPN. Пользователь подключается к VPN, проходит двойную аутентификацию, а RDP остаётся доступным только из VPN-сети.

В этом случае внешний firewall не должен пропускать TCP/3389 из интернета. Он должен пускать только VPN-протоколы, которые вы используете. Внутри VPN можно дополнительно ограничить RDP только нужными серверами.

RD Gateway + MFA — лучше для серверной инфраструктуры

Если пользователей больше, серверов несколько, есть разные группы доступа и нужен журнал подключений, удобнее использовать RD Gateway. Пользователи подключаются не напрямую к каждому серверу, а к шлюзу. Шлюз уже решает, кому куда можно заходить.

Для MFA часто используют связку RD Gateway + NPS. Например, NPS может работать с Azure MFA через расширение NPS Extension for Azure MFA. Также встречаются решения вроде Duo, AuthLite и другие MFA-провайдеры, которые умеют защищать RDP или RD Gateway.

Здесь есть нюанс: выбирайте тот вариант MFA, который реально защищает именно RDP-сценарий. Иногда поставщик показывает красивую веб-страницу с кодом, но она не встроена в Windows logon или RD Gateway. Для RDP это не то, что нужно.

Conditional Access не всегда защищает обычный RDP

Если речь про Azure Virtual Desktop или Windows 365, Conditional Access может быть частью схемы доступа. Но для классического RDP до локального Windows Server нельзя автоматически считать, что облачные правила Microsoft Entra ID сами защитят вход. Для обычного сервера чаще используют VPN + MFA, RD Gateway + NPS/MFA или сторонний MFA-провайдер, встроенный в процесс входа.

Практический порядок настройки

1. Определите, кто и откуда подключается. Составьте список пользователей, серверов и адресов. Если адресов нет или они постоянно меняются, сразу смотрите в сторону VPN или RD Gateway.
2. Закройте публичный RDP. Уберите TCP/3389 из правил «для всех». Если сервер в облаке, проверьте security group/NSG/firewall. Если сервер за NAT, проверьте и внешний firewall, и проброс портов.
3. Включите NLA. Это базовая настройка для современных Windows-серверов. Без неё RDP становится заметно более уязвимым к подбору и лишней нагрузке.
4. Настройте TLS и высокий уровень шифрования. Для актуальных клиентов используйте TLS. Устаревшие TLS 1.0/1.1 лучше отключать после проверки совместимости.
5. Поставьте до