الملخص

  • يعتبر انقطاع مصادقة 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.

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

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

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

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

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

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

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

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

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

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

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

يجب أن يشمل أمان النشر دليلًا على التراجع

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

توفر وثائق الثقة وعلاقة الخدمة من Microsoft السياق التعاقدي والتأكيدي لهذه الأسئلة. يقدم مركز الثقة Microsoft علىhttps://www.microsoft.com/fr-fr/trust-centerنقطة دخول عامة لوثائق الأمان والخصوصية والامتثال والثقة. توفر صفحة اتفاقية عملاء Microsoft علىhttps://www.microsoft.com/fr-fr/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 Identity لحسابات الخدمة أو الأذونات المفوضة أو الموصلات أو واجهات برمجة التطبيقات الإدارية، فقد ينشئ الانقطاع تراكمًا صامتًا. قد يشكو المستخدمون البشريون بسرعة. قد تفشل المهام الآلية بصمت، أو تعيد المحاولة، أو تكرر العمل، أو تنتظر رمزًا. يجب أن تفحص مراجعة ما بعد الحادث سجلات الأتمتة وليس فقط تذاكر تسجيل دخول المستخدمين. الهوية ليست فقط طبقة وصول للموظفين؛ إنها اعتماد سير عمل من آلة إلى آلة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

أسئلة للمجلس

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

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

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