lundi 22 mai 2017

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

dimanche 23 avril 2017

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.



dimanche 26 mars 2017

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.

lundi 27 février 2017

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.

lundi 23 janvier 2017

La java des loggers

Petite plongée rapide dans le merveilleux monde du logging Java.

Les loggers

Dans le monde Java, on a pléthore de libraires de logging : 
  • LOG4J est la solution « legacy », elle existe depuis très longtemps et est largement adoptée. 
  • La version 1.4 du JDK a introduit le Java Utility Logger, JUL de son petit nom, qui est assez peu employé du fait de son arrivée tardive et de ses capacités moindres. 
  • Plus récemment, on a vu apparaître logBack qui est à mon avis le meilleur des trois et qui est celui à privilégier de nos jours, on peut le voir comme une version largement améliorée de LOG4J (qui date un peu et comporte quelques bugs gênants en utilisation avancée). 
  • Il en existe d’autres encore.

Du coup, l’architecte logiciel doit faire un choix… mais les architectes n’aiment pas se mettre à la colle avec une dépendance quand ils peuvent l’éviter. Pour cette raison, il existe des façades permettant d’abstraire l’API de log. En utilisant ces façades, on ne dépend plus d’une API de logging particulière et le client de l’API peut déployer celle qu’il préfère, il dépendra par contre de la façade. Mais on n’aura plus accès aux spécificités de tel ou  tel logger non exposées par le façade.

Les façades

Où ça se complique un peu c’est qu’il existe deux façades. La plus ancienne est Java Commons Loggin, JCL de son petit nom. Elle est largement utilisée car c’est la première à être apparue. Mais elle pose quelques problèmes dont on s’est aperçu au fil du temps, et une autre façade est apparue, Simple Logging Facade For Java, SLF4J de son petit nom. C’est aujourd’hui indubitablement le meilleur choix.

Spring utilise JCL du fait de son ancienneté, et le conserve pour des raisons de compatibilité ascendante même si ça ennuie manifestement ses développeurs (la documentation est très claire sur ce point, aujourd’hui ils prendraient SLF4J sans hésitation). Hibernate qui est plus récent s’appuie sur SLF4J, probablement comme tous les frameworks ou API récents.

Quelle différence entre JCL et SLF4J ? 

La principale est la façon dont ces façades déterminent au bootstrap le logger concret à utiliser. 

JCL s’appuie sur un mécanisme dynamique de configuration et essaye de deviner quel est le logger à utiliser. Or ceci pose des soucis dans les environnements complexes avec de nombreux classloaders (typiquement un serveur d’application JEE). 

A l’inverse SLF4J s’appuie plus prosaïquement sur une dépendance qui peut être satisfaite par diverses implémentations concurrentes, la première trouvée dans le classpath étant nécessairement la gagnante (ça s’appelle un binding dans la terminologie SLF4J) : c’est plus simple et plus facile à maîtriser, par contre on a une contrainte à gérer au niveau de l’assemblage de l’application en prévoyant bien la dépendance voulue.

Regardons de plus près comment c’est implémenté. 

Une rapide incursion dans la documentation et le code source nous permettra de mieux comprendre.

L’API SLF4J fournit une interface Logger qui matérialise le concept de logger dans le code client, et une factory associé LoggerFactory. Cette factory s’appuie en interne sur une implémentation d’une interface ILoggerFactory pour fabriquer les loggers concrets. L’implémentation est déterminée au premier appel (pattern singleton) en parcourant le classpath à la recherche d’une classe org.slf4j.impl.StaticLoggerBinder (qui bien sur implémente l’interface ILoggerFactory). Cette classe n’est pas fournie dans le composant slf4j-api mais par un des « bindings SLF4J».

Donc selon le binding déployé, on obtient une implémentation différente qui renverra soit une implémentation directe de  l’interface Logger (cas du logger logBack), soit un adapter quelconque vers un framework tiers. Ainsi, un adapter vers LOG4J routera les appels sur l’interface Logger, par simple application du polymorphisme, vers les classes de LOG4J ; un adapter vers JUL fera de même mais vers les classes du JDK.

Si vous êtes attentif, vous devez vous demander comment on peut compiler SLF4J vu qu’il a une dépendance sur des classes qui ne sont pas dans son code source et dont il existe une multitude d’implémentation. Et comment il se fait que si on oublie de déployer le binding, on ne se prend pas une ClassNotFoundException mais un joli message bien travaillé. La réponse est bien entendu l’utilisation des mécanismes de réflexion (qui permettent de référencer une classe de façon dynamique).

Voici pour le mécanisme de base de SLF4J qui se base donc sur le mécanisme de classloading java pour obtenir de façon totalement agnostique une implémentation. C’est en quelque sorte du lazy binding, le binding entre la façade et le logger concret est effectué au runtime.

JCL fournit une interface Log qui a exactement le même rôle que l’interface Logger dans SLF4J, et bien sur une factory associée LogFactory. LogFactory est une classe abstraite et l’implémentation par défaut est LogFactoryImpl qui fait partie de JCL. Contrairement à SLF4J, cette factory ne délègue pas le job à une classe tierce déterminée au runtime, mais fait le travail elle-même via un algorithme de découverte dynamique (voir la javadoc de la classe org.apache.commons.impl.Log.LogFactoryImpl  pour le détail).

Rappel rapide des principes de fonctionnement

Rappelons rapidement le mécanisme de base : une application qui veut loguer obtient un logger via l’appel à la factory de l’API puis utilise les méthodes de cet objet pour loguer des messages avec un niveau associé (debug, info, error …). A un logger est associé un niveau de log (tout log de niveau inférieur produit avec ce logger sera ignoré) et un éventuellement un ou plusieurs appenders. Un appender est chargé d’écrire le log (dans un fichier, sur une socket, dans une base de données …), et accessoirement dispose également d’un niveau de log.

Un logger correspond basiquement à une chaîne de caractère organisée de façon hiérarchique à la façon des noms de domaines ou des noms de package (x.y.z). De ce fait tout logger à un père (x.y est le père de x.y.z et a comme père x, qui a comme père « root »). Quand on logue sur un logger et qu’il n’a pas d’appender associé, c’est celui de son père qui va jouer, s’il n’en n’a pas non plus ce sera le grand-père etc. jusqu’au sommet de la hiérarchie appelé rootLogger. Et c’est généralement sur le rootLogger qu’on branche un appender (on peut aussi en brancher sur les niveaux inférieurs par exemple pour séparer les logs par couche applicative, ou par brique technique, ou pour surveiller plus particulièrement le comportement d’un composant. On est ici sur des choix de design effectués par l’architecte logiciel). 

La configuration de quel appender est associé à quel logger (et tous les autres éléments de configuration comme les level ou les formats des messages) peut se faire de façon programmatique via l’API du logger (directement, pas de couche d’abstraction de ceci dans les façades) ou plus généralement via un fichier (properties ou XML).

Cohabitation JCL / SLF4J

Un souci survient quand on a dans une application diverses briques qui utilisent pour certaines JCL et d’autres SLF4J, si on veut regrouper toutes les écritures de logs dans un même fichier par exemple.

Imaginez que vous avez dans votre application des composants basés sur JCL et d’autres sur SLF4J. Il faut vous assurer que ces deux composants vont utiliser les mêmes loggers pour éviter d’avoir des appenders écrivant des logs de façon concurrente sur des canaux distincts. Et ici commencent les difficultés… 

Alors, je ne vais pas faire ici le tour de la question, ce serait un peu long et ce n’est pas mon objet dans cet article mais si vous avez compris ce qui est exposé plus haut vous devez comprendre qu’il faut déjà s’assurer que les deux factory de log concurrentes (celle de JCL et celle du binding SLF4J) vont s’appuyer sur la même API de log. 

Puis pourront venir des problèmes liés au fait que les classes des API de logging pourront éventuellement être chargées par des classloaders différents, et là ça devient assez compliqué car les mécanismes en question sont spécifiques par exemple au serveur d’application utilisé, à sa configuration, à sa version, et à la façon dont les APIS sont intégrées.

Bien, je vais maintenant vous donner une bonne nouvelle. Ce n’est pas la panacée absolue mais ça permet de simplifier la problématique : SLF4J fourni un mécanisme qui permet de rediriger les logs produits par JCL vers SLF4J, et de là vers l’API de logging bindée. C’est un bridge JCL-SLF4J. Et nous allons étudier rapidement son principe de fonctionnement, juste pour le fun. Ca ira très vite car c’est en fait très simple, et très crade. Mais pourquoi crade ?

En matière de design des systèmes selon le paradigme objet, il existe des grands principes, il en existe même des chiées, parfois contradictoires les uns avec les autres, mais c’est là le travail de l’architecte de privilégier tel ou tel principe selon ses priorités. Et ici on viole brutalement un des principes les plus sacrés, c’est plus du hack qu’autre chose à mon sens, m’enfin si c’est brutal il faut reconnaître que c’est efficace. Et il faut relativiser, pour avoir étudié en détail quelques frameworks open source ou interne aux API du JDK (tiens au hasard, JAAS, le framework de sécurité de la plateforme java), je peux témoigner que nos grands gourous ne se privent pas de prendre des raccourcis, dans le genre « faîtes comme je dis, pas comme je fais ». Ceci dit, quand on veut faire des choses totalement génériques, le paradigme objet comme le langage Java atteignent leurs limites, et parfois le design de certains composants ne laisse pas le choix. Ce n’est pas un hasard s’il existe des langages dynamiques, et si le JDK lui-même embarque des capacités de scripting.

Bref, le bridge JCL over SLF4J ré-implémente tout simplement l’API JCL. Oui, vous avez bien lu, il écrase les classes JCL publiques par les siennes (même classes, même packages). A partir de là, c’est un jeu d’enfant de rediriger les appels vers les API SLF4J, la suite vous la connaissez. Bien sûr, pour que ça fonctionne il faut ici aussi veiller au grain lors du déploiement ; le jar du bridge doit être avant le jar JCL dans le classpath (le mieux étant de ne pas l’avoir mais ici on peut rencontrer des problèmes car c’est souvent une dépendance interne des serveurs d’application, et on retombe dans des soucis de classloading).

Allons un peu plus loin

Allons encore un peu plus loin. Je m’appuie sur un exemple. J’ai Bonitasoft (une solution BPM Java, mais peu importe, disons simplement une webapp déployée sous tomcat) qui utilise SLF4J et Spring (basé sur JCL) et Hibernate (basé sur SLF4). 

Tout ce petit monde est déployé sous Tomcat qui lui aussi utilise JCL pour ses propres logs. Bon vu comme ça, on peut se dire que ça ne va pas être un poème, mais en fait tout est déjà solutionné par l’intégration Bonita/Tomcat qui est plutôt très bien faîte. On a un joli fichier de configuration logging.properties, une documentation propre, et des templates dont s’inspirer. Le système de logger concret est JUL (enfin presque comme on va le voir). 

Mais à l’examen de ce fichier de configuration, je découvre une syntaxe absolument pas conforme à la façon dont se configure JUL. Creusons.

Comme j’aime bien comprendre, je me plonge un peu plus avant dans la documentation Tomcat (ici : http://tomcat.apache.org/tomcat-7.0-doc/logging.html) et je vois des choses un peu bizarres. 

On commence par vous expliquer qu’on utilise JCL mais que depuis la version 6 Tomcat utilise sa propre version dans des packages renommés. C’est quoi encore cette sombre bidouille ? 

Histoire d’en avoir le cœur net, je télécharge le code source de Tomcat, et effectivement ils n’utilisent pas JCL mais un truc à eux qui ressemble à JCL comme deux gouttes d’eau mais qui n’est pas JCL

Ça s’utilise comme JCL mais ce sont des classes spécifiques à Tomcat et le mécanisme de découverte dynamique de JCL a été supprimé et remplacé par du code qui bootstrape directement le logger utilisé en interne. 

Ça m’inspire deux questions :

·         à quoi ça sert d’avoir une couche d’abstraction qui code en dur l’utilisation du logger concret ? La réponse est que la distribution Tomcat fournit d’autres implémentations de leur bouzin, et la documentation associée, pour écraser leur implémentation par défaut par une autre qui n’est pas hardcodée et permet d’utiliser un autre logger concret. Même principe qu’avec le bridge JCL-SLF4J, on écrase les classes par d’autres.
·         Si JCL posait tant de problèmes qu’on a dû le remplacer par autre chose, tant qu’à devoir passer sur tout le code pour le refactorer, pourquoi pas avec SLF4J qui fonctionne très bien et est un standard de fait, plutôt qu’une implémentation maison exotique ?

Bref, je continue ma lecture de la documentation et du code source. L’implémentation de Log renvoyée par la factory semble être essentiellement un passe-plat vers JUL  (un adapteur), avec juste un petit bloc d’initialisation statique qui modifie la configuration par défaut de JUL sur des points mineurs.

A ce stade, je n’ai toujours pas compris comment est géré le bootstrap de JUL. Je sais qu’il est spécifique car le format du fichier de configuration supporte des options non standards et que j’ai bien vu une différence de comportement. 

Finalement, je trouve que l’explication réside dans une implémentation spécifique de l’interface LogManager de JUL ; cette interface est en charge de gérer la configuration de l’arbre des loggers en mémoire.

Cette implémentation spécifique se justifie et est expliquée dans la documentation. Elle permet de gérer un jeu de configuration par webapp, et elle permet de gérer correctement la libération des ressources en cas de déchargement d’une webapp pour éviter les fuites mémoire (j’ai regardé vite fait, à priori c’est la mise en œuvre d’une WeakHashMap qui apporte ça).

Conclusion

Voilà, pour ce petit tour rapide. Comme on peut le voir, dans le monde Java on ne fait pas toujours dans la simplicité.

L’exercice sur Tomcat pourrait être renouvelé sur la plupart des autres serveurs JEE, mais pas toujours avec le code source disponible … 

lundi 29 août 2016

Sécurite - Vol 1 : définitions

L'utilisation croissante d'outils informatiques divers, et les données de plus en plus sensibles que nous leur confions, font de la sécurité une problématique de plus en plus prégnante. Pour autant c'est un sujet souvent mal compris par les utilisateurs qui sont pourtant régulièrement impactés dans leurs usages par les procédures mises en oeuvre, sans nécessairement comprendre le pourquoi ni le comment.

Le sujet est complexe et nécessite d'être abordé progressivement. Nous allons tenter de donner un premier niveau de compréhension des problèmes et solutions. Comme d'habitude sur ce blog, notre objectif n'est pas de tenir des propos d'experts mais de vulgariser le sujet et donner les informations clés pour faciliter un éventuel travail complémentaire du lecteur intéressé.

Dans ce premier article nous expliquons les enjeux. Les articles suivants exploreront divers aspects des solutions usuelles et expliqueront les bases techniques requises (cryptographie en particulier).

La donnée au cœur de la problématique : DICP

Tout d'abord il est important de préciser ce qu'un professionnel de l'informatique entend par "sécurité" car ce n'est pas nécessairement la même chose que le grand public qui se focalise généralement sur la confidentialité.

Tout le monde a entendu parler du vol de données par d'audacieux pirates qui s'emparent des données de tel ou tel site web. Récemment, un site organisant des rencontres extra-conjugales s'est fait voler ses données et ces dernières ont été mises en ligne publiquement, conduisant à au moins deux suicides de personnes ne supportant pas de voir leurs infidélités, avérées ou non, dévoilées sur la place publique. Des "people" se sont fait voler des photos intimes dénudées qui ont fait la joie des voyeurs. Wikileaks est à l'origine de crises diplomatiques. Les exemples ne manquent pas. Ici, on est face à des problèmes de confidentialité de la donnée.

Egalement dans l'actualité récente, des pirates travaillant pour le compte de l'Etat Islamique ont mené des attaques de types DDOS (Distributed Deny Of Service) sur des sites de l'état afin de les rendre indisponibles. Rappelons qu'une attaque de ce type vise à solliciter un site en le bombardant de requêtes de façon à dépasser ses capacité de traitement et le faire tomber en panne. Ici, on est face à un problème de disponibilité de la donnée (le site étant indisponible, il ne peut plus délivrer la donnée).

Les mêmes pirates après les attentats du 13 novembre à Paris ont modifié les pages d'accueil de sites destinés au grand public, comment par exemple le site de France 5, afin de remplacer les contenus initialement publiés par des messages de propagande. Ici, on est face à un problème d'Intégrité de la donnée (l'information publiée "les terroristes ont commis un attentat abominable" est devenue un bullshit du genre "les héros du jihad ont puni les infidèles" ce qui bien sur n'est pas le message que voulait délivrer le rédacteur).

Plus récemment, après cette fois les attentats de Nice, l'application "alerte attentat" que l'état avait fait développer afin d'envoyer des messages d'alerte au public (enfin pour ceux équipés d'un smartphone Apple ou Android, ayant une couverture réseau pour les data, et ayant activé l'application... ) a totalement foiré : les messages d'alerte sont arrivés très longtemps après la bagarre car l'application était indisponible le moment venu. Encore un problème de disponibilité (de la donnée "une attaque est en cours à Nice, allez vous mettre à l'abri, évitez la zone") mais qui cette fois ci n'est pas lié à une attaque du système informatique.

Au travers de quelques exemples, nous avons mis en exergue les 3 aspects de la sécurité :
  • D pour Disponibilité de la donnée
  • I pour Intégrité de la donnée
  • C pour Confidentialité de la donnée

Auxquels il faut en ajouter un quatrième : P pour Preuve. Il s'agit ici de tout ce qui touche, en gros, aux logs qui permettent après la survenue d'un problème (comme la corruption ou l'indisponibilité d'une donnée) de déterminer
  • comment il est survenu, donc pour permettre d'analyser le problème et faire les corrections nécessaires
  • qui est responsable (notion de preuve) et qui doit éventuellement supporter les conséquences, financières et/ou judiciaires, du problème survenu
Les logs c'est le jargon informatique pour désigner les traces que laisse tout programme, principalement dans des fichiers dits de journalisation, sur ce qui se passe en interne, ou sur les actions sensibles menées par des opérateurs humains.

La sécurité du système d'information c'est la bonne prise en compte de ces 4 aspects, résumés dans l'acroyme DICP, à tous les niveaux (conception, exploitation, utilisation).

Firewall, antivirus etc.

Nous venons de définir ce qu'est la sécurité d'un système d'information et pour autant nous n'avons aucunement cité les premiers sujets qui viennent à l'esprit de nombreuses personnes quand on aborde le sujet. 

Le firewall a été popularisé par les conneries débitées dans les films et séries, et tout le monde a entendu parler des méchants virus informatiques et des antivirus qui les combattent.

Firewall comme antivirus ne sont que des moyens. Ce sont des éléments, certes importants, de la politique de sécurité (qui vise à garantir DICP des données) mais ce ne sont que des éléments parmi d'autres.

Pourquoi installons nous des antivirus (et les maintenons nous à jour, nous assurons nous que les utilisateurs ne peuvent les désactiver etc.) ? > Pour nous prémunir contre des virus. 

Pourquoi nous prémunissons nous des virus ? > Car les virus vont avoir une action malveillante qui impactera le DICP. Ils vont surveiller vos frappes au clavier et vous voler vos identifiants et mots de passe, ce qui compromet la Confidentialité et fausse les Preuves, ou mettre en place divers mécanismes pour atteindre ce même objectif. Ils vont supprimer ou modifier vos fichiers ce qui compromet l'Intégrité. Ils vont utiliser votre ordinateur pour faire des actions malveillantes (attaque ddos, spam, diffusion de virus ...) et ce faisant le priver d'une partie de sa capacité de traitement et compromettre la Disponibilité.

Quel est le rôle d'un firewall ? Interdire l'accès au réseau interne aux personnes non autorisées et donc, entre autre, garantir la Confidentialité et l'Intégrité des données.

Politique de Sécurité de l'Information

Nous avons parlé jusque ici de sécurité du système d'information (ou du système informatique, c'est la même chose).

Mais le système d'information n'est qu'un outil, qui sert à gérer de l'information, et ce qu'on cherche à protéger in-fine c'est l'information. Et il faut donc commencer par définir une politique de sécurite de l'information. Un simple exemple : à quoi bon dépenser des millions pour sécuriser à outrance les données stockées dans votre SI vis à vis du monde extérieur, si tout le monde ou peu s'en faut dans l'entreprise y a accès et sans avoir conscience des enjeux économiques associés ni être responsabilisé ?

La politique de sécurité du SI n'est qu'un élément de la politique de sécurité de l'information (un élément essentiel de nos jours mais pas le seul élément).

La politique de sécurité de l'information doit définir les informations importantes et leur sensibilité en terme de DICP. En effet, ce sont ces exigences qui vont guider la construction de la politique de sécurité du système d'information et elles ont un impact majeur en matière de coût.

Par exemple, si le besoin de disponibilité est très important, il va falloir mettre en place des solutions de haute disponibilité avec de la redondance sur tous les éléments, un site de secours informatique permettant de redémarrer très rapidement en cas de sinistre majeur, impliquant de la réplication en temps réel entre les deux sites et donc la location de liens réseaux à très haut débit etc.

Nul besoin d'être un expert pour comprendre que deux sites informatiques, ça coûte grosso modo le double d'un seul site... Votre société préfère peut être se trouver sans outil informatique pendant quelques jours, que supporter en permanence le coût d'une capacité de redémarrage en 1 Heure pour un sinistre dont la probabilité de survenance est somme toute assez faible. Des procédures manuelles dégradées et un processus de reprise progressif sur quelques jours sont sans doute suffisants. Mais si vous gérez un aéroport ou une base de missile nucléaire les choses sont différentes...

Je vous suggère la lecture de l'article en lien qui donne un très bon exemple et une très bonne explication des DICP de façon très amusante et en Français tant qu'à faire.

Quelques données clés au sujet de la sécurité

La sécurité est l'affaire de tous, à commencer par les utilisateurs des systèmes qui en constituent le principal maillon faible. L'ingénierie sociale est un des principaux moyens utilisés par les pirates pour détourner les mesures de sécurité mises en place par les organisations.


La sécurité ne relève pas que des informaticiens et de la mise en oeuvre de moyens technique ; il y a aussi et entre autre des aspects organisationnels ou de gestion RH. Par exemple, il faut penser à désactiver les comptes des collaborateurs quittant la société, sensibiliser les utilisateurs, identifier les responsables de la sécurité et les former, organiser les locaux ...


La sécurité maximale du SI est la sécurité de son élément le plus faible. Imaginez un SI super sécurisé au niveau réseau et pour lequel on permettrait un accès administrateur depuis un poste hébergé dans un local dont la porte ne fermerait pas a clé.

Il existe des méthodologies pour vérifier la prise en compte des contraintes DICP sur lesquelles s'appuient les consultants en sécurité pour mener des audits. Les formations relatives à la sécurité se développent, il y a un marché en plein essor en la matière.

Il existe des certifications qualité pour garantir que les organisations ont le souci et sont organisées d'une façon satisfaisante au regard du DICP. Le respect de telle ou telle certification est une exigence de plus en plus courante pour des grands contrats.

Il y a une prise de conscience forte de l'état sur l'importance de la sécurité compte tenu de la digitalisation croissante de l'économie et des risques de cyber-attaques pouvant gravement déstabiliser un état ou une économie. L'état s'est doté d'une agence de sécurité et embauche à tour de bras. Des opérateurs d'importance vitale (OIV) sont identifiés et se voient imposés par la loi des normes et règles en matière de sécurité.

Focus sur l'exemple "Alerte attentat"

La raison du dysfonctionnement était que suite à des travaux de génie civil (un bien grand mot pour parler d'ouvrier qui ont fait une tranchée dans le sol) le câble réseau raccordant le datacenter où était hébergée l'application a été coupé, ce qui a entraîné un dysfonctionnement de l'application.

Les sondes surveillant le bon fonctionnement de l'application et sur lesquelles s'appuyait la supervision (la surveillance du bon fonctionnement) ont données de mauvaises informations et laissé croire que l'application fonctionnait correctement après rétablissement de la connexion réseau.

Quand on a eu besoin de l'application, à priori dans les minutes qui ont suivi l'attentat de Nice (supposition, il y a peut être ici aussi eu des dysfonctionnements et des retards dans l'activation du système d'alerte) on s'est rendu compte du problème et il a fallu un long moment pour redémarrer le système (ce qui en soit n'est pas normal non plus).

Une première remarque : un datacenter digne de ce nom doit disposer de deux accès réseaux redondés de façon à ce que ce type d'incident, pas si rare, n'ait pas d'incidences. Ensuite, pour une application aussi critique, le bon sens aurait voulu qu'elle soit installée sur deux sites (deux datacenters) distincts et suffisamment distants géographiquement. Ces deux mesures de simple bon sens auraient permis d'apporter ce qu'on appelle la Haute Disponibilité (voir mon article sur la HD disponible ici), et ce d'autant plus facilement que la solution s'appuie sur une couche de virtualisation (voir mes articles sur la virtualisation ici, ici et ici). La Haute Disponibilité est un moyen au service de la politique de sécurité (plus particulièrement de l'aspect Disponibilité).

Ensuite, j'estime qu'une application bien conçue doit être capable de supporter une perte et un rétablissement de la connexion réseau. Il suffit de prendre cette considération en compte dans la phase de conception technique, les solutions existent. Enfin, la supervision a manifestement été bien mal conçue puisqu'elle affichait un voyant vert où on aurait du avoir des alertes en rouge clignotant partout. Bref, un amateurisme bien difficile à accepter s'agissant d'une application qui est censée protéger des vies humaines et qui doit être financée, conçue et exploitée en conséquence.  Ici aussi on est sur un problème de disponibilité et on voit que cette problématique de sécurité doit être prise en compte dans la conception, et donc en amont dans la spécification et l'expression du besoin qui en est à l'origine. La sécurité doit être prise en compte à tous les étages.

Face à cet échec, des corrections sont à apporter (et ont à priori été apportées). Mais au delà, il peut être intéressant d'établir les responsabilités respectives des différents intervenants du projet :

  • la MOA (l'état qui a rédigé le cahier des charges, défini le planning, financé l'opération, validé la solution) a elle exprimé le besoin de Haute Disponibilité, suffisamment financé l'opération pour permettre cette mise en oeuvre, vérifié le bon fonctionnement ? N'a elle pas imposé ou accepté un planning ne prévoyant cette mise en HD qu'ultérieurement (voire pas du tout) ?
  • la MOE (le prestataire qui a conçu et réalisé l'opération) a elle bien fait son travail, a elle rempli son devoir de conseil en alertant la MOA sur un besoin de HD non exprimé ou non financé, a elle bien sélectionné l'hébergeur (si ce n'est pas l'état qui l'a imposé ce qui est tout à fait probable dans le cas présent) ?
  • l'hébergeur (la société qui est en charge des serveurs physiques sur lesquels est installée l'application, et de leur connexion Internet) offrait il le niveau de sécurité requis ?
  • l'exploitant (la société en charge de la supervision applicative c'est à dire de surveiller le bon fonctionnement et de rétablir la situation en cas de problème, ici la même que l'hébergeur à priori). A priori il semble hors du coup car le mauvais fonctionnement des sondes ne peut guère lui être opposé, un exploitant  ne fait qu'utiliser les outils qu'on lui fournit en suivant des procédures qu'on lui fournit. Si ces outils ou procédures sont défaillants, il ne peut pas en être responsable, sauf dysfonctionnement manifeste qu'il n'aurait pu que constater et qu'il n'aurait pas signalé.
Ici on voit l'importance de bien contractualiser et de disposer des logs permettant de comprendre l'origine d'un problème afin de pouvoir se retourner contre le responsable et obtenir des dédommagements ou le faire condamner en cas de conséquence condamnable au civil ou au pénal. La sécurité doit être prise en compte à tous les étages.

Conclusion (temporaire)

La sécurité est un sujet d'actualité et qui ne cesse de prendre de l'importance.

Tout utilisateur régulier de site internet ou d'applications mobiles a pu voir apparaître de nouveaux usages en lien avec la sécurité, même si ils n'ont pas forcément fait le lien :
  • généralisation de techniques de double authentification : par exemple envoi de sms sur votre portable avec un mot de passe temporaire
  • possibilité d'utiliser ses identifiants de réseaux sociaux (FaceBoox, LinkedIn, Google+...) sur de multiples sites sans devoir se créer à chaque fois de nouveaux identifiants
  • demande d'autorisation pour autoriser à des applications d'accéder à certaines données personnelles gérées pour vous par diverses applications (réseaux sociaux ou autre)


Cette rapide  introduction visait à préciser que la sécurité du SI s'inscrivait dans un cadre plus global visant à la sécurité de l'information, qu'elle ne relevait pas uniquement des informaticiens et des moyens informatiques, et que son champ d'application était bien plus développé que ne l'imaginent probablement les néophytes sur le sujet.

Dans les prochains articles nous expliquerons rapidement les quelques principes de base en cryptographie dont la compréhension est requise, et nous mettrons un focus sur les problématiques d'authentification et d'habilitation.