Connexion sécurisée à MySQL - Chicoree

1 Préambule

Je suppose ici que vous avez déjà installé MySQL et que vous êtes un minimum familier de son utilisation. Je vais donc rapidement passer sur la création de la base qui nous servira de support. Notez tout de même que je crée au passage un utilisateur autorisé à faire des requêtes SELECT sur les tables:

1.1 Créer la base

1.2 Interroger la base avec le client MySQL

Comme vous le constatez, les informations stockées dans cette table sont critiques. Et vous comprenez bien que les clients n'ont pas envie que n'importe qui sache quels films ils ont loués... Faisons justement une requête qui permet d'extraire ces informations. Comme vous le remarquerez, ici cette requête sera effectuée sous l'identité de audit, l'utilisateur légitime de la base, dûment authentifié par son mot de passe:

2 Utiliser SSL pour sécuriser la connexion

Une solution pour supprimer les risques de captures d'information par écoute directe, est d'utiliser la possibilité pour MySQL d'établir une connexion utilisant SSL (Secure Sockets Layer) entre le client et le serveur. C'est ce que nous allons faire maintenant.

2.1 SSL en quelques mots

SSL permet de crypter la communication entre deux machines. Et donc de communiquer de manière sécurisée au travers d'un réseau ouvert comme internet. Outre le cryptage à proprement parler, SSL dispose également de mécanismes qui permettent de garantir l'intégrité des données transmises, de détecter la perte de données ou encore le fait que des trames soient répétées ou permutées.

2.2 Certificat racine

Pour que ce mécanisme fonctionne, il va de soi que celui qui veut prouver son identité, et la personne à qui il veut le prouver doivent être d'accord pour accepter le même tiers de confiance.

2.3 Certificat racine autosigné

Il est aussi possible de générer soi-même des certificats racine. Dans ce cas, on parle de certificats autosignés. Ceux-ci peuvent être utilisés exactement comme les certificats racine émis par une autorité. La différence? Et bien, comme il n'y a plus de tiers de confiance connu impliqué pour garantir votre identité, si vous émettez vos propres certificats racine, vos correspondants devront vous faire confiance. Par ailleurs, il faudra aussi diffuser de manière fiable votre certificat racine auprès de vos clients.

2.4 Certificat serveur

Pour que le serveur puisse prouver son identité, il est nécessaire que celui-ci fournisse un certificat signé par une autorité de certification. Tout d'abord, il faut commencer par générer une demande de certificat:

2.5 Certificat client

SSL permet éventuellement d'authentifier les deux parties d'une communication (le serveur et le client, par exemple). Cela nous servira dans un instant. On procède exactement de la même manière pour obtenir le certificat client que le certificat serveur:

3 Configurer le serveur pour utiliser un certificat

Vous pouvez configurer le serveur MySQL pour qu'il utilise un certificat pour prouver son identité et crypter la communication en modifiant le fichier de configuration de my.conf. Vous devrez rajouter les options ssl-ca, ssl-cert et ssl-key. Recherchez la section [mysqld] et modifiez ces options en conséquence:

4 Se connecter avec le client avec SSL

Pour le client, vous pouvez également utiliser my.cnf pour le configurer. Ou à la place passer les arguments nécessaires sur la ligne de commande au moment de son invocation:

4.1 Forcer l'utilisation de SSL

Très bien, nous pouvons nous connecter en utilisant SSL. Mais rien ne nous empêche pour l'instant de nous connecter sans! C'est à dire, comme au début de cet article, en faisant passer les données en clair. Il est parfois nécessaire de n'accepter que des communications sécurisées. Dans MySQL il est possible d'exiger une communication cryptée lorsque l'on fixe les permissions pour un utilisateur à l'aide de la clause REQUIRE SSL de la commande SQL GRANT:

4.2 Authentification mutuelle

Authentifier le serveur et exiger une communication cryptée est déjà un bon début. Mais il est parfois aussi nécessaire de vérifier l'identité du client. C'est à dire de faire l'authentification mutuelle du client et du serveur. Dans ce cadre, MySQL propose diverses solutions pour s'assurer avec plus ou moins de force de l'identité du client que nous allons maintenant détailler.

4.2.1 Forcer l'utilisation d'un certificat X.509

La première manière de procéder va être d'exiger de la part du client un certificat X.509:

4.2.2 Forcer la vérification du sujet du certificat (SUBJECT)

Dans la version précédente, le simple fait de fournir un certificat signé par une autorité reconnue par le serveur permet d'authentifier le client. Mais jusqu'à présent les informations contenues dans le certificat n'avaient pas eu d'importance.

4.2.3 Forcer la vérification de l'émetteur du certificat (ISSUER)

Enfin, il est aussi possible d'exiger que le certificat fourni par le client soit émis (signé) par une certaine autorité:

4.2.4 Combinaisons

Pour terminer il faut signaler que les clauses REQUIRE ISSUER et REQUIRE SUBJECT peuvent être combinées. Par ailleurs, il existe aussi une clause REQUIRE CIPHER qui permet d'exiger une certaine force de chiffrement, et qui peut être utilisée seule ou combinée aux deux clauses mentionnées ci-dessus. Je vous invite à vous reporter à la documentation de MySQL pour en savoir plus.

5 Conclusion

Un élément aussi critique qu'un serveur de base de données mérite bien qu'on investisse un peu de temps pour le sécuriser. Ici, nous avons parlé exclusivement de SSL, mais ne vous y trompez pas: "passer le serveur en SSL" ne suffit pas à le sécuriser! Si votre serveur est par ailleurs fragile, SSL ne vous "sauvera pas la mise". C'est juste un élément de plus dans l'arsenal de la sécurisation de votre serveur de bases de données. Mais un élément important!