تکین آنالیز | کالبدشکافی نشت ۱۰ ترابایتی TiDB Cloud و گروه FulcrumSec

زلزله در قلب دیتابیس‌های توزیع‌شده؛ کالبدشکافی نفوذ به PingCAP و سرقت ۱۰ ترابایت اطلاعات

در پاییز سال ۲۰۲۶، انتشار گزارشی تکان‌دهنده در نشریه دارک ریدینگ (Dark Reading) و بیانیه‌های رسمی کمپانی پینگ‌کپ (PingCAP)، بنیان‌های اعتماد به پایگاه‌های داده ابری را دچار زمین‌لرزه‌ای شدید کرد. پینگ‌کپ، خالق پایگاه داده توزیع‌شده و متن‌باز TiDB و سرویس تمام‌ابری TiDB Cloud، رسماً تأیید کرد که مهاجمان سایبری موفق شده‌اند به سیستم‌های داخلی این شرکت نفوذ کرده و حجم عظیمی از داده‌های حیاتی را به سرقت ببرند. گروه باج‌افزاری و اخاذی نوظهور معروف به Fulcrum Security (FulcrumSec) با بر عهده گرفتن مسئولیت این حمله، مدعی سرقت بیش از ۱۰ ترابایت داده حساس، میلیون‌ها فایل سازمانی و متادیتای عملیاتی هزاران کلاستر ابری شد.

پایگاه داده TiDB به عنوان یکی از پیشرفته‌ترین سیستم‌های پردازش تراکنشی و تحلیلی هم‌زمان (HTAP) در جهان شناخته می‌شود که غول‌های فناوری، بانک‌های بین‌المللی، پلتفرم‌های تجارت الکترونیک و استودیوهای بزرگ بازی‌سازی برای مدیریت میلیاردها رکورد بلادرنگ به آن متکی هستند. خبر نفوذ به زیرساخت این شرکت، جامعه مهندسی نرم‌افزار و مدیران امنیت ارشد (CISO) در سراسر دنیا را در بهتی عمیق فرو برد؛ چرا که بسیاری تصور می‌کردند با تفویض مدیریت پایگاه داده به سرویس‌های ابری، خطر نفوذ به صفر تقلیل می‌یابد.

بر اساس گزارش‌های کالبدشکافی فارنزیک، مهاجمان برای یک بازه زمانی طولانی و فرساینده، دقیقاً از ۹ سپتامبر تا ۷ اکتبر ۲۰۲۶، بدون فعال شدن زنگ‌های هشدار متداول، در شبکه‌های داخلی پینگ‌کپ حضور فعال داشته‌اند. این پنجره نفوذ ۲۸ روزه نشان‌دهنده تبحر فوق‌العاده بالای تیم نفوذگر در مخفی‌سازی ردپای دیجیتال، استفاده از کانال‌های ارتباطی مبهم و سوءاستفاده هوشمندانه از توکن‌های دسترسی مشروع است که تمامی لایه‌های سنتی EDR و پایش امنیتی را خلع سلاح کرده بود.

نکته بسیار حیاتی که در تحلیل‌های اولیه گم شده بود، تمایز میان لایه ذخیره‌سازی داده‌های اصلی مشتریان (Data Plane) و لایه کنترل و مدیریت ابری (Control Plane) است. پینگ‌کپ در بیانیه‌های خود تأکید کرد که شواهد مستقیمی از دسترسی نفوذگران به کلاسترهای عملیاتی TiDB یا رکوردهای بانکی مشتریان به دست نیامده است. اما همان‌طور که این پرونده به تلخی نشان داد، در معماری‌های ابری مدرن، متادیتای کنترلی دست‌کمی از اصل داده‌ها ندارد و می‌تواند شاه‌کلید نفوذ به خصوصی‌ترین بخش‌های زیرساخت شرکت‌های مشتری باشد.

شروع زنجیره حمله نه از یک زیرو-دی پیچیده در هسته توزیع‌شده TiKV، بلکه از یک آسیب‌پذیری در مدیریت کلیدها و دسترسی‌ها رقم خورد. نفوذگران گروه FulcrumSec با در اختیار گرفتن مدارک هویتی یک اکانت سرویس داخلی (Service Account Credentials) موفق شدند گیت‌های ورودی اولیه محیط‌های ابری پینگ‌کپ را دور بزنند. در سیستم‌های توزیع‌شده مدرن، اکانت‌های سرویس شریان حیاتی اتوماسیون میان کوبرنتیز، پایپ‌لاین‌های CI/CD و واسط‌های API ابری هستند که معمولاً امتیازات دسترسی بالایی دارند.

مهاجمان پس از ورود اولیه، بی‌درنگ عملیات شناسایی افقی (Lateral Movement) را آغاز کردند. آنها به جای ایجاد سر و صدا یا تلاش برای دستکاری خوشه‌های ذخیره‌سازی که بلافاصله سیستم‌های مانیتورینگ کارایی دیتابیس را حساس می‌کرد، توجه خود را به سمت انبارهای متادیتا، سرورهای ثبت وقایع و بسترهای ارتباطی مشتریان با درگاه ابری معطوف کردند. این استراتژی صامت، نفوذگران را قادر ساخت تا بیش از ۴ هفته بدون شناسایی به استخراج داده‌ها (Data Exfiltration) مشغول باشند. آنان به صورت حساب‌شده، از ترافیک رمزگذاری‌شده TLS برای انتقال بسته‌های اطلاعاتی به سرورهای فرماندهی و کنترل (C2) استفاده کردند تا جریان دیتای خروجی در میان ترافیک عظیم بک‌آپ‌های روزانه کلاسترها استتار شود.

بررسی‌های موشکافانه نشان می‌دهد که اکانت سرویس قربانی، دارای دسترسی گسترده به باکت‌های ذخیره‌سازی پشتیبان ابری در AWS S3 و Google Cloud Storage بوده است. این باکت‌ها نه تنها شامل ایمیج‌های توسعه داخلی و سورس‌کدهای اختصاصی پینگ‌کپ بودند، بلکه حجم گسترده‌ای از فایل‌های تحلیل کارایی، دپوی لاگ‌های تشخیصی و کَش کوئری‌های رابط گرافیکی وب‌سایت ابری را در خود جای داده بودند که عملاً نقشه کامل معماری داده مشتریان را فاش می‌کرد. در بخش‌های بعدی، به تفکیک لایه‌های معماری، علل ریشه‌ای نشت در محیط‌های چندمستأجری و راهکارهای مهار این فاجعه خواهیم پرداخت.

تفکیک معماری Data Plane و Control Plane؛ مرز باریک میان امنیت داده و متادیتای عملیاتی

برای درک عمق این بحران سایبری، باید لایه‌های مهندسی یک پایگاه داده ابری توزیع‌شده (Distributed DBaaS) را کالبدشکافی کرد. در معماری استاندارد TiDB، لایه داده (Data Plane) از موتورهای قدرتمند ذخیره‌سازی کلید-مقدار TiKV بر بستر پروتکل اجماع رفت (Raft Consensus) و موتور تحلیل ستونی TiFlash تشکیل شده است. این گره‌های ذخیره‌سازی معمولاً در شبکه‌های ایزوله، پشت دیوارهای آتش خصوصی و با رمزنگاری در حالت سکون (Encryption at Rest با کلیدهای پیشرفته AES-256) میزبانی می‌شوند و دسترسی مستقیم به آن‌ها حتی برای پرسنل پشتیبانی و مهندسان ارشد پینگ‌کپ نیز به شدت محدود و منوط به احراز هویت‌های چندمرحله‌ای است.

در نقطه مقابل، لایه کنترل (Control Plane) مغز متفکر ارکستراسیون کلاد است؛ جایی که اپراتورهای کوبرنتیز (TiDB Operator)، سیستم‌های توزیع بار، پایپ‌لاین‌های مقیاس‌پذیری خودکار (Auto-scaling)، سرویس‌های مانیتورینگ کارایی و پنل وب کاربران مدیریت می‌شوند. نفوذ گروه FulcrumSec دقیقاً در همین لایه کنترلی متمرکز بود. مهاجمان متوجه شدند که نیازی به شکستن کلاسترهای مستحکم دیتابیس ندارند؛ چرا که کنترل پلین در حال بلعیدن و ذخیره متادیتاهایی بود که برای حمله به سازمان‌ها کفایت می‌کرد. این لایه مدیریتی به صورت مستمر بسته‌های تله‌متری عملکردی شامل مصرف پردازنده، گلوگاه‌های دیسک و الگوهای ترافیک کوئری‌ها را جمع‌آوری می‌کرد که همگی در باکت‌های اشتراکی تجمیع می‌شدند.

هنگامی که مشتریان از کنسول وب TiDB Cloud استفاده می‌کنند، کوبرنتیز در پس‌زمینه برای مدیریت منابع با باکت‌های ذخیره‌سازی مرکزی و سرویس‌های تله‌متری داخلی پینگ‌کپ ارتباط برقرار می‌کند. خطای مرگبار پینگ‌کپ این بود که این شریان‌های ارتباطی را در یک شبکه گسترده متصل به هم رها کرده بود؛ به طوری که یک کلید اکانت سرویس سازمانی با دسترسی‌های بیش‌ازحد به مهاجمان اجازه داد تا میان زیرسیستم‌های مختلف جابجا شوند و دپوی متادیتای تمام مستأجران را هدف قرار دهند. این امر موجب شد تا مرزهای جداسازی منطقی میان کلاسترهای شرکت‌های گوناگون عملاً بی‌اثر شود و داده‌های تشخیصی صدها سازمان بزرگ در اختیار مهاجمان قرار گیرد.

این ماجرا مرزهای فرضی امنیت در سیستم‌های چندمستأجری (Multi-Tenant) را در هم شکست. در حالی که بخش آی‌تی شرکت‌ها آسوده‌خاطر بودند که کانتینرهای دیتابیس آن‌ها از سایر مشتریان مجزاست، پینگ‌کپ داده‌های جانبی و تشخیصی هزاران شرکت را در یک مخزن مشترک کنترل پلین تجمیع کرده بود؛ مخزنی که فاقد مرزبندی‌های رمزنگاری سخت‌گیرانه لایه داده بود و دسترسی به آن نیازی به عبور از پروتکل‌های احراز هویت متقابل نداشت.

فاجعه ذخیره‌سازی نامحسوس لاگ‌های کوئری و متادیتای SQL؛ افشای اسرار مشتریان سازمانی

تکان‌دهنده‌ترین بخش گزارش دارک ریدینگ، افشای سازوکار ذخیره‌سازی کوئری‌های SQL در محیط ابری بود. بسیاری از توسعه‌دهندگان و تحلیل‌گران داده از ابزار داخلی Web SQL Editor در داشبورد TiDB Cloud برای دیباگ، تست کارایی و اجرای کوئری‌های آزمایشی استفاده می‌کردند. آنچه کاربران نمی‌دانستند این بود که این درگاه وب، تمام کوئری‌های ارسالی، خروجی خطاهای نحوی، ردپای تریس‌ها و حتی پیش‌نمایش برخی جداول را برای اهداف بهینه‌سازی و تاریخچه کاربری در باکت‌های ابری کنترل پلین آرشیو می‌کرد.

در کدهای SQL اجرا شده در این محیط، حجم سرسام‌آوری از اطلاعات محرمانه نهفته بود؛ از کلمات عبور پیش‌فرض تست‌ها، کلیدهای دسترسی به رابط‌های API که توسعه‌دهندگان در دستورات INSERT قرار داده بودند، نام کاربری مدیران، هش توکن‌های سشن، ساختار کامل اسکیماها و روابط جداول پایگاه داده گرفته تا اطلاعات هویتی و مالی شهروندان. دستیابی به این تاریخچه‌ها به هکرها امکان داد تا ساختار داخلی سامانه‌های مشتریان را به دقت بشناسند.

کد نمونه زیر نشان‌دهنده الگوی سیاستی نامناسبی است که در سیستم‌های ابری پینگ‌کپ به کار رفته بود؛ سیاستی که به یک نقش هویتی سرویس کوبرنتیز اجازه می‌داد تا بدون نیاز به احراز هویت چندعاملی یا محدودیت آدرس آی‌پی سازمانی، تمام محتویات باکت‌های کش و تله‌متری را استخراج کند. مهاجمان با بهره‌برداری از همین پیکربندی ضعیف توانستند پایش‌های امنیتی را دور بزنند.

پیامد چنین نشتی فراتر از یک سرقت دیتای ساده است. هنگامی که یک مهاجم ساختار کامل اسکیما و متن کوئری‌های پرکاربرد یک شرکت را به دست می‌آورد، ساخت بارهای آلوده برای حملات تزریق SQL هدفمند، مهندسی معکوس الگوهای تجاری و نفوذ به رابط‌های API اختصاصی شرکت قربانی به امری پیش‌پاافتاده تبدیل می‌شود.

فروپاشی مدل مسئولیت مشترک (Shared Responsibility) در عصر پایگاه‌های داده مدیریت‌شده

سال‌هاست که ارائه‌دهندگان غول‌پیکر ابری مفهوم «مدل مسئولیت مشترک» را به عنوان سنگ بنای امنیت کلاد به مشتریان عرضه می‌کنند؛ اصلی که می‌گوید امنیت فیزیکی، شبکه زیرساخت و مجازی‌سازی بر عهده ارائه‌دهنده است، در حالی که رمزنگاری داده‌ها، کنترل دسترسی کاربران و امنیت اپلیکیشن بر دوش مشتری است. اما حادثه پینگ‌کپ نشان داد که در دوران پایگاه‌های داده کاملاً مدیریت‌شده (Fully Managed DBaaS)، این مدل کلاسیک کارایی خود را از دست داده و تبدیل به یک سراب گمراه‌کننده شده است.

در یک سرویس دیتابیس ابری مدرن، مشتری کنترلی بر لاگ‌گیری سیستم‌عامل میزبان، ذخیره‌سازی داده‌های دیباگ در وب‌پورتال، مانیتورینگ کارایی و سیاست‌های دسترسی ابزارهای داخلی ارائه‌دهنده ندارد. وقتی یک کاربر شرکتی یک کوئری را در داشبورد TiDB Cloud اجرا می‌کند، با این فرضیه پیش می‌رود که این دستور تنها برای محاسبه نتیجه پردازش شده و سپس از حافظه فرار محو می‌شود. ذخیره‌سازی بی‌صدای این فرامین در انبارهای داده جانبی پینگ‌کپ، نقض آشکار شفافیت معماری و نقض توافق‌نامه‌های سطح خدمات محرمانگی است؛ چرا که مشتریان هزینه پردازش ابری را پرداخت می‌کنند تا امنیت آن‌ها تضمین شود، نه اینکه کدهای تجاری و کوئری‌های داخلی‌شان در قالب لاگ‌های سیستماتیک آرشیو گردد.

این فاجعه زیرساختی از منظر حقوقی و رگولاتوری عواقب سنگینی به همراه دارد. قوانینی چون GDPR در اروپا، قانون CCPA در کالیفرنیا، و به ویژه مقررات نوین حفاظت از داده‌های شخصی در امارات متحده عربی و عربستان سعودی، جریمه‌های سنگینی را برای نشت اطلاعات بدون رمزنگاری وضع کرده‌اند. به عنوان مثال، بانک مرکزی عربستان (SAMA) و اداره خدمات مالی دبی (DFSA) مقررات سرسختانه‌ای در مورد اقامت محلی داده‌ها (Data Residency) و نظارت بر زنجیره تأمین ارائه‌دهندگان ابری دارند. سازمان‌هایی که تصور می‌کردند با ذخیره داده‌های خود در کلاسترهای رمزگذاری‌شده TiDB از الزامات رگولاتوری پیروی کرده‌اند، اکنون متوجه شده‌اند که متادیتای عملیاتی آن‌ها بدون اطلاع در فضای وب دست‌به‌دست می‌شود و ممکن است آنها را با جریمه‌های سنگین مالیاتی و لغو مجوزهای فعالیت تجاری روبرو کند.

بسیاری از تحلیل‌گران امنیت ابری معتقدند که صنعت کلاد باید تعریف داده‌های حساس را بازنگری کند. داده‌های تله‌متری، متادیتای کلاسترها و لاگ‌های خطا نباید به عنوان اطلاعات درجه دوم و فاقد ارزش تلقی شوند. در دست یک بازیگر تهدید ماهر، این متادیتاها دقیقاً مانند شاه‌کلیدی عمل می‌کنند که می‌توانند مکانیزم‌های دفاعی پیچیده‌ترین فایروال‌های شرکتی را از کار بیندازند و مسیر نفوذ بدون سر و صدا را برای ماه‌ها هموار نگاه دارند.

کالبدشکافی ریسک‌های زنجیره تأمین و تهدیدهای دارک‌وب علیه زیرساخت‌های مالی و گیمینگ

پایگاه داده TiDB به دلیل توان خارق‌العاده در پردازش صدها هزار تراکنش در ثانیه، ستون فقرات زیرساختی بسیاری از پلتفرم‌های حساس به تأخیر در سراسر جهان است؛ از صرافی‌های رمزارز و سیستم‌های تسویه بانکی چندملیتی گرفته تا سرورهای چندنفره بازی‌های آنلاین که نیازمند هماهنگی آنی میلیون‌ها بازیکن هستند. نشت متادیتای چنین پلتفرم‌هایی، زنگ خطری بی‌سابقه برای زنجیره تأمین جهانی به صدا درآورده است.

گروه اخاذی FulcrumSec با قرار دادن نمونه‌هایی از داده‌های مسروقه در فروم‌های اختصاصی دارک‌وب، اقدام به اخاذی مستقیم از پینگ‌کپ و تهدید به انتشار اسناد محرمانه مشتریان این شرکت کرد. آنچه این گروه به عنوان اثبات ادعا منتشر کرد، شامل قطعه‌کدهای حساس، اسناد استقرار مخفی، و لیست کاملی از نام کاربری و ایمیل مهندسان ارشد کمپانی‌های مالی و گیمینگ متصل به کلاسترهای TiDB بود که خطرات فیشینگ هدفمند را به اوج رساند.

استراتژی اخاذی دوگانه (Double Extortion) گروه FulcrumSec متمرکز بر فشار هم‌زمان بر ارائه‌دهنده سرویس و مشتریان آن است. وقتی ارائه‌دهنده از پرداخت باج خودداری کند، مهاجمان مستقیماً با شرکت‌های تجاری موجود در لیست‌های نشت‌کرده تماس گرفته و تهدید می‌کنند که ساختار کوئری‌ها، ترافیک تراکنش‌ها و آسیب‌پذیری‌های کشف‌شده در دیتابیس‌های آن‌ها را به رقبای تجاری یا سایر کارتل‌های هکری می‌فروشند. این تهدید نشان می‌دهد که شرکت‌ها باید راهکارهای قرنطینه و مقاوم‌سازی را به سرعت در زیرساخت خود اعمال نمایند.

راهنمای عملیاتی قرنطینه و مقاوم‌سازی؛ چک‌لیست امنیت سازمان‌ها در برابر نشت متادیتا

پس از افشای این رخداد، سازمان‌هایی که از TiDB Cloud یا سرویس‌های مشابه ابری استفاده می‌کنند، باید فوراً یک پروتکل پاسخ به حادثه چندمرحله‌ای را فعال کنند. نخستین گام حیاتی، چرخش اضطراری تمام مدارک هویتی (Immediate Credential Rotation) است؛ تمامی کلمات عبور دیتابیس، کلیدهای احراز هویت API، توکن‌های دسترسی سرویس و گواهی‌های امنیتی SSL/TLS که در طول ۹۰ روز گذشته در کنسول‌های تحت وب یا اسکریپت‌های استقرار استفاده شده‌اند، باید بی‌درنگ منقضی و مجدداً تولید شوند.

گام دوم، بازنگری بنیادین در توپولوژی شبکه است. دسترسی به پورت‌های کلاسترهای پایگاه داده از طریق اینترنت عمومی تحت هر شرایطی باید مسدود شود. معماری امنیتی باید ارتباطات را منحصراً از طریق نقاط پایانی خصوصی (PrivateLink / VPC Peering) با احراز هویت متقابل mTLS مجاز بداند. این اقدام موجب می‌شود که حتی در صورت افشای متن کامل کوئری‌ها و اطلاعات ساختار دیتابیس، نفوذگران بدون حضور منطقی درون شبکه خصوصی قادر به اتصال به گره‌های داده نباشند.

گام سوم، ایجاد محدودیت سخت‌گیرانه روی استفاده از ابزارهای ادیتور وب است. تیم‌های مهندسی باید اجرای هرگونه کوئری حاوی داده‌های زنده و حساس را در محیط‌های کنسول وب ممنوع اعلام کرده و سیاست‌های عدم ذخیره‌سازی تاریخچه را فعال کنند. علاوه بر این، بررسی دقیق لاگ‌های ابری برای شناسایی هرگونه فراخوانی غیرعادی از سوی آی‌پی‌های مشکوک یا تغییرات ناگهانی در امتیازات اکانت‌های سرویس الزامی است.

مدیران سیستم باید متغیرهای محیطی حاوی توکن‌های دسترسی را از کانتینرهای استقرار حذف کرده و به جای آن از سرویس‌های مدیریت اسرار نظیر HashiCorp Vault یا AWS Secrets Manager با چرخش خودکار دوره‌ای استفاده نمایند تا ردپای اعتبارنامه‌ها از فایل‌های پیکربندی و لاگ‌های اجرایی پاک شود.

گام چهارم، پیاده‌سازی معماری رمزنگاری سمت کاربر (Client-Side Encryption) با کلیدهای تحت مدیریت سازمان (CMEK) است. اگر یک سازمان پیش از ارسال رکوردهای حساس به لایه دیتابیس، فیلدهای حیاتی را با استفاده از ماژول‌های امنیتی سخت‌افزاری رمزگذاری کند، حتی افشای کامل جدول، کوئری و متادیتای دیتابیس نیز نمی‌تواند اطلاعات واقعی را در معرض دید هکرها قرار دهد. این رویکرد انولوپ انکریپشن (Envelope Encryption) متضمن آن است که ارائه‌دهنده سرویس ابری و پرسنل نگهداری آن هرگز به کلیدهای متن آشکار داده‌ها دسترسی نداشته باشند و محیط ذخیره‌سازی همواره یک فضای باینری کدر و غیرقابل نفوذ باقی بماند.

جمع‌بندی استراتژیک تحریریه تکین؛ بازتعریف اعتماد زیرساختی در دنیای ابری ۲۰۲۶

پرونده نفوذ به پینگ‌کپ و افشای اسرار ده ترابایتی آن، نقطه عطفی تاریخی در ادبیات امنیت فناوری اطلاعات به شمار می‌رود. این رویداد نشان داد که امنیت سیستم‌های ابری دیگر با شعارهای تبلیغاتی و گواهی‌نامه‌های انطباق سنتی سنجیده نمی‌شود، بلکه نیازمند بازطراحی معماری بر مبنای اصل «فرض نفوذ پایدار» (Assume Breach Mindset) است؛ اصلی که از همان ابتدا فرض می‌کند زیرساخت‌ها در معرض نفوذ قرار دارند و سیستم باید به گونه‌ای طراحی شود که کمترین سطح افشای داده را تحمل کند.

در دنیای ابری فردا، سازمان‌های هوشمند دیگر سرنوشت داده‌های خود را به ارائه‌دهندگان ثالث واگذار نمی‌کنند بدون آنکه بر ریزترین سطوح تله‌متری و ذخیره‌سازی لاگ‌ها نظارت داشته باشند. اعتماد به دیتابیس‌های ابری باید از یک رابطه کورکورانه به یک تعامل مبتنی بر راستی‌آزمایی ریاضی، ایزولاسیون پردازش محرمانه (Confidential Computing با فناوری‌های AMD SEV-SNP و Intel SGX) و تفکیک قطعی کنترل پلین از داده‌های مشتریان ارتقا یابد. در این معماری‌های نوین، حتی اگر کل کنترل پلین و کوبرنتیز اپراتور ارائه‌دهنده هک شود، حافظه موقت محاسباتی (RAM Enclaves) در سطح سخت‌افزار پردازنده رمزگذاری شده و مانع هرگونه استخراج دیتای زنده می‌گردد.

حادثه TiDB هشداری رسا به تمامی مدیران ارشد فناوری است که برای همیشه توهم امنیت تضمین‌شده در اَبَر را کنار بگذارند و با تجهیز زیرساخت‌های خود به سیستم‌های دفاعی لایه‌بندی‌شده و ایزولاسیون کامل متادیتا، پایداری سازمان خود را در برابر زلزله‌های بعدی تضمین کنند؛ چرا که در عصر حملات سایبری نسل ششم، بقای کسب‌وکارها در گرو پارانویا و هوشیاری مهندسی مداوم است.