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

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

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

</div>

! | платформа вимагає повторну 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"

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

'''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 ==

[[Категорія:ERP]]

* CISA: More than a Password. |}

! ! {| class="wikitable"
=== Етап 3. Технічне впровадження ===
== 13. Впровадження MFA в K2 ERP ==

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

<div style="border-left: 8px solid #2e7d32; background: #e8f5e9; padding: 14px 18px; margin: 16px 0;">
</div>
NIST SP 800-63B пояснює, що phishing resistance потребує криптографічної автентифікації, а автентифікатори з ручним введенням коду, як приклад OTP, не вважаються phishing-resistant, бо код можна ввести на фальшивому сайті й передати зловмиснику. |-
| last_used_at
| timestamp
| Останнє використання. Приклад

! | платформа вимагає новий challenge.{{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, контроль доступу
}}

* TOTP;
* FIDO2 / passkeys;
* push або number matching;
* recovery codes;
* device trust;
* risk-based challenge;
* журнал MFA;
* dashboard. |-
| TOTP
| style="background:#ffcc80;" | Ні
| Краще за пароль, але код можна ввести на фішинговій сторінці. |}

</div>

== 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-запити. |}

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

[[Категорія:Контроль доступу]]
У ERP зберігаються:
! | style="background:#c8e6c9;" | Must have
|-
| Новий пристрій
| MFA + підтвердження пристрою. Приклад

{| class="wikitable"

* 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;" | провідний бухгалтер
| Доступ до фінансів, податків, зарплат, документів. |}

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

__TOC__
<div style="border-left: 8px solid #6a1b9a; background: #f3e5f5; padding: 14px 18px; margin: 16px 0;">
! |-
| AC-10
| користувач системи запускає масовий експорт. Чому потрібна MFA

! |-
| AC-12
| Recovery виконано. | style="background:#ffcc80;" | Високий
|-
| style="background:#ffcc80;" | HR / зарплата
| Доступ до персональних і зарплатних даних. Значення
=== Етап 5. Контроль ===
|-
| AC-1
| користувач системи вмикає TOTP. | Запускається recovery-процедура. FIDO2 / passkeys або TOTP як мінімум виступає ключовою рисою '''Рекомендовано для K2 ERP:''' для адміністраторів і фінансових ролей. користувач системи
Захист:
{| class="wikitable"
|-
| Щось, що користувач системи знає
| Пароль, PIN
| Найслабший фактор, якщо застосовують, коли потрібно самостійно. ! |-
| payload
| jsonb
| Технічні інформаційні дані без секретів. | style="background:#c8e6c9;" | MFA + погодження. |-
| Push без number matching
| style="background:#ffcc80;" | Ні
| виступає як ризик MFA fatigue. |-
| AC-9
| Адміністратор змінює роль користувача. ! | Вхід дозволено тільки після другого фактора. Очікуваний результат

</div>

* recovery codes;
* резервний фактор;
* процедуру відновлення доступу;
* перевірку особи користувача;
* погодження адміністратором;
* журнал recovery-події;
* заборону відновлення доступу одним адміністратором для критичних ролей;
* тимчасовий доступ із коротким TTL;
* обов’язкове повторне конфігурація MFA після recovery. | style="background:#ffcc80;" | Високий
|-
| style="background:#ffcc80;" | Віддалений доступ
| Вхід поза офісною мережею має більший ризик. | style="background:#c8e6c9;" | Must have
|-
| Фінансові ролі
| MFA обов’язкова завжди. |-
| risk_score
| integer
| Оцінка ризику.</div>
|-
| 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;" | Добре
| Без дії
|}

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

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

! ! Тип

! |-
| created_at
| timestamp
| Дата. Коментар

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

</div>
{| class="wikitable"
!=== 14.1. Базова MFA ===
|-
| id
| uuid
| ID методу. Критерій
{| class="wikitable"
|-
| id
| uuid
| ID challenge. * щотижневий звіт;
* список користувачів без MFA;
* блокування критичних ролей без MFA;
* регулярний перегляд методів;
* заміна SMS на сильніші методи. Рівень

* визначити всіх активних користувачів;
* визначити критичні ролі;
* знайти спільні логіни;
* знайти користувачів без входу понад 90 днів;
* знайти адміністраторів;
* знайти API-користувачів. Критерій
{| class="wikitable"
! {| class="wikitable"

! |-
| FIDO2 security key
| style="background:#c8e6c9;" | Так
| Криптографічно прив’язаний до справжнього домену. SEO-опис
|-
| Зміна банківських реквізитів
| Ризик підміни рахунку. | style="background:#ef9a9a;" | Критично
|-
| 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
| TOTP, SMS, EMAIL, PUSH, FIDO2, PASSKEY. |-
| AC-7
| Фіндиректор входить із нового пристрою. Для API потрібні інші контролі. Критерій
!== 3. Де MFA має бути обов’язковою ==

[[Категорія:Інформаційна безпека]]
! |-
| ip_address
| varchar
| IP. | style="background:#c8e6c9;" | Must have
|-
| Token rotation
| Регулярна заміна token. ! |}

'''Критично критично:''' recovery-процедура не повинна бути слабшим місцем, ніж MFA.<div style="border-left: 8px solid #2e7d32; background: #e8f5e9; padding: 14px 18px; margin: 16px 0;">
! |-
| Щось, чим користувач системи виступає як
| Біометрія на пристрої
| застосовується для для активації пристрою або passkey. |-
| AC-3
| користувач системи вводить неправильний код. Тип
<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">
! | платформа вимагає повторну MFA. Рівень захисту
== 16. Джерела ==
! | style="background:#c8e6c9;" | MFA + audit log. Роль / зона
! |-
| Push із number matching
| style="background:#fff9c4;" | Частково краще
| Зменшує ризик випадкового підтвердження. | style="background:#c8e6c9;" | MFA адміністратора. Phishing-resistant? | Він підсвічується червоним. |-
| created_at
| timestamp
| Дата створення. | Він бачить покриття MFA по ролях. Рекомендація

! Правило
! №
== 1. Що таке MFA ==
MFA має бути безпечною, але не повинна блокувати бізнес-середовище назавжди. Метод

! Якщо MFA можна обійти дзвінком одному адміністратору, це ризик. | style="background:#c8e6c9;" | MFA + погодження. | style="background:#c8e6c9;" | MFA + журнал.=== 12.2. Проблемні користувачі ===
|-
| Token scopes
| Обмежити права інтеграції. операційна дія

== 17. Див. так само ==

{| class="wikitable"

=== Етап 4. Міграція користувачів ===
! | Challenge стає FAILED, спроба логуються. SEO-опис
=== 11.3. mfa_events ===
'''Ризик без MFA:''' якщо пароль користувача ERP викрадено через phishing, malware, витік браузера, слабкий пароль або повторне використання пароля, зловмисник здатна зайти в систему як легальний користувач системи. |}

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

! |}

! | style="background:#ffcc80;" | Високий
|-
| style="background:#ffcc80;" | API-адміністрування
| Компрометація API здатна вплинути на інтеграції. SMS використовувати лише як перехідний або резервний метод. |-
| user_agent
| text
| Браузер / пристрій. Тип MFA

! |-
| Масовий експорт даних
| Ризик витоку. |-
| Створення платежу
| Ризик фінансової втрати. | платформа вимагає MFA і логування. Якщо зловмисник отримує пароль бухгалтера забезпечується через '''Критично критично:''' пароль більше не можна вважати достатнім захистом; так само реалізовано адміністратора, фінансового директора або API-користувача, він здатна отримати доступ до фінансів, зарплат, договорів, складу, цін, банківських даних і управлінської звітності. | style="background:#ef9a9a;" | Критично
|-
| style="background:#ef9a9a;" | Користувачі з банківськими операціями
| Можуть впливати на платежі або реквізити. | style="background:#c8e6c9;" | Must have
|-
| бухгалтерський обліковий облік
| MFA обов’язкова завжди. Очікуваний результат
ERP. |-
| Видалення або скасування документа
| Ризик приховування операцій. ERP керує бізнесом. :contentReference [oaicite:0]{index=0}

! №

! |-
| created_at
| timestamp
| Дата створення. Дія

{| class="wikitable"
Потрібно передбачити:
=== 7.2. Adaptive MFA ===
=== Етап 1. Аудит користувачів ===
|-
| AC-5
| Адміністратор без MFA намагається увійти. Показник

! | Вхід заблоковано або примусово вимагається MFA. |-
| Зміна ролі користувача
| Ризик розширення доступу. ! Коментар
=== 11.2. mfa_challenges ===
== 5. Phishing-resistant MFA ==
|-
| Адміністратори
| MFA обов’язкова завжди. |-
| challenge_type
| varchar
| LOGIN, STEP_UP, RECOVERY, CRITICAL_ACTION. | style="background:#c8e6c9;" | Must have
|-
| Signed webhooks
| Захист від підроблених callback. |-
| Push із number matching
| користувач системи вводить число з екрана входу
| style="background:#c8e6c9;" | Кращий
| Захищає від випадкового натискання «Approve». Вона вимагає від користувача підтвердити вхід більше ніж одним способом. Політика
! Чому потрібна повторна MFA

!=== 11.1. mfa_methods ===

!<div style="border-left: 8px solid #2e7d32; background: #e8f5e9; padding: 14px 18px; margin: 16px 0;">
|-
| SMS
| style="background:#ef9a9a;" | Ні
| Код можна виманити. |-
| Passkeys
| Ключ доступу на пристрої
| style="background:#c8e6c9;" | Дуже сильний
| Сучасний phishing-resistant підхід. Тип
</div>

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

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

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

=== Етап 2. Політика MFA ===
== 15. Висновок ==
MFA потрібна не тільки на вході, а й перед окремими діями.== 7. Політики MFA для K2 ERP ==
|-
| Користувачів із 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;" | Контроль
|}

{| class="wikitable"

{| class="wikitable"
! API-контроль
! Для звичайних користувачів — TOTP або push із number matching. |}

'''Орієнтир:''' CISA прямо зазначає, що деякі типи MFA кращі за інші: phishing-resistant MFA виступає як стандартом, до якого мають прагнути організації, але будь-яка MFA краще, ніж її відсутність. Очікуваний результат
{| class="wikitable"
=== 14.4. Recovery ===
'''Ризик:''' якщо користувач системи отримує push-запит, який сам не ініціював, і натискає «Approve», MFA не захистить систему. |-
| ip_address
| varchar
| IP. |-
| Email-код
| Код на email
| style="background:#ffcc80;" | Базовий
| Залежить від безпеки поштової скриньки. №

! |-
| AC-4
| Challenge прострочений. Критерій
== 4. Типи MFA ==
[[Категорія:MFA]]
|-
| id
| uuid
| ID події. | style="background:#ef9a9a;" | Критично
|-
| style="background:#ffcc80;" | Менеджери з доступом до цін і знижок
| Можуть змінити комерційні умови. Для ERP потрібен другий фактор, а для критичних ролей — бажано phishing-resistant MFA: FIDO2, passkeys або інші криптографічно захищені методи. |-
| method_type
| varchar
| Тип MFA. |-
| Push-підтвердження
| Підтвердити в мобільному додатку
| style="background:#fff9c4;" | Добрий
| Потрібен захист від MFA fatigue. * CISA: Phishing-Resistant MFA Guidance. |-
| AC-6
| Бухгалтер без MFA намагається увійти. MFA
! SEO-опис

{| class="wikitable"
! | Подія логуються, користувач системи зобов’язаний налаштувати новий фактор. | style="background:#c8e6c9;" | Must have
|}

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

</div>

* новий пристрій;
* новий браузер;
* нова країна;
* незвичний час входу;
* багато невдалих спроб;
* спроба експорту даних;
* зміна критичних реквізитів;
* зміна ролей;
* доступ до зарплат;
* доступ до банківських операцій. :contentReference [oaicite:2]{index=2}
<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">
|-
| style="background:#ef9a9a;" | Адміністратор ERP
| здатна змінювати ролі, права, конфігурація, інтеграції. |}

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

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

! |-
| Вимкнення інтеграції
| Ризик зупинки бізнес-процесу. | style="background:#c8e6c9;" | Must have
|-
| Зміна реквізитів
| Повторна MFA-перевірка. |-
| TOTP
| Google Authenticator, Microsoft Authenticator, 1Password, Bitwarden
| style="background:#fff9c4;" | Добрий
| функціонує офлайн, коди змінюються кожні 30 секунд. Стан

! |-
| expires_at
| timestamp
| Строк дії. |-
| AC-15
| виступає як адміністратор без MFA. |}

MFA — це один із найважливіших і найшвидших способів зменшити ризик злому ERP.[[Категорія:K2 ERP]]
! |-
| AC-2
| користувач системи входить із MFA. |-
| event_type
| varchar
| MFA_ENABLED, MFA_DISABLED, MFA_PASSED, MFA_FAILED, RECOVERY_USED. |-
| AC-13
| Recovery для адміністратора. Колір
! |-
| Щось, що користувач системи має
| Телефон, токен, security key, passkey
| Сильніший захист, бо зловмиснику потрібен фізичний або криптографічний фактор. Фактор

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

[[Категорія:Кібербезпека]]
</div>
'''Зелена зона:''' у K2 ERP увімкнено MFA для критичних ролей, step-up MFA для небезпечних операцій, dashboard контролю, журнал подій, recovery-процедура та поступовий перехід на phishing-resistant MFA. |-
| Passkey
| style="background:#c8e6c9;" | Так
| Сучасний phishing-resistant варіант. | платформа вимагає налаштувати MFA. |-
| is_primary
| boolean
| базовий метод. | платформа вимагає MFA і створює подію ризику. * NIST SP 800-63B-4: Authentication and Authenticator Management. :contentReference [oaicite:1]{index=1}
|-
| AC-11
| користувач системи втратив MFA-пристрій. Ризик
{| class="wikitable"
'''Головне правило:''' пароль — це лише перший бар’єр. * NIST SP 800-63B: Digital Identity Guidelines. |}

! |-
| user_agent
| text
| Пристрій. Призначення
</div>
'''Червона зона:''' адміністратори, бухгалтерський обліковий облік, фінансовий блок або керівники входять у ERP тільки за паролем.

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