Amazon GuardDutyで検出された脅威、対処要否はどう判断する？

齊藤弘樹

AWSを利用している環境では、AWS Security HubやAWS Config、そしてAmazon GuardDutyを有効化しているケースが多いのではないでしょうか。

　

私が参画しているプロジェクトでも、Amazon GuardDutyが脅威を検出するとメールで通知されます。

　

その際に悩ましいのが、「この検出結果は本当に対処が必要なのか？」という判断です。

　

今回の記事では、Amazon GuardDutyで検出された脅威に対して、対処が必要かどうかを判断するための考え方を整理してみました。

　

　

はじめに

日々の運用のなかで、皆さんのもとにはどれくらいの通知が届いているでしょうか。

　

サーバーやネットワークの監視に加えて、クラウド環境ではアカウント自体の監視も必要になります。軽微なものも含めると、日々確認すべきアラートは増える一方です。

　

今回私が気になった Amazon GuardDuty の検出結果も、そうした数多くの通知のひとつでした。

　

私はGuardDutyの対応を直接担当しているわけではありませんが、「この検出結果に対して、対応すべきかどうかをどう判断するのがよいのか」が気になりました。

　

特に気になったのは、重要度が“Medium”や“Low”の検出結果をどう扱うべきかという点です。

　

AWS の「AWS Black Belt Online Seminar」では、検出結果の確認から対応までの流れとして、次のようなプロセスが紹介されています。

　

  1. 検出結果の取得
    　⇒検出結果の確認、メール通知の受領
    　
  2. 検出結果の調査
    　⇒検出結果タイプの確認、影響を受けるリソースの特定
    　
  3. トリアージ
    　⇒問題の切り分け、脅威への対処要否の判断、優先度付け

　

その後、判断結果に応じて次のような対応に進みます。

　

  • 脅威への対処が必要な場合
    ⇒封じ込め、根絶、復旧などを実施する

  • 脅威への対処が不要な場合
    ⇒検出結果をアーカイブする

　

今回私が特に知りたかったのは、この 「3. トリアージ」 の考え方です。

　

その前に、まずは Amazon GuardDuty の基本情報を簡単に整理します。

　

　

Amazon GuardDutyとは

Amazon GuardDuty は、AWS 環境内の不審なアクティビティや潜在的な脅威を継続的に検出する脅威検知サービスです。

　

GuardDuty は、CloudTrailイベントログ、VPCフローログ、DNSログなどのデータソースを分析して、検出結果（Finding）を生成します。

　

さらにくわしく知りたい方は、What is GuardDuty?を見てみてください。

　

　

■基礎データソースの分析（デフォルトの検知機能）

GuardDutyは、利用者環境とは独立したデータストリームを分析して脅威を検出します。代表的なデータソースは次のとおりです。

　

  • CloudTrailイベントログ
    ⇒IAMユーザーやロールによる異常なAPIコールなどを検知

  • VPCフローログ
    ⇒EC2インスタンスに対するSSHブルートフォース攻撃などを検知

  • DNSログ
    ⇒フィッシングやマルウェア配布に関連する不審なドメインへの名前解決などを検知

　

■検出結果の重要度


GuardDuty の各検出結果には、潜在的なリスクに応じた重大度（Severity）が設定されています。重大度の値は 1.0〜10.0 の範囲で、値が高いほどリスクが高いことを意味します。(Severity levels of GuardDuty findingsより)

　

  • Critical（9.0〜10.0）
    ⇒攻撃が進行中、または直近で発生した可能性があり、1つ以上の AWS リソースが侵害されている、もしくは侵害された可能性を示します。(Critical severityより)

  • High（7.0〜8.9）
    ⇒対象リソースが侵害され、不正な目的でアクティブに使用されている可能性を示します。(High severityより)

  • Medium（4.0〜6.9）
    ⇒通常の挙動から逸脱した不審なアクティビティがあり、侵害の可能性を示します。(Medium severityより)

  • Low（1.0〜3.9）
    ⇒侵害そのものではないものの、不審な試行や予兆と見なせるアクティビティを示します。(Low severityより)

　

■検出結果タイプ（Finding type）

GuardDutyでは、検出結果タイプによって「何が起きたのか」が端的に表現されています。

　

AWS 公式ドキュメントでも、finding typeは検出結果の詳細のなかでも特に重要な情報のひとつとされています。(GuardDuty の検出結果の形式より)

　

たとえば、検出結果タイプは概ね次のような要素で構成されています。

　

フィールド 概要 例
ThreatPurpose 脅威の主な目的 Discovery / Backdoor
ResourceTypeAffected 脅威の対象となったAWSリソース EC2 / IAMUser / S3
ThreatFamilyName 検出されたアクティビティの種別 NetworkPortUnusual / AnomalousBehavior
DetectionMechanism どのような仕組みで脅威を検出したか TCP / UDP / Custom / Reputation
Artifact 攻撃で利用されたツールや関連要素 DNS / PrivilegedContainer

　

　

検出結果をもとにどう判断するか

Amazon GuardDutyの検出結果から対処要否を判断するうえで、特に重要になるのは「重要度」と「検出結果タイプ」です。

　

■Critical / Highは基本的に即時対応

重要度がCritical、またはHighの場合は、基本的に即時対応が必要だと考えてよいでしょう。

　

もちろん詳細確認は必要ですが、「対応するかどうか」を迷うよりも、まずは影響範囲の確認や封じ込めを優先すべきレベルです。

　

AWS公式でも、これらは侵害や不正利用の可能性が高い重大な検出結果として位置づけられています。

　

　

■Medium / Lowは一律に判断できない

一方で、MediumやLowの場合は少し事情が異なります。

　

結論から言うと、

　

  • Mediumだから対応不要
  • Lowだから無視してよい

　

と一律には決められません。

　

実際には、システムの特性やプロジェクトの運用方針によって判断が分かれます。

　

MediumやLowの検出結果には、今すぐ封じ込めが必要とは限らないものも含まれます。

　

ただし、だからといって放置してよいわけではありません。内容を確認したうえで、

　

  • 優先度を下げて後続対応とする
  • 問題ない動作と判断してアーカイブする
  • 監視継続対象として扱う

　

といった整理が必要になります。

　

　

■事前に「検出結果タイプごとの方針」を決めておく

この判断を運用の現場で毎回ゼロから行うのは大変です。

　

そのため、あらかじめ検出結果タイプごとに対処要否の方針を整理しておくのが現実的です。

　

GuardDutyにはEC2、IAM、S3などリソース種別ごとに多数の検出結果タイプがあり、AWS公式でもアクティブなfinding typeが一覧化されています。

　

なお、finding typeは追加・廃止されることがあるため、定期的に公式ドキュメントを確認する前提で整理しておくのがよいでしょう。(GuardDuty finding typesより)

　

たとえば、EC2向けの検出結果タイプには、以下のようなものがあります。
　

Backdoor:EC2/C&CActivity.B
Backdoor:EC2/C&CActivity.B!DNS
Backdoor:EC2/DenialOfService.Dns
Backdoor:EC2/DenialOfService.Tcp
Backdoor:EC2/DenialOfService.Udp
Backdoor:EC2/DenialOfService.UdpOnTcpPorts
Backdoor:EC2/DenialOfService.UnusualProtocol
Backdoor:EC2/Spambot
Behavior:EC2/NetworkPortUnusual
Behavior:EC2/TrafficVolumeUnusual
CryptoCurrency:EC2/BitcoinTool.B
CryptoCurrency:EC2/BitcoinTool.B!DNS
DefenseEvasion:EC2/UnusualDNSResolver
DefenseEvasion:EC2/UnusualDoHActivity
DefenseEvasion:EC2/UnusualDoTActivity
Impact:EC2/AbusedDomainRequest.Reputation
Impact:EC2/BitcoinDomainRequest.Reputation
Impact:EC2/MaliciousDomainRequest.Reputation
Impact:EC2/MaliciousDomainRequest.Custom
Impact:EC2/PortSweep
Impact:EC2/SuspiciousDomainRequest.Reputation
Impact:EC2/WinRMBruteForce
Recon:EC2/PortProbeEMRUnprotectedPort
Recon:EC2/PortProbeUnprotectedPort
Recon:EC2/Portscan
Trojan:EC2/BlackholeTraffic
Trojan:EC2/BlackholeTraffic!DNS
Trojan:EC2/DGADomainRequest.B
Trojan:EC2/DGADomainRequest.C!DNS
Trojan:EC2/DNSDataExfiltration
Trojan:EC2/DriveBySourceTraffic!DNS
Trojan:EC2/DropPoint
Trojan:EC2/DropPoint!DNS
Trojan:EC2/PhishingDomainRequest!DNS
UnauthorizedAccess:EC2/MaliciousIPCaller.Custom
UnauthorizedAccess:EC2/MetadataDNSRebind
UnauthorizedAccess:EC2/RDPBruteForce
UnauthorizedAccess:EC2/SSHBruteForce
UnauthorizedAccess:EC2/TorClient
UnauthorizedAccess:EC2/TorRelay

　

EC2のfinding typeはAWS公式ドキュメントで確認できます。(GuardDuty EC2 finding typesより)

　

このように、検出結果タイプはある程度パターン化されています。

　

そのため、事前にそれぞれの内容を確認し、「即時対応」「要確認」「原則アーカイブ可」などの運用ルールを定めておけば、日々の運用でも十分に回しやすくなります。

　

さらに、EC2に関しては対象サーバーを、

　

  • 重要サーバー
  • 非重要サーバー
  • インターネット接続あり / なし
  • 外部公開あり / なし

　

などで分類しておくと、より現実的な判断がしやすくなります。

　

たとえば、同じMediumの検出結果でも、重要な本番サーバーで発生した場合と、検証用の一時的なサーバーで発生した場合では、優先度が変わるはずです。

　

　

まとめ：私なりの結論

Amazon GuardDutyの検出結果に対して、対処要否を判断する際に大切なのは、重要度のラベルだけで機械的に判断しないことだと感じました。

　

Critical / Highは即時対応を前提にしつつ、Medium / Lowについては次の観点で判断するのが現実的です。

　

  1. 検出結果タイプは何か
  2. 影響を受けたリソースは何か
  3. そのリソースは重要か
  4. 想定内の動作か、それとも逸脱か
  5. 事前に定めた運用ルールに照らしてどう扱うか

　

つまり、GuardDutyのトリアージを安定して回すには、事前準備が重要ということです。

　

通知が来てから毎回悩むのではなく、検出結果タイプごとの対応方針をあらかじめ整理しておくことで、運用負荷を下げつつ判断のばらつきも減らせます。

　

GuardDutyを有効化して終わりではなく、検出結果をどう扱うかまで設計しておくことが、実運用では大切なのだと思います。

　

　

参考リンク:AWS公式ドキュメント、AWS Black Belt Online Seminar

　

　

↓ほかの協栄情報メンバーのセキュリティについての記事を公開しています。ぜひ参考にしてみてください。
　

　
■そのチャットボット本当に安全？生成AIセキュリティ勉強会に参加してみた(齊藤弘樹)

　
■「情報セキュリティ10大脅威 2026」が発表されたので確認してみた(齊藤弘樹)

　

　

　

Last modified: 2026-03-28

Author