Brevet FR3046514A1 — publié le 20170707

Procédé de traitement d'un service réseau L'invention se situe dans le domaine des réseaux de télécommunication, et concerne plus particulièrement un procédé de traitement d'un service réseau au sein d'une infrastructure en nuage en cas d'attaque réseau. L'organisme de normalisation ETSI (pour « European Telecommunications Standards Institute ») a lancé début 2013 un projet dénommé NFV (pour « Network Functions Virtualization ») pour établir, entre les experts des secteurs des télécommunications et des technologies de l'information, les premières spécifications dans le domaine de la virtualisation (c'est-à-dire la dématérialisation) des fonctions utilisées dans les réseaux de télécommunications, désignées par la suite par fonctions réseau virtualisées (également appelées VNF pour « Virtualized Network Function »). Ces fonctions réseau virtualisées désignent par exemple les fonctions mises en oeuvre par une entité de gestion de mobilité virtualisée (e.g. MME pour « Mobility Management Entity »), une passerelle (e.g. P-GW pour « PDN Gateway »), un pare-feu, etc. La virtualisation des fonctions réseau est réalisée par des infrastructures dites en nuage, plus communément désignés par « cloud », qui implémentent et hébergent ces fonctions sur des machines virtuelles accessibles par exemple par l'intermédiaire d'une application réseau. Ces machines virtuelles utilisent des ressources informatiques et réseau matérielles distantes (ex. connectivité réseau, puissance de calcul, espaces de stockage, serveurs, applications, etc.), gérées par l'infrastructure en nuage, et mutualisées entre ses différents clients en fonction de leurs besoins respectifs. Les clients peuvent ainsi accéder à ces ressources sans avoir à administrer l'infrastructure sous-jacente de gestion de ces ressources, qui est souvent complexe. Composées ensemble, les fonctions réseau virtualisées forment des services réseau correspondant par exemple à un coeur de réseau IMS (pour « IP Multimedia Subsystem »), un réseau de distribution de contenus (ou réseau CDN pour « Content Distribution Network »), ou encore un coeur de réseau EPC (pour « Evolved Packet Core »). Ces services réseau sont créés par une entité d'orchestration qui pour chacun d'entre eux crée un graphe, dit « Forwarding Graph », représentant des fonctions réseau virtualisées, les connexions entre ces fonctions et l'ordre dans lequel un trafic entrant est soumis à ces fonctions réseau virtualisées afin de rendre le service considéré. Les infrastructures en nuage sont, comme toute infrastructure réseau, susceptibles de faire l'objet d'attaques réseau. Ces attaques sont notamment de nature à compromettre un service réseau mis en oeuvre par une telle infrastructure en nuage. Tel que défini actuellement dans un document de spécification de l'ETSI intitulé « Network Functions Virtualisation (NFV); Management and Orchestration », version 1.1.1 de décembre 2014, des notifications de type « Virtual resources fault management » peuvent être émises par des entités de gestion d'infrastructures virtualisées (appelées VIM pour « Virtual Infrastructure Manager » dans la terminologie NFV) vers une entité 3046514 2 d'orchestration (appelé NFVO pour «NFV Orchestrator » dans la terminologie NFV) ou vers des entités de gestion des VNFs (appelées VNFM pour VNF Manager). Ces notifications permettent d'identifier une ou plusieurs occurrences d'anomalies mais les entités de gestion d'infrastructures virtualisées n'ont pas la connaissance de la séquence de fonctions réseau virtualisées d'un service 5 réseau pour corréler des événements associés à un flux donné. Les notifications de type « Virtual resources fault management » ne permettent pas de déterminer si une anomalie relève d'une attaque réseau. Une attaque réseau est ainsi susceptible de ne pas être traitée correctement, ce qui peut avoir de lourdes répercussions sur le service réseau cible de l'attaque ainsi que sur le réseau support de ce service (e.g. perte de contrôle d'une ou plusieurs entité du réseau, fuite d'informations 10 confidentielles sur les abonnés du réseau). Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations. Selon un premier aspect, l'invention concerne un procédé de traitement d'un service réseau supporté par une infrastructure de réseau permettant la virtualisation de fonctions réseau, le 15 service réseau étant formé d'une séquence, dite séquence initiale, d'au moins une fonction réseau virtualisée traitant un flux entrant. Le procédé comprend les étapes suivantes : - détection d'une anomalie relative à la au moins une fonction réseau virtualisée ; - détection et identification d'une attaque réseau ciblant le service réseau à partir de l' anomalie ; 20 - identification dans la séquence initiale d'au moins une fonction réseau virtualisée impactée par l'attaque ; - modification de la séquence initiale pour circonscrire l'attaque de telle sorte que le flux entrant soit routé vers au moins une fonction réseau virtualisée, dite fonction curative, mettant en oeuvre un traitement du flux entrant, dit flux malveillant, ainsi que des fonctions mises en oeuvre 25 par la au moins une fonction réseau virtualisée impactée par l'attaque. Le procédé de traitement permet à partir par exemple d'une anomalie (e.g. paquets de données non conformes à un type de paquet attendu) du flux entrant de détecter qu'une attaque réseau est en cours, et de mettre en oeuvre des traitements visant à rétablir le fonctionnement normal du service réseau attaqué. Ces attaques sont par exemple des attaques de type « vol de 30 service » ou encore de type « vol d'information ». Une attaque de type « vol de service » consiste plus précisément à exploiter une faille dans le service supporté par l'infrastructure réseau en nuage, dans l'objectif d'en retirer un avantage pour un attaquant, comme par exemple la livraison de contenus gratuitement dans le cadre d'un service de livraison de contenus payants. Une attaque de type « vol d'information », consiste également à exploiter une faille de sécurité mais à la différence 35 d'une attaque de type « vol de service », cette faille se situe au niveau d'un système d'exploitation, ou d'une application mise en oeuvre sur un serveur objet de l'attaque. Une telle attaque est susceptible d'avoir des conséquences très lourdes sur l'infrastructure hébergeant le service réseau 3046514 3 attaqué dans son ensemble si elle n'est pas traitée rapidement. Une attaque de type « vol d'information » peut en effet permettre dans certains cas une prise de contrôle complète d'une ou de plusieurs entités du réseau fournissant le service réseau attaqué. Le procédé permet de contrecarrer de telles attaques en modifiant dynamiquement la séquence de fonctions réseau 5 virtualisée associée au service réseau objet de l'attaque. Le procédé permet ainsi de rediriger un flux entrant malveillant (flux utilisateur ou flux émis par l'auteur de l'attaque) relatif à un service réseau vers des fonctions réseau virtualisées saines aptes à traiter le flux malveillant. Selon une caractéristique particulière, le procédé comprend en outre un envoi d'une 10 notification que la séquence initiale a été modifiée, à une entité d'orchestration, l'entité commandant un routage du flux entrant vers la au moins une fonction curative en fonction d'un type du flux entrant. Les services réseaux proposés dans une infrastructure réseau en nuage sont limités à un catalogue de services réseau prédéfinis et maintenus par une entité d'orchestration, dite « entité 15 NFVO » (pour « Network Functions Virtualization Orchestrator »). En notifiant cette dernière entité que la séquence initiale a été modifiée, le procédé permet une mise à jour instantanée du catalogue de services réseau. Des demandes ultérieures relatives au service réseau ciblé par l' attaque sont ainsi, le cas échéant, directement orientées vers un service réseau non corrompu et formé de fonctions réseau virtualisées aptes à traiter un flux malveillant. 20 Le routage en fonction du type de flux entrant permet en outre de router le flux malveillant vers des fonctions réseau virtualisées spécialisées par type de flux. Le traitement d'un flux malveillant est ainsi accéléré, seuls les traitements pertinents pour un type de flux concerné étant appliqués. En outre, la différenciation par type de flux, lorsque plusieurs flux entrant sont émis à 25 destination du service réseau attaqué, mais que seuls certains types de flux sont malveillants, permet de ne router que ces derniers vers les fonctions dites curatives. Selon une caractéristique particulière, la modification de séquence consiste en une reconfiguration de la connectivité des fonctions réseau virtualisées de la séquence. Le procédé permet de répondre aux attaques par simple reconfiguration des points de 30 connexion (ou CP pour « Connection Points ») entre fonctions réseau virtualisées. Le procédé permet ainsi d' apporter une réponse rapide en temps réel et simple à une attaque. La reconfiguration est en outre de décision et de portée locale. La mise en oeuvre du procédé est par ailleurs facilitée dans la mesure où la modification de la séquence est une simple reconfiguration. Selon une caractéristique particulière, la fonction réseau virtualisée impactée par l'attaque 35 comprend au moins un composant corrompu, la fonction curative mettant en oeuvre uniquement les fonctions mises en oeuvre par le au moins un composant corrompu de la fonction réseau virtualisée impactée par l'attaque. 3046514 4 En isolant uniquement les composants de la séquence qui sont corrompus le procédé est accéléré. Lorsque seul un composant mineur d'une fonction réseau virtualisée est impacté par l'attaque il n'est en effet pas nécessaire de mettre en oeuvre tous les composants d'une fonction réseau virtualisée, les composants sains de la fonction étant avantageusement réutilisés dans la 5 nouvelle séquence. Cette réutilisation des composants sains d'une fonction réseau virtualisée impactée par une attaque permet en outre une économie des ressources de l'infrastructure en nuage hébergeant le service. Seuls les composants nécessitant un traitement sont en effet substitués. Selon une caractéristique particulière, le procédé selon comprend en outre : 10 - une validation par une entité d'orchestration de la modification de séquence avant routage du flux entrant malveillant vers la fonction réseau virtualisée curative ; - un traitement préventif et/ou curatif complémentaire du flux entrant malveillant par l'entité d'orchestration en fonction d'un type de l'attaque. Le traitement du flux malveillant par une entité d'orchestration permet d'adapter la 15 réponse à une attaque en fonction du type de cette attaque. Ceci est particulièrement avantageux dans le cas de fonctions réseau virtualisées gérées par exemple par différents équipementiers, chaque équipementier étant susceptible d'appliquer ces propres mesures suite à l' attaque à travers notamment le VNF Manager. Selon un deuxième aspect, l'invention concerne une entité de gestion de ressources 20 virtualisées, gérant au moins une fonction réseau virtualisée d'une séquence, dite séquence initiale, de fonctions réseau virtualisées traitant un flux entrant et formant un service réseau. L'entité comprend : - un module de réception, agencé pour recevoir une notification qu'une attaque réseau relative au service réseau a été détectée ; 25 - un module de commande, agencé pour commander une identification dans la séquence initiale d'au moins une fonction réseau virtualisée impactée par l'attaque ; - un module de traitement d'une séquence, agencé pour modifier la séquence initiale de telle sorte qu'un flux entrant, dit flux malveillant, soit routé vers au moins une fonction réseau virtualisée curative mettant en oeuvre un traitement du flux malveillant ainsi que des fonctions 30 mises en oeuvre par la au moins une fonction réseau virtualisée impactée par l'attaque. Selon une caractéristique particulière, le module de commande de l'entité de gestion de ressources virtualisées est en outre agencé pour commander un routage du flux entrant malveillant vers la au moins une fonction réseau virtualisée curative en fonction du type du flux entrant malveillant. 35 Selon un troisième aspect, l'invention concerne un système de traitement d'un service réseau supporté par une infrastructure de réseau virtualisé, le service réseau étant formé d'une 3046514 5 séquence, dite séquence initiale, d'au moins une fonction réseau virtualisée traitant un flux entrant. Le système comprend : - une entité de gestion de ressources virtualisées selon le deuxième aspect ; - une entité d'orchestration comprenant : 5 - un module de validation agencé pour valider une modification de séquence traitée par l'entité de gestion de ressources virtualisées, avant routage d'un flux entrant malveillant vers une fonction réseau virtualisée curative ; - un module de traitement préventif et/ou curatif agencé pour mettre en oeuvre un traitement complémentaire du flux entrant malveillant en fonction d'un type 10 d' attaque. Selon une caractéristique particulière, le système comprend en outre un module de sécurité agencé pour identifier dans la séquence initiale au moins une fonction réseau virtualisée impactée par l'attaque. Les avantages énoncés pour le procédé de traitement selon le premier aspect sont 15 transposables directement au système de traitement selon le troisième aspect. Selon un quatrième aspect, l'invention concerne également un programme comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé précédemment décrit, lorsque ledit programme est exécuté sur ordinateur et un support d'enregistrement lisible par ordinateur sur lequel est enregistré un programme d'ordinateur 20 comprenant des instructions de code de programme pour l'exécution des étapes du procédé précédemment décrit. L'invention sera mieux comprise à l'aide de la description suivante de modes de réalisation particuliers, en référence aux dessins annexés sur lesquels : - la figure 1 représente de manière simplifié une infrastructure réseau en nuage selon un 25 mode particulier de réalisation ; - les figures 2a et 2b représentent un service réseau respectivement avant et après mise en oeuvre du procédé de traitement selon un mode particulier de réalisation ; - la figure 3 représente un organigramme du procédé de traitement, et des échanges entre équipements mettant en oeuvre le procédé, selon un mode particulier de réalisation ; 30 - la figure 4 représente une entité de gestion de ressources virtualisées selon un mode particulier de réalisation. La figure 1 représente un système 100 de traitement d'un service réseau supporté par une infrastructure de réseau permettant la virtualisation de fonctions réseau selon un mode particulier 35 de réalisation. Le système 100 comprend une entité de gestion de ressources virtualisées 40 et une entité d'orchestration 50. Optionnellement le système 100 comprend également un module de sécurité 60. 3046514 6 L'entité d'orchestration 50 est plus particulièrement en charge du pilotage des entités de gestion de ressources virtualisées 40 et des entités de gestion d'infrastructure virtualisée 30 du réseau de communication 1 dans lequel est mis en oeuvre le système 100. L'entité d'orchestration 50 dispose d'un catalogue 11 de services réseau. Ce catalogue 11 est par exemple une base de 5 données agencée pour mémoriser des services réseau et des séquences d'au moins une fonction réseau virtualisée correspondant à ces services. Le catalogue précise notamment un comportement opérationnel prédéfini des fonctions réseau virtualisées sur lesquelles reposent les services réseau du catalogue 11, ainsi que les ressources nécessaires (e.g. nombre de machines virtuelles, mémoire, bande passante, latence) afin de déployer ces fonctions et mettre en oeuvre les services réseau du 10 catalogue. Les fonctions réseau virtualisées sont décrites par des descripteurs de fonctions réseau virtualisées (en anglais « VNF descriptor » pour « Virtual Network Function descriptor ») tels que définis par l'ETSI. Les fonctions réseau virtualisées correspondent à des fonctions fournies par l'opérateur du réseau de communication 1 pour traiter un paquet de données émis par exemple depuis un terminal utilisateur 70. Il s'agit à titre d'exemple non limitatif de services de traduction 15 d'adresses réseau, de pare-feu, de services de répartition de charge, de transcodage, de mise en cache, d'optimisation de requête, ou encore d'enrichissement de paquets réseau. Selon l'architecture NFV définie dans le document de spécifications de l'ETSI « GS NFV- MAN 001 » publié en décembre 2014, lorsqu'un service réseau du catalogue 11 est mis en oeuvre dans le réseau de communication 1, l'entité d'orchestration 50 s'adresse aux entités de gestions de 20 ressources virtualisées en charge de gérer les fonctions réseaux virtualisées de la séquence d'au moins une fonction réseau virtualisée formant ce service réseau. Chaque entité de gestion de ressources virtualisées est associée à au moins une fonction réseau virtualisée de la séquence. Une entité de gestion de ressources virtualisées a plus particulièrement pour rôle de gérer le cycle de vie d'une fonction réseau virtualisée, c'est-à-dire sa création, sa mise en oeuvre et sa terminaison. Les 25 fonctions réseau virtualisées sont à cette fin installées sur des machines virtuelles (cf. supra) crées et gérées par une entité de gestion d'infrastructure virtualisée 30. Une entité de gestion de ressources virtualisée reçoit en provenance d'une fonction réseau virtualisée dont elle a la charge, des informations dites « FCAPS » (pour « Fault, Configuration, Accounting, Performance, Security ») de gestion d'erreur, de configuration, d'usage, de performance, et de sécurité relatives à 30 cette fonction réseau virtualisée. Ces informations sont gérées par une fonction de gestion EM 20 (pour « Element Management ») tel que décrite dans le document de l'ETSI en section 5.5.1. Elles permettent notamment à une entité de gestion de ressources virtualisées d'adapter les ressources affectées à une fonction réseau virtualisée. A titre d'exemple, l'entité de gestion de ressources virtualisées 40 est en charge de la gestion des fonctions réseaux virtualisées 10a et 10b. Ces 35 fonctions réseaux virtualisées 10a-b assurent par exemple les fonctions d'un serveur web proxy. Le système 100 comprend par ailleurs un module de sécurité 60. Le module de sécurité 60 permet d'identifier une attaque tel que décrit dans la demande de brevet US2015/0033340 intitulée 3046514 7 « Systems and methods for self-tuning network intrusion detection and prevention » du 23 juillet 2014. Une attaque réseau est plus précisément identifiée à partir d'un flux malveillant dans lequel est identifié un motif connu (e.g. source de l'attaque qui n'est pas de confiance, paquets aléatoires, séquences TCP pour « Transmission Control Protocol » incohérentes). 5 Les communications entre l'entité de gestion de ressources virtualisées 40, l'entité de gestion d'infrastructure virtualisée 30 et les fonctions réseaux virtualisées 10a-b du réseau de communication 1 sont réalisées par l'intermédiaire des interfaces telles que définies dans le document de spécifications « GS NFV-MAN 001 ». Plus précisément, l'entité de gestion de ressources virtualisées 40 communique avec la fonction réseau virtualisée 10a et avec la fonction 10 réseau virtualisée 10b via des interfaces Ve-Vnfm-vnf. L'entité de gestion de ressources virtualisées 40 communique également avec l'entité de gestion d'infrastructure virtualisée 30 via une interface Vi-Vnfm. La communication entre l'entité d'orchestration 50 et l'entité de gestion de ressources virtualisées 40 est assurée par une interface Or-Vnfm. Seule une entité de gestion de ressources virtualisées 40 est représentée, il n'existe 15 cependant aucune limitation quant au nombre d'entité de gestion de ressources virtualisées mises en oeuvre pour fournir un service réseau. En outre, dans un autre mode de réalisation, de même qu'une entité de gestion de ressources virtualisées 40 est susceptible de gérer plusieurs fonctions réseau virtualisées, une fonction réseau virtualisée est susceptible d'être gérée par une ou plusieurs entités de gestion de ressources virtualisées. 20 Seules deux fonctions réseau virtualisées 10a-b sont représentées, il n'existe cependant aucune limitation quant au nombre de fonctions réseau virtualisées de la séquence de fonctions réseau virtualisées formant un service réseau. Les figures 2a et 2b représentent un service réseau NS1 respectivement avant et après 25 mise en oeuvre du procédé de traitement selon un mode particulier de réalisation. Le service réseau NS1 comprend trois fonctions réseau virtualisées VNF1, VNF2 et VNF3. Le service réseau NS1 traite un ou plusieurs flux entrant reçu au point de connexion CP01, point d'entrée du service réseau NS1, et retourne le ou les flux une fois traités au point de connexion CP02, point de sortie du service réseau NS1. Les points de connexion CP01 et CP02 30 sont également appelés point de livraison et point de terminaison du service réseau NS1. Les points de connexion sont plus généralement définis comme des points d'entrée/sortie. Il s'agit selon le cas de points d'entrée/sortie d'une fonction réseau virtualisée, ou d'un service réseau. Les figures 2a et 2b correspondent plus particulièrement à un graphe (dit « Forwarding Graph ») modélisant les relations entre les fonctions réseau virtualisées VNF1, VNF2 et VNF3. Ces 35 relations sont modélisées par des liens virtuels (ou « Virtual Links » selon la terminologie NFV) reliant les fonctions réseau virtualisées par des points de connexions. 3046514 8 La description des liens virtuels comprend en outre des caractéristiques de qualité de service telles que la bande passante souhaitée, la latence, ou encore la gigue (cf. document « GS NFV-MAN 001 », section 6.4.1). A titre d'exemple, dans le mode de réalisation décrit en relation avec la figure 2a, le 5 service réseau NS1 dans sa configuration initiale est formé d'une séquence de trois fonctions réseau virtualisées VNF1, VNF2 et VNF3. La fonction réseau virtualisée VNF1 comprend trois points de connexion CP11, CP12 et CP13 ; la fonction réseau virtualisée VNF2 comprend deux points de connexion CP21 et CP22 ; et la fonction réseau virtualisée VNF3 comprend trois points de connexion CP31, CP32 et CP33. Le point de connexion CP11 de la fonction réseau virtualisée 10 VNF1 est relié au point d'entrée CPO1 du service réseau NS1 par le lien virtuel VL1. Le point de connexion CP33 de la fonction réseau virtualisée VNF3 est relié au point de sortie CP02 du service réseau NS1 par le lien virtuel VL5. La fonction réseau virtualisée VNF1 est outre relié aux fonctions réseau virtualisées VNF2 et VNF3 par respectivement un lien virtuel VL2 entre les points de connexion CP13 et CP21, et par un lien virtuel VL4 entre les points de connexion CP12 et 15 CP32. De même, les fonctions réseau virtualisées VNF2 et VNF3 sont liées par un lien virtuel VL3 entre les points de connexion CP22 et CP31. La figure 2b illustre le même service réseau NS1, décrit précédemment en relation avec la figure 2a, après que la séquence de fonctions réseau VNF1, VNF2 et VNF3 ait été reconfigurée en réponse à une attaque réseau selon un procédé de traitement qui sera décrit ultérieurement en 20 relation avec la figure 3. La fonction réseau virtualisée VNF1 est selon ce procédé de traitement identifiée dans la séquence initiale impactée par l'attaque réseau. La séquence de fonctions réseau virtualisées est alors reconfigurée afin d'isoler la fonction réseau virtualisée VNF1 et de router les flux à destination de cette dernière fonction vers une fonction réseau virtualisée VNF1', dite fonction curative, mettant en oeuvre un traitement du flux ainsi que des fonctions mises en oeuvre 25 par la fonction réseau virtualisée VNF1. La reconfiguration de la séquence de fonctions réseau virtualisées est réalisée par une entité de gestion de ressources virtualisées VNFM 40 gérant la fonction réseau virtualisée VNF1 et consiste plus précisément à reconfigurer les liens virtuels comprenant des points de connexion appartenant à la fonction réseau virtualisée VNF1 impactée par l'attaque réseau, à savoir les liens virtuels VL1, VL2 et VL4. Après reconfiguration, la 30 séquence formant le service réseau NS1 est constituée des fonctions réseau virtualisées VNF1', VNF2 et VNF3. La fonction réseau virtualisée comprend trois points de connexion CP11', CP12' et CP13'. Les liens virtuels VL1, VL2 et VL4 sont reconfigurés et lient respectivement le point de connexion CP11' au point de connexion CP01, le point de connexion CP13' au point de connexion CP21, et le point de connexion CP12' au point de connexion CP32. Les liens virtuels VL3 et VL5 35 sont inchangés. 3046514 9 La figure 3 représente un organigramme du procédé de traitement, et des échanges entre entités mettant en oeuvre le procédé, selon un mode particulier de réalisation. Par la suite, on se place dans une configuration réseau telle que celle décrite en relation avec la figure 1. Lors d'une étape E0, le terminal 70 envoie une requête HTTP (pour « HyperText 5 Transfert Protocol ») à la fonction réseau virtualisée VNF1 10a. La fonction réseau virtualisée VNF1 10a correspond par exemple à une fonction proxy web, dite « fonction initiale » d'une séquence S d'au moins une fonction réseau virtualisée formant un service réseau NS1 du catalogue de services réseau 11 de l'entité d'orchestration NFVO 50. La requête HTTP constitue un flux entrant pour le service réseau NS1. On suppose par la suite que ce flux entrant comprend des 10 paquets de données malicieux constituant une attaque réseau visant le service réseau NS1. Lors d'une étape El, la fonction réseau virtualisée VNF1 10a déclenche une alarme signalant une anomalie à l'entité de gestion de ressources virtualisées VNFM 40. Lors d'une étape E2, l'anomalie est également détectée par la fonction de gestion EM 20 de la fonction réseau virtualisée VNF1 10a. 15 Lors d'une étape E3, la fonction de gestion EM 20 de la fonction réseau virtualisée VNF1 10a s'adresse au module de sécurité 60 afin de déterminer et identifier le cas échéant une attaque réseau à partir de l'anomalie détectée dans le flux entrant. Le message envoyé au module de sécurité comprend en particulier un identifiant de la fonction réseau virtualisée pour laquelle une anomalie a été détectée, ainsi qu'un identifiant du point de présence hébergeant cette fonction 20 réseau virtualisée. Le module de sécurité 60 identifie à partir du flux entrant qu'une attaque réseau est en cours, le flux entrant est alors dit « malveillant », et retourne à la fonction de gestion EM 20 une réponse indiquant le type d'attaque subie par le service réseau NS1. A titre d'exemple l'attaque subie est une attaque de type DDoS pour « Distributed Denial of Service ». Lors d'une étape E4, la fonction de gestion EM 20 de la fonction réseau virtualisée VNF1 25 10a notifie l'entité de gestion de ressources virtualisées VNFM 40 de l'attaque en précisant la fonction réseau virtualisée visée par l'attaque et le point de présence où est localisée l'attaque. Lors d'une étape E5, l'entité de gestion de ressources virtualisées VNFM 40 commande à l'entité de gestion d'infrastructures virtualisées VIM 30 la mise en oeuvre de la connectivité avec une fonction réseau virtualisée VNF1' 10b, dite fonction curative, apte à mettre en oeuvre un 30 traitement du flux malveillant ainsi que des fonctions mises en oeuvre par la fonction réseau virtualisée VNF1 10a impactée par l'attaque réseau. Lors d'une étape E6, l'entité de gestion de ressources virtualisées VNFM 40 informe l'entité d'orchestration 50 que la fonction réseau virtualisée VNF1 10a subit une attaque réseau en précisant notamment le type de fonction réseau virtualisée impactée et le ou les points de présence 35 touchés par l'attaque. Lors d'une étape E7, l'entité de gestion de ressources virtualisées VNFM 40 demande l'activation des points de connexion de la fonction réseau virtualisée VNF1' 10b afin de router le 3046514 10 trafic venant de la fonction réseau virtualisé VNF1 10a vers la fonction VNF1' 10b. La fonction réseau virtualisée VNF1' 10b, une fois ses points de connexion activés, répond à l'entité de gestion de ressources virtualisées VNFM 40 par un message d'acquittement. Lors d'une étape E8, l'entité d'orchestration 50 valide la modification de séquence initiée 5 à l'étape E5 ainsi que le routage du trafic vers la fonction réseau virtualisée VNF1' 10b. Lors d'une étape E9, l'entité de gestion de ressources virtualisées VNFM 40 demande à l'entité de gestion d'infrastructure virtualisée VIM 30 de configurer les liens virtuels entre les points de connexion de la fonction réseau virtualisée VNF1' 10b et les points de connexion des fonctions réseau virtualisées auxquelles était connectée la fonction réseau virtualisée VNF1 10a de 10 la séquence initiale de fonctions réseau virtualisées formant le service réseau NS1. Le routage du trafic à destination de l'ancienne fonction réseau virtualisée VNF1 10a est alors immédiatement redirigé via les liens virtuels nouvellement configurés vers la fonction réseau virtualisée VNF1' 10b. La fonction réseau virtualisée 10b est notamment munie, en plus des fonctions propres à la fonction réseau virtualisée VNF1 10a, de fonctions d'inspection des paquets en profondeur 15 (fonctions DPI pour « Deep Packet Inspection) et de fonctions pare-feu, afin de traiter le flux malveillant et ainsi enrayer l'attaque. On suppose dans le présent mode de réalisation que le simple re-routage du trafic vers la fonction réseau virtualisée VNF1' 10b suffit à traiter l'attaque. Le trafic à destination du service NS1 peut ainsi avantageusement être maintenu sans perturbation du service NS1. 20 Lors d'une étape E10, l'entité de gestion d'infrastructure virtualisée VIM 30 notifie l'entité de gestion de ressources virtualisées VNFM 40 que les points de connexions et les liens virtuels ont été mis à jour. Lors d'une étape El 1, l'entité de gestion de ressources virtualisées VNFM 40 notifie l'entité d'orchestration 50 que le graphe associé au service réseau NS1 a été modifié afin de tenir 25 compte de la nouvelle séquence de fonctions réseau virtualisées. Cette nouvelle séquence correspond à la séquence de fonctions réseau virtualisées précédemment décrite en relation avec la figure 2b. L'entité d'orchestration 50 met alors à jour son catalogue 11 de services réseau pour le service réseau NS1. Lors d'une étape E12, de même qu'à l'étape E10, l'entité de gestion d'infrastructure 30 virtualisée VIM 30 notifie l'entité d'orchestration 50 que les points de connexions et les liens virtuels ont été mis à jour. Les notifications envoyées aux étapes El 1 et E12 sont acquittées par l'entité d'orchestration 50. Puis lors d'une étape E13, l'entité de gestion de ressources virtualisées VNFM 40 notifie 35 la fonction de gestion EM 20 de la fonction réseau virtualisée VNF1' 10b de la reconfiguration du graphe associé au service réseau NS1. Cette notification entraîne une opération dite de « post-configuration » et est nécessaire dans le cas où le routage du flux entrant est fonction du flux traité 3046514 11 par la VNF1' 10b. Dans un autre mode de réalisation, cette post-configuration permet par exemple à la fonction réseau virtualisée VNF1' 10b de différencier le routage d'un flux entrant suivant sa nature. Seuls les flux correspondant à un service bénéficiant d'une qualité de service élevée sont par exemple routés sur commande de l'entité d'orchestration 50 vers la fonction réseau virtualisée 5 VNF1' 10b. Lors d'une étape E14, la fonction réseau virtualisée VNF1 10a est détruite. Dans un autre mode de réalisation, les composants corrompus de la fonction réseau virtualisée VNF1 10a impactés par l'attaque réseau sont identifiés (à l'aide par exemple du module de sécurité 60). La fonction réseau virtualisée VNF1' 10b met alors en oeuvre uniquement les 10 fonctions mises en oeuvre par les composants corrompus de la fonction réseau virtualisée impactée par l' attaque. Dans un autre mode de réalisation, l'entité d'orchestration 50 après validation de la modification de la séquence de fonctions réseau virtualisées formant le service réseau NS1, met en oeuvre un traitement préventif et/ou curatif complémentaire du flux entrant malveillant. 15 Dans un autre mode de réalisation, l'anomalie est détectée par l'entité de gestion de ressources virtualisées VNFM 40 qui supervise la fonction réseau virtualisée VNF1 10a attaquée, ou par l'entité d'orchestration 50 responsable du service réseau NS1 impacté. Dans un autre mode de réalisation, les fonctions de traitement du flux malveillant ainsi que les fonctions mises en oeuvre par la fonction réseau virtualisée VNF1 10a impactée par 20 l'attaque réseau mises en oeuvre par la fonction réseau virtualisée VNF1 10a sont assurées par deux fonctions réseau virtualisées distinctes. La figure 4 représente une entité de gestion de ressources virtualisées 40 gérant au moins une fonction réseau virtualisée d'une séquence, dite séquence initiale, de fonctions réseau 25 virtualisées traitant un flux entrant et formant un service réseau. L'entité de gestion de ressources virtualisées comprend : - un module de réception 400, agencé pour recevoir une notification qu'une attaque réseau relative au service réseau a été détectée, l'attaque étant constituée d'un flux entrant malveillant ; - un module de commande 410, agencé pour commander une identification dans la séquence 30 initiale d'au moins une fonction réseau virtualisée impactée par l'attaque ; - un module de traitement 420 d'une séquence, agencé pour modifier la séquence initiale de telle sorte que le flux entrant malveillant soit routé vers au moins une fonction réseau virtualisée, dite fonction curative mettant en oeuvre un traitement du flux malveillant ainsi que des fonctions mises en oeuvre par la au moins une fonction réseau virtualisée impactée par l'attaque. 35 Dans un autre mode de réalisation, le module de commande est en outre agencé pour commander un routage du flux entrant malveillant vers la au moins une fonction réseau virtualisée curative en fonction du type du flux entrant malveillant. 3046514 12 L'invention est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et/ou logiciels, apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit précédemment 5 pour le module concerné. Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel. Un tel composant logiciel est stocké en mémoire puis chargé et exécuté par un processeur de données d'une entité physique et est susceptible d'accéder aux 10 ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc). De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware). Il peut s'agir d'un composant matériel programmable ou non, avec ou sans processeur intégré pour l'exécution de logiciel. Il s'agit par exemple d'un circuit intégré, d'une 15 carte à puce, d'une carte électronique pour l'exécution d'un micrologiciel (firmware), etc. Dans un mode de réalisation particulier, les modules 400, 410 et 420 sont agencés pour mettre en oeuvre le procédé de traitement précédemment décrit. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter celles des étapes du procédé de traitement précédemment décrit, mises en oeuvre par une entité de gestion de ressources 20 virtualisées. L'invention concerne donc aussi : - un programme pour une entité de gestion de ressources virtualisées, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé de traitement précédemment décrit, lorsque ledit programme est exécuté par ladite entité ; - un support d'enregistrement lisible par une entité de gestion de ressources virtualisées sur lequel 25 est enregistré le programme pour une telle entité. Les modules logiciels peuvent être stockés dans ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal électrique, optique ou radio, ou un réseau de télécommunication. REVENDICATIONS1. Procédé de traitement d'un service réseau supporté par une infrastructure de réseau permettant la virtualisation de fonctions réseau (10a), ledit service réseau étant formé d'une séquence, dite séquence initiale, d'au moins une fonction réseau virtualisée (10a) traitant un flux entrant, ledit procédé comprenant les étapes suivantes : - détection (El, E2) d'une anomalie relative à ladite au moins une fonction réseau virtualisée ; - détection et identification (E3) d'une attaque réseau ciblant ledit service réseau à partir de ladite anomalie ; - identification (E3) dans ladite séquence initiale d'au moins une fonction réseau virtualisée impactée par ladite attaque ; - modification (E5, E7, E9) de ladite séquence initiale pour circonscrire l'attaque de telle sorte que ledit flux entrant soit routé vers au moins une fonction réseau virtualisée, dite fonction curative, mettant en oeuvre un traitement dudit flux entrant, dit flux malveillant, ainsi que des fonctions mises en oeuvre par ladite au moins une fonction réseau virtualisée impactée par ladite attaque. 2. Procédé selon la revendication 1, comprenant en outre un envoi (E11) d'une notification que ladite séquence initiale a été modifiée, à une entité d'orchestration, ladite entité commandant un routage dudit flux entrant vers ladite au moins une fonction curative en fonction d'un type dudit flux entrant. 3. Procédé selon la revendication 1, dans lequel ladite modification de séquence consiste en une reconfiguration de la connectivité des fonctions réseau virtualisées de ladite séquence. 4. Procédé selon la revendication 1, dans lequel la fonction réseau virtualisée impactée par ladite attaque comprend au moins un composant corrompu, ladite fonction curative mettant en oeuvre uniquement les fonctions mises en oeuvre par ledit au moins un composant corrompu de la fonction réseau virtualisée impactée par ladite attaque. 5. Procédé selon la revendication 1, comprenant en outre : - une validation (E8) par une entité d'orchestration de ladite modification de séquence avant routage dudit flux entrant malveillant vers ladite fonction réseau virtualisée curative ; - un traitement préventif et/ou curatif complémentaire dudit flux entrant malveillant par ladite entité d'orchestration en fonction d'un type de ladite attaque. 3046514 14 6. Entité de gestion de ressources virtualisées (40), gérant au moins une fonction réseau virtualisée d'une séquence, dite séquence initiale, de fonctions réseau virtualisées traitant un flux entrant et formant un service réseau, ladite entité comprenant : - un module de réception (400), agencé pour recevoir une notification qu'une attaque réseau 5 relative audit service réseau a été détectée ; - un module de commande (410), agencé pour commander une identification dans ladite séquence initiale d'au moins une fonction réseau virtualisée (10a) impactée par ladite attaque ; - un module de traitement (420) d'une séquence, agencé pour modifier ladite séquence initiale de telle sorte qu'un flux entrant, dit flux malveillant, soit routé vers au moins une fonction réseau 10 virtualisée curative (10b) mettant en oeuvre un traitement dudit flux malveillant ainsi que des fonctions mises en oeuvre par ladite au moins une fonction réseau virtualisée impactée par ladite attaque. 7. Entité de gestion de ressources virtualisées selon la revendication 6, dans laquelle le module de 15 commande est en outre agencé pour commander un routage dudit flux entrant malveillant vers ladite au moins une fonction réseau virtualisée curative en fonction du type dudit flux entrant malveillant. 8. Système (100) de traitement d'un service réseau supporté par une infrastructure de réseau 20 virtualisé, ledit service réseau étant formé d'une séquence, dite séquence initiale, d'au moins une fonction réseau virtualisée traitant un flux entrant, ledit système comprenant : - une entité de gestion de ressources virtualisées (40) selon la revendication 6 ; - une entité d'orchestration (50) comprenant : - un module de validation agencé pour valider une modification de séquence traitée par ladite 25 entité de gestion de ressources virtualisées, avant routage d'un flux entrant malveillant vers une fonction réseau virtualisée curative ; - un module de traitement préventif et/ou curatif agencé pour mettre en oeuvre un traitement complémentaire dudit flux entrant malveillant en fonction d'un type d'attaque. 30 9. Système (100) selon la revendication 8, comprenant en outre un module de sécurité (60) agencé pour identifier dans ladite séquence initiale au moins une fonction réseau virtualisée impactée par ladite attaque. 10. Programme pour une entité de gestion de ressources virtualisées, comprenant des instructions 35 de code de programme destinées à commander l'exécution des étapes du procédé selon l'une des revendications 1 à 5, lorsque ledit programme est exécuté par une entité de gestion de ressources virtualisées. 3046514 15 11. Support d'enregistrement lisible par une entité de gestion de ressources virtualisées sur laquelle est enregistré le programme selon la revendication 10.