Une norme pour tout gérer : un langage commun pour la crise de la gestion des identités du cloud

Malgré la généralisation accrue de la collaboration dans le secteur technologique, la bataille se poursuit et divise dans un domaine : celui de la gestion des accès et des identités.

Les tendances de mise en container, d'API et d'open source sont plus que les derniers termes IT à la mode - elles témoignent d'un changement dans la manière dont les esprits les plus affutés de la technologie prennent de l'avance dans l'économie digitale. Les entreprises d'aujourd'hui se rendent compte que, plutôt que de réinventer la roue avec chaque nouvelle technologie, elles peuvent plus rapidement et mieux innover en puisant dans la faculté offerte par la collaboration, l'intégration et l'ouverture, au lieu de faire du bricolage. Toutefois, malgré la généralisation accrue de la collaboration dans le secteur technologique, la bataille se poursuit et divise dans un domaine : celui de la gestion des accès et des identités (l'IAM).

En l'état, la plupart des entreprises qui lancent des applications et des systèmes traitant des identités (c'est-à-dire le plus grand nombre, voire toutes) déploient des modèles et des interfaces propriétaires personnalisés - ce qui implique que les entreprises doivent minutieusement intégrer et gérer les identités dans les applications au cas par cas et sur mesure. Dans le monde actuel, une entreprise peut gérer au quotidien des milliers d'applications et d'identités qui se déplacent dans et hors du cloud - ou de systèmes en local - ce qui revient à mettre une pression colossale dans les délais et sur les ressources financières. 

Il existe toutefois une solution à la crise des identités de l'IAM : le SCIM (System for Cross-Domain Identity Management), une API REST à norme ouverte qui définit le modèle et le protocole permettant à présent aux entreprises de gérer les identités de façon uniforme et cohérente. Malgré cela, l'adoption généralisée du SCIM par les fournisseurs de SaaS et d'IAM ne s'est pas encore produite, beaucoup préférant s'en tenir à ce qu'ils connaissent et élaborer leurs API personnalisées. Ainsi, l'entreprise moyenne est forcée de gérer les identités dans ses applications cloud avec un codage sur mesure chronophage.

Dans cet article, j'explique pourquoi le secteur doit se débarrasser d'une approche amateur, adopter des normes ouvertes et je reviens sur l'importance de l'interopérabilité et de la collaboration dans l'économie digitale.

IAM: l'histoire en bref

Depuis les débuts de l'IAM, les services informatiques travaillent à intégrer leurs solutions d'IAM à une myriade de systèmes d'identité en local. Ces systèmes incluent des mainframes, des systèmes de messagerie, des systèmes de contrôle des accès physiques, des serveurs Unix/Linux et de très nombreuses applications métier basées sur Oracle, Microsoft et d'autres bases de données. Il semble qu'il y ait un nombre quasiment illimité de ces systèmes en local, néanmoins l'intégration de ces systèmes avec la pluparts des solutions IAM a été grandement réussie. Pourquoi ? La plupart des systèmes et solutions en local sont sur le marché depuis de nombreuses années, voire des décennies, si bien que beaucoup de problèmes d'interopérabilité ont été résolus.

Prenons par exemple Active Directory de Microsoft ou SQL; la solution de base de données d'Oracle et RACF (Resource Access Control Facility) d'IBM pour le contrôle d'accès au mainframe. Comment l'interopérabilité entre ces systèmes de bases de données s'effectue-t-elle? La solution vient d'ODBC (Open Database Connectivity ) sorti en 1992. Comment l'interopérabilité entre services de répertoires en local est-t-elle effectuée? La solution vient du protocole LDAP (Lightweight Directory Access Protocol ) sorti en 1993.

Aujourd'hui, une solution de gestion des identités peut utiliser un connecteur LDAP pour communiquer avec n'importe quelle solution LDAP. Peu importe qu'une solution ait été développée par Microsoft, IBM, Oracle ou un autre éditeur prenant en charge LDAP, il est possible d'obtenir facilement une interopérabilité avec elle et de l'incorporer dans sa solution de gestion des identités avec un seul type de connecteur.

Où veux-je en venir ? Le secteur a eu plus de deux décennies pour résoudre les problèmes d'interopérabilité entre la plupart des systèmes en local. Malheureusement, ce n'est pas le cas avec les systèmes cloud.

La transformation cloud et ses défis

Les systèmes cloud sont complètement différents. Pourquoi ? Ces cinq et quelques dernières années, de nouveaux logiciels et solutions proposés dans le cloud ont proliféré. Ceci a eu un effet transformateur pour de très nombreuses entreprises. Pensez seulement à des solutions telles que Salesforce, Dropbox, Office 365, Workday, ServiceNow et vous comprendrez ce que je veux dire.

Quoi qu'il en soit, ce déluge d'applications cloud dans les entreprises implique également des charges accrues pour les professionnels de l'informatique en charge de la sécurité - le volume en jeu à lui seul revient à gérer et à sécuriser des milliers d'applications supplémentaires - toutes ces applications étant susceptibles d'utiliser des mécanismes différents pour échanger les données d'identité. De plus, avec l'essor des solutions SaaS et de la tendance du BYOA (Bring Your Own App), il est à présent très facile pour chaque employé et chaque équipe d'acheter et d'introduire des solutions dans leur organisation sans impliquer le service informatique. De ce fait, l'informatique pense souvent qu'un nombre donné de solutions cloud est utilisé quand, en réalité, ce nombre peut être 2 à 4 fois plus important.

Un de nos clients a réussi à faire un inventaire dans son entreprise et a découvert qu'ils utilisaient un peu plus de 1200 solutions Cloud. Vous vous rendez compte ? D'après mon expérience, il est vraiment rare de trouver un client prêt à intégrer plus de cent systèmes en local avec sa solution IAM - en général, ce sont 15 à 50 systèmes qui doivent être intégrés. Cependant, sachant que des données sensibles sont constamment diffusées et échangées dans le monde actuel régi par le SaaS à la fois en sortie et en entrée d'une organisation, il est d'une importance capitale de garder le contrôle et une visibilité des endroits où résident vos données d'identité. Ceci peut s'avérer difficile quand vos applications et vos systèmes parlent tous des langages différents. Du coup, existe-t-il un équivalent à ODBC ou à LDAP pour les systèmes Cloud? Oui, et c'est là que le SCIM entre en scène.

Pourquoi le SCIM importe

Depuis 2015, le SCIM est une norme de l'IEFT (Internet Engineering Task Force), en particulier RFC 7644. API REST ouverte basée sur JSON et XML, cette norme automatise l'échange des informations d'identité des utilisateurs entre systèmes informatiques en fournissant un modèle commun d'utilisateur, un modèle d'extension et un protocole de service. En substance, le SCIM a été créé comme moyen puissant de normaliser - donc de simplifier - la façon dont les données d'identité sont échangées entre partenaires et systèmes.

Pourquoi le SCIM importe-t-il tant ? Dans les faits, sans méthode standardisée de connexion, les entreprises doivent écrire des connecteurs logiciels personnalisés pour relier leurs applications et systèmes à leur système IAM. Or aujourd'hui, les grandes entreprises détiennent jusqu'à plusieurs milliers d'applications et de serveurs, bases de données et fichiers partagés associés qu'elles hébergent et qu'il faut livrer aux utilisateurs, ce qui peut revenir à des centaines d'heures de travail répétitif.

Grâce à des systèmes qui fonctionnent avec le SCIM, les entreprises peuvent facilement établir l'interopérabilité entre diverses solutions cloud en utilisant un seul type de connecteur - au final, cela permet à ces différents systèmes de communiquer avec le même langage. C'est une économie de temps et de coûts considérable d'un point de vue des services pour tout client. De plus, cela réduit la complexité de votre système IAM qui traite avec un seul type de connecteur, au lieu de multiples connecteurs.

Des cas d'usage illustrent la puissance du SCIM : si un employé quitte votre entreprise, le SCIM peut être utilisé pour supprimer automatiquement les comptes de cet utilisateur dans les systèmes externes en un clic rapide. Il évite de devoir mettre fin à la livraison de tous les comptes de cet utilisateur un à un dans chaque application : les applications Google de travail, Salesforce, Slack, Office 365, pour n'en citer que quelques-unes.

Autre exemple : si vous décidez de changer de fournisseur pour votre système CRM qui utilise le SCIM, les données dans l'ancien système peuvent être facilement migrées vers le nouveau système une fois connecté au SCIM. Autrement, sans SCIM, toutes ces données peuvent se retrouver verrouillées dans un stockage des identités propriétaire d'un système, ce qui rend la migration de ces données difficile, si ce n'est impossible.  

Pour cette raison, l'impact potentiel du SCIM sur l'économie digitale est vaste. Grâce à la capacité de connecter l'infrastructure en communiquant avec le langage SCIM commun à tous, sans pointilleux codage personnalisé, les équipes informatiques peuvent sécuriser et synchroniser les données et les identités bien mieux et plus vite, tout en concentrant leurs efforts sur ce qui compte : la transformation digitale et l'innovation. Par conséquent, les entreprises peuvent réaliser davantage d'économies de temps et de coûts et ce, plus rapidement.

Faire que les différences RESTent sur pause

Tandis que l'explosion des systèmes cloud survient de toute part, il devient de plus en plus critique de pouvoir facilement prendre en charge et intégrer ces systèmes dans nos solutions d'identité. Le SCIM apporte une réponse à cela. Il nous permet de transformer la gestion des identités en plateforme universelle plutôt que d'en faire une étape fastidieuse dans l'adoption du cloud.

Malheureusement, il existe des problèmes avec le SCIM. Principalement, les fournisseurs de SaaS n'ont pas massivement adopté le SCIM. Contrairement au LDAP et au ODBC que des centaines de fournisseurs ont adoptés, seuls quelques fournisseurs ont opté pour le SCIM. Ainsi, alors qu'un standard en place est disponible, il n'y a pas d'adoption généralisée et, sans adoption généralisée, nous continuerons à subir des problèmes d'interopérabilité dans notre monde toujours plus régi par le SaaS.

Compte-tenu de la réserve propre à notre secteur, il n'y a rien d'étonnant - l'ouverture peut sembler contrintuitive à ceux qui, dans le secteur, sont en charge de protéger les données. Certains fournisseurs de SaaS peuvent également craindre qu'avoir recours à une norme d'interopérabilité utilisée par leurs concurrents va renforcer la compétition avec ceux-ci. Vu ainsi, il peut être tentant de vouloir verrouiller les données - donc les clients - dans une approche propriétaire.

Toutefois, selon le dicton, la marée montante soulève tous les bateaux. Adopter les cultures de la coopération dans la concurrence et de la collaboration nous permettra d'autant mieux de sécuriser les données sensibles d'identité dans les environnements SaaS actuels dispersés et de concentrer nos efforts sur la transformation digitale - des mécanismes loin d'être inutiles.

Tandis que la sécurité et la confidentialité deviennent des sujets toujours plus sensibles parmi les brèches de sécurité actuellement exacerbées, ceci est plus critique que jamais. Il est recommandé que les entreprises, en tant que clients, exigent un support SCIM dans les diverses solutions cloud et SaaS qu'elles achètent. Certains fournisseurs peuvent se contenter de verrouiller les entreprises dans une approche propriétaire, mais d'autres peuvent tout simplement ignorer l'existence d'une norme comme le SCIM.

À l'autre bout du prisme, il est recommandé aux développeurs qui élaborent les nouvelles solutions, infrastructures et applications d'aujourd'hui d'envisager d'utiliser le SCIM comme leur couche d'identité. Cela permet un gain de temps tout en contribuant à l'ouverture et à l'interopérabilité de l'économie digitale, un modèle gagnant - gagnant. C'est seulement en défendant un langage commun que le SCIM pourra atteindre l'ubiquité qu'il lui faut pour transformer et unifier l'écosystème digital. Il est temps que les différences RESTent sur pause.