Chez toutes les sociétés équipées d’une solution de gestion des identités et des accès, la migration des systèmes constitue une question incontournable.
Au fil des années, certaines solutions réputées ont dû quitter le marché. Pour les entreprises qui disposent de ces solutions, un remplacement devient alors nécessaire à court terme. Et par rapport à ce contexte, plusieurs fournisseurs font la publicité et la promesse d’une migration fluide de l’ancienne solution vers leur plateforme.
Ainsi, ils affirment que certains outils contribuent à automatiser la conversion et la migration des configurations de données existantes vers le nouvel environnement. Mais en réalité, l’effort que représente la migration d’un système IAM est comparable à un déménagement. Et pour rester sur cette métaphore, supposons que le plan de sol de votre ancienne adresse puisse être utilisé à votre nouveau domicile, et que le déménageur puisse y réinstaller vos meubles sans aucune instruction de votre part. Considéreriez-vous cela comme un avantage ?
À l’occasion de la conférence EIC de KuppingerCole et de la conférence IAM de Gartner, plusieurs experts sont intervenus pour expliquer clairement qu’il serait peu avisé de remplacer un système IAM par l’équivalent technologique d’un nouveau fournisseur ; autrement dit selon un rapport de 1:1. En effet, le système installé a probablement été conçu il y a dix ans. Et compte tenu de la spécification fonctionnelle caractéristique de l’époque, et de l’expérience limitée des clients en matière d’IAM (partant du principe qu’il s’agit de leur tout premier système), il devient évident qu’une remise à plat, voire probablement une refonte conceptuelle de la solution, seront fortement recommandées, et ce avant toute migration.
Le modèle de données
De prime abord, depuis la précédente (et première) génération de solutions IAM, peu de choses ont changé : identités, rôles, groupes, systèmes… Le modèle de données des anciennes solutions semble rester valide, et nombre de fournisseurs mettent en avant leur capacité à extraire automatiquement les données existantes pour les importer dans le nouveau système. Inutile de s’étendre sur ce type de prestations.
En outre, il ne fait nul doute que la gouvernance des accès a, elle aussi, laissé sa griffe sur le modèle de données. Avec la mise en œuvre croissante de l’IAM dans les différentes directions métiers de l’entreprise, les solutions IAM traitent et stockent un panel d’informations largement étendu. Il convient de bien distinguer les différents types d’identités : identités des employés, sous-traitants et clients, identités techniques…
Lorsque les anciennes générations de solution ont été conçues, les systèmes étaient essentiellement utilisés pour des utilisateurs humains, internes à l’entreprise. Du fait des nouveaux usages tels que le cloud, la mobilité ou l’internet des objets, le périmètre de l’IAM s’étend désormais au-delà des frontières de l’entreprise et les identités se complexifient.
Parmi les critères de sélection, il est nécessaire de s’assurer que les éditeurs sont en mesure de distinguer et de traiter l’ensemble des types d’identités propres à l’entreprise cliente. Parallèlement, les structures organisationnelles des entités métiers se sont complexifiées au cours de la dernière décennie.
Là où les anciens systèmes IAM géraient des arborescences simples, les systèmes actuels doivent distinguer différents responsables métiers en fonction des cas d’usage. À cela s’ajoute le besoin croissant d’administrer les droits d’accès selon l’affectation des utilisateurs à des projets spécifiques, plutôt que selon leur poste dans l’organigramme.
Qu’elle soit automatique ou semi-automatique, la migration des données vers le nouveau système ne posera aucun problème à la majorité des fournisseurs. Toutefois, si un client entame un projet de migration sans avoir préalablement spécifié ses exigences, la nouvelle solution IAM peut se révéler aussi limitée que l’ancienne.
Compte tenu de l’évolution du modèle de données, les clients doivent garder à l’esprit que la migration s’avère être un projet IAM à part entière, qui devra intégrer les fameuses questions du type “Où trouver les nouvelles données ?”, ou encore “Quel est le processus pour telle situation ?”.
Les systèmes cibles
Gérer les droits d’accès au niveau des plateformes et des systèmes informatiques de l’entreprise constitue un prérequis de base des systèmes IAM standards. Aussi, lors de la sélection de l’éditeur, les clients ont raison de considérer les capacités de provisioning comme un critère important. Des aspects, tels que la liste des connecteurs standards disponibles pour les plateformes impliquées, seront clairement les indicateurs d’une migration efficace. Mais d’autres aspects doivent être pris en compte.
Ainsi, la mise en cohérence des données est une fonction largement sous-estimée : tous les concepts IAM reposent sur la capacité du système à synchroniser périodiquement les données présentes sur les systèmes cibles avec celles présentes dans le référentiel IAM.
Mais déterminer quel système est prioritaire (référentiel IAM ou système cible) est une question spécifique à chaque client. La solution doit permettre une configuration suffisamment granulaire pour déterminer quels systèmes régissent quels champs de données ; sans parler de la nécessité de disposer d’une communication bidirectionnelle pour chacun des connecteurs.
Les workflows
Pour migrer un workflow, il faut distinguer la partie processus de la partie interface utilisateur. Selon nous, lorsqu’une entreprise est en phase de sélection d’un fournisseur IAM, il n’est pas rare d’avoir à répondre à des questions concernant la capacité de la solution à respecter les standards de workflow (notamment BPMN, la norme du BPM). On pourrait penser que la prise en charge de ces normes diminuerait considérablement les efforts de migration.
Or, si un processus peut certes être migré plus facilement en s’appuyant sur de telles normes, il n’en reste pas moins que des logiques telles qu’escalades, délégations, substitutions et des structures organisationnelles sont autant d’éléments difficiles à spécifier dans des notations standards.
Pour ce qui est de l’interface, les clients s’inquiètent de la capacité ou de la volonté de l’utilisateur final à s’adapter aux nouvelles interfaces. Aussi ont-ils tendance à demander un remplacement à l’équivalent de l’interface existante.
L’expérience montre que faire en sorte que les nouveaux workflows ressemblent trait pour trait aux anciens, en termes d’ergonomie et d’expérience utilisateur, s’avère plus complexe que ce que l’on peut imaginer. Partant de ce constat, l’entreprise aurait tout à gagner à créer une nouvelle interface répondant aux standards d’expérience utilisateur d’aujourd’hui.
La conformité
La prise en compte des workflows induit un autre aspect qui doit, lui aussi, être envisagé lors du remplacement du système IAM : la mise en conformité. En effet, si l’on remonte à 2005, en matière d’IAM, l’efficacité et la productivité constituaient des drivers bien plus importants que le respect des normes et réglementations. Or, il est indéniable que les exigences de conformité et d’audit qui s’appliquent aux processus se sont considérablement développées au cours des dernières années.
Les processus de recertification des utilisateurs ou les processus liés à la mise en œuvre des politiques de sécurité sont devenus des caractéristiques fondamentales des solutions IAM. Certaines solutions ont pu évoluer dans ce sens, dans une certaine mesure. D’autres fournisseurs sont confrontés à des limites en termes d’évolution, à cause du design de leur solution ou du fait de l’arrêt du support technologique.
Quoi qu’il en soit, les clients devront passer en revue les exigences de conformité auxquels ils sont soumis, et déployer les fonctionnalités requises au plus vite sur leur future solution.
Conclusion
Tous ces exemples mettent en évidence la plus importante faiblesse de l’idée prétendue qu’”une migration rapide et automatisée d’un système IAM est possible”. D’importantes évolutions ont pris place depuis la mise en œuvre des premiers systèmes IAM.
Les entreprises se sont ouvertes et ont repoussé les frontières de leur SI. Le paysage des systèmes cibles administrés a évolué. Les smartphones et tablettes ont bouleversé notre conception de l’expérience utilisateur. En conséquence, les attentes des utilisateurs ont considérablement changé.
Votre ancien système IAM n’a pas été conçu au départ et n’a pas été adapté au fil des années pour répondre à ces attentes. Aussi, la migration doit-elle être considérée comme une occasion de mettre en œuvre une solution répondant à vos besoins actuels et futurs. Bien sûr, cette approche nécessite des efforts supplémentaires de révision et de refonte de votre concept IAM.
Bastien MEAUX, Marketing & Partners Manager France de Beta Systems
