these doctorat une architecture de securité

More documents

Recommendations

Info

Chapitre 6. Implantation dans ProActive : une approche transparente Le composant parallèle (schéma (c) figure 6.13) est construit au-dessus du mécanisme de communication de groupe. Les composants du composant parallèle sont regroupés au sein d’un groupe. La communication sécurisée au sein d’un composant parallèle se comporte de manière identique à celle d’une communication de groupe. Selon le fait que le groupe est un groupe simple, hiérarchique ou actif, le gestionnaire de sécurité s’adaptera aux propriétés des communications sécurisées au sein d’un groupe d’objets actifs telles que présentées dans la section 6.4. 6.8 Sémantique des communications sécurisées tel-00239252, version 1 - 5 Feb 2008 6.8.1 Communications locales et distantes Dans la partie 4.3, nous avons présenté la sémantique des communications telle qu’elle existe au sein de la bibliothèque. Nous allons reprendre les points et montrer comment l’introduction de la sécurité s’intègre avec le modèle existant. Lorsque deux objets actifs se trouvent dans le même espace d’adressage (i.e. dans la même machine virtuelle), ils doivent pouvoir communiquer directement sans passer par la pile des protocoles réseaux, tout en conservant une sémantique identique. Cette optimisation existe dans ProActive cependant elle maintient la sémantique de passage de paramètres par copie profonde, garantissant ainsi l’absence d’objets passifs partagés. Au niveau du protocole de sécurité, on peut se demander si, lors d’un appel de méthode local, le chiffrement de la communication n’est pas superflu vu l’inexistence du risque d’interception de la communication par une tierce partie. Cependant, nous avons fait le choix de chiffrer les communications même à l’intérieur du même espace adressage. Si, du point de vue des performances, cette solution n’est pas optimale, elle a l’avantage de garantir la sémantique du mécanisme de sécurité : toute communication qu’elle soit locale ou distante sera chiffrée si la politique de sécurité l’impose. 6.8.2 Sécurisation des messages Nous allons présenter ici les techniques mises en œuvre pour appliquer le principe de transparence de la sécurité par rapport au code application. Un des effets de bord positifs de cette approche est d’étendre la transparence de la sécurité bien au delà du code applicatif et de d’implanter la transparence dans les méta-objets eux-mêmes. Pour cela, nous avons étendu l’interface Message qui est l’interface mère de tous les messages échangés entre les diverses entités composant une application. La principale modification a fait en sorte que le message puisse gérer lui-même sa sécurité. En effet, lorsqu’un message va être envoyé sur le réseau, il doit être sérialisé. Un objet sérialisable est capable de gérer lui-même sa propre sérialisation. À partir de ce moment, le message est capable de détecter qu’il va être envoyé sur le réseau. Il va ainsi pouvoir sécuriser les diverses données sensibles qu’il contient en fonction de la politique de sécurité qui aura été négociée par le gestionnaire de sécurité. Pour chaque classe implantant l’interface Message, il est nécessaire de spécialiser les méthodes gérant la sécurisation du message. Effectivement, selon le type de la classe, les données sensibles ne seront pas les mêmes. Par exemple, la classe RequestImpl contient une variable d’instance correspondant à l’appel de méthode et à ses paramètres. Cette variable n’existe bien évidemment pas dans la classe ReplyImpl qui contient une autre variable représentant le résultat d’un précédent appel de méthode. 6.8.3 Appel de méthode sécurisé La figure 6.14 présente les divers objets et méta-objets traversés lors d’un appel de méthode sécurisé d’un objet actif sur un autre. On s’aperçoit en premier lieu que le chemin suivi par l’appel de méthode sécurisé est ressemble fortement à celui d’un appel de méthode non sécurisé. On a rajouté en fait deux indirections supplémentaires. La première se situe au moment de l’envoi du message vers le body 120
Section 6.8. Sémantique des communications sécurisées tel-00239252, version 1 - 5 Feb 2008 FIG. 6.14 – Appel de méthode sécurisé 121
Page 1 and 2:
THÈSE DE DOCTORAT École doctorale
Page 3 and 4:
tel-00239252, version 1 - 5 Feb 200
Page 5 and 6:
Table des matières Remerciements x
Page 7 and 8:
TABLE DES MATIÈRES 6.3.3 Optimisat
Page 9 and 10:
Table des figures tel-00239252, ver
Page 11 and 12:
Liste des tableaux 2.1 Niveau de co
Page 13 and 14:
Remerciements Mes remerciements von
Page 15 and 16:
Chapitre 1 Introduction tel-0023925
Page 17 and 18:
Section 1.1. Problématique et obje
Page 19 and 20:
Chapitre 2 Théories et Modèles Ce
Page 21 and 22:
Section 2.2. Vulnérabilités des s
Page 23 and 24:
Section 2.3. Le contrôle d’accè
Page 25 and 26:
Section 2.4. Introduction à la cry
Page 27 and 28:
Section 2.4. Introduction à la cry
Page 29 and 30:
Section 2.5. Les infrastuctures à
Page 31 and 32:
Section 2.6. Les politiques de séc
Page 33 and 34:
Section 2.6. Les politiques de séc
Page 35 and 36:
Section 2.7. Programmation Réflexi
Page 37 and 38:
Section 2.7. Programmation Réflexi
Page 39 and 40:
Section 2.8. Sécurisation du code
Page 41 and 42:
Section 2.9. Conclusion ce contexte
Page 43 and 44:
Chapitre 3 Étude d’intergiciels
Page 45 and 46:
Section 3.2. Open Grid Service Arch
Page 47 and 48:
Section 3.2. Open Grid Service Arch
Page 49 and 50:
Section 3.3. CORBA // recuperation
Page 51 and 52:
Section 3.4. Les Entreprise JavaBea
Page 53 and 54:
Page 55 and 56:
Page 57 and 58:
Section 3.5. La plateforme .NET sé
Page 59 and 60:
Section 3.5. La plateforme .NET } L
Page 61 and 62:
Section 3.6. Bilan Legion Globus CO
Page 63 and 64:
Chapitre 4 Contexte : ProActive tel
Page 65 and 66:
Section 4.2. Objets Actifs objet. t
Page 67 and 68:
Section 4.3. Sémantique des commun
Page 69 and 70:
Section 4.5. Communications de grou
Page 71 and 72:
Section 4.5. Communications de grou
Page 73 and 74:
Section 4.6. Déploiement des appli
Page 75 and 76:
Section 4.6. Déploiement des appli
Page 77 and 78:
Section 4.7. Conclusion Le con
Page 79 and 80:
Chapitre 5 Une architecture de séc
Page 81 and 82:
Section 5.2. Un modèle de sécurit
Page 83 and 84: Section 5.2. Un modèle de sécurit
Page 85 and 86: Section 5.2. Un modèle de sécurit
Page 87 and 88: Section 5.3. Authentification des e
Page 93 and 94: Section 5.4. Politiques de sécurit
Page 95 and 96: Section 5.4. Politiques de sécurit
Page 97 and 98: Section 5.5. Négociation Dynamique
Page 99 and 100: Section 5.5. Négociation Dynamique
Page 101 and 102: Section 5.6. Sécurité induite par
Page 109 and 110: Section 5.7. Propagation dynamique
Page 111 and 112: Section 5.8. Exemple du journal int
Page 113 and 114: Chapitre 6 Implantation dans ProAct
Page 115 and 116: Section 6.1. Création des entités
Page 117 and 118: Section 6.2. Interface de programma
Page 119 and 120: Section 6.3. Migration et sécurit
Page 121 and 122: Section 6.4. Communications de grou
Page 123 and 124: Section 6.4. Communications de grou
Page 125 and 126: Section 6.5. Architecture pair-à-p
Page 127 and 128: Section 6.5. Architecture pair-à-p
Page 129 and 130: Section 6.6. Tolérance aux pannes
Page 131 and 132: Section 6.7. Modèle à composants
Page 133: Section 6.7. Modèle à composants
Page 137 and 138: Section 6.9. Conclusion Pour qu’u
Page 139 and 140: Chapitre 7 Tests et performances 7.
Page 141 and 142: Section 7.2. Les itérations de Jac
Page 143 and 144: Section 7.2. Les itérations de Jac
Page 145 and 146: Chapitre 8 Conclusion Ce chapitre r
Page 147 and 148: Section 8.2. Perspectives tel-00239
Page 149 and 150: Section 8.2. Perspectives ouverte ;
Page 151 and 152: Annexe A Grammaire de la politique
Page 153 and 154: Bibliographie tel-00239252, version
Page 155 and 156: BIBLIOGRAPHIE tel-00239252, version
show all

these doctorat une architecture de securité

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?