10. MFA для API та інтеграцій
! | платформа вимагає повторну MFA. | style="background:#c8e6c9;" | MFA + рольовий контроль. Рівень
! |-
| status
| varchar
| ACTIVE, PENDING, DISABLED, LOST. |-
| AC-16
| виступає як користувач системи тільки з SMS. | Він підсвічується помаранчевим. Поле
12. Dashboard MFA
! |-
| status
| varchar
| PENDING, PASSED, FAILED, EXPIRED. | style="background:#c8e6c9;" | Must have
|-
| Віддалений доступ
| MFA обов’язкова завжди. |-
| Email code
| style="background:#ef9a9a;" | Ні
| Ризик компрометації пошти. |-
| SMS-код
| Код у SMS
| style="background:#ffcc80;" | Базовий
| Краще, ніж без MFA, але не найкращий варіант. Критерій
! {| class="wikitable"
MFA fatigue — це коли зловмисник уже знає пароль і багато разів надсилає push-запити користувачу, сподіваючись, що той випадково натисне «Підтвердити». | style="background:#c8e6c9;" | Must have
|-
| Expiration date
| Token не повинен бути вічним. | style="background:#c8e6c9;" | Must have
|-
| IP whitelist
| Дозволити доступ тільки з відомих IP. Управлінський результат: керівник повинен бачити, у кого MFA увімкнена, у кого вимкнена, які ролі входять без другого фактора, які користувачі мають застарілі методи MFA, які входи були підозрілими та які акаунти потрібно заблокувати. | Потрібне додаткове погодження. №
MFA — це багатофакторна автентифікація. |-
| user_id
| uuid
| користувач системи. |-
| user_id
| uuid
| користувач системи. Роль
14. Acceptance Criteria
- CISA: More than a Password. |}
! ! {| class="wikitable"
Етап 3. Технічне впровадження
13. Впровадження MFA в K2 ERP
NIST SP 800-63B пояснює, що phishing resistance потребує криптографічної автентифікації, а автентифікатори з ручним введенням коду, як приклад OTP, не вважаються phishing-resistant, бо код можна ввести на фальшивому сайті й передати зловмиснику. |-
| last_used_at
| timestamp
| Останнє використання. Приклад
! | платформа вимагає новий challenge.SEO title: MFA для ERP
SEO keywords: MFA, 2FA, багатофакторна автентифікація, ERP security, K2 ERP, кібербезпека ERP, FIDO2, passkeys, OTP, TOTP, push, SMS, контроль доступу
</noinclude>
{{SEO
Шаблон для службового SEO-опису сторінки.
}}
- TOTP;
- FIDO2 / passkeys;
- push або number matching;
- recovery codes;
- device trust;
- risk-based challenge;
- журнал MFA;
- dashboard. |-
| TOTP
| style="background:#ffcc80;" | Ні
| Краще за пароль, але код можна ввести на фішинговій сторінці. |}
2. Чому MFA критична саме для ERP
6. MFA fatigue / push bombing
API не використовує MFA так само, як людина. | платформа показує QR, приймає код і активує метод. |-
| Біометрія без криптографії
| Face ID / Touch ID тільки для розблокування
| style="background:#fff9c4;" | Залежить від реалізації
| Має бути прив’язана до безпечного автентифікатора. |-
| method_id
| uuid
| Метод MFA. |-
| AC-17
| виступає як підозрілі MFA-запити. |}
У ERP зберігаються:
! | style="background:#c8e6c9;" | Must have
|-
| Новий пристрій
| MFA + підтвердження пристрою. Приклад
- number matching;
- показ геолокації та пристрою;
- rate limit на MFA-запити;
- блокування після кількох відхилень;
- навчання користувачів;
- alert адміністратору;
- перехід на FIDO2 / passkeys для критичних ролей. | style="background:#c8e6c9;" | Must have
| Admin MFA
|
MFA для створення, перегляду та відкликання token. Поле
14.5. Dashboard
|
| AC-8
|
style="background:#ffcc80;" | Високий
|
! |-
| AC-14
| Адміністратор відкриває MFA dashboard. | style="background:#c8e6c9;" | Must have
|-
| Новий IP / країна
| MFA challenge + alert. * Внутрішні вимоги K2 ERP до ролей, доступів, MFA, журналювання та API-безпеки.=== 14.2. Критичні ролі ===
! |-
| FIDO2 / Security Key
| YubiKey, Feitian, Titan Key
| style="background:#c8e6c9;" | Дуже сильний
| Phishing-resistant MFA. |}
ERP — це не сайт із новинами і не проста CRM. | Вони підсвічуються червоним і створюють alert. Коментар
- спочатку адміністратори;
- потім бухгалтерський обліковий облік;
- потім фінансовий блок;
- потім керівники;
- потім HR;
- потім усі інші користувачі. Поле
7.1. Базова політика
NIST у Digital Identity Guidelines описує, що на рівні AAL2 автентифікація має виконуватись через багатофакторний автентифікатор або комбінацію двох однофакторних автентифікаторів. | style="background:#c8e6c9;" | Must have
|-
| Зміна ролей
| Повторна MFA-перевірка. | style="background:#ef9a9a;" | Критично
|-
| style="background:#ef9a9a;" | провідний бухгалтер
| Доступ до фінансів, податків, зарплат, документів. |}
! |-
| AC-10
| користувач системи запускає масовий експорт. Чому потрібна MFA
! |-
| AC-12
| Recovery виконано. | style="background:#ffcc80;" | Високий
|-
| style="background:#ffcc80;" | HR / зарплата
| Доступ до персональних і зарплатних даних. Значення
Етап 5. Контроль
|-
| AC-1
| користувач системи вмикає TOTP. | Запускається recovery-процедура. FIDO2 / passkeys або TOTP як мінімум виступає ключовою рисою Рекомендовано для K2 ERP: для адміністраторів і фінансових ролей. користувач системи
Захист:
| Щось, що користувач системи знає
|
Пароль, PIN
|
-
|
payload
|
jsonb
|
style="background:#c8e6c9;" | MFA + погодження. |-
|
Push без number matching
|
Ні
|
-
|
AC-9
|
Вхід дозволено тільки після другого фактора. Очікуваний результат
- recovery codes;
- резервний фактор;
- процедуру відновлення доступу;
- перевірку особи користувача;
- погодження адміністратором;
- журнал recovery-події;
- заборону відновлення доступу одним адміністратором для критичних ролей;
- тимчасовий доступ із коротким TTL;
- обов’язкове повторне конфігурація MFA після recovery. | style="background:#ffcc80;" | Високий
|
| Віддалений доступ
|
style="background:#c8e6c9;" | Must have
|
| Фінансові ролі
|
-
|
risk_score
|
integer
|
Оцінка ризику.
|
| admin2
|
Адміністратор
|
Вимкнено
|
Критично
|
Заблокувати або увімкнути MFA
|
| buh_olena
|
Бухгалтер
|
SMS
|
Високий
|
Перевести на TOTP/FIDO2
|
| sales_ivan
|
Менеджер
|
TOTP
|
Норма
|
Без дії
|
| cfo
|
Фіндиректор
|
FIDO2
|
Добре
|
Без дії
|
Adaptive MFA вмикає додаткову перевірку за ризиковими умовами:
! Очікуваний результат
! №
! ! Тип
! |-
| created_at
| timestamp
| Дата. Коментар
- фінансові документи;
- банківські виписки;
- платежі;
- зарплати;
- персональні інформаційні дані;
- договори;
- реквізити контрагентів;
- ціни;
- знижки;
- залишки;
- виробництво;
- управлінська формування звітів;
- податкова інформаційні матеріали;
- інтеграції з банками, ПРРО, доставкою, маркетплейсами. Очікуваний результат
| === 14.1. Базова MFA ===
|
| id
|
uuid
|
ID методу. Критерій
| id
|
uuid
|
ID challenge. * щотижневий звіт;
- список користувачів без MFA;
- блокування критичних ролей без MFA;
- регулярний перегляд методів;
- заміна SMS на сильніші методи. Рівень
- визначити всіх активних користувачів;
- визначити критичні ролі;
- знайти спільні логіни;
- знайти користувачів без входу понад 90 днів;
- знайти адміністраторів;
- знайти API-користувачів. Критерій
| class="wikitable"
|
-
|
FIDO2 security key
|
Так
|
Криптографічно прив’язаний до справжнього домену. SEO-опис
|
| Зміна банківських реквізитів
|
style="background:#ef9a9a;" | Критично
|
| Фінансовий директор
|
Доступ до платежів, бюджетів, рахунків, управлінської звітності.=== 14.3. Step-up MFA ===
- визначити обов’язкові ролі;
- визначити allowed MFA methods;
- заборонити слабкі методи для критичних ролей;
- визначити recovery-процедуру;
- визначити step-up MFA для критичних дій.== 9. Recovery та резервні коди ==
Не вся MFA однаково сильна. |-
|
user_id
|
uuid
|
style="background:#c8e6c9;" | Must have
|
| Idempotency key
|
-
|
method_type
|
varchar
|
-
|
AC-7
|
Фіндиректор входить із нового пристрою. Для API потрібні інші контролі. Критерій
|
== 3. Де MFA має бути обов’язковою ==
|
-
|
ip_address
|
varchar
|
style="background:#c8e6c9;" | Must have
|
| Token rotation
|
}
Критично критично: recovery-процедура не повинна бути слабшим місцем, ніж MFA.
|
-
|
Щось, чим користувач системи виступає як
|
Біометрія на пристрої
|
-
|
AC-3
|
користувач системи вводить неправильний код. Тип
|
платформа вимагає повторну MFA. Рівень захисту
16. Джерела
|
style="background:#c8e6c9;" | MFA + audit log. Роль / зона
|
-
|
Push із number matching
|
Частково краще
|
style="background:#c8e6c9;" | MFA адміністратора. Phishing-resistant? | Він підсвічується червоним. |-
|
created_at
|
timestamp
|
Він бачить покриття MFA по ролях. Рекомендація
|
Правило
|
№
1. Що таке MFA
MFA має бути безпечною, але не повинна блокувати бізнес-середовище назавжди. Метод
|
style="background:#c8e6c9;" | MFA + погодження. | style="background:#c8e6c9;" | MFA + журнал.=== 12.2. Проблемні користувачі ===
|
| Token scopes
|
Обмежити права інтеграції. операційна дія
17. Див. так само
Етап 4. Міграція користувачів
Challenge стає FAILED, спроба логуються. SEO-опис
11.3. mfa_events
Ризик без MFA: якщо пароль користувача ERP викрадено через phishing, malware, витік браузера, слабкий пароль або повторне використання пароля, зловмисник здатна зайти в систему як легальний користувач системи. |}
|
}
|
style="background:#ffcc80;" | Високий
|
| API-адміністрування
|
-
|
user_agent
|
text
|
Браузер / пристрій. Тип MFA
|
-
|
Масовий експорт даних
|
-
|
Створення платежу
|
платформа вимагає MFA і логування. Якщо зловмисник отримує пароль бухгалтера забезпечується через Критично критично: пароль більше не можна вважати достатнім захистом; так само реалізовано адміністратора, фінансового директора або API-користувача, він здатна отримати доступ до фінансів, зарплат, договорів, складу, цін, банківських даних і управлінської звітності. | style="background:#ef9a9a;" | Критично
|
| Користувачі з банківськими операціями
|
style="background:#c8e6c9;" | Must have
|
| бухгалтерський обліковий облік
|
MFA обов’язкова завжди. Очікуваний результат
ERP. |-
|
Видалення або скасування документа
|
Ризик приховування операцій. ERP керує бізнесом. :contentReference [oaicite:0]{index=0}
|
№
|
-
|
created_at
|
timestamp
|
Дата створення. Дія
Потрібно передбачити:
7.2. Adaptive MFAЕтап 1. Аудит користувачів
| AC-5
|
Адміністратор без MFA намагається увійти. Показник
|
Вхід заблоковано або примусово вимагається MFA. |-
|
Зміна ролі користувача
|
Ризик розширення доступу. ! Коментар
11.2. mfa_challenges
5. Phishing-resistant MFA
|
| Адміністратори
|
-
|
challenge_type
|
varchar
|
style="background:#c8e6c9;" | Must have
|
| Signed webhooks
|
-
|
Push із number matching
|
користувач системи вводить число з екрана входу
|
Кращий
|
Захищає від випадкового натискання «Approve». Вона вимагає від користувача підтвердити вхід більше ніж одним способом. Політика
|
Чому потрібна повторна MFA
|
=== 11.1. mfa_methods ===
|
|
| SMS
|
Ні
|
-
|
Passkeys
|
Ключ доступу на пристрої
|
Дуже сильний
|
Сучасний phishing-resistant підхід. Тип
|
style="background:#c8e6c9;" | Must have
|
Зазвичай фактори поділяються на:
Етап 2. Політика MFA
15. Висновок
MFA потрібна не тільки на вході, а й перед окремими діями.== 7. Політики MFA для K2 ERP ==
|
| Користувачів із MFA
|
86%
|
Потрібно довести до 100%
|
| Адміністраторів із MFA
|
100%
|
Норма
|
| Бухгалтерів із MFA
|
92%
|
Потрібна дія
|
| Фінансових ролей із MFA
|
100%
|
Норма
|
| Користувачів тільки з SMS
|
18
|
Замінити на TOTP/FIDO2
|
| Невдалих MFA за день
|
12
|
Контроль
|
| Підозрілих MFA-запитів
|
3
|
Критично
|
| Recovery-подій за місяць
|
4
|
Контроль
|
| API-контроль
|
}
Орієнтир: CISA прямо зазначає, що деякі типи MFA кращі за інші: phishing-resistant MFA виступає як стандартом, до якого мають прагнути організації, але будь-яка MFA краще, ніж її відсутність. Очікуваний результат
14.4. RecoveryРизик: якщо користувач системи отримує push-запит, який сам не ініціював, і натискає «Approve», MFA не захистить систему. |-
| ip_address
|
varchar
|
-
|
Email-код
|
Код на email
|
Базовий
|
Залежить від безпеки поштової скриньки. №
|
-
|
AC-4
|
Challenge прострочений. Критерій
4. Типи MFA
|
| id
|
uuid
|
style="background:#ef9a9a;" | Критично
|
| Менеджери з доступом до цін і знижок
|
-
|
method_type
|
varchar
|
-
|
Push-підтвердження
|
Підтвердити в мобільному додатку
|
Добрий
|
-
|
AC-6
|
Бухгалтер без MFA намагається увійти. MFA
|
SEO-опис
| Подія логуються, користувач системи зобов’язаний налаштувати новий фактор. | style="background:#c8e6c9;" | Must have
|
8. MFA для критичних операцій
- новий пристрій;
- новий браузер;
- нова країна;
- незвичний час входу;
- багато невдалих спроб;
- спроба експорту даних;
- зміна критичних реквізитів;
- зміна ролей;
- доступ до зарплат;
- доступ до банківських операцій. :contentReference [oaicite:2]{index=2}
|
| Адміністратор ERP
|
}
Правильне рішення для бізнесу: у K2 ERP потрібно впровадити MFA для критичних ролей, адміністраторів, бухгалтерії, фінансів, керівників, віддаленого доступу, API-адміністрування та всіх користувачів із доступом до чутливих даних. {| class="wikitable"
11. Модель даних MFA
| -
|
Вимкнення інтеграції
|
style="background:#c8e6c9;" | Must have
|
| Зміна реквізитів
|
-
|
TOTP
|
Google Authenticator, Microsoft Authenticator, 1Password, Bitwarden
|
Добрий
|
функціонує офлайн, коди змінюються кожні 30 секунд. Стан
|
-
|
expires_at
|
timestamp
|
-
|
AC-15
|
}
MFA — це один із найважливіших і найшвидших способів зменшити ризик злому ERP.
|
-
|
AC-2
|
-
|
event_type
|
varchar
|
-
|
AC-13
|
Recovery для адміністратора. Колір
|
-
|
Щось, що користувач системи має
|
Телефон, токен, security key, passkey
|
Сильніший захист, бо зловмиснику потрібен фізичний або криптографічний фактор. Фактор
12.1. KPI керівника / адміністратора
Зелена зона: у K2 ERP увімкнено MFA для критичних ролей, step-up MFA для небезпечних операцій, dashboard контролю, журнал подій, recovery-процедура та поступовий перехід на phishing-resistant MFA. |-
|
Passkey
|
Так
|
платформа вимагає налаштувати MFA. |-
|
is_primary
|
boolean
|
платформа вимагає MFA і створює подію ризику. * NIST SP 800-63B-4: Authentication and Authenticator Management. :contentReference [oaicite:1]{index=1}
|
| AC-11
|
користувач системи втратив MFA-пристрій. Ризик
Головне правило: пароль — це лише перший бар’єр. * NIST SP 800-63B: Digital Identity Guidelines. |}
| -
|
user_agent
|
text
|
Пристрій. Призначення
Червона зона: адміністратори, бухгалтерський обліковий облік, фінансовий блок або керівники входять у ERP тільки за паролем.
|
|
|
|
| |
|
|
