はじめに
想定読者
- 脅威検出・ふるまい検知についての基本知識はあり、GuardDutyの仕様を知りたい人
- GuardDutyを既に利用している/基本的な機能は知っていて、脅威検出の仕組みを知りたい人
記事の目的
「AWSのエンドポイントセキュリティ、AWSサービスだけで実現できる？Inspector/GuardDutyとEDRの役割分担を整理してみた」をまとめるにあたり、EDRとGuardDutyの違いの解像度を高めるために、以下の項目についてGuardDutyの仕様を調査しました。
- 脅威検出までのタイムラグ
- 正確性（誤検知への対処）
- 網羅性（脅威検出の対象範囲）
同様の疑問がある方のお役にたつと幸いです。
Amazon GuardDutyの機能概要
Amazon GuardDutyはAWSアカウント内を継続的にモニタリングし、悪意ある操作や不正な動作などの脅威を検知するサービスです。独自の機械学習モデルとセキュリティベンダーから提供される脅威インテリジェンスによって、AWSアカウント内の各種ログデータを分析します。
では、GuardDutyによる脅威検出はどれくらいリアルタイムなのか？誤検知は発生しないのか？他のAWSサービスとは何が違うのか？といった点を、公式ドキュメントをもとに調査しました。
GuardDutyがサポートするAWSサービス
GuardDutyでは、以下のAWSサービス上の脅威を検知可能です。
2025/12時点：GuardDuty とは
- AWSアカウント全体
- 特定サービスに限らないアカウントレベルでの不審な挙動
- AWS IAM
- Amazon EC2
- Amazon ECS
- Amazon EKS
- AWS Lambda
- Amazon S3
GuardDutyの基本機能と専用の保護プラン
GuardDutyは登場以降も機能が拡張され続けており、現在はAWSアカウント全体をカバーする「基本機能」と特定のリソース専用の「保護プラン（オプション）」の2種類があります。本記事では「基本機能」について調査した結果をまとめています。
- 基本機能
- 主に「AWSアカウント全体」、「IAM」、「EC2」の脅威検出を行う
- 保護プラン
- 現在7種類の保護プランがあり、保護したいサービス/ユースケースごとに使い分ける
保護プランと対応するAWSサービス、ユースケースは以下の通りです。
| 保護プラン | 対応するAWSサービス | ユースケース |
|---|---|---|
| Malware Protection for EC2 |
Amazon EC2 (Amazon EBS) |
EC2にアタッチされているEBSボリュームのマルウェアを検出 |
| Runtime Monitoring |
Amazon ECS Amazon EKS Amazon EC2 |
OSレベルのイベントを分析して、ランタイム脅威を検出 |
| EKS Protection | Amazon EKS | Amazon EKS クラスターで記録された Kubernetes 監査ログを分析して、不審な挙動を検出 |
| Lambda Protection | AWS Lambda | VPC内で実行されるLambda関数の通信ログを分析し、不審な通信を検出 |
| RDS Protection |
Amazon RDS (Amazon Aurora) |
ログインに関するログを分析し、不審なアクセスを検出 |
| S3 Protection | Amazon S3 | S3に対する不審な操作を検出 |
| Malware Protection for S3 | Amazon S3 | S3にアップロードされたオブジェクト内に存在するマルウェアを検出 |
1. GuardDutyによる脅威検知のタイムラグ
攻撃者が侵入した場合、データを持ち出されたり攻撃される前に検知・遮断できることが重要になります。GuardDutyの場合、実際のイベント発生から脅威検出するまでどれくらいのタイムラグがあるのか、公式ドキュメントで確認してみましたが、明確な情報は公開されていないようでした。
各種ログを解析し、その結果から脅威検出を行うという方式を踏まえると、それらのログの生成・送信・分析の時間がかかるため、数分以上はかかる可能性が高いです。
2. GuardDutyによる脅威検知の誤検知
GuardDutyは普段のAWSアカウントの使用状況を学習したうえで「異常検知」を行うため、正当な業務オペレーションであっても「普段と違う動き」をすると、脅威として検出されてしまう可能性があります。そこで、誤検知されやすいケースとその抑制方法を確認しました。
誤検知が起きやすいシナリオと対策
正常なオペレーションとして普段と異なるアクセスが発生するケースとして、以下のシナリオが考えられます。
-
負荷テスト
特に開発中のように稼働リソースが少ない状態で、テストのために急に数十～数百のEC2を起動した場合、異常な振る舞いとして検出される可能性がある（UnauthorizedAccess:EC2/SSHBruteForce等）
-
セキュリティテスト
特に脆弱性診断などで自社の端末からポートスキャンなどを行った場合、悪意ある攻撃として検出される可能性が高い（Recon:EC2/Portscan等）
-
アクセス端末の変更
開発フェーズに伴うアクセス元拠点の変更やオフショアの利用、出張などで普段アクセスしない場所・時間などからEC2にアクセスすると、不審なアクセスとして検出される可能性がある（Behavior:EC2/NetworkPortUnusual等）
GuardDutyを利用する場合、ほとんどのケースで脅威が検出されたら、アラートで通知するようにしていると思います。そのため、誤検知によるアラートは運用者にとってノイズとなってしまいますが、「信頼済みIPリスト」と「抑制ルール」の利用によって誤検知を抑制することができます。
信頼済みIPリスト
「信頼済みIPリスト」に登録したIPアドレスからのアクセスは、GuardDutyによる脅威検出の対象から除外されます。自社拠点のIPアドレスなどを登録しておくことで、負荷テストやセキュリティテストを実施した場合の誤検知を抑制することができます。
IPリストの記述はプレーンテキストを含めて現在6種類がサポートされています。
- プレーンテキスト (TXT)
- 脅威情報構造化記述形式 (STIX)
- Open Threat Exchange (OTX)TM CSV
- FireEyeTM iSIGHT 脅威インテリジェンス CSV
- ProofpointTM ET Intelligence Feed CSV
- AlienVaultTM Reputation Feed
TXT以外は脅威情報を共有するために規格化されたフォーマットです。自社内で信頼するIPアドレスを指定する際にはTXTで十分なケースが多いでしょう。
なお、信頼済みIPリストは名前の通りIPアドレスの登録のみがサポートされていましたが、2025年9月のアップデートにより、IPアドレスとドメインをサポートする「エンティティリスト」が利用可能になっています。
News Amazon GuardDuty の新しいカスタムエンティティリストによる脅威検出の強化
現在は「エンティティリスト」の利用が推奨されています
抑制ルール
抑制ルールを使用すると、特定の条件の検出結果を自動でアーカイブ（非アクティブ化） します。アーカイブされた検出結果は通知されないため、誤検知による運用負荷を軽減する効果が見込めます。
以下のような属性を使って条件指定できるため「セキュリティテストを実施するEC2に特定のタグを付与して、そのタグがついたリソースの検出はアーカイブする」といった形で誤検知を抑制できます。
- リソースが所属するAWSアカウント
- リソースが存在するリージョン
- リソースのタグ など
なお、信頼済みリストに該当するアクセスは、そもそも脅威として検出されませんが、抑制ルールに該当するものは一度脅威として検出され、検出結果は残るという違いがあります。
3. GuardDutyによる脅威検知の対象範囲
GuardDutyが検出できる脅威はその仕組み上、「どのデータソースを入力としているか」に依存します。つまり、ログから情報が得られない範囲はGuardDutyでは検出できません。改めて、データソースについて確認してみました。
基本機能で分析される「データソース」
基本機能の場合、以下の3種類のログがGuardDutyによって分析されます。
-
AWS CloudTrail 管理イベント
- AWSアカウントに対する管理操作（コントロールプレーン操作）の履歴
-
VPCフローログ
- VPC内のIPトラフィックのログ
-
DNSクエリログ
- Route 53 Resolver宛のDNSリクエストのログ
GuardDutyが分析するログから考えると、CloudTrailに記録されないOS内部の操作やアプリケーションの挙動、VPCフローログに記録されないパケットの中身（ペイロード）の分析が必要な脅威はGuardDutyの検出範囲外となります。
OS内部の挙動については、Runtime Monitoringの利用により一部カバーされますので、それを踏まえてGuardDutyの分析・検出の対象範囲について整理しました。
| レイヤ | 分析対象 | 検出可能な脅威 | 分析対象外 | 検出できない脅威 |
|---|---|---|---|---|
| アプリケーション |
AWS APIコール (CloudTrail) 「誰が」AWSリソースに対して「何をしたか」の記録 |
・不正なコンソールログイン ・IAMロールの奪取 ・S3バケットの公開設定変更 ・セキュリティ設定の無効化 |
アプリ層のロジック・ログ Webアプリ固有のログイン試行、決済処理、業務操作ログ |
・Webアプリの管理者権限乗っ取り ・アプリ仕様の悪用（不正送金など） ・アプリ内での情報閲覧 |
| OS内部 |
プロセス/ファイルイベント (※Runtime Monitoring有効時) プロセス起動、ファイル変更、ネットワーク接続 |
・マルウェアの実行 ・権限昇格の試行 ・ランサムウェアの挙動 ・Webシェルの設置 |
標準機能でのOS内部ログ (※Runtime Monitoring無効時) OS内のコマンド履歴、ファイル操作ログ |
・OS内部での静かな権限昇格 ・ログ改ざん ・ファイルレスマルウェアの活動（検知設定による） |
| ネットワーク |
VPC Flow Logs (L3/L4) 送信元/先IP、ポート番号、パケット量、通信時間 |
・C&Cサーバーへの通信 ・ポートスキャン ・EC2へのSSHブルートフォース ・仮想通貨マイニング通信 |
パケットペイロード (L7) HTTPリクエストの中身、SQLクエリ、POSTデータ |
・SQLインジェクション ・XSS (クロスサイトスクリプティング) ・特定の脆弱性を突くWeb攻撃リクエスト |
GuardDutyが検出できない脅威への対策
GuardDutyだけで全レイヤーに対応することは想定されていません。他のサービスも組み合わせた多層防御を実装することが重要です。
GuardDutyがカバーしていない範囲については、以下のような対策が考えられます。
| 範囲 | セキュリティ対策 |
|---|---|
| アプリ層のロジック・ログ | CloudWatch（ログの取得） CloudWatch Insight/OpenSearch/SIEM製品（分析） |
| OS 内部 | EDR製品（3rdParty製品） |
| パケットペイロード (L7) | AWS WAF（脆弱性を狙った攻撃への対策） AWS Network Firewall（プロトコル異常・DPI） |
まとめ
GuardDutyの脅威検出のタイムラグ、発生しやすい誤検知と抑制方法、検出可能な範囲について、ドキュメントを紐解きながら仕様を整理しました。公式ドキュメントには明示されていない部分もありますが、GuardDutyの仕組みを理解することは適切なセキュリティ設計のために重要です。本記事がその一助になると幸いです。
関連記事
- 本調査の発端：
AWSのエンドポイントセキュリティ、AWSサービスだけで実現できる？Inspector/GuardDutyとEDRの役割分担を整理してみた
- 機能詳細編 Inspectorバージョン：
Amazon Inspectorスキャン機能詳細：ドキュメントから読み解くスキャンの仕組み