Сообщить об ошибкеКороткий ответ
Аудит-логи фиксируют, кто, когда и какое именно действие выполнил в системе (вход, изменение прав, доступ к ресурсу, удаление объекта), в отличие от логов приложения, которые описывают работу самой бизнес-логики; аудит нужен для расследования инцидентов и подтверждения соответствия требованиям.
Как это работает подробнее
аудит-подсистема (например, Kubernetes audit log, CloudTrail в AWS) перехватывает каждый запрос к API с указанием субъекта (пользователь/сервис-аккаунт), действия, объекта и результата, и записывает это в неизменяемом (append-only) виде, отдельно от логов приложения.
Пример кода
security-example-447.json
{
"level": "Metadata",
"verb": "delete",
"user": {"username": "alice@example.com"},
"objectRef": {"resource": "deployments", "namespace": "prod", "name": "billing-api"},
"requestReceivedTimestamp": "2024-03-01T03:12:44Z"
}Что использовать на практике
- Практика. аудит-логи хранят отдельно от обычных логов, часто в выделенном хранилище с ограничением на изменение/удаление, и используют при расследовании инцидентов («кто удалил этот деплоймент в 3 ночи») и при подготовке к комплаенс-проверкам.
- Проверка. Ожидаемое поведение: такая запись в Kubernetes audit log позволяет точно установить, что именно пользователь alice@example.com удалил деплоймент billing-api в namespace prod в 03:12 — этого не покажет лог самого приложения billing-api, которое просто перестанет отвечать.
Подводные камни
- Ошибка. путать лог приложения («ошибка 500 при обработке запроса») с аудит-логом («пользователь X вызвал DELETE на ресурс Y»); не включать аудит вовсе, полагая, что логов приложения достаточно для расследований; хранить аудит-лог там же, откуда его может удалить тот же аккаунт, чьи действия он фиксирует.