MFA для RDP: блокируйте несанкционированный удалённый доступ
Remote Desktop Protocol (RDP) остаётся одним из самых эксплуатируемых протоколов удалённого доступа в корпоративных средах. Злоумышленники непрерывно сканируют сеть в поисках открытого порта 3389, используют украденные учётные данные и пытаются осуществить латеральное перемещение через RDP-сессии. Одного пароля уже недостаточно.
Protectimus предлагает целевое MFA-решение именно для Remote Desktop. Компонент Protectimus Winlogon перехватывает аутентификацию на уровне Windows Credential Provider, добавляя надёжный второй фактор непосредственно в процесс входа через RDP — без изменения существующей архитектуры удалённого доступа.
Содержание
- Почему RDP — вектор атаки №1 в корпоративных сетях
- Как MFA от Protectimus работает с Remote Desktop Protocol
- Поддерживаемые методы аутентификации для RDP
- Сценарии развёртывания MFA для RDP
- Системные требования и совместимость
- Пошагово: как добавить MFA к RDP за 4 шага
- Расширенные опции настройки
- Комплаенс и стандарты безопасности
- Кейсы клиентов и сценарии использования
- Часто задаваемые вопросы
- Начните внедрение MFA для RDP уже сегодня
Короткий ответ
Разверните Protectimus Winlogon Agent на своих RDP-серверах, подключите его к облачному сервису Protectimus или on-premises платформе и включите принудительную MFA для RDP-сессий. Большинство организаций завершают настройку одного сервера менее чем за 2 часа.
Ключевые факты
Украденные учётные данные питают ransomware
73% жертв ransomware имели утечку учётных данных или заражение infostealer-вредоносным ПО в течение года до атаки
RDP — любимая точка входа ransomware
Более 90% инцидентов ransomware включают RDP в качестве вектора первичного доступа
Предупреждение CISA AA22-074A
CISA определяет RDP как основной вектор атаки и рекомендует MFA как важнейшее средство снижения риска
Ключевые преимущества
Без зависимости от VPN
Запрос MFA происходит на уровне Windows Credential Provider — до того, как откроется сессия.
Аварийный доступ
Одноразовые резервные коды предоставляют безопасный вариант восстановления доступа, когда обычную проверку MFA выполнить невозможно.
Полная совместимость с NLA
Работает с включённой Network Level Authentication — рекомендуемым базовым уровнем безопасности для всех RDP-развёртываний.
Широкое покрытие сервисов
Защищает AD, VPN-шлюзы, приложения, федерированные через ADFS, вход в Windows и RDP, OWA, а также кастомные веб-приложения.
Масштабируемое развёртывание
Protectimus Winlogon component поддерживает централизованное развёртывание через GPO, упрощая внедрение в крупных Windows-средах.
Гибкость развёртывания
Облачный SaaS или on-premises MFA-платформа с полным контролем над резидентностью данных.
Почему RDP — вектор атаки №1 в корпоративных сетях
В начале пандемии организации поспешно открывали RDP в интернет. Многие так и не закрыли этот доступ обратно. Сегодня сканеры безопасности постоянно обнаруживают миллионы хостов с доступным из публичного интернета портом 3389 — и злоумышленники точно знают, где искать.
Модель угроз для систем, открытых через RDP, делится на три категории, ни одну из которых не остановит один лишь пароль:
Credential stuffing и брутфорс.Злоумышленники перебирают списки учётных данных из предыдущих взломов — миллиарды пар логин/пароль, которыми торгуют на форумах даркнета и в Telegram-каналах. Надёжный пароль не даёт никакой защиты, если его повторно использовали с другого взломанного сайта. Инструменты вроде Hydra и Medusa пытаются тысячи комбинаций входа RDP в минуту против незащищённых от таких попыток конечных точек.
Pass-the-hash и Kerberoasting. Как только злоумышленник получает точку опоры на любой Windows-машине в вашей среде — через фишинг, уязвимое веб-приложение, что угодно — он может извлечь NTLM-хеши из памяти с помощью Mimikatz и аутентифицироваться на других Windows-системах через RDP, вообще не зная пароль в открытом виде. Одноразовый пароль на основе времени (TOTP), генерируемый заново каждые 30 секунд, нигде не хранится так, чтобы pass-the-hash мог до него добраться.
Уязвимости RDP. CVE-2019-0708 (BlueKeep) и CVE-2019-1181/1182 (DejaBlue) продемонстрировали, что сам RDP может содержать уязвимости до аутентификации, связанные с повреждением памяти. Патчинг остаётся основным средством контроля, но глубокая защита требует второго уровня аутентификации даже на полностью обновлённых серверах.
Список разрешённых IP-адресов — не замена MFA. Правила файрвола, разрешающие только известные корпоративные IP, не срабатывают в четырёх распространённых ситуациях: сотрудники с динамическими домашними IP от провайдера; деловые командировки; доступ сторонних поставщиков; и, что важнее всего, любой злоумышленник, уже скомпрометировавший машину в пределах разрешённого диапазона. Внутренний злоумышленник, перемещающийся латерально через RDP, попадает в тот же allowlist, которым пользуется ваш администратор.
NIST SP 800-63B прямо указывает на это: любая точка доступа RDP, доступная более чем из одной доверенной физической локации, должна требовать MFA.
Как MFA от Protectimus работает с Remote Desktop Protocol
Protectimus Winlogon Agent интегрируется на уровне Windows Credential Provider — подсистемы аутентификации между вводом данных пользователем и процессом входа Windows (winlogon.exe / LogonUI). Запрос MFA происходит после подачи учётных данных, но до того, как Windows предоставит сессию.
Поток аутентификации
Совместимость с NLA
NLA аутентифицирует пользователя до открытия полной сессии рабочего стола. Агент Protectimus полностью совместим с NLA и не требует её отключения. Пользователи вводят свои учётные данные Windows и OTP в рамках одного потока аутентификации. Оставляйте NLA включённой вместе с MFA — они покрывают разные части поверхности атаки (NLA снижает риск denial-of-service, MFA останавливает злоупотребление учётными данными).
Поскольку Protectimus работает на уровне Windows Credential Provider, он защищает как локальные входы Windows, так и сессии Remote Desktop с помощью одного механизма аутентификации. После успешной проверки OTP исходные учётные данные Windows продолжают проходить стандартный процесс аутентификации Windows, сохраняя совместимость с существующими процессами аутентификации Active Directory и локальных учётных записей.
Поддерживаемые методы аутентификации для RDP
Метод | Приложение / устройство | Рекомендовано для | Доступен для автоматической регистрации |
|---|---|---|---|
TOTP-приложение-аутентификатор | Protectimus SMART, Google Authenticator, и др. | Большинства пользователей и стандартных RDP-развёртываний | Да |
SMS OTP | Пользователей, которые не могут использовать приложения-аутентификаторы | Да | |
Email OTP | Пользователей без доступа к смартфонам или аппаратным токенам | Да | |
OTP через чат-бота | Protectimus BOT (Telegram, Viber, Facebook Messenger) | Промышленных, медицинских сред и сред без смартфонов | Нет |
Push-уведомления | Пользователей, предпочитающих аутентификацию одним касанием | Нет | |
Аппаратный токен (брелок) | Промышленных, медицинских сред и сред без смартфонов | Нет | |
Аппаратный токен (карта) | Сотрудников, которые уже носят пропуска или ID-карты | Нет |
Примечание: Автоматическая регистрация в настоящее время поддерживает Protectimus SMART OTP, SMS OTP и Email OTP. Push-уведомления, аппаратные токены и доставку OTP через чат-ботов в мессенджерах администраторы могут назначать вручную.
Аппаратные TOTP-токены особенно уместны для RDP в промышленных или медицинских средах, где смартфоны запрещены. Protectimus Slim NFC и Protectimus FLEX можно перепрограммировать через NFC при необходимости, позволяя повторно использовать тот же токен вместо замены.
Сценарии развёртывания MFA для RDP
Сценарий 1: отдельный Windows-сервер
Установите Protectimus Winlogon Agent на Windows-сервере, подключите его к сервису Protectimus или on-premises платформе и настройте пользователей и методы аутентификации. Все RDP-сессии — и локальные консольные входы — на этом сервере теперь требуют второй фактор. Типично для филиалов, jump-хостов или серверов малого бизнеса.
Сценарий 2: среда с несколькими серверами
В средах с несколькими Windows-серверами установите Protectimus Winlogon Agent на каждом сервере, принимающем входы пользователей. Все серверы можно подключить к одному Resource Protectimus, что позволяет администраторам централизованно управлять политиками MFA, пользователями и методами аутентификации, защищая каждую RDP-точку доступа.
Сценарий 3: развёртывание через Active Directory с помощью GPO
Для более крупных сред Protectimus поддерживает централизованное развёртывание через групповую политику. Администраторы могут установить компонент на контроллере домена и создать GPO для автоматического развёртывания на выбранных серверах и рабочих станциях. Это существенно снижает усилия на внедрение и обеспечивает согласованную защиту MFA во всей Windows-среде.
Примечание: Protectimus Winlogon защищает входы Windows и RDP-доступ на системах, где установлен компонент. Организации, стремящиеся к MFA-защите для всех сервисов, интегрированных с Active Directory, могут также рассмотреть MFA for Active Directory через компонент Protectimus DSPA, который принудительно применяет динамические одноразовые пароли на уровне каталога.
Системные требования и совместимость
Поддерживаемые ОС Windows (хост RDP)
ОС | Статус |
|---|---|
Windows Server 2022 | Полная поддержка |
Windows Server 2019 | Полная поддержка |
Windows Server 2016 | Полная поддержка |
Windows Server 2012 / 2012 R2 | Полная поддержка |
Windows 10 / 11 | Полная поддержка |
Windows 8 / 8.1 | Полная поддержка |
Поддерживаются как серверы, присоединённые к AD, так и отдельные рабочие группы. Изменений схемы Active Directory или кастомных расширений каталога не требуется.
Требования к серверу Protectimus (on-premises)
Компонент | Минимум |
|---|---|
CPU | 2 vCPU |
RAM | 8 ГБ |
Хранилище | 20 ГБ |
ОС | Linux, Windows, FreeBSD |
Java | JDK 8+ |
База данных | PostgreSQL 10+ |
Для облачного развёртывания никакая серверная инфраструктура, кроме Winlogon Agent на хосте RDP, не требуется.
Пошагово: как добавить MFA к RDP за 4 шага
Шаг 1: Разверните сервер аутентификации Protectimus
Выберите модель развёртывания:
Облако: зарегистрируйтесь на service.protectimus.com. Серверная инфраструктура не требуется. Бесплатный тариф включает до 10 пользователей, а новые аккаунты получают тестовый кредит $25 для оценки платных методов аутентификации и фильтров.
On-Premises: установите Protectimus On-Premise Platform на собственной инфраструктуре. Настройте базу данных, создайте учётную запись администратора и проверьте доступ к консоли управления.
После развёртывания создайте Resource, который будет использоваться для управления пользователями, токенами и политиками доступа Winlogon.
Шаг 2: Настройте политики доступа Winlogon
Откройте настройки Resource и перейдите на вкладку Winlogon.
Настройте необходимые политики доступа, включая:
- Включите доступ для локальных входов Windows и/или RDP-сессий.
- Включите двухфакторную аутентификацию.
- Настройте автоматическую регистрацию пользователей.
- Настройте автоматическую активацию токенов.
- Выберите методы аутентификации, доступные для автоматической регистрации (Protectimus SMART OTP, SMS OTP или Email OTP).
- Настройте доверенные IP-адреса, если требуется.
- Определите, требуется ли MFA для всех пользователей или только для выбранных учётных записей.
Для большинства развёртываний Protectimus рекомендует включать автоматическую регистрацию пользователей и токенов.
Шаг 3: Установите Protectimus Winlogon Agent
Загрузите последнюю версию инсталлятора Protectimus Winlogon и запустите его на Windows-сервере, который нужно защитить.
Во время установки укажите:
- API URL
- Логин учётной записи
- API-ключ
- ID ресурса
Также можно настроить:
- Политики MFA для локальных и RDP-входов
- Параметры офлайн-доступа
- Генерацию резервных кодов
- Принудительную MFA только для RDP
В средах Active Directory администраторы могут дополнительно развернуть компонент через групповую политику (GPO) или выполнить удалённую установку с контроллера домена.
Шаг 4: Зарегистрируйте пользователей и протестируйте аутентификацию
Если включена автоматическая регистрация, пользователям будет предложено активировать метод аутентификации во время первого успешного входа.
Организации, использующие аппаратные OTP-токены, push-уведомления или аутентификацию через чат-боты, могут создавать пользователей и назначать токены вручную.
После регистрации проверьте как локальные входы Windows, так и входы через Remote Desktop, чтобы подтвердить корректное применение политик MFA. Прежде чем завершить текущую сессию администратора, протестируйте аутентификацию с помощью второй учётной записи, чтобы избежать случайной блокировки из-за ошибок конфигурации.
Подробные скриншоты и примеры развёртывания — в fполном пошаговом гайде по интеграции RDP.
Расширенные опции настройки
Опция | Что она делает |
|---|---|
Отдельные политики для локальных входов и RDP | Настройте разные правила доступа для локальных входов Windows и сессий Remote Desktop. Например, требуйте MFA только для доступа через RDP, разрешая стандартные локальные входы. |
Автоматическая регистрация пользователей | Предлагает пользователям активировать поддерживаемый метод аутентификации при первом входе. |
Автоматическая активация токенов | Предлагает пользователям активировать поддерживаемый метод аутентификации при первом входе. |
Доверенные IP-адреса | Позволяет пользователям входить без OTP при подключении с указанных доверенных IP-адресов. |
Развёртывание через GPO | Централизованное развёртывание, обновление и удаление компонента Winlogon через групповую политику Active Directory. |
Удалённая установка | Установка компонента Winlogon напрямую на выбранных компьютерах домена с контроллера домена без ожидания обработки GPO. |
Защита установки | Предотвращает несанкционированное удаление компонента Winlogon с управляемых рабочих станций. |
Комплаенс и стандарты безопасности
MFA для RDP напрямую соответствует требованиям аутентификации в основных фреймворках:
NIST SP 800-63B — уровень уверенности 2+ требует MFA для удалённого доступа. Аутентификаторы на основе TOTP удовлетворяют требованию «нечто, что у вас есть». См. NIST SP 800-63B.
HIPAA Security Rule — требует технических средств контроля против несанкционированного доступа к ePHI через сеть. RDP к медицинским серверам передаёт ePHI; MFA — основное средство контроля. См. рекомендации HHS.
PCI DSS v4.0 — требование 8.4.2 предусматривает MFA для любого неконсольного административного доступа к среде обработки данных держателей карт. RDP явно является неконсольным.
SOC 2 (Type II)— CC6.1 (логический контроль доступа). Аудиторы отмечают RDP без MFA как проблему. Документированное развёртывание с журналированием событий обычно удовлетворяет требованию к доказательствам.
ISO 27001:2022— контроль Annex A 8.5 требует надёжной аутентификации для привилегированного и удалённого доступа.
NIS2 Directive (EU)— статья 21 требует MFA для субъектов критической и важной инфраструктуры. RDP к продакшн-системам явно попадает в область действия.
Кейсы клиентов и сценарии использования
Финансовые услуги: усиление защиты после инцидента на более чем 200 серверах
Региональная финансовая компания столкнулась с инцидентом credential stuffing: злоумышленник аутентифицировался на Windows-сервере через RDP, используя учётные данные из несвязанной утечки SaaS, и перемещался латерально в течение 40 минут, прежде чем сработало оповещение SIEM. CISO нужно было развернуть защиту на более чем 200 серверах менее чем за две недели без изменений схемы AD — модификация схемы заняла бы месяцы через их процесс контроля изменений. Команда развернула Winlogon Agent через MSI групповой политики. Пользователи активировали свои методы аутентификации во время первого успешного входа в Windows или RDP. В течение 10 дней каждый доступный через RDP сервер требовал второй фактор; 15 старших администраторов на торговой площадке получили аппаратные токены вместо приложений на смартфоне.
Здравоохранение: готовность к аудиту HIPAA
Многопрофильный медицинский провайдер обнаружил один пробел во время проверки на соответствие HIPAA Security Rule: доступ через RDP к серверам EMR без MFA. Их юридический отдел требовал, чтобы все данные аутентификации оставались on-premises, поскольку журналы аутентификации содержали бы чувствительную информацию о доступе пользователей и временные метки, связанные с системами, обрабатывающими ePHI. On-premises платформа Protectimus заработала менее чем за три часа. Внешний аудитор принял экспорт журнала событий как часть доказательств организации для контролей аудита HIPAA по 45 CFR § 164.312(b).
Производство: внедрение аппаратных токенов без смартфоновes
Производителю автозапчастей нужна была MFA для Windows-серверов на производственном цеху, где операторы не носят смартфоны и мобильный сигнал ненадёжен. Компания стандартизировалась на токенах Protectimus Slim NFC — в формате карты, которую носят вместе с пропусками. Токены предварительно активировал администратор; никакого шага активации со стороны конечного пользователя не потребовалось. Аппаратные TOTP-токены продолжают генерировать одноразовые пароли без интернета или мобильной связи, что делает их хорошо подходящими для сред, где смартфоны запрещены или мобильное покрытие ненадёжно.
FAQ
Работает ли MFA Protectimus с NLA (Network Level Authentication)?
Да, и NLA должна оставаться включённой. Protectimus Winlogon Agent интегрируется на уровне Windows Credential Provider, что совместимо с NLA. Пользователи вводят свои учётные данные Windows и OTP в рамках потока аутентификации до открытия сессии удалённого рабочего стола.
Что происходит, если сервер Protectimus недоступен?
Если сервис или on-premises платформа Protectimus временно недоступны, пользователи не могут завершить MFA стандартными методами аутентификации, пока соединение не будет восстановлено.
Для аварийных сценариев Protectimus поддерживает одноразовые резервные коды, которые можно использовать вместо OTP для доступа к защищённым системам Windows. Резервные коды генерируются во время установки Winlogon, и новый резервный код автоматически выдаётся каждый раз, когда использован предыдущий. Резервные коды следует хранить надёжно как часть плана непрерывности бизнеса организации.
Могу ли я использовать аппаратные токены вместо смартфона?
Да. Protectimus поддерживает все аппаратные токены стандарта OATH-TOTP, включая Protectimus TWO, FLEX, SHARK и Slim NFC. Аппаратные токены работают в средах, где смартфоны запрещены, и функционируют независимо от сетевого соединения.
Сколько времени занимает развёртывание на 50 серверах?
Скриптованное развёртывание или развёртывание через групповую политику на 50 серверах обычно завершается в течение одного рабочего дня. Инсталлятор поддерживает тихую установку с параметрами командной строки. Регистрация пользователей происходит параллельно с внедрением: пользователи активируют свои методы аутентификации во время первого успешного входа в Windows или RDP.
Есть ли on-premises вариант для требований к резидентности данных?
Да. Полную платформу Protectimus можно развернуть на собственной инфраструктуре, включая среды Linux, Windows и FreeBSD. Все данные аутентификации, журналы и записи пользователей остаются в пределах периметра вашей сети, обеспечивая тот же набор функций, что и облачный сервис.
В чём разница между MFA для RDP и Winlogon?
Компонент Protectimus Winlogonзащищает как локальные входы Windows, так и сессии Remote Desktop с помощью одного агента. Страница /winlogon/ охватывает все поддерживаемые сценарии аутентификации Windows. Эта страница сфокусирована именно на доступе через Remote Desktop, включая модель угроз для RDP, совместимость с Network Level Authentication (NLA), сценарии развёртывания и лучшие практики защиты RDP-сред. Полный гайд по установке — в MFA для входа в Windows и RDP.
Начните внедрение MFA для RDP уже сегодня
Облачный сервис Protectimus включает бесплатный тариф до 10 пользователей, что позволяет организациям проверить полное развёртывание на репрезентативном сервере перед более широким внедрением. Новые аккаунты также получают тестовый кредит $25 для оценки дополнительных методов аутентификации. On-premises MFA-платформа доступна для организаций с требованиями к резидентности данных.
Если ваша область действия выходит за пределы RDP — VPN, локальный вход в Windows, ADFS — та же платформа покрывает всё это из единой админ-консоли. MFA для Active Directory через компонент DSPA и RADIUS MFA for VPN доступны как часть более широкой экосистемы Protectimus.
Заключение
RDP остаётся самым прямым путём из интернета в вашу Windows-инфраструктуру. Украденного пароля достаточно, чтобы злоумышленник прошёл им. Второй фактор — 30-секундный TOTP-код, сгенерированный мобильным приложением или аппаратным токеном, — делает эту учётную запись бесполезной саму по себе.
Protectimus Winlogon Agent добавляет MFA на уровне Windows Credential Provider, защищая как локальные входы Windows, так и сессии Remote Desktop, оставаясь при этом полностью совместимым с Network Level Authentication (NLA). Решение можно развернуть за часы и масштабировать на крупные Windows-среды с помощью централизованных инструментов развёртывания.
Весь пошаговый гайд по установке — в полной инструкции по интеграции RDP →
