SIEMهای مدرن برای اینکه بتوانند با حجم بالای Telemetry (تلمتری/لاگ و رخداد)، تنوع منابع (EDR، Cloud، Network، IAM) و نیاز به Near Real-Time Detection (تشخیص نزدیک به بلادرنگ) کنار بیایند، ناچارند از معماریهای Stream Processing (پردازش جریانی) استفاده کنند. در این معماریها دادهها بهصورت پیوسته وارد خط پردازش میشوند، غنیسازی (Enrichment)، همبستگی (Correlation)، نرمالسازی و در نهایت تولید Alert انجام میشود.
در این اکوسیستم، دو نام بسیار پرکاربرد دیده میشود:
- Apache Kafka (کافکا): ستون فقرات انتقال رویداد و Event Backbone
- Apache Flink (فلینک): موتور پردازش جریانی stateful برای محاسبات پیچیده و real-time analytics
اما Kafka و Flink رقیب مستقیم یکدیگر نیستند؛ هرکدام نقش متفاوتی در معماری SIEM بازی میکنند. سوال درست معمولاً این است: «کجا Kafka کافی است؟ کجا باید Flink اضافه شود؟ و trade-offها چیست؟»
SIEM مدرن چرا به Stream Processing نیاز دارد؟
در SIEMهای نسل جدید، چند نیاز کلیدی باعث مهاجرت از معماری batch/ETL سنتی به پردازش جریانی شده است:
Latency پایین برای Detection
قوانین و مدلها باید در چند ثانیه تا چند ده ثانیه نتیجه دهند.
پایداری در برابر Burst و Spike
مثلاً یک Outage، یک اسکن داخلی، یا یک کمپین Brute Force میتواند حجم رخداد را چند برابر کند.
تفکیک Ingestion از Processing
برای جلوگیری از اینکه تغییرات در pipeline باعث Down شدن ingestion شود.
قابلیت Reprocessing
برای زمانی که Rule اصلاح میشود یا Threat Intel جدید اضافه میشود و باید تاریخچه دوباره پردازش شود.
معماری مرجع Stream Processing در SIEM
یک مدل رایج (Vendor-neutral) در SIEMهای مدرن:
- Collectors/Forwarders (Syslog, Beats, Agents, Cloud connectors)
- Message Bus / Event Streaming Platform (معمولاً Kafka)
- Stream Processing Layer (Flink / Spark Streaming / Kafka Streams)
- Enrichment Services (Asset DB, CMDB, IAM, Threat Intel, GeoIP)
- Detection Layer (Correlation + UEBA + ML)
- Storage (Hot: Elasticsearch/OpenSearch، Cold: Object Storage)
- Alerting/Case Management/SOAR integration
Kafka در SIEM: نقش، نقاط قوت، محدودیتها
Kafka چیست (در این بحث)؟
Kafka یک Distributed Commit Log (لاگ توزیعشده) و Event Streaming Platform است؛ یعنی تمرکزش روی انتقال قابل اعتماد رویداد، Buffering، Decoupling و Replay است.
Kafka در SIEM چه کارهایی را عالی انجام میدهد؟
Ingestion با throughput بالا
Kafka برای میلیونها event در ثانیه طراحی شده و با partitioning به خوبی scale میشود.
جدا کردن Producer و Consumer
تیم Detection میتواند pipeline را تغییر دهد بدون اینکه ingestion قطع شود.
Replay / Backfill
اگر یک Use Case خراب بوده یا enrichment جدید اضافه شده، میتوان از offsetها دوباره مصرف کرد.
Routing و Fan-out
یک event میتواند همزمان به چند consumer برسد:
- ذخیرهسازی
- threat hunting
- detection real-time
- data lake
Kafka کجا محدود میشود؟
Kafka به خودی خود موتور پردازش پیچیده نیست. بله، با Kafka Streams میتوانید پردازش انجام دهید، اما:
مدیریت state پیچیده در سناریوهای سنگین correlation دشوارتر میشود
پردازشهای event-time و windowهای پیچیده محدودترند
نیاز به کنترل دقیق watermark، late events و exactly-once در محاسبات سنگین دارید
Flink در SIEM: نقش، نقاط قوت، محدودیتها
Flink چیست؟
Flink یک Stateful Stream Processing Engine (موتور پردازش جریانی با حالت/State) است که برای پردازشهای پیچیده نزدیک به real-time ساخته شده: windowing، joins، CEP، event-time semantics و fault tolerance.
Flink در SIEM کجا میدرخشد؟
Correlation پیشرفته و Stateful Detection
SIEM برای تشخیصهای جدی نیاز به نگهداری state دارد، مثلاً:
- «اگر یک user در ۱۰ دقیقه از دو کشور مختلف login کرد»
- «اگر یک host در ۵ دقیقه ۱۰۰ اتصال ناموفق داشت و سپس یک موفقیت رخ داد»
اینها window + state + ordering میخواهند.
Complex Event Processing – CEP (پردازش رخداد پیچیده)
الگوهای چندمرحلهای حمله مثل:
Initial Access → Priv Esc → Lateral Movement
در Flink CEP به شکل طبیعیتر مدل میشود.
Event-time و Late events
در SIEM لاگها همیشه به ترتیب نمیرسند (Cloud log delays، network jitter). Flink با watermark و event-time semantics بهتر از بسیاری گزینهها مدیریت میکند.
Exactly-once state consistency
برای سناریوهایی که خروجی باید دقیق باشد (مثلاً شمارشهای حساس، detectionهای مبتنی بر threshold).
Flink چه هزینهای دارد؟
پیچیدگی عملیاتی: مدیریت cluster، checkpointing، state backend
نیاز به مهارت تخصصی: تیم باید Flink را بفهمد (job lifecycle، backpressure، tuning)
هزینه منابع: stateful processing RAM/IO بیشتری میخواهد
