はじめる前に
- 必須AWS アカウントを持ち、マネジメントコンソールにサインインできること
- 必須通知の宛先として使える、自分が受信できるメールアドレスを持っていること
- あると良い「イベント駆動」（何かが起きたことをきっかけに処理が動く考え方）という言葉を聞いたことがある
- あると良いSNS（通知サービス）や EventBridge（イベントの橋渡し）という名前を聞いたことがある
※ このハンズオンは すべてコンソールだけで完結します。コマンドライン操作やサーバーへのログインは一切ありません。
参照する公式ドキュメント
手順に迷ったときや、用語の意味を確かめたいときに開きましょう。
※ リンク切れの場合は、ページタイトルで検索してください。
背景・シナリオ
不正なアクセスやマルウェアの通信といった脅威の兆候は、自分の目で気づくのが難しいものです。GuardDuty は、VPC のログや DNS の問い合わせ、API の操作履歴などを継続的に分析し、怪しい挙動があれば「検出結果（Finding）」として知らせてくれる脅威検出サービスです。
ただし、GuardDuty を有効にするだけでは、検出結果はコンソールの中に表示されるだけです。誰かが毎日コンソールを見に行くのは現実的ではないため、検出結果が出た瞬間に自動でメールへ届く仕組みを別に組み立てる必要があります。今回は EventBridge で検出結果のイベントを捉え、SNS 経由でメールに変換する、よくある通知パイプラインの組み方を体験します。
GuardDuty を有効にしたら、すぐに何か通知が来るの？
いいえ。GuardDuty が脅威を検出すると、コンソールの「検出結果」一覧に表示されるだけです。メールなどへ自動で知らせるには、EventBridge と SNS（や Lambda など）を組み合わせて、自分で通知の経路を作る必要があります。それが今回のハンズオンの中心です。
本物の攻撃を受けないと検出結果は出ないの？
本物の検出を待つと、いつ・何が起きるか分からず再現性が低いです。そこで GuardDuty には、学習・テスト用に「サンプル検出結果を生成する」機能が用意されています。これを使うと、安全に・確実にパイプライン全体の動作を確認できます。
GuardDuty を有効化し、検出結果のイベントを EventBridge ルールで捉えて SNS トピックに渡す仕組みを作る。サンプル検出結果を生成し、登録したメールアドレスに通知が届くことを確認する。
つくる構成
GuardDuty が出す検出結果のイベントを、EventBridge のルールが捉えて SNS トピックに渡し、SNS がメールへ変換して届けます。4 つのサービスが一列につながるパイプラインです。
Finding を発生
捉えて転送
配信用に中継
通知が届く
要件
以下の要件を満たし、検出結果からメール通知までの一連の流れが動くことを確認してください。
| No | 要件 |
|---|---|
| 1 | リージョンは「東京（ap-northeast-1）」を使用する。 |
| 2 | GuardDuty を有効化する。 |
| 3 | SNS トピックを 1 つ作成し（タイプ「スタンダード」）、自分が受信できるメールアドレスでE メールサブスクリプションを登録する。届いた確認メールのリンクからサブスクリプションを確認（Confirm）する。 |
| 4 | EventBridge ルールを作成する。イベントソースを「AWS のサービス」・GuardDuty、イベントタイプを「GuardDuty Finding」とするイベントパターンを設定し、ターゲットを手順 3 の SNS トピックにする。 |
| 5 | GuardDuty のサンプル検出結果を生成し、数分待って登録したメールアドレスに通知が届くことを確認する。 |
構築の進め方
「受け皿（SNS）を作る → 橋渡し（EventBridge）を作る → 検出元（GuardDuty）を有効にする → サンプルで動かして確かめる」の順に進めます。
-
マネジメントコンソールにサインインし、リージョンを合わせる
ブラウザで AWS マネジメントコンソールにサインインし、画面右上のリージョンが「アジアパシフィック（東京）ap-northeast-1」になっていることを確認します。
-
SNS トピックを作成する
SNS コンソールの「トピック」→「トピックの作成」を開きます。タイプ「スタンダード」を選び、名前（例：
guardduty-alert-topic）を付けて作成します。先に受け皿を用意するあとで EventBridge ルールのターゲットを選ぶときに、先にトピックがあるとスムーズに選べます。
-
E メールサブスクリプションを登録し、確認する
作成したトピックの「サブスクリプションの作成」で、プロトコル「E メール」、エンドポイントに自分が受信できるメールアドレスを入力します。作成すると確認メールが届くので、メール内の「Confirm subscription」リンクをクリックします。
確認しないと届かないサブスクリプションの状態が 「Pending confirmation（確認待ち）」のままだと、いくらイベントが流れても通知は配信されません。必ずリンクをクリックして「Confirmed」にしておきましょう。
-
EventBridge ルールを作成する
EventBridge コンソールの「ルール」→「ルールを作成」を開きます。名前（例：
guardduty-finding-rule）を付け、イベントバスは「default」のまま進めます。ルールタイプ
イベントパターンを持つルールGuardDuty が出す「検出結果イベント」をきっかけにするスケジュール決まった時刻・間隔で実行する（今回は使わない）↳「何かが起きたら」動かしたいので、イベントパターンを選びます
イベントパターンの設定で、イベントソース「AWS のサービス」、AWS サービス「GuardDuty」、イベントタイプ「GuardDuty Finding」を選びます。
イベントソース AWS のサービス AWS サービス GuardDuty イベントタイプ GuardDuty Finding イベントパターンは「条件」ここで指定した条件に一致するイベントだけが、このルールに反応します。GuardDuty が出す検出結果のイベントだけを狙って捉えるための絞り込みです。
-
ターゲットに SNS トピックを指定して、ルールを作成する
ターゲットの選択で「SNS トピック」を選び、手順 2 で作った
guardduty-alert-topicを指定します。画面に「リソースベースポリシーを自動的に更新する」というチェックボックスが出る場合はチェックを入れたまま進み、ルールを作成します。トピックへの送信許可を自動で設定EventBridge が SNS トピックにイベントを送るには、トピック側で「EventBridge からの発行を許可する」設定が必要です。コンソールでターゲットに SNS を選ぶと、この許可がまとめて設定されます。
-
GuardDuty を有効化する
GuardDuty コンソールを開き、「今すぐ始める」（Get started）→「GuardDuty の有効化」を実行します。有効化には数十秒〜数分かかります。
-
サンプル検出結果を生成し、メールを確認する
GuardDuty コンソールの左メニュー「設定」を開き、「サンプル検出結果を生成」ボタンを押します。「検出結果」一覧に、サンプルであることが分かる項目（タイプ名に「Sample」を含むもの）が複数表示されます。
数分待ち、手順 3 で登録したメールアドレスの受信ボックスを確認します。検出結果の内容（JSON 形式）を含む通知メールが届いていれば成功です。
件数が多くても焦らないサンプル検出結果は複数の種類が一度に生成されるため、メールも複数件届くことがあります。これは想定どおりの動きです。
つまずきポイント
初学者がよく引っかかる箇所を先回りでまとめました。答えそのものは載せていませんが、「どこを見直せばよいか」の手がかりとして使ってください。
「検出結果一覧にはサンプルが見えるのに、通知が届かない」
確認したい点がいくつかあります。①SNS サブスクリプションの状態が「Confirmed」になっているか（確認メールのリンクをクリックし忘れていないか）、②EventBridge ルールが「有効（Enabled）」になっているか、③イベントパターンのイベントソース・イベントタイプが GuardDuty Finding に正しく一致しているか——のいずれかが欠けていることが多いです。
「数分待っても、受信ボックスに何も増えない」
迷惑メールフォルダに振り分けられている場合があります。送信元のアドレス（no-reply@sns.amazonaws.com など）で検索してみましょう。また、サブスクリプション登録時のメールアドレスのタイプミスも、よくある原因の 1 つです。
完了チェック
要件の再確認ではなく、画面のどこを見れば達成を確認できるかをまとめました。各コンソールを開いて、次を順に確かめましょう。
- GuardDuty コンソールで、ステータスが「有効」になっている。
- SNS コンソールの「サブスクリプション」一覧で、状態が「Confirmed」になっている。
- EventBridge の「ルール」一覧で、
guardduty-finding-ruleの状態が「有効」になっている。 - GuardDuty の「検出結果」一覧に、サンプルの検出結果が複数表示されている。
- 登録したメールアドレスの受信ボックスに、検出結果の通知メールが届いている。
考えてみよう
手を動かすことに加えて、次の問いに自分の言葉で答えられるようにしておくと、理解がより深まります。
- なぜ GuardDuty の検出結果を直接コンソールで見に行くのではなく、EventBridge と SNS で通知する仕組みを作ったのでしょうか。
ヒント
定期的にコンソールを見に行く運用は、見落としが起きやすく、気づくまでに時間がかかります。「起きたことをきっかけに、向こうから知らせてもらう」という発想に変えることで、気づくまでの時間を短縮できます。 - 今回はメール通知だけにしましたが、EventBridge のターゲットを SNS ではなく Lambda 関数にすると、どんな自動対応が考えられるでしょうか。
ヒント
検出結果の内容に応じて、該当するセキュリティグループを自動で締める、関係する IAM ユーザーのアクセスキーを無効化するなど、人の判断を介さない自動対応が考えられます。一方で、誤検知のまま自動対応すると業務に影響が出るリスクもあります。両方の側面から考えてみましょう。 - サンプル検出結果を使って動作確認をしましたが、本番運用では実際の検出結果に依存します。GuardDuty は「何を見て」脅威を検出していると思いますか。
ヒント
GuardDuty は、VPC のフローログ・DNS の問い合わせログ・CloudTrail の操作履歴など、すでに AWS 環境内にあるログを継続的に分析しています。何か新しいセンサーを追加しなくても検出が始まる、という点から考えてみましょう。
後片づけ
作ったものを片づけるところまでが一連の流れです。次の順で進めると迷いにくいです。
- EventBridge ルールを削除する：
guardduty-finding-ruleを選び「削除」。 - SNS トピックを削除する：
guardduty-alert-topicを削除すると、紐づくサブスクリプションも合わせて削除されます。 - GuardDuty を無効化する（学習目的で残さない場合）：GuardDuty コンソールの「設定」から「GuardDuty の無効化」を選びます。
残しておくかどうかは目的に応じて判断する
GuardDuty を無効化すると、それまでの検出結果の履歴も失われます。学習用のアカウントで一度試しただけなら無効化して問題ありませんが、実務のアカウントでは無効化してよいかどうかを必ず確認してから操作してください。
コストに関する注意: GuardDuty には 30 日間の無料トライアルがありますが、トライアル終了後は分析するログの量（VPC フローログ・DNS ログ・CloudTrail イベントなど）に応じて料金が発生します。有効化したままにすると継続して課金されるため、検証が終わったら無効化するかどうかを検討しましょう。SNS のメール通知やEventBridge のカスタムイベントは、今回程度の利用量であれば無料利用枠の範囲に収まることが多いですが、最新の料金は AWS の公式料金ページで確認してください。