Логирование и аудит действий пользователей: журнал, который отвечает «кто, что и когда»

Писать всё подряд бесполезно: объём растёт, а нужное тонет. Делим события по цене пропуска. Если событие не записалось и это нельзя исправить задним числом, оно относится к первому классу.

• Первый класс — деньги, права и удаления. Изменение цены и условий, выдача и отзыв ролей, удаление записей, массовая выгрузка, действия поддержки от имени клиента. Запись идёт в одной транзакции с операцией: нет записи — нет и действия.
• Второй класс — доступ. Входы и неудачные попытки, отказы в правах, открытие карточек с защищёнными данными, скачивание документов. Запись допустимо отправлять через очередь, но потеря ограничена и оговорена.
• Третий класс — всё остальное. Открытие справочников, смена вкладок, нажатия. Мы не пишем их в журнал аудита: для этого есть аналитика продукта, у неё другие читатели и другие правила.

Справочник действий вместо свободного текста

Каждое событие получает код из справочника: «заказ.цена.изменение», «роль.выдача», «выгрузка.клиентов». Справочник лежит в репозитории, новое событие появляется вместе с кодом и проходит ревью. Благодаря кодам журнал становится данными: отчёт «все выдачи ролей за месяц» делается запросом.

Что в журнал не попадает

Пароли, коды подтверждения, токены сессий, содержимое форм и значения чувствительных полей. Достаточно факта изменения и идентификатора записи. Подробнее о разделении данных и журнала — на странице защиты персональных данных; структура записи разобрана в статье «Как вести журнал действий пользователей».

В коде: слой бизнес-операций

Основной вариант, если код ваш и менять его можно. Запись делается в одном слое, где выполняются осмысленные действия, а не в каждом обработчике. Видны смысл и автор, в том числе «от имени» кого действовали. Минус: правки в базе в обход приложения не видны.

В базе: триггеры или захват изменений

Подходит для старых систем и для случаев, когда код менять нельзя. Любая правка таблицы в любом режиме попадает в журнал. Минус: база видит «строка изменена», но не знает, какой пользователь приложения это сделал, пока его идентификатор не передан в сеанс. Часть систем, например 1С, ведёт собственный журнал регистрации; мы подключаем его выгрузку в общий журнал, а не заменяем его.

На входе: шлюз или прокси

Фиксирует все обращения к программному интерфейсу: кто, к чему, с каким результатом. Не требует правок в коде, но видит только адреса и статусы. Подходит для первого шага и для API, дополняя запись в слое операций. Защита самих интерфейсов описана на странице защиты API.

Какой вариант выбрать, решается на обследовании по трём признакам: можно ли менять код, есть ли доступ в обход приложения, насколько важны значения «до и после».

Администратор организации-клиента видит действия только своих сотрудников: кто вошёл, кто скачал документы, кто пригласил нового пользователя, кто изменил реквизиты. Раздел содержит фильтры по сотруднику, действию и периоду и выгрузку результата.

Главное требование — изоляция: клиент не должен увидеть записи другой организации или сотрудников поддержки вместе с их служебными заметками. Это проверяется отдельным тестом, как и права в кабинете. О разделении данных клиентов см. статью про мультиарендность в SaaS и страницу личного кабинета. Вход поддержки «от имени клиента» записывается и показывается клиенту, если это решено на обследовании.

Журнал аудита отвечает на вопрос «кто что сделал». Вопрос «работает ли сервис и где он тормозит» решают метрики, технические журналы и трассировка, см. страницу мониторинга веб-сервисов. Оба набора данных связывает сквозной номер запроса, но хранятся они раздельно.

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

Журнал фиксирует совершённые действия и не заменяет разграничение прав и вход: за вход отвечает единый вход и двухфакторная аутентификация.