A Security Architecture for Computational Grids

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

2. Plan • Introduction • Les problèmes de sécurité • Les besoins de sécurité • La politique de sécurité • Etat de l’art • L’architecture proposée • Déploiement • Conclusion et critiques

3. 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 d’une 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 l’objet 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 d’une politique de sécurité ainsi que des mécanismes et protocoles adéquats. • Le problème de contrôle d’accès est un problème qui fait encore l’objet de recherche, cet article ce présente comme l ‘un de premier qui c’est attaqué à ce genre de problème.

4. 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 l’utilisation d’une variété de mécanismes tels que : l'UNICAST et le MULTICAST. Ou bien l’inté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. 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 d’un même groupe etc… • Supporté une multitude d’implémentation

6. 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 d’authentification 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 d’accès est prise localement. • Un programme ou un processus est autorisé pour travailler pour le compte de l’utilisateur, en utilisant un sous ensemble des ses droits. • Si un ensemble de processus s’exécute pour le compte d’un 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. Etat de l’art • Kerberos (largement utilisé dans les années 80) • DSE dérivé de Kerberos • SSH • SSL (Netscape's secure communication package) • CRISIS • The Legion

8. L’architecture proposée Définition 1 : C’est la partie qui s’occupe de gérer les différents processus, en leurs donnant la permission de travailler pour le compte de l’utilisateur pour une période de temps limitée. Définition 2 : C’est un agent qui est utilisé pour faire la translation des opérations et des mécanismes de sécurité entre l’inter-domaine et l’intra-domaine.

9. Protocole 1 • un utilisateur s’authentification sur le UserProxy • 2. L’utilisateur 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. Protocole 2 • 1. Le UserProxy et le RessourceProxy s’assure qu’il y’a pas un autre qui utilise Cup et le Crp, et vérifie par la suite si Cup n’a pas expiré. • 2. Le UserProxy envoi au RessourceProxy sa requête signée sous la forme suivante : • Sigup{Allocation spécification} • 3. Le RessourceProxy s’assure que le Credential de l’utilisateur signé par le UserProxy est autorisé par la politique locale de sécurité a s’allouer ces ressources. • 4. Si la requête est honorée, le RessourceProxy créé le Ressource Credential, qui contient le nom de l’utilisateur, l’ensemble 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 à l’exécution.

11. Protocole 3 1. Le processus et son UserProxy vérifies si il y’a 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. Protocole 4 1. Le UserProxy s’authentifie auprès du Ressource Proxy, et ensuite envoi le Map-Subject-UP, la requête de mappage. 2. Le User s’authentifie 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. 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. Déploiement L’avantage d’utiliser GSS-API : • Le déploiement de GSI : qui c’est 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. L’utilisation du protocole d’authentification 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. Conclusion et critiques • L’architecture décrite dans cet article est facile à implémenter et vient comme une porte ouverte à d’autre recherche ainsi que l’élaboration de nouveaux mécanismes plus sophistiqués. • L’apport de cette article en terme de sécurité se base essentiellement sur l‘introduction de la notion de User Proxy et de Ressource Proxy, cette apport est notamment considérable vu que depuis 1998 on note 74 Citations d’après Citeseer. • Néanmoins, je trouve que l’article est très bien structuré, mais présente quelques difficultés de compréhension et d’ambiguïté pour les différents termes utilisés.

16. Merci pour votre attention Questions Question ? Question ? Question ? Question ? Question ? Question ? Question? Question ? Question ?