Principe de privilège minimum
Le fonctionnement de ce modèle et
l'intégrité du système sont garantis si l'attribution des
permissions respecte le principe de privilège minimum.
Ce principe exige que l'utilisateur ne dispose pas de plus de
droits que nécessaire à son travail Ce qui implique que les
permissions affectées a un rôle constituent le strict minimum
nécessaire à l'accomplissement des tâches relatives
à ce rôle.
2.6.2. Modèle RBAC
Hiérarchique
Le modèle RBAC hiérarchique (Hierarchical RBAC)
ajoute au modèle de base le support de hiérarchie des
rôles.
La hiérarchie établit les liens de
parenté entre plusieurs niveaux des rôles et permet aux
rôles « parents » de disposer des permissions attribuées
aux rôles « enfants »
Le standard admet deux types de hiérarchies :
o le modèle hiérarchique
général (General Hierarchical RBAC) : cette variante
établie des relations multiples entre plusieurs « parents » et
« enfants ».
o le modèle hiérarchique
limité (Limited Hierarchical RBAC) : cette version limite la relation a
une simple structure d'arborescence. Ce qui veut dire qu'un rôle ne peut
avoir qu'un seul « parent ».
Cette extension du modèle permet une administration
plus efficace dans les grandes structures qui gèrent de très
nombreuses permissions d'un grand nombre d'utilisateurs. D'aune pan ce principe
permet de bien gérer les situations où certains rôles
différent; (du niveau supérieur) doivent bénéficier
de certaines permissions communes.
Remarque : Très souvent on applique une
version simple de l'extension au modèle hiérarchique limite. Elle
admet une hiérarchie des rôles a deux niveaux. Le niveau 1 est
appelé « un rôle » et le terne d'« un
profil » sera utilisé pour le deuxième niveau. Le profil
permettra donc les regroupements des rôles.
2.6.3. Modèle RBAC avec
contraintes
Le modèle RBAC avec contraintes (Constrained RBAC)
ajoute au modèle la contrainte de séparation des pouvoirs.
Cette contrainte permet d'inclure dans le modèle la
gestion de conflits d'intérêts et assurer que les utilisateurs
bénéficieront des permissions selon la politique définie
par l'organisation et ne pourront pas abuser de cumul non contrôle de
droits.
Séparation Statique des Pouvoirs (SSD -
Statk Séparation of Doty Relations)
La contrainte de séparation des pouvons est
utilisée pour assurer le respect de la politique des habilitations
Un conflit d'intérêts peut arriver (dans un
système du type RBAC) quand l'utilisateur obtient simultanément
les droits associés à des rôles incompatibles.
Une méthode pour éviter cette situation est la
mise en oeuvre de séparation statique de pouvoir (SSD pour Static
Séparation of Dutv)
L'exclusion mutuelle de certains rôles est
spécifiée par les régies de SSD. Ces règles sont
interprétées lors du processus d'affectation des rôles par
l'administrateur et l'empêchent d'affecter des rôles incompatibles
au même utilisateur
De cette manière, a une personne qui
bénéficie d'un rôle, on ne pourra pas affecter un
deuxième rôle interdit par la règle de SSD.
Pour éviter les incohérences les règles
SSD doivent prendre en compte les regroupements des rôles en fonction de
leur hiérarchie.
Séparation Dynamique des Pouvoirs (DSD -
Dynamic Séparation of Doty Relations)
La séparation dynamique limite comme la SSD le;
rôles accessibles à un utilisateur.
Par contre le conteste est différent. La limitation
n'est pas exploitée au moment de l'affectation des rôles mais au
moment de leur activation dans une session.
Dans une même session, un utilisateur a la
possibilité de ne pas activer tous ses rôles, mais uniquement le
sous-ensemble de ses rôles nécessaires à la
réalisation de la tâche à accomplir.
Ce mécanisme permet de garantir l'application des
permissions minimales nécessaires dans une période
d'exécution d'une tâche On peut parler, dans ce conteste, de
révocation temporaire des privilèges
La mise en oeuvre de ce mécanisme peut se
révéler très complexe et le plus souvent n'est pas
réalisée.
| 
