Audit de base de données MySQL

MySQL | PostgreSQL | SQL Server

Cet article décrit l'audit de base de données Cloud SQL pour MySQL et le plug-in d'audit Cloud SQL pour MySQL. Pour utiliser l'audit de base de données dès maintenant, consultez la section Utiliser l'audit de base de données MySQL.

Qu'est-ce que l'audit de base de données ?

L'audit de base de données vous permet de suivre des actions spécifiques des utilisateurs dans la base de données, telles que des mises à jour de table, des requêtes de lecture, des attributions de droits d'utilisateur, etc. Les audits de bases de données sont utiles pour les organisations qui doivent suivre l'activité des utilisateurs pour des raisons de sécurité ou pour se conformer à diverses réglementations financières, gouvernementales et ISO. L'audit de base de données est compatible avec Cloud SQL pour MySQL 5.7 et 8.0.

Plug-in d'audit Cloud SQL pour MySQL

L'audit de base de données est activé par le plug-in d'audit Cloud SQL pour MySQL, ou cloudsql_mysql_audit. Ce plug-in utilise l'API d'audit MySQL ouverte pour surveiller et consigner l'activité dans MySQL. Le plug-in envoie des journaux aux journaux d'audit d'accès aux données de Cloud Logging. Les journaux d'audit d'accès aux données sont désactivés par défaut, car ils peuvent être volumineux. Vous devez explicitement activer les journaux pour utiliser le plug-in.

Lorsque le plug-in est actif, les règles d'audit existantes que vous avez créées sont appliquées afin de générer les journaux d'audit pour la base de données. Lorsque le plug-in est désactivé, aucun journal d'audit n'est généré.

Pour en savoir plus sur les plug-ins MySQL, consultez la section Plug-ins MySQL Server.

Qui utilise l'audit de base de données ?

Trois types d'utilisateurs sont impliqués dans l'audit de base de données :

Administrateurs : utilisateurs qui administrent la base de données. Les administrateurs sont des utilisateurs de l'audit responsables de l'activation et de la désactivation de l'audit sur l'instance et de la création de nouveaux utilisateurs. Ils accordent également les autorisations d'audit aux auditeurs. Les administrateurs peuvent également créer, supprimer et mettre à jour des règles d'audit.
Auditeurs : utilisateurs autorisés à créer, supprimer et mettre à jour les règles d'audit. Leurs accès sont attribués par les administrateurs.
Clients : utilisateurs dont l'activité est auditée via les règles d'audit mais qui ne sont pas des utilisateurs de l'audit et n'ont pas de droits d'administration ou d'audit. Leurs accès sont régis par les administrateurs.

Les administrateurs et les auditeurs sont également appelés "utilisateurs de l'audit".

Règles d'audit

L'audit de base de données utilise des règles d'audit pour définir des combinaisons d'utilisateurs, de bases de données, d'objets, d'opérations et d'états devant déclencher la création d'un journal d'audit. Une règle d'audit contient les informations suivantes :

Id : identifiant de règle autonumérique. Chaque règle d'audit est automatiquement associée à un ID d'audit lors de la création de la règle. Une fois créé, l'ID d'audit n'est pas modifiable.
Username : Liste des utilisateurs et/ou caractères génériques séparés par des virgules. Vous pouvez utiliser des astérisques (*) comme caractères génériques pour l'utilisateur et pour l'hôte. Utilisez l'astérisque comme suffixe, préfixe ou les deux. En outre, les utilisateurs ne peuvent utiliser le caractère générique % que pour l'hôte. Le maximum est de 2 048 caractères.
Dbname : liste des noms de base de données et/ou caractères génériques séparés par des virgules. Vous pouvez utiliser des astérisques (*) comme caractères génériques pour l'utilisateur et pour l'hôte. Utilisez l'astérisque comme suffixe, préfixe ou les deux. Le maximum est de 2 048 caractères.
Object : liste des noms d'objets de base de données (tables, fonctions, procédures stockées, etc.) et/ou caractères génériques séparés par des virgules. Vous pouvez utiliser des astérisques (*) comme caractères génériques pour l'utilisateur et pour l'hôte. Utilisez l'astérisque comme suffixe, préfixe ou les deux. Le maximum est de 2 048 caractères.
Operation : liste des opérations de base de données séparées par des virgules. Le plug-in accepte les opérations groupées (telles que LDD, LMD, etc.), les opérations uniques (telles que les mises à jour, les suppressions, etc.) et les caractères génériques (*) pour toutes les opérations. Consultez la liste complète des opérations compatibles. Le plug-in accepte également les groupes d'opérations que vous pouvez utiliser pour auditer un groupe d'opérations. Le maximum est de 2 048 caractères.
Op_result : résultat de l'opération.
- S pour auditer les opérations ayant réussi
- U pour l'audit des opérations ayant échoué
- B pour le suivi des opérations ayant réussi ou échoué
- E pour créer des règles exclusives

Types d'opération

Les types d'opération sont les différents types d'activités ou opérations que vous pouvez auditer dans la base de données :

DQL : lire les données de la base de données (c'est-à-dire les instructions SELECT)
DML : ajouter, supprimer ou modifier des données
DDL : créer ou modifier la structure des objets de base de données dans la base de données
DCL : gérer les droits des utilisateurs dans la base de données
Show : décrire les objections de la base de données ou indiquer son état.
Call : appeler une procédure stockée

Considérations affectant la journalisation d'audit

Sauvegardes

Lors de la restauration d'une instance à partir d'une sauvegarde ou d'une récupération à un moment précis (PITR), les règles d'audit effectuent également un rollback à l'heure de la sauvegarde ou de la récupération. Cela se produit car les règles d'audit font partie des données stockées dans la base de données, tout comme les cibles (les utilisateurs et les objets) que la règle audite.

Instances dupliquées avec accès en lecture

Les règles d'audit sont automatiquement répliquées d'une instance principale vers ses instances dupliquées avec accès en lecture. Les clients ne peuvent pas ajouter, supprimer ni modifier des règles d'audit sur des instances dupliquées avec accès en lecture. Si vous souhaitez modifier les règles d'audit d'une instance dupliquée, vous devez mettre à jour les règles d'audit de l'instance principale.

Si vous mettez à jour les règles d'audit sur l'instance principale, vous devez actualiser la règle d'audit sur l'instance dupliquée afin de vous assurer que les nouvelles règles d'audit sont également mises à jour sur les instances dupliquées avec accès en lecture. La commande suivante actualise la règle d'audit :

CALL mysql.cloudsql_reload_audit_rule(1)

Les utilisateurs peuvent activer la journalisation d'audit sur les instances dupliquées indépendamment de l'instance principale. Après avoir modifié l'instance principale, vous devez exécuter la commande d'actualisation ou redémarrer l'instance dupliquée pour rendre les règles de journal d'audit effectives.

Disponibilité des bases de données lors des échecs de journaux d'audit

Si une opération d'audit échoue, Cloud SQL n'empêche pas l'activité de la base de données de se terminer. Par exemple, lorsqu'une instance manque d'espace disque et que Cloud SQL ne peut pas générer de journal d'audit, la base de données permet toujours à l'utilisateur d'effectuer des requêtes de lecture, même si cette activité génère normalement un journal d'audit.

Instances en lecture seule

Si une instance a l'option read_only définie sur true, vous ne pouvez pas ajouter ni mettre à jour de règles d'audit, car elles sont stockées dans les tables. Avant de pouvoir créer, mettre à jour ou supprimer des règles, vous devez supprimer l'option read_only.

Limites et problèmes connus

Appliquer des journaux binaires

Le plug-in d'audit Cloud SQL pour MySQL n'est pas compatible avec les journaux binaires sur une instance.

Dans certains cas, si vous essayez d'appliquer des journaux binaires lorsque le plug-in d'audit Cloud SQL pour MySQL est activé, il se peut que l'instance de base de données plante.

Si vous souhaitez appliquer des journaux binaires à l'aide de l'utilitaire mysqlbinlog, vous devez d'abord désactiver l'audit de base de données en définissant cloudsql_mysql_audit=OFF.

Taux d'ingestion de journaux

Avant que Cloud SQL n'envoie les journaux d'audit à Cloud Logging, ils sont temporairement écrits sur le disque de l'instance, en utilisant l'espace disque. Les journaux sont importés dans Cloud Logging et supprimés du disque à une vitesse de 4 Mo par seconde. Lorsque la charge de la génération des journaux dépasse le taux d'importation, l'instance subit une augmentation de l'utilisation du disque, ce qui peut entraîner un manque de capacité de disque et un plantage de votre base de données. Même si l'augmentation automatique de l'espace de stockage sur disque est activée, l'augmentation de l'utilisation du disque augmente les coûts.

Lorsque vous utilisez cette fonctionnalité, voici nos recommandations :

Activez l'augmentation automatique de l'espace de stockage.
Surveillez l'utilisation globale du disque. Vous ne pouvez pas surveiller la charge de génération de journaux séparément. Utilisez la métrique cloudsql.googleapis.com/database/disk/utilization dans l'Explorateur de métriques.
Si nécessaire, réduisez la vitesse de génération des journaux en limitant l'activité de la base de données ou en réduisant l'audit.

Auditer les opérations ayant échoué

Si vos règles d'audit incluent l'audit des opérations ayant échoué (op_result est défini sur U pour les opérations ayant échoué ou sur B pour les opérations ayant réussi ou échoué), certains utilisateurs pourraient surcharger votre instance de base de données avec des journaux d'audit en exécutant en continu des opérations ayant échoué. Si la vitesse de génération des journaux dépasse le taux d'ingestion des journaux, une augmentation indésirable de l'utilisation du disque peut se produire, épuisant ainsi l'espace disque. Au lieu de cela, procédez ainsi lorsque vous auditez des opérations ayant échoué :

Contrôlez les accès au niveau de l'instance.
Configurez un système de surveillance ou d'alerte pour signaler toute augmentation anormale des journaux d'opérations ayant échoué.

Règles d'audit

Vous ne pouvez pas créer plus de 1 000 combinaisons de règles d'audit au total par instance de base de données. Une combinaison de règles d'audit est un ensemble unique composé d'un utilisateur, d'une base de données, d'un objet et d'opérations. Par exemple, une règle d'audit s'appliquant à user1,user2, db1,db2, table1,table2 et select,delete génère 2 x 2 x 2 x 2 = 16 combinaisons. La création ou la mise à jour des règles d'audit échoue si le nombre total de combinaisons de règles d'audit est supérieur à 1 000.

Opérations non acceptées

Les opérations suivantes ne sont actuellement pas acceptées.

Les fonctions suivantes ne sont pas acceptées lorsqu'elles sont utilisées comme décrit ci-dessous :
- Dans les requêtes SELECT avec UNION, INTERSECT, la clause WHERE, les requêtes imbriquées, les sous-requêtes, etc.
- Dans les instructions UPDATE, DELETE, INSERT et REPLACE.
Par exemple, si vous disposez d'une règle d'audit pour auditer l'objet func1, les éléments suivants ne sont pas audités :
- SELECT func1() FROM table;
- SELECT * FROM table WHERE a = func1();
- SELECT func1() != 0;
- SELECT func1() > 0;
- SET @x = func1();
Une fonction appelée directement par SELECT sans aucun opérateur et sans clause WHERE est auditée :
- SELECT func1();
- SELECT db.func1();
Le filtrage par adresse IP n'est pas disponible pour le moment.

Étape suivante

Découvrez comment utiliser l'audit de base de données MySQL.