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

Логирование — это подложка обнаружения

Прежде чем обнаружить атаку, сдержать инцидент или доказать в разборе, что произошло, событие должно где-то надёжно существовать. Лог — это не отладочное удобство, которое прикручивают для разработчиков, а сырьё, из которого построена каждая последующая защитная способность. Твой SIEM коррелирует строки логов. Твои алерты срабатывают на паттерны в строках логов. Твой таймлайн инцидента и есть последовательность строк логов. NIST SP 800-92 формулирует это прямо: управление логами — это дисциплина генерации, передачи, хранения и анализа записей, позволяющих восстановить связанную с безопасностью активность. Если событие не зафиксировано в момент, когда оно происходит, никакой умный тулинг постфактум его уже не восстановит.

Поэтому «что логировать» — решение архитектуры безопасности, а не вопрос удобства разработчика. Действия атакующего ложатся на наблюдаемые техники — их каталогизирует MITRE ATT&CK: доступ к учётным данным, повышение привилегий, эксфильтрация данных, обход защиты. Каждое из них оставляет след тогда и только тогда, когда нужное событие было инструментировано. Работа защитника — сделать так, чтобы каждое значимое действие порождало сигнал, на который потом можно среагировать. Недологируешь — и ты слепой; атакующий неделями работает в тишине. Перелогируешь не то — сольёшь сырые тела запросов, полные заголовки, секреты — и ты построил вторую утечку: гигантское поисковое хранилище учёток и PII, которое само теперь стало мишенью.

Что фиксировать: классы событий безопасности

Отбрось шум. События, стоящие своей цены хранения, — те, что реально нужны следователю или правилу алерта. В грубом порядке приоритета:

Заметь паттерн: ты логируешь связанное с безопасностью решение, а не каждую строку бизнес-кода. Удачный просмотр товара — шум. 403 на /api/admin/users — решение авторизации, достойное записи, потому что всплеск таких — это кто-то картографирует твою модель прав. Зрелый рефлекс — инструментировать узкие места: слой аутентификации, middleware авторизации, админ-обработчики, пути экспорта данных — один раз, централизованно, чтобы покрытие не зависело от того, вспомнит ли каждый автор фичи добавить вызов лога.

Контекст — это то, что делает строку доказательством

Лог со словами error: forbidden бесполезен через три недели. Строка обязана отвечать на пять вопросов следователя: кто, что, с-чем, когда, откуда. Это означает структурированное событие (JSON, а не свободный текст, который потом будешь парсить регэкспом), несущее как минимум: стабильный id актора (id пользователя или сервисного принципала — никогда просто отображаемое имя), действие, целевой ресурс и его id, авторитетную серверную метку времени, исходный IP и user-agent, correlation/request id, чтобы сшить запрос между сервисами, и исход (разрешено/отказано, успех/провал). 403 без id актора и id ресурса говорит, что что-то заблокировали; он не говорит, что тот же аккаунт только что заблокировали 400 раз за 90 секунд по 400 разным id счетов — а это и есть настоящий сигнал.

Жёсткое правило: что нельзя писать в лог никогда

Логи утекают. Их шлют в сторонние SIEM, реплицируют в дешёвое холодное хранилище, читают инженеры поддержки, индексируют для полнотекстового поиска и хранят годами. Поэтому секрет в логе — это секрет с максимально широким радиусом поражения и максимально долгим временем жизни. Считай лог полупубличным и никогда не пиши: пароли (даже «неверные» — они раскрывают паттерн пользователя и часто верный пароль с опечаткой), сессионные токены, API-ключи, JWT и bearer-заголовки, полные номера карт (PCI-DSS запрещает это прямо: хранить полный PAN в логах нельзя, а CVV не допускается вообще) и немаскированные PII сверх того, что нужно расследованию, — государственные id, полные медкарты, сырые заголовки Authorization. Механизм, причиняющий это, почти всегда — перезахват: кто-то логирует всё тело запроса или все заголовки «на всякий случай», и теперь каждый пароль и токен, что когда-либо прошёл, лежит в Elasticsearch.

Срок хранения: достаточно долго, чтобы расследовать, достаточно коротко, чтобы быть безопасным

Срок хранения — это реальный компромисс, а не дефолт «храним всё вечно». Держи логи слишком коротко — и не расследуешь пробой, о котором узнал лишь спустя месяцы, а это нормальный случай при времени пребывания в недели и раскрытиях, что приходят ещё позже. Держи слишком долго, в неправильной форме — и ты копишь растущую кучу PII, которая стоит денег на хранении, расширяет поверхность атаки и сталкивается с законом о минимизации данных (принцип ограничения хранения в GDPR). Зрелый ответ — многоуровневый: горячее искомое хранилище для свежей активности (часто ~90 дней), чтобы обнаружение и живое расследование были быстрыми; более дешёвое неизменяемое холодное/архивное хранилище на тот более долгий горизонт, что требует твой комплаенс (часто год и более для аудита и регулируемых данных); и агрессивная минимизация или псевдонимизация PII внутри этих логов, чтобы архив был полезен для форензики, не становясь обузой. И критически — делай логи безопасности append-only / tamper-evident: стандартный ход атакующего после компрометации — удалить логи, что его раскроют, поэтому хранилище, на которое опирается следователь, должно быть таким, которое атакующий, добравшийся до сервера приложения, не сможет тихо переписать.