Télécharger la présentation
La présentation est en train de télécharger. S'il vous plaît, attendez
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
Présentations similaires
© 2024 SlidePlayer.fr Inc.
All rights reserved.