HeatlhEventの通知を一つのアカウントへ集約する

Posted at 2024-10-21

概要

複数のAWSアカウントで発生したHealthイベントを一つのアカウントで確認できるようにしたい
上記要件を実現するために、EventBridgeのクロスアカウント送受信を使用する
AWS Organizationを使用して複数アカウントを管理できる場合はもっと簡単に集約する方法があるが、諸事情によりメンバーアカウントの中だけで集約する必要があったため、今回の対応を実施

構成

集約するイベントを受信するアカウントをアカウントA、イベントを送信するアカウントをアカウントBとする
各アカウントでイベントを補足したいリージョンすべてにEventBridgeルールを設定する
- 今回は東京リージョンとバージニア北部リージョンで構成
イベントをユーザに通知する手段としてUser Notificaionsを採択。Amazon SNSを使うことも可能だが、可読性の高いHTMLメールで送信されるため、こちらを選択した

設定手順

アカウントA

アカウントAのイベントバスへ配信されたイベントを処理するための設定を行う

User Notificaionsの設定

通知チャネルの作成

User Notificationsの画面から「配信チャネル」→「Eメールの追加」をクリック
「受信者」に通史を送信するメールアドレス、「名前」に対象を識別するための名前を入力
「Eメールの追加」をクリック
検証用のメールが送信されるので、メール本文内の「Verify Email」をクリックして検証を済ませる

通知設定の作成

画面右上「QuickSetup」にて「Health」を選択
「通知設定を作成」をクリック
「リージョン」に「US East(N. Virginia)」と「Asia Pasific(Tokyo)」を選択する
「Eメール（オプション）」に前工程で作成した通知チャネルを設定する
「通知設定を作成する」をクリック

通知設定を作成することで、自動でHealthイベントを処理するためのEventBrigdeルールが各リージョンに作成される。今回の場合は、東京リージョンとバージニア北部リージョンの計2つ作成される。

イベントバスの設定

EventBridgeの「イベントバス」から「default」をクリック
「許可」タブから「アクセス許可」をクリック

「リソースベースのポリシー」のテキストボックスへ以下のポリシーを設定する（バージニア北部の場合）

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowPutEventsFromSpecificAccount",
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::<アカウントBのID>:root"
    },
    "Action": "events:PutEvents",
    "Resource": "arn:aws:events:us-east-1:<アカウントAのID>:event-bus/default"
  }]
}

「更新」をクリックする

アカウントB

アカウントBのイベントバスへ配信されたイベントをアカウントAのイベントバスへ転送するための設定を行う

IAMロールの作成

アカウントAへイベントを配信するための権限を付与するためのIAMロールを作成する。手順は割愛するが、使用したポリシードキュメントは以下の通り。

信頼関係ポリシー

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

IAMポリシー

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "events:PutEvents",
      "Resource": "arn:aws:events:*:<アカウントAのID>:event-bus/default"
    }
  ]
}

EventBridgeルールの作成

東京リージョン

EventBridgeの画面から「ルールを作成」をクリック
ステップ１：任意の名前を入力して、「次へ」をクリック
ステップ２：「イベントパターン」へ以下のパターンを設定して「次へ」をクリック
```
{
  "source": ["aws.health"],
  "detail-type": ["AWS Health Event"]
}
```
ステップ３：「ターゲット1」へ以下のパラメータを入力する
- ターゲットタイプ：EventBrigdeイベントバス、「別のアカウントまたはリージョンのイベントバス」
- ターゲットとしてのイベントバス：アカウントAの東京リージョンのイベントバスのARN
- 実行ロール：前工程で作成したIAMロールを指定
ステップ４：タグを設定
ステップ５：「ルールの作成」をクリック

バージニア北部リージョン

東京リージョンと同様の手順でルールを作成する

同じリソースを繰り返し作成する形になるので、工数・作業ミスの観点からこの辺はTerraformなどで作成したほうがベターです

動作確認

ここまでAWSのHealthイベントを扱うためのリソースを作成・設定してきましたが、実は動作確認のためにテスト用のHealthイベントを意図的に発生させることができません。従って、今回は一緒にGuardDutyのFindingsを検出した時のイベントルールを追加し、こちらが正しく集約できるかを確認します。

アカウントAの追加設定

User NotificaionsにGuardDuty Findingsの設定を追加します。以下のEventBrigdeルールが生成されていればOKです。

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"]
}

アカウントBの追加設定

Healthイベントの設定と同様の手順で、GuardDutyの設定を追加します。アカウントAと同様のGuardDuty用のイベントパターンを設定したルールを作成します。

アカウントAの動作確認

アカウントAのCloudShellを起動し、以下のコマンドを実行します。実行後、EventBridgeがイベントを検出するまで、5～10分ほど掛かるのでしばらく待ちます。

実行するコマンド例：

aws guardduty create-sample-findings \
--detector-id $(aws guardduty list-detectors --query 'DetectorIds' --output text) \
--finding-types Policy:S3/AccountBlockPublicAccessDisabled --region <対象リージョン>