Рассылка логов в несколько SIEM-систем: как дублировать отправку данных, не удваивая риски
News | 27.10.2026
Организациям часто требуется отправлять одни и те же события безопасности в несколько платформ управления информацией и событиями безопасности (SIEM). Распространенные сценарии включают миграцию на новую SIEM, интеграцию с поставщиками услуг управляемой безопасности (MSSP), долгосрочное архивирование для соответствия нормативным требованиям, а также центры мониторинга безопасности (SOC), работающие в разных регионах.
Разветвление логов (log fan-out), также известное как двойная отправка (dual-shipping), позволяет единой точке сбора пересылать события сразу в два или более мест назначения. С помощью NXLog Agent организации могут маршрутизировать данные в несколько потоков вывода из одного источника, применять специфические для каждого получателя преобразования и управлять поведением пайплайна в случаях, когда один из адресатов становится недоступен.
Сложность заключается в поддержании надежной доставки без неоправданного роста затрат на сбор данных (ingestion costs), расхождений в количестве событий или избыточного операционного усложнения. В этом руководстве рассматриваются основные архитектуры разветвления, демонстрируются практические шаблоны конфигурации NXLog и описываются способы валидации доставки данных в несколько SIEM-систем.
Что такое разветвление логов (Log Fan-Out)?
Разветвление логов (log fan-out) — это процесс параллельной отправки одного и того же собранного события в несколько мест назначения. Термин «двойная отправка» (dual-shipping) описывает частный случай пересылки данных двум адресатам. Для схожих архитектур также часто используются термины «зеркалирование» (mirroring) и «ответвление» (teeing).
Один из подходов — развертывание отдельных агентов для каждой SIEM на каждом хосте. Однако это влечет за собой увеличение числа жизненных циклов конфигураций, усложнение управления сертификатами, дополнительный расход ресурсов процессора и оперативной памяти, а также вероятность расхождения в количестве событий, если агенты считывают данные из источников в разное время.
Решения NXLog предлагают альтернативу: единый агент собирает данные один раз и маршрутизирует их в несколько модулей вывода. Каждый вывод может применять собственную логику обработки, позволяя организациям подключать адресатов с разными форматами данных и требованиями к их приему.
Когда следует использовать двойную отправку (Dual-Shipping)?
1. Миграция SIEM
Параллельный запуск двух платформ SIEM позволяет командам безопасности валидировать новую платформу на живой телеметрии, не нарушая работу действующих правил обнаружения угроз. Это помогает выявить проблемы с парсингом, недостающие поля и различия в логике детектирования до окончательного переключения.
Тем не менее дублирование всех сырых событий на обе платформы может значительно увеличить затраты на их обработку. В руководстве Microsoft по параллельному развертыванию Microsoft Sentinel с существующей SIEM подробно описаны эксплуатационные и финансовые недостатки длительного параллельного использования систем. В определенных случаях пересылка алертов вместо дублирования сырых логов позволяет снизить затраты на эксплуатацию обеих платформ.
2. MSSP или MDR и внутренний SOC
Поставщику услуг управляемой безопасности (MSSP) или сервису управляемого обнаружения и реагирования (MDR) могут требоваться сырые телеметрические данные для собственных процессов детекции и расследований. В то же время внутреннему SOC необходима собственная копия данных для threat hunting, реагирования на инциденты, аудита и операционной независимости.
Разветвление позволяет обеим командам получать актуальные данные без необходимости развертывания отдельных агентов сбора для каждого получателя.
3. SIEM и долгосрочный архив
SIEM может хранить часто запрашиваемые данные для оперативного обнаружения угроз и расследований, тогда как объектное хранилище или более доступный по стоимости репозиторий логов сохраняет информацию на длительные периоды. Такой подход разделяет данные в зависимости от их назначения, вместо того чтобы одинаково дорого платить за прием и анализ каждого события.
4. Региональные SIEM или системы отдельных бизнес-подразделений
Крупные организации могут иметь центральный SOC наряду с локальными командами безопасности в регионах. Единый источник может передавать данные в несколько SIEM-систем, при этом политики маршрутизации будут учитывать различия в операционных задачах и требованиях к локализации хранения данных (data residency).
Перед внедрением двойной отправки важно четко определить, какие именно события требуются каждому адресату, как долго продлится параллельная работа систем и действительно ли необходимо полное дублирование данных. Фильтрация или выборочная маршрутизация помогают держать расходы под контролем. Дополнительные рекомендации приведены в нашей статье о фильтрации и сокращении объема логов перед отправкой в SIEM.
Сравнение архитектур разветвления логов
| Архитектура | Где происходит маршрутизация | Основные преимущества | Ключевые факторы для учета |
|---|---|---|---|
| Отдельные агенты на каждом хосте | На каждой конечной точке | Независимый сбор данных и автономная конфигурация | Максимальные операционные издержки и риск расхождения в количестве событий |
| Один агент с несколькими выводами | На каждой конечной точке | Единый процесс сбора, индивидуальная обработка под получателя, независимые очереди вывода | Требует грамотной настройки контроля потока (flow control) и параметров очередей |
| Центральный ретранслятор или уровень коллекторов | На выделенных хостах-ретрансляторах (relay) | Централизованная маршрутизация для источников, где невозможно запустить агент | Требует планирования пропускной способности, высокой доступности и защищенного транспорта |
| Пересылка сырых логов на уровне SIEM-to-SIEM | Внутри исходной SIEM | Потенциальная простота первоначальной настройки | Удвоение затрат на прием данных (ingestion) и рост архитектурной зависимости систем |
Для большинства рабочих станций и серверов оптимальной отправной точкой является маршрутизация на уровне агента. Для сетевых устройств и других источников, где запуск агента невозможен, распределение берет на себя уровень ретрансляторов.
Настройка разветвления логов с помощью NXLog Agent
Ниже показаны примеры маршрутизации потока событий безопасности Windows (Windows Security) в Splunk через HTTP Event Collector (HEC) и в Microsoft Sentinel через Logs Ingestion API. Представленная конфигурация является иллюстративной: параметры аутентификации, URL-адреса эндпоинтов, правила сбора данных (DCR) и сопоставления полей должны быть адаптированы под вашу инфраструктуру и проверены на используемой версии NXLog Agent.
Шаблон 1: Отправка из одного входа в несколько выходов
В NXLog Agent маршрут соединяет модули ввода с модулями вывода через директиву Path. В одном маршруте можно указать несколько выходов через запятую, благодаря чему они получают события параллельно.
Каждый адресат может независимо преобразовывать свою копию события. Например, для Splunk HEC требуется специальная структура (envelope), в то время как Logs Ingestion API в Microsoft Sentinel ожидает записи, точно соответствующие схеме, определенной в правиле сбора данных (Data Collection Rule, DCR).
Module xm_json
Module im_msvistalog
Channel Security
Path windows_security => splunk_hec, sentinel
В примере показана общая структура маршрутизации, а не готовая к промышленной эксплуатации конфигурация. Логика преобразования данных под конкретные выходы должна быть реализована с использованием корректных процедур и полей NXLog для каждого места назначения.
Подробные сведения о реализации приведены в официальной документации NXLog: настройки маршрутов (route settings), модуль вывода HTTP и модуль вывода Microsoft Azure Monitor. Практические руководства по интеграции с Splunk и Microsoft Sentinel содержат дополнительные указания по настройке.
Шаблон 2: Отправка отфильтрованного подмножества во вторую SIEM
Далеко не каждому адресату требуются абсолютно все события. Например, в ходе пилотного тестирования новой SIEM на начальном этапе могут понадобиться только логи аутентификации и действий привилегированных учетных записей. Выборочная маршрутизация снижает затраты на дублирующий прием данных, сохраняя полный поток событий в основной SIEM.
NXLog поддерживает изолированную обработку для каждого вывода, поэтому фильтр, примененный внутри блока Exec одного вывода, не затрагивает другие. Ниже представлен упрощенный пример логики выборки:
В этом примере отбираются события безопасности Windows, связанные со входом в систему, использованием специальных привилегий, созданием учетных записей и изменением состава групп. Основная SIEM продолжит получать журнал Security целиком, в то время как во второй приемник будет отправляться только выбранная часть данных.
Перед применением фильтра проверьте, что отобранные события полностью покрывают сценарии детектирования и соответствуют схеме целевой системы. Подробнее об обработке и маршрутизации телеметрии перед отправкой в SIEM читайте в нашем руководстве по сокращению объема логов без потери правил обнаружения.
Обработка сбоев приемников: управление потоком (Flow Control) и очереди
Одно из критически важных решений при проектировании разветвления — определение логики работы при недоступности одного из получателей.
При включенном контроле потока (flow control) заблокированный модуль вывода может приостановить обработку на всем маршруте выше по потоку, пока задержка не устранится. В маршруте с несколькими выходами это приведет к задержке доставки и в исправно работающую SIEM. Например, длительные проблемы с приемом данных на стороне Sentinel могут заблокировать передачу событий в Splunk, если они находятся в общем маршруте.
Выбор корректной конфигурации зависит от типа источника, приоритета каждого места назначения и допустимости задержки или потери событий для организации.
Вариант А: Оставить контроль потока (Flow Control) включенным
Для источников, допускающих паузу (таких как файлы или Windows Event Log), сохранение активного flow control позволяет агенту замедлять сбор данных, если адресат не справляется с приемом. Это предотвращает потерю событий на время восстановления целевой системы, хотя доставка в работающий приемник также может задерживаться.
Это более надежный подход в тех случаях, когда сохранность событий важнее непрерывной доставки в режиме реального времени на все направления. При этом емкость очередей и глубина хранения на источнике должны быть достаточными для компенсации предполагаемого простоя.
Вариант Б: Отключить контроль потока для вторичного вывода
Если основная SIEM должна гарантированно получать данные в реальном времени, flow control можно отключить для вторичного вывода, где потеря данных после переполнения очереди считается допустимой. Вторичный вывод буферизует события при краткосрочных сбоях, тогда как основной вывод сохраняет защиту механизмом контроля потока.
Path windows_security => splunk_hec, sentinel
В этом примере для вторичного вывода задана очередь размером 16 МиБ. Это значение приведено исключительно для наглядности: размер очереди должен рассчитываться на основе объема потока событий, их среднего размера и целевой продолжительности сбоя, которую система должна сгладить.
Базовая формула для расчета:
Необходимая емкость очереди ≈ количество событий в секунду × длительность простоя в секундах × средний размер сериализованного события.
Рекомендуется закладывать дополнительный запас на всплески трафика и служебные накладные расходы, а также тестировать поведение очереди под нагрузкой. Небольшая очередь защитит от кратковременных задержек в сети или троттлинга, но не спасет от потерь при длительной недоступности сервиса.
Директива PersistLogqueue TRUE включает сохранение очереди вывода на диске во время работы агента. Постоянные очереди создают дополнительную нагрузку на дисковую подсистему ввода-вывода (I/O) и требуют предварительного тестирования. Сама по себе персистентность очереди не является абсолютной гарантией сквозной доставки.
Отключение контроля потока на модуле ввода — принципиально иное решение: оно снимает защиту от противодавления (backpressure) сразу для обоих адресатов. Для приостанавливаемых источников настраивайте flow control точечно на соответствующем выводе, избегая его глобального отключения без четкого понимания последствий.
Подробную информацию см. в документации NXLog: буферизация и контроль потока, а также настройка буферизации. Рекомендуем также ознакомиться со статьей Softprom об офлайн-буферизации для сборщиков логов.
Шаблон 3: Разветвление логов на уровне ретранслятора (Relay Tier)
Сетевые устройства (межсетевые экраны, коммутаторы, программно-аппаратные комплексы) зачастую не поддерживают установку агента сбора. Они передают события по протоколу Syslog на ретранслятор (relay), который затем распределяет их по целевым системам. Агенты на конечных точках также могут отправлять данные на общий ретранслятор, если в компании принята централизованная топология.
Уровень ретрансляции позволяет упростить конфигурацию конечных точек: агенты передают данные в единую точку назначения, не требуя информации о структуре и параметрах всех целевых SIEM.
Module xm_syslog
Module im_udp
ListenAddr 0.0.0.0:514
FlowControl FALSE
Exec parse_syslog();
Module im_tcp
ListenAddr 0.0.0.0:1514
Exec parse_json();
# Определение модулей splunk_hec и sentinel с соответствующими
# схемами событий и настройками аутентификации.
Path network_syslog, agents => splunk_hec, sentinel
Приведенный пример демонстрирует лишь общую концепцию архитектуры. Модули ввода, транспортные протоколы, правила парсинга и форматы преобразования должны соответствовать вашим источникам данных и корпоративным требованиям к безопасности.
В продуктивных средах необходимо обеспечить шифрование по TLS на пути от конечных точек к ретранслятору, высокую доступность (HA), сегментацию сети, контроль доступа, а также достаточную вычислительную мощность и емкость очередей. Для источников UDP, которые невозможно приостановить в отличие от файловых логов, требуется уделить особое внимание предотвращению перегрузок и потерь пакетов.
Если источники генерируют события с различными схемами, настройте независимую обработку для каждого типа данных, не полагаясь на универсальное сопоставление полей.
Для масштабных инфраструктур ознакомьтесь с рекомендациями NXLog по распределению нагрузки NXLog Agent и описанием модуля ввода TLS/SSL.
Централизованное развертывание разветвления логов через NXLog Platform
Ручное редактирование конфигурационных файлов допустимо лишь на единичных серверах. В масштабах сотен или тысяч агентов централизованное управление позволяет унифицированно вносить изменения, контролировать результат и оперативно выполнять откат при сбоях.
NXLog Platform предоставляет средства централизованного управления конфигурациями агентов. Администраторы могут создавать конфигурации, назначать их группам агентов, отслеживать версии, сравнивать изменения и при необходимости восстанавливать предыдущие ревизии.
Рекомендуемый порядок поэтапного внедрения:
- Создайте копию рабочей конфигурации и добавьте в нее вторичный модуль вывода.
- Обновите маршрут (route), включив в него оба назначения.
- Назначьте измененную конфигурацию пилотной группе узлов.
- Сравните количество событий, проверьте корректность парсинга на стороне приемников и проконтролируйте поведение очередей.
- Расширьте охват развертывания после подтверждения стабильности доставки и корректности детекции.
- По завершении миграции отключите устаревшую SIEM через плановое обновление конфигурации.
Для задач автоматизации можно использовать NXLog Agent Management API, интегрируя процессы управления конфигурациями с репозиториями контроля версий и пайплайнами CI/CD.
Методики измерения и анализа объемов передаваемых данных описаны в материале Softprom о визуализации потоков и объемов телеметрии с помощью NXLog Platform.
Как убедиться, что обе SIEM получают идентичные события
В процессе миграции, аудита или расследования инцидентов командам необходимо подтверждать полноту и согласованность данных в обоих приемниках. Регулярная сверка помогает вовремя выявить разрывы в потоке данных и отделить транспортные сбои от ошибок схемы или парсинга.
1. Добавление сквозного идентификатора события
Если источник содержит уникальный маркер, передавайте его в обе SIEM. В журнале событий Windows для сквозной корреляции записей оптимально подходит комбинация имени хоста, имени канала и номера записи.
Module im_msvistalog
Channel Security
Exec $FanoutId = $Hostname + ":" + $Channel + ":" + string($RecordNumber);
Добавьте это поле в схемы обоих приемников. Для Microsoft Sentinel его необходимо предварительно объявить в соответствующем потоке DCR, чтобы значение было корректно записано в целевую таблицу.
2. Сверка количества событий и идентификаторов
Сравнивайте количество событий в обеих SIEM с группировкой по хостам и временным интервалам, после чего проводите точечную сверку по сквозным идентификаторам. Постоянные расхождения на конкретном хосте указывают на локальную проблему сбора или парсинга. Массовые пробелы по множеству хостов обычно свидетельствуют о неполадках транспорта или на стороне самого приемника.
Учитывайте задержки приема данных (ingestion latency), особенности обработки часовых поясов, повторные попытки отправки и фильтрацию на стороне SIEM. Простое совпадение общего числа записей еще не гарантирует идентичности переданных событий.
3. Мониторинг внутренних логов NXLog Agent
Отслеживайте внутренний журнал агента на предмет ошибок вывода, переполнения очередей и предупреждений. Направляйте системные сообщения агента в систему мониторинга инфраструктуры, чтобы устранять неполадки до того, как они приведут к длительной потере телеметрии.
Сведения о настройке приведены в документации к модулю ввода Internal.
4. Стресс-тестирование недоступности приемника
Смоделируйте отказ одного из приемников в тестовом окружении под репрезентативной нагрузкой. Убедитесь, что доступная SIEM продолжает получать данные согласно выбранной стратегии flow control, отследите динамику заполнения очереди и подтвердите успешную отправку накопленных событий после восстановления целевой системы.
Для симуляции сбоев в процессе тестирования удобно использовать модуль вывода Blocker. Обязательно валидируйте лимиты очередей и логику восстановления перед запуском решения в эксплуатацию.
Типичные ошибки при параллельной отправке логов (Dual-Shipping)
- Использование единого формата данных для всех направлений. Разные SIEM-системы требуют индивидуальной структуры пакета, специфических имен полей, форматов времени и схем данных. Преобразуйте события для каждого вывода отдельно.
- Отсутствие контроля сроков действия сертификатов. Отслеживайте сроки действия сертификатов, учетных данных и токенов доступа для каждого направления.
- Игнорирование алертов о переполнении очереди. Если на вторичном выводе настроен сброс событий при заполнении очереди, настройте оповещения о критическом росте буфера до наступления потери данных.
- Отключение контроля потока без анализа рисков. Четко определите, какому выводу разрешено терять события, и поддерживает ли источник безопасную приостановку чтения.
- Несогласованные временные метки. Явно сопоставляйте время события (event time) для каждого адресата, чтобы обеспечить возможность точной аналитической сверки.
- Пренебрежение раздельной фильтрацией. Контролируйте, чтобы каждая SIEM получала именно тот объем событий, который требуется для ее задач детектирования, расследований и комплаенса.
- Затягивание временной схемы двойной отправки. Фиксируйте четкую дату вывода старой системы из эксплуатации при миграции. Если параллельная отправка в архив или сторонний SOC планируется на постоянной основе, формализуйте эту архитектуру и зоны ответственности.
Заключение: Построение надежного пайплайна для нескольких SIEM
Разветвление логов позволяет доставлять телеметрию безопасности в несколько систем назначения без необходимости установки отдельных агентов сбора под каждую SIEM. NXLog Agent обеспечивает параллельную маршрутизацию через несколько выходов, индивидуальную обработку событий для каждого получателя и гибкое управление поведением при сбоях.
На рабочих станциях и серверах разветвление реализуется непосредственно на агенте. Для сетевого оборудования и систем, не поддерживающих агенты, централизованное распределение выполняется на уровне ретрансляторов (relay). NXLog Platform берет на себя централизованное управление конфигурациями всего парка агентов, а сквозные идентификаторы, сверка счетчиков, контроль очередей и стресс-тесты гарантируют надежность доставки.
Оптимальная архитектура зависит от ключевого приоритета: стопроцентная сохранность каждого события, бесперебойность потока в основную SIEM, оптимизация стоимости приема данных или управляемая миграция. Определите эти требования до начала проекта, протестируйте нештатные сценарии и обеспечьте постоянный мониторинг пайплайна после ввода в эксплуатацию.
Softprom — официальный дистрибьютор NXLog. Мы помогаем организациям оценивать решения NXLog, проектировать архитектуры сбора и маршрутизации логов, а также интегрировать телеметрию с SIEM и платформами безопасности. Свяжитесь с Softprom, чтобы подобрать оптимальное решение NXLog для вашей инфраструктуры.
Поделиться:
