Un outil industriel

1. Un outil industriel CA-RCM Luigi.Logrippo@uqo.ca

2. CA-RCM: Un outil pour RBAC • CA Technologies est une grande compagnie d’informatique, 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 l’ensemble des politiques dans une organisation est conforme à certaines politiques générales • Il est important de comprendre que CA-RCM n’est pas un outil pour octroyer ou refuser l’accès • N’est pas un outil de décision (pour le PDP) mais il est un outil d’administration (pour le PAP)

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

4. Extraction de rôles avec CA-RCM • CA-RCM utilise les listes de contrôle d’accès d’une 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

5. CA-RCM comme outil de vérification ou audit • Une organisation pourrait avoir certains principes pour l’administration des politiques, p.ex.: • Il ne devrait pas être permis d’avoir 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 l’ensemble de politiques d’une organisation doit être conforme • CA-RCM contrôle si l’ensemble des politiques de l’organisation est conforme aux meta-politiques • Sinon, il affiche des message qui signalent l’erreur • L’administrateur peut décider • de modifier la ou les politiques qui ont généré l’erreur • de tolérer l’erreur • dans ce deuxième cas, la même erreur sera affichée à la prochaine vérification • La vérification des meta-politiques dans l’ensemble de politiques d’une organisation devrait être faite régulièrement, et occasionnellement par un groupe de personne distinct des administrateurs des politiques: • Les ‘vérificateurs’ ou ‘auditors’

6. Dans la prochaine diapositive • En haut: affectation d’usagers à 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

8. Extension de RBAC • CA-RCM s’applique à 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 d’usagers à ressources • Etc. – nous verrons dans les exemples

9. 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 l’ensemble 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 d’autre) • Les éléments gauche et droite peuvent être presque n’importe quoi: • Usager • Role • Ressource • Peuvent aussi être des ensembles de tels éléments, nous verrons

10. Structure des meta-politiques • Chaque meta-politique consiste en trois éléments: • Un élément gauche (LEFT) qui peut contenir une liste d’une 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 d’entité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 n’est pas indiqué, le défaut est ‘Any’

11. Contraintes d’affectation entre entités - 1 • Contraintesd’affectation entre les entités • Role-Role (By users) • ONLY <L> MAY HAVE <R> : Seuls les utilisateurs qui ont des rôles à gauche peuvent avoir les rôles à droite. • <L> MUST HAVE <R> : Les utilisateurs qui ont des rôles à gauche doivent avoir les rôles à droite. • <L> FORBIDDEN TO HAVE <R> : Les utilisateurs qui ont des rôles à gauche ne peuvent pas avoir les rôles à droite. • <L> ONLY ALLOWED TO HAVE <R> : Les utilisateurs qui ont des rôles à gauche ne peuvent avoir que les rôles à droite, et pas d'autres. • Role-Role (By Roles) • ONLY <L> MAY HAVE <R> : Seuls les rôles qui ont des sous-rôles à gauche peuvent avoir des sous-rôles à droite. • <L> MUST HAVE <R> : Les rôles qui ont des sous-rôles à gauche doivent avoir des sous-rôles à droite. • <L> FORBIDDEN TO HAVE <R> : Les rôles qui ont des sous-rôles à gauche ne peuvent pas avoir des sous-rôles à droite. • <L> ONLY ALLOWED TO HAVE <R> : 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) • ONLY <L> MAY HAVE <R> : Seuls les utilisateurs qui ont des rôles à gauche peuvent accéder aux ressources à droite. • <L> MUST HAVE <R> : Les utilisateurs qui ont des rôles à gauche doivent pouvoir accéder aux ressources à droite. • <L> FORBIDDEN TO HAVE <R> : Les utilisateurs qui ont des rôles à gauche ne peuvent pas accéder aux ressources à droite. • <L> ONLY ALLOWED TO HAVE <R> : Les utilisateurs qui ont des rôles à gauche ne peuvent accéder qu’aux ressources à droite, et pas d'autres.

12. Contraintes d’affectation entre entités - 2 • Role-Resource (By Roles) • ONLY <L> MAY HAVE <R> : Seuls les rôles qui ont des rôles enfants à gauche peuvent accéder aux ressources à droite. • <L> MUST HAVE <R> Les rôles qui ont des rôles enfants à gauche doivent pouvoir accéder aux ressources à droite. • <L> FORBIDDEN TO HAVE <R> : Les rôles qui ont des rôles enfants à gauche ne peuvent pas accéder aux ressources à droite. • <L> ONLY ALLOWED TO HAVE <R> : Les rôles qui ont des rôles enfants à gauche ne peuvent accéder qu’aux ressources à droite, et pas d'autres. • Resource-Resource (By users) • ONLY <L> MAY HAVE <R> : Seuls les utilisateurs qui peuvent accéder aux ressources à gauche peuvent accéder aux ressources à droite. • <L> MUST HAVE <R> : Les utilisateurs qui peuvent accéder aux ressources à gauche doivent pouvoir accéder aux ressources à droite. • <L> FORBIDDEN TO HAVE <R> : Les utilisateurs qui peuvent accéder aux ressources à gauche ne peuvent pas accéder aux ressources à droite. • <L> ONLY ALLOWED TO HAVE <R> : Les utilisateurs qui peuvent accéder aux ressources à gauche ne peuvent accéder qu’aux ressources à droite, et pas d'autres. • Resource-Resource (By Roles) • ONLY <L> MAY HAVE <R> : Seuls les rôles qui incluent des ressources à gauche peuvent accéder aux ressources à droite. • <L> MUST HAVE <R> : Les rôles qui incluent des ressources à gauche doivent pouvoir accéder aux ressources à droite. • <L> FORBIDDEN TO HAVE <R> : Les rôles qui incluent des ressources à gauche ne peuvent pas accéder aux ressources à droite. • <L> ONLY ALLOWED TO HAVE <R> : Les rôles qui incluent des ressources à gauche ne peuvent accéder qu’aux 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.

13. Exemples de contraintes entre entités • Role-Role (by users) : ONLY <Administrateur> May Have <Financier> : • seuls les utilisateurs ayant le rôle <Administrateur> ont le droit d’avoir le rôle <Financier>. • Resource-Resource (by roles) : <File1> Must Have <File2> : • les rôles ayant la ressource <File1> doivent avoir la ressource <File2>. • Role-Resource (by users) : <Financier> Forbidden To Have <File1> : • les utilisateurs qui ont le rôle <Financier> ne peuvent pas avoir la ressource <File1>.

14. Contraintes d’affectation entre attributs et identités • User Attribute-Role • ONLY <L> MAY HAVE <R> : Seuls les utilisateurs ayant des attributs à gauche peuvent avoir les rôles à droite. • <L> MUST HAVE <R> : Les utilisateurs ayant des attributs à gauche doivent avoir les rôles à droite. • <L> FORBIDDEN TO HAVE <R> : Les utilisateurs ayant des attributs à gauche ne peuvent pas avoir les rôles à droite • <L> ONLY ALLOWED TO HAVE <R> : Les utilisateurs ayant des attributs à gauche ne peuvent avoir que les rôles à droite, et pas d'autres. • User Attribute-Resource • ONLY <L> MAY HAVE <R> : Seuls les utilisateurs ayant des attributs à gauche peuvent accéder aux ressources à droite. • <L> MUST HAVE <R> Les utilisateurs ayant des attributs à gauche doivent pouvoir accéder aux ressources à droite. • <L> FORBIDDEN TO HAVE <R> Les utilisateurs ayant des attributs à gauche ne peuvent pas accéder aux ressources à droite. • <L> ONLY ALLOWED TO HAVE <R> Les utilisateurs ayant des attributs à gauche ne peuvent accéder qu’aux ressources à droite, et pas d'autres. • Exemple • User Attribute-Role : <Age < 60ans> Must Have <Employé> : • Les utilisateurs ayant la valeur de l’attribut <Age> inférieur à 60ans, doivent avoir le rôle <Employé>.

15. Contraintes d’affectation entre attributs • User Attribute-RoleAttribute • ONLY <L> MAY HAVE <R> : Seuls les utilisateurs ayant des attributs à gauche peuvent avoir des rôles ayant les attributs à droite. • <L> MUST HAVE <R> : Les utilisateurs ayant des attributs à gauche doivent avoir des rôles ayant les attributs à droite. • <L> FORBIDDEN TO HAVE <R> : Les utilisateurs ayant des attributs à gauche ne peuvent pas avoir des rôles ayant les attributs à droite • <L> ONLY ALLOWED TO HAVE <R> : Les utilisateurs ayant des attributs à gauche ne peuvent avoir que des rôles ayant les attributs à droite, et pas d'autres. • Exemples • User Attribute-RoleAttribute : <Age > 60ans> Must Have <Statut = Inactif> : • Les utilisateurs ayant la valeur de l’attribut <Age> supérieure à 60ans, doivent avoir les rôles avec la valeur de l’attribut <Statut> égale á Inactif.

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

17. 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 »

18. Must have avec Any, All 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

19. Forbidden to have avec Any, All 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 qu’il n’a pas (cas possiblement un peu théorique)

20. Exemple avec ONLY 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 n’est pas permis: une entité qui est aussi affectée à tous les éléments de Y=LEFT ne peut pas avoir des entités à l’extérieur de Z=RIGHT.

21. Contraintes de cardinalité - 1 Segregation Of Duty Roles • <L> SHOULD HAVE NO MORE THAN N: Les utilisateurs ne peuvent pas avoir plus que N (à droite) rôles dans l’ensemble à gauche. • <L> SHOULD HAVE AT LEAST N: Les utilisateurs ne peuvent pas avoir moins que N (à droite) rôles dans l’ensemble à gauche. • <L> SHOULD HAVE EXACTLY N: Les utilisateurs doivent avoir exactement N (à droite) rôles dans l’ensemble à gauche. Segregation Of Duty Resources • <L> SHOULD HAVE NO MORE THAN N: Les utilisateurs ne peuvent pas avoir accès à plus que N (à droite) ressources dans l’ensemble à gauche. • <L> SHOULD HAVE AT LEAST N: Les utilisateurs ne peuvent pas avoir accès à moins que N (à droite) ressources dans l’ensemble à gauche. • <L> SHOULD HAVE EXACTLY N: Les utilisateurs doivent avoir accès à exactement N (à droite) ressources dans l’ensemble à gauche.

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

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

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

25. Exemples de contraintes sur les valeurs • User Attribute Value : Number In <Age> Must Be Greater Than <20> • la valeur de l’attribut des utilisateurs <Age> doit être supérieure à <20>. • User Attribute Value : <Name> Should Not Be Empty : • la valeur de l’attribut des utilisateurs <Name> ne doit pas être vide.

26. Incohérences • Comme dans le cas de règle et politiques ‘normales’, il y a la possibilité que l’administrateur 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 d’incohérences existe • V. mémoire de maîtrise de Hassen Khalifa

27. Conclusion • L’outil CA-RCM est un bon exemple d’outil de vérification ou audit d’ensembles de politiques dans un environnement RBAC, et au-delà de RBAC

28. Pour en savoir plus • V. le mémoire de maîtrise d’Hassen 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 d’accès » • Une bonne partie de cette présentation vient de ce mémoire, Merci Hassen! • Faire une recherche web sur: • « CA Role & Compliance Manager »