L’extraction de rôles Role mining Luigi.Logrippo@uqo.ca

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 ACL, 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 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 droit 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 Lorrie 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: 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

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

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 de la 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 ACL 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 Méthode essentiellement exponentielle Faites une recherche web sur ce terme

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 exponentiel: 2P P étant le nombre de permissions Donc il n’est pas pratique dans le cas d’organisations avec des dizaines de milliers de permissions et usagers Cependant il existe des méthodes de complexité plus raisonnable, en général basées sur les statistiques Ces méthodes ne garantissent pas de trouver la solution optimale, mais elles trouvent des bonnes approximations

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 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 pour calculer la ‘distance’ Un grand nombre de méthodes existent dans ce domaine Jaccard, un botaniste, développa sa propre 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 La méthode ne sera pas expliquée, mais elle est expliquée dans des articles www Essentiellement, il s’agit de 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 selon leur proximité dans cette mesure

Distances obtenues selon Jaccard a1=Albert, a2=Bern, etc.

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,66 0,66 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

Complexité La Méthode 1est 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 normalement beaucoup plus efficace Cependant nous venons de voir que le résultat obtenu par la Méthode 2 n’est pas le meilleur possible, La Méthode 2 ne trouve pas certains héritages Donc 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

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

Héritage pour réduire le nombre de règles Une des fonctions de l’héritage est de réduire le nombre de règles explicites Dans l’exemple suivant, observez comment le fait de n’avoir pas trouvé une relation d’héritage possible pour Marie dans le diagramme à droite nous force à introduire une règle spécifique pour Marie règle qui est implicite dans le diagramme à gauche

Exemple +ES Groupement de roles optimal Groupement de roles sub-optimal Imtiaz Imtiaz Gianni, Harry Marie +AP Gianni, Harry Marie +AP +ES Frank Jean Frank Jean Claire, Doron, Ernie CO, AC Albert CH Bern ES Claire, Doron, Ernie CO, AC Albert CH Bern ES Une règle additionnelle pour Marie car nous n’avons pas exploité l’héritage Jean  Marie Les tirets montrent les différences

Mesures de qualité Il y a donc plusieurs critères d’évaluation d’algorithmes qui peuvent être en opposition Les algorithmes qui sont les plus efficaces Les algorithmes qui produisent les plus petits ensembles de rôles Les algorithmes qui produisent le plus petit nombre de règles individuelles On veut obtenir un compromis raisonnable

Autrement dit Un des avantage d’avoir les rôles et les relations d’héritages est de réduire le nombre de 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

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 des 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 VIDE: P1,P2,P3 P1 P2 P3 Alice X Bob Alice: P1,P2 Bob: P2,P3

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 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 Raffiner le modèle de scénario

Exemple pratique développe seulement l’identification des scénarios et des permissions Pour l’exemple complet, voir: Ferraiolo et al., RBAC, 233-237

Identification et modélisation des scénarios d’usage Développer les scénarios – 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

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 passer son cours Ceci n’est ni un role, ni une permission Pour ce faire, il doit Pouvoir faire accès à Moodle Pouvoir y déposer ses travaux … 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 les permissions existantes mais peut arriver à 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 Les rôles connecteurs sont des rôles 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

Conclusion La bonne attribution de rôles et la détermination de la hiérarchie des rôles est une difficulté majeure 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 Ingénierie de rôles: Déterminer les rôles sur la base du fonctionnement de l’organisation et des tâches existantes Ces méthodes doivent être utilisées ensemble pour trouver un bon compromis Dont la grande 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 est souvent révisée …

Références principales Le livre de Ferraiolo et al., déjà mentionné E.J. Coyne, J.M. Davis: Role Engineering. Artech House, 2008. Cherchez dans le www: beaucoup de matériaux

Exemple 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ère, mais avec: 0●1=0; 1●0=0; 0●0=0; 1●1=1 Dans l’exemple précédent, on voit que: (e) = (a) ● (c) (e) = (b) ● (d)