La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

RBAC Role Based Access Control 1

Présentations similaires


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

1 RBAC Role Based Access Control 1

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 demployés DAC suppose que les usagers sont propriétaires des ressources et peuvent transférer les droits sur elles, Tandis que normalement cest lorganisation qui est propriétaire des ressources, et veut en retenir le contrôle 2

3 3 Concept de Groupe La gestion des politiques et des membres des organisations peut être facilitée par lintroduction 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 4

5 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 … À lUQO: étudiants, professeurs, techniciens … Dans un hôpital: patients, docteurs, personnel dadministration, etc. Laffectation dun usager à un rôle est un acte officiel qui a beaucoup de conséquences dans lorganisation

6 Exemple de hiérarchie de rôles 6 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 7

8 Moodle Apparemment, Moodle utilise aussi RBAC Exercice: Étudier limplémentation de RBAC dans Moodle 8

9 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 dusagers, mais cette définition nest pas conforme à la norme RBAC

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

11 Exemple plus concret 11 Ferraiolo, RBAC

12 Simplification apportée par RBAC RBAC simplifie la gestion du contrôle daccès car les permissions sont déterminés en fonction des rôles et cette association ne change pas souvent 12

13 Usagers, sujets, sessions, rôles Du point de vue formel, un rôle nest quun nom qui identifie un ensemble de permissions Les rôles sont affectés aux usagers, mais afin quun 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 13

14 Usager, sujet, rôle 14 Lusager u1 peut effectuer lopération op2 lobjet 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

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: Lensemble de rôles dun sujet doit être inclus dans lensemble de rôles de lusager auquel le sujet appartient 15

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

17 RBAC de base Core RBAC ou RBAC plat 17 user_sessionssession_roles (UA) User Assign- ment (PA) Permission Assignment USERSOBSOPS SESSIONS ROLES PRMS

18 Usagers, sujets et sessions Sujet nest pas mentionné dans ce diagramme Il est mentionné implicitement car les usagers deviennent des sujets en amorçant des sessions 18

19 Fonctions pour RBAC de base (core RBAC) assigned_users(role): retourne lensemble dusagers affectés à un rôle donné assigned_permissions(role): lensemble des permission pour le rôle session_users(session): lusager correspondant à une session session_roles(session): lensemble de roles pour une session avail_session_perms(session): permissions disponibles à un usager dans une session 19

20 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 ) 2 USERS, 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 ) 2 PRMS, 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 ) 2 ROLES, the mapping of subject s onto a set of roles. Formally: subject_roles ( s i ) { r ROLES |( subject_user ( s i ), r ) UA } Modèle formel (source: Ferraiolo, RBAC)

21 RBAC Hiérarchique 21

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

24 RBAC Hiérarchique 24 (UA) User Assign- ment (RH) Role Hierarchy user_sessionssession_roles (PA) Permission Assignment USERSOBSOPS SESSIONS ROLES PRMS

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

26 Types dhéritage Héritage dusager (UI): Tous les usagers autorisés à un role r sont aussi autorisés à un rôle r tel que rr Héritage de permission (PI) Un rôle r a toutes les permissions dun rôle r, si rr Héritage dactivation (AI) Dans une activation de session, un sujet qui a un rôle r aura automatiquement un rôle r tel que rr 26

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

28 Exemples de hiérarchies de rôles 1 28 Professionnel de santé Docteur Docteur de familleDocteur 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

29 Exemple de hiérarchie de roles 2 29 Ingénieur Ingénieur Matériel Ingénieur Logiciel Ingénieur en chef Héritage multiple: lingénieur en chef hérite de deux côtés

30 Roles spéciaux 30 Ingénieur Ingénieur MatérielIngénieur Logiciel Directeur dingénierie Ingénieur Matériel 1 Un pb avec RBAC est quon 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 31 Département dingénierie Chef de projet 1 Ingénieur ProductionQualité Directeur Chef de projet 2 Ingénieur ProductionQualité PROJET 2PROJET 1 Employé

32 Hiérarchies générales ou limitées Les hiérarchies limitées sont des arbres Aucun sujet ne peut avoir plus dun rôle senior Ceci est très contraignant dans une organisation, mais facilite le calcul de lhéritage Revoir les exemples précédents qui sont presque tous des hiérarchies générales 32

33 Groupes, roles et héritage 33 Ferraiolo et al. p. 76 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

34 Utilisation combinée dhéritage dusagers et permissions (=privilèges) 34 Les rôles vers lhaut sont ceux qui contiennent « le plus grand nombre de privilèges et le plus petit nombre dusagers » 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 quun usager peut avoir une permission par effet dune hiérarchie 35

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 à lorganisation au lieu davoir une quantité de rôles indépendants Facilite le travail de ladministrateur si la hiérarchie est stable Une seule décision à un niveau élevé a des conséquences aux niveaux inférieurs 36

37 Mais attention Souvent la hiérarchie de rôles organisationnels ne correspond pas à la hiérarchie dhéritage de permissions Ex 1: un directeur de banque naura normalement pas lunion 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 linfirmier Aussi normalement les hiérarchies dhéritage sont beaucoup moins profondes 37

38 RBAC avec contraintes 38

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

40 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 reviewerevaluates requests with respect to business purpose, applicable policy, backup documentation, and authorized signature. II.Check preparerprepares checks and ledger entries. III.Check issuerhas checks signed and approves ledger entry. IV.Check delivererdistributes checks or sends to payees. V.Ledger reviewerreconciles 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 handleropens mail, reviews, and endorses checks. II.Cashierprocesses cash, determines account coding, and deposits in bank account or delivers to another cashier. III.Auditorensures that all checks received are deposited and accounts coded correctly; also receives checks returned to the office. IV.Ledger reviewerreconciles department accounting records with accounting office records. 40 Ferraiolo et al., RBAC

41 Représentation possible (exemple plus simple) 41

42 Tâches et permissions En terminologie RBAC, la séparation de tâches devrait vraiment sappeler 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

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

44 Différents types de contraintes 44 (UA) User Assign- ment(RH) Role Hierarchy user_sessionssession_roles (PA) Permission Assignment USERSOBSOPS 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 dinté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 45

46 Exemples de contraintes 2 Préréquis Un usager peut être affecté à un rôle seulement si lusager est déjà membre dun autre rôle Un role peut avoir une permission seulement sil a déjà une autre permission 46

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 47

48 Et puis … Il ny 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 lhistoire: 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 lobjet dextensions de RBAC 48

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 dhéritage Dans un système complexe, ceci est difficile à vérifier 49

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é dun ensemble de SSD 50

51 Comment implémenter les contraintes? Dans ladministration du système Les outils dadministration empêchent la création de certaines situations P.ex. si ladministrateur cherche à créer une situation défendue, loutil lavertit ou empêche que la situation soit créée On pense ici à une séquence de décisions de ladmin, Détection par vérification (audit) Des outils spécialisés contrôlent le système pour voir que certaines situations nexistent pas Le système entier est contrôlé périodiquement Si des situations défendues existent, des diagnostiques sont affichées et ladministrateur 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 quil nest pas le même sujet qui vient de lautoriser Sil lest, il bloque la transaction Ou lenregistre dans un fichier qui sera vérifié plus tard 51

52 Histoire de décisions de ladmin Mercredi: ladmin crée les rôles comptables et contrôleur, ils sont indépendants Jeudi : ladmin donne au rôle comptable la permission démettre des chèques Jeudi: ladmin donne au rôle contrôleur la permission de contrôler les chèques Vendredi: ladm décide que Alice a les deux rôles ? Il y a malheureusement plusieurs manières pour arriver à une situation de conflit 52

53 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 dintérêt P.ex. aucun employé de banque ne peut avoir deux session actives pour deux clients différents 53

54 Contraintes statiques et dynamiques Les contraintes dynamiques sont celles qui ne peuvent être contrôlées quau 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 54

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

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

57 Difficultés pour le contrôle statique P. ex. considérez le cas où un sujet reçoit deux permissions en conflit par lentremise 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 57 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 daffectation 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

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 ny a que des politiques positives 59

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 60

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

62 RBAC dans la Toile 62

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 dun domaine On peut identifier deux architectures possibles: User-pull Server-pull 63

64 Architecture User-Pull Lusager récupère les informations concernant son rôle du serveur de rôle et il les présente au serveur web 64 HTTP

65 Architecture Server-Pull Lusager sidentifie chez le serveur web et ce dernier demande les informations concernant le rôle à ladministrateur 65

66 Utilisation User-pull est plus approprié si le serveur est à lextérieur de lentreprise Le serveur web ne devrait pas connaître le rôle de lusager à lintérieur Park, Sandhu, RBAC on the Web by Smart Certificates, 1999 (les dessins sont pris de cet article) 66

67 Flux de données 67

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 68

69 Difficultés pratiques Dans RBAC il est facile davoir 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 lentremise de Bob Il est théoriquement possible détablir toutes ces possibilités, mais ceci nest pas pratique sil 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 ladministrateur, sil y a des héritages et partages de permissions complexes 69

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

71 Administration de RBAC et Rôles administatifs 71

72 72 Administration de RBAC Lutilisation 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 73 Rôles et permissions administratifs Source: Ferraiolo et al. Chap.9 Roles usagers Roles administratifs

74 74 Roles admin dans une organisation Administrateurs de rôles pour toute lorganisation 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 75

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 quil crée un cycle dans lhé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 linsère Add Descendant 76

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 77

78 Conclusions sur RBAC 78

79 RBAC Norme et implémention RBAC est le sujet dune norme de lANSI-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 lidée de RBAC 79

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 dune organisation les tâches dans une organisation 80

81 Limites de RBAC 1 Pouvez-vous facilement spécifier en RBAC la politique suivante: Un docteur ne peut faire accès quaux dossiers de ses propres patients Pensez-y bien, comment on pourrait le faire et à quels coûts 81

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

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 didentifier seulement un petit nombre de rôles, et le reste échappe à RBAC Ce qui est contre-productif 83

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 lexpressivité des différentes techniques Pour des exigences spécifiques, un de RBAC ou DAC pourrait être plus simple à utiliser que lautre Aussi, si RBAC est utilisé pour obtenir les résultats de MAC, il est nécessaire dajouter des mécanismes pour assurer laspect obligatoire de MAC 84

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, 2 nd 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 85

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


Télécharger ppt "RBAC Role Based Access Control 1"

Présentations similaires


Annonces Google