RBAC Role Based Access Control

Présentation au sujet: "RBAC Role Based Access Control"— Transcription de la présentation:

1 RBAC Role Based Access Control

2 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

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

4 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’

5 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

6 Exemple de hiérarchie de rôles
IBM Corporation, LOTUS Documentation Consulter cette page pour voir les permissions de chaque rôle dans cet exemple

7 Moodle et Microsoft Exchange
Deux logiciels qui apparemment utilisent les concepts de RBAC et vous pourriez vous amuser à les essayer

8 Moodle Apparemment, Moodle utilise aussi RBAC
Exercice: Étudier l’implémentation de RBAC dans Moodle

9 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

10 RBAC: 1er modèle conceptuel
Usagers Rôles Permissions Rôle 1 Rôle 2 Rôle 3 opération Cette affectaton peut changer souvent Cette affectaton ne change pas souvent

11 Exemple plus concret Ferraiolo, RBAC

12 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

13 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 sujet Un 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 login Un sujet peut appartenir à plusieurs sessions simultanément

14 Usager, sujet, rôle Continus: Vision entreprise, statique
Pointillés: Vision système, dynamique L’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)

15 Différentes affectations
Un usager peut avoir plusieurs sujets Usagers et sujets peuvent être affectés à différents rôles Condition 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

16 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 …

17 RBAC de base Core RBAC ou RBAC plat
user_sessions session_roles (UA) User Assign- ment (PA) Permission Assignment USERS OBS OPS SESSIONS ROLES PRMS

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

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 RBAC Hiérarchique

22 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 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

23 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é Hérite de tous Chef salaires: Ficher 5 Chef subventions: Fichier 6 3 Héritent de leurs subordonnés Comptable 1 F1, imprimante Comptable 2: F1, F2, Imprimante Comptable 3: F4

24 RBAC Hiérarchique (RH) Role Hierarchy (UA) User Assign- ment (PA)
Permission Assignment USERS ROLES OPS OBS PRMS user_sessions session_roles SESSIONS

25 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’

26 Types d’héritage Héritage d’usager (UI): Héritage de permission (PI)
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’

27 Diagramme UML pour RBAC
Source: Ahn and Shin: Role-Based Authorization Constraints …

28 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

29 Exemple de hiérarchie de roles 2
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

30 Directeur d’ingénierie
Roles spéciaux Ingénieur Ingénieur Matériel Ingénieur Logiciel Directeur d’ingénierie Maté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

31 Partitions dans la hiérarchie
Directeur Chef de projet 1 Chef de projet 2 Production Qualité Production Qualité Ingénieur Ingénieur Département d’ingénierie PROJET 1 PROJET 2 Employé

32 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

33 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 les groupes sont administrés séparemment Ferraiolo et al. p. 76

34 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. Ferraiolo et al. p. 77

35 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

36 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

37 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

38 RBAC avec contraintes

39 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

40 Exemple pratique Ferraiolo et al., RBAC Separation of Duties
Disbursement of Funds The following minimum separation of duties applies to individuals in departments and accounting offices who are responsible for the disbursement of funds. The following duties shall be performed by different individuals: Check request reviewer—evaluates requests with respect to business purpose, applicable policy, backup documentation, and authorized signature. Check preparer—prepares checks and ledger entries. Check issuer—has checks signed and approves ledger entry. Check deliverer—distributes checks or sends to payees. Ledger reviewer—reconciles bank statement with general ledger cash account. Depository Funds The following minimum separation of duties applies to individuals in departments and accounting offices who are responsible for depository funds. Mail handler—opens mail, reviews, and endorses checks. Cashier—processes cash, determines account coding, and deposits in bank account or delivers to another cashier. Auditor—ensures that all checks received are deposited and accounts coded correctly; also receives checks returned to the office. Ledger reviewer—reconciles department accounting records with accounting office records. Ferraiolo et al., RBAC

41 Représentation possible (exemple plus simple)

42 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

43 Différents types de RBAC
RBAC3 ou Symétrique ROLE HIERARCHIES + CONSTRAINTS RBAC1 ROLE HIERARCHIES RBAC2 CONSTRAINTS RBAC0 BASIC RBAC Ravi Sandhu

44 Différents types de contraintes
(UA) User Assign- ment (RH) Role Hierarchy user_sessions session_roles (PA) Permission Assignment USERS OBS OPS SESSIONS ROLES PRMS Contraintes S Article Ahn and Shin: Role-Based Authorization Constraints …

45 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

46 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

47 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

48 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

49 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

50 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

51 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

52 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

53 Statique et dynamique Statique (SSD): Dynamique (DSD):
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

54 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

55 SSD et DSD définitions SSD - Statique: DSD - Dynamique
É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

56 RBAC Symétrique C’est le RBAC avec Aussi appélé RBAC-3
hiérarchies de rôles et contraintes Aussi appélé RBAC-3

57 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

58 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

59 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

60 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

61 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?

62 RBAC dans la Toile

63 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

64 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

65 Architecture Server-Pull
L’usager s’identifie chez le serveur web et ce dernier demande les informations concernant le rôle à l’administrateur

66 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)

67 Flux de données

68 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

69 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

70 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 …

71 Administration de RBAC et Rôles administatifs

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é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

73 Rôles et permissions administratifs
Roles usagers Roles administratifs Source: Ferraiolo et al. Chap.9

74 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é

75 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

76 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

77 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

78 Conclusions sur RBAC

79 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

80 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

81 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

82 Limites de RBAC 2 (citation trouvée dans WWW)
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)

83 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

84 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

85 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, WET ICE Proceedings. Tenth IEEE International Workshops on, 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

86 Quelques champions … D. Richard (Rick) Kuhn Un des inventeurs de RBAC
Ravi Sandhu Auteur de travaux fondamentaux sur RBAC