یک پتابایت لاگ توی یک آخر هفته
خلاصهٔ کاملتر
به گفتهٔ نویسنده، Scanner برای فشارآزمایی در مقیاس بالا و ساختن یه محیط واقعیِ شکار تهدید، یه سطل S3 رو با ۱.۴ پتابایت لاگ CloudTrail پر کرده و فقط Scanner رو بهش وصل کرده. کل کار حدود ۸۰ ساعت طول کشیده، اوجِ توانِ پردازش حدود ۲۳.۹ تِبیبایت در ساعت بوده و روز سوم بالای ۲۰ تِبیبایت در ساعت رو نگه داشته.
نکتهٔ اصلی معماریِ متفاوتشه. موتورهای مبتنیبر Lucene برای هر ترم در هر سند یه ورودی نگه میدارن و ایندکسشون معمولاً ۲ تا ۳ برابر دادهٔ اصلی میشه و باید روی ذخیرهسازی سریع بمونه. Scanner بهجاش توکنها رو به صفحههایی حدود ۱۰۰ هزار رویداد نگاشت میکنه؛ همین دانهبندیِ درشتتر دفترداری موقع ایندکس رو کم و ایندکس رو خیلی کوچک میکنه. نتیجه: فقط ۱۳۹ تِبیبایت ایندکسِ فشرده از ۱.۴ پتابایت ورودی خام.
طراحی از دل ویژگیهای تأخیر S3 درمیاد. چون خوندن اولین بایت از S3 صرفنظر از حجم ۱۰۰ تا ۵۰۰ میلیثانیه طول میکشه و این هزینه ثابته، Scanner در تکههای بزرگتر میخونه؛ یه صفحهٔ کامل رو میگیره و با پردازشِ شتابگرفته با SIMD اسکنش میکنه. نتیجه تأخیر پرسوجو در حد چند ثانیهست، که روی یه پتابایت داده عالیه.
هماهنگی روی سه انبار پشتیبان میچرخه: SQS کار رو صف میکنه، DynamoDB پیشرفت ایندکس و اجارههای فایل رو ردیابی میکنه تا دو ورکر یه فایل رو دوباره ننویسن، و MySQL نقش انبار متادیتا رو داره و به موتور پرسوجو میگه کدوم فایلهای ایندکس آمادهٔ جستوجو هستن. مسیر نوشتن و خوندن هم کاملاً از هم جدان.
برای اثبات فایده، نویسنده یه سوزن رو لای انبار کاه قایم کرده: یه کمپین APT جاسازیشده لای ۶۸۹ میلیارد رویداد قانونی. با کمک Claude Code که پرسوجوها رو از طریق سرور MCP اجرا میکرد، تیم تونست فعالیتِ یه IP مشکوک رو دنبال کنه. یه پرسوجوی نمونه این شکلی بود:
@index=demo-data sourceIPAddress:"185.234.72.111" | stats count() by requestParameters.bucketName
هر پرسوجو روی یه سال داده بین ۱۰ ثانیه تا ۲ دقیقه جواب میداد. تیم الگوی کلاسیک APT رو دید: چند ماه شناساییِ آروم و کمسروصدا، یه موج اولیهٔ خروج داده، و بعد در دسامبر خروج انبوهِ حدود ۵۰ هزار فایل از یه سطل بایگانی. مکانیزم ماندگاری هم یه کاربر IAM پشتی بود که اسمش شبیه یه حساب سرویس طراحی شده بود تا از چشم تحلیلگر رد بشه.
نویسنده میگه کل بازجویی از هشدار اولیه تا کل زنجیرهٔ حمله کمتر از ۱۰ دقیقه طول کشید. حرف اصلی اینه که جستوجوی مستقیم روی S3 کارهایی رو ممکن میکنه که قبلاً نبودن، مثل شکار تهدید سریع روی سالها لاگ، اونهم با کسری از هزینهٔ SIEMهای سنتی.
نکات کلیدی:
- ایندکس ۱.۴ پتابایت لاگ CloudTrail در حدود ۸۰ ساعت و بدون دخالت دستی
- ایندکسِ صفحهمحور بهجای ریزدانه، حجم رو به ۱۰٪ دادهٔ خام میرسونه
- طراحی حول تأخیر S3 بنا شده؛ خوندن تکههای بزرگ و اسکن با SIMD
- هماهنگی با SQS، DynamoDB و MySQL؛ مسیر خوندن و نوشتن جدا
- یه کمپین APT جاسازیشده در کمتر از ۱۰ دقیقه با کمک Claude Code و MCP پیدا شد
