MariaDB
 sql >> Base de données >  >> RDS >> MariaDB

Explorer les différentes façons de chiffrer vos données MariaDB

Le chiffrement de votre base de données MariaDB, qu'elle soit en transit ou au repos, est l'une des choses les plus importantes qu'une organisation doit prendre en compte si vous appréciez vos données.

Les organisations qui traitent des transactions financières, des dossiers médicaux, des informations confidentielles ou même des données personnelles doivent exiger ce type de protection des données. Fondamentalement, le chiffrement de la base de données transformera vos données lisibles en un format illisible (ou du moins difficile à déchiffrer) par tout utilisateur non autorisé.

Le cryptage de vos données empêche l'utilisation abusive ou l'intention malveillante par des pirates ou du personnel non autorisé qui pourrait endommager votre entreprise. Les données non chiffrées sont susceptibles d'être attaquées par des pirates qui injectent des données malveillantes susceptibles d'endommager votre infrastructure ou de voler des informations. Quartz a récemment publié un article sur la plus grande violation qui s'est produite dans ce sens et il est alarmant que des données aient été volées sur des milliards de comptes au cours des deux dernières décennies.

Ressources associées Comment chiffrer vos sauvegardes MySQL et MariaDB Sécurité de la base de données - Chiffrement des sauvegardes en transit et au repos Mise à jour :Devenir un administrateur de base de données ClusterControl - Gestion des clés SSL et chiffrement des données MySQL en transit

Dans ce blog, nous discuterons de différentes manières de chiffrer vos données MariaDB, qu'elles soient au repos ou en transit. Nous vous fournirons une compréhension de base du chiffrement et de son utilisation afin que vous puissiez utiliser ces approches pour protéger vos données.

Chiffrement des données MariaDB :en transit

MariaDB n'utilise pas, par défaut, le cryptage lors de la transmission de données sur le réseau du serveur au client. Cependant, l'utilisation de la configuration par défaut pourrait inciter un pirate potentiel à espionner un canal non sécurisé/non crypté. Si vous travaillez dans un environnement isolé ou hautement sécurisé, cet état par défaut peut être acceptable. Ceci, cependant, n'est pas idéal lorsque votre client et votre réseau se trouvent sur des réseaux différents, car cela configure votre base de données pour une éventuelle attaque "man-in-the-middle".

Pour éviter ces attaques, MariaDB vous permet de chiffrer les données en transit entre le serveur et les clients à l'aide du protocole Transport Layer Security (TLS) (anciennement connu sous le nom de Secure Socket Layer ou SSL). Pour commencer, vous devez vous assurer que votre serveur MariaDB a été compilé avec le support TLS. Vous pouvez le vérifier en exécutant l'instruction SHOW GLOBAL VARIABLES comme indiqué ci-dessous :

MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'version_ssl_library';
+---------------------+---------------------------------+
| Variable_name       | Value                           |
+---------------------+---------------------------------+
| version_ssl_library | OpenSSL 1.0.1e-fips 11 Feb 2013 |
+---------------------+---------------------------------+
1 row in set (0.001 sec)

Vous pourriez être confus quant à la différence entre SSL et TSL. La documentation peut utiliser le terme SSL et les variables de configuration utilisent également ssl_* comme préfixe, cependant, MariaDB ne prend en charge que ses successeurs sécurisés et non plus les anciennes versions SSL. Vous devrez peut-être identifier et utiliser les versions correctes de MariaDB qui nécessitent la bonne prise en charge des versions TLS que vous devez utiliser. Par exemple, PCI DSS v3.2 recommande d'utiliser une version de protocole minimale de TLSv1.2 prise en charge par les anciennes versions de MariaDB. Cependant, avec TLS 1.3, nécessite OpenSSL 1.1.1, est plus rapide en raison d'une poignée de main plus efficace entre les deux systèmes communiquant et cela est pris en charge depuis MariaDB 10.2.16 et MariaDB 10.3.8.

Pour utiliser les chiffrements disponibles pour une version TLS spécifique, vous pouvez le définir à l'aide de --ssl-cipher dans mysqld commande ou chiffrement SSL variable dans le fichier de configuration. Notez que les chiffrements TLSv1.3 ne peuvent pas être exclus lors de l'utilisation d'OpenSSL, même en utilisant la variable système ssl_cipher.

Paramètres de configuration pour chiffrer les données en transit

Pour chiffrer vos données en transit, vous pouvez exécuter la séquence de commandes ci-dessous :

Générer un certificat CA

openssl genrsa 2048 > ca-key.pem
openssl req -new -x509 -nodes -days 365000 -subj "/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server"  -key ca-key.pem -out ca-cert.pem

Générer un certificat de serveur

openssl req -newkey rsa:2048 -days 365000 -nodes -keyout server-key.pem -out server-req.pem -subj "/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=DB Server" 
openssl  rsa -in server-key.pem -out server-key.pem
openssl x509 -req -in server-req.pem -days 365000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem

Générer un certificat client

openssl req -newkey rsa:2048 -days 365000 -nodes -keyout client-key.pem -out client-req.pem  -subj "/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=Client Server"
openssl rsa -in client-key.pem -out client-key.pem
openssl  x509 -req -in client-req.pem -days 365000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem

Prenez note que votre nom commun (CN) dans le -subj L'argument doit être unique par rapport à vos certificats CA, serveur et client que vous générez. Techniquement, CA et Server peuvent avoir le même CN, mais il est préférable d'en faire un identifiant unique pour ces trois. Sinon, vous recevrez une erreur telle que :

ERROR 2026 (HY000): SSL connection error: tlsv1 alert unknown ca

D'accord, les certificats et les clés sont en place. Vous devez spécifier le chemin à l'aide des variables ssl_* dans votre fichier de configuration MySQL (par exemple, /etc/my.cnf pour le système d'exploitation basé sur RHEL ou /etc/mysql/my.cnf pour le système d'exploitation Debian/Ubuntu). Voir l'exemple de configuration ci-dessous :

[msqld]
...
ssl_ca=/etc/ssl/galera/self-gen/ca-cert.pem
ssl_cert=/etc/ssl/galera/self-gen/server-cert.pem
ssl_key=/etc/ssl/galera/self-gen/server-key.pem

Bien sûr, vous devez spécifier le bon chemin où avez-vous placé votre certificat et vos clés.

Placez ensuite ces paramètres sous [client-mariadb] section de votre fichier de configuration comme tel ci-dessous :

[client-mariadb]
ssl_ca = /etc/ssl/galera/self-gen/ca-cert.pem
ssl_cert=/etc/ssl/galera/self-gen/client-cert.pem
ssl_key=/etc/ssl/galera/self-gen/client-key.pem

Comme mentionné précédemment, vous pouvez spécifier le type de chiffrement que votre configuration SSL/TLS peut utiliser. Cela peut être fait en spécifiant la configuration de configuration ci-dessous :

[mysqld]
…
ssl_ca=/etc/ssl/galera/self-gen/ca-cert.pem
ssl_cert=/etc/ssl/galera/self-gen/server-cert.pem
ssl_key=/etc/ssl/galera/self-gen/server-key.pem
ssl-cipher=AES256-GCM-SHA384

Ou vous pouvez utiliser la configuration suivante telle quelle ci-dessous :

ssl-cipher=TLSv1.2      ### This will use all Ciphers available in TLS v1.2
ssl-cipher=HIGH:!DSS:!RCA-SHA:!DES-CBC3-SHA:[email protected]       ### Will list strong ciphers available and exclude ciphers in prefix.

La dernière ligne indique l'équivalent de cette commande :

openssl ciphers -v 'HIGH:!DSS:!RCA-SHA:!DES-CBC3-SHA:[email protected]'

Cela exclura les chiffrements faibles et les chiffrements sous forme de préfixe tels que DHE-DSS-AES256-GCM-SHA384 chiffrer par exemple.

Génération de votre certificat à l'aide de ClusterControl

Alternativement, vous pouvez utiliser ClusterControl pour générer les certificats et les clés pour vous. Pour ce faire, vous pouvez procéder comme indiqué ci-dessous :

  1. Sélectionnez votre cluster MariaDB, puis accédez à Sécurité et sélectionnez Cryptage SSL. Dans mon exemple ci-dessous, il s'agit d'un cluster MariaDB Galera :
  2. Sélectionnez le cryptage SSL et activez-le. Vous pourrez créer un nouveau certificat ou en choisir un existant. Pour cet exemple, je choisirai l'option "Créer un certificat":
  3. La dernière étape consiste à configurer les jours d'expiration de votre certificat. Voir ci-dessous: Si vous cliquez sur "Redémarrer les nœuds", ClusterControl effectuera un redémarrage progressif. Notez que si vous utilisez MariaDB 10.4 (qui est actuellement sur sa version RC), vous pouvez utiliser SSL sans redémarrer votre serveur MariaDB. Utilisez simplement la commande SSL FLUSH qui est une nouvelle fonctionnalité ajoutée dans la version MariaDB 10.4.

Une autre façon de gérer vos certificats/clés TLS/SSL, vous pouvez également utiliser la gestion des clés sous ClusterControl. Consultez ce blog pour en savoir plus sur la façon de procéder.

Créez votre utilisateur TLS/SSL MariaDB

Au cas où vous pensiez avoir terminé, vous ne l'êtes pas. Vous devez vous assurer que vos utilisateurs sont tenus d'utiliser SSL lorsqu'ils se connectent au serveur. Cet utilisateur devra toujours interagir avec le serveur via un canal privé. Ceci est très important car vous devez vous assurer que tous vos clients interagiront avec votre serveur de manière très sécurisée et privée.

Pour ce faire, faites simplement l'exemple suivant :

MariaDB [(none)]> CREATE USER [email protected]'192.168.10.200' IDENTIFIED BY '[email protected]';
Query OK, 0 rows affected (0.005 sec)
MariaDB [(none)]> GRANT ALL ON *.* TO [email protected]'192.168.10.200' REQUIRE SSL;
Query OK, 0 rows affected (0.005 sec)

Assurez-vous que lors de la connexion à votre client/hôte d'application, copiez le certificat que vous avez généré en fonction des étapes précédentes.

Vérification de votre connexion

Tester votre connexion si elle est cryptée ou non est très important pour déterminer l'état. Pour ce faire, vous pouvez effectuer la commande suivante :

mysql -e "status"|grep -i 'cipher'
SSL:                    Cipher in use is DHE-RSA-AES256-GCM-SHA384

Alternativement, OpenSSL version 1.1.1 a ajouté la prise en charge de -starttls mysql . Il existe un binaire openssl compilé statiquement disponible que vous pouvez obtenir ici https://testssl.sh/openssl-1.0.2k-dev-chacha.pm.ipv6.Linux+FreeBSD.tar.gz (ou consultez cette présentation au format PDF) . Ensuite, vous pouvez faire la commande suivante ci-dessous :

echo | bin/openssl.Linux.x86_64.static s_client -starttls mysql -connect localhost:3306 -CAfile /etc/ssl/galera/self-gen/ca-cert.pem

L'exemple de résultat serait comme ci-dessous :

$ echo | bin/openssl.Linux.x86_64.static s_client -starttls mysql -connect localhost:3306 -CAfile /etc/ssl/galera/self-gen/ca-cert.pem 
CONNECTED(00000003)
depth=1 C = PH, ST = Davao Del Sur, L = Davao City, O = Maximus Aleksandre, CN = CA Server
verify return:1
depth=0 C = PH, ST = Davao Del Sur, L = Davao City, O = Maximus Aleksandre, CN = DB Server
verify return:1
---
Certificate chain
 0 s:/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=DB Server
   i:/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server
 1 s:/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server
   i:/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDTDCCAjQCAQEwDQYJKoZIhvcNAQELBQAwazELMAkGA1UEBhMCUEgxFjAUBgNV
BAgMDURhdmFvIERlbCBTdXIxEzARBgNVBAcMCkRhdmFvIENpdHkxGzAZBgNVBAoM
Ek1heGltdXMgQWxla3NhbmRyZTESMBAGA1UEAwwJQ0EgU2VydmVyMCAXDTE5MDYx
MDAyMTMwNFoYDzMwMTgxMDExMDIxMzA0WjBrMQswCQYDVQQGEwJQSDEWMBQGA1UE
CAwNRGF2YW8gRGVsIFN1cjETMBEGA1UEBwwKRGF2YW8gQ2l0eTEbMBkGA1UECgwS
TWF4aW11cyBBbGVrc2FuZHJlMRIwEAYDVQQDDAlEQiBTZXJ2ZXIwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDNwFuoqJg8YlrDinxDZN4+JjFUTGlDfhmy
9H/1C4fZToegvd3RzU9mz3/Fgyuoez4szHDgkn7o4rqmKAH6tMm9R44qtBNGlxka
fn12PPXudDvij4A9C3nVatBJJXTSvSD4/eySY33kAS1DpKsgsTgKAKOsyadcvXYU
IP5nfFc7pxX/8qZADVmyeik4M+oLxO6ryurt0wmUhOmlz5zQghh9kFZLA49l+p95
m5D53d/O+Qj4HSb2ssZD2ZaRc2k4dMCVpa87xUbdP/VVLeu0J4BE3OJiwC0N1Jfi
ZpP2DOKljsklaAYQF+tPnWi5pgReEd47/ql0fNEjeheF/MJiJM1NAgMBAAEwDQYJ
KoZIhvcNAQELBQADggEBAAz7yB+UdNYJ1O5zJI4Eb9lL+vNVKhRJ8IfNrwKVbpAT
eQk9Xpn9bidfcd2gseqDTyixZhWjsjO2LXix7jRhH1DrJvhGQ7+1w36ujtzscTgy
ydLH90CnE/oZHArbBhmyuqmu041w5rB3PpI9i9SveezDrbVcaL+qeGo8s4ATB2Yr
Y3T3OTqw6o/7cTJJ8S1aXBLTyUq5HAtOTM2GGZMSYwVqUsmBHA3d7M8i7yp20RVH
78j1H6+/hSSY4SDhwr04pSkzmm6HTIBCgOYrmEV2sQ/YeMHqVrSplLRY3SZHvqHo
gbSnasOQAE1oJnSNyxt9CRRAghM/EHEnsA2OlFa9iXQ=
-----END CERTIFICATE-----
subject=/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=DB Server
issuer=/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server
---
No client certificate CA names sent
Client Certificate Types: RSA fixed DH, DSS fixed DH, RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA512
Server Temp Key: DH, 2048 bits
---
SSL handshake has read 3036 bytes and written 756 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : DHE-RSA-AES256-GCM-SHA384
    Session-ID: 46E0F6FA42779DB210B4DF921A68E9E4CC39ADD87D28118DB0073726B98C0786
    Session-ID-ctx: 
    Master-Key: 2A2E6137929E733051BE060953049A0553F49C2F50A183EEC0C40F7EFB4E2749E611DF54A88417518A274EC904FB3CE6
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 4a dd f3 7f 1e b7 9e cb-77 58 b9 75 53 34 5c 61   J.......wX.uS4\a
    0010 - 3a 4d 0e aa e2 6b 27 8e-11 ff be 24 ad 66 88 49   :M...k'....$.f.I
    0020 - c1 ba 20 20 d8 9f d5 5c-23 9d 64 dc 97 f2 fa 77   ..  ...\#.d....w
    0030 - bf e6 26 1f 2c 98 ee 3b-71 66 0c 04 05 3e 54 c1   ..&.,..;qf...>T.
    0040 - 88 b6 f7 a9 fd b8 f9 84-cd b8 99 9f 6e 50 3b 13   ............nP;.
    0050 - 90 30 91 7d 48 ea 11 f7-3f b7 6b 65 2e ea 7e 61   .0.}H...?.ke..~a
    0060 - 70 cd 4e b8 43 54 3d a0-aa dc e5 44 a7 41 3a 5e   p.N.CT=....D.A:^
    0070 - 3e cb 45 57 33 2b a4 8f-75 d8 ce a5 9e 00 16 50   >.EW3+..u......P
    0080 - 24 aa 7a 54 f8 26 65 74-11 d7 f3 d6 66 3b 14 60   $.zT.&et....f;.`
    0090 - 33 98 4a ef e2 17 ba 33-4e 7f 2b ce 46 d7 e9 11   3.J....3N.+.F...

    Start Time: 1560133350
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
DONE
ClusterControlConsole unique pour l'ensemble de votre infrastructure de base de donnéesDécouvrez les autres nouveautés de ClusterControlInstallez ClusterControl GRATUITEMENT

Chiffrement des données MariaDB :au repos

Les données chiffrées qui sont stockées physiquement dans votre stockage matériel (c'est-à-dire au repos) offrent plus de stabilité et de protection contre une violation de données. Si un attaquant malveillant peut se connecter à votre base de données MariaDB, il peut lire les données en texte brut. Semblable à l'utilisation d'une commande de chaînes sous Linux, vous pourrez facilement récupérer les données de la base de données. De plus, cela ajoute plus de danger si l'attaquant a une compréhension avancée du format de fichier du tablespace.

Le chiffrement au repos est une protection supplémentaire, mais il ne remplace pas un bon pare-feu, des mots de passe forts, des autorisations utilisateur correctes et un chiffrement en transit entre le client et le serveur.

La prise en charge par MariaDB du chiffrement sur les tables et les espaces de table a été ajoutée dans la version 10.1.3. Vos tables étant cryptées, vos données sont presque impossibles à voler. Ce type de cryptage permet également à votre organisation de se conformer aux réglementations gouvernementales telles que le RGPD.,

Une fois que vous avez activé le chiffrement des données au repos dans MariaDB, les tables définies avec ENCRYPTED=YES ou avec innodb_encrypt_tables=ON verront vos données stockées chiffrées. Il est déchiffré uniquement lorsqu'il est accessible via la base de données de MariaDB, sinon, les données sont illisibles.

Par exemple, en lisant une donnée qui n'est pas cryptée, elle vous affichera comme telle :

$ strings admin_logs.ibd|head -10
=r7N
infimum
supremum
infimum
supremum/
failThe verification code you entered is incorrect.KK
elmo1234failThe password or username you entered is invalidKK
elmo1234failThe password or username you entered is invalidKK
elmoasfdfailThe verification code you entered is incorrect.KK
safasffailThe verification code you entered is incorrect.KK

mais avec des données chiffrées, votre tablespace ne sera pas lisible comme dans l'exemple ci-dessous :

# strings user_logs.ibd |head -10
E?*Pa
[+YQ
KNmbUtQ
T_lPAW
\GbQ.
] e2
#Rsd
ywY%o
kdUY
{]~GE

Il convient également de noter que le chiffrement Data-At-Rest de MariaDB ajoute une surcharge de taille de données d'environ 3 à 5 %. Le chiffrement MariaDB est également entièrement pris en charge lors de l'utilisation des moteurs de stockage XtraDB et InnoDB. Le chiffrement est également pris en charge pour le moteur de stockage Aria, mais uniquement pour les tables créées avec ROW_FORMAT=PAGE (valeur par défaut) et pour le journal binaire (journal de réplication). MariaDB permet même à l'utilisateur de choisir de manière flexible ce qu'il faut chiffrer. Dans XtraDB ou InnoDB, on peut choisir de chiffrer :

  • tout — tous les tablespaces (avec toutes les tables)
  • tableaux individuels
  • tout, à l'exception des tables individuelles

De plus, on peut choisir de chiffrer les fichiers journaux XtraDB/InnoDB (ce qui est recommandé).

MariaDB a ses limites. Galera Cluster gcache, par exemple, n'est pas chiffré mais il est prévu dans le cadre de la version MariaDB 10.4. Vous pouvez trouver une liste complète des limitations ici.

Comment installer et configurer MariaDB pour le chiffrement des données au repos

  1. Générez des clés de chiffrement aléatoires à l'aide de la commande openssl rand. 
    $ mkdir -p /etc/mysql/encryption
$ for i in {1..5}; do openssl rand -hex 32 >> /etc/mysql/encryption/keyfile;  done;
    Maintenant, ouvrez et modifiez le fichier /etc/mysql/encryption/keyfile et ajoutez l'ID de clé auquel il sera fait référence lors de la création de tables chiffrées car il s'agit de l'ID de clé de chiffrement. Voir ENCRYPTION_KEY_ID pour plus de détails. Par conséquent, le format suivant doit être le suivant :
    <encryption_key_id1>;<hex-encoded_encryption_key1>
<encryption_key_id2>;<hex-encoded_encryption_key2>
    In my example keyfile, this looks as the following:
    $ cat keyfile
1;687a90b4423c10417f2483726a5901007571c16331d2ee9534333fef4e323075
2;e7bf20f1cbde9632587c2996871cff74871890d19b49e273d13def123d781e17
3;9284c9c80da9a323b3ac2c82427942dfbf1718b57255cc0bc0e2c3d6f15ac3ac
4;abf80c3a8b10643ef53a43c759227304bcffa263700a94a996810b0f0459a580
5;bdbc5f67d34a4904c4adc9771420ac2ab2bd9c6af1ec532e960335e831f02933
  2. Créons ou générons un mot de passe aléatoire à l'aide de la commande similaire de l'étape 1 :
    $ openssl rand -hex 128 > /etc/mysql/encryption/keyfile.key
  3. Avant de passer à l'étape suivante, il est important de prendre note des détails suivants concernant le chiffrement du fichier de clé :
    • Le seul algorithme actuellement pris en charge par MariaDB pour chiffrer le fichier de clé est le mode Cipher Block Chaining (CBC) d'Advanced Encryption Standard (AES).
    • La taille de la clé de chiffrement peut être de 128 bits, 192 bits ou 256 bits.
    • La clé de chiffrement est créée à partir du hachage SHA-1 du mot de passe de chiffrement.
    • Le mot de passe de chiffrement a une longueur maximale de 256 caractères.
    Maintenant, pour chiffrer le fichier de clé à l'aide de la commande openssl enc, exécutez la commande suivante ci-dessous :
    $ openssl enc -aes-256-cbc -md sha1 -pass file:/etc/mysql/encryption/keyfile.key -in /etc/mysql/encryption/keyfile    -out /etc/mysql/encryption/keyfile.enc
  4. Ajoutez les variables suivantes dans votre fichier de configuration MySQL (c'est-à-dire /etc/my.cnf sur le système d'exploitation Linux basé sur RHEL ou /etc/mysql/my.cnf sur le système d'exploitation basé sur Linux Debian/Ubuntu) 
    [mysqld]
…
#################### DATABASE ENCRYPTION ##############################
plugin_load_add = file_key_management
file_key_management_filename = /etc/mysql/encryption/keyfile.enc
file_key_management_filekey = FILE:/etc/mysql/encryption/keyfile.key
file_key_management_encryption_algorithm = aes_cbc 
encrypt_binlog = 1

innodb_encrypt_tables = ON
innodb_encrypt_log = ON
innodb_encryption_threads = 4
innodb_encryption_rotate_key_age = 0 # Do not rotate key
  5. Redémarrez le serveur MariaDB maintenant 
    $ systemctl start mariadb

Vérifiez et testez le chiffrement

Pour vérifier et tester le cryptage, créez simplement un exemple de table. Par exemple, créez la table en exécutant les instructions SQL suivantes :

MariaDB [test]> CREATE TABLE a (i int) ENGINE=InnoDB ENCRYPTED=YES;
Query OK, 0 rows affected (0.018 sec)
MariaDB [test]> CREATE TABLE b (i int) ENGINE=InnoDB;
Query OK, 0 rows affected (0.003 sec)

Ensuite, ajoutons quelques données aux tables :

MariaDB [test]> insert into a values(1),(2);
Query OK, 2 rows affected (0.001 sec)
Records: 2  Duplicates: 0  Warnings: 0
MariaDB [test]> insert into b values(1),(2);
Query OK, 2 rows affected (0.001 sec)
Records: 2  Duplicates: 0  Warnings: 0

Pour vérifier et voir quelles sont les tables chiffrées, exécutez simplement la commande SELECT suivante requête ci-dessous :

MariaDB [test]> SELECT * FROM information_schema.innodb_tablespaces_encryption\G
*************************** 1. row ***************************
                       SPACE: 4
                        NAME: mysql/gtid_slave_pos
           ENCRYPTION_SCHEME: 1
          KEYSERVER_REQUESTS: 1
             MIN_KEY_VERSION: 1
         CURRENT_KEY_VERSION: 1
    KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
              CURRENT_KEY_ID: 1
        ROTATING_OR_FLUSHING: 0
*************************** 2. row ***************************
                       SPACE: 2
                        NAME: mysql/innodb_index_stats
           ENCRYPTION_SCHEME: 1
          KEYSERVER_REQUESTS: 1
             MIN_KEY_VERSION: 1
         CURRENT_KEY_VERSION: 1
    KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
              CURRENT_KEY_ID: 1
        ROTATING_OR_FLUSHING: 0
*************************** 3. row ***************************
                       SPACE: 1
                        NAME: mysql/innodb_table_stats
           ENCRYPTION_SCHEME: 1
          KEYSERVER_REQUESTS: 1
             MIN_KEY_VERSION: 1
         CURRENT_KEY_VERSION: 1
    KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
              CURRENT_KEY_ID: 1
        ROTATING_OR_FLUSHING: 0
*************************** 4. row ***************************
                       SPACE: 3
                        NAME: mysql/transaction_registry
           ENCRYPTION_SCHEME: 1
          KEYSERVER_REQUESTS: 0
             MIN_KEY_VERSION: 1
         CURRENT_KEY_VERSION: 1
    KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
              CURRENT_KEY_ID: 1
        ROTATING_OR_FLUSHING: 0
*************************** 5. row ***************************
                       SPACE: 5
                        NAME: test/a
           ENCRYPTION_SCHEME: 1
          KEYSERVER_REQUESTS: 1
             MIN_KEY_VERSION: 1
         CURRENT_KEY_VERSION: 1
    KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
              CURRENT_KEY_ID: 1
        ROTATING_OR_FLUSHING: 0
*************************** 6. row ***************************
                       SPACE: 6
                        NAME: test/b
           ENCRYPTION_SCHEME: 1
          KEYSERVER_REQUESTS: 1
             MIN_KEY_VERSION: 1
         CURRENT_KEY_VERSION: 1
    KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
              CURRENT_KEY_ID: 1
        ROTATING_OR_FLUSHING: 0
6 rows in set (0.000 sec)

La création de la table InnoDB n'a pas besoin de spécifier le mot-clé ENCRYPTED=YES. Il est créé automatiquement comme nous l'avons spécifié dans le fichier de configuration pour avoir innodb_encrypt_tables =ON.

Si vous souhaitez spécifier l'identifiant de chiffrement de la table à utiliser, vous pouvez également procéder comme suit :

MariaDB [test]> CREATE TABLE c (i int) ENGINE=InnoDB ENCRYPTION_KEY_ID = 4;
Query OK, 0 rows affected (0.003 sec)

L'ENCRYPTION_KEY_ID provient du fichier de clé de chiffrement que nous avons généré précédemment.

De plus, si vous voulez plus de tests via le shell, vous pouvez utiliser les chaînes commande que je vous ai montrée plus tôt.

Informations supplémentaires sur le chiffrement MariaDB

Si votre instance MariaDB ne doit contenir aucune table non chiffrée, configurez simplement la variable dans votre fichier de configuration my.cnf dans [mysqld] comme suit :

innodb_encrypt_tables = FORCE.

Pour le chiffrement binlog, ajoutez simplement ce qui suit

encrypt_binlog = 1

Le redo-log d'InnoDB n'est pas chiffré par défaut. Pour le chiffrer, ajoutez simplement la variable ci-dessous après la section [mysqld],

innodb-encrypt-log

Si vous avez besoin d'un chiffrement pour vos tables et fichiers temporaires sur disque, vous pouvez ajouter ce qui suit :

encrypt-tmp-disk-tables=1
encrypt-tmp-files=1