Le modèle Or-BAC (Organization Based Access Control)

1. Le modèle Or-BAC(Organization Based Access Control) Frédéric Cuppens

2. 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 … Frederic.Cuppens@telecom-bretagne.eu

3. 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 Frederic.Cuppens@telecom-bretagne.eu

4. 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éé Frederic.Cuppens@telecom-bretagne.eu

5. 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 Frederic.Cuppens@telecom-bretagne.eu

6. 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 Frederic.Cuppens@telecom-bretagne.eu

7. 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 Frederic.Cuppens@telecom-bretagne.eu

8. 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 autre • Dans 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-organisations • Chaque organisation ou sous-organisation gère sa propre politique de permissions • Les 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 Frederic.Cuppens@telecom-bretagne.eu

9. De T-MAC à Or-BAC Équipe-Permission Rôle-Permission • 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 Organisation—Rôle—Permission T-MAC utilise deux relations binaires Or-BAC utilise une seule relation ternaire Frederic.Cuppens@telecom-bretagne.eu

10. 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) Frederic.Cuppens@telecom-bretagne.eu

11. 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 Frederic.Cuppens@telecom-bretagne.eu

12. 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 • Expression de permissions, d’interdictions, et d’obligations • Expression des contextes Frederic.Cuppens@telecom-bretagne.eu

13. 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) Frederic.Cuppens@telecom-bretagne.eu

14. Activité Rôle Vue Sujet Action Objet Le modèle Or-BAC Organisation Frederic.Cuppens@telecom-bretagne.eu

15. 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 Frederic.Cuppens@telecom-bretagne.eu

16. 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, …) Frederic.Cuppens@telecom-bretagne.eu

17. Le modèle Or-BAC • Abstractions des trois entités concrètes en trois entités abstraites • Les entités concrètes • Les sujets, les actions et les objets • Au niveau du système d’informations, les permissions sont concrètes • On définit trois nouvelles entités • Les rôles : abstractions des sujets • Les activités : abstractions des actions • Les vues : abstractions des objets • Un obtient une politique de contrôle d’accès à deux niveaux • Intérêt • S’affranchir de l’implémentation • Obtenir une politique de sécurité générique Frederic.Cuppens@telecom-bretagne.eu

18. Subject Role Empower Organization 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 Empower • Une organisation habilite un sujet dansun certain rôle • Empower (Organization, Subject, Role) • Ex : Empower(hopital_sud, jean, medecin) Frederic.Cuppens@telecom-bretagne.eu

19. 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) Frederic.Cuppens@telecom-bretagne.eu

20. 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) Frederic.Cuppens@telecom-bretagne.eu

21. Activité Rôle Vue Sujet Action Objet Empower, Consider, Use Organisation Empower Consider Use Frederic.Cuppens@telecom-bretagne.eu

22. Définition des contextes: Hold • Expression des contextes • Modéliser un règlement de sécurité en fonction de circonstances concrètes • L’heure de la journée • L’état du système (mode normal, mode dégradé) • « Lieu » où est réalisée l’activité • … • La relation Hold • Une organisation définit que tel sujet réalise telle action sur tel objet dans un contexte donné • Hold (Organization, Subject, Action, Object, Context) Frederic.Cuppens@telecom-bretagne.eu

23. Définition des contextes Noter l’utilisation d’un formalisme provenant de Rule-Based Access Control • Exemple de contextes • Contexte grève Organisation(org)  En-grève(s)  Action(a)  Objet(o)  Hold (org, s, a, o, grève) • Contexte urgence Use(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_medecin Use(hopital_sud, o, dossier-medical)  Dossier-patient(o,p)  Patient-medecin(p,s) Action(a)  Hold (hopital_sud, s, a, o, patient_du_medecin) Frederic.Cuppens@telecom-bretagne.eu

24. Définition des contextes • Exemple de contextes • Contexte defaut Organisation(org)  Sujet(s)  Action(a)  Objet(o)  Hold (org, s, a, o, defaut) • Contexte heure_de_travail Sujet(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 defaut: aucune condition contextuelle Frederic.Cuppens@telecom-bretagne.eu

25. Taxonomie de contextes Frederic.Cuppens@telecom-bretagne.eu

26. 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) Consider Empower Use Hold Frederic.Cuppens@telecom-bretagne.eu

27. 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) Frederic.Cuppens@telecom-bretagne.eu

28. 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 Frederic.Cuppens@telecom-bretagne.eu

29. 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(subject,action, object) Frederic.Cuppens@telecom-bretagne.eu

30. 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) Frederic.Cuppens@telecom-bretagne.eu

31. Role View Permission Hold Consider Empower Use Is_permitted Récapitulatif Abstract level Activity Context Organization Concrete level Action Object Subject Frederic.Cuppens@telecom-bretagne.eu

32. 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 + 6mois) Frederic.Cuppens@telecom-bretagne.eu

33. 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.) Frederic.Cuppens@telecom-bretagne.eu

34. 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 interditele 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 Frederic.Cuppens@telecom-bretagne.eu

35. 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 abstraites P-Permission (Organization, Role, Activity, View, Context, Priority) P-Interdiction (Organization, Role, Activity, View, Context, Priority) Frederic.Cuppens@telecom-bretagne.eu

36. 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(subject,action, object, priority) Frederic.Cuppens@telecom-bretagne.eu

37. 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 Frederic.Cuppens@telecom-bretagne.eu

38. 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 Frederic.Cuppens@telecom-bretagne.eu

39. 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 ? Frederic.Cuppens@telecom-bretagne.eu

40. 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 Frederic.Cuppens@telecom-bretagne.eu

41. 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) Frederic.Cuppens@telecom-bretagne.eu

42. 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 Frederic.Cuppens@telecom-bretagne.eu

43. 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 conflit • Spécifier que R4  R7 • Spécifier que R7  R4 • 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 Frederic.Cuppens@telecom-bretagne.eu

44. Administration du modèle • AdOr-BAC : Administration Model for Or-BAC • Principe : • Déterminer les droits correspondant à la réalisation de ces tâches • Contrô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 Frederic.Cuppens@telecom-bretagne.eu

45. 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 Frederic.Cuppens@telecom-bretagne.eu

46. Billet d’avion Compagnie aérienne Numéro de vol Nom du passager Date et heure Numéro de siège 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 Frederic.Cuppens@telecom-bretagne.eu

47. context privilege Activity grantee Role View Permission target issuer Consider Organization Empower Use Action Object Is_permitted Subject Administration du modèle Context View_PRA Frederic.Cuppens@telecom-bretagne.eu

48. 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 Frederic.Cuppens@telecom-bretagne.eu

49. stockage saisie API consultation affichage BDD MotOr-BAC • Logiciel open source disponible sur sourceforge.net Détection et gestion des conflits déclenchement de l’analyse de cohérence résultats de l’analyse GUI JENA JAVA JAVA Frederic.Cuppens@telecom-bretagne.eu

50. Dynamic constraint Dynamic organization Context hierarchy Context Constraint Or-BAC Organization Subject / Role Action / Activity Object / View Permission Hierarchy Prohibition Conflict management Conflict management Obligation Le modèle Or-BAC : récapitulatif Frederic.Cuppens@telecom-bretagne.eu