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

Le principe de proportionnalité

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

Le principe de pertinence des données

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

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

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

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

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

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

Le principe de transparence

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

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

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

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

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

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

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

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

Nouvelles approches méthodologiques à trouver

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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