بخش ۶ — سناریوهای کامل و حل مسئله: وقتی همهٔ لایه‌ها به هم می‌رسند

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

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

نفوذ تدریجی (از فیشینگ تا خروج داده)

وضعیت اولیه

شرکتی با ۳۰۰ سرور، ۲۰ فایروال، ۵۰۰۰ کاربر و یک تیم امنیتی چهارنفره. سازمان یک سامانهٔ SIEM دارد، یک سیستم مدیریت لاگ یعنی Elastic Stack و روی هر سرور یک Filebeat نصب است. فایروال‌ها لاگ را از طریق Syslog به یک Relay می‌فرستند که آن را به سیستم مرکزی می‌رساند. ساعت همهٔ سیستم‌ها با NTP همگام است.

رویدادها در هر لایه

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

ساعت ۱۰:۱۵ شب، لایهٔ تولید (فیشینگ): یکی از کارمندان بخش فروش ایمیلی دریافت می‌کند که ظاهراً از طرف سرویس منابع انسانی است و از او می‌خواهد رمزش را برای «به‌روزرسانی» وارد کند. کارمند روی لینک کلیک می‌کند و رمز را وارد می‌کند. مهاجم حالا اعتبارنامه را دارد و هیچ سیستمی این رویداد را ثبت نمی‌کند، چون فیشینگ در یک سایت خارجی رخ داده است.

ساعت ۱۰:۲۰ شب، لایهٔ تولید (ورود): مهاجم از یک IP خارجی که قبلاً هرگز در سازمان دیده نشده، با اعتبارنامهٔ کارمند وارد سیستم می‌شود. سرور احراز هویت یعنی Active Directory این ورود موفق را ثبت می‌کند: event_id=4624, user=ali, src_ip=185.x.x.x, logon_type=3.

ساعت ۱۰:۳۵ شب، لایهٔ تولید (حرکت جانبی): مهاجم از حساب ali برای اتصال به یک سرور فایل استفاده می‌کند. سرور فایل این اتصال را ثبت می‌کند: user=ali, src_ip=185.x.x.x, target=fileserver-03, share=finance$.

ساعت ۱۰:۵۰ شب، لایهٔ تولید (خروج داده): مهاجم از سرور فایل، ۲۰۰۰ فایل مالی را در یک آرشیو فشرده می‌کند و آن را به یک سرویس اشتراک فایل ابری آپلود می‌کند. فایروال این ترافیک خروجی را ثبت می‌کند: src=fileserver-03, dst=185.x.x.x, bytes=450MB, proto=HTTPS.

10:20  Active Directory  event_id=4624, user=ali, src_ip=185.x.x.x, logon_type=3
10:35  fileserver-03     user=ali, src_ip=185.x.x.x, target=fileserver-03, share=finance$
10:50  firewall          src=fileserver-03, dst=185.x.x.x, bytes=450MB, proto=HTTPS

آنچه هر ابزار می‌بیند

سیستم مدیریت لاگ. سامانهٔ Elastic Stack هر سه رویداد را می‌بیند، ولی جداگانه. اگر تحلیلگر جست‌وجو کند «user=ali»، سه نتیجه می‌گیرد: ورود از یک IP جدید، دسترسی به پوشهٔ مالی و آپلود ۴۵۰ مگابایت. هیچ‌کدام به‌تنهایی «حمله» به نظر نمی‌رسد. ورود از IP جدید می‌تواند سفر کاری باشد و دسترسی به پوشهٔ مالی می‌تواند بخشی از وظایف شغلی.

سامانهٔ SIEM. اینجا تفاوت ظاهر می‌شود. سامانهٔ SIEM یک قاعدهٔ همبستگی دارد: اگر کاربری از IP جدید وارد شود، سپس به پوشه‌ای دسترسی پیدا کند که معمولاً به آن دسترسی ندارد و سپس حجم غیرعادی داده آپلود کند، هشدار بده. این سامانه سه رویداد را در یک بازهٔ ۳۰ دقیقه‌ای به هم وصل می‌کند و یک هشدار با اولویت بالا تولید می‌کند: «احتمال خروج داده توسط کاربر ali».

نقطهٔ شکست

هشدار در ساعت ۱۰:۵۵ شب تولید می‌شود و تیم امنیتی چهارنفره در آن ساعت در دسترس نیست. هشدار تا صبح در صف می‌ماند. صبح روز بعد، تحلیلگر هشدار را می‌بیند و درمی‌یابد داده‌ها ساعت‌ها پیش خارج شده‌اند.

خطر

میان هشدار تا پاسخ، پنج ساعت فاصله است و همین پنج ساعت دقیقاً برای خارج کردن ۲۰۰۰ فایل مالی کافی بود. تشخیصی که کسی در آن ساعت بیدار نباشد تا آن را دریافت کند، یک کنترل امنیتی نیست.

راه‌حل معماری

این سناریو سه درس معماری دارد.

اول، هشدار باید به کانال مناسب برود. هشدارهای با اولویت بالا نباید فقط در داشبورد SIEM بمانند. باید به یک سیستم پیام‌رسانی مثل PagerDuty یا یک کانال تلگرام یا اسلک بروند که تیم را ساعت ۳ بامداد بیدار کند. طراحی «مسیر تشدید» بخشی از معماری SIEM است، نه یک فکر بعدی.

نکته

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

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

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

قطعی شبکه و بقای داده

وضعیت اولیه

شرکتی با دو دیتاسنتر، یکی در تهران و یکی در اصفهان. سرورهای تهران لاگ‌های خود را از طریق یک لینک MPLS با پهنای باند محدود به یک سرور مرکزی در اصفهان می‌فرستند. سرور مرکزی یک صف Disk-Assisted دارد که در صورت قطعی، دادهٔ ورودی را روی دیسک بافر می‌کند.

رویدادها در هر لایه

ساعت ۲:۰۰ بامداد، قطعی لینک: لینک MPLS بین تهران و اصفهان قطع می‌شود. علت، بریده شدن یک کابل فیبر در مسیر است. تخمین تعمیر، ۶ ساعت.

ساعت ۲:۰۰ تا ۸:۰۰، لایهٔ تولید، ادامهٔ کار: سرورهای تهران به کار خود ادامه می‌دهند. یک سرور وب در تهران خطاهای مکرر می‌دهد، کاربری در ساعت ۳ بامداد تلاش‌های ناموفق ورود دارد و یک فایروال ترافیک مشکوکی را مسدود می‌کند. همهٔ این‌ها لاگ می‌شوند، ولی هیچ‌کدام نمی‌توانند به اصفهان برسند.

ساعت ۲:۰۰ تا ۸:۰۰، لایهٔ جمع‌آوری، بافر: روی هر سرور تهران یک Agent از نوع Filebeat یا rsyslog لاگ‌ها را جمع می‌کند و وقتی لینک قطع می‌شود نمی‌تواند به مقصد برسد. یک صف محلی روی همان Agent داده را روی دیسک نگه می‌دارد. سرور مرکزی اصفهان هم صف Disk-Assisted خودش را برای داده‌های ارسال‌شده از منابع دیگر، مثلاً فایروال‌های اصفهان، دارد.

ساعت ۸:۰۰ صبح، بازگشت لینک: لینک MPLS تعمیر می‌شود و Agentهای تهران شروع به تخلیهٔ صف محلی خود می‌کنند. داده‌های ۶ ساعت گذشته به ترتیب به سرور مرکزی اصفهان می‌رسند و سرور مرکزی هم صف Disk-Assisted خودش را تخلیه می‌کند. هیچ لاگی از دست نمی‌رود.

آنچه بدون بافر اتفاق می‌افتاد

اگر Agentهای تهران بافر نداشتند، در لحظهٔ قطعی لینک هر لاگ جدید یا در حافظه می‌ماند و بعد از مدتی دور ریخته می‌شد، یا بلافاصله دور ریخته می‌شد. نتیجه اینکه ۶ ساعت داده از دست می‌رفت.

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

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

هشدار

صف Disk-Assisted وقتی پر می‌شود، داده را بی‌صدا دور می‌ریزد. هیچ اثری از این اتفاق روی داشبورد دیده نمی‌شود، پس تیمی که عمق صف را پایش نکند می‌تواند باور کند پوشش کامل دارد، در حالی که شواهد بی‌سروصدا از بین می‌روند.

راه‌حل معماری

این سناریو سه درس معماری دارد.

اول، بافر باید در چند لایه باشد. بافر فقط روی سرور مرکزی کافی نیست، چون قطعی ممکن است در هر نقطه‌ای از مسیر رخ دهد. Agent هم باید بافر خودش را داشته باشد. معماری بالغ از بافر در لبه، یعنی همان Agent، و در مرکز، یعنی Relay یا Aggregator، استفاده می‌کند.

دوم، صف باید پایش شود. صف Disk-Assisted وقتی پر شود، بی‌صدا داده را دور می‌ریزد. پایش «عمق صف» و «نرخ دور ریختن» بخشی جدایی‌ناپذیر از معماری است، نه یک افزونهٔ اختیاری.

سوم، ظرفیت صف باید طراحی شود. صف Disk-Assisted ظرفیت محدودی دارد، برای نمونه ۲ گیگابایت، و قطعی‌ای که از این ظرفیت طولانی‌تر شود، داده از دست می‌برد. طراحی از «حداکثر قطعی قابل تحمل» شروع می‌شود: اگر می‌خواهید ۲۴ ساعت قطعی را تحمل کنید، ظرفیت صف باید برای ۲۴ ساعت داده کافی باشد. این یک تصمیم اقتصادی است، چون ظرفیت بیشتر یعنی دیسک بیشتر.

تحلیل پس از حادثه و انطباق

وضعیت اولیه

شرکتی خدمات مالی درمی‌یابد داده‌های مشتریانش در یک بازار سیاه فروخته می‌شود. حمله احتمالاً هفته‌ها پیش رخ داده و کسی متوجه نشده است. تیم امنیت باید بفهمد چه اتفاقی افتاده، چه داده‌ای تحت تأثیر قرار گرفته و نهاد نظارتی چه اقدامی لازم دارد.

رویدادها در هر لایه (بازسازی گذشته)

لایهٔ تولید: لاگ‌های سرورهای وب، پایگاه داده، Active Directory، فایروال و Email Gateway. همهٔ این‌ها در ۹۰ روز گذشته در سیستم مرکزی ذخیره شده‌اند.

لایهٔ ذخیره‌سازی: داده‌های ۳۰ روز اخیر در فاز Hot روی SSD هستند و جست‌وجوی سریعی دارند. داده‌های ۳۰ تا ۹۰ روز اخیر در فاز Warm روی دیسک کندتر هستند. داده‌های قدیمی‌تر از ۹۰ روز در Frozen روی آبجکت استوریج آرشیو شده‌اند.

لایهٔ تحلیل: تیم امنیت یک بازهٔ جست‌وجو تعریف می‌کند که همهٔ فعالیت‌های مشکوک ۹۰ روز گذشته را پوشش می‌دهد و سامانهٔ SIEM یک خط زمانی می‌سازد:

• روز ۱: یک ایمیل فیشینگ به کاربر reza ارسال می‌شود. سامانهٔ Email Gateway این را ثبت کرده، ولی سامانهٔ SIEM آن را با اولویت پایین علامت زده است، چون هر روز هزاران فیشینگ مسدود می‌شود.
• روز ۲: کاربر reza از یک IP جدید در کشور همسایه وارد می‌شود. سامانهٔ Active Directory این را ثبت کرده و سامانهٔ SIEM آن را با برچسب «ورود از IP جدید» علامت زده، ولی با اولویت پایین، چون سفر کاری رایج است.
• روز ۳ تا ۱۰: کاربر reza به‌تدریج به پوشه‌های بیشتری دسترسی پیدا می‌کند و فایل‌های کم‌حجم دانلود می‌کند. سامانهٔ SIEM این الگو را با عنوان «دسترسی غیرعادی» علامت زده، ولی چون در بازهٔ روزهای کاری بوده، اولویت متوسط دارد.
• روز ۱۵: یک آپلود بزرگ ۲ گیگابایتی به یک سرویس ابری خارجی انجام می‌شود. فایروال این را ثبت کرده و سامانهٔ SIEM آن را با برچسب «خروج داده» علامت زده و یک هشدار با اولویت بالا تولید کرده است. کسی به این هشدار رسیدگی نکرد.

آنچه تحلیل پس از حادثه نشان می‌دهد

تیم امنیت با استفاده از لاگ‌های همبسته‌شده می‌تواند حمله را دقیقاً بازسازی کند:

مرحله	روز	لاگی که شاهد را نگه داشته است
نقطهٔ ورود	۱	لاگ Email Gateway ایمیل فیشینگ را دارد
اعتبارنامهٔ سرقت‌شده	۲	لاگ Active Directory ورود را دارد
حرکت جانبی	۳ تا ۱۰	لاگ سرور فایل دسترسی را دارد
خروج داده	۱۵	لاگ فایروال ترافیک خروجی را دارد

همهٔ این‌ها از لاگ‌های ۹۰ روز گذشته قابل بازسازی است. شرکت می‌تواند دقیقاً بگوید چه داده‌هایی تحت تأثیر قرار گرفته‌اند، یعنی ۲۰۰۰ فایل مالی، کدام مشتریان درگیرند و نهاد نظارتی چه اقدامی لازم دارد.

نقطهٔ شکست

نقطهٔ شکست در این سناریو، پاسخ ندادن به هشدار است. سامانهٔ SIEM هشدار را در روز ۱۵ تولید کرد، ولی کسی به آن رسیدگی نکرد. اگر رویهٔ پاسخ تعریف شده بود، مثلاً «هر هشدار با اولویت بالا باید در عرض یک ساعت بررسی شود»، حمله در روز ۱۵ متوقف می‌شد، نه هفته‌ها بعد.

نقطهٔ شکست دوم، کاهش نویز است. اگر Email Gateway روزانه هزاران ایمیل فیشینگ را مسدود کند و همهٔ آن‌ها در SIEM به‌عنوان هشدار ثبت شوند، هشدار واقعی در نویز گم می‌شود. طراحی درست SIEM باید رویدادهای شبیه به هم را از هم جدا کند: «فیشینگ مسدودشده» با «فیشینگ کلیک‌شده» متفاوت است.

امنیت

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

راه‌حل معماری

این سناریو سه درس معماری دارد.

اول، نگهداری داده باید بر اساس الزام انطباق طراحی شود. اگر شرکت لاگ‌ها را فقط ۳۰ روز نگه می‌داشت، نمی‌توانست حمله‌ای را که هفته‌ها پیش شروع شده بازسازی کند. استاندارد PCI-DSS حداقل ۱۲ ماه نگهداری را الزام می‌کند و این الزام دقیقاً برای همین سناریوها است.

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

سوم، رویهٔ پاسخ باید تعریف شود. سامانهٔ SIEM بدون رویهٔ پاسخ فقط یک ناظر است. تیم امنیت باید بداند هر هشدار با اولویت بالا، چه در ساعت کاری و چه خارج از آن، به چه کسی می‌رسد و چه اقدامی انجام می‌شود. این رویه بخشی از معماری است، نه یک فکر بعدی.

جمع‌بندی

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

• نفوذ تدریجی نشان می‌دهد یک سیستم مدیریت لاگ می‌تواند همهٔ رویدادهای مرتبط را نگه دارد و باز هم حمله را از دست بدهد، چون همبستگی و مسیر تشدید جا افتاده بودند. فاصلهٔ پنج‌ساعته میان هشدار و پاسخ، بهای ۲۰۰۰ فایل مالی شد.
• قطعی شبکه نشان می‌دهد بافر در لبه تعیین می‌کند شش ساعت لاگ بماند یا برود، و صف پایش‌نشده حتی وقتی چیزی آشکارا خراب نمی‌شود هم داده را بی‌سروصدا دور می‌ریزد.
• تحلیل پس از حادثه نشان می‌دهد نگهداری داده، چرخهٔ عمر قابل جست‌وجو و رویهٔ پاسخ مشخص هستند که یک حملهٔ کشف‌شده را به حمله‌ای قابل اثبات تبدیل می‌کنند و حداقل ۱۲ ماههٔ PCI-DSS دقیقاً برای همین مورد است.

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

بخش قبل: بخش ۵ — چالش‌های عملیاتی و حریم خصوصی · بخش بعد: بخش ۷ — جمع‌بندی و اصول طراحی · فهرست بخش‌ها