Les arguments pour séparer la gestion d’identité de la gestion de droits

Ce n’est pas parce qu’un métier formule une phrase que les hypothèses qui la sous-tendent restent valables dans le temps, ou étaient mêmes valables au départ.

Cas de figure: La gestion des identités et des accès ( « Identity and Access Management » ).

L’entrée Wikipedia pour la gestion des identités indique même que la gestion des identités (IdM) et la gestion des identités et des accès (IAM) sont des phrases interchangeable. C’est dommage.

Quel est le problème? Deux concepts fonctionnels, Gestion d’identité et Gestion des accès, ont été fusionnés pour former un acronyme pratique, IAM. Bien que cela puisse sembler logique à certains, ne serait-ce que par habitude, cette fusion a des origines historiques et non logiques.

Cela ressemble un peu à l’ATF, le Bureau américain de l’alcool, du tabac et des armes à feu, qui tire son étrange mandat (et son nom) d’une série de politiques gouvernementales non apparentées, établies au cours de plus de 60 ans.

La beauté du génie logiciel, comparé à d’autres professions, c’est qu’elle est moins liée à l’histoire: si une nouvelle façon de faire voit le jour, et si un nombre suffisant d’ingénieurs est convaincu que la nouvelle façon est meilleure, elle peut rapidement remplacer l’ancienne façon. Nous sommes certes confrontés à des problèmes tels que la rétro-compatibilité, l’adoption utilisateur et les courbes d’apprentissage, mais nos décisions sont rarement guidées par un respect de la tradition. L’émergence de l’informatique cloud, du DevOps et des microservices sont des exemples récents de cette volonté de modifier radicalement nos méthodes afin d’obtenir de nouveaux avantages.

Lorsque les chercheurs du NIST David Ferraiolo et Rick Kuhn ont formalisé le contrôle d’accès basé sur les rôles (RBAC) au début des années 90, le « problème » était strictement humain : le RBAC était initialement décrit comme une amélioration évolutive par rapport aux systèmes discrétionnaires (DAC) et obligatoires (MAC), les méthodes de contrôle d’accès utilisées à l’époque.

Nous avons mis à niveau notre technologie, mais nous avons pris du retard dans la mise à niveau de nos méthodologies et architectures.

Le contrôle d’accès basé sur les attributs (ABAC), formalisé en tant que généralisation du RBAC, constitue une amélioration incrémentale : les rôles ont été remplacés par des conditions booléennes ou des règles de gestion plus expressives. Mais le modèle de l’entité à laquelle des privilèges sont accordés n’a pas été mis à niveau. Dans de nombreux cas réels, cette entité n’est pas un être humain, mais une machine (physique ou virtuelle), une ressource numérique, un logiciel ou un processus en cours d’exécution. Et si les règles métier constituent souvent une amélioration par rapport aux approches précédentes, elles ne représentent plus l’état de l’art.

Repenser l’identité pour le Cloud

La vie numérique – chez soi, au travail, en transit – est en train de transformer notre définition même de l’identité. Laissant de côté les aspects existentiels et philosophiques de cette transformation pour un autre post, voici certaines conséquences pratiques et techniques de nos nouvelles formes d’identité:

  • Représentations multiples. Un grand nombre de personnes ont deux identités en ligne: professionnelle et personnelle. Quelques-uns en ont beaucoup plus – un pour chaque réseau social, par exemple.
  • Bruce Wayne / Botman. De nombreuses tâches machine s’exécutent dans le cloud pour le compte d’un utilisateur (humain). Les services d’automatisation tels que IFTTT et Zapier reposent sur des autorisations mises en cache afin que leurs scripts puissent communiquer avec des services en ligne à la demande de l’utilisateur, en empruntant essentiellement l’identité de cet utilisateur. L’infrastructure cloud (Google Cloud, AWS, Azure) s’appuie sur des « comptes de service » pour résoudre ce même problème.
  • Urbanisme SI hétérogène. Auparavant, les entreprises prenaient des engagements stratégiques forts auprès d’un petit nombre de prestataires informatiques, voire d’un seul écosystème. Dans les premières années de ce siècle, il nous arrivait de décrire une société comme étant « un Microsoft Shop », un autre comme étant « basé sur Mac » ou encore un autre « fonctionnant sous SAP ». L’essor rapide des logiciels en tant que service (SaaS) et des solutions cloud a apporté une plus grande diversité aux grandes et aux petites entreprises; et avec cette diversité, un défi aggravé pour atteindre l’interopérabilité et la cohérence globale. Les cas d’utilisation simples qui commençaient par la question « Qui est cet utilisateur? » ne sont plus simples.

Un pas vers une gestion de droits polyvalente

Si les développeurs n’ont aucune raison de se soucier de la tradition, ils s’intéressent également peu à l’élégance intellectuelle – du moins pas comme fin en soi. L’élégance est privilégié, mais seulement si elle promet un avantage ou bienfait. Par conséquent, séparer la gestion d’identité de la gestion des droits doit produire des avantages concrets, sinon ce n’est qu’un exercice intellectuel.

Avant d’énumérer quelques avantages de cette séparation, il convient de remarquer que la séparation est déjà en cours. Un certain nombre de startups se sont établies dans l’espace de la gestion des identités, avec une prise en charge minimale voire inexistante de la gestion de l’accès, ou avec une gestion d’accès conçue comme une offre distincte (souvent facultative). Quelques entreprises qui réussissent avec ce modèle: Auth0, Dashlane, Okta et OneLogin.

Une fois que la gestion d’accès est disponible en tant qu’unité fonctionnelle distincte, dépendant de l’identité numérique, mais pas intimement liée à celle-ci, il en découle de belles conséquences, entre autres :

  • La gestion des accès transversaux sur plusieurs applications et plateformes. Nous n’en sommes pas encore là, mais dans un avenir proche, vous pourrez exprimer des règles telles que « Geraldine peut modifier le contenu » une fois, et les appliquer en une fois à votre CRM, votre gestionnaire de contenu et vos autres applications SaaS.
  • Contrôle d’accès sensible aux identités multiples. Nous méritons des systèmes qui savent que c’est vous, que vous soyez connecté via SAML, LDAP, Google ou Facebook – mais qui respectent des règles qui accordent des privilèges différents en fonction de la façon dont vous avez démontré votre identité. Le privilège « Modifier ma biographie perso » peut être accordé quelle que soit la manière dont vous avez été authentifié, mais peut-être que le privilège « Ouvrir le sas de la station spatiale » ne sera accordé que si vous vous êtes connecté par une méthode plus blindée.
  • Gestion d’accès multi-entités. Un plan unique devrait prendre en charge la gestion d’accès pour toutes les entités: êtres humains, robots agissant pour le compte d’êtres humains, robots autonomes, serveurs (physiques, virtuels ou conteneurisés), applications / services s’exécutant sur ces serveurs… bref, traiter les entités déléguées simplement comme un autre mécanisme d’authentification. Un tel cadre pourrait fournir une gestion intégrée verticalement, allant des pare-feu de réseau jusqu’à la gestion des autorisations basée sur les rôles humains ou les attributs, sans avoir à recourir à des mesures palliatives délicates telles qu’au niveau de la passerelle API, les fonctions « callback » pour l’OAuth2, ou les « comptes de service ».

Il y a un seuil coûts / bénéfices clair pour la gestion d’accès. Si le système devient trop complexe, il faudra soit des ressources dédiées, dotées de compétences spécialisées, pour le gérer — ce qui pousse son coût de fonctionnement jusqu’à, voire au delà de sa valeur — soit le simplifier à un point gérable, ce qui peut également réduire la valeur globale du système.

Toute modification qui nous permet de « refactoriser » la gestion d’accès afin de réduire ou de maintenir les niveaux de complexité opérationnelle, même lorsque les règles gérées deviennent plus complexes, est une bonne chose.

La séparation de la gestion d’identité et de la gestion d’accès, ainsi que leur mise en œuvre et leur déploiement en tant que deux systèmes distincts et modulaires (quoique interdépendants), constituent un grand pas dans une direction souhaitable.

Photo par  unsplash-logoAlex Iby

Share This