Réussir votre projet IGA : commencez par les personas

Pourquoi les projets IGA échouent plus souvent qu'ils ne le devraient

L'Identity Governance and Administration (IGA) existe depuis assez longtemps pour que l'on puisse s'attendre à un faible taux d'échec. Les concepts sont bien établis, les principales plateformes sont matures, et les personnes ayant déjà mené ce type de projet ne manquent pas. Et pourtant, les projets continuent de dépasser les délais, de ne pas respecter leur périmètre initial, ou de livrer une solution qui fonctionne, mais pas tout à fait pour cette organisation.

Les raisons ont tendance à se regrouper autour d'un ensemble de thèmes familiers.

L'adhésion de la direction est souvent citée, et elle compte réellement. Sans un engagement fort de la part des dirigeants, les projets sont vulnérables face aux réductions de périmètre lorsque les budgets se resserrent ou que les priorités changent.

Les objectifs du programme sont un autre coupable habituel : soit les ambitions ont été fixées trop haut par rapport à ce que la technologie peut réellement offrir, soit elles n'ont jamais été assez précises pour être mesurables dès le départ.

Les délais de livraison dérapent lorsque la planification est sacrifiée au profit d'une mise en avant rapide auprès des parties prenantes. Les choix technologiques échouent lorsque l'évaluation repose sur des démonstrations fournisseurs plutôt que sur des exigences documentées. Il est facile de se laisser séduire par une plateforme riche en fonctionnalités et de découvrir ensuite que les fonctionnalités réellement nécessaires étaient justement celles qui exigent le plus de personnalisation. Les coûts dérapent lorsque les exigences changent en cours d'implémentation, ou lorsque l'effort de configuration et d'intégration est sous-estimé dès le départ.

Tous ces problèmes sont réels, et tous ont déjà fait l'objet de longs écrits. Mais il existe un mode d'échec qui a tendance à se dissimuler derrière plusieurs des autres, et qui reçoit bien moins d'attention : le projet n'a jamais véritablement établi pour qui il était conçu.

La plupart des projets IGA qui rencontrent des difficultés peuvent faire remonter au moins une partie du problème à des hypothèses formulées en amont sur les types d'utilisateurs, d'identités et de scénarios d'accès que la solution devait gérer, des hypothèses qui se sont révélées erronées.

La solution n'est pas compliquée, mais elle exige de la discipline. Elle consiste à démarrer le projet en construisant une vision complète de votre paysage identitaire, pas de la technologie, pas des intégrations, pas des flux de travail. Uniquement les personnes et les identités que votre programme de gouvernance doit couvrir. Tout le reste en découle.

La suite de cet article explique comment construire cette vision de votre paysage identitaire, et pourquoi cela fait une différence bien plus importante que ce que la plupart des organisations imaginent.

Vous envisagez donc l'Identity Governance

La technologie elle-même est rarement la raison pour laquelle les projets IGA rencontrent des difficultés : la cause profonde est presque toujours de partir d'un produit plutôt que de comprendre ses collaborateurs.

Que l'on vous ait demandé d'évaluer une plateforme IGA, ou que vous soyez déjà en plein projet et que les choses se compliquent, vous avez probablement remarqué que la technologie n'est généralement pas la partie la plus difficile.

Les plateformes IGA (le logiciel qui contrôle qui a accès à quoi, automatise l'intégration et la sortie des collaborateurs, et garantit qu'une personne revoit ces droits d'accès périodiquement) sont matures, bien comprises et largement performantes. La plupart des grandes plateformes gèrent les cas d'usage principaux sans grande difficulté.

Alors pourquoi tant de projets IGA dépassent-ils leur budget, prennent-ils plus de temps que prévu, ou aboutissent-ils à une solution qui ne convient pas tout à fait ?

Dans notre expérience, cela revient presque toujours à la même cause profonde : l'organisation a commencé par choisir un produit plutôt que de comprendre ses collaborateurs.

La chose la plus précieuse que vous puissiez faire avant d'évaluer le moindre fournisseur est de comprendre qui travaille réellement dans votre organisation et à quoi ressemble sa relation avec l'identité.

Ce n'est pas aussi simple que « les employés entrent, les employés sortent »

En apparence, l'IGA semble simple. Quelqu'un rejoint l'entreprise, il obtient des comptes. Quelqu'un part, ces comptes sont désactivés. Entre les deux, quelqu'un vérifie périodiquement que les personnes ont toujours besoin de ce qu'elles possèdent.

La réalité, dans la plupart des organisations, est bien plus complexe. Considérez quelques-unes des questions qui ont tendance à émerger une fois qu'un projet est en cours :

Que se passe-t-il pour les prestataires et le personnel d'agence : apparaissent-ils dans votre système RH ? Si non, d'où la plateforme IGA tire-t-elle leurs informations ?

Qu'en est-il des fournisseurs tiers ayant besoin d'accéder à des systèmes spécifiques : comment sont-ils intégrés, et qui gère leur cycle de vie ?

Avez-vous des employés qui travaillent au sein de plusieurs entités juridiques ou régions, potentiellement avec des rôles différents dans chacune d'elles ?

Existe-t-il des comptes de service, des comptes partagés ou des identités machine qui doivent être régis au même titre que les utilisateurs humains ?

Qu'en est-il des utilisateurs occupant des rôles sensibles (dirigeants, équipes financières, administrateurs IT) qui pourraient nécessiter des contrôles plus stricts ou des processus d'approbation différents ?

L'un de vos personas détient-il un accès sur lequel un régulateur ou un auditeur posera des questions précises, et cela change-t-il la façon dont ses permissions doivent être revues ou documentées ?

Les permissions doivent-elles durer indéfiniment, ou certaines permissions, notamment les plus sensibles, doivent-elles être limitées dans le temps ?

Aucun de ces cas n'est marginal. Dans toute organisation de plus de quelques centaines de personnes, ce sont la norme. Et si la plateforme IGA que vous avez choisie n'a pas été évaluée à leur aune, vous le découvrirez à vos dépens, généralement pendant l'implémentation, au moment où changer de cap coûte cher.

Entrez le persona

En matière d'identity governance, un persona est un type distinct d'utilisateur dont le cycle de vie identitaire, les exigences d'accès ou les sources de données diffèrent significativement des autres : non pas des personnes individuelles, mais des types de personnes.

Il existe une technique qui fait partie de l'analyse structurée des systèmes depuis des décennies, empruntée à l'origine au génie logiciel, parfaitement adaptée à la résolution de ce problème. Elle porte différents noms - personas utilisateurs, acteurs, archétypes identitaires - mais l'idée est simple.

Avant de définir ce qu'un système doit faire, on définit d'abord tous les différents types de personnes (et de non-personnes) que ce système doit servir.

Dans notre expérience, une organisation de taille moyenne identifie généralement entre trente et cinquante personas identitaires distincts. Pour les organisations des secteurs de la santé, de l'éducation ou de la distribution, ce nombre peut facilement doubler.

Quelques exemples pour illustrer cela :

Un employé permanent qui rejoint l'entreprise via votre système RH, avec un parcours d'intégration standard, l'approbation de son responsable hiérarchique, et un ensemble défini d'accès de base par défaut.

Un prestataire recruté via une agence, dont la fiche vit dans une feuille de calcul ou un portail fournisseurs plutôt que dans le SIRH, et qui peut travailler pour plusieurs clients simultanément.

Un étudiant ou un stagiaire avec un engagement à durée déterminée et un accès qui doit expirer proprement à la fin de son stage.

Un utilisateur IT à privilèges qui détient des comptes administratifs nécessitant un contrôle accru, des mesures de séparation des tâches, et potentiellement un accès juste-à-temps plutôt que des permissions permanentes.

Une identité non humaine, telle qu'un compte de service applicatif ou une intégration API, qui possède des permissions, doit être régie, et ne remplira certainement jamais un formulaire de demande d'accès en libre-service.

Chacun de ces personas interagira différemment avec votre plateforme IGA. Certains seront intégrés automatiquement depuis un système source. D'autres nécessiteront des processus manuels ou des sources de données alternatives. Certains auront besoin de chaînes d'approbation spécialisées ; d'autres auront besoin que leur accès expire selon un calendrier.

Pourquoi cela compte pour le choix de la plateforme

Une fois votre liste de personas établie, vos exigences s'écrivent presque d'elles-mêmes.

Vous cessez de demander « cette plateforme prend-elle en charge l'entrée/mutation/sortie ? » (elles répondent toutes oui) et commencez à poser des questions bien plus précises :

Peut-elle ingérer des données d'identité provenant de sources multiples, comme un SIRH, des feuilles de calcul, LDAP et des points de terminaison SCIM, et les réconcilier en un enregistrement d'identité unique ?

Peut-elle gérer des identités qui n'ont aucun enregistrement RH, via un flux d'intégration distinct ?

Peut-elle appliquer des politiques de gouvernance différentes selon les types d'utilisateurs, de sorte que vos prestataires bénéficient d'un cycle de revue d'accès de 90 jours tandis que vos utilisateurs à privilèges en ont un mensuel ?

Lorsque quelqu'un change de rôle, peut-elle calculer l'écart et provisionner ou déprovisionner les bons éléments sans intervention humaine et sans créer de droits orphelins ?

Peut-elle signaler lorsque quelqu'un accumule une combinaison de droits d'accès représentant un risque, même si chaque droit pris individuellement semblait inoffensif au moment de son octroi ? Peut-elle montrer à un auditeur pourquoi l'accès de chaque persona a été approuvé et par qui, selon une cadence de revue adaptée au risque que représente ce persona ?

Une plateforme IGA bien conçue devrait pouvoir gérer tout ce qui précède. L'exercice des personas vous indique lesquelles de ces capacités sont réellement essentielles pour votre organisation, et lesquelles ne sont qu'un plus.

Il vous indique également ce qu'il faut demander à voir lorsque vous évaluez des fournisseurs. Plutôt que d'assister à une présentation générique du produit, vous pouvez remettre au fournisseur un ensemble de personas et lui demander de vous montrer, précisément, comment sa plateforme gère chacun d'eux.

L'exercice des personas transforme l'évaluation d'un fournisseur d'une simple comparaison de fonctionnalités en un véritable test de capacité. Il est bien plus difficile de dissimuler une lacune lorsque vous avez demandé un scénario précis plutôt qu'une capacité générale.

À quoi ressemble une bonne implémentation en pratique

Lorsque vous observez un déploiement IGA bien configuré, la logique des personas est visible dans l'architecture. Différents types d'identités suivent différents parcours d'intégration. L'accès est attribué en fonction du rôle et du contexte, et non de listes gérées manuellement. Lorsque la situation de quelqu'un change (une promotion, une mutation, une prolongation de contrat), la plateforme réagit automatiquement.

Les revues d'accès sont délimitées intelligemment : les bonnes personnes revoient les bons droits, selon une cadence adaptée au niveau de risque. Lorsqu'un réviseur repère quelque chose qui ne devrait pas être là, la suppression est automatique et traçable. Lorsqu'un accès est nécessaire de toute urgence, il existe un flux de demande et d'approbation qui laisse une trace claire.

Les combinaisons d'accès sensibles (par exemple, la capacité de créer un bon de commande et également de l'approuver) sont identifiées de manière proactive, et non découvertes lors d'un audit. Les exceptions sont gérées avec supervision plutôt que de s'accumuler silencieusement.

Rien de tout cela n'exige une plateforme particulièrement exotique. Ce que cela exige, c'est que quelqu'un, tôt dans le projet, ait pris le temps de comprendre quels types de personnes et d'identités l'organisation compte réellement, et ait conçu la solution autour d'elles.

Le bénéfice se manifeste partout où l'accès touche l'activité de l'entreprise : les droits circulent plus vite car ils ne nécessitent pas d'intervention manuelle, ils sont plus précis car liés au contexte plutôt qu'à des listes statiques, et la conformité cesse d'être une course contre la montre parce que les preuves ont été capturées au fil du travail, et non reconstituées après coup.

L'avantage pratique

Au-delà d'accroître les chances de succès de votre projet IGA, l'exercice des personas présente quelques effets secondaires utiles.

Il profite aussi à d'autres projets. L'identité touche pratiquement tout dans une organisation. Votre liste de personas sera tout aussi utile lors de l'évaluation de solutions de Privileged Account Management (PAM), d'outils de gestion des terminaux, ou de tout autre système ayant besoin de savoir qui sont vos utilisateurs et ce qu'ils font.

Il facilite les échanges avec les parties prenantes. Lorsque vous pouvez faire référence au « persona du prestataire » ou au « persona de l'administrateur à privilèges » plutôt que de décrire une exigence technique abstraite, la conversation devient plus concrète. Les parties prenantes métier comprennent les personas d'une manière qu'elles ne comprennent pas toujours les schémas de droits d'accès.

Il constitue un apport naturel pour la gouvernance de projet. Si vous utilisez une matrice RACI (Responsible, Accountable, Consulted, Informed) pour gérer les responsabilités du projet, votre liste de personas vous fournit la matière première. Derrière chaque persona se trouvent un propriétaire métier, un référent technique et un ensemble de parties prenantes, qui doivent tous être consultés, informés ou directement impliqués.

Où se situe une plateforme comme Netwrix Identity Manager

Rien de tout cela n'est une raison de retarder le choix d'une plateforme. C'est une raison d'en choisir une conçue pour fonctionner dans le sens de votre liste de personas, et non contre elle.

Netwrix Identity Manager régit les identités internes, externes, invitées, techniques, IoT et des agents IA selon le même modèle, de sorte qu'un prestataire recruté via une feuille de calcul, un compte de service dont personne aux RH n'a jamais entendu parler, un agent IA provisionnant son propre accès, et un employé permanent arrivant via votre flux RH bénéficient tous de la même discipline de cycle de vie, plutôt que de quatre solutions de contournement différentes. Les identités tierces et non humaines disposent de leur propre parcours de cycle de vie, y compris un accès limité dans le temps qui expire selon le calendrier prévu plutôt que de subsister après la fin d'un contrat ou d'une mission. L'intégration de nouveaux systèmes ne nécessite pas non plus de projet d'intégration sur mesure : des connecteurs standard couvrent AD, LDAP, SQL, CSV et SCIM d'emblée, avec des connecteurs avancés et des API génériques disponibles pour tout ce qui est plus spécifique à votre environnement.

La gestion des rôles fonctionne de la même manière. Vous définissez des modèles de rôle et de politique par persona plutôt qu'une politique unique pour tous, et le role mining utilise le machine learning pour analyser les schémas d'accès réels, découvrir les structures de rôles et maintenir le modèle à jour à mesure que l'usage évolue, de sorte qu'il ne se contente pas de refléter l'organigramme du jour de sa création.

Le volet risque est conçu pour cette même réalité. Un moteur de politiques détecte et prévient les conflits de séparation des tâches, et une surveillance continue signale les comptes orphelins et les anomalies avant qu'ils ne remontent lors d'un audit, plutôt qu'après.

Rien de tout cela ne remplace l'exercice des personas. C'est ce qui rend possible un passage rapide de la conception à l'implémentation : chaque identité est définie et régie selon ses propres termes, plutôt que forcée dans un unique circuit et corrigée par des exceptions pour s'y adapter. Le résultat : un risque plus faible, une implémentation plus rapide et un coût moindre.

En résumé

Les plateformes d'Identity Governance sont matures et performantes. La technologie n'est généralement pas ce qui met les projets en difficulté. Ce qui met les projets en difficulté, c'est de partir d'un produit et d'essayer d'y faire entrer, après coup, la réalité de l'organisation.

L'alternative (identifier d'abord ses personas identitaires, les utiliser pour définir les exigences, puis évaluer les plateformes au regard de ces exigences) paraît évidente une fois décrite. Mais elle est étonnamment rare en pratique, et l'écart qu'elle comble est important.

Elle ne nécessite ni outillage spécialisé ni connaissances techniques approfondies. Elle nécessite du temps, de bonnes questions, et la volonté d'impliquer les bonnes personnes de toute l'entreprise dès le début du processus.

Réussissez vos personas, et le reste du projet devient nettement plus simple. Ratez-les, ou faites-en l'impasse, et vous risquez de vous retrouver à adapter après coup une solution à un problème que vous n'aviez pas pleinement compris au moment de l'acheter.

Rencontrez-vous des difficultés avec votre programme d'identité ? Nous pouvons vous aider à comprendre vos personas et la façon dont Netwrix Identity Manager peut faire de votre projet une réussite. Demandez une démo.