5.3 Représentation formelle du modèle de contrôle d’accès
5.3.2 Modélisation de politiques de contrôle d’accès
Une politique est un ensemble de règles. Cela signifie que le modèle de gestion de politique est
principalement basé sur des stratégies de combinaison de règles. Sachant qu’une règle peut avoir
comme effetPermit,DenyouNot-applicable, le modèle de politiques doit pouvoir prendre une
déci-sion vis-à-vis d’une requête sur la base des effets des règles qui composent la politique en question.
Ainsi, comme une règle, l’effet d’une politique prend comme valeursDeny,PermitouNotApplicable.
5.3. Représentation formelle du modèle de contrôle d’accès
Les stratégies de combinaison que nous avons utilisées dans nos modèles de contrôle d’accès
sont Deny-takes-precedence, Permit-takes-precedence, All-Deny, All-Permit, All-NotApplicable.
Cepen-dant, ces stratégies doivent être utilisées selon une certaine discipline. Par conséquent, afin de former
une politique, nous avons procédé avec deux types de regroupement de règles, l’un basé sur tous les
attributs de la cible d’une requête, et l’autre basé uniquement sur le sujet de cette dernière.
5.3.2.1 Patron de politiques basées sur la cible
La première méthode de définition d’une politique est de faire un regroupement de règles en se
basant sur la même cible contenue dans la requête reçue, à savoir : le sujet, l’objet et l’action. Par
conséquent, la politique contient uniquement des règles qui sont applicables sur la requête reçue.
Cette méthode de regroupement par cible est utilisée dans le cas où une ressource appartient à
au moins deux ou plusieurs entités collaboratrices. Il suffit qu’une seule entité revendique l’accès
à la ressource pour que la requête soit rejetée. Cependant, si tous les propriétaires de la ressource
sont d’accord pour accorder l’accès, la requête sera autorisée. Par conséquent, dans cette méthode
de formation de politique, nous opérons les stratégies de combinaison :All-permit et
Deny-takes-precedence.
Le patron générique de politiques basées sur la cible est illustré dans lemodèle 5, dans lequel
les politiques sont référencées par la variablep. Les stratégies de combinaison sont définies à travers
les axiomes(1)pourDeny-takes-precedenceet(2)pourAll-permit. Dans l’axiome(1), pour chaque
politiquep, règleret instantt, il suffit qu’une seule règle appartenant à la politique soit à effetDeny
pour que l’événementDisApprovePolicyse produise à l’égard de cette politique, provoquant ainsi un
effetDeny pour la politique à travers le fluent PolicyDenied. Inversement, l’axiome(1) vérifie que
toutes les règles d’une politique autorisent l’accès à la ressource demandée,i.e., effetPermit.
sort p, r
fluent PolicyPermitted(p) fluent PolicyDenied(p) fluent PolicyNotApplicable(p) event ApprovePolicy(p) event DisApprovePolicy(p) event RejectPolicy(p) predicate PolicyHasRules(p,r)
∀p, time: Initiates (ApprovePolicy(p), PolicyPermitted(p), time).
∀p, time: Initiates (DisApprovePolicy(p), PolicyDenied(p), time).
∀p, time: Initiates (RejectPolicy(p), PolicyNotApplicable(p), time).
#Combination strategy : Deny-takes-precedence
∀ p, r, time : Happens(DisApprovePolicy(p),time) → ∃r : PolicyHasRules(p,r)∧ Hold-sAt(RuleDenied(r),time). ...(1)
#Combination strategy : All-permit
∀ p, r, time : Happens(ApprovePolicy(p),time) ∧ PolicyHasRules(p,r) → Hold-sAt(RulePermitted(r),time). ...(2)
∀ p: ¬HoldsAt (PolicyPermitted(p),0).
∀ p: ¬HoldsAt (PolicyDenied(p),0).
Chapitre 5. Contrôle d’accès
5.3.2.2 Patron de politiques basées sur le sujet
Dans cette méthode, les politiques sont formées à base des règles concernant le même sujet, à
savoir le sujet de la requête reçue. Par conséquent, on peut trouver dans la politique des règles qui
ne sont pas applicables sur la requête en question. Cette manière de définir des politiques consiste
à trouver au moins une règle dans l’ensemble permettant d’accréditer ou non le sujet en question.
Cette méthode se base sur l’hypothèse qu’il ne peut pas y avoir deux règles avec les mêmes cibles et
de types différents. En revanche, si aucune règle n’est applicable sur la ressource en question avec
l’action désirée, l’effet de la politique seraNot-Applicable. Par conséquent, nous procédons au moyen
des stratégies(permit/deny)-takes-precedenceavec All-NotApplicable. Ces stratégies de combinaison
sont ainsi choisies pour ce genre de politiques afin d’éviter les éventuels conflits de combinaison.
En effet, si les stratégies Deny-overrides, All-permit avec All-NotApplicable sont utilisées ensemble,
on aura une incohérence dans le cas où une règle qui satisfait la cible est permise, et que dans la
politique il existe certaines règles qui ne sont pas applicables.
La modélisation de ce type de politiques basées sur le sujet est illustrée dans lemodèle 6. Les
stratégiesDeny-takes-precedenceetPermit-takes-precedencesont mises en place respectivement à
tra-vers les axiomes(1)et(2)de préconditions de l’événementDisApprovePolicyetApprovePolicy. Quant
à l’axiome(3), il vérifie si toutes les règles de la politique ne s’appliquent pas à la cible de la requête
reçue afin d’ignorer la politique en rendant l’effetPolicyNot-applicable.
sort p, r
fluent PolicyPermitted(p) fluent PolicyDenied(p) fluent PolicyNotApplicable(p) event ApprovePolicy(p) event DisApprovePolicy(p) event RejectPolicy(p) predicate PolicyHasRules(p,r)
∀ p, time: Initiates (ApprovePolicy(p), PolicyPermitted(p), time).
∀ p, time: Initiates (DisApprovePolicy(p), PolicyDenied(p), time).
∀ p, time: Initiates (RejectPolicy(p), PolicyNotApplicable(p), time).
#Combination strategy : Deny-takes-precedence:
∀ p, r, time : Happens(DisApprovePolicy(p), time)→ ∃ r: PolicyHasRules(p,r)∧ Hold-sAt(RuleDenied(r), time). ...(1)
#Combination strategy : Permit-takes-precedence:
∀ p, r, time: Happens(ApprovePolicy(p), time)→
∃r: PolicyHasRules(p,r)∧HoldsAt(RulePermitted(r),t). ...(2)
#Combination strategy : All-NotApplicable:
∀ p, r, time : Happens(RejectPolicy(p), time) ∧ PolicyHasRules(p,r) → Hold-sAt(RuleNotApplicable(r), time). ...(3)
∀ p: ¬HoldsAt(PolicyPermitted(p),0).
∀ p: ¬HoldsAt(PolicyDenied(p),0).
∀ p: ¬HoldsAt (PolicyNotApplicable(p),0).
Modèle 6 (Modèle de politique : regroupement par sujet)
À la fin des deux modèles de politiques, nous initialisons les fluents correspondant aux différents
effets de la politique, à savoirPermited,DeniedouNotApplicable.
5.3. Représentation formelle du modèle de contrôle d’accès
5.3.2.3 Instance et évaluation de politique
Pour définir une instance de politique, nous avons utilisé le prédicatPolicyHasRule qui spécifie
quelles règles rentrent sous la sphère de quelle politique. Ainsi, nous avons défini (conformément
à l’exemple de motivation) la politique concernant la candidature deJessy, qui doit envoyer sonCV
à Jamespour lecture. Nous avons appelé cette politique JessyApplication. Nous avons conçu cette
politique avec les deux méthodes de combinaison, à savoir : cible et sujet. Lemodèle 7montre une
instance de politique basée sur des règles ayant la même cible (Sujet/Objet/Action) que la requête
reçue, à savoir :James/CV_Jessy.pdf/Read.
policy JessyApplication
PolicyHasRule(JessyApplication, RuleJessy). PolicyHasRule(JessyApplication, RuleBob). PolicyHasRule(JessyApplication, RuleAlice).
Modèle 7 (Policy (Target) specification)
Cette politique est composée de trois règles,RuleJessy, RuleBob, RuleAlicequi sont définies
res-pectivement par :Jessy, Bobet Alice. Dans leurs règles,Jessyet Aliceautorisent Jamesà lire leCV
deJessy,i.e.,les deux règles sont de typesPermission. Cependant,Bob, l’encadrant deJessy,
reven-dique l’accès (pour une raison donnée) via sa règle qui est de typeInterdiction. Quand on invoque le
raisonneur pour ce patron, il donne les résultats qui apparaissent dans lasolution 3.
t0 ... Happens(ApproveRule(RuleJessy), 0). Happens(ApproveRule(RuleAlice), 0). Happens(DisApproveRule(RuleBob), 0). t1 +RulePermitted(RuleJessy). +RulePermitted(RuleAlice). +RuleDenied(RuleBob). Happens(DisApprovePolicy(JessyApplication), 1). t2 +PolicyDenied(JessyApplication).
Solution 3 (Résultats d’évaluation de politique (Target) par Dec-Reasoner)
Le Modèle 8 illustre une instance de politique basée sur le même sujet. Dans l’ensemble des
règles qui composent cette politique, seule la règle définie parJessys’applique sur la requête reçue,
et approuve par ailleurs cette demande d’accès. Le résultat duDec-Reasonerfigure dans lasolution 4.
Il est à noter que dans la solution décrite par le raisonneurDec-Reasoner, le signe moins (-) précédant
un fluent signifie sa valeur estfaux, le signe (+) signifie que la valeur du fluent estvrai.
Chapitre 5. Contrôle d’accès
policy JessyApplication PolicyHasRule(JessyApplication, RuleEve). PolicyHasRule(JessyApplication, RuleWalter). PolicyHasRule(JessyApplication, RuleNestor). PolicyHasRule(JessyApplication, RuleJessy). PolicyHasRule(JessyApplication, RuleMatilda).Modèle 8 (Policy (sujet) specification)
Le résultat du raisonnement est le suivant :
t0 ... Happens(Mismatch(RuleEve), 0). Happens(Mismatch(RuleWalter), 0). Happens(Mismatch(RuleNestor), 0). Happens(Match(RuleJessy), 0). Happens(Mismatch(RuleMatilda), 0). t1 -RuleTargetHolds(RuleEve). -RuleTargetHolds(RuleWalter). -RuleTargetHolds(RuleNestor). +RuleTargetHolds(RuleJessy). -RuleTargetHolds(RuleMatilda). t2 Happens(RejectRule(RuleEve), 2). Happens(RejectRule(RuleWalter), 2). Happens(RejectRule(RuleNestor), 2). Happens(ApproveRule(RuleJessy), 2). Happens(RejectRule(RuleMatilda), 2). t3 +RuleNotApplicable(RuleEve). +RuleNotApplicable(RuleWalter). +RuleNotApplicable(RuleNestor). +RulePermitted(RuleJessy). +RuleNotApplicable(RuleMatilda). t4 Happens(ApprovePolicy(JessyApplication), 4). t5 +PolicyPermitted(JessyApplication).
Solution 4 (Résultats d’évaluation de politique (Sujet) par Dec-Reasoner)