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 підтримує централізоване розгортання через 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) | Користувачів, які надають перевагу отриманню OTP у месенджерах | Ні |
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 для 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. Перш ніж завершити поточну сесію адміністратора, протестуйте автентифікацію за допомогою другого облікового запису, щоб уникнути випадкового блокування через помилки конфігурації.
Детальні скриншоти й приклади розгортання — у повному покроковому гіді з інтеграції RDP.
Розширені опції налаштування
Опція | Що вона робить |
|---|---|
Окремі політики для локальних входів і RDP | Налаштуйте різні правила доступу для локальних входів Windows та сесій Remote Desktop. Наприклад, вимагайте MFA лише для доступу через RDP, дозволяючи стандартні локальні входи. |
Автоматична реєстрація користувачів | Автоматично створює облікові записи користувачів у Protectimus під час першого входу. |
Автоматична активація токенів | Пропонує користувачам активувати підтримуваний метод автентифікації під час першого входу. |
Довірені IP-адреси | Дозволяє користувачам входити без OTP при підключенні з визначених довірених IP-адрес. |
Розгортання через GPO | Централізоване розгортання, оновлення та видалення компонента Winlogon через групову політику Active Directory. |
Віддалене встановлення | Встановлення компонента Winlogon безпосередньо на обраних комп’ютерах домену з контролера домену без очікування обробки GPO. |
Захист встановлення | Запобігає несанкціонованому видаленню компонента Winlogon з керованих робочих станцій. |
Комплаєнс і стандарти безпеки
MFA для RDP безпосередньо відповідає вимогам автентифікації в основних фреймворках:
NIST SP 800-63B — рівень впевненості 2+ вимагає MFA для віддаленого доступу. Автентифікатори на основі TOTP задовольняють вимогу “щось, що ви маєте”.See 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).
Виробництво: впровадження апаратних токенів без смартфонів
Виробнику автозапчастин потрібна була MFA для Windows-серверів на виробничому цеху, де оператори не носять смартфони й мобільний сигнал ненадійний. Компанія стандартизувалася на токенах Protectimus Slim NFC — у форматі картки, яку носять разом із перепустками. Токени попередньо активував адміністратор; жодного кроку активації з боку кінцевого користувача не було потрібно. Апаратні TOTP-токени продовжують генерувати одноразові паролі без інтернету чи мобільного зв’язку, що робить їх добре придатними для середовищ, де смартфони заборонені чи мобільне покриття ненадійне.
Часті запитання
Чи працює 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 для VPN доступні як частина ширшої екосистеми Protectimus.
Висновок
RDP залишається найпрямішим шляхом з інтернету у вашу Windows-інфраструктуру. Викраденого пароля достатньо, щоб зловмисник пройшов ним. Другий фактор — 30-секундний TOTP-код, згенерований мобільним застосунком чи апаратним токеном, — робить цей обліковий запис марним сам по собі.
Protectimus Winlogon Agent додає MFA на рівні Windows Credential Provider, захищаючи і локальні входи Windows, і сесії Remote Desktop, залишаючись при цьому повністю сумісним з Network Level Authentication (NLA). Рішення можна розгорнути за години й масштабувати на великі Windows-середовища за допомогою централізованих інструментів розгортання.
Повний покроковий гід зі встановлення — у повній інструкції з інтеграції RDP →
