مايكروسوفت ستورم-0558: التحكم التشغيلي في ضرر الرموز المميزة كاختبار للمساءلة العامة

ملخص

• استخدمت ستورم-0558 مفتاح توقيع مايكروسوفت للمستهلكين وثغرة في التحقق للوصول إلى بريد Exchange Online المؤسسي. مما جعل التحكم في الضرر التشغيلي مهمة تقع على عاتق المزود بشكل أساسي، لأن العملاء لم يتمكنوا من تدوير مفتاح مايكروسوفت، أو تصحيح مدقق الرموز المميزة الخاص بها، أو فحص بيئة التوقيع الداخلية لديها.
• جاء أهم اختبار للمساءلة العامة بعد فشل الثقة: مدى سرعة مايكروسوفت في تحديد مسار الرموز المميزة المزورة، وإيقاف تجديدها، ومنع قبول المفتاح، واستبدال مواد التوقيع، وتوسيع سجلات العملاء، وشرح ما ظل مجهولاً.
• خلص مجلس مراجعة السلامة الإلكترونية لاحقاً إلى أن الحادثة كان يمكن منعها وانتقد ثقافة الأمان لدى مايكروسوفت، وإدارة المفاتيح، وضوابط التحقق، والوصول إلى السجلات، وتصحيح تفسير سابق لكيفية الحصول على المفتاح. قبلت مايكروسوفت نتائج المجلس وأعلنت عن عمل مبادرة المستقبل الآمن، لكن الكثير من أدلة التنفيذ لا تزال تقارير ذاتية من المزود.
• مسار الحصول على المفتاح غير المحسوم مهم. تم تضييق رواية مايكروسوفت حول تفريغ الذاكرة إلى فرضية رئيسية بعد أن قالت الشركة إنها لم تعثر على تفريغ ذاكرة يحتوي على المفتاح المتأثر. وبالتالي تقع المساءلة على إخفاقات السيطرة المثبتة وعدم اليقين المتبقي، وليس على سلسلة سرقة مثبتة بالكامل.

خريطة الأدلة

ضرر الرموز المميزة هو نمط فشل يتحكم به المزود

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

لهذا السبب فإن السيطرة التشغيلية على الضرر هي العدسة المركزية. يمكن للعملاء تحصين الحسابات، وطلب المصادقة متعددة العوامل، وتقليل الامتيازات، ومراقبة السجلات، والاستجابة بسرعة. لا يمكنهم تدوير مفاتيح التوقيع الداخلية لمايكروسوفت. لا يمكنهم تغيير كود التحقق من جانب الخادم في Exchange Online. لا يمكنهم رؤية كل مسار إصدار رمز مميز داخلي. لا يمكنهم الاحتفاظ بتفريغات الذاكرة الداخلية لمايكروسوفت أو سجلات بيئة التوقيع. عندما تفشل البنية التحتية للثقة لمزود السحابة، تكون قدرة العميل على منع الضرر الأول محدودة للغاية.

جعلت استشارة CISA-FBI هذا التخصيص واضحاً بشكل استثنائي. قالت إن إجراءات التخفيف للنشاط كانت مسؤولية مايكروسوفت لأن البنية التحتية المتأثرة كانت قائمة على السحابة. هذه الجملة مهمة. لا تعني أن العملاء لم يكن لهم دور في الكشف أو الاستجابة. كان كشف وزارة الخارجية حاسماً. إنها تعني أن إجراءات الاحتواء الحاسمة كانت من جانب المزود: توقف عن قبول المسار المزور، واحظر المفتاح، واستبدل مواد التوقيع، ووسع الأدلة. هذه هي السيطرة التشغيلية على الضرر.

لم يكن الحدث اختراقاً عادياً لعلب البريد. لم تكن ستورم-0558 بحاجة إلى اصطياد كلمة مرور كل هدف. لقد أساءت استخدام قرار ثقة هوية سحابية. وهذا يجعل الضرر عاماً بطريقة تتجاوز المنظمات الضحية. تعتمد الحكومات والشركات المنظمة والجمهور على مستوى هوية المزود كبنية تحتية مشتركة. إذا فشلت حدود الرموز المميزة التي يتحكم بها المزود، فلا يمكن اختزال المساءلة إلى تكوين العميل.

يتطلب السجل العام أيضاً الدقة. كانت الحادثة في المقام الأول فشلاً في السرية والاتصالات الموثوقة، وليس انقطاعاً لتوفر Exchange Online. استمر البريد في العمل. كان الضرر هو الوصول الصامت إلى الرسائل وفقدان الثقة بأن حدود هوية الخدمة قد صمدت. تشمل استمرارية القطاع العام هذا النوع من الضرر. يمكن أن يظل صندوق البريد الدبلوماسي قابلاً للوصول بينما تكون محتوياته مخترقة.

بقيت قصة الحصول على المفتاح دون حل

قدم منشور مايكروسوفت في سبتمبر 2023 حول الحصول على المفتاح في الأصل رواية مفصلة عن تفريغ الذاكرة. وصفت انهياراً في أبريل 2021 في نظام توقيع المستهلك، ثم انتقل تفريغ الذاكرة إلى بيئة تصحيح أخطاء الشركة، وفشل فحص بيانات الاعتماد في اكتشاف مادة المفتاح، واختراق لاحق لحساب مهندس. أصبحت هذه القصة رواية عامة للسبب الجذري. في مارس 2024، أضافت مايكروسوفت تصحيحاً يضيق نطاق الادعاء. قالت إنها لم تجد تفريغ ذاكرة يحتوي على المفتاح المتأثر وأن مسار تفريغ الذاكرة ظل فرضية رئيسية بدلاً من حقيقة مثبتة.

جعل CSRB عدم اليقين هذا محورياً. أفاد بأن مايكروسوفت حققت في فرضيات عديدة ولا تزال لا تعرف بالضبط كيف أو متى حصلت ستورم-0558 على المفتاح الخاص MSA لعام 2016. هذا المسار غير المحلول ليس ملاحظة جانبية. إذا كان مسار الحصول غير معروف، فلا يمكن للمزود أن يثبت علناً أن نفس المسار قد تم إغلاقه بالكامل. يمكنه تعزيز إدارة المفاتيح، وعزل أنظمة التوقيع، وتحسين السجلات، وأتمتة التدوير، وتقليل نطاق الانفجار المستقبلي. هذه ضوابط حقيقية. لكنها لا تحدد بأثر رجعي سلسلة السرقة.

لذلك يجب أن تقوم المساءلة على فئتين. الفئة الأولى هي الإخفاقات المثبتة أو المدعومة بقوة: ظل مفتاح قديم موثوقاً، وفشل التحقق عبر حدود المستهلك-المؤسسة، ولم تكن السجلات الموسعة متاحة على نطاق واسع للعملاء، وبالغ تفسير مايكروسوفت العام المبكر في يقين مسار الحصول على المفتاح. الفئة الثانية هي عدم اليقين المتبقي: كيف غادر المفتاح سيطرة مايكروسوفت بالضبط، وما إذا كانت أي مواد حساسة ذات صلة قد تعرضت، وما إذا كان هناك مسار أدلة داخلي كامل على الإطلاق.

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

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

بدأ التحكم في الضرر بإجراءات التحقق والمفاتيح

يُظهر تسلسل التخفيف العام أن الاحتواء لم يكن مفتاحاً واحداً. قالت مايكروسوفت إنها أوقفت OWA عن قبول الرموز المميزة الصادرة عن GetAccessTokenForResource للتجديد، ومنعت OWA من استخدام الرموز المميزة الموقعة بواسطة مفتاح MSA المكتسب، واستبدلت المفتاح، وسحبت مفاتيح توقيع MSA التي كانت صالحة أثناء الحادثة، وأصدرت مفاتيح جديدة من أنظمة محصنة، ومنعت الاستخدام للعملاء المستهلكين المتأثرين لمنع استخدام الرموز المميزة الصادرة سابقاً. كان هذا برنامجاً مرحلياً للتحكم في الضرر.

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

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

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

تُظهر الحادثة أيضاً سبب أهمية عمر المفتاح كمخاطر تشغيلية، وليس فقط كنظافة تشفير. يعطي مفتاح طويل العمر يظل موثوقاً بعد دورة حياته المقصودة للمهاجم هدف قيمة أكبر ونافذة فائدة محتملة أطول. وجد CSRB أن تدوير مفتاح توقيع المستهلك لمايكروسوفت أصبح يدوياً ثم توقف بعد مخاوف انقطاع، دون استبدال آلي مكتمل. هذه مقايضة بين التوفر والأمان تكبدت تكلفتها المؤجلة في حادثة سرية. تشمل السيطرة التشغيلية على الضرر جعل تدوير المفاتيح مملاً بما يكفي بحيث لا يؤدي الخوف من الانقطاع إلى تجميد دورة حياة الأمان.

كانت السجلات محور المساءلة العامة

اكتشفت وزارة الخارجية نشاطاً مريباً من خلال سجلات الوصول إلى علب البريد الموسعة. غيرت هذه الحقيقة الحادثة. أظهرت أن العملاء يمكنهم تقديم إشارة حاسمة حتى عندما كان المزود يسيطر على التخفيف. كما كشفت مشكلة ترخيص. في ذلك الوقت، أكدت استشارة CISA-FBI على أهمية أحداث تدقيق MailItemsAccessed وأشارت إلى أن السجلات ذات الصلة كانت مرتبطة بترخيص من مستوى أعلى. أثنت CISA لاحقاً علناً على التزام مايكروسوفت بتوسيع السجلات الهامة دون تكلفة إضافية.

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

التزم إعلان مايكروسوفت للسجلات في يوليو 2023 بتوسيع الوصول إلى سجلات الوصول إلى البريد الإلكتروني المفصلة وأكثر من 30 حدث تدقيق آخر للعملاء القياسيين، وزيادة الاحتفاظ الافتراضي بـ Audit Standard من 90 إلى 180 يوماً. أعلنت CISA وOMB وONCD ومايكروسوفت لاحقاً عن توسيع السجلات للوكالات الفيدرالية، مع التمكين التلقائي والاحتفاظ الافتراضي لمدة 180 يوماً. كانت هذه التغييرات كبيرة لأنها نقلت الأدلة من ملحق مدفوع نحو توقع أمان أساسي.

درس المساءلة أوسع من نوع سجل واحد. يجب على مزودي السحابة التعامل مع السجلات اللازمة لاكتشاف إخفاقات السيطرة من جانب المزود كجزء من طبقة سلامة الخدمة. لا ينبغي للعملاء أن يضطروا لشراء رؤية مميزة لاكتشاف أنه تم إساءة استخدام مفتاح مزود أو خلل في التحقق. يمكن للمزودين فرض رسوم على التحليلات المتقدمة والتخزين والكشف المُدار. لكن أحداث الأمان الخام اللازمة لإعادة بناء الوصول إلى بيانات العملاء تنتمي إلى خط الأساس بشكل أقرب.

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

تشمل استمرارية القطاع العام الاتصالات الموثوقة

تضمنت الحسابات المتأثرة علب بريد للقطاع العام وجهات حكومية ذات صلة. قالت وزارة الخارجية لاحقاً إن ما يقرب من 60,000 بريد إلكتروني تم تحميلها من 10 حسابات وأن النظام المخترق كان غير مصنف، ولم يتم اختراق البريد الإلكتروني المصنف. حدد CSRB 22 منظمة وأكثر من 500 فرد متضررين في جميع أنحاء العالم. تؤطر هذه التفاصيل الضرر بعناية: لم يكن انهياراً لتوفر البريد الإلكتروني الحكومي، والسجل العام لا يكشف عن محتوى الرسائل. كان مع ذلك فشلاً خطيراً في الاتصالات الموثوقة.

يعتمد العمل الحديث للقطاع العام على البريد الإلكتروني السحابي للدبلوماسية والتجارة والسياسة والجدولة والتفاوض والتنسيق الإداري. يمكن أن يغير فقدان السرية السلوك حتى لو ظلت الخدمة متصلة. قد يحتاج المسؤولون إلى افتراض أن الاتصالات قد تمت قراءتها، وقد تحتاج المصادر أو الخطط إلى الحماية، وقد تنتقل الاتصالات المستقبلية إلى قنوات مختلفة. لم تكن الخدمة بحاجة إلى التعطل لفرض تكلفة تشغيلية.

لهذا السبب تنتمي ستورم-0558 إلى استمرارية القطاع العام وكذلك الأمن السيبراني. غالباً ما يتم تعريف الاستمرارية من خلال التوفر: هل يمكن للوكالة مواصلة العمل؟ يتضمن النموذج الأكثر نضجاً التشغيل الموثوق: هل يمكن للوكالة الاستمرار في استخدام الخدمة لوظيفتها العامة المقصودة دون رؤية الخصم؟ صندوق البريد الذي يعمل تقنياً ولكن يمكن للخصم قراءته بصمت هو بنية تحتية متدهورة.

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

عكست الرسائل البرلمانية وجلسات الاستماع ومراجعة CSRB هذا الاعتماد. لم تنشئ حكماً قضائياً أو نتيجة مسؤولية تنظيمية، لكنها جلبت ثقافة الأمان وإدارة المفاتيح وخيارات السجلات للمزود إلى العلن. هذا مناسب لفشل في البنية التحتية المشتركة لهوية السحابة المستخدمة من قبل الوكالات العامة.

أصبحت ثقافة الأمان سيطرة تشغيلية

لم يقتصر تقرير CSRB على عيب واحد في الكود. انتقد ثقافة الأمان لدى مايكروسوفت ووصف سلسلة من الإخفاقات التي يمكن تجنبها. هذا التأطير مهم لأن دورة حياة مفتاح التوقيع، والتحقق من الرمز المميز، وإعدادات السجلات الافتراضية، واختراق شبكة الشركة، وتصحيح السبب الجذري، ورؤية العملاء ليست أخطاء معزولة. إنها نتائج الأولوية التنظيمية، وأنظمة الهندسة، وقبول المخاطر، والحوكمة.

قد تبدو ثقافة الأمان غامضة. في هذه الحادثة كان لها أشكال ملموسة. توقفت عملية تدوير المفاتيح اليدوية بعد مخاوف الانقطاع دون استبدال آلي مكتمل. عبر افتراض تحقق حدود المستهلك-المؤسسة. قيدت السجلات المميزة رؤية العملاء. ظل تفسير عام مبكر يقينياً للغاية لفترة طويلة جداً بعد أن عرفت مايكروسوفت أنه يتطلب تصحيحاً. هذه ليست مواقف؛ إنها قرارات تشغيلية وحالات سيطرة.

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

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

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

يجب أن يكون التحقق من الرمز المميز مملاً ومركزياً وصعب التجاوز

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

تشرح وثائق هوية مايكروسوفت الحالية مفاهيم مثل المُصدر، والجمهور، ومفاتيح التوقيع، والبيانات الوصفية للاكتشاف، ورموز الوصول، وتدوير المفاتيح. هذه الوثائق هي مراجع موجهة للعملاء، وليست دليلاً على حالة الكود لعام 2023. لا تزال تُظهر منطق التحكم: التوقيع الصالح لا يكفي إذا تم إصدار الرمز المميز لعالم هوية مختلف، أو جمهور، أو مستأجر، أو خدمة. الصلاحية التشفيرية تجيب على سؤال واحد. سياق التفويض يجيب على آخر.

مهمة المزود هي جعل المسار الآمن هو المسار السهل. إذا احتاجت خدمة إلى قبول رموز هوية مميزة، فيجب أن تستخدم مكتبة قياسية تفرض قواعد المُصدر، والجمهور، والمستأجر، والنطاق، ومصدر المفتاح، وتحديث البيانات الوصفية. يجب أن تكون الانحرافات نادرة، ومراجعة، ومسجلة، ومختبرة. يجب أن يكون تدوير المفاتيح في حالات الطوارئ متدرباً عليه. يجب أن ترفض الخدمات التركيبات المستحيلة بشكل افتراضي. يجب أن تراقب المراقبة الرموز المميزة التي لا تكون علاقتها بمفتاح التوقيع والمُصدر والمورد والمستأجر منطقية.

يستفيد العملاء عندما يصبح التحقق من المزود مملاً. لا ينبغي أن يضطروا للسؤال عما إذا كان كل فريق خدمة في مايكروسوفت قد نفذ التحقق من الرمز المميز بشكل صحيح. يجب أن يكونوا قادرين على الاعتماد على ضوابط الهوية المركزية والضمان المستقل. أظهرت حادثة ستورم-0558 ما يحدث عندما يصبح الحد الذي كان يجب أن يكون نظامياً خاصاً بالخدمة بما يكفي ليكون للخلل أهمية.

يمتد هذا الدرس إلى ما بعد مايكروسوفت. يدير كل مزود سحابة كبير بنية تحتية للرموز المميزة تعبر المنتجات والمستأجرين وعوالم الهوية وواجهات برمجة التطبيقات. التحقق المركزي، ودورة حياة المفاتيح الآلية، والأدلة المرئية للعملاء هي متطلبات أمان شائعة. جعلت الحادثة هذه المتطلبات عامة لأن الفشل لامس البريد الحكومي.

يغير عدم اليقين المتبقي عبء الضمان

تنتهي بعض الحوادث بسبب جذري دقيق وإغلاق دقيق. ستورم-0558 لا تفعل، على الأقل في السجل العام. لا يزال مسار الحصول على المفتاح غير محلول. أفاد CSRB أن مايكروسوفت لم تتمكن من تحديد كيف أو متى تم الحصول على المفتاح. هذا عدم اليقين لا يمنع المعالجة. إنه يغير عبء الضمان.

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

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

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

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

حدد عدم تناظر الأدلة سقف العميل

كشفت ستورم-0558 أيضاً عن سقف صارم للتحقيق من جانب العميل. يمكن للعميل فحص أحداث تدقيق علب البريد، وربط الوصول المشبوه، والحفاظ على سجلات المستأجرين، والتصعيد إلى مايكروسوفت. لا يمكنه فحص بيئة التوقيع، أو سرد كل قرار ثقة بمفتاح داخلي في مايكروسوفت، أو إثبات ما إذا كان المفتاح قد استخدم ضد خدمات أخرى، أو تحديد ما إذا كانت الجهة الفاعلة قد حصلت على المفتاح من خلال تفريغ ذاكرة، أو اختراق شركة، أو مسار آخر. كانت أهم الأدلة داخل المزود.

عدم التناظر هذا متأصل في الخدمات السحابية، لكنه يصبح حاداً عندما يتضمن الفشل البنية التحتية لهوية المزود. في اختراق حساب عادي، قد يكون العميل قادراً على مراجعة أجهزة المستخدم، ورسائل التصيد، ومطالبات MFA، وسياسات الوصول المشروط، والسجلات المحلية. في ستورم-0558، كان السؤال الحاسم هو لماذا قبلت خدمات مايكروسوفت الرموز المميزة المزورة وكيف حصلت الجهة الفاعلة على مادة التوقيع التي تتحكم بها مايكروسوفت. كان هذا السؤال خارج نطاق العميل.

وبالتالي يزداد واجب أدلة المزود مع تناقص رؤية العميل. كان على مايكروسوفت التحقيق في الأنظمة الداخلية، والحفاظ على الأدلة المتاحة، وشرح الفجوات، وتصحيح الادعاءات العامة، وجعل السجلات الموجهة للعملاء أكثر سهولة. كان على العملاء الثقة بمايكروسوفت للحصول على النصف الداخلي من القصة. قللت مراجعة CSRB فجوة الثقة هذه من خلال جلب تدقيق عام مستقل للحقائق التي يحتفظ بها المزود، لكنها لم تقض على كل مجهول. يمكنها الإبلاغ عما استطاعت مايكروسوفت والمشاركون الآخرون إعادة بنائه؛ لا يمكنها صنع سجلات لم تكن موجودة.

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

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

تدوير المفاتيح في حالات الطوارئ هو قدرة استمرارية

غالباً ما تتم مناقشة تدوير المفاتيح كمهمة صيانة تشفيرية. أظهرت ستورم-0558 أنها أيضاً قدرة استمرارية. إذا كان مفتاح التوقيع مشتبهاً أو مؤكداً اختراقه، يجب على المزود تدويره أو إبطاله دون كسر المصادقة الشرعية على نطاق غير مقبول. وهذا يعني أن التطبيقات والخدمات ونقاط نهاية البيانات الوصفية والذاكرة المخبأة والعملاء ومكتبات التحقق يجب أن تتحمل تغيير المفتاح. إذا كان مسار التدوير هشاً، فقد تتردد فرق الأمان أو تؤخر أو تترك المفاتيح القديمة موثوقة لفترة أطول مما ينبغي.

مناقشة CSRB لتدوير مفتاح توقيع المستهلك تجعل هذه النقطة ملموسة. أوقفت مايكروسوفت التدوير اليدوي بعد مخاوف انقطاع ولم تكمل الاستبدال الآلي. ربما يكون هذا القرار قد قلل من مخاطر التوفر الفورية، لكنه ترك مفتاحاً قديماً موثوقاً. لم يكن الفشل الأعمق ببساطة هو عمر المفتاح. كان غياب مسار تدوير آمن وآلي وقابل للقياس يمكنه التعامل مع التغيير الروتيني والطوارئ.

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

للتدوير في حالات الطوارئ أيضاً عنصر تواصل مع العملاء. عندما يدور المزود المفاتيح بعد اختراق مشتبه، قد يحتاج العملاء إلى معرفة ما إذا كانت تطبيقاتهم أو تكاملاتهم تتطلب إجراءً، وما إذا كانت ذاكرة الرموز المميزة المخبأة متأثرة، وما إذا كانت إخفاقات المصادقة متوقعة، وما إذا كانت الرموز المميزة القديمة لا تزال صالحة. خلال ستورم-0558، سيطرت مايكروسوفت على مسار Exchange Online المتأثر، لكن المبدأ الأوسع ينطبق عبر هوية السحابة. سلامة المفاتيح واستمرارية العملاء مرتبطان.

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

غيرت السجلات الأساسية من يدفع ثمن عدم اليقين

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

كان لدى وزارة الخارجية السجلات المعززة اللازمة لاكتشاف الوصول الشاذ إلى علب البريد. أظهر هذا النجاح ما يمكن أن تفعله القياسات الجيدة. كما أثار سؤال العدالة: لماذا يجب أن تعتمد القدرة على اكتشاف فشل هوية من أصل المزود على مستوى الترخيص؟ حول بيان CISA العام بأن السجلات الهامة يجب أن تكون متاحة دون تكلفة إضافية قرار منتج إلى قضية مساءلة.

لذلك لم يكن التزام مايكروسوفت بتوسيع أحداث Audit Standard والاحتفاظ بها مجرد بادرة نجاح للعملاء. لقد غير نموذج تخصيص الضرر. إذا تلقى العملاء الأساسيون المزيد من السجلات، يمكنهم المشاركة في الكشف وتحديد النطاق عندما تفشل ضوابط المزود. إذا تلقت الوكالات الفيدرالية تمكيناً تلقائياً واحتفاظاً أطول، فإنها أقل اعتماداً على إعادة البناء بعد فوات الأوان. المزيد من السجلات لا تمنع اختراق المفتاح. إنها تقلل الفترة التي يكون فيها العملاء عمياناً.

تؤثر السجلات أيضاً على اليقين القانوني والتشغيلي. يمكن لمنظمة يمكنها إثبات عناصر البريد التي تم الوصول إليها تخصيص الإخطار، والمعالجة الداخلية، والاستجابة الدبلوماسية، أو إجراءات استمرارية الأعمال. قد تضطر منظمة بدون سجلات إلى معاملة مجموعة أوسع على أنها متأثرة محتملة. بهذا المعنى، تقلل السجلات الضرر الثانوي. لا تساعد فقط في العثور على المهاجمين؛ إنها تساعد في تجنب عدم اليقين الواسع المفرط.

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

تصحيحات المزود هي جزء من الاستجابة للحوادث

جعلت ستورم-0558 أيضاً التصحيح العام جزءاً من المساءلة التشغيلية. نشرت مايكروسوفت إشعاراً أولياً بالحادثة، وتحليلاً تقنياً، ثم منشور تحقيق حول الحصول على المفتاح. قدم منشور سبتمبر تفسيراً مفصلاً كان لا بد من تضييقه لاحقاً. لم يقم تصحيح مارس 2024 بمجرد تعديل حاشية تاريخية. لقد غير ما يمكن للعملاء تصديقه بمسؤولية عن السبب الجذري.

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

لذلك يجب أن تكون التصحيحات سريعة ومرئية وصريحة. لا ينبغي للمزود دفن مستوى ثقة متغير للسبب الجذري في منشور مؤرخ دون ذكر ما تغير ولماذا بوضوح. أضافت مايكروسوفت بالفعل تحديث مارس 2024، وناقش CSRB لاحقاً توقيت وأهمية التصحيح. درس المساءلة هو أن الثقة في السبب الجذري هي بحد ذاتها حقيقة معلنة. عندما تنخفض الثقة من "حدث هذا" إلى "هذه تظل فرضيتنا الرئيسية"، يحتاج العملاء إلى المعرفة.

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

تحتاج المسؤولية المشتركة إلى خريطة سطح السيطرة

ستورم-0558 هو ترياق مفيد للغة المسؤولية المشتركة الغامضة. يمكن أن تصبح عبارة "المسؤولية المشتركة" ضباباً إذا لم تسمِ أسطح السيطرة. في هذه الحادثة، سيطرت مايكروسوفت على دورة حياة المفتاح، والتحقق من الرمز المميز، والتخفيف من جانب الخدمة، وتوفر السجلات الأساسية، وحفظ الأدلة الداخلية، ومعظم إثبات السبب الجذري. سيطر العملاء على مراقبة المستأجرين، وتصعيد الحوادث، ومراجعة علب البريد، ونظافة الحساب، وتكوين السياسة. سيطرت الحكومات على ضغط الشراء، والرقابة، وآليات المراجعة العامة. هذه الأدوار مختلفة.

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

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

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

للوكالات العامة واجب إضافي لأن اعتمادها يمكن أن يشكل معايير السوق. عندما تصر الحكومة العملاء على أن تكون السجلات الحرجة أساسية، قد يغير المزودون العروض لشرائح أوسع. يُظهر توسيع السجلات بعد ستورم-0558 أن المساءلة العامة يمكن أن تحسن وضع الأمان الافتراضي. التحدي هو جعل هذا التحسين منهجياً بدلاً من أن يكون مدفوعاً بالحوادث.

اختبار المساءلة

جعلت مايكروسوفت ستورم-0558 السيطرة التشغيلية على ضرر الرموز المميزة اختباراً للمساءلة العامة لأن الضوابط الحاسمة كانت داخل سحابة مايكروسوفت. يمكن للعملاء الكشف والتصعيد والتحقيق في علب بريدهم الخاصة، لكن مايكروسوفت وحدها يمكنها استبدال المفتاح، وتصحيح التحقق، وتغيير سلوك تجديد الرموز المميزة، وتوسيع السجلات الأساسية، وشرح فجوة الأدلة الداخلية.

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

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