В 2024 году мы рассказывали, как развернули масштабный центр мониторинга безопасности над «Газпром-Медиа». Тогда даже позволили себе тезис о том, что способны подключить любой актив к мониторингу за одни сутки. Это правда, но опытный инженер, прошедший через реалии корпоративной среды, скажет вам, что запустить систему в продакшен — это всего лишь начало. А вот эксплуатировать ее на живой, постоянно изменяющейся инфраструктуре, где каждый день меняются сетевые доступы и появляются новые сервисы, — долгосрочная задача повышенной сложности.

Что происходит, когда центр мониторинга безопасности федерального холдинга превышает отметку в 100 000 событий в секунду? Когда стандартные решения начинают буксовать, а инфраструктура разрастается до 100 сервисов? В 2025 году наша команда столкнулась именно с такими вызовами.

В этой статье расскажем, как мы решали архитектурные «головоломки» высоконагруженного SIEM, боролись с экзотическими форматами логов медийных систем, создавали кастомные коннекторы и как Purple Team-учения помогли обнаружить настоящих злодеев.

Для тех, кто пропустил предыдущие материалы или забыл детали за прошедший год, напомню контекст. «Газпром-Медиа» — не монолитная структура, а, скорее, федерация из множества подразделений. Телеканалы, радиостанции, продакшен-студии и цифровые сервисы, где у каждого актива свой монастырь, свой устав, привычки и легаси-системы.

В 2024 году мы развернули SOC, который, как зонтиком, накрыл все эти подразделения холдинга. Его архитектурная основа за год не изменилась.

Мы по-прежнему используем Kaspersky Unified Monitoring and Analysis Platform (KUMA) с мультитенантной архитектурой и базой данных ClickHouse. Помимо SIEM, важную роль выполняет XDR-решение, которое мониторит значительную часть инфраструктуры. XDR стал одним из ключевых источников событий: не только инцидентов безопасности, но и данных о состоянии конечных точек. Заказчик использует XDR для оперативного реагирования: изоляции хостов, проверки гипотез о компрометации и обнаружения атакующего.

Однако если в прошлом году мы обслуживали семьдесят серверов SIEM, то сейчас количество хостов выросло почти до сотни. Но главное — нагрузка. Превысив отметку в 100 000 событий в секунду (EPS), сталкиваешься с принципиально иной сложностью задач.

Управление потоком событий

В 2025 году мы окончательно поняли, что классическая схема маршрутизации событий, описанная в инструкциях к коробочным СЗИ, не подходит для работы под экстремальной нагрузкой. Так, обычно путь события в KUMA SIEM выглядит линейно: источник отправляет лог на коллектор, тот передает его в коррелятор, затем данные попадают в хранилище, но из-за строгих требований к отказоустойчивости нам требовалась более разветвленная и сложная архитектура. Пришлось разработать и весь год совершенствовать иной алгоритм.

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

Дополнительную сложность создает географическая распределенность. Часть компонентов SIEM работает в рамках основной инсталляции, а часть развернута изолированно на удаленных площадках с ограниченной пропускной способностью каналов связи. Хранение производится в нескольких хранилищах со сложной ролевой моделью: одни события направляются в центральную систему, другие остаются на локальных площадках. Такая архитектура продиктована ограничениями сетевой инфраструктуры, но она существенно усложняет координацию и мониторинг всей системы.

Для центра мониторинга, который должен реагировать на инциденты немедленно, любая задержка в регистрации события просто недопустима. Так, однажды из строя вышел один коррелятор из кластера. Балансировка сработала недостаточно быстро, и накопилась очередь. Когда мы устранили проблему и восстановили компонент, система обработала накопленные данные. SOC за одну минуту получил двести инцидентов — и все это были старые события, которые система, наконец, «прожевала» и выдала одновременно.

В таких ситуациях возникает парадокс, похожий на «Уловку-22». Как искать причину задержек или потерь событий? Логика подсказывает: нужно повысить уровень журналирования компонентов до уровня Debug для получения подробных логов, но при нагрузке более 100 000 EPS это просто опасно. Включение детального логирования на коллекторе или корреляторе приводит к генерации огромного объема текстовых логов, которые блокируют дисковую подсистему сервера. Место на диске заканчивается за минуты, и компонент прекращает работу. Поэтому мы используем точечные методы: включаем отладку на секунды, применяем сэмплирование или анализируем косвенные признаки, избегая полноценного режима отладки.

Ситуацию дополнительно осложняет организационный фактор. В крупных структурах доступы к серверам и логам регулярно пересматриваются по соображениям внутренней политики безопасности. В результате внешний SOC порой остается без прямого доступа к компонентам той или иной системы, и отладка превращается в игру «горячо-холодно» через посредника. Приходится использовать косвенные признаки и телеметрию, доступную через стандартные интерфейсы, и постоянно запрашивать у коллег дополнительные данные. Этот алгоритм несколько усложняет процесс отладки.

Другая сложность касается мониторинга доступности источников. Стандартные механизмы SIEM работают бинарно: если события отсутствуют определенное количество минут, генерируется алерт о недоступности источника. В период отладки новых источников в сети заказчика регулярно возникали микрозадержки в одну-две минуты. Из-за этого центр мониторинга получал множество ложных срабатываний. Приходили сотни уведомлений о недоступности серверов, которые фактически работали корректно, но испытывали временные задержки в передаче данных.

Чтобы решить эту проблему, мы отключили стандартный мониторинг для проблемных зон и реализовали собственную логику на базе механизма оповещения об изменении активлистов. Мы создали правило корреляции, которое при поступлении события обновляет временную метку в специальном списке. Второе правило проверяет актуальность этой метки. Затем мы настроили гибкие пороги, которые игнорируют кратковременные задержки, но надежно сигнализируют о реальной недоступности источника.

Отдельной задачей стала оптимизация хранилища данных. ClickHouse — производительная и надежная база данных, но требует квалифицированного администрирования. При нашей схеме записи образовывалось большое количество мелких партиций. Это приводило к фрагментации, которая снижала производительность и увеличивала расход дискового пространства. Потребовалась глубокая настройка движка базы данных: оптимизация процессов слияния партиций, удаление мелких частей и настройка политик хранения TTL для предотвращения влияния старых данных на обработку новых.

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

Kubernetes и DNS

Мы развернули ядро системы в Kubernetes для обеспечения отказоустойчивости, но столкнулись с проблемой в базовом компоненте — системе доменных имен DNS. На практике выяснилось, что KUMA в отказоустойчивом кластере при наших масштабах сильно зависит от внешнего DNS-сервера. Удаленный коллектор пытается отправить события в ядро, но не может определить имя сервиса внутри Kubernetes. Он начинает накапливать события в локальном кэше вплоть до исчерпания дискового пространства.

Обойтись локальными записями в файлах hosts или другими временными решениями оказалось невозможно. Необходим выделенный компонент, к которому могут обратиться все части распределенной системы, включая компоненты на удаленных площадках, в других подсетях или центрах обработки данных. Без корректного разрешения имен компоненты SIEM теряют связь друг с другом.

Решением стало обязательное внедрение внешнего DNS-сервера, доступного для всех сегментов сети заказчика. Технически это простая задача, но в масштабах крупного холдинга согласование сетевых доступов, открытие портов на десятках м��жсетевых экранов и координация с локальными администраторами для внесения необходимых настроек превращается в комплексный организационный процесс с десятками участников.

Кастомные решения и тонкая настройка

Другой показательный случай связан с обогащением данных из LDAP. У нас мультитенантная архитектура, и в одном сегменте сети могут находиться активы разных юридических лиц холдинга. При возникновении инцидента аналитик должен мгновенно понять принадлежность сервера: телеканалу или бухгалтерии радиостанции. Стандартный механизм KUMA интегрируется с Active Directory, но поддерживает только предопределенный набор полей. Нам же требовалась возможность извлекать специфические атрибуты, в частности, Organizational Unit (OU), для автоматической привязки к юридическим лицам.

Мы придумали обходное решение. На стороне контроллера домена скрипт PowerShell выгружает необходимые данные и формирует CSV-файл. Затем созданный нами скрипт-посредник на Python обрабатывает этот файл и передает данные напрямую в словарь SIEM через API. Главная сложность в выборе места для размещения данных. В стандартной схеме событий не оказалось подходящего свободного поля. Анализ документации показал наличие редко используемого поля DeviceCustomFloatingPoint4Label. Несмотря на странное название, поле функционирует корректно. Теперь значение OU размещается именно там. При поступлении события с заполненным полем мы сразу определяем принадлежность актива. Это решение обеспечило мгновенную атрибуцию инцидентов, полностью обойдя ограничения стандартного коннектора.

Языковой барьер

Дополнительную сложность создало разнообразие источников. Если с логами ОС или сетевого оборудования все понятно и стандартизировано, то проприетарный софт медийщиков и самописные системы из начала двухтысячных создавали серьезные трудности в обработке.

Стандартные парсеры ожидают на входе кодировку UTF-8 или CP1251. Мы же порой получали потоки данных, которые выглядели как полная абракадабра. Вендорский парсер смотрел на этот набор символов и честно говорил, что не знает, как с этим работать, выдавая ошибку. Ситуацию усугубляла склейка событий. Порой логи приходили не по одному, а пачками, группами в одну длинную бесконечную строку. Или, наоборот, одно событие приходило разорванным на куски.

Главная проблема таких сложных источников — полное отсутствие документации. Формат логов зачастую был и��вестен только разработчику, который уволился еще до пандемии. К счастью, KUMA позволяет писать гибкие парсеры, и мы по полной использовали эту возможность. Анализировали сырой текст лога, который стандартный коннектор не мог обработать, и пошагово создавали регулярные выражения для извлечения временных меток, IP-адресов и действий пользователей.

В результате написали собственную библиотеку кастомных нормализаторов. За 2025 год это позволило покрыть множество новых типов источников, о которых многие даже не слышали.

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

Охота на призраков

Все эти усилия принесли свои плоды, когда мы обнаружили подозрительную активность на одном из хостов во внутреннем контуре. Хост обычно демонстрировал минимальную активность, а тут выдал аномальный всплеск трафика. Мы направили уведомление заказчику и привлекли команду реагирования из отдела Incident Response для углубленного анализа логов. Проблемный хост оказался устаревшим веб-сервисом, который был доступен из внешней сети.

Расследование показало, что он уже подвергался компрометации прежде. Тогда администраторы провели очистку системы, устранили следы атаки и удалили вредоносное программное обеспечение, но не устранили первоначальную уязвимость, не закрыли точку входа. Активность, которую мы обнаружили в 2025 году, не была тестированием. Злоумышленник, возможно, тот же или новый, пытался использовать старую уязвимость в надежде развить атаку. Мы предоставили заказчику расширенный отчет, «легитимная активность» была переквалифицирована в критический инцидент, а хост изолирован без последствий для информационной безопасности холдинга.

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

Проверка на прочность

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

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

Эти учения подтвердили: в масштабах холдинга рассчитывать исключительно на локальных администраторов не стоит. В ходе упражнений мы наблюдали, что локальные системы защиты заказчика в зонах без нашего покрытия не всегда срабатывали. Причем порой локальные администраторы вполне могли заметить и предотвратить подозрительную активность, но не реагировали вовремя. По результатам мы провели масштабную ревизию активов и включили в систему мониторинга целый ряд дополнительных конечных точек, устранив слепые зоны и серьезно укрепив безопасность «Газпром-Медиа Холдинга».

Планы на будущее и выводы

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

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

Что дальше?

На 2026 год у нас амбициозные планы. Сейчас в холдинге развертывается решение для защиты от DDoS-атак. Наша задача — не просто собирать логи с этой системы (обнаружение DDoS через SIEM малоэффективно), а настроить интеллектуальное взаимодействие. Мы планируем анализировать активность этого решения в контексте других событий безопасности, обогащая инциденты данными о сетевых аномалиях.

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

Основные выводы

Если коротко резюмировать наш опыт масштабирования мониторинга, то:

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

  • отладка высоконагруженных систем — отдельная инженерная дисциплина, где привычные методы могут поломать то, что пытаешься починить;

  • документация к legacy-системам — роскошь, а обратный инжиниринг и регулярные выражения — необходимость;

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

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

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

Система безопасности всегда должна эволюционировать быстрее угроз и сохранять эту тенденцию на долгой дистанции. А для этого просто необходимы надежная база и зрелые процессы.

Делитесь в комментариях своими историями масштабирования SIEM. Будет интересно сравнить подходы и болевые точки в разных компаниях.