rbac role based access control 1 [email protected]
TRANSCRIPT
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èresCW est un modèle pensé essentiellement pour un seul problèmeACM 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
3
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
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
5
Concept organisationnel de ‘Rôle’
Le concept de rôle existe dans presque toute organisationLes 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
Exemple de hiérarchie de rôles
6
http://infolib.lotus.com/resources/portal/8.0.0/doc/fr/PT800ACD002/security/sec_roles.htmlIBM Corporation, LOTUS DocumentationConsulter cette page pour voir les permissions de chaque rôle dans cet exemple
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 RBACExercice: Étudier l’implémentation de RBAC dans Moodle
8
9
RBACRBAC 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
RBAC: 1er modèle conceptuel
10
Usagers Rôles Permissions
Rôle 1
Rôle 2
Rôle 3
Cette affectatonpeut changer souvent
Cette affectatonne change pas souvent
opération
Exemple plus concret
11Ferraiolo, RBAC
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 un sujetUn sujet est un processus qui agit pour un usager, ou un sujet dans une session
Changeant de session, un usager devient un autre sujet et assume donc le(s) rôle(s) du nouveau sujet
• 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 loginUn sujet peut appartenir à plusieurs sessions simultanément
13
Usager, sujet, rôle
14L’usager u1 peut effectuer l’opération op2 l’objet o2 à travers le role r2. Pour ce faire, il invoque le sujet s2 (source: Ferraiolo, RBAC)
Continus: Vision entreprise, statique
Pointillés: Vision système, dynamique
Différentes affectations
Un usager peut avoir plusieurs sujetsUsagers et sujets peuvent être affectés à différents rôlesCondition de cohérence:
L’ensemble de rôles d’un sujet doit être inclus dans l’ensemble de rôles de l’usager auquel le sujet appartient
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éesUtiliser un ordiEntrer dans une salleRecevoir un salaire…
16
RBAC de base Core RBAC ou RBAC plat
17
user_sessions session_roles
(UA)User Assign-
ment
(PA)PermissionAssignment
USERS OBSOPS
SESSIONS
ROLES
PRMS
Usagers, sujets et sessions
‘Sujet’ n’est pas mentionné dans ce diagrammeIl est mentionné implicitement car les usagers deviennent des sujets en amorçant des sessions
18
user_sessions session_roles
(UA)User Assign-
ment
(PA)PermissionAssignment
USERS OBSOPS
SESSIONS
ROLES
PRMS
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ôlesession_users(session): l’usager correspondant à une sessionsession_roles(session): l’ensemble de roles pour une sessionavail_session_perms(session): permissions disponibles à un usager dans une session
19
20
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}
Modèle formel (source: Ferraiolo, RBAC)
RBAC Hiérarchique
21
RBAC HiérarchiqueDans 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
22
Comptable 1
Chef salaires
Comptable 2
Directeur de comptabilité
Comptable 3
Cheef facturation
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
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ériteSans devoir spécifier la liste complète des permissions hérités
23
Chef subventions: Fichier 6 3
Directeur comptabilité
Chef salaires: Ficher 5
Comptable 1F1, imprimante
Comptable 2: F1, F2,
ImprimanteComptable 3: F4
Héritent de leurs subordonnés
Hérite de tous
RBAC Hiérarchique
24
(UA)User Assign-
ment
(RH)(RH)Role HierarchyRole Hierarchy
user_sessions session_roles
(PA)PermissionAssignment
USERS OBSOPS
SESSIONS
ROLES
PRMS
HiérarchieLa hiérarchie doit être un ordre partiel
Pas nécessairement un arbrePas 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’
25
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’
26
Diagramme UML pour RBAC
27Source: Ahn and Shin: Role-Based Authorization Constraints …
Exemples de hiérarchies de rôles 1
28
Professionnel de santé
Docteur
Docteur de famille Docteur Spécialiste
Ce transparent et les suivants: notes de cours de R. Sandhu
Les hiérarchies de rôles ne sont pas nécessairement des arbres
Exemple de hiérarchie de roles 2
29
Ingénieur
Ingénieur Matériel Ingénieur Logiciel
Ingénieur en chef
Héritage multiple: l’ingénieur en chef hérite de deux côtés
Roles spéciaux
30
Ingénieur
Ingénieur Matériel Ingénieur Logiciel
Directeur d’ingénierieIngénieurMatériel 1
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
Partitions dans la hiérarchie
31
Département d’ingénierie
Chef de projet 1
Ingénieur
Production Qualité
Directeur
Chef de projet 2
Ingénieur
Production Qualité
PROJET 2PROJET 1
Employé
Hiérarchies générales ou limitées
Les hiérarchies limitées sont des arbresAucun sujet ne peut avoir plus d’un rôle seniorCeci 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
32
Groupes, roles et héritage
33Ferraiolo et al. p. 76
On peut affecter des groupes à des rôlesCeci peut être utile, mais peut aussi être source de confusion si les roles et les groupes sont administrés séparemment
Utilisation combinée d’héritage d’usagers et permissions (=privilèges)
34
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.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
35
Avantages de RBAC hiérarchique
Permet de réduire le nombre de permissions explicitesPermet 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
36
Mais attentionSouvent 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’infirmierAussi normalement les hiérarchies d’héritage sont beaucoup moins profondes
37
RBAC avec contraintes
38
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 temporellesUn docteur ne peut être admis en salle d’opération que entre 8:00 et 18:00
Autres: vaste éventail de possibilitésAucun usager ne peut avoir plus de 5 rolesAucun groupe de moins de 3 usagers ne peut couvrir toutes les permissions existantes dans un département
39
Exemple pratique
Separation of DutiesI.Disbursement of FundsII.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 FundsV.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.
40Ferraiolo et al., RBAC
Représentation possible(exemple plus simple)
41
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
42
Différents types de RBAC
RBAC0BASIC RBAC
RBAC3 ou SymétriqueROLE HIERARCHIES +
CONSTRAINTS
RBAC1ROLE
HIERARCHIES
RBAC2CONSTRAINTS
Ravi Sandhu
Différents types de contraintes
44
(UA)User Assign-
ment
(RH)(RH)Role HierarchyRole Hierarchy
user_sessions session_roles
(PA)PermissionAssignment
USERS OBSOPS
SESSIONS
ROLES
PRMS
ContraintesS
Article Ahn and Shin: Role-Based Authorization Constraints …
Exemples de contraintes 1
Reliées à la séparation de tâchesNe pas affecter à un usager des rôles en conflit (séparation de tâches, SOD)Ne pas affecter à un rôle des permissions en conflitDes usagers en conflit d’intérêt ne peuvent pas être affectés au même rôleDes rôles en conflit ne peuvent pas être activés dans la même session
45
Exemples de contraintes 2
PréréquisUn usager peut être affecté à un rôle seulement si l’usager est déjà membre d’un autre rôleUn role peut avoir une permission seulement s’il a déjà une autre permission
46
Exemples de contraintes 3
CardinalitéNe pas avoir plus (ou moins) de N usagers pour tel rôleUn usager ne peut pas avoir plus de N sessions actives en même tempsUne permission doit être donnée à au moins N roles
47
Et puis …
Il n’y a aucune limite aux contraintes qui peuvent être nécessaires dans des situations pratiquesP.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 futurNoter 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
48
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ôleHié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
49
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 usagerSsdRoleSet Cardinality: retourne la cardinalité d’un ensemble de SSD
50
Comment implémenter les contraintes?
Dans l’administration du systèmeLes 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écisionP.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
51
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èquesJeudi: l’admin donne au rôle contrôleur la permission de contrôler les chèquesVendredi: l’adm décide que Alice a les deux rôles
?
Il y a malheureusement plusieurs manières pour arriver à une situation de conflit
52
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
53
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 tempsSeulement la dernière des méthodes mentionnées est appropriée dans ce cas
54
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 - DynamiquePareil, 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
55
RBAC Symétrique
C’est le RBAC avec hiérarchies de rôles et contraintes
Aussi appélé RBAC-3
56
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érarchiquePlusieurs niveaux hiérarchiques peuvent être entre les deux rôles
Il peut être difficile de trouver tous les cas comme ça dans une grande organisationConsidérez le cas de nouveaux rôles qui peuvent être créés et qui héritent les autorisations des rôles subordonnés
57
Role qui permet d’émettre des chèques
Role qui permet le contrôle des chèques
Sujet
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
58
Difficultés pour le contrôle dynamique
RBAC avec héritage *et* contraintes dynamiques est difficile à implémenter de manière correcteLes contraintes dynamiques introduisent des politiques négatives
Dans le reste de RBAC, il n’y a que des politiques positives
59
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èquesBen les signeOn 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
60
Exercice
Comment spécifier la contrainte suivante:Un docteur ne peut ordonner des médicaments pour lui-mêmeEst-ce une contrainte statique, dynamique?
61
RBAC dans la Toile
62
RBAC dans la Toile
Dans la Toile, nous avons trois éléments de base:ClientServeur WebServeur 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 domaineOn peut identifier deux architectures possibles:
User-pullServer-pull
63
Architecture User-Pull
L’usager récupère les informations concernant son rôle du serveur de rôle et il les présente au serveur web 64
HTTP
Architecture Server-Pull
L’usager s’identifie chez le serveur web et ce dernier demande les informations concernant le rôle à l’administrateur
65
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)
66
Flux de données
67
Flux de données dans RBAC
On peut avoir du partage de données dans deux manières fondamentales:
Par héritagePermissions 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
68
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 F1Bob: lire F1, écrire F2Charline: 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 complexesAffectation 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
69
Méthodes pour contrôler le flux
Des méthodes ont été inventées pour pallier à ces possibilitésP.ex. on peut créer des hiérarchies de rôles sur le modèle de MACÀ voir plus tard …
70
Administration de RBAC et
Rôles administatifs
71
72
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éeQuelles sont les permissions associées à chaque rôleQuelle est la hiérarchie des rôlesComment différents usagers peuvent devenir associés à différents rôlesQuelles sont les contraintes à respecter
On ajoute donc les concepts deRôles administratifsPermissions administratives
73
Rôles et permissions administratifs
Source: Ferraiolo et al. Chap.9
Roles usagers
Roles administratifs
74
Roles admin dans une organisation
Administrateurs de rôles pour toute l’organisationAdministrateurs de rôles pour un département donnéAdministrateurs de rôles pour un projet donné
Commandes administratives pour RBAC de base
(dans la norme ANSI-INCIT)Add UserDelete UserAdd RoleDelete RoleAssign User (à un rôle)Deassign UserGrant Permission (à un rôle)Revoke PermissionCreate Session (pour un usager)Delete Session
75
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 InheritanceAdd Ascendant: crée un nouveau rôle et l’insèreAdd Descendant
76
Commandes admin avec SD
Separation of Duties: SSD Static, DSD Dynamic
Create SSD setDelete SSD setAdd SSD Role MemberDelete SSD Role MemberSet SSD Set Cardinality
+ Semblables pour Dynamic SD
77
Conclusions sur RBAC
78
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
79
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 organisationles tâches dans une organisation
80
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
81
Limites de RBAC 2
Let's say that there are two organizations within a single company called A and BEach company has its own set of data, DataSetA and DataSetBThere are roles Employee and ManagerEmployees can view data from their own organizationManagers 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)
82
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 politiquesDes autres organisations se contentent d’identifier seulement un petit nombre de rôles, et le reste échappe à RBAC
• Ce qui est contre-productif
83
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 RBACCes 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’autreAussi, 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
84
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, 2007Norme 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
85
Quelques champions …
86
D. Richard (Rick) KuhnUn des inventeurs de RBAC
Ravi SandhuAuteur de travaux fondamentaux sur RBAC