le mod le or bac organization based access control n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Le modèle Or-BAC (Organization Based Access Control) PowerPoint Presentation
Download Presentation
Le modèle Or-BAC (Organization Based Access Control)

Loading in 2 Seconds...

play fullscreen
1 / 51

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


  • 73 Views
  • Uploaded on

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 …

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Le modèle Or-BAC (Organization Based Access Control)' - hall


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
nb de luigi logrippo
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

slide3
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

pourquoi un nouveau mod le de contr le d acc s
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

pourquoi un nouveau mod le de contr le d acc s1
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

id es qui ont conduit au mod les or bac
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

variations de rbac
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

t mac team based access control
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

de t mac or bac
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

rule based access control
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

de ru bac rbac
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

le mod le or bac
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

avantages principaux par rapport rbac
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

le mod le or bac1

Activité

Rôle

Vue

Sujet

Action

Objet

Le modèle Or-BAC

Organisation

Frederic.Cuppens@telecom-bretagne.eu

abstractions sur diff rents l ments
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

le mod le or bac2
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

le mod le or bac3
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

le mod le or bac empower r le

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

le mod le or bac consider action
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

le mod le or bac use objet
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

empower consider use

Activité

Rôle

Vue

Sujet

Action

Objet

Empower, Consider, Use

Organisation

Empower

Consider

Use

Frederic.Cuppens@telecom-bretagne.eu

d finition des contextes hold
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

d finition des contextes
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

d finition des contextes1
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

taxonomie de contextes
Taxonomie de contextes

Frederic.Cuppens@telecom-bretagne.eu

politiques de contr le d acc s en or bac
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

d finition d une politique de contr le d acc s
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

d finition d une politique de contr le d acc s1
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

d finition d une politique de contr le d acc s2
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

exemple de d rivation
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

r capitulatif

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

obligations
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

autre exemple d obligation
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

possibilit de conflits
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

gestion des conflits
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

gestion des conflits suite
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

d rivation des permissions concr tes effectives
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

strat gie pour priorit
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

comment garantir que les conflits sont r solus
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

comment garantir que les conflits sont r solus1
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

contraintes de s paration
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

gestion des conflits potentiels
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

gestion des conflits potentiels1
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

administration du mod le
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

administration du mod le1
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

administration du mod le2

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

administration du mod le3

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

motor bac
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

motor bac1

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

le mod le or bac r capitulatif

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

conclusion
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 …

Frederic.Cuppens@telecom-bretagne.eu