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 base 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 base 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 du journal d'audit Aurora MySQL dans un groupe de journaux CloudWatch. Vous pouvez ensuite consulter, filtrer et rechercher les journaux d'audit via l' CloudWatch interface. Pour plus d’informations, consultez Publication de journaux Amazon Aurora MySQL sur 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 base 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, veuillez consulter 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 base de données. Vous pouvez utiliser la procédure présentée dans Modification des paramètres d'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 AWS CLI commande modify-db-cluster-parameter-group ou l'opération d'API Amazon RDS ModifyDB ClusterParameter Group pour modifier les paramètres du cluster de bases de données par programmation.

La modification de ces paramètres n'exige pas de redémarrage du cluster de base 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' CloudWatchinterface 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 contient aucun filtre qui exclut certaines requêtes des journaux d'audit. Pour exclure SELECT des requêtes, vous devez exclure toutes les instructions DML.

Si un utilisateur signale ces SELECT requêtes internes dans les journaux d'audit, vous pouvez l'exclure en définissant le paramètre de cluster de base 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 pour exclure les SELECT requêtes.

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 de plus amples informations, veuillez consulter 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. Chaque instance Aurora distribue les écritures dans quatre fichiers journaux à la fois. La taille maximale des journaux est de 100 Mo au total. Lorsque cette limite non configurable est atteinte, Aurora effectue une rotation des fichiers et génère quatre nouveaux fichiers.

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 des journaux, activez le paramètre permettant de télécharger les journaux d'audit CloudWatch et de les consulter à l'aide de l' CloudWatch interface.

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 Aurora à l'aide des flux d'activité des bases 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.