Block a user after a number of failed login attempts

added backlog questionable + 1 deleted label

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

changed the description

Pre-RFC for auth attempts tracking.

Мотивация

Сертификация требует от СУБД учета удачных и неудачных попыток аутентификации, а также возможности реагировать на неудачные попытки через блокирование учетных записей (на некоторый срок и/или до разблокирования администратором).

Особенности Picodata

Следует отметить, что нормативные документы сертификации не разделяют СУБД на централизованные и распределенные. Требования хорошо перекладываются на классические СУБД (например, postgres), которые масштабируются вертикально, но могут не учитывать нюансы распределенных систем, например, накладные расходы на общение и синхронизацию узлов кластера при принятии решений.

Стратегии реализации

Локальная блокировка

Самый очевидный вариант -- следить за попытками аутентификации локально на каждом узле кластера, не передавая информацию о неудачных попытках на другие узлы. Если предположить, что блокировка происходит после 3-5 неудачных попыток, получаем систему со следующими свойствами:

При долбежке в один узел блокировка произойдет очень быстро.
При беспорядочной долбежке в разные узлы количество попыток кратно увеличится, но при должных параметрах пароля шансы его подобрать будут крайне малы.
Если добавлять записи о каждой попытке аутентификации в логи, агрегация логов с каждого узла позволит следить за релевантными событиями безопасности.

Вопрос только в том, как на такое предложение отреагирует ФСТЭК.

Глобальная блокировка

Если документы подразумевают, что учетную запись необходимо блокировать на всех узлах кластера, для этого потребуется:

Как минимум, после регистрации N неудачных попыток на одном узле оповещать остальные;
Вероятно, вести глобальный учет всех неудачных попыток, что очень дорого.

Еще один фактор -- скорость распространения решения о блокировке:

Оптимистичный вариант: хорошо, если можно не гарантировать одновременную блокировку на всех узлах. В таком случае можно сначала принять решение о блокировке локально, а затем асинхронно передать эту информацию на остальные узлы (например, раз в 5 минут).
Пессимистичный вариант: блокировать учетную запись нужно (более-менее) одновременно на всех узлах кластера. В любом случае останется небольшое окно после принятия решения о блокировке, поскольку эту информацию нельзя передать мгновенно.

Замечание: этот подход можно успешно комбинировать с локальной блокировкой.

Важно учитывать, что аутентификация не должна быть завязана на кворум кластера! Иными словами, критические пути механизма аутентификации не должны зависеть от гарантий записи в raft журнал и подтверждения со стороны N/2 + 1 узлов.

Идеи

Выбор стратегии определяет, куда должна быть записана метка о блокировке учетной записи.
- В локальный спейс для локальной блокировки, уж это понятно.
- Локальную блокировку можно делать через grant/revoke (@rosik).
- Для глобальной блокировки все сложнее, потому что кворум.
После каждой неудачной попытки можно наращивать время локального кулдауна.

TODO: нагенерировать еще идей.

assigned to @funbringer

mentioned in issue #349 (closed)

added 1 deleted label

Дизайн фичи в итоге сросся в Google Docs — Docs — Access control — Блокировка учетных записей пользователей. Можно кодить.

removed questionable label

assigned to @e-ivkov and unassigned @funbringer

mentioned in merge request !723 (merged)

mentioned in issue #392 (closed)

changed milestone to %23.12.0

closed with merge request !723 (merged)

mentioned in issue #894 (closed)

mentioned in issue #922 (closed)