Alors que le monde devient de plus en plus axé sur les données, le traitement sécurisé des données des utilisateurs est plus critique que jamais.
En tant que développeurs, notre travail est déjà assez difficile : nous devons gérer des systèmes extrêmement complexes et fragiles, avec de multiples points de défaillance, tout en traduisant les souhaits humains fluctuants en interfaces utilisateur et en backends. À cette tâche s’ajoute une considération émergente et essentielle : la sécurité des données. Et ce pour une bonne raison : en tant que clients, nous sommes furieux si nos données sont utilisées à mauvais escient (il n’est donc que juste que nous offrions à nos utilisateurs une expérience sûre et agréable), et les gouvernements et les entreprises l’exigent pour des raisons de conformité.
La sécurité des données, un moyen de faire passer le message
Ce qui rend la sécurité plus difficile, c’est qu’elle comporte plusieurs couches et qu’elle devient la responsabilité de tout le monde et de personne. Dans une équipe cloud moderne, plusieurs équipes contrôlent directement l’entrée et la sortie des données : les développeurs, les administrateurs de bases de données, les administrateurs système (les personnes DevOps, si vous voulez), les utilisateurs privilégiés du back-office, et ainsi de suite. Ces rôles/équipes peuvent rapidement fermer les yeux et considérer que la sécurité des données est le problème des autres. En effet, un administrateur de base de données ne peut pas contrôler l’aspect applicatif de la sécurité, une personne DevOps ne peut absolument rien faire pour l’accès au back-office, etc.
Les développeurs et la sécurité des données
Cela dit, les développeurs disposent de la plus grande surface d’accès aux données : ils construisent chaque partie de l’application ; ils se connectent à divers services de backend ; ils transfèrent des jetons d’accès dans les deux sens ; ils peuvent lire/écrire dans l’ensemble de la base de données ; les applications qu’ils écrivent ont un accès incontesté à toutes les parties du système (par exemple, une application Django en production a tous les privilèges pour vider ou effacer l’ensemble de la collection S3 des dix dernières années), et ainsi de suite. Par conséquent, le risque le plus élevé de négligence ou d’oubli en termes de sécurité se situe au niveau du code source et relève de la responsabilité directe du développeur.
La sécurité des données est un trou de lapin sans fond, et il est impossible d’en effleurer la surface en un seul article. Cependant, je souhaite aborder la terminologie essentielle que les développeurs doivent connaître pour assurer la sécurité de leurs applications. Pensez-y comme à un cours de sécurité des données d’application 101.
Commençons par le commencement !
Hachage
Si vous voulez une définition très rigoureuse, vous pouvez toujours consulter Wikipédia, mais en termes simples, le hachage est le processus de conversion des données sous une autre forme, où l’information est illisible. Par exemple, en utilisant le processus bien connu (et très peu sûr) du codage Base64, la chaîne “Mon secret est-il bien gardé ?” peut être convertie (“hachée”) en “SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/”. Si vous commencez à écrire votre journal personnel au format Base64, par exemple, votre famille ne pourra en aucun cas lire vos secrets (à moins qu’elle ne sache décoder à partir de Base64) !
Cette idée de brouillage des données est utilisée pour stocker les mots de passe, les numéros de carte de crédit, etc. dans les applications web (en fait, elle devrait être utilisée dans tous les types d’applications). L’idée, bien sûr, est qu’en cas de violation de données, le pirate ne devrait pas pouvoir utiliser les mots de passe, les numéros de carte de crédit, etc. pour causer des dommages réels. Des algorithmes très robustes et sophistiqués sont utilisés pour effectuer ce hachage ; quelque chose comme Base64 serait une blague et serait cassé instantanément par n’importe quel attaquant.
Le hachage de mots de passe utilise une technique cryptographique connue sous le nom de hachage à sens unique, ce qui signifie que s’il est possible de brouiller les données, il n’est pas possible de les débrouiller. Alors comment l’application sait-elle qu’il s’agit de votre mot de passe lorsque vous vous connectez ? Elle utilise le même processus et compare la forme brouillée du mot de passe que vous venez de saisir à la forme brouillée stockée dans la base de données ; si les deux correspondent, vous êtes autorisé à vous connecter !
Puisque nous parlons de hachage, voici quelque chose d’intéressant. Si vous avez déjà téléchargé des logiciels ou des fichiers sur l’internet, on vous a peut-être dit de vérifier les fichiers avant de les utiliser. Par exemple, si vous souhaitez télécharger la version ISO d’Ubuntu Linux, la page de téléchargement vous proposera de vérifier votre téléchargement ; si vous cliquez dessus, une fenêtre contextuelle s’ouvrira :
Cette dernière vous demande d’exécuter une commande qui va essentiellement hacher l’intégralité du fichier que vous venez de télécharger et comparer le résultat à la chaîne de hachage que vous voyez sur la page de téléchargement : 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5. Cette conversion est effectuée à l’aide de l’algorithme SHA256, dont vous pouvez voir la mention dans les dernières parties de la commande : shasum -a 256 --check.
L’idée est que si le hachage produit par votre vérification est différent, cela signifie que quelqu’un a interféré avec votre téléchargement et vous a fourni un fichier compromis à la place.
Certains noms familiers que vous entendrez dans le domaine du hachage de mots de passe sont MD5 (peu sûr et désormais défunt), SHA-1 et SHA-2 (familles d’algorithmes dont SHA-256 fait partie, tout comme SHA-512), SCRYPT, BCRYPT, etc.
Salage
Tous les types de sécurité sont un jeu du chat et de la souris : le voleur apprend à connaître le système actuel et trouve une nouvelle faille, qui est remarquée, et les fabricants de serrures améliorent leur jeu, et ainsi de suite. La cryptographie ne fait pas exception. Bien qu’il soit devenu impossible de convertir les hachages en mots de passe, les attaquants ont développé au fil du temps des techniques sophistiquées qui combinent la devinette intelligente et la puissance de calcul pure et simple.
C’est ainsi qu’est née la technique du salage. Cela signifie simplement que le calcul du hachage d’un mot de passe (ou de n’importe quelle donnée) sera effectué sur la base d’une combinaison de deux éléments : les données elles-mêmes, ainsi qu’une nouvelle chaîne aléatoire que l’attaquant ne peut pas deviner. Ainsi, avec le salage, si nous voulons hacher le mot de passe superman009, nous sélectionnerons d’abord une chaîne aléatoire comme “sel”, disons bCQC6Z2LlbAsqj77, puisnous effectuerons le calcul de hachage sur superman009-bCQC6Z2LlbAsqj77. Le hachage obtenu s’écarte des structures habituelles produites par l’algorithme, ce qui réduit considérablement les possibilités de rétro-ingénierie intelligente ou de devinettes.
Le hachage et le salage sont des domaines incroyablement compliqués et en constante évolution. En tant que développeur d’applications, nous ne nous en occuperons donc jamais directement. Mais nous serions grandement aidés si nous les connaissions et pouvions prendre de meilleures décisions. Par exemple, si vous maintenez un vieux framework PHP et que vous constatez qu’il utilise des hachages MD5 pour les mots de passe, vous savez qu’il est temps d’insérer une autre bibliothèque de mots de passe dans le processus de création des comptes d’utilisateurs.
Clés
Vous rencontrerez souvent le terme “clés” dans le contexte du cryptage. Jusqu’à présent, nous avons abordé le hachage des mots de passe ou le chiffrement à sens unique, qui consiste à convertir les données de manière irréversible et à détruire la forme originale. C’est une mauvaise idée pour l’usage pratique quotidien : un document écrit et envoyé par courrier électronique de manière si sûre qu’il ne peut jamais être lu n’est d’aucune utilité ! Nous voulons donc crypter les données de manière à ce que l’information soit accessible à l’expéditeur et au destinataire, mais qu’elle soit illisible pendant son transfert ou son stockage.
C’est pour cela qu’il existe le concept de “clé” en cryptographie. C’est exactement ce que l’on croit : la clé d’une serrure. La personne qui détient l’information la brouille en utilisant un secret appelé “clé”. Si le destinataire/attaquant ne possède pas cette clé, il est impossible de décoder les données, quelle que soit la sophistication de ses algorithmes.
Rotation des clés
Si les clés rendent le chiffrement possible et fiable, elles comportent les mêmes risques que les mots de passe : une fois que quelqu’un connaît la clé, tout est fini. Imaginez un scénario dans lequel quelqu’un pirate une partie d’un service comme GitHub (même si c’est pour quelques secondes) et peut mettre la main sur un code vieux de 20 ans. Dans le code, il trouve également les clés cryptographiques utilisées pour chiffrer les données de l’entreprise (il est horrible de stocker les clés avec le code source, mais vous seriez surpris de voir à quel point cela arrive souvent !) Si l’entreprise n’a pas pris la peine de modifier ses clés (tout comme les mots de passe), la même clé peut être utilisée pour faire des ravages.
C’est pourquoi la pratique consistant à changer fréquemment les clés a évolué. C’est ce qu’on appelle la rotation des clés, et si vous utilisez un fournisseur de PaaS en nuage digne de ce nom, elle devrait être disponible en tant que service automatisé.
Par exemple, AWS dispose d’un service dédié à cette tâche, appelé AWS Key Management Service (KMS). Un service automatisé vous évite de changer et de distribuer les clés entre tous les serveurs, ce qui est aujourd’hui une évidence lorsqu’il s’agit de grands déploiements.
Cryptographie à clé publique
Si tout ce qui vient d’être dit sur le chiffrement et les clés vous fait penser que c’est très lourd, vous avez raison. Garder les clés en sécurité et les transmettre de manière à ce que seul le destinataire puisse voir les données pose des problèmes logistiques qui n’auraient pas permis aux communications sécurisées d’aujourd’hui de prospérer. Mais grâce à la cryptographie à clé publique, nous pouvons communiquer ou faire des achats en ligne en toute sécurité.
Ce type de cryptographie a constitué une avancée mathématique majeure, et c’est la seule raison pour laquelle l’internet ne s’effondre pas dans la peur et la méfiance. Les détails de l’algorithme sont complexes et hautement mathématiques, c’est pourquoi je ne peux l’expliquer ici que de manière conceptuelle.
La cryptographie à clé publique repose sur l’utilisation de deux clés pour traiter les informations. L’une des clés, appelée clé privée, est censée rester privée et ne jamais être partagée avec qui que ce soit ; l’autre, appelée clé publique (d’où le nom de la méthode), est censée être publiée publiquement. Si je vous envoie des données, je dois d’abord obtenir votre clé publique, crypter les données et vous les envoyer ; de votre côté, vous pouvez décrypter les données à l’aide de votre combinaison de clé privée et de clé publique. Tant que vous ne révélez pas accidentellement votre clé privée, je peux vous envoyer des données cryptées que vous seul pouvez ouvrir.
La beauté du système réside dans le fait que je n’ai pas besoin de connaître votre clé privée et que quiconque intercepte le message ne peut rien faire pour le lire, même s’il possède votre clé publique. Si vous vous demandez comment cela est possible, la réponse la plus courte et la moins technique vient des propriétés de la multiplication des nombres premiers :
Les ordinateurs ont du mal à factoriser les grands nombres premiers. Ainsi, si la clé d’origine est très grande, vous pouvez être sûr que le message ne pourra pas être décrypté, même dans des milliers d’années.
Sécurité de la couche transport (TLS)
Vous savez maintenant comment fonctionne la cryptographie à clé publique. Ce mécanisme (connaître la clé publique du destinataire et lui envoyer des données cryptées à l’aide de cette clé) est à l’origine de la popularité du protocole HTTPS et permet à Chrome d’indiquer “Ce site est sécurisé” Ce qui se passe, c’est que le serveur et le navigateur chiffrent le trafic HTTP (rappelez-vous que les pages web sont de très longues chaînes de texte que les navigateurs peuvent interpréter) avec leurs clés publiques respectives, ce qui permet d’obtenir le protocole HTTP sécurisé (HTTPS).
Il est intéressant de noter que le cryptage n’a pas lieu au niveau de la couche de transport en tant que telle ; le modèle OSI ne dit rien sur le cryptage des données. Les données sont simplement cryptées par l’application (dans ce cas, le navigateur) avant d’être transmises à la couche transport, qui les achemine ensuite vers leur destination, où elles sont décryptées. Cependant, le processus implique la couche de transport et, en fin de compte, il aboutit à un transport sécurisé des données, c’est pourquoi le terme générique de sécurité de la couche “transport” est resté.
Vous pouvez même rencontrer le terme Secure Socket Layer (SSL) dans certains cas. Il s’agit du même concept que TLS, sauf que SSL est apparu bien avant et qu’il a été abandonné au profit de TLS.
Chiffrement intégral du disque
Parfois, les besoins en matière de sécurité sont si importants que rien ne peut être laissé au hasard. Par exemple, les serveurs gouvernementaux où sont stockées toutes les données biométriques d’un pays ne peuvent pas être provisionnés et exécutés comme des serveurs d’application normaux, car le risque est trop élevé. Pour répondre à ces besoins, il ne suffit pas que les données soient cryptées uniquement lors de leur transfert ; elles doivent également l’être lorsqu’elles sont au repos. Pour cela, le chiffrement intégral du disque est utilisé pour chiffrer l’intégralité d’un disque dur afin de garantir la sécurité des données, même en cas de violation physique.
Il est important de noter que le chiffrement intégral du disque doit être effectué au niveau du matériel. En effet, si nous chiffrons l’intégralité du disque, le système d’exploitation est également chiffré et ne peut pas s’exécuter au démarrage de la machine. Le matériel doit donc comprendre que le contenu du disque est crypté et doit procéder au décryptage à la volée lorsqu’il transmet les blocs de disque demandés au système d’exploitation. En raison de ce travail supplémentaire, le chiffrement intégral du disque se traduit par des lectures/écritures plus lentes, ce que les développeurs de ces systèmes doivent garder à l’esprit.
Chiffrement de bout en bout
Avec les cauchemars actuels des grands réseaux sociaux en matière de confidentialité et de sécurité, personne n’ignore le terme “chiffrement de bout en bout”, même s’il n’a rien à voir avec la création ou la maintenance d’applications.
Nous avons vu précédemment que le chiffrement intégral du disque constituait la stratégie ultime à l’épreuve des balles, mais pour l’utilisateur lambda, ce n’est pas pratique. Imaginez que Facebook veuille sécuriser les données téléphoniques qu’il génère et stocke dans votre téléphone, mais qu’il n’ait pas accès au chiffrement de l’ensemble de votre téléphone et au verrouillage de tout le reste dans le processus.
C’est pourquoi ces entreprises ont mis en place un chiffrement de bout en bout, ce qui signifie que les données sont chiffrées lorsqu’elles sont créées, stockées ou transférées par l’application. En d’autres termes, même lorsque les données parviennent au destinataire, elles sont entièrement cryptées et ne sont accessibles que par le téléphone du destinataire.
Notez que le chiffrement de bout en bout (E2E) n’offre aucune garantie mathématique, contrairement à la cryptographie à clé publique ; il s’agit simplement d’un chiffrement standard dont la clé est stockée dans l’entreprise, et vos messages sont aussi sûrs que l’entreprise le décide.
Conclusion 👩🏫
Vous avez probablement déjà entendu parler de la plupart de ces termes. Peut-être même tous. Si c’est le cas, je vous encourage à revoir votre compréhension de ces concepts et à évaluer dans quelle mesure vous les prenez au sérieux. N’oubliez pas que la sécurité des données d’application est une guerre que vous devez gagner à chaque fois (et pas seulement une fois), car une seule violation suffit à détruire des industries entières, des carrières et même des vies !