Безопасность логирования и мониторинга

16 мин чтения·Для руководителя разработки и лидера безопасности

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

Мониторинг безопасности идёт дальше: вместо того чтобы ждать, пока кто-то заметит проблему и пойдёт смотреть логи, система активно отслеживает подозрительные паттерны и сигнализирует в реальном времени. Тысячи неудачных попыток входа за пять минут. Административный аккаунт, который вдруг обратился к данным, которых никогда не касался. Сервер, устанавливающий соединения с известными адресами атакующих.

Задача лидер безопасности — сотрудника, который берёт на себя вопросы информационной безопасности в команде как дополнительную зону ответственности, — выстроить эту систему. Задача руководителя — убедиться, что система работает, и понимать свои обязательства перед регуляторами.

Почему это важно для бизнеса

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

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

Быстрое обнаружение снижает ущерб. По данным российских ИБ-аналитиков (Positive Technologies, ГК «Солар»), среднее время между вторжением и обнаружением исчисляется неделями и месяцами. Мониторинг с правильно настроенными оповещениями сокращает это время до минут и часов.

Это требование регуляторов. Для субъектов критической информационной инфраструктуры (КИИ) логирование и мониторинг — не рекомендация, а обязательство по 187-ФЗ. Требования к системам обработки персональных данных закреплены в приказах ФСТЭК № 21 (для ПДн) и № 17 (для ГИС). Уведомление НКЦКИ/ГосСОПКА об инцидентах — обязательство, невыполнение которого влечёт административную и в ряде случаев уголовную ответственность.

Законодательные обязательства по логированию и уведомлению

Критическая информационная инфраструктура (187-ФЗ)

Если компания является субъектом КИИ (финансовые организации, операторы связи, транспорт, здравоохранение, промышленность и ряд других отраслей) — обязательно:

Подключение к ГосСОПКА (государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак) или создание ведомственного/корпоративного центра мониторинга, взаимодействующего с ГосСОПКА через НКЦКИ (Национальный координационный центр по компьютерным инцидентам, cert.gov.ru)
Уведомление НКЦКИ об инцидентах на значимых объектах КИИ в установленные сроки (как правило, в течение суток)
Сбор и хранение информации об инцидентах согласно требованиям регулятора

Порядок и сроки уведомления определяются Приказом ФСБ России № 367 и методическими документами НКЦКИ.

Персональные данные (152-ФЗ)

Уведомление Роскомнадзора об утечке персональных данных: 24 часа — уведомить о факте инцидента, 72 часа — предоставить результаты расследования
Для выполнения этого требования необходимо фактически выявить инцидент — что невозможно без мониторинга
Приказ ФСТЭК № 21 требует ведения журналов событий безопасности для информационных систем персональных данных

ГОСТ Р 57580.1 (финансовый сектор)

Для финансовых организаций, подпадающих под требования Банка России (Положения 683-П, 719-П, 757-П), ГОСТ Р 57580.1 устанавливает конкретные требования к мониторингу событий ИБ, включая технические меры по сбору, защите и анализу журналов аудита.

Что нужно фиксировать в логах

Не все события одинаково важны для безопасности. Вот что критично:

Аутентификация и доступ

Событие	Почему важно	Приоритет
Успешный / неудачный вход	Обнаружение брутфорса, несанкционированного доступа	Критический
Смена пароля	Признак захвата аккаунта	Критический
События MFA	Попытки обхода, изменение настроек	Критический
Создание и закрытие сессии	Угон сессии, аномальные паттерны доступа	Высокий
Изменение прав доступа	Повышение привилегий, угрозы изнутри	Критический
Использование API-ключей	Скомпрометированные учётные данные	Высокий
SSH / RDP-соединения	Боковое перемещение, первоначальный доступ	Критический

Безопасность приложений

Событие	Почему важно	Приоритет
Отказы валидации входных данных	Попытки атак (SQLi, XSS)	Высокий
Отказы авторизации	Попытки нарушения контроля доступа	Высокий
Операции с файлами	Exfiltration данных, шифровальщики	Средний
Транзакции / платёжные события	Фрод-детект	Критический
Превышение лимитов API	Злоупотребление, скрейпинг, DDoS	Средний

Инфраструктура

Событие	Почему важно	Приоритет
Разрешения / запреты межсетевого экрана	Сетевая разведка, атаки	Высокий
DNS-запросы	C2-коммуникация, exfiltration	Средний
Запуск процессов	Вредоносное ПО, майнеры	Высокий
Изменения конфигурации сервисов	Вмешательство, бэкдоры	Средний
Изменения целостности файлов	Руткиты, бэкдоры	Высокий
Вызовы облачного API	Злоупотребление ресурсами, ошибки конфигурации	Высокий

Что категорически нельзя фиксировать в логах

Следующие данные не должны попадать в журналы — это создало бы новый вектор утечки:

Пароли — даже в случае ошибки аутентификации. Фиксируйте «попытка входа не удалась», но не сам пароль
Полные номера банковских карт — только последние 4 цифры
СНИЛС, паспортные данные, ИНН — минимизация персональных данных в логах
Сессионные токены, API-ключи — фиксируйте факт использования, не значение
Персональные данные в объёме, превышающем необходимый

Централизованный сбор логов: архитектура

Логи, разбросанные по десяткам серверов, бесполезны в момент инцидента. Нужна централизованная система.

Базовая архитектура:

Источники логов                    Сборщики / агенты
(приложения, серверы,              (Filebeat, Fluentd,
СУБД, сетевое оборудование,  →     Vector, Fluent Bit)
облачные API, межсетевые           
экраны)                     →     Агрегатор / SIEM
                                   (хранение, индексация,
                                   поиск, анализ)
                                        ↓
                            Визуализация + Оповещения
                            (дашборды, алерты в VK Teams /
                            eXpress / корпоративный ITSM)

Ключевые требования к системе:

Централизованное хранение — не на прикладных серверах
Защита от изменений (tamper-proof) — логи не должны редактироваться после записи
Разделение доступа — приложения пишут в логи, но не могут их удалять
Гарантированная доставка — даже при сетевых сбоях события не теряются
Настроенные оповещения — журнал, который никто не читает, не защищает

Российские SIEM и системы мониторинга

Коммерческие российские решения

MaxPatrol SIEM (Positive Technologies) — ведущая российская SIEM-система. Сбор событий из широкого спектра источников, корреляция, встроенные правила обнаружения, интеграция с БДУ ФСТЭК. Сертифицирована ФСТЭК России. Используется государственными органами, финансовыми и промышленными организациями.

KUMA (Kaspersky Unified Monitoring and Analysis Platform) — SIEM-платформа от Лаборатории Касперского. Коллектор событий, механизм корреляции, аналитика угроз. Интегрируется с другими продуктами Kaspersky, имеет сертификацию ФСТЭК.

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

R-Vision SIEM / Security Vision — платформы для мониторинга, управления инцидентами и автоматизации реагирования (SOAR). Используются крупным бизнесом и государственным сектором.

Перечисленные решения подходят для субъектов КИИ, так как включены в реестр российского ПО Минцифры и/или сертифицированы ФСТЭК.

Open-source решения с размещением на собственном сервере

Для компаний без жёстких требований к сертифицированным СЗИ — рабочая альтернатива:

OpenSearch / ELK Stack — классический стек для централизованного логирования (Elasticsearch/OpenSearch для хранения, Logstash/OpenSearch Ingest для обработки, Kibana/OpenSearch Dashboards для визуализации). Открытый исходный код, широкие возможности поиска и аналитики, требователен к ресурсам.

Wazuh — полноценная open-source SIEM с функциями обнаружения угроз, контроля целостности файлов, мониторинга уязвимостей и управления соответствием требованиям. Работает на базе OpenSearch. Встроенные правила детектирования по MITRE ATT&CK. Подходит небольшим и средним компаниям как начальная точка входа.

Grafana + Loki — более лёгкий стек для сбора и визуализации логов. Меньше требований к ресурсам, но ограниченные возможности SIEM-анализа. Хорошо работает в связке с Prometheus для метрик.

Graylog — централизованное управление логами с элементами SIEM: встроенные алерты, потоки событий, интеграция с OpenSearch.

Сравнение подходов

Критерий	Коммерческий SIEM (MaxPatrol, KUMA)	Open-source (Wazuh, OpenSearch)
Сертификация ФСТЭК	Есть	Нет
Требования к ресурсам	Зависит от вендора	Высокие (особенно Elasticsearch)
Стоимость лицензии	Высокая	Нулевая
Стоимость внедрения	Высокая	Средняя
Готовые правила обнаружения	Да, с поддержкой	Базовые, нужна настройка
Интеграция с ГосСОПКА	Да	Требует доработки
Подходит для КИИ	Да	Зависит от требований

Для субъектов КИИ и крупных компаний с регуляторными требованиями — коммерческие российские SIEM. Для малого и среднего бизнеса без жёстких требований — начинать с Wazuh или OpenSearch.

Настройка оповещений

Логи полезны только если их кто-то смотрит. Оповещения превращают пассивное накопление данных в активный мониторинг.

Категории оповещений

Критический уровень — немедленная реакция:

Несколько неудачных попыток входа, затем успешная (credential stuffing сработал)
Административный пользователь создан не-администратором
Отключён межсетевой экран или SIEM-агент
Подозрительный процесс (сигнатуры майнеров, шифровальщиков)
Соединение с известными вредоносными адресами (по данным НКЦКИ, ФинЦЕРТ, threat intelligence)
Доступ к производственной СУБД с нетипичного IP

Высокий уровень — расследование в течение нескольких часов:

Продолжающаяся брутфорс-атака
Нетипичное использование API
Доступ к административным ресурсам в нерабочее время
Массовый экспорт данных
Событие повышения привилегий

Средний уровень — проверка в течение рабочего дня:

Превышение порога неудачных входов
Резкий рост частоты ошибок приложения
Доступ из нетипичной географии
Предупреждения об истечении сертификатов

Низкий уровень — еженедельный просмотр:

Доступ с нового устройства
Попытки нарушить политику (заблокированные)
Незначительные изменения конфигурации

Что детектировать: ключевые сценарии

Атаки на аутентификацию:

Подозрительный паттерн: более 20 неудачных попыток входа с одного IP за 5 минут
Критический: успешный вход после серии неудач (признак компрометации)
Критический: успешный вход из географии, несовместимой с предыдущей (разные страны в течение часа)

Повышение привилегий:

Создание пользователя с правами администратора
Изменение роли на привилегированную
Интерактивная сессия сервисного аккаунта (он не должен логиниться интерактивно)

Exfiltration данных:

Экспорт более N записей за короткое время (пороговое значение определяется для конкретного бизнеса)
Резкий рост числа запросов к базе данных от одного пользователя
Доступ к конфиденциальным данным в нерабочее время

Инфраструктурные атаки:

SSH-соединение с внешнего IP (должно идти только через VPN или бастион)
Запуск нетипичных процессов (по паттернам: майнеры, reverse shell, сканеры)
Изменение правил межсетевого экрана или группы безопасности

Борьба с усталостью от оповещений

Слишком много алертов — то же самое, что их отсутствие: все начинают игнорировать. Несколько правил:

Пороговые значения, не единичные события. «10 неудачных входов за 5 минут с одного IP» — это паттерн. «Один неудачный вход» — норма.
Контекст в оповещении. Алерт должен содержать: источник IP, целевые аккаунты, количество событий, временной диапазон, рекомендуемое действие. Сообщение «подозрительная активность» бесполезно в 3 часа ночи.
Правильные уровни серьёзности. CRITICAL — кто-то должен проснуться. HIGH — разобраться в течение часа. MEDIUM — в ближайшие часы рабочего дня.
Регулярная настройка. Если более 30% алертов — ложные срабатывания, порог нужно пересмотреть.
Оповещение туда, где его увидят. Для корпоративных мессенджеров — VK Teams, eXpress, Compass. Для критических инцидентов — звонок ответственному.

Хранение логов и требования к срокам

Требования российского законодательства

Нормативный акт / стандарт	Минимальный срок хранения	Примечания
187-ФЗ, объекты КИИ	По требованию регулятора	Определяется категорией значимости объекта
Приказ ФСТЭК № 21 (ПДн)	В соответствии с мерами защиты	Логи инцидентов — от 1 года
ГОСТ Р 57580.1 (финсектор)	5 лет для критичных событий	Требования Банка России
152-ФЗ (ПДн)	«Не дольше, чем необходимо»	Срок определяется целями обработки
Рекомендации ФСТЭК	3 года	Для обеспечения возможности расследования
Внутренняя лучшая практика	90 дней «горячих», 1 год архива	Баланс стоимости и полезности

Уровни хранения

Эффективная стратегия хранения предполагает разные уровни:

Уровень	Период	Скорость доступа	Стоимость	Назначение
Горячий	7–30 дней	Быстро (секунды)	Высокая	Оперативное расследование, алерты
Тёплый	30–90 дней	Медленнее (минуты)	Умеренная	Расследование инцидентов
Холодный/архив	90 дней — 5 лет	Долго (часы)	Низкая	Compliance, исторический анализ

Для облачного хранения архивных логов в российской инфраструктуре: Yandex Object Storage, VK Cloud Storage, Selectel S3-совместимые хранилища.

Целостность логов

Для расследования инцидентов и соответствия требованиям регуляторов критично, чтобы логи были защищены от изменений.

Что требуется:

Приложения имеют права только на запись в систему логирования, не на удаление или изменение
Критические журналы хранятся в отдельной системе с ограниченным доступом
Для особо чувствительных логов — криптографическая подпись записей (поддерживается в MaxPatrol SIEM, Wazuh и ряде других решений)
Хранилище логов — отдельный защищённый периметр

Расследование инцидентов с помощью логов

Когда инцидент произошёл, логи — главный инструмент расследования.

Алгоритм расследования

Первичная триажировка. Что сработало? Когда? Какие системы затронуты? Назначить ответственного.
Оценка масштаба. Один инцидент или продолжающаяся атака? Какие аккаунты скомпрометированы? Какие данные под угрозой?
Построение временной шкалы. Что произошло первым? Как события связаны между собой? Каков полный путь атакующего от точки входа до целевых ресурсов?
Установление причины. Как проникли? Через что? Какая уязвимость или ошибка конфигурации была использована?
Анализ ущерба. К каким данным получили доступ? Что было изменено или похищено?
Сдерживание. Заблокировать вредоносные IP, отключить скомпрометированные аккаунты, изолировать затронутые системы, отозвать скомпрометированные учётные данные.
Документирование. Отчёт об инциденте, временная шкала событий, список действий по устранению. Для субъектов КИИ — уведомление НКЦКИ.

Что нужно искать в логах

Для установления первоначального доступа:

Все события аутентификации для скомпрометированного аккаунта за период до и во время инцидента
Все события с IP-адреса атакующего
Первое появление аномального паттерна

Для трассировки движения атакующего:

Все события из скомпрометированной сессии
Команды, выполненные на затронутых хостах
Сетевые соединения между системами

Для оценки утечки данных:

Операции экспорта данных, скачивания файлов от скомпрометированного аккаунта
Нетипичные запросы к базам данных
Отправка данных во внешние системы

Контрольный список при расследовании

Типичные ошибки

Логировать только ошибки. Нормальные события не менее важны для безопасности. Успешные входы нужны для обнаружения скомпрометированных аккаунтов, успешные API-запросы — для выявления exfiltration.

Нет временных меток или неправильный часовой пояс. Логи без временных меток бесполезны. Использовать ISO 8601 в UTC на всех системах — это условие для корреляции событий из разных источников.

Секреты в логах. Пароли, токены, данные карт в логах создают новую уязвимость. Маскировать или исключать чувствительные поля.

Нет ротации и очистки. Диски заполняются, приложения падают. Ротация и политики хранения настраиваются при развёртывании, а не когда место закончится.

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

Слишком много алертов. Если дежурный видит 500 оповещений в день и перестаёт на них реагировать — это не мониторинг. Настраивать пороги до тех пор, пока каждый алерт не будет требовать реакции.

Логи только на прикладных серверах. Критические события происходят везде — на межсетевых экранах, в базах данных, в облачных API. Собирать всё.

Не проверять, что алерты работают. Как убедиться, что сигнализация сработает? Генерировать тестовые события, проверять, что они попадают в алерты и доставляются по нужным каналам.

Типичный кейс (обезличенный)

Российская ИТ-компания на 80 человек имела SIEM-систему с настроенными алертами. В течение трёх дней система фиксировала нетипичную активность одного аккаунта: запросы к базе данных клиентов в ночное время, нетипичный объём. Алерты приходили — но уходили в общий канал оповещений, где их никто не смотрел. На четвёртый день сработал алерт от антивируса уже на другом хосте. При расследовании оказалось: учётная запись сотрудника была скомпрометирована, данные 40 000 клиентов выгружены. Логи сохранились и позволили восстановить полную картину — это ускорило уведомление Роскомнадзора и расследование. Но инцидент можно было предотвратить, если бы алерты маршрутизировались правильно.

Урок: мало настроить алерты — нужно убедиться, что кто-то их реально получает и реагирует.

См. также

Плейбуки реагирования — как использовать логи при инциденте
Разведка угроз — что превращать в правила обнаружения
Соответствие требованиям — требования к срокам хранения

Что дальше

Централизованный сбор логов выстроен, оповещения настроены, обязательства перед регуляторами выполняются. Когда что-то произойдёт — вы узнаете об этом вовремя, а не через несколько месяцев.

Этим разделом завершается модуль «Безопасность в разработке и операциях». Следующий шаг: культура безопасности — как сделать так, чтобы вся команда разделяла ответственность за ИБ, а не только лидер безопасности.

Почему это важно для бизнеса​

Законодательные обязательства по логированию и уведомлению​

Критическая информационная инфраструктура (187-ФЗ)​

Персональные данные (152-ФЗ)​

ГОСТ Р 57580.1 (финансовый сектор)​

Что нужно фиксировать в логах​

Аутентификация и доступ​

Безопасность приложений​

Инфраструктура​

Что категорически нельзя фиксировать в логах​

Централизованный сбор логов: архитектура​

Российские SIEM и системы мониторинга​

Коммерческие российские решения​

Open-source решения с размещением на собственном сервере​

Сравнение подходов​

Настройка оповещений​

Категории оповещений​

Что детектировать: ключевые сценарии​

Борьба с усталостью от оповещений​

Хранение логов и требования к срокам​

Требования российского законодательства​

Уровни хранения​

Целостность логов​

Расследование инцидентов с помощью логов​

Алгоритм расследования​

Что нужно искать в логах​

Контрольный список при расследовании​

Типичные ошибки​

Типичный кейс (обезличенный)​

См. также​

Что дальше​