R: Створена сторінка: {{DISPLAYTITLE:MFA для ERP: багатофакторна автентифікація в K2 ERP}} {{SEO |title=MFA для ERP |description=Стаття про MFA для ERP-систем: навіщо потрібна багатофакторна автентифікація, де її вмикати обов'язково, які є типи MFA, ризики без MFA, політики доступу, dashboard і впровадження в K2 ERP....

2026-05-07T19:11:10Z

Створена сторінка: {{DISPLAYTITLE:MFA для ERP: багатофакторна автентифікація в K2 ERP}} {{SEO |title=MFA для ERP |description=Стаття про MFA для ERP-систем: навіщо потрібна багатофакторна автентифікація, де її вмикати обов'язково, які є типи MFA, ризики без MFA, політики доступу, dashboard і впровадження в K2 ERP....

Нова сторінка

{{DISPLAYTITLE:MFA для ERP: багатофакторна автентифікація в K2 ERP}}

{{SEO
|title=MFA для ERP
|description=Стаття про MFA для ERP-систем: навіщо потрібна багатофакторна автентифікація, де її вмикати обов'язково, які є типи MFA, ризики без MFA, політики доступу, dashboard і впровадження в K2 ERP.
|keywords=MFA, 2FA, багатофакторна автентифікація, ERP security, K2 ERP, кібербезпека ERP, FIDO2, passkeys, OTP, TOTP, push, SMS, контроль доступу
}}

<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">
'''Критично важливо:''' пароль більше не можна вважати достатнім захистом для ERP. Якщо зловмисник отримує пароль бухгалтера, адміністратора, фінансового директора або API-користувача, він може отримати доступ до фінансів, зарплат, договорів, складу, цін, банківських даних і управлінської звітності.
</div>

<div style="border-left: 8px solid #2e7d32; background: #e8f5e9; padding: 14px 18px; margin: 16px 0;">
'''Правильне рішення:''' у K2 ERP потрібно впровадити MFA для критичних ролей, адміністраторів, бухгалтерії, фінансів, керівників, віддаленого доступу, API-адміністрування та всіх користувачів із доступом до чутливих даних.
</div>

<div style="border-left: 8px solid #1565c0; background: #e3f2fd; padding: 14px 18px; margin: 16px 0;">
'''Орієнтир:''' CISA прямо зазначає, що деякі типи MFA кращі за інші: phishing-resistant MFA є стандартом, до якого мають прагнути організації, але будь-яка MFA краще, ніж її відсутність. :contentReference[oaicite:0]{index=0}
</div>

<div style="border-left: 8px solid #6a1b9a; background: #f3e5f5; padding: 14px 18px; margin: 16px 0;">
'''Управлінський результат:''' керівник повинен бачити, у кого MFA увімкнена, у кого вимкнена, які ролі входять без другого фактора, які користувачі мають застарілі методи MFA, які входи були підозрілими та які акаунти потрібно заблокувати.
</div>

__TOC__

== 1. Що таке MFA ==

'''MFA''' — це багатофакторна автентифікація. Вона вимагає від користувача підтвердити вхід більше ніж одним способом.

Зазвичай фактори поділяються на:

{| class="wikitable"
! Фактор
! Приклад
! Коментар
|-
| Щось, що користувач знає
| Пароль, PIN
| Найслабший фактор, якщо використовується самостійно.
|-
| Щось, що користувач має
| Телефон, токен, security key, passkey
| Сильніший захист, бо зловмиснику потрібен фізичний або криптографічний фактор.
|-
| Щось, чим користувач є
| Біометрія на пристрої
| Використовується для активації пристрою або passkey.
|}

NIST у Digital Identity Guidelines описує, що на рівні AAL2 автентифікація має виконуватись через багатофакторний автентифікатор або комбінацію двох однофакторних автентифікаторів. :contentReference[oaicite:1]{index=1}

== 2. Чому MFA критична саме для ERP ==

ERP — це не сайт із новинами і не проста CRM. ERP керує бізнесом.

У ERP зберігаються:

* фінансові документи;
* банківські виписки;
* платежі;
* зарплати;
* персональні дані;
* договори;
* реквізити контрагентів;
* ціни;
* знижки;
* залишки;
* виробництво;
* управлінська звітність;
* податкова інформація;
* інтеграції з банками, ПРРО, доставкою, маркетплейсами.

<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">
'''Ризик без MFA:''' якщо пароль користувача ERP викрадено через phishing, malware, витік браузера, слабкий пароль або повторне використання пароля, зловмисник може зайти в систему як легальний користувач.
</div>

== 3. Де MFA має бути обов’язковою ==

{| class="wikitable"
! Роль / зона
! Чому потрібна MFA
! Рівень
|-
| style="background:#ef9a9a;" | Адміністратор ERP
| Може змінювати ролі, права, налаштування, інтеграції.
| style="background:#ef9a9a;" | Критично
|-
| style="background:#ef9a9a;" | Головний бухгалтер
| Доступ до фінансів, податків, зарплат, документів.
| style="background:#ef9a9a;" | Критично
|-
| style="background:#ef9a9a;" | Фінансовий директор
| Доступ до платежів, бюджетів, рахунків, управлінської звітності.
| style="background:#ef9a9a;" | Критично
|-
| style="background:#ef9a9a;" | Користувачі з банківськими операціями
| Можуть впливати на платежі або реквізити.
| style="background:#ef9a9a;" | Критично
|-
| style="background:#ffcc80;" | Менеджери з доступом до цін і знижок
| Можуть змінити комерційні умови.
| style="background:#ffcc80;" | Високий
|-
| style="background:#ffcc80;" | HR / зарплата
| Доступ до персональних і зарплатних даних.
| style="background:#ffcc80;" | Високий
|-
| style="background:#ffcc80;" | Віддалений доступ
| Вхід поза офісною мережею має більший ризик.
| style="background:#ffcc80;" | Високий
|-
| style="background:#ffcc80;" | API-адміністрування
| Компрометація API може вплинути на інтеграції.
| style="background:#ffcc80;" | Високий
|}

== 4. Типи MFA ==

{| class="wikitable"
! Тип MFA
! Приклад
! Рівень захисту
! Коментар
|-
| SMS-код
| Код у SMS
| style="background:#ffcc80;" | Базовий
| Краще, ніж без MFA, але не найкращий варіант.
|-
| Email-код
| Код на email
| style="background:#ffcc80;" | Базовий
| Залежить від безпеки поштової скриньки.
|-
| TOTP
| Google Authenticator, Microsoft Authenticator, 1Password, Bitwarden
| style="background:#fff9c4;" | Добрий
| Працює офлайн, коди змінюються кожні 30 секунд.
|-
| Push-підтвердження
| Підтвердити в мобільному додатку
| style="background:#fff9c4;" | Добрий
| Потрібен захист від MFA fatigue.
|-
| Push із number matching
| Користувач вводить число з екрана входу
| style="background:#c8e6c9;" | Кращий
| Захищає від випадкового натискання «Approve».
|-
| FIDO2 / Security Key
| YubiKey, Feitian, Titan Key
| style="background:#c8e6c9;" | Дуже сильний
| Phishing-resistant MFA.
|-
| Passkeys
| Ключ доступу на пристрої
| style="background:#c8e6c9;" | Дуже сильний
| Сучасний phishing-resistant підхід.
|-
| Біометрія без криптографії
| Face ID / Touch ID тільки для розблокування
| style="background:#fff9c4;" | Залежить від реалізації
| Має бути прив’язана до безпечного автентифікатора.
|}

<div style="border-left: 8px solid #2e7d32; background: #e8f5e9; padding: 14px 18px; margin: 16px 0;">
'''Рекомендовано для K2 ERP:''' для адміністраторів і фінансових ролей — FIDO2 / passkeys або TOTP як мінімум. Для звичайних користувачів — TOTP або push із number matching. SMS використовувати лише як перехідний або резервний метод.
</div>

== 5. Phishing-resistant MFA ==

Не вся MFA однаково сильна.

NIST SP 800-63B пояснює, що phishing resistance потребує криптографічної автентифікації, а автентифікатори з ручним введенням коду, наприклад OTP, не вважаються phishing-resistant, бо код можна ввести на фальшивому сайті й передати зловмиснику. :contentReference[oaicite:2]{index=2}

{| class="wikitable"
! Метод
! Phishing-resistant?
! Коментар
|-
| SMS
| style="background:#ef9a9a;" | Ні
| Код можна виманити.
|-
| Email code
| style="background:#ef9a9a;" | Ні
| Ризик компрометації пошти.
|-
| TOTP
| style="background:#ffcc80;" | Ні
| Краще за пароль, але код можна ввести на фішинговій сторінці.
|-
| Push без number matching
| style="background:#ffcc80;" | Ні
| Є ризик MFA fatigue.
|-
| Push із number matching
| style="background:#fff9c4;" | Частково краще
| Зменшує ризик випадкового підтвердження.
|-
| FIDO2 security key
| style="background:#c8e6c9;" | Так
| Криптографічно прив’язаний до справжнього домену.
|-
| Passkey
| style="background:#c8e6c9;" | Так
| Сучасний phishing-resistant варіант.
|}

== 6. MFA fatigue / push bombing ==

'''MFA fatigue''' — це коли зловмисник уже знає пароль і багато разів надсилає push-запити користувачу, сподіваючись, що той випадково натисне «Підтвердити».

<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">
'''Ризик:''' якщо користувач отримує push-запит, який сам не ініціював, і натискає «Approve», MFA не захистить систему.
</div>

Захист:

* number matching;
* показ геолокації та пристрою;
* rate limit на MFA-запити;
* блокування після кількох відхилень;
* навчання користувачів;
* alert адміністратору;
* перехід на FIDO2 / passkeys для критичних ролей.

== 7. Політики MFA для K2 ERP ==

=== 7.1. Базова політика ===

{| class="wikitable"
! Політика
! Правило
! Колір
|-
| Адміністратори
| MFA обов’язкова завжди.
| style="background:#c8e6c9;" | Must have
|-
| Бухгалтерія
| MFA обов’язкова завжди.
| style="background:#c8e6c9;" | Must have
|-
| Фінансові ролі
| MFA обов’язкова завжди.
| style="background:#c8e6c9;" | Must have
|-
| Віддалений доступ
| MFA обов’язкова завжди.
| style="background:#c8e6c9;" | Must have
|-
| Новий пристрій
| MFA + підтвердження пристрою.
| style="background:#c8e6c9;" | Must have
|-
| Новий IP / країна
| MFA challenge + alert.
| style="background:#c8e6c9;" | Must have
|-
| Зміна реквізитів
| Повторна MFA-перевірка.
| style="background:#c8e6c9;" | Must have
|-
| Зміна ролей
| Повторна MFA-перевірка.
| style="background:#c8e6c9;" | Must have
|}

=== 7.2. Adaptive MFA ===

Adaptive MFA вмикає додаткову перевірку за ризиковими умовами:

* новий пристрій;
* новий браузер;
* нова країна;
* незвичний час входу;
* багато невдалих спроб;
* спроба експорту даних;
* зміна критичних реквізитів;
* зміна ролей;
* доступ до зарплат;
* доступ до банківських операцій.

== 8. MFA для критичних операцій ==

MFA потрібна не тільки на вході, а й перед окремими діями.

{| class="wikitable"
! Операція
! Чому потрібна повторна MFA
! Рекомендація
|-
| Зміна банківських реквізитів
| Ризик підміни рахунку.
| style="background:#c8e6c9;" | MFA + погодження.
|-
| Створення платежу
| Ризик фінансової втрати.
| style="background:#c8e6c9;" | MFA + рольовий контроль.
|-
| Зміна ролі користувача
| Ризик розширення доступу.
| style="background:#c8e6c9;" | MFA адміністратора.
|-
| Масовий експорт даних
| Ризик витоку.
| style="background:#c8e6c9;" | MFA + журнал.
|-
| Видалення або скасування документа
| Ризик приховування операцій.
| style="background:#c8e6c9;" | MFA + audit log.
|-
| Вимкнення інтеграції
| Ризик зупинки бізнес-процесу.
| style="background:#c8e6c9;" | MFA + погодження.
|}

== 9. Recovery та резервні коди ==

MFA має бути безпечною, але не повинна блокувати бізнес назавжди.

Потрібно передбачити:

* recovery codes;
* резервний фактор;
* процедуру відновлення доступу;
* перевірку особи користувача;
* погодження адміністратором;
* журнал recovery-події;
* заборону відновлення доступу одним адміністратором для критичних ролей;
* тимчасовий доступ із коротким TTL;
* обов’язкове повторне налаштування MFA після recovery.

<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">
'''Критично важливо:''' recovery-процедура не повинна бути слабшим місцем, ніж MFA. Якщо MFA можна обійти дзвінком одному адміністратору, це ризик.
</div>

== 10. MFA для API та інтеграцій ==

API не використовує MFA так само, як людина. Для API потрібні інші контролі.

{| class="wikitable"
! API-контроль
! Призначення
! Рівень
|-
| Token scopes
| Обмежити права інтеграції.
| style="background:#c8e6c9;" | Must have
|-
| IP whitelist
| Дозволити доступ тільки з відомих IP.
| style="background:#c8e6c9;" | Must have
|-
| Token rotation
| Регулярна заміна token.
| style="background:#c8e6c9;" | Must have
|-
| Expiration date
| Token не повинен бути вічним.
| style="background:#c8e6c9;" | Must have
|-
| Signed webhooks
| Захист від підроблених callback.
| style="background:#c8e6c9;" | Must have
|-
| Idempotency key
| Захист від повторної обробки.
| style="background:#c8e6c9;" | Must have
|-
| Admin MFA
| MFA для створення, перегляду та відкликання token.
| style="background:#c8e6c9;" | Must have
|}

== 11. Модель даних MFA ==

=== 11.1. mfa_methods ===

{| class="wikitable"
! Поле
! Тип
! Опис
|-
| id
| uuid
| ID методу.
|-
| user_id
| uuid
| Користувач.
|-
| method_type
| varchar
| TOTP, SMS, EMAIL, PUSH, FIDO2, PASSKEY.
|-
| status
| varchar
| ACTIVE, PENDING, DISABLED, LOST.
|-
| is_primary
| boolean
| Основний метод.
|-
| last_used_at
| timestamp
| Останнє використання.
|-
| created_at
| timestamp
| Дата створення.
|}

=== 11.2. mfa_challenges ===

{| class="wikitable"
! Поле
! Тип
! Опис
|-
| id
| uuid
| ID challenge.
|-
| user_id
| uuid
| Користувач.
|-
| method_id
| uuid
| Метод MFA.
|-
| challenge_type
| varchar
| LOGIN, STEP_UP, RECOVERY, CRITICAL_ACTION.
|-
| status
| varchar
| PENDING, PASSED, FAILED, EXPIRED.
|-
| risk_score
| integer
| Оцінка ризику.
|-
| ip_address
| varchar
| IP.
|-
| user_agent
| text
| Браузер / пристрій.
|-
| created_at
| timestamp
| Дата створення.
|-
| expires_at
| timestamp
| Строк дії.
|}

=== 11.3. mfa_events ===

{| class="wikitable"
! Поле
! Тип
! Опис
|-
| id
| uuid
| ID події.
|-
| user_id
| uuid
| Користувач.
|-
| event_type
| varchar
| MFA_ENABLED, MFA_DISABLED, MFA_PASSED, MFA_FAILED, RECOVERY_USED.
|-
| method_type
| varchar
| Тип MFA.
|-
| ip_address
| varchar
| IP.
|-
| user_agent
| text
| Пристрій.
|-
| payload
| jsonb
| Технічні дані без секретів.
|-
| created_at
| timestamp
| Дата.
|}

== 12. Dashboard MFA ==

=== 12.1. KPI керівника / адміністратора ===

{| class="wikitable"
! Показник
! Значення
! Стан
|-
| Користувачів із MFA
| 86%
| style="background:#fff9c4;" | Потрібно довести до 100%
|-
| Адміністраторів із MFA
| 100%
| style="background:#c8e6c9;" | Норма
|-
| Бухгалтерів із MFA
| 92%
| style="background:#ffcc80;" | Потрібна дія
|-
| Фінансових ролей із MFA
| 100%
| style="background:#c8e6c9;" | Норма
|-
| Користувачів тільки з SMS
| 18
| style="background:#ffcc80;" | Замінити на TOTP/FIDO2
|-
| Невдалих MFA за день
| 12
| style="background:#ffcc80;" | Контроль
|-
| Підозрілих MFA-запитів
| 3
| style="background:#ef9a9a;" | Критично
|-
| Recovery-подій за місяць
| 4
| style="background:#fff9c4;" | Контроль
|}

=== 12.2. Проблемні користувачі ===

{| class="wikitable"
! Користувач
! Роль
! MFA
! Ризик
! Дія
|-
| admin2
| Адміністратор
| style="background:#ef9a9a;" | Вимкнено
| style="background:#ef9a9a;" | Критично
| Заблокувати або увімкнути MFA
|-
| buh_olena
| Бухгалтер
| style="background:#ffcc80;" | SMS
| style="background:#ffcc80;" | Високий
| Перевести на TOTP/FIDO2
|-
| sales_ivan
| Менеджер
| style="background:#fff9c4;" | TOTP
| style="background:#fff9c4;" | Норма
| Без дії
|-
| cfo
| Фіндиректор
| style="background:#c8e6c9;" | FIDO2
| style="background:#c8e6c9;" | Добре
| Без дії
|}

== 13. Впровадження MFA в K2 ERP ==

=== Етап 1. Аудит користувачів ===

* визначити всіх активних користувачів;
* визначити критичні ролі;
* знайти спільні логіни;
* знайти користувачів без входу понад 90 днів;
* знайти адміністраторів;
* знайти API-користувачів.

=== Етап 2. Політика MFA ===

* визначити обов’язкові ролі;
* визначити allowed MFA methods;
* заборонити слабкі методи для критичних ролей;
* визначити recovery-процедуру;
* визначити step-up MFA для критичних дій.

=== Етап 3. Технічне впровадження ===

* TOTP;
* FIDO2 / passkeys;
* push або number matching;
* recovery codes;
* device trust;
* risk-based challenge;
* журнал MFA;
* dashboard.

=== Етап 4. Міграція користувачів ===

* спочатку адміністратори;
* потім бухгалтерія;
* потім фінанси;
* потім керівники;
* потім HR;
* потім усі інші користувачі.

=== Етап 5. Контроль ===

* щотижневий звіт;
* список користувачів без MFA;
* блокування критичних ролей без MFA;
* регулярний перегляд методів;
* заміна SMS на сильніші методи.

== 14. Acceptance Criteria ==

=== 14.1. Базова MFA ===

{| class="wikitable"
! №
! Критерій
! Очікуваний результат
|-
| AC-1
| Користувач вмикає TOTP.
| Система показує QR, приймає код і активує метод.
|-
| AC-2
| Користувач входить із MFA.
| Вхід дозволено тільки після другого фактора.
|-
| AC-3
| Користувач вводить неправильний код.
| Challenge стає FAILED, спроба логуються.
|-
| AC-4
| Challenge прострочений.
| Система вимагає новий challenge.
|}

=== 14.2. Критичні ролі ===

{| class="wikitable"
! №
! Критерій
! Очікуваний результат
|-
| AC-5
| Адміністратор без MFA намагається увійти.
| Вхід заблоковано або примусово вимагається MFA.
|-
| AC-6
| Бухгалтер без MFA намагається увійти.
| Система вимагає налаштувати MFA.
|-
| AC-7
| Фіндиректор входить із нового пристрою.
| Система вимагає MFA і створює подію ризику.
|}

=== 14.3. Step-up MFA ===

{| class="wikitable"
! №
! Критерій
! Очікуваний результат
|-
| AC-8
| Користувач змінює банківські реквізити.
| Система вимагає повторну MFA.
|-
| AC-9
| Адміністратор змінює роль користувача.
| Система вимагає повторну MFA.
|-
| AC-10
| Користувач запускає масовий експорт.
| Система вимагає MFA і логування.
|}

=== 14.4. Recovery ===

{| class="wikitable"
! №
! Критерій
! Очікуваний результат
|-
| AC-11
| Користувач втратив MFA-пристрій.
| Запускається recovery-процедура.
|-
| AC-12
| Recovery виконано.
| Подія логуються, користувач зобов’язаний налаштувати новий фактор.
|-
| AC-13
| Recovery для адміністратора.
| Потрібне додаткове погодження.
|}

=== 14.5. Dashboard ===

{| class="wikitable"
! №
! Критерій
! Очікуваний результат
|-
| AC-14
| Адміністратор відкриває MFA dashboard.
| Він бачить покриття MFA по ролях.
|-
| AC-15
| Є адміністратор без MFA.
| Він підсвічується червоним.
|-
| AC-16
| Є користувач тільки з SMS.
| Він підсвічується помаранчевим.
|-
| AC-17
| Є підозрілі MFA-запити.
| Вони підсвічуються червоним і створюють alert.
|}

== 15. Висновок ==

MFA — це один із найважливіших і найшвидших способів зменшити ризик злому ERP.

<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">
'''Червона зона:''' адміністратори, бухгалтерія, фінанси або керівники входять у ERP тільки за паролем.
</div>

<div style="border-left: 8px solid #2e7d32; background: #e8f5e9; padding: 14px 18px; margin: 16px 0;">
'''Зелена зона:''' у K2 ERP увімкнено MFA для критичних ролей, step-up MFA для небезпечних операцій, dashboard контролю, журнал подій, recovery-процедура та поступовий перехід на phishing-resistant MFA.
</div>

'''Головне правило:''' пароль — це лише перший бар’єр. Для ERP потрібен другий фактор, а для критичних ролей — бажано phishing-resistant MFA: FIDO2, passkeys або інші криптографічно захищені методи.

== 16. Джерела ==

* CISA: More than a Password.
* CISA: Phishing-Resistant MFA Guidance.
* NIST SP 800-63B: Digital Identity Guidelines.
* NIST SP 800-63B-4: Authentication and Authenticator Management.
* Внутрішні вимоги K2 ERP до ролей, доступів, MFA, журналювання та API-безпеки.

== 17. Див. також ==

* [[K2 ERP]]
* [[Кібербезпека ERP]]
* [[Контроль доступу]]
* [[MFA]]
* [[2FA]]
* [[FIDO2]]
* [[Passkeys]]
* [[TOTP]]
* [[API Security]]
* [[Журнал аудиту]]
* [[Incident Response]]
* [[Zero Trust]]
* [[Рольова модель]]

[[Категорія:ERP]]
[[Категорія:K2 ERP]]
[[Категорія:Кібербезпека]]
[[Категорія:MFA]]
[[Категорія:Контроль доступу]]
[[Категорія:Інформаційна безпека]]

MFA - Історія редагувань