Flux d’exécution

Cette section décrit le flux global d’application et d’assurance de la politique de sécurité à travers ses éléments centraux et en se basant sur la figure 5.1. Les modules d’extension, qui ne font pas partie du cœur du SEE, sont décrits à la section 5.2.

5.1.2.1 Gestionnaire de politique

Afin de sécuriser une architecture logicielle, le SEE a besoin de deux éléments : sa configuration interne et la politique de sécurité.

La configuration interne du SEE est prédéfinie mais peut être modifiée par l’expert en sécurité. Elle contient les propriétés, les capacités, ainsi que les mécanismes disponibles et les capacités qui leur sont associées.

5.1. IMPLÉMENTATION DU SEE

La politique de sécurité est définie par l’administrateur de l’architecture logicielle et exprime ses besoins de sécurité. Elle contient les contextes identifiant les ressources (ainsi que leur association) et les propriétés instanciées mettant en jeu ces contextes.

La configuration interne évolue en fonction des résultats d’assurance. En effet, la dé-tection d’un dysfonctionnement d’un mécanisme ou d’un comportement inattendu d’une propriété peut entraîner la désactivation d’un module d’extension ou la réapplication d’une propriété.

Enfin, le module de score calcule et met à jour les scores d’application (initial et réel), le taux de couverture et le taux de couverture des propriétés en fonction des résultats fournis par les moteurs d’application et d’assurance.

5.1.2.2 Moteur d’application

Lorsque le gestionnaire de politique a chargé la configuration et la politique, le moteur d’application peut compiler la politique afin de la projeter sur les mécanismes (phase d’application).

Le moteur de sélection de propriétés est responsable de la première partie du processus d’application (étapes 1 à 3). Il interroge le gestionnaire de politique (étape 2) afin de déterminer quelles propriétés peuvent être utilisées pour appliquer une propriété instanciée (c’est-à-dire déterminer quelles sont les propriétés compatibles). Ce moteur implémente l’algorithme 9 (section 4.4.2, p. 78).

Dans un second temps, le moteur de sélection des mécanismes recherche, pour chaque propriété compatible avec la propriété instanciée, une solution associant des mécanismes aux capacités et maximisant le score d’application de la propriété (étapes 4 à 8). Cette opération implique également des échanges avec le gestionnaire de politique pour savoir quelles capacités peuvent être utilisées (étape 6), quels mécanismes les fournissent (étape 7) et quelles sont leurs contraintes de compatibilité et de dominance. Cette partie implémente l’algorithme 12 (section 4.4.3, p. 80).

Les propriétés instanciées peuvent alors être projetées selon la solution trouvée. Cela correspond à l’algorithme 18 (section 4.4.4, p. 89). Trois étapes se succèdent. Tout d’abord, le moteur d’application projette les propriétés : il contacte les modules d’extension afin d’appliquer les capacités du bloc d’application (étapes 9 à 11). Dans une deuxième phase, le moteur d’application contacte les modules pour appliquer les blocs d’assurance des pro-priétés, ce qui permet de vérifier que les propriétés appliquées ont bien l’effet attendu (étapes 12 et 13). Enfin, pour chaque module qui a été utilisé pour au moins une capacité, le moteur d’application demande la génération de tests d’assurance pour vérifier le statut du mécanisme associé (étapes 14 et 15).

Il est à noter que, tout au long du processus d’application (phases de compilation et de projection) et dès lors que des erreurs sont rencontrées, des informations sont envoyées au moteur d’assurance (étapes A et B).

5.1.2.3 Moteur d’assurance

Le processus d’assurance se décompose en deux étapes principales : le traitement des erreurs relatives à l’application de la politique de sécurité et celui des informations obtenues au cours de l’exécution du système.

Tout d’abord, le moteur d’assurance reçoit et traite les erreurs se produisant lors de l’application de la politique (étapes A et B), en suivant le processus décrit à la section 4.5.2 (p. 92). Le moteur d’assurance obtient ces informations depuis le moteur d’application, ce qui correspond à une erreur lors de la compilation ou de la projection d’une propriété.

Le second cas traité par le moteur d’assurance concerne des erreurs détectées au cours de la vie du système (étapes C). Ces erreurs se produisent alors que la politique a été cor-rectement appliquée et peuvent avoir deux causes : un dysfonctionnement d’un mécanisme (étape D) ou une propriété n’ayant pas l’effet escompté (étape E).

L’ensemble de ces informations est alors interprété afin de mettre à jour la base de connaissances du SEE (étapes F et G). Une telle mise à jour implique une nouvelle pro-jection de la sous-partie de la politique de sécurité ayant rencontré un problème.

5.1.2.4 Moteur de communications

Finalement, pour qu’une application cohérente de la politique de sécurité soit possible, il est nécessaire que les modules d’extension et les SEE puissent communiquer. En effet, les SE^E forment un système multi-agents, ce qui implique qu’ils puissent communiquer entre eux afin de se coordonner et d’échanger des informations. Deux types de communications peuvent se produire : soit la communication s’effectue entre deux modules d’un même SE^E, soit elle fait intervenir des SEE distants. Ces communications se produisent par l’intermédiaire du répertoire partagé du SEE.

Partage de données Des échanges d’informations peuvent se produire lorsque les SEE

ont besoin de partager des données dans le cadre d’une propriété. Par exemple, dans le cas de la propriété de confidentialité réseau, les capacités internes publish et get_published

permettent à deux SEE de partager une clef de chiffrement symétrique (voir propriété P3, section 3.5.2.2). De plus, des communications peuvent être nécessaires entre plusieurs modules d’un même SEE. Ainsi, un module souhaitant utiliser un port peut demander son ouverture à un module de pare-feu : le port à ouvrir est transmis grâce au module de communication.

Ce partage utilise les mêmes capacités internes pour la communication intra et inter-SE^E. Seuls les contextes mis en jeu lors de l’appel à ces capacités indiquent de quel type de communication il s’agit.

Communications intra-SEE Dans le cas de communications intra-SEE, deux types de communications peuvent avoir lieu : les échanges de données et les demandes d’application de capacités supplémentaires.

Les échanges de données se produisent lorsqu’un mécanisme a besoin d’une information générée par un autre mécanisme. Par exemple, un mécanisme fournissant une capacité de chiffrement doit récupérer la localisation de la clef à utiliser. Celle-ci peut avoir été géné-rée par un autre mécanisme et il est donc nécessaire que ces deux mécanismes puissent communiquer. Dans le prototype proposé, cet échange d’information est fait par l’intermé-diaire d’un annuaire local et interne au SEE. Chaque module d’extension peut publier des informations dans cet annuaire (section 3.4.4, p. 51). Ces informations sont à destination d’un seul module et sont associées à la propriété en cours d’application. Par conséquent, l’information ne peut être lue que par le module destinataire et uniquement pendant l’ap-plication de la propriété. Les informations ne peuvent donc pas être récupérées par d’autres modules. L’information stockée par le SEE est de la forme suivante :

(Source, Destination, P ropri´et´e, Inf ormation) où :

– Source et Destination désignent respectivement le module publiant l’information et celui autorisé à la récupérer ;

5.1. IMPLÉMENTATION DU SEE

– Propriété indique quelle propriété demande le partage d’information ; – Information contient les données effectivement partagées.

Ces quatre informations et les données partagées sont représentées sous forme de contexte. En effet, lorsque deux modules d’extension souhaitent partager de l’informa-tion, cela a pour but d’enrichir les contextes mis en jeu par les capacités de la propriété concernée.

Le deuxième type de communications intra-SEE se produit lorsqu’un module demande l’application de capacités supplémentaires. Des capacités supplémentaires peuvent par exemple être demandées dans le cas de mécanismes dépendants. En effet, lorsqu’un mé-canisme M1 dépendant d’un mécanisme M2 est appelé, cette dépendance peut entraîner l’appel à une capacité de M2. Si un tel appel se produit, il faut donc que M1 puisse de-mander au moteur de projection l’application d’une capacité par M2.

Considérons le cas d’un module IPSec dépendant du module Racoon. Alors, lors de l’application de la capacitéencrypt_flow, le module IPSec appelle le module Racoon pour appliquer la capacité create_security_association. Ce type de communications est au-tomatiquement réalisé par le moteur d’application qui, lors de l’application d’une capacité, récupère une valeur de retour contenant deux éléments : une valeur booléenne qui indique si l’application de la capacité a rencontré ou non une erreur et une liste des capacités supplémentaires requises.

Communications inter-SEE Des modules d’extension appartenant à différents SEE

peuvent également avoir besoin de communiquer. Cela se produit lors de l’application de propriétés réseaux impliquant plusieurs nœuds. De telles communications doivent être réalisées de manière sécurisée et elles se font donc en utilisant le réseau administrateur d’OpenStack (la plateforme d’informatique en nuage utilisée dans le cadre de nos expéri-mentations). Si une autre plateforme était utilisée, il faudrait de la même manière que les communications entre SEE aient lieu sur un réseau sécurisé différent du réseau utilisateur ou que les communications entre SEE soient chiffrées et authentifiées.

Des SEE peuvent communiquer dans deux types de situations : lors de l’application de capacités ayant besoin de partager de l’information et lors des phases de négociation pour la projection.

Différentes solutions peuvent être envisagées pour implémenter le partage d’information entre SEE. Dans le cadre de notre prototype, nous utilisons l’annuaire interne des SEE, déjà utilisé pour les communications intra-SEE. Un annuaire global pourrait également être utilisé, mais des annuaires locaux permettent de conserver un système décentralisé. De la même manière que lors des échanges intra-SEE, les informations publiées par un SE^E ne sont visibles que par le SEE destinataire. Ainsi, chaque information publiée est associée à sa source et à son destinataire. La source et le destinataire peuvent être soit un SE^E, soit un module d’extension spécifique d’un SEE : si le destinataire est un module, les autres modules du SEE destinataire n’auront pas accès à l’information publiée. Dans les deux cas, l’information publiée est associée à la propriété ayant publié l’information : en effet, cette information ne sera disponible que pour cette propriété, appliquée sur un nœud distant.

Le deuxième cas de communications inter-SEE se produit lors de l’application de pro-priétés réseaux. En effet, pour appliquer une propriété réseau, une phase de négociation est nécessaire afin de sélectionner des modules compatibles pour chacune des capacités. Cette négociation se fait également sur le réseau dédié aux communications entre SEE.

L’algorithme 25 permet de sélectionner les couples de mécanismes disponibles sur deux nœuds N1 et N2 pour une capacité c.

Algorithme 25 Sélection de modules d’extension compatibles

1: function SelectConsistentPlugin (capacité c, nœud N1, nœud N2) 2: SSM1 TrouverEtOrdonnerSSM(c) sur N1

3: SSM2 TrouverEtOrdonnerSSM(c) sur N2

4: CompN et Matrice de compatibilité réseau .Section 3.4.4 5: listeSSM ;

6: for all mécanisme Midans SSM1 do 7: for all mécanisme Mjdans SSM2 do

8: if Miet Mjsont compatibles (d’après CompNet)then 9: score somme des scores d’ordonnancement de Miet Mj

10: Ajouter (Mi, Mj) à listeSSM selon score 11: end if

12: end for 13: end for

14: return listeSSM 15: end function

Cet algorithme utilise la fonction TrouverEtOrdonnerSSM afin d’obtenir les méca-nismes pouvant appliquer c sur chacun des nœuds considérés (lignes 2 et 3). Puis, il récupère la matrice de compatibilité réseau indiquant quels sont les mécanismes compatibles pour appliquer une même capacité au niveau réseau (ligne 4). Enfin, l’algorithme parcourt les mécanismes disponibles sur N1(lignes 6 à 13) et ceux disponibles sur N2 (lignes 7 à 12) afin de trouver des mécanismes compatibles (ligne 8). Les couples de mécanismes compatibles sont alors ajoutés à la liste de couples possibles (ligne 10) selon la somme de leur score d’ordonnancement (ligne 9). Finalement, cette liste de couples ordonnés est renvoyée par la fonction (ligne 13) et sera utilisée comme un domaine par les algorithmes de recherche de solution.

Grâce à cet algorithme, il est ainsi possible de sélectionner les mécanismes de sécurité de façon à ce que les applications des propriétés réseaux par plusieurs SEE soient compatibles.