Résumé

  • L’IR 8625 définitif du NIST examine la sécurité du RAN Intelligent Controller (RIC). L’agence l’a annoncé le 8 octobre, en même temps qu’un projet distinct destiné aux déploiements O-RAN des agences fédérales.
  • O-RAN s’appuie sur TLS mutuel pour authentifier les composants et sur OAuth2 pour les autoriser, mais l’Alliance ne fixe ni le format ni la granularité des portées OAuth2. C’est l’opérateur qui choisit si un droit vise un actif, une API ou une action précise.
  • Un service central de décision facilite la mise à jour des règles, mais chaque demande d’accès dépend alors de sa disponibilité et l’accès d’applications relevant d’un autre domaine administratif devient plus complexe.

Une xApp peut-elle lire une politique du réseau radio sans pouvoir la modifier ni la supprimer ? Le rapport final du NIST en fait un exemple utile de granularité OAuth2, tout en laissant à l’organisation qui exploite le réseau le soin de trancher.

Le 8 octobre, le NIST a annoncé deux publications consacrées à O-RAN, aux fonctions différentes. L’IR 8625 final examine les exigences de sécurité du contrôleur RAN en temps quasi réel et de ses applications. L’IR 8623 est un projet de profil distinct pour les agences fédérales. Le présent article ne reprend pas la question du risque institutionnel abordée par ce projet : il examine la répartition de l’autorité d’autorisation au sein d’un réseau radio programmable.

Le RIC fournit aux applications un cadre pour surveiller et gérer les ressources du réseau d’accès radio. Le NIST décrit le Near-RT RIC comme opérant sur un sous-ensemble de cellules, avec des délais de réponse opérationnels inférieurs à une seconde. Le Non-RT RIC traite des données plus larges et des contrôles à un rythme plus lent. Les xApps fonctionnent dans le premier, les rApps dans le second. Une rApp peut analyser les mesures de plusieurs cellules, puis transmettre une règle aux xApps pour un ajustement plus rapide.

Cette souplesse donne aussi à des logiciels le pouvoir d’influer sur le comportement du réseau. L’analyse des menaces du NIST relève que des applications tierces peuvent recueillir des informations sur le RAN et les transmettre à d’autres composants, y compris hors du réseau. Une identité usurpée, des privilèges excessifs, une donnée modifiée ou une application mal configurée peuvent donc dépasser le seul processus logiciel concerné. Il s’agit de catégories de menaces, pas d’incidents signalés ni de constats sur un opérateur en activité.

Le rapport décrit TLS mutuel avec certificats X.509 pour l’authentification et les jetons d’accès OAuth2 pour l’autorisation. La portée d’un jeton indique les privilèges associés à une ressource ; celle-ci, ou un point de contrôle des règles, vérifie si l’opération demandée est permise. Le demandeur, la ressource et le serveur d’autorisation doivent partager le même sens de cette portée. Or O-RAN ALLIANCE ne prescrit pas encore de format. Les exemples du NIST vont de l’accès à un actif entier à une API donnée, puis à un appel individuel : lire une politique sans pouvoir la créer ou la supprimer.

L’organisation qui déploie le réseau choisit cette granularité selon ses règles de confiance zéro et sa maturité opérationnelle. Le choix n’est pas anodin. Un droit large facilite l’intégration d’une application, mais peut aussi autoriser des opérations inutiles à sa tâche. Des droits plus fins limitent les actions possibles, à condition que le demandeur, la ressource et le service d’autorisation s’accordent sur leur vocabulaire, leur propriétaire et leur durée de vie. Le NIST ne prétend ni que les opérateurs suivent tous le même modèle ni qu’une mise en œuvre soit certifiée.

Dans une architecture cloud-native, des composants de plateforme, par exemple un maillage de services, peuvent prendre en charge l’authentification et l’autorisation à la place du code métier de chaque application. Cette séparation peut uniformiser les contrôles. Le NIST décrit aussi un point central de décision : il simplifie les mises à jour de règles et la collecte d’informations sur les accès et l’état de sécurité. La contrepartie est nette. Si ce point est indisponible, les demandes d’accès dans le RAN ne peuvent pas y être autorisées.

Cela ne prouve pas que le service radio s’interromprait : le rapport identifie une dépendance d’autorisation, pas une panne du réseau.

La frontière s’élargit lorsqu’une application relève d’un autre domaine administratif. Le NIST cite une rApp fournie en logiciel-service : le point central d’un opérateur peut ne pas disposer du contexte nécessaire pour évaluer un acteur extérieur. Un jeton ne contient pas toujours les informations relatives à la posture ou au comportement récents du demandeur. Qui atteste l’identité de l’application, qui peut modifier ses droits et quelle autorité voit les éléments utiles restent des questions de déploiement.

Le NIST distingue enfin la protection du canal de celle des données. TLS mutuel protège la communication entre composants. Dans un flux cloud-native, un stockage partagé ou un courtier de messages peut s’interposer entre le producteur et le consommateur d’une politique ou d’une mesure. Des signatures ou un chiffrement appliqués à l’objet peuvent préserver son origine, son intégrité ou sa confidentialité malgré ces intermédiaires, mais obligent producteurs et consommateurs à gérer les clés et à vérifier les artefacts. L’IR 8625 présente ce point comme un sujet d’analyse, pas comme une obligation de remplacer la sécurité des canaux.

La conclusion du rapport est circonscrite : les protocoles normalisés rendent possibles les contrôles zéro confiance, sans décider du sens des permissions choisies par l’opérateur ni supprimer sa responsabilité quant à la continuité de l’autorisation et à la confiance entre domaines. Les sources ne citent aucune mise en œuvre particulière, intrusion, défaillance de politique ou mesure d’effet sur la disponibilité.

Sources