Создать сервис журнала аудита действий пользователей для комплаенса

Мы выросли до ситуации, когда не в состоянии внятно ответить проверяющим и крупным клиентам на простой вопрос: кто именно совершил действие и в какой момент. Сегодня следы операций разбросаны по общим логам сервиса, а те логи перезаписываются, тонут в отладочных сообщениях и легко теряются или правятся вручную. Полноценным журналом аудита это назвать нельзя, и из-за этого мы уже теряем контракты. Нам нужен отдельный сервис, который трактует каждое существенное действие пользователя или администратора как самостоятельную запись события: кто совершил, какое действие, над каким объектом, в какое время, с какого адреса или клиента и с описанием того, что конкретно поменялось. Подчеркну: это не общее логирование и не система замера производительности, и это не страница состояния сервиса. Нас интересует надёжная летопись пользовательских действий для комплаенса и разбора инцидентов безопасности.

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

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

— Структура записи: автор, действие, объект, время, источник, детали изменения
— Хранилище только на дописывание, устойчивое к подмене (хеш-цепочка либо аналог)
— Интерфейс приёма событий и небольшая библиотека-клиент для наших сервисов
— Поиск и отбор по автору, действию, объекту, датам и полному тексту
— Гибкие сроки хранения и юридическая заморозка удаления
— Доступ на чтение по ролям с фиксацией самого обращения к журналу
— Проверяемый экспорт для аудиторов с описанием целостности выгрузки