الملخص

  • في 12 نوفمبر 2018، تسربت مسارات مرتبطة بخدمات Google من مزود الخدمة النيجيري MainOne إلى China Telecom ثم انتشرت عبر مزودين آخرين، مما أدى إلى توجيه بعض حركة مرور Google عبر مسارات غير متوقعة وجعل الخدمات غير متاحة لبعض المستخدمين.
  • يختلف هذا الحادث عن حادثة اختطاف يوتيوب التي قامت بها Pakistan Telecom عام 2008. هنا لم تكن مشكلة المساءلة الحرجة هي حظر وطني تم تصديره كمسار أكثر تحديداً ذي أصل خاطئ؛ بل كانت عدم توافق بين العقد والتحكم، حيث تسربت المسارات التي تم تعلمها عبر علاقة واحدة إلى علاقات أخرى.
  • يدعم السجل العام وجود خطأ في التهيئة وليس دليلاً على اختراق ناجح للمحتوى. أفادت Google بأن حركة المرور المتأثرة كانت مشفرة وأنه لا يوجد سبب للاعتقاد بأن الخدمات قد تعرضت للاختراق، بينما تعامل المراقبون المستقلون مع مسار التوجيه باعتباره خطراً جاداً على التوافر والمراقبة.
  • التحقق من أصل المسار (RPKI) ليس حلاً كاملاً لهذه الفئة من الفشل لأن المسارات المتأثرة قد تستمر في الظهور وكأنها صادرة من نظام Google المستقل (AS) الشرعي. تتطلب تسربات المسارات تصفية العملاء والنظراء، وضوابط مدركة للعلاقات، وحدوداً للبادئات، ومراقبة، وتنسيق، وآليات لاحقة مثل BGP Roles.
  • الدرس المتعلق بالمساءلة هو أن عقود التناظر والترانزيت التجارية لا تفرض نفسها. يجب على المشغلين تحويل العلاقات التجارية إلى سياسات موجهات وضوابط قابلة للتحقق خارجياً قبل أن يتحول مسار متسرب إلى انقطاع عالمي.

سجل الأدلة وكيفية استخدامه

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

#السجل العامالاستخدام في هذا التحليل
1تحليل Cloudflareتحليل المشغل لبدء الساعة 21:12 بالتوقيت العالمي، وخطأ التهيئة من MainOne، وآليات تسرب المسارات، وتأثر إمكانية الوصول إلى Google، وتأطير مسار المسار.
2تحليل ThousandEyesقياس مستقل لتناظر MainOne مع Google في IXPN، وتسرب المسارات إلى China Telecom، وانتشارها عبر TransTelecom و NTT، وتأثير مسار المستخدم.
3تحليل Internet Societyتفسير أمن التوجيه بأن التصفية من قبل 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 على خطأ في تكوين الموجه.
9RFC 4271معيار BGP-4 لتوجيه الأنظمة المستقلة، وإعلانات المسارات وسياسة التوجيه.
10RFC 7908تصنيف تسرب المسارات المستخدم لتصنيف الانتشار خارج النطاق المقصود.
11RFC 7454إرشادات عمليات وأمن BGP لتصفية البادئات، وتصفية مسار AS، وسياسة الحدود.
12RFC 8212سلوك الرفض الافتراضي لـ EBGP في حالة عدم وجود سياسة استيراد/تصدير صريحة.
13RFC 6811معيار التحقق من أصل RPKI المستخدم لشرح لماذا يمكن لتسربات المسارات ذات الأصل الصحيح أن تتحايل على فحوصات الأصل فقط.
14RFC 9234معيار BGP Roles و Only-to-Customer لمنع تسرب المسارات لاحقًا.
15إجراءات مشغل الشبكة وفق MANRSمعايير الصناعة للتصفية، ومكافحة الانتحال، والتنسيق، والتحقق العالمي.
16NIST 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 هش. هذه العبارة صحيحة ولكنها ليست دقيقة بما يكفي. الدرس الأكثر وضوحاً هو أن الإنترنت تحتوي على العديد من العلاقات التجارية التي لا يمكن لبرمجيات التوجيه استنتاجها إلا إذا قام المشغلون بترميزها. قد يرسل النظير مسارات ينبغي أن تظل محلية. قد يتلقى مزود الترانزيت مسارات لا ينبغي أبداً قبولها من ذلك الجار. قد يحتفظ المسار بأصل النظام المستقل الصحيح بينما لا يزال يسافر عبر مسار ينتهك التوقعات التجارية والتشغيلية.

تتقارب تقارير Cloudflare و ThousandEyes و Internet Society حول الشكل الأساسي. كان لدى MainOne اتصال مع Google من خلال علاقة تناظر في لاغوس. تسربت المسارات المرتبطة بـ Google من هذه العلاقة إلى China Telecom. قامت China Telecom بنشرها، وظهرت مسارات تضم TransTelecom و NTT وشبكات أخرى. ثم اتبع المستخدمون الذين يحاولون الوصول إلى خدمات Google مسارات لم تكن لديها القدرة أو السياسة أو التصفية المتوقعة لحمل تلك الحركة. تم إسقاط بعض حركة المرور وأصبحت الخدمات غير متاحة لبعض المستخدمين.

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

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

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

الأصل الصحيح لا يعني المسار الصحيح

تبدأ العديد من مناقشات أمن التوجيه بحالات الاختطاف لأن الإعلانات ذات الأصل الخاطئ أسهل في الشرح. يقول شخص لا يملك بادئة، في الواقع، أرسل تلك الحركة إلي. تم بناء التحقق من أصل المسار (RPKI) لمعالجة هذه الفئة: حيث ينشر حامل المورد تفويض أصل المسار (ROA)، ويمكن للشبكات المُتحققة رفض المسارات التي لا يتطابق أصل نظامها المستقل أو طول البادئة الخاصة بها. هذا التحكم مهم. يُظهر حدث Google 2018 حدوده.

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

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

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

تحاول الأعمال التقنية اللاحقة مثل BGP Roles وسمة 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 تحكماً كاملاً للتسرب، لكنه لا يزال جزءاً من هيكل المساءلة. إنه يساعد على التمييز بين فئة من السلطة الزائفة عن أخرى، ويقلل من المستوى الأساسي للمسارات السيئة، ويمنح المشغلين أدلة مقروءة آلياً للعديد من الحوادث التي كانت ستعتمد على الثقة اليدوية.

الحد دقيق. إذا كان المسار لا يزال صادراً عن نظام Google المستقل المصرح به، يمكن لمكون الأصل أن يتحقق بينما يظل المسار غير مقبول. في هذه الحالة، يقول RPKI إن الأصل مسموح به، وليس أن MainOne أو China Telecom أو TransTelecom أو NTT أو أي جزء آخر من المسار ينبغي أن يحمل المسار في تلك العلاقة. يتطلب التحقق من المسار ومنع تسرب المسار ضوابط إضافية. لهذا السبب فإن RFC 9234 والآليات المدركة للعلاقات مهمة. إنها تعالج جزءاً مختلفاً من مشكلة الثقة.

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

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

لذلك، يجب أن يأخذ القارئ معه نموذجاً متعدد الطبقات. يعالج RPKI سلطة الأصل. تعالج مرشحات البادئات ومسار AS سلطة العميل والنظير المتوقعة. يمكن لـ BGP Roles و OTC ترميز اتجاه العلاقة. تكتشف المراقبة الانحرافات. يصلح التنسيق البشري ما لا يمكن للأتمتة أن تقرره بأمان. تحافظ لغة العقد ومقاييس الحوكمة على الطبقات. كشف حدث Google عن فجوة في ذلك النموذج متعدد الطبقات، وليس عن عبثية بنائه.

كان سجل إصلاح عام أفضل سيفصل كل نقطة تحكم

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

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

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

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

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

قرار القارئ بشأن عقود التوجيه

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

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

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

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

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

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

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

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

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

الطباعة

الخلاصة

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