Chiffrement, gestion des clés et secrets

Ce que le chiffrement protège, et ce qu’il ne protège pas

Le chiffrement est souvent traité comme une case à cocher : « les données sont chiffrées en transit et au repos ». Cette formule masque la question qui compte, à savoir contre qui. Chaque couche de chiffrement protège les données contre certains acteurs et pas contre d’autres, et dans tous les cas la protection est exactement aussi solide que le contrôle exercé sur ceux qui peuvent utiliser la clé. Le chiffrement ne supprime pas le problème du contrôle d’accès ; il le déplace des données vers les clés, où il est généralement plus facile à gérer, à auditer et à révoquer.

Le chiffrement en transit empêche que des données qui traversent un réseau soient lues ou modifiées en chemin. Sur le web, cela signifie TLS, présenté au chapitre 0 ; entre services, cela signifie TLS ou TLS mutuel, abordé avec le zero trust. Le chiffrement au repos protège les données stockées, mais « au repos » ne désigne pas une seule chose : le tableau montre les couches courantes sur la plateforme de livraison de repas.

En lisant le tableau de haut en bas, chaque couche protège contre davantage d’acteurs et coûte davantage de fonctionnalités. Une conception saine utilise partout les couches bon marché et transparentes (TLS et le chiffrement du stockage sont presque gratuits aujourd’hui) et les couches coûteuses de façon sélective, pour les données dont l’exposition causerait le plus de tort. Décider de quelles données il s’agit relève de la classification des données, traitée plus loin dans cette section avec la tokenisation et un exemple commenté.

Cryptographie symétrique et asymétrique

Le chiffrement symétrique utilise une seule clé secrète pour chiffrer et déchiffrer. Il est assez rapide pour les données en masse, et l’algorithme standard est AES (FIPS 197, 2001), avec des clés de 128 ou 256 bits. Les conceptions modernes utilisent le chiffrement authentifié, qui détecte les falsifications en plus de masquer le contenu : AES en mode Galois/Counter (AES-GCM) ou ChaCha20-Poly1305 (RFC 8439). Les modes authentifiés exigent un nonce unique pour chaque message chiffré sous la même clé ; réutiliser un nonce avec AES-GCM peut révéler le texte en clair et permettre des falsifications, ce qui est l’une des nombreuses raisons d’utiliser des bibliothèques éprouvées plutôt que d’assembler soi-même des primitives.

La cryptographie asymétrique utilise une paire de clés : une clé publique que tout le monde peut détenir et une clé privée gardée secrète. Elle permet deux choses dont la cryptographie symétrique est incapable. L’accord de clés permet à deux parties qui ne se sont jamais rencontrées d’établir une clé symétrique partagée sur un réseau ouvert (Diffie-Hellman sur courbes elliptiques dans TLS 1.3). Les signatures numériques (RSA, ECDSA, Ed25519) permettent à quiconque possède la clé publique de vérifier que des données proviennent du détenteur de la clé privée et n’ont pas été modifiées, ce qui apporte l’intégrité, l’authenticité et une base pour la non-répudiation. Les opérations asymétriques sont lentes, si bien que les protocoles réels sont hybrides : TLS utilise la cryptographie asymétrique pour authentifier le serveur et convenir des clés, puis le chiffrement symétrique pour les données.

Un grand ordinateur quantique casserait les algorithmes RSA et à courbes elliptiques actuels, mais pas AES avec des clés suffisamment longues. En août 2024, le NIST a publié ses premières normes post-quantiques : FIPS 203 (ML-KEM, pour l’établissement de clés), FIPS 204 (ML-DSA) et FIPS 205 (SLH-DSA), ces deux dernières pour les signatures. Les données qui doivent rester confidentielles pendant de nombreuses années sont menacées dès aujourd’hui par des attaquants qui enregistrent maintenant le trafic chiffré pour le déchiffrer plus tard ; la réponse architecturale est donc l’agilité cryptographique : tenez un inventaire des endroits où chaque algorithme est utilisé, évitez de les coder en dur, et préférez des bibliothèques, des protocoles et des fournisseurs capables d’en changer, comme les grands navigateurs et les bibliothèques TLS ont commencé à le faire avec l’échange de clés hybride post-quantique.

Hachage, MAC, signatures et chiffrement sont des outils différents

Confondre ces primitives est une source courante de défauts de conception, comme « chiffrer » des mots de passe pour pouvoir les déchiffrer, ou se fier à un simple hachage pour prouver qu’un webhook provient d’un prestataire de paiement. Le tableau les présente côte à côte.

Stocker les mots de passe

Une fonction de hachage généraliste comme SHA-256 est conçue pour être rapide, ce qui est exactement l’inverse de ce qu’il faut pour les mots de passe : les processeurs graphiques peuvent tester des milliards d’essais par seconde contre une table volée de hachages rapides. Le hachage des mots de passe utilise des fonctions volontairement lentes et, idéalement, gourmandes en mémoire (memory-hard), afin que chaque essai coûte à l’attaquant du temps et de la mémoire bien réels, avec un sel aléatoire unique par mot de passe, pour que des mots de passe identiques produisent des hachages différents et que les tables précalculées soient inutiles.

L’OWASP Password Storage Cheat Sheet donne les recommandations actuelles par ordre de préférence. Argon2id (une variante d’Argon2, lauréat de la Password Hashing Competition de 2015), avec au minimum 19 Mio de mémoire, deux itérations et un degré de parallélisme de un (ou un compromis équivalent, comme 46 Mio avec une itération). scrypt lorsque Argon2id n’est pas disponible, avec un paramètre de coût de 2¹⁷ (128 Mio), une taille de bloc de 8 et un parallélisme de 1. bcrypt uniquement pour les systèmes hérités, avec un facteur de travail d’au moins 10, en gardant à l’esprit que la plupart des implémentations ignorent les entrées au-delà de 72 octets. Lorsque la conformité FIPS 140 est exigée, PBKDF2 avec HMAC-SHA-256 et 600 000 itérations. Ces valeurs augmentent à mesure que le matériel progresse : consultez donc la version actuelle de la cheat sheet plutôt que de recopier des chiffres dans un document de conception.

Trois points de conception en découlent. Stockez l’algorithme et les paramètres avec chaque hachage (les formats encodés standard le font), pour pouvoir relever les paramètres plus tard : lorsqu’un utilisateur se connecte avec succès, vérifiez le mot de passe par rapport à l’ancien hachage et recalculez immédiatement le hachage avec les nouveaux paramètres. Envisagez un poivre (pepper), un secret ajouté à chaque mot de passe avant le hachage et conservé dans un coffre-fort ou un HSM plutôt que dans la base de données, ce qui met en échec un attaquant qui ne vole que la base de données. Surtout, demandez-vous si vous devez vraiment stocker des mots de passe : déléguer l’authentification à un fournisseur d’identité et proposer des passkeys retire le secret le plus attaqué de la plupart de vos services.

Gestion des clés et chiffrement d’enveloppe

Les clés ont un cycle de vie, décrit dans la NIST SP 800-57 Part 1 : génération (à partir d’une source aléatoire appropriée), stockage, distribution, utilisation, rotation à la fin d’une cryptopériode définie, révocation en cas de compromission, et destruction. Faire tout cela de façon sûre à la main est irréaliste, c’est pourquoi les architectures s’appuient sur un service de gestion de clés (KMS) comme AWS KMS, Azure Key Vault ou Google Cloud KMS, ou sur un système auto-hébergé comme HashiCorp Vault. Un KMS conserve les clés maîtresses dans des modules de sécurité matériels (HSM), des dispositifs résistants aux manipulations validés selon FIPS 140, et effectue des opérations avec ces clés à la demande, sous réserve d’une politique d’accès, de sorte que les applications ne voient jamais les clés maîtresses et que chaque utilisation est journalisée.

Envoyer chaque enregistrement au KMS pour le chiffrer serait lent et coûteux, et les API de KMS limitent la taille des requêtes. Le chiffrement d’enveloppe (envelope encryption) résout ce problème. L’application demande au KMS une nouvelle clé de chiffrement des données (DEK) ; le KMS la renvoie deux fois, en clair et enveloppée (chiffrée) sous une clé de chiffrement de clés (KEK) qui ne quitte jamais le HSM. L’application chiffre les données localement avec la DEK en clair, efface la DEK de sa mémoire et stocke le texte chiffré avec la DEK enveloppée. Pour déchiffrer, elle n’envoie au KMS que la petite DEK enveloppée ; le KMS vérifie la permission de l’appelant, journalise la requête et renvoie la DEK.

import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

def encrypt_field(plaintext: bytes, kms, kek_id: str, context: bytes) -> dict:
    dek = AESGCM.generate_key(bit_length=256)            # fresh data key
    nonce = os.urandom(12)                               # never reuse with this key
    ct = AESGCM(dek).encrypt(nonce, plaintext, context)  # context binds it to its row
    wrapped = kms.encrypt(key_id=kek_id, plaintext=dek)  # KEK stays inside the KMS
    return {"ct": ct, "nonce": nonce, "wrapped_dek": wrapped, "kek": kek_id}

def decrypt_field(rec: dict, kms, context: bytes) -> bytes:
    dek = kms.decrypt(key_id=rec["kek"], ciphertext=rec["wrapped_dek"])  # checked, logged
    return AESGCM(dek).decrypt(rec["nonce"], rec["ct"], context)

Le chiffrement d’enveloppe présente plusieurs avantages architecturaux. La rotation est peu coûteuse : la rotation d’une KEK crée une nouvelle version de clé pour les nouvelles opérations d’enveloppement, tandis que les anciennes versions restent disponibles pour le déchiffrement ; les DEK existantes peuvent être réenveloppées sans toucher aux données, et un rechiffrement complet n’est nécessaire que si une DEK elle-même a pu être exposée. Le rayon d’impact est limité : avec une DEK par enregistrement, par fichier ou par partition, une DEK divulguée expose peu de choses. La séparation des tâches devient possible : le service des commandes peut utiliser sa KEK pour désenvelopper, mais ni modifier sa politique ni la supprimer, tandis que les administrateurs de la sécurité peuvent gérer les clés mais pas déchiffrer les données. Les hiérarchies de clés épousent l’organisation : une KEK par service et par classe de données, ou par locataire, si bien qu’une grande chaîne de restaurants pourrait même fournir et contrôler sa propre clé. Enfin, détruire une clé est un outil puissant : le crypto-shredding (effacement cryptographique) rend illisible toute copie des données chiffrées sous cette clé, y compris les sauvegardes et les journaux d’événements immuables, ce qui compte pour l’effacement au titre du RGPD et pour les systèmes en event sourcing.

Le prix à payer est une nouvelle dépendance critique. Si le KMS est indisponible, les données chiffrées ne peuvent pas être lues ; si une clé est supprimée par erreur, les données sont perdues pour de bon. Les KMS des fournisseurs de cloud imposent donc un délai d’attente avant suppression, et les architectes devraient traiter la suppression de clés et les modifications de politique de clé comme des opérations privilégiées, journalisées et à deux personnes, mettre brièvement en cache les DEK désenveloppées là où la latence des appels au KMS compte, et inclure le KMS dans les plans de reprise après sinistre.

Gestion des secrets

Un secret est tout identifiant qui donne un accès : mots de passe de bases de données, clés d’API du prestataire de paiement, clés privées, clés de signature, secrets clients OAuth, secrets de webhook. La gestion des secrets part d’une règle : les secrets ne vivent jamais dans le code source, ni dans les images de conteneur, ni dans les fichiers de configuration commités dans des dépôts, car ceux-ci sont copiés, mis en cache, forkés et lus par beaucoup plus de personnes et de systèmes que ne devrait l’être le secret. Une fois dans l’historique d’un dépôt, un secret y reste même après la suppression de la ligne.

Les secrets ont leur place dans un coffre-fort de secrets (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager) qui les stocke chiffrés, ne les remet qu’aux charges de travail authentifiées conformément à une politique, journalise chaque accès et prend en charge la rotation. Mieux encore que de renouveler des secrets de longue durée : ne pas en avoir. Un coffre-fort peut émettre des secrets dynamiques, comme un compte de base de données créé pour une instance de service avec un bail d’une heure, et l’identité de charge de travail permet aux services de s’authentifier auprès des API cloud et entre eux sans aucun secret stocké. Les secrets injectés à l’exécution devraient être lus dans des fichiers ou par l’API du coffre-fort plutôt que dans des variables d’environnement largement visibles, qui ont tendance à finir dans des vidages mémoire après plantage et dans des journaux de débogage.

La prévention exige de l’automatisation, car les gens font des erreurs. Les hooks de pré-commit et les scanners de pipeline (comme gitleaks et detect-secrets) interceptent les secrets avant qu’ils ne soient poussés ; les hébergeurs de dépôts recherchent les formats de secrets connus, et la push protection de GitHub bloque les push qui en contiennent. Les dépôts publics sont scannés par des attaquants dans les minutes qui suivent un push. Les conséquences sont bien documentées : en 2016, des attaquants qui avaient obtenu l’accès à un dépôt GitHub privé utilisé par des ingénieurs d’Uber y ont trouvé une clé d’accès au stockage cloud d’Uber et ont téléchargé les données à caractère personnel d’environ 57 millions de passagers et de chauffeurs.

La tokenisation et la réduction du périmètre PCI DSS

La tokenisation remplace une valeur sensible par un jeton qui n’a aucun lien mathématique avec elle ; la valeur réelle est conservée dans un coffre-fort séparé et étroitement protégé, et seul ce coffre-fort peut faire la correspondance inverse. Contrairement au chiffrement, un jeton volé ne peut pas être inversé avec une clé, car il n’y a pas de clé, seulement une consultation dans un système que l’attaquant ne contrôle pas.

Son usage le plus important concerne les paiements par carte. La Payment Card Industry Data Security Standard (PCI DSS, actuellement en version 4.0.1, publiée en juin 2024) s’applique à tout composant de système qui stocke, traite ou transmet des données de titulaires de carte, ou qui est connecté à ces composants ou pourrait en affecter la sécurité. Une plateforme qui laisse les numéros de carte transiter par ses serveurs fait entrer dans le périmètre son API gateway, ses services, ses journaux, ses réseaux et ses administrateurs, avec des centaines d’exigences et une évaluation annuelle. Une plateforme qui utilise les champs de paiement hébergés ou la redirection du prestataire de paiement, de sorte que les numéros de carte vont directement de l’appareil du client au prestataire, ne reçoit qu’un jeton et éventuellement les quatre derniers chiffres, et son périmètre PCI DSS se réduit considérablement : un petit commerçant peut avoir droit au questionnaire d’auto-évaluation le plus court, et même les plus grands commerçants, qui ont toujours besoin d’une évaluation annuelle par un évaluateur qualifié, ont beaucoup moins de systèmes à évaluer. C’est la conception retenue dans le modèle de menaces de l’étape de paiement : les données de carte les moins chères à protéger sont celles que vous ne détenez jamais. Chiffrer vous-même les numéros de carte ne permet pas la même réduction, car quiconque peut les déchiffrer reste dans le périmètre.

La même idée fonctionne pour d’autres identifiants sensibles. Un service interne de tokenisation peut remplacer les numéros de sécurité sociale ou de passeport par des jetons dans toute la plateforme, de sorte qu’un seul petit service, fortement protégé, voie jamais les valeurs réelles.

Classification des données

Les décisions de chiffrement, de tokenisation, de journalisation, de conservation et d’accès dépendent toutes de la connaissance du degré de sensibilité de chaque donnée. Un schéma de classification des données définit quelques niveaux assortis de règles de traitement, pour que les équipes ne tranchent pas chaque cas à partir de zéro. Quatre niveaux sont courants ; l’important est que chaque jeu de données du catalogue de données ou du schéma de la plateforme porte un niveau, et que les règles soient appliquées par des modèles et des contrôles plutôt que de mémoire.

Chiffrement au niveau des champs

Le chiffrement au niveau des champs, la couche applicative du premier tableau, chiffre des champs individuels avant leur écriture, généralement avec un chiffrement d’enveloppe et une KEK par classe de données. Sa force est que tout ce qui se trouve en aval de l’application ne détient que du texte chiffré : les administrateurs de bases de données, les répliques en lecture, les sauvegardes et l’entrepôt de données alimenté par capture des données modifiées. Une violation de l’un d’eux n’expose rien de lisible, et l’accès au texte en clair se réduit aux services qui peuvent appeler le KMS avec cette clé, chaque appel étant journalisé.

Ses coûts sont réels. La base de données ne peut plus indexer, rechercher, trier ni faire de jointure sur le champ chiffré. Les recherches d’égalité peuvent être rétablies avec un index aveugle (blind index), une colonne séparée qui contient un hachage à clé (HMAC) de la valeur normalisée, au prix de révéler quelles lignes partagent une même valeur. Le chiffrement déterministe présente la même fuite, tandis que les requêtes par plage nécessitent des schémas spécialisés ou ne devraient tout simplement pas être faites sur de tels champs. Certaines bases de données proposent un chiffrement côté client au niveau des champs ou un chiffrement interrogeable, qui intègrent ces techniques. En raison de ces coûts, le chiffrement au niveau des champs devrait être réservé aux données restreintes, dont les champs sont de toute façon rarement interrogés.