| HR / зарплата
|
Доступ до персональних і зарплатних даних.; "user_agent": context.get("user_agent"),
11.; Модель даних 2FA
=== Етап 5.; Контроль ===
!; | style="background:#c8e6c9;" | 2FA + рольовий контроль.; ERP.; Приклад
{| class="wikitable"
== 3.; Чому 2FA критична для ERP ==
|-
| SMS-код
| Код у SMS
| style="background:#ffcc80;" | Базовий
| Краще, ніж тільки пароль, але не найкращий варіант.; |-
| Push із number matching
| користувач системи вводить число з екрана входу
| style="background:#c8e6c9;" | Кращий
| Зменшує ризик MFA fatigue.; Дія
!; | платформа вимагає 2FA і створює подію ризику.; | style="background:#ffcc80;" | Високий
|}
2FA має використовуватись не тільки при вході, але й перед небезпечними діями.; користувач системи вводить TOTP-код або підтверджує другим фактором.; |-
| user_agent
| text
| Браузер / пристрій.; Рівень
|-
| Користувачів із 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;" | Контроль
|}
== 1.; Що таке 2FA ==
=== 11.3. two_factor_events ===
</div>
!; |-
| created_at
| timestamp
| Дата створення.; |-
| AC-6
| Бухгалтер без 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>
!; | Потрібне додаткове погодження.; Критерій
!; |-
| Email-код
| Код на email
| style="background:#ffcc80;" | Базовий
| Безпека залежить від пошти.; * Внутрішні вимоги K2 ERP до ролей, доступів, 2FA, журналювання та API-безпеки.; Роль / зона
db.commit()
!; |-
| user_id
| uuid
| користувач системи.; |-
| AC-7
| Фіндиректор входить із нового пристрою.; * CISA: Phishing-Resistant MFA Guidance.; Значення
<syntaxhighlight lang="python">
== 15.; Впровадження 2FA в K2 ERP ==
!; |}
!; | платформа вимагає новий challenge.; | style="background:#ef9a9a;" | Критично
|-
| style="background:#ef9a9a;" | Фінансовий директор
| Має доступ до платежів, бюджетів, рахунків, звітів.; платформа визначає, чи потрібна 2FA.; |-
| is_primary
| boolean
| ключовий метод.; |-
| Злам пошти
| Якщо пошту зламано, код додатково доступний зловмиснику.; |-
| AC-13
| Recovery для адміністратора.; |-
| Вимкнення інтеграції
| Ризик зупинки бізнес-процесу.; | style="background:#c8e6c9;" | 2FA + погодження.; Для критичних ролей у K2 ERP краще мислити ширше: MFA, adaptive MFA, step-up MFA і phishing-resistant MFA.; |}
db=db,
"status": "PENDING",
{| class="wikitable"
def create_2fa_challenge(user_id: str, method_type: str, context: dict, db: "Session") -> "TwoFactorChallenge":
=== 11.2. two_factor_challenges ===
"risk_score": context.get("risk_score", 0),
|-
| Адміністратор
| 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;" | Контроль
|}
def verify_totp_challenge(challenge_id: str, code: str, db: "Session") -> bool:
!; |-
| created_at
| timestamp
| Дата.;== 18.; Джерела ==
</div>
|-
| AC-8
| користувач системи змінює банківські реквізити.; * CISA: MFA Guidance.; | Запускається recovery-процедура.; |-
| challenge_type
| varchar
| LOGIN, STEP_UP, RECOVERY, CRITICAL_ACTION.; |-
| status
| varchar
| ACTIVE, PENDING, DISABLED, LOST.; !; Коментар
8.; |-
| ip_address
| varchar
| IP.; Подія входу записується в журнал.; |-
| Масовий експорт даних
| Ризик витоку.; Очікуваний результат
* щотижневий звіт;
* список користувачів без 2FA;
* блокування критичних ролей без 2FA;
* поступова відмова від SMS;
* перехід критичних ролей на FIDO2 / passkeys.; | платформа вимагає повторну 2FA.; Окремо варто відзначити ПРРО, маркетплейсами, службами доставки і електронним підписом.; | style="background:#ffcc80;" | Високий
|}
<div style="border-left: 8px solid #2e7d32; background: #e8f5e9; padding: 14px 18px; margin: 16px 0;">
<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">
=== Етап 1.; Аудит користувачів ===
!; Рекомендований метод
|-
| AC-5
| Адміністратор без 2FA намагається увійти.; | style="background:#ef9a9a;" | Критично
|}
Найпростіший приклад:
== 16. Acceptance Criteria ==
"challenge_type": challenge.challenge_type,
'''Червона зона:''' адміністратори, бухгалтерський обліковий облік, фінансовий блок, HR або керівники входять у K2 ERP тільки за паролем.; Роль
</div>
def is_2fa_required(user: "User", request_context: "RequestContext") -> bool:
'''Ризик без 2FA:''' викрадений пароль має змогу відкрити доступ до ERP без додаткової перевірки.; Роль
!; Це фактично відповідає ідеї 2FA: одного пароля недостатньо.; |-
| Щось, чим користувач системи є собою
| Біометрія на пристрої
| має змогу використовуватись для активації passkey або пристрою.; |-
| created_at
| timestamp
| Дата створення.; характеристика
!; | style="background:#fff9c4;" | Середній
|-
| Не phishing-resistant
| Код можна виманити.; Для ERP пароль без другого фактора — це незакритий ризик.; 6.; | style="background:#ffcc80;" | Високий
|-
| style="background:#ffcc80;" | Віддалений доступ
| Вхід поза офісом має підвищений ризик.; Ризик
!; | style="background:#c8e6c9;" | 2FA + погодження.; №
== 14.; Приклад Python-логіки ==
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>
{| class="wikitable"
2.; | style="background:#fff9c4;" | Середній
|-
| Незручність за кордоном
| SMS має змогу не приходити в роумінгу.; Тип
|-
| AC-1
| користувач системи вмикає TOTP.; |-
| event_type
| varchar
| 2FA_ENABLED, 2FA_DISABLED, 2FA_PASSED, 2FA_FAILED, RECOVERY_USED.; |-
| FIDO2 security key
| YubiKey, Feitian, Titan Key
| style="background:#c8e6c9;" | Дуже сильний
| Phishing-resistant варіант.; Потрібно передбачити:
[[Категорія:2FA]]
!; |-
| MFA fatigue
| користувач системи отримує багато push-запитів і випадково підтверджує.; Рекомендація
{| class="wikitable"
</div>
"user_id": user_id,
<syntaxhighlight lang="python">
== 2. 2FA vs MFA ==
* CISA: More than a Password.; Критерій
if challenge.status != "PENDING":
!; |-
| Push
| Підтвердження в мобільному додатку
| style="background:#fff9c4;" | Добрий
| Потрібен захист від випадкового підтвердження.; !; №
=== 7.3.; Push-2FA без number matching ===
return True
{{DISPLAYTITLE:2FA для ERP: двофакторна автентифікація в K2 ERP}}
!; |-
| method_type
| varchar
| Тип 2FA.; '''Зелена зона:''' у K2 ERP увімкнено 2FA для критичних ролей, step-up 2FA для небезпечних операцій, dashboard контролю, журнал подій і поступовий перехід на FIDO2 / passkeys.; Для критичних ролей потрібні TOTP, FIDO2 або passkeys.; * NIST SP 800-63B: Digital Identity Guidelines.; | style="background:#c8e6c9;" | Обов'язково
|-
| Заборона спільних логінів
| 2FA неможливо нормально використовувати зі спільним акаунтом.; Якщо другий фактор можна обійти простим проханням у чаті, це небезпечна технічна архітектура.; | style="background:#ef9a9a;" | Критично
|-
| Випадкове підтвердження
| користувач системи натискає approve, не читаючи.; 2FA і MFA часто використовують як синоніми, але між ними є собою різниця.; !; Фактор
!;</syntaxhighlight>
* [[K2 ERP]]
* [[MFA]]
* [[2FA]]
* [[Кібербезпека ERP]]
* [[Контроль доступу]]
* [[FIDO2]]
* [[Passkeys]]
* [[TOTP]]
* [[SMS OTP]]
* [[API Security]]
* [[Журнал аудиту]]
* [[Incident Response]]
=== 14.3.; Перевірка TOTP-коду ===
2FA — це мінімальний рівень захисту ERP від викрадених паролів.; №
!; | Вхід дозволено тільки після другого фактора.; платформа перевіряє challenge.; Статус
[[Категорія:K2 ERP]]
{| class="wikitable"
* фінансові документи;
* рахунки;
* банківські виписки;
* платежі;
* зарплати;
* кадрові інформаційні дані;
* податкові документи;
* договори;
* клієнти;
* постачальники;
* ціни;
* знижки;
* залишки;
* виробничі рецептури;
* управлінська формування звітів;
* інтеграції з банками.; ERP — це центр керування компанією.; |}
challenge = two_factor_challenge_repository.get_by_id(db, challenge_id)
=== 9.2.; Рекомендовані правила ===
=== 14.1.; Перевірка необхідності 2FA ===
=== 7.2. Email-2FA ===
!;<div style="border-left: 8px solid #f57c00; background: #fff3e0; padding: 14px 18px; margin: 16px 0;">
* TOTP;
* SMS як резервний або перехідний варіант;
* FIDO2 / passkeys для критичних ролей;
* recovery codes;
* device trust;
* risk-based challenge;
* журнал 2FA;
* dashboard 2FA.; |-
| AC-2
| користувач системи входить із 2FA.; |-
| Щось, що користувач системи має
| Телефон, додаток Authenticator, security key, passkey
| Другий фактор.; Вводить логін і пароль.; |}
1.;<pre>
!; return True
"method_type": method_type,
!; |-
| Зміна ролей користувача
| Ризик несанкціонованого доступу.; користувач системи вводить логін і пароль.; if user.role in ["ADMIN", "CHIEF_ACCOUNTANT", "CFO", "HR_PAYROLL"]:
data={
'''Правило для K2 ERP:''' SMS можна використовувати тільки як перехідний або резервний варіант.; Поле
Якщо пароль бухгалтера забезпечується через '''Критично істотно:''' пароль сам по собі не є собою достатнім захистом; додатково реалізовано адміністратора, фінансового директора або менеджера буде викрадено, зловмисник має змогу отримати доступ до фінансів, зарплат, договорів, клієнтів, складу, цін, банківських реквізитів і управлінської звітності.; | style="background:#ef9a9a;" | Критично
|}
!; Приклад
},
!; | style="background:#ef9a9a;" | Критично
|-
| style="background:#ef9a9a;" | центральний бухгалтер
| Має доступ до фінансів, податків, зарплат.; | style="background:#c8e6c9;" | Обов'язково
|-
| 2FA для віддаленого доступу
| Вхід поза офісом тільки з 2FA.; Чому 2FA обов’язкова
!; |-
| AC-12
| Recovery виконано.; | Вхід заблоковано або примусово вимагається 2FA.; | style="background:#c8e6c9;" | 2FA + журнал.; Якщо потрібна — створює 2FA challenge.; | платформа вимагає повторну 2FA.; №
== 9.; Політика 2FA для K2 ERP ==
challenge = two_factor_challenge_repository.create(
2.; Коментар
|
-
|
AC-9
|
Пароль + TOTP-код.; {| class="wikitable"
- визначити обов’язкові ролі;
- визначити дозволені методи;
- заборонити слабкі методи для критичних ролей;
- визначити recovery-процедуру;
- визначити step-up 2FA для критичних дій.; !; характеристика
|
| Користувачі з експортом даних
|
Challenge стає FAILED, спроба логуються.; |-
|
ip_address
|
varchar
|
-
|
status
|
varchar
|
-
|
AC-4
|
Challenge прострочений.; Очікуваний результат
Критично істотно: recovery не повинен бути слабшим за саму 2FA.; Рівень безпеки
|
; Приклад
|
; Рівень
"ip_address": context.get("ip_address"),
| style="background:#c8e6c9;" | Обов'язково
|
payload={
- вимагати 2FA для всіх користувачів;
- не дозволяти SMS для адміністраторів;
- не дозволяти email-код для фінансових ролей;
- вимагати FIDO2 / passkey для super admin;
- вимагати повторну 2FA для критичних дій;
- блокувати користувача після багатьох невдалих 2FA;
- логувати всі 2FA-події;
- показувати dashboard покриття 2FA.; Очікуваний результат
11.1. two_factor_methods
10. Recovery 2FA
|
-
|
AC-16
|
class="wikitable"
6.; Рекомендація для K2 ERP
)
- резервні коди;
- резервний метод 2FA;
- заявку на відновлення доступу;
- перевірку особи;
- погодження адміністратором;
- журнал recovery-події;
- тимчасовий доступ з коротким TTL;
- обов’язкове повторне конфігурація 2FA після recovery.; характеристика
user_id=user_id,
користувач системи має змогу втратити телефон, додаток або security key.; |-
|
AC-3
|
}
|
Він бачить покриття 2FA по ролях.; |-
|
TOTP
|
Google Authenticator, Microsoft Authenticator, 1Password, Bitwarden
|
Добрий
|
style="background:#ffcc80;" | Високий
|
