ملخص

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

الهوية أصبحت طبقة التحكم السحابية

Azure Active Directory، الآن جزء من Microsoft Entra ID، ليس مجرد شاشة تسجيل دخول. إنه طبقة تحكم للوصول إلى البريد الإلكتروني والتعاون ومستندات Office والإدارة وإدارة الأجهزة وتطبيقات SaaS وأدوات الأمان وأتمتة سير العمل والتكامل مع الشركاء. عندما تفشل طبقة الهوية، قد لا يرى المستخدم المتأثر مشكلة "منصة هوية". يرى المستخدم Outlook أو Teams أو SharePoint أو Office.com أو بوابة Azure أو تطبيقات الأعمال أو سير عمل SaaS متكامل لا يمكن الوصول إليه. التبعية مجردة للمستخدم وملموسة للمؤسسة.

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

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

نقطة دخول سجل حالة Azure الحالية لـ Microsoft علىhttps://status.azure.com/en-us/status/history/وإرشادات صحة خدمة Microsoft 365 علىhttps://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health?view=o365-worldwideتُظهر القنوات العامة الموجهة للمسؤولين التي يُفترض من خلالها تصنيف حوادث الخدمة. نظرة عامة على واجهة برمجة تطبيقات اتصالات Microsoft 365 علىhttps://learn.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-service-communications-api-overview?view=o365-worldwideتُظهر مسارًا أكثر آلية لبيانات الصحة ومركز الرسائل. لا تثبت هذه المصادر بمفردها كل تفاصيل سبتمبر 2020. تُظهر أن أدلة صحة الخدمة جزء من نموذج التشغيل لعملاء السحابة من Microsoft.

يتم تعريف سطح الهوية أيضًا في وثائق Microsoft الحالية. أساسيات Microsoft Entra ID علىhttps://learn.microsoft.com/en-us/entra/fundamentals/whatisتصف منصة الهوية. وثائق المصادقة علىhttps://learn.microsoft.com/en-us/entra/identity/authentication/overview-authenticationوثائق المصادقة متعددة العوامل علىhttps://learn.microsoft.com/en-us/entra/identity/authentication/concept-mfa-howitworksتصف ضوابط الهوية المواجهة للعميل. إرشادات المراقبة والصحة علىhttps://learn.microsoft.com/en-us/entra/identity/monitoring-health/overview-monitoring-healthتمنح العملاء مفردات لمراقبة حالة الهوية. هذه الوثائق هي سياق المنتج الحالي، وليس تحليلًا بعد وقوع الحادث. لا تزال ضرورية لأنها تشرح لماذا يعد انقطاع المصادقة حدثًا في طبقة التحكم.

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

سجل الحالة ليس مثل استعادة الوصول

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

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

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

مواد مرونة الهوية من Microsoft ذات صلة لأنها تمنح العملاء مفردات لهذا التمييز. نظرة عامة على المرونة علىhttps://learn.microsoft.com/en-us/entra/architecture/resilience-overviewوإرشادات مرونة بيانات الاعتماد علىhttps://learn.microsoft.com/en-us/entra/architecture/resilience-in-credentialsتناقش كيفية تصميم أنظمة الهوية لتحقيق التوفر والتعافي. إرشادات Microsoft حول مرونة التطبيقات والهوية علىhttps://learn.microsoft.com/en-us/entra/architecture/resilience-with-microsoft-entra-idتعطي مدخلاً آخر لتصميم الاستمرارية. لا تؤكد هذه المصادر ما حدث في سبتمبر 2020. تُظهر أن مرونة الهوية هي تحكم مصمم، وليست مجرد أمل في نجاح تسجيل الدخول.

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

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

سلامة النشر يجب أن تشمل إثبات التراجع

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

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

تساعد وثائق الموثوقية والهندسة المعمارية الأوسع لـ Microsoft في تأطير المعيار. إرشادات الموثوقية من Azure علىhttps://learn.microsoft.com/en-us/azure/reliability/وركيزة الموثوقية لـ Azure Well-Architected علىhttps://learn.microsoft.com/en-us/azure/well-architected/reliability/تعامل الموثوقية كتصميم ومراقبة واستجابة للفشل وتحسين مستمر. مواد مرونة مركز بنية Azure علىhttps://learn.microsoft.com/en-us/azure/architecture/framework/resiliency/overviewتعطي لغة عامة للمرونة وتخطيط أوضاع الفشل. هذه مراجع حالية واسعة، وليست تحليلًا محددًا لسبتمبر 2020. النقطة ذات الصلة هي أن سلامة النشر وإثبات التراجع ينتميان داخل الموثوقية، وليس خارجها.

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

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

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

رؤية المسؤولين يمكن أن تفشل مع نفس تبعية الهوية

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

لذلك فإن إرشادات صحة الخدمة من Microsoft هي مصدر للمساءلة. وثائق صحة الخدمة علىhttps://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health?view=o365-worldwideتشرح كيف يطلع المسؤولون على الحوادث والإشعارات. واجهة برمجة تطبيقات اتصالات الخدمة علىhttps://learn.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-service-communications-api-overview?view=o365-worldwideتمنح المؤسسات طريقة لدمج اتصالات الخدمة في أنظمتها الخاصة. قيمة واجهة برمجة التطبيقات ليست مجرد راحة. إذا كان بإمكان سير عمل الحوادث لدى العميل استيعاب رسائل صحة المزود في قناة لا تعتمد على مسار البوابة المتأثر، فلديه رؤية أكثر مرونة.

يجب أن تشمل رؤية العميل أيضًا مراقبة محلية. مواد مراقبة صحة Microsoft Entra علىhttps://learn.microsoft.com/en-us/entra/identity/monitoring-health/overview-monitoring-healthومفاهيم تقارير تسجيل الدخول في وثائق Microsoft تساعد العملاء على رؤية أحداث الهوية داخل المستأجر. لكن سجلات المستأجر مفيدة فقط إذا بقيت قابلة للوصول ومحفوظة ومفهومة. أثناء حادث واسع النطاق للمزود، قد تظهر السجلات المحلية أعراضًا قبل أن تصبح صفحة حالة المزود محددة بما يكفي. بعد التعافي، تساعد السجلات المحلية في إثبات أي المستخدمين والتطبيقات تأثروا. بدون أدلة محلية، قد يكون لدى المؤسسة حكايات فقط ورسالة حالة عامة.

الوصول في حالات الطوارئ هو تحكم ذو صلة. إرشادات الوصول الطارئ من Microsoft علىhttps://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-accessتوصي بالحفاظ على حسابات وصول طارئ للعمليات المميزة. هذه الإرشادات ليست نتيجة حول سبتمبر 2020. إنها ذات صلة لأن حوادث الهوية تختبر ما إذا كان الوصول الطارئ تحكمًا موثقًا ومراقبًا وممارسًا. حساب طوارئ لم يختبره أحد، أو تم حظره بنفس فشل الوصول الشرطي، أو غير متاح لقائد الحادث ليس تحكمًا موثوقًا.

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

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

يجب أن تكون الحلول البديلة حقيقية تحت هوية متضررة

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

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

توفر مواد الثقة وعلاقة الخدمة من Microsoft السياق التعاقدي والضماني لهذه الأسئلة. مركز الثقة من Microsoft علىhttps://www.microsoft.com/en-us/trust-centerيعطي نقطة دخول عامة لمواد الأمان والخصوصية والامتثال والثقة. صفحة اتفاقية عملاء Microsoft علىhttps://www.microsoft.com/licensing/docs/customeragreementتعطي سياق العلاقة للخدمات السحابية. لا تقرر هذه المصادر أي تعويض عن حادث 2020. تذكر المشترين أن تبعية الخدمة تُحكم من خلال مزيج من أدلة الحالة العامة وشروط العقد ومواد الضمان وهندسة العميل وخطط الاستمرارية المحلية.

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

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

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

يجب أن يحافظ الإبلاغ العام على عدم اليقين

الإبلاغ العام المعاصر مفيد لكن له حدود. وصفت التقارير الإعلامية مشاكل واسعة في مصادقة Microsoft 365 وAzure Active Directory، بما في ذلك التأثير على خدمات مثل Outlook وTeams وOffice.com والوصول الإداري. على سبيل المثال، أبلغ BleepingComputer عن مشاكل مصادقة Microsoft 365 علىhttps://www.bleepingcomputer.com/news/microsoft/microsoft-365-outage-causes-authentication-issues-globally/وأبلغ The Verge عن انقطاع خدمة Microsoft 365 علىhttps://www.theverge.com/2020/9/28/21492361/microsoft-365-office-outage-down-outlook-teams. هذه التقارير هي أدلة مفيدة على التأثير العام والرسائل العامة. لكنها ليست بديلاً عن سجلات Microsoft الداخلية أو تليمترية خاصة بعميل.

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

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

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

يمكن للأطر الخارجية المساعدة في الحفاظ على انضباط المراجعة. إطار عمل الأمن السيبراني من NIST علىhttps://www.nist.gov/cyberframeworkيعطي مفردات عامة للحوكمة والتحديد والحماية والكشف والاستجابة والتعافي. إرشادات تخطيط الطوارئ من NIST علىhttps://csrc.nist.gov/pubs/sp/800/34/r1/finalتعطي دورة حياة لتخطيط الطوارئ والاختبار. NIST SP 800-53 علىhttps://csrc.nist.gov/pubs/sp/800/53/r5/upd1/finalتعطي عائلات تحكم للتحكم في الوصول، وتخطيط الطوارئ، والتدقيق، والاستجابة للحوادث، وإدارة التكوين. هذه المصادر ليست نتائج حوادث Microsoft. تمنح العملاء طريقة لتحويل انقطاع هوية سحابية إلى مراجعة تحكم قابلة للتدقيق.

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

أدلة المستأجر يجب أن تفصل بين فشل تسجيل الدخول والجلسة والتطبيق

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

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

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

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

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

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

يجب أن تحدد المشتريات تركيز الهوية بشكل صريح

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

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

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

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

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

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

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

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

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

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

ملف أدلة القارئ

تستخدم هذه المقالة المصادر العامة التالية كملف أدلة لانقطاع مصادقة Azure Active Directory في سبتمبر 2020، وتبعية Microsoft 365، وتواصل الحالة، ومرونة الهوية، ورؤية المسؤولين، وتصميم التراجع للعملاء، واستمرارية المؤسسات والقطاع العام. تُعامل المصادر التي كتبتها Microsoft كوثائق مزود وسياق صحة الخدمة. تُعامل المصادر الإعلامية كتقارير عامة عن الحادث، وليس كأدلة جنائية كاملة.

أسئلة مراجعة مجلس الإدارة

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

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

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