R: Створена сторінка: {{DISPLAYTITLE:2FA для ERP: двофакторна автентифікація в K2 ERP}} {{SEO |title=2FA для ERP |description=Стаття про 2FA для ERP-систем: що таке двофакторна автентифікація, чим 2FA відрізняється від MFA, де її вмикати в K2 ERP, які методи безпечніші, ризики SMS, TOTP, push, FIDO2, dashboard та Acceptance Criteria. |keywo...

2026-05-07T19:13:26Z

Створена сторінка: {{DISPLAYTITLE:2FA для ERP: двофакторна автентифікація в K2 ERP}} {{SEO |title=2FA для ERP |description=Стаття про 2FA для ERP-систем: що таке двофакторна автентифікація, чим 2FA відрізняється від MFA, де її вмикати в K2 ERP, які методи безпечніші, ризики SMS, TOTP, push, FIDO2, dashboard та Acceptance Criteria. |keywo...

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

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

{{SEO
|title=2FA для ERP
|description=Стаття про 2FA для ERP-систем: що таке двофакторна автентифікація, чим 2FA відрізняється від MFA, де її вмикати в K2 ERP, які методи безпечніші, ризики SMS, TOTP, push, FIDO2, dashboard та Acceptance Criteria.
|keywords=2FA, MFA, двофакторна автентифікація, K2 ERP, ERP security, кібербезпека ERP, TOTP, SMS, FIDO2, passkeys, OTP, контроль доступу
}}

<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">
'''Критично важливо:''' пароль сам по собі не є достатнім захистом для ERP. Якщо пароль бухгалтера, адміністратора, фінансового директора або менеджера буде викрадено, зловмисник може отримати доступ до фінансів, зарплат, договорів, клієнтів, складу, цін, банківських реквізитів і управлінської звітності.
</div>

<div style="border-left: 8px solid #2e7d32; background: #e8f5e9; padding: 14px 18px; margin: 16px 0;">
'''Правильне рішення:''' у K2 ERP потрібно впровадити 2FA як мінімальний обов'язковий рівень захисту для критичних ролей: адміністраторів, бухгалтерії, фінансів, керівників, HR, користувачів із доступом до банківських операцій і користувачів із віддаленим доступом.
</div>

<div style="border-left: 8px solid #1565c0; background: #e3f2fd; padding: 14px 18px; margin: 16px 0;">
'''Орієнтир:''' CISA зазначає, що phishing-resistant MFA є стандартом, до якого мають прагнути організації, але будь-яка MFA краще, ніж її відсутність. Для ERP це означає: 2FA потрібно впроваджувати негайно, а для критичних ролей поступово переходити на сильніші методи — FIDO2 або passkeys.
</div>

__TOC__

== 1. Що таке 2FA ==

'''2FA''' — це двофакторна автентифікація. Вона вимагає від користувача підтвердити вхід двома різними факторами.

Найпростіший приклад:

<pre>
1. Користувач вводить логін і пароль.
2. Система просить другий фактор: код із додатку, SMS, push або security key.
3. Тільки після другого фактора користувач входить у K2 ERP.
</pre>

{| class="wikitable"
! Фактор
! Приклад
! Коментар
|-
| Щось, що користувач знає
| Пароль або PIN
| Перший фактор.
|-
| Щось, що користувач має
| Телефон, додаток Authenticator, security key, passkey
| Другий фактор.
|-
| Щось, чим користувач є
| Біометрія на пристрої
| Може використовуватись для активації passkey або пристрою.
|}

NIST у Digital Identity Guidelines описує, що для AAL2 потрібна багатофакторна автентифікація або комбінація двох різних однофакторних автентифікаторів. Це фактично відповідає ідеї 2FA: одного пароля недостатньо.

== 2. 2FA vs MFA ==

2FA і MFA часто використовують як синоніми, але між ними є різниця.

{| class="wikitable"
! Термін
! Що означає
! Приклад
|-
| 2FA
| Рівно два фактори автентифікації.
| Пароль + TOTP-код.
|-
| MFA
| Два або більше факторів.
| Пароль + FIDO2 + додатковий step-up для критичної дії.
|}

<div style="border-left: 8px solid #f57c00; background: #fff3e0; padding: 14px 18px; margin: 16px 0;">
'''Важливо:''' 2FA — це мінімальний рівень захисту. Для критичних ролей у K2 ERP краще мислити ширше: MFA, adaptive MFA, step-up MFA і phishing-resistant MFA.
</div>

== 3. Чому 2FA критична для ERP ==

ERP — це центр управління компанією.

У K2 ERP або іншій ERP можуть бути:

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

<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">
'''Ризик без 2FA:''' викрадений пароль може відкрити доступ до ERP без додаткової перевірки. Для зловмисника це означає можливість діяти від імені реального працівника.
</div>

== 4. Де 2FA має бути обов’язковою ==

{| class="wikitable"
! Роль / зона
! Чому 2FA обов’язкова
! Рівень
|-
| style="background:#ef9a9a;" | Адміністратор K2 ERP
| Може змінювати права, ролі, інтеграції, налаштування.
| style="background:#ef9a9a;" | Критично
|-
| style="background:#ef9a9a;" | Головний бухгалтер
| Має доступ до фінансів, податків, зарплат.
| style="background:#ef9a9a;" | Критично
|-
| style="background:#ef9a9a;" | Фінансовий директор
| Має доступ до платежів, бюджетів, рахунків, звітів.
| style="background:#ef9a9a;" | Критично
|-
| style="background:#ef9a9a;" | Користувачі з банківськими операціями
| Можуть впливати на платежі або реквізити.
| style="background:#ef9a9a;" | Критично
|-
| style="background:#ffcc80;" | HR / зарплата
| Доступ до персональних і зарплатних даних.
| style="background:#ffcc80;" | Високий
|-
| style="background:#ffcc80;" | Менеджери з доступом до цін
| Можуть змінювати комерційні умови.
| style="background:#ffcc80;" | Високий
|-
| style="background:#ffcc80;" | Віддалений доступ
| Вхід поза офісом має підвищений ризик.
| style="background:#ffcc80;" | Високий
|-
| style="background:#ffcc80;" | Користувачі з експортом даних
| Можуть вивантажити клієнтів, ціни, договори, залишки.
| style="background:#ffcc80;" | Високий
|}

== 5. Методи 2FA ==

{| class="wikitable"
! Метод
! Приклад
! Рівень безпеки
! Коментар
|-
| SMS-код
| Код у SMS
| style="background:#ffcc80;" | Базовий
| Краще, ніж тільки пароль, але не найкращий варіант.
|-
| Email-код
| Код на email
| style="background:#ffcc80;" | Базовий
| Безпека залежить від пошти.
|-
| TOTP
| Google Authenticator, Microsoft Authenticator, 1Password, Bitwarden
| style="background:#fff9c4;" | Добрий
| Код генерується в додатку і змінюється кожні 30 секунд.
|-
| Push
| Підтвердження в мобільному додатку
| style="background:#fff9c4;" | Добрий
| Потрібен захист від випадкового підтвердження.
|-
| Push із number matching
| Користувач вводить число з екрана входу
| style="background:#c8e6c9;" | Кращий
| Зменшує ризик MFA fatigue.
|-
| FIDO2 security key
| YubiKey, Feitian, Titan Key
| style="background:#c8e6c9;" | Дуже сильний
| Phishing-resistant варіант.
|-
| Passkeys
| Ключ доступу на пристрої
| style="background:#c8e6c9;" | Дуже сильний
| Сучасний варіант без класичного пароля.
|}

== 6. Рекомендація для K2 ERP ==

{| class="wikitable"
! Роль
! Мінімальний метод
! Рекомендований метод
! Колір
|-
| Адміністратор
| TOTP
| FIDO2 / passkey
| style="background:#c8e6c9;" | Сильний захист
|-
| Головний бухгалтер
| TOTP
| FIDO2 / passkey
| style="background:#c8e6c9;" | Сильний захист
|-
| Фінансовий директор
| TOTP
| FIDO2 / passkey
| style="background:#c8e6c9;" | Сильний захист
|-
| HR / зарплата
| TOTP
| TOTP або FIDO2
| style="background:#c8e6c9;" | Обов'язково
|-
| Менеджер продажів
| TOTP або push
| TOTP
| style="background:#fff9c4;" | Бажано
|-
| Склад
| TOTP або SMS
| TOTP
| style="background:#fff9c4;" | Бажано
|-
| Тимчасовий користувач
| TOTP
| Короткий TTL + TOTP
| style="background:#ffcc80;" | Контроль
|}

<div style="border-left: 8px solid #2e7d32; background: #e8f5e9; padding: 14px 18px; margin: 16px 0;">
'''Правило для K2 ERP:''' SMS можна використовувати тільки як перехідний або резервний варіант. Для критичних ролей потрібні TOTP, FIDO2 або passkeys.
</div>

== 7. Ризики слабкої 2FA ==

=== 7.1. SMS-2FA ===

{| class="wikitable"
! Ризик
! Опис
! Рівень
|-
| Перехоплення SMS
| Код може бути скомпрометований через мобільні ризики або соціальну інженерію.
| style="background:#ffcc80;" | Високий
|-
| Залежність від оператора
| Користувач може не отримати код.
| style="background:#fff9c4;" | Середній
|-
| Незручність за кордоном
| SMS може не приходити в роумінгу.
| style="background:#fff9c4;" | Середній
|-
| Не phishing-resistant
| Код можна ввести на фальшивому сайті.
| style="background:#ef9a9a;" | Критично
|}

=== 7.2. Email-2FA ===

{| class="wikitable"
! Ризик
! Опис
! Рівень
|-
| Злам пошти
| Якщо пошту зламано, код також доступний зловмиснику.
| style="background:#ef9a9a;" | Критично
|-
| Затримки доставки
| Код може приходити із затримкою.
| style="background:#fff9c4;" | Середній
|-
| Не phishing-resistant
| Код можна виманити.
| style="background:#ef9a9a;" | Критично
|}

=== 7.3. Push-2FA без number matching ===

{| class="wikitable"
! Ризик
! Опис
! Рівень
|-
| MFA fatigue
| Користувач отримує багато push-запитів і випадково підтверджує.
| style="background:#ef9a9a;" | Критично
|-
| Випадкове підтвердження
| Користувач натискає approve, не читаючи.
| style="background:#ffcc80;" | Високий
|}

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

2FA має використовуватись не тільки при вході, але й перед небезпечними діями.

{| class="wikitable"
! Операція
! Чому потрібна повторна 2FA
! Рекомендація
|-
| Зміна банківських реквізитів
| Ризик підміни рахунку.
| style="background:#c8e6c9;" | 2FA + погодження.
|-
| Створення платежу
| Ризик фінансової втрати.
| style="background:#c8e6c9;" | 2FA + рольовий контроль.
|-
| Зміна ролей користувача
| Ризик несанкціонованого доступу.
| style="background:#c8e6c9;" | 2FA адміністратора.
|-
| Масовий експорт даних
| Ризик витоку.
| style="background:#c8e6c9;" | 2FA + журнал.
|-
| Видалення документа
| Ризик приховування операцій.
| style="background:#c8e6c9;" | 2FA + audit log.
|-
| Вимкнення інтеграції
| Ризик зупинки бізнес-процесу.
| style="background:#c8e6c9;" | 2FA + погодження.
|}

== 9. Політика 2FA для K2 ERP ==

=== 9.1. Обов’язкові правила ===

{| class="wikitable"
! Правило
! Опис
! Статус
|-
| 2FA для адміністраторів
| Без 2FA адміністратор не може увійти.
| style="background:#c8e6c9;" | Обов'язково
|-
| 2FA для бухгалтерії
| Доступ до фінансових і податкових даних тільки з 2FA.
| style="background:#c8e6c9;" | Обов'язково
|-
| 2FA для фінансів
| Платежі, бюджети, реквізити — тільки з 2FA.
| style="background:#c8e6c9;" | Обов'язково
|-
| 2FA для віддаленого доступу
| Вхід поза офісом тільки з 2FA.
| style="background:#c8e6c9;" | Обов'язково
|-
| 2FA для нового пристрою
| Новий пристрій потребує другого фактора.
| style="background:#c8e6c9;" | Обов'язково
|-
| 2FA для нової країни/IP
| Система має вимагати повторну перевірку.
| style="background:#c8e6c9;" | Обов'язково
|-
| Заборона спільних логінів
| 2FA неможливо нормально використовувати зі спільним акаунтом.
| style="background:#c8e6c9;" | Обов'язково
|}

=== 9.2. Рекомендовані правила ===

* вимагати 2FA для всіх користувачів;
* не дозволяти SMS для адміністраторів;
* не дозволяти email-код для фінансових ролей;
* вимагати FIDO2 / passkey для super admin;
* вимагати повторну 2FA для критичних дій;
* блокувати користувача після багатьох невдалих 2FA;
* логувати всі 2FA-події;
* показувати dashboard покриття 2FA.

== 10. Recovery 2FA ==

Користувач може втратити телефон, додаток або security key. Тому потрібен безпечний recovery-процес.

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

* резервні коди;
* резервний метод 2FA;
* заявку на відновлення доступу;
* перевірку особи;
* погодження адміністратором;
* журнал recovery-події;
* тимчасовий доступ з коротким TTL;
* обов’язкове повторне налаштування 2FA після recovery.

<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">
'''Критично важливо:''' recovery не повинен бути слабшим за саму 2FA. Якщо другий фактор можна обійти простим проханням у чаті, це небезпечна архітектура.
</div>

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

=== 11.1. two_factor_methods ===

{| class="wikitable"
! Поле
! Тип
! Опис
|-
| 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. two_factor_challenges ===

{| class="wikitable"
! Поле
! Тип
! Опис
|-
| id
| uuid
| ID challenge.
|-
| user_id
| uuid
| Користувач.
|-
| method_id
| uuid
| Метод 2FA.
|-
| 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. two_factor_events ===

{| class="wikitable"
! Поле
! Тип
! Опис
|-
| id
| uuid
| ID події.
|-
| user_id
| uuid
| Користувач.
|-
| event_type
| varchar
| 2FA_ENABLED, 2FA_DISABLED, 2FA_PASSED, 2FA_FAILED, RECOVERY_USED.
|-
| method_type
| varchar
| Тип 2FA.
|-
| ip_address
| varchar
| IP.
|-
| user_agent
| text
| Пристрій.
|-
| payload
| jsonb
| Технічні дані без секретів.
|-
| created_at
| timestamp
| Дата.
|}

== 12. Dashboard 2FA ==

=== 12.1. KPI адміністратора ===

{| class="wikitable"
! Показник
! Значення
! Стан
|-
| Користувачів із 2FA
| 86%
| style="background:#fff9c4;" | Потрібно довести до 100%
|-
| Адміністраторів із 2FA
| 100%
| style="background:#c8e6c9;" | Норма
|-
| Бухгалтерів із 2FA
| 92%
| style="background:#ffcc80;" | Потрібна дія
|-
| Фінансових ролей із 2FA
| 100%
| style="background:#c8e6c9;" | Норма
|-
| Користувачів тільки з SMS
| 18
| style="background:#ffcc80;" | Замінити на TOTP/FIDO2
|-
| Невдалих 2FA за день
| 12
| style="background:#ffcc80;" | Контроль
|-
| Підозрілих 2FA-запитів
| 3
| style="background:#ef9a9a;" | Критично
|-
| Recovery-подій за місяць
| 4
| style="background:#fff9c4;" | Контроль
|}

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

{| class="wikitable"
! Користувач
! Роль
! 2FA
! Ризик
! Дія
|-
| admin2
| Адміністратор
| style="background:#ef9a9a;" | Вимкнено
| style="background:#ef9a9a;" | Критично
| Заблокувати або увімкнути 2FA
|-
| 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;" | Добре
| Без дії
|}

== 13. Приклад процесу входу з 2FA ==

<pre>
1. Користувач відкриває K2 ERP.
2. Вводить логін і пароль.
3. Система перевіряє пароль.
4. Система визначає, чи потрібна 2FA.
5. Якщо потрібна — створює 2FA challenge.
6. Користувач вводить TOTP-код або підтверджує другим фактором.
7. Система перевіряє challenge.
8. Якщо все коректно — створює сесію.
9. Подія входу записується в журнал.
</pre>

== 14. Приклад Python-логіки ==

=== 14.1. Перевірка необхідності 2FA ===

<syntaxhighlight lang="python">
def is_2fa_required(user: "User", request_context: "RequestContext") -> bool:
if user.role in ["ADMIN", "CHIEF_ACCOUNTANT", "CFO", "HR_PAYROLL"]:
return True

if request_context.is_remote_access:
return True

if request_context.is_new_device:
return True

if request_context.is_high_risk_ip:
return True

return user.two_factor_required
</syntaxhighlight>

=== 14.2. Створення 2FA challenge ===

<syntaxhighlight lang="python">
def create_2fa_challenge(user_id: str, method_type: str, context: dict, db: "Session") -> "TwoFactorChallenge":
challenge = two_factor_challenge_repository.create(
db=db,
data={
"user_id": user_id,
"method_type": method_type,
"challenge_type": context.get("challenge_type", "LOGIN"),
"status": "PENDING",
"risk_score": context.get("risk_score", 0),
"ip_address": context.get("ip_address"),
"user_agent": context.get("user_agent"),
"expires_at": utc_now_plus_minutes(5),
},
)

audit_logger.log(
event_type="2FA_CHALLENGE_CREATED",
user_id=user_id,
payload={
"method_type": method_type,
"challenge_type": challenge.challenge_type,
},
)

db.commit()
return challenge
</syntaxhighlight>

=== 14.3. Перевірка TOTP-коду ===

<syntaxhighlight lang="python">
def verify_totp_challenge(challenge_id: str, code: str, db: "Session") -> bool:
challenge = two_factor_challenge_repository.get_by_id(db, challenge_id)

if challenge.status != "PENDING":
return False

if challenge.expires_at < utc_now():
challenge.status = "EXPIRED"
db.commit()
return False

method = two_factor_method_repository.get_active_totp_method(
db=db,
user_id=challenge.user_id,
)

is_valid = totp_service.verify(
secret=method.secret_encrypted,
code=code,
)

if is_valid:
challenge.status = "PASSED"
method.last_used_at = utc_now()
else:
challenge.status = "FAILED"

audit_logger.log(
event_type="2FA_PASSED" if is_valid else "2FA_FAILED",
user_id=challenge.user_id,
payload={"challenge_id": str(challenge.id)},
)

db.commit()
return is_valid
</syntaxhighlight>

== 15. Впровадження 2FA в K2 ERP ==

=== Етап 1. Аудит користувачів ===

* знайти всіх активних користувачів;
* знайти адміністраторів;
* знайти бухгалтерію;
* знайти фінансові ролі;
* знайти HR / зарплату;
* знайти користувачів із віддаленим доступом;
* знайти спільні логіни;
* знайти користувачів без входу понад 90 днів.

=== Етап 2. Політика 2FA ===

* визначити обов’язкові ролі;
* визначити дозволені методи;
* заборонити слабкі методи для критичних ролей;
* визначити recovery-процедуру;
* визначити step-up 2FA для критичних дій.

=== Етап 3. Технічна реалізація ===

* TOTP;
* SMS як резервний або перехідний варіант;
* FIDO2 / passkeys для критичних ролей;
* recovery codes;
* device trust;
* risk-based challenge;
* журнал 2FA;
* dashboard 2FA.

=== Етап 4. Запуск ===

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

=== Етап 5. Контроль ===

* щотижневий звіт;
* список користувачів без 2FA;
* блокування критичних ролей без 2FA;
* поступова відмова від SMS;
* перехід критичних ролей на FIDO2 / passkeys.

== 16. Acceptance Criteria ==

=== 16.1. Базова 2FA ===

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

=== 16.2. Критичні ролі ===

{| class="wikitable"
! №
! Критерій
! Очікуваний результат
|-
| AC-5
| Адміністратор без 2FA намагається увійти.
| Вхід заблоковано або примусово вимагається 2FA.
|-
| AC-6
| Бухгалтер без 2FA намагається увійти.
| Система вимагає налаштувати 2FA.
|-
| AC-7
| Фіндиректор входить із нового пристрою.
| Система вимагає 2FA і створює подію ризику.
|}

=== 16.3. Step-up 2FA ===

{| class="wikitable"
! №
! Критерій
! Очікуваний результат
|-
| AC-8
| Користувач змінює банківські реквізити.
| Система вимагає повторну 2FA.
|-
| AC-9
| Адміністратор змінює роль користувача.
| Система вимагає повторну 2FA.
|-
| AC-10
| Користувач запускає масовий експорт.
| Система вимагає 2FA і логування.
|}

=== 16.4. Recovery ===

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

=== 16.5. Dashboard ===

{| class="wikitable"
! №
! Критерій
! Очікуваний результат
|-
| AC-14
| Адміністратор відкриває 2FA dashboard.
| Він бачить покриття 2FA по ролях.
|-
| AC-15
| Є адміністратор без 2FA.
| Він підсвічується червоним.
|-
| AC-16
| Є користувач тільки з SMS.
| Він підсвічується помаранчевим.
|-
| AC-17
| Є підозрілі 2FA-запити.
| Вони підсвічуються червоним і створюють alert.
|}

== 17. Висновок ==

2FA — це мінімальний рівень захисту ERP від викрадених паролів.

<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">
'''Червона зона:''' адміністратори, бухгалтерія, фінанси, HR або керівники входять у K2 ERP тільки за паролем.
</div>

<div style="border-left: 8px solid #2e7d32; background: #e8f5e9; padding: 14px 18px; margin: 16px 0;">
'''Зелена зона:''' у K2 ERP увімкнено 2FA для критичних ролей, step-up 2FA для небезпечних операцій, dashboard контролю, журнал подій і поступовий перехід на FIDO2 / passkeys.
</div>

'''Головне правило:''' 2FA потрібно впроваджувати не колись, а одразу. Для ERP пароль без другого фактора — це незакритий ризик.

== 18. Джерела ==

* CISA: More than a Password.
* CISA: MFA Guidance.
* CISA: Phishing-Resistant MFA Guidance.
* NIST SP 800-63B: Digital Identity Guidelines.
* NIST SP 800-63B-4: Authentication and Authenticator Management.
* Внутрішні вимоги K2 ERP до ролей, доступів, 2FA, журналювання та API-безпеки.

== 19. Див. також ==

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

[[Категорія:ERP]]
[[Категорія:K2 ERP]]
[[Категорія:Кібербезпека]]
[[Категорія:2FA]]
[[Категорія:MFA]]
[[Категорія:Контроль доступу]]
[[Категорія:Інформаційна безпека]]

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