these doctorat une architecture de securité

More documents

Recommendations

Info

Chapitre 2. Théories et Modèles posés lors de l’utilisation de politiques de sécurité dans un environnement distribué. Dans la section 2.7, nous avons abordé le thème de la programmation réflexive ainsi que l’utilisation de protocoles à méta objets et présenté les problèmes posés au niveau de la sécurité dans de tels systèmes. L’interception transparente des appels de méthodes envoyés par et vers des objets réflexifs constitue la base de la partie implicite de notre approche. L’implantation de notre mécanisme de sécurité au sein du méta niveau nous permet, toujours de manière implicite, de mettre en œuvre les objets et les protocoles de sécurité nécessaires sans avoir à modifier le code métier de l’application. Il est ainsi possible de rendre la gestion de la sécurité orthogonale au code métier de l’application. Finalement nous nous sommes intéressés au problème de sécurisation du code mobile. Notre étude s’est essentiellement portée sur l’analyse des problèmes de sécurité existants dans le cadre des agents mobiles dont l’hôte est considéré comme de confiance. tel-00239252, version 1 - 5 Feb 2008 28
Chapitre 3 Étude d’intergiciels sécurisés pour le calcul distribué tel-00239252, version 1 - 5 Feb 2008 Il existe déjà de nombreux intergiciels sécurisés. S’ils proposent tous des mécanismes de sécurité basiques permettant l’authentification, l’intégrité et la confidentialité des données, ils n’ont pas la même approche dans la façon de manipuler des objets de sécurité et de faire interagir l’utilisateur, l’application et l’intergiciel. Nous allons dans ce chapitre présenter les intergiciels que nous avons étudiés. Pour chacun, nous présentons l’architecture générale et le modèle de sécurité utilisé. Afin de permettre une comparaison plus aisée et quand cela nous a été possible, nous présentons l’implantation d’un même exemple pour chaque intergiciel ainsi que les modifications imposées par le mécanisme de sécurité qui en résultent. L’exemple choisi représente l’implantation d’un journal intime accessible à distance. Bien évidemment, seule la personne à qui appartient le journal a le droit d’écrire dedans et de le lire, les communications avec le serveur doivent être confidentielles et intègres. Il s’agit d’un exemple simple, mettant en évidence les mécanismes de sécurité impliqués pour chaque intergiciel ainsi que le niveau de transparence qu’il est possible d’obtenir. Tous les systèmes présentés ici se basent sur le postulat que les hôtes qui leur permettent de s’exécuter sont de confiance. 3.1 Legion Développé à l’université de Virginie par l’équipe d’Andrew Grimshaw, Legion [74, 91, 106] est un des premiers projets traitant de grilles de calcul, sa conception remontant à 1994. Dans son principe, Legion se présente comme un méta système d’exploitation à objets orienté grille de calcul. Il étend le système d’exploitation initial en lui rajoutant ses fonctionnalités propres. Cette couche d’abstraction et d’uniformisation permet la réunion d’un ensemble de machines indépendantes et hétérogènes en un seul environnement virtuel partagé par tous les utilisateurs. D’après ses auteurs, Legion est capable de gérer un système contenant des milliers de machines hôtes et autant d’objets, l’ensemble étant interconnecté par des liens réseaux très haut débit. La philosophie poursuivie par Legion comporte plusieurs aspects dont le point le plus important est le suivant : Tout est objet. Tout objet Legion appartient à une classe et peut communiquer avec les autres objets par invocation de méthodes. Une classe consiste en une interface, un ensemble d’implantations en divers langages de programmation (C++ et ADA), un générateur ainsi que des informations sur son propriétaire et les besoins en terme de ressources. Les interfaces sont décrites dans un langage d’interface (Interface Definition Language ou IDL) indépendant du langage de programmation. Les implantations se divisent en deux parties, les implantations sources contenant le code source de l’objet et les implantations concrètes représentant la version exécutable de l’objet. Comme n’importe quel système d’exploitation, Legion est construit au dessus de ressources 29
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: Section 2.9. Conclusion ce contexte
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 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 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 103 and 104:
Page 105 and 106:
Page 107 and 108:
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 and 134:
Section 6.7. Modèle à composants
Page 135 and 136:
Section 6.8. Sémantique des commun
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
Page 157 and 158:
Page 159 and 160:
show all

these doctorat une architecture de securité

Create successful ePaper yourself

Delete template?

Save as template?