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.
| 
