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

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

MASTER MANAGEMENT DES ORGANISATIONS - M2

SPÉCIALITÉ PROFESSIONNELLE : MANAGEMENT DES SYSTÈMES

D'INFORMATION ET DE CONNAISSANCE

1 Introduction

Glossaire :

Index

Table des illustrations

Bibliographie

MÉMOIRE

Exigences juridiques des accès au S.I.

Organisation des modèles applicatifs ou Applications Sectorielles

L'atelier Profils HRD Security

Ses caractéristiques

Rôles et utilisateurs

Rôles et axes de confidentialité

Les activités

Protection juridique de l'information :

Protection technologique de l'information

Intentionnalité

Les contraintes endogènes

Les contraintes exogènes

Les contraintes d'autorisation

Les contraintes d'assignation

L'attribut de contexte

La fonction de contexte

Une condition de contexte

Définition des rôles et de leurs dépendances.

· Définition des organisations

Le modèle de scénario :

Le catalogue des permissions :

Le catalogue des contraintes :

Les définitions de tâches :

Les profils de travail :

Le modèle concret R-BAC :

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

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

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

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

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

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

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

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

Le profil applications

Le profil informations

Le profil requêtes

Le profil actions

Le profil populations

Le profil navigation

Les populations autorisées

Les Données accessibles

Les rôles et les activités

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

L'environnement juridique et réglementaire

La protection des données en France

Mettre en place une charte et communiquer

La démarche de sécurité

Les objets et domaines de sécurité

Les démarches normalisées

La Théorie de l'activité

Le principe de finalité

Le principe de proportionnalité

Le principe de pertinence des données

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

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

Le principe de transparence

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

Présentation

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

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

Normes et Principes de gestion des habilitations au sein des entreprises

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

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)

1 Introduction

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.

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 :

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

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

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.

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.

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.

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)

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.

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.

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

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.

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.

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

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 ordre^1(*) 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.

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 ?

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.

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 ?

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.

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.

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

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

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 :

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.

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.

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.

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 ans^2(*).

GIP^3(*) 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.

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 COBOL^4(*).

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.

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.

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

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.

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.

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é :

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.

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 :

Le profil requêtes

Le profil actions

Le profil populations

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.

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

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

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

Acteur	Profils						Gestionnaires principaux
Acteur	Information	Population	Application	Action	Requète	Navigation	Gestionnaires principaux
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 ?

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.

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

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.

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

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

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

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.

ï 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 :

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 :

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

ï 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,

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 :

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

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

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

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.

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

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.

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

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éterminent la liste des domaines et des services auxquels ils sont associés,

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

ï 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,

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

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 :

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

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

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

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 :

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.

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.

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

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.

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.

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 :

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

ï 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 :

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.

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

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.

ï 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

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

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

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.

Ce n'est pas seulement l'interface qui compte, mais l'interaction et les intentions de l'utilisateur:

- l'adéquation entre le système et le contexte dans lequel il est utilisé (Beaudouin-Lafon 2000)

Intentionnalité

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 ;

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 volitions^5(*), 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) ;

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

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)

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.

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

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)

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

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

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.

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

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.

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.

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.

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.

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

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

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

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

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

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

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

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.

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.

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

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

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.

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.

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

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.

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

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.

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

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)

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.

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

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.

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 ?

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.

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 é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"

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

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

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

· Les identifiants qu'il utilisera pour se connecter à ses applications cibles

· La liste des règles permettant d'associer un profil (organisation, rôle) à une application ou un système.

· La liste des exceptions permettant en complément d'associer un utilisateur à une application ou un système.

· La liste exhaustive des droits d'accès en appliquant la politique définie : pour chaque règle les utilisateurs sélectionnés ainsi que les identifiants applicatifs associés.

Cette approche empirique donne une base de travail, mais manque de formalisme pour être pérenne. Elle comporte aussi de nombreux éléments induits. Il n'est pas dit comment sont extrait les besoins

Avec ce que nous avons étudié et vu en page 45 ce n'est pas seulement l'interface qui compte, mais l'interaction et les intentions de l'utilisateur:

· l'adéquation entre le système et le contexte dans lequel il est utilisé (Beaudouin-Lafon 2000)

Les concepts sous-jacent de l'intentionnalité sont maintenant utilisées dans la mis au point de systèmes multi-agents (SMA). Elle peut nous aider à établir le modèle comportemental de l'utilisateur (buts, plans d'action, rôles...). Quoi de mieux que l'utilisation de scénario pour mettre en lumière les plans d'action et les rôles en discerner les buts ? Voila pourquoi une approche basée sur l'utilisation de scénario nous a paru pertinente.

Il existe plusieurs approches pour aborder l'ingénierie des rôles. La première concerne l'approche basée sur les scénarios. Cette approche (Neumann et Strembeck 2002) est axée sur l'élaboration de scénarios pour l'ingénierie des rôles fonctionnels dans R-BAC. Dans cette approche, chaque tâche est décrite en utilisant un ensemble de scénarios. Ensuite chaque scénario est décomposé en une série d'étapes. Parce que chaque étape est associée à une opération d'accès particulier, chaque scénario est lié à un ensemble de permissions. Cette approche nous a semblé pertinente par rapport à notre problématique. Nous allons donc étudier plus en détail cette nouvelle approche d'ingénierie des rôles utilisant les scénarios. Le concept de scénario a une importance fondamentale pour la présente démarche. En raison de la forte importance des facteurs humains dans l'ingénierie des rôles, les scénarios sont un bon moyen pour diriger notre processus. Nous utilisons des scénarios pour trouver les autorisations nécessaires (relatif à R-BAC) et définir les tâches (relatif à l'ergonomie).

Dans un processus d'ingénierie des rôles basé sur l'utilisation des scénarios, les scénarios d'un système d'information sont utilisées pour définir les tâches et en « dériver » les permissions. En général, un scénario décrit une séquence d'actions et d'événements. Par exemple : « enregistrer un nouveau salarié dans un système d'information des ressources humaines ». Ainsi, chaque scénario se déroule en plusieurs étapes, et un sujet effectuant un scénario doit posséder toutes les autorisations qui sont nécessaires pour mener à bien les différentes étapes de ce scénario. A son tour, une tâche est composée d'un ou plusieurs scénarios, et des tâches peuvent être combinées pour former des profils de travail.

Un profil de travail regroupe un ensemble de tâches qu'un certain type de sujet est autorisé à exercer. Dans un environnement R.H. différents profils de travail pour les gestionnaires Paie, les secrétaires et les managers sont nécessaires, par exemple. Dans le processus d'ingénierie des rôles, les profils de travail sont ensuite exploités conjointement avec le catalogue des permissions et le catalogue des contraintes pour définir un modèle R-BAC concret. Toutefois, l'approche axée sur le scénario présenté dans (Neumann et Strembeck 2002) ne fournit qu'une orientation générale pour la définition des sous-processus (exogène). Notre but sera de préciser et de faire appliquer les contraintes dans un contexte R-BAC environnement nous a conduit à la définition du processus d'extension proposés dans la présente section.

L'ingénierie des exigences axée sur les Buts utilise les liens Buts/Objectifs afin de susciter, de préciser, d'analyser et de valider les exigences.

Nous aborderons la combinaison d'approches scénario/buts. Des aperçus plus complet de l'ingénierie des exigences basé sur les buts peuvent être trouvés dans (Van Lamsweerde 2001) et (Kavakli 2002).

Les buts et les scénarios ont des caractéristiques complémentaires (Van Lamsweerde 2001). Les buts sont généralement abstraits et déclaratif. Ce sont les objectifs de haut niveau de l'entreprise, de l'organisation ou du système. Les scénarios sont concrets, ce sont : soient des récits, soient des descriptions de procédures. Ils décrivent des situations réelles en utilisant des exemples et des illustrations. D'où, en combinant les avantages des buts et ceux des scénarios nous pouvons trouver un moyen efficace d'obtenir et de valider les exigences de nos contraintes d'accès. Les buts sont réalisés au moyen de scénarios et raffiné en exigences. De même réciproquement, les scénarios peuvent être utilisés pour aider à découvrir les buts.

Cette méthode d'analyse des exigences basées sur les buts utilise la hiérarchie des buts entre eux pour organiser des exigences issues des scénarios, des obstacles aux buts, des contraintes contextuelles (Antón 1996). D'autres organisent hiérarchiquement des scénarios selon les objectifs et leurs contraintes dans leurs « uses cases » (Cockburn 1997). Colette Rolland propose une approche bidirectionnelle avec un couplage scénario- objectif entre découverte des buts et de création de scénario (Rolland, Souveyet et Ben Achour 1998). H. Kaindl a proposé un processus systématique de conception basée sur un modèle combinant les scénarios avec des objectifs et des fonctions (Kaindl, A Design Process Based on a Model Combining Scenarios with Goals and Functions 2000). Dans ce modèle combiné, le «but» sert de lien entre les fonctions et les objectifs: un système de fonctions globales qui ont certains objectifs et ces buts correspondent avec les (sous-) buts des utilisateurs. Le But a également été intégré aux scénarios pour modéliser des tâches (Kaindl 1995).

L'ingénierie des exigences différencie les exigences fonctionnelles et les exigences non-fonctionnelles (relative à la qualité). Les exigences fonctionnelles définissent les buts du système, c'est-à-dire ce pour quoi le système est construit (l'utilisation intentionnelle du système). Les exigences non fonctionnelles définissent des demandes comme la maintenabilité, interopérabilité ou la performance. Pour capturer, illustrer et organiser les exigences fonctionnelles trois catégories générales de modèles d'exigences ont été retenues :

Les modèles de buts : les buts décrivent les exigences sur un niveau abstrait. Les buts sont, par exemple, bien adaptés pour capturer les exigences au niveau des processus de gestions. Ainsi, ils peuvent être utilisés pour communiquer avec la direction.

Les modèles de scénarios : les scénarios décrivent l'usage du système sous forme d'actions et de séquences d'évènements. Les scénarios sont bien adaptés pour modéliser un système à partir de la perspective utilisateur. Ils facilitent la communication avec les utilisateurs finaux.

Les modèles de solutions : ces modèles capturent la solution ou les solutions visées en détail et comblent l'écart entre les modèles d'exigences et l'architecture du système. Par conséquent ils facilitent la communication entre l'équipe en charge des exigences et l'équipe en charge de l'implémentation. UML est le standard « de facto » des modèles orientés solutions. Ses différents types de diagrammes peuvent être utilisés dans toutes les phases du développement.

(Rolland, et al. 1998) proposent un framework pour synthétiser toute l'abondante littérature au sujet des scénarios. Ce cadre de référence propose de considérer les scénarios selon quatre points de vues différents, chaque vue permettant de capter un aspect pertinent des scénarios.

La vue selon la forme porte sur le mode d'expression d'un scénario. Est-ce que les scénarios sont décrits de façon formalisé ou informelle, de façon statique, animées ou interactif.

La vue selon le contenu concerne le genre de connaissance qui est exprimé dans un scénario. Les scénarios peuvent, par exemple, se concentrer sur la description de fonctionnalités d'un système, ou ils peuvent décrire une vue plus large dans lequel la fonctionnalité est intégrée dans un plus vaste processus de gestion avec divers intervenants et des ressources liés à celui-ci.

La vue selon les buts est utilisée pour saisir le rôle que joue un scénario dans le processus d'ingénierie des exigences. Il s'agit de décrire les fonctionnalités d'un système, d'explorer des alternatives de conception ou d'expliquer les inconvénients ou l'inefficacité d'un système. Voilà des exemples de rôles qui peuvent être assignés à un scénario.

La vue selon le cycle de vie suggère de considérer les scénarios comme des objets existant et évoluant dans le temps à travers l'exécution d'opérations au cours du processus d'ingénierie des exigences. La création, la suppression ou le raffinement sont des exemples d'utilisation de ce type d'opérations. La question de la persistance contre l'éphémère est également un élément abordé dans ce point de vue.

Dans l'approche basée sur les scénarios, chaque action et évènement dans un scénario peut être vu comme une étape. Cette étape peut être associée avec une opération d'accès particulière. Ainsi un scénario peut être une source intéressante pour la dérivation des permissions qui sont appliquées dans un ordre particulier pour atteindre un but prédéfini.

Chaque définition de tâche (par exemple procéder à la saisie d'un jour d'absence) correspond à un ou plusieurs scénarios. Ces tâches sont de nouveau combinées pour former un profil de travail. Le profil de travail comprend toutes les tâches d'un certain type d'employé peut accomplir. De ce fait chaque scénario peut être relié à un ensemble de permissions. Il est donc possible de tirer des permissions pour un profil de travail directement des tâches ou d'un scénario.

L'ingénierie des rôles dirigés par les scénarios est composée de sept activités majeures qui possèdent leur propre sous-processus.

Dans la Figure 30 nous voyons que les activités 1 à 4 forment un cycle qui est répété jusqu'à ce que le modèle de scénario soit complet. C'est le pré requis pour les activités 5 à 7. Tout le processus (les activités 1 à 7) est conçu pour être exécuté de façon itérative et incrémentale. Chaque itération résulte d'une nouvelle étape de l'évolution des modèles.

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

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.

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.

Figure 32 : interrelation des modèles et des documents utilisés et produits dans le processus d'ingénierie des 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.

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 :

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.

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.

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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 demandes transmises via le self-service et qui doivent être validées

ï 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) :

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

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.

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.

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.

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.

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

Code	Libellé	Technologie					Activité
		Noeud d'arbre web	Processus guidé	DMS	HR config tool	Rapport

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.

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.

Cette modélisation sous forme de graphe permet de mieux visualiser les impacts de modifications de permissions d'un rôle junior^7(*) (ou structure de rôle^8(*)). 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

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.

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.

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 :

Ces familles n'ont aucun impact applicatif, elles serviront d'appui au travail de modélisation des rôles.

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.

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 :

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.

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

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

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

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

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

Table des illustrations

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.

Debaes, Nicolas, Pierre Pezziardi, et Bruno Vincent. Gestion des identités : une politique pour le Système d'information. Paris: Octo Technology, 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.

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

* ⁵ 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)

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

Libellé

Dossier de gestion applicable à l'activité

Technologie

Espace professionnel RH

Processus guidé

Requête & batch

Gestion documentaire