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

Présentation au sujet: "Une architecture de sécurité hiérarchique, adaptable et dynamique pour la grille Arnaud Contes."— Transcription de la présentation:

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

2 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

3 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

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

5 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

6 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

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

8 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é

9 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

10 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

11 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

12 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

13 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

14 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

15 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

16 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]

17 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

18 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 - -

19 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

20 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

21 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

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

23 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

24 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

25 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

26 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

27 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

28 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]

29 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 */

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

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

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

33 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

34 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

35 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

36 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

37 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 1Go RAM, linux kernel , JVM Sun 1.5.0, bibliothèque bouncycastle 1.20

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

39 Les iterations de Jacobi
Diagonalisation de matrice JVM … …

40 Durée d’une itération 8 ordinateurs 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

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

42 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

43 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

44 Merci de votre attention
Questions ?