Certains termes techniques, tels que « Cloud Computing », « Edge Computing », ou encore « container » sont plus couramment usités sous cette forme, c’est pourquoi ils ne sont pas traduits en français dans cet article.
Délivrer un service dans les réseaux virtualisés
La virtualisation des réseaux a un impact considérable sur la façon dont sont gérés à la fois les services et les infrastructures télécoms. Voici un exemple qui en illustre certains avantages.
Un opérateur veut proposer un service de réalité augmentée à un gestionnaire d’un entrepôt dans une usine. Les utilisateurs finaux de ce service sont par exemple les techniciens de l’usine, munis de lunettes connectées. Le service consiste à afficher des informations utiles sur les produits stockés dans l’entrepôt, superposées à la vision de l’ouvrier qui examine ces produits.
Ce travail a donné lieu à quatre articles scientifiques et une démo
Dans ce service de réalité augmentée, les flux vidéo provenant des lunettes connectées sont transmis à un serveur de traitement qui rajoute les informations utiles dans l’image. A cette fin, le serveur de traitement a besoin d’accéder à des informations stockées dans une base de données. Les données sont chiffrées donc le service a également besoin d’une fonction de déchiffrage. Le service est donc composé dans cet exemple de trois fonctions, chacune exécutée dans un container différent. L’ensemble est appelé « chaîne de service ». Pour que ce service fonctionne correctement, il faut que la latence entre l’utilisateur et le serveur d’application ne soit pas trop importante (par exemple inférieure à 15 ms) pour éviter un décalage entre ce que voit le technicien et les informations remontées. Si le temps de traitement des 3 fonctions est de 5 ms, il reste 10 ms au maximum pour les communications entre les 3 containers et l’utilisateur final. L’exploitant de ce service va donc contracter un SLA (Service Level Agreement) avec le fournisseur de l’infrastructure pour avoir des garanties que cette latence ne sera pas dépassée pour des raisons directement liées à l’infrastructure (surcharge, panne, etc.) Déployer et gérer un tel service nécessite de déterminer où placer les éléments des chaines de service sur l’infrastructure, de telle sorte que l’ensemble de la chaîne respecte les SLAs associés au service. Plus ces éléments sont déployés à proximité de l’utilisateur, moins la latence de communication sera grande, cependant, les ressources de calcul étant moins importantes en périphérie de réseau elles sont généralement plus couteuses. Il y a donc un compromis à trouver entre le coût de placement et la latence. L’idéal est de déployer le service avec le coût le plus bas possible, mais avec une latence suffisante pour respecter le SLA.
Outre le critère de latence, le placement des containers doit prendre en considération le partage de l’infrastructure au sein d’un Data Center : il faut garantir que les services déployés disposent de suffisamment de ressources (calcul, mémoire, stockage) pour assurer leur bonne exécution quels que soient la charge des serveurs.
Enfin, il faut que le choix de placement prenne en compte la sécurité, avec des critères d’isolation des services.
Isolation des services
L’infrastructure physique est partagée entre tous les services, cependant certains services manipulant des données sensibles requièrent d’être isolés des autres services. En effet, il est possible qu’un service puisse accéder aux données d’un autre, en particulier par des techniques de « canaux auxiliaires » pour le vol de données confidentielles. Dans certains cas ces attaques peuvent aller jusqu’à de « l’empoisonnement de données » (l’attaquant modifie des données qui ne lui appartiennent pas), voire attaquer la disponibilité des ressources physiques sur le serveur.
Il est théoriquement possible d’avoir une infrastructure dédiée dans le cloud car les ressources y sont suffisantes. En revanche, dans le edge cloud, il devient irréaliste d’avoir une infrastructure physique dédiée pour tous les services critiques, cela nécessiterait des investissements beaucoup trop lourds.
Pour y remédier, une pseudo-isolation est mise en place, où les services sensibles sont isolés physiquement des services peu sécurisés. À cette fin, chaque fonction d’une chaîne de services définit un niveau d’isolation (de 1 à 5) correspondant à ses exigences. Ce niveau peut être défini dans l’accord de niveau de service (SLA) contracté. Le niveau 5 est réservé aux services de niveau étatique ou liés à des obligations légales, le niveau 4 est dédié aux applications industrielles critiques (au sens de la Directive NIS2), et ainsi de suite jusqu’à 1 pour les services grand public qui n’ont pas de besoin spécifique de sécurité.
En outre, chaque fonction d’une chaîne de services se voit attribuer un niveau de confiance. Celui-ci peut être déterminé par un processus d’évaluation de la sécurité, tel qu’un audit, sur la base des critères suivants, par exemple :
- Analyse ou audit de la vulnérabilité de l’image du container,
- Processus de développement du service (langage de programmation, pratiques de codage, bibliothèques utilisées, etc.),
- Processus de test de la chaîne de services.
Le niveau de confiance est déterminé par le fournisseur d’infrastructure. Si le propriétaire du service ne souhaite pas soumettre son service à l’audit de sécurité, il se voit attribuer le niveau de confiance le plus bas possible. Tout comme le niveau d’isolation, le niveau de confiance peut être fixé sur une échelle de 1 à 5.
L’isolation de la chaîne de services peut alors être appliquée, en s’assurant que deux fonctions sont physiquement colocalisées si un critère lié à ces exigences d’isolation et niveau de confiance est réalisé. Un tel critère pourrait être par exemple (cas simplifié) : le niveau de confiance de l’une est supérieur ou égal au niveau d’isolation de l’autre. De cette manière, les fonctions sensibles ne sont hébergées qu’avec des fonctions sécurisées.
Cette approche de pseudo-isolation présente plusieurs avantages par rapport à l’isolation physique : tout d’abord, elle permet de limiter les coûts, en n’imposant pas un usage dédié et statique de ressources de l’infrastructure pour des services critiques. Un autre avantage est que ce type d’isolement de sécurité est flexible, il peut être déployé à la demande pour répondre à un besoin spécifique et limité dans le temps, ce qui permet d’optimiser les ressources et les coûts. Par exemple, l’isolation peut être mise en place lorsqu’une opération de maintenance est en cours, c’est-à-dire lorsque les risques de brèches de sécurité sont plus élevés, puis elle est libérée lorsque l’opération est terminée. Cette adaptation des nœuds de l’infrastructure aux besoins dynamiques de sécurité des usagers, sous des hypothèses fortes de critères de colocalisation physique, permet d’optimiser les couts d’infrastructure (à un instant donné seules les ressources nécessaires sont réservées pour opérer des services à forte criticité). Néanmoins, prendre en compte ce type de contraintes rend encore plus difficile le placement des fonctions des chaines, comme illustré dans l’exemple ci-dessous.
Ainsi, déterminer comment placer puis gérer et orchestrer des chaines de service en prenant en compte toutes les contraintes et besoins de chaque service, tout en minimisant les ressources utilisées dans les infrastructures sont des problèmes difficiles. Ces problèmes se modélisent et se résolvent à l’aide de techniques et méthodes issues du domaine de l’optimisation mathématique. Des algorithmes efficaces en sont dérivés. Intégrés au cœur des réseaux ils permettront d’automatiser le cycle de vie des services tout en offrant des garanties fortes sur la qualité et la sécurité des services et en rationalisant l’utilisation des ressources.
Orchestration Cross-cloud
Cet article présente une problématique de recherche liée à la virtualisation des réseaux, à savoir comment placer et orchestrer des services déployés dans le continuum Cloud-Edge Computing, avec des contraintes très diverses telles que la qualité de service ou bien l’isolation de sécurité. Le continuum Cloud-Edge Computing peut être schématisé par la figure suivante :
Aperçu du continuum Cloud-Edge Computing
L’orchestrateur peut exécuter des containers au niveau central (qui correspond au Cloud Computing), ou bien dans des Data Centers plus proches des utilisateurs (Edge Computing).
Lorsque l’orchestrateur décide où placer les fonctions d’un service, il n’est pas forcément tenu d’utiliser les Data Centers d’un même fournisseur. Cela ouvre donc de nouvelles possibilités quant à l’orchestration des services dans un environnement cross-cloud (i.e. composé de Data Centers de différents fournisseurs, y compris un cloud privé). En particulier, les avantages apportés sont les suivants :
- L’orchestration permet de prendre en compte les requis particuliers des services (SLA)
- Orange pourrait agir comme courtier Business-to-Business (B2B), en sélectionnant l’environnement de déploiement le moins cher et le plus adapté aux services à déployer.
- Un service de défense par mobilité de cible (Moving Target Defense, MTD) devient envisageable. Les containers d’un service qui nécessite une sécurisation particulière sont déplacés régulièrement, afin d’empêcher des attaquants potentiels de réunir des informations sur l’environnement d’exécution. Ceci rend toute attaque sur ces containers particulièrement difficile.
Conclusion
Orange a conçu des algorithmes basés sur l’optimisation mathématique pour déterminer le placement des containers en respectant tous les requis de ce service (chaînage, latence, sécurité, etc.). Puis Orange a implémenté ces algorithmes dans un prototype d’un orchestrateur multi-clusters.
Cette approche a base d’outils « démontrables » est d’intérêt dans le cadre de nos travaux sur les futures certifications de nos infrastructures (EUCS/EU5G), pour traiter en particulier certains besoins de sécurité difficiles à établir dans l’état de l’art actuel.
Ce travail a donné lieu à quatre articles scientifiques et la démo du prototype a été présentée lors des Orange Open Tech Days, à Orange Gardens, en novembre 2023. Cette démo présente un tableau de bord pour la plateforme Edge Computing qui montre en temps réel : la charge (CPU et mémoire) des clusters, la latence de communication (intra-cluster et inter-clusters), ainsi que le coût d’utilisation des clusters. Les paramètres du tableau de bord permettent de superviser les indicateurs de performance clés et en particulier d’observer l’effet d’une dégradation de la latence d’un cluster sur les chaînes de services déployées, puis le rétablissement du niveau de SLA requis grâce à la migration des fonctions. La démonstration a été présentée à environ 300 visiteurs, pendant trois jours, suscitant un vif intérêt et donnant lieu à des échanges très inspirants.
Par la suite, ces algorithmes de placement prendront en compte l’énergie consommée, de manière à pouvoir réduire au maximum l’empreinte carbone des services. De plus la démo intégrera de nouveaux fournisseurs de Cloud (Amazon Web Service, Google Cloud Provider) afin de démontrer la faisabilité et la pertinence d’une approche cross-cloud.
Glossaire :
Container
Machine virtuelle allégée, car le container ne virtualise que les couches logicielles au-dessus du système d’exploitation.
Continuum Cloud-Edge Computing
Désigne l’intégration et l’orchestration continues des services informatiques entre le cloud centralisé et l’Edge Computing, en périphérie du réseau. Cette approche vise à optimiser les performances et la sécurité en traitant les données au plus près de leur source, tout en utilisant les ressources du cloud pour des tâches plus intensives ou globales.
Cross-cloud
Plateforme composée de Data Centers de différents fournisseurs, y compris des clouds privés.
Directive NIS2
Le Parlement européen et le Conseil de l’Union européenne ont adopté la directive « Network and Information Security » (NIS). Cette directive a pour objectif d’augmenter le niveau de cybersécurité des acteurs majeurs de dix secteurs d’activité stratégiques.
Optimisation combinatoire
Branche de l’optimisation en mathématiques appliquées. Son but est de trouver les meilleures solutions pour des problèmes avec une grande combinatoire.
Orchestration
Dans le contexte du cloud, l’orchestration désigne l’automatisation de la gestion des SLA (Service Level Agreement) : contrat entre un fournisseur et un client qui définit le niveau de qualité de service minimal requis par le client et sur lequel le fournisseur s’engage. Dans notre cas, un SLA est établi entre un prestataire de service et un opérateur Edge Cloud (e.g. Orange) qui fournit l’infrastructure cloud sur laquelle reposent ces services.
Virtualisation
Création d’une version virtuelle d’une ressource informatique, telle qu’un serveur, un système d’exploitation, un périphérique de stockage ou des ressources réseau. Elle permet de diviser une ressource physique en plusieurs environnements virtuels isolés. Cela permet une utilisation plus efficace des ressources.
