Журналы аудита: что записывать, как сохранить их неизменность и кто может их читать

Что это

Упомянутый OWASP Logging Cheat Sheet требует, чтобы каждая запись фиксировала когда, где, кто и что: метки времени события и записи в лог, приложение и хост, идентификатор действующего пользователя или машины и её адрес источника, тип события, затронутый объект, результат и причину. В список событий, которые нужно логировать всегда, входят успешные и неуспешные попытки аутентификации, отказы авторизации, действия по администрированию пользователей, использование административных привилегий, доступ к чувствительным данным, использование и ротация ключей, изменения конфигурации. Журнал аудита — это та часть перечисленного, которая документирует действия, совершённые от имени конкретного субъекта (principal), и хранится именно как запись для истории, а не как вывод для отладки.

Почему это важно

Журнал аудита чего-то стоит только тогда, когда он полон по значимым действиям и не может быть незаметно отредактирован тем самым человеком, чьи действия он фиксирует. Собственный список атак на логи в cheat sheet включает блокирование записи или повреждение лога атакующим, чтобы замести следы, а также подмену записываемой идентичности, чтобы скрыть настоящего виновника.

Как применять

• Генерируйте события аудита на уровне приложения, где известны и субъект действия, и объект, в виде структурированных записей со стабильной схемой: actor, actor type, action, object type и id, outcome, reason, request id, метка времени в UTC.
• Записывайте actor как идентификатор, а не как отображаемое имя, и явно указывайте имперсонацию («администратор X действует от имени пользователя Y»).
• Не записывайте идентификаторы сессий, токены доступа, пароли, ключи или полные персональные данные; cheat sheet включает их в список данных, которые нужно исключать или маскировать.
• Оперативно передавайте записи в хранилище, которое само приложение изменить не может: таблицу только для добавления под ролью базы данных с правом только на запись, либо объектное хранилище с блокировкой на срок хранения. Упомянутый Amazon S3 Object Lock описывает модель «однократная запись — многократное чтение», чей режим compliance не даёт перезаписать или удалить объект никому на протяжении срока хранения.
• Добавьте признаки обнаружения подделки — например, цепочку хешей или периодические подписанные дайджесты — и проверяйте их по расписанию.
• Ограничьте доступ на чтение поимённо заданной группой, логируйте каждое чтение и периодически пересматривайте список привилегий, как того требует cheat sheet.
• Заранее определите срок хранения и удаляйте данные по расписанию; хранение данных аудита сверх нужного срока само по себе создаёт риск.

Подводные камни

Смешивание записей аудита с логами приложения, которые ротируются через неделю. Логирование намерения («запрошено удаление»), но не результата. Сообщения в свободной текстовой форме, по которым невозможно делать запросы. Доверие идентификатору пользователя, присланному самим клиентом, без проверки. Неизменяемый журнал, который никто ни разу не читает — вплоть до инцидента.