Les développeurs de terminologie critique doivent savoir

À l'heure où le monde se tourne de plus en plus vers l'exploitation des données, la sécurisation des informations des utilisateurs est devenue un impératif absolu.

En tant que développeurs, notre mission est déjà complexe : gérer des systèmes délicats et hétérogènes, avec des points de défaillance multiples, tout en traduisant des besoins humains en interfaces utilisateurs et en fonctionnalités backend. À cette tâche, s'ajoute une préoccupation croissante et incontournable : la protection des données. Et pour cause : en tant que clients, nous sommes indignés lorsque nos données sont utilisées de manière inappropriée. Il est donc juste que nous offrions à nos utilisateurs une expérience à la fois sécurisée et agréable. De plus, les gouvernements et les entreprises l'exigent pour des raisons de conformité.

La sécurité des données, une responsabilité partagée

La complexité de la sécurité réside dans le fait qu'elle s'articule en plusieurs couches et incombe à tous. Dans une équipe cloud moderne, diverses équipes gèrent l'entrée/sortie des données : développeurs, administrateurs de bases de données, administrateurs système (les équipes DevOps), utilisateurs privilégiés du back-office, etc. Ces rôles et équipes pourraient rapidement se décharger de cette responsabilité en la considérant comme le problème des autres. Or, la réalité est que chacun doit assumer sa part, car un administrateur de base de données n'a pas prise sur la sécurité applicative, et un membre de l'équipe DevOps ne peut rien faire en ce qui concerne l'accès au back-office, par exemple.

Le rôle crucial des développeurs dans la sécurité des données

Ceci étant dit, les développeurs ont la plus grande portée en matière d'accès aux données. Ils construisent chaque composant de l'application, se connectent à de nombreux services backend, gèrent les jetons d'accès, ont un contrôle total sur le cluster de bases de données pour la lecture/écriture et leurs applications disposent d'un accès illimité à toutes les parties du système. Par exemple, une application Django en production a tous les droits pour vider ou supprimer une collection S3 datant de dix ans. Par conséquent, le plus grand risque de négligence ou d'omission en matière de sécurité réside au niveau du code source, une responsabilité qui incombe directement au développeur.

La sécurité des données est un sujet vaste et complexe qu'il est impossible de traiter en profondeur en un seul article. Toutefois, je souhaite aborder les concepts essentiels que les développeurs doivent maîtriser pour sécuriser leurs applications. Considérons cela comme une initiation à la sécurité des données applicatives.

Commençons !

Hachage

Si vous recherchez une définition formelle, vous pouvez consulter Wikipédia. En termes simples, le hachage est le processus de transformation des données en une forme illisible. Par exemple, en utilisant la méthode bien connue (mais très peu sécurisée) du codage Base64, la phrase "Mon secret est-il en sécurité avec vous ?" peut être transformée (hachée) en "SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/". Si vous décidiez d'écrire votre journal personnel en Base64, votre famille ne pourrait pas lire vos secrets, sauf si elle savait comment décoder le Base64 !

Cette idée de rendre les données incompréhensibles 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'objectif est qu'en cas de violation de données, un attaquant ne puisse pas utiliser les mots de passe ou les numéros de carte de crédit pour causer un préjudice réel. Des algorithmes sophistiqués et robustes sont utilisés pour effectuer ce hachage. Une méthode comme Base64 serait une plaisanterie et serait déchiffrée instantanément par un attaquant.

Le hachage de mots de passe utilise une technique cryptographique appelée hachage unidirectionnel, ce qui signifie qu'il est possible de brouiller les données, mais pas de les déchiffrer. Alors, comment l'application sait-elle que c'est bien votre mot de passe lorsque vous vous connectez ? Elle utilise le même processus et compare la version brouillée de ce que vous venez de saisir avec la version brouillée stockée dans la base de données. Si les deux correspondent, vous êtes autorisé à vous connecter !

À ce propos, voici une information intéressante. Si vous téléchargez des logiciels ou des fichiers sur Internet, il vous a peut-être été demandé de vérifier les fichiers avant de les utiliser. Par exemple, si vous téléchargez l'ISO d'Ubuntu Linux, la page de téléchargement propose une option de vérification. Si vous cliquez dessus, une fenêtre contextuelle s'ouvre :

La fenêtre contextuelle vous demande d'exécuter une commande qui va hacher le fichier que vous venez de télécharger et comparer le résultat à la chaîne de hachage affichée sur la page de téléchargement : 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5. Cette conversion est réalisée grâce à l'algorithme SHA256, que l'on retrouve à la fin 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 modifié votre téléchargement et vous a fourni un fichier compromis.

Parmi les noms courants dans le domaine du hachage de mots de passe, on trouve MD5 (non sécurisé et obsolète), SHA-1 et SHA-2 (une famille d'algorithmes dont SHA-256 et SHA-512 sont membres), SCRYPT, BCRYPT, etc.

Salage

La sécurité est un jeu du chat et de la souris : un attaquant analyse le système existant et trouve une faille, qui est ensuite corrigée, puis les mécanismes de sécurité sont améliorés, et ainsi de suite. La cryptographie ne fait pas exception. Bien qu'il soit devenu impossible de déchiffrer un mot de passe à partir de son hachage, les attaquants ont développé des techniques sophistiquées combinant des suppositions intelligentes avec une puissance de calcul brute. Il est donc devenu fréquent qu'ils parviennent à deviner le mot de passe à partir de son hachage.

"M. Rumpelstiltskin, je suppose ?!"

C'est dans ce contexte que la technique du salage a émergé. Cela signifie que le hachage d'un mot de passe (ou de toute donnée) est effectué en combinant deux éléments : les données elles-mêmes et une 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électionnons d'abord une chaîne aléatoire comme "sel", par exemple bCQC6Z2LlbAsqj77, puis nous effectuons le hachage sur superman009-bCQC6Z2LlbAsqj77. Le hachage résultant sera différent des structures habituelles produites par l'algorithme, ce qui réduit considérablement les possibilités de rétro-ingénierie ou de déduction.

Le hachage et le salage sont des domaines complexes en constante évolution. En tant que développeurs d'applications, nous ne devrions jamais les gérer directement, mais avoir une compréhension de leur fonctionnement nous aidera à prendre de meilleures décisions. Par exemple, si vous maintenez un ancien framework PHP et que vous constatez qu'il utilise des hachages MD5 pour les mots de passe, vous savez qu'il est temps d'intégrer une nouvelle bibliothèque de mots de passe au processus de création de compte utilisateur.

Clés

Vous rencontrerez souvent le terme "clés" dans le contexte du chiffrement. Jusqu'à présent, nous avons évoqué le hachage de mots de passe ou le chiffrement unidirectionnel, où les données sont transformées de manière irréversible, effaçant la forme d'origine. Cette méthode est inadaptée à un usage courant : un document écrit et envoyé par e-mail de manière si sécurisée qu'il ne peut plus jamais être lu n'a aucune utilité ! Ainsi, nous souhaitons chiffrer les données de manière à ce qu'elles soient accessibles à l'expéditeur et au destinataire, tout en étant illisibles pendant leur transfert ou leur stockage.

Pour cela, le concept de "clé" existe en cryptographie. Il s'agit d'une métaphore similaire à la clé d'une serrure. La personne qui possède l'information la brouille à l'aide d'un secret appelé clé. Si le récepteur ou un attaquant ne possède pas cette clé, il est impossible de déchiffrer les données, même avec des algorithmes complexes.

Rotation des clés

Bien que les clés rendent le chiffrement possible et fiable, elles comportent les mêmes risques que les mots de passe : si quelqu'un découvre la clé, tout est compromis. Imaginez un scénario où un attaquant pirate un service comme GitHub (même pour quelques secondes) et met la main sur du code vieux de 20 ans. Dans ce code, il trouve également les clés cryptographiques utilisées pour chiffrer les données de l'entreprise (une mauvaise pratique consistant à stocker les clés avec le code source, mais c'est plus courant qu'on ne le pense !). Si l'entreprise n'a pas pris la peine de changer ses clés (tout comme les mots de passe), cette clé peut être utilisée pour causer des dégâts.

C'est pourquoi la pratique du changement régulier des clés a évolué. C'est ce qu'on appelle la rotation des clés, et si vous utilisez un fournisseur de cloud PaaS de qualité, ce service devrait être automatisé.

Crédit image : AWS

Par exemple, AWS propose un service dédié appelé AWS Key Management Service (KMS). Un service automatisé vous évite le tracas de changer et de distribuer les clés entre tous les serveurs, ce qui est indispensable pour les déploiements à grande échelle.

Cryptographie à clé publique

Si les discussions précédentes sur le chiffrement et les clés vous font penser que c'est compliqué, vous avez raison. La sécurité des clés et leur transmission afin que seul le destinataire puisse lire les données posent des problèmes logistiques qui auraient empêché l'essor des communications sécurisées d'aujourd'hui. Mais grâce à la cryptographie à clé publique, nous pouvons communiquer et faire des achats en ligne en toute sécurité.

Cette forme de cryptographie a été une avancée mathématique majeure, sans laquelle Internet serait un lieu de peur et de méfiance. Les détails de l'algorithme sont complexes et très mathématiques, je ne peux donc l'expliquer qu'en termes de concepts.

La cryptographie à clé publique repose sur l'utilisation de deux clés pour traiter les informations. L'une est la clé privée, qui doit rester secrète et ne jamais être partagée. L'autre est la clé publique, qui est destinée à être publiée. Si je veux vous envoyer 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échiffrer les données en utilisant votre clé privée et votre clé publique. Tant que vous ne divulguez pas accidentellement votre clé privée, je peux vous envoyer des données chiffrées que vous seul pouvez ouvrir.

La beauté du système est que je n'ai pas besoin de connaître votre clé privée et qu'une personne interceptant le message ne pourra pas le lire, même avec votre clé publique. Si vous vous demandez comment cela est possible, la réponse la plus simple réside dans les propriétés de la multiplication de grands nombres premiers :

Il est difficile pour les ordinateurs de factoriser de grands nombres premiers. Ainsi, si la clé d'origine est très grande, vous pouvez être certain que le message ne pourra pas être déchiffré, même dans des milliers d'années.

Sécurité de la couche de 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 chiffrées à l'aide de cette clé) est à la base de la popularité du protocole HTTPS, et c'est la raison pour laquelle Chrome affiche "Ce site est sécurisé". En réalité, le serveur et le navigateur chiffrent le trafic HTTP (les pages web sont de longues chaînes de texte que les navigateurs peuvent interpréter) avec les clés publiques de l'autre, créant ainsi le HTTPS (HTTP sécurisé).

Crédit image : Mozilla

Il est intéressant de noter que le chiffrement n'a pas lieu au niveau de la couche transport à proprement parler. Le modèle OSI ne prévoit rien sur le chiffrement des données. En fait, les données sont chiffrées par l'application (ici, le navigateur) avant d'être transmises à la couche transport, qui les achemine vers leur destination, où elles sont déchiffrées. Toutefois, le processus implique la couche transport, ce qui conduit au terme générique de sécurité de la couche "transport".

Vous pourriez également rencontrer le terme Secure Socket Layer (SSL). C'est le même concept que TLS, sauf que SSL est apparu bien avant et est désormais remplacé par TLS.

Chiffrement complet du disque

Parfois, les exigences de sécurité sont si élevées qu'aucun détail ne doit être négligé. Par exemple, les serveurs gouvernementaux qui stockent toutes les données biométriques d'un pays ne peuvent pas être gérés comme des serveurs d'applications classiques, car le risque est trop grand. Pour ces besoins, il ne suffit pas que les données soient chiffrées uniquement pendant leur transfert, elles doivent également l'être au repos. Pour cela, le chiffrement complet 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 vol physique.

Il est important de noter que le chiffrement complet du disque doit être effectué au niveau matériel. En effet, si l'ensemble du disque est chiffré, le système d'exploitation l'est également et ne peut pas démarrer la machine. Le matériel doit donc comprendre que le contenu du disque est chiffré et doit effectuer le déchiffrement à la volée lorsqu'il transmet les blocs de disque demandés au système d'exploitation. Ce travail supplémentaire entraîne des lectures/écritures plus lentes, un facteur que les développeurs de tels systèmes doivent prendre en compte.

Chiffrement de bout en bout

Avec les problèmes de confidentialité et de sécurité liés aux grands réseaux sociaux, le terme "chiffrement de bout en bout" est devenu familier, même pour ceux qui ne travaillent pas dans le développement ou la maintenance d'applications.

Nous avons vu que le chiffrement complet du disque offre la solution ultime en matière de sécurité, mais il est peu pratique pour l'utilisateur quotidien. 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 votre téléphone, bloquant ainsi tout le reste.

C'est pourquoi ces entreprises ont mis en place le 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. Autrement dit, même lorsque les données parviennent au destinataire, elles restent chiffrées et ne sont accessibles qu'à partir du téléphone du destinataire.

Crédit image : Google

Il est important de noter que le chiffrement de bout en bout (E2E) ne garantit pas une sécurité mathématique, contrairement à la cryptographie à clé publique. Il s'agit simplement d'un chiffrement standard où la clé est stockée par l'entreprise et vos messages sont aussi sûrs que l'entreprise le décide.

Conclusion 👩‍🏫

Vous avez probablement déjà entendu la plupart de ces termes, voire tous. Si c'est le cas, je vous encourage à revoir votre compréhension de ces concepts et à évaluer la manière dont vous les prenez au sérieux. N'oubliez pas que la sécurité des données applicatives est une guerre que vous devez gagner à chaque fois, car une seule faille peut détruire des entreprises, des carrières et même des vies !