Dans ce deuxième article sur la gestion des identités et des accès (IAM), nous examinons pourquoi de nombreuses organisations rencontrent des difficultés à transformer leur écosystème IAM, et comment les programmes IAM doivent être abordés et structurés. Dans notre article précédent, nous avons identifié les principaux facteurs d’amélioration de l’IAM et quatre niveaux de maturité clés. Nous avons estimé que des programmes dédiés et proactifs sont essentiels pour gravir cette échelle de maturité.
L’IAM est un concept ayant des impacts multiples. Cela doit être pris en compte lors de l’exécution d’un tel programme, afin d’éviter de tomber rapidement dans les problématiques courantes. Voyons cela de plus près.
Les défis d’un programme IAM : quelques exemples typiques
Les trois principaux facteurs qui imposent des exigences en matière d’IAM sont l’évolution des activités métier, la cybersécurité et l’expérience des utilisateurs. Cependant, les organisations entreprennent souvent des programmes IAM motivés, exclusivement ou principalement, par le désir de migrer vers une nouvelle solution. Avec la dette technique ou l’outillage comme seule véritable préoccupation, les programmes IAM peuvent être très rapidement confrontés à des problèmes.
1/ Impacts de la migration vers une nouvelle solution
Souvent, le désir est de simplement migrer vers un nouvel outil ou d’effectuer une mise à niveau majeure de la solution technique existante, tout en laissant tous les autres éléments du service IAM inchangés. Cela peut avoir des effets indésirables sur ces autres aspects. Par exemple, un nouvel outil entraînera probablement de nouveaux processus d’approbation, qui nécessiteront la formation du personnel à une nouvelle interface utilisateur. Il pourrait même nécessiter des processus de départ et d’arrivée entièrement nouveaux pour les RH. Ce point sensible se résume finalement à un manque d’évaluation de l’impact du changement technologique, dans le contexte d’un écosystème IAM plus large.
2/ Une liste d’exigences toujours plus longue
Lorsqu’une organisation réalise que le changement IAM ne se limite pas à l’outillage, cela peut souvent ouvrir les vannes à un nombre irréaliste de nouveaux objectifs. Les parties prenantes finissent par exiger davantage du programme (comme une meilleure expérience utilisateur et une intégration ITSM accrue), alors que ces nouveaux objectifs n’avaient pas été identifiés et pris en compte à l’origine. Le programme peut devenir un moyen d’exprimer le mécontentement à l’égard du service IAM existant, ce qui entraîne un glissement de périmètre. Cette dynamique peut rapidement mettre à mal le programme au niveau de la gestion du changement, du budget et de l’architecture de la solution.
3/ Forcer une mise en œuvre similaire
Une fois que les interactions entre la nouvelle solution IAM et ses services périmétriques sont pleinement opérationnelles, vous devez encore tenir compte des différences de philosophie de conception entre le nouvel outil et l’ancien. Les principales différences de conception des produits doivent être prises en compte. Si ce n’est pas le cas, les organisations peuvent finir par exiger un code personnalisé et des configurations complexes sur la nouvelle solution, simplement pour correspondre à l’ancienne configuration. Cela peut avoir un impact sur l’assistance du fournisseur, la maintenance, les performances globales – sans parler de la nécessité de conserver un énorme corpus de connaissances sur la personnalisation complexe. En empruntant cette voie, vous risquez de causer plus de problèmes que ceux que vous essayez de résoudre. Un véritable effet papillon peut donc se produire lorsqu’on essaie de forcer l’utilisation d’outils différents à des fins similaires.
La clé pour éviter ces problèmes courants est de reconnaître que l’IAM doit être considérée comme un sujet transversal, qui a un impact sur la technologie, les personnes et les processus.
Quelle est donc l’approche recommandée ?
La clé du succès est la reconnaissance du fait que l’amélioration de l’IAM est un programme de grande envergure. La mise en œuvre de nouvelles solutions n’est que la partie émergée de l’iceberg, et les impacts clés ne doivent pas être sous-estimés. Les points clés à considérer lors de la transformation sont :
- Le renouvellement de la solution IAM : le déploiement (ou la mise à niveau) de la nouvelle solution IAM. Cela comprend l’architecture de la solution, l’ingénierie et la migration technique.
- La modélisation des droits : les droits d’accès existants doivent être traduits dans le nouvel écosystème IAM, tels que les rôles métier et les profils d’application.
- Le nettoyage des données IAM : l’examination, le nettoyage et la validation de la fiabilité et de l’exactitude des données utilisateurs existants. Par exemple, la recertification du rôle d’un utilisateur et la validation de son supérieur hiérarchique pour s’assurer que la bonne personne approuve les demandes d’accès.
- Les nouveaux processus et la gestion du changement : cela inclut de nouvelles façons de demander et d’examiner l’accès aux applications, de nouveaux processus pour gérer les départs et les arrivées, et la formation du personnel.
- L’interopérabilité avec les autres services et actifs du SI : par exemple, l’intégration du nouvel outillage IAM avec le SOC peut nécessiter une réingénierie de l’ingestion des journaux dans le SIEM et des appels API. Un autre travail typique consiste à coordonner la migration avec celles liées à l’AD.
Nous recommandons donc de structurer le programme IAM de telle sorte que chacun de ces sujets soit couvert par un projet individuel. Le département en charge de la rédaction des politiques IAM doit opérer au niveau du programme, afin de fournir des inputs clairs permettant de guider les différents projets.
Un sponsorship fort et une vision publiquement partagée des objectifs sont également essentiels à la réussite. Les programmes IAM touchant de nombreux domaines organisationnels, il est essentiel que le gestionnaire de programme et la fonction PMO soient soutenus au niveau de la direction.
Enfin, la flexibilité est essentielle pour gérer l’évolution des circonstances et des contraintes. Voici d’autres conseils pour que le programme puisse rester sur la bonne voie et atteindre les objectifs prévus :
- Trouver un bon compromis entre les actifs hérités, la cible idéale et les capacités de la nouvelle solution : la cible doit être basée sur ce qui aide le mieux à fournir le service IAM de bout en bout à l’entreprise.
- Évaluez la possibilité d’intégrer des nouvelles solutions aux services existants, même s’ils ne sont pas envisagés à l’origine dans l’état cible idéal. Simplifiez et rationalisez dans la mesure du possible. Cela sera utile à la fois à court et à long terme.
- N’excluez pas la possibilité de conserver des outils existants qui devaient initialement être déclassés, si cela soutient les objectifs de l’IAM : il est parfois préférable de conserver certains actifs existants, plutôt que de déclasser et de migrer au nom de la modernisation technique.
Dans cet article, nous avons vu comment la définition des objectifs clés est essentielle pour la réussite du programme. Il est important de comprendre l’ampleur du changement IAM, à la fois pour structurer le programme et pour respecter les délais et le budget. Cette approche permettra également aux responsables du programme et à chaque responsable de stream de mettre en œuvre des mesures flexibles pour migrer d’un écosystème et d’applications legacy vers la nouvelle solution. Le tout sans perdre de vue les principes directeurs de la gestion des identités et des accès.
