2FA

3. |-

AC-15

виступає як адміністратор без 2FA.

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

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

5. Методи 2FA

AC-1

користувач системи вмикає TOTP. ! Фактор

Щось, що користувач системи знає

Пароль або PIN

Перший фактор. )

def is_2fa_required(user: "User", request_context: "RequestContext") -> bool:

Тип

if challenge.status != "PENDING":

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

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

TOTP;
SMS як резервний або перехідний варіант;
FIDO2 / passkeys для критичних ролей;
recovery codes;
device trust;
risk-based challenge;
журнал 2FA;
dashboard 2FA. Тільки після другого фактора користувач системи входить у K2 ERP. |-

created_at

timestamp

Вхід заблоковано або примусово вимагається 2FA. №

SMS-код

Код у SMS

Базовий

Краще, ніж тільки пароль, але не найкращий варіант. 6. ! * NIST SP 800-63B: Digital Identity Guidelines. Рекомендований метод Зелена зона: у K2 ERP увімкнено 2FA для критичних ролей, step-up 2FA для небезпечних операцій, dashboard контролю, журнал подій і поступовий перехід на FIDO2 / passkeys. ! №

{| class="wikitable"
<syntaxhighlight lang="python">
== 15. Впровадження 2FA в K2 ERP ==
 data={
|-
| id
| uuid
| ID методу. Поле
|-
| AC-11
| користувач системи втратив 2FA-пристрій. Для критичних ролей потрібні TOTP, FIDO2 або passkeys. Очікуваний результат
! | платформа вимагає новий challenge. | Подія логуються, користувач системи зобов’язаний налаштувати новий фактор. ! |}

 "challenge_type": context.get("challenge_type", "LOGIN"),

'''критично:''' 2FA — це мінімальний рівень захисту. | style="background:#c8e6c9;" | Обов'язково
|}

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

* вимагати 2FA для всіх користувачів;
* не дозволяти SMS для адміністраторів;
* не дозволяти email-код для фінансових ролей;
* вимагати FIDO2 / passkey для super admin;
* вимагати повторну 2FA для критичних дій;
* блокувати користувача після багатьох невдалих 2FA;
* логувати всі 2FA-події;
* показувати dashboard покриття 2FA. | style="background:#c8e6c9;" | 2FA адміністратора. |-
| Видалення документа
| Ризик приховування операцій. Рівень

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

! | платформа вимагає 2FA і створює подію ризику. №
! Для критичних ролей у K2 ERP краще мислити ширше: MFA, adaptive MFA, step-up MFA і phishing-resistant MFA. |-
| Зміна ролей користувача
| Ризик несанкціонованого доступу. ! | Пароль + FIDO2 + додатковий step-up для критичної дії. | Challenge стає FAILED, спроба логуються. Приклад
<div style="border-left: 8px solid #f57c00; background: #fff3e0; padding: 14px 18px; margin: 16px 0;">
! |}

! |-
| FIDO2 security key
| YubiKey, Feitian, Titan Key
| style="background:#c8e6c9;" | Дуже сильний
| Phishing-resistant варіант. '''2FA''' — це двофакторна автентифікація. |-
| method_type
| varchar
| TOTP, SMS, EMAIL, PUSH, FIDO2, PASSKEY. |}

 return True

{| class="wikitable"

=== 7.3. Push-2FA без number matching ===
== 1. Що таке 2FA ==
=== 7.1. SMS-2FA ===

{| class="wikitable"
<div style="border-left: 8px solid #2e7d32; background: #e8f5e9; padding: 14px 18px; margin: 16px 0;">
== 2. 2FA vs MFA ==

 "challenge_type": challenge.challenge_type,

 "expires_at": utc_now_plus_minutes(5),

* CISA: More than a Password. користувач системи
=== 12.1. KPI адміністратора ===
=== 16.4. Recovery ===
! Роль

7. |-
| AC-3
| користувач системи вводить неправильний код. !</div>

* визначити обов’язкові ролі;
* визначити дозволені методи;
* заборонити слабкі методи для критичних ролей;
* визначити recovery-процедуру;
* визначити step-up 2FA для критичних дій. SEO-опис
! | style="background:#ffcc80;" | Високий
|-
| style="background:#ffcc80;" | Менеджери з доступом до цін
| Можуть змінювати комерційні умови. |}

<pre>

! | style="background:#c8e6c9;" | 2FA + журнал. | Він підсвічується помаранчевим. |-
| expires_at
| timestamp
| Строк дії. SEO-опис
=== 16.2. Критичні ролі ===
! | style="background:#ffcc80;" | Високий
|}

{| class="wikitable"

! Тип
</div>

},


 payload={
{| class="wikitable"

=== Етап 1. Аудит користувачів ===
== 9. Політика 2FA для K2 ERP ==

2FA і MFA часто використовують як синоніми, але між ними виступає як різниця. | style="background:#c8e6c9;" | Обов'язково
|-
| 2FA для нової країни/IP
| платформа має вимагати повторну перевірку. * CISA: Phishing-Resistant MFA Guidance. Вона вимагає від користувача підтвердити вхід двома різними факторами. Для ERP це означає: 2FA потрібно впроваджувати негайно, а для критичних ролей поступово переходити на сильніші методи. |-
| status
| varchar
| ACTIVE, PENDING, DISABLED, LOST. * спочатку адміністратори;
* потім бухгалтерський обліковий облік;
* потім фінансовий блок;
* потім керівники;
* потім HR;
* потім усі інші користувачі.== 14. Приклад Python-логіки ==
{| class="wikitable"
5. 4. if request_context.is_remote_access:

 challenge = two_factor_challenge_repository.get_by_id(db, challenge_id)

! |-
| MFA
| Два або більше факторів. |-
| AC-10
| користувач системи запускає масовий експорт. Тип

! user_id=user_id,

=== 16.5. Dashboard ===

[[Категорія:Контроль доступу]]
! Рівень
 return user.two_factor_required
! | Він бачить покриття 2FA по ролях. Для зловмисника це означає можливість діяти від імені реального працівника. користувач системи вводить логін і пароль. | style="background:#ef9a9a;" | Критично
|}

{| class="wikitable"

 return challenge
! Критерій

'''Головне правило:''' 2FA потрібно впроваджувати не колись, а одразу. Правило
! |-
| ip_address
| varchar
| IP. | style="background:#c8e6c9;" | Обов'язково
|-
| Заборона спільних логінів
| 2FA неможливо нормально використовувати зі спільним акаунтом. 2FA
|-
| id
| uuid
| ID події. Поле
! |-
| method_id
| uuid
| Метод 2FA. |-
| last_used_at
| timestamp
| Останнє використання. SEO-опис

 "method_type": method_type,
[[Категорія:MFA]]
<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">

Якщо пароль бухгалтера забезпечується через '''Критично критично:''' пароль сам по собі не виступає як достатнім захистом; так само реалізовано адміністратора, фінансового директора або менеджера буде викрадено, зловмисник здатна отримати доступ до фінансів, зарплат, договорів, клієнтів, складу, цін, банківських реквізитів і управлінської звітності. ! |}

'''Правильне рішення для бізнесу:''' у K2 ERP потрібно впровадити 2FA як мінімальний обов'язковий рівень захисту для критичних ролей: адміністраторів, бухгалтерії, фінансів, керівників, HR, користувачів із доступом до банківських операцій і користувачів із віддаленим доступом. Критерій

! |-
| payload
| jsonb
| Технічні інформаційні дані без секретів. | платформа вимагає 2FA і логування. SEO-опис

[[Категорія:Інформаційна безпека]]
 "method_type": method_type,
{| class="wikitable"
! Приклад
! | style="background:#ffcc80;" | Високий
|-
| style="background:#ffcc80;" | Користувачі з експортом даних
| Можуть вивантажити клієнтів, ціни, договори, залишки. | style="background:#c8e6c9;" | 2FA + рольовий контроль. |-
| risk_score
| integer
| Оцінка ризику. Подія входу записується в журнал. |-
| status
| varchar
| PENDING, PASSED, FAILED, EXPIRED. 2FA має використовуватись не тільки при вході, але й перед небезпечними діями. ! Рівень

! Чому 2FA обов’язкова
{| class="wikitable"
! Якщо все коректно — створює сесію. | style="background:#fff9c4;" | Середній
|-
| Не phishing-resistant
| Код можна ввести на фальшивому сайті. | style="background:#ef9a9a;" | Критично
|-
| style="background:#ef9a9a;" | провідний бухгалтер
| Має доступ до фінансів, податків, зарплат. Для ERP пароль без другого фактора — це незакритий ризик. ! операційна дія
|-
| AC-8
| користувач системи змінює банківські реквізити. * Внутрішні вимоги K2 ERP до ролей, доступів, 2FA, журналювання та API-безпеки. | Вхід дозволено тільки після другого фактора. |-
| user_id
| uuid
| користувач системи. |-
| Масовий експорт даних
| Ризик витоку. | style="background:#c8e6c9;" | Обов'язково
|-
| 2FA для фінансів
| Платежі, бюджети, реквізити — тільки з 2FA. користувач системи відкриває K2 ERP. Ризик

* резервні коди;
* резервний метод 2FA;
* заявку на відновлення доступу;
* перевірку особи;
* погодження адміністратором;
* журнал recovery-події;
* тимчасовий доступ з коротким TTL;
* обов’язкове повторне конфігурація 2FA після recovery. ERP. SEO-опис
== 6. Рекомендація для K2 ERP ==
|-
| AC-5
| Адміністратор без 2FA намагається увійти. Коментар
 "risk_score": context.get("risk_score", 0),
3. |-
| TOTP
| Google Authenticator, Microsoft Authenticator, 1Password, Bitwarden
| style="background:#fff9c4;" | Добрий
| Код генерується в додатку і змінюється кожні 30 секунд. Коментар

=== Етап 2. Політика 2FA ===
[[Категорія:Кібербезпека]]
!<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">
NIST у Digital Identity Guidelines описує, що для AAL2 потрібна багатофакторна автентифікація або комбінація двох різних однофакторних автентифікаторів. користувач системи вводить TOTP-код або підтверджує другим фактором. | style="background:#fff9c4;" | Середній
|-
| Незручність за кордоном
| SMS здатна не приходити в роумінгу. |-
| Email-код
| Код на email
| style="background:#ffcc80;" | Базовий
| Безпека залежить від пошти. |-
| Passkeys
| Ключ доступу на пристрої
| style="background:#c8e6c9;" | Дуже сильний
| Сучасний варіант без класичного пароля. |-
| event_type
| varchar
| 2FA_ENABLED, 2FA_DISABLED, 2FA_PASSED, 2FA_FAILED, RECOVERY_USED. | style="background:#ffcc80;" | Високий
|}

! |}

 db=db,

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

! |-
| AC-13
| Recovery для адміністратора. |-
| Push із number matching
| користувач системи вводить число з екрана входу
| style="background:#c8e6c9;" | Кращий
| Зменшує ризик MFA fatigue. |-
| user_id
| uuid
| користувач системи. | style="background:#ef9a9a;" | Критично
|-
| style="background:#ef9a9a;" | Користувачі з банківськими операціями
| Можуть впливати на платежі або реквізити. платформа просить другий фактор: код із додатку, SMS, push або security key. | style="background:#c8e6c9;" | 2FA + погодження. Показник
[[Категорія:2FA]]
== 13. Приклад процесу входу з 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;" | Добре
| Без дії
|}

!</syntaxhighlight>

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

! '''Правило для K2 ERP:''' SMS можна використовувати тільки як перехідний або резервний варіант. | style="background:#ef9a9a;" | Критично
|-
| style="background:#ffcc80;" | HR / зарплата
| Доступ до персональних і зарплатних даних. платформа перевіряє challenge. Роль / зона
|-
| Адміністратор
| 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;" | Контроль
|}

! Рекомендація
[[Категорія:ERP]]
=== 16.3. Step-up 2FA ===
== 18. Джерела ==
|-
| Злам пошти
| Якщо пошту зламано, код так само доступний зловмиснику. |}

{| class="wikitable"

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

{| class="wikitable"
! Дія

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

! |-
| user_id
| uuid
| користувач системи. "user_id": user_id,

* знайти всіх активних користувачів;
* знайти адміністраторів;
* знайти бухгалтерію;
* знайти фінансові ролі;
* знайти HR / зарплату;
* знайти користувачів із віддаленим доступом;
* знайти спільні логіни;
* знайти користувачів без входу понад 90 днів. Поле
</div>
<div style="border-left: 8px solid #1565c0; background: #e3f2fd; padding: 14px 18px; margin: 16px 0;">
 return True
! |-
| Вимкнення інтеграції
| Ризик зупинки бізнес-процесу. |}

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

 },
! №
=== 11.3. two_factor_events ===
 event_type="2FA_CHALLENGE_CREATED",

== 8. 2FA для критичних операцій ==
== 3. Чому 2FA критична для ERP ==
=== 11.2. two_factor_challenges ===
! |-
| AC-16
| виступає як користувач системи тільки з SMS. Статус
|-
| style="background:#ef9a9a;" | Адміністратор K2 ERP
| здатна змінювати права, ролі, інтеграції, конфігурація. |-
| method_type
| varchar
| Тип 2FA. |-
| AC-6
| Бухгалтер без 2FA намагається увійти. | style="background:#ef9a9a;" | Критично
|-
| Затримки доставки
| Код здатна приходити із затримкою. Вводить логін і пароль. |-
| ip_address
| varchar
| IP.=== 14.2. Створення 2FA challenge ===
{| class="wikitable"

 "user_agent": context.get("user_agent"),

FIDO2 або passkeys виступає ключовою рисою '''Орієнтир:''' CISA зазначає, що phishing-resistant MFA виступає як стандартом, до якого мають прагнути організації, але будь-яка MFA краще, ніж її відсутність. Роль
{| class="wikitable"
2. |-
| challenge_type
| varchar
| LOGIN, STEP_UP, RECOVERY, CRITICAL_ACTION. Ризик
! Критерій
 )
<syntaxhighlight lang="python">
== 17. Висновок ==
|-
| Зміна банківських реквізитів
| Ризик підміни рахунку. |-
| AC-2
| користувач системи входить із 2FA. |-
| AC-9
| Адміністратор змінює роль користувача. Окремо варто відзначити ПРРО, маркетплейсами, службами доставки і електронним підписом. |-
| user_agent
| text
| Браузер / пристрій. | платформа вимагає повторну 2FA. |-
| AC-17
| виступає як підозрілі 2FA-запити. платформа перевіряє пароль. ! |-
| is_primary
| boolean
| базовий метод. SEO-опис
ERP — це центр керування компанією. | style="background:#c8e6c9;" | 2FA + audit log. |-
| Push
| Підтвердження в мобільному додатку
| style="background:#fff9c4;" | Добрий
| Потрібен захист від випадкового підтвердження. * NIST SP 800-63B-4: Authentication and Authenticator Management. | style="background:#ef9a9a;" | Критично
|}

'''Червона зона:''' адміністратори, бухгалтерський обліковий облік, фінансовий блок, HR або керівники входять у K2 ERP тільки за паролем. | платформа вимагає налаштувати 2FA. |-
| created_at
| timestamp
| Дата створення. |-
| Щось, чим користувач системи виступає як
| Біометрія на пристрої
| здатна використовуватись для активації passkey або пристрою. | style="background:#c8e6c9;" | Обов'язково
|-
| 2FA для віддаленого доступу
| Вхід поза офісом тільки з 2FA. Термін

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

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

 if user.role in ["ADMIN", "CHIEF_ACCOUNTANT", "CFO", "HR_PAYROLL"]:

* фінансові документи;
* рахунки;
* банківські виписки;
* платежі;
* зарплати;
* кадрові інформаційні дані;
* податкові документи;
* договори;
* клієнти;
* постачальники;
* ціни;
* знижки;
* залишки;
* виробничі рецептури;
* управлінська формування звітів;
* інтеграції з банками. Рівень
{| class="wikitable"
1. return True
|-
| 2FA для адміністраторів
| Без 2FA адміністратор не здатна увійти. | платформа показує QR, приймає код і активує метод. №
! Чому потрібна повторна 2FA
2. | style="background:#ef9a9a;" | Критично
|-
| Випадкове підтвердження
| користувач системи натискає approve, не читаючи. |-
| Створення платежу
| Ризик фінансової втрати.

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

if request_context.is_new_device:

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

"status": "PENDING",

2FA	Вони підсвічуються червоним і створюють alert. \| Він підсвічується червоним. ! Якщо потрібна — створює 2FA challenge. \| Пароль + TOTP-код. \| Потрібне додаткове погодження. \|-	user_agent	text	Пристрій. Ризик	Рівень безпеки 10. Recovery 2FA
Перехоплення SMS	платформа вимагає повторну 2FA. * CISA: MFA Guidance. Стан Ризик без 2FA: викрадений пароль здатна відкрити доступ до ERP без додаткової перевірки. \| style="background:#ef9a9a;" \| Критично
Фінансовий директор	Має доступ до платежів, бюджетів, рахунків, звітів. Колір	-	AC-14	Адміністратор відкриває 2FA dashboard. Критерій	}	Мінімальний метод Потрібно передбачити:	-	Щось, що користувач системи має	Телефон, додаток Authenticator, security key, passkey	Другий фактор. Що означає	style="background:#c8e6c9;" \| 2FA + погодження. SEO-опис
id	uuid	-	MFA fatigue	користувач системи отримує багато push-запитів і випадково підтверджує. Значення 11. Модель даних 2FA	Ризик def create_2fa_challenge(user_id: str, method_type: str, context: dict, db: "Session") -> "TwoFactorChallenge":
Користувачів із 2FA	86%	Потрібно довести до 100%
Адміністраторів із 2FA	100%	Норма
Бухгалтерів із 2FA	92%	Потрібна дія
Фінансових ролей із 2FA	100%	Норма
Користувачів тільки з SMS	18	Замінити на TOTP/FIDO2
Невдалих 2FA за день	12	Контроль
Підозрілих 2FA-запитів	3	Критично
Recovery-подій за місяць	4	Контроль

style="background:#ffcc80;" | Високий

Віддалений доступ

}

11.1. two_factor_methods

challenge = two_factor_challenge_repository.create(

-

AC-12

Recovery виконано. Очікуваний результат

Критично критично: recovery не повинен бути слабшим за саму 2FA. |}

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

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

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> У K2 ERP або іншій ERP можуть бути:

if request_context.is_high_risk_ip:

16. Acceptance Criteria

"ip_address": context.get("ip_address"),

return True

користувач системи здатна втратити телефон, додаток або security key. ! |}

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

-	AC-4	Challenge прострочений. ! Тому потрібен безпечний recovery-процес. ! Це фактично відповідає ідеї 2FA: одного пароля недостатньо. Приклад audit_logger.log( 12. Dashboard 2FA 1. ! \|-	created_at	timestamp	style="background:#c8e6c9;" \| Обов'язково
2FA для бухгалтерії	style="background:#fff9c4;" \| Середній
Не phishing-resistant	style="background:#ffcc80;" \| Високий
Залежність від оператора	користувач системи здатна не отримати код. Критерій db.commit()	Запускається recovery-процедура. Якщо другий фактор можна обійти простим проханням у чаті, це небезпечна технічна архітектура. \| style="background:#c8e6c9;" \| Обов'язково
2FA для нового пристрою	-	AC-7	Фіндиректор входить із нового пристрою. 2FA — це мінімальний рівень захисту ERP від викрадених паролів. Очікуваний результат 16.1. Базова 2FA def verify_totp_challenge(challenge_id: str, code: str, db: "Session") -> bool: SEO title: 2FA для ERP SEO keywords: 2FA, MFA, двофакторна автентифікація, K2 ERP, ERP security, кібербезпека ERP, TOTP, SMS, FIDO2, passkeys, OTP, контроль доступу </noinclude> {{SEO Шаблон для службового SEO-опису сторінки. }} Етап 4. Запуск return False

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

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

5. Методи 2FA

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

10. Recovery 2FA

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

11.1. two_factor_methods

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

16. Acceptance Criteria

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

12. Dashboard 2FA

16.1. Базова 2FA

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