Transcript Role-Based Access Control - Site Web à vocation éducationnel de l

RBAC
Role Based Access Control
[email protected]
1
Problèmes avec MAC et DAC
La plupart des modèles MAC sont basés sur des très fortes
structurations hiérarchiques des usagers et de ressources, qui
peuvent être trouvées seulement dans des organisations
particulières
CW est un modèle pensé essentiellement pour un seul problème
ACM et DAC sont de gestion difficile car chaque usager est un
cas individuel
Considérez des cies de milliers d’employés
DAC suppose que les usagers sont propriétaires des ressources
et peuvent transférer les droits sur elles,
Tandis que normalement c’est l’organisation qui est propriétaire des
ressources, et veut en retenir le contrôle
2
Concept de “Groupe”
La gestion des politiques et des membres des organisations peut
être facilitée par l’introduction de politiques par ‘groupes’
P.ex. le gérant du système crée un groupe ‘programmeurs qui
participent au projet X’ et octroie des permissions à ce groupe
Group-based access control
Ceci se fait, mais la gestion est encore difficile car le gérant de la
sécurité a la responsabilité de créer et gérer les groupes
3
Concept de Rôle
RBAC est basé sur deux points:
Le fait que dans les organisations les employés sont
classés par rôles
• Comptable, programmeur, docteur, infirmière, technicien
…
Le fait que chaque employé, pour exécuter son rôle,
a besoin de certaines ‘permissions’
• Notion de ‘besoin de savoir’
4
Concept organisationnel de ‘Rôle’
Le concept de rôle existe dans presque toute
organisation
Les personnes qui appartiennent à un rôle ont plusieurs
propriétés en commun:
Responsabilités,échelles salariales …
À l’UQO: étudiants, professeurs, techniciens …
Dans un hôpital: patients, docteurs, personnel
d’administration, etc.
L’affectation d’un usager à un rôle est un acte officiel
qui a beaucoup de conséquences dans l’organisation
5
Exemple de hiérarchie de rôles
http://infolib.lotus.com/resources/portal/8.0.0/doc/fr/PT800ACD002/security/sec_roles.html
IBM Corporation, LOTUS Documentation
Consulter cette page pour voir les permissions de chaque rôle dans cet exemple
6
Moodle et Microsoft Exchange
Deux logiciels qui apparemment utilisent les
concepts de RBAC et vous pourriez vous
amuser à les essayer
7
Moodle
Apparemment, Moodle utilise aussi RBAC
Exercice: Étudier l’implémentation de RBAC
dans Moodle
8
RBAC
RBAC profite de cette notion organisationnelle de rôle pour
associer des permissions de sécurité aux différents rôles
Le rôle devient un mécanisme pour associer des
permissions aux usagers
Parfois on trouve des définitions de
rôles comme groupes ou
ensembles d’usagers, mais cette
définition n’est pas conforme à la
norme RBAC
9
RBAC: 1er modèle conceptuel
Usagers
Rôles
Permissions
Rôle 1
opération
Rôle 2
Rôle 3
Cette affectaton
peut changer souvent
Cette affectaton
ne change pas souvent
10
Exemple plus concret
Ferraiolo, RBAC
11
Simplification apportée par RBAC
RBAC simplifie la gestion du contrôle d’accès
car les permissions sont déterminés en fonction
des rôles et cette association ne change pas
souvent
12
Usagers, sujets, sessions, rôles
Du point de vue formel, un rôle n’est qu’un nom qui identifie un ensemble
de permissions
Les rôles sont affectés aux usagers, mais afin qu’un usager puisse les utiliser,
il doit activer des sujets dans des sessions
Un sujet est un processus qui agit pour un usager, il existe dans une session
Changeant de session, un usager peut activer des nouveaux sujets et en les
activant il assume le(s) rôle(s) de ces sujets
• P.ex. un employé de banque Paul
–
–
peut être un sujet avec un rôle quand il est aux prêts et
un autre sujet avec un autre rôle quand il est aux investissements
Une ‘session’ correspond à un domaine de sécurité
Normalement, pour accéder à une session, un sujet doit effectuer un login
Un sujet peut se trouver dans plusieurs sessions simultanément
13
Usager, sujet, rôle
Continus:
Vision entreprise,
statique
Session
Pointillés: Vision
système,
dynamique
L’usager u1 peut effectuer l’opération op2 sur l’objet o2 à travers le rôle r2.
Pour ce faire, il doit entrer dans une session qui lui permette d’activer le sujet s2
(source: Ferraiolo, RBAC)
14
Cohérence
Condition de cohérence:
L’ensemble de rôles d’un sujet doit être inclus dans
l’ensemble de rôles des usagers qui peuvent l’activer
• Ex: Si un sujet S peut avoir rôle caissier, les usagers qui
peuvent activer S doivent aussi pouvoir avoir rôle caissier
15
Permissions
(ou ‘privilèges)
Formellement, les permissions sont des paires
(opération, objet)
Les opérations et les objets sont des entités
génériques
Lire, écrire, mettre à jour etc. un fichier ou base de
données
Utiliser un ordi
Entrer dans une salle
Recevoir un salaire
…
16
‘Core’ RBAC
RBAC de base ou plat
17
RBAC de base
Core RBAC ou RBAC plat
(UA)
User Assignment
USERS
(PA)
Permission
Assignment
ROLES
user_sessions
session_roles
OPS
OBS
PRMS
SESSIONS
18
Usagers, sujets et sessions
‘Sujet’ n’est pas mentionné dans ce diagramme
Il est mentionné implicitement car les usagers
deviennent des sujets en amorçant des sessions
(UA)
User Assignment
USERS
(PA)
Permission
Assignment
ROLES
user_sessions
session_roles
OPS
OBS
PRMS
SESSIONS
19
Fonctions pour RBAC de base
(core RBAC)
assigned_users(role): retourne l’ensemble d’usagers affectés à
un rôle donné
assigned_permissions(role): l’ensemble des permission pour le
rôle
session_users(session): l’usager correspondant à une session
session_roles(session): l’ensemble de roles pour une session
avail_session_perms(session): permissions disponibles à un
usager dans une session
20
Modèle formel (source: Ferraiolo, RBAC)
USERS, ROLES, OPS, and OBS (users, roles, operations, and objects, respectively).
UA ⊆ USERS × ROLES, a many-to-many mapping between users and roles (user-to-role assignment
relation).
assigned_users: (r:ROLES) → 2USERS, the mapping of role r onto a set of users.
Formally: assigned_users(r) = {u ∈ USERS ∣ (u,r) ∈ UA}
PRMS = 2(OPS × OBS), the set of permissions.
PA ⊆ PRMS × ROLES, a many-to-many mapping between permissions and roles (role-permission assignment
relation).
assigned_permissions(r: ROLES) →2PRMS, the mapping of role r onto a set of permissions.
Formally: assigned_permissions(r) = {p ∈ PRMS|(p,r) ∈ PA}.
SUBJECTS, the set of subjects.
subject_user(s: SUBJECTS) → USERS, the mapping of subject s onto the subject's associated user.
subject_roles(s:SUBJECTS) →2ROLES, the mapping of subject s onto a set of roles.
Formally: subject_roles(si) ⊆ {r ∈ ROLES|(subject_user(si),r) ∈ UA}
21
Exercice
Expliquer pourquoi les rôles sont définis comme
primitifs. Pourquoi on ne dit pas:
Qu’un rôle est un ensemble de sujets
Qu’un rôle est un ensemble de permissions
Les raisons sont pratiques, et essentiellement
les mêmes dans les deux cas
22
RBAC Hiérarchique
23
RBAC Hiérarchique
Dans les organisations, il y a normalement des hiérarchies de
rôles, et les patrons ont plus de pouvoir que les subordonnés
Ils héritent leurs permissions
Directeur de comptabilité
Chef salaires
Comptable 1
Comptable 2
Cheef facturation
Comptable 3
Comptable 4
Le directeur des salaires hérite les permissions des comptables 1 et 2, et le
Directeur de la comptabilité hérite les permissions des deux directeurs
Si Comptable1 a une permission, alors le Chef Salaire et le Directeur de
Comptabilité l’ont aussi
24
Simplification apportée par le concept de
hiérarchie
Pour un rôle en haut de la hiérarchie, il suffit de spécifier de
quels rôles il hérite
Sans devoir spécifier la liste complète des permissions hérités
Directeur
comptabilité
Chef salaires:
Ficher 5
Comptable 1
F1, imprimante
Hérite de tous
Chef
subventions:
Fichier 6 3
Comptable 2:
F1, F2,
Imprimante
Héritent de leurs
subordonnés
Comptable 3: F4
25
RBAC Hiérarchique
(RH)
Role Hierarchy
(UA)
User Assignment
USERS
(PA)
Permission
Assignment
ROLES
user_sessions
session_roles
OPS
OBS
PRMS
SESSIONS
26
Hiérarchie
La hiérarchie doit être un ordre partiel
Pas nécessairement un arbre
Pas nécessairement un treillis
Les rôles inférieurs s’appellent ‘junior’ et les supérieurs
‘senior’
‘Comptable1’ est junior de ‘Chef salaires’
‘Chef salaires’ est senior de ‘Comptable1’ et junior de
‘Directeur de comptabilité’
On utilise aussi
≤ pour ‘junior’
≥ pour ‘senior’
27
Types d’héritage
Héritage d’usager (UI):
Tous les usagers autorisés à un role r sont aussi
autorisés à un rôle r’ tel que r≥r’
Héritage de permission (PI)
Un rôle r a toutes les permissions d’un rôle r’, si r≥r’
Héritage d’activation (AI)
Dans une activation de session, un sujet qui a un
rôle r aura automatiquement un rôle r’ tel que r≥r’
28
Diagramme UML pour RBAC
Source: Ahn and Shin: Role-Based Authorization Constraints …
29
Exemples de hiérarchies de rôles 1
Docteur de famille
Docteur Spécialiste
Docteur
Les hiérarchies de rôles ne
sont pas nécessairement
des arbres
Professionnel de santé
Ce transparent et les suivants: notes de cours de R. Sandhu
30
Exemple de hiérarchie de roles 2
Ingénieur en chef
Ingénieur Logiciel
Ingénieur Matériel
Ingénieur
31
Héritage multiple: l’ingénieur en chef hérite de deux côtés
Roles spéciaux
Ingénieur
Matériel 1
Directeur d’ingénierie
Ingénieur Matériel
Ingénieur Logiciel
Ingénieur
Un pb avec RBAC est qu’on définit trop souvent des rôles spéciaux, parfois pour des cas
individuels, et ils compliquent la structure des rôles
32
Partitions dans la hiérarchie
Directeur
Chef de projet 1
Production
Chef de projet 2
Qualité
Production
Ingénieur
PROJET 1
Qualité
Ingénieur
Département d’ingénierie
PROJET 2
Employé
33
Hiérarchies générales ou limitées
Les hiérarchies limitées sont des arbres
Aucun sujet ne peut avoir plus d’un rôle senior
Ceci est très contraignant dans une organisation,
mais facilite le calcul de l’héritage
• Revoir les exemples précédents qui sont presque tous
des hiérarchies générales
34
Groupes, roles et héritage
On peut affecter des groupes à des rôles
Ceci peut être utile, mais peut aussi être source de confusion si les roles et
35
les groupes sont administrés séparemment
Ferraiolo et al. p. 76
Utilisation combinée d’héritage d’usagers et permissions
(=privilèges)
Les rôles vers l’haut sont ceux qui contiennent
« le plus grand nombre de privilèges et le plus petit nombre d’usagers »
Les permissions de U3 sont: P4, P5, P8, P9, P10, P1,_P2, P3.
36
Ferraiolo et al. p. 77
Fonctions pour RBAC hiérarchique
Sont essentiellement les mêmes que pour RBAC
de base, mais il faut tenir compte qu’un usager
peut avoir une permission par effet d’une
hiérarchie
37
Avantages de RBAC hiérarchique
Permet de réduire le nombre de permissions
explicites
Permet de construire une hiérarchie de rôles
cohérente à l’organisation au lieu d’avoir une
quantité de rôles indépendants
Facilite le travail de l’administrateur si la
hiérarchie est stable
Une seule décision à un niveau élevé a des
conséquences aux niveaux inférieurs
38
Mais attention
Souvent la hiérarchie de rôles organisationnels ne
correspond pas à la hiérarchie d’héritage de
permissions
Ex 1: un directeur de banque n’aura normalement pas l’union
de toutes les permissions de tous les employés
• Il lui pourrait être nié de lire les transactions des usagers, etc.
Ex2: dans un hôpital un infirmier et un docteur appartiennent
à deux hiérarchies différentes, cependant le docteur a droit
de lire tous les dossiers de l’infirmier
Aussi normalement les hiérarchies d’héritage sont beaucoup
moins profondes
39
RBAC avec contraintes
40
Types de contraintes
Séparation de tâches (separation of duties)
Exemple: Celui qui approuve un cheque ne peut pas être
celui qui le signe
Contraintes temporelles
Un docteur ne peut être admis en salle d’opération que entre
8:00 et 18:00
Autres: vaste éventail de possibilités
Aucun usager ne peut avoir plus de 5 roles
Aucun groupe de moins de 3 usagers ne peut couvrir toutes
les permissions existantes dans un département
41
Exemple pratique
Separation of Duties
I.Disbursement of Funds
II.The following minimum separation of duties applies to individuals in departments and
accounting offices who are responsible for the disbursement of funds.
III.The following duties shall be performed by different individuals:
I. Check request reviewer—evaluates requests with respect to business
purpose, applicable policy, backup documentation, and authorized
signature.
II. Check preparer—prepares checks and ledger entries.
III. Check issuer—has checks signed and approves ledger entry.
IV. Check deliverer—distributes checks or sends to payees.
V. Ledger reviewer—reconciles bank statement with general ledger cash
account.
IV.Depository Funds
V.The following minimum separation of duties applies to individuals in departments and
accounting offices who are responsible for depository funds.
VI.The following duties shall be performed by different individuals:
I. Mail handler—opens mail, reviews, and endorses checks.
II. Cashier—processes cash, determines account coding, and deposits in
bank account or delivers to another cashier.
III. Auditor—ensures that all checks received are deposited and accounts
coded correctly; also receives checks returned to the office.
IV. Ledger reviewer—reconciles department accounting records with
accounting office records.
Ferraiolo et al., RBAC
42
Représentation possible
(exemple plus simple)
43
Tâches et permissions
En terminologie RBAC, la séparation de tâches
devrait vraiment s’appeler séparation de rôles ou
de permissions
Cependant la terminologie ‘séparation de tâches’
est bien établie dans la théorie des organisations
44
Différents types de RBAC
RBAC3 ou Symétrique
ROLE HIERARCHIES +
CONSTRAINTS
RBAC1
ROLE
HIERARCHIES
Ravi Sandhu
RBAC2
CONSTRAINTS
RBAC0
BASIC RBAC
Différents types de contraintes
(RH)
Role Hierarchy
(UA)
User Assignment
USERS
(PA)
Permission
Assignment
ROLES
user_sessions
session_roles
OPS
OBS
PRMS
SESSIONS
S
Contraintes
46
Article Ahn and Shin: Role-Based Authorization Constraints …
Exemples de contraintes 1
Reliées à la séparation de tâches
Ne pas affecter à un usager des rôles en conflit
(séparation de tâches, SOD)
Ne pas affecter à un rôle des permissions en conflit
Des usagers en conflit d’intérêt ne peuvent pas être
affectés au même rôle
Des rôles en conflit ne peuvent pas être activés dans
la même session
47
Exemples de contraintes 2
Préréquis
Un usager peut être affecté à un rôle seulement si
l’usager est déjà membre d’un autre rôle
Un role peut avoir une permission seulement s’il a
déjà une autre permission
48
Exemples de contraintes 3
Cardinalité
Ne pas avoir plus (ou moins) de N usagers pour tel
rôle
Un usager ne peut pas avoir plus de N sessions
actives en même temps
Une permission doit être donnée à au moins N roles
49
Et puis …
Il n’y a aucune limite aux contraintes qui peuvent être
nécessaires dans des situations pratiques
P.ex. Muraille de Chine: il y a là une contrainte qui est
déterminée par l’histoire:
Les lectures-écritures effectuées avant déterminent les accès permis
dans le futur
Noter la différence avec RBAC où on parle de permissions déjà reçues
Cependant la documentation RBAC mentionne seulement les
contraintes que nous avons spécifiées avant
autres types de contraintes ont fait l’objet d’extensions de RBAC
50
Séparation de tâches simple et hiérarchique
Simple, directe: Les deux tâches en séparation
ne peuvent pas être affectées à un seul rôle
Hiérarchique: Un usager ne peut pas acquérir la
permission pour deux tâches en séparation ni
directement ni par effet d’héritage
Dans un système complexe, ceci est difficile à
vérifier
51
Commandes pour Séparation de tâches
(Ssd Static separation of duties)
Ssd Role Sets: retourne la liste de tous les
ensembles de rôles qui ne peuvent pas être
assignés ensemble au même usager
SsdRoleSet Cardinality: retourne la cardinalité
d’un ensemble de SSD
52
Comment implémenter les contraintes?
Dans l’administration du système
Les outils d’administration empêchent la création de certaines situations
• P.ex. si l’administrateur cherche à créer une situation défendue, l’outil l’avertit ou
empêche que la situation soit créée
• On pense ici à une séquence de décisions de l’admin,
Détection par vérification (audit)
Des outils spécialisés contrôlent le système pour voir que certaines situations
n’existent pas
• Le système entier est contrôlé périodiquement
• Si des situations défendues existent, des diagnostiques sont affichées et
l’administrateur devra corriger la situation
Au moment de la prise de décision
P.ex. au moment où un sujet demande d’émettre un cheque, le système contrôle
qu’il n’est pas le même sujet qui vient de l’autoriser
• S’il l’est, il bloque la transaction
• Ou l’enregistre dans un fichier qui sera vérifié plus tard
53
Histoire de décisions de l’admin
Mercredi: l’admin crée les rôles comptables et contrôleur, ils sont
indépendants
Jeudi : l’admin donne au rôle comptable la permission d’émettre
des chèques
Jeudi: l’admin donne au rôle contrôleur la permission de
contrôler les chèques
Vendredi: l’adm décide que Alice a les deux rôles
?
Il y a malheureusement plusieurs manières pour arriver à une
situation de conflit
54
Statique et dynamique
Statique (SSD):
La tâche de signer les chèques est incompatible en
principe avec la tâche de les approuver
Dynamique (DSD):
Un usager ne peut pas avoir deux sessions actives
avec deux tâches en conflit d’intérêt
• P.ex. aucun employé de banque ne peut avoir deux
session actives pour deux clients différents
55
Contraintes statiques et dynamiques
Les contraintes dynamiques sont celles qui ne
peuvent être contrôlées qu’au moment de la
prise de décision
P.ex. un cheque ne peut pas être émis et contrôlé
par le même sujet, mais les sujets affectés aux deux
permissions peuvent changer dans le temps
Seulement la dernière des méthodes mentionnées
est appropriée dans ce cas
56
SSD et DSD définitions
SSD - Statique:
Étant donné un ensemble de rôles en conflit,
aucun usager ne peut avoir plus de n rôles dans cet
ensemble
• Cas simple: n=1 (n déterminé en fonction des besoins)
DSD - Dynamique
Pareil, mais:
aucun ensemble de sujets pour un même usager ne peut
avoir simultanément plus de n rôles dans un ensemble de
rôles en conflit
57
RBAC Symétrique
C’est le RBAC avec
hiérarchies de rôles et
contraintes
Aussi appélé RBAC-3
58
Difficultés pour le contrôle statique
P. ex. considérez le cas où un sujet reçoit deux permissions en conflit par l’entremise
de rôles à différents niveaux hiérarchique
Plusieurs niveaux hiérarchiques peuvent être entre les deux rôles
Il peut être difficile de trouver tous les cas comme ça dans une grande
organisation
Considérez le cas de nouveaux rôles qui peuvent être créés et qui héritent les
autorisations des rôles subordonnés
Role qui permet
d’émettre des chèques
Role qui permet
le contrôle des chèques
Sujet
59
Outils de vérification statiques
(audit)
Des outils industriels existent, pour permettre de vérifier
si un ensemble d’affectation rôles et permissions
satisfait à un ensemble de contraintes, p.ex.
Y a-t-il un rôle avec moins de 5 usagers?
Y a-t-il un usager qui a plus de 5 rôles?
Y a-t-il un sujet qui a toutes les permissions A,B,C?
Ces outils affichent des diagnostiques qui pourront être
utilisés pour nettoyer le système
À discuter plus tard
60
Difficultés pour le contrôle dynamique
RBAC avec héritage *et* contraintes
dynamiques est difficile à implémenter de
manière correcte
Les contraintes dynamiques introduisent des
politiques négatives
Dans le reste de RBAC, il n’y a que des politiques
positives
61
Difficultés pratiques
Il y a beaucoup de cas pratiques qui peuvent conduire à la
violation de contraintes de manière dynamique
Surtout liés à la nature dynamique du travail dans les organisations
Alice est affectée au rôle de contrôleur de chèques
Ben les signe
On demande à Alice de remplacer temporairement le chef de
Ben, elle obtient ses permissions
Alice peut et ne peut pas signer les chèques
On trouve aussi des cas beaucoup plus difficiles à détecter
62
Exercice
Comment spécifier la contrainte suivante:
Un docteur ne peut ordonner des médicaments pour
lui-même
Est-ce une contrainte statique, dynamique?
63
RBAC dans la Toile
64
RBAC dans la Toile
Dans la Toile, nous avons trois éléments de base:
Client
Serveur Web
Serveur de Rôles
Un client se connecte à un serveur web via un navigateur web
Le serveur de rôles est maintenu par un administrateur qui
affecte des utilisateurs à des rôles au sein d’un domaine
On peut identifier deux architectures possibles:
User-pull
Server-pull
65
Architecture User-Pull
HTTP
L’usager récupère les informations concernant son rôle du
serveur de rôle et il les présente au serveur web
66
Architecture Server-Pull
L’usager s’identifie chez le serveur web et ce dernier demande
les informations concernant le rôle à l’administrateur
67
Utilisation
User-pull est plus approprié si le serveur est à
l’extérieur de l’entreprise
Le serveur web ne devrait pas connaître le rôle de
l’usager à l’intérieur
Park, Sandhu: RBAC on the Web by Smart Certificates, 1999
(les dessins sont pris de cet article)
68
Comparaison
Park, Ahn, Sandhu: Role-Based Access Control on the
Web using LDAP, 2001
69
Flux de données
70
Différence importante MAC-RBAC
Les méthodes MAC se préoccupent surtout de contrôler
le flux de données
Direct ou indirect
RBAC et les autres méthodes que nous verrons
dorénavant se préoccupent surtout du contrôle d’accès
Elles peuvent contrôler l’accès aux informations comme à
autres entités, p.ex. locaux ou outils
Elles n’ont pas des mécanismes spécifiques pour le contrôle
de flux
71
Flux de données dans RBAC
On peut avoir du partage de données dans deux
manières fondamentales:
Par héritage
Permissions partagées
• P.ex. dans un hôpital les docteurs et les infirmières
appartiennent à des hiérarchies différentes
– Mais ils peuvent partager la permission de lire les dossiers des
patients
72
Difficultés pratiques
Dans RBAC il est facile d’avoir des transferts de données entre rôles à travers des
‘canaux indirects’
Alice: son rôle lui permet d’écrire dans fichier F1
Bob: lire F1, écrire F2
Charline: lire F2
• Charline peut recevoir une copie de F1 par l’entremise de Bob
Il est théoriquement possible d’établir toutes ces possibilités, mais ceci n’est pas
pratique s’il y a:
Grand nombre de rôles
Héritages complexes
Affectation de rôles qui peuvent changer fréquemment
Donc dans RBAC
un usager ne peut pas avoir contrôle sur ses informations et
en pratique ceci peut aussi être très difficile pour l’administrateur, s’il y a des héritages et
partages de permissions complexes
73
Méthodes pour contrôler le flux
Des méthodes ont été inventées pour pallier à
ces possibilités
P.ex. on peut créer des hiérarchies de rôles sur
le modèle de MAC
À voir plus tard …
74
Administration de RBAC et
Rôles administatifs
75
Administration de RBAC
L’utilisation de RBAC dans une entreprise doit être
administrée. Les administrateurs doivent déterminer
Quels sont les rôles possibles dans une entreprise donnée
Quelles sont les permissions associées à chaque rôle
Quelle est la hiérarchie des rôles
Comment différents usagers peuvent devenir associés à
différents rôles
Quelles sont les contraintes à respecter
On ajoute donc les concepts de
Rôles administratifs
Permissions administratives
76
Rôles et permissions administratifs
Roles usagers
Roles administratifs
Source: Ferraiolo et al. Chap.9
77
Roles admin dans une organisation
Administrateurs de rôles pour toute l’organisation
Administrateurs de rôles pour un département
donné
Administrateurs de rôles pour un projet donné
78
Commandes administratives pour RBAC de base
(dans la norme ANSI-INCIT)
Add User
Delete User
Add Role
Delete Role
Assign User (à un rôle)
Deassign User
Grant Permission (à un rôle)
Revoke Permission
Create Session (pour un usager)
Delete Session
79
Opérations sur les hiérarchies de rôles
Ajouter une relation de séniorité entre rôles
Retirer une relation de séniorité entre rôles
Ces deux opérations doivent être exécutées avec la
plus grande attention car elles peuvent impliquer un
grand nombre de sujets et un grand nombre de
permissions
80
Commandes administratives
pour RBAC hiérarchique
Add Inheritance: établit un héritage entre deux rôles
existants; valide seulement à certaines conditions
Clairement, on ne peut pas permettre qu’il crée un cycle dans
l’héritage, aussi il faut considérer si on veut que la hiérarchie
soit arborescente (=limitée)
Delete Inheritance
Add Ascendant: crée un nouveau rôle et l’insère
Add Descendant
81
Commandes admin avec SD
Separation of Duties: SSD Static, DSD Dynamic
Create SSD set
Delete SSD set
Add SSD Role Member
Delete SSD Role Member
Set SSD Set Cardinality
+ Semblables pour Dynamic SD
82
Conclusions sur RBAC
83
RBAC Norme et implémention
RBAC est le sujet d’une norme de l’ANSI-INCIT, qui le
décrit avec précision (utilisant le langage logique Z)
American National Standards Institute – InterNational
Committee for Information Technology Standards
Il a connu plusieurs implémentations, souvent pas
complètement fidèles à la norme
IBM, Microsoft, Oracle …
On connait aussi un bon nombre de systèmes qui ne
sont pas fidèles, mais se sont inspirés de l’idée de
RBAC
84
Avantages de RBAC
Comme déjà dit, les avantages de RBAC sont
nombreux et surtout il établit une relation stable
entre
la sécurité des données
la structure d’une organisation
les tâches dans une organisation
85
Limites de RBAC 1
Pouvez-vous facilement spécifier en RBAC la
politique suivante:
Un docteur ne peut faire accès qu’aux dossiers de
ses propres patients
• Pensez-y bien, comment on pourrait le faire et à quels
coûts
86
Limites de RBAC 2
Let's say that there are two organizations within a single company called A
and B
Each company has its own set of data, DataSetA and DataSetB
There are roles Employee and Manager
Employees can view data from their own organization
Managers can edit data from their own organization and view data from the
other organization (i.e. company-wide)
I cannot find a way to implement this in a RBAC system without creating roles
such as ReadDataSetA and EditDataSetA. Approaches that require this many
roles are too cumbersome since there will be hundreds of organizations and
companies.
(citation trouvée dans WWW)
87
Limites de RBAC 3
Bien que RBAC ait été créé pour simplifier la
spécification de politiques, en pratique
Pour spécifier des cas comme les précédents
Et aussi pour spécifier toutes les exceptions, cas particulier,
etc.
Il est normal de trouver des systèmes RBAC avec des
milliers de rôles et politiques
Des autres organisations se contentent d’identifier seulement
un petit nombre de rôles, et le reste échappe à RBAC
• Ce qui est contre-productif
88
Résultats théoriques
RBAC peut être configuré pour produire des résultats équivalents
à MAC ou DAC
Il faut utiliser le modèle admin de RBAC pour pouvoir changer les
autorisations comme on peut faire dans DAC
Mais le modèle DAC style HRU peut à son tour être configuré
pour obtenir les résultats de RBAC
Ces résultats ne disent rien sur l’expressivité des différentes
techniques
Pour des exigences spécifiques, un de RBAC ou DAC pourrait être plus
simple à utiliser que l’autre
Aussi, si RBAC est utilisé pour obtenir les résultats de MAC, il est
nécessaire d’ajouter des mécanismes pour assurer l’aspect ‘obligatoire’ de
MAC
89
Principales Ressources utilisées
(merci!)
G.-J. Ahn, M.E. Shin: Role-Based Authorization Constraints Specification Using Object
Constraint Language. Enabling Technologies: Infrastructure for Collaborative
Enterprises, 2001. WET ICE 2001. Proceedings. Tenth IEEE International Workshops
on, 157-162.
D.F. Ferraiolo, D.R. Kuhn, R. Chandramouli. Role-Based Access Control, 2nd ed.,
Artech House, 2007
Norme ANSI-INCIT pour RBAC (disponible dans Moodle)
J.S. Park, R. Sandhu, RBAC on the Web by Smart Certificates, RBAC '99 Proceedings
of the fourth ACM workshop on Role-based access control, 1-9.
R. Sandhu, Diapositives dans son site web
90
Quelques champions …
D. Richard (Rick) Kuhn
Un des inventeurs de RBAC
Ravi Sandhu
Auteur de travaux fondamentaux sur RBAC
91