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 au repos par défaut avec des clés managées par Microsoft (MMK), vous pouvez éventuellement utiliser des clés gérées par le client (CMK) lors de la création d’un groupe SIM ou lors du déploiement d’un réseau mobile privé pour chiffrer les données avec votre propre clé.
Si vous choisissez d’utiliser une clé CMK, vous devez 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. Consultez les définitions 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.
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 remplacer les certificats au moins une fois par an, notamment en supprimant les anciens certificats de votre système. C’est ce qu’on appelle des certificats de rotation. 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.
Informations d’identification personnelle
packages diagnostics peut contenir des informations à partir de votre site, qui peuvent, selon l’utilisation, inclure des données telles que des données personnelles, des données client et des journaux générés par le système. 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.
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 l’ID Entra pour l’accès à la supervision locale. Consultez les définitions Azure Policy pour azure Private 5G Core.