Contrôle d accès par les ontologies

Transcription

1 Contrôle d accès par les ontologies Outil de validation automatique des droits d accès Mémoire Étienne Théodore SADIO Maîtrise en informatique Maître ès sciences (M.Sc.) Québec, Canada Étienne Théodore SADIO, 2015

2

3 Résumé De nos jours, nous assistons à l émergence d un écosystème informatique au sein de l entreprise due à la cohabitation de plusieurs types de systèmes et d équipements informatique. Cette diversité ajoute de la complexité dans la gestion de la sécurité informatique en général et le contrôle d accès en particulier. En effet, plusieurs systèmes informatiques implémentent le contrôle d accès en se basant sur des modèles comme le MAC 1, DAC 2, RBAC 3 entre autres. Ainsi, chaque système a sa propre stratégie donc son propre de modèle de contrôle d accès. Cela crée une hétérogénéité dans la gestion des droits d accès. Pour répondre à ce besoin de gestion du contrôle d accès, nous avons, dans ce mémoire, présenté la conception d une ontologie et d un outil de gestion automatique des droits d accès dans un environnement hétérogène. Cet outil se base sur notre ontologie qui permet d introduire une abstraction sur les modèles de contrôle d accès implémentés dans les différents systèmes à analyser. Ainsi, les administrateurs de sécurité disposent un outil pour valider l ensemble des droits d accès dans leurs écosystèmes informatique. 1. MAC : contrôle d accès obligatoire 2. DAC : contrôle d accès discrétionnaire 3. RBAC : contrôle d accès à base de rôles iii

4

5 Abstract Today, we are seeing the emergence of an IT ecosystem within companies due to the coexistence of several types of systems and computer equipements. This diversity adds complexity in management of computer security in general and particulary in access control. Indeed, several computer systems implement access control techniques based on models like MAC 4, DAC 5, RBAC 6 among others. Each system has its own strategy based on its own access control model. This creates a heterogeneity in the management of access rights. To respond to this need related to the management of access control, we presented the design of an ontology and we developped an automated management tool of access rights in a heterogeneous environment. This tool is based on our ontology which introduces an abstraction on access control models implemented in different systems that we want analyze. Thus, security administrators have a tool to validate all access rights in their IT ecosystems. 4. MAC: Mandatory Access Control 5. DAC: Discretionary Access Control 6. RBAC: Role Based Access Control v

6

7 Table des matières Résumé Abstract Table des matières Liste des tableaux Liste des figures Remerciements iii v vii ix xi xv Introduction 1 Contexte Problematique Objectif et méthodologie Organisation Etat de l art et motivation Introduction Besoins des administrateurs en sécurité informatique Architecture de système informatique et modèles de contrôle d accès Processus d audit et de validation des droits d accès Outils de gestion des droits d accès Modèle UML pour la gestion du contrôle d accès Gestion sémantique des droits d accès : AMO Conclusion Modèle de gestion basé sur le concept des ontologies Introduction Pourquoi une ontologie Liste des concepts intervenant dans le contrôle d accès Relation entre les différents concepts du contrôle d accès Graphe de représentation de l ontologie Raisonnement sur la validation des droits d accès Conclusion Implémantation de l outil de traitement Introduction vii

8 3.2 Architecture Outils de provisioning Mécanisme de validation de droits d accès Exemple AVTAC : Framework pour le contrôle d accès Conclusion Conclusion 67 Enrichissement de l ontologie Analyse du domaine de la sécurité informatique plus largement A Document XACML 69 A.1 Traduction droit d accès linux en XACML A.2 Traduction droit d accès Windows en XACML viii

9 Liste des tableaux 1.1 Exemple de liste de contrôle d accès Exemple de Les listes de capacités modèle de contrôle d accès discrétionnaires Modèle RBAC Correspondance OWL-DL et logique descriptive SHOIN(D) Grammaire BNF d un sous ensemble de XACML SDDL Syntax Traduction de SDDL vers XACML ix

10

11 Liste des figures 1.1 Caputure d écrant de SetACL Studio architecture de OpenIDM SecureUML Méamodel Ontologie AMO Familles de loguique descriptive Hierarchie des classes Graph Ontologie Simplifié Architecture de l outil de validation linux strcture basic des droits d accès Droit d accès Linux : Example ACL Minimale ACL Etendue Structure d un descripteur de sécurité Example Example Language SDDL Language SDDL : ACE Capture d écran n 1 de l outil de validation Capture d écran n 2 de l outil de validation Architecture access validation tool xi

12

13 Je dédie ce mémoire à mon père Aloyse SADIO, à ma mère Ivette Tine et à mes deux soeurs Marie Rosalie Sadio et Josephine Marie Élisabeth Sadio. Vous êtes ma fierté et le rocher sur lequel je m appuie pour avancer. xiii

14

15 Remerciements Je tiens à remercier tous ceux ou celles qui, de près ou de loin, ont contribué à la réussite de ce travail. Je désire remercier tout particulièrement mon directeur de recherche, le professeur Mohamed Mejri qui m a accompagné et m a encadré dans cette aventure. J ai beaucoup appris avec toi en terme de valeur humaine et d exigence du travail bien fait. Ton support, tes conseils et tes encouragements m ont permis d arriver à un tel résultat. Je tiens à remercier le professeur Hatem Ben STA qui a supervisé comme codirecteur mon travail et qui a beaucoup contribué dans l approche intégrant l utilisation des ontologies. Vous m avez guidé tout en me laissant la liberté de décider. Merci pour tout. Je remercie le professeur Kamel Adi qui a accepté de corriger mon mémoire. J exprime également toute ma gratitude à mes collègues de LSI, en particulier Khadija Arrachid, Memel Emmanuel Lathe et Maxime Leblanc, qui, par nos échanges, ont permis d enrichir mes travaux de recherche. Aucun mot ne peut exprimer ma gratitude que j éprouve, pour ma famille qui a été d un soutien inestimable durant toute cette aventure or de mon pays de naissance. Infiniment merci. Sans vous, cette aventure ne serait pas possible. Et comme le dit un proverbe chinois " Quand tout va bien on peut compter sur les autres, quand tout va mal on ne peut compter que sur sa famille." Je tiens, également, à faire un clin d oeil à mes amis qui ont été là pour me motiver et partager des moments formidables. Je veux nommer Adolphe Ndiaye, Jean Édouard Dioh, Anani Thiery Hema, Thierno Barry, Ibrahima Issoufou et Mamadou Seydou Cissé. Merci pour votre disponibilité. xv

16

17 Puisque la montagne ne vient pas à nous, allons à la montagne. Mahomet xvii

18

19 Introduction Contexte La sécurité informatique est un monde qui regroupe un ensemble de compétences et de savoirfaire. Cela s explique par le fait que la notion de sécurité informatique intègre les notions de confidentialité, d intégrité, de disponibilité, de la non-répudiation, d imputation et d authentification. L un des aspects de la sécurité informatique est le contrôle d accès qui en est un de ces piliers. Le contrôle d accès peut-être défini comme étant la vérification qu une entité demandant l accès à une ressource a les droits nécessaires pour le faire. Ainsi on peut naturellement le définir comme étant l ensemble des règles qui régissent cette vérification en se basant sur une politique de sécurité. Dans la vie de tous les jours, cette politique de contrôle d accès peut être considérée dans plusieurs exemples. Prenons le cas d une personne qui veut passer la frontière dans un pays ; le contrôle d accès se définit ici par le fait de s assurer que la personne dispose de tous ses documents légaux à savoir le passeport, visas et autres. Dans un autre exemple, une personne qui veut accéder aux ressources d un cours à l université, le contrôle d accès sera la vérification de l inscription de cette personne à la formation dans laquelle ce cours est donné. Ces règles sont définies dans le monde de l informatique en terme de droit d accès. Le contrôle d accès peut se résumer alors comme étant la gestion des droits d accès. Plusieurs systèmes informatiques implémentent le contrôle d accès en se basant sur des modèles comme le MAC, DAC, RBAC entre autres. Un modèle de contrôle d accès permet de définir une stratégie de définition de règles pour l attribution des droits d accès. Ainsi, chaque système a sa propre stratégie donc son propre modéle de contrôle d accès. Cela crée une hétérogénéité dans la gestion des droits d accès, taches que les administrateurs en sécurités informatiques doivent s acquitter en prenant le soin de ne pas introduire des erreurs qui peuvent se transformer en faille majeure de sécurité. 1

20 Problematique Pour être compétitive de nos jours, une entreprise doit être flexible en disposant d une vitesse de réorganisation accélérée pour pouvoir suivre les phénomènes de fusion, de cession d une activité et d acquisition d entreprises. Il suffit de lire la presse économique pour se rendre compte que dans les entreprises ça évolue de plus en plus vite. De plus, avec la place de choix qu occupent les systèmes informatiques dans la compétitivité de l entreprise moderne, il va de soit que toute réorganisation au sein de l entreprise affecte l organisation des systèmes informatiques. Ainsi la tâche de gestion des systèmes informatiques est plus complexe du fait de la diversité des solutions techniques informatiques (équipements réseau divers, OS multiples (Linux, Mac, Windows), appareil mobile). Pour les administrateurs, il est primordial de pouvoir remplir tout cahier de charge induit par une réorganisation au sein de l entreprise, aussi bien durant une fusion, une cession ou une acquisition que lors de changement occasionner par un flux de personnel. Dans MAGDA 7 (Methode d administration et de gestion des droits et accréditation), le Club de la sécurité des systèmes d information français (CLUSIF 8 ) a fait plusieurs constats : L administration des systèmes de sécurité est faite par des personnes les plus aptes et les mieux placer au sein de l entreprise pour les contourner. Ainsi cette population s attribue en général des droits exorbitants pour accomplir leurs tâches. L intégration des métiers au système informatique provoque un accroissement de l hétérogénéité des plates-formes et des méthodes d administrations. La vitesse de la réorganisation dans l entreprise induite par les rachats, les fusions et les absorptions d entreprises se propage mal ou trop lentement dans l attribution des droits d accès. La restructuration et réorganisation provoque un flux de départs, d absences, de remplacements et très souvent l intervention d acteurs externes a l entreprise. On assiste alors à une mauvaise gestion de ces flux en termes de contrôle d accès. La gestion combinatoire insupportable dès que l entreprise dépasse une taille modeste et/ou que l on fait face à un environnement réellement ouvert (n utilisateurs confrontés à m ressources pour p types d usages). Ces constatations montrent les grands défis de l affectation des droits d accès au sein d une entreprise. Il s agit d un processus qui a besoin d être audité et validé régulièrement. D où 7. MAGDA :http :// 8. CLUSIF :https :// 2

21 la pertinence de fournir aux administrateurs de sécurité informatique un outil de gestion automatisé des droits d accès. Objectifs et méthodologie L objectif de nos travaux est de fournir aux administrateurs des outils pour auditer et valider des droits d accès dans un environnement hétérogène. Notre méthodologie consiste à : comprendre les différents modèles du contrôle d accès et d étudier les modèles les plus utilisés dans l industrie ; trouver des concepts du domaine de la sécurité informatique pour décrire et retrouver tous les modèles de contrôle d accès montrer comment l utilisation de la technologie des ontologies permet de retrouver les différents concepts du contrôle d accès. Organisation Le présent document est orgamisé comme suit : Le premier chapitre détaillera les motivations qui ont suscité nos travaux en analysant les besoins des entreprises sur le plan du contrôle d accès. Nous décrirons le contrôle d accès et ces différents modèles, pour finir par un état de l art des outils et technologie qui sont présent dans le marché de la gestion des droits d accès. Dans le second chapitre, nous allons présenter notre approche utilisant la technologie des ontologies. Une présentation générale des ontologies sera faite dans un premier temps, et nous montrerons en quoi l utilisation des ontologies peut servir à mettre en oeuvre un outil de gestion et d audit du contrôle d accès. Dans le troisième chapitre nous présenterons notre outil de gestion et de validation des droits d accès, en montrant l architecture générale de notre prototype, et présenter ses modes de fonctionnement. Nous allons finir notre document par une conclusion où nous dégagerons les perspectives de nos travaux. 3

22

23 Chapitre 1 Etat de l art et motivation. 1.1 Introduction Le contrôle d accès est l un des fondements de la sécurité informatique. Dans plusieurs entreprises, la tâche première des administrateurs en sécurité est de faire la gestion, l audit et la validation d accès aux ressources. Alors, il est important de mettre le doigt sur l analyse des besoins des administrateurs en thermes de sécurité informatique pour montrer la problématique liée au contrôle d accès. De plus, mettre en relief la compréhension informelle et formelle du contrôle d accès, de la politique de contrôle d accès et des différents modèles de contrôle d accès nous permettra de fournir les mécanismes d audit et de validation des droits d accès au sein des entreprises. Ainsi, il sera plus facile d interroger l état de l art, afin de montrer ce qui se fait dans le marché de l informatique. 1.2 Besoins des administrateurs en sécurité informatique De nos jours, dans les structures sociales, professionnelles et même familiales, l informatique occupe une place très importante. De plus, nous assistons à l interconnexion des différentes ressources informatiques à travers un réseau local ou même via internet. Une personne utilisant les nouvelles technologies ne peut pas se passer de gadgets, comme l ordinateur, le Smartphone et la tablette de lecture, qui sont devenus indispensables avec l avènement des réseaux sociaux comme Facebook, Linkedin et autres. Ainsi cette personne voudra passer d un gadget à l autre et y retrouver ses mêmes logiciels favoris, elle voudra aussi partager ses centres d intérêt (vidée, musique, photo) avec le monde qui l entoure en utilisant ses gadgets. De même à l échelle de l entreprise comme à l échelle de la personne, les métiers s appuient sur des systèmes informatiques pour plus d efficacité en terme d organisation et d optimisation. De plus, ces systèmes sont connectés et la notion de partage de ressources est présente. 5

24 Cependant, la mise en oeuvre du contrôle d accès à toutes les ressources informatiques (fichiers, équipements, logiciels) est un problème qui représente un danger autant à l échelle d une personne qu à l échelle de l entreprise. Il est vrai que pour une personne l ignorance du danger peut s expliquer, car la majorité des personnes qui utilisent ces outils informatiques sont des novices et n appréhendent pas toutes les implications des risques encourus. Par contre dans une entreprise, ce danger commence à être pris en considération du faite de la médiatisation des dommages qu auraient subis d autres entreprises à cause d attaques malveillantes aussi bien à l interne qu à l externe. Ainsi le concept de politique de sécurité de système informatique sur lequel repose le système d information est une chose qui a trouvé une place de choix dans les entreprises. Cette politique de sécurité recouvre plusieurs notions de sécurités à savoir l intégrité des données, la confidentialité, la non-répudiation. Ces notions de sécurités doivent être assurées par un ensemble de mécanismes parmi lesquels le contrôle d accès. La mise en oeuvre de ce dernier pose une vraie problématique ce qui fait qu elle a une place importante dans toute cette architecture de sécurité et pour cette raison elle a sa propre politique. Une aide non négligeable est apportée par la connaissance de certains modèles de contrôle d accès qui entrainent dans leur implémentation une méthodologie de gestions des droits d accès par les administrateurs. 1.3 Architecture de système informatique et modèles de contrôle d accès La conception d un système d information est faite à partir des besoins de l entreprise qui va l utiliser. Ainsi, les architectures des systèmes informatiques varient d une entreprise à l autre. On peut alors remarquer que cette diversité implique l existence de plusieurs manières de faire le contrôle d accès. Donc, il est primordial de savoir quel modèle de contrôle d accès est implémenté dans une architecture d un système donné. Cependant une majorité des technologies informatiques comme les équipements réseaux, les OS 1, les SGBD 2 et les PGI 3, etc. utilisés dans les entreprises sont développées avec des exigences très génériques et ils implémentent leurs propres modèles de contrôle d accès. Dès lors il est pertinent d avoir une bonne connaissance et maitrise des modèles de contrôles d accès les plus rependus et implémentés. 1. Systemes d exploitation, ex : Windows linux 2. Systeme de gestion de base de données 3. progiciel de gestion intégré 6

25 1.3.1 Cadre sémantique pour le contrôle d accès Dans [?] on y décrit un cadre sémantique pour le contrôle d accès afin de pouvoir traduire les modèle de contrôles d accès dans une représentation unique. Définitions et notation Entités : Les entités du système peuvent être réparties en deux ensembles : l ensemble S des sujets, également appelés entités actives, qui correspondent aux entités qui effectuent les actions dans le système, et l ensemble O des objets, également appelés entités passives, qui subissent les actions. Les sujets et les objets sont généralement considérés comme des entités atomiques. Dans certains modèles, on parle d utilisateur plutôt de sujet. Ces deux ensembles ne sont pas nécessairement disjoints : par exemple, un processus peut à la fois être un sujet et ainsi effectuer des opérations, et un objet, dans le cas où un autre processus tente de l arrêter. Exemple : Considérons un système de gestion des ressources. L ensemble S e = {s 1, s 2,..., s n } représente les utilisateurs du réseau, et l ensemble O e = {o 1, o 2,..., o m } représente les ressources (imprimantes, stockage réseau, scanners, etc.). Accès : l ensemble A des modes d accès caractérisent les différents types d accès effectués par les sujets sur les objets. Cet ensemble contient généralement lire, écrire, éxécute. Une approche classique consiste à représenter un accés, noté A par un triplet (s, o, x) signifiant que le sujet s accéde à l objet o selon le mode d accès x. Exemple : Considérons un système de gestion des ressources. L ensemble S e = {s 1, s 2,..., s n } représente les utilisateurs du réseau, et l ensemble O e = {o 1, o 2,..., o m } représente les ressources (imprimantes, stockage réseau, scanners, etc.). L ensemble A e est défini commme le produit cartésien S e O e A, oû A = {lire; ecrire}. Parametres de sécurité : Il est souvent nécessaire d associer de l information aux entités afin de pouvoir exprimer la politique de sécurité et également décrire précisément le systéme. Ces informations sont construites à partir de ce que nous appelerons les paramétres de sécurité, noté par ρ. Exemple : dans la suite de l exemple précédant, chaque utilisateur et chaque ressource peut appartenir à une ou plusieurs équipes de travail (comptabilité, ressources humaines, etc.), et nous introduisons le paramétre de sécurité ρ = {t 1, t 2,..., t k }, où chaque t i reprèsente un nom d équipe. État : Un état représente le système à un instant donné et contient au moins une description de l ensemble des accès courants, c est-à-dire de tous les accès qui ont été acceptés et qui n ont pas encore été relachés. L ensemble des états est noté Σ. 7

26 Fonction de securité : Un état doit également définir un ensemble de fonctions de sécurité, qui relient les différentes entités aux paramètres de sécurité. Étant donné que ces fonctions de sécurité sont spécifiées par les états, elles peuvent être modifiées lors de transitions, contrairement aux paramètres de sécurité, qui sont fixes pour une politique donnée. On definit Υ(σ), σ dans Σ, représente l ensemble des fonctions de sécurité de l état σ. Υ : Σ SF SF : ensembles des fonctions de sécurité. Accès courant : Un accès courant désigne un accès qui a été accepté et qui n a pas encore été relâché. La fonction qui transforme un ensemble d états en un ensemble d accès courants est noté Λ. Ainsi on a : Λ : Σ (A) Oû (A) désigne l ensemble des parties de A. Etant donné un état σ, Λ(σ) représente l ensemble des accés courants du systéme dans l état σ. Exemple : La fonction t s : S e (ρ) (resp. t o : O e (ρ)) associe à chaque utilisateur (resp. ressource) un ensemble d équipes. Un état σ Σ est un triplet (m ; t s ; t o ), où m (A e ) est un ensemble d accés et t s et t o sont les fonctions de sécurité introduites ci-avant. Pour un état σ = (m; t s ; t o ), on a donc Λ(σ) = m et Υ(σ) = (t s ; t o ). Prédicat de securité : Une politique de sécurité spécifie les états sûrs d un système. Ces états sûrs sont caractérisés par un prédicat. On note par Ω le prédicat de sécurité caractérisant un état respectant la politique de sécurité. En effet, l ensemble σ Σ Ω(σ) des états sûrs est noté Σ Ω Exemple : La politique considérée pour la gestion de ressources consiste à imposer que si un utilisateur accéde à une ressource, alors il doit appartenir à une équipe à laquelle appartient la ressource et impose qu un utilisateur ne puisse accéder à plus de trois ressources differentes en même temps. On definit le prédicat Ω e ainsi : σ = (m, t s, t o ) Σ e Ω e (σ) s S e o O e x A e (s, o, x) m t s (s) t o (o) s S e x A e card({o O e (s, o, x) m}) 3 8

27 Politique de sécurité : Une politique de contrôle d accès dans un système informatique est l attribution ou la non attribution de permissions pour accéder à une ressource. Formellement une politique de contrôle d accès P par un quintuple : P = (S, O, A, Σ, Ω). où S est un ensemble de sujets non vide, O un ensemble d objets, A est un ensemble de mode d accès, Σ est l ensemble des états sur lequel le système est mise en oeuvre, et Ω est le prédicat de sécurité qui définit les états sûrs du systéme. Pour implémenter une politique de sécurité dans un système donné, il y a un grand nombre d approches et de philosophies. La création de modèles de contrôle d accès permet de mettre en pratique ces différentes approches et tous les modèles peuvent être retrouvés dans le cadre sémantique décrit dans cette sous-section. Ainsi, nous allons présenter quelques modèles dans la sous-section qui suit Exemples de modèles de contrôle d accès Il existe plusieurs modèles de contrôle d accès bien documentés dans la littérature de la sécurité informatique et de nombreux articles en décrivent un grand nombre d extensions. Un travail exhaustif a été réalisé dans [?] pour décrir les modèles de contrôle d accès les plus utilisés. Dans ce qui suit, nous allons présenter quelques-uns de ces modèles en les classifiants en trois catégories qui sont les modèles classiques, les modèles à rôles et les modèles alternatives. Modèles classiques Modèles discrétionnaires Les modèles de contrôles d accès discrétionnaires sont des moyens de limiter l accès aux objets basés sur l identité des sujets ou des groupes auxquels ils appartiennent. Les accès sont discrétionnaires, car un sujet avec une certaine autorisation d accès est capable de transmettre cette permission à n importe quel autre sujet. Exemples : Liste de contrôle d accès (ACL Access Control List) Avec les ACL, une information est rattachée à chaque objet. Il s agit d une liste qui spécifie pour chaque sujet les droits d accès à cet objet. Voici un petit exemple : On considére l ensemble d objets {toto; titi; tata}, l ensemble de sujets {diane; f lorian}, ainsi que les droits d accès {lecture; ecriture}. Ainsi, l utilisateur diane peut accéder en écriture à l objet tata et en lecture à l objet titi et à l objet toto ; tandis que, l utilisateur florian peut lire et écrire l objet toto et lire l objet titi. 9

28 Objet toto titi tata Liste [(diane,lecture) ;(florian,écriture) ;(floriant, lecture)] [(diane,lecture) ; (florian,lecture)] [(diane, écriture)] Table 1.1: Exemple de liste de contrôle d accès Listes de capacités (capabilities list) Les listes de capacités fonctionnent sur le même principe que les ACL, sauf que les listes de droits d accès sont rattachées aux sujets au lieu des objets. Les capacités sont l autre face de la médaille du discrétionnaire. Chaque sujet a conscience de sa propre existence et de son interaction avec le monde. Exemple : En reprenant les mêmes sujets, objets et droits d accès que ci-dessus, voici l exemple repris en capacités : sujet diane florian liste [(toto,lecture) ;(titi,lecture) ;(tata,écriture)] [(toto,lecture) ;(titi,lecture) ;(toto,écriture)] Table 1.2: Exemple de Les listes de capacités Dans le modèle de contrôle d accès discrétionnaires on peut décrire le cadre sémantique pour identifier les different éléments du modèle. On a ainsi : Cadre Sémantique S : Sujets O : Objets A : Modes d accès A = S O A : Accès ρ : Paramétre de sécurité Σ : Ensemble des états Λ : Σ (A) : Accès courants d un état Υ : Σ SF : Fonction de sécurité Ω : Prédicat de sécurité Modêle discrétionnaire Utilisateurs fichiers lire, écrire vide Σ d : Ensemble des états σ = (m, f d ) Λ(σ) = m accès courant de σ Υ(σ) = f d : A bool indique si un accès est autorisé ou non. Ω d : prédicat de sécurité a A a Λ(σ) f d (a) = true P [ρ] = (S, O, A, Σ, Ω) : P [ρ] = (S, O, A, Σ d, Ω d ) Politique de contrôle d accès Table 1.3: modèle de contrôle d accès discrétionnaires Modèle mandataires Le contrôle d accès mandataire est exprimé en termes de niveaux de sécurité associés aux sujets et aux objets et à partir desquels sont dérivées les actions autorisées. 10

29 Il est utilisé lorsque la politique de sécurité des systèmes d information impose que les décisions de protection ne doivent pas être prises par le propriétaire des objets concernés, et lorsque ces décisions de protection doivent lui être imposées par ledit système. Ces particularités sont : le modèle est fortement centralisé et il est rigide, mais contrôlable. Comme exemples, on peut citer le modèle de Bell et LaPadula [?] qui est utilisé principalement dans les environnements militaires à cause de son contrôle centralisé, et il permet à l administrateur du système de définir des privilèges pour protéger la confidentialité et l intégrité des ressources dans le système. Les politiques obligatoires les plus fréquemment utilisées sont les politiques multiniveaux. Ces politiques reposent sur des classes de sécurité affectées aux informations et des niveaux d habilitations actées aux utilisateurs. Modèles à rôles Modèle RBAC RBAC (Role Based Access Control ) est présenté dans [?]. Le principe de ce modèle est d offrir un accès à l information selon les rôles assignés aux sujets. Dans ce modèle, le rôle est le concept principal, les privilèges sont accordés à un rôle et si ce rôle est associé à une ou plusieurs entités, alors les entités obtiennent les privilèges indirectement à travers les rôles. Le cadre sémantique de RBAC est donné dans le tableau 1.4. Dans le modèle RBAC [?], on fait une distinction entre les sujets et les utilisateurs. En effet, on considère un ensemble d utilisateurs U comme étant l entité qui peut initier une ou plusieurs sessions dans le système considéré. C est la notion de session qui correspond à l ensemble S des sujets dans RBAC. Ainsi, la fonction user permet d associer un utilisateur à une session. Dans RBAC l ensemble O des objets est complètement arbitraire et les modes d accès classiques (lire, écrire, exécuter, etc.) sont aussi utilisé sur les objets. RBAC introduit la notion de permission. Une permission met en relation des opérations, ici identifier aux modes d accès, et des objets. On note par P l ensemble des permissions. P permet de considérer des modes d accès spécifique à certains objets. Exemple : soit S = {s 1, s 2, s 3, s 4 } et O = {o 1, o 2 }. P = {(a 1 ; o 1 ), (a 1 ; o 2 ), (a 2 ; o 1 ), (a 2 ; o 2 )} avec a i A. Dans le modèle RBAC le paramétre de sécurité ρ rbac regroupe l ensembles des utilisateurs U, car la notion d utilisateur va servir à spécifier un rôle associé à un sujet, l ensemble des rôle noté R et une relation d ordre partiel R. Un état appartenant à Σ rbac constitu un ensemble d accès courants m et les fonctions de sécurité suivantes : user qui permet d associer un utilisateur à un sujet ; role qui permet de faire le lien entre un utilisateur et les permissions qui lui sont associées. Cela est réalisé par les deux relations UA et P A. 11

30 Cadre Sémantique Modêle discrétionnaire S :Sujets user : S U S : Ensemble de sessions ou de sujets U : Ensemble d utilisateur user : fonction qui permet d associer un utilisateur à une session, c est-à-dire à un sujet. O : Objets O : Objets A : Modes d accès lire, écrire, executer A = S O A : Accès A = S O A P A O P : ensemble des permissions ρ : Paramètre de sécurité ρ rbac = (U, R, R ) R :ensemble des rôles, R : relation d ordre partiel sur R R R R Σ : Ensemble des états σ : Un état σ Σ σ = (m, user, UA, P A, roles) Λ : Σ (A) : Accès courants d un état Λ(σ) = m accès courant de σ Υ : Σ SF :Fonctions de sécurité Υ(σ) = {user, UA, P A, role} UA U R :affectation d utilisateurs aux rôles P A P R :affectation de permission aux rôles roles : S (R) : roles actif d un sujet. Ω : Prédicat de sécurité Ω : prédicat de sécurité s S roles(s) ER(s, UA) ER(s, UA) = {r R r r R r (user(s), r ) UA P [ρ] = (S, O, A, Σ, Ω) : P [ρ] = (S, O, A, Σ rbac, Ω rbac ) Politique de contrôle d accès Table 1.4: Modèle RBAC roles qui définit l ensemble des rôles actifs d un sujet à un instant donnée. RBAC impose que les rôles actifs associés à un sujet, c est-à-dire à une session, appartiennent à l ensemble des rôles "autorisés" pour l utilisateur qui a lancé cette session. Ainsi le prédicat de sécurité Ω rbac respect la propriéte suivante : s roles(s) ER(s, UA), ER(s, UA) = {r R r r R r (user(s), r ) UA} Il est important de noter que la propriété indique qu un sujet peut activer un rôle qui n est pas en relation avec son utilisateur suivant UA, grâce à l ordre partiel R. En pratique pour mettre en ouvre un modèle RBAC, il faut bien définir les rôles, cette définition peut être faite en se basant sur les données des services RH d une entreprise. En effet, un rôle 12

31 peut être créé sur la base du service et du lieu de travail d un employé. Cette approche permet de générer une matrice qui fait l attribution automatique des droits d accès pour un nouvel employé. Comme exemple, si un infirmier est affecté dans le service de chirurgie dans un nouvel hôpital, il se voit automatiquement attribuer les droits d infirmier en chirurgie qui vont lui permettre de jouer pleinement son rôle. Extensions du modele RBAC Il existe de nombreuses extensions faites sur le modèle RBAC. Nous allons donner un exemple d extension du modèle RBAC qui introduit la notion de risque et de délégation c est le Risk-RBAC ( [?]). Il est important d introduire une relation d ordre en fonction de l importance des objets et de la dangerosité des actions sur ces objets. Ainsi une évolution du modèle RBAC a été faite dans l article Risk Analysis in Access Control Systems [?] pour introduire la notion de risque dans RBAC. Le modèle RBAC R est défini comme RBAC en y ajoutant la fonction de sécurité RF et un ensemble de niveaux de confiance C. RF est une fonction d analyse de risque. Le principe est d affecter un niveau de confiance à un utilisateur u U noté CNF (u) : U C. Et pour tous les rôles on calcule le niveau minimum de confiance noté MLC(R) : R C. la valeur du risque relatif à un utilisateur u et un rôle R noté rv(u, R) et est comprise entre 0 et 1 et est calculée de la manière qui suit : 0, si CNF (u) MLC(R) rv(u, R) = CNF (u) 1 MLC(R), sinon Dans cet article, la notion de délégation et du risque relatif à cette délégation y sont introduits. Cette notion désigne le risque engendré sur les objets de u 1 si u 1 délégue son rôle à u 2, ce risque est noté par del_rv(u 1, u 2 ) et il est calculé comme suit : Concepts alternatifs 0, si CNF (u 1 ) CNF (u 2 ) del_rv(u 1, u 2 ) = 1 CNF (u 1) CNF (u 2 ), sinon Il existe plusieurs autres molèles de contrôle d accès qui répondent à une diversité de besoins en terme de sécurité. Nous pouvons en cité quelques un : OrBAC (Organization-Based Access Control) [?] : le modèle de contrôle d accès basé sur l organisation est un modèle RBAC avec l introduction des concepts de vue, d activité et d organisation. Cela a pour objectif de définir une politique de contrôle d accès indépendante de son implantation. Pour se faire, OrBAC fait une abstraction des sujets en rôle, des actions en activité et des objets en vue. 13

32 T-RBAC (Temporal Role Bsae Access Control) a été développé par ELISA BERTINO et ANDREA BONATTI [?]. Le modèle T-RBAC permet de règler les problèmes des rôles qui dependent du temps. (RelBAC Relation-Based Access Control) [?] : le modèles de contrôle d accès basé sur les relations entre les sujets. Ce modèle a un grand avenir dans les modes des reseaux sociaux via internet. La connaissance des différents modèles de contrôle d accès qui sont implémentés dans chaque système informatique est un atout non négligeable pour les administrateurs de sécurité, car cette connaissance aide dans la définition de procédure d audit et des validations des droits d accès. 1.4 Processus d audit et de validation des droits d accès. Dans un système informatique, la mise en place d une politique de sécurité et des dispositifs de gouvernance ne suffisent pas pour garantir un bon niveau de sécurité et une réponse aux besoins de gestion des risques relatifs aux métiers. Ainsi pour maintenir le niveau de sécurité à un niveau acceptable, il est important de mettre en place une stratégie de contrôle qui va intégrer l ensemble des facteurs qui entre en jeu dans la structure de l entreprise, dans le métier, et le contrôle d accès. Sur ce plan de contrôle, on retrouve un ensemble de processus d audit et de validation de droits d accès. Le processus d audit des droits d accès est une manière d avoir des photographies permanentes des accès courants. L action d audit est souvent très ponctuelle dans l entreprise or cette action peut ou doit être associée à l action de monitorage des droits d accès et d une action de validation permanente. De ce fait, l audit des droits d accès peut être défini comme étant des actions d analyse des droits d accès et de leurs validations. Il aboutit généralement à un constat qui révèle la cohérence des droits d accès vis-à-vis de la politique de sécurité. En général, le processus de cette validation d un droit d accès est une procédure administrative et fait appel à des composants de l entreprise qui ne sont pas dans le métier de la sécurité informatique. Ce processus est décrit souvent sous la forme d un protocole. La mise en place d un processus de validation doit prendre en compte certains paramètres dont les plus importants sont : L identification des référentielles des sources de données personnelles aux différentes populations (interne, externe, clients, visiteurs, etc.) et ces référentielles doivent être très fiable. La désignation du responsable de la définition du processus de validation. 14

33 La définition des règles de séparation des pouvoirs en conformité avec le règlement du secteur d activité. L identification et la formalisation de la gestion du cycle de vie des droits d accès (arrivée, départ, mutation d une entité). Engagement fort de la direction et du ménagement dans l élaboration du processus de validation. Dans la gestion des identités le CLUSIF démontre que ce processus de validation est établi sous forme de workflow. De plus, on y fait l illustration du cas de référencement d un nouvel utilisateur qui arrive dans une entreprise. Les actions identifiées sont : embauche dans une entrepise Référencement dans le systeme de gestion de la paye. attribution d un bureau Référencement dans la base du service logistique, attribution d un numéro de téléphone Réferencement dans la base théléphonique, attribution d un ordinateur, d un identifiant et d un mot de passe Réferecement dans le systeme bureautique. attribution d un badge pour accès au locaux Réferencement dans le système de gestion des badges, droits d accès sur une application Réferencement dans la base de l application. etc. L ajout d un nouvel utilisateur montre qu un worklfow de validation des droits d accès doit prendre en compte le plan organisationnel d entreprise. Il est donc important de disposer d une bonne description de tous les utilisateurs, de leurs tâches et de leurs unités d affectation au sein de l entreprise. Pour accompagner les entreprises dans la gestion du contrôle d accès, des normes ont été créées. Nous pouvons citer : La norme ISO/CEI [?] est une norme publiée en 2005 par l ISO 4. On y présente un ensemble de mesures ou des règles de bonnes pratiques destinées ont la sécurité informatique. Dans le chapitre 11, la version ISO/27002 :2005 et le chapitre 9 de la version ISO/27002 :2013, ISO donne les mesures pour le contrôle d accès sur les systèmes d information. Ainsi, la manière d assurer la protection des systèmes réseau, de détecter les activités non autorisées y est décrite et, également des conseils d utilisation d appareil mobile y sont fournis. Cette norme indique également les différents niveaux de responsabilité des utilisateurs et comment ils doivent, en conséquence, gérer leurs informations d authentification. Les bases sont fournies aux administrateurs pour écrire des politiques de sécurité dédiés au contrôle d accès. 4. ISO : Organisation internationale de normalisation 15

34 Cobit 5 [?] est une norme proposée par l ISACA 6 pour fournir une orientation aux entreprises et aux institutions gouvernementales dans la gestion de la sécurité informatique, la gestion des risques, le pilotage d activités d audits, etc. Cobit propose également des mesures pour évaluer la gestion et l audite du contrôle d accès. La TCSEC 7 [?] est une norme qui a été définie par le département de la défense des États-Unis pour fournir un cadre d évaluation des systèmes informatiques. Cette norme donne également la description des différentes implémentations des modèles de contrôle d accès. Le pragmatisme militaires fait que la structure de cette norme est sous la forme d une liste de critères, de définitions et de hiérarchisation de l information. On y trouve également des outils d analyse et d évaluation. On constate que l adoption d une norme permet aux entreprises d avoir un cadre de référence de bonnes pratiques, mais cela ne permet pas d automatiser la gestion du contrôle d accès. Les administrateurs de sécurité ont besoin d outils pour les aider dans leurs tâches. Il existe plusieurs entreprises œuvrant dans la sécurité informatique qui propose des outils de gestion des droits d accès sous un label plus générique qui est la gestion des identités et des habilitations. Dans la section qui suit, nous en présentons quelques uns qui peuvent être d une aide précieuse pour les administrateurs de sécurité informatique. 1.5 Outils de gestion des droits d accès Il existe plusieurs applications pour la gestion des droits d accès dans le marché de la sécurité informatique. Elles sont caractérisées principalement par le fait qu elles soient en majorité dédiées à un écosystème particulier. De plus, les constructeurs d équipements ou de systèmes informatiques créent leurs propres outils de gestion de contrôle d accès qui ne sont pas, en général, compatibles avec d autres systèmes. Ci-après nous citons quelques outils SetACL Studio Cet outil a été développé par une entreprise allemande du nom de Helge Klein GmbH qui porte le nom de son fondateur Heige Kein. SETACL gère les permissions des utilisateurs et pemet de faire des audits sur les droits d accès. Il fait tout ce que les outils intégrés à Windows peuvent faire, et bien plus encore. Il est intrinsèquement automatisable et programmable par scripts. La version SETACL COM offre toutes les fonctionnalités d un langage de programmation compatible COM 8 (C#, Visual 5. Cobit : Control Objectives for Information and related Technology, en français Objectifs de contrôle de l Information et des Technologies Associées 6. ISACA : Information Systems Audit and Control Association 7. TCSEC : Trusted Computer System Evaluation Criteria 8. COM : Component Object Model est un standard de Microsoft 16

35 Basic, C++, Delphi, PowerShell, VBScript, etc). De plus, tous les objets sont pris en charge, à savoir les fichiers, les processus, les registres et les services. 17

36 18 Figure 1.1: Caputure d écrant de SetACL Studio

37 1.5.2 Windows Identity Foundation Cet outil aide les développeurs.net à construire des applications qui extériorisent l authentification des utilisateurs de l application, l amélioration de la productivité des développeurs, le renforcement de la sécurité des applications. Les développeurs peuvent profiter d une plus grande productivité, en utilisant un modèle d identité unique simplifié et qui est basé sur des jetons d identités. Ils peuvent créer des applications plus sécurisées avec un modèle d accès mono-utilisateur. Ils introduisent, ainsi, des implémentations personnalisées et, permettant aux utilisateurs finaux d y accéder en toute sécurité via des applications logicielles ou sur sur des servics en nuagique. Enfin, ils peuvent profiter de plus de souplesse dans le développement d applications grâce à l interopérabilité intégrée qui permet aux utilisateurs, applications, systèmes et autres ressources de communiquer via des jetons d identité. Windows Identity Foundation permet de développer des outils de gestion des droits d accès et cela pour toutes les entités du système d exploitation Windows (application, service, registre, etc.) IBM Security Identity and Access Assurance Le logiciel IBM Security Identity and Access Assurance propose une solution complète pour assurer la gestion des identités et des accès, ainsi que la vérification de la conformité des utilisateurs. Anciennement connu sous le nom de IBM Tivoli Identity and Access Assurance, qui regroupe quatre logiciels IBM qui administre, sécurise et surveille l accès aux ressources par les utilisateurs. IBM Security Identity and Access Assurance est une solution qui gère les droits d accès de plusieurs systèmes d exploitation, et d équipements réseau ; de plus la gestion des droits d accès prend en charge plusieurs applications et services tels que les SGBD et les applications métier. Cet outil est multiplateforme ; cela lui confère un atout certain. Seulement le prix de la solution et les coûts de formation pour son utilisation sont énormes ; donc très peu compétitif au niveau des PME SAM Jupiter SAM Jupiter est développé par Beta Systems Software AG qui est une entreprise très importante dans le marché des logiciels de gestion des identités. SAM Jupiter permet d assurer une transparence dans les traitements relatifs à la gestion des identités, et contribue à la gestion du contrôle d accès. Les utilisateurs peuvent suivre précisément les tâches d administration préalablement exécutées dans SAM Jupiter, afin de savoir quelle personne a approuvé ou a accordé les autorisations d accès, et sur quelle base un utilisateur spécifique s est vu allouer ses droits d accès. 19

38 SAM Jupiter est principalement basé sur une analyse du fichier log des événements du système d exploitation. Il est supporté par les systèmes d exploitation Linux et Wimdows. Il est moins complet que IBM Security Identity and Access Assurance, mais jumelé avec d autres outils, il peut être très puissant LinID LinID est la seule suite logicielle de gestion d identité "Open Source", qui permet de gagner en efficacité et en sécurité dans la gestion des données d identité, d accès et d habilitation. Cette suite est développée par l entreprise LinAGORA, une entreprise française qui oeuvre dans le monde de l open source. LinID est principalement utilisé dans l environnement Windows où est déployé un domaine actice directory OpenIDM OpenIDM permet aux entreprises d automatiser la gestion du cycle de vie de l identité de l utilisateur en temps réel, y compris la gestion des comptes utilisateurs et des privilèges d accès aux applications. Léger et agile, OpenIDM a été conçu pour aider les entreprises à assurer la conformité aux politiques et aux exigences réglementaires dans l ensemble des entreprises, Cloud, réseaux sociaux et mobiles. ForgeRock est la structure qui a porté le projet d OpenIDM. OpenIDM est fait en java et il gère les systèmes Windows et Linux. De plus, son architecture client-serveur permet une souplesse dans son déploiement. Il est basé sur un outil de provisioning nommé OpenICF qui est un framework que l on peut utiliser avec java et.net principalement. Figure 1.2: architecture de OpenIDM 20

39 1.5.7 Quest One Identity Membre de la suite de Quest Software de l entreprise DELL, Quest One Identity assure le contrôle des accès et l administration des identités et améliore, en plus, la vérification de conformité en consolidant l automatisation et la génération de rapports. Quest One vous permet de trouver rapidement et facilement les comptes et les utilisateurs qui possèdent des droits d accès inadaptés. Quest One Identity permet effectuer une découverte approfondie des environnements Active Directory et accéder à la gouvernance de toute l entreprise. Il fonctionne sous Windows et est optimisé pour une architecture basée sur Active directory de Windows Étude comparative Le caractère commun des outils cités plus haut est que les politiques de sécurités sont statiques et, en plus, l initiative d audits et de validations des droits d accès est du ressort des administrateurs de sécurité souvent suite aux résultats de l analyse des journaux après une alerte de sécurité. D où la nécessité de bâtir des outils qui disposent d une intelligence de validation faisant intervenir le moins possible l humain. De plus, ces outils devront avoir une base théorique et formelle. Dans l état de l art, on peut trouver des travaux allant dans le sens d implémenter un outil de validation automatique des droits d accès en se basant sur une théorie et un formalisme mathématique. Nous avons retenu de présenter un modèle de gestion des droits d accès basé sur UML 9 qui est le plus proche de notre approche dans la réalisation d un outil de gestion et d audit des droits d accès. 1.6 Modèle UML pour la gestion du contrôle d accès. UML (langage de modélisation unifié [?] est comme sont nom l indique un langage de modélisation basé sur plusieurs types de diagrammes et qui a eu un grand succès dans le génie logiciel avec l orienté objet. Il est évidant que le l aura de UML dans le domaine de l industrie du logiciel et dans le monde accadémique a inspiré plus d un à utiliser cette technologie dans les domaines de la sécurité informatique et plus particulièrement dans le domaine de la gestion du contrôle d accès. Plusieurs modèles de contrôle d accès sont décrits sous forme de diagrammes UML. De plus, le succès de UML combiné au succès du modèle RBAC ont fait que dans la littérature ce couple est très pressant. 9. UML : Unified Modeling Language 21

40 Ainsi, dans [?] Gilles Goncalves et de Fred Hémery introduisent une modélisation très pertinente du modèle RBAC. En effet, dans ce travail, on trouve une méthodologie d implémentation du modèle RBAC, qui va de la définition des rôles à la mise en place de la stratégie de gestion. Un des travaux sur la gestion des droits d accès qui nous interpelle particulièrement est celui de David Basin et de Jürgen Doser [?] où ils décrivent un modèle basé sur UML permettant de faire une description des spécificités de sécurité d un système d information et donne un outil pour générer, automatiquement, une architecture de sécurité intégrant ces spécificités. L idée de base est de prendre un modèle d un système et d y ajouter un modèle de sécurité pour engendrer un nouveau modèle appelé modèle de transformation. Ce dernier permet de transformer l infrastructure existante en y ajoutant une surcouche sécuritaire et respectant des spécifications de sécurité. En utilisant UML, l approche du Model Driven Security est de subdiviser le contrôle d accès en deux types de décision : Une décision déclarative : cette partie représente toutes les décisions d accès qui ne dépendent que d information statique. Une décision programmée : cette partie représente toutes les décisions d accès qui dépendent d information dynamique satisfaisant les contraintes d autorisations pour les différents états du système. Cette approche est basée sur modèlisation UML de RBAC, et de la programmation par contrainte que fournit UML via son le langage OCL. Ainsi on définit une représentation des relations de modèle RBAC avec le diagramme de classe de la figure 1.3. La figure 1.3 représente les décisions déclaratives et la partie programmée qui est une instanciation de ce diagramme de classe à laquelle on applique les contraintes liées à chaque objet. On a alors un test à faire sur chaque décision de contrôle d accès en vérifiant que pour chaque décision déclarative, la contrainte qui lui est associée est respectée. Ce modèle est très intéressant dans la gestion des droits d accès durant la phase de conception d un système donné. Cependant, dans un écosystème hétérogène où l on n a pas la maitrise des différents systèmes, il est préférable de disposer d un outil qui fait abstraction des différents systèmes et qui, grâce à la description de la politique de sécurité, pourra récupérer l ensemble des droits d accès et en faire l analyse de conformité. 22

41 Figure 1.3: SecureUML Méamodel 1.7 Gestion sémantique des droits d accès : AMO Le Web 2.0 a entrainé une émergence des applications Web dans le monde de l entreprise. Cette révolution a permis le développement de plusieurs plates-formes pour la collaboration, le télétravail et les réseaux sociaux. Ainsi, les wikis, les blogues, les forums et d autres outils de partage de contenu sont devenus incontournables pour une entreprise numérique. La particularité de ces systèmes est qu ils sont faits pour être conçus et déployés par des personnes qui ne sont pas dans le domaine de la conception d applications web. Car, pour les créer, on utilise d autres applications Web de gestion de contenues qui sont connues sous le nom de CMS 10. Comme tous systèmes informatiques, la problématique de la gestion des droits d accès est à considérer pour assurer la sécurité de ces outils. C est dans ce cadre que [?] a défini une ontologie pour la gestion sémantique des droits d accès au contenu avec l utilisation d une ontologie nommée AMO (Access Management Ontologiy). Sans rentrer dans les détails sur les ontologies que nous allons développer dans le chapitre suivant, nous allons vous présenter AMO. L idée qui est à la base de AMO est de fournir un mécanisme de gestion des droits d accès dans les systèmes de gestion de contenu qui reposent sur des serveurs web sémantiques. Ce mécanisme est réalusé grâce à une ontologie qui décrit des classes et des propriétés permettant d annoter les objets (pages web, article, images, etc.) sur lesquels le contrôle d accès sera réalisé. 10. CMS : Content Management System, en français on parle de système de gestion de contenu : SGC 23

42 Les systèmes de gestions de contenu étant différents de la gestion des droits d accès, AMO permet de définir des concepts génériques et un ensemble de propriétés pour être en mesure d annoter des ressources sans que cela ait un impact sur le type système de gestion de contenu utilisé. Ainsi, en identifiant les principes que partagent tous les systèmes de gestion de contenu, AMO utilise les entités suivantes : Les agents : ces derniers sont associés aux utilisateurs, groupes d utilisateurs, services qui interagissent avec le système. Les roles. Dans le cas de systèmes d édition collaborative tels que les wikis ou les CMS, il s agit des rôles d invité, de contributeur, d administrateur. On peut retrouver d autres rôles suivant le type de système. Les actions autorisés : les actions qui peuvent être réalisé sur une ressource sont la création, la lecture, la modification et la destruction de contenu, la modification des droits d accès, la modification de la liste des agents autorisés sur une ressource et la modification du type d accès défini pour une ressource. Les types d accès aux ressources : une ressource peut être publique (les utilisateurs ont accès en lecture et écriture), privée (seuls les agents autorisés ont accès en lecture et écriture) ou semi-privée (accès libre en lecture, accès en écriture uniquement pour les agents autorisés). Les actions autorisées pour un agent sur une ressource dépendent du role de l agent et/ou du type d accès défini pour la ressource. Cela permet de construire une ontologie qui a comme métaclasses Role, Action et AccessT ype et chaque métaclasse est défini comme suit : Role composé des classes Administrator, Contributor et Guest. Action est la métaclasse de ReadContent, ModifyContent, DeleteContent, ModifyUser- Rights, ModifyAccessType et ModifyAuthorizedAgents. AccessT ype est la métaclasse des classes Private, Public et SemiPublic. De plus les classes Document, Agent et la sous-classe AuthorizedActionOnResource de la classe Action permettent de compléter l ontologie et de définir les propriétés suivantes : creator et hasauthorizedagent : associent un agent à un document ; hasrole : associe un rôle à un agent ; hasactiononresource : associe une action à un rôle ; hasaccesstype : associe un type d accès à un document ; hasauthorizedactiononresource : associe une instance de AuthorizedActionOnResource à un agent. 24

43 Figure 1.4: Ontologie AMO hasdocument et hasaction : associent à une instance de AuthorizedActionOnResource respectivement un document et une action. Ainsi, dans la figure 1.4 on peut voir une représentation de l ontologie AMO. AMO permet de détacher l annotation du contrôle d accès sur les ressources vers l ontologie en définissant une stratégie de contrôle et cela de façons déclaratives sous forme de règles. Comme exemple de règles, on a : un membre d un groupe hérite du ou des rôle(s) attribués à son groupe ; le créateur d une ressource est un agent de cette ressource ; Avec un système de requêtes permettant d interroger l otologie, on peut, avant chaque accès, vérifier la validité de la règle qui est appliquée à une ressource. Ainsi, on construit un système contrôle d accès grâce à AMO. AMO est utilisé par le wiki sémantique SweetWiki [?] que les auteurs de [?] ont développé pour illustrer l intégration aux technologies du web sémantique. AMO peut être déployé sur la plupart des CMS qui sont orientés dans les web sémantiques. Cette approche permet d introduire une formalisation de la gestion des droits d accès. Elle est limitée, car elle se restreint au web sémantique. Mais c est une approche qui est innovatrice dans la mesure ou elle intègre l idée d abstraction pour généraliser la gestion des droits d accès dans les systèmes de gestion de contenu. 25

44 1.8 Conclusion Dans ce chapitre nous avons décrit les besoins qu ont les administrateurs en sécurité informatique sur la gestion des droits d accès et les problèmes liés à l attribution des droits d accès. Nous avons également mis en relief des descriptions informelle et formelle du contrôle d accès, qui facilite la compréhension des différents processus d audit et de validation des droits d accès qui nous a permis de vous présenter quelques outils et approches qui existent dans le marché informatique. Cette revue globale du contrôle d accès dans la sécurité informatique représente un point de départ pour positionner nos travaux et entamer la partie suivante où l on présente notre modèle de gestion basé sur les ontologies. 26

45 Chapitre 2 Modèle de gestion basé sur le concept des ontologies. 2.1 Introduction Dans ce chapitre, nous allons mettre en relief le choix des ontologies pour faire la validation automatique des droits d accès. Pour ce faire, il est important de connaitre la définition et la description d une ontologie avant d en concevoir une qui va servir comme base pour bâtir un outil de validation de droit d accès. Ainsi, nous allons motiver notre choix sur l utilisation des ontologies ; par la suite nous présenterons les différents langages utilisés dans la définition des ontologies ; pour finir par la définition les concepts du domaine du contrôle d accès et de la création d un ontologie qui va nous servir à implémenter notre prototype logiciel de gestion et de validation des droits d accès. 2.2 Pourquoi une ontologie Le choix de l utilisation d une ontologie pour développer un outil de gestion et de validation des droits d accès est motivé par la place qu occupent les ontologies dans l informatique en général et l informatique décisionnelle en particulier. De ce fait, les ontologies représentent une brique essentielle dans l architecture de notre logiciel Définition d une ontologie Les ontologies, à l origine d une branche de la philosophie qui s intéresse à la nature et à l organisation de la réalité, correspondent à ce qu Aristote appelait la Philosophie première, c est à dire la partie de la métaphysique qui s intéresse à l être en tant qu être, par opposition aux philosophies secondes qui s intéressent à l étude des manifestations de l être (Garf, 1996). 27

46 En informatique, la littérature fournit plusieurs de définitions du mot ontologie. Ces définitions, dans leur diversité, offrent des points de vue à la fois différents et complémentaires. Cependant, une définifion qui fait autorité a été faite par Greber et s énonce comme suit : "Une ontologie est la spécification d une conceptualisation. [...] Une conceptualisation est une vue abstraite et simplifiée du monde que l on veut représenter". Pour nous, l ontologie se définit comme étant un ensemble de termes hiérarchiquement structurés, conçu afin de décrire un domaine qui peut être utilisé comme un squelette de base pour les bases de connaissances. Une ontologie est basée sur la logique descriptive, or, cette dernière est un langage de représentation de connaissance qui peut être utilisée pour représenter la connaissance terminologique d un domaine d application d une manière formelle et structurée. Notre objectif étant de faire une représentation du contrôle d accès en informatique donc, naturellement, l utilisation d une ontologie est justifiée Les constituantes d une ontologie Une ontologie est composée d un ensemble structuré de concepts d un domaine bien déterminé. Elle est structurée comme un dictionnaire formel qui définit les concepts par leurs relations sémantiques et de subsomption. Ainsi, une ontologie est composée de : Classes qui énumèrent l ensemble des concepts d un domaine ; Attributs qui décrivent les caractéristiques et les propriétés d une classe. On parle parfois de rôles. Facettes qui sont des restrictions sur les attributs. Instances qui constituent une base de connaissances. Ils sont les vrais individus ou données réels de l ontologie Langages des ontologies Historiques Pour la création et la manipulation des ontologies, il existe plusieurs langages de spécification spécialisés ; nous pouvons citer : OKBC (Open Knowledge Base Connectivity ) [?] : API permettant d accéder à des bases de connaissance ; KIF (Knowledge Interchange Format ) [?] : langage destiné à faciliter des échanges de savoirs entre systèmes informatiques hétérogènes. Loom : langage de représentation des connaissances dont le but avoué est de «permettre la construction d applications intelligentes» ; 28

47 DAML-ONT (DARPA Agent Markup Language Ontology ) [?] : fondé sur XML, résulte d!un effort du DARPA (Defense Advanced Research Projects Agency) pour l expression de classes plus complexes que le permet RDF-S ; RDF/RDF-S (Resource Description Framework) : RDF est un modèle de graphe destiné à décrire de façon formelle les ressources Web et leurs métadonnées, de façon à permettre le traitement automatique de telles descriptions. RDF-S fournit des éléments de bases pour la définition d ontologies ou vocabulaires destinés à structurer des ressources RDF. [?] OWL (Web Ontology Language) [?] est un langage de description d ontologies conçu pour la publication et le partage d ontologies sur le Web sémantique. Langage OWL Dans le cadre de notre projet, nous nous sommes particulièrement intéressé au langage OWL [?]. Ce dernier est inspiré de DAML (US DARPA Agent Markup Language) projet Américain et OIL (Ontology Inference Layer) projet Européen. Comme RDF, OWL est un langage XML, ce qui lui confère un caractère d universalité syntaxique ; de plus il permet : une représentation très riche des connaissances : propriétés, classes avec identité, équivalence, contraire, cardinalité, symétrie, transitivité, etc. de faire un raisonnement sur ces connaissances en s appuyant sur la logique descriptive (LD). Ce dernier point est un aspect très important dans le choix du langage OWL. En effet, la logique descriptive a fait ses preuves dans la représentation des politiques des sécurités en informatique, elle fournit un support très riche et satisfait aux conditions suivantes : l expressivité ; la clarté ; la lisiblé ; la non embiguité ; et l extenciblité. Un document OWL est une ontologie : Qui peut avoir un identificateur unique représenté par un URI (Uniform Resource Identifier) ; qui contient : des faits qui sont des descriptions d individus ; des axiomes qui fournissent la descriptions des concepts. 29

48 Un documment a la forme suivante : ontologie ::= Ontology()[ontologieID]{directive}directive ::= axiome f ait L ontologie OWL la plus simple que l on peut écrire est : ontology() Notons, que OWL comprend les 2 classes pré-définies : owl : T hing : correspondant à owl : Nothing : correspondant à. Exemple : La phrase "Un docteur est une personne qui peut avoir des enfants." se traduit en LD et en OWL par : LD : P ersonne aenf ant.(docteur aenf ant.docteur). OWL : <owl:class> <owl:intersectionof rdf:parsetype="collection"> <owl:class rdf:about="#personne"/> <owl:restriction> <owl:onproperty rdf:resource="#aenfant"/> <owl:toclass> <owl:unionof rdf:parsetype="collection"> <owl:class rdf:about="#docteur"/> <owl:restriction> <owl:onproperty rdf:resource="#aenfant"/> <owl:hasclass rdf:resource="#docteur"/> </owl:restriction> </owl:unionof> </owl:toclass> </owl:restriction> </owl:intersectionof> </owl:class> Owl se décline en trois sous langages que sont : 1. OWL-Lite. OWL-Lite correspond à la famille SHIF(D) [?] de la logique descriptive. Il se caractérise par les attributs suivants : simple, facile à programmer, raisonnements rapides ; 30

49 expressivité limitée à des hiérarchies de classification et de fonctionnalités de contraintes simples de cardinalité 0 ou 1 (relations fonctionnelles). Exemple : OWL-Lite ne permet pas d exprimer : "une personne a une seule adresse, mais peut avoir un ou plusieurs prénoms". 2. OWL-DL. OWL-DL correspond à la famille SHOIN(D) [?] de la logique descriptive et il a comme particularité : d être une logique de description d où le DL ; expressivité élevée : contient tout OWL avec certaines restrictions ; raisonnements : pouvant être faits dans une logique descriptive ; plus lents que dans OWL-Lite ; complétude du calcul : toutes les inférences sont assurées d être prises en compte ; décidabilité : tous les calculs des formules OWL-DL sont évaluées et se terminent en un temps fini ; 3. OWL-Full. OWL-Full comprend tout OWL-DL avec en plus tout RDF et il se caractérise par : une expressivité maximale ; une compatibilité complète avec RDF/RDF-S ; des raisonnements souvent : très complexes ; très lents ; incomplets ; indécidables. Pour notre prototype de gestion et de validation nous utiliseront OWL-DL ; Langage OWL-DL OWL-DL est basé sur la logique descriptive en particulier SHOIN(D) [?]. D pour Data property. D une manière générale les éléments fondamentaux de la logique descriptive sont : les éléments du monde réel sont représentés par des concepts, des rôles et des individus. les concepts et rôle possédent une description structurée à laquelle est associée une sémantique. 31

50 toutes les manipulations faites sur les concepts et les rôles sont réalisées en accord avec la sémantique. deux types de connaissances sont prises en compte : les concepts avec leurs composants, et les faits ou assertions, où interviennent les concepts et les instances de concepts. la relation de subsomption qui organise concepts et rôles en hiérarchies. le Raisonnement qui est une opération de classification et d instanciation. Il existe plusieurs familles de logique descriptive : AL, ALN, ALC, SH, ALCN, ALCQ, ALCF, SHOIN, SHIQ, SHIF. La différence entre une famille et une autre se résume principalement en terme d expressivité : Restriction de cardinalité N. Exemple : Homme 2aEnfant designe un homme qui a 2 enfants ou plus. Restriction de cardinalité qualifiée Q. Exemple : Homme 2aEnfant.F emme désigne un homme qui à 2 enfants ou plus et ces enfants sont des femmes. Énumération O. Exemple : Homme {Jean, P aul} désigne un homme qui à Jean et Paul comme enfant avec Jean et Paul deux individus du concepte Homme. Inversion I. Exemple : F emme P ersonne Homme pour décrire qu une femme est une personne et ne peut pas être un homme. Dans la famille de logique descriptive ALN les concepts et les rôles se décrivent ainsi : concept ::= identif icateur concept concept identif icateur role.concept entier positif role entier positif role. role ::= identif icateur Il existe deux types de concepts : Les concepts primitifs où les rôles déterminent des conditions nécessaires d appartenance à l extension du concept. Les concepts définis où les rôles déterminent des conditions nécessaires et suffisantes d appartenance à l extension du concept. Exemples : Un Homme est une Personne. Une Femme est une Personne. Aucune Femme n est un Homme et vice-versa. Une Équipe est (définie comme) un Ensemble ayant au moins 2 membres qui sont tous des Personnes. 32

51 Une Petite-équipe est (définie comme) une Équipe ayant au plus 5 membres. Une Équipe-moderne est (définie comme) une Équipe ayant au moins 4 membres, ayant au moins 1 chef, et dont tous les chefs sont des Femmes. Représentation en logique descriptive ALN : P ERSONNE (primitif) EN SEM BLE (primitif) HOMME P ERSONNE(primitif) F EMME P ERSONNE(primitif) (F EMME HOMME) ÉQUIP E := (ENSEMBLE ( membre.p ERSONNE) ( 2membre))(déf ini) P ET IT E ÉQUIP E := (ÉQUIP E ( 5membre))(défini) ÉQUIP E MODERNE := (ÉQUIP E ( 4membre) ( 1chef) ( chef.f EM M E))(déf ini) Avec Owl-DL la famille de langage descriptive utilisée est le SHOIN(D). famille SHOIN(D) la famille SHOIN(D) est une famille de langages très expressive comme nous le montre la figure 2.1. Dans SHOIN(D) on a comme constructeurs de concept : Atomic : A, B en général un concepte atomique est designé par son nom. Not : C. And : C D. Or : C D. Exists : R.C. For all : R.C. At least : R.C ( R). At most : R.C ( R). Nominal : {i 1,..., i n }. Pour les Rôles nous avons : Atomic : R ; Inverse : R. Ainsi pour définir une base de connaissance ou une ontologie dans SHOIN(D), les axiomes sont définis comme suit : 33

52 Figure 2.1: Familles de loguique descriptive Axiomes de concepts : Subclass : C D ; Equivalent : C D. Axiomes de Rôles : Subrole : R S ; Transitivity : T rans(s). Axiomes assertionnel : Instance : C(a) ; Role : R(a, b) ; Same : a = b ; Different : a b. Ainsi il est facile de décrire une base de connaissance avec ces différents axiomes. Exemple : Concept : Humain parentde.humain Orphelin Humain enf antde.v ivant. Individu : Orphelin(Louis) parentde(jean, Louis). 34

53 Dans SHOIN(D) le (D) pour Data property signifie que l on distingue deux types de rôles : ceux liant deux individus, et ceux associant un individu à un littéral. OWL-DL correspondant à logique descriptive SHOIN(D), on peut definir un tableau de correspondance des constructeurs entre les deux langages. Voir tableau 2.1. Constructeur de OWL DL Constructeurs de SHOIN(D) 2 DL Exemple 3 Thing Nothing intersectionof(c 1... C n ) C 1... C n Humain Homme unionof(c 1... C n ) C 1... C n Docteur Avocat complementof(c) C Homme oneof {x 1 }... {x n } {P aul} {Jean} Rôle P P allvaluesfrom (C) P.C aenf ant.docteur P somevaluesfrom (C) P.C aenf ant.avocat P hasvalue (x) P.{x} aenf ant.alice P maxcardinality (n) np 1aEnf ant P mincardinality (n) np 2aEnf ant Table 2.1: Correspondance OWL-DL et logique descriptive SHOIN(D) Notation et Conventions Pour décrire le langage OWL-DL nous utiliseront un notation BNF avec comme conventions : symboles terminaux : représentés en italique ; symboles non-terminaux : représentés en caractères gras ; alternatives : séparées par des barres ( ) ; éléments facultatifs (pouvant apparaître au plus une fois) englobés par des crochets ([...]) ; éléments répétitifs (pouvant apparaître un nombre illimité de fois, incluant zéro) : englobés par des accolades ({...}). OWL-DL Syntaxe des axiomes de classe axiome : := Class([classe] modalité description) modalité : := complete partial description : := classeid restiction unionof ({description}) intersectionof ({description}) complementof ({description}) oneof ({individuid}) Avec OWL-DL il est éegalement possible de déclarer des classes équivalentes, des classes disjointes, et des axiomes spécialisé dont l énumeration et la Hierarchie : 35

54 axiome : := DisjointClasses(description description {description}) EquivalentClasses(description {description}) SubClassOf (description {description}) EnumeratedClass(classeID {IndividuID}) Nous remarquons ainsi que les classes impliquées dans les axiomes peuvent avoir une description plus ou moins complexes. Deplus, la déclaration de classes équivalentes peut contenir une seule classe et cela reviendrais à déclarer une classe (Class(ClasseID partial)) ; Il est également a noté qu un axiome peut être défini de plusieurs manières. Exemple : En Logique descriptive : AnimalDeCompagnie AnimalDomestique (Chien Chat) (Chien Chat) AnimalDomestique Animal AnimalSauvage En OWL-DL(forme 1) Namespace(local = <http :// Ontology( Class(local :Animal partial) Class(local :AnimalSauvage partial) Class(local :AnimalDeCompagnie complete local :AnimalDomestique unionof( local :Chien local :Chat)) DisjointClasses(local :Chien local :Chat) Class(local :AnimalDomestique complete local :Animal complementof(local :AnimalSauvage))) En OWL-DL(forme 2) Namespace(local = <http :// Ontology( Class(local :Animal partial) Class(local :AnimalSauvage partial) Class(local :AnimalDeCompagnie complete intersectionof( local :AnimalDomestique unionof( local :Chien local :Chat))) 36

55 DisjointClasses(local :Chien local :Chat) Class(local :AnimalDomestique complete intersectionof( local :Animal complementof(local :AnimalSauvage)))) Dans la première forme, la classe AnimalDomestique demeure anonyme, et est locale à l axiome ; tandis que dans la deuxième forme l identificateur AnimalDomestique est fourni et permet de la réutiliser dans plusieurs endroits. OWL-DL Syntaxe des axiomes de Restriction restriction : := restriction( propriétéindividuid élémentrestrictionindividu) restriction(propriétéindividuid élémentrestrictionindividu) élémentrestrictionindividu : := allvaluesfrom (description) somevaluesfrom (description) value (individuid) cardinalité élémentrestrictionlittéral : := allvaluesfrom (datarange) somevaluesfrom (datarange) value (littéral) cardinalité cardinalité : := mincardinality (entiernonnégatif) datarange : := typelittéralid maxcardinality (entiernonnégatif) cardinality (entiernonnégatif) rdfs :Literal oneof {littéral} Avec OWD-DL nous pouvons avoir n importe quelle valeur entière dans une restriction de cardinalité, et la spécification d un individu pour remplir un rôle. 37

56 OWL-DL Syntaxe des axiomes de propriété axiome : := DatatypeProperty( propriétélittéralid {super((propriétélittéralid)}) [Functional] { domaine (description )} {range(datarange)} DatatypeProperty( propriétéindividuid {super((propriétéindividuid)} {inverseof ((propriétéindividuid)} [Functional InverseFunctional FunctionalInverseFunctional Transitive] {domaine(description)} {range(datarange)}) Les axiomes d équivalence dans les propriétés ont comme syntaxe : axiome : := EquivalentProperties( propriétélittéralid propriétélittéralid {(propriétélittéralid)} SubPropertyOf (propriétélittéralid propriétélittéralid) EquivalentProperties(propriétéIndividuID propriétéindividuid{propriétéindividuid)} SubPropertyOf (propriétéindividuid propriétéindividuid) OWL-DL les Faits Pour être complet dans la description de OWL-DL il est défini une syntaxe pour les faits qui représente des instances des concepts ou classe. fait : := individu SameIndividual(individuID individuid {individuid}) DifferentIndividuals(individuID Ainsi nous avons : individuid {individuid} individu : := Individual([individuID] {type(description)}) {valeur}) valeur : := value(propriétéindividu IndividuID) value(propriétéindividu Individu) value(propriétélittéral Littéral) Un langage OWL-DL nous permettra d appliquer des raisonnements très complexes juste en utilisant des moteurs de raisonnement aussi appeler moteurs d inférence que disposent les API de programmes informatiques dans la gestion des ontologies ( [?]). Parmi ces moteurs, nous pouvons citer : Racer, FaCT, Pellet, FaCT++, Surnin, Hoolet, F-OWL. La différence de ces moteurs d inférence réside dans le langage d implémentation, la famille de la logique descriptive supportée, la décidabilité, et le sous-langage OWL supporté. Avec cette richesse que nous fournissent les ontologies et le langage OWL-DL, nous pouvons bâtir un outil assez complet et générique afin de prendre en compte la majorité des architectures informatiques et rénales pressantes dans les entreprises. 38

57 2.2.5 Éditeurs d ontologie Il existe plusieurs outils pour éditer et visualise les ontologies, on peut citer : SWOOP [?] qui est développé par l université du Maryland et qui supporte le standard RDF et OWL ; OntoEdit [?] qui est un éditeur qui intégre l aspect collaboratif de création d une ontologie. HOZO [?] développé au japon est un editeur graphique d ontologie de haut niveau et permet de gérer des ontologies volimineuses. Protégé [?] qui est l outil de référence dans la création et le développement des ontologies. Protégé ( [?]) est une platforme qui permet de créer, de gerer et d implémanter des ontologies. Elle est tres modulaire et peut intégrer plusieurs plug-ins pour la représentation graphique des ontologies. Il a été créé à l université Stanford et est très populaire dans le domaine du Web sémantique et dans monde de la recherche scientifique. De plus, Protégé est un logiciel conçu en java et il existe une API programmable pour définir et traiter les ontologies dans d autres projets java. Ainsi, pour notre projet nous utiliseront Protégé pour créer notre ontologie et grâce au plug-in graphique, nous allons extraire plusieurs représentations graphiques de notre ontologie. 2.3 Liste des concepts intervenant dans le contrôle d accès. L objectif de l utilisation d une ontologie étant de donner un caractère générique à un outil de validation de droit d accès et de faire abstraction du modèle de contrôle d accès sous-djacent. Ainsi les concepts représentés dans notre ontologie seront ceux que partagent tous les modèles de contrôle d accès en y introduisant un caractère hiérarchique. La liste des concepts peut alors être dans un premier temps composée de sujets, objets, et modes d accès. Ces trois éléments sont les composants que partage tous les modèles de contrôle d accès : "un sujet accède a un objet avec un mode d accès." Ajoutons une hiérarchie et une spécialisation aux concepts de cette liste et nous obtenons : Sujet : Un sujet est atomique ou composé. Un sujet atomique représente un utilisateur. Un sujet composé représente un groupe d utilisateurs. Un groupe est constitué de plusieurs utilisateurs et/ou plusieurs groupes. Mode d accès : 39

58 Un mode d accès est atomique ou composé. Un mode d accès est dit composé s il est composé de plusieurs accès atomiques et/ou d accès composés. Objet : Pour les objets, nous laissons le concept tel qui l est. Naturellement s il y a une politique de contrôle d accès, elle est mise en oeuvre pour autoriser au refuser des accès. Ainsi nous pouvons ajouter le concept de permission. Une permission est le concept qui autorise ou refuse qu un sujet accède à un objet avec un mode d accès donné. Un regroupement de permissions représentera un nouveau concept que l on nommera un rôle. Ainsi les concepts qui composent notre ontologie sont les suivants : Groupe. Utilisateur. Sujet. Permission. Rôle. Objet ou ressources pour éviter toute contradiction nous utiliseront le terme ressource en lieu et place du terme objet pour désigner toute entité passive. Action. Action atomique. Action composée. À partir de cette liste de concept, nous allons voir si les modèles classiques de contrôles d accès peuvent être retrouvés via notre ontologie. Pour ce faire, nous allons en faire une description logique. 2.4 Relation entre les différents concepts du contrôle d accès. Les relations entre les différents concepts de notre ontologie se définissent comme suit : Un sujet est un Groupe ou un Utilisateur. Un Groupe est composé au moins d un Utilisateur ou au moins d un Groupe. Un sujet peut avoir un rôle et tout rôle peut avoir plusieurs permissions. Il existe une permission sur une ressource pour faire une action. Une action est une action atomique ou une action composée, Une action composée est ensemble d actions atomiques. 40

59 En logique descriptive cela donne : U tilisateur Groupe 1 estcomposede.u tilisateur 1 estcomposede.groupe Sujet U tilisateur Groupe Ressource Action_Atomique Action_Compose 1 estcomposede.action_atomique 1 estcomposede.action_compose Action Action_Atomique Action_compose Role 1 ap ourp ermission.p ermission Sujet 1 ap ourrole.role Role 1 roleaf f ecterasujet.sujet ApourRole roleaf f ecterasujet P ermission 1 permissionaf f ecterarole.role P ermissionsurressource.ressource F aireaction.action permissionaf f ecterarole ap ourp ermission Alors les propriétés que nous disposons sont : estcomposede : qui exprime les éléments qui composent un concept ; ap oup remission : affecte une ou plusieurs permissions à un rôle ; ap ourrole : affect un ou plusieurs rôles à un sujet ; permissionsurresource : est la permission affectant une ressource donnée ; fairaction : permet de lier l action que la permission affecte ; permissionaf f ecterarole : est une symétrie de la propriété ap oup remission qui indique à quel rôle la permission est affectée ; roleaffecterasujet : est une symétrie de ap ourrole qui indique à quel sujet un rôle est affecté. La simplicité de nos concepts et de leurs relations pose la problématique suivante : serons-nous capables de retrouver toutes les représentations des droits d accès de l ensemble des modèles de contrôle d accès? La réponse est ; pour tous les modèles de contrôle d accès la représentation des droits d accès se résume en : un sujet a la permission de faire une action sur une ressource ; or, si notre objectif est de représenter une telle phrase via notre ontologie il suffit de l interroger et de voir si les réponses obtenues nous permettent de construire une telle phrase. Ainsi pour un sujet donné s 1 qui a une permission p 1 pour faire l action a 1 sur la sur ressource ress 1 nous avons : 41

60 soit le rôle rol 1 telque : rol 1 role et rol 1 role roleaffecterasujet.{s 1 } ap oup remission.p 1 ; donc r 1 étant affecté à s 1, et est composer de la permission p 1 alors peut dire que s 1 à la permission p 1 pour faire l action a 1 sur la ressource res 1. Ce type relations nous permettra de retrouver les modèles de contrôle d accès comme le modèle mandataire, discrétionnaire, et les modèle Rbac. Pour ce faire on a : Modèle madataire : Pour retrouver le modèle mandataire, il suffit de créer autant de rôles qu il y a de niveau d accès sur les ressources, affecter à chaque sujet le rôle de son niveau d accès et l ensemble des rôles de niveau d accès inférieur. Modèle discretionnaire : Pour le modèle discrétionnaire, il suffit de créer la relation : un rôle possède une permission. Modèle RBAC : Les fonctions d affectation de rôle à un sujet et les fonctions d affectation d une permission a un rose son pressant dans notre ontologie. 2.5 Graphe de représentation de l ontologie. Avec Protege nous obtenons une hiérarchie de classe illustrée par la figure 2.2 et la représentation de notre ontologie est détallée dans la figure 2.3 : Figure 2.2: Hierarchie des classes 42

61 estcomposerde Ontologie Graph estcomposerde Groupe Action Composée Utilisateur Sujet apourrole Action Action Atomique faireaction Resource roleaffecterasujet permissionsurressource Permission Rôle apourpermission permissionaffecterarole Figure 2.3: Graph Ontologie Simplifié 2.6 Raisonnement sur la validation des droits d accès. Pour faire un raisonnement sur la validation des droits d accès, il faut être en mesure d écrire la politique de sécurité sous la forme d une requête DL-Query. Cette dernière est appliquée à l ontologie et le résultat donne la liste des droits d accès et leurs contextes qui respectent la politique de sécurité. L idée est d utiliser la capacité des ontologies à faire des résonnements. Ainsi, les contextes d instanciations de l ontologie feront que, pour chaque droit d accès, une validation se fait s il respecte la relation avec la politique de sécurité. 2.7 Conclusion Après une analyse de l état de l art dans le chapitre précédent, nous avons, dans ce chapitre, expliqué les éléments qui ont motivé le choix de développer un outil de validation en utilisant les ontologies. Ainsi, la réponse à la question qui vise à savoir pourquoi une ontologie est un choix pertinent permet de bien identifier le contexte et le cadre de notre travail. Dans un second temps, nous avons construit notre propre ontologie qui va être le centre de notre outil de validation automatique des droits d accès. Cela nous permet d aborder le chapitre suivant pour présenter notre outil de validation automatique du contrôle d accès. 43

62

63 Chapitre 3 Implémantation de l outil de traitement 3.1 Introduction Dans ce chapitre, nous présentons un prototype de notre logiciel informatique qui permet de faire la validation automatique des droits d accès dans un écosystème informatique hétérogène. En nous basant sur notre ontologie décrite dans le chapitre précédent, et des outils de provisioning, nous allons décrire l architecture de notre prototype, montrer les mécanismes utilisés pour la validation des droits d accès et donner un exemple de cas d utilisation. 3.2 Architecture Le prototype de validation de droit d accès est une application faite en JAVA et FLEX, il est composé des éléments suivants : Outils de provisioning : Les outils de provisioning ont la charge de récupérer les différents objets qui représentent un droit d accès dans une infrastructure donnée. Ils permettent également de standardiser la représentation des différents droits d accès en XML plus précisément en XACML. L ontologie : L ontologie permet de faire une analyse des droits d accès pour détecter le respect ou non d une politique de sécurité donnée. Generateur de rapport : Le générateur de rapport permet de générer un document PDF qui résume les accès invalides par rapport à la politique de sécurité et décrit les corrections à apporter sur les droits d accès affin de les corriger. 45

64 Architecture Générateur de rapport Politique de sécurité stocker Ontologie instanciée Moteur de validation des droits d accès Opérations BD stockant la politique de sécurité P 1 et Qui a accès à quoi? Pour la politique de sécurité donnée quels sont les accès valides? Quel est le rôle pour un utilisateur donné? Outil de provisioning Traducteur XML Linux Script Windows Script Routeur Script Appli Script Mac Script Windows Objet Linux Objet Network Objet Software Objet Figure 3.1: Architecture de l outil de validation 46

65 Le fonctionnement consiste à récupérer les objets qui représentent les droits d accès dans les différents systèmes informatiques grâce à des scriptes spécifiques à une plateforme ou à un système d exploitation, et avec ces objets, instancier notre ontologie pour lister les droits d accès valides et non valides suivant une politique de sécurité donnée. Une série d interrogations peut être réalisée grâce à des requêtes DL-query pour répondre à des questions précises. L outil permet également de générer un rapport au format PDF. La récupération des droits d accès est primordiale dans le processus de validation, car elle est la base de tout le traitement qui permet d instancier l ontologie. La représentation de droit d accès étant variable d un système à l autre, un standard de représentation est nécessaire. 3.3 Outils de provisioning Les outils de provisioning représentent le principal fournisseur de données de l outil de validation. En effet, ils ont la charge de collecter les droits d accès dans les différents systèmes qui composent l écosystème informatique de l entreprise. Ainsi, pour prendre en charge un environnement hétérogène, les outils de provisionieng se décomposent en plusieurs modules qui sont dédiés à un système d exploitation, à une application ou à un équipement réseau spécifique. Il se pose, alors, un besoin de standardiser la représentation des droits d accès des différents systèmes avant de les acheminer vers l ontologie. Ainsi, les outils de provisioning traduisent les différents droits d accès en XACML [?] qui est un standard XML pour la représentation des politiques de contrôle d accès. Le choix de XACML est motivé par le fait qu il permet de représenter une politique de sécurité et possède toute la sémantique pour la traduction des objets de type accès des différents systèmes à analyser vers un format XML. Pour se faire, on utilise une formalisation d un sous-ensemble de XACML-3.0 que nous avons spécifié dans une grammaire BNF voir table 3.1. Cette grammaire est assez riche pour décrire tous les droits d accès recuperer dans les différents systèmes informatiques. Dans la section 3.4, nous allons voir en détail comment cette traduction est effectuée pratiquement. Mais avant intéressons-nous au mécanisme de validation de droits d accès dans la section qui suit. 3.4 Mécanisme de validation de droits d accès Le mécanisme de validation des droits d accès peut se diviser en trois parties qui sont l instanciation de l ontologie, l écriture de la politique de sécurité de l entreprise en une ou plusieurs requêtes DL-query et l appel a un raisonneur pour vérifier la cohérence des droits d accès 47

66 P DP policies ::= P olicyset P olicy P olicyset ::= < POLICYSET P Sheader > [Description] T argets P olicies [Obligation] [Advice] < / POLICYSET > P olicy ::= < POLICY P header > [Description] T argets Rules [Obligation] [Advice] < / POLICY > Policies ::= Policy Policy Policies Rules ::= < RULE Rheader > [Description] [T argets] [Condition] [Obligation] [Advice] < / RULE > P Sheader ::= PolicySetId = string Version = number PolicyCombiningAlgId = P alg P header ::= PolicyeId = string Version = number RuleCombiningAlgId = Ralg Rheader ::= RuleId = string Effect = REffect P alg ::= only-one-applicable Ralg Ralg ::= deny-overrides permit-overrides first-applicable ordered-permit-overrides REffect ::= Permit Deny T argets ::= < TARGET > [MatchAny] < / TARGET > MatchAny ::= < AnyOf > matchall < / AnyOf > < AnyOf > matchall < / AnyOf > MatchAny MatchAll ::= < AllOf > Matches < / AnyOf > < AnyOf > Matches < / AllOf > MatchAll Matches ::= Match Match Matches Match ::= < Match MatchID = MatchId > < AttrValue > value < / AttrValue > < AttributeDesignator ADHeader / > < / Match > MatchId ::= string-equal integer-equal string-regexp-match integer-greater-than... ADHeader ::= Category= Subject AttributeId = AttSubject DataType= type MustBePresent= boolean Category= resource AttributeId = AttResource DataType= type MustBePresent= boolean Category= action AttributeId = AttAction DataType= type MustBePresent= boolean Category= environment AttributeId = AttEnv DataType= type MustBePresent= boolean Subject ::= access-subject recipient-subject intermediary-subject... AttSubject ::= subject-id subject-id-qualifier key-info authentication-time... AttResource ::= resource-id target-namespace AttAction ::= action-id implied-action action-namespace AttEnv ::= current-time current-date current-datetime type ::= x500name rfc822name ipaddress dnsname xpathexpression string boolean double time date datetime anyuri hexbinary base64binary Condition ::= < Condition > BooleanExpression < / Condition > Table 3.1: Grammaire BNF d un sous ensemble de XACML

67 instanciés suivant la politique de sécurité. Instanciation de l ontologie : Cette étape permet de peupler l ontologie par les données récupérées via les outils de provisionning. Il est effectué d une manière automatique par l API de gestion de l ontologie. En effet, en utilisant des parseurs XML, les droits d accès sont affectés à leur classe respective avec les propriétés qui les caractérisent. Cette opération peut prendre beaucoup de temps d où la pertinence de le faire cette opération une fois et par la suite d identifier juste les instances qui ont été modifiées pour mettre à jour notre ontologie. On peut remarquer que l ontologie nous sert en même temps de base de donnée, car elle permet de stocker les droits d accès déjà récupérer dans les différents systèmes de l entreprise. Cet aspect est intéressant, car elle peut permettre de voir l évolution de l implémentation de la politique de sécurité dans les différents systèmes au fil du temps et d avoir des points de comparaison pour des opérations d audit. Écriture des requêtes de la politique de la sécurité : La politique de sécurité de l entreprise est généralement décrite dans un document texte qui est compréhensible des cadres et autres personnels de l entreprise. Ainsi, il est indispensable de réécrire ce document pour une exploitation informatique. On peut représenter la politique de sécurité d une manière précise et complète avec un langage comme XACML. De plus, il est nécessaire d exploiter cette politique pour générer un certain nombre de requêtes qui nous permettront d interroger automatiquement l ontologie. En effet, les requêtes sont une série de questions que l on pose à l ontologie pour vérifier la validité ou nons des droits d accès. Pour ce faire, prenons un exemple simple de politique de sécurité qui stipule que le groupe des administrateurs ont accès juste en lecture à un fichier test.txt et que le super utilisateur root de chaque machine seul a le droit d écriture sur le fichier test.txt. Il est possible de générer une requête DL-Querry pour identifier tous les droits d accès qui ne respectent pas cette politique. Ainsi on a : les éléments que l on doit retrouver comme instance pour notre ontologie : Action Atominque : read, write, execute (pour lecture, écriture et exécution) ; Utilisateur : root ; Groupe : root ; Permission : accept, deny ; Rôle : néan ; Resource : test.txt ; Appel à la commande ls -l de Linux pour visualiser les droits d accès sur le fichier test.txt : # ls -l -rw-r--r--. 1 root root 0 30 nov. 13:45 test.txt 49

68 Réécriture de la politique en une requête DL-Query : Groupe has(root,apourrole(role has(,apourpermission(prermision has(access,permissionsurressource(ressource has(test.txt)) and FaireAction (Action has(read))))and Permision has(deny,permissionsurresource (Ressource has(test.txt)) and FaireAction (Action has(execute) and Action has(write)))))) and Utilisateur has(root,apourrole(role has(,apourpermission(prermision has(access,permissionsurressource(ressource has(test.txt)) and FaireAction (Action has(read) and Action has(write))))and Permision has(deny,permissionsurresource (Ressource has(test.txt)) and FaireAction (Action has(execute)))))) Ainsi, le résultat de cette requête sera composé d instances qui doivent être qu un utilisateur root pour le droit d écriture, le reste des utilisateurs pour le droit de lecture et aucun utilisateur pour le droit d exécution du fichier. Appel à un raisonneur : Le raisonneur permet de faire l analyse de conformité des instances de l ontologie et de générer tous les liens possibles entre toutes les instances de l ontologie. Ainsi, l ontologie se dote d une intelligence par laquelle, d une manière autonome, elle peut répondre aux différentes interrogations que les requêtes provenant de la politique de sécurité nous ont fournies. Une fois, les trois étapes ont été réalisées, un rapport est généré pour donner la liste des droits d accès valide et la liste des droits d accès non valident. Nous verrons dans la section qui suit un exemple pour mettre en évidence toute le processus de l outil. 3.5 Exemple Traduction de droits d accès Linux vers XACML Avant de donner un exemple de traduction d un droit d accès Linux vers XACML, commençons par une explication de la représentation des droits d accès Linux. Représentation des droits d accès sous Linux Les concepts de base pour le contrôle d accès dans Linux Dans les systèmes d exploitation Linux, le contrôle d accès se fait en suivant le modèle DAC. En effet un objet (fichiers, processus d exécutions) appartient à un propriétaire dit Owner et 50

69 Figure 3.2: linux strcture basic des droits d accès est également associé à un Groupe dit Owner Group. Le reste des utilisateurs dit Others sont pris en compte dans la définition des droits d accès sur un objet. À l exception du super-utilisateur qui a un contrôle total sur tous les objets du système, seul le Owner peut lire, écrire ou exécuter ses objets ; et seul lui peut donner des accès au Owner Group et aux Others. Plus de détails sur le contrôle des droits d accès sur Linux se trouvent dans [?]. Les droits d accès attribués à un objet sont représentés par trois jeux de trois caractères qui appartiennent à l ensemble : {r, w, x, }. Le premier des jeux de trois caractères, désigne le droit d accès du Owner, le second jeu de trois caractères représente les droits d accès du Owner Group et dernier jeu de caractères désigne les droits attribuer au Others comme le montre la figure3.2. Ainsi on obtient trois blocs de trois caractères. Le premier caractère de chaque bloc donne le droit de lecture si sa valeur est égale à "r", sinon sa valeur est égale à " " et l accès en lecture n est pas autorisé. Le second caractère de chaque bloc indique le droit d accès en écriture sur un objet ; si sa valeur est égale à "w" alors l accès en écriture sur un objet est autorisé ; sinon la valeur est égale à " ". Le troisième caractère d un bloc désigne l autorisation d exécuter un objet si la valeur du caractère est égale à "e" et de refuser l exécution de l objet si la valeur est " ". La structure minimale de l attribution des droits d accès sur un objet est mise en exergue sur la figure3.4. En effectuant la commande ls -l, on peut retrouver les droits d accès des différents fichiers comme le montre la figure3.3. Figure 3.3: Droit d accès Linux : Example Dans cet exemple, le premier caractère indique le type de l objet ( pour un fichier normal, d pour un répertoire, l pour un lien symbolique, b pour un bloc disque et c un caractère d un équipement). Les caractères suivants donnent les droits d accès pour respectivement le Owner, Owner Group et Others. La valeur -rw-r r- indique que le Owner a les droits de lecture et d écriture, le Owner Group et le Others ont le droit de lecture. Sous Linux, les droits d accès peuvent être modifiés par le Owner où le super-utilisateurs en utilisant la commande chmod. 51

70 Gestion des listes de contrôles d accès sous Linux Durant les dernières années, plusieurs versions récentes de système Unix-Like ont été patchées pour intégrer les ACLs (Access Control List) [?] qui permet d implémenter le modèle mandataire (MAC). Cette extension permet de rendre plus flexible et plus fine la gestion des droits d accès. Les ACLs ne remplacent pas le modèle standard de Linux, mais font une extension et garantis la rétrocompatibilité. Les ACLs peuvent être divisés en deux groupes : l ACL minimal, voir la figure3.4, représente le modèle traditionnel du contrôle d accès Linux. Figure 3.4: ACL Minimale L ACL étendue, voir figure 3.5, introduit la notion de masque (Mask), d utilisateurs nommés (Named User) et de groupes nommés (Named Groups). Ainsi, il vient enrichir les ACL minimales. Les droits d accès concernant le Owner et Others restent effectives. Cependant, pour les autres entrées (Named User, Named Groups, et Named User et Owner Groups) les droits d accès sont attribués s ils sont également attribués au masque, sinon, leurs droits sont considérés comme étant masqués. Figure 3.5: ACL Etendue Il n est pas difficile de comprendre le rôle des utilisateurs nommés et des Groupes nommés qui vont nous permettre d attribuer individuellement des droits à, respectivement, des utilisateurs 52

71 et des groupes. Les commandes Linux getfacl et setfacl permettent de visualiser et de modifier les ACLs. Exemple : Prenons le fichier exemple.txt avec les droits d accès rw pour l utilisateur lionel appartenant au groupe "users". Si l utilisateur courant nommé test appartenant au groupe test veut lire le fichier exemple.txt, cela va se traduire par un échec. La capture du Shell Linux suivant le confirme. #id uid=1003(test) gid=1000(test) #ls -l exemple.txt -rw lionel users :36 exemple.txt # cat exemple.txt cat: exemple.txt: Permission denied l execution de la commande getfacl donne : Nous pouvons remarquer que seul l utilisateur lionel a des droits d accès sur le fichier, le reste des utilisateurs n a aucun droit sur le fichier exemple.txt. Cependant grâce au ACL étendu, il est possible de donner l accès en lecture et en écriture à l utilisateur test. Pour ce faire, on utilise la commande setfacl. Ainsi dans un shell on obtien : # getfacl exemple.txt file: exemple.txt owner: lionel group: users user::rw- group::--- other::--- # setfacl -m user:test:rw exemple.txt # ls -la exemple.txt -rw-rw lionel users :36 exemple.txt # getfacl exemple.txt... user::rwuser:test:rwgroup::--- mask::rw- other::--- 53

72 Ainsi, avec le masque rw qui est identique pour l utilisateur test membre du groupe users il est possible de de lire et d écrire le fichier exemple.txt. SELinux SELinux est un module de sécurité introduite dans la famille des systèmes d exploitation Linux pour implémenter le modelé de contrôle d accès RBAC dans la gestion des droits d accès Linux. Ainsi, il permet de définir des niveaux de sécurité pour classer les applications du système. Ce procédé augmente la finesse du contrôle d accès, car dans Selinux, on attribue un niveau de confidentialité pour chaque objet du système. Les différentes entités de SeLinux sont : Les Types. Le type est l attribut le plus important pour un objet, car les décisions d accès se basent sur le type de l objet source et le type de l objet cible à accéder. Le type est un attribut que l on assigne à un objet (fichier, port réseau, etc.) et un processus ; dans ce cas, on parle de domaine au lieu de type. La présence du suffixe _t désigne un type : Exemple sysadm_t. Les Roles. Dans SELinux, la notion de rôle est différente de la notion de rôle dans RBAC. En effet, le rôle est un intermédiaire entre un utilisateur et un type ou un domaine. Le rôle décrit un ensemble de types qu un utilisateur peut utiliser. D une manière générale, le rôle est identifié par le suffixe _r. Exemple : soit un administrateur qui utilise un système pour faire une tache qui est dans le rôle staf_r ; s il veut faire des taches d administration système, il doit explicitement entrer dans le rôle sysadm_r. Les Identités. Les identités sont similaires à la notion de nom d utilisateur dans Linux (username). À chaque identité SELinux, on attribue un ensemble de rôles. En général, l identité d un utilisateur ne change pas durant une session. Dans SELinux, il existe des identités génériques qui peuvent être attribuées à chaque utilisateur. Ainsi, tout utilisateur Linux est mappé à un utilisateur SELinux par la politique actuelle. Ce mappage permet l héritage des droits et restrictions de l utilisateur SELinux correspondant. Le contexte. Dans SELinux, le contexte est très important dans le mécanisme d attribution ou refus d accès sur un objet. Un contexte SELinux est présenté de la manière suivante : identite : role : type. La commande ls Z permet de visualiser les contextes. Exemple : # ls -Z drwxr-xr-x root root system_u:object_r:bin_t bin drwxr-xr-x root root system_u:object_r:boot_t boot drwxr-xr-x root root system_u:object_r:device_t dev drwxr-xr-x root root system_u:object_r:etc_t etc On remarque que le rôle générique object_r est attribué à tous les objets. Les autres champs du contexte nous permettent de déduire que les fichiers qui ont la même identité system_u et ont des types différents : bin_t, boot_t, device_t et etc_t. 54

73 Chaque objet (ou processus) est confiné à son propre type (ou domaine), et ne pourra pas accéder à des informations qui ne sont pas placées dans le bon contexte. Il est possible de connaître la liste des contextes à laquelle peut accéder un processus à l aide de la commande sesearch. Traduction en XACML Dans une machine qui tourne sur Linux, la représentation des droits d accès peut être visualisée en lançant la commande "ls -l". Cela nous donne un ensemble d information sur les permissions d accès et la propriété d un objet du système d exploitation. Exemple : -rw-r--r-- 1 root staff 0 18 fv 20:19 exemple.txt on peut extraire les droits d accès suivant : U tilisateur Actionpermise Actionnonpermise root rw x staf f r wx any r wx En utilisant XACML pour représenter cet objet de droits d accès Linux, on va s accorder sur les règles suivant : l utilisation de l algorithme de combinaison f ist applicable chaque action permise et action non permise est transformé en une règle XACML avec ses attributs appropriés de subject, resource et action. Ainsi pour notre exemple on obtient en XACML : 55

74 f irst applicable; target : {string equal( exemple.txt, resource.resource id)}; rules : {(deny; target : { string equal(root, subject.subject.id) string equal( x, action.action id)}) (permt; target : { string equal(root, subject.subject.id) string equal( rw, action.action id)}) (deny; target : { string equal(staf f, subject.subject.id) string equal( w, action.action id) string equal( x, action.action id)}) (deny; target : { string equal( w, action.action id) string equal( x, action.action id)}) (permit; target : { string equal( r, action.action id)})} On peut voir le document XACML complet en annexe A Traduction de droits d accès Windows vers XACML Pour comprendre l exemple de traduction des droits d accès Windows vers XACM, nous allons faire une petite description de la représentation de contrôle d accès sous Windows. Le contrôle d accès sous Windows Windows est un système d exploitation qui implémente le modèle de contrôle d accès discrétionnaire. D une manière basique, les systèmes Windows utilisent des listes de contrôle d accès discrétionnaire (DACL : discretionary access control lists) pour renforcer le contrôle des droits d accès sur ces différents objets. Ainsi, l accès à tout objet (fichier, dossier dans NTFS, objet Active Directory, clé de registre, etc.) peut être contrôlé par un descripteur de sécurité. Il existe également la notion de sujet dans les systèmes Windows qui sont composés d utilisateurs, processus, ordinateurs, etc. Ces sujets sont appelés Principal Security dans le modèle de Microsoft et sont identifiables grâce à un SID (Security identifier). Dans la figure3.6, le descripteur de sécurité [?] est constitué : d un entête qui contient les informations sur la version du descripteur et les adresses qui fournissent les positions des DACL et SACL ; d un SID du propriétaire de l objet (Owner SID) ; d un SIDdu groupe primaire qui possède l objet (Primary Group SID) ; 56

75 d un DACL qui décrit les droits d accès pour les utilisateurs et les groupes ; et d un SACL qui permet de contrôler comment l accès est effectué. Figure 3.6: Structure d un descripteur de sécurité Un DACL est une liste de plusieurs ACE (Access Control Entries). Tous les ACEs fournissent les informations de contrôle d accès suivant : Un SID qui identifie un utilisateur ou un groupe ; Un masque d accès de 32-bite qui spécifie le droit d accès. Chaque bit correspond à un droit d accès spécifique qui dépend du type d ACE et qui peut prendre la valeur 1 ou 0. Un ensemble de bits flags qui détermine si les objets fils peuvent hériter de l ACE. Un flag qui indique le type de l ACE [?]. À titre d exemple, si le bit correspondant au droit d accès lire une permission a la valeur 1 et le type de l ACE est Deny, l ACE interdit le droit de lire les permissions de l objet. Si le même bit est à 1 et que le type de l ACE est Allow, ACE autorise la lecture des permissions de l objet. [?] Le format du masque d accès est composé de bits qui correspondent aux types de droits d accès suivant : les droits génériques qui facilitent la portabilité des applications. Exemple : generic read, generic write, generic execute, generic all ; les droits standards qui s appliquent à n importe quel type d objet. Exemple : DELETE (droit de supprimer l object), WRITE DAC (droit de moditier le DACL), WRITE OW- NER (droit de changer le propriertaire de l objet) ; les droits spécifiques qui dépendent du type d objet. Exemple : Traverse Folder/ Execute File (Pour un dossier : Traverse Folder autorise ou interdit la navigation à traverser le dossier pour chercher des fichiers ou des dossiers. Pour un fichier : Execute File autorise ou interdit l exécution du fichier). 57

76 Figure 3.7: Example 1 Le propriétaire d un objet n a pas nécessairement une entrée dans le DACL, mais peut, implicitement, lire et modifier les permissions de son objet. Si un objet ne possède pas de DACL, le système Windows autorise l accès total à tous les utilisateurs ; sinon, le système vérifie les ACE qui sont dans le DACL de l objet. Chaque ACE d un DACL d un objet spécifie le droit d accès permis ou refusé pour l utilisateur qui peut être un simple utilisateur, un groupe ou une session de connexion. [?] Le système examine chaque ACE séquentiellement jusqu à trouver un événement parmi les suivants : Un refus d accès : l ACE refuse explicitement l accès à toute requête initiant une demande d accès listé. Voir Figure 3.8. Un ou plusieurs accès autorisés par les ACEs ; dans ce cas, les droits d accès sont accordés à toute requête initiant une demande d accès. Voir Figure 3.7. Tous les ACEs ont été vérifiés et jusqu au dernier, les ACEs ne donnent pas une réponse explicite d autorisation. Dans ce cas les droits d accès sont simplement refusés. [?] Dans Microsolft Windows, le SDDL (Security descriptor definition language) est le langage utilisé pour définir un format de chaine de caractère pour convertir le descripteur de sécurité en texte comme on peut le voir dans les figures 3.9 et Traduction vers XACML Comme nous l avons fait avec XACML, nous avons besoin d une grammaire BNF pour le SDDL. Ainsi, dans le tableau 3.2, on définit la syntaxe de SDDL. 58

77 Figure 3.8: Example 2 Figure 3.9: Language SDDL Figure 3.10: Language SDDL : ACE 59

78 Security Descriptor ::= { Owner_SID ; Goup_SID ; DACL} DACL ::= {Dacl-flag, ACE} ACE ::= {ACE Type ;ACE Flag ; Rights ;SID } DACL ::= ace :{Ace} ACE Type ::= A D ACE Flag ::= CI OI NP IO ID SA FA Rights ::= GA GR GW GX... SID ::= S domaine-500 S DACL Flag ::= P AR AI AU SY... Owner_SID ::= S domaine Group_SID ::= BA... Table 3.2: SDDL Syntax Windows XACML Security Descriptor = Policies ACE = Rules Rights, SID = Targets ACE :Type = Effect Ralg = first-applicable Table 3.3: Traduction de SDDL vers XACML En utilisant la syntaxe SDDL, on peut alors définir le tableau 3.3 comme table de correspondance entre SDDL et XACML. Après ces deux étapes, on peut donner l exemple de traduction d un droit d accès Windows vers XACML. Ainsi, soit le SDDL du fichier test.txt suivant : O:S G:S D:AI(D;;CC;;;\S ) (A;ID;FA;;;BA) 60

79 En applicable règle de transformations de SDDL vers XACML on obtient : f irst applicable; target : {string equal( text.txt, resource.resource id)}; rules : {(deny; target : { string equal( S , subject.subject.id) string equal( CC, action.action id)}) (permit; target : { string equal( BA, subject.subject.id) string equal( F A, action.action id)}) (permit; target : { string equal( S , subject.subject.id) string equal( GA, action.action id)})} On peut voir le document XACML complet en annexe A Outil de validation Comme le montre la fugure 3.11, l outil de validation se divise en plusieurs partie : 1. Chargeur de fichier XACML pour récupérer les droits d accès à analyser à partir d un fichier XACML existant. 2. Outil de scan réseau pour faire une découverte réseau et cibler les postes sur lesquels on peut récupérer les droits d accès. Cela fait appel, en arrière-plan, aux outils de provisionning. 3. La liste des machines dont les droits d accès seront analysés et donc les droits d accès qui ont été recueillis. 4. La liste des objets à instancier dans l ontologie pour chaque machine. 5. Les boutons de traitement pour débuter la validation. Cette première fenêtre permet de faire l instanciation de l ontologie. Une fois cette étape passée, nous accédons à l interface suivant qui est décrit dans la figure 3.12 où va se faire la validation et les différentes opérations d interrogation de l ontologie. 3.6 AVTAC : Framework pour le contrôle d accès Dans le domaine du contrôle d accès, plusieurs outils peuvent être agrégés pour répondre à une problématique bien particulière. Ainsi, l idée de mettre en place un framework pour le contrôle 61

80 Figure 3.11: Capture d écran n 1 de l outil de validation Figure 3.12: Capture d écran n 2 de l outil de validation 62

81 Figure 3.13: Architecture access validation tool d accès nous est venue et dans [?] nous avons décrit le Framekork AVTAC pour agréger les outils de gestion du contrôle d accès avec des outils d analyse de conformité des politiques de sécurité et des outils de calcul de distance entre des politiques de sécurité et des outils d analyse et corrélation de journaux. La figure 3.13 montre l architecture du Framework AVTAC qui est bâti autour de notre prototype de validation. AVTAC a une architecture qui ressemble à l architecture d un système d exploitation. En effet, par analogie, l ontologie joue le rôle d un noyau, la couche XACML d un Shell et les différents outils qui composent AVTAC jouent le rôle que joueraient les applications dans un système d exploitation. Dans AVTAC, l ontologie joue plusieurs rôles qui sont : Dictionnaire : l ontologie permet d avoir un cadre pour décrire tous les concepts communs qui sont utilisés par les différents outils de AVTAC. Ainsi, on est sûr d avoir la même base de connaissance. 63