Confidentialité et ergonomie, personnaliser l'accès au SIRH avec RBAC

L'attribut de contexte

Il représente une certaine propriété de l'environnement dont la véritable valeur pourrait changer dynamiquement (comme le temps, la date, ou les données d'une session par exemple) ou qui varie pour différentes instances de la même entité abstraite (par ex, le lieu de travail, l'affectation, l'anniversaire, ou la nationalité). Ainsi, les attributs de contexte sont un moyen de rendre (exogène) l'information contextuelle explicite. Au niveau programmation, chaque attribut de contexte (AC) représente une variable qui est associée avec un domaine_AC qui détermine le type et la gamme de valeurs que cet attribut AC peut prendre (par ex, une date, un nombre entier, une chaine).

La fonction de contexte

C'est un mécanisme pour obtenir la valeur courante d'un attribut spécifique de contexte (c.-à-d., pour saisir explicitement l'information du contexte). Par exemple, une fonction date() pourrait être définie pour renvoyer la date du jour. Naturellement une fonction de contexte peut également recevoir un ou plusieurs paramètres d'entrée. Par exemple, une fonction grade(sujet) peut prendre le nom du sujet hors du triplet (sujet, opération, objet) pour obtenir le grade du sujet, qui lance une demande courante d'accès, par exemple, le grade peut être lu dans son dossier du personnel.

Une condition de contexte

C'est un prédicat (une fonction booléenne) qui se compose d'un opérateur et de deux opérandes ou plus. Le premier opérande représente toujours un attribut de contexte, alors que les autres opérandes peuvent être l'un ou l'autre attribut de contexte ou des valeurs constantes. Toutes les variables doivent être rectifiées avant évaluation. Par conséquent, chaque attribut de contexte est remplacé par une valeur constante en utilisant la fonction correspondante de contexte avant l'évaluation de la condition.

Les contraintes contextuelles sont utilisées pour définir les autorisations conditionnelles. En ce qui concerne les termes définis ci-dessus, une autorisation conditionnelle est une autorisation qui est associée à un ou plusieurs contextes, les contraintes et les accès accordés correspondants si chaque contrainte contextuelle a la valeur "vraie". Par conséquent, les autorisations conditionnelles accordent un accès opérationnel si les valeurs réelles des attributs du contexte venant de l'environnement remplissent les contraintes contextuelles rattachées. La relation entre le contexte des contraintes et des permissions est une relation (n,n) (voir ci-dessus Figure 27). De ce fait, un certain nombre de permissions peuvent être associées à une même contrainte contextuelle si nécessaire.

De la même manière que nous avions définis les règles du R-BAC brut, nous pouvons l'enrichir de la façon suivante avec une définition algébrique des contraintes contextuelles. Cette définition est donnée ci-dessous (Elle étend les définitions fournies par (Ferraiolo, Kuhn et Chandramouli 2003), il est ajouté en particulier l'abréviation PRMS réfère à l'ensemble de permissions) (STREMBECK et NEUMANN 2004).

Tableau 10 : Propriétés des contraintes contextuelles

ATTS L'ensemble des attributs du contexte (par exemple, heure locale, l'adresse IP locale, le nom de l'objet, grade du sujet).

DOMAINE Le jeu des domaines (par exemple, boolean, date, entier, réel, chaines).

CONSTANTES = {x | x est une valeur constante ? domaine(x) ? DOMAINS}.

OPERANDES = ATTS ? CONSTANTES

OPERATEURS, l'ensemble des opérateurs de comparaison, tel que =, =, >, <, =, =.

domaine(oprtr : OPERATEURS) ? {d ? DOMAINES}, une fonction pour déterminer l'ensemble des domaine pour lequel un opérateur est spécifié.

domaine(oprnd : OPERANDES) ? {d ? DOMAINES}, une fonction pour déterminer le type d'une opérande.

CONDITIONS = 2 OPERANDS × OPERATORS, ?c ? CONDITIONS : c ? {(oprnd1, . . . , oprndx , oprtr)|oprnd1, . . . , operndx ? OPERANDES, oprtr ? OPERATEURS} ? {domaine(oprnd1) ? · · ·? domaine(oprndx ) ? domain(oprtr)}.

CC = 2 CONDITIONS, l'ensemble des contraintes contextuelles.

PCL ? PRMS×CC, couplage permission/condition contextuelle

linked ccs(p : PRMS) ? {contraintes ? CC}, le couplage d'une permission p à un ensemble de contrainte contextuelle. Formellement: linked ccs(p) = {c ? CC | (p, c) ? PCL}

Cette définition algébrique rend difficilement compte des contraintes endogènes, comme la séparation des droits ou des contraintes de cardinalités, par exemple. Elles ne peuvent souvent être obtenues qu'à partir des règles métier d'une organisation particulière. Des contraintes comme : « les rôles "gestionnaire RH" et "contrôleur paie" doivent être statiquement mutuellement exclusive », ou « la Cardinalité maximale pour l'utilisateur avec un rôle "contrôleur paie" est "unique" ».

Maintenant nous avons de nombreux outils pour construire notre ingénierie des rôles. Cette ingénierie va nous aider à préciser les contraintes exogènes (contexte). Dans la section 5, nous allons proposer un cadre pour les processus d'ingénierie.

5 A la recherche d'une ingénierie des rôles

Le contrôle d'accès par les rôles est une innovation majeure. Peu de consultants en connaisse les concepts. Notre objectif est de découvrir comment utiliser au mieux cette approche novatrice à partir de ce que nous avons étudié jusqu'à présent. Comment passer d'une méthode empirique à une méthode scientifique ?

5.1 Méthode empirique

Sans vrai recul sur la nouveauté que constitue un contrôle d'accès basé sur les rôles, l'approche la plus courante pour créer une politique d'accès est une approche descendante (Top-Down).

Cette approche commence, soit par la définition d'un modèle de sécurité des accès qui soit cohérent avec les métiers et le système d'information de l'organisation, soit par une analyse des droits définis dans les systèmes et applications.

Il existe une autre approche qui part au contraire du terrain et de la réalité des accès.

Cette approche ascendante (Bottom-Up) permet de collecter de façon simple les accès des utilisateurs à leurs applications durant une période donnée et d'associer automatiquement à chaque utilisateur l'identifiant qu'il utilise pour accéder à son application.

Une fois les accès effectifs collectés, les utilisateurs sont associés à leur rôle et à leur organisation. Une politique optimisée en est déduite. Cette politique peut ensuite, via les identifiants des utilisateurs, être comparée aux droits déclarés dans les systèmes cibles pour analyser les écarts et en déduire des adaptations. Prenons comme référence la politique idéale de l'entreprise qui permet d'associer correctement un droit (ou une permission) à un utilisateur.

· L'approche Top-Down qui s'appuie sur les droits déclarés dans les systèmes et applications génère une politique plus permissive que la politique cible car cette approche intègre les failles déclarées dans les systèmes et applications.

· L'approche Bottom-Up qui s'appuie sur les accès effectivement effectués pendant une certaine période génère une politique trop restrictive par rapport à la politique idéale car cette politique n'intègre pas les accès qui auront été faits en dehors de la période de collecte.

La comparaison des écarts entre la politique Bottom-Up et les systèmes cibles (Top-Down) permet de focaliser l'analyse sur les points qui permettront de se rapprocher de la politique idéale.

La définition d'une politique R-BAC étendu à partir d'une approche Bottom-Up comporte quatre étapes principales.

1. La collecte des accès nécessaire.

2. La définition des attributs des utilisateurs.

3. La validation du modèle.

4. La création de la politique à partir des accès nécessaire.

5.1.2 La collecte des accès nécessaire

La collecte des accès effectivement effectués est au coeur de l'approche Bottom-up. Elle va nous permettre de définir une politique qui reflète la réalité des accès. A partir des accès tels qu'ils existaient sur l'ancien système, nous allons définir les accès aux pages ayant des actions fonctionnelles similaires.

Cette collecte va nous permettre d'obtenir les relations suivantes :

Figure 28 : collecte des accès nécessaires à l'utilisateur

5.1.3 La définition des attributs des utilisateurs.

Cette étape va nous permettre d'associer un rôle et une organisation à chaque utilisateur.