Парольна політика і MFA

1) Цілі та область дії

Мета: знизити ризик компрометації облікових записів співробітників/партнерів і гравців, забезпечити відповідність внутрішнім стандартам безпеки і вимогам регуляторів.
Охоплення: всі корпоративні акаунти (SSO/IdP), адмін-панелі, платіжні та KYC-консолі, сервісні/бот-акаунти, а також користувацькі акаунти гравців.

2) Базові принципи

Phishing-resistant за замовчуванням: FIDO2/WebAuthn ≥ TOTP ≥ Push ≥ SMS/e-mail OTP (останні - тільки як fallback).
Least Privilege + JIT: привілеї видаються мінімально і тимчасово, MFA обов'язково при підвищенні.
Passwords as last resort: упор на пасфрази і менеджери паролів; заборона «пам'ятних» коротких паролів.
Security by Default: MFA включена за замовчуванням; для критичних дій - re-auth.
Observability: всі події автентифікації/заявок/скидів - в аудиторських журналах.

3) Вимоги до паролів/пасфразів

3. 1 Співробітники/адміни

Формат: пасфраза ≥ 14 символів, допускаються прогалини; заборонені вимоги до «складності» типу'A1!'- замість цього перевірка на витоки (have-I-been-pwned-стиль локально/через API-хеш).
Перевикористання: заборона reuse останніх 10, заборона корпоративного пароля для зовнішніх сервісів.
Ротація: тільки при компрометації/ризику; примусова періодична зміна - не застосовується (щоб уникнути слабких паролів).
Зберігання: тільки в корпоративному менеджері паролів; заборона локальних файлів/браузерних автозберігань поза MDM-профілями.

3. 2 Гравці

Мінімум 10-12 символів або генератор пасфраз; візуальна індикація сили; блок списків популярних паролів.
Увімкнути «показати пароль» і «вставка з менеджера»; не нав'язувати нестандартні обмеження (емодзі/символи - можна).

4) Хешування і секрети

Алгоритм: Argon2id (пам'ять ≥ 256 MB, ітерації ≥ 3, паралелізм ≥ 1); припустимо bcrypt (cost ≥ 12) як легасі.
Сіль: унікальна 16 + байт на запис. Перець (pepper): системний секрет в HSM/KMS.
Оновлення: при вході легасі-хеші прозоро «перехешувати» на поточний профіль.
Сервісні ключі/API-токени: не «паролі» - керувати через секрет-менеджер, ротація за розкладом і при інцидентах.

5) MFA: фактори та пріоритети

• резервні backup-коди (10 шт. одноразові), зберігання офлайн;
• MFA-enforcement: для адмін-доступів та платіжних дій без винятків;
• Number-matching в push, заборона «одним натисканням погодитися».

6) Політика сесій і re-auth

Тривалість: web 12 год (інтерактив), адмін-консолі 8 год, критичні панелі 4 год.
Idle timeout: 15-30 хв для адмінок.
Re-auth с MFA: при виплатах/зміні реквізитів/зміні e-mail/MFA/видачі токенів API.
Device binding: MDM/зареєстрований пристрій для співробітників; для гравців - запам'ятовування довірених пристроїв з ризик-оцінкою.

7) Захист від атак на аутентифікацію

Credential stuffing: IP/device/user-based rate-limits, захисні затримки, поведінковий аналіз, перевірка паролів, що витекли.
Brute force: прогресивні затримки/капча після N невдач; м'які блокування (тимчасові), без тривалого lockout для гравців.
Password spraying: детекція за аномаліями (багато акаунтів з одним паролем).
MFA-fatigue: ліміт push-запитів, number-match, повідомлення користувачеві.
Bot/anti-automation: WebAuthn переважно, поведінкові сигнали, TLS-фіксація, mTLS для адмін-панелей.

8) Процедури (SOP)

8. 1 Онбординг співробітника

1. SSO-аккаунт через SCIM;

2. видача FIDO2-ключа (мінімум 2: основний + резервний) і TOTP;

3. встановлення менеджера паролів;

4. підтвердження навчання (фішинг, MFA).

8. 2 Втрата пристрою/скидання MFA

1. Самовідрахунок через портал → тимчасове блокування сесій;

2. верифікація за документами + підтвердження через керівника;

3. випуск нових факторів;

4. аудит журналу входів за 30 днів.

8. 3 Break-glass (аварійний доступ)

Тільки для відновлення; Фактор: HSM-збережений майстер-токен + другий стверджуючий; час ≤ 30 хв; повний запис сесії; пост-рев'ю Security + DPO.

8. 4 Скидання пароля гравця

Канал: e-mail/телефон, одноразове посилання ≤ 15 хв; після скидання - обов'язкове налаштування MFA при наступному вході (м'який примус з бонусом/мотивацією).

9) Правила для різних категорій обліків

9. 1 Співробітники/вендори

Обов'язковий WebAuthn + TOTP; заборона SMS-MFA.
Доступ до адмінок тільки з MDM-пристроїв/корп-VPN; JIT при підвищенні привілеїв.
Заборона локальних «загальних» акаунтів; тільки іменовані.

9. 2 Гравці

MFA м'яко-примусова: мотиваційні банери, бонуси за включення; жорстко - при high-risk (виплати/зміна реквізитів).
Підтримка доступності: ключові фрази/екранні зчитувачі, fallback-канали.

9. 3 Сервісні акаунти/API

Без паролів; тільки взаємна автентифікація (mTLS, OIDC client-creds, підпис вебхуків).
Ключі в секрет-менеджері; ротація та аудит.

10) Інтеграція з IdP/SSO

Центральний IdP (OIDC/SAML); групова прив'язка до ролей (RBAC as code).
Adaptive MFA: посилювати фактори за ризик-сигналами (гео/новий пристрій/аномалії).
SCIM-провиженінг/де-провиженінг; offboarding ≤ 15 хв після звільнення.

11) Журналювання та аудит

Події (аудит-обов'язкові): `LOGIN_SUCCESS/FAIL`, `MFA_ENROLL/VERIFY/FAIL`, `PASSWORD_RESET_REQUEST/COMPLETE`, `MFA_RESET`, `DEVICE_TRUST_ADD/REMOVE`, `BREAK_GLASS_START/END`, `ADMIN_LOGIN`, `RISK_UPGRADE`, `TOKEN_ISSUE/REVOKE`.

Копія в WORM, підпис/хеш-ланцюжки; прив'язка до'trace _ id','actor _ id','purpose'.

12) Метрики та KPI/KRI

MFA adoption (співробітники): 100% WebAuthn, 100% TOTP як резерв.
MFA adoption (гравці): ≥ 30-50% в 6 міс (залежно від ринку).
Compromised logins: 0; частка спроб з витеклими паролями, заблокованих на периметрі - 100%.
Avg time to offboard: ≤ 15 хв.
Push fatigue alerts/1000 MAU: ↓ MoM.
Password reset success rate: ≥ 98% без звернення в саппорт.
Re-auth coverage: 100% для high-risk операцій.

13) Приклади політик (фрагменти)

13. 1 Політика довжини і перевірки витоків (псевдо-YAML)

yaml password:
min_length: 14 allow_spaces: true banned_lists:
- top100k_common
- organization_keywords breach_check: enabled  # k-anonymity lookup rotation: on_compromise_only

13. 2 MFA-енфорсмент

yaml mfa:
required_roles:
- admin
- payments
- aml
- kyc required_factors:
- webauthn fallback:
- totp disallowed:
- sms

13. 3 Re-auth для чутливих дій

yaml reauth:
actions:
- change_payout_details
- approve_withdrawal
- change_email
- manage_mfa ttl_minutes: 5

14) Взаємозв'язок з іншими контролями

RBAC/ABAC/SoD: MFA обов'язкова при призначенні/зміні ролей, JIT-підйомах і операціях'APPROVE _'.
Журнали та зберігання логів: «Аудиторські журнали і сліди доступу», «Політика зберігання логів».
Інциденти: при підозрі на компрометацію - негайний password + token reset, відгук сесій, форензика (див. «Процедури при витоку даних»).

15) Чек-листи

Перед релізом автентифікації

• WebAuthn включений, TOTP як резерв, backup-коди видаються.
• Перевірка витеклих паролів і лексичних списків.
• Rate-limits і захист від credential stuffing.
• Re-auth для чутливих операцій.
• Логи/аудит і алерти в SIEM.

Щоквартально

• Аналітика MFA-прийняття; A/B-мотиватори для гравців.
• Рев'ю політик Push-втоми.
• Ротація сервісних ключів, перевірка перцю/KMS.
• Навчання: втрата ключа FIDO2, відмова TOTP, break-glass.

16) Дорожня карта впровадження

Тижні 1-2: аудит аутентифікації, включити WebAuthn і TOTP, налаштувати breach-check, оновити політику паролів (пасфрази).
Тижні 3-4: впровадити re-auth для high-risk, number-matching в push, SIEM-алерти; роздати FIDO2 ключі співробітникам.
Місяць 2: адаптивна MFA (ризик-сигнали), повнофункціональний менеджер паролів, self-service портал скидання, backup-коди.
Місяць 3 +: A/B просування MFA гравцям, періодичні навчання, оптимізація UX і зниження MFA-fatigue, автоматизація звітності KPI.

TL; DR

Сильна автентифікація = пасфрази + WebAuthn (обов'язково) + TOTP (резерв) + re-auth для ризикових дій, захист від stuffing/brute, надійне хешування (Argon2id), менеджер паролів і аудит кожного кроку. Це скорочує компрометації акаунтів, спрощує відповідність вимогам і майже не трет UX, якщо зробити грамотно.