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) になれば完了です。

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 リストに関する重要な考慮事項
コメント