Sécurité Vol 4 : Gestion des identités

Dans ce 4éme article consacré à la sécurité, nous allons effleurer un sujet particulièrement riche et complexe : la gestion des identités. 

Précédent article de la série :

Sécurite - Vol 1 : définitions (DICP)

Sécurité Vol 2 - Les base en cryptographie - 1 (fonctions de hashage)

Sécurité Vol 2 - Les base en cryptographie - 2 (cryptographie)

Posons le problème : pour protéger les données des accès indésirables (cf DICP), les applications en contrôlent l'accès. Nous avons deux problématiques :

• l'authentification qui est le processus qui permet d'identifier formellement une entité. Le terme est volontairement flou (abstrait en fait) mais il désigne le plus souvent une personne humaine, un utilisateur qui se connecte sur une application. Mais ce peut être autre chose, par exemple une application qui se connecte dans le cadre d'un traitement automatisé. 

• l'habilitation qui est le processus qui vise à déterminer, une fois l'entité authentifiée, la nature et l'étendue de ses droits d'accès. Peut elle lire telle donnée, modifier telle autre, déclencher tel traitement etc.

Il est bien important de comprendre que ces deux problématiques sont gérées distinctement tout en étant liées. On ne peut habiliter une entité que si et seulement si elle a été préalablement authentifiée. 

Le plus souvent l'authentification est basée sur un couple login (identifiant, username, adresse mail etc) / mot de passe. Le login constitue l'identité numérique de l'entité qui se connecte, le mot de passe est ce qu'on appelle en sécurité un challenge : son rôle est de challenger l'affirmation de l'entité qui se présente en prétendant être untel (telle identité numérique, ou tel login si vous préférez) : ha oui, comme ça tu prétends être  "mimiledugenou@gmail.com" ? Bien, vu que je suis en charge de contrôler les accès, il se trouve que j'ai le mot de passe du gars en question (rappel : en fait normalement on n'a pas le mot de passe mais un hachage du mot de passe mais je simplifie volontairement ici). Donc, donne moi le mot de passe, si c'est le bon c'est que (normalement, sauf si le mot de passe a été usurpé) tu es bien qui tu prétends être. 

Alors de plus en plus, le mot de passe est remplacé par un autre type de challenge (données biométriques comme une empreinte digitale ou de l'iris) mais ça reste exactement le même principe. Et parfois, pour renforcer la sécurité d'autres challenges sont ajoutés : par exemple un code temporaire est envoyé par SMS sur le numéro de portable associé à l'identité numérique. C'est ce qu'on appelle logiquement la double authentification (2FA) ou l'authentification multiple. Il existe différents mécanismes, l'envoi de code par SMS étant probablement le plus répandu.

Quel que soit le mécanisme de challenge, il est nécessaire que les informations sur les identités numériques et les données associées soient stockées quelque part : données personnelles (nom, prénom, mail, numéro de téléphone etc.) et les données relatives au challenge. Il est donc nécessaire d'avoir un référentiel utilisateur.

Alors historiquement que s'est il passé (la plupart du temps) ? Une entreprise met en place une première application, elle créé un référentiel des utilisateurs de l'application, par exemple via des tables dans la base de données de l'application. Puis elle crée un accès à chaque personne de l'entreprise qui doit utiliser l'application, avec les habilitation adaptées à son usage et à son niveau de responsabilité. Puis vient une seconde application avec donc un nouveau référentiel utilisateur. Puis une troisième application, puis une quatrième etc.

On voit qu'au bout d'un moment, le malheureux employé qui utilise 5 applications doit retenir 5 logins et passwords associés, plus le login qui lui permet d'ouvrir sa session windows, plus celui qui lui permet d'utiliser la messagerie etc. On ajoute à ça, qu'on l'oblige à changer régulièrement ses mots de passes, et qu'on lui interdit les mots de passes trop simples à deviner ou à cracker (règles de longueur minimale et de complexité) et ça se finit en collection de post-it collés sur l'écran ou vaguement cachés dans le tiroir du bureau. Et du coup, plus de sécurité !

Il a donc fallu trouver des réponses. Alors, diverses réponses ont pu exister mais je vais aller directement à ce qui se fait le plus couramment aujourd'hui.

Dans un premier temps, l'entreprise crée un référentiel utilisateur centralisé unique : toutes les plateformes techniques proposent un outil de cette nature, si le SI de votre entreprise est géré sur une plateforme Microsoft ce sera Active Directory, si vous être sur une plateforme Unix ou Linux ce sera un service d'annuaire quelconque. Tous ces services (Microsoft AD inclus) implémentent un protocole appelé LDAP qui permet de les interroger et mettre à jour de façon normalisée. C'est un standard.

En deux mots, un annuaire LDAP est constitué d'une série d'entrées, chaque entrée étant caractérisée par un type de donné normalisé décrivant ses attributs, les entrées étant organisées de façon arborescente (ou hiérarchique). Chaque entrée est identifiée par le chemin parcouru depuis la racine de l'arbre pour l'atteindre (chaque nœud disposant d'un attribut qui par convention en constitue l'identifiant). Un annuaire offre des accès très rapides en lecture et est peu optimisé à l'inverse pour les accès en écriture. Etant donné qu'il centralise beaucoup de données, il est généralement redondé afin de ne pas constituer un SPOF (single point of failure) ; dans les organisations un tant soit peu complexe, on a souvent plusieurs annuaires (avec des mécanismes de réplication ou encore de chaînage dynamique pour permettre de répartir les entrées sur plusieurs annuaires reliés). La façon d'organiser les entrées au sein d'un annuaire est une décision délicate qui doit être pesée avec soin, c'est un domaine d'expertise spécifique (un de plus), et les projets de mise en oeuvre d'un annuaire sont réputés pour leur difficulté et leur taux d'échec élevé (souvent liés à des problèmes organisationnels dans l'entreprise).

Premier avantage, tous les outils classiques fournis avec votre plateforme technique (messagerie, agenda partagé, répertoires partagés etc.) sont nativement implémentés pour savoir s'appuyer sur cet annuaire centralisé (ils sont configurés de façon adéquate par votre service informatique) ce qui explique que, normalement, votre login système vous permet d'utiliser de façon transparente, sans devoir vous authentifier à nouveau, la messagerie, l'agenda partagé etc., dès lors que vous avez ouvert une session de travail sur votre ordinateur. Gros ouf de soulagement.

Second avantage, les programmeurs de vos applications spécifiques vont progressivement modifier les applications pour qu'elles se basent sur le référentiel utilisateur centralisé en s'appuyant sur le protocole LDAP (c'est une tâche relativement simple) ; pour vous permettre d'utiliser partout le même couple login/password. Second ouf de soulagement. Fini les post-it partout.

Mais, que constatons nous ? Certes, nous utilisons partout la même identité mais il est néanmoins nécessaire de devoir s'authentifier auprès de chaque application spécifique (saisir le login / password). Or, ce n'est pas le cas pour les outils fournis avec le système (messagerie, agenda etc.). Pourquoi donc et comment améliorer encore ceci ?

En fait votre système d'exploitation fournit un mécanisme de SSO, et ce mécanisme est implémenté (et configuré par votre service informatique) par les applications standards. SSO ça veut dire Single Sign On, authentification unique en bon Français. L'idée est qu'une fois que vous vous êtes authentifiés initialement (généralement en ouvrant une session de travail), le système note vos informations d'identité quelque part et les fournit automatiquement aux autres applications que vous démarrez. Et si ces applications implémentent le mécanisme de SSO en question, elles récupèrent automatiquement votre identité et ne vous la redemandent plus. Sous Windows, le mécanisme en question s'appelle Kerberos, et il est bien sur implémenté par tous les outils fournis par Microsoft (agenda partagé, messagerie etc.). Il est également présent sur les systèmes Unix.

Par contre, vos applications métiers n'implémentent pas (encore) ce protocole. D'où la nécessité de les modifier à nouveau pour implémenter ce mécanisme. Cependant, ceci n'est pas si courant pour diverses raisons que j'ignore mais probablement dues à des difficultés techniques à implémenter le support Kerberos. Enfin, les entreprises n'utilisent pas que des applications développées spécifiquement, elles utilisent également des logiciels fournis par des éditeurs : si ces derniers n'implémentent pas le support, vous ne pouvez pas y faire grande chose (vous n'avez généralement pas accès au code source, sauf logiciel open source mais c'est encore une autre histoire).

D'autres solutions de SSO existent qui ne sont pas liées à la plateforme technique utilisée, et qui peuvent être supportées plus facilement par vos développements spécifiques ou par vos logiciels éditeurs. La plus connue est probablement CAS même si plus récemment bien d'autres outils sont apparus qui partagent avec CAS, et en opposition avec Kerberos, la faculté à étendre les capacités de SSO au delà des frontières de l'entreprise (ce qu'on appelle parfois le web SSO). Une des difficultés quand on aborde ce domaine est la multitude de protocoles et de standards concurrents qui sont mis en oeuvre par ces différentes solutions : ils ne couvrent pas tous les mêmes problématiques, se recoupent, sont parfois corrélés, existent en différentes versions très différentes... Nous en parlons brièvement un peu plus loin.

Alors pourquoi le "web SSO" ? Hé bien car de nos jours les entreprises utilisent fréquemment des applications qui sont hors de leurs murs (hors de leur réseau informatique) : d'une part des applications dans le cloud qui sont louées en mode SAAS (voir cet article sur le cloud computing si ça ne vous parle pas), et d'autre part des applications mises à disposition par des partenaires commerciaux (clients, fournisseurs) dans le cadre de partenariats.

Ce constat nous amène maintenant à aborder une problématique importante : les mécanismes d'authentification, qu'ils implémentent ou non un mécanisme de SSO, s'appuient sur un référentiel utilisateur (annuaire LDAP le plus souvent). Or, ces référentiels utilisateurs il faut les gérer et les maintenir à jour ce qui d'un point de vue organisationnel n'est pas une mince affaire. Des salariés sont embauchés, d'autres sont mutés, d'autres enfin quittent l'entreprise. Et n'oublions pas le recours massif aux CDD, intérimaires, stagiaires et autres employés précaires.

En matière de sécurité cette gestion est critique : laisser des accès à un salarié licencié, c'est prendre le risque d'actions malveillantes et en tout état de cause un trou dans la sécurité, c'est exactement comme laisser la clé du bureau. Et encore pour le moment, nous n'avons parlé que de référencer les identités numériques, mais il faut également gérer leurs habilitations. Enfin, si jusque présent nous nous sommes focalisés sur une vision purement interne, le fait d'utiliser des applications externes (louées en SAAS ou mises à disposition par un partenaire ) et plus encore de donner accès à des personnes externes (partenaires commerciaux qui accèdent de l'extérieur de l'entreprise à vos données via des applications que vous leur mettez à disposition) démultiplient la complexité.

Imaginons, que vous donniez accès à un partenaire commercial, à une application de votre SI. Vous allez devoir créer, puis gérer, des comptes utilisateurs (on en revient à la multiplication des login/password et aux fameux post-it). Première possibilité, vous faîtes le nécessaire sur demande de votre partenaire : ça fait du travail en plus, et surtout si vous n'êtes pas prévenu du départ d'un collaborateur de l'entreprise partenaire qui avait des accès, vous ne désactiverez pas, d'où trou de sécurité. Ensuite, vous avez quand même beaucoup moins de maîtrise quand au respect des règles de sécurité internes à votre société, de la part de salariés externes, encore un souci de sécurité : si ça se trouve votre partenaire n'a pas de politique de sécurité, ni de RSSI (responsable de la sécurité), leurs postes de travail sont pleins de virus ou ouverts à tous vents aux hackers, les salariés surexploités, ou en conflit avec leur direction et revanchards, les départs mal gérés etc... On le voit, une certaine relation de confiance doit être instaurée quand des accès externes sont accordés. Seconde possibilité, vous ouvrez à votre partenaire l'accès à l'outil qui permet de gérer les identités. Ce n'est pas terrible non plus pour de nombreuses raisons, et dans les deux solutions, vous polluez votre annuaire LDAP avec des données externes, et en outre sa structure n'a peut être pas été pensée pour ça à l'origine.

Une solution serait que les salariés de vos partenaires s'authentifient avec leur compte habituel, celui qu'ils utilisent au sein de leur entreprise :

• vous n'avez plus à gérer les identités numériques pour votre partenaire (il les gère selon ses processus habituels), 

• les utilisateurs ne voient pas se multiplier leurs identifiants. 

Cette solution existe, ça s'appelle la fédération d'identité, et on peut le voir comme une extension du modèle SSO.

Nous avons évoqué le contexte professionnel jusqu'à présent. Mais la fédération d'identité permet également à de nombreuses applications web ou sur smartphone de s'appuyer sur des identités gérées par des grands acteurs du web : Facebook, Google, Twitter etc.

Vous avez surement remarqué que de plus en plus de site vous permettent de vous identifier avec un compte FaceBook par exemple au lieu d'imposer la création d'une n-iéme identité. C'est une tendance forte.

Le service public investit massivement sur Internet depuis quelques années afin de faire des économies et offrir des services en ligne aux citoyens que nous sommes, avec pas mal de belles réussites. Du coup, il y a une multitude de sites et de login à gérer... Qu'à cela ne tienne, l'état a déployé FranceConnect qui va fédérer progressivement l'ensemble de ses services numériques autour des 3 référentiels utilisateurs gérés par les impôts  (impots.gouv.fr), le régime général de la sécurité sociale (ameli.fr) et La Poste (tout citoyen à une adresse mail, et un identifiant, fourni par La Poste).




Si l'idée de base de la fédération d'identité est simple, la mise en oeuvre est un poil plus compliquée. En effet, comme dans la mise en oeuvre du SSO, il va falloir adapter les applications afin qu'elles sachent dialoguer avec ce outil (ou on en mettra un en place, ou on choisira de s'appuyer sur un outil fourni sur Internet ou par un prestataire spécialisé). Or, si dans le cas de la mise en oeuvre d'un SSO interne vous êtes seul maître chez vous, dans le cadre d'une collaboration avec des partenaires externes, il va falloir s'entendre sur la façon de faire, et établir un protocole commun. En outre ce protocole doit être particulièrement sécurisé car les échanges vont passer par internet qui est un réseau public.

Malheureusement, il n'existe pas qu'un seul standard, ils sont divers et issus de différents acteurs. Ce qui n'est pas sans compliquer la vie des développeurs du fait de l'absence d'interopérabilité (il faut prendre en charge n protocoles), Il est assez difficile de s'y retrouver sur le sujet si on n'est pas expert (ce que je ne suis pas), mais bon, je me lance et j'essaye de faire une synthèse correcte.

SAML : c'est un ensemble de normes qui définissent le format des données échangées et la façon de les sécuriser (mise en oeuvre de techniques de cryptographie), et une série de protocoles pour différents cas d'usage incluant le SSO et la fédération d'identité (mais pas que, plus généralement c'est en rapport avec diverses problématiques de sécurité informatique). C'est basé sur SOAP et donc sur XML et différents protocoles de la famille des Web Services. C'est normalisé par l'OASIS. Différents outils implémentent SAML, parmi lesquels on peut citer Shibboleth.

JWT : c'est une norme qui définit un format de donnée et la façon de les sécuriser (mise en oeuvre de techniques de cryptographie). JWT ne traite pas du tout de SSO ou d'autre cas d'usage. C'est uniquement une brique qui est utilisée dans le cadre de la mise en oeuvre de ces cas d'usage, définie par d'autres protocoles. A l'inverse de SAML, XML n'est pas du tout utilisé, JWT a une approche plus moderne basée sur les techniques actuelles utilisée en développement Web, avec notamment la mise en oeuvre de JSON, d'appels REST et l'utilisation d'URLs. Pour ceux qui sont intéressés je recommande la lecture du JWT Handbook, c'est très bien écrit et pas trop ardu.

OAUTH 2 : c'est un protocole lié à la problématique de gestion des habilitations. Quand vous utilisez une application sur votre smartphone  ou sur le web et que vous choisissez de vous identifier avec votre login facebook (par exemple, ou Google+ ou Linkedln etc.), un écran vous demande généralement si vous acceptez la diffusion de certaines de vos info personnelles. Hé bien c'est Oauth qui est mis en oeuvre. Nous le citons car il est également impliqué dans les mécanismes qui nous intéressent (Web SSO, fédération d'identité)

OpenID Connect : c'est une surcouche au dessus de Oauth 2 qui ajoute la prise en charge du SSO et de la fédération d'identité. C'est une évolution de OpenID (désormais caduque). Un exemple de société implémentant un service d'authentification compatible est Google. Ceci permet aux applications implémentant le protocole d'authentifier leurs utilisateurs avec leurs login Google+.

WS-Federation : famille de protocole Microsoft. Basé comme SAML sur les technologies XML et SOAP.

Allez, j'ai trouvé un petit article sympa et à jour (ce qui n'est pas si fréquent car ces technologies ont énormément évoluées ce qui peut créer de la confusion) qui peut être intéressant à lire en complément : ici.

Conclusion

Il y aurait encore énormément de choses à dire, la gestion des identités est une discipline très riche et rien que l'étude des différents protocoles liés aux problématiques d'authentification et de gestion des habilitations (sujet que nous avons à peine évoqué, ici aussi il y aurait beaucoup à dire) peut demander des journées de travail acharné. Mais vous devez déjà avoir compris que l'étude de cette problématique ne s'improvise pas et nécessite le recours à des experts du domaine.

Pour l'anecdote, il y a quelques années j'intervenais en tant qu'architecte sur un gros projet ecommerce pour un très grand compte dans le domaine du luxe. Alors que ma zone de confort et ma compétence principale étaient l'architecture applicative, je me suis trouvé embarqué malgré moi en réunion sur des sujets d'architecture du SI (la confusion entre les disciplines est fréquente alors que ce ne sont pas les mêmes compétences du tout). Et un interlocuteur m'a demandé si je connaissais SAML mais sans détacher les lettres. J'ai mal compris (et en outre je ne connaissais pas SAML) et j'ai répondu "Samuel ? Non, je ne vois pas qui c'est"...