V´erification de la coh´erence

L’analyse s’av`ere tr`es consid´erable dans la mesure o`u elle permet de r´ev´eler des car- act´eristiques importantes du syst`eme mod´elis´e, concernant sa structure et son com-

Tableau 7.2 Fonctions d’accessibilit´e

Fonction Description

Mark. <PageName>’ <PlaceName> N M

Fonction qui retourne l’ensemble des jetons qui se trouve `a la place<PlaceName> de la Neme instance de la page <PageName> du marquage M.

SearchNodes ( <search area>, <predicate function>, <search limit>, <evaluation function>, <start value>, <combination function>)

Fonction qui parcourt tous les noeuds de l’espace des ´etats sp´ecifi´e dans <search area> et applique sur chaque noeud, la fonction <evaluation function>. Les r´esultats de cette op´eration sont combin´es selon <combination function>. La fonction <predicate function> associe chaque noeud `a une valeur bool´eenne et ne conserve que ceux dont la valeur est ´evalu´ee `a true. Pour parcourir tous les noeuds du graphe, on pr´ecise la valeur EntireGraph au niveau de <search area> et la valeur NoLimit au niveau de <search limit> pour poursuivre la recherche de tous les noeuds dont <predicate function> est ´evalu´ee `a true.

List.nth(l,n) Retourne le neme _{´el´ement de la liste l avec 0≤} n < lengthl.

portement dynamique. L’int´erˆet de la mod´elisation est de proc´eder `a la v´erification de propri´et´es sp´ecifiques telles que les propri´et´es de s´ecurit´e. CPNtools offre des fonc- tions d’exploration pour r´ecup´erer les marquages qui r´epondent `a certains crit`eres. Le tableau 7.2 montre un exemple de trois fonctions.

Nous montrons que les r´eseaux de Petri repr´esentent un formalisme intuitif pour aider `a la d´etection des incoh´erences et incompl`etudes dans les r`egles d’une politique de s´ecurit´e RBAC. Les anomalies auxquelles on s’int´eresse peuvent ˆetre exprim´ees par des propri´et´es d’atteignabilit´e pour d´eceler la redondance et l’incompl´etude des r`egles, des propri´et´es de sˆuret´e pour v´erifier l’inconsistance, ou des propri´et´es de vivacit´e pour la pr´esence d’´etats de blocage. Ces anomalies peuvent ˆetre d´etect´ees en proc´edant `a une

analyse du graphe de marquages calcul´e `a partir du r´eseau de Petri mod´elisant la poli- tique RBAC.

Supposons, par exemple, qu’on souhaite v´erifier les r`egles suivantes:

- Deux rˆoles assign´es `a un mˆeme usager ne sont pas en s´eparation statique de tˆaches. - Deux rˆoles en s´eparation dynamique de tˆaches n’appartiennent pas `a l’ensemble des rˆoles actifs d’un mˆeme usager.

- L’ensemble de rˆoles activ´es par un usager est un sous-ensemble des rˆoles auxquels il est autoris´e.

Selon l’exemple courant, ces r`egles se traduisent respectivement par: - u0ne doit pas ˆetre assign´e les rˆoles r1et r2 en mˆeme temps.

- u0ne peut pas activer r1et r2simultan´ement.

- Tous les rˆoles activ´es par u0doivent figur´es dans sa liste de rˆoles autoris´es.

Pour v´erifier si tous les ´etats accessibles sont consistants avec les trois r`egles pr´ec´edentes, nous avons exprim´e chacune des r`egles en fonctions ML tel que repr´esent´e `a la fig- ure 7.12.

La fonction assigned roles retourne la liste des rˆoles autoris´es `a chaque sujet. Chaque ´el´ement de cette liste correspond aux rˆoles autoris´es `a l’usager u0, et ce pour chaque ´etat accessible. La fonction active roles retourne la liste des rˆoles activ´es par l’usager u0, et ce pour chaque ´etat accessible. La fonction authorized roles est ´evalu´ee sur chaque ´etat accessible pour v´erifier si un rˆole `a l’´etat actif est aussi un rˆole autoris´e. La fonction retourne true si cette condition est satisfaite par tout ´etat accessible du mod`ele, et faux sinon. Pour cet exemple, nous obtenons que les ´etats accessibles ne pr´esentent aucune violation avec la sp´ecification initiale.

Dans le cas o`u une r`egle est viol´ee, il est possible de rechercher les causes du probl`eme, par exemple, en examinant de pr`es les ´etats qui ne satisfont pas `a la r`egle et les chemins

Figure 7.12 Model-checking des r`egles de consistence du mod`ele RBAC

menant `a ces ´etats. Cela donnera une id´ee pour localiser la source du probl`eme. Le mod`ele devra ensuite ˆetre modifi´e en cons´equence, et les propri´et´es devront ˆetre rev´erifi´e- es jusqu’`a ce qu’elles soient satisfaites. L’erreur pourrait ´egalement provenir d’une mau- vaise expression des propri´et´es `a partir de la sp´ecification informelle. Dans ce cas, les propri´et´es devront ˆetre r´e´ecrites et rev´erifi´ees de nouveau (Choppy et al., 2007). Si on arrive `a obtenir un mod`ele de r´eseau de Petri color´e avec la plupart des propri´et´es satisfaites, une analyse plus approfondie peut ˆetre effectu´ee, conduisant `a d’´eventuels changements dans la sp´ecification. Une mod´elisation formelle du mod`ele RBAC fournit une description pr´ecise du syst`eme de s´ecurit´e.

7.4 Conclusion

Le mod`ele RBAC se prˆete naturellement `a la protection des syst`emes d’information coop´eratifs qui mettent en oeuvre des techniques de workflow et plus g´en´eralement de groupware (logiciels de groupes compos´es d’op´erations diff´erentes et multiples). De plus, dans plusieurs travaux de recherches (Oren and Haller, 2005), les r´eseaux de Petri se sont av´er´es ad´equats et ont ´et´e utilis´es avec succ`es pour la sp´ecification des appli- cations Workflow et la description de comportements dynamiques complexes. Comme exemple d’application, nous proposons une approche globale, bas´ee sur les r´eseaux de Petri, pour traiter la gestion des autorisations dans les Workflows o`u le mod`ele du Work- flow est greff´ee au mod`ele RBAC. L’id´ee est de repr´esenter les applications du syst`eme Workflow de fac¸on modulaire (sur diff´erents modules) `a l’aide de CPNtools, et grce au mod`ele RBAC, le syst`eme accorde `a un utilisateur l’ensemble des ressources (autori- sations) n´ecessaires pour effectuer une tˆache particuli`ere. Nous expliciterons cette id´ee plus en d´etail dans la section 7.5 du chapitre 7.

En conclusion, nous ajoutons aussi que dans (Rakkay and Boucheneb, 2007), nous avons montr´e qu’une approche `a base des r´eseaux de Petri color´es temporis´es est aussi perti- nente pour la v´erification et la validation des mod`eles `a base `a des rˆoles aussi bien en termes de rigueur que de souplesse. La dimension temporelle est int´eressante `a int´egrer dans le mod`ele, notamment pour pr´evenir l’utilisation abusive des privil`eges d’acc`es. Le mod`ele GTRBAC d´efinit deux types de contraintes temporelles pour capturer le comportement dynamique du syst`eme: les contraintes de dur´ee et les contraintes de p´eriodicit´e.

Les contraintes de p´eriodicit´e sont utilis´ees pour d´efinir des intervalles exacts au cours desquels un rˆole peut ˆetre activ´e (ou d´esactiv´e), ou encore des intervalles au cours desquels des actions d’assignation d’un rˆole `a un usager (ou de privil`eges `a un rˆole) sont

valides. Les contraintes de dur´ee expriment la dur´ee o`u l’assignation (ou l’activation) d’un rˆole est valide ou encore la dur´ee de disponibilit´e d’un le rˆole pour une ´eventuelle activation. Une mani`ere simple pour int´egrer le temps consiste `a ajouter des temporisa- tions qui sont support´ees par l’outil CPNtools. On consid`ere, dans ce cas, une horloge globale et les jetons sont estampill´es par la date `a laquelle ils sont prˆets.