الخلاصة

  • يعرّف RFC 10020 مجموعة CoAP ومجموعة التطبيق ومجموعة الأمان بوصفها مجموعات مستقلة. ويمكن أن تكون العلاقات بينها متعددًا إلى متعدد، أو واحدًا إلى متعدد، أو متعددًا إلى واحد، أو واحدًا إلى واحد؛ ويحدد النشر الفعلي كيفية مطابقتها.
  • يستطيع Group OSCORE توثيق العضو المحدد في مجموعة الأمان الذي أنشأ رسالة محمية. لكن RFC ينص على أن هذه العضوية لا تحل محل التحكم في الوصول إلى موارد التطبيق، فالهوية الموثقة والصلاحية التشغيلية حقيقتان منفصلتان.

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

لم تخفق الحماية. الذي أخفق هو الافتراض بأن ثلاث عضويات مختلفة تعني سلطة واحدة.

يقع هذا الفصل في صميم RFC 10020، وهو معيار IETF على مسار المعايير صدر في يوليو 2026 للاتصال الجماعي عبر CoAP. يحل النص محل RFC 7390 ويحدّث RFC 7252 وRFC 7641، ويجعل البث المتعدد عبر UDP/IP وسيلة النقل الافتراضية للطلبات الجماعية. وقيمته للحوكمة أنه لا يمنح كلمة «عضو» معنى شاملًا لا يملكه البروتوكول.

ثلاث مجموعات لثلاثة أسئلة

مجموعة CoAP هي مجموعة من نقاط النهاية المضبوطة لاستقبال الرسائل المرسلة إلى عنوان IP متعدد البث ومنفذ UDP مرتبطين بالمجموعة. إنها قائمة وصول شبكي: من يستمع في هذه الوجهة؟ يمكن أن يحمل URI عنوان البث المتعدد أو اسم مضيف للمجموعة، وأن يحدد منفذًا غير المنفذ الافتراضي 5683 عند الحاجة.

مجموعة التطبيق هي نقاط نهاية خادمة تشترك في وظيفة تطبيقية من خلال موارد CoAP. إنها قائمة وظيفية: أي خوادم ينبغي أن تفسر المسار والطريقة بوصفهما عملية لهذا التطبيق؟ قد يظهر اسم المجموعة صراحة في مسار URI، أو يستنتجه المستقبِل من الطلب وسياق النشر.

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

لا تشتق قائمة من أخرى. يسمح RFC 10020 بجميع أنماط العلاقة بينها. قد تستخدم مجموعات تطبيق متعددة مجموعة أمان واحدة لتقليل التخزين وكلفة التحديث. وقد تستخدم مجموعة تطبيق واحدة مجموعات أمان متعددة عندما تختلف الخوارزميات التي يدعمها العملاء. الكيان المكلّف بالضبط هو الذي ينشئ هذه العلاقات بحسب النشر.

وقائمة المرسلين لا تساوي قائمة المستمعين. يقع البروتوكول ضمن Any-Source Multicast، لذلك قد يكون مصدر الطلب عضوًا في مجموعة IP الوجهة أو لا يكون، ولا يفرض النموذج حدًا على عدد المصادر. ومن ثم فإن تحويل «يستمع إلى المجموعة» إلى «مسموح له بالإرسال» يضيف قاعدة لا يوفرها النقل.

التحقق من الهوية لا يمنح المورد

يستخدم الاتصال المحمي Group OSCORE المعرّف في RFC 10021. وهو يبني على OSCORE في RFC 8613، ويستخدم بنى COSE مثل المحددة في RFC 9052 لحماية رسائل CoAP في طبقة التطبيق. يوقّع المرسل بمفتاحه الخاص في نمط المجموعة، بينما يشتق النمط الثنائي مفاتيح للاتصال واحدًا إلى واحد.

الضمان الناتج قوي لكنه محدود. يستطيع المستقبِل إثبات أن نقطة نهاية محددة ومعروفة، وهي عضو في مجموعة OSCORE، قد أنشأت الرسالة. لا توفر المادة المتماثلة المشتركة وحدها سوى تحقق على مستوى المجموعة، ويضيف Group OSCORE توثيق المصدر. ومع ذلك، فهو لا يوثق عنوان IP أو منفذ UDP الذي جاءت منه الحزمة.

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

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

يمكن لإطار ACE في RFC 9200 أن يساند عملية طلب نقطة النهاية إذنًا للانضمام لدى Group Manager. لكن الإذن بالحصول على مواد المجموعة لا يعني تلقائيًا الإذن باستخدام كل مورد تحميه تلك المواد. إذن الانضمام وصحة الرسالة وإذن العملية تحتاج إلى سجلات مستقلة.

يبدأ اختلاف القوائم قبل التركيب أحيانًا

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

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

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

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

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

الصمت ليس إيصالًا بعدم التنفيذ

تغير الطلبات الجماعية طبيعة الدليل المستمد من الردود. يرسل العميل طلبًا واحدًا بالبث المتعدد، ويرد كل خادم عادة عبر بث أحادي. ولمنع ازدحام الشبكات المقيدة وانفجار الردود، تكون طلبات المجموعة Non-confirmable، ويوزع الخادم رده ضمن نافذة عشوائية تسمى Leisure. وتظل قيود NSTART وPROBING_RATE سارية.

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

قد يعني غياب الرد ضياع الطلب، أو عدم انطباق المورد، أو حجب جواب الرفض، أو انتظار Leisure، أو ضياع الرد، أو تنفيذ العملية من دون رد. وإذا أعاد العميل الطلب بمعرّف Message ID جديد، فقد يعالجه مرة ثانية خادم عالج النسخة الأولى. عدد الردود ليس عدد الآثار.

هنا تظهر قيمة أولوية الكود العامل عند Heng Lu. تصف القوائم الثلاث ما أراد النظام الوصول إليه وتشغيله وحمايته. وتصف الملاحظة ما فعله النشر الفعلي. تحتاج الحوكمة إلى وصل الإعلان بالتنفيذ لا إلى إخفاء أحدهما في الآخر.

إيصال ترخيص بثلاثة سجلات

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

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

يسجل القسم الثالث مجموعة الأمان: Group Manager، ومعرف المجموعة، والخوارزميات، وهوية المرسل الموثقة، وحقبة OSCORE، ودليل الانضمام، وحالة المغادرة، وآخر إعادة للمفاتيح ومدى اكتمالها. ويبقى توثيق المرسل منفصلًا عن التحقق من عنوانه الشبكي. وعندما يلزم إثبات إمكانية الوصول إلى العنوان، يساعد خيار Echo في RFC 9175 على التحقق من أن الطالب الموثق قابل للوصول في العنوان الذي ادعاه.

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

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

الحماية تقلص التضخيم ولا تلغيه

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

يقلل Group OSCORE مساحة الهجوم بتوثيق المرسل وحماية المسار والاستعلام، وتضيف حدود الرد وخيار Echo وسائل أخرى. لكنه لا يلغي عضوًا داخليًا خبيثًا، ولا خصمًا على المسار، ولا أثر العدد والحجم في الردود المشروعة.

توفر فكرة مرآة السياسات لدى Heng Lu معيارًا أفضل للواجهة: عليها أن تعرض توزيع التحكم الحقيقي. العنوان والمورد وGroup Manager والترخيص وحجب الرد والملاحظة لها أصحاب مختلفون. لا توضح عبارة «المجموعة آمنة» أي مسؤولية تحققت.

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

المصادر