Modèles de sécurité

     

Alice, Bob, Charlie : → Subject file : Nat → Object

zero : → Nat

succ : Nat → Nat

et P est composé des symboles d’actions read et write de profil Subject × Object. L’atome read(Alice, file(succ(zero))) décrit l’action correspondant à la lecture du fichier identifié par le nombre 1 (symbolisé par succ(zero)) par Alice.

3.1.2 Modèles de sécurité

Comme nous l’avons déjà indiqué, les modèles de sécurité spécifient les méca-nismes à implanter dans le système pour garantir les propriétés de sécurité désirées (confidentialité, intégrité, . . . ). Dans le cadre proposé, le modèle de sécurité décrit les structures qui lui sont spécifiques, les règles permettant de calculer les autorisations ainsi que la forme des configurations « acceptables ». La définition suivante précède une explication des différents choix qui sont exprimés dans cette dernière.

Définition 3.3.Un modèle de sécurité mod sur une signature de sécurité ˜Σ = (S, F, P) est la donnée de :

1. On rappelle (définition 2.82) que la notation Σ est utilisée pour les signatures « fonctionnelles » (c.-à-d. sans prédicat) tandis que ˜Σ dénote une signature « logique » (c.-à-d. avec symboles de prédicats). Lorsqu’une signature logique ˜Σ = (S, F , P) est définie, alors Σ réfère à (S, F ).

• une extension de Σ notée ˜Σmod= (S ∪ Smod,F ∪ Fmod,Pmod)telle que : 1. pour tout symbole f : s1× . . . × sn → s ∈ FConsmod, s ∈ Smod (c.-à-d.

on ne crée pas de nouveaux constructeurs de la signature de sécurité), 2. pour tout symbole f : s1 × . . . × sn → s ∈ FDefmod, s est finiment

constructible, c.-à-d. T (ΣCons )s est fini,

• un ensemble de règles de sécurité Γmod de la forme : action7→ ϕ

où action est un atome linéaire de At(˜Σ, X ) appelé motif d’action et ϕ est une formule de For=( ˜Σ_mod) telle que pour toute égalité t = t0, t et t0 sont d’une sorte finiment constructible,

• une théorie du premier ordre (c.-à-d. un ensemble de formules) Tmod ⊆ For=( ˜Σ_mod) dans laquelle pour toute égalité t = t0, t et t0 sont d’une sorte finiment constructible et

• un sous-ensemble de sortes S+

mod de Smod.

Le choix de ces différents éléments se justifie de la manière suivante :

• L’extension de la signature de sécurité décrit les nouvelles informations propres au modèle de sécurité. Par exemple, un modèle basé sur des niveaux de sécurité peut définir la nouvelle sorte Level ainsi qu’un ordre sur les niveaux caractérisé par un prédicat inf : Level × Level. La première condition sur cette extension indique que le modèle ne doit pas créer de nouveaux termes de donnée sortés par la signature de sécurité. Par exemple, dans le cas où la signature de sé-curité comporte les sortes Subject et Object, le modèle ne peut pas définir de nouveaux sujets et objets. La seconde condition indique que les interprétations de fonctions sont à valeurs dans des ensembles finis (condition nécessaire pour garantir des résultats de décidabilité ultérieurs). C’est le cas, par exemple, de la fonction qui attribue les niveaux de sécurité aux sujets et objets si l’ensemble des niveaux est fixé par le modèle.

• Les règles de sécurité définissent le schéma de calcul des autorisations, c.-à-d. les conditions à satisfaire pour qu’une action soit permise.

• Comme expliqué précédemment, la sémantique des informations de sécurité n’est pas connue au niveau de la définition du modèle mais le modèle peut contraindre les interprétations des symboles qu’elle définit. Par exemple, dans le cas de la définition d’une relation d’ordre partielle inf, la théorie devra préciser que l’interprétation de inf doit respecter la contrainte ∀x, y, z : inf(x, y) ∧ inf (y, z)⇒ inf(x, z).

• Enfin, le modèle peut spécifier l’existence de termes d’une sorte donnée sans en préciser les constructeurs. Par exemple, le modèle peut indiquer la présence de niveaux de sécurité mais ne pas les définir. Autrement dit, le modèle indique que c’est à l’étape de configuration que devront être définis les niveaux souhaités par l’administrateur. Dans ce cas, S+

mod doit contenir Level.

3.1. SPÉCIFICATION DES MODÈLES ET DES POLITIQUES

Exemple 3.4.Dans cet exemple, nous nous proposons de spécifier un exemple très simple pour illustrer la définition précédente. Nous nous basons sur une description simplifiée du modèle introduit dans [Sandhu et al., 1996] dans le-quel les actions possibles sont la lecture et l’écriture. Rappelons que l’idée principale du modèle RBAC est d’assigner chaque utilisateur à un ensemble de rôles. Le modèle attribue également des modes d’accès (read et write) sur les ressources (les fichiers dans notre cas) aux rôles. Enfin, un utilisateur sera habilité à effectuer une action sur une ressource ssi il possède un rôle dis-posant du mode d’accès correspondant sur le fichier en question. Dans notre cadre, ceci se traduit de la façon suivante. Notons ˜Σ la signature de sécurité définie dans l’exemple précédent et faisant état d’un système composé d’utili-sateurs et de fichiers. Les informations de sécurité définies par le modèle sont les rôles et les modes d’accès. De ce fait, Σrbac étend ˜Σ avec les sortes Role et Mode. Nous considérons dans notre exemple que l’ensemble des rôles doit être défini par l’administrateur mais que les modes d’accès sont fixés par le modèle. Dans ce cadre, Σrbacest composé des constructeurs (en l’occurence des constantes) read_mode et write_mode de sorte Mode correspondant res-pectivement aux modes de lecture et d’écriture tandis qu’aucun constructeur de sorte Role n’est défini et alors S+

rbac ={Role}. Nous utiliserons le prédicat ura : Subject× Role pour représenter l’assignation des rôles aux utilisateurs (ura pour user-role assignment) et le prédicat pra : Role × Mode × Object pour l’affectation des privilèges d’accès aux rôles (pra pour privilege-role assignment). Les règles de sécurité se définissent simplement de la façon sui-vante :



read(s, o)7→ ∃r : ura(s, r) ∧ pra(r, read_mode, o) write(s, o)7→ ∃r : ura(s, r) ∧ pra(r, write_mode, o) Dans la suite, nous noterons rbac le modèle de sécurité ainsi défini.

Comme tous les exemples, ce dernier n’illustre que partiellement les différents choix exposés dans la définition 3.3. L’utilisation de symboles définis et de théories sera illustrée dans l’exemple 3.23.

Le lecteur attentif remarquera que la définition donnée des modèles de sécurité n’induit pas une façon unique de calculer les autorisations. Par exemple, quel sens donner à un modèle comportant les règles read(s, o) 7→ ϕ1et read(s, o) 7→ ϕ2? Pour définir un schéma unique de calcul des autorisations, il est nécessaire (et suffisant) de munir les modèles d’une stratégie d’interprétation.

Définition 3.5.Une stratégie d’interprétation indique la façon dont les autori-sations d’action doivent être évaluées en fonction des règles de sécurité du modèle. En d’autres termes, elle associe à chaque action une formule à vérifier dont le calcul de la validité correspond à l’évaluation de l’autorisation d’action. Nous définissons les stratégies suivantes :

à un motif d’action filtrant l’action considérée sont satisfaites : Γand mod: ac7→ ^{^} a7→ϕ∈Γmod σ(a)=ac σ(ϕ)

• or : qui permet l’exécution d’une action ssi au moins une des contraintes associées à un motif d’action filtrant l’action considérée est satisfaite :

Γor

mod: ac7→ ^_

a7→ϕ∈Γmod

σ(a)=ac

σ(ϕ)

• or_else^ν, qui permet l’exécution d’une action ssi la contrainte associée au premier motif d’action filtrant l’action courante est satisfait et, dans le cas où l’action ne filtre aucun motif d’action, procède à la décision par défaut (autorisation dans le cas ν = > et refus dans le cas ν = ⊥) :

Γor_else^ν

mod : ac7→



σ(ϕ_i) si σ(a_i) = ac et∀j < i, @σ0 : σ0(a_j) = ac ν sinon

où ν ∈ {>, ⊥} et où les règles de Γmod sont supposées être ordonnées. Notons que par définition, l’autorisation par défaut (c.-à-d. lorsqu’aucun motif d’action ne correspond à l’action à évaluer) pour la stratégie and est > et corres-pond à ⊥ pour la stratégie or.

Nous supposerons dans la suite que tous les modèles sont munis d’une straté-gie d’interprétation qui sera indiquée en exposant du modèle, sauf lorsque toutes les stratégies coïncident (c.-à-d. lorsque chaque action possible filtre exactement un motif, ce qui est le cas dans notre précédent exemple).