Материал

Журнал аудита: как сделать его полезным для расследования инцидентов

Опубликовано: 16 июня 2026 Время чтения: 19 мин

Большинство компаний ведут логи. Мало кто успевает ими воспользоваться в нужный момент

Зачем вообще говорить о журналах аудита в 2025 году

Казалось бы, аудит-логи — тема давно закрытая. У каждой зрелой команды есть SIEM, retention policy и дашборд. Но когда происходит реальный инцидент, картина меняется: «у нас не было этих логов», «они хранились только три дня», «формат не стандартизирован, парсер не справился» — это типичные фразы из постмортемов.

Отчёт IBM «Cost of a Data Breach 2024» фиксирует: средняя стоимость утечки данных достигла $4,88 млн, что на 10% больше, чем годом ранее [1]. При этом среднее время обнаружения инцидента составило 204 дня, а на локализацию ушло ещё 73 дня [2]. Компании, которые использовали AI и автоматизацию в процессах безопасности, выявляли и сдерживали угрозы почти на 100 дней быстрее конкурентов — в значительной мере за счёт качественных логов, пригодных для автоматического анализа [3].

Если журнал аудита — это просто поток текста без структуры, без контекста и без централизованного хранения, он не поможет ни следователю, ни детектирующей системе. Эта статья о том, как выстроить логирование так, чтобы оно реально работало в момент расследования.

Что такое журнал аудита: строгое определение

Журнал аудита (audit log, audit trail) — это хронологическая, защищённая от несанкционированных изменений запись событий в информационной системе, фиксирующая, кто выполнил действие, что именно было сделано, в какой момент, на каком ресурсе и с каким результатом [4].

Ключевые атрибуты, отличающие аудит-лог от общего лога приложения:

Неизменяемость (immutability) — запись не может быть изменена после создания.
Хронологическая упорядоченность — события следуют в порядке их наступления с точным временем.
Привязка к субъекту — каждое действие связано с конкретным пользователем, сервисным аккаунтом или процессом.
Охват критичных операций — фокус не на отладочной информации, а на событиях, значимых для безопасности, комплаенса и подотчётности.
Доказательная сила — лог должен выдерживать проверку при внутреннем расследовании, аудите или судебном разбирательстве.

DevSecOps School формулирует это лаконично: аудит-лог — это «бортовой самописец» (black box) цифровой системы [5]. Именно с этой аналогией удобно работать при проектировании: что должен воспроизвести бортовой самописец, чтобы реконструировать произошедшее?

Почему логи не помогают: пять системных сбоев

OWASP Top 10:2025 выделяет «Сбои безопасного логирования и мониторинга» как самостоятельный класс уязвимостей (A09:2025) [6]. Это не случайно: именно они превращают управляемый инцидент в дорогостоящий хаос.

Вот пять наиболее распространённых причин, по которым логи оказываются бесполезными в момент расследования.

Первый сбой — логируются только успехи. Если система записывает успешные входы, но не фиксирует неудачные попытки аутентификации, расследование брутфорса или credential-stuffing-атаки становится невозможным. Именно это произошло в известном инциденте с Target в 2013 году: поддержание логов неудачных попыток входа могло дать ранний сигнал [7].

Второй сбой — отсутствие контекста. Запись ERROR: access denied бесполезна без идентификатора пользователя, IP-адреса источника, имени ресурса и временной метки с часовым поясом [8]. Контекст — это всё, что позволяет следователю восстановить цепочку событий.

Третий сбой — локальное хранение. Злоумышленник, получивший привилегированный доступ, первым делом удаляет или изменяет локальные логи. 14 ноября 2024 года Cloudflare потерял примерно 55% клиентских логов за три с половиной часа из-за каскадного отказа в pipeline — без удалённого резервного хранилища эти события просто исчезли [9].

Четвёртый сбой — несогласованные форматы. Если каждый сервис пишет логи в своём формате, их корреляция требует предварительной нормализации, которая занимает время и вводит ошибки [10]. При расследовании инцидента в компании с микросервисной архитектурой команды потратили дни только на то, чтобы выровнять форматы из десятков сервисов.

Пятый сбой — неправильное время. Несинхронизированные часы на разных серверах делают невозможным корректное построение таймлайна. Если события в разных логах расходятся на минуты или часы, причинно-следственные связи теряются.

Что обязательно логировать: минимально достаточная модель

NIST SP 800-92 и его обновлённый драфт 2023 года (SP 800-92 Rev.1) определяют принципы управления логами безопасности для государственных систем США, которые стали де-факто стандартом и для коммерческого сектора [11]. На практике «что логировать» определяется моделью угроз конкретной организации, но есть категории, универсальные для большинства сред.

По данным инцидент-ревью 2024–2025 годов, чаще всего при расследованиях отсутствуют следующие типы логов [12]:

Логи аутентификации — успехи и неудачи входа, смена учётных данных, выдача токенов. Без них невозможно ответить на вопрос «кто был первым».

Логи запуска процессов — какие исполняемые файлы запускались, с какими аргументами и от чьего имени. Без них расследование теряет причинно-следственную видимость.

Логи сетевой активности — соединения между хостами, внешние подключения, объём переданных данных. Без них невозможно установить lateral movement или факт эксфильтрации.

DNS-логи — запросы к внешним доменам. Именно DNS-запросы часто раскрывают C2-инфраструктуру атакующего. «Нам нужны были DNS-логи, чтобы увидеть, к каким C2-серверам обращалась машина. "Мы их не собираем"» — реальная цитата из постморема одного из расследований [13].

Логи изменений конфигурации — кто и что изменил в правилах файрвола, политиках, ролях и разрешениях. Атакующие часто ослабляют защитные контроли ещё до начала основного действия.

К этому базовому набору стоит добавить:

изменения привилегий и членства в группах;
создание, изменение и удаление учётных записей;
доступ к чувствительным данным и их экспорт;
операции с резервными копиями;
события безопасности из EDR, антивирусов, IDS/IPS.

Принцип здесь не «логировать всё» (это путь к alert fatigue и огромным расходам на хранение), а «логировать всё, что нужно для ответа на вопросы следователя».

Анатомия качественной записи в журнале аудита

Каждая запись должна самостоятельно отвечать на шесть вопросов: кто, что, когда, где, над чем и с каким результатом. Sonar и DevSecOps School определяют типовой набор полей [4, 5]:

Временная метка (timestamp) — в UTC, с точностью до миллисекунды, в формате ISO 8601 (2025-06-01T14:22:09.142Z). Хаотичные или локальные временные зоны — источник ошибок при корреляции.

Идентификатор субъекта (actor) — user_id, email, service account name. Не имя для отображения — оно меняется — а неизменяемый идентификатор.

Действие (action) — глагол в стандартизированной форме: user.login, file.delete, role.grant. Свободный текст типа «пользователь что-то сделал» бесполезен.

Ресурс (resource/target) — объект, над которым выполнялось действие: file path, resource ID, endpoint.

Результат (outcome) — success или failure, плюс код ошибки при неудаче.

Контекст запроса — IP-адрес источника, user agent, session ID, request ID для трассировки в распределённых системах.

Среда (environment) — имя сервиса, версия, datacenter, region. Критично в микросервисных и мультиклаудных архитектурах.

Пример качественной JSON-записи:

{
  "timestamp": "2025-06-01T14:22:09.142Z",
  "event_type": "user.login",
  "actor": {
    "user_id": "usr-7890",
    "email": "ivanov@company.ru"
  },
  "resource": "/admin/settings",
  "outcome": "failure",
  "error_code": "INVALID_MFA_TOKEN",
  "source_ip": "203.0.113.55",
  "user_agent": "Mozilla/5.0 ...",
  "session_id": "sess-a1b2c3",
  "service": "auth-service",
  "environment": "production"
}

Структурированный JSON напрямую совместим с SIEM-системами и позволяет строить фильтры, алерты и корреляционные правила без ручного парсинга. В сфере безопасности также широко применяются форматы CEF (Common Event Format) и LEEF (Log Event Extended Format), специально адаптированные для интеграции с SIEM-платформами типа IBM QRadar, Splunk и ArcSight [14].

Целостность логов: почему неизменяемость — не опция

Лог, который можно изменить, не является доказательством. Это особенно важно при расследованиях с участием инсайдеров или при атаках, где злоумышленник получил привилегированный доступ.

Известный вектор: атакующий удаляет Windows Event Log, выгружает Sysmon-драйвер и отключает event tracing — всё это делается до начала основных действий, чтобы скрыть следы lateral movement. В реальном случае с FortiGate в 2025–2026 годах именно недостаточный срок хранения логов не позволил установить первоначальный вектор проникновения [15].

Два основных технических подхода к обеспечению целостности:

WORM-хранилище (Write Once, Read Many) — записи физически или программно блокируются от изменения после первой записи. Пример: Amazon S3 с функцией Object Lock. Это наиболее практичный подход для большинства организаций [16].

Криптографическое связывание (hash chaining) — каждая запись содержит хеш предыдущей, образуя верифицируемую цепочку. Любое изменение прошлой записи разрушает цепочку и сразу становится заметным [17]. Подход, инспирированный блокчейн-технологиями, обеспечивает математическое доказательство целостности.

Дополнительные меры:

немедленная пересылка логов на изолированный, централизованный log-сервер (не хранить только локально);
шифрование при хранении (AES-256) и при передаче (TLS 1.3);
мониторинг целостности файлов (FIM) на директориях с логами;
раздельный доступ: кто управляет системами — не должен иметь права удалять логи;
логирование самого доступа к логам — кто читал, экспортировал, изменял retention-политику [18].

Политика хранения: сколько держать и в каком формате

Срок хранения — это компромисс между требованиями регуляторов, временем обнаружения угроз и стоимостью хранения.

IBM «Cost of a Data Breach 2024» зафиксировал: среднее время обнаружения инцидента составляет 204 дня. Это значит, что при retention менее семи месяцев организация может столкнуться с ситуацией, когда логи начального заражения уже удалены к моменту обнаружения инцидента. Blumira рекомендует устанавливать срок хранения как минимум вдвое больше ожидаемого времени обнаружения [19].

Регуляторные минимумы по основным стандартам [20]:

PCI DSS 4.0 — 12 месяцев, из них 3 месяца должны быть немедленно доступны для анализа.
HIPAA — 6 лет для логов, связанных с защищёнными медицинскими данными.
SOX (Section 802) — минимум 5 лет, SEC (Section 103) — 7 лет для аудиторских рабочих документов.
GDPR — конкретный срок не установлен, регулятор требует обосновать необходимость хранения; на практике — 1–3 года.
NIS 2 — 18 месяцев для логов безопасности.
ISO 27001 — рекомендует не менее 12 месяцев.

Если организация попадает под несколько регуляторов одновременно, применяется принцип наиболее строгого требования: при пересечении HIPAA и SOX выбирается 7-летний срок SOX, который автоматически покрывает HIPAA [21].

Практически удобная стратификация хранения:

«горячее» хранилище (1–3 месяца) — быстрый поиск, интеграция с SIEM, немедленный доступ при инциденте;
«тёплое» хранилище (3–12 месяцев) — объектное хранилище с индексированием, доступ за минуты;
«холодный» архив (свыше 12 месяцев) — дешёвое хранилище, доступ за часы, используется при комплаенс-аудите или судебных запросах.

Централизация и SIEM: от разрозненных логов к расследуемой картине

Отдельные логи из разных источников — это не система. Расследование инцидента в среде с децентрализованными логами сравнимо с попыткой собрать пазл, когда половина деталей хранится в разных комнатах, каждая в своей упаковке.

SIEM (Security Information and Event Management) — центральная платформа для сбора, нормализации и корреляции событий из всех источников инфраструктуры [22]. Корреляционные правила позволяют автоматически связывать разрозненные события в инцидент: например, цепочку «неудачный вход → успешный вход через 30 секунд → изменение привилегий → доступ к финансовым данным» можно обнаружить автоматически, если все четыре события нормализованы в общую схему.

На российском рынке востребованы как отечественные решения (Solar JSOC SIEM, KUMA от «Лаборатории Касперского», R-Vision SIEM, MaxPatrol SIEM), так и международные платформы (Splunk, IBM QRadar, Microsoft Sentinel). Ключевые требования при выборе не изменились: производительность сбора, качество встроенных правил корреляции, возможность кастомизации и наличие готовых парсеров под используемые в организации источники [23].

Централизация также означает необходимость нормализации форматов. Когда один сервис пишет user_id, а другой — userId или account_id, автоматическая корреляция ломается. Стандартизация схемы логов — это инфраструктурное решение, которое принимается до того, как всё написано, а не после инцидента.

Журнал аудита в контексте расследования: от таймлайна к Root Cause

Хорошее расследование инцидента начинается с восстановления таймлайна — последовательности событий с точным временем. Именно здесь качество логов проявляется ярче всего.

Типичный сценарий расследования и вопросы, на которые должен отвечать журнал аудита:

Начальный доступ: Когда и каким образом атакующий впервые оказался в системе? Ответ: логи аутентификации, VPN, SSO, OWA.

Разведка: Какие ресурсы исследовал атакующий, прежде чем действовать? Ответ: логи HTTP-запросов, DNS, LDAP-запросов к Active Directory.

Повышение привилегий: Какие учётные записи или роли были затронуты? Ответ: логи изменения групп, выдачи токенов, sudo-команд, Event ID 4672 в Windows.

Lateral movement: Как атакующий перемещался между системами? Ответ: сетевые логи, RDP-сессии, WMI-события, Event ID 4624 с типом 3 (network) и типом 10 (RDP).

Persistence: Какие механизмы закрепления установил атакующий? Ответ: логи изменений реестра, scheduled tasks, новых сервисов, изменений SSH authorized_keys.

Эксфильтрация: Что и куда было вынесено? Ответ: сетевые логи объёма трафика, FTP/SCP/HTTPS-логи, DNS-логи.

Действие на цели: Что именно было скомпрометировано или зашифровано? Ответ: логи файловых операций, изменений БД, резервного копирования.

Этот подход согласуется с фреймворком MITRE ATT&CK, который систематизирует тактики и техники атакующих [24]. Каждая техника ATT&CK имеет соответствующие события в логах — это позволяет заранее проектировать покрытие логирования относительно модели угроз.

Ещё один инструмент проектирования — Cyber Kill Chain (Lockheed Martin): каждая фаза цепочки должна оставлять следы в логах. Если хотя бы одна фаза не покрыта, атакующий может пройти её незамеченным.

Типичные ошибки при внедрении журнала аудита

Логировать «всё подряд» без приоритизации. Это приводит к огромным объёмам шума, высоким расходам на хранение и SIEM, а также к alert fatigue — состоянию, когда аналитики перестают реагировать на сигналы из-за их количества [25]. Правильный подход: сначала модель угроз, затем — что именно нужно видеть, чтобы детектировать соответствующие TTP.

Не тестировать полноту логирования. Многие организации уверены, что логи собираются, пока не наступает реальный инцидент. Red team-упражнения, tabletop exercises и регулярная проверка покрытия — обязательная часть программы [26].

Логировать чувствительные данные. CWE-532 описывает вставку паролей, токенов, номеров карт и PII в лог-файлы [9]. Это нарушает GDPR, PCI DSS и создаёт вторичный вектор утечки.

Не обновлять политику после инцидентов. Если playbook и модель логирования не меняются после каждого инцидента, инцидент не использован как источник улучшений. Постмортем должен включать раздел «что мы не смогли увидеть в логах и почему».

Не иметь процедуры извлечения и предоставления логов. При юридическом запросе или внешнем аудите нужно быстро предоставить логи в приемлемом формате. Отсутствие такой процедуры — дополнительный риск.

Забывать о логировании доступа к самим логам. Chain of custody — цепочка хранения доказательств — требует фиксации каждого обращения к лог-файлам: кто читал, экспортировал или менял retention-политику [18].

Чек-лист для команды: что проверить прямо сейчас

Готовность системы логирования к расследованию инцидентов можно проверить по следующим пунктам:

Все критичные источники (auth, сеть, DNS, изменения конфигурации, файловые операции) собираются в централизованное хранилище?
Форматы стандартизированы (JSON, CEF, syslog RFC 5424) — одна схема для всех сервисов?
Временны́е метки в UTC, часы синхронизированы по NTP?
Логи хранятся вне досягаемости атакуемых систем — удалённый SIEM или изолированное объектное хранилище?
Целостность обеспечена — WORM или hash chaining?
Срок хранения соответствует регуляторным требованиям и времени обнаружения угроз?
Есть корреляционные правила, покрывающие ключевые техники ATT&CK?
Последний раз полнота покрытия логирования проверялась менее шести месяцев назад?
Есть документированная процедура предоставления логов по запросу следствия или аудитора?
В логах не хранятся пароли, токены, полные номера карт и другие чувствительные данные?

Будущее: наблюдаемость, AI и конвергенция с security-данными

Несколько трендов, которые уже влияют на практику аудит-логирования:

Конвергенция observability и security. Традиционные логи в cloud-native средах становятся частью более широкого стека — метрики, трейсы, профили (MELT). Для расследований это означает возможность коррелировать security-события с производительностью и поведенческими паттернами в единой платформе [27].

ML-анализ аномалий. Вместо заранее написанных правил корреляции системы всё чаще используют базовые поведенческие модели и выявляют отклонения автоматически. По данным IBM, использование AI и автоматизации снизило средние расходы на брешь до $3,84 млн против $5,72 млн у компаний без этих технологий [3].

Криптографически верифицируемые логи. Подход, вдохновлённый блокчейном, — log entries с hash chaining — позволяет математически доказывать целостность цепочки событий. Это снимает вопросы к доказательной силе логов в юридических процессах [17].

Логирование AI-агентов. По мере того как AI-агенты становятся частью разработки и операций, их действия тоже требуют полноценного аудит-трейла: какой агент, от чьего имени, какой инструмент вызвал и с каким результатом [28].

Журнал аудита и контроль AI-кодинга

Если ваша команда использует AI-ассистенты для генерации кода, журнал аудита становится важным элементом не только security operations, но и контроля самого процесса разработки.

AI пишет быстро — но PR-ревью часто не успевает за скоростью генерации. Новая зависимость, изменение конфигурации или миграция базы данных, добавленные AI, могут незаметно для команды попасть в production. Именно здесь в дополнение к журналу аудита уместен слой контроля до merge и релиза — такой как HighVibe, который анализирует конкретное изменение в коде, конфигурации и зависимостях в момент PR, объясняет риск простым языком и предлагает следующий шаг. Это не замена аудит-логам, а дополнительный контрольный слой, который закрывает окно между «написано» и «задетектировано в production».

Заключение

Журнал аудита — это не артефакт комплаенса, который создаётся для проверяющих. Это инструмент расследования, который должен быть готов к использованию в день X — в тот день, когда у команды будет 204 дня наблюдения за инцидентом или меньше, чтобы ответить на вопрос «что произошло».

Полезный журнал аудита строится на трёх опорах: правильный состав событий (что логировать), правильная структура (как логировать) и правильная инфраструктура (где хранить и как защищать). Ни одна из них не компенсирует отсутствие других.

Начать можно с трёх шагов: утвердить перечень критичных источников логов и проверить, что они реально собираются в одном месте; стандартизировать схему записей; установить политику хранения с учётом регуляторных требований и среднего времени обнаружения инцидентов в вашей индустрии.

Источники

[1] IBM Security — "Cost of a Data Breach Report 2024" — https://www.ibm.com/think/insights/whats-new-2024-cost-of-a-data-breach-report

[2] BigID — "The 8 Hidden Costs of a Data Breach: Insights from the 2024 IBM Report" — https://bigid.com/blog/2024-ibm-report-data-breach-insights/

[3] Abnormal AI — "IBM Cost of a Data Breach Report: AI + Automation Key Findings" — https://abnormal.ai/blog/ibm-cost-of-a-data-breach-report

[4] Sonar — "Audit Logging Best Practices, Components & Challenges" — https://www.sonarsource.com/resources/library/audit-logging/

[5] DevSecOps School — "What is Audit Logs? Meaning, Architecture, Examples, Use Cases (2026 Guide)" — https://devsecopsschool.com/blog/audit-logs/

[6] OWASP — "A09:2025 Security Logging and Alerting Failures" — https://owasp.org/Top10/2025/A09_2025-Security_Logging_and_Alerting_Failures/

[7] Medium / JSOC IT BLOG — "Logs You Don't Collect — The Evidence You'll Wish You Had" — https://medium.com/@jsocitblog/logs-you-dont-collect-the-evidence-you-ll-wish-you-had-7ce84a977cc3

[8] Medium / InstaTunnel — "Insufficient Logging and Monitoring: The Blind Spot That Hides Breaches for Months" — https://medium.com/@instatunnel/insufficient-logging-and-monitoring-the-blind-spot-that-hides-breaches-for-months-222a18616442

[9] SecureLayer7 — "OWASP A09: Security Logging And Monitoring Failures Explained" — https://blog.securelayer7.net/a09-security-logging-and-monitoring/

[10] HyreLog — "The Cost of Poor Audit Logging: Real Incidents and What They Teach Us" — https://www.hyrelog.com/blog/cost-of-poor-audit-logging

[11] NIST — "SP 800-92 Rev.1 (Draft): Cybersecurity Log Management Planning Guide" — https://csrc.nist.gov/pubs/sp/800/92/r1/ipd

[12] Snare Solutions — "The 5 Logs Most Often Missing During Breach Investigations" — https://www.snaresolutions.com/the-5-logs-most-often-missing-during-breach-investigations/

[13] Medium / JSOC IT BLOG — "Logs You Don't Collect — The Evidence You'll Wish You Had" — https://medium.com/@jsocitblog/logs-you-dont-collect-the-evidence-you-ll-wish-you-had-7ce84a977cc3

[14] Zecurit — "Types of SIEM Logs & Formats Explained" — https://zecurit.com/knowledge-hub/siem-log-types-and-formats/

[15] SentinelOne — "FortiGate Edge Intrusions: Stolen Service Accounts Lead to Rogue Workstations and Deep AD Compromise" — https://www.sentinelone.com/blog/fortigate-edge-intrusions/

[16] Censinet — "Audit Trail Best Practices for Cloud Compliance" — https://censinet.com/perspectives/audit-trail-best-practices-cloud-compliance

[17] Confluent — "Real-Time Compliance & Audit Logging With Apache Kafka" — https://www.confluent.io/blog/build-real-time-compliance-audit-logging-kafka/

[18] Mattermost — "Compliance by Design: 18 Tips to Implement Tamper-Proof Audit Logs" — https://mattermost.com/blog/compliance-by-design-18-tips-to-implement-tamper-proof-audit-logs/

[19] Blumira — "5 Best Practices For Security Log Retention" — https://www.blumira.com/blog/5-best-practices-for-security-log-retention

[20] Edge Delta — "What is Log Retention? A Complete Guide to Policies and Practices in 2025" — https://edgedelta.com/company/knowledge-center/what-is-log-retention

[21] Claudia SOP — "Compliance Log Retention Requirements by Regulation" — https://claudiasop.com/blog/compliance-log-retention-requirements.html

[22] RT Solar — "SIEM-система: что это такое, как работает, функции, критерии выбора" — https://rt-solar.ru/products/solar_siem/blog/6147/

[23] Serverflow — "Технология SIEM: полный обзор архитектуры, корреляции событий и интеграции с SOAR" — https://serverflow.ru/blog/stati/tekhnologiya-siem-polnyy-obzor-arkhitektury-korrelyatsii-sobytiy-i-integratsii-s-soar/

[24] Medium / Kunal Nagra — "Tracing an Enterprise Breach: A Kill Chain & MITRE ATT&CK Walkthrough from Windows Logs" — https://medium.com/@kunalnagra19/tracing-an-enterprise-breach-a-kill-chain-mitre-att-ck-walkthrough-from-windows-logs-8f12c8df4161

[25] Cyberhaven — "What Is an Audit Log? Guide for Security Leaders" — https://www.cyberhaven.com/infosec-essentials/what-is-audit-log

[26] Orca Security — "Audit Logs: Complete Guide to Cloud Security Monitoring" — https://orca.security/glossary/audit-logs/

[27] Dynatrace — "Log auditing and log forensics benefit from converging observability and security data" — https://www.dynatrace.com/news/blog/log-auditing-and-log-forensics/

[28] arXiv — "Clawed and Dangerous: Can We Trust Open Agentic Systems?" (Audit Telemetry Example) — https://arxiv.org/pdf/2603.26221