4.2 Permissions et interdictions
4.2.1 Permissions
Au sein d’une politique de CA, les permissions correspondent au fait d’autoriser une entit´e `a
r´ealiser une action. EnEB3SEC, les permissions autorisent l’ex´ecution d’une action pour certaines
valeurs des param`etres de s´ecurit´e. Les permissions sont elles-mˆemes divis´ees en deux cat´egories,
les permissions sans contraintes et avec contraintes.
4.2.1.1 Permissions sans contraintes
Une permission sans contraintes correspond `a une permission qui est toujours valide au sein du SI.
Une permission sans contrainte s’exprime enEB3SEC `a l’aide du patron suivant :
1. permission( ),
Ce patron d´efinit pour l’action action ∈ Σsec un ensemble de valeurs pour l’environnement de
s´ecurit´e. Ces valeurs sont exprim´ees `a l’aide de−→p
sec. Dans ce patron,−→p
sec ne peut contenir que des
valeurs constantes ou le caract`ere g´en´erique “ ”.
Il est aussi utile de pouvoir exprimer plusieurs valeurs pour l’environnement de s´ecurit´e
as-soci´ees `a une action dans une mˆeme permission. Pour ce faire, le patron suivant introduit des
variables quantifi´ees :
1. permissionq( ),
2. | −→psec ∈Esec :
3. h−→psec,action( )i
La seconde ligne de ce patron permet d’utiliser l’op´erateur de choix quantifi´e afin de d´efinir les
diff´erentes valeurs que peuvent prendre l’environnement de s´ecurit´e pour que l’actionaction soit
permise. Dans le cas de ce patron,−→p
secne poss`ede que des composantes scalaires ´egales `a l’´el´ement
ou ´etant une des variables quantifi´ees.
Dans la politique de CA donn´ee en exemple, la premi`ere r`egle correspond `a des exemples
typiques de permission. Ces permissions n’autorisent que les personnes ayant le rˆoleguichetieret
conseiller`a pouvoir r´ealiser l’actiondeposer. Ces permissions sont mod´elis´ees s´epar´ement `a l’aide
du premier patron :
1. permission1( ),
2. h , guichetier, , ,deposer( )i
et
1. permission2( ),
2. h , conseiller, , ,deposer( )i
Le second patron peut aussi ˆetre utilis´e pour mod´eliser les deux permissions pr´ec´edentes en
une seule expression :
1. permissionq1( ),
4.2. PERMISSIONS ET INTERDICTIONS
4.2.1.2 Equivalence entre les permissions du diagramme de classes et les expressions obte-´
nues `a l’aide des patrons de permission
Le patron de conception correspondant aux permissions sans contraintes peut ˆetre utilis´e `a la place
de l’´el´ementhr, o, idEvt(evt)i ∈permissiondu pr´edicat statique. Dans l’exemplepermissionq1,
les environnements de s´ecurit´e ne pr´ecisent que le rˆole utilis´e. Cependant la seconde ligne
du pr´edicat statique peut aussi ˆetre remplac´ee par des expressions de processus. En effet, les
diff´erentes valeurs possibles des param`etres de s´ecurit´e peuvent ˆetre pr´ecis´ees dans l’expression
de processus. Pour reprendre l’exemple de la figure 3.3, on peut utiliser l’expression de processus
suivante :
1. exemple( ),
2. hcatherine, directeur, M ontreal, ,creer client( )i
3. | hcatherine, directeur, M ontreal, ,modifier nom( , )i
4. | . . .
Un mod`ele de s´ecurit´e de style RBAC peut aussi ˆetre utilis´e. Dans ce cas, les param`etres de s´ecurit´e
sont au nombre de deux et correspondent `a l’utilisateur et le rˆole qu’il peut jouer.
4.2.1.3 Permissions avec contraintes
Les permissions avec contraintes sont des permissions qui ne sont pas toujours applicables dans
le syst`eme. La contrainte associ´ee `a la permission permet de restreindre leur champs d’application
`a la valeur d’un pr´edicat bool´een d´efini sur les variables du syst`eme (les attributs du diagramme
de classes de la partie fonctionnelle, les attributs du diagramme de classes de la politique de CA)
et les param`etres de l’action. Pour que la permission puisse ˆetre effective, la contrainte doit ˆetre
´evalu´ee `a vraie. Les permissions avec contraintes sont mod´elis´ees en EB3SEC `a l’aide du patron
suivant :
1. permissionc( ),
2. | −−→pf onc∈Ef onc :
3. contr(−→p
sec,−−→p
f onc) =⇒ h−→psec,action(−−→p
Deux nouvelles notations sont introduites dans ce patron. Le pr´edicat contr(−→x
1, . . . ,−x→
n)
corres-pond `a une contrainte, c’est-`a-dire une fonction `a valeur bool´eenne d´efinie sur les ´el´ements utilis´es
dans −→p
sec et −−→p
f onc. La garde utilis´ee `a la ligne 3. permet d’assujettir la validit´e de la permission
`a la valeur de la garde. Le vecteur−−→p
f onc permet de repr´esenter les variables fonctionnelles du SI
n´ecessaires `a l’expression de la permission avec contraintes. Dans ce patron seules les variables
fonctionnelles (i.e.−−→p
f onc) sont quantifi´ees,−→p
sec, repr´esentant les param`etres de s´ecurit´e, ne contient
que des constantes ou des caract`eres g´en´eriques. La syntaxe des contraintes est la mˆeme que pour
l’entit´e Contrainte du diagramme de classe de s´ecurit´e. Les contraintes correspondent `a une
for-mule logique du premier ordre pouvant utiliser toutes les constantes et les variables pr´esentes dans
l’expression de processus.
Comme pour les permissions sans contraintes, les param`etres de s´ecurit´e peuvent aussi ˆetre
quantifi´es de mani`ere `a regrouper plusieurs r`egles au sein d’une mˆeme expression. Le patron
sui-vant est alors utilis´e dans ce cas :
1. permissionc,q( ),
2. | −−→pf onc,−→p
sec ∈Ef onc×Esec :
3. contr(−→p
sec,−−→p
f onc) =⇒ h−→psec,action(−−→p
f onc)i
Dans ce patron, les variables fonctionnelles (i.e. −−→p
f onc) et les param`etres de s´ecurit´e (i.e. −→p
sec)
peuvent ˆetre des variables quantifi´ees.
La r`egle r`egle 7 correspond `a une permission sous contraintes. Elle autorise les personnes
ayant le rˆole deconseiller `a r´ealiser l’actionverifierpour les ch`eques d’un certain montant. Elle se
mod´elise par :
1. permissionc,q1 ( ),
2. |c∈cId : |o ∈oId :
3. Cheque(c).montant > Organisation(o).limite
4.2. PERMISSIONS ET INTERDICTIONS
Dans le document
Modélisation de politiques de sécurité à l'aide de méthode de spécifications formelles
(Page 80-84)