הקמת איסוף אירועי אבטחה מרכזי עבור SIEM

הקמת איסוף אירועי אבטחה מרכזי עבור SIEM

נתקלתם פעם במצב שבו לאחר תקרית אתם צריכים לאסוף לוגים מ-15 שרתים אחד אחד, עם חותמות זמן שונות בדקות? זה מבזבז שעות על חקירה. אחד הלקוחות שלנו — חברת פינטק עם 200 מיקרוסרוויסים — לפני יישום איסוף מרכזי בילה עד 3 ימים במציאת שורש הבעיה של דליפה. לאחר הקמת צינור ה-SIEM, הזמן ירד לשעתיים. אנחנו פותרים את הבעיה הזו — אנו מגדירים איסוף אירועי אבטחה מרכזי מקצה לקצה, ומבטיחים אספקה ושלמות נתונים. יש לנו ניסיון של 10+ שנים באבטחת תשתיות, ואנחנו יודעים איך להימנע מטעויות נפוצות.

איסוף אירועים מרכזי (צינור SIEM) הוא לא רק השלכת לוגים למקום אחד. זו ארכיטקטורה שמאפשרת לתאם אירועים, לבנות התראות, ולמצוא במהירות את שורש הבעיה של תקרית. להלן נפרק את הארכיטקטורה האופיינית, בחירת סוכנים, תפקיד ה-broker, ותצורות נפוצות.

ארכיטקטורה אופיינית: מה הולך לאן ולמה

מקורות (שרתים, קונטיינרים, שירותי ענן) → סוכנים (Fluent Bit, Filebeat, rsyslog) → message broker (Kafka — אופציונלי) → מעבד/מפענח (Logstash, Vector, Fluentd) → אחסון (Elasticsearch/OpenSearch, Loki, Splunk). יש צורך ב-message broker לנפחים גבוהים (100K+ אירועים/שנייה) או אם האחסון עלול להיות לא זמין — Kafka מאגר עד 7 ימים. לנפחים קטנים (עד 10K אירועים/שנייה), אפשר ללכת ישירות סוכן → אחסון.

השוואת סוכנים פופולריים

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 לא מאבד אירועים בעת אתחול הודות ל-# /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 . להלן תצורות עבור לקוח ושרת בבלוק אחד.

# На каждом сервере-источнике /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: הוא קל יותר, תומך בריבוי ערוצים, ויש לו מערכת תוספים. עבור סביבות syslog טהורות (ציוד רשת, Unix) — rsyslog. Filebeat משתלב היטב במחסנית Elastic. שילוב ביניהם מקובל: לדוגמה, Fluent Bit על K8s, rsyslog על התקני רשת.

Kafka כחיץ לנפחים גבוהים

ב-100K+ אירועים/שנייה או עם מספר יעדי אחסון — 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 לשימור ארוך טווח:

# 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
  }
}

למה סנכרון זמן חשוב לתאם?

ללא זמן מדויק בכל המקורות, תיאום הוא חסר ערך. הפרש של יותר משנייה אחת יכול לשנות את רצף אירועי התקיפה. NTP הוא חובה — באופן אידיאלי שרת NTP פנימי אחד לכל התשתית, מסונכרן עם מספר שרתים חיצוניים. אנו משתמשים ב-chrony, שהוא מהיר ומדויק יותר מ-ntpd. על כל השרתים אנו מגדירים queue.saveonshutdown ומנטרים את ה-offset באמצעות # На каждом сервере-источнике /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") — זה חלק מההתחייבות שלנו.

איך אנחנו עובדים על פרויקט

1. ניתוח: ביקורת תשתית, נפחי לוגים, דרישות שימור.
2. תכנון: בחירת מחסנית (Elastic/Loki, Kafka/ללא), תרשים זרימה.
3. פיילוט: הגדרה על 2-3 מקורות, אימות אספקה.
4. ייצור: פריסת סוכנים על כל הצמתים, הגדרת רוטציה ושימור.
5. תיעוד והדרכת צוות.
6. תמיכה אחריות לחודש לאחר העלייה לאוויר.

מה כלול בפרויקט

• ביקורת תשתית הלוגינג הנוכחית.
• תכנון תוכנית איסוף תוך התחשבות בשימור ועמידה ברגולציה.
• התקנה והגדרה של סוכנים (Fluent Bit, Filebeat, rsyslog) על כל המקורות.
• הגדרת Kafka broker (אם נדרש).
• חיבור אחסון (Elasticsearch/OpenSearch/Loki).
• יצירת דשבורדים והתראות לאירועים מרכזיים.
• תיעוד מלא: דיאגרמות, תצורות, runbook.
• הדרכה לעד 5 מהנדסים.
• אחריות לאספקת לוגים ללא הפרעות.

העלות מחושבת באופן אישי לאחר ביקורת תשתית. אנו מעריכים את הפרויקט ביום אחד. צרו קשר לקבלת ייעוץ. הזמינו פרויקט איסוף לוגים מרכזי — המהנדסים שלנו יבצעו ביקורת ויישמו את הפתרון, ויחסכו לכם עד 30% מזמן התגובה לתקריות.