Alors que le monde devient de plus en plus axé sur les données, la gestion sécurisée des données des utilisateurs est plus critique que jamais.
En tant que développeurs, notre travail est déjà assez difficile : gérer des systèmes très complexes et fragiles avec de multiples points de défaillance pendant que nous traduisons les souhaits humains flottants en interfaces utilisateur et backends. S'ajouter à la tâche est une considération émergente et essentielle : la sécurité des données. Et pour une bonne raison : en tant que clients, nous sommes furieux si nos données sont mal utilisées (il est donc juste que nous donnions à nos utilisateurs une expérience sécurisée et agréable), et les gouvernements et les entreprises l'exigent pour la conformité.
La sécurité des données comme renvoi
Ce qui rend la sécurité plus difficile, c'est qu'elle a plusieurs couches et devient la responsabilité de tout le monde n'est la responsabilité de personne. Dans une équipe cloud moderne, plusieurs équipes contrôlent directement l'entrée/la sortie des données : développeurs, administrateurs de base de données, administrateurs système (les gens de DevOps, si vous voulez), les utilisateurs privilégiés du back-office, etc. Ces rôles/équipes peuvent rapidement fermer les yeux et considérer la sécurité des données comme le problème des autres. Pourtant, la réalité est qu'ils ont leurs propres mondes à gérer car un administrateur de base de données ne peut pas contrôler le côté application de la sécurité, un DevOps personne ne peut absolument rien faire au sujet de l'accès au back-office, et ainsi de suite.
Développeurs et sécurité des données
Cela dit, les développeurs ont la plus grande surface d'accès en matière de données : ils construisent chaque partie de l'application ; ils se connectent à divers services principaux ; les jetons d'accès au ferry dans les deux sens ; ils ont tout le cluster de base de données pour lire/écrire à leur commande ; 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 toute 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 de négligence en termes de sécurité existe au niveau du code source et relève de la responsabilité directe du développeur.
Maintenant, la sécurité des données est un terrier de lapin sans fond, et il n'y a aucun moyen que je puisse même gratter la surface dans un seul message. Cependant, je souhaite couvrir la terminologie essentielle que les développeurs doivent connaître pour assurer la sécurité de leurs applications. Considérez-le comme App Data Security 101.
Commençons!
Hashing
Si vous voulez une définition très rigoureuse, il y a toujours Wikipédia, mais en termes simples, le hachage est le processus de conversion des données sous une autre forme, où les informations sont illisibles. Par exemple, en utilisant le processus bien connu (et très peu sûr) de Encodage Base64, la chaîne « Mon secret est-il en sécurité avec vous ? » peut être converti (« haché ») en « SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/ ». Si vous commencez à écrire votre journal personnel au format Base64, par exemple, votre famille n'a aucun moyen de lire vos secrets (à moins qu'elle ne sache décoder en Base64) !
Cette idée de brouiller les données est utilisée lors du stockage de mots de passe, de numéros de carte de crédit, etc., dans des 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, l'attaquant ne devrait pas être en mesure d'utiliser les mots de passe, les numéros de carte de crédit, etc., pour causer des dommages réels. Des algorithmes hautement robustes et sophistiqués sont utilisés pour effectuer ce hachage ; quelque chose comme Base64 sera une blague et sera cassé instantanément par n'importe quel attaquant.
Le hachage de mot 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échiffrer. Alors, comment l'application sait-elle qu'il s'agit de votre mot de passe lorsque vous vous connectez ? Eh bien, il utilise le même processus et compare la forme cryptée de ce que vous venez d'entrer comme mot de passe à la forme cryptée stockée dans la base de données ; s'ils correspondent, vous êtes autorisé à vous connecter !
Pendant que nous sommes sur le sujet des hachages, voici quelque chose d'intéressant. Si vous téléchargez un logiciel ou des fichiers sur Internet, on vous a peut-être demandé de vérifier les fichiers avant de les utiliser. Par exemple, si vous souhaitez télécharger le Ubuntu Linux ISO, la page de téléchargement vous montrera une option pour vérifier votre téléchargement ; si vous cliquez dessus, une fenêtre contextuelle s'ouvrira :
La fenêtre contextuelle vous dit 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 la Algorithme SHA256, dont vous pouvez voir la mention dans les parties finales de la commande : shasum -a 256 --check.
L'idée est que si le hachage produit par votre chèque est différent, cela signifie que quelqu'un s'est ingéré dans 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 mot de passe sont MD5 (non sécurisé et maintenant disparu), SHA-1 et SHA-2 (familles d'algorithmes, dont SHA-256 est membre, tout comme SHA-512), SCRYPTE, BCRYPT, etc.
Salting
Tous les types de sécurité sont un jeu du chat et de la souris : le voleur apprend le système actuel et trouve une nouvelle faille, qui est remarquée, et les serruriers améliorent leur jeu, et ainsi de suite. La cryptographie ne fait pas exception. Alors qu'il est devenu impossible de reconvertir les hachages en mots de passe, les attaquants ont développé au fil du temps des techniques sophistiquées qui combinent devinettes intelligentes avec une puissance de calcul pure ; en conséquence, neuf fois sur dix, ils peuvent prédire le mot de passe correct, étant donné uniquement le hachage.
En conséquence, la technique du salage s'est développée. Cela signifie simplement que le calcul de hachage d'un mot de passe (ou de toute 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. Donc, avec le salage, si on veut hacher le mot de passe superman009, nous sélectionnons d'abord une chaîne aléatoire en tant que « sel », disons : bCQC6Z2LlbAsqj77puis effectuez le calcul de hachage sur superman009-bCQC6Z2LlbAsqj77. Le hachage résultant s'écartera des structures habituelles produites par l'algorithme, réduisant considérablement la portée de l'intelligence ingénierie inverse ou conjecture.
Le hachage et le salage sont des domaines incroyablement compliqués et évoluent constamment. Ainsi, en tant que développeur d'applications, nous ne traiterions jamais directement avec eux. Mais cela nous aiderait grandement si nous les connaissions et pouvions prendre de meilleures décisions. Par exemple, si vous maintenez un ancien Cadre PHP et si vous voyez 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 de compte utilisateur.
Keys
Vous rencontrez souvent le terme « clés » dans le contexte du cryptage. Jusqu'à présent, nous avons couvert le hachage de mot de passe ou le cryptage à sens unique, où nous convertissons les données de manière irréversible et détruisons la forme d'origine. C'est une mauvaise idée pour une utilisation pratique quotidienne - un document écrit et envoyé par e-mail de manière si sécurisée qu'il ne peut jamais être lu ne sert à rien ! Ainsi, nous voulons crypter les données de manière à ce que les informations soient ouvertes avec l'expéditeur et le destinataire, mais pendant qu'elles sont transférées ou stockées, elles doivent être illisibles.
Pour cela, la notion de « clé » existe en cryptographie. C'est exactement ce que cela ressemble : la clé d'une serrure. La personne qui possède les informations les brouille à l'aide d'un secret appelé clé. À moins que le récepteur/attaquant n'ait cette clé, il est impossible de déchiffrer les données, quelle que soit la sophistication de leurs algorithmes.
Rotating Keys
Bien que les clés rendent le cryptage possible et fiable, elles comportent les risques que comportent les mots de passe : une fois que quelqu'un connaît la clé, tout le jeu est en place. Imaginez un scénario dans lequel quelqu'un pirate une partie d'un service comme GitHub (même pour quelques secondes) et peut mettre la main sur du code vieux de 20 ans. À l'intérieur du code, ils trouvent également les clés cryptographiques utilisées pour crypter les données de l'entreprise (une pratique horrible pour stocker les clés avec le code source, mais vous seriez surpris de la fréquence à laquelle cela se produit !). Si l'entreprise n'a pas pris la peine de changer ses clés (tout comme les mots de passe), la même clé peut être utilisée pour faire des ravages.
En conséquence, la pratique consistant à changer fréquemment de clés a évolué. C'est ce qu'on appelle la rotation des clés, et si vous utilisez un cloud respectable PaaS fournisseur, il devrait être disponible en tant que service automatisé.
Par exemple, AWS a un service dédié pour cela appelé Service de gestion des clés AWS (KMS). Un service automatisé vous évite les tracas liés au changement et à la distribution des clés entre tous les serveurs et est une évidence de nos jours lorsqu'il s'agit de grands déploiements.
Public Key Cryptography
Si toutes les discussions précédentes sur le cryptage et les clés vous font penser que c'est très lourd, vous avez raison. Garder les clés en sécurité et les transmettre afin que seul le destinataire puisse voir les données se heurte à des problèmes logistiques qui n'auraient pas permis aux communications sécurisées d'aujourd'hui de prospérer. Mais tout cela grâce à la cryptographie à clé publique, nous pouvons communiquer ou effectuer des achats en ligne en toute sécurité.
Ce type de cryptographie a été une percée mathématique majeure, et c'est la seule raison pour laquelle Internet ne s'effondre pas dans la peur et la méfiance. Les détails de l'algorithme sont complexes et hautement mathématiques, je ne peux donc l'expliquer que de manière conceptuelle ici.
La cryptographie à clé publique repose sur l'utilisation de deux clés pour traiter les informations. L'une des clés s'appelle Clé privée et est censée rester privée avec vous et ne jamais être partagée avec qui que ce soit ; l'autre s'appelle Public Key (d'où vient le nom de la méthode) et est censée être publiée publiquement. Si je vous envoie des données, je dois d'abord obtenir votre clé publique, chiffrer les données et vous les envoyer ; de votre côté, vous pouvez déchiffrer 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 est que je n'ai pas besoin de connaître votre clé privée, et 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 :
Il est difficile pour les ordinateurs de factoriser de grands nombres premiers. Ainsi, si la clé d'origine est très volumineuse, vous pouvez être sûr que le message ne pourra pas être déchiffré, même dans des milliers d'années.
Transport Layer Security (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 celle-ci) est à l'origine de toute la popularité du HTTPS et c'est ce qui fait dire à Chrome : "Ce site est sécurisé". Ce qui se passe, c'est que le serveur et le navigateur chiffrent le trafic HTTP (rappelez-vous, les pages Web sont de très longues chaînes de texte que les navigateurs peuvent interpréter) avec les clés publiques de l'autre, ce qui donne un HTTP sécurisé (HTTPS).
Crédit image : MozillaIl est intéressant de noter que le cryptage ne se produit pas sur la couche de transport en tant que telle ; les Modèle OSI ne dit rien sur le cryptage des données. C'est juste que les données sont cryptées par l'application (dans ce cas, le navigateur) avant d'être transmises à la couche de transport, qui les dépose plus tard à sa destination, où elles sont décryptées. Cependant, le processus implique la couche de transport et, en fin de compte, tout se traduit par un transport sécurisé des données, de sorte que le terme vague de sécurité de la couche de « transport » est resté.
Vous pourriez même rencontrer le terme Secure Socket Layer (SSL) dans certains cas. C'est le même concept que TLS, sauf que SSL a vu le jour bien avant et est maintenant supprimé en faveur de TLS.
Full Disk Encryption
Parfois, les besoins de sécurité sont si intenses que rien ne peut être laissé au hasard. Par exemple, les serveurs gouvernementaux où toutes les données biométriques d'un pays sont stockées ne peuvent pas être provisionnés et fonctionner comme des serveurs d'applications normaux car le risque est trop élevé. Il ne suffit pas pour ces besoins que les données soient cryptées uniquement lors de leur transfert ; il doit également être chiffré au repos. Pour ça, cryptage 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 violation physique.
Il est important de noter que le Full Disk Encryption doit être effectué au niveau 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. Ainsi, le matériel doit 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. En raison de ce travail supplémentaire effectué, le chiffrement complet du disque entraîne des lectures/écritures plus lentes, ce qui doit être pris en compte par les développeurs de tels systèmes.
End-to-End Encryption
Avec les cauchemars continus de confidentialité et de sécurité des grands réseaux sociaux de nos jours, 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 comment Full Disk Encryption fournit la stratégie ultime à l'épreuve des balles, mais pour l'utilisateur quotidien, ce n'est pas pratique. Je veux dire, imaginez que Facebook veut que les données téléphoniques qu'il génère et stocke dans votre téléphone soient sécurisées, mais il ne peut pas avoir accès au cryptage de votre téléphone entier et au verrouillage de tout le reste dans le processus.
Pour cette raison, ces entreprises ont commencé le cryptage de bout en bout, ce qui signifie que les données sont crypté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 cryptage de bout en bout (E2E) ne comporte aucune garantie mathématique comme le fait la cryptographie à clé publique ; il s'agit simplement d'un cryptage standard où la clé est stockée avec 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, ainsi qu'à évaluer à quel point vous les prenez au sérieux. N'oubliez pas que la sécurité des données des applications est une guerre que vous devez gagner à chaque fois (et pas une seule fois), car une seule violation suffit à détruire des industries, des carrières et même des vies entières !
