Удаленный доступ без лишнего риска: как защитить RD Gateway и RDP с помощью двухфакторной аутентификации

RDP и RD Gateway остаются одной из уязвимых точек входа в корпоративную инфраструктуру — особенно если удаленный доступ открыт из интернета и защищен только паролем. В такой схеме одной утечки учетных данных или успешного брутфорса достаточно, чтобы злоумышленник получил доступ к серверу. В статье разбираемся, как работает двухфакторная аутентификация для удаленных рабочих столов, какие схемы используют для защиты RDP и как внедрить 2FA без лишней нагрузки на сотрудников.

Почему RD Gateway и RDP требуют дополнительной защиты

Remote Desktop Protocol (RDP) и Remote Desktop Gateway (RD Gateway) стали стандартом для удаленной работы и администрирования Windows-инфраструктуры. Через них сотрудники подключаются к рабочим столам, подрядчики — к внутренним системам, а администраторы — к серверам и терминальным узлам.

Проблема в том, что именно удаленный доступ остается одной из самых уязвимых точек инфраструктуры. Если у RDP есть «выход наружу» или RD Gateway защищен только паролем, злоумышленнику не нужно искать сложную уязвимость — достаточно получить учетные данные. Источником могут стать:

• утечки паролей;

• фишинг;

• перебор слабых комбинаций;

• зараженный компьютер сотрудника.

Особенно опасны такие сценарии для компаний, где к инфраструктуре подключаются удаленные сотрудники, подрядчики или техническая поддержка. Один скомпрометированный аккаунт может открыть доступ сразу ко всей внутренней сети.

Вот возможные риски для RDP и RD Gateway:

Именно поэтому защита RDP двухфакторной аутентификацией — необходимая практика для корпоративного удаленного доступа. Даже если пароль сотрудника утек, одного логина и пароля уже недостаточно для подключения к серверу или RD Gateway.

На практике MFA для RDP и Windows Server обычно строится через отдельный RADIUS-сервер или интеграцию с системой аутентификации. После ввода пароля пользователь дополнительно подтверждает вход — например, через TOTP-код, push-уведомление или аппаратный токен.

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

Двухфакторная аутентификация

ID — защита учетных записей сотрудников: подключений через VPN, RDG, ActiveSync, ADFS (протоколы OpenID Connect, SAML), защита входа в Windows, OWA.

Оставить заявку

Какие варианты 2FA используют для защиты RDP и RD Gateway

Как работает 2FA для RDP и RD Gateway

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

Для Remote Desktop Gateway это выглядит так:

1. Сотрудник отправляет запрос на подключение к RD Gateway.

2. RD Gateway получает запрос и передает его в NPS или RADIUS-сервер для проверки правил доступа.

3. NPS определяет сценарий аутентификации и передает запрос в систему MFA.

4. Система отправляет пользователю запрос на подтверждение второго фактора — например, TOTP-код или push-уведомление.

5. После успешной проверки пользователь получает доступ к RDP-сессии.

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

Например, сотрудник использует одинаковый пароль для корпоративного RDP и внешнего сайта. После очередной утечки логин и пароль оказываются в открытых базах, а бот начинает автоматически проверять их на RD Gateway компании. Если второй фактор не включен, злоумышленник получает полноценный удаленный доступ к серверу. Поэтому в некоторых компаниях MFA для RDP становится базовым требованием безопасности — особенно для удаленного доступа администраторов и подрядчиков.

Вот возможные варианты второго фактора:

Для двухфакторной аутентификации RD Gateway компании обычно выбирают либо отдельную MFA-платформу, либо сервис, который уже интегрируется с Active Directory, RADIUS и корпоративными политиками доступа.

Например, в Контур.ID можно создать единые правила MFA для сотрудников, подрядчиков и администраторов: подключать push-подтверждения, TOTP или резервные способы входа, а также централизованно управлять сценариями аутентификации пользователей.

Какие методы аутентификации используют на практике

Выбор второго фактора зависит не только от уровня защиты, но и от того, как сотрудники реально работают с инфраструктурой.

Если сотрудники постоянно подключаются к RD Gateway с ноутбуков и телефонов, удобнее работают push-подтверждения или TOTP-коды. Пользователь получает запрос в приложении и подтверждает вход за несколько секунд — без SMS и дополнительных устройств.

Для администраторов удаленного доступа требования обычно жестче. Здесь выбор второго фактора зависит от требований компании и сценариев работы: могут использоваться аппаратные токены, сертификаты, Рутокен, TOTP или другие способы подтверждения входа. Это связано с тем, что компрометация привилегированной учетной записи может дать злоумышленнику доступ сразу к критичным системам инфраструктуры.

Отдельный сценарий — закрытые контуры и сегменты без выхода в интернет. В таких сетях двухфакторная аутентификация для RDP без интернета обычно строится на локальной проверке TOTP-кодов или аппаратных ключах без облачного сервиса.

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

Как внедрить 2FA для Remote Desktop Gateway

Базовая схема настройки RD Gateway с NPS / RADIUS

В большинстве инфраструктур настройка 2FA для Remote Desktop Gateway строится через связку RD Gateway, NPS и RADIUS-сервера.

Упрощенно схема выглядит так:

Пользователь → RD Gateway → NPS/RADIUS → MFA-сервис → RDP-сервер 

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

В типовой инструкции по настройке обычно есть несколько этапов:

• установка и настройка NPS;

• подключение RADIUS-сервера;

• создание политик доступа;

• настройка портов и сертификатов;

• подключение MFA;

• тестирование RDP-клиентов.

Но на практике сложность возникает не в самой схеме, а в эксплуатации. Например, сотрудник меняет телефон и не переносит TOTP-приложение. После этого он не может подключиться к терминальному серверу, а ИБ-специалистам приходится срочно выдавать резервный доступ. Поэтому перед внедрением важно заранее определить, кто будет подключаться, откуда, к каким системам и какие сценарии требуют резервного доступа.

Как перейти с обычного RDP на 2FA без остановки работы

Одна из возможных ошибок при внедрении MFA для RD Gateway — попытка включить ее сразу для всей инфраструктуры. Намного безопаснее работает поэтапная схема:

1. сначала — администраторы;

2. затем — подрядчики;

3. после этого — сотрудники на удаленной работе;

4. в конце — остальные RDP-сценарии.

Так проще протестировать совместимость, проверить нагрузку и не заблокировать пользователей из-за ошибок настройки.

Например, если компания использует старые терминальные серверы или нестандартные RDP-клиенты, часть сотрудников может просто потерять возможность подключаться после включения MFA. Поэтому перед массовым внедрением обычно создают тестовую группу и проверяют:

• как работает вход;

• что происходит при потере второго фактора;

• как выглядит резервный сценарий доступа;

• насколько стабильно работает RADIUS-аутентификация.

Отдельно стоит продумать аварийный доступ. Если сотрудник потерял телефон или не может подтвердить вход, у ИБ-специалистов и администраторов должна быть безопасная резервная схема, а не временное отключение MFA «на пару часов».

2FA для RDP без интернета и защита от брутфорса

В некоторых компаниях удаленный доступ работает не только через облачные сервисы. Производственные сегменты, изолированные сети, КИИ и внутренние контуры часто вообще не имеют выхода в интернет. Но это не отменяет необходимость защищать RDP и RD Gateway. В таких сценариях двухфакторная аутентификация для RDP без интернета обычно строится на локальной проверке второго фактора:

• TOTP-кодах;

• аппаратных токенах;

• сертификатах;

• Рутокенах и PKI-инфраструктуре.

Например, администратор подключается к серверу в закрытом контуре. После ввода пароля система запрашивает одноразовый код из приложения или подтверждение через аппаратный ключ. Проверка проходит локально, без обращения к внешнему облачному сервису при каждой попытке входа. Такой подход особенно важен для инфраструктур, где:

• нельзя передавать данные наружу;

• есть ограничения по регуляторике;

• нестабильно работает интернет;

• критичен непрерывный доступ к системам.

Но даже при использовании MFA нельзя ограничиваться только вторым фактором. Защита RDP от брутфорса дает оптимальный результат в сочетании с другими мерами безопасности. Минимальный набор обычно включает:

• запрет прямого RDP-доступа из интернета;

• публикацию RDP только через RD Gateway или VPN;

• сегментацию сети;

• ограничение IP-адресов;

• отдельные политики для администраторов;

• журналирование подключений.

Например, если RDP-сервер открыт наружу на стандартном порту и защищен только SMS-2FA, инфраструктура все равно остается удобной целью для автоматизированных атак. Боты могут бесконечно проверять логины, перегружать сервис запросами и искать ошибки в настройке доступа, но даже если злоумышленник подберет пароль, второй фактор не даст подключиться к RDP без подтверждения входа.

Именно поэтому лучшие практики двухфакторной аутентификации RDP — это не отдельный «второй код», а полноценный контроль удаленного доступа.

Практические сценарии и лучшие практики

Какие решения используют для защиты RD Gateway

Для защиты RD Gateway и RDP компании могут использовать три типа решений:

• встроенные механизмы Microsoft;

• отдельные MFA-платформы;

• специализированные системы контроля доступа.

Для базовых сценариев компании иногда используют расширение NPS для Microsoft MFA. Но в крупных инфраструктурах этого часто недостаточно: нужны единые политики доступа, резервные методы входа, аудит подключений и централизованное управление сотрудниками. Поэтому компании нередко используют отдельные MFA-решения. Они позволяют подключать разные типы второго фактора, управлять доступом через RADIUS-сервер и быстрее масштабировать защиту на новые сервисы.

Например, в небольшой инфраструктуре с несколькими терминальными серверами компании может хватить базовой MFA через NPS и RADIUS. Но если к RD Gateway регулярно подключаются подрядчики, администраторы и удаленные сотрудники из разных филиалов, обычно нужны более гибкие политики доступа: отдельные правила для разных типов пользователей, резервные сценарии входа и централизованное управление аутентификацией.

Если задача — защитить не только RDP, но и весь корпоративный удаленный доступ, удобнее использовать единую систему аутентификации. Например, Контур.ID позволяет централизованно управлять двухфакторной аутентификацией для сотрудников, подрядчиков и администраторов, добавлять новые способы подтверждения входа и контролировать политики доступа из одного интерфейса.

Бесплатные сервисы 2FA для RD Gateway тоже встречаются — например, на базе multiOTP или отдельных open source-компонентов. Но такие схемы обычно требуют больше ручной настройки и сложнее поддерживаются в крупной инфраструктуре.

Что важно учесть при внедрении 2FA для удаленного доступа

На практике пользователи редко сопротивляются внедрению самой двухфакторной аутентификации как таковой. Проблемы могут возникнуть, когда защита внедряется без учета рабочих сценариев. Например, подрядчику нужен доступ к серверу на две недели для обновления бухгалтерской системы. Без MFA, отдельных учетных записей и ограничений по времени такой доступ иногда сохраняется в инфраструктуре месяцами.

Другие возможные проблемы тоже обычно связаны не с самой MFA, а с организацией доступа:

• подрядчик не может срочно подключиться к серверу;

• сотрудник меняет телефон и теряет доступ;

• резервный код хранится в общем чате;

• администраторы используют одну учетную запись на нескольких человек.

В результате защита формально есть, но реальные риски никуда не исчезают. Чтобы этого избежать, при внедрении MFA для RD Gateway и RDP стоит заранее определить:

1. кто и к каким системам подключается;

2. какие способы входа разрешены;

3. как работает резервный доступ;

4. какие действия логируются;

5. как быстро можно отключить скомпрометированную учетную запись.

Отдельное внимание обычно уделяют администраторам удаленного доступа. Для них часто вводят более строгие политики: отдельные учетные записи, обязательную MFA, аппаратные токены, ограничения по IP, запись и аудит подключений.

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

Информационная безопасность бизнеса

Контур.Эгида — сервисы информационной безопасности: уменьшение рисков внутренних угроз и утечек конфиденциальных данных, предотвращение атак злоумышленников.

Оставить заявку

Заключение

RDP и RD Gateway остаются одной из самых уязвимых точек корпоративной инфраструктуры — особенно если удаленный доступ защищен только паролем. Двухфакторная аутентификация помогает заметно снизить риск компрометации учетных записей, брутфорса и несанкционированного доступа к серверам.

При этом сама MFA работает эффективно только вместе с другими мерами: сегментацией сети, контролем доступа, аудитом подключений и продуманными политиками безопасности. Чем раньше компания выстроит такую систему для удаленного доступа, тем меньше шансов, что обычный RDP-вход станет причиной серьезного инцидента.