Розсилання логів у кілька SIEM-систем: як передавати дані в дві системи, не подвоюючи ризики

Організаціям часто потрібно відправляти одні й ті самі події безпеки до декількох платформ управління інформацією та подіями безпеки (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.

Порівняння архітектур розгалуження логів

Для більшості кінцевих точок і серверів маршрутизація на рівні агента є оптимальним рішенням. Для мережевого обладнання та інших пристроїв, що не підтримують установку агентів, завдання розподілу вирішує рівень ретрансляторів.

Налаштування розгалуження логів за допомогою NXLog Agent

Нижче наведено приклади маршрутизації потоку подій безпеки Windows (Windows Security) у Splunk через HTTP Event Collector (HEC) та в Microsoft Sentinel через Logs Ingestion API. Ця конфігурація є базовою: параметри автентифікації, адреси ендпоінтів, правила збору даних (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



    Module om_http
    URL    https://splunk.example.com:8088/services/collector/event
    AddHeader Authorization: Splunk 
    HTTPSCAFile %CERTDIR%/splunk-ca.pem

    
        # Формування структури події (envelope) для Splunk HEC.
        # Мапінг обов'язкових полів: host, time, source та event.
        # Серіалізація підготовленого запису у формат JSON.
    

    Module         om_azuremonitor
    ClientId       
    TenantId       
    ClientSecret   
    URL            https://.ingest.monitor.azure.com
    DcrImmutableId 
    StreamName     Custom-WindowsSecurity_CL

    
        # Мапінг полів події на колонки, оголошені в потоці DCR.
        # Серіалізація запису в JSON та присвоєння змінній $raw_event.
    

    Path windows_security => splunk_hec, sentinel

Наведений приклад відображає базову логіку побудови маршрутів, а не готовий production-файл. Логіка перетворення даних під кожен вивід має бути реалізована з урахуванням правил і синтаксису полів NXLog для відповідного сервісу.

Докладні технічні інструкції наведено в офіційній документації NXLog: параметри маршрутів (route settings), модуль виводу HTTP та модуль виводу Microsoft Azure Monitor. Інструкції щодо підключення до Splunk і Microsoft Sentinel містять додаткові відомості щодо інтеграції.

Шаблон 2: Передача відфільтрованої вибірки до другої SIEM

Не кожному адресату потрібен весь масив подій без винятку. Наприклад, під час пілотування нової SIEM на старті можуть знадобитися лише логи автентифікації та дій адміністраторів. Вибіркова маршрутизація запобігає надмірним витратам на паралельний збір, зберігаючи повний журнал в основній SIEM.

В NXLog обробка налаштовується індивідуально для кожного виводу, тому фільтр всередині блоку Exec одного виводу жодним чином не впливає на інший. Нижче наведено спрощений приклад селективної логіки:

    Module om_azuremonitor

    
        if ($EventID == 4624 or $EventID == 4625 or
            $EventID == 4672 or $EventID == 4720 or
            $EventID == 4728)
        {
            # Мапінг вибраної події на схему Sentinel DCR.
            # Серіалізація запису в JSON та присвоєння змінній $raw_event.
        }
        else
        {
            drop();
        }
    

У цьому фрагменті відбираються події безпеки Windows, що стосуються входів у систему, використання підвищених привілеїв, створення облікових записів та зміни складу груп. Основна SIEM продовжить отримувати весь журнал Security, тоді як до другої системи підуть лише відібрані записи.

Перед запуском фільтрації у промислове середовище переконайтеся, що відібрані події відповідають запланованим сценаріям виявлення загроз, а структура даних узгоджена з цільовою схемою. Детальніше про попередню обробку та маршрутизацію телеметрії читайте у статті про те, як зменшити обсяг логів без втрати якості виявлення.

Керування відмовами приймачів: контроль потоку (Flow Control) та черги

Одне з ключових інженерних рішень під час побудови розгалуження — забезпечення стабільності конвеєра в разі недоступності одного з приймачів.

Якщо контроль потоку (flow control) увімкнено, блокування одного з виводів може зупинити рух подій вище за маршрутом, доки черга не звільниться. У спільній схемі це призведе до затримки доставки і в працездатну SIEM. Наприклад, збій прийому на стороні Sentinel може загальмувати надходження подій до Splunk через заблокований спільний маршрут.

Правильний вибір конфігурації базується на типі джерела, пріоритетності кожної системи та допустимому рівні затримок або втрат для компанії.

Варіант А: Залишити контроль потоку (Flow Control) увімкненим

Для джерел, які дозволяють тимчасову паузу (файли, Windows Event Log), збереження активного flow control дає агенту змогу уповільнювати зчитування, якщо приймач перевантажений. Це захищає події від втрати на період відновлення сервісу, хоча доставка до паралельного робочого призначення також сповільниться.

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

Варіант Б: Вимкнути контроль потоку для вторинного виводу

Якщо первинна SIEM має гарантовано отримувати дані без затримок у реальному часі, flow control можна вимкнути на вторинному виводі, де втрата інформації після вичерпання черги вважається допустимою. Вторинний вивід згладжує короткочасні збої завдяки буферу, тоді як первинний канал працює під постійним захистом контролю потоку.

    Module om_http
    # Налаштування основного призначення.
    # Flow control залишається увімкненим за замовчуванням.

    Module         om_azuremonitor
    # Налаштування вторинного призначення.
    FlowControl    FALSE
    LogqueueSize   16777216
    PersistLogqueue TRUE

    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 надає можливості для централізованого управління агентами. Адміністратори можуть створювати конфігурації, прив'язувати їх до обраних груп агентів, вести версійність, порівнювати зміни та оперативно повертатися до стабільних ревізій.

Послідовність контрольованого розгортання:

1. Створіть копію поточної робочої конфігурації та додайте новий вивід.
2. Оновіть маршрут (route), включивши обидва напрямки.
3. Застосуйте оновлену конфігурацію до невеликої пілотної групи.
4. Звірте кількість подій, перевірте коректність парсингу в обох SIEM та проаналізуйте черги.
5. Розширте розгортання на решту хостів після підтвердження стабільності.
6. Після завершення міграції вимкніть стару систему через планову зміну конфігурації.

Для автоматизації процесів можна використовувати NXLog Agent Management API, інтегруючи оновлення з репозиторіями контролю версій і пайплайнами CI/CD.

Методи оцінки та візуалізації потоків даних детально розглянуто в інструкції Softprom про те, як візуалізувати рух та обсяги телеметрії за допомогою NXLog Platform.

Як переконатися, що обидві SIEM отримують однакові події

Під час міграції, аудиту чи аналізу інцидентів командам потрібно мати впевненість, що обидва приймачі отримали повний набір даних. Системний процес перевірки допомагає вчасно знаходити прогалини в телеметрії та відрізняти мережеві збої від проблем із форматом даних.

1. Додавання наскрізного ідентифікатора події

Якщо джерело містить унікальні атрибути, передавайте їх в обидві системи. Для журналу подій 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. Обов'язково перевірте обмеження черг та алгоритми відновлення перед розгортанням у продуктивному середовищі.

Типові помилки під час налаштування паралельної відправки логів

• Використання єдиного формату даних для різних приймачів. Різні SIEM вимагають індивідуальних структур пакетів, власних назв полів, специфічних форматів часу та схем. Здійснюйте перетворення для кожного виводу окремо.
• Недогляд за термінами дії сертифікатів. Контролюйте терміни придатності сертифікатів, паролів і токенів для кожного напрямку.
• Відсутність сповіщень про переповнення черги. Якщо на вторинному виводі налаштовано відкидання подій після вичерпання черги, налаштуйте сповіщення про наближення до ліміту буфера до початку втрати даних.
• Вимкнення контролю потоку без оцінки ризиків. Чітко визначте, якому виводу дозволено втрачати події, і чи підтримує джерело безпечне призупинення читання.
• Неузгоджені часові мітки. Явно фіксуйте час події (event time) для кожного призначення, щоб зробити подальше порівняння коректним.
• Ігнорування вибіркової фільтрації. Переконайтеся, що кожна SIEM отримує саме ті дані, які необхідні для її задач детекції, розслідувань та комплаєнсу.
• Перетворення тимчасової схеми подвійної відправки на постійну. Визначте точну дату виведення старої платформи з експлуатації під час міграції. Якщо ж довгострокова відправка до архіву чи зовнішнього SOC є плановою, зафіксуйте цю архітектуру та зони відповідальності в регламентах.

Висновок: Побудова надійного пайплайну для кількох SIEM

Розгалуження логів дозволяє доставляти телеметрію безпеки до кількох систем призначення без потреби встановлювати окремі агенти збору під кожну SIEM. NXLog Agent забезпечує паралельну маршрутизацію через кілька виходів, незалежну обробку подій під вимоги кожного отримувача та гнучке керування конвеєром у разі збоїв.

На кінцевих пристроях та серверах розгалуження виконується безпосередньо на агенті. Для мережевих пристроїв та систем, де агент встановити неможливо, централізований розподіл бере на себе шар ретрансляторів (relay). NXLog Platform забезпечує централізоване керування конфігураціями для всього парку агентів, а наскрізні ідентифікатори, звірка підрахунків, моніторинг черг і стрес-тести підтверджують точність і повноту доставки.

Оптимальна архітектура залежить від головної мети: стовідсоткове збереження подій, стабільна доставка до основної SIEM у реальному часі, зменшення витрат на збір даних чи контрольована міграція. Визначте ці пріоритети до початку проєкту, ретельно протестуйте поведінку під час збоїв та налаштуйте моніторинг пайплайну після запуску.

Softprom є офіційним дистриб'ютором NXLog. Ми допомагаємо компаніям тестувати рішення NXLog, проектувати архітектури збору та маршрутизації логів, а також інтегрувати телеметрію з SIEM і платформами безпеки. Зв'яжіться з Softprom, щоб обговорити впровадження NXLog у вашому середовищі.