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

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

RÉDIGÉ ET SOUTENU PAR :

CHRISTOPHE THOMAS

PROMOTION JB 2007

DIRECTEUR DE MÉMOIRE :

INDIQUER ICI LE NOM DU DIRECTEUR DE MÉMOIRE

DATE DE LA SOUTENANCE :

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

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.

	Gestion temps et activités	Planning	Paie
Arthur	Lecture/écriture	Lecture
Bernard	Lecture/écriture	Lecture/écriture	Lecture
Charles	Lecture	Lecture/écriture	Lecture/écriture

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

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

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

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

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

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.

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

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

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

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

Rôle de la MOA

Rôle de la MOEI

Définition du besoin

Création des profils-type

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

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

Création des contextes de navigation

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

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

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

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

MÉMOIRE