امروز می‌خوایم درباره یکی از مهم‌ترین و شاید نادیده گرفته‌شده‌ترین اجزای یک معماری SIEM قدرتمند صحبت کنیم.

در دنیای امروز که هر ثانیه هزاران لاگ از صدها سیستم مختلف تولید می‌شه، مدیریت و پردازش این حجم از داده یک چالش واقعیه. همه ما می‌دونیم که از دست دادن حتی یک لاگ امنیتی می‌تونه به قیمت یک رخنه امنیتی فاجعه‌بار تموم بشه. حالا تصور کنید سیستمی که برای جمع‌آوری لاگ طراحی کردید، درست در اوج یک حمله سایبری به خاطر حجم بالای ترافیک از کار بیفته. این دقیقا کابوس هر کارشناس امنیته.

اینجاست که یک قهرمان بی‌سروصدا وارد صحنه می‌شه: “Message Broker” یا “کارگزار پیام”. درک نقش این کامپوننت، کلید ساخت یک معماری SIEM پایدار، قابل اعتماد و مقاوم در برابر شکست هست. امروز با هم یاد می‌گیریم که این ابزار چطور می‌تونه از فاجعه از دست رفتن لاگ‌ها جلوگیری کنه.

اما قبل از اینکه به راه حل بپردازیم، بیایید ببینیم دقیقا با چه مشکلی روبرو هستیم؟

اولین نقطه شکست در معماری‌های ساده، معمولاً همون جاییه که انتظارش رو نداریم: جمع‌کننده‌های لاگ یا Aggregators. این سیستم‌ها وظیفه خطیری در دریافت، پردازش اولیه و ارسال لاگ‌ها دارند، اما به راحتی می‌تونن به پاشنه آشیل کل معماری ما تبدیل بشن.

یک جمع‌کننده مثل Splunk Heavy Forwarder، وقتی فقط وظیفه دریافت و ارسال خام لاگ‌ها رو به عهده داره، می‌تونه حجم عظیمی از داده رو مدیریت کنه. اما به محض اینکه ما شروع به اضافه کردن قوانین پردازشی سنگین مثل Parsing (تجزیه) و Enrichment (غنی‌سازی) می‌کنیم، عملکردش به شدت افت می‌کنه. برای مثال، یک Forwarder که در حالت عادی می‌تونه ۲۰ هزار رویداد در ثانیه (EPS) رو پردازش کنه، بعد از اضافه شدن این تنظیمات پیچیده، ممکنه توانش به ۵ هزار EPS یا حتی کمتر کاهش پیدا کنه. این یعنی ۷۵ درصد افت عملکرد! این افت شدید، یک گلوگاه خطرناک ایجاد می‌کنه و وقتی حجم لاگ‌ها از این آستانه فراتر بره، سیستم یا از کار می‌افته یا شروع به دور ریختن لاگ‌ها می‌کنه.

اما مشکل فقط به جمع‌کننده‌ها ختم نمی‌شود؛ لایه ذخیره‌سازی ما هم چالش‌های خاص خودش را دارد.

سیستم ذخیره‌سازی ما، مثل Splunk Indexers، یک کارگر چندوظیفه‌ایه. این سیستم باید همزمان لاگ‌های جدید رو بپذیره، اون‌ها رو ایندکس کنه تا قابل جستجو بشن و در عین حال به کوئری‌ها و جستجوهای سنگین تحلیل‌گران امنیت پاسخ بده. این مثل شعبده‌بازی با چند تا توپ به صورت همزمانه؛ اگر یکی از کارها بیش از حد سنگین بشه، تمرکز سیستم به هم می‌ریزه و ممکنه توپ‌ها (یعنی لاگ‌ها) روی زمین بیفتن.

وقتی یک تحلیل‌گر یک کوئری پیچیده و سنگین اجرا می‌کنه، منابع سیستم ذخیره‌سازی درگیر پاسخ به اون می‌شه. در این شرایط، فرآیند پذیرش لاگ‌های جدید کند یا حتی متوقف می‌شه. این کندی به سرعت به لایه قبلی، یعنی Splunk Heavy Forwarder، فشار میاره. Forwarder که جایی برای ارسال لاگ‌ها نداره، دچار فشار بیش از حد می‌شه و در نهایت، فاجعه اتفاق می‌افته: لاگ‌های حیاتی از دست می‌رن.

خب، با این دو چالش بزرگ، معماری سنتی ما شکننده به نظر می‌رسد. بیایید ببینیم یک طراحی هوشمندانه‌تر چگونه است.

اینجاست که Message Broker به عنوان یک “امدادگر” یا یک “بافر هوشمند” وارد معماری ما می‌شه. کارگزار پیام یک لایه میانی بین منابع تولیدکننده لاگ و سیستم‌های پردازشگر ماست. این سیستم به صورت استراتژیک قرار می‌گیره تا شوک‌ها و فشارهای ناگهانی رو جذب کنه و به کل سیستم اجازه بده با آرامش و به صورت پایدار کار کنه.

وظایف اصلی یک کارگزار پیام رو می‌شه در سه مورد کلیدی خلاصه کرد:

اما آیا این یعنی باید همیشه و برای همه چیز از بروکر استفاده کنیم؟ پاسخ همیشه مثبت نیست.

یک معمار خوب فقط نمی‌دونه از چه ابزاری استفاده کنه، بلکه می‌دونه چه زمانی نباید از یک ابزار استفاده کنه. اضافه کردن یک بروکر به معماری، پیچیدگی و بار مدیریتی رو افزایش می‌ده، پس باید هوشمندانه ازش استفاده کرد.

بسیاری از اپلیکیشن‌های مدرن و Agentهای جدید، قابلیت‌های بافر داخلی دارند. یعنی می‌تونن لاگ‌ها رو به صورت موقت در حافظه (memory) یا روی دیسک ذخیره کنن. اما همه این Agentها یکسان نیستند. برخی فقط آنلاین بودن مقصد را بررسی می‌کنند که کافی نیست. Agentهای واقعاً هوشمند، اطمینان حاصل می‌کنند که سیستم مقصد توانایی پذیرش حجم لاگ ارسالی را دارد و دچار کندی نشده است. فقط در این حالت است که می‌توانیم با اطمینان از بروکر صرف نظر کنیم، چون Agent خودش نقش یک شبکه ایمنی کوچک رو بازی می‌کنه.

در چنین شرایطی، ارسال لاگ از این Agentهای هوشمند به یک بروکر، در واقع اتلاف منابع و اضافه کردن یک لایه غیرضروریه. کارگزارهای پیام عمدتاً برای سیستم‌هایی طراحی شده‌اند که نمی‌توانند از دریافت موفق لاگ توسط مقصد اطمینان حاصل کنند. بهترین مثال برای این سیستم‌ها، دستگاه‌های شبکه‌ای هستند که از پروتکل Syslog استفاده می‌کنن. Syslog لاگ رو ارسال می‌کنه و براش مهم نیست که آیا مقصدی برای دریافت اون وجود داره یا نه. اینجور سیستم‌ها به شدت به یک بروکر برای جلوگیری از گم شدن لاگ نیاز دارند.

بسیار خب، حالا که می‌دانیم چه زمانی به بروکر نیاز داریم، بیایید گزینه‌های محبوب در دنیای اوپن‌سورس را بررسی کنیم.

انتخاب ابزار مناسب به اندازه خود معماری اهمیت داره. دو تا از محبوب‌ترین کارگزارهای پیام در دنیای اوپن‌سورس RabbitMQ و Kafka هستن. برای درک تفاوتشون، می‌شه از استعاره “خودروی اسپرت در مقابل خودروی خانوادگی” استفاده کرد. هر دو شما رو به مقصد می‌رسونن، اما با ویژگی‌ها و هزینه‌های کاملاً متفاوت.

بیایید این دو رو با هم مقایسه کنیم:

انتخاب ابزار یک بخش ماجراست، بخش دیگر نحوه یکپارچه‌سازی آن با ابزارهای جمع‌آوری لاگ مانند Splunk Forwarder است.

اضافه کردن یک بروکر، معماری جمع‌آوری لاگ ما رو از یک مدل ساده و شکننده، به یک مدل دو مرحله‌ای هوشمند و مقاوم تبدیل می‌کنه. بیایید ببینیم این معماری در عمل چطور کار می‌کنه:

مزایای کلیدی این معماری فوق‌العاده است:

در نهایت، همه این بحث‌ها به یک سوال اساسی می‌رسد: آیا شما باید از بروکر استفاده کنید یا می‌توانید ریسک کنید؟

در پایان این اپیزود، از خودتون سه سوال کلیدی بپرسید:

اگر پاسخ شما به هر یک از این سوالات “بله” است، پس قمار نکنید. همین امروز برای پیاده‌سازی یک Message Broker در معماری خود برنامه‌ریزی کنید. این کار پایداری، انعطاف‌پذیری و قابلیت اطمینان کل زیرساخت امنیتی شما را تضمین خواهد کرد.

خیلی ممنون که در این اپیزود هم با ما همراه بودید. امیدوارم این بحث براتون مفید بوده باشه. در اپیزود بعدی درباره تکنیک‌های پیشرفته غنی‌سازی لاگ صحبت خواهیم کرد. تا اون موقع، امن و پایدار بمونید. خدانگهدار.