Налаштування централізованого збору подій безпеки в SIEM

Централізований збір подій безпеки: налаштування

Стикалися з ситуацією, коли після інциденту логи доводиться збирати по крихтах з 15 серверів, а на деяких час різниться на хвилини? Це втрачає години на розслідування. Один із наших клієнтів — фінтех-компанія з 200 мікросервісами — до впровадження централізованого збору витрачав до 3 днів на пошук першопричини витоку. Після налаштування SIEM-пайплайну час скоротився до 2 годин. Ми вирішуємо цю проблему — налаштовуємо централізований збір подій безпеки під ключ, гарантуючи доставку та збереження даних. У нашій практиці 10+ років досвіду в інфраструктурній безпеці, і ми знаємо, як уникнути типових помилок.

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

Типова архітектура централізованого збору подій безпеки

Джерела (сервери, контейнери, хмарні сервіси) → агенти (Fluent Bit, Filebeat, rsyslog) → брокер повідомлень (Kafka — опціонально) → процесор/парсер (Logstash, Vector, Fluentd) → сховище (Elasticsearch/OpenSearch, Loki, Splunk). Брокер повідомлень потрібен при високих обсягах (100K+ events/sec) або якщо сховище може бути недоступним — Kafka буферизує до 7 днів. При невеликих обсягах (до 10K events/sec) можна напряму агент → сховище.

Порівняння популярних агентів

Fluent Bit у 10 разів легший за Filebeat за споживанням пам'яті, що критично для високонавантажених вузлів.

Fluent Bit: легковаговий агент для хостів та контейнерів

Fluent Bit — 450KB бінарник, споживає ~1MB RAM на агент. Для високонавантажених серверів та для K8s DaemonSet це критично.

# /etc/fluent-bit/fluent-bit.conf
[SERVICE]
    Flush 5
    Daemon Off
    Log_Level info
    Parsers_File parsers.conf

[INPUT]
    Name tail
    Tag audit.*
    Path /var/log/audit/audit.log
    Parser auditd
    DB /var/lib/fluent-bit/audit.db
    Mem_Buf_Limit 50MB
    Skip_Long_Lines Off
    Refresh_Interval 10

[INPUT]
    Name tail
    Tag auth.*
    Path /var/log/auth.log
    Parser syslog-rfc3164
    DB /var/lib/fluent-bit/auth.db
    Mem_Buf_Limit 10MB

[INPUT]
    Name systemd
    Tag systemd.*
    Systemd_Filter _SYSTEMD_UNIT=sshd.service
    Systemd_Filter _SYSTEMD_UNIT=sudo.service

[FILTER]
    Name modify
    Match *
    Add host ${HOSTNAME}
    Add environment production
    Add datacenter eu-west-1

[OUTPUT]
    Name http
    Match *
    Host 192.168.1.101
    Port 3100
    URI /loki/api/v1/push
    Format json
    Retry_Limit 5

rsyslog для централізації через syslog-протокол

Для інфраструктури де вже є rsyslog — форвардинг на центральний сервер. Ми гарантуємо, що при перезапуску rsyslog не втрачає події завдяки queue.saveonshutdown. Нижче показані конфігурації для клієнта та сервера в одному блоці.

# На кожному сервері-джерелі /etc/rsyslog.d/99-central-syslog.conf
action(type="omfwd" Target="192.168.1.100" Port="6514" Protocol="tcp" StreamDriver="gtls" StreamDriverMode="1" StreamDriverAuthMode="x509/name" StreamDriverPermittedPeers="syslog.internal" queue.type="LinkedList" queue.size="100000" queue.filename="fwdq" queue.maxdiskspace="1g" queue.saveonshutdown="on" action.resumeRetryCount="-1")
# На центральному сервері /etc/rsyslog.d/00-receive.conf
module(load="imtcp" StreamDriver.AuthMode="x509/certvalid" StreamDriver.Name="gtls" PermittedPeer=["*.internal.example.com"])
input(type="imtcp" port="6514")
template(name="DynFile" type="string" string="/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log")
*.* action(type="omfile" DynaFile="DynFile")

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

Який агент обрати: Fluent Bit, Filebeat або rsyslog?

У сучасних проектах ми частіше використовуємо Fluent Bit: він легший, підтримує мультиплексування, plugin-екосистему. Для чистого syslog-оточення (мережеве обладнання, Unix) — rsyslog. Filebeat добре лягає у стек Elastic. Комбінувати допустимо: наприклад, Fluent Bit на K8s, rsyslog на мережевих пристроях.

Kafka як буфер при високих обсягах

При 100K+ events/sec або кількох сховищах — Kafka в середині. Kafka забезпечує в 5 разів вищу пропускну здатність порівняно з прямим записом у сховище при пікових навантаженнях.

---
# Filebeat → Kafka топик
output.kafka:
  hosts: ["192.168.1.103:9092", "192.168.1.104:9092", "192.168.1.105:9092"]
  topic: 'security-events-%{[agent.hostname]}'
  partition.round_robin:
    reachable_only: false
  required_acks: 1
  compression: gzip
  max_message_bytes: 1000000
---

Logstash читає з Kafka та пише в Elasticsearch + одночасно в S3 для long-term retention:

# logstash.conf
input {
  kafka {
    bootstrap_servers => "192.168.1.103:9092,192.168.1.104:9092"
    topics => ["security-events-.*"]
    group_id => "logstash-security"
    codec => json
  }
}
filter {
  if [event][module] == "auditd" {
    mutate {
      add_tag => ["audit", "compliance"]
    }
  }
  geoip {
    source => "[source][ip]"
  }
}
output {
  elasticsearch {
    hosts => ["https://192.168.1.110:9200", "https://192.168.1.111:9200"]
    index => "security-events-%{+YYYY.MM.dd}"
    template_name => "security-events"
  }
  s3 {
    bucket => "security-events-archive"
    region => "eu-west-1"
    prefix => "raw/%{+YYYY/MM/dd}/"
    codec => json_lines
    buffer_interval => 900
  }
}

Чому важлива синхронізація часу для кореляції?

Без точного часу на всіх джерелах correlation марна. Різниця більше 1 секунди може змістити послідовність подій атаки. NTP — обов'язково, і бажано один внутрішній NTP-сервер для всієї інфраструктури, синхронізований з кількома зовнішніми. Використовуємо chrony, він швидший і точніший за ntpd. На всіх серверах налаштовуємо server 192.168.1.102 iburst prefer і моніторимо offset через chronyc tracking — це також частина нашої гарантії.

Процес роботи над проектом

1. Аналітика: аудит інфраструктури, обсягів логів, вимог до зберігання.
2. Проектування: вибір стеку (Elastic/Loki, Kafka/ні), схема потоків.
3. Пілот: налаштування на 2-3 джерелах, перевірка доставки.
4. Продакшн: розгортання агентів на всіх вузлах, налаштування ротації та retention.
5. Документація та навчання команди.
6. Гарантійна підтримка 1 місяць після введення.

Що входить у проект

• Аудит поточної інфраструктури логування.
• Проектування схеми збору з урахуванням retention та compliance.
• Встановлення та конфігурація агентів (Fluent Bit, Filebeat, rsyslog) на всіх джерелах.
• Налаштування брокера Kafka (якщо потрібен).
• Підключення сховища (Elasticsearch/OpenSearch/Loki).
• Створення дашбордів та алертів за ключовими подіями.
• Повна документація: схеми, конфіги, runbook.
• Навчання до 5 інженерів.
• Гарантія безперебійної доставки логів.

Зв'яжіться з нами, щоб отримати консультацію. Замовте проект централізованого збору логів — наші інженери проведуть аудит і впровадять рішення, а економія часу на incident-response складе до 30%.