Amazon GuardDuty カスタムエンティティリスト強化で実現するノイズ低減と検知精度向上 – 設定・自動化・検証手順

GuardDuty Custom Entity Lists の概要

2025 年 9 月のアップデートで Amazon GuardDuty に Custom Entity Lists (Trusted / Threat) が追加され、従来の IP (単一 / CIDR) リストに加えてドメイン指定がサポートされました。これにより SaaS / CDN 由来の頻繁な IP 変動でも安定して誤検知 (False Positive) を抑制しつつ、既知悪性指標を組織特性に合わせて柔軟に反映できるようになりました。

Enhancing threat detection with Amazon GuardDuty new custom entity lists

GuardDuty 導入前に顕在化していた課題

誤検知ノイズの蓄積はアナリストのアラート疲労を招き、IP ベース運用の限界はクラウドネイティブ/SaaS 依存度の高まりとともに年々顕在化、さらに属人的なリスト更新プロセスが改善サイクル遅延を生み出していました。

課題 影響 典型症状
誤検知ノイズ アラート疲労 信頼 SaaS ドメインへの頻繁な検知
IP 依存 表現力不足 CDN / マルチリージョン分散で IP 可変
更新遅延 対応遅れ リストメンテが属人化

GuardDuty Custom Entity Lists 適用後の改善効果

「ドメイン許可」によるホワイトリスト管理単純化は初期効果が出やすく、「精度向上」による誤検知率低下は長期的に分析リソースの再配分を可能にし、「運用自動化」は継続的な脅威インテリジェンス反映のリードタイムを短縮します。

改善領域 具体効果 運用インパクト
ドメイン許可 SaaS / API ホワイトリスト管理が単純化 ノイズ削減 → MTTA/MTTR 短縮
精度向上 自社固有リソースを考慮した検知 誤検知率低下で分析リソース最適化
運用自動化 S3 オブジェクト更新反映 CI/CD 連携で日次更新可能

GuardDuty Trusted / Threat 利用パターン

  • Trusted Entity Lists: 業務必須 SaaS (*.enterprise-saas.com 等) を許可し誤検知ノイズを抑制
  • Threat Entity Lists: 外部 Threat Intel フィードを日次同期し新規悪性ドメインを即時反映

GuardDuty Custom Entity Lists 設定手順

1. エンティティリストの準備

エンティティリストは以下の形式をサポートしています。

  • プレーンテキスト(TXT)
  • 構造化脅威情報表現(STIX)
  • オープン脅威交換 (OTX)TM CSV
  • FireEye™ iSIGHT 脅威インテリジェンス CSV
  • ProofpointTM ET インテリジェンスフィード CSV
  • AlienVaultTM レピュテーションフィード

各ドキュメントの詳細は以下ページに例があります。
エンティティリストと IP アドレスリストを使用した脅威検出のカスタマイズ – Amazon GuardDuty

今回は TXT 形式で登録してみましょう。

trusted-domains.txt (例)

allowed-saas.com
corporate-tool.net
192.0.2.0/24

2. S3 へ配置

  • バケット: sec-reference-lists
  • パス例: guardduty/trusted/trusted-domains.txt

実運用にあたっては、定義ファイルを配置する S3 バケットはバージョニングの有効化などを行い、変更履歴を追跡できるようにしましょう。

3. GuardDuty コンソール / API 登録

aws guardduty create-trusted-entity-set \
  --detector-id  \
  --name trusted-domains \
  --format TXT \
  --location s3://sec-reference-lists/guardduty/trusted/trusted-domains.txt \
  --activate

ディテクター ID はGuardDuty コンソールの設定ページから確認できます

実行例

~ $ aws guardduty create-trusted-entity-set \
>   --detector-id  \
>   --name trusted-domains \
>   --format TXT \
>   --location s3://sec-reference-lists/guardduty/trusted/trusted-domains.txt \
>   --activate
{
    "TrustedEntitySetId": "d3e47ea9c8f34f7496dc10757e5d206f"
}

4. 有効化と状態確認

aws guardduty get-trusted-entity-set \
  --detector-id 123456789abcdefg \
  --trusted-entity-set-id d3e47ea9c8f34f7496dc10757e5d206f

実行結果例

~ $ aws guardduty get-trusted-entity-set \
> --detector-id  \
> --trusted-entity-set-id 
{
    "Name": "trusted-domains",
    "Format": "TXT",
    "Location": "s3://sec-reference-lists/guardduty/trusted/trusted-domains.txt",
  "ExpectedBucketOwner": "",
    "Status": "ACTIVE",
    "Tags": {},
    "CreatedAt": "2025-09-09T07:32:39+00:00",
    "UpdatedAt": "2025-09-09T07:32:39+00:00"
}

GuardDuty Threat Entity の挙動確認

example.com を脅威として設定し、検知させてみようと思います。

以下のエンティティリストを脅威として登録します。

threat-list.txt

example.com

脅威を登録する際には create-threat-entity-set を利用します。

aws guardduty create-threat-entity-set \
  --detector-id  \
    --name threat-domains \
    --format TXT \
    --location s3://sec-reference-lists/guardduty/threat/threat-domains.txt \
    --activate

実行結果

~ $ aws guardduty create-threat-entity-set \
>     --detector-id  \
>     --name threat-domains \
>     --format TXT \
>     --location s3://sec-reference-lists/guardduty/threat/threat-domains.txt \
>     --activate
{
    "ThreatEntitySetId": "f0d2e0c8cd6e4b5eb5c55d245c232376"
}

状態確認

登録状況はGuardDuty コンソールのリストページからも確認できます。

ステータスが Active (ACTIVE) になれば完了です。

Activate!

EC2 を立てて example.com 宛に通信を行います。

[ec2-user@ip-172-31-33-66 ~]$ curl example.com --head
HTTP/1.1 200 OK
Content-Type: text/html
ETag: "84238dfc8092e5d9c0dac8ef93371a07:1736799080.121134"
Last-Modified: Mon, 13 Jan 2025 20:11:20 GMT
Cache-Control: max-age=86000
Date: Tue, 09 Sep 2025 08:23:11 GMT
Connection: keep-alive

GuardDuty の検出結果ページにカスタム脅威リストでの検知が確認できれば成功です。

GuardDuty で脅威 (Threat) と信頼 (Trusted) が競合した場合の優先順位

結論

信頼設定が優先されます。
エンティティリストと IP アドレスリストを使用した脅威検出のカスタマイズ – Amazon GuardDuty

信頼されたリストと脅威リストの両方に同じ IP アドレスまたはドメインを含める場合、信頼されたリストのこのエントリが優先されます。このエントリに関連付けられたアクティビティがある場合、GuardDuty は結果を生成しません。

検証

trust-entity-list.txt と threat-entity-list.txt を用意し、登録します。
両ファイルには同じドメインを設定します。

trust-entity-list.txt

serverworks.co.jp

threat-entity-list.txt

serverworks.co.jp

serverworks.co.jp にアクセスして、検出結果が生成されるか確認します。

~ $ curl serverworks.co.jp --head
HTTP/1.1 301 Moved Permanently
Date: Tue, 09 Sep 2025 08:59:44 GMT
Server: Apache
Location: https://serverworks.co.jp/
Content-Type: text/html; charset=iso-8859-1

検出結果が生成されていないため、想定通りの動作となります。

まとめ (GuardDuty カスタムエンティティ活用ポイント)

以上、GuardDuty で設定可能になったカスタム許可リスト・カスタム脅威リストについて確認してきました。
環境で利用している SaaS との通信が検知されてしまっている場合に、ドメイン指定で許可セットを指定できるのは便利ですね。
これによって定期的に SaaS の IP アドレスを確認し、許可 IP セットを更新するような運用が不要になります。
現在 GuardDuty への対応で、SaaS の IP が検出されてしまう、自社のサービスが検出されてしまう等の事象にお悩みの方がいらっしゃいましたら、ぜひカスタムエンティティリストを試してみてください!

注意点

  • 信頼 (Trusted) リストは最小限に保ちましょう。過剰なワイルドカード (例: *.com, *.*) や広すぎるトップレベルドメイン配下一括許可は検知抜けリスクを高めます。推奨は (1) 具体的な FQDN 単位、(2) ワイルドカードを使う場合でもサブドメイン 1 階層程度に限定し、四半期ごとに棚卸しを行う。無効化候補は「直近 N 日アクセス無し」「対応するビジネスオーナー不在」など定量条件で抽出することが望ましいです。
  • リスト更新時は Git 等で差分レビューし、S3 アップロード前に重複 / 無効フォーマット / 想定外ワイルドカードを CI で検証するガードレールを設けると事故抑止になります。
  • エンティティリスト・IP アドレスリストの変更反映には一般的に 15 分ほど、最大で 40 分かかります。
    エンティティリストと IP アドレスリストを使用した脅威検出のカスタマイズ – Amazon GuardDuty

    エンティティリストまたは IP アドレスリストを有効化、無効化、または削除した後、このプロセスは 15 分以内に完了すると予想されます。状況によっては、このプロセスが完了するまでに最大 40 分かかる場合があります。

その他の考慮事項に関しては以下のドキュメントに記載があります。
エンティティリストと IP アドレスリストを使用した脅威検出のカスタマイズ – GuardDuty リストに関する重要な考慮事項

参考リンク

手嶋 凌一朗 (記事一覧)

エンタープライズクラウド部・クラウドリライアビリティ課

書きたい心はあるんです。

趣味はテニスと釣り




Source link

関連記事

コメント

この記事へのコメントはありません。