بخش ۰ — مقدمه
شبکهٔ امروزی، شبکهٔ دیروز نیست. یک دهه پیش، سازمانی با ده سرور و یک فایروال، شبکه‌ای «بزرگ» محسوب می‌شد.
همان سازمان امروز ده‌ها ماشین مجازی، چند کلاستر کوبرنتیز، سرویس‌های ابری، دستگاه‌های اینترنت اشیا و صدها کاربر راه دور دارد. هر کدام از این اجزا، لاگ تولید می‌کند. هر لاگ، یک تکه از پازلی است که هیچ‌کس به‌تنهایی نمی‌تواند تصویر کاملش را ببیند.
نوشتهٔ پیشین، فلسفهٔ لاگ، توضیح داد چرا ثبت رویدادها به وجود آمد و چه نیازی را برطرف کرد. اما پرسشی بنیادی‌تر را بی‌پاسخ گذاشت، و این سند دقیقاً به همان پرسش پاسخ می‌دهد.
چرا این سند نوشته شد
دو نوشتهٔ قبلی، دو تکهٔ جدا از هم بودند: یکی دربارهٔ فلسفهٔ لاگ و دیگری دربارهٔ خانوادهٔ سرورهای لاگ مرکزی. اما این دو تکه، در عمل یک زنجیرهٔ به‌هم‌پیوسته‌اند.
نمی‌توان دربارهٔ SIEM حرف زد، بدون اینکه بفهمیم چرا لاگ پراکنده شکست می‌خورد. نمی‌توان معماری لاگ مرکزی را طراحی کرد، بدون اینکه بدانیم هر لایه چه وظیفه‌ای دارد. و نمی‌توان ابزار انتخاب کرد، بدون اینکه بدانیم هر ابزار کجای این زنجیره می‌نشیند.
وقتی شبکه از یک سرور به هزار سرور می‌رسد، لاگ‌ها را کجا ببریم؟ اگر هر دستگاه لاگ خودش را نگه دارد، در لحظهٔ حادثه چه کسی تصویر کامل را می‌بیند؟
این سند، آن زنجیره را کامل می‌کند. از «چرا مرکزیت ضروری است» شروع می‌شود، به «چه ابزارهایی وجود دارند» می‌رسد و سپس «چگونه در سطح فنی کار می‌کنند» را توضیح می‌دهد. بعد، «SIEM به‌عنوان مغز تحلیلی» را در عمق می‌کاود، چالش‌های عملیاتی و حریم خصوصی را صادقانه می‌گوید، سه سناریوی کامل را حل می‌کند و در نهایت به یک چک‌لیست طراحی قابل اجرا می‌رسد.
این سند برای چه کسی نوشته شده
این سند دو مخاطب دارد و تلاش کرده برای هر دو قابل فهم باشد، بدون اینکه به سطح یکی تنزل کند.
مخاطب اول، مهندس و متخصص: کسی که با rsyslog، Elastic Stack، Wazuh یا Splunk کار کرده، یا در حال طراحی یک معماری لاگ برای سازمانش است. برای این مخاطب، سند جزئیات فنی کافی دارد: پروتکل‌ها، انواع صف، چرخهٔ عمر داده، قواعد همبستگی و تصمیم‌های معمارانه. اما هیچ‌جا فرض نمی‌کند که خواننده از قبل همه‌چیز را می‌داند؛ هر مفهوم کلیدی، بار اول که می‌آید، توضیح کوتاهی هم دارد.
مخاطب دوم، تازه‌کار یا فردی که آشنایی ندارد: کسی که تازه وارد حوزهٔ زیرساخت یا امنیت شده، یا مدیری که می‌خواهد بفهمد تیمش دربارهٔ چه چیزی حرف می‌زند. برای این مخاطب، هر بخش با یک تشبیه یا مثال روزمره شروع می‌شود و اصطلاحات فنی در پرانتز یا با یک جملهٔ کوتاه توضیح داده می‌شوند. هدف این نیست که سند «ساده‌سازی» شود، بلکه این است که «قابل ورود» باشد: خوانندهٔ تازه‌کار می‌تواند از ابتدا شروع کند و کم‌کم بالا برود، بدون اینکه در میانهٔ راه گم شود.
چگونه این سند را بخوانیم
سند به‌صورت خطی طراحی شده و ترتیب بخش‌ها تصادفی نیست. هر بخش بر بخش قبلی سوار می‌شود.
اگر عجله دارید یا فقط به بخش خاصی نیاز دارید، این نقشهٔ راه کوتاه می‌تواند کمک کند:
- اگر می‌خواهید فقط بفهمید «چرا»: بخش ۱ (فلسفهٔ مرکزیت) را بخوانید و بعد بخش ۷ (جمع‌بندی) را. این دو، تصویر کامل «چرا» را می‌دهند، بدون جزئیات فنی.
- اگر می‌خواهید ابزار انتخاب کنید: بخش ۲ (خانوادهٔ سرورهای لاگ) و بخش ۴ (SIEM در عمق) را بخوانید. جدول مقایسه در بخش ۲ به شما می‌گوید کدام ابزار برای کدام هدف است.
- اگر مهندس هستید و می‌خواهید طراحی کنید: بخش ۳ (معماری فنی) و بخش ۷ (اصول طراحی) ستون فقرات کار شماست. بخش ۵ (چالش‌ها) را هم از دست ندهید، چون همان جا است که بسیاری از طراحی‌ها شکست می‌خورند.
- اگر می‌خواهید در عمل ببینید چطور کار می‌کند: بخش ۶ (سناریوها) را بخوانید. سه سناریوی کامل، همهٔ بخش‌های قبلی را در موقعیت‌های واقعی به هم وصل می‌کنند.
پیش‌نمایش بخش‌ها
بخش ۱ — فلسفهٔ مرکزیت: چرا لاگ پراکنده شکست می‌خورد. این بخش نشان می‌دهد که مرکزیت یک انتخاب سلیقه‌ای نیست، بلکه پاسخ به پنج مشکل بنیادین است: مقیاس، زمان، قالب، عمر داده و ظرفیت انسانی. با یک سناریوی کوتاه از شبکهٔ ۲۰۰ سروری بدون مرکزیت شروع می‌شود و نشان می‌دهد چرا حتی یک اسکریپت ساده هم این مشکلات را حل نمی‌کند.
بخش ۲ — خانوادهٔ سرورهای لاگ مرکزی: نقشهٔ کامل ابزارها. این بخش همهٔ اعضای خانواده را با نام معرفی می‌کند: سرور Syslog، سیستم مدیریت لاگ (LMS)، SIEM، SOAR، XDR و اجزای مکملی مثل Log Shipper و Relay. برای هر کدام، نقش، محدودیت و مخاطب اصلی گفته می‌شود. در پایان هم یک جدول مقایسهٔ جامع و یک معماری مرجع سه‌لایه ارائه می‌شود.
بخش ۳ — معماری فنی: خط لولهٔ لاگ از تولید تا تحلیل. این بخش در سطح فنی توضیح می‌دهد که خط لوله چگونه کار می‌کند.
مسیر از لایهٔ تولید (سیستم‌عامل، برنامه، شبکه، ابر) آغاز می‌شود، از لایهٔ حمل (Push در برابر Pull، Agent در برابر Agentless، پروتکل‌ها) می‌گذرد و به لایهٔ جمع‌آوری (Relay، Aggregator، بافر دیسکی) می‌رسد. سپس لایهٔ پردازش (Parse، Normalize، Enrich، Route) و لایهٔ ذخیره‌سازی (ایندکس‌محور در برابر ستون‌محور، چرخهٔ عمر داده) به کار می‌آیند و در نهایت لایهٔ تحلیل و پاسخ قرار می‌گیرند. دو ستون پنهان ولی ضروری هم معرفی می‌شوند: ساعت واحد (NTP) و شناسهٔ همبستگی (Correlation ID).
بخش ۴ — SIEM در عمق: مغز تحلیلی. این بخش به تفصیل توضیح می‌دهد که SIEM چه می‌کند که بقیه نمی‌کنند: همبستگی رویدادها، رویکرد قاعده‌محور در برابر آماری و یادگیری ماشین، و مفهوم Use Case. مثال‌های واقعی از قواعد همبستگی (Brute Force، Impossible Travel، Lateral Movement، Data Exfiltration)، مدیریت هشدار و خستگی هشدار و نقش Threat Intelligence هم بررسی می‌شوند. محدودیت‌ها هم صادقانه بیان می‌شوند.
بخش ۵ — چالش‌های عملیاتی و حریم خصوصی. این بخش آنچه را می‌گوید که در تبلیغات ابزارها گفته نمی‌شود: حجم داده و هزینه، کیفیت داده، امنیت خود سیستم لاگ (اگر SIEM هک شود چه می‌شود؟)، حریم خصوصی و ماسک کردن داده و انطباق با استانداردهایی مثل PCI-DSS و HIPAA. اهمیت NTP و نگهداری قواعد هم در همین بخش مطرح می‌شود. جملهٔ کلیدی آن این است: «SIEM بدتر از نداشتن SIEM است اگر تیم آماده نباشد.»
بخش ۶ — سناریوهای کامل و حل مسئله. سه سناریوی کامل ارائه می‌شود، هر کدام با وضعیت اولیه، رویدادهای پراکنده در هر لایه، آنچه هر ابزار می‌بیند، نقطهٔ شکست و راه‌حل معماری.
سناریوی اول نفوذ تدریجی است، از Insider تا Lateral Movement و Exfiltration. سناریوی دوم قطعی شبکه و بقای داده است. سناریوی سوم تحلیل پس از حادثه و انطباق است.
بخش ۷ — جمع‌بندی و اصول طراحی. این بخش همهٔ مطالب را به یک چک‌لیست قابل اجرا تبدیل می‌کند: ده اصل طراحی یک معماری لاگ مرکزی، تصمیم‌های کلیدی که یک معمار باید بگیرد و اشتباهات رایج. سپس نقشهٔ راه پیاده‌سازی تدریجی برای سازمانی که از صفر شروع می‌کند ارائه می‌شود.
یک قرارداد کوچک با خواننده
در سراسر این سند، سه قرارداد رعایت شده است که خوب است بدانید:
اول، هیچ اصطلاح فنی‌ای بدون توضیح رها نمی‌شود. بار اول که یک اصطلاح می‌آید، در پرانتز یا با یک جملهٔ کوتاه توضیح داده می‌شود. اگر بعداً دوباره بیاید، فرض می‌شود که خواننده یاد گرفته است.
دوم، هیچ ادعای فنی‌ای بدون مثال رها نمی‌شود. هر مفهوم انتزاعی، با یک مثال عینی همراه است. مثلاً وقتی از «همبستگی رویدادها» حرف می‌زنیم، بلافاصله یک مثال واقعی می‌آید که نشان دهد این همبستگی در عمل چه شکلی است.
سوم، محدودیت‌ها پنهان نمی‌شوند. این سند تبلیغات فروشندهٔ ابزار نیست. هر جا ابزاری محدودیت دارد، گفته می‌شود و هر جا رویکردی شکست می‌خورد، گفته می‌شود.
هدف این است که خواننده بعد از خواندن سند بتواند تصمیم بگیرد، نه اینکه فقط تحت تأثیر قرار بگیرد.
جمع‌بندی
- این سند از مقدمه‌ای که در آن هستید شروع می‌شود و با یک چک‌لیست طراحی قابل اجرا در بخش ۷ تمام می‌شود.
- دو مخاطب دارد: مهندسانی که با rsyslog، Elastic Stack، Wazuh یا Splunk کار کرده‌اند، و تازه‌کارهایی که به‌تازگی وارد زیرساخت یا امنیت شده‌اند.
- هر بخش هم جزئیات فنی کافی برای یک مهندس دارد و هم یک توضیح کوتاه به زبان ساده برای خوانندهٔ تازه‌کار.
- اگر وقت کمی دارید، نقشهٔ راه بالا شما را مستقیم به بخش‌هایی می‌رساند که پاسخ پرسش‌تان هستند.
- سه قرارداد با خواننده دارد: هیچ اصطلاحی بدون توضیح، هیچ ادعایی بدون مثال و هیچ محدودیتی بدون بیان صریح.
بخش بعد: بخش ۱ — فلسفهٔ مرکزیت · فهرست بخش‌ها