

Avis de fin de support : le 31 mars 2027, le support d'Amazon AWS WorkMail prendra fin. Après le 31 mars 2027, vous ne pourrez plus accéder à la WorkMail console Amazon ni aux WorkMail ressources Amazon. Pour plus d'informations, consultez la page [de WorkMail fin de support d'Amazon](https://docs.aws.amazon.com/workmail/latest/adminguide/workmail-end-of-support.html). 

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.

# Activation de l'enregistrement des événements par e-mail
<a name="tracking"></a>

Vous activez la journalisation des événements par e-mail dans la WorkMail console Amazon afin de suivre les e-mails de votre organisation. La journalisation des événements par e-mail utilise un rôle Gestion des identités et des accès AWS lié à un service (SLR) pour autoriser la publication des journaux des événements par e-mail sur Amazon. CloudWatch Pour plus d'informations sur les rôles liés aux services IAM, consultez. [Utilisation de rôles liés à un service pour Amazon WorkMail](using-service-linked-roles.md)

Dans les journaux CloudWatch d'événements, vous pouvez utiliser des outils CloudWatch de recherche et des indicateurs pour suivre les messages et résoudre les problèmes liés aux e-mails. Pour plus d'informations sur les journaux d'événements auxquels Amazon WorkMail envoie CloudWatch, consultez[Surveillance des journaux d'événements WorkMail liés aux e-mails d'Amazon](cw-events.md). Pour plus d'informations sur CloudWatch les journaux, consultez le [guide de l'utilisateur Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/).

**Topics**
+ [Activation de la journalisation des événements de messagerie](#enable-tracking)
+ [Création d'un groupe de journaux personnalisé et d'un rôle IAM pour la journalisation des événements par e-mail](#custom-tracking-role)
+ [Désactivation de la journalisation des événements de messagerie](#turn-off-tracking)
+ [Prévention du cas de figure de l’adjoint désorienté entre services](#cross-service-confused-deputy-prevention)

## Activation de la journalisation des événements de messagerie
<a name="enable-tracking"></a>

Voici ce qui se produit lorsque vous activez la journalisation des événements par e-mail à l'aide des paramètres par défaut, Amazon WorkMail :
+ Crée un rôle Gestion des identités et des accès AWS lié à un service —. `AmazonWorkMailEvents`
+ Crée un groupe de CloudWatch journaux —`/aws/workmail/emailevents/organization-alias`.
+ Définit la durée de conservation des CloudWatch journaux à 30 jours.

**Pour activer la journalisation des événements de messagerie**

1. Ouvrez la WorkMail console Amazon à l'adresse [https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/).

   Si nécessaire, modifiez la AWS région. Dans la barre en haut de la fenêtre de console, ouvrez la liste **Sélectionnez une région** et choisissez une région. Pour plus d'informations, consultez [Régions et points de terminaison ](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html) dans le *Référence générale d'Amazon Web Services*.

1. Dans le volet de navigation, choisissez **Organizations**, puis le nom de votre organisation.

1. Dans le volet de navigation, sélectionnez **Paramètres de journalisation**.

1. Choisissez l'onglet **Paramètres du journal du flux de courrier électronique**. 

1. Dans la section **Paramètres du journal du flux de courrier électronique**, choisissez **Modifier**.

1. Déplacez le curseur **Activer les événements de messagerie** **sur la position Activée**.

1. Effectuez l’une des actions suivantes :
   + (Recommandé) Choisissez **Utiliser les paramètres par défaut**.
   + (Facultatif) **Effacez les paramètres Utiliser par défaut** et sélectionnez un **groupe de journaux de destination** et un **rôle IAM dans** les listes qui apparaissent.
**Note**  
Choisissez cette option uniquement si vous avez déjà créé un groupe de journaux et un rôle IAM personnalisé à l'aide du AWS CLI. Pour de plus amples informations, veuillez consulter [Création d'un groupe de journaux personnalisé et d'un rôle IAM pour la journalisation des événements par e-mail](#custom-tracking-role).

1. Sélectionnez **J'autorise Amazon WorkMail à publier les journaux sur mon compte en utilisant cette configuration**.

1. Choisissez **Enregistrer**.

## Création d'un groupe de journaux personnalisé et d'un rôle IAM pour la journalisation des événements par e-mail
<a name="custom-tracking-role"></a>

Nous vous recommandons d'utiliser les paramètres par défaut lorsque vous activez la journalisation des événements par e-mail pour Amazon WorkMail. Si vous avez besoin d'une configuration de surveillance personnalisée, vous pouvez utiliser le AWS CLI pour créer un groupe de journaux dédié et un rôle IAM personnalisé pour la journalisation des événements de courrier électronique.

**Pour créer un groupe de journaux et un rôle IAM personnalisés pour la journalisation des événements par e-mail**

1. Utilisez la AWS CLI commande suivante pour créer un groupe de journaux dans la même AWS région que votre WorkMail organisation Amazon. Pour plus d’informations, consultez [create-log-group](https://docs.aws.amazon.com/cli/latest/reference/logs/create-log-group.html) dans la *Référence des commandes de l’AWS CLI *.

   ```
   aws –-region us-east-1 logs create-log-group --log-group-name workmail-monitoring
   ```

1. Créez un fichier contenant la stratégie suivante :

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "Service": "events.workmail.amazonaws.com"
         },
         "Action": "sts:AssumeRole"
       }
     ]
   }
   ```

------

1. Utilisez la AWS CLI commande suivante pour créer un rôle IAM et joindre ce fichier en tant que document de politique de rôle. Pour plus d'informations, consultez [create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html) dans la *Référence des commandes de l'AWS CLI *.

   ```
   aws iam create-role --role-name workmail-monitoring-role --assume-role-policy-document file://trustpolicyforworkmail.json
   ```
**Note**  
Si vous êtes un utilisateur de politiques `WorkMailFullAccess` gérées, vous devez inclure le terme `workmail` dans le nom du rôle. Cette stratégie gérée vous permet uniquement de configurer la journalisation des événements de messagerie à l'aide de rôles dont le nom contient `workmail`. Pour plus d'informations, consultez la section [Octroi à un utilisateur des autorisations lui permettant de transmettre un rôle à un AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html) dans le *Guide de l'utilisateur IAM*.

1. Créez un fichier contenant la politique pour le rôle IAM que vous avez créée à l'étape précédente. Au minimum, la stratégie doit accorder à ce rôle les autorisations pour créer des flux de journaux et insérer des événements de journal dans le groupe de journaux que vous avez créé à l'étape 1.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "logs:CreateLogStream",
                   "logs:PutLogEvents"
               ],
               "Resource": "arn:aws:logs:us-east-1:111122223333:log-group:example-log-group*"
           }
       ]
   }
   ```

------

1. Utilisez la AWS CLI commande suivante pour associer le fichier de politique au rôle IAM. Pour plus d’informations, consultez [put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html) dans la *Référence des commandes de l’AWS CLI *.

   ```
   aws iam put-role-policy --role-name workmail-monitoring-role --policy-name workmail-permissions --policy-document file://rolepolicy.json
   ```

## Désactivation de la journalisation des événements de messagerie
<a name="turn-off-tracking"></a>

Désactivez la journalisation des événements par e-mail depuis la WorkMail console Amazon. Si vous n'avez plus besoin d'utiliser la journalisation des événements par e-mail, nous vous recommandons de supprimer également le groupe de CloudWatch journaux et le rôle lié au service associés. Pour de plus amples informations, veuillez consulter [Supprimer un rôle lié à un service pour Amazon WorkMail](using-service-linked-roles.md#delete-slr).

**Pour désactiver la journalisation des événements de messagerie**

1. Ouvrez la WorkMail console Amazon à l'adresse [https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/).

   Si nécessaire, modifiez la AWS région. Dans la barre en haut de la fenêtre de console, ouvrez la liste **Sélectionnez une région** et choisissez une région. Pour plus d'informations, consultez [Régions et points de terminaison ](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html) dans le *Référence générale d'Amazon Web Services*.

1. Dans le volet de navigation, choisissez **Organizations**, puis le nom de votre organisation.

1. Dans le panneau de navigation, choisissez **Surveillance**.

1. Dans la section **Paramètres du journal**, choisissez **Modifier**.

1. Déplacez le curseur **Activer les événements de messagerie** sur la position Off.

1. Choisissez **Enregistrer**.

## Prévention du cas de figure de l’adjoint désorienté entre services
<a name="cross-service-confused-deputy-prevention"></a>

Le problème de député confus est un problème de sécurité dans lequel une entité qui n’est pas autorisée à effectuer une action peut contraindre une entité plus privilégiée à le faire. En AWS, l'usurpation d'identité interservices peut entraîner la confusion des adjoints. L’usurpation d’identité entre services peut se produire lorsqu’un service (le *service appelant*) appelle un autre service (le *service appelé*). 

Le service d'appel peut être manipulé pour utiliser ses autorisations afin d'agir sur les ressources d'un autre client auquel il n'aurait pas été autorisé à accéder autrement. 

 Pour éviter cela, AWS fournit des outils qui vous aident à protéger vos données pour tous les services auprès des principaux fournisseurs de services qui ont obtenu l'accès aux ressources de votre compte. 

Nous recommandons d'utiliser les clés de contexte de condition [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)globale [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)et les clés de contexte dans les politiques de ressources afin de limiter les autorisations accordées par CloudWatch Logs et Amazon S3 aux services qui génèrent des journaux. Si vous utilisez les deux clés contextuelles de condition globale, les valeurs doivent utiliser le même identifiant de compte lorsqu'elles sont utilisées dans la même déclaration de politique.

Les valeurs de `aws:SourceArn` doivent être celles ARNs des sources de diffusion qui génèrent des journaux.

Le moyen le plus efficace de se protéger contre le problème de député confus consiste à utiliser la clé de contexte de condition globale `aws:SourceArn` avec l’ARN complet de la ressource. Si vous ne connaissez pas l'ARN complet de la ressource ou si vous spécifiez plusieurs ressources, utilisez la clé de contexte de condition globale `aws:SourceArn` avec des caractères génériques (`*`) pour les parties inconnues de l'ARN.