Chiffrer les communications entre serveurs applicatifs et base de données avec TLS interne

require_secure_transport = ON : cette directive, une fois posée dans la configuration MySQL, refuse toute connexion qui n’utilise pas TLS, y compris depuis une machine du même réseau privé. Elle part d’un constat simple : un réseau privé partagé entre plusieurs machines virtuelles, chez un fournisseur cloud, n’est pas automatiquement un réseau de confiance absolue, surtout lorsque d’autres locataires du même fournisseur partagent la même infrastructure physique sous-jacente.

Dès qu’un serveur applicatif et son serveur de base de données sont séparés sur deux machines distinctes, une décision architecturale de plus en plus courante pour isoler la charge, le trafic MySQL circule sur le réseau reliant les deux machines. Sans chiffrement, ce trafic reste lisible par quiconque parviendrait à intercepter les paquets à ce niveau, mots de passe compris lors de l’authentification initiale.

Générer les certificats nécessaires à la liaison chiffrée

MySQL prend en charge TLS nativement pour les connexions entrantes, à condition de disposer d’une autorité de certification interne, même minimale, pour signer les certificats du serveur et, si l’authentification mutuelle est souhaitée, ceux des clients applicatifs. La génération d’une autorité de certification locale s’effectue avec OpenSSL :

openssl genrsa 2048 > ca-key.pem
openssl req -new -x509 -nodes -days 3650 \
  -key ca-key.pem -out ca-cert.pem \
  -subj "/CN=Autorite-Interne-WPModerne"

Un certificat serveur est ensuite signé par cette autorité, pour le serveur MySQL exclusivement, avec une durée de validité plus courte que celle de l’autorité elle-même, en anticipation d’un renouvellement régulier.

Activer TLS côté serveur MySQL

Une fois les certificats générés, la configuration du serveur MySQL référence chacun d’eux dans son fichier principal :

[mysqld]
ssl_ca = /etc/mysql/certs/ca-cert.pem
ssl_cert = /etc/mysql/certs/server-cert.pem
ssl_key = /etc/mysql/certs/server-key.pem
require_secure_transport = ON

La directive require_secure_transport, disponible depuis plusieurs versions de MySQL et de MariaDB, empêche toute connexion en clair, y compris depuis une adresse IP interne au réseau privé, ce qui garantit qu’aucune connexion applicative oubliée ne contourne silencieusement le chiffrement.

Configurer le client applicatif côté serveur web

Côté serveur applicatif, la connexion PHP vers MySQL doit explicitement demander TLS et vérifier le certificat présenté par le serveur, faute de quoi une interception de type intermédiaire malveillant resterait possible malgré l’activation du chiffrement côté serveur :

$mysqli = mysqli_init();
mysqli_ssl_set(
    $mysqli,
    null,
    null,
    '/etc/mysql/certs/ca-cert.pem',
    null,
    null
);
mysqli_real_connect(
    $mysqli,
    '10.0.0.20',
    'wordpress_user',
    'mot_de_passe',
    'wordpress',
    3306,
    null,
    MYSQLI_CLIENT_SSL
);

L’argument MYSQLI_CLIENT_SSL, passé lors de l’établissement de la connexion, impose l’usage de TLS pour cette session ; la référence au certificat de l’autorité interne permet à PHP de vérifier que le serveur contacté est bien celui attendu, et non une machine ayant usurpé son adresse sur le réseau privé.

Vérifier que la connexion est effectivement chiffrée

Une fois la configuration en place, une requête directe depuis une session MySQL confirme l’état réel de la connexion, plutôt que de se fier uniquement à l’absence d’erreur de connexion :

SHOW STATUS LIKE 'Ssl_cipher';

Une valeur non vide dans le résultat confirme qu’un algorithme de chiffrement est effectivement utilisé pour la session en cours ; une valeur vide indique une connexion toujours en clair, malgré une configuration apparemment correcte, souvent due à un client qui n’a pas transmis les bons paramètres de connexion.

Renouveler les certificats sans interrompre le service

• Programmer une alerte plusieurs semaines avant l’expiration du certificat serveur, distincte de celle utilisée pour les certificats TLS publics du site.
• Tester le renouvellement sur un environnement de recette avant de l’appliquer en production, un certificat MySQL mal renouvelé bloquant immédiatement toutes les connexions applicatives.
• Conserver l’ancien certificat quelques jours après le renouvellement, le temps de confirmer qu’aucune connexion résiduelle ne l’utilise plus.

Le réseau privé d’un fournisseur cloud protège d’un accès extérieur non autorisé ; il ne garantit rien contre une observation interne à l’infrastructure partagée. TLS entre applicatif et base de données ferme cette dernière fenêtre.

Ce que ce chiffrement ne couvre pas

Cette mise en place protège les données en transit entre les deux serveurs ; elle ne traite pas du chiffrement au repos des données stockées sur le disque du serveur de base de données lui-même, qui répond à une menace différente et nécessite un dispositif distinct.

En résumé

Chiffrer la liaison entre serveur applicatif et serveur de base de données avec TLS ferme une fenêtre d’interception souvent négligée dès lors que les deux rôles sont séparés sur des machines distinctes. Deux fichiers de configuration suffisent à cette mise en place, moyennant une autorité de certification interne et une vérification régulière, via Ssl_cipher, que le chiffrement reste effectivement actif après chaque modification de configuration.