Перейти до вмісту

2FA

Матеріал з K2 ERP Wiki Ukraine — База знань з автоматизації та санкцій в Україні


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



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

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

Орієнтир: CISA зазначає, що phishing-resistant MFA є стандартом, до якого мають прагнути організації, але будь-яка MFA краще, ніж її відсутність. Для ERP це означає: 2FA потрібно впроваджувати негайно, а для критичних ролей поступово переходити на сильніші методи — FIDO2 або passkeys.

1. Що таке 2FA

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

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

1. Користувач вводить логін і пароль.
2. Система просить другий фактор: код із додатку, SMS, push або security key.
3. Тільки після другого фактора користувач входить у K2 ERP.
Фактор Приклад Коментар
Щось, що користувач знає Пароль або PIN Перший фактор.
Щось, що користувач має Телефон, додаток Authenticator, security key, passkey Другий фактор.
Щось, чим користувач є Біометрія на пристрої Може використовуватись для активації passkey або пристрою.

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

2. 2FA vs MFA

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

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

Важливо: 2FA — це мінімальний рівень захисту. Для критичних ролей у K2 ERP краще мислити ширше: MFA, adaptive MFA, step-up MFA і phishing-resistant MFA.

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

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

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

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

Ризик без 2FA: викрадений пароль може відкрити доступ до ERP без додаткової перевірки. Для зловмисника це означає можливість діяти від імені реального працівника.

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

Роль / зона Чому 2FA обов’язкова Рівень
Адміністратор K2 ERP Може змінювати права, ролі, інтеграції, налаштування. Критично
Головний бухгалтер Має доступ до фінансів, податків, зарплат. Критично
Фінансовий директор Має доступ до платежів, бюджетів, рахунків, звітів. Критично
Користувачі з банківськими операціями Можуть впливати на платежі або реквізити. Критично
HR / зарплата Доступ до персональних і зарплатних даних. Високий
Менеджери з доступом до цін Можуть змінювати комерційні умови. Високий
Віддалений доступ Вхід поза офісом має підвищений ризик. Високий
Користувачі з експортом даних Можуть вивантажити клієнтів, ціни, договори, залишки. Високий

5. Методи 2FA

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

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

Роль Мінімальний метод Рекомендований метод Колір
Адміністратор TOTP FIDO2 / passkey Сильний захист
Головний бухгалтер TOTP FIDO2 / passkey Сильний захист
Фінансовий директор TOTP FIDO2 / passkey Сильний захист
HR / зарплата TOTP TOTP або FIDO2 Обов'язково
Менеджер продажів TOTP або push TOTP Бажано
Склад TOTP або SMS TOTP Бажано
Тимчасовий користувач TOTP Короткий TTL + TOTP Контроль

Правило для K2 ERP: SMS можна використовувати тільки як перехідний або резервний варіант. Для критичних ролей потрібні TOTP, FIDO2 або passkeys.

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

7.1. SMS-2FA

Ризик Опис Рівень
Перехоплення SMS Код може бути скомпрометований через мобільні ризики або соціальну інженерію. Високий
Залежність від оператора Користувач може не отримати код. Середній
Незручність за кордоном SMS може не приходити в роумінгу. Середній
Не phishing-resistant Код можна ввести на фальшивому сайті. Критично

7.2. Email-2FA

Ризик Опис Рівень
Злам пошти Якщо пошту зламано, код також доступний зловмиснику. Критично
Затримки доставки Код може приходити із затримкою. Середній
Не phishing-resistant Код можна виманити. Критично

7.3. Push-2FA без number matching

Ризик Опис Рівень
MFA fatigue Користувач отримує багато push-запитів і випадково підтверджує. Критично
Випадкове підтвердження Користувач натискає approve, не читаючи. Високий

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

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

Операція Чому потрібна повторна 2FA Рекомендація
Зміна банківських реквізитів Ризик підміни рахунку. 2FA + погодження.
Створення платежу Ризик фінансової втрати. 2FA + рольовий контроль.
Зміна ролей користувача Ризик несанкціонованого доступу. 2FA адміністратора.
Масовий експорт даних Ризик витоку. 2FA + журнал.
Видалення документа Ризик приховування операцій. 2FA + audit log.
Вимкнення інтеграції Ризик зупинки бізнес-процесу. 2FA + погодження.

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

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

Правило Опис Статус
2FA для адміністраторів Без 2FA адміністратор не може увійти. Обов'язково
2FA для бухгалтерії Доступ до фінансових і податкових даних тільки з 2FA. Обов'язково
2FA для фінансів Платежі, бюджети, реквізити — тільки з 2FA. Обов'язково
2FA для віддаленого доступу Вхід поза офісом тільки з 2FA. Обов'язково
2FA для нового пристрою Новий пристрій потребує другого фактора. Обов'язково
2FA для нової країни/IP Система має вимагати повторну перевірку. Обов'язково
Заборона спільних логінів 2FA неможливо нормально використовувати зі спільним акаунтом. Обов'язково

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.

Критично важливо: recovery не повинен бути слабшим за саму 2FA. Якщо другий фактор можна обійти простим проханням у чаті, це небезпечна архітектура.

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

11.1. two_factor_methods

Поле Тип Опис
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

Поле Тип Опис
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

Поле Тип Опис
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 адміністратора

Показник Значення Стан
Користувачів із 2FA 86% Потрібно довести до 100%
Адміністраторів із 2FA 100% Норма
Бухгалтерів із 2FA 92% Потрібна дія
Фінансових ролей із 2FA 100% Норма
Користувачів тільки з SMS 18 Замінити на TOTP/FIDO2
Невдалих 2FA за день 12 Контроль
Підозрілих 2FA-запитів 3 Критично
Recovery-подій за місяць 4 Контроль

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

Користувач Роль 2FA Ризик Дія
admin2 Адміністратор Вимкнено Критично Заблокувати або увімкнути 2FA
buh_olena Бухгалтер SMS Високий Перевести на TOTP/FIDO2
sales_ivan Менеджер TOTP Норма Без дії
cfo Фіндиректор FIDO2 Добре Без дії

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

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

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

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

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

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

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

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

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

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

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

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

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

16.3. Step-up 2FA

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

16.4. Recovery

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

16.5. Dashboard

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

17. Висновок

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

Червона зона: адміністратори, бухгалтерія, фінанси, HR або керівники входять у K2 ERP тільки за паролем.

Зелена зона: у K2 ERP увімкнено 2FA для критичних ролей, step-up 2FA для небезпечних операцій, dashboard контролю, журнал подій і поступовий перехід на FIDO2 / passkeys.

Головне правило: 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. Див. також

Отримано з https://wiki.erp.kyiv.ua/index.php?title=2FA&oldid=1000