MFA for Cisco AnyConnect: Complete Guide to Securing VPN Access 2026
Cisco AnyConnect обслуговує віддалений доступ мільйонів корпоративних користувачів — і при цьому не має власного механізму примусової перевірки другого фактора. Клієнт передає облікові дані тому бекенду автентифікації, який налаштований на пристрої ASA чи Firepower. Якщо цей бекенд перевіряє лише логін і пароль, VPN-сесія відкривається за викраденими обліковими даними так само легко, як і за легітимними.
За даними Verizon 2026 Data Breach Investigations Report та кількох рекомендацій CISA щодо ransomware, компрометація VPN залишається одним з основних векторів первинного доступу в ransomware-кампаніях 2024–2026 років, включно з операціями, пов’язаними з Akira, LockBit і Black Basta. Шлях атаки рідко буває складним: зібрати облікові дані через фішинг чи infostealer, визначити шлюз AnyConnect, автентифікуватися й закріпитися в системі. Єдиний надійний бар’єр — другий фактор автентифікації, який не можна повторно використати разом із викраденими обліковими даними.
У цьому посібнику пояснюється, як налаштуватибагатофакторну автентифікацію (MFA) для Cisco AnyConnectз використанням аутентифікації на основі RADIUS, які методи аутентифікації доступні, як відбувається розгортання як у хмарних, так і в локальних середовищах, а також які стандарти відповідності підтримує ця архітектура.
Незалежний від виробника огляд розгортання MFA на шлюзах FortiGate, Palo Alto, SonicWall, OpenVPN та інших можна знайти в розділі «Protectimus MFA для VPN».
Коротка відповідь: MFA для Cisco AnyConnect реалізується шляхом налаштування пристрою ASA чи Firepower на пересилання запитів автентифікації на RADIUS-сервер. RADIUS Server від Protectimus розташований між ASA й платформою автентифікації Protectimus: він приймає запит на порту UDP 1812, перевіряє основні облікові дані у вашому каталозі й підтверджує OTP разом із платформою Protectimus, перш ніж повернути ASA відповідь Access-Accept чи Access-Reject. Користувачі автентифікуються за допомогою застосунку Protectimus SMART OTP, апаратного токена або OTP, доставленого через чат-бота, — зазвичай вводячи OTP у полі другого запиту.
Ключові факти
99,9% атак блокується завдяки MFA
Microsoft повідомляє, що MFA блокує понад 99,9% атак на компрометацію облікових записів — найбільш ефективний окремий засіб захисту від вторгнень на основі облікових даних (Microsoft Digital Defense Report).
$4,4 млн — середня вартість витоку даних у 2026 році
Середня глобальна вартість витоку даних у 2025 році сягнула $4,44 млн, а для організацій у США досягла рекордних $10,22 млн (IBM Cost of a Data Breach Report 2025).
87% claim по ransomware починаються з віддаленого доступу
Звіт Coalition Cyber Claims Report показав, що сервіси віддаленого доступу стали точкою входу для 87% страхових випадків, пов’язаних з ransomware, а компрометація VPN окремо стала причиною 73% вторгнень, для яких було встановлено вектор входу.
Ключові переваги
Інтеграція на основі RADIUS
Cisco AnyConnect не має власної MFA — примусова перевірка другого фактора вимагає RADIUS-сервера, що обробляє автентифікацію від імені пристрою ASA чи Firepower.
Жодних змін на стороні клієнта
RADIUS Server Protectimus проксіює запити автентифікації між ASA (UDP 1812) і платформою Protectimus — не потрібно нічого змінювати в клієнті AnyConnect чи конфігурації VPN-тунелю.
6 методів другого фактора
Підтримувані другі фактори: TOTP-застосунок (Protectimus SMART), апаратні токени (Slim NFC, TWO, FLEX, SHARK), OTP через чат-бота в Telegram/Viber/Facebook, SMS, email.
Хмара або повністю on-premise
Доступні обидва варіанти розгортання — хмарний (SaaS) і повністю on-premise; on-premise не потребує зовнішнього з’єднання й підтримує air-gapped середовища.
Гнучке впровадження за групами
MFA можна обмежити конкретними профілями з’єднання чи групами користувачів через призначення AAA server group і RADIUS filter attributes.
Готовність до аудиту
Впровадження допомагає організаціям відповідати вимогам MFA в PCI DSS v4.0, HIPAA, NIST SP 800-63B, SOC 2 та ISO 27001.
Навіщо Cisco AnyConnect потрібна MFA у 2026 році
Автентифікація AnyConnect лише за паролем — задокументований вектор первинного доступу для ransomware; викрадені VPN-облікові дані активно торгуються й експлуатуються масово.
Індустрія крадіжки облікових даних для VPN-доступу вже поставлена на потік. Шкідливе ПЗ класу infostealer — RedLine, Lumma, Vidar та подібні — цілеспрямовано атакує облікові дані, збережені в браузерах, та конфігураційні файли VPN-клієнтів. Зібрані облікові дані пакуються разом з адресою відповідного VPN-шлюзу й продаються протягом кількох годин після збору. Зловмисник, що купує лог облікових даних зі скомпрометованого пристрою у вашій організації, вже має адресу сервера AnyConnect, логін і пароль.Двофакторна автентифікація для Cisco AnyConnect — єдиний засіб захисту, який робить ці облікові дані непридатними для використання.
Звіт Coalition Cyber Claims Report показав, що сервіси віддаленого доступу стали точкою входу для 87% страхових випадків, пов’язаних з ransomware, а компрометація VPN окремо відповідала за 73% ransomware-вторгнень, для яких було встановлено вектор входу, — порівняно з 38% у 2023 році та 66% у 2024. Це зростання не випадкове. Оператори ransomware перейшли до атак на основі ідентичності саме тому, що вони створюють менше “шуму”, ніж експлуатація вразливостей, і краще масштабуються з автоматизованими інструментами.
Специфічні паттерни атак на середовища AnyConnect:
Credential stuffing.Аналіз журналів SSO-провайдерів від Verizon показав, що credential stuffing становить 19% усіх спроб автентифікації в медіанному щоденному вимірі. Та сама модель застосовна до VPN-шлюзів. Атаки виконуються з низькою швидкістю, щоб уникнути тригерів блокування, безперервно перевіряючи скомпільовані з витоків списки облікових даних проти кінцевої точки AnyConnect.
Брутфорс. Шлюзи Cisco ASA та Firepower зі слабкими або типовими політиками блокування облікових записів постійно скануються. CISA видала кілька рекомендацій, спеціально присвячених кампаніям credential stuffing з боку державно фінансованих зловмисників проти VPN-інфраструктури Cisco ASA.
Викрадення сесійних токенів через AiTM. Для розгортань, що використовують push-based MFA, набори інструментів adversary-in-the-middle на кшталт Tycoon2FA перехоплюють сесійні токени в реальному часі під час автентифікації. Коди на основі TOTP, що спливають кожні 30 секунд, значно стійкіші, оскільки вікно повторного використання надзвичайно вузьке — перехоплений TOTP стає марним ще до того, як його можна повторно використати.
Збір даних через infostealer. Один скомпрометований пристрій може передати збережені VPN-облікові дані, XML-файли профілів Cisco AnyConnect, а для впроваджень з push-based MFA — сесійні cookie, дійсні протягом годин чи днів. TOTP-based 2FA для Cisco AnyConnect обмежує вікно вразливості часовим кроком токена.
Жоден із цих паттернів атаки не вимагає від зловмисника зламати шифрування, експлуатувати вразливість ПЗ чи витрачати значні ресурси. Потрібні лише дійсні облікові дані. Впровадження MFA для Cisco AnyConnect усуває статичні облікові дані як життєздатний примітив атаки.
Як працює MFA для Cisco AnyConnect
Cisco AnyConnect MFA працює через протокол RADIUS — пристрій ASA або Firepower пересилає запити на автентифікацію на зовнішній сервер RADIUS, який здійснює перевірку за другим фактором.
Cisco ASA та Firepower не підтримують на рівні ядра TOTP, HOTP або push-аутентифікацію. Їхня архітектура AAA побудована на базі RADIUS та LDAP. ДодаванняAnyConnect RADIUS MFAозначає розгортання проміжного сервера RADIUS, який приймає запити від ASA, виконує як первинну перевірку облікових даних, так і верифікацію за допомогою одноразового пароля (OTP), а також повертає стандартну відповідь RADIUS «Access-Accept» або «Access-Reject».
Алгоритм аутентифікації:
- Користувач відкриває Cisco AnyConnect і вводить облікові дані (логін + пароль)
- ASA чи Firepower пересилає запит автентифікації на Protectimus RADIUS Server на порту UDP 1812
- RADIUS Server пересилає основні облікові дані у налаштований каталог (Active Directory, LDAP чи локальне сховище) для перевірки першого фактора
- Якщо основні облікові дані пройшли перевірку, RADIUS Server запитує другий фактор автентифікації, а отримавши його, пересилає OTP платформі автентифікації Protectimus для перевірки другого фактора
- Платформа Protectimus перевіряє OTP проти токена, зареєстрованого за користувачем, і повертає результат — пройдено/не пройдено
- RADIUS Server надсилає ASA відповідь Access-Accept чи Access-Reject
- ASA дозволяє або забороняє встановлення VPN-тунелю
Формати введення облікових даних:
Формат challenge-response: ASA спочатку перевіряє основний пароль, а потім видає RADIUS Access-Challenge із запитом OTP в окремому полі вводу. Це забезпечує зручніший користувацький досвід і поширено використовується в сучасних розгортаннях MFA для AnyConnect, включно з інтеграціями Protectimus, але вимагає увімкненої підтримки challenge-response у профілі з’єднання ASA.
Комбінований формат:Деякі розгортання RADIUS підтримують комбіновану автентифікацію, під час якої користувач вводить[password][OTP]як єдиний обліковий запис — наприклад,P@ssw0rd!459812. Сервер RADIUS відокремлює останні 6 цифр як OTP. У клієнті AnyConnect не з’являється додаткове запит. Це простіша конфігурація, яка працює з усіма версіями AnyConnect.
Сумісність із Cisco Firepower (FTD):
Інтеграція з RADIUS однаково застосовується до Firepower Threat Defense, що керує VPN-мережею віддаленого доступу AnyConnect. Шлях до налаштувань у Firepower Management Center: Remote Access VPN → Connection Profiles → AAA → RADIUS Server Group. Налаштування порту та спільного секретного ключа ідентичні до налаштувань ASA.
Cisco ISE:
Для організацій, що використовують Cisco ISE як AAA-інфраструктуру, Protectimus інтегрується через стандартний RADIUS-проксі. ISE пересилає запити автентифікації на Protectimus RADIUS Server, який виконує перевірку OTP й повертає результат ISE для оцінки політики.
Supported MFA Methods
Protectimus підтримує шість способів доставки другого фактора для Cisco AnyConnect: TOTP-застосунок, апаратні токени, OTP через чат-бота, SMS, email і push-сповіщення — кожен із власними характеристиками безпеки та зручності.
Застосунок Protectimus SMART OTP
Застосунок Protectimus SMART OTP генерує коди OATH TOTP на Android та iOS. Ключові функції для enterprise: хмарне резервне копіювання для самостійного відновлення токена після втрати пристрою, захист PIN-кодом і біометрією на рівні застосунку та налаштовуваний часовий крок (30, 60, 90 секунд і кратні значення до 3000 секунд). Хмарне резервне копіювання знижує навантаження на службу підтримки під час заміни пристроїв — користувачі самостійно відновлюють свої токени без участі адміністратора.
Апаратні OTP-токени
Для середовищ, де мобільні пристрої заборонені, — режимних об’єктів, виробничих цехів, air-gapped мереж або організацій із суворими обмеженнями BYOD — Protectimus пропонує чотири моделі апаратних токенів:
| Токен | Форм-фактор | Часовий крок | Інтерфейс | Опис |
| Protectimus Slim NFC | Кредитна картка | 30/60 с | NFC | Компактний перепрограмований токен у форматі кредитної картки з підтримкою NFC, який зручно поміщається в гаманець |
| Protectimus TWO | Брелок | 30/60 с | Немає | Стандартний апаратний токен SHA-1 для традиційних розгортань OTP із фіксованими початковими значеннями токена |
| Protectimus FLEX | Брелок | 30 с | NFC | Перепрограмований брелок-токен для гнучкого enterprise-розгортання |
| Protectimus SHARK | Брелок | 30 секунд | Немає | Апаратний токен SHA-256 для організацій, яким потрібні більш надійні криптографічні алгоритми для масштабних розгортань |
Усі чотири моделі використовують стандарт OATH TOTP і активуються через адмін-консоль Protectimus. NFC-моделі з можливістю перепрограмування (Slim NFC, FLEX) можна перепрограмувати через смартфон на Android із NFC, що дозволяє адміністраторам чи користувачам замінити секретний ключ, не замінюючи сам токен.
Protectimus BOT (доставка OTP через чат-бота)
Коди OTP доставляються через чат-бота в Telegram, Viber або Facebook Messenger. Користувач отримує код з обмеженим терміном дії у прив’язаному месенджер-акаунті. Потребує інтернет-з’єднання на пристрої користувача, але усуває потребу встановлювати окремий застосунок-автентифікатор. Підходить для користувачів без корпоративного управління пристроями чи в BYOD-середовищах, де встановлення застосунків обмежене.
SMS OTP
Одноразові паролі доставляються через SMS. Protectimus підтримує інтеграцію з власним SMS-провайдером через SMPP, що дозволяє маршрутизувати повідомлення через наявну SMS-інфраструктуру. Нижчий рівень безпеки, ніж у TOTP-застосунка чи апаратного токена, але підходить як резервний метод для окремих груп користувачів.
Email OTP
Доставка OTP через email. Найнижчий рівень безпеки — самі поштові скриньки є ціллю крадіжки облікових даних, — але забезпечує резервний варіант для користувачів без доступу до мобільних пристроїв.
Push-автентифікація
Push-сповіщення надсилаються на мобільний пристрій користувача для підтвердження замість ручного введення OTP. Користувачі підтверджують чи відхиляють спробу входу безпосередньо в застосунку Protectimus SMART. Однак цей метод автентифікації все ще може бути вразливий до MFA fatigue та атак push bombing.
Порівняльний огляд:
| Метод | Захист від фішингу | Можливість роботи в автономному режимі | Самостійне відновлення | Необхідний пристрій |
| Додаток SMART OTP | Висока | Так | Так (резервне копіювання в хмарі) | Смартфон |
| Апаратний токен | Висока | Так | Ні (замінюється адміністратором) | Апаратний токен |
| BOT (Telegram/Viber) | Середня | Ні | Немає | Смартфон |
| SMS | Середня | Ні | Не застосовується | Мобільний телефон |
| Низька-середня | Ні | Не застосовується | Доступ до електронної пошти | |
| Push | Середня | Ні | Так (резервне копіювання в хмарі) | Смартфон |
Саме для розгортань 2FA для Cisco VPN методи на основі TOTP — застосунок SMART і апаратні токени — операційно найбільш доречні. Обидва працюють офлайн (коди OTP генеруються локально на пристрої й не потребують інтернет-з’єднання на боці користувача) і обидва стійкі до перехоплення токенів через AiTM завдяки 30-секундному вікну дії.
Покрокове налаштування
Налаштування MFA для Cisco AnyConnect з Protectimus передбачає чотири етапи: налаштування платформи або сервісу Protectimus, конфігурацію RADIUS Server, налаштування AAA на ASA/Firepower та реєстрацію користувачів.
Крок 1: Налаштування платформи чи хмарного сервісу Protectimus
Зареєструйтеся на protectimus.comдля хмарного сервісу або встановіть Protectimus On-Premise Platformна власній інфраструктурі. У платформі:
- Створіть ресурс, що представляє інтеграцію AnyConnect VPN
- ЗапишітьURL-адресу API, логінтаключ API — знадобляться для налаштування сервера RADIUS
Крок 2: Встановлення й налаштування Protectimus RADIUS Server
Якщо ви використовуєте хмарний сервіс Protectimus, встановіть сервер RADIUS Protectimus на хості під управлінням Linux (рекомендується) або на сервері Windows, доступному з ASA. У разі локального розгортання сервер RADIUS встановлюється разом із платформою Protectimus.
Відредагуйте файл конфігурації radius.yml. Ось приклад базової конфігурації radius.yml:
auth:
providers:
- LDAP
- PROTECTIMUS_OTP
re-enter-otp: true
principal-normalization: true
protectimus-api:
login: your-api-login
api-key: your-api-key
url: https://api.protectimus.com/
resource-id: your-resource-id
radius:
secret: your-shared-secret
clients:
- name: cisco-asa
secret: your-shared-secret
ips:
- 192.168.1.100/32 # ASA outside interface IP
auth-port: 1812
listen-address: 0.0.0.0
ldap:
base: dc=example,dc=com
urls:
- ldap://192.168.1.10:389
username: admin@example.com
password: your-ldap-password
principal-attribute: userPrincipalName
Цей приклад показує базову конфігурацію LDAP + OTP для MFA Cisco AnyConnect. Реальні розгортання можуть потребувати додаткових налаштувань залежно від використовуваних провайдерів автентифікації, режиму inline OTP, атрибутів RADIUS чи інтеграції з Active Directory у вашому середовищі.
Повна документація з налаштування Protectimus RADIUS Server доступна в гіді Protectimus RADIUS 2FA.
Запустіть службу RADIUS-сервера. Переконайтеся, що вона прослуховує UDP 1812. Перевірте, що правила файрвола дозволяють UDP 1812 та 1813 (accounting) від IP-адреси ASA до RADIUS Server.
Крок 3: Налаштування AAA Server Group у Cisco ASA
У Cisco ASDM, navigate to: Configuration → Remote Access VPN → AAA/Local Users → AAA Server Groups:
- Натисніть «Додати» у розділі «Групи серверів AAA».
- Вкажіть назву групи серверів AAA (наприклад,protectimus) та встановіть«Протокол»наRADIUS.
- Налаштуйте параметри групи:
- Accounting Mode — Single
- Reactivation Mode — Depletion
- Dead Time —10
- Max Failed Attempts — 3
- Натисніть OK.
- Виберіть щойно створену AAA Server Group.
- У розділі Servers in the Selected Group натисніть Add.
- Налаштуйте параметри RADIUS-сервера
- Interface Name— інтерфейс, що використовується для зв’язку з Protectimus RADIUS Server
- Server Name or IP Address— IP-адреса Protectimus RADIUS Server
- Timeout—10 секунд (збільште, якщо користувачам потрібно більше часу для введення кодів OTP)
- Server Authentication Port — 1816
- Server Accounting Port — 1815
- Retry Interval —10 секунд
- Server Secret Key — must match the secret configured in the Protectimus RADIUS Server
- Натисніть OK.
Для Cisco Firepower via FMC, перейдіть до:
Objects → Object Management → RADIUS Server Group → Add Group.
Додайте нову RADIUS Server Group. Параметри ідентичні.
Крок 4: Налаштування VPN-з’єднання AnyConnect
У Cisco ASDM відкрийте:
Wizards → VPN Wizards → AnyConnect VPN Wizard
- Налаштуйте профіль з’єднання:
- ВкажітьConnection Profile Name
- ВиберітьVPN Access Interface
- Налаштуйте протоколи VPN:
- УвімкнітьSSL
- УвімкнітьIPsec
- Виберіть або згенеруйте сертифікат пристрою
- Додайте файли образу клієнта AnyConnect (*.pkg).
- У розділіAuthentication Methods::
- Виберіть раніше створену protectimusгрупу серверів AAA
- У розділіетапі налаштування SAML:
- Встановітьметод автентифікаціїнаAAA
- Виберіть групу серверів protectimus AAA
- Залиште SAML-сервер зі значенням None
- Налаштуйте пул IP-адрес для клієнтів.
- Налаштуйте параметри DNS.
- Увімкніть Exempt VPN traffic from network address translation.
- Увімкніть Allow Web Launch.
- Перегляньте підсумок конфігурації та натисніть Finish.
Крок 5: Реєстрація користувачів
Додайте користувачів до платформи Protectimus вручну, через CSV-імпорт або через синхронізацію LDAP з Active Directory. Призначте токени користувачам вручну або активуйте Self-Service Portal, щоб користувачі могли самостійно реєструватися й керувати своїми токенами. Проведіть тести автентифікації з пілотною групою перед більш широким впровадженням.
Варіанти розгортання: хмара vs on-premisemise
MFA Protectimus для Cisco AnyConnect доступне як хмарний SaaS-сервіс або повністю on-premise платформа — обидва варіанти підтримують повну RADIUS-інтеграцію та повний набір функцій.
Хмарне розгортання
Хмарний сервіс потребує лише локально розгорнутого компонента RADIUS Server. RADIUS Server взаємодіє з API хмарного сервісу Protectimus Cloud для перевірки OTP. Жодної платформенної інфраструктури на боці клієнта не потрібно..
Технічні вимоги для хмарного розгортання:
- Один сервер Linux чи Windows для компонента RADIUS Server
- Вихідний доступ HTTPS від RADIUS Server до api.protectimus.com
- Вхідний UDP 1812/1813 від ASA до RADIUS Server
On-premise розгортання
Protectimus On-Premise Platform працює повністю у вашій інфраструктурі. Жодні дані автентифікації не залишають вашу мережу в жодний момент.
Технічні вимоги:
Компонент | Вимога |
CPU | Мінімум 2 ядра |
RAM | Мінімум 8 ГБ |
Storage | Мінімум 20 ГБ дискового простору |
OS | Linux (основна), Windows |
HA-конфігурація | Опційний кластер із 3 вузлів з HAProxy |
Балансування навантаження | Рекомендований балансувальник для HA-розгортань |
Порівняння варіантів розгортання:
ФакторХмара | On-Premise | |
Необхідна інфраструктура | Лише RADIUS Server | Protectimus On-Premise Platform (включає RADIUS Server) |
Час до першої автентифікації | Зазвичай кілька годин | Зазвичай кілька годин після підготовки інфраструктури |
Обслуговування платформи | Здійснює Protectimus | Самостійне |
Резидентність даних | Хмара Protectimus | Повністю у вашій мережі |
Підтримка air-gapped | Ні | Так |
HA / кластеризація | Здійснює Protectimus | Самостійна (рекомендовано 3 вузли) |
Розгортання у приватній хмарі | Ні | AWS/Azure/VMware private cloud |
Для середовищ, що працюють у межах вимог PCI DSS до середовища обробки даних власників карток, HIPAA, FISMA чи будь-якого фреймворку, де резидентність даних автентифікації оцінюється під час аудиту, on-premise розгортання є архітектурно доречним вибором.
Protectimus vs Cisco Duo для AnyConnect
Обидва рішення, Protectimus і Cisco Duo, інтегруються з Cisco AnyConnect через RADIUS і підтримують другі фактори на основі TOTP — архітектурні відмінності полягають у моделі розгортання, доступності апаратних токенів і вимогах до зовнішнього з’єднання.
Цей розділ описує об’єктивні технічні відмінності. Правильний вибір залежить від конкретних інфраструктурних вимог вашої організації.
Архітектура інтеграції
Обидва рішення використовують RADIUS як основний шлях інтеграції для SSL VPN та IPSec VPN у AnyConnect. Duo додатково пропонує SAML-based інтеграцію, що уможливлює інтерактивний запит на реєстрацію та автентифікацію для VPN-входу через браузер (клієнт AnyConnect 4.6+). Шлях через RADIUS — який використовують обидва рішення — покриває всі типи з’єднань AnyConnect без додаткових відмінностей у налаштуванні.
On-premise розгортання й зовнішнє з’єднання
Protectimus On-Premise функціонує як повністю автономна платформа. Після розгортання вона не потребує зовнішнього з’єднання для перевірки запитів автентифікації — уся перевірка OTP відбувається у вашій мережі.
On-premise компонент Duo (Duo Authentication Proxy) проксіює запити автентифікації до хмарної інфраструктури Duo для обробки. Запити автентифікації проходять через сервери Duo навіть у “on-premise” конфігураціях. Для організацій із вимогами до ізоляції мережі, air-gapped середовищ чи комплаєнс-фреймворків, які обмежують вихід даних автентифікації за межі мережі, це важлива архітектурна відмінність.
Підтримка апаратних токенів
Protectimus пропонує чотири моделі апаратних OTP-токенів, доступних безпосередньо: Slim NFC, TWO, FLEX і SHARK. Усі підтримують стандарт OATH TOTP. NFC-моделі підтримують перепрограмування через NFC за допомогою смартфона на Android. Duo підтримує сумісні з OATH апаратні токени сторонніх виробників, але не пропонує власної лінійки апаратних токенів.
Інтеграція з екосистемою Cisco
Пряма інтеграція Duo з Cisco ISE, Cisco Umbrella та Cisco SecureX забезпечує тісніше застосування політик для організацій, що вже працюють у межах стека безпеки Cisco. Protectimus інтегрується з Cisco ISE через стандартний RADIUS-проксі, але не має спеціалізованих конекторів для інших компонентів платформи Cisco.
Об’єктивне порівняння:
Фактор | Protectimus | Cisco Duo |
RADIUS-інтеграція для AnyConnect | Так | Так |
Підтримка SAML / інтерактивного вебзапиту | Ні | Так |
Підтримка апаратних токенів | 4 моделі апаратних токенів (класичні та програмовані) | Підтримує токени OATH сторонніх виробників |
On-premise без зовнішніх залежностей | Так | Ні (потребує хмару Duo) |
Підтримка air-gapped середовищ | Так | Ні |
Портал самостійної реєстрації | Так | Так |
Інтеграція з Cisco ISE | Через RADIUS-проксі | Нативна інтеграція |
Інтеграція з екосистемою Cisco (ISE, Umbrella, SecureX) | SСтандартна RADIUS-based інтеграція | Нативна інтеграція |
Комплаєнс і сценарії використання
MFA для Cisco AnyConnect через Protectimus напряму відповідає обов’язковим вимогам щодо другого фактора в PCI DSS v4.0, HIPAA, NIST SP 800-63B, SOC 2 та ISO 27001.
PCI DSS v4.0
Вимога 8.4.2 передбачає MFA для будь-якого неконсольного адміністративного доступу та будь-якого віддаленого мережевого доступу з-поза меж середовища обробки даних власників карток. VPN-з’єднання AnyConnect до систем у межах області дії PCI DSS підпадає під цю вимогу без винятків. Реалізація TOTP від Protectimus задовольняє вимогу 8.4.2; on-premise розгортання враховує аспекти резидентності даних, важливі для аудиторів PCI DSS, що оцінюють розміщення інфраструктури автентифікації.
HIPAA
Технічні гарантії безпеки HIPAA Security Rule (45 CFR §164.312) вимагають контролю доступу та автентифікації для систем, що містять електронну захищену медичну інформацію. Настанови HHS явно рекомендують MFA для віддаленого доступу до систем ePHI. Для медичних організацій, що використовують AnyConnect для доступу до клінічних систем, впровадженняCisco AnyConnect MFAвідповідає поточним очікуванням аудиту HHS.
NIST SP 800-63B
На рівні впевненості автентифікатора 2 (AAL2) NIST вимагає механізму багатофакторної автентифікації з використанням затвердженого автентифікатора типу “щось, що ви маєте”. OATH TOTP відповідає AAL2. Апаратні токени задовольняють AAL2 без додаткових умов; застосунок Protectimus SMART OTP із захистом PIN-кодом чи біометрією також відповідає AAL2. Організації, що працюють у межах FedRAMP чи FISMA, посилаються безпосередньо на NIST 800-63B щодо вимог автентифікації для віддаленого доступу.
SOC 2
Аудити SOC 2 Type II оцінюють логічний контроль доступу за критерієм Common Criteria 6.1 (CC6.1). Примусова MFA для VPN віддаленого доступу — з документованою політикою, доказами впровадження й журналами аудиту — задовольняє CC6.1 і є стандартним доказом для SOC 2-аудитів.
ISO 27001
Контроль Annex A A.9.4.2 (безпечні процедури входу) стосується надійності автентифікації для доступу до систем. MFA для VPN віддаленого доступу є стандартним доказом для цього контролю під час сертифікаційних аудитів ISO 27001.
Галузеві сценарії використання:
Галузь | Драйвер комплаєнсу | Примітки щодо розгортання |
Фінансові послуги | PCI DSS v4.0, SOX | On-premise розгортання; апаратні токени для привілейованого доступу |
Охорона здоров’я | HIPAA, HITECH | On-premise розгортання; SMART app + апаратний токен як резерв |
Держсектор / оборона | NIST 800-63B, FISMA | On-premise розгортання; підтримка air-gapped |
Енергетика / критична інфраструктура | NERC CIP, NIS2 | On-premise розгортання; підтримка air-gapped |
Професійні послуги | SOC 2 Type II | Хмарне або on-premise розгортання |
Усунення типових проблем
Більшість збоїв автентифікації MFA для Cisco AnyConnect зводиться до чотирьох першопричин: проблеми з RADIUS-з’єднанням, невідповідність спільного секрету, дрейф часу OTP та неправильна конфігурація атрибутів AAA.
Проблеми з’єднання RADIUS
Переконайтеся, що UDP 1816 відкритий від зовнішнього чи внутрішнього інтерфейсу ASA (залежно від розміщення RADIUS Server) до IP-адреси RADIUS Server. Виконайте тест автентифікації aaa-сервера protectimus хост <ip> username <user> password <password> з CLI ASA, щоб з’ясувати, чи проблема на шляху ASA-RADIUS, чи RADIUS-API Protectimus. Перевірте журнали RADIUS Server на коди причин відмови та помилки з’єднання з API.
Невідповідність спільного секртного ключа
Спільний секрет ключ у конфігурації сервера ASA AAA повинен точно збігатися зізначенню секретузначенням на серверах RADIUSконфігурації клієнтів— з урахуванням регістру та без пробілів у кінці. Незбіг зазвичай проявляється у вигляді перевищення часу очікування або помилкиERROR, а не явноюAccess-Reject, оскільки ASA не може розшифрувати відповідь, підписану іншим секретом.
Дрейф часу OTP
Перевірка TOTP залежить від часу. Дрейф годинника, що перевищує 30 секунд між хостом RADIUS Server і токеном, спричинить збої OTP. Переконайтеся, що NTP налаштовано й синхронізовано на хості RADIUS Server. Платформа Protectimus за замовчуванням приймає вікно ±1 часовий крок (перевіряючи попередній і наступний OTP на додаток до поточного), забезпечуючи 90 секунд допуску — це не компенсує стійкий дрейф годинника. За потреби вікно допустимого дрейфу часу можна розширити в конфігурації платформи чи хмарного сервісу Protectimus, хоча це не повинно замінювати належну синхронізацію часу.
Таймаут автентифікації під час введення OTP
Типовий таймаут AAA-сервера ASA часто становить 10–12 секунд. Однак короткі значення таймауту AAA-сервера можуть переривати автентифікацію ще до того, як користувач встигне ввести код OTP, особливо при використанні SMS, email чи доставки через чат-бота. Якщо користувачі відчувають збої автентифікації через таймаут, збільште значення таймауту в конфігурації AAA-сервера до 60 секунд або більше. Для доставки через SMS чи email доречніше 90–120 секунд з урахуванням можливої затримки доставки.
Поширені запитання
Як увімкнути MFA на Cisco AnyConnect?
Cisco AnyConnect не має вбудованого механізму MFA — примусова перевірка другого фактора вимагає налаштування ASA чи Firepower на використання зовнішнього RADIUS-сервера для AAA-автентифікації. Процес із Protectimus: встановити й налаштувати Protectimus RADIUS Server на хості Linux чи Windows, доступному з ASA; створити AAA server group в ASDM чи FMC, що вказує на IP-адресу RADIUS Server на порту UDP 1816; призначити цю server group профілю з’єднання AnyConnect у розділі Authentication; зареєструвати користувачів у платформі Protectimus з їхнім типом токена. Першу автентифікацію з примусовою MFA можна отримати за 2–4 години для стандартного однодоменного розгортання. Повний покроковий гід — на protectimus.com/guides/cisco-anyconnect/.
Чи підтримує Cisco AnyConnect застосунки-автентифікатори на основі TOTP на кшталт Google Authenticator?
Cisco AnyConnect не прив’язаний до конкретного постачальника TOTP — він передає облікові дані на RADIUS-сервер, який виконує перевірку OTP. Працює будь-який OATH TOTP-сумісний застосунок, включно з Google Authenticator, Microsoft Authenticator і Protectimus SMART OTP. Функціональна відмінність для enterprise-розгортань полягає в можливостях керування. Protectimus SMART OTP підтримує хмарне резервне копіювання для самостійного відновлення токена, захист PIN-кодом і біометрією та налаштовуваний часовий крок, відмінний від типового 30-секундного. Google Authenticator і Microsoft Authenticator не мають API керування й не підтримують налаштування часового кроку, що обмежує їхню корисність у масштабних розгортаннях, де важливі відновлення токена й видимість для аудиту.
Чи можна використовувати апаратні OTP-токени з VPN Cisco AnyConnect?
Так. Апаратні токени OATH TOTP інтегруються з AnyConnect через RADIUS так само, як і програмні токени, — користувач вводить 6-значний OTP, показаний на токені, як другий крок після введення пароля й логіну для VPN. Protectimus пропонує чотири моделі апаратних токенів: Slim NFC (програмований токен у форм-факторі кредитної картки з підтримкою NFC), TWO (брелок, без NFC), FLEX (програмований апаратний токен NFC у форм-факторі брелока) та SHARK (апаратний TOTP-токен SHA-256 у форм-факторі брелока, непрограмований). Усі використовують стандарт OATH TOTP, підтримують 30-секундний часовий крок (опційно 60-секундний) і керуються через адмін-консоль Protectimus. Апаратні токени операційно доречні для середовищ, де мобільні пристрої заборонені, для польових працівників без надійного доступу до смартфонів або для ролей із високими вимогами до безпеки, які потребують окремого від основного пристрою користувача фізичного автентифікатора.
Чим MFA Protectimus для Cisco AnyConnect відрізняється від Cisco Duo?
Обидва рішення інтегруються через RADIUS і підтримують другі фактори на основі TOTP для AnyConnect. Основна архітектурна відмінність — в on-premise розгортанні: Protectimus On-Premise обробляє всі запити автентифікації у вашій інфраструктурі без потреби у зовнішньому з’єднанні. Duo Authentication Proxy пересилає кожен запит автентифікації до хмарної інфраструктури Duo, тобто on-premise розгортання Duo потребують вихідного доступу до інтернету до серверів Duo. Для середовищ із вимогами до ізоляції мережі чи air-gapped мереж ця відмінність важлива. Щодо апаратних токенів, Protectimus пропонує чотири моделі для прямого постачання; Duo покладається на сумісні з OATH пристрої сторонніх виробників. Duo забезпечує тіснішу інтеграцію з ширшим стеком безпеки Cisco — ISE, Umbrella, SecureX — для організацій, стандартизованих на екосистемі Cisco.
Чи відповідає MFA Protectimus для Cisco AnyConnect вимогам PCI DSS, HIPAA, NIST?
Так. Реалізація TOTP через RADIUS задовольняє вимоги MFA в основних комплаєнс-фреймворках. Вимога 8.4.2 PCI DSS v4.0 передбачає MFA для будь-якого віддаленого доступу до середовища обробки даних власників карток — OATH TOTP через RADIUS задовольняє цю вимогу. Технічні гарантії HIPAA вимагають контролю доступу для систем ePHI; MFA для VPN-доступу прямо рекомендована в поточних настановах HHS. NIST SP 800-63B AAL2 вимагає автентифікатора типу “щось, що ви маєте” — OATH TOTP задовольняє AAL2; апаратні токени забезпечують найвищий рівень впевненості AAL2. SOC 2 CC6.1 (логічний контроль доступу) та ISO 27001 A.9.4.2 (безпечні процедури входу) обидва враховуються документованою, примусовою MFA для віддаленого доступу. Варіант on-premise розгортання особливо доречний, коли аудитори комплаєнсу оцінюють резидентність даних автентифікації та місце їх обробки.
Чи можна застосувати MFA лише до окремих груп користувачів Cisco AnyConnect?
Так, кількома способами налаштування. На рівні ASA кожному профілю з’єднання (tunnel group) можна призначити окрему AAA server group — це дозволяє конкретним профілям примусово застосовувати RADIUS MFA, тоді як інші використовують локальну автентифікацію чи автентифікацію через Active Directory. У платформі Protectimus політики на основі груп дозволяють примусово застосовувати MFA для конкретних груп користувачів, тоді як до інших груп застосовуються інші політики автентифікації. Ця гнучкість підтримує поетапне впровадження — починаючи з примусової MFA для привілейованих облікових записів та IT-персоналу, перш ніж поширювати її на всіх користувачів.
Що відбувається, якщо користувач втратив OTP-токен чи смартфон?
Відновлення залежить від методу автентифікації. Для користувачів застосунку Protectimus SMART OTP з увімкненим хмарним резервним копіюванням користувач самостійно відновлює токен на новому пристрої через портал самообслуговування Protectimus без участі адміністратора. У разі втрати апаратного токена адміністратор деактивує втрачений токен в адмін-консолі Protectimus і видає заміну. У термінових ситуаціях адміністратор може тимчасово вимкнути MFA для конкретного облікового запису — ця дія обмежена в часі, вимагає авторизації адміністратора й фіксується в журналі аудиту Protectimus. Активація порталу самообслуговування та увімкнення хмарного резервного копіювання в застосунку SMART до впровадження настійно рекомендуються, щоб мінімізувати навантаження на службу підтримки в типових сценаріях заміни пристроїв.
Чи підтримує Protectimus Cisco AnyConnect з on-premise розгортанням?
Так. Protectimus On-Premise Platform встановлюється на серверах Linux чи Windows у вашій інфраструктурі — фізичному обладнанні, on-premise VMware чи середовищах приватної хмари на кшталт AWS чи Azure. Мінімальні вимоги: 2-ядерний CPU, 8 ГБ RAM, 200 ГБ сховища. Для високої доступності підтримується кластер щонайменше з 3 вузлів із балансуванням навантаження через HAProxy, з реплікацією master-slave між вузлами. Жодні дані автентифікації не залишають вашу мережу в жодний момент — перевірка OTP, керування користувачами й журналювання аудиту відбуваються локально. On-premise розгортання доречне для організацій, що працюють у межах HIPAA, вимог PCI DSS до середовища обробки даних власників карток, фреймворків NIST 800-63B/FISMA, або будь-яких середовищ, де вимоги до ізоляції мережі чи резидентності даних обмежують використання зовнішніх сервісів автентифікації.
Висновок
Cisco AnyConnect — надійний клієнт VPN для віддаленого доступу. Його безпека у 2026 році повністю залежить від того, які засоби контролю автентифікації застосовує ASA чи Firepower перед наданням тунелю. Автентифікація лише за паролем на VPN-шлюзі, доступному з інтернету, — задокументований вектор первинного доступу для операторів ransomware, який до того ж ефективно масштабується за допомогою автоматизованих інструментів перевірки облікових даних.
Шлях інтеграції через RADIUS технічно нескладний. Protectimus RADIUS Server встановлюється за години, конфігурація AAA на ASA потребує десятихвилинного проходження в ASDM, а результат — примусова двофакторна автентифікація на Cisco AnyConnect для кожного користувача в кожному профілі з’єднання — без змін у клієнті AnyConnect, конфігурації VPN-тунелю чи наявній інфраструктурі каталогів.
Ключові рішення перед розгортанням: хмара чи on-premise (це визначається вимогами до суверенітету даних та ізоляції мережі), метод автентифікації (TOTP-застосунок для більшості середовищ, апаратні токени там, де мобільні пристрої обмежені) та послідовність впровадження (поетапно за профілем з’єднання чи групою користувачів для управління навантаженням на реєстрацію та вплив на підтримку).
Для організацій, що працюють у межах PCI DSS, HIPAA, NIST 800-63B, або в середовищах із вимогами до ізоляції мережі, on-premise розгортання є архітектурно доречним вибором. Для стандартних enterprise-розгортань без регуляторних обмежень щодо резидентності даних хмарне розгортання забезпечує швидший шлях до примусової Cisco AnyConnect MFA з нижчим операційним навантаженням.
Готові додати MFA до вашого розгортання Cisco AnyConnect? Зв’яжіться з Protectimusщоб обговорити ваше середовище ASA чи Firepower, підтвердити сумісність з RADIUS у наявній AAA-інфраструктурі та запросити технічну демонстрацію.
