CASSIOPEIA. CLOUD Application Supplying Secure Infrastructures Over Pre- Existing Intranet Architecture. Proyecto de Grado - Georges Chaudy

Transcription

1 CASSIOPEIA CLOUD Application Supplying Secure Infrastructures Over Pre- Existing Intranet Architecture Proyecto de Grado - Georges Chaudy Universidad de los Andes Facultad de Ingeneria DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN BOGOTÁ D.C. JUNIO

2 CASSIOPEIA CLOUD Application Supplying Secure Infrastructures Over Pre- Existing Intranet Architecture Proyecto de Grado - Georges Chaudy Proyecto de grado presentado al departamento de Ingeniero de Sistemas y computación de la Universidad de Los Andes Director: PhD. Claudia Lucia Jiménez Guarín Profesora Asociada Universidad de los Andes Facultad de Ingeneria DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN BOGOTÁ D.C. JUNIO

3 Table des matières 1 Synthèse Introduction Les systèmes distribués et ses outils Les contraintes associées aux systèmes distribués Description du problème Antécédents et contexte MAGOS et son histoire MAGOS CLOUD SECURE en quelques lignes Les points fort de MAGOS CLOUD SECURE Infrastructure As A Service Un système déclaratif Virtualisation au cœur de MAGOS CLOUD SECURE Opportunisme La tolérance à l'erreur Sécurité La configuration automatique des machines générées Les faiblesses de MAGOS CLOUD SECURE Attribution des adresses IP Complexité du déploiement Risques de failles des serveurs Complexité de génération de nouvelles plateformes Absence de GUI Evolution de PUPPET Sécurité partielle CASSIOPEIA prend la relève Description générale de la solution Objectif général Objectifs spécifiques Stratégie globale Stratégies spécifiques Architecture réseau Architecture logicielle Architecture du système

4 5.1 Cas d'utilisation Diagramme de classes Diagrammes de déploiement et composants Infrastructure physique Infrastructure virtuelle Diagrammes de séquence Sécurité du système Politique de sécurité Mécanismes de sécurité Implémentation Langage Ruby Ruby on Rails EnvironnementsCASSIOPEIA Gestionnaire de version Versions des logiciels Validation et résultats Conclusion et travaux ultérieurs Bibliographie

5 Table des illustrations : Figure 1 Composants de MAGOS CLOUD SECURE... 9 Figure 2 Réseau Privé Virtuel N2N Figure 3 Réseau Privé Virtuel OpenVPN Figure 4 Diagramme de cas d'utilisation Figure 5 Diagramme de classe Figure 6 Diagramme de déploiement Figure 7 Diagramme de composants du serveur CASSIOPEIA Figure 8 Diagramme de composant d'un nœud CASSIOPEIA Figure 9 Diagramme de déploiement d'une machine virtuelle Figure 10 Diagramme de déploiement de l'infrastructure virtuelle Figure 11 Diagramme de séquence. Installation Figure 12 Diagramme de séquence. Gérer les utilisateurs Figure 13 CRON jobs Figure 14 Utilisation de l'api Rest de Puppet Figure 15 Diagramme de séquence. Surveillance Nagios Figure 16 Diagramme de séquence. Déployer une plateforme Figure 17 Diagramme de séquence. Déployer une application Figure 18 Communication sécurisée avec puppet Figure 19 Isolation des machines virtuelles offerte par VMware sur une machine physique

6 1 Synthèse Les systèmes distribués prennent une place de plus en plus importante de par le monde. Ils permettent aux entreprises et universités le stockage et le calcul intensif, en utilisant des machines bon marché. De nombreux outils font surface dans les communautés open source facilitant la création d applications d E-Science et Web 2.0. Les applications actuelles, que ce soit dans le contexte scientifique ou industriel, doivent considérer l utilisation d infrastructures distribuées pour répondre à un nombre grandissant d utilisateurs et permettre la gestion d un volume important de données. Malheureusement, la mise en place d infrastructures distribuées est un défi difficile à relever. Les frais d achat, d entretien, de maintenance et d administration des machines s avèrent très importants. De plus, les connaissances nécessaires pour apprendre à maitriser de tels systèmes et comprendre les rouages internes sont difficiles à acquérir. Enfin, la sécurité de l infrastructure doit être en permanence assurée. CASSIOPEIA propose une solution simple afin de générer rapidement et à moindre coût des plateformes sûres, pouvant être mises à l échelle, équipées des dernières technologies en matière de systèmes répartis. CASSIOPEIA s'adresse aux chercheurs et développeurs Web désireux d'utiliser des systèmes répartis et disposant déjà d'un réseau d'ordinateurs au sein de leur entreprise ou université qu ils souhaitent rentabiliser en capitalisant l espace et le temps de calcul sous-utilisé. 2 Introduction 2.1 Les systèmes distribués et ses outils Le stockage et le traitement de grands volumes de données est au cœur de l innovation scientifique.de plus en plus, les systèmes distribués s imposent dans les entreprises et universités, permettant d augmenter de manière significative la capacité de traitement et de stockage des données, ainsi que de créer des applications destinées à un nombre croissant d utilisateurs. L apparition des réseaux sociaux marque une étape majeure dans l évolution des systèmes distribués. Les grandes entreprises comme Google, Facebook ou Amazon construisent de gigantesques data center aux quatre coins du monde afin de disposer de la puissance de calcule nécessaire pour leurs applications CLOUD. Chaque data center héberge plusieurs milliers de serveurs reliés au monde par plusieurs connections très haut débit. Les données y sont encryptées, dupliquées et protégées par plusieurs couches de sécurité. Ce type d infrastructure permet de proposer des services tels que Youtube où sont stockées chaque minute près de 60 heures de nouvelles vidéos, regardés chaque jour près de quatre milliards d enregistrements et analysésquotidiennement près de 100 ans de contenu [1]. 6

7 Le monde scientifique, de son côté, collabore dans des projets comme EGEE [2]afin de créer des infrastructures de type GRID et augmenter sa capacité de traitement. Ainsi, ce sont plus 15 petabytes de données générées chaque année par le LHC, l accélérateur de particules du CERN, qui sont transmis et traités dans près de 200 sites sur trois continents. [3] Les applications actuelles, que ce soit dans le contexte scientifique ou industriel, doivent considérer l utilisation d infrastructures distribuées pour répondre à un nombre grandissant d utilisateurs et permettre la gestion d un volume important de données.heureusement, de nombreux outils permettant le traitementet le stockage en parallèle sont aujourd hui disponibles dans les communautés open source. On peut distinguer deux catégories d outils principales.d'une part, les bases de données dites NoSQL, [4] qui permettent le stockage en parallèle de grands volumes de données. A la différencedes bases de données relationnelles, ces outils garantissent un temps d'accès relativement faible quelle que soit la quantité d information stockée [5]. Les données sont réparties et dupliquées surun cluster d'ordinateurs. Plus le nombre de machines composants le cluster est grand, plus la capacité de stockage du système augmente. Malheureusement, ce type d outils ne peut être transactionnel, ne pouvant offrir qu une cohérence partielle des données au profit d un temps d accès minimal. Pour citer un exemple, Cassandra, l'hériter libre du système NoSQL de Facebook est largement utilisé à travers le monde, notamment au sein d'applications Web [6]. Dans un deuxième temps, on trouve les outils permettant le traitement en parallèle des données. Hadoop [7], la version libre du File Système de Google [8], est une référence dans le domaine. Très apprécié dans le milieu de la recherche, il permet de traiter en parallèle des données sur de grands clusters de machines, tout en garantissant leur intégrité. Puissants, les outils de calcul reparti sont à la pointe de l'innovation et permettent une infinité d'applications. Méconnus, ils sont souvent substitués par des outils plus conventionnels tels que les bases de données relationnelles, moins efficaces à grande échelle. 2.2 Les contraintes associées aux systèmes distribués Les systèmes distribués peuvent être utilisés pour une infinité d usages distincts. On les retrouve souvent au cœur d application de type Web 2.0 comme les moteurs de recherche ou les réseaux sociaux. On les retrouve aussi au sein d applications d E-science, par exemple dans des applications de biologie ou de physique qui requièrent l analyse de grandes quantités de données. Bien que les systèmes répartis soient très utiles, leur mise en place est un défi souvent difficile à relever. Plusieurs facteurs empêchent les développeurs de faire le choix de ces technologies.le premier facteur limitant est bien sûrmatériel et donc financier. Le calcul distribué repose sur des clusters de machines dédiées autraitement et stockage des données. Certes, les machines nécessaires peuvent être de bon marché. En effet, les systèmes répartis disposant de mécanismes de récupération, l état global du système n est pas compromis en cas de faille. Néanmoins, les frais d'achat, de maintenance, d'administration ne peuvent pas être ignorés et restent très importants. La facture finale peut s'avérersalée. 7

8 Le tempset les connaissances nécessaires à la mise en place de systèmes distribués peuvent aussi être considéréscomme une limitation. En effet, les outils de calcul distribués sont récents et souvent mal documentés. Leur installation peut être complexe. Il faut d'abord configurer l environnement d'exécution, choisir le système d'exploitation, installer les dépendances, configurer les droits d'accès, tout un ensemble de petites choses qui demande de vastes connaissances. Ensuite, le temps de configuration du réseau ne doit pas être pris à la légère. L'interconnexion des machines, la définition d'une politique de nommage, l'attribution des plages d'adresses demandent de la patience. Pour finir, il faut du temps pour apprendre à maitriser le système et comprendreen détail les rouages internes. Un dernier facteur, souvent négligé, est la sécurité de l'infrastructure. Bien plus complexe qu'un système présent sur une seule machine, plusieurs niveaux de sécurité doivent être pris en compte. An niveau logiciel, il faut configurer les doits d'accès et la sécurité des communications. Au niveau de la machine, la configuration des pare-feux, des accès SSH et politique d assignation des mots de passe. Enfin, au niveau du réseau, il faut s'assurer configurer les règles de routeur et contrôler les flux de données. L'utilisation de systèmes répartis requière des connaissances transversales, ainsi qu un investissement matériel, financier et humain important. Bien que les possibilités offertes par de tels systèmes soient attrayantes, beaucoup de gens préfèrent encore se tourner vers des systèmes plus traditionnels, moins complexes, probablement car ils sont plus rassurants. 2.3 Description du problème CASSIOPEIA propose une solution simple afin de générer rapidement et à moindre coût des plateformes sûres, pouvant être mises à l échelle, équipées des dernières technologies en matière de systèmes répartis. CASSIOPEIA s'adresse aux chercheurs et développeurs Web désireux d'utiliser des systèmes répartis et disposant déjà d'un réseau d'ordinateurs, au sein de leur entreprise ou université, qu ils souhaitent rentabiliser en capitalisant l espace et le temps de calcul sous-utilisé. 3 Antécédents et contexte Le projet CASSIOPEIA est le résultat d'une longue évolution qui débutât il y a plusieurs années avec le projet MAGOS [9]. Au fil des itérations, le projet a grandipermettant d'englober un plus grand spectre d utilisateurs, tout en augmentant la fiabilité du système et sa sécurité. L'évolution des technologies associées au projet nous permet aujourd'hui de revoir l'architecture du système et de proposer une meilleureexpérience d'utilisation. 3.1 MAGOS et son histoire Le projet MAGOS (Middleware Architecture for GridOriented Services) [9]débutât avec la volonté d'offrir aux développeurs SOA une gestion facile de sur une infrastructure type GRID. L'utilisateur déclarait au moyen d un fichier XML les besoins fonctionnels qu'il attendait d'une infrastructure de 8

9 type GRID, définissait les flux de travail et fournissait un ensemble de fichiers à traiter. MAGOS se chargeait alors de générer l'infrastructure nécessaire à l'exécution du flot de données de l'utilisateur. Après les premières utilisations du système, l'équipe MAGOS prit conscience de nombreuses améliorations possibles, dont deux principales. Tout d'abord que les besoins des utilisateurs ne se limitaient pas à la création de flots de données, notamment dans le monde de la biologie et que MAGOS devait permettre la création de processus plus complexes. Ensuite, que beaucoup d'applications reposaient sur des sources de données autres que des fichiers, comme le Web, bases de données distribuées, capteurs. Ainsi naquit MAGOSCLOUD qui marque le changement du paradigme GRID à celui de CLOUD, MAGOSCLOUD reposant sur la virtualisation, la mutualisation des ressources et la génération d infrastructures de systèmes distribués. L'ultime version du middleware, intitulée MAGOS CLOUD SECURE, marque une évolution majeure avec l ajout de la couche d authentification des utilisateurs et les sécurisations des communications. Dans la suite de cette section, nous souhaitons analyser en détail les points forts et faiblesses de MAGOS CLOUD SECURE afin d y proposer un ensemble d améliorations. 3.2 MAGOS CLOUD SECURE en quelques lignes MAGOS CLOUD SECURE est un middleware permettant de générer et configurer des machines virtuelles sur une infrastructure d ordinateurs existante. Cette infrastructure physique est composée d un ensemble d ordinateurs qui, lorsqu ils ne sont pas utilisés, sont exploités par MAGOS CLOUD SECURE afin d héberger jusqu à deux machines virtuelles. On parle d architecture opportuniste car l application utilise les ressources inexploitées de l entreprise. Les machines physiques, pour être compatible avec MAGOS CLOUD SECURE, doivent disposer d un système d exploitation Windows, de l hyperviseur de virtualisation VMware Workstation et pouvoir exécuter des applications JAVA. Figure 1 Composants de MAGOS CLOUD SECURE 9

10 MAGOS CLOUD SECURE s organise autour de huit composants principaux : PUPPET Chaque machine virtuelle est configurée par le gestionnaire de configuration PUPPET. Un client Puppet est installé sur chaque machine virtuelle. Il se connecte à un serveur Puppetconfiguré pour satisfaire les besoins de l application. PUPPET se charge d installer la configuration décrite par l utilisateur sur une machine Debian vierge. PUPPETinstalle par exemple automatiquement Java, Hadoop ou Glassfish sur la machine spécifiée. Pour savoir quelle configuration installer sur quel serveur, PUPPET communique avec le composant MCServer au moyen d un script shell appelé ExternalNode [10] MCNode C est une application Java exécutée sur les machines physiques Windows. Elle reçoit depuis le composant MCLoadBalancer des demandes de création de machines virtuelles. Afin de créer celles-ci, le composant génère un Link Clone [11]à partir d une machine virtuelle Debian Template. Il démarre ensuite la machine virtuelle grâce à l API de communication VMware VIX [12], lui attribue une adresse IP publique et y démarre le client PUPPET. Le composant se charge ensuite de surveiller l état de la machine physique qu il transmet au composant MCLoadBalancer MCInstance Cette application Java est exécutée sur les machines virtuelle Linux. Elle est pré installée, tout comme PUPPET, sur les machines virtuellestemplate Debian. Elle reçoit les demandes de mis-à-jour de la machine virtuelle en provenance du composant MCserver. Suite à une demande de mise à jour, le client Puppet est éxécuté. Le composant se charge aussi de surveiller l état de la machine virtuelle qu il transmet au composant MCLoadBalancer MCLoadBalancer Cette application Java est exécutée sur un serveur Linux autonome. Elle reçoit les demandes de création de nouvelles plateformes depuis le composant MCServer qu elle transforme en demandes de création de machines virtuelles. L application prend en compte l occupation réelle des machines physique et leur charge de travail CPU afin de choisir celle qui est la plus apte à héberger une nouvelle machine virtuelle. Une fois la machine cible identifiée, MCLoadBalancer envoie au composant MCNodede cette dernière la demande de création de machine afin qu il procède au déploiement de la machine virtuelle Serveur Kerberos Le système de sécurité de MAGOS CLOUD SECURE s organise autour d un serveur Kerberos assurant la sécurité de l infrastructure à plusieurs niveaux. Il permet d abord de garantir la sécurité des communications entre chaque composant du système. Ensuite, il offre un système d authentification unique (Single Sign in) aux utilisateurs. Pour finir, il permet d associer un rôle à chaque utilisateur, d associer une liste d actions autorisées pour chaque rôle, ainsi quede vérifier que l utilisateur est en droit d effectuer une action suivant son rôle Serveur LDAP Ce serveur est associé au serveur Kerberos. Il est utilisé comme répertoire pour stocker les clés générées par le serveur kerberos. Ce serveur peut potentiellement être remplacé par un serveur LDAP déjà existant au sein de l entreprise. 10

11 Serveur DNS Ce serveur permet de stocker l association entre noms de domaines et adresse IP des machines générées par MAGOS CLOUD SECURE MCServer Il s agit du cœur de l application, implémentant tous les objets métier et l intelligence du système. MCServer est une application JAVA exécuté sur serveur autonome. Il fonctionne en symbiose avec le serveur Puppet, lui fournissant les informations nécessaires pour configurer les machines virtuelles de l infrastructure MySQL server Le serveur MySQL permet la persistance des objets métiers générés par MAGOS CLOUD SECURE. Le serveur possède un script SQL de configuration. 3.3 Les points fort de MAGOS CLOUD SECURE MAGOS CLOUD SECUREest défini par un certain nombre de caractéristiques qui font sa force. Afin de mieux comprendre ce qu'est MAGOS CLOUD SECURE, nous souhaitons les illustrer en détail cidessous Infrastructure As A Service MAGOS CLOUD SECURE est un service CLOUD permettant la génération d'infrastructures comme Service. L'utilisateur choisit dans le catalogue l infrastructure ou système distribué qu'il souhaite pour réaliser son application. Par exemple, un développeur d'applications d'e-science pourra formuler la demande d'une infrastructure Hadoop composée d'une machine maîtresse et quatre machines esclaves. MAGOS CLOUD SECURE se charge alors de la génération des cinq machines, leur assigne une adresse IP propre, déploie le système distribué Hadoop, puis remet les codes d'accès de la machine maîtresse à l'utilisateur afin qu'il y installe son application. MAGOS CLOUD SECURE permet ainsi de livrer des infrastructuresprêtes à l'emploi à ses utilisateurs Un système déclaratif MAGOS CLOUD SECURE s'adapte aux demandes des utilisateurs. En effet, chaque utilisateur et chaque application est unique. De la même manière, chaque plateforme doit être unique et correspondre au mieux à besoins fonctionnelles du système. Au moyen d'un fichier XML, l'utilisateur spécifie ses besoins et MAGOSCLOUD se charge du reste. Par exemple, dans le projet SismoMAGOS, l utilisateur installe une application d E-science spécifique au domaine de la sismologie et parallélise le traitement des données grâce au système distribué Hadoop Virtualisation au cœur de MAGOS CLOUD SECURE Afin de générer les plateformes spécifiées par l'utilisateur, MAGOS CLOUD SECUREvirtualise les machinespour plusieurs raisons. D'une part, la virtualisation permet une abstractiondumatériel physique et d'uniformiser les ressources. Ainsi, MAGOSCLOUD n'a pas à se soucier de la gestion de 11

12 drivers et est compatible avec toute machine supportant les outils de virtualisation. Dans un deuxième temps, la virtualisation permet de mutualiser les ressources et installer plusieurs machines virtuelles sur une même machine physique. Cela permet de garantir un usage optimal des ressources. Enfin, la virtualisation facilite la gestion du parc de machines, permettant une gestion à distance, le déplacement des machines virtuelles et bien plus encore Opportunisme L'originalité de MAGOSCLOUD est sa capacité de s'intégrer à une infrastructure physique existante. Les universités, par exemple, disposent en général d'un ensemble d'ordinateurs disponibles pour ses élèves, représentant un capital de ressourcesnon négligeable. Après une analyse détaillée de l'utilisation des ordinateurs d'une de ses salles informatiques, l'université Los Andes a conclu que seul 10% des ressources de celle-ci sont utilisées en moyenne. Les élèves étant présents en journée, réalisant non seulement des tâches de bureautique peu gourmandes comme la saisie de rapport ou la vérification d' s, mais aussi des travaux de programmation et de modélisation bien plus consommateur en ressources. Ils conclurent qu'il serait dommage de laisser un tel capital inexploité. MAGOS CLOUD SECURE est dit opportuniste car il sonde les machines existantes et y déploie ses machines virtuelles lorsqu elles ne sont pas utilisées. Pour cela, MAGOS CLOUD SECURE utilise des hyperviseurs de niveau 2, c est-à-dire installé au-dessus d un système d exploitation comme logiciel, pour déployer ses machines virtuelles. Plus précisément, MAGOS CLOUD SECURE utilise Vmwareworkstation pour réaliser cette tâche La tolérance à l'erreur L infrastructure physique de MAGOS CLOUD étant opportuniste, il est impossible de garantir la stabilité des machines. En effet, les ordinateurs hôtes peuvent être arrêtés par mégarde, ou tout simplement être réquisitionnés par un élève ou employé de l entreprise. MAGOSse charge alors de redéployer les machines virtuelles vers une autre machine hôte afin de garantir une continuité de service. L utilisateur ne perçoit pas l indisponibilité des machines, ni lors du processus de déploiement d une infrastructure, ni lors de l exécution de son application Sécurité La sécurité est la préoccupation principale de MAGOS CLOUD SECURE. Plusieurs niveaux de sécurité ont été mis en place. D une part, l authentification des utilisateurs. Chaque utilisateur se voit attribuer un rôle et un ensemble d action autorisée. L utilisation d un système Kerberos permet d assurer cette tâche. D autre part, MAGOS CLOUD SECURE crypte les communications entre chacun de ses composants. Ce niveau de sécurité est essentiel car toutes les communications passent par l infrastructure hôte et peuvent être facilement interceptées. Pour finir, MAGOS CLOUD SECURE cherche à encrypter les communications issues des systèmes distribués générés. La communication entre plusieurs machines d un cluster Hadoop peut ainsi être sécurisée. 12

13 3.3.7 La configuration automatique des machines générées. La stratégie de déploiement des machines virtuelles utilisée par MAGOS CLOUD SECURE se base sur l utilisation d un gestionnaire de configuration. En effet, MAGOS CLOUD SECURE déploie des machines virtuelles contenant un système d exploitation Debian de base. Une fois fonctionnel, le gestionnaire de configuration se charge de l installation des outils définis par l utilisateur. Le travail d un développeur expert consiste donc en la traduction du processus d installation d un système réparti en langage PUPPET. Ce processus est plus ou moins simple. L installation de Cassandra, par exemple, requière l installation de Java, l extraction de l archive tar de Cassandra, la modification des fichiers de configuration et pour finir l exécution d un script de démarrage. Un simple fichier décrivant ce processus en langagepuppet permet l installation sur une nouvelle machine virtuelle. 3.4 Les faiblesses de MAGOS CLOUD SECURE Au fur et à mesure de l utilisation de MAGOS Cloud Sécure, un certain nombre de faiblesses du logiciel ont fait surface Attribution des adresses IP L attribution de l adresse IP d une machine générée par MAGOS CLOUD SECURE est réalisée à partir d une liste d adresses mises à disposition par le propriétaire de la plateforme physique. Une telle architecture possède des contraintes. Une première contrainte est liée au caractère évolutif du système. En effet, la capacité de création, ou nombre de machines virtuelles qui peuvent être créées par MAGOS CLOUD SECURE, est restreinte par le nombre d adresses publiques allouées par l administrateur. Une petite entreprise ne disposant que de deux adresses publiques ne pourra pas générer une plateforme Hadoop de 5 machines, même si elle dispose d un nombre d hôtes suffisant pour les accueillir. Bien plus grave, l attribution d une adresse publique à chaque machine entraine une vulnérabilité importante. Toute machine sera alors visible depuis le réseau local, voir depuis internet, la rendant vulnérable aux attaques non prévues par le système Complexité du déploiement Le processus de mise en service de MAGOS CLOUD SECURE est très complexe. A l heure actuelle, le déploiement de MAGOS CLOUD SECURE requière : L installation et la configuration de 8 serveurs différents : MCServer, MCBalancer, MCNode, Kerberos, LDAP, MYSQL, DNS et PUPPET server. La modification du code source : où sont inscrites les adresses des autres servers qui composent MAGOS CLOUD SECURE. 13

14 La version de production de MAGOS CLOUD SECURE est présente sur trois machines différentes, dont une virtuelle, rendant l identification des problèmes un véritable challenge Risques de failles des serveurs A l inverse des plateformes générées, les serveurs de MAGOS CLOUD SECURE sont vulnérables en cas de faille. Ne disposant pas de système de récupération, l arrêt d un des serveurs entraine la mise hors-service de la totalité du système Complexité de génération de nouvelles plateformes L un des points forts de MAGOS CLOUD SECURE est la possibilité de mettre de nouveaux types de plateformes à disposition des utilisateurs. Un développeur expert du système distribué Cassandra, peut ainsi décider de suivre le processus de création d un type de plateforme. Cette plateforme sera ensuite disponible pour tous les utilisateurs. Le processus de création d un type de plateforme est composé de3 étapes : Création des fichiers de configuration en langage PUPPET. Ajouts du type de plateforme dans la base de données Modification du code source de MAGOS CLOUD SECURE pour prendre en charge le nouveau type de plateforme. Une machine Hadoop Master a par exemple besoin de connaitre son facteur de réplication, ainsi que la liste des adresses et noms de ses esclaves. Les deux premières étapes requièrent une connaissance de PUPPET et de SQL, mais ne posent aucun problème particulier. La dernière étape requière une connaissance détaillée du code de MAGOS CLOUD SECURE, rendant bien complexe l ajout d un nouveau type de plateforme Absence de GUI L interface de communication existante pour ajouter des utilisateurs, déployer une plateforme, partager des ressources est constituée d un ensemble de scripts Windows et Linux. Ses scripts doivent être exécutés avec les droits appropriés, sur la bonne machine. Le besoin d une interface graphique pour centraliser les actions se fait ressentir Evolution de PUPPET PUPPET est une référence dans le domaine de la configuration automatique de machines. Depuis MAGOS CLOUD SECURE, PUPPET à connue plusieurs évolutions majeures, notamment trois importantes. Premièrement, la compatibilité avec les machines Windows. L utilisation de cette fonctionnalité permettrait de simplifier significativement le flot de communication du système. Deuxièmement, la possibilité depuis le serveur de forcer le client à se rafraichir sa configuration. Jusqu à présent, MAGOS CLOUD SECURE implémentait lui-même cette fonctionnalité en envoyant un signal de MCServer à MCBalancer, de MCBalancer à MCNode puis de MCNode à MCInstance. Enfin, 14

15 PUPPET dispose maintenant d'une API Web pour exécuter les commandes de base et récupérer les rapports d état des machines Sécurité partielle Plusieurs failles dans la sécurité de MAGOS CLOUD SECURE ont été identifiées. MAGOS CLOUD SECURE effectue un travail remarquable pour protéger les machines virtuelles qu il génère des attaques extérieures. Comme nous l avons vue précédemment, toute machine générée se voit attribuer une adresse IP publique et est accessible depuis le réseau extérieur. La mise en place de pare-feux et la gestion des droits d accès rendent les attaques complexes. Plus le nombre de machines virtuelles générées est grand, plus un attaquant dispose de portes d entrée potentielles. Il faut donc veiller en permanence à la mise à jour des systèmes de protection pour éviter les attaques connues et répertoriées. Un aspect de la sécurité pris en compte partiellement par MAGOS CLOUD SECURE est la protection contre les attaques venant du réseau interne, plus précisément en provenance des machines physiques de l infrastructure. En effet, les utilisateurs des machines physiques peuvent potentiellement écouter le trafic circulant sur la carte réseau de la machine, dont les communications sortantes des machines virtuelles hébergées sur la machine. Par défaut, le système est donc en permanence confronté à des attaques de type Man in the middle. Heureusement, les communications entre les composants de MAGOS CLOUD SECURE sont cryptées par le serveur Kerberos et protégées pour ce type d attaque. Malheureusement, les autres communications entre machines virtuelles, comme les requêtes ARP, DNS ou les requêtes venant d une application utilisateur peuvent être interceptés. L attaquant peut ainsi disposer d informations critiques sur le système. On remarquera notamment qu un mouchard, installé sur une ou plusieurs machines physiques, permettrait d enregistrer un grand volume d information qui, une fois croisé et analysé, pourrait révéler des informations compromettantes. Pour finir, nous remarquons que le système d authentification fourni par le serveur Puppet est complètement désactivé. Cette faille est la plus importante. Une machine extérieure à l infrastructure peut ainsi facilement se faire passer par une machine virtuelle de MAGOS CLOUD SECURE. En effet, il lui suffit seulement de connaitre le nom de la machine cible pour pirater le système. 3.5 CASSIOPEIA prend la relève Il est important de signaler le côté obsolète du nom de MAGOS CLOUD SECURE. L acronyme du nom MAGOS(Middleware Architecture for Grid Oriented Services) est associé au concept de GRID, alors que le système est de type CLOUD. Aussi, depuis sa seconde version, le système n est plus orienté service ce qui rentre en contradiction avec son nom. Un rafraichissement du nom MAGOS CLOUD SECURE s impose. CASSIOPEIA, ou Cassiopée en Français, est l une des plus belles constellations qui illuminent nos nuits. Elle raconte la belle histoire d Andromède, fille de la reine Cassiopée et du roi Céphée, 15

16 princesse d Éthiopie. L utilisation de CASSIOPEIA comme nom permet de mettre en avant le concept de constellation de machines. 4 Description générale de la solution 4.1 Objectif général Revoir l architecture et l implémentation de MAGOS CLOUD SECURE dans le but de simplifier son déploiement, surveiller l état de l infrastructure, augmenter la stabilité du système, faciliter le développement de nouveaux types de plateforme et simplifier son utilisation, tout cela dans un environnement sécurisé. 4.2 Objectifs spécifiques Regrouper les machines virtuelles générées au sein d un réseau virtuel privé. Surveiller l état du système à l aide d outils spécialisés. Simplifier le processus de développement de nouvelles plateformes. Créer une interface graphique. 4.3 Stratégie globale Afin de mettre en place les améliorations citées ci-dessus, deux approches distinctes s offrent à nous. La première consiste en la modification de l application existante. Il s agit donc de réaliser un audit détaillé de l application afin d identifier les bugs, les fonctionnalités manquantes et implémenter les modifications nécessaires. La deuxième alternative consiste à réaliser une révision complète de l architecture de MAGOS CLOUD SECURE en reprenant l implémentation sur des bases saines. Après une analyse préliminaire du code source de MAGOS CLOUD SECURE, des évolutions technologiques, la décision fut prise de ré implémenter complètement MAGOS CLOUD SECURE. L architecture vieillissante rendant complexe l ajout de nouvelles fonctionnalités. Les évolutions technologiques permettant une simplification importante des processus. Deux critères en particulier ont fait pencher la bascule. Le code source de MAGOS CLOUD SECURE est fragmenté en un ensemble de scripts répartis sur plusieurs serveurs communiquant entre eux au travers de protocoles mal documentés. 4.4 Stratégies spécifiques Deux axes de réflexions ont été identifiés pour définir la nouvelle architecture du système. D une part, une révision de l architecture du réseau. D autre part, une mise à niveau de l architecture du logiciel. 16

17 4.4.1 Architecture réseau Le premier axe de réflexion porte sur la question de l organisation du réseau et des machines de CASSIOPEIA. Plus haut, nous évoquions la problématique liée à l attribution d une adresse IP à chaque machine générée par MAGOS CLOUD SECURE. Une machine virtuelle se voyait attribuer une adresse IP de classe A, accessible depuis n importe accès internet dans le monde. Le réseau était donc vulnérable en tout point à des attaques venant de l extérieur, avec un grand risque de piratage. Pour résoudre ce problème, la décision fut prise de regrouper les machines virtuelles au sein d un même réseau virtuel privé, ou VPN. Cette stratégie offre plusieurs avantages. Tout d abord, cela permet d isoler complètement les plateformes du reste du monde. Ainsi, seuls les membres du VPN sont en mesure de se contacter les uns les autres. En réalité, les seuls hôtes qui nécessitent une adresse publique sont les serveurs Web et certaines bases de données. Le deuxième avantage majeur est l encryptions de toutes les communications, automatique au sein d un VPN. Rappelons que toutes les communications entre machines passent par la plateforme physique et le réseau local de l entreprise. Tout utilisateur présent sur le réseau est donc en mesure d écouter les communications et d avoir accès au contenu des transmissions. L utilisation d un VPN permet de garantir l intégrité et l authenticité des données. A la différence de MAGOS CLOUD SECUREoù les communications étaient sécurisées au niveau de la couche applicative, l utilisation permet de crypter les communications au niveau de la couche réseau. Cela permet de garantir une sécurité accrue et continue du système, s assurant qu aucun message ne soit transmit en claire. Nous avons étudié deux technologies VPN différentes permettant l implémentation d un VPN Réseau Virtuel Privé pair à pair La première technologie étudiée est VPN de type paire à paire (P2P). L implémentation la plus connue s appelle N2N [13]. Son architecture se base sur deux composants (cf Figure 2 Réseau Privé Virtuel N2N). Les Edgenodess installent sur les machines virtuelles et permettent au réseau d être créé. Une interface réseau Tun/Tap est ajoutée à la machine et sert de point d entrée au VPN. Les Supernodes, de leur côté, sont utilisés pour initialiser la connexion et accéder aux nœuds cachés derrière des Firewall. Ce sont les seuls nécessitants une adresse IP publique. 17

18 Figure 2 Réseau Privé Virtuel N2N L avantage principal de la technologie Pair é Pair est sa capacité de mise à l échelle. Ce type d infrastructure fonctionne très bien avec un nombre important d EdgeNodes. En effet, une fois la communication entre un Edgenodeet un Supernode initialisée, les Edgenodes peuvent ensuite directement communiquer entre eux. La charge au niveau d un supernode est donc minime. Malheureusement, N2N possède deux inconvénients majeurs. D une part, son manque de documentation. Bien que très attrayant, il est peu utilisé et il est difficile de trouver de l aide en cas de problème. Un deuxième inconvénient est l impossibilité de créer des sous réseaux différents. Les machines virtuelles générées pour un utilisateur doivent être en mesure de communiquer entre elles, mais ne doivent pas être accessibles par les machines générées pour un autre utilisateur Réseau virtuel privé client-serveur La deuxième technologie étudiée est une architecture de type Client-Serveur. Openvpn [14] est une référence dans le domaine. Son architecture se base sur deux composants (cf Figure 3 Réseau Privé Virtuel OpenVPN), les clients et les serveurs. Une interface réseau de type Tun/Tap est ajoutée à chaque machine du réseau, client comme serveur, et sert de point d entrée au VPN. Tous les clients se connectent à un serveur et communiquent sur un canal sécurisé avec lui. Les communications entre deux clients passent donc par un serveur qui a le rôle d intermédiaire. 18

19 Figure 3 Réseau Privé Virtuel OpenVPN Openvpn a le grand avantage d être entièrement libre, bien documenté, facile de configuration et dispose d une communauté forte disponible en cas de problème. A la différence de N2N, les serveurs constituent un goulot d étranglement important, lié au fait qu ils centralisent toutes les communications. Cependant, la mise à l échelle de l infrastructure est garantie en multipliant le nombre de serveurs. Au moment de se connecter à un serveur, un client choisit aléatoirement parmi la liste des serveurs celui auquel il souhaite se connecter. Aussi, Openvpn possède la capacité de créer facilement des sous réseaux. Les serveurs, en tant qu intermédiaires entre les clients, peuvent contrôler le flux de communications et bloquer les connections entre deux sous réseaux distincts si nécessaire. La décision fut prise d utiliser OpenVpn pour interconnecter les machines virtuelles générées par CASSIOPEIA au sein d un même réseau virtuel privé Architecture logicielle Un deuxième axe de réflexion porte sur la question de l architecture logicielle de CASSIOPEIA. Nous évoquions antérieurement la difficulté de déploiement de MAGOS CLOUD SECURE. Cette difficulté repose principalement sur la nécessité d installer, de configurer et surveiller sept serveurs différents afin de commencer à utiliser le système. Nous avons donc étudié la possibilité de centraliser les serveurs au sein d une seule et même application. En plus de simplifier le déploiement, le fait de regrouper les serveurs permettrait aussi de supprimer d office les serveurs Kerberos et LDAP. En effet, le serveur Kerberos permet l authentification unique des utilisateurs (single sign in), lui évitant ainsi d avoir à se connecter séparément aux cinq applications java composant MAGOS CLOUD SECURE. Le serveur LDAP, lui, permet le stockage des clés générées par Kerberos. La sécurisation des communications entre les différents composants fournis par Kerberos serait inutile dans le cas d une application unique Deux serveurs sur huit serait ainsi supprimés. Cependant, il faut prendre en compte les risques liés à l assemblage des composants de MAGOS CLOUD SECURE. Deux risques majeurs sont à éviter. 19

20 Premièrement, il est important d éviter les goulots d étranglement. Plus l application a de taches à effectuer, plus la charge de la machine qui l héberge augmente. Pour éviter de saturer la machine hôte, Il nous faut donc simplifier au maximum les taches assignées à l application et déléguer les processus complexes aux autres machines de l infrastructure. Dans un deuxième temps, il limite les risques en cas de failles du système. Aucune application n est parfaite et une erreur est vite arrivée Déléguer la communication à PUPPET Comme nous l avons vu dans l introduction, de nombreuses fonctionnalités ont été ajoutées au gestionnaire de configuration PUPPET depuis la première version de MAGOS CLOUD SECURE. Grâce à celles-ci, la plupart des communications nécessaires au bon fonctionnement de CASSIOPEIApeuvent être déléguées à PUPPET, nous obligeant à exploiter au maximum les fonctionnalités proposées par ce dernier. PUPPET est un logiciel largement utilisé à travers le monde et sa stabilité est éprouvée. Deux types de communicationspeuvent ainsi être pris en charge par PUPPET. Dans un premier temps, tout le mécanisme de déploiement des machines virtuelle impliquant les composants MCServer, MCLoadBalancer, MCInstance et MCNodepeut être ré implémenté à l aide de PUPPET. En effet, la prise en charge des machines Windows ajouté dans les versions 2.7.X de PUPPET nous permet aujourd hui de gérer la configuration de toutes les machines physiques de CASSIOPEIA. Ensuite, le processus de rafraichissement des machines, autrefois implémenté manuellement par les composants MCLoadBalancer, MCNode et MCInstance, est remplacé par la commande Kick offerte par PUPPET. De la sorte, après une modification de l infrastructure coté serveur, CASSIOPEIA demande ainsi aux machines nécessitant une modification de mettre à jour leur configuration Surveillance de l infrastructure avec PUPPET MAGOS CLOUD SECURE implémentait toute un processus pour récupérer l état des machines. Les composants MCNode et MCInstance sondaient respectivement l état des machines physiques et machines virtuelles, puis transmettaient un rapport au composant MCBalancer. Une fonctionnalité bien intéressante de PUPPET qui est sa capacité de gestion des Facts. Le client PUPPET collecte un certain nombre d informations de sa machine hôte, qu il transmet ensuite au serveur qui les utilise pour adapter la configuration de la machine cible. Par exemple, le serveur connait ainsi le type de système d exploitation, le nom de la machine, le type de CPU, la mémoire libre et bien plus encore. Mieux encore, PUPPET nous permet de créer des faits personnalisés afin de récupérer tout type d information à propos de la machine cible. Le développeur n a qu à spécifier les commandes à exécuter sur les machines cibles et PUPPET se charge de tout le processus d exécution et de récupération de l information. Grace à cette fonctionnalité, nous pouvons vérifier par exemple quels composants sont installés sur une machine physique, le nombre d utilisateurs connectés, ou encore l état des machines virtuelles. 20