Парольная политика и 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, если сделать грамотно.