Instance de propriétés

Les définitions des propriétés sont complexes à écrire et à utiliser. C’est pourquoi elles ne sont visibles que par l’expert en sécurité chargé de définir de nouvelles propriétés ou d’intégrer de nouveaux mécanismes de sécurité. L’administrateur de l’architecture logicielle n’a pas connaissance de la description exacte des propriétés. En effet, le langage vise à ce qu’un non-expert en sécurité puisse définir une politique en se basant uniquement sur les besoins de son architecture. Par conséquent, nous introduisons la notion de prototype de propriété.

Définition 3.5.4: Prototype

Un prototype est la signature d’une propriété ou d’une classe : son nom, son type de retour et, s’il s’agit d’une propriété, ses paramètres (une liste de types de contextes).

Un prototype est donc caractérisé par son nom et la liste de ses arguments (une liste de types de contextes). De plus, chaque prototype est associé à une description textuelle permettant à l’utilisateur de savoir à quels besoins répond la propriété, sans connaître son fonctionnement interne. Par exemple, le prototype de P1 est :

/**

* Interdit l’acces a l’information de fichiers pour tous les utilisateurs sauf ceux specifies

*

* @param SCFile les fichiers confidentiels * @param SCUser ^{les utilisateurs autorises} */

boolean Confidentiality_Access_Control(Type.Passive.Data.File SCFile, ID.User

SCUser);

Les prototypes sont utilisés pour définir une politique de sécurité, puisqu’ils permettent d’exprimer un besoin sans spécifier comment y répondre.

3.5.4.2 Prototypes de propriétés instanciés

Afin de définir une politique de sécurité qui adresse ses besoins, l’administrateur de l’architecture logicielle utilise les prototypes pour définir des propriétés instanciées prenant en arguments des contextes reflétant son architecture logicielle. La politique se base donc sur les prototypes, sur les contextes identifiant les ressources, sur l’architecture logicielle à protéger et sur ses besoins de sécurité.

Considérons par exemple le cas d’un utilisateur souhaitant garantir la confidentialité des fichiers de configuration mail d’un serveur. Cela peut être obtenu en utilisant la politique suivante :

1 mailConfig := (Type.Passive.Data.File.Configuration="conf"):(Domain="mail");

2 mailAdmin := (Id.Role="admin"):(Domain="mail");

3

4 @Confidentiality (mailConfig, mailAdmin);

Listing 3.11 – Confidentialité de fichiers de configuration

Le contextemailConfigdéfinit les fichiers de configuration qui doivent être confidentiels. Le contextemailAdminidentifie les utilisateurs autorisés à lire les fichiers protégés. Enfin, la propriété de confidentialité garantit que l’information des fichiers ne peut pas être obtenue par un utilisateur non autorisé. La technique d’application n’est pas spécifiée : selon les

3.5. PROPRIÉTÉS

cas, cette propriété pourra être appliquée soit en mettant en place du contrôle d’accès, soit en utilisant du chiffrement.

Le type de mécanisme choisi dépend notamment de l’environnement et des autres pro-priétés de la politique. La compatibilité des mécanismes est prise en compte, et le rôle particulier de l’attribut Domain intervient (section 3.4.3.1, p. 48). Par exemple, si toutes les propriétés d’un domaine font intervenir des utilisateurs humains, on pourra choisir du chiffrement ou du contrôle d’accès. Cependant, si l’une des propriétés du domaine fait intervenir un service, le contrôle d’accès sera choisi afin que l’application puisse toujours accéder à ses fichiers (sauf si le chiffrement et le déchiffrement peuvent être faits de manière transparente).

Par conséquent, il est possible de définir simplement des propriétés de sécurité qui sont indépendantes à la fois des mécanismes et des méthodes d’applications.

3.5.4.3 Score d’ordonnancement et d’application

Lorsqu’une propriété instanciée doit être appliquée, le prototype de cette instance peut être compatible avec plusieurs propriétés. Il est donc nécessaire de pouvoir ordonner les propriétés compatibles avec la propriété instanciée. Pour cela, on définit un score d’or-donnancement, basé sur le score statique des propriétés (définition 3.5.3) et sur le score d’inclusion de la propriété instanciée, défini de manière équivalente au score d’inclusion des capacités (définition 3.4.4). On obtient donc la définition suivante :

Définition 3.5.5: Score d’ordonnancement de propriété

Soit Pinst une propriété instanciée à appliquer. Soient Pi,1in les prototypes de proprié-tés compatibles avec Pinst au sens de la définition de compatibilité des capacités (défi-nition 3.4.3). On note Sstat(Pi) le score statique de Pi, d’après la définition 3.5.3 et d(Pi, Pinst)le score d’inclusion de Pidans Pinst (définition équivalente à la définition 3.4.4). Alors, le score d’ordonnancement Sord(Pi) des Pi est défini par :

Sord(P_i) = ^Sstat(Pi) d(P_i, P_inst) + 1

Le score d’ordonnancement est utilisé lors de la projection des propriétés (chapitre 4) afin de déterminer quelle est la meilleure propriété compatible avec la propriété instanciée donnée. Plus ce score est élevé, plus la propriété Pi est adaptée pour appliquer P .

Ce score peut être calculé grâce à l’algorithme 7. Pour chaque argument de la propriété instanciée Pinst (lignes 3 à 10), le score d’inclusion par rapport au type de contexte attendu par la propriété P (ligne 4) est calculé (ligne 6). En cas de non inclusion d’un des arguments, une valeur négative est retournée (ligne 8). Si tous les arguments sont inclus, le score statique de la propriété est récupéré (ligne 11) afin d’obtenir le score d’ordonnancement de la propriété P (ligne 12).

De plus, une propriété combine un ensemble de capacités et peut donc potentiellement mettre en jeu un ensemble de mécanismes durant son application. On peut donc extra-poler un score d’application d’une propriété instanciée à partir du score d’application des capacités et du score d’ordonnancement des propriétés sélectionnées.

Définition 3.5.6: Score d’application de propriété

Soit Pinst une propriété instanciée à appliquer. Soient Pi,1in les propriétés compatibles avec Pinst. On note Sord(Pi) le score d’ordonnancement de Pi (définition 3.5.5). Soient C_{i,j,1jm} les capacités composant Pi. On note Sapp(Ci,j) le score d’application de Ci,j

Algorithme 7 Calcul du score d’ordonnancement de la propriété P par rapport à Pinst 1: function scoreOrdonnancementPropriété (P , Pinst)

2: inclus 0

3: for all ctx[i] dans Pinst.listeContextesdo 4: argType P.argument[i]

5: if compatibilitéDeContexte(argType, ctx[i]) then

6: inclus inclus + scoreInclusion(argType, Type(ctx[i])) .Déf. 3.3.11 7: else

8: return -1 9: end if 10: end for

11: scoreStatique le score statique de P définit dans la classe (par défaut, 1) 12: return ( scoreStatique / (inclus + 1) )

13: end function

(définition 3.4.11). Alors, le score d’application Sapp(Pinst) de Pinst est défini par : Sapp(P_inst) = n X i=1 m X j=1

Sord(P_i)⇤ Sapp(Ci,j) , Sapp(Pinst) = n X i=1 m X j=1 Sstat(P_i)

d(P_i, P_inst) + 1⇤ Sapp(Ci,j) , Sapp(Pinst) = n X i=1 m X j=1 Sstat(Pi) d(P_i, P_inst) + 1⇤ q X l=1 S(c, M_l)⇤ ¹ d(c, C_i,j) + 1

Les scores d’applications des propriétés permettent de comparer les manières dont une même propriété a été appliquée sur différents systèmes.

Règle 3.5.7: Comparaison des applications de propriété

Soit Pinst une propriété instanciée à appliquer. Soient Sapp(Pinst)₁ et Sapp(Pinst)₂ son score d’application sur deux systèmes différents. Alors, l’application ayant le score le plus élevé est la meilleure.

3.5.5 Synthèse

Cette section a présenté les propriétés qui permettent de répondre aux besoins de sécurité. Les propriétés sont définies par un expert en sécurité, combinent des capacités et mettent en jeu les contextes. Elles peuvent être de trois sortes : les propriétés systèmes qui sécurisent les ressources d’un système et s’appliquent indépendamment sur les machines, les propriétés réseaux qui protègent les communications entre machines, et les propriétés hybrides qui combinent les deux premiers types afin de sécuriser des interactions de bout-en-bout.

Afin de factoriser l’expression de la politique, les propriétés ayant des objectifs de sécu-rité similaires peuvent être regroupées en classes. Les classes et les prototypes de propriétés sont utilisés par l’administrateur de l’architecture logicielle pour exprimer les besoins de sécurité de l’architecture logicielle. Les classes et propriétés qui ont été définies sont dispo-nibles à l’annexe A.2.

De plus, chaque propriété se voit attribuer un score d’ordonnancement et d’application indiquant la priorité et la qualité de son application. Ainsi, deux applications différentes d’une même propriété peuvent être comparées, afin de déterminer le niveau de protection effectif apporté par la propriété.