در نگاه اول، شاید به نظر برسد که وظیفه اصلی بخش ذخیره‌سازی در یک SIEM، تنها نگهداری حجم عظیمی از لاگ‌هاست. اما واقعیت این است که این بخش، مسئولیت‌های استراتژیک و بسیار مهم‌تری بر عهده دارد که مستقیماً بر کارایی تحلیل‌های امنیتی بلادرنگ تأثیر می‌گذارد. هدف از جمع‌آوری لاگ‌ها، استفاده از آن‌هاست و اگر سیستم ذخیره‌سازی نتواند به سرعت اطلاعات مورد نیاز را در اختیار ما قرار دهد، تمام این لاگ‌ها عملاً بی‌فایده خواهند بود.

به طور خلاصه، یک معماری ذخیره‌سازی قدرتمند باید چهار مسئولیت کلیدی را به خوبی مدیریت کند:

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

وقتی از «کلان‌داده» در حوزه امنیت صحبت می‌کنیم، منظورمان حجم سرسام‌آوری از لاگ‌هاست. سازمان‌های کوچک ممکن است روزانه با میلیون‌ها یا میلیاردها لاگ سروکار داشته باشند، اما شرکت‌های بزرگ به راحتی تریلیون‌ها لاگ را ذخیره می‌کنند و حجم داده‌هایشان به مقیاس پتابایتی (PB) می‌رسد.

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

این موضوع ما را به یک سؤال حیاتی می‌رساند: اگر سخت‌افزار لازم برای ذخیره پتابایت‌ها داده را داریم، راز معماری برای جستجوی سریع در این حجم از اطلاعات چیست؟ پاسخ در انتخاب یک فلسفه ذخیره‌سازی نهفته است که اساساً با پایگاه‌های داده‌ای که اکثر ما با آن‌ها بزرگ شده‌ایم، متفاوت است.

پایگاه‌های داده سنتی و رابطه‌ای مانند Microsoft SQL یا MySQL برای وظایفی طراحی شده‌اند که شامل ایجاد، خواندن، به‌روزرسانی و حذف مداوم داده‌هاست. برای تضمین یکپارچگی داده‌ها در این عملیات پیچیده، این سیستم‌ها از مجموعه‌ای از قوانین به نام ACID compliant پیروی می‌کنند. فکر کنید ACID مثل یک کارمند دقیق بانک است که باید هر تراکنش را قبل از نهایی شدن، چندین بار بررسی، شمارش و بازشماری کند. این رویکرد برای داده‌های مالی عالی است، اما برای لاگ‌های امنیتی – که در واقع گزارش‌های نهایی از یک رخداد هستند – مثل این است که همان کارمند بانک را مجبور کنیم یک رسید چاپ‌شده را دوباره تأیید اعتبار کند. این یک تأخیر غیرضروری است که عملکرد را از بین می‌برد.

اینجاست که مفهوم WORM یا “Write-Once-Read-Many” (یک بار بنویس، چند بار بخوان) به عنوان یک راه‌حل بهینه مطرح می‌شود. نبوغ WORM برای ذخیره‌سازی لاگ در این است که قابلیتی را که به آن نیازی نداریم – یعنی امکان به‌روزرسانی مداوم یک رکورد – کنار می‌گذارد تا ویژگی‌هایی را که به شدت به آن‌ها نیاز داریم، تقویت کند: یعنی نوشتن فوق‌العاده سریع و ایندکس‌گذاری تقریباً بلادرنگ برای جستجو.

سیستم‌های مبتنی بر WORM:

یکی از بهترین نمونه‌های عملی که این مدل را با موفقیت پیاده‌سازی کرده، پلتفرم Splunk است.

Splunk یکی از پلتفرم‌های پیشرو در دنیای SIEM است که از مدل ذخیره‌سازی WORM برای ساخت یک معماری قدرتمند و مقیاس‌پذیر برای جستجوی بلادرنگ در مقیاس بزرگ استفاده می‌کند. راز موفقیت آن در معماری ذخیره‌سازی توزیع‌شده‌اش نهفته است.

در این معماری، داده‌ها در سرورهای مختلفی به نام ایندکسر (Indexer) ذخیره می‌شوند. برای جلوگیری از دست رفتن داده‌ها، Splunk از مفهومی به نام “ضریب تکثیر” (Replication Factor) استفاده می‌کند. این یعنی به ازای هر قطعه از داده، چندین کپی در ایندکسرهای مختلف نگهداری می‌شود تا اگر یکی از سرورها از کار افتاد، اطلاعات همچنان در دسترس باقی بماند.

اما این طراحی هوشمندانه دو مزیت کلیدی به همراه دارد:

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

یکی از کارهای دقیق و شاید کمی خسته‌کننده در پیاده‌سازی SIEM، “نگاشت انواع فیلد” (Field Type Mapping) است. اما اهمیت این کار آنقدر زیاد است که می‌تواند تفاوت بین یک سیستم کارآمد و یک سیستم ناکارآمد را رقم بزند.

بیایید یک مثال ساده را بررسی کنیم: تفاوت بین "404" و 404. اولی یک رشته (String) متنی است، در حالی که دومی یک عدد (Integer) است. شاید این تفاوت کوچک به نظر برسد، اما تأثیر آن بر قابلیت‌های جستجو، گزارش‌گیری و هشداردهی عظیم است. اگر نوع فیلد به درستی تعریف شود، قابلیت‌های قدرتمندی در اختیار شما قرار می‌گیرد:

یک نکته بسیار مهم: این سخت‌گیری در تعریف فیلدها، یک شمشیر دولبه است. از یک طرف، مانند یک دروازه‌بان کنترل کیفیت عمل می‌کند و منابع داده شما را مجبور می‌کند که داده‌ها را تمیز و سازگار ارسال کنند. از طرف دیگر، یک پیکربندی اشتباه می‌تواند باعث حذف شدن بی‌صدای لاگ‌ها (dropped logs) و از دست رفتن داده‌های امنیتی حیاتی شود. به همین دلیل است که تنظیم صحیح انواع فیلد در ابتدای کار، فقط یک «بهترین رویه» نیست؛ بلکه یک وظیفه حیاتی و ضروری است.

در نهایت، اگرچه تنظیم فیلدها کاری دقیق و زمان‌بر است، اما برای بهره‌برداری کامل از قدرت یک SIEM، امری ضروری است. و این قدرت، مستقیماً به سرعت سیستم وابسته است.

در دنیای تحلیل تاکتیکی امنیت، یک اصل کلیدی وجود دارد: سرعت پادشاه است. در حالت ایده‌آل، جستجوهای شما باید در کمتر از ۵ ثانیه پاسخ دهند. اگر تیم شما برای یک پرس‌وجوی ساده به طور مداوم بیش از ۳۰ ثانیه منتظر می‌ماند، شما یک مشکل عملکردی ندارید، بلکه یک مشکل بنیادین در معماری سیستم خود دارید.

در این زمینه، می‌توان از “نظریه پنجره‌های شکسته” (Broken Windows Theory) الهام گرفت. این نظریه می‌گوید که مشکلات کوچک و نادیده گرفته‌شده، به تدریج به مشکلات بزرگ و غیرقابل کنترل تبدیل می‌شوند. این اصل دقیقاً در مورد عملکرد SIEM نیز صادق است. وقتی یک جستجو دقایق طول می‌کشد، رشته افکار یک تحلیلگر از هم می‌پاشد. کنجکاوی جای خود را به ناامیدی می‌دهد. تحلیلگر شروع به پرسیدن سؤالات کمتری می‌کند. و یک تحلیلگر امنیتی که از پرسیدن سؤال «چه می‌شد اگر؟» دست بکشد، دیگر یک شکارچی تهدید نیست؛ بلکه یک تولیدکننده گزارش است. کندی SIEM شما مستقیماً کیفیت تحلیلگران انسانی شما را کاهش می‌دهد.

یک راه‌حل عملی برای مقابله با این مشکل این است که اگر عملکرد سیستم به یک چالش تبدیل شده، لاگ‌های مربوط به انطباق (Compliance) را از لاگ‌های تاکتیکی (Tactical) جدا کنید. این جداسازی می‌تواند در سطح سرورهای ذخیره‌سازی یا حتی پارتیشن‌های مختلف دیسک انجام شود. به این ترتیب، جستجوهای حیاتی و فوری روی دیسک‌های سریع‌تر انجام می‌شوند و لاگ‌های کم‌اهمیت‌تر، عملکرد کلی سیستم را تحت تأثیر قرار نمی‌دهند.

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

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