الخلاصة

  • يقول RIPE NCC إنه يحدّث لوحة RPKI لاستخدام OpenID Connect، وبدأ استبدال مفاتيح API الحالية بمفاتيح مبنية على OIDC ومتكاملة مع RIPE NCC Access. العمل ما زال قيد التنفيذ.
  • رفضت المؤسسة في مسار منفصل استخدام واجهة لمنارة RPKI لأنها كانت ستسمح بتعديل ROA لكل فضاء RIPE NCC. التحقق من صاحب الاعتماد وتحديد الموارد التي يسيطر عليها إثباتان مختلفان.

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

في خطة RPKI للربع الرابع من 2026، والمحدّثة في 17 سبتمبر، أوضح RIPE NCC أنه ينقل لوحة التحكم إلى OpenID Connect الذي يوفره نظام الدخول الموحد RIPE NCC Access. وبدأ أيضاً العمل على استبدال مفاتيح RPKI API الحالية بمفاتيح قائمة على OIDC ومتصلة بالنظام نفسه. ستضاف مساحة لإدارتها داخل اللوحة، بينما ستُعرض تفاصيل التنفيذ والجدول الزمني في اجتماع RIPE مقبل. الحالة المنشورة هي «قيد التنفيذ»، وليست خدمة مكتملة.

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

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

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

يوضح بند آخر في صفحة التخطيط لماذا يجب الحفاظ على هذا الفصل. طلب المجتمع منارة توجيه معروفة تتغير صلاحيتها في RPKI لخدمة الباحثين. لم يضفها RIPE NCC لأن الواجهة المستخدمة كانت ستسمح بتحرير ROA لكل فضائه، وعدّ ذلك غير مقبول. وسيبحث عن نهج آخر مع فريق RIS.

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

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

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

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

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

المصادر