On-Premise MFA: повний гід із self-hosted багатофакторної автентифікації (2026)
Хмарна автентифікація — шлях найменшого спротиву для більшості організацій. Швидше розгортається, не потребує обслуговування інфраструктури, і коли щось ламається о другій ночі — це вже не ваша проблема. Для значної частки підприємств такий компроміс цілком прийнятний.
Для решти — тих, хто працює під GDPR, DORA, NIS2, PCI DSS чи HIPAA, тих, хто експлуатує air-gapped мережі в оборонній сфері чи критичній інфраструктурі, тих, чиї аудитори комплаєнсу ставлять незручні запитання про те, де саме зберігаються дані автентифікації, — розрахунок виглядає інакше. Коли користувачі автентифікуються в системах, що містять дані власників карток чи електронну захищену медичну інформацію, дані автентифікації часто підпадають під суворі вимоги комплаєнсу й резидентності даних. У хмарному розгортанні MFA ці дані залишають вашу мережу. В on-premise розгортанні — ні.
Цей гід пояснює, як працює архітектура on-premise MFA, чому вона все ще необхідна у 2026 році для організацій із суворими вимогами комплаєнсу чи ізоляції мережі, і як вона порівнюється з хмарними та приватнохмарними альтернативами. Щодо конкретики продукту Protectimus — ціни, специфікації розгортання, підтримувані токени та демо — див. сторінку Protectimus On-Premise MFA Platform.
Зміст
- Чому on-premise MFA важлива у 2026 році
- On-Premise MFA vs хмарна MFA vs приватна хмара
- Як працює on-premise MFA від Protectimus
- Enterprise-функції: кластеризація, HA, мультидоменний AD
- Підтримувані методи MFA
- Які сервіси можна захистити
- Вимоги до розгортання
- Галузеві сценарії й комплаєнс
- FAQ
- Висновок
Коротка відповідь
On-premise MFA — це self-hosted архітектура автентифікації, у якій рушій перевірки OTP, база користувачів, секрети токенів і журнали аудиту працюють цілком у вашій власній інфраструктурі — фізичних серверах, віртуалізованих середовищах чи приватній хмарі. Жоден запит автентифікації не залишає вашу мережу.
Цей гід пояснює, чому регульовані галузі досі обирають цю модель у 2026 році, як працює архітектура, що вона захищає, і як порівнюється з хмарними альтернативами.
Щодо конкретики продукту Protectimus — ціни, підтримувані токени, специфікації розгортання та демо — див.
Protectimus On-Premise MFA Platform →
Ключові факти
99,9% атак блокується завдяки MFA
Microsoft повідомляє, що MFA блокує понад 99,9% атак на компрометацію облікових записів — найефективніший окремий засіб захисту від вторгнень на основі облікових даних. (Microsoft Digital Defense Report)
$4,4 млн — середня вартість витоку даних у 2025 році
Середня глобальна вартість витоку даних у 2025 році сягнула $4,44 млн, а для організацій у США досягла рекордних $10,22 млн (IBM Cost of a Data Breach Report 2025).
22% зламів через зловживання обліковими даними
Зловживання обліковими даними стало вектором первинного доступу в 22% зламів; 88% атак класу Basic Web Application передбачали викрадені облікові дані. (Verizon 2026 Data Breach Investigations Report)
Ключові переваги
Автентифікація залишається on-premise
Уся перевірка OTP, секрети токенів і журнали аудиту працюють у вашій власній мережі. Жодної зовнішньої залежності для обробки автентифікації.
High-Availability кластеризація
Продакшн-розгортання використовують кластерну багатовузлову архітектуру (зазвичай 3+ вузли) з балансуванням навантаження й реплікацією бази даних.
Мультидоменний Active Directory
Нативна підтримка мультидоменних середовищ Active Directory з централізованим управлінням автентифікацією з єдиного екземпляра платформи.
Широке покриття сервісів
Захищає AD, VPN-шлюзи, застосунки, федеровані через ADFS, вхід у Windows та RDP, OWA, а також кастомні вебзастосунки.
Покриття комплаєнсу
Допомагає відповідати вимогам PCI DSS v4.0, HIPAA, NIST SP 800-63B, SOC 2, ISO 27001, GDPR, DORA, NIS2.
Здатність працювати в air-gapped мережах
Функціонує без інтернет-з’єднання після розгортання — єдина життєздатна архітектура для секретних мереж та ICS-середовищ.
Чому on-premise MFA важлива у 2026 році
Чесна відповідь полягає в тому, що більшість організацій не обирають цей варіант добровільно — до нього їх підштовхують обмеження, через які хмарна MFA стає нежиттєздатною.
GDPR розглядає дані подій автентифікації — логіни, часові мітки, IP-адреси, результати перевірки — як персональні дані. Маршрутизація їх через хмарного провайдера автентифікації створює відносини обробки даних, які вимагають DPA, оцінки безпеки й потенційно оцінки впливу передачі даних. DORA класифікує сервіси автентифікації як ICT-сервіси, що робить хмарних провайдерів MFA суб’єктами вимог управління ризиками третіх сторін. NIS2, стаття 21, включає залежності від інфраструктури автентифікації в область оцінки ризиків ланцюга постачання.
Для фінансових установ, медичних організацій та операторів критичної інфраструктури зберігання автентифікації у власній інфраструктурі часто спрощує перевірки на відповідність комплаєнсу й знижує вплив ризиків третіх сторін.
Air-gapped мережі — складніше обмеження. Секретні державні системи, середовища оборонних підрядників під дією ITAR чи CMMC, мережі промислових систем управління та певна фінансова торгова інфраструктура зазвичай не можуть маршрутизувати запити автентифікації до зовнішніх API. On-premise — єдина архітектура, яка тут працює.
On-Premise MFA vs хмарна MFA vs приватна хмара
Фактор | On-Premise | Хмарна MFA | Приватна хмара |
Розташування даних автентифікації | Ваші сервери | Інфраструктура вендора | Ваш хмарний тенант |
Підтримка air-gapped | Так | Ні | Залежить |
Потрібне зовнішнє з’єднання | Ні | Так | Так (хмарний провайдер) |
Затримка | LAN — передбачувана | Залежить від інтернету | Залежить від інтернету |
HA / кластеризація | Самостійна (рекомендовано 3 вузли) | Керується провайдером | Самостійна |
Область аудиту третіх сторін | Відсутня | Повна оцінка вендора | Хмарний провайдер у зоні перевірки |
Час до розгортання | Дні | Години | Від годин до днів |
Приватна хмара поєднує багато переваг on-premise MFA з операційною гнучкістю хмарної інфраструктури. Дані автентифікації залишаються в межах виділеного хмарного середовища організації, а не спільної SaaS-платформи, тоді як базовий хмарний провайдер залишається в межах області оцінки комплаєнсу й ризиків. Для організацій, що вже використовують регульовані робочі навантаження в AWS чи Azure з відповідним контрактним покриттям, це пропонує баланс між контролем та операційною гнучкістю.
Як працює on-premise MFA від Protectimus
Платформа має три функціональні рівні:
Рушій автентифікації. Рушій перевірки OTP реалізує стандарти OATH TOTP, HOTP та OCRA. Запити автентифікації надходять через RADIUS, DSPA чи API. Рушій перевіряє OTP проти seed-значення токена, збереженого локально, і повертає результат — пройдено чи ні. Матеріал seed ніколи не залишає вашу інфраструктуру — ні під час активації, ні під час перевірки.
Рівень інтеграції. Протоколи, плагіни й компоненти інтеграції, що з’єднують захищені системи з рушієм автентифікації:
- RADIUS— VPN-шлюзи, контролери мережевого доступу, Wi-Fi та інші RADIUS-based системи
- DSPA— автентифікація на основі OTP для Active Directory, каталогів LDAP і підключених сервісів
- ADFS plugin— федерований доступ до Microsoft 365, SharePoint, Salesforce та інших застосунків, підключених через ADFS
- Windows Credential Provider— захист входу в Windows та RDP, включно з підтримкою офлайн-автентифікації
- Плагіни для вебзастосунків та API-інтеграції—Outlook Web App,Roundcube, кастомні вебзастосунки та сервіси, інтегровані через REST API чи SDK
Рівень управління та аудиту. Інтеграція з Active Directory, каталогами LDAP та іншими джерелами даних користувачів автоматично підтримує синхронізацію облікових записів. Журнали подій автентифікації — кожна спроба, часова мітка, результат — залишаються локальними. Портал самообслуговування опрацьовує реєстрацію токенів, синхронізацію та заміну пристроїв без участі адміністратора.
Enterprise-функції: кластеризація, висока доступність, мультидоменний AD
Продакшн-розгортання on-premise MFA зазвичай використовують кластерну багатовузлову архітектуру з балансуванням навантаження й реплікацією бази даних — щоб автентифікація продовжувала працювати, навіть якщо один вузол вийде з ладу. Мінімально життєздатне налаштування високої доступності — три вузли (для кворуму) з балансувальником навантаження попереду й реплікацією бази даних master-slave позаду.
Підтримка мультидоменного Active Directory уможливлює інтеграцію зі складними enterprise-середовищами, що містять кілька доменів чи структур каталогів. Синхронізацію LDAP можна налаштувати для окремих каталогів, зберігаючи централізоване управління автентифікацією з єдиного екземпляра платформи.
Protectimus On-Premise MFA Platform підтримує кластерні розгортання з кількома вузлами платформи, балансуванням навантаження через HAProxy та реплікованими базами даних PostgreSQL. Повну архітектуру розгортання, системні вимоги й таймлайн впровадження дивіться на сторінці Protectimus On-Premise MFA Platform →
Підтримувані методи MFA
Метод | Стійкість до фішингу | Офлайн | Самостійне відновлення |
Висока | Так | Так (хмарне резервне копіювання) | |
Висока | Так | Ні (замінює адміністратор) | |
Середня | Ні | Н/З | |
Низька-середня | Ні | Н/З | |
Низька-середня | Ні | Н/З | |
Середня | Ні | Так (хмарне резервне копіювання) |
Для середовищ, де мобільні пристрої заборонені, — виробничих цехів, режимних об’єктів, секретних мереж — апаратні токени OATH TOTP зазвичай є пріоритетним другим фактором. Стандартизація на OATH означає, що токени переносимі між вендорами: токен OATH TOTP від одного постачальника працює з будь-яким іншим OATH-сумісним рушієм перевірки.
Protectimus пропонує чотири моделі апаратних токенів для таких сценаріїв, включно з програмованими NFC-картками та токенами SHA-256 з фіксованим seed-значенням. Усі варіанти апаратних токенів →
Методи на основі TOTP (застосунок-автентифікатор та апаратні токени) операційно найнадійніші для більшості enterprise on-premise розгортань. Обидва генерують коди локально без інтернет-з’єднання. Обидва створюють 30-секундні коди, марні для зловмисника, який перехопив їх уже після закінчення терміну дії.
Які сервіси можна захистити
Active Directory, LDAP і бази даних. З Protectimus DSPA on-premise MFA захищає облікові записи каталогу на рівні самого каталогу, поширюючи захист на вхід у Windows, RDP, VPN-доступ, OWA та будь-який застосунок, прив’язаний до AD. Таргетинг на основі груп дозволяє почати з привілейованих облікових записів, перш ніж розширювати покриття. Protectimus реалізує MFA на рівні каталогу черезDSPA (Dynamic Strong Password Authentication) →
VPN-шлюзи через RADIUS.Покриває Cisco ASA, Cisco Firepower, Fortinet, Palo Alto, Check Point, Juniper та більшість VPN-шлюзів, сумісних з RFC 2865. Вхідний UDP 1812 від шлюзу — основна мережева вимога. Приклад практичної реалізації — MFA для Cisco AnyConnect →
ADFS і федеровані застосунки. Плагін інтегрується як додатковий провайдер автентифікації в конвеєрі ADFS, вмикаючи захист MFA для всіх федерованих сервісів, маршрутизованих через ADFS, — Microsoft 365, SharePoint, Salesforce та інших. Див. Інтеграцію з ADFS →
Вхід у Windows і RDP. Windows Credential Provider захищає вхід у робочі станції та сервери, з підтримкою офлайн-перевірки через одноразові резервні коди для робочих станцій, які не можуть з’єднатися з сервером автентифікації. Див. MFA для входу в Windows і RDP →
Outlook Web App і вебзастосунки. Інтеграція OWA для Exchange 2013–2019. Roundcube через плагін. Кастомні вебзастосунки через REST API чи SDK. Див. Інтеграцію з OWA → та Інтеграцію з Roundcube →
Вимоги до розгортання
Платформи on-premise MFA мають скромні апаратні вимоги — кілька ядер CPU та кілька гігабайт RAM на вузол зазвичай достатньо для самого рушія автентифікації. Обсяг сховища масштабується переважно залежно від терміну зберігання журналів аудиту.
Стандартне однодоменне впровадження — один ліс AD, один VPN-шлюз, стандартні робочі станції — досяжне за один-два дні, включно з пілотним тестуванням. Повний час впровадження далі залежить від кількості інтеграцій і підходу до реєстрації (портал самообслуговування чи масове CSV-провіжінінг).
Наявну RADIUS-інфраструктуру — включно з Cisco ISE та FreeRADIUS — зазвичай можна зберегти, інтегрувавши нову платформу автентифікації як RADIUS-проксі-рівень з мінімальними змінами конфігурації.
Точні специфікації розгортання Protectimus (CPU, RAM, сховище, підтримувані ОС і бази даних, покроковий таймлайн впровадження) — на сторінці Protectimus On-Premise MFA Platform →
Галузеві сценарії й комплаєнс
Галузь | Драйвер комплаєнсу | Примітки |
Фінансові послуги | PCI DSS v4.0, SOX, DORA | Апаратні токени для регульованих і високобезпечних середовищ; DSPA для AD |
Охорона здоров’я | HIPAA, HITECH | Апаратні токени для EVV-процесів і MFA для спільних клінічних робочих станцій |
Держсектор / оборона | NIST 800-63B, FISMA, CMMC | Air-gapped розгортання й підтримка апаратних токенів |
Енергетика / критична інфраструктура | NERC CIP, NIS2 | On-premise MFA й апаратні токени для ізольованих ICS та OT-середовищ |
Телеком | NIS2 | MFA для розподіленої телеком- та мультисайтової мережевої інфраструктури |
PCI DSS v4.0, вимога 8.4.2, передбачає MFA для будь-якого віддаленого доступу до середовища обробки даних власників карток — без винятків. DORAвідносить хмарних провайдерів автентифікації до категорії ICT-постачальників третьої сторони, що вимагає формальної due diligence. Технічні гарантії HIPAA (45 CFR §164.312)вимагають контролю доступу для систем ePHI; HHS прямо рекомендує MFA для віддаленого доступу. OATH TOTP широко використовується для підтримки вимог автентифікації NIST SP 800-63B на рівні AAL2.
FAQ
Що таке on-premise MFA і чим вона відрізняється від хмарної MFA?
On-premise MFA виконує весь стек автентифікації — рушій OTP, базу користувачів, секрети токенів, журнали аудиту — на ваших власних серверах. Хмарна MFA надсилає запити автентифікації на обробку в інфраструктуру вендора. Досвід кінцевого користувача ідентичний: запит другого фактора. Відмінність — де відбувається обробка й чи потрібне зовнішнє з’єднання. On-premise перевіряє OTP локально, без вихідних викликів. Хмарна MFA перестає працювати, якщо API вендора недоступне.
Чому регульовані галузі надають перевагу on-premise MFA у 2026 році?
Три причини. По-перше, резидентність даних: GDPR, DORA та PCI DSS накладають вимоги щодо того, де обробляються дані автентифікації; on-premise MFA тримає їх повністю під контролем організації. По-друге, air-gapped мережі: секретні середовища й середовища критичної інфраструктури не можуть маршрутизувати запити до зовнішніх API — on-premise є єдиною архітектурою, яка тут функціонує. По-третє, простота аудиту: відсутність стороннього процесора автентифікації означає відсутність оцінки безпеки вендора в межах аудиту комплаєнсу.
Чи може on-premise MFA від Protectimus працювати в air-gapped мережах?
Так. Уся перевірка OTP виконується проти seed-значень токенів, збережених локально. Під час автентифікації не виконується жодного вихідного виклику. Платформа функціонує без інтернет-з’єднання після початкового розгортання. Попередньо активовані апаратні токени підтримують повністю ізольовані air-gapped розгортання.
Які апаратні вимоги для розгортання on-premise MFA?
Рекомендований мінімум на вузол: 2-ядерний CPU, 8 ГБ RAM, 20 ГБ сховища, Linux чи Windows. Продакшн HA-розгортання зазвичай використовують кластер із 3 вузлів із балансувальником навантаження. Ті самі вимоги до розгортання застосовні до фізичних, віртуальних і приватнохмарних середовищ, включно з AWS та Azure.
Чи підтримує on-premise MFA кластеризацію й високу доступність?
Так. Рекомендований мінімум — кластер із 3 вузлів із балансуванням навантаження через HAProxy та реплікацією бази даних primary-replica. Автоматичний фейловер маршрутизує запити на справні вузли, якщо один із них стає недоступним. Кількість вузлів понад три підвищує і пропускну здатність, і відмовостійкість.
Які сервіси може захистити on-premise MFA?
Active Directory через DSPA, VPN-шлюзи та інші сервіси через RADIUS, федеровані застосунки через плагін ADFS, вхід у робочу станцію Windows та RDP через Windows Credential Provider, Outlook Web App, Roundcube та кастомні вебзастосунки через REST API.
Чи відповідає on-premise MFA вимогам GDPR, DORA, PCI DSS, HIPAA?
On-premise — найнадійніша позиція комплаєнсу для фреймворків із вимогами до резидентності даних. Вимозі 8.4.2 PCI DSS v4.0 можна відповідати через OATH TOTP за допомогою RADIUS та інших компонентів інтеграції. Відповідність GDPR посилюється усуненням залежності від зовнішнього процесора автентифікації. Вимоги DORA щодо ризиків третьої сторони ICT не застосовуються до внутрішньо розміщеної інфраструктури. Технічні гарантії HIPAA задовольняються завдяки журналам автентифікації, що зберігаються локально.
Скільки часу потрібно для розгортання Protectimus On-Premise MFA Platform?
Стандартне однодоменне середовище — один ліс AD, один VPN-шлюз, стандартні робочі станції — досяжне за один-два дні, включно з пілотним тестуванням. Повне впровадження залежить від кількості інтеграцій і підходу до реєстрації. Портал самообслуговування й масовий CSV-провіжінінг значно знижують навантаження на адміністратора під час впровадження. Зв’яжіться з Protectimus, щоб оцінити ваше конкретне середовище.
Висновок
On-premise MFA — не правильний вибір для кожної організації. За відсутності регуляторних вимог до резидентності даних чи вимог до ізоляції мережі хмарна MFA швидша й операційно простіша.
Для організацій, де ці обмеження реальні — де вихід даних автентифікації за межі мережі створює ризик для комплаєнсу, де air-gapped архітектура унеможливлює зовнішні виклики API, — on-premise є єдиною архітектурою, яка тут працює. Protectimus On-Premise MFA Platform покриває повне розгортання для такого сценарію: DSPA для Active Directory, RADIUS для VPN, ADFS для федерованих застосунків, Windows Credential Provider для робочих станцій.
