Dr. Lilia SFAXI
Sécurité des ���Systèmes Répartis Partie III : CIF et DCIF
Doctorants ETIC, Ecole Polytechnique de Tunisie 2014
Modèle de Représentation des ���Systèmes Répartis
Besoin d’un modèle de représentation des systèmes répartis qui soit : Flexible Modulaire Configurable à la compilation et à l’exécution Offre une séparation nette entre l’architecture et le comportement de l’application ���
2
SYSTÈMES À BASE DE COMPOSANTS CIF et DCIF
3
CBSE : Ingénierie Logicielle���à Base de Composants CBSE (Component-based Software Engineering)
Représentation du système sous forme d’interconnexion de composants Favorise la séparation des préoccupations (separation of concerns)
Composant : Unité de composition Assemblé avec d’autres composants Peut être déployée indépendamment des autres
4
Composant D’après [Broy98] : Les composants sont des entités
qui doivent : Encapsuler les données Être implantables dans la plupart des langages de programmation Être hiérarchiquement entrelacés Avoir des interfaces clairement définies Pouvoir être incorporés dans des canevas (frameworks)
5
Composant Composé de :
Attributs : Interfaces de configuration Ports : Principalement 2 types:
Ports Serveurs : Reçoivent des requêtes d’autres composants Ports Clients : Émettent des messages vers d’autres composants
Liaisons : Permettent de relier les différents composants
6
C1
C3
C2
C_parent
Composant Un composant peut être hiérarchique
7
C C1
C3
C2
CBSE Représentation orientée composants
Séparation de l’architecture du système et de son implémentation
Architecture : Utilisation du Langage de Description d’Architecture (ADL)
Implémentation : Utilisation d’un langage impératif (Java par exemple)
8
CBSE : Avantages • Couplage faible
Composants intégrés sans besoin de savoir que font les autres
• Flexibilité Composant peuvent être facilement remplacés par d’autres
• Composition
• Hétérogénéité Possible de combiner plusieurs langages d’implémentation, et mécanismes de communication
9
Exemples de Modèles à base de Composants���Fractal Définition du terme « Fractale » « Forme géométrique de forme irrégulière ou fragmentée qui
peut être découpée en parties, chacune d’elles étant approximativement une copie de taille réduite du tout » Mandelbrot 1982
10
Exemples de Modèles à base de Composants���Fractal Réalisé par INRIA et l’unité R&D de France Telecom
en Juin 2002 Modèle à base de composants modulaire et
extensible pour la construction de systèmes répartis hautement adaptables et reconfigurables
Terminologie Composant Interface Liaison
11
Exemples de Modèles à base de Composants���Fractal : Composant Entité de conception (compile-time) et d’exécution(run-time)
Modèle de type et d’instance
Encapsulation de données et comportement
Composé de : Contenu : ensemble fini de sous-composants Membrane : contrôleur contenant l’ensemble des interfaces et permettant de gérer les sous-composants
Modèle hiérarchique Composant composite Composant primitif
12
Exemples de Modèles à base de Composants���Fractal : Interface Point d’accès à un composant Interne vs Externe
Interface interne : accessible à partir des sous-composants Interface externe : accessible à partir de l’extérieur du composant
Métier vs Contrôle Interface métier : fonctionnalité fournie ou requise du composant Interface de contrôle : aspect non-fonctionnel, permettant la configuration ou l’introspection du composant
Interfaces de contrôle prédéfinies dans Fractal
Client vs Serveur Interface client : services requis Interface serveur : services fournis
13
Exemples de Modèles à base de Composants���Fractal : Liaison (Binding) Chemin de communication entre composants Explicite les dépendances entre composants Manipulable à l’exécution : reconfiguration dynamique 2 types :
Primitive Entre interface client et interface serveur Une interface client peut être liée au plus à une interface serveur Une interface serveur peut être liée à une ou plusieurs interfaces client
Composite Ensemble de liaisons primitives et de composants de communication
14
Exemples de Modèles à base de Composants���Fractal : Exemple
15
Client Serveur
CC BC LC
BC AC
m m s s
LifecycleController Démarrage/arrêt du
composant
BindingController Gestion des liaisons
entre les composants
ContentController Contrôle du contenu
d’un composite
AttributeController Contrôle des attributs
du composant
Interface serveur
Interface client Binding
Exemples de Modèles à base de Composants���Fractal : Exemple d’ADL
16
Exemples de Modèles à base de Composants���SCA : Service Component Architecture Produit d’un effor t conjugué entre plusieurs
entreprises (IBM, Oracle, Sun…)
Standard OASIS
Ensemble de spécifications
Permet de simplifier la création, implémentation et déploiement de services dans l’architecture SOA en f a i s an t abs t r ac t ion des dé ta i l s de communication sous-jacente
17
Exemples de Modèles à base de Composants���SCA : Service Component Architecture Entité principale : Composant
Instance d’une implémentation configurée Offre des services à d’autres composants Requiert des références à partir d’autres composants Définit des propriétés Communique avec les autres composants via des liaisons, de différents types : Web service binding JMS binding EJB Session Bean binding “SCA Binding” (liaison par défaut)
Propose plusieurs implémentations, dont: Tuscany : implémentation de référence de SCA Frascati
18
Exemples de Modèles à base de Composants���SCA : Politiques Dans SCA, les politiques représentent les aspects non
fonctionnels de l’application Recueil de données (logging) Supervision (monitoring) Sécurité
Définies dans le fichier definitions.xml Représentés sous forme de :
Intentions (Intents) : besoins abstraits des composants, services et références Paramètres de politiques (Policy Sets) : caractéristiques énoncées dans les intents en appliquent des politiques particulières à un composant ou à une liaison d’un service ou d’une référence, tout en spécifiant les détails techniques.
19
Exemples de Modèles à base de Composants���SCA : Exemple
20
Propriété
Service
Référence
Liaison
Exemples de Modèles à base de Composants���SCA : Exemple d’ADL
21
Besoins : Non-Interférence dans les Systèmes Répartis Besoin d’une solution qui :
Configure la politique de sécurité à un haut niveau d’abstraction Applique le CFI à un niveau de granularité fin Ne requiert pas d’expertise particulière en langages typés sécurité Offre la possibilité de relaxer la propriété de non-interférence Sépare les contraintes fonctionnelles des contraintes de sécurité Propose une solution pour les modules patrimoniaux Soit applicable aux systèmes répartis réels
Soit applicable dynamiquement, peu de surcoût en terme de performances
22
CIF : Component Information Flow
DCIF : Distributed Component Information Flow
CIF : COMPONENT INFORMATION FLOW CIF et DCIF
23
CIF Intergiciel (Middleware) pour la construction de systèmes répartis non-
interférents
Offre un modèle et un ensemble d’outils
S’applique aux systèmes répartis à base de composants Applications Réparties
Sys. Exp. Sys. Exp. Sys. Exp.
Noyau Noyau Noyau
Réseau
OUTILS CIF
CIF���Configuration de Sécurité
Étiquettes de sécurité au niveau des : Ports Attributs
Capacités (capabilities) : Besoins de rétrogradation
25
C2 C1
M
P1
P2
{S1 ; I1}
{S2 ; I2}
{Sm ; Im} C
CIF���Configuration de Sécurité
Exemple ADL SCA
<composite name = "C"> <component name = "C1">
<reference name = "P1" target = "C2/P2 "> <interface.java interface = "pack.PItf"/> </reference> <property name="M"> Hello World! </property> <implementation.java class="pack.C1Impl"/>
</component> <component name = "C2">
<service name = "P2"> <interface.java interface = "pack.PItf"/> </reference> <implementation.java class="pack.C2Impl"/>
</component> </composite>
Exemple Policy <policy targetComposite= "C">
<component name = "C1"> <port name= "P1" label= "{S1;I1}"/> <attribute name= "M" label= "{Sm;Im}"/> <capabilities> <capability> cap1 </capability> </capabilities> </component> <component name = "C2"> <port name= "P2" label= "{S2;I2}"/> </component>
</policy>
26
C2 C1
M
P1
P2
{S1 ; I1}
{S2 ; I2}
{Sm ; Im} C
CIF���Non-Interférence
La propriété de non-interférence doit être vérifiée à deux niveaux : Entre les composants (Inter-Component Verification) À l'intérieur de chaque composant (Intra-Component Verification)
27
C2 C1
M
P1
P2
{S1 ; I1}
{S2 ; I2}
{Sm ; Im} C
CIF���Sécurité Intra-Composant Propagation de l’étiquette de sécurité dans l’implémentation de chaque
composant
Distinction entre deux types d’étiquettes : Etiquettes immuables : Etiquettes des ports et attributs, attribuées dans le fichier Policy Etiquettes générées : Etiquettes intermédiaires déterminées par le compilateur
⇒ Le flux d’information entre les entités Java doit être non-interférent
28
Exemple Implémentation package security; class C1 implements StartItf{ String {Sm;Im} message; SendItf {S;I} p;
public void start() { String{Sint;Iint} messageSent = "Hello " + message; p.send(messageSent); } }
C1
M {Sm ; Im}
P {S ; I} Start { }
CIF���Sécurité Inter-Composant Sémantiquement, si l (C1.P1) = {S1 ; I1} et l (C2.P2) = {S2 ;I2}
Confidentialité C1 : Je veux que le message envoyé à travers P1 garde au moins le niveau de confidentialité S1 C2 : Je garantis la protection du message reçu à travers P2 si son niveau de confidentialité est S2
Intégrité C1 : Je garantis que le niveau d’intégrité du message envoyé à travers P1 est au moins I1 C2 : Je veux que le message reçu par P2 ait au moins l’intégrité I2
29
C2 C1
P1 {S1 ; I1}
P2 {S2 ; I2}
M {Sm ; Im} C
CIF���Sécurité Inter-Composant La vérification inter-composant assure que :
1. Le flux d’information entre les composants est non-interférent Pour chaque liaison, vérifier que :
l (portClient) ⊆ l (portServeur)
2. Les données envoyées sont préservées Inser tion de composants cryptographiques entre les composants fonctionnels
30
C2 C1
C P1 {S1 ; I1}
P2 {S2 ; I2}
M {Sm ; Im}
CIF���CIF Tools Ensemble d’outils
Vérification des contraintes de sécurité à la compilation Génération du code de sécurité
Applications conçues avec un modèle orienté composant qui respecte les conditions suivantes : Utilisation d’un ADL pour la représentation de l’architecture Utilisation d’un langage orienté objet pour la description du comportement
Prototypes appliqués à : Modèle Orienté Composants : SCA et Fractal Modèle d’Etiquettes : DLM et modèle à base de Jetons
Langages utilisés ADL : XML Implémentation : Java 6
31
CIF���CIF Tools : Étapes d'Exécution
32
CIF���Générateur CIForm
CIF Intermediate Format
API en Java décrivant : L’architecture du système Les contraintes de sécurité
Construit à partir des fichiers ADL et Policy avec un analyseur DOM (Java Xerces)
Facilement extensible pour : D’autres modèles orientés composants D’autres modèles d’étiquettes
33
CIF���Générateur CIForm
34
CIF���CIFIntra
35
Utilisation du compilateur Polyglot [Nystrom03]
1. Extraction d’un AST à partir du code de chaque composant 2. Parcours de l’AST grâce à des classes Visiteur 3. Affectation des étiquettes immuables aux attributs et méthodes Java 4. Calcul des étiquettes générées pour les éléments intermédiaires
Dans le cas d’une interférence, appel au composant Contrôleur Quand le composant est jugé non-interférent, son code annoté est
généré
CIF���CIFIntra
36
CIF���CIFIntra : Polyglot
37
Polyglot : Compilateur extensible Réalisé pour créer des extensions à Java Basé sur le principe de visiteurs et de passes Initialement :
Input : code implémenté avec une extension à Java (ex. JIF) Output : Code Java équivalent
CIF exploite Polyglot pour aller dans l’autre sens Input : Code métier en Java Output : Code Java annoté (JIF-like)
CIF���CIFIntra : Visiteurs (1/3)
38
Visiteurs
Classes qui parcourent l’AST (Arbre de Syntaxe Abstraite) pour réaliser les traitements voulus
Chaque visiteur effectue une opération particulière pour vérifier le flux de données Attribution d'étiquettes aux variables locales et méthodes non annotées
Fonctionnement Si le code est non-interférent è Génération du code Java annoté Si une interférence est trouvée, un module contrôleur est appelé Si l’interférence est non voulue, une exception est lancée
CIF���CIFIntra : Visiteurs (2/3)
39
SecureTranslator
StoreLabelled FieldsVisitor
MethodVisitor
LabelMethodWith HighestReturnVisitor
BlockVisitor
SecureTranslator : • Responsable de la génération du code
annoté final • Parse le code initial et lance les autres
visiteurs successivement StoreLabelledFieldsVisitor : Pour chaque attribut de la classe visitée, lui associer le label correspondant dans l’ADL, s’il existe
MethodVisitor / BlockVisitor : Parcourt l’implémentation de chaque méthode/Bloc LabelMethodWithHighestReturnVisitor : Attribue un label aux méthodes non annotées dans l’ADL
CIF���CIFIntra : Visiteurs (3/3)
40
StoreHighAndLowLabelVisitor
SecureTranslator
StoreLabelled FieldsVisitor
MethodVisitor
LabelMethodWith HighestReturnVisitor
BlockVisitor
VerifyLocalVisitor
VerifyHigherThan StoredVisitor
VerifyLowerThan StoredVisitor
StoreHighAndLowLabelVisitor Pour une expression donnée, sauvegarde les labels de plus haut et de plus bas niveau de sécurité VerifyLocalVisitor Vérifie si une affectation à une variable locale est autorisée ou pas
VerifyHigherThanStoredLabelVisitor Pour une étiquette donnée, vérifie que toutes les étiquettes d’une expression donnée sont plus élevées qu'elle VerifyLowerThanStoredLabelVisitor Pour une étiquette donnée, vérifie que toutes les étiquettes d’une expression donnée sont moins élevées qu'elle
Exemple Policy <policy targetComposite= "C"> <component name = "C1">
<port name= "P" label= "{}"/> <port name= "start" label= "{}"/> <attribute name= "M" label= "{a;}"/> <capabilities> <capability> a- </capability> <capability> b+ </capability> </capabilities>
</component> </policy>
CIF���CIFIntra : Exemple
41
Exemple Implémentation
package pack; class C1Impl implements StartItf{
String M; SendItf P;
public void start() { String messageSent = "Hello " + message; P.send(messageSent); }
}
C1
M {a ; }
P { } start { }
Exemple ADL SCA <composite name = "C"> <component name = "C1">
<service name="start"> <interface.java interface = "pack.StartItf"/> </service> <reference name = "P"> <interface.java interface = "pack.PItf"/> </reference> <property name="M"> Alice </property> <implementation.java class="pack.C1Impl"/>
</component> </composite>
Exemple Policy <policy targetComposite= "C"> <component name = "C1">
<port name= "P" label= "{}"/> <port name= "start" label= "{}"/> <attribute name= "M" label= "{a;}"/> <capabilities> <capability> a- </capability> <capability> b+ </capability> </capabilities>
</component> </policy>
CIF���CIFIntra : Exemple
42
C1
M {a ; }
P { } start { }
Exemple ADL SCA <composite name = "C"> <component name = "C1">
<service name="start"> <interface.java interface = "pack.StartItf"/> </service> <reference name = "P"> <interface.java interface = "pack.PItf"/> </reference> <property name="M"> Alice </property> <implementation.java class="pack.C1Impl"/>
</component> </composite>
Elément Type ADL Type Java Label start Service Méthode {} P Reference Attribut {} M Property Attribut {a;}
Exemple Policy <policy targetComposite= "C"> <component name = "C1">
<port name= "P" label= "{}"/> <port name= "start" label= "{}"/> <attribute name= "M" label= "{a;}"/> <capabilities> <capability> a- </capability> <capability> b+ </capability> </capabilities>
</component> </policy>
CIF���CIFIntra : Exemple
43
C1
M {a ; }
P { } start { }
Elément Type ADL Type Java Label start Service Méthode {} P Reference Attribut {} M Property Attribut {a;}
Exemple Implémentation
package pack; class C1Impl implements StartItf{
String {a;} M; SendItf {} P;
public void{} start() { String messageSent = "Hello " + message; P.send(messageSent); }
}
Exemple Policy <policy targetComposite= "C"> <component name = "C1">
<port name= "P" label= "{}"/> <port name= "start" label= "{}"/> <attribute name= "M" label= "{a;}"/> <capabilities> <capability> a- </capability> <capability> b+ </capability> </capabilities>
</component> </policy>
CIF���CIFIntra : Exemple
44
C1
M {a ; }
P { } start { }
Elément Type ADL Type Java Label start Service Méthode {} P Reference Attribut {} M Property Attribut {a;}
Exemple Implémentation
package pack; class C1Impl implements StartItf{
String {a;} M; SendItf {} P;
public void{} start() { String messageSent = "Hello " + M; P.send(messageSent); }
}
Exemple Policy <policy targetComposite= "C"> <component name = "C1">
<port name= "P" label= "{}"/> <port name= "start" label= "{}"/> <attribute name= "M" label= "{a;}"/> <capabilities> <capability> a- </capability> <capability> b+ </capability> </capabilities>
</component> </policy>
CIF���CIFIntra : Exemple
45
C1
M {a ; }
P { } start { }
Elément Type ADL Type Java Label start Service Méthode {} P Reference Attribut {} M Property Attribut {a;}
Exemple Implémentation
package pack; class C1Impl implements StartItf{
String {a;} M; SendItf {} P;
public void{} start() { String{a;} messageSent = "Hello " + M; P.send(messageSent); }
}
Interférence!
CIF���CIFIntra : Contrôleur Module dans CIFIntra Permet de vérifier si la rétrogradation des niveaux de
sécurité d'un élément est autorisée ou pas, en cas d'interférence
Il permet de : Vérifier s'il peut résoudre l'interférence à son niveau (sans faire appel à l'utilisateur) grâce aux capacités du composant Sinon, signaler l'interférence à l'utilisateur, qui aura la possibilité de l'autoriser ou pas
46
Exemple Policy <policy targetComposite= "C"> <component name = "C1">
<port name= "P" label= "{}"/> <port name= "start" label= "{}"/> <attribute name= "M" label= "{a;}"/> <capabilities> <capability> a- </capability> <capability> b+ </capability> </capabilities>
</component> </policy>
CIF���CIFIntra : Exemple
47
C1
M {a ; }
P { } start { }
Elément Type ADL Type Java Label start Service Méthode {} P Reference Attribut {} M Property Attribut {a;}
Exemple Implémentation
package pack; class C1Impl implements StartItf{
String {a;} M; SendItf {} P;
public void{} start() { String{a;} messageSent = "Hello " + M; P.send(messageSent); }
}
Interférence!
CIF���CIFIntra : Liaisons Internes
Cas des composants patrimoniaux (Legacy Components) Comment vérifier la non-interférence intra-composant, si on ne dispose pas du code du composant?
Chaque composant patrimonial doit être accompagné d'un IBA (Internal Bindings Artifact) Représente les liaisons internes d'un composant, sans divulguer son code Liaison interne :
Relation entre les entrées et sorties du composant Une entrée et une sortie d'un composant sont liées ssi il existe un flux d'information entre elles
Le composant est non-interférent ssi pour chaque entrée e et sortie s liées :
l (e) ⊆ l (s)
48
CIF���CIFIntra : Liaisons Internes
49
CIF���CIFInter
50
Vérification du flux d’information entre les composants Si aucune liaison ne présente d’interférence, les générateurs fonctionnels :
1. Insèrent des composants cryptographiques dans l’instance CIForm
2. Génèrent le nouvel ADL fonctionnel 3. Génèrent le code des composants cryptographiques
CIF���CIFInter
51
DCIF : DYNAMIC COMPONENT INFORMATION FLOW
CIF et DCIF
52
DCIF Dynamic Component Information Flow
Canevas orienté composants pour la construction de systèmes distribués sécurisés à la compilation et à l’exécution
Définit deux types de composants : Des composants fonctionnels Des composants de gestion
53
DCIF���Architecture
54
DCIF���Architecture Global Manager
Composite Responsable de la gestion des composants fonctionnels
Factory Gère les mises à jour de l'architecture du système Un composant Factory Global et un composant Factory pour chaque domaine
Security Manager Dispatche les informations entre les composants de sécurité, selon leur type
Key Manager Gestionnaire de clefs cryptographiques
IFC Manager Gestionnaire des flux d'information du système
CryptoManager Gestion des opérations de crypto pour chaque noeud
55
DCIF���Architecture : IFC Manager
56
DCIF���Architecture : IFC Manager
Policy Manager Orchestre les communications dans le IFCM Stocke les certificats IBA et les instances CIForm
Policy Extractor Extrait les informations à partir des fichiers Policy
Label Manager Stocke les étiquettes du système
Controller Prend les décisions de rétrogradation
Intra-Component Verifier Vérification dynamique intra-composant
57
DCIF���Reconfiguration Dynamique
Ajout d’un composant Création d’un CM pour son nœud Policy Extractor extrait les étiquettes du fichier Policy, et les stocke dans le Label Manager Le Intra-component Verifier vérifie le code de ce composant, ou son certificat IBA
Suppression d’un composant La clef du composant est supprimée du Key Manager Les étiquettes de ce composant sont supprimées du Label Manager L’instance CIForm est mise à jour
Remplacement d’un composant Suppression + ajout d’un composant
Migration d’un composant Suppression d’un composant d’un domaine + son ajout dans un autre domaine
58
Références [Broy98] : M. Broy, A. Deimel, et al. "What characterizes a (software) component ?”
Software- Concepts & Tools, 19(1) :49–56, June 1998.
[Nystrom03] : N. Nystrom, M.R. Clarkson, and A.C. Myers. “Polyglot : An extensible compiler framework for Java”. In Proceedings of the 12th International Conference on Compiler Construction, pages 138–152. Springer-Verlag, April 2003.
59