Аудит и логирование

Фиксация значимых действий для расследования инцидентов, соответствия и отчётности.

Что логировать

Аутентификация: успешные и неудачные входы, смена пароля, отзыв сессий, сброс пароля.
Доступ к данным: доступ к чувствительным сущностям (учётные записи, credentials metadata, ключи) — кто, когда, какое действие.
Изменения конфигурации: изменение прав, ролей, настроек безопасности, секретов (без записи самих секретов).
Административные действия: создание/удаление пользователей, изменение критичных настроек платформы.
Доступ к аудит-логам: кто и когда читал или экспортировал аудит-логи (защита от подчистки следов).

Неизменяемость: аудит-логи не редактируются и не удаляются в рамках retention; при необходимости только добавление (append-only).
Контекст: в каждой записи — timestamp (UTC), идентификатор субъекта (user_id, service account), действие, ресурс (тип + id), результат (успех/отказ), IP или источник запроса при необходимости.
Без PII в избытке: не логировать пароли, токены, полные персональные данные; при необходимости — хеш или маскирование; см. Logging.
Хранение и доступ: отдельный контур или разделение прав на чтение аудит-логов; retention по политике compliance; защита от несанкционированного доступа.

Structured logging: сервисы пишут структурированные логи (JSON); события аудита выделяются отдельным полем или направляются в отдельный sink (Loki, отдельная БД или SIEM).
События из сервисов: часть аудита может дублироваться в Kafka (отдельный топик audit.events) для централизованной обработки и долгосрочного хранения.
API Gateway: логирование отказов в аутентификации (401), доступа (403), rate limit; корреляция по request_id и trace_id.

На странице