3.3.2 Le modèle de validation
Notre modèle de validation des politiques de
sécurité est représenté par la figure 5 et sa
démarche de validation est décrite par les activités
ci-dessous :
~ [Activité 1] : La première
activité qui a déjà été faite, consistait
à l'analyse et la conception graphique de la politique de
sécurité en utilisant UML.
14
[Activité 2] : La seconde
activité consiste en la génération du fichier XML
correspondant au modèle concret de cette politique de
sécurité. En effet, les diagrammes UML peuvent être
décrits par la syntaxe de XML.
[Activité 3] : La troisième
activité consiste, à partir du fichier XML produit à
l'activité précédente, à générer
toutes les règles de la politique de contrôle d'accès dans
la spécification OrBAC. Toutes ces règles seront sous la forme
Obligation (sous-organisation, rôle, activité, vue, contexte)
ou Permission (sous-organisation, rôle, activité, vue,
contexte) si un contexte existe bien évidemment.
[Activité 4] : La quatrième
consiste à produire les prédicats de ces règles, qui se
présenteront ainsi qu'il suit :
VX E Org, SousOrg(X)
? Contexte(X) = Activit(X,
vue) pour les règles d'Obligations
et
?X E Org, SousOrg(X)
? Contexte(X) = Activit(X,
vue) pour les règles de permissions. Nous devons garder
à l'esprit qu'il peut y avoir des règles qui possèdent
plus d'une activité et voire aucun contexte.
[Activité 5] : La cinquième
activité consiste à produire à partir des
prédicats, un fichier texte des prédicats conforme à la
syntaxe de Prolog.
[Activité 6] :La sixième
activité consiste à exécuter le test de cohérence
sur le fichier produit à l'activité 5 à l'aide de
Prolog.
FIGURE 5 Modèle de validation
Les étapes que nous observons entre ces
activités expriment le passage d'une activité à une autre.
L'étape 1 est la phase de génération du code XML
associé à la modélisation graphique de la politique de
sécurité. L'étape 2 est la phase de prétraitement.
L'étape 3 est la phase de production des règles dans la
spécification OrBAC. L'étape 4 est la phase de dérivation
des prédicats et l'étape 5, la phase de validation des
prédicats. Elle vérifie la cohérence des règles au
sens du calcul des prédicats.
15
3.3.3 Description de quelques activités
Activité 3 : Production des règles de
contrôle d'accès suivant la spécification OrBAC
L'algorithme utilisé pour produire les règles de
contrôle est le suivant :
Algorithme production des règles
Entrée :
Le fichier XML produit à l'activité 2
Sortie :
Le fichier des règles de contrôle d'accès
respectant la spécification OrBAC.
Variable :
~ Package table de hachage des concepts
fondamentaux contenant le nom du concept et un identifiant IDPack
comme clé de hachage.
~ Class table de hachage contenant les
entités appartenant à chaque concept fondamental. Elle contient
le nom de l'entité, l'identifiant du concept fondamentale auquel il
appartient et un identifiant IdClass comme clé de
hachage.
~ Relation table de hachage contenant les
relations entre toutes les entités appartenant à la politique de
sécurité. Elle contient les IdClass des
entités qu'elle relie et un identifiant IdRel comme
clé de hachage.
~ Assoc table de hachage contenant les
relations de type obligation ou permission entre les entités appartenant
à la politique de sécurité. Elle contient le nom de
l'association et un identifiant IdAssoc comme clé de
hachage
Debut:
1. On recherche le nom de la règle dans Assoc
avec Idassoc. On recherche dans Relation
les classes qui lui sont reliées. Cette relation concerne
toujours une classe du package Rôle et du package Activité. Le
Champ IdFrom désigne une classe du package Rôle
et le champ IdEnd, désigne une classe du package
Activité. Le nom de la classe en question est obtenu en faisant une
recherche dans la table de hachage.
2. On cherche dans la table Relation, toutes
les relations qui ont IdFrom comme noeud terminal et les
IdFrom de ces relations sont les Id des classes du package
Org.
3. On cherche en suite dans Relation, toutes
les relations qui ont des IdEnd comme noeud initial et les
IdEnd de ces relations sont les Id des classes du package
Vue.
4. On recherche dans la table Relation les
relations ayant IdFrom équivalent à cet
élément. Les IdEnd de ces relations sont les Id
des classes du package Contexte.
Fin:
16
Activité 4 : Dérivation des
prédicats
Pour transformer les règles obtenues à
l'activité 3 en prédicats, nous devons leur associer un langage
de 1er ordre qui fournira une syntaxe
permettant d'exprimer les instances de ces règles. Chacune de ces
règles contient des symboles extraits d'un vocabulaire particulier
classés en quatre groupes : les symboles de constante, les variables
individuelles, les variables de contexte, les symboles de relation et les
symboles de fonction [12].
~ Les symboles de constante correspondent aux instances de
classes ci-dessus, c'est-à-dire les instances de classe de type
organisation, rôle, sujet, activité, action, vue, objet, contexte.
Nous pouvons par exemple avoir le sujet Boby qui joue le rôle de
maintenancier et donc restaure les systèmes d'exploitation des
ordinateurs personnels en cas de panne. Dans cet exemple on peut donc retrouver
les instances de certaines de ces différentes classes.
~ Les variables individuelles correspondent ici aux sujets ou
utilisateurs qui jouent un rôle dans Org. On va les noter par des lettres
latines majuscules comme X, Y
l'un peut remplacer Boby.
~ Les symboles de relation correspondent ici aux associations.
Nous en avons deux: permission et obligation. Nous utiliserons les
quantificateurs universels ou existentiels pour les interpréter. Les
quantificateurs universels correspondront au symbole de relation obligation et
les quantificateurs existentiels correspondront au symbole de relation
permission.
~ Les symboles de fonction correspondent aux formules
atomiques des règles ci-dessus telles que Sous-Org correspondant
à une sous-organisation de Org, Cont correspondant à contexte et
Act correspondant à une action. De ce fait, Org
? Cont, Org V
Cont sont des formules. Pour x
une variable individuelle, Vx E
Org et x E Org
sont aussi des formules.
Ainsi, une règle de type Obligation (sous-Org,
Rôle, Activité, Vue, Contexte) produira pour une variable X
de type Rôle et v de type Vue :
VX E Org, Sous
- Org(X) ? Cont(X)
= Act(X, v).
La règle "Les hôtes privés de Org sont
interdits d'accéder à certains sites Internet entre 7h et 16h"
correspondra à l'écriture Obligation (Org, Hôte
privé de Org, accéder à site internet, Internet,
Temps). Pour les propositions :
Time(X) : X travail entre 7h et 16h, SI(X,a) : X accède au
site Internet A, Hpv(X) : X est un hôte privé
On aura la formule :
VX E Org, Hpv(X)
? Time(X) = -iSI(X,
a)
La règle "Les hôtes externes du réseau
public ne peuvent accéder qu'aux serveurs de la DMZ (FTP, DNS, SMTP,
Serveur WEB, Serveur de messagerie...) du réseau" correspondra à
l'écriture
17
Permission (Not-Org, Hôte public, accéder
á un serveur de la DMZ, Serveurs de la DMZ ). Pour les propositions
:
Admz(X,s) : X accède au serveur s de la DMZ du
réseau
Hpb(X) : X est un hôte public
On aura le prédicat :
?X ?/ Org, Hpb(X)
Admz(X, s)
Ce processus de dérivation nous permet de
décrire le XML Schéma suivant afin de
modéliser la politique de sécurité :
| 
