Amazon Aurora ajoute l’échange de clés post-quantique à PostgreSQL 18
AWS permet désormais de choisir des groupes d’échange de clés hybrides ML-KEM sur Aurora PostgreSQL 18 via le paramètre ssl_groups, sans redémarrage. Activez-le sur les bases qui portent des données à longue durée de vie pour neutraliser la collecte « harvest now, decrypt later ».
29 octobre 2026. AWS annonce la prise en charge de l’échange de clés post-quantique dans Amazon Aurora PostgreSQL-Compatible Edition. Aurora PostgreSQL 18 et supérieur uniquement. Un seul paramètre à modifier : ssl_groups. Le cloud vient d’abaisser le coût d’une défense qui ressemblait encore, il y a un an, à un chantier de migration réservé aux laboratoires.
Pourquoi l’échange de clés, et pas le chiffrement
Le risque que AWS adresse ici n’est pas le chiffrement des données, mais la négociation de la clé qui le protège. En TLS, le contenu des échanges est chiffré par un algorithme symétrique comme AES ou ChaCha20, que l’ordinateur quantique ne casse pas directement. Ce qu’il casse, via l’algorithme de Shor, c’est l’échange de clés : ECDHE, X25519 et le RSA reposent tous sur des problèmes mathématiques qu’un ordinateur quantique suffisamment grand résout en temps polynomial.
Un attaquant qui capture aujourd’hui du trafic chiffré n’a donc pas besoin de le déchiffrer maintenant. Il le stocke, puis le déchiffrera quand un ordinateur quantique à tolérance de fautes sera disponible. Cette stratégie porte un nom : « harvest now, decrypt later ». Pour une base de données, l’enjeu est maximal : les données personnelles, médicales ou financières ont une durée de vie légale et commerciale qui se compte en décennies, très au-delà de l’horizon raisonnable d’un déchiffreur quantique.
La réponse de l’industrie s’appelle ML-KEM, pour Module-Lattice-Based Key-Encapsulation Mechanism. C’est l’algorithme standardisé par le NIST en août 2024 sous la référence FIPS 203. Il ne « remplace » pas l’échange de clés classique : il encapsule une clé dans un problème de réseau euclidien, réputé résistant au quantique.
Ce que fait exactement le paramètre ssl_groups
Concrètement, Aurora PostgreSQL 18 expose un paramètre de cluster nommé ssl_groups, hérité de PostgreSQL 18 lui-même. C’est un paramètre dynamique : la modification ne demande aucun redémarrage de l’instance.
La valeur par défaut reste classique : prime256v1:X25519. La nouveauté est une liste blanche de cinq valeurs autorisées, dont deux groupes hybrides :
- X25519MLKEM768 — un hybride X25519 + ML-KEM-768 ;
- SecP256r1MLKEM768 — un hybride P-256 (ECDHE) + ML-KEM-768 ;
- X25519, prime256v1, secp384r1 — les groupes classiques conservés en secours.
L’ordre de la liste fixe la préférence du serveur. Le premier groupe que le client prend aussi en charge est celui qui est utilisé pour la connexion. Pour activer l’échange post-quantique, on fait donc basculer la valeur du paramètre :
aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name mon-aurora-pg18 \
--parameters "ParameterName=ssl_groups,ParameterValue=X25519MLKEM768:X25519,ApplyMethod=immediate"Le point important : le groupe hybride X25519MLKEM768 conserve la composante X25519. Si la partie ML-KEM venait à être cassée demain, la partie classique assurerait toujours la confidentialité. C’est précisément ce qui rend le déploiement défendable en production aujourd’hui, alors que ML-KEM est encore jeune.
La contrainte cachée : ML-KEM exige TLS 1.3
Activer ssl_groups ne suffit pas. La documentation AWS pose deux conditions que beaucoup vont découvrir après coup.
D’abord, les groupes ML-KEM ne fonctionnent qu’en TLS 1.3. Une connexion qui retombe en TLS 1.2 ignore purement et simplement ssl_groups pour ce qui concerne les échanges RSA. Pour être certain que le post-quantique s’applique, il faut donc combiner trois paramètres :
aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name mon-aurora-pg18 \
--parameters "ParameterName=ssl_min_protocol_version,ParameterValue=TLSv1.3,ApplyMethod=immediate"
aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name mon-aurora-pg18 \
--parameters "ParameterName=rds.force_ssl,ParameterValue=1,ApplyMethod=immediate"rds.force_ssl impose le chiffrement de toutes les connexions, et ssl_min_protocol_version à TLSv1.3 élimine la retombée silencieuse en TLS 1.2. Sans cette seconde ligne, une application ancienne pourrait négocier un échange classique et vous croire protégé — un faux sentiment de sécurité qui est exactement ce que le post-quantique doit éviter.
La contrepartie est une contrainte opérationnelle réelle : tout client qui ne parle pas TLS 1.3 sera refusé. Sur un parc hétérogène de connecteurs, c’est un test de compatibilité à planifier avant la bascule, pas une option à cocher un vendredi soir.
Le vrai travail reste côté client
La moitié serveur est simple — c’est l’autre moitié qui demande du travail. Le groupe X25519MLKEM768 ne se négocie que si le client le prend aussi en charge. Cela dépend de la pile logicielle :
- libpq et les pilotes officiels PostgreSQL reposent sur OpenSSL ; le support de ML-KEM et des groupes hybrides n’est présent que dans les versions récentes de la bibliothèque ;
- les pilotes JDBC, .NET ou les drivers d’ORM embarquent leur propre pile TLS, dont le support post-quantique est inégal ;
- les connection pools comme PgBouncer ou les proxys d’accès interposent leur propre terminaison TLS : un pool en TLS 1.2 annulerait le gain côté serveur.
La conséquence pratique est qu’un déploiement complet passe par un inventaire des clients avant d’activer la bascule stricte. AWS offre ici une transition en douceur : on peut d’abord placer X25519MLKEM768 en tête de ssl_groups tout en laissant X25519 en secours. Les clients post-quantiques négocient l’hybride, les anciens retombent sur X25519. On mesure l’adoption, puis on durcit avec ssl_min_protocol_version.
Des poignées de main plus lourdes, mais pas plus lentes là où ça compte
ML-KEM n’est pas gratuit au niveau du fil. Une part de clé hybride X25519MLKEM768 est nettement plus volumineuse qu’une part X25519 classique — le texte chiffré ML-KEM-768 pèse à lui seul 1 088 octets, contre 32 octets pour une clé publique X25519. Le coût se traduit par un ClientHello et un ServerHello légèrement plus gros, et quelques millisecondes supplémentaires à l’établissement de la session — pas sur le chiffrement symétrique qui suit. Pour une application qui mutualise ses sessions via un pool, le coût amorti est négligeable ; pour un parc qui ouvre des milliers de connexions courtes par seconde, mesurez avant de basculer.
C’est précisément l’intérêt de la posture hybride par défaut : on conserve X25519 dans la liste, et la négociation ne paie le coût ML-KEM que lorsque les deux côtés le supportent. Une première étape saine consiste à activer le groupe hybride, puis à observer la latence et le taux d’erreur des connexions pendant une semaine avant d’imposer TLS 1.3.
Ce que cela dit de la maturité du post-quantique
L’annonce d’AWS s’inscrit dans une bascule plus large que les équipes ont parfois du mal à dater. NIST a publié FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) et FIPS 205 (SLH-DSA) en août 2024. Les navigateurs et les grands fournisseurs déploient déjà des groupes hybrides, et Aurora rejoint un mouvement où le post-quantique cesse d’être une veille pour devenir un paramètre de configuration.
Ce qui change ici, c’est le seuil d’entrée. Jusqu’à présent, sécuriser une base contre la collecte différée impliquait de maintenir sa propre bibliothèque cryptographique, de compiler des versions à jour et de gérer les incompatibilités soi-même. Avec Aurora PostgreSQL 18, la moitié serveur tient dans un paramètre sans redémarrage. C’est le signe que le post-quantique entre dans l’ère du service managé.
Il ne faut pas surinterpréter pour autant. ML-KEM-768 correspond au niveau de sécurité 3 du NIST, comparable à l’AES-192. Il n’est pas « incassable » : il est réputé résistant aux attaques quantiques connues, et les implémentations sont encore en phase de maturation, comme l’ont montré les ajustements du NIST entre les versions successives de ses standards.
Verdict
Si vous exploitez Aurora PostgreSQL 18 ou supérieur avec des données personnelles, de santé ou financières dont la durée de vie dépasse dix ans, activez ssl_groups avec X25519MLKEM768 en tête dès maintenant : le coût est quasi nul, aucun redémarrage n’est requis, et le groupe hybride conserve X25519 en secours. Durcissez ensuite progressivement : forcez TLS 1.3 via ssl_min_protocol_version une fois l’inventaire des clients validé, et imposez rds.force_ssl. Si votre base ne porte que des données éphémères ou déjà exposées, la bascule n’est pas urgente — mais profitez de la prochaine mise à niveau majeure pour l’intégrer, car le coût de la migration ne fera qu’augmenter à mesure que le parc de clients vieillit. Et si vous opérez des versions antérieures à 18, retenez l’échéance : la fenêtre de collecte « harvest now » est déjà ouverte, et chaque mois d’attente rend le déchiffrement différé plus probable.