Utilisation de l’Audit avancé avec un cluster de bases de données Amazon Aurora MySQL - Amazon Aurora
Activation de l’Audit avancéConsultation des journaux d’auditDétails du journal d’audit

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utilisation de l’Audit avancé avec un cluster de bases de données Amazon Aurora MySQL

Vous pouvez utiliser la fonctionnalité d’Audit avancé hautement performante d’Amazon Aurora MySQL pour contrôler l’activité de la base de données. Pour ce faire, vous activez l’ensemble des journaux d’audit en définissant plusieurs paramètres du cluster de bases de données. Lorsque l’Audit avancé est activé, vous pouvez l’utiliser pour consigner n’importe quelle combinaison d’événements pris en charge.

Vous pouvez afficher ou télécharger les journaux d’audit pour consulter les informations d’audit d’une instance de base de données à la fois. Pour ce faire, vous pouvez utiliser les procédures présentées dans Surveillance des fichiers journaux Amazon Aurora.

Astuce

Pour un cluster de bases de données Aurora contenant plusieurs instances de base de données, il peut être plus pratique d’examiner les journaux d’audit de toutes les instances du cluster. Pour ce faire, vous pouvez utiliser CloudWatch Logs. Vous pouvez activer un paramètre au niveau du cluster pour publier les données des journaux d’audit Aurora MySQL dans un groupe de journaux dans CloudWatch. Vous pouvez ensuite afficher, filtrer et examiner les journaux d’audit via l’interface CloudWatch. Pour plus d’informations, consultez Publication de journaux Amazon Aurora MySQL dans Amazon CloudWatch Logs.

Activation de l’Audit avancé

Utilisez les paramètres décrits dans cette section pour activer et configurer l’Audit avancé pour votre cluster de bases de données.

Utilisez le paramètre server_audit_logging pour activer ou désactiver l’Audit avancé.

Utilisez le paramètre server_audit_events pour spécifier les événements à journaliser.

Utilisez les paramètres server_audit_incl_users et server_audit_excl_users pour spécifier les utilisateurs à auditer. Par défaut, tous les utilisateurs sont audités. Pour plus d’informations sur le fonctionnement de ces paramètres lorsque l’un ou les deux sont vides, ou que les mêmes noms d’utilisateur sont spécifiés dans les deux, consultez les sections server_audit_incl_users et server_audit_excl_users.

Configurez l’Audit avancé en définissant ces paramètres dans le groupe de paramètres utilisé par votre cluster de bases de données. Vous pouvez utiliser la procédure présentée dans Modification de paramètres dans un groupe de paramètres de base de données dans Amazon Aurora pour modifier les paramètres de cluster de bases de données à l’aide d’AWS Management Console. Vous pouvez utiliser la commande de l’AWS CLI modify-db-cluster-parameter-group ou l’opération d’API Amazon RDS ModifyDBClusterParameterGroup pour modifier des paramètres de cluster de bases de données par programmation.

La modification de ces paramètres n’exige pas de redémarrage du cluster de bases de données lorsque le groupe de paramètres est déjà associé à votre cluster. Lorsque vous associez le groupe de paramètres au cluster pour la première fois, un redémarrage du cluster est nécessaire.

server_audit_logging

Active ou désactive l’Audit avancé. Par défaut, ce paramètre est défini sur OFF. Définissez-le sur ON pour activer l’Audit avancé.

Aucune donnée d’audit n’apparaît dans les journaux, à moins que vous ne définissiez également un ou plusieurs types d’événements à auditer à l’aide du paramètre server_audit_events.

Pour confirmer que les données d’audit sont journalisées pour une instance de base de données, vérifiez que certains fichiers journaux de cette instance soient nommés sous la forme audit/audit.log.other_identifying_information. Pour voir les noms des fichiers journaux, suivez la procédure présentée dans Liste et affichage des fichiers journaux de base de données.

server_audit_events

Contient la liste séparée par des virgules des événements à consigner. Les événements doivent être indiqués en lettres majuscules, et il ne doit y avoir aucun espace entre les éléments de liste, par exemple : CONNECT,QUERY_DDL. La valeur par défaut de ce paramètre est une chaîne vide.

Vous pouvez consigner n’importe quelle combinaison des événements suivants :

  • CONNECT – Consigne les connexions réussies et celles ayant échoué, ainsi que les déconnexions. Cet événement inclut des informations utilisateur.

  • QUERY – Consigne toutes les requêtes en texte brut, notamment les requêtes ayant échoué suite à des erreurs de syntaxe ou d’autorisation.

    Astuce

    Lorsque ce type d’événement est activé, les données d’audit incluent des informations sur la surveillance continue et les informations de surveillance de l’état effectuées automatiquement par Aurora. Si vous ne vous intéressez qu’à des types particuliers d’opérations, vous pouvez utiliser les types d’événements les plus spécifiques. Vous pouvez également utiliser l’interface CloudWatch pour rechercher dans les journaux des événements liés à des bases de données, des tables ou des utilisateurs spécifiques.

  • QUERY_DCL – Semblable à l’événement QUERY, mais renvoie uniquement les requêtes en langage de contrôle de données (DCL) (GRANT, REVOKE, etc.).

  • QUERY_DDL – Semblable à l’événement QUERY, mais renvoie uniquement les requêtes en langage de définition de données (DDL) (CREATE, ALTER, etc.).

  • QUERY_DML – Semblable à l’événement QUERY, mais renvoie uniquement les requêtes en langage de manipulation de données (DML) (INSERT, UPDATE, etc. ainsi que SELECT).

  • TABLE – Consigne les tables affectées par l’exécution d’une requête.

Note

Aurora ne comporte aucun filtre qui exclut certaines requêtes des journaux d’audit. Pour exclure des requêtes SELECT, vous devez exclure toutes les instructions DML.

Si un utilisateur signale ces requêtes SELECT internes dans les journaux d’audit, vous pouvez l’exclure en définissant le paramètre de cluster de bases de données server_audit_excl_users. Toutefois, si cet utilisateur est également utilisé dans d’autres activités et ne peut pas être omis, il n’existe aucune autre option permettant d’exclure les requêtes SELECT.

server_audit_incl_users

Contient la liste séparée par des virgules des noms d’utilisateur des utilisateurs dont l’activité est consignée. Il ne doit y avoir aucun espace blanc entre les éléments de la liste, par exemple : user_3,user_4. La valeur par défaut de ce paramètre est une chaîne vide. La longueur maximale est de 1 024 caractères. Les noms d’utilisateur spécifiés doivent correspondre aux valeurs figurant dans la colonne User de la table mysql.user. Pour plus d’informations sur les noms d’utilisateur, consultez Noms d’utilisateur et mots de passe de compte dans la documentation sur MySQL.

Si server_audit_incl_users et server_audit_excl_users sont vides (valeurs par défaut), tous les utilisateurs sont audités.

Si vous ajoutez des utilisateurs à server_audit_incl_users et laissez server_audit_excl_users vide, alors seuls ces utilisateurs sont audités.

Si vous ajoutez des utilisateurs à server_audit_excl_users et laissez server_audit_incl_users vide, alors tous les utilisateurs sont audités, à l’exception de ceux répertoriés dans server_audit_excl_users.

Si vous ajoutez les mêmes utilisateurs à server_audit_excl_users et server_audit_incl_users, alors ces utilisateurs sont audités. Lorsque le même utilisateur est répertorié dans les deux paramètres, server_audit_incl_users se voit accorder la priorité.

Les événements de connexion et de déconnexion ne sont pas affectés par cette variable ; ils sont toujours consignés, le cas échéant. Un utilisateur est journalisé même s’il est également spécifié dans le paramètre server_audit_excl_users, car la priorité de server_audit_incl_users est plus élevée.

server_audit_excl_users

Contient la liste séparée par des virgules des noms d’utilisateur des utilisateurs dont l’activité n’est pas consignée. Il ne doit y avoir aucun espace blanc entre les éléments de la liste, par exemple : rdsadmin,user_1,user_2. La valeur par défaut de ce paramètre est une chaîne vide. La longueur maximale est de 1 024 caractères. Les noms d’utilisateur spécifiés doivent correspondre aux valeurs figurant dans la colonne User de la table mysql.user. Pour plus d’informations sur les noms d’utilisateur, consultez Noms d’utilisateur et mots de passe de compte dans la documentation sur MySQL.

Si server_audit_incl_users et server_audit_excl_users sont vides (valeurs par défaut), tous les utilisateurs sont audités.

Si vous ajoutez des utilisateurs à server_audit_excl_users et laissez server_audit_incl_users vide, alors seuls ces utilisateurs répertoriés dans server_audit_excl_users ne sont pas audités, tous les autres le sont.

Si vous ajoutez les mêmes utilisateurs à server_audit_excl_users et server_audit_incl_users, alors ces utilisateurs sont audités. Lorsque le même utilisateur est répertorié dans les deux paramètres, server_audit_incl_users se voit accorder la priorité.

Les événements de connexion et de déconnexion ne sont pas affectés par cette variable ; ils sont toujours consignés, le cas échéant. Un utilisateur est consigné si ce dernier est également spécifié dans le paramètre server_audit_incl_users car celui-ci possède une priorité supérieure à server_audit_excl_users.

Consultation des journaux d’audit

Vous pouvez consulter et télécharger les journaux d’audit à l’aide de la console. Dans la page Bases de données, choisissez l’instance de base de données pour en afficher les détails, puis faites défiler la page jusqu’à la section Journaux. Les journaux d’audit produits par la fonction d’audit avancé sont nommés sous la forme audit/audit.log.other_identifying_information.

Pour télécharger un fichier journal, recherchez le fichier dans la section Journaux puis choisissez Télécharger.

Vous pouvez également obtenir la liste des fichiers journaux à l’aide de la commande describe-db-log-files de l’AWS CLI. Vous pouvez télécharger le contenu d’un fichier journal à l’aide de la commande download-db-log-file-portion de l’AWS CLI. Pour plus d’informations, consultez Liste et affichage des fichiers journaux de base de données et Téléchargement d’un fichier journal de base de données.

Détails du journal d’audit

Les fichiers journaux sont représentés sous forme de fichiers CSV (variables séparées par des virgules) au format UTF-8. Les requêtes sont également placées entre guillemets simples (’).

Le journal d’audit est stocké séparément sur le stockage local de chaque instance de base de données Aurora MySQL. Chaque instance distribue les écritures entre quatre fichiers journaux à la fois. La taille maximale d’un fichier journal est de 100 Mo. Lorsque cette limite non configurable est atteinte, Aurora effectue une rotation de fichier et en génère un nouveau.

Astuce

Les entrées de fichier journal ne sont pas classées par ordre séquentiel. Pour ordonner les entrées, utilisez la valeur d’horodatage. Pour consulter les derniers événements, vous devrez peut-être passer en revue tous les fichiers journaux. Pour plus de flexibilité dans le tri et la recherche des données de journaux, activez le paramètre pour charger les journaux d’audit sur CloudWatch et les afficher à l’aide de l’interface CloudWatch.

Pour afficher des données d’audit avec plus de types de champs et avec une sortie au format JSON, vous pouvez également utiliser la fonction Flux d’activité de base de données. Pour plus d’informations, consultez Surveillance d’Amazon Aurora à l’aide des flux d’activité de base de données.

Les fichiers journaux d’audit incluent les informations séparées par des virgules suivantes en lignes, dans l’ordre indiqué :

Champ Description

timestamp

L’horodatage Unix pour l’événement consigné avec une précision à la microseconde.

serverhost

Le nom de l’instance pour laquelle*** l’événement est consigné.

username

Le nom d’utilisateur connecté de l’utilisateur.

hôte

L’hôte à partir duquel** l’utilisateur s’est connecté.

connectionid

Le numéro d’identification de la connexion pour l’opération consignée.

queryid

Le numéro d’identification de la requête qui peut être utilisé pour trouver les événements de la table relationnelle et les requêtes liées. Pour les événements TABLE, plusieurs lignes sont ajoutées.

fonctionnement

Le type d’action enregistrée. Les valeurs possibles sont : CONNECT, QUERY, READ, WRITE, CREATE, ALTER, RENAME et DROP.

database

La base de données active, telle que définie par la commande USE.

objet

Pour les événements QUERY, cette valeur indique la demande effectuée par la base de données. Pour les événements TABLE, cette valeur indique le nom de la table.

retcode

Le code de retour de l’opération consignée.