Caractéristiques essentielles du cloud

L’utilisation des systèmes informatiques est aujourd’hui en pleine évolution. Le modèle classique qui consiste à associer à chaque utilisateur une machine physique qu’il possède et dont il va exploiter les ressources devient de plus en plus obsolète. Aujourd’hui, les ressources informatiques que l’on utilise peuvent être distribuées n’importe où dans l’Internet et les postes de travail du quotidien ne sont plus systématiquement des machines réelles. Cette constatation met en avant deux phénomènes importants qui sont à l’origine de l’évolution de notre utilisation de l’informatique : le Cloud computing et la virtualisation. Le Cloud computing (ou informatique en nuage en français) permet à un utilisateur d’exploiter des ressources informatiques, de granularités potentiellement très différentes, pendant une durée variable, qui sont à disposition dans un nuage de ressources. L’utilisation de ces ressources est ensuite facturée à l’utilisateur. Ce modèle peut être bien sûr avantageux pour une entreprise qui peut s’appuyer sur des ressources informatiques potentiellement illimitées, qu’elle n’a pas nécessairement à administrer et gérer elle même. Elle peut ainsi en tirer un gain de productivité et un gain financier. Du point de vue du propriétaire des machines physiques, le gain financier lié à la location des puissances de calcul est accentué par une maximisation de l’exploitation de ces machines par différents clients. L’informatique en nuage doit donc pouvoir s’adapter à la demande et facilement se reconfigurer. Une manière d’atteindre ces objectifs nécessite notamment l’utilisation de machines virtuelles et des techniques de virtualisation associées. Même si la virtualisation de ressources informatiques n’est pas née avec le Cloud, l’avènement du Cloud a considérablement augmenté son utilisation. L’ensemble des fournisseurs d’informatique en nuage s’appuient aujourd’hui sur des machines virtuelles, qui sont beaucoup plus facilement déployables et migrables que des machines réelles

La virtualisation de ressources informatiques était auparavant essentiellement basée sur des techniques logicielles. Mais l’utilisation massive de machines virtuelles notamment pour le Cloud, a poussé les fondeurs de processeurs à inclure des mécanismes d’assistance matérielle à la virtualisation dans leurs processeurs. Ces extensions matérielles permettent d’une part de rendre plus facile la virtualisation, et d’autre part d’obtenir des gains de performance. Ainsi, un certain nombre de technologies ont vu le jour, telles que VT-x et VT-d chez Intel ou AMDV chez AMD ou Virtualization Extensions chez ARM. Par ailleurs, la virtualisation nécessite l’implémentation de fonctionnalités supplémentaires, capables de gérer les différentes machines virtuelles, de pouvoir les ordonnancer, les isoler et partager les ressources matérielles comme la mémoire et les périphériques. Ces différentes fonctionnalités sont en général prises en charge par un gestionnaire de machines virtuelles, dont le travail peut donc être plus ou moins facilité, en fonction des caractéristiques du processeur sur lequel il s’exécute (assistance matérielle à la virtualisation ou non). De façon globale, ces technologies introduisent des nouveaux modes d’exécution sur les processeurs, de plus en plus privilégiés et de plus en plus complexes.

Ainsi, s’il est indéniable que l’utilisation de la virtualisation apporte un véritable intérêt pour l’informatique d’aujourd’hui, il est par ailleurs évident que sa mise en œuvre ajoute une complexité aux systèmes informatiques, complexité à la fois logicielle (gestionnaire de machines virtuelles) et matérielle (nouveaux mécanismes d’assistance à la virtualisation intégrés dans les processeurs). À partir de ce constat, il est légitime de se poser la question de la sécurité informatique dans ce contexte où l’architecture des processeurs devient de plus en plus complexe, avec des modes de plus en plus privilégiés. Étant donné la complexité des systèmes informatiques, l’exploitation de vulnérabilités présentes dans les couches privilégiées ne risquet-elle pas d’être très sérieuse pour le système global ? Étant donné la présence de plusieurs machines virtuelles, qui ne se font pas mutuellement confiance, au sein d’une même machine physique, est-il possible que l’exploitation d’une de ces vulnérabilités soit réalisée par une machine virtuelle compromise ? N’est-il pas nécessaire d’envisager de nouvelles architectures de sécurité prenant en compte ces risques ?

Le cloud computing

Ces dernières années, les entreprises ont progressivement transformé leurs parcs informatiques. Initialement, si nous prenons l’exemple des applications webs d’entreprises, les ordinateurs personnels clients ainsi que les serveurs étaient hébergés physiquement et gérés par la même entreprise. Elle jouait donc à la fois le rôle de fournisseur de service et de client. Puis, de plus en plus, l’hébergement des serveurs a été délégué à des entreprises externes (action de mettre en infogérance) pour minimiser les coûts de production. Par la suite, plus de responsabilités ont été données aux entreprises d’infogérance. Notamment, la gestion et la maintenance de la pile logicielle de la machine ont été aussi déléguées à ces acteurs extérieurs, qui proposent par exemple directement la location d’environnements d’hébergement de sites Web ou d’applications diverses accessibles par le réseau Internet. Dans ce cas, les entreprises clientes n’ont plus la possibilité de gérer les couches sous-jacentes aux applications qu’elles utilisent. De plus, la configuration et la mise en œuvre de ces applications ne sont pas entièrement connues et peuvent être spécifiques à l’hébergeur, ce qui peut entraîner des difficultés de migration. L’infogérance entraîne une donc grande dépendance vis-à-vis du fournisseur de service, sans pour autant qu’elle apporte de nouvelles fonctionnalités. L’avènement de la virtualisation a redonné de la flexibilité et de la maîtrise sur la pile logicielle d’une machine. En effet, les fournisseurs de services se sont appuyés sur les machines virtuelles pour, par exemple, permettre à un utilisateur de garder le contrôle sur le système opératoire d’une machine qu’il veut faire infogérer. Aussi, les hébergeurs obtiennent la possibilité de mutualiser des machines physiques pour héberger plusieurs machines virtuelles, réduisant encore les coûts. Notons que les architectures virtualisées n’interdisent pas non plus les anciennes méthodes d’hébergement de services comme la mutualisation de serveurs Web. Les clients peuvent de plus migrer plus simplement leurs machines virtuelles chez un autre hébergeur en déplaçant simplement les fichiers de configuration des machines virtuelles et disques virtuels. Cette solution est tout de même limitée en matière de flexibilité. Par exemple, la configuration matérielle des machines virtuelles n’est pas extensible sans l’intervention du fournisseur de service. En plus, en cas de défaillance physique, le fournisseur doit effectuer manuellement la migration des machines virtuelles sur d’autres hôtes physiques, ce qui engendre un temps d’arrêt notable même s’il est plus réduit qu’avec les architectures non virtualisées. Enfin, le client ne peut pas lui même configurer une infrastructure complète avec un contrôle total sur le matériel et le réseau virtuel sans intervention du fournisseur. L’absence de ces fonctionnalités a contribué à la conception des architectures cloud, ou cloud computing, qui a émergé il y a quelques années maintenant. Le cloud computing (cloud) ou informatique en nuage en Français, est un modèle d’architecture et d’infrastructure de service informatique. Les formes que peuvent prendre les architectures cloud sont si nombreuses et différentes qu’il est très difficile d’en donner une définition ferme et arrêtée. Néanmoins, l’institut national des standards et des technologies, le National Institute of Standards and Technology (NIST), propose une définition via les caractéristiques du cloud et les acteurs, souvent reprise par les acteurs du domaine.

Caractéristiques essentielles du cloud

Selon le NIST, le cloud est défini par 5 caractéristiques essentielles, 3 types de services pouvant être commercialisés et 4 modèles de déploiement [1, 2]. Le cloud doit proposer un service disposant des caractéristiques suivantes :
— Libre et accessible à la demande : le client doit pouvoir unilatéralement modifier la configuration de son infrastructure informatique, par exemple le temps processeur loué ou sa bande passante réseau, sans que cela ne requière l’intervention d’une personne humaine chez le fournisseur de service.
— Accessible massivement par le réseau : les fonctionnalités du cloud doivent être accessibles par le réseau et au travers d’une diversité d’appareils qui ne disposent pas forcément de grandes capacités de calcul tels que des appareils mobiles.
— Où les ressources sont mises en commun : les ressources du fournisseur de service sont mises en commun afin de servir une multitude de clients selon un modèle multi tenant, c’est-à-dire mutualisant les ressources matérielles et logicielles. Cette propriété apporte un aspect d’indépendance vis-à-vis de la localisation physique des ressources, sur laquelle le client n’a généralement pas de contrôle.
— Flexible : Il doit être possible d’allouer et de supprimer rapidement des ressources informatiques, et ce parfois automatiquement. Du point de vue de l’utilisateur, la quantité de ressources apparaît souvent illimitée. Celles-ci doivent pouvoir être affectées à tout moment et à n’importe quelle quantité.
— Facturé à l’usage : les systèmes cloud contrôlent et optimisent l’utilisation de ressources en effectuant des mesures au niveau de contrôle approprié. L’utilisation des ressources peut être surveillée, contrôlée et rapportée, ce qui apporte autant de transparence au fournisseur de service qu’à l’utilisateur.

Les architectures de type cloud proposent à la consommation trois types de services différents :
— Software As A Service (SAAS) ou logiciel en tant que service : ici, le fournisseur de service offre la possibilité aux utilisateurs d’utiliser le service fourni par une application telle qu’une application WEB, une API réseau ou bien un service de courrier électronique. L’utilisateur ne gère ni ne contrôle l’infrastructure cloud sous jacente à l’application fournie.
— Platform As A Service (PAAS) ou plateforme en tant que service : ce type de service donne la capacité à l’utilisateur de déployer dans l’infrastructure cloud, diverses applications, bibliothèques, outils qui sont supportés par le fournisseur de service. L’utilisateur ne gère ni ne contrôle la couche cloud sous-jacente comme le réseau, les serveurs physiques, le système d’exploitation ou le stockage. Toutefois, il peut configurer les applications et l’environnement d’hébergement de celles-ci.
— Infrastructure As A Service (IAAS) ou l’infrastructure en tant que service : à ce niveau de service, on donne à l’utilisateur la capacité d’allouer du temps processeur, du stockage, configurer le réseau et d’autres ressources informatiques fondamentales dans lesquelles il peut y déployer n’importe quel type de logiciel. Encore une fois, l’utilisateur n’a pas à gérer les couches du cloud sous-jacentes, mais dispose du contrôle sur les systèmes d’exploitation, le stockage, les applications et certains éléments réseau. Le NIST définit aussi 4 modèles de déploiement caractérisant l’origine des utilisateurs vis-à-vis du fournisseur de service, c’est-à-dire le propriétaire de l’infrastructure cloud.
— Le cloud privé : les utilisateurs finaux des services cloud privés appartiennent à la même organisation. L’infrastructure peut être elle aussi propriété de cette même organisation, mais peut aussi être pilotée par une entreprise tierce ou les deux.
— Le cloud communautaire : les utilisateurs appartiennent à un groupe d’organisations qui partagent certains centres d’intérêt (du point de vue de la sécurité par exemple). Il est géré par une ou plusieurs organisations membres de la communauté, mais peut l’être aussi encore une fois par un acteur extérieur.
— Le cloud public : les clouds publics ont pour vocation d’être massivement ouverts à tous, ce qui implique que les utilisateurs ne partagent très certainement aucun centre d’intérêt. Ce type de cloud peut être géré par tout type d’organisations.
— Le cloud hybride : un regroupement d’au moins deux clouds qui ne suivent pas forcément le même mode de déploiement. Les différents clouds sont connectés par des protocoles définis pour rendre possible la migration de données et d’applications inter cloud ce qui permet notamment d’effectuer de l’équilibrage de charge

Les 5 propriétés du cloud citées précédemment peuvent paraître très ambitieuses à obtenir en réalité. Prenons quelques exemples illustrant leur difficulté de mise en œuvre. Du point de vue de la flexibilité des ressources, il apparaît par exemple difficile d’opérer et contrôler une éventuelle diminution demandée de la quantité de mémoire vive et de temps processeur, utilisés par le système d’exploitation d’un client, s’il maîtrise complètement les ressources matérielles d’une machine physique. Comment opérer une mise en commun des ressources matérielles d’une même machine entre plusieurs systèmes d’exploitation si ceux-ci ont pour vocation de s’en approprier la totalité ? Comment mettre en application le concept d’indépendance de la localisation physique pour migrer simplement les différents logiciels et données d’un client d’une machine physique à une autre ?

Les acteurs des systèmes cloud

Il existe 4 acteurs principaux dans les systèmes cloud.

Le client Le client est une personne qui va consommer le service d’un cloud. Elle peut être la même que le gérant du cloud dans le cas du cloud privé ou faire partie d’une organisation différente si l’on considère un cloud public. Dans la très grande majorité des cas, ces personnes ne possèdent pas de privilèges sur la partie administrative de l’infrastructure et n’ont pas d’accès physique aux machines du cloud.

L’administrateur du cloud Un administrateur de cloud est une personne physique appartenant à l’organisation gérante du cloud. Afin d’exercer son activité, il possède donc des privilèges élevés sur l’infrastructure et parfois même un accès physique aux machines hôtes qui composent le cloud.

Machines distantes Ce groupe comprend toutes les machines et leurs utilisateurs pouvant communiquer, au travers d’un réseau quelconque, avec une interface physique présente sur une des machines hôtes du cloud. Dans notre étude, cet acteur comprend aussi les autres machines hôtes faisant partie du même cloud.

Les constructeurs de matériel Ce dernier type d’acteur est spécial dans le sens où il ne va pas utiliser / administrer et interagir avec le cloud en production, mais est tout de même essentiel à représenter dans notre modèle de menace. Afin d’exécuter les logiciels et communiquer avec le monde extérieur, les concepteurs de systèmes et fournisseurs de service s’appuient sur ces matériels produits par ce type d’acteur. Ces matériels sont très complexes et leur chaîne de production n’est pas forcément maîtrisée en termes de sécurité, du début à la fin par les constructeurs, à cause de problématiques de sous-traitance par exemple. Pour ces raisons, leur intégration dans l’analyse de sécurité des systèmes cloud est donc, selon nous, indispensable.

Table des matières

Introduction
1 Contexte scientifique et État de l’art
1.1 Le cloud computing
1.1.1 Caractéristiques essentielles du cloud
1.1.2 Les acteurs des systèmes cloud
1.2 Virtualisation et machines virtuelles
1.2.1 Types de virtualisation
1.2.2 Techniques de virtualisation
1.2.3 Mise en œuvre des machines virtuelles
1.3 Gestionnaires de machines virtuelles
1.3.1 Architecture
1.3.2 Fonctionnement et rôle de l’hyperviseur
1.4 Vulnérabilités et attaques
1.4.1 Terminologie de la sécurité informatique
1.4.2 Problèmes de sécurité apportés par la virtualisation
1.4.3 Modèle de menaces
1.4.4 Attaques des systèmes virtualisés
1.5 La sécurité dans les architectures virtualisées
1.5.1 Surveillance des machines virtuelles
1.5.2 Renforcement de l’isolation
1.5.3 Vulnérabilité du logiciel et confiance dans le matériel
1.6 Objectifs de la thèse
2 Étude des architectures matérielles actuelles
2.1 Introduction
2.2 Les processeurs Intel récents
2.3 Mécanismes d’isolation et de contrôle d’accès
2.3.1 Les cœurs
2.3.2 Interconnexion du processeur
2.3.3 Interconnexion des périphériques
2.3.4 Démarrage et chaîne de confiance
2.4 Rappels techniques
2.4.1 Détails sur l’architecture Intel 64
2.4.2 Extension matérielle d’assistance à la virtualisation
2.4.3 Interconnexion des périphériques
2.5 Conclusion
3 Architecture de sécurité
3.1 Introduction
3.2 Modèle de menaces et hypothèses
3.3 Attestation de code et racine de confiance dynamique
3.4 Vue d’ensemble de l’approche proposée
3.4.1 Infrastructure matérielle
3.4.2 Périphérique de confiance
3.4.3 Hyperviseur de sécurité
3.5 Cycle de test d’intégrité
3.5.1 Les challenges
3.5.2 Les tests d’environnement
3.5.3 Tests d’intégrité du logiciel observé
3.6 Intégrité de l’hyperviseur de sécurité
3.6.1 Espace mémoire et chargement
3.6.2 Modes et niveaux de privilèges
3.6.3 Gestion de la mémoire et des caches
3.6.4 Compteurs et fréquence de fonctionnement
3.6.5 Gestion des interruptions externes
3.6.6 Gestion des périphériques
3.6.7 Isolation
3.7 Conception des challenges et tests d’environnement
3.7.1 Expressivité des tests d’environnement
3.7.2 Expressivité des challenges
3.7.3 Détermination du temps d’exécution
3.7.4 Vérification des caractéristiques de l’hyperviseur de sécurité
3.7.5 Détection de l’émulation ou de la virtualisation de l’hyperviseur
3.8 Conclusion
Conclusion

Lire le rapport complet