Sécurité et gestion des utilisateurs

Introduction

La sécurité des données du système informatique de l’entreprise n’est pas seulement l’affaire du RSSI (Responsable de la sécurité des systèmes d’information). Les techniques et les bonnes pratiques nécessaires pour se protéger doivent être connues et appliquées, par tout un chacun. Les éléments de la chaîne applicative étant interdépendants, la robustesse de cette chaîne va dépendre de la solidité de son maillon le plus faible. Un test non effectué par l’application, un compte utilisateur qui a trop de droits sur la base de données, une mise à jour de sécurité non effectuée ou tout simplement une maladresse sur le serveur de production peuvent être à l’origine du vol ou de l’altération des numéros de cartes bancaires de vos clients par exemple. Les conséquences peuvent alors être désastreuses tant financièrement qu’en terme d’image pour la société. Certes la sécurité absolue n’existe pas, mais nous allons dans ce chapitre essayer de vous donner toutes les pratiques nécessaires pour minimiser les risques.

Sécurisation du serveur MariaDB

Les questions liées à la sécurité doivent être posées dès l’installation du serveur de base de données. MariaDB dérive étroitement de MySQL, or dans la philosophie de MySQL l’utilisateur doit pouvoir télécharger, installer et utiliser le SGBDR (Système de gestion de bases de données relationnelles) sans aucune difficulté. Cette simplicité est l’un des points forts de MySQL, car d’une part, cela a permis de démocratiser l’utilisation d’une base de données en rendant accessible cet univers (beaucoup de développeurs ont connu les bases de données grâce à MySQL) et d’autre part, cela donne la possibilité de tester très simplement son application. L’inconvénient majeur est que son installation par défaut est très permissive, notamment en matière de sécurité...

1. Sécurisation de l’installation

Le but de cette section n’est pas de revenir sur l’installation du serveur qui est détaillée au chapitre Installation du serveur, mais simplement de rappeler quelques points cruciaux concernant la sécurité. Vous devrez certainement les adapter en fonction de votre type d’installation et de votre système d’exploitation.

a. Contrôler les droits

Vous devez créer un groupe et un utilisateur dédié pour lancer l’instance mysqld :


$ groupadd mysql 
$ useradd -g mysql mysql

Le répertoire de données contient les informations sensibles, il doit donc être préservé d’actes de malveillance ou de la visualisation par des personnes non autorisées :


$ cd /usr/local/mariadb/ 
$ chown -R root . 
$ chown -R mysql data 
$ chgrp -R mysql .

mysqld ne doit en aucun cas être exécuté avec l’administrateur système root sous UNIX (ou administrateur sous MS Windows). Un utilisateur avec par exemple le droit FILE pourrait créer des fichiers en tant que root.

b. Mettre un mot de passe au compte utilisateur root

C’est le super-utilisateur de MariaDB (à ne pas confondre avec l’administrateur système root sous UNIX) ; il a donc tous les droits sur le serveur MariaDB ; il doit...

Chiffrement des données

Pour faire face aux besoins de chiffrement d’informations sensibles (financières, médicales...) ou pour tenter de se prémunir contre le vol de données, contre des administrateurs peu scrupuleux, il peut être nécessaire de crypter ses données. Avant la version 10.1, MariaDB ne possédait pas de modules de chiffrement capables par exemple de crypter le contenu d’une colonne ou d’une table. Il est cependant possible de crypter/décrypter des données avec les fonctions AES_ENCRYPT()/AES_DECRYPT(), DES_ENCRYPT()/DES_DECRYPT() et ENCODE()/DECODE() (pour plus de détails, consultez la page suivante de la documentation MySQL : https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html).

Les données sont alors cryptées sur le disque. Par contre, elles sont en clair, y compris la clé de cryptage dans le code SQL, ainsi que sur le réseau.


mysql> INSERT INTO t_crypt VALUES (1, AES_ENCRYPT('Phrase  
cryptée','crypt_key'));  
Query OK, 1 row affected (0,00 sec)  
  
mysql> SELECT i, b FROM t_crypt;  
+------+------------------+  
| i    | data_crypt       |  
+------+------------------+  
| 1    | ?z#�uػb�7�G[g,<  |  
+------+------------------+  ...

Les options pour renforcer la sécurité

1. skip-networking

Dans le cas d’architectures où le client est sur la même machine que le serveur, il peut être intéressant d’interdire les connexions distantes. Non seulement vous vous affranchissez de la latence et d’éventuels problèmes liés au réseau, mais c’est également un moyen de limiter les risques d’attaques distantes. L’option skip-networking permet au serveur MariaDB de ne plus écouter les connexions TCP/IP. Les connexions au serveur MariaDB ne peuvent dès lors se faire qu’en local, avec les sockets sous UNIX. Sous un environnement MS Windows, le principe est le même, mais avec les protocoles named pipes ou shared memory.

Dans le fichier de configuration my.cnf (ou my.ini), skip-networking est activé :


[mysqld]  
skip-networking

Il est désormais impossible de se connecter au serveur MariaDB en utilisant le protocole TCP/IP :


$ mysql --host=localhost --protocol=tcp  
ERROR 2003 (HY000): Can't connect to MySQL server on 'localhost' (111)

Il ne reste plus que le protocole UNIX socket (named pipe ou shared memory sous Windows) :


$ mysql --host=localhost --protocol=socket  
Welcome to the MySQL monitor. Commands end with ; or \g.  
Your MySQL connection id is 4  
Server version: 5.1.35-log MySQL Community Server (GPL)  
  
Type 'help;' or '\h' for help. Type '\c' to clear the current input 
statement.  
  
Mysql>

2. bind-address

L’option bind-address permet d’attacher (bind) une adresse IP à votre serveur MariaDB, plus précisément à son ou à ses interfaces réseau. En d’autres termes, les connexions clientes ne pourront passer que par cette adresse IP pour atteindre le serveur...

Gestion des utilisateurs et des mots de passe

La gestion des utilisateurs de MariaDB se fait entièrement grâce à des tables dédiées qui appartiennent au schéma système mysql : user, db, tables_priv, columns_priv, procs_priv.

La table user contient la liste des comptes utilisateur. Ils sont décrits avec, entre autres, les colonnes host (le nom d’hôte) et user (le nom). Ces deux colonnes représentent la clé primaire de la table. On y trouve également la colonne password (le mot de passe du compte) qui est stockée sous une forme hachée (grâce à la fonction de hachage password()), ainsi que les droits globaux de l’utilisateur, comme le droit de faire des insertions (INSERT), des lectures (SELECT)…

La table db contient les droits spécifiques à une base de données (ou schémas) de chaque utilisateur.

La table tables_priv contient les droits spécifiques à une table ou à une vue.

La table columns_priv contient les droits spécifiques à une colonne.

La table procs_priv contient les droits pour les routines stockées, c’est-à-dire les procédures et les fonctions stockées.

1. Connexion aux comptes utilisateur

Au lancement du serveur, les tables système sont chargées en mémoire. La table user voit alors ses données triées en fonction de la colonne host, du plus spécifique (localhost, adresse IP) jusqu’au moins spécifique (%). Pour deux valeurs de host identiques, un tri supplémentaire est effectué sur la colonne user, toujours du plus spécifique (un nom de compte utilisateur) au moins spécifique, c’est-à-dire le compte utilisateur anonyme (’’). Lorsque le client se connecte, le compte utilisateur qui est choisi est le premier qui correspond à l’hôte (host) de la table user triée, puis à l’utilisateur (user) avec le bon mot de passe (password).

Le serveur possède deux utilisateurs, ’daz’@’%’ et ’daz’@’localhost’ :


mysql_root> SELECT user, host FROM mysql.user WHERE user ='daz'; 
+------+-----------+ 
| user | host      | 
+------+-----------+ 
| daz  | %         | ...

Sécurisation des vues et des routines stockées

Comme nous l’avons vu à la section Attribution des droits, l’accès aux objets de la base de données est sécurisé au niveau des comptes utilisateur, avec un système qui vous y autorise ou non. Cependant, même en ayant le droit d’accéder à l’objet (vues, procédures et fonctions stockées), il n’est pas certain que vous ayez le droit d’accéder aux données auxquelles il se réfère. Pour exécuter une vue (ou une routine), il faut que l’utilisateur ait le droit de manipuler tous les objets auxquels accède la vue (ou la routine) ou bien que la vue (ou la routine) soit exécutée à travers un utilisateur qui possède les droits adéquats (un peu comme si vous utilisiez la commande Linux su).

Pour une vue, c’est la clause SQL SECURITY qui permet de paramétrer ce comportement avec pour valeurs :

INVOKER : la vue est exécutée avec les droits de l’utilisateur.
DEFINER : la vue est exécutée avec les droits de son créateur.


mysql_root> CREATE SQL SECURITY INVOKER VIEW City_fra1 AS SELECT name 
FROM world.City WHERE countrycode='FRA'; 
 
mysql_root> CREATE SQL SECURITY DEFINER VIEW City_fra2 AS SELECT name 
FROM world.City WHERE countrycode='FRA'; ...