Intégration des solutions IAM as a Service : attention aux complexités et aux coûts cachés !

Les solutions de gestion des identités et des accès en mode cloud, ou IAM as a Service, se multiplient.

Comme toutes les solutions IAM, leur mission est de sécuriser et faciliter l'accès aux applications et services cloud, mais aussi aux applications historiques déployées en entreprises, qu'elles soient métier issues d'un éditeur ou développées en interne. Elles doivent donc supporter l'interfaçage avec ces applications, ce qui peut s'avérer plus complexe qu'espéré.

Les solutions de gestion des Identités et des Accès, ou IAM, sont un élément essentiel de la sécurité des entreprises. Elles peuvent s’appuyer sur une infrastructure au sein de l’entreprise (On Premise ou sur site) mais peuvent aussi aujourd’hui être délivrées sous la forme d’une application SaaS, de type IAM as a Service ou IDaaS, ou une combinaison (hybride) des deux.

 La mission première de toutes ces solutions est à la fois de valider l’identité et l’accès des utilisateurs vers tous les applicatifs de l’entreprise, et de transmettre à ces derniers les éléments d’identification des utilisateurs.

Considérer l’existant

Concrètement, elles doivent donc faciliter l’accès à la fois aux applications et services cloud, de plus en plus présents car largement plébiscités par les utilisateurs, mais aussi aux applications historiques déployées en entreprise, qu’elles soient métier (finance, achat, RH, comptabilité, documentaires, collaboratif...), issues d’un éditeur de progiciel, ou développées spécifiquement en interne.

Pour cela, il est donc nécessaire de la part des solutions exclusivement IAM as a Service de supporter l’interfaçage avec ces applications déployées en entreprise. Ce qui peut s’avérer plus compliqué que prévu.

 En effet, gérer l’accès et l’identité numérique des utilisateurs de ressources de l’entreprise nécessite d’avoir un « pied » dans son système d’information et de disposer d’un interfaçage avec son existant : qu’il soit au niveau des systèmes, notamment un référentiel d’identités, au niveau des applicatifs ou des réseaux. L’interfaçage avec le SI de l’entreprise permet de fournir un ensemble de fonctionnalités liées à cet existant sur site, tels que l’identifiant des utilisateurs s’appuyant sur un ou plusieurs annuaires (ou référentiels) internes d’entreprise ou l’accès aux applications déjà utilisées au quotidien (par exemple depuis l’adoption d’un ERP mis en œuvre plusieurs années auparavant ainsi qu’une multitude d’applications métier). Par ailleurs, un certain nombre d’applications historiques ne supportent pas nécessairement les protocoles standards en matière d’authentification et peuvent être issus de plates-formes ou développements plus anciens rendant l’intégration difficile depuis un service IDaaS distant.

L’adoption d’une solution de gestion des identités et des accès sous la forme d’un service (« IDaaS », ou IDentity as a Service) requiert donc d’avoir cette interaction, cet interfaçage local avec les systèmes d’information d’entreprise sur site. Ce lien qui peut sembler simple en apparence est en réalité -en fonction de sa mise en œuvre- plus complexe qu’il n’y paraît.

Certains éditeurs de solutions exclusivement IDaaS s’appuient sur un message de simplicité d’usage mais aussi de simplicité et de rapidité de mise en œuvre. Celle-ci peut rapidement s’avérer plus complexe qu’espéré, particulièrement une fois passé les applications les plus simples à intégrer. De plus, nombre d’éditeurs de solutions IDaaS peuvent négliger de préciser les coûts additionnels non prévus nécessaires à la mise en place de ce lien avec les applications historiques de l’entreprise, qu’il s’agisse de coûts d’infrastructure ou d’administration.

 Lorsque la solution d’IAM vise à gérer l’accès et l’identité numérique d’utilisateurs de l’entreprise auprès d’applications situées exclusivement cloud (donc SaaS), le lien avec le SI existant dans l’entreprise est moindre, néanmoins il reste nécessaire, à minima pour authentifier cet utilisateur et assurer un interfaçage avec son moyen d’authentification primaire (le plus souvent un couple « Identifiant + Mot de Passe »), dès lors que l’entreprise ne souhaite pas externaliser le stockage du mot de passe dans un système hors de son contrôle et situé dans le cloud.

Le risque de sécurité pour l’entreprise associé à l’externalisation du Login et mot de passe est dans ce cas élevé, car des solutions d’IAM as a Service ont déjà été par le passé la cible de pirates.

Attention aux coûts cachés

Enfin, avec la multiplication des offres IDaaS, certains éditeurs de solutions sur site d’ancienne génération, certaines datant de plus de 20 ans (éditeurs généralistes issus du mainframe, des systèmes de gestion de base de données, etc.) ont récemment annoncé avoir développé une évolution de leur solution en mode IDaaS. Toutefois, ils ont parfois du mal à se positionner correctement pour offrir aux utilisateurs un ensemble de fonctionnalités couvrant de manière équivalente les besoins applicatifs du système d’information de l’entreprise sur site (restés donc derrière les firewalls) aussi bien que ceux des applications SaaS.

Une attention toute particulière devra être portée au coût de mise en œuvre et à la capacité de couverture des multiples usages, dans le cas de contrats cadre existants avec ces éditeurs, qui offrent le plus souvent « gracieusement » (toute ou partie) des licences de ces nouvelles solutions. L’adoption et la mise en œuvre de ces anciennes plates-formes peuvent rendre leur évolution (voire leur migration) longue, coûteuse et complexe. Le client peut alors devenir encore plus captif de ces éditeurs généralistes, au profit de leurs services professionnels d’intégration. 

Autour du même sujet

Annonces Google