rbac role based access control

RBACRole Based Access Control

1

[email protected]

Problèmes avec MAC et DAC

La plupart des modèles MAC sont basés sur des très fortes structurations hiérarchiques des usagers et de ressources, qui peuvent être trouvées seulement dans des organisations particulièresCW est un modèle pensé essentiellement pour un seul problèmeACM et DAC sont de gestion difficile car chaque usager est un cas individuel

Considérez des cies de milliers d’employés

DAC suppose que les usagers sont propriétaires des ressources et peuvent transférer les droits sur elles,

Tandis que normalement c’est l’organisation qui est propriétaire des ressources, et veut en retenir le contrôle

2

3

Concept de “Groupe”

La gestion des politiques et des membres des organisations peut être facilitée par l’introduction de politiques par ‘groupes’P.ex. le gérant du système crée un groupe ‘programmeurs qui participent au projet X’ et octroie des permissions à ce groupe

Group-based access control

Ceci se fait, mais la gestion est encore difficile car le gérant de la sécurité a la responsabilité de créer et gérer les groupes

Concept de Rôle

RBAC est basé sur deux points:Le fait que dans les organisations les employés sont classés par rôles

• Comptable, programmeur, docteur, infirmière, technicien …

Le fait que chaque employé, pour exécuter son rôle, a besoin de certaines ‘permissions’

• Notion de ‘besoin de savoir’

4

5

Concept organisationnel de ‘Rôle’

Le concept de rôle existe dans presque toute organisationLes personnes qui appartiennent à un rôle ont plusieurs propriétés en commun:

Responsabilités,échelles salariales …

À l’UQO: étudiants, professeurs, techniciens …Dans un hôpital: patients, docteurs, personnel d’administration, etc. L’affectation d’un usager à un rôle est un acte officiel qui a beaucoup de conséquences dans l’organisation

Exemple de hiérarchie de rôles

6

http://infolib.lotus.com/resources/portal/8.0.0/doc/fr/PT800ACD002/security/sec_roles.htmlIBM Corporation, LOTUS DocumentationConsulter cette page pour voir les permissions de chaque rôle dans cet exemple

http://infolib.lotus.com/resources/portal/8.0.0/doc/fr/PT800ACD002/security/sec_roles.html

Moodle et Microsoft Exchange

Deux logiciels qui apparemment utilisent les concepts de RBAC et vous pourriez vous amuser à les essayer

7

Moodle

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

8

9

RBACRBAC profite de cette notion organisationnelle de rôle pour associer des permissions de sécurité aux différents rôles Le rôle devient un mécanisme pour associer des permissions aux usagers

Parfois on trouve des définitions de rôles comme groupes ou ensembles d’usagers, mais cette définition n’est pas conforme à la norme RBAC

RBAC: 1er modèle conceptuel

10

Usagers Rôles Permissions

Rôle 1

Rôle 2

Rôle 3

Cette affectatonpeut changer souvent

Cette affectatonne change pas souvent

opération

Exemple plus concret

11Ferraiolo, RBAC

Simplification apportée par RBAC

RBAC simplifie la gestion du contrôle d’accès car les permissions sont déterminés en fonction des rôles et cette association ne change pas souvent

12

Usagers, sujets, sessions, rôles

Du point de vue formel, un rôle n’est qu’un nom qui identifie un ensemble de permissions

Les rôles sont affectés aux usagers, mais afin qu’un usager puisse les utiliser, il doit activer des sujets dans des sessionsUn 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 loginUn sujet peut se trouver dans plusieurs sessions simultanément

13

Usager, sujet, rôle

14L’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)

Continus: Vision entreprise, statique

Pointillés: Vision système, dynamique

Session

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

15

Permissions (ou ‘privilèges)

Formellement, les permissions sont des paires (opération, objet)Les opérations et les objets sont des entités génériques

Lire, écrire, mettre à jour etc. un fichier ou base de données

Utiliser un ordi

Entrer dans une salle

Recevoir un salaire

…

16

‘Core’ RBAC RBAC de base ou plat

17

RBAC de base Core RBAC ou RBAC plat

18

user_sessions session_roles

(UA)User Assign-

ment

(PA)PermissionAssignment

USERS OBSOPS

SESSIONS

ROLES

PRMS

Usagers, sujets et sessions

‘Sujet’ n’est pas mentionné dans ce diagrammeIl est mentionné implicitement car les usagers deviennent des sujets en amorçant des sessions

19


(UA)User Assign-

ment


USERS OBSOPS

SESSIONS

ROLES

PRMS

Fonctions pour RBAC de base (core RBAC)

assigned_users(role): retourne l’ensemble d’usagers affectés à un rôle donnéassigned_permissions(role): l’ensemble des permission pour le rôlesession_users(session): l’usager correspondant à une sessionsession_roles(session): l’ensemble de roles pour une sessionavail_session_perms(session): permissions disponibles à un usager dans une session

20

21

USERS, ROLES, OPS, and OBS (users, roles, operations, and objects, respectively).

UA ⊆ USERS × ROLES, a many-to-many mapping between users and roles (user-to-role assignment relation).

assigned_users: (r:ROLES) → 2USERS, the mapping of role r onto a set of users. Formally: assigned_users(r) = {u ∈ USERS (∣ u,r) ∈ UA}

PRMS = 2(OPS × OBS), the set of permissions.

PA ⊆ PRMS × ROLES, a many-to-many mapping between permissions and roles (role-permission assignment relation).

assigned_permissions(r: ROLES) →2PRMS, the mapping of role r onto a set of permissions. Formally: assigned_permissions(r) = {p ∈ PRMS|(p,r) ∈ PA}.

SUBJECTS, the set of subjects.

subject_user(s: SUBJECTS) → USERS, the mapping of subject s onto the subject's associated user.

subject_roles(s:SUBJECTS) →2ROLES, the mapping of subject s onto a set of roles. Formally: subject_roles(si) {⊆ r ∈ ROLES|(subject_user(si),r) ∈ UA}

Modèle formel (source: Ferraiolo, RBAC)

Exercice

Expliquer pourquoi les rôles sont définis comme primitifs. Pourquoi on ne dit pas:

Qu’un rôle est un ensemble de sujetsQu’un rôle est un ensemble de permissions

Les raisons sont pratiques, et essentiellement les mêmes dans les deux cas

22

RBAC Hiérarchique

23

RBAC HiérarchiqueDans les organisations, il y a normalement des hiérarchies de rôles, et les patrons ont plus de pouvoir que les subordonnés

Ils héritent leurs permissions

24

Comptable 1

Chef salaires

Comptable 2

Directeur de comptabilité

Comptable 3

Cheef facturation

Comptable 4

Le directeur des salaires hérite les permissions des comptables 1 et 2, et le Directeur de la comptabilité hérite les permissions des deux directeurs

Si Comptable1 a une permission, alors le Chef Salaire et le Directeur de Comptabilité l’ont aussi

Simplification apportée par le concept de hiérarchie

Pour un rôle en haut de la hiérarchie, il suffit de spécifier de quels rôles il hériteSans devoir spécifier la liste complète des permissions hérités

25

Chef subventions: Fichier 6 3

Directeur comptabilité

Chef salaires: Ficher 5

Comptable 1F1, imprimante

Comptable 2: F1, F2,

ImprimanteComptable 3: F4

Héritent de leurs subordonnés

Hérite de tous

RBAC Hiérarchique

26

(UA)User Assign-

ment

(RH)(RH)Role HierarchyRole Hierarchy



USERS OBSOPS

SESSIONS

ROLES

PRMS

HiérarchieLa hiérarchie doit être un ordre partiel

Pas nécessairement un arbrePas nécessairement un treillis

Les rôles inférieurs s’appellent ‘junior’ et les supérieurs ‘senior’‘Comptable1’ est junior de ‘Chef salaires’‘Chef salaires’ est senior de ‘Comptable1’ et junior de ‘Directeur de comptabilité’

On utilise aussi ≤ pour ‘junior’≥ pour ‘senior’

27

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’

28

Diagramme UML pour RBAC

29Source: Ahn and Shin: Role-Based Authorization Constraints …

Exemples de hiérarchies de rôles 1

30

Professionnel de santé

Docteur

Docteur de famille Docteur Spécialiste

Ce transparent et les suivants: notes de cours de R. Sandhu

Les hiérarchies de rôles ne sont pas nécessairement des arbres

Exemple de hiérarchie de roles 2

31

Ingénieur

Ingénieur Matériel Ingénieur Logiciel

Ingénieur en chef

Héritage multiple: l’ingénieur en chef hérite de deux côtés

Roles spéciaux

32

Ingénieur

Ingénieur Matériel Ingénieur Logiciel

Directeur d’ingénierieIngénieurMatériel 1

Un pb avec RBAC est qu’on définit trop souvent des rôles spéciaux, parfois pour des cas individuels, et ils compliquent la structure des rôles

Partitions dans la hiérarchie

33

Département d’ingénierie

Chef de projet 1

Ingénieur

Production Qualité

Directeur

Chef de projet 2

Ingénieur

Production Qualité

PROJET 2PROJET 1

Employé

Hiérarchies générales ou limitées

Les hiérarchies limitées sont des arbresAucun sujet ne peut avoir plus d’un rôle seniorCeci est très contraignant dans une organisation, mais facilite le calcul de l’héritage

• Revoir les exemples précédents qui sont presque tous des hiérarchies générales

34

Groupes, roles et héritage

35Ferraiolo et al. p. 76

On peut affecter des groupes à des rôlesCeci peut être utile, mais peut aussi être source de confusion si les roles et les groupes sont administrés séparemment

Utilisation combinée d’héritage d’usagers et permissions (=privilèges)

36

Les rôles vers l’haut sont ceux qui contiennent « le plus grand nombre de privilèges et le plus petit nombre d’usagers »

Les permissions de U3 sont: P4, P5, P8, P9, P10, P1,_P2, P3.Ferraiolo et al. p. 77

Fonctions pour RBAC hiérarchique

Sont essentiellement les mêmes que pour RBAC de base, mais il faut tenir compte qu’un usager peut avoir une permission par effet d’une hiérarchie

37

Avantages de RBAC hiérarchique

Permet de réduire le nombre de permissions explicitesPermet de construire une hiérarchie de rôles cohérente à l’organisation au lieu d’avoir une quantité de rôles indépendants Facilite le travail de l’administrateur si la hiérarchie est stable

Une seule décision à un niveau élevé a des conséquences aux niveaux inférieurs

38

Mais attentionSouvent la hiérarchie de rôles organisationnels ne correspond pas à la hiérarchie d’héritage de permissions

Ex 1: un directeur de banque n’aura normalement pas l’union de toutes les permissions de tous les employés

• Il lui pourrait être nié de lire les transactions des usagers, etc.

Ex2: dans un hôpital un infirmier et un docteur appartiennent à deux hiérarchies différentes, cependant le docteur a droit de lire tous les dossiers de l’infirmierAussi normalement les hiérarchies d’héritage sont beaucoup moins profondes

39

RBAC avec contraintes

40

Types de contraintes

Séparation de tâches (separation of duties)

Exemple: Celui qui approuve un cheque ne peut pas être celui qui le signe

Contraintes temporellesUn docteur ne peut être admis en salle d’opération que entre 8:00 et 18:00

Autres: vaste éventail de possibilitésAucun usager ne peut avoir plus de 5 rolesAucun groupe de moins de 3 usagers ne peut couvrir toutes les permissions existantes dans un département

41

Exemple pratique

Separation of DutiesI.Disbursement of FundsII.The following minimum separation of duties applies to individuals in departments and accounting offices who are responsible for the disbursement of funds.III.The following duties shall be performed by different individuals:

I. Check request reviewer—evaluates requests with respect to business purpose, applicable policy, backup documentation, and authorized signature.

II. Check preparer—prepares checks and ledger entries.III. Check issuer—has checks signed and approves ledger entry.IV. Check deliverer—distributes checks or sends to payees.V. Ledger reviewer—reconciles bank statement with general ledger cash

account.IV.Depository FundsV.The following minimum separation of duties applies to individuals in departments and accounting offices who are responsible for depository funds.VI.The following duties shall be performed by different individuals:

I. Mail handler—opens mail, reviews, and endorses checks.II. Cashier—processes cash, determines account coding, and deposits in

bank account or delivers to another cashier.III. Auditor—ensures that all checks received are deposited and accounts

coded correctly; also receives checks returned to the office.IV. Ledger reviewer—reconciles department accounting records with

accounting office records.

42Ferraiolo et al., RBAC

Représentation possible(exemple plus simple)

43

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

44

Différents types de RBAC

RBAC0BASIC RBAC

RBAC3 ou SymétriqueROLE HIERARCHIES +

CONSTRAINTS

RBAC1ROLE

HIERARCHIES

RBAC2CONSTRAINTS

Ravi Sandhu

Différents types de contraintes

46

(UA)User Assign-

ment

(RH)(RH)Role HierarchyRole Hierarchy



USERS OBSOPS

SESSIONS

ROLES

PRMS

ContraintesS

Article Ahn and Shin: Role-Based Authorization Constraints …

Exemples de contraintes 1

Reliées à la séparation de tâchesNe pas affecter à un usager des rôles en conflit (séparation de tâches, SOD)Ne pas affecter à un rôle des permissions en conflitDes usagers en conflit d’intérêt ne peuvent pas être affectés au même rôleDes rôles en conflit ne peuvent pas être activés dans la même session

47


PréréquisUn usager peut être affecté à un rôle seulement si l’usager est déjà membre d’un autre rôleUn role peut avoir une permission seulement s’il a déjà une autre permission

48


CardinalitéNe pas avoir plus (ou moins) de N usagers pour tel rôleUn usager ne peut pas avoir plus de N sessions actives en même tempsUne permission doit être donnée à au moins N roles

49

Et puis …

Il n’y a aucune limite aux contraintes qui peuvent être nécessaires dans des situations pratiquesP.ex. Muraille de Chine: il y a là une contrainte qui est déterminée par l’histoire:

Les lectures-écritures effectuées avant déterminent les accès permis dans le futurNoter la différence avec RBAC où on parle de permissions déjà reçues

Cependant la documentation RBAC mentionne seulement les contraintes que nous avons spécifiées avant

autres types de contraintes ont fait l’objet d’extensions de RBAC

50

Séparation de tâches simple et hiérarchique

Simple, directe: Les deux tâches en séparation ne peuvent pas être affectées à un seul rôleHiérarchique: Un usager ne peut pas acquérir la permission pour deux tâches en séparation ni directement ni par effet d’héritage

Dans un système complexe, ceci est difficile à vérifier

51

Commandes pour Séparation de tâches

(Ssd Static separation of duties)Ssd Role Sets: retourne la liste de tous les ensembles de rôles qui ne peuvent pas être assignés ensemble au même usagerSsdRoleSet Cardinality: retourne la cardinalité d’un ensemble de SSD

52

Comment implémenter les contraintes?

Dans l’administration du systèmeLes outils d’administration empêchent la création de certaines situations

• P.ex. si l’administrateur cherche à créer une situation défendue, l’outil l’avertit ou empêche que la situation soit créée

• On pense ici à une séquence de décisions de l’admin,

Détection par vérification (audit)Des outils spécialisés contrôlent le système pour voir que certaines situations n’existent pas

• Le système entier est contrôlé périodiquement• Si des situations défendues existent, des diagnostiques sont affichées et l’administrateur devra

corriger la situation

Au moment de la prise de décisionP.ex. au moment où un sujet demande d’émettre un cheque, le système contrôle qu’il n’est pas le même sujet qui vient de l’autoriser

• S’il l’est, il bloque la transaction• Ou l’enregistre dans un fichier qui sera vérifié plus tard

53

Histoire de décisions de l’admin

Mercredi: l’admin crée les rôles comptables et contrôleur, ils sont indépendants Jeudi : l’admin donne au rôle comptable la permission d’émettre des chèquesJeudi: l’admin donne au rôle contrôleur la permission de contrôler les chèquesVendredi: l’adm décide que Alice a les deux rôles

?

Il y a malheureusement plusieurs manières pour arriver à une situation de conflit

54

Statique et dynamique

Statique (SSD):La tâche de signer les chèques est incompatible en principe avec la tâche de les approuver

Dynamique (DSD):Un usager ne peut pas avoir deux sessions actives avec deux tâches en conflit d’intérêt

• P.ex. aucun employé de banque ne peut avoir deux session actives pour deux clients différents

55

Contraintes statiques et dynamiques

Les contraintes dynamiques sont celles qui ne peuvent être contrôlées qu’au moment de la prise de décision

P.ex. un cheque ne peut pas être émis et contrôlé par le même sujet, mais les sujets affectés aux deux permissions peuvent changer dans le tempsSeulement la dernière des méthodes mentionnées est appropriée dans ce cas

56

SSD et DSD définitions

SSD - Statique: Étant donné un ensemble de rôles en conflit, aucun usager ne peut avoir plus de n rôles dans cet ensemble

• Cas simple: n=1 (n déterminé en fonction des besoins)

DSD - DynamiquePareil, mais: aucun ensemble de sujets pour un même usager ne peut avoir simultanément plus de n rôles dans un ensemble de rôles en conflit

57

RBAC Symétrique

C’est le RBAC avec hiérarchies de rôles et contraintes

Aussi appélé RBAC-3

58

Difficultés pour le contrôle statique

P. ex. considérez le cas où un sujet reçoit deux permissions en conflit par l’entremise de rôles à différents niveaux hiérarchiquePlusieurs niveaux hiérarchiques peuvent être entre les deux rôles

Il peut être difficile de trouver tous les cas comme ça dans une grande organisationConsidérez le cas de nouveaux rôles qui peuvent être créés et qui héritent les autorisations des rôles subordonnés

59

Role qui permet d’émettre des chèques

Role qui permet le contrôle des chèques

Sujet

Outils de vérification statiques

(audit)Des outils industriels existent, pour permettre de vérifier si un ensemble d’affectation rôles et permissions satisfait à un ensemble de contraintes, p.ex.

Y a-t-il un rôle avec moins de 5 usagers?Y a-t-il un usager qui a plus de 5 rôles?Y a-t-il un sujet qui a toutes les permissions A,B,C?

Ces outils affichent des diagnostiques qui pourront être utilisés pour nettoyer le systèmeÀ discuter plus tard

60

Difficultés pour le contrôle dynamique

RBAC avec héritage *et* contraintes dynamiques est difficile à implémenter de manière correcteLes contraintes dynamiques introduisent des politiques négatives

Dans le reste de RBAC, il n’y a que des politiques positives

61

Difficultés pratiques

Il y a beaucoup de cas pratiques qui peuvent conduire à la violation de contraintes de manière dynamique

Surtout liés à la nature dynamique du travail dans les organisations

Alice est affectée au rôle de contrôleur de chèquesBen les signeOn demande à Alice de remplacer temporairement le chef de Ben, elle obtient ses permissions

Alice peut et ne peut pas signer les chèques

On trouve aussi des cas beaucoup plus difficiles à détecter

62

Exercice

Comment spécifier la contrainte suivante:Un docteur ne peut ordonner des médicaments pour lui-mêmeEst-ce une contrainte statique, dynamique?

63

RBAC dans la Toile

64

RBAC dans la Toile

Dans la Toile, nous avons trois éléments de base:ClientServeur WebServeur de Rôles

Un client se connecte à un serveur web via un navigateur web Le serveur de rôles est maintenu par un administrateur qui affecte des utilisateurs à des rôles au sein d’un domaineOn peut identifier deux architectures possibles:

User-pullServer-pull

65

Architecture User-Pull

L’usager récupère les informations concernant son rôle du serveur de rôle et il les présente au serveur web 66

HTTP

Architecture Server-Pull

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

67

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)

68

Comparaison

69

Park, Ahn, Sandhu: Role-Based Access Control on the Web using LDAP, 2001

Flux de données

70

Différence importante MAC-RBAC

Les méthodes MAC se préoccupent surtout de contrôler le flux de données

Direct ou indirect

RBAC et les autres méthodes que nous verrons dorénavant se préoccupent surtout du contrôle d’accès

Elles peuvent contrôler l’accès aux informations comme à autres entités, p.ex. locaux ou outilsElles n’ont pas des mécanismes spécifiques pour le contrôle de flux

71

Flux de données dans RBAC

On peut avoir du partage de données dans deux manières fondamentales:

Par héritagePermissions partagées

• P.ex. dans un hôpital les docteurs et les infirmières appartiennent à des hiérarchies différentes

– Mais ils peuvent partager la permission de lire les dossiers des patients

72

Difficultés pratiques

Dans RBAC il est facile d’avoir des transferts de données entre rôles à travers des ‘canaux indirects’

Alice: son rôle lui permet d’écrire dans fichier F1Bob: lire F1, écrire F2Charline: lire F2

• Charline peut recevoir une copie de F1 par l’entremise de Bob

Il est théoriquement possible d’établir toutes ces possibilités, mais ceci n’est pas pratique s’il y a:Grand nombre de rôles Héritages complexesAffectation de rôles qui peuvent changer fréquemment

Donc dans RBAC un usager ne peut pas avoir contrôle sur ses informations et en pratique ceci peut aussi être très difficile pour l’administrateur, s’il y a des héritages et partages de permissions complexes

73

Méthodes pour contrôler le flux

Des méthodes ont été inventées pour pallier à ces possibilitésP.ex. on peut créer des hiérarchies de rôles sur le modèle de MACÀ voir plus tard …

74

Administration de RBAC et

Rôles administatifs

75

76

Administration de RBAC

L’utilisation de RBAC dans une entreprise doit être administrée. Les administrateurs doivent déterminer

Quels sont les rôles possibles dans une entreprise donnéeQuelles sont les permissions associées à chaque rôleQuelle est la hiérarchie des rôlesComment différents usagers peuvent devenir associés à différents rôlesQuelles sont les contraintes à respecter

On ajoute donc les concepts deRôles administratifsPermissions administratives

77

Rôles et permissions administratifs

Source: Ferraiolo et al. Chap.9

Roles usagers

Roles administratifs

78

Roles admin dans une organisation

Administrateurs de rôles pour toute l’organisationAdministrateurs de rôles pour un département donnéAdministrateurs de rôles pour un projet donné

Commandes administratives pour RBAC de base

(dans la norme ANSI-INCIT)Add UserDelete UserAdd RoleDelete RoleAssign User (à un rôle)Deassign UserGrant Permission (à un rôle)Revoke PermissionCreate Session (pour un usager)Delete Session

79

Opérations sur les hiérarchies de rôles

Ajouter une relation de séniorité entre rôlesRetirer une relation de séniorité entre rôles

Ces deux opérations doivent être exécutées avec la plus grande attention car elles peuvent impliquer un grand nombre de sujets et un grand nombre de permissions

80

Commandes administratives pour RBAC hiérarchique

Add Inheritance: établit un héritage entre deux rôles existants; valide seulement à certaines conditions

Clairement, on ne peut pas permettre qu’il crée un cycle dans l’héritage, aussi il faut considérer si on veut que la hiérarchie soit arborescente (=limitée)

Delete InheritanceAdd Ascendant: crée un nouveau rôle et l’insèreAdd Descendant

81

Commandes admin avec SD

Separation of Duties: SSD Static, DSD Dynamic

Create SSD setDelete SSD setAdd SSD Role MemberDelete SSD Role MemberSet SSD Set Cardinality

+ Semblables pour Dynamic SD

82

Conclusions sur RBAC

83

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

84

Avantages de RBAC

Comme déjà dit, les avantages de RBAC sont nombreux et surtout il établit une relation stable entre

la sécurité des données la structure d’une organisationles tâches dans une organisation

85

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

86

Limites de RBAC 2

Let's say that there are two organizations within a single company called A and BEach company has its own set of data, DataSetA and DataSetBThere are roles Employee and ManagerEmployees can view data from their own organizationManagers can edit data from their own organization and view data from the other organization (i.e. company-wide)I cannot find a way to implement this in a RBAC system without creating roles such as ReadDataSetA and EditDataSetA. Approaches that require this many roles are too cumbersome since there will be hundreds of organizations and companies.

(citation trouvée dans WWW)

87

Limites de RBAC 3

Bien que RBAC ait été créé pour simplifier la spécification de politiques, en pratique

Pour spécifier des cas comme les précédents Et aussi pour spécifier toutes les exceptions, cas particulier, etc.Il est normal de trouver des systèmes RBAC avec des milliers de rôles et politiquesDes autres organisations se contentent d’identifier seulement un petit nombre de rôles, et le reste échappe à RBAC

• Ce qui est contre-productif

88

Résultats théoriques

RBAC peut être configuré pour produire des résultats équivalents à MAC ou DAC

Il faut utiliser le modèle admin de RBAC pour pouvoir changer les autorisations comme on peut faire dans DAC

Mais le modèle DAC style HRU peut à son tour être configuré pour obtenir les résultats de RBACCes résultats ne disent rien sur l’expressivité des différentes techniques

Pour des exigences spécifiques, un de RBAC ou DAC pourrait être plus simple à utiliser que l’autreAussi, si RBAC est utilisé pour obtenir les résultats de MAC, il est nécessaire d’ajouter des mécanismes pour assurer l’aspect ‘obligatoire’ de MAC

89

Principales Ressources utilisées (merci!)

G.-J. Ahn, M.E. Shin: Role-Based Authorization Constraints Specification Using Object Constraint Language. Enabling Technologies: Infrastructure for Collaborative Enterprises, 2001. WET ICE 2001. Proceedings. Tenth IEEE International Workshops on, 157-162.D.F. Ferraiolo, D.R. Kuhn, R. Chandramouli. Role-Based Access Control, 2nd ed., Artech House, 2007Norme ANSI-INCIT pour RBAC (disponible dans Moodle)J.S. Park, R. Sandhu, RBAC on the Web by Smart Certificates, RBAC '99 Proceedings of the fourth ACM workshop on Role-based access control, 1-9.R. Sandhu, Diapositives dans son site web

90

Quelques champions …

91

D. Richard (Rick) KuhnUn des inventeurs de RBAC

Ravi SandhuAuteur de travaux fondamentaux sur RBAC

rbac role based access control

Documents