WebAssembly, ça bouge

WebAssembly, quelques nouvelles du front.

Dans un article déjà ancien dédié aux technologies front end, j'abordais la technologie WebAssembly (aka wasm). Et ma conclusion était qu'on allait sans doute voire apparaître de nouveaux langages compilant en WebAssembly, et qu'on développerait de moins en moins avec la purge qu'est javascript (même si les choses continuent à bien évoluer aussi de ce côté)

Pas mal d'eau a coulé sous les ponts depuis, je fais toujours une revue de presse régulière et j'ai noté que les avis majoritairement exprimés sur le net n'allaient pas dans mon sens ; l'analyse était plutôt que javascript resterait le langage de développement dans l'immense majorité des cas et que wasm resterait cantonné à un marché de niche. Soit.

Mais aujourd'hui je tombe sur une news qui me renforce dans ma conviction initiale. Microsoft développe depuis quelques mois, non pas un nouveau langage, mais un outillage (compilateur wasm) et un framework web full stack (qui couvre la partie client et la partie serveur) qui permettent de développer des applications web en C# (le langage de prédilection de Microsoft) : Blazor !

Voilà qui est plus qu'intéressant. Il est certes bien trop tôt pour envisager de démarrer un projet sur cette technologie mais ça me semble être prometteur et indiquer la tendance à suivre en matière de technologies web.

Au passage, il sera possible de compiler en asm.js en attendant la généralisation du support wasm par les navigateurs.

Je vois aussi un autre effet de bord sur le choix des langages de développement. En effet, le langage C# enfonce Java dans pas mal de domaines (le langage est plus moderne ce qui est normal puisqu'il est plus récent et qu'il a pu reprendre le meilleur de ses prédécesseurs, en particulier Java et le génialissime Pascal Objet) à un moment où Oracle semble annoncer que l'usage de Java va devenir payant pour les entreprises (ce sujet est encore un peu flou pour moi, je dois trouver le temps de creuser, je suis surpris de ne pas voir plus de réactions). J'ai beau ne pas être fan des technologies Microsoft, ça donne à réfléchir.

Lien vers la news initiale sur Développez.com : cliquez ici.

Candide et les éditeurs de logiciel

Dans cette série d'articles dédiée à la culture générale en informatique, j'ai essayé de me mettre dans la peau de quelqu'un de novice qui se trouverait conduit à exercer une responsabilité quelconque impliquant la mise en oeuvre de moyens informatiques. Et j'ai essayé de lui donner quelques points de repères. On ne parlera pas ici de technique, ou très peu, mais plutôt des acteurs du secteur, des différents métiers, des tendances, de différents façon d'aborder des projets.

Ces articles n'intéresseront aucunement les professionnels du domaine, ils visent plutôt une population de non informaticiens qui veulent avoir un minimum de compréhension de l'écosystème de l'informatique, et ce pour éviter de se faire dévorer tout cru quand ils iront se frotter au milieu.

Dans cet article, je vais parler d'un type d'acteur incontournable : les éditeurs de logiciel.

Les éditeurs de logiciel.

Leur activité consiste à fabriquer des logiciels qu'ils vont ensuite commercialiser auprès de clients dits "finaux", selon différents canaux de vente et diverses modalités commerciales.

Microsoft pour prendre un exemple connu de tous est un éditeur, il fabrique (développe) la suite Office (Word, Excel, Powerpoint etc) ou Windows 10 pour citer deux produits phares. Puis il vous vend le droit d'installer et d'utiliser le logiciel, ce qu'on appelle une licence utilisateur.

Citons quelques éditeurs incontournables : IBM, Oracle, Adobe, Apple

Les licences d'utilisation

Vous n'achetez pas un produit auprès d'un éditeur, mais le droit de l'utiliser dans le respect de conventions définies. Les conventions étant définies par la licence d'utilisation.

Par exemple, quand vous achetez une licence d'un système d'exploitation (Windows 7, Windows 10 etc) la licence détermine si vous n'avez le droit de l'installer que sur une machine unique, celle sur laquelle vous l'avez installé la première fois (ce modèle de licence est souvent appelé OEM), ou au contraire si vous aurez le droit quand cette machine sera abandonnée (en panne, renouvellement du matériel etc.) de l'installer à nouveau sur une autre machine (souvent appelé licence "boite"). Notez bien que dans les deux cas, une licence ne donne le droit qu'à une seule installation sur un seul poste. Il existe aussi bien sur pour les entreprises des licences en volume qui donnent le droits à n installations.

Dans les deux cas le produit est exactement le même mais le prix est bien différent : la licence, OEM est bien moins chère que la licence "boite". Quand vous achetez un PC de distributeur, il est généralement vendu avec un OS pré-installé sous licence OEM (le nom de la licence, Original Equipment Manufacturer vient de là), ce qui explique que vous n'avez pas le droit, et très généralement pas la possibilité via divers systèmes de contrôle, de réinstaller l'OS fourni avec la machine sur une autre machine : répétons nous bien, vous n'avez pas acheté le logiciel mais uniquement un droit d'usage limité (en l’occurrence à la machine sur laquelle il a été installé la première fois).

J'ai donné l'exemple d'un logiciel "utilisateur" qui est destiné à être installé sur un poste de travail pour être utilisé par une personne (celle qui utilise la machine). Mais les éditeurs commercialisent aussi des logiciels qui par nature sont destinés à être installés sur un serveur et à être utilisés par un nombre variables d'utilisateurs. Ces logiciels sont totalement incontournables et vous en utilisez quotidiennement  : messagerie, base de données, annuaires, serveurs web etc.

Les modèles de licence sont alors bien différents et leur tarif est généralement conditionné par différentes métriques, éventuellement combinées : 

• le nombre d'utilisateurs. Ce peut être par exemple, 10 utilisateurs préalablement identifiés qui sont les seuls autorisés à utiliser le logiciel, ou encore 10 utilisateurs quelconques auquel cas 10 personnes maximum ont le droit d'utiliser le logiciel simultanément peu importe qui elles sont (ce second modèle est plus souple)

• la puissance du serveur. C'est la capacité de traitement du serveur (l'ordinateur, la machine), sur lequel est installé le logiciel, qui va déterminer le tarif. La puissance se quantifie généralement via le nombre de processeurs ou le nombre de cœurs (les processeurs modernes disposent de plusieurs cœurs, le processeur est le composant "englobant" qui est enfiché sur la carte mère, le cœur est le composant englobé utile où se trouve la puissance de traitement). Il existe d'autres systèmes de quantification plus complexes.

• Le volume d'utilisation. C'est l'utilisation du logiciel qui détermine le tarif. Si vous l'installez et n'en faites rien, il ne coûtera rien, si vous l'utilisez abondamment le facture sera en conséquence. Le volume ici encore peut se quantifier de bien des façons qui dépendent étroitement de la fonction du logiciel (pour un logiciel de paye ce sera peut être le nombre de bulletins de paye émis, pour un logiciel de bourse le nombre d'ordres passés etc.)

Il existe sans doute d'autres possibilités, je ne cherche pas à être exhaustif, et de toute façon on peut compter sur les éditeurs pour faire preuve d'imagination en la matière.

Le modèle économique

Il faut bien comprendre le modèle économique des éditeurs.

Ils supportent intégralement le coût de réalisation du logiciel (encore que, ils ont diverses astuces qui leur permettent de s'en faire financer une partie par les clients). Ensuite, ils vendent des licences. Si le produit a coûté 1000 Euros, et qu'ils tarifient une licence d'utilisation mono-utilisateur 10 Euros, une fois qu'ils en ont vendu 100 ils sont à l'équilibre et toute vente supplémentaire est de la marge pure (je simplifie). C'est pourquoi les éditeurs qui sortent des logiciels à succès sont extrêmement riches.

Ceci explique que dans certains contextes concurrentiels où un éditeur veut absolument placer un premier produit chez un client (dans l'optique de placer ensuite le reste de sa gamme), il peut se permettre de baisser considérablement son tarif de base, voire offrir le produit (qui au final ne lui coûte rien une fois amorti). Ceci explique aussi pourquoi les tarifs sont aussi souvent opaques (de nombreux éditeurs ne communiquent même pas de prix public, ou alors ont des systèmes de tarification tellement alambiqués que même eux ont du mal à s'y retrouver). Conclusion : négociez pied à pied et faîtes jouer la concurrence. 

J'ai parlé jusqu'à présent des modes de commercialisation "anciens" tels qu'ils se sont toujours pratiqués, et se pratiquent toujours (fréquemment sous l’appellation "on premise") : vous achetez une licence, vous obtenez une copie du logiciel, vous l'installez  sur vos postes de travail ou vos serveurs, et vous l'utilisez. Mais une tendance très forte est la commercialisation de logiciels en mode SAAS dans lequel le logiciel est mis à disposition sur Internet et facturé selon l'usage. Je vous renvoie pour plus de détail à un précédent article de ce blog dédié à l'informatique dans le cloud. Le modèle économique est un peu différent car l'éditeur vend ici du service en plus d'un droit d'utilisation de ses logiciels (l'exploitation de la plateforme technique sur laquelle est installée le logiciel dont vous louez les services).

Les pièges

Si envisagez l'achat de licences, soyez très prudents. et prenez bien le temps d'étudier les offres en détail. Les éditeurs multiplient les astuces pour vous facturer le plus possible, en multipliant les options incompréhensibles, et les (très) mauvaises surprises ne sont pas rares.

Le dernier sport des éditeurs consiste à réaliser des audits de votre utilisation afin de détecter des cas d'utilisation non couverts et réclamer des sommes exorbitantes, devant les tribunaux si nécessaire. Certains cas n'étant parfois ni interdits, ni autorisés, il peut régner un certain flou artistique et les juges n'étant pas des experts en informatique, hé bien on peut toujours espérer... plutôt que de devoir supporter le risque juridique et devant le coût des procédures juridiques, certains entreprises qui contrairement aux éditeurs ne sont pas assises sur un trésor de guerre et ne disposent pas de bataillons d'avocats spécialisés préfèrent négocier et payer. Les éditeurs sont certes légitimes à défendre leur droit de propriété intellectuelle, mais dans certains cas, on n'est pas loin d'une forme de racket. Deux exemples actuels :

• SAP : qui profite du flou sur les accès par des systèmes tiers aux données gérées par ses applicatifs

• Oracle : qui a profité du rachat de Java (développé par Sun), gratuit depuis toujours, pour ajouter des produits sous licence payante que certains utilisent sans se douter qu'ils sortent du cadre gratuit pratiqué depuis toujours.

L'open source

Il nous faut évoquer le cas des organisations open source. Même si elles ne commercialisant pas toujours les logiciels qu'elle développent, elles n'en mènent pas moins une activité assez largement assimilable à celle d'un éditeur de logiciel "traditionnel" : elles fabriquent des logiciels et les diffusent.

Par ailleurs, certains éditeurs choisissent de diffuser leurs logiciels avec des licences gratuites et open source, et de gagner leur vie non pas par la vente de licences mais par la vente de services connexes ou d'extensions payantes. J'ai déjà assez abordé ces points dans un précédent article vers lequel je vous renvoie.

Les pratiques commerciales de ces acteurs, quand ils sont à vocation commerciale, sont je dirais généralement plus simples à appréhender. Je ne vais pas rentrer dans le détail mais je dirais simplement qu'ici aussi il faut bien étudier l'offre et déceler d'éventuels chausses-trappes (de façon assez générale, l'offre gratuite qui est souvent mise en avant est elle vraiment suffisante, quelle en sera l'impact sur le coût des ressources humaines, à quel moment et à quel coût devrez vous basculer sur un modèle payant en raison de limitations de la version gratuite).

Certaines organisations, de par la nature particulière de leur modèle de développement (équipes mouvantes, distribuées sur toute la planète, sans cadre organisationnel aussi strict que ceux rencontrés dans une entreprise classique), ou de leur activité (plateformes serveurs à l'échelle mondiale traitant des volumes énormes avec de fortes contrainte de disponibilité) sont à l'origine de nombreuses innovations en terme de méthodes de travail, de technologies et d'outils, qui ont largement influencé le milieu informatique.  Les technologies sont fréquemment mises à disposition gratuitement et en open source. Des entreprises tentent parfois de répliquer ces modèles sans vraiment en comprendre les pré-requis. Attention ici à l'effet de mode : si l'adoption de ces pratiques peut se révéler être un superbe levier de productivité ou de développement, il n'y a pas de panacée et ce qui convient parfaitement à une multinationale du web ne sera pas nécessairement transposable dans une entreprise plus modeste et plus traditionnelle.

Les projets d'intégration

La mise en oeuvre d'un logiciel éditeur, que ce soit un logiciel propriétaire ou une solution open source, est un projet informatique en soit. Il peut s'agir d'un petit projet si le travail se limite à l'installation et à un peu de paramétrage (voire uniquement du paramétrage en cas de mise en oeuvre du modèle SAAS), ou d'un projet pharaonique dans le cas par exemple de la mise en oeuvre d'un ERP comme SAP qui implique beaucoup de paramétrage complexe et des développements complémentaires pour s'interfacer finement avec le SI.

On distingue généralement les projets qui visent à déployer et intégrer au SI un logiciel qui fournit des fonctionnalités nativement (on parle généralement de projet d'intégration), et les projets basés sur la mise en oeuvre d'un langage de programmation avec lequel un logiciel "sur mesure" est développé par une équipes de programmeurs spécialisés (on parle généralement de projet de développement spécifique).

Un projet d'intégration est supposé être moins coûteux : le logiciel (ses licences d'utilisation) est vendu en volume et le coût de développement amorti sur de nombreuses ventes, vous ne supportez donc qu'une fraction du coût du produit. A l'inverse en cas de développement spécifique vous supportez seul la totalité du coût de développement.

Ceci n'est cependant vrai que si il y a une forte corrélation entre les capacités du logiciel et les besoins de l'entreprise. L'intégration d'un logiciel du marché inadapté au besoin sera risquée et coûteuse.



Il y a ici deux travers à citer :

• projet d'intégration : il faut bien s'assurer que la couverture fonctionnelle du logiciel est satisfaisante, et accepter dans une certaine mesure d'adapter son mode de fonctionnement aux contraintes apportées par le logiciel. Vouloir faire le contraire est contre nature et conduit fréquemment à l'échec. Les capacités de paramétrage des logiciels et leur capacité à s'adapter à des cas particuliers n'est pas illimitée.

• projet spécifique : il faut accepter de ne pas avoir nécessairement le même niveau de fonctionnalité et de confort d'utilisation qu'avec un logiciel du marché. La raison en est simple : un éditeur peaufine son produit pendant des années et dispose de ressources techniques très importantes, il peut mettre beaucoup de moyens et d'argent sur la table ; à l'inverse une équipe de développement mobilisée temporairement pour un projet dispose de moins de temps, de moins de budget, et souvent de moins de compétences. 

Ne cherchez pas à avoir le beurre et l'argent du beurre, généralement vous n'aurez ni l'un ni l'autre.

Une autre point important à avoir en tête : les éditeurs sont en général peu enclins, dans le contexte de projets d'intégration, à prendre des engagements de résultat : ils savent à peu près ce que leur outil sait faire (ses fonctionnalités, ses capacités à traiter des volumes importants avec des temps de réponse satisfaisant) mais pour autant ils se contentent généralement de promesses.

Ça se comprend parfaitement de leur point de vue car ils ne maîtrisent pas le besoin précis de leur client (et donc la capacité de leur outil à y répondre), ni l'infrastructure matérielle qu'il va mettre en place (les machines seront elles assez puissantes ?), ni leur organisation (y aura  il des personnes formées et disponibles, le projet sera il géré correctement ?). Et plutôt que de prendre des risques liés à ces zones d'incertitudes, ils se limitent à  vendre des licences et à proposer des prestations d'expertises facturées très très cher au temps passé, donc sans engagement de résultat (et par expérience, il n'est pas rare que les compétences des "experts" soient très largement exagérées).

Si le client veut un engagement ferme, il doit se tourner vers une société de prestation de service en informatique qui sera chargée de mener le projet d'intégration, avec une enveloppe budgétaire définie par avance. Dans le cas où le produit ne permet pas de répondre au besoin, c'est l'intégrateur et le client qui payeront les pots cassés, l'éditeur lui sera gagnant dans tous les cas. Même sanction si le logiciel est adapté mais que le projet d'intégration échoue (par la faute du client ou de l'intégrateur, ou des deux). Pour cette raison, il faut se méfier des promesses plus ou moins vagues des éditeurs en phase d'avant vente : ils peuvent parfaitement vous vendre un produit sans être sur qu'il répondra à vos attentes, voire même en sachant que ce n'est pas le cas (et là on est dans la malhonnêteté la plus complète).

Certains logiciels éditeurs n'apportent  que peu, voire aucune, fonctionnalité en eux même, mais fournissent l'ossature technique ou fonctionnelle sur laquelle s'appuyer pour réaliser des développements spécifiques "sur mesure" (par exemple des outil de gestion de processus métiers, ou des outils de gestion de contenu) ; une fine connaissance du produit de la part des informaticiens chargés de la réalisation du projet est alors requise. Il n'est pas inutile de s'assurer de ce point, en demandant par exemple des références d'intégration réussies du produit chez un autre client.

On peut rencontrer des difficultés avec des outils éditeurs très spécialisés et/ou très peu répandus que très peu de personnes connaissent sur le marché, sachant en outre que les logiciels éditeurs sont souvent très peu documentés publiquement. En clair, pour avoir accès à l'information qui permet de juger de la capacité de l'outil, il faut commencer par l'acheter pour avoir accès à la documentation (dans le meilleur des cas) ou au support technique de l'éditeur. Et bien sur si à ce moment là, on se rend compte de certaines limitations dont le commercial de l'éditeur s'était bien gardé de parler, il est trop tard.


Je terminerais cet article par un dernier avertissement.

On constate dans de nombreuses entreprises des tensions entre la fonction informatique (la DSI) et les fonctions métier (les gens qui utilisent les outils informatique pour faire leur travail et faire tourner leur entreprise). Et il n'est pas exceptionnel que des responsables métier (hors de la DSI) décident de court-circuiter les services informatiques et de s'appuyer sur des éditeurs pour mettre en place des outils informatiques. Et l'émergence du cloud et des offres SAAS (location de logiciel facturé à l'usage, installé et exploité dans le cloud par un prestataire externe) ne fait qu'amplifier la chose (il est plus facile de cacher qu'on a signé un contrat avec un éditeur qui a une offre dans le cloud que d'acheter et d'installer du matériel informatique en cachette).

Ce phénomène a d'ailleurs pris une telle ampleur qu'il a un nom (shadow IT, informatique fantôme) et fait même l'objet d'études. Il peut  arriver que ça donne de très bons résultats mais c'est à mon sens une très mauvaise pratique.

A chacun son métier, et les personnes non formées au métier de l'informatique ont d'une part toutes les chances de se faire emberlificoter par des jolies présentations des commerciaux de l'éditeur et le fameux "effet waou", et surtout n'ont généralement aucune conscience des multiples contraintes à prendre en compte dans la mise en place d'outils un tant soit peu critiques (supervision, exploitation, sauvegardes, sécurité ...) ni des coûts associés, ni de la nécessité de considérer l'architecture du système informatique dans sa globalité afin d'éviter de la scléroser et de la rendre ingouvernable au bout d'un certain temps.

Conclusion

Voilà pour ce premier article intitulé "Candide et les éditeurs de logiciel" en référence bien entendu au Candide de Voltaire. J'espère qu'il évitera des déconvenues à certains en remettant quelques pendules à l'heure : un homme averti en vaut deux.

Dans un prochain article, je me pencherais sur les SSII (ou ESN comme on les appelle maintenant). J'essayerai modestement (car le sujet est complexe) de donner quelques clés aux novices afin de mieux appréhender leur mode de fonctionnement et leur éviter de tomber dans les pièges les plus grossiers.

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"...  

Sécurité Vol 3 - Les base en cryptographie - 2

La suite de la série d'article relative au vaste sujet de la sécurité. Nous allons parler de cryptographie et tenter d'apporter les notions essentielles à ce sujet

Précédent article de la série :
Sécurite - Vol 1 : définitions
Sécurité Vol 2 - Les base en cryptographie - 1

L'essentiel

La cryptographie permet tout simplement de transformer (chiffrer) une information pour la rendre illisible, sauf pour celui ou ceux qui dispose(nt) des informations nécessaires pour réaliser l'opération inverse (le déchiffrement) et la rendre lisible à nouveau.

L'opération qui part de la donnée initiale en clair et qui produit la donnée illisible est le chiffrement. La donnée transformée est dîte chiffrée. On utilise aussi souvent le terme cryptage : même si pour les puristes c'est une hérésie, ça semble accepté par le dictionnaire.

L'opération qui part de la donnée chiffrée et qui permet de retrouver la donnée initiale est le déchiffrement. Ici aussi on utilise souvent le terme décryptage mais là c'est carrément une erreur car la sémantique du mot "décrypter" est différente (expliqué plus loin).

Tous les enfants se sont amusés un jour à chiffrer un mot en transformant par exemple MOT en NPU : ici on a naïvement effectué un remplacement de chaque lettre par sa suivante dans l'alphabet. C'est un exemple d'algorithme très basique. On peut le rendre un poil plus complexe en ne remplaçant pas chaque lettre par sa suivante dans l'alphabet, mais par la niéme lettre suivante : si on dit n=2, A devient C, si on dit n=3 A devient D etc.... L'algorithme de chiffrement a ici une donnée supplémentaire qui est la clé de chiffrement.

Toujours avec ce même exemple naïf, la personne a qui est communiqué par exemple OQV (permutation du mot MOT avec n=2) doit savoir que l'algorithme utilisé est celui que nous venons d'expliquer et que la clé vaut 2, faute de quoi elle ne pourra pas déchiffrer le message. Dans la pratique, les algorithmes sont souvent connus et c'est la confidentialité de la clé qui est essentielle.

On voit donc que la clé requise pour le déchiffrement doit être connue du destinataire, et de lui seul si on veut garantir la confidentialité de la donnée : une personne qui intercepterait la donnée chiffrée ne pourrait la déchiffrer sans cela. Dans le cas où la cryptographie est utilisée pour garantir la confidentialité d'une donnée, le secret de la clé est primordial, et la transmission de la clé au destinataire une problématique (il ne faut pas qu'elle puisse être interceptée car sinon tout message qui serait à son tour intercepté pourrait être déchiffré). Nous avons ici parlé de la confidentialité mais nous verrons plus loin qu'il y a d'autres utilisations de la cryptographie.

L'algorithme que nous avons présenté est très simple, trop simple. Il est aisé de deviner que OQV correspond en fait à MOT, en s'appuyant sur diverses techniques s'appuyant par exemple sur la fréquence moyenne à laquelle on retrouve les différentes lettres de l'alphabet dans un texte. Cette opération qui consiste à "casser le code" s'appelle le décryptage, à ne pas confondre donc avec le déchiffrement.

Il existe heureusement des algorithmes, issus de la recherche mathématique, qui sont bien plus complexes et qui ne peuvent pas être percés sans devoir recourir à une puissance de traitement tellement colossale qu'elle est inatteignable d'un point de vue pratique. On a en fait une course à l'armement : du fait de l'augmentation de la puissance de traitement des ordinateurs, de la diminution du prix de ces derniers, et des possibilités offertes par les technologies actuelles de distribuer les calculs sur de nombreuses machines, il devient possible de casser (décrypter) certains algorithme qui doivent dès lors être abandonnés au profit de nouveaux algorithmes. Sachant que la difficulté dépend également de la longueur de la clé utilisée pour le chiffrement.

Symétrique / Asymétrique

Il existe deux familles.

Commençons par la cryptographie symétrique : la donnée est chiffrée et déchiffrée avec la même clé, partagée entre l'émetteur et le destinataire (2 dans notre exemple). C'est la forme la plus ancienne qui existe depuis l'antiquité au moins et qui est simple à comprendre. L'algorithme actuellement utilisé est AES (d'autres ont été utilisés par le passé et sont devenus caduques comme DES)

Mais il existe une forme plus récente qui est la cryptographie asymétrique. On dispose non pas d'une clé unique mais d'un jeu constitué de deux clés appairées. L'une est dite publique et l'autre est dite secrète. L'une sert à chiffrer et l'autre à déchiffrer, et vice-versa. Ce qui est chiffré avec la clé publique nécessite la clé privée associée pour le déchiffrement, et inversement ce qui est chiffré avec la clé privé nécessite la clé publique associée. Comme leur nom l'indique, la clé publique est destinée à être connue de tout le monde tandis que la clé privée ne doit être connue que de l'entité qui a créé le jeu de clé. La famille d'algorithme actuellement utilisée est RSA, c'est cet algorithme qui sécurise les transactions des cartes bancaires (au moins en France).

La cryptographie symétrique vise uniquement à la confidentialité des échanges entre deux correspondants. Elle implique que la clé soit partagée ce qui est une difficulté dans les échanges électroniques. D'une part en cas de stockage de la clé, il faut qu'il soit parfaitement sécurisé mais surtout car la transmission électronique de la clé au cours d'un processus automatisé constitue une faille potentielle : quiconque espionnant le dialogue pourrait intercepter la clé et dès lors la confidentialité ne serait plus garantie.

La cryptographie asymétrique permet bien sur d'assurer la confidentialité mais elle a aussi d'autres cas d'usage. Nous allons en voir trois.

La signature électronique

Dans le cas de la signature numérique, la clé privée est utilisée par le destinataire pour chiffrer un condensat (hashage, cf article précédent) de la donnée à certifier (par exemple une facture électronique ou un contrat).

Le condensat chiffré est diffusé avec la donnée certifiée qui n'a pas besoin d'être chiffrée (sauf si on veut en garantir la confidentialité par ailleurs). La clé publique étant par définition publique (sic), n'importe qui peut déchiffrer le condensat, il n'y a donc pas ici de confidentialité.

Mais par contre, en recalculant le condensat de la donnée initiale et en le comparant avec le résultat du déchiffrement du condensat chiffré, on peut vérifier que la donnée n'a pas été altérée (si la donnée a été modifiée, le condensat sera différent, si le condensat chiffré a été altéré, il ne pourra pas être déchiffré avec la clé publique).

Si le contrôle aboutît, on est certain d'une part de l'intégrité du message (le contrat ou la facture reçu est bien celui qui a été signé) et de l'identification de l'émetteur (il est le seul a disposer de la clé privé qui a été utilisée pour chiffrer le condensat, donc personne ne peut avoir signé à sa place). Ce sont bien entendu deux propriétés indispensables pour pouvoir disposer de signatures électroniques avec une valeur probante au niveau juridique.

Dernier point : pourquoi chiffre on un condensat de la donnée et pas le donnée elle même ? Ce serait plus direct et en outre on aurait du même coup la confidentialité de la donnée transmise. C'est dû aux limitations des algorithmes de cryptographie asymétrique qui ont des limites sur la taille maximale de la donnée à chiffrer et qui produisent une donnée chiffrée trop volumineuse. Un condensat est de petite taille (et de taille fixe) quelle que soit la taille de la donnée initiale.

La messagerie sécurisée

On est en plein dans l'actualité avec le retour du débat sur la sécurité vs la liberté dans nos démocraties modernes. Les techniques de cryptographie utilisées dans les what'sapp et autres applications modernes empêchent (en théorie) l'espionnage de nos communications ce qui est un gage de liberté (vous êtes protégés des grandes oreilles de l'état) qui est détourné par les organisations criminelles ou terroristes. Pour ces raisons, on a régulièrement des démagogues qui surfent sur la peur générée par daech & consorts pour essayer de faire passer des lois liberticides qui limitent les possibilités en matière de cryptographie (limites sur les algorithmes, sur la taille des clés, sur le stockage sécurisé des clés etc.).

Bref, le principe de fonctionnement est simple : vous voulez échanger avec quelqu'un et être sur que personne ne pourra vous espionner ? Votre destinataire calcule un jeu de clé et vous transmet la clé publique avec laquelle vous chiffrez votre message. Seul votre destinataire, qui est en possession de la clé privée, pourra déchiffrer le message. Si la clé privée est à usage unique et n'est pas conservée, et que le message n'est pas stocké, alors personne ne pourra espionner la conversation ni la récupérer ultérieurement sur votre appareil.

HTTPS

Le fameux https qui permet de faire des achats en toute confiance sur Internet...

En fait ce n'est en rien une garantie absolue car les pirates sont très astucieux mais c'est quand même un très bon niveau de sécurité et le compromettre demande quand même des moyens très importants.

Nous parlerons peut être de l'attaque Man In The Middle une autre fois (j'ai prévu de présenter une attaque récente de grande envergure qui a compris un grand établissement financier et qui a trompé tous les utilisateurs malgré l'utilisation de https).

Quand vous initiez une communication en https, le serveur web commence par vous envoyer un certificat SSL. C'est un fichier stocké sur le serveur web qui décrit l'organisation qui gère le serveur web.

Ce fichier est lui même accompagné d'une signature numérique qui permet d'en vérifier l'authenticité (il est signé par ce qu'on appelle une autorité de certification, l'équivalent par exemple du représentant assermenté de l'état qui a délivré et validé votre carte d'identité après avoir vérifié que vous étiez bien qui vous prétendiez). C'est le navigateur qui procède à cette vérification : le certificat est en effet signé avec la clé privée de l'autorité de certification et le navigateur a une base de donnée qui embarque normalement les clés publiques de tous les organismes de certification racine (je passe les détails). Ce sont les mécanismes de signature électronique expliqués plus haut.

Si le certificat est émis par une autorité non reconnue, votre navigateur vous affiche une alerte (site non sécurisé) et vous donne le choix entre continuer ou non, et en général il insiste bien pour que vous n'alliez pas plus loin (plus ça va et plus il faut insister avec les dernières versions de navigateurs). Ce type de problème est, et sera sans doute, de plus en plus fréquent : Google a révélé qu'une autorité de certification importante a été corrompue (des employés ont été corrompus et on délivré des certificats de complaisance, des vraies faux documents d'identité en quelque sorte) et que de façon plus générale elle n'était pas assez rigoureuse dans ses contrôles (pour augmenter sa rentabilité) et à invalidé les certificats émis par cette autorité ; la découverte récente que l'algorithme de hashage SHA-1 n'était plus fiable va provoquer l'invalidation de nombreux certificats dont la signature électronique s'appuie sur cet algorithme.

Ensuite votre navigateur et le serveur se mettent d'accord sur les algorithmes à utiliser : en effet, les navigateurs anciens n'implémentent pas les derniers algorithmes qui sont les plus sécurisés (on va se répéter, raison pour laquelle il faut maintenir vos logiciels à jour).

Ensuite le navigateur calcule une clé de chiffrement -symétrique- à usage unique (clé de session) qui va être utilisée pour sécuriser les échanges ultérieurs. Cette clé de chiffrement est ensuite elle même chiffrée avec la clé publique du serveur. Comment le navigateur connait il la clé publique du serveur ? Elle fait partie des informations présentes dans le certificat SSL. Si vous avez suivi ce qui est dis plus haut, nous venons de solutionner le problème de l'échange sécurisé de la clé dans le contexte de la cryptographie symétrique.

La clé est envoyée au serveur. Il connait (et il est le seul) sa clé privée et il peut donc déchiffrer l'information et retrouver la clé de session. On a utilisé ici de la cryptographie asymétrique.

Dès lors, le client (votre navigateur) et le serveur disposent d'un secret partagée qu'ils vont utiliser pour chiffrer leurs échanges via un bête mécanisme de cryptographie symétrique cette fois ci. Les raisons pour lesquelles on ne continue pas à utiliser la crypto asymétrique sont multiples : ces algorithmes font des calculs mathématiques très complexes qui prennent beaucoup de ressources, ils sont limités en taille etc.

Conclusion (temporaire)

Si vous avez compris tout ça, vous avez les connaissances de base utiles pour comprendre de nombreux aspects de la sécurité informatique. Il reste beaucoup à dire mais l'essentiel est là je pense.

Sécurité Vol 2 - Les base en cryptographie - 1

J'ai pris le temps pour écrire ce second article sur la sécurité mais vieux motard que jamais. J'ai été pas mal occupé et un peu fainéant pour être honnête. Bref, je vais expliquer brièvement les bases techniques essentielles qu'il est indispensable de maîtriser pour pouvoir comprendre ce qui viendra ensuite.

Précédent article de la série : Sécurite - Vol 1 : définitions

Un peu de vocabulaire

Tout d'abord une précision utile. Le langage couramment employé en matière de cryptographie est généralement incorrect. Entre néologismes et mauvaises traductions de l'anglais, la plupart des gens, et j'en fait partie, utilisent des mots qui portent un sens différent de celui qu'ils veulent communiquer, ou qui carrément n'existent pas. Je vous renvoie à cet article très clair sur le sujet : Les mots « crypter » et « cryptage » n’existent pas !.

J'utilise parfois les conventions courantes bien qu'elles soient incorrectes : par exemple "décrypter" au lieu de "déchiffrer". Toutes mes excuses aux puristes.

Hachage

Le hachage est désigné par de nombreux termes souvent dérivés de l'application de ce principe qui est très employé en informatique et en cryptographie. On entendra donc parler de hashcode, d'empreinte, de condensat, de clé de contrôle et d'autres termes encore.

Le hachage est simplement une fonction (au sens mathématique du terme) qui prend en entrée une information quelconque et produit en sortie une donnée qui a des propriétés particulières qui la rendent très utile dans de nombreux domaines.

Le hash a donc des propriétés intéressantes dont nous allons parler rapidement.

Unicité

Deux données différentes en entrée ne produiront jamais un hash identique. C'est la conception de l'algorithme de hachage qui garantit ceci

Si deux valeurs différentes peuvent produire un même hash, on parle de collision, et quand la possibilité d'un tel cas est avérée l'algorithme est abandonné. Ceci s'est déjà produit à plusieurs reprises par le passé ce qui n'est pas sans conséquence. Par exemple, les algorithmes de hachage étant implémentés par les navigateurs pour sécuriser la navigation en https, le fait qu'on découvre qu'un algorithme doit être abandonné et remplacé par un autre implique une mise à jour du navigateur. Voilà pourquoi il est recommandé de toujours utiliser un navigateur récent et à jour pour faire des achats ou toute autre opération sensible en ligne. C'est également pour cette raison qu'il faut maintenir à jour ses systèmes d'exploitation. Actuellement (début 2017) l'algorithme SHA-1 est majoritairement utilisé, or il vient d'être démontré qu'il avait des failles et devait être abandonné au profit d'un algorithme plus robuste (SHA-256 à priori).

Non-réversibilité

Il n'est pas possible de retrouver la donnée en entrée à partir de son hash. Si quelqu'un dispose du hash d'une donnée, il ne peut pas en déduire la donnée initiale.

C'est pour cette raison que les hackers ont constitué des bases de données avec des milliards de chaînes de caractères, et le résultat de l'application des fonctions de hachage courante sur chacune de ces données. Ainsi, en connaissant un hash et l'algorithme avec lequel il a été produit (des données relativement aisées à obtenir), en faisant une recherche dans cette base sur la colonne qui stocke le hash, on pourra déduire la chaîne de caractères initiale si elle n'est ni trop longue ni trop complexe (la complexité de mesurant par le fait de mélanger différentes types de caractères : minuscules, majuscules, caractères spéciaux etc...). On appelle ça une attaque par dictionnaire.

Usages fréquents

Contrôle d'accès par mot de passe

Il est fréquent que les applications nécessitent une authentification de l'utilisateur, ceci afin de vérifier son identité. Une fois l'identité établie, il est possible de déterminer son niveau d'habilitation (les actions qu'il peut entreprendre, les données auxquelles il a accès etc.). 

Le moyen le plus simple et le plus fréquent encore de nos jours de contrôler l'identité d'un utilisateur est de lui demander de s'identifier en saisissant un identifiant (login) et de prouver qu'il est bien le détenteur de cette identité en fournissant un mot de passe. Comme le mot de passe a été défini initialement par l'utilisateur à la création de son compte, et qu'il est censé ne l'avoir communiqué à personne et le conserver secret (en évitant par exemple de l'inscrire sur un post-it collé sur son écran), si le mot de passe fourni correspond, on est certain de l'identité de la personne.

Intuitivement on imagine que l'application en question doit stocker le mot de passe de l'utilisateur quelque part en regard de son identifiant pour pouvoir vérifier le mot de passe. Hé bien non. Il est certes possible de faire ainsi mais c'est une très très très mauvaise pratique et c'est bien souvent interdit. En fait, on ne stocke pas le mot de passe mais uniquement son hash. En comparant le hash du mot de passe saisi avec le hash stocké initialement, on fait la vérification voulue sans devoir stocker en clair le mot de passe (ce qui permettrait à quelqu'un de mal intentionné ayant accès au fichier des mots de passe d'usurper n'importe quelle identité).

Il arrive que des hackers arrivent à voler les fichiers stockant les identifiants et les mots de passe, ou les hash de mot de passe si la sécurité est gérée correctement (ceci dis, si c'était le cas, il n'auraient pas pu voler les fichiers en question). Si les mots de passe sont en clair, ils peuvent directement voler votre identité numérique (s'authentifier sous votre nom et mener des actions qui vous seront imputées).Si ce sont des hash, ils feront une attaque par dictionnaire : si vos mots de passes sont trop simples et trop courts, ils arriveront à leur fin, mais si vous avez défini un mot de passe assez long et mélangeant chiffres + lettres + caractères spéciaux, ils n'arriveront pas à trouver votre mot de passe.

On peut éliminer le risque d'attaque par dictionnaire en utilisant une technique appelée "salage" (salt) : au lieu de stocker le hash du mot de passe, on stocke le hash de la combinaison du hash du mot de passe et d'une chaîne de caractère constante. Il n'y a ainsi plus de lien direct entre la valeur stockée dans le fichier des mots de passe et le mot de passe de l'utilisateur. 

Vous devez comprendre maintenant pourquoi de plus en plus on vous oblige à avoir des mots de passe d'une longueur minimum et avec une certaine complexité. 

Si on ajoute qu'on peut en outre vous obliger à les changer fréquemment, et sans réutiliser des anciens mots de passe, et que vous utilisez de nombreuses applications ayant chacune sa propre liste d'utilisateurs et mots de passe, ça peut rapidement devenir problématique de se rappeler de tous ces mots de passes. Une astuce serait d'utiliser le même mot de passe sur les différentes applications mais d'une part ce n'est pas forcément possible (chaque application imposant des règles de longueur et de complexité différentes), et d'autre part c'est dangereux (le mot de passe volé sur un site donnera accès à tous vos autres comptes sur tous vos autres sites). Une autre astuce consiste à noter tous ces mots de passes et identifiants quelque part... très dangereux aussi car si quelqu'un vole votre fichier, il aura accès à toutes vos identités numériques. Il existe différentes parades dont nous parlerons plus en détail dans un autre article tant le sujet est vaste (en informatique, il existe une discipline spécifique dédiée au sujet, appelée IAM Identity and Access Management) : mise en place de SSO (Single Sign On, on ne s'authentifie qu'une seule fois et une seule identité numérique permet l'accès à de multiples applications), fédération d'identité (un même référentiel utilisateur est utilisé par de nombreuses applications interfacées via des protocoles standards sur le référentiel en question).

Signature électronique

Dans le monde réel, vous authentifiez des documents en apposant votre signature. Il existe un équivalent en informatique qui a la même valeur probante au niveau juridique moyennant le respect de quelques pré-requis.

Nous n'allons pas détailler ce point car nous n'avons pas encore abordé tous les pré-requis. Mais nous pouvons déjà expliquer que la signature numérique est un hash du document qui a ensuite été chiffré par un algorithme de cryptographie asymétrique (rien de compliqué, nous verrons ça dans un prochain article).

Du fait des propriétés d'un hash, on peut vérifier la validité de la signature vis à vis d'un document en recalculant le hash et en le comparant avec la signature numérique (le hash initial qui a été chiffré). Si le document a été modifié, le hash sera différent et la signature invalide pour ce document (par ailleurs, il n'est pas possible de falsifier la signature de par les propriétés de la cryptographie asymétrique)..

Usages courants en informatique

Nous mettons le focus sur la sécurité et n'abordons donc pas toute une catégorie d'usages des fonctions de hachage en informatique (généralement basées sur l'unicité et la moindre taille que la donnée hachée).

Un hash peut servir de somme de contrôle (checksum). L'exemple typique est le téléchargement d'un très gros fichier depuis un serveur web : il y a des risques non négligeables que le fichier téléchargé sur votre poste soit corrompu (un seul octet invalide suffit, si votre fichier fait des centaines de Méga-Octet et est téléchargé depuis l'autre bout du monde et passe par des lignes sous marines et un grand nombre d'équipements réseaux, il n'est pas exceptionnel que des problèmes surviennent). Pour vérifier que le fichier n'a pas été corrompu (et éventuellement de façon volontaire pour introduire un virus dans un programme par exemple, au delà des simples problèmes de communication), vous pouvez généralement télécharger un second fichier (bien souvent le résultat d'un hachage par l'algorithme MD5) : ce second fichier est le hash du fichier téléchargé. Avec l'utilitaire adéquat implémentant l'algorithme de hachage utilisé, vous recalculez le hash du fichier et le comparez avec le hash téléchargé : si ils correspondent, le fichier n'a pas été corrompu sinon vous n'avez plus qu'à relancer le téléchargement).

Conclusion (temporaire)

La sécurité est un sujet relativement complexe : si on essaye de le prendre de front c'est très obscur, mais si on commence par comprendre les briques de base, ça devient assez simple, tant qu'on ne rentre pas dans les arcanes des algorithmes (sinon un très solide bagage mathématique est requis).

Nous venons de voir une première brique, les autres suivront dans quelque temps.

Open source : la base

Depuis longtemps, je constate qu'il y a une assez large incompréhension de ce qu'est le logiciel libre. Du coup, j'ai rédigé un petit article sur le sujet, histoire de dégrossir un peu le sujet.

Free ne veut pas dire gratuit

Je rentre directement dans le lard d'une fausse idée largement répandue. Le mouvement du logiciel libre est à l'origine anglo-saxon et dans la langue de Shakespeare on parle donc de Free Software. Le terme "free" peut avoir différentes traductions dont "gratuit". Cependant, ce n'est pas ce sens qu'il faut retenir ici, mais celui de liberté. Pour ceux qui en douteraient, voici un pointeur sur une saine lecture sur le site de la Free Software Foundation, un organisme qui promeut la diffusion de code source ouvert : https://www.fsf.org/about/what-is-free-software

Un logiciel "free" n'est pas dans le domaine public : quelqu'un en détient la propriété intellectuelle et son usage est soumis à une licence : vous devez respecter les conditions d'utilisation dictées par la licence, vous ne pouvez pas faire ce que vous voulez. Mais la logique qui prévaut à la rédaction de la licence est bien différente que dans le cas d'un logiciel propriétaire, et elle vous accorde beaucoup plus de droits et de libertés.

Un logiciel "free" est donc un logiciel dont vous pouvez, selon certaines conditions qui dépendent de la licence associée, utiliser le code bien sur mais également l'étudier, le modifier pour l'adapter à vos besoins ou encore le copier et le diffuser. C'est là la principale différence avec un logiciel "propriétaire" dont la licence ne vous permet que d'utiliser le logiciel (le code source n'est pas fourni, et quand bien même vous pourriez vous le procurer par décompilation, ce serait illégal) ; si vous constatez un bug, vous ne pouvez pas le corriger, si vous voulez améliorer une fonctionnalité, vous n'en avez pas le droit.

Un logiciel "free" peut tout à fait être payant. C'est d'ailleurs le modèle économique retenu par de nombreux acteurs de l'open source. Quand un tel acteur souhaite, pour des raisons X ou Y, générer des revenus grâce au logiciel qu'il a développé, il le distribue souvent selon deux modèles : une version gratuite assortie d'une licence présentant certaines restrictions qui en rendent l'usage impossible dans un cadre commercial, et une version payante assortie d'une autre licence levant les dîtes restrictions.

Certains acteurs de l'open source ne cherchent pas à se rémunérer (ils ont d'autres motivations, diverses et variées). D'autres proposent des services de consulting ou de support qui seront retenus par ceux pour qui l'outil est un élément critique (qui connaît mieux un produit que son développeur ?). Certains développent des compléments payants autour d'une base gratuite. D'autres enfin détournent quelque peu l'idée généreuse originale et proposent des versions open source très limitées qui n'ont que pour objet de pousser à l'achat d'une version payante (pot de miel).

Pluralité/Complexité des licences

Il n'existe pas un modèle de licence open source. Il en existe des dizaines, réparties en deux grandes familles. Et avec des différences qu'il est essentiel de comprendre

Précision utile : si vous développez un logiciel non commercial et à code source ouvert, vous n'avez probablement pas à vous soucier outre mesure des licences. C'est dans le cadre d'un développement commercial appuyé sur du code logiciel ouvert qu'il convient de prendre quelques précautions sous peine de sérieuses déconvenues, voire de désastre.

Dans les premiers temps de l'open source, de nombreuses fausses idées ont été diffusées, en particulier par les grandes sociétés commercialisant des logiciels commerciaux, afin d'effrayer les entreprises. Il en résulte malheureusement encore souvent des craintes infondées. Il n'est pas exceptionnel que cela constitue un frein à l'utilisation de logiciel libre dans certaines grandes entreprises peu au fait des subtilités à maîtriser. Les choses ont cependant évoluées ces dernières années, même Microsoft s'est mis à l'open source, et de nombreuses entreprises ont adopté l'open source comme levier d'innovation et de performance.

Il nous faut préciser le sens de "commercial" : c'est une application qui est commercialisée, distribuée, dont on peut acquérir un exemplaire. Un développement interne réalisé par une entreprise n'entre pas dans ce cadre. Une application commercialisée en mode SAAS étant non distribuée n'est pas non plus une application commerciale. Toutefois, nous développerons ce dernier point un peu plus loin.

Viralité de la licence

La viralité d'une licence définit le fait que le logiciel développé à l'aide du logiciel soumis à cette licence virale soit lui même obligatoirement à code source ouvert (le terme exact est copyleft).

En gros, si vous utilisez pour votre projet commercial, une librairie ou un framework open source qui a une licence virale, vous avez l'obligation de fournir votre code source. Du coup, n'importe qui peut prendre le fruit de votre travail et l'utiliser à son tour. Ce qui pose bien évidemment plusieurs problèmes majeurs : n'importe qui peut monter un commerce concurrent au votre avec un avantage économique majeur lié au fait qu'il n'aura pas supporté le coût de l'investissement initial (le développement du logiciel). 

C'est à ce type de licence virale (licences GPL principalement) que recourent les acteurs open source qui veulent générer des revenus par de la vente de licence. Si vous ne voulez pas diffuser votre code source et que vous voulez utiliser leur code, vous devez passer par une distribution payante assortie d'une licence non virale (licences BSD, ASF, MIT, MPL ...).

Conclusion ; il est nécessaire en cas de projet commercial de bien examiner la licence de toutes les librairies, frameworks, et autres éléments logiciels open source que vous prévoyez d'utiliser afin de vérifier leur viralité. 

Précision importante : un développement spécifique interne ne sera pas distribué et ne constitue pas un logiciel commercial, même si il est commandé et acheté à un prestataire externe.

Mode SAAS

Si vous ne savez pas ce qu'est le SAAS, vous pouvez lire cet article : Formes et intérêts du Cloud computing. Sinon, en résumé lapidaire, c'est la commercialisation d'une application mise à disposition sur Internet sur un modèle de location (facturation à l'usage).

La commercialisation d'application en mode SAAS étant une tendance assez lourde, il y a une facilité à contourner les règles du copyleft (utilisation à des fins commerciales de produits open source sous copyleft sans partage du code produit, ce qui est contraire à l'idée de partage de la connaissance derrière le mouvement open-source).

En réaction est apparue la licence AGPL qui ajoute des clauses spécifiques pour prévoir ce cas.

Conclusion

Le recours aux logiciels open-source amène de nombreux avantages mais comporte également quelques risques. Toute médaille à son revers. Si l'éditeur décide de changer de stratégie et de changer son modèle de licence à partir d'une certaine version, que ferez vous ? Si vous découvrez en cours de route que les fonctions incluses dans la version gratuite sont trop limitées et qu'il vous faut la version payante, que se passera il ? Si le développement du produit est interrompu, quelles conséquences pour vous ?

La gratuité, fréquente, du logiciel ne doit pas faire négliger les autres aspects du choix.

Chaque situation est différente et une réflexion doit être menée au cas par cas. Par exemple, dans le cas d'un développement spécifique, un des rôles de l'architecte applicatif est de faire les bons choix au regard du contexte, dans le cas d'un projet SI, il ne faudra pas négliger les coûts de montée en compétence des personnels de l'IT. Toute brique technique open source occupant un rôle central dans une architecture SI ou simplement applicative doit être envisagée sous de nombreux angles.

Les compétences techniques ne sont pas suffisantes pour une prise de décision éclairée. Des aspects juridiques et stratégiques sont à considérer.