Добавление центрального журнала аутентификации в Discourse

Внести вклад Функция
1

Резюме

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

Детали

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

В качестве примера, провайдер локального входа может иметь следующий (неполный) список событий:

  • кто-то с [IP] не смог войти как пользователь fhqwhgads, который не существует
  • кто-то с [IP] не смог войти как пользователь supermathie, был ограничен по частоте запросов
  • кто-то с [IP] не смог войти как пользователь supermathie, но предоставил неверный пароль
  • кто-то с [IP] успешно вошел как пользователь supermathie, предоставив верный пароль
  • кто-то с [IP] не смог войти как пользователь supermathie, предоставив верный пароль, но требуется MFA для продолжения
  • кто-то с [IP] не смог войти как пользователь supermathie, предоставив верный пароль и неверный TOTP-код
  • кто-то с [IP] успешно вошел как пользователь supermathie, предоставив верный пароль и верный TOTP-код для токена vault-work

Проблема с использованием существующих логов (веб-логов) заключается в том, что за исключением события ограничения по частоте запросов, все они выглядят абсолютно одинаково ([200] POST /session HTTP/1.1). В лог не передается никакой смысл.

Проблемы

Существует опасение, что анонимные события будут генерировать записи в журналах, и необходимо найти баланс между этим и выявлением событий, интересных с точки зрения анализа SIEM, например, атак методом подбора паролей (password spraying).

Логирование ВСЕГО означает, что любой пользователь из Интернета может заполнить ваши логи… но спорно, является ли это реальной проблемой. Обратите внимание на пункт о хранении ниже — возможно, неудачные попытки входа будут храниться в журнале приложения в течение более короткого периода.

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

Вопросы

Хранение: хранить все вечно? 30 дней? 90 дней? удалять анонимные события раньше?

Аутентификация по API-ключу: следует ли логировать здесь вызовы с неверными пользовательскими или администраторскими API-ключами? Вероятно, да — это поможет в отладке.

Сколько параметров должно быть настраиваемым? Например, включение отладочных логов для всего или только для одного провайдера?

Особенности реализации

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

Предыстория

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

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

Для нас и администраторов сайтов было бы полезно иметь удобный способ просмотра этих логов из консоли Rails.

18 лайков