この記事は約11分で読めます。
カスタマーサクセス部 岡部です。
本記事では Organization 設計を含め、セキュリティ対策の一環として設定する必要がある通知設定について記載します。
今までの課題
AWS では Security Hub をはじめ、Inspector や GuardDuty、Macie など複数のセキュリティサービスがあります。
セキュリティサービスを有効化することがセキュリティ対策の第一歩ですが、各サービス単体では検知までが役割であり、通知や IPS のような自動防御まではしてくれません。
ですので、まずは通知設定もしくは定期的な棚卸しが必要になります。
特に通知設定が重要なサービスは GuardDuty になりますが、今までですと GuardDuty → (Security Hub) → EventBridge → SNS → メール の構成が必要でした。
また、デフォルトのメールアドレスへの通知設定ですと json 形式での通知になるため、視認性が高くないという問題があります。
EventBridge の Input Transformer を使う方法もありますが、必要な情報の抽出や整形などが必要で、ややめんどうです。
今回ご紹介する User Notifications では EventBridge → SNS の構成を簡略しつつ、通知内容の視認性を高くすることができますので、ご参考にしていただけますと幸いです。
AWS User Notifications とはなにか
User Notifications は 2023年5月3日 に一般提供が開始された、AWS におけるイベント通知を一元的に設定、表示できるサービスです。
AWS User Notifications is an AWS service that provides a central location for managing your AWS notifications.
サービスの用途としては、AWS Health の通知で利用している方が多いと思います。
AWS User Notifications を使うとどんなメリットがあるのか
一番のメリットは視認性の高い通知を受け取れることです。
以下に「EventBridge → SNS でのメール通知」で受け取ったパターンと「User Notifications でのメール通知」で受け取ったパターンの通知例を示しますので、比較してみてください。
また、User Notifications を設定するだけで通知設定まで完了し、EventBridge や SNS の設定は不要なので、通知設定を簡略化することができます。
AWS 環境構成図
構成図として全体像を示します。
管理アカウントは除外していますが、AWS Organizations を利用しており、セキュリティアカウント1つとメンバーアカウントが3つある環境を示しています。
実装方法
初期設定
マルチアカウントにおける設定
現時点で Organizationsにも対応していますが、自動で全アカウントに設定を配布できるものではなく、あくまで検知内容を集約する機能となっているようですので本記事内では設定やサービスの委任については範囲外とします。
代わりに、マルチアカウント環境では GuardDuty を委任しているアカウントで User Notifications を設定することで、擬似的に通知を集約することが可能です。
しかし、この場合、通知内容のアカウント番号が発報されたアカウントではなく、委任されているアカウントとなってしまう点には注意が必要です。
CloudFormation StackSets で各アカウントに通知設定を配布する方法もありますが、この場合、各アカウントでメール検証を行わなければならないため、アカウントが多いと検証作業や確認作業が難しくなってしまうため、現時点で GuardDuty の通知に関しては委任されたアカウントでの設定を推奨いたします。
つきましては、以下からの手順はすべて GuardDuty を委任している Audit アカウントやセキュリティアカウントで実施してください。
Notification hubs の設定
はじめに「Notification hubs」を設定しましょう。
User Notifications の画面から「Notification hubs」へ遷移し、「Edit」を押下します。
Notification hubs は通知を保存、処理、複製する AWS リージョンを指定する設定ですので、普段使うリージョンを指定すると良いです。
今回は私が普段利用する東京リージョンを追加いたしました。
プルダウンから対象のリージョンを選択したら、「Update」を押下します。
通知設定
初期設定が完了しましたので、次に通知設定を行います。
User Notifications では "Notification configurations" が通知設定の本設定となります。
AWS managed notifications subscriptions という新しいマネージドな機能もありますが、現在は AWS Health のみに対応しているため、今回は通常の Notification configurations から設定していきます。
まずは「Notification configurations」から「Create notification configuration」を押下します。
User Notifications では「Quick setup」にて"CloudWatch", "EC2", "Health" が事前に設定が用意されていますが、今回は GuardDuty の通知を設定したいため、そのまま選択せずに次の項目へ進んでください。
「Name」および「Description」は任意で入力します。
今回は「Notification-GuardDuty-High-and-Critical」と命名します。
「AWS service name」では「GuardDuty」、「Event type」では「GuardDuty Finding」を設定します。
「Regions」では検知対象のリージョンを選択することができます。
すべてのリージョンを選択することもできますが、今回は「US East (N. Virginia)」「Asia Pacific (Tokyo)」のみを選択します。
GuardDuty は全リージョンで有効化している場合もあると思いますので、その場合はすべてのリージョンを選択してください。
「Advanced filter」では GuardDuty の Severity をフィルターしていきます。
対象を Severity High（Severity 7）以上したいので、以下のように入力します。
ここは EventBridge 設定時の Event pattern と同様に入力しても問題ありません。
{
"detail": {
"severity": [
{
"numeric": [
">=",
7
]
}
]
}
}
「Aggregation settings」では検知から通知までの間隔を設定できます。
「Receive within 5 minutes」に設定すると 5分間隔での通知となり、5分以内に検知した通知はまとめて通知されます。
最速で通知してほしいので「Receive within 5 minutes」に設定します。
また、「Delivery channels」では通知先を設定します。
Chat channels (Slack や teams) や Mobile App (push 通知) も設定できますが、今回は「Email」を設定してきます。
「recipient」にはメールアドレスをいれ、「Name」は任意の名前を入力します。
※ 複数の通知先を設定することも可能です。
※ 後ほど確認しますが、ここで入力された値が Delivery channels として登録されます。
任意のタグを付与し、「Create notification configuration」を押下します。
今回は Name タグのみ付与しておきます。
ここまでで User Notifications の通知設定は完了です。
通知先（メールアドレス）の検証
設定したメールアドレス宛に email-verification@aws.com から検証用のメールが届いていることを確認します。
※ 届いていない場合は迷惑ボックス等に割り振られていないかご確認ください。
検証時の注意点は以下3点です。
- 対象アカウントへログインした状態でリンクを踏む必要がある
- 「notifications-contacts:ActivateEmailContact」の権限が必要である
- 有効期限が12時間である
1. 対象アカウントへログインした状態でリンクを踏む必要がある
Amazon SNS を利用した場合には、マネジメントコンソールにアクセスしていなくてもメールで届くリンクからアクセスするだけで検証が可能となります。
しかし、User Notifications ではマネジメントコンソールにログインした状態でリンクからアクセスする必要がある点にご注意ください。
2. 「notifications-contacts:ActivateEmailContact」の権限が必要である
User Notifications ではメール検証に特定の権限が必要です。
注意点としては、この権限がマネージドポリシーである「ReadOnlyAccess」には付与されていないことです。
AdministratorAccess や PowerUserAccess の権限が付与されていれば問題ありませんが、運用者にはそこまで強い権限は付与されていないこともあると思うので、検証前にご確認ください。
また、私が確認した限り User Notifications に対するマネージドポリシーは見当たりませんでした。
そのため、必要であれば以下のようなポリシーを作成し、担当者に付与してください。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "UserNotificationsContactsFullAccess",
"Effect": "Allow",
"Action": "notifications-contacts:*",
"Resource": "*"
},
{
"Sid": "DenyCreateandDeleteUserNotificationsEmailContact",
"Effect": "Deny",
"Action": [
"notifications-contacts:DeleteEmailContact",
"notifications-contacts:CreateEmailContact"
],
"Resource": "*"
}
]
}
3. 有効期限が12時間である
検証用のメールが通知されてから12時間経ってしまうと有効期限切れとなり、検証できなくなります。
通知先が自分以外のメンバーの場合には、本日中に対応するように伝えるか、もしくは権限があれば Resend も可能なので担当者の権限に応じて案内をしてください。
無事に検証が完了すると以下のような画面が出力されます。
また、Delivery channels で Verification status が Active となっていることも確認しましょう。
通知テスト
これで通知設定がすべて完了しました。
メール検証も終わっているので設定は問題ないはずですが、内容確認の意味も含めて通知テストを行いましょう。
※ 通知内容にマネジメントコンソールへのリンクが含まれる仕様上、迷惑メール等に振り分けられる可能性もありますので、必ずご確認ください。
GuardDuty にはサンプル検知の機能があります。
マネジメントコンソールからの操作ですと、すべての検知項目が発報されてしまうので、AW CLI を用いて特定の項目を検出させることを推奨します。
CloudShell 等で以下のコマンドを実行して、High と Low のサンプル検出をさせます。
Severity High
aws guardduty create-sample-findings \ --detector-id $(aws guardduty list-detectors --query 'DetectorIds' --output text) \ --finding-types Backdoor:EC2/DenialOfService.UnusualProtocol
Severity Low
aws guardduty create-sample-findings \ --detector-id $(aws guardduty list-detectors --query 'DetectorIds' --output text) \ --finding-types Policy:S3/AccountBlockPublicAccessDisabled
エラーがなくプロンプトが返ってきたら成功です。
設定したように最長5分でメール通知が飛びますので、少し待ってから High のみが通知されることを確認してください。
送信元は guardduty@aws.com となります。
まとめ
本記事では User Notifications を利用して Amazon GuardDuty の視認性を高めた検出結果をメール通知する方法とテスト通知についてご紹介いたしました。
GuardDuty のデフォルト通知内容（json）を見たことがある方には、より嬉しいサービスだと感じていただけたのではないでしょうか。
メール検証がややめんどうですが基本的には始めの1回だけで設定は完了しますし、Amazon SNS のようにメールから unsubscribe するリスクもありません。
設定後の運用は楽になると思いますので、是非お試しいただけますと幸いです。
おまけ
右上のベルマーク
User Notifications が利用できるようになったタイミングで右上にベルマークが追加されました。
これは User Notifications で通知があった場合に赤く件数が表示され、そこから内容の確認もできるようになっています。
通知設定をしているのでメール等で気づけると思いますが、赤くなっていた際にはこちらもご確認いただくと良いです。
User Notifications の裏側の設定
User Notifications で設定される EventBridge がどのような設定になっているか気になったので、確認してみました。
設定したリージョンに「AWSUserNotificationsManagedRule-xxxxx」という名前で Rule が構築されています。
Type が Managed となっており、Delete はできるようですが Edit や Disable はできないように設定されていました。
また、Event pattern では設定した High 以上の条件は記載されていなかったので、おそらく User Notifications 側で Filter をかけているようです。
それでは、またお会いしましょう。
岡部 純 (執筆記事の一覧)
カスタマーサクセス部所属
AWS資格全冠取得、2024 All Certifications Engineers
マルチアカウント、AWS Organizations 運用を得意としています
