E メールイベントのログ記録の有効化 - Amazon WorkMail

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

E メールイベントのログ記録の有効化

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

CloudWatch イベントログでは、CloudWatch 検索ツールとメトリクスを使用してメッセージを追跡し、E メールの問題をトラブルシューティングできます。Amazon WorkMail が CloudWatch に送信するログイベントの詳細については、Amazon WorkMail E メールイベントログのモニタリング を参照してください。CloudWatch Logs の詳細については、Amazon CloudWatch Logs ユーザーガイドを参照してください。

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

デフォルト設定 Amazon WorkMail を使用して E メールイベントのログ記録を有効にすると、次のようになります。

  • 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/) を開きます。

    必要に応じて、 AWS リージョンを変更します。コンソールウィンドウの上部にあるバーで、[リージョンを選択] リストを開き、リージョンを選択します。詳細については、「Amazon Web Services 全般のリファレンス」の「リージョンとエンドポイント」を参照してください。

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

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

  4. E メールフローログ設定タブを選択します。

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

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

  7. 次のいずれかを行います:

    • (推奨)「デフォルト設定を使う」を選択します。

    • (オプション) [デフォルト設定を使用する] のチェックボックスをオフにし、[送信先ロググループ][IAM ロール] を選択します。

      注記

      AWS CLIを使用してロググループと カスタム IAMロールをすでに作成している場合にのみ、このオプションを選択してください。詳細については、「E メールイベントログ記録用のカスタムのロググループと IAM ロールの作成」を参照してください。

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

  9. [Save] を選択します。

E メールイベントログ記録用のカスタムのロググループと IAM ロールの作成

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

E メールイベントログ記録用のカスタムのロググループと IAM ロールを作成するには
  1. 次の AWS CLI コマンドを使用して、Amazon WorkMail 組織と同じ AWS リージョンにロググループを作成します。詳細については、AWS CLI コマンドリファレンスcreate-log-group を参照してください。

    aws –-region us-east-1 logs create-log-group --log-group-name workmail-monitoring
  2. 以下のポリシーを含むファイルを作成します。

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "events.workmail.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
  3. 次の AWS CLI コマンドを使用して IAM ロールを作成し、このファイルをロールポリシードキュメントとしてアタッチします。詳細については、「AWS CLI コマンドリファレンス」の create-role を参照してください。

    aws iam create-role --role-name workmail-monitoring-role --assume-role-policy-document file://trustpolicyforworkmail.json
    注記

    WorkMailFullAccess マネージドポリシーユーザーの場合は、ロール名workmailに という用語を含める必要があります。この管理ポリシーでは、名前に workmail を含むロールを使用して E メールイベントログ記録を設定することのみが許可されます。詳細については、「IAM ユーザーガイド」の「 AWS サービスにロールを渡すアクセス許可をユーザーに付与する」を参照してください。

  4. 前のステップで作成した IAM ロールのポリシーを含むファイルを作成します。最低でも、このポリシーではそのロールに、ログストリームを作成するためのアクセス許可と、ステップ 1 で作成したロググループにログイベントを追加するためのアクセス許可を付与する必要があります。

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "arn:aws:logs:us-east-1:111122223333:log-group:workmail-monitoring*" } ] }
  5. 次の AWS CLI コマンドを使用して、ポリシーファイルを IAM ロールにアタッチします。詳細については、AWS CLI コマンドリファレンスput-key-policy を参照してください。

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

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

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

E メールイベントのログ記録を無効にするには
  1. Amazon WorkMail コンソール (https://console.aws.amazon.com/workmail/) を開きます。

    必要に応じて、 AWS リージョンを変更します。コンソールウィンドウの上部にあるバーで、[リージョンを選択] リストを開き、リージョンを選択します。詳細については、「Amazon Web Services 全般のリファレンス」の「リージョンとエンドポイント」を参照してください。

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

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

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

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

  6. [Save] を選択します。

サービス間での不分別な代理処理の防止

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

呼び出し元のサービスは、そのアクセス許可を使用して、本来はアクセス許可を持たない別の顧客のリソースで動作するように操作できます。

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

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

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

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