مدیریت حجم عظیم داده‌های تولید شده توسط زیرساخت‌های ابری، یکی از چالش‌های اصلی تیم‌های عملیات امنیت (SOC) و مهندسان امنیت است. سرویس Logpush در Cloudflare لاگ‌ها را در دسته‌های سریع ارسال می‌کند تا اطلاعات تقریباً در لحظه (Real-time) در دسترس باشند. با معرفی قابلیت Transformers، اکنون کاربران می‌توانند پیش از خروج لاگ‌ها از محیط کلودفلر، آن‌ها را فیلتر، بازسازی و پالایش (Redact) کنند.
چرا به Transformers نیاز است؟
تیم‌های Observability معمولاً لاگ‌های Cloudflare را به سیستم‌های مدیریت رویداد و اطلاعات امنیتی (SIEM)، پلتفرم‌های تحلیل داده یا Object Storage ارسال می‌کنند. اما پیش از رسیدن داده‌ها به مقصد، نیاز است که:
- ترافیک‌های مربوط به Health Check حذف شوند.
- فیلدهای حساس برای رعایت حریم خصوصی پالایش (Redact) شوند.
- ساختار رکوردها برای داشبوردها و بررسی‌های امنیتی تغییر یابد (Reshape).
پیش از این، این فرآیند نیازمند یک سرویس پردازشی مجزا بود که مدیریت، مقیاس‌بندی و نظارت بر آن هزینه عملیاتی زیادی داشت. همچنین، پرداخت هزینه برای انتقال و ذخیره‌سازی داده‌هایی که در نهایت حذف می‌شدند، یک اتلاف منابع بود.
معماری فنی و نحوه عملکرد
در Transformers، کاربران یک کوئری SQL تعریف می‌کنند تا رکوردها را فیلتر کرده و خروجی را تغییر دهند. این پردازش مستقیماً در خط لوله (Pipeline) ارسال Logpush ادغام شده است. برای دستیابی به کارایی بالا در مقیاس میلیاردها رویداد در ثانیه، کلودفلر از تکنولوژی‌های زیر استفاده کرده است:
- Apache DataFusion: یک موتور کوئری Rust-based که بر پایه Apache Arrow ساخته شده و دارای یک Planner SQL و موتور اجرای ستونی (Columnar) است.
- Apache Arrow: یک فرمت حافظه ستونی مستقل از زبان که اجازه می‌دهد داده‌ها با سرعت بسیار بالا بین زبان‌های Go (که Bufstream با آن نوشته شده) و Rust (که DataFusion با آن نوشته شده) جابجا شوند.
- FFI و C-ABI: برای انتقال بهینه داده‌ها بین محیط‌های اجرای Go و Rust بدون ایجاد سربار زیاد در حافظه.
پایداری و امنیت داده‌ها
یکی از نکات کلیدی در طراحی Transformers، رویکرد Fail Closed است. اگر به هر دلیلی اجرای یک Transformer با خطا مواجه شود، سیستم برای جلوگیری از ارسال داده‌های خام (که ممکن است حاوی اطلاعات حساس پالایش‌نشده باشند یا ساختار اشتباه داشته باشند)، از ارسال آن دسته از لاگ‌ها خودداری کرده و تلاش مجدد (Retry) می‌کند. در صورت تداوم خطا، Job مربوطه به‌طور خودکار غیرفعال می‌شود تا منابع سیستم برای سایر کاربران حفظ شود.
در نهایت، خروجی‌های پردازش شده در قالب NDJSON فشرده شده و به مقصد نهایی ارسال می‌شوند. این معماری باعث می‌شود تیم‌های امنیتی بدون نیاز به زیرساخت‌های واسط، کنترل کاملی بر داده‌های ارسالی به SIEM خود داشته باشند.
