Spécification des règles de sécurité

Du point de vue formel, une règle de sécurité est une formule modale dont les différentes clauses ne sont pas toutes des formules modales (par exemple : rÆPq). Elle reflète la manière dont l’état de sécurité est en relation avec les différentes permissions, obligations, interdictions et recommandations qui existent dans le système.

Dans le langage proposé, les règles de sécurité prennent essentiellement la forme suivante : "s"a"o"r"a"v"c

P(org, r, a, v, c) Ÿ RdO(org, s, r) Ÿ VdO(org, o, v) Ÿ AdO(org, a, a) Ÿ

CdO(org, s, a, o, c) Æ Est_permis(s, a, o) :

Si l’organisation org, dans le contexte c, accorde la permission au rôle r de réaliser l’activité a sur la vue v, si org habilite le sujet s dans le rôle r, si org utilise l’objet o dans la vue v, si org considère l’action a comme faisant partie de l’activité a et si au sein org le contexte c est vrai entre s, a et o, alors le sujet s a la permission de réaliser l’action a sur l’objet o.

Cette manière de faire couvre parfaitement les différents cas d’accès qui se présentent dans le domaine médical. Néanmoins, dans la sphère sociale, les règles de sécurité sont un peu différentes. En effet, Le tableau 5.1 rappelle les diff.érents accès possibles :

Rôle {Type} Types d’accès autorisés

P e r s o n n e n o n -inscrite

{revendiqué}

Demand e de renseignement ; abonnement ou désabonnement ; lecture actualités ; dépôt de commentaires ; informations : techniques et informations d’ordre général sur les partenaires et le fonctionnement de Net-entreprises ; accès au plan du site.

Personne inscrite Informations et alertes personnalisées ; modification de ses propres informations d’inscription ou d’authentification.

Dirigeant

{ a t t r i b u é e t a n o n y m e p a r défaut} ;{revendiqué pour être nominatif}

Vision d’ensemble sur l’adhésion de son établissement à Net-entreprises : visualisation de l’historique des modifications ; consultation des personnes autorisées et de leurs droits ; réinitialisation de l’administrateur ; radiation de l’établissement ; limitation du nombre d’administrateurs ; interdiction (ou levée d’interdiction) de toute nouvelle inscription pour son établissement.

Mandataire social {revendiqué}

Radiation de son entreprise ; limitation du nombre d’administrateurs ; interdiction (ou levée d’interdiction) de toute inscription pour son entreprise.

Administrateur {revendiqué}

Inscription ; gestion des personnes autorisées et de leurs droits d’accès aux déclarations : nomination ou révocation de ces personnes, consultation ou modification de leurs droits, définition de leurs périmètres d’habilitation ; résiliation de son inscription.

Personne autorisée {attribué}

Accès (préparation, validation ou visualisation) aux déclarations ou aux paiements

Tableau 5.1 : Droits associés à chaque rôle de notre scénario social.

Ce récapitulatif nous montre de nouvelles formes de règles, que nous n’avons pas analysé précédemment. Considérons la règle la plus originale dans les accès aux services de Net-entreprises : “un administrateur désigne une personne autorisée à effectuer des types de déclarations selon une certaine modalité pour le compte d’un certain établissement³⁰”.

Cette règle peut être décomposée en deux autres règles :

- une première règle donnant à l’administrateur le droit de désigner (ou révoquer) des personnes autorisées, c’est-à-dire d’affecter des utilisateurs au rôle personne autorisé ; cette règles s’appelle règle de délégation (ou d’administration) ;

- une deuxième règle donnant à la personne autorisée le droit d’effectuer des déclarations pour le compte d’un certain établissement.

Nous proposons de représenter les règles de délégation sous la forme “Permission (organisation, RdO, AdO, VdO, CdO)”, avec :

- organisation est la structure qui décide de déléguer, c’est-à-dire l’établissement déclarant ; - RdO est la fonction qui a le pouvoir de désigner, nommer, ou révoquer des personnes

habilitées, dans notre cas, c’est le rôle administrateur dans l’établissement déclarant ; - AdO correspond à l’activité nomination dans l’établissement déclarant (association d’un

utilisateur à un rôle) ;

- CdO est le processus suivi par l’administrateur pour effectuer cette nomination, notons le par exemple “inscription de nouvelles personnes autorisées” ;

- VdO est le “schéma de la règle de délégation” ; les objets appartenant à cette vue sont des règles.

Récapitulons, la règle de délégation (qui autorise l’administrateur à affecter des nominations) a la forme suivante : “Permission (établissement déclarant, administrateur, désigner ou révoquer, schéma de la règle de délégation, inscription de nouvelles personnes autorisées)”.

En insérant un objet dans la vue “schéma de la règle de délégation”, l’administrateur désigne une personne autorisée pour effectuer des types de déclarations, pour une certaine organisation, selon une certaine modalité. Par conséquent, cette vue particulière, notée “V_schéma-règle-délégation”, possède les attributs³¹ suivants :

• org : l’organisation dans laquelle le rôle concerné sera joué, c’est-à-dire l’établissement déclaré ; " schéma-délégation_i Œ V_schéma-règle-délégation, org(schéma-délégation_i) = étab-déclaré_a) ;

• rôle : le rôle délégué, c’est-à-dire “personne autorisée” ; Rôle(schéma-délégation_i) = personne-autorisée ;

• sujet : le sujet (Claire, Philippe, …) bénéficiant de la délégation, c’est donc l’utilisateur qui sera désigné (par l’administrateur) comme personne autorisée ; par exemple, sujet(schéma-délégation_i) = Philippe ;

• activité : l’activité correspondant à l’action que la personne autorisée (Philippe ) peut effectuer, par exemple activité(schéma-délégationi) = envoyer-formulaire-déclaration ;

• vue : la vue déléguée, c’est-à-dire la vue que la personne autorisée va manipuler ; il peut s’agir de types de déclarations ou types de titres de paiement, par exemple, les déclarations URSSAF, DUCS, CSSS, DADS-TDS : vue(schéma-délégationi) = déclarations-URSSAF, Vue(schéma-délégation_j) = titre-paiement-DUCS, etc.

30 Rappelons que l’établissement déclarant et l’établissement déclaré ne sont pas nécessairement les mêmes, en l’occurrence dans le cas d’un tiers déclarant.

31 Bien évidemment, les attributs de cette vue sont instanciés à chaque fois que l’administrateur désigne ou révoque une personne autorisée, autrement dit à chaque fois qu’il insère un objet dans cette vue.

• contexte : le contexte (ou processus, ou cadre) dans lequel la déclaration ou le paiement sera effectué, par exemple, contexte(schéma-délégation_j) = processus-de-paiement, contexte(schéma-délégationj) = processus-de-déclaration, etc.

Pour résumer, les deux règles dont nous avons besoin sont : Première règle :

- Permission (établissement déclarant, administrateur, désigner ou révoquer, schéma de la règle de délégation, inscription de nouvelles personnes autorisées) ;

Deuxième règle qui spécifie la forme logique de la vue “schéma de la règle de délégation”.

Nous la définissons de la manière suivante :

- " schéma-délégation_iŒ V_schéma-règle-délégation VdO(org, schéma-délégation_i, schéma-règle-délégation) Æ RdO(étab-déclaré_a, Philippe, Personne-autorisée) Ÿ

Permission(étab-déclaré_a, P e r s o n n e - a u t o r i s é e, envoyer-formulaire-déclaration, déclarations-URSSAF, processus-de-déclaration)

Même si le principe reste toujours le même, la manière selon laquelle ce type de règles peut être exprimé n’est pas unique. Elle dépend étroitement du fonctionnement et des objectifs³² de l’organisation (entreprise) étudiée. À cet égard, il faut d’abord avoir des réponses aux questions suivantes (qui dépendent de l’organisation) :

- Est ce que l’on considère les sous-rôles³³ du rôle personne autorisée ou pas ?

- Si oui, est ce que les privilèges associés aux sous-rôles sont stables (toujours les mêmes)?

Dans ce cas, il serait préférable de décomposer la règle ci-dessus en deux parties : dans une première étape, il faut associer les permissions aux rôles, tandis que dans la deuxième étape, on affecte les utilisateurs aux rôles (les sous-rôles du rôle personnes autorisé) ; sinon, il serait également possible d’associer directement des permissions aux utilisateurs.

- Est ce que l’on considère que la vue “déclaration” et différente de la vue “paiement”, ou à l’inverse, on considère une vue “type de déclaration” mais avec deux modalités différentes : “déclarer” et “payer”.

Cette analyse nous conduit à discuter le problème d’administration des droits, sujet intéressant qui a fait l’objet d’études récentes, et qui est souvent associé à un modèle de contrôle d’accès. En l’occurrence, les modèles ARBAC97 « Administration Role-Based Acces Control » [Sandhu & Bhaidipati1997 ; Sandhu & Bhaidipati1999], ARBAC99 [Sandhu &

Munawer 1999] ainsi que ARBAC02 [Oh & Sandhu 2002] ont été associés au modèle RBAC, tandis que le modèle AdOr-BAC (Administration Model for Or-BAC) a été associé au modèle Or-BAC [Cuppens & Miège 2003a]. Les modèles d’administration associés à R B A C considèrent les associations : URA (User Role Administration), PRA (Permission Role Administration) tandis que AdOr-BAC redéfinit ces deux associations et ajoute l’association UPA « User Permission Administration ». Analysons, à travers des exemples adaptés à notre scénario social, comment AdOr-BAC présente ces trois associations :

URA sert à affecter des utilisateurs à des rôles. Modéliser des règles du type

“l’administrateur est autorisé à affecter un utilisateur au rôle Personne Autorisée (PA) dans l’établissement déclarée étab-déclaré_a”, nécessite la création des vues URA et URA-PA-

32 Un objectif peut par exemple être : une définition séparée des personnes autorisées, puis de leurs périmètres d’habilitations, ou à l’inverse, définir ces deux tâches en même temps.

33 Nous avons déjà expliqué dans la section 3.2.3.2.1 que les sous-rôles du rôle personne autorisée peuvent être : personne autorisée à effectuer les déclarations, personne autorisée à effectuer des paiements, personne autorisée à consulter les déclarations etc.

déclaré_a. URA possède trois attributs : sujet (sujet concerné par l’affectation), rôle (auquel le sujet sera affecté) et org (l’organisation dans laquelle le sujet sera affecté). URA-PA- étab-déclaré_a. est définie comme suit :

- " ura Œ URA VdO(org, ura, URA-PA- étab-déclaré_a) Æ RdO(org(ura), sujet(ura), rôle(ura)) ; avec : “org(ura) = étab-déclaré_a” et “rôle(ura) = personne autorisée” (ou l’un de ses sous-rôles).

La règle autorisant l’administrateur à gérer les rôles des utilisateurs ressemble à celle donnée dans l’exemple précédent (Permission (établissement-déclarant_b, administrateur, gestion, URA-PA- étab-déclaré_a, Processus-habilitation-PA)).

PRA sert à associer des permissions à des rôles. L’association PRA a cinq attributs : initiateur (organisation où la permission s’applique), rôle (rôle qui bénéficie de la délégation), privilège (l’activité déléguée), cible (vue concernée par la délégation) et contexte (dans lequel la règle s’applique). Donner une nouvelle permission à un rôle correspond en fait, à créer un nouvel objet qui se conforme à l’association PRA. Le lien entre ces objets et la relation

“Permission” est modélisé par : - "org "contexte,

VdO(org, pra, PRA) Æ Permission (initiateur(pra), rôle(pra), privilège(pra), cible(pra), contexte(pra)).

Ainsi, la règle où l’administrateur est autorisé à affecter la permission “consulter des déclarations” au rôle “personne-autorisée” peut être modélisée comme suit :

- (Permission (établissement-déclarant_b, administrateur, gestion, PRA-PA- étab-déclaré_a, Processus-habilitation-PA))

La vue PRA-PA- étab-déclaré_a est définie par :

- "pra, VdO(établissement-déclarant_b, pra, PRA-PA- étab-déclaré_a,) ´ VdO(établissement-déclarant_b, pra, PRA) Ÿ

initiateur(pra) = étab-déclaré_a, Ÿ rôle(pra) = personne-autorisée Ÿ privilège (pra) = consultation Ÿ cible(pra) = déclaration Ÿ

contexte(pra) = processus-vérification.

UPA sert à affecter des permissions à des utilisateurs. Cuppens et Miège distinguent deux cas différents nommés : UPA1 et UPA2. UPA1 donne à un utilisateur le droit d’associer une permission à un autre utilisateur pour réaliser une certaine tâche sur un certain objet, tandis que UPA2 donne à un utilisateur le droit d’associer une permission à un autre utilisateur pour réaliser une certaine activité sur une vue. Dans le cadre de ce mémoire, nous donnons seulement un exemple de UPA2. Celle-ci contient cinq attributs : initiateur (organisation dans laquelle la permission s’applique), sujet (sujet qui bénéficie de la délégation), privilège (l’action déléguée), cible (l’objet concernée par la délégation) et contexte (dans lequel la permission s’applique). Afin d’exprimer la règle “le dirigeant de l’entreprise déclarante peut associer, à l’administrateur, le droit de mettre à jour la table des personnes autorisées”, nous devons, tout d’abord, définir la vue MJTPA (pour Mise à jour de la Table des Personnes Autorisée) qui est une sous-vue de UPA2 :

- "upa, VdO(établissement-déclarant_b, upa, MJTPA) ´ VdO(établissement-déclarant_b, upa, UPA2) Ÿ

RdO(étab-déclaré_a, sujet(upa), Personne-autorisée) Ÿ

privilège(upa) = consultation Ÿ

sous-vue(étab-déclaré_a, cible(upa), table-personnes-autorisée).

Notons tout de même que la vision présentée dans [Cuppens & Miège 2003a] considère l’attribut initiateur comme l’organisation qui décide de la délégation (l’établissement déclarant) tandis que dans notre vision, il s’agit de l’organisation dans laquelle la permission d’applique (l’établissement déclaré).

Cette section montre que le langage proposé permet de couvrir la richesse des SICSS, notamment vis-à-vis de la représentation des permissions, des interdictions, des obligations et des recommandations. Néanmoins, comme tout langage basé sur la logique déontique, des questions comme l’interprétation sémantique des formules (modèles de Kripke) s’imposent fréquemment.

À cet égard, des techniques de déduction automatique, fondées par exemple sur la méthode des tableaux [Fitting 1993], ont été proposées. Entre autres, ils permettent de vérifier si, partant d’un état sûr (qui satisfait les objectifs de sécurité), et en appliquant les règles de sécurité, on retrouve un état (une situation) ou certains objectifs de sécurité sont violés (état non sûr). Un exemple de l’application de la méthode des tableaux dans le cadre des politiques de sécurité est donné dans [Ortalo 1998].

Afin de détecter et résoudre les conflits, on peut également utiliser la logique possibiliste.

Rappelons qu’un conflit peut être défini comme une situation dans laquelle un utilisateur aurait simultanément la permission et l’interdiction, ou l’obligation et l’interdiction, d’effectuer une action sur un objet (section 4.4.1.2, page 112). Par exemple, l’application d’un enchaînement de règles permet de déduire qu’un médecin ne traitant pas un patient P n’a pas le droit de consulter son dossier médical, alors qu’un autre enchaînement de règles permet de déduire qu’en cas d’urgence, n’importe quel médecin peut lire le dossier médical d’un patient. Ces deux résultats amènent à un conflit dans le cas où un médecin n’ayant jamais traité un patient veut lire son dossier alors qu’il y a urgence. Nos partenaires de MP6 proposent d’utiliser la logique possibiliste [Benferhat et al. 2003] pour résoudre ce type de conflits en associant, aux formules de la base, des coefficients de confiance allant de 0 à 1. Ainsi, dans notre exemple, si l’on considère l’urgence comme étant prioritaire, on donne un coefficient x₁ pour la première règle, et x₂ pour la deuxième, avec x₁< x₂. La comparaison des coefficients permet de ne retenir que la deuxième règle.

Chapitre 6. Application d’Or-BAC aux SICSS et mise en oeuvre

Préambule

Le modèle Or-BAC a été associé, d’une part, à une spécification UML pouvant guider le processus de mise en œuvre (chapitre 4), et d’autre part à un formalisme logique (chapitre 5) pouvant aider à raisonner sur les permissions, obligations, interdiction et recommandation ; à détecter et résoudre les conflits, etc.

Le présent chapitre propose une démarche progressive fondée sur l’utilisation d’UML [Muller & Gaertner 2000 ; Booch et al. 1999] pour la définition d’une politique de sécurité -fondée sur Or-BAC - d’un système ou d’une organisation.

Cette démarche - qui peut être appliquée à différentes organisations - tient compte des aspects conceptuels, statiques et dynamiques de la politique de sécurité. Nous allons ainsi montrer comment utiliser les différents diagrammes UML pour : représenter les interactions entre les utilisateurs et le système ; spécifier les concepts de permission, interdiction ou obligation ; représenter des processus ; détailler les types de relations ; etc.

La deuxième partie présente l’analyse conceptuelle, organisationnelle et opérationnelle que nous avons suivi pour mettre en œuvre un logiciel de contrôle d’accès pour un centre de soins dentaires contenant plusieurs organisations (cabinets, services, etc.). Seuls les aspects décrivant le passage entre la politique de sécurité (fondée sur Or-BAC) et le contrôle d’accès seront abordés en détail. L’analyse fonctionnelle du logiciel est donnée en annexe D.