Discussion :

[DeveloprJr]

Bonjour à tous,

Je souhaite obtenir de l'aide pour trouver comment que je pourrais implémenter une encryption à une base de données MySQL qui en possède pas. Je souhaiterai encrypter tous les champs avec des données sensibles sans avoir à toucher le code des applications qui auront à accéder ces champs. Mon objectif est de rendre toutes les informations sensibles illisibles lorsqu'il y a un accès direct à la DB. Présentement, Il n'y a que les champs reliés aux mots de passe qui sont encryptés avec une encryption aes_encrypt et qui sont par la suite décryptés dans les applications qui les accèdent, avec une clé.

J'ai trouvé quelques posts qui abordent le sujet mais les solutions ne s'appliquent pas tout à fait à ma situation.

J'ai également trouvé ces liens (pas disponibles en français) qui expliquent comment implémenter une encryption mais les explications sont au delà de mes compétences actuelles:


dev. mysql.com/doc/refman/8.3/en/innodb-data-encryption.html
dev. mysql.com/blog-archive/controlling-table-encryption-in-mysql-8-0/
digitalconnectmag.com/mysql-encryption-the-easy-guide-to-protect-your-data-in-2022/

J'utilise présentement phpMyAdmin pour faire mes manipulations dans la DB. Étant débutant dans l'encryption de DB, j'apprécierai beaucoup si quelqu'un pourrait me suggérer quelques solutions simples qui nécessiteront aucun ou presque pas de changements aux applications qui accèderont ces champs encryptés.

Merci à l'avance pour vos suggestions.

[SQLpro]

Il ne faut pas vous faire d'illusion... Le chiffrement dans MySQL est trompeur, inefficace et même dangereux....

En effet, bien qu'il existe quelques possibilités de chiffrement 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 mise en œuvres 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...
À titre d'exemple, Microsoft SQL Server utilise un chiffrement de type SHA_512 (512 bits) 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ée avec le paramètre de salage ne donne 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 certains 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...



Autres 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 : un module externe sensible que des personnes malveillantes peuvent modifier facilement ou supprimer et qui impose d'utiliser le mot de passe en clair à un moment dans les applications, la limitation de la clé de chiffrement et le 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éhicule chiffrées jusqu'à l'application qui peut les déchiffrer pour les afficher. Par exemple la technologies "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, inaccessible à 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...

A +

[DeveloprJr]

Énorme merci pour cette réponse détaillée. J'ignorais complètement que MySQL n'était pas fait pour ce genre de stockage de données sensibles. Je vais définitivement devoir tout transférer vers une autre base de données.

Ceci étant dit, je vais quand même devoir trouver une solution intérim car je dois rendre la DB conforme à certains critères de sécurité que l'un de nos clients nous a fournit sur une liste, et "l'encryption" des données en fait partie. Par "encryption", la liste semble indiquer de rendre les données sensibles de la DB illisibles lorsque chargée avec une application comme phpMyAdmin ou autres interfaces de gestion de DB similaires. Une fois complétée, cela va nous permettre d'au moins passer les critères "sur papier" et nous faire gagner du temps pour effectuer le transfert vers un autre type de DB plus robuste et approprié pour le stockage de données sensibles.

Avez-vous quelques solutions simples à me suggérer et implémentables sans faire trop de changements au code des applications qui accèdent la DB?

Merci, votre expertise est très appréciée.

[SQLpro]

SQL Server est le moins cher et le plus conforme à la norme SQL...

Si c'est pour du Web, l'édition WEB en mode hébergé (SPLA) est peu couteuse. De l'ordre de 30 € par mois (hors matériel et OS : Windows ou linux)...

Mais il existe certaines limitations :

• max 4 CPU avec un max de 16 cœurs en tout (de quoi servir plus de 10 000 connexions) par exemple 4 x 4.
• 64 Go de Cache en RAM... de quoi avoir des bases de plus de 600 Go (SQL Server étant 3 fois moins gourmand en volume de données que MySQL) sans compter le journal de transactions...
• 16 Go de tables "in memory" en sus
• 16 Go d'index verticaux (columnstore) en sus

A +

[DeveloprJr]

Merci pour votre suggestion. Je pensais plus à une solution intérim avec MySQL. J'aimerais conserver tout ce qui est présentement en place avec MySQL et juste "encrypter" ou rendre illisible les données sensibles qui y sont insérées lorsqu'on navigue à travers la base de données avec un outil tel que PHPMyAdmin, DBForge ou autres outils similaires.

Présentement il n'y a que les mots de passe qui sont illisibles mais utiliser la même méthode pour encrypter tous les autres champs que je voudrais rendre illisible va être très laborieux sachant que je vais devoir aller également modifier les requêtes dans le code de l'application qui fait appel à ces champs. Existe t-il une simple requête qui permetterait d'encrypter (rendre illisible) tous les champs que je souhaite d'encrypter sans que j'ai à modifier le code de mon application. Quelque chose du style:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ENCRYPT * FROM nom_de_la_table.nom_de_la_colonne, nom_de_la_table.nom_de_la_colonne, nom_de_la_table.nom_de_la_colonne, nom_de_la_table.nom_de_la_colonne METHODE_ENCRYPTION(PARAMETRES1, PARAMETRES2, ETC...);

Pour l'instant, je souhaite seulement à être conforme (sur papier) à une des exigences demandées par un client, ce qui me donnera le temps de faire le transfert vers SQL (ou autre) entre temps.

Merci encore pour votre feedback.

[SQLpro]

Vous pouvez utiliser une vue qui déchiffre toutes les informations et ne passer que par cette vue.

A +

[DeveloprJr]

Je souhaite faire des modifications qu'au niveau de MySQL et ne pas créer de nouveau code faute de temps. N'existe t-il pas une méthode pour encrypter les données à la source?

Sur ce lien (digitalconnectmag.com/mysql-encryption-the-easy-guide-to-protect-your-data-in-2022/), une explication semble indiquer que si à l'exemple 3 (au 2/3 de la page)... En essayant les différentes requête directement avec PHPMyAdmin, je n'obtiens que des erreurs.

Quelques clarifications là dessus seraient grandement apprécié.

Merci.

[SQLpro]

Vous renommez la table et créez la vue avec l'ancien nom de la table.

A +

[DeveloprJr]

C'est peut-être le débutant en moi mais je ne suis pas sûr de comprendre votre suggestion... Je souhaite rendre illisible les données sensibles lorsqu'on accède la base de données avec un outil tel que PHPMyAdmin. Pouvez-vous me préciser comment que l'implémentation de votre suggestion va accomplir cet objectif?

Merci.