Буферизація в автономному режимі для інструментів передачі логів: як зберегти журнали безпеки, коли цільова система недоступна

Офлайн-буферизація (Offline buffering) — це здатність збирача логів тимчасово зберігати події у разі недоступності системи призначення та автоматично пересилати їх після відновлення зв'язку. Без ефективної буферизації збій SIEM, мережевий збій або перезапуск агента можуть призвести до безповоротних прогалин у телеметрії безпеки.

Будь-яке SIEM-середовище рано чи пізно стикається з перервами в роботі. Те саме стосується WAN-з'єднань, центральних колекторів та інфраструктури, на якій розгорнуто стек управління логами. Такі інциденти не повинні призводити до втрати даних безпеки, але підсумковий результат сильно залежить від того, як ваша технологія збору логів обробляє події під час порушення доставки.

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

Що таке офлайн-буферизація у збирачі логів?

Збирач логів розташовується між джерелами подій (такими як журнал подій Windows, syslog, файли та додатки) та системами призначення (такими як SIEM, озеро даних, база даних або центральний колектор).

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

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

Ефективна буферизація змінює ситуацію з «втрати даних» на «затримку доставки».

Малюнок 1. Де конвеєр логів зберігає події у разі недоступності цільової системи.

Де конвеєри логів можуть втрачати дані

Кілька поширених сценаріїв збоїв можуть призвести до втрати логів. Кожен із них вимагає відповідного механізму захисту.

Цільова система стає недоступною

Технічне обслуговування SIEM, обмеження швидкості зчитування (throttling), збої сервісів, ліцензійні ліміти або квоти можуть завадити приймачу приймати нові події. Збирачу логів потрібна достатня ємність черги або буфера для утримання цих подій до відновлення цільової системи.

Збій мережевого з'єднання

Обрив VPN-тунелю, збій WAN, проблеми з маршрутизацією або перевантаження мережевого каналу можуть призвести до того ж ефекту, що й збій SIEM. У цих ситуаціях важливу роль відіграють як ємність буфера, так і управління зворотним тиском (backpressure).

Перезапуск агента або хоста

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

Джерело не може бути призупинено

Деякі джерела логів, особливо UDP syslog та локальні сокети /dev/log, не можуть просто чекати, поки колектор стане доступним. Якщо приймач припиняє прийом даних, операційна система або додаток-відправник можуть відкинути події до того, як збирач встигне їх обробити.

Буферизація в оперативній пам'яті проти дискової буферизації

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

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

Як NXLog Agent буферизує логи при недоступності призначення

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

Черги логів та управління потоком (Flow Control)

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

Для черг в оперативній пам'яті розмір за замовчуванням становить 2 МБ (MiB) з мінімумом у 512 КБ (KiB). Коли черга наближається до налаштовуваної ємності, NXLog Agent використовує управління потоком (flow control) для створення зворотного тиску (backpressure) на вищестоящі модулі.

Для джерел, які можна призупинити (таких як файли, журнал подій Windows та TCP-з'єднання), це дозволяє тимчасово уповільнити або призупинити збір, замість безперервної генерації неконтрольованого обсягу необроблених даних.

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

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

Постійні черги для захисту від збоїв

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

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

<Input windows_events>
    Module             im_msvistalog
</Input>

<Output siem>
    Module             om_elasticsearch
    URL                https://siem.example.com:9200/_bulk
    LogqueueSize       4194304
    PersistLogqueue    TRUE
    SyncLogqueue       TRUE
</Output>

<Route r1>
    Path               windows_events => siem
</Route>

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

Виділені буфери для тривалих збоїв

Черги логів насамперед призначені для створення зворотного тиску та згладжування короткочасних затримок. Для триваліших збоїв може знадобитися спеціалізований модуль процесора Buffer (pm_buffer).

Модуль Buffer може підтримувати буфери як в оперативній пам'яті, так і на диску, і дозволяє адміністраторам задавати максимальну ємність за допомогою MaxSize. Необов'язковий параметр WarnLimit генерує попередження до того, як буфер досягне свого максимального розміру.

<Input syslog_udp>
    Module        im_udp
    ListenAddr    0.0.0.0:514
</Input>

<Processor disk_buffer>
    Module        pm_buffer
    Type          Disk
    MaxSize       512000
    WarnLimit     409600
</Processor>

<Output siem>
    Module        om_http
    URL           https://siem.example.com:8080/
</Output>

<Route r1>
    Path          syslog_udp => disk_buffer => siem
</Route>

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

Обробка джерел, які не можна призупинити

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

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

Локальні сокети /dev/log вимагають особливої уваги. Призупинення зчитування може заблокувати виклик syslog() для додатків на всьому хості. У таких сценаріях управління потоком можна вимкнути, одночасно збільшивши обсяг нижчестоящих черг або виділених буферів.

<Extension syslog>
    Module          xm_syslog
</Extension>

<Input dev_log>
    Module          im_uds
    UDS             /dev/log
    Exec            parse_syslog();
    FlowControl     FALSE
</Input>

<Output siem>
    Module          om_elasticsearch
    URL             https://siem.example.com:9200/_bulk
    LogqueueSize    4194304
</Output>

<Route r1>
    Path            dev_log => siem
</Route>

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

Буферизація — це не те саме, що підтвердження доставки

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

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

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

Такий підхід забезпечує доставку за принципом «як мінімум один раз» (at-least-once delivery). Якщо цільова система чутлива до дублікатів подій, слід налаштувати відповідні механізми дедуплікації.

Управління цими налаштуваннями вручну на сотнях або тисячах систем швидко стає непрактичним. Платформа NXLog Platform забезпечує централізоване управління конфігураціями, групування агентів та моніторинг, дозволяючи одноманітно розгортати політики буферизації по всій інфраструктурі.

Якої ємності має бути буфер логів?

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

Проста формула розрахунку:

Необхідний розмір буфера = кількість подій за секунду × середній розмір події × тривалість збою

Наприклад, агент, що обробляє 2 000 подій за секунду при середньому розмірі події 800 байт, генерує приблизно 1,6 МБ даних за секунду, або близько 5,8 ГБ за годину.

Щоб витримати чотиригодинний збій SIEM, системі знадобиться буфер ємністю приблизно 23 ГБ без урахування додаткового запасу надійності.

При розрахунку ємності враховуйте таке:

• Вимірюйте реальний розмір подій. Події безпеки Windows можуть бути суттєво більшими за окремі повідомлення syslog від міжмережевих екранів.
• Встановлюйте поріг раннього попередження. Параметр WarnLimit на рівні близько 80% від MaxSize дає час на реагування до повного заповнення буфера.
• Використовуйте виділене сховище, де це можливо. Переповнення кореневої файлової системи може перетворити проблему збору логів на збій доступності всього хоста.
• Передбачайте додатковий запас. Раптові сплески обсягу подій можуть витратити буфер значно швидше за середнє значення.

Тестуйте буфер до настання реального збою

Стратегію буферизації слід протестувати до того, як вона знадобиться під час реального інциденту.

NXLog Agent містить інструменти для симуляції недоступності цільової системи. Модуль виведення Blocker (om_blocker) може імітувати недоступний приймач, а модуль процесу Blocker (pm_blocker) дозволяє блокувати або розблоковувати маршрут за вимогою або розкладом.

<Input app_logs>
    Module       im_file
    File         '/var/log/app/*.log'
</Input>

<Processor disk_buffer>
    Module       pm_buffer
    Type         Disk
    MaxSize      512000
    WarnLimit    409600
</Processor>

<Output blackhole>
    Module       om_blocker
</Output>

<Route outage_drill>
    Path         app_logs => disk_buffer => blackhole
</Route>

Під час тестування перевірте три ключові аспекти:

1. Буфер заповнюється приблизно з тією швидкістю, яка передбачалася розрахунками ємності.
2. Попередження WarnLimit з'являються в логах NXLog Agent у міру наближення буфера до порогового значення.
3. Накопичені дані успішно та у правильному порядку відправляються після того, як цільова система знову стає доступною.

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

Непротестований буфер — це лише припущення, а не перевірений захід забезпечення надійності.

Як популярні збирачі логів обробляють офлайн-буферизацію

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

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

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

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

Продовжуйте збір логів, навіть коли SIEM недоступна

Надійність збору логів — важлива частина сучасної архітектури безпеки. Збій цільової системи не повинен автоматично призводити до безповоротної втрати телеметрії безпеки.

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

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

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

Часті запитання

Чи втрачає збирач логи при недоступності SIEM?

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

У чому різниця між чергами логів NXLog Agent та модулем процесора Buffer?

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

Що використовувати: буферизацію в пам'яті чи на диску?

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

Чи гарантує офлайн-буферизація доставку?

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

Як протестувати офлайн-буферизацію?

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