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
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.
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 :
Cette question s’inscrit directement dans la gestion des Identités.
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 :
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.
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 :
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 :
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.
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.
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 :
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 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.
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.
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.
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.
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 :
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).
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.
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.
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.
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.
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 :
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.
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 :
|
Dans certains cas (à discuter et à valider en interne dans l’entreprise, pour construire les règles de gestion des processus)
|
__________________________________________________________________________________________
Valideur |
Traite la demande d’habilitations qui lui est adressée. |
Il peut :
|
Généralement :
|
__________________________________________________________________________________________
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 :
|
(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 :
|
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 :
|
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 :
|
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 :
|
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 :
|
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.
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.
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.
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.
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.
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 :
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 :
|
_____________________________________________________________________________________________
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 :
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. |
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) :
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.
É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.
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.
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.
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.
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) :
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.
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 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.
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 :
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.
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.
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.
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 à :
Une gestion des identités correcte et respectant les bonnes pratiques IAM doit :
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.
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.
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.
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 :
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.
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.
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.
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 :
|
_____________________________________________________________________________________________
Aider le Porteur du projet IAM à construire une gouvernance de Sécurité IAM argumentée à l’ensemble de l’entreprise |
|
_____________________________________________________________________________________________
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 :
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 :
|
______________________________________________________________________________________________
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 :
|
_____________________________________________________________________________________________
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 :
|
______________________________________________________________________________________________
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
|
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.
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 :