FR 3070778 A1 20190308 FR 1758228 A 20170906 SYSTEME ET PROCEDE D'AUTHENTIFICATION D'INSTRUCTIONS DE GESTION DE RESSOURCES INFORMATIQUES D'UN SERVEUR DE VIRTUALISATION Description Domaine technique de l'invention. L'invention a pour objet un système et un procédé d'authentification d'instructions de gestion de ressources informatiques d'au moins un serveur de virtualisation, c'est-à-dire d'un serveur pouvant porter des machines virtuelles. 15 Elle concerne le domaine technique des systèmes de gestion de l'information et, plus précisément, la gestion des ressources informatiques dans un environnement virtualisé. 20 État de la technique. La «virtualLsation» est une technique informatique consistant à faire fonctionner plusieurs systèmes d'exploitation, serveurs ou applications, sur un même serveur physique. Une infrastructure informatique virtuelle offre la capacité 25 de gérer des ressources informatiques mises en commun dans une entreprise, permettant de mieux répondre aux besoins organisationnels dynamiques et de tirer le meilleur parti des investissements dans l'infrastructure. 10 Une infrastructure informatique virtuelle comprend généralement un ou 30 plusieurs serveurs de virtualisation disposant chacun de ressources informatiques. - 2 - Tout ou partie de ces ressources informatiques sont allouées dans une pluralité de machines virtuelles (ou VM pour Virtual Machine) isolées les unes par rapport aux autres, et chacune dotée d'un système d'exploitation et d'applications informatiques. Chaque VM est une entité autonome et indépendante. L'installation 5 de plusieurs VM permet d'exécuter différents systèmes d'exploitation et applications sur un seul et même serveur physique, ou « hôte ». Un gestionnaire (ou VMM pour Virtual Machine Manager) de VM, également connu sous le nom d'hyperviseur, exécute des opérations de gestion des ressources informatiques du serveur de virtualisation en fonction d'instructions. La formulation de telles instructions peut être externalisée et prise en charge par un orchestrateur qui, grâce à une vision globale des états des différents serveurs de virtualisation et du réseau les interconnectant, est apte à prendre de meilleurs décisions globales par rapport au cas où le serveur prendrait de telles décisions de manière autonome, sur la base d'informations locales au serveur. Lorsque les instructions sont formulées par un orchestrateur, puis envoyées aux serveurs de virtualisation pour leur exécution, on parle d'instruction d'orchestration. Une instruction est ici une requête portant un ordre qui doit être réalisé par le récepteur. En pratique, le VMM reçoit de l'orchestrateur des instructions sur la façon de créer, détruire, modifier, copier, migrer des VM, manuellement ou automatiquement. En outre, le VMM fournit des fonctionnalités spécifiques pour exécuter plusieurs systèmes d'exploitation distincts. Le VMM consiste généralement en une couche logicielle adaptée pour découpler les VM de l'hôte et allouer dynamiquement les ressources informatiques aux différentes VM suivant les besoins. Cette architecture des infrastructures informatiques virtualisées est sensible aux attaques qui peuvent venir d'horizons différents. En particulier, en générant des instructions d'orchestration fallacieuses, une personne mal intentionnée peut obtenir la création, destruction, modification, copie ou migration malicieuses de VM pour, par exemple, effectuer des attaques externes de type DDOS (pour 3 l'anglais Distributed Denial Of Service) visant à rendre l'hôte, un service et/ou l'infrastructure informatique indisponibles, en surchargeant la bande passante ou en accaparant les ressources informatiques jusqu'à épuisement. Des attaques internes sont également possibles, telles que des attaques MITM (pour Man-in- 5 the-middle) ayant pour but d'intercepter les communications entre les éléments de l'infrastructure informatique, des attaques visant à falsifier ou affecter l'intégrité de données. L'invention vise à remédier à cet état des choses. En particulier, un objectif 10 de l'invention est de protéger et sécuriser les serveurs de virtualisation et leurs machines virtuelles. Un autre objectif de l'invention est de sécuriser la communication entre l'orchestrateur et le VMM, pour garantir qu'une instruction d'orchestration est 15 autorisée et légitime. Divulgation de l'invention. 20 La solution proposée par l'invention est un système d'authentification d'instructions de gestion de ressources informatiques comprenant: - au moins un serveur de virtualisation disposant de ressources informatiques et comportant : o au moins une machine virtuelle dans laquelle sont allouées tout ou 25 partie des ressources informatiques, o un gestionnaire de machines virtuelles adapté pour exécuter une opération de gestion des ressources informatiques du serveur de virtualisation en fonction d'une instruction d'orchestration, - au moins un orchestrateur adapté pour fournir l'instruction d'orchestration. 30 4 Le système comprend en outre un dispositif d'authentification adapté pour exécuter une opération d'authentification de l'instruction d'orchestration fournie par l'orchestrateur, laquelle opération d'authentification est réalisée avant que le gestionnaire exécute l'opération de gestion. 5 Le dispositif d'authentification permet donc d'authentifier chaque instruction d'orchestration. En cas d'authentification négative, l'instruction d'orchestration n'est pas exécutée par le gestionnaire. Cela résout le problème d'exécution non autorisée d'instruction d'orchestration malveillante et évite la mise en oeuvre 10 d'opérations de création, migration, modification, copie ou destruction de machine(s) virtuelle(s) non autorisées. D'autres caractéristiques avantageuses de l'invention sont listées ci-dessous. Chacune de ces caractéristiques peut être considérée seule ou en 15 combinaison avec les caractéristiques remarquables définies ci-dessus, et faire l'objet, le cas échéant, d'une ou plusieurs demandes de brevet divisionnaires : - Avantageusement, l'instruction d'orchestration fournie par l'orchestrateur est incluse dans une requête transmise par ledit orchestrateur au dispositif d'authentification (VMOA pour Virtual Machine Orchestrator Authenticator) ; cette 20 l'instruction d'orchestration n'est transmise par l'orchestrateur au gestionnaire qu'après que le dispositif d'authentification VMOA a exécuté l'opération d'authentification et transmis audit orchestrateur une réponse de validation de l'authentification. - Avantageusement, l'instruction reçue par le gestionnaire est incluse dans 25 une requête transmise par ledit gestionnaire au dispositif d'authentification VMOA ; le gestionnaire n'exécute l'opération de gestion qu'après que le dispositif d'authentification VMOA a exécuté l'opération d'authentification et transmis audit gestionnaire une réponse de validation de l'authentification. - Selon un mode de réalisation, l'orchestrateur est identifié par une donnée 30 d'identification unique ; le gestionnaire est identifié par une donnée d'identification unique ; le dispositif d'authentification VMOA comprend une base de données 5 dans laquelle est enregistrée une table associant la donnée d'identification de l'orchestrateur à la donnée d'identification du gestionnaire. - La requête reçue par le dispositif d'authentification VMOA contient avantageusement une donnée d'identification de l'orchestrateur et une donnée 5 d'identification du gestionnaire ; durant l'opération d'authentification, le dispositif d'authentification VMOA interroge la table pour vérifier que les données d'identification contenues dans la requête correspondent aux données d'identification contenues dans la table ; le dispositif d'authentification VMOA est adapté pour générer et transmettre la réponse de validation de l'authentification, à 10 la condition que les données d'identification contenues dans la requête correspondent aux données d'identification contenues dans la table. - La table enregistrée dans la base de données du dispositif d'authentification VMOA est préférentiellement adaptée pour mémoriser la nature et la quantité des ressources informatiques disponibles dans le serveur de virtualisation ; la requête 15 reçue par le dispositif d'authentification VMOA contient en outre des informations concernant : la nature de l'opération de gestion à exécuter, la nature et la quantité des ressources informatiques nécessaires pour réaliser cette opération de gestion ; durant l'opération d'authentification, le dispositif d'authentification VMOA exécute un processus informatique logique d'interrogation de la table pour vérifier 20 que la nature et la quantité des ressources informatiques disponibles dans le serveur de virtualisation permet de réaliser l'opération de gestion desdites ressources informatiques ; le dispositif d'authentification VMOA est adapté pour générer et transmettre la réponse de validation de l'authentification, qu'à la condition que la nature et la quantité des ressources informatiques disponibles 25 dans le serveur de virtualisation permet de réaliser l'opération de gestion desdites ressources informatiques. - Selon un mode de réalisation, le système comprend : - une pluralité de serveurs de virtualisation disposant chacun de ressources informatiques et comportant chacun : au moins une machine virtuelle dans laquelle sont allouées 30 tout ou partie des ressources informatiques du serveur de virtualisation respectif ; au moins un gestionnaire de machines virtuelles adapté pour exécuter une - 6 - opération de gestion des ressources informatiques du serveur de virtualisation respectif en fonction d'une instruction d'orchestration ; - un ou plusieurs orchestrateurs, chacun desdits orchestrateurs étant adapté pour fournir une instruction d'orchestration à au moins un des gestionnaires ; - le dispositif 5 d'authentification VMOA est adapté pour exécuter une opération d'authentification pour chaque instruction d'orchestration fournie par le ou les orchestrateurs. - Selon un mode de réalisation, le dispositif d'authentification VMOA se compose de plusieurs modules d'authentification intégrés dans le gestionnaire et dans l'orchestrateur, chacun desdits modules recevant l'instruction d'orchestration 10 fournie par l'orchestrateur et exécutant l'opération d'authentification de ladite instruction de manière autonome. - Selon un mode de réalisation, le système comprend : - une pluralité de serveurs de virtualisation disposant chacun de ressources informatiques et comportant chacun : au moins une machine virtuelle dans laquelle sont allouées 15 tout ou partie des ressources informatiques du serveur de virtualisation respectif ; au moins un gestionnaire de machine virtuelle adapté pour exécuter une opération de gestion des ressources informatiques du serveur de virtualisation respectif en fonction d'une instruction d'orchestration ; - un ou plusieurs orchestrateurs, chacun desdits orchestrateurs étant adapté pour fournir une instruction d'orchestration à 20 au moins un des gestionnaires ; - le dispositif d'authentification VMOA se compose de plusieurs modules d'authentification intégrés dans les gestionnaires et/ou dans le ou les orchestrateurs ; - chaque instruction d'orchestration fournie par le ou les orchestrateurs est reçue par chacun des modules d'authentification, lesquels modules exécutent chacun une opération d'authentification en réponse à 25 la réception de ladite instruction. - Chaque instruction d'orchestration fournie par un orchestrateur est avantageusement reçue par chacun des modules d'authentification, chaque gestionnaire étant adapté pour exécuter une opération de gestion que si au moins un nombre prédéterminé de modules d'authentifications a exécuté une opération 30 d'authentification de l'instruction d'orchestration et généré une réponse de validation de l'authentification. 7 - Les opérations de gestion sont préférentiellement enregistrées dans des blocs d'un système de base de données structurée en blockchain. Cette base de données est avantageusement distribuée ou dupliquée dans chacun des modules d'authentification. 5 Un autre aspect de l'invention concerne un procédé d'authentification d'instructions de gestion de ressources informatiques d'au moins un serveur de virtualisation, comprenant des étapes consistant à: - fournir une instruction d'orchestration, 10 - exécuter une opération de gestion des ressources informatiques du serveur de virtualisation en fonction d'une instruction d'orchestration reçue. Ce procédé comprend en outre une étape consistant à exécuter une opération d'authentification de l'instruction d'orchestration, laquelle opération d'authentification est réalisée avant l'exécution de l'opération de gestion. 15 D'autres caractéristiques avantageuses de ce procédé objet de l'invention sont listées ci-dessous. Chacune de ces caractéristiques peut être considérée seule ou en combinaison avec les caractéristiques remarquables définies ci-dessus, et faire l'objet, le cas échéant, d'une ou plusieurs demandes de brevets 20 divisionnaires : - Le procédé peut comprendre les étapes consistant à: - inclure une instruction d'orchestration dans une requête ; - transmettre la requête à plusieurs modules d'authentification intégrés dans un gestionnaire adapté pour exécuter l'opération de gestion et dans un orchestrateur adapté pour fournir l'instruction 25 d'orchestration ; - exécuter une opération d'authentification de l'instruction d'orchestration incluse dans la requête, dans chacun des modules d'authentification. - Le procédé peut également comprendre les étapes consistant à : - inclure une instruction d'orchestration dans une requête ; - transmettre la requête à 30 plusieurs modules d'authentification intégrés dans plusieurs gestionnaires adaptés pour exécuter chacun des opérations de gestion, et/ou dans plusieurs - 8 - orchestrateurs adaptés pour fournir chacun une instruction d'orchestration ; - exécuter une opération d'authentification de l'instruction d'orchestration incluse dans la requête, dans chacun des modules d'authentification. - Préférentiellement, une opération de gestion n'est exécutée que si au moins 5 un nombre prédéterminé de modules d'authentifications a exécuté une opération d'authentification et généré une réponse de validation de l'authentification. - Le procédé comprend avantageusement une étape consistant à enregistrer les opérations de gestion, dans des blocs d'une base de données structurée en blockchain. 10 - Le procédé comprend avantageusement une étape consistant à attribuer des ressources effectives et des ressources artificielles à au moins un orchestrateur et à au moins un serveur de virtualisation, de sorte que : les ressources artificielles que possède le serveur de virtualisation représentent les ressources informatiques qui lui sont réellement allouées à un instant donné et/ou 15 les ressources informatiques utilisées par au moins une de ses machines virtuelles en cours d'exécution ; les ressources artificielles que possède l'orchestrateur représentent les ressources informatiques qu'il est réellement capable d'allouer au serveur de virtualisation à un instant donné ; les ressources effectives que possède le serveur de virtualisation représentent les ressources 20 informatiques qu'il est capable d'allouer à au moins une de ses machines virtuelles à un instant donné ; les ressources effectives que possède l'orchestrateur représentent les ressources informatiques utilisées par au moins une machine virtuelle en cours d'exécution du serveur de virtualisation. - Avantageusement, une opération de gestion est exécutée en mettant en 25 oeuvre un échange de ressources effectives et de ressources artificielles entre l'orchestrateur et le serveur de virtualisation. - Avantageusement, un transfert de ressources effectives, respectivement de ressources artificielles, de l'orchestrateur vers le serveur de virtualisation déclenche un transfert de ressources artificielle, respectivement de ressources 30 effectives, du serveur de virtualisation vers l'orchestrateur. 9 Description des figures. D'autres avantages et caractéristiques de l'invention apparaîtront mieux à la 5 lecture de la description d'un mode de réalisation préféré qui va suivre, en référence aux dessins annexés, réalisés à titre d'exemples indicatifs et non limitatifs et sur lesquels : - la figure 1 schématise l'agencement de différents composants d'un dispositif d'authentification VMOA selon un premier mode de réalisation, 10 - la figure 2 illustre un exemple de système objet de l'invention comprenant un dispositif d'authentification VMOA selon le premier mode de réalisation, - la figure 3 illustre un autre exemple de système objet de l'invention comprenant un dispositif d'authentification VMOA selon le premier mode de réalisation, 15 - la figure 4 illustre différentes étapes mises en oeuvre dans le procédé objet de l'invention, avec un dispositif d'authentification VMOA selon le premier mode de réalisation, - la figure 5 illustre un exemple de système objet de l'invention comprenant un dispositif d'authentification VMOA selon un second mode de réalisation, 20 - la figure 6 illustre un autre exemple de système objet de l'invention comprenant un dispositif d'authentification VMOA selon le second mode de réalisation, - la figure 7 illustre différentes étapes mises en oeuvre dans le procédé objet de l'invention, avec un dispositif d'authentification VMOA selon le second mode de 25 réalisation, - la figure 8 illustre des étapes de transactions faisant intervenir des ressources artificielles et des ressources effectives, - la figure 9a schématise un système objet de l'invention, - la figure 9b illustre un bloc de genèse d'une blockchain, pour le système de 30 la figure 9a, - 10 - - la figure 10a illustre des échanges de ressources effectives et artificielles dans le système de la figure 9a, lors de la création d'une machine virtuelle, - la figure 10b illustre les blocs d'une blockchain, suite aux échanges de ressources de la figure 10a, 5 - la figure 11a illustre des échanges de ressources effectives et artificielles dans le système de la figure 10a, lors du redimensionnement d'une machine virtuelle, - la figure 11b illustre les blocs d'une blockchain, suite aux échanges de ressources de la figure 11a, 10 - la figure 12a illustre des échanges de ressources effectives et artificielles dans le système de la figure 11a, lors de la migration d'une machine virtuelle, - la figure 12b illustre les blocs d'une blockchain, suite aux échanges de ressources de la figure 12a, - la figure 13a illustre des échanges de ressources effectives et artificielles 15 dans le système de la figure lia, lors de la destruction d'une machine virtuelle, - la figure 13b illustre les blocs d'une blockchain, suite aux échanges de ressources de la figure 13a. 20 Modes préférés de réalisation de l'invention. Le système et le procédé objet de l'invention engendrent des manipulations d'éléments physiques, notamment des signaux (électriques ou magnétiques) et des données numériques, capables d'être stockés, transférés, combinés, 25 comparés, ..., et permettant d'aboutir à un résultat souhaité. L'invention met en oeuvre une ou plusieurs applications informatiques exécutées par des équipements informatiques. Par souci de clarté, il faut comprendre au sens de l'invention que « un équipements fait quelque chose » 30 signifie « l'application informatique exécutée par le processeur ou microprocesseur de l'équipement fait quelque chose». Tout comme « l'application informatique fait quelque chose» signifie « l'application informatique exécutée par le processeur ou microprocesseur de l'équipement fait quelque chose». Encore par souci de clarté, la présente invention fait référence à un ou 5 plusieurs « processus informatiques logiques». Ces derniers correspondent aux actions ou résultats obtenus par l'exécution d'instructions de différentes applications informatiques. Aussi, il faut également comprendre au sens de l'invention que « un processus informatique logique est adapté pour faire quelque chose» signifie « les instructions d'une application informatique exécutées par un 10 processeur ou microprocesseurs font quelque chose». Encore par souci de clarté, les précisions suivantes sont apportées à certains termes utilisés dans la description et les revendications : - « Ressource informatique » peut être compris de façon non limitative 15 comme : composant, matériel, logiciel, fichier, connexion à un réseau informatique, quantité de mémoire RAM, espace de disque dur, throughput, bande passante, vitesse de processeur, nombre de CPU, etc. - « Serveur de virtualisation » peut être compris de façon non limitative comme : serveur de virtualisation sur intemet, serveur de virtualisation sur Cloud, 20 serveur de virtualisation sur une plate-forme, serveur de virtualisation sur une infrastructure locale, réseaux de serveurs, cluster, noeud, ferme de serveurs, ferme de noeuds. - « Requête » désigne un ordre d'exécution pouvant suivre un protocole de communication et comprenant des paramètres en entrée (question) et des 25 paramètres en retour (réponse), pouvant se présenter sous la forme OK ou ERROR dans un format lié au protocole employé. - « Orchestrateur » peut être compris de façon non limitative comme : module d'orchestration de services de réseau ; système d'orchestration de contenu ; processus automatique d'organisation, de coordination et de gestion de systèmes 30 informatiques complexes, de middleware et de services ; orchestration de la gestion de services, controller. L'orchestrateur peut être une plate-forme logicielle - 12 - qui fournit un point d'entrée pour organiser les ressources informatiques du serveur de virtualisation et automatiser des ensembles complexes d'opérations de gestion de ces ressources. L'orchestrateur fonctionne comme un gestionnaire, capable de reprendre tout ou partie, en les coordonnant, des processus 5 automatisés déjà en place. L'orchestrateur fournit aussi des fonctions annexes pour le développement, la gestion et la supervision des opérations qu'il effectue. - « Unité centrale de traitement » peut être compris de façon non limitative comme : processeur, microprocesseurs, CPU (pour Central Processing Unit). - « Matériel informatique » représente une ou plusieurs pièces détachées 10 d'un équipement informatique et peut être compris de façon non limitative comme hardware. - « Logiciel » peut être compris comme : application informatique, programmes informatiques ou software. - « Réseau informatique » ou « réseau » peut être compris de façon non 15 limitative comme : bus informatique, réseau personnel (PAN), réseau local (LAN, WLAN, ..), réseau étendu (WAN), réseau intemet, réseau intranet, réseau extranet. Le réseau informatique est un ensemble d'équipements informatiques reliés entre eux pour échanger, de manière sécurisée ou non, des informations et/ou des données selon un protocole de communication (ISDN, Ethernet, ATM, 20 IP, CLNP, TCP, HTTP, ...). - « Base de données » peut être comprise de façon non limitative comme un ensemble structuré et organisé de données enregistrées sur des supports accessibles par des équipements informatiques et pouvant être interrogées, lues et mises à jour. Des données peuvent y être insérées, récupérées, modifiées et/ou 25 détruites. La gestion et l'accès à la base de données peuvent être assurés par un ensemble de logiciels qui constituent un système de gestion de base de données (SGBD). Conformément à l'invention, l'authentification des instructions 30 d'orchestration, générées et émises par l'orchestrateur, est assuré par un - 13 - dispositif d'authentification (ci-après désigné par VMOA pour Virtual Machine Orchestrator Authenticator). Selon un premier mode de réalisation, le VMOA se présente sous la forme 5 d'un serveur ou d'une plateforme informatique centralisé, pouvant être considéré comme un équipement informatique intermédiaire entre le ou les orchestrateurs et le ou les VMM. Dans une variante de réalisation, le VMOA se compose de plusieurs modules d'authentification décrits plus avant dans la description. 10 Premier mode de réalisation (VMOA centralisé). Dans le premier mode de réalisation, le VMOA est centralisé et peut consister en un serveur physique ou, dans certains cas, être composé de 15 plusieurs ordinateurs distincts qui communiquent et interagissent en réseau pour exécuter les fonctions décrites plus avant dans la description. En se rapportant à la figure 1, le VMOA peut notamment comprendre une unité centrale de traitement 10, une ou plusieurs mémoires 11, une interface 20 réseau 12, une base de données 13, qui sont mutuellement connectées via un bus 15. Un ou plusieurs logiciels sont enregistrés dans la ou les mémoires 11 et dont les instructions, lorsqu'elles sont exécutées par l'unité de traitement 10, permettent de réaliser les fonctionnalités décrites plus avant dans la description. L'interface réseau 12 est une interface de communication filaire ou sans fil 25 adaptée pour établir une communication notamment avec : un ou plusieurs orchestrateurs et un ou plusieurs VMM. Cette communication est établie via un réseau informatique qui est préférentiellement sécurisé de façon à sécuriser l'échange de données entre le VMOA et les équipements précités. 30 La base de données informatique 13 peut être hébergée directement dans le VMOA, ou dans un autre serveur ou dans un réseau de serveurs type Cloud - 14 - Computing, ou dans un ordinateur. Dans le cas où la base de données 13 n'est pas localisée dans le VMOA, et pour sécuriser l'échange de données entre ledit VMOA et ladite base, la connexion entre ces deux équipements est préférentiellement réalisée au travers d'un réseau privé virtuel (VPN), d'un réseau 5 internet sécurisé, ou d'une liaison filaire. La figure 2 illustre un exemple de système objet de l'invention. Un orchestrateur ORCH est adapté pour fournir des instructions d'orchestration au gestionnaire VMM d'un serveur de virtualisation SV dont les ressources 10 informatiques sont allouées dans une pluralité de machines virtuelles VIV11, VM2, VM3. Sur cette figure, trois machines virtuelles sont schématisées à titre illustratif, étant entendu que le VMM peut gérer un nombre supérieur ou inférieur de machines virtuelles. Le VMM, l'orchestrateur ORCH et le VMOA communiquent au travers d'un réseau R auquel ils sont connectés. 15 Sur la figure 3, le système comprend un nombre entier n k 1 d'orchestrateurs ORCHi,..., ORCH. Chacun de ces orchestrateurs est adapté pour fournir des instructions d'orchestration à un ou plusieurs gestionnaires, respectivement VMMii-VMMim (m k 1) et VMMni-VMMnp (p k 1), de serveurs de 20 virtualisation 5V1, SVn, dont les ressources informatiques sont allouées dans une ou plusieurs machines virtuelles (non représentées par souci de clarté). Le nombre d'orchestrateurs et le nombre de gestionnaires, le nombre de serveurs de virtualisation et/ou le nombre de machines virtuelles, peuvent être fixes ou varier dans le temps. Un seul VMOA, commun aux orchestrateurs ORCHi,..., ORCH n et 25 aux gestionnaires, VMMii-VMMim, ..., VMMni-VMM, est en charge de l'authentification de toutes les instructions d'orchestration émises par lesdits orchestrateurs. Ce VMOA commun fonctionne comme un seul noeud qui est localisé et maintenu dans un seul endroit. 30 Chaque orchestrateur et chaque gestionnaire est identifié par une donnée d'identification unique (ID) qui peut par exemple consister en un code - 15 - alphanumérique unique ou une adresse IP unique. Chaque machine virtuelle peut également être identifiée par une donnée d'identification unique (ID) Chaque orchestrateur est également appairé à un ou plusieurs 5 gestionnaires au(x)quel(s) il est autorisé à transmettre des instructions d'orchestration. Sur la figure 2, l'orchestrateur ORCH transmet des instructions d'orchestration uniquement au gestionnaire VMM. Sur la figure 3, l'orchestrateur ORCHi transmet des instructions d'orchestration uniquement aux gestionnaires VMMii-VMMim et l'orchestrateur ORCH2 transmet des instructions d'orchestration 10 uniquement aux gestionnaires VMMni-VMM. En d'autres termes, l'orchestrateur ORCHi n'est pas autorisé à transmettre des instructions d'orchestration aux gestionnaires VMMni-VMMnp et l'orchestrateur ORCH2 n'est pas autorisé à transmettre des instructions d'orchestration aux gestionnaires VMMii-VMMim. 15 Les ressources informatiques disponibles dans les serveurs de virtualisation peuvent être de nature différente et de quantité différente. Par exemple, sur la figure 2, le serveur de virtualisation SV peut disposer de 100 Go (Giga Octets) de mémoire RAM qui peuvent être gérés par le gestionnaire VMM, ce dernier pouvant les répartir dans les différentes machines virtuelles VIV11, VM2, 20 VM3. Sur la figure 3, le serveur de virtualisation SV1 peut par exemple disposer de 100 Go de mémoire RAM qui peuvent être gérés par le gestionnaire VMMii, et d'une bande passante de 100 GB/s (GigaBits par seconde) qui peut être gérée par le gestionnaire VMMim. Le serveur de virtualisation SVn peut quant à lui par exemple disposer de 500 fichiers de données qui peuvent être gérés par le 25 gestionnaire VMMni et allouées aux machines virtuelles associés, et de 200 Go de mémoire RAM qui peuvent être gérés par le gestionnaire VMM. La base de données 13 mémorise ses différentes informations dans une table enregistrée dans ladite base : nature et quantité des ressources 30 informatiques disponibles dans chaque serveur de virtualisation, ID de chaque orchestrateur, ID de chaque gestionnaire y associé. D'autres informations peuvent - 16 - également être enregistrées dans cette table, comme par exemple des données d'horodatage (date/heure), ID des machines virtuelles, état de chaque machine virtuelle (« en cours », « détruite », ...), allocation des ressources dans chaque machine virtuelle, etc. 5 Le tableau 1 ci-dessous illustre une table enregistrée dans la base de données 13, en se référant à l'exemple précité relatif à la figure 2. Horodatage IDorchestrateur IDgestionnaire Nature Quantité Allocation des ressources des des dans les VM ressources ressources TO ORCH VMM Go 100 VIV11:20 VM2:20 VM3:60 Ti ORCH VMM Go 100 VIV11:15 VM2:20 T2 ORCH VMM Go 100 VIV11:15 VM2:20 VM3:65 Tableau 1 10 A l'instant TO, les 100 Go du serveur de virtualisation SV sont réparties pour 20 Go dans la machine virtuelle VIV11 et pour 20 Go dans la machine virtuelle VM2. 60 Go restent disponibles dans le serveur SV. A l'instant Ti, 5 Go sont enlevés de la machine virtuelle VIV11 qui dispose 15 maintenant de 15 Go. 65 Go restent disponibles dans le serveur SV. A l'instant T2, une machine virtuelle VM3 disposant de 65 Go est créée. La base de données, et plus particulièrement sa table, est donc une base de données dynamique, en ce sens que les données qu'elle contient évoluent dans le temps et restent préférentiellement mémorisées et classées 20 chronologiquement. Plus particulièrement, chaque opération de gestion exécutée en fonction d'une instruction d'orchestration authentifiée durant une opération d'authentification, est enregistrée, classée et horodatée. - 17 - Dans le cadre de l'architecture de la figure 2, l'authentification d'une instruction d'orchestration fournie par l'orchestrateur ORCH va maintenant être expliquée en référence à la figure 4: - Etape 1 : L'orchestrateur ORCH génère et transmet au VMOA une requête 5 dans laquelle est incluse l'instruction d'orchestration. Cette dernière peut par exemple consister, sans être limitatif, en une création, une destruction, une modification, une copie, une migration des machine virtuelles. Pour suivre l'exemple précité, cette instruction est par exemple l'affectation des 65 Go dans une nouvelle machine virtuelle VM3. Outre l'instruction d'orchestration, la requête 10 comprend l'ID de l'orchestrateur ORCH, l'ID du gestionnaire VMM, la nature de l'opération de gestion (« création d'une nouvelle machine virtuelle »), la nature (« Go ») et la quantité de ces ressources (« 65 ») à y affecter. - Evénement 2: Le VMOA effectue l'opération d'authentification de l'instruction d'orchestration. La réception de la requête transmise à l'étape 1 est 15 l'élément déclencheur de cette opération d'authentification. Le VMOA interroge la table enregistrée dans la base de données 13 pour au moins vérifier que les données d'identification contenues dans la requête correspondent aux données d'identification contenues dans ladite table. En pratique, l'ID de l'orchestrateur ORCH et l'ID du gestionnaire VMM contenus dans la requête doivent 20 correspondre aux ID contenues dans la table. A défaut, l'opération d'authentification se soldera par un échec. Préférentiellement, pour sécuriser davantage l'opération de gestion, le VMOA exécute un processus informatique logique plus complexe par lequel, outre la vérification des ID, ledit VMOA vérifie que la nature et la quantité des 25 ressources informatiques disponibles dans le serveur de virtualisation SV permet de réaliser l'opération de gestion des ressources informatiques incluse dans la requête. Dans l'exemple précité, le VMOA interroge la table pour vérifier que les 65 Go devant être affectés dans la nouvelle machine virtuelle VM3, sont bien disponibles, à un instant T, dans le serveur de virtualisation SV. Par exemple, si la 30 quantité de ressources indiquée dans la requête était de 70 Go, c'est-à-dire - 18 - supérieure à la quantité disponible dans le serveur de virtualisation SV, l'opération d'authentification se solderait par un échec. - Evénement 3 : Si l'ID de l'orchestrateur ORCH et l'ID du gestionnaire VMM contenus dans la requête correspondent aux ID contenues dans la table, le VMOA 5 génère une réponse de validation de l'authentification (OK). Si le processus informatique logique plus complexe décrit au paragraphe précédent est mis en oeuvre, cette réponse de validation de l'authentification n'est générée qu'à la condition que la nature et la quantité des ressources informatiques disponibles dans le serveur de virtualisation SV permettent de réaliser l'opération de gestion. 10 A défaut, le VMOA génère une réponse de refus de l'authentification (ERROR). - Etape 4: Le VMOA transmet à l'orchestrateur ORCH la réponse à la requête. - Etape 5: L'orchestrateur ORCH transmet l'instruction d'orchestration au gestionnaire VMM. Cette instruction n'est transmise que si la réponse à la requête 15 est une réponse de validation (OK). Si la réponse à la requête est une réponse de refus (ERROR), l'orchestrateur ORCH n'est pas autorisé à transmettre l'instruction d'orchestration au gestionnaire VMM. - Evénement 6: Le gestionnaire VMM exécute l'opération de gestion en fonction de l'instruction d'orchestration reçue et authentifiée. Pour suivre l'exemple 20 précité, le gestionnaire VMM crée la machine virtuelle VM3 et lui affecte 65 Go. - Etape 7: De manière optionnelle, le gestionnaire VMM transmet au VMOA une information indiquant que l'opération de gestion a été correctement exécutée. - Evénement 8: Le VMOA met à jour la table et horodate les données nouvellement enregistrées. Cette mise à jour peut toutefois être réalisée pendant 25 ou après l'évènement 3, dès lors que le VMOA génère une réponse de validation de l'authentification (OK). Pour sécuriser davantage le processus d'authentification, à la réception de l'instruction d'orchestration transmise par l'orchestrateur ORCH à l'étape 5, le 30 gestionnaire VMM peut également demander au VMOA d'authentifier cette instruction. Il s'agit donc d'une double authentification. En effet, une personne mal - 19 - intentionnée contrôlant l'orchestrateur ORCH pourrait quand même transmettre l'instruction d'orchestration au gestionnaire VMM même si la réponse à la requête est une réponse de refus (ERROR). Les étapes et/ou évènements ci-dessous illustre ce double processus d'authentification, et apparaissent sur la figure 4, en 5 dessous de la ligne en pointillé : - Etape 5: L'orchestrateur ORCH transmet l'instruction d'orchestration au gestionnaire VMM. - Etape 9: Le gestionnaire VMM génère et transmet au VMOA une requête dans laquelle est incluse l'instruction d'orchestration reçue à l'étape 5. Outre 10 l'instruction d'orchestration, la requête comprend l'ID de l'orchestrateur ORCH, l'ID du gestionnaire VMM, la nature de l'opération de gestion (« création d'une nouvelle machine virtuelle »), la nature (« Go ») et la quantité de ces ressources (« 65 ») à y affecter. - Evénement 10: Le VMOA effectue la même opération d'authentification de 15 l'instruction d'orchestration que celle décrite précédemment en référence à l'événement 2. - Evénement 11: Si l'ID de l'orchestrateur ORCH et l'ID du gestionnaire VMM contenus dans la requête de l'étape 9 correspondent aux ID contenues dans la table et si, le cas échéant, la nature et la quantité des ressources informatiques 20 disponibles dans le serveur de virtualisation SV permettent de réaliser l'opération de gestion, le VMOA génère une réponse de validation de l'authentification (OK). A défaut, le VMOA génère une réponse de refus de l'authentification (ERROR). - Etape 12: Le VMOA transmet au gestionnaire VMM la réponse à la requête. 25 - Etape 13: De manière optionnelle, le gestionnaire VMM transmet à l'orchestrateur ORCH une information indiquant que l'authentification de l'instruction d'orchestration a été validée ou refusée par le VMOA. - Evénement 14: Le gestionnaire VMM exécute l'opération de gestion en fonction de l'instruction d'orchestration reçue et authentifiée. 30 - Etape 15: De manière optionnelle, le gestionnaire VMM transmet au VMOA une information indiquant que l'opération de gestion a été correctement exécutée. - 20 - - Evénement 16: Le VMOA met à jour la table et horodate les données nouvellement enregistrées. Cette mise à jour peut toutefois être réalisée pendant ou après l'évènement 11, dès lors que le VMOA génère une réponse de validation de l'authentification (OK). 5 Dans une autre variante de réalisation, la transmission de l'instruction d'orchestration à l'étape 5 peut être réalisée sans que le VMOA ait préalablement authentifié ladite instruction (les étapes et événements 1 à 4 précités ne sont pas mis en oeuvre). 10 Le processus d'authentification qui vient d'être décrit, s'applique de manière identique dans une architecture plus complexe telle que celle illustrée sur la figure 3, le VMOA commun étant adapté pour exécuter une opération d'authentification pour chaque instruction d'orchestration fournie par chacun des orchestrateurs 15 ORCHi, ORCH2. Deuxième mode de réalisation (VMOA non centralisé). 20 Dans un second mode de réalisation, le VMOA n'est pas centralisé comme dans le premier mode de réalisation précité, mais distribué dans un ou plusieurs éléments du système et se compose de plusieurs modules (ou agents) d'authentification. 25 Sur la figure 5, ces modules d'authentification VM0AoRcH, VM0Avmm sont intégrés dans l'orchestrateur ORCH et dans le gestionnaire VMM. Ils peuvent par exemple se présenter sous la forme de matériels informatiques ou de couches logicielles implémentées dans l'orchestrateur ORCH et dans le gestionnaire VMM. Dans une variante de réalisation, seul l'orchestrateur ORCH ou seul le 30 gestionnaire VMM intègre un module d'authentification VM0AoRcH ou VM0Avmm. - 21 - Sur la figure 6, des modules d'authentification VM0AoRcH1, VM0AoRcHn, VM0Avmm11, VM0Avmm1m, VMOAVMMn1 , VMOAVMMnp, VMOAHOST, sont intégrés dans le ou les orchestrateurs °Rait..., ORCHn, dans les gestionnaires VMMiiVMMim, ..., VMMni-VMMnp et dans le serveur hôte SH. Dans une variante de 5 réalisation, seul un ou plusieurs de ces équipements peut intégrer un module d'authentification (par exemple : l'orchestrateur ORCHi et le serveur hôte SH). Chacun de ces modules d'authentification intègre tout ou partie de la base de données décrite précédemment en référence au premier mode de réalisation. 10 La base de données est donc distribuée ou dupliquée, tout ou partie des données qu'elle contient résidants dans chacun des modules d'authentification. Cette répartition des données peut provenir : - d'une fragmentation des données, chaque fragment étant distribué dans un module d'authentification (chacun des modules d'authentification intègre une partie de la base de données) ; ou d'une 15 réplication (ou duplication) de données, l'ensemble des données étant répliqué dans chacun des modules d'authentification (chacun des modules d'authentification intègre toute la base de données). Chacun des modules d'authentification est adapté pour interroger, lire et mettre à jour la base de données distribuée ou dupliquée. 20 Tous les modules d'authentification communiquent entre eux, au travers du réseau R ou d'un autre réseau informatique, de manière à pouvoir mettre à jour les données de la base de données, en fonction des opérations d'orchestration exécutées. Par exemple, lorsque le gestionnaire VMMii exécute une opération de 25 gestion en fonction d'une instruction d'orchestration émise par l'orchestrateur ORCHi, le module d'authentification VMOAHosT intégré dans le serveur hôte SH a connaissance de cette opération et met à jour la base de données en conséquence. - 22 - Dans le cadre de l'architecture de la figure 5, l'authentification d'une instruction d'orchestration fournie par l'orchestrateur ORCH va maintenant être expliquée en référence à la figure 7: - Evénement 100: L'orchestrateur ORCH génère la requête dans laquelle est 5 incluse l'instruction d'orchestration. Le module d'authentification VM0AoRcH intégré dans l'orchestrateur ORCH effectue l'opération d'authentification de l'instruction d'orchestration (identique à l'évènement 2 précité en référence à la figure 4). - Etape 101 : Si le module d'authentification VM0AoRcH valide 10 l'authentification, l'orchestrateur ORCH transmet l'instruction d'orchestration au gestionnaire VMM. - Evénement 102: Le module d'authentification VM0Avmm intégré dans le gestionnaire VMM effectue l'opération d'authentification de l'instruction d'orchestration (identique aux évènements 10 et 11 précités en référence à la 15 figure 4). Etant donné que le module d'authentification VM0Avmm effectue l'opération d'authentification de l'instruction d'orchestration, l'opération d'authentification exécutée par module d'authentification VM0AoRcH durant l'événement 100 n'est pas nécessaire, bien qu'elle offre davantage de sécurité au système. Aussi, l'étape 101 peut être réalisée même sans validation de 20 l'authentification au niveau de l'orchestrateur ORCH. - Evénement 103: Si le module d'authentification VM0Avmm valide l'authentification, le gestionnaire VMM exécute l'opération de gestion en fonction de l'instruction d'orchestration reçue. - Evénement 104: Le module d'authentification VM0Avmm met à jour la base 25 de données et horodate les données nouvellement enregistrées. Cette mise à jour peut toutefois être réalisée pendant ou après l'événement 102, dès lors que le module d'authentification VM0Avmm valide l'authentification. - Etape 105: Le module d'authentification VM0Avmm transmet au module d'authentification VM0AoRcH une information indiquant que l'opération de gestion 30 a été correctement exécutée. - 23 - - Evénement 106: Le module d'authentification VM0AoRcH met à jour la base de données et horodate les données nouvellement enregistrées. Chacun des modules d'authentification VM0AoRcH et VM0Avmm reçoit donc 5 l'instruction d'orchestration fournie par l'orchestrateur ORCH et exécute l'opération d'authentification. Ce processus d'authentification s'applique de manière identique dans une architecture plus complexe telle que celle illustrée sur la figure 6. Chaque 10 instruction fournie par le ou les orchestrateurs ORCHi, ORCH2 est reçue par chacun des modules d'authentification VM0AoRcH1, VM0AoRcHn, VM0Avmm1 1, VM0Avmm1m, VMOAVMMn1 , VMOAVMMnp, VMOAHOST, lesquels modules exécutent chacun une opération d'authentification en réponse à la réception de ladite instruction. 15 Une variante de réalisation est illustrée sur la figure 7, en dessous de la ligne en pointillé : - Evénement 200: L'orchestrateur ORCH génère la requête dans laquelle est incluse l'instruction d'orchestration. Le module d'authentification VM0AoRcH 20 intégré dans l'orchestrateur ORCH effectue de manière autonome l'opération d'authentification de l'instruction d'orchestration. - Etape 201 : Simultanément à l'événement 200, le module d'authentification VM0AoRcH transmet la requête au module d'authentification VM0Avmm intégré dans le gestionnaire VMM. 25 - Evénement 202: Le module d'authentification VM0Avmm effectue de manière autonome l'opération d'authentification de l'instruction d'orchestration. L'opération d'authentification est ainsi réalisée simultanément, ou quasi simultanément, dans chacun des modules d'authentification VM0AoRcH et VM0Avmm. Pour les mêmes raisons que celles évoquées précédemment pour 30 l'événement 102, l'opération d'authentification exécutée par le module d'authentification VM0AoRcH n'est pas nécessaire. - 24 - - Etape 203: Si le module d'authentification VM0AoRcH valide l'authentification, il transmet une réponse de validation de l'authentification au module d'authentification VM0AoRcH. Et si le module d'authentification VM0Avmm valide l'authentification, il peut également transmettre une réponse de validation 5 de l'authentification au module d'authentification VM0AoRcH. - Evénement 204: Si le module d'authentification VM0Avmm valide l'authentification et reçoit une réponse de validation de l'authentification du module d'authentification VM0AoRcH, le gestionnaire VMM exécute l'opération de gestion en fonction de l'instruction d'orchestration reçue. De manière plus générale et 10 dans une architecture plus complexe telle que celle illustrée sur la figure 6, on peut envisager qu'un gestionnaire ne puisse exécuter une opération de gestion qu'à la condition que X% (avec X>0, par exemple 50ÉXÉ100) des modules d'authentification aient validé l'authentification de l'instruction d'orchestration. - Evénement 205: Le module d'authentification VM0Avmm met à jour la base 15 de données et horodate les données nouvellement enregistrées. Cette mise à jour peut toutefois être réalisée pendant ou après l'évènement 102, dès lors que le module d'authentification VM0Avmm valide l'authentification. - Etape 206: Le gestionnaire VMM transmet à l'orchestrateur ORCH une information indiquant que l'opération de gestion a été correctement exécutée. 20 - Evénement 207: Le module d'authentification VM0AoRcH met à jour la base de données et horodate les données nouvellement enregistrées. Cette variante de réalisation s'applique de manière identique dans une architecture plus complexe telle que celle illustrée sur la figure 6 et permet de 25 répliquer l'opération d'authentification dans chacun des modules d'authentification. Ainsi, si un des modules venait à être défaillant au point de ne plus pouvoir réaliser l'opération d'authentification, cette dernière est dans tous les cas réalisée de manière redondante dans chacun des autres modules valides, conférant de ce fait une résilience accrue au système. 30 - 25 - Afin de gérer la cohérence et/ou la coordination des modules d'authentification, un système classique de gestion de base de données (SGBD) peut être prévu pour gérer la base de données distribuée ou dupliquée dans l'ensemble des modules. Un ou plusieurs des modules peuvent être élus comme 5 des noeuds maîtres servant de points d'entrée pour enregistrer, dans la base de données distribuée, chaque opération d'authentification exécutée en fonction d'une instruction d'orchestration authentifiée. 10 Troisième mode de réalisation (base de données structurée en blockchain). La basse de données peut être structurée en blockchain ou chaîne de blocs et s'appuyer sur un consensus décentralisé pour enregistrer et valider les opérations d'authentification. 15 Toutes les opérations de gestion exécutées en fonction d'instructions d'orchestration authentifiées (ci-après « les transactions ») sont enregistrées dans les blocs d'une base de données structurée en blockchain. Après avoir enregistré une transaction, un nouveau bloc est généré et toutes les nouvelles transactions 20 vont être validées par tout ou partie du réseau de modules d'authentification, qui vont analyser l'historique complet de la chaîne de blocs. Si le bloc est validé, il est horodaté et ajouté à la chaîne de blocs et devient visible dans l'ensemble du réseau. Une fois ajouté à la chaîne, un bloc ne peut plus être ni modifié ni supprimé, ce qui garantit l'authenticité et la sécurité du réseau. Chaque bloc peut 25 contenir une ou plusieurs opérations de gestion. Au démarrage, pour la première fois, au moins un des modules d'authentification crée un bloc de la genèse, qui est le premier bloc de la blockchain. Toutes les transactions ultérieures sont stockées dans des blocs 30 supplémentaires enchaînés ensemble de manière à construire une chaîne de blocs. Chaque bloc est horodaté et la donnée d'horodatage d'un bloc contient la - 26 - donnée d'horodatage du bloc précédent, ce qui constitue une chaîne de blocs horodatés. Ces blocs sont liés entre eux par un identifiant unique qui résulte d'une 5 empreinte, ou hasch. Chaque bloc contient une donnée d'horodatage, les détails d'une ou plusieurs opérations de gestion, et le hasch du bloc précédent qui devient l'identifié du bloc. Dans cette structure en blockchain, un protocole de consensus décentralisé 10 mettant en jeu tout ou partie des modules d'authentification, permet de valider chaque transaction. Les noeuds participants à la validation d'une transaction peuvent être les serveurs de virtualisation, les gestionnaires, les orchestrateurs, les machines virtuelles, ou tout autre matériel dédié ou virtuel. 15 Dans le cadre de l'architecture de la figure 6, l'authentification d'une instruction d'orchestration fournie par un orchestrateur ORCHi à un gestionnaire VMMni va maintenant être expliquée : - Un orchestrateur ORCHi génère une requête dans laquelle est incluse une instruction d'orchestration pour le gestionnaire VMMni. 20 - Simultanément, l'orchestrateur ORCHi transmet la requête à chaque noeud de la blockchain, c'est-à-dire à chaque module d'authentification VM0AoRcH1, VM0AoRcHn, VM0Avmm11, VM0Avmm1m, VM0Avmmn1, VM0Avmmnp, VMOAHosT. - Chaque module d'authentification VM0AoRcH1, VM0AoRcHn, VM0Avmm11, VM0Avmm1m, VM0Avmmn1, VM0Avmmnp, VMOAHosT effectue de manière autonome 25 une opération d'authentification de l'instruction d'orchestration. L'opération d'authentification est ainsi réalisée simultanément, ou quasi simultanément, dans chacun des modules d'authentification. - Chaque module d'authentification VM0AoRcH1, VM0AoRcHn, VM0Avmm11, VM0Avmm1m, VMOAVMMn1 , VMOAVMMnp, VMOAHOST ayant validé l'authentification, 30 transmet une réponse de validation de l'authentification à chaque autre noeud de la blockchain, c'est-à-dire à chaque autre module d'authentification. - 27 - - Si chaque module d'authentification VM0AoRcH1, VM0AoRcHn, VM0Avmm11, VM0Avmm1m, VMOAVMMn1 , VMOAVMMnp, VMOAHOST valide l'authentification, le gestionnaire VMMni exécute l'opération de gestion en fonction de l'instruction d'orchestration reçue. En appliquant un principe de consensus, on peut envisager 5 que le gestionnaire VMMni ne puisse exécuter une opération de gestion qu'a la condition que X% (avec X>0, par exemple 50ÉXÉ100) des modules d'authentification aient validé l'authentification de l'instruction d'orchestration. - Chaque module d'authentification VM0AoRcH1, VM0AoRcHn, VM0Avmm11, VM0Avmm1m, VM0Avmmn1, VM0Avmmnp, VMOAHosT, y compris ceux n'ayant pas 10 validé l'instruction d'orchestration, mettent à jour la basse de données et horodate la transaction. Exemple de gestion de ressources dans une base de données structurée en 15 blockchain. Par souci de simplification, et sans que cela soit limitatif, l'hypothèse retenue est que des ressources informatique d'une seule nature doivent être gérées, par exemple une quantité de mémoire RAM. Deux cas de gestion peuvent 20 être prévus à l'amorçage : i. Toutes les ressources informatiques sont détenues par l'orchestrateur, le serveur de virtualisation ne disposant d'aucune ressource, ii. Toutes les ressources informatiques sont détenues par un serveur de virtualisation, l'orchestrateur ne disposant d'aucune ressource. 25 Le cas i) peut être problématique alors que le cas ii) peut faciliter l'implémentation. Dans le premier cas i), l'orchestrateur dispose de suffisamment de ressources à transférer pour créer une nouvelle machine virtuelle. 30 - 28 - Dans le premier cas, à l'amorçage, l'orchestrateur possède un nombre suffisant de ressources à transférer pour de nouvelles machines virtuelles. Chaque nouvelle création de machine virtuelle correspond à une transaction, avec des ressources à transférer de l'orchestrateur vers ladite machine virtuelle. Un 5 problème peut intervenir lorsque le serveur de virtualisation doit être libéré, par exemple suite à une instruction d'orchestration relative à la destruction ou à la migration de machines virtuelles. Une transaction doit prévoir le retour des ressources vers l'orchestrateur. Ce dernier doit donc générer une instruction d'orchestration dans une situation où il n'est plus le propriétaire des ressources, 10 mais simplement le destinataire. Bien que techniquement possible, cette situation ne s'applique pas vraiment à un système structuré en blockchain, où l'émetteur d'une telle instruction doit être le propriétaire des ressources à transférer et non pas le destinataire de ces ressources. Aussi, le cas i) peut potentiellement engendrer une source de conflit et/ou une incompatibilité opérationnelle. 15 Dans le cas ii), lorsque le serveur de virtualisation libère ses ressources, l'orchestrateur doit là encore générer une instruction d'orchestration dans une situation où il n'est pas le propriétaire des ressources, mais simplement le destinataire. Etant donné que l'émission de cette instruction émane de 20 l'orchestrateur et non du serveur de virtualisation, il est apparu intéressant de concevoir une double transaction : une première transaction de l'orchestrateur vers le serveur de virtualisation qui déclenche une seconde transaction du serveur de virtualisation vers l'orchestrateur. Cette double transaction peut s'appliquer également au cas i) précité. 25 Le principe à la base de cette double transaction consiste à concevoir une opération de gestion (découlant d'une instruction d'orchestration), comme un échange de deux ressources : des ressources effectives objets d'une première transaction (aboutissant à l'opération de gestion souhaitée) et des ressources 30 artificielles objets d'une seconde transaction. Les ressources artificielles et la seconde transaction sont des artefacts créés spécifiquement pour respecter les - 29 - contraintes précitées liées à la directivité des transactions dans une blockchain. Les ressources effectives et artificielles ont la même valeur absolue. Pour des ressources de même nature : une quantité de ressources effectives est échangée contre la même quantité de ressources artificielles. 5 Dans le cadre de l'invention, les deux transactions sont soumises au procédé d'authentification décrit précédemment en référence au second ou au troisième mode de réalisation. Hors cadre de l'invention, ces deux transactions peuvent être exécutées sans mettre en oeuvre ce procédé d'authentification. 10 La figure 8 illustre des étapes de cette double transaction dans un système comprenant : un orchestrateur ORCH et deux serveurs de virtualisation SV1 et SV2. Ces éléments communiquent entre eux au travers d'un réseau de communication (non représenté). L'orchestrateur ORCH intègre un module 15 d'authentification VM0AoRcH. Chaque serveur de virtualisation SVi, SV2 comprend au moins une machine virtuelle VM1, VM2 et un gestionnaire VMMi, VMM2 intégrant un module d'authentification VM0Avmm1, VM0Avmm2. Les ressources effectives (par exemple une quantité effective de mémoire RAM) sont initialement localisées dans un des serveurs de virtualisation SVi, SV2 ou dans les deux 20 serveurs. Les ressources artificielles représentent un gage des ressources effectives. Pour attribuer des ressources au serveur de virtualisation SVi (par exemple dans le cas d'une création ou d'un redimensionnement par augmentation de la machine 25 virtuelle VM1), l'orchestrateur ORCH doit « acheter » au gestionnaire VMMi des ressources effectives (figure 8 : étape la) et lui « vendre », sous forme de gage, la même quantité de ressources artificielles (figure 8 : étape lb). De manière symétrique, quand le serveur de virtualisation SV2 libère des ressources (par exemple dans le cas d'une destruction ou d'un redimensionnement par diminution 30 de la machine virtuelle VM2), l'orchestrateur ORCH « vend » au gestionnaire - 30 - VMM2 des ressources effectives (figure 8: étape 2a) et lui « achète », sous forme de gage, la même quantité de ressources artificielles (figure 8 : étape 2b). Pour chaque serveur de virtualisation SVi et SV2, les ressources artificielles 5 qu'il possède représentent les ressources informatiques qui lui sont réellement allouées à un instant donné et/ou les ressources informatiques utilisées par au moins une machine virtuelle VM1, VM2 en cours d'exécution. Pour l'orchestrateur ORCH, les ressources artificielles qu'il possède représentent les ressources informatiques qu'il est réellement capable d'allouer aux serveurs de virtualisation 10 SVi et SV2 à un instant donné. A l'inverse, pour chaque serveur de virtualisation SVi et SV2, les ressources effectives qu'il possède représentent les ressources informatiques qu'il est capable d'allouer à ses machines virtuelles VM1, VM2 à un instant donné. Et pour l'orchestrateur ORCH, les ressources effectives qu'il possède représentent les ressources informatiques utilisées par au moins une 15 machine virtuelle VM1, VM2 en cours d'exécution. Dans le bloc de genèse, toutes les ressources artificielles du système sont attribuées à l'orchestrateur ORCH. Et toutes les ressources effectives sont allouées aux serveurs de virtualisation SVi et SV2. Le nombre total de ressources 20 artificielles correspond au nombre total de ressources effectives, ce nombre restant inchangé à chaque instant et à l'issue de chaque transaction. En d'autres termes une ressource artificielle a systématiquement un équivalent en ressource effective. Les ressources sont redistribuées après chaque transaction. 25 Les échanges de ressources effectives et artificielles vont maintenant être décrits en prenant, à titre d'exemple illustratif et non limitatif seulement, la succession des transactions (opérations de gestion) suivantes: 1. Création d'une machine virtuelle. 2. Redimensionnement d'une machine virtuelle. 30 3. Migration d'une machine virtuelle. 4. Destruction d'une machine virtuelle. - 31 - Initialement (genèse), 256 Go de mémoire RAM sont répartis pour moitié dans le serveur de virtualisation SV1 et pour moitié dans le serveur de virtualisation SV2. Dans ces conditions, le serveur de virtualisation SV1 et le 5 serveur de virtualisation SV2 détiennent chacun 128 ressources effectives (128 Go de mémoire RAM) gérées par leur gestionnaire respectif VMMi et VMM2, et l'orchestrateur détient 256 (128x2) ressources artificielles. La différence entre le nombre de ressources effectives et le nombre de ressources artificielles est donc nulle. La figure 9a illustre le système à l'état initial, les serveurs de virtualisation 10 SV1 et SV2 n'ayant pas encore de machines virtuelles. La figure 9b schématise un bloc de genèse de la blockchain où la lettre « A » renvois aux ressources artificielles et la lettre « E » aux ressources effectives. La figure 10a schématise les transactions pour la création d'une machine 15 virtuelle VM1 disposant de 64 Go de mémoire RAM dans le serveur de virtualisation SV1. L'orchestrateur ORCH « vend » 64 ressources artificielles au gestionnaire VMMi (étape 1.64A) et lui « achète » 64 ressources effectives (étape 2.64E). La figure 10b schématise les blocs de la blockchain à l'issue de cette création de machine virtuelle. 20 La figure lia schématise le redimensionnement de la machine virtuelle VM1 par une diminution de 32 Go de mémoire RAM. L'orchestrateur ORCH « vend » 32 ressources effectives au gestionnaire VMMi (étape 1.32E) et lui « achète » 32 ressources artificielles (étape 2.32A). La figure 11 b schématise les 25 blocs de la blockchain à l'issue de ce redimensionnement. La figure 12a schématise la migration de la machine virtuelle VM1 vers le serveur SV2. L'orchestrateur ORCH « vend » 32 ressources effectives au gestionnaire VMMi (étape 1.32E) et lui « achète » 32 ressources artificielles 30 (étape 2.32A). L'orchestrateur ORCH « vend » 32 ressources artificielles au gestionnaire VMM2 (étape 1.32A) et lui « achète » 32 ressources effectives (étape - 32 - 2.32E). La figure 12b schématise les blocs de la blockchain à l'issue de cette migration. La figure 13a schématise la destruction de la machine virtuelle VIV11. 5 L'orchestrateur ORCH « vend » 32 ressources effectives au gestionnaire VMM2 (étape 1.32E) et lui « achète » 32 ressources artificielles (étape 2.32A). La figure 13b schématise les blocs de la blockchain à l'issue de cette destruction. Le tableau 2 ci-dessous résume la variation des ressources effectives et 10 artificielles dans l'exemple précité. Orchestrateur VMM1 VMM2 Ressources allouées Effectives Artificielles Effectives Artificielles Effectives Artificielles Genèse 0 256 128 0 128 0 Opération 1 (création VM1) 64 192 64 64 128 0 Opération 2 32 224 96 32 128 0 (redimensionnement VM1) Opération 3 (migration VM1) 32 224 128 0 96 32 Opération 4 256 0 128 0 128 0 (destruction VM1) Tableau 2 Lors de la création d'une machine virtuelle, l'orchestrateur peut également 15 spécifier le nombre de coeurs physiques (également connus comme « CPU virtuels » ou « processeurs virtuels ») alloués à ladite machine. Ce nombre de processeurs virtuels est alloué dynamiquement par le gestionnaire VMM selon les instructions de l'orchestrateur. 20 Initialement (genèse), 32 processeurs virtuels sont alloués au système et répartis de manière équilibrée entre le serveur de virtualisation SVi et le serveur de virtualisation SV2. Le serveur de virtualisation SVi et le serveur de virtualisation SV2 détiennent par exemple chacun 16 ressources effectives (16 processeurs virtuels) gérées par leur gestionnaire respectif VMMi et VMM2, et l'orchestrateur - 33 - détient 32 (16x2) ressources artificielles. La différence entre le nombre de ressources effectives et le nombre de ressources artificielles est donc nulle. Le tableau 3 ci-dessous illustre, pour le même scénario que celui du 5 tableau 2, la variation des ressources effectives et artificielles relatives aux processeurs virtuels. Orchestrateur VMM1 VMM2 Ressources allouées Effectives Artificielles Effectives Artificielles Effectives Artificielles Genèse 0 32 16 0 16 0 Opération 1 16 16 8 8 8 8 (création VM1 et VM2) Opération 2 12 20 12 4 8 8 (redimensionnement VM1) Opération 3 (migration VM1) 16 16 16 0 4 12 Opération 4 12 20 16 0 8 8 (destruction VM1) Tableau 3 10 Opération 1 : deux machines virtuelles VIV11 et VM2 sont créées respectivement dans le serveur SV1 et SV2. 8 processeurs virtuels sont alloués à chacune de ces machines virtuelles. L'orchestrateur ORCH « vend » à chacun des gestionnaires VMMi, VMM2, 8 ressources artificielles et leur « achète » respectivement 8 ressources effectives. 15 Opération 2 : l'orchestrateur redimensionne la machine virtuelle VIV11 en lui enlevant 4 processeurs virtuels. L'orchestrateur ORCH « vend » 4 ressources effectives au gestionnaire VMMi et lui « achète » 4 ressources artificielles. Opération 3 : la machine virtuelle VIV11 migre vers le serveur SV2. L'orchestrateur ORCH « vend » 4 ressources effectives au gestionnaire VMMi et 20 lui « achète » 4 ressources artificielles. L'orchestrateur ORCH « vend » 4 ressources artificielles au gestionnaire VMM2 et lui « achète » 4 ressources effectives. Opération 4 : la machine virtuelle VIV11 est détruite dans le serveur de virtualisation SV2. L'orchestrateur ORCH « vend » 4 ressources effectives au 25 gestionnaire VMM2 et lui « achète » 4 ressources artificielles. - 34 - En outre, un autre type de ressources pouvant être allouées à une machine virtuelle est la bande passante. Chaque machine virtuelle peut utiliser une fraction de la totalité de la bande passante physique allouée à un serveur de virtualisation. 5 Initialement (genèse), une bande passante de 10 Gbit/s (Giga Bits par seconde) est par exemple allouée au réseau, 4 Gbit/s pour le serveur de virtualisation SVi et 6 Gbit/s pour le serveur de virtualisation SV2. Aussi, le serveur de virtualisation SVi détient 4 ressources effectives (correspondants aux 4 Gbit/s qui lui sont alloués) gérés par le gestionnaire VMMi et le serveur de virtualisation 10 SV2 détient 6 ressources effectives (correspondants aux 6 Gbit/s qui lui sont alloués) gérés par le gestionnaire VMM2. L'orchestrateur détient 10 (6+4) ressources artificielles. La différence entre le nombre de ressources effectives et le nombre de ressources artificielles est donc nulle. 15 Le tableau 4 ci-dessous illustre, pour le même scénario que ceux des tableaux 2 et 3, la variation des ressources effectives et artificielles relatives aux allocations de la bande passante. Orchestrateur VMM1 VMM2 Ressources allouées Effectives Artificielles Effectives Artificielles Effectives Artificielles Genèse 0 10 4 0 6 0 Opération 1 6 4 0 4 4 2 (création VM1 et VM2) Opération 2 4 6 2 2 4 2 (redimensionnement VM1) Opération 3 (migration VM1) 6 4 4 0 2 4 Opération 4 4 6 4 0 4 2 (destruction VM1) Tableau 4 20 Opération 1 : deux machines virtuelles VIV11 et VM2 sont créées respectivement dans le serveur SVi et SV2. 4 Gbit/s sont alloués à la machine virtuelle VIV11 et 2 Gbit/s sont alloués à la machine virtuelle VM2. L'orchestrateur ORCH « vend » au gestionnaire VMMi, 4 ressources artificielles et lui « achète » 4 - 35 - ressources effectives. L'orchestrateur ORCH « vend » au gestionnaire VMM2, 2 ressources artificielles et lui « achète » 2 ressources effectives. Opération 2 : l'orchestrateur redimensionne la machine virtuelle VIV11 en réduisant sa bande passante à 2 Gbit/s. L'orchestrateur ORCH « vend » au 5 gestionnaire VMMi, 2 ressources effectives et lui « achète » 2 ressources artificielles. Opération 3 : la machine virtuelle VIV11 migre vers le serveur SV2. L'orchestrateur ORCH « vend » au gestionnaire VMMi, 2 ressources effectives et lui « achète » 2 ressources artificielles. L'orchestrateur ORCH « vend » au 10 gestionnaire VMM2, 2 ressources artificielles et lui « achète » 2 ressources effectives. Opération 4 : la machine virtuelle VIV11 est détruite dans le serveur de virtualisation SV2. L'orchestrateur ORCH « vend » au gestionnaire VMM2, 2 ressources effectives et lui « achète » 2 ressources artificielles. 15 L'agencement des différents éléments et/ou moyens et/ou étapes de l'invention, dans les modes de réalisation décrits ci-dessus, ne doit pas être compris comme exigeant un tel agencement dans toutes les implémentations. En tout état de cause, on comprendra que diverses modifications peuvent être 20 apportées à ces éléments et/ou moyens et/ou étapes, sans s'écarter de l'esprit et de la portée de l'invention. En particulier : - L'opération de gestion des ressources informatiques exécutée par un gestionnaire peut impliquer plusieurs machines virtuelles. - Pour sécuriser davantage le processus d'authentification, les 25 communications entre l'orchestrateur et le VMOA et le gestionnaire VMM et le VMOA, peuvent être réalisées au travers d'un réseau informatique qui est distinct du réseau informatique au travers duquel communiquent l'orchestrateur REVENDICATIONS1. Système d'authentification d'instructions de gestion de ressources informatiques comprenant: - au moins un serveur de virtualisation (SV) disposant de ressources informatiques et comportant : o au moins une machine virtuelle (VIV11, VM2, VM3) dans laquelle sont allouées tout ou partie des ressources informatiques, o un gestionnaire (VMM) de machines virtuelles adapté pour exécuter une opération de gestion des ressources informatiques du serveur de virtualisation (SV) en fonction d'une instruction d'orchestration, - au moins un orchestrateur (ORCH) adapté pour fournir l'instruction d'orchestration, se caractérisant par le fait que le système comprend en outre un dispositif d'authentification (VMOA) adapté pour exécuter une opération d'authentification de l'instruction d'orchestration fournie par l'orchestrateur (ORCH), laquelle opération d'authentification est réalisée avant que le gestionnaire (VMM) exécute l'opération de gestion. 2. Système selon la revendication 1, dans lequel : - l'instruction d'orchestration fournie par l'orchestrateur (ORCH) est incluse dans une requête transmise par ledit orchestrateur au dispositif d'authentification (VMOA), - l'instruction d'orchestration n'est transmise par l'orchestrateur (ORCH) au gestionnaire (VMM) qu'après que le dispositif d'authentification (VMOA) a exécuté l'opération d'authentification et transmis audit orchestrateur une réponse de validation de l'authentification. 3. Système selon l'une des revendications 1 ou 2, dans lequel - 37 - - l'instruction reçue par le gestionnaire (VMM) est incluse dans une requête transmise par ledit gestionnaire au dispositif d'authentification (VMOA), - le gestionnaire (VMM) n'exécute l'opération de gestion qu'après que le dispositif d'authentification (VMOA) a exécuté l'opération d'authentification et 5 transmis audit gestionnaire une réponse de validation de l'authentification. 4. Système selon l'une des revendications 1 à 3, dans lequel : - l'orchestrateur (ORCH) est identifié par une donnée d'identification unique, - le gestionnaire (VMM) est identifié par une donnée d'identification unique, 10 - le dispositif d'authentification (VMOA) comprend une base de données dans laquelle est enregistrée une table associant la donnée d'identification de l'orchestrateur (ORCH) à la donnée d'identification du gestionnaire (VMM). 5. Système selon la revendication 4, dans lequel : 15 - la requête reçue par le dispositif d'authentification (VMOA) contient une donnée d'identification de l'orchestrateur (ORCH) et une donnée d'identification du gestionnaire (VMM), - durant l'opération d'authentification, le dispositif d'authentification (VMOA) interroge la table pour vérifier que les données d'identification contenues dans la 20 requête correspondent aux données d'identification contenues dans la table, - le dispositif d'authentification (VMOA) est adapté pour générer et transmettre la réponse de validation de l'authentification, à la condition que les données d'identification contenues dans la requête correspondent aux données d'identification contenues dans la table. 25 6. Système selon l'une des revendications 4 ou 5, dans lequel : - la table enregistrée dans la base de données du dispositif d'authentification (VMOA) est adaptée pour mémoriser la nature et la quantité des ressources informatiques disponibles dans le serveur de virtualisation (SV), 30 - la requête reçue par le dispositif d'authentification (VMOA) contient en outre des informations concernant : la nature de l'opération de gestion à exécuter, la - 38 - nature et la quantité des ressources informatiques nécessaires pour réaliser cette opération de gestion, - durant l'opération d'authentification, le dispositif d'authentification (VMOA) exécute un processus informatique logique d'interrogation de la table pour vérifier 5 que la nature et la quantité des ressources informatiques disponibles dans le serveur de virtualisation (SV) permet de réaliser l'opération de gestion desdites ressources informatiques, - le dispositif d'authentification (VMOA) est adapté pour générer et transmettre la réponse de validation de l'authentification, qu'a la condition que la 10 nature et la quantité des ressources informatiques disponibles dans le serveur de virtualisation (SV) permet de réaliser l'opération de gestion desdites ressources informatiques. 7. Système selon l'une des revendications précédentes, comprenant : 15 - une pluralité de serveurs de virtualisation (5V1, ..., SV) disposant chacun de ressources informatiques et comportant chacun : o au moins une machine virtuelle dans laquelle sont allouées tout ou partie des ressources informatiques du serveur de virtualisation respectif, 20 o au moins un gestionnaire (VMMii-VMMim, ..., VMMni-VMMnp) de machine virtuelle adapté pour exécuter une opération de gestion des ressources informatiques du serveur de virtualisation respectif en fonction d'une instruction d'orchestration, - un ou plusieurs orchestrateurs (ORCH1,..., ORCHn), chacun desdits 25 orchestrateurs étant adapté pour fournir une instruction d'orchestration à au moins un des gestionnaires (VMMii-VMMim, ..., VMMni-VMMnp), - le dispositif d'authentification (VMOA) est adapté pour exécuter une opération d'authentification pour chaque instruction d'orchestration fournie par le ou les orchestrateurs (ORCH1,..., ORCHn). 30 - 39 - 8. Système selon la revendication 1, dans lequel le dispositif d'authentification (VMOA) se compose de plusieurs modules d'authentification (VM0AoRcH, (VM0Avmm) intégrés dans le gestionnaire (VMM) et dans l'orchestrateur (ORCH), chacun desdits modules recevant l'instruction d'orchestration fournie par 5 l'orchestrateur (ORCH) et exécutant l'opération d'authentification de ladite instruction de manière autonome. 9. Système selon la revendication 1, comprenant : - une pluralité de serveurs de virtualisation (5V1, ..., SVn) disposant chacun 10 de ressources informatiques et comportant chacun : o au moins une machine virtuelle dans laquelle sont allouées tout ou partie des ressources informatiques du serveur de virtualisation respectif, o au moins un gestionnaire (VMMii-VMMim, ..., VMMni-VMMnp) de 15 machine virtuelle adapté pour exécuter une opération de gestion des ressources informatiques du serveur de virtualisation respectif en fonction d'une instruction d'orchestration, - un ou plusieurs orchestrateurs (ORCH1,..., ORCH), chacun desdits orchestrateurs étant adapté pour fournir une instruction d'orchestration à au moins 20 un des gestionnaires (VMMii-VMMim, ..., VMMni-VMMnp), - le dispositif d'authentification (VMOA) se compose de plusieurs modules d'authentification (VM0AoRcH1, VM0AoRcHn, VM0Avmm11, VM0Avmm1m, VM0Avmmn1, VM0Avmmnp) intégrés dans les gestionnaires (VMMii-VMMim, ..., VMMni-VMMnp) et/ou dans le ou les orchestrateurs (ORCH1,..., ORCH), 25 - chaque instruction d'orchestration fournie par le ou les orchestrateurs (ORCH1,..., ORCH) est reçue par chacun des modules d'authentification (VM0AoRcH1, VM0AoRcHn, VM0Avmm11, VM0Avmm1m, VM0Avmmn1, VM0Avmmnp), lesquels modules exécutent chacun une opération d'authentification en réponse à la réception de ladite instruction. 30 10. Système selon l'une des revendications 8 ou 9, dans lequel : - 40 - - chaque instruction d'orchestration fournie par un orchestrateur (ORCH1,..., ORCHn) est reçue par chacun des modules d'authentification (VM0AoRcH1, VM0AoRcHn, VM0Avmm11, VM0Avmm1m, VM0Avmmn1, VMOAVMMnp), - chaque gestionnaire (VMMii-VMMim, ..., VMMni-VMMnp) est adapté pour 5 exécuter une opération de gestion que si au moins un nombre prédéterminé de modules d'authentifications (VM0AoRcH1, VM0AoRcHn, VM0Avmm11, VM0Avmm1m, VM0Avmmn1, VM0Avmmnp) a exécuté une opération d'authentification de l'instruction d'orchestration et généré une réponse de validation de l'authentification. 10 11. Système selon l'une des revendications 8 à 10, dans lequel les opérations de gestion sont enregistrées dans des blocs d'une base de données structurée en blockchain, laquelle base de données est distribuée ou dupliquée dans chacun des modules d'authentification (VM0Avmm, VM0AoRcH1, VM0AoRcHn, VM0Avmm11, 15 VM0Avmm1m, VM0Avmmn1, VM0Avmmnp). 12. Procédé d'authentification d'instructions de gestion de ressources informatiques d'au moins un serveur de virtualisation (SV), comprenant des étapes consistant à : 20 - fournir une instruction d'orchestration, - exécuter une opération de gestion des ressources informatiques du serveur de virtualisation (SV) en fonction d'une instruction d'orchestration reçue, se caractérisant par le fait que ledit procédé comprend en outre une étape consistant à exécuter une opération d'authentification de l'instruction 25 d'orchestration, laquelle opération d'authentification est réalisée avant l'exécution de l'opération de gestion. 13. Procédé selon la revendication 12, comprenant des étapes consistant à: - inclure une instruction d'orchestration dans une requête, 30 - transmettre la requête à plusieurs modules d'authentification (VM0AoRcH, VM0Avmm) intégrés : - 41 - o dans un gestionnaire (VMM) adapté pour exécuter l'opération de gestion, o et dans un orchestrateur (ORCH) adapté pour fournir l'instruction d'orchestration. 5 - exécuter une opération d'authentification de l'instruction d'orchestration incluse dans la requête, dans chacun des modules d'authentification (VM0AoRcH, VM0Avmm). 14. Procédé selon la revendication 12, comprenant des étapes consistant à: 10 - inclure une instruction d'orchestration dans une requête, - transmettre la requête à plusieurs modules d'authentification (VM0AoRcH1, VM0AoRcHn, VM0Avmm1i, VM0Avmm1m, VM0Avmmn1, VM0Avmmnp) intégrés : o dans plusieurs gestionnaires (VMMii-VMMim, ..., VMMni-VMMnp) adaptés pour exécuter chacun des opérations de gestion, 15 o et/ou dans plusieurs orchestrateurs (ORCH1,..., ORCHn) adaptés pour fournir chacun une instruction d'orchestration, - exécuter une opération d'authentification de l'instruction d'orchestration incluse dans la requête, dans chacun des modules d'authentification (VM0AoRcH1, VM0AoRcHn, VM0Avmm11, VM0Avmm1m, VM0Avmmn1, VMOAVMMnp). 20 15. Procédé selon la revendication 14, consistant à exécuter une opération de gestion que si au moins un nombre prédéterminé de modules d'authentifications (VM0AoRcH1, VM0AoRcHn, VM0Avmm1 1 , VM0Avmm1m, VM0Avmmn1, VMOAVmMnP) a exécuté une opération d'authentification et généré une réponse de validation de 25 l'authentification. 16. Procédé selon l'une des revendications 12 à 15, consistant à enregistrer les opérations de gestion, dans des blocs d'une base de données structurée en blockchain. 30 - 42 - 17. Procédé selon la revendication 16, consistant à attribuer des ressources effectives et des ressources artificielles à au moins un orchestrateur (ORCH) et à au moins un serveur de virtualisation (SVi, SV2), de sorte que : - les ressources artificielles que possède le serveur de virtualisation (SVi, 5 SV2) représentent les ressources informatiques qui lui sont réellement allouées à un instant donné et/ou les ressources informatiques utilisées par au moins une de ses machines virtuelles (VIV11, VM2) en cours d'exécution, - les ressources artificielles que possède l'orchestrateur (ORCH) représentent les ressources informatiques qu'il est réellement capable d'allouer au 10 serveur de virtualisation (SVi, SV2) à un instant donné, - les ressources effectives que possède le serveur de virtualisation (SVi, SV2) représentent les ressources informatiques qu'il est capable d'allouer à au moins une de ses machines virtuelles (VIV11, VM2) à un instant donné, - les ressources effectives que possède l'orchestrateur (ORCH) représentent 15 les ressources informatiques utilisées par au moins une machine virtuelle (VIV11, VM2) en cours d'exécution du serveur de virtualisation (SVi, SV2). 18. Procédé selon la revendication 17, dans lequel une opération de gestion est exécutée en mettant en oeuvre un échange de ressources effectives et de 20 ressources artificielles entre l'orchestrateur (ORCH) et le serveur de virtualisation (SVi, SV2). 19. Procédé selon la revendication 18, dans lequel un transfert de ressources effectives, respectivement de ressources artificielles, de l'orchestrateur 25 (ORCH) vers le serveur de virtualisation (SVi, SV2) déclenche un transfert de ressources artificielle, respectivement de ressources effectives, du serveur de virtualisation (SVi, SV2) vers l'orchestrateur (ORCH).