انقطاع Cloudflare يوليو 2020 ومسؤولية نشر قواعد التوجيه

ملخص

نشرت Cloudflare تقرير ما بعد الحادث العام لـ 17 يوليو 2020 وصف تغييرًا في التكوين الشبكي في أتلانتا، ونافذة انقطاع رئيسي لمدة 27 دقيقة، وفقدان حوالي نصف حركة المرور في الذروة، وتأثير عالمي على العملاء جعل التحكم الداخلي في حركة المرور مشكلة توفر للعملاء.
سؤال المسؤولية هو: من كان يتحكم في اختبارات قواعد أجهزة التوجيه، والنشر التدريجي، وتفضيل المسار، وضوابط الحد الأقصى للبادئة، وسلوك التبديل الاحتياطي للعمود الفقري، واتصال حالة العميل، وسرعة التراجع، والدليل على أن أمان النشر تغير بعد الحادث.
هذه ليست حالة انقطاع سحابي عام. إنها حالة مرونة شبكية لأن خدمات حافة Cloudflare و DNS والأمان وتوصيل التطبيقات وتوجيه حركة المرور هي جزء من سلسلة الخدمات العامة و استمرارية الأعمال للمنظمات الأخرى.
تتعامل هذه المقالة مع تقرير Cloudflare اللاحق للحدث كسجل حادث من الطرف الأول وتستخدم BGP والمرونة و SRE و NIST و CISA ومصادر الحالة كسياق، وليس كدليل على جهاز توجيه خاص.
الدرس الدائم هو أن التغيير الشبكي التدريجي يجب أن يتم إثباته، وليس فقط الوعد به: يجب على المزود أن يوضح كيف يتم اختبار نشر قاعدة جهاز توجيه، وتحديده، ومراقبته، وإلغاؤه، ومنعه من التحول إلى انقطاع عميل مشترك.

لماذا تنتمي هذه الحالة إلى ملف المخاطر والمسؤولية

جعلت Cloudflare من نشر قواعد أجهزة التوجيه اختبارًا للمسؤولية في مجال مرونة الشبكة لأن حادث 17 يوليو 2020 كشف سمة أساسية للاعتماد الحديث على السحابة: قرار حركة المرور الداخلي لمزود ما يمكن أن يصبح حدث توفر عام للعملاء الذين لم يروا التغيير أبدًا. أشار تقرير الحادث من Cloudflare علىhttps://blog.cloudflare.com/cloudflare-outage-on-july-17-2020/إلى أن تغييرًا في التكوين في أتلانتا تسبب في تعتيم حركة المرور الأساسية، مع استمرار الحادث الرئيسي من 21:12 UTC إلى 21:39 UTC وتأثير كبير على جزء كبير من حركة المرور. يوفر هذا السجل العام عمودًا فقريًا واقعيًا واضحًا بما يكفي لطرح أسئلة المسؤولية دون اختراع سجلات جهاز توجيه خاصة.

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

صفحة حالة Cloudflare علىhttps://www.cloudflarestatus.com/وتاريخ الحالة علىhttps://www.cloudflarestatus.com/history/مهمان لأن الاتصال العام يصبح جزءًا من التحكم في الحوادث. أثناء انقطاع المزود، يحتاج العملاء إلى تحديد ما إذا كان مصدرهم الخاص معطلاً، أو أن DNS متورط، أو أن عناصر التحكم الأمنية تمنع حركة المرور، أو وجود مسارات بديلة، أو أنه يجب دعوة المستخدمين للانتظار. صفحة الحالة ليست مجرد قطعة أثرية اتصالية. إنها إشارة تشغيلية تشكل الفرز النهائي.

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

مركز تعلم BGP من Cloudflare علىhttps://www.cloudflare.com/learning/security/glossary/what-is-bgp/و RFC 4271 علىhttps://www.rfc-editor.org/rfc/rfc4271.htmlو NIST SP 800-189 علىhttps://csrc.nist.gov/pubs/sp/800/189/finalمفيدة لأنها تؤطر التوجيه بين النطاقات وتبادل حركة المرور المرن. إنها ليست استنتاجات حول أجهزة التوجيه في يوليو 2020. إنها تساعد القراء على فهم لماذا التفضيلات المحلية وإعلانات المسار وتوجيه حركة المرور و backbones المزود هي أسطح تحكم بدلاً من سباكة مجردة.

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

فشل قاعدة جهاز التوجيه يتحول إلى انقطاع عميل عندما تكون الحافة بنية تحتية مشتركة

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

توثيق خدمة Cloudflare علىhttps://developers.cloudflare.com/fundamentals/وhttps://developers.cloudflare.com/dns/يوضح مدى واسع يمكن أن يكون سطح تحكم العميل. توثيق Workers علىhttps://developers.cloudflare.com/workers/ومعلومات الترابط الشبكي علىhttps://www.cloudflare.com/network-interconnect/تظهر أن Cloudflare ليست مجرد مخبأ لموقع ويب. إنها منصة حافة، وبيئة تشغيل مطور، وكيان عند نقاط الترابط. هذه الصفحات ليست دليلًا على حادث. إنها تشرح لماذا يعتمد العملاء بشكل معقول على إدارة التغيير الشبكي الداخلي لـ Cloudflare.

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

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

مواد SRE من Google حول معالجة الحمل الزائد علىhttps://sre.google/sre-book/handling-overload/و إدارة الحالة الحرجة علىhttps://sre.google/sre-book/managing-critical-state/هي سياق مفيد لأنها تؤطر كيف تفشل الأنظمة الموزعة تحت الحمل والتغذية الراجعة ومشكلات إدارة الحالة. حادث Cloudflare كان حدث تحكم شبكي، وليس حالة Google SRE. لكن مفردات SRE تساعد في طرح الأسئلة الصحيحة: ما الإشارة التي كانت مراقبة؟ ما العتبة التي كانت مهمة؟ ما الاستجابة الآلية التي كانت موجودة؟ ما القرار البشري الذي كان مطلوبًا؟ وكيف تم التحقق من الإصلاح؟

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

النشر التدريجي هو ضابط مسؤولية، وليس مجرد راحة تقنية

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

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

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

NIST SP 800-34 Rev. 1 علىhttps://csrc.nist.gov/pubs/sp/800/34/r1/finalو NIST SP 800-160 Vol. 2 Rev. 1 علىhttps://csrc.nist.gov/pubs/sp/800/160/v2/r1/finalمفيدة هنا لأنها تحدد تخطيط الاستمرارية ومفاهيم المرونة السيبرانية. هذه ليست أدلة أجهزة توجيه. إنها تساعد في ترجمة الهندسة الشبكية إلى واجبات مرنة: التوقع، المقاومة، الاسترداد، التكيف، والتحقق. يجب أن يظهر تقرير ما بعد الحادث من المزود ليس فقط استرداد حادث، ولكن أيضًا تكييف نظام النشر الذي مكّن الحادث.

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

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

سرعة التراجع لا تكون مرئية إلا عندما يكون التسلسل الزمني دقيقًا

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

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

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

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

استمرارية القطاع العام تزيد من المخاطر. مواد مرونة البنية التحتية الحرجة من CISA علىhttps://www.cisa.gov/resources-tools/resources/critical-infrastructure-resilienceمفيدة لأن العديد من الخدمات العامة والحرجة تعتمد على توفر الويب و DNS وتصفية الأمان. انقطاع المزود يمكن أن يؤثر على المعلومات المدنية، والبوابات العامة، والاتصالات المجاورة للطوارئ، والخدمات الأساسية عبر الإنترنت حتى عندما لا يكون المزود نفسه وكالة عامة. هذا لا يعني أن كل عميل لـ Cloudflare كان بنية تحتية حرجة. إنه يعني أن عملية التحكم للمزود يجب أن تكون قوية بما يكفي للعملاء الذين هم حرجون.

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

الترابط والعبور وتصميم العمود الفقري هي جزء من ثقة العميل

حادث Cloudflare يوليو 2020 يقع على الحدود بين هندسة العمود الفقري الداخلي والنظام البيئي الأوسع للإنترنت. نادرًا ما يفحص العملاء تفاصيل الترابط والعبور، لكن هذه التفاصيل تشكل قابلية الوصول. PeeringDB علىhttps://www.peeringdb.com/يعطي سياقًا عامًا للنظام البيئي للترابط. RIPE RIS علىhttps://ris.ripe.net/و RouteViews علىhttps://www.routeviews.org/routeviews/يظهران أن مراقبة عامة للتوجيه موجودة، حتى لو لم تكشف كل قرار خاص للمزود. إجراءات مشغلي MANRS علىhttps://manrs.org/netops/actions/و RFC 7908 علىhttps://www.rfc-editor.org/rfc/rfc7908.htmlتوفر مفردات لتسريب المسار وأمان التوجيه ذات صلة بالأحداث المجاورة.

لا ينبغي الخلط بين حادث يوليو 2020 وتسريب المسار في يونيو 2019 الذي حللته Cloudflare علىhttps://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/. في 2019، كانت Cloudflare مزودًا متأثرًا يشرح تسريب مسار يتضمن شبكات أخرى. في 2020، وصف تقرير Cloudflare الخاص مشكلة تكوين شبكي داخلي. التمييز مهم لأن خريطة المسؤولية تختلف. لتسريب مسار، قد يشمل الإصلاح التحقق من الأصل، التصفية، مسؤولية مزود العبور، ومعايير النظام البيئي. لانقطاع قاعدة جهاز توجيه داخلي، يركز الإصلاح بشكل مباشر أكثر على إدارة تغيير المزود، والاختبار، والتفضيل المحلي، وحواجز الحد الأقصى للبادئة، ونصف قطر انفجار التحكم في حركة المرور.

نشرت Cloudflare مستندات حول RPKI وأمان التوجيه، مثلhttps://blog.cloudflare.com/rpki/وhttps://blog.cloudflare.com/rpki-updates-data/. تظهر هذه المصادر الدعوة العامة لـ Cloudflare ومفرداتها التقنية حول أمان المسار. إنها لا تثبت تلقائياً إصلاح يوليو 2020. إنها تساعد القراء على فهم لماذا يجب تقييم مزود يشارك بعمق في أمان التوجيه من خلال كل من الانضباط القابل للتحقق للتغييرات الشبكية والتعليم العام.

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

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

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

استمرارية العميل تعتمد على إثبات المزود، وليس على ثقة المزود

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

نموذج 10-K 2020 لـ Cloudflare علىhttps://www.sec.gov/Archives/edgar/data/1477333/000147733321000023/net-20201231.htmيوفر سياق مخاطر الأعمال للشركة، بينما وثائق الثقة والامتثال لـ Cloudflare علىhttps://www.cloudflare.com/trust-hub/يوفر سياق ضمان حالي. إيداعات المستثمرين وصفحات الثقة ليست دليلاً على إصلاح الحادث. إنها تظهر أن التوفر والأمان وثقة العميل مادية لنموذج الأعمال. هذا يجعل المسؤولية التفصيلية للحوادث عقلانية تجاريًا، وليس فقط مرغوبة أخلاقيًا.

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

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

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

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

الأدلة السلبية جزء من تقرير شبكي مفيد بعد الحادث

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

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

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

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

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

يجب أن تتضمن دفاتر تشغيل العميل قرارات انقطاع حافة المزود

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

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

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

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

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

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

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

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

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

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

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

الدرس الدائم هو جعل أمان تغيير الشبكة قابلًا للملاحظة

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

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

المستندات الأوسع من Cloudflare حول التوجيه والموثوقية، بما في ذلكhttps://www.cloudflare.com/learning/security/glossary/what-is-bgp/وhttps://blog.cloudflare.com/rpki/وhttps://blog.cloudflare.com/rpki-updates-data/تظهر أن الشركة تفهم التوجيه العام كمجال مسؤولية. حالة يوليو 2020 تطبق نفس المعيار داخليًا. الدعوة للتوجيه العام تكون أقوى عندما تكون ضوابط التغيير الشبكي الداخلي قابلة للتحقق أيضًا. لا يشعر العملاء بالتمييز بين الأسباب بين النطاقات وداخل النطاقات بوضوح كما يشعر المهندسون. إنهم يشعرون بقابلية الوصول.

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

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

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