الخلاصة

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

التحقق من الدخول لا يشرح وحده سلطة التغيير

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

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

وتدعم RIPE-843 هذا الفصل. فهي تربط مفاتيح API بحساب محدد في RIPE NCC Access، وتقول إن المفتاح قد يُعطل إذا عُطل الحساب أو إذا لم يعد الشخص مسؤول صيانة للحساب في التطبيق المعني. هذه قاعدة لدورة هوية الحساب، وليست دفترًا عامًا يبيّن نطاق كل طلب أو تفويض كل مورد.

آلية هوية مخططة وحدّ نطاق رُفض

في صفحة RPKI Quarterly Planning، يقول RIPE NCC إنه يخطط لاستبدال مفاتيح RPKI الحالية بمفاتيح مبنية على OpenID Connect ومتكاملة مع RIPE NCC Access، وإضافة قسم لإدارتها في لوحة RPKI. الحالة المنشورة هي «Planned». ولا تحدد الصفحة موعد نشر أو تصميمًا نهائيًا للرمز أو بنية عامة لأحداث التغيير.

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

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

يكفي إيصال صغير للنطاق من دون كشف البنية

ليس المطلوب نشر أسرار أو بادئات أو أرقام AS أو طلبات API الخام أو الإعدادات. فقد تزيد تلك المواد انكشاف الشبكة من دون أن تشرح قرارًا. يمكن لإيصال نطاق محدود أن يحتفظ بما يلزم.

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

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

المصادر