‏غنی‌سازی لاگ‌ها با Observability Pipelines دیتاداگ

تیم‌های امنیتی و مهندسی پلتفرم برای بررسی تهدیدها، اولویت‌بندی رویدادها، و رعایت الزامات compliance به لاگ‌های پرجزئیات نیاز دارن. مشکل اینجاست که این جزئیات اغلب در منابع جداگانه‌ای مثل فیدهای threat intelligence در Snowflake، لیست دارایی‌ها در S3، یا امتیاز ریسک در Databricks نگه داشته می‌شن. وقتی غنی‌سازی لاگ‌ها بعد از ورود به سیستم انجام بشه، تیم‌ها مجبورن برای هر ابزار downstream جداگانه همون lookup رو تکرار کنن که هم کند هم پرهزینه‌ست.

Observability Pipelines دیتاداگ این مشکل رو با یه پردازنده‌ی به اسم Enrichment Table حل می‌کنه. این پردازنده اجازه می‌ده لاگ‌ها قبل از اینکه به SIEM، دیتالیک، یا هر ابزار دیگه‌ای برسن، با داده‌های Reference Tables غنی بشن. Reference Tables به‌صورت خودکار با منابع SaaS و ابر همگام می‌شن و نیازی به به‌روزرسانی دستی CSV نیست.

منابعی که می‌شه باهاشون کار کرد متنوعن: Snowflake برای فیدهای threat intelligence و پروفایل کاربری، ServiceNow CMDB برای متادیتای دارایی‌ها، Salesforce برای اطلاعات مشتری، Databricks برای خروجی مدل‌های ML مثل امتیاز تقلب، و Cloud Storage (S3، Azure Blob، GCS) برای داده‌های مرجع مثل allowlist و IP reputation.

یه مورد کاربردی مهم اینه که می‌شه لاگ‌های تاریخی رو از آرشیو بیرون کشید (rehydration) و با context به‌روز غنی‌شون کرد. مثلاً یه مهندس امنیتی می‌تونه لاگ‌های احراز هویت قدیمی رو از Azure Blob Storage بخونه، با لیست دارایی به‌روز از Snowflake ترکیب کنه، و نتیجه رو برای تحلیل به Microsoft Sentinel بفرسته — حتی اگه threat intelligence بعد از وقوع رویداد تغییر کرده باشه.

غنی‌سازی لاگ‌ها یه مزیت مهم دیگه هم داره: مسیریابی هوشمند. بعد از اینکه یه رویداد با طبقه‌بندی تهدید یا tier مشتری غنی شد، می‌شه بر اساس اون تصمیم گرفت. مثلاً ترافیک بی‌خطر رو به S3 (ارزان‌تر) بفرستیم و رویدادهای مشکوک یا مخرب رو مستقیم به SIEM مثل CrowdStrike یا Datadog Cloud SIEM هدایت کنیم. این کار نویز ابزارهای گران downstream رو کم می‌کنه.

از نظر فنی، Enrichment Table processor از یه local cache استفاده می‌کنه. اگه مقدار کلید (مثلاً ip_address) در cache پیدا شه، لاگ فوری غنی و ارسال می‌شه. اگه نه، لاگ در حافظه buffer می‌مونه و کلید به صف درخواست‌های API اضافه می‌شه. هر ثانیه یا وقتی صف به حد مشخصی رسید، همه‌ی کلیدها یکجا از Datadog Reference Tables API گرفته می‌شن، cache به‌روز می‌شه، و لاگ‌های buffered غنی‌سازی و ارسال می‌شن.

نکات کلیدی:

• غنی‌سازی لاگ قبل از ارسال به downstream tools انجام می‌شه و نیازی به lookup مجدد در هر ابزار نیست
• Reference Tables به‌صورت خودکار با Snowflake، ServiceNow، Salesforce، Databricks و Cloud Storage همگام می‌شن
• امکان rehydration لاگ‌های آرشیوشده و غنی‌سازی با context جدید وجود داره
• مسیریابی شرطی بر اساس attribute های غنی‌شده، هزینه‌ی ابزارهای گران رو کاهش می‌ده
• پردازنده از local cache و صف‌بندی API برای بهینه‌سازی latency استفاده می‌کنه