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

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

Il s'agit de déterminer ce qui doit être défini et paramétré dans une structure de rôle (rôle junior) et ce qui peut l'être dans un modèle de rôle. Pour nous aider, nous pouvons nous aider de la Figure 12 : Eléments de paramétrage d'un rôle dans HRa Suite 7 en page 32.

Si l'algorithme peut être générique à tout dispositif, en revanche le modèle de données doit être spécifique à l'infrastructure technique afin de faciliter son implémentation.

Le rôle à paramétrer est au centre du dispositif, avec en aval l'utilisateur auquel nous rattacherons le ou les rôles. En amont, nous retrouvons tout ce qui se rattache aux permissions.

La figure suivante nous semble bien résumer les interrelations entre les éléments à paramétrer. Ce modèle de données pourra nous aider à développer un outil pour soutenir notre démarche.

Figure 42 : modèle de données du paramètrage des rôles pour HRa S7

5.3.7 Définition du modèle R-BAC

La hiérarchie des rôles préliminaire, le catalogue des permissions et le catalogue des contraintes servent d'entrants au sous-processus de définition du modèle R-BAC. Le schéma suivant décrit l'ordre des activités correspondantes. Contrairement à la déduction de la hiérarchie des rôles préliminaires, cette démarche doit être outillée.

En premier lieu, il faut revoir tous les rôles marqués comme redondants. Le consultant doit décider avec l'expert du domaine fonctionnel, quel rôle est effectivement redondant, quel rôle doit être retiré du modèle, et quel rôle doit être conservé même s'il a été marqué comme redondant.

Jusqu'à présent le catalogue des contraintes ne contenait que les contraintes des permissions individuelles (voir 5.3.3 ci-dessus Identification des contraintes de permissions). Nous allons maintenant définir les contraintes des rôles. L'identification des contraintes est une tâche complexe qui nécessite de rencontrer les experts du domaine fonctionnel.

Figure 43 : sous processus de modélisation des rôles R-BAC

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

Il va s'agir pour nous de « nettoyer » les rôles paramétrés des permissions inutiles avant de les livrer et de les exploiter. Bien que nous ne soyons pas encore arrivés à cette étape du projet, nous pouvons anticiper le fait suivant : pour la modélisation des rôles, il y a deux niveaux (la structure de rôle, et le modèle de rôle). Un troisième niveau peut être créé si nous utilisons la possibilité d'affecter plusieurs rôles à un utilisateur. Pour rester dans la métaphore cinématographique, après les scénarios et les rôles, ce troisième niveau sera appelé « acteur pressenti ». Ces acteurs pressentis sont réparti dans 9 familles de rôles. Ces familles sont pour le Personnel Médical et le Personnel Non Médical :

· 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 serviront d'appui au travail de modélisation des rôles.

6 Résultats et perspectives

Nous voici arrivé au terme de notre voyage. Nous avons exploré des territoires qui s'ignoraient alors qu'il semble bien pouvoir se compléter. Il reste néanmoins encore quelques points à éclaircir.

6.1 Créer un espace de travail orienté métier en utilisant l'accès basé sur les rôles

Aborder la gestion des habilitations selon l'ergonomie et la confidentialité, nous a semblé une approche stimulante parce que peu d'auteurs rapprochent ces deux domaines ensemble. Chacun de ces domaines étaient traités séparément, la gestion de la sécurité et de la confidentialité d'un côté et l'ergonomie et les I.H.M. de l'autre. Certes ce sont chacun de vaste sujet. Nous pensons avoir réussi à les concilier grâce à l'approche novatrice du contrôle d'accès basé sur les rôles (R-BAC).

Les explications du peu de visibilité de cette approche peuvent avoir plusieurs origines :

· Ceux qui conçoivent le système doivent tout savoir,

· Ceux qui gèrent le système veulent tout voir,

· Ceux qui vendent le système veulent tout montrer,

Donc la question de la restriction des accès de l'utilisateur final aux écrans et aux données n'est pertinente pour aucun de ces intervenants. Elle complexifie (inutilement) leur travail. Nous pensons avoir démontré qu'il s'agit d'un « accessoire » important. De la conception (Saidani et Nurcan 2007) au développement (il a récemment été implémenté dans ASP.NET 2.0 (Schackow 2006)) petit à petit le concept « rôle » fait sa place dans le domaine de l'informatique. Nous pouvons penser que ceux qui vendent les systèmes informatiques le prendront en compte dans leur argumentaire de vente (comme c'est le cas pour HRa Suite 7) dans peu de temps. Nous pensons en particulier au marché du logiciel en ligne de type ASP ou SaaS.

R-BAC est une technologie qui offre une alternative au traditionnel contrôle d'accès discrétionnaire (DAC) et au contrôle d'accès obligatoire (MAC). R-BAC permet aux entreprises de définir et de faire appliquer des politiques de sécurité qui s'adapte naturellement à la structure de leur organisation.

La mise en place de R-BAC n'est pas une affaire simple. C'est pour cela que nous avons essayé de développer des outils méthodologiques pour mettre en place une ingénierie des rôles. Nous avons essayé de prendre en compte les enjeux de la confidentialité, les buts visés par l'ergonomie, de relier ces deux univers en s'appuyant sur le dispositif R-BAC en utilisant des méthodes inspirées de l'ingénierie des exigences tels que l'utilisation des scénarios pour en extraire nos « besoins » en permissions d'accès aux écrans et aux données.

6.2 Lacunes et points à développer

Néanmoins, nous sommes conscients qu'il reste encore des points à développer. Notamment en ce qui concerne l'attribution « automatique » ou dynamique d'un rôle en fonction du poste (emploi) affecté à l'utilisateur. Dans notre approche, bien que nous ayons développé certains éléments théoriques des contraintes contextuelles, nous n'avons pas rapproché le rôle de l'emploi de l'utilisateur. L'attribution des rôles est aussi une tâche non négligeable de l'ingénierie des rôles. Qu'est-ce qui plus proche d'un rôle dans un processus métier qu'un emploi ? Le principal problème est que la nomenclature des emplois est bien plus riche que celle des rôles. On pourrait nous objecter qu'une table de correspondance emploi/rôles est toujours envisageable. Cela mérite d'être expérimenté.

Un autre aspect évoqué mais non détaillé sont les impacts économiques de notre démarche. Nous nous sommes limités au SIRH HRa Suite 7 et il nous est difficile de dire si d'autre progiciel utilise les rôles dans leur habilitation d'accès puisque de toute façon l'accès basé sur les rôles n'est pas encore un argument de vente...