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

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

Sur notre projet, il a été défini neuf grandes familles de rôles.

ï Expert RH,

ï Responsable valideur,

ï Trésorerie générale (TG),

ï Contrôleur financier (CF),

ï Consultation des données,

ï Agent,

ï Candidat,

ï Paramétrage fonctionnel,

ï Administration / paramétrage applicatif

Ces familles n'ont aucun impact applicatif, elles servent d'appui au travail de définition des rôles et permettent d'identifier les acteurs pressentis. L'objectif des scénarios va être de découvrir les actions fonctionnelles. Le but des actions fonctionnelles pour chaque rôle est de donner une vue d'ensemble des permissions par rôle afin de pouvoir vérifier la cohérence générale du rôle et son adéquation avec le métier du futur utilisateur.

En partant de la synthèse des actions fonctionnelles par rôle il devient possible d'attribuer de façon précise les actions fonctionnelles nécessaires au rôle. Ces actions fonctionnelles correspondent aux transactions de l'outil HR Access ou SAP et constituent le degré le plus fin possible pour les habilitations sur les actions.

L'action fonctionnelle correspond souvent dans le cas d'HR Access à la page web. Ce qui signifie que par défaut, un accès sur une action fonctionnelle induit l'accès à toutes ses fonctionnalités et à toutes les informations (dont le périmètre de population a été paramétré dans le rôle) contenues sur cette page.

5.3.2 Déterminer les permissions des scénarios

La recherche des origines des permissions est décrite dans la figure suivante. Le but de cette activité est l'identification des permissions qui sont nécessaire pour accomplir les scénarios d'utilisation du système. Le résultat de ce sous-processus est l'établissement d'un catalogue des permissions (voir Figure 32).

Figure 34 : sous-processus de recherche des permissions

Durant la phase de recherche de permissions chaque scénario est examiné. Pour identifier les permissions, nous examinons chaque séquence du scénario et vérifions quelle opération un sujet (un utilisateur) a besoin pour accomplir cette étape. Pour chacune de ces opérations nous définissons et cataloguons une paire (opération, objet) dans le catalogue des permissions.

Certaines étapes de base comme « saisir dossier agent » sont présent dans plusieurs scénarios. Chaque permission n'est enregistrée qu'une seule fois dans le catalogue des permissions. Chaque permission peut être reliée à plusieurs scénarios.

Les permissions peuvent être différenciées en permission abstraite et en permission élémentaire (Sandhu, et al. 1996). C'est-à-dire en permission avec différent niveau de granularité. Une permission abstraite comme « demande un n° de dossier » est composé de permission élémentaire comme « lire le dossier » ou ensuite « mettre à jour le dossier ». L'approche basé sur les scénarios rend possible la détection de ces niveaux de granularité. Comme nous l'avons déjà mentionné plus haut, un scénario peut être approfondi dans de nouveaux scénarios. Ces nouveaux scénarios pourront servir à identifier des permissions plus élémentaires^6(*).

HRA suite 7 dispose d'un modèle conceptuel de données élaborés (voir Figure 7 : le modèle conceptuel des données pour la gestion du personnel avec HR-Access). Il dispose aussi de trois catégories d'acteurs qui correspondent au trois grandes populations qui doivent accéder au SIRH, le professionnel RH, le manager et l'employé. Ces catégories d'acteurs sont similaires à des modèles de rôles R-BAC et peuvent être instanciés.

· L'employé peut être instancié par son identifiant. Il ne peut accéder seulement qu'à son dossier. Reste à lui attribuer les écrans pour y accéder (voir en page 34).

· Le manager peut être instancié par l'unité organisationnelle dont il est responsable. Il accède ainsi à son UO et aux UO subordonnées. L'ergonomie de ses accès est définie en page 34.

· Le professionnel RH est instancié par le centre de gestion dont il a la charge. Ce centre de gestion peut être différent de son UO d'affectation.

Pour les deux premières catégories d'acteurs les permissions sont simples et peu nombreuses. Le problème est plus complexe car il y a de nombreuses catégories de « professionnels RH » dans les directions de ressources humaines d'importantes structures. De la gestion administrative du personnel de base à l'expert RH, en passant par le gestionnaire Paie ou le responsable de la formation, chacun de ces intervenants a des raisons légitimes d'accéder au SIRH. C'est pour cela que HRA Suite 7 a défini trois axes de permissions :

Processus métiers	Populations	Données accessibles
Codes activités Codes Workflow	Populations autorisées rattachées au rôle	Droits d'accès Filtres sur occurrences Restrictions de mise à jour ...

Ces trois axes vont nous aider à structurer et affiner notre catalogue des permissions.

Par rapport au framework technique d'HRa Suite 7 vu dans le Paramétrage technique des rôles en page 31, les permissions à identifier sont les suivantes :

Figure 35 : Liste des permissions à identifier pour un rôle

Nous pouvons retranscrire ces permissions dans le tableau suivant :

Tableau 11 : Tableau permettant de lister les permissions nécessaires à l'exécution d'un scénario

Scénario	Catégorie d'acteur	Structure de données			Action Fonctionnelle	Droit d'accès aux données
		Dossiers Agent	Dossiers Réglementation	Dossiers Structures		Mode d'accès	Actions

* ⁶ Dans la pratique les scénarios servant à identifier les permissions élémentaires sont faits par les développeurs, alors que les scénarios explicitant les permissions abstraites sont rédigés par les consultants fonctionnels.