WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

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
  

Disponible en mode multipage

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

U N I V E R S I T É P A R I S 1 P A N T H É O N - S O R B O N N E

MASTER MANAGEMENT DES ORGANISATIONS - M2

SPÉCIALITÉ PROFESSIONNELLE : MANAGEMENT DES SYSTÈMES

D'INFORMATION ET DE CONNAISSANCE

MÉMOIRE

CONFIDENTIALITE ET ERGONOMIE, PERSONNALISER L'ACCES AU S.I.R.H. AVEC LE CONTROLE D'ACCES BASE SUR LES ROLES (R-BAC)

RÉDIGÉ ET SOUTENU PAR :

CHRISTOPHE THOMAS

PROMOTION JB 2007

 

DIRECTEUR DE MÉMOIRE :

INDIQUER ICI LE NOM DU DIRECTEUR DE MÉMOIRE

 

DATE DE LA SOUTENANCE :

LAISSER CETTE LIGNE EN BLANC ET NE RIEN INSCRIRE SI VOUS NE LA CONNAISSEZ PAS ENCORE

INSTITUT D'ADMINISTRATION DES ENTREPRISES DE PARIS

L'UNIVERSITÉ N'ENTEND DONNER AUCUNE APPROBATION NI IMPROBATION AUX OPINIONS ÉMISES DANS CE MÉMOIRE : CES OPINIONS DOIVENT ÊTRE CONSIDÉRÉES COMME PROPRES À LEUR AUTEUR.

CONFIDENTIALITÉ ET ERGONOMIE, PERSONNALISER L'ACCÈS AU S.I.R.H. ET PROPOSER UN ENVIRONNEMENT DE TRAVAIL INFORMATIQUE ORIENTÉ MÉTIER AVEC LE CONTRÔLE D'ACCÈS BASÉ SUR LES RÔLES (R-BAC)

Table des matières

1 Introduction 6

1.1 Les rôles : clés des nouveaux paradigmes des accès au système d'information 6

1.2 Trouver comment conjuguer confidentialité et ergonomie avec l'ingénierie des rôles 6

2 Quelle solution pour personnaliser l'accès au système d'information 9

2.1 Comment différencier les accès au système d'information de l'entreprise ? 9

2.1.1 les nouvelles tendances RH imposent de déléguer certaines tâches à différentes catégories d'acteurs dans l'entreprise 9

2.2 Pourquoi avoir une approche ergonomique ? 14

2.3 La gestion des identités et des accès 15

2.3.1 gestion des accès 15

2.3.2 gestion des identités 16

2.3.3 De la gestion des rôles à l'ingénierie des rôles 16

2.4 fournir un environnement de travail dynamique grâce à un système d'information dirigé par les rôles 16

2.5 Les enjeux économiques de la mise en place d'un dispositif R-BAC 18

3 De GIP à HR-Access, des progiciels en phase avec leur époque 20

3.1 Le SIRH : HRA Suite 7 20

3.1.1 Son histoire et ses aspects techniques 20

3.1.2 Le Modèle Conceptuel des Données du SIRH 22

3.1.3 Aspects fonctionnels 22

3.1.4 La gestion de la confidentialité avec la gestion des accès par profils 23

3.2 Les nouveautés de HRA Suite 7 28

3.2.1 Les rôles 28

3.2.2 Paramétrage technique des rôles 31

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

3.3.1 Une interface utilisateur orientée métier 33

3.3.2 Ecran type du salarié 34

3.3.3 Ecran type du responsable 34

3.3.4 Page d'accueil Expert RH 34

3.4 En conclusion. 35

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

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

4.1.1 Approche par les risques. 37

4.2 Ergonomie 43

4.2.1 ISO 13407 43

4.2.2 ISO/TR 16982 : 44

4.2.3 Conception basée sur les intentions de l'utilisateur 45

4.2.4 Conception basée sur des Critères d'ergonomie 47

4.2.5 Conception basé sur le contexte de l'utilisateur 48

4.3 R-BAC 50

4.3.1 Assembler l'authentification à l'autorisation 50

4.3.2 Utilisateurs, sujets, objets, opérations et permissions 50

4.3.3 Description formelle du R-BAC par Ferraiolo et Kuhn 51

4.4 Définir un modèle conceptuel des données pour R-BAC 53

4.4.1 Utilisateurs 53

4.4.2 Action fonctionnelle 54

4.4.3 règles métiers (business rules) 54

4.4.4 Rôle 54

4.4.5 Unité organisationnelle 54

4.4.6 permissions 54

4.4.7 contextes 54

4.4.8 Exclusions 54

4.4.9 Risques 55

4.5 règles d'héritage des permissions 55

4.5.1 Héritage des permissions par les rôles 55

4.5.2 Héritage organisationnel des permissions 55

4.5.3 Héritage hiérarchique des permissions 55

4.5.4 Héritage des permissions par les couples (rôle, organisation) 55

4.5.5 Les exclusions 56

4.5.6 Propositions de modèle conceptuel pour un R-BAC étendue 56

4.5.7 Les limites de R-BAC 56

4.5.8 Les différentes catégories de contraintes dans R-BAC 57

4.5.9 Contraintes contextuelles 59

5 A la recherche d'une ingénierie des rôles 62

5.1 Méthode empirique 62

5.1.2 La collecte des accès nécessaire 63

5.1.3 La définition des attributs des utilisateurs. 63

5.1.4 La validation du modèle. 64

5.1.5 La création de la politique à partir des accès nécessaire 64

5.1.6 Analyse critique du modèle existant des déclarations faites dans les systèmes et applications cibles. 65

5.2 ingénierie des rôles 65

5.2.1 ingénierie des rôles basés sur les scénarios 65

5.2.2 Ingénierie des rôles basés sur les buts 66

5.2.3 Une ingénierie des exigences pour les rôles 66

5.2.4 Un cadre de référence pour les scénarios : 67

5.2.5 Appliquer l'utilisation des scénarios à l'ingénierie des rôles. 68

5.2.6 Interrelations des modèles et définition documentaire 69

5.2.7 Des profils de travail aux rôles 71

5.3 Mise en oeuvre du processus d'ingénierie des rôles 72

5.3.1 Identifier et formaliser des scénarios d'utilisation 72

5.3.2 Tirer les permissions des scénarios 75

5.3.3 Identification des contraintes de permissions 77

5.3.4 Rationalisation des modèles de scénarios 79

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

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

5.3.7 Définition du modèle R-BAC 84

6 Résultats et perspectives 86

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

Glossaire : 88

Index 89

Bibliographie 91

1 Introduction

1.1 Les rôles : clés des nouveaux paradigmes des accès au système d'information

Le système d'information n'existe pas pour lui-même, mais pour rendre service à un utilisateur ou un groupe d'utilisateurs. C'est l'utilisateur qui déclenche le processus de gestion. C'est lui qui donne ou reçoit les informations du système d'information (S.I). L'utilisateur qui donne les informations en entrée peut ne pas être le même que l'utilisateur qui déclenche le processus ou celui qui bénéficie du résultat. L'utilisateur n'est pas le même parce qu'il a un rôle différent dans le processus d'entreprise. Dans cette étude nous nous intéresserons au rôle comme moyen d'accès au SI.

Depuis plusieurs années, de plus en plus d'auteurs font appel aux rôles pour modéliser les processus d'entreprise. Nous pouvons prendre par exemple la multi-méthode EKD-CMM élaboré par le CRI à l'IAE de Paris.

Dans la façon de modéliser d'EKD-CMM, les entreprises forment des réseaux de processus reliés afin d'atteindre leurs objectifs. Ce qui se passe dans les processus est regardé en termes de rôle que les individus ou les groupes jouent afin de réaliser leurs tâches. Les utilisateurs exécutent des activités pour atteindre les objectifs de l'entreprise. Les activités sont portées par des rôles différents suivant les processus métier. Le modèle d'acteur/rôle vise à décrire comment des acteurs sont reliés à chaque autre et ainsi qu'aux buts. Ce modèle de rôle/activité est utilisés dans EKD-CMM pour définir les processus d'entreprise, la façon ils consomment ou produisent des ressources pour atteindre les objectifs de l'entreprise.

Alors que EKD-CMM utilise les rôles pour participer à la définition du système à construire, notre approche des rôles sera différente pour plusieurs raisons. Le système d'information que nous souhaitons implémenter pré-existe, il s'agit d'un système d'information des ressources humaines (SIRH). Il couvre 85 % du besoin. Des adaptations seront à faire, mais une infrastructure technique et un ensemble d'outils sont disponible. Les rôles doivent nous servir définir les accès à l'infrastructure et aux outils nécessaires à un groupe d'utilisateur devant exercer les mêmes tâches. Il s'agit donc d'une définition à posteriori des rôles. Cette définition des rôles nous la voudrions dynamique afin qu'elle s'adapte aux contextes du sujet qui utilise le rôle.

1.2 Trouver comment conjuguer confidentialité et ergonomie avec l'ingénierie des rôles

Nous avons vu que les applications informatiques en entreprise doivent être maintenant accédées par une multitude d'utilisateurs. Ces utilisateurs ont des attentes et des besoins différents par rapport à cette application. Ces attentes et ces besoins peuvent être regroupées et liées dans des rôles. D'autres contraintes que les attentes et les besoins de l'utilisateur doivent être prise en compte. Ce sont les contraintes de confidentialité et les contraintes d'ergonomie. Pour être ergonomique, l'interaction Homme-Machine à besoin d'un contexte. Les rôles et l'organisation de l'utilisateur peuvent fournir le contexte recherché.

Il va donc s'agir pour nous, d'identifier les rôles et d'identifier les entités nécessaires aux tâches de l'utilisateur. Ainsi, l'utilisateur ne verra que ce qu'il a le droit de voir et ne pourra effectuer que des tâches et des actions déterminées sur des populations dédiées selon le profil qui lui a été attribué. De façon induite, le contrôle d'accès basé sur les rôles procure une ergonomie adaptée à chaque utilisateur: Une interface utilisateur orientée métier. C'est l'ergonomie qui guide l'élaboration du R-BAC et non plus la sécurité.

Formulé différemment, cette démarche d'« ingénierie des rôles » reposera sur la gestion des habilitations et la gestion de la sécurité.

La gestion des habilitations se base sur la définition de trois grands principes :

- Les droits d'actions

Scénario : L'utilisateur X a le droit de créer un dossier dans le cadre du processus d'Embauche.

- Les droits d'actions dans quel périmètre

Scénario : L'utilisateur X a le droit d'effectuer une action d'embauche uniquement dans le site A.

- Les acteurs des actions

Scénario 1 : Acteur 1 est un utilisateur ayant les habilitations d'Expert Formation en charge uniquement de la Formation dans le site A

Scénario 2 : Acteur 2 est un utilisateur ayant les habilitations de Gestionnaire GA et Gestionnaire formation pour le site A.

L'attribution des habilitations à un acteur se fera en fonction de ses attributions métiers. Par exemple, un Gestionnaire Paie qui dans ses attributions n'est en charge que de la Paie ne se verra attribuer que les habilitations liées à la Paie.

La sécurité dans la gestion des habilitations garantie :

- La qualité des données

Exemple : C'est le fait de s'assurer que les données modifiables ne le sont que par les utilisateurs ayant reçus les habilitations.

- La confidentialité des données

Scénario 1 : C'est de s `assurer qu'un gestionnaire en charge de la paie ne verra que la paie de son site d'affectation.

Scénario 2 : C'est de s'assurer qu'un gestionnaire qui n'est pas en charge de la paie des cadres dirigeants ne puisse pas voir la population des cadres dirigeants.

Scénario 3 : S'assurer que des données médicales qui font partie du dossier médical de l'agent ne soit visible que par le médecin du travail.

Les applications du SIRH (SAP Hr et Hr Access) permettent de définir et d'attribuer des autorisations spécifiques aux utilisateurs du système selon leurs fonctions, leurs responsabilités et leur contexte d'utilisation. Pour pouvoir définir et attribuer ces autorisations, un travail en amont va être nécessaire. Par où commencer ? Quelles vont être les informations à collecter ? Comment discerner les informations utiles des informations superflues ? De quoi a-t-on besoin pour paramétrer les rôles ? L'objectif de ce mémoire va être, pour moi, de faire l'inventaire des fondations théoriques aux éléments pratiques, pour construire une méthode de travail pour définir les rôles qui permettront d'accéder au SIRH.

Comme nous venons de le voir, le fait d'utiliser des scénarios est une approche intéressante. Elle permet d'expliquer concrètement les aspects d'un problème. Elle est proche des attentes de l'utilisateur. Nous pensons qu'elle nous permettra de trouver les éléments que nous recherchons pour construire le paramétrage des rôles dans notre application.

2

2 Quelle solution pour personnaliser l'accès au système d'information

2.1 Comment différencier les accès au système d'information de l'entreprise ?

De nos jours, les progiciels métiers ont envahi le quotidien des employés et cadres de l'entreprise. Ces progiciels en sont à leur troisième, voire énième version. Chaque nouvelle version étant enrichit de nouvelles fonctionnalités issues de la capitalisation faites sur des projets d'implémentations majeurs, d'autres venants d'un logiciel racheté par l'éditeur à un autre éditeur. Les multiples fonctionnalités rajoutées à chaque génération ont fait des progiciels un énorme framework qui répond à un maximum de besoins d'une ou de plusieurs directions de l'entreprise.

Ce qui est bien pour le niveau stratégique ne l'est pas nécessairement pour le niveau opérationnel. Avoir accès à une centaine d'écrans peut nuire à la productivité de l'utilisateur final. Un travail est à faire sur l'ergonomie de l'application. D'autre part, avoir accès à des centaines d'écrans implique que l'utilisateur peut accéder à des pages qui ne le concernent pas à plus d'un titre. Il y a donc un travail à faire sur la confidentialité.

Figure 1 : Les buts des utilisateurs sont différents lorsqu'ils accèdent au S.I.

La figure 1 illustre notre propos : Comment différencier les accès au système d'information de l'entreprise ? Notre réponse est d'expliquer comment le rôle de l'utilisateur dans l'entreprise peut être un critère discriminant d'accès à ce S.I.. Pour certains S.I. il faut gérer des milliers, voire plusieurs milliers d'utilisateurs. L'objet de cette étude va être de trouver des attributs discriminants de l'utilisateur pour industrialiser la gestion des accès aux entités du S.I. : accès aux données qui relève du domaine de la confidentialité et accès aux autres composants du S.I. (pages, actions fonctionnels, workflows...). Il s'agira de proposer une ingénierie des rôles (He 2007)

2.1.1 les nouvelles tendances RH imposent de déléguer certaines tâches à différentes catégories d'acteurs dans l'entreprise

Cette différenciation des accès devient un enjeu majeur avec la délégation de certaines tâches de saisie directement par les intéressés eux-mêmes.

Jusqu'à présent le problème des accès aux systèmes d'information pouvait être éludé par le fait que chaque groupe d'utilisateurs avait son application. Une application de saisie des temps pour les salariés, était interfacée avec une application de gestion des plannings, qui était interfacée avec l'application de gestion administrative pour les gestionnaires RH, qui elle-même était interfacée avec une application paie pour les gestionnaires Paie. Ces multiples applications avec leurs interfaces faisaient les beaux jours des urbanistes.

Figure 2 : à chaque groupe son application

Maintenant ces différents processus métiers sont inclus dans un même système d'information des ressources humaines (comme c'est le cas d'HR Access Suite 7 qui sera le support de notre étude de cas.

Autrefois, les applications étaient bien compartimentées puisque sur de systèmes différents. Qu'en est-il maintenant que tout a été regroupé sur un même système ? Exigences juridiques à prendre en compte en plus des exigences métier. Quelle méthode pour définir nos accès utilisateurs ?

Exigences juridiques des accès au S.I.

Tout le monde ne doit pas tout voir

Les exigences de confidentialité sont réglementées en France. La CNIL a publié un guide de travail où elle indique les sept principes clés de la confidentialité du SIRH (CNIL Commission Nationale Informatique et Liberté 2005).

Le principe de finalité

Les données à caractère personnel ne peuvent être recueillies et traitées que pour un usage déterminé et légitime. (...)Tout détournement de finalité est passible de sanctions pénales. De même, l'ensemble des objectifs poursuivis dans le cadre de l'informatisation doit être clairement exprimés (...).

Le principe de proportionnalité

Le traitement de données personnelles envisagé ne doit pas conduire à apporter aux droits et libertés des personnes de restrictions qui ne seraient pas proportionnées au but recherché (article L.120-2 du code du travail).

Le principe de pertinence des données

Les données personnelles doivent être adéquates, pertinentes et non excessives au regard des objectifs poursuivis.

Les données ne peuvent être conservées dans un fichier de façon illimitée

Les informations ne peuvent être conservées de façon indéfinie dans les fichiers informatiques. Une durée de conservation doit être établie en fonction de la finalité de chaque fichier.

La sécurité des données doit être assurée

Ce cinquième principe est important pour notre problématique. L'employeur, en tant que responsable du traitement, est astreint à une obligation de sécurité : il doit définir les mesures nécessaires pour garantir la confidentialité des données (sécurité des matériels, mots de passe individuels, habilitations d'accès définies en fonction des besoins réels de chaque intervenant...).

Ainsi, les données à caractère personnel ne peuvent être consultées que par les personnes habilités à y accéder en raison de leurs fonctions. Elles peuvent néanmoins être communiquées à des tiers autorisés en application de dispositions législatives particulières (inspection du travail, services fiscaux, services de police...).

Le principe de transparence

Lors de l'informatisation du service du personnel, les employés concernés doivent être clairement informés des objectifs poursuivis, du caractère obligatoire ou facultatif de leurs réponses, des destinataires des données et des modalités d'exercice de leurs droits « informatique et libertés » (droit d'accès, de rectification et d'opposition). Cette information peut être diffusée par tout moyen. Elle doit être portée sur les questionnaires établie par l'employeur. Enfin, l'employeur doit adresser une déclaration préalable à la CNIL sauf, pour les traitements les plus courants, (cf. www.cnil.fr). Cette déclaration est ensuite communicable à toute personne qui en fait la demande.

Le respect des droits des employés ou des candidats à un emploi

Toute personne peut demander au détenteur d'un fichier de lui communiquer toutes les informations la concernant contenues dans ce fichier. Elle a également le droit de faire rectifier ou supprimer les informations erronées. Toute personne a le droit de s'opposer, pour des motifs légitimes, à ce que des données à caractère personnel la concernant soient enregistrées dans un fichier informatique. Ainsi un employé peut s'opposer à figurer dans un fichier s'il avance des motifs légitimes (défaut manifeste de confidentialité, manque d'information sur les objectifs poursuivis...) que l'employeur doit apprécier. En revanche, un employé ne peut s'opposer au recueil de données nécessaires au respect d'une obligation légale (ex. : déclarations sociales obligatoires, éléments de calcul du salaire...).

Garder des traces parce que la trace est un commencement de preuve

Pour se connecter au système d'information, l'utilisateur devra donner un identifiant et un mot de passe. Cet identifiant sera sa signature pour les fichiers de journalisation des connexions destinés à identifier et enregistrer toutes les connexions ou tentatives de connexion à un système d'informations. Les fichiers de journalisation constituent une mesure de sécurité, généralement préconisée par la CNIL dans le souci que soient assurées la sécurité et la confidentialité des données à caractère personnel, lesquelles ne doivent pas être accessibles à des tiers non autorisés ni utilisées à des fins étrangères à celles qui justifient leur traitement. Ils n'ont pas pour vocation première le contrôle des utilisateurs.

La finalité de ces fichiers de journalisation, consiste à garantir une utilisation normale des ressources des systèmes d'information et, le cas échéant, à identifier les usages contraires aux règles de confidentialité ou de sécurité des données définies par l'entreprise, c'est-à-dire ne pas modifier des données impactant le salaire sans y être autorisé.

Ces fichiers de journalisation n'ont pas, en tant que tels, à faire l'objet des formalités préalables auprès de la CNIL. Lorsqu'ils sont associés à un traitement automatisé d'informations nominatives afin de garantir ou de renforcer le niveau de sécurité de ce dernier, ils doivent être portés à la connaissance de la CNIL au titre des mesures de sécurités entourant le fonctionnement du traitement principal dont ils sont le corollaire.

D'autres aspects ne sont pas mentionnés par la CNIL. Elle n'indique pas que la trace électronique n'est valable que si l'identification est valable (Caprioli 2001). L'authentification est la base des autres services de sécurité. En effet, si l'identité d'une personne n'est pas établie de manière sûre (si l'identité est usurpée), les autres services (habilitations, imputabilité, signature, ...) perdent toute leur valeur (Debaes, Pezziardi et Vincent 2007). Nous étudierons plus en détail la gestion des identités et des accès en page 40.

Nouvelles approches méthodologiques à trouver

Brève histoire de la sécurité et de l'accès au système d'information.

Les données informatiques sont exposées à trois types de risques : la disparition, la consultation non autorisée et l'altération.

A l'époque où l'Ordinateur était peu répandu et encore mystérieux, peu d'utilisateurs avaient accès aux ressources ou savaient comment y accéder. La gestion de ces accès était donc simple. Le début des années 70 a vu la définition des premiers modèles de sécurité : modèle de contrôle d'accès et de contrôle de flux. Depuis, de nombreux modèles de sécurité ont été définis.

Une politique de sécurité est dite fermée si par défaut tous les accès sont interdits; dans ce cas elle ne contient généralement que des autorisations positives (ou permissions).

Une politique de sécurité est dite ouverte si, par défaut tous les accès sont autorisés, elle ne contiendra que des autorisations négatives (ou interdictions).

A l'origine était I-BAC : I-BAC (Identity Based Access Control) est le premier modèle de contrôle d'accès proposé dans la littérature (Lampson 1971). Ce modèle introduit les concepts fondamentaux de sujet, d'action et d'objet :

· Le sujet est une entité active du SI (utilisateur, ordinateur, processus, programme,...)

· L'objet est une entité passive du SI (fichier, base de donnée, ordinateur, programme,...)

· L'action désigne un effet recherché lorsqu'un sujet accède à un objet (lire, écrire, modifier,...)

L'objectif du modèle I-BAC est de contrôler tout accès direct des sujets aux objets via l'utilisation des actions. Ce contrôle est basé sur l'identité du sujet et l'identificateur de l'objet, d'où le nom du modèle I-BAC.

Tableau 1 : matrice de contrôle d'accès

 

Gestion temps et activités

Planning

Paie

Arthur

Lecture/écriture

Lecture

 

Bernard

Lecture/écriture

Lecture/écriture

Lecture

Charles

Lecture

Lecture/écriture

Lecture/écriture

Dans I-BAC, une permission a le format suivant : un sujet a la permission de réaliser une action sur un objet. Avec I-BAC, on suppose implicitement que la politique de contrôle d'accès est fermée. La politique d'autorisation spécifie donc des permissions et on refusera l'accès si la politique d'autorisation ne permet pas de déduire que cet accès est explicitement permis. Pour représenter une politique d'autorisation, le modèle proposé introduit également un autre concept, celui de matrice de contrôle d'accès qui est repris dans plusieurs autres modèles. Dans une matrice de contrôle d'accès ( Tableau 1 : matrice de contrôle d'accès), les lignes et colonnes de la matrice correspondent à l'ensemble des sujets et des objets du SI. Les "cases'' de la matrice représentent l'ensemble des permissions qu'un sujet donné possède sur un objet donné. Dans notre scénario, nous en déduirons qu'Arthur ne peut ni lire, écrire les données de la paie.

Le modèle de type I-BAC est aujourd'hui implanté dans la plupart des systèmes d'exploitation actuels, tels que Windows, Unix ou Linux. Pour mettre en oeuvre ce modèle dans un SI, on n'implante pas directement la matrice de contrôle d'accès. Il existe en fait deux grandes approches possibles suivant que l'implantation repose sur une décomposition en lignes ou en colonnes de la matrice. (M.A. Harrison 1976)

La décomposition en colonnes consiste à associer, à chaque objet, un descripteur appelé liste de contrôle d'accès (ACL), qui représente l'ensemble des sujets ayant des accès sur l'objet considéré avec, pour chaque sujet, l'ensemble des actions que ce sujet peut réaliser sur cet objet.

La décomposition en ligne consiste à associer à chaque sujet, un ensemble de capacités, représentant l'ensemble des objets auxquels le sujet peut accéder avec, pour chaque objet, l'ensemble des actions que le sujet peut réaliser sur cet objet.

A l'usage, une limite importante du modèle I-BAC est apparue : la politique d'autorisation devient rapidement complexe à exprimer et administrer. Il est en effet nécessaire d'énumérer les autorisations pour chaque sujet, action et objet. En particulier, lorsqu'un nouveau sujet ou objet est créé, il est nécessaire de mettre à jour la politique d'autorisation pour définir les nouvelles permissions associées à ce sujet ou objet. Hors de nos jours, dans un système d'informations, des milliers de sujet interagissent avec de milliers d'objets...

Il nous faut repenser la façon d'accéder aux applications.

Pour pallier ce problème, de nouveaux modèles ont été définis. Chaque modèle proposant une expression plus structurée de la politique d'autorisation, mettant en valeur un ou plusieurs attributs de l'utilisateur : son rôle (R-BAC) (Ferraiolo, Kuhn et Chandramouli 2003), son organisation (Or-BAC) (N. Cuppens 2004), ce qu'il doit voir (V-BAC) (Lentzner 2004), ou ce qu'il doit faire (T-BAC et T-MAC) (Roshan 1997).

Définir des Modèles d'autorisations dynamiques et contextuelles

Face au nombre croissant d'accès à accorder, nous devons arriver à élaborer un système d'autorisations qui ne soient pas statiques. Il doit dépendre de conditions qui, si elles sont satisfaites, permettent d'activer dynamiquement les autorisations. Dans ce cas, nous parlons souvent d'autorisations contextuelles. Ainsi, les autorisations peuvent dépendre de contextes temporels (par exemple permission pendant les heures de travail), de contextes géographiques (par exemple, permission à l'intérieur de l'enceinte sécurisée de l'entreprise), de contextes provisionnels (permission si d'autres actions ont, au préalable, été réalisées comme dans le cas d'un workflow). D'autres types de contextes peuvent également être définis. Pour représenter ces autorisations contextuelles, plusieurs modèles de contrôle d'accès à base de règles ont été proposés (modèles de type Rule-BAC). Dans ces modèles, une politique d'autorisation correspond à un ensemble de règles de la forme condition permission qui spécifient qu'une permission peut être accordée lorsqu'une certaine condition est satisfaite. Les modèles de type Rule-BAC sont en quelque sorte les fondations logiques des autres modèles d'autorisations d'accès. Elles reposent sur une logique du premier ordre1(*) qui est indécidable. Leur formalisme théorique ne permet pas la structuration d'une politique d'autorisation avec l'introduction des concepts de rôle, d'activité, de vue et d'organisation. Cette structuration est indispensable pour être exploitable rapidement. Le modèle Or-BAC offre également la possibilité d'exprimer des autorisations contextuelles. Pour cela, le concept de contexte est explicitement introduit dans le modèle (Cuppens et Miège 2003). La définition d'un contexte correspond à une condition logique qui permet de conclure que l'on se trouve dans un contexte particulier lorsque cette condition est satisfaite. Remarquons que chaque organisation définit ses contextes. Ceci permet de modéliser la définition d'un contexte tel que la population rattaché peut varier d'une organisation à une autre.

2.2 Pourquoi avoir une approche ergonomique ?

Comme nous l'avions déjà souligné, alors que les applications informatiques structurent de plus en plus les modes d'organisation des entreprises, aucune démarche n'est mise en oeuvre lors de la conception du système d'information pour optimiser la productivité et le confort des utilisateurs finaux. Dans un article parue dans le journal « Entreprise et Carrières » (Nogier et Helderlé 2006), JF Nogier regrette que l'ergonomie soit le parent pauvre de l'informatique. L'ergonomie, ce n'est pas seulement l'esthétique des pages mais aussi la façon d'accéder aux écrans nécessaires à la tâche à accomplir par l'utilisateur. Il explique cette lacune par le fait que la démarche de conception des systèmes d'information est généralement descendante. Des experts porteurs des déclinaisons métiers des applications informatiques vont spécifier le besoin à partir de leur propre connaissance du domaine. Les utilisateurs n'interviennent qu'à la fin du projet, généralement lors de la recette.

En fait, l'ergonomie informatique est méconnue. En France, l'ergonome a souvent l'image d'un chercheur. Les formations au métier d'ergonome sont encore trop théoriques. Or le métier d'ergonome informatique est typiquement un métier transverse. Il nécessite une formation adaptée et pluridisciplinaire lui permettant de comprendre les différents aspects de la conception d'un produit logiciel. De plus, de nombreuses normes encadrent maintenant l'ergonomie.

Des outils difficiles à utiliser ont un impact direct sur la productivité. Le risque est de délivrer des solutions trop complexes dont la cinématique et les fonctionnalités n'ont pas été validées dans le contexte réel d'utilisation. L'appropriation de l'outil par les utilisateurs finaux est difficile. L'entreprise doit mettre l'accent sur la formation avec des surcoûts à la clé.

Ici encore, comme pour la gestion de la confidentialité, nous nous apercevons que la notion de contexte à toute son importance pour composer l'environnement de travail.

La gestion des accès pourrait-elle fournir le « contexte » dont l'ergonomie a besoin ?

2.3 La gestion des identités et des accès

Il nous apparait maintenant utile de préciser le périmètre de la gestion des accès que nous allons étudier.

La sécurité des systèmes d'information a longtemps été considérée comme l'apanage des équipes systèmes et réseau. Cette vision est aujourd'hui dépassée. Les logiciels d'infrastructure comportent de moins en moins de failles, tandis que les processus de sécurisation des systèmes sont aujourd'hui matures.

2.3.1 gestion des accès

Toutes les applications devant être utilisées par plus d'une personne dispose d'une gestion des accès. Du blog jusqu'à l'ERP. Elle permet de contrôler la manière dont un utilisateur se connecte à l'application. Elle traite des sujets tels que l'authentification, le filtrage des accès en fonction de l'utilisateur, la méthode d'authentification utilisée, le type de poste de travail, sa localisation ou encore la délégation des accès ou l'audit centralisé des accès.

Authentification : Processus consistant à s'assurer de l'identité d'un utilisateur, portant sur un des trois fondamentaux suivant (Debaes, Pezziardi et Vincent 2007) :
- ce que je sais :
un secret que je suis le seul à connaitre, tel un mot de passe, un code PIN ;
- ce que je possède : un objet physique que je suis le seul à posséder, comme une carte à puce ;
- ce que je suis : une caractéristique corporelle que je suis le seul à posséder comme l'empreinte digitale ou l'iris.

Nous n'étudierons pas ces dispositifs puisque notre étude portera sur la question suivante : à quoi a-t-on le droit d'accéder ?

2.3.2 gestion des identités

Elle se focalise principalement sur la création des attributs de l'identité de l'utilisateur. Cela concerne ses attributs métiers qui définissent sa place au sein de l'entreprise et apparaissent dans l'annuaire LDAP de l'organisation, mais aussi ses attributs techniques tels qu'ils sont déclarés dans les systèmes informatiques.

2.3.3 De la gestion des rôles à l'ingénierie des rôles

Elle permet de définir une politique des accès et de l'appliquer pour la gestion des accès et la gestion des identités après l'authentification.

La définition commune de l'ingénierie est l'« ensemble des activités qui concourent à la conception et à l'élaboration d'un projet industriel » (Encarta® 2008 2007). Nous souhaitons que notre problématique aboutisse à une ingénierie des rôles. Notre intention est d'élaborer à partir des rôles de l'utilisateur qui se connecte, un système d'autorisations qui ne soient pas statiques mais qui dépendent de conditions qui, si elles sont satisfaites, permettent d'activer dynamiquement les autorisations. Il va s'agir pour nous de préparer et de combiner un ensemble d'activité qui va nous permettre d'élaborer et de concevoir une description des rôles qui répondent à notre but.

2.4 fournir un environnement de travail dynamique grâce à un système d'information dirigé par les rôles

Vous trouverez dans la figure ci-dessous la carte des buts que nous visons pour construire cet environnement de travail dynamique. Il s'appuie à la fois sur les buts de l'ergonomie et sur les buts de la confidentialité.

Figure 3 : Les buts d'ergonomie de l'espace de travail

Pour les buts de la confidentialité, nous nous sommes appuyés sur les possibilités du framework technologique du SIRH que nous allons étudier.

Figure 4 : Carte des buts de la confidentialité avec R-BAC pour un SIRH

2.5 Les enjeux économiques de la mise en place d'un dispositif R-BAC

Le National Institute of Standards and Technology (NIST) avait commandé en 2002 une étude sur les impacts économiques de l'adoption du dispositif R-BAC dans les systèmes d'informations (Gallager, O'Connor et Kropp 2002). Les bénéfices de l'adoption de la mise en oeuvre d`un R-BAC sont les suivants :

· administration des accès simplifiée,

· productivité organisationnelle améliorée,

· réduction du temps d'immobilisation d'un nouvel employé,

· intégrité et sécurité système améliorée,

· conformité réglementaire simplifiée.

Comme vous pouvez le voir ce sont surtout des gains de productivité. Nous pensons aussi que l'ingénierie des rôles avec un dispositif R-BAC peut aussi apporter une valeur ajoutée au système qui l'implémente.

Fournir une application sur-mesure grâce au rôle

Pour les éditeurs et les intégrateurs, l'implémentation d'un dispositif R-BAC va permettre à l'utilisateur final de lui fournir uniquement les écrans dont il a besoin pour son rôle dans l'entreprise et « créer » pour lui une « application » correspondant à son rôle dans l'entreprise.

Un nouveau business-model : Facturer en fonction des responsabilités du rôle

Cette possibilité de fournir une application sur mesure à chaque utilisateur pourrait permettre d'élaborer un nouveau système de licence et de facturation à partir des rôles. Plus le rôle dispose de privilège plus le tarif est élevé et inversement moins il a de privilège plus le tarif est bas. Ce dispositif de facturation pourrait être envisagé et fournir un nouveau business-model pour le marché du logiciel en ligne de type ASP ou SaaS (Barathon 2007). Il a représenté 1230 M € pour la France en 2007.

En conclusion, il nous faut réussir à identifier les utilisateurs par leurs rôles dans les processus métier pour les raisons illustrées dans la figure suivante :

Figure 5 : d'après M.Mersiol (LAAS-CNRS) Club SEE Systèmes Informatiques de Confiance Journée « Facteurs Humains » 19/04/2001

Le rôle est un objet à la croisé des mondes : il va nous permettre d'agréger des concepts techniques, théoriques et fonctionnels et de les faire converger vers une solution méthodologique.

3 De GIP à HR-Access, des progiciels en phase avec leur époque

Pour notre étude de cas sur la mise place d'un accès basé sur les rôles, nous allons étudier le système d'information des ressources humaines HRA Suite 7. Son évolution illustre les grandes tendances des systèmes d'informations depuis plus de trente ans2(*).

3.1 Le SIRH : HRA Suite 7

3.1.1 Son histoire et ses aspects techniques

GIP3(*) a été créé par la compagnie Générale d'Informatique. GIP a suivi les grandes tendances du moment. Il s'agit avant tout d'un progiciel de paie hautement paramétrable et ceci dès la fin des années 1960. Chaque élément participant au calcul de la paie était stocké dans un fichier paramètre séquentiel appelé « sous-fichier ». Ensuite lorsqu'est venue l'époque des Ateliers de Génie Logiciel et de ses générateurs de codes, la CGI a intégré le L4G Pacbase à l'environnement de développement de GIP.

Ce produit n'était rien de plus qu'un générateur de COBOL qui permettait de produire des états et des programmes « batch » de façon automatisée en s'appuyant sur la méthode de programmation phare de l'époque : CORIG. C'est d'ailleurs de là que vient le nom de PAC qui signifie « Programmation Automatique "Corrigée" »

Pour la petite histoire, Pacbase aurait été imaginé par des informaticiens travaillant au ministère des finances. Ils n'étaient pas très doués en programmation Cobol et un peu fainéants et ont eu l'idée de concevoir un programme qui leur permettrait d'écrire les applications à leur place. Le premier atout de PAC se comprend très vite : le code est généré automatiquement donc les risques d'erreurs de syntaxe sont minimes. Les créateurs du produit fondent la CGI et très vite PAC700 connait un essor important car il est disponible pour presques toutes les plateformes de développement de l'époque (BULL, IBM, etc...).

 

Le produit va être rebaptisé PACBASE et son noyau est constitué par le dictionnaire qui est LE référentiel des données informatiques de l'entreprise. Différents modules sont venus se greffer au fil des évolutions technologiques (pacbase.free.fr 2003-2008).

GIP fonctionnait avec des « squelettes » de programmes COBOL qui contenait les traitements « génériques » de paie. La CGI ayant intégré l'environnement Pacbase à GIP, cela lui permettait d'ajouter des traitements complémentaires dans des « contextes ». Les contextes sont des emplacements particuliers dans les différents squelettes COBOL4(*).

La gestion de la Paie est une application longue et complexe à développer en interne. C'est pour cela que GIP est un des premiers progiciels qui a connu un grand succès bien avant SAP.

Chaque génération de GIP s'est adaptée aux technologies du moment. Lorsque les tables relationnelles sont apparu, GIP devenue SIGAGIP l'a presqu'immédiatement adopté. Les « sous-fichiers » sont devenus des tables relationnelles. Hormis pour les données devant être traitées par lots (batchs) qui reste stockées dans des fichiers séquentiels ou séquentiels indexés, tout le reste est stocké dans des tables relationnelles, y compris les sources Pacbase.

Lorsque l'époque du client/serveur est arrivée, SIGAGIP est devenue SIGAGIP/CS. C'est aussi à cette époque de la CGI a été racheté par I.B.M.

La Figure 6 présente l'architecture générale de SIGAGIP/CS qui est devenu HR-Access V1 après son rachat par IBM.

Figure 6 : Architecture technique client/serveur de SIGAGIP/CS

Cette architecture a trois niveaux a permis, de faire évoluer à leur rythme chacun des niveaux qui eux-mêmes reposait sur des technologies différentes : le poste client (de Windows au client web), le serveur (du Mainframe, unix ou AS/400), et la base de données ( DB2, Oracle...). Cette architecture à trois niveaux permet de s'adapter à l'architecture technique du client.

3.1.2 Le Modèle Conceptuel des Données du SIRH

Il n'y a pas que l'architecture technique qui a évolué, le modèle conceptuel des données à aussi évolué.

Le modèle conceptuel de données (MCD) a pour but d'écrire de façon formelle les données qui seront utilisées par le système d'information. Il s'agit donc d'une représentation des données, facilement compréhensible, permettant de décrire le système d'information à l'aide d'entités. Il ne se préoccupe pas des contraintes d'organisation et techniques.

Ce MCD met en évidence les entités présentes dans l'application, ainsi que les relations qu'elles ont entre elles. Nous obtenons pour le modèle « fonction public » le schéma suivant :

Un Agent occupe un Poste. Un poste requiert des compétences et un agent détient également des compétences. De plus, un poste est associé à un emploi de référence qui fait lui-même partie d'une filière. Enfin un agent appartient aussi à une filière bien déterminée.

La Figure 7 illustre comment sont représenté les données. La notion de dossier de gestion permet de rassembler les données connues sur l'objet à gérer. La notion de dossier réglementaire permet de rassembler des données organisées de façon simple comme un code et un libellé par exemple. Les dossiers des salariés sont des dossiers de gestion alors que la description des données de références (comme le paramétrage) sont des dossiers réglementaires.

Figure 7 : le modèle conceptuel des données pour la gestion du personnel avec HR-Access

3.1.3 Aspects fonctionnels

Au cours de ces quarante années d'existence, HR-Access est devenue une solution applicative intégrée dédiée au domaine de la Gestion des Ressources Humaines.

Ce modèle de données constitue véritablement le socle du Système d'Information et permet une véritable approche globale et intégrée de la gestion des Ressources Humaines, de l'Administration du Personnel et de la Paie pour toutes les populations gérées : chaque information est décrite de manière unique et est ensuite utilisable dans tous les domaines fonctionnels et tous les modèles applicatifs proposés avec HR Access. Cette architecture est la seule capable d'assurer une cohérence complète du Système d'Information Ressources Humaines.

HR Access est une solution applicative organisée en modèles applicatifs dont la cohérence est assurée par le modèle de données

Afin de proposer une offre applicative proche des attentes de ses clients (c'est à dire dans laquelle les utilisateurs se reconnaissent), l'éditeur IBM a dû organiser les fonctionnalités proposées en modèles de gestion dédiés à certains secteurs.

En particulier HR Access propose un modèle applicatif pour le Secteur Public et un modèle applicatif pour le secteur Privé.

L'ensemble des fonctionnalités nécessaires pour couvrir les besoins de La Poste s'appuient sur deux modèles applicatifs proposés par HR Access (Droit Privé, Droit Public).

Organisation des modèles applicatifs ou Applications Sectorielles

Les Applications Sectorielles partagent naturellement une grande majorité de données communes qui constituent un « Tronc Commun ».

Ce « Tronc Commun » est enrichi des spécificités propres à chacun des modèles (par exemple la carrière administrative est une spécificité du modèle dédié aux personnes relevant du Droit Public).

L'ensemble des fonctions sont organisées de manière différenciée dans chacun des modèles, de manière à ce que les gestionnaires se reconnaissent plus facilement dans HR Access.

Remarque : les fonctions de Gestion Stratégiques des Ressources Humaines (SHR) sont considérées comme transverses et sont communes quelle que soit l'offre sectorielle : les données et leur représentation (Processus / Procédures) sont par conséquents indépendants du modèle applicatif.

3.1.4 La gestion de la confidentialité avec la gestion des accès par profils

Dans HR-Access, la gestion des accès se fait par profil. La gestion de la confidentialité par profil se rapproche du modèle V-BAC. Nous désignerons donc par V-BAC (View Based Access Control) ce type de modèle de contrôle d'accès. Intuitivement, dans une base de données relationnelle, une vue correspond au résultat d'une requête SQL auquel on a donné un nom. Pour faciliter l'expression et la gestion d'une politique d'autorisation, les éditeurs d'HR-Access avaient besoin d'un concept pour structurer les objets. Parmi les modèles de contrôle d'accès proposant une telle structuration des objets, on peut citer le modèle de sécurité proposé par SQL pour les bases de données relationnelles. L'expression d'une politique de sécurité en SQL repose sur le concept de vue (Lentzner 2004). Le concept de vue ne se limite pas au modèle relationnel.

Il a donc été défini six répertoires de profils :

· les profils populations,

· les profils applications,

· les profils informations

· les profils requêtes,

· les profils navigation,

· les profils actions.

Figure 8 : synthèse des profils d'accès

Le profil applications

Le profil applications donne la liste des applications et des processus autorisés. Toute application ou processus non mentionné dans la liste est interdit pour le gestionnaire qui est associé au profil.

Le profil informations

Le profil informations donne la liste des structures de données et des informations autorisées ou interdites.

Un témoin indique, pour chaque information accessible, le type d'action autorisé :

- la consultation,

- la modification/suppression, ou

- l'interdiction.

Toute structure de données ou information non mentionnée dans la liste est interdite pour le gestionnaire qui est associé au profil.

De plus, en associant à la définition du profil informations des structures de données dites dynamiques, il est possible de modifier le profil information d'un utilisateur à rupture procédure, par traitements spécifiques.

Figure 9 : schéma de définition du profil information

La définition d'un profil information peut être constituée d'un profil statique uniquement, un profil statique complété d'un profil dynamique ou d'un profil dynamique exclusivement.

Le profil information dynamique permet les droits d'accès aux informations soient déterminés dynamiquement en fonction du code utilisateur et des informations contenues dans son dossier de gestion. Par exemple en fonction du grade de l'utilisateur (information Grade dans son dossier) il pourra visualiser ou non l'information Salaire.

Un gestionnaire peut accéder aux applications et aux processus autorisés par son profil applications et, dans ces processus, travailler :

· sur les dossiers décrits par son profil populations et

· sur les informations autorisées par son profil informations.

Le profil requêtes

Le profil requêtes indique, pour chaque structure de données, le temps maximum d'exécution des requêtes autorisées à un gestionnaire.

Il n'autorise, à un gestionnaire, parmi les requêtes existantes, que celles dont le temps maximum d'exécution est inférieur au temps indiqué dans le profil.

Dans la mesure où le SGBDR fournit un module d'estimation des requêtes, il refuse la requête lancée par un gestionnaire lorsque sa durée estimée par le SGBDR est supérieure au temps maximum d'exécution indiquée dans le profil. Le temps est exprimé en secondes.

Le profil actions

Le profil actions indique les actions, autres que celles découlant des autres profils , autorisées à un gestionnaire dans HR Design.

Ces actions sont :

· dans les processus de gestion des données :

- annulation de dossiers,

- l'interdiction d'accéder aux requêtes,

· dans les processus d'interrogation de données :

- création de requêtes publiques, c'est-à-dire accessibles aux autres gestionnaires, ou privées,

- limitation d'exécution d'une requête,

- saisie de SQL natif,

Les limitations d'exécution d'une requête sont :

· le nombre de dossiers maximum pouvant être sélectionné ; au delà de ce nombre, la sélection est interrompue et aucun dossier n'est sélectionné,

· le nombre de dossiers maximum pouvant être sélectionné sans demande de confirmation ; au delà de ce nombre et jusqu'au seuil nombre de dossiers maximum pouvant être sélectionné, une confirmation est demandée au gestionnaire,

· le temps maximum d'exécution d'une requête ; au delà de ce temps, la requête est abandonnée,

Le profil populations

Le profil populations décrit les caractéristiques des dossiers accessibles. Une population est un ensemble de dossiers de gestion sélectionnés. La population est désignée par :

· les noms de structures de données qui décrivent les dossiers,

· un type de profil sélectionné et

· des requêtes écrites en langage SQL ou des traitements spécifiques.

Présentation

Un profil population détermine les populations de dossiers qu'un utilisateur peut utiliser.

Cette confidentialité est appliquée sur toutes les requêtes de sélection applicative, on effectue alors une intersection entre la requête applicative et la liste de dossiers autorisés définie par le profil.

La liste de dossiers autorisée est déterminée par une requête SQL.

Figure 10 : définition du profil Population

Le profil navigation

Définir un profil navigation consiste à indiquer la liste des Contextes de navigation autorisés au gestionnaire titulaire de ce profil pour l'utilisation d'un applicatif intranet. Un contexte de navigation est un regroupement fonctionnel de page web, c'est-à-dire qu'un contexte de navigation regroupe les pages permettant d'accéder au contrat, à la formation...

Dans HRD Studio, lors de la description d'un noeud de navigation d'un arbre fonctionnel, le concepteur lui associe un objet Contexte de Navigation.

Ainsi, dans l'applicatif intranet, un gestionnaire ne peut accéder qu'aux pages Web issues de noeuds portant un contexte de navigation qui lui est autorisé par son profil navigation.

Les contextes de navigation sont des objets génériques décrits via HRD Studio.

L'atelier Profils HRD Security

Il propose différents modes de résolution de la requête SQL pour aboutir à la liste de dossiers suivant le type de profil associé. La confidentialité d'un gestionnaire est définie par association d'un profil de chaque type au gestionnaire.

Dans HRD Security, création ou modification des utilisateurs auxquels un profil doit être associé.

La gestion de la confidentialité impose donc de connaître l'ensemble des utilisateurs et leurs missions respectives. De leur rôle sera déduit des profils de confidentialité propre qui leur seront attribués. Les étapes de mise en oeuvre d'une confidentialité sont les suivantes :

§ le recensement des différents types d'acteurs (responsable emploi, gestionnaire RH, responsable organique, responsable opérationnel, ...)

Pour chaque acteur,

§ le recensement des outils utilisés (HR Design Web, Self-Service, Business Objects Production, Business Objects Infocentre, ...),

§ le recensement des contextes de navigation autorisés,

§ le recensement des actions autorisées,

§ le recensement des informations autorisés ou interdites,

§ le recensement des populations de dossiers autorisés.

§ la détermination des différents profils-type

§ l'association des acteurs aux différents profils-type.

Tableau 2 : répartition des rôles MOA/MOE

Rôle de la MOA

Rôle de la MOEI

Définition du besoin

Création des profils-type

Création des utilisateurs (habilitations) par « assemblage » des profils-type.

Assistance technique à la définition du besoin et à la création des profils-type

Création des contextes de navigation

Association des contextes de navigation aux noeuds de l'arbre de navigation

Le résultat de ce travail est une matrice des profils qui a la forme suivante :

Tableau 3 : Exemple de matrice des profils/acteurs

Acteur

Profils

Gestionnaires principaux

Information

Population

Application

Action

Requète

Navigation

Utilisateur technique

INFO02

POPUL09

APPLI011

ACTIO02

Aucun

NAVTECH01

Non

Gestionnaire RH EGRH 1

INFO0003

POPUL001

APPLI001

ACTION01

REQ00001

Aucun

Non

Gestionnaire RH EGRH 2

INFO0003

POPUL002

APPLI001

ACTION02

REQ00001

Aucun

Non

Cellule d'administration des référentiels

INFO0001

POPUL008

APPLI009

ACTION12

REQ00005

NAVIG001

Non

Administrateur national des habilitations

INFO0002

POPUL008

APPLI007

ACTION13

REQ00005

Aucun

Oui

Tout est-il à reprendre avec la nouvelle approche de la confidentialité par les rôles ?

3.2 Les nouveautés de HRA Suite 7

Nous n'aborderons pas toutes les évolutions de HRa Suite 7 par rapport à ses prédécesseurs, mais seulement ce qui nous semble une innovation majeur : l'accès par les rôles qui détermine l'espace de travail.

L'application HRa Suite 7 est la même application pour tous les acteurs. Toutefois, elle a été conçue pour être adaptée aux besoins de l'utilisateur. Le profil de l'utilisateur est désormais déterminant dans HRa Suite 7 selon qu'il soit salarié, responsable ou professionnel RH. Selon son profil (son rôle), l'utilisateur accèdera à une application répondant à ses besoins avec un contenu approprié. Il aura des composants et des fonctionnalités spécifiques à son rôle.

Les besoins des utilisateurs ont été définis pour chaque type (employé, manager, professionnel RH) lors de la phase de conception et sont transformés en termes de droits, d'accès et de populations autorisées lors de l'utilisation de l'application.

Ainsi, l'utilisateur ne verra que ce qu'il a le droit de voir et ne pourra effectuer que des tâches et des actions déterminées sur des populations dédiées selon le profil qui lui a été attribué.

Dans HRa Suite 7, la confidentialité de l'utilisateur dépend de son rôle. Et son rôle lui donnera accès à un espace de travail adapté appelé HRa Space. C'est le point d'entrée unique et obligatoire vers l'application HRa Suite 7 pour tous les utilisateurs.

HRa Space c'est :

ï un nouveau composant,

ï un véritable bureau dédié aux professionnels RH,

ï intègre les services, les fonctions et les composants nécessaires,

ï permet l'accès à toutes les actions fonctionnelles disponibles à l'utilisateur.

3.2.1 Les rôles

Jusqu'à la version 5.2, la confidentialité applicative était gérée par les profils. Dans HRa Suite 7, elle est entièrement basée sur un nouveau concept : les rôles.

Un rôle est une abstraction de l'utilisateur en tant qu'acteur logique du système. Il s'agit d'un modèle d'utilisateur qui décrit un acteur agissant au titre d'une tâche donnée dans le contexte des processus métier. Les rôles sont des nouveaux objets de conception personnalisables dans HRD Studio. Avant d'être utilisés dans HRa Suite, ils doivent être mis en exploitation. Un rôle définit un ensemble de caractéristiques (mission du rôle) permettant à un gestionnaire d'utiliser l'application HRa Suite 7. Les rôles déterminent les habilitations (activités), l'accès aux données, aux populations et aux tâches qu'un utilisateur peut effectuer.

Il est possible d'attribuer plusieurs rôles à un utilisateur.

Les rôles ont un impact sur la présentation de l'application, dans la mesure où ils conditionnent l'interface utilisateur.

Ses caractéristiques

Un rôle est caractérisé par :

ï des droits : l'accès aux données et aux processus métiers,

ï des devoirs : ce sont les tâches (de workflow) qui lui sont dédiées au sein d'un processus métier,

Les rôles permettent de rattacher des droits et des devoirs à des notions fonctionnelles (responsable d'UO, postes, emplois, etc.).

Lorsqu'un rôle est attribué à un utilisateur cela lui confère une mission :

ï des habilitations, ces sont des autorisations rattachées à une activité

ï des droits d'accès aux données, ce sont les données accessibles pour les actions à réaliser

ï des règles relatives aux tâches de workflow,

ï des populations spécifiques,

ï d'autres caractéristiques (alertes).

Rôles et utilisateurs

Un rôle est associé à une catégorie d'acteur définissant ainsi un type d'activité. Les catégories d'acteur correspondent à des modèles de rôles.

Il existe trois catégories d'acteurs dans HRa Suite :

ï Collaborateur : il concerne l'agent, travaille uniquement sur son dossier

ï Manager : Il concerne le manager, il travaille avec des collaborateurs. Il n'exerce pas d'activités métiers RH.

ï Expert RH : Il concerne le gestionnaire applicatif. Uniquement des activités métiers RH.

Dans HRa Suite, les utilisateurs n'effectuent pas les mêmes tâches selon la catégorie d'acteurs à laquelle appartient le rôle qu'ils utilisent. Par exemple, un salarié peut être autorisé à envoyer des demandes de congé et un responsable à valider la demande de congé de ses subordonnés.

Un rôle est associé à une et une seule catégorie d'acteurs. Mais un même rôle peut être affecté à plusieurs utilisateurs. De plus un utilisateur peut avoir plusieurs rôles : Mme Martin peut être employé (du service RH) en tant que manager de 2 autres employés de l'administration des cadres du siège. Ici, nous identifions 3 rôles génériques : employé, manager et professionnel RH.

Rôles et axes de confidentialité

La confidentialité des utilisateurs est directement liée aux rôles qui leur sont attribués. Cette confidentialité se décline suivant 3 axes principaux :

ï les populations autorisées,

ï les données accessibles,

ï les processus métiers associés aux rôles.

Lorsque ces caractéristiques sont définies, le rôle doit être mis en exploitation pour être actif.

Les populations autorisées

Les populations autorisées rattachées au rôle permettent de définir un périmètre des populations spécifiques à l'utilisateur. On définit :

ï la ou les structures de données interrogeables,

ï par structure de données interrogeables, les populations de dossiers correspondantes.

Ces populations de dossiers peuvent être, soit l'ensemble des dossiers de la structure de données, soit des populations répondant à une condition de sélection SQL. La condition SQL est obtenue par une requête HRD Query. Dans cette condition SQL, il est possible d'utiliser des rubriques provenant des paramètres d'instanciation associés aux rôles.

On peut définir plusieurs populations différentes, et en spécifier certaines comme étant la population par défaut.

Les Données accessibles

Un modèle de rôle détermine des droits d'accès pour les applications qui effectuent un accès direct aux données : l'application du professionnel RH, par exemple. Une mission du rôle consiste à définir les structures de données et informations auxquelles l'utilisateur peut accéder pour les actes de gestion à effectuer.

Pour chaque information de la structure de données, on définit :

ï les droits d'accès sur les données (interdit, lecture, création/suppression, etc.),

ï la population de dossiers pour cette information (restriction de population). Par exemple, un manager peut être autorisé à consulter uniquement le salaire de ses subordonnés directs,

ï une restriction en mise à jour : la mise à jour de l'information n'est autorisée que pour certaines valeurs des données du dossier,

ï des actions sur les dossiers : création, suppression.

3.2.2 Paramétrage technique des rôles

Figure 11 : Pré requis du paramétrage technique des rôles

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.

Protection juridique de l'information :

Pour pallier à un retard dans le traitement technologique de la protection du système d'information, une solution juridique peut être envisagée. De manière générale, la déontologie des usages des Systèmes d'information repose sur les constats suivants :

ï L'outil informatique est devenu nécessaire, mais son utilisation est facteur de risques pour l'entreprise ;

ï La loi évolue vers une responsabilisation systématique et accrue de l'entreprise et de ses représentants ;

ï La sécurité juridique appelle un contrôle renforcé de l'usage qui est fait de ces outils ;

ï Le périmètre de ce contrôle étant juridiquement encadré, il faut trouver un équilibre entre la nécessité pour l'entreprise de s'assurer du respect des règles en vigueur et la garantie, pour le personnel, du respect de ses droits fondamentaux (vie privée, secret des correspondances...).

Figure 16 : la déontologie des usages (source CIGREF 2006)

En 2006, le CIGREF s'est posé la question de la déontologie des usages des Systèmes d'information (CIGREF 2006). Quelles utilisations des outils informatiques de l'entreprise sont conformes aux règles éthiques, morales et juridiques définies ? Il s'agissait de réfléchir d'une part, sur la manière dont les règles existantes sont traduites en termes d'application concrète et, d'autre part, sur les limites de leur champ d'application. La déontologie des usages des Systèmes d'information sert ainsi de maillon fondamental entre l'utilisation régulière des outils et le comportement des utilisateurs.

Le tableau ci-dessous résume quelques uns des risques envisagés sur le SI les réponses juridiques et déontologiques qu'il est possible d'apporter.

Tableau 4 : Risques juridiques et réponses déontologiques (CIGREF 2006)

Menaces "classiques"

Dispositions applicables

Peine maximale

Quelques règles déontologiques

Atteinte aux données personnelles

Art. 226-16 à 226-24 du Code Pénal (voir Loi Informatique et Libertés du 6 janvier 1978, modifiée par la loi du 6 août 2004)

Jusqu'à 5 ans de prison et 300.000 euros d'amende

Déclarer ses traitements ou demander une autorisation et les limiter à ce qui est déclaré, collecter loyalement les données et les sécuriser de manière appropriée, respecter droits des personnes fichées...

Atteinte aux données financières

Art. L621-15 du Code Monétaire et Financier (modifié par Loi de Sécurité Financière du 1 août 2003)

Jusqu'à 1,5 millions d'euros ou 10x le montant du profit réalisé

Gouvernance d'entreprise transparente, sécurisation des données financières, définition de politiques de sécurité...

Atteintes aux Systèmes d'information de tiers (virus, entraves...)

Art. 323-1 à 323-7 du Code Pénal (créés par la loi Godfrain du 5 janvier 1988, modifiée par la Loi pour la Confiance dans l`Économie Numérique du 21 juin 2004)

Jusqu'à 5 ans de prison et 75.000 euros d'amende

Sensibiliser les utilisateurs, interdire l'importation de fichiers sur les postes utilisateurs, mettre à jour pare-feu et antivirus, effectuer des tests de vulnérabilité, mettre en place des pots de miel (pièges à pirates informatiques), rédiger une charte d'usage...

Contrefaçon d'oeuvres audiovisuelles ou de logiciels

Art. 335-1 et suivants du Code de la PI (peines aggravées par la Loi Perben II, 9 mars 2004)

Jusqu'à 3 ans de prison et 300.000 euros d'amende

Sensibilisation du personnel, restrictions en matière de sauvegarde de données et d'accès à Internet...

L'environnement juridique et réglementaire

L'entreprise évolue dans un environnement juridique qu'elle ne maîtrise pas et auquel elle ne peut pas déroger. En particulier, l'utilisation des technologies de l'information est un domaine faisant l'objet de multiples textes juridiques tant nationaux qu'européens ou internationaux, ainsi que de recommandations de la CNIL (en France) qui n'ont pas la même portée juridique.

En effet, en France, plusieurs textes ont récemment modifié l'environnement légal en matière de Systèmes d'information : la loi pour la confiance dans l'économie numérique du 21 juin 2004, la nouvelle loi informatique et libertés du 6 août 2004 complétée par le décret d'application du 20 octobre 2005 (CNIL 2007). Par ailleurs, le code du Travail (articles L.120-2 et suivants, puis L 432-2 et L 432-2-1) exige des entreprises qu'elles informent au préalable les représentants du personnel avant tout projet important d'introduction de nouvelles technologies lorsque celles-ci sont susceptibles d'avoir des conséquences sur l'emploi, la qualification, la rémunération, la formation ou les conditions de travail du personnel (CIGREF 2006).

La protection des données en France

La CNIL a explicité dans un document d'orientation du 10 novembre 2005 la mise en place des dispositifs d'alerte professionnelle dont la finalité est de renforcer la protection des données sensibles de l'entreprise en favorisant la dénonciation de comportements suspects de collaborateurs (CNIL 2005). Ce dispositif est applicable à un cadre restreint et sous certaines conditions :

ï limitation du dispositif d'alerte aux domaines comptables, financiers et bancaires (lutte contre la corruption),

ï définition des catégories de personnes concernées par le dispositif d'alerte par le chef d'entreprise qui fixe également les limites de la procédure,

ï création d'une organisation spécifique dans l'entreprise chargée de la gestion du dispositif d'alerte : nomination d'un responsable, définition de son rôle,

ï information individuelle et collective des salariés sur le dispositif d'alerte, par tous les moyens,

ï information des salariés mis en cause dans le cadre de l'alerte professionnelle par le responsable du dispositif.

Définir la portée du secret professionnel en qualifiant les données

La déontologie permet de discerner les règles adéquates en matière de secret professionnel et de déterminer la manière la plus adaptée pour le mettre en oeuvre. Car, en effet, traiter de manière massive des données confidentielles et/ou sensibles implique le respect du secret professionnel. Il s'agit d'une obligation légale qui requiert :

ï une qualification préalable des données et des personnes soumises au secret ;

ï une qualification préalable des circonstances dans lesquelles le secret peut être levé.

Mettre en place une charte et communiquer

Parmi les moyens mis en oeuvre pour assurer la conformité juridique des usages du SI, de nombreuses entreprises ont mis en place une charte. Plus de 95% des entreprises sont déjà dotées d'une charte d'utilisation du SI ou sont en train de le faire (CIGREF 2006).

L'introduction de telles règles n'a pas pour but de moraliser, ni de standardiser les comportements des salariés au regard de l'usage du SI, mais de donner des repères sur les conduites que l'entreprise attend des collaborateurs en matière d'usages du SI :

ï Responsabiliser les salariés au regard de l'usage du SI de l'entreprise,

ï Assurer à la fois la transparence, la confidentialité et le respect de l'espace privé des salariés,

ï Sécuriser en interne et en externe la circulation des informations,

ï Respecter et faire respecter le droit de propriété intellectuelle,

ï Concilier le besoin de sécurité et l'esprit d'entreprise,

ï Rendre l'environnement juridique lié aux usages des outils informatiques plus lisible et compréhensible,

ï Lister de manière exhaustive les règles d'utilisation des outils liés aux Systèmes d'information.

Les entreprises peuvent choisir de donner une dimension juridique à leur démarche en adossant leur charte d'usages, ou certaines de ses dispositions seulement, à leur règlement intérieur. Les règles ainsi établies ont alors force obligatoire et un système de contrôle / sanctions en cas de non respect peut s'appliquer (HUGOT 2008).

La protection de l'information par des moyens juridiques permet de définir ce qu'il faut protéger. C'est un moyen nécessaire mais clairement insuffisant. Des moyens technologiques doivent renforcer et sécuriser la protection de la confidentialité.

Protection technologique de l'information

La mise en place d'un dispositif technologique de protection de l'information peut être considérée comme un projet à part entière. Pour mettre en place ce projet de protection technologique de l'information, la Direction centrale de la sécurité des systèmes d'information (DCSSI) du Secrétariat général de la défense nationale (SGDN) a établit des directives en matière de sécurité des systèmes d'information que nous allons voir plus loin.

La démarche de sécurité

La sécurité des systèmes d'information (SSI) traite en premier lieu et essentiellement des informations et des « traitements » qui leur sont appliqués. Les besoins, exigences et objectifs techniques ou organisationnels en découlent naturellement. Parmi les cinq critères fondamentaux de sécurité identifié au début de ce chapitre, trois critères fondamentaux sont à prendre en ligne de compte : la confidentialité, l'intégrité et la disponibilité, tant des informations que des systèmes et des environnements dans lesquels ils se trouvent.

La SSI est directement associée à une appréciation et un traitement des risques de protection des données étudié précédemment. Ces risques sont qualifiés d'opérationnels car ils agissent directement sur les activités des administrations des entreprises. En effet, l'organisme utilisant des moyens des technologies de l'information et de communication (TIC) et en particulier de l'Internet, pour réaliser ses activités et ses transactions, est directement concerné par la SSI.

Les objets et domaines de sécurité

Puisque la SSI considère l'information, le traitement, le système et son environnement, les objets de la démarche de sécurité seront : les informations, les processus, fonctions ou applications, la technologie (matériel et systèmes d'exploitation), l'environnement physique (bâtiments, locaux...), les intervenants humains. Tous ces objets, dont certains sont particulièrement actifs, comme les processus et les hommes, doivent êtes clairement définis. Chacun est plus particulièrement concerné par un domaine de sécurité spécifique, et chacun intervient peu ou prou dans chaque domaine. Une politique de sécurité qui ne prendrait pas en compte tous ces objets et domaines serait instable et incomplète. Elle produirait une solution dangereuse reposant sur un faux sentiment de sécurité plus dommageable encore que de ne rien faire.

Les démarches normalisées

Depuis une dizaine d'années, de nombreux efforts sont entrepris pour fixer des règles, ou du moins des directives générales, pour la gestion de la sécurité des technologies de l'information. Ces travaux se sont traduits par des normes nationales et internationales (telles que les normes [ISO 13335 (ISO 2001)], [ISO 17799 (ISO 2000)]...). La sécurisation d'un système d'information ne peut se contenter de firewalls et logiciels, aussi performants soient-ils. Les normes ISO 27000 définissent les étapes de mise en place d'un système de management de la sécurité de l'information (SMSI), et recommandent les meilleures pratiques.

ISO 27001: les clefs du management de la sécurité

La norme ISO 27001 décrit ce que doit être un système de management de la sécurité de l'information (SMSI) pertinent. Un SMSI recouvre l'ensemble des ressources mises en place pour organiser et gérer la sécurité au quotidien. Il englobe les différents documents formalisant les règles de sécurité, ainsi que l'organisation associée (RSSI, correspondants sécurité, exploitants, instances de décision...). Le SMSI constitue donc un dispositif global de gouvernance de la sécurité de l'information. Il est important de noter qu'il est toujours défini pour un périmètre bien déterminé: toute l'entreprise, un métier ou un processus particulier, une application, un centre de production... Comme les systèmes de management de la qualité (ISO 9000) et de l'environnement (ISO 14000), un SMSI ISO 27001 repose sur le cycle de progrès PDCA : Plan, Do, Check, Act, également appelé Roue de Deming. Ce cycle vise une amélioration continue reposant sur une logique simple: dire ce que l'on fait, faire ce que l'on a dit, puis contrôler et corriger ce qui ne va pas.

Cette norme décrit exhaustivement le « quoi » et le « quand » du management de la sécurité. Le « comment » n'est pas décrit. Pour combler cette lacune, la Direction centrale de la sécurité des systèmes d'information (DCSSI) du Secrétariat général de la défense nationale (SGDN) a établit des directives en matière de sécurité des systèmes d'information. La méthode EBIOS a été élaborée dans la continuité et dans l'esprit de ces démarches. Elle s'utilise généralement au niveau de la phase d'élaboration d'un schéma directeur opérationnel d'un système d'information. Son objectif principal est de permettre à tout organisme, de déterminer les actions de sécurité qu'il convient d'entreprendre.

EBIOS : Expression des besoins et identification des objectifs de sécurité

Elle peut être mise en oeuvre par l'expert sécurité de l'organisme et peut s'appliquer à tous les niveaux de la structure d'un système d'information à concevoir ou existant (sous-systèmes, applications). Elle s'articule de la façon suivante :

Figure 17 : La démarche EBIOS globale

Chacune des étapes de la démarche est parfaitement décrite dans les documents publiés par le Secrétariat générale de la défense nationale. Elle est disponible à l'adresse suivante : http://www.ssi.gouv.fr/fr/confiance/ebiospresentation.html. Des organigrammes et des check-lists accompagnent chaque étape. Nous ne les détaillerons pas ici et invitons le lecteur à consulter le site du SGDN.

Normes et Principes de gestion des habilitations au sein des entreprises

Les habilitations s'appuient le plus souvent sur la norme ISO/IEC 17799-2005. En effet cette norme est un guide des bonnes pratiques en matière de sécurité du système qui a pour objectif de « donner » des recommandations pour gérer la sécurité de l'information à l'intention de ceux qui sont responsables de définir, d'implémenter ou de maintenir la sécurité au sein de l'entreprise.

La norme identifie, au chapitre « Contrôles d'Accès Logiques » des objectifs visant à maîtriser les accès au patrimoine informationnel au travers des habilitations fournies par la maitrise d'ouvrage.

Sont abordés notamment :

· L'inventaire de toutes les informations sensibles accédées par les applications ;

· La législation, la réglementation et les engagements contractuels concernant le contrôle d'accès logique ;

· Les règles de gestion et d'administration des droits d'accès ;

· Les droits d'accès attribués par défaut aux principales catégories de personnel.

Alors que la protection juridique semble reposer sur la bonne volonté de chaque intervenant, elle permet de pointer les objets à protéger. Elle est néanmoins insuffisante. La protection technologique fournit l'infrastructure et les outils de protection. Elle semble exhaustive, mais elle est par contre trop complexe, c'est-à-dire composé de nombreux éléments qui forment un ensemble difficile à appréhender. Il y a trop d'éléments qui ne sont pas du périmètre du système d'information des ressources humaines qui est notre système cible. Une solution pourrait être de « nettoyer » la démarche de tout ce qui ne concerne pas la cible. Nous ne choisirons pas cette option et préférons nous investir dans une démarche plus novatrice.

4.2 Ergonomie

Cette approche est moins « stratégique » puisqu'elle se veut plus opérationnelle et tournée vers l'utilisateur final. Plutôt que d'interdire et de lister les menaces, nous allons choisir seulement ce qui est nécessaire à l'activité de l'utilisateur final. Par défaut, il n'aura donc pas accès à ce qui lui est interdit.

Il s'agit de faire de la confidentialité « inconsciente » : vous ne pouvez pas voir ce qui n'est pas de votre périmètre et n'est pas utile à votre tâche.

Les gains attendus seront toujours les suivant :

ï Assurer l'utilité (économique) : Le système envisagé dans le contexte d'une activité

ï Assurer l'utilisabilité (ergonomique) : Le système vu sous l'angle perceptif et cognitif de l'utilisateur

ï Assurer l'acceptabilité (sociologique) : Le système vu sous l'angle du sens de l'usage

Ici encore, il existe des démarches normalisées.

4.2.1 ISO 13407

La norme ISO 13407 définit les conditions de la mise en oeuvre d'un processus centré utilisateur

Il s'agit de mettre l'utilisateur au coeur de la conception. Cinq principes sous-jacents à cette norme :

ï Une préoccupation amont des utilisateurs, de leurs tâches et de leur environnement

ï La participation active de ces utilisateurs, ainsi que la compréhension claire de leurs besoins et des exigences liées à leurs tâches

ï Une répartition appropriée des fonctions entre les utilisateurs et la technologie

ï L'itération des solutions de conception

ï L'intervention d'une équipe de conception multidisciplinaire

Figure 18 : Cycle de conception ISO 13407

L'objectif de la Norme ISO 13407 établit en 1999 est d'accroître l'utilisabilité des systèmes, c'est-à-dire de concevoir des applications plus faciles à comprendre et à utiliser en permettant une réduction des frais de formation et de l'assistance technique. Il s'agit aussi de permettre l'augmentation de la satisfaction de l'utilisateur par une diminution des gênes et contraintes. Ceci a comme conséquence une augmentation de la productivité pour les utilisateurs et les entreprises. Avec comme résultat final une meilleure impression de qualité, une esthétique et un impact du produit donnant un avantage par rapport aux concurrents.

4.2.2 ISO/TR 16982 :

La norme ISO/TR 16982 définit l'ergonomie de l'interaction homme-système avec les méthodes d'utilisabilité pour la conception centrée sur l'opérateur humain (ISO 2002). Ce document propose un ensemble de méthode basé sur les observations, la mesure des performances, les incidents critiques, les questionnaires et les interviews, des approches créatives comme penser à haute voix ou d'autres méthodes de créativité, des analyses documentaires automatisées ou faisant appel à l'expertise, ainsi que des approches basées sur des modèles.

Ces différentes méthodes peuvent avoir chacune leur pertinence aux différentes étapes d'un projet.

Tableau 5 : intégration des méthodes ISO/TR 16982 dans le cycle de développement

 

Méthodes

Processus du cycle de vie

Observation des utilisateurs

Mesures relatives aux performances

Analyses des incidents critiques

Questionnaires

Interviews

Penser tout haut

Conception & évaluation collaborative

Méthodes de créativité

Analyse documentaire

Méthodes basées sur des modèles

Evaluation par expertise

Evaluation automatisée

Acquisition approvisionnement

++

+

+

+

+

 

+

 

++

 

+

 

Développement et analyse des exigences

++

+

+

++

++

++

+

+

+

+

+

 

Développement conception architecturale

+

++

 

+

+

++

+

++

++

+

+

+

Développement test de qualification

+

++

+

++

++

+

+

 

+

+

+

+

Maintenance fonctionnement

+

+

++

+

+

 

+

 
 
 

+

 

Source : AFNOR

L'ergonomie ne se nourrit pas seulement de normes et de méthodes. Des approches théoriques aident à comprendre les méthodes et à défricher de nouveaux territoires.

4.2.3 Conception basée sur les intentions de l'utilisateur

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)

Intentionnalité

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...).

Le terme intentionnalité dérive du terme latin intendo qui signifie pointer vers, se diriger vers.

Donald Davidson, dans l'article « Intending », discute de façon approfondie la question des intentions dirigées vers le futur (Davidson 1980) .L'article commence par une mise au point sur la théorie des intentions dans l'action et de la rationalisation des actions :

ï L'ergonome a besoin d'expliquer une action, c'est-à-dire de la rationaliser, et de trouver une raison de l'action qui ait pu la causer ;

ï Rationaliser, c'est reconstruire un raisonnement pratique dont l'action est la conclusion ;

ï Un raisonnement pratique comporte comme prémisses

o L'expression d'un désir, sous la forme d'une proposition évaluative du type il est bon (désirable) pour moi d'accomplir la saisie de mes congés

o l'expression, sous forme d'assertions, de croyances pratiques, portant sur les moyens nécessaires pour réaliser le désir dans la situation de l'action ;

Ce point identifie les valeurs et les désirs : accorder de la valeur à la réalisation d'une certaine action revient, selon Davidson, à désirer cette réalisation.

ï Un raisonnement pratique ne comporte rien d'autre que des et des assertions pratiques (exprimant les croyances pratiques).

Le dernier point exclut que des états spécifiques, comme des volitions5(*), puissent figurer dans un raisonnement pratique : « agir avec une intention ne requiert pas qu'existe quelque acte mystérieux de la volonté que ce soit, ni d'attitudes ou d'épisodes spéciaux de vouloir. La théorie n'a besoin que des désirs (ou d'autres pro-attitudes), des croyances, et des actions elles-mêmes ».

Pour MICHAEL BRATMAN l'intention est bien plus qu'une rémanence des choix commis.

Dans son ouvrage (Bratman 1987) il place l'intention au coeur de la prise de décision. Pour lui, la modélisation au moyen des seules notions de désir et de croyance est insuffisante. Il considère la notion d'intention comme intrinsèquement liée à celle de plan. Il dénonce en outre l'ambiguïté de ce second concept dont il donne deux définitions différentes. Selon lui, un plan peut être une structure abstraite identifiant une fonction qui lie un enchaînement d'actions à une situation. C'est le sens le plus communément adopté. Mais il définit aussi le plan comme une structure comprenant en plus des états mentaux. Dans ce second cas, un plan contient, en plus d'une représentation d'un enchaînement d'action, des états mentaux spécifiques à ce plan, tels que des croyances, des désirs. Pour résumer la proposition de BRATMAN, nous pourrions synthétiser le rôle de l'intention dans le processus de prise de décision en trois points :

ï l'intention participe à la recherche d'un plan permettant d'atteindre le but fixé selon les ressources disponibles ;

ï l'intention contraint les plans envisageables (l'entité ne peut avoir d'intentions contradictoires) ;

ï l'intention participe à la remise en cause des croyances.

Un plan est partiel : il ne décrit pas avec précision l'activité qu'il doit guider. Un plan est la composante de l'activité qui traduit la consistance de cette même activité avec nos intentions / désirs.)

Un plan a des propriétés :

ï Hiérarchique

ï Consistant (ressources / exécution)

ï Partiel

ï Est un synonyme de l'intention

ï Explique prospectivement l'activité

Le plan est en effet partiel : ce qui a été fait n'est su qu'après l'activité. Il n'y a pas d'instructions dans le plan. (Suchman 1987)

Que contient le plan ?

ï des consignes ?

ï des conseils ?

A quoi sert-il ?

ï A amorcer l'activité : c'est une donnée du problème.

Cette notion de plan est reprise dans HRA Suite 7. Un Plan HRa définit dans une langue donnée pour chaque catégorie d'acteur (employé, manager, professionnel RH) les domaines et thèmes RH qui les concernent ainsi que les actions fonctionnelles correspondantes.

Pour un employé et un manager, on définit :

- la page d'accueil,

- les fonctions collaboratives

- la barre de navigation comportant les actions fonctionnelles et activités regroupées par thèmes,

Pour un professionnel RH, on définit :

- la page d'accueil,

- les fonctions collaboratives

- les domaines métiers avec pour chaque domaine,

o une page d'accueil,

o une barre de navigation comportant les actions fonctionnelles et activités regroupées par thèmes

4.2.4 Conception basée sur des Critères d'ergonomie

Les critères ergonomiques ont trois caractéristiques qui les distinguent d'autres activités ergonomiques et en font un outil de choix:

· Ils sont basés sur une analyse de l'interface, activité plus rapide et moins dispendieuse que les tests d'utilisabilité;

· Ils sont utilisables par des non-spécialistes du domaine de l'utilisabilité;

· Ils sont explicites pour permettre des mesures précises, puis standardisés pour donner des résultats reproductibles. (Scapin et Bastien 1993)

Figure 19 : vue globale des critères d'ergonomie de Bastien/Scapin

Nous avons retenus sept critères qui sont les suivant :

· Compatibilité : Capacité du système à s'intégrer dans l'activité des utilisateurs. Il s'agit pour nous de ne fournir à l'utilisateur seulement les écrans nécessaires à son rôle.

· Guidage : Faciliter l'utilisation du système et son apprentissage. Aider l'utilisateur a accomplir son plan et réaliser son intention.

· Homogénéité : Concerne la cohérence globale de l'interface. Comme nous l'avons vue lors de la description de l' Ergonomie de l'application et Caractéristiques de HRa Space en page 33, chaque catégorie d'acteur dispose d'une interface similaire.

· Flexibilité : Capacité de l'interface à s'adapter à différents contextes d'utilisation. La structure de l'interface utilisateur a été étudiée pour être homogène et flexible puisque cette structure est identique pour toutes les catégories d'acteur.

· Contrôle utilisateur : Concerne le degré de contrôle de l'utilisateur sur les traitements réalisés par le système. Nous avons indiqué en page 29 qu'un rôle était caractérisé par des droits (concerne l'accès aux données et aux processus métiers). Ces droits déterminent les traitements auxquels l'utilisateur à droit et peut enclencher.

· Traitements des erreurs : Regroupe les différents moyens visant à protéger l'utilisateur des erreurs et à corriger celle-ci. Le fait de ne pas donner les droits d'accès à des tâches pour lequel l'utilisateur n'est pas compétent et de pouvoir restreindre les droits de mise à jour limite les risques d'erreur.

· Concision : Ensemble des moyens visant à réduire la charge perceptive et mnésique de l'utilisateur. Notre objectif de réduire le nombre le page accessible à l'utilisateur répond totalement à ce critère.

Cette sélection de critères nous servira à évaluer à la fin de notre étude la pertinence des rôles dans l'ergonomie de l'application.

4.2.5 Conception basé sur le contexte de l'utilisateur

Pour répondre de façon satisfaisante aux critères d'ergonomie, nous avons besoin de connaitre le contexte de l'utilisation. Le contexte peut être décrit par un ensemble d'interaction.

La Théorie de l'activité

La théorie de l'activité est une manière de décrire et de caractériser les structures de l'activité humaine de toutes sortes. D'abord présenté par les psychologues russes Rubinshtein, Leontiev, et Vigotsky au siècle dernier, la théorie de l'activité plus récemment a gagné une attention croissante parmi les designers et les ergonomes. Pour les ergonomes, le grand potentiel de la théorie de l'activité est de fournir un modèle organisé et cohérent pour examiner, décrire, et comprendre le plus grand nombre de contexte d'activité dans lesquelles l'usage d'un outil logiciel ou de tout autre objet est inclut. Pour que ce potentiel soit entièrement réalisé cependant, les formulations et les expressions un peu vagues de cette théorie de l'activité ont du être reformulé pour être plus précise et accessible.

Dans une formulation qui a été largement copié, la structure de l'activité humaine est schématiquement représentée comme dans le diagramme de la Figure 20. La perspective originale, représentée par le triangle supérieur dans le diagramme, est que cette activité humaine est exécutée par les agents (le sujet) motivé vers la solution d'un problème ou par un but (l'objet ou le motif). Il agi en médiateur par ses outils (les objets) dans un procédé transformationnel produisant un résultat (l'issue). d'Engeström (Engeström, Miettinen et Punamäki 1999) a élaboré cette perspective en ajoutant les éléments dans la moitié inférieure du diagramme, impliquant que toute activité a lieu dans un contexte social (la communauté) avec les responsabilités différenciées (les rôles ou la division de travail) contraint par les facteurs socio-culturels et de procédure (les règles).

Pour comprendre les interactions, la théorie de l'activité et le modèle d'Engeström (Engeström, Miettinen et Punamäki 1999) peuvent nous fournir un cadre de réflexion intéressant.

Figure 20 : modèle d'Engestrom d'analyse de l'activité et des relations médiatrices

Pour illustrer notre propos, Arthur (sujet) doit saisir ses congés (objet). Arthur doit s'authentifier (règles). L'acquisition et la saisie des congés sont aussi soumises à des règles (de gestion). Dans le SIRH, les unités organisationnelles peuvent être considérées comme des « communautés » et ainsi servir à différencier les règles, les sujets ou les objets. Les instruments seront les écrans, l'application, les traitements informatiques. Ce modèle est intéressant pour comprendre les interactions. Le point d'entrée de notre étude est le sujet.

Par rapport à notre modèle conceptuel des données du SIRH : sont modélisé comme dossier de gestion, le sujet (le salarié) et la communauté (l'unité organisationnelle). Les « objets » sont des attributs des éléments du modèle. Les instruments et les règles sont des moyens de traitements des dossiers de gestion.

Figure 21 : Transformation et interprétation du modèle

En continuant notre transformation du modèle, nous pensons que les relations médiatrices passent par des contraintes contextuelles qui décideront des permissions accordées aux rôles du sujet.

Notre objectif est de trouver un moyen définir l'accès aux entités du système afin d'une part d'en limité l'accès pour assurer la confidentialité des données et d'autre part de fournir un environnement de travail orienté métier en ne donnant accès qu'aux écrans utile au rôle de l'utilisateur.

Maintenant que nous avons une vision claire de ce qui doit être accessible en terme de confidentialité et d'ergonomie. Il nous faut maintenant définir ce qui va supporter les contraintes contextuelles qui décideront des permissions accordées. Pour cela nous allons étudier le contrôle d'accès basé sur les rôles. Le modèle R-BAC (Role Based Access Control) propose de structurer l'expression de la politique d'autorisation autour du concept de rôle ..

4.3 R-BAC

4.3.1 Assembler l'authentification à l'autorisation

Un rôle est un concept organisationnel : des rôles sont affectés aux utilisateurs conformément à la fonction attribuée à ces utilisateurs dans l'organisation. Le principe de base du modèle R-BAC est de considérer que les autorisations sont directement associées aux rôles. Dans R-BAC, les rôles reçoivent donc des autorisations de réaliser des actions sur des objets. Comme nous l'avons vu en page 15, le modèle R-BAC ne considère que des autorisations positives (permissions) et fait donc l'hypothèse que la politique est fermée. Un autre concept introduit par le modèle R-BAC est celui de session. Pour pouvoir réaliser une action sur un objet, un utilisateur doit d'abord créer une session et, dans cette session, activer un rôle qui a reçu l'autorisation de réaliser cette action sur cet objet. Si un tel rôle existe et si cet utilisateur a été affecté à ce rôle, alors cet utilisateur aura la permission de réaliser cette action sur cet objet une fois ce rôle activé. Lorsqu'un nouveau sujet est créé dans le SI, il suffit d'affecter des rôles au sujet pour que ce sujet puisse accéder au SI conformément aux permissions accordées à cet ensemble de rôles. Comparé au modèle I-BAC que nous avons vu pour Définir des Modèles d'autorisations dynamiques et contextuelles ci-dessus en page 14, la gestion de la politique d'autorisation s'en trouve simplifiée puisqu'il n'est plus nécessaire de mettre à jour cette politique chaque fois qu'un nouveau sujet est créé. Dans le cas général, n'importe quel ensemble de rôles peut être affecté à un utilisateur et un utilisateur peut activer dans une session n'importe quel sous-ensemble des rôles qui lui ont été affectés. Le modèle R-BAC introduit la notion de contrainte pour spécifier des politiques d'autorisation incluant des situations plus restrictives. Ainsi, une contrainte de séparation statique spécifie que certains rôles, par exemple médecin et infirmier, ne peuvent pas être simultanément affectés à un utilisateur. Une contrainte de séparation dynamique spécifie que, même si certains rôles peuvent être affectés à un même utilisateur, par exemple médecin libéral et chirurgien, ces rôles ne peuvent pas être activés simultanément dans une même session. Dans R-BAC, il est également possible d'organiser les rôles de façon hiérarchique. Les rôles héritent les autorisations des autres rôles qui leur sont hiérarchiquement inférieurs. Lorsqu'un rôle r1 est hiérarchiquement supérieur à un rôle r2, on dit que r1 est un rôle senior de r2. Le modèle R-BAC constitue aujourd'hui un standard.

4.3.2 Utilisateurs, sujets, objets, opérations et permissions

Une terminologie s'est développée pendant les dernières 3 décennies pour décrire les modèles et les systèmes de contrôle d'accès. Presque n'importe quel modèle de contrôle d'accès peut être énoncé formellement en utilisant les notions des utilisateurs, les sujets, les objets, les opérations, et les permissions, et les rapports entre ces entités. Il est important de comprendre ces limites, parce que le lecteur les rencontrera non seulement dans notre mémoire mais également dans la majeure partie de la littérature sur le contrôle d'accès et la sécurité informatique.

Le périmètre de l'utilisateur se réfère aux personnes qui se connectent par une interface au système informatique. Dans beaucoup d'applications, il est possible qu'un utilisateur simple ait de multiples identifiants, et ces identifications peuvent être ouvertes simultanément. Les mécanismes d'authentification rendent cela possible. Une instance de dialogue d'un utilisateur avec un système s'appelle une session.

Un objet peut être n'importe quelle ressource accessible sur un système informatique, y compris des dossiers, des périphériques tels que des imprimantes, des bases de données, et des entités à grain fin telles que différents champs dans des disques de base de données. Des objets sont traditionnellement regardés en tant qu'entités passives qui contiennent ou reçoivent l'information, bien que les mêmes modèles tôt de contrôle d'accès aient inclus la possibilité de traiter des programmes, des imprimantes, ou d'autres entités actives comme objets.

Une opération est un processus actif appelé par un sujet. Les premiers modèles (tel que I-BAC) de contrôle d'accès qui ont été concernés strictement par les contrôle de flux de l'information (c.-à-d., l'accès en lecture/écriture) ont appliqué le terme de sujet à tous les processus actifs, mais les modèles de R-BAC exigent une distinction entre le sujet et l'opération.

Les permissions (ou les privilèges) sont des autorisations pour effectuer certaines actions sur le système. Comme utilisé dans ce livre, et dans la plupart de la littérature sur la sécurité informatique, le terme de permission se rapporte à une certaine combinaison d'objet et d'opération. Une opération particulière utilisée sur deux objets différents représente deux permissions distinctes, et de la même façon, deux opérations différentes appliquées à un objet simple représentent deux permissions distinctes.

4.3.3 Description formelle du R-BAC par Ferraiolo et Kuhn

Dans leur ouvrage de référence (Ferraiolo, Kuhn et Chandramouli 2003) D. Ferraiolo et al. Fournissent une description formelle du modèle R-BAC.

Tableau 6 : Description formelle de R-BAC de Ferraiolo et Kuhn

Description formelle originale de R-BAC

Pour chaque sujet, le rôle actif est celui qui est actuellement l'objet en utilisant:

AR (s :sujet) = (Le rôle actif de sujet s)

Chaque objet peut être autorisé à effectuer un ou plusieurs rôles:

RA (s :sujet) = (Autorisé rôles pour objet s)

Chaque fonction peut être autorisé à réaliser une ou plusieurs opérations:

TA(r :rôle) = (Transactions autorisées pour rôle r)

Les Sujets peuvent exécuter des transactions. Le prédicat exécuter(s, t) est vraie si et seulement si l'objet peut exécuter la transaction t à l'heure actuelle, sinon, elle est fausse:

Exécuter(s :sujet ;t :transaction) = [Vrai si sujet s peut exécuter transaction t]

1. Rôle de la mission: Un sujet peut exécuter une transaction que si le sujet a été choisi ou assigné un rôle:

s : sujet,t : tran ? exec(s,t) \u8658Ë AR(s) ? ?

2. Rôle d'autorisation: Un rôle actif du sujet doit être autorisé pour le sujet:

s : subject ? AR(s) \u8838 RA(s)

3. Autorisation de la transaction: un objet peut exécuter une transaction que si l'opération est autorisée pour le rôle actif du sujet:

s : subject,t : tran ? exec(s,t) \u8658Ë t \u8712 TA(AR(s))

Notez que, parce que la condition de l'article 3 est «seulement si», cette règle prévoit la possibilité que des restrictions supplémentaires puissent être mises sur l'exécution des transactions.

Cette règle ne constitue pas une garantie pour une transaction d'être exécutable seulement parce que c'est une TA [AR (s)]. L'ensemble des transactions sont potentiellement exécutables par le rôle actif du sujet. Par exemple, un stagiaire pour un rôle de supervision peut être assigné au rôle de superviseur, mais peut avoir des restrictions appliquées à son rôle, qui limitent les transactions accessibles à un sous-ensemble de ceux qui sont normalement autorisés pour le rôle de superviseur.

Figure 22 : les relations dans R-BAC

Figure 23 : les permissions s'appliquent sur des opérations et des objets

Le modèle brut de R-BAC est défini de façon formelle dans les tableaux suivant :

Tableau 7 : Définition du modèle brut de R-BAC

UTILISATEURS, RÔLES, OPS et OBS : (Respectivement Utilisateurs, les rôles, les activités et les objets)

AU UTILISATEURS X ROLES : une relation n,n entre utilisateur et rôle (relation d'assignation d'un utilisateur à un rôle).

Utilisateurs_assignés : (r :ROLES) 2utilisateurs, application du rôle à un ensemble d'utilisateurs. Formellement Utilisateurs_assignés(r) = {u UTILISATEURS | (u,r) AU)

PRMS = 2(OPSxOBS), l'ensemble des permissions.

PA PRMS X ROLES, relation n,n entre permissions et rôles (relation d'assignation rôle-permission).

Permission_assignées (r :ROLES) 2PRMS, l'application du rôle r à un ensemble de permission. De façon formelle Permission_assignées (r :ROLES)= {p\u8712PRMS|(p,r)\u8712PA}

SUJETS : l'ensemble des sujets.

Utilisateur_sujet (s :SUJET) UTILISATEUR, l'application des sujets s à l'ensemble des utilisateurs associés aux sujets.

Roles_sujet(s :SUJET) 2ROLES, l'application de sujets s à un ensemble de rôle. Soit Roles_sujet(si) {r \u8712 ROLES|(Utilisateur_sujet(si),r) \u8712 AU}


Tableau 8 : Propriété des authorisation du rôle

Propriété 1 : autorisation du rôle = Un sujet ne peut jamais avoir un rôle actif qui n'est pas autorisé pour son utilisateur.

\u8704Í s:SUJETS, u : UTILISATEURS, r :ROLES

r \u8712 roles_sujet(s) ^ u \u8712 utilisateur_sujet(s) \u8658Ë u \u8712 utilisateur_assigné(r)

? acces: SUJETS × OPS × OBS ? BOOLEAN;

? acces(s, op, o) = 1 Si le sujet peut accéder à l'objet sur l'opération en utilisant op, sinon 0


Tableau 9 : Propriété des autorisations d'accès aux objets

Propriété 2 : autorisation s'accès à l'objet = Un sujet s peut effectuer une opération op sur objet O seulement si il existe un rôle r qui est inclus dans le sujet du rôle actif fixés et il existe une permission qui est attribué à r tels que la permission autorise l'exécution d'op portant sur O .

s:SUJETS, op:OPS, o:OBS

access(s, op, o) \u8658Ë \u8707Îr: ROLES, p:PRMS r \u8712 roles_sujet ^ p \u8712 permissions_assigné(r) ^ (op, o) \u8712 p


Ces descriptions formalisées ne favorisent pas la créativité. Nous allons illustrer notre propos avec le schéma suivant :

Figure 24 : Association utilisateur rôle et privilèges rôles

4.4 Définir un modèle conceptuel des données pour R-BAC

Nous avons identifiés plusieurs éléments pour construire ce modèle conceptuel. Il s'agit de :

· Des utilisateurs,

· Les actions fonctionnelles,

· Les règles métiers,

· Les rôles,

· L'unité organisationnelle,

· Les permissions,

· Les contextes,

· Les exclusions,

· Les risques,

· Les héritages hiérarchiques.

Nous allons maintenant détailler tous ces éléments.

4.4.1 Utilisateurs

Un utilisateur déclaré dans l'annuaire d'entreprise devant avoir accès à l'application. C'est à lui que sera attribué un rôle.

4.4.2 Action fonctionnelle

Par exemple, une action fonctionnelle peut être une action concernant l'état civil d'un individu, l'historique des absences, les données professionnelles.

Dans le SIRH, un objet action fonctionnelle est caractérisé par :

ï une langue,

ï une technologie (processus guidés, rapports, noeuds d'arbres Web, DMS),

ï une activité,

ï un code action contextuel par défaut.

Dans notre modèle R-BAC, les permissions d'exécution concernent les actions fonctionnelles. Il ne concerne pas le lancement d'exécutable comme sur un micro-ordinateur.

4.4.3 règles métiers (business rules)

Elles vont nous aider à créer une association entre un ensemble de caractéristiques métiers et un rôle.

Exemple : si métier=Expert_recrutement et Unité Organisationnel = Siege alors rôle = Expert_recrutement siège

4.4.4 Rôle

Une caractéristique permettant de définir le métier ou le domaine de responsabilité au sein de l'organisation

4.4.5 Unité organisationnelle

Organisation au sein de l'entreprise. L'unité organisationnelle est la plus petite entité d'organisation dans une structure organisationnelle. Il s'agit d'un rôle ou d'une position tenue par une entité organisationnelle (personne, machine ou système informatique) (Vernadat 1996).

La granularité de la définition de l'organisation dépendra de la volonté de délimité les périmètres de chacun. Comme nous l'avons dans la définition formelle de R-BAC, l'organisation n'est pas prise en compte. Elle le sera dans les versions étendues de R-BAC. Or comme nous le verrons plus loin l'unité organisationnelle est une contrainte contextuelle importante pour le SIRH.

4.4.6 permissions

Le droit d'appliquer certaines opérations sur certaine ressource.

4.4.7 contextes

C'est un environnement structurel et événementiel qui sert de cadre. C'est aussi un sous-ensemble du champ d'application des permissions. Cet élément nous semble important, nous allons le développer plus loin dans notre étude en particulier avec le concept de contraintes contextuelles qui permettront de combler les lacunes du modèle initial de R-BAC.

4.4.8 Exclusions

Il s'agit de déterminer de façon manuelle ou automatique les incohérences et les incompatibilités entre différentes permissions et/ou différents rôles et/ou différents couples (rôles, organisations).

4.4.9 Risques

Un risque est la possibilité d'être exposé aux conséquences néfastes d'événements futurs. Dans le cadre de R-BAC, il s'agit de la définition du mode d'application de l'exclusion en fonction de la criticité du risque associé.

4.5 règles d'héritage des permissions

Les rôles peuvent être hiérarchisés entre eux comme nous l'avons vu en page 50 dans Assembler l'authentification à l'autorisation. L'héritage d'une permission (d'un droit) permet à un utilisateur de se voir reconnaître son droit parce que soit son rôle soit son organisation en hérite. Cette notion permet de réduire très significativement le nombre de règles pour définir l'ingénierie des rôles.

4.5.1 Héritage des permissions par les rôles

L'héritage par les rôles fait partie du modèle R-BAC. Il permet de s'assurer qu'un rôle possède bien tous les droits associés aux rôles qu'il inclue.

Ainsi si le rôle « Expert Dossier Administratif » contient le rôle « Expert RH » et le rôle « Dossier Administratif », le rôle « Expert Dossier Administratif » héritera des droits et permissions associés aux rôles « Expert RH » et « Dossier Administratif » en plus de ses droits et permissions propres.

4.5.2 Héritage organisationnel des permissions

L'héritage par les organisations permet d'affecter à toute une organisation un droit ou une permission particulière.

Un utilisateur qui appartient à une organisation appartient « d'une certaine manière » à tous les noeuds de cette organisation. Il peut donc se voir affecter des droits associés.

Un utilisateur affecté à une unité organisationnelle de niveau 1 (Siège) peut voir toutes les UO subordonnées (niveau > 1). Un utilisateur affecté à une UO de niveau 3 peut voir le UO de niveau inférieur ou égale à 3 sous réserve qu'il appartienne au groupe d'acteur "manager" ou "expert RH".

4.5.3 Héritage hiérarchique des permissions

Ce type d'héritage se positionne au niveau des utilisateurs pour leur permettre d'hériter d'applications associées aux organisations sous-jacentes. Cet héritage permet à l'utilisateur d'une organisation parente de pouvoir effectuer les mêmes opérations que les utilisateurs des organisations sous-jacentes.

4.5.4 Héritage des permissions par les couples (rôle, organisation)

L'héritage s'applique aussi sur les couples (rôles, organisation) par application des règles associées aux rôles et aux organisations. Par exemple, si l'on affecte au couple (rôle=professionnel RH, organisation=Siège) le droit d'accéder l'action fonctionnelle "Saisir éléments de Paie", ce droit s'appliquera à :

· Tous les Professionnels RH du siège sous-jacent (héritage par l'organisation).

· Tous les responsables Professionnels RH de la Direction générale (héritage par les rôles).

· Tous les responsables Professionnels RH des organisations sous-jacentes (directions fonctionnelles reliés au siège).

· 4.5.5 Les exclusions

Les exclusions permettent de définir au niveau de la politique de sécurité des accès les règles de séparation des tâches (en anglais « segregation of duties »). Le modèle R-BAC étendu permet de définir des règles avancées d'exclusion qui peuvent combiner des ensembles de rôles, de couples (rôles, organisation), de permissions et de couples (permission, organisation)...

Il est ainsi possible, par exemple, d'empêcher qu'un utilisateur soit à la fois gestionnaire administratif de son unité organisationnelle et puisse saisir ses propres éléments de paie.

4.5.6 Propositions de modèle conceptuel pour un R-BAC étendue

Nous allons regrouper les concepts définit précédemment au sein d'un schéma récapitulatif.

Figure 25 : Modèle conceptuel des données pour un R-BAC étendu

4.5.7 Les limites de R-BAC

Ce que la plupart des spécialistes reprochent à R-BAC, c'est qu'il n'y a pas de prise en compte de l'organisation. Chacun reprend le noyau de R-BAC et lui implémente des contraintes supplémentaires. Il nous faut donc voir comment ajouter ces contraintes supplémentaires. Comme l'ont souligné (Saidani et Nurcan 2007) la prise en compte du contexte de l'utilisateur permet de répondre aux besoins de flexibilité des processus d'entreprise. Le résultat est une variabilité du comportement en fonction du contexte. Dans le cadre de notre étude, nous pensions initialement que le contexte changerait avec le rôle. C'est le rôle qui donne les éléments du contexte, si un paramètre du rôle change, le contexte changera grâce aux contraintes contextuelles que nous allons maintenant définir.

Figure 26 : Taxonomie des contraintes contextuelles d'après (Saidani et Nurcan 2007)

4.5.8 Les différentes catégories de contraintes dans R-BAC

En principe, R-BAC s'appuie sur la définition des contraintes conventionnelles dans les différentes parties du modèle R-BAC (Ferraiolo, Kuhn et Chandramouli 2003). Toutefois, les premiers efforts de recherche concernant R-BAC ont porté principalement sur les contraintes de séparation des droits. Avec l'intérêt croissant pour R-BAC, la recherche se rapportant à d'autres types de contraintes sur R-BAC a aussi gagné en importance [voir, par exemple, La gestion des identités et des accès en page 15]. Dans ce document, nous allons détailler les contraintes contextuelles de R-BAC. Ensuite, nous décrirons certaines dimensions pour la catégorisation des contraintes R-BAC qui nous semble pertinente. Ensuite, nous utiliserons ces dimensions pour expliquer notre définition du contexte. Au début, nous faisons une distinction entre les contraintes statiques et dynamiques:

· Les contraintes Statiques sont les contraintes qui peuvent être évaluées par des "temps d'administration" d'un modèle R-BAC, par exemple, la contrainte de séparation des fonctions statique (SSD) qui précise que deux rôles sont mutuellement exclusifs et ne doivent jamais être attribué à un même sujet en même temps.

· Les contraintes dynamiques ne peuvent être vérifiées qu'au moment de l'exécution en fonction des valeurs effectives d'attributs spécifiques ou par rapport à des caractéristiques de la session en cours. Par exemple, à cause de la séparation dynamique des fonctions qui définissent les contraintes réciproques que deux rôles exclusifs ne doit jamais être activées en même temps au sein de la même session utilisateur, ou que des contraintes de temps qui limitent à un rôle une activation spécifique par rapport à un intervalle de temps (par exemple, de 8 heures du matin à 8 heures du soir).

Un autre critère pour classer les contraintes R-BAC est la distinction entre facteurs endogènes (modèle intrinsèque) et exogènes (environnementaux) :

Les contraintes endogènes

Elles sont complètement contraintes en ce qui concernent les propriétés intrinsèques d'un modèle R-BAC et intrinsèquement affectées à la structure et à la construction d'une instance d'un modèle R-BAC. Par exemple, une obligation de séparation statique (SSD) pesant sur deux permissions mutuellement exclusives interdit l'assignation de ces permissions pour le même rôle. En outre, il influe également sur la définition du rôle respectif de la hiérarchie, car il interdit en outre que deux rôles distincts qui possèdent les autorisations correspondantes puissent avoir un rôle senior commun. Sinon, ce rôle senior pourrait acquérir deux permissions (mutuellement exclusif) violant de ce fait la contrainte SSD correspondante [voir, par exemple, (Ferraiolo, Kuhn et Chandramouli 2003)].

Les contraintes exogènes

Elles sont des contraintes qui sont exclusivement des attributs qui n'appartiennent pas aux éléments essentiels d'un modèle R-BAC (par exemple, les contraintes de temps qui limitent l'activation d'un rôle à un intervalle spécifique de temps ou qui permettent l'accès à des opérations sur une ressource seulement un jour de la semaine), ou qui font référence à des attributs extérieur (c'est-à-dire extérieurs au modèle R-BAC ) ou des propriétés d'un élément du modèle R-BAC spécifiques (par exemple, l'emplacement actuel du projet ou la cession d'un sujet spécifique). En général, les contraintes exogènes sont définies comme étant des conditions qui prennent en compte des données externes pour certaines opérations ou les décisions d'un contrôle d'accès au service.

A côté de la catégorisation statique / dynamique et endogène / exogène, les contraintes peuvent aussi être subdivisée en contraintes d'autorisation et en contraintes d'assignation :

Les contraintes d'autorisation

Elles sont des contraintes qui placent des contrôles supplémentaires sur les décisions de contrôle d'accès. Ainsi, même si le sujet est en possession d'une autorisation qui accorde une certaine demande d'accès, l'accès ne peut être permis que si d'autres contraintes d'autorisation correspondante sont remplies en même temps. Par exemple, c'est le cas des accès par abonnement par exemple. Quand l'abonnement est terminé, l'accès devient interdit.

Les contraintes d'assignation

Ce sont les contraintes qui contrôlent l'assignation ou l'activation des permissions et des rôles (par exemple, la contrainte de séparation des fonctions). En fait ces contraintes d'assignation sont le coeur de notre problématique. Il s'agit de choisir et de déterminer de façon manuelle ou automatique les incohérences et les incompatibilités entre différentes permissions et/ou différents rôles et/ou différents couples.

Les catégories ci-dessus ne sont pas complètement orthodoxes, et n'ont pas la prétention de fournir un cadre de classification pour tous les types possibles de contraintes R-BAC. Néanmoins, ces catégories permettent d'examiner les différents aspects qui peuvent être observés individuellement, et faciliter la définition des contraintes contextuelles R-BAC.

Figure 27 : Les permissions R-BAC avec des contraintes contextuelles

4.5.9 Contraintes contextuelles

En premier lieu, une contrainte contextuelle est un concept abstrait au niveau de la modélisation (à l'instar des autres types de contraintes, ou le concept de rôle). Une contrainte contextuelle aide à préciser certains attributs du contexte. Ils doivent remplir comme conditions de permettre une opération. En respectant ce qui concerne les catégories mentionnées précédemment, nous avons donc à définir les contraintes contextuelles comme des contraintes d'autorisation dynamique exogènes. Toutes les contraintes contextuelles peuvent (en principe) être également appliquée à l'assignation ou l'activation des contraintes (cf. 0 ci-dessus), jusqu'à présent, notre expérience sur la modélisation et l'application des contraintes contextuelles sont principalement basées sur leur utilisation comme des contraintes d'autorisation dynamique exogènes. Comme les décisions d'autorisation sont basés sur les permissions d'un sujet particulier possédant un rôle, les des contraintes contextuelles sont associé aux autorisations R-BAC (voir la Figure 27 : Les permissions R-BAC avec des contraintes contextuelles).

L'attribut de contexte

Il représente une certaine propriété de l'environnement dont la véritable valeur pourrait changer dynamiquement (comme le temps, la date, ou les données d'une session par exemple) ou qui varie pour différentes instances de la même entité abstraite (par ex, le lieu de travail, l'affectation, l'anniversaire, ou la nationalité). Ainsi, les attributs de contexte sont un moyen de rendre (exogène) l'information contextuelle explicite. Au niveau programmation, chaque attribut de contexte (AC) représente une variable qui est associée avec un domaineAC qui détermine le type et la gamme de valeurs que cet attribut AC peut prendre (par ex, une date, un nombre entier, une chaine).

La fonction de contexte

C'est un mécanisme pour obtenir la valeur courante d'un attribut spécifique de contexte (c.-à-d., pour saisir explicitement l'information du contexte). Par exemple, une fonction date() pourrait être définie pour renvoyer la date du jour. Naturellement une fonction de contexte peut également recevoir un ou plusieurs paramètres d'entrée. Par exemple, une fonction grade(sujet) peut prendre le nom du sujet hors du triplet (sujet, opération, objet) pour obtenir le grade du sujet, qui lance une demande courante d'accès, par exemple, le grade peut être lu dans son dossier du personnel.

Une condition de contexte

C'est un prédicat (une fonction booléenne) qui se compose d'un opérateur et de deux opérandes ou plus. Le premier opérande représente toujours un attribut de contexte, alors que les autres opérandes peuvent être l'un ou l'autre attribut de contexte ou des valeurs constantes. Toutes les variables doivent être rectifiées avant évaluation. Par conséquent, chaque attribut de contexte est remplacé par une valeur constante en utilisant la fonction correspondante de contexte avant l'évaluation de la condition.

Les contraintes contextuelles sont utilisées pour définir les autorisations conditionnelles. En ce qui concerne les termes définis ci-dessus, une autorisation conditionnelle est une autorisation qui est associée à un ou plusieurs contextes, les contraintes et les accès accordés correspondants si chaque contrainte contextuelle a la valeur "vraie". Par conséquent, les autorisations conditionnelles accordent un accès opérationnel si les valeurs réelles des attributs du contexte venant de l'environnement remplissent les contraintes contextuelles rattachées. La relation entre le contexte des contraintes et des permissions est une relation (n,n) (voir ci-dessus Figure 27). De ce fait, un certain nombre de permissions peuvent être associées à une même contrainte contextuelle si nécessaire.

De la même manière que nous avions définis les règles du R-BAC brut, nous pouvons l'enrichir de la façon suivante avec une définition algébrique des contraintes contextuelles. Cette définition est donnée ci-dessous (Elle étend les définitions fournies par (Ferraiolo, Kuhn et Chandramouli 2003), il est ajouté en particulier l'abréviation PRMS réfère à l'ensemble de permissions) (STREMBECK et NEUMANN 2004).

Tableau 10 : Propriétés des contraintes contextuelles

ATTS L'ensemble des attributs du contexte (par exemple, heure locale, l'adresse IP locale, le nom de l'objet, grade du sujet).

DOMAINE Le jeu des domaines (par exemple, boolean, date, entier, réel, chaines).

CONSTANTES = {x | x est une valeur constante ? domaine(x) ? DOMAINS}.

OPERANDES = ATTS ? CONSTANTES

OPERATEURS, l'ensemble des opérateurs de comparaison, tel que =, =, >, <, =, =.

domaine(oprtr : OPERATEURS) ? {d ? DOMAINES}, une fonction pour déterminer l'ensemble des domaine pour lequel un opérateur est spécifié.

domaine(oprnd : OPERANDES) ? {d ? DOMAINES}, une fonction pour déterminer le type d'une opérande.

CONDITIONS = 2 OPERANDS × OPERATORS, ?c ? CONDITIONS : c ? {(oprnd1, . . . , oprndx , oprtr)|oprnd1, . . . , operndx ? OPERANDES, oprtr ? OPERATEURS} ? {domaine(oprnd1) ? · · ·? domaine(oprndx ) ? domain(oprtr)}.

CC = 2 CONDITIONS, l'ensemble des contraintes contextuelles.

PCL ? PRMS×CC, couplage permission/condition contextuelle

linked ccs(p : PRMS) ? {contraintes ? CC}, le couplage d'une permission p à un ensemble de contrainte contextuelle. Formellement: linked ccs(p) = {c ? CC | (p, c) ? PCL}

Cette définition algébrique rend difficilement compte des contraintes endogènes, comme la séparation des droits ou des contraintes de cardinalités, par exemple. Elles ne peuvent souvent être obtenues qu'à partir des règles métier d'une organisation particulière. Des contraintes comme : « les rôles "gestionnaire RH" et "contrôleur paie" doivent être statiquement mutuellement exclusive », ou « la Cardinalité maximale pour l'utilisateur avec un rôle "contrôleur paie" est "unique" ».

Maintenant nous avons de nombreux outils pour construire notre ingénierie des rôles. Cette ingénierie va nous aider à préciser les contraintes exogènes (contexte). Dans la section 5, nous allons proposer un cadre pour les processus d'ingénierie.

5 A la recherche d'une ingénierie des rôles

Le contrôle d'accès par les rôles est une innovation majeure. Peu de consultants en connaisse les concepts. Notre objectif est de découvrir comment utiliser au mieux cette approche novatrice à partir de ce que nous avons étudié jusqu'à présent. Comment passer d'une méthode empirique à une méthode scientifique ?

5.1 Méthode empirique

Sans vrai recul sur la nouveauté que constitue un contrôle d'accès basé sur les rôles, l'approche la plus courante pour créer une politique d'accès est une approche descendante (Top-Down).

Cette approche commence, soit par la définition d'un modèle de sécurité des accès qui soit cohérent avec les métiers et le système d'information de l'organisation, soit par une analyse des droits définis dans les systèmes et applications.

Il existe une autre approche qui part au contraire du terrain et de la réalité des accès.

Cette approche ascendante (Bottom-Up) permet de collecter de façon simple les accès des utilisateurs à leurs applications durant une période donnée et d'associer automatiquement à chaque utilisateur l'identifiant qu'il utilise pour accéder à son application.

Une fois les accès effectifs collectés, les utilisateurs sont associés à leur rôle et à leur organisation. Une politique optimisée en est déduite. Cette politique peut ensuite, via les identifiants des utilisateurs, être comparée aux droits déclarés dans les systèmes cibles pour analyser les écarts et en déduire des adaptations. Prenons comme référence la politique idéale de l'entreprise qui permet d'associer correctement un droit (ou une permission) à un utilisateur.

· L'approche Top-Down qui s'appuie sur les droits déclarés dans les systèmes et applications génère une politique plus permissive que la politique cible car cette approche intègre les failles déclarées dans les systèmes et applications.

· L'approche Bottom-Up qui s'appuie sur les accès effectivement effectués pendant une certaine période génère une politique trop restrictive par rapport à la politique idéale car cette politique n'intègre pas les accès qui auront été faits en dehors de la période de collecte.

La comparaison des écarts entre la politique Bottom-Up et les systèmes cibles (Top-Down) permet de focaliser l'analyse sur les points qui permettront de se rapprocher de la politique idéale.

La définition d'une politique R-BAC étendu à partir d'une approche Bottom-Up comporte quatre étapes principales.

1. La collecte des accès nécessaire.

2. La définition des attributs des utilisateurs.

3. La validation du modèle.

4. La création de la politique à partir des accès nécessaire.

5.1.2 La collecte des accès nécessaire

La collecte des accès effectivement effectués est au coeur de l'approche Bottom-up. Elle va nous permettre de définir une politique qui reflète la réalité des accès. A partir des accès tels qu'ils existaient sur l'ancien système, nous allons définir les accès aux pages ayant des actions fonctionnelles similaires.

Cette collecte va nous permettre d'obtenir les relations suivantes :

Figure 28 : collecte des accès nécessaires à l'utilisateur

5.1.3 La définition des attributs des utilisateurs.

Cette étape va nous permettre d'associer un rôle et une organisation à chaque utilisateur.

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"

· Expert Dossier Administratif

· Expert Recrutement

· Expert Développement professionnel

· Expert Compétences

· Expert Formation

· Expert écoles

· Expert Risques professionnels

· Expert GTA

· Expert Règle de GTA

· Expert Paie local

· Expert paie central

· Expert Règle de paie

· Expert Déclaration de paie

· Gestionnaire GA/PAIE

· Expert financier (CF)

· Expert paramétrage applicatif

· Expert Organisation

 

· Définition des organisations

Les 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...

Structure Hierarchique

UO de Niveau

Population

APHP

1

A définir

Hopital

2

Tous les dossiers de l'hôpital

Pôle :
* Pôle Administratif
* Pôle Médical
* Pôle Service

3

Tous les dossiers du pôle découpé en :
* Dossier du pôle Administratif
* Dossier du pôle Médical
* Dossier du pôle Service

Unité de Gestion

4

Personnel Non Médical (PNM)

Service

4

Personnel Médical (PM)

UF/UC

5

Personnel Médical (PM) - Affectation cible

Associer un rôle et une organisation à chaque utilisateur

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 :

Rôles Métiers RH

Exemples d'activités

Niveau dans la structure Hierarchique

Périmètre de gestion des populations

Expert Dossier Administratif

Embauche
Contrat
Carrière

UO de niveau 2 (Hôpital / Site)

Toute la population de l'Hôpital / Site

Expert Décisions

Configuration
Suivi des décisions

UO de niveau 2 (Hôpital / Site)

Toute la population de l'Hôpital / Site

Expert Recrutement

Demandes de personnel
Suivi des recrutements

UO de niveau 2 (Hôpital / Site)

Toute la population de l'Hôpital / Site

Expert GTA

Plannifier l'activiter
Suivre l'activité

UO de niveau 2 (Hôpital / Site)

Toute la population de l'Hôpital / Site

Expert Paie Local

Voir tous les résultats
Calculer

UO de niveau 2 (Hôpital / Site)

Toute la population de l'Hôpital / Site

Expert Paie Central

Voir tous les résultats
Calculer

UO de niveau 1 (APHP)

Toute la population de l'APHP

Expert Déclaration de paie

Production de la DADS-U
Production de la DUCS

UO de niveau 1 (APHP)

Toute la population de l'APHP

5.1.4 La validation du modèle.

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.

5.1.5 La création de la politique à partir des accès nécessaire

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

5.1.6 Analyse critique du modèle existant des déclarations faites dans les systèmes et 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

5.2 ingénierie des rôles

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.

5.2.1 ingénierie des rôles basés sur les scénarios

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.

5.2.2 Ingénierie des rôles basés sur les buts

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).

5.2.3 Une ingénierie des exigences pour les rôles

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.

5.2.4 Un cadre de référence pour les scénarios :

(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.

5.2.5 Appliquer l'utilisation des scénarios à l'ingénierie des rôles.

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.

5.2.6 Interrelations des modèles et définition documentaire

Nous allons maintenant préciser les interrelations entre les modèles et les livrables du processus.

Le modèle de scénario :

Il se compose de tous les scénarios d'utilisation du système étudié. Il sert de modèle de base pour notre approche.

Le catalogue des permissions :

Il est constitué de toutes les permissions identifiées pour le système. Puisque les étapes du scénario sont associées avec des opérations d'accès, les permissions sont tirées des scénarios. Les permissions sont constituées des paires (opération, objet) et ont un identifiant unique. Nous retrouvons dans ce catalogue les écrans devant être accédé par les utilisateurs.

Le catalogue des contraintes :

Il contient les contraintes qui doivent être appliquées pour les permissions. Dans une application plus approfondit du processus, ce catalogue peut être enrichit des contraintes appliquées aux rôles (qui seront définit plus tard). La définition des contraintes contextuelles (Voir Les différentes catégories de contraintes dans R-BAC étudié ci-dessus en page 57) s'intégreront dans ce catalogue. Nous retrouverons dans ce catalogue les restrictions d'accès relatives à la confidentialité.

Les définitions de tâches :

Elles décrivent les tâches que doivent effectuer les utilisateurs avec le système étudié. Chaque tâche est composée d'un ou plusieurs scénarios qui sont exécutés séquentiellement ou en parallèle pour atteindre un but.

Les profils de travail :

Ils se composent des différentes définitions de tâches. Chaque profil de travail est unique. Il se veut une description complète de toutes les tâches qu'un utilisateur doit accomplir ou est autorisé à accomplir. Dans notre approche, c'est le rôle préliminaire à « R-BAC ». Nous détaillerons par la suite les différences entre nos profils de travail et les rôles R-BAC, ainsi que le processus pour extraire une hiérarchie de rôle R-BAC des profils de travail.

Figure 31 : composition d'un profil de travail

Le modèle concret R-BAC :

C'est le résultat final de l'ingénierie des processus. Il se compose de tous les rôles du système organisé en une ou plusieurs hiérarchies de rôle. Nous entendons par hiérarchie de rôles, les règles d'héritage des rôles seniors qui héritent des permissions et des contraintes de tout leur rôle junior.

Notre dispositif pourra être résumé de la façon suivante :

Figure 32 : interrelation des modèles et des documents utilisés et produits dans le processus d'ingénierie des rôles

5.2.7 Des profils de travail aux rôles

Comme nous l'avons indiqué plus haut, les permissions ne sont pas explicitement associées avec les profils de travail. Elles peuvent être obtenues transitivement par les scénarios associés à un profil de travail ( voir Figure 31 : composition d'un profil de travail). C'est une différence essentielle entre les profils de travail et les rôles R-BAC, depuis que le dispositif R-BAC permet d'assigner directement les permissions aux rôles.

De plus les profils de travail sont définis de façon autonome. Ils n'ont aucun lien direct entre eux. Puisqu'une tâche peut être assignée à plus d'un profil de travail et que chaque scénario peut être assigné à plus d'une tâche, il y a potentiellement de nombreuses redondances dans ces définitions de profils. C'est aussi une autre différence entre les profils et les rôles qui, eux, permettent des héritages hiérarchiques qui limite ces redondances. C'est en cela que les profils de travail peuvent être vue comme l'étape préliminaire des rôles R-BAC.

Les liens de traçabilité : conçu pour le changement.

Le modèle d'interrelation décrit en Figure 32 met en lumière les liens de traçabilité entre modèles (Gotel et Finkelstein 1994). Ces traces sont essentielles pour rendre efficace la gestion des modèles. Idéalement, cela permet de retrouver quelles permissions sont demandées dans un scénario aussi bien que de savoir dans quelle scénario (tâches, ou profil) utilise telle ou telle permission. Les liens de traçabilité facilitent la compréhension des modèles. Ils sont aussi des pré-requis pour une gestion du changement efficace. Ils assurent une propagation efficace des changements effectués dans les modèles. Par exemple si un nouveau scénario d'utilisation du système est défini, dans lequel nous devons assigner des tâches et des profils, cela pourrait mettre à jour le modèle R-BAC rattaché. D'autres liens de traçabilité pourraient être ajoutés comme :

· « Concrétisé par » entre deux scénarios,

· « Nécessaire pour exécuter » entre une permission et un scénario,

· « Défini par » entre une contrainte et l'origine de cette contrainte,

· « est une partie de » entre un scénario et une tâche, ou

· « implémenté dans » entre un profil de travail et un rôle R-BAC.

Malheureusement ce genre de liens, s'ils sont intellectuellement intéressant, consomment beaucoup trop de temps et complexifient le dispositif en le rendant plus difficile à gérer. Il ne faut donc retenir que les liens essentielles pour la gestion des modèles tels qu'ils ont été définis par (Neumann et Strembeck 2002).

Néanmoins, il nous est apparu intéressant de signaler que nous pouvions gérer les liens de traçabilité lors du processus de conception. Mais la gestion de la traçabilité du processus de conception est un domaine de recherche à part entière avec le design rationale (Moran et Carroll 1996) et cela dépasse le cadre de ce mémoire.

5.3 Mise en oeuvre du processus d'ingénierie des rôles

Nous allons vous détailler maintenant les sous-processus de (Neumann et Strembeck 2002) et voir comment les adapter dans le cadre d'une mise en oeuvre dans un SIRH.

5.3.1 Identifier et formaliser des scénarios d'utilisation

Dans ce sous-processus, les scénarios d'utilisation sont identifiés et formalisés. En premier, une phrase décrit l'objet du scénario :

Exemple : « saisir les données individuelles de l'agent », « décrire le parcours de l'agent », « compléter le dossier ».

Figure 33 : sous-processus de formalisation du scénario

Le scénario et ses séquences : il doit pouvoir répondre à l'ensemble des questions habituelles (QQCOQP : Qui, quoi, comment, où, quand, pourquoi)

Identifiant : SC1GAPRH

Thème : Gestion dossier Agent

Objet : saisir et gérer les données individuelles du dossier agent

Qui : Expert dossier administratif site, (catégorie d'acteur Professionnel RH)

Où : Unité de organisationnelle (siège ou établissement)

 

Action fonctionnelle

Mise à jour des données individuelles et changement d'affectations sur le site

Contraintes contextuelles

Ergonomie

Confidentialité

Séquence 1 (comment manière, moyens)

Le gestionnaire accède à la page XAECR1

Il saisit un n° de dossier d'un agent appartenant à son UO

Le gestionnaire administratif (GA) accède aux données en mise à jour. Il ne doit voir que les agents relevant de l'UO dont il est gestionnaire

Séquence 2 :

Le gestionnaire accède à la page XAECR1

Il saisit un n° de dossier d'un agent n'appartenant pas à son UO

Le GA ne peut pas accéder à ce dossier s'il n'appartient pas à l'UO dont il est gestionnaire

...

 
 

Identifiant : SC1GAEMP

Thème : Gestion dossier Agent

Objet : saisir et gérer les données individuelles du dossier agent

Qui : Agent, (Catégorie d'acteur Employé)

Où : Unité de organisationnelle (siège ou établissement)

 

Action fonctionnelle

Mise à jour des données individuelles et changement d'affectations sur le site.

Contraintes contextuelles

Ergonomie

Confidentialité

Séquence 1 (comment manière, moyens)

L'employé accède à la page XAECR1

Il saisit son n° de dossier

L'employé accède aux données en mise à jour. Il ne doit voir que son propre dossier dont il est gestionnaire. La mise à jour est validé par le N+1

Séquence 2 :

L'employé accède à la page XAECR1

Il saisit un n° de dossier d'un agent n'appartenant pas à son UO

L'employé ne peut pas accéder à ce dossier.

...

 
 

Identifiant : SC1GAMAN

Thème : Gestion dossier Agent

Objet : saisir et gérer les données individuelles du dossier agent

Qui : responsable hiérarchique, (Catégorie d'acteur Manager)

Où : Unité de organisationnelle (siège ou établissement)

 

Action fonctionnelle

 
 

Contraintes contextuelles

Ergonomie

Confidentialité

Séquence 1 (comment manière, moyens)

Le responsable accède à la page XAECR1

Il saisit un n° de dossier de ses subordonnées dont il a reçu une demande de validation de MàJ

Le responsable accède aux données en lecture. Il valide ou refuse la mise à jour du N-1.

Séquence 2 :

Le responsable accède à la page XAECR1

Il saisit un n° de dossier d'un agent n'appartenant pas à son UO

Le responsable ne peut pas accéder à ce dossier.

...

 
 

Ces scénarios vont servir de base pour la dérivation des permissions et la définition des tâches et du profil de travail. Il est essentiel que chaque séquence soit explicitement décrite. Chaque scénario est décrit sous la forme structuré d'un tableau et peut être illustré d'un diagramme quand cela est nécessaire comme dans le cas d'un workflow de mise à jour.

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émentaires6(*).

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

 
 
 
 
 
 
 
 

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

Pour l'expert dossier administratif site, nous obtenons une synthèse des actions fonctionnelles :

ï Embauche et nomination (y compris affectation hiérarchique) : UG hiérarchique, grade, données individuelles...

ï Affectation budgétaire : UG budgétaire

ï SC1GAPRH : Mise à jour des données individuelles et changement d'affectations sur le site

ï Mutation de l'agent (entre sites AP-HP)

ï Cessation de fonction et retraite

ï Variante, temps de travail

ï ...

ï Gestion des absences

ï Consultation des mises à dispositions

ï Requêtes et états en lien avec ce rôle

Pour chacune de ces actions fonctionnelles, il nous faut identifier les pages et les données accédées par ces pages

Tableau 12 : Exemple de mise en oeuvre d'un tableau des permissions par 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

SC1GAPRH 

Expert RH

* identification Agent

* Famille

* Coordonnées

* Documents

* Véhicules

* Mensurations

* Médical

* Handicap

* Règles
identifiant

* liens familiaux

* Codif. Adresse

* Codif. Document

* Codif.véhicule

* Table mensuration

* Codif. Médicale

* Codif. Handicap

* toutes

Données individuelle

Ecriture

Autorisé sur population

...

 
 
 
 
 
 
 

5.3.3 Identification des contraintes de permissions

Nous entrons dans le coeur du sujet. Car c'est une des parties les plus difficiles du processus d'ingénierie des rôles. La première étape est de définir quel types de contraintes peut être formalisées. Deux des types les plus répandues dans l'industrie sont la séparation des droits et les cardinalités. D'autres types de contraintes peuvent exister comme nous l'avons vue dans la Figure 26 : Taxonomie des contraintes contextuelles d'après (Saidani et Nurcan 2007), comme des contraintes d'horaires, d'affectations ou de séquences de tâches. Nous ne modéliserons que les contraintes implémentées dans le dispositif R-BAC mis en place. C'est-à-dire que dans notre SIRH HRA suite 7 sont implémentés des contraintes d'accès aux données et d'accès aux processus pour ne garder que les plus élémentaires et ne pas alourdir notre propos.

Figure 36 : sous-processus de définition des contraintes

Les contraintes sont identifiées avec les experts du domaine, en particulier avec l'encadrement qui définit les règles d'accès aux informations, c'est-à-dire les données plus les pages permettant l'accès à ces données et le type d'accès (consultation, mise à jour ou mise à jour avec validation du N+1). Ces personnes sont (ou devraient) être capable d'indiquer les règles de confidentialités d'accès aux données par rapport à l'organisation de l'entreprise et plus précisément la structure hiérarchique des unités organisationnelles.

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

La contrainte de permission identifiée est l'habilitation sur les structures. Elle définit :

ï Le périmètre des dossiers qui peuvent être consultés,

ï Le périmètre des demandes transmises via le self-service et qui doivent être validées

Pour un rôle donné, l'utilisateur est habilité :

ï Soit sur un ou plusieurs codes établissements (cas des gestionnaires), sans distinction PM et PNM en standard.

ï Soit sur une ou plusieurs unités organisationnelles (cas des responsables/valideurs dans le self-service) :

o UG pour le PNM (standard),

o Service/UF/UC pour le PM (standard),

o Pôle ou pôle PM ou pôle PNM (écart),

ï Sur une unité organisationnelle dans le cas des gestionnaires populations particulières :

o UG particulière au sein de chacun des établissements.

Scénario GRHHEGP01 :

Un gestionnaire RH d'HEGP est habilité sur :

Un rôle « expert dossier administratif » pour le code établissement « HEGP » Saisie d'une embauche pour un agent d'HEGP PM et PNM...

Un rôle « responsable données individuelles » pour le code établissement « HEGP » Validation d'une modification d'adresse transmise par un agent d'HEGP PM et PNM

Un chef de service d'HEGP est habilité sur un rôle « responsable absences PM » pour le code Service/UF/UC « XXX » Validation d'une demande de congés transmise par un médecin du service « XXX »

Le CF est habilité sur le rôle « Contrôleur financier » Validation d'un arrêté transmis par le gestionnaire RH.

Un membre de la TG est habilité sur le rôle « Trésorerie générale » Blocage d'une paie individuelle.

Figure 37 : Contraintes de permissions sur les structures

5.3.4 Rationalisation des modèles de scénarios

A cette étape, les scénario qui ont été construit à l'étape 1 sont revus et analysé en profondeur avec les experts métiers.

Décomposition : chaque étape de chaque scénario est revue. Si elle ne semble pas assez détaillée pour être implémenté, il faut le réécrire en scénario plus fin.

Généralisation : les scénarios sont relus pour voir si des similarités existent entre eux. Ces scénarios similaires sont réécrits dans des scénarios plus génériques. En général, les scénarios qui peuvent être regroupé sont les cas où les permissions peuvent être instanciées. Il faut donc trouver le bon paramètre d'instanciation.

Figure 38 : sous-processus de rationalisation des scénarios

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 junior7(*) (ou structure de rôle8(*)). Dans le cadre d'HRa Suite 7, la hiérarchie est limitée à un niveau.

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...

Glossaire :

Termes

Définition

source

Accès

Un accès est la réalisation d'une action

XACML (OASIS 2004)

Acteur

Un acteur est un salarié de l'entreprise impliqué dans une étape d'un scénario. L'acteur et l'étape associée sont identifiés dans une séquence de diagramme.

 

Acteur pressenti

L'acteur pressenti correspond à un groupe d'utilisateurs ayant des postes/emplois auxquels nous pouvons attribuer un ou plusieurs rôles.

 

Action

Une action est une opération sur une ressource

XACML

Action fonctionnelle

Une action fonctionnelle permet de réaliser un acte de gestion.

HRAS

Agent

Catégorie d'acteur qui ne concerne que le salarié et peut travailler uniquement sur son propre dossier

HRAS

Contrôle d'accès

Un contrôle d'accès est un accès contrôlé en accord avec une politique d'accès.

XACML

Etape

Une étape est une action ou un évènement dans un scénario

Neumann/Strembeck (Neumann et Strembeck 2002)

Expert RH

Catégorie d'acteur qui concerne le gestionnaire applicatif qui exerce des activités métier SIRH.

HRAS

Instanciation

Il s'agit d'un anglicisme utilisé dans HR Access et qui permet de définir une instance à partir d'un modèle générique, et qui permet de décliner un modèle générique en cas particulier associé à un ou des utilisateurs.

 

Manager

Catégorie d'acteur qui concerne le niveau responsable hiérarchique. Il peut travailler sur les dossiers de ses collaborateurs mais n'exerce pas d'activités métier RH,

HRAS

Objet

Un objet est une entité qui contient ou reçoit une information. Les objets peuvent représenter des supports d'informations (ex : tables, fichiers...). Les objets peuvent aussi être des ressources systèmes comme de l'espace disque, une imprimante...

L'ensemble des objets couvert par R-BAC incluent tous les objets listés dans les permissions assignés à des rôles.

ANSI-R-BAC ( Information Technology Industry Council 2004)

Opération

Une action qu'un utilisateur peut faire sur une application. exécuter, lecture, création,...

Une opération peut aussi être appelée privilège.

ANSI-R-BAC

Permission

Une permission est une autorisation de réaliser une opération sur un ou plusieurs objets R-BAC protégés.

ANSI-R-BAC

Politique

Une politique est un ensemble de règles, un identifiant pour un algorithme combinant des règles et (optionnellement) un ensemble d'obligations. Une politique peut être un composant d'un ensemble politique.

XACML

Profil de travail

Un profil de travail est un document d'étape qui est constitué de toutes les tâches pouvant être accompli par un utilisateur.

Neumann/Strembeck

Règle

Une règle est l'unité élémentaire d'une politique. Une règle à une cible, un effet et une condition.

XACML

Ressource

Une ressource peut être une donnée, un service ou une entité du système.

XACML

Rôle

Un rôle définit un ensemble de caractéristiques (mission du rôle) permettant à un gestionnaire d'utiliser l'application HRa Suite 7 Les rôles déterminent les habilitations (activités), l'accès aux données, aux populations et aux tâches qu'un utilisateur peut effectuer. Un rôle est un objet qui permet d'agréger des autorisations à un utilisateur.

HRAS

Rôle fonctionnel

Un rôle fonctionnel reflète l'essentiel des tâches de gestion qui doivent être accompli. Il est défini comme un ensemble de tâche relative à une fonction

Neumann/Strembeck

Rôle junior

Dans une hiérarchie de rôle, un rôle A est dit « junior » d'un rôle B si le rôle B hérite de toutes les permissions associé au rôle A.

XACML R-BAC

Rôle organisationnel

Un rôle organisationnel correspond à l'organisation hiérarchique dans une entreprise en termes de structure interne.

 

Rôle senior

Dans une hiérarchie de rôle, un rôle A est dit « senior » d'un rôle B si le rôle A hérite de toutes les permissions associé au rôle B.

XACML R-BAC

Rôle session

Un rôle session est un rôle activé par une session utilisateur

ANSI-R-BAC

Scénario

Un scénario est un exemple d'utilisation du système sous forme de séquences d'action et d'évènement.

Les scénarios peuvent être schématisé avec UML.

Neumann/Strembeck

Sujet

Un sujet est un acteur dont les attributs peuvent être référencés par un prédicat.

XACML

Tâche

Une tâche est une collection d'un ou plusieurs scénarios

Neumann/Strembeck

Thème

Un thème est un regroupement cohérent d'actions fonctionnelles

HRAS

Utilisateur

Un utilisateur est déclaré dans l'annuaire d'entreprise. Dans certain cas il peut être étendu à des machines, réseaux ou agents intelligents autonome

ANSI-R-BAC

Index

ACL, 13

authentification, 15, 16, 35, 49, 50, 54

Bottom-Up, 62

CIGREF, 36, 37

confidentialité, 6, 9, 10, 11, 12, 15, 23, 26, 27, 28, 29, 30, 34, 35, 36, 38, 39, 42, 48, 49, 70

contraintes, 6, 22, 43, 48, 49, 54, 56, 57, 58, 59, 60, 61, 66, 70, 71, 77, 80, 82, 83

Contraintes contextuelles, 74; contraintes, 59

différenciation, 10

disponibilité, 35, 39

droits d'accès, 25, 29, 31, 35, 36, 47, 65

EBIOS, 40

enjeux économiques, 18

ergonomie, 6, 7, 9, 14, 15, 32, 34, 35, 36, 43, 44, 46, 47, 49, 66, 78

Ergonomie, 31, 42, 47, 74

exigences juridiques, 35

Exigences juridiques, 10

gestion des accès, 9, 15, 16, 23, 34

gestion des identités, 12, 15, 16, 57

habilitations, 7, 11, 12, 27, 28, 29, 41, 75, 86

histoire de la sécurité, 12

HR Access, 23

HRa Suite 7, 28, 29, 31, 86

HR-Access, 20, 21, 22, 23, 34

I-BAC, 13, 49, 50

ingénierie des exigences, 66, 67, 68

Ingénierie des rôles, 66

intégrité, 18, 35, 39

Intentionnalité, 44

ISO, 40, 42, 43

ISO 13335, 40

les profils populations: profils, 24

Modèle Conceptuel des Données, 22

modèles de buts, 67

Or-BAC, 14

permissions, 12, 13, 14, 48, 49, 50, 51, 52, 53, 54, 55, 58, 59, 60, 65, 66, 68, 69, 70, 71, 72, 75, 76, 77, 78, 79, 80, 81, 82, 83, 86, 87

politique de sécurité, 12, 23, 39, 55

Profil actions, 25

Profil applications, 24

Profil informations, 24

profil navigation, 26, 27

Profil populations, 26

Profil requêtes, 25

profils, 23, 24, 25, 27, 28, 29, 66, 70, 72, 80, 81

protection des données, 38, 39

R-BAC, 14, 49

risques, 20, 36, 37, 39, 47, 53

rôles, 6, 7, 9, 16, 18, 19, 20, 27, 28, 29, 30, 31, 32, 34, 35, 44, 47, 48, 49, 50, 51, 52, 53, 54, 55, 57, 58, 60, 61, 62, 63, 65, 66, 67, 68, 69, 70, 71, 72, 73, 75, 77, 78, 81, 82, 83, 85, 86

Rule-BAC, 14

scénarios, 8, 65, 66, 67, 68, 69, 70, 72, 73, 75, 76, 79, 80, 81, 87

sécurité des systèmes d'information, 15, 39

T-BAC, 14

théorie de l'activité, 47, 48

Top-Down, 62

traçabilité, 35, 72, 73

types de risques, 12

utilisateurs, 6, 9, 10, 12, 14, 15, 23, 27, 28, 29, 30, 32, 34, 35, 37, 42, 43, 47, 49, 51, 53, 55, 62, 63, 65, 67, 70

V-BAC, 14, 23

Table des illustrations

Figure 1 : Les buts des utilisateurs sont différents lorsqu'ils accèdent au S.I. 9

Figure 2 : à chaque groupe son application 10

Figure 3 : Les buts d'ergonomie de l'espace de travail 17

Figure 4 : Carte des buts de la confidentialité avec R-BAC pour un SIRH 18

Figure 5 : d'après M.Mersiol (LAAS-CNRS) Club SEE Systèmes Informatiques de Confiance Journée « Facteurs Humains » 19/04/2001 19

Figure 6 : Architecture technique client/serveur de SIGAGIP/CS 21

Figure 7 : le modèle conceptuel des données pour la gestion du personnel avec HR-Access 22

Figure 8 : synthèse des profils d'accès 24

Figure 9 : schéma de définition du profil information 25

Figure 10 : définition du profil Population 26

Figure 11 : Pré requis du paramétrage technique des rôles 31

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

Figure 13 : écran type du salarié 34

Figure 14 : écran type du manager 34

Figure 15 : écran type Expert RH 35

Figure 16 : la déontologie des usages (source CIGREF 2006) 37

Figure 17 : La démarche EBIOS globale 42

Figure 18 : Cycle de conception ISO 13407 44

Figure 19 : vue globale des critères d'ergonomie de Bastien/Scapin 47

Figure 20 : modèle d'Engestrom d'analyse de l'activité et des relations médiatrices 49

Figure 21 : Transformation et interprétation du modèle 49

Figure 22 : les relations dans R-BAC 52

Figure 23 : les permissions s'appliquent sur des opérations et des objets 52

Figure 24 : Association utilisateur rôle et privilèges rôles 53

Figure 25 : Modèle conceptuel des données pour un R-BAC étendu 56

Figure 26 : Taxonomie des contraintes contextuelles d'après (Saidani et Nurcan 2007) 57

Figure 27 : Les permissions R-BAC avec des contraintes contextuelles 59

Figure 28 : collecte des accès nécessaires à l'utilisateur 63

Figure 29 : les quatre vues sur les scénarios (Rolland, et al. 1998) 67

Figure 30 : Macro-processus de l'ingénierie des rôles 69

Figure 31 : composition d'un profil de travail 70

Figure 32 : interrelation des modèles et des documents utilisés et produits dans le processus d'ingénierie des rôles 71

Figure 33 : sous-processus de formalisation du scénario 72

Figure 34 : sous-processus de recherche des permissions 75

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

Figure 36 : sous-processus de définition des contraintes 78

Figure 37 : Contraintes de permissions sur les structures 79

Figure 38 : sous-processus de rationalisation des scénarios 80

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

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

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

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

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

Tableau 1 : matrice de contrôle d'accès 13

Tableau 2 : répartition des rôles MOA/MOE 27

Tableau 3 : Exemple de matrice des profils/acteurs 27

Tableau 4 : Risques juridiques et réponses déontologiques (CIGREF 2006) 38

Tableau 5 : intégration des méthodes ISO/TR 16982 dans le cycle de développement 44

Tableau 6 : Description formelle de R-BAC de Ferraiolo et Kuhn 51

Tableau 7 : Définition du modèle brut de R-BAC 52

Tableau 8 : Propriété des authorisation du rôle 52

Tableau 9 : Propriété des autorisations d'accès aux objets 53

Tableau 10 : Propriétés des contraintes contextuelles 60

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

Tableau 12 : Exemple de mise en oeuvre d'un tableau des permissions par scénario 77

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

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

Bibliographie

Information Technology Industry Council. American National Standard for Information Technology - Role-Based Access Control,. ANSI INCITS 359-2004, 2004.

Antón, A.I. «Goal-Based Requirements Analysis.» Proc. of the 2nd IEEE International Conference on Requirements Engineering (ICRE'96), 1996: 136-144.

Barathon, Didier. «L'ASP cherche de nouveaux profils de revendeurs.» http://www.01net.com/. 05 février 2007. http://www.01net.com/article/340559.html (accès le Mars 02, 2008).

Beaudouin-Lafon, Michel. ««Ceci n'est pas un ordinateur Perspectives sur l'interaction Homme-Machine», Numéro spécial «informatiques - enjeux, tendances, évoiutions».» Technique et Science informatique TS119(1-2-3), 2000: 69-74.

Bratman, Michael. Intention, Plans, and Practical Reason. Cambridge, MA: Harvard University Press, 1987.

Caprioli, Eric. «TRAÇABILITE ET DROIT DE LA PREUVE ELECTRONIQUE.» http://www.caprioli-avocats.com . Mai 2001. http://www.caprioli-avocats.com/pages/publications/edocs/tracabilite/edocs_tracabilite_dtpreuve.htm (accès le 03 03, 2008).

CIGREF. «Déontologie des usages des Systèmes d'Information - CIGREF - CEA-CED.» CIGREF. 7 Aout 2006. http://cigref.typepad.fr/cigref_publications/2006/08/index.html#entry-12065552 (accès le Mars 04, 2008).

--. «Tableau de bord Sécurité : Indicateurs clés de la sécurité système d'information.» CIGREF. 10 Octobre 2007. http://cigref.typepad.fr/cigref_publications/2007/10/index.html#entry-39835740 (accès le Mars 03, 2008).

CNIL. « Dispositifs d'alerte professionnelle : à quelles conditions sont-ils conformes à la loi informatique et libertés ?» CNIL. 15 Novembre 2005. http://www.cnil.fr/index.php?id=1890 (accès le Mars 06, 2008).

--. « La loi "informatique et libertés" 78-17 modifié.» CNIL. 30 Novembre 2007. http://www.cnil.fr/index.php?id=1163 (accès le Mars 03, 2008).

CNIL Commission Nationale Informatique et Liberté. GUIDE PRATIQUE POUR LES EMPLOYEURS. Paris: CNIL, 2005.

Cockburn, Alistair. «Structuring Use Cases with Goals.» Journal of Object-Oriented Programming, Vol. 10, 1997: 56-62.

Cuppens, Frédéric, et Alexandre Miège. «Modelling Contexts in the Or-BAC Model.» 19th Annual Computer Security Applications Conference (ACSAC '03). 2003.

Cuppens, Nora. Le modèle Or-Bac. Equipe SERES-ENST-Bretagne, 2004.

Davidson, Donald. «Essays on Actions and Events.» Intending, 1980: 83-102.

Debaes, Nicolas, Pierre Pezziardi, et Bruno Vincent. Gestion des identités : une politique pour le Système d'information. Paris: Octo Technology, 2007.

Encarta® 2008. «Microsoft® Encarta® 2008. (c) 1993-2007 Microsoft Corporation.» Microsoft® Encarta® 2008. . DVD-Rom. Édité par Microsoft Corporation. 2007.

Engeström, Y., R. Miettinen, et R. Punamäki. «Activity theory and individual and social transformation.» Perspectives on activity theory, 1999: 19-38.

Ferraiolo, David, Richard Kuhn, et Ramaswamy Chandramouli. Role-based access Control. Boston: Artech House, 2003.

Gallager, Michael P., Alan C. O'Connor, et Brian Kropp. The economic Impact of Role-Based Access Control. NIST / RTI, 2002.

Gotel, O., et A. Finkelstein. An analysis of the requirements traceability problem. Proc. of the IEEE International Conference on Requirement Engineering (ICRE), 1994.

He, Qingfeng. A Structured Role engineering for Privacy-Aware RBAC Systems. Raleigh: Department of Computer Science North Carolina State University, 2007.

HUGOT, Olivier. «Liberté surveillée pour l'utilisation à des fins privées de l'informatique de l'entreprise.» IT-Expert n°71, 2008: 48-50.

ISO. Information technology - Code of practice for information security Management. ISO, 2000.

--. Information technology - Security techniques - Guidelines for the management of IT security. ISO, 2001.

--. ISO/TR 16982:2002 : Ergonomie de l'interaction homme-système -- Méthodes d'utilisabilité pour la conception centrée sur l'opérateur humain. Genève: ISO, 2002.

Kaindl, H. «A Design Process Based on a Model Combining Scenarios with Goals and Functions.» IEEE Transactions on Systems, Man, and Cybernetics, Vol. 30, 2000: 537-551.

Kaindl, H. «An Integration of Scenarios with their Purpose in Task Modeling.» Proc. of the 1995 Symposium on Designing Interactive System, 1995: 227-235.

Kavakli, E. «Goal-Oriented Requirements Engineering: A Unifying Framework.» Requirement Engineering Journal Vol6, 2002: 237-251.

Lampson, B. «Protection.» 5th Princeton Symposium on Information Sciences and Systems. Princeton, 1971. 437-443.

Lentzner, Rémy. SQL 3 - Avec Oracle, MySQL, Microsoft SQL Server et Access. Paris: DUNOD, 2004.

M.A. Harrison, W.L. Ruzzo, and J.D. Ullman. «Protection in Operating Systems.» Communication of the ACM. 1976. 19(8):461--471.

Microsoft. «Gestion des identités et des accès.» Microsoft Technet. 11 Mai 2004. http://www.microsoft.com/france/technet/securite/topics/identitymanagement/idmanage/P1Fund_1.mspx (accès le Mars 06, 2008).

Moran, Thomas, et John Carroll. Design rationale, Concepts, techniques and Use. Mahwah, New Jersey: Lawrence Erlbaum Associates, Publishers, 1996.

Neumann, Gustav, et Mark Strembeck. «A Scenario-driven Role Engineering Process for Functional RBAC Roles.» Proc. of the 7th ACM Symposium on Access Control Models and Technologies (SACMAT'02), 2002: 33-42.

Nogier, jean-françois, et Rodolphe Helderlé. «L'ergonomie informatique est source de productivité.» Entreprise & Carrières n°760, 2006.

OASIS. XACML Profile for Role Based Access Control (RBAC). Committee Specification 01, 2004.

pacbase.free.fr. «pacbase.free.fr.» http://pacbase.free.fr/. 03 Mars 2003-2008. http://pacbase.free.fr/ (accès le Mars 03, 2008).

Rolland, C., et al. «A proposal for a scenario classification framework.» Requirements Engineering Journal, Vol. 3, 1998: 23-47.

Rolland, Colette, C. Souveyet, et Camille Ben Achour. «Guiding goal modeling using scenarios.» IEEE Transactions on Software Engineering, Vol. 24 , 1998: 1055-1071.

Roshan, Thomas. «TMAC: A primitive for Applying RBAC in collaborative environment.» 2nd ACM, Workshop on RBAC. FairFax, Virginia,USA: ACM, 1997. 13-19.

Saidani, Oumeima, et Selmin Nurcan. Prise en compte de l'Utilisateur dans l'Ingénierie des Processus d'entreprise. Paris: Université Paris 1 - Panthéon - Sorbonne, 2007.

Sandhu, R.S., E.J. Coyne, H.L. Feinstein, et C.E. Youman. «Role-based access control models.» IEEE Computer, 29, 1996.

Scapin, Dominic, et Christian Bastien. Ergonomic Criteria for the Evaluation of Human-Computer interfaces. France: INRIA, 1993.

Schackow, Stefan. Professional ASP.NET 2.0 Security,Membership,and Role Management . Indianapolis: Wiley Publishing, Inc., 2006.

SGDN / DCSSI / SDO / BCS. «EBIOS - Expression des Besoins et Identification des Objectifs de Sécurité.» http://www.ssi.gouv.fr/fr/confiance/ebiospresentation.html. 5 février 2004. http://www.ssi.gouv.fr/fr/confiance/documents/methodes/ebiosv2-section1-introduction-2004-02-05.pdf (accès le Mars 5, 2008).

STREMBECK, Mark, et Gustav NEUMANN. «An Integrated Approach to Engineer and Enforce Context Constraints in RBAC Environments.» ACM Transactions on Information and System Security, Aout 2004: 392-427.

Suchman, Lucy. Plans and situated actions: the problem of human/machine communication. Cambridge MA: Cambridge University Press, 1987.

Van Lamsweerde, A. «Goal-Oriented Requirements Engineering: A Guided Tour.» Proc. of the 5th International Symposium on Requirements Engineering (RE'01), 2001: 249-262.

Vernadat, F. Enterprise modeling and integration : principles and applications. Londres: Chapman & Hall, 1996.

* 1 C'est-à-dire avec un formalisme logique mathématique et théorique.

* 2 C'est le progiciel sur lequel j'interviens.

* 3 GIP : Gestion Informatique de la Paie.

* 4 Encore sur la Suite 7, ce principe est encore utilisé pour tous les traitements se faisant sur le serveur.

* 5 En psychologie acte ou conduite qui manifestent la faculté de se déterminer librement à agir ou à ne pas agir en vertu de motifs conscients et délibérés (Encarta® 2008 2007)

* 6 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.

* 7Selon la nomenclature XACML R-BAC

* 8Selon la nomenclature HRa Suite 7






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Il y a des temps ou l'on doit dispenser son mépris qu'avec économie à cause du grand nombre de nécessiteux"   Chateaubriand