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

Les activités

Une activité est un regroupement d'actions fonctionnelles cohérentes (Données individuelles, Gestion des temps, etc) permettant à l'utilisateur d'effectuer des actes de gestion. Une activité concerne un ensemble de technologie faisant référence à une ou plusieurs structures de données.

On peut définir des activités spécifiques à un salarié, un manager ou un expert RH en précisant leur type d'accès.

La notion de technologie dans la définition de l'activité détermine les accès aux composants suivant :

· Applicatif Hra Space (Expert RH)

· Processus Guidés (Collaborateur et Manager)

· Exécution de jobs batch et ou rapports

· Autres (Documents)

Les rôles et les activités

Un code activité est rattaché à un modèle de rôle. Cela lui confère à l'utilisateur un ensemble d'habilitations spécifiques rattachées à sa mission.

Les activités associées à un utilisateur ayant un modèle de rôle donné lui permettent d'avoir accès à des actions fonctionnelles particulières liées à cette activité.

Pour une activité associée à un rôle, on peut :

· Autoriser son accès de façon permanente ou non

· Restreindre les dossiers liés à cette activité

L'accès aux données dans les activités

Pour chaque information de l'activité, on peut définir :

· Les droits d'accès aux données (Interdit, Lecture, Création/Suppression, etc.)

· La population des dossiers pour cette information

· La restriction de mise à jour

· Des actions sur les dossiers : Création, Suppression

La figure ci-dessous nous donne un aperçu synthétique des éléments nécessaires au paramétrage d'un rôle dans HRa Suite 7.

Figure 12 : Eléments de paramétrage d'un rôle dans HRa Suite 7

Les éléments à prendre en compte sont :

- La définition des Actions fonctionnelles

- Le regroupement des Actions fonctionnelles par Code Activité

- Le périmètre des populations

- La définition des modèles de rôles

- La définition des paramètres d'instance des rôles

- Les utilisateurs du système.

3.3 Ergonomie de l'application et Caractéristiques de HRa Space

La caractéristique essentielle de HRa Space est qu'il s'adapte à l'utilisateur de façon dynamique :

ï à l'aide des mécanismes de gestion des rôles,

ï aux zones fonctionnelles gérées par HRa Suite 7.

L'utilisateur accède à l'application selon les actions fonctionnelles qu'il doit effectuer. Une action fonctionnelle est définie en termes de droits, et de devoirs, selon les rôles auxquels elle est rattachée. Les droits et les devoirs occupent des zones spécifiques dans l'espace de travail. C'est la nature de l'action fonctionnelle qui détermine l'application qui sera utilisée pour effectuer l'action.

Pour chaque action fonctionnelle, HRa Space :

ï intègre tous les composants RH nécessaires à des besoins fonctionnels complexes,

ï implémente des fonctions RH évoluées (gestion des rôles, processus guidés, ...),

ï détermine la présentation et la navigation dans l'application,

ï gère les populations et les actions utilisateurs,

ï procure une ergonomie adaptée à chaque utilisateur.

3.3.1 Une interface utilisateur orientée métier

HRa Space adapte l'application, selon le rôle de l'utilisateur connecté. Le contenu de HRa Space est entièrement dynamique et dépend du contexte généré par les propriétés de l'utilisateur. Dans l'application, les rôles ne sont pas directement visibles, pourtant :

ï ils définissent les différents types d'accès,

ï ils déterminent la liste des domaines et des services auxquels ils sont associés,

ï ils permettent d'accéder à des composants qui les utilisent.

HRa Space fournit une interface utilisateur orientée métier. Ainsi, HRa Space :

ï distingue les zones de l'écran en fonction de leur orientation métier,

ï identifie la structure prédéfinie de l'écran,

ï identifie le contenu dynamique de l'écran,

ï effectue le lien entre l'ergonomie finale et le design de l'interface utilisateur.

L'organisation logique de HRa Space est directement fonction des rôles. En effet, HRa Space :

ï filtre les actions fonctionnelles : seules les actions fonctionnelles autorisées par les rôles sont accessibles,

ï organise et regroupe les actions fonctionnelles :

o HRa Space adapte l'interface utilisateur selon les rôles en ne faisant apparaître que les domaines et les thèmes ayant trait aux activités de l'utilisateur.

o les actions fonctionnelles sont triées par type d'accès (salarié, responsable, professionnel RH),

o les rôles exercés dans le même domaine fonctionnel sont regroupés dans le même onglet,

ï distribue : une fonction associée à un rôle est transmise au composant qui gère cette fonction.

3.3.2 Ecran type du salarié

La page ci-dessous représente l'écran type du salarié géré par HRa Space. On remarque une zone pour les fonctions collaboratives et une zone pour les actions fonctionnelles autorisées :

ï les actions fonctionnelles regroupées par thèmes,

ï les fonctions collaboratives (liées au workflow),

Figure 13 : écran type du salarié

3.3.3 Ecran type du responsable

La page ci-dessous représente l'écran type du responsable géré par HRa Space. On remarque :

ï les actions fonctionnelles regroupées par thèmes,

ï les fonctions collaboratives (liées au workflow),

ï un guide (recommandations et jauges) permettant de donner des informations supplémentaires en relation avec l'action fonctionnelle courante,

Figure 14 : écran type du manager

3.3.4 Page d'accueil Expert RH

L'expert dispose des fonctions collaboratives mais aussi d'un niveau supplémentaire que sont les domaines métier.

Figure 15 : écran type Expert RH

3.4 En conclusion.

Pour le seul aspect de la gestion des accès, nous avons vu, que tout au long de son histoire, le SIRH HR-Access a su rester en phase avec les grandes tendances de son époque. Maintenant compte-tenue de ses possibilités, nous aimerions élaborer une approche méthodologique pour construire des rôles correspondants aux besoins des utilisateurs l'entreprise. Actuellement, c'est l'approche empirique qui prédomine, car l'accès par les rôles est encore une approche nouvelle.

Nous allons étudier dans notre partie suivante, ce qui nous semble être les 3 piliers fondamentaux de cette ingénierie des rôles que nous voulons proposer :

· La confidentialité,

· L'ergonomie,

· Et le contrôle d'accès basé sur les rôles.

4 Est-il possible de protéger l'accès à l'information en facilitant son accès ?

L'accès à un système d'information doit être protégé et sécurisé. Des exigences juridiques l'imposent comme nous l'avons vu en page 10. Nous allons donc voir théoriquement par quels moyens. Nous verrons ensuite comment faciliter l'accès aux données utiles à l'utilisateur en étudiant ses intentions et l'ergonomie nécessaire pour atteindre ses buts. Après avoir déterminé ce que l'utilisateur ne doit pas voir, et ce qui lui est nécessaire, nous examinerons le corpus théorique du contrôle d'accès basé sur les rôles (R-BAC) qui sera le support de notre ingénierie des rôles.

4.1 Confidentialité : un des aspects fondamentaux de la sécurité

Parmi l'ensemble des caractéristiques qui constitue la sécurité informatique, nous en avons identifié cinq qui nous paraisse fondamentales.

L'authentification : elle consiste à s'assurer de l'identité d'un utilisateur avant de lui donner accès à un système ou à une application. C'est le processus de vérification des informations d'identification d'une entité de sécurité en fonction des valeurs d'un stockage d'identité. Les protocoles d'authentification tels que Kerberos version 5, Secure Sockets Layer (SSL), NTLM et l'authentification Digest protègent le processus d'authentification et évitent l'interception des informations d'identification (Microsoft 2004).

L'intégrité : elle désigne la capacité à s'assurer de la non-altération des informations d'origine, qu'elle soit accidentelle ou malveillante. C'est la propriété d'exactitude et de complétude des éléments essentiels. (SGDN / DCSSI / SDO / BCS 2004)

La disponibilité : elle concerne la garantie sur le bon fonctionnement d'une application, sa résistance vis-à-vis des pannes accidentelles et attaques incapacitantes. C'est la propriété d'accessibilité au moment voulu des éléments essentiels par les utilisateurs autorisés (SGDN / DCSSI / SDO / BCS 2004).

La traçabilité : elle consiste à stocker des traces de toutes interactions des utilisateurs avec les applications afin de pouvoir détecter des attaques ou des dysfonctionnements.

La confidentialité : elle consiste à empêcher la lecture d'informations par des personnes non habilitées ou mal intentionnées. C'est la propriété des éléments essentiels à n'être accessibles qu'aux utilisateurs autorisés (SGDN / DCSSI / SDO / BCS 2004).

La confidentialité peut être traitée en associant à chaque couple utilisateur-ressource une information indiquant si l'utilisateur peut accéder à la ressource et, si oui, quels droits d'accès il possède (droits de consultation, de modification, de création, de suppression ou une combinaison de ces divers droits). La granularité de la ressource varie selon les systèmes. Dans le cas le plus simple, c'est un fichier. Dans des systèmes plus complexes, cela peut être une partie d'un fichier. (Encarta® 2008 2007)

La confidentialité n'est pas qu'un dispositif technique. Elle nécessite une réflexion en amont pour décider quel utilisateur a droit à quelle ressource. Si nous partons de la question : « quel utilisateur a droit à quelle ressource ? ». Deux directions peuvent être choisies pour gérer la confidentialité, soit une approche par la sécurité et les risques qui sont la plus courante, soit une approche, plus originale, par l'ergonomie.

4.1.1 Approche par les risques.

Dans notre approche par les risques, nous allons étudier deux moyens :

- Le moyen juridique,

- Les moyens technologiques.

Chacun de ces moyens va nous permettre de nous poser les bonnes questions par rapport aux droits d'accès.