La protection des données est l'un des aspects les plus importants de l'administration d'une base de données. Selon la structure organisationnelle, que vous soyez développeur, administrateur système ou administrateur de base de données, si vous gérez la base de données de production, vous devez surveiller l'accès et l'utilisation non autorisés des données. L'objectif de la surveillance de la sécurité est double. Premièrement, pour identifier les activités non autorisées sur la base de données. Et deuxièmement, pour vérifier si les bases de données et leurs configurations à l'échelle de l'entreprise sont conformes aux politiques et normes de sécurité.
Dans cet article, nous diviserons la surveillance de la sécurité en deux catégories. L'un sera lié à l'audit des activités des bases de données MySQL et MariaDB. La deuxième catégorie concernera la surveillance de vos instances pour détecter d'éventuelles failles de sécurité.
Surveillance basée sur des règles de requête et de connexion
L'audit continu est une tâche impérative pour surveiller votre environnement de base de données. En auditant votre base de données, vous pouvez obtenir la responsabilité des actions entreprises ou du contenu consulté. De plus, l'audit peut inclure certains composants système critiques, tels que ceux associés aux données financières pour prendre en charge un ensemble précis de réglementations telles que SOX ou le règlement RGPD de l'UE. Habituellement, cela est réalisé en enregistrant des informations sur les opérations de base de données sur la base de données dans un fichier journal externe.
Par défaut, l'audit dans MySQL ou MariaDB est désactivé. Vous et y parvenez en installant des plugins supplémentaires ou en capturant toutes les requêtes avec le paramètre query_log. Le fichier journal des requêtes générales est un enregistrement général des performances de MySQL. Le serveur enregistre certaines informations dans ce journal lorsque les clients se connectent ou se déconnectent, et il consigne chaque instruction SQL reçue des clients. En raison de problèmes de performances et du manque d'options de configuration, general_log n'est pas une bonne solution à des fins d'audit de sécurité.
Si vous utilisez MySQL Enterprise, vous pouvez utiliser le plugin MySQL Enterprise Audit qui est une extension de la version propriétaire de MySQL. Le plug-in MySQL Enterprise Audit Plugin est uniquement disponible avec MySQL Enterprise, qui est une offre commerciale d'Oracle. Percona et MariaDB ont créé leurs propres versions open source du plugin d'audit. Enfin, le plug-in McAfee pour MySQL peut également être utilisé avec différentes versions de MySQL. Dans cet article, nous nous concentrerons sur les plugins open source, bien que la version Enterprise d'Oracle semble être la plus robuste et la plus stable.
Caractéristiques des plugins d'audit open source MySQL
Bien que les plugins d'audit open source fassent le même travail que le plugin Enterprise d'Oracle - ils produisent une sortie avec une requête de base de données et des connexions - il existe quelques différences architecturales majeures.
Plugin d'audit MariaDB - Le plugin d'audit MariaDB fonctionne avec MariaDB, MySQL (à partir des versions 5.5.34 et 10.0.7) et Percona Server. MariaDB a commencé à inclure le plugin d'audit par défaut à partir des versions 10.0.10 et 5.5.37, et il peut être installé dans n'importe quelle version à partir de MariaDB 5.5.20. C'est le seul plugin qui prend en charge Oracle MySQL, Percona Server et MariaDB. Il est disponible sur les plateformes Windows et Linux. Les versions à partir de 1.2 sont les plus stables, et il peut être risqué d'utiliser des versions inférieures à celle-ci dans votre environnement de production.
McAfee MySQL Audit Plugin – Ce plugin n'utilise pas l'API d'audit MySQL. Il a été récemment mis à jour pour prendre en charge MySQL 5.7. Certains tests montrent que les plugins basés sur l'API peuvent offrir de meilleures performances, mais vous devez le vérifier avec votre environnement.
Plugin de journal d'audit Percona - Percona fournit une solution d'audit open source qui s'installe avec Percona Server 5.5.37+ et 5.6.17+ dans le cadre du processus d'installation. Comparé à d'autres plugins open source, ce plugin a plus de fonctionnalités de sortie car il produit XML, JSON et vers syslog.
Comme il a des crochets internes au serveur pour être compatible avec le plugin d'Oracle, il n'est pas disponible en tant que plugin autonome pour les autres versions de MySQL.
Installation du plug-in basée sur l'extension d'audit MariaDB
L'installation des plugins MySQL open source est assez similaire pour les versions MariaDB, Percona et McAfee.
Percona et MariaDB ajoutent leurs plugins dans le cadre des binaires du serveur par défaut, il n'est donc pas nécessaire de télécharger les plugins séparément. La version Percona ne prend officiellement en charge que son propre fork de MySQL, il n'y a donc pas de téléchargement direct depuis le site Web du fournisseur (si vous souhaitez utiliser ce plugin avec MySQL, vous devrez obtenir le plugin à partir d'un package de serveur Percona). Si vous souhaitez utiliser le plugin MariaDB avec d'autres forks de MySQL, vous pouvez le trouver sur https://downloads.mariadb.com/Audit-Plugin/MariaDB-Audit-Plugin/. Le plugin McAfee est disponible sur https://github.com/mcafee/mysql-audit/wiki/Installation.
Avant de commencer l'installation du plugin, vous pouvez vérifier si le plugin est présent dans le système. L'emplacement du plug-in dynamique (ne nécessitant pas de redémarrage de l'instance) peut être vérifié avec :
SHOW GLOBAL VARIABLES LIKE 'plugin_dir';
+---------------+--------------------------+
| Variable_name | Value |
+---------------+--------------------------+
| plugin_dir | /usr/lib64/mysql/plugin/ |
+---------------+--------------------------+Vérifiez le répertoire renvoyé au niveau du système de fichiers pour vous assurer que vous disposez d'une copie de la bibliothèque du plug-in. Si vous n'avez pas server_audit.so ou server_audit.dll à l'intérieur de /usr/lib64/mysql/plugin/, il est plus probable que votre version de MariaDB ne soit pas prise en charge et devrait la mettre à niveau vers la dernière version..
La syntaxe pour installer le plugin MariaDB est :
INSTALL SONAME 'server_audit';Pour vérifier les plugins installés, vous devez exécuter :
SHOW PLUGINS;
MariaDB [(none)]> show plugins;
+-------------------------------+----------+--------------------+--------------------+---------+
| Name | Status | Type | Library | License |
+-------------------------------+----------+--------------------+--------------------+---------+
| binlog | ACTIVE | STORAGE ENGINE | NULL | GPL |
| mysql_native_password | ACTIVE | AUTHENTICATION | NULL | GPL |
| mysql_old_password | ACTIVE | AUTHENTICATION | NULL | GPL |
| wsrep | ACTIVE | STORAGE ENGINE | NULL | GPL |
| MRG_MyISAM | ACTIVE | STORAGE ENGINE | NULL | GPL |
| MEMORY | ACTIVE | STORAGE ENGINE | NULL | GPL |
| CSV | ACTIVE | STORAGE ENGINE | NULL | GPL |
| MyISAM | ACTIVE | STORAGE ENGINE | NULL | GPL |
| CLIENT_STATISTICS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INDEX_STATISTICS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| TABLE_STATISTICS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| USER_STATISTICS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| PERFORMANCE_SCHEMA | ACTIVE | STORAGE ENGINE | NULL | GPL |
| InnoDB | ACTIVE | STORAGE ENGINE | NULL | GPL |
| INNODB_TRX | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_LOCKS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_LOCK_WAITS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_CMP | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
...
| INNODB_MUTEXES | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_SYS_SEMAPHORE_WAITS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_TABLESPACES_ENCRYPTION | ACTIVE | INFORMATION SCHEMA | NULL | BSD |
| INNODB_TABLESPACES_SCRUBBING | ACTIVE | INFORMATION SCHEMA | NULL | BSD |
| Aria | ACTIVE | STORAGE ENGINE | NULL | GPL |
| SEQUENCE | ACTIVE | STORAGE ENGINE | NULL | GPL |
| user_variables | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| FEEDBACK | DISABLED | INFORMATION SCHEMA | NULL | GPL |
| partition | ACTIVE | STORAGE ENGINE | NULL | GPL |
| rpl_semi_sync_master | ACTIVE | REPLICATION | semisync_master.so | GPL |
| rpl_semi_sync_slave | ACTIVE | REPLICATION | semisync_slave.so | GPL |
| SERVER_AUDIT | ACTIVE | AUDIT | server_audit.so | GPL |
+-------------------------------+----------+--------------------+--------------------+---------+Si vous avez besoin d'informations supplémentaires, consultez la table PLUGINS dans la base de données information_schema qui contient des informations plus détaillées.
Une autre façon d'installer le plugin consiste à activer le plugin dans my.cnf et à redémarrer l'instance. Un exemple de configuration de plugin d'audit de base de MariaDB pourrait être :
server_audit_events=CONNECT
server_audit_file_path=/var/log/mysql/audit.log
server_audit_file_rotate_size=1073741824
server_audit_file_rotations=8
server_audit_logging=ON
server_audit_incl_users=
server_audit_excl_users=
server_audit_output_type=FILE
server_audit_query_log_limit=1024Le paramètre ci-dessus doit être placé dans my.cnf. Le plugin d'audit créera le fichier /var/log/mysql/audit.log qui tournera sur une taille de 1 Go et il y aura huit rotations jusqu'à ce que le fichier soit écrasé. Le fichier ne contiendra que des informations sur les connexions.
Actuellement, il existe seize paramètres que vous pouvez utiliser pour ajuster le plug-in d'audit MariaDB.
server_audit_events
server_audit_excl_users
server_audit_file_path
server_audit_file_rotate_now
server_audit_file_rotate_size
server_audit_file_rotations
server_audit_incl_users
server_audit_loc_info
server_audit_logging
server_audit_mode
server_audit_output_type
Server_audit_query_log_limit
server_audit_syslog_facility
server_audit_syslog_ident
server_audit_syslog_info
server_audit_syslog_priorityParmi eux, vous pouvez trouver des options pour inclure ou exclure des utilisateurs, définir différents événements de journalisation (CONNECT ou QUERY) et basculer entre fichier et syslog.
Pour vous assurer que le plugin sera activé au démarrage du serveur, vous devez définir
plugin_load=server_audit=server_audit.so dans vos paramètres my.cnf. Une telle configuration peut en outre être protégée par server_audit=FORCE_PLUS_PERMANENT qui désactivera l'option de désinstallation du plugin.
UNINSTALL PLUGIN server_audit;
ERROR 1702 (HY000):
Plugin 'server_audit' is force_plus_permanent and can not be unloadedVoici quelques exemples d'entrées produites par le plug-in d'audit MariaDB :
20180817 20:00:01,slave,cmon,cmon,31,0,DISCONNECT,information_schema,,0
20180817 20:47:01,slave,cmon,cmon,17,0,DISCONNECT,information_schema,,0
20180817 20:47:02,slave,cmon,cmon,19,0,DISCONNECT,information_schema,,0
20180817 20:47:02,slave,cmon,cmon,18,0,DISCONNECT,information_schema,,0
20180819 17:19:19,slave,cmon,cmon,12,0,CONNECT,information_schema,,0
20180819 17:19:19,slave,root,localhost,13,0,FAILED_CONNECT,,,1045
20180819 17:19:19,slave,root,localhost,13,0,DISCONNECT,,,0
20180819 17:19:20,slave,cmon,cmon,14,0,CONNECT,mysql,,0
20180819 17:19:20,slave,cmon,cmon,14,0,DISCONNECT,mysql,,0
20180819 17:19:21,slave,cmon,cmon,15,0,CONNECT,information_schema,,0
20180819 17:19:21,slave,cmon,cmon,16,0,CONNECT,information_schema,,0
20180819 19:00:01,slave,cmon,cmon,17,0,CONNECT,information_schema,,0
20180819 19:00:01,slave,cmon,cmon,17,0,DISCONNECT,information_schema,,0Rapport sur les modifications de schéma
Si vous avez besoin de suivre uniquement les modifications DDL, vous pouvez utiliser le rapport opérationnel de ClusterControl sur les modifications de schéma. Le rapport de détection de modification de schéma affiche toutes les modifications DDL apportées à votre base de données. Cette fonctionnalité nécessite un paramètre supplémentaire dans le fichier de configuration de ClusterControl. Si ce n'est pas défini, vous verrez les informations suivantes :schema_change_detection_address n'est pas défini dans /etc/cmon.d/cmon_1.cnf. Une fois que cela est en place, un exemple de sortie peut être comme ci-dessous :
Il peut être configuré avec un calendrier et les rapports peuvent être envoyés par e-mail aux destinataires.
ClusterControl :planifier un rapport opérationnel Évaluation de la sécurité de la base de données MySQL
Vérification de la mise à niveau du package
Tout d'abord, nous allons commencer par les contrôles de sécurité. Être à jour avec les correctifs MySQL aidera à réduire les risques associés aux vulnérabilités connues présentes dans le serveur MySQL. Vous pouvez maintenir votre environnement à jour en utilisant le référentiel de packages des fournisseurs. Sur la base de ces informations, vous pouvez créer vos propres rapports ou utiliser des outils tels que ClusterControl pour vérifier votre environnement et vous alerter des éventuelles mises à jour.
Le rapport de mise à niveau de ClusterControl rassemble les informations du système d'exploitation et les compare aux packages disponibles dans le référentiel. Le rapport est divisé en quatre sections; récapitulatif de mise à niveau, packages de base de données, packages de sécurité et autres packages. Vous pouvez comparer rapidement ce que vous avez installé sur votre système et trouver une mise à niveau ou un correctif recommandé.
ClusterControl :rapport de mise à niveau 
ClusterControl :détails du rapport de mise à niveau Pour les comparer manuellement, vous pouvez exécuter
SHOW VARIABLES WHERE variable_name LIKE "version";
Avec des bulletins de sécurité comme :
https://www.oracle.com/technetwork/topics/security/alerts-086861.html
https://nvd.nist.gov/view/vuln/search- résultats ?adv_search=true&cves=on&cpe_vendor=cpe%3a%2f%3aoracle&cpe_produ
https://www.percona.com/doc/percona-server/LATEST/release-notes/release-notes_index.html
https://downloads.mariadb.org/mariadb/+releases/
https://www.cvedetails.com/vulnerability-list/vendor_id-12010/Mariadb.html
https://www. cvedetails.com/vulnerability-list/vendor_id-13000/Percona.html
Ou référentiels de fournisseurs :
Sur Debian
sudo apt list mysql-serverSur RHEL/Centos
yum list | grep -i mariadb-serverComptes sans mot de passe
Les mots de passe vides permettent à un utilisateur de se connecter sans utiliser de mot de passe. MySQL était fourni avec un ensemble d'utilisateurs pré-créés, dont certains peuvent se connecter à la base de données sans mot de passe ou, pire encore, des utilisateurs anonymes. Heureusement, cela a changé dans MySQL 5.7. Enfin, il est livré uniquement avec un compte root qui utilise le mot de passe que vous choisissez au moment de l'installation.
Pour chaque ligne renvoyée par la procédure d'audit, définissez un mot de passe :
SELECT User,host
FROM mysql.user
WHERE authentication_string='';De plus, vous pouvez installer un plug-in de validation de mot de passe et mettre en place une politique plus sécurisée :
INSTALL PLUGIN validate_password SONAME 'validate_password.so';
SHOW VARIABLES LIKE 'default_password_lifetime';
SHOW VARIABLES LIKE 'validate_password%';Un bon début peut être :
plugin-load=validate_password.so
validate-password=FORCE_PLUS_PERMANENT
validate_password_length=14
validate_password_mixed_case_count=1
validate_password_number_count=1
validate_password_special_char_count=1
validate_password_policy=MEDIUMBien sûr, ces paramètres dépendront des besoins de votre entreprise.
Surveillance de l'accès à distance
Éviter l'utilisation de caractères génériques dans les noms d'hôte permet de contrôler les emplacements spécifiques à partir desquels un utilisateur donné peut se connecter et interagir avec la base de données.
Vous devez vous assurer que chaque utilisateur ne peut se connecter à MySQL qu'à partir d'hôtes spécifiques. Vous pouvez toujours définir plusieurs entrées pour le même utilisateur, cela devrait aider à réduire le besoin de caractères génériques.
Exécutez l'instruction SQL suivante pour évaluer cette recommandation (assurez-vous qu'aucune ligne n'est renvoyée) :
SELECT user, host FROM mysql.user WHERE host = '%';Tester la base de données
L'installation par défaut de MySQL est livrée avec une base de données inutilisée appelée test et la base de données de test est disponible pour tous les utilisateurs, en particulier pour les utilisateurs anonymes. Ces utilisateurs peuvent créer des tables et y écrire. Cela peut potentiellement devenir un problème en soi - et les écritures ajouteraient une surcharge et réduiraient les performances de la base de données. Il est recommandé de supprimer la base de données de test. Pour déterminer si la base de données de test est présente, exécutez :
SHOW DATABASES LIKE 'test';Si vous remarquez que la base de données de test est présente, il se peut que le script mysql_secure_installation qui supprime la base de données de test (ainsi que d'autres activités liées à la sécurité) n'ait pas été exécuté.
CHARGER LE FICHIER DE DONNEES
Si le serveur et le client ont la possibilité d'exécuter LOAD DATA LOCAL INFILE, un client pourra charger des données d'un fichier local vers un serveur MySQL distant. Le paramètre local_infile indique si les fichiers situés sur l'ordinateur du client MySQL peuvent être chargés ou sélectionnés via LOAD DATA INFILE ou SELECT local_file.
Ceci, potentiellement, peut aider à lire les fichiers auxquels le client a accès - par exemple, sur un serveur d'application, on pourrait accéder à toutes les données auxquelles le serveur HTTP a accès. Pour l'éviter, vous devez définir local-infile=0 dans my.cnf.
Exécutez l'instruction SQL suivante et assurez-vous que le champ Valeur est défini sur OFF :
SHOW VARIABLES WHERE Variable_name = 'local_infile';Surveiller les espaces de table non chiffrés
À partir de MySQL 5.7.11, InnoDB prend en charge le chiffrement des données pour les tables stockées dans des espaces de table fichier par table. Cette fonctionnalité fournit un chiffrement au repos pour les fichiers de données d'espace de table physique. Pour vérifier si vos tables ont été chiffrées, exécutez :
mysql> SELECT TABLE_SCHEMA, TABLE_NAME, CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES
WHERE CREATE_OPTIONS LIKE '%ENCRYPTION="Y"%';
+--------------+------------+----------------+
| TABLE_SCHEMA | TABLE_NAME | CREATE_OPTIONS |
+--------------+------------+----------------+
| test | t1 | ENCRYPTION="Y" |
+--------------+------------+----------------+Dans le cadre du chiffrement, vous devez également envisager le chiffrement du journal binaire. Le serveur MySQL écrit de nombreuses informations dans les journaux binaires.
Validation de la connexion chiffrée
Dans certaines configurations, la base de données ne doit pas être accessible via le réseau si chaque connexion est gérée localement, via le socket Unix. Dans de tels cas, vous pouvez ajouter la variable « skip-networking » dans my.cnf. Le saut de réseau empêche MySQL d'utiliser une connexion TCP/IP, et seul le socket Unix serait possible sous Linux.
Cependant, il s'agit d'une situation plutôt rare car il est courant d'accéder à MySQL via le réseau. Vous devez ensuite vérifier que vos connexions sont cryptées. MySQL prend en charge SSL comme moyen de crypter le trafic à la fois entre les serveurs MySQL (réplication) et entre les serveurs MySQL et les clients. Si vous utilisez le cluster Galera, des fonctionnalités similaires sont disponibles - la communication intra-cluster et les connexions avec les clients peuvent être cryptées à l'aide de SSL. Pour vérifier si vous utilisez le cryptage SSL, exécutez les requêtes suivantes :
SHOW variables WHERE variable_name = 'have_ssl';
select ssl_verify_server_cert from mysql.slave_master_info;C'est tout pour le moment. Cette liste n'est pas exhaustive, faites-nous savoir s'il y a d'autres vérifications que vous effectuez aujourd'hui sur vos bases de données de production.
