بخش ۳ — معماری فنی: خط لولهٔ لاگ از تولید تا تحلیل
دانستن نام ابزارها با دانستن اینکه داده در واقع چگونه حرکت می‌کند یکی نیست. در این بخش یک پیام لاگ را از لحظهٔ تولید تا لحظهٔ تصمیم‌گیری انسان یا ماشین دنبال می‌کنیم و از میان شش لایه‌ای عبور می‌دهیم که هرکدام دقیقاً یک کار را بر عهده دارند.
بخش قبل خانوادهٔ سرورهای لاگ مرکزی را معرفی کرد. این بخش دربارهٔ سازوکار میان آن‌هاست: هر قطعه چه می‌کند، چه چیزی را تضمین می‌کند و چه چیزی را تضمین نمی‌کند. هدف این است که مهندس بتواند معماری را طراحی کند و تازه‌کار بفهمد هر قطعه کجای تصویر می‌نشیند.
خط‌لوله به عنوان یک مفهوم واحد
خط‌لولهٔ لاگ (Log Pipeline) مسیر کامل یک پیام از لحظهٔ تولید تا لحظهٔ مقصد است. در rsyslog این مسیر با سه مفهوم توصیف می‌شود: ورودی (Input)، رولست (Ruleset) و اکشن (Action). سامانهٔ syslog-ng همان سه نقش را با نام‌های منابع (Sources)، مسیرهای لاگ (Log Paths) و مقاصد (Destinations) می‌سازد.
این شباهت تصادفی نیست. همهٔ ابزارهای بالغ لاگ از همین الگوی سه‌گانه پیروی می‌کنند، چون پاسخ طبیعی به یک پرسش است: داده از کجا می‌آید، چه پردازشی می‌شود و کجا می‌رود.
اما خط‌لولهٔ واقعی در یک شبکهٔ بزرگ سه مرحله ندارد. دست‌کم شش لایهٔ متمایز وجود دارد که هرکدام مسئولیت خودش را دارد، و در ادامه هر شش لایه را از پایین به بالا طی می‌کنیم.
تولید (Sources)
همه‌چیز از یک رویداد شروع می‌شود. برنامه‌ای خطا می‌دهد، کاربری وارد سیستم می‌شود، فایروالی بسته‌ای را مسدود می‌کند یا کرنل لینوکس ری‌استارت می‌شود. هرکدام جای دیگری رخ می‌دهد و هر تولیدکننده، لاگ را به زبان خودش می‌نویسد.
سیستم‌عامل. کرنل لینوکس پیام‌هایش را در یک بافر حلقوی (ring buffer) نگه می‌دارد که از مسیر /dev/kmsg خواندنی است و سرویس systemd هم ژورنال مخصوص خودش را دارد. هر دو منبع، لاگ‌هایی حیاتی دربارهٔ سلامت سیستم تولید می‌کنند.
برنامه‌ها. یک سرور وب مانند Nginx یا Apache، یک سرور SSH، یک پایگاه داده یا یک سرویس اختصاصی. هرکدام لاگ را به شکل خودش می‌نویسد: برخی در فایل، برخی در Syslog و برخی روی stdout.
شبکه. روترها، سوئیچ‌ها و فایروال‌ها معمولاً از پروتکل Syslog استفاده می‌کنند و لاگ را به یک سرور مرکزی می‌فرستند.
ابر و کانتینر. در محیط‌های مدرن، لاگ‌ها از سرویس‌های ابری مانند AWS CloudWatch یا Azure Monitor و از کانتینرها، از مسیر stdout و stderr، می‌آیند.
هر منبعی که لاگ تولید می‌کند باید در طراحی خط‌لوله دیده شود. مرکز امنیت سایبری کانادا توصیه می‌کند سازمان فهرست کاملی از منابع حیاتی داشته باشد و به‌طور منظم بررسی کند که آیا هرکدام واقعاً لاگ می‌فرستند یا نه.
حمل (Transport)
داده باید از منبع به مقصد برسد و تصمیم‌های این لایه تعیین می‌کنند که چقدر می‌توانید به دادهٔ رسیده اعتماد کنید.
مدل Push یا Pull. در مدل Push، منبع یا عاملی که روی آن نصب است، لاگ را به سمت مقصد می‌فرستد. در مدل Pull، مقصد به سراغ منبع می‌رود و لاگ را برمی‌دارد. انتخاب میان این دو به معماری شبکه و سیاست امنیتی بستگی دارد. پروتکل Syslog معمولاً از نوع Push است و برخی جمع‌کننده‌ها مانند Promtail برای Loki به شکل Pull کار می‌کنند.
عامل یا بدون عامل. عامل برنامهٔ کوچکی است که روی هر سرور نصب می‌شود، لاگ را می‌خواند و می‌فرستد. مزیتش کنترل و پردازش محلی است. بدون عامل یعنی دستگاه خودش لاگ را می‌فرستد، مانند فایروالی که Syslog می‌فرستد. مزیتش سادگی است، به قیمت کنترل کمتر روی قالب و زمان‌بندی.
پروتکل‌ها. پروتکلی که انتخاب می‌کنید قابلیت اعتماد به همهٔ لایه‌های بالاتر را تعیین می‌کند، چون هرکدام تضمین متفاوتی می‌خرند.
| پروتکل | تضمین تحویل | کجا به کار می‌آید |
|---|---|---|
| پروتکل UDP | هیچ تضمینی | ارسال syslog ساده که افتادن گاه‌به‌گاه پیام در آن پذیرفته شده است |
| پروتکل TCP | فقط در سطح اتصال | انتقال عمومی روی شبکهٔ قابل اعتماد |
| پروتکل TLS | سطح اتصال، همراه با رمزنگاری | هر لینکی که از شبکهٔ نامطمئن عبور می‌کند |
| پروتکل RELP | تأیید به‌ازای هر پیام | مسیرهایی که گم شدن یک پیام در آن‌ها غیرقابل قبول است |
| پروتکل HTTP | درخواست و پاسخ استاندارد | ارسال به Elasticsearch یا Splunk HEC |
| پروتکل Kafka | پایدار و قابل بازپخش | حجم بسیار بالا که بازپخش لازم دارد |
اگر از UDP استفاده می‌کنید، بدانید که در حال شانس‌بازی هستید. هیچ تضمینی برای تحویل وجود ندارد و اگر بافر دریافت پر شود، پیام بی‌صدا دور ریخته می‌شود. برای لاگ‌های امنیتی و حسابرسی، UDP انتخاب اشتباهی است.
جمع‌آوری و بافر (Aggregation and Buffering)
وقتی لاگ از منبع خارج شد باید جایی بنشیند و این لایه دو کار انجام می‌دهد: تجمیع و بافر.
تجمیع. یک سرور مرکزی، یا چند سرور، که لاگ‌ها را از منابع متعدد دریافت می‌کند. این سرور می‌تواند یک نمونهٔ سادهٔ rsyslog باشد یا یک کلاستر کامل Elasticsearch. نقش اصلی‌اش دریافت داده و نگه‌داشتن موقت آن پیش از پردازش است.
ریلی. در شبکه‌های بزرگ، یک لایهٔ واسط میان منابع و مقصد نهایی قرار می‌گیرد. ریلی از چند منبع جمع می‌کند و به مقصد می‌فرستد. ارزشش این است که دسترسی میان شبکه‌ها را محدود می‌کند، چون منابع فقط به ریلی دسترسی دارند، و بار را پخش می‌کند. این دقیقاً همان نقشی است که rsyslog برای آن ساخته شده و در چندین هاپ کار می‌کند: برنامه، جمع‌آورندهٔ گره، ریلی و SIEM.
بافر. مهم‌ترین بخش این لایه همین‌جاست و پاسخ پرسش کلیدی این لایه را می‌دهد: اگر مقصد کند باشد یا شبکه قطع شود، لاگ‌ها کجا می‌روند؟ بدون بافر، لاگ‌ها دور ریخته می‌شوند. در rsyslog از صف‌های دیسکی استفاده می‌شود، جایی که داده در حافظه بافر می‌شود و در صورت نیاز به دیسک سرریز می‌کند. با این سازوکار، مقصد کندی مانند Elasticsearch تحت فشار نمی‌تواند لاگ‌های مقصدهای دیگر را از بین ببرد.
در syslog-ng همین ایده با نام کنترل جریان بیان می‌شود: مقصدی که نمی‌تواند پیام‌ها را پردازش کند، منبع را وادار به توقف خواندن می‌کند تا بافر سرریز نکند.
بافر بدون پایش خطرناک است. اگر صف پر شود و کسی متوجه نشود، لاگ‌ها بی‌صدا دور ریخته می‌شوند. پایش نرخ پرشدگی صف بخشی جدایی‌ناپذیر از این لایه است، نه یک کار اضافه.
پردازش (Processing)
دادهٔ خام تقریباً همیشه غیرقابل استفاده است و این لایه آن را به چیزی تبدیل می‌کند که قابل جست‌وجو و تحلیل باشد. چهار عملیات این کار را انجام می‌دهند.
تجزیه یعنی استخراج فیلد از متن خام. یک خط لاگ SSH مانند نمونهٔ زیر، چهار واقعیتی را در خود دارد که هر جست‌وجویی به آن‌ها نیاز دارد:
Failed password for root from 10.0.1.5 port 52341
پس از تجزیه، همان رویداد به فیلدهای ساختاریافته تبدیل می‌شود:
action=failed_login user=root src_ip=10.0.1.5 src_port=52341
در rsyslog ماژول‌هایی مانند mmjsonparse و mmnormalize این کار را انجام می‌دهند. در Elastic Stack، ابزار Logstash یا Elasticsearch Ingest Pipeline همین نقش را بر عهده می‌گیرد.
نرمال‌سازی یعنی تبدیل قالب‌های مختلف به یک ساختار واحد. فایروال ممکن است زمان را به یک شکل بنویسد و سرور لینوکس به شکلی دیگر:
firewall: 2026-10-19 14:32:05
linux: Oct 19 14:32:05
result: 2026-10-19T14:32:05Z (ISO 8601)
بدون این مرحله، مقایسه و همبستگی میان منابع اصلاً ممکن نیست.
غنی‌سازی یعنی افزودن اطلاعاتی که در لاگ اصلی نیست ولی برای تحلیل حیاتی است. اگر لاگی یک IP دارد، غنی‌سازی می‌تواند موقعیت جغرافیایی، سازمان صاحب آن یا اطلاعات دارایی مربوط به آن را اضافه کند. مستندات Google SecOps نشان می‌دهد که چگونه موقعیت مکانی و فراداده‌های فایل به رویدادها افزوده می‌شوند تا تحلیلگر زمینهٔ بیشتری داشته باشد. در rsyslog همین کار با ماژول‌های سفارشی یا فراخوانی API انجام می‌شود.
مسیریابی یعنی تصمیم‌گیری دربارهٔ مقصد هر پیام. یک لاگ امنیتی مانند ورود ناموفق باید به SIEM برود. یک لاگ عملکردی مانند زمان پاسخ باید به سامانهٔ تحلیل عملکرد برود. یک لاگ دیباگ که حجم زیادی دارد، می‌تواند حذف شود یا به آرشیو ارزان‌قیمت برود.
در rsyslog این کار با قواعد if/then داخل رولست انجام می‌شود و یک پیام می‌تواند به‌طور موازی به چند مقصد فرستاده شود (الگوی Fan-out).
مسیریابی هوشمند هزینه را پایین می‌آورد. rsyslog دقیقاً برای این طراحی شده که داده را پیش از رسیدن به سامانه‌های گران‌قیمتی مانند SIEM کم کند. حذف نویز در لبه، هزینهٔ پهنای باند، CPU و ذخیره‌سازی را در همهٔ لایه‌های بالایی کاهش می‌دهد.
ذخیره‌سازی (Storage)
دادهٔ پردازش‌شده باید جایی ذخیره شود که قابل جست‌وجو باشد و انتخاب محل ذخیره‌سازی مستقیماً روی هزینه و سرعت اثر می‌گذارد.
ذخیره‌سازی ایندکس‌محور. سامانه‌های Elasticsearch و OpenSearch داده را در ساختار ایندکس نگه می‌دارند تا جست‌وجوی متن کامل سریع بماند. این رویکرد برای تحلیل امنیتی و جست‌وجوی ad-hoc عالی است، ولی نگهداری داده گران‌تر تمام می‌شود.
ذخیره‌سازی ستون‌محور. سامانهٔ ClickHouse برای تحلیل‌های تجمیعی مانند «تعداد ورودهای ناموفق در هر ساعت» بهینه شده است. فشرده‌سازی بهتری دارد و روی دادهٔ حجیم ارزان‌تر است، اما جست‌وجوی متن کامل در آن محدودتر می‌ماند.
ذخیره‌سازی فایل خام. گاهی لاگ‌ها فقط برای آرشیو و انطباق نگه داشته می‌شوند و نیازی به جست‌وجوی سریع ندارند. در این حالت، فایل فشرده یا آبجکت استوریج مانند S3 ارزان‌ترین گزینه است.
چرخهٔ عمر داده. ارزش دادهٔ لاگ با گذشت زمان کم می‌شود. لاگ امروز برای تشخیص زنده حیاتی است، لاگ ماه گذشته برای تحلیل پس از حادثه اهمیت دارد و لاگ سال گذشته فقط برای انطباق لازم است. یک معماری بالغ داده را بر اساس سن میان لایه‌ها جابه‌جا می‌کند و همین کار را ILM در Elasticsearch انجام می‌دهد:
Hot روی SSD سریع، جست‌وجوی کامل
Warm روی دیسک کندتر، جست‌وجوی کامل
Cold ذخیره‌سازی ارزان، جست‌وجوی محدود
Frozen اسنپ‌شات جست‌وجوپذیر روی آبجکت استوریج ارزان (S3)
الگوی رایج، نگه‌داشتن یک روز در Hot و بقیه در Frozen است که هزینه را تا ۱۶ برابر کاهش می‌دهد. همین ILM فازهای استاندارد Hot/Warm/Cold/Delete را مدیریت می‌کند و می‌تواند بر اساس زمان یا حجم ایندکس، rollover را خودکار کند.
بازهٔ نگهداری (Retention) یک تصمیم قانونی و اقتصادی است نه صرفاً فنی. استاندارد PCI-DSS حداقل یک سال نگهداری لاگ را الزام می‌کند و دست‌کم سه ماه آن باید فوری در دسترس باشد. استانداردهای HIPAA و SOC 2 هم الزامات خودشان را دارند، پس طراحی ذخیره‌سازی باید از همین‌جا شروع شود.
تحلیل و پاسخ (Analytics and Response)
آخرین لایه جایی است که داده به تصمیم تبدیل می‌شود و دو بخش دارد: تحلیل و پاسخ.
تحلیل یعنی جست‌وجو در داده، داشبوردهای تصویری مانند نمودار روند خطاها و همبستگی رویدادها که موضوع SIEM در عمق است. یک جست‌وجو می‌تواند ساده باشد: «همهٔ ورودهای ناموفق کاربر X در ۲۴ ساعت گذشته». تحلیل می‌تواند دستی و توسط تحلیلگر باشد یا خودکار و توسط قواعد.
پاسخ یعنی وقتی تحلیل به نتیجه رسید، چه اتفاقی می‌افتد. هشدار به تیم امنیت، باز شدن تیکت یا در سیستم‌های بالغ اقدام خودکار مانند قفل کردن حساب یا مسدود کردن IP. همین لایه جایی است که SOAR کار می‌کند.
تحلیل بدون پاسخ ناقص است. اگر سامانه تشخیص دهد حمله‌ای در جریان است و هیچ اقدامی انجام نشود، ارزش تشخیص صفر است. طراحی خط‌لوله باید از ابتدا مشخص کند هر نوع هشدار به چه اقدامی می‌انجامد.
دو ستون پنهان: ساعت واحد و شناسهٔ همبستگی
دو عنصر در همهٔ لایه‌های بالا حضور دارند که در ظاهر کوچک‌اند، ولی بدون آن‌ها کل خط‌لوله بی‌فایده است.
ساعت واحد با NTP. اگر ساعت سرورها همگام نباشد، ترتیب رویدادها در تحلیل به هم می‌ریزد. مرکز پاسخ به حوادث سایبری مالزی، MyCERT، صریحاً هشدار می‌دهد که اگر زمان روی رایانه‌های مختلف شبکه همگام نباشد، تطبیق اقدامات ثبت‌شده در لاگ‌های مختلف دشوار می‌شود.
حتی هنگام نفوذ هم اگر ساعت‌ها اشتباه باشند، همبستگی فعالیت ثبت‌شده با اقدامات خارجی تقریباً غیرممکن می‌شود. پروتکل NTP همهٔ دستگاه‌ها را با یک منبع زمان واحد همگام می‌کند و در معماری لاگ یک پیش‌نیاز است، نه یک گزینه.
با NTP مثل بخشی از خط‌لوله رفتار کنید، نه جزئیات سیستم‌عامل. سرور مرکزی لاگ می‌تواند خودش مرجع زمان ناوگان باشد و همسو بودن دستگاه‌های سرگردان را پایش کند، که همان استدلال مرکزیت است این بار برای زمان.
شناسهٔ همبستگی. یک درخواست کاربر ممکن است از ده سرویس مختلف عبور کند. هر سرویس لاگ خودش را می‌نویسد و بدون یک شناسهٔ مشترک، تحلیلگر نمی‌فهمد که هر ده لاگ به یک درخواست تعلق دارند. شناسهٔ همبستگی که در هدر درخواست منتقل می‌شود و در همهٔ لاگ‌ها ثبت می‌شود، این شکاف را پر می‌کند. در سیستم‌های توزیع‌شده این شناسه همان نقش شمارهٔ پیگیری در یک ادارهٔ پستی را دارد، چون بدون آن هر بسته داستان جداگانه‌ای است.
کل خط‌لوله در یک نگاه
شش لایه در نمای زیر کنار هم می‌نشینند، از منابعی که رویداد می‌سازند در پایین تا انسان‌ها و سامانه‌هایی که روی داده تصمیم می‌گیرند در بالا.
جمع‌بندی
خط‌لولهٔ لاگ مجموعه‌ای از قطعات جداگانه نیست؛ یک سیستم به‌هم‌پیوسته است و ضعف هر لایه به لایه‌های بالا منتقل می‌شود. حمل غیرقابل اعتماد داده را گم می‌کند، پردازش ناقص تحلیل را ناممکن می‌سازد، ذخیره‌سازی بدون چرخهٔ عمر هزینه را منفجر می‌کند و ساعت همگام‌نشده، همبستگی را بی‌معنا می‌کند.
| لایه | کارش چیست | بدون آن چه خراب می‌شود |
|---|---|---|
| تولید | رویدادها را می‌سازد | منابعی که فهرست نشده‌اند نامرئی می‌مانند |
| حمل | داده را با تضمینی انتخابی جابه‌جا می‌کند | افتادن پیامی که کسی متوجهش نمی‌شود |
| جمع‌آوری و بافر | داده را در قطعی‌ها جمع و نگه می‌دارد | لاگ‌هایی که با کند شدن مقصد دور ریخته می‌شوند |
| پردازش | تجزیه، نرمال‌سازی، غنی‌سازی و مسیریابی | جست‌وجوهایی که بی‌سروصدا جواب غلط می‌دهند |
| ذخیره‌سازی | داده را بر اساس سن، قابل جست‌وجو نگه می‌دارد | هزینه‌ای که بی‌حد می‌شود |
| تحلیل و پاسخ | یافته را به اقدام تبدیل می‌کند | تشخیصی که هیچ نتیجه‌ای ندارد |
معماری خوب این شش لایه را با هم می‌بیند، نه جدا. SIEM فقط لایهٔ تحلیل و پاسخ است و بدون پنج لایه زیر خودش چیزی برای تحلیل ندارد. بخش بعد دقیقاً همین لایه را باز می‌کند.
بخش قبل: بخش ۲ — خانوادهٔ سرورهای لاگ مرکزی · بخش بعد: بخش ۴ — SIEM در عمق · فهرست بخش‌ها