«Без логов вы не просто не увидите атаку — вы не сможете доказать, что она была. Вы останетесь с утечкой данных, сломанными системами и не сможете ответить на главные вопросы регулятора: что произошло, когда и по чьей вине. Логи — это не просто данные, это ваша институциональная память и единственный беспристрастный свидетель в киберпространстве.»
Неизменяемая память системы: зачем нужны аудит-логи
Аудит-лог — это не просто файл с записями, а хронологически выверенный след любого события в информационной системе. В контексте российского регулирования (152-ФЗ, приказы ФСТЭК) они трансформируются из инструмента технической диагностики в юридически значимый артефакт. Их основная функция смещается с простого обнаружения проблем на обеспечение доказательной базы для внутренних расследований, отчётности перед регуляторами и, в крайнем случае, судебных разбирательств.
Без полноценных логов инцидент информационной безопасности превращается в «глухое» событие: факт ущерба есть, а установить источник, путь атаки и масштаб компрометации — невозможно. Система слепа к своим же прошлым состояниям.
Ключевые функции журналов аудита
- Детекция аномалий: Автоматический анализ потоков событий для выявления подозрительных паттернов, от брут-форса до внутренних утечек данных.
- Реконструкция инцидента: Точное восстановление последовательности действий злоумышленника: от точки входа до финальной цели.
- Формирование доказательств: Создание целостной и неизменяемой цепочки записей, которая будет принята при проверке ФСТЭК или в суде.
Обязательные требования к организации хранения
Требования регуляторов сформулированы не как рекомендации, а как обязательный минимум. Их несоблюдение ведёт к предписаниям и штрафам.
1. Полнота охвата источников
Собирать логи необходимо со всех корпоративных активов, формирующих цифровой след. Типичное упущение — сбор только с серверов, в то время как критическая активность может идти с рабочих станций или сетевого оборудования.
- Серверная инфраструктура (физическая, виртуальная, облачная)
- Пользовательские рабочие станции (особенно привилегированных учётных записей)
- Активное сетевое оборудование (межсетевые экраны, коммутаторы, маршрутизаторы)
- Системы управления идентификацией и доступом (Active Directory, FreeIPA, специализированные СУД)
- Критические бизнес-приложения (CRM, ERP, системы документооборота) и СУБД
2. Минимальный срок хранения
Установленный минимум в 90 календарных дней для оперативного хранения — это не случайная цифра. Она основана на статистике обнаружения инцидентов: многие атаки, особенно целевые, выявляются постфактум, спустя недели после проникновения. Три месяца — минимальный буфер для анализа.
Важно различать оперативное и архивное хранение:
| Тип хранения | Рекомендуемый срок | Назначение и нюансы |
|---|---|---|
| Оперативное (в SIEM) | ≥ 90 дней | Для ежедневного мониторинга и расследования свежих инцидентов. Требует быстрого поиска. |
| Долгосрочный архив | 1-5 лет и более | Для хранения по требованию отраслевых стандартов (например, для ПДн, финансовых данных). Логи, связанные с инцидентом, хранятся до его полного юридического закрытия. |
3. Обеспечение целостности и защиты от изменений
Это ключевое и наиболее часто нарушаемое требование. Логи, хранящиеся на том же сервере, где происходят события, бесполезны как доказательство — злоумышленник с привилегиями может их стереть или подделать.
Стратегия защиты строится на нескольких уровнях:
- Немедленная централизация: Передача логов в выделенную защищённую систему (SIEM) сразу после генерации, минуя локальное дисковое пространство источника.
- Запись на неизменяемые носители (WORM): Использование специализированных хранилищ или функций (Immutable Snapshots в облаке), которые технически блокируют удаление или изменение данных до истечения заданного срока.
- Криптографическое подтверждение целостности: Регулярное хеширование (например, алгоритмом ГОСТ Р 34.11-2012) потоков логов и архивов с возможностью последующей верификации.
- Жёсткое разграничение прав: Право на удаление или очистку логов должно быть выведено за пределы команд эксплуатации и предоставлено только узкой группе сотрудников службы информационной безопасности.
Что именно нужно логировать: ключевые категории событий
Объём логов может быть огромен. Политика логирования должна фокусироваться на событиях, которые имеют максимальную ценность для безопасности и расследований.
| Категория события | Конкретные примеры для логирования | Критичность для анализа |
|---|---|---|
| Аутентификация | Все попытки входа (успешные/неуспешные) с указанием учётной записи, источника (IP) и времени. События сброса пароля, блокировки учётной записи, использования многофакторной аутентификации. | ВЫСОКАЯ. Основа для обнаружения подбора учётных данных, компрометации и доступа из неожиданных мест. |
| Управление доступом | Попытки доступа к файлам, каталогам, базам данных (особенно отказы в доступе). Изменение списков контроля доступа (ACL). Использование привилегий администратора (sudo, runas). Доступ к конфиденциальным данным. | ВЫСОКАЯ. Позволяет отследить горизонтальное и вертикальное перемещение злоумышленника в сети после взлома. |
| Изменение конфигурации | Любые изменения правил межсетевого экрана, политик безопасности ОС, групповых политик. Установка или удаление программного обеспечения. Запуск/остановка критических системных служб или планировщиков задач. | КРИТИЧЕСКАЯ. Прямое указание на вредоносную активность, подготовку к атаке или установку бэкдора. |
| Сетевые события | Необычные исходящие соединения на нестандартные порты или в «подозрительные» географические регионы. Срабатывания систем обнаружения вторжений (IDS/IPS). Аномально большие объёмы исходящего трафика. Сканирование портов изнутри сети. | ВЫСОКАЯ. Ключевой источник для обнаружения компрометации, активности вредоносного ПО и каналов управления (C2). |
Практический план внедрения
- Инвентаризация и классификация: Составьте полный реестр активов, генерирующих логи. Определите, какие из них являются критическими с точки зрения 152-ФЗ и отраслевых требований.
- Разработка политики логирования: Документ, утверждённый руководством, должен однозначно определять: перечень источников, состав собираемых событий, сроки и места хранения (оперативное/архив), ответственных.
- Выбор и настройка платформы: Внедрение SIEM-системы или иного централизованного хранилища, способного принимать потоки данных со всех источников. Настройка правил парсинга и нормализации.
- Организация защищённого контура хранения: Настройка WORM-хранилища для оперативных данных и криптографически защищённого процесса создания долгосрочных архивов. Жёсткое ограничение прав доступа на запись/удаление.
- Внедрение контроля работоспособности: Регулярные (ежедневные/еженедельные) автоматические проверки:
- Поступление логов со всех критических источников.
- Соблюдение требуемого срока хранения (90+ дней).
- Отсутствие аномальных событий очистки или модификации журналов.
- Интеграция в процессы: Включение работы с логами в регламенты реагирования на инциденты. Проведение учебных расследований на основе реальных или синтезированных логов для отработки навыков команды.
Ответы на частые вопросы
Почему нельзя хранить логи только на источниках событий?
Потому что это сводит на нет их доказательную ценность. Компрометировав сервер, злоумышленник в первую очередь постарается скрыть следы, удалив локальные журналы. Централизованное и защищённое хранение исключает такую возможность.
Что грозит организации, если срок хранения логов меньше 90 дней?
Во-первых, формальное несоответствие требованиям регуляторов (ФСТЭК), что ведёт к предписаниям об устранении нарушений. Во-вторых, практическая невозможность расследования инцидентов, обнаруженных с задержкой. В-третьих, в случае судебного разбирательства по факту утечки данных отсутствие доказательств будет трактоваться не в пользу организации.