Dans l’architecture 5G fondée sur les services, une AMF peut découvrir le point de terminaison SBI d’une UDM ou d’une SMF, mais cette découverte ne lui donne pas à elle seule l’autorisation de récupérer des données d’abonné ou de créer une session PDU. La communication orientée services assouplit les interactions entre fonctions réseau, tout en exposant un ensemble plus large d’API du cœur de réseau. Si un producteur de services NF traite toute requête joignable sans contrôle d’autorisation, il ne peut pas déterminer de manière fiable si l’appelant est légitime, enregistré ou autorisé à utiliser le service demandé.
Le 5GC répond à ce problème au moyen d’un modèle d’autorisation basé sur OAuth 2.0. Un consommateur de services NF demande d’abord un jeton d’accès au NRF, puis présente ce jeton lorsqu’il appelle le producteur de services NF cible. Le producteur n’exécute l’opération demandée qu’après avoir validé le jeton et ses revendications d’autorisation. Dans ce modèle, le NRF agit non seulement comme registre et fonction de découverte, mais également comme serveur d’autorisation pour l’accès SBI protégé.
Risques des appels SBI non protégés
Les réseaux 5G autonomes utilisent une architecture fondée sur les services, dans laquelle des fonctions réseau telles que l’AMF, la SMF, l’UDM et l’AUSF exposent un ou plusieurs services au moyen d’interfaces basées sur HTTP/2. Un consommateur peut invoquer ces services via des API HTTP normalisées, ce qui réduit les dépendances point à point étroites et permet d’établir dynamiquement des relations de service.
Lors de l’enregistrement du UE, par exemple, l’AMF peut appeler le service Nudm_SDM de l’UDM afin d’obtenir les informations d’abonnement. Lors de l’établissement d’une session PDU, l’AMF peut appeler le service Nsmf_PDUSession de la SMF afin de créer un contexte de gestion de session. Ces deux procédures concernent des informations sensibles sur l’abonné ou des ressources critiques du cœur de réseau.
Si l’UDM renvoie les données d’abonnement uniquement parce que la requête atteint le bon URI, rien ne garantit que l’appelant est une AMF autorisée. De même, une SMF qui crée une session sans valider le demandeur pourrait accepter des appels provenant d’une fonction réseau non fiable ou mal configurée. La joignabilité du point de terminaison confirme seulement que la communication est techniquement possible ; elle n’établit ni l’identité ni l’autorisation.
Le risque devient plus important dans les déploiements cloud natifs. Les instances NF peuvent être créées, mises à l’échelle, mises à niveau, déplacées ou supprimées selon l’évolution des besoins opérationnels. Un consommateur de services peut également sélectionner différentes instances productrices par l’intermédiaire de la découverte fondée sur le NRF. Les adresses statiques et les configurations fixes entre pairs sont donc insuffisantes pour contrôler chaque requête de service.
Le 5GC sépare la découverte de services de l’autorisation de services. La découverte indique où un service adapté est disponible. L’autorisation détermine si le consommateur actuel est autorisé à l’utiliser. Avant le traitement de la requête métier, le consommateur doit obtenir un justificatif associé au service visé et le producteur doit le valider.
Le NRF comme serveur d’autorisation
OAuth 2.0 est un cadre général d’autorisation destiné à contrôler les accès entre applications. Il n’est pas propre aux réseaux mobiles. Son modèle standard définit trois rôles principaux : le client qui demande l’accès, le serveur d’autorisation qui émet un jeton et le serveur de ressources qui protège la ressource ou le service demandé.
Dans le modèle de sécurité SBI du 5GC, ces rôles correspondent directement au comportement des fonctions réseau :
| Rôle OAuth 2.0 | Entité 5GC | Responsabilité principale |
|---|---|---|
| Client | Consommateur de services NF | Demande un jeton d’accès et lance l’appel de service |
| Serveur de ressources | Producteur de services NF | Fournit le service SBI et valide le jeton présenté |
| Serveur d’autorisation | NRF | Évalue la requête et émet un jeton d’accès limité à une portée définie |
Lorsqu’une AMF doit appeler un service UDM, l’AMF agit comme consommateur de services NF, l’UDM comme producteur de services NF et le NRF fournit la fonction d’autorisation. L’AMF obtient un jeton avant d’appeler Nudm_SDM. L’UDM vérifie ensuite que le jeton est valide et que ses revendications autorisent l’accès au service demandé.
Pour prendre en charge ce processus, le NRF expose le service Nnrf_AccessToken. Une demande de jeton peut inclure l’identité du consommateur, le nom du service demandé, le type de NF cible, le type de NF consommateur et l’identifiant du client. Après avoir évalué la requête, le NRF renvoie un jeton d’accès accompagné d’informations telles que le type de jeton et sa durée de validité.
Le NRF n’exécute pas l’opération métier demandée. Il définit le contexte d’autorisation et émet le justificatif d’accès. La récupération des données d’abonné, la création de sessions et les autres opérations propres à un service restent sous la responsabilité du producteur de services NF concerné.
Flux d’accès aux services fondé sur les jetons
La procédure d’accès aux services NF définie pour le 5GC peut être divisée en deux étapes. Le consommateur obtient d’abord un jeton d’accès auprès du NRF, puis le présente au producteur cible lorsqu’il demande le service réel. Cette séparation empêche une requête non vérifiée de passer directement au traitement métier.
Demande d’un jeton d’accès
Le consommateur de services NF doit d’abord disposer d’une identité valide et d’un contexte d’enregistrement accessible au NRF. Il appelle ensuite Nnrf_AccessToken et indique le service auquel il souhaite accéder, le type de NF cible ainsi que ses propres informations de consommateur.
Le NRF évalue la demande au regard des données d’enregistrement disponibles et de la politique d’autorisation. Si l’autorisation est accordée, il génère un jeton d’accès et le renvoie au consommateur. À ce stade, aucune consultation d’abonné, création de session ou autre opération métier n’a encore été exécutée. Le consommateur a seulement reçu l’autorisation de tenter l’appel du service protégé.
Appel du service protégé
Le consommateur envoie la requête métier au producteur de services NF et inclut le jeton d’accès dans l’en-tête HTTP Authorization. Avant de traiter la requête, le producteur vérifie l’intégrité du jeton, sa période de validité et ses revendications d’autorisation. Le service demandé n’est exécuté que si ces contrôles réussissent.
Prenons l’exemple de l’établissement d’une session PDU. L’AMF envoie d’abord une requête HTTP/2 POST au service Nnrf_AccessToken du NRF, en indiquant qu’elle doit accéder au service Nsmf_PDUSession de la SMF. Après autorisation, le NRF renvoie le jeton dans une réponse HTTP 200 OK.
L’AMF envoie ensuite la requête Nsmf_PDUSession à la SMF sélectionnée et y joint le jeton. La SMF valide le justificatif avant de créer le contexte de gestion de session PDU. Si la requête est acceptée et le contexte créé avec succès, la SMF peut renvoyer une réponse HTTP 201 Created.
Cette séquence place l’autorisation avant l’exécution métier. Connaître l’adresse de la SMF et le chemin de l’API ne suffit pas. Sans jeton valide couvrant le service visé, le demandeur ne doit pas être autorisé à poursuivre la création normale de la session.
Portée et limites de conception
La découverte de services fondée sur le NRF et l’autorisation fondée sur le NRF sont liées, mais constituent deux capacités distinctes. La découverte identifie les instances productrices disponibles et les services qu’elles prennent en charge. L’autorisation décide si un consommateur donné peut appeler l’un de ces services. L’achèvement de la découverte ne dispense pas d’obtenir un jeton approprié.
Le jeton d’accès ne remplace pas non plus les données métier. Le NRF ne récupère pas les informations d’abonnement de l’UDM et ne crée pas de session SMF lorsqu’il émet un jeton. Il fournit la preuve que le consommateur a été autorisé dans une portée définie. Le producteur reste responsable du traitement de la requête et de la génération de la réponse.
Une mise en œuvre sécurisée exige un contrôle effectif côté producteur. Obliger le consommateur à demander un jeton apporte peu de protection si le producteur ne valide pas l’intégrité, l’expiration et les revendications du jeton avant d’exécuter le service. Le consommateur, le NRF et le producteur doivent donc appliquer des règles compatibles de traitement des jetons.
L’autorisation est également limitée dans sa portée et dans le temps. Un jeton émis pour un service SBI ne donne pas automatiquement un accès illimité à toutes les interfaces exposées par d’autres fonctions réseau. Les jetons expirés ou dont les revendications ne correspondent pas au service cible ne doivent pas être considérés comme des justificatifs valides.
Le NRF prend ainsi en charge deux fonctions distinctes liées à la sécurité dans le cœur 5G. Il maintient les profils NF et facilite la découverte de services, ce qui aide les consommateurs à trouver les producteurs appropriés. Par l’intermédiaire de Nnrf_AccessToken, il contrôle également si ces consommateurs sont autorisés à invoquer des services SBI protégés.
Questions fréquentes
Un jeton d’accès peut-il remplacer l’enregistrement NF ?
Non. L’enregistrement NF établit l’identité de l’instance et son profil de service. Un jeton d’accès fournit l’autorisation pour un contexte défini d’accès à un service. L’enregistrement et l’émission de jetons répondent à des objectifs différents.
Un même jeton peut-il être utilisé avec plusieurs instances NF ?
Cela dépend des revendications du jeton, du type de NF cible, de la portée du service et de la politique d’autorisation applicable. Chaque producteur doit vérifier que le jeton est valable pour la requête en cours, au lieu de l’accepter uniquement parce qu’il n’a pas encore expiré.
Les jetons existants cessent-ils immédiatement de fonctionner lorsque le NRF est indisponible ?
Le comportement dépend du format du jeton, de sa période de validité, de la méthode de vérification côté producteur et de la politique de déploiement. Une indisponibilité temporaire du NRF ne détermine pas automatiquement l’état de tous les jetons déjà émis, mais les nouvelles demandes de jeton peuvent être affectées.
OAuth 2.0 chiffre-t-il le contenu des messages SBI ?
Non. OAuth 2.0 assure principalement l’autorisation et le contrôle d’accès. La protection du transport SBI repose sur des mécanismes de sécurité distincts, tels que TLS. Un jeton d’accès valide ne doit pas être considéré comme un substitut au transport chiffré.
