these doctorat une architecture de securité

More documents

Recommendations

Info

Chapitre 5. Une architecture de sécurité de haut niveau 5.6.1 Principe Nous avons déjà présenté les descripteurs de déploiement (voir section 4.6) qui introduisent un niveau d’abstraction concernant le déploiement de l’application et permettent une structuration de l’application en terme d’activités conceptuelles. Nous allons étendre cette approche en se servant de la structuration de l’application pour exprimer les besoins de sécurité de chaque activité et ainsi définir une politique de sécurité générale pour l’application. tel-00239252, version 1 - 5 Feb 2008 Afin de définir de manière abstraite la politique de sécurité d’une application, nous réutilisons la notion de nœuds virtuels introduite précédemment et nous posons la définition suivante : Définition 12 Sécurité des nœuds virtuels Une politique de sécurité peut être définie au niveau des nœuds virtuels. A l’exécution, la politique de sécurité d’un nœud va dépendre de la politique du nœud virtuel dont il fait partie et de la politique de la JVM sur laquelle il se trouve. Les nœuds virtuels sont le support de l’expression de la politique de sécurité d’une application. Si, au moment de la conception d’une application, un processus requiert un niveau de sécurité spécifique (authentification des utilisateurs et chiffrement des communications), alors ce processus doit être rattaché à un nœud virtuel sur lequel ces règles de sécurité sont imposées. Il est de la responsabilité du concepteur de structurer son application ou ses composants en utilisant l’abstraction liée aux nœuds virtuels pour imposer les règles de sécurité voulues. Lorsqu’une politique de sécurité doit être calculée pour une interaction donnée, le nœud, en tant qu’entité sécurisée, va rechercher dans ses propres politiques de sécurité celles qui correspondent à l’interaction. Etant donné, que le nœud appartient à un nœud virtuel donné d’une application donnée et que sa politique de sécurité est identique à celle de l’application, la politique de sécurité qu’il retournera sera conforme à celle de l’application. Nous avons également vu que l’algorithme de composition des politiques de sécurité assure leur interopérabilité. Ainsi, nous pouvons prouver que quel que soit le résultat du déploiement d’une application, la politique de sécurité initialement définie au niveau des nœuds virtuels sera conservée et appliquée. La figure 5.13 expose les divers éléments entrant en jeu dans le processus de déploiement d’une application sécurisée. Elle présente une application structurée autour de deux nœuds virtuels (VN1 et VN2), chacun contenant un objet actif. Le fichier de déploiement spécifie deux runtimes (Runtime1 et Runtime2). Le premier Runtime1 est déployé avec la politique de sécurité de l’application et apparaîtra comme une entité appartenant à l’application. Le deuxième Runtime2 est un runtime déjà existant, possédant sa propre politique de sécurité, indépendante de celle de l’application. Les nœuds et les objets actifs dépendront de la politique de sécurité de l’application décrite dans un fichier externe référencé par le descripteur de déploiement. Le référencement se fait par l’ajout d’une balise supplémentaire au sein du descripteur de déploiement : 5.6.2 Contexte et environnement Lors du déploiement d’une application, l’utilisateur va être amené à écrire des politiques de sécurité concernant les interactions entre les entités de l’application elles mêmes et les interactions entre les entités de l’application et des entités extérieures au contexte de l’application. Pour écrire une règle d’une politique de sécurité, il faut pouvoir identifier les entités ; nous avons vu qu’il était possible d’utiliser le certificat de l’entité pour cette identification. Cependant, les diverses entités d’une application, ne possèdent pas, dans le cas d’un déploiement sécurisé transparent, de certificats. Ces derniers ne seront créés dynamiquement que lors du déploiement de l’application. La seule identification des diverses entités qui existe à ce niveau du déploiement de l’application est celle donnée par le descripteur de déploiement. On retrouve dans le descripteur des identifiants permettant la mise en place de l’architecture qui servira de support à l’application. Ce sont ces identifiants que nous allons réutiliser au sein du fichier de politique de sécurité. 88
Section 5.6. Sécurité induite par le déploiement tel-00239252, version 1 - 5 Feb 2008 FIG. 5.13 – Déploiement d’une application sécurisée 5.6.3 Descripteur de politiques de sécurité Nous allons décrire maintenant la syntaxe du descripteur de politiques de sécurité. Il s’agit du fichier qui contient les informations nécessaires au mécanisme de sécurité pour mettre en place l’architecture sécurisée et la politique de sécurité qui va gouverner le comportement de l’application. Le fichier est au format XML. Un fichier de politique de sécurité commence par la balise XML . La première partie du fichier contient les informations utiles au mécanisme de sécurité. La première balise permet de nommer l’application, ce nom se trouvera au sein de toutes les entités créées à partir de ce déploiement. Il permet à l’utilisateur, s’il le souhaite, de nommer une instance donnée d’une application juste en changeant la chaîne de caractères. Garden La partie suivante concerne l’identification de l’instance de l’application associée à ce descripteur de sécurité, deux approches sont possibles. La première consiste à référencer le certificat de l’utilisateur en utilisant la ligne XML suivante : user-certificate.p12 où user-certificate.p12 représente le fichier contenant le certificat de l’utilisateur. Cette approche a l’avantage de minimiser les actions imposées à l’utilisateur lors du lancement de son application. En effet, le certificat d’application sera généré automatiquement à partir de celui de l’utilisateur. L’inconvénient vient justement de cette transparence, le certificat étant généré automatiquement, il sera impossible à l’utilisateur de conserver ce certificat s’il le désire. Pour palier à cette situation, il est possible de spécifier le certificat à utiliser comme certificat d’application. C’est-à-dire le certificat qui servira de certificat racine pour toutes les entités créées par le mécanisme de sécurité. Dans ce cas, on remplace la ligne XML précédente par : application-certificate.p12 89
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 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 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: Section 5.6. Sécurité induite par
Page 105 and 106: Section 5.6. Sécurité induite par
Page 107 and 108: 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 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é

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

Delete template?

Save as template?