L'un des principaux facteurs et fondamentaux de la gouvernance des données est la sécurité. C'est une bonne pratique d'avoir mis en place la sécurité de la base de données chaque fois que vous avez votre gestion de données impliquée pour une entreprise ou une consommation de masse.
La sécurité des données est l'un des aspects les plus importants de l'administration d'une base de données. Il joue un rôle critique pour lequel chaque gestion de base de données devrait mettre en œuvre. Lorsqu'il est implémenté et fait correctement, le résultat améliore non seulement la sécurité de vos données, mais affecte également la stabilité du système, améliore le cycle de vie du développement, renforce la conformité de vos données et améliore la sensibilisation à la sécurité jusqu'au niveau de votre équipe. Tout le monde ne veut pas que ses données se retrouvent entre de mauvaises mains. Si des données sont violées, cela met non seulement en danger la confidentialité et l'intégrité de vos données, mais expose également votre organisation à des risques financiers importants. Même pour une simple implémentation de gestion de base de données, si vous découvrez que quelqu'un s'est déjà introduit dans votre système, le sentiment d'insécurité et de peur des conséquences qui pourraient vous en résulter est totalement inconfortable.
Déterminer si votre connexion au serveur MySQL est sûre dépend de la sécurité avec laquelle MySQL transmet les données en transit. Avec une connexion non chiffrée entre le client MySQL et le serveur, une personne ayant accès au réseau pourrait surveiller tout votre trafic et inspecter les données envoyées ou reçues entre le client et le serveur.
Lorsque vous devez déplacer des informations sur un réseau de manière sécurisée, une connexion non chiffrée est inacceptable. Pour rendre tout type de données illisibles, utilisez le cryptage. Les algorithmes de chiffrement doivent inclure des éléments de sécurité pour résister à de nombreux types d'attaques connues telles que la modification de l'ordre des messages chiffrés ou la relecture des données deux fois.
Mais mon MySQL est sûr, non ?
Croire que votre MySQL est sûr sans déterminer sa stabilité et ses vérifications de vulnérabilité est comme une religion. Vous avez tendance à croire même sans le voir, même sans le toucher. Le problème est que MySQL est une technologie et que son existence n'est pas basée sur des pensées abstraites. Cela doit être testé, cela doit être prouvé, et cela nécessite de la sécurité et suit les meilleures pratiques qui ont également été testées par d'autres.
Déterminer si vos connexions au serveur MySQL, c'est-à-dire en transit, sont sécurisées ou si elles sont cryptées repose sur "comment avez-vous configuré votre base de données ?" ou "qui a configuré votre base de données ?".
MySQL prend en charge les connexions cryptées entre les clients et le serveur à l'aide du protocole TLS (Transport Layer Security). TLS est parfois appelé SSL (Secure Sockets Layer) mais MySQL n'utilise pas réellement le protocole SSL pour les connexions cryptées car son cryptage est faible et SSL a déjà été déprécié en faveur de TLS. TLS utilise des algorithmes de chiffrement pour garantir que les données reçues sur un réseau public sont fiables. Il dispose de mécanismes pour détecter la modification, la perte ou la relecture de données. TLS intègre également des algorithmes qui fournissent une vérification d'identité à l'aide de la norme X.509. SSL ou TLS sont utilisés de manière interchangeable, mais pour le contexte de chiffrement avec MySQL, TLS est utilisé pour lequel MySQL prend en charge les connexions chiffrées à l'aide des protocoles TLSv1, TLSv1.1, TLSv1.2 et TLSv1.3.
X.509 permet d'identifier quelqu'un sur Internet. En termes simples, il devrait y avoir une entité appelée « autorité de certification » (ou CA) qui attribue des certificats électroniques à toute personne qui en a besoin. Les certificats reposent sur des algorithmes de chiffrement asymétriques qui ont deux clés de chiffrement (une clé publique et une clé secrète). Un propriétaire de certificat peut présenter le certificat à une autre partie comme preuve d'identité. Un certificat est constitué de la clé publique de son propriétaire. Toute donnée chiffrée à l'aide de cette clé publique ne peut être déchiffrée qu'à l'aide de la clé secrète correspondante, qui est détenue par le propriétaire du certificat.
Tout comme les Spartiates utilisaient Scytale
Scytale est connu pour être utilisé comme moyen de chiffrer et de déchiffrer un message qui était utilisé vers 400 av. par les Spartiates. Ils écrivaient un message sur une feuille de papyrus (un type de papier) enroulée autour d'un bâton. Le destinataire ne peut déchiffrer le message que si le diamètre et la taille du bâton sont corrects. Il sert de moyen de crypter et d'éviter l'extraction non autorisée de messages ou de données vers la destination cible.
Tout comme avec MySQL, l'utilisation des protocoles et des chiffrements SSL/TLS est un moyen d'éviter que quelqu'un extraie vos données ou détourne vos données lorsqu'elles passent par le câble ou sur Internet.
Par défaut, les programmes MySQL tentent de se connecter en utilisant le cryptage si le serveur prend en charge les connexions cryptées, revenant à une connexion non cryptée si une connexion cryptée ne peut pas être établie. Depuis la version MySQL>=5.7, les fichiers TLS/SSL et RSA peuvent être créés ou générés avec le support de variables. Pour les distributions MySQL compilées à l'aide d'OpenSSL, le serveur MySQL a la capacité de générer automatiquement les fichiers SSL et RSA manquants au démarrage. Les variables système auto_generate_certs, sha256_password_auto_generate_rsa_keys et caching_sha2_password_auto_generate_rsa_keys (version>=8.0) contrôlent la génération automatique de ces fichiers. Ces variables sont activées par défaut. Ils peuvent être activés au démarrage et inspectés mais pas définis lors de l'exécution.
Par défaut, ces variables sont définies sur ON ou activées. Sinon, les utilisateurs peuvent invoquer manuellement l'utilitaire mysql_ssl_rsa_setup. Pour certains types de distribution, tels que les packages RPM et DEB, l'invocation de mysql_ssl_rsa_setup se produit lors de l'initialisation du répertoire de données. Dans ce cas, la distribution MySQL n'a pas besoin d'être compilée avec OpenSSL tant que la commande openssl est disponible.
Une fois ces fichiers disponibles et/ou générés, MySQL n'utilisera toujours pas les connexions de chiffrement pour les raisons suivantes. Comme mentionné précédemment, par défaut, les programmes clients MySQL tentent d'établir une connexion cryptée si le serveur prend en charge les connexions cryptées, avec un contrôle supplémentaire disponible via le mode --ssl (ou --ssl <=5.7.11 car cela est déjà obsolète) choix :
-
Par défaut, si la connexion MySQL n'est pas marquée avec --ssl-mode, la valeur par défaut est définie sur --ssl-mode=PRÉFÉRÉ. Par conséquent, les clients tentent de se connecter en utilisant le cryptage, revenant à une connexion non cryptée si une connexion cryptée ne peut pas être établie.
-
Avec --ssl-mode=REQUIRED, les clients nécessitent une connexion chiffrée et échouent si aucune ne peut être établie.
-
Avec --ssl-mode=DISABLED, les clients utilisent une connexion non chiffrée.
-
Avec --ssl-mode=VERIFY_CA ou --ssl-mode=VERIFY_IDENTITY, les clients nécessitent une connexion chiffrée et également effectuer une vérification par rapport au certificat CA du serveur et (avec VERIFY_IDENTITY) par rapport au nom d'hôte du serveur dans son certificat.
Avec le mécanisme par défaut de MySQL pour utiliser une connexion préférée, il essaie probablement d'essayer d'utiliser la connexion cryptée ou sécurisée, mais cela laisse encore des choses à faire et à déterminer.
Comme mentionné précédemment, les variables auto_generate_certs, sha256_password_auto_generate_rsa_keys et caching_sha2_password_auto_generate_rsa_keys (version>=8.0) aident à générer les fichiers SSL/TLS et RSA requis, l'utilisateur normal sans ces exigences lors de la connexion doit toujours être précaire. Par exemple, créons un utilisateur appelé dbadmin.
mysql> create user 'dbadmin'@'192.168.40.%' identified by '[email protected]';
Query OK, 0 rows affected (0.01 sec)
mysql> GRANT ALL PRIVILEGES ON *.* TO 'dbadmin'@'192.168.40.%';
Query OK, 0 rows affected (0.01 sec)Vérifiez ensuite si les variables sont correctement définies, ce qui devrait être activé tel qu'il est par défaut :
mysql> show global variables where variable_name in ('auto_generate_certs','sha256_password_auto_generate_rsa_keys','caching_sha2_password_auto_generate_rsa_keys');
+----------------------------------------------+-------+
| Variable_name | Value |
+----------------------------------------------+-------+
| auto_generate_certs | ON |
| caching_sha2_password_auto_generate_rsa_keys | ON |
| sha256_password_auto_generate_rsa_keys | ON |
+----------------------------------------------+-------+
3 rows in set (0.00 sec)Vérifier si les fichiers sont générés en conséquence dans le chemin /var/lib/mysql/ (ou le chemin de datadir pour ce MySQL) :
$ find /var/lib/mysql -name "*.pem"
/var/lib/mysql/ca-key.pem
/var/lib/mysql/ca.pem
/var/lib/mysql/server-key.pem
/var/lib/mysql/server-cert.pem
/var/lib/mysql/client-key.pem
/var/lib/mysql/client-cert.pem
/var/lib/mysql/private_key.pem
/var/lib/mysql/public_key.pemVérifiez ensuite si les fichiers SSL sont chargés correctement :
mysql> show global variables like 'ssl%';
+---------------+-----------------+
| Variable_name | Value |
+---------------+-----------------+
| ssl_ca | ca.pem |
| ssl_capath | |
| ssl_cert | server-cert.pem |
| ssl_cipher | |
| ssl_crl | |
| ssl_crlpath | |
| ssl_fips_mode | OFF |
| ssl_key | server-key.pem |
+---------------+-----------------+
8 rows in set (0.00 sec)Déterminez la sécurité de votre connexion
Maintenant, ça a l'air bien. Cela signifie également que MySQL est prêt à accepter les connexions cryptées. Mais en se connectant à MySQL tel quel, comme indiqué, il doit utiliser --ssl-mode=PREFFERED par défaut, ou si --ssl-mode n'est pas spécifié, il sera toujours restauré pour utiliser une connexion non chiffrée. Voir ci-dessous :
$ mysql [email protected] -h 192.168.40.110 -udbadmin -e "status;"|grep ssl -i
SSL : Non utilisé
Cela révèle qu'il n'utilise pas de connexion sécurisée. La vérification des variables d'état de session SSL si des chiffrements sont utilisés révèle vide :
mysql> show global status like 'ssl%';
+--------------------------------+--------------------------+
| Variable_name | Value |
+--------------------------------+--------------------------+
| Ssl_accept_renegotiates | 0 |
| Ssl_accepts | 2 |
| Ssl_callback_cache_hits | 0 |
| Ssl_cipher | |
| Ssl_cipher_list | |
| Ssl_client_connects | 0 |
| Ssl_connect_renegotiates | 0 |
| Ssl_ctx_verify_depth | 18446744073709551615 |
| Ssl_ctx_verify_mode | 5 |
| Ssl_default_timeout | 0 |
| Ssl_finished_accepts | 2 |
| Ssl_finished_connects | 0 |
| Ssl_server_not_after | Aug 28 12:48:46 2031 GMT |
| Ssl_server_not_before | Aug 30 12:48:46 2021 GMT |
| Ssl_session_cache_hits | 0 |
| Ssl_session_cache_misses | 0 |
| Ssl_session_cache_mode | SERVER |
| Ssl_session_cache_overflows | 0 |
| Ssl_session_cache_size | 128 |
| Ssl_session_cache_timeouts | 0 |
| Ssl_sessions_reused | 0 |
| Ssl_used_session_cache_entries | 0 |
| Ssl_verify_depth | 0 |
| Ssl_verify_mode | 0 |
| Ssl_version | |
+--------------------------------+--------------------------+
25 rows in set (0.002 sec)Appliquer une connexion sécurisée
Puisqu'il révèle que la connexion n'est toujours pas sécurisée, MySQL introduit la variable require_secure_transport qui demande que toutes les connexions à établir soient chiffrées et sécurisées. Toute tentative de connexion pour une connexion non sécurisée échoue. Par exemple, en l'activant sur le serveur :
mysql> set global require_secure_transport=1;
Query OK, 0 rows affected (0.00 sec)Toute tentative de connexion en tant que client à l'aide d'une connexion non chiffrée échouera :
$ mysql [email protected] -h 192.168.40.110 -udbadmin
ERROR 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON.Pour vous connecter avec succès et en toute sécurité, vous devez spécifier les variables ssl-ca, ssl-cert, ssl-key. Voir ci-dessous :
$ mysql [email protected] -h 192.168.40.110 -udbadmin --ssl-ca=/tmp/pem/ca.pem --ssl-cert=/tmp/pem/server-cert.pem --ssl-key=/tmp/pem/server-key.pem -e "show global status like 'ssl%'\G"
*************************** 1. row ***************************
Variable_name: Ssl_accept_renegotiates
Value: 0
*************************** 2. row ***************************
Variable_name: Ssl_accepts
Value: 16
*************************** 3. row ***************************
Variable_name: Ssl_callback_cache_hits
Value: 0
*************************** 4. row ***************************
Variable_name: Ssl_cipher
Value: TLS_AES_256_GCM_SHA384
*************************** 5. row ***************************
Variable_name: Ssl_cipher_list
Value: TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES256-SHA:CAMELLIA256-SHA:CAMELLIA128-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA
*************************** 6. row ***************************
Variable_name: Ssl_client_connects
Value: 0
*************************** 7. row ***************************
Variable_name: Ssl_connect_renegotiates
Value: 0
*************************** 8. row ***************************
Variable_name: Ssl_ctx_verify_depth
Value: 18446744073709551615
*************************** 9. row ***************************
Variable_name: Ssl_ctx_verify_mode
Value: 5
*************************** 10. row ***************************
Variable_name: Ssl_default_timeout
Value: 7200
*************************** 11. row ***************************
Variable_name: Ssl_finished_accepts
Value: 11
*************************** 12. row ***************************
Variable_name: Ssl_finished_connects
Value: 0
*************************** 13. row ***************************
Variable_name: Ssl_server_not_after
Value: Aug 28 12:48:46 2031 GMT
*************************** 14. row ***************************
Variable_name: Ssl_server_not_before
Value: Aug 30 12:48:46 2021 GMT
*************************** 15. row ***************************
Variable_name: Ssl_session_cache_hits
Value: 0
*************************** 16. row ***************************
Variable_name: Ssl_session_cache_misses
Value: 0
*************************** 17. row ***************************
Variable_name: Ssl_session_cache_mode
Value: SERVER
*************************** 18. row ***************************
Variable_name: Ssl_session_cache_overflows
Value: 0
*************************** 19. row ***************************
Variable_name: Ssl_session_cache_size
Value: 128
*************************** 20. row ***************************
Variable_name: Ssl_session_cache_timeouts
Value: 0
*************************** 21. row ***************************
Variable_name: Ssl_sessions_reused
Value: 0
*************************** 22. row ***************************
Variable_name: Ssl_used_session_cache_entries
Value: 0
*************************** 23. row ***************************
Variable_name: Ssl_verify_depth
Value: 18446744073709551615
*************************** 24. row ***************************
Variable_name: Ssl_verify_mode
Value: 5
*************************** 25. row ***************************
Variable_name: Ssl_version
Value: TLSv1.3Alternativement, si un utilisateur est créé avec REQUIRED SSL par exemple, cela devrait également vous connecter en utilisant SSL même si require_secure_transport est désactivé, ce qui est sa valeur par défaut. Notez que, si require_secure_transport est activé, sa capacité complète les exigences SSL par compte, qui sont prioritaires. Par conséquent, si un compte est défini avec REQUIRE SSL, l'activation de require_secure_transport ne permet pas d'utiliser le compte pour se connecter à l'aide d'un fichier socket Unix.
S'assurer que les déploiements de serveurs MySQL sont chiffrés et sûrs
Sans tracas, c'est ce que nous attendons toujours avec impatience afin qu'il n'y ait pas d'autres problèmes et préoccupations à craindre. ClusterControl déploie les bases de données MySQL à l'aide de connexions cryptées et génère pour vous les certificats SSL et RSA. Par exemple, une capture d'écran ci-dessous vous montrant l'activité de travail d'une commande Créer un cluster à partir de ClusterControl.
Il configure les fichiers SSL et RSA et les place dans /etc/ chemin mysql/certs/ comme ci-dessous :
mysql> show global variables like 'ssl%';
+---------------+--------------------------------+
| Variable_name | Value |
+---------------+--------------------------------+
| ssl_ca | /etc/mysql/certs/server_ca.crt |
| ssl_capath | |
| ssl_cert | /etc/mysql/certs/server.crt |
| ssl_cipher | |
| ssl_crl | |
| ssl_crlpath | |
| ssl_key | /etc/mysql/certs/server.key |
+---------------+--------------------------------+
7 rows in set (0.00 sec)Ensuite, ClusterControl regroupe également les fichiers SSL et RSA générés de manière centralisée sous le panneau de navigation Gestion des clés, comme indiqué ci-dessous :
Une fois déployé, tout ce que vous avez à faire est de créer des utilisateurs avec SSL REQUIS ou d'avoir require_secure_transport si vous souhaitez appliquer une couche chiffrée et sécurisée pour vos connexions au serveur MySQL.
