

サポート終了通知: 2027 年 3 月 31 日、 AWS は Amazon WorkMail のサポートを終了します。2027 年 3 月 31 日以降、Amazon WorkMail コンソールまたは Amazon WorkMail リソースにアクセスできなくなります。詳細については、[Amazon WorkMail のサポート終了](https://docs.aws.amazon.com/workmail/latest/adminguide/workmail-end-of-support.html)」を参照してください。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# E メールイベントログ記録の有効化
<a name="tracking"></a>

組織の電子メールメッセージを追跡するには、Amazon WorkMail コンソールで電子メールイベントのログ記録を有効にします。E メールイベントログ記録では、 AWS Identity and Access Management サービスにリンクされたロール (SLR) を使用して、E メールイベントログを Amazon CloudWatch に発行するアクセス許可を付与します。IAM サービスにリンクされたロールの詳細については、[Amazon WorkMail のサービスリンクロールの使用](using-service-linked-roles.md) を参照してください。

CloudWatch イベントログでは、CloudWatch 検索ツールとメトリクスを使用してメッセージを追跡し、E メールの問題をトラブルシューティングできます。Amazon WorkMail が CloudWatch に送信するログイベントの詳細については、[Amazon WorkMail E メールイベントログのモニタリング](cw-events.md) を参照してください。CloudWatch Logs の詳細については、[Amazon CloudWatch Logs ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/)を参照してください。

**Topics**
+ [E メールイベントログ記録をオンにする](#enable-tracking)
+ [E メールイベントログ記録用のカスタムのロググループと IAM ロールの作成](#custom-tracking-role)
+ [E メールイベントログ記録をオフにする](#turn-off-tracking)
+ [サービス間での不分別な代理処理の防止](#cross-service-confused-deputy-prevention)

## E メールイベントログ記録をオンにする
<a name="enable-tracking"></a>

デフォルト設定を使用して E メールイベントログ記録をオンにすると、Amazon WorkMail は以下を行います。
+  AWS Identity and Access Management サービスにリンクされたロールを作成します – `AmazonWorkMailEvents`。
+ CloudWatch Logs ロググループを作成する - `/aws/workmail/emailevents/organization-alias`。
+ CloudWatch ログ保持を 30 日間に設定する

**E メールイベントのログ記録をオンにするには**

1. Amazon WorkMail コンソール ([https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/)) を開きます。

   必要に応じて、 AWS リージョンを変更します。コンソールウィンドウの上部にあるバーで、**[リージョンを選択]** リストを開き、リージョンを選択します。詳細については、「Amazon Web Services 全般のリファレンス」の「[リージョンとエンドポイント](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)」を参照してください。

1. ナビゲーションペインで **[組織]** を選択し、組織の名前を選択します。

1. ナビゲーションペインで、**[ログ記録の設定]** を選択します。

1. **[E メールフローログの設定]** タブを選択します。

1. **[E メールフローログの設定]** セクションで、**[編集]** を選択します。

1. **[メールイベントを有効にする]** スライダーを**オン**の位置に移動します。

1. 次のいずれかを行います。
   + (推奨)「**デフォルト設定を使う**」を選択します。
   + (オプション) **[デフォルト設定を使用する]** のチェックボックスをオフにし、**[送信先ロググループ]** と **[IAM ロール]** を選択します。
**注記**  
 AWS CLIを使用してロググループと カスタム IAMロールをすでに作成している場合にのみ、このオプションを選択してください。詳細については、「[E メールイベントログ記録用のカスタムのロググループと IAM ロールの作成](#custom-tracking-role)」を参照してください。

1. **[この設定を使用して、Amazon WorkMail が自分のアカウントでログを発行することを承認しました]** を選択します。

1. **[保存]** を選択します。

## E メールイベントログ記録用のカスタムのロググループと IAM ロールの作成
<a name="custom-tracking-role"></a>

Amazon WorkMail の E メールイベントログ記録を有効にする場合は、デフォルト設定を使用することをお勧めします。カスタムモニタリング設定が必要な場合は、 を使用して AWS CLI 、E メールイベントログ記録用の専用ロググループとカスタム IAM ロールを作成できます。

**E メールイベントログ記録用のカスタムのロググループと IAM ロールを作成するには**

1. 次の AWS CLI コマンドを使用して、Amazon WorkMail 組織と同じ AWS リージョンにロググループを作成します。詳細については、*AWS CLI コマンドリファレンス*の [create-log-group](https://docs.aws.amazon.com/cli/latest/reference/logs/create-log-group.html) を参照してください。

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

1. 以下のポリシーを含むファイルを作成します。

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

****  

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

------

1. 次の AWS CLI コマンドを使用して IAM ロールを作成し、このファイルをロールポリシードキュメントとしてアタッチします。詳細については、「AWS CLI コマンドリファレンス**」の [create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html) を参照してください。

   ```
   aws iam create-role --role-name workmail-monitoring-role --assume-role-policy-document file://trustpolicyforworkmail.json
   ```
**注記**  
`WorkMailFullAccess` マネージドポリシーユーザーの場合は、ロール名に `workmail` という用語を含める必要があります。この管理ポリシーでは、名前に `workmail` を含むロールを使用して E メールイベントログ記録を設定することのみが許可されます。詳細については、*IAM ユーザーガイド*[の「 AWS サービスにロールを渡すアクセス許可をユーザーに付与](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html)する」を参照してください。

1. 前のステップで作成した IAM ロールのポリシーを含むファイルを作成します。最低でも、このポリシーではそのロールに、ログストリームを作成するためのアクセス許可と、ステップ 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. 次の AWS CLI コマンドを使用して、ポリシーファイルを IAM ロールにアタッチします。詳細については、*AWS CLI コマンドリファレンス*の [put-key-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html) を参照してください。

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

## E メールイベントログ記録をオフにする
<a name="turn-off-tracking"></a>

Amazon WorkMail コンソールから E メールイベントログ記録を無効にします。E メールイベントログを使用する必要がなくなった場合は、関連する CloudWatch ロググループとサービスリンクの役割も削除することをお勧めします。詳細については、「[Amazon WorkMail のサービスリンクロールの削除](using-service-linked-roles.md#delete-slr)」を参照してください。

**E メールイベントのログ記録を無効にするには**

1. Amazon WorkMail コンソール ([https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/)) を開きます。

   必要に応じて、 AWS リージョンを変更します。コンソールウィンドウの上部にあるバーで、**[リージョンを選択]** リストを開き、リージョンを選択します。詳細については、「Amazon Web Services 全般のリファレンス」の「[リージョンとエンドポイント](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)」を参照してください。

1. ナビゲーションペインで **[組織]** を選択し、組織の名前を選択します。

1. ナビゲーションペインで、[**モニタリング**] を選択します。

1. **[設定]** セクションで、**[編集]** を選択します。

1. **[メールイベントを有効化]** スライダーをオフの位置に移動します。

1. **[保存]** を選択します。

## サービス間での不分別な代理処理の防止
<a name="cross-service-confused-deputy-prevention"></a>

混乱した代理問題は、アクションを実行するためのアクセス許可を持たないエンティティが、より特権のあるエンティティにアクションの実行を強制できてしまう場合に生じる、セキュリティ上の問題です。では AWS、サービス間のなりすましにより、混乱した代理問題が発生する可能性があります。サービス間でのなりすましは、1 つのサービス (*呼び出し元サービス*) が、別のサービス (*呼び出し対象サービス*) を呼び出すときに発生する可能性があります。

呼び出し元サービスのアクセス許可は、本来アクセスが許可されていない別のユーザーのリソースにアクセスするために操作されて利用される可能性があります。

 これを防ぐために、 は、アカウント内のリソースへのアクセス権が付与されたサービスプリンシパルを持つすべてのサービスのデータを保護するのに役立つツール AWS を提供します。

リソースポリシー内では [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) および [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) のグローバル条件コンテキストキーを使用して、ログを生成しているサービスに対して CloudWatch Logs と Amazon S3 から付与されるアクセス許可を制限することをお勧めします。両方のグローバル条件コンテキストキーを使用する場合、同じポリシーステートメント内では、同じアカウント ID を値として使用する必要があります。

`aws:SourceArn` の値は、ログを生成している配信リソースの ARN でなければなりません。

混乱した代理問題から保護するための最も効果的な方法は、リソースの完全な ARN を指定して `aws:SourceArn` グローバル条件コンテキストキーを使用することです。リソースの ARN 全体が不明または複数のリソースを指定する場合、ARN の未知部分にワイルドカード `*`が付いた `aws:SourceArn` グローバルコンテキスト条件キー を使用します。