Modèle de contrôle d'accés
•Als PPTX, PDF herunterladen•
1 gefällt mir•1,527 views
Modèle de contrôle d'accés insipiré d'ORBAC ,
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (18)
Ähnlich wie Modèle de contrôle d'accés
Modèle de contrôle d'accés
- 1. Présenté par : Bouafia Doria. Ziraoui Bouchra. Proposé et encadré: Docteur N.Boustia. 1
- 2. 1. Problématique . 2. Travaux réalisés dans le même axe de recherche ( la délégation). 3. Objectifs . 4. Le contrôle d’accès. 5. La délégation . 6. La notion de non monotonie. 7. Modélisation . 8. Réalisation . 9. Conclusion et perspectives . 2
- 3. réaliser un modèle de contrôle d’accès comprenant la modélisation du concept de délégation formalisé avec une logique non monotone . 3 Délégation non monotone dans le contrôle d’accès
- 4. 4 Sujet Institution/ organisme de recherche Caractéristiques Managing Delegation in Access Control Models ENST BRETAGNE • Modèle de délégation pour OrBAC • Formalisme utilisé : logique du premier ordre La délégation des permissions dans le contrôle d’accès avec logique de description Saad Dahleb/ LRIS -USTHB • Modèle de délégation pour OrBAC • Formalisme utilisé: logique de description.
- 5. 5 I. Conception d’un modèle de contrôle d’accès : 1) Inspiré d’OrBAC. 2) Incluant la modélisation de la délégation . 3) Basé sur une logique non monotone qui est une logique défaut () et exception (). II. Application de ce modèle sur un exemple concret.
- 6. les modèles de contrôle d'accès discrétionnaires. DAC les modèles de contrôle d'accès obligatoires. MAC Modèle de sécurité à base de rôle. RBAC Inconvénient Majeur : Ces modèles ne permettent de modéliser que les politiques de sécurité qui se restreignent à des permissions statiques .[1] 6 [1]:Anas Abou El Kalam, Rania El Baida, Philippe Balbiani,Salem Benferhat,Frédéric Cuppens, Yves Deswarte, Alexandre Miège,Claire Saurel, Gilles Trouessin, « ORBAC : un modèle de contrôle d’accès basé sur les organisations », projet RNRT MP6 (Modèles et Politiques de Sécurité des Systèmes d’ Informations et de Communication en Santé et en Social). OrBAC
- 9. 9 Action sujet Activité contexte Objet Rôle Vue Permission Est-Permis Niveau concret Niveau abstrait
- 11. 11 Le modèle AdOr-BAC permet d‘administrer une politique de sécurité Or- BAC. Il permet de gérer toutes ces relations. [2] PRA (Permission-Role Assignment) URA (User-Role Assignment) : UPA (User-Permission Assignment) : Délégation [2]:Mokhtari Mohamed Amine ,Ghersi Cherifa « Mémoire pour l’obtention d’un Master « Délégation dans le contrôle d’accès avec logique de description » , juillet 2012
- 12. 12 Rôle assignment Licence assignment
- 13. La délégation permet de donner à un utilisateur particulier un privilège, sans donner ce privilège à toutes les personnes ayant le même rôle que lui. [3] [3]:www.orbac.org. 13
- 14. 14 Délégation temporaire/ permanente Délégation monotone/non monotone Délégation Grant- dependant/Grant- independant Délégation par accord unilatéral/bilatéral Délégation totale/partielle Délégation simple/multiple Délégation par agent /auto-active Délégation à un-pas/à pas-multiple
- 15. 15 Révocation simple Révocation GD Révocation en cascade Révocation GID
- 16. 16
- 17. 17 TBOX ABOX Inférence Langage de description Base de connaissances Définition des concepts et leur propriétés Déclaration des instances ( individus)
- 18. 18 Critère de comparaison Logique du premier ordre Logique de description Complexité Calcul des prédicats semi décidable Algorithmes d’inférence décidables et parfois polynomiaux. Structuration des connaissances NON OUI
- 19. 19 CClassicδε comprend tous les connecteurs de la LD C‐CLASSIC les connecteurs δ et ε d’ALδε 21
- 20. 20
- 21. 21 La TBOX Des entités et relations d’OrBAC La ABOX des individus de la TBOX décrite (instances) Représentation logique Représentation logique De la délégation Héritage
- 22. 22 Contexte défaut Contexte exception δ Est-Permis ⊑ δ Permission ⊓ Habilite ⊓ Utilise ⊓ Considère Est-Permis ε ⊑ Permission ε ⊓ Habilite ⊓ Utilise ⊓ Considère Par défaut, le contexte est normal· toute action qui n’est pas permise est interdite. Est-Permis ⊑ Est-Permis ε Est-Permis ⊑ δ Est-Permis
- 23. 23 Licence assignement Rôle assignement Licence Délégation Grant option Licence Licence transfer Rôle Délégation Vues administratives Vues de Délégation Cessionnaire C’est un sujet ou un rôle qui délègue une licence, c’est le délégant.
- 24. 24
- 25. 25 Licence Délégation Contexte exception Contexte défaut Délégation Partielle Délégation Permanente Délégation Temporaire Permission ⊑ UtiliseL.Licence_Délégation ⊓ BénéficiaireL.bénéficiaire ⊓ PrivilègeL.Action⊓ CibleL.Objet . Permission ε ⊑ UtiliseL.Licence_Délégation ⊓ BénéficiaireL.bénéficiaire ⊓ PrivilègeL.Action⊓ CibleL.Objet . 1 1 2 2
- 26. 26 Rôle Délégation Délégation totale Habilite ⊑ UtiliseRD.Rôle_Délégation ⊓ AssigneeRD.bénéficiaire ⊓ AssignmentRD.Rôle.
- 27. 27 Grant Option Licence Contexte exception Contexte défaut Délégation à n-pas. Délégation à 1-pas. Permission ⊑ UtiliseL.GOL ⊓ BénéficiaireL.bénéficiaire⊓ PrivilègeL.Action ⊓ CibleL.Objet ⊓ niveau <=niveauMax Permission ⊑ UtiliseL.GOL ⊓ BénéficiaireL.bénéficiaire⊓ PrivilègeL.Action ⊓ Cible.Objet⊓ niveau <=niveauMax 1 1 2 2
- 28. 28 Licence Transfer Contexte exception Contexte défaut Délégation Non monotone Délégation Monotone Licence_Délégation ⊑ UtiliseL.licence_transfer Licence_Délégation ⊑ UtiliseL.licence_transfer 1 1 2 2
- 29. 29
- 30. 30 Révocation GD Révocation GID Révocation en cascade Définit ⊑ UtiliseL.Licence_Délégation ⊓ CessionnaireL.cessionnaire. Définit ⊑ UtiliseL.Licence_Délégation ⊓ CessionnaireL.cessionnaire ⊓ HabiliteGR.Rôle⊓ HabiliteU.Rôle. Délégation en cascade Licence délégation
- 31. 31
- 32. 32 Le Système d’information médical du service de cardiologie de l’hôpital Frantz-Fanon. 1. Nous avons dressé trois organigrammes pour la hiérarchisation de rôles , d’activités et de vues . 2. Cette hiérarchisation est particulièrement utile pour appliquer le mécanisme d’inférence d’héritage . 3. Nous avons dressé une ABOX reflétant le service de cardiologie tel qu’il est, en prenant en considération que les rôles principaux vue l’effectif de ce service.
- 33. 33 Ajout/modification /suppression Ajout / suppression Service d’interrogation Pour avoir l’état actuel de la base Des entités OrBAC Des relations OrBAC
- 34. 34 Expression de la délégation Administration de la délégation Révocation avec ses différents types Expression des différents types de délégation Gestion de cessionnaires
- 35. 35 Nous avons conçu un modèle de sécurité dynamique et contextuelle où: on peut exprimer la délégation avec ses différents types en utilisant les entités et relations définies dans le modèle OrBAC. la modélisation a été réalisée avec une logique de description augmentée des operateurs et pour l’expression du contexte .
- 36. 36 Prendre en compte d’autres contextes tels que le contexte temporel et spatial. Intégrer à notre modèle, en plus des permissions les obligations et les recommandations. Etendre la prise en charge des types de délégations à tous les types existants .
- 37. 37
Hinweis der Redaktion
- Mesdames membres du jury Honorable assistance bonjour, aujourd’hui nous allons présenter notre projet de fin d’étude, portant comme intitulé « Délégation non monotone dans le contrôle d’accès» Ce sujet a été proposé et encadré par …. Et a été réalisé par moi-même ainsi que ma binome Ziraoui ⊓ .
- Pour présenter notre projet nous avons dressé le plan suivant :
- Pour définir la problématique qui a été posée dans notre sujet on décompose son intitulé . En décomposant on distingue trois notions : la délégation , la non monotonie , et le contôle d’accés . Ainsi la problématique qui a été posé était de : Nous detaillerons ces trois notions plus tard
- premier sujet sur la délégation…. Ce sujet a été traiter au sein de l’ecole nationale supérieure télécom de bretagne , l’institution meme ou est né OrBac ( modèle que nous définirons plus tard ) les caractéristiques de ce sujet est que le modèle de contrôle d’acc »s a été formalisé avec une logique du premier ordre …. Deuxième sujet …. Ce sujet a été proposé a l’université de saad dahleb et a l’université de Houari Boumediene mais sa proposition a été faite intialement par le LRIS laboratoire de recherche au sein de l’USTHB , ce modèle a été formalisé avec une logique de description ….
- Les objectifs que nous avons dressé pour notre projet :….. Ces objectifs permettent de montrer l’apport de notre projet , cet apport consiste à l’utilisation des logiques non monotones dans la modélisation de la délégation mais pas seulement on utilise également ce type de logique pour modéliser les entités et relations d’OrBAC qui nous aident à exprimer la délégation .
- Les modèles de contrôle d’accès se divise en deux classe : Les modèles de contrôle Discrétionnaire DAC, et les modèles de contrôle obligatoire Mac, on a aussi noté l’apparition du modèle a base de rôle RBAC , L’inconvénient majeur de ces modèles est l’impossibilité de modéliser des permissions dynamiques , D’où l’appariation d’un nouveau modèle de contrôle d’acces nomme OrBac, qui lui, offre la possibilité de modéliser des permission dynamique et contextuelle . Nous allons présenter brièvement ce modèle
- En premier lieu les entites d’OrBAc L’entité centrale du modèle OrBac est l’organisation, en effet OrBac est basé sur cette entité. Les autres entites d’orbac qui sont : …. Sont organisé en deux niveaux( niveaux concret, niveaux abstrait)
- Dans le modèle OrBac chaque entité du niveau abstrait est une abstraction d’une entité du niveau concret pour les lier OrBac possède des relations . Le sujet est mis en correspondance avec le rôle grace a la relation habilite, l’objet avec la vue grace a la relation utilise et l’action avec l’activité grace a la relation considère , le contexte avec toutes les entités concrètes grace a la relation définit , Toutes ses relations sont relié a l’organisation qui demeure l’entité centrale .
- Dans Orbac , une permission qui est une relation, qui lie quatre entités :rôle , vue , activité et contexte .et cela au niveau abstrait , au niveau concret une permission noté alors, est permis lie les entités sujet , objet et action.
- Orbac offre la possibilité de modéliser des hiérarchies. Qui ont trois type en premier les hiérarchies de rôle en effet un rôle peut avoir des sous rôles et ainsi de suite, le même raisonnement s’applique en deuxième aux vue, et en troisième aux activités Cette hiérarchisation est particulièrement utile pour la modélisation du mécanisme d’inférence d’héritage .
- L‘administration est un élément important d‘une politique de sécurité. Un modèle d‘administration doit permettre de déterminer les utilisateurs qui ont le droit de faire évoluer la politique de sécurité. ……………………………………………… Adorbac comporte en particulier trois sous modèles La vue UPA permet la mise en Œuvre des mécanismes de délégation
- Pour administrer la politique de sécurité il faut définir des fonctions administratives en considérant différentes vues administratives. Les objets qui appartiennent à ces vues ont une sémantique spéciale. On doit prendre en considération deux vues administratives, la première est la vue rôle-assignment et la seconde est la vue licence assignment. La vue rôle-assignment : l’objectif de cette vue est d’assigner à un utilisateur un rôle. La vue licence assignment: l’objectif de cette vue est de donner la permission à un utilisateur ou un rôle de faire une action ou une activité
- De manière générale ……
- Voici les types de délégations , notons que les delegations qui sont dans le meme oval ne peuvent pas avoir lieu en meme temps .
- La révocation est un aspect important dans les modèles de délégation, quand on délègue un droit il faut pouvoir le révoquer Il existe deux types de révocation , Un premier type permet de ne révoquer le droit qu’à une personne désignée c’est une révocation simple. Le deuxième type permet de révoquer le droit sur une personne, ainsi que sur toutes les personnes ayant reçu ce droit par délégation, c’est une révocation en cascade Si la délégation est temporaire, il faut pouvoir la révoquer. On a pu voir précédemment deux types de délégation jouant sur la révocation. Lorsque la délégation est "grant-dependant" alors seule la personne à l’origine de la délégation peut ôter ce droit. Quand la délégation est de type "grant-independant" seules les personnes ayant engendré la délégation d’un droit à une personne peuvent lui révoquer ce droit
- La notion de non monotonie dans ce cas est lié au formalisme utilisé pour l’écriture du modèle de sécurité . OrBAC est basé sur la logique du premier ordre où le contexte est un simple argument. Le modèle que nous avons réalisé repose sur la logique de description non monotone. Pour mieux définir la notion de non monotonie dans une logique de descriptions on commence par la présentation des logiques de description .
- Modéliser une base de connaissances en logique de description revient à formaliser une TBOX et une Abox , la Tbox contenant La définition …… Et la Abox la declaration des instances c’est-à-dire des individus , toutes deux sont formalisées avec un langage de description , l’inference se fait sur les deux niveaux terminologique pour la TBOX et factuel pour la ABOX
- Après la présentation de la logique de description nous dressons un tableau comparatif avec les logique des prédicats pour montrer pourquoi il est intéressant de formaliser les modèles de sécurité avec ce genre de logique . Du point de vue compléxité , le calcul des predicats ( l’inference) est semi decidable en logique des premier ordre quant aux logiques de decription les algorithmes d’inference sont décidables et parfois meme polynomiaux , il est plus interessant aussi d’utiliser une logique de desecription pour des connaissances structurées commes celles presentes dans les organisation ce qui est notre cas .
- 1.De nombreux travaux ont été introduits dans le but d’étendre les DLs et d’arriver à un meilleur niveau d’expressivité La logique de description C‐CLASSIC est une variante des logiques de descriptions classiques elle comprend un algorithme de calcul de subsomption polynomial, correct et complet. 2.ALδε permet d’introduire les notions défauts et exception, qui sont très importantes pour la représentation non monotone de connaissances, symbolisées par les deux connecteurs et ε.
- Puisque La modélisation de notre modèle de contrôle d’accés s’est faite en logique de description , elle s’est faite suivant la modélisation d’une TBOX et d’une ABOX ,
- La tbox de notre modèle est une ………..des entités d’orbac et de la délégation . La Abox de notre modèle est aussi une représentation logique mais cette fois ci des individus de la Tbox décrite. L’inférence dans notre modèle se fait avec le mécanisme d’héritage qui fait partie des inférences terminologiques Nous allons présenter la tbox représentant la délégation puisque c’est le but de notre étude . Avant dela nous prestons les regles de securité appliqué dans notre modèle
- Une permission par défaut existe pour un rôle R, une activité Av et une vue V dans une organisation Or (δ Permission) . Un sujet S est habilité dans ce rôle R (Habilite) . Un objet O est utilisé dans cette vue V (Utilise) . Une action Ac implémente cette activité Av (Considère). Alors Le sujet S est par défaut permis d’effectuer l’action Ac sur l’objet O (δ Est- Permis). Etant donné que Est-Permis ⊑ δ Est-Permis (une permission concrète peut être déduite D’une permission par défaut), on peut dire finalement que le sujet S a la permission D’effectuer l’action Ac sur l’objet O. Dans le cas où on a une exception sur un concept permission (Permission ε), on dit qu’on a une exception sur le concept Est-Permis noté Est-Permis ε. On sait que Est- Permis (une permission concrète ne peut être déduite d’une permission exceptionnelle), de cela on déduit que le sujet S n’est pas permis d’effectuer l’action Ac sur l’objet O. Aussi dans notre modèle : ……..
- Pour modéliser la délégation nous avons choisi d’utiliser les vues administratives définies dans AdOrbac : Licence assignement, Rôle assignement De La vue licence assignement hérite la vue Licence délégation et de la vue rôle assignement hérite la vue rôle délégation Ces vues ont les mêmes attributs que les vues administratives Avec un attribut supplémentaire appelé le cessionnaire, en plus de cela . de la vue licence délégation hérite deux autre vue : la vue licence transfert et la vue Grant Option Licence qu’on définira plus tard dans la modélisation de types de délégation .
- Dans notre modèle la délégation est auto-active et a accord unilateral , bien que nous n’avons pas modélisé ces deux types de delegations , ils sont modélisé implicitement , puisque le cessionnaire dans notre modèle et le détenteur du droit et qu’il délègue ses droits sans accord de la partie bénéficiaire .
- Pour modéliser une délégation partielle , on utilise la vue licence délégation , dans un contexte défaut , la délégation est permanente , et dans un contexte exception la délégation est temporaire . Par défaut le bénéficiaire de la licence délégation aura la permission de faire l’action Action sur l’objet Objet . Dans un contexte exception le bénéficiaire perd la permission de faire l’action Action sur l’objet Objet .
- Pour modéliser une délégation totale, on utilise la vue rôle délégation, Avec cette règle , Le bénéficiaire de la rôle délégation sera habilité a faire le role « role »
- Pour modéliser une délégation à 1 pas /à n pas , on utilise la vue grant option licence , dans un contexte défaut , la délégation est une délégation à n pas , et dans un contexte exception la délégation est une délégation à 1 pas . Par défaut le bénéficiaire de la délégation a n pas aura la permission de faire l’action Action sur l’objet Objet tant que son niveau lui permet . Dans un contexte exception le bénéficiaire a la permission de faire l’action Action sur l’objet Objet seulement si son niveau est egal au niveau max de la permission que laquelle on a généré l’exception.
- Pour modéliser la délégation monotone/non monotone utilise la vue licence transfer pour modéliser , dans un contexte défaut , la délégation est non monotone , et dans un contexte exception la délégation est monotone . Dans un contexte defaut si (L) appartient à la vue licence_délégation alors (L) appartient aussi à la vue licence_transfer en d’autre L sera une licence transferable ( l’utilisateur perdra le droit qu’il délègue) Dans un contexte exception si (L) appartient à la vue licence_délégation alors (L) ne vas plus appartenir aussi à la vue licence_transfer L n’est plus transferable c’est-à-dire que l’utilisateur conserve le droit qu’il délègue .
- Avec une révocation GD seul le cessionnaire peut révoquer les droits données par la licence qu’il a délégué . si (L) appartient à la vue licence_ délégation et (cessionnaire) est le cessionnaire de (L) alors le cessionnaire détient l’autorisation de révoquer (L) . Avec une revocation GID chaque utilisateur qui a délégué un droit meme si il nest pas le cessionnaire initiale peut revoquer ce droit si (L) appartient à la vue licence_ délégation, (cessionnaire) est le cessionnaire de (L), (GR) est habilité à faire le Rôle, Et (U) est habilité à faire le Rôle alors l’utilisateur (U) détient l’autorisation de révoquer (L). POUR la revocation en cascade On definit une nouvelle vue , vue delegation en cascade la suppression des objets appartenant a cette vue conduira à une révocation en cascade , notons que la vue delegation en cascade herite de la vue licence delegation.
- Pour appliquer notre modèle nous avons choisi un système d’information médical , ce choix nous a paru évident vue que le modèle OrBAC a été initialement crée pour le domaine médical .le système d’information qu’on a choisi est le
- En conclusion les objectifs initiaux ont été atteint ………..il reste tout de meme un certain nombre de perspectives à ce projet …