Перейти до вмісту

MFA

Матеріал з K2 ERP Wiki Ukraine — База знань з автоматизації та санкцій в Україні


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



Критично важливо: пароль більше не можна вважати достатнім захистом для ERP. Якщо зловмисник отримує пароль бухгалтера, адміністратора, фінансового директора або API-користувача, він може отримати доступ до фінансів, зарплат, договорів, складу, цін, банківських даних і управлінської звітності.

Правильне рішення: у K2 ERP потрібно впровадити MFA для критичних ролей, адміністраторів, бухгалтерії, фінансів, керівників, віддаленого доступу, API-адміністрування та всіх користувачів із доступом до чутливих даних.

Орієнтир: CISA прямо зазначає, що деякі типи MFA кращі за інші: phishing-resistant MFA є стандартом, до якого мають прагнути організації, але будь-яка MFA краще, ніж її відсутність. :contentReference[oaicite:0]{index=0}

Управлінський результат: керівник повинен бачити, у кого MFA увімкнена, у кого вимкнена, які ролі входять без другого фактора, які користувачі мають застарілі методи MFA, які входи були підозрілими та які акаунти потрібно заблокувати.

1. Що таке MFA

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

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

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

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

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

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

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

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

Ризик без MFA: якщо пароль користувача ERP викрадено через phishing, malware, витік браузера, слабкий пароль або повторне використання пароля, зловмисник може зайти в систему як легальний користувач.

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

Роль / зона Чому потрібна MFA Рівень
Адміністратор ERP Може змінювати ролі, права, налаштування, інтеграції. Критично
Головний бухгалтер Доступ до фінансів, податків, зарплат, документів. Критично
Фінансовий директор Доступ до платежів, бюджетів, рахунків, управлінської звітності. Критично
Користувачі з банківськими операціями Можуть впливати на платежі або реквізити. Критично
Менеджери з доступом до цін і знижок Можуть змінити комерційні умови. Високий
HR / зарплата Доступ до персональних і зарплатних даних. Високий
Віддалений доступ Вхід поза офісною мережею має більший ризик. Високий
API-адміністрування Компрометація API може вплинути на інтеграції. Високий

4. Типи MFA

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

Рекомендовано для K2 ERP: для адміністраторів і фінансових ролей — FIDO2 / passkeys або TOTP як мінімум. Для звичайних користувачів — TOTP або push із number matching. SMS використовувати лише як перехідний або резервний метод.

5. Phishing-resistant MFA

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

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

Метод Phishing-resistant? Коментар
SMS Ні Код можна виманити.
Email code Ні Ризик компрометації пошти.
TOTP Ні Краще за пароль, але код можна ввести на фішинговій сторінці.
Push без number matching Ні Є ризик MFA fatigue.
Push із number matching Частково краще Зменшує ризик випадкового підтвердження.
FIDO2 security key Так Криптографічно прив’язаний до справжнього домену.
Passkey Так Сучасний phishing-resistant варіант.

6. MFA fatigue / push bombing

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

Ризик: якщо користувач отримує push-запит, який сам не ініціював, і натискає «Approve», MFA не захистить систему.

Захист:

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

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

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

Політика Правило Колір
Адміністратори MFA обов’язкова завжди. Must have
Бухгалтерія MFA обов’язкова завжди. Must have
Фінансові ролі MFA обов’язкова завжди. Must have
Віддалений доступ MFA обов’язкова завжди. Must have
Новий пристрій MFA + підтвердження пристрою. Must have
Новий IP / країна MFA challenge + alert. Must have
Зміна реквізитів Повторна MFA-перевірка. Must have
Зміна ролей Повторна MFA-перевірка. Must have

7.2. Adaptive MFA

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

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

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

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

Операція Чому потрібна повторна MFA Рекомендація
Зміна банківських реквізитів Ризик підміни рахунку. MFA + погодження.
Створення платежу Ризик фінансової втрати. MFA + рольовий контроль.
Зміна ролі користувача Ризик розширення доступу. MFA адміністратора.
Масовий експорт даних Ризик витоку. MFA + журнал.
Видалення або скасування документа Ризик приховування операцій. MFA + audit log.
Вимкнення інтеграції Ризик зупинки бізнес-процесу. MFA + погодження.

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

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

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

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

Критично важливо: recovery-процедура не повинна бути слабшим місцем, ніж MFA. Якщо MFA можна обійти дзвінком одному адміністратору, це ризик.

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

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

API-контроль Призначення Рівень
Token scopes Обмежити права інтеграції. Must have
IP whitelist Дозволити доступ тільки з відомих IP. Must have
Token rotation Регулярна заміна token. Must have
Expiration date Token не повинен бути вічним. Must have
Signed webhooks Захист від підроблених callback. Must have
Idempotency key Захист від повторної обробки. Must have
Admin MFA MFA для створення, перегляду та відкликання token. Must have

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

11.1. mfa_methods

Поле Тип Опис
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

Поле Тип Опис
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

Поле Тип Опис
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 керівника / адміністратора

Показник Значення Стан
Користувачів із MFA 86% Потрібно довести до 100%
Адміністраторів із MFA 100% Норма
Бухгалтерів із MFA 92% Потрібна дія
Фінансових ролей із MFA 100% Норма
Користувачів тільки з SMS 18 Замінити на TOTP/FIDO2
Невдалих MFA за день 12 Контроль
Підозрілих MFA-запитів 3 Критично
Recovery-подій за місяць 4 Контроль

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

Користувач Роль MFA Ризик Дія
admin2 Адміністратор Вимкнено Критично Заблокувати або увімкнути MFA
buh_olena Бухгалтер SMS Високий Перевести на TOTP/FIDO2
sales_ivan Менеджер TOTP Норма Без дії
cfo Фіндиректор FIDO2 Добре Без дії

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

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

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

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

14.3. Step-up MFA

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

14.4. Recovery

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

14.5. Dashboard

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

15. Висновок

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

Червона зона: адміністратори, бухгалтерія, фінанси або керівники входять у ERP тільки за паролем.

Зелена зона: у K2 ERP увімкнено MFA для критичних ролей, step-up MFA для небезпечних операцій, dashboard контролю, журнал подій, recovery-процедура та поступовий перехід на phishing-resistant MFA.

Головне правило: пароль — це лише перший бар’єр. Для 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. Див. також

Отримано з https://wiki.erp.kyiv.ua/index.php?title=MFA&oldid=999