L’extraction de rôles Role mining http://w3.uqo.ca/luigi/INF6153/index.html

Déterminer les rôles Pour maximiser les avantages de RBAC, il est essentiel que les rôles soient bien choisis Ceci est un problème majeur dans l’utilisation pratique de RBAC Un obstacle à l’adoption de RBAC dans plusieurs organisations, surtout les grandes

Comment déterminer les rôles Étant donné une organisation dans laquelle les rôles ne sont pas clairement établis, comment les établir? Deux approches: Extraction de rôles: travailler sur la base des permissions existantes, les ACM, et dériver automatiquement les rôles dont on a besoin Bottom-up Ce processus pourrait conduire à des rôles contre-intuitifs, sur la base d’erreurs ou permissions exceptionnelles Ingénierie des rôles: dériver les rôles sur la base d’une analyse de la structure et du fonctionnement de l’organisation Top-down Procédé manuel Pourrait être difficile à faire quand il y a beaucoup de sujets et permissions Dizaines de milliers … En pratique, les deux approches se complémentent et doivent être utilisées ensemble

Terminologie Extraction de rôles: role mining Ingénierie de rôles: role engineering

Exemple d’extraction de rôles Permissions existantes (ACL) Comp Achat Cheq Estim Appr Albert x Bern Claire Doron Ernie Frank Gianni Lorrie Imtiaz Jean Marie ? Pour simplifier, les croix indiquent des permissions génériques sur des ressources génériques P.ex. Comp pourrait être: Lire F5, écrire F7.

Procédé intuitif Comp Achat Cheq Estim Appr Albert x Bern Claire Doron Ernie Frank Gianni Harry Imtiaz Jean Marie Commencer des rôles qui ont le plus petit nombre de permissions, et bâtir progressivement utilisant l’héritage

Voici un ordre partiel de rôles Imtiaz Ajout explicite:AP COmp AChat CHeq EStim APppr Albert x Bern Claire Doron Ernie Frank Gianni Harry Imtiaz Jean Marie Gianni, Harry Marie +AP Frank Jean Claire, Doron, Ernie CO, AC Albert CH Bern ES

Les rôles et les héritages trouvés Selon le diagramme précédent, il faudrait avoir: un rôle pour les sujets Claire, Doron, Ernie avec permissions CO, AC un rôle pour Albert seul avec la permission CH etc. et aussi il faudrait avoir les héritages montrés par les flèches

On peut le voir comme un treillis v. Diagrammes de Hasse plus tard Imtiaz Gianni, Harry Marie +AP Frank Jean Claire, Doron, Ernie CO, AC Albert CH Bern ES Role vide: aucun sujet, aucune permission: ∅

On peut le transformer dans un arbre hiérarchique Imtiaz Il pourrait y avoir plusieurs manières de le faire. Voici une manière, quelles sont les autres? Gianni, Harry +ES Marie +AP On a dû enlever une arête et ajouter des permissions explicites Frank Jean +CO, AC Claire, Doron, Ernie CO, AC Albert CH Bern ES

Moindre privilège On voit que les rôles obtenus de cette manière respectent automatiquement le principe de ‘moindre privilège’ Si les permissions existantes respectent ce principe

Algorithmes Il y a eu beaucoup de recherche dans ce sujet, et plusieurs algorithmes ont été développés En général, sur des bases statistiques

Méthode banale Créer un rôle par sujet Mais dans ce cas il n’y aura aucun avantage d’utiliser RBAC et nous serons essentiellement dans les listes de facultés Il faudra avoir des règles individuelles pour chaque sujet=rôle Créer des rôles qui groupent plusieurs sujets est déjà une amélioration, une affectation d’une règle à un rôle intéressera plusieurs sujets Utiliser l’héritage permettra normalement de réduire encore les affectations, car une seule affectation peut intéresser tout un sous-arbre

Méthode 1: Diagrammes de Hasse C’est la manière la plus intuitive, construire un diagramme d’inclusion de permissions Méthode que nous avons utilisé au début On commence par la base, qui sont les éléments qui ont moins d’autorisations et on bâtit le diagramme en ajoutant progressivement les éléments qui en ont de plus en plus

Complexité Comme tous les algorithmes qui exigent la partition d’un ensemble dans tous ses sous-ensembles, l’algorithme de la Méthode 1 est en principe exponentiel: 2P P étant le nombre de permissions Donc il pourrait ne pas être pratique dans le cas d’organisations avec des dizaines de milliers de permissions et usagers Cependant la complexité de 2P est atteinte seulement dans des cas extrêmes, qui ne sont pas réalisés dans ces organisations Car dans ces cas les matrices ACL sont très éparpillées

Explication de la complexité Essentiellement, cette méthode fonctionne de la manière suivante: Trouver tous ceux qui ont une seule permission: {CO}, {AC}, {CH}, {ES}, {AP} Trouver tous ceux qui ont deux permissions: {CO,AC}, {CO,CH}, {CO,ES}, {CO,AP}, {AC,CH}, {AC,ES}, etc. … Trouver tous ceux qui ont trois permissions: {CO,AC,CH}, {CO,AC,ES}, etc. …. Etc. pour quatre et cinq permissions … Cet ensemble forme un diagramme de Hasse Donc en principe la méthode est basée sur l’énumération de tous les sous-ensembles de l’ensemble de permissions P qui sont en nombre de 2P 25= 32 dans notre cas mais ça monte de manière exponentielle avec la valeur de P … Évidemment la méthode peut être améliorée mais elle reste de nature exponentielle

Hiérarchies de rôles et treillis Une hiérarchie de rôles n’est pas nécessairement un treillis S’il est désirable qu’elle le soit, il faudra probablement ajouter des rôles fictives, qui pourraient ne pas exister en réalité p.ex. Le rôle de ceux qui ont toutes les permissions Le rôle de ceux qui n’ont aucune permission

Méthode 2: Algorithmes de groupement (clustering) Le groupement (clustering) est une technique statistique qui vise à grouper ensemble les éléments similaires d’un ensemble, en ordre de similarité ou ‘distance’ On compare 2 à 2 tous les éléments, utilisant une ‘mesure de similarité’ dont il y en a plusieures On commence à grouper les éléments les moins distants et on continue faisant des groupes de plus en plus grands quand possible On trouve tout de suite les groupes d’éléments à distance 0: {Claire, Doron, Ernie} et {Gianni, Harry} Puis on trouve des autres groupes d’éléments de moins en moins similaires Jusqu’à ce que tous les éléments sont groupés

Résultat Le groupement donne comme résultat un arbre hiérarchique Le résultat spécifique pourra être différent selon les algorithmes de similarité et des groupement utilisés

Méthodes qui considèrent la ‘distance’ Un grand nombre de méthodes existent dans ce domaine Jaccard, un botaniste, développa une méthode pour calculer la similarité entre plantes étant donné leur caractéristiques Cette méthode peut être utilisée pour calculer la similarité entre permissions de sujets Essentiellement, on commence par comparer deux à deux des entités selon leurs caractéristiques (1, 2, 3 …) et d’établir pour chaque paire d’entités une mesure de similarité Puis un arbre est construit reliant ensemble les entités en considération de: leur proximité dans cette mesure et les inclusions La méthode ne sera pas expliquée, mais elle est expliquée dans des articles www Des programmes sont aussi disponibles

Distances obtenues selon Jaccard Albert Bern Claire Doron Ernie Frank Gianni Harry Imtiaz Jean Marie

Distances obtenues selon Jaccard Albert Bern Claire Doron Ernie Frank Gianni Harry Imtiaz Jean Marie a11 Claire Doron Ernie Frank, Claire, Doron, Ernie Gianni, Harry Frank Imtiaz, Gianni, Harry Imtiaz, Marie Marie, Jean

Arbre obtenu selon la similarité calculée Imtiaz Les chiffres indiquent les distances. Cet arbre considère non seulement la similarité, mais aussi l’inclusion. On voit que nous n’avons pas obtenu tous les liens hiérarchiques 0,2 0,2 Gianni, Harry Marie 0,25 0,25 Frank Jean 0,33 0,67 0,67 Claire, Doron, Ernie Albert Bern Remerciement: A.M. Crétu

Arbre de rôles obtenu Imtiaz L’arbre obtenu doit être complété ajoutant des autorisations explicites Gianni, Harry +ES Marie +AP Frank Jean +CO, AC Claire, Doron, Ernie CO, AC Albert CH Bern ES

Comparaison entre diagramme obtenu avec la première méthode et ce dernier voir plus d’ajouts explicites dans le deuxième

Complexité La Méthode 1 est en principe exponentielle sur le nombre de permissions: 2P La Méthode 2 compare les éléments 2 à 2, sa complexité est polynomiale, N2, où N est le nombre de sujets Normalement N2 << 2P, donc la Méthode 2 est en principe beaucoup plus efficace Cependant nous avons vu que le résultat obtenu par la Méthode 2 pourrait être moins bon que celui obtenu par la méthode 1, La Méthode 2 peut ne pas trouver certains héritages Dans ce cas la Méthode 2 force à affecter explicitement certaines permissions que la Méthode 1 donne par héritage La Méthode 2 peut donc produire plus de règles individuelles que la méthode 1

Point de réflexion Dans notre exemple initial nous avons: N2 = 11x11 = 121 Donc N2 << 2P est faux dans cet exemple! Mais considérez 10 permissions et 10 sujets …

Variété de méthodes Nous venons d’illustrer seulement deux méthodes de base, qui ont été grandement développées, cherchant à rendre les résultats plus utilisables

Mesures de qualité Il y a plusieurs critères d’évaluation d’algorithmes qui peuvent être en opposition Efficacité, rapidité Dizaines de milliers de sujets à considérer Production des plus petits nombres de rôles Production du plus petit nombre d’affectations de permissions individuelles Bonne utilisation des hiérarchies et héritage Production de différentes solutions à évaluer

Héritage pour réduire le nombre d’affectations explicites Comparez encore une fois les deux exemples précédents Ils ont trouvé les même rôles Cependant dans le deuxième on n’a pas utilisé certains héritages donc il a plus d’affectations explicites de permissions

Comparaison entre diagramme obtenu avec la première méthode et ce dernier voir plus d’ajouts explicites dans le deuxième

Autrement dit Un des avantage d’avoir les rôles et les relations d’héritages est de réduire le nombre de rôles et règles Règles = affectations explicites de permissions En général, le plus qu’on a des relations d’héritage, le moins qu’on a de règles individuelles Les méthodes qui trouvent tous les héritages sont inefficaces Donc pour juger de la qualité les autres méthodes d’extraction de rôles on utilise des métriques basées sur Nombre de relations d’héritage: à maximiser Nombre de règles individuelles: à minimiser Efficacité: à maximiser

Reconstitution On devrait pouvoir reconstituer la liste originale de privilèges à partir des affectations des rôles aux sujets et de la liste des privilèges de chaque rôle. Trois rôles sans hiérarchie et affectation d’usagers à plusieurs rôles. Figure de A. Colantonio

Exercice Faire cette vérification pour l’exemple présenté avant

Correspondance avec la structure de l’organisation? Un pb pratique est que les rôles obtenus avec les Méthodes 1 ou 2 pourraient ne pas correspondre aux rôles reconnus dans l’organisation P.ex. il se peut que le sujet ‘Imtiaz’ n’ait pas du tout un rôle important dans l’org Il se trouve seulement à avoir beaucoup d’autorisations … L’ingénierie des rôles peut corriger ce problème, en considération du fonctionnement réel de l’organisation

Le “bruit” Dans une organisation établie, normalement les ACL sont sédimentées dans le temps et mal organisées On aura pu affecter des privilèges à des usagers, parfois temporairement ou en exception, puis oublié Certains usagers peuvent avoir une pluralité de fonctions, donc le regroupement est difficile Des identités apparemment différentes pourraient être le même usager Plusieurs usagers pourraient ne plus exister …

Critères de simplification Enlever les rôles qui ne contiennent pas un minimum de sujets, ou un minimum de ressources Les fusionner avec des autres Enlever les rôles qui n’ont pas été utilisés depuis quelque temps, ou qui se réfèrent à des ressources non-existantes Enlever les rôles qui empêchent une meilleur classification d’un bon nombre d’autres

Nettoyage des données Comme normalement dans l’exploration des données, l’exploration automatique des rôles doit être précédée et accompagnée d’une phase de ‘nettoyage’ manuel En collaboration avec la direction de l’organisation Faut faire attention à quoi on nettoie! Elle doit aussi être accompagnée par un processus de ‘ingéniérie de rôles’ qui tient en compte les besoins réels de l’organisation Pour trouver une hiérarchie de rôles utile en pratique

Cas plus complexes Ici nous avons deux rôles séparés et indépendants Aucun avantage de créer une hiérarchie Perm1 Perm2 Perm3 Alice X Bob

Rôles fictifs Si on désire avoir une seule hiérarchie, on peut créer des rôles fictifs V. rôles connecteurs ci-dessous VIDE: P1,P2,P3 P1 P2 P3 Alice X Bob Alice: P1,P2 Bob: P2,P3

Plusieurs rôles par usager/sujet Nous avons vu le cas où on a un seul rôle par sujet une seule hiérarchie de rôles Parfois il peut être convenable d’avoir plusieurs rôles par sujet sujets appartenant à différentes hiérarchies   P0 P1 P2 P3 S0 X S1 S2 S3

Exemple Considérations:   P0 P1 P2 P3 S0 X S1 S2 S3   Permissions R0 P0  R1 P0,P1 R2 P0,P1,P2 R3 P3 R4 P3,P2 R5 P3,P2,P1   Affectations de rôles S0 R5 S1 R0, R4 S2 R1,R3 S3 R2 Deux hiérarchies Considérations: Nous avons créé plus de rôles (6) qu’il y a de sujets (4)! Cependant ces hiérarchies de rôles pourraient correspondre à la structure de l’organisation on veut que les privilèges d’un rôle senior changent automatiquement quand celles du rôle junior changent

Ingénierie des rôles Elle est basée sur l’analyse des scénarios d’entreprise pour trouver les permissions nécessaires

Approche basée scénarios Source: Ferraiolo, Kuhn, Chandramouli Approche basée scénarios Profil Travail Fonction organisationnelle Ensemble d’activités prévues par la fonction - Suggèrent les Rôles Activités (décrites en UML, p.ex.) Étapes dans les activités Les étapes peuvent demander des Permissions

Étapes principales Identifier et modéliser les scénarios d’usage Dériver les permissions à partir des scénarios Identifier les contraintes Valider: Contrôler que les résultats de chaque étape correspondent aux besoins et pratiques organisationnels, sinon continuer à raffiner les scénarios jusqu’à satisfaction

Exemple pratique développe seulement l’identification des scénarios et des permissions Exemple pris de: Ferraiolo et al., RBAC, 233-237 Voir ces texte pour qqs. explics additionnelles

Identification et modélisation des scénarios d’usage Développer les scénarios à partir de: Collections d’historiques par les experts Journaux de systèmes (system logs) Assigner des noms aux scénarios Valider les scénarios Contrôle par les experts Compiler les scénario

Exemple de scénarios: intent to perform order Notifies Order

Identification d’acteurs et étapes Workflow Scenario Actor Step Frequency lab order with results Intent to perform order—collect specimen Phlebotomist Receives STAT order Collects specimen Prints STAT label Lab tech Process specimen Logs specimen Laboratory system (lab tech, phlebotomoist, and/or pathologist?) Notifies order Notifies

Correspondance entre acteurs et étapes avec identification des opérations Workflow Scenario Actor Step {Operation, Object} Frequency lab order with results Intent to perform order—collect specimen Phlebotomist Receives STAT order {R, Order} {C, Observation} Collects specimen {U, Order} {R, WorkList} Prints STAT label {C, Device} Lab tech Process STAT specimen {U, Observation} Logs specimen Laboratory system (lab tech, phlebotomoist, and/or pathologist?) Notify order Create Read Update Delete Execute

Identification d’objets Les dernières deux colonnes sont les permissions Workflow Scenario Actor Step Operation Object Frequency lab order with results Intent to perform order—collect specimen Phlebotomist Receives STAT order R, C Order, Observation Collects specimen U R Observation, Order, WorkList Prints STAT label Device Lab tech Process specimen Observastion Logs specimen Observation Laboratory system (lab tech, phlebotomoist, and/or pathologist?) Notifies order Order Ce tableau permet aussi d’affecter les permissions aux acteurs=sujets

Raffinement et nettoyage En réalité, les choses ne seront pas si simples … Il y aura des scénarios à raffiner, des scénarios superflus, dupliqués ou incohérents, etc.

Raffinement Les premières étapes de ce processus pourraient ne pas produire des rôles dans le sens propre Un procédé de raffinement est normalement nécessaire Un étudiant doit suivre son cours Ceci n’est ni un rôle, ni une permission spécifique Pour ce faire, il doit Pouvoir faire accès à Moodle Pouvoir y déposer ses travaux Pouvoir faire accès aux salles de cours à certaines heures … Voici que le rôle ‘étudiant’ est bâti prenant en considération les besoins

En pratique … Les deux approches présentées sont complémentaires et doivent être utilisées ensemble par des experts Extraction de rôles (role mining) Ingénierie de rôles (role engineering) L’extraction de rôles se fait sur la base des permissions existantes mais peut trouver des rôles qui ne correspondent pas aux besoins de l’organisation L’ingénierie de rôles prend en compte les processus de l’organisation et peut obtenir les permissions nécessaires pour les tâches existantes Les rôles obtenus passent en utilisation pratique, et il pourrait être nécessaire de les modifier s’il y a des problèmes Ceci est un processus d’amélioration et adaptation continu

Rôles connecteurs Comme déjà vu, les rôles connecteurs sont des rôles fictifs, qui n’existent pas dans l’organisation mais qui sont inventés par l’administrateur de RBAC pour simplifier l’attribution de permissions urologue cardiologue chirurgien médecin Le rôle ‘chirurgien’ aurait pu être créé pour le seul but de lui affecter la permission d’accès aux salles d’opération, qui puis est héritée par urologue et cardio Sans rôle connecteur: deux attributions séparées d’une permission à deux rôles Avec rôle connecteur: la permission est attribuée une seule fois à un seul rôle

Exemple pratique https://github

Étapes (livre de Coyne-Davis: Role Engineering) Définir les permissions Relier les perms aux rôles Prendre en considération les flux des travaux (workflow) Concevoir la structure des rôles (et héritages) Modéliser la structure des rôles Optimiser la structure des rôles Tester en pratique les définitions des rôles Organiser les rôles dans un répertoire

Conclusion La bonne attribution de rôles et la détermination de la hiérarchie des rôles sont des défis majeur dans la mise en œuvre de RBAC et méthodes semblables Deux méthodes principales : Extraction de rôles: role mining Trouver les rôles sur la base des permissions existantes avant RBAC Procédé algorithmique Ingénierie de rôles: Déterminer les rôles sur la base du fonctionnement de l’organisation et des tâches existantes Procédé basé sur l’analyse organisationnelle Ces méthodes doivent être utilisées ensemble pour trouver une bonne solution Dont la difficulté de cette tâche, Qui doit impliquer tant les techniciens de la sécurité, que les administrateurs et les employés de l’organisation Cette activité ne cesse jamais, car la structure de certaines organisations et de leurs tâches sont souvent révisés …

Spécialistes pour RBAC Une organisation utilisant RBAC aura probablement besoin de: Des ingénieurs de rôles, surtout pour planifier l’installation initiale Des administrateurs de RBAC, pour ajouter et retirer des usagers des leur rôles ajouter et retirer des permissions créer et retirer des rôles créer et modifier des hiérarchies Etc. (voir commandes administratives) Des vérificateurs, qui interviendront à fréquences périodiques pour vérifier si le système courant respecte toujours la politique de l’organisation

Logiciels pour RBAC Des logiciels existent pour assister les spécialistes dans toutes les fonctions précédentes

Références principales Le livre de Ferraiolo et al., déjà mentionné E.J. Coyne, J.M. Davis: Role Engineering. Artech House, 2008. RBAC Role Engineering Process, 2004 http://csrc.nist.gov/groups/SNS/rbac/documents/HealthcareRBACTFRoleEngineeringProcessv3.0.pdf Page NIST: http://csrc.nist.gov/groups/SNS/rbac/standards.html Cherchez dans le www: beaucoup de ressources

Exemple d’optimisation de rôles Les différents tableaux dans cet exemple représentent le même ensemble de permissions. Supposons que dans une organisation nous avons les rôles (a) qui sont affectés à des usagers de la manière décrite dans (c). Ceci donne l’affectation de permissions décrite dans (e). À partir de (e) on peut voir que le même ensemble de permissions peut être décrit avec deux rôles seulement, ce qui est représenté dans (b) et (d). S. Hachana, F. Cuppens, N. Cuppens-Boulahia, J. Garcia-Alfaro:Semantic analysis of role mining results and shadowed roles detection. Information Security Technical Report. 17(4) 2013, 131–147

Dans l’exemple précédent, on voit que: Relation entre matrice de rôles, matrice d’affectation de rôles à usagers, et matrice des permissions La multiplication entre matrices booléennes fonctionne comme la multiplication entre matrices régulières, mais avec: 0 x 1 = 0; 1 x 0 = 0; 0 x 0 = 0; 1 x 1 = 1 Dans l’exemple précédent, on voit que: (e) = (a) x (c) (e) = (b) x (d)

Exercice: Persuadez-vous … P.ex. notez que l’usager U4 a, au début, les rôles r1 et r2 et donc les perms p1,p2,p3 Il a ces mêmes perms dans la situation finale, avec seulement le rôle R1

Un fameux problème exponentiel http://www.arm.ac.uk/astropark/hypercube.htm Une graine dans la première case Deux dans la deuxième Quatre dans la quatrième …..