Le chiffrement est souvent un sujet de sécurité, mais il est également important pour la confidentialité. L'objectif du chiffrement est d'empêcher des tiers de lire les informations chiffrées, mais empêcher d'autres personnes de lire vos informations est un moyen de les garder privées. Un utilisateur est souvent limité dans les limites qu'il peut effectuer lui-même, mais avec votre aide en tant que fournisseur du service qu'il utilise, le chiffrement peut l'aider à conserver ses données.
Il existe trois façons pertinentes d'appliquer le chiffrement pour protéger la confidentialité des utilisateurs: le chiffrement en transit, le chiffrement au repos et le chiffrement de bout en bout:
- Le chiffrement en transit consiste à assurer le chiffrement des données entre l'utilisateur et votre site, c'est-à-dire HTTPS. Vous avez probablement déjà configuré le protocole HTTPS pour vos sites, mais êtes-vous sûr que toutes les données en transit vers vos sites sont chiffrées ? C'est à quoi servent la redirection et le mécanisme HSTS. Ils sont décrits ci-dessous et doivent faire partie de votre configuration HTTPS.
- Le chiffrement au repos consiste à chiffrer les données stockées sur vos serveurs. Cela constitue une protection contre les violations de données et constitue un élément important de votre stratégie de sécurité.
- Le chiffrement de bout en bout est le chiffrement des données sur le client avant qu'elles n'atteignent votre serveur. Cela protège les données utilisateur, même de votre part: vous pouvez stocker les données de vos utilisateurs, mais vous ne pouvez pas les lire. Cette solution est difficile à implémenter et n'est pas adaptée à tous les types d'applications, mais elle contribue fortement à préserver la confidentialité des utilisateurs, car personne d'autre ne peut voir leurs données.
HTTPS
La première étape consiste à diffuser votre service Web via HTTPS. Vous l'aurez probablement déjà fait, mais si ce n'est pas le cas, il s'agit d'une étape importante. HTTPS est HTTP, le protocole utilisé par un navigateur pour demander des pages Web à un serveur, mais chiffré à l'aide de SSL. Cela signifie qu'un pirate informatique externe ne peut pas lire ni interférer avec une requête HTTPS entre l'expéditeur (votre utilisateur) et le destinataire (vous), car elle est chiffrée et ne peut donc ni la lire, ni la modifier. Il s'agit du chiffrement en transit: lorsque les données sont transférées de l'utilisateur à vous, ou de vous à l'utilisateur. Le chiffrement HTTPS en transit empêche également le FAI de l'utilisateur ou le fournisseur du réseau Wi-Fi qu'il utilise de lire les données qu'il vous envoie dans le cadre de sa relation avec votre service. Cela peut également avoir un impact sur les fonctionnalités de votre service: de nombreuses utilisations des API JavaScript existantes nécessitent que le site Web soit diffusé via HTTPS. La liste MDN est plus complète, mais les API liées à un contexte sécurisé incluent les service workers, les notifications push, le partage Web et les cryptos Web, ainsi que certaines API d'appareils.
Pour diffuser votre site Web via HTTPS, vous aurez besoin d'un certificat SSL. Ceux-ci peuvent être créés sans frais via Let's Encrypt ou sont souvent fournis par votre service d'hébergement, le cas échéant. Il est également possible d'utiliser un service tiers qui constitue un "proxy" pour votre service Web et peut fournir des services HTTPS, de mise en cache et CDN. Il existe de nombreux exemples de services de ce type, tels que Cloudflare et Fastly. Le choix exact du service dépend de votre infrastructure actuelle. Auparavant, le protocole HTTPS pouvait être fastidieux ou coûteux à mettre en œuvre. C'est pourquoi il n'était généralement utilisé que sur les pages de paiement ou sur des origines particulièrement sécurisées. Cependant, des certificats disponibles sans frais, des améliorations des normes et une plus grande prolifération des navigateurs ont éliminé tous ces obstacles.
À faire
- Activez HTTPS sur vos serveurs pour tout (quelle que soit la méthode choisie).
- Envisagez d'utiliser un proxy, comme Cloudflare, devant vos serveurs (httpsiseasy.com/ explique le processus).
- Let's Encrypt vous guide tout au long du processus de création de votre propre certificat SSL Let's Encrypt.
- Vous pouvez également utiliser directement OpenSSL pour créer votre propre certificat et le faire signer par l'autorité de certification de votre choix. La section Activer HTTPS explique en détail comment procéder.
L'approche que vous choisissez dépend des compromis commerciaux. La gestion de la connexion SSL par un tiers est la plus simple à configurer, et offre d'autres avantages tels que l'équilibrage de charge, la mise en cache et l'analyse. Toutefois, cela s'accompagne également d'une dépendance évidente à ce tiers, ainsi que d'une dépendance inévitable vis-à-vis de ses services (et éventuellement d'un paiement, en fonction des services que vous utilisez et de vos niveaux de trafic).
Le processus SSL s'effectuait auparavant avant de générer des certificats et de les faire signer par une autorité de certification. Toutefois, l'utilisation de Let's Encrypt peut être plus facile si elle est prise en charge par votre fournisseur ou si votre équipe de serveurs est techniquement assez compétente pour cela, et qu'elle est sans frais. Il est également courant que votre fournisseur propose SSL en tant que service si vous utilisez un service à un niveau supérieur à celui de l'hébergement dans le cloud. Cela vaut donc la peine d'être vérifié.
Pourquoi
La sécurité fait partie de votre stratégie de confidentialité: être capable de démontrer que vous protégez les données utilisateur contre les interférences permet d'instaurer un climat de confiance. Si vous n'utilisez pas HTTPS, vos sites sont également signalés comme "non sécurisés" par les navigateurs (et ce depuis un certain temps). Les API JavaScript existantes ne sont souvent disponibles que pour les pages HTTPS ("origines sécurisées"). De plus, vos utilisateurs ne peuvent pas identifier leur utilisation du Web par leur FAI. Il s'agit sans aucun doute d'une bonne pratique. Il n'y a pratiquement aucune raison de ne pas utiliser le protocole HTTPS pour les sites Web pour l'instant.
Présentation d'une page HTTP (non sécurisée) dans les navigateurs
Rediriger vers HTTPS
Si votre site est disponible à la fois via des URL http: et https:, vous devez rediriger tous les accès des URL HTTP vers des URL https. C'est pour les raisons décrites ci-dessus, et cela garantit également que votre site ne s'affichera pas sur whynohttps.com s'il devient populaire. La procédure dépend en grande partie de votre infrastructure. Si vous êtes hébergé sur AWS, vous pouvez utiliser un équilibreur de charge classique ou d'application. Google Cloud est similaire. Dans Azure, vous pouvez créer une porte d'entrée ; dans Node avec Express, vérifier request.secure. Dans Nginx, capturer tous les ports 80 et renvoyer le port 301 ; et dans Apache, utiliser une règle RewriteRule. Si vous utilisez un service d'hébergement, il est fort probable qu'il gère automatiquement la redirection vers des URL HTTPS, comme le font Netlify, Firebase et les pages GitHub, entre autres.
HSTS
HSTS est l'abréviation de "HTTP Strict-Transport-Security" et permet de verrouiller définitivement un navigateur afin qu'il utilise HTTPS pour votre service. Une fois que vous êtes satisfait de votre migration vers HTTPS, ou si vous l'avez déjà fait, vous pouvez ajouter un en-tête de réponse HTTP Strict-Transport-Security à vos réponses sortantes. Un navigateur qui a déjà accédé à votre site auparavant enregistrera avoir vu cet en-tête. Dès lors, il accédera automatiquement à ce site en tant que HTTPS, même si vous demandez le protocole HTTP. Cela évite de passer par la redirection comme indiqué ci-dessus: le navigateur "met à jour " silencieusement toutes les requêtes adressées à votre service pour qu'elles utilisent HTTPS.
De même, vous pouvez diffuser un en-tête Upgrade-Insecure-Requests avec vos pages. Ceci est différent, mais lié à Strict-Transport-Security. Si vous ajoutez Upgrade-Insecure-Requests: 1, les requêtes de cette page vers d'autres ressources (images, scripts) seront demandées au format HTTPS, même si le lien est http. Cependant, le navigateur ne demandera pas à nouveau la page elle-même en tant que HTTPS et ne le mémorisera pas pour la prochaine fois. En pratique, les demandes de mise à niveau non sécurisées sont utiles si vous convertissez un site existant contenant de nombreux liens au format HTTPS et que vous avez du mal à convertir les URL des liens dans le contenu. Toutefois, il est préférable de modifier le contenu dans la mesure du possible.
HSTS est avant tout une fonctionnalité de sécurité: il "verrouille" votre site sur HTTPS pour les utilisateurs qui s'y sont déjà rendus. Toutefois, comme ci-dessus, HTTPS est bon pour la confidentialité, et HSTS est bon pour HTTPS. De même, les demandes de mise à niveau non sécurisées ne sont pas indispensables si vous mettez à jour l'ensemble de votre contenu. Toutefois, il s'agit d'une approche "ceinture et accolades" utile pour renforcer la défense en profondeur afin de garantir que votre site utilise toujours le protocole HTTPS.
À faire
Ajoutez l'en-tête HSTS à vos réponses sortantes:
Strict-Transport-Security: max-age=300; includeSubDomains
Le paramètre max-age détermine la durée, en secondes, pendant laquelle le navigateur doit mémoriser et appliquer la mise à niveau HTTPS. (Ici, nous la réglons sur 300 secondes, soit cinq minutes.) Vous voudriez à terme que ce chiffre s'élève à 6 3072 000, soit deux ans, et soit le chiffre recommandé par hstspreload.org, mais il est assez difficile de le récupérer en cas de problème. Nous vous recommandons donc de définir d'abord un nombre faible (300), d'effectuer un test pour vérifier que tout n'a pas fonctionné, puis d'augmenter ce nombre par étapes.
Ajoutez les en-têtes Upgrade-Insecure-Requests à vos réponses sortantes:
Upgrade-Insecure-Requests: 1
Content-Security-Policy: upgrade-insecure-requests
Chiffrement de bout en bout
Un bon moyen de garantir la confidentialité des données utilisateur consiste à ne les montrer à personne d'autre que l'utilisateur, vous y compris. Cela aide considérablement votre position de confiance: si vous ne disposez pas des données de vos utilisateurs, il est clair que vous ne pouvez pas les utiliser comme bon vous semble. Pour ce faire, l'une des méthodes consiste à ne pas laisser les données utilisateur quitter leur appareil, en stockant toutes les données côté client. Cette approche fonctionne, mais il existe des limites pour une application purement côté client: le stockage de données du navigateur peut être limité en taille et, dans certains navigateurs, il peut être effacé avec peu ou pas d'avertissement. Il est également difficile, voire impossible, d'accéder à vos données sur deux appareils, tels qu'un ordinateur portable et un téléphone mobile. Pour cette raison, il peut être utile d'envoyer des données au serveur normalement, mais de les chiffrer avec une clé connue uniquement de l'utilisateur, de sorte que le serveur ne puisse pas y accéder (car il ne peut pas les déchiffrer), mais peut les stocker.
Comment ça marche ?
Cette approche est fréquemment utilisée par les applications de messagerie, où elle est appelée "chiffrement de bout en bout" ou "e2e". De cette manière, deux personnes qui connaissent les clés de l'autre peuvent chiffrer et déchiffrer leurs messages dans les deux sens, puis les envoyer via le fournisseur de messagerie, mais ce dernier (qui ne possède pas ces clés) ne peut pas les lire. La plupart des applications ne sont pas des applications de messagerie, mais il est possible de combiner les deux approches (un magasin de données uniquement côté client et le chiffrement des données avec une clé connue du client) pour stocker les données localement, mais également les envoyer sous forme chiffrée au serveur. Il est important de comprendre que cette approche présente des limites: elle n'est pas possible pour tous les services et, en particulier, elle ne peut pas être utilisée si, en tant que fournisseur de services, vous avez besoin d'accéder à ce que l'utilisateur stocke. Comme décrit dans la partie 2 de cette série, il est préférable de respecter le principe de minimisation des données ; évitez autant que possible de collecter des données. Si l'utilisateur a besoin de stocker des données, mais que vous n'avez pas besoin d'y accéder pour fournir le service, le chiffrement de bout en bout est une alternative utile. Si vous fournissez des services qui nécessitent de pouvoir voir ce que l'utilisateur stocke pour fournir le service, le chiffrement de bout en bout n'est pas adapté. Toutefois, si ce n'est pas le cas, vous pouvez faire en sorte que le code JavaScript côté client de votre service Web chiffre toutes les données qu'il envoie au serveur et les déchiffre.
Exemple: Excalidraw
Excalidraw explique comment faire dans un article de blog. Il s'agit d'une application de dessin vectoriel qui stocke les dessins sur le serveur, lesquels sont chiffrés avec une clé choisie de manière aléatoire. Excalidraw peut implémenter ce chiffrement de bout en bout avec relativement peu de code si cela s'explique en partie par le fait que les bibliothèques cryptographiques sont désormais intégrées au navigateur avec window.crypto, un ensemble d'API JavaScript compatibles avec tous les navigateurs modernes. La cryptographie est difficile et la mise en œuvre
des algorithmes s'accompagne de nombreux cas particuliers. Le fait de laisser le navigateur faire le gros du travail ici rend le chiffrement plus accessible aux développeurs Web et facilite donc la mise en œuvre de la confidentialité via des données chiffrées. Comme le décrit Excalidraw dans son texte, la clé de chiffrement reste côté client, car elle fait partie du fragment d'URL: lorsqu'un navigateur visite une URL https://example.com/path?param=1#fraghere, le chemin de l'URL (/path) et les paramètres (param=1) sont transmis au serveur (example.com), mais pas le fragment (fraghere). Le serveur ne le voit donc jamais. Cela signifie que même si les données chiffrées passent par le serveur, la clé de chiffrement ne le fait pas. La confidentialité est donc préservée, car les données sont chiffrées de bout en bout.
Limites
Cette approche du chiffrement des données utilisateur n'est pas infaillible. Elle contribue à votre position de confiance envers vos utilisateurs, mais ne peut pas la remplacer complètement. Vos utilisateurs devront toujours faire confiance à votre service, car vous pouvez à tout moment remplacer le code JavaScript côté client par un code JavaScript subtilement similaire qui ne chiffre pas les données de manière infaillible. Même s'il est possible, en tant qu'utilisateur, de détecter si un site Web que vous utilisez a fait cela, il est extrêmement difficile de le faire. En pratique, vos utilisateurs auront toujours besoin de faire confiance à un fournisseur de données, même s'il n'est pas fiable pour prouver que ces données ne sont pas délibérément chiffrées.
Il est également important de se rappeler que l'un des objectifs du chiffrement de bout en bout est de vous empêcher, en tant que propriétaire du site, de lire les données. C'est une bonne chose pour la confidentialité, mais cela signifie aussi que vous ne pouvez pas intervenir en cas de problème. En substance, un service utilisant le chiffrement de bout en bout donne à l'utilisateur le contrôle des clés de chiffrement. (Cela n'est peut-être ni évident, ni évident, mais quelqu'un doit disposer de la clé, et si les données restent privées, il ne s'agit pas de vous.) Si ces clés sont perdues, vous ne pourrez rien faire pour vous aider, et probablement toutes les données chiffrées avec ces clés risquent également d'être perdues. Il existe un équilibre délicat entre confidentialité et facilité d'utilisation: préserver la confidentialité des données pour tous les utilisateurs à l'aide du chiffrement, mais également éviter d'obliger les utilisateurs à être des experts en cryptologie qui gèrent leurs propres clés de manière sécurisée.
Chiffrement au repos
Outre le chiffrement des données de vos utilisateurs en transit, il est également important de penser à chiffrer les données que vous avez stockées sur le serveur. Cela permet de vous protéger contre les violations de données, car toute personne qui obtient un accès non autorisé à vos données stockées possède des données chiffrées, qu'elle espère ne pas avoir les clés à déchiffrer. Il existe deux approches différentes et complémentaires pour chiffrer les données au repos : le chiffrement que vous ajoutez et le chiffrement ajouté par votre fournisseur de stockage cloud (si vous faites appel à un fournisseur de stockage cloud). Le chiffrement du fournisseur de stockage n'offre pas une protection renforcée contre les violations de données via votre logiciel (car le chiffrement du fournisseur de stockage est généralement transparent pour vous en tant qu'utilisateur de son service), mais il aide à lutter contre les violations survenant sur son infrastructure. Elle est souvent simple à activer et mérite donc d'être envisagée. Ce champ change rapidement et votre équipe de sécurité (ou les ingénieurs chevronnés de votre équipe) sont les mieux placés pour le conseiller. Toutefois, tous les fournisseurs de stockage cloud proposent le chiffrement au repos pour le stockage de blocs Amazon S3 en définissant Azure Storage et Google Cloud Storage par défaut, ainsi que pour le stockage de données de base de données AWS RDS, Azure SQL et Google Cloud SQL, entre autres. Vérifiez auprès de votre fournisseur de stockage cloud, si vous en utilisez un. Il est plus difficile de gérer vous-même le chiffrement des données au repos afin de protéger les données utilisateur contre les violations de données, car il est difficile de gérer les clés de chiffrement de manière sécurisée et de les rendre disponibles au code sans les rendre accessibles aux pirates informatiques. Ce n'est pas l'endroit idéal pour obtenir des conseils sur les problèmes de sécurité à ce niveau. Discutez-en avec vos ingénieurs ou une équipe dédiée, ou avec des agences de sécurité externes.