GuardDuty を有効にしたら、数日のうちに検出結果が届き始めます。ところが、どれから見るのか、どこまで自分で調べるのか、誰に渡すのかが決まっていないと、一覧に未対応が溜まるだけになります。本物と想定内の通信が混ざるので、全部を同じ温度で追うのも現実的ではありません。この記事では、検出結果を受け取ってから「振り分ける → 裏を取る → 封じ込めるか抑制するか」までの回し方を、運用の型として整理します。
この記事の結論
- 検出結果は重大度と種類（finding type）で受け、高いものから見る。全部を同じ温度で追わない。
- 通知は Amazon EventBridge で受け、重大度で絞って担当に送る。自動隔離は、誤検知のときの影響を決めてから。
- 本物か想定内かは、対象のリソース・呼び出し元の IP・AWS CloudTrail の操作履歴で裏を取る。
- 想定内と繰り返し確認できたものだけ、種類と対象を絞った抑制ルールにする。抑制された検出結果はアーカイブされ、EventBridge などには送られない。
- 広すぎる抑制は、複数段階の攻撃を見つける材料まで消す。ルールは狭く作り、定期的に見直す。
検出結果が届いたら最初に何を見るか
Amazon GuardDuty は、CloudTrail などのログを自分で集めて解析しなくても、エージェントなしで脅威を検出するサービスです。検知そのものは AWS が提供する部分で、出てきた検出結果をどう扱うか、どこへ通知するかは利用者側の仕事になります。この分担は責任共有モデルの考え方どおりです。検出結果の概要は公式の検出結果のページから各ページに入れます。
検出結果を開いたら、次の3つを順に見ます。
| 見るもの | 何が分かるか | その次にすること |
|---|---|---|
| 重大度 | どれだけ急ぐか | 高いものから先に対応する。数値の範囲の定義は公式の重大度のページで確認する |
| 種類（finding type） | どんな振る舞いを疑っているか | 種類の名前から、対象が EC2 か IAM か S3 かを読み取る |
| 対象のリソースと呼び出し元 | どのリソースが、どの IP やロールから | 想定した使い方かを、持ち主に聞けるかどうかで切り分ける |
種類は数が多いので、記事で網羅はしません。公式の一覧を引きながら、見慣れない種類が出たときに意味を調べる、という使い方で十分です。大事なのは、重大度の高いものと低いものを同じ列に並べて、上から順に潰そうとしないことです。
FINDING TRIAGE検出結果の回し方
重大度で振り分け、裏を取ってから封じ込めか抑制かを決める
-
受ける
EventBridge で通知
-
振り分け
重大度と種類
-
裏取り
対象・IP・CloudTrail
-
本物
封じ込めて人に渡す
-
想定内
狭い抑制ルール
通知はどこに送るか
検出結果は EventBridge にも届きます。ここにルールを作り、重大度や種類のイベントパターンで絞って、チャットや起票の仕組みに流します。コンソールの画面を毎日開いて確かめる運用は続きません。見に来るのを待たずに、重大度の高いものだけが担当に届く形にします。EventBridge そのものの仕組みはEventBridge の記事にあります。
絞り方の考え方は2段です。
- EventBridge のルールで、重大度の高いものだけを即時の送り先（呼び出し当番など）へ送る。
- 低いものは、まとめて確認する場所（週次の確認用のチャンネルなど）へ送る。
ここで自動化の話が出てきます。重大度の高い EC2 の検出結果をきっかけに、Lambda で隔離用のセキュリティグループへ付け替える構成は、練習問題でもよく出る型です。技術的には組めますが、誤検知だったときに本番の通信が止まります。止めたときの影響（どのシステムが何分止まってよいか）を先に決めてから組むのが順序です。決められないうちは、通知と手順書から始めます。
FINDING ROUTES検出結果の通り道
抑制ルールの門を通ると静かになり、通った検出結果が重大度で振り分けられる
抑制ルールと EventBridge のルール
- 抑制条件に合う検出結果 アーカイブ・通知なし種類＋送信元などで絞る
- 高重大度の高い検出結果 即時の送り先へ抑制に合わない
- 低重大度の低い検出結果 週次の確認へ抑制に合わない
CHECK 1ここまでの確認
GuardDuty の検出結果をチャットや起票の仕組みへ流す入口になるサービスはどれ?
答えと解説
答え: 1. Amazon EventBridge
検出結果は EventBridge に届き、ルールで重大度や種類を絞って送り先を決められます。「通知はどこに送るか」の章を読み直してください。
本物か想定内かをどう切り分けるか
通知が届いたら、まず対象と呼び出し元を確かめます。その IP は自社の拠点か、契約している業者か、見覚えのない外部か。対象のロールやインスタンスは、誰が持っているものか。持ち主に聞けば「その時間に作業していた」と分かることもあります。
それで決まらないときは、CloudTrail で操作を裏取りします。CloudTrail は API 操作の履歴を残すので、検出結果のロールやアクセスキーが、いつ、どこから、どの操作をしたかを時系列で追えます。見るのは主に次の点です。
- 検出の前後で、普段しない操作（権限の変更、新しいキーの作成、ログ設定の変更）が続いていないか
- 呼び出し元の IP が、普段の接続元と違っていないか
- 同じ主体が、別のリージョンやアカウントでも操作していないか
関係するロールや IP の過去の振る舞いをまとめて見たいときは、Amazon Detective で検出結果から調査に入る方法があります。動作を関係のグラフで見られるので、CloudTrail を1行ずつ読むより全体像をつかみやすい場面があります。
本物だったときの最初の一手
裏が取れて本物の疑いが強いなら、最初にやるのは封じ込めです。原因の究明は、止めたあとで構いません。
- 漏えいしたアクセスキーなら、まず無効化する。正規の処理が同じキーを使っているなら、新しいキーを発行して差し替える。そのうえで CloudTrail で使用履歴を調べる。
- EC2 が疑わしいなら、隔離用のセキュリティグループに付け替えて通信を止める。インスタンスは消さずに残し、あとで調べられるようにする。
- 自分で判断し切れない、または影響範囲が広いときは、手順書に決めておいた連絡先へ渡す。
「人に渡す」条件は、検出結果が届く前に決めておきます。誰が一次対応で、どの重大度から誰に上げるかが空白のままだと、本物のときほど最初の数十分が迷いに使われます。ポストモーテムとして残す書き方はポストモーテムの記事にあります。
CHECK 2ここまでの確認
検出結果に出てきた IAM ロールが「いつ・どの操作をしたか」を調べる先として、まず当たるのはどれ?
答えと解説
答え: 2. AWS CloudTrail の API 操作の履歴
誰がいつどの API を呼んだかは CloudTrail に残ります。「本物か想定内かをどう切り分けるか」の章に戻ってください。
想定内の検出結果はどう減らすか
取引先の脆弱性診断が定期的にポートスキャンをする、といった「想定内と分かっているもの」は、毎回通知されると本物を見落とす原因になります。その騒音を減らす機能が抑制ルールです。公式の抑制ルールのページには、仕組みが次のように書かれています。
- 条件に合う新しい検出結果は、自動でアーカイブされる。
- アーカイブされた検出結果は、Security Hub・S3・Detective・EventBridge などの送り先には送られない。
- アーカイブされたものは、一定期間は見返せる（公式には 90 日の保管と書かれている）。
- 複数アカウントの構成では、抑制ルールを作れるのは管理者のアカウントだけ。
- 同じ検出結果が繰り返し出て、誤検知だと確認できたものにだけ作ることが推奨されている。
つまり「消える」のではなく「静かになる」機能で、静かになる範囲には通知も含まれます。広く作るほど、本物の通知まで止まります。公式も、抑制は Extended Threat Detection のような複数段階の攻撃の検出に使う材料に影響しうると注意しています。
SUPPRESSION SCOPE抑制ルールの広さ
抑制は狭いほど見逃しにくい。広いほど静かだが材料も消える
狭いルール
- 見逃しにくい
- 条件を決める手間が増える
- 種類＋送信元で絞る
広いルール
- 通知は静かになる
- 本物の通知も止まる
- 複数段階の攻撃の材料も消える
支点は「同じ確認を繰り返したか」
作り方の原則は、条件を狭くすることです。診断業者のポートスキャンなら、検出の種類と業者の送信元 IP を組み合わせます。種類だけで抑制すると、別の送信元の本物のスキャンも静かになります。逆に送信元だけで抑制すると、その IP が別の種類の検出を出したときも見えなくなります。操作の画面の順番は改定で変わるので書きませんが、条件を何で絞るかは設計として決めておきます。
CHECK 3ここまでの確認
定期的に来る取引先の診断で同じ種類の検出結果が繰り返し出るとき、いちばん狭い減らし方はどれ?
答えと解説
答え: 2. 種類と送信元などの条件を絞った抑制ルールを作る
全面無効にすると本物も見逃します。抑制ルールは条件を絞るほど、消える材料が少なくなります。「抑制ルールとアーカイブ」の章を読み直してください。
週次・月次で何を見直すか
運用は、通知を作って終わりではありません。見直す項目を決めておきます。
| 頻度 | 見るもの | 目的 |
|---|---|---|
| 週次 | 未対応の件数と、低い重大度の検出結果 | 溜まっていないか、同じ種類が増えていないか |
| 週次 | 即時の送り先に届いた件数 | 多すぎれば絞り方を見直し、ゼロが続けば通知経路が生きているかを確かめる |
| 月次 | 抑制ルールの一覧 | もう来ない業者の条件や、広すぎる条件が残っていないか |
| 月次 | 手順書と連絡先 | 担当が変わっていないか |
抑制ルールは足すだけで消されないと、静かに肥大します。作ったときの理由（誰の何のためか）を記録に残し、理由が無くなったら外します。
CHECK 4ここまでの確認
抑制ルールに合った新しい検出結果は、そのあとどう扱われる?
答えと解説
答え: 2. 自動でアーカイブされ、EventBridge などの送り先には届かない
抑制された検出結果は自動でアーカイブされ、一定期間は見返せますが、通知の送り先には出ません。だから広すぎる抑制は本物の通知まで止めます。
まとめ
検出結果は、重大度で振り分け、EventBridge で担当に届け、対象と CloudTrail で裏を取る順で回します。本物なら先に封じ込め、想定内と繰り返し確認できたものだけを、狭い抑制ルールで静かにします。自動隔離は影響を決めてから、抑制ルールは定期的に棚卸しします。アラームの初動はアラームが鳴ったときの記事、組織全体での管理はマルチアカウントの設計へ進んでください。
Cloudory 執筆者（AWS 認定 全冠）
検出結果の運用は、機能の知識よりも「誰が何分以内に何をするか」を事前に決めておけるかで差が出ます。まず重大度の高いものだけ担当に届く形を作り、それから抑制を足してください。
参照ソース
- Amazon GuardDuty ユーザーガイド｜検出結果 — 検出結果の概要と、重大度・種類の各ページへの入口として使った
- Amazon GuardDuty ユーザーガイド｜抑制ルール — 自動アーカイブ、アーカイブ後の送り先、保管期間、管理者のみ作成、広すぎる抑制の注意の根拠として使った
- AWS 責任共有モデル — 検知は AWS、検出結果への対応は利用者という分担の根拠として使った（台帳 shared-responsibility）
