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.
# Audit des événements Amazon DocumentDB
Avec Amazon DocumentDB (compatible avec MongoDB), vous pouvez auditer les événements qui ont été effectués dans votre cluster. Les exemples d'événements enregistrés incluent les tentatives d'authentification réussies et celles ayant échoué, la suppression d'une collection dans une base de données ou la création d'un index. Par défaut, l'audit est désactivé sur Amazon DocumentDB et nécessite que vous acceptiez d'utiliser cette fonctionnalité.
Lorsque l'audit est activé, Amazon DocumentDB enregistre les événements relatifs au langage de définition des données (DDL), au langage de manipulation des données (DML), à l'authentification, à l'autorisation et aux événements de gestion des utilisateurs dans Amazon Logs. CloudWatch Lorsque l'audit est activé, Amazon DocumentDB exporte les enregistrements d'audit de votre cluster (documents JSON) vers Amazon CloudWatch Logs. Vous pouvez utiliser Amazon CloudWatch Logs pour analyser, surveiller et archiver vos événements d'audit Amazon DocumentDB.
Bien qu'Amazon DocumentDB ne facture aucun coût supplémentaire pour activer l'audit, des tarifs standard vous sont facturés pour l'utilisation des CloudWatch journaux. Pour plus d'informations sur la tarification des CloudWatch journaux, consultez [ CloudWatch les tarifs Amazon](https://aws.amazon.com/cloudwatch/pricing/).
La fonctionnalité d'audit Amazon DocumentDB est nettement différente de l'utilisation des ressources de service surveillée avec. AWS CloudTrail CloudTrail enregistre les opérations effectuées avec le AWS Command Line Interface (AWS CLI) ou AWS Management Console sur des ressources telles que des clusters, des instances, des groupes de paramètres et des instantanés. L'audit des ressources CloudTrail est activé par défaut et ne peut pas être désactivé. La fonctionnalité d'audit Amazon DocumentDB est une fonctionnalité optionnelle. Elle enregistre les opérations qui ont lieu au sein de votre cluster sur des objets, par exemple sur des bases de données, des collections, des index et des utilisateurs.
**Topics**
+ [Événements pris en charge](#auditing-events)
+ [Permettre l'audit](#event-auditing-enabling-auditing)
+ [Désactivation de l'audit](#event-auditing-disabling-auditing)
+ [Accès à vos événements d'audit](#event-auditing-accessing)
+ [Filtrage des événements d'audit DML](#filtering-dml-events)
## Événements pris en charge
L'audit Amazon DocumentDB prend en charge les catégories d'événements suivantes :
+ **Langage de définition des données (DDL)** : inclut les opérations de gestion de base de données, les connexions, la gestion des utilisateurs et les autorisations.
+ **Événements de lecture du langage de manipulation des données (lectures DML) :** incluent `find()` les différents opérateurs d'agrégation, les opérateurs arithmétiques, les opérateurs booléens et les autres opérateurs de requête de lecture.
+ **Événements d'écriture du langage de manipulation de données (écritures DML) :** inclusions `insert(), update(), delete(),` et opérateurs `bulkWrite()`
Les types d'événements sont les suivants.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/documentdb/latest/developerguide/event-auditing.html)
**Note**
Les valeurs du champ de paramètre du document d'événement DML sont limitées à 1 Ko. Amazon DocumentDB tronque la valeur si elle dépasse 1 Ko.
**Note**
Les événements de suppression TTL ne sont pas audités pour le moment.
## Permettre l'audit
L'activation de l'audit sur un cluster est un processus en deux étapes. Assurez-vous que les deux étapes sont terminées, sinon les journaux d'audit ne seront pas envoyés à CloudWatch Logs.
### Étape 1. Activer le paramètre de cluster audit\$1logs
Pour activer l'audit, vous devez modifier le `audit_logs` paramètre dans le groupe de paramètres. `audit_logs`est une liste d'événements à consigner, séparés par des virgules. Les événements doivent être spécifiés en minuscules et il ne doit y avoir aucun espace entre les éléments de la liste.
Vous pouvez définir les valeurs suivantes pour le groupe de paramètres :
| Value | Description |
| --- | --- |
| ddl | Cette configuration permettra d'auditer les événements DDL tels que CreateDatabase, DropDatabase, CreateCollection, DropCollection, CreateIndex, DropIndex, AuthCheck, authenticate, CreateUser, DropUser, User, User, UpdateUser et grantRolesTo revokeRolesFrom dropAllUsers FromDatabase |
| dml\$1read | Cette configuration permettra d'auditer les événements de lecture DML tels que find, sort count, distinct, group, projecta, unwind, GeoNear, GeoIntersects, GeoWithin et d'autres opérateurs de requête de lecture MongoDB. |
| dml\$1write | Cette configuration permettra d'auditer les événements d'écriture DML tels que insert (), update (), delete () et BulkWrite () |
| all | Cette configuration permettra d'auditer les événements de votre base de données, tels que les requêtes de lecture, les requêtes d'écriture, les actions de base de données et les actions d'administrateur. |
| none | Cette configuration désactivera l'audit |
| enabled (hérité) | Il s'agit d'un ancien paramètre équivalent à « ddl ». Cette configuration permettra d'auditer les événements DDL tels que CreateDatabase, DropDatabase, CreateCollection, DropCollection, CreateIndex, DropIndex, AuthCheck, authenticate, CreateUser, DropUser, User, User, User, UpdateUser et. grantRolesTo revokeRolesFrom dropAllUsers FromDatabase Nous vous déconseillons d'utiliser ce paramètre car il s'agit d'un ancien paramètre. |
| disabled (héritage) | Il s'agit d'un ancien paramètre équivalent à « aucun ». Nous vous déconseillons d'utiliser ce paramètre car il s'agit d'un ancien paramètre. |
**Note**
La valeur par défaut du paramètre de cluster audit\$1logs est `none` (legacy "`disabled`«).
Vous pouvez également utiliser les valeurs mentionnées ci-dessus dans des combinaisons.
| Value | Description |
| --- | --- |
| ddl, dml\$1read | Cette configuration permettra d'auditer les événements DDL et les événements de lecture DML. |
| ddl, dml\$1write | Cette configuration activera l'audit des événements DDL et de l'écriture DML. |
| dml\$1read, dml\$1write | Cette configuration permettra d'effectuer un audit pour tous les événements DML. |
**Note**
Vous ne pouvez pas modifier un groupe de paramètres par défaut.
Pour plus d’informations, consultez les ressources suivantes :
+ [Création de groupes de paramètres de cluster Amazon DocumentDB](cluster_parameter_groups-create.md)
Après avoir créé un groupe de paramètres, modifiez-le en remplaçant la valeur du paramètre `audit_logs` par `all`.
+ [Modification des groupes de paramètres du cluster Amazon DocumentDB](cluster_parameter_groups-modify.md)
### Étape 2. Activer l'exportation d'Amazon CloudWatch Logs
Lorsque la valeur du paramètre de `audit_logs` cluster est`enabled`,, ou `ddl` `dml_read``dml_write`, vous devez également activer Amazon DocumentDB pour exporter les journaux vers Amazon. CloudWatch Si vous omettez l'une de ces étapes, les journaux d'audit ne seront pas envoyés à CloudWatch.
Lorsque vous créez un cluster, effectuez un point-in-time-restore instantané ou restaurez un instantané, vous pouvez activer CloudWatch les journaux en suivant ces étapes.
------
#### [ Using the AWS Management Console ]
Pour permettre à Amazon DocumentDB d'exporter des journaux à CloudWatch l'aide de la console, consultez les rubriques suivantes :
+ **Lors de la création d'un cluster** — Dans[Création d'un cluster et d'une instance principale à l'aide du AWS Management Console](db-cluster-create.md#db-cluster-create-con), voir **Créer un cluster : configurations supplémentaires** (étape 5, **Exportations du journal**)
+ **Lors de la modification d'un cluster existant** : [Modification d'un cluster Amazon DocumentDB](db-cluster-modify.md)
+ **Lorsque vous effectuez une restauration instantanée d'un cluster** : [Restauration à partir d'un instantané de cluster](backup_restore-restore_from_snapshot.md)
+ **Lorsque vous effectuez une point-in-time restauration** : [Restaurer à un point dans le temps](backup_restore-point_in_time_recovery.md)
------
#### [ Using the AWS CLI ]
**Pour activer les journaux d'audit lors de la création d'un cluster**
Le code suivant crée le cluster `sample-cluster` et active les journaux CloudWatch d'audit.
**Example**
Pour Linux, macOS ou Unix :
```
aws docdb create-db-cluster \
--db-cluster-identifier sample-cluster \
--port 27017 \
--engine docdb \
--master-username master-username \
--master-user-password password \
--db-subnet-group-name default \
--enable-cloudwatch-logs-exports audit
```
Pour Windows :
```
aws docdb create-db-cluster ^
--db-cluster-identifier sample-cluster ^
--port 27017 ^
--engine docdb ^
--master-username master-username ^
--master-user-password password ^
--db-subnet-group-name default ^
--enable-cloudwatch-logs-exports audit
```
**Pour activer les journaux d'audit lors de la modification d'un cluster existant**
Le code suivant modifie le cluster `sample-cluster` et active les journaux CloudWatch d'audit.
**Example**
Pour Linux, macOS ou Unix :
```
aws docdb modify-db-cluster \
--db-cluster-identifier sample-cluster \
--cloudwatch-logs-export-configuration '{"EnableLogTypes":["audit"]}'
```
Pour Windows :
```
aws docdb modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--cloudwatch-logs-export-configuration '{"EnableLogTypes":["audit"]}'
```
Le résultat de ces opérations ressemble à ceci (format JSON).
```
{
"DBCluster": {
"HostedZoneId": "ZNKXH85TT8WVW",
"StorageEncrypted": false,
"DBClusterParameterGroup": "default.docdb4.0",
"MasterUsername": "",
"BackupRetentionPeriod": 1,
"Port": 27017,
"VpcSecurityGroups": [
{
"Status": "active",
"VpcSecurityGroupId": "sg-77186e0d"
}
],
"DBClusterArn": "arn:aws:rds:us-east-1:900083794985:cluster:sample-cluster",
"Status": "creating",
"Engine": "docdb",
"EngineVersion": "4.0.0",
"MultiAZ": false,
"AvailabilityZones": [
"us-east-1a",
"us-east-1c",
"us-east-1f"
],
"DBSubnetGroup": "default",
"DBClusterMembers": [],
"ReaderEndpoint": "sample-cluster.cluster-ro-corcjozrlsfc.us-east-1.docdb.amazonaws.com",
"EnabledCloudwatchLogsExports": [
"audit"
],
"PreferredMaintenanceWindow": "wed:03:08-wed:03:38",
"AssociatedRoles": [],
"ClusterCreateTime": "2019-02-13T16:35:04.756Z",
"DbClusterResourceId": "cluster-YOS52CUXGDTNKDQ7DH72I4LED4",
"Endpoint": "sample-cluster.cluster-corcjozrlsfc.us-east-1.docdb.amazonaws.com",
"PreferredBackupWindow": "07:16-07:46",
"DBClusterIdentifier": "sample-cluster"
}
}
```
------
## Désactivation de l'audit
Vous pouvez désactiver l'audit en désactivant l'exportation CloudWatch des journaux et en désactivant le `audit_logs` paramètre.
### Désactivation de l'exportation CloudWatch des journaux
Vous pouvez désactiver l'exportation des journaux d'audit à l'aide du AWS Management Console ou du AWS CLI.
------
#### [ Using the AWS Management Console ]
La procédure suivante utilise le AWS Management Console pour désactiver l'exportation des journaux vers Amazon DocumentDB vers. CloudWatch
**Pour désactiver les journaux d'audit**
1. [Connectez-vous à la AWS Management Console console Amazon DocumentDB et ouvrez-la à https://console.aws.amazon.com l'adresse /docdb.](https://console.aws.amazon.com/docdb)
1. Dans le panneau de navigation, choisissez **Clusters**. Choisissez ensuite le bouton à gauche du nom du cluster pour lequel vous souhaitez désactiver l'exportation des journaux.
1. Choisissez **Actions**, puis **Modify (Modifier)**.
1. Faites défiler jusqu'à la section **Log exports (Exportations de journaux)**, puis choisissez **Disabled (Désactivé)**.
1. Sélectionnez **Continuer**.
1. Vérifiez vos modifications, puis choisissez quand cette modification devra être appliquée à votre cluster.
+ **Appliquer pendant la fenêtre de maintenance planifiée suivante**
+ **Appliquer immédiatement**
1. Choisissez **Modifier le cluster**.
------
#### [ Using the AWS CLI ]
Le code suivant modifie le cluster `sample-cluster` et désactive les journaux CloudWatch d'audit.
**Example**
Pour Linux, macOS ou Unix :
```
aws docdb modify-db-cluster \
--db-cluster-identifier sample-cluster \
--cloudwatch-logs-export-configuration '{"DisableLogTypes":["audit"]}'
```
Pour Windows :
```
aws docdb modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--cloudwatch-logs-export-configuration '{"DisableLogTypes":["audit"]}'
```
La sortie de cette opération ressemble à ceci (format JSON).
```
{
"DBCluster": {
"DBClusterParameterGroup": "default.docdb4.0",
"HostedZoneId": "ZNKXH85TT8WVW",
"MasterUsername": "",
"Status": "available",
"Engine": "docdb",
"Port": 27017,
"AvailabilityZones": [
"us-east-1a",
"us-east-1c",
"us-east-1f"
],
"EarliestRestorableTime": "2019-02-13T16:35:50.387Z",
"DBSubnetGroup": "default",
"LatestRestorableTime": "2019-02-13T16:35:50.387Z",
"DBClusterArn": "arn:aws:rds:us-east-1:900083794985:cluster:sample-cluster2",
"Endpoint": "sample-cluster2.cluster-corcjozrlsfc.us-east-1.docdb.amazonaws.com",
"ReaderEndpoint": "sample-cluster2.cluster-ro-corcjozrlsfc.us-east-1.docdb.amazonaws.com",
"BackupRetentionPeriod": 1,
"EngineVersion": "4.0.0",
"MultiAZ": false,
"ClusterCreateTime": "2019-02-13T16:35:04.756Z",
"DBClusterIdentifier": "sample-cluster2",
"AssociatedRoles": [],
"PreferredBackupWindow": "07:16-07:46",
"DbClusterResourceId": "cluster-YOS52CUXGDTNKDQ7DH72I4LED4",
"StorageEncrypted": false,
"PreferredMaintenanceWindow": "wed:03:08-wed:03:38",
"DBClusterMembers": [],
"VpcSecurityGroups": [
{
"Status": "active",
"VpcSecurityGroupId": "sg-77186e0d"
}
]
}
}
```
------
### Désactivation du paramètre audit\$1logs
Pour désactiver le paramètre `audit_logs` de votre cluster, vous pouvez modifier ce dernier de façon à ce qu'il utilise un groupe de paramètres dans lequel la valeur du paramètre `audit_logs` est `disabled`. Vous pouvez également modifier la valeur du paramètre `audit_logs` dans le groupe de paramètres du cluster afin qu'elle soit `disabled`.
Pour plus d’informations, consultez les rubriques suivantes :
+ [Modification d'un cluster Amazon DocumentDB](db-cluster-modify.md)
+ [Modification des groupes de paramètres du cluster Amazon DocumentDB](cluster_parameter_groups-modify.md)
## Accès à vos événements d'audit
Suivez les étapes ci-dessous pour accéder à vos événements d'audit sur Amazon CloudWatch.
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Assurez-vous que vous vous trouvez dans la même région que votre cluster Amazon DocumentDB.
1. Dans le panneau de navigation, sélectionnez **Logs** (Journaux).
1. Pour rechercher les journaux d'audit de votre cluster, dans la liste, trouvez et choisissez **/aws/docdb/*yourClusterName*/audit**.
Les événements d'audit pour chacune de vos instances sont disponibles sous chacun des noms d'instance respectifs.
## Filtrage des événements d'audit DML
### Commencer à utiliser le filtrage d'audit DML
Les événements d'audit DML peuvent être filtrés avant d'être écrits sur Amazon CloudWatch. Pour utiliser cette fonctionnalité, le journal d'audit et la journalisation DML doivent être activés. Amazon DocumentDB prend en charge le filtrage sur`atype`,`command`, `user``namespace`, et. `auditAuthorizationSuccess`
**Note**
Les événements DDL ne sont pas filtrés.
Vous pouvez activer le filtrage d'audit à tout moment en spécifiant le filtre d'audit à l'aide des `auditAuthorizationSuccess` paramètres `setAuditConfig``filter`,, et de l'`db.adminCommand( { command } )`opération :
```
db.admin.runCommand(
{
setAuditConfig: 1,
filter:
{
//filter conditions
},
auditAuthorizationSuccess: true | false
}
)
```
Vous pouvez également récupérer les paramètres du filtre d'audit en exécutant la commande suivante :
```
db.admin.runCommand( { getAuditConfig: 1})
```
**Exigences en matière de sécurité**
Seule users/roles une base de données dotée d'une action privilégiée `auditConfigure` peut exécuter les commandes ci-dessus `admindb` lors de la définition ou de la liste des filtres d'audit DML. Vous pouvez soit utiliser l'un des rôles intégrés de [`clusterAdmin`,,`root`]`hostManager`, soit créer des rôles personnalisés dotés de `auditConfigure` privilèges. Voici un exemple d'utilisation de rôles existants avec le `auditConfigure` privilège et un exemple avec des rôles personnalisés.
Utilisateur doté d'un rôle intégré :
```
use admin
db.createUser(
{
user: "myClusterAdmin",
pwd: "password123",
roles: [ { role: "clusterAdmin", db: "admin" } ]
}
)
```
Utilisateur doté de rôles personnalisés :
```
use admin
db.createRole(
{
role: "myRole",
privileges: [
{ resource: { cluster: true }, actions: [ "auditConfigure" ] }
],
roles: []
}
)
db.createUser(
{
user: "myUser",
pwd: "myPassword",
roles: [ { role: "myRole", db: "admin" } ]
}
)
```
#### Cas d'utilisation du filtrage
**Exemple : filtrage des événements par commandes**
```
db.admin.runCommand(
{
setAuditConfig: 1,
filter: {
"$and": [
{
"param.command":
{
$in: [ "find","count", "insert", "delete", "update", "findandmodify" ]
}
}
]
},
auditAuthorizationSuccess: true
}
)
```
**Exemple : filtrage des événements par nom d'utilisateur**
Dans cet exemple, seul l'utilisateur « MyUser » sera enregistré :
```
db.admin.runCommand(
{
setAuditConfig: 1,
filter: {
"$and": [
{
"param.user":
{
$in: [ "myUser" ]
}
}
]},
auditAuthorizationSuccess: true})
```
**Exemple : filtrage par `atype`**
```
db.admin.runCommand(
{
setAuditConfig: 1,
filter: {atype: "authCheck"},
auditAuthorizationSuccess: true
})
```
**Note**
Tous les journaux DML ont un`authCheck`. `atype` Seul le DDL en a une autre. `atype` Si vous entrez une valeur autre que `authCheck` le`filter`, cela ne produira pas de connexion DML. CloudWatch
**Exemple : filtrage à l'aide de plusieurs filtres joints par des opérateurs**
```
db.admin.runCommand(
{
setAuditConfig: 1,
filter: {
"$and": [
{
"param.command":
{
$in: [ "find","count", "insert", "delete", "update", "findandmodify" ]
}
}
],
"$nor": [
{
"param.command":
{
$in: ["count", "insert", "delete", "update", "findandmodify" ]
}
}]
},
auditAuthorizationSuccess: true})
```
**Note**
Au niveau supérieur, uniquement `$and``$or`, et `$nor` sont pris en charge. Tous les autres opérateurs ne sont pas pris en charge et provoqueront une erreur.
**Exemple : filtrage par événements par `auditAuthorizationSuccess`**
Dans ce filtre, toutes les commandes ayant passé avec succès l'autorisation ne seront pas enregistrées :
```
db.admin.runCommand(
{
setAuditConfig: 1,
filter: {},
auditAuthorizationSuccess: false
}
)
```
**Exemple : filtrage avec `$in` et `$nin` conditions**
Lorsque vous utilisez à la fois in `$in` et`$nin`, la commande ne sera pas enregistrée car il y aura un « et » implicite entre les conditions. Dans cet exemple, regex bloquera la `find` commande afin que rien ne soit enregistré :
```
db.admin.runCommand(
{
setAuditConfig: 1,
filter: {
"$and": [
{
atype: "authCheck",
"param.command":
{
$in: [ "find", "insert", "delete", "update", "findandmodify" ],
$nin: ["count", "insert", "delete", "update", "findandmodify" ],
$not: /^^find.*/
}
},
],
"$or": [
{
"param.command":
{
$nin: ["count", "insert", "delete", "update", "findandmodify" ]
}
}]
},
auditAuthorizationSuccess: true})
```
**Exemple : filtrage par `namespace`**
```
db.admin.runCommand(
{
setAuditConfig: 1,
filter: {
"$and": [
{
"param.ns":
{
$in: [ "test.foo" ]
}
}
]},
auditAuthorizationSuccess: true})
```
**Exemple : réinitialisation du filtre par défaut**
La réinitialisation à la valeur par défaut signifie que chaque événement d'audit DML sera enregistré. Pour rétablir la valeur par défaut du filtrage, exécutez la commande suivante :
```
db.admin.runCommand(
{
setAuditConfig: 1,
filter: {},
auditAuthorizationSuccess: true
}
)
```