تلقى مجتمع الأمن السيبراني خبرًا لافتًا: سلسلة استغلال (Cyber Chain) مرتبطة بخدمة قاعدة بيانات سحابية يمكن أن تسمح—نظريًا ثم عمليًا في المختبر—بتجاوز عزل الاستعلامات داخل محرك Gremlin في Azure Cosmos DB. وفقًا لبحث شركة Wiz، كان بإمكان المهاجم الهروب من “صندوق الحماية” الخاص باستعلامات الرسم البياني ثم الحصول على صلاحيات قراءة وكتابة واسعة عبر قواعد بيانات عملاء ضمن مستأجرات متعددة (Multi-Tenancy)، أي داخل نفس منصة السحابة لكن تحت حسابات مختلفة.

الأهمية هنا لا تتعلق فقط بمنتج بعينه، بل بنمط خطير يتكرر في البنية السحابية الحديثة: عندما يفشل افتراض “العزل” بين طبقات التنفيذ أو بين المستأجرين، قد يتحول خلل برمجي من مشكلة محلية إلى نافذة اختراق أوسع—حتى لو لم يتم اختراق بيانات الضحايا مباشرة في حالة الإبلاغ هذه.

ما الذي حدث؟ من استعلام Gremlin إلى مفاتيح تمنح سيطرة شاملة

بحسب Wiz، بدأت السلسلة باسم استعلام مُصاغ ضد قاعدة Gremlin يملكها المهاجم—أي ليست اختراقًا مباشرًا لقاعدة ضحية من البداية. الفكرة كانت كسر القيود التي تُفرض عادةً على الاستعلامات داخل محرك Gremlin المدمج، ثم استخدام ما نتج عن ذلك للوصول إلى مكوّن داخلي حساس داخل النظام.

الخلل أُطلق عليه اسم CosmosEscape، وادعت Wiz أن محرك Gremlin في Cosmos DB يقوم بترجمة استعلامات Gremlin إلى كود .NET ويشغله داخل بيئة مُقيّدة. المشكلة—كما وصفتها Wiz—أن القيود لم تُحسن التعامل مع انعكاس .NET (Reflection)، وهو مفهوم برمجي يسمح للبرنامج بفحص الأنواع واستدعاء وظائف بشكل ديناميكي، ما قد يفتح الباب لبناء قدرات قراءة/كتابة ملفات ثم الوصول إلى تنفيذ أوامر عشوائية (Arbitrary Code Execution).

لماذا تعتبر “التنفيذ داخل بيئة مقيدة” نقطة انكسار؟

في الأنظمة التي تسمح للمستخدم بإرسال استعلامات، تُبنى حماية عادة على فكرة: “حتى لو نفذنا كودًا، سنحبسه داخل بيئة مقيدة.” لكن في البيئات متعددة المستأجرين، فإن أي مسار يؤدي إلى مفاتيح توقيع أو دلائل حسابات أو قدرة على جلب مفاتيح أولية قد يحول هذا الحبس إلى مجرد تأخير قبل الوصول إلى السيطرة.

وفقًا للتفاصيل المنشورة، وصل التنفيذ إلى ما سمي DB Gateway، وهو مكوّن ينفذ استعلامات العملاء على عنقود متعدد المستأجرين داخل Azure Service Fabric. ورغم أن قواعد البيانات الخاصة بالعملاء لا تُخزن في تلك العناقيد نفسها، إلا أن هذا البوابة—بحسب Wiz—كانت قادرة على استرجاع المفتاح الأساسي (Primary Key) لحساب Cosmos DB المطلوب.

والمفتاح الأساسي هنا هو نقطة التحول: Microsoft توضح أن المفتاح الأساسي يمنح تحكمًا كاملاً على موارد حساب Cosmos DB. والأخطر في رواية Wiz أن هناك “سر توقيع” على مستوى النظام يمكنه—عبر بوابة DB Gateway—تجاوز حدود المستأجرين والوصول إلى مفاتيح أولية عبر حسابات مختلفة ضمن مناطق متعددة وأيضًا عبر واجهات APIs متعددة مثل SQL وMongoDB وCassandra وGremlin.

ما الذي يعنيه ذلك عمليًا؟ مفاتيح، كتالوجات، وحدود شبكة

يرسم تقرير Wiz صورة لثلاثة مسارات حساسة:

• استرجاع مفاتيح أولية لحسابات أخرى: ما يتيح لاحقًا طلب صلاحيات قراءة/كتابة على نطاق أوسع داخل المنصة.
• الوصول إلى Config Store: وصفته Wiz كـ”دليل” يحتوي أسماء حسابات Cosmos DB ومعرّفات الاشتراك والـTenant وإعدادات الشبكة والعلامات. هذا النوع من الكتالوجات يجعل الاستهداف أكثر دقة لأن المهاجم لا يحتاج إلى التخمين.
• تجاوز حدود العزل الشبكي من داخل الخدمة: إذا كانت البوابة تفرض حدود الشبكة من داخلية المنصة، فإن استغلالها من الداخل قد يجعل الحدود أقل فعالية.

وتشير Wiz أيضًا إلى أن سلسلة الاستغلال قد تصل إلى حسابات “معزولة” خصوصًا إذا كانت حدود الشبكة تُطبّق من خلال نفس المكوّن الذي تم اختراقه. وفي تقريرها، لم تُثبت Wiz تغييرًا فعليًا لإعدادات شبكة عميل آخر، لكنها استنتجت إمكانية ذلك بناءً على الوصول إلى Config Store.

هل تم الوصول إلى بيانات العملاء؟

هنا تبرز نقطة مهمة: Microsoft قالت—بعد تحقيق—لم تجد دليلًا على نشاط غير مصرح خارج اختبار الباحثين، وصرّحت بأنه لم يتم الوصول إلى بيانات عملاء، ولا توجد إجراءات مطلوبة من العملاء. كذلك ذكرت أن مراجعتها لم تُظهر استخدامًا غير مشروع خارج نطاق الاختبار.

مع ذلك، تبقى قيمة القصة عالية لأنها توضّح “كيف” يمكن أن يحدث تجاوز للعزل لو توافرت شروط تشغيلية مختلفة، أو لو كان المهاجم يمتلك مدخلات أكثر ملاءمة، أو لو كان هناك نافذة زمنية أطول قبل الإغلاق.

وتيرة الإصلاح: إغلاق نقطة الدخول ثم إصلاح شامل

بحسب المعلومات المتاحة، تم إيقاف نقطة دخول Gremlin خلال أقل من يومين (خلال 48 ساعة) من تقرير نوفمبر 2025. ثم أكملت Microsoft إصلاحًا طويل الأمد عبر جميع المناطق في يوليو 2026، وألغت كذلك “المفتاح على مستوى المنصة” الذي لعب دورًا محوريًا في السلسلة.

هذا التسلسل—إجراء إسعافي سريع ثم علاج شامل—يمثل نمطًا يُعتبر أفضل ممارسة في الاستجابة: تقليل سطح الهجوم فورًا، ثم معالجة السبب الجذري (Root Cause) بدل الاكتفاء بمنع المدخلات فقط.

ماذا نتعلم؟ العزل في السحابة ليس “سحرًا”

من منظور دفاعي، هذه الحادثة تذكّرنا بأن العزل في السحابة يعتمد على طبقات متعددة: قيود على الاستعلام، قيود على التنفيذ داخل محرك الرسوم، قيود على التفاعل مع المكوّنات الداخلية، وأخيرًا حماية أسرار مثل مفاتيح التوقيع والفهارس.

وعندما يفشل قيد واحد—مثل قيود التنفيذ التي لم تمنع Reflection بشكل كافٍ—فإن سلسلة الاستغلال قد تستخدم ذلك للوصول إلى مكوّنات “تملك مفاتيح” أو “تملك كتالوجات”، فتتغير المعادلة من اختراق محلي إلى اختراق على مستوى المنصة.

للتقريب، يمكنك اعتبار الأمر مثل نظام داخل مبنى: حتى لو كانت غرفة الاجتماعات محمية، فإن وجود مفتاح رئيسي لدى موظف في مكتب استقبال يفتح الباب لباقي الأدوار. في الحالة الرقمية، “المفتاح الرئيسي” كان سر توقيع وممرًا داخليًا يربط بين المستأجرين.

كيف يرتبط ذلك باتجاهات التهديد الأوسع؟

شهدت السنوات الأخيرة زيادة في استهداف بيئات السحابة عبر استغلال نقاط ضعف في منطق التطبيقات أو محركات الاستعلام أو تكاملات الخدمة. وبالتوازي، ارتفعت أهمية مفاهيم مثل:

• الاعتماد على “حواجز التنفيذ”: أي بيئة مقيدة يجب أن تُصمم وفق نموذج تهديد واقعي، وليس وفق افتراضات مبسطة.
• تقليل الامتيازات عبر المكوّنات: تقليل قدرة البوابات الداخلية على جلب مفاتيح حسابات أخرى.
• إدارة الأسرار على مستوى المنصة: تقليل تأثير اختراق سر واحد عبر إلغاء المفاتيح على المستوى العام أو تطبيق فصل أشد.

كما أن هذا النوع من القضايا ينسجم مع توجهات أوسع في الصناعة نحو “هندسة أمنية افتراضية” (Security-by-Design)، حيث لا يكفي إجراء تصحيح بعد وقوع الخطر؛ بل يجب إعادة تصميم القيود لتصمد أمام قدرات ديناميكية مثل Reflection.

من زاوية الامتثال، كثير من المؤسسات تستند إلى ممارسات مثل إطار NIST للأمن السيبراني واعتبارات التحكم في الوصول والمفاتيح، إضافة إلى مبادئ التحقق المستمر وعدم الثقة بين المكوّنات. ورغم أن هذه الأطر ليست “قانونًا” مباشرًا على مزود السحابة، إلا أنها توفر لغة موحدة لتقييم ما إذا كان العزل كافيًا وما إذا كانت الأسرار موزعة بطريقة تقلل من أثر الاختراق.

لماذا لم تُسجل ثغرة بمعرّف CVE؟ وما الذي يعنيه ذلك؟

وفقًا للبيان المتداول، لم تُدرج السلسلة بمعرّف CVE أو درجة شدة (CVSS). هذا لا يعني أن الخطر غير حقيقي؛ بل قد يعني أن التصنيف الرسمي لم يكتمل أو لم يُنشر ضمن المصادر المتاحة. عمليًا، قد يربك غياب CVE الفرق بين “تحديثات عامة” و“تحديثات مرتبطة بخلل محدد”، وهو سبب آخر يجعل من المهم للمؤسسات متابعة بلاغات المزوّدين وتوصياتهم التشغيلية بدل الاعتماد فقط على نشرات CVE.

خلاصة دفاعية: كيف تستعد المؤسسات لمثل هذه السيناريوهات؟

حتى لو كان الإصلاح قد تم بواسطة مزود الخدمة، فإن الدرس يهم كل من يستخدم قواعد بيانات سحابية أو محركات استعلام تدعم منطقًا معقدًا. ويمكن تلخيص ما يجب فعله دفاعيًا في نقاط عملية:

• مراجعة سياسات المفاتيح: التأكد من أن المفاتيح تُدار بأقل صلاحيات ممكنة وأن الوصول إلى المفاتيح الأساسية لا يكون “واسعًا بلا داع”.
• تنشيط المراقبة: رصد أنماط الاستعلام غير المعتادة، ومحاولات التنفيذ غير المتوقعة داخل محركات الاستعلام.
• تطبيق مبدأ الفصل: فصل البيئات (Development/Production) وتقييد الاتصال الشبكي قدر الإمكان، مع التحقق من أن الحدود تُفرض من طبقات متعددة.
• الاستعداد للإبلاغ المنسق: وضع إجراءات داخلية لتلقي بلاغات المزوّدين وتحويلها إلى تحديثات وتحقق سريع.

وفي النهاية، هذه الحادثة تطرح سؤالًا جوهريًا على كل فريق أمن سحابي: هل تعتمد دفاعاتك على “قيود استعلام” تبدو قوية، لكنها قد تنهار أمام قدرات ديناميكية مثل Reflection أو أمام مسارات داخلية للوصول إلى الأسرار؟

سؤالي للنقاش: إذا كان العزل داخل خدمة سحابية ينهار بسبب خلل في محرك استعلام، فما هي أسرع طريقة لديك لتقليل الأثر—هل هي فصل المفاتيح، أم تقييد الوصول إلى البوابات الداخلية، أم مراقبة سلوك الاستعلام قبل فوات الأوان؟

للمتابعة والنقاش، يمكنك مشاركة رأيك عبر منصاتنا:

• فيسبوك
• إكس

هاشتاغات مقترحة: #الأمن_السيبراني #الأمن_السحابي #اختراق_السحابة #إدارة_المفاتيح #التصحيح_السريع

مصادر إضافية للاطلاع:
Gremlin,
CVE,
التحقق المستمر.