مايكروسوفت ترفض تصنيف ثغرة حرجة في Azure وتتجاهل إصدار معرف CVE

مقدمة تحليلية

في خطوة أثارت موجة من الجدل داخل مجتمع الأمن السيبراني العالمي، رفضت شركة Microsoft الاعتراف بتقرير أمني يسلط الضوء على ثغرة وصفت بأنها 'حرجة' في منصة Azure السحابية. التقرير، الذي قدمه باحثون أمنيون مستقلون، يشير إلى وجود خلل بنيوي قد يسمح بتجاوز حدود الأمان، إلا أن عملاق البرمجيات قرر عدم إصدار معرف CVE (Common Vulnerabilities and Exposures) لهذه الحالة، مكتفياً بتصنيفها كمسألة لا تستدعي تحديثاً أمنياً رسمياً. هذا الرفض ليس مجرد إجراء إداري، بل هو انعكاس لسياسة 'الإصلاح الصامت' التي تنتهجها شركات السحابة الكبرى، حيث يتم معالجة الخلل في الكود المصدري من جانب الخادم دون إخطار المستخدمين أو توثيق الثغرة في قاعدة البيانات الوطنية للثغرات (NVD). إن غياب الشفافية في هذا السياق يضع مديري الأنظمة وخبراء الاستجابة للحوادث في موقف صعب، حيث يفتقرون إلى المعايير الموحدة لتقييم المخاطر التي قد تكون تعرضت لها بياناتهم خلال فترة وجود الثغرة قبل معالجتها غير المعلنة.

التحليل التقني

تعتمد Microsoft في تقييمها للثغرات على معايير مركز استجابة الأمن (MSRC)، والتي تشترط أن تكسر الثغرة 'حداً أمنياً' (Security Boundary) معتمداً لكي تستحق إصدار معرف CVE. في الحالة الراهنة، (بيانات تقنية مفصلة حول كود الثغرة غير متوفرة في المصدر الأصلي)، ولكن النزاع يتمحور حول مفهوم 'عزل المستأجرين' (Tenant Isolation) في بيئات الحوسبة السحابية. تتضمن النقاط التقنية الخلافية عادةً ما يلي:

• تجاوز صلاحيات الهوية المدارة (Managed Identity): حيث يمكن لهوية معينة الوصول إلى موارد خارج نطاقها المسموح.
• ثغرات حقن الكود في خدمات التكامل: مثل Azure Data Factory أو Azure Automation.
• الوصول غير المصرح به إلى بيانات التعريف (Metadata Service) الخاصة بالآلات الافتراضية.

عندما ترفض مايكروسوفت إصدار CVE، فإنها غالباً ما تبرر ذلك بأن الثغرة تتطلب 'سوء تكوين' من قبل المستخدم، أو أنها تقع ضمن نطاق 'نموذج المسؤولية المشتركة'. ومع ذلك، يجادل الباحثون بأن أي ثغرة تسمح لمستخدم في 'مستأجر' (Tenant) معين برؤية أو تعديل بيانات مستخدم في مستأجر آخر، حتى لو كانت تتطلب ظروفاً خاصة، يجب أن تُوثق رسمياً لضمان قدرة الشركات على مراجعة سجلات الوصول (Audit Logs) بأثر رجعي. الخطر التقني هنا يكمن في 'العمى الأمني'؛ فمعظم أدوات مسح الثغرات (Vulnerability Scanners) تعتمد كلياً على معرفات CVE لتحديد الأنظمة المصابة. وبدون هذا المعرف، تظل الثغرة غير مرئية لأدوات الامتثال والرقابة الآلية، مما يترك ثغرة في جدار الحماية التنظيمي للمؤسسات الكبرى.

السياق وتأثير السوق

تأتي هذه الواقعة في وقت تواجه فيه Azure ضغوطاً متزايدة لتعزيز موثوقيتها الأمنية بعد سلسلة من الإخفاقات البارزة في السنوات الأخيرة. إن قرار عدم إصدار CVE يؤثر بشكل مباشر على 'اقتصاديات الأمن'؛ حيث تعتمد شركات التأمين السيبراني على هذه المعرفات لتسعير بوالص التأمين وتقدير حجم التعرض للمخاطر. غياب التوثيق الرسمي يعني أن الشركات المؤمن عليها قد لا تتمكن من إثبات وقوع حادث أمني مرتبط بثغرة 'مرفوضة' من قبل المزود. بالمقارنة مع المنافسين، نجد أن Amazon Web Services (AWS) وGoogle Cloud Platform (GCP) يتبعان أحياناً نهجاً مختلفاً، لكن المشكلة تظل قائمة في قطاع السحابة ككل. السوق حالياً يشهد حالة من 'تعب الثغرات'، حيث يتم اكتشاف آلاف العيوب سنوياً، مما يدفع الشركات الكبرى لمحاولة تقليل عدد الـ CVEs المرتبطة بأسمائها للحفاظ على سمعة علامتها التجارية وتجنب انخفاض أسهمها في البورصة عند الإعلان عن ثغرات واسعة النطاق. علاوة على ذلك، فإن هذا الرفض يؤثر على العلاقة بين شركات التقنية ومجتمع البحث الأمني. الباحثون الذين يقضون مئات الساعات في هندسة عكسية لأنظمة Azure المعقدة يشعرون بالإحباط عندما يتم تجاهل نتائجهم أو 'سرقتها' من خلال إصلاحها بصمت دون منحهم الائتمان المناسب أو المكافأة المالية العادلة (Bug Bounty)، مما قد يدفعهم مستقبلاً لنشر الثغرات علناً (Full Disclosure) قبل إبلاغ الشركة، وهو سيناريو كارثي للجميع.

رؤية Glitch4Techs

في Glitch4Techs، نرى أن امتناع Microsoft عن إصدار CVE لثغرة وصفت بالحرجة يمثل تراجعاً عن وعود الشفافية التي قطعتها الشركة بعد اختراقات 2023. إن 'الأمان بالغموض' (Security by Obscurity) هو استراتيجية فاشلة في بيئة سحابية مترابطة. لا يمكن لمزود الخدمة أن يكون هو الخصم والحكم في آن واحد عند تقييم خطورة أخطائه البرمجية. المخاوف الأساسية التي نراها تشمل:

• تآكل الثقة في 'نموذج المسؤولية المشتركة': إذا كان المزود يخفي الثغرات، فكيف يمكن للمستخدم تحمل مسؤوليته؟
• تأخر الاستجابة للمخاطر: الشركات التي لا تعرف بوجود الثغرة لن تقوم بتغيير مفاتيح التشفير أو مراجعة الأذونات.
• خلق سوق سوداء للمعلومات: رفض التوثيق الرسمي يشجع على بيع هذه الثغرات لجهات استخباراتية أو مجموعات برامج الفدية.

نتوقع أن تتدخل الهيئات التنظيمية مثل CISA في الولايات المتحدة أو وكالة ENISA في الاتحاد الأوروبي لفرض معايير أكثر صرامة على 'الإصلاحات الصامتة'. نوصي عملاء Azure حالياً بتبني نهج 'عدم الثقة المطلق' (Zero Trust) وعدم الاعتماد فقط على تحديثات مايكروسوفت، بل يجب مراقبة سلوك الهويات داخل السحابة بشكل مستقل واستخدام أدوات طرف ثالث لرصد التغييرات غير الموثقة في البنية التحتية.