الخلاصة

  • يُبقي RFC 9918 المصادقة المتبادلة بشهادات X.509 في NETCONF عبر TLS، ويحذّر من أن جهة التصديق الموثوقة لهذا الغرض ينبغي أن تُصدر الشهادات فقط لمن يحق لهم الوصول إلى خوادم NETCONF.
  • قبول مسار الشهادة خطوة واحدة؛ تليها قاعدة ربط مرتبة، واسم مستخدم، وسياسة NACM، وعملية RPC، وحالة مخزن بيانات، ثم أثر يحتاج إلى قياس مستقل.
  • سجل التدقيق المفيد يعيد بناء سلسلة القرارات من الشهادة إلى النتيجة، ولا يختصر التفويض والتغيير في عبارة «نجح TLS».

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

يحدّث RFC 9918 نقل NETCONF عبر TLS. تبقى المصادقة المتبادلة في TLS 1.2 إلزامية، وتُوصى المصادقة المتبادلة في TLS 1.3 وتُفضَّل عند توافرها، وتُحظر البيانات المبكرة. أما بدء الاتصال وتأطيره وإغلاقه والتحقق من هوية العميل والخادم فتبقى مرتبطة بـ RFC 7589.

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

ينظّم RFC 5280 التحقق من مسار X.509: التوقيعات، وفترة الصلاحية، والقيود والسياسات، ومرساة الثقة، وما يتوافر من معلومات الإبطال. هذه أدلة ضرورية، لكنها لا تُنشئ وحدها حقاً محلياً في إدارة جهاز. مرساة الثقة ليست قائمة موظفين مخوّلين، حتى لو تعامل معها التطبيق كما لو كانت كذلك.

بعد المسار تأتي صناعة الهوية. يصف RFC 7589 قائمة مرتبة تربط الشهادات بالأسماء. يمكن للقاعدة أن تطابق بصمة الشهادة الطرفية، أو بصمة جهة تصديق موثوقة شاركت في السلسلة. ثم تعطي اسماً مضبوطاً سلفاً أو تستخرجه من rfc822Name أو dNSName أو عنوان IP أو أول subjectAltName مدعوم أو، في المسار القديم غير المفضّل، Common Name.

ترتيب القائمة قرار تشغيلي. قد تسبق قاعدة عامة لجهة التصديق قاعدة دقيقة لشهادة بعينها، فتُنتج اسماً مختلفاً من المادة المشفرة نفسها. وإذا طابقت القاعدة ولم تستطع إنتاج اسم NETCONF صالح، يستمر الفحص إلى القواعد التالية؛ وإن لم تنجح أي قاعدة، تنتهي الجلسة. يبيّن RFC 7407 هذا السطح في نموذج YANG، ولذلك يجب حفظ نسخته وترتيبه مثل أي إعداد نافذ.

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

ولا ينتهي الأمر عند الاسم. يطلب RFC 6241 أن تسلّم طبقة النقل هوية مصادقاً عليها وأن يعرف الخادم صلاحياتها وينفذها خلال الجلسة. يقدّم RFC 8341 سطح NACM المستقل: المستخدم والمجموعات والعملية والبيانات أو الإجراء المستهدف والقواعد السارية لحظة بدء المعالجة.

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

حتى قبول <edit-config> ليس دليلاً نهائياً على الأثر. يربط معرّف الرسالة الطلب بالرد. ويثبت اختيار candidate أو running، والأقفال، والتحقق، وcommit أو confirmed-commit، والقراءة اللاحقة حالة الإعداد. أما برمجة الجهاز وحركة الحزم ونتيجة الخدمة فتحتاج إلى قياسات أخرى. رد <ok> ليس رصداً لمسار المرور.

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

يسجل IANA خدمة netconf-tls على منفذ TCP 6513، مع الإحالة إلى RFC 7589 وRFC 9918. يثبت السجل تخصيص الاسم والمنفذ، لا وجود خدمة مستمعة أو مصدر مسموح أو نسخة TLS أو قاعدة ربط أو قرار NACM أو تغييراً في المرور.

تدعم فكرة الحد الأدنى للمواصفات الأولية لدى Heng Lu قاعدة مشتركة قابلة للتحقق محلياً مع إبقاء الإذن المحلي ظاهراً بوصفه محلياً. وتعطي أولوية الشفرة العاملة وزناً لإيصالات السلسلة والربط وNACM وRPC ومخزن البيانات، لا لوصف «موثوق». أما طبقات الواقع فتمنع صحة PKI والهوية والسلطة والأثر من استعارة يقين بعضها. هذه عدسات تحريرية معلنة وليست متطلبات إضافية من IETF.

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

المصادر