FIDO2

Критично важливо: SMS-коди, email-коди, TOTP і push-підтвердження зменшують ризик злому, але не є повністю захищеними від phishing. Для адміністраторів, бухгалтерії, фінансів і керівників ERP потрібна сильніша автентифікація — FIDO2 / WebAuthn / passkeys.

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

Орієнтир: FIDO Alliance описує FIDO2 як набір стандартів, де WebAuthn є web API для FIDO-автентифікації, а CTAP2 дозволяє використовувати зовнішні автентифікатори — security keys або мобільні пристрої — через USB, NFC або BLE. :contentReference[oaicite:0]{index=0}

Управлінський результат: керівник і адміністратор безпеки повинні бачити, які користувачі мають FIDO2, які досі використовують слабкі методи MFA, які ключі зареєстровані, які втрачено, які входи були підозрілими та які ролі не можна допускати до ERP без phishing-resistant автентифікації.

1. Що таке FIDO2

FIDO2 — це сучасний стандарт автентифікації, який дозволяє входити в систему без класичного пароля або використовувати сильний другий фактор, захищений криптографією.

FIDO2 складається з двох ключових частин:

Компонент	Опис	Для чого потрібен
WebAuthn	Стандартний web API, який підтримується браузерами та платформами.	Дозволяє web-додатку K2 ERP працювати з passkeys і security keys.
CTAP2	Протокол взаємодії між браузером / ОС і зовнішнім автентифікатором.	Дозволяє використовувати USB, NFC або BLE security key.

FIDO Alliance пояснює, що passkey — це FIDO-облікові дані, прив’язані до акаунта користувача в застосунку або на сайті; користувач входить так само, як розблоковує пристрій — біометрією, PIN або pattern. :contentReference[oaicite:1]{index=1}

2. Чому FIDO2 важливий саме для ERP

ERP — це система, де компрометація доступу може мати прямі фінансові наслідки.

У K2 ERP можуть зберігатися:

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

Ризик: якщо вхід у ERP захищено тільки паролем, SMS-кодом або TOTP-кодом, користувача все ще можна атакувати через phishing-сайт, який імітує сторінку входу.

Перевага FIDO2: автентифікація криптографічно прив’язується до справжнього домену K2 ERP. Це означає, що ключ не підтвердить вхід на фальшивому домені.

3. FIDO2, passkeys і security keys

Термін	Що означає	Приклад
FIDO2	Стандарт phishing-resistant автентифікації.	WebAuthn + CTAP2.
WebAuthn	API браузера для входу через FIDO.	Вхід у K2 ERP через passkey.
CTAP2	Протокол для зовнішніх ключів.	USB/NFC/BLE security key.
Security key	Фізичний ключ автентифікації.	YubiKey, Feitian, Titan Key або інший FIDO2-сумісний ключ.
Passkey	FIDO-облікові дані на пристрої або в password manager.	Windows Hello, macOS/iCloud Keychain, Android, iOS, 1Password, Bitwarden.
Platform authenticator	Автентифікатор, вбудований у пристрій.	Touch ID, Face ID, Windows Hello.
Roaming authenticator	Переносний автентифікатор.	USB/NFC security key.

4. Чим FIDO2 сильніший за SMS, TOTP і push

Метод	Захищає від викраденого пароля	Захищає від phishing	Коментар
Пароль	Ні	Ні	Найслабший варіант для ERP.
SMS OTP	Частково	Ні	Код можна виманити або перехопити.
Email OTP	Частково	Ні	Якщо зламана пошта — зламана 2FA.
TOTP	Так	Ні	Код можна ввести на фальшивому сайті.
Push	Так	Частково	Є ризик MFA fatigue.
Push із number matching	Так	Краще	Менше ризику випадкового approve.
FIDO2 security key	Так	Так	Рекомендовано для критичних ролей.
Passkey	Так	Так	Зручний сучасний варіант.

NIST SP 800-63B Revision 4 зазначає, що застосунки рівня AAL2 повинні пропонувати phishing-resistant варіант автентифікації. :contentReference[oaicite:2]{index=2} CISA також прямо вказує, що єдиною широко доступною phishing-resistant автентифікацією є FIDO/WebAuthn. :contentReference[oaicite:3]{index=3}

5. Як працює FIDO2 у K2 ERP

5.1. Реєстрація ключа

1. Користувач входить у K2 ERP звичайним способом.
2. Відкриває налаштування безпеки.
3. Натискає «Додати FIDO2 / passkey».
4. K2 ERP створює WebAuthn registration challenge.
5. Браузер передає challenge автентифікатору.
6. Користувач підтверджує дію PIN, біометрією або дотиком до ключа.
7. Автентифікатор створює пару ключів.
8. Публічний ключ зберігається в K2 ERP.
9. Приватний ключ залишається на пристрої або security key.

Правильна модель: K2 ERP ніколи не зберігає приватний ключ користувача. У системі зберігається тільки публічний ключ і технічні параметри credential.

5.2. Вхід користувача

1. Користувач відкриває K2 ERP.
2. Система створює authentication challenge.
3. Браузер передає challenge FIDO2-автентифікатору.
4. Користувач підтверджує вхід на пристрої або ключі.
5. Автентифікатор підписує challenge приватним ключем.
6. K2 ERP перевіряє підпис публічним ключем.
7. Якщо перевірка успішна — створюється сесія.

6. Де FIDO2 має бути обов’язковим

Роль / зона	Чому потрібен FIDO2	Рівень
Super Admin	Повний контроль над системою.	Обов’язково
Адміністратор K2 ERP	Ролі, права, налаштування, інтеграції.	Обов’язково
Головний бухгалтер	Фінанси, податки, зарплата, звіти.	Обов’язково
Фінансовий директор	Платежі, бюджети, банківські дані.	Обов’язково
HR / зарплата	Персональні й зарплатні дані.	Рекомендовано
Керівники	Доступ до управлінської звітності.	Рекомендовано
Віддалений доступ	Вищий ризик phishing і компрометації.	Рекомендовано
Масовий експорт даних	Ризик витоку даних.	Step-up FIDO2

7. FIDO2 для критичних дій

FIDO2 потрібно використовувати не тільки для входу, а й для підтвердження небезпечних операцій.

Операція	Ризик	Контроль
Зміна банківських реквізитів	Підміна рахунку.	Step-up FIDO2 + погодження.
Зміна ролі користувача	Розширення доступу.	Step-up FIDO2 адміністратора.
Масовий експорт клієнтів	Витік бази.	Step-up FIDO2 + audit log.
Підтвердження платежу	Фінансова втрата.	Step-up FIDO2 + двоетапне погодження.
Вимкнення інтеграції	Зупинка бізнес-процесу.	Step-up FIDO2.
Генерація API token	Створення прихованого доступу.	Step-up FIDO2 + журнал.

8. Політика FIDO2 для K2 ERP

8.1. Мінімальні правила

Правило	Опис	Статус
FIDO2 для Super Admin	Без FIDO2 super admin не може увійти.	Must have
FIDO2 для адміністраторів	Усі адміністратори повинні мати FIDO2.	Must have
Мінімум 2 зареєстровані ключі для admin	Основний і резервний ключ.	Must have
Заборона SMS для admin	SMS не допускається як основний метод для admin.	Must have
Step-up FIDO2 для критичних дій	Потрібне повторне підтвердження.	Must have
Журнал FIDO2-подій	Реєстрація, вхід, помилка, видалення ключа.	Must have
Recovery через погодження	Відновлення доступу до admin-акаунта потребує погодження.	Must have

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

FIDO2 для всіх фінансових ролей;
FIDO2 для користувачів із доступом до зарплати;
FIDO2 для користувачів із віддаленим доступом;
passkeys для зручного входу з корпоративних пристроїв;
фізичні security keys для адміністраторів;
hardware security key як резерв для керівника;
заборона реєстрації невідомих пристроїв без підтвердження;
регулярний аудит зареєстрованих FIDO2-ключів.

9. Модель даних FIDO2

9.1. fido2_credentials

Поле	Тип	Опис
id	uuid	ID credential.
user_id	uuid	Користувач.
credential_id	text	ID WebAuthn credential.
public_key	text	Публічний ключ.
sign_count	integer	Лічильник підписів, якщо підтримується.
authenticator_type	varchar	PLATFORM або ROAMING.
transport	varchar	USB, NFC, BLE, INTERNAL.
device_name	varchar	Назва пристрою.
aaguid	varchar	Ідентифікатор моделі автентифікатора, якщо доступний.
backup_eligible	boolean	Чи може credential бути синхронізованим.
backup_state	boolean	Чи є credential у backup-синхронізації.
status	varchar	ACTIVE, LOST, DISABLED, REVOKED.
last_used_at	timestamp	Останнє використання.
created_at	timestamp	Дата створення.

9.2. fido2_challenges

Поле	Тип	Опис
id	uuid	ID challenge.
user_id	uuid	Користувач.
challenge_type	varchar	REGISTRATION, LOGIN, STEP_UP, RECOVERY.
challenge	text	Challenge для WebAuthn.
rp_id	varchar	Relying Party ID, наприклад erp.example.com.
origin	varchar	Дозволений origin.
status	varchar	PENDING, PASSED, FAILED, EXPIRED.
expires_at	timestamp	Строк дії.
created_at	timestamp	Дата створення.

9.3. fido2_events

Поле	Тип	Опис
id	uuid	ID події.
user_id	uuid	Користувач.
credential_id	uuid	Credential, якщо є.
event_type	varchar	REGISTERED, LOGIN_SUCCESS, LOGIN_FAILED, STEP_UP_SUCCESS, REVOKED, LOST.
ip_address	varchar	IP.
user_agent	text	Браузер / пристрій.
risk_score	integer	Оцінка ризику.
payload	jsonb	Технічні дані без секретів.
created_at	timestamp	Дата.

10. API K2 ERP для FIDO2

10.1. Почати реєстрацію ключа

POST /api/v1/security/fido2/registration/options

10.2. Завершити реєстрацію ключа

POST /api/v1/security/fido2/registration/verify

10.3. Почати вхід через FIDO2

POST /api/v1/security/fido2/authentication/options

10.4. Завершити вхід через FIDO2

POST /api/v1/security/fido2/authentication/verify

10.5. Список ключів користувача

GET /api/v1/security/fido2/credentials

10.6. Відкликати ключ

POST /api/v1/security/fido2/credentials/{credential_id}/revoke

10.7. Позначити ключ як втрачений

POST /api/v1/security/fido2/credentials/{credential_id}/mark-lost

10.8. Step-up FIDO2 для критичної дії

POST /api/v1/security/fido2/step-up/verify

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

11.1. Перевірка, чи потрібен FIDO2

def is_fido2_required(user: "User", action: str | None = None, context: dict | None = None) -> bool:
    if user.role in ["SUPER_ADMIN", "ADMIN", "CFO", "CHIEF_ACCOUNTANT"]:
        return True

    if action in [
        "CHANGE_BANK_DETAILS",
        "CREATE_API_TOKEN",
        "CHANGE_USER_ROLE",
        "MASS_EXPORT",
        "APPROVE_PAYMENT",
    ]:
        return True

    if context and context.get("remote_access") is True:
        return user.security_policy.require_fido2_for_remote_access

    return False

11.2. Створення registration challenge

def create_fido2_registration_options(user: "User", db: "Session") -> dict:
    challenge = fido2_service.generate_challenge()

    fido2_challenge_repository.create(
        db=db,
        data={
            "user_id": user.id,
            "challenge_type": "REGISTRATION",
            "challenge": challenge,
            "rp_id": "erp.example.com",
            "origin": "https://erp.example.com",
            "status": "PENDING",
            "expires_at": utc_now_plus_minutes(5),
        },
    )

    return {
        "rp": {
            "name": "K2 ERP",
            "id": "erp.example.com",
        },
        "user": {
            "id": str(user.id),
            "name": user.email,
            "displayName": user.full_name,
        },
        "challenge": challenge,
        "pubKeyCredParams": [
            {"type": "public-key", "alg": -7},
            {"type": "public-key", "alg": -257}
        ],
        "authenticatorSelection": {
            "userVerification": "required",
            "residentKey": "preferred",
        },
        "timeout": 300000,
        "attestation": "none",
    }

11.3. Збереження credential

def save_fido2_credential(user_id: str, verification_result: dict, db: "Session") -> "Fido2Credential":
    credential = fido2_credential_repository.create(
        db=db,
        data={
            "user_id": user_id,
            "credential_id": verification_result["credential_id"],
            "public_key": verification_result["public_key"],
            "sign_count": verification_result.get("sign_count", 0),
            "authenticator_type": verification_result.get("authenticator_type"),
            "transport": verification_result.get("transport"),
            "aaguid": verification_result.get("aaguid"),
            "backup_eligible": verification_result.get("backup_eligible"),
            "backup_state": verification_result.get("backup_state"),
            "status": "ACTIVE",
        },
    )

    audit_logger.log(
        user_id=user_id,
        event_type="FIDO2_CREDENTIAL_REGISTERED",
        payload={
            "credential_id": str(credential.id),
            "authenticator_type": credential.authenticator_type,
        },
    )

    db.commit()
    return credential

11.4. Перевірка входу

def verify_fido2_login(user: "User", assertion_response: dict, db: "Session") -> bool:
    credential = fido2_credential_repository.get_by_credential_id(
        db=db,
        credential_id=assertion_response["credential_id"],
    )

    if not credential or credential.status != "ACTIVE":
        return False

    is_valid = fido2_service.verify_assertion(
        assertion_response=assertion_response,
        public_key=credential.public_key,
        expected_rp_id="erp.example.com",
        expected_origin="https://erp.example.com",
    )

    if not is_valid:
        audit_logger.log(
            user_id=user.id,
            event_type="FIDO2_LOGIN_FAILED",
            payload={"credential_record_id": str(credential.id)},
        )
        db.commit()
        return False

    credential.last_used_at = utc_now()

    audit_logger.log(
        user_id=user.id,
        event_type="FIDO2_LOGIN_SUCCESS",
        payload={"credential_record_id": str(credential.id)},
    )

    db.commit()
    return True

12. Recovery та втрата ключа

Користувач може втратити security key або пристрій із passkey. Тому recovery має бути сильним і контрольованим.

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

мінімум два ключі для адміністраторів;
резервний hardware key;
recovery codes;
заявка на відновлення;
перевірка особи користувача;
погодження другим адміністратором;
журнал recovery;
обов’язкове відкликання втраченого ключа;
обов’язкова реєстрація нового FIDO2-ключа;
тимчасовий доступ тільки з коротким TTL.

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

13. Dashboard FIDO2

13.1. KPI адміністратора безпеки

Показник	Значення	Стан
Super Admin із FIDO2	100%	Норма
Адміністраторів із FIDO2	100%	Норма
Фінансових ролей із FIDO2	80%	Потрібна дія
Бухгалтерів із FIDO2	76%	Потрібна дія
Користувачів тільки з SMS	18	Замінити
Втрачених ключів	2	Контроль
Ключів без використання понад 90 днів	11	Перевірити
Підозрілих FIDO2-помилок	3	Критично

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

Користувач	Роль	Поточний метод	Ризик	Дія
admin2	Адміністратор	TOTP без FIDO2	Критично	Видати security key
buh_olena	Бухгалтер	SMS	Високий	Перевести на FIDO2 або TOTP
cfo	Фіндиректор	FIDO2 security key	Добре	Без дії
director	Керівник	Passkey	Добре	Без дії

14. План впровадження FIDO2 в K2 ERP

Етап 1. Аудит доступів

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

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

визначити ролі, для яких FIDO2 обов’язковий;
визначити дозволені типи ключів;
визначити, чи дозволені passkeys;
визначити, чи потрібні hardware keys для admin;
визначити recovery-процедуру;
визначити step-up FIDO2 для критичних дій.

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

WebAuthn registration;
WebAuthn authentication;
credential storage;
challenge storage;
origin / RP ID validation;
credential revocation;
lost key flow;
FIDO2 events;
dashboard.

Етап 4. Пілот

super admin;
адміністратори;
фінансовий директор;
головний бухгалтер;
5–10 power users;
перевірка recovery;
перевірка step-up дій.

Етап 5. Масове впровадження

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

15. Acceptance Criteria

15.1. Реєстрація FIDO2

№	Критерій	Очікуваний результат
AC-1	Користувач додає FIDO2 security key.	Ключ реєструється, публічний ключ зберігається.
AC-2	Користувач додає passkey.	Passkey реєструється як platform authenticator.
AC-3	Challenge прострочений.	Реєстрація не приймається.
AC-4	Origin неправильний.	Реєстрація відхиляється.

15.2. Вхід через FIDO2

№	Критерій	Очікуваний результат
AC-5	Користувач входить із FIDO2.	Сесія створюється після успішної перевірки assertion.
AC-6	Користувач використовує невідомий ключ.	Вхід відхиляється.
AC-7	Ключ відкликаний.	Вхід відхиляється.
AC-8	Користувач із роллю admin не має FIDO2.	Вхід блокується або вимагається реєстрація FIDO2.

15.3. Step-up FIDO2

№	Критерій	Очікуваний результат
AC-9	Користувач змінює банківські реквізити.	Система вимагає step-up FIDO2.
AC-10	Адміністратор створює API token.	Система вимагає step-up FIDO2.
AC-11	Користувач запускає масовий експорт.	Система вимагає step-up FIDO2 і логування.

15.4. Recovery

№	Критерій	Очікуваний результат
AC-12	Користувач повідомляє про втрату ключа.	Ключ позначається LOST або REVOKED.
AC-13	Admin recovery.	Потрібне погодження другим адміністратором.
AC-14	Recovery завершено.	Подія логуються, користувач реєструє новий ключ.

15.5. Dashboard

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

16. Висновок

FIDO2 — це один із найсильніших практичних способів захистити ERP від phishing і викрадених паролів.

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

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

Головне правило: для ERP пароль і одноразовий код — це вже недостатньо для критичних ролей. Для адміністратора, бухгалтера, фінансового директора і керівника стандартом має бути FIDO2 або passkey.

17. Джерела

FIDO Alliance: Passkeys.
FIDO Alliance: User Authentication Specifications Overview.
CISA: More than a Password.
CISA: Phishing-resistant MFA.
NIST SP 800-63B Revision 4.
Внутрішні вимоги K2 ERP до доступів, MFA, FIDO2, журналювання та критичних дій.

18. Див. також