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

Exemple d'application au projet et analyse critique de la mise en oeuvre

A l'usage, il est fréquent que cette étape se fasse au fur et à mesure de l'étape 2 ( Déterminer les permissions des scénarios) puisque c'est au moment d'examiner les permissions nécessaire que nous pouvons voir si la description du scénario a une granularité suffisante pour accomplir cette tâche.

5.3.5 Définir les tâches et les profils de travail.

Dans ce sous-processus, les scénarios qui doivent rester ensemble sont combinés en tâche. Ces tâches sont alors utilisées pour définir les profils de travail :

Une tâche est une collection de scénarios qui peuvent être combinées pour réaliser une opération complexe. Le changement de situation familiale d'un agent peut par exemple consister à l'assemblage des scénarios suivant : « saisir un dossier agent », « modifier sa situation familiale ».

Un profil de travail est constitué d'une ou plusieurs tâches. De ce fait chaque profil de travail ressemble à une description de poste.

Figure 39 : processus de définition des tâches et des profils de travail

Le processus de définition des tâches et des profils de travail est bien plus complexe que ne peut le suggérer la Figure 39. Comme pour les contraintes, les spécifications des tâches et des profils de travail sont très différente suivant les organisations et les systèmes d'informations.

Exemple d'application au projet et analyse critique de la mise en oeuvre

A l'étape actuelle du projet, nous n'avons pas encore mis en oeuvre les dernières étapes de la méthodologie que nous comptons utiliser. Des adaptations seront encore à prévoir, mais nous pensons que l'essentiel est là et que le chemin est bien balisé.

Ce que (Neumann et Strembeck 2002) appelle « tâche » est à rapprocher d'une « activité » dans Hra Suite 7. Il va s'agir pour nous de déterminer dans le catalogue des permissions et celui des contraintes ce qui relève du rôle, de l'action fonctionnelle ou de l'activité.

Tableau 13 : éléments de paramétrage d'une action fonctionnelle

Code	Libellé	Technologie					Activité
		Noeud d'arbre web	Processus guidé	DMS	HR config tool	Rapport

Tableau 14 : éléments de paramétrage d'une activité

Code	Libellé	Dossier de gestion applicable à l'activité	Technologie
			Espace professionnel RH	Processus guidé	Requête & batch	Gestion documentaire

Ces deux tableaux seront des outils utiles pour ce sous-processus.

5.3.6 En déduire une hiérarchie des rôles préliminaire

A cette étape, le processus d'ingénierie des rôles a traité assez d'information pour construire une première version d'une hiérarchie de rôle R-BAC. Le profil de travail et le catalogue de permissions sont les points de départ de ce travail. Pour chaque profil de travail nous allons créer un rôle avec le même nom ou un nom similaire (gestionnaire administratif, expert paie, expert RH...). Alors que les profils de travail sont composés de tâches qui eux même sont composé de scénarios, nous pouvons directement identifier toutes les permissions devant être assignées à un rôle particulier. N'oublions pas que nous avons déjà tiré toutes les permissions des scénarios dans l'étape précédente.

Maintenant que nous avons transformés tous les profils de travail en rôle qui possède des permissions, nous pouvons identifier des rôles redondants. C'est-à-dire que nous recherchons des rôles qui possèdent exactement les mêmes permissions qu'un ou plusieurs rôles. Ces rôles ne seront pas supprimés, mais doivent être identifiés et revue si nécessaire. Il arrive que des rôles puissent avoir temporairement les mêmes permissions. Le profil de travail auxquels ils sont rattachés indique que des permissions seront ajoutées ou retirées. Une autre possibilité est qu'un rôle junior soit définit pour ces rôles avec les mêmes permissions. Nous ajouterons de nouveaux rôles juniors lorsqu'un des profils de travail devra être enrichi.

Figure 40 : processus d'affinage des profils de travail en hiérarchie de rôles

Avant qu'une hiérarchie finale des rôles R-BAC puisse être définie, nous devons construire une hiérarchie préliminaire des rôles. Avant tout, la prochaine étape sera l'identification des rôles junior. Dans cette activité nous recherchons les rôles dont les permissions sont des sous-ensembles de permissions assignés à un autre rôle. Pour deux rôles R1 et R2 où les permissions de R2 sont composées d'un sous-ensemble de permissions de R1, nous pouvons dire que R1 est plus important que R2. Nous identifions comme cela toutes les relations de subordinations qui nous permettent de définir des relations d'héritages entre les 2 rôles où R1 > R2. Chaque R2 est défini comme rôle junior pour le R1 correspondant. Nous enlevons comme cela toutes les permissions redondantes pour chaque rôle. Ce qui signifie que nous enlevons toutes les permissions qui ne sont pas assignées directement à un rôle et qui peuvent être hérité d'un rôle junior. Quand cette étape est terminée, nous avons définie une hiérarchie des rôles préliminaire.

L'algorithme de cette étape pourrait être le suivant :

Pour chaque profil de travail {

Créer rôle et assigner permissions

Ajouter rôle à ensemble des rôles

}

Pour chaque rôle1 dans ensemble des rôles {

Pour chaque rôle2 dans ensemble des rôles {

Si {permissions du rôle1 = permissions du rôle2} {

Ajouter rôle1 et rôle2 dans Rôles potentiellement redondant}

Si {rôle1 > rôle2} {

Ajouter rôle2 à rôlejunior(rôle1)

}

}

}

Pour chaque rôle dans ensemble des rôles {

Si {rôlejunior(rôle) existe} {

Pour chaque jrole1 dans rôlejunior(rôle) {

Pour chaque jrole2 dans rôlejunior(rôle) {

Si {jrole1 > jrole2} {

Supprimer jrole2 de rôlejunior(rôle)

}

}

}

}

}

Pour chaque rôle dans ensemble des rôles {

Pour chaque jrole dans rôlejunior(rôle) {

A rôle ajouter_héritage_relation_à jrole

}

A rôle retirer permissions redondante

}

Comme vous pouvez le noter, la déduction de la hiérarchie des rôles préliminaires est un processus bien structuré qui pourrait être adapté et développé dans une macro Excel. La démarche est simplifié, nous définissons comme rôle junior les rôles dont les permissions sont de vrais sous-ensemble du rôle senior auxquels ils sont rattachés. Par conséquent, il n'y a pas de contrôle de cohérence fonctionnel de ces nouvelles relations et donc nous ne définissons pas sémantiquement les nouvelles relations. Normalement, les rapprochements fonctionnels des rôles sont fait lors de la constructions du catalogue des contraintes. C'est-à-dire que quoiqu'il arrive les rôles du domaine GRH ne peuvent hériter de permission des rôles du domaine PAIE puisqu'il s'agit d'accès aux actions fonctionnelles.

Une aide peut aussi être apportée à la construction de cette hiérarchie de rôles en faisant appel aux graphes, puisque cet algorithme ressemble fort à une exploration de graphe. Nous pensons ici aux DAG (directed acyclic graphs) qui sont des graphes orientés sans cycles ( Figure 41). Un arbre est un DAG.

Figure 41 : exemple de DAG représentant une hiérarchie de rôles

Cette modélisation sous forme de graphe permet de mieux visualiser les impacts de modifications de permissions d'un rôle junior^7(*) (ou structure de rôle^8(*)). Dans le cadre d'HRa Suite 7, la hiérarchie est limitée à un niveau.

* ⁷Selon la nomenclature XACML R-BAC

* ⁸Selon la nomenclature HRa Suite 7