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....

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

<div style="border-left: 8px solid #6a1b9a; background: #f3e5f5; padding: 14px 18px; margin: 16px 0;">

</div>

'''Головне правило:''' пароль — це лише перший бар’єр.; | 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 на сильніші методи.;</div>

!; Поле

FIDO2 / passkeys або TOTP як мінімум виступає ключовою рисою '''Рекомендовано для K2 ERP:''' для адміністраторів і фінансових ролей.; |}

!; |-
| Видалення або скасування документа
| Ризик приховування операцій.;</div>
!; * новий пристрій;
* новий браузер;
* нова країна;
* незвичний час входу;
* багато невдалих спроб;
* спроба експорту даних;
* зміна критичних реквізитів;
* зміна ролей;
* доступ до зарплат;
* доступ до банківських операцій.; | style="background:#c8e6c9;" | MFA + погодження.; Роль / зона

[[Категорія:K2 ERP]]
== 17.; Див.; додатково ==
<div style="border-left: 8px solid #2e7d32; background: #e8f5e9; padding: 14px 18px; margin: 16px 0;">
MFA — це один із найважливіших і найшвидших способів зменшити ризик злому ERP.; Тип MFA

<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">
{| class="wikitable"
!; |-
| Passkeys
| Ключ доступу на пристрої
| style="background:#c8e6c9;" | Дуже сильний
| Сучасний phishing-resistant підхід.; |-
| AC-14
| Адміністратор відкриває MFA dashboard.; | style="background:#c8e6c9;" | Must have
|-
| Новий пристрій
| MFA + підтвердження пристрою.; MFA

=== 14.2.; Критичні ролі ===
<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">
API не використовує MFA так само, як людина.; | style="background:#c8e6c9;" | MFA + рольовий контроль.; |-
| user_id
| uuid
| користувач системи.; Політика
== 11.; Модель даних MFA ==
{| class="wikitable"
|-
| id
| uuid
| ID методу.; | style="background:#c8e6c9;" | Must have
|-
| Фінансові ролі
| MFA обов’язкова завжди.; | платформа вимагає налаштувати MFA.; {| class="wikitable"

</div>

NIST у Digital Identity Guidelines описує, що на рівні AAL2 автентифікація має виконуватись через багатофакторний автентифікатор або комбінацію двох однофакторних автентифікаторів.; * Внутрішні вимоги K2 ERP до ролей, доступів, MFA, журналювання та API-безпеки.; Чому потрібна MFA
|-
| style="background:#ef9a9a;" | Адміністратор ERP
| має змогу змінювати ролі, права, конфігурація, інтеграції.; |-
| Щось, чим користувач системи є собою
| Біометрія на пристрої
| застосовується для активації пристрою або passkey.; |-
| TOTP
| style="background:#ffcc80;" | Ні
| Краще за пароль, але код можна ввести на фішинговій сторінці.; №

<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">

* CISA: More than a Password.; Тип
!; користувач системи

!; Очікуваний результат
!; Роль

'''MFA fatigue''' — це коли зловмисник уже знає пароль і багато разів надсилає push-запити користувачу, сподіваючись, що той випадково натисне «Підтвердити».; Phishing-resistant?; | style="background:#c8e6c9;" | Must have
|}

{| class="wikitable"

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

<div style="border-left: 8px solid #1565c0; background: #e3f2fd; padding: 14px 18px; margin: 16px 0;">

=== Етап 2.; Політика MFA ===
== 13.; Впровадження MFA в K2 ERP ==
'''Правильне рішення для бізнесу:''' у K2 ERP потрібно впровадити MFA для критичних ролей, адміністраторів, бухгалтерії, фінансів, керівників, віддаленого доступу, API-адміністрування та всіх користувачів із доступом до чутливих даних.; | style="background:#ffcc80;" | Високий
|}

!; |}

!; Рівень
!; Для ERP потрібен другий фактор, а для критичних ролей — бажано phishing-resistant MFA: FIDO2, passkeys або інші криптографічно захищені методи.; !; |-
| AC-3
| користувач системи вводить неправильний код.; №
!; |-
| user_agent
| text
| Пристрій.; | style="background:#ef9a9a;" | Критично
|-
| style="background:#ef9a9a;" | Фінансовий директор
| Доступ до платежів, бюджетів, рахунків, управлінської звітності.; Критерій
ERP.; | платформа вимагає новий challenge.; |-
| TOTP
| Google Authenticator, Microsoft Authenticator, 1Password, Bitwarden
| style="background:#fff9c4;" | Добрий
| функціонує офлайн, коди змінюються кожні 30 секунд.; Очікуваний результат
!; * визначити обов’язкові ролі;
* визначити allowed MFA methods;
* заборонити слабкі методи для критичних ролей;
* визначити recovery-процедуру;
* визначити step-up MFA для критичних дій.; | платформа показує QR, приймає код і активує метод.; | style="background:#c8e6c9;" | Must have
|-
| Віддалений доступ
| MFA обов’язкова завжди.; Фактор

!; |-
| FIDO2 security key
| style="background:#c8e6c9;" | Так
| Криптографічно прив’язаний до справжнього домену.; Показник
{{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, контроль доступу
}}
|-
| 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;" | Добре
| Без дії
|}

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

</div>

* визначити всіх активних користувачів;
* визначити критичні ролі;
* знайти спільні логіни;
* знайти користувачів без входу понад 90 днів;
* знайти адміністраторів;
* знайти API-користувачів.; |-
| Щось, що користувач системи має
| Телефон, токен, security key, passkey
| Сильніший захист, бо зловмиснику потрібен фізичний або криптографічний фактор.; Для API потрібні інші контролі.; |-
| AC-9
| Адміністратор змінює роль користувача.; |}

{| class="wikitable"

!; :contentReference [oaicite:0]{index=0}
'''Червона зона:''' адміністратори, бухгалтерський обліковий облік, фінансовий блок або керівники входять у ERP тільки за паролем.; | style="background:#c8e6c9;" | Must have
|-
| Expiration date
| Token не повинен бути вічним.; |-
| AC-17
| є собою підозрілі MFA-запити.; |-
| user_id
| uuid
| користувач системи.;=== Етап 4.; Міграція користувачів ===
!; {| class="wikitable"
!; |-
| AC-7
| Фіндиректор входить із нового пристрою.; Значення
!; |-
| ip_address
| varchar
| IP.; Для звичайних користувачів — TOTP або push із number matching.; SMS використовувати лише як перехідний або резервний метод.; !; |-
| Зміна ролі користувача
| Ризик розширення доступу.; |-
| method_type
| varchar
| TOTP, SMS, EMAIL, PUSH, FIDO2, PASSKEY.; * NIST SP 800-63B-4: Authentication and Authenticator Management.; * CISA: Phishing-Resistant MFA Guidance.;[[Категорія:ERP]]
{{DISPLAYTITLE:MFA для ERP: багатофакторна автентифікація в K2 ERP}}
=== 14.1.; Базова MFA ===
|-
| AC-8
| користувач системи змінює банківські реквізити.; |-
| payload
| jsonb
| Технічні інформаційні дані без секретів.; | платформа вимагає MFA і логування.; Тип

!; Рекомендація
!; | style="background:#c8e6c9;" | Must have
|-
| Admin MFA
| MFA для створення, перегляду та відкликання token.; {| class="wikitable"
!; |-
| Push із number matching
| користувач системи вводить число з екрана входу
| style="background:#c8e6c9;" | Кращий
| Захищає від випадкового натискання «Approve».; | Він підсвічується помаранчевим.; :contentReference [oaicite:2]{index=2}
!; '''Зелена зона:''' у K2 ERP увімкнено MFA для критичних ролей, step-up MFA для небезпечних операцій, dashboard контролю, журнал подій, recovery-процедура та поступовий перехід на phishing-resistant MFA.; | Він бачить покриття MFA по ролях.; Очікуваний результат
<div style="border-left: 8px solid #2e7d32; background: #e8f5e9; padding: 14px 18px; margin: 16px 0;">
|-
| Адміністратори
| MFA обов’язкова завжди.; |-
| AC-2
| користувач системи входить із MFA.; №
== 8.; MFA для критичних операцій ==
|-
| AC-1
| користувач системи вмикає TOTP.; |-
| challenge_type
| varchar
| LOGIN, STEP_UP, RECOVERY, CRITICAL_ACTION.; Очікуваний результат

[[Категорія:Контроль доступу]]
<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">
Adaptive MFA вмикає додаткову перевірку за ризиковими умовами:
!; Критерій
</div>
Захист:
=== Етап 5.; Контроль ===
|-
| SMS
| style="background:#ef9a9a;" | Ні
| Код можна виманити.; характеристика

[[Категорія:Кібербезпека]]
!; Дія

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

== 5. Phishing-resistant MFA ==

* фінансові документи;
* банківські виписки;
* платежі;
* зарплати;
* персональні інформаційні дані;
* договори;
* реквізити контрагентів;
* ціни;
* знижки;
* залишки;
* виробництво;
* управлінська формування звітів;
* податкова відомості;
* інтеграції з банками, ПРРО, доставкою, маркетплейсами.; :contentReference [oaicite:1]{index=1}
!; | style="background:#ef9a9a;" | Критично
|-
| style="background:#ef9a9a;" | центральний бухгалтер
| Доступ до фінансів, податків, зарплат, документів.; Якщо зловмисник отримує пароль бухгалтера забезпечується через '''Критично істотно:''' пароль більше не можна вважати достатнім захистом; додатково реалізовано адміністратора, фінансового директора або API-користувача, він має змогу отримати доступ до фінансів, зарплат, договорів, складу, цін, банківських даних і управлінської звітності.;== 16.; Джерела ==

=== 7.2. Adaptive MFA ===

* recovery codes;
* резервний фактор;
* процедуру відновлення доступу;
* перевірку особи користувача;
* погодження адміністратором;
* журнал recovery-події;
* заборону відновлення доступу одним адміністратором для критичних ролей;
* тимчасовий доступ із коротким TTL;
* обов’язкове повторне конфігурація MFA після recovery.; Колір
|-
| Зміна банківських реквізитів
| Ризик підміни рахунку.;<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">
|-
| AC-11
| користувач системи втратив MFA-пристрій.; | Запускається recovery-процедура.; | style="background:#c8e6c9;" | MFA адміністратора.; Правило
'''Орієнтир:''' CISA прямо зазначає, що деякі типи MFA кращі за інші: phishing-resistant MFA є собою стандартом, до якого мають прагнути організації, але будь-яка MFA краще, ніж її відсутність.; | style="background:#c8e6c9;" | Must have
|-
| Зміна ролей
| Повторна MFA-перевірка.; Коментар

{| class="wikitable"

</div>
== 6. MFA fatigue / push bombing ==
== 15.; Висновок ==

!; |-
| Push без number matching
| style="background:#ffcc80;" | Ні
| є собою ризик MFA fatigue.; |-
| AC-10
| користувач системи запускає масовий експорт.; Критерій

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

<div style="border-left: 8px solid #2e7d32; background: #e8f5e9; padding: 14px 18px; margin: 16px 0;">

!; Критерій
!; API-контроль

{| class="wikitable"

!; Приклад
|-
| SMS-код
| Код у SMS
| style="background:#ffcc80;" | Базовий
| Краще, ніж без MFA, але не найкращий варіант.; !; | Він підсвічується червоним.; | Вони підсвічуються червоним і створюють alert.; Коментар

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

</div>
!; |}

== 4.; Типи MFA ==

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

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

'''MFA''' — це багатофакторна автентифікація.; |}

'''Управлінський результат:''' керівник повинен бачити, у кого MFA увімкнена, у кого вимкнена, які ролі входять без другого фактора, які користувачі мають застарілі методи MFA, які входи були підозрілими та які акаунти потрібно заблокувати.; |-
| method_id
| uuid
| Метод MFA.; | style="background:#c8e6c9;" | Must have
|-
| IP whitelist
| Дозволити доступ тільки з відомих IP.; | style="background:#c8e6c9;" | Must have
|-
| Новий IP / країна
| MFA challenge + alert.; |-
| Push-підтвердження
| Підтвердити в мобільному додатку
| style="background:#fff9c4;" | Добрий
| Потрібен захист від MFA fatigue.; |-
| created_at
| timestamp
| Дата створення.; |-
| AC-16
| є собою користувач системи тільки з SMS.; ERP — це не сайт із новинами і не проста CRM.; | платформа вимагає повторну MFA.; | style="background:#c8e6c9;" | MFA + погодження.; | style="background:#ef9a9a;" | Критично
|-
| 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%
| 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;" | Контроль
|}

=== 14.5. Dashboard ===

!; |-
| expires_at
| timestamp
| Строк дії.; Стан
|-
| Token scopes
| Обмежити права інтеграції.; |-
| ip_address
| varchar
| IP.; | Вхід заблоковано або примусово вимагається MFA.; |-
| Push із number matching
| style="background:#fff9c4;" | Частково краще
| Зменшує ризик випадкового підтвердження.; |-
| status
| varchar
| ACTIVE, PENDING, DISABLED, LOST.; №
=== 11.3. mfa_events ===
__TOC__
!; |}

== 10.; MFA для API та інтеграцій ==
=== Етап 1.; Аудит користувачів ===
{| class="wikitable"

!; Чому потрібна повторна MFA

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

!; Тип
!; | Подія логуються, користувач системи зобов’язаний налаштувати новий фактор.; |-
| Email code
| style="background:#ef9a9a;" | Ні
| Ризик компрометації пошти.; |}

</div>

!; | style="background:#c8e6c9;" | Must have
|}

=== 11.2. mfa_challenges ===

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

!; Вона вимагає від користувача підтвердити вхід більше ніж одним способом.; |-
| Масовий експорт даних
| Ризик витоку.; Коментар
Зазвичай фактори поділяються на:
'''Критично істотно:''' recovery-процедура не повинна бути слабшим місцем, ніж MFA.; |-
| user_agent
| text
| Браузер / пристрій.; Очікуваний результат
!; |-
| Біометрія без криптографії
| Face ID / Touch ID тільки для розблокування
| style="background:#fff9c4;" | Залежить від реалізації
| Має бути прив’язана до безпечного автентифікатора.; | style="background:#c8e6c9;" | Must have
|-
| Зміна реквізитів
| Повторна MFA-перевірка.; | style="background:#ffcc80;" | Високий
|-
| style="background:#ffcc80;" | Віддалений доступ
| Вхід поза офісною мережею має більший ризик.; !; | style="background:#c8e6c9;" | Must have
|-
| Idempotency key
| Захист від повторної обробки.; | платформа вимагає повторну MFA.; |-
| AC-6
| Бухгалтер без MFA намагається увійти.; характеристика

[[Категорія:MFA]]
=== 12.1.; KPI керівника / адміністратора ===
=== 12.2.; Проблемні користувачі ===

!; |}

!; Призначення
{| class="wikitable"

!; '''Ризик:''' якщо користувач системи отримує push-запит, який сам не ініціював, і натискає «Approve», MFA не захистить систему.; Рівень
=== Етап 3.; Технічне впровадження ===
|-
| id
| uuid
| ID події.; |-
| status
| varchar
| PENDING, PASSED, FAILED, EXPIRED.; |-
| user_id
| uuid
| користувач системи.; | style="background:#c8e6c9;" | Must have
|-
| Token rotation
| Регулярна заміна token.; характеристика
{| class="wikitable"
|-
| AC-5
| Адміністратор без MFA намагається увійти.; Якщо MFA можна обійти дзвінком одному адміністратору, це ризик.; |-
| Створення платежу
| Ризик фінансової втрати.; | style="background:#ef9a9a;" | Критично
|-
| style="background:#ffcc80;" | Менеджери з доступом до цін і знижок
| Можуть змінити комерційні умови.; |-
| is_primary
| boolean
| ключовий метод.; | Вхід дозволено тільки після другого фактора.; |-
| Passkey
| style="background:#c8e6c9;" | Так
| Сучасний phishing-resistant варіант.; MFA має бути безпечною, але не повинна блокувати бізнес-середовище назавжди.; |-
| AC-12
| Recovery виконано.;=== 7.1.; Базова політика ===
Не вся MFA однаково сильна.; |-
| AC-4
| Challenge прострочений.; |-
| Вимкнення інтеграції
| Ризик зупинки бізнес-процесу.; |-
| event_type
| varchar
| MFA_ENABLED, MFA_DISABLED, MFA_PASSED, MFA_FAILED, RECOVERY_USED.; |-
| created_at
| timestamp
| Дата створення.; |-
| AC-13
| Recovery для адміністратора.; операційна дія
== 12. Dashboard MFA ==

!; | style="background:#ffcc80;" | Високий
|-
| 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
| style="background:#c8e6c9;" | Дуже сильний
| Phishing-resistant MFA.; !; Критерій
{| class="wikitable"
|-
| id
| uuid
| ID challenge.;== 7.; Політики MFA для K2 ERP ==
</div>
== 9.; Recovery та резервні коди ==
{| class="wikitable"
|-
| Щось, що користувач системи знає
| Пароль, PIN
| Найслабший фактор, якщо застосовують, коли потрібно самостійно.; |}

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

=== 14.4. Recovery ===
'''Ризик без MFA:''' якщо пароль користувача ERP викрадено через phishing, malware, витік браузера, слабкий пароль або повторне використання пароля, зловмисник має змогу зайти в систему як легальний користувач системи.; Метод
[[Категорія:Інформаційна безпека]]

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