Embed Size (px)
DESCRIPTION
Le modèle Or-BAC (Organization Based Access Control). Frédéric Cuppens. NB de Luigi Logrippo. Ces notes de cours nous ont été gracieusement fournies par un des créateurs de OrBAC, le Prof. Frédéric Cuppens de Télécom Bretagne Un grand remerciement à lui … - PowerPoint PPT Presentation
Citation preview
Le modèle Or-BAC(Organization Based Access
Control)
Frédéric Cuppens
NB de Luigi Logrippo
Ces notes de cours nous ont été gracieusement fournies par un des créateurs de OrBAC, le Prof. Frédéric Cuppens de Télécom Bretagne Un grand remerciement à lui …
Cependant LL a ajouté plusieurs diapositives et points d’éclaircissement, espérant que tout soit correct, et que l’auteur principal ne soit pas en désaccord …
2
Plan
Pourquoi un nouveau modèle de contrôle d’accès ?
Le modèle Or-BAC Concepts de base Gestion des contextes Définition de la politique de contrôle d’accès Gestion des conflits Administration
Implantation de Or-BAC Fonctionnalités de MotOr-BAC
3
Pourquoi un nouveau modèle de contrôle d’accès ? DAC (HRU, 1975)
Modèle de contrôle d’accès Ensemble de faits :
Permission( Sujeti, Actionk , Objetl )
Limites de DAC Expressivité limitée
Impossible d’exprimer des règles dépendant du contexte Exemple : permission seulement pendant les heures de
travail Pas de structuration
La politique de contrôle d’accès doit être mise à jour chaque fois qu’un nouveau sujet ou un nouvel objet est créé
4
Pourquoi un nouveau modèle de contrôle d’accès ? RBAC (Sandhu, 1996)
Avantages de RBAC Structuration de la politique de contrôle d’accès par la notion de
rôle Conception modulaire grâce à la hiérarchie de rôle
Héritage des permissions
Inconvénients Expressivité limitée
Les sujets jouant le même rôle auront les mêmes permissions Pas de permissions contextuelles
Structuration limitée Besoin d’expliciter la structure d’une permission en fonction de
l’application Modèle d’administration séparé du reste de RBAC
Notion de rôle administratif distincte des rôles standards
5
Idées qui ont conduit au modèles Or-BAC Plusieurs développement ont fourni des idées qui
ont conduit au modèle OrBAC T-BAC, V-BAC, T-MAC, Ru-BAC
6
Variations de RBAC
T-BAC: (T=Task) l’utilisateur ne doit obtenir une permission que lorsque ceci est nécessaire pour poursuivre l’exécution de son activité Ex.: achat d'un billet d'avion, la permission d’éditer une facture
ne doit être activée qu'après la réservation et l'achat du billet V-BAC: (V=View) une vue correspond au résultat d'une
requête SQL auquel on a donné un nom Une vue constitue donc un moyen efficace pour accorder un
accès à l'ensemble des objets contenus dans la vue par exemple définir une vue contenant l'ensemble des objets
ayant pour suffixe .doc et appartenant au répertoire /pierre/projet1
Les commandes GRANT et REVOKE sont appliquées à la vue VR-BAC combine les concepts de rôle et de vue
7
T-MAC: Team Based Access Control
Prend en considération le fait qu’on peut avoir plusieurs organisations et qu’une organisation est un modèle structuré Un utilisateur d’une organisation peut souhaiter avoir accès
aux données d’une autreDans les services web, un usager d’une org peut
demander accès aux données d’une autre org Un hôpital peut se décomposer en plusieurs sous-
organisationsChaque organisation ou sous-organisation gère sa propre
politique de permissionsLes organisations ou sous-organisations peuvent être
crées ou dissoutes dynamiquement Donc les permissions doivent être associées non seulement
aux rôles, mais aussi aux organisations dans lesquelles un sujet exerce son rôle
8
De T-MAC à Or-BAC
Un sujet obtient des permissions en fonction des rôles qu’il joue dans une certaine organisation
Ex.: les permissions du rôle médecin changent suivant qu'il s'agit d'un médecin dans une équipe de garde ou d'un médecin dans une équipe d'urgence
9
Équipe-Permission
Rôle-Permission
Organisation—Rôle—Permission
T-MAC utilise deux relations binaires
Or-BAC utilise une seule relation ternaire
Rule-Based Access Control
Rule Based Access Control Jajodia et al. (1997) Bertino et al. (2003) Halpern et Weissman (2003)
Modèle de contrôle d’accès Ensemble de règles :
Condition Permission( Sujet, Action , Objet )
Exemple : Un médecin a la permission de consulter les dossiers médicaux de ses patients pendant les heures de travail medecin(s) dossier_medical(o)
patient(s,p) id_patient(o,p) 08:00 GLOBAL_CLOCK GLOBAL_CLOCK 20:00
Permission(s,consulter,o)
10
De Ru-BAC à RBAC
Avantage de Rule Based Access Control Expressivité plus importante que DAC et RBAC
Inconvénients Règles rapidement complexes à exprimer Pas de structuration Modèle d’administration à définir
11
Le modèle Or-BAC Or-BAC : contrôle d’accès basé sur les organisations
Utilise ensemble les idées que nous venons de voir Objectif
Introduire un niveau d’abstraction permettant d’exprimer la politique de contrôle d’accès indépendamment de son implantation
Quatre principes L’organisation est l’entité centrale du modèle Deux niveaux d’abstraction
Niveau concret : sujet , action , objet Niveau abstrait : rôle, activité , vue
EExpression de permissions, d’interdictions, et d’obligations EExpression des contextes
12
Avantages principaux par rapport à RBAC
Considération explicite de l’aspect « organisation » ou équipe
Hiérarchies non seulement de sujets, but aussi d’actions et d’objets
Concept de contexte et possibilité de spécifier conditions booléennes de complexité arbitraire sur le contexte
Permissions négatives Langage de spécification formel et précis, comme
un langage de programmation Environnement d’exécution pleinement développé
et utilisable (MotOrBAC)
13
Le modèle Or-BAC
ActionAction ObjetObjetSujetSujet
RôleRôle VueVueActivitéActivité
OrganisationOrganisation
14
Abstractions sur différents éléments
Par la notion de Rôle, RBAC permet d’abstraire par rapport aux sujets Des règles s’appliquent à des classes structurées de
sujets
OrBAC fait l’extension de cette idée et l’applique aux actions et aux objets Les règles d’OrBAC peuvent être appliquées à des
classes structurées d’actions et objets
15
Action ObjetSujet
Rôle VueActivité
Organisation
Le modèle Or-BAC
L’organisation est l’entité centrale du modèle Objectifs
Décliner une politique de sécurité suivant les organisations
Formalisme commun aux différentes organisations Assurer l’Interopérabilité de différentes organisations
Hiérarchie d’organisations Décomposition de la politique de contrôle d’accès sur
les sous organisations (départements, unités, …)
16
Action ObjetSujet
Rôle VueActivité
Organisation
Le modèle Or-BAC
Abstractions des trois entités concrètes en trois entités abstraites
Les entités concrètesLes sujets, les actions et les objetsAu niveau du système d’informations, les permissions sont
concrètes
On définit trois nouvelles entitésLes rôles : abstractions des sujetsLes activités : abstractions des actionsLes vues : abstractions des objets
Un obtient une politique de contrôle d’accès à deux niveaux Intérêt
S’affranchir de l’implémentationObtenir une politique de sécurité générique
17
Le modèle Or-BAC: Empower Rôle
Les rôles Concept introduit dans le modèle RBAC
Un sujet obtient des permissions en fonction du ou des rôles qu’il joue dans une certaine organisation
Ex : Jean joue le rôle de médecin à l’hôpital Sud
Relation EmpowerUne organisation habilite un sujet dans un certain rôleEmpower (Organization, Subject, Role)
Ex : Empower(hopital_sud, jean, medecin)
Subject
Organization
RoleEmpower
18
Le modèle Or-BAC: Consider Action
Les actions Vision classique des actions
Type spécifique d'interaction entre les sujets et les objets (« lire », « écrire », …)
Les activités Abstraction des actions Une activité est un ensemble d’actions ayant des
propriétés communes La relation Consider
Une organisation considère qu’une action entre dans la réalisation d’une certaine activité
Consider (Organization, Action, Activity) Ex : Consider(hopital_sud, acroread,consultation)
19
Le modèle Or-BAC: Use Objet
Les objets Entité passive au sens traditionnel
Les vues Abstraction des objets Proche du concept de vue dans les bases de données Relation Use
Une organisation utilise un objet dans une certaine vue
Use (Organization, Object, View) Ex : Use(hopital_sud, fich27.pdf, dossier_medical)
20
Empower, Consider, Use
21
Empower Consider
Use
ActionAction ObjetObjetSujetSujet
RôleRôle VueVueActivitéActivité
OrganisationOrganisation
Définition des contextes: Hold
Expression des contextes Modéliser un règlement de sécurité en fonction de
circonstances concrètesL’heure de la journéeL’état du système (mode normal, mode dégradé)« Lieu » où est réalisée l’activité…
La relation HoldUne organisation définit que tel sujetréalise telle action sur tel objet dans un contexte donnéHold (Organization, Subject, Action, Object, Context)
22
Définition des contextes
Exemple de contextes Contexte grève
Organisation(org) En-grève(s) Action(a) Objet(o) Hold (org, s, a, o, grève)
Contexte urgenceUse(hopital_sud, o, dossier-medical) Dossier-patient(o,p) Cas-urgent(p,s) Action(a)
Hold (hopital_sud, s, a, o, urgence)
Contexte patient_du_medecinUse(hopital_sud, o, dossier-medical) Dossier-patient(o,p) Patient-medecin(p,s) Action(a)
Hold (hopital_sud, s, a, o, patient_du_medecin)
23
Noter l’utilisation d’un formalisme provenant de Rule-Based Access Control
Définition des contextes Exemple de contextes
Contexte defautOrganisation(org) Sujet(s) Action(a) Objet(o)
Hold (org, s, a, o, defaut)
Contexte heure_de_travailSujet(s) Action(a) Objet(o)08:00 CLOCK CLOCK 20:00
Hold (hopital_sud, s, a, o, heure_de_travail)
Expressions booléennes de contexte Contextes conjontifs, disjonctifs, négatifs Ex : patient_du_medecin & heure_de_travail
24
defaut: aucune condition contextuelle
Politiques de contrôle d’accès en Or-BAC Introduction des relations Permission et
Interdiction Permission (Organization, Role, Activity, View, Contexte) Interdiction (Organization, Role, Activity, View, Contexte)
26
Empower
Consider
Use
Hold
Définition d’une politique de contrôle d’accès Exemples de permission :
Permission(hopital_sud, sec-medical, gerer, rendez-vous, defaut)
Interdiction(hopital_sud, infirmier, consulter, dossier_medical, defaut)
Permission(hopital_sud, infirmier, consulter, dossier_soin, defaut)
Permission(hopital_sud, medecin, consulter, dossier_medical,patient_du_medecin)
Permission(hopital_sud, infirmier, consulter, dossier_medical, urgence)
Interdiction(hopital_sud, medecin, consulter, dossier_medical, greve)
27
Définition d’une politique de contrôle d’accès Permission abstraite
Permission (Organization, Role, Activity, View, Context)
Permission concrète Is_permitted(subject, action, object)
Exemple de permissions, d’interdictions et d’obligations concrètes Jean a la permission de lire le document toto.doc Jean a l’interdiction de supprimer le document toto.doc
28
Définition d’une politique de contrôle d’accès Les permissions concrètes sont déduites des
permissions abstraites Règle GR1 :
Règle similaire GR2 pour l’interdiction
Permission (org, role, activity, view, context) Empower (org, subject, role) Consider (org, action, activity) Use (org, object, view) Hold(org,suject,action,object,context)
Is_permitted Is_permitted ((subjectsubject,, action action, , objectobject))
Permission (org, role, activity, view, context) Empower (org, subject, role) Consider (org, action, activity) Use (org, object, view) Hold(org,suject,action,object,context)
Is_permitted Is_permitted ((subjectsubject,, action action, , objectobject))
29
Exemple de dérivation
Empower(hopital_sud, jean, medecin) Consider(hopital_sud, acroread, consultation) Use(hopital_sud, fich27.pdf, dossier_medical) Dossier-patient(fich27.pdf,paul) Patient-medecin(paul, jean)
Permission(hopital_sud, medecin, consulter, dossier_medical,patient-medecin)
Use(hopital_sud, o, dossier-medical) Dossier-patient(o,p) Patient-medecin(p,s) Action(a)
Hold (hopital_sud, s, a, o, patient-medecin)
Hold (hopital_sud, jean, acroread, fich27.pdf, patient-medecin) Is-permitted(jean, acroread, fich27.pdf)
30
Récapitulatif
Permission
Consider
Activity
Role
Empower OrganizationOrganization
View
Use
Abstract level
ObjectSubject
Action
Is_permitted
Concrete level
Context
31
Hold
Obligations
Dans Or-BAC il est aussi possible d’exprimer des règles d’obligation
Obligation (Organization, Role, Activity, View, Contexte)
Exemple: Un usager doit changer son mot de passe tous les six mois
Obligation (hopital_sud, medecin, changer, mot_passe,date –courante >= date-dernier-changement + 6
mois)
32
Autre exemple d’obligation
Dans une organisation, on peut aussi avoir des obligations de type différent, comme p.ex.
Chaque fois qu’un médecin consulte un dossier d’un patient qui n’est pas à lui, un message est automatiquement envoyé à son chef de rayon
Ce type d’obligation peut aussi être spécifié en Or-BAC, mais les contextes à considérer sont de type différent (histoire, etc.)
33
Possibilité de conflits
Il est important de comprendre que deux règles peuvent être parfois en conflit, parfois non
Ceci peut être dû aux conditions de contextes auxquels les règles sont assujetties
Exemple: Il est permis d’exécuter l’action X seulement les mercredis L’action X est interdite le premier jour de chaque mois
Un conflit se vérifiera seulement les premiers jours des mois qui sont aussi des mercredis
Parfois il pourrait être très difficile de déterminer si certaines combinaisons de conditions peuvent être vraies en même temps
Un outil doit signaler la possibilité de conflit et La vérification du conflit réel doit être laissée au jugement
d’une personne
34
Gestion des conflits
Définition Conflit Is_permitted(s,a,o) Is_prohibited(s,a,o)
Objectif Résoudre les conflits entre permissions et interdictions Respecter les contraintes Résolution au niveau abstrait
Principe La priorité entre règles peut être utilisée pour résoudre les
conflits Niveaux de priorité associés aux permissions et interdictions
abstraitesP-Permission (Organization, Role, Activity, View, Context, Priority)P-Interdiction (Organization, Role, Activity, View, Context, Priority)
35
Gestion des conflits (suite)
Dérivation des permissions concrètes avec priorité Règle P-RG1 (remplace RG1) :
Règle P-RG2 identique pour dériver les interdictions
P-Permission (org, role, activity, vue, context, priority) Empower (org, subject, role) Consider (org, action, activity) Use (org, object, view) Hold(org, subject, action, object, context)
P-Is-permitted P-Is-permitted ((subjectsubject,, action action, , object, object, prioritypriority))
P-Permission (org, role, activity, vue, context, priority) Empower (org, subject, role) Consider (org, action, activity) Use (org, object, view) Hold(org, subject, action, object, context)
P-Is-permitted P-Is-permitted ((subjectsubject,, action action, , object, object, prioritypriority))
36
Dérivation des permissions concrètes effectives Prédicats Higher-Permission et Higher-
Interdiction : P-Is-permitted(s,a,o,p2) p1 p2
Higher-Permission(s,a,o,p1) P-Is-prohibited(s,a,o,p2) p1 p2
Higher-Interdiction(s,a,o,p1)
Higher-Permission(s,a,o,p1) veut dire qu’il existe une permission pour le sujet s, action a et objet o qui a une priorité plus élevée que p1
Pareil pour prohibition
37
Stratégie pour priorité
Axiomes de stratégie avec priorité : P-Is-permitted(s,a,o,p1) Higher-Interdiction(s,a,o,p1)
Is-permitted(s,a,o) P-Is-prohibited(s,a,o,p1) Higher-Permission(s,a,o,p1)
Is-prohibited(s,a,o)
Donc (s,a,o) est permis s’il n’y a pas une interdiction plus élevée pour (s,a,o)
Pareil pour prohibition
38
Comment garantir que les conflits sont résolus ? Cas 1 :
Les règles de la politique de sécurité sont totalement ordonnées Tous les conflits sont résolus
Mais, un ordre total est difficile à gérer Mais, il est inutile d’ordonner certaines règles
Cas 2 : Les règles sont partiellement ordonnées Besoin d’une condition supplémentaires pour garantir
que les conflits sont résolus ?
39
Comment garantir que les conflits sont résolus ? Solution
Résoudre les conflits potentiels au niveau abstrait
Conflit potentiel Il existe une règle R1 :
Permission (Org1, Role1, Activity1, View1, Context1)
Il existe une règle R2 :Interdiction (Org2, Role2, Activity2, View2, Context2)
• R1 et R2 peuvent s’appliquer en même temps
• Contraintes de séparation• Pour détecter les règles qui ne peuvent pas s’appliquer
en même temps
40
Contraintes de séparation
Prédicat separated-role(org, r1, r2) Dans l’organisation org, les rôles r1 et r2 sont séparés Contrainte associée :
separated-role(org, r1, r2) empower(org, s, r1) empower(org, s, r2)
erreur()
On définit de même les notions de séparation d’activités, de vues et de contexte Prédicat separated-activity(org, a1, a2) Prédicat separated-view(org, v1, v2) Prédicat separated-context(org, c1, c2)
41
Gestion des conflits potentiels Détection des conflits potentiels au niveau abstrait
Un conflit potentiel existe au niveau abstrait si la condition suivante est satisfaite :
P-Permission(org, r1, a1, v1, c1, p1) P-Interdiction(org, r2, a2, v2, c2, p2) ¬ (p1 p2) ¬ (p2 p1) ¬ (separated-role(org, r1, r2)) ¬ (separated-activity(org, v1, v2)) ¬ (separated-view(org, v1, v2)) ¬ (separated-context(org, c1, c2))
Théorème : S’il n’est pas possible de dériver la condition ci-dessus, alors on a la
garantie qu’aucun conflit ne peut exister au niveau concret C’est-à-dire on ne peut pas avoir
Is-permitted(s, a, o) Is-prohibited(s, a, o)
La détection des conflits potentiels est calculable en temps polynomial
42
Gestion des conflits potentiels
Exemple : P-Permission(hopital_sud, medecin, consulter,
dossier_medical,patient_du_medecin, R4)
P-Interdiction(hopital_sud, directeur, consulter, dossier_medical,
defaut, R7)
Conflit si un sujet jouent les rôles de médecin et de directeur dans l’hôpital sud
Trois solutions possibles pour résoudre le conflit1. Spécifier que R4 R72. Spécifier que R7 R43. Spécifier que les rôles médecin et directeur sont séparés
Un sujet ne pourra pas jouer simultanément ces deux rôles
43
Administration du modèle
AdOr-BAC : Administration Model for Or-BAC Principe :
Déterminer les droits correspondant à la réalisation de ces tâchesContrôle d’accès appliqué aux tâches administratives
Objectifs Absence de séparation entre les rôles administratifs et
les rôles standard Les règles « administratives » doivent avoir le même
format que les règles standard Permettre la délégation
44
Administration du modèle
Administration par la gestion de vues- Vue PRA :
- Affectation des sujets aux rôles- Vue URA :
- Affectation des permissions aux rôles- Vue UPA :
- Délégation
45
Administration du modèle
Affectation des permissions aux rôles Vue PRA : Permission Role Assignment
Principe Donner une permission revient à créer un ticket
Donner une permission = insérer un objet dans la vue PRA
Administrer les droits = définir les permissions sur PRA
Billet d’avion
Numéro de siège
Nom du passager
Compagnie aérienne Numéro de vol
Date et heure
46
Administration du modèle
Permission
Consider
Activity
Role
Empower OrganizationOrganization
View
Use
ObjectSubject
Action
Is_permitted
View_PRA
issuer
target
grantee
privilege Context
context
47
MotOr-BAC
Outil de saisie de la politique de sécurité abstraite Organisation, rôles, activités, vues, règles
Outil de vérification de la politique de sécurité Détection des conflits et gestion de contraintes
Outil de simulation Saisie des sujets, des actions et des objets Dérivation des permissions concrètes
48
MotOr-BAC
BDDBDD GUIGUIAPIAPI
affichage
saisie
consultation
stockage
Détection et gestion des
conflits
Détection et gestion des
conflits déclenchement de l’analyse de cohérencerésultats de
l’analyse
JAVA JAVAJENA
Logiciel open source disponible sur sourceforge.net
49
Le modèle Or-BAC : récapitulatif
OrganizationSubject / RoleAction / ActivityObject / ViewPermission
Or-BAC
Dynamicorganization
Constraint
Prohibition
Context
Hierarchy
Obligation
Dynamicconstraint
Conflictmanagement
Contexthierarchy
Conflictmanagement
50
Conclusion
Système très flexible de plusieurs points de vue
Langage formel pour la spécification de politiques
Gestion des hiérarchies d’héritage Hiérarchies de rôles, de vues, d’activités, de contextes et
d’organisation
Méthode formelle pour la décomposition et le raffinement de politiques de sécurité
Gestion et résolution des conflits entre règles
Simplification de l’administration de la politique
Outil MotOr-BAC pleinement fonctionnel et public pour utilisation et expérimentation
Pas d’utilisation industrielle, malgré tout …
51
![Segmentation of the Optic Nerve Head Based on … › open-access › segmentation-of-the...above [7-9], for the estimation of the distribution of hemoglobin in normal and glaucomatous](https://img.pdfslide.fr/doc/110x75/5f0d99477e708231d43b2691/segmentation-of-the-optic-nerve-head-based-on-a-open-access-a-segmentation-of-the.jpg)
