Rapport stage Dess Isa

3.1Le modèle Or-Bac

Or-Bac, Organization Based Access Control, est un modèle de politique de sécurité [2,3]. Il est issu de travaux réalisés dans le cadre du projet RNRT MP6 (Modèles de Politiques de Sécurité de Systèmes d’Informations et de Communication en Santé et en Social) et d’une thèse financée par France Télécom. Dans cette section, nous présentons les principales caractéristiques du modèle Or-Bac permettant ainsi d’en donner une vue d’ensemble. Nous introduisons dans un premier temps les différents éléments du modèle.



Figure 11 : Le modèle Or-Bac

3.1.1Les éléments du modèle

Le modèle Or-Bac définit un certain nombre d’entités et de relations (voir figure 11). Les entités sont représentées par des rectangles et les relations par des ovales. On voit se dessiner la structure à deux niveaux de la politique de sécurité où le sujet est mis en correspondance avec le rôle, l’objet avec la vue et l’action avec l’activité.

L’abstraction des entités traditionnelles du contrôle d’accès (sujet, action, objet) en méta entités (rôle, activité, vue) a pour objectif d’élaborer une politique de sécurité à deux niveaux, un niveau concret et un niveau abstrait. Le niveau abstrait permet de spécifier une politique de sécurité indépendamment de l’implantation qui en sera faite. Enfin, le concept d’organisation, offre la possibilité de définir une politique de sécurité de façon modulaire.

3.1.2L’organisation

Le concept d’organisation est central dans ce nouveau modèle. Une organisation peut être vue comme un groupe organisé d’entités actives, c’est-à-dire de sujets jouant certains rôles.

L’organisation est un des paramètres des règles de sécurité de sorte qu’il est possible de gérer simultanément plusieurs politiques de sécurité associées à différentes organisations.

Or-Bac définit des règles spécifiques à l’organisation. En particulier, l’organisation peut être structurée en plusieurs sous organisations qui ont chacune leur propre politique de sécurité. Il est également possible de spécifier une politique de sécurité générique au niveau d’une organisation mère. Ses sous organisations peuvent alors hériter de sa politique de sécurité mais aussi ajouter ou supprimer des règles et ainsi définir leur politique de sécurité. D’un point de vue pratique, cette hiérarchie permet de modéliser la structure des organisations réelles qui peuvent être constituées de départements, d’entité, d’unité …

3.1.3Les sujets et les rôles

L’entité Subject est utilisée différemment selon les modèles de sécurité. Dans le modèle Or-BAC, un sujet peut être soit une entité active, c’est-à-dire un utilisateur, soit une organisation. Dans ce modèle un sujet joue un rôle dans une organisation. Ainsi, l’entité Rôle est utilisée pour structurer le lien entre les sujets et les organisations.

Par exemple l’utilisateur « Pierre » joue le rôle « administrateur » dans l’organisation « département informatique ». Les permissions obtenues par Pierre dépendent ainsi de son rôle et de l’organisation dans laquelle il l’exerce.

La relation qui lie le sujet, le rôle et l’organisation est appelée Empower(figure 11). L’exemple précédent peut alors s’écrire de la manière suivante :

Empower (département_informatique, Pierre, administrateur)

Des permissions sont accordées aux rôles. Les sujets obtiennent alors les permissions accordées aux rôles qu’ils jouent, sachant qu’un sujet peut jouer plusieurs rôles.

Enfin, il est possible de hiérarchiser l’ensemble des rôles définis dans une organisation. Un mécanisme d’héritage permet alors d’accorder toutes les permissions d’un rôle à ses sous rôles. La définition de rôles, l’affectation de rôles aux sujets et l’héritage des permissions à travers la hiérarchie ont pour objectif de structurer l’ensemble des sujets d’une organisation et de simplifier ainsi la gestion de la politique de sécurité.

3.1.4Les objets et les vues

Dans le modèle Or-Bac, l’entité Object représente principalement les entités non actives, c’est-à-dire toutes les ressources de l’organisation, comme les fichiers, les courriers électroniques, les formulaires imprimés, etc. Comme nous venons de le voir, les rôles nous permettent de structurer les sujets et de faciliter la mise à jour de la politique de sécurité. Dans la mesure où il est également nécessaire de structurer les objets et d’ajouter de nouveaux objets au système, une entité comparable au rôle pour les sujets est nécessaire pour les objets. C’est l’entité View. Une vue correspond, comme dans les bases de données relationnelles, à un ensemble d’objets qui satisfont une propriété commune. Prenons l’exemple des fichiers client d’un fournisseur d’accès. Chaque organisation peut choisir la manière dont ces fichiers sont implantés. Ces informations peuvent être gérées par des fichiers papier ou stockées dans une base de données. L’organisation peut ainsi avoir à manipuler des objets de nature diverse. Dans ce cas, une vue « fichier client » est créé. Cette vue regroupe l’ensemble des objets correspondants aux fichiers clients quelle que soit leur nature. Une vue est donc une abstraction d’un ensemble d’objets.

Dans la mesure où les vues caractérisent la manière dont les objets sont utilisés dans l’organisation, nous avons besoin d’une relation qui lie ces trois entités : la relation Use(figure11).

Nous pourrons alors écrire qu’une certaine organisation « FAI » utilise un certain fichier « fichier245.xls » dans la vue « fichier client » :

Use (FAI, fichier245.xls, fichier_client)

Enfin, comme pour les rôles, il est possible de définir des hiérarchies de vues.

3.1.5Les actions et les activités

Les politiques de sécurité spécifient les accès autorisés aux entités passives par des entités actives et régulent les actions effectuées sur le système. Dans le modèle Or-Bac, l’entité Action englobe principalement les actions informatiques comme « lire », « écrire », « envoyer », etc. De la même manière que les rôles et les vues sont des abstractions des sujets et des objets, l’entité Activity représente l’abstraction d’une action.

Ainsi, les rôles associent des sujets qui remplissent les mêmes fonctions, les vues regroupent des objets qui satisfont une propriété commune, et les activités correspondent à des actions qui ont un même objectif. Nous pouvons par exemple définir l’activité « consulter ». L’action « acroread », c’est-à-dire utiliser Acrobat Reader, pourra être considérée par une certaine organisation comme implantant l’activité « consulter ».

Dans la mesure où différentes organisations peuvent considérer qu’une même action est employée pour réaliser différentes activités, la relation Consider (figure 11) sera utilisée pour associer les entités Organization, Action et Activity.

Nous pourrons alors écrire une relation du type :

Consider (département_informatique, acroread, consulter)

Comme pour les rôles et les vues, le modèle Or-Bac offre la possibilité de définir une hiérarchie d’activités.

3.1.6Une politique de sécurité à deux niveaux

Nous venons de voir que les sujets, les actions et les objets sont respectivement abstraits en rôles, en activités et en vues, comme le représente la figure 12. Nous obtenons alors une politique de sécurité à deux niveaux. Le modèle Or-Bac permet ainsi d’établir une politique de sécurité abstraite (rôle, activité, vue) indépendante des choix d’implémentation (sujet, action, objet). Les relations correspondant aux permissions sont :

Is_permitted la relation entre un sujet, une action et un objet : Is_permitted (Subject, Action, Object). De telles règles de sécurité sont dites concrètes.

Permission la relation abstraite entre un rôle, une activité et une vue. L’organisation dans laquelle une permission est valide est aussi indiquée dans cette relation : Permission (Organisation, Role, Activity, View). Cette relation signifie que l’organisation donne la permission à un rôle de réaliser une activité sur une vue

L’objectif dans le modèle Or-Bac est de rédiger la politique de sécurité à l’aide de permissions abstraites. Les permissions concrètes sont alors dérivées des permissions abstraites. La règle de dérivation est la suivante :

Si Permission (Organisation, Role, Activity, View) et

Empower (Organisation, Subject, Role) et

Consider (Organisation, Action, Activity) et

Use (Organisation, Object, View)

Alors Is_permitted (Subject, Action, Object)

Pour illustrer cette règle, considérons l’exemple suivant : l’utilisateur « Jean » désire ouvrir le fichier «fiche_client_21.pdf » à l’aide d’Acrobat Reader. Le contrôle d’accès associé à cette requête correspond à la permission suivante : Is_permitted (Jean, acroread, fiche_client_21.pdf). Cela signifie alors que si nous avons la permission abstraite Permission (département_informatique, administrateur, consulter, fiche_client) et que l’organisation « département informatique » emploie Jean dans le rôle « administrateur », que cette organisation considère l’action « acroread » comme une activité « consulter », et que cette organisation utilise l’objet « fiche_client_21.pdf » dans la vue « fiche_client », alors Jean obtient l’accès demandé.

3.1.7Modélisation Or-Bac d’une politique de sécurité réseau

Pour, construire un modèle de politique de sécurité réseau basé sur Or-Bac, il faut établir des correspondances entre le vocabulaire employé dans Or-bac et celui utilisé pour les entités intervenantes dans un modèle de politique de sécurité réseau. On peut établir sur un modèle d’un réseau local d’entreprise les correspondances suivantes.

Une organisation est assimilée à un ensemble d’hôtes gérés par des composants de sécurité (pare-feu), l’organisation correspond de fait à tout le réseau et ses composants.

Les rôles sont affectés aux hôtes. Un exemple de rôle peut être un serveur DNS ou un firewall. Les activités correspondent aux divers services (application : http, ftp, smtp..) offerts par l’organisation.

Les vues sont utilisées pour structurer et assembler les entités auxquels s’appliquent les différents services réseau. Ainsi dans un réseau, nous définissons une vue comme étant un hôte destinataire du message. Cet hôte est au préalable identifié par son rôle. On peut pour le modèle Or-bac appliqué à un réseau considérer une vue comme un ensemble d’hôtes de destination.

3.1.8Implémentation logiciel de Or-Bac

Les exigences de contrôle d’accès orientées modèle Or-bac ont été transformées en des schémas XML (eXtensible Markup Language - en français: langage de marquage étendu) pour des raisons de potabilité et d’aisance pour la génération des règles génériques de contrôle d’accès.

XML est un langage de balises comme Html. Cependant, il est extensible et évolutif, ce qui signifie que les balises ne sont pas prédéfinies, c’est à l’utilisateur de les introduire selon ses besoins. On spécifie ainsi dans un document « la DTD¹⁰ » ou dans « des schémas¹¹ », la description et les caractéristiques de nos nouvelles balises. Dans notre cas, il s’agit d’introduire et de définir les balises correspondant aux différentes entités du modèle Or-Bac et leurs liens.

Le schéma Or-Bac
Les schémas XML sont des documents qui servent à définir et à valider le contenu et la structure des données XML. Un schéma XML décrit certains types de données XML à l'aide du langage de définition de schéma XML (XSD, XML Schema Definition). Les éléments du schéma (éléments, attributs, types et groupes) servent à définir une structure et un contenu de données valides ainsi que des relations entre certains types de données XML. Les schémas XML peuvent également fournir des valeurs par défaut pour les attributs et les éléments.

Le modèle Or-Bac est spécifié par un schéma XML tel que présenté dans la figure 13. Dorénavant, pour définir une politique de sécurité réseau Or-Bac, on crée des documents au format XML, qui suivent les recommandations du modèle de référence.

Figure 13: le modèle Or-Bac
Voici une instance du schéma Or-Bac au format XML, l’exemple complet est en annexe.









RelevantEntity definitions-->

RelevantRole definitions-->





























111.222.1.10

24



















111.222.1.17

24

 « organization » correspond au réseau de l’entreprise, les rôles (server FTP, serveur Mail, etc..) sont définis entre les balises relevantRole, les sous-rôles (qui vont permettre l’héritage des permissions) entre les balises subRole. Les activités (fpt, dns , ssh) sont définies sous les balises relevantActivity et les vues sous relevantVue. Pour une instance du schèma Or-bac, il n’est pas nécessaire d’utiliser toutes les balises. Seules celles dont on a besoin sont utilisées.

Le modèle Or-Bac offre la possibilité de définir des zones d’inclusion et d’exclusion pour un même réseau, cela signifie que plusieurs entités dont les rôles sont différents (donc des droits différents) peuvent se trouver sur le même réseau. La définition de la politique de sécurité doit néanmoins être définie en fonction des rôles et non du réseau, mais définir des zones d’inclusion et d’exclusion induit forcément la gestion des exceptions dans l’écriture des règles de filtrage.  C’est ce que nous allons voir dans la section suivante.