بخش ۲ — خانوادهٔ سرورهای لاگ مرکزی: نقشهٔ کامل ابزارها
در بخش قبل دیدیم که چرا لاگ پراکنده در شبکه‌های بزرگ شکست می‌خورد. اما «مرکزیت» یک ابزار واحد نیست؛ یک خانوادهٔ کامل از ابزارها است که هرکدام بخشی از پاسخ را فراهم می‌کنند. نشناختن این خانواده، دلیلی است که سازمان‌ها ابزار اشتباه را برای مسئلهٔ اشتباه می‌خرند.
این خانواده پنج عضو اصلی دارد، به‌علاوهٔ چند ابزار مکمل که معماری بدون آن‌ها کار نمی‌کند. در این بخش، هر عضو را یکی‌یکی معرفی می‌کنیم و می‌گوییم چه کاری می‌کند، چه کاری نمی‌کند و کجای معماری می‌نشیند.
چرا «سرور لاگ» یک واژهٔ گمراه‌کننده است
وقتی کسی می‌گوید «ما یک سرور لاگ داریم»، همین یک جمله می‌تواند به ده چیز مختلف اشاره کند. ممکن است یک سرور سادهٔ rsyslog باشد که پیام‌های شبکه را در فایل می‌نویسد، یا یک کلاستر Elasticsearch که میلیون‌ها لاگ را ایندکس می‌کند. ممکن است یک SIEM سازمانی باشد که تهدیدها را همبسته می‌کند، یا ترکیبی از همهٔ این‌ها.
این ابهام در عمل خطرناک است. سازمانی که فکر می‌کند «سرور لاگ» دارد، شاید در واقع فقط یک انبار فایل داشته باشد و در لحظهٔ حادثه بفهمد نه ابزار جست‌وجو دارد و نه ابزار تحلیل. حالت برعکس هم دیده می‌شود: سازمانی که یک SIEM گران‌قیمت خریده، ممکن است بفهمد هیچ‌کس قواعد همبستگی را تنظیم نکرده و آن SIEM فقط یک صفحهٔ نمایش بی‌فایده است.
راه‌حل این است که خانواده را بشناسیم و بدانیم هر عضو چه نقشی دارد. در ادامه، پنج عضو اصلی این خانواده را یکی‌یکی با نام، نقش و مرزهایشان معرفی می‌کنیم.
سرور Syslog
ساده‌ترین و قدیمی‌ترین عضو خانواده. یک سرور Syslog برنامه‌ای است که پیام‌های Syslog را از دستگاه‌های شبکه دریافت، ذخیره و قابل جست‌وجو می‌کند. این پیام‌ها معمولاً از روترها، سوئیچ‌ها، فایروال‌ها و سرورهای لینوکسی می‌آیند که از پروتکل استاندارد Syslog استفاده می‌کنند.
چه کاری می‌کند: جمع‌آوری، ذخیره‌سازی و نمایش پیام‌ها. برخی نسخه‌ها حتی می‌توانند SNMP Trap را هم دریافت کنند. برای تیمی که عملیات شبکه را بر عهده دارد و می‌خواهد بداند چرا یک سوئیچ مرتب ری‌استارت می‌شود، همین ابزار کافی و مناسب است.
چه کاری نمی‌کند: تحلیل امنیتی پیشرفته، همبستگی رویدادها یا پاسخ خودکار. نهایت کاری که یک سرور Syslog خوب انجام می‌دهد، ارسال ایمیل هشدار است وقتی چند بار ورود ناموفق ثبت شود.
مثال از دنیای واقعی: rsyslog که در نوشتهٔ قبلی دربارهٔ معماری آن صحبت کردیم، syslog-ng و Kiwi Syslog Server. این ابزارها معمولاً متن‌باز یا ارزان‌قیمت‌اند و روی هر توزیع لینوکسی نصب می‌شوند.
سرور Syslog یک «لوله» است، نه یک «مغز». اگر فقط به جمع‌آوری نیاز دارید کافی است، و اگر به تحلیل نیاز دارید باید یک لایه بالاتر بروید.
سیستم مدیریت لاگ (Log Management System / LMS)
یک پله بالاتر از سرور Syslog خام. سیستم مدیریت لاگ داده را از منابع بسیار متنوع‌تری، نه فقط از Syslog، جمع می‌کند، آن را نرمال‌سازی و ایندکس می‌کند و امکان جست‌وجوی سریع در حجم عظیم داده را فراهم می‌سازد. هدف اصلی این سیستم‌ها قابل استفاده کردن داده است، نه لزوماً تحلیل امنیتی.
چه کاری می‌کند: جمع‌آوری از منابع متعدد مثل فایل، API و Agent، نرمال‌سازی قالب‌ها، ذخیره‌سازی بلندمدت، جست‌وجوی سریع، داشبوردهای تصویری، و تحلیل عملکرد و عیب‌یابی. این سیستم به سؤال «چه اتفاقی افتاد؟» پاسخ می‌دهد، نه به سؤال «آیا این اتفاق خطرناک است؟».
چه کاری نمی‌کند: تحلیل امنیتی پیشرفته. سیستم مدیریت لاگ می‌تواند نشان دهد کاربری ساعت ۳ بامداد از یک IP جدید وارد شده، اما نمی‌تواند بگوید این ورود بخشی از یک زنجیرهٔ حمله است. برای این کار به SIEM نیاز است.
مثال از دنیای واقعی: Elastic Stack که قبلاً ELK نامیده می‌شد، یعنی Elasticsearch به‌علاوهٔ Logstash به‌علاوهٔ Kibana به‌علاوهٔ Beats، یکی از محبوب‌ترین گزینه‌های متن‌باز است. Beats لاگ‌ها را جمع می‌کند، Logstash آن‌ها را پردازش می‌کند، Elasticsearch ایندکس و ذخیره می‌کند و Kibana نمایش می‌دهد. Graylog هم گزینهٔ دیگری است. Loki از Grafana رویکرد سبک‌تری دارد: فقط برچسب‌ها را ایندکس می‌کند و متن لاگ را فشرده در ذخیره‌سازی ارزان نگه می‌دارد.
پلتفرم Elastic Stack به‌خودی‌خود یک SIEM نیست؛ یک بستر است که می‌توانید روی آن قابلیت‌های شبیه SIEM بسازید. قواعد همبستگی، هشدارها و منطق تشخیص را باید خودتان بنویسید و در نسخهٔ رایگان موتور همبستگی داخلی وجود ندارد. ابزارهایی مثل Elastalert تا حدی این شکاف را پر می‌کنند.
خودِ SIEM (Security Information and Event Management)
حالا به SIEM می‌رسیم که در جایگاه خودش روی سیستم مدیریت لاگ می‌نشیند. SIEM یک سیستم مدیریت لاگ است که یک لایهٔ تحلیل امنیتی روی آن اضافه شده است. تفاوت کلیدی در همان لایهٔ اضافه است: همبستگی رویدادها (Event Correlation) و تشخیص تهدید.
چه کاری می‌کند: همهٔ کارهای یک سیستم مدیریت لاگ را انجام می‌دهد، به‌علاوهٔ قواعد همبستگی، تطبیق با پایگاه دادهٔ تهدیدات شناخته‌شده، هشدارهای امنیتی با اولویت و در نسخه‌های پیشرفته پاسخ خودکار. نمونهٔ یک قاعدهٔ همبستگی این است: «اگر ورود ناموفق، سپس دسترسی به پوشهٔ مالی و سپس حجم غیرعادی داده». SIEM به سؤال «آیا این اتفاق خطرناک است؟» پاسخ می‌دهد.
تفاوت بنیادین با سیستم مدیریت لاگ: یک سیستم مدیریت لاگ می‌گوید «کاربر X از یک IP جدید وارد شد.» یک SIEM همین را با داده‌های دیگر ترکیب می‌کند و می‌گوید «کاربر X که قبلاً هرگز از این IP وارد نشده بود، ساعت ۳ بامداد وارد شد، سپس تلاش کرد سطح دسترسی خودش را بالا ببرد و بعد از آن ۵۰۰ رکورد از پایگاه داده را خواند. این ترکیب با الگوی یک نفوذ داخلی مطابقت دارد.» این همان همبستگی است.
مثال از دنیای واقعی: Splunk که هم قابلیت مدیریت لاگ دارد و هم SIEM، Wazuh که متن‌باز است و بر تشخیص نفوذ و انطباق تمرکز دارد، و IBM QRadar یا Microsoft Sentinel در سطح سازمانی. SIEM برای تیم امنیت (SecOps) و مرکز عملیات امنیت (SOC) ساخته شده، نه برای عیب‌یابی روزمرهٔ یک سرویس.
این ابزار گران و پیچیده است و اگر درست تنظیم نشود، سیل هشدارهای کاذب تولید می‌کند و تیم امنیت را فرسوده می‌کند. یک SIEM بدون قواعد همبستگی تنظیم‌شده، فقط یک سیستم مدیریت لاگ گران‌قیمت است.
خودِ SOAR (Security Orchestration, Automation and Response)
یک لایهٔ دیگر که روی SIEM می‌نشیند. SOAR خودش لاگ جمع نمی‌کند، یا خیلی کم، بلکه از داده‌ای که SIEM فراهم کرده استفاده می‌کند تا **پاسخ به تهدید را خودکار کند. اگر SIEM بگوید «این یک حمله است»، SOAR می‌تواند به‌طور خودکار فایروال را به‌روزرسانی کند، حساب کاربری را قفل کند یا یک تیکت برای تیم پشتیبانی باز کند.
تفاوت با SIEM: SIEM تشخیص می‌دهد، SOAR پاسخ می‌دهد. SOAR یک پلی‌بوک (Playbook) اجرا می‌کند، یعنی مجموعه‌ای از اقدامات از پیش تعریف‌شده که در پاسخ به یک نوع حادثه اجرا می‌شوند. SIEM یک ابزار تحلیلی است و SOAR یک ابزار عملیاتی.
مثال از دنیای واقعی: Cortex XSOAR از شرکت Palo Alto و Shuffle که متن‌باز است. این ابزارها برای سازمان‌هایی هستند که حجم حوادث امنیتی از توان پاسخ دستی تیمشان بیشتر شده است.
این ابزار گران و پیچیده است و نیازمند تیم بالغی است که پلی‌بوک‌ها را طراحی و نگهداری کند. برای سازمانی که تازه شروع کرده، SOAR زود است.
خودِ XDR (Extended Detection and Response)
نسل جدیدتری که تمرکزش روی یکپارچه کردن داده‌های امنیتی از منابع پراکنده، یعنی Endpoint، شبکه، ایمیل و ابر، و تحلیل خودکار آن‌هاست. XDR از EDR یعنی Endpoint Detection and Response تکامل یافته است: EDR فقط روی Endpoint تمرکز داشت، XDR دامنه را به شبکه، سرور، ابر و فراتر گسترش می‌دهد.
تفاوت با SIEM: SIEM روی «جمع‌آوری همه‌چیز» تمرکز دارد و سپس تحلیل می‌کند. XDR روی «جمع‌آوری هدفمند داده‌هایی که بالاترین اثربخشی تشخیص را دارند» تمرکز دارد و از Endpoint به‌عنوان لنگر همبستگی استفاده می‌کند. XDR اغلب به‌عنوان مکمل SIEM معرفی می‌شود، نه جایگزین آن: SIEM انبار داده و موتور همبستگی است و XDR لایهٔ تحلیل و پاسخ سریع‌تر روی آن.
مثال از دنیای واقعی: CrowdStrike Falcon، Cisco XDR و Microsoft Defender XDR. این ابزارها در شبکه‌های بزرگی که چندین ابزار امنیتی جداگانه دارند و می‌خواهند دید یکپارچه‌ای روی همه داشته باشند، ارزش پیدا می‌کنند.
این ابزار معمولاً با اکوسیستم یک فروشنده گره خورده است و انعطاف‌پذیری SIEM را برای قواعد سفارشی ندارد. اگر سازمان شما از چند فروشندهٔ مختلف ابزار امنیتی استفاده می‌کند، XDR ممکن است دید کاملی ندهد.
اعضای مکمل: لوله‌ها و پل‌ها
علاوه بر اعضای اصلی، چند ابزار مکمل وجود دارند که نقش «لوله» را بازی می‌کنند و بدون آن‌ها معماری کار نمی‌کند.
فرستندهٔ لاگ (Log Shipper): یک عامل سبک، یعنی Agent، روی هر سرور که فایل‌های لاگ را می‌خواند و به سیستم مرکزی می‌فرستد. مسئولیت‌هایش خواندن فایل، پردازش اولیهٔ قالب، افزودن متادیتا مثل نام میزبان و محیط، بافر کردن در صورت قطعی مقصد و ارسال به سیستم مرکزی است. نمونه‌ها Filebeat برای ELK، Fluentd، Fluent Bit، Vector و Promtail برای Loki هستند.
ریلی لاگ (Log Relay): یک سرور میانی که لاگ‌ها را از چند منبع جمع می‌کند و به مقصد نهایی می‌فرستد. ریلی مخصوصاً وقتی مفید است که بخواهید بین شبکه‌های مختلف لاگ منتقل کنید و دسترسی بین شبکه‌ها را محدود کنید. ریلی می‌تواند پردازش اضافه مثل فیلتر کردن و تبدیل داده هم انجام دهد.
تجمیع‌کننده (Log Aggregator): یک سرویس مرکزی که لاگ‌های ارسال‌شده را دریافت می‌کند. این می‌تواند یک سرور سادهٔ rsyslog باشد، یک کلاستر Elasticsearch یا Loki.
این ابزارها خودشان SIEM نیستند و تحلیل امنیتی انجام نمی‌دهند؛ فقط داده را جابه‌جا می‌کنند. بدون آن‌ها، هیچ‌کدام از اعضای اصلی خانواده ورودی ندارد.
جدول مقایسهٔ جامع
جدول زیر پنج عضو اصلی و ابزارهای مکمل را کنار هم می‌گذارد تا تفاوت میان جمع‌آوری، جست‌وجو، تشخیص، پاسخ و حمل در یک نگاه دیده شود.
| نوع | هدف اصلی | چه چیزی جمع می‌کند | مخاطب اصلی | مثال | آیا تحلیل امنیتی می‌کند؟ |
|---|---|---|---|---|---|
| سرور Syslog | تمرکز پیام‌های شبکه | پیام‌های Syslog از روتر، سوئیچ و فایروال | NetOps | مانند rsyslog، syslog-ng، Kiwi | خیر (فقط ذخیره و نمایش) |
| سیستم مدیریت لاگ (LMS) | جست‌وجو و تحلیل داده | لاگ از هر منبعی (فایل، API، Agent) | DevOps، SRE، انطباق | مانند Elastic Stack، Graylog، Loki | خیر (مگر اینکه خودتان اضافه کنید) |
| خودِ SIEM | تشخیص تهدید امنیتی | لاگ امنیتی و همبستگی | SecOps، SOC | مانند Splunk، Wazuh، QRadar، Sentinel | بله (همبستگی و هشدار) |
| خودِ SOAR | خودکارسازی پاسخ | داده از SIEM | SOC (پاسخ به حادثه) | مانند Cortex XSOAR، Shuffle | خیر (فقط پاسخ می‌دهد) |
| خودِ XDR | دید یکپارچهٔ امنیتی | Endpoint و شبکه و ابر | تیم امنیت | مانند CrowdStrike، Cisco XDR | بله (تحلیل و پاسخ) |
| فرستندهٔ لاگ | حمل داده | فایل‌های لاگ محلی | همه | مانند Filebeat، Fluentd، Vector | خیر (فقط حمل می‌کند) |
معماری مرجع: این ابزارها روی هم می‌نشینند، نه به‌جای هم
یک اشتباه رایج این است که فکر کنیم باید «یکی را انتخاب کنیم». در عمل، این ابزارها لایه‌لایه روی هم می‌نشینند. یک معماری مرجع سه‌لایه به این شکل است.
لایهٔ ۱، جمع‌آوری و حمل: روی هر سرور، یک Log Shipper مثل Filebeat یا rsyslog لاگ‌ها را جمع می‌کند و به یک سرور مرکزی می‌فرستد. اگر شبکه بزرگ باشد، یک یا چند Relay واسطه می‌شوند تا بار پخش شود و دسترسی بین شبکه‌ها محدود بماند.
لایهٔ ۲، ذخیره‌سازی و جست‌وجو: یک سیستم مدیریت لاگ مثل Elastic Stack یا Loki داده را دریافت، نرمال‌سازی، ایندکس و ذخیره می‌کند. این لایه به سؤال «چه اتفاقی افتاد؟» پاسخ می‌دهد و برای عیب‌یابی، تحلیل عملکرد و انطباق استفاده می‌شود.
لایهٔ ۳، تحلیل امنیتی و پاسخ: یک SIEM مثل Wazuh یا Splunk از همان داده تغذیه می‌کند و تهدیدها را همبسته می‌کند. اگر تیم بالغ باشد، یک SOAR پاسخ‌های ساده را خودکار می‌کند. اگر سازمان از چندین ابزار امنیتی استفاده کند، XDR می‌تواند دید یکپارچه‌ای روی Endpoint و شبکه فراهم کند.
هر لایه وظیفهٔ خودش را دارد و حذف یکی، لایهٔ بالایی را ضعیف می‌کند. اگر لایهٔ ۱ نباشد، لایهٔ ۲ داده‌ای ندارد؛ اگر لایهٔ ۲ نباشد، لایهٔ ۳ نمی‌تواند جست‌وجو کند؛ و اگر لایهٔ ۳ نباشد، داده هست اما تحلیل امنیتی وجود ندارد.
یک هشدار صادقانه: ابزار را برای مسئله انتخاب کنید، نه برعکس
در پایان این بخش، یک هشدار صادقانه لازم است. بسیاری از سازمان‌ها SIEM می‌خرند چون «بقیه هم می‌خرند»، بدون اینکه بدانند چه مسئله‌ای را می‌خواهند حل کنند. نتیجه یک ابزار گران‌قیمت است که کسی از آن استفاده نمی‌کند.
قبل از انتخاب ابزار، به این پرسش‌ها پاسخ دهید:
- آیا فقط می‌خواهید لاگ‌ها را جمع و جست‌وجو کنید؟ سیستم مدیریت لاگ کافی است و SIEM لازم نیست.
- آیا به تشخیص تهدید امنیتی نیاز دارید؟ SIEM لازم است، اما فقط اگر تیم تحلیلگر دارید که قواعد همبستگی را تنظیم کند.
- آیا حجم حوادث از توان پاسخ دستی تیم بیشتر است؟ در این صورت SOAR را در نظر بگیرید.
- آیا از چندین ابزار امنیتی مختلف استفاده می‌کنید و دید یکپارچه می‌خواهید؟ XDR ممکن است مناسب باشد، اما محدودیت‌های اکوسیستم را در نظر بگیرید.
پاسخ این پرسش‌ها ابزار را انتخاب می‌کند، نه برعکس. این ابزارها با هم رقابت نمی‌کنند بلکه روی هم می‌نشینند، پس لازم نیست همه را با هم بخرید؛ آنچه مسئلهٔ شما می‌خواهد همان است که باید انتخاب شود.
در بخش بعد، همین لایه‌ها را در سطح فنی باز می‌کنیم: از لحظه‌ای که یک لاگ تولید می‌شود تا لحظه‌ای که تحلیل نهایی به دست می‌آید.
جمع‌بندی
- «سرور لاگ» یک نام واحد برای چند ابزار متفاوت است؛ پیش از خرید بدانید که با یک انبار فایل طرفید یا با یک بستر تحلیل امنیتی.
- این خانواده پنج عضو اصلی دارد: سرور Syslog، سیستم مدیریت لاگ، SIEM، SOAR و XDR.
- این ابزارها با هم رقابت نمی‌کنند؛ لایه‌لایه روی هم می‌نشینند و حذف هر لایه، لایهٔ بالایی را ضعیف می‌کند.
- سیستم مدیریت لاگ به سؤال «چه اتفاقی افتاد؟» پاسخ می‌دهد و SIEM به سؤال «آیا این اتفاق خطرناک است؟».
- ابزار را برای مسئله انتخاب کنید، نه برعکس؛ خرید ابزار بدون مسئلهٔ مشخص فقط هزینه تولید می‌کند.
بخش قبل: بخش ۱ — فلسفهٔ مرکزیت · بخش بعد: بخش ۳ — معماری فنی · فهرست بخش‌ها