Réalisation du module de vérification de la politique de sécurité

By 1 March 2013

8.3 Réalisation du module de vérification

À la date de rédaction de ce manuscrit, nous réalisons les classes de vérification de politique proposées dans le cadre de l’application JavaHBAC [58] en utilisant les packages de vérification de modèles Automaton et JavaBDD, disponibles en ligne.

Une autre ébauche du module de vérification de la politique de sécurité est réalisée dans le cadre du stage de Master de recherche de Nancy Betancourt [7]. La vérification de la politique dans cette approche se base sur le problème de la satisfaction des formules logiques. L’implémentation utilise le solver MiniSAT développé par Niklas Eén et Niklas Soresson [21]. Cette implémentation doit encore être améliorée pour pouvoir être utilisable.

8.4 Calcul du risque

Ce module est développé sous la forme d’une classe Java (RiskManager.java ) qui implante l’algorithme de calcul du risque que nous avons présenté au chapitre 7. Ce calcul prend comme paramètres d’entrée l’historique de l’entité et les informations échangées lors de la phase de négociation et fournit comme résultat l’évaluation du risque sous la forme d’un événement. Une partie du code source de ce composant est présentée en annexe.

8.5 Interface et protocole de négociation

Le protocole assure les communications entre deux parties en négociation. Il utilise les sockets pour transférer les informations sur le réseau.

Le client et le vendeur, les deux parties en négociation, sont deux programmes :

le client et le serveur respectivement échangent leurs messages sous un format standardisé. Quand le programme (client ou serveur ) reçoit un message, il le transmet au module Event Analyzer pour que le message soit transformé en événement. Ensuite, cet événement sera transmis comme paramètre à l’Agent de Négociation pour réaliser la négociation.

8.5.1 Échanges

Les échanges sont réalisés de façon continue entre les deux programmes.

-Le client envoie un message au serveur, et quand le serveur le reçoit, il appelle la méthode process() (côté serveur) de l’agent de négociation, pour savoir comment réagir;
-le serveur envoie un message au client et quand le client le reçoit, il appelle lui aussi la méthode process (côté client) de l’agent de négociation.

Les messages d’échange sont de types différents : proposition, négociation, rejet et conclusion qui sont décrits dans la section suivante. Ce processus continu jusqu’à ce que l’une des deux parties échange un message de type conclusion qui indique la fin de la négociation. Le squelette des programmes client et serveur est fourni dans l’annexe B.

8.5.2 Event Analyzer

Cette classe traite les transformations des événements en message et réciproquement. Un message d’entrée est transformé en événement pour être utilisé dans l’agent de négociation. À l’inverse, la réponse de l’agent de négociation est transformée en message pour permettre l’échange avec l’autre partie à travers le protocole.

public class EventAnalyzer{
{
String eventname[]; // tableau des événements Message msg_list[]; // liste de messages String event; // evennt
Message msg;
public EventAnayze() {};
public Message EventToMessage(String event){return msg;}
public Event MessageToEvent(Message msg){return event;}
}

8.5.3 Structure des messages

Comme indiqué, nous avons besoin d’un format précis pour les messages échangés par ce protocole. Le message se compose des informations suivantes : un identifiant du message, le type du message, l’événement équivalent et les données échangées. Nous définissons une classe qui permet de stocker ces informations et qui offre les traitements (méthodes) nécessaires à leur utilisation.

public class Message implements Serializable

{
int ident; //identifiant du msg int type; //type du message
String event //événement équivalent
String data; //données échangées
};

La spécification détaillée de cette classe est donnée dans l’Annexe B.

8.6 Agent de négociation

Ce module traite les échanges de négociation en terme d’événements. C’est un processus parallèle au protocole d’échange. Nous abordons ici les classes principales intégrées à ce module.

8.6.1 Processus de négociation

Cette classe (AgentNegotiation.java) gère tout au long de son déroulement le processus de négociation. L’Agent réalise les traitements suivants :
-À chaque étape, il prend comme paramêtre l’événement, transformé à partir du message échangé, pour effectuer la négociation de l’étape courante, en créant un nouvel objet de la classe Étape de négociation
-Le processus continue ainsi jusqu’à ce qu’il ait reçu un événement, ou qu’il propose un événement, qui corresponde à un message de type conclusion, ce qui indique la fin de la négociation.

Le détail de la classe se trouve dans l’annexe B.

8.6.2 Étape de négociation

Cette classe traite la négociation à chaque étape du processus. Quand l’entité reçoit un événement spécifiant une proposition du partenaire, elle a besoin de l’analyser pour donner une proposition, une négociation, un rejet ou une conclusion correspondant. Les opérations suivantes sont traitées dans la classe.

-Calculer EC , l’ensemble des événements candidats à partir de la structure d’événements. Ce traitement appellera la procédure de vérification de la politique, les classes du module de Vérification.
-Appliquer la stratégie (Strategy ) pour déterminer avec quel événement réagir.
-Envoyer l’événement à la classe « Protocole et Interface » pour construire les messages à échanger.

Le squelette général de cette classe est donné dans l’annexe B.

8.6.3 Stratégie de négociation

À chaque étape de la négociation, quand l’entité a un ensemble d’événements candidats EC avec lesquels elle peut réagir, elle applique sa stratégie pour choisir le meilleur événement. Le fonctionnement de cette classe est basé sur l’algorithme StrategieNegociation que nous avons présenté dans le chapitre 6. L’algorithme utilise le poids de la causalité des événements candidats, l’événement ayant un poids le plus faible est choisi.

8.6.4 Historique

L’historique des transactions est important pour la négociation. C’est un ensemble de configurations où chacune d’elle contient l’ensemble des événements correspondant à une session (une transaction). Nous avons besoin de stocker l’historique de chaque session pour que l’entité puisse s’en servir lors des négociations qu’elle effectuera ultérieurement.

En terme de structure et de données manipulées pour représenter l’historique, nous choisissons dans notre implémentation le format XML pour les stocker. Un description de ce format XML est donné dans l’annexe A.

8.7 Synthèse

Dans ce chapitre, nous avons présenté la structure de l’implémentation de notre prototype de négociation, en utilisant le modèle de négociation présenté au chapitre 6. Le prototype actuel est en cours de réécriture pour obtenir une version complète.

Lire le mémoire complet ==> <(a title="Infrastructure de gestion de la confiance sur Internet " href="http://blog.wikimemoires.com/2013/02/infrastructure-de-gestion-de-la-confiance-sur-internet/">Infrastructure de gestion de la confiance sur Internet )
Thèse pour obtenir le grade de Docteur – Spécialité : Informatique
École Nationale Supérieure des Mines de Saint-Étienne