Sécurité pour Azure Private 5G Core
Azure Private 5G Core permet aux fournisseurs de services et aux intégrateurs de systèmes de déployer et de gérer en toute sécurité des réseaux mobiles privés pour une entreprise. Il stocke en toute sécurité la configuration du réseau et la configuration SIM utilisée par les appareils qui se connectent au réseau mobile. Cet article répertorie des détails sur les fonctionnalités de sécurité fournies par Azure Private 5G Core, qui permettent de protéger le réseau mobile.
Azure Private 5G Core se compose de deux composants principaux qui interagissent les uns avec les autres :
- Le service Azure Private 5G Core, hébergé dans Azure, les outils de gestion utilisés pour configurer et surveiller le déploiement.
- Instances de cœur de paquets, hébergées sur des appareils Azure Stack Edge : ensemble complet de fonctions réseau 5G qui fournissent une connectivité aux appareils mobiles à un emplacement de périphérie.
Plateforme sécurisée
Azure Private 5G Core nécessite le déploiement d’instances Packet Core sur une plateforme sécurisée, Azure Stack Edge. Pour plus d’informations sur la sécurité d’Azure Stack Edge, consultez Protection des données et sécurité Azure Stack Edge.
Chiffrement au repos
Le service de base Azure Private 5G Core stocke toutes les données en toute sécurité au repos, y compris les informations d’identification SIM. Il assure le chiffrement des données au repos à l’aide de clés de chiffrement gérées par la plateforme, gérées par Microsoft. Le chiffrement au repos est utilisé par défaut lors de la création d’un groupe SIM.
Les instances Packet Core de base d’Azure Private 5G Core sont déployées sur des appareils Azure Stack Edge, qui gèrent la protection des données.
Chiffrement au repos de clé gérée par le client
Outre le chiffrement par défaut au repos à l’aide de clés gérées par Microsoft (MMK), vous pouvez éventuellement utiliser des clés gérées par le client (CMK) pour chiffrer les données avec votre propre clé.
Si vous choisissez d’utiliser une clé CMK, vous devrez créer un URI de clé dans votre coffre de clés Azure et une identité affectée par l’utilisateur avec un accès Read, Wrap et Unwrap à la clé. Notez les points suivants :
- La clé doit être configurée de manière à avoir une date d’activation et une date d’expiration. Nous vous recommandons de configurer la permutation automatique des clés de chiffrement dans le coffre de clés Azure.
- Le groupe de cartes SIM accède à la clé via l’identité affectée par l’utilisateur.
Pour plus d’informations sur la configuration de CMK, consultez Configurer des clés gérées par le client.
Vous pouvez utiliser Azure Policy pour appliquer l’utilisation de CMK pour les groupes SIM. Pour pus d’informations, consultez Définitions de stratégie Azure Policy pour Azure Private 5G Core.
Important
Une fois qu’un groupe SIM est créé, vous ne pouvez pas changer le type de chiffrement. Toutefois, si le groupe SIM utilise une clé CMK, vous pouvez mettre à jour la clé utilisée pour le chiffrement.
Informations d’identification de SIM en écriture seule
Azure Private 5G Core fournit un accès en écriture seule aux informations d’identification SIM. Les informations d’identification SIM sont les secrets qui autorisent l’accès au réseau pour les UE (équipements utilisateur).
Étant donné que ces informations d’identification sont très sensibles, Azure Private 5G Core n’autorise pas les utilisateurs du service à accéder en lecture aux informations d’identification, sauf si la loi l’exige. Les utilisateurs avec suffisamment de privilèges peuvent remplacer les informations d’identification ou les révoquer.
Chiffrement du NAS
La signalisation Non-access stratum (NAS) s’exécute entre l’UE et l’AMF (5G) ou MME (4G). Il contient les informations permettant d’autoriser les opérations de gestion de session et de mobilité qui permettent la connectivité du plan de données entre l’UE et le réseau.
Le cœur de paquets effectue un chiffrement et une protection de l’intégrité de la NAS. Pendant l’inscription d’un UE, l’UE comprend ses fonctionnalités de sécurité pour le NAS avec des clés 128 bits. Pour le chiffrement, par défaut, Azure Private 5G Core prend en charge les algorithmes suivants dans l’ordre de préférence :
- NEA2/EEA2 : Chiffrement AES (Advanced Encryption System) 128 bits
- NEA1/EEA1 : 128 bits Snow 3G
- NEA0/EEA0 : Algorithme de chiffrement null 5GS
Cette configuration permet le niveau de chiffrement le plus élevé pris en charge par l’UE tout en autorisant les UE qui ne prennent pas en charge le chiffrement. Pour rendre le chiffrement obligatoire, vous pouvez interdire NEA0/EEA0, empêchant les UE qui ne prennent pas en charge le chiffrement NAS de s’inscrire auprès du réseau.
Vous pouvez modifier ces préférences après le déploiement en modifiant la configuration principale du cœur de paquets.
Authentification RADIUS
Azure Private 5G Core prend en charge l’authentification avec le protocole RADIUS (Remote Authentication Dial-In User Service). Vous pouvez configurer le cœur de paquets pour contacter un serveur d’authentification, d’autorisation et de comptabilité (AAA) RADIUS dans votre réseau, afin d’authentifier les UE lors du rattachement au réseau et à l’établissement de session. La communication entre le cœur de paquets et le serveur RADIUS est sécurisée avec un secret partagé stocké dans Azure Key Vault. Le nom d’utilisateur et le mot de passe par défaut des UE sont également stockés dans Azure Key Vault. Vous pouvez utiliser l’identité d’abonné mobile international (IMSI) de l’UE à la place d’un nom d’utilisateur par défaut. Consultez Collecter les valeurs RADIUS pour plus d’informations.
Votre serveur RADIUS doit être accessible à partir de votre appareil Azure Stack Edge sur le réseau de gestion. RADIUS est uniquement pris en charge pour l’authentification initiale. D’autres fonctionnalités RADIUS, telles que la comptabilité, ne sont pas prises en charge.
Accès aux outils de supervision locale
Connectivité sécurisée à l’aide de certificats TLS/SSL
L’accès aux tableaux de bord du suivi distribué et Packet Core est sécurisé par HTTPS. Vous pouvez fournir votre propre certificat HTTPS pour attester l’accès à vos outils de diagnostic locaux. La fourniture d’un certificat signé par une autorité de certification mondialement connue et approuvée accorde une sécurité supplémentaire à votre déploiement ; nous vous recommandons d’utiliser cette option plutôt que d’utiliser un certificat signé par sa propre clé privée (auto-signé).
Si vous décidez de fournir vos propres certificats pour l’accès de supervision locale, vous devez ajouter le certificat à un Key Vault Azure et configurer les autorisations d’accès appropriées. Pour plus d’informations sur la configuration de certificats HTTPS personnalisés pour l’accès à la supervision locale, consultez Collecter des valeurs de supervision locale.
Vous pouvez configurer la façon dont l’accès à vos outils de supervision locale est attesté lors de la création d’un site. Pour les sites existants, vous pouvez modifier la configuration de l’accès local en suivant Modifier la configuration de l’accès local dans un site.
Nous vous recommandons de permuter (remplacer) les certificats au moins une fois par an, notamment en supprimant les anciens certificats de votre système. Vous devrez peut-être faire pivoter vos certificats plus fréquemment s’ils expirent après moins d’un an, ou si les stratégies de l’organisation l’exigent.
Pour plus d’informations sur la génération d’un certificat Key Vault, consultez Méthodes de création de certificat.
Authentification d’accès
Vous pouvez utiliser Microsoft Entra ID ou un nom d’utilisateur et un mot de passe local pour accéder aux de suivi distribué et tableaux de bord de base de paquets.
Microsoft Entra ID vous permet de vous authentifier en mode natif à l’aide de méthodes sans mot de passe pour simplifier l’expérience de connexion et réduire le risque d’attaques. Par conséquent, pour améliorer la sécurité dans votre déploiement, nous vous recommandons de configurer l’authentification Microsoft Entra sur les noms d’utilisateur et les mots de passe locaux.
Si vous décidez de configurer l’ID Microsoft Entra pour l’accès à la surveillance locale, après le déploiement d’un site de réseau mobile, vous devez suivre les étapes décrites dans Activer l’ID Microsoft Entra pour les outils de surveillance locaux.
Consultez Choisir la méthode d’authentification pour les outils de surveillance locaux pour plus d’informations sur la configuration de l’authentification d’accès de supervision locale.
Vous pouvez utiliser Azure Policy pour appliquer Microsoft Entra ID pour l’accès à la supervision locale. Pour pus d’informations, consultez Définitions de stratégie Azure Policy pour Azure Private 5G Core.
Informations d’identification personnelle
Les diagnostics de package peuvent inclure des données personnelles, des données client et des journaux générés par le système à partir de votre site. Lorsque vous fournissez le package de diagnostics au support Azure, vous accordez explicitement à azure l’autorisation d’accéder au package de diagnostics et à toutes les informations qu’il contient. Vous devez confirmer que cela est acceptable dans les politiques et contrats de confidentialité de votre entreprise.