Логирование безопасности: что записывать и на что настраивать алерты

Коротко

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

• фиксированный список событий безопасности, которые пишет само приложение;
• структурированные записи с одинаковыми полями;
• централизованное хранилище, которое атакующий или обычный админ не может тихо отредактировать;
• небольшой набор алертов, которые кто-то действительно читает.

События, которые стоит логировать

Аутентификация

• успешные и неудачные входы, выходы;
• включение и отключение 2FA, неверные коды;
• смена пароля и запросы сброса;
• блокировки и разблокировки аккаунтов.

Авторизация и доступ

• отказ в доступе (403) к эндпоинтам или объектам;
• попытки открыть чужие записи;
• создание API-ключей, их использование из нового места, отзыв.

Действия администраторов

• выдача и снятие ролей и прав;
• создание, блокировка, удаление пользователей;
• изменение настроек оплаты, безопасности, интеграций;
• вход «под пользователем» сотрудниками поддержки.

Операции с чувствительными данными

• массовые выгрузки и экспорт;
• массовый просмотр персональных данных;
• удаление большого числа записей.

Системные сигналы

• необычно частые ошибки валидации;
• ошибки проверки подписи вебхуков;
• ошибки приложения в проверках безопасности.

Как выглядит хорошая запись

Используйте структурированные логи (JSON) с одинаковыми полями:

{
  "ts": "2026-03-14T09:21:07Z",
  "event": "auth.login_failed",
  "actor_id": null,
  "target": "user:4812",
  "ip": "203.0.113.17",
  "user_agent": "Mozilla/5.0 ...",
  "request_id": "a1b2c3",
  "result": "failure",
  "reason": "bad_password"
}

Ключевые поля: время в UTC, название события, кто (пользователь или сервис), над чем, IP-адрес, результат и request ID, чтобы связать лог с трейсами приложения.

Что нельзя писать в логи

• Пароли, в том числе неверные из неудачных попыток — часто это настоящий пароль с опечаткой.
• Токены сессий, JWT, API-ключи, ссылки сброса, OTP-коды, заголовки Authorization и cookies.
• Полные номера карт и CVV. Если нужно — только маскированный вид.
• Секреты из переменных окружения и конфигов.
• Лишние персональные данные: паспортные номера, полные тела запросов с личными полями.

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

Хранение и сроки

• Отправляйте логи в центральную систему вне сервера приложения, чтобы взломанный сервер не мог стереть следы.
• Ограничьте доступ к логам и логируйте сам доступ к ним.
• Синхронизируйте время (NTP) на всех серверах.
• Срок хранения зависит от законов, договоров и отраслевых стандартов, которые к вам применимы (например, PCI DSS для карточных платежей), а также от того, сколько атака может оставаться незамеченной. В логах есть персональные данные, поэтому законы о персональных данных тоже ограничивают, как долго и где их хранить. Свежие логи держите в быстром поиске, старые — в дешёвом архиве.

Алерты, которые ловят атаки рано

Правила настройки:

• Мало и по делу: у каждого алерта есть ответственный и короткая инструкция «что делать».
• Подстраивайте пороги под нормальный трафик: шумные алерты сначала глушат, потом игнорируют.
• Критичные алерты — в канал, который читают люди, а не только в папку почты.
• Регулярно проверяйте алерты, вызывая их намеренно.

Частые ошибки

• Логируются только ошибки, а не успешные значимые действия.
• Логи лежат только на том же сервере, что и приложение.
• Свободный текст, по которому нельзя искать и агрегировать.
• В продакшене оставлен debug-режим с полными телами запросов.