La plateforme IGA d'un fournisseur de services technologiques était configurée pour propager les événements du cycle de vie des identités (provisionnement, changements de rôle et déprovisionnement) à toutes les applications connectées via des connecteurs SCIM et de synchronisation d'annuaire. La liste des applications connectées à l'IGA comprenait dix-sept systèmes. Lors d'un audit d'intégration pour une nouvelle mission client, l'équipe de sécurité du fournisseur a constaté qu'un ingénieur récemment parti avait toujours un accès actif à l'espace de travail de projet partagé du client dans Confluence. L'enquête a révélé que le client avait déployé une nouvelle instance Confluence auto-hébergée six semaines avant le départ de l'ingénieur pour soutenir un projet précis. La nouvelle instance avait été ajoutée à l'environnement par l'équipe projet sans en informer les administrateurs de l'IGA, et sans être ajoutée à la liste des connecteurs de l'IGA. Lorsque l'ingénieur a été déprovisionné, l'IGA a correctement déprovisionné les dix-sept systèmes connectés. Le dix-huitième système, la nouvelle instance Confluence, n'a pas été touché, car l'IGA ignorait son existence. L'accès de l'ingénieur à Confluence a subsisté non pas parce que le processus de déprovisionnement a échoué, mais parce que le système se trouvait en dehors du périmètre du processus.
Que recouvre réellement le risque lié à la propagation des identités entre systèmes ?
La propagation des identités entre systèmes est le processus par lequel les événements du cycle de vie des identités (création d'utilisateurs, changements de rôle et déprovisionnement) sont communiqués depuis une source d'identité centrale (généralement un IdP ou une plateforme IGA) à tous les systèmes connectés, afin que l'état des identités soit cohérent dans l'ensemble du paysage applicatif. Lorsqu'un employé arrive, le provisionnement crée des comptes dans tous les systèmes concernés. Lorsqu'un rôle change, les modifications d'accès sont appliquées de manière cohérente. Lorsqu'un employé part, le déprovisionnement supprime simultanément ses accès à tous les systèmes. Les défaillances de propagation surviennent lorsque certains systèmes ne reçoivent pas ces événements du cycle de vie, soit parce que la voie de propagation est incomplète, soit parce que des systèmes ont été ajoutés à l'environnement sans être enregistrés pour recevoir les événements du cycle de vie.
La lacune de l'inventaire des connecteurs est le principal mode de défaillance de la propagation. Les plateformes IGA propagent les événements vers les systèmes qu'elles connaissent, c'est-à-dire les systèmes intégrés en tant que connecteurs et configurés pour recevoir les événements du cycle de vie. Les systèmes ajoutés à l'environnement sans être intégrés à l'IGA sont invisibles pour le processus de propagation. Dans les environnements d'entreprise dynamiques où les équipes déploient régulièrement de nouvelles applications, de nouveaux services cloud et de nouveaux outils de développement, l'écart entre la liste des connecteurs de l'IGA et l'inventaire réel des applications se creuse en permanence, sauf s'il existe un processus actif reliant le déploiement de tout nouveau système à son intégration dans l'IGA.
Le problème des systèmes fantômes amplifie la lacune des connecteurs. Les applications déployées par des équipes pour les besoins d'un projet précis (un nouvel outil de collaboration pour une mission client, un environnement de développement pour un sprint, un tableau de bord de surveillance pour le déploiement d'un système) contournent souvent entièrement le processus de provisionnement de l'informatique. L'équipe déploie l'application, crée des comptes et l'utilise sans en informer l'informatique ni l'équipe IGA. Lorsque des membres de l'équipe partent, le déprovisionnement par l'IGA n'atteint pas l'application, car celle-ci n'a jamais été enregistrée. Les comptes subsistent indéfiniment et sont parfois découverts des mois plus tard lors d'un audit sans rapport.
- Nouveaux systèmes non enregistrés dans la liste des connecteurs de l'IGA : applications déployées sans en informer les administrateurs de l'IGA
- Applications fantômes déployées par les équipes : systèmes créés en dehors du processus de provisionnement de l'informatique, sans intégration des événements du cycle de vie
- Liste des connecteurs non tenue à jour par rapport à l'inventaire actuel des applications : le périmètre de l'IGA prend du retard sur le périmètre réel de l'environnement
- Aucun processus de découverte des nouvelles applications : aucun mécanisme permettant d'identifier les systèmes absents de la liste des connecteurs de l'IGA
- Exhaustivité de la propagation non vérifiée : hypothèse selon laquelle le déprovisionnement par l'IGA couvre tous les systèmes
Pourquoi c’est important
La propagation des identités entre systèmes est importante pour la TPRM, car les fournisseurs qui accèdent aux environnements des clients via plusieurs systèmes (espaces de travail de projet, outils de collaboration avec les clients, environnements de développement partagés) peuvent présenter des lacunes de déprovisionnement IGA pour les systèmes connexes à l'environnement du client qui ont été déployés spécifiquement pour la mission. Ce sont précisément les systèmes les plus susceptibles de se trouver en dehors de la liste standard des connecteurs de l'IGA : déployés rapidement pour un objectif précis, gérés par une équipe projet plutôt que par l'informatique, et non enregistrés dans l'IGA avant la fin de la mission.
La fenêtre d'accès après le départ est la dimension aux conséquences les plus immédiates. Lorsqu'un employé du fournisseur qui gérait une mission client s'en va, le déprovisionnement par l'IGA supprime ses accès à l'entreprise. Mais l'outil de collaboration déployé pour la mission, l'environnement de développement partagé et l'espace de travail du projet propre au client peuvent tous se trouver en dehors de la liste des connecteurs de l'IGA, et l'accès à chacun d'eux subsiste jusqu'à ce que quelqu'un l'identifie et le supprime spécifiquement.
Là où la plupart des équipes se trompent
La défaillance la plus constante consiste à considérer l'automatisation de l'IGA comme un déprovisionnement exhaustif sans vérifier que la liste des connecteurs de l'IGA correspond à l'inventaire actuel des applications. L'IGA est exhaustive pour les systèmes figurant dans sa liste de connecteurs. Vérifier l'exhaustivité exige de comparer la liste des connecteurs à l'inventaire réel des applications, un rapprochement que la plupart des organisations effectuent rarement, voire jamais.
- Considérer l'automatisation de l'IGA comme exhaustive sans vérifier la liste des connecteurs
- Aucun rapprochement de l'inventaire des applications avec la liste des connecteurs de l'IGA
- Déploiement de nouvelles applications ne déclenchant pas leur enregistrement dans l'IGA
- Découverte des applications fantômes non réalisée
- Vérification des accès après le départ ne couvrant pas les systèmes hors IGA
À quoi ressemblent les bonnes pratiques
Les programmes matures de propagation des identités tiennent à jour une liste des connecteurs de l'IGA qui correspond à l'inventaire réel des applications, grâce à des processus qui relient le déploiement de nouvelles applications à leur enregistrement dans l'IGA, à un rapprochement périodique de la liste des connecteurs avec le paysage applicatif et à une analyse de découverte des systèmes situés en dehors du périmètre de l'IGA.
- Le déploiement d'une nouvelle application déclenche son enregistrement dans l'IGA : un processus exige l'intégration dans l'IGA avant la fin du déploiement de l'application
- Rapprochement périodique de la liste des connecteurs : comparaison du périmètre de l'IGA avec l'inventaire actuel des applications
- Découverte des applications fantômes : recherche des applications absentes de la liste des connecteurs de l'IGA
- Vérification des accès après le départ : confirmation que le déprovisionnement a couvert tous les systèmes, y compris les applications hors IGA
- Inventaire des applications en tant qu'élément de gouvernance : liste tenue à jour de toutes les applications avec leur statut de connexion à l'IGA
Outils
Découverte SaaS : Grip Security, Nudge Security, BetterCloud
Les plateformes de découverte SaaS identifient les applications utilisées dans une organisation, y compris les applications fantômes déployées par des équipes sans enregistrement auprès de l'informatique. Ces plateformes détectent l'accès aux applications grâce à la télémétrie d'extensions de navigateur, à l'analyse du trafic réseau ou à l'analyse des journaux du fournisseur d'identité. Pour les professionnels de la TPRM, demander si le fournisseur utilise la découverte SaaS pour identifier les applications situées en dehors du périmètre de son IGA constitue une question précise sur la détection des applications fantômes.
IGA avec découverte des applications : SailPoint, Saviynt
Les plateformes IGA modernes offrent des capacités de découverte des applications, qui identifient les applications dans lesquelles des utilisateurs ont des comptes non gérés par l'IGA. Pour les professionnels de la TPRM, demander si l'IGA du fournisseur comprend une découverte des applications qui identifie les systèmes non enregistrés comportant des comptes utilisateurs constitue une question précise sur la détection des lacunes de propagation.
Enjeux de gouvernance
Le défi de gouvernance de l'exhaustivité de la propagation des identités tient à l'évolution continue de l'environnement. Les inventaires d'applications changent sans cesse : de nouveaux outils sont déployés, d'anciens sont mis hors service, le périmètre des déploiements existants change. La liste des connecteurs de l'IGA qui était exacte lors du dernier rapprochement l'est de moins en moins à mesure que l'environnement évolue. Maintenir l'exhaustivité exige soit une découverte automatisée qui identifie en continu les nouveaux systèmes, soit un processus qui relie chaque déploiement de nouvelle application à son enregistrement dans l'IGA avant sa mise en service.
- Exiger l'enregistrement dans l'IGA avant le déploiement de toute nouvelle application : un point de contrôle de gouvernance dans le processus de déploiement
- Mettre en place une découverte SaaS pour détecter les applications fantômes
- Rapprochement périodique de la liste des connecteurs avec l'inventaire actuel des applications
- Vérification des accès après le départ incluant les systèmes hors IGA
- Intégrer l'exhaustivité de la propagation à l'évaluation de la gouvernance des accès
Si vous êtes une petite équipe
Après le prochain départ d'un membre du personnel d'un fournisseur, effectuez une vérification que la plupart des organisations ne font jamais : demandez au fournisseur de confirmer que le déprovisionnement a couvert tous les systèmes auxquels la personne partie avait accès, pas seulement les systèmes gérés par l'IGA, mais aussi les outils propres à un projet, les plateformes de collaboration avec les clients et les applications déployées par les équipes. La réponse fera apparaître à la fois les systèmes situés en dehors du périmètre de l'IGA et l'existence ou non d'un processus du fournisseur pour les identifier.
- Demander aux fournisseurs de confirmer, à chaque départ, que le déprovisionnement a couvert tous les systèmes, y compris les applications hors IGA
- Demander si le fournisseur dispose d'un processus pour identifier les applications situées en dehors du périmètre de son IGA
- Demander à quelle fréquence la liste des connecteurs de l'IGA est rapprochée de l'inventaire réel des applications
- Demander si le déploiement d'une nouvelle application déclenche son enregistrement dans l'IGA
Ce qu’il faut exiger
Demandez directement :
« Lorsque vous déprovisionnez un membre du personnel qui avait accès à notre environnement, ce déprovisionnement couvre-t-il tous les systèmes auxquels il avait accès, y compris les outils propres à un projet, les plateformes de collaboration avec les clients et les applications déployées par les équipes qui ne sont pas gérées par votre IGA centrale ? »
« À quelle fréquence la liste des connecteurs de votre IGA est-elle rapprochée de votre inventaire réel des applications afin d'identifier les systèmes dans lesquels des utilisateurs ont des comptes qui ne sont pas gérés par le processus de cycle de vie de l'IGA ? »
Preuves attendues
- Liste des connecteurs de l'IGA avec la date du dernier rapprochement
- Capacité ou processus de découverte des applications fantômes
- Processus de vérification des accès après le départ couvrant les systèmes hors IGA
- Processus d'enregistrement dans l'IGA lors du déploiement d'une nouvelle application
Il faut demander précisément à un fournisseur qui confirme un déprovisionnement automatisé par l'IGA si cette automatisation couvre les applications déployées pour des projets précis qui peuvent ne pas figurer dans la liste des connecteurs de l'IGA. L'automatisation couvre ce que l'IGA connaît. La question porte sur ce que l'IGA ne connaît pas.
Comment le prouver
- Registres de rapprochement de la liste des connecteurs de l'IGA
- Registres de découverte des applications fantômes
- Vérification des accès après le départ incluant les systèmes hors IGA
- Processus d'enregistrement dans l'IGA lors du déploiement d'une nouvelle application
À retenir
L'IGA a déprovisionné l'utilisateur de dix-sept systèmes. Le dix-huitième système, l'instance Confluence déployée six semaines plus tôt par l'équipe projet, n'a jamais figuré dans la liste des connecteurs. L'automatisation a fonctionné. Le périmètre était incomplet. L'exhaustivité de la propagation des identités exige que l'IGA connaisse chaque système dans lequel des utilisateurs ont des comptes : pas seulement les systèmes enregistrés lors du déploiement de l'IGA, mais chaque système ajouté à l'environnement depuis. La liste des connecteurs est le périmètre de gouvernance. L'inventaire des applications est le périmètre réel. L'écart entre les deux, c'est là que les utilisateurs partis conservent leurs accès. Rapprochez les listes. Enregistrez les nouveaux déploiements. Vérifiez l'exhaustivité après chaque départ. L'automatisation n'est exhaustive que dans la mesure de ce qu'elle connaît.