Un outil industriel

CA-RCM

1

Luigi.Logrippo@uqo.ca

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)

2

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)

3

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 efficacesCA 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 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’

5

Dans la prochaine diapositive

En haut: affectation d’usagers à rôlesDans 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 s’applique à RBACIl 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

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

9

Structure des meta-politiquesChaque 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’

10

Contraintes d’affectation entre entités - 1

11

Contraintes d’affectation entre les entités

Role-Role (By users)

oONLY <L> MAY HAVE <R> : Seuls les utilisateurs qui ont des rôles à gauche peuvent avoir les rôles à droite.

o<L> MUST HAVE <R> : Les utilisateurs qui ont des rôles à gauche doivent avoir les rôles à droite.

o<L> FORBIDDEN TO HAVE <R> : Les utilisateurs qui ont des rôles à gauche ne peuvent pas avoir les rôles à droite.

o<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)

oONLY <L> MAY HAVE <R> : Seuls les rôles qui ont des sous-rôles à gauche peuvent avoir des sous-rôles à droite.

o<L> MUST HAVE <R> : Les rôles qui ont des sous-rôles à gauche doivent avoir des sous-rôles à droite.

o<L> FORBIDDEN TO HAVE <R> : Les rôles qui ont des sous-rôles à gauche ne peuvent pas avoir des sous-rôles à droite.o<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)

oONLY <L> MAY HAVE <R> : Seuls les utilisateurs qui ont des rôles à gauche peuvent accéder aux ressources à droite.

o<L> MUST HAVE <R> : Les utilisateurs qui ont des rôles à gauche doivent pouvoir accéder aux ressources à droite.

o<L> FORBIDDEN TO HAVE <R> : Les utilisateurs qui ont des rôles à gauche ne peuvent pas accéder aux ressources à droite.

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

Contraintes d’affectation entre entités - 2

12

Role-Resource (By Roles)

oONLY <L> MAY HAVE <R> : Seuls les rôles qui ont des rôles enfants à gauche peuvent accéder aux ressources à droite.

o<L> MUST HAVE <R> Les rôles qui ont des rôles enfants à gauche doivent pouvoir accéder aux ressources à droite.

o<L> FORBIDDEN TO HAVE <R> : Les rôles qui ont des rôles enfants à gauche ne peuvent pas accéder aux ressources à droite.

o<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)

oONLY <L> MAY HAVE <R> : Seuls les utilisateurs qui peuvent accéder aux ressources à gauche peuvent accéder aux ressources à droite.

o<L> MUST HAVE <R> : Les utilisateurs qui peuvent accéder aux ressources à gauche doivent pouvoir accéder aux ressources à droite.

o<L> FORBIDDEN TO HAVE <R> : Les utilisateurs qui peuvent accéder aux ressources à gauche ne peuvent pas accéder aux ressources à

droite.

o<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)

oONLY <L> MAY HAVE <R> : Seuls les rôles qui incluent des ressources à gauche peuvent accéder aux ressources à droite.

o<L> MUST HAVE <R> : Les rôles qui incluent des ressources à gauche doivent pouvoir accéder aux ressources à droite.o<L> FORBIDDEN TO HAVE <R> : Les rôles qui incluent des ressources à gauche ne peuvent pas accéder aux ressources à droite.

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

Exemples de contraintes entre entités

13

o Role-Role (by users) : ONLY <Administrateur> May Have <Financier> :

o seuls les utilisateurs ayant le rôle <Administrateur> ont le droit d’avoir le rôle

<Financier>.

o Resource-Resource (by roles) : <File1> Must Have <File2> :

o les rôles ayant la ressource <File1> doivent avoir la ressource <File2>.

o Role-Resource (by users) : <Financier> Forbidden To Have <File1> :

o les utilisateurs qui ont le rôle <Financier> ne peuvent pas avoir la ressource

<File1>.

Contraintes d’affectation entre attributs et identités

14

User Attribute-Role

oONLY <L> MAY HAVE <R> : Seuls les utilisateurs ayant des attributs à gauche peuvent avoir les rôles à droite.

o<L> MUST HAVE <R> : Les utilisateurs ayant des attributs à gauche doivent avoir les rôles à droite.

o<L> FORBIDDEN TO HAVE <R> : Les utilisateurs ayant des attributs à gauche ne peuvent pas avoir les rôles à droite

o<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

oONLY <L> MAY HAVE <R> : Seuls les utilisateurs ayant des attributs à gauche peuvent accéder aux ressources à droite.

o<L> MUST HAVE <R> Les utilisateurs ayant des attributs à gauche doivent pouvoir accéder aux ressources à droite.

o<L> FORBIDDEN TO HAVE <R> Les utilisateurs ayant des attributs à gauche ne peuvent pas accéder aux ressources à droite.

o<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

oUser Attribute-Role : <Age < 60ans> Must Have <Employé> :

o Les utilisateurs ayant la valeur de l’attribut <Age> inférieur à 60ans, doivent avoir le rôle <Employé>.

Contraintes d’affectation entre attributs

15

User Attribute-Role Attribute

oONLY <L> MAY HAVE <R> : Seuls les utilisateurs ayant des attributs à gauche peuvent avoir des rôles

ayant les attributs à droite.

o<L> MUST HAVE <R> : Les utilisateurs ayant des attributs à gauche doivent avoir des rôles ayant les

attributs à droite.

o<L> FORBIDDEN TO HAVE <R> : Les utilisateurs ayant des attributs à gauche ne peuvent pas avoir

des rôles ayant les attributs à droite

o<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

oUser Attribute-Role Attribute : <Age > 60ans> Must Have <Statut = Inactif> :

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

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 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)

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 qu’il n’a pas (cas possiblement un peu théorique)

Exemple avec ONLY

20

All LEFT Allowed to have Only Any RIGHTLes 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=RIGHTLes 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.

Contraintes de cardinalité - 1

21

Segregation Of Duty Roles

o <L> SHOULD HAVE NO MORE THAN N: Les utilisateurs ne peuvent pas avoir plus que N (à

droite) rôles dans l’ensemble à gauche.

o <L> SHOULD HAVE AT LEAST N: Les utilisateurs ne peuvent pas avoir moins que N (à droite)

rôles dans l’ensemble à gauche.

o <L> SHOULD HAVE EXACTLY N: Les utilisateurs doivent avoir exactement N (à droite) rôles

dans l’ensemble à gauche.

Segregation Of Duty Resources

o <L> SHOULD HAVE NO MORE THAN N: Les utilisateurs ne peuvent pas avoir accès à plus que

N (à droite) ressources dans l’ensemble à gauche.

o <L> SHOULD HAVE AT LEAST N: Les utilisateurs ne peuvent pas avoir accès à moins que N (à

droite) ressources dans l’ensemble à gauche.

o <L> SHOULD HAVE EXACTLY N: Les utilisateurs doivent avoir accès à exactement N (à droite)

ressources dans l’ensemble à gauche.

Contraintes de cardinalité - 2

22

User Counter Of Roles

o <L> SHOULD HAVE NO MORE THAN N: Les rôles à gauche ne peuvent avoir plus

que N (à droite) utilisateurs.

o <L> SHOULD HAVE AT LEAST N: Les rôles à gauche ne peuvent avoir moins que N

(à droite) utilisateurs.

o <L> SHOULD HAVE EXACTLY N: Les rôles à gauche doivent avoir exactement N (à

droite) utilisateurs.

User Counter Of Resources

o <L> SHOULD HAVE NO MORE THAN N: Les ressources à gauche ne peuvent avoir

plus que N (à droite) utilisateurs.

o <L> SHOULD HAVE AT LEAST N: Les ressources à gauche ne peuvent avoir moins

que N (à droite) utilisateurs.

o <L> SHOULD HAVE EXACTLY N: Les ressources à gauche doivent avoir exactement

N (à droite) utilisateurs.

Exemples de contraintes de cardinalité

23

o 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}.

o Chaque utilisateur peut avoir un seul des deux rôles ou bien aucun

d’entre les deux.

o User Counter Of Resources : < {File1, File2} > Should Have At Least <5> :

Les ressources <File1> et <File2> ne peuvent avoir moins que <5>

Utilisateurs.

o Il doit y avoir au moins 5 utilisateurs qui sont affectés à chaque

ressource.

Contraintes sur les valeurs

24

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

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

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

o DATE IN <L> MUST BE EARLIER THAN <R>: Les dates des attributs des utilisateurs à gauche doivent

être antérieures à la date à droite.

o DATE IN <L> MUST BE LATER THAN <R>: Les dates des attributs des utilisateurs à gauche doivent être

postérieures à la date à droite.

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

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

o <L> SHOULD BE EMPTY: Les valeurs des attributs des utilisateurs à gauche doivent être vides.

o <L> 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 <Age> Must Be Greater Than <20>

o la valeur de l’attribut des utilisateurs <Age> doit être supérieure à <20>.

o User Attribute Value : <Name> Should Not Be Empty :

o la valeur de l’attribut des utilisateurs <Name> ne doit pas être vide.

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

26

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

27

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 »

28