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](USER_LogAccess.md).
**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](AuroraMySQL.Integrating.CloudWatch.md).
## 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\$1audit\$1incl\$1users](#AuroraMySQL.Auditing.Enable.server_audit_incl_users) et [server\$1audit\$1excl\$1users](#AuroraMySQL.Auditing.Enable.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](USER_WorkingWithParamGroups.Modifying.md) 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](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-parameter-group.html) ou l’opération d’API Amazon RDS [ModifyDBClusterParameterGroup](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBClusterParameterGroup.html) 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.
**Topics**
+ [server\$1audit\$1logging](#AuroraMySQL.Auditing.Enable.server_audit_logging)
+ [server\$1audit\$1events](#AuroraMySQL.Auditing.Enable.server_audit_events)
+ [server\$1audit\$1incl\$1users](#AuroraMySQL.Auditing.Enable.server_audit_incl_users)
+ [server\$1audit\$1excl\$1users](#AuroraMySQL.Auditing.Enable.server_audit_excl_users)
### server\$1audit\$1logging
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](USER_LogAccess.Procedural.Viewing.md).
### server\$1audit\$1events
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\$1DCL – Semblable à l’événement QUERY, mais renvoie uniquement les requêtes en langage de contrôle de données (DCL) (GRANT, REVOKE, etc.).
+ QUERY\$1DDL – Semblable à l’événement QUERY, mais renvoie uniquement les requêtes en langage de définition de données (DDL) (CREATE, ALTER, etc.).
+ QUERY\$1DML – 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\$1audit\$1excl\$1users](#AuroraMySQL.Auditing.Enable.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\$1audit\$1incl\$1users
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](https://dev.mysql.com/doc/refman/8.0/en/user-names.html) 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\$1audit\$1excl\$1users
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](https://dev.mysql.com/doc/refman/8.0/en/user-names.html) 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](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-log-files.html) 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](https://docs.aws.amazon.com/cli/latest/reference/rds/download-db-log-file-portion.html) de l’AWS CLI. Pour plus d’informations, consultez [Liste et affichage des fichiers journaux de base de données](USER_LogAccess.Procedural.Viewing.md) et [Téléchargement d’un fichier journal de base de données](USER_LogAccess.Procedural.Downloading.md).
## 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](DBActivityStreams.md).
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\$1\$1\$1 l’événement est consigné. |
| username | Le nom d’utilisateur connecté de l’utilisateur. |
| hôte | L’hôte à partir duquel\$1\$1 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. |