|
Confidentialité et ergonomie, personnaliser l'accès au SIRH avec RBAC( Télécharger le fichier original )par Christophe THOMAS Université Paris 1 Panthéon Sorbonne - MASTER M2 Management Système d'information et de Connaissances 2008 |
Définition des rôles et de leurs dépendances.Les rôles sont définis simplement par le nom du métier. Ils héritent du groupe d'acteur "expert RH"
· Définition des organisationsLes organisations suivent un schéma hiérarchique dont le sommet est l'entité que l'on veut analyser. Cette entité peut-être une société, une direction, un département...
Un utilisateur appartient en général à une organisation et possède un rôle (un métier). Cela définit ce que nous appellerons un profil. Nous pouvons avoir par exemple :
Nous avons maintenant pour chaque utilisateur : · L'identifiant principal · Le profil (organisation, rôle) · La liste effective des accès dont il a besoin pendant une période donnée · Les identifiants qu'il utilisera pour se connecter à ses applications cibles L'étape 3 va permettre de valider le modèle afin que la politique d'accès finale reflète le plus possible la réalité de l'organisation. Cette étape se fera en enrichissant et en précisant certaines relations.
Nous avons à présent pour chaque utilisateur : · L'identifiant principal (virtuel si nécessaire) · Le profil (organisation optimisée, rôle) · La liste réelle des accès qu'il utilisera pendant une période donnée · Les identifiants qu'il utilisera pour se connecter à ses applications cibles
Les éléments fournis par cette méthode empirique sont : · La liste des règles permettant d'associer un profil (organisation, rôle) à une application ou un système. · La liste des exceptions permettant en complément d'associer un utilisateur à une application ou un système. · La liste exhaustive des droits d'accès en appliquant la politique définie : pour chaque règle les utilisateurs sélectionnés ainsi que les identifiants applicatifs associés. Cette approche empirique donne une base de travail, mais manque de formalisme pour être pérenne. Elle comporte aussi de nombreux éléments induits. Il n'est pas dit comment sont extrait les besoins Avec ce que nous avons étudié et vu en page 45 ce n'est pas seulement l'interface qui compte, mais l'interaction et les intentions de l'utilisateur: · la séquence d'actions nécessaires pour accomplir une tâche · l'adéquation entre le système et le contexte dans lequel il est utilisé (Beaudouin-Lafon 2000) Les concepts sous-jacent de l'intentionnalité sont maintenant utilisées dans la mis au point de systèmes multi-agents (SMA). Elle peut nous aider à établir le modèle comportemental de l'utilisateur (buts, plans d'action, rôles...). Quoi de mieux que l'utilisation de scénario pour mettre en lumière les plans d'action et les rôles en discerner les buts ? Voila pourquoi une approche basée sur l'utilisation de scénario nous a paru pertinente. Il existe plusieurs approches pour aborder l'ingénierie des rôles. La première concerne l'approche basée sur les scénarios. Cette approche (Neumann et Strembeck 2002) est axée sur l'élaboration de scénarios pour l'ingénierie des rôles fonctionnels dans R-BAC. Dans cette approche, chaque tâche est décrite en utilisant un ensemble de scénarios. Ensuite chaque scénario est décomposé en une série d'étapes. Parce que chaque étape est associée à une opération d'accès particulier, chaque scénario est lié à un ensemble de permissions. Cette approche nous a semblé pertinente par rapport à notre problématique. Nous allons donc étudier plus en détail cette nouvelle approche d'ingénierie des rôles utilisant les scénarios. Le concept de scénario a une importance fondamentale pour la présente démarche. En raison de la forte importance des facteurs humains dans l'ingénierie des rôles, les scénarios sont un bon moyen pour diriger notre processus. Nous utilisons des scénarios pour trouver les autorisations nécessaires (relatif à R-BAC) et définir les tâches (relatif à l'ergonomie). Dans un processus d'ingénierie des rôles basé sur l'utilisation des scénarios, les scénarios d'un système d'information sont utilisées pour définir les tâches et en « dériver » les permissions. En général, un scénario décrit une séquence d'actions et d'événements. Par exemple : « enregistrer un nouveau salarié dans un système d'information des ressources humaines ». Ainsi, chaque scénario se déroule en plusieurs étapes, et un sujet effectuant un scénario doit posséder toutes les autorisations qui sont nécessaires pour mener à bien les différentes étapes de ce scénario. A son tour, une tâche est composée d'un ou plusieurs scénarios, et des tâches peuvent être combinées pour former des profils de travail. Un profil de travail regroupe un ensemble de tâches qu'un certain type de sujet est autorisé à exercer. Dans un environnement R.H. différents profils de travail pour les gestionnaires Paie, les secrétaires et les managers sont nécessaires, par exemple. Dans le processus d'ingénierie des rôles, les profils de travail sont ensuite exploités conjointement avec le catalogue des permissions et le catalogue des contraintes pour définir un modèle R-BAC concret. Toutefois, l'approche axée sur le scénario présenté dans (Neumann et Strembeck 2002) ne fournit qu'une orientation générale pour la définition des sous-processus (exogène). Notre but sera de préciser et de faire appliquer les contraintes dans un contexte R-BAC environnement nous a conduit à la définition du processus d'extension proposés dans la présente section. L'ingénierie des exigences axée sur les Buts utilise les liens Buts/Objectifs afin de susciter, de préciser, d'analyser et de valider les exigences. Nous aborderons la combinaison d'approches scénario/buts. Des aperçus plus complet de l'ingénierie des exigences basé sur les buts peuvent être trouvés dans (Van Lamsweerde 2001) et (Kavakli 2002). Les buts et les scénarios ont des caractéristiques complémentaires (Van Lamsweerde 2001). Les buts sont généralement abstraits et déclaratif. Ce sont les objectifs de haut niveau de l'entreprise, de l'organisation ou du système. Les scénarios sont concrets, ce sont : soient des récits, soient des descriptions de procédures. Ils décrivent des situations réelles en utilisant des exemples et des illustrations. D'où, en combinant les avantages des buts et ceux des scénarios nous pouvons trouver un moyen efficace d'obtenir et de valider les exigences de nos contraintes d'accès. Les buts sont réalisés au moyen de scénarios et raffiné en exigences. De même réciproquement, les scénarios peuvent être utilisés pour aider à découvrir les buts. Cette méthode d'analyse des exigences basées sur les buts utilise la hiérarchie des buts entre eux pour organiser des exigences issues des scénarios, des obstacles aux buts, des contraintes contextuelles (Antón 1996). D'autres organisent hiérarchiquement des scénarios selon les objectifs et leurs contraintes dans leurs « uses cases » (Cockburn 1997). Colette Rolland propose une approche bidirectionnelle avec un couplage scénario- objectif entre découverte des buts et de création de scénario (Rolland, Souveyet et Ben Achour 1998). H. Kaindl a proposé un processus systématique de conception basée sur un modèle combinant les scénarios avec des objectifs et des fonctions (Kaindl, A Design Process Based on a Model Combining Scenarios with Goals and Functions 2000). Dans ce modèle combiné, le «but» sert de lien entre les fonctions et les objectifs: un système de fonctions globales qui ont certains objectifs et ces buts correspondent avec les (sous-) buts des utilisateurs. Le But a également été intégré aux scénarios pour modéliser des tâches (Kaindl 1995). L'ingénierie des exigences différencie les exigences fonctionnelles et les exigences non-fonctionnelles (relative à la qualité). Les exigences fonctionnelles définissent les buts du système, c'est-à-dire ce pour quoi le système est construit (l'utilisation intentionnelle du système). Les exigences non fonctionnelles définissent des demandes comme la maintenabilité, interopérabilité ou la performance. Pour capturer, illustrer et organiser les exigences fonctionnelles trois catégories générales de modèles d'exigences ont été retenues : Les modèles de buts : les buts décrivent les exigences sur un niveau abstrait. Les buts sont, par exemple, bien adaptés pour capturer les exigences au niveau des processus de gestions. Ainsi, ils peuvent être utilisés pour communiquer avec la direction. Les modèles de scénarios : les scénarios décrivent l'usage du système sous forme d'actions et de séquences d'évènements. Les scénarios sont bien adaptés pour modéliser un système à partir de la perspective utilisateur. Ils facilitent la communication avec les utilisateurs finaux. Les modèles de solutions : ces modèles capturent la solution ou les solutions visées en détail et comblent l'écart entre les modèles d'exigences et l'architecture du système. Par conséquent ils facilitent la communication entre l'équipe en charge des exigences et l'équipe en charge de l'implémentation. UML est le standard « de facto » des modèles orientés solutions. Ses différents types de diagrammes peuvent être utilisés dans toutes les phases du développement. (Rolland, et al. 1998) proposent un framework pour synthétiser toute l'abondante littérature au sujet des scénarios. Ce cadre de référence propose de considérer les scénarios selon quatre points de vues différents, chaque vue permettant de capter un aspect pertinent des scénarios.
Figure 29 : les quatre vues sur les scénarios (Rolland, et al. 1998) La vue selon la forme porte sur le mode d'expression d'un scénario. Est-ce que les scénarios sont décrits de façon formalisé ou informelle, de façon statique, animées ou interactif. La vue selon le contenu concerne le genre de connaissance qui est exprimé dans un scénario. Les scénarios peuvent, par exemple, se concentrer sur la description de fonctionnalités d'un système, ou ils peuvent décrire une vue plus large dans lequel la fonctionnalité est intégrée dans un plus vaste processus de gestion avec divers intervenants et des ressources liés à celui-ci. La vue selon les buts est utilisée pour saisir le rôle que joue un scénario dans le processus d'ingénierie des exigences. Il s'agit de décrire les fonctionnalités d'un système, d'explorer des alternatives de conception ou d'expliquer les inconvénients ou l'inefficacité d'un système. Voilà des exemples de rôles qui peuvent être assignés à un scénario. La vue selon le cycle de vie suggère de considérer les scénarios comme des objets existant et évoluant dans le temps à travers l'exécution d'opérations au cours du processus d'ingénierie des exigences. La création, la suppression ou le raffinement sont des exemples d'utilisation de ce type d'opérations. La question de la persistance contre l'éphémère est également un élément abordé dans ce point de vue.
Dans l'approche basée sur les scénarios, chaque action et évènement dans un scénario peut être vu comme une étape. Cette étape peut être associée avec une opération d'accès particulière. Ainsi un scénario peut être une source intéressante pour la dérivation des permissions qui sont appliquées dans un ordre particulier pour atteindre un but prédéfini. Chaque définition de tâche (par exemple procéder à la saisie d'un jour d'absence) correspond à un ou plusieurs scénarios. Ces tâches sont de nouveau combinées pour former un profil de travail. Le profil de travail comprend toutes les tâches d'un certain type d'employé peut accomplir. De ce fait chaque scénario peut être relié à un ensemble de permissions. Il est donc possible de tirer des permissions pour un profil de travail directement des tâches ou d'un scénario. L'ingénierie des rôles dirigés par les scénarios est composée de sept activités majeures qui possèdent leur propre sous-processus.
Figure 30 : Macro-processus de l'ingénierie des rôles Dans la Figure 30 nous voyons que les activités 1 à 4 forment un cycle qui est répété jusqu'à ce que le modèle de scénario soit complet. C'est le pré requis pour les activités 5 à 7. Tout le processus (les activités 1 à 7) est conçu pour être exécuté de façon itérative et incrémentale. Chaque itération résulte d'une nouvelle étape de l'évolution des modèles. Nous allons maintenant préciser les interrelations entre les modèles et les livrables du processus. |
|
