Evaluation et analyse de la Plateforme de gestion de confiance

Systèmes distribués

Un système informatique distribué est une collection de machines ou de calculateurs autonomes qui sont connectés à l’aide d’un réseau de communication. Chaque machine exécute des fonctions (séquences de calculs) en utilisant un intergiciel (middleware1), qui s’occupe d’activer des fonctions et de coordonner leurs activités de telle sorte qu’un utilisateur perçoive le système comme un système intégré unique. Il n’y a pas de définition universellement acceptée du terme système distribué, au contraire cela décrit des systèmes d’information avec des architectures et caractéristiques très différentes. Dans la littérature, on peut trouver diverses définitions. Il a été défini par Tanenbaum (Tanenbaum & Van Steen, 2007) par : « un ensemble d’ordinateurs indépendants qui apparaît à un utilisateur comme un système unique et cohérent ». Et par Lamport (Lamport, 1978) : « un système réparti est un système qui vous empêche de travailler quand une machine dont vous n’avez jamais entendu parler tombe en panne ». Ainsi, un système distribué est un système constitué d’un ensemble d’entités en interaction à travers un canal de communication.

Grille

Les origines des grilles sont assez floues, aux alentours des années 70. Certains disent [10] que le précurseur des grilles est la société Apple, plus précisément l’entreprise NeXT avant qu’elle ne se fasse racheter par Apple, s’appuyant sur une idée de Xerox. Le docteur Richard Crandall (NeXT) serait le premier à avoir expérimenté les grilles, grâce à son programme de calcul parallèle distribué baptisé Zilla, le programme utilisait des machines chaînées entre elles pour des traitements mathématiques complexes. D’autres (Abbas, 2004) disent que l’idée serait venue de trois personnes, du docteur en Mathématiques et en Informatique Ian Foster (Directeur du laboratoire National Argonne à Chicago aux États-Unis), de Monsieur Carl Kesselman chercheur en informatique à « University of Southern California » et du Steve Tuecke ingénieur en informatique au Laboratoire National Argonne. Ces trois chercheurs sont surnommés « fathers of the Grid » (les fondateurs de grille) et sont à l’origine de l’une des plus importantes organisations de grilles « The Globus Alliance » (Foster & Kesselman, 1997).

Une grille fonctionne comme un réseau de distribution électrique ; celui-ci fournit à chaque utilisateur toutes les ressources dont il a besoin au moyen d’une interface simplifiée, une prise de courant. Toute la complexité du réseau sous-jacent (de la centrale électrique en particulier) est complètement cachée. De plus, l’utilisateur peut faire varier brutalement sa consommation sans démarche préalable. Dans une grille, puissance de calcul et capacités de stockage sont pratiquement illimitées puisque toutes les ressources de la grille peuvent être mobilisées en cas de besoin. Elle permet de mettre sans effort en production intensive une application développée localement et de mieux partager les ressources disponibles (dans les centres de calcul et dans les laboratoires ou bien dans les différents sites d’une entreprise). La première définition la plus citée d’une grille reflétant ses origines et a été suggérée par Foster et Kesselman (Czajkowski et al., 1998) : «Une grille de calcul est une infrastructure matérielle et logicielle qui fournit un accès fiable, constant, omniprésent et peu coûteux pour des capacités de calcul haute performance. »

Le partage de ressources a été étendu par la suite à d’autres domaines. Une grille est maintenant considérée par la communauté des chercheurs comme une couche intergicielle permettant le partage fiable, sûr et efficace de ressources et de données entre des entités organisationnelles indépendantes (Schikuta et al., 2009). Les grilles furent aussi adoptées par l’industrie avec différentes interprétations. IBM par exemple décrit les grilles indirectement en se référant à ses caractéristiques: « Une grille informatique permet de rassembler un ensemble de serveurs, systèmes de stockage et réseaux dans un seul grand système fournissant ainsi la puissance de multiples systèmes de ressources à un seul utilisateur dans un but précis. Pour un utilisateur, un fichier de données ou une application, le système semble être un seul énorme système informatique virtuel ». (Kourpas, 2006) Inspiré par l’omniprésence, la facilité d’utilisation et la fiabilité du réseau électrique, les informaticiens dans les milieux des années 1990 ont commencé à explorer la conception et le développement d’une infrastructure analogue appelée Grille de puissance de calcul. Une grille de calcul permet d’accéder à la puissance de calcul et l’application à tout moment ou lieu, comme nécessaire sans la nécessité de posséder l’infrastructure nécessaire pour produire le service (Buyya, Abramson, & Venugopal, 2005).

Informatique Utilitaire

Avec la popularité et l’utilisation croissante des grilles de calcul, les grandes installations de grilles ont rencontré de nouveaux problèmes, telles que les demandes excessives de ressources. Initialement, la gestion des ressources n’assure pas un accès équitable aux ressources dans de nombreux systèmes. Les paramètres traditionnels (débit, temps d’attente, latence) n’ont pas permis de garantir les exigences les plus subtiles des utilisateurs. Il n’y avait pas de réelle flexibilité et souplesse pour les exigences des utilisateurs en matière de ressources, ni de dispositions pour accueillir les utilisateurs avec des travaux urgents. Dans les environnements informatiques utilitaires, les utilisateurs attribuent une valeur « d’utilité » à leurs jobs, où l’utilité est une évaluation fixe, variable dans le temps définissant différentes contraintes de qualité de service-QoS2 (délai, priorité, satisfaction). L’évaluation est le montant qu’ils sont prêts à payer à un fournisseur de services pour satisfaire leurs demandes. Les fournisseurs de services tentent de maximiser leur utilité qui est alors en corrélation avec leur profit. Ils peuvent choisir de donner une plus grande priorité (le bénéfice se fait par unité de ressources) aux jobs des utilisateurs, conduisant à un scénario où les systèmes partagés sont considérés comme un marché, où les utilisateurs se disputent des ressources basées sur l’utilité ou la valeur de leurs jobs. (Bhatti, 2005)

Confiance Dans le cadre du paradigme du Cloud Computing, une organisation renonce à un contrôle direct sur de nombreux aspects de la sécurité et, ce faisant, confère un niveau sans précédent de confiance au fournisseur de services. Divers défis se rapportant à la confiance peuvent être considérés :

•Services de composites. Les services Cloud peuvent être composés par d’autres services. Les fournisseurs de services qui sous-traitent certains services à partir d’un tiers fournisseur peuvent rencontrer certaines difficultés comme la portée du contrôle sur la tierce partie, les responsabilités en cause et les remèdes et recours disponibles en cas de problème. La confiance est souvent non transitive, exigeant que les arrangements d’un tiers soient divulgués avant de parvenir à un accord avec le prestataire de services et que les modalités de ces ententes soient maintenues tout au long de l’accord.

•Visibilité. L’utilisation de services Cloud laisse le contrôle au fournisseur pour sécuriser les systèmes sur lesquels les données et les applications fonctionnent. Pour éviter de créer des lacunes dans la sécurité, des contrôles de gestion, de procédures et de techniques doivent être appliqués proportionnellement à celles qui sont utilisés pour les systèmes internes de l’organisation. C’est une tâche colossale, puisque les mesures pour comparer la sécurité de deux systèmes informatiques demeurent un domaine de recherche continuel. En outre, le suivi du réseau et du système par l’utilisateur est généralement en dehors du champ d’application de la plupart des services, ce qui limite la visibilité et les moyens de vérification des opérations directement.

•Gestion des risques. Avec les services Cloud, certains sous-systèmes ou composants de sous-système sont en dehors du contrôle direct de l’organisation qui détient l’information et autorise l’utilisation du système. Certains se sentent plus à l’aise quand ils ont plus de contrôle sur les processus et les équipements concernés. Au minimum, un degré élevé de contrôle offre la possibilité de considérer d’autres solutions, établir des priorités et agir de façon décisive dans l’intérêt de l’organisation lorsqu’ils sont confrontés à un incident. Lors du choix entre une solution en interne et une mise en oeuvre dans le Cloud, les risques associés doivent être évalués en détail. Évaluer et gérer les risques dans les systèmes qui utilisent les services de Cloud peut être un défi. Idéalement, le niveau de confiance est basé sur le taux de contrôle que l’organisation a sur le service externe, en matière d’utilisation de sécurité nécessaires à la protection du service et la preuve de l’efficacité des contrôles. Toutefois, la vérification du fonctionnement correct d’un sous-système et l’efficacité des contrôles de sécurité peut ne pas être réalisable, ainsi le niveau de confiance doit se baser sur d’autres facteurs.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Chapitre 1 : Introduction Générale
1.1. Introduction
1.1.1. Définition du problème
1.1.2. Objectifs
1.1.3. Méthodologie
1.2. Contributions
1.3. Organisation de la thèse
Chapitre 2 : Etat de l’art
2.1. Introduction
2.2. Cloud Computing
2.2.1. Infrastructures informatiques distribuées
2.2.2. Cloud Computing
2.2.3. Concept de base
2.2.4. Avantages et défis
2.2.5. Obstacles et possibilités pour le Cloud Computing
2.3. Sécurité pour le Cloud Computing
2.3.1. Défis de sécurité
2.3.2. Mesures de sécurité dans le Cloud Computing:
2.4. Confiance
2.4.1. Définitions
2.4.2. Aspects de base
2.4.3. Représentation de la confiance
2.4.4. Systèmes de confiance
2.4.5. Modèles computationnels de confiance
2.5. Confiance pour le Cloud Computing
2.6. Conclusion
Chapitre 3 : Système proposé
3.1. Principe de base
3.1.1. Approche
3.1.2. Hypothèses
3.1.3. Exigences
3.1.4. Investigation de travaux existants
3.2. Conception
3.2.1. Considérations de conception
3.2.2. Architecture
3.2.3. Composants du système
3.3. Modèle de calcul
3.3.1. Sources des évidences pour le calcul de confiance
3.3.2. Modélisation de la confiance
3.3.3. Calcul de la confiance
3.3.4. Modèle de sélection
3.4. Modèle de menaces
3.4.1. Menaces pour un système du Cloud Computing
3.4.2. Vulnérabilités et risques
3.4.3. Travaux existants
3.4.4. Modèle proposé
3.5. Conclusion
Chapitre 4 : Implémentation et Simulation
4.1. Implémentation
4.1.1. Environnement de travail
4.1.2. Implémentation du système
4.2. Simulation et analyses
4.2.1. Evaluation et analyse du modèle de calcul
4.2.2. Evaluation et analyse du Modèle de filtrage
4.2.3. Evaluation et analyse de la Plateforme de gestion de confiance
4.3. Conclusion
Chapitre 5 : Conclusion et Perspectives
5.1. Apports de notre travail
5.2. Limites et perspectives