في البنية المعتمدة على الخدمات لشبكات الجيل الخامس، يمكن لوظيفة AMF اكتشاف نقطة نهاية SBI التابعة لوظيفة UDM أو SMF، لكن الاكتشاف وحده لا يمنحها الإذن باسترجاع بيانات المشترك أو إنشاء جلسة PDU. تجعل الاتصالات المعتمدة على الخدمات التفاعل بين وظائف الشبكة أكثر مرونة، لكنها تكشف في الوقت نفسه نطاقًا أوسع من واجهات برمجة تطبيقات الشبكة الأساسية. وإذا عالج منتج خدمة NF كل طلب يمكن الوصول إليه من دون التحقق من التفويض، فلن يتمكن من تحديد ما إذا كان المتصل شرعيًا أو مسجلًا أو مخولًا باستخدام الخدمة المطلوبة بصورة موثوقة.
تعالج شبكة 5GC هذه المشكلة من خلال نموذج تفويض قائم على OAuth 2.0. يطلب مستهلك خدمة NF أولًا رمز وصول من NRF، ثم يقدمه عند استدعاء منتج خدمة NF المستهدف. ولا ينفذ المنتج العملية المطلوبة إلا بعد التحقق من الرمز ومن مطالبات التفويض التي يتضمنها. وفي هذا النموذج، لا يعمل NRF كسجل ووظيفة اكتشاف فحسب، بل يعمل أيضًا كخادم تفويض للوصول المحمي إلى SBI.
مخاطر استدعاءات SBI غير المحمية
تستخدم شبكات الجيل الخامس المستقلة بنية معتمدة على الخدمات، حيث تعرض وظائف الشبكة مثل AMF وSMF وUDM وAUSF خدمة واحدة أو أكثر عبر واجهات قائمة على HTTP/2. ويمكن للمستهلك استدعاء هذه الخدمات من خلال واجهات HTTP API موحدة، مما يقلل الاعتماد الصارم على الاتصالات من نقطة إلى نقطة ويتيح إنشاء علاقات الخدمة بصورة ديناميكية.
فعلى سبيل المثال، أثناء تسجيل UE قد تستدعي AMF خدمة Nudm_SDM التابعة لـ UDM للحصول على معلومات الاشتراك. وأثناء إنشاء جلسة PDU قد تستدعي AMF خدمة Nsmf_PDUSession التابعة لـ SMF لإنشاء سياق إدارة الجلسة. وتتضمن كلتا العمليتين معلومات حساسة عن المشترك أو موارد مهمة في الشبكة الأساسية.
إذا أعادت UDM بيانات الاشتراك لمجرد وصول الطلب إلى URI الصحيح، فلن يكون لديها ما يضمن أن الجهة المتصلة هي AMF مخولة. وبالمثل، قد تقبل SMF التي تنشئ جلسة من دون التحقق من مقدم الطلب استدعاءات صادرة عن وظيفة شبكة غير موثوقة أو مضبوطة بصورة خاطئة. إن إمكانية الوصول إلى نقطة النهاية تؤكد فقط أن الاتصال ممكن من الناحية التقنية، لكنها لا تثبت الهوية أو التفويض.
يزداد هذا الخطر في البيئات السحابية الأصلية. فقد يتم إنشاء مثيلات NF أو توسيعها أو تقليصها أو ترقيتها أو نقلها أو إزالتها مع تغير المتطلبات التشغيلية. كما يستطيع مستهلك الخدمة اختيار مثيلات مختلفة للمنتج عن طريق الاكتشاف القائم على NRF. لذلك لا تكفي العناوين الثابتة وإعدادات الأقران المحددة مسبقًا للتحكم في كل طلب خدمة على حدة.
تفصل 5GC بين اكتشاف الخدمة وتفويض الخدمة. يجيب الاكتشاف عن مكان توفر الخدمة المناسبة، بينما يحدد التفويض ما إذا كان مسموحًا للمستهلك الحالي باستخدامها. وقبل معالجة طلب الخدمة الفعلي، يجب على المستهلك الحصول على بيانات اعتماد مرتبطة بالخدمة المقصودة، كما يجب على المنتج التحقق منها.
NRF بوصفه خادم التفويض
OAuth 2.0 هو إطار تفويض عام للتحكم في الوصول بين التطبيقات، وليس مخصصًا لشبكات الهاتف المحمول. ويحدد نموذجه القياسي ثلاثة أدوار رئيسية: العميل الذي يطلب الوصول، وخادم التفويض الذي يصدر الرمز، وخادم الموارد الذي يحمي المورد أو الخدمة المطلوبة.
في نموذج أمان SBI ضمن 5GC، تتوافق هذه الأدوار مباشرة مع سلوك وظائف الشبكة:
| دور OAuth 2.0 | كيان 5GC | المسؤولية الرئيسية |
|---|---|---|
| العميل | مستهلك خدمة NF | يطلب رمز وصول ويبدأ استدعاء الخدمة |
| خادم الموارد | منتج خدمة NF | يوفر خدمة SBI ويتحقق من الرمز المقدم |
| خادم التفويض | NRF | يقيّم الطلب ويصدر رمز وصول محدود النطاق |
عندما تحتاج AMF إلى استدعاء خدمة UDM، تعمل AMF بوصفها مستهلك خدمة NF، وتعمل UDM بوصفها منتج الخدمة، بينما يوفر NRF وظيفة التفويض. تحصل AMF على رمز قبل استدعاء Nudm_SDM. وبعد ذلك تتحقق UDM من صلاحية الرمز ومن أن المطالبات الواردة فيه تسمح بالوصول إلى الخدمة المطلوبة.
لدعم هذه العملية، يتيح NRF خدمة Nnrf_AccessToken. ويمكن أن يتضمن طلب الرمز معلومات مثل هوية المستهلك واسم الخدمة المطلوبة ونوع NF المستهدفة ونوع NF المستهلكة ومعرف العميل. وبعد تقييم الطلب، يعيد NRF رمز وصول إلى جانب معلومات مرتبطة به مثل نوع الرمز ومدة صلاحيته.
لا ينفذ NRF عملية الخدمة المطلوبة. فهو يحدد سياق التفويض ويصدر بيانات اعتماد الوصول. وتظل مسؤولية استرجاع بيانات المشترك وإنشاء الجلسات والعمليات الأخرى الخاصة بالخدمة على عاتق منتج خدمة NF المعني.
تدفق الوصول إلى الخدمة القائم على الرمز
يمكن تقسيم إجراء الوصول إلى خدمات NF المحدد في 5GC إلى مرحلتين. يحصل المستهلك أولًا على رمز وصول من NRF، ثم يقدمه إلى المنتج المستهدف عند طلب الخدمة الفعلية. ويمنع هذا الفصل انتقال طلب غير متحقق منه مباشرة إلى معالجة الخدمة الفعلية.
طلب رمز وصول
يجب أن يمتلك مستهلك خدمة NF أولًا هوية صالحة وسياق تسجيل متاحًا لدى NRF. ثم يستدعي Nnrf_AccessToken ويحدد الخدمة التي يريد الوصول إليها ونوع NF المستهدفة ومعلوماته بصفته مستهلكًا.
يقيّم NRF الطلب بالاستناد إلى بيانات التسجيل المتاحة وسياسة التفويض. وإذا تمت الموافقة على التفويض، ينشئ رمز وصول ويعيده إلى المستهلك. وفي هذه المرحلة لا يكون قد تم تنفيذ أي استعلام عن المشترك أو إنشاء جلسة أو أي عملية خدمة فعلية أخرى. ويكون المستهلك قد حصل فقط على إذن بمحاولة استدعاء الخدمة المحمية.
استدعاء الخدمة المحمية
يرسل المستهلك طلب الخدمة الفعلي إلى منتج خدمة NF ويضمن رمز الوصول في ترويسة HTTP Authorization. وقبل معالجة الطلب، يتحقق المنتج من سلامة الرمز ومدة صلاحيته ومطالبات التفويض الخاصة به. ولا تُنفذ الخدمة المطلوبة إلا عند نجاح جميع عمليات التحقق.
لنأخذ إنشاء جلسة PDU مثالًا. ترسل AMF أولًا طلب HTTP/2 POST إلى خدمة Nnrf_AccessToken التابعة لـ NRF، وتوضح أنها تحتاج إلى الوصول إلى خدمة Nsmf_PDUSession التابعة لـ SMF. وبعد إتمام التفويض، يعيد NRF الرمز في استجابة HTTP 200 OK.
ثم ترسل AMF طلب Nsmf_PDUSession إلى SMF المختارة وتضمنه الرمز. وتتحقق SMF من بيانات الاعتماد قبل إنشاء سياق إدارة جلسة PDU. وإذا تم قبول الطلب وإنشاء السياق بنجاح، يمكن لـ SMF إعادة استجابة HTTP 201 Created.
يضع هذا التسلسل التفويض قبل تنفيذ الخدمة الفعلية. فمعرفة عنوان SMF ومسار API ليست كافية. ومن دون رمز صالح يشمل الخدمة المقصودة، يجب ألا يُسمح لمقدم الطلب بمتابعة إنشاء الجلسة بالطريقة المعتادة.
النطاق وحدود التصميم
يرتبط اكتشاف الخدمات القائم على NRF بالتفويض القائم على NRF، لكنهما قدرتان منفصلتان. يحدد الاكتشاف مثيلات المنتج المتاحة والخدمات التي تدعمها، بينما يقرر التفويض ما إذا كان يحق لمستهلك معين استدعاء إحدى هذه الخدمات. ولا يلغي إكمال الاكتشاف الحاجة إلى الحصول على رمز مناسب.
كما أن رمز الوصول لا يحل محل بيانات الخدمة الفعلية. فعند إصدار الرمز، لا يسترجع NRF معلومات الاشتراك من UDM ولا ينشئ جلسة في SMF. وإنما يقدم دليلًا على أن المستهلك حصل على التفويض ضمن نطاق محدد. ويظل المنتج مسؤولًا عن معالجة الطلب وإنشاء الاستجابة.
يتطلب التنفيذ الآمن فرض التحقق من جهة المنتج. فإلزام المستهلك بطلب رمز لا يوفر حماية كافية إذا لم يتحقق المنتج من سلامة الرمز وانتهاء صلاحيته ومطالباته قبل تنفيذ الخدمة. ولذلك يجب أن يتبع المستهلك وNRF والمنتج قواعد متوافقة لمعالجة الرموز.
يقتصر التفويض كذلك على نطاق ومدة زمنية. فالرمز الصادر لخدمة SBI واحدة لا يمنح تلقائيًا وصولًا غير محدود إلى جميع الواجهات التي تعرضها وظائف الشبكة الأخرى. ويجب ألا تُعامل الرموز المنتهية الصلاحية أو التي لا تتوافق مطالباتها مع الخدمة المستهدفة بوصفها بيانات اعتماد صالحة.
وبذلك يدعم NRF وظيفتين منفصلتين متعلقتين بالأمان في شبكة الجيل الخامس الأساسية. فهو يحتفظ بملفات NF ويدعم اكتشاف الخدمات، مما يساعد المستهلكين على العثور على المنتج المناسب. ومن خلال Nnrf_AccessToken، يتحكم أيضًا في ما إذا كان هؤلاء المستهلكون مخولين باستدعاء خدمات SBI المحمية.
الأسئلة الشائعة
هل يمكن لرمز الوصول أن يحل محل تسجيل NF؟
لا. يحدد تسجيل NF هوية المثيل وملف الخدمة الخاص به، بينما يوفر رمز الوصول تفويضًا لسياق محدد للوصول إلى الخدمة. ويؤدي التسجيل وإصدار الرمز وظيفتين مختلفتين.
هل يمكن استخدام رمز واحد مع عدة مثيلات NF؟
يعتمد ذلك على مطالبات الرمز ونوع NF المستهدفة ونطاق الخدمة وسياسة التفويض المطبقة. ويجب على كل منتج التحقق من أن الرمز صالح للطلب الحالي بدلًا من قبوله لمجرد أن صلاحيته لم تنته بعد.
هل تتوقف الرموز الحالية عن العمل فورًا عندما يصبح NRF غير متاح؟
يعتمد السلوك على تنسيق الرمز ومدة صلاحيته وطريقة التحقق لدى المنتج وسياسة النشر. ولا يؤدي تعطل NRF مؤقتًا إلى تحديد حالة جميع الرموز الصادرة سابقًا بصورة تلقائية، لكن طلبات الرموز الجديدة قد تتأثر.
هل يقوم OAuth 2.0 بتشفير محتوى رسائل SBI؟
لا. يوفر OAuth 2.0 بصورة أساسية التفويض والتحكم في الوصول. أما حماية نقل SBI فتتم بآليات أمان منفصلة مثل TLS. ولا ينبغي اعتبار رمز الوصول الصالح بديلًا عن النقل المشفر.
