RBAC Role Based Access Control

1. RBACRole Based Access Control Luigi.Logrippo@uqo.ca

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

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. Rôle 1 Rôle 2 Rôle 3 RBAC: 1er modèle conceptuel Usagers Rôles Permissions 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 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

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

15. 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

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. ‘Core’ RBAC RBAC de base ou plat

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

19. 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

20. 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

21. 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}

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

23. RBAC Hiérarchique

24. Directeur de comptabilité Chef salaires Cheef facturation Comptable 1 Comptable 3 Comptable 2 Comptable 4 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 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

25. 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 2: F1, F2, Imprimante Comptable 1 F1, imprimante Comptable 3: F4

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

27. 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’

28. 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’

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

30. 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

31. Ingénieur en chef Ingénieur Logiciel Ingénieur Matériel Ingénieur Exemple de hiérarchie de roles 2 Héritage multiple: l’ingénieur en chef hérite de deux côtés

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

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

34. 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

35. 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

36. 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

37. 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

38. 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

39. 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

40. RBAC avec contraintes

41. 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

42. Exemple pratique Ferraiolo et al., RBAC

43. Représentation possible(exemple plus simple)

44. Tâches et permissions • En terminologie RBAC, la séparation de tâches devrait vraiment s’appeler séparation de rôles ou depermissions • Cependant la terminologie ‘séparation de tâches’ est bien établie dans la théorie des organisations

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

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

47. 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

48. 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

49. 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

50. 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