En la arquitectura basada en servicios de 5G, una AMF puede descubrir el punto final SBI de una UDM o una SMF, pero el descubrimiento por sí solo no concede permiso para recuperar datos de abonados ni para crear una sesión PDU. La comunicación basada en servicios flexibiliza las interacciones entre las funciones de red, pero también expone un conjunto más amplio de API del núcleo. Si un productor de servicios NF procesa todas las solicitudes accesibles sin verificar la autorización, no puede determinar con fiabilidad si quien llama es legítimo, está registrado o tiene permiso para utilizar el servicio solicitado.
5GC resuelve este problema mediante un modelo de autorización basado en OAuth 2.0. Un consumidor de servicios NF solicita primero un token de acceso al NRF y después lo presenta al llamar al productor de servicios NF de destino. El productor ejecuta la operación solicitada únicamente después de validar el token y sus declaraciones de autorización. En este modelo, el NRF no solo actúa como registro y función de descubrimiento, sino también como servidor de autorización para el acceso protegido a la SBI.
Riesgos de las llamadas SBI sin protección
Las redes 5G autónomas utilizan una arquitectura basada en servicios, en la que funciones de red como AMF, SMF, UDM y AUSF exponen uno o varios servicios mediante interfaces basadas en HTTP/2. Un consumidor puede invocar esos servicios a través de API HTTP normalizadas, lo que reduce las dependencias rígidas punto a punto y permite crear relaciones de servicio de forma dinámica.
Durante el registro del UE, por ejemplo, la AMF puede llamar al servicio Nudm_SDM de la UDM para obtener información de suscripción. Durante el establecimiento de una sesión PDU, la AMF puede llamar al servicio Nsmf_PDUSession de la SMF para crear un contexto de gestión de sesión. Ambos procedimientos implican información sensible del abonado o recursos críticos de la red central.
Si la UDM devuelve datos de suscripción únicamente porque la solicitud ha llegado al URI correcto, no tiene ninguna garantía de que el llamante sea una AMF autorizada. Del mismo modo, una SMF que cree una sesión sin validar al solicitante podría aceptar llamadas de una función de red no fiable o configurada de forma incorrecta. La accesibilidad del punto final solo confirma que la comunicación es técnicamente posible; no demuestra la identidad ni la autorización.
El riesgo aumenta en despliegues nativos de la nube. Las instancias NF pueden crearse, escalarse, actualizarse, trasladarse o eliminarse a medida que cambian las necesidades operativas. Un consumidor de servicios también puede seleccionar distintas instancias productoras mediante el descubrimiento basado en el NRF. Por ello, las direcciones estáticas y las configuraciones fijas entre pares no bastan para controlar cada solicitud de servicio.
5GC separa el descubrimiento de servicios de la autorización de servicios. El descubrimiento responde dónde está disponible un servicio adecuado. La autorización determina si el consumidor actual puede utilizarlo. Antes de procesar la solicitud de negocio, el consumidor debe obtener una credencial vinculada al servicio previsto y el productor debe validarla.
El NRF como servidor de autorización
OAuth 2.0 es un marco general de autorización para el acceso controlado entre aplicaciones; no es exclusivo de las redes móviles. Su modelo estándar define tres funciones principales: el cliente que solicita acceso, el servidor de autorización que emite un token y el servidor de recursos que protege el recurso o servicio solicitado.
En el modelo de seguridad SBI de 5GC, estas funciones se corresponden directamente con el comportamiento de las funciones de red:
| Función de OAuth 2.0 | Entidad 5GC | Responsabilidad principal |
|---|---|---|
| Cliente | Consumidor de servicios NF | Solicita un token de acceso e inicia la llamada al servicio |
| Servidor de recursos | Productor de servicios NF | Presta el servicio SBI y valida el token presentado |
| Servidor de autorización | NRF | Evalúa la solicitud y emite un token de acceso con alcance limitado |
Cuando una AMF necesita llamar a un servicio de la UDM, la AMF actúa como consumidor de servicios NF, la UDM como productor y el NRF proporciona la función de autorización. La AMF obtiene un token antes de llamar a Nudm_SDM. Después, la UDM comprueba si el token es válido y si sus declaraciones permiten acceder al servicio solicitado.
Para respaldar este proceso, el NRF expone el servicio Nnrf_AccessToken. Una solicitud de token puede incluir la identidad del consumidor, el nombre del servicio solicitado, el tipo de NF de destino, el tipo de NF consumidor y el identificador del cliente. Tras evaluar la solicitud, el NRF devuelve un token de acceso junto con información como el tipo de token y su periodo de validez.
El NRF no ejecuta la operación de negocio solicitada. Define el contexto de autorización y emite la credencial de acceso. La recuperación de datos de abonados, la creación de sesiones y otras operaciones específicas siguen siendo responsabilidad del productor de servicios NF correspondiente.
Flujo de acceso a servicios basado en tokens
El procedimiento de acceso a servicios NF definido para 5GC puede dividirse en dos etapas. El consumidor obtiene primero un token de acceso del NRF y luego lo presenta al productor de destino al solicitar el servicio real. Esta separación evita que una solicitud no verificada pase directamente al procesamiento de negocio.
Solicitud de un token de acceso
El consumidor de servicios NF debe disponer primero de una identidad válida y de un contexto de registro accesible para el NRF. A continuación llama a Nnrf_AccessToken e identifica el servicio al que desea acceder, el tipo de NF de destino y su propia información como consumidor.
El NRF evalúa la solicitud según los datos de registro disponibles y la política de autorización. Si se concede la autorización, genera un token de acceso y lo devuelve al consumidor. En ese momento todavía no se ha realizado ninguna consulta de abonado, creación de sesión u otra operación de negocio. El consumidor solo ha recibido permiso para intentar la llamada al servicio protegido.
Llamada al servicio protegido
El consumidor envía la solicitud de negocio al productor de servicios NF e incluye el token de acceso en la cabecera HTTP Authorization. Antes de procesar la solicitud, el productor verifica la integridad del token, su periodo de validez y sus declaraciones de autorización. El servicio solicitado solo se ejecuta cuando todas esas comprobaciones tienen éxito.
Consideremos el establecimiento de una sesión PDU. La AMF envía primero una solicitud HTTP/2 POST al servicio Nnrf_AccessToken del NRF, indicando que necesita acceder al servicio Nsmf_PDUSession de la SMF. Tras la autorización, el NRF devuelve el token en una respuesta HTTP 200 OK.
La AMF envía entonces la solicitud Nsmf_PDUSession a la SMF seleccionada e incluye el token. La SMF valida la credencial antes de crear el contexto de gestión de la sesión PDU. Si la solicitud se acepta y el contexto se crea correctamente, la SMF puede devolver una respuesta HTTP 201 Created.
Esta secuencia sitúa la autorización antes de la ejecución de negocio. Conocer la dirección de la SMF y la ruta de la API no es suficiente. Sin un token válido que cubra el servicio previsto, no se debe permitir que el solicitante continúe con la creación normal de la sesión.
Alcance y límites del diseño
El descubrimiento de servicios basado en el NRF y la autorización basada en el NRF están relacionados, pero son capacidades distintas. El descubrimiento identifica las instancias productoras disponibles y los servicios que admiten. La autorización decide si un consumidor concreto puede llamar a uno de esos servicios. Completar el descubrimiento no elimina la necesidad de obtener un token adecuado.
El token de acceso tampoco sustituye a los datos de negocio. El NRF no recupera información de suscripción de la UDM ni crea una sesión de la SMF cuando emite un token. Proporciona una prueba de que el consumidor ha sido autorizado dentro de un alcance definido. El productor sigue siendo responsable de procesar la solicitud y generar la respuesta.
Una implementación segura exige aplicar los controles en el lado del productor. Exigir al consumidor que solicite un token ofrece poca protección si el productor no valida la integridad, la caducidad y las declaraciones del token antes de ejecutar el servicio. Por tanto, el consumidor, el NRF y el productor deben seguir reglas compatibles de procesamiento de tokens.
La autorización también está limitada por el alcance y el tiempo. Un token emitido para un servicio SBI no concede automáticamente acceso ilimitado a todas las interfaces expuestas por otras funciones de red. Los tokens caducados o cuyas declaraciones no coincidan con el servicio de destino no deben considerarse credenciales válidas.
Por tanto, el NRF admite dos funciones distintas relacionadas con la seguridad en el núcleo 5G. Mantiene perfiles NF y permite el descubrimiento de servicios para ayudar a los consumidores a localizar productores adecuados. A través de Nnrf_AccessToken, también controla si dichos consumidores están autorizados a invocar servicios SBI protegidos.
Preguntas frecuentes
¿Puede un token de acceso sustituir al registro de la NF?
No. El registro de la NF establece la identidad de la instancia y su perfil de servicio. Un token de acceso proporciona autorización para un contexto definido de acceso a servicios. El registro y la emisión de tokens cumplen funciones diferentes.
¿Puede utilizarse un token con varias instancias NF?
Depende de las declaraciones del token, del tipo de NF de destino, del alcance del servicio y de la política de autorización aplicable. Cada productor debe verificar que el token sea válido para la solicitud actual, en lugar de aceptarlo únicamente porque aún no haya caducado.
¿Los tokens existentes fallan inmediatamente cuando el NRF no está disponible?
El comportamiento depende del formato del token, su periodo de validez, el método de verificación del productor y la política de despliegue. Una interrupción temporal del NRF no determina automáticamente el estado de todos los tokens emitidos anteriormente, aunque puede afectar a las nuevas solicitudes de tokens.
¿OAuth 2.0 cifra el contenido de los mensajes SBI?
No. OAuth 2.0 proporciona principalmente autorización y control de acceso. La protección del transporte SBI se gestiona mediante mecanismos de seguridad independientes, como TLS. Un token de acceso válido no debe considerarse un sustituto del transporte cifrado.
