|
CONCEPTION ET VERIFICATIN DE LA COHERENCE
D'UNE
POLITIQUE DE SECURITE DANS UN RESEAU
LOCAL
FOTSO TAGNE Carine Ariette
1
Résumé
Les entreprises sont au quotidien exposées aux attaques
qui pourraient ies conduire à des catastrophes diverses. Une poiitique
de sécurité vaiide aiderait ies PME à protéger ieur
système informatique. Le domaine de ia sécurité
étant vaste, nous nous sommes tout particuiièrement
intéressés au contrôie des accès de ieur
réseau informatique. Dans cet articie, nous proposons un premier
modèie permettant d'exprimer de manière moins ambiguë ies
poiitiques de contrôie d'accès basé sur ie modèie
OrBAC. Nous proposons égaiement un second modèie, basé sur
ia iogique de premier ordre, permettant d'évaiuer ieur cohérence.
La poiitique de contrôie d'accès est décrite à
i'aide du iangage XML, puis ies prédicats définissant ies
règies sont extraits et évaiués à i'aide de
JlProiog. L'impiémentation de nos modèies avec ie iangage Java a
permis d'obtenir des résuitats probants.
Mots clés : Contrôie
d'accès, Logique des prédicats, Modèie de
sécurité, OrBAC, Poiitique de sécurité,
Sécurité, XML.
Abstract
Companies are daiiy exposed to attacks that couid iead to
various disasters. A valid sccurity poiicy wiii heip the SME to protect their
computer system. We are particuiariy interested in controiiing the access of
their computer network, because the fieid of security is vast. in this paper,
we propose a first modei to express a iess ambiguous poiicy-based access
controi on OrBAC modei. We aiso offer a second modei, based on first-order
iogic, to assess their consistency. The access controi poiicy is described
using XML, then the predicates defining the ruies are extracted and evaiuated
using JlProiog. The impiementation of our modei with the Java ianguage has
yieided satisfactory resuits.
Keywords : Access Controi, Predicate Logic,
Security modei, OrBAC, Poiicy Security, Security, XML.
1. Département d'Informatique, Université de
Yaoundé I-Cameroun,
caryfotso@gmail.com
2
1 Introduction
De nos jours, la sécurité informatique se
révèle une priorité pour protéger le système
informationnel d'une entreprise. Le contrôle d'accès qui
représente une composante importante de la sécurité des
systèmes, consiste à restreindre l'accès au système
exclusivement aux entités 2 autorisées, en fonction de
leurs niveaux d'accès et d'autorisations ou, de leurs profils
utilisateurs répondant aux règles de sécurité de
l'entreprise. Il est donc indispensable pour les entreprises visant à
protéger l'accès à leur réseau, de définir
leur politique de contrôle d'accès. Il s'agit en effet, de fixer
les règles et procédures destinées à limiter ou
contourner les menaces pouvant affecter l'intégrité, la
disponibilité, la confidentialité de son patrimoine
informationnel.
Afin de spécifier clairement le comportement d'un
système, d'implémenter des mécanismes pour assurer
certains objectifs de sécurité et d'assurer la gestion des
risques futurs, des modèles formels de contrôle d'accès ont
été définis dans la littérature. Ils
décrivent les permissions répondant aux exigences et aux
contraintes fonctionnelles des organisations. Nous pouvons citer DAC[4],
MAC[5], RBAC[8], OrBAC[12]... . plusieurs autres formalismes et langages ont
également été proposés afin d'exprimer et de
valider les règles de sécurité mais ne sont
malheureusement pas à notre disposition.
Contrairement aux autres modèles qui se limitent
à l'expression des permissions, OrBAC offre un modèle plus riche
et modulaire. Il est plus expressif car en plus des permissions, il permet
d'exprimer des obligations, des interdictions et même des recommandations
qui dépendent d'un contexte. Cependant, il ne permet malheureusement pas
de vérifier la validité d'une politique de
sécurité, ni ne propose pas d'outils pour le faire.
Tout au long de ces travaux, nous nous sommes penchés
sur la validation des politiques de sécurité basées sur
OrBAC. A cet effet, nous proposons une politique de sécurité
pouvant permettre aux PME 3 (entreprises locales) de
sécuriser leur système d'informations et ainsi,
d'améliorer les performances des services rendus par ces entreprises.
Qui plus est, nous proposons un modèle de validation de cette politique
et de toute autre politique reposant sur OrBAC.
Ce mémoire est organisé de la façon
suivante : La section 2 présente des modèles et quelques outils
de contrôle d'accès de la littérature. La section 3 propose
un modèle de validation de la politique de sécurité. La
section 4 présente l'implémentation de l'outil qui va
évaluer la politique. Et enfin la section 5 conclut l'article et propose
des perspectives.
2 Les politiques de sécurité basées sur le
contrôle d'accès
Initié par le Department Of Defense américain
(DOD) dans les années 70 [3], le contrôle daccès joue un
rôle important dans la stratégie globale de sécurité
du réseau d'une entreprise dans la
2. Entités : utilisateurs ou personnes, ordinateurs
...
3. On définit une PME ici comme une entreprise qui
possède différents types d'équipements réseau, tels
qu'un site web, une DMZ, les serveurs de données, les routeurs, les
pare-feu, les commutateurs, les ordinateurs ...
3
mesure où, il empêche l'utilisation non
autorisée de ressources accessibles par le réseau. Voilà
pourquoi les politiques de contrôle d'accès définissent les
directives qui spécifient qui a la permission
d'effectuer quoi (quelle action) sur quelle
ressource [1]. [2] définit un modèle de contrôle
d'accès comme une organisation structurée de données
utilisées pour prendre une décision d'accès en accordant
ou en refusant à un sujet d'effectuer une
action sur un objet. Ces concepts clés
constituent la base d'une politique de sécurité où :
~ Un sujet est une entité active du système qui
demande des droits d'accès correspondant à l'autorisation
d'exécuter des actions sur les objets.
~ Un objet est une entité passive du système qui
correspond à des informations ou à une ressource à
protéger.
~ Une action est un moyen permettant à un sujet de
manipuler les objets du système.
Ainsi, pour assurer des objectifs de sécurité
tels que la confidentialité et l'intégrité,
différents modèles de contrôle d'accès ont
été définis dans la littérature afin de
représenter de façon claire et non ambigüe l'ensemble des
actions qui reflètent la vision stratégique de
sécurité d'une organisation.
2.1 Les modèles de contrôle
d'accès
2.1.1 Les modèles de contrôle
d'accès discrétionnaires (DAC)
Proposées en 1971 par Lampson [4], les politiques
discrétionnaires sont basées sur l'identité des
utilisateurs (d'où son nom IBAC 5) et les règles
explicites d'accès qui stipulent que les utilisateurs (sujets) sont
autorisés à définir leur propre règlement de
sécurité sur les informations (objets) dont ils sont
propriétaires[5]. En d'autres termes, chaque objet a un
propriétaire qui décide des sujets qui y ont accès. Ces
permissions d'accès sont représentées par une matrice dans
laquelle chaque ligne correspond à un utilisateur, chaque colonne
à une ressource et le contenu de cette matrice définit le droit
d'accès (lecture, écriture, exécution, ... ) de
l'utilisateur sur la ressource [2]. Cependant, leur mise en oeuvre est
coûteuse en mémoire lorsque le nombre d'utilisateurs est
important. Leur mise à jour est difficile et ne permet pas de
contrôler une information ou ce qui en est fait une fois qu'elle a
été accédée par un utilisateur
légitime6, ce qui rend le système vulnérable
à des chevaux de Troie 7 et l'expose à des fuites
d'informations. Son avantage est l'utilisation d'une politique de gestion
décentralisée.
2.1.2 Les modèles de contrôle
d'accès mandataires (MAC)
Introduites en 1976 par Bell et LaPadula [1] afin d'apporter
une solution aux problèmes de fuites d'informations des modèles
DAC, les politiques mandataires sont utilisées spécialement dans
les
4. Généralement, un sujet correspond à un
utilisateur
5. IBAC : Identity based access control
6. Il se pose dans ce cas un problème de propagation des
droits dû à la capacité de possession
7. Les chevaux de Troie sont des processus exécutant des
fonctions illicites cachées dans des fonctions légitimes
4
environnements militaires à cause de leurs
contrôles centralisés. Elles permettent à 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 et affectent aux sujets et objets d'une organisation, des
niveaux de sécurité qui sont non modifiables par les utilisateurs
et qui régissent la manière dont l'information est transmise dans
les systèmes. En effet chaque sujet reçoit un niveau
d'habilitation et chaque objet un niveau de classification. Si le niveau
d'habilitation d'un sujet est supérieur ou égal au niveau de
classification d'un objet, alors ce sujet a la permission d'accéder
à cet objet [5]. Les règles de cette politique diffèrent
selon qu'il s'agisse de maintenir des propriétés de
confidentialité (on a le modèle Bell-Lapadula utilisé
pendant longtemps dans les systèmes militaires pour assurer la
confidentialité) ou d'intégrité (on a les modèles
Biba, DTE, Clark et Wilson, la Muraille de Chine). Ce modèle est
très rigide car, il ne permet pas de gérer les exceptions entre
les différents niveaux de sécurité. Il est adapté
pour les administrations centralisées, les systèmes clos et
contrôlés à haute confidentialité ou
intégrité. Les systèmes ici peuvent êtres
détournés et exploités pour transférer des
informations [6] via des canaux cachés non désignés pour
la communication.
2.1.3 Les modèles de contrôle
d'accès basées sur les rôles (RBAC)
Proposées en 1992 par David Ferrailo et Richard Kuhn
[8], les politiques basées sur les rôles sont adaptées pour
les organisations comportant un nombre important d'utilisateurs et d'objets.
Leur principe général est d'introduire un niveau d'indirection
entre utilisateurs et permissions. C'est le concept de rôle qui a
été intercalé entre eux afin de mieux structurer les
droits d'accès. Il représente une fonction dans le cadre d'une
organisation, c'est-à-dire qu'il décrit facilement les
activités qu'un sujet a le droit d'accomplir au sein de cette
organisation. Les sujets ayant reçus l'autorisation de jouer un
rôle, héritent alors des permissions associées à ce
rôle. Ceci dit, d'un côté nous avons des permissions qui
sont accordées aux rôles, et de l'autre côté, des
utilisateurs se voient affecter un ou plusieurs rôles. De ce fait, si un
nouvel employé est recruté dans une organisation, il suffit de
lui assigner un (des) rôle(s) pour que le système l'intègre
automatiquement dans les limites autorisées par la politique de cette
organisation. Ce modèle simplifie l'administration des systèmes,
facilite la compréhension de la structure de l'organisation et
même de la politique de sécurité, réduit la
complexité de gestion des droits d'accès et permet à ce
que les rôles soient organisés de manière à former
une hiérarchie permettant de raffiner les différentes permissions
attribuées à chaque rôle. L'un de ses problèmes
majeurs est le fait que, les utilisateurs ayant le même rôle
obtiennent les mêmes privilèges. Ce qui réduit la
flexibilité des politiques de sécurité 8. On
souhaiterait par exemple que dans certaines organisations telles qu'un
hôpital, un médecin n'ait accès qu'aux dossiers de ses
patients et ce n'est pas exprimable dans RBAC. Le modèle ORBAC
(organisation Based Access Control) a été proposé pour
faire face à cette limite. Il étend le modèle RBAC et
attribut des permissions|obligations|recommandations|interdictions
pour la
8. Pourtant un utilisateur pourrait avoir un rôle
privé.
5
réalisation d'activités dans une organisation par
un rôle dans un contexte donné. 2.1.4 Les modèles
de contrôle d'accès basées sur l'organisation
(OrBAC)
Proposé en 2003 par Abou El Kalam et al [10], le
contrôle d'accès basé sur l'organisation reprend les
principes de rôles du modèle RBAC en offrant en plus, la
possibilité de modifier la politique de sécurité en
fonction d'une circonstance concrète, c'est-à-dire qu'il exprime
facilement les permissions qui dépendent d'un contexte. En dehors des
permissions, il offre la possibilité d'exprimer des obligations, des
interdictions et même des recommandations dépendant bien
évidemment des contextes. Il est centré sur le concept
d'organisation (groupe structuré d'entités actives), et tous ses
autres concepts sont définis par rapport à l'organisation. A
partir des relations ternaires (habilite, utilise et considère), il
définit les relations qui existent entre les entités du niveau
concret (sujets, objets, et actions), du niveau abstrait (rôles, vues et
activités) et l'entité contexte ainsi qui suit [12] :
Les sujets et les rôles
Dans ce modèle, un Sujet peut être un utilisateur
ou une organisation. L'entité Rôle est utilisée
pour structurer le lien entre les sujets et les organisations. La relation
Habilite est introduite entre ces entités. Si
Org est une organisation, s un sujet et r un rôle, alors
Habilite(Org, s, r) signifie que l'organisation Org
habilite le sujet s à jouer le rôle r. D'où
l'exemple Habilite (hôpital général, Marie,
infirmière) : l'hôpital général habilite Marie
dans le rôle d'infirmière.
Les objets et les vues
L'entité Objet représente
principalement les entités non actives. L'entité vue
regroupe un ensemble d'objets qui satisfait une propriété
commune. Elle caractérise la manière dont les objets sont
utilisés dans l'organisation. La relation utilise est
introduite entre ces entités. Si Org est une
organisation, o un objet et v une vue, alors la relation Utilise(Org, o, v)
signifie que Org utilise l'objet o dans la vue v. D'où l'exemple
Utilise (service sécurité réseau, courrier
électronique, dossiers administratif) : le service
sécurité réseau utilise courrier électronique comme
un dossier administratif.
Les actions et les activités
L'entité Action englobe principalement les
actions informatiques comme "lire", "écrire", "envoyer", etc.
L'entité Activité correspond à des actions qui
ont un objectif commun (exemple : consulter, modifier, transmettre, etc.). En
effet, l'objectif ici c'est de pouvoir caractériser des organisations
qui structurent différemment les mêmes activités. Si nous
considérons par exemple l'activité "consultation", elle peut
correspondre à l'action "lire" un fichier dans l'organisation
hôpital général, mais peut tout aussi bien
correspondre à l'action "select" sur une base de données dans
l'hôpital central. La relation Considère est
introduite entre ces entités. Si Org est une
organisation, a une action et A une activité, la relation
Considère(Org, a, A) signifie que Org
considère l'action a comme faisant partie de l'activité
A. D'où l'exemple Considère (hôpital
général, lire, consultation) : l'hôpital
général considère l'action "lire" comme une
consultation.
Les contextes
Le contexte spécifie les circonstances concrètes
dans lesquelles les organisations accordent des permissions (ou interdictions)
à des rôles pour réaliser des activités sur des
vues. Elle a été introduite par la relation
Définit. Si on veut par exemple savoir quand est ce
qu'un utilisateur ou sujet a le droit d'accéder à une
information, La relation Définit(Org, s,
a, 0, c) établit le contexte c définit par l'organisation
Org pour le sujet s, l'action a sur l'objet o. D'où l'exemple
Définit(hôpital général, Marie, lire,
carnet.doc, médecin-traitant) qui signifie que l'hôpital
général définit Marie ayant le droit de lire carnet.doc
car elle est le médecin traitant du patient auquel ce carnet
appartient.
La politique de contrôle d'accès OrBAC est
définie par les relations permission, obligation et interdiction sur
organisation Rôle Activité Vue Contexte. Ainsi,
Permission (Org, r, a, y, c) indique que dans une organisation Org, un
rôle r est autorisé à effectuer une activité a sur
une vue v dans un contexte c. Les autorisations concrètes de type
(sujet, action, objet) quant à eux sont dérivées des
relations Est_permis, Est_interdit, Est_obligatoire et
Est_recommandé. On aura par exemple Est_permis(s,
a, o) qui signifie que le sujet s a la permission de réaliser
l'action a sur l'objet o. La figure ci-dessous résume donc le
modèle de sécurité OrBAC[11].
FIGURE 1 Modèle OrBAC [12]
6
7
L'avantage de ce modèle est qu'il permet d'exprimer des
règles contextuelles qui peuvent être spécifiques à
une organisation. Il permet de spécifier au sein d'une même
organisation structurée en plusieurs sous organisations plusieurs
politiques de sécurité. Contrairement aux autres modèles
qui ne modélisent que des politiques de sécurité se
restreignant à des permissions statiques, OrBAC offre la
possibilité d'exprimer des règles relatives aux permissions,
interdictions, obligations et recommandations. Malheureusement, il ne permet
pas d'assurer qu'il n'y aura pas de conflits dans la politique de
sécurité (par exemple, pour un sujet donné, une action
donnée, et un objet donné, il nous faut détecter et
résoudre une situation dans laquelle il serait possible de
dériver à la fois une permission et une interdiction). Il ne
montre pas comment détecter une violation de la politique de
sécurité et pour finir, ne dit en rien si une politique de
sécurité est cohérente ou pas.
La volonté sous-jacente à cette abondance de
modèles de contrôle d'accès, c'est de proposer une
organisation des droits qui permet de traduire au mieux les politiques de
sécurité ou l'ensemble des règles qui régissent la
façon dont sont protégées les ressources d'un
système. Une fois que nous avons pris connaissance de ces
modèles, il faut implanter celui qui se rapproche le plus de notre
organisation car, le choix d'un modèle a une influence capitale sur les
solutions que nous pouvons obtenir. En vue de se rassurer de sa
sûreté, il faut vérifier que la politique mise en place est
cohérente.
2.2 Les méthodes de vérification des
politiques de contrôle d'accès
Pour spécifier et vérifier les politiques de
contrôle d'accès, plusieurs langages et outils ont
été développés. Ces mécanismes de
contrôle d'accès spécifient quels sujets sont (ou ne sont
pas) autorisés à effectuer quelles actions spécifiques
à quelle(s) ressource(s). Les plus connus dans la littérature
sont : XACML (eXtensible Access Control Markup Language)[16] [7], PONDER [13],
EPAL (Enterprise Privacy Authorization Language) [14], ASL (Authorization
Specification Language) [15],.... Ils permettent de définir plusieurs
règles de politiques de contrôle d'accès, et parce qu'ils
n'offrent aucun mécanisme pour éviter les conflits et les
incohérences, ils proposent des outils (tels que Alloy analyser, Ponder
toolkit, Margrave, ... ) pour valider les politiques. Dans chaque règle,
on retrouve :
~ Un sujet qui peut être un utilisateur, une machine, un
processus, un programme, etc,
~ Un objet qui peut être un fichier, une base de
données, une machine, un programme, etc,
~ Un droit d'accès qui désigne l'ensemble des
actions qu'un sujet a la permission d'effectuer sur un objet (lire,
écrire, modifier, etc.),
~ Un contexte qui est une contrainte qui lie le sujet, le
droit d'accès et l'objet (contexte temporel, contexte spatial, etc.).
Ces éléments devront être
évalués par le système de contrôle d'accès
avant de générer une décision d'accès à
l'objet qui peut être positive ou négative.
8
Dans un but d'illustration, nous utiliserons le modèle
OrBAC pour montrer comment modéliser la politique de
sécurité d'une organisation. Nous verrons également
comment à partir de JProlog nous pouvons arriver à valider une
politique de sécurité car, la plupart des langages de
contrôle d'accès ci-dessus ne fournissent aucun moyen pour valider
les politiques ou règles de sécurité et aussi, les outils
qu'ils proposent ne sont pas à notre disposition.
3 Modélisation et validation d'une politique de
sécurité
Les attaques 9 auxquelles les organisations sont
généralement exposées, ont permis de développer des
stratégies de sécurité 10 en vue de
protéger le réseau et d'éviter que les systèmes
soient compromis. Toutes ces directives sont définies de manière
globale par la politique de sécurité qui fixe les objectifs de
sécurité auxquels l'organisation devra se conformer en vue de
garantir la protection des ressources de son système. Elles abordent
différentes techniques de défense parmi les quelles le
contrôle d'accès qui nous intéresse.
Il sera donc question dans cette section, de proposer la
politique de contrôle d'accès que pourrait adopter une PME; de
présenter la modélisation de cette politique en utilisant le
modèle OrBAC, ce qui permettra d'étayer le fonctionnement et
maîtriser la complexité de cette politique de
sécurité; et enfin de la valider.
3.1 Le modèle générique
Il est important de se rappeler que dans OrBAC les
règles de sécurité ne sont pas spécifiées
pour chaque sujet, objet et action. Or, il est primordial d'identifier
clairement ces concepts dès la conception. Nous proposons un
modèle générique utilisant le formalisme UML pour la
spécification de ses entités vues comme objets abstraits. Car,
nonobstant le fait qu'il n'existe pas de langage ou d'outil pour
modéliser OrBAC, UML est un langage standard qui a un domaine
d'application très étendu, il a une grande capacité
à décrire des niveaux d'abstractions, à
hiérarchiser des représentations, à enrichir facilement un
modèle et son utilisation est libre de droit.
Ce modèle générique est une
représentation abstraite d'une politique de sécurité
devant être conforme au modèle OrBAC et de son fonctionnement au
sein d'une organisation. Il sert à spécifier la politique de
sécurité indépendamment de l'implantation qui en sera
faite.
Grâce au formalisme UML, nous pouvons modéliser
de manière plus expressive et moins complexe, les éléments
fondamentaux de la politique de sécurité d'une organisation tels
que : les sous
9. Attaques : les intrusions systèmes, les
accès non autorisés, les interceptions et usurpations
d'identités et de mots de passes, les dénis de service ...
10. Stratégies de sécurité :
définition des rôles et responsabilités des utilisateurs,
définition des comportements autorisés et ceux qui ne le sont
pas, ...
9
organisations, les différents rôles, les
différentes activités, les vues et les contextes. La figure 2
présente notre modèle générique.
FIGURE 2 Modèle Abstrait de la politique
Les types d'accès que sont les permissions, les
obligations, les interdictions et les recommandations permettent d'exprimer les
règles contextuelles qui existent entre les éléments
fondamentaux. Notre modélisation décrit uniquement les types
d'accès permission et obligation car selon [12], les recommandations
peuvent être vues comme étant des permissions et les interdictions
sont en fait des non permissions.
Dans la section suivante, nous présentons la
modélisation concrète des règles de sécurité
issue du modèle abstrait.
3.2 Le modèle concret
Le modèle concret est dépendant d'une politique
de sécurité bien définie. Il explicite les
éléments fondamentaux décrits par le modèle
générique ainsi que les relations qui existent entre eux. Nous
nous servons du formalisme UML pour le produire à partir du
modèle générique.
Dans les sections suivantes nous présentons la
politique de sécurité de l'organisation Org (qui est une PME) et
le modèle concret associé à cette politique de
sécurité.
10
3.2.1 La Politique de sécurité de
l'organisation Org
L'organisation Org est une entreprise de type PME dotée
d'un service de ressource humaine, d'un service technique et d'un service
financier. Son architecture réseau est décrite par la figure
3.
FIGURE 3 Architecture réseau de Org
La politique de sécurité de Org telle que
définie par son administrateur réseau stipule que :
L'accès au réseau par un utilisateur se fait à partir d'un
ordinateur ayant accès au réseau. Les hôtes privés
de Org ont la permission d'accéder et de naviguer sur Internet.
Les hôtes privés de Org sont interdits
d'accéder à certains sites Internet entre 7h et 16h.
Les hôtes externes du réseau public ne peuvent
accéder qu'aux serveurs de la DMZ (FTP, DNS, SMTP, Serveur WEB, Serveur
de messagerie,...) du réseau.
Le serveur DHCP a la permission de configurer les connexions
(distribuer les adresses IP) des serveurs de Org.
Le serveur DHCP est interdit de configurer les connexions
(distribuer les adresses IP) des serveurs de Org.
L'hôte affecté au rôle d'administrateur
système a l'obligation de gérer (créer, enregistrer,
octroyer des droits aux utilisateurs en fonction de leur rôle) les
utilisateurs qui se connectent au système.
Les hôtes privés de Org qui voudront se connecter
et accéder à un service du réseau devront obligatoirement
s'identifier et s'authentifier auprès du serveur d'authentification
Radius.
Le serveur d'annuaire (LDAP) ou serveur de domaine (active
directory) a la permission de centraliser et rendre disponible les informations
des utilisateurs aux serveurs d'authentification et d'application.
11
~ Les hôtes privés de Org n'ont pas
l'accès direct au serveur d'annuaire.
~ Le serveur d'authentification (Radius) a la permission de
gérer (authentifier, autoriser et comptabiliser) les accès de
tous les utilisateurs sur le réseau.
~ L'hôte affecté au rôle de gestion des
firewalls a la permission de gérer (accéder, configurer et
utiliser les services d'administration des firewalls) les interfaces des
firewalls du réseau en toutes circonstances.
~ L'hôte affecté au rôle de gestion des
serveurs peut mettre à jour les serveurs de la DMZ.
~ L'hôte affecté au rôle de serveur
d'administration peut sécuriser, mettre à jour, configurer,
administrer, activer les services requis pour des rôles précis sur
les serveurs d'application, d'authentification et d'annuaire.
~ L'hôte affecté au rôle de serveur
d'administration peut configurer les ports pour autoriser l'administration
à distance des serveurs d'application, d'authentification et
d'annuaire.
~ L'hôte affecté au rôle de technicien
réseau peut assurer la maintenance (installer les antivirus, les
logiciels d'applications et d'exploitation à distance, dépanner
...) des ordinateurs du réseau.
~ L'hôte affecté au rôle d'administration
des ressources humaines peut accéder et mettre à jour (ajouter,
modifier ses informations, supprimer) les profils des employés sur une
application stockée sur le serveur d'application.
~ L'hôte affecté au rôle de gestion de
carrière est interdit d'accéder à l'application qui paye
les employés mais il gère (planifie, notifie, publie, met
à jour) l'avancement automatique des employés après un
temps précis et suivant des critères précis sur le serveur
d'application entre 7h et 16h.
~ L'hôte affecté au rôle de
comptabilisation peut consulter, établir le budget, la liste des
recettes
et dépenses de l'organisation et établir les
salaires des employés sur le serveur d'application. ~ L'hôte
affecté au rôle d'administration financière établit
la paye des employés et gère les
opérations des différentes sous-organisations
sur le serveur d'application.
Les règles ci-dessus constituent des unités
élémentaires de la politique de sécurité de Org.
Elles peuvent comporter des anomalies dues par exemple à des
incohérences 11 ou contradictions, des redondances, des
incomplétudes 12 . . . . La vérification de cette
politique de sécurité représente donc un enjeu important
pour la sécurisation de l'organisation. Il est cependant
nécessaire de la modéliser pour mieux exprimer ses exigences afin
de vérifier sa cohérence.
11. Une incohérence peut provenir de deux
décisions opposées concernant un accès donné qui
est à la fois permis et interdit.
12. Une règle est dite incomplète si un sujet
demande un accès à un objet alors qu'aucune réponse
(permission ou interdiction) n'est indiquée pour cette demande
d'accès.
12
3.2.2 Le modèle concret de la politique de
sécurité de Org
Les règles de sécurité définies
par l'administrateur réseau de Org, nous permettent de construire,
grâce au formalisme UML, le modèle concret de la politique de
sécurité qui décrit comment elles sont conçues de
manière à répondre aux besoins de sécurité.
La figure 4 présente cette politique.
FIGURE 4 Modèle concret de la politique
Les relations entre les éléments fondamentaux de la
figure 4 sont modélisées linéairement suivant la chaine
:
13
La plupart des composants des éléments
fondamentaux sont organisés de manière hiérarchique (voir
figure 4). Les sous-classes représentant l'ensemble des rôles, des
vues, des activités et des contextes héritent des
opérations et des attributs des classes plus abstraites. Le fait
qu'elles soient également des classes, leurs donnent la
possibilité de pouvoir intégrer d'autres classes plus moins
abstraites qu'elles. Ainsi, elles se prêtent facilement à des
modifications et ce, en fonction de la politique de l'organisation. D'où
les qualités de flexibilité, d'extensibilité et
d'évolutivité du modèle. Nous aurons par exemple pu
modifier l'architecture de la figure 4 en proposant que le rôle
"technicien" hérite en plus du rôle d'"Administrateur
réseau". Ce modèle possède également un aspect
modulaire vu les fonctions de chacun, les interactions qui existent entre eux
et sa structure en composants indépendants.
3.3 modèle de validation de la politique de
sécurité
La validation de cette politique de sécurité va
consister à représenter ses règles décrites au tout
début en langage naturel sous forme de données structurées
XML et à les transformer sous forme de prédicats que nous
exprimerons en Prolog pour validation.
3.3.1 Le langage eXtensible Markup Language (XML)
XML (eXtensible Markup Language) est un langage permettant de
décrire, à l'aide de balises personnalisées, une structure
de données ou documents de tous types. Il décrit les solutions de
stockage, manipulation, transformation et échange des données
structurées et les stocke dans des fichiers texte. Il est
auto-descriptif et extensible, basé sur une structure arborescente
permettant de modéliser la majorité des problèmes
informatiques. Il se veut "universel", portable, utilisable par toute
application pourvue d'un parseur XML. Chaque fichier XML doit posséder
son "XML Schéma" qui permet de définir le modèle de son
document, c'est-à-dire, qui définit la structure, le type de son
contenu et permet notamment de vérifier la validité de ce
document. Il nous permettra de représenter le modèle concret afin
de faciliter le traitement automatique des règles de
sécurité et de coder plus aisément les prédicats
issus de l'analyse de ces règles.
3.3.2 Le modèle de validation
Notre modèle de validation des politiques de
sécurité est représenté par la figure 5 et sa
démarche de validation est décrite par les activités
ci-dessous :
~ [Activité 1] : La première
activité qui a déjà été faite, consistait
à l'analyse et la conception graphique de la politique de
sécurité en utilisant UML.
14
[Activité 2] : La seconde
activité consiste en la génération du fichier XML
correspondant au modèle concret de cette politique de
sécurité. En effet, les diagrammes UML peuvent être
décrits par la syntaxe de XML.
[Activité 3] : La troisième
activité consiste, à partir du fichier XML produit à
l'activité précédente, à générer
toutes les règles de la politique de contrôle d'accès dans
la spécification OrBAC. Toutes ces règles seront sous la forme
Obligation (sous-organisation, rôle, activité, vue, contexte)
ou Permission (sous-organisation, rôle, activité, vue,
contexte) si un contexte existe bien évidemment.
[Activité 4] : La quatrième
consiste à produire les prédicats de ces règles, qui se
présenteront ainsi qu'il suit :
VX E Org, SousOrg(X)
? Contexte(X) = Activit(X,
vue) pour les règles d'Obligations
et
?X E Org, SousOrg(X)
? Contexte(X) = Activit(X,
vue) pour les règles de permissions. Nous devons garder
à l'esprit qu'il peut y avoir des règles qui possèdent
plus d'une activité et voire aucun contexte.
[Activité 5] : La cinquième
activité consiste à produire à partir des
prédicats, un fichier texte des prédicats conforme à la
syntaxe de Prolog.
[Activité 6] :La sixième
activité consiste à exécuter le test de cohérence
sur le fichier produit à l'activité 5 à l'aide de
Prolog.
FIGURE 5 Modèle de validation
Les étapes que nous observons entre ces
activités expriment le passage d'une activité à une autre.
L'étape 1 est la phase de génération du code XML
associé à la modélisation graphique de la politique de
sécurité. L'étape 2 est la phase de prétraitement.
L'étape 3 est la phase de production des règles dans la
spécification OrBAC. L'étape 4 est la phase de dérivation
des prédicats et l'étape 5, la phase de validation des
prédicats. Elle vérifie la cohérence des règles au
sens du calcul des prédicats.
15
3.3.3 Description de quelques activités
Activité 3 : Production des règles de
contrôle d'accès suivant la spécification OrBAC
L'algorithme utilisé pour produire les règles de
contrôle est le suivant :
Algorithme production des règles
Entrée :
Le fichier XML produit à l'activité 2
Sortie :
Le fichier des règles de contrôle d'accès
respectant la spécification OrBAC.
Variable :
~ Package table de hachage des concepts
fondamentaux contenant le nom du concept et un identifiant IDPack
comme clé de hachage.
~ Class table de hachage contenant les
entités appartenant à chaque concept fondamental. Elle contient
le nom de l'entité, l'identifiant du concept fondamentale auquel il
appartient et un identifiant IdClass comme clé de
hachage.
~ Relation table de hachage contenant les
relations entre toutes les entités appartenant à la politique de
sécurité. Elle contient les IdClass des
entités qu'elle relie et un identifiant IdRel comme
clé de hachage.
~ Assoc table de hachage contenant les
relations de type obligation ou permission entre les entités appartenant
à la politique de sécurité. Elle contient le nom de
l'association et un identifiant IdAssoc comme clé de
hachage
Debut:
1. On recherche le nom de la règle dans Assoc
avec Idassoc. On recherche dans Relation
les classes qui lui sont reliées. Cette relation concerne
toujours une classe du package Rôle et du package Activité. Le
Champ IdFrom désigne une classe du package Rôle
et le champ IdEnd, désigne une classe du package
Activité. Le nom de la classe en question est obtenu en faisant une
recherche dans la table de hachage.
2. On cherche dans la table Relation, toutes
les relations qui ont IdFrom comme noeud terminal et les
IdFrom de ces relations sont les Id des classes du package
Org.
3. On cherche en suite dans Relation, toutes
les relations qui ont des IdEnd comme noeud initial et les
IdEnd de ces relations sont les Id des classes du package
Vue.
4. On recherche dans la table Relation les
relations ayant IdFrom équivalent à cet
élément. Les IdEnd de ces relations sont les Id
des classes du package Contexte.
Fin:
16
Activité 4 : Dérivation des
prédicats
Pour transformer les règles obtenues à
l'activité 3 en prédicats, nous devons leur associer un langage
de 1er ordre qui fournira une syntaxe
permettant d'exprimer les instances de ces règles. Chacune de ces
règles contient des symboles extraits d'un vocabulaire particulier
classés en quatre groupes : les symboles de constante, les variables
individuelles, les variables de contexte, les symboles de relation et les
symboles de fonction [12].
~ Les symboles de constante correspondent aux instances de
classes ci-dessus, c'est-à-dire les instances de classe de type
organisation, rôle, sujet, activité, action, vue, objet, contexte.
Nous pouvons par exemple avoir le sujet Boby qui joue le rôle de
maintenancier et donc restaure les systèmes d'exploitation des
ordinateurs personnels en cas de panne. Dans cet exemple on peut donc retrouver
les instances de certaines de ces différentes classes.
~ Les variables individuelles correspondent ici aux sujets ou
utilisateurs qui jouent un rôle dans Org. On va les noter par des lettres
latines majuscules comme X, Y
l'un peut remplacer Boby.
~ Les symboles de relation correspondent ici aux associations.
Nous en avons deux: permission et obligation. Nous utiliserons les
quantificateurs universels ou existentiels pour les interpréter. Les
quantificateurs universels correspondront au symbole de relation obligation et
les quantificateurs existentiels correspondront au symbole de relation
permission.
~ Les symboles de fonction correspondent aux formules
atomiques des règles ci-dessus telles que Sous-Org correspondant
à une sous-organisation de Org, Cont correspondant à contexte et
Act correspondant à une action. De ce fait, Org
? Cont, Org V
Cont sont des formules. Pour x
une variable individuelle, Vx E
Org et x E Org
sont aussi des formules.
Ainsi, une règle de type Obligation (sous-Org,
Rôle, Activité, Vue, Contexte) produira pour une variable X
de type Rôle et v de type Vue :
VX E Org, Sous
- Org(X) ? Cont(X)
= Act(X, v).
La règle "Les hôtes privés de Org sont
interdits d'accéder à certains sites Internet entre 7h et 16h"
correspondra à l'écriture Obligation (Org, Hôte
privé de Org, accéder à site internet, Internet,
Temps). Pour les propositions :
Time(X) : X travail entre 7h et 16h, SI(X,a) : X accède au
site Internet A, Hpv(X) : X est un hôte privé
On aura la formule :
VX E Org, Hpv(X)
? Time(X) = -iSI(X,
a)
La règle "Les hôtes externes du réseau
public ne peuvent accéder qu'aux serveurs de la DMZ (FTP, DNS, SMTP,
Serveur WEB, Serveur de messagerie...) du réseau" correspondra à
l'écriture
17
Permission (Not-Org, Hôte public, accéder
á un serveur de la DMZ, Serveurs de la DMZ ). Pour les propositions
:
Admz(X,s) : X accède au serveur s de la DMZ du
réseau
Hpb(X) : X est un hôte public
On aura le prédicat :
?X ?/ Org, Hpb(X)
Admz(X, s)
Ce processus de dérivation nous permet de
décrire le XML Schéma suivant afin de
modéliser la politique de sécurité :
3.4 Propriétés du modèle
Tout comme les autres modèles, le modèle
ci-dessus vise à assurer une protection efficace des ressources du point
de vue du contrôle d'accès. Il a tout de même certaines
caractéristiques qui le différencient des autres langages et
techniques de modélisation :
~ Pour analyser une politique de sécurité, ses
règles doivent suivre le format du modèle OrBAC et elles doivent
être conçues de manière graphique en utilisant UML.
~ Les liens entre les classes sont orientés,
c'est-à-dire que pour la construction de nos règles, les liens
entre les packages sont représentés de Org vers Rôles, de
Rôles vers Activité, de Activité vers Vue et de Vue vers
Contexte.
~ Il existe une très forte dépendance entre nos
activités.
18
~ Il est flexible, extensible, interopérable et
évolutif car il offre la possibilité d'ajouter, supprimer ou
modifier des fonctions, et même d'intégrer d'autres modules.
~ Il a une architecture modulaire.
4 Implémentation et Résultats
L'évaluation des prédicats se fera avec Prolog.
Dans Prolog, les prédicats servent à qualifier les objets ou
données du problème et à décrire les relations dans
lesquelles ils sont impliqués. Ces données représentent en
effet des faits qu'on considère vrais et les relations sont en fait les
règles. Notre modèle permet de produire les règles
nécessaires à Prolog, mais la production des faits requiert une
bonne connaissance de la structure de l'organisation et de ses composants.
Cette tâche est laissée à la charge de l'administrateur
réseau qui définit la politique de sécurité.
4.1 Implémentation de notre modèle
DOM4J 13 est une API Open Source Java permettant de
travailler avec XML. Nous l'avons utilisé parce qu'il permet de
parcourir et manipuler (ajouter, modifier, supprimer, . . . ) les
données XML. Cette bibliothèque est compatible avec les standards
DOM, SAX et JAXP. DOM4J permet de modéliser un fichier XML comme un
arbre. Cette structure arborescente permet ainsi, d'accéder aux noeuds
du document XML avec des instructions comme nextchild(). Pour chaque noeud, on
peut récupérer ses fils dans une liste, lire et modifier ses
attributs.
Les prédicats générés sont
évalués à partir d'une plateforme java qui intègre
Prolog: JIProlog. JIProlog (Java Internet Prolog) est un Prolog
interprète mis en oeuvre en Java qui possède un IDE pour
éditer et tester le code Prolog. Acronyme de programmation logique,
Prolog est un langage d'expression des connaissances basé sur la
déclaration des relations existantes entre différentes
entités et sur le calcul des prédicats de premier ordre. C'est
l'utilisateur qui définit cette base de connaissances et
l'interpréteur Prolog l'utilise pour répondre aux questions. En
effet, la structure de prolog impose que l'on produise les règles et les
faits pour l'évaluation d'une politique.
Les faits sont des données élémentaires
ou des formules atomiques constituées du nom d'un prédicat suivi
entre parenthèse d'une liste ordonnée d'arguments qui sont les
objets du problème qu'on considère vrais.
EX : "Les hôtes privés de Org
ont la permission d'accéder et naviguer sur Internet" se traduit par :
Machine A (chatter, facebk).
Les règles par contre sont des relations qui permettent
d'établir de nouveaux faits par déduction à partir des
hypothèses.
EX : si on a :
13. DOM4J : Document Object Model, API Java permettant de
manipuler des données XML de manière plus simple. http ://
dom4j.org
19
AI(X) : X a la permission d'accéder sur Internet NI(X) : X
a la permission de naviguer sur Internet Hp(X) : X est un hôte
privé
la relation : "Les hôtes privés de Org ont la
permission d'accéder et naviguer sur Internet" se traduit en Prolog par
la règle Hp(X) :- AI(X) , NI(X).
Ainsi, pour déterminer si un ensemble de règles
ou une politique est appliqué pour une requête donnée, il
faut vérifier si cette dernière correspond aux cibles.
Un programme Prolog peut être constitué d'un ou
de plusieurs fait(s) au moins, car c'est à partir de lui (d'eux) que
Prolog va pouvoir rechercher des preuves pour répondre aux
requêtes de l'utilisateur. Ainsi, un programme Prolog prendra en
entrée un ensemble de règles et de faits et produira en sortie
l'expression "true" ou l'expression "fail".
Le simulateur ci-dessus nous a permis de générer
les règles que nous allons fournir à Prolog, nous devons donc
produire des faits (qui constituera notre test) qui nous permettront de valider
la politique. C'est donc de ces faits que nous introduisons les autorisations
concrètes.
4.2 Etape de prétraitement ou d'extraction
d'informations utiles à la construction des règles de la
politique de contrôle d'accès
Comme nous l'avons mentionné plus haut, cette
étape consiste en l'extraction dans un fichier XML, des valeurs
nécessaires à la construction des règles de contrôle
d'accès pour la production des prédicats. D'après le XML
Schéma du code XML généré à l'étape
1, il s'agit des informations concernant les packages, les classes, les
relations et les associations qui nous aideront à produire les
règles d'accès. Pour ce faire, nous utilisons un parseur qui
prend en entrée le nom du fichier XML généré,
parcourt les noeuds de l'arbre de ce fichier XML et produit en sortie un second
arbre qui est conforme au XML Schéma des prédicats. C'est la
méthode createDocument() qui est utilisée pour créer ce
nouveau fichier.
4.3 Application à la politique de sécurité
de Org
Logiciel de modélisation UML, Visual Paradigm est un
outil de création des modèles et diagrammes UML. Il permet
également la génération de code de programmation dans une
bonne partie des langages communs (XML, Java, C,
VB.NET, PHP, ... ), la modélisation
de bases de données relationnelles, la génération de code
SQL et le déploiement dans les principaux SGBDR (MySQL, MS SQL Server,
Oracle, ... ), ... Bref il offre de nombreuses fonctionnalités de
modélisation et possède une interface graphique intuitive, claire
et agréable à utiliser. Il est multi plate-forme (java) mais
relativement coûteux.
20
4.3.1 Fichiers XML manipulés
Visual Paradigm nous a aidé à
générer le fichier XML correspondant à la politique de
sécurité modélisée. La figure 6 nous permet de
comprendre comment il a structuré les données ou informations de
cette politique de sécurité. La figure 7 quant à elle,
présente le résultat du prétraitement du fichier XML de la
figure 6 avec la méthode CreateDocument(). Il s'agit en effet de
I'extraction des informations utiles à la production d'un fichier XML
minimal ou réduit conforme au XML Schéma présenté
en section 3.3.
FIGURE 6 Fichier XML de la politique de
sécurité
Nous pouvons observer (cf Figure 7) que nous passons d'un
premier fichier XML de 18290 lignes à un fichier plus réduit de
131 lignes dépourvu d'informations liées soit au modèle,
soit à Visual Paradigm qui ne nous intéressent guère.
21
FIGURE 7 Fichier XML réduit
4.3.2 Génération des règles dans la
spécification OrBAC
L'algorithme de la section 3.3.3 nous aide à produire
les règles dans la spécification OrBAC en utilisant le fichier
XML réduit de la figure 7. La figure 8 présente un extrait de
l'exécution de cet algorithme.
FIGURE 8 Règles dans la spécification OrBAC
22
4.3.3 Production des prédicats des
règles
La figure 9 présente la production des prédicats
des règles produites dans la section 4.3.2 suivant le processus
décrit dans l'activité 4 de la section 3.3.2.
FIGURE 9 Prédicat conforme à la
notation classique
4.3.4 Validation avec Prolog
Comme nous l'avons dit en section 4.1, JIProlog prendra en
entrée un ensemble de règles et de faits et produira en sortie
l'expression "true" ou l'expression "fail". Ainsi, les prédicats
ci-dessus sont traduits en Prolog, produits dans un fichier texte et
importé dans JIProlog comme l'ensemble des règles de la
politique.
Les faits quant à eux constituent ce que nous avons
appelé les autorisations concrètes. Rappelons que les relations
Permission, Interdiction, recommandation et
Obligation permettent à Org de spécifier les permissions
accordées suivant de contexte et qu'elles correspondent à une
relation entre les rôles, les vues et les activités. Dans la
pratique, ces relations se doivent d'être concrètes car elles sont
accordées aux sujets pour effectuer des actions sur des objets
d'où l'introduction des relations Est_permis,
Est_interdit, Est_recommandé et Est_obligatoire
[9]. La relation Est_permis(s, a, 0) signifie qu'il est permis au
sujet s de réaliser l'action a sur l'objet o. Les relations
Est_interdit, Est_recommandé et Est_obligatoire
sont définies de la même manière. D'après [11]
[12], ces instances explicites de relations sont dérivées
logiquement des relations Permission (Sous-Org, Rôle,
Activité, Vue, Contexte) ? Habilite (Sous-Org,
Sujet, Rôle) ? Considère (Sous-Org,
Action, Activité) ? Utilise (Sous-Org, Objet,
Vue) ? définit (Sous-Org, Sujet, Action,
Object, Contexte) ? Est_permis (Sujet, Action,
Objet). Il en est de même pour les autres relations.
Ainsi, un exemple de fait des règles ci-dessus serait :
Boby (gérer employé, 07h-15h).
L'outil de validation est en effet un script qui
exécutera toutes ces activités. En effet, il nous proposera une
interface qui ira de la modélisation UML de la politique de
sécurité jusqu'à la production de l'expression "true" si
la politique est cohérente ou l'expression "fail" sinon.
23
5 Conclusion et perspectives
Dans cet article, nous avons proposé une
démarche de validation des politiques de contrôle d'accès
basées sur le modèle OrBAC. En effet, Nous sommes partis du fait
que les entreprises sont en général exposées à
différentes sortes d'attaques. Alors, il est urgent de leur proposer une
politique valide de contrôle d'accès notamment OrBAC, qui
protègerait leurs systèmes et éviterait qu'ils soient
compromis.
Ainsi, ce travail a permis d'apporter les contributions
suivantes :
~ La proposition d'un modèle générique
pour exprimer des politiques de contrôle d'accès Or-BAC;
~ La proposition d'une politique de sécurité que
pourrait déployer les PME pour contrôler les accès à
leur système informatique;
~ La proposition d'un modèle de validation d'une
politique de contrôle d'accès afin de s'assurer de sa
cohérence.
En effet, le modèle générique qui est la
représentation abstraite de la politique de sécurité et de
son fonctionnement, a permis en utilisant le formalisme UML, de faciliter la
construction d'un modèle plus concret décrivant de manière
explicite les règles de la politique d'accès au système
proposée pour Org, tout en insistant à la fois sur ses aspects
statiques et dynamiques. Le modèle de validation quant à lui,
propose une démarche de validation de cette politique. Il utilise le
langage XML pour représenter, stocker et manipuler la politique de
contrôle d'accès, génère toutes ses règles
sous la forme des règles dans la spécification OrBAC et produit
les prédicats associés à ces règles qu'il fournit
à l'APl JlProlog. JlProlog utilise la logique de premier ordre pour
évaluer ces règles et permet de juger la cohérence de la
politique.
On pourrait améliorer ce travail en intégrant
dans le modèle de validation, un module de sécurisation des
documents Xml utilisant des techniques de chiffrement, un module de
détection des incohérences et conflits de la politique de
contrôle d'accès parce que le modèle ci-dessus ne
prévoit malheureusement pas de nous dire pourquoi une politique n'est
pas validée. On pourrait également étendre ce
modèle à la gestion d'autres aspects de la sécurité
comme la détection des intrusions qui est un problème intimement
lié au contrôle d'accès.
Remerciements
~ J'exprime ma profonde gratitude à mon directeur de
mémoire le Dr TINDO Gilbert pour son suivi et ses conseils dont-il a su
me faire profiter tout au long de ce travail.
~ Je remercie tous les membres de mon jury d'avoir bien voulu
accepté d'évaluer ce travail.
~ Je remercie Dr KOUOKAM pour le soutien qu'il m'a
apporté face à toutes les difficultés que j'ai
rencontré dans la réalisation de ce travail.
~ Je remercie M. NOUNAMO P. et M. Djiongo C. pour leur soutien et
leur aide.
24
~ Je remercie TAMO Léonie, FANSI Luisa et mon papa pour la
relecture de ce travail.
~ Je ne saurais oublier mes parents pour leurs soutiens
constant et inconditionnel, leurs conseils ... je leur suis reconnaissante.
~ Ma gratitude s'exprime également à l'endroit
de mes oncles, mes tantes, mes frères, mes soeurs, mes ami(e)s et mes
camarades qui m'ont soutenus et à tous ceux qui de près ou de
loin ont contribué à la réalisation de ces travaux.
Références
[1] Marwan CHEAITO, Un cadre de spécification et de
déploiement de politiques d'autorisation, Thèse de Doctorat de
l'université de Toulouse soutenu le 09/03/2012, pages 34, 35, 42.
[2] Romuald Thion, Structuration Relationnelle des Politiques
de Contrôle D'accès Représentation, Raisonnement et
Vérification Logiques, Thése de doctorat de L'Institut National
des Sciences Appliquées de Lyon soutenue en 2008, pages 18, 26, 35,
235.
[3] HIND RAKKAY, Approches formelles pour la
modélisation et la vérification du contrôle d'accès
et des contraintes temporelles dans les Systèmes
d'information,Thèse de doctorat de l'école polytechnique de
Montreal, avril 2009, pages 32.
[4] Butler W. Lampson, Protection, ln 5th Princeton Symposium
on Information Science and Systems, pages 437-443, 1971. Reprinted in ACM
Operating Systems Review 8(1) : 18-24, 1974.
[5] Céline COMA, Interopérabilité et
cohérence de politiques de sécurité pour les
systèmes auto-Organisants, Thèse de doctorat de l'école
nationale supérieure des télécommunications de BRETAGNE en
habilitation conjointe avec l'université de Rennes 1, soutenu le 22
avril 2009, pages 20, 22, 24.
[6] Amal HADDAD, Modélisation et Vérification
de Politique de Sécurité, mémoire de Master 2 recherche de
l'Université Joseph Fourrier, Septembre 2005, pages 22.
[7] Lorch, M., Proctor, S., Lepro, R., Kafura, D., and Shah,
S. First experiences using XACML for access control in distributed systems. ln
XMLSEC 03 : Procee dings of the 2003 ACM workshop on XML se curity (2003), ACM
Press, pages 25-37
[8] David F. Ferraiolo et D. Richard Kuhn, Role-Based Access
Controls, article, pages 1.
[9] Salem BENFERHAT et Rania EL BAIDA, Gestion des Conflits
dans les Systèmes de Contrôles dAccès Basés sur
IOrganisation (OrBAC), article, page 3.
[10] BELLAL Toufik, Expression d'une politique de
sécurité dans un réseau social, mémoire de Master 2
recherche à l'université de Bretagne Occidentale, juin 2010,
page13.
[11]
25
Frédéric Cuppens, Nora Cuppens-Boulahia et
Alexandre Miège, Héritage de privilèges dans le
modèle OrBAC : Application dans un environnement réseau, cours
SSTIC 02-04 juin 2004, pages 10, 11.
[12] Anas Abou El Kalam et al, ORBAC : un modèle de
contrôle d'accès basé sur les Organisations, article, page
3, 7, 8.
[13] Schunter, M., and Powers, C. The Enterprise Privacy
Authorization Language (EP AL 1.1), 2003.
[14] Damianou, N., Dula y, N., Lupu, E., and Sloman, M.
Ponder: A Language for Specifying Security and Management Policies for
Distributed Systems. The Language Specification - Version 2.3. Imperial College
Research Report DoC 2000/1, Oct. 2000.
[15] Jajodia, S., Samara ti, P., Sapino, M. L., and
Subrahmanian, V. S. Flexible support for multiple access control policies. ACM
Trans. DatabaseSyst. 26, 2 (2001), pages 214-260.
[16] Godik, S., and Moses, T. extensible access control
markup language (XACML)version 1.1, Aug.2003.
| 
