Le chiffrement des données dans MySQL/MariaDB est trompeur, inefficace et même dangereux, dans les versions communautaires libres et même dans certaines autres distributions payantes. Voici pourquoi...
En effet, bien qu'il existe quelques possibilités de chiffrement dans MySQL/MariaDB aucune n'est efficace ni pertinente...
Dans les grands SGBDR le chiffrement le plus employé est le "Transparent Data Encryption" aussi appelé TDE, qui consiste à chiffrer le stockage des bases au niveau du disque. Les données restent claires en mémoire et ce n'est que lorsqu'il faut lire les données sur les disques ou les écrire que le chiffrement déchiffrement s'effectue. Pour cela le SGBDR doit impérativement gérer directement son stockage sans passer par la couche système (ce que font IBM DB2; Oracle Database ou Microsoft SQL Server).
Or ce n'est pas le cas de MySQL/MariaDB qui délègue lectures et écritures disque à la couche OS....
Bien que MySQL propose le chiffrement "InnoDB Data-at-rest Encryption" cela ne concerne que les tables innodb...
Il y a bien un TDE dans l'édition Enterprise.... (payante...), mais le problème est que dans le TDE de l'édition Enterprise, les tables temporaires ne sont pas chiffrées, les sauvegardes (dump) non plus, et les performances sévèrement dégradées...
Quant à chiffrer certaines colonnes de certaines tables, là aussi les méthodes mises en œuvre dans MySQL sont pauvres, inefficaces et inutiles !
Le chiffrement des mots de passe est basé sur l'algorithme SHA-1 (160 bits) non salé...
Or la CNIL indique que pour les données de santé (un exemple parmi d'autres... idem dans le monde bancaire notamment) le hachage doit se faire avec un algorithme d'au moins 80 bits et salé ! Ce que ne permet pas MySQL...
C'est pourquoi il fait souvent l'objet de pénalités pour les clients qui utilisent des bases de données MySQL/MariaDB...
À titre d'exemple, Microsoft SQL Server utilise un chiffrement de type SHA_512 (512 bits, donc trois fois plus lourd que MySQL/MariaDB) avec salage interne.
NOTE : qu'est-ce que le salage du chiffrement ?
Cela consiste à introduire une information relativement "aléatoire", en complément de l'information que l'on veut chiffrer, afin que deux valeurs identiques une fois chiffrées avec le paramètre de salage ne donnent pas la même valeur de chiffrement afin de lutter contre l'attaque d'informations chiffrée par analyse fréquentielle. Par exemple le chiffrement de deux patronymes identiques "DUPONT" afférents à deux personnes physiques différentes devrait donner pour l'un une valeur binaire différente de l'autre. La figure ci-après donne un exemple de chiffrement dans Microsoft SQL Server ou l'on voit bien que le même patronyme est chiffré de deux manières différentes :
NOTE : qu'est-ce que l'analyse fréquentielle ?
C'est une technique de cassage du chiffre par analyse de la fréquence d'apparition des mêmes données chiffrées pour toute ou partie d'une valeur chiffrée dans une collection de valeurs dont on sait que certaines valeurs peuvent être répétitives et dont on connait la loi de distribution, même de manière approximative. Par exemple le nom DUPONT est le 22e nom de famille le plus fréquent en France...
Autre problématique, le chiffrement des colonnes des tables n'existe pas en standard dans MySQL. Il faut recourir à un plugin externe, qui limite le chiffrement à l'algorithme AES en128, 192 ou 256 bits.
Quatre inconvénients : (1) un module externe sensible que des personnes malveillantes peuvent modifier facilement ou supprimer et (2)qui impose d'utiliser le mot de passe en clair à un moment dans les applications, (3) la limitation de la clé de chiffrement et le (4) fait que les données chiffrées ne sont pas salées...
Cette dernière problématique est extrêmement grave, car le salage du chiffrement est indispensable dans les données des bases. En effet, les bases de données portant d’importantes collections de données, une attaque par analyse fréquentielle des données chiffrées est aisé sur des données dont on connait la distribution statistique, comme les patronymes (voir https://www.geneanet.org/genealogie/), les prénoms (https://www.insee.fr/fr/statistiques...mmaire=7635552), les données comptables (loi de Benford), les numéros de sécurité sociale…
De même, les applications devant chiffrer ou déchiffrer doivent à un moment avoir le mot de passe en clair.... Ce qui veut dire qu'il suffit d'avoir accès au code de l'application pour péter le chiffrement... C'est comme si vous fermiez votre voiture à clé en laissant les clés sur la porte !
Autrement dit le chiffrement dans MySQL ne sert à rien...
À titre d'exemple, Microsoft SQL Server utilise un chiffrement interne systématiquement salé, par clé symétrique, asymétrique, certificat, mot de passe, et avec les algorithmes : RC2, RC4, RC4_128, DES, TRIPLE_DES, TRIPLE_DES_3KEY, DESX, AES (128, 192, 256), RSA (512, 1024, 2048, 3072, 4096)...
De plus pour sécuriser le chiffrement, les clés sont protégées par une hiérarchie de clefs depuis la clé d’instance puis la clé de la base, qui protège les clés crées par SQL Server pour le chiffrement des données. Et pour qu'il ne soit pas nécessaire d'exposer la moindre clé dans les applications, le déchiffrement peut être automatisé sans jamais exposer le mot de passe (DECRYPTBYKEYAUTOASYMKEY, DECRYPTBYKEYAUTOCERT) ou encore par des vues de déchiffrement situées dans d’autres bases...
Enfin, il est possible de déléguer la gestion des clés de ,SQL Server par un boitier électronique sécurisé (« Hardware Security Module » technologie appelé EKM : Extensible Key Management) qui s'autodétruit en cas d'intrusion... Exemple Thales Luna
Enfin, le fin du fin est d'utiliser le chiffrement de bout en bout qui laisse les données chiffrées dans la base et les véhicules chiffrées jusqu'à l'application qui peut les déchiffrer pour les afficher. Par exemple la technologie "AlwaysEncrypted" de Microsoft SQL Server. De même le traitement des données chiffrées peut utiliser des zones de mémoire réservées, inaccessibles à d'autres processus, car la mémoire peut aussi être lue par des processus malveillants. On appelle cela des enclaves mémoire sécurisées et cela existe pour Microsoft SQL Server avec la technologie Secure Enclaves...
Tout cela n'existe pas dans MySQL, même dans la version Enterprise, par ce que MySQL/mariaDB n'est pas un SGBD d'entreprise, mais sert surtout à des CMS ou des blogs et n'a aucune vocation a traiter des données de santé ou des données financières... ou de quelconques données sensibles comme la paye...