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