A Security Architecture for Computational Grids Fait par : Ian Foster, Carl Kesselman Gene Tsudik, Steven Tuecke Mathematics and Computer Science Argonne.

Présentation au sujet: "A Security Architecture for Computational Grids Fait par : Ian Foster, Carl Kesselman Gene Tsudik, Steven Tuecke Mathematics and Computer Science Argonne."— Transcription de la présentation:

1 A Security Architecture for Computational Grids Fait par : Ian Foster, Carl Kesselman Gene Tsudik, Steven Tuecke Mathematics and Computer Science Argonne National Laboratory Information Sciences Institut University of Southern California DEA DISIC 2003/2004 Option : Métacomputing Revue darticle par : Mr Saadi Rachid

2 Introduction Les problèmes Les besoins La politique Etat de lart Le modèle proposée Déploiement Conclusion et critiques Plan Introduction Les problèmes de sécurité Les besoins de sécurité La politique de sécurité Etat de lart Larchitecture proposée Déploiement Conclusion et critiques

3 Introduction Les problèmes Les besoins La politique Etat de lart Le modèle proposée Déploiement Conclusion et critiques Introduction La technologie actuelle et les besoins croissants des scientifiques exigent de plus en plus l'accès rapide à de grandes quantités de données en utilisant un certain nombre de ressources, ayant souvent besoin dune grande capacité de calcule. De ce faite, une nouvelle technologie issus des systèmes distribué à vus le jour, sous le nom de Grille de calcule ou DataGrid, cette architecture fait lobjet de plusieurs Projet de recherche au niveau US et européen. Ceci conduit impérativement à des problèmes de sécurité dans la grille de calcule, qui nécessite le développer dune politique de sécurité ainsi que des mécanismes et protocoles adéquats. Le problème de contrôle daccès est un problème qui fait encore lobjet de recherche, cet article ce présente comme l un de premier qui cest attaqué à ce genre de problème.

4 Introduction Les problèmes Les besoins La politique Etat de lart Le modèle proposée Déploiement Conclusion et critiques Les Problèmes de sécurité La dynamisité des utilisateur,des ressources la quantité et l'endroit des Ressources change rapidement et dynamiquement. les processus utilisent différentes techniques de calcules nécessitant lutilisation dune variété de mécanismes tels que : l'UNICAST et le MULTICAST. Ou bien lintégration de quelques moulinettes touchant la couche de bas niveau du TCP/IP. Une diversité de mécanismes de techniques et de politique tels que SSL, Kerberos etc.… La gestion des différents profiles locaux et externes La dispersion géographique des ressources et des utilisateurs

5 Introduction Les problèmes Les besoins La politique Etat de lart Le modèle proposée Déploiement Conclusion et critiques Les besoins de sécurité Un login unique: Protection du Credential: (mots de passe, clés privées, etc.) doivent être protégés. Interopérabilité avec les solutions de sécurité implémentées déjà localement Exportabilité Conformité Credential avec les infrastructures de certification existantes telle que X.509v3 Supporté un groupe de communication : une allocation de Ressources partagées, au mouvement dynamique au sein dun même groupe etc… Supporté une multitude dimplémentation

6 Introduction Les problèmes Les besoins La politique Etat de lart Le modèle proposée Déploiement Conclusion et critiques La politique de sécurité La grille de calcul comprend une multitude de domaine sécurisé. La politique de sécurité est appliquée localement sur le domaine Mécanisme dauthentification entre les différentes Ressources qui se trouve sur des sites diffèrent. Une authentification globale implique une authentification locale sur chaque machine locale Toutes décision de contrôle daccès est prise localement. Un programme ou un processus est autorisé pour travailler pour le compte de lutilisateur, en utilisant un sous ensemble des ses droits. Si un ensemble de processus sexécute pour le compte dun même sujet dans un même domaine sécurisée, ils doivent alors impérativement partagés le même sous ensemble de droits.

7 Introduction Les problèmes Les besoins La politique Etat de lart Le modèle proposée Déploiement Conclusion et critiques Etat de lart Kerberos ( largement utilisé dans les années 80 ) DSE dérivé de Kerberos SSH SSL ( Netscape's secure communication package ) CRISIS The Legion

8 Introduction Les problèmes Les besoins La politique Etat de lart Le modèle proposée Déploiement Conclusion et critiques Larchitecture proposée Définition 1 : Cest la partie qui soccupe de gérer les différents processus, en leurs donnant la permission de travailler pour le compte de lutilisateur pour une période de temps limitée. Définition 2 : Cest un agent qui est utilisé pour faire la translation des opérations et des mécanismes de sécurité entre linter-domaine et lintra-domaine.

9 Introduction Les problèmes Les besoins La politique Etat de lart Le modèle proposée Déploiement Conclusion et critiques Protocole 1 1.un utilisateur sauthentification sur le UserProxy 2. Lutilisateur produit alors Le UserProxy Credential, Cup, en utilisant son propre Credential, Cu, pour signer le tuple suivant : Cup= Sigu { user-id, Hôte, temps de validité, etc….} 3. De cette manière le processus est créé et pourra fournir le Cup.

10 Introduction Les problèmes Les besoins La politique Etat de lart Le modèle proposée Déploiement Conclusion et critiques Protocole 2 1. Le UserProxy et le RessourceProxy sassure quil ya pas un autre qui utilise Cup et le Crp, et vérifie par la suite si Cup na pas expiré. 2. Le UserProxy envoi au RessourceProxy sa requête signée sous la forme suivante : Sigup{Allocation spécification} 3. Le RessourceProxy sassure que le Credential de lutilisateur signé par le UserProxy est autorisé par la politique locale de sécurité a sallouer ces ressources. 4. Si la requête est honorée, le RessourceProxy créé le Ressource Credential, qui contient le nom de lutilisateur, lensemble des ressources qui lui sont allouées, les noms des ressources etc. 5. Le Ressources Proxy envoi de manière sécurisée le Ressources Credential au UserProxy 6. Le UserProxy examine la requête, si il est satisfait, il envoi alors Le Cp signé pour cette requête. 7. Le UserProxy alors envoi à son tour de manière sécurisée le Cp. 8. A ce moment là le RessourceProxy alloue Les Ressources nécessaires et passe le Cp à lexécution.

11 Introduction Les problèmes Les besoins La politique Etat de lart Le modèle proposée Déploiement Conclusion et critiques Protocole 3 1. Le processus et son UserProxy vérifies si il ya pas un autre qui utilise Le Cp et le Cup. 2. Le processus alors envoi sa requête signée au UserProxy : Sigp {Allocation request} 3. Si le UserProxy veut honorer cette requête alors il lance le protocole 2 4. Le résultat obtenu est signé par le UserProxy et renvoyé au Processus demandeur.

12 Introduction Les problèmes Les besoins La politique Etat de lart Le modèle proposée Déploiement Conclusion et critiques Protocole 4 1. Le UserProxy sauthentifie auprès du Ressource Proxy, et ensuite envoi le Map-Subject-UP, la requête de mappage. 2. Le User sauthentifie auprès du la Ressources en utilisant la politique de sécurité locale, et ensuite envoi le Map- Subject-P, la requête de mappage. 3. Le Ressource Proxy se met en attente des deux requêtes de mappage. 4. Si deux requête coïncide pendant un Map-timeout, alors le RessourceProxy met à jour sa table de mappage, et envoi un acquittement aux User et au UserProxy.

13 Introduction Les problèmes Les besoins La politique Etat de lart Le modèle proposée Déploiement Conclusion et critiques Déploiement Les quatre protocoles sont implémentés en utilisant Les GSS-API (Generic Security Services application programming interface) qui a été développé par GSI (Globus Security Infrastructure)

14 Introduction Les problèmes Les besoins La politique Etat de lart Le modèle proposée Déploiement Conclusion et critiques Déploiement Lavantage dutiliser GSS-API : Le déploiement de GSI : qui cest fait dans le cadre du projet Globus, qui implémente une architecture en grille appelée Gusto qui peut atteindre une puissance de calcule de 2.5 Teraflops, et intégre 20 sites réparties sur 5 pays, NSF Supercomputer Centers, DOE Laboratories, DoD Resource Centers, NASA Laboratories, Universities, And Companies. 2.Lutilisation du protocole dauthentification assez rigide car il a fait ces preuves, appelé SAP basée sur un système de clés publiques, qui représente la partie authentification dans SSL. GSS/SAP En ce qui concerne la certification elle est gérée par le Système Globus. les RessourcesProxy ont été implémentés comme Gateways aux autres systèmes.

15 Introduction Les problèmes Les besoins La politique Etat de lart Le modèle proposée Déploiement Conclusion et critiques Conclusion et critiques Larchitecture décrite dans cet article est facile à implémenter et vient comme une porte ouverte à dautre recherche ainsi que lélaboration de nouveaux mécanismes plus sophistiqués. Lapport de cette article en terme de sécurité se base essentiellement sur lintroduction de la notion de User Proxy et de Ressource Proxy, cette apport est notamment considérable vu que depuis 1998 on note 74 Citations daprès Citeseer. Néanmoins, je trouve que larticle est très bien structuré, mais présente quelques difficultés de compréhension et dambiguïté pour les différents termes utilisés.

16 Introduction Les problèmes Les besoins La politique Etat de lart Le modèle proposée Déploiement Conclusion et critiques Questions Question ? ? ? ? ? ? ? ? ? Merci pour votre attention