SERGAM-Xpert vous présente son pôle d'expertise

IAM fonctionnel

Principes, fonctionnement, utilisations...

Préambule

Cet article est destiné aux personnes souhaitant parfaire leur culture générale et il vise à vulgariser l’IAM pour les non spécialistes fonctionnels ou techniques du domaine.

 

Il s’adresse aux DSI, RSSI, chefs de projets informatiques et chefs de projets fonctionnels. Mais aussi à tous ceux qui veulent comprendre le sujet sans forcément vouloir en devenir expert.

 

Volontairement, ce document est élaboré sur un schéma didactique et ne prétend en aucun cas être la critique sous entendue d’un quelconque système d’information. Il est établi simplement pour éveiller la curiosité sur des problématiques souvent considérées comme logiques – ou évidemment mises en œuvre – dans une entreprise lambda mais qui, dans une bonne majorité des cas, ne le sont pas encore.

 

Cet article ne dévoile pas non plus comment les activités et les actions sont effectuées mais seulement de quoi elles sont constituées. SERGAM-Xpert vous présente ici un petit échantillon de son expertise dans le domaine complexe et totalement transverse de l'IAM.

 

Pour connaître les savoir-faire de l'entreprise, veuillez vous rapprocher de SERGAM-Xpert qui répondra à vos questions.

 

Les termes spécifiques employés sont simples mais s’inscrivent, bien entendu, dans le vocabulaire de l’informatique de gestion.

 

Création : SERGAM-Xpert (2014)

Sources : SERGAM-Xpert

 

Définition et historique simplifiés

IAM est l’acronyme anglais de Identity and Access Management ou en français, gestion des identités et des accès et/ou habilitations.

 

Cette activité de gestion s’inscrit dans la sécurité informatique et ses actions menées pour préserver et garantir la sécurité des systèmes d’information d’une entreprise, quelques soient ses domaines d’activité. Elle peut sembler récente mais dans le monde bancaire, l’IAM a fait son apparition quelques semaines après l’affaire « Worldcome » en 1999.

 

En France, c’est depuis 2006 et les incidents survenus à La Société Générale où l’un de ses traders (J. KERVIEL, et l’affaire qui en est apparue : « Jérôme KERVIEL » ou « KERVIEL ») lui a fait perdre de très importants montants de transactions financières. C’est à ce moment-là que les problématiques liées à l’IAM ont véritablement intéressé les esprits. Cet établissement s’était retrouvé confronté à une véritable faille dans la sécurité de son système d’information. Une faille qui a mis en lumière un risque opérationnel présent.

 

Principes de l'IAM

L’IAM permet de répondre précisément à deux questions fondamentales qui permettent de prévenir les incidents liés aux risques opérationnels :

1. Qui est qui (dans l’entreprise) ?

Cette question s’inscrit directement dans la gestion des Identités.

2. Qui fait quoi et pour combien de temps (dans l’entreprise) ?

Celle-ci s’inscrit en complément de la gestion des identités, dans celle des accès et des habilitations.

 

L’IAM est mis en place et en œuvre pour minimiser, voire contrer les risques opérationnels liés à de possibles habilitations qui pourraient ne pas correspondre précisément aux activités d’un collaborateur. De plus, la gestion des identités et des habilitations œuvre pour que les données d’identités des collaborateurs et les données « métiers » (tels que les profils métiers, les droits et habilitations, les applicatifs) soient centralisées afin que tous les outils qui doivent les utiliser, manipulent des informations justes et parfaites (à un moment donné puisque des interventions de modifications et consolidations peuvent intervenir). Et par conséquent, réduire de manière significative les saisies multiples.

 

Les solutions et processus IAM se fondent sur cinq éléments « phares » et prépondérants qui sont :

• Les processus de création et de modification des données d’identité des collaborateurs,
• Les données d’identité des collaborateurs internes ou prestataires (réalisées en amont),
• Les Acteurs qui interviennent dans les traitements de gestion des demandes d’habilitations,
• Les informations des profils métiers,
• Les processus de gestion des demandes d’habilitations.

 

Utilisations

Comme on l’a vu plus haut, l’IAM sert à contrôler et limiter au maximum les risques opérationnels pouvant provenir des collaborateurs ayant accès au parc applicatif du Système d’Information.

 

La gestion des identités et des accès ou des habilitations concerne essentiellement les accès physiques ou logiques aux locaux et surtout au parc applicatif en général et d’un point de vue plus détaillé, aux fonctionnalités, opérations et données embarquées dans les applicatifs. Et ce, durant tout le cycle de vie d’un collaborateur – interne ou prestataire – dans l’entreprise.

 

Par cycle de vie, il faut comprendre : depuis le moment où le collaborateur entre dans les locaux jusqu’à son départ définitif. Qu’il s’agisse d’un simple visiteur, d’un collaborateur interne, d’un sous-traitant ou de tout autre prestataire devant avoir accès aux locaux et principalement au système d’information.

 

Il faudra cependant faire une distinction claire et précise entre les accès aux locaux qui pourront être gérés par les services des Moyens Généraux et les accès et habilitations aux applicatifs du SI.

 

En effet, afin de ne pas mélanger toutes les actions et pour distinguer les réels risques opérationnels, l’IAM gérera de manière très précise et fidèle les accès et habilitations aux applicatifs. En cas de départ définitif de l’entreprise, le badge d’accès aux locaux sera d’une manière générale plus facilement désactivé que les droits dans les applicatifs. Nous allons voir pourquoi un peu plus loin.

 

Ce que l'IAM permet de faire et ce qu'il ne permet pas

Lorsqu’on propose de mettre en place une gestion des habilitations dans un SI qui n’a – jusque là – rien prévu à cet effet, les réactions peuvent être très négatives. Et ce, selon les localisations où cette évolution du SI devra se faire.

 

En effet, en France, que l’on travaille dans le Service Public ou dans le Privé, la peur du « flicage » est quasiment omniprésente. Il faut alors user de beaucoup d’argumentations pour faire comprendre que l’IAM ne s’inscrit pas dans une démarche pour « fliquer » les collaborateurs dans leurs activités. Dans les pays anglo-saxons, les réticences sont moins importantes ou difficiles à clarifier.

 

C’est la raison pour laquelle, avant d’entrer dans le vif du sujet, il est important d’apporter certaines précisions sur ce que l’IAM permet de faire et au contraire, ce qu’il ne permet pas de faire.

 

Comme nous le verrons un peu plus tard, l’IAM impose une transversalité totale de son mode opératoire, sur l’entreprise. Avec cela, l’IAM apportera de nombreux retours sur investissements. Parmi ceux-ci, on peut énumérer :

• La simplification et l’exactitude des données utilisées :
  • L’IAM permet de réutiliser des données d’identités saisies en amont dans différents référentiels. Cette manœuvre permet de réduire au maximum les risques d’erreurs imputées aux saisies multiples.
  • Les modifications, si elles doivent être apportées, le sont dans les référentiels « maîtres » utilisés par la ou les solutions IAM. Cela assure leur exactitude et seules les personnes autorisées les mettent à jour.
  • La visibilité des populations devant avoir accès aux outils et aux données et qui sont présentes dans les référentiels, est précise et juste.
  • On sait précisément quelles sont les différentes populations de l’entreprise : internes, externes, visiteurs, etc. ainsi que leur cycle de vie dans l’entreprise (présence, absence, congés, départ définitif).
• La centralisation et l’homogénéisation des données :
  • On aura une visibilité complète sur la population ayant – et devant avoir – accès aux applicatifs du SI, avec leurs droits et habilitations.
  • L’utilisation de référentiels d’identités et d’habilitations centralisés regroupant les demandes et les autorisations appartenant aux collaborateurs.
  • Des procédures automatiques permettent de contrôler les informations et de les réconcilier (mises à jour selon des règles de gestion prédéfinies) entre les différents référentiels afin de toujours assurer la justesse des données.
  • Les revues des comptes sont simplifiés : elles proviennent directement – et possiblement de manière automatique – des référentiels qui sont eux-mêmes alimentés de données précises et justes.
  • Selon des règles de gestion à paramétrer, il est possible de faire en sorte que les demandes d’habilitations soient créées en fonction des dates effectives de présence des collaborateurs.
• L’historique des informations est assuré :
  • Toutes les données consultées, modifiées, ajoutées ou supprimées sont enregistrées et historisées dans des bases de données dédiées.
  • Les pistes d’audit sont assurées : on sait qui est intervenu ou a consulté une information, à quelle date et pourquoi.

Par contre, il faut être conscient que l’IAM ne peut réaliser certaines tâches qui ne sont pas de son ressort, ni de ses capacités. Par exemple et surtout, parmi les plus importantes :

• L’IAM n’a pas vocation, ni la possibilité de vérifier si un collaborateur travaille bien ou si ses actions sont parfaitement en adéquation avec son métier.
  • Une solution IAM – quelle qu’elle soit – n’est pas mise en œuvre pour « fliquer » les collaborateurs de l’entreprise.
• L’IAM se trouve en dernier maillon de la chaine de mise à jour des données du SI, tant pour les identités que pour les habilitations. Les données qu’il utilise ne doivent pas « remonter » dans le SIRH.
  • C’est le SIRH (outil dédié à la gestion des ressources humaines intégré dans un système d’information spécifique) qui fait autorité en termes de données et d’informations à utiliser (pour les collaborateurs internes).
  • L’IAM ne peut intervenir pour faire évoluer la carrière d’un collaborateur (notion de GPEC) mais au contraire, sera en capacité de faire évoluer les habilitations du collaborateur tout au long de son cycle de vie dans l’entreprise (actions et règles de gestion à définir précisément et à paramétrer selon la solution choisie).

 

Pour illustrer l’éclaircissement des malentendus au sujet du « flicage », il faut comprendre que l’IAM se comporte comme une entreprise qui a pour charge de mettre en place la signalisation sur les routes. Cette entreprise intervient pour baliser la route et permettre aux automobilistes de circuler sur des tronçons routiers qui sont mis à leur disposition. Dès lors que la route est ouverte à la circulation, la signalisation permet d’utiliser certaines options de déplacements ou au contraire, de restreindre certains accès. Ce n’est pas cette société qui se chargera de s’assurer que l’automobiliste aura un comportement correct sur la route. Ou qu’il ne roule pas à trop faible allure ou au contraire, trop vite par rapport à la vitesse limite signalée.

 

Les demandes d’habilitations créées – pour un utilisateur – avec une solution IAM permettent de faire peu de choses près, la même chose : lui permettre d’accéder à certains outils (réseau routier, dans l’illustration) pour ensuite faire en sorte qu’il puisse travailler avec les fonctionnalités et données qui sont mises à sa disposition (routes, accès autorisés, etc.) et ce, en respectant la signalisation qui lui est présentée (accès à certaines opérations et données correspondant).

 

Vérifier si un collaborateur effectue correctement les missions pour lesquelles il est présent sont du ressort de son supérieur hiérarchique ou de son responsable de mission. En aucun cas, c’est celui de l’IAM. Une solution IAM ne pourrait être juge et partie.

 

Comprendre le risque opérationnel

Depuis l’affaire « KERVIEL » qui a secoué le monde des banques et celui de la sécurité informatique à plus ou moins grande échelle, une nouvelle forme de risque est apparue : le risque opérationnel « humain ».

La notion de « risque opérationnel » est apparue avec les accords de Bâle 2. Ils incluaient déjà la possibilité de défaillances humaines ou techniques dans les pertes probables que pouvaient subir les établissements financiers.

 

Il se trouve que le risque opérationnel, au-delà des actions qui peuvent être réalisées par l’établissement financier dans son mode de fonctionnement quotidien, concerne aussi pour beaucoup, l’humain et les machines. Or, il est beaucoup plus facile de se protéger « techniquement » du risque opérationnel que du risque « humain ».

 

En effet, dès lors qu’un outil informatique possède un catalogue très fourni de fonctionnalités, il suffit d’en « verrouiller » certaines considérées comme présentant un risque potentiel afin qu’elles ne soient pas utilisables. Bien entendu, cette vision est extrêmement simplifiée et schématique car ici, le propos n’est pas de comprendre comment on bloque techniquement une fonctionnalité dans un outil informatique.

 

Or, dans la plupart des entreprises, le risque provient de l’humain et de ses capacités d’adaptation et aussi de sa possible curiosité. Car, il semble être inscrit dans la nature humaine, le besoin d’aller au-delà de ses propres droits et de tenter, parfois, des manœuvres ou des actions qui ne lui sont normalement pas autorisées ou accessibles.

 

Aussi, il va s’agir, non seulement de s’assurer qu’une fonctionnalité n’est pas accessible dans l’outil mais aussi et surtout, de faire qu’un utilisateur spécifique (parce que son métier l’impose ou l’interdit) n’ait pas accès à cet outil ou la fonctionnalité en particulier.

 

Ces actions sont gérées dans la gestion des accès et des droits ou habilitations.

 

Comprendre l'articulation des accès et des habilitations

Il faut aussi comprendre que pour parvenir à travailler avec un outil informatique métier spécifique, il faut non seulement avoir l’accès à cet outil mais aussi avoir des droits d’habilitations qui permettent d’utiliser telle ou telle fonctionnalité ou opération.

 

La plupart des systèmes d’informations et des applicatifs métiers qui y sont connectés fonctionnent de la manière suivante. Les applicatifs sont eux-mêmes connectés à des référentiels dans lesquels les droits d’accès et les droits d’habilitations sont inscrits pour les utilisateurs. Selon des paramètres techniques spécifiques aux outils et aux applicatifs, il sera possible de préciser plus ou moins finement les droits d’accès et d’habilitations que les utilisateurs auront pour effectuer leurs actions métiers.

 

Bien entendu, à chaque droit et habilitation correspondra une identité appartenant à l’entreprise et qui sera dûment référencée.

 

Pour la mise en œuvre, on parle alors de « positionnement des droits » dans les référentiels, pour une identité.

 

 

Articulation entre la gestion des identités, la gestion des accès et des droits (présents dans le Profil Métier, en allant du général au détaillé). Aux informations d’identité correspondent des habilitations :

 

L'IAM et les contrôles

Il ne sert à rien de mettre en place un projet IAM (car comme nous le verrons ci après, il s’inscrit dans les projets transverses) s’il n’est pas prévu d’effectuer des contrôles. Ce sont les contrôles positionnés sur les Identités et sur les accès et habilitations qui permettront de s’assurer que les risques opérationnels sont réduits au maximum ou au contraire, qui mettront en lumière les points qui devront être renforcés ou consolidés, voire corrigés.

 

Les contrôles consistent à prévoir une « piste d’audit » dans le suivi des actions qui permettent de gérer les identités et les habilitations. Cela sous-entend qu’il doit être possible de tracer toutes les informations, depuis leur création et leur enregistrement en bases de données jusqu’à leur suspension ou leur suppression des mêmes bases.

 

Cette piste d’audit doit également montrer de manière claire et précise quand et par qui les données ont été manipulées, tout au long de leur cycle de vie.

 

Les pistes d’audit doivent donc être constituées aussi bien pour la gestion des identités (des collaborateurs internes ou externes devant accéder aux locaux et au SI) que bien entendu pour la gestion des accès et des habilitations.

 

Un projet transverse

Un projet IAM est forcément transverse.

En effet, parce qu’il va concerner tous les collaborateurs de l’entreprise – internes ou externes – il est nécessaire que toutes les Directions et organisations de l’entreprises soient parties prenantes au projet.

En termes de gestion des Identités, tous les collaborateurs doivent être connus et reconnus.

 

Pour ce qui est de la gestion des accès et des habilitations, là aussi, il est important d’avoir une vue d’ensemble du parc applicatif présent dans chaque structure, organisation et métier de l’entreprise.

 

Il ne serait être cohérent d’envisager des processus IAM qui demeureraient utilisés en silo. La raison principale venant du fait qu’un collaborateur est potentiellement mobilisable dans n’importe quelle entité de la structure. Également parce que le système de paie gère l’ensemble des collaborateurs internes de l’entreprise. Il en est de même des possibles transformations et restructurations.

 

S’il s’avérait qu’une entreprise devait avoir plusieurs systèmes de paie non centralisés, par besoin de connaître l’effectif global, il faudrait atteindre la base de données rassemblant l’ensemble des collaborateurs. Et dans ce cas là, il faudrait aussi penser aux possibles déplacements et mobilités des collaborateurs qui, au cours de leur cycle de vie dans l’entreprise, peuvent changer d’organisation, de structure, de rattachement et de métier. Par conséquent, les informations liées à l’identité seront impactées (rattachement, lien hiérarchique, date de départ d’une entité, date d’arrivée dans la nouvelle entité, poste ou fonction, voire le type de contrat, etc.) tout comme le seront les droits d’accès et d’habilitations.

 

De plus, pour des raisons liées au suivi des pistes d’audit (il faut savoir qui a demandé, pour qui, qui a validé ou refusé et quand), il est nécessaire d’avoir la vision d’ensemble de la structure.

 

La gestion des identités

En termes de gestion des Identités, il est assez facile de répondre à la première question : « Qui est qui ? » pour ce qui est des collaborateurs internes.

 

En effet, qu’il s’agisse du secteur public comme du privé, la plupart des collaborateurs sont enregistrés dans un SIRH qui assure la gestion de leur paie mensuelle selon les évolutions de leur cycle de vie dans l’entreprise. Avec l’ensemble des données qu’il contient, il est possible de savoir ce qui permet de dire quand une personne est entrée dans l’entreprise, quand elle en est absente et quand elle devrait la quitter (même s’il s’agit d’un contrat à durée indéterminée car une date fictive positionnée loin dans le futur peut être inscrite). De plus, si le système est bien organisé, chaque collaborateur doit disposer d’un identifiant unique (généralement appelé « matricule ») qui permet de le distinguer facilement et aisément d’une possible homonymie.

 

Il est donc possible d’avoir des éléments définissant les identités des collaborateurs « internes » (qui sont présents dans l’effectif et dont la paie mensuelle est calculée à partir d’un outil RH).

 

Pour les collaborateurs externes (prestataires, visiteurs, sous-traitants, et toute autre personne ne devant pas figurer dans le SIRH), la réponse à la question « Qui est qui ? » peut être plus compliquée à fournir. Si la structure ne possède pas de service Achats pour commander et régler les factures des sous-traitants et autres prestataires, il faut pouvoir retrouver les données d’identité et de mission (date de début, date de fin, rattachement, etc.). En cas d’impossibilité, il faut recenser cette population qui représente un potentiel risque opérationnel.

 

Qu’il s’agisse de la gestion des identités via un outil SIRH, d’une base de données, d’un ERP ou de toute autre solution plus ou moins complète et perfectionnée, il est important que des Acteurs dédiés interviennent pour renseigner les données des collaborateurs. Qu’ils soient internes ou prestataires, il faut avoir rapidement un état des lieux sur les effectifs présents, sur les absentéismes, les budgets, l’organisation et la structure de fonctionnement de l’entreprise. Quelque soit sa taille, les informations qu’elle contient sont importantes et concourent aux études, analyses et décisions qui seront prises pour son évolution future.

 

La gestion des accès et des habilitations

Il est souvent constaté que la gestion des identités présente dans l’entreprise prévaut sur celle des accès et des habilitations. En effet, la gestion des identités est relativement simple à mettre en place et en œuvre. Les solutions RH et SIRH présentes sur le marché fonctionnent toutes autour d’un socle et d’un moteur équivalent, tant pour la gestion des identités que celle de la carrière. Viennent ensuite se rapporter des moteurs annexes capables de calculer précisément (par exemple) les absences et leurs impacts sur la paie.

 

D’autant plus que les entreprises publiques et privées ont un réglementaire de gestion administrative différent les unes des autres. Il existe donc la possibilité de réaliser une forte capitalisation de la connaissance entre les projets. Les rubriques de paie et leurs calculs sont très similaires entre les structures appartenant au même secteur.

 

La gestion des habilitations présente quant à elle, une capitalisation beaucoup plus réduite. En effet, bien que les moteurs de gestion des droits et habilitations fonctionnent sur le même modèle et que les structures mettant en œuvre les projets IAM appartiennent souvent aux mêmes secteurs de métiers (banque, assurance, gestion de flux financiers, gestion de données sensibles, etc.), chaque entreprise possède ses propres spécificités. Car en tout état de cause, même si elles appartiennent au même secteur d’activité, les finesses d’actions dans les métiers peuvent être très différentes.

 

La gestion des accès et des habilitations doit donc pouvoir répondre à la question « Qui fait quoi et jusqu’à quand ? ». Cela sous-entend que le « QUI » existe et est correctement renseigné.

 

C’est principalement le « QUOI » qui demeure le plus complexe à obtenir. Il s’agit bien entendu du métier et de ses subtilités qu’exercera le collaborateur – au sein de l’entreprise – pour le poste qui lui a été confié. Car il faut bien distinguer la nature fonctionnelle d’un métier et sa définition technique dans les applicatifs et les référentiels qui se chargeront d’en autoriser le ou les accès.

 

Pour illustrer ces propos, prenons l’exemple simple d’une « Assistante de Direction Marketing » de Madame « Xxxx ZZZZZ » ayant le matricule « 123456 ».

 

Au niveau de la gestion des Identités, dans le SIRH (ou son équivalent), il sera précisé dans l’information « Poste » ou « Fonction » de la collaboratrice « Xxxx ZZZZZ », matricule « 123456 », qu’elle occupe le poste ou la fonction de « Assistante de Direction Marketing ».

 

Qu’il s’agisse d’un poste / fonction dans la grande distribution, une banque d’investissements ou d’une industrie du textile, le libellé est identique. C’est donc bien l’appellation fonctionnelle qui est identique.

D’un point de vue technique, il faut que cette personne puisse accéder à l’ensemble des outils, applicatifs, périmètres de visibilité du SI qui corresponde exactement à sa fonction. Et si par exemple, l’organisation de l’entreprise présente plusieurs branches avec chacune une Direction très spécifique, il est important que l’assistante de Direction de l’une des Directions n’ait pas les mêmes accès et habilitations qu’une autre. Cela signifie, par conséquent, qu’il doit être possible de distinguer de manière spécifique les métiers des différentes assistantes.

 

Pour cela, on utilisera le principe d’affectation de « rôle » ou de « profil métier » qui regroupera l’ensemble des droits qu’un collaborateur devra avoir pour exercer pleinement ses activités. Dans le cadre de la gestion des accès et des habilitations, c’est cette information de « rôle » ou de « profil métier » qui sera enregistré avec les données d’identités du collaborateur. On donnera à ce profil métier un nom explicite qui correspondra au métier du collaborateur. La notion de durée d’utilisation des accès et des habilitations seront soit définies par les informations présentes dans les données d’identité, soit définies de manière plus précise dans l’affectation du « rôle » ou du « profil métier ». De là, il sera parfaitement possible de répondre à la question « Qui fait quoi et pour combien de temps ? ».

 

Le plus gros travail consistera à comprendre comment doivent être traduits techniquement les droits fonctionnels. Par exemple, si cette assistante de Direction doit avoir accès à la Messagerie de l’entreprise, à certains groupes de messagerie puis à des outils de bureautique, voire même pouvoir accéder à des univers de données ou d’espaces de travail dans l’infocentre, il faut être en mesure de traduire techniquement ces besoins fonctionnels en attributs techniques. Ce sont ces attributs techniques qui figureront dans le « rôle » ou le « profil métier » qui correspondront à « Assistante de Direction Marketing » dans les référentiels cibles. Car, lorsqu’il faudra que cette personne soit opérationnelle à sa fonction, ce sont les attributs techniques qui seront positionnés dans les référentiels de droits, en fonction des demandes d’habilitations qui auront été demandées et validées pour la collaboratrice en question (voir chapitre suivant : « Vers une simplification des processus de gestion », page 10). Comprendre la correspondance entre les attributs techniques et la fonction est une des activités du Role Manager IAM et des Responsables des Habilitations.

 

Le Role Management ou la gestion des profils, des droits et des habilitations

 

Il ne peut y avoir de gestion des habilitations sans une gestion précise des profils (métiers) et des droits qui les composent.

 

Comme on l'a vu plus tôt, c'est l'activité du collaborateur qui va dicter ses activités quotidiennes ou spécifiques dans l'entreprise. Ce sont elles qui doivent montrer quels outils informatiques, quels référentiels, bases de données, fonctions et données seront utilisés par le collaborateur. 

 

Or, pour accéder à tout cela et pouvoir les utiliser, il faut constituer des collections de droits d'accès et de droits d'utilisations qui seront regroupés en un seul et même ensemble que l'on nomme généralement "profil métier". Ces informations qui constituent les "profils métiers" sont communément appelées "habilitations". L'action qui consiste à les gérer est la "gestion des habilitations" (ou "Role Management")que l'on retrouve dans la traduction française du sigle "IAM".

 

Les termes regroupés dans les profils métiers sont toujours techniques car ils correspondent très exactement à ce qui est présent et à ce qui sera mis en place ou paramétré (intervention que l'on nomme "positionnement des droits") dans les référentiels qui regroupent les habilitations.

 

Une des grandes problématiques que l'on rencontre dans l'IAM est de parvenir à comprendre ces termes techniques et leur apporter - ou faire correspondre - une définition technique. Car il peut arriver que les profils métiers affectés aux collaborateurs n'aient pas de sens techniques ou fonctionnels compréhensibles ou encore, qu'ils ne correspondent pas au nom du poste du collaborateur dans son métier.

 

Les grandes missions du Role Management consistent à aider les Responsables des Habilitations des entités d'une entreprises, dans la constitution (par constitution, il faut comprendre l'action qui consiste à déterminer quels droits vont devoir être présents dans les profils métiers) des profils métiers, comprendre les règles de gestion qui peuvent présenter des spécificités complexes (ségrégations des droits, associations obligatoires, associations toxiques ou associations interdites, etc.) et construire tous les outils qui permettront de bien comprendre la nature des droits, des habilitations et des impacts des affectations.

 

En fonction du modèle de gestion des données d'habilitations qu'on voudra employer (voir le chapitre suivant : "Les deux principaux modèles de gestion des données IAM"), les fonctions du Role Manager consisteront à constituer et à construire les profils métiers en respectant les règles de gestion dictées par le modèle choisi (RBAC ou ORBAC).

 

Le Role Management intervient aussi dans la construction de toute la documentation permettant de comprendre fonctionnellement et techniquement ce que sont les droits d'accès, les droits d'habilitations afin que l'ensemble des Acteurs impliqués dans les processus de gestion des habilitations comprenne parfaitement les informations qu'ils manipulent.

 

SERGAM-Xpert s'est construit une véritable expertise dans le Role Management.

 

Les deux principaux modèles de données IAM

L’IAM gère les demandes d’habilitations des collaborateurs devant travailler dans les applicatifs métiers ou techniques du SI. Il ne s’attache que très « exceptionnellement » à gérer des demandes qui concernent la fourniture de matériels (téléphone portable, matériel informatique et divers) car ces demandes-ci ne concernent pas des applications du SI.

Les solutions IAM du marché incluent pour la plupart des modules de collection (voire parfois de gestion) des profils métiers des collaborateurs, selon leurs métiers ou l’organisation.

Il existe deux modèles de gestion des habilitations, en fonction des contrôles que l’on veut effectuer :

• Le modèle RBAC
• Le modèle ORBAC

 

Le modèle RBAC (Role Based on Access Control)

Pour ce modèle, les contrôles des habilitations portent sur le profil métier du collaborateur. RBAC est l’acronyme anglais de « Role Based on Access Control » autrement dit, les contrôles sont effectués sur les habilitations du collaborateur.

 

L’organisation des profils métiers doit être faite selon le métier du collaborateur, quel que soit son rattachement organisationnel ou hiérarchique. Deux collaborateurs peuvent avoir le même profil métier alors qu’ils n’appartiennent pas à la même structure dans l’entreprise mais qu’ils aient le même intitulé de poste ou de fonction (exemple : une « Secrétaire de Direction » appartenant au service du Marketing pourra avoir les même habilitations dans son profil métier que la « Secrétaire de Direction » du service Informatique).

 

Avantages et inconvénients du modèle RBAC :

Les avantages sont liés à la facilité de gestion des profils métiers possédant des intitulés identiques. Il sera alors possible de ne créer qu’un seul profil métier par intitulé. Si un ou plusieurs collaborateurs devaient avoir des droits spécifiques ou discriminants pour distinguer des droits spécifiques ne devant s’inscrire dans le profil métier (parce que spécifiques), ceux-ci seraient gérés de manière unitaire par collaborateur.

 

L’inconvénient vient du fait que si deux profils métiers qui appartiennent à deux entités différentes de la structure (exemple, secrétaire de Direction Comptable et secrétaire de la Direction Informatique), possèdent des droits d’accès aux données similaires, il est très difficile, voire quasiment impossible de distinguer les populations et leurs rattachements effectifs. Seuls les droits supplémentaires permettent alors de faire la distinction entre les collaborateurs.

 

Le modèle ORBAC (Organization Role Based on Access Control)

Dans le modèle ORBAC, les profils métiers sont construits de manière à ce que chaque collaborateur, en fonction de son rattachement hiérarchique ou opérationnel dans l’organisation, possède des droits distincts de ceux qui possèdent un intitulé de poste ou de fonction proche, mais qui appartiennent à d’autres structures dans l’entreprise.

 

Pour le modèle ORBAC (acronyme anglais de « Organization Role Based on Access Control »), les contrôles sont effectués selon deux axes complémentaires : les droits et habilitations du profil métier ET l’organisation dans l’entreprise. Ainsi, deux collaborateurs ayant le même intitulé de poste mais appartenant à deux structures différentes, devront posséder des droits et habilitations différentes.

 

Avantages et inconvénients du modèle ORBAC :

Les avantages du modèle ORBAC reposent sur la précision des contrôles qui pourront être réalisés sur les profils métiers affectés aux collaborateurs. Il sera ainsi possible de savoir avec précision si tous les collaborateurs possédant le profil métier appartiennent effectivement à la même structure ; s’il est normal que tel collaborateur ait accès à un périmètre fonctionnel ou technique spécifié par les droits présents dans son profil métier ou pourquoi, un collaborateur appartenant à la structure n’a pas accès à un périmètre ou à des fonctionnalités particulières.

 

Pour ce qui est de l’affectation des droits demandés dans une demande d’habilitations, il sera aisément possible de s’assurer qu’une demande est cohérente par rapport à la structure de rattachement du collaborateur. Et pour distinguer de manière très spécifique les droits d’un collaborateur par rapport à un autre appartenant à la même structure de rattachement, les droits supplémentaires gérés unitairement à l’individu seront discriminants.

 

Les inconvénients reposent sur la complexité de la constitution des profils métiers. En effet, il sera nécessaire de construire les profils métiers en connaissant parfaitement bien les ressources, les périmètres fonctionnels et les périmètres de visibilité des données spécifiques à l’entité de rattachement du collaborateur. Également, dans le cas de la multiplication d’intitulés de profils métiers, il sera nécessaire de construire autant de profils métiers qu’il y aura d’intitulés.

 

Bien sûr, pour distinguer les profils métiers ayant peu ou prou le même intitulé dans deux ou davantage de structures de rattachement, il sera possible de précéder les intitulés des profils métiers, de l’acronyme du Service ou de la Direction.

 

Ce qui a été présenté jusqu’ici est une base de connaissance qui permettra à celui ou à celle qui l’aura compris, d’acquérir suffisamment de matière pour comprendre les enjeux d’un projet IAM. Ce que c’est et ce que cela fait.

Maintenant, les pages qui suivent permettent d’aller plus loin dans certains détails. Il ne s’agit pas d’une réelle formation à l’IAM mais d’accéder au vocabulaire spécifique et à bon nombre des modus operandi et règles de gestion qui doivent être pris en compte pour la bonne réalisation d’un projet IAM. Selon les cas et les environnements, tous les sujets ne sont pas traités mais ceux présents donnent une vision relativement complète de ce qui est réalisable de faire et aussi des résultats et des retours sur investissements que produira un projet IAM correctement mis en œuvre.

Pour ceux qui veulent aller plus loin...

Voici, pour ceux qui veulent approfondir leurs connaissances de l’IAM, quelques sujets classés en chapitres qui sont traités dans les projets devant résoudre des problématiques IAM. Ils trouveront aussi les enjeux, les contraintes et les actions à mettre en œuvre pour qu’un projet IAM mis en œuvre soit un succès.

Les descriptions des points présentés ici peuvent correspondre à une vision idéale, tant en termes d’Acteurs impliqués, de processus, de workflows, de règles de gestion ou de gouvernance de sécurité. Elles représentent néanmoins des résultats de capitalisations sur des projets ayant existé et fait leurs preuves en termes d’efficacité. À chacun ensuite d’élargir ou restreindre les périmètres d’intervention en fonction des capacités du projet et de l’entreprise qui le mettra en œuvre.

Et n’oublions pas qu’il est toujours possible de lotir un projet pour garantir sa réalisation complète.

Bonne lecture.

 

Vers une simplification des processus de gestion

Possibilité de mettre en place différents types de workflows IAM

En fonction des processus prévus pour la gestion des Identités et des Habilitations, il est tout à fait envisageable de prévoir plusieurs workflows utiles à la gestion de différents types de demandes.

 

Cependant, par exemple, pour distinguer la gestion des identités des collaborateurs Internes des Prestataires, il n’est pas nécessaire de prévoir des processus ou des workflows différents. Il suffit d’envisager une distinction de type de demande qui peut se faire – par exemple et si le cas est envisageable – automatiquement au moment de la saisie du matricule du Bénéficiaire.

 

Par contre, il peut être judicieux de prévoir un « circuit court » ou « d’urgence » qui serait simplifié en termes de traitements des demandes en impliquant moins d’Acteurs dans le processus. Mais afin de ne pas transformer ce circuit – qui peut être considéré comme un circuit de gestion des exceptions – comme étant celui qui sera toujours utilisé par ceux qui veulent que leur demande soit traitée rapidement, il est primordial de définir des règles de gestions précises et strictes comme par exemple, préciser que seule une certaine catégorie de Demandeurs peut créer des demandes – et pour une catégorie de Bénéficiaires bien définie et circonscrite – via ce workflow. Une autre règle de gestion qui a fait ses preuves est de préciser que seules les demandes concernant une certaine catégorie de population pourront être créées via ce circuit.

 

Car il ne faut pas oublier que les processus et workflows sont faits pour gérer la majorité des demandes d’habilitations et non les demandes exceptionnelles. Aussi, seules les demandes exceptionnelles doivent être gérées de manière exceptionnelle. Les autres demandes (demandes de nouveaux droits, demandes de modification de droits ou demandes de suppression de droits) ne sont pas exceptionnelles et sont la majorité des demandes. Par conséquent, celles-ci doivent obligatoirement passer par le « circuit » normal.

 

Faire la distinction entre les demandes « normales » et les demandes « exceptionnelles » permet de spécifier des Acteurs spécifiques et de gérer les priorités.

 

Également, parce que le « départ définitif » ou le congé de longue durée (LDD) sont des cas de risques opérationnels potentiels, il est judicieux de prévoir un processus ultra rapide permettant de geler très efficacement les droits d’un collaborateur parti définitivement de l’entreprise. Selon les réglementaires de sécurité et les politiques de l’entreprise, il sera ensuite facile, à l’aide d’une procédure automatique de supprimer les droits des référentiels.

 

Les processus de gestion des demandes d’habilitations.

Afin de simplifier la gestion des habilitations, pour un collaborateur entrant, ses évolutions de métier ou bien signaler son départ définitif de l’entreprise, il est nécessaire de mettre en œuvre des processus qui soient clairs, précis et rapides. Pour cela, plusieurs solutions sont envisageables :

• Automatiser intégralement les actions par des routines informatiques,
• Automatiser et gérer humainement les actions de gestion par des processus clairement établis en respectant des règles de gestion précises dans les actions,
• Laisser intégralement l’humain gérer les actions visant à traiter les demandes d’habilitations.

 

Les processus IAM font appel à des enchaînements d’étapes de traitement des demandes impliquant des acteurs techniques (référentiels, routines, workflows, bases de données, connecteurs, etc.) et ou humains permettant de créer, modifier, supprimer et utiliser des données liées à l’identification des collaborateurs d’une organisation, et de gérer les demandes d’habilitations les concernant. Ces processus s’inscrivent dans les démarches de contrôles afin d’assurer les pistes d’audits des habilitations positionnées dans les référentiels de droits, pour chaque collaborateur.

 

De par sa transversalité, le projet IAM concerne toutes les structures (Divisions, Directions, Services, métiers) d’une organisation. Ainsi, les référentiels IAM alimentés des données d’identité et d’habilitations deviennent à leur tour transverses et doivent devenir les références pour tous les autres référentiels et applications utilisant des données transverses.

 

Les solutions IAM peuvent également prendre en charge l’alimentation des référentiels de droits, soit par de l’approvisionnement automatique (utilisation de connecteurs), soit par l’envoi de notifications aux acteurs en charge de l’approvisionnement manuel. La plupart des outils et solutions IAM embarquent des modèles de processus et workflows techniques et/ou humains pouvant être adaptés aux besoins des clients. Ces workflows peuvent mettre à contribution des acteurs humains chargés de gérer les données d’identités et les demandes d’habilitations. Ces acteurs interviennent dans des fonctionnalités sont spécifiées dans les étapes du ou des workflows.

 

Un projet IAM implique que des contrôles soient faits tant au niveau des identités, dans l’organisation (présences, absences, congés, mobilités, évolutions de carrière, départs définitifs) qu’au niveau des habilitations (qui a droit d’accéder à quoi ? qui a créé la demande d’habilitations ? qui l’a validée ? à quelle date la demande a-t-elle été créée ? quand a-t-elle été validée ? qui a positionné les droits ? jusqu’à quand les droits sont-ils positionnés ?). Si aucun contrôle sur les données ou des pistes d’audit ne doivent être effectués alors il n’est pas nécessaire de lancer un projet IAM. Ceci peut constituer une des motivations pour le lancement d’un projet IAM pour l’entreprise.

 

Un projet IAM permet de simplifier et de minimiser les saisies d’informations et de répliquer dans les référentiels de droits de manière uniforme, les données d’un collaborateur liées à ses habilitations. En cas d’anomalies, il sera possible de réconcilier les bases et les référentiels selon des règles de gestions préétablies, soit en modifiant les habilitations, soit en en supprimant (cas des départs), soit en effectuant de nouvelles demandes afin d’ajouter les droits manquants.

 

Acteurs majeurs des processus et workflows IAM et règles de gestion de fonctionnement

Les acteurs devant intervenir dans les workflows de gestion des identités et des habilitations doivent respecter les règles de ségrégation des droits (exemple : une demande d’habilitation créée par un acteur ne peut être validée par lui-même ; l’acteur qui constitue les profils métiers ne peut être le Valideur des demandes d’habilitations ; un administrateur technique ne peut pas créer de demandes d’habilitations, etc.).

 

L’idéal étant de définir une collection d’Acteurs qui traiteront les demandes d’habilitations au fur et à mesure de leur avancement dans les processus. Au besoin, certains Acteurs peuvent être « adaptés » en fonction des processus qui auront été définis. L’important étant de retrouver la cinématique :

 

 

Exemple des différents acteurs intervenant dans la gestion des habilitations (et des identités, dans un processus ou workflow différent) :

Acteur	Description	Fonctionnalités	Règle de gestion (généralement usitée)
Bénéficiaire	Collaborateur pour lequel une demande d’habilitations est créée. Tout collaborateur de l’entreprise est potentiellement un Bénéficiaire	Peut consulter les droits qui lui ont été affectés Peut consulter sa fiche annuaire	Règle de gestion à valider : le Bénéficiaire peut-il créer une demande pour lui-même ?

_________________________________________________________________________________________

Demandeur

Crée la demande d’habilitations

Peut consulter : les droits qui lui sont affectés les droits du collaborateur pour lequel il crée une nouvelle demande mettre à jour la date de départ d’un collaborateur dans le cas des demandes de départ

Dans certains cas (à discuter et à valider en interne dans l’entreprise, pour construire les règles de gestion des processus) le Demandeur peut être tout collaborateur de l’entreprise le Demandeur doit correspondre à un pool de collaborateurs autorisés à créer des demandes

__________________________________________________________________________________________

Valideur

Traite la demande d’habilitations qui lui est adressée.

Il peut : consulter les droits qui sont affectés au Bénéficiaire valider la demande demander des informations complémentaires au Demandeur refuser la demande et justifier le refus annuler la demande déléguer ses actions pour une période donnée consulter les droits de son équipe

Généralement : le Valideur est le Responsable Hiérarchique du Demandeur ou son N+1 (Règle de ségrégation des droits) Le Valideur ne doit pas pouvoir valider une demande qui le concerne

__________________________________________________________________________________________

Contrôleur RH

Acteur facultatif qui ne peut intervenir que pour les collaborateurs internes. Intervient pour s’assurer que le Bénéficiaire est présent dans l’entreprise au moment de la création de la demande d’habilitations

Il peut : consulter les droits qui sont affectés au Bénéficiaire valider la demande demander des informations complémentaires au Demandeur refuser la demande et justifier le refus annuler la demande déléguer ses actions pour une période donnée

(Règle de ségrégation des droits) Le contrôle RH ne doit pas pouvoir valider une demande d’habilitations qui le concerne

__________________________________________________________________________________________

Responsable Applicatif

Acteur en charge de faire la cohérence fonctionnelle entre la demande d’habilitations et le métier ou la fonction du Bénéficiaire. Il ne traite que les demandes correspondant à son périmètre applicatif dont il est responsable fonctionnellement

Il peut : consulter les droits qui sont affectés au Bénéficiaire valider la demande demander des informations complémentaires à l’Acteur précédent refuser la demande et justifier le refus annuler la demande déléguer ses actions pour une période donnée

Le Responsable Applicatif ne traite que les demandes concernant une application appartenant à son parc applicatif. (règle de ségrégation des droits) le Responsable Applicatif ne doit pas pouvoir valider une demande d’habilitations qui le concerne

__________________________________________________________________________________________

Responsable des Habilitations

Acteur facultatif : peut être remplacé par le Responsable Applicatif Il intervient pour s’assurer que les droits demandés sont conformés à ce que l’application peut supporter

Il peut : consulter les droits qui sont affectés au Bénéficiaire valider la demande demander des informations complémentaires à l’Acteur précédent refuser la demande et justifier le refus annuler la demande déléguer ses actions pour une période donnée

Le Responsable des Habilitations crée et constitue les profils métiers correspondant au parc applicatif dont il a la responsabilité. Il ne traite que les demandes concernant une application appartenant à son parc applicatif. (règle de ségrégation des droits) le Responsable des Habilitations ne doit pas pouvoir valider une demande d’habilitations qui le concerne

__________________________________________________________________________________________

Administrateur technique / Provisioning auto

Positionne les droits demandés pour le Bénéficiaire dans le référentiel des accès ou des droits de l’applicatif dont il a la charge

Il peut : valider la demande une fois les actions de positionnement des droits effectuées refuser la demande en justifiant son refus

Une fois les droits positionnés, une notification de réalisation est transmise au Bénéficiaire et au Demandeur

__________________________________________________________________________________________

Structure de supervision des processus et des workflows

Cellule indépendante des Acteurs impliqués dans les workflows et en charge de de superviser les processus IAM et garantir les bons respects des contraintes de Sécurité et IAM

Cette cellule : est le relais entre le RSSI et les Acteurs des workflows pour les formations et les évolutions des processus et workflows peut intervenir aux étapes de validation des Acteurs non techniques est la MOA pour les demandes d’évolutions (exemple, impacts de nouvelles réglementations Sécurité SI) est le support de Niveau 1 aux Acteurs des workfklows peut intervenir pour débloquer des demandes non traitées ou retardées

Les demandes d’habilitations concernant les membres de la cellule doivent respecter les processus normaux. Les demandes d’habilitations pour la cellule de supervision ne peuvent être validées par elle-même

__________________________________________________________________________________________

Processus auto IAM

Des processus automatiques inclus dans la solution choisie doivent être mis en place pour faciliter et fiabiliser certaines tâches.

D’importantes actions doivent être mises en œuvre pour faciliter les échanges, les transmissions de données et les enregistrements. Tels que : toute demande doit être référencée selon son type et doit être numérotée chronologiquement. En outre, elle doit comporter le nom du Demandeur distinguer les demandes de services HelpDesk des demandes d’habilitations envois de notifications aux Acteurs en charge de traiter les demandes d’habilitations les demandes annulées et refusées doivent comporter une justification création automatique des autorisations en fonction des demandes d’habilitations validées

Les demandes d’habilitations doivent être numérotées, référencées et archivées. Elles doivent être transmises directement aux Valideurs définis selon l’organigramme (N+1 ?), et selon le processus ad hoc.   Les demandes destinées au circuit court ou d’urgence doivent lui parvenir uniquement si le Bénéficiaire appartient à un groupe autorisé.   Les notifications ne doivent pas s’apparenter à des spams.   Les autorisations doivent être numérotées, référencées et archivées avec : le Bénéficiaire, le Demandeur, les droits demandés sur les applications.

Les Acteurs devant intervenir dans les workflows de gestion des identités et des habilitations doivent respecter les règles de ségrégation des droits (exemple : une demande d’habilitation créée par un Acteur ne peut être validée par lui-même ; l’Acteur qui constitue les profils métiers ne peut être le « Valideur » des demandes d’habilitations ; un administrateur technique ne peut pas créer de demandes d’habilitations, etc.).

 

L’idéal étant de définir une collection d’Acteurs qui traitera les demandes d’habilitations au fur et à mesure de leur avancement dans les workflows. Au besoin, certains Acteurs peuvent être « adaptés » en fonction des processus qui auront été définis. L’important étant de retrouver la cinématique.

 

De l'implication et de la responsabilisation des Acteurs impliqués dans les processus IAM

Une des grandes difficultés – qui n’est pas insurmontable – consiste à nommer des Acteurs qui interviendront dans les étapes des processus de la gestion des identités (essentiellement pour celles concernant les collaborateurs non internes) et dans celles de la gestion des habilitations, afin de construire et garantir une piste d’audit.

 

Cependant, il faut bien comprendre que pour assurer une piste d’audit cohérente capable de contrôler les données d’identités et surtout celles liées aux droits présents dans les référentiels applicatifs, il est nécessaire que des Acteurs impliqués interviennent dans les étapes des processus.

 

En effet, les changements qu’impliquent ces « nominations » peuvent être importants dès lors que les habitudes de travail sont installées depuis un certain temps. Être un Acteur présent dans un processus ou dans un workflow implique des actions à réaliser à des étapes précises et sur des supports différents de ceux manipulés habituellement lors des activités quotidiennes.

 

Comme il a été vu plus tôt, les règles liées à la ségrégation des droits imposent aussi que tous les Acteurs ne pourront pas effectuer toutes les actions des processus. Ces règles sont primordiales pour la piste d’audit : on doit être en mesure de savoir avec précision, qui a émis une demande d’habilitations pour un Bénéficiaire, qui l’a traitée, qui l’a validée et qui a réalisé les gestes techniques pour positionner les droits. Ce sont là, les actions minimales pour la piste d’audit.

 

D’autres Acteurs peuvent venir compléter la piste d’audit comme par exemple le Responsable Applicatif et le Responsable Habilitations. Ce dernier, s’il n’intervient pas dans les étapes des processus de gestion des habilitations, il devra néanmoins exister pour réaliser le catalogue des profils métiers et la définition des droits qu’ils devront embarquer pour constituer ces profils.

 

Aussi, en respectant la ségrégation des droits, le Valideur ne peut être de Bénéficiaire de la demande d’habilitations émise.

 

Vers une bonne ségrégation des droits et des devoirs

La ségrégation des droits et des devoirs est un des « piliers » de l’IAM visant à réduire au maximum le risque opérationnel. Cette ségrégation consiste à faire en sorte que des Acteurs ou des Bénéficiaires de droits et privilèges ne puissent une seule et même personne afin de ne pas être à la fois « juge » et partie ».

 

La notion de ségrégation des droits concerne deux populations fortement impliquées dans l’entreprise et les processus IAM qui sont à mettre en œuvre.

 

La ségrégation des droits et des devoirs des Acteurs impliqués dans les processus et workflows IAM

Comme il a été vu un peu plus haut, il est impératif que les Acteurs qui interviennent dans la prise en charge des demandes d’habilitations ne puissent avoir tous les droits et effectuent toutes les actions. Il ne pourrait être envisagé qu’un processus IAM répondant aux contraintes de sécurité et qui respecte les lois dictées par la prévention des risques opérationnels, ne comporte qu’un et un seul Acteur.

 

Une règle est simple : on ne peut traiter une demande qui nous concerne directement.

 

En effet, au moment de la création, un Demandeur ne peut valider une demande d’habilitations pour lui même. De même, par exemple, un peu plus loin dans le workflow, une demande concernant un Bénéficiaire ne peut être validée par lui-même s’il est le Responsable Applicatif fonctionnel pour lequel la demande a été créée.

 

Il faut nécessairement une tierce personne pour traiter (qui soit capable de juger, valider ou invalider) la demande qui est créée pour un Bénéficiaire. Et ce, quelle que soit l’étape du workflow.

 

Il en sera de même pour les Responsable des Habilitations en charge de constituer ou créer les profils métiers. Il faudra une tierce personne capable de confirmer ou infirmer qu’un droit peut effectivement être affecté (positionné) à un Responsable des habilitations, afin que la piste d’audit soit correctement constituée.

 

Et comme nous allons le voir, cette ségrégation des droits et devoirs concerne aussi les profils métiers.

 

La ségrégation des droits des Bénéficiaires des rôles et des profils métiers qui leur sont affectés

Certaines réglementations métiers imposent qu’un seul et même individu ne puisse cumuler des actions dans son propre métier. On trouve un bon nombre de ces contraintes au niveau des métiers devant manipuler des flux financiers, des données et informations sensibles ou devant accéder à certaines zones de bâtiments.

 

Aussi, les Responsables des Habilitations des directions métiers doivent constituer des profils métiers qui intègrent ces règles de gestion afin de bien répartir les actions dans les fonctions.

 

On retrouve cette notion de ségrégation des droits dans l’expression anglaise « Segregation Of Duties » qui consiste effectivement à s’assurer qu’un accès restreint n’est pas ouvert ou autorisé parce qu’un autre droit positionné dans le même profil métier (ou rôle) en donne la capacité. Il en sera exactement de même du bon respect des règles de gestion liées à certaines fonctionnalités dans un applicatif spécifique.

 

Cela suppose que les règles de gestion doivent être comprises, recensées et régulièrement mises à jour afin de s’assurer que les modifications apportées au niveau des réglementaires liés à la profession soient respectées.

Des bibliothèques de règles de gestion pourront être constituées et périodiquement, des revues de comptes permettront de vérifier qu’elles sont bien mises en œuvre dans les référentiels d’accès et de droits.

 

Quelques bonnes pratiques IAM

Plusieurs bonnes pratiques et règles de gestion liées à l’IAM sont intéressantes à étudier. Nous avons par exemple :

 

Bonne pratique

Règles de fonctionnement et de gestion

Acteur

Type de collaborateur de l’entreprise (il sera préférable de désigner des Acteurs parmi les collaborateurs internes de l’entreprise afin de respecter les règles d’accès aux données sensibles) chargé de gérer les demandes d’habilitations, tout au long du processus ou du workflow de gestion des demandes d’habilitations ou de gestion des identités.   Les Acteurs possèdent des droits, des devoirs et ont à leur disposition des fonctionnalités dans la solution technique IAM mise en place.

____________________________________________________________________________________________

Autorisation

L’autorisation est créée au moment où l’administrateur technique ou le système de provisionnement automatique des droits a positionné des habilitations dans le ou les référentiels d’habilitations.   L’autorisation est nominative et comporte la date de création de l’habilitation et sa date de fin.   L’autorisation est un faire-valoir ou une preuve comme quoi les habilitations demandées sont bien positionnées pour un Bénéficiaire et pour une durée spécifique. En cas de perte de données, elle permettra de reconstruire les habilitations à l’identique de ce qui avait été demandé.   La cinématique de création d’une autorisation est la suivante : Demande  -à   habilitations à positionner   -à   Autorisation

_____________________________________________________________________________________________

Devoir (des Acteurs)

Les Acteurs des processus et workflows doivent respecter des règles de fonctionnement et d’usage qui sont autant de « devoirs » afin de respecter les bonnes pratiques IAM.   Ainsi, de manière générale, l’Acteur : ne peut intervenir à une autre étape que celle dont il a la charge et la responsabilité. est responsable des actions qu’il effectue à son étape. est garant des bonnes pratiques IAM et ne peut encourager le détournement des processus et workflows IAM définis. ne peut déléguer ses actions et son rôle d’Acteur à un tiers sans en avoir eu préalablement l’autorisation. Toutes les règles de fonctionnement qui régissent les Devoirs des Acteurs doivent être consignées, soit dans les Spécifications Fonctionnelles, soit dans les consignes dictées par le RSSI ou le Responsable Sécurité de l’entreprise.

_____________________________________________________________________________________________

Droit d’accès

Ensemble des caractéristiques techniques permettant d’accéder à certains référentiels techniques ou de droits (ex. AD)

_____________________________________________________________________________________________

Droit (des Acteurs)

Ensemble des actions que l’Acteur est en mesure d’effectuer pour traiter et prendre en charge une demande d’habilitations (ou pour la gestion des identités) dans les processus et workflows dédiés.

_____________________________________________________________________________________________

Fonctionnalité

Traitements prévus pour la gestion des demandes d’habilitations et d’identités et qui sont liées à la disposition de chaque Acteur des processus, en fonction de sa nature ou de son rôle.

______________________________________________________________________________________________

Habilitation

Caractéristiques techniques détaillant les éléments nécessaires au positionnement de paramètres permettant au collaborateur de travailler dans une application (ou outil) technique ou métier.   Une habilitation doit avoir une date de début et une date de fin. Arrivée à échéance, une habilitation doit être supprimée. Toutefois, il est possible de proroger une habilitation qui a fait l’objet d’une demande spécifique dûment établie et validée.   A la fin du processus de création de l’habilitation qui sera positionnée dans le référentiel applicatif, une autorisation nominative est générée automatiquement, pour le Bénéficiaire et le ou les droits demandés. A toute habilitation doit forcément correspondre une demande dûment créée dans un processus ou workflow identifié et elle doit être validée par des Acteurs hiérarchiques ou fonctionnels ET à une autorisation nominative.   Toute habilitation orpheline (pour laquelle il n’existe pas de demande traitée ou d’autorisation dans un workflow) doit être supprimée du référentiel.   Si une habilitation a été supprimée par erreur, elle ne peut être reconstituée que si une demande est à nouveau créée et soumise dans un des processus ou workflow.   Dans le cas de la reprise des données, parce que la plupart des demandes d’habilitations des droits présents dans les référentiels n’ont pas de demandes dûment soumises et validées, des demandes « fictives » seront créées automatiquement pour chaque habilitation. Puis une autorisation nominative sera créée et archivée.

_____________________________________________________________________________________________

Matricule unique

Chaque collaborateur doit avoir un matricule unique permettant d’assurer l’unicité absolue même en cas d’homonymie. Dans le cas d’absence de matricule (exemple, cas des collaborateurs externes ou non gérés par le SIRH), un matricule technique peut être créé. Il n’aura aucune signification fonctionnelle (non utilisé pour l’accès au réseau ou pour se connecter à une application) mais restera la clé primaire de l’identifiant d’une identité.   Quelques règles de gestion liées au matricule : il doit être strictement unique. il ne doit servir qu’une et une seule fois pour la même identité. en aucun cas, un matricule de collaborateur ne doit être réutilisé, même dans le cas de collaborateurs externes ou prestataires. pour des raisons de traçabilité des pistes d’audits, il doit être réaffecté au même collaborateur si celui-ci quitte temporairement l’entreprise (quel que soit la durée de l’absence). dans les cas de changement de statut d’un collaborateur (exemple, un collaborateur externe devient interne), le matricule externe doit être remplacé par un matricule interne mais il doit exister un lien logique (technique) entre les deux matricules. dans le cas de l’utilisation d’un matricule technique ou de changement de statut, le matricule technique attribué la première fois est conservé.

_____________________________________________________________________________________________

Nature ou Rôle (des Acteurs)

Chaque Acteur d’un processus possède une nature ou un rôle spécifique. Tous deux déterminent les droits, devoirs et fonctionnalités qui lui seront utiles pour la gestion des identités ou la gestion des demandes d’habilitations.   Les principaux rôles des Acteurs sont les suivants : Demandeur Valideur Contrôleur RH Responsable applicatif Responsable des habilitations Administrateur technique Superviseur des processus ou des workflows L’ensemble des caractéristiques qui déterminent les devoirs, droits et fonctionnalités de chaque rôle doit être clairement consigné dans les spécifications ou dans les ordres du Responsable Sécurité de l’entreprise. Ce sont ces descriptions qui doivent faire foi dans la manière dont les Acteurs gèreront les demandes qui leur parviendront.

_____________________________________________________________________________________________

Profil métier

Regroupement du droit d’accès et d’habilitations correspondant à un métier pour un collaborateur.   Généralement, un profil métier est désigné selon deux libellés : un court (synthétique, utilisé dans certaines applications) et un long, plus détaillé et explicite.

_____________________________________________________________________________________________

Référentiel des identités

Mise en place d’un référentiel des identités centralisé et unique pour la gestion des demandes d’habilitations.   Les données d’identité provenant de la RH peuvent être traitées au moyen de procédures « batch » afin d’avoir l’ensemble des données utiles des collaborateurs internes.   Les données des collaborateurs externes ou prestataires doivent être centralisées dans le référentiel des identités.

_____________________________________________________________________________________________

Référentiel des Habilitations

Les référentiels des habilitations sont ceux dans lesquels les droits sont positionnés pour chaque collaborateur.

_____________________________________________________________________________________________

Référentiel des Structures

Ce référentiel est nécessaire dans le cas de l’utilisation d’un modèle RBAC car il regroupe les différentes organisations et structures de l’entreprise.   Il permet notamment de rattacher les collaborateurs dans l’organigramme de l’entreprise, d’en connaître le ou les liens hiérarchiques et permet de suivre avec précision les mobilités et d’en répercuter précisément les droits.   Il est à noter qu’il existe des solutions du marché qui sont spécialisées dans la gestion des structures.

_____________________________________________________________________________________________

Workflow de gestion des identités

Pour les collaborateurs internes et externes, les workflows de gestion de leurs identités doivent être distincts.   Le workflow de gestion des identités est différent de celui de gestion des habilitations car les informations manipulées sont distinctes.

_____________________________________________________________________________________________

Workflow de gestion des habilitations

Le processus ou workflow de gestion des habilitations ne concerne QUE les demandes d’habilitations. C’est-à-dire, les demandes créées afin d’autoriser un ou plusieurs collaborateurs à agir dans une ou plusieurs applications du système d’information de l’entreprise.   Dans certains cas très spécifiques, il peut être inclus dans le ou les processus de gestion des habilitations, des demandes d’accès à des fournitures qui ne sont pas des habilitations dans des applications, mais des « assets » (articles techniques tels qu’ordinateurs portables ou téléphones, PDA, etc.).   Les processus et workflows de gestion des habilitations mettent en scène des Acteurs en charge de gérer les demandes d’habilitations, selon les droits, devoirs et règles de gestion qui sont clairement définis dans une documentation projet dédiée aux Acteurs.

 

Les données utiles à la gestion des identités (extrait)

Par données d’identités, il faut comprendre que les demandes d’habilitations n’utiliseront que celles utiles à l’octroi de droits d’accès et d’habilitations. Ces données pourront provenir du ou des référentiels RH pour les collaborateurs internes ou du Service des Achats (ou autre) pour les collaborateurs prestataires.

 

L’IAM ne gère pas les données d’identités ne devant pas « sortir » des SIRH, telles que celles utilisées pour la paie ou pour identifier administrativement un collaborateur (exemple : numéro de Sécurité Sociale). Une solution IAM ne doit pas non plus se substituer à un SIRH mais s’interfacer avec lui afin de récupérer des données pour les utiliser pour les demandes d’habilitations. Ces données sont généralement (liste non exhaustive) :

• Le matricule ou identifiant unique du collaborateur.
• Sa civilité.
• Son nom d’état civil.
• Son nom usuel.
• Son prénom.
• Son entité de rattachement hiérarchique ou opérationnelle
• Son entité de rattachement juridique (peut être différente de l’opérationnelle dans le cas de mobilité)
• Les matricules, nom et prénom de son responsable hiérarchique
• Son statut (actif, inactif, parti)*
• Sa fonction ou métier dans son entité de rattachement
• Sa date d’arrivée
• Sa date de départ prévisionnelle (notamment pour les prestataires)

 

Cela implique aussi que le ou les processus de création, modification et de suppression des informations d’identité soient clairement cartographiés afin de limiter au maximum les saisies multiples et réduire à son minimum les risques d’erreurs.

 

Préconisations de pré requis pour la mise en oeuvre d'un projet IAM

Mettre en place une gouvernance Sécurité IAM pour l’ensemble de l’entreprise

Étant donné qu’un projet IAM est totalement transverse, il est prépondérant que le Sponsor ou le « Porteur » du projet communique sur les nouvelles directives IAM qui viendront s’inscrire dans la gouvernance de Sécurité globale.

 

Les règles de gestion et bonnes pratiques liées à l’IAM imposent qu’elles soient adoptées par l’ensemble de l’entreprise. En effet, il est inconcevable – et inapproprié, voire totalement contraire – qu’un ou plusieurs collaborateurs de l’entreprise utilisent des moyens détournés pour ne pas s’inscrire dans les directives IAM. Par exemple, cela peut arriver dans le cas où les processus ou workflows refondus pour mettre en œuvre les contraintes IAM, soient si lourds que la plupart des utilisateurs les contournent pour leurs demandes d’habilitations.

 

Il faut alors prendre le temps de reconsidérer les impacts des évolutions et adapter les messages liés aux conduites du changement afin de faire adhérer toutes les populations aux nouveaux processus. Cependant, s’il est considéré comme nécessaire de modifier en profondeur les processus actuels parce qu’ils ne répondent plus aux exigences dictées par l’IAM, alors il est important que ce soit le Sponsor ou le « Porteur » du projet qui communique auprès des différentes Directions et équipes sur les nouvelles directives.

 

Il faut également comprendre que dès lors que des processus IAM qui ont été validés sont mis en œuvre, il doit être interdit de les contourner pour « faire autrement ». Cette notion d’interdiction doit être impérativement communiquée par le « Porteur » du projet. Elle viendra s’inscrire dans les nouvelles politiques de gouvernance de Sécurité de l’entreprise.

 

Ces politiques de gouvernance de Sécurité et d’IAM doivent être consignées dans un document qui servira de référence pour l’ensemble de l’entreprise. Des modifications pourront être apportées mais uniquement avec l’accord du référent Sécurité qu’est le RSSI.

 

Parmi les règles importantes de gouvernance IAM, il y a celles liées à la gestion des profils métiers et des droits supplémentaires.

 

L’habitude qui consiste à gérer des « exceptions » en guise de profils métiers va à l’encontre des bonnes pratiques IAM. Car une gestion des habilitations, quelle qu’elle soit, consiste à gérer du général et très occasionnellement des exceptions.

 

C’est la raison pour laquelle il est important qu’un « Sachant » se charge de constituer (pour le périmètre applicatif dont il est responsable ou qu’il maîtrise fonctionnellement) les profils relatifs à un ou plusieurs métiers afin que la majorité des collaborateurs ait un ou N (selon les règles de gestion relatives à l’affectation des profils métiers) profils affectés (avec une dénomination explicite) et que la notion de « profil de référence » soit abandonnée au profit de profils dûment nommés.

 

Ensuite, pour ce qui est de la gestion des « exceptions » en termes de droits, des droits supplémentaires affectés à l’unité par collaborateur permettront de fournir des droits spécifiques.

 

Ainsi constituées, les habilitations deviendront des collections de droits généraux avec quelques droits particuliers pour l’ensemble des collaborateurs de l’entreprise.

 

Les revues de comptes seront d’autant plus simplifiées. Et les réconciliations, s’il doit y en avoir, le seront aussi.

Pour ce qui est des contrôles des référentiels, il est important que les fréquences soient clairement spécifiées. Il en sera de même des Acteurs / intervenants en charge des contrôles, des outils qui devront être utilisés mais aussi des règles de gestion liées aux résultats constitués et de la possibilité de les consulter (par qui ? Quand ? Où ?).

 

De même, il faut communiquer sur une règle de gestion et de bonne pratique IAM qui est de prévenir que toute demande d’habilitations doit obligatoirement être créée via un des processus ou workflow de gestion des habilitations. Dans le cas contraire, les droits ne seront pas positionnés.

 

D’ailleurs, les pistes d’audit seront là pour confirmer le bon respect de cette règle de conduite.

 

De l’importance d’une bonne fédération des équipes pour le projet

Un projet IAM est lourd, coûteux et chronophage. Il est important que l’entreprise sache qu’elle sera sollicitée car – comme nous l’avons vu plus tôt – le projet est transverse et concerne tout le monde. Cette fédération concerne aussi bien les Directions opérationnelles et métiers que celles dédiées au projet.

 

Parce que les sujets ne sont pas tous simples, il est important que le Porteur ou le Sponsor du projet fédère les équipes en charge de sa bonne réalisation.

 

On a vu des tentatives de réalisation de projets IAM où le Sponsor n’était pas en capacité de fédérer et motiver ses équipes projet. Dans la majorité des cas, le projet n’a pu aboutir et il s’en est suivi une certaine forme de découragement.

 

L’assistant à maîtrise d’ouvrage IAM ne peut endosser le rôle de Sponsor. Par conséquent, cet Acteur n’est surtout pas à minimiser lors du lancement du projet IAM et pour sa bonne réalisation.

 

Organisation des équipes projet et importance du Sponsor ou « Porteur » du projet

Il est prépondérant que les équipes collaboratrices et impliquées dans le projet du côté de l’entreprise soient nommées, constituées et organisées. Ces actions sont celles du « Porteur » du projet ou a minima celles du Directeur de projet dûment nommé.

 

Avec ces nominations, constitutions et organisations, il s’agira de s’assurer que tous les intervenants seront en capacité de s’approprier les sujets du projet, aussi bien fonctionnels que techniques afin d’assurer sa bonne réalisation.

 

Comme il est vu dans cette démarche, un nombre important d’actions devront être réalisées avant et pendant le projet. Avant, pour avoir les connaissances et éléments qui seront nécessaires à la mise en place des différentes « briques » du projet (fonctionnelles, organisationnelles, structurelles et techniques). Puis, pendant le projet, lorsque les spécifications seront en cours de réalisations et lorsque les paramétrages ou développements permettront de mettre en œuvre la ou les solutions choisies.

 

Les équipes du projet de l’entreprise qui se lancera dans « l’aventure » devront « être en ordre de marche » pour ne pas ralentir ou stopper le projet. Un important effort devra être consenti par le « Porteur » du projet pour mobiliser, fédérer et motiver « ses troupes ». Et ce, comme cela a été évoqué dans le chapitre précédent.

Ainsi, il est primordial de s’assurer que les Sachants fonctionnels et techniques seront disponibles et accessibles lorsque les besoins de leurs participations se feront connaître.

 

Pour faciliter les échanges entre les équipes et pour capitaliser sur la connaissance, il est judicieux de prévoir un espace sur le réseau dédié à la centralisation des données et des informations du projet. De même, pour la gestion documentaire et le suivi des versions des documents de référence, un espace « SharePoint » peut être mis en place, accessible à tout intervenant sur le projet.

 

Pour ce qui est des relations hiérarchiques entre les différentes équipes ou leurs membres, c’est l’entreprise qui devra définir les règles de gestion, sachant que plus elles sont élaborées – avec des modus operandi lourds et complexes – plus grande sera l’inertie qui s’installera dans le projet. Ce qui aura pour conséquence fâcheuse de démotiver et de désorganiser les équipes de travail.

 

L’importance de bien se comprendre (utilisation d’un vocabulaire commun)

Parfois, il peut arriver qu’au sein d’une même entreprise, un même mot ou expression peut signifier plusieurs choses totalement différentes et parfois sans rapport, d’une Direction ou d’un Service à l’autre. Par exemple, pour certaines DRH, le statut définit le type de population d’internes (CDI, stagiaires, CDD, etc.). Alors que le statut doit normalement définir si le collaborateur est présent, absent ou parti définitivement de l’entreprise.

 

Par conséquent, avant toute réflexion sur une expression de besoin ou la refonte des processus, il est judicieux de prévoir un glossaire qui regrouperait l’ensemble des termes du projet et qui permettrait de constituer un vocabulaire avec une définition commune pour chaque expression. Au besoin, on pourra ajouter les définitions originelles utilisées par chaque entité ou population.

 

Un référentiel applicatif précis

Comme pour les identités et les habilitations, il est très important qu’il y ait un référentiel regroupant l’ensemble des applicatifs devant être gérés par l’IAM.

 

Si ce n’est déjà fait, ce référentiel devient la « porte d’entrée » pour créer une demande d’habilitations car il est impossible de créer une demande ne reposant sur aucune application (technique ou métier). Par conséquent, comme il a été vu à un autre moment de cette étude, le référentiel des applicatifs doit regrouper les informations utiles et nécessaires à l’élaboration des demandes d’habilitations.

 

Certaines solutions techniques permettent de caractériser finement les applications et applicatifs sur lesquels des demandes pourront être créées, avec (à titre d’exemples) :

• Le nom de l’application.
• Ce pour quoi elle est utilisée.
• La ou les Directions, le ou les Départements, le ou les Services où l’applicatif est utilisé.
• Les métiers associés à l’applicatif.
• La configuration utilisée pour sa réalisation (progiciel, développement spécifique, bureautique, base de données, référentiel, annuaire, etc.).
• Son niveau de criticité en termes de Sécurité (risque opérationnel).
• Sa localisation géographique (France, région, agence, pays, etc.).
• Son mode d’approvisionnement des droits (automatique, manuel).
• Dans le cas d’approvisionnement manuel, les coordonnées de l’administrateur technique (nom, prénom, matricule, email, téléphone, localisation géographique).
• Sa version.
• Son obsolescence.
• La date de dernière mise à jour des informations.
• L’auteur des mises à jour (matricule, nom, prénom, qualité).

 

Une règle de gestion simple à mettre en œuvre pour la gestion de ce référentiel est de considérer que tant qu’un applicatif ou application n’est pas enregistré dans le référentiel, il est impossible d’établir de demande d’habilitations.

 

Un référentiel des droits applicatifs (profils) précis et compréhensible

Le référentiel des profils métiers doit être complet au moment de la mise en production de la solution IAM qui aura été réalisée. Ce référentiel sera régulièrement mis à jour, au fur et à mesure que de nouveaux profils seront créés, modifiés ou supprimés.

 

Ce référentiel servira de base de données de travail pour la création des demandes d’habilitations qui seront précises et les plus justes possibles.

 

Tous les droits seront enregistrés dans le référentiel afin qu’ils puissent être affectés à l’unité ou en groupes à des Bénéficiaires qui doivent avoir des droits spécifiques en fonction de leurs activités.

 

Construit sur un modèle ORBAC, le référentiel pourra distinguer les profils métiers d’une entité par rapport aux autres.

 

Les profils métiers possèderont deux noms : un premier utilisé en tant que raccourci, un second utilisé en tant que nom complet. Chacun d’eux respectera une nomenclature spécifique justement afin de pouvoir respecter les règles du modèle ORBAC des habilitations.

 

L’AMOA interviendra pleinement pour assister les contributeurs à construire les profils métiers, les nommer et les gérer. Ces actions sur la constitution des profils métiers à partir de l’existant se nomme la « rationalisation des droits » (« Role Management » en anglais).

 

Un référentiel des structures précis et complet

Un modèle ORBAC impose que le référentiel des structures soit complet et précis afin de pouvoir très rapidement et facilement faire le lien logique entre le collaborateur, son entité de rattachement et le profil métier qu’on lui affecte.

 

Ce référentiel doit montrer précisément les liens de subordinations entre les départements et les Services, tels qu’ils figurent dans l’annuaire ou bien encore l’organigramme de l’entreprise.

 

Selon les solutions IAM, il existe la possibilité d’interfacer l’organigramme avec les données présentes dans le référentiel IAM. Cela possède l’avantage de pouvoir gérer les mobilités unitaires ou massives. Ce qui n’empêchera pas une intervention d’un ou plusieurs responsables des habilitations mais qui aura le mérite de préparer les fichiers d’extractions des revues de compte lors des mouvements de personnels.

 

De la bonne définition des besoins pour le projet IAM

Beaucoup de structures ont tendance à sous-estimer les étapes qui consistent à définir clairement et précisément les besoins IAM.

 

Il ne faut pas oublier que ce sont ces étapes qui serviront de « références ». En effet, les développements et paramétrages qui concerneront la mise en œuvre d’une solution fonctionnelle et ou technique se fonderont sur des expressions de besoins qui auront la forme de spécifications fonctionnelles générales puis détaillées et de spécifications techniques, elles-mêmes fondées à partir du cahier des charges.

 

Ces besoins doivent être rédigés suite à des analyses de l’existant, des analyses d’écart avec les préconisations et bonnes pratiques IAM adaptées à l’entreprise et concertées entre tous les contributeurs au projet. Mais avec pour objectif principal la cible à réaliser, en tenant compte de plusieurs axes de travail :

• L’axe fonctionnel pour la gestion des Identités et la gestion des Habilitations (non imbriquées selon les cas de types de populations), avec :
  • les nouveaux processus présentant :
    • Les différents processus prévus :
      • Nouvel arrivant.
      • Modification ou suppression de données avec ou non des impacts sur les habilitations.
      • Départ définitif.
      • Circuit court ou de demandes urgentes (ex. gestion des VIP).
    • Toutes les étapes impliquant les actions de nouveaux Acteurs (certainement différents et avec d’autres responsabilités que ceux existant).
    • Tous les Acteurs intervenant à chaque étape.
    • Toutes les données manipulées, selon les étapes :
      • En consultation.
      • En affichage automatique (d’un écran à l’autre).
      • En modification.
      • En suppression.
    • Toutes les fonctionnalités permettant :
      • D’aider les Acteurs dans leurs actions de gestion des identités et des habilitations.
      • De simplifier les échanges de données entre Acteurs humains et techniques.
      • De créer des demandes d’habilitations spécifiques.
      • De créer des données en masse (ex. arrivées de stagiaires).
      • De créer des demandes d’habilitations pour des droits supplémentaires discriminants d’un Bénéficiaire.
      • De gérer les organisations et les structures en impactant les informations des collaborateurs (identités, rattachements, liens hiérarchiques, droits).
    • Toutes les actions automatiques réalisées par le système, telles que :
      • Les envois de notifications.
      • Les affichages d’informations d’identités et d’habilitations en fonction des données saisies (ex. matricule, nom et prénom, responsable hiérarchique, dates, etc.).
      • Les enregistrements des données.
    • Toutes les règles de gestion :
      • De chaque Acteur impliqué dans les processus et workflows :
        • Droits.
        • Devoirs.
        • Interdictions.
        • Délégations.
      • De manipulation des données (saisie, consultation, modification).
      • D’enregistrement de données (données intermédiaires, données validées, données d’identité, données d’habilitations).
      • De propagation des données dans les référentiels.
      • De confidentialité d’accès aux données par les Acteurs.
      • Des périmètres de visibilité des données des Acteurs.
      • De réconciliation des référentiels d’identités.
      • De réconciliation des référentiels d’habilitations.
  • Le référentiel des applications concernées par l’IAM.
  • La gestion des référentiels de droits et de profils métiers.
  • La gestion des droits supplémentaires dans les demandes d’habilitations.
  • Les contrôles des référentiels d’identités.
  • Les contrôles des référentiels d’habilitations.
  • Les audits des données IAM.
  • La structure de supervision des workflows et des processus.
  • La console d’administration des workflows et des processus, pour :
    • Modifier des règles de gestion basiques.
    • Ajouter des Acteurs délégués.
    • Débloquer des demandes non traitées.
    • Modifier des périmètres de visibilité d’Acteurs.
    • Ajouter des administrateurs techniques.
• L’axe organisationnel et structurel, avec :
  • L’organigramme de l’entreprise.
  • Les organisations des Directions, Départements et Services.
  • Les pays concernés et leurs spécificités réglementaires et de règles de gestion.
  • Les agences.
  • Les Acteurs actuels et leurs responsabilités.
  • Les métiers.
  • Etc.
• L’axe technique, avec :
  • La description de l’Urbanisation.
  • La description de l’Architecture.
  • Le réseau.
  • Les équipes techniques.
  • Etc.

De l’importance de la refonte des processus existant au regard des bonnes pratiques IAM

Compte tenu de l’organisation actuelle des Acteurs intervenant dans les processus existant de l’entreprise qui veut refondre son IAM, il est peut être envisageable de faire évoluer ses processus progressivement afin de mieux amortir les conduites aux changements.

 

Cependant, afin d’être sûr de gérer correctement les identités (collaborateurs) de l’entreprise, tous les processus – en plus de celui d’arrivée, et surtout, celui du départ définitif – doivent être spécifiés avec leurs étapes et Acteurs respectifs.

 

De l’importance de la création et de l’implication des Acteurs dans les processus et workflows

Les prérequis IAM imposent que des Acteurs interviennent dans les processus et workflows IAM.

Au-delà de la simple « création » par leur nomination et définition de leurs activités, les Acteurs doivent être impliqués dans les nouveaux processus et workflows IAM. Il est à noter que plus les Acteurs sont impliqués, plus les traitements des demandes d’habilitations sont réactifs et rapides.

 

Cette implication attendue peut être motivée par le Porteur du projet ou son Sponsor, voire par une bonne communication sur les nouvelles procédures IAM. Leurs impacts positifs et les avantages de telles pratiques, tant pour l’entreprise que pour la prévention des risques motiveront l’implication des contributeurs au projet.

Nous avons vu plus tôt, que l’IAM impose une responsabilisation des Acteurs en charge de traiter les demandes d’habilitations. Et ce, afin de garantir la qualité de la piste d’audit. Sous-estimer la responsabilisation des Acteurs des workflows ou pire, ne pas vouloir les nommer afin qu’ils traitent les demandes équivaut à ne pas réaliser le projet.

 

Cependant, il ne faut pas non plus être trop « psychorigide » dans la formalisation des actions et des devoirs des Acteurs impliqués. Il est nécessaire, comme dans toute bonne mécanique, de laisser suffisamment de jeu entre les pièces afin que la mécanique fonctionne bien, sans blocages intempestifs.

 

De l’importance d’une structure de supervision des processus et des workflows

Les processus et workflows IAM, ainsi que les Acteurs avec leurs droits et devoirs qui y sont impliqués ont besoin d’une entité indépendante qui puisse résoudre des déblocages de situations. Cette entité est une structure de supervision qui n’est pas rattachée à une Direction et elle ne se substitue pas directement aux Acteurs en charge du traitement des demandes. Mais elle peut intervenir uniquement si l’un d’eux est dans l’incapacité d’accomplir une tâche et de traiter une demande. D’autre part, cette structure – ou cellule – est garante des bonnes pratiques IAM et des règles de fonctionnement des processus et des workflows auprès des Acteurs et des collaborateurs susceptibles d’utiliser la solution IAM.

 

Il faut aussi préciser que cette structure – qui est présente dans pratiquement toutes les entreprises qui ont refondu leur gestion des identités et / ou des habilitations – est généralement le relais du RSSI afin de faire évoluer la solution lorsque des réglementaires de sécurité impactent les pratiques de gestion des identités ou des habilitations.

 

Une autre fonction concerne aussi la formation des Acteurs aux nouvelles fonctionnalités qui ont été récemment implémentées.

 

Dans le cas des évolutions fonctionnelles ou techniques, elle représente – sous le couvert du RSSI et de la gouvernance Sécurité de l’entreprise – la MOA qui les demandera et voudra les voir implémentées, selon une gestion des priorités qui sera dictée par le RSSI ou la couverture des nouveaux risques à prévenir.

Une console d’administration complète est prévue pour cette structure pour intervenir directement dans la solution IAM. Elle permet d’ajouter certains Acteurs (exemple, l’Auditeur), de paramétrer certaines étapes et fonctionnalités spécifiques telles que la délégation de certains Acteurs, les notifications, les périmètres de visibilité, etc.

 

Une centralisation des données d’identités et d’habilitations

La gestion des identités se charge de créer, modifier et supprimer des « identités », donc des informations liées aux collaborateurs de l’entreprise. Qu’ils soient internes ou prestataires.

 

Parce que les utilisateurs (Demandeurs et autres Acteurs impliqués dans les processus et workflows) de la solution IAM doivent pouvoir accéder aux données de tous les Bénéficiaires, il est impératif que toutes les données liées aux Identités soient centralisées et régulièrement réconciliées afin que tous les référentiels possèdent les mêmes données. Même s’ils concernent des périmètres ou des populations différents (collaborateurs du Siège, collaborateurs en agences), il est impératif qu’il y ait un référentiel unique regroupant toutes les données nécessaires à :

• Obtenir une gestion des identités :
  • Facile : saisies minimisées.
  • Rapide : accès aux données et mises à jour des données optimisées.
  • Efficace : une propagation précise des données dans tous les référentiels techniques et métiers concernés.
  • Précise : des consultations de données ciblées selon des périmètres de visibilité et d’accès spécifiques en fonction des Acteurs.
• Obtenir une gestion des habilitations centralisée :
  • Performante : permettant un traitement efficace et précis des demandes d’habilitations.
  • Sécurisée : dont les processus et workflows garantissent un respect des règles de sécurité des actions et des données.
  • Facile : pour la consultation des droits et autorisations d’un Bénéficiaire.
  • Précise : juste dans l’affectation des droits.
  • Auditable rapidement.
  • Traçable : dont les historiques et les archivages des données sont centralisés.

D’une bonne gestion des Identités – Centralisation des données

Une gestion des identités correcte et respectant les bonnes pratiques IAM doit :

• Avoir une gestion des identités des collaborateurs internes, juste et précise :

Si pour les collaborateurs internes, le SIRH peut être une base de référence utile, toutes les données n’y sont pas nécessairement toutes enregistrées. Dans certains cas, toutes les données des collaborateurs internes n’y figurent pas. Par exemple, certaines agences gèrent elles-mêmes leurs collaborateurs. Aussi, pour gérer des demandes d’habilitations pouvant être émises des agences et concernant des droits pour des applicatifs, il sera nécessaire de prévoir des traitements automatiques permettant de récupérer des fichiers contenant les informations que le SIRH ne possèderait pas. Pour la gestion des habilitations, les informations très spécifiques (numéro de Sécurité Sociale, catégories socioprofessionnelles, informations de paie ou de carrière) ne sont pas utilisées.

 

• Avoir une gestion des collaborateurs externes, centralisée et précise :

Les données des collaborateurs prestataires et externes doivent être centralisées au même titre que celles des collaborateurs internes. Dans tous les cas de populations, les informations de rattachement à la structure de l’entreprise doivent être centralisées pour le respect du modèle ORBAC de la gestion des habilitations.

 

La problématique de la réutilisation des matricules

Pour tous les collaborateurs, la réutilisation des matricules est à proscrire. Les matricules sont nominatifs et à usage unique.

 

On peut envisager la réutilisation d’un matricule si la gestion des historiques est correctement effectuée. Dans le cas d’un départ d’un collaborateur pour plusieurs mois ou années, on pourra lui affecter à nouveau son matricule – déjà utilisé par lui et seulement lui – à son retour dans l’entreprise.

 

La gestion des changements de situation

Plusieurs changements de situations doivent être suivis et correctement gérés (en termes d’historique des informations originelles, les dates de modifications de données et les liens entre les données) comme par exemple :

• Les changements d’identités (cas des mariages et des divorces : changement de nom de famille avec impacts sur la messagerie).
• Les changements de statuts : un prestataire devient interne ou inversement, un interne devient prestataire (avec changement de matricule, d’où le lien entre les deux matricules).

D’une bonne gestion des habilitations

Comme il a été vu plus haut, la gestion des habilitations représente le point où le risque opérationnel se concentre le plus.

 

Les processus de gestion des habilitations ne doivent pas être sont confondus avec ceux de gestion des demandes d’actions de la cellule HelpDesk. Comme vu plus haut aussi, ces processus doivent être distingués.

Une bonne gestion IAM encourage l’utilisation de profils métiers créés par des Sachants opérationnels ou fonctionnels et connaissant les droits des applicatifs. Maintenant, si ces individus n’existent pas au sein de l’entreprise, il faudra recourir à la création de glossaires technico-fonctionnels afin de trouver les définitions fonctionnelles aux termes techniques représentés dans les rôles et profils métiers.

 

Un effort important devra être consenti à la rationalisation des profils métiers. Cette action consiste dans la création de profil métiers généraux représentant le cœur de métier des collaborateurs des Directions (cf. la nomenclature des fonctions de la GPEC) avec l’ensemble des droits particuliers nécessaires à ces fonctions. Ces profils métiers permettront de regrouper sous le principe de chaînage entre les données, la sélection des droits des différents référentiels applicatifs concernés. Et ce, selon le modèle ORBAC évoqué précédemment.

Dans le cas où des profils métiers ne doivent pas contenir de droits métiers spécifiques (par exemple, le cas des consultants en AMOA), des profils pourront être constitués de droits « de base » nécessaires à tous les collaborateurs (accès à la messagerie, aux outils de bureautique, au périmètre de visibilité défini par le rattachement opérationnel) et être affectés en tant que tels.

 

Pour ce qui concerne les distinctions spécifiques entre les collaborateurs, des droits supplémentaires pourront être ajoutés unitairement à chaque collaborateur, selon les particularités de ses activités.

 

Dans tous les cas de figure, tous les profils métiers et droits supplémentaires qui devront être affectés aux collaborateurs devront faire l’objet de demandes d’habilitations qui seront traitées dans les processus et workflows IAM tels qu’ils seront spécifiés.

 

Une bonne gestion des habilitations passera aussi par la règle qui précise qu’à une habilitation doit correspondre une demande formulée, créée, datée et soumise par 1 à N Acteurs impliqués dans le workflow.

 

De l’importance de ne pas sous-estimer la conduite du changement

Tout projet IAM déclenche des méfiances relatives aux changements. Les habitudes des utilisateurs seront transformées et certains réflexes devront être abandonnés au profit de nouvelles pratiques.

 

Les conduites du changement ne sont efficaces que si les utilisateurs et les collaborateurs contributeurs se sentent accompagnés dans les phases qui imposent des actions et des procédures différentes du quotidien.

Pour cela, il est important que les Acteurs majeurs du projet interviennent pour aider et supporter celles et ceux pour qui les changements peuvent être très perturbant. Aussi, il est important de rassurer et de s’assurer que l’Acteur ou l’utilisateur n’est pas abandonné mais au contraire, est accompagné dans une démarche de conduite du changement.

 

Ces actions de conduite du changement passeront par des formations régulières, des rappels sur les nouvelles pratiques et les nouveaux processus à utiliser.

 

Dès lors, il ne faut surtout pas sous estimer les relations humaines et les échanges sur tous les sujets relatifs au projet et ses conséquences sur le quotidien.

 

L’AMOA (présenté ci-après) est là pour aider tous les contributeurs du projet à retrouver confiance et à se l’approprier.

 

De l’importance d’une reprise des données juste et précise

Les projets IAM imposent des phases de reprises des données non négligeables.

En effet, la plupart du temps, le projet consiste à mettre en place une solution technico-fonctionnelle qui fonctionnera avec des données homogènes, en lieu et place de solutions hétérogènes ou archaïques en terme de gestion des identités et de gestion des habilitations.

 

Pour que la nouvelle solution puisse fonctionner avec le moins de pertes de données et avec la meilleure transition possible, il est prépondérant que les données d’origine soient repositionnées au mieux dans les nouveaux référentiels d’habilitations.

 

Les droits positionnés ne seront modifiés que si des anomalies sont rencontrées. Par exemple, des droits seront supprimés si des collaborateurs ont définitivement quitté l’entreprise. Ou bien, des droits seront modifiés si à l’issue des actions de rationalisation des profils métiers, il est constaté que des collaborateurs possèdent plus ou moins de droits qu’ils ne devraient avoir, en fonction de leurs activités.

 

Généralement, plusieurs étapes s’enchaînent pour la reprise des données. Elles concernent aussi bien les matricules qui possiblement devront évoluer, les informations des collaborateurs (uniquement ceux qui sont effectivement présents) et celles liées aux habilitations, les profils métiers et les règles de gestion d’affectation.

 

De l'importance de l'intervention d'un AMOA IAM sur le projet

La présence d’un Assistant à Maîtrise d’Ouvrage expert des problématiques IAM soulage la MOA et facilite les étapes de coordination avec la MOE et la DSI.

 

Comme on le voit depuis le début, les sujets liés à l’IAM ne sont pas tous intuitifs. Il est important d’en connaître les spécificités, les modes de fonctionnement, les règles de gestion, les ordonnancements des actions à mener et les actions à réaliser.

 

Sans l’aide d’un intervenant capable d’aider les maîtrises d’ouvrage pour la constitution des profils métiers et les équipes techniques pour les aider à réfléchir à la création d’un identifiant unique à « propager » dans les différents référentiels et applicatifs comportant des informations d’identité et d’habilitations, aider le Sponsor dans la fédération des équipes du projet, etc., la bonne réalisation du projet est compromise. Et tout cela en respectant les préconisations réglementaires IAM.

 

Enfin, il faut que l’AMOA IAM ait pour intervention principale l’accompagnement des contributeurs du projet dans les démarches et les rédactions de documents dont ils ne sont pas coutumiers du fait.

 

En aucun cas, il n’interviendra pour les remplacer dans leurs tâches quotidiennes de production spécifiques de leur métier mais bel et bien pour les aider à compléter des actions nécessaires aux phases de préparation et de réalisation d’un projet.

 

Voici les actions pour lesquelles un assistant à maîtrise d’ouvrage (AMOA) expert IAM est prépondérant dans un premier temps, et celles qui doivent être menées avant le lancement d’un projet IAM :

 

Action AMOA IAM	Description
Faire un état des lieux de l’existant	Aider le client à lister les différents processus et workflows existant (gestion des identités, gestion des habilitations) et faire une analyse d’écart entre eux et les bonnes pratiques IAM (matricule unique, demandes d’habilitations, notions de profil de référence, pistes d’audit, Acteurs impliqués, ségrégation des droits, etc.).

_____________________________________________________________________________________________

Aider pour des expressions des besoins fonctionnels et techniques IAM précises

Aider le client dans la définition des besoins et dans la rédaction d’un cahier des charges supportant toutes les problématiques IAM, en incluant les bonnes pratiques, les fonctionnalités, les règles de gestion, les Acteurs et leurs activités, les données manipulées, etc.

_____________________________________________________________________________________________

Communiquer et conseiller pour les futures conduites du changement

Intervenir auprès des différents groupes d’utilisateurs dans la conduite du changement qu’imposera le projet IAM à mettre en place. Communiquer autour de supports que l’AMOA pourra apporter dans les phases de prises de connaissances.

______________________________________________________________________________________________

Intervenir pour aider à constituer un référentiel des identités précis et fiable

Instruire l’architecture fonctionnelle et technique du référentiel des identités centralisé, avec : Les informations d’identité des collaborateurs internes. Les informations d’identité des collaborateurs externes et prestataires. Les informations d’organisation et de structure, avec : Les Directions. Les Départements. Les Services. Les Agences. Les Responsables Hiérarchiques. La distinction entre les entités juridiques et opérationnelles. Construire les règles de gestion d’approvisionnement du référentiel des identités avec les données provenant : Du SIRH. Du référentiel des collaborateurs externes concernés par l’IAM. Des Agences. De la solution IAM. Lister  et revoir les procédures de mise à jour de l’annuaire et de l’organigramme.

_____________________________________________________________________________________________

Aider le Porteur du projet IAM à construire une gouvernance de Sécurité IAM argumentée à l’ensemble de l’entreprise

Intervenir dans la constitution des fichiers d’extractions des référentiels applicatifs des droits regroupant : Les collaborateurs (matricule, nom, prénom, entité de rattachement). Pour chacun d’eux, les droits présents dans les référentiels. Intervenir et aider les Sachants fonctionnels et les autres contributeurs, à : Pointer les collaborateurs partis définitivement de l’entreprise. Construire les profils métiers. Instruire les directives pour fédérer et motiver les futurs Acteurs dans les nouveaux processus de gestion des identités et des habilitations. Définir les Acteurs et leurs actions au sein de la solution IAM. Revoir les processus de gestion des Identités. Revoir les processus de gestion des Habilitations.

_____________________________________________________________________________________________

Aider la DSI et la DRH à cartographier précisément tous les processus et workflows liés à la gestion des identités

Intervenir pour cartographier les différents processus mais aussi pour lister, modéliser et retrouver toutes les règles de gestion des identités des collaborateurs internes et externes.

_____________________________________________________________________________________________

Aider la DSI et la DRH à cartographier précisément tous les processus et workflows liés à la gestion des habilitations

Intervenir pour lister, modéliser et retrouver toutes les règles de gestion des habilitations des collaborateurs internes et externes.

______________________________________________________________________________________________

Aider la DSI et les Métiers à cartographier le schéma Directeur de l’entreprise global et celui concerné par le projet IAM

Cartographier l’ensemble des applications présentes dans le Système d’Information de l’entreprise, avec : L’architecture globale du SI de l’entreprise. Les liens de dépendance entre applicatifs. Le sens des flux de données. Faire une proposition d’architecture pour la solution IAM choisie. Cartographier l’ensemble des applications présentes dans le Système d’Information de l’entreprise devant être prise en charge par le projet IAM, avec : Les liens de dépendance entre applicatifs. Le sens des flux de données. Les règles de gestion spécifiques liées aux dépendances (par exemple : pour travailler dans l’application A, il faut que les droits soient positionnés dans B, C, D et avec un Groupe « E »).

______________________________________________________________________________________________

Intervenir pour consolider les processus et workflows de gestion des identités et des habilitations

Analyser et mettre en exergue les écarts entre l’existant et les bonnes pratiques IAM en s’adaptant aux exigences fonctionnelles et organisationnelles de l’entreprise concernée, avec : Les évolutions des processus. Les évolutions des workflows. Une réflexion sur la mise en place d’Acteurs intervenant dans la gestion des Identités. Une réflexion sur la mise en place d’Acteurs intervenant dans la gestion des Habilitations. Une réflexion sur les ségrégations des devoirs et des droits des Acteurs impliqués dans la gestion des Identités et la gestion des Habilitations.

_____________________________________________________________________________________________

Aider l’entreprise dans la construction de son référentiel des structures

Construire un référentiel des structures et faire les choix des trigrammes des Directions, Départements et Services qui seront réutilisés dans la gestion des habilitations pour des identifications (profils métiers, rattachements, etc.) et peut-être le matricule / identifiant unique technique des collaborateurs de l’entreprise.

______________________________________________________________________________________________

Aider l’entreprise à constituer un référentiel applicatif centralisé, précis et fiable

Construire un référentiel recensant l’ensemble des outils et applicatifs devant être gérés par le projet IAM, comportant : Le nom de l’applicatif. Sa fonction (description fonctionnelle ou technique). La ou les Directions et Services concernés. Le ou les Métiers concernés. Préciser son niveau de sensibilité en termes de Sécurité (fonctionnelle ET technique). Préciser son niveau de priorité en termes de prise en charge IAM. Son ou ses Responsables fonctionnels (nom, matricules, coordonnées de contact, localisations, entités d’appartenance, métier / fonction). Son type d’approvisionnement des droits (automatique ou manuel). Dans le cas d’approvisionnement manuel, les noms et coordonnées des Administrateurs techniques. Préciser le format des fichiers d’extraction pour les contrôles des habilitations. Etc.

______________________________________________________________________________________________

Aider l’entreprise dans les actions de Role Management

Intervenir auprès des Sachant pour construire les profils métiers par fonction (cf. proposition de GPEC) et selon l’organisation de l’entreprise et par collaborateur Définir les formats des fichiers des extractions des référentiels applicatifs et de droits. Effectuer des extractions applicatives pour obtenir tous les droits positionnés dans les référentiels, par collaborateur. Construire le ou les glossaires techniques et fonctionnels des droits présents dans les extractions.

 

Petits rappels au sujet de la CNIL et la protection des données d'identité

Il existe souvent des confusions au sujet de ce qui est dicté par la Commission Informatique et Liberté (CNIL) pour ce qui est de l’utilisation de données liées aux identités des collaborateurs.

 

Fort heureusement, ce n’est pas parce qu’on met en place un projet IAM qu’il est impossible d’utiliser les informations d’identité des collaborateurs, de les sauvegarder et de les tracer en prévision de futurs audits.

La CNIL n’interdit pas l’utilisation des informations d’identité des collaborateurs présents dans une structure dès lors que le fichier décrivant les informations utilisées est dûment déclaré auprès de ses services.

 

Quelques points pour aller encore plus loin...

Cet article n’étant pas exhaustif, voici quelques sujets qui pourront intéresser et être traités pour la bonne réalisation d’un projet IAM :

• L’abandon de la notion de profil de référence pour une bonne gestion des profils métiers des collaborateurs.
• Les règles de gestion liées aux profils métiers (dépendances, exclusions, priorités, Segregation of Duties, etc.).
• Règles de construction des profils métiers.
• Règles d’affectation des profils métiers et droits supplémentaires dans les demandes d’habilitations.
• La gestion des mobilités.
• Planification de la reprise des données.
• Règles de gestion liées aux données à reprendre.
• Préparation à la conduite du changement.
• Plannings, supports et populations concernés par la conduite du changement
• Etc.