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. # Événements, journaux et pistes d'audit La surveillance des [métriques des instances](db-instance-monitoring.md) de base de données et [des métriques du système d'exploitation](os-monitoring.md), l'analyse des tendances, la comparaison des métriques avec les valeurs de référence et la génération d'alertes lorsque les valeurs dépassent les seuils définis sont autant de bonnes pratiques nécessaires pour vous aider à atteindre et à maintenir la fiabilité, la disponibilité, les performances et la sécurité de vos instances de base de données Amazon RDS. Cependant, une solution complète doit également surveiller les événements de base de données, les fichiers journaux et les pistes d'audit des bases de données MySQL et MariaDB. **Sections** + [Événements Amazon RDS](rds-events.md) + [journaux de base de données](database-logs.md) + [Pistes d'audit](audit-trails.md) # Événements Amazon RDS Un *événement *Amazon* RDS* indique un changement dans l'environnement Amazon RDS. Par exemple, lorsque le statut de l'instance de base de données passe de *Starting* à *Available*, Amazon RDS génère l'événement`RDS-EVENT-0088 The DB instance has been started`. Amazon RDS diffuse des événements à Amazon EventBridge quasiment en temps réel. Vous pouvez accéder aux événements via la console Amazon RDS, la AWS CLI commande [describe-events](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/describe-events.html) ou le fonctionnement de l'API Amazon RDS. [DescribeEvents](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeEvents.html) L'illustration d'écran suivante montre les événements et les journaux affichés sur la console Amazon RDS. ![\[Alarmes, événements et journaux affichés sur la console Amazon RDS\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/amazon-rds-monitoring-alerting/images/alarms-events-logs-rds-console.png) Amazon RDS émet différents types d'événements, notamment des événements d'instance de base de données, des événements de groupe de paramètres de base de données, des événements de groupe de sécurité de base de données, des événements de capture de base de données, des événements de proxy RDS et des événements de déploiement bleu/vert. Les informations incluent : + Nom et type de source ; par exemple : `"SourceIdentifier": "database-1", "SourceType": "db-instance"` + Date et heure de l'événement ; par exemple : `"Date": "2022-12-01T09:20:28.595000+00:00"` + Message associé à l'événement, par exemple : `"Message": "Finished updating DB parameter group"` + Catégorie d'événement ; par exemple : `"EventCategories": ["configuration change"]` Pour une référence complète, consultez les [catégories d'événements et les messages d'événements Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Messages.html) dans la documentation Amazon RDS. Nous vous recommandons de surveiller les événements Amazon RDS, car ils indiquent des changements de statut concernant la disponibilité des instances de base de données, des modifications de configuration, des modifications de l'état de lecture des répliques, des événements de sauvegarde et de restauration, des actions de basculement, des événements de défaillance, des modifications apportées aux groupes de sécurité et de nombreuses autres notifications. Par exemple, si vous avez configuré une instance de base de données de réplication en lecture afin d'améliorer les performances et la durabilité de votre base de données, nous vous recommandons de surveiller les événements Amazon RDS pour la catégorie d'événements de *réplication en lecture* associée aux instances de base de données. Cela est dû au fait que des événements tels que `RDS-EVENT-0057 Replication on the read replica was terminated` ceux indiquant que votre réplique en lecture ne se synchronise plus avec l'instance de base de données principale. Une notification à l'équipe responsable indiquant qu'un tel événement s'est produit pourrait aider à atténuer le problème en temps opportun. Amazon EventBridge et d'autres Services AWS entités AWS Lambda, telles qu'Amazon Simple Queue Service (Amazon SQS) et Amazon Simple Notification Service (Amazon SNS), peuvent vous aider à automatiser les réponses aux événements du système tels que les problèmes de disponibilité des bases de données ou les modifications des ressources. Sur la console Amazon RDS, vous pouvez récupérer les événements des dernières 24 heures. Si vous utilisez l'API AWS CLI ou l'API Amazon RDS pour consulter les événements, vous pouvez récupérer les événements des 14 derniers jours à l'aide de la commande **describe-events comme** suit. ``` $ aws rds describe-events --source-identifier database-1 --source-type db-instance { "Events": [ { "SourceIdentifier": "database-1", "SourceType": "db-instance", "Message": "CloudWatch Logs Export enabled for logs [audit, error, general, slowquery]", "EventCategories": [], "Date": "2022-12-01T09:20:28.595000+00:00", "SourceArn": "arn:aws:rds:eu-west-3:111122223333:db:database-1" }, { "SourceIdentifier": "database-1", "SourceType": "db-instance", "Message": "Finished updating DB parameter group", "EventCategories": [ "configuration change" ], "Date": "2022-12-01T09:22:40.413000+00:00", "SourceArn": "arn:aws:rds:eu-west-3:111122223333:db:database-1" } ] } ``` Si vous souhaitez stocker des événements sur le long terme, soit jusqu'à la période d'expiration spécifiée, soit de façon permanente, vous pouvez utiliser les [CloudWatch journaux](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) pour enregistrer les informations relatives aux événements générés par Amazon RDS. Pour implémenter cette solution, vous pouvez utiliser une rubrique Amazon SNS pour recevoir des notifications d'événements Amazon RDS, puis appeler une fonction Lambda pour enregistrer l'événement dans Logs. CloudWatch 1. Créez une fonction Lambda qui sera appelée lors de l'événement et enregistrez les informations de l'événement dans Logs. CloudWatch CloudWatch Logs est intégré à Lambda et constitue un moyen pratique de consigner les informations relatives aux événements, en utilisant la fonction **d'impression** pour. `stdout` 1. Créez une rubrique SNS avec un abonnement à une fonction Lambda (**définissez Protocol sur Lambda) et définissez** le point de **terminaison** sur le nom de ressource Amazon (ARN) de la fonction Lambda que vous avez créée à l'étape précédente. 1. Configurez votre rubrique SNS pour recevoir des notifications d'événements Amazon RDS. Pour obtenir des instructions détaillées, consultez l'[article AWS Re:Post](https://repost.aws/knowledge-center/sns-topics-rds-notifications) sur la façon de faire en sorte que votre rubrique Amazon SNS reçoive des notifications Amazon RDS. 1. Sur la console Amazon RDS, créez un nouvel abonnement à un événement. Définissez **Target** sur l'ARN, puis sélectionnez la rubrique SNS que vous avez créée précédemment. Définissez le **type de source** et **les catégories d'événements à inclure** en fonction de vos besoins. Pour plus d'informations, consultez la section [S'abonner aux notifications d'événements Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Subscribing.html) dans la documentation Amazon RDS. # Journaux de base de données Les bases de données MySQL et MariaDB génèrent des journaux auxquels vous pouvez accéder à des fins d'audit et de dépannage. Ces journaux sont les suivants : + [Audit](https://mariadb.com/kb/en/mariadb-audit-plugin-log-format/) — La piste d'audit est un ensemble d'enregistrements qui enregistrent l'activité du serveur. Pour chaque session client, il enregistre qui s'est connecté au serveur (nom d'utilisateur et hôte), quelles requêtes ont été exécutées, quelles tables ont été consultées et quelles variables du serveur ont été modifiées. + [Erreur](https://dev.mysql.com/doc/refman/8.0/en/error-log.html) — Ce journal contient les heures de démarrage et d'arrêt du serveur (`mysqld`), ainsi que les messages de diagnostic tels que les erreurs, les avertissements et les notes qui apparaissent lors du démarrage et de l'arrêt du serveur, ainsi que pendant le fonctionnement du serveur. + [Général](https://dev.mysql.com/doc/refman/8.0/en/query-log.html) — Ce journal enregistre l'activité`mysqld`, y compris l'activité de connexion et de déconnexion pour chaque client, ainsi que les requêtes SQL reçues des clients. Le journal général des requêtes peut être très utile lorsque vous suspectez une erreur et que vous souhaitez savoir exactement à quoi le client a envoyé un message`mysqld`. + [Requête lente](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html) : ce journal fournit un enregistrement des requêtes SQL dont l'exécution a pris du temps. Il est recommandé de [publier les journaux de base de données d'Amazon RDS vers Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Procedural.UploadtoCloudWatch.html). Avec CloudWatch Logs, vous pouvez effectuer une analyse en temps réel des données du journal, stocker les données dans un stockage hautement durable et gérer les données avec l'agent CloudWatch Logs. Vous pouvez [accéder aux journaux de votre base de données et les](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Procedural.Watching.html) consulter depuis la console Amazon RDS. Vous pouvez également utiliser CloudWatch Logs Insights pour rechercher et analyser de manière interactive les données de vos CloudWatch journaux dans Logs. L'exemple suivant illustre une requête dans le journal d'audit qui vérifie combien de fois les `CONNECT` événements apparaissent dans le journal, qui s'est connecté et depuis quel client (adresse IP) ils se sont connectés. L'extrait du journal d'audit pourrait ressembler à ceci : ``` 20221201 14:07:05,ip-10-22-1-51,rdsadmin,localhost,821,0,CONNECT,,,0,SOCKET 20221201 14:07:05,ip-10-22-1-51,rdsadmin,localhost,821,0,DISCONNECT,,,0,SOCKET 20221201 14:12:20,ip-10-22-1-51,rdsadmin,localhost,822,0,CONNECT,,,0,SOCKET 20221201 14:12:20,ip-10-22-1-51,rdsadmin,localhost,822,0,DISCONNECT,,,0,SOCKET 20221201 14:17:35,ip-10-22-1-51,rdsadmin,localhost,823,0,CONNECT,,,0,SOCKET 20221201 14:17:35,ip-10-22-1-51,rdsadmin,localhost,823,0,DISCONNECT,,,0,SOCKET 20221201 14:22:50,ip-10-22-1-51,rdsadmin,localhost,824,0,CONNECT,,,0,SOCKET 20221201 14:22:50,ip-10-22-1-51,rdsadmin,localhost,824,0,DISCONNECT,,,0,SOCKET ``` L'exemple de requête Log Insights montre qu'une personne est `rdsadmin` connectée à la base de données `localhost` toutes les 5 minutes, pour un total de 22 fois, comme indiqué dans l'illustration suivante. Ces résultats indiquent que l'activité provenait de processus internes d'Amazon RDS tels que le système de surveillance lui-même. ![\[Rapport Log Insights\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/amazon-rds-monitoring-alerting/images/log-insights.png) Les événements du journal incluent fréquemment des messages importants que vous souhaitez prendre en compte, tels que des avertissements ou des erreurs concernant les opérations associées aux instances de base de données MySQL et MariaDB. Par exemple, si une opération échoue, une erreur peut survenir et être enregistrée dans le fichier journal des erreurs comme suit : `ERROR 1114 (HY000): The table zip_codes is full` Vous souhaiterez peut-être surveiller ces entrées pour comprendre l'évolution de vos erreurs. Vous pouvez [créer des CloudWatch métriques personnalisées à partir des journaux Amazon RDS en utilisant des filtres](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html) pour activer la surveillance automatique des journaux des bases de données Amazon RDS afin de surveiller un journal spécifique pour détecter des modèles spécifiques et de générer une alarme en cas de violation du comportement attendu. [Par exemple](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CountOccurrencesExample.html), créez un filtre métrique pour le groupe de journaux `/aws/rds/instance/database-1/error` qui surveillerait le journal des erreurs et rechercherait le [modèle spécifique](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html), tel que`ERROR`. Définissez le **modèle de filtre** sur `ERROR` et la **valeur de la métrique** sur`1`. Le filtre détectera chaque enregistrement de journal contenant le mot clé `ERROR` et augmentera le nombre de 1 pour chaque événement de journal contenant le mot « ERROR ». Après avoir créé le filtre, vous pouvez définir une alarme pour vous avertir en cas de détection d'erreurs dans le journal des erreurs MySQL ou MariaDB. Pour en savoir plus sur la surveillance du journal des requêtes lentes et du journal des erreurs en créant un CloudWatch tableau de bord et en utilisant CloudWatch Logs Insights, consultez le billet de blog [Création d'un tableau de CloudWatch bord Amazon pour surveiller Amazon RDS et Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/creating-an-amazon-cloudwatch-dashboard-to-monitor-amazon-rds-and-amazon-aurora-mysql/). # Pistes d'audit La piste d'audit (ou journal d'audit) fournit un enregistrement chronologique pertinent pour la sécurité des événements survenus dans votre environnement. Compte AWS Il inclut des événements pour Amazon RDS, qui fournissent des preuves documentaires de la séquence d'activités ayant affecté votre base de données ou votre environnement cloud. Dans Amazon RDS for MySQL ou MariaDB, l'utilisation de la piste d'audit implique : + Surveillance du journal d'audit de l'instance de base de données + Surveillance des appels d'API Amazon RDS AWS CloudTrail Pour une instance de base de données Amazon RDS, les objectifs de l'audit sont généralement les suivants : + Faciliter la responsabilisation dans les domaines suivants : + Modifications effectuées sur le paramètre ou la configuration de sécurité + Actions effectuées dans un schéma, une table ou une ligne de base de données, ou actions affectant un contenu spécifique + Détection et investigation des intrusions + Détection et investigation des activités suspectes + Détection des problèmes d'autorisation ; par exemple, pour identifier les violations des droits d'accès par des utilisateurs réguliers ou privilégiés La piste d'audit de base de données tente de répondre à ces questions typiques : *qui a consulté ou modifié les données sensibles de votre base de données ? Quand est-ce que cela s'est produit ? D'où un utilisateur spécifique a-t-il accédé aux données ? Les utilisateurs privilégiés ont-ils abusé de leurs droits d'accès illimités ?* MySQL et MariaDB implémentent la fonctionnalité de journal d'audit des instances de base de données à l'aide du plugin d'audit MariaDB. Ce plugin enregistre les activités de la base de données, telles que la connexion des utilisateurs à la base de données et les requêtes exécutées sur la base de données. L'enregistrement de l'activité de la base de données est stocké dans un fichier journal. Pour accéder au journal d'audit, l'instance de base de données doit utiliser un groupe d'options personnalisé avec l'option `MARIADB_AUDIT_PLUGIN`. Pour plus d'informations, consultez la prise en [charge du plug-in d'audit MariaDB pour MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.Options.AuditPlugin.html) dans la documentation Amazon RDS. Les enregistrements du journal d'audit sont stockés dans un format spécifique, tel que défini par le plugin. Vous trouverez plus de détails sur le format du journal d'audit dans la documentation du [serveur MariaDB](https://mariadb.com/kb/en/mariadb-audit-plugin-log-format/). La piste AWS Cloud d'audit de votre AWS compte est fournie par le [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)service. CloudTrail capture les appels d'API pour Amazon RDS sous forme d'événements. Toutes les actions Amazon RDS sont enregistrées. CloudTrail fournit un enregistrement des actions effectuées dans Amazon RDS par un utilisateur, un rôle ou un autre AWS service. Les événements incluent les actions effectuées dans la console de AWS gestion AWS CLI, AWS SDKs et APIs. ## Exemple Dans un scénario d'audit classique, vous devrez peut-être combiner les AWS CloudTrail traces avec le journal d'audit de la base de données et la surveillance des événements Amazon RDS. Par exemple, vous pouvez avoir un scénario dans lequel les paramètres de base de données de votre instance de base de données Amazon RDS (par exemple,`database-1`) ont été modifiés et votre tâche consiste à identifier qui a effectué la modification, ce qui a été modifié et quand le changement s'est produit. Pour accomplir cette tâche, procédez comme suit : 1. Répertoriez les événements Amazon RDS survenus dans l'instance de base de données `database-1` et déterminez s'il existe un événement dans la catégorie `configuration change` contenant le message`Finished updating DB parameter group`. ``` $ aws rds describe-events --source-identifier database-1 --source-type db-instance { "Events": [ { "SourceIdentifier": "database-1", "SourceType": "db-instance", "Message": "Finished updating DB parameter group", "EventCategories": [ "configuration change" ], "Date": "2022-12-01T09:22:40.413000+00:00", "SourceArn": "arn:aws:rds:eu-west-3:111122223333:db:database-1" } ] } ``` 1. Identifiez le groupe de paramètres de base de données utilisé par l'instance de base de données : ``` $ aws rds describe-db-instances --db-instance-identifier database-1 --query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups]' [ [ "database-1", "mariadb", [ { "DBParameterGroupName": "mariadb10-6-test", "ParameterApplyStatus": "pending-reboot" } ] ] ] ``` 1. [Utilisez le AWS CLI pour rechercher CloudTrail des événements](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events-cli.html) dans la région où `database-1` est déployé, pendant la période autour de l'événement Amazon RDS découvert à l'étape 1, et où`EventName=ModifyDBParameterGroup`. ``` $ aws cloudtrail --region eu-west-3 lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=ModifyDBParameterGroup --start-time "2022-12-01, 09:00 AM" --end-time "2022-12-01, 09:30 AM" { "eventVersion": "1.08", "userIdentity": { "accountId": "111122223333", "accessKeyId": "AKIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AIDACKCEVSQ6C2EXAMPLE", "arn": "arn:aws:iam::111122223333:role/Role1", "accountId": "111122223333", "userName": "User1" } } }, "eventTime": "2022-12-01T09:18:19Z", "eventSource": "rds.amazonaws.com", "eventName": "ModifyDBParameterGroup", "awsRegion": "eu-west-3", "sourceIPAddress": "AWS Internal", "userAgent": "AWS Internal", "requestParameters": { "parameters": [ { "isModifiable": false, "applyMethod": "pending-reboot", "parameterName": "innodb_log_buffer_size", "parameterValue": "8388612" }, { "isModifiable": false, "applyMethod": "pending-reboot", "parameterName": "innodb_write_io_threads", "parameterValue": "8" } ], "dBParameterGroupName": "mariadb10-6-test" }, "responseElements": { "dBParameterGroupName": "mariadb10-6-test" }, "requestID": "fdf19353-de72-4d3d-bf29-751f375b6378", "eventID": "0bba7484-0e46-4e71-93a8-bd01ca8386fe", "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "111122223333", "eventCategory": "Management", "sessionCredentialFromConsole": "true" } ``` L' CloudTrail événement révèle que `User1` le rôle `Role1` du AWS compte 111122223333 a modifié le groupe `mariadb10-6-test` de paramètres de base de données utilisé par l'instance de base de données sur. `database-1` `2022-12-01 at 09:18:19 h` Deux paramètres ont été modifiés et définis sur les valeurs suivantes : + `innodb_log_buffer_size = 8388612` + `innodb_write_io_threads = 8` ## Fonctionnalités supplémentaires CloudTrail et CloudWatch journaux Vous pouvez résoudre les incidents opérationnels et de sécurité survenus au cours des 90 derniers jours en consultant **l'historique des événements** sur la CloudTrail console. Pour prolonger la période de rétention et tirer parti des fonctionnalités de requête supplémentaires, vous pouvez utiliser [AWS CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html). Avec AWS CloudTrail Lake, vous pouvez conserver les données d'événements dans un magasin de données d'événements pendant sept ans au maximum. **En outre, le service prend en charge les requêtes SQL complexes qui offrent une vue plus approfondie et plus personnalisable des événements que les vues fournies par de simples recherches de valeurs-clés dans l'historique des événements.** Pour surveiller vos pistes d'audit, définir des alarmes et recevoir des notifications lorsqu'une activité spécifique se produit, vous devez [configurer CloudTrail pour envoyer ses enregistrements de suivi à CloudWatch Logs](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/monitor-cloudtrail-log-files-with-cloudwatch-logs.html). Une fois que les enregistrements de suivi sont stockés sous forme de CloudWatch journaux, vous pouvez définir des filtres métriques pour évaluer les événements du journal en fonction des termes, des phrases ou des valeurs, et attribuer des métriques aux filtres métriques. En outre, vous pouvez créer des CloudWatch alarmes générées en fonction des seuils et des périodes que vous spécifiez. Par exemple, vous pouvez configurer des alarmes qui envoient des notifications aux équipes responsables, afin qu'elles puissent prendre les mesures appropriées. Vous pouvez également configurer CloudWatch pour exécuter automatiquement une action en réponse à une alarme.