Le contexte

D’une manière générale, le contexte peut être défini comme toute information qui caractérise la situation d’une entité ou qui spécifie les circonstances concrètes dans lesquelles les organisations accordent des permissions à des rôles pour réaliser des activités sur des vues. En l’occurrence : qui peut déléguer ? Quand l’utilisateur a-t-il le droit d’accéder à une information ? D’où l’accès est-il possible ? Comment, où et pour quelles raisons, les informations sont-elles disponibles ?

Le contexte est ainsi l’une des notions utilisées par la politique présentée pour mieux respecter le principe du moindre privilège²⁵. Dans le domaine médical, le contexte permettra d’exprimer des notions comme : l’urgence, les processus habituels, l’exclusion mutuelle, les attributs temporels, etc. En effet, le contexte peut être vu selon différentes facettes, selon qu’il est relié aux sujets, aux objets ou à l’utilisation elle-même. Une étude détaillée concernant l’utilisation du contexte dans les applications médicales peut être trouvée dans [Abou el Kalam

& Deswarte 2002] ainsi que dans la norme européenne [CEN 1999].

4.2.5.1 Contexte et contraintes du rôle

En général, le contexte du rôle précise des valeurs que doivent prendre certaines variables contextuelles pour autoriser, interdire, obliger ou recommander à un utilisateur de jouer un rôle donné. Par exemple :

- instant d’accès : le rôle médecin de salle est valide pendant les heures normales de travail tandis que le rôle médecin de garde est valide la nuit ;

- cardinalité : c’est une contrainte sur le nombre maximal ou minimal d’utilisateurs autorisés à jouer un certain rôle, que ce soit directement ou indirectement (à travers l’héritage) ;

25 Ce principe consiste à ne donner accès aux utilisateurs autorisés qu’aux seules ressources dont ils ont besoin pour accomplir leurs tâches, et ce, seulement pendant la durée de ces tâches.

Activité Organisation

Action

AdO

0..n 0..n

Id_Organisation Id_Activité

…

Purpan:Organisation Lecture:Activité

Read:Action

Rangueil:Organisation Lecture: Activité

LectureDansRangueil:VdO Select:Action

LectureDansPurpan:VdO

- exclusion mutuelle : cette contrainte peut être statique ou dynamique ; une exclusion mutuelle statique entre deux rôles signifie qu’un utilisateur ne peut jamais jouer ces deux rôles, par exemple, dans le même établissement, être personnel soignant et comptable ; une exclusion mutuelle dynamique entre deux rôles signifie que l’utilisateur ne peut pas jouer les deux rôles simultanément, par exemple, médecin à l’hôpital et médecin travaillant pour une société d’assurance.

4.2.5.2 Contexte d’objet

Comme les rôles, les objets (ou d’une manière générale les vues) ont des attributs contextuels spécifiques. Par exemple :

- la durée de conservation des données : données de neurologie (70 ans), maladies héréditaires (illimitée), etc. ;

- le lieu : les dossiers de spécialités de chacune des unités sont situés et gérés localement dans les ordinateurs de cette unité ; dans certains cas, l’accès à ce type de dossier ne peut se faire que localement ; de manière générale, certaines organisations des SICSS associent à leurs objets (données, ressources) les emplacements où ils sont situés et gérés.

4.2.5.3 Attributs d’utilisateurs

Dans la pratique, certains attributs des utilisateurs peuvent être utilisés pour obliger ou recommander l’exécution d’une certaine action, interdire ou accorder des autorisations spécifiques ou des droits temporaires. Nous pouvons citer par exemple :

- l’affiliation à un corps de santé régional, national, ou international ;

- l’expérience dans la pratique de certains types particuliers de soins comme l’acupuncture ; etc.

4.2.5.4 Contexte de l’utilisation

Une entité peut être concrète ou abstraite. L’ensemble des entités abstraites de la politique proposée peut lui-même être partitionné en deux niveaux logiques : un premier niveau contenant les rôles, les vues et les activités, et un deuxième niveau schématisant les coalitions (ou les collaborations). Les organisations en font partie. En réalité, les organisations (les équipes de soins, par exemple) collaborent dans des processus spécifiques.

Le contexte d’utilisation est un concept innovant qui utilise la notion de processus pour gérer les accès normaux, et la notion d’objectif d’utilisation pour supporter les exceptions, avec plus de responsabilité. Le but est de réaliser un bon compromis entre le respect du principe du moindre privilège et la flexibilité du contrôle d’accès. Tout accès doit donc être inscrit soit dans un processus, soit dans une exception déclarant un objectif spécifique de l’utilisation prétendue. Les autorisations finales seront ainsi différentes selon que l’utilisateur aura déclaré tel ou tel objectif d’utilisation.

4.2.5.4.1 Processus

Dans le cas d’un processus de soins, le consentement (explicite ou implicite) du patient est recueilli, et l’activité de soins est enregistrée dans le système par une personne habilitée par exemple, le médecin traitant. Le processus est ainsi identifié par un patient, un motif et des organisations qui collaborent pour traiter le patient.

En outre, dans le domaine médical, différents protocoles de processus (processus-types) peuvent être énumérés. Il suffit qu’une personne habilitée instancie un de ces processus, et les

accès s’inscriront dans ce cadre. À titre d’exemple, le processus “demande d’avis neurochirurgical en urgence” peut être constitué des étapes suivantes :

- arrivée du patient aux urgences où il est accueilli par l’infirmière ; - examen clinique par le médecin urgentiste ;

- réalisation d’un scanner par un radiologue et un manipulateur radio ; - réalisation des examens de biologie ;

- prise en compte des résultats du scanner et demande d’avis neurochirurgical ; - le radiologue donne son avis à l’urgentiste ;

- le biologiste donne son avis sur les examens de biologie ;

- le neurochirurgien de l’hôpital distant donne son avis à l’urgentiste ; - le neurochirurgien de l’hôpital distant accepte le transfert du patient ; - sortie administrative du patient ;

- préparation de l’accueil du patient dans le service de neurochirurgie ; - accueil du patient dans le service de neurochirurgie ;

- visite au patient et organisation de la prise en charge ; - intervention chirurgicale en neurochirurgie.

Par analogie, dans Net-entreprises, système représentatif du secteur social, nous trouvons des processus bien cadrés comme le processus d’inscription ou le processus d’accès aux services sécurisés. Ces processus ont été partiellement décrits dans la section 3.2.2.1.3, et sont donnés plus en détail dans [GIP 2002b].

4.2.5.4.2 Exception

Dans un cas d’exception, c’est-à-dire pour tout accès au système en dehors d’un processus habituel, l’utilisateur doit déclarer un objectif d’utilisation. Dans le domaine de la santé, ceci correspond à des cas non prévus dans les processus de soins, où le consentement du patient est souvent impossible. Le but est de favoriser la vie des patients et de ne pas faire obstacle au travail du personnel soignant, tout en engageant la responsabilité de l’utilisateur. De même, dans la sphère sociale, nous pouvons énumérer des cas d’exception tels que :

- à l’échéance (urgence), les personnes autorisées peuvent forcer le système pour préparer ou valider les déclarations ou les paiements via les services de Net-entreprises ;

- lors de la sélection des déclarations en mode standard, le système propose à la personne autorisée une liste de déclarations correspondant au profil de son établissement ; toutefois, cette liste n’est pas limitative et la personne autorisée peut forcer certains paramètres ; - il doit être possible de forcer le niveau²⁶ de sécurité pour certains services et dans des

conditions très particulières.

Afin de satisfaire les objectifs cités précédemment (flexibilité et sécurité), nous suggérons que le système effectue deux types de contrôles dans le cas d’une exception :

- un contrôle a priori : les règles de sécurité doivent spécifier quel utilisateur (ou rôle) a le droit de déclarer quel objectif, et dans quelles conditions ; par exemple si le médecin est absent (grève, force majeure), tout professionnel soignant peut déclarer l’objectif

“urgence non habituelle” et accéder au dossier médical du patient ; un autre exemple est

26 Les accès à Net-entreprises sont paramétrés par trois niveaux de sécurité. Si l’utilisateur ne possède pas le niveau requis pour un service, l’accès lui est refusé, sauf dans le cas d’exception que nous décrivons.

celui d’un médecin qui a traité autrefois un patient et qui souhaite ré-accéder à son dossier en spécifiant comme objectif révision du diagnostic ;

- un contrôle a posteriori : pour plus de flexibilité, le système peut autoriser certains accès, avec un ensemble minimal de vérifications (contrôle a priori) ; pour renforcer la sécurité, nous proposons des contrôles supplémentaires, qui seront réalisés a posteriori, notamment à travers les fonctionnalités d’audit et éventuellement par des notifications automatiques des patients ou des médecins traitants ; l’analyse des enregistrements d’audit permet de vérifier a posteriori le bien fondé des décisions prises (par exemple, le caractère d’urgence non habituel) ; à cet égard, notre démarche spécifie ce type de contrôle à l’intérieur de la politique de sécurité, au même titre que les contrôles a priori.

Notons que certaines contraintes contextuelles décrites dans ce mémoire, notamment celles sur les rôles, peuvent être vues comme analogues aux contraintes d’intégrité dans le domaine des bases de données [Godfrey et al. 1998]. Toutefois, les contraintes d’intégrité sont des obligations qui valident les opérations après leurs exécutions (vérification en aval), alors que le contexte que nous décrivons (sauf le contexte d’utilisation) est vérifié avant d’autoriser ou non l’accès (vérification en amont).

Les concepts de base que nous venons de présenter sont des briques nécessaires et suffisantes pour construire Or-BAC. Dans la section suivante, nous montrons comment les assembler et les relier pour représenter la politique de sécurité à l’aide de ce modèle.