Les dépendances généralisées comme support à l’expression et à la vérification de politiques de sécurité. Romuald Thion, Stéphane Coulondre LIRIS, Laboratoire d'InfoRmatique en Images et Systèmes d'information, UMR 5205 INSA de Lyon, bât. Blaise Pascal, campus de la Doua, 69622 Villeurbanne Cedex [email protected], [email protected] RÉSUMÉ.

Les modèles RBAC (Role Based Access Control) tendent à s’imposer comme modèles de contrôle d’accès de référence. Ces modèles deviennent de plus en plus expressifs (prise en compte de la mobilité des utilisateurs, activations temporelles,…) et des contraintes sont introduites (rôles mutuellement exclusifs, contraintes de cardinalité, de pré requis, …) pour refléter les spécificités des organisations : ceci a tendance à augmenter le nombre de règles, à compliquer leur expression, à rendre difficiles les tâches d’administration et peut même conduire à la définition de politiques inconsistantes. Nous allons montrer dans cet article comment un outil théorique issu des bases de données, les dépendances génératrices de tuples contraintes (CTGDs), permet de représenter de façon homogène des politiques de sécurité et des contraintes sur les entités de la politique. Nous montrerons également comment les procédures de preuve développées pour les CTGDs permettent la vérification de ces politiques. Les algorithmes d’inférence peuvent vérifier qu’une politique n’est pas contradictoire, qu’une nouvelle règle n’est pas superflue ou encore l'impact de l’introduction de nouveaux utilisateurs, ressources, etc. Notre proposition sera illustrée par la représentation et la vérification d’une politique de type RBAC. ABSTRACT.

Role based access control (RBAC) models are becoming a de facto standard. These models are more and more expressive (temporal or geographical access control) and constraints (mutually exclusive roles, cardinality, prerequisite) are introduced to reflect specificities of organizations: a growing tendency to increase number of rules, which are harder and harder to express, lead administration tasks to be more and more complex and policies may even become inconsistent. This paper shows that a theoretical tool from research on databases, constrained tuplegenerating dependencies (CTGDs), is useful to express policies and constraints on core elements. We also show that proof procedures permit to check policy rules consistency, to verify a new rule is not already implied by existing ones or to know what does introducing new elements in policy produce. Our proposal is based on modelling and checking a constrained RBAC model. : Contrôles d’accès, dépendances génératrices de tuples, modèles RBAC, programmation logique par contraintes, gestion de politiques.

MOTS-CLÉS

KEYWORDS:

Access control, tuple-generating dependencies, RBAC models, constraint logic programming, policy management.

2 Congrès Inforsid : atelier Sécurité des Systèmes d’Information / 2005

1. Introduction Si l’ouverture de nos systèmes d’information est séduisante par bien des aspects, elle met en lueur un problème qui revêt une importance de plus en plus cruciale : celui de la sécurité. Désormais, toute machine connectée se doit de disposer d’un mécanisme de mise à jour du système, d’un firewall, voire d’un anti-virus et d’un anti-spyware, sans quoi elle est la cible en quelques minutes de vers, scripts de scan automatisés, pirates, sites web malicieux, etc. La sécurité a désormais une importance capitale : nous nous intéressons ici à un aspect particulier des mécanismes de sécurité : le contrôle des accès. 1.1. Politiques de contrôle des accès Contrôler les accès, c’est déterminer si un sujet (un processus, une machine, un utilisateur, …) peut effectuer une opération (lire, écrire, modifier, supprimer, rechercher, …) demandée sur une ressource (une tuple, une table, un objet, un fichier, …). Une politique de contrôle des accès (« access control policy ») spécifie sous forme de règles les droits des sujets sur les ressources d’un système, dans le but de renforcer la politique de sécurité au sens large (intégrité, disponibilité, protection physique des biens et des personnes, surveillance …) de l’organisation. Le contrôle des accès organisé autour de la notion de rôle, RBAC pour « Role Based Access Control » (Sandhu et al., 1996) est un modèle de contrôle des accès en cours d’adoption et un domaine de recherche actif. Ce modèle est basé sur le fait qu’une grande partie des décisions de contrôles des accès sont déterminées par les rôles des personnes dans leur organisation. Un rôle est une fonction ou un titre au sein d'une organisation, conférant une sémantique en termes d'autorité et de responsabilité des personnes qui l'endossent (Sandhu et al., 1996). 1.2. Motivations Les travaux sur la modélisation de politiques de sécurité de type RBAC proposent des modèles de plus en plus expressifs : conditionnements temporels sur les rôles (Bertino et al., 2001, Barker et al., 2003), d’autres s’attachent plus à la vérification (Koch et al., 2003). Notre proposition essaie de concilier les deux aspects que sont : – l’homogénéité, l’expressivité : peut-on représenter dans le modèle de politique utilisé une grande variété de contraintes requises pour un contrôle des accès fiables? – les requêtes, les possibilités de validation : peut-on interroger et vérifier des politiques de sécurité exprimées dans le modèle ?

Les dépendances comme support à l’expression et à la vérification de politiques 3 1.3. Notre approche Nous allons montrer dans cet article en quoi les « dépendances génératrices de tuples contraintes » (CTGDs) peuvent être un outil adéquat à la représentation et à la vérification de politiques de sécurité. Nous étaierons notre propos en représentant une politique de type T-RBAC3 (concepts de base RBAC + hiérarchie des rôles + contraintes + activation temporelles) dans le modèle des CTGDs et nous utiliserons les procédures d’inférences proposées dans (Maher et al., 1996) pour vérifier cette politique. Afin d’éviter toute confusion, nous précisons ici que le terme « contraintes » peut soit désigner des égalités/inégalités entre termes dans les formules des CTGDs (ex : X ≤ Y, 3≥ T, 2 ≠ 3, …), soit des restrictions sur les éléments des modèles RBAC (ex : aucun utilisateur ne peut endosser simultanément les rôles r1 et r2). Nous allons montrer dans cet article en quoi les « contraintes RBAC » représentent la sémantique associée aux « contraintes CTGDs » lorsqu’on représente une politique de type RBAC avec les CTGDs. Nous étudierons dans la section suivante des propositions de représentation et de vérification de politiques de sécurité, en section 3, nous présenterons les dépendances génératrices de tuples contraintes et les idées principales des algorithmes d’inférences y afférents. La section 4 montrera quels sont les intérêts des CTGDs pour l’expression et la vérification de politiques de contrôle des accès RBAC, dont la mis en œuvre sera exposée en chapitre 5. Enfin, la dernière section proposera une discussion et des perspectives d’utilisation des CTGDs en sécurité.

2. Etude de modèles existants

Figure 1. Modèle RBAC3 (pas de formalisme spécifique)

4 Congrès Inforsid : atelier Sécurité des Systèmes d’Information / 2005 L’article (Sandhu et al., 1996) présente la famille des modèles RBAC (RBAC0 : core RBAC, RBAC1 : RBAC0+hiérarchie des rôles, RBAC2 : RBAC0 + contraintes, RBAC3 : RBAC1+RBAC2). Afin de permettre une définition plus expressive des règles de contrôle des accès, ces modèles RBAC ont été repris et étendus. Le modèle Temporal-RBAC (Bertino et al., 2001), prend en compte des contraintes d’activation temporelles sur les rôles et les affectations. L'approche OrBAC (Kalam et al., 2003) propose quand à elle de structurer les autres entités du contrôle d’accès grâce à la notion d’organisation, mais sans la rattacher directement à la notion de rôle pour faciliter l’intégration de plusieurs politiques. 2.1. Modélisation en programmation logique par contrainte Dans (Barker et al., 2003) les auteurs proposent d’utiliser la programmation logique par contraintes (CLP, basée sur la logique des prédicats à laquelle est ajoutée la notion de contrainte linéaire sur les entiers/rationnels/réels) pour exprimer et implémenter les modèles de la famille RBAC ainsi que le modèle T-RBAC (Bertino et al., 2001). Grâce à leur représentation, les auteurs peuvent produire des programmes de contrôle des accès permettant la gestion de la hiérarchie des rôles et des ressources. Leur proposition permet également le conditionnement temporel des affectations des rôles aux utilisateurs ainsi que la gestion de contraintes statiques et dynamiques (fonction des sessions) sur les affectations, les permissions et les hiérarchies. Leur proposition permet la modélisation de politiques fermée (tout ce qui n’est pas explicitement permis est interdit), de type ouverte (tout ce qui n’est pas explicitement interdit est permis) ou hybride. On remarque que la logique utilisée n’utilise pas de quantificateurs existentiels dans les règles, et que les algorithmes d’inférence (SLD-résolution) imposent la forme clausale qui ne permet pas toujours une traçabilité efficace de l'inférence. 2.2. Représentation et vérification L’article (Koch et al., 2003) indique que dans le but d’éviter les inconsistances il est nécessaire d’avoir une représentation précise des règles de contrôles des accès (les auteurs se basent sur des exemples de type RBAC), et si possible graphiquement afin de faciliter les tâches d’administration. L’article compare trois approches et leurs intérêts du point de vue de l‘intuitivité et de la vérifiabilité. Le premier formalisme étudié est UML. Comme il n’existe pas d’outils permettant la vérification de contraintes sur les diagrammes UML, les auteurs proposent de transformer cette représentation en graphes (le troisième formalise étudié dans l’article). Le second formalisme abordé est Alloy : un langage permettant de décrire les structures des objets, des contraintes sur ces objets et comment la structure des objets peut évoluer. Enfin, la troisième proposition étudiée dans (Koch et al., 2003) est celle des Graph Transformations. Il s’agit d’un modèle de graphe sur lesquels sont bâties des règles de transformations utilisées pour représenter le modèle de contrôle des accès. Des procédures d’inférences travaillant sur ces graphes permettent de vérifier graphiquement les politiques.

Les dépendances comme support à l’expression et à la vérification de politiques 5 Ces trois formalismes permettent de vérifier que l'ajout d'une nouvelle contrainte (par exemple d’exclusion mutuelle entre deux rôles) ne rende pas la politique inconsistante. Cependant, les outils étudiés dans (Koch et al., 2003) ne permettent pas de répondre aux questions comme « Quelles sont les rôles ayant accès à cette donnée ? ». De plus, ces formalismes ne permettent pas d'exprimer des contraintes linéaires comme les contraintes temporelles ou géographiques. 2.3. Notre position Notre proposition est basée sur l’utilisation des CTGDs pour l’expression de politiques de sécurité et des procédures d’inférences pour vérifier ces politiques. Les contraintes linéaires présentes dans les formules de la logique du premier ordre que sont les CTGDs vont nous permettre de spécifier des contraintes au sens RBAC qui sont délicates à exprimer, et peuvent même nécessiter l’introduction de formalismes particuliers. Un des intérêts de l’utilisation des CTGDs plutôt que la programmation logique par contrainte de (Barker et al., 2003) est qu’elles permettent d’introduire des quantificateurs existentiels qui expriment des faits inconnus à l’avance. On peut ainsi exprimer des règles imposant l’affectation de permissions à un rôle sans savoir à l’avance quel rôle disposera effectivement de ces permissions (ex : « si un rôle dispose d’un droit de lecture sur une ressource, alors il existe un rôle qui dispose des droits d’écriture »). De plus, il est conceptuellement plus simple de disposer d'une procédure d'inférence spécialisée pour les CTGDs. En effet, ceci permet de ne pas avoir recours à une étape de transformation préalable coûteuse (i.e. Skolemization) nécessaire à l'utilisation des procédures de preuves classiques de la logique du premier ordre qui ne travaillent pas sur l'ensemble initial des formules. Les procédures de preuves sur CTGDs (Maher et al., 1996) ne décomposent par les règles sur lesquelles elles travaillent et raisonnent directement sur celles-ci. Un des intérêts est qu’un fois un but prouvé, on peut garder la trace des CTGDs qui ont été successivement appliquées pour suivre le cheminement qui a abouti à la preuve, qui par nature est ainsi beaucoup plus facile à analyser et à comprendre.

3. L’apport des bases de données Les recherches théoriques sur les bases de données relationnelles ont abondamment étudié les « dépendances de données » (data dependencies), proposant des ensembles de plus en plus grands de dépendances. Les plus connues sont les dépendances fonctionnelles et multivaluées, qui sont toutes deux des sous ensembles des dépendances génératrices de tuples, appelées aussi dépendances généralisées (Ullman, 1988). Nous allons montrer en quoi les dépendances de données peuvent être utiles pour l’expression et la vérification de politiques.

6 Congrès Inforsid : atelier Sécurité des Systèmes d’Information / 2005 3.2. Les dépendances génératrices de tuples contraintes (CTGDs) Les travaux de (Maher et al., 1996) ont étudié de nouveaux types de dépendances parmi les plus générales qui soient actuellement : les dépendances génératrices de tuples contraintes (constrained tuple generating dependencies, CTGDs). Ces dépendances sont représentables formellement en logique du premier ordre (Abiteboul et al., 1995) par : ~ ~ ~ ~ ~ ∀ X , p 1 ( X 1 ) ∧ p 2 ( X 2 ) ∧ ... ∧ p k ( X k ) ∧ c ( X ) → ~ ~ ~ ~ ~ ~ ~ ~ ~ ∃ Y , q 1 ( X , Y 1 ) ∧ q 2 ( X , Y 2 ) ∧ ... ∧ q n ( X , Y n ) ∧ c ' ( X , Y )

Où X et Y sont des ensembles disjoints d’attributs et pi, qi des symboles de relations (en BdD) / prédicats (en logique). X (resp. Y) désigne l’ensemble des attributs présents au moins dans l’hypothèse (resp. uniquement dans la conclusion) et quantifiés universellement (resp. existentiellement). Enfin c (resp. c’) désigne des conjonctions de contraintes linéaires (, ≤, ≥, ≠, =) sur tout ou partie des attributs X (resp. X et Y). Les CTGDs n’introduisent pas de négation sur les prédicats, cependant on peut tout de même modéliser des règles de sécurité qui représentent certaines interdictions sans utiliser de littéraux négatifs, par exemple en utilisant ┐(x = y) ≡ (x ≠ y) 3.3. Inférence sur les CTGDs (Maher et al., 1996) développe deux procédures de preuves pour les CTGDs, ces procédures permettent de déterminer si un ensemble de CTGDs F implique une CTGD g, soit soit F |= g. Il s’agit de prouver que dans toute base de données où les dépendances de F sont satisfaites la dépendance g l’est aussi. Ces algorithmes sont semi-decidables : ils peuvent ne pas terminer. Comme chaque passe est un pas de plus dans les implications, on peut dans la pratique limiter le nombre de CTGDs successivement applicables pour produire de nouveaux faits. Trois cas sont à distinguer quand l’algorithme se termine : Vrai par preuve, Vrai par vacuité (les contraintes linéaires se contredisent), et Faux. Nous montrerons que le cas de la vacuité est porteur de sens si l'on veut vérifier que la politique est consistante (que les contraintes RBAC ne sont pas violées).

4. Expression et validation de politiques de type RBAC 4.1. Symboles de prédicats et de constantes Comme dans (Barker et al., 2003) nous avons choisi d’utiliser :

Les dépendances comme support à l’expression et à la vérification de politiques 7 – ura(Utilisateur, Role), pour représenter les affectations des rôles aux utilisateurs (user-role assignment), – pra(Accès, Objet, Role), pour représenter les affectations de permissions (un droit d’accès sur une ressource) aux rôles (permission-role assignment), – senior(RoleFils, RoleParent), pour représenter l’héritage entre rôles, et par exemple inclus(ObjetFils, ObjetPere) pour la hiérarchie des objets – autorise(Utilisateur, Accès, Objet), qui représente la permission d’accès accordée à un utilisateur sur un objet. 4.2. L’implication logique Nous allons utiliser les CTGDs pour représenter les axiomes qui forment le cœur des modèles RBAC. Les axiomes permettent de définir le comportement et le type de politique (RBAC, MAC, hybride), par exemple : – la notion d’héritage de rôles et d’objets est transitive et réflexive, – quand un rôle hérite d’un autre, il hérite de ses permissions. Comme nous sommes dans un cas de logique positive et de monde fermé, un rôle héritant dispose donc au moins d’autant de permissions que son père, – un utilisateur est autorisé d’accès sur une ressource s’il endosse un rôle qui dispose (au travers de l’héritage éventuellement) de cet accès sur la ressource. Libre à un administrateur d’entrer d’autres règles de gestion pour tâcher de respecter au mieux une définition de politique exprimée en langue naturelle, et selon les besoins de son organisation. 4.3. Les contraintes linéaires Les CTGDs ajoutent des contraintes linéaires par rapport aux TGDs. Lorsque des contraintes sont présentes en hypothèse elles nous permettent de conditionner les affectations des rôles selon le temps (en modélisant des plages horaires (Bertino et al., 2001) ou l’espace (en représentant des zones géographiques (Grumbach et al., 2001). Lorsque des contraintes sont présentes en conclusion, elles expriment des contraintes sur les éléments de la politique. Par exemple : – pour exprimer le fait qu’un rôle n’est attribué que dans la plage horaire [t1, t2], on utiliserait heure(H) { t1 ≤ H ≤ t2 } Æ ura(utilisateur, role). – pour exprimer le fait qu’un rôle n’est attribué que dans un secteur rectangulaire [x1, x2], [y1, y2] (en utilisant des contraintes entre x et y on peut représenter d’autres surfaces) on utiliserait position(X,Y) {x1≤ X ≤ x2, y1≤ Y ≤ y2} Æ ura(utilisateur, role) – pour exprimer le conditionnement d’un rôle selon le niveau d’urgence en cours : urgence(X) {X>3} Æ senior(responsable, securite), pour « seulement en cas d’alerte majeure un responsable dispose des droits des agents de la sécurité »

8 Congrès Inforsid : atelier Sécurité des Systèmes d’Information / 2005 – pour exprimer des contraintes d’unicité, on utiliserait des règles de type dépendances fonctionnelles, ura(U1,directeur), ura(U2,directeur) Æ {U1=U2}, pour « à tout instant il n’y a qu’un seul utilisateur qui endosse le rôle de directeur ». – des interdictions spécifiques, cas particulier, comme par exemple le fait qu’un utilisateur « user » ne puisse explicitement pas endosser un rôle « roleInterdit » : ura(user,Role) Æ {Role ≠ roleInterdit} – l’exclusion mutuelle entre rôles : aucun utilisateur ne peut endosser les rôles r1 et r2 : ura(U, r1), ura(U,R) {r1 ≠ R} Æ {R ≠ r2}. La terminaison par vacuité est particulièrement adaptée à cette problématique (cf. section 3.3.). S’il existe des faits qui activent l’hypothèse de la dernière CTGD proposée ci-dessus, par exemple ura(romuald, r1), ura(romuald,r2), alors la contrainte de conclusion de g ({r2 ≠ r2}) sera ajoutée à la politique qui deviendra inconsistante : les affectations des rôles r1 et r2 à l’utilisateur Romuald violent la politique. 4.4. Quantificateur existentiel Les variables présentes uniquement dans la conclusion des formules logiques sont quantifiées existentiellement. Intuitivement, cela s’entend par « il existe au moins un élément tel que … ». Cette sémantique est utilisée ici pour prendre en compte les contraintes de pré-requis sur les politiques RBAC : – contrainte de pré-requis sur les affectations de rôles : « pour tout utilisateur disposant du rôle adjoint, alors y a un au moins un autre utilisateur qui est directeur » : ura(U, adjoint) Æ ura(U2, directeur) {U2 ≠ U} . – contrainte de pré-requis sur les permissions : par exemple, « pour tout utilisateur qui a droit de lecture sur une ressource, alors il existe au moins un utilisateur qui a droit d’écriture sur cette ressource »: autorise(U, r, O) Æ autorise(U2, w, O). Ces deux règles comportent une variable U2 quantifiée existentiellement (uniquement présente en conclusion) qui représente l’existence d’un utilisateur, mais que l’on ne connaît pas nécessairement. Prenons l’exemple de la première contrainte de pré-requis (présence d’un directeur). Pour qu’il n’y ait pas de lacunes dans la politique, l’administrateur doit introduire un utilisateur disposant du rôle directeur, par exemple ura(andré, directeur).. Nous pouvons étendre cette idée à une définition plus large de la cohérence d’une politique : « pour tout rôle, il faut qu’il existe au moins un utilisateur qui endosse le rôle », « pour toute ressource, il faut qu’il existe un rôle pouvant la lire, l’écrire et l’exécuter »…, (Goncalves et al., 2003).

Les dépendances comme support à l’expression et à la vérification de politiques 9 5. Résultats Nous avons implémenté le premier algorithme d’inférence proposé dans (Maher et al., 1996). Il nous a permis de travailler sur la politique que nous décrivons dans la section 5.1. pour exécuter des requêtes, trouver les éléments manquant qui rendent la politique lacunaire, vérifier qu’il n’y a pas de faits qui violent la politique, savoir si l’ajout d’un fait rendrait la politique inconsistante, etc. 5.1. Exemple de modélisation RBAC Selon que l’on se trouve à différents stades de la réalisation d’une politique de contrôle des accès de type RBAC, différents besoins de vérification peuvent apparaître : – lors de la définition des règles qui forment le cœur même de la politique, ses axiomes : comme les propriétés de la relation d’héritage, la définition des permissions des utilisateurs sur les ressources par l’intermédiaire du rôle, etc. – lors de la création de la hiérarchie des rôles et des affectations des permissions. – lors de la mise en place des contraintes d’exclusion mutuelle sur les rôles et des affectations de permissions, on voudrait vérifier la consistance de la politique. – lors de la mise en place de pré requis sur les rôles ou les permissions pour vérifier qu’il n’y a pas de lacunes dans la politique (recherche automatisée des termes introduits par le quantificateur existentiel, cf. section 4.4.) – et même lors des étapes suivantes comme l’affectation des rôles aux utilisateurs la mise en place des contraintes, l’intégration de la notion de session, etc. Dans notre représentation (inspirée de Barker et al., 2003), les identificateurs de variables commencent par une majuscule, les CTGDs sont de la forme hypothèse Æ conclusion (inversé en Prolog), les variables présentes au moins en hypothèse sont quantifiées universellement et celles uniquement en conclusion sont quantifiées existentiellement. #définition des rôles et de leur hiérarchie directe ->seniorDirect(doctorant,etudiant), seniorDirect(doctorant,chercheur). ->seniorDirect(moniteur,doctorant),seniorDirect(moniteur,enseignant). ->seniorDirect(mcf,enseignant),seniorDirect(mcf,chercheur). #CTGDs 1, 2 et 3 #définition des affectations des permissions aux rôles ->pra(r,examen,etudiant),pra(w,examen,enseignant),pra(r,partiel,mcf). ->pra(r,publi,chercheur),pra(w,revue,mcf),pra(w,publi,directeur). #CTGDs 4 et 5 #contrainte de pré requis sur les permissions pra(r,O,R1) -> pra(w,O,R2). #CTGD 6 #senior est la fermeture transitive réflexive de seniorDirect seniorDirect(X,Y)->senior(X,X),senior(Y,Y),senior(X,Y). #CTGD 7

10 Congrès Inforsid : atelier Sécurité des Systèmes d’Information / 2005 seniorDirect(X,Y),seniorDirect(Y,Z)-> senior(X,Z). #CTGD 8 ura(U,X)->senior(X,X). #CTGD 9, cas limite où X n’hérite d’aucun rôle pra(A,O,X)->senior(X,X). #CTGD 10 #L’administrateur est un “Super Role”, il hérite de tous les autres senior(R,R)->senior(administrateur,R). #CTGD 11 #les rôles héritent des permissions de leurs parents pra(A,O,R1),senior(R2,R1)->pra(A,O,R2). #CTGD 12 #définition des permissions par l’intermédiaire du rôle ura(U,R1),pra(A,O,R1)->autorise(U,A,O). #CTGD 13 #un seul utilisateur peut être directeur ura(U1,directeur),ura(U2,directeur)->{U1=U2}. #CTGD 14 #contrainte de pré requis sur les affectations de rôles ura(U1, adjoint) -> ura(U2, directeur){U2 =\= U1}. #CTGD 15 #interdiction spécifique ura(romuald,R) -> {R=\=directeur}. #CTGD 16 #role mutuellement exclusifs : étudiant et maître de conférences ura(U,etudiant),ura(U,R) {R=\=etudiant}-> {R=\=mcf}. #CTGD 17 #affectation de rôles limitées dans le temps Heure(H) {H>=8, H= ura(romuald, moniteur). #CTGD 18 Heure(H) {H=0}-> ura(romuald, etudiant). #CTGD 19 Heure(H) {H>18, H ura(romuald, etudiant). #CTGD 20

Nous avons indiqué que les procédures de preuve pour les CTGDs permettent de prouver que F |=g, le jeu d’essai ci-dessus fait donc figure de base F. Pour des raisons de lisibilité les notions de sessions ou de hiérarchies d’objets n’apparaissent pas dans cet exemple. De même nous n’avons pas fait figuré les prédicats role(R), utilisateur(U) ou permission(A,O) ni les contraintes d’accès géographiques. 5.2. Exemples d’utilisation Cette section illustre l’utilisation des procédures d’inférence (qui prouvent que F |= g) sur les CTGDs pour vérifier la politique définie dans le jeu d’essai (la base F) : – Est-ce que si l’on affecte le rôle doctorant à un utilisateur, celui-ci dispose du droit d’écriture sur les examens ? Ici, g ≡ ura(X, doctorant) Æ autorise(X, w, examen). L’algorithme se termine et indique que F |≠ g, en effet, le rôle doctorant n’hérite pas du rôle enseignant, le seul à disposer du droit d’écriture sur les examens. On note qu’il s’agit d’un problème de TGDs sans contraintes ni variables existentielles (Full-TGDs), pour lesquels les algorithmes sont adéquats et complets. – Est-ce que le rôle administrateur dispose de toute affectation de permission existante ? Ici, g ≡ pra(A,O,X) Æ pra(A,O,administrateur). L’algorithme se termine et indique que F |=g : cette dernière CTGDs est redondante. Par application successive des CTGDs 10, 11 et 12 le rôle administrateur hérite de tous les rôles existants et donc de X, qui dispose du droit A sur l’objet O.

Les dépendances comme support à l’expression et à la vérification de politiques 11 – Est-ce que l’affectation des rôles mcf et etudiant à un utilisateur provoque une inconsistance ? Ici, g ≡ ura(U,mcf), ura(U, etudiant)Æ. L’algorithme se termine et prouve que F |= g par vacuité : on a une inconsistance dans la politique. L’application de la CTGD 17 va ajouter la contrainte {mcf ≠ mcf} qui n’est jamais vraie. – Est-ce que la politique souffre de lacunes si j’indique que Romuald est adjoint ? ura(romuald, adjoint) Æ. Dans ce cas ci, la politique est lacunaire, en effet, la CTGD 15 va introduire le fait ura(tmp, directeur), et la contrainte {tmp ≠ romuald} dans la politique, or il se trouve qu’il n’y a pas d’utilisateur affecté au rôle directeur, il y a donc une lacune dans la politique que l’administrateur doit maintenir (la recherche peut être automatisée).

6. Discussion, perspectives Nous avons montré que les CTGDs fournissent un cadre très expressif qui permet de modéliser des politiques de type RBAC et d’exprimer des contraintes d’exclusions mutuelles, des restrictions selon des critères spatio-temporels ou des pré-requis. Les algorithmes de preuves permettent de raisonner sur ces modélisations, en travaillant sur les CTGDs sans les décomposer, facilitant ainsi la traçabilité du raisonnement et les tâches de vérification. Nous avons également montré que les trois cas de terminaison des algorithmes d’inférences (vrai par preuve, vrai par vacuité, faux) sont porteurs de sens. 6.1. Extensions aux travaux sur les disjunctives CTGDs Les travaux de (Maher et al., 1996) on étés prolongés par la thèse (Wang, 2002) qui définit un ensemble encore plus général des dépendances de données : les disjunctive constrained tuple-generating dependencies. Ces dernières ne restreignent plus les règles au seul connecteur et logique mais aussi au ou. Nous évaluons actuellement l’intérêt de l’introduction de la disjonction dans les règles de contrôle des accès, elles permettraient par exemple d’exprimer des règles telles que « pour tout utilisateur endossant le rôle agent, il existe soit un responsable administratif, soit un responsable exécutif (éventuellement les deux) ». 6.2. Représentation graphique Des travaux comme (Coulondre et al., 1998) on mis en évidence le lien entre représentation de graphes conceptuels et formules logiques. Nous pensons pouvoir utiliser ces résultats pour représenter graphiquement des politiques de contrôle des accès, au moins dans le cas des TGDs sans contraintes, et faciliter ainsi les tâches d’administrations (Koch et al., 2003).

12 Congrès Inforsid : atelier Sécurité des Systèmes d’Information / 2005 6.3. Application à la modélisation et vérification des règles de firewalls Enfin, nous pensons que les CTGDs peuvent être utiles pour la modélisation et la vérification des jeux de règles de firewall. Alors que dans notre exemple en section 5, certaines CTGDs modélisent le cœur de la politique (ses axiomes), d’autres des faits, des contraintes sur les éléments ou encore des pré-requis, un pendant pour les firewalls est envisagé. Certaines CTGDs modéliseraient le cœur du firewall (la notion d’état de connexion pour les firewalls dits « statefull »), d’autres les règles d’action (accept/deny) ou encore le comportement réactif (création de nouvelles autorisations temporaires selon un événement).

7. Références bibliographiques Abiteboul S., Hull R., Vianu V., “Foundations of Databases”, Addison-Wesley Publishing, 1995 Barker S., Stuckey P., “Flexible access control policy specification with constraint logic programming”, ACM Transactions on Information and System Security (TISSEC), vol. 6 , num. 4, 2003 Bertino E., Bonatti P. A., Ferrari A., “TRBAC: A temporal role based access control model”, ACM Transaction on Information System and Security, p. 191-233, August 2001 Coulondre S., Salvat E., “Piece resolution: towards larger perspectives”, proc. of the 6th International Conference on Conceptual Structures, p. 179-193, 1998 Goncalves G., Hemery F., Poinszeswka-Maranda A. “Ingénierie des rôles : de la conception à l’évolution des schémas de sécurité”, Atelier Sécurité des Systèmes d’Information (Inforsid04), 2004 Grumbach S., Rigaux P., Segoufin L., “Spatio-Temporal Data Handling with Constraints”, GeoInformatica, vol. 5, num 1, Kluwer Academic Publishers, p. 95-115, 2001 Kalam A., El Baida R., Balbiani P., Benferhat S., Cuppens F. et al., “Organization Based Access Control”, IEEE 4th International Workshop on Policies for Distributed Systems and Networks, 2003. Koch M., Parisi-Presicce F., “Visual Specifications of Policies and Their Verification”, Fundamental Approaches to Software Engineering, 2003 Maher M., Srivastava D., “Chasing Constrained Tuple-Generating Dependencies”, Symposium on Principles of Database Systems, 1996 Sandhu R., Coyne E., Feinstein H., Youman C., “ Role-Based Access Control Models”, IEEE Computer, vol. 29, num. 2, p. 38-47, 1996. Ullman J., “Principles of knowledge-base systems. Volume I: classical database systems”, Computer Science Press, 1988 Wang J., “Exploiting Constraints for Query Processing”, Diploma thesis for PhD, Griffith University, Brisbane Australia, 2002