GuardDutyの全リージョンの検出結果を通知する方法3選
GuardDutyは、有効化するだけで良い感じに不審なアクティビティを検出してくれるサービスです。料金も安価なため、ぜひ全環境で有効化しておきたいサービスです。
しかし、GuardDutyはリージョン別サービスであるため、有効化や通知設定は基本的にリージョンごとに行う必要があります。
有効化の方法は、ここでは割愛します。コンソールで全リージョン分ポチポチするのはしんどいため、CloudFormation StackSets、AWS CLI、Organizations連携といった方法をおすすめします。
ここでは、GuardDuty検出結果の通知を全リージョン分設定する方法を示します。通知手段はメールを想定していますが、他の手段も利用可能です。全体的に詳細は省略しますので、具体的な設定内容とデプロイ方法は別の資料をご参照ください。
TL;DR
AWS User Notifications、良いと思います!
基本的な通知方法
単一リージョンでGuardDuty検出結果を通知する基本的な方法は、GuardDuty → EventBridge → SNSと構成することです。
参考:GuardDuty の EventBridge ルール設定で、SNS 通知を送信できるようにする | AWS re:Post
しかし、この構成を全リージョンにそのままデプロイした場合、SNSトピックが全リージョンに作成されるため、サブスクリプションの登録作業や変更作業に手間が掛かってしまいます。これはデプロイ手順をCloudFormation StackSetsなどで自動化できたとしても、簡略化することができません。
そのため、全リージョン展開する場合、SNSトピック(一般的に言えば、通知先の登録場所)が一箇所になるように工夫する必要があります。
方法1:EventBridgeリージョン間イベント送受信
最も単純な方法は、EventBridgeのリージョン間でのイベント送受信を使用する方法です。
各リージョンのEventBridgeルールで、GuardDuty検出イベントを特定のリージョン(ホームリージョンと呼ぶことにします)のEventBridgeイベントバスに送信するようにし、ホームリージョンのSNSトピック経由で通知するようにします。
参考:GuardDuty 全リージョン分の検出結果を EventBridge で集約してからメール通知する CloudFormation テンプレートの紹介 | DevelopersIO
方法2:Security Hub経由
少しトリッキーな方法は、Security Hubを経由する方法です。Security Hubを「ハブ」として使用することになるので、ある意味名前どおりの順当な方法とも言えるかもしれません。
構成するには、Security Hubを有効化し、Security Hubのクロスリージョン集約を設定します。このとき、セキュリティ標準は有効化しなくても構いません。GuardDutyとSecurity Hubの統合はデフォルトで有効であり、自動的にGuardDutyの検出結果がSecurity Hubに取り込まれます。
EventBridgeルールのイベントパターンは、"source": ["aws.guardduty"]
ではなく"source": ["aws.securityhub"]
とすることがポイントです。
この方法は、Security Hubの活用を考えている方におすすめです。例えば、Security Hubのセキュリティチェックも使用したい方や、全リージョンのGuardDuty検出結果を一画面で確認したい方、検出結果のステータス(通知済み、解決済みなど)をSecurity Hubで管理したい方などです。
参考:【小ネタ】GuardDuty 通知は Security Hub 経由で行うとリージョン集約ができて便利 | DevelopersIO
方法3:AWS User Notifications経由
最近新たに利用可能になった方法が、2023年5月にGAされたAWS User Notificationsを使用する方法です。
User Notificationsを使用すれば、通知のトリガーとなるイベントパターンと通知先を1箇所で管理することができます。また、通知の履歴もUser Notificationsコンソールで確認できます。ちなみに通知のトリガーを設定すると、裏側ではEventBridgeルールが作成されます。
HealthやCloudWatch Alarmといった他のAWSサービスの通知もまとめて管理できるため、複数のサービスの通知をUser Notificationsで管理したい方に特におすすめです。
参考:[新サービス] AWS User Notificationsで通知設定を試してみた | DevelopersIO
まとめ
SNSトピックを使用する方法(方法1、2)とUser Notificationsを使用する方法(方法3)の比較を下表にまとめました。
観点 | SNSトピック経由 | User Notifications経由 |
---|---|---|
見やすさ | △ 何もしなければJSON形式です。読みやすくするには、EventBridgeの入力トランスフォーマーやStep Functionsによる整形が必要です |
○ HTML形式 ○ 同じ時間帯の検出結果を1つにまとめて通知する機能があります ○ 通知設定と履歴を一元的に管理できます |
カスタマイズ性 | ○ Lambda関数などで何でもできます ○ EventBridgeルールのイベントパターンで、通知対象をフィルターできます |
× 既定の文面のみ ○ EventBridgeルールのイベントパターンで、通知対象をフィルターできます(同左) |
デプロイ方法 | ○ マネジメントコンソール、AWS CLI、CloudFormationなど | △ マネジメントコンソールのみ |
設定の簡単さ | △ User Notificationsに比べると設定項目は多いです | ○ 数分で設定できます |
総合的に見て、簡単に分かりやすい通知を受け取ることができるUser Notificationsが、一般にはおすすめだと思いました!
Discussion