Microsoft Storm-0558 جعلت السيطرة التشغيلية على ضرر الرموز اختبارًا عامًا للمساءلة

الملخص

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

خريطة الأدلة

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

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

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

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

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

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

قصة الحصول على المفتاح ظلت غير محلولة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

أصبحت ثقافة الأمان تحكمًا تشغيليًا

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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