Brevet FR3160782A1 — publié le 20251003

Il est proposé un module de sécurité adapté pour opérer sur un système comprenant un ensemble de ressources, le système étant adapté pour gérer au moins un service dans un environnement informatique en nuage, le système étant adapté pour mettre en œuvre des opérations de clonage, une opération de clonage impliquant une ressource source contribuant à l’au moins un service avant l’opération de clonage et une ressource cible contribuant à l’au moins un service à l’issue de l’opération de clonage, en remplacement de ladite ressource source, le module étant configuré pour effectuer un clonage d'une ressource de l’ensemble conformément à un délai représentatif d’une vulnérabilité estimée de ladite ressource Figure de l’abrégé : Figure 1 Système de défense trompeuse, mouvante, et hybride La présente divulgation relève du domaine de la sécurité des systèmes informatiques. Elle concerne plus précisément un module de sécurité, ainsi qu’un procédé, un programme informatique et un support d’enregistrement correspondants. L'état de l'art comprend des systèmes qui utilisent des technologies de conteneurisation, comme "Docker" (marque déposée), et d'orchestration de conteneurs, comme "Kubernetes" (marque déposée). Ces systèmes sont conçus pour déployer des applications et des services sur des agglomérations de traitement de données, ou « clusters », en les répartissant sur plusieurs environnements de travail, ou « clouds ». Dans ce contexte, il existe un besoin continu pour des fonctions de sécurité à même de prévenir les attaques informatiques, déconcerter et décourager les attaquants. Résumé La présente divulgation vient améliorer la situation. Il est proposé un module de sécurité adapté pour opérer sur un système comprenant un ensemble de ressources, le système étant adapté pour gérer au moins un service dans un environnement informatique en nuage, le système étant adapté pour mettre en œuvre des opérations de clonage, une opération de clonage impliquant une ressource source contribuant à l’au moins un service avant l’opération de clonage et une ressource cible contribuant à l’au moins un service à l’issue de l’opération de clonage, en remplacement de ladite ressource source, le module étant configuré pour effectuer un clonage d'une ressource de l’ensemble conformément à un délai représentatif d’une vulnérabilité estimée de ladite ressource. Selon un autre aspect, il est proposé un procédé mis en œuvre par un module de sécurité adapté pour opérer sur un système comprenant un ensemble de ressources, le système étant adapté pour gérer au moins un service dans un environnement informatique en nuage, le système étant adapté pour mettre en œuvre des opérations de clonage, une opération de clonage impliquant une ressource source contribuant à l’au moins un service avant l’opération de clonage et une ressource cible contribuant à l’au moins un service à l’issue de l’opération de clonage, en remplacement de ladite ressource source, le procédé comprenant : effectuer un clonage d'une ressource de l’ensemble conformément à un délai représentatif d’une vulnérabilité estimée de ladite ressource. Selon un autre aspect, il est proposé un programme informatique comportant des instructions pour la mise en œuvre de tout ou partie d’un procédé tel que défini dans les présentes lorsque ce programme est exécuté par un processeur. Selon un autre aspect, il est proposé un support d’enregistrement non transitoire, lisible par un ordinateur, sur lequel est enregistré un tel programme. En permettant le clonage de ressources en se basant sur leur vulnérabilité estimée, la technique proposée augmente la difficulté pour les attaquants de compromettre des services, car elle génère constamment une nouvelle configuration système qui leur est inconnue. Les caractéristiques exposées dans les paragraphes suivants peuvent, optionnellement, être mises en œuvre, indépendamment les unes des autres ou en combinaison les unes avec les autres : Dans un exemple, le délai est déterminé sur la base d’une information de sécurisation de la ressource. Cela permet de personnaliser la réactivité du module de sécurité en fonction du niveau de sécurité actuel de chaque ressource individuelle. Le module de sécurité peut collecter les informations de sécurisation d’une pluralité de ressources et prioriser les ressources qui nécessitent une attention plus immédiate, en adaptant le délai de clonage à la volatilité de leur état de sécurité. L’information de sécurisation de la ressource peut être obtenue de différentes manières. Par exemple, une évaluation de vulnérabilité a priori peut être réalisée via une analyse de risques basée sur des caractéristiques intrinsèques de la ressource, comme sa complexité, son exposition réseau ou son historique de failles de sécurité. Une surveillance en temps réel du système permet de capturer des données opérationnelles qui pourraient signaler des comportements anormaux ou des tentatives d'accès suspectes, qui sont souvent les précurseurs d'une exploitation malveillante imminente. Des mesures régulières de l'intégrité de la ressource et des évaluations de configurations, associées à des estimations basées sur l'apprentissage machine des tendances de sécurité, fournissent un tableau de bord dynamique du statut de sécurité. Enfin, la consultation d'une bibliothèque de vulnérabilités connues permet de comparer l'état actuel de la ressource avec les défauts et exploits documentés, permettant ainsi d'identifier et de réagir aux vulnérabilités connues avec une efficacité accrue. Dans un exemple, le délai est en outre représentatif d’une criticité du service. Cela permet d’adapter les mesures de protection compte tenu l'importance du service, garantissant ainsi une allocation optimale des ressources mobilisables à des fins de sécurité informatique. Par exemple le délai avant clonage pourrait être raccourci pour un service de traitement de paiement en ligne d'une banque comparativement à un service de streaming vidéo reflétant la différence de criticité des services concernés. Dans un exemple, le délai est déterminé sur la base d’un paramètre d’environnement de la ressource. Cela permet d’assurer une réactivité accrue face aux changements d'environnement opérationnel ou aux nouvelles menaces détectées. Par exemple, si une ressource opère dans un environnement fonctionnel et/ou géographique avec un taux élevé de tentatives d'intrusion, il peut être prévu de réduire le délai avant le prochain clonage depuis cette ressource pour répondre rapidement à l'évolution de la menace. Dans un exemple, le module de sécurité est configuré pour effectuer le clonage de la ressource avant l'expiration du délai en réponse à une détection d'un événement déclencheur lié à un risque de sécurité concernant la ressource. Cela augmente la résilience du système en permettant une action proactive face aux risques de sécurité émergents. Par exemple, lors de la détection d'un trafic réseau suspect indiquant une possible attaque, il peut être prévu de cloner immédiatement la ressource, réduisant ainsi la fenêtre d'opportunité pour l'attaque de réussir. Dans un exemple, la ressource cible est choisie à l'expiration du délai parmi une pluralité de ressources candidates préalablement identifiées. Cela améliore la continuité du service en ayant des options de récupération prédéfinies, ce qui accélère la reprise après une attaque. Par exemple, après une attaque ayant compromis une ressource, il peut être prévu de rapidement basculer vers un clone déjà identifié, minimisant le temps d'arrêt du service. Cela permet aussi de mettre en œuvre une stratégie trompeuse par la création de leurres. D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels : Fig. 1 FIG. 1 est un ordinogramme représentant un algorithme d’un programme informatique convenant pour mettre en œuvre une stratégie de défense mouvante selon un mode de réalisation. Fig. 2 FIG. 2 montre une architecture informatique en clusters à l’issue d’une opération de clonage mise en œuvre par application d’une stratégie de défense mouvante avec utilisation de leurres selon un mode de réalisation. Fig. 3 FIG. 3 montre une série d’échanges mis en œuvre avant et pendant une procédure de clonage mise en œuvre par application d’une stratégie de défense mouvante selon un mode de réalisation. Dans la description qui va suivre, des chiffres de référence identiques désignent des éléments identiques ou ayant des fonctions similaires. La présente divulgation concerne une technique permettant d’assister un système comprenant un ensemble de ressources, un tel système étant en outre adapté pour gérer un ou plusieurs services déployés dans un environnement informatique en nuage, spécifiquement dans des systèmes de télécommunications. Il est à noter en préambule que le terme « service » est utilisé dans le présent document de manière générale pour englober un service à proprement parler, un ou plusieurs microservices ou même une application complète. On entend par « application » un ensemble de fonctionnalités logicielles qui répondent à un besoin spécifique. Une application peut être composée d'un ou plusieurs services ou microservices qui travaillent ensemble pour fournir la fonctionnalité globale. Il convient de noter que la distinction entre un « service » et un « microservice » repose principalement sur l'échelle et le découpage fonctionnel de l'architecture logicielle d'une application. Un service est une unité fonctionnelle autonome qui peut couvrir un ensemble large de fonctionnalités et qui peut aussi bien former une partie d’une application plus large ou être utilisée par plusieurs applications. Un microservice est plus petit en termes de ressources et est généralement responsable d'une fonctionnalité spécifique d’une application. La gestion du ou desdits services s’effectue notamment par la mise en œuvre, par le système, d’opérations de clonage afin de répliquer des configurations supportant le ou lesdits services. Pour référence, des exemples de système de clonage appropriés sont détaillés dans les techniques de l’art antérieur. De tels systèmes de clonage comprennent notamment un gestionnaire, un orchestrateur et, à titre optionnel, un service virtuel configuré comme un dispositif de routage. Le gestionnaire joue un rôle clé dans le déclenchement du processus de clonage d’une configuration supportant un service. Il est capable de détecter un événement déclencheur résultant de l'application d'une stratégie de gestion du service. À la suite de la détection de cet événement, le gestionnaire définit une ou plusieurs contraintes associées à l'événement et envoie des instructions de clonage à l'orchestrateur. L’orchestrateur, dans l’environnement informatique en nuage, est conçu pour recevoir du gestionnaire une ou plusieurs instructions de clonage et ladite une ou plusieurs contraintes. L'orchestrateur est également capable de recueillir une ou plusieurs informations sur l'utilisation de ressources individuelles issues de diverses agglomérations de traitement de données. Cette ou ces informations sont obtenues avec une granularité suffisante pour permettre une analyse détaillée de l'utilisation de chaque ressource individuelle. L’interprétation de la ou des instructions par l’orchestrateur lui permet de désigner une ou plusieurs ressources définissant un déploiement initial d'un service au sein d'une infrastructure de communication initiale (ou environnement de travail initial). En tenant compte de la ou des instructions de clonage, de la contrainte reçue, et de la ou des informations recueillies, l'orchestrateur peut alors identifier une ou plusieurs ressources cibles dans la même infrastructure de communication, le cas échéant dans le même cluster, ou dans au moins une nouvelle infrastructure de communication. Cela permet un clonage de la ou des ressources désignées, facilitant ainsi un nouveau déploiement du service qui respecte la ou les contraintes spécifiées. Le service virtuel configuré comme un dispositif de routage peut être configuré pour rediriger, à l'issue d'une opération de clonage, tout ou partie d’un trafic réseau du déploiement initial du service concerné vers le nouveau déploiement, de manière transparente pour l'orchestrateur et le gestionnaire. Cela permet une transition fluide et efficace entre le déploiement initial et le nouveau déploiement, contribuant ainsi à la continuité du service. Dans le contexte de la présente technique, le clonage s’inscrit dans une démarche de migration, impliquant non seulement un nouveau déploiement d’un service, mais également une suppression ou une désactivation temporaire ou permanente du déploiement initial du service, de manière à par exemple assurer une continuité de service en anticipation d’une maintenance impliquant une mise hors ligne d’un serveur. Un aspect de la technique proposée dans le présent document est un module de sécurité adapté pour opérer sur un système informatique comprenant un ensemble de ressources, dont une ressource dite « ressource source » contribuant à au moins un service avant l’opération de clonage et une ressource dite « ressource cible » contribuant à l’au moins un service à l’issue de l’opération de clonage, en remplacement de la ressource source. Tous moyens matériels et/ou logiciels adaptés peuvent être utilisés pour la mise en œuvre pratique du module de sécurité. De manière générale, bien que des aspects de la technique proposée puissent être décrits dans le présent document comme étant un processus, un dispositif, un système, une procédure ou une méthode, il est à noter que la technique proposée peut également couvrir une mémoire informatique susceptible d’être raccordée à un processeur éventuellement raccordé à une interface de communication, la mémoire stockant des instructions qui, lorsqu'elles sont exécutées par un tel processeur, permettent de réaliser les processus, dispositifs, systèmes, procédures ou méthodes décrits dans ce document. Il est entendu que, dans le contexte de l’assistance à une opération de clonage, le module de sécurité peut être intégré au système de clonage décrit précédemment et/ou peut être configuré pour communiquer avec le système de clonage de manière à faciliter l’identification par l’orchestrateur d’une ou plusieurs ressources cibles. Quelques termes spécifiques aux systèmes informatiques et aux environnements informatiques en nuage sont à présent clarifiés pour une meilleure compréhension de la technique proposée. L’expression « système informatique » se réfère, dans le contexte du présent document, à un support physique et/ou logiciel qui permet la communication et le partage de ressources et de services dans l’environnement informatique en nuage. Ce système peut désigner une infrastructure de communication ou une ou plusieurs de ses sous-parties, notamment des systèmes de traitement et de stockage de données, des serveurs et des réseaux, des centres de données, des systèmes cloud, des équipements de télécommunication, etc. Ce système peut aussi bien concerner l'infrastructure de communication au sein d'une organisation spécifique, comme un réseau interne d'ordinateurs et de serveurs, ou une infrastructure plus large, comme un réseau de télécommunications ou le cloud. La technique proposée est applicable à tout type de système informatique et à tout type d’architecture réseau. Un système informatique comporte un ensemble de ressources susceptibles d’être réservées aux fins d’un fonctionnement d’un ou plusieurs services. Cet ensemble de ressources peut inclure des ressources de types variés, notamment des temps de calcul au niveau d’un ou plusieurs processeurs, des emplacements d’une ou plusieurs mémoires, ou encore des créneaux d’utilisation, exprimés par exemple en temps et/ou en fréquence, d’un ou plusieurs canaux de communication. Un système informatique peut être étendu sur plusieurs sites et bénéficier de l'efficacité d’une architecture multi-sites. De telles architectures sont bien établies et permettent de renforcer la robustesse et la gestion des ressources au sein de l'ensemble du système informatique. Des architectures distribuées à 'l’edge', c’est-à-dire en périphérie d’un réseau ou d’un système, représentent une évolution supplémentaire particulièrement pertinente pour des systèmes de télécommunications tels que les Cloud-RAN où elles sont en cours de déploiement. Les environnements informatiques en nuage s’appuient sur un ou plusieurs systèmes informatiques tels que définis ci-avant. Notamment, les systèmes de clonage peuvent se confondre avec, comprendre ou être intégrés à un ou plusieurs systèmes informatiques tels que définis ci-avant. Dans les environnements informatiques en nuage, l'unité d'hébergement de base est souvent appelée un « conteneur ». Ces conteneurs sont des unités logicielles légères qui encapsulent le code et toutes ses dépendances, permettant ainsi à une application de s’exécuter de manière fiable d'un environnement informatique à un autre. Pour la gestion de ces conteneurs, une solution appelée "Kubernetes" (marque déposée), K8S, est fréquemment employée. "Kubernetes" (marque déposée) est un système qui facilite le déploiement, la mise à l'échelle et la gestion des applications conteneurisées. Dans l'architecture de "Kubernetes" (marque déposée), les conteneurs sont regroupés en « pods », qui constituent l’unité de base représentant un déploiement d'une application. Plusieurs pods peuvent être regroupés en un « Node » ou « nœud », qui symbolise un serveur. La définition du « Node » ou « nœud » dans l’architecture de "Kubernetes" (marque déposée) correspond à celle du « nœud » dans le système NUMA (en anglais « non-uniform memory access). Ces nœuds sont ensuite regroupés en « clusters », soit des ensembles de serveurs qui travaillent ensemble et peuvent être perçus comme un système unique. Dans le contexte de "Kubernetes" (marque déposée), un cluster est constitué d'un groupe de « Masters » et de Nodes. Les Masters sont les composants du cluster "Kubernetes" (marque déposée) qui fournissent l'interface de contrôle pour le cluster, et qui gèrent l'ordonnancement des pods, la détection et la gestion des échecs, ainsi que le déploiement de nouvelles versions des applications. Les Nodes, quant à eux, sont les serveurs qui exécutent les applications et qui fournissent l'environnement d'exécution pour les conteneurs. Pour gérer les communications réseau entre les conteneurs d'une application déployée sur un cluster "Kubernetes" (marque déposée), des conteneurs sidecar de type proxy sont attachés en coupure à chaque conteneur principal de l’application. Les proxys sidecar sont responsables de l'interception et de la gestion des communications réseau. Chaque proxy sidecar agit en tant qu'intermédiaire entre le conteneur principal auquel il est attaché et le reste du réseau. Pour renforcer la sécurité, les proxys sidecar peuvent inclure des fonctions telles que la validation des requêtes et des réponses, la gestion des autorisations et des identités, ainsi que la surveillance. ISTIO (https://istio.io/) est un exemple de maillage de services open source, couramment utilisé par des opérateurs de mise en réseau et de sécurité pour l’exécution d’applications distribuées basées sur des microservices, et qui fournit une manière uniforme de connecter, gérer et sécuriser ces microservices à l’aide de proxys sidecar. La technique proposée se rapporte à la mise en œuvre d’opérations de clonage, par exemple par un système de clonage tel que décrit précédemment. Une opération de clonage décrite modifie la disposition des ressources qui supportent les services ou micro-services en les transformant. A cet effet, on peut par exemple définir un état initial du système informatique à un instant initial avant une mise en œuvre d’une opération de clonage relative à un service et un état final du système informatique à un instant final après la mise en œuvre de l’opération de clonage. A l’instant initial, le système informatique est configuré de telle sorte qu’une ou plusieurs ressources de l’ensemble de ressources interviennent pour un déploiement initial du service, cette ou ces ressources sont qualifiées de ressources source. A l’instant final, le système informatique est configuré de telle sorte qu’une ou plusieurs ressources de l’ensemble de ressources, différentes de et en remplacement de la ou des ressources source, interviennent pour un nouveau déploiement du service, cette ou ces ressources sont qualifiées de ressources cibles ou ressources de destination. La technique proposée est particulièrement adaptée aux architectures de micro-services, telles que les conteneurs et les fonctions réseau virtuelles. Ces dernières sont couramment utilisées dans les systèmes de télécommunications et dans les environnements informatiques basés sur le cloud. Les opérations de clonage, au cœur de la technique proposée, offrent des avantages sécuritaires pour les applications critiques. Elles changent la topologie des systèmes, s'inscrivant dans une stratégie de défense mouvante. En outre, elles permettent de dupliquer ou de créer des copies redondantes de certains déploiements de services, ce qui contribue à améliorer les performances globales de ces services. La sélection de la ressource cible parmi l’ensemble de ressources disponibles peut avantageusement s’appuyer sur la reconnaissance et la gestion dynamique d'éléments tels que les groupes de conteneurs ou pods, les ensembles de serveurs ou clusters et les applications elles-mêmes. Des scénarios bénéficiant d’une gestion efficace de l'environnement "Kubernetes" (marque déposée) sont particulièrement adaptés. Cette gestion efficace peut inclure la gestion des permissions à travers un système de contrôle d'accès basé sur les rôles (RBAC), l'assurance de la sécurité des images de conteneurs, et l'utilisation de clusters virtuels sauvegardés par un même cluster physique, ou « namespaces » en anglais, pour isoler les différents clients. En résumé, la sélection d’une ressource cible destinée à contribuer à un nouveau déploiement d’un service à l’issue d’une opération de clonage en remplacement d’une ressource source peut prendre en compte plusieurs facteurs, tels que le type d'acteurs impliqués, la catégorie de clients, la chaîne de micro-services concernée, ainsi que les aspects techniques et fonctionnels liés à l'hébergement. Le déploiement des services et des données, facilité par les opérations de clonage, peut s'étendre efficacement sur les divers clusters de plusieurs clouds. Cette stratégie de répartition peut englober différents niveaux géographiques, allant du cloud centralisé jusqu'aux niveaux plus décentralisés comme le fog, l'edge et le far edge et peut traiter de manière différenciée les ressources provenant de divers fournisseurs de cloud, permettant une gestion des ressources à la fois flexible et efficace. Cette polyvalence peut être alignée sur une politique de qualité de service basée sur des besoins spécifiques des services déployés et conçue pour assurer une répartition optimale des charges et une meilleure continuité des services dans des architectures évolutives. A titre d’illustration, la demande de brevet FR2306267 prévoit une procédure d’identification de ressources de destination pour la mise en œuvre d’un clonage selon une politique consciente des ressources. La demande de brevet FR2310610 prévoit en outre une procédure permettant de prendre en compte l’affinité entre processus et données pour la détermination au sein de l’ensemble de ressources d’une ou plusieurs ressources de destination appropriées parmi un ensemble plus grand de ressources potentielles. Les procédures détaillées dans ces demandes de brevet sont orientées vers la recherche de performance. En revanche, ces demandes de brevet ne divulguent aucune stratégie particulière en matière de sécurité informatique. Parallèlement, CHO, JH et al. Toward Proactive, Adaptive Defense: A Survey on Moving Target Defense. IEEE Communications Surveys & Tutorials, 22, 2019, pages 709-745 présente, dans un contexte de prolifération de cyberattaques, un ensemble de solutions pro-actives et adaptives de défense permettant de déconcerter, décourager les attaquants et prévenir les attaques. Ces solutions relèvent du concept général dit de défense mouvante ou dynamique, en anglais, « Moving Target Defense », MTD. Les cyberattaques susceptibles de viser des systèmes informatiques dans des environnements informatiques en nuage sont de natures diverses. Parmi les types de cyberattaques courantes, on peut citer les attaques par déni de service distribué ou attaques DDoS (en anglais «distributed denial of service attack ») ou des tentatives d’intrusion par différents biais. Certaines cyberattaques peuvent être particulièrement sophistiquées, en particulier les menaces persistantes avancées ou APT (en anglais « Advanced Persistent Threat »). Il apparait particulièrement avantageux de mettre en place un système pro-actif et adaptif de défense mouvante s’appuyant sur des capacités de clonage dans le contexte des systèmes informatiques dans des environnements informatiques en nuage. Dans ce but, il est proposé un module de sécurité configuré pour déclencher, initier, commander, programmer ou effectuer une opération de clonage d'une ressource de l’ensemble de ressources d’un tel système informatique. Le module de sécurité est guidé dans cette tâche par un délai calculé, déterminé, estimé, choisi ou obtenu en fonction d’une vulnérabilité estimée de la ressource. La « vulnérabilité » d'une ressource peut être comprise comme sa susceptibilité à être compromise ou affectée négativement. Cette vulnérabilité peut se manifester de différentes manières, telles que la facilité avec laquelle un service peut être détourné, la probabilité de détection par les attaquants, ou la simplicité de localisation et d'accès par des éléments non autorisés. La « vulnérabilité estimée » d’une ressource est définie sur la base d’un ou plusieurs attributs relatifs à un effort potentiel ou estimé pour compromettre ou affecter des dommages à cette ressource. Le nombre de ces attributs est quelconque. Un ou plusieurs de ces attributs peuvent par exemple contribuer à définir une signature de la ressource ou du service auquel elle contribue, tels qu’un nombre de sessions actives, un taux d’utilisation en matière de charge et/ou de mémoire, un type et un volume de données traitées, ou une fréquence d’interactions avec d'autres nœuds ou services. Ces divers attributs, qui capturent chacun un aspect spécifique de la vulnérabilité d'une ressource, peuvent être regroupées dans une métrique quantitative générale appelée « surface d'attaque ». La surface d'attaque d’une ressource peut ainsi être définie comme représentative de l'ensemble des points d'entrée, canaux et éléments de données non fiables, en d’autres termes la quantité d’opportunités exploitables par des attaquants pour compromettre ou affecter négativement la ressource. En pratique, la surface d'attaque d’une ressource est calculable en affectant des valeurs numériques aux attributs du service ou de la ressource, en se basant sur une connaissance du système et de son environnement en termes de clusters, proxys, nodes ou pods. De manière non exhaustive, on peut citer un nombre de clients utilisant le service, un nombre de ressources physiques impliquées, telles que des pods, proxys, nœuds, ou clusters, un nombre de flux de données ou de messages inter-nœuds impliqués, un degré de criticité de ces ressources physiques, flux de données, ou messages inter-nœuds, ou encore un degré de facilité d’accès à ces ressources physiques ou de facilité d’interception de ces flux de données ou messages inter-nœuds. Par extension, la surface d’attaque d’un service est calculable sur la base des surfaces d’attaque de chacune des ressources contribuant au service. Réduire une surface d’attaque d’une ressource revient à diminuer la probabilité de détection de la ressource par des attaquants en agissant sur un ou plusieurs paramètres contrôlables. Parmi ces paramètres, l’un des plus simples à contrôler est le temps de présence ou de localisation, défini comme la durée séparant l’affectation d’une ressource source à un service avant l’opération de clonage de l’affectation d’une ressource cible à ce service à l’issue de l’opération de clonage en remplacement de la ressource source. Un aspect central de la technique proposée repose sur l’utilisation de la vulnérabilité estimée ou la surface d'attaque comme indicateur pour fixer un délai indiquant le moment optimal de déclenchement d'une opération de clonage. Ce délai peut être choisi en fonction des risques identifiés et de la nécessité de maintenir la continuité et l'efficacité des services concernés. La valeur retenue pour le délai est déterminée, calculée ou choisie de manière différenciée pour chaque ressource ou pour chaque service. Par exemple, en se référant à une ressource particulière ou un service particulier, la valeur retenue pour le délai peut être sélectionnée parmi un éventail de valeurs possibles prédéfinies en fonction de la vulnérabilité estimée de cette ressource ou de ce service. Chacune des valeurs possibles peut par exemple être associée par avance, dans une table de correspondance, à une gamme de vulnérabilités estimées. La détermination du délai peut être adaptative. Elle peut s’appuyer sur une surveillance en temps réel, prenant en compte des facteurs comme la fréquence des attaques et la nécessité de ne pas impliquer un nœud parent compromis. Elle peut également s’appuyer sur une information représentative d’une capacité à répondre aux événements. Des opérations de clonage trop fréquentes peuvent impacter la disponibilité des services pour les utilisateurs, d'où la nécessité d'un équilibre optimal entre un objectif de sécurité système et un objectif de performance en matière par exemple de qualité de service et/ou d’expérience. La technique proposée peut adopter une stratégie hybride en matière de cybersécurité. Les opérations de clonage peuvent être mises en œuvre par défaut selon une programmation périodique, comme le clonage de toutes les ressources contribuant au déploiement d’un ou plusieurs services à intervalles de temps réguliers. Outre les approches de programmation périodique, la technique peut intégrer des opérations de clonage non périodiques pour améliorer la sécurité. Par exemple, le clonage peut être déclenché de manière aléatoire, à des intervalles irréguliers pour réduire la prévisibilité. Une autre approche pourrait être basée sur des modèles heuristiques ou des algorithmes d'apprentissage automatique qui déterminent le moment optimal pour le clonage en analysant des tendances de sécurité complexes. Ces algorithmes pourraient prendre en compte non seulement les événements de sécurité mais aussi des paramètres opérationnels variables, comme la charge du système ou la disponibilité des ressources, pour optimiser à la fois la sécurité et l'efficacité du système. Une telle programmation périodique ou non, également connue sous l’expression anglaise « IP shuffling », crée un mouvement constant dans la structure de l’environnement en nuage, rendant difficile pour les attaquants de cibler et de compromettre des nœuds spécifiques. Indépendamment ou en complément de la possibilité d’une telle activation périodique, le clonage peut également être déclenché par des indicateurs de compromission ou des seuils prédéfinis, où le système réagit automatiquement lorsqu'une certaine condition est remplie, ajoutant ainsi une couche supplémentaire de réponse adaptative face aux menaces en constante évolution. Par exemple, des opérations de clonage peuvent être déclenchée de manière événementielle, immédiatement ou à bref délai, en réaction à une détection d'attaques ou d'anomalies telles que des consommations d'énergie anormales ou des excès de messages inter-nœuds. Outre la détermination d’un délai spécifique pour la mise en œuvre du clonage, des stratégies de sécurité informatique complémentaires peuvent être mises en œuvre. Une stratégie potentielle concerne la création de faux nœuds en phase de pré-déploiement, c’est-à-dire préalablement à la mise en œuvre de l’opération de clonage en tant que telle. Cette stratégie trompeuse permet de masquer la véritable structure et l'activité du réseau et ainsi de tromper les attaquants potentiels. Indépendamment ou en complément de cette stratégie trompeuse à base de faux nœuds, les opérations de clonage peuvent aussi bien mettre en œuvre une simple réincarnation de nœuds, c’est-à-dire une utilisation d’un seul nœud cible en remplacement d’un nœud source, correspondant à une forme de redondance, c’est-à-dire une utilisation de plusieurs nœuds cibles en remplacement d’un seul nœud source. La redondance contribue non seulement à l’amélioration de performance, mais également à la sécurité informatique en modifiant la signature du service. En complément des opérations de clonage, une autre stratégie de sécurité informatique envisageable est l'installation d'un réseau de microservices conçu pour être isolé du reste de l'infrastructure physique. Cette isolation se réalise grâce à des communications sécurisées et exclusives au sein de chaque groupe de conteneurs ou pod. Pour sécuriser ces communications, on peut utiliser une méthode connue de chiffrage et/ou d’authentification, telle que par exemple le mTLS, ou « Mutual Transport Layer Security ». Il est présent fait référence à la FIG. 1 , qui représente un exemple possible d’algorithme permettant la mise en œuvre de la technique proposée au niveau d’un système de clonage adapté pour mettre en œuvre des opérations de clonage au sein d’un ou plusieurs systèmes informatiques dans un environnement informatique en nuage. Il est prévu : un module 1 de définition et de mise à jour de politique de sécurité (DEF POL SEC), un module 2 de déploiement de la politique de sécurité (DEPL POL SEC), un module 3 de préparation de l’infrastructure (PREP INFRA), un module 35 de gestion de situations où la politique de sécurité ne peut pas être mise en œuvre (DEFT) un module 4 d’identification des ressources nécessaires au déploiement sécurisé des services (ID RES), un module 45 d’application de la politique de sécurité (APPL POL SEC), un module 5 de suivi en temps réel (SURV), un module 6 de mise à jour des informations de topologie à l’issue des opérations de clonage (MAJ TOPO), et un module 7 de mise à jour du routage des services (MAJ INFO ROUT). Le module 1 de définition et de mise à jour de politique de sécurité est configuré pour mettre en place une politique de sécurité sur un système informatique, par exemple un serveur de télécommunications. La politique de sécurité inclut, au moins, un mécanisme de défense mouvante qui peut être englobée dans une stratégie défensive hybride. Celle-ci combine par exemple redondance, en dispersant les ressources sur plusieurs clusters et réincarnation périodique de nœuds, pour renouveler et protéger le réseau de télécommunications, ou encore la création de leurres ajoutant une couche de complexité à la structure réelle du réseau. Face aux attaques par déni de service, une réaction proactive peut impliquer un changement périodique de cluster d’hébergement, de telle sorte que pour chaque opération de clonage, le cluster comprenant la ressource source et le cluster comprenant la ressource cible ne sont pas colocalisés. Une réaction réactive pourrait combiner cette réincarnation inter-cluster avec une génération de leurres, ou faux nœuds, dans le cluster initial pour désorienter les attaquants. Pour contrer les intrusions, il est possible de mettre en œuvre le clonage des ressources d'un cluster affecté spécifiquement vers d'autres clusters. Une approche trompeuse peut se coupler à ce clonage en cas de détection d'intrusion sur plusieurs clusters, créant un environnement plus complexe et plus difficile à exploiter pour les attaquants. Les services d'une criticité supérieure, susceptibles d'être ciblés par des menaces persistantes avancées, peuvent bénéficier d'une stratégie proactive et réactive renforcée. Cette stratégie comprend la distribution redondante des ressources à travers plusieurs clusters pour un isolement et une réactivité instantanée en cas d'incident, ainsi que l'exécution d'opérations de clonage périodiquement et/ou en réponse à des événements spécifiques identifiés par une surveillance continue. Les services moins sensibles peuvent s'appuyer sur une sécurisation allégée, évitant par exemple la nécessité d'une répartition des ressources sur plusieurs clusters. La flèche 'a' indique un processus de transmission de directives relatives à la politique de sécurité du module 1 vers le module 2 de déploiement de la politique de sécurité pour leur mise en œuvre. Les fonctions du module 2 peuvent être remplies de manière centralisée, par exemple par un gestionnaire ou un orchestrateur d’un système de clonage. Il collecte des métriques afin de surveiller l'activité en temps réel au sein du système informatique et définit des règles de sécurité dont l’application déclenche la détermination de délais spécifiques pour le clonage des ressources en fonction de leur vulnérabilité estimée respective. La détermination de délais spécifiques s’effectue de manière différenciée par service ainsi que par ressource contribuant au service. La détermination de délais spécifiques par application d’une règle de sécurité correspondant à l’application d’une stratégie réactive dépend également du type d’événement détecté. La flèche 'b' représente une communication entre le module 2 et le module 3 de préparation de l'infrastructure, pour assurer que l'infrastructure est prête à appliquer la politique de sécurité. Le module 3 est configuré pour mettre en place un mécanisme de collecte en temps réel d’indicateurs pour surveiller l’efficacité de la politique de sécurité et/ou son impact sur d’autres aspects tels que la performance des services déployés, le taux d’utilisation de ressources ou la consommation d’énergie. La flèche ‘c’ représente une communication du module 3 vers le module 4, symbolisant un transfert des informations nécessaires à l'identification des ressources après la préparation de l'infrastructure. La flèche ‘j’ représente une communication du module 3 vers le module 35 indiquant une situation où il n'est pas possible d'appliquer la politique de sécurité. Le module 4 d’identification des ressources nécessaires au déploiement sécurisé des services peut être configuré pour repérer non seulement les ressources initiales, dites ressources sources, qui sont actuellement en service, mais aussi pour désigner les ressources de remplacement, ou ressources cibles, ainsi que les éventuelles ressources leurres utilisées dans des stratégies trompeuses en simulant de fausses cibles. Le module 4 peut être configuré pour identifier, outre les ressources en tant que telles (par exemple des nœuds, pods ou clusters) d’autres éléments qui y sont associés (par exemple des informations DNS) et impliqués dans les changements de topologie résultant de la mise en œuvre d’opérations de clonage. Le module 4 peut être configuré pour prendre activement part aux stratégies de sécurité impliquant des actions de modification de topologie, telles que l'effacement, le déplacement ou l'activation de nœuds, afin de réagir de manière flexible, proactive et/ou réactive aux diverses situations de menace. Par exemple, dans le cadre d'une stratégie réactive, si une attaque par déni de service ou une tentative d’intrusion est détectée sur un nœud spécifique, le module 4 est capable de déterminer rapidement si le nœud visé est un leurre ou une véritable ressource opérationnelle. Si le nœud visé est authentique, le module peut être configuré pour initier sa suppression sécurisée et activer une ressource de remplacement, ce qui permet de maintenir la prestation de service tout en éliminant le point de vulnérabilité exploité par l'attaque. Le module 4 peut en outre être configuré pour identifier des ressources cibles en prenant en compte un ensemble de besoins et contraintes, par exemple à l’aide d’un algorithme d’optimisation conjoint de ces besoins et contraintes. Ces besoins et contraintes peuvent se rapporter par exemple au fonctionnement d’un service auquel contribuent des ressources source, au fonctionnement conjoint d’autres services, à des impératifs de sécurité ou encore à des impératifs techniques de l’infrastructure informatique. L’identification de ressources cibles peut inclure la mise en œuvre de règles de géo-réplication, en identifiant des nœuds cibles dans différents emplacements géographiques en cas de défaillance ou de compromission d'un nœud. La flèche ‘d’ représente une communication du module 4 vers le module 45. Cette communication permet de reporter au module 45 les ressources préalablement identifiées par le module 4 et ainsi de permettre au module 45 de mettre en œuvre la politique de sécurité en gérant ces ressources préalablement identifiées par le module 4. La flèche ‘e’ indique une initiation d’un suivi en temps réel relatif aux ressources préalablement identifiées par le module 4 et gérées par le module 45. Le module 5 de suivi en temps réel est configuré pour mettre en œuvre une surveillance, incluant par exemple une obtention de mesures et/ou un mécanisme de détection d’attaques. Il peut être configuré de manière à permettre de stopper immédiatement les nœuds affectés par une attaque, enclenchant ainsi leur réincarnation sans leur participation, pour minimiser l'impact sur les applications distribuées. Le module 5 peut être configuré de manière à empêcher une opération de clonage initialement prévue dans certaines situations. Par exemple dans un scénario où une ressource contribuant au fonctionnement d’un service est considérée comme compromise, c’est-à-dire potentiellement contrôlée par un tiers malveillant, il peut être prévu d’isoler cette ressource en l’empêchant de poursuivre sa contribution au fonctionnement d’un service et de ne pas déclencher le clonage de cette ressource vers une ressource cible. Dans un autre exemple, une opération de clonage qui occasionnerait une dégradation excessive de performance peut être retardée ou annulée. La flèche avec l’annotation « Nk » indique une communication du module 5 vers le module 4 lorsque le suivi en temps réel détecte un événement lié à un risque de sécurité concernant la ressource. Cette communication permet de déclencher, au niveau du module 4, une reconsidération des ressources nécessaires au déploiement sécurisé des services compte tenu du problème détecté incluant potentiellement une nouvelle identification de ressources cibles et/ou de leurres en vue d’une future opération de clonage. La flèche ‘f’ avec l’annotation « Ok » partant du module 5 vers le module 6, illustre une procédure de clonage et de déclenchement d’une mise à jour des informations de topologie faisant suite à un suivi en temps réel réussi et ne détectant aucun événement lié à un risque de sécurité concernant la ressource. Le module 6 de mise à jour des informations de topologie à l’issue des opérations de clonage est configuré pour maintenir à jour les informations sur la configuration actuelle du réseau, reflétant les changements réalisés par application de la politique de sécurité. La flèche ‘g’ partant du module 6 vers le module 7 illustre une communication permettant d’assurer que toute mise à jour de la topologie est reflétée dans la mise à jour du routage des services. Le module 7 de mise à jour du routage des services est configuré pour adapter le routage aux nouvelles configurations des serveurs et à la nouvelle topologie du réseau. La flèche ‘h’ avec l’annotation « Timer 4 » partant du module 7 vers le module 4 illustre un retour d’information à l’issue de la mise à jour du routage, permettant de confirmer que des ressources cibles préalablement identifiées par le module 4 peuvent être considérées comme nouvelles ressources source à la suite de la réalisation d’opérations de clonage. Les flèches ‘j’’, 'g'', et ‘h’’ avec l'annotation « i, Timer 1 », partant respectivement des modules 35, 6 et 7 vers le module 1, représentent des retours d'information permettant une réévaluation de la politique de sécurité par le module 1. Il est à présent fait référence à la FIG. 2 qui illustre de manière schématique deux clusters "Kubernetes" (marque déposée) 100, 200. Chaque cluster est composé d’un plan de contrôle et de plusieurs nœuds. Le plan de contrôle 102, 202 est responsable de la gestion et de la coordination des différents éléments du cluster. En particulier, le plan de contrôle comporte des modules de commande (« Controllers » en anglais) chargés de surveiller l’état du cluster et d’effectuer des actions pour maintenir, ou parvenir à, l’état souhaité. Il existe par exemple des modules de commande pour gérer des déploiements, des services, des réplicas, entre autres. Un gestionnaire de modules de commande (« Controller Manager » en anglais) est responsable de l’exécution de ces modules de commande. D’autres composants du plan de contrôle jouent des rôles spécifiques. Un serveur API (« API Server » en anglais) est prévu pour exposer l’API de "Kubernetes" (marque déposée) et sert de principal point d’entrée pour interagir avec le cluster. Un équilibreur de charge (« Load Balancer » en anglais) permet de répartir la charge du trafic entrant vers différents services en distribuant le trafic entre les nœuds du cluster ou entre des pods fonctionnant sur différents nœuds. Un ordonnanceur (« Scheduler » en anglais) est chargé d’attribuer les pods aux nœuds du cluster en fonction de besoins en ressources, de contraintes et de politiques définies. Une base de données appelée ETCD stocke en temps réel l’état du cluster "Kubernetes" (marque déposée), y compris des informations sur les nœuds, les pods, les services, les configurations, etc.... Elle rend ces informations accessibles en lecture et en écriture à tous les composants du cluster en temps réel. Il est considéré qu’à un instant donné, l’ensemble du plan de contrôle d’un cluster donné, ou au moins l’un de ses composants, tels que le gestionnaire de modules de commande, un module de commande spécifique, le serveur API, l’équilibreur de charge, ou l’ordonnanceur, joue le rôle d’un orchestrateur mettant en œuvre une procédure de clonage déclenchée par un module de sécurité selon la technique proposée. Chaque cluster 100, 200 comporte également plusieurs nœuds 110, 120, 130, 210, 220, 230 qui contiennent eux-mêmes des pods 112, 122. Chaque pod peut correspondre au déploiement d’une application, représenté par un cube. Certains pods d’intérêt 114, correspondant à des déploiements d’applications spécifiques, sont également représentés avec des proxys sidecar 116, représentés par des ronds près des cubes. La FIG. 2 représente une topologie des clusters 100, 200 à l’issue d’une procédure de clonage, dans un exemple de réalisation. Le plan de contrôle 102 d’un cluster comprenant un nœud 110 en tant que ressource source a identifié dans ce même cluster un nœud 130, ainsi qu’un pod 122 en tant que leurres. Le plan de contrôle 102 du cluster comprenant le nœud source 110 a interagi avec le plan de contrôle 202 d’un autre cluster 200, ce qui a permis de désigner un nœud 230 situé dans cet autre cluster en tant que ressource cible. En l’absence d’attaque et à l’expiration d’un délai prédéfini fonction d’une vulnérabilité estimée du nœud source 110, ou sur détection d’une attaque visant le nœud 130 ou le pod 122, la procédure de clonage a été mise en œuvre, répliquant le nœud source 110 dans le nœud cible 230. La FIG. 2 est à considérer comme illustrant un exemple simplifié de stratégie de défense mouvante. Des actions complémentaires peuvent être mises en œuvre, par exemple il peut être prévu de désigner une pluralité de nœuds cibles situés dans un ou plusieurs clusters en tant que ressources cibles et de répliquer le nœud source 110 dans chaque nœud cible ainsi désigné. En complément de la redondance ainsi obtenue, une stratégie adaptée de routage vers les nœuds cibles peut offrir une brique de sécurité supplémentaire. Cette stratégie peut comprendre l'adoption d'un routage intelligent qui analyse en temps réel le profil de la menace et le niveau de risque associé à chaque nœud cible. En ajustant le routage basé sur ces évaluations, le système peut diriger le trafic vers les nœuds jugés les plus sûrs à un moment donné. De manière générale, la défense mouvante peut combiner une stratégie de clonage et de routage avancée et adaptative pour créer un système de défense en profondeur, rendant le paysage de sécurité du système informatique en nuage beaucoup plus résilient et moins prévisible pour les attaquants. Il est à présent fait référence à la FIG. 3 qui décrit une procédure de gestion de services dans un environnement de cloud computing qui utilise une stratégie de défense mouvante. La procédure est représentée par une série d’échanges entre un orchestrateur, une base de données, un cluster 100 d’hébergement d’une ressource source contribuant à une ancienne instance d’un service et un cluster 200 destiné à héberger, à l’issue de la procédure, une ressource cible contribuant à une nouvelle instance du service. L'orchestrateur (ORCH) demande 11 à la base de données (DB) de chercher un service (SRC SRVID) par son nom ou identifiant et la base de données répond 12 en fournissant l'identifiant (SRVID) du service. L'orchestrateur commande 13 la création d'une nouvelle instance de service (CR SRVID) dans le cluster 200 en utilisant l'identifiant du service fourni et le cluster 200 confirme 14 la création de la nouvelle instance de service (SRVID). L'orchestrateur demande 15 la création d'une nouvelle cible pour le service (CR SRVTGTID) dans le cluster 200 et le cluster 200 confirme 16 que la cible du service a été créée avec l’identifiant du service (SRVTGTID). La création de la nouvelle cible implique l’identification d’une ressource cible au sein du cluster 200 puis la mise en œuvre d’une procédure de clonage depuis la ressource source au sein du cluster 100 vers la ressource cible. La création de la nouvelle cible de service peut en outre inclure la création d’une ou plusieurs fausses cibles ou leurres pour détourner ou confondre les attaquants potentiels, ajoutant une couche supplémentaire de sécurité. L'orchestrateur modifie 17 le poids de la nouvelle instance de service dans le routage (SRV WGT 100) pour que tout le trafic soit dirigé vers la nouvelle instance. Ceci représente l'activation du nouveau service ou la redirection du trafic dans le cadre de la stratégie de défense mouvante. Le cluster 200 confirme 18 que le poids (WGT 100) du service virtuel a été modifié, ce qui indique que la nouvelle instance est désormais en service et traite le trafic. L'orchestrateur réduit 19 le poids de l'ancienne instance de service à 0 (SRV WGT 0) pour que plus aucun trafic ne soit dirigé vers elle. Ceci représente un retrait ou une rotation d’instances du service, encore une fois dans l'esprit de la stratégie de défense mouvante. Le cluster 100 confirme 20 que le poids (WGT 0) de l'ancienne instance de service virtuel a été réduit à 0, complétant le processus de basculement vers la nouvelle instance. Dans le cadre de la stratégie de défense mouvante, la demande 15 de création de la nouvelle cible, ainsi que les modifications 17 et 19 des poids respectifs de la nouvelle et de l’ancienne instance de service dans le routage représentent des résultats possibles d’une action de déclenchement mise en œuvre par un module de sécurité intégré ou raccordé à l’orchestrateur pour effectuer un clonage de la ressource source vers la ressource cible. En intégrant la stratégie de défense mouvante, cette procédure ne se limite pas à cloner simplement les services, mais elle manipule activement le routage du trafic pour augmenter la difficulté pour un attaquant de cibler ou de compromettre un service spécifique. En alternant entre les instances de service et en modifiant leur poids, c’est-à-dire leur priorité dans le routage du trafic, l’environnement de réseau reste en constante évolution, ce qui le rend plus difficile à attaquer efficacement. Les présentes solutions techniques peuvent trouver à s’appliquer auprès d’opérateurs et entreprises désireux de renforcer la sécurité de leurs applications et services fonctionnant dans des environnements basés sur les conteneurs et les micro-services. Elles sont particulièrement adaptées pour la gestion de systèmes au sein d'environnements informatiques en nuage, que ce soit privés ou hybrides, combinant des éléments privés et publics. Elles jouent un rôle clé dans la protection des bases de données, dont les points d'accès constituent souvent des vulnérabilités. Bien que ces bases soient situées dans des emplacements fortement sécurisés, leur accès se fait fréquemment via des infrastructures partagées entre des domaines privés et publics, ce qui peut présenter des risques. Ces solutions sont adaptées à diverses configurations de clusters, qu'ils soient localisés sur un seul site ou répartis sur plusieurs sites et gérés par différents acteurs, comme dans le cas des configurations de Cloud-RAN. Des exemples d'application peuvent concerner une grande variété de systèmes et d’infrastructures, par exemple des clusters exploités par de multiples acteurs, répartis sur différentes zones géographiques, et étendus sur plusieurs centres de données, ou un cluster principal avec des répliques distribuées sur plusieurs centres de données, ou encore des clusters multi-acteurs et multi-zones connectant des satellites à des centres de données terrestres. La présente divulgation ne se limite pas aux exemples décrits ci-avant, seulement à titre d’exemple, mais elle englobe toutes les variantes que pourra envisager l’homme de l’art dans le cadre de la protection recherchée. Module de sécurité adapté pour opérer sur un système comprenant un ensemble de ressources , le système étant adapté pour gérer au moins un service dans un environnement informatique en nuage, le système étant adapté pour mettre en œuvre des opérations de clonage, une opération de clonage impliquant une ressource source (110) contribuant à l’au moins un service avant l’opération de clonage et une ressource cible (230) contribuant à l’au moins un service à l’issue de l’opération de clonage, en remplacement de ladite ressource source, le module étant configuré pour effectuer un clonage d'une ressource de l’ensemble conformément à un délai représentatif d’une vulnérabilité estimée de ladite ressource. Module de sécurité selon la revendication 1, dans lequel le délai est déterminé sur la base d’une information de sécurisation de la ressource. Module de sécurité selon la revendication 1 ou 2, dans lequel le délai est en outre représentatif d’une criticité du service. Module de sécurité selon la revendication 3, dans lequel le délai est déterminé sur la base d’un paramètre d’environnement de la ressource. Module de sécurité selon l’une des revendications 1 à 4, configuré pour effectuer le clonage de la ressource avant l'expiration du délai en réponse à une détection d'un événement déclencheur lié à un risque de sécurité concernant la ressource. Module de sécurité selon l’une des revendications 1 à 5, dans lequel la ressource cible est choisie à l'expiration du délai parmi une pluralité de ressources candidates préalablement identifiées. Procédé mis en œuvre par un module de sécurité adapté pour opérer sur un système comprenant un ensemble de ressources, le système étant adapté pour gérer au moins un service dans un environnement informatique en nuage, le système étant adapté pour mettre en œuvre des opérations de clonage, une opération de clonage impliquant une ressource source (110) contribuant à l’au moins un service avant l’opération de clonage et une ressource cible (230) contribuant à l’au moins un service à l’issue de l’opération de clonage, en remplacement de ladite ressource source, le procédé comprenant : effectuer un clonage d'une ressource de l’ensemble conformément à un délai représentatif d’une vulnérabilité estimée de ladite ressource. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon la revendication 7 lorsque ce programme est exécuté par un processeur. Support d’enregistrement non transitoire lisible par un ordinateur sur lequel est enregistré un programme pour la mise en œuvre du procédé selon la revendication 7 lorsque ce programme est exécuté par un processeur.