Loading AI tools
De Wikipédia, l'encyclopédie libre
La sécurité des hyperviseurs est relative à toute menace ou toute attaque par des virus informatiques qui remettrait en question la sécurité (au sens informatique) basée sur les services de confidentialité, d’intégrité et de disponibilité.
Cet article aborde successivement la description, l’évolution de la sécurité et les risques encourus quant à l’utilisation des hyperviseurs. Puis, il traite de la vulnérabilité des hyperviseurs, des attaques et des solutions apportées pour les sécuriser.
La virtualisation consiste à faire fonctionner un ou plusieurs systèmes d'exploitation ou applications sur un ou plusieurs ordinateurs/Serveur informatique au lieu d'en installer un(e) seul(e) par machine. Ces ordinateurs virtuels sont aussi appelés serveur privé virtuel (Virtual Private Server ou VPS) ou encore environnement virtuel (Virtual Environment ou VE)[1],[2]. Un Hyperviseur est une plate-forme de virtualisation qui permet à plusieurs systèmes d’exploitation de travailler sur une même machine physique en même temps. Les hyperviseurs sont classés en 2 catégories Type 1 natif et Type 2[3]:
La sécurité en informatique est l’ensemble des moyens techniques, organisationnels, juridiques et humains nécessaires et mis en place pour conserver, rétablir et garantir la sécurité du système d’information[19].
Les technologies de virtualisation prennent une part de plus en plus importante depuis les années 2000[20],[21],[22]. Ce phénomène est lié notamment au développement de nouveaux usages comme la virtualisation des postes de travail, la virtualisation des applications d’entreprise, la virtualisation du stockage[23],[24],[25], ou l’apparition du cloud computing.
De plus la virtualisation permet de faire des économies de place, d’énergie et de budget en diminuant le nombre de serveurs utilisés en les mutualisants et en optimisant leurs usages[26],[27]. Cette technologie est mise en avant comme élément d'amélioration que ce soit dans le cadre de la sécurité, de la fiabilité ou de la disponibilité[28]. Cette technologie touche de plus en plus les grandes entreprises mais également les PME (Petite et Moyenne Entreprise) et PMI (Petite et Moyenne Industrie).
L'Hyperviseur améliore la sécurité du point de vue :
L'Hyperviseur repose sur le matériel et en cas de défaillance sur la machine il suffit de posséder un équipement compatible avec le produit de virtualisation pour en fabriquer une équivalente[29].
Avec l’utilisation des solutions de stockage partagé de type SAN (Storage Area Network), l'Hyperviseur permet la réplication synchrone[30].
L'Hyperviseur permet de concevoir des architectures isolées au sein d’un hôte. Il permet également d’œuvrer sur le réseau local sans utiliser physiquement de carte réseau[31].
L'Hyperviseur de par sa technologie engendre de nouveaux risques comme les attaques entre machines virtuelles, la fuite d'information d’une machine virtuelle, la prise de contrôle du système hôte[32]… Ci-dessous un ensemble des risques liés à ces nouvelles technologies[33]:
La compromission est la prise de contrôle par un acteur malveillant d’un système invité depuis un autre système invité ou de la couche d’abstraction depuis un système invité. Le risque qui en découle est la fuite d'information ou des perturbations du système pouvant aller jusqu'à l'indisponibilité d'un service[34]. Il est essentiel que chaque brique matériel, système d’exploitation hôte et système d’exploitation invité soient à jour de tous les correctifs de sécurité[35].
La panne d’une ressource commune peut engendrer l'indisponibilité simultanée de plusieurs systèmes[36] et potentiellement tous les services hébergés sur la même machine.
Dans le cas de la virtualisation, les instances que sont le système d’exploitation, les applications, le système de stockage de données et autres… se partagent une même ressource. De ce fait il devient difficile de maitriser les différents échanges internes à une même machine physique et donc de garantir que les ressources bas niveaux partagés n'introduisent pas de possibilité de fuite d’information[36].
La virtualisation fait apparaitre des opérations d’administration nouvelles comme la mise en place des quotas sur des ressources partagées ou la gestion d'ajout de disque ou de périphérique de stockage réseau entre les machines virtuelles. L'administration s'en trouve complexifiée d'autant plus que ce sont en général des personnes différentes qui gèrent les parties réseaux, serveurs, sauvegardes et stockages[37].
Les opérations de supervision peuvent s’avérer complexes du fait de l’incompatibilité entre le cloisonnement nécessaire des machines virtuelles et la nécessité de vision d’ensemble de la part de la supervision. Dès lors il devient difficile de tracer un événement ou une action de bout en bout[38].
Les systèmes invités sont moins adhérents aux équipements c'est-à-dire qu'un système se voit reproduit à l'identique sur plusieurs machines. En conséquence la localisation précise d’une donnée s'en trouve complexifiée et les risques de copie non maîtrisée s'en trouve accrus avec les conséquences graves que cela peut engendrer comme la modification ou le vol d'informations[38].
Avec la virtualisation il est possible à la suite de dysfonctionnements d'arrêter et de redémarrer plusieurs systèmes invités sur un même système hôte mais il devient complexe de gérer ces erreurs sans leur prise en compte globale[38].
Il convient donc de mettre en place une centralisation et une corrélation des journaux sur l'ensemble des systèmes.
Certaines investigations menées après incident lié au partage de ressources matérielles par plusieurs systèmes peuvent s'avérer plus difficile. L'optimisation de la gestion de la mémoire vive par la solution de virtualisation rend plus délicate l'analyse de l'historique des états de la machine et par conséquent le traitement d'un incident dans la mesure où cette mémoire est réallouée à une autre machine virtuelle dès que celle-ci n’est plus utilisée[38].
Les hyperviseurs ont été graduellement utilisés dans des applications de plus en plus critiques, leur fiabilité est d'une importance vitale[39]. Contrairement aux systèmes d'exploitation traditionnels qui doivent supporter le système de fichier, les piles réseaux, etc., un hyperviseur présente des abstractions relativement simples telles la CPU et la mémoire. En conséquence de ces propriétés, les hyperviseurs ont été largement considérés comme une architecture pour construire des systèmes d'exploitation sécurisés[40].
Cependant, il y a diverses inquiétudes concernant les hyperviseurs actuels. Avec de plus en plus de machines virtuelles déployées sur une seule plate-forme gérée par un seul hyperviseur, la robustesse est aussi un point posant problème. Les hyperviseurs modernes dérivent des systèmes d'exploitation contemporains. Malheureusement beaucoup de décisions de conception "restent inchangées, même si dans le même temps le matériel et logiciel ont évolué". Exemple de la conception monolithique qui utilise des langages procéduraux tels que le langage de programmation C. Un trop grand nombre de lignes de code n'est pas adapté à une vérification formelle. En fait les meilleurs techniques de vérification disponibles peuvent gérer environ 10K lignes de code[41]. De cela résulte une piètre maintenabilité. Il est donc difficile d'étendre les fonctionnalités des hyperviseurs[42].
Pour construire un hyperviseur robuste le choix du langage de programmation est critique. Le langage doit être suffisamment efficace pour manipuler les objets de bas niveau, expressif et permettre de vérifier l'intégrité du code. Le TCB (Trusted Computing Base) est défini comme la totalité des mécanismes de protection dans un système informatique, incluant le hardware (matériel informatique), le firmware, et le software (logiciel)[43].
De leur combinaison ressort la partie responsable du renforcement de la politique de sécurité. Ainsi, malgré une faible empreinte de l'hyperviseur en lui-même, ces plates-formes ont un large TCB[43]. Un micro-hyperviseur tel NOVA propose une architecture dans laquelle la réduction du TCB fait partie intégrante de la conception[44].
Les plates-formes de virtualisation telles que Xen, Vmware ESX et Hyper-V sont responsables de l'isolation et de la gestion de la mémoire des machines virtuelles. Puisque l'hyperviseur s'exécute au plus haut niveau de privilège, il forme avec le matériel la partie dite TCB[43].
Architecturalement, ces plates-formes dépendent de composants additionnels, des pilotes logiciels, des composants d'émulation, etc.
La compromission d'un de ces composants permettra à un attaquant d'obtenir des privilèges tels que l'accès à des zones mémoires ou d'injecter du code malveillant[43].
L'hyperviseur est une couche entre le système d'exploitation de la machine hôte et l'environnement virtuel, il offre de nouvelles opportunités pour les logiciels malicieux.
L'hyperviseur étant lui-même un logiciel, il comporte en son sein les bugs traditionnels et les vulnérabilités inhérentes à la création de programmes informatique.
Les environnements virtualisés sont vulnérables du fait même des systèmes d'exploitations s'exécutant comme des machines virtuelles, à l'ensemble des exploits et attaques traditionnelles qui se retrouvent sur les environnements plus classiques.
L'attente sécuritaire pour les environnements virtuels est d'autant plus élevée qu'elle dépend du nombre de systèmes d'exploitation virtuels à protéger, du nombre de points d'entrées potentiels, du nombre de failles à patcher et des points d'interconnexions.
Dans un environnement non virtuel, les applications s'exécutant sur une machine peuvent se voir l'une ou l'autre et dans certains cas communiquer entre elles. Tandis que dans un environnement virtuel les programmes tournant sur une machine sont en principe isolés des autres programmes tournant sur les autres machines. De ce point de vue le degré d'isolation devrait être assez fort pour que les vulnérabilités d'une machine ne puissent pas affecter les autres machines virtuelles ainsi que la machine hôte[45].
La couche de virtualisation est très impliquée à travers tout le cycle de vie de la machine virtuelle. Chaque interaction entre la machine virtuelle et l'hyperviseur est un vecteur potentiel d'attaque qui peut être exploité par un système d'exploitation virtualisé non autorisé. La machine virtuelle interagit directement avec l'hyperviseur et indirectement avec le système d'exploitation de la machine hôte et l'émulateur à travers lequel la VM (Virtual Machine) fait ses appels systèmes.
Un appel système est un événement qui se produit quand la VM exécute un code de sortie alors le code l'hyperviseur gère un évènement (par exemple émuler un accès mémoire). Un hypercall est similaire à un appel système, il est utilisé par les machines virtuelles pour demander des services explicites à l'hyperviseur[41].
VM Exit | Reason |
---|---|
EPTV | An attempt to access memory with a guestphysicaladdress was disallowed by the configuration of the EPT paging structures. |
APICACC | Guest software attempted to access memory at a physical address on the APIC-access page. |
MSRWR | Guest software attempted to write machine specific register, MSR. |
MSRRD | Guest software attempted to read machine specific register, MSR. |
IOINSR | Guest software attempted to execute an I/O instruction. |
DRACC | Guest software attempted to move data to or from a debug register. |
CRACC | Guest software attempted to access CR0, CR3,CR4, or CR8 x86 control registers. |
CPUID | Guest software attempted to execute CPUID instruction. |
PNDVINT | Pending virtual interrupt. |
EXTINT | An external interrupt arrived. |
EXCNMI | Exception or non-maskable interrupt, NMI. |
Chaque appel système de la machine virtuelle peut être vu comme un canal de communication où une VM envoie implicitement ou explicitement des informations à l'hyperviseur que ce dernier doit traiter. L'ensemble des appels représente une partie de la surface d'attaque[41]. Certaines solutions telles que Nohype permettent de réduire la surface d'attaque en éliminant le besoin d'interaction entre les machines virtuelles et l'hyperviseur.
Un des premiers bénéfices apportés par la virtualisation est l'isolation, elle permet d'assurer qu'une application tournant sur une VM n'accède pas à une application tournant sur un autre VM. L'isolation doit être fortement maintenue, pour que l'intrusion dans une machine virtuelle ne permette pas l'accès aux autres machines virtuelles, à l'hyperviseur et à la machine hôte. Pour exemple, le partage du presse-papiers dans un environnement virtuel est une fonctionnalité pratique qui permet aux données d'être transférées entre les machines virtuelles et la machine hôte. Mais cette fonctionnalité peut aussi servir de passerelle pour transférer des données entre des codes malicieux agissant en collaboration au sein de différentes machines virtuelles. Certaines technologies de virtualisation ne mettent pas en œuvre l'isolation dans le but de permettre à des applications conçues pour un système d'exploitation, d'être opérationnelles sur un autre système d'exploitation, ce genre de solution permet l'exploitation des failles de sécurité des deux systèmes d'exploitation, et donne aussi un accès sans limites aux ressources de la machine hôte, telles que le système de fichiers[45].
Les machines virtuelles sont autorisées à partager les ressources de la machine hôte mais tout en fournissant l'isolation entre machines virtuelles et entre les VM et l'hôte. Cela dit les machines virtuelles sont conçues de telle manière qu'un programme tournant sur l'une ne puisse communiquer avec les programmes tournant sur l'autre, ou avec les programmes s'exécutant sur la machine hôte. Mais en réalité les organisations compromettent l'isolation. Elles configurent des isolations "flexibles" pour répondre aux besoins de leur architecture. Dans cette situation l'évasion de machine virtuelle est l'attaque la plus grave si l'isolation entre les machines virtuelles est compromise. Dans l'évasion de machine virtuelle, le programme s'exécutant dans la VM est capable de contourner l'hyperviseur et obtenir l'accès à la machine hôte. La machine hôte étant la racine, le programme qui a obtenu l'accès acquiert les privilèges administrateur. Cela a pour résultat de rendre caduque la sécurité d'ensemble de l'environnement. L'exploit Cloudburst est un exemple d'évasion de VM, il prend l'avantage sur une fonction d'affichage d'un produit Vmware, ce qui a permis l'évasion d'une VM et ainsi d'accéder à l'hyperviseur[45].
Dans le cas du trafic réseau, l'isolation dépend complètement de la manière dont l'environnement virtuel est connecté. Dans la majorité des cas la machine virtuelle est reliée à l'hôte au moyen d'un switch virtuel, ce qui permet à la VM d'utiliser l'ARP poisoning pour rediriger les paquets venant et entrant d'une autre machine virtuelle. L'isolation requiert un Hyperviseur sans défaut de conception et sans bug[46].
L'hyperviseur est responsable de l'isolation entre les machines virtuelles, les VM sont protégées si l'hyperviseur se comporte correctement. Dans le cas contraire l'hyperviseur introduit une faille de sécurité à l'ensemble de système. Une solution est de protéger l'hyperviseur de toutes modifications non autorisées[47].
Lors de la migration à chaud de machine virtuelle, les trois principales ressources physiques utilisées sont la mémoire, le réseau et le disque local.
La mémoire peut être copié directement d'un hôte vers l'autre, pour le disque local et l'interface réseau la migration n'est pas trivial[48].
La migration à chaud de machines virtuelles est une caractéristique essentielle de la virtualisation. Elle permet le transfert d'une machine virtuelle d'un serveur physique vers un autre sans interrompre les services en cours d'exécution sur la VM. La migration à chaud offre les avantages suivants : équilibrage de la charge de travail, la consolidation des machines virtuelles, etc.
L'hyperviseur est un logiciel qui émule la partie matérielle vue par les machines virtuelles, il contrôle complètement les ressources du système. La plupart des versions commerciales et open source des hyperviseurs supportent la migration à chaud.
La migration à chaud inclut beaucoup d'état de transferts à travers le réseau. Durant la procédure, protéger le contenu des fichiers d'état de la VM est important[48]. La plupart des travaux, pour mettre en œuvre la migration à chaud, se sont concentrés sur l'implémentation de cette migration avec peu ou pas de considération pour la sécurité s'y rattachant[49]. La mémoire est un point crucial par ce qu'il est difficile pour une machine virtuelle de chiffrer sa propre mémoire[50]. Les protocoles de migration à chaud ne chiffrant pas les données en cours de transferts, toutes les données migrantes, tel que les mots de passe sont transmises en clair. De plus, après la migration l'environnement d'exécution de la machine virtuelle, aura peut-être changé en termes de ressources processeur, mémoire, drivers. De tels changements peuvent être détectés, et un attaquant capable de caractériser ces changements pourrait déclencher des attaques de type side-channel[51].
Une politique d'accès inappropriée permet à un utilisateur non autorisé d'initialiser, de migrer ou d'arrêter une machine virtuelle. La politique de contrôle d'accès prend aussi en compte l'accès à l'hyperviseur, l'isolation entre les VM, le partage des ressources, etc. Une politique d'accès inappropriés permettra à un attaquant de réaliser les attaques suivantes :
Le protocole de migration ne chiffre pas les données lors de leur circulation sur le réseau. Il est donc possible de mettre en place des attaques passives ou actives en utilisant des techniques telles que l'ARP/DHCP poisoning, DNS poisoning et l'IP/route hijacking. Les attaques passives peuvent être par exemple l'écoute du réseau pour récupérer des données sensibles. Les attaques actives peuvent être la manipulation des services d'authentification telles que sshd/bin/login ou la manipulation de la mémoire noyau. Il a été montré que le RTT (Round-trip delay time) des paquets ICMP est une métrique prometteuse pour détecter à distance le processus de migration d'une machine virtuelle. En ciblant une machine virtuelle avec les paquets ICMP, il est possible de déterminer quand cette machine a migré sur une autre machine physique[49] .
Dans un environnement où les migrations à chaud sont initiées automatiquement pour distribuer la charge sur un grand nombre de serveurs, un attaquant pourrait faire la "promotion " de fausses ressources via le "Control Plane". Ainsi l'attaquant pourra influencer le "Control Plane" pour migrer une VM vers un hyperviseur compromis[52]. Le "Control Plane" est le mécanisme de communication employé par les machines virtuelles pour déclencher et gérer les migrations à chaud.
Le module de migration implémente les fonctionnalités nécessaires à la migration des machines virtuelles, il doit donc être résistant aux attaques. Les vulnérabilités dans les modules de migration sont les débordements de pile, de tas, etc[52].. De telles vulnérabilités peuvent être utilisées par un attaquant pour y injecter du code malicieux ou même arrêter le processus de migration. Le module de migration de l'hyperviseur peut donner la possibilité à l'attaquant d'atteindre l'ensemble des machines virtuelles, le code du module de migration doit être scruté en profondeur pour y supprimer de telles vulnérabilités. Une approche pour sécuriser la migration à chaud est d'isoler le trafic en assignant les VM à un Virtual Lan (Vlan). Le problème principal posé par les VLAN est l'augmentation de la complexité et le coût administratif élevé quand le nombre de machines virtuelles croît.
Les hyperviseurs ne peuvent en principe s'attaquer directement l'un l'autre, parce que chaque instance s'exécute dans son propre espace d'adressage et un canal direct de communication n'existe pas entre les hyperviseurs.
Pour contourner cela un attaquant devra passer par des services partagés par plusieurs hyperviseurs, par exemple les pilotes. Les pilotes utilisent un canal de communication dédié pour chaque hyperviseur. Quand un hyperviseur malicieux exécute une attaque de type déni de service en soumettant trop de requêtes, le pilote peut couper le canal de communication. La première préoccupation de sécurité concernant les drivers et leur utilisation de la DMA (Direct Memory Access). Si une plate-forme n'inclut pas un IOMMU (Input/Output Memory Management Unit (en)), alors tout pilote qui accède directement à la mémoire doit être de confiance[44].
Sur les nouvelles plates-formes qui fournissent une IOMMU, l'hyperviseur réduit l'usage de la DMA, un pilote compromis ou un driver malicieux peut seulement affecter la disponibilité de son propriétaire, l'intégrité et la confidentialité de la région mémoire qui lui est assignée[44]. Donc si un hyperviseur délègue l'ensemble de la mémoire physique d'une machine virtuelle à un driver alors ce dernier pourra manipuler la VM tout entière. En utilisant la IOMMU l'hyperviseur bloque les transferts vers sa propre zone mémoire et restreint les vecteurs d'interruption disponibles pour les pilotes. Dans les architectures où les drivers sont intégrés à l'hyperviseur, un matériel non sûr peut saper la sécurité du système dans son entier[44].
DMA capable devices : ce sont des dispositifs qui peuvent directement lire la mémoire sans intervention de la CPU. Ainsi ils peuvent passer outre aux protections de l'hyperviseur. Ces attaques peuvent être en grande partie réalisées par l’émergence de dispositifs d'entrées/sorties virtuels[53].
Un hypercall est l'équivalent d'un appel système sur les systèmes d'exploitations classiques . D'un point de vue sécuritaire les hypercall sont des véhicules commodes pour un attaquant. Si un attaquant compromet une machine virtuelle pour lancer un hypercall malicieux, il peut causer de sérieux problèmes à l'ensemble du système virtualisé. Des études récentes suggèrent que les interfaces des hypercalls peuvent être exploitées pour injecter du code malicieux dans l'hyperviseur[54]. Ci-dessous le scenario typique d'une attaque d'hypercall dans une architecture XEN :
Bien qu'une machine virtuelle ne puisse directement modifier les structures de données tels les tables, les descripteurs globaux… Ces opérations peuvent être demandées à travers les hypercalls. Si un attaquant peut modifier un hypercall, il peut potentiellement modifier les droits d'accès à ces structures de données. Il peut ainsi avoir accès aux pages mémoire d'autres machines virtuelles ou modifier le code de ces machines. Il peut aussi causer un déni de service à l'encontre des utilisateurs légitimes de la VM.
Rejouer un machine virtuelle peut être pratique pour le diagnostic mais cela peut créer des problèmes pour certains algorithmes de cryptographie. Par exemple, la valeur occasionnelle d'une clé symétrique ne devrait jamais être réutilisée. Si une machine virtuelle est réinitialisée à un état précédent, une même valeur pourrait être répétée. Un attaquant pourrait exploiter cette propriété pour réaliser une attaque contre le système de cryptographie[55].
Ces attaques exploitent les propriétés physiques du matériel pour récolter des informations pouvant donner un schéma ou pattern de fonctionnement du système à attaquer. Le fait que plusieurs machines virtuelles partagent le même matériel rend l'attaque side channel relativement aisée à réaliser. Sans mise en place de dispositif de sécurité au niveau matériel, le partage du matériel est dangereux[51]. L'un des buts de ce type d'attaque est de révéler les clés cryptographiques. Ces attaques sont généralement catégorisées en trois classes[56] :
Dans les environnements Cloud Computing, il est possible de mapper l'infrastructure et d'identifier là-où une machine virtuelle réside. Il est alors possible d'instancier de nouvelles machines virtuelles, jusqu'à ce qu'une soit placée en corésidence avec la VM cible. Après ce placement la VM instanciée peut extraire des données confidentielles en provenance de la VM légitime. Ceci est un type d'attaque side-channel[57].
Les attaques side-channel sont donc très liées à l'existence de phénomènes physiques causés par le traitement sous-jacent des données par les dispositifs électroniques. Quelles sont les contre-mesures[58]?
Cette attaque consiste à installer un hyperviseur non autorisé qui prendra le contrôle complet du serveur. Les mesures standards de sécurité sont dans ces cas inefficaces, car le système d'exploitation ne se rendra pas compte que la machine a été compromise[59]. Des attaques telles que l'hyperjacking peuvent mettre en balance la sécurité d'architecture comme le cloud computing[60].
Pour faire face aux failles et/ou aux attaques de plus en plus sophistiquées révélées par l’utilisation des hyperviseurs, les entreprises ont besoin d'une suite complète de solutions pour les sécuriser.
L'une des premières tentatives pour concevoir un hyperviseur sécurisé est faite par Karger & al[61] lors d’une recherche menée entre 1981 et 1990 sur la production d’un noyau de sécurité Virtual Machine Monitor (VMM)[62]. Ce projet de recherche a obtenu le niveau de sécurité A1 par le National Computer Security Center (NCSC)[63]. Il s’agit du niveau de sécurité le plus élevé conformément aux critères d’évaluation du Trusted Computer System Evaluation Criterial publié par NCSC en 1985 et qui est également connu sous le nom de Livre Orange[64]. Le développement du noyau de sécurité VMM est effectué à partir de l’extension d’adresse virtuelle de l'architecture VAX conçue par Digital Equipment Corporation au cours des années 1970.
Conformément aux exigences du niveau de sécurité A1, le VAX Hyperviseur prend en compte les systèmes de contrôle d’accès DAC et MAC de toutes les machines virtuelles[65]. Avec MAC, le VMM VAX utilise le modèle de protection Bell-Lapadula Model pour la protection de la vie privée[66] et le modèle de protection d’intégrité Biba[67].
Le noyau de sécurité VAX prend en compte et fait fonctionner simultanément et en toute sécurité plusieurs machines virtuelles sur un seul système physique VAX tout en assurant l’isolement et le partage contrôlé des données sensibles. Il est doté d’un système d’authentification sécurisé, avec un niveau de performance élevé et des outils de gestion du système très développés soumettant ainsi les machines virtuelles à des contrôles d’accès et d’audits obligatoires[68]. Ainsi chaque machine virtuelle est dotée d’une classe d’accès composée d’une classe secrète et d’une classe d’intégrité similaire aux classes dans les VMS Security Enhancement Services (VMS SES)[62].
Pour répondre à la fois aux exigences du niveau élevé de sécurité A1 et aux exigences du monde réel des utilisateurs, les techniques suivantes sont introduites dans le noyau de sécurité VAX[61].
Tout comme les contrôles d'accès, les lignes directrices de conception et le code sont obligatoires ou discrétionnaires. Les lignes directrices obligatoires sont fondées sur une expérience préalable dans l'évolution du noyau de sécurité. Des lignes directrices facultatives sont utilisées pour éviter les pièges bien connus dans la programmation et pour avoir des codes lisibles et cohérents[69].
À chaque fois qu'un utilisateur veut accéder à une machine virtuelle, il doit d'abord s'authentifier au VMM VAX. À cet effet, le VAX hyperviseur offre un processus de confiance en cours d'exécution dans le noyau. Ce processus ne s'exécute qu’après validation de l’Authentification de l’utilisateur. Puis, le VAX hyperviseur crée un chemin de confiance entre le processus serveur et l'utilisateur. Le serveur fournit des commandes permettant à l'utilisateur de se connecter à une machine virtuelle en fonction de ses droits d'accès. Dans le cas où l'utilisateur a les droits nécessaires pour se connecter à une machine virtuelle une autre voie de sécurité est établie entre l'utilisateur et la machine virtuelle, lui permettant d'interagir avec le système d'exploitation en cours d'exécution dans la machine virtuelle[69].
En résumé, le VMM VAX offre un niveau de sécurité élevé en répondant aux niveaux d'exigence de sécurité A1 avec non seulement la mise en œuvre des modèles de sécurité formels, DAC, MAC, de l'analyse des canaux cachés mais aussi aux exigences du monde réel avec une distribution sécurisée des ressources finales et un niveau élevé de confiance à l'utilisateur[62].
En 2003, Tal Garfinkel et al[72] ont écrit un article présentant une Machine virtuelle basée sur une plateforme de confiance appelée Terra[73]. L'architecture Terra est basée sur un moniteur de machine virtuelle[74] qui permet à plusieurs machines virtuelles d'être multiplexées sur une seule machine physique. Terra utilise le moniteur de machine virtuelle sécurisée appelée Trusted Virtual Monitor Machine (TVMM)[75]. L’architecture TVMM propose des services variés avec des mécanismes de protection avancés.
Pour atteindre ces objectifs en matière de sécurité le TVMM offre une interface pour le maintien de l'application en sécurité. À cet effet, Terra fournit plusieurs classes de disques virtuels qui sont utilisés pour assurer la Confidentialité et l'intégrité des données. Le TVMM chiffre/déchiffre et HMAC les données d’une VM au nom de cette VM assurant ainsi l'intimité du stockage et de l'intégrité.
En conclusion, Terra présente une architecture très flexible qui fournit certaines fonctions de sécurité très importantes dont l'attestation. Toutefois, pour pouvoir utiliser toutes les fonctions de sécurité offertes par Terra, le système doit être exécuté sur du matériel inviolable. Ce qui n’est pas le cas pour les puces matérielles pour PC. Ceci étant, cela peut changer dans un proche avenir avec le Module TPM implémenté dans les PC depuis 2010[77].
L'architecture de sécurité sHype est surement l’une des approches les plus connues quand il s’agit de créer un hyperviseur sûr[80]. Elle est née d’un projet de recherche d’IBM développé pour IBMs rHype avec un hyperviseur open-source. Peu de temps après la sortie de sa première version, elle est implémentée dans un hyperviseur Open source[81]. Son objectif principal est de contrôler les flux d’information explicites entre les machines virtuelles[82]. sHype utilise la politique de sécurité formelle MAC[83].
sHype utilise le concept d'un moniteur de référence qui applique les relations d’accès autorisées entre les sujets et objets d'un système[84]. Cela signifie que le moniteur de référence est appelé chaque fois qu’un utilisateur veut accéder à un objet. Toutefois, le moniteur de référence ne décide pas si un utilisateur peut accéder à un objet. Il impose seulement la décision qui est souvent prise ailleurs dans le système. C’est le Module de Contrôle d’Accès (MAC) qui est responsable de cette décision. Le MAC utilise la politique de sécurité formelle avec des étiquettes qui sont fixées sur les sujets et les objets du système et le type d'opération qu’un sujet peut exécuter pour rendre une Access Control Decision (DAC)[85]. Ainsi le flux de travail complet que le système exécute si un sujet tente d'accéder à un objet est la suivante : l'appel d'accès de l'objet est intercepté par le moniteur de référence, qui à son tour appelle le MAC[86] en plaçant une requête d'autorisation (Authorization Query : AQ). Cet AQ contient les étiquettes de l'objet et les opérations qui peuvent être exécutées sur l'objet (lecture, écriture ...). Le MAC utilise la politique de sécurité formelle et les données de l'AQ pour faire un DAC qui est ensuite renvoyé à l'écran de référence. Enfin, le moniteur de référence applique le DAC en autorisant ou en refusant d’exécuter l'opération. Dans ce processus, le moniteur de référence est effectivement mis en œuvre en utilisant des crochets d'exécution qui sont répartis sur l'hyperviseur.
L'élément clé de l'architecture sHype pour répondre à son objectif de contrôler les flux d’information explicites entre les machines virtuelles est le moniteur de référence qui isole sHype des machines virtuelles et permet le partage des ressources entre les machines virtuelles uniquement si cela est permis par un contrôle d’accès obligatoire (Mandatory Access Control)[87].
Par l’intermédiaire de MAC, sHype applique la politique de contrôle d'accès basée sur l'application des contraintes inter-partition aux flux d'information. sHype contrôle le flux d'information explicite par l'utilisation de ressources partagées explicitement virtuel (ex : VLAN) pour garantir la surveillance de l’accès non exclusif aux ressources de la partition virtuelle et assurer l’assignement exclusif des ressources virtuelles aux partitions[88].
Le contrôle d’accès aux domaines MAC limite l'accès aux ressources virtuelles uniquement à des domaines qui appartiennent à la même coalition que la ressource virtuelle. Les domaines MAC deviennent ainsi partie intégrante de la base informatique sécurisée ou Trusted Computing Base.
sHype utilise l’attestation Trusted Platform Module[89] qui offre la possibilité de générer et d’apporter des mesures d'intégrité d'exécution sur l'hyperviseur et les Machines virtuelles. Cela permet aux systèmes distants de déduire les propriétés d'intégrité du système en cours d'exécution.
Pour répondre aux exigences métier, sHype utilise les différentes politiques MAC comme le Modèle de Biba, le Modèle Bell-LaPadula, Caermarvon[90] ainsi que le Chinese Wall[91].
En conclusion, la sécurité proposée par le sHype repose sur l'isolement fourni par le noyau qu’il complète par la supervision du partage des ressources entre les machines virtuelles. Le sHype agit en tant que médiateur à l'intérieur de l'hyperviseur et entre les machines virtuelles dans la gestion des ressources en fonction de la politique de sécurité active et du contrôle d'accès dans les communications inter-virtuelles[92]. Tout ceci concourt à une grande flexibilité de l’architecture sHype avec des politiques de sécurité mesurées et indépendantes de la mise en œuvre technique.
Une autre approche pour assurer la sécurité est proposée avec l’architecture HyperWall. Il s’agit de protéger les machines virtuelles invitées à partir d'un hyperviseur non fiable[93]. Avec HyperWall, l’hyperviseur gère librement la mémoire, les cœurs de processeur et d'autres ressources d'une plate-forme. Une fois les machines virtuelles créées, le CIP (Confidentiality and Integrity Protection) protège la mémoire des machines virtuelles invitées à partir de l'hyperviseur ou par le DMA(Direct Memory Access) selon les spécifications du client. Le client peut spécifier que certaines plages de mémoire soient protégées contre les accès par l'hyperviseur ou par le DMA[94]. L’HyperWall est l’élément clé qui assure la protection de la confidentialité et de l'intégrité des objets qui ne sont accessibles que par le matériel. Ils protègent tout ou partie de la mémoire d'une machine virtuelle basée sur les spécifications du client.
Pour assurer son objectif de protéger les machines virtuelles invitées quand l’hyperviseur est compromis, l’HyperWall utilise les mécanismes de protection qui sont détaillées ci-dessous :
De nouvelles tables de protection de confidentialité et d'intégrité (CIP) sont introduites dans les machines virtuelles pour garantir à la fois la confidentialité et l’intégrité des données de la machine virtuelle et les codes des régions de la machine virtuelle que le client souhaite protéger. L’utilisation des tables CIP pour isoler la machine virtuelle est combinée à la cryptographie pour augmenter la sécurité[95].
Avec HyperWall, l'hyperviseur est capable de gérer entièrement la plateforme, pour démarrer, mettre en pause ou en arrêt les machines virtuelles ou de modifier l'affectation de la mémoire, de vérifier que l'hyperviseur n’a pas un comportement contraire à ce qui est attendu. Pour ce faire, l’HyperWall fournit des données de hachage pour attester que l'image du client VM initiale et les protections spécifiées étaient instanciées lors du lancement de la machine virtuelle. En outre, les preuves de confiance peuvent être générées pendant la durée de vie de la machine virtuelle pour vérifier que ses protections spécifiées ne sont pas corrompues. Lorsque la machine virtuelle est interrompue, sa mémoire protégée est mis à zéro par le matériel pour prévenir la fuite de données ou de code. Ainsi l'hyperviseur et le DMA retrouvent les droits d'accès à la mémoire de la machine virtuelle[93].
En 2009, David Grawrock annonce la notion de Trusted Computing avec une approche modulaire de la conception de la sécurité des plateformes et PC dans son livre Dynamics of a Trusted Platform. Le processeur Intel Trusted Execution Technology (TXT) est un bloc utilisé pour créer une plateforme sécurisée en implémentant des fonctionnalités de sécurité et de nouvelles capacités dans le processeur[100]. L’utilisation de la technologie d’exécution fiabilisée Intel TXT permet la protection de l’infrastructure informatique contre les attaques logicielles au démarrage d’un serveur ou d’un ordinateur.
Intel TXT fonctionne en créant un environnement de lancement mesuré[101] (MLE) qui permet de lancer certains éléments essentiels de l'environnement par rapport à une source connue servant de référence. Intel TXT crée un identifiant cryptographique unique pour chaque lancement de code approuvé. Ce mécanisme permet de bloquer le lancement des codes non approuvés. Cette solution basée sur la sécurisation du matériel fournit la plateforme sécurisée sur laquelle les solutions de confiance peuvent être déployées pour se protéger contre les attaques logicielles qui menacent l'intégrité, la confidentialité, la fiabilité et la disponibilité du système[102].
Pour atteindre ses objectifs, les serveurs Intel TXT intègrent :
L’intégration de ces éléments est complétée par les principales caractéristiques des deux méthodes suivantes dans ces serveurs pour avoir une racine de confiance ou Root of Trust :
L'architecture Intel TXT utilise le modèle S-RTM pour fournir des méthodes pour mesurer et enregistrer dans le module TPM un des logiciels du système qui se trouve dans la zone de confiance[102] .
Cette approche est utilisée par VMware ESXi pour renforcer la sécurité matérielle dans sa nouvelle architecture vSphere 5.0 et a supprimé le système d’exploitation en Console (COS) et les fonctionnalités d’administration nécessaires ont été directement intégrées dans le noyau VM kernel au cœur de l’architecture. La suppression des failles de sécurité associées au système d’exploitation générique contribue à améliorer la sécurité et la fiabilité.
En 2010, toujours dans l’optique de sécuriser les hyperviseurs Xuxian Jiang et son étudiant en doctorat Zhi Wang proposent l’Isolation de l’hyperviseur via Hypersafe[106]. Il s’agit d’un logiciel appelé HyperSafe qui tire parti des fonctionnalités matérielles existantes pour garantir les hyperviseurs contre de telles attaques. Les programmes malveillants doivent exécuter leur propre code dans l’hyperviseur. Pour éviter que cela se produise, le logiciel Hypersafe utilise une technique de verrouillage mémoire non contournable qui interdit de manière fiable l’introduction d’un nouveau code dans l’hyperviseur par une personne en dehors de l’administrateur de l’hyperviseur tout en empêchant toute tentative de modification du programme source de l’hyperviseur par des utilisateurs externes par la technique d’indexation.
Pour répondre à ses objectifs de protéger l’hyperviseur, les auteurs de Hypersafe utilisent un matériel de confiance de type TPM assistée d’une racine statique/dynamique (Trusted Boot) où sont implémentées les deux techniques principales suivantes :
En conclusion et comme le dit Jiang : “We can guarantee the integrity of the underlying hypervisor by protecting it from being compromised by any malware downloaded by an individual user, ” “By doing so, we can ensure the hypervisor’s isolation.”, le logiciel Hypersafe garantit seulement l'isolation de l'Hyperviseur et pas son intégrité en le protégeant contre les attaques malveillantes.
Les approches énumérées ci-dessus pour sécuriser les hyperviseurs proposent dans l’ensemble un niveau de sécurité élevé mais avec quelques nuances.
Le VAX Hypervisor propose le plus haut niveau de sécurité car cette approche répond au niveau d’exigence de sécurité A1 du NCSC en combinant :
En plus des fonctions de sécurité, le Vax Hyperviseur impose des obligations pour le processus de développement logiciel avec des normes de codage sécurisées. Cependant, ce haut niveau de sécurité est limité à la plateforme VMM VAX sans prendre en compte les processeurs VAX[61]. l’architecture proposée par le Vax Hypervisor est complexe et peu flexible.
L’architecture Terra offre une bonne flexibilité sans apporter un niveau de sécurité similaire à ceux de VAX Hyperviseur et de SHype. Ceci est du essentiellement au fait que Terra ne propose pas le mandataire d’accès contrôlé (MAC). De ce fait, Terra n’est pas en mesure de sécuriser de façon fiable la circulation des informations. Terra reste donc une architecture très flexible qui s’adapte au besoin avec les boites Open-Box et Closed-Box.
sHype offre une architecture très souple avec l’option MAC lui permettant de respecter les différents modèles de sécurité formels. Avec MAC, sHype gère les flux d'information explicites et offre des garanties d'intégrité du contenu. Aussi, le SHype sécurise la circulation des informations en la limitant à lui-même et réduit également le nombre de canaux cachés dans l'architecture. sHype s’appuie sur l’isolement fournit par le noyau et traduit l'isolement sous-jacent de la machine virtuelle dans les propriétés d'isolation liées aux charges différentes de travail[108]. Les canaux cachés constituent un problème pour l’architecture sHype. Ce problème peut être résolu dans un proche avenir avec les travaux en cours[109]. Ces travaux en cours vont permettre une attestation à distance pour sHype. Le sHype ne repond pas aujourd’hui aux objectifs fixés contrairement à l’architecture Vax Hypervisor. Cependant, le niveau de sécurité offert par sHype est convenable et sera amélioré avec les travaux en cours dans un proche avenir[110].
Il est à noter que pour sécuriser les hyperviseurs, il faut vérifier que le système est mis en œuvre correctement et ne contient aucune lacune grave susceptible de compromettre la sécurité de l’ensemble du système.
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.