Une architecture de sécurité hiérarchique, adaptable et dynamique pour la grille Arnaud Contes

Sommaire Contexte et objectifs Modèle de sécurité Intégration avec ProActive Conclusions et perspectives Contexte et objectifs Modèle de sécurité Intégration avec ProActive Conclusions et perspectives

Architecture d’une application Runtime = Service offert par un fournisseur Nœud = Espace d’exécution propre à une application Runtime A Runtime B Nœud 1 / app. A Nœud 2 / application A Nœud 3 / app. A Nœud 1 / app. C Nœud 1 / app. B

Déploiement sur grille de calcul Grappe A Même application, multiples déploiements Multiples politiques de sécurité Grappe B

Analyse de solutions de sécurité Legion Globus Corba EJB .NET Communications (A,I,C) + Plusieurs niveaux de Politiques - Sécurité de l’application : Développeur, administrateur Utilisateur Négociation dynamique (+) Sécurité configurable selon le déploiement

Objectifs Faciliter l’utilisation des mécanismes de sécurité par une intégration implicite au code métier de l’application Modèle de sécurité Fonctionnalités de sécurité de base (Authentification, Intégrité, Confidentialité) Prise en compte des politiques de tous les acteurs, notions de hiérarchie: machines, administration (virtuelle) Configurable par l’utilisateur Adaptable en fonction du déploiement

Sommaire Contexte et objectifs Modèle de sécurité Intégration avec ProActive Conclusions et perspectives

Problème initial Contrôle d’accès Diverses entités à sécuriser Entités appartenant à divers acteurs Nécessité d’identifier ces entités Exprimer des politiques de sécurité

Entités sécurisées Définition générique Architecture hiérarchique Objet protégé + gestionnaire de sécurité Pas de supposition faite sur l’objet protégé Architecture hiérarchique Sécurité non intrusive Pas de modification de l’objet protégé Interception des communications par objet d’interposition

Entité sécurisée - Identité Politiques de sécurité Objet Gestionnaire de sécurité - Identité Communications sécurisées Politiques de sécurité Objet protégé - Sessions (connexions aux autres entités) Communications en clair

Authentification Architecture à clé publique de type SPKI Une entité sécurisée == un certificat SPKI Clé publique/privée + identifiant Certificats égaux, peuvent générer des certificats Création de chaînes de certificats Arnaud INRIA INRIA Sophia Équipe OASIS Laurent

Certificat d’application Identifier les objets appartenant à la même application Entité 4 Arnaud Arnaud App. A Entité 2 Entité 3 App. B Entité 1 Entité 2 Entité 1 Entité 1 Approche simple Approche avec certificat d’application Création d’un contexte de sécurité par application Espace de nommage local à l’application

Domaines de sécurité Imposer une même politique de sécurité à un ensemble de runtimes Exemple : regrouper tous les ordinateurs d’une même grappe de calcul sous une même politique Un domaine est une entité sécurisée Organisation hiérarchique des domaines

Taxonomie des politiques Dn Politique des domaines Identité Politiques D0 Identité Politiques Politique de l’application Runtime Identité Politiques Noeud Identité Politiques Politiquede sécurité Objet Politique du fournisseur de ressources Identité Politiques

Langage déclaratif 1/2 -> : Interactions # Attributs Attributs : Entités sources Entités cibles -> : Interactions # Attributs Attributs : Authentification [A] Integrité [I] Confidentialité [C] Chaque attribut: Requis [+] Optionel [?] Refusé [-] Entité : Domaine Runtime Certificat d’application Noeud Objet Certificat Interactions : Requête Réponse Création Runtime Création Noeud Création d’objet

Langage déclaratif 2/2 Pour les interactions intra-domaine A, pas besoin de sécurité Domaine[A]->Domaine[A]:requête, réponse, migration, création noeud, création objet #[?A,?I,?C] Authentification requise des appels de méthodes pour les objets se trouvant dans le domaine A vers le domaine B : Domaine[A]->Domaine[B]:requête, réponse#[+A,?I,?C] Localisation précise Noeud[N1] -> Domaine[A]:requête, réponse#[+A,+I,+C] Runtime[R1],Noeud[N1] -> Domaine[A]: requête, réponse#[+A,?I,?C]

Politiques de sécurité Plusieurs niveaux de politiques Plusieurs politiques pour une situation donnée Calcul d’une politique résultante Sélection des politiques adéquates Composition de ces politiques

Composition de politiques Support de l’interopération La politique résultante préserve les attributs de chaque politique Si incompatibilité, interdiction de l’interaction Appelé Requis (+) Optionnel (?) Refusé (-) Appelant Requis (+) + + invalide Optionnel (?) + ? - Refusé (-) invalide - -

Négociation dynamique Sécurisation transparente des interactions entre les entités I Domaine Inria A Objet A Objet B <Psession> A Id objet A B Id objet B session B I 1. Récupérer la localisation des entités source (A) et cible (B) 2. Calcul de la politique en fonction des entités en présence 3. Validation par l’appelé de la politique <Psession> proposée par l’appelant 4. Création de l’objet session contenant la politique entre A et B

Propagation dynamique du contexte de sécurité Support de la dynamicité des applications Automatiser la création des entités sécurisées Conserver le contexte de sécurité de l’application Nouvelle entité sécurisée: Utilisation du certificat d’application pour créer le certificat de l’entité Copie de la politique de sécurité de l’application

Sécurité induite par le déploiement Communication normale Descripteur de déploiement Grappe A et B Descripteur de sécurité Grappe A et B Identité Politiques Processus de déploiement Descripteur de déploiement Grappe A Communication sécurisée Grappe A Processus de déploiement Descripteur de sécurité Grappe A Identité Politiques Grappe B

Sommaire Contexte et objectifs Modèle de sécurité Intégration avec ProActive Conclusions et perspectives

ProActive Bibliothèque Java pour le calcul distribué Modèle à objet actifs Objet racine (activité) + graphe d’objets passifs Pas de partage d’objets passifs Communication Invocation de méthode à distance Asynchrone avec rendez-vous Protocole à méta objets Interception transparente des communications Sémantique insensible au déploiement Modèle de déploiement abstrait

Modèle de déploiement abstrait Repose sur la notion de nœuds virtuels (VN) Nœud == projection d’un VN sur un runtime Développement Code source Déploiement Descripteur XML Objets  VN VN  Runtimes  Hosts

Entités sécurisées et interactions Objet actif, Nœud (nœud virtuel), Runtime Interactions : Requêtes / réponses Migration Création d’objet actif Création de nœuds

Communications sécurisées Pendant la phase de rendez-vous : Initialisation de la session (si nécessaire) Transmission du message sécurisé Si autorisée, conserve la garantie de la délivrance du message Expéditeur peut être informé de l’échec de la communication et agir en conséquence

Exemple Une grille composée de deux grappes Application : Domaine [GrappeA] -> Domaine [GrappeA]: Q,P,M # [?A,?I,?C] Domaine [GrappeB] -> Domaine [GrappeB]: Q,P,M # [?A,?I,?C] Domaine [GrappeA] -> Domaine [GrappeB]: Q,P,M # [+A,+I,+C] Domaine [GrappeB] -> Domaine [GrappeA]: Q,P,M # [+A,+I,+C] Application : 2 nœuds virtuels (vn1,vn2) 2 objects actifs

Descripteurs : déploiement et sécurité Nœuds virtuels: vn1, vn2 Projections: vn1 --> OrdinateursGrappeA, OrdinateursGrappeB vn2 --> OrdinateursGrappeA Sécurité : VN [vn1] -> VN [vn2] : Q,P # [+A,?I,?C] VN [vn1] -> VN [vn1] : M # [+A,?I,?C]

Code standard, pas de sécurité … proActiveDescriptor.activateMappings(); vn1 = proActiveDescriptor.getVirtualNode("vm1"); vn2 = proActiveDescriptor.getVirtualNode("vm2"); Flower rose = (Flower) ProActive.newActive(Flower.class,new Object[]{« Rose »}, vn1.getNode()}; Flower daliah = (Flower) ProActive.newActive(Flower.class,new Object[]{« Daliah »}, vn2.getNode()}; /* migration vers le même nœud virtuel, même domaine */ rose.migrateTo(vn1); /* communication dans le même domaine */ rose.sayHelloTo(daliah); /* migration vers le même nœud virtuel, autre domaine */ /* communication entre les deux domaines */

Exemple Politiques de sécurité VN1 Runtime VN2 Domaine GrappeA Domaine GrappeB Politiques de sécurité VN1 Runtime VN2

Exemple Politiques de sécurité VN1 Runtime VN2 Domaine GrappeA Domaine GrappeB Politiques de sécurité VN1 Runtime VN2

Exemple Politiques de sécurité VN1 Runtime VN2 Domaine GrappeA Domaine GrappeB Rose Daliah Politiques de sécurité VN1 Runtime VN2

Exemple Migration : - même VN - même domaine Domaine GrappeA Domaine GrappeB Migration : - même VN - même domaine Rose Daliah Politique de l’application : VN1 -> VN1 : migration # [+A,?I,?C] Politique du domaine : GrappeA -> GrappeA : [?A,?I,?C] Politique résultante : Migration : [+A,?I,?C] Politiques de sécurité VN1 Runtime VN2

Exemple Appel de meth. - même domaine Domaine GrappeA Domaine GrappeB Appel de meth. - même domaine Rose Daliah Politique de l’application : VN1 -> VN2 : requête # [+A,?I,?C] Politique du domaine : GrappeA -> GrappeA : [?A,?I,?C] Politique résultante communication sécurisée [+A,?I,?C] Politiques de sécurité VN1 Runtime VN2

Exemple Migration : - même VN - autre domaine Domaine GrappeA Domaine GrappeB Migration : - même VN - autre domaine Rose Rose Rose Daliah Politique de l’application : VN1 -> VN1 : migration # [+A,?I,?C] Politique du domaine : GrappeA -> GrappeB : [+A,+I,+C] Politique résultante migration sécurisée [+A,+I,+C] Politiques de sécurité VN1 Runtime VN2

Exemple Appel de meth. - même VN - autre domaine Domaine GrappeA Domaine GrappeB Appel de meth. - même VN - autre domaine Rose Daliah Politique de l’application : VN1 -> VN2 : requête # [+A,?I,?C] Politique du domaine : GrappeB -> GrappeA : [+A,+I,+C] Politique résultante communication sécurisée [+A,+I,+C] Politiques de sécurité VN1 Runtime VN2

Performances Création objet actif Génération d’une clé de session AES Sans sécurité : 80 ms Avec sécurité (clé RSA 1024bits) : 540 ms Dont temps de génération de clé 460 ms Génération d’une clé de session AES 192 bits : 0.8 ms Test réalisés sur des pentium IV@3GHz, 1Go RAM, linux kernel 2.4.22, JVM Sun 1.5.0, bibliothèque bouncycastle 1.20

Performances (+A,+I,+C) Pire cas possible, pas de calcul, pas de recouvrement Test réalisés sur des pentium IV@3GHz, 1Go RAM, linux kernel 2.4.22, JVM Sun 1.5.0, bibliothèque bouncycastle 1.20

Les iterations de Jacobi Diagonalisation de matrice JVM 2 5 7 9 1 0 1 0 5 6 7 8 … …

Durée d’une itération 8 ordinateurs (PIV@3.2GHz, 1Go ram, Ethernet 1Gb/s) / 16 objets actifs Coût de la sécurité : de 120% à 18% Version distribuée plus rapide que séquentiel pour matrice >= 8 M doubles Distribuée et sécurisée + rapide >= 22M doubles

Sommaire Contexte et objectifs Modèle de sécurité Intégration avec ProActive Conclusions et perspectives

Conclusions Modèle de sécurité : Sécurité : Concept générique : entités sécurisées Sécurité : Transparente au code métier des applications (développeurs) Configurable selon le déploiement (utilisateurs) Gestion de plusieurs niveaux de politiques de sécurité Calcul dynamique de la politique Propagation dynamique du contexte de sécurité Langage de sécurité déclaratif Politiques composables supportant l’interopération

Perspectives Support du contrôle de flux Reconfiguration dynamique des entités sécurisées : Mise à jour de la politique de sécurité Changement d’identité Preuve formelle du modèle Utilisation pratique: projet Européen Provenance

Merci de votre attention Questions ?