Schémas d’implémentation de TLS mutuel (mTLS)

Le TLS standard authentifie uniquement le serveur auprès du client au moyen d’un certificat. Le TLS mutuel (mTLS) étend ce mécanisme : les deux parties présentent et vérifient leurs certificats. Le client présente un certificat client après que le serveur l’a demandé au moyen de CertificateRequest pendant la négociation TLS. Le serveur vérifie le certificat client auprès d’une CA de confiance. mTLS constitue le fondement des réseaux sans confiance implicite : au lieu de s’appuyer sur la sécurité du périmètre réseau, les services s’authentifient mutuellement par voie cryptographique à chaque connexion. Les architectures de maillage de services comme Istio, Linkerd et Consul Connect mettent en œuvre mTLS de manière transparente entre les microservices.

La négociation mTLS étend TLS 1.3 de la manière suivante : après ServerHello, puis le certificat et le message de fin du serveur, le serveur envoie un message CertificateRequest qui précise les autorités de certification et les algorithmes de signature acceptés. Le client répond avec son certificat (la chaîne de certificats client) et CertificateVerify (une signature de la transcription de la négociation réalisée avec la clé privée du client). Le serveur vérifie la chaîne de certificats client auprès de son magasin de CA de confiance et valide la signature CertificateVerify. Si les deux vérifications réussissent, la connexion est authentifiée mutuellement. Le client ne peut pas contrefaire CertificateVerify sans la clé privée correspondant au certificat.

Dans les environnements de maillage de services, les certificats clients sont généralement délivrés par une CA interne. Istio utilise les SVID de SPIFFE (cadre d’identité de production sécurisée pour tous) : chaque charge de travail reçoit un certificat contenant une SAN de type URI SPIFFE (nom alternatif du sujet), telle que spiffe://cluster.local/ns/default/sa/payment-service. Ces certificats ont une courte durée de vie, généralement 24 heures, et sont renouvelés automatiquement par le plan de contrôle du maillage (istiod). Pour le mTLS destiné aux utilisateurs, par exemple dans un VPN d’entreprise ou pour des clients d’API, les certificats peuvent être délivrés par une CA d’entreprise, avoir des durées de vie plus longues et être distribués via MDM (gestion des appareils mobiles) sur les appareils des employés.

La vérification mTLS côté serveur comporte plusieurs étapes : (1) Validation de la chaîne — vérifier que le certificat client remonte jusqu’à une CA racine de confiance dans le magasin de CA client du serveur. (2) Vérification de la période de validité — s’assurer que le certificat n’est pas expiré et que sa période de validité a commencé. (3) Vérification de la révocation — vérifier au moyen d’OCSP ou de CRL que le certificat n’a pas été révoqué. (4) Correspondance SAN/CN — extraire l’identité déclarée du certificat SAN (URI SPIFFE, nom DNS ou adresse électronique). (5) Autorisation — vérifier que l’identité authentifiée est autorisée à accéder à la ressource demandée. Les étapes 4 et 5 nécessitent une logique au niveau de l’application qui dépasse la configuration TLS de base.

Les certificats à courte durée de vie éliminent le besoin d’une révocation explicite : si un certificat expire après 24 heures, la fenêtre d’impact d’une compromission est limitée. Le renouvellement nécessite : (1) Renouvellement anticipé — délivrer un nouveau certificat avant l’expiration de l’ancien, en effectuant le renouvellement à 80 % de sa durée de vie. (2) Remplacement sans interruption de service — le service doit accepter les anciens et les nouveaux certificats pendant la période de transition. (3) Rechargement sans interruption — la pile TLS doit recharger les informations d’identification sans interrompre les connexions existantes (nginx : nginx -s reload ; Envoy : mise à jour dynamique du certificat xDS). L’API de charge de travail SPIFFE, mise en œuvre par SPIRE, automatise la distribution et le renouvellement des certificats via une API de socket de domaine Unix.

Istio implémente mTLS de manière transparente au moyen de proxys auxiliaires Envoy injectés dans chaque pod. Le plan de contrôle (istiod) agit comme une CA en utilisant un certificat intermédiaire signé par la CA racine du maillage. Le proxy auxiliaire de chaque pod reçoit un SVID SPIFFE via l’interface SDS (service de découverte des secrets). Les politiques PeerAuthentication configurent le mode mTLS : STRICT (mTLS obligatoire), PERMISSIVE (mTLS et texte en clair acceptés, pour la migration) ou DISABLE. Les ressources AuthorizationPolicy définissent les services autorisés à communiquer, en vérifiant l’identité SPIFFE dans le certificat client. Cela met en œuvre une confiance zéro au sein du cluster sans modifier le code de l’application.

Pour les clients externes d’interfaces de programmation, mTLS fournit une authentification plus forte que les clés d’interface ou les jetons OAuth. Le client conserve une clé privée dans un stockage sécurisé (HSM, magasin de clés du système d’exploitation ou clé logicielle protégée par une phrase secrète). Le certificat client est épinglé à la CA attendue du point de terminaison de l’interface. Chaque requête d’interface est authentifiée au niveau TLS : aucun en-tête Authorization distinct n’est nécessaire. La protection des interfaces de programmation de Cloudflare, les certificats clients de la passerelle d’interfaces de programmation d’AWS et le mTLS des comptes de service de Google Cloud appliquent tous ce modèle. Une clé d’interface compromise peut être utilisée depuis n’importe où ; une clé privée mTLS compromise exige également le vol de l’appareil exécutant le client.

Les déploiements mTLS présentent plusieurs difficultés opérationnelles. (1) Distribution des certificats : fournir les certificats clients de manière sécurisée à tous les services, en particulier dans les environnements dynamiques où le nombre de pods augmente et diminue. (2) Compromission de la CA : la CA interne est une cible de grande valeur ; si elle est compromise, tous les certificats de service sont invalidés. Les CA protégées par HSM et les CA racines hors ligne réduisent ce risque. (3) Débogage : le trafic mTLS chiffré est opaque pour les outils de débogage standard ; l’observabilité du maillage de services (Jaeger, Kiali) est nécessaire. (4) Compatibilité avec les équipements intermédiaires : les proxys d’inspection TLS interrompent mTLS sauf s’ils sont explicitement configurés pour transmettre les certificats clients. (5) Incidents d’expiration des certificats : un échec de rotation peut provoquer des interruptions complètes du service.

SPIFFE (cadre d’identité sécurisé pour tous les environnements de production) définit une norme d’identité des charges de travail utilisant des SVID X.509. SPIRE (environnement d’exécution SPIFFE) en est l’implémentation de référence. Le serveur SPIRE agit comme autorité d’enregistrement et CA. Les agents SPIRE s’exécutent sur chaque nœud et attestent l’identité des charges de travail à l’aide d’attesteurs de nœud (identité d’instance AWS, JWT de compte de service Kubernetes, TPM) et d’attesteurs de charge de travail (PID Unix, métadonnées du moteur de conteneurs). L’interface des charges de travail fournit les SVID aux charges de travail via un socket de domaine Unix utilisant une interface gRPC simple. SPIRE s’intègre à Envoy, Nginx et aux principaux maillages de services comme source de certificats.

Pour les déploiements mTLS à haute sécurité, les clés privées doivent résider dans des modules de sécurité matérielle (HSM) plutôt que dans des magasins de clés logiciels. La bibliothèque TLS (OpenSSL, BoringSSL) charge la clé privée via l’interface PKCS#11, qui redirige les opérations de signature vers le HSM. La clé privée ne quitte jamais la limite du HSM sous forme de texte en clair. Parmi les options HSM infonuagiques figurent AWS CloudHSM, Azure Dedicated HSM et Google Cloud HSM. Pour le mTLS au niveau des appareils (IdO, ordinateurs portables d’entreprise), le TPM 2.0 fournit une fonction similaire : la clé client TLS est liée au TPM et la signature exige une autorisation du TPM, ce qui rend l’extraction de la clé depuis un appareil compromis extrêmement difficile.

Tester mTLS nécessite des outils prenant en charge la présentation d’un certificat client. OpenSSL s_client : openssl s_client -connect host:443 -cert client.pem -key client.key -CAfile server-ca.pem. curl : curl --cert client.pem --key client.key --cacert server-ca.pem https://host. Pour tester un maillage de services, istioctl proxy-config secret pod/name affiche le certificat actuel et son expiration. Exécutez kubectl exec dans un pod, puis utilisez curl sur le point de terminaison d’administration du proxy auxiliaire (localhost:15000) pour inspecter les écouteurs actifs et leur configuration mTLS. Les tests automatisés de rotation doivent vérifier que les connexions restent stables pendant les événements de rotation des certificats.

Quelle étape supplémentaire mTLS ajoute-t-il par rapport à TLS standard ?

mTLS ajoute l’authentification par certificat client à TLS : les deux parties vérifient leurs certificats respectifs. Les SVID SPIFFE fournissent une identité standardisée aux charges de travail grâce aux URI SPIFFE dans les SAN des certificats. Istio implémente mTLS de manière transparente au moyen de proxys auxiliaires Envoy avec les modes STRICT/PERMISSIVE. Les certificats à courte durée de vie (24 h) éliminent le besoin de révocation et limitent la période d’exploitation d’une compromission. SPIRE automatise l’émission et la rotation des certificats via l’interface des charges de travail. Les clés privées mTLS doivent résider dans des HSM ou des TPM pour les déploiements à haute sécurité. Les difficultés opérationnelles comprennent la protection des clés de CA, la compatibilité avec les équipements intermédiaires et la rotation sans interruption de service.