ملخص
- في 12 نوفمبر 2018، تم تسريب مسارات مرتبطة بخدمات Google من قبل مزود الإنترنت النيجيري MainOne إلى China Telecom ثم تم نشرها عبر مزودين آخرين، مما أرسل بعض حركة مرور Google عبر مسارات غير متوقعة وجعل الخدمات غير قابلة للوصول لبعض المستخدمين.
- تختلف الحادثة عن اختطاف YouTube من قبل Pakistan Telecom في 2008. هنا كانت مشكلة المساءلة الحرجة ليست حظرًا وطنيًا تم تصديره كمسار أكثر تحديدًا من أصل خاطئ؛ بل كانت عدم تطابق بين العقد والتحكم حيث هربت المسارات التي تم تعلمها من خلال علاقة واحدة إلى علاقات أخرى.
- السجل العام يدعم سوء التكوين العرضي بدلاً من دليل على اختراق ناجح للمحتوى. ذكرت Google أن حركة المرور المتأثرة كانت مشفرة وليس لديها سبب للاعتقاد بأن الخدمات قد تم اختراقها، بينما اعتبر المراقبون المستقلون مسار التوجيه خطرًا جديًا على التوفر والمراقبة.
- التحقق من صحة أصل RPKI ليس حلاً كاملاً لهذه الفئة من الفشل لأن المسارات المتأثرة لا يزال بإمكانها الظهور كأنها من أصل Google الشرعي. تتطلب تسريبات المسارات تصفية العملاء والنظراء، وضوابط واعية بالعلاقة، وحدود البادئات، والمراقبة، والتنسيق، وآليات لاحقة مثل BGP Roles.
- الدرس في المساءلة هو أن عقود التبادل التجاري والنقل لا تفرض نفسها. يجب على المشغلين تحويل العلاقات التجارية إلى سياسات توجيه وضوابط قابلة للتحقق خارجيًا قبل أن يصبح المسار المسرب انقطاعًا عالميًا.
سجل الأدلة وكيفية استخدامه
تتعامل هذه المقالة مع السجل العام كأدلة متعددة الطبقات. تُستخدم تقارير الحوادث والمعايير وقياسات المتصفح أو التوجيه والمواد التنظيمية أو السياسية وإرشادات المشغل الحالية لمطالبات مختلفة. تُنسب المصادر التي أعدتها الشركات كمواقف للشركة. تُستخدم المعايير والتوجيهات اللاحقة لشرح الضوابط وعرض توقعات المساءلة، وليس لاختراع حقائق خاصة أو فرض التزامات لاحقة بأثر رجعي حيث لا يدعم السجل العام هذا الادعاء.
| # | السجل العام | الاستخدام في هذا التحليل |
|---|---|---|
| 1 | تحليل Cloudflare | تحليل مشغل لبدء الحادثة في 21:12 UTC، سوء تكوين MainOne، آليات تسريب المسار، تأثيرها على وصول Google، وتأطير مسار التوجيه. |
| 2 | تحليل ThousandEyes | قياس مستقل لربط MainOne مع Google في IXPN، تسريب المسارات إلى China Telecom وانتشارها عبر TransTelecom وNTT، وتأثيرها على مسار المستخدم. |
| 3 | تحليل إنترنت سوساييتي | تفسير لأمن التوجيه بأن تصفية MainOne أو China Telecom كانت يمكن أن تمنع التسريب، وأن التحقق من صحة أصل RPKI وحده غير كافٍ للتسريبات ذات الأصل الشرعي. |
| 4 | تقرير Wired | حساب عام معاصر يميز المسارات المشبوهة من بيان Google بأن حركة المرور مشفرة ولا يوجد دليل على الاختراق. |
| 5 | تقرير Ars Technica | تغطية تقنية معاصرة لـ MainOne وChina Telecom والانتشار العالمي. |
| 6 | تقرير DataCenterDynamics | تقرير صناعي يستشهد بتصريحات الأطراف المعنية وتأطير سوء التكوين العرضي. |
| 7 | تقرير BankInfoSecurity | تقرير معاصر يحتفظ بتفاصيل BGPmon: AS37282 MainOne سرب بادئات Google إلى China Telecom واختفى المسارات لاحقًا. |
| 8 | تاريخ Kentik لحوادث BGP | ملخص تحليل شبكي لاحق لسياق تسريب المسار وتأكيد MainOne لسوء تكوين الموجه. |
| 9 | RFC 4271 | معيار BGP-4 للتوجيه بين AS، وإعلانات المسارات وسياق السياسة. |
| 10 | RFC 7908 | تصنيف تسريب المسارات المستخدم لتصنيف الانتشار خارج النطاق المقصود. |
| 11 | RFC 7454 | إرشادات عمليات BGP وأمنه لتصفية البادئات وتصفية مسار AS وسياسة الحدود. |
| 12 | RFC 8212 | سلوك رفض EBGP الافتراضي عندما لا توجد سياسة استيراد/تصدير صريحة. |
| 13 | RFC 6811 | معيار التحقق من صحة أصل RPKI المستخدم لشرح كيف يمكن للتسريبات ذات الأصل الصحيح تجنب عمليات التحقق من الأصل فقط. |
| 14 | RFC 9234 | معيار أدوار BGP وOnly-to-Customer لمنع تسريبات المسار اللاحقة. |
| 15 | إجراءات مشغلي شبكات MANRS | معايير الصناعة للتصفية ومكافحة الانتحال والتنسيق والتحقق العالمي. |
| 16 | NIST SP 800-189 | توجيه حكومي لتبادل حركة المرور بين النطاقات المرن وضوابط أمن BGP متعددة الطبقات. |
| 17 | التحقق من صحة أصل BGP من RIPE NCC | شرح تشغيلي لـ ROAs وحالات صالح/غير صالح/غير موجود وسياسة المشغل. |
| 18 | متابعة كشف تسريب المسار من Cloudflare | سياق مراقبة لاحق لكشف تسريبات المسار من البيانات العامة وبيانات المزود. |
| 19 | تحليل ThousandEyes لوصول China Telecom | تحليل لاحق يشير إلى انتشار China Telecom لتسريب Google 2018 وتأثير النقل الأوسع. |
| 20 | مذكرة تهديد CERT-EU | مذكرة تهديد من القطاع العام تشير إلى سوء توجيه Google في نوفمبر 2018 في سياق مخاطر توجيه China Telecom الأوسع. |
كانت الحادثة حول حدود لا يمكن لموجهات التوجيه استنتاجها
من السهل تسطيح تسريب مسار Google لعام 2018 في عبارة مألوفة: BGP هش. هذه العبارة صحيحة ولكنها ليست دقيقة بما يكفي. الدرس الأكثر وضوحًا هو أن الإنترنت يحتوي على العديد من العلاقات التجارية التي لا تستطيع برامج التوجيه استنتاجها ما لم يقم المشغلون بترميزها. قد يرسل النظير مسارات يجب أن تبقى محلية. قد يتلقى مزود النقل مسارات لا ينبغي أبدًا قبولها من ذلك الجار. قد يحتفظ المسار بـ AS الأصل الصحيح بينما لا يزال يسافر عبر مسار ينتهك التوقعات التجارية والتشغيلية.
تتقارب حسابات Cloudflare وThousandEyes وإنترنت سوساييتي حول الشكل الأساسي. كان لدى MainOne اتصال بـ Google من خلال علاقة نظير في لاغوس. هربت المسارات المرتبطة بـ Google من تلك العلاقة نحو China Telecom. نشرتها China Telecom إلى الأمام، وظهرت مسارات تشمل TransTelecom وNTT وشبكات أخرى. المستخدمون الذين حاولوا الوصول إلى خدمات Google اتبعوا بعد ذلك مسارات لم تكن لديها السعة أو السياسة أو التصفية المتوقعة لحمل تلك الحركة. تم إسقاط بعض الحركة وأصبحت الخدمات غير قابلة للوصول لبعض المستخدمين.
هذه ليست نفس آلية اختطاف YouTube من Pakistan Telecom. في عام 2008، قامت Pakistan Telecom بنشر مسار أكثر تحديدًا لمساحة عنوان YouTube من AS الأصل الخاطئ، وقامت PCCW بنشره. في عام 2018، تصف التحليلات العامة الهامة تسريب مسار حيث تم نشر مسارات من أصل Google خارج نطاق العلاقة المقصودة. يمكن أن يبدو الأصل شرعيًا بينما لا يزال المسار خاطئًا. هذا الاختلاف مهم لأنه يغير الضوابط التي كانت ستساعد. يمكن للتحقق من الأصل رفض أصل خاطئ. لا يمكنه بمفرده إثبات أن مسارًا ذا أصل صحيح قد عبر فقط علاقات تجارية صالحة.
عدم تطابق العقد والتحكم هو مركز مشكلة الحوكمة. قد ينص عقد النظير على أن الطرف يجب أن يتبادل فقط مسارات معينة أو لا يجب أن يوفر نقلًا. قد تحدد اتفاقية النقل نطاقات العملاء وقواعد التصدير. لكن الموجه البعيد سيعيد التوجيه بناءً على المسارات التي يتلقاها والسياسة التي تم تكوينه لتطبيقها. إذا كانت السياسة مفقودة أو قديمة أو متساهلة جدًا، يصبح الحد القانوني أو التجاري زخرفيًا. تتبع الحزمة مستوى التحكم، وليس ملف PDF للعقد.
لهذا ينتمي الحدث إلى الحوكمة. لم يكن الفشل كارثة طبيعية غامضة. كان عدم تطابق بين التكوين التقني والعلاقة التجارية وسلطة التوجيه والمراقبة والتصعيد. كل منظمة في المسار كانت لديها رؤية تشغيلية أضيق من التأثير العالمي. يمكن لـ MainOne تكوين التصدير بشكل خاطئ. يمكن لـ China Telecom القبول والنشر. يمكن لمزودين آخرين تفضيل المسارات أو تمريرها. يمكن لـ Google اكتشاف سرية طبقة الخدمة والتواصل بشأنها، لكنها لم تستطع إعادة كتابة كل سياسة استيراد خارجية مباشرة.
الأصل الصحيح لا يعني المسار الصحيح
تبدأ العديد من مناقشات أمن التوجيه بعمليات الاختطاف لأن الإعلانات ذات الأصل الخاطئ أسهل في الشرح. شخص لا يملك بادئة يقول، في الواقع، أرسل تلك الحركة إلي. تم بناء RPKI Route Origin Validation لمعالجة هذه الفئة: ينشر مالك المورد تفويض أصل المسار، ويمكن للشبكات التي تقوم بالتحقق رفض المسارات التي لا يتطابق فيها AS الأصل أو طول البادئة. هذا التحكم مهم. يُظهر حدث Google لعام 2018 حده.
أوضحت إنترنت سوساييتي النقطة بوضوح في تحليلها العام: في هذا السيناريو، كانت البادئات لا تزال تنشأ بشكل شرعي من AS الصحيح، لذلك من الصعب على الشبكات الوسطى حظر التسريب باستخدام التحقق من الأصل وحده. يمكن أن يكون للمسار أصل صحيح ولا يزال يمثل علاقة تصدير غير صالحة. لهذا السبب فإن تسريب المسار ليس مجرد اختطاف بلغة أكثر ليونة. إنه فشل في العلاقة: تنتشر المسارات خارج نطاقها المقصود.
يمكن أن يكون التأثير العملي شديدًا بنفس القدر للمستخدمين. المسار ذو الأصل الصحيح الذي يسافر عبر مزود خاطئ قد ينقل حركة المرور إلى شبكة ذات سعة غير كافية، أو تصفية مقيدة، أو مخاوف مراقبة، أو وصول ضعيف. يرى المستخدمون انتهاء المهلة. يرى العملاء خدمات سحابية معطلة. ترى فرق الحوادث تتبعات غريبة عبر دول ومزودين لم يتوقعوها. الأصل الصحيح لا يطمئنهم إذا كان المسار يسقط الحزم أو ينتهك افتراضات المخاطر الخاصة بهم.
يجب أن يغير هذا التمييز المشتريات والإشراف من مجالس الإدارة. السؤال عما إذا كان المزود لديه RPKI مفيد لكنه غير كامل. يجب على المشترين أيضًا أن يسألوا ما إذا كان المزود يقوم بتصفية مسارات العملاء، ويرفض المسارات غير المتسقة مع العلاقات التجارية، ويحافظ على حدود البادئات، ويراقب التسريبات، ويشارك في قنوات التنسيق، ويمكنه شرح كيف يتم الحفاظ على مسارات النظير من أن تصبح مسارات نقل. إجابة بنعم/لا حول تغطية RPKI لا يمكن أن تحل محل التحكم في المسار الواعي بالعلاقة.
تحاول الأعمال التقنية اللاحقة مثل أدوار BGP وخاصية Only-to-Customer جعل العلاقات التجارية مرئية لبروتوكول التوجيه. لم تكن تلك الآليات تحكمًا عالميًا مكتملاً في عام 2018، ولا تطبقها المقالة بأثر رجعي كمعيار إلزامي. أهميتها تفسيرية: فهي موجودة لأن المشغلين أدركوا أن العديد من التسريبات الضارة هي إخفاقات في سياسة المسار وليست إخفاقات في تفويض الأصل. احتاجت الصناعة إلى طرق لجعل عبارة "هذا المسار لا يجب أن يذهب بهذه الطريقة" قابلة للفحص آليًا.
كانت China Telecom مضخم الانتشار
تظهر MainOne في السجل العام كمصدر للتسريب، لكن الحدث أصبح مهمًا عالميًا لأن مزودين آخرين قبلوا ونشروا المسارات. China Telecom مركزية في الحسابات العامة لأنها تلقت مسارات Google المسربة ومررتها إلى الأمام. يجب وصف هذا الدور بحذر. تدعم المصادر العامة معالجة عرضية أو خاطئة للمسارات؛ لا تثبت عملية اعتراض حركة ناجحة. لكن النية ليست مطلوبة للمساءلة. يمكن لمزود النقل أن يسبب ضررًا كبيرًا من خلال الاعتقاد بأن مسار عميل أو نظير كان يجب أن يقوم بتصفيته.
مزود ذو نطاق عالمي لديه التزام عالي النفوذ بمعرفة المسارات التي يُصرح للجار بالإعلان عنها والمسارات التي يجب تصديرها. هذا لا يعني أن كل قرار مسار بسيط. نطاقات العملاء تتغير، والنظراء لديهم ترتيبات معقدة، وتبادل الإنترنت يحمل مسارات متنوعة، وبيانات السجل يمكن أن تكون فوضوية. لكن الواجب الأساسي يبقى: لا يجب على المزود الكبير معاملة كل مسار غير متوقع على أنه قابل للتصدير عالميًا لمجرد أن بناء جملة BGP صحيح.
يجب أن تتطابق التصفية أيضًا مع العلاقة. لا يجب أن يصبح مسار النظير مسار نقل إلا إذا كانت العلاقة تسمح بذلك صراحة. لا يجب أن يكون العميل قادرًا على الإعلان عن مسارات منصة سحابية ضخمة إلا إذا كان هذا العميل يوفر نقلًا شرعيًا لتلك المنصة. يجب على المزود تطبيق تصفية البادئات ومسارات AS، وحدود البادئات القصوى، وتوليد سياسة التوجيه من بيانات موثوقة، ومراقبة التغييرات المفاجئة في مجموعة المسارات الكبيرة، والتصعيد خارج النطاق للإعلانات الشاذة للبادئات الشهيرة.
جعلت الرؤية العامة لمسار التوجيه دور الانتشار صعب التجاهل. وصفت ThousandEyes مسارات عبر China Telecom وTransTelecom. سجلت Cloudflare توجيهًا غير عادي وتأثيرًا على الخدمة. ركزت التقارير الإخبارية على حركة المرور التي تمر عبر الصين وروسيا لأن هذا المسار يحمل مخاوف سياسية ومراقبة واضحة. حتى لو كانت حركة المرور مشفرة ولم تظهر أنها تعرضت للاختراق، فإن المسار نفسه قوض توقعات العملاء حول أين ستسافر حركة المرور وما إذا كانت ستبقى قابلة للوصول.
هذه هي النقطة السياسية: مزود يصدر مسارًا مسربًا يحول خطأ شبكة أخرى إلى حدث عالمي. سوء التكوين الأصلي مهم، لكن الانتشار يحدد نصف قطر الانفجار. يجب أن تقيس مساءلة التوجيه لذلك أول تصدير سيء وكل نقطة تضخيم رئيسية.
كان لدى Google واجبات مرونة لكن ليس سيطرة من جانب واحد
كانت Google مشغل الخدمة المتأثر وأحد الأطراف التي لديها أكبر قدرة على اكتشاف أن شيئًا غريبًا يحدث لحركة المرور المتجهة إلى Google. كما سيطرت على حماية طبقة التطبيق التي كانت مهمة. ذكرت التقارير العامة أن Google قالت إن حركة المرور المتأثرة كانت مشفرة ولا يوجد سبب للاعتقاد بأن الخدمات قد تعرضت للاختراق. هذا التمييز مهم. يمكن للتشفير تقليل مخاطر السرية حتى عندما يسلك التوجيه مسارًا سيئًا. لا يحل مشكلة التوفر، لكنه يمنع تسريب المسار من أن يصبح تلقائيًا حدثًا مثبتًا لكشف البيانات.
تشمل واجبات Google في مثل هذا الحدث مراقبة المسار، ونشر ROA، وكائنات IRR دقيقة، والتصعيد مع المزودين، والتواصل مع العملاء، وهندسة المرور الطارئة، والأدلة بعد الحدث. منصة بحجم Google لا يمكنها إيقاف كل تسريب خارجي، لكن يمكنها تقليل وقت الاكتشاف والإصلاح. يمكنها أيضًا تصميم الخدمات بحيث لا يكشف انعطاف المسار عن محتوى المستخدم بصمت. التشفير، ونظافة الشهادات، وتكرار الخدمة، والقياس عن بعد للشبكة كلها جزء من حزمة المرونة هذه.
في نفس الوقت، لم تستطع Google فرض سياسة الاستيراد والتصدير الصحيحة على MainOne أو China Telecom من جانب واحد. لهذا يجب أن تتبع مساءلة أمن التوجيه قدرة التحكم بدلاً من رؤية العلامة التجارية. عانى المستخدمون من أعراض انقطاع Google، وتحملت علامة Google التجارية ضربة الثقة المواجهة للجمهور. لكن سياسة التوجيه التي قبلت وصدّرت المسارات المسربة كانت خارج شبكة Google. سؤال الحوكمة هو كيف عالجت عقود Google وترتيبات النظير ودفاتر التصعيد هذا الاعتماد الخارجي قبل الحدث.
سيتضمن السجل العام الأقوى من المنصات المتأثرة وقت الاكتشاف، وعدد البادئات المتأثرة، والتأثير المواجه للعميل، وتغييرات المسار الملحوظة، وتقييم التشفير والسرية، والمزودين الذين تم الاتصال بهم، وختم الإصلاح، وأي تغييرات في مراقبة المسار أو متطلبات الشريك بعد الحادثة. بعض هذه الأدلة قد تكون حساسة أثناء حدث مباشر، لكن الملخصات بعد الحدث يمكنها مشاركة الفئات دون كشف أسرار دفاعية.
بالنسبة للعملاء، الدرس ليس إلقاء اللوم على Google لكل مسار خارجي. إنه سؤال كبار مزودي الخدمات السحابية والمنصات عن كيفية مراقبتهم للوصول العالمي، والمسارات المصرح بها، ومدى سرعة اكتشافهم للمسارات المشبوهة، وما الالتزامات التي يقدمونها عندما يتسبب فشل توجيه من طرف ثالث في جعل الخدمات غير قابلة للوصول. التوفر لا ينتهي عند حافة المزود.
العقود تحتاج إلى ضوابط قابلة للتنفيذ
عبارة "عدم تطابق العقد والتحكم" تلتقط نمط فشل يظهر عبر البنية التحتية للإنترنت. قد يكون لدى الأطراف عقود تحدد من هو النظير أو العميل أو المزود. لكن أجهزة التوجيه تفرض سياسة المسار، وليس النية القانونية. إذا كانت سياسة المسار لا تجسد العلاقة، يصبح العقد حجة بعد وقوع الحدث بدلاً من كونه تحكمًا وقائيًا. جعل تسريب Google لعام 2018 هذه الفجوة مرئية للمستخدمين العاديين لأن تغيير المسار كسر خدمات عالية الوضوح.
تشمل الضوابط القابلة للتنفيذ تصفية البادئات المبنية على مجموعات المسار المصرح بها من العميل، وتصفية مسار AS، وحدود المسار، وسياسات جلسة النظير، والتحقق من صحة أصل RPKI، وكشف تسريب المسار، والتنبيه للتصدير المفاجئ للبادئات الشهيرة، وجهات اتصال الطوارئ المختبرة. تشمل أيضًا ضوابط الحوكمة: مراجعة التغييرات لسياسة التصدير، وتسوية مجموعة المسار بشكل دوري، ومراجعة نطاق العميل، وتدريبات الحوادث، وسلطة موثقة لإغلاق جلسة مسربة بسرعة.
تجعل إرشادات MANRS وNIST وIETF هذه الضوابط أقل غرابة مما كانت عليه في العصور السابقة. النقطة ليست أن كل مشغل يمكنه القضاء على كل تسريب غدًا. النقطة هي أن مفردات التحكم موجودة. مزود يبيع الوصول العالمي يجب أن يكون قادرًا على شرح كيف يمنع مسار نظير محلي من أن يصبح نقلًا عالميًا وكيف يكتشف الفشل إذا انكسرت الوقاية.
يجب على مجالس الإدارة طلب أدلة، وليس شعارات. "نحن نتبع أفضل الممارسات" ليس كافيًا. لوحة معلومات مفيدة ستظهر سياسة التحقق من صحة RPKI، وتغطية تصفية العملاء، وتغطية سياسة استيراد وتصدير EBGP الصريحة، وأحداث الحد الأقصى للبادئات، واستثناءات كائنات المسار القديمة، وتنبيهات التسريب، وأوقات الاستجابة، والشذوذ غير المحلول. ستميز رفض الأصل غير الصالح من ضوابط تسريب المسار، لأن هاتين فئتين مختلفتان من المخاطر.
الخلاصة هي أن تسريب مسار Google لعام 2018 كان حدثًا للمساءلة حول قابلية حوكمة العلاقات. خطأ MainOne كان مهمًا. انتشار China Telecom كان مهمًا. قبول الشبكات الأخرى كان مهمًا. مرونة Google وتواصلها كانا مهمين. كان على الجمهور تجربة فشل سياسة المسار كانقطاع في الخدمة. درس الإصلاح ليس فقط نظافة BGP بشكل أفضل بشكل مجرد؛ إنه تحويل العقود والتوقعات إلى ضوابط مسار تفشل بشكل مرئي وتتعافى بسرعة.
بدا المسار سياسيًا لأن المسار كان خاطئًا تشغيليًا
جذب تسريب مسار Google لعام 2018 الانتباه العام جزئيًا لأن حركة المرور بدت وكأنها تمر عبر الصين وروسيا. كانت هذه الجغرافيا مهمة للمستخدمين والصحفيين لأنها أثارت مخاوف المراقبة والسيادة. توضح أيضًا قاعدة أكثر عمومية: عندما تنتهك مسارات التوجيه التوقعات، يتسع نطاق التفسير بسرعة. لا يعرف المستخدمون ما إذا كانوا يرون ازدحامًا، أو رقابة، أو اختطافًا، أو تسربًا عرضيًا، أو مراقبة، أو هجومًا، أو محسن توجيه خاطئ. يجب أن يكون سجل المشغل دقيقًا بما يكفي لفصل تأثير التوفر عن اختراق السرية والحادث عن النية.
حافظت التقارير العامة على موقف Google بأن حركة المرور المتأثرة كانت مشفرة ولا يوجد سبب للاعتقاد بأن خدماتها قد تعرضت للاختراق. كان هذا البيان مهمًا. قلل من خطر أن يتم التعامل مع انعطاف المسار تلقائيًا على أنه خرق للمحتوى. لكن التشفير لم يمحِ مشكلة التوفر. المستخدم الذي تكون حركة مروره مشفرة لكنها مسقطة لا يزال لا يمكنه الوصول إلى الخدمة. الشركة التي تكون خدمة Google الخاصة بها غير قابلة للوصول لا تزال تواجه اضطرابًا تشغيليًا. وكالة عامة أصبح مسارها الآن يعبر ولاية قضائية غير متوقعة قد لا يزال لديها مخاوف سياسية حتى لو تم الحفاظ على سرية الحمولة.
كشف المسار أيضًا لماذا تكون الضوابط الواعية بالعلاقة أكثر أهمية من التصنيفات الوطنية. دور China Telecom لم يكن إشكاليًا لمجرد أن الشبكة صينية. كان إشكاليًا لأنه من الواضح أن المسار لم يكن يجب قبوله ونشره بهذا الشكل. مزود كبير آخر في بلد مختلف كان يمكن أن يخلق انقطاعًا مماثلاً إذا قبل مسارًا تم تعلمه من نظير أو تسرب من عميل انتهك سياسة المسار. يجب أن يركز معيار المساءلة لذلك على التصفية، وسلطة المسار، والعلاقة، والمراقبة، وأدلة الإصلاح، مع الاعتراف بأن الجغرافيا يمكن أن تضخم قلق المستخدم.
يساعد هذا التمييز في تجنب قراءتين سيئتين. قراءة سيئة تعامل الحدث كدليل على اعتراض خبيث دون دليل. الأخرى تعامله كحادث غير ضار لأنه لم يتم إثبات اختراق المحتوى. القراءة الصحيحة في المنتصف: يمكن أن يكون تسريب المسار عرضيًا ولا يزال خطيرًا؛ يمكن أن تظل حركة المرور المشفرة سرية ولا تزال غير متوفرة؛ يمكن أن يفتقر المزود إلى نية خبيثة ولا يزال يفشل في واجب تصفية مهم. تحتاج الحوكمة إلى تلك المفردات الوسطى.
تظهر البصريات السياسية أيضًا لماذا التواصل العام في الوقت المناسب مهم. في غياب تفسير المشغل، تصبح تتبعات التوجيه ومسارات BGP مادة خام للتكهن. يجب على المنصات المتأثرة التواصل حول ما هو معروف عن المسار، وما هو معروف عن التشفير، وما لا يزال غير معروف، وما تم إصلاحه، والأطراف التي سيطرت على سياسات المسار الفاشلة. هذه ليست فقط إدارة سمعة. إنها طريقة لمنع المستخدمين من الخلط بين كل مسار غريب وخرق مؤكد مع الاستمرار في معاملة التوفر وسلامة التوجيه كمخاطر حقيقية.
النظير والنقل هما علاقات تجارية ذات أسنان تقنية
غالبًا ما يتم تلخيص النظير والنقل كترتيبات تجارية: يتبادل النظير حركة المرور للمنفعة المتبادلة، بينما يبيع مزودو النقل الوصول إلى الإنترنت الأوسع. يُظهر تسريب Google لماذا تحتاج هذه المصطلحات إلى أسنان تقنية. لا يجب تصدير مسار تم تعلمه من نظير تلقائيًا كما لو كان مسار عميل. لا يجب تصديق مسار عميل تلقائيًا كما لو كان العميل مصرحًا له بنقل منصة عالمية. المسار المقبول تحت علاقة واحدة يجب أن يحمل قيود سياسة عندما يعبر حدًا آخر.
يجب تنفيذ هذا التعيين في تكوين الموجه وأنظمة التحقق. يشمل سياسة استيراد صريحة لما قد يرسله الجار، وسياسة تصدير صريحة لأين قد تذهب هذه المسارات، وتصفية البادئات ومسارات AS، وحدود المسار، والتحقق من صحة أصل RPKI حيثما ينطبق، وعلامات العلاقة، ومراقبة التوسع المفاجئ في مجموعة المسار، وسلطة الإغلاق الطارئ. الكلمة المهمة هي "صريح". الافتراضات والمعرفة القبلية ليست كافية عندما يمكن لخطأ تكوين أن يجعل Google غير قابلة للوصول.
يعكس مبدأ الرفض الافتراضي لـ RFC 8212 نفس الفلسفة: لا يجب أن تستورد جلسات BGP الخارجية أو تصدر مسارات دون سياسة صريحة. لا يمنع هذا كل خطأ. سياسة خاطئة صريحة لا تزال يمكن أن تسرب مسارات. لكنه يزيل الافتراض الأكثر خطورة بأن الجلسة غير المكونة أو غير المكتملة يجب أن تنشر افتراضيًا. في لغة الحوكمة، الرفض الافتراضي يجبر المشغلين على ذكر نية التوجيه الخاصة بهم قبل أن يتصرف مستوى التحكم.
يجب أن تتبع العقود نفس المنطق. اتفاقية نظير أو عقد نقل لا يجب أن تقول فقط ما ينوي الأطراف؛ يجب أن تتطلب دليلاً على أن النية مُنفذة. هل يحافظ كل طرف على مرشحات المسار؟ كيف يتم إنشاء مجموعات بادئات العملاء؟ كم مرة يتم مراجعتها؟ ماذا يحدث عندما يسرب جار بادئات شهيرة؟ من لديه سلطة إغلاق جلسة؟ ما الإشعار العام أو للعميل الذي يتبع؟ هذه البنود ليست تجاوزًا قانونيًا غريبًا. إنها ترجمة الضرر الناتج عن التوجيه إلى التزامات تشغيلية.
يجب أن يهتم العملاء حتى عندما لا يكونون مشغلي شبكات. مشتري SaaS، بنك، ناشر، أو وكالة حكومية قد يعتمد على مزود يعتمد وصوله على علاقات النقل. لا يمكن للمشتري تدقيق كل مسار عالمي، لكن يمكنه سؤال مزوديه الحرجين عن كيفية مراقبتهم للوصول، وكيف يستخدمون RPKI، وكيف يحمون ضد تسريبات المسار، وكيف يخطرون العملاء عندما يؤثر فشل مسار خارجي على الخدمة. اتفاقية مستوى الخدمة التي تستبعد "مشاكل توجيه الإنترنت" قد تصف التخصيص القانوني، لكنها لا تجعل الاعتماد التشغيلي يختفي.
لماذا لا يزال التحقق من الأصل جزءًا من النقاش
لأن حدث Google لعام 2018 كان تسريب مسار وليس اختطافًا بسيطًا بأصل خاطئ، قد يستنتج بعض القراء أن RPKI غير ذي صلة. سيكون هذا الدرس خاطئًا. التحقق من صحة أصل RPKI لم يكن تحكمًا كاملاً للتسريب، لكنه لا يزال ينتمي إلى مجموعة المساءلة. يساعد في تمييز فئة من السلطة الزائفة عن أخرى، ويقلل من المستوى الأساسي للمسارات السيئة، ويعطي المشغلين دليلاً قابلاً للقراءة آليًا للعديد من الحوادث التي كانت ستعتمد لولا ذلك على الثقة اليدوية.
الحد دقيق. إذا كان المسار لا يزال ينشأ من AS Google المصرح به، يمكن أن يتحقق مكون الأصل بينما يظل المسار غير مقبول. في هذه الحالة، يقول RPKI إن الأصل مسموح به، وليس أن MainOne أو China Telecom أو TransTelecom أو NTT أو أي جزء مسار آخر يجب أن يحمل المسار في تلك العلاقة. التحقق من المسار ومنع تسريب المسار يتطلبان ضوابط إضافية. لهذا أهمية RFC 9234 والآليات الواعية بالعلاقة. تعالج جزءًا مختلفًا من مشكلة الثقة.
لا يزال التحقق من الأصل يمكن أن يساعد أثناء الاستجابة للحوادث. إذا كان مسار مشبوه غير صحيح الأصل، يمكن للمشغلين رفضه أو تصعيده على أنه غير مصرح به على الأرجح. إذا كان صحيح الأصل لكن مريب المسار، يمكنهم تصنيف الحادثة كتسريب أو فشل في سياسة المسار. هذا التصنيف يؤثر على من يتصل وأي أدلة يفحصها. عملية أمن توجيه ناضجة لا تطلب من RPKI الإجابة على كل سؤال؛ تستخدم RPKI لإزالة الغموض حيث يمكنها ثم تطبق فحوصات سياسة مسار إضافية.
RPKI يغير أيضًا الحوافز حول التوثيق. منصة مثل Google يجب أن تحافظ على ROAs دقيقة، لكن يجب أيضًا أن تحافظ على كائنات المسار وسياسات النظير وجهات اتصال المزود والمراقبة الخارجية. مزود مثل China Telecom يجب أن يتحقق من الأصول لكن أيضًا يصفي وفقًا للعلاقة. نظير مثل MainOne يجب أن يمنع مسارات النظير من التسرب إلى النقل. الضوابط تكمل بدلاً من أن تحل محل بعضها البعض.
يجب على القارئ أن يأخذ نموذجًا متعدد الطبقات. RPKI يتعامل مع سلطة الأصل. تصفية البادئات ومسارات AS تتعامل مع سلطة العميل والنظير المتوقعة. أدوار BGP وOTC يمكنها ترميز اتجاه العلاقة. المراقبة تكتشف الانحرافات. التنسيق البشري يصلح ما لا يمكن للأتمتة أن تقرره بأمان. لغة العقد ومقاييس الحوكمة تحافظ على صيانة الطبقات. كشف حدث Google فجوة في ذلك النموذج متعدد الطبقات، وليس عدم جدوى بنائه.
سجل إصلاح عام أفضل كان سيفصل كل نقطة تحكم
سجل مفيد بعد الحادثة لتسريب 2018 كان سيحدد كل نقطة تحكم في المسار. في MainOne، كان السجل سيشرح أي مجموعة مسار تم تعلمها من Google، وأي سياسة كان يجب أن تمنع التصدير، وما الذي تغير، ومتى بدأ التسريب، ومتى تم اكتشافه، وكيف تم تصحيحه. في China Telecom، كان سيشرح لماذا تم قبول المسار المسرب، وما إذا كانت مرشحات العملاء أو النظراء موجودة، وما إذا كانت حدود المسار قد تم تشغيلها، ومتى توقف التصدير. عند المزودين النهائيين، كان سيشرح أي المسارات تم اختيارها ولماذا.
بالنسبة لـ Google، كان السجل سيغطي التأثير المواجه للعميل، والخدمات المتأثرة، وتقييم التشفير والاختراق، وجدول زمني للاكتشاف، وتصعيد المزود، ومراقبة المسار، وأي هندسة مرور طارئة، وتغييرات بعد الحدث في متطلبات النظير. بالنسبة للمراقبين المستقلين، كان دليل مجمع المسار يمكن أن يظهر الانتشار والسحب. بالنسبة للعملاء، ملخص موجز كان يمكن أن يميز فقدان التوفر عن دليل كشف البيانات. تلك السجلات المنفصلة كانت ستتيح لكل طرف امتلاك سطح التحكم الخاص به دون إجبار بيان فاعل واحد على شرح الإنترنت بأكمله.
السجل العام متاح جزئيًا من خلال التحليل المستقل، لكن سجل الإصلاح الداخلي يظل ضعيفًا. هذا شائع في حوادث التوجيه. غالبًا ما يصلح المشغلون المسار ويمضون قدمًا. المشكلة هي أن حوادث التوجيه ليست فرصًا للتعلم إلا إذا تم وصف فشل التحكم على المستوى الذي يمكن إصلاحه. "سوء التكوين" غير كافٍ. أي سياسة؟ أي جلسة؟ أي مجموعة مسار؟ أي علاقة جار؟ أي تنبيه؟ أي سلطة للسحب؟ بدون تلك الإجابات، يمكن أن يتكرر نفس الفشل مع بادئة مختلفة ومنصة مختلفة.
لا يجب على المنظمين والمشترين الكبار أن يطلبوا من كل مشغل نشر تكوين موجه حساس. يمكنهم طلب خطط أمن التوجيه وفئات الأدلة. على سبيل المثال: تغطية تصفية بادئات العملاء، وسياسة التحقق من صحة RPKI، والتنبيه بتسريب المسار، وتغطية سياسة EBGP الصريحة، واستثناءات الحد الأقصى للبادئات، ومعدلات نجاح الاتصال في حالات الطوارئ، وملخصات ما بعد الحادثة. تلك المقاييس عملية بما يكفي لتدقيقها دون كشف كل سطر موجه.
يبقى تسريب Google لعام 2018 مفيدًا لأنه يجعل عدم تطابق العقد والتحكم مرئيًا. لم يكن كافيًا أن العلاقات التجارية توحي بأن المسار لا يجب أن يسافر بهذه الطريقة. احتاجت أجهزة التوجيه إلى سياسة قابلة للتنفيذ. احتاجت المراقبة إلى رؤية الانحراف. احتاج البشر إلى جهات اتصال يمكن الوصول إليها. احتاج الجمهور إلى دليل على أن التسريب تم احتواؤه وأن التشفير حد من مخاطر السرية. هذه هي مجموعة الحوكمة التي كشفها الحادث.
قرار القارئ لعقود التوجيه
يجب أن يترك القارئ تسريب مسار Google لعام 2018 بسؤال مشتريات وحوكمة: هل يترجم مزودونا الحرجون علاقات التوجيه إلى ضوابط يمكننا قياسها؟ لا يهتم تسريب المسار بأن العقد يصف الجار كنظير أو عميل. يهتم بما إذا كانت سياسة الموجه تمنع التصدير الخاطئ وما إذا كانت المراقبة تلتقط التسريب عندما تفشل السياسة. يجب على العملاء لذلك سؤال المزودين عن أدلة تصفية بادئات العملاء، وسياسات استيراد وتصدير EBGP الصريحة، والتحقق من صحة RPKI، والتنبيه بتسريب المسار، وجهات اتصال التصعيد على مدار الساعة.
بالنسبة للمنصات، القرار هو معاملة التوجيه الخارجي كجزء من مرونة الخدمة. يمكن لمزود أن يمتلك مراكز بيانات ممتازة وTLS قوي وتطبيقات محصنة بينما لا يزال يصبح غير قابل للوصول إذا فضلت الشبكات البعيدة مسارًا مسربًا. هذا يعني أن مراقبة المسار العالمية، وتدريبات تصعيد المزود، ونظافة ROA، ونظافة كائن المسار، والتواصل مع العملاء تحتاج إلى الجلوس بالقرب من هندسة التوفر العادية. "الإنترنت انكسر خارج حافتنا" قد يكون صحيحًا وصفيًا، لكن العملاء لا يزالون بحاجة إلى دليل على الاكتشاف والتشخيص والإصلاح.
بالنسبة لمزودي النقل، القرار هو إثبات التصفية قبل أن يجعل تسريب مسار شهير المشكلة عامة. لا يجب السماح لجلسة عميل أو نظير بأن تصبح مسار نقل مفاجئ لـ Google أو بنك أو خدمة حكومية أو CDN. يجب على المزود معرفة مجموعات المسار المتوقعة، ورفض الإعلانات غير المعقولة، والتنبيه على التوسع المفاجئ، والاحتفاظ بسجلات كافية لشرح الإصلاح. تأتي قيمة الوصول العالمي مع واجب عدم عولمة خطأ طرف آخر.
بالنسبة لمجالس الإدارة والمنظمين، الدرس هو طلب مقاييس أمن التوجيه بنفس الطريقة التي يطلبون بها مقاييس الأمن السيبراني. معدل رفض RPKI غير الصحيح، وتغطية تصفية العملاء، وتغطية السياسة الصريحة، وتنبيهات التسريب، وكائنات المسار القديمة، وحوادث الحد الأقصى للبادئات، ووقت استجابة الاتصال هي إشارات حوكمة. ليست أسرار حزم عميقة. إنها دليل على أن حدود العلاقة لها إنفاذ تقني.
حدث 2018 لا يزال مفيدًا لأنه يرفض أن يتناسب مع تحكم واحد. RPKI مهم، لكن التحقق من الأصل وحده لم يكن كافيًا. العقود مهمة، لكنها لم تفرض نفسها. التشفير مهم، لكنه لم يستعيد الوصول. تطلب الإصلاح المجموعة الكاملة: سياسة المسار، المراقبة، التنسيق، التواصل مع العملاء، والأدلة العامة.
اختبار تشغيلي نهائي هو سؤال ما إذا كان سيتم ملاحظة تسريب المسار التالي أولاً من قبل العملاء أو الباحثين الخارجيين أو الشبكات التي تحمله. إذا كان المستخدمون الخارجيون هم الكاشف الأساسي، فإن نظام العقد والتحكم ضعيف جدًا. يجب أن يكون المزودون قادرين على رؤية متى يظهر النظير فجأة لنقل شبكة فائقة الحجم، ومتى يصدر العميل مجموعة مسار خارج سلطته، ومتى تتعارض مسارات حركة المرور مع العلاقات التجارية. تلك الرؤية تحول عقود التوجيه من أوراق إلى بنية تحتية قابلة للتنفيذ.
نفس الاختبار ينتمي إلى مشتريات الخدمات السحابية ومزودي المحتوى. قد لا يدير المشتري BGP على نطاق عالمي، لكن يمكنه أن يسأل ما إذا كان مزوده يراقب تسريبات المسار، ويتحقق من الأصول، وينشر جهات اتصال أمن التوجيه، ويتمرن على تصعيد المزود، ويمكنه شرح ما إذا كانت حركة المرور كانت غير متوفرة فقط أو كانت أيضًا معرضة لخطر المسار. تلك الإجابات ليست تفاهات شبكة مجردة. إنها تشكل استمرارية الإيرادات، ودعم العملاء، وضمان الخصوصية، والوصول في القطاع العام. حادثة Google/MainOne هي لذلك تذكير بأن مالكي التطبيقات يرثون بعض الاعتماد على التوجيه سواء لامست فرقهم سياسة التوجيه أم لا.
تبدأ المساءلة عندما يتم تسمية هذا الاعتماد الموروث وقياسه وتعيينه لمالك تحكم بدلاً من معاملته كطقس غير معروف للإنترنت.
يجب على هذا المالك أيضًا التحكم في اللغة المستخدمة أثناء الانقطاع. يمكن أن تبدو تسريبات المسارات مثل تفاصيل ناقل بعيدة، لكن سؤال العميل فوري: هل يمكن للمستخدمين الوصول إلى الخدمة، هل المسار موثوق، ما الذي تغير، ومتى سيعود إلى طبيعته؟ ملاحظة حادثة قوية تميز فقدان الوصول، مسار النقل غير المتوقع، حالة التشفير، الاشتباه في الاختراق، والمعالجة. يُظهر سجل Google لماذا تلك التمييزات مهمة. الطمأنة بأن حركة المرور كانت مشفرة مهمة، لكنها لا تجيب على سؤال التوفر. سحب المسار قد يستعيد الخدمة، لكنه لا يشرح أي علاقة فشلت. التواصل الجيد يبقي أسطح التحكم تلك منفصلة بما يكفي للمشترين والمستخدمين والمشغلين للتعلم من الحدث.
الخلاصة
معيار المساءلة هو تحكم عملي مقترن بأدلة عامة. السجل الأقوى لا يتظاهر بأن كل ممثل سيطر على كل نتيجة. يحدد من يمكنه منع الفشل، ومن يمكنه اكتشافه، ومن يمكنه الحد من نصف قطر الانفجار، ومن يمكنه إخطار الأطراف المتأثرة، ومن يمكنه إصلاح علاقة الثقة، وما الدليل الذي يثبت أن الإصلاح وصل إلى الأنظمة والأشخاص الذين اعتمدوا عليه.
حد أدلة إضافي
بالنسبة لتسريب مسار Google لعام 2018 الذي أظهر عدم التطابق بين عقود التوجيه والتحكم الفعلي، فإن حد الأدلة الإضافي هو الحفاظ على فصل الحقائق المؤكدة والاستدلال المدعوم بالأدلة والمعلومات غير المعروفة. هذا الفصل مهم لأن حدثًا يشمل تسريب مسار Google وMainOne وعدم تطابق العقد والتحكم يمكن وصفه كمشكلة تقنية أو تعاقدية أو اتصالية اعتمادًا على أي ممثل يتحدث. لذلك يجب أن يعود تحليل المساءلة إلى التحكم العملي: من يمكنه تغيير التكوين، وتحديد التعرض، وتسريع الاكتشاف، وتفويض الإخطار، أو إثبات أن الإصلاح قد وصل إلى المستخدمين المتأثرين.
تضيف هذه العدسة اختبارًا دقيقًا للسبب الجذري والحدث المحفز. يشرح المحفز لماذا أصبح الحدث مرئيًا في لحظة معينة؛ يتطلب السبب الجذري أدلة حول خيارات التصميم والتحكم والحوكمة والتحقق التي كانت موجودة قبل تلك اللحظة. يجب تقييم الظروف المساهمة مثل الاعتماد والتفويض ونوافذ التغيير والعقود والسجلات والحوافز دون معاملة بيان الشركة كحقيقة كاملة أو تحويل احتمال إلى استنتاج مؤكد.
ينطبق نفس الانضباط على فشل الكشف وفشل الاستجابة وفشل التعافي. يجب أن يُظهر السجل العام متى شوهدت الإشارة، ومن كان لديه سلطة التصرف، وما الذي قيل للعملاء أو المنظمين، وأي أدلة إضافية من شأنها تقوية أو إضعاف الاستنتاج. بينما تظل تلك العناصر جزئية، فإن الاستنتاج المسؤول ليس اتهامًا إضافيًا؛ إنه خريطة أكثر دقة للمسؤولية وعدم اليقين وضوابط مستوى التحكم والاعتماد التي يجب أن يتحقق منها تدقيق لاحق.

