Парольная политика и защита доступа

Механизмы защиты

1. Защита от подбора паролей

Два независимых слоя — кратковременная блокировка по серии неудач в памяти процесса и постоянная блокировка учетной записи — отказывают во входе после настраиваемого числа неудачных попыток. Неверный пароль, временная блокировка по серии и постоянная блокировка возвращают ошибку 401, так что атакующий не может их различить.

Отказы дополнительно сопровождаются случайной задержкой, чтобы блокировку нельзя было отличить от медленной проверки пароля по времени ответа.

Переменные окружения для настройки порогов

TNGRI_LOGIN_THROTTLE_*

2. Политика паролей

Каждый новый пароль проверяется на соответствие следующим параметрам:

  • Длина

  • Разнообразие символов

  • Использование фрагментов логина в пароле

  • Использование предыдущих паролей

У пароля есть время жизни — срок, в течение которого пароль актуален. При окончании этого срока учетная запись блокируется до разблокировки администратором.

Значения по умолчанию заданы консервативно и настраиваются через переменные окружения.

Переменные окружения для настройки значений по умолчанию

TNGRI_PASSWORD_POLICY_*.

3. Токен восстановления

В случае когда администраторская учетная запись заблокирована попытками атакующего подобрать к ней пароль, администратор может предъявить токен восстановления системе для входа. Для этого нужно выполнить запрос POST /auth/recovery со своим токеном. Это действие сбрасывает все блокировки и позволяет администратору системы войти в нее.

Все три механизма применяются только к парольному входу (POST /auth/login, SCRAM-SHA-256 поверх psql). Вход через SSO или аутентификация через токены эти механизмы не используют.

Чек-листы восстановления

Настройка токена восстановления

  1. Сразу после установки системы выпустите токен восстановления для учетной записи администратора по умолчанию:

    prostore user mint-recovery --username admin

  2. Сохраните токен в командном менеджере паролей вне основной системы. Команда показывает токен один раз, и Tengri не сможет показать его повторно.

  3. Повторите эти действия для каждой учетной записи, которой нужен способ восстановления. Общесистемного главного токена восстановления не предусмотрено — токены выпускаются по одному на пользователя.

Во время инцидента

  1. По журналу определите заблокированную учетную запись:
    account '<user>' blocked after N failed login attempts

  2. С доверенного клиента отправьте сохраненный токен на точку входа восстановления вместе с именем заблокированной учетной записи:

    curl -X POST https://<host>/auth/recovery \
  -H 'Content-Type: application/json' \
  -d '{"login": "<user>", "token": "<сохраненный-токен>"}'

  3. Сохраните recovery_token из JSON-ответа — это единственная копия следующего токена.

  4. Блокировка снимается автоматически.

После этого войдите обычным способом и смените пароль затронутого пользователя.

После инцидента

  1. Убедитесь, что новый токен восстановления сохранен в менеджере паролей.

  2. Просмотрите следующие строки журнала в окне инцидента:

    • recovery token used

    • recovery token rejected

    Каждая запись должна сопоставляться с известным оператором.

  3. Если исходный токен мог быть скомпрометирован (передан по ненадежному каналу, попал в запись экрана и т. п.), выпустите новый токен, чтобы аннулировать ротированную копию.

  4. Сопоставьте пороги защиты от подбора с наблюдаемым трафиком, в первую очередь эти:

    • TNGRI_LOGIN_THROTTLE_MAX_FAILURES

    • TNGRI_PASSWORD_POLICY_MAX_FAILED_LOGINS

    Повысьте их в случае необходимости.