Chapitre 9.2 — Mesures techniques

⏱️ TL;DR — Les mesures techniques sont la partie du dev : chiffrement en transit (TLS/HTTPS partout, sans exception), chiffrement au repos (base et sauvegardes), pseudonymisation pour réduire l’exposition, et surtout le hachage des mots de passe. Ici, il n’y a pas de débat : un mot de passe se hache avec un algorithme lent et salé (bcrypt, argon2), jamais en clair, jamais avec MD5 ou SHA-1 seuls. Ajoute une gestion propre des secrets (clés hors du code) et des sauvegardes chiffrées et testées. Ces mesures ne sont pas du luxe : ce sont les fondamentaux attendus de tout le monde.

🎯 Objectifs

• Mettre du chiffrement en transit (TLS/HTTPS) et comprendre le chiffrement au repos.
• Distinguer chiffrement (réversible) et hachage (à sens unique) — et savoir quand utiliser quoi.
• Hacher correctement un mot de passe (bcrypt/argon2, sel) et reconnaître les mauvaises pratiques.
• Gérer les secrets et clés hors du code, et faire des sauvegardes chiffrées et testées.
• Employer la pseudonymisation comme mesure de réduction du risque.

Chiffrer en transit : HTTPS partout, point

Toute donnée personnelle qui circule sur le réseau doit être chiffrée en transit via TLS (le S de HTTPS). Sans ça, un intermédiaire sur le réseau peut lire les mots de passe, les cookies de session, les contenus. Ce n’est plus négociable en 2026 : HTTPS sur tout le trafic, y compris les sous-domaines internes, les API et les webhooks.

Règles simples et non négociables :

• Aucune page de connexion, aucun formulaire, aucune API en http:// simple.
• Redirection systématique de http vers https, en-tête HSTS pour forcer le navigateur.
• Pas de contenu mixte (une page https qui charge une ressource http).
• Certificats à jour (le renouvellement automatique évite les oublis).

⚠️ Piège — « L’appli interne / l’environnement de recette n’a pas besoin de HTTPS. » Faux : la recette contient souvent des copies de vraies données (ou des données réalistes), et les réseaux « internes » ne sont pas des zones de confiance. On chiffre en transit partout, prod comme hors-prod.

Chiffrer au repos : base et sauvegardes

Le chiffrement au repos protège les données stockées (base, disques, sauvegardes) si le support est volé, la sauvegarde égarée ou un accès disque compromis. La plupart des hébergeurs et moteurs de base proposent le chiffrement du disque et des sauvegardes : active-le. Pour les données très sensibles (santé, par exemple), on peut aller plus loin avec un chiffrement applicatif de certaines colonnes.

Point clé : le chiffrement au repos protège contre le vol du support, pas contre un attaquant qui a des droits applicatifs légitimes. Si ton appli peut lire la colonne en clair, un attaquant qui prend le contrôle de l’appli le peut aussi. Le chiffrement au repos complète le contrôle d’accès (chapitre 9.3), il ne le remplace pas.

Chiffrement vs hachage : ne confonds jamais les deux

Deux opérations qu’on mélange en permanence, avec des usages opposés.

La règle d’or : un mot de passe ne se chiffre pas, il se hache. Tu n’as jamais besoin de relire un mot de passe — tu as seulement besoin de vérifier qu’un mot de passe fourni correspond à celui enregistré. Le hachage à sens unique est exactement fait pour ça.

Hacher un mot de passe correctement

Trois exigences, non négociables :

1. Un algorithme de hachage de mot de passe dédié, conçu pour être lent et coûteux à calculer : argon2 (recommandé aujourd’hui) ou bcrypt. La lenteur est une fonctionnalité : elle ralentit les attaques par force brute.
2. Un sel unique par mot de passe (les bibliothèques bcrypt/argon2 le gèrent automatiquement et l’intègrent au résultat) — ça neutralise les tables précalculées.
3. Jamais de stockage en clair, jamais MD5 ou SHA-1 seuls (rapides, cassés pour cet usage), jamais ta propre « fonction maison ».

import argon2 from "argon2"
 
// ✅ BON — hachage lent et salé, à sens unique
export async function hasherMotDePasse(motDePasse: string): Promise<string> {
  // argon2 gère le sel automatiquement et l'inclut dans le hash retourné
  return argon2.hash(motDePasse)
}
 
export async function verifierMotDePasse(hash: string, saisie: string): Promise<boolean> {
  // Comparaison à temps constant, fournie par la bibliothèque
  return argon2.verify(hash, saisie)
}
 
// À l'inscription : on ne stocke QUE le hash
const hash = await hasherMotDePasse(motDePasseEnClair)
await db.users.create({ email, passwordHash: hash })
// motDePasseEnClair sort de la mémoire, on ne le journalise ni ne le renvoie JAMAIS

Variante bcrypt si c’est ta stack : le principe est identique (fonction dédiée, sel auto, vérification par la bibliothèque).

import bcrypt from "bcrypt"
 
// ✅ BON — bcrypt : algorithme lent, sel intégré au résultat
export async function hasher(motDePasse: string): Promise<string> {
  const coutTravail = 12 // facteur de coût : à augmenter avec le temps et le matériel
  return bcrypt.hash(motDePasse, coutTravail)
}
 
export async function verifier(hash: string, saisie: string): Promise<boolean> {
  return bcrypt.compare(saisie, hash)
}

Et le contre-exemple, celui qui apparaît vraiment dans des bases piratées :

// ❌ MAUVAIS — à ne JAMAIS faire, sous aucun prétexte
 
// 1) Stockage en clair : une fuite de la base = tous les mots de passe exposés
await db.users.create({ email, password: motDePasseEnClair })
 
// 2) "Chiffré" avec une clé stockée à côté : réversible = pas mieux qu'en clair
await db.users.create({ email, password: chiffrer(motDePasseEnClair, CLE) })
 
// 3) MD5 / SHA-1 seuls : rapides à casser, tables précalculées, pas de sel
import crypto from "crypto"
const empreinte = crypto.createHash("md5").update(motDePasseEnClair).digest("hex")
await db.users.create({ email, password: empreinte }) // faussement rassurant

⚠️ Piège — « On hache déjà, on est bons » — alors que c’est du SHA-256 sans sel en une passe. SHA-256 est excellent pour l’intégrité (vérifier qu’un fichier n’a pas changé), mais inadapté aux mots de passe : il est rapide, donc friable en force brute, et sans sel il expose aux tables précalculées. Pour un mot de passe, il faut un algorithme lent et salé : argon2 ou bcrypt. La rapidité, ici, est un défaut.

💡 Réflexe — Ne réinvente jamais la cryptographie. Utilise une bibliothèque éprouvée (argon2, bcrypt pour les mots de passe ; les primitives standard pour le reste), garde-la à jour, et prévois de ré-hacher les mots de passe le jour où l’utilisateur se reconnecte, si tu montes le coût de travail ou changes d’algorithme. « Fait maison » en crypto = faille garantie.

Pseudonymisation : réduire l’exposition

La pseudonymisation (déjà vue au chapitre 1.1) est citée par l’article 32 comme mesure de sécurité. Rappel : elle remplace les identifiants directs par un pseudonyme, mais une table de correspondance permet encore de remonter à la personne — la donnée reste personnelle, mais elle est moins exposée.

En pratique côté dev : séparer les identités directes (nom, e-mail) des données d’usage, référencer par un user_id opaque, restreindre l’accès à la table de correspondance. Si un jeu de données « travail » fuit sans la table d’identités, le préjudice est moindre. Ce n’est pas de l’anonymisation (on ne sort pas du RGPD), mais c’est une vraie réduction de risque.

Secrets et clés : hors du code, toujours

Le meilleur chiffrement ne vaut rien si la clé traîne dans le dépôt Git. Règles :

• Aucun secret (clé d’API, mot de passe de base, clé de chiffrement) en dur dans le code ou committé dans Git.
• Secrets via variables d’environnement ou un gestionnaire de secrets dédié.
• Rotation possible des clés, et séparation des environnements (les secrets de prod ne sont pas ceux de dev).
• Une clé de chiffrement se stocke séparément des données qu’elle protège (sinon voler la base, c’est voler la clé avec).

⚠️ Piège — Le fichier .env avec les vrais secrets committé « par erreur », ou une clé d’API collée dans le code front (donc publique). Un secret dans l’historique Git y reste même après suppression : il faut le considérer comme compromis et le faire tourner (le révoquer et en générer un nouveau).

Sauvegardes : chiffrées et testées

Une sauvegarde sert deux propriétés de l’article 32 : la disponibilité et la résilience. Mais deux conditions, souvent oubliées :

• Chiffrées : une sauvegarde est une copie complète de tes données personnelles ; si elle fuite, c’est une violation. Elle doit être chiffrée au repos, comme la base.
• Testées : une sauvegarde qu’on n’a jamais restaurée n’est pas une sauvegarde, c’est une hypothèse. Le jour de l’incident n’est pas le bon moment pour découvrir qu’elle est corrompue ou incomplète. On planifie des restaurations d’essai régulières.

🧭 Sur FormaCampus — Concrètement : HTTPS sur tout (site, API, espace organisme) ; mots de passe apprenants et formateurs hachés en argon2 ; colonne « aménagement de handicap » (santé) chiffrée au repos avec une clé gérée hors du code ; user_id opaque pour séparer identités et résultats (pseudonymisation) ; pas de données bancaires stockées (délégation à un prestataire de paiement) ; sauvegardes quotidiennes chiffrées et une restauration d’essai documentée chaque trimestre. Chaque mesure est notée dans la politique de sécurité pour être démontrable.

🔒 Côté personne concernée — Un apprenant ne verra jamais ton argon2, mais il en vit les effets : le jour où une autre plateforme se fait pirater et que ses mots de passe fuitent, ceux hachés correctement résistent — les siens ne finissent pas en clair sur un forum. Le hachage, c’est la différence entre « une fuite embêtante » et « tous mes comptes ailleurs sont désormais en danger » (car les gens réutilisent leurs mots de passe).

📚 Le texte — L’article 32 cite explicitement le chiffrement et la pseudonymisation parmi les mesures appropriées, ainsi que la capacité à rétablir la disponibilité et l’accès aux données en cas d’incident (d’où l’exigence de sauvegardes fiables). Le RGPD ne nomme pas d’algorithme précis : les recommandations techniques (longueurs de clé, algorithmes du moment) relèvent des guides de la CNIL et de l’ANSSI, à consulter pour les paramètres à jour.

✏️ Exercices

Exercice 1 — Chiffrer ou hacher ? Pour chaque donnée, dis s’il faut la chiffrer (réversible) ou la hacher (à sens unique) : (a) le mot de passe d’un compte ; (b) le numéro de carte d’un moyen de paiement à ré-afficher partiellement ; (c) une colonne « santé » qu’un médecin scolaire doit relire ; (d) un jeton d’API que le système doit renvoyer au client.

Exercice 2 — Repère les fautes. Revue de code : crypto.createHash("sha1").update(password) pour stocker un mot de passe, la clé AES en constante dans le fichier source, et les sauvegardes en clair sur un bucket public. Trois problèmes — nomme-les et corrige.

Exercice 3 — Pourquoi « lent » est une qualité ? Explique en deux phrases pourquoi un algorithme rapide comme SHA-256 est un mauvais choix pour les mots de passe, alors que c’est un bon choix pour vérifier l’intégrité d’un fichier.

🧠 Quiz de révision

Chapitre suivant : Contrôle d’accès & habilitations — moindre privilège, rôles (RBAC), authentification forte (MFA), revue des accès et cloisonnement.