D’autres projets [32, 4, 74, 33, 58] s’int´eressent `a l’int´egration de politiques de s´ecurit´e au sein des
SI. Ces diff´erents projets ´etablissent des comparaisons des mod`eles de politiques de s´ecurit´e. Le
projet ORKA d´efinit unframeworkpermettant de comparer les diff´erents mod`eles de CA. Ce
fra-meworkest d´ecrit dans [5]. Il ´etablit trente-quatre points de comparaison class´es en huit cat´egories.
Dans la suite, nous d´ecrivons les diff´erentes cat´egories avant de proposer un ensemble de crit`eres
inspir´es de ceframework.
La premi`ere cat´egorie concerne la sp´ecification des mod`eles. Cette cat´egorie permet de d´efinir
comment la politique est mod´elis´ee. Les crit`eres de cette cat´egorie permettent de pr´eciser si la
po-litique cible des actions de haut niveau (pr´esentes dans la sp´ecification) ou de bas niveau (pr´esentes
dans l’impl´ementation). Elle s’int´eresse aussi au formalisme utilis´e, en permettant de pr´eciser si
le langage utilis´e est formel, semi-formel, informel ou structur´e. Les diff´erents crit`eres permettent
de d´efinir le domaine applicatif cibl´e par la m´ethode et aussi l’utilisation du mod`ele. L’utilisation
du mod`ele correspond soit `a la v´erification de la politique, l’impl´ementation ou la v´erification en
temps r´eel.
La seconde cat´egorie concerne l’expressivit´e de la politique de CA. Cette cat´egorie concerne
l’ensemble des concepts exprimables dans la politique. Par exemple, elle rend compte du nombre
de niveaux d’abstraction utilis´es (mod´elisation, impl´ementation, . . .), du nombre de concepts de
CA (permission, interdiction, obligation et SoD) qui peuvent ˆetre exprim´es dans la politique. Pour
pouvoir prendre en compte certains concepts de CA dynamiques, la politique de CA doit connaˆıtre
l’´etat desworkflowsdu SI. Cette cat´egorie rend aussi compte de la mani`ere dont les instances des
workflowsdu syst`eme sont repr´esent´ees en m´emoire.
La troisi`eme cat´egorie permet de d´eterminer si un langage utilise des notations graphiques
ou textuelles. Elle permet aussi de d´eterminer si un mod`ele repr´esent´e est compr´ehensible par un
humain. Cette cat´egorie juge aussi de la modularit´e, de la capacit´e d’extension et de la d´efinition
de la s´emantique du langage.
Une autre cat´egorie juge de la mani`ere dont la mod´elisation est impl´ement´ee. Elle permet
de savoir si la m´ethode a pour but d’ˆetre utilis´ee avec un noyau de s´ecurit´e ou d’ˆetre int´egr´ee
dans le syst`eme existant. Dans le cas o`u la m´ethode est utilis´ee avec un noyau de s´ecurit´e, les
crit`eres de cette cat´egorie permettent de savoir si l’impl´ementation du noyau est compatible avec
les notions de point de prise de d´ecision de la politique (PDP) et point de mise en application de la
politique (PEP).
Une cat´egorie concerne la validation et permet de savoir si les m´ethodes de mod´elisation de
politiques de CA permettent de r´ealiser la validation de la politique. Le cas ´ech´eant, elle permet de
r´epertorier les diff´erents outils permettant de r´ealiser du v´erification de mod`eles.
1.6. COMPARAISON
D’autres cat´egories permettent de comparer les mod`eles selon l’administration qu’ils
per-mettent de r´ealiser sur le mod`ele mis en place, la fac¸on dont l’impl´ementation s’adapte aux
syst`emes existant ou encore de la maturit´e de la m´ethode.
Comme nous voulons ´etablir une comparaison des mod`eles pr´ec´edemment pr´esent´es, nous
consid´erons les m´ethodes suivantes :
RBAC : Cette m´ethode n’inclut pas seulement le standard. Nous incluons sous la d´enomination
RBAC l’ensemble des extensions pr´esent´ees : hi´erarchie des rˆoles, contraintes
d’activa-tion des rˆole, contraintes de SSD et DSD. Nous consid´erons secureUML comme une
impl´ementation de cette m´ethode inclus dans ce mod`ele.
SoDA : Dans ce mod`ele nous incluons l’alg`ebre SoDA permettant d’exprimer des contraintes
de SoD. De plus nous incluons aussi un mod`ele RBAC permettant d’exprimer les
per-missions du syst`eme. L’inclusion du mod`ele RBAC est n´ecessaire pour pouvoir consid´erer
l’impl´ementation en CSP de politiques SoDA.
XACML : Nous incluons dans ce mod`ele le standard XACML, le mod`ele ABAC et l’ensemble
des travaux de formalisation pr´esent´es dans la section 1.5.2.3.
OrBAC Nous appelons OrBAC la m´ethode OrBAC ainsi que son impl´ementation [20].
Les crit`eres pr´esents dans [5] sont trop nombreux. Tous ces crit`eres ne sont pas forc´ement
probant pour la comparaison de mod`eles de politiques de s´ecurit´e. Nous d´etaillons ci-apr`es les
crit`eres que nous utilisons pour comparer les diff´erentes m´ethodes.
repr´esentation des workflows : Ce crit`ere permet d’exprimer le fait que la m´ethode permet de
repr´esenter les instances de processus de l’organisation. Ce crit`ere permet de savoir si le
mod`ele peut prendre en compte les contraintes dynamiques de CA.
concepts de CA : Ce crit`ere permet de comparer l’expressivit´e des diff´erentes m´ethodes. En plus
de pr´eciser le nombre de cat´egories de crit`eres pris en consid´eration par la m´ethode, ce crit`ere
d´efinit quels types de contraintes sont pris en compte par la m´ethode.
formalisme : Ce crit`ere permet d’indiquer le formalisme des m´ethodes compar´ees. Le formalisme
utilis´e peut ˆetre formel ou structur´e.
pr´esentation : Ce crit`ere permet de comparer la lisibilit´e des sp´ecifications r´ealis´ees dans le
mod`ele. Par lisibilit´e, nous entendons la repr´esentation des sp´ecifications r´ealis´ees :
gra-phique, textuelle . . .
v´erification Ce crit`ere permet de pr´eciser si les sp´ecifications r´ealis´ees dans la m´ethode peuvent
ˆetre formellement v´erifi´ees ou s’ils peuvent servir `a r´ealiser des preuves.
1.6. COMPARAISON
P
P
P
P
P
P
P
P
P
PP
crit`eres
mod`eles
RBAC SoDA XACML OrBAC
repr´esentation des
workflows
state-based
event-based non
state-based
(1)
concepts
de CA
permissions oui oui oui oui
permissions
avec
contraintes
oui(2) non oui oui
interdictions non non oui oui
interdictions
avec
contraintes
non
pertinent
non
pertinent oui oui
obligations non non
non
pertinent
(3)
oui
SSD oui oui oui oui
DSD oui oui non
pertinent oui
formalisme formel formel structur´e formel
pr´esentation (4) textuelle
(5)
textuelle
(6)
textuelle
(7)
v´erification (8)
v´erification
de
mod`eles
possible
(9)
(10) non(11)
(1) pour exprimer les SoD, lesworkflowssont mod´elis´es `a l’aide de r´eseaux de Petri, avant d’ˆetre
transform´es en contextes. Dans le mod`ele, les workflows ne sont pas repr´esent´es mais des
contextes permettent de savoir si les ´ev´enements n´ecessaires `a la prise de d´ecision ont ´et´e
ex´ecut´es.
(2) seules les contraintes temporelles d’activation des rˆoles peuvent ˆetre exprim´ees.
(3) un m´ecanisme d’exception existe en XACML. Il est d´ecrit dans la section 5.3.1.1.
(4) de nombreux outils et m´ethodes se basent sur la m´ethode RBAC. La description d’une politique
peut se faire par des moyens allant d’un diagramme entit´e relation `a l’´ecriture de fichiers
XML.
(5) la s´emantique et la syntaxe d’une politique en SoDA sont formellement d´ecrits. Dans le cadre
de cette comparaison, le mod`ele est pr´esent´e sous la forme d’un mod`ele CSP.
(6) une politique XACML est d´ecrite `a l’aide de fichiers XML pr´esent´es dans la section 5.3.1.1.
(7) une politique OrBAC se pr´esente sous la forme d’un ensemble de formules logiques.
(8) selon la m´ethode utilis´ee, des techniques de v´erification de mod`eles, de simulation ou de
preuve peuvent ˆetre envisag´ees.
(9) en vue des outils utilis´es, des m´ethodes de v´erification de mod`eles peuvent ˆetre envisag´ees ;
leur utilisation n’a pas ´et´e pr´esent´ee par les auteurs de la m´ethode.
(10) le langage XACML n’est pas formel. Cependant des travaux permettent d’en formaliser un
sous-ensemble et d’effectuer des v´erifications sur ce sous-ensemble.
(11) les probl`emes de conflits sont g´er´es `a l’aide de priorit´es d´efinies dans la politique.
Dans le document
Modélisation de politiques de sécurité à l'aide de méthode de spécifications formelles
(Page 46-51)