SECURITE DANS LES GRILLES DE CALCUL

Transcription

1 DEA Informatique Réseaux et Systèmes Mémoire de DEA Informatique SECURITE DANS LES GRILLES DE CALCUL LABORATOIRE IRISA- UNIVERSITE DE RENNES 1 PROJET PARIS Campus Universitaire de Beaulieu RENNES Cedex France Réalisé par Jamal Eddine GHAFFOUR ghaffouj@ifsic.univ-rennes1.fr Dirigé par Mme. Christine MORIN et M. Louis Rilling {christine.morin,louis.rilling}@irisa.fr Université Rennes 1 Juin 2004

2 Table des Matières Table des Matières... 2 Introduction Accès sécurisé aux ressources d une grille Introduction aux grilles de calcul Architecture générale d une grille de calcul Différentes topologies de grilles Besoins de sécurité dans un environnement de grille Intergiciels pour grilles de calcul Globus Legion Discussion Conclusion Protocole de sécurité pour une grille Objectif du stage Contexte du protocole Modèle Cryptographie dans les systèmes distribués La cryptographie à clé publique Cryptographie à seuil Rafraîchissement proactif Adaptation Description des requêtes Description du fonctionnement du protocole Asynchronisme Discussion Vérification des protocoles de Sécurité Introduction Propriétés de sécurité Modèle de vérification Logique Modale BAN Model checking Vérification du protocole Authentification Secret Disponibilité Conclusion Référence Annexe

3 Introduction Le concept de «grille de calcul» (Grid [1]) est apparu suite à la demande des scientifiques de disposer d une très grande puissance de calcul et d une capacité de stockage de l ordre du péta octet. Le travail collaboratif des scientifiques nécessite en permanence l accès et l échange d importantes bases de données à travers l Internet afin de corréler entre elles leurs informations, établir des statistiques, analyser les résultats De même, les scientifiques ont besoin d effectuer des calculs importants pour modéliser une situation ou un appareil, exécuter un programme de CAO Ces traitements exigent la plupart du temps des moyens de calculs et de stockage considérables. De plus, ils correspondent à une utilisation intensive des ressources de calcul mais seulement pendant un laps de temps réduit. L investissement nécessaire ne peut être pris en charge par des entités isolées, mais exige la mise en place de collaborations plus larges, au niveau international. Les centres de calcul en tant que tels ne suffiront plus d'ici quelques années. Le concept de grille de calcul sera sans doute une réponse à cette demande. Les grilles sont définies comme un ensemble d institutions/individus qui décident de partager des ressources et des services sous certaines contraintes et politiques. Ce partage peut être un simple accès aux fichiers, une demande de calcul, une allocation de mémoire ou toute autre opération qui paraît parfois nécessaire pour résoudre quelques problèmes de recherche ou d industrie qui demandent des ressources importantes. Les ressources partagées entre les institutions/individus qui font partie de la grille sont physiquement distribuées et parfois individuellement administrées. Afin d assurer un accès sécurisé aux ressources exposées, de nouveaux protocoles et outils doivent être définis pour supporter l environnement particulier de la grille et assurer les services de sécurité : la disponibilité, confidentialité, intégrité, authentification, et la non répudiation. L objectif de stage est la définition d un protocole de sécurité qui permet un accès sécurisé aux ressources partagées d une grille. Ce protocole doit garantir les services de sécurité, prendre en compte les propriétés associées à l environnement des grilles, et considérer les nouveaux défis liés à cet environnement : ressources reliées à travers des réseaux publics non protégés «Internet», politique et mécanismes de sécurité différents pour chaque institution/individu, dynamicité, et passage à l échelle. Dans ce rapport, nous présentons une description d un protocole de sécurité que nous avons défini pour un environnement de grille. Nous décrivons également sa validité en utilisant les méthodes et les outils de vérification pour les protocoles de sécurité. Dans une première partie, nous présentons les grilles, nous décrivons les besoins de sécurité associés à l environnement des grilles et les solutions adoptées par quelques intergiciels de grilles en terme de sécurité. Dans la deuxième partie nous décrivons le protocole de sécurité que nous avons défini durant ce stage, nous commençons par une description des hypothèses relatives à l environnement d exécution du protocole, puis nous présentons le protocole proposé. La troisième partie est consacrée à la vérification et à la validation de ce protocole. Nous exposons dans la quatrième partie les conclusions de notre travail. 3

4 1 Accès sécurisé aux ressources d une grille Cette partie représente un état de l art des systèmes de sécurité employés dans les grilles. Nous commençons par définir les propriétés d une grille : nous décrivons l architecture générale de la grille, ainsi que ses différentes topologies. Ensuite, nous entamons la définition des propriétés de sécurité qu il faut satisfaire dans un environnement de la grille. Nous décrivant par la suite quelques intergiciels de grille (Globus et Legion), et nous terminons par une discussion sur les différents systèmes utilisés dans la grille pour assurer la sécurité. 1.1 Introduction aux grilles de calcul Le terme «The Grid» ou «grille de calcul», a été introduit pour la première fois aux Etats- Unis dans les années 1990 pour décrire une infrastructure de calcul répartie utilisée dans des projets de recherche scientifique et industrielle. Dans un des premiers documents qui définissent des concepts de grille de calcul [1], les scientifiques tentent de fournir une définition détaillée des objectifs, de la forme et de l architecture des grilles de calcul. La notion de grille de calcul est fondée dur le concept de la grille d électricité (power grid). Par analogie à cette grille d électricité, la notion de grille de calcul (computational grid) est définie comme étant une infrastructure matérielle et logicielle qui fournit des service pour partager des ressources pour résoudre qui demandent des ressources importantes. 1.2 Architecture générale d une grille de calcul Nous présentons dans ce paragraphe un ensemble de principes et de critères de conception généraux utilisés dans la définition des architectures de grilles. Les grilles de calcul possèdent quatre principales caractéristiques [6]: Existence de plusieurs domaines administratifs : les ressources sont géographiquement distribuées et appartiennent à différentes organisations chacune ayant ses propres politiques de gestion et de sécurité. Ainsi il est indispensable de respecter les politiques de chacune de ces organisations. Hétérogénéité des ressources : les ressources dans une grille sont de nature hétérogène en terme de matériels et de logiciels. Passage à l échelle (scalability) : une grille pourra être constituée de quelques dizaines de ressources à des millions voire des dizaines de millions. Cela pose de nouvelles contraintes sur les applications et les algorithmes de gestion des ressources. Nature dynamique des ressources : les grilles sont caractérisées par leur aspect dynamique (Arrivée de nouveaux membre, départ des membres existants, ). Cela pose des contraintes sur les applications telles que l adaptation au changement dynamique du nombre de ressources, la tolérance aux pannes et aux délais 4

5 Plusieurs étapes constituent le processus de construction d une grille [6]: intégration des différents composants matériels et logiciels en une ressource globale à travers le réseau. l implémentation d intergiciels offrant une vue transparente et consistante à cette ressource. le développement d outils permettant le contrôle et la gestion de l infrastructure et des applications. le développement d applications exploitant cette infrastructure. Dans [3], une architecture générale des grilles de calcul est proposée. Bien que chaque projet ait sa propre architecture, une architecture générale est importante pour expliquer certains concepts fondamentaux des grilles. La figure ci-dessous illustre une telle architecture : Applications Recherche scientifique, ingénierie, finances, portail Environnements et outils de programmation Langages, interfaces, librairies, compilateurs Intergiciels Soumission et ordonnancement de tâches, découverte de services Sécurité Authentification, autorisation, confidentialité Infrastructure matérielle PC, Station de travail, équipement réseau, Figure 1 : Architecture générale d une grille de calcul 1.3 Différentes topologies de grilles [4] énumère les grilles d un point de vue topologique en trois types par ordre croissant d étendue géographique et de complexité: intragrilles (intragrids), extragrilles (extragrids) et intergrilles (intergrids). Intragrille (en analogie avec Intranet) : la plus simple des grilles est l intragrille, composée d un ensemble relativement limitée de ressources et de services et appartenant à une organisation unique. Les principales caractéristiques d une telle grille sont l interconnexion à travers un réseau performant et haut débit, un domaine 5

6 de sécurité unique et maîtrisé par les administrateurs de l organisation et un ensemble relativement statique et homogène de ressources. Extragrille (en analogie avec Extranet) : une extragrille étend le modèle en regroupant plusieurs intragrilles. Les principales caractéristiques d une telle grille sont la présence d un réseau d interconnexion hétérogène haut et bas débit (LAN/WAN), de plusieurs domaines de sécurité distincts, et d un ensemble plus ou moins dynamique de ressources. Un exemple d utilisation est lors d alliances et d échanges «Business -to- Business» (B2B) entre entreprises partenaires. Intergrille (en analogie avec Internet) : une intergrille consiste à agréger les grilles de multiples organisations, en une seule grille. Les principales caractéristiques d une telle grille sont la présence d un réseau d interconnexion très hétérogène haut et bas débit (LAN / WAN), de plusieurs domaines de sécurité distincts et ayant parfois des politiques de sécurité différentes et même contradictoires, et d un ensemble très dynamique de ressources. 1.4 Besoins de sécurité dans un environnement de grille Cette partie est consacrée à la description des besoins de sécurité dans un environnement de grilles. Echange des politiques de sécurité Dans un environnement de grille, les politiques de sécurité déployées dans chaque institution/individu sont différentes. L aspect dynamique de la grille exige que ces politiques doivent être découvertes dynamiquement. En effet, dans le cas où deux institutions/individus veulent communiquer entre eux, ils commencent par découvrir les politiques et les mécanismes adoptés par chacun d entre eux, suivi par un processus de négociation afin de définir les politiques et les mécanismes optimaux qu ils utiliseront pour une communication sécurisée. Ainsi, un modèle de sécurité dans l environnement des grilles doit intégrer les services suivant : la description, la découverte et la négociation des politiques et des mécanismes de sécurité. Authentification Ambiguïté Un des gains offerts par le déploiement des grilles, qu il n y a pas de limitation géographique sur la localisation de ses membres. Ceci entraîne l utilisation de plusieurs systèmes non compatibles, qui doivent assurer une communication authentifiée entre les participants des 6

7 différentes institutions/individus. Pour pouvoir développer plus facilement et plus rapidement des systèmes d intercommunication qui rendent transparents les différents mécanismes et politiques de sécurité utilisés localement, les opérations requises pour chaque système pour un niveau de sécurité donné, doivent être claires et non ambiguë. Authentification mutuelle Tout modèle de sécurité fiable doit aussi garantir le bon fonctionnement du concept d authentification mutuelle afin d établir une confiance entre les parties communicantes. La notion de confiance s établit après la phase d authentification, et toute entité autorisée aura confiance pour accéder aux services disponibles en fonction de ses droits d accès. Cette confiance mutuelle permet au service de s assurer que les instituts/individus qui utilisent les ressources sont les vrais instituts/individus et non pas des imposteurs. Elle permet également aux utilisateurs de s assurer qu ils utilisent les ressources des institutions/individus, auxquels ils font confiance avant de commencer toute communication. Cette authentification mutuelle est mise en œuvre souvent en utilisant les autorités de certification (CA), qui représente un tiers de confiance en attribuant des certificats pour chaque institution/individu. Une authentification unique Afin d assurer un calcul parallèle et un équilibrage de charge dans une grille, l exécution d une tâche en utilisant les ressources de la grille peut s étendre sur plusieurs institutions/individus. L authentification unique vient en aide pour une institution/individu pour ne pas s authentifier à chaque fois la tâche s étends sur un nouveau domaine. En effet, une fois l institution/individu s authentifie avec succès auprès d une entité d authentification de la grille (obtention d un ticket d accès), elle n a pas à se re-authentifier à chaque fois que la tâche s étends sur un autre domaine de la grille. Délégation Les services permanents doivent être capables d effectuer des actions à la faveur de l utilisateur sans son intervention. S il n y a pas de relation de confiance entre le domaine source de la requête et le domaine traversé par cette requête, l application utilisateur délègue à une entité son autorité afin de réaliser les actions nécessaires dans ce domaine. La délégation d une autorité d une entité à une autre doit être mise en œuvre avec précaution, c est à dire que l entité déléguée ne peut pas effectuer plus que les tâches que celles que la délégation lui a confié. La délégation doit être valable pour une durée de vie limitée afin de réduire la possibilité d une mauvaise utilisation de cette autorité. Dans plusieurs scénarios, une tâche initiée par l utilisateur prend plus de temps que celui spécifié dans la durée de vie des credentials (Un credential est une liste de droits accordés à un utilisateur) délégués. Dans ce cas, l utilisateur doit être informé avant l expiration des credentials pour pouvoir les rafraîchir afin que la tâche puisse s achever. 7

8 Identification Un environnement de grille est constitué de plusieurs domaines qui maintiennent entre eux des relations de confiance. Toute opération entre les institutions/individus des différents domaines nécessite une authentification mutuelle. Après une authentification réussie d une entité d un domaine sur un autre domaine, ce dernier essaye d identifier l entité communicante à partir de son registre d utilisateurs pour définir ses droits d accès. Pour ce faire il faut partager un registre global des utilisateurs, ce qui parait irréaliste à cause de l aspect dynamique de la grille. En outre, les credentials sont exprimés différemment dans chaque domaine et donc sont syntaxiquement et sémantiquement incompatibles. Une solution est d implémenter des services de mappage/traduction dans les entités intermédiaires (proxies, passerelle, etc.) dans chaque domaine. Le rôle de ce service est de transformer l identité d une entité qui fait partie des identités d un domaine en une identité dans un autre domaine. Confidentialité La confidentialité est assurée en ne permettant qu aux entités ayant le droit d accéder aux données/programmes d y accéder. Ceci peut être garanti, premièrement en imposant des infrastructures physiques pour le réseau de la grille (VPN), deuxièmement en utilisant des algorithmes de chiffrement (RSA [18], El-Gamal [19]). Intégrité des données Chaque membre de la grille doit posséder des méthodes et des outils pour s assurer que les données reçues ne sont pas affectés par des modifications non autorisées. En fonction de la politique de sécurité adoptée et les relations de confiance établie entre les membres de la grille, ce service peut est implémenté ou non. Par exemple, une grille qui maintient une relation de confiance entre tous ses domaines peut ne pas exiger ce service à chaque passage par un domaine intermédiaire lors d une communication point à point. Administration Un modèle de sécurité doit offrir des fonctions d administration qui incluent plusieurs aspects: administration des clés, administration des répertoires d utilisateurs, administration des politiques de confiances, administration des politiques de mappage et traduction. Selon la politique choisie dans la grille, cette dernière peut être administrée d une manière centralisée ou décentralisée. L utilisation d un système centralisé restreint l aspect dynamique et flexible de la grille et nécessite une connaissance des mécanismes et des politiques déployées dans chaque institution/individu. Ainsi le choix d une administration décentralisée est plus souhaitable, car elle offre aux administrateurs de chaque institution/individu la liberté de gérer leurs ressources locales. Les fonctions d administration doivent également offrir les outils qui assument un niveau élevé de sécurité, comme les anti-virus et les détecteurs d intrusion. 8

9 Dans la littérature des systèmes de sécurité, on ne décrit pas comment ces derniers sont administrés. 1.5 Intergiciels pour grilles de calcul Dans cette partie, nous donnons une vue d ensemble sur les principaux intergiciels pour grilles de calcul. Nous exposons essentiellement les intergiciels Globus et Legion. Nous avons choisi ces intergiciels en raison de leur importance et leur maturité aux niveaux académique et industriel et à cause de l intérêt grandissant envers eux dans les projets de grande ampleur Globus La boîte à outils Globus est formée d un ensemble de composants [9]. Globus est devenu le grand standard utilisé dans les projets de grilles de calcul. Plusieurs nombreuses entreprises ont adopté Globus pour servir de base à leurs produits commerciaux pour grilles de calcul. Par la suite, nous présentons les principales fonctionnalités offertes par Globus à ses utilisateurs, particulièrement en terme de sécurité Introduction Globus fournit les fonctionnalités et les services de base nécessaires pour la construction de grilles de calcul. Ainsi, nous trouvons des services et des mécanismes tels que la sécurité, la localisation et la gestion des ressources, la communication Globus est composé d un ensemble de modules ayant chacun une interface que les services de niveau supérieur peuvent utiliser pour invoquer ses mécanismes. La table1 expose ces différents services [7]. Service Nom Description Gestion de ressources GRAM Allocation des ressources et gestion des processus Communication Nexus Service de communication unicast et multicast Sécurité GSI Authentification et autorisation Information MDS Information sur la structure et l état de la grille Table 1 : Principaux services offerts par Globus. Par la suite, nous détaillons les mécanismes de gestion de la sécurité dans Globus Gestion de la sécurité Globus fournit une architecture de sécurité complexe permettant de sécuriser le fonctionnement de la grille. Les composants de sécurité fournissent les mécanismes qui assurent l authentification, l autorisation et la confidentialité des échanges. Cette architecture de sécurité est appelée «Grid Security Infrastructure» ou GSI [17]. Globus repose sur la cryptographie à clé publique. Ainsi pour pouvoir utiliser les mécanismes de sécurité de GSI, il faut créer une paire de clés (publique/privée) et demander la délivrance 9

10 d un certificat numérique d une autorité de certification (CA) et cela pour chaque noeud de la grille. A la fin de cette procédure, nous avons sur chaque machine trois informations importantes contenant respectivement : la clé publique du CA, la clé privée du nœud et le certificat numérique du nœud (au format X.509). Il est important de noter que le fichier contenant la clé privée du nœud devra être particulièrement sécurisé pour ne pas y permettre un accès illégal par des utilisateurs non autorisés. Pour cela les mécanismes du système d exploitation sous-jacent devront être utilisés (droits d accès, chiffrement, détection d intrusion et d intégrité). Authentification et autorisation Dans un scénario de communication entre deux nœuds de la grille, il faut qu ils aient confiance l un en l autre, on parle d une authentification mutuelle. Pour cela GSI offre un mécanisme d authentification mutuelle et d autorisation qui utilise SSL/TLS [20]. Globus assure cette procédure pour chaque requête d exécution de tâche. La procédure est la suivante comme présentée dans la figure2 [4] : 1. Le nœud A envoie son certificat au nœud B. 2. B s assure que le certificat est valide et extrait l identité et la clé publique de A du certificat. 3. B génère un nombre aléatoire et l envoie à A. 4. Lors de la réception de ce nombre, A le chiffre avec sa clé privée (c est ici que A pourra demander à l utilisateur d entrer le mot de passe) et l envoie à B. 5. Lors de la réception du nombre chiffré, B le déchiffre avec la clé publique de A et s assure qu il est le même. A est alors authentifié par B. 6. La procédure est répétée dans le sens inverse pour que A authentifie B. 7. B transpose le nom de l utilisateur se trouvant dans le certificat en un nom d utilisateur local au nœud. Pour cela un fichier appelé grid-map est utilisé. 10

11 4 Mot de passe Noeud A Ton certificat 1 envoyer 3 Ton certificat créer & envoyer Nœud B 2 Donnes ta clé publique & sujet Ta clé privée aléatoire aléatoire Clé publique de CA 4 Chiffrer & envoyer 5 aléatoire décrypter Ta Clé privée 5 Identifier Sujet 6 mappage Nom utilisateur <Sujet> <nom utilisateur> Fichier de mappage Figure 2 : Authentification et autorisation Délégation et authentification unique Imaginons la situation où un utilisateur doit lancer des milliers de tâches et que ses tâches doivent lancer à leurs tours de nouvelles tâches. Il devient impossible de demander à l utilisateur de fournir son mot de passe. Heureusement GSI offre un mécanisme de délégation permettant de diminuer le nombre de fois qu un utilisateur doit fournir son mot de passe. Ce mécanisme de délégation est une extension des mécanismes de SSL. La création d un proxy est la solution. Ainsi si un utilisateur utilise un nœud A authentifié par un nœud B, il pourra créer un proxy sur B lui délégant ainsi son autorité. B sera en mesure de créer des tâches sur un nœud C comme si l utilisateur sur A les avait créées. Un proxy consiste en un nouveau certificat numérique avec une nouvelle paire de clés publique/privée. Il contient l identité de l utilisateur légèrement modifiée pour indiquer que c est un proxy. Ce nouveau certificat est signé par l utilisateur lui-même et non pas par l AC. De plus un proxy a une durée de vie limitée. Il est alors utilisé pour assurer la procédure d authentification mutuelle et d autorisation sans avoir à impliquer l utilisateur. 11

12 La figure suivante détaille les étapes de création et d utilisation d un proxy [4] : Utilisateur Création d un proxy utilisateur C U Host computer Proxy utilisateur C UP Allocation d une resource distante C P C U C U P C R Long-lived credential Temporary credential Delegated credential User s credential Proxy credential Resource proxy credential Site 1 Resource credentials Global-to-local mapping table Site 2 Global-to-local mapping table Resource credentials C R Local policy and mechanisms Processus C P Allocation de ressources Processus C P C R Local policy and mechanisms Figure 3 : Délégation, création et utilisation d un proxy (source [8]). Il faut noter que ce processus d authentification et d autorisation du proxy nécessite l établissement d une chaîne de confiance de l autorité de certification jusqu au proxy en passant par l utilisateur. Communication chiffrée Bien que GSI requière le déroulement des processus d authentification et d autorisation, la procédure de chiffrement des communications entre nœuds n est pas utilisée par défaut et cela afin d éviter la surcharge des échanges par le chiffrement et le déchiffrement. Mais puisque GSI utilise SSL comme système sous-jacent, la procédure de création d une clé secrète commune entre deux nœuds est possible (clé de session). Cette clé sera alors utilisée par un algorithme tel que DES [22] pour chiffrer les échanges. D un autre côté GSI assure par défaut l intégrité des données. Pour plus de détails sur GSI le lecteur pourra se référer à ww.globus.org/security. 12

13 1.5.2 Legion Les concepteurs de Legion l avaient défini comme un système fournissant à ses utilisateurs une interface uniforme à une importante capacité de calcul, facilitant la collaboration entre eux et cachant la complexité due au fait que le système est constitué de milliers voire de millions de ressources distribuées à travers le monde. En effet, l utilisateur aura l illusion d utiliser un ordinateur unique mais très puissant. Dans la suite nous présentons les principes de base de Legion ainsi que les fonctionnalités offertes par la plateforme essentiellement en terme de sécurité Introduction L architecture de Legion est une architecture en couches [10], avec au plus bas niveau l infrastructure matérielle et logicielle. La couche en dessus est constituée des objets de base («Core Legion Objects») [11]. Cet ensemble d objets implémente les fonctionnalités fondamentales (gestion des ressources, migration, sécurité ) requises pour le bon fonctionnement du système. La couche suivante est composée de l ensemble des objets offrant des fonctionnalités de haut niveau tels que les services d ordonnancement, de système de fichiers et d information. Les deux dernières couches offrent des librairies d interface aux services sous-jacents et les applications des utilisateurs. La figure suivante illustre l architecture de Legion : Application Librairie Legion (méthode d invocation de service) Systéme de fichier Legion Service de gestion de ressources Objet Legion de gestion de services (Core Objects) Infrastructure Figure 4 : Architecture de Legion (source Services de sécurité Dans ce paragraphe, nous citons trois mécanismes de sécurité offerts par Legion permettant d assurer un niveau de sécurité dans le système. Ces trois mécanismes traitent de l authentification, de l autorisation et de la confidentialité des échanges. 13

14 Identification et authentification Les identités dans Legion sont fondées sur les identificateurs d objets ou LOID. Même les utilisateurs de Legion possèdent leur propre LOID. La partie concernant la sécurité dans un LOID contient un certificat X.509 contenant lui-même une clé publique RSA. L inclusion d une clé publique dans un LOID rend facile le chiffrement des messages destinés à un objet et la vérification des données signées par lui. Ce certificat est propagé avec les appels de méthodes entre objets. L authentification de l identité d un objet ou d un utilisateur se fait alors en se basant sur ces certificats X.509 et en utilisant le mécanisme de chaîne de confiance. Autorisation Dans un environnement de grille de calcul, il est fréquent que les tâches (des objets dans le cas de Legion) accèdent à des ressources de la part de l utilisateur. Puisqu il est interdit de fournir la clé privée d un utilisateur aux objets qui le représentent, il faut utiliser un autre mécanisme. Revenir à chaque appel à l utilisateur pour fournir sa clé privée est un mécanisme fastidieux, complexe et non performant. Pour éviter cela, un mécanisme de délégation est utilisé dans Legion avec l utilisation des «credentials». Quand un objet demande l accès à une ressource, il présente le credential qu il possède. Cette ressource pourra alors décider de lui accorder l accès ou pas. Dans Legion deux types de credentials existent [12]: Delegated credential : qui spécifie explicitement le bénéficiaire. Bearer credential : qui donne tous les bénéfices à son porteur. L accès est contrôlé du côté des ressources par des listes d accès «Access Control List». Chaque ressource contient une liste d objets (représentés par leur LOID) qui peuvent y accéder. Plus particulièrement chaque méthode d un objet est munie de deux listes, une appelée allow et l autre appelée deny. Lors de l appel de cette méthode par un objet la liste deny est consultée pour s assurer que l identité (LOID) de l objet n existe pas. Dans le cas contraire, la liste allow est consultée pour s assurer que l identité de l objet existe. C est suite à cette double procédure que l objet se voit accorder l accès à la méthode. Confidentialité et intégrité des communications Un appel de méthode dans Legion consiste en un ensemble de messages. Legion assure la confidentialité et l intégrité de ces messages. Il existe trois modes de sécurité dans Legion [12]: Pas de chiffrement Mode privé : dans ce mode tout le message est chiffré. RSA est utilisé pour échanger une clé DES (clé de session) qui sert pour le chiffrement. Mode protégé : dans ce mode la partie du message contenant des informations critiques (tel qu un credential) est chiffrée. L autre partie est protégée en conservant son intégrité (utilisation d une fonction de hachage). Le but de chiffrer un crendential est d empêcher son vol. 14

15 Enfin, notons que Legion fournit un mécanisme d estampillage, permettant d éviter toute attaque par répétition. 1.6 Discussion Cette partie sera consacrée à la description d autres modèles existants et les mécanismes qui ils déploient pour adresser les besoins de sécurité. Plus que Legion et Globus, les modèles décrits incluent les projets qui adressent les infrastructures pour le calcul distribué CRISIS [13], SHARP [14]; ainsi que ceux qui définissent des systèmes de fichiers distribués SFS [15], FARSITE [16]. Authentification, confidentialité et intégrité La majorité des infrastructures (GLOBUS, CRISIS, SHARP) de sécurité introduisent le protocole SSL (Secure Socket Layer) dans leurs infrastructures pour permettre l authentification. GSI utilise OpenSSL ou SSLeay qui sont des implémentations libre du protocole SSLv3. Ce dernier garantie aussi la confidentialité et l intégrité des données et supporte les proxies de certificats pour la communication avec les CAs. Ceci explique le grand déploiement de ce protocole dans les architectures de sécurité distribuée (CRISIS, LEGION, SFS, FARSITE). Dans une première implémentation, GLOBUS oblige son infrastructure à supporter une seule autorité de certification CA qui associe les Credentials aux utilisateurs. Mais en pratique, les utilisateurs doivent être capable de se présenter avec des Credentials obtenus de n importe quel CA : Le CA du domaine local, un CA commercial, etc. la nouvelle implémentation de GSI supporte les multiples CAs ; et donc les domaines doivent être capable de traiter les Credentials attribués par différents CAs, et en même temps introduire dans leurs politiques locales l information des CAs auxquels ils font confiance, et à qui ces CAs doivent faire confiance. par exemple, un domaine qui offre des outils pour l éducation peut faire confiance par exemple dans un CA d une école, et ne fait pas confiance à des certificats attribués à des utilisateurs qui sont pas étudiants par exemple. Alors les utilisateurs doivent présenter tous leurs Credentials et le domaine décide lequel il va utiliser en fonction de ses politiques de contrôle. CRISIS introduit dans son approche deux types de certificat : les certificats d identité et les certificats de transfert. Le certificat d identité associe une clé publique à un principal (utilisateur, machine), et qui est valide pour une période de temps. Le certificat de transfert sert à transférer une partie de privilège d un principal à un autre principal. Dans l approche de CRISIS ; le CA signe les certificats d identité qui seront valable pour une longue durée (souvent de l ordre de semaines) et identifie un principal local OLA (on-line agent)qui sera chargé de re-signer ce certificat avec un temps relativement court (à l ordre des heures). Le support de cette approche offre plusieurs avantages. Premièrement, pour réussir à voler les clés, le CA et l OLA doivent être «subverted : détournés». En outre l existence du OLA permet au CA d être non fonctionnel pour des durées importantes liées à la validité de ses certificats, par conséquent attaquer le CA devient une tache très difficile. Un autre avantage 15

16 de cette approche que le système de certification reste opérationnel même dans l existence des CAs ou des OLAs qui sont malicieux. Une autre approche qui définit un système de fichier distribué est SFS, ce dernier assume qu il y a dans chaque domaine un serveur de fichier et un serveur d authentification. Pour accéder à un fichier, l utilisateur envoie une requête au serveur de fichier, ce dernier transmet cette demande (opaque pour lui) au serveur d authentification local qui vérifie la signature de l utilisateur et extrait ses Credentials, qui sont envoyé au retour au serveur de fichier qui décident en fonction de ses ACLs si l utilisateur a le droit d accès au fichier. Le serveur d authentification local maintient la liste des utilisateurs et des groupes qui sont définis localement, et maintient dans des caches la liste de tous les utilisateurs et des groupes qui peuvent utiliser ce système de fichiers distribué. Chaque serveur d authentification locale met à jour périodiquement (chaque heure) son cache en demandant les bases des utilisateurs aux serveurs d authentification des autres domaines en utilisant une communication sécurisée SSL par exemple. Cette approche permet la disponibilité du système dans le cas où un serveur d authentification d un domaine n est pas disponible, mais augmente considérément la taille des caches dans le cas d un système qui contient un grand nombre d utilisateur. Etablissement d une relation de confiance entre domaines L approche de Globus ne nécessitent pas une relation de confiance supplémentaire entre les différents domaines pour permettre la délégation, ceci est dû à l authentification effectuée pour chaque allocation de ressources entre le proxy utilisateur et le proxy ressource, ou entre le processus crée dynamiquement et le proxy de ressource. CRISIS nécessitent une relation de confiance entre les différents domaines de la grille, il suppose la présence de multiples domaines administrés d une façon autonome et dans chaque domaine il y a au moins une entité CA/OLA. Les différents domaines ont pas le même degré de confiance dans chaque CA, et donc les CAs sont arrangé dans une structure de graphe. Lorsque un principal reçoit un certificat d un CA situé dans un domaine quelconque, il vérifie la validité de ce dernier en cherchant dans le graphe un chemin de confiance à partir du domaine locale (domaine où se situe la principal) au domaine destination (domaine source du certificat). Dans la version actuelle de CRISIS le graphe est maintenu statiquement par l administrateur de chaque domaine, et dans les versions prochaines le support dynamique de ce graphe est prévu. Farsite utilise la même approche que celui de CRISIS pour assurer les relations de confiance entre les différents domaines. SFS nécessite également une relation de confiance entre les différents domaines pour permettre l échange des bases d utilisateurs et des groupes entre les serveurs d authentification locaux. SFS se contente de maintenir cette relation de confiance dans des fichiers de configurations définis localement par l administrateur du domaine. 16

17 Identification et Autorisation L infrastructure GSI définie initialement utilisait des simples ACLs (Access Control List) pour définir les droits d accès à un utilisateur identifié à partir de la phase d authentification. Dans la version courante de GSI, et avec le support de multiples autorité de certification CAs comme déjà expliqué dans la partie authentification, GSI introduit une fonction générale de contrôle d accès en utilisant l API GAAC (Generic Autorisation & Access Control). Dans un système distribué, il y a moins de confiance et plus de risques ; alors il est vitale que les principals transfèrent le moins possible de leurs privilèges aux autres principals. CRISIS introduit la notion de rôles qui associent une partie des privilèges d un utilisateur avec des nom (nom de domaine, de principal, de tache, etc.) permettant le choix des privilèges à transférer vers un processus. Le principal crée un nouveau rôle en générant un certificat d identité qui contient clé publique/clé privée, et un certificat de transfert qui définit la partie des privilèges associée à ce rôle. Pour autoriser des principals à effectuer des taches sur des domaines distants, CRISIS maintient des ACLs sur chaque nœud. Dans l approche de CRISIS, pour effectuer l autorisation les demandeurs sont responsables de prouver qu ils sont autorisés pour accéder à un objet. Le demandeur envoi au reference monitor une liste de certificats qui décrit ses Credentials, ce dernier vérifie si tous les certificats sont signé par une clé publique d un CA qu il lui fait confiance (recherche dans le graphe des CAs) et après il vérifie dans ses ACLs si le principal est autorisé pour un tel accès. Dans le Projet LEGION, chaque objet est identifié par un LOID unique (Legion Object Identifier). LOID consiste à un nombre variable de champs de données binaire ; un de ces champs contient un certificat X.509. L accès à un objet dans LEGION est défini comme la possibilité d appeler une méthode de cet objet. Le contrôle d accès n est pas centralisé ce qui permet à chaque objet de renforcer son politique de contrôle d accès. Le modèle général d accès dans LEGION se base sur l utilisation d une couche MayI qui définit si l objet appelant est autorisé pour un tel appel. Une fois l utilisateur obtient ses Credentials, les serveurs SFS décident les droits d accès en fonction de ces derniers. Dans un approche simple, SFS définit trois type de credentials : Unix Credentials qui sont basés sur le fichier /etc/passwd du système UNIX, public key credentials qui représentent une fonction de hachage appliquée à la clé publique de l utilisateur, et Group List Credentials qui définit les groupes auxquels l utilisateur appartient. Dans SFS l accès de contrôle est basé sur ces trois types de Credentials, le serveur vérifie l ACL associé au fichier ou au répertoire pour déterminer si la requête peut être honorée. 1.7 Conclusion Les modelés décrits dans cette partie, ont tous conservé une vision statique d un système distribué pour adresser les besoins de sécurité dans un environnement de grilles. En effet, ils se sont fondés sur des solutions de base pour la sécurité dans un système distribué (Kerberos [21], PKI) en introduisant des services qui remédient quelques problèmes associés à la grille : Service d authentification unique pour alléger l utilisation de la grille, délégation pour permettre l accès à des ressources de plusieurs domaines. Mais tous ces 17

18 modèles n ont pas abordé les problèmes liés à dynamicité de la grille et qui nécessite d introduire des services de flexibilité et d interopérabilité. Le projet Globus dans son infrastructure GSI reste le seul à aborder cet aspect en intégrant des solutions génériques et paramétrables. Le support de la dynamicité de la grille nécessite l introduction d autres systèmes de sécurité. En effet, les solutions décrites sont basées sur des modèles de confiances qui définissent les différentes relations de confiance entre les domaines de la grille. Cette solution montre ses limites rapidement dans environnement dynamique et de grande échelle. Nous décrivons dans la suite de ce rapport notre proposition pour un protocole de sécurité pour un environnement de la grille. 18

19 2 Protocole de sécurité pour une grille Dans cette partie, nous décrivons le protocole de sécurité que nous avons défini pour un accès sécurisé aux ressources d une grille. Nous commençons par définir les objectifs et les besoins d un tel protocole, ensuite nous proposons une description détaillé du fonctionnement de notre protocole, et nous terminons par une discussion sur les propriété garantit par le protocole ainsi que les façon de son utilisation dans le différentes architectures de la grille. 2.1 Objectif du stage L approche la plus simple est de mettre en œuvre une infrastructure centralisée qui introduit des serveurs dédiés pour assurer les propriétés de sécurité. La mise en œuvre d une telle infrastructure introduit un point de vulnérabilité dans le système, car si l entité centrale est corrompue tout le service est corrompu. Les services de sécurité proposés pour les grilles ont essayé de définir une architecture moins centralisée fondée sur les chaînes de confiance. Dans l exemple du projet Globus, son infrastructure GSI nécessite pour ses processus d authentification et d autorisation l établissement d une chaîne de confiance entre les autorités de certification des différentes institutions/individus de la grille. Dans un environnement de grille, chaque institution/individu membre de la grille est administré individuellement et met en œuvre ses propres mécanismes et politiques de sécurité. Par conséquent, il n y a aucune garantie sur les moyens de sécurité déployés dans cette institution. Les autorités de certification déployées dans les domaines de la grille dans le cas de GSI peuvent être facilement corrompues, et alors présenter un point de vulnérabilité pour le service. Les grilles sont caractérisées également par leur dynamicité, la maintenance de ces chaînes de confiance devient une tâche difficile dans un système à grande échelle. L objectif de base dans notre stage est définir un service de sécurité qui satisfait les propriétés suivantes : Décentralisé : les services d authentification et d autorisation doivent être garantis en absence d une entité centrale (autorité de certificat, serveur d authentification). On souhaite également que notre système soit similaire à un système pair à pair dans le sens où les services de sécurité sont réalisés par des membres des systèmes et non pas par des serveurs dédiés à réaliser les services (les membres de la grille sont à la fois des utilisateurs et des serveurs). Dynamique : l environnement de grille est caractérisé par sa dynamicité, le protocole doit alors s adapter pour supporter les changements de l architecture de la grille (départ d un nœud, arrivée d un nœud, nœud détecté corrompu ). Disponible : un protocole de sécurité doit assurer un service permanent en protégeant le service des attaques lancées par des adversaires. Un modèle 19

20 d adversaire analogue à un modèle de tolérance aux fautes est proposé pour caractériser la puissance d un adversaire. Deux modèles sont définis : - Adversaire passif : il est capable de lire les informations sur le système sans changer son comportement (voler l information enregistrée sur les serveurs, voir le contenu des messages échangés...). - Adversaire actif : en plus de la lecture des informations, il est capable de contrôler le comportement du système afin de le dévier de sa spécification (empêcher la terminaison d une opération cryptographique, altérer ou détruire les messages échangés..). On parle d un adversaire byzantin. Sécurisé : le protocole doit assurer les services de sécurité : authentification, intégrité, confidentialité, non répudiation. Authentification unique : à travers une seule authentification avec succès, un membre de la grille peut accéder aux différentes ressources/programmes exposés par la grille. Résistant au facteur d échelle : une grille consiste en un nombre d institutions/individus de l ordre de quelques centaines ou des milliers qui partagent l utilisation de leurs ressources. Un protocole de sécurité doit passer à l échelle en permettant ses services dans un réseau de grande taille. 2.2 Contexte du protocole L idée clé dans notre protocole est de permettre un fonctionnement analogue à un serveur d authentification et d autorisation qui attribue des tickets pour permettre les accès aux différentes ressources de la grille (tel que par exemple un serveur Kerberos). L architecture centralisée représente une grande vulnérabilité aux attaques des adversaires (attaques passives, attaques actives). Ainsi, notre protocole essaye de réduire cette vulnérabilité en faisant appel aux protocoles de réplication, tout en gardant une utilisation transparente d un seul serveur pour les utilisateurs du service. Par conséquent, pour accéder à une ressource de la grille, chaque membre de la grille doit avoir un ticket d accès. Un ticket dans notre service se compose des informations reliés à l utilisateur (sa clé publique, ses droits d accès, ). Notre service est fondé sur la confiance dans la clé secrète du service. Tout membre qui souhaite un accès à une ressource de la grille présente un ticket, qu il obtient après la phase d authentification. L accès est accepté si et seulement si le ticket est signé par la clé secrète du service. Ainsi, notre service maintient un couple clé privé/publique. La clé privée est maintenue secrète, et utilisée pour signer les ticket d accès. Afin de permettre la vérification du ticket, tous les membres de la grille ont la connaissance de la clé publique du service. Dans ce qui suit, les membres de la grille qui sont autorisés à participer aux processus de signature avec la clé secrète du service sont appelés des serveurs, tandis que les autres entités sont appelées des clients. 20

21 Notre service démarre avec un serveur central qui détient cette clé secrète. En fonction du nombre de serveurs connectés à notre service et des hypothèses sur l environnement d exécution, ce dernier évolue en un système décentralisé. En effet, le serveur central définit un partage de la clé secrète et associe à chaque serveur de la grille un sous partage en utilisant la cryptographie à seuil. De cette manière, pour signer un message chaque serveur génère une signature partielle du message en utilisant son sous-partage, et un ensemble de serveurs est capable de générer une signature de ce message avec la clé secrète du service à partir des signatures partielles, et sans qu aucun d eux ne connaisse explicitement la clé secrète. En utilisant une cryptographie à seuil ( n, t + 1), plus de t serveurs doivent être corrompus pour pouvoir générer une signature par la clé secrète du service. Notre protocole utilise également le rafraîchissement des sous-partages pour lutter contre les adversaires mobiles. Les sous-partages sont périodiquement régénérés et les anciens sont détruits. Ceci oblige l adversaire à attaquer au moins t + 1serveurs dans une période limitée appelée fenêtre de vulnérabilité. 2.3 Modèle Notre décrivons dans cette partie notre protocole de sécurité dans un environnement synchrone. Dans la partie xxx, nous définissons les adaptations faites à notre protocole dans un système asynchrone. Notre protocole est constitué de deux phases en fonction du nombre de participants au système: Phase 1 Un seul serveur détient la clé secrète du service. On assure que les moyens de sécurité déployés dans le domaine qui contient ce serveur. Afin d assurer la disponibilité du service, on peut mettre en place plusieurs serveurs qui détiennent la clé secrète du service. Le passage à un système décentralisé est fait en supposant que avec n serveurs, un adversaire n arrive pas à corrompre plus de t serveurs dans une fenêtre de vulnérabilité. Afin d assurer la disponibilité du service, la décision de passage à un système décentralisé est prise dés que n! 2 t + 1 dans un environnement synchrone, et n! 3 t + 1 dans un environnement asynchrone. Phase 2 Les processus d authentification et d autorisation deviennent décentralisés. Plusieurs serveurs participent à la signature du ticket. Les hypothèses liées à notre environnement d exécution sont les suivantes : Serveurs : Notre protocole est exécuté par n serveurs. Ils peuvent être corrects ou corrompus. Un serveur corrompu peut arrêter son exécution, dévier son exécution de sa 21

22 spécification (fautes byzantines), et/ou rendre l information enregistrée dans le serveur inaccessible. On suppose que : au plus t serveurs sont corrompus durant une fenêtre de vulnérabilité. les algorithmes cryptographiques utilisés sont sécurisés (cryptographie à clé publique, cryptographie à seuil, rafraîchissement proactif des sous partages) Lien de communication : chaque serveur est connecté à un canal de diffusion broadcast. Les nœuds connectés à ce canal peuvent lire d une manière instantanée chaque message diffusé sur ce dernier par un autre nœud. Environnement synchrone : les serveurs ont accès à une horloge globale. Le temps est divisée en périodes de temps déterminées par l horloge globale (par exemple, un jour, une semaine, etc.). Au début de chaque période, les serveurs exécutent un protocole de mise à jour (update phase). A la fin de cette phase, les serveurs enregistrent de nouveaux sous partages pour la clé secrète du service. Ces hypothèses offrent aux adversaires la capacité de : corrompre t serveurs dans un temps limité «fenêtre de vulnérabilité», insérer de nouveaux messages, détruire, altérer, rejouer, et réordonner les messages. Système centralisé Système décentralisé Client Trusted1 Serveur1 Sous-partage s 1 Serveur2 Sous-partage s 2 Client Trusted2 Serveur1 Secret S Client Trusted3 Serveur3 Sous-partage s 3 Serveur4 Sous-partage s 4 Figure 5 : Passage d un système centralisé à un système décentralisé. Le système évolue en un système décentralisé après la connexion de 3 serveurs n! 3 t + 1. Le serveur 1 définit un partage (4,1) pour la clé S et associe chaque sous-partage s i au serveur i. 22