[MariaDB] Encryptage données sous Mariadb 10.2

Encryptage données sous Mariadb 10.2

Bonjour

Je voulais prendre votre avis sur l'encryptage de données sous Mariadb avec le plugin "file_key_management"

Après sa mise en place, je constate que les résultats des requêtes sont toujours affichés en claire même au niveau du serveur.
Je constate aussi que la restauration d'une base cryptée, peut se faire facilement si on modifie le dump en retirant l'option de cryptage dans la création des tables.

Je m'attendais à voir des données cryptées (non compréhensible) d'une table cryptée.

Cdt

Salut bo9al.

J'ai fait le test suivant sous Mariadb 10.2.9.

Pour ce faire, j'ai suivi ces didacticiel :
--> http://www.chriscalender.com/an-intr...n-dare-part-1/
--> http://www.chriscalender.com/an-intr...n-dare-part-2/

1) j'ai repris l'exemple du fichier "keys.txt" que je reproduis ci-après :

Code:

1
2
1;770A8A65DA156D24EE2A093277530142
18;F5502320F8429037B8DAEF761B189D12F5502320F8429037B8DAEF761B189D12

Par rapport à l'exemple, il ne faut pas mettre un espace après le point-virgule.

2) j'ai modifié le fichier my.ini en ajoutant ceci :

Code:

1
2
3
4
5
6
7
8
9
10
11
# ----------------#
#     Pluggin     #
# ----------------#
 
plugin-load-add=file_key_management.dll
file-key-management
file-key-management-filename = "F:/Wamp/bin/mariadb/mariadb10.2.9/keys.txt"
 
innodb-encrypt-tables = force
innodb-encrypt-log
innodb-encryption-threads=4

3) j'ai redémarré MariaDB. Voici le fichier mariadb_error.log :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
2018-04-24 15:31:19 2604 [Note] wampmariadbd (unknown): Arrêt normal du serveur
 
2018-04-24 15:31:19 2604 [Note] Event Scheduler: Purging the queue. 0 events
2018-04-24 15:31:19 1240 [Note] InnoDB: FTS optimize thread exiting.
2018-04-24 15:31:19 2604 [Note] InnoDB: Starting shutdown...
2018-04-24 15:31:20 2604 [Note] InnoDB: Shutdown completed; log sequence number 2670763
2018-04-24 15:31:20 2604 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2018-04-24 15:31:20 2604 [Note] wampmariadbd: Arrêt du serveur terminé
 
2018-04-24 15:31:21 2600 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2018-04-24 15:31:21 2600 [Note] InnoDB: Uses event mutexes
2018-04-24 15:31:21 2600 [Note] InnoDB: Compressed tables use zlib 1.2.3
2018-04-24 15:31:21 2600 [Note] InnoDB: Number of pools: 1
2018-04-24 15:31:21 2600 [Note] InnoDB: Using generic crc32 instructions
2018-04-24 15:31:21 2600 [Note] InnoDB: Initializing buffer pool, total size = 1G, instances = 2, chunk size = 128M
2018-04-24 15:31:21 2600 [Note] InnoDB: Completed initialization of buffer pool
2018-04-24 15:31:21 2600 [Note] InnoDB: Highest supported file format is Barracuda.
2018-04-24 15:31:22 2600 [Note] InnoDB: 128 out of 128 rollback segments are active.
2018-04-24 15:31:22 2600 [Note] InnoDB: Creating shared tablespace for temporary tables
2018-04-24 15:31:22 2600 [Note] InnoDB: Setting file 'f:\Wamp\bin\mariadb\mariadb10.2.9\data\ibdata\ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2018-04-24 15:31:22 2600 [Note] InnoDB: File 'f:\Wamp\bin\mariadb\mariadb10.2.9\data\ibdata\ibtmp1' size is now 12 MB.
2018-04-24 15:31:22 2600 [Note] InnoDB: 5.7.19 started; log sequence number 2670763
2018-04-24 15:31:22 2600 [Note] InnoDB: Creating #1 encryption thread id 144 total threads 4.
2018-04-24 15:31:22 2600 [Note] InnoDB: Creating #2 encryption thread id 144 total threads 4.
2018-04-24 15:31:22 2600 [Note] InnoDB: Creating #3 encryption thread id 144 total threads 4.
2018-04-24 15:31:22 2600 [Note] InnoDB: Creating #4 encryption thread id 144 total threads 4.
2018-04-24 15:31:22 2600 [Note] Plugin 'FEEDBACK' is disabled.
2018-04-24 15:31:22 2600 [Note] Server socket created on IP: '::'.
2018-04-24 15:31:22 2600 [Note] Reading of all Master_info entries succeded
2018-04-24 15:31:22 2600 [Note] Added new Master_info '' to hash table
2018-04-24 15:31:22 2600 [Note] wampmariadbd: ready for connections.
Version: '10.2.9-MariaDB'  socket: ''  port: 3307  mariadb.org binary distribution

Aucune erreur et l'on constate que le thread 4 est bien activé.

4) création d'une table InnoDB de nom test :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
 
--------------
SET AUTOCOMMIT = 0
--------------
 
--------------
START TRANSACTION
--------------
 
--------------
DROP DATABASE IF EXISTS `base`
--------------
 
--------------
CREATE DATABASE `base`
    DEFAULT CHARACTER SET `latin1`
    DEFAULT COLLATE       `latin1_general_ci`
--------------
 
--------------
DROP TABLE IF EXISTS `test`
--------------
 
--------------
CREATE TABLE IF NOT EXISTS `test`
( `id`      integer unsigned not null auto_increment primary key,
  `libelle` char(10)         not null
) ENGINE=InnoDB
  DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci`
  ROW_FORMAT=COMPRESSED
  ENCRYPTED=YES
  ENCRYPTION_KEY_ID = 18
--------------
 
--------------
INSERT INTO `test` (`libelle`) values
  ('un'),('deux'),('trois'),('quatre'),('cinq'),('six'),('sept'),('huit'),('neuf'),('dix'),('onze'),('douze'),('treize'),('quatorze'),('quinze'),('seize')
--------------
 
--------------
select * from test
--------------
 
+----+----------+
| id | libelle  |
+----+----------+
|  1 | un       |
|  2 | deux     |
|  3 | trois    |
|  4 | quatre   |
|  5 | cinq     |
|  6 | six      |
|  7 | sept     |
|  8 | huit     |
|  9 | neuf     |
| 10 | dix      |
| 11 | onze     |
| 12 | douze    |
| 13 | treize   |
| 14 | quatorze |
| 15 | quinze   |
| 16 | seize    |
+----+----------+
--------------
COMMIT
--------------
 
--------------
SET AUTOCOMMIT = 1
--------------
 
 
Appuyez sur une touche pour continuer...

Nous avons ajouté, lors de la création de la table, ceci :

Code:

1
2
ENCRYPTED=YES
ENCRYPTION_KEY_ID = 18

Nous utilisons le chiffrement.
Et nous utilisons la clef 18, celui du fichier keys.txt du paragraphe 1).

5) vérification !

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
--------------
SELECT *
  FROM  PLUGINS
 where  plugin_type = 'encryption'
--------------
 
+---------------------+----------------+---------------+-------------+---------------------+-------------------------+------------------------+------------------------+----------------------------------+----------------+-------------+-----------------+---------------------+
| PLUGIN_NAME         | PLUGIN_VERSION | PLUGIN_STATUS | PLUGIN_TYPE | PLUGIN_TYPE_VERSION | PLUGIN_LIBRARY          | PLUGIN_LIBRARY_VERSION | PLUGIN_AUTHOR          | PLUGIN_DESCRIPTION               | PLUGIN_LICENSE | LOAD_OPTION | PLUGIN_MATURITY | PLUGIN_AUTH_VERSION |
+---------------------+----------------+---------------+-------------+---------------------+-------------------------+------------------------+------------------------+----------------------------------+----------------+-------------+-----------------+---------------------+
| file_key_management | 1.0            | ACTIVE        | ENCRYPTION  | 3.0                 | file_key_management.dll | 1.13                   | Denis Endro eperi GmbH | File-based key management plugin | GPL            | ON          | Stable          | 1.0                 |
+---------------------+----------------+---------------+-------------+---------------------+-------------------------+------------------------+------------------------+----------------------------------+----------------+-------------+-----------------+---------------------+
--------------
SELECT  *
  FROM  INNODB_TABLESPACES_ENCRYPTION
 WHERE  NAME LIKE 'base/test'
--------------
 
+-------+-----------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
| SPACE | NAME      | ENCRYPTION_SCHEME | KEYSERVER_REQUESTS | MIN_KEY_VERSION | CURRENT_KEY_VERSION | KEY_ROTATION_PAGE_NUMBER | KEY_ROTATION_MAX_PAGE_NUMBER | CURRENT_KEY_ID | ROTATING_OR_FLUSHING |
+-------+-----------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
|    96 | base/test |                 1 |                  1 |               1 |                   1 |                     NULL |                         NULL |             18 |                    0 |
+-------+-----------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
 
Appuyez sur une touche pour continuer...

Le plugin "file_key_management" est activé.
Ma table test est bien chiffrée "ENCRYPTION_SCHEME = 1" et j'utilie une clef de chiffrement "CURRENT_KEY_ID = 18".

Citation:

Envoyé par bo9al

Après sa mise en place, je constate que les résultats des requêtes sont toujours affichés en claire même au niveau du serveur.

Si je lance le test du vidage de ma table, j'obtiens ceci :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
--------------
SELECT  *
  FROM  test
--------------
 
+----+----------+
| id | libelle  |
+----+----------+
|  1 | un       |
|  2 | deux     |
|  3 | trois    |
|  4 | quatre   |
|  5 | cinq     |
|  6 | six      |
|  7 | sept     |
|  8 | huit     |
|  9 | neuf     |
| 10 | dix      |
| 11 | onze     |
| 12 | douze    |
| 13 | treize   |
| 14 | quatorze |
| 15 | quinze   |
| 16 | seize    |
+----+----------+
 
Appuyez sur une touche pour continuer...

Donc, je ne sais pas répondre à votre question, pourquoi les libellés apparaissent lisibles.
Je suis allé sous PhpMyAdmin, et je fais la même constatation, les libellés sont lisibles.

Je vais poursuivre mes investigations !
Il faut, peut-être positionner un quelconque paramètre quelque part. :?

P.S.: J'ai vérifié avec chiffrement et sans chiffrement et j'ai constaté la différence dans le fichier système de ma table "test".
Il est vrai que ce n'est pas très clair ce qu'il nomme chiffrement, mais a priori, il faut passer par le client pour obtenir en clair les libellé, même s'ils sont chiffrés.

@+

Bonjour Artemus24
merci d'abord pour votre réactivité.
J'ai fait les mêmes tests, et j'ai obtenu les mêmes résultats.
Je pense que le cryptage/décryptage se fait de manière transparente au niveau de la bdd, et les données s'affichent tout le temps en claire.
Je pense que ce type de cryptage empêche la copie malhonnête des fichiers de données (le contenu du répertoire datadir), pour monter une base sur un autre serveur.

@+

Salut bo9al.

Citation:

Envoyé par bo9al

Je pense que le cryptage/décryptage se fait de manière transparente au niveau de la bdd, et les données s'affichent tout le temps en claire.

C'est vrai, mais d'après ce que j'ai pu comprendre, les données sont lisibles qu'au travers du client MariaDB.

Citation:

Envoyé par bo9al

Je pense que ce type de cryptage empêche la copie malhonnête des fichiers de données (le contenu du répertoire datadir), pour monter une base sur un autre serveur.

Vous soulevez le problème de la sécurité de deux choses :
--> du répertoire contenant la base de données. Dans mon exemple, ma base se nomme "base" et donc je parle de ceci : "F:Wamp/bin/mariadb/mariadb10.2.9/data/base".
--> du fichier contenant les clefs : "F:Wamp/bin/mariadb/mariadb10.2.9/Keys.txt".

Comment rendre inaccessible ce répertoire et fichier, en dehors du serveur MariaDB ?

C'est pourquoi, il faut accorder les droits d'accès à un compte système Windows (ou autre) qui aura toutes les permissions pour gérer le répertoire contenant.
Ce répertoire ne sera pas accessible, même en lecture, pour les autres comptes windows (ou autre).

De même, il faut, pour le compte root, le différencier du compte système windows et ne pas lui donner tous les droits.

Je pense que c'est un plus, de chiffrer les données dans toutes les tables du serveur MariaDB.
Mais le problème reste la sécurité au niveau de l'ordinateur qui ne doit pas être négligé.

Cordialement.
Artemus24.
@+