2.7.1. Définition de TMAC
Le modèle TMAC (pour TeaM-based Access Control en anglais) a été formulé pour la première fois en 1997 par Thomas [Thomas 1997 ; Wang 1999]. Le but était alors de fournir un contrôle d’accès pour les systèmes ayant des activités de collaboration. À cet égard, l’entité de base, l’équipe, est une abstraction qui encapsule un ensemble d’utilisateurs, qui ont des rôles différents et qui collaborent dans le but d’accomplir une tâche ou d’atteindre un objectif commun. D’une part, les utilisateurs appartenant à une équipe donnée devront avoir accès à l’ensemble des ressources utilisées par l’équipe et d’autre part, les permissions d’un utilisateur devront être dérivées des permissions accordées aux rôles qu’il joue.
Le concept TMAC distingue l’attribution et l’activation des permissions. Les permissions attribuées sont, par exemple, celles associées à un utilisateur lorsqu’il choisit un rôle au moment de la connexion ; les permissions activées sont celles qui dépendent des variables environnementales (lieu, temps, etc.), elles peuvent donc changer selon le contexte. Le pouvoir d’intégrer les informations contextuelles, lors de la décision d’accès, permet au modèle TMAC d’être flexible et d’exprimer des politiques d’accès pouvant fournir des permissions plus fines que celles de RBAC.
Selon TMAC, le contexte de collaboration d’une équipe donnée doit tenir compte de deux types de contexte :
- contexte utilisateur : les utilisateurs qui forment l’équipe à un moment donné ; - contexte objet : les instances d’objets que l’équipe utilise pour accomplir sa tâche.
Dans TMAC [Thomas 1997], une équipe t est définie par : - TU, ses membres ;
- TR, l’ensemble des rôles que les membres de l’équipe peuvent jouer (TR Õ R), où R désigne l’ensemble des rôles présents dans le système d’information ;
- h Õ TR, un rôle particulier nommé “responsable de l’équipe” ; - OT, un ensemble d’objets associés à l’équipe ;
- TP, un ensemble de permissions associées à l’équipe (TP Õ TR ¥ OT).
- UC, un contexte-utilisateur (UC Õ TR ¥ TU) ;
- OC, un contexte-objet (OC Õ OT ¥ O), où O désigne l’ensemble des objets.
La figure 2.5 donne une description graphique des concepts de TMAC tels qu’ils ont été définis dans [Thomas 1997].
Figure 2.5 : Illustration des concepts de TMAC.
Le travail décrit dans [Thomas 1997] reste une introduction innovante de la notion d’équipe dans la formulation des politiques de sécurité. En effet, dans TMAC, l’appartenance d’un utilisateur à une équipe donnée lui confère le droit d’accéder aux ressources associées à cette équipe. Ainsi, les permissions d’un utilisateur dépendent non seulement, du ou des rôles qu’il joue à un moment donné, mais aussi de l’activité courante de l’équipe à laquelle il appartient.
Dans le domaine médical, par exemple, un médecin n’a le droit de prescrire des médicaments que pour les patients qu’il traite (le simple fait d’être médecin ne lui donne pas le droit de prescrire des médicaments pour tous les patients). TMAC peut exprimer ce besoin dans la mesure où elle voit un médecin comme un membre d’une ou plusieurs équipes. Néanmoins, Thomas [Thomas 1997] n’a pas spécifié la façon selon laquelle les règles de sécurité seront représentées, ni comment les permissions seront dérivées.
2.7.2. C-TMAC : Context-TMAC
C-TMAC (pour Context-TeaM Based Access Control en anglais) [Georgiadis et al. 2001] est une amélioration de TMAC qui fournit, de manière explicite, les règles d’activation des permissions selon le contexte. C-TMAC utilise un mélange de RBAC et TMAC, et consiste en cinq entités : utilisateurs, rôles, permissions, équipes et contextes.
Durant une session, les permissions d’un utilisateur représentent l’union des permissions de tous les rôles qu’il a activé. Par ailleurs, dans le contexte sont incluses des informations concernant l’activité de son équipe, ainsi que des informations contextuelles comme le temps.
Très proche de la spécification de RBAC, le modèle C-TMAC définit les éléments suivants : - U, R, P, S, T, C désignent respectivement l’ensemble des utilisateurs, rôles, permissions,
sessions, équipes et contextes ;
- PRS Õ P ¥ R est une relation plusieurs à plusieurs associant les permissions aux rôles ; - URS Õ U ¥ R est une relation plusieurs à plusieurs associant les utilisateurs aux rôles ; - CTS Õ C ¥ T est une relation plusieurs à plusieurs associant les contextes aux équipes ; - UTS Õ U ¥ T est une relation plusieurs à plusieurs associant les utilisateurs aux équipes ; - Session-User : SÆU, une fonction associant chaque session si à un utilisateur User(si) ; - Session-Role : SÆ2R, une fonction associant chaque session si à un ensemble de rôles
Roles(si), avec : Rôles(si) Õ {r | (User(si), r) Œ URS} ;
- Session-Team : SÆ2T, une fonction associant chaque session si à un ensemble d’équipes Team(si) avec : Team(si) Õ {t | (User(si), t) Œ UTS} ;
Rôles de l’équipe Types d’objets
Instances d’objets
Contexte-Utilisateur
Membres de l’équipe
Permissions de l’équipe
Contexte de collaboration
Contexte-Objet
- Team-User : TÆ2U, une fonction associant chaque équipe ti à un ensemble d’utilisateurs User(ti), avec : User(ti) Õ {u | (u, ti) Œ UTS} Ÿ$sj : user(sj)=u} ;
- Team-Role : TÆ2R, une fonction associant chaque équipe ti à un ensemble de rôles
†
Role(ti)Õ{r| (user(ti),r)ŒURS} ; les permissions de l’équipe ti sont notées permission-rôle-équipe. Elles sont déduites à partir de la formule « ⊕r Œ roles(ti) = {p | (p,r) Œ PRS} ». Celle-ci désigne la combinaison (représentée dans la formule par l’opérateur ⊕) des permissions de tous les rôles des utilisateurs appartenant à l’équipe.
L’ensemble permission-rôle-équipe dépend de la notion de combinaison. Selon C-TMAC, une combinaison correspond à l’un des trois cas suivants :
- si la combinaison est une agrégation, permission-rôle-équipe est l’union des permissions des rôles des utilisateurs appartenant à l’équipe ;
- si la combinaison est un maximum (resp. minimum) : permission-rôle-équipe est égal à l’ensemble maximal (resp. minimal) des permissions des membres de l’équipe ;
- dans d’autres cas non spécifiés dans [Georgiadis et al. 2001], la combinaison peut dépendre de la structure courante de l’équipe.
Selon C-TMAC, la dérivation des permissions (et donc l’accès aux ressources) suit la procédure suivante :
Après son identification et son authentification, l’utilisateur sélectionne un sous-ensemble de rôles et d’équipes auxquels il a droit. L’ensemble des permissions de l’utilisateur session) est combiné avec l’ensemble des permissions de l’équipe (permission-rôle-équipe) comme indiqué dans les deux étapes ci-dessous :
Étape 1 : considérons un utilisateur ayant activé un sous-ensemble de rôles et participant à un sous-ensemble d’équipes. Initialement, les permissions de ses rôles sont dérivées à partir des formules suivantes :
permission-rôle = permission-rôle-session ⊕ permission-rôle-équipe
Étape 2 : les permissions finales sont dérivées à partir du contexte de l’équipe et des permissions des rôles. C-TMAC utilise ainsi l’opérateur de filtrage “
ƒ
” pour restreindre les permissions acquises à travers les rôles joués :permission-contexte = permission-rôle ƒ contexte-équipe
Afin de rendre le contrôle d’accès dynamique, cette deuxième règle déduit l’ensemble final des permissions d’un utilisateur, en utilisant le contexte courant de son équipe comme “filtre”.
Cette manière de faire permet d’extraire des sous-ensembles de permission-rôle en s’appuyant sur les valeurs des variables contextuelles de l’équipe : le lieu, le temps, le patient traité, etc.
Étudions le fonctionnement de C-TMAC dans un contexte médical, environnement où plusieurs équipes peuvent être impliquées dans des processus dynamiques composés de plusieurs tâches. Soit l’exemple d’un patient traité dans le service de médecine générale. Suite à une attaque cardiaque, il est transféré d’urgence à l’unité de soins cardiologiques. La tâche de l’équipe de cardiologie (traiter les patients cardiaques) est exécutée durant un intervalle de temps donné et dans un endroit spécifique (l’unité de cardiologie). Les variables contextuelles sont ainsi, le temps, le lieu et le patient. La procédure est décrite dans la figure ci-dessous.
Figure 2.6 : Activation des permissions selon C-TMAC.
Dans cet exemple, on suppose que :
- la base de données contient la table Patient(patientID, Champ1, Champ2, Champ3, Champ4) ;
- les paramètres du contexte, PatientID, temps et lieu ;
- les permissions associées aux rôles médecin, cadre-infirmière et infirmière sont :
• Permissions(médecin) : SELECT Champ1, Champ2, Champ3 FROM Patient,
• Privilèges(cadre-infirmière) : SELECT Champ1, Champ3, Champ4 FROM Patient,
• Privilèges(infirmière) : SELECT Champ1, Champ4 FROM Patient.
Dans l’exemple, on suppose qu’il existe des équipes assurant le service des urgences : Eq-Ur localisées dans la salle (UR1) ou dans la salle (UR3), ainsi qu’une équipe de soins primaires (GN2). Le contexte associé à Eq-Ur est :
PatientID IN : (200, 351) AND temps IN [10h-12h] AND lieu IN (UR1, UR3).
Supposons maintenant que Mary et Helen ont commencé leur session s1 et s2 et qu’elles activent leurs rôles “cadre-infirmière” et “infirmière” respectivement au sein de Eq-Ur. On obtient alors,
Team-User(Eq-Ur) = [Mary, Helen]
Team-Role(Eq-Ur) = [cadre-infirmière, infirmière].
Les permissions de Eq-Ur sont déduites à partir de l’union des permissions des rôles des utilisateurs qui y participent, c’est-à-dire :
Permission-rôle-équipe(Eq-Ur) = SELECT Champ1, Champ3, Champ4 FROM Patient.
Supposons par ailleurs, que Chris commence une session s3 et qu’il active le rôle médecin au sein de l’équipe Eq-Ur. On a donc :
Team-User(Eq-Ur) = [Chris, Mary, Helen] ;
Team-Role(Eq-Ur) = [médecin, cadre-infirmière, infirmière], et
Permission-rôle-session Select Champ1, Champ2, Champ3 From Patient
Select
Champ1, Champ3, Champ4 From Patient Permission-rôle-équipe
Patients : (200, 351) Temps : [10h-12h]
Lieu : (UR1, UR3) Contexte de l’équipe
Combinaison = Agrégation
Filtrage Permission-rôles
Select Champ1, Champ2, Champ3, Champ4 From Patient
Permission-Contexte Select
Champ1, Champ2, Champ3, Champ4 From Patient
Where PatientID IN (200, 351) And Temps IN ([10h!; 12h)]
And Lieu IN (UR 1, UR 3) Identification + authentification
Activation des rôles Participations à des équipes
Permission-Rôle(Chris)=Permission-rôle-session(médecin)⊕Permission-rôles-équipe(Eq-Ur)
= {SELECT Champ1, Champ2, Champ3 FROM patient} » {SELECT Champ1, Champ3, Champ4 FROM patient}.
En appliquant la règle de filtrage, les permissions finales sont :
Permission-Contexte(Chris) = Permission-rôle(Chris) ƒ contexte-équipe(Eq-Ur)
= SELECT Champ1, Champ2, Champ3, Champ4 FROM patients ;
Where PatientID IN (200, 351) AND temps IN [10h-12h] AND lieu IN (UR1, UR3).
À travers cet exemple très simple, on peut constater que C-TMAC présente certaines faiblesses. En effet, si la combinaison est une agrégation, un utilisateur qui rejoint une équipe renforce les permissions de cette équipe en lui ajoutant les siennes : (Permissions-équipe-après affectation = Permissions-équipe-avant affectation » Permissions(nouvel utilisateur)). Ainsi, tous les membres de l’équipe auront les mêmes permissions. Néanmoins, dans le secteur médical, même si les professionnels de santé appartiennent à la même équipe du même hôpital, ils n’ont pas les mêmes droits d’accès aux mêmes parties des fichiers. Il est évident que les permissions finales du médecin doivent être différentes de celles de l’infirmière, même si tous les deux appartiennent à la même équipe de soins. Or, si on reprend l’exemple de la figure 2.6, en considérant, cette fois-ci, que le médecin se connecte avant l’infirmière, on constatera qu’en rejoignant l’équipe, l’infirmière a les mêmes permissions que le médecin.
Le cas où la combinaison est le maximum ou le minimum est, lui aussi, non réaliste car la déduction des permissions (application des deux règles citées précédemment) se fait de la même manière pour tous les membres d’une équipe donnée. On aura donc le même ensemble de privilèges pour tous ses membres. De plus, dans le secteur de la santé, que veut dire un ensemble minimal ou maximal de permissions ?
Par ailleurs, C-TMAC ne spécifie pas explicitement comment dériver les permissions dans le cas où la combinaison dépendrait de la structure de l’équipe.