L'Importance de l'Audit des Bases de Données
La fonction d'audit des bases de données est primordiale pour la sécurité des systèmes d'information et la conformité réglementaire. Elle consiste à enregistrer de manière exhaustive les actions des utilisateurs sur la base de données, permettant ainsi un suivi, une investigation et une analyse postérieurs. Cette traçabilité est essentielle pour identifier les anomalies, attribuer les responsabilités en cas d'incident et garantir l'intégrité des données. Pour les administrateurs de bases de données (DBA), disposer de logs d'audit clairs est un atout majeur pour la résolution de problèmes et la gestion des incidents.
Limitations des Mécanismes de Log Nativs de MySQL
Contrairement à d'autres systèmes de gestion de bases de données, la version communautaire de MySQL ne propose pas de fonctionnalité d'audit intégrée au sens strict. Bien que MySQL fournisse le journal binaire (binlog) et le journal général (general log), ces outils ne sont généralement pas considérés comme des solutions d'audit complètes en raison de leurs objectifs et de leurs caractéristiques spécifiques.
- Le Binlog (Journal Binaire) : Ce journal enregistre toutes les modifications de données et de structure (DDL et DML, à l'exception des requêtes de lecture comme
SELECTouSHOW) sous forme d'événements binaires. Il est principalement utilisé pour la réplication entre serveurs et la récupération de données. Bien qu'il contienne des informations sur les modifications, son format n'est pas optimisé pour l'analyse d'audit et il ignore les opérations de lecture, qui sont souvent cruciales pour l'audit. - Le General Log (Journal Général) : Ce journal capture toutes les requêtes SQL reçues par le serveur MySQL. Bien qu'il enregistre potentiellement toutes les actions, y compris les
SELECT, son activation est fortement déconseillée en production. Le volume de données généré est colossal, entraînant une dégradation significative des performances de la base de données et rendant l'analyse et le filtrage des informations d'audit extrêmement difficiles.
Face à ces limitations, la solution la plus courante pour implémenter l'audit sur une version communautaire de MySQL est d'utiliser un plugin d'audit tiers. Parmi les options disponibles, le plugin d'audit de MariaDB, le Percona Audit Log Plugin et le McAfee MySQL Audit Plugin sont les plus connus. Le plugin d'audit de MariaDB est souvent privilégié pour sa compatibilité et sa facilité d'intégration avec MySQL.
Mise en Œuvre du Plugin d'Audit MariaDB
Nous allons détailler les étapes pour installer et configurer le plugin d'audit MariaDB, nommé server_audit.so (ou server_audit.dll sous Windows), sur un serveur MySQL.
1. Acquisition du Plugin
La première étape consiste à obtenir le fichier du plugin server_audit.so. Ce fichier doit être extrait d'une installation de MariaDB dont la version est compatible avec votre version de MySQL. Il est crucial que le système d'exploitation de l'instance MariaDB source corresponde à celui de votre serveur MySQL.
Par exemple, pour un serveur MySQL 5.7 sous CentOS, vous devrez télécharger un package MariaDB pour CentOS, tel que MariaDB 10.2.38, qui est généralement compatible avec MySQL 5.7 et inclut une version récente du plugin (e.g., 1.4.13). Il est recommandé d'utiliser une version de plugin 1.4.4 ou supérieure pour bénéficier de fonctionnalités avancées comme l'exclusion des requêtes SELECT.
Après avoir téléchargé l'archive MariaDB (par exemple, mariadb-10.2.38-linux-x86_64.tar.gz depuis downloads.mariadb.com), décompressez-la. Le fichier server_audit.so se trouvera généralement dans le répertoire mariadb-10.2.38-linux-x86_64/lib/plugin/.
2. Préparation du Fichier Plugin
Une fois le fichier server_audit.so extrait, copiez-le dans le répertoire des plugins de votre installation MySQL et ajustez ses permissions.
# Vérifier le chemin du répertoire des plugins MySQL
mysql -u root -p -e "SHOW VARIABLES LIKE 'plugin_dir';"
+---------------+------------------------------+
| Variable_name | Value |
+---------------+------------------------------+
| plugin_dir | /usr/local/mysql/lib/plugin/ |
+---------------+------------------------------+
# Copier le fichier server_audit.so dans ce répertoire
# (Assurez-vous d'être dans le répertoire où se trouve votre server_audit.so)
cp server_audit.so /usr/local/mysql/lib/plugin/
# Se déplacer vers le répertoire du plugin pour ajuster les permissions
cd /usr/local/mysql/lib/plugin/
# Changer le propriétaire et les permissions du plugin pour MySQL
chown mysql:mysql server_audit.so
chmod 755 server_audit.so
# Vérifier les permissions
ls -lh server_audit.so
-rwxr-xr-x. 1 mysql mysql 191K May 4 2021 server_audit.so
3. Installation et Activation du Plugin
Maintenant, vous pouvez installer le plugin directement depuis le client MySQL.
-- Se connecter à MySQL et installer le plugin
mysql -u root -p
mysql> INSTALL PLUGIN server_audit SONAME 'server_audit.so';
Query OK, 0 rows affected (0.07 sec)
-- Vérifier que le plugin est actif
mysql> SHOW PLUGINS;
+----------------------------+--------+--------------------+-----------------+---------+
| Name | Status | Type | Library | License |
+----------------------------+--------+--------------------+-----------------+---------+
...
| SERVER_AUDIT | ACTIVE | AUDIT | server_audit.so | GPL |
+----------------------------+--------+--------------------+-----------------+---------+
4. Configuration des Paramètres d'Audit
Le plugin d'audit MariaDB offre plusieurs variables de configuration pour personnaliser son comportement. Vous pouvez les modifier de manière dynamique (temporaire) ou les rendre persistantes via le fichier de configuration my.cnf.
Afficher les paramètres actuels :
mysql> SHOW VARIABLES LIKE '%audit%';
+-------------------------------+-----------------------+
| Variable_name | Value |
+-------------------------------+-----------------------+
| server_audit_events | |
| server_audit_excl_users | |
| server_audit_file_path | server_audit.log |
| server_audit_file_rotate_now | OFF |
| server_audit_file_rotate_size | 1000000 |
| server_audit_file_rotations | 9 |
| server_audit_incl_users | |
| server_audit_loc_info | |
| server_audit_logging | OFF |
| server_audit_mode | 1 |
| server_audit_output_type | file |
| server_audit_query_log_limit | 1024 |
| server_audit_syslog_facility | LOG_USER |
| server_audit_syslog_ident | mysql-server_auditing |
| server_audit_syslog_info | |
| server_audit_syslog_priority | LOG_INFO |
+-------------------------------+-----------------------+
Configuration dynamique (pour des tests immédiats) :
-- Activer l'audit
mysql> SET GLOBAL server_audit_logging=ON;
-- Définir les types d'événements à auditer (connexions, tables, DDL, DCL, DML sans SELECT)
mysql> SET GLOBAL server_audit_events='connect,table,query_ddl,query_dcl,query_dml_no_select';
-- Spécifier le chemin du fichier journal d'audit
mysql> SET GLOBAL server_audit_file_path ='/data/mysql/logs/server_audit.log';
-- Définir la taille maximale du fichier journal avant rotation (ici, 100 Mo)
mysql> SET GLOBAL server_audit_file_rotate_size=104857600;
Rendre la configuration persistante (via my.cnf) :
Pour que la configuration persiste après un redémarrage du serveur MySQL, ajoutez les lignes suivantes sous la section [mysqld] de votre fichier de configuration my.cnf :
[mysqld]
# Force l'installation et l'activation permanente du plugin
server_audit=FORCE_PLUS_PERMANENT
server_audit_logging=ON
server_audit_file_path=/data/mysql/logs/server_audit.log
server_audit_events=connect,table,query_ddl,query_dcl,query_dml_no_select
server_audit_file_rotate_size=104857600
# Autres options possibles:
# server_audit_output_type=FILE (ou SYSLOG)
# server_audit_incl_users=user1,user2 (Inclure uniquement ces utilisateurs)
# server_audit_excl_users=root (Exclure ces utilisateurs de l'audit)
# server_audit_file_rotations=10 (Nombre de fichiers de rotation à conserver)
Voici une brève explication des principaux paramètres :
server_audit_logging: Active ou désactive l'enregistrement des événements d'audit (ON/OFF).server_audit_output_type: Définit la destination des logs (FILEpour un fichier local ouSYSLOGpour le système de log).server_audit_file_path: Spécifie le chemin complet du fichier journal d'audit.server_audit_events: Une liste séparée par des virgules des types d'événements à auditer (CONNECT,QUERY,TABLE,QUERY_DDL,QUERY_DCL,QUERY_DML,QUERY_DML_NO_SELECT, etc.).QUERY_DML_NO_SELECTest particulièrement utile pour exclure les lectures.server_audit_incl_users/server_audit_excl_users: Listes d'utilisateurs à inclure ou à exclure spécifiquement de l'audit.server_audit_file_rotate_size: La taille maximale d'un fichier journal d'audit avant qu'il ne soit archivé et qu'un nouveau soit créé.server_audit_file_rotations: Le nombre de fichiers journaux archivés à conserver.
5. Vérification et Analyse des Journaux d'Audit
Après l'installation et la configuration, le plugin commencera à enregistrer les activités spécifiées. Effectuons quelques opérations pour voir le contenu du journal.
-- Exemples d'opérations SQL
mysql> CREATE DATABASE ma_nouvelle_db;
mysql> USE ma_nouvelle_db;
mysql> CREATE TABLE utilisateurs (id INT PRIMARY KEY AUTO_INCREMENT, nom VARCHAR(50));
mysql> INSERT INTO utilisateurs (nom) VALUES ('Alice'), ('Bob');
mysql> UPDATE utilisateurs SET nom = 'Charlie' WHERE id = 1;
mysql> DELETE FROM utilisateurs WHERE id = 2;
mysql> DROP TABLE utilisateurs;
mysql> DROP DATABASE ma_nouvelle_db;
Voici des exemples d'entrées que vous pourriez trouver dans le fichier /data/mysql/logs/server_audit.log :
# Événements de connexion/déconnexion/échec de connexion
20230115 10:00:01,mon_serveur,root,127.0.0.1,100,0,CONNECT,,,0
20230115 10:00:05,mon_serveur,test_user,192.168.1.10,101,0,FAILED_CONNECT,,,1045
20230115 10:01:30,mon_serveur,root,127.0.0.1,100,0,DISCONNECT,ma_nouvelle_db,,0
# Événements de requête (DDL, DML, etc.)
20230115 10:00:10,mon_serveur,root,127.0.0.1,100,200,QUERY,,CREATE DATABASE ma_nouvelle_db,0
20230115 10:00:15,mon_serveur,root,127.0.0.1,100,201,QUERY,ma_nouvelle_db,CREATE TABLE utilisateurs (id INT PRIMARY KEY AUTO_INCREMENT, nom VARCHAR(50)),0
20230115 10:00:20,mon_serveur,root,127.0.0.1,100,202,QUERY,ma_nouvelle_db,INSERT INTO utilisateurs (nom) VALUES ('Alice'), ('Bob'),0
20230115 10:00:25,mon_serveur,root,127.0.0.1,100,203,QUERY,ma_nouvelle_db,UPDATE utilisateurs SET nom = 'Charlie' WHERE id = 1,0
20230115 10:00:30,mon_serveur,root,127.0.0.1,100,204,QUERY,ma_nouvelle_db,DELETE FROM utilisateurs WHERE id = 2,0
20230115 10:00:35,mon_serveur,root,127.0.0.1,100,205,QUERY,ma_nouvelle_db,DROP TABLE utilisateurs,0
20230115 10:00:40,mon_serveur,root,127.0.0.1,100,206,QUERY,,DROP DATABASE ma_nouvelle_db,0
Le format des entrées est généralement le suivant :
- Pour les connexions :
[timestamp],[serverhost],[username],[host],[connectionid],0,CONNECT|DISCONNECT|FAILED_CONNECT,[database],,[returncode] - Pour les requêtes :
[timestamp],[serverhost],[username],[host],[connectionid],[queryid],QUERY,[database],[query_text],[returncode]
Chaque entrée fournit des informations détaillées sur l'heure, l'hôte du serveur, l'utilisateur, l'adresse IP source, l'identifiant de connexion, le type d'événement, la base de données concernée (si applicable), la requête exécutée (pour les événements QUERY) et un code de retour indiquant le succès ou l'échec de l'opérationn.
Avantages et Inconvénients du Plugin MariaDB Audit
Le plugin server_audit est une solution robuste mais il présente des compromis à considérer.
Avantages :
- Richesse du contenu audité : Il capture un large éventail d'événements, y compris les connexions/déconnexions, les tentatives de connexion échouées, les opérations DDL, DML (avec ou sans
SELECT), les appels aux procédures stockées, les déclencheurs et les événements planifiés. - Flexibilité des politiques d'audit : Il permet une configuration fine des événements à auditer, comme l'exclusion des requêtes
SELECT(très utile pour réduire le volume de logs) ou l'inclusion/exclusion de certains utilisateurs spécifiques. - Facilité d'utilisation : Il est gratuit, relativement simple à installer et peut être activé ou désactivé dynamiquement sans redémarrer le serveur.
Inconvénients :
- Impact sur les performances : L'activation de l'audit entraîne inévitablement une surcharge des ressources du serveur, tant en termes de CPU (pour le traitement des logs) que d'E/S disque (pour l'écriture des logs).
- Consommation d'espace disque : Les fichiers journaux peuvent devenir très volumineux rapidement, nécessitant une gestion attentive de la rotation et de la rétention.
- Format de log fixe : Le format de sortie des journaux est prédéfini et offre peu de possibilités de personnalisation, ce qui peut compliquer l'intégration avec certains systèmes d'analyse de logs externes.