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

Офлайн-буферизация (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 для временной блокировки маршрута. Отслеживайте рост буфера, пороговые предупреждения и полное восстановление отправки накопленной очереди после того, как целевая система снова станет доступной.