Un outil industriel CA-RCM 1

CA-RCM: Un outil pour RBAC CA Technologies est une grande compagnie dinformatique, son nom était avant Computer Associates RCM Role and Compliance Manager est un outil pour établir des hiérarchies de rôles (extraction de rôles) Il est aussi un outil pour contrôler que lensemble des politiques dans une organisation est conforme à certaines politiques générales Il est important de comprendre que CA-RCM nest pas un outil pour octroyer ou refuser laccès Nest pas un outil de décision (pour le PDP) mais il est un outil dadministration (pour le PAP) 2

Les deux fonctionnalités majeures de CA-RCM Extraction de rôles: Étant donné une liste de contrôle daccès, trouver une structure de rôles qui lui correspond Vérification de politiques: Étant donné un ensemble de politiques, déterminer sil est conforme à certains principes (meta-politiques) 3

Extraction de rôles avec CA-RCM CA-RCM utilise les listes de contrôle daccès dune organisation et il cherche à organiser les permissions dans des hiérarchies de rôles La méthode est en principe semblable à celle que nous avons vu dans le chapitre: Extraction de rôles Les algorithmes de CA-RCM sont très efficaces CA détient un brevet qui contient la description des algorithmes mais ces derniers sont de difficile compréhension 4

CA-RCM comme outil de vérification ou audit Une organisation pourrait avoir certains principes pour ladministration des politiques, p.ex.: Il ne devrait pas être permis davoir tant le rôle X que le rôle Y (séparation de tâches) Les employés junior ne devraient pas pouvoir accéder aux données finances Tout rôle devrait avoir au moins 5 sujets et moins de 21 … nous verrons plusieurs exemples Ces dernières politiques seront appelées meta-politiques car elles sont des politiques auxquelles lensemble de politiques dune organisation doit être conforme CA-RCM contrôle si lensemble des politiques de lorganisation est conforme aux meta- politiques Sinon, il affiche des message qui signalent lerreur Ladministrateur peut décider de modifier la ou les politiques qui ont généré lerreur de tolérer lerreur dans ce deuxième cas, la même erreur sera affichée à la prochaine vérification La vérification des meta-politiques dans lensemble de politiques dune organisation devrait être faite régulièrement, et occasionnellement par un groupe de personne distinct des administrateurs des politiques: Les vérificateurs ou auditors 5

Dans la prochaine diapositive En haut: affectation dusagers à rôles Dans le milieu: meta-politiques à respecter À bas: diagnostiques concernant erreurs, meta- politiques non respectées Ignorer les détails … il ne sont pas importants pour nous 6

7

Extension de RBAC CA-RCM sapplique à RBAC Il est aussi approprié pour un RBAC étendu, où On connait non seulement les usagers, les rôles, les ressources, et les permissions, mais aussi leurs attributs On peut avoir des permissions qui sont des affectations directes dusagers à ressources Etc. – nous verrons dans les exemples 8

Exemples de meta-politiques en CA-RCM Any Maîtrise ForbiddenToHave All Classified Aucun étudiant de maîtrise ne peut avoir ALL Documents classifiés All Maîtrise MayHave Any Secret Pour lensemble des étudiants de maîtrise, ils peuvent avoir accès à Secret Any Professor Only Allowed ToHave Any Top Secret Peuvent avoir Top Secret seulement (rien dautre) Les éléments gauche et droite peuvent être presque nimporte quoi: Usager Role Ressource Peuvent aussi être des ensemble s de tels éléments, nous verrons 9

Structure des meta-politiques Chaque meta-politique consiste en trois éléments: Un élément gauche ( LEFT ) qui peut contenir une liste dune ou plusieurs entités différentes, tel que usagers, rôles, ressources, conditions, permissions, etc. Un élément de droite ( RIGHT ) qui aussi peut contenir une liste dentités différentes, comme les précédentes Un opérateur de contraintes entre les deux: Forbidden to have, May have, etc., nous verrons Tant LEFT que RIGHT peuvent avoir les quantificateurs Any ou All Si un quantificateur nest pas indiqué, le défaut est Any 10

Contraintes daffectation entre entités Contraintes daffectation entre les entités Role-Role (By users) o ONLY MAY HAVE : Seuls les utilisateurs qui ont des rôles à gauche peuvent avoir les rôles à droite. o MUST HAVE : Les utilisateurs qui ont des rôles à gauche doivent avoir les rôles à droite. o FORBIDDEN TO HAVE : Les utilisateurs qui ont des rôles à gauche ne peuvent pas avoir les rôles à droite. o ONLY ALLOWED TO HAVE : Les utilisateurs qui ont des rôles à gauche ne peuvent avoir que les rôles à droite, et pas d'autres. Role-Role (By Roles) o ONLY MAY HAVE : Seuls les rôles qui ont des sous-rôles à gauche peuvent avoir des sous-rôles à droite. o MUST HAVE : Les rôles qui ont des sous-rôles à gauche doivent avoir des sous-rôles à droite. o FORBIDDEN TO HAVE : Les rôles qui ont des sous-rôles à gauche ne peuvent pas avoir des sous-rôles à droite. o ONLY ALLOWED TO HAVE : Les rôles qui ont des sous-rôles à gauche ne peuvent avoir que des sous-rôles à droite, et pas d'autres. Role-Resource (By users) o ONLY MAY HAVE : Seuls les utilisateurs qui ont des rôles à gauche peuvent accéder aux ressources à droite. o MUST HAVE : Les utilisateurs qui ont des rôles à gauche doivent pouvoir accéder aux ressources à droite. o FORBIDDEN TO HAVE : Les utilisateurs qui ont des rôles à gauche ne peuvent pas accéder aux ressources à droite. o ONLY ALLOWED TO HAVE : Les utilisateurs qui ont des rôles à gauche ne peuvent accéder quaux ressources à droite, et pas d'autres.

Contraintes daffectation entre entités Role-Resource (By Roles) o ONLY MAY HAVE : Seuls les rôles qui ont des rôles enfants à gauche peuvent accéder aux ressources à droite. o MUST HAVE Les rôles qui ont des rôles enfants à gauche doivent pouvoir accéder aux ressources à droite. o FORBIDDEN TO HAVE : Les rôles qui ont des rôles enfants à gauche ne peuvent pas accéder aux ressources à droite. o ONLY ALLOWED TO HAVE : Les rôles qui ont des rôles enfants à gauche ne peuvent accéder quaux ressources à droite, et pas d'autres. Resource-Resource (By users) o ONLY MAY HAVE : Seuls les utilisateurs qui peuvent accéder aux ressources à gauche peuvent accéder aux ressources à droite. o MUST HAVE : Les utilisateurs qui peuvent accéder aux ressources à gauche doivent pouvoir accéder aux ressources à droite. o FORBIDDEN TO HAVE : Les utilisateurs qui peuvent accéder aux ressources à gauche ne peuvent pas accéder aux ressources à droite. o ONLY ALLOWED TO HAVE : Les utilisateurs qui peuvent accéder aux ressources à gauche ne peuvent accéder quaux ressources à droite, et pas d'autres. Resource-Resource (By Roles) o ONLY MAY HAVE : Seuls les rôles qui incluent des ressources à gauche peuvent accéder aux ressources à droite. o MUST HAVE : Les rôles qui incluent des ressources à gauche doivent pouvoir accéder aux ressources à droite. o FORBIDDEN TO HAVE : Les rôles qui incluent des ressources à gauche ne peuvent pas accéder aux ressources à droite. o ONLY ALLOWED TO HAVE : Les rôles qui incluent des ressources à gauche ne peuvent accéder quaux ressources à droite, et pas d'autres. NB: la documentation parle parfois de sub-roles (diapo précédente), parfois de child-roles, probablement ces deux termes ont la même signification.

Exemples de contraintes entre entités 13 o Role-Role (by users) : ONLY May Have : o seuls les utilisateurs ayant le rôle ont le droit davoir le rôle. o Resource-Resource (by roles) : Must Have : o les rôles ayant la ressource doivent avoir la ressource. o Role-Resource (by users) : Forbidden To Have : o les utilisateurs qui ont le rôle ne peuvent pas avoir la ressource.

Contraintes daffectation entre attributs et identités 14 User Attribute-Role o ONLY MAY HAVE : Seuls les utilisateurs ayant des attributs à gauche peuvent avoir les rôles à droite. o MUST HAVE : Les utilisateurs ayant des attributs à gauche doivent avoir les rôles à droite. o FORBIDDEN TO HAVE : Les utilisateurs ayant des attributs à gauche ne peuvent pas avoir les rôles à droite o ONLY ALLOWED TO HAVE : Les utilisateurs ayant des attributs à gauche ne peuvent avoir que les rôles à droite, et pas d'autres. User Attribute-Resource o ONLY MAY HAVE : Seuls les utilisateurs ayant des attributs à gauche peuvent accéder aux ressources à droite. o MUST HAVE Les utilisateurs ayant des attributs à gauche doivent pouvoir accéder aux ressources à droite. o FORBIDDEN TO HAVE Les utilisateurs ayant des attributs à gauche ne peuvent pas accéder aux ressources à droite. o ONLY ALLOWED TO HAVE Les utilisateurs ayant des attributs à gauche ne peuvent accéder quaux ressources à droite, et pas d'autres. Exemple o User Attribute-Role : Must Have : o Les utilisateurs ayant la valeur de lattribut inférieur à 60ans, doivent avoir le rôle.

Contraintes daffectation entre attributs 15 User Attribute-Role Attribute o ONLY MAY HAVE : Seuls les utilisateurs ayant des attributs à gauche peuvent avoir des rôles ayant les attributs à droite. o MUST HAVE : Les utilisateurs ayant des attributs à gauche doivent avoir des rôles ayant les attributs à droite. o FORBIDDEN TO HAVE : Les utilisateurs ayant des attributs à gauche ne peuvent pas avoir des rôles ayant les attributs à droite o ONLY ALLOWED TO HAVE : Les utilisateurs ayant des attributs à gauche ne peuvent avoir que des rôles ayant les attributs à droite, et pas d'autres. Exemples o User Attribute-Role Attribute : 60ans> Must Have : o Les utilisateurs ayant la valeur de lattribut supérieure à 60ans, doivent avoir les rôles avec la valeur de lattribut égale á Inactif.

May have avec Any, All … 16 Exemple: Only All {Femme, Age>50, AvecEnfants} May have Any {Pension, Indemnité}: Nous voyons (flèches vertes) une entité dans lensemble X qui est affectée à toutes les entités de Y, qui sont les trois attributs. Cette entité peut avoir les entités dans lensemble Z, pension ou indemnité. Nous voyons aussi (flèches rouges) une entité dans lensemble E qui nest pas affectée à toutes les entités de Y. Cette entité ne peut pas avoir les entités dans lensemble Z. (Figures du mémoire de Hassen Khalifa)

Exemple avec permissions lecture-écriture Only All {(F1,r),(F2,w),(F3,r)} May have Any {(F4,w),(F5,r)} « Seulement les sujets, ou rôles, etc. qui peuvent lire de F1, écrire sur F2 et lire de F3 (les trois) peuvent écrire sur F4 ou lire de F5 » 17

Must have avec Any, All 18 Any {(F1,r),(F2,w),(F3,r)} Must have all {(F4,w),(F5,r)} Une entité qui a au moins une des permissions à gauche doit avoir toutes les permissions à droite

Forbidden to have avec Any, All 19 Any {(F1,r),(F2,w),(F3,r)} Forbidden to have All {(F4,w),(F5,r)} Une entité (sujet, rôle …) qui a une permission à gauche ne peut pas avoir toutes les permissions à droite: il doit exister au moins une permission à droite quil na pas (cas possiblement un peu théorique)

Exemple avec ONLY 20 All LEFT Allowed to have Only Any RIGHT Les flèches vertes montrent ce qui est permis: que les entités qui sont affectées à tous les éléments de Y=LEFT peuvent avoir seulement des éléments dans Z=RIGHT Les flèches rouges montrent un exemple de ce qui nest pas permis: une entité qui est aussi affectée à tous les éléments de Y=LEFT ne peut pas avoir des entités à lextérieur de Z=RIGHT.

Contraintes de cardinalité Segregation Of Duty Roles o SHOULD HAVE NO MORE THAN N: Les utilisateurs ne peuvent pas avoir plus que N (à droite) rôles dans lensemble à gauche. o SHOULD HAVE AT LEAST N: Les utilisateurs ne peuvent pas avoir moins que N (à droite) rôles dans lensemble à gauche. o SHOULD HAVE EXACTLY N: Les utilisateurs doivent avoir exactement N (à droite) rôles dans lensemble à gauche. Segregation Of Duty Resources o SHOULD HAVE NO MORE THAN N: Les utilisateurs ne peuvent pas avoir accès à plus que N (à droite) ressources dans lensemble à gauche. o SHOULD HAVE AT LEAST N: Les utilisateurs ne peuvent pas avoir accès à moins que N (à droite) ressources dans lensemble à gauche. o SHOULD HAVE EXACTLY N: Les utilisateurs doivent avoir accès à exactement N (à droite) ressources dans lensemble à gauche.

Contraintes de cardinalité User Counter Of Roles o SHOULD HAVE NO MORE THAN N: Les rôles à gauche ne peuvent avoir plus que N (à droite) utilisateurs. o SHOULD HAVE AT LEAST N: Les rôles à gauche ne peuvent avoir moins que N (à droite) utilisateurs. o SHOULD HAVE EXACTLY N: Les rôles à gauche doivent avoir exactement N (à droite) utilisateurs. User Counter Of Resources o SHOULD HAVE NO MORE THAN N: Les ressources à gauche ne peuvent avoir plus que N (à droite) utilisateurs. o SHOULD HAVE AT LEAST N: Les ressources à gauche ne peuvent avoir moins que N (à droite) utilisateurs. o SHOULD HAVE EXACTLY N: Les ressources à gauche doivent avoir exactement N (à droite) utilisateurs.

Exemples de contraintes de cardinalité 23 o Segregation Of Duty Roles : Should Have No More Than : Les utilisateurs ne peuvent avoir plus que rôle de lensemble {Administrateur, Financier}. o Chaque utilisateur peut avoir un seul des deux rôles ou bien aucun dentre les deux. o User Counter Of Resources : Should Have At Least : Les ressources et ne peuvent avoir moins que Utilisateurs. o Il doit y avoir au moins 5 utilisateurs qui sont affectés à chaque ressource.

Contraintes sur les valeurs 24 o NUMBER IN MUST BE GREATER THAN : Les valeurs numériques des attributs des utilisateurs à gauche doivent être supérieures à la valeur numérique à droite. o NUMBER IN MUST BE LESS THAN : Les valeurs numériques des attributs des utilisateurs à gauche doivent être inférieures à la valeur numérique à droite. o NUMBER IN MUST BE EQUAL TO : Les valeurs numériques des attributs des utilisateurs à gauche doivent être égales à la valeur numérique à droite. o DATE IN MUST BE EARLIER THAN : Les dates des attributs des utilisateurs à gauche doivent être antérieures à la date à droite. o DATE IN MUST BE LATER THAN : Les dates des attributs des utilisateurs à gauche doivent être postérieures à la date à droite. o MUST MATCH REGULAR EXPRESSION : Les valeurs des attributs des utilisateurs à gauche doivent correspondre à la valeur définie par l'expression régulière à droite. o MUST NOT MATCH REGULAR EXPRESSION : Les valeurs des attributs des utilisateurs à gauche ne doivent pas correspondre à la valeur définie par l'expression régulière à droite. o SHOULD BE EMPTY: Les valeurs des attributs des utilisateurs à gauche doivent être vides. o SHOULD NOT BE EMPTY: Les valeurs des attributs des utilisateurs à gauche ne doivent pas être vides.

Exemples de contraintes sur les valeurs 25 o User Attribute Value : Number In Must Be Greater Than o la valeur de lattribut des utilisateurs doit être supérieure à. o User Attribute Value : Should Not Be Empty : o la valeur de lattribut des utilisateurs ne doit pas être vide.

Incohérences Comme dans le cas de règle et politiques normales, il y a la possibilité que ladministrateur introduise par erreur des meta-règles ou meta-politiques mutuellement incohérentes: A must have B A cannot have B Ceci est un exemple facile, direct, mais des exemples indirects et plus difficiles à voir peuvent être trouvés facilement Un bon nombre de possibilités dincohérences existe V. mémoire de maîtrise de Hassen Khalifa 26

Conclusion Loutil CA-RCM est un bon exemple doutil de vérification ou audit densembles de politiques dans un environnement RBAC, et au-delà de RBAC 27

Pour en savoir plus V. le mémoire de maîtrise dHassen Khalifa, qui sera bientôt dans le site des mémoires de notre département « Détection des anomalies entre les contraintes dans les politiques de contrôle daccès » Une bonne partie de cette présentation vient de ce mémoire, Merci Hassen! Faire une recherche web sur: « CA Role & Compliance Manager » 28