Настройка централизованного сбора событий безопасности в 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 loki.internal.example.com
    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="syslog.internal.example.com" Port="6514" Protocol="tcp" StreamDriver="gtls" StreamDriverMode="1" StreamDriverAuthMode="x509/name" StreamDriverPermittedPeers="syslog.internal.example.com" 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 в середине:

# Filebeat → Kafka топик
output.kafka:
  hosts: ["kafka1:9092", "kafka2:9092", "kafka3: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 => "kafka1:9092,kafka2: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://es1:9200", "https://es2: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 ntp.internal.example.com 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 инженеров.
• Гарантия бесперебойной доставки логов.

Стоимость рассчитывается индивидуально после аудита инфраструктуры. Мы оценим проект за 1 день. Свяжитесь с нами, чтобы получить консультацию. Закажите проект централизованного сбора логов — наши инженеры проведут аудит и внедрят решение, а экономия времени на инцидент-респонс составит до 30%.