RADIUS-автентифікація з MFA: захист кожної точки доступу до мережі
RADIUS — протокол, що непомітно обробляє автентифікацію для більшості корпоративних VPN, Wi-Fi-мереж та мережевої інфраструктури, — був створений в іншу епоху. Свою роботу він виконує надійно: мережевий пристрій надсилає облікові дані на RADIUS-сервер, сервер звіряє їх з каталогом, і доступ надається чи забороняється. Чого він не робить — це не перевіряє, що людина, яка вводить ці облікові дані, справді є тим, за кого себе видає. Викрадений пароль так само дієвий, як і справжній.
Додавання MFA до RADIUS закриває цю прогалину. Замість заміни наявної інфраструктури RADIUS-проксі розташовується між вашими мережевими пристроями та каталогом — примусово застосовуючи другий фактор до кожного запиту автентифікації, перш ніж видається Access-Accept.
Зміст
- Що таке RADIUS-автентифікація і чому їй потрібна MFA
- Як Protectimus додає MFA до RADIUS-автентифікації
- Підтримувані методи MFA для RADIUS
- Підтримувані RADIUS-клієнти та мережеве обладнання
- RADIUS MFA для VPN
- RADIUS MFA для бездротового мережевого доступу
- Варіанти розгортання
- Системні вимоги та інтеграція
- Покроково: як налаштувати RADIUS MFA за 5 кроків
- Комплаєнс: як RADIUS MFA відповідає регуляторним вимогам
- Часті запитання
- Почніть захищати доступ до вашої мережі вже сьогодні
Коротка відповідь
RADIUS (Remote Authentication Dial-In User Service) — основа контролю мережевого доступу в більшості корпоративних середовищ, що обробляє автентифікацію для VPN, корпоративного Wi-Fi, мережевих пристроїв доступу, NPS та VDI-шлюзів. Сам протокол, визначений у RFC 2865, був розроблений за десятиліття до того, як атаки на основі облікових даних стали нормою. Додавання MFA поверх RADIUS сьогодні означає вставлення другого кроку перевірки між мережевим пристроєм і вашим каталогом — без заміни наявної інфраструктури. Protectimus працює як RADIUS-проксі: ваш файрвол Cisco, шлюз Fortinet чи файрвол Palo Alto продовжують спілкуватися по RADIUS точно так само, як і раніше, тоді як другий фактор примусово застосовується на рівні проксі перед видачею RADIUS Access-Accept.
Ключові факти
Облікові дані — вектор атаки №1
Атаки на основі облікових даних — включно з фішингом, credential stuffing та password spraying — послідовно посідають перші місця серед векторів первинного доступу для зламів мереж, при цьому VPN-точки доступу є основною ціллю.
AAL2 вимагає MFA
NIST SP 800-63B Authenticator Assurance Level 2 (AAL2) прямо вимагає багатофакторної автентифікації для будь-якого мережевого доступу до чутливих систем.
Інфраструктура VPN під атакою
Рекомендація CISA щодо безпеки VPN зазначає, що зловмисники регулярно цілять в інфраструктуру віддаленого доступу саме тому, що їй часто бракує другого фактора автентифікації.
Ключові переваги
Жодних змін інфраструктури не потрібно
Protectimus працює як RADIUS-проксі; ваші наявні VPN-шлюзи, бездротові контролери та мережеві комутатори зберігають свою конфігурацію.
Швидке розгортання
Багато організацій можуть впровадити RADIUS MFA протягом одного робочого дня, залежно від складності інфраструктури та вимог інтеграції.
Незалежність від вендора
Задокументовані й протестовані інтеграції з Cisco ASA/FTD, Juniper, Fortinet FortiGate, Palo Alto GlobalProtect, SonicWall, Check Point, F5 та багатьма іншими платформами.
Повна синхронізація з AD/LDAP
Провіжінінг користувачів, групові політики та пошук у каталозі — усе це підтягується з наявної Active Directory чи LDAP.
On-premises чи хмара
Доступні варіанти розгортання, що дозволяють організаціям обрати архітектуру, яка найкраще відповідає їхнім вимогам безпеки й операційним потребам.
Розроблено для VPN
та інших сценаріїв віддаленого доступу на основі RADIUS.
Що таке RADIUS-автентифікація і чому їй потрібна MFA
RADIUS — це клієнт-серверний протокол, що централізує автентифікацію, авторизацію та облік (AAA) для мережевого доступу. Коли користувач підключається до VPN, автентифікується в корпоративному Wi-Fi чи входить у комутатор через інтерфейс управління, мережевий пристрій (званий NAS — Network Access Server) надсилає пакет Access-Request на RADIUS-сервер. Цей сервер перевіряє облікові дані й відповідає одним із трьох повідомлень: Access-Accept (дозволити вхід), Access-Reject (відмовити) чи Access-Challenge (запросити додаткову інформацію, наприклад OTP).
Це охайний, перевірений часом протокол. Але його первинний дизайн передбачав, що дійсна комбінація логін/пароль є достатнім доказом ідентичності. У 2026 році це припущення неспроможне.
Чому самих лише паролів недостатньо для захисту сервісів, автентифікованих через RADIUS
Credential stuffing — атака, через яку команди мережевої безпеки не сплять ночами. Зловмисники купують чи збирають списки викрадених пар логін/пароль — мільярди з них вільно торгуються на кримінальних форумах — і автоматизують спроби входу проти VPN-точок доступу. У більшості VPN-шлюзів немає достатньо жорстких політик блокування, щоб зупинити повільні “low-and-slow” атаки. Навіть 0,5% успіху проти списку з 50 000 облікових даних дає зловмисникам 250 дійсних VPN-сесій.
Password spraying — тихіший варіант: замість атаки на один обліковий запис, зловмисники пробують один типовий пароль (наприклад, Autumn2024!) на тисячах облікових записів. Це обходить більшість порогів блокування облікових записів і майже непомітне в журналах.
Окрім масових атак навмання, цілеспрямовані зловмисники використовують фішинг для збору доменних облікових даних, а потім переходять безпосередньо до доступу через VPN чи Wi-Fi — повністю обходячи периметровий захист.
Сам RADIUS не має механізму примусового застосування другого фактора. Він передає облікові дані бекенд-каталогу, отримує назад Accept/Reject — і на цьому розмова завершується. Один із поширених способів додати MFA до RADIUS — розгорнути RADIUS-проксі, який перехоплює Access-Request, перевіряє пароль вище за потоком, а потім примусово застосовує запит OTP перед видачею Access-Accept.
Як Protectimus додає MFA до RADIUS-автентифікації
Потік автентифікації
VPN- / Wi-Fi-клієнт
Cisco ASA / FortiGate / UniFi тощо
Перевіряє пароль через AD / LDAP
Повертає Access-Challenge (OTP)
Перевіряє OTP
Повертає Access-Accept
Крок 1 — Перевірка облікових даних. Protectimus пересилає пароль користувача до Active Directory чи LDAP для основної автентифікації. Якщо пароль не пройшов перевірку, запит негайно відхиляється. Запит MFA для невдалих паролів не видається — це запобігає атакам на перебір (enumeration).
Крок 2 — Запит MFA. Після успішної перевірки пароля Protectimus надсилає Access-Challenge назад до мережевого пристрою із запитом другого фактора. Користувач вводить свій TOTP-код із MFA-застосунку, апаратного OTP-токена чи OTP через чат-бота/SMS/email.
Крок 3 — Прийняти чи відхилити. Якщо другий фактор пройшов перевірку, видається Access-Accept. Якщо ні — Access-Reject. Мережевий пристрій застосовує результат.
Одна важлива технічна примітка: потік Access-Challenge вимагає, щоб пристрій NAS підтримував RADIUS challenge/response. Більшість сучасних VPN-клієнтів (Cisco AnyConnect, Fortinet SSL VPN, Palo Alto GlobalProtect) обробляють це нативно. Для пристроїв, що не підтримують RADIUS Access-Challenge, Protectimus підтримує Inline-режим. У цьому режимі користувачі вводять пароль та OTP в одному полі, використовуючи налаштовуваний розділювач (наприклад, password,otp). Такий підхід дозволяє примусово застосовувати MFA навіть на застарілих системах, що підтримують лише одинарний обмін автентифікацією.
Підтримувані методи MFA для RADIUS
Різні сценарії мережевого доступу вимагають різних методів другого фактора. VPN-тунельний клієнт не має вебінтерфейсу браузера. Клієнт 802.1X для корпоративного Wi-Fi має ще менше можливостей. Таблиця нижче зіставляє методи зі сценаріями.
| Метод | Як працює | Найкраще підходить для | Примітки |
|---|---|---|---|
| Застосунок-автентифікатор (TOTP) | 30-секундний код, що змінюється, з застосунку-автентифікатора | VPN та інші підтримувані сервіси, захищені RADIUS | Працює практично з будь-яким RADIUS-клієнтом; інтернет не потрібен після реєстрації |
| Апаратні токени (TOTP) | 30-секундний код, що змінюється, з фізичного TOTP-пристрою | Air-gapped середовищ, користувачів без смартфонів | Підтримує Protectimus Two, Slim NFC, Flex, Shark та сторонні OATH-сумісні токени |
| SMS OTP | 6-значний код через SMS | VPN та інші підтримувані сервіси, захищені RADIUS | Потрібен мобільний сигнал; працює з Inline-режимом |
| Email OTP | 6-значний код на emaill | VPN та інші підтримувані сервіси, захищені RADIUS | Підходить там, де SMS недоступне |
| Chatbot OTP | OTP через Telegram, Viber чи Facebook Messenger | VPN та інші підтримувані сервіси, захищені RADIUS | Без витрат на SMS чи залежності від мобільного оператора |
Саме для VPN: TOTP (через застосунок чи апаратний токен) та OTP через чат-бота/SMS/email працюють як у режимі challenge/response, так і в Inline-режимі.
Підтримувані RADIUS-клієнти та мережеве обладнання
Protectimus має задокументовані інтеграції та протестований з наведеним нижче мережевим обладнанням. Повний гід з інтеграції RADIUS MFA містить покрокову конфігурацію для кожного.
Вендор | Продукт / функція | Тип доступу |
|---|---|---|
Cisco | VPN | |
Cisco | Адміністративний доступ | |
Juniper | VPN | |
Fortinet | VPN | |
Palo Alto | VPN | |
SonicWall | VPN | |
Check Point | VPN | |
F5 | VPN / проксі застосунків | |
Citrix | VPN / проксі застосунків | |
Ubiquiti | Гостьовий Wi-Fi | |
Array Networks | VPN |
Цей список охоплює найпоширеніші розгортання. Будь-який пристрій, що надсилає стандартні RADIUS-запити за RFC 2865, працюватиме, навіть якщо його немає в цьому списку.
Примітка: Деякі RADIUS-based розгортання ще не включені до наших задокументованих інтеграцій. Оскільки Protectimus працює як стандартизований RADIUS-проксі, додаткові RADIUS-архітектури — включно з розгортаннями на основі FreeRADIUS чи Microsoft NPS — також можуть бути сумісними. Якщо ви плануєте одне з таких розгортань, зв’яжіться з нашою командою, щоб обговорити ваше конкретне середовище.
RADIUS MFA для VPN
VPN — безумовно найпоширеніше розгортання RADIUS MFA, і водночас найкритичніше з точки зору безпеки. Скомпрометована VPN-сесія дає зловмиснику ту саму мережеву позицію, що й у легітимного віддаленого співробітника, — з доступом до файлових ресурсів, внутрішніх вебзастосунків, баз даних і шляхів для латерального переміщення.
Як MFA працює через VPN (без браузера)
Коли користувач підключається через Cisco AnyConnect чи SSL VPN-клієнт Fortinet, з’єднання ініціюється на рівні ОС чи клієнтського застосунку. Тут немає ані браузера, ані JavaScript, ані redirect URI. VPN-клієнт надсилає облікові дані безпосередньо на NAS, який пересилає їх як RADIUS Access-Request.
З увімкненою підтримкою challenge/response у VPN-клієнті потік працює точно так, як описано в розділі про архітектуру: користувач бачить другий запит (“Введіть ваш OTP”) в інтерфейсі VPN-клієнта після введення пароля. Більшість сучасних VPN-клієнтів коректно відображають це поле, і користувачі знаходять це інтуїтивно зрозумілим.
Для застарілих VPN-клієнтів, що не підтримують RADIUS Access-Challenge, Protectimus надає Inline-режим. Користувачі вводять пароль та OTP в одному полі автентифікації, використовуючи налаштований розділювач. Це дозволяє організаціям розгорнути MFA без заміни наявної VPN-інфраструктури.
Переконайтеся, що VPN-шлюз завжди може досягти RADIUS-сервера Protectimus (UDP 1812/1813, якщо використовується облік), незалежно від конфігурації маршрутизації VPN.
Перегляньте повний посібник з інтеграції RADIUS MFA і MFA для Cisco AnyConnect VPN для конкретної конфігурації вендорів.
Повний огляд розгортання MFA на Cisco, Fortinet, Palo Alto, SonicWall, OpenVPN та інших VPN-шлюзах див. Protectimus MFA для VPN.
RADIUS MFA для бездротового мережевого доступу
Хоча VPN є найпоширенішим розгортанням RADIUS MFA, організації також використовують RADIUS для захисту бездротового мережевого доступу. Точний потік автентифікації залежить від бездротової інфраструктури та методу автентифікації, що використовується.
Protectimus підтримує сценарії бездротового доступу, що інтегруються з автентифікацією на основі RADIUS, включно з розгортаннями гостьового Wi-Fi, такими як Ubiquiti UniFi Guest Portal. У таких середовищах користувачі автентифікуються за допомогою одноразового пароля, доставленого через SMS, чат-бота, email, чи TOTP, згенерованого застосунком-автентифікатором чи апаратним токеном, залежно від розгортання.
Для середовищ гостьового Wi-Fi Protectimus можна розгорнути або з хмарним сервісом Protectimus, або з Protectimus On-Premise Platform. Запити автентифікації перевіряються через платформу Protectimus, перш ніж надається доступ до мережі, тоді як адміністратори зберігають централізоване журналювання й можливості управління користувачами.
Плануючи MFA для корпоративних бездротових мереж, перевірте, чи підтримують ваша бездротова інфраструктура й потік автентифікації потрібний метод RADIUS-автентифікації. Можливості автентифікації можуть відрізнятися залежно від бездротового контролера, шлюзу доступу чи реалізації captive-порталу.
Варіанти розгортання
Хмарний RADIUS MFA (SaaS)
RADIUS-сервер Protectimus встановлюється у вашій мережі й налаштовується на взаємодію з хмарним сервісом Protectimus. Ваші мережеві пристрої надсилають запити RADIUS-автентифікації на локальний RADIUS-сервер Protectimus, який перевіряє основні облікові дані користувача проти вашої Active Directory чи LDAP і верифікує другий фактор через хмарний сервіс Protectimus. Жодна on-premises MFA-платформа не потрібна, що робить це розгортання підходящим для організацій, які хочуть швидке впровадження й мінімальну інфраструктуру.
On-Premises RADIUS MFA сервер
RADIUS-сервер Protectimus та Protectimus On-Premise Platform встановлюються на стандартних хостах Windows Server чи Linux у вашій мережі. RADIUS-сервер перевіряє основні облікові дані проти Active Directory чи LDAP і верифікує другий фактор, використовуючи локальну платформу Protectimus. Усі запити автентифікації залишаються у вашій інфраструктурі, що робить це розгортання підходящим для організацій з вимогами до резидентності даних, air-gapped середовищ чи внутрішніх політик безпеки, що забороняють хмарні сервіси автентифікації.
Налаштування високої доступності
В обох режимах розгортання Protectimus підтримує конфігурації високої доступності. Організації можуть розгорнути основні й резервні екземпляри RADIUS-сервера Protectimus. Мережеві пристрої можна налаштувати з обома IP-адресами серверів, використовуючи стандартний RADIUS-failover (резервний сервер використовується, якщо основний не відповідає протягом налаштованого періоду таймауту). Більшість корпоративних файрволів, VPN-шлюзів та RADIUS-клієнтів підтримують це нативно.
У хмарних розгортаннях резервні екземпляри RADIUS-сервера Protectimus підключаються до хмарного сервісу Protectimus. В on-premises розгортаннях високу доступність можна поширити й на саму платформу Protectimus, розгорнувши її як кластер за керованим клієнтом балансувальником навантаження. Організації також можуть розгортати компоненти в окремих локаціях, щоб додатково знизити ризик переривання сервісу.
Системні вимоги та інтеграція
Компонент | Вимога |
|---|---|
Варіанти розгортання | Windows, Linux, Docker |
Порти RADIUS | UDP 1812 (автентифікація), UDP 1813 (облік) |
IP-протокол | Підтримуються IPv4 та IPv6 |
Інтеграція з каталогами | Каталоги Active Directory та LDAP |
Мережеві пристрої | Будь-який RADIUS-клієнт, сумісний з RFC 2865 |
Java | Java потрібна для встановлень на Windows. Якщо Java ще не встановлена, інсталятор може встановити її автоматично. Актуальну підтримувану версію дивіться в поточній документації Protectimus. |
Правила файрвола | Відкритий UDP 1812 між RADIUS-клієнтами й RADIUS-сервером Protectimus; доступ LDAP/LDAPS (389/636) від RADIUS-сервера Protectimus до Active Directory чи LDAP, якщо використовується для основної автентифікації. |
Покроково: як налаштувати RADIUS MFA за 5 кроків
Крок 1 — Розгорніть RADIUS-сервер Protectimus. Оберіть хмарне чи on-premises розгортання. Для хмарного варіанта створіть обліковий запис на service.protectimus.com, активуйте доступ до API та встановіть RADIUS-сервер Protectimus у своїй мережі. Для on-premises варіанта завантажте пакет інсталятора, запустіть його на цільовому сервері Windows чи Linux і встановіть і RADIUS-сервер Protectimus, і Protectimus On-Premise Platform.
Крок 2 — Налаштуйте з’єднання з AD/LDAP. У конфігураційному файлі RADIUS-сервера Protectimus додайте адресу вашого контролера домену, обліковий запис для прив’язки, базу пошуку та налаштування провайдера автентифікації. Протестуйте з’єднання, щоб підтвердити, що RADIUS-сервер Protectimus може взаємодіяти з вашою службою каталогу.
Крок 3 — Додайте свій мережевий пристрій як RADIUS-клієнт. У конфігурації RADIUS-сервера Protectimus зареєструйте IP-адресу та спільний секрет для кожного пристрою NAS, наприклад вашого VPN-шлюзу, файрвола чи іншого підтримуваного мережевого пристрою. Це той самий спільний секрет, який ви налаштуєте на боці пристрою.
Крок 4 — Скеруйте мережевий пристрій на Protectimus. На вашому Cisco ASA, Fortinet, Palo Alto чи іншому підтримуваному пристрої змініть IP-адресу RADIUS-сервера на RADIUS-сервер Protectimus. Встановіть спільний секрет, що відповідає налаштованому на кроці 3, і налаштуйте порт UDP 1812 для RADIUS-автентифікації.
Крок 5 — Зареєструйте користувачів і протестуйте. Зареєструйте пілотну групу користувачів — надіславши їм посилання для самостійної реєстрації чи здійснивши масовий імпорт через групу AD. Попросіть їх відсканувати QR-код у своєму застосунку-автентифікаторі чи призначте апаратні токени. Протестуйте повний потік автентифікації, використовуючи ваш сервіс, захищений RADIUS: введіть облікові дані, пройдіть запит OTP і підтвердьте, що доступ надається після дійсного коду.
Повний технічний огляд зі скриншотами для конкретних вендорів дивіться в full RADIUS MFA integration guide.
Комплаєнс: як RADIUS MFA відповідає регуляторним вимогам
NIST SP 800-63B (AAL2)
Настанови NIST щодо цифрової ідентичності визначають три рівні впевненості автентифікатора. AAL2 вимагає два окремі фактори автентифікації для доступу до чутливих систем. RADIUS MFA з TOTP чи апаратними токенами безпосередньо задовольняє вимоги AAL2 — пароль є запам’ятованим секретом (щось, що ви знаєте), а TOTP-код генерується прив’язаним автентифікатором (щось, що ви маєте).
PCI DSS v4.0 — вимога 8.4
Вимога 8.4.2 PCI DSS v4.0 передбачає MFA для будь-якого доступу до середовища обробки даних власників карток — для будь-якого користувача, незалежно від того, підключається він віддалено чи зсередини мережі. Вимога 8.4.3 звужується конкретно до віддаленого доступу: MFA потрібна для будь-якого віддаленого мережевого доступу до CDE ззовні мережі організації, охоплюючи однаково співробітників, підрядників і сторонніх постачальників. RADIUS MFA допомагає організаціям задовольнити обидві вимоги, примусово застосовуючи MFA для VPN та інших сервісів, захищених RADIUS, до систем у межах середовища обробки даних власників карток.
HIPAA — контроль доступу (45 CFR § 164.312)
Технічна гарантія HIPAA щодо контролю доступу вимагає від охоплюваних суб’єктів впровадження процедур, що надають доступ до електронної PHI лише уповноваженим особам. RADIUS MFA прямо відповідає цій вимозі, додаючи другий крок перевірки до доступу через VPN і Wi-Fi — двох шляхів, які найчастіше використовуються для віддаленого доступу до клінічних систем.
Директива NIS2 (ЄС) — стаття 21
NIS2 вимагає від основних і важливих суб’єктів впроваджувати рішення багатофакторної чи безперервної автентифікації для доступу до мережевих та інформаційних систем. RADIUS MFA задовольняє цю вимогу для сценаріїв віддаленого доступу, явно згаданих у настановах з впровадження ENISA.
ISO/IEC 27001:2022 — Annex A 8.5
Контроль ISO 27001 щодо безпечної автентифікації прямо рекомендує MFA для сценаріїв доступу з високим ризиком, включно з віддаленим доступом і привілейованими обліковими записами. RADIUS MFA допомагає організаціям впровадити цей контроль для VPN та інших сервісів, захищених RADIUS.
Часті запитання
Чи підтримує Protectimus RADIUS Access-Challenge для інтерактивного введення OTP?
Так. Protectimus нативно використовує RADIUS Access-Challenge для інтерактивних запитів OTP. Коли пристрій NAS підтримує challenge/response (що властиво більшості сучасних VPN-клієнтів), користувачі бачать друге поле вводу для свого OTP після введення пароля. Для пристроїв, що не підтримують challenge/response, доступний Inline-режим як резервний варіант.
Чи можу я використовувати RADIUS MFA від Protectimus без заміни наявного RADIUS- чи NPS-сервера?
Так, і це найпоширеніша модель розгортання. Protectimus працює як RADIUS-проксі вище за потоком від вашого наявного сервера автентифікації. Ваші пристрої NAS вказують на Protectimus; Protectimus обробляє примусове застосування MFA, а потім пересилає перевірений запит далі. Ваші наявні політики автентифікації, маршрутизація та конфігурація обліку залишаються незмінними.
Який порт RADIUS-автентифікації використовує Protectimus?
Protectimus використовує стандартний порт RADIUS-автентифікації: UDP 1812. Облік (якщо потрібен) використовує UDP 1813. Обидва порти налаштовувані.
Як MFA працює через VPN, коли немає інтерфейсу браузера?
Підтримуються два режими. У режимі challenge/response mode,VPN-клієнт показує другий запит після прийняття пароля — користувач вводить свій OTP у це поле. В Inline-режимі користувач вводить пароль та OTP разом в одному полі, використовуючи налаштований розділювач. Браузер не потрібен в жодному з випадків; весь потік відбувається в межах нативного інтерфейсу автентифікації клієнта.
Чи підтримує RADIUS від Protectimus високу доступність і failover?
Так. Ви можете розгорнути кілька екземплярів RADIUS-сервера Protectimus і налаштувати ваші пристрої NAS з основною та резервною цілями RADIUS. Якщо основний сервер не відповідає протягом таймауту RADIUS, NAS автоматично повторює спробу з резервним сервером. В on-premises розгортаннях високу доступність можна також поширити на саму платформу Protectimus, розгорнувши її як кластер. Мережеві пристрої автоматично перемикаються на резервний сервер, коли основний стає недоступним, допомагаючи підтримувати доступність автентифікації.
Чи можу я інтегрувати RADIUS від Protectimus з Active Directory?
Так, і це типова конфігурація для більшості корпоративних розгортань. Protectimus підключається до вашої AD через LDAP чи LDAPS (порт 389/636) і пересилає перевірку пароля контролеру домену. Підтримуються політики на основі груп — ви можете вимагати MFA для одних груп AD і звільнити від неї інші, чи призначити різні методи MFA за групами.
Почніть захищати доступ до вашої мережі вже сьогодні
Кожна VPN-точка доступу, корпоративна Wi-Fi-мережа та сервіс, захищений RADIUS, — потенційна точка входу. RADIUS MFA закриває прогалину, пов’язану з автентифікацією лише за обліковими даними, без потреби змінювати наявну мережеву інфраструктуру.
- Розгорнути on-premises → Protectimus On-Prem MFA Platform
- Використати хмарний сервіс → Гід з налаштування Protectimus SaaS
- Прочитати технічний гід → Повний гід з інтеграції RADIUS MFA
- Апаратні токени для RADIUS MFA → Токени Protectimus
- MFA для Active Directory → Гід з агентless MFA для AD
- MFA для входу в Windows та RDP → Компонент Winlogon
