🛡️ GuardDuty 抑制ルール

Suppression Rule で「オオカミ少年」問題を解決!

AWS Security Services

💡 たとえ話で理解しよう

🏢 ビルの警備員さんに例えると...

GuardDutyは 24時間体制のセキュリティ警備員 のようなものです。 不審な人物を見つけると、すぐに報告してくれます。

しかし、毎日来る 清掃業者さん 定期便の配達員さん まで 「不審者発見!」と報告されたら、本当に危険な時に気づけなくなりますよね?🤔

そこで登場するのが 抑制ルール(Suppression Rule) ! これは警備員さんに渡す 「顔パスリスト」 のようなものです。

「この人は毎日来る清掃業者さんだから、いちいち報告しなくていいよ」と 事前に教えておくことで、 本当に重要なアラートだけに集中 できるようになります!✨

📊 抑制ルールの仕組み

🔍
GuardDuty
脅威を検出
🚨
Finding
(検出結果)生成
📋
抑制ルールで
フィルタリング
📦
マッチ → 自動アーカイブ
(非表示)
または
🔔
マッチしない → 通常表示
(要対応)
❌ 抑制ルールなし
  • 🔔 ポートスキャン検出(開発テスト)
  • 🔔 異常なAPIコール(自動化ツール)
  • 🔔 不正ログイン試行 ⚠️ 重要!
  • 🔔 DNS異常(内部DNS)
  • 🔔 EC2外部通信(正規バックアップ)

😵 ノイズが多くて重要なアラートを見逃す!

✅ 抑制ルールあり
  • 📦 ポートスキャン → 自動アーカイブ
  • 📦 異常なAPIコール → 自動アーカイブ
  • 🔔 不正ログイン試行 ⚠️ すぐ対応!
  • 📦 DNS異常 → 自動アーカイブ
  • 📦 EC2外部通信 → 自動アーカイブ

😊 本当に重要なアラートに集中できる!

⚙️ 抑制ルールの動作ステップ

1

ルールを作成

「この条件に合うFindingは重要じゃない」というフィルター条件を設定します。検出タイプ、重大度、リソースなどで指定可能。

2

Finding生成時に照合

GuardDutyが新しい脅威を検出してFindingを生成すると、自動的に抑制ルールと照合されます。

3

マッチしたら自動アーカイブ

ルールにマッチしたFindingは自動的にアーカイブ状態に。コンソールのデフォルト表示から除外されます。

4

いつでも確認可能

アーカイブされたFindingは削除されません。フィルターを変更すればいつでも確認できます。

🎯 フィルタリングできる条件

📝

Finding Type

検出タイプで絞り込み
例: Recon:EC2/PortProbeUnprotectedPort

⚠️

Severity

重大度で絞り込み
Low / Medium / High

🖥️

Resource Type

リソース種類で絞り込み
EC2 / S3 / IAM など

🏷️

Resource Tags

タグで絞り込み
Environment: dev など

🌐

IP Address

送信元/宛先IPで絞り込み
特定のIPを除外

🔑

Account ID

AWSアカウントで絞り込み
マルチアカウント環境向け

💼 よくある使用シーン

🧪 開発環境のテスト活動

シナリオ
開発チームがペネトレーションテストを実施。大量のポートスキャン検出が発生。
Finding Type: Recon:EC2/*
Resource Tag: Environment = dev

🤖 自動化ツールの正常動作

シナリオ
CI/CDパイプラインやバックアップツールによるAPI呼び出しが異常検出される。
Finding Type: UnauthorizedAccess:IAMUser/*
Principal: automation-role

🏢 既知の社内IPアドレス

シナリオ
オフィスのNAT GatewayからのアクセスがTor/VPNとして誤検出される。
Finding Type: UnauthorizedAccess:*
Service.Action.NetworkConnectionAction
.RemoteIpDetails.IpAddressV4 = 203.0.113.10

📊 低重大度の大量アラート

シナリオ
Lowレベルの検出結果が大量に発生し、重要なアラートが埋もれる。
Severity: Low
※ 慎重に使用すること!

⚠️ 注意すべきポイント

🙈 過剰な抑制は危険

抑制ルールを広く設定しすぎると、本当の脅威も見逃す可能性があります。最小限の範囲で、具体的な条件を設定しましょう。

📝 定期的なレビュー

環境は変化します。設定した抑制ルールが今でも適切か、定期的に見直しましょう。不要になったルールは削除を。

🗂️ アーカイブは削除ではない

抑制されたFindingは削除されず、アーカイブに残ります。必要に応じてフィルターを変更して確認できることを覚えておきましょう。

🔄 EventBridgeとの関係

抑制されたFindingも、EventBridgeには送信されます。EventBridge側でも同様のフィルタリングが必要な場合があります。

✨ ベストプラクティス

具体的な条件を設定

「すべてのLow重大度を抑制」ではなく、「特定のFinding Typeで、特定のリソースに対するものだけ」のように具体的に指定しましょう。

理由を説明に記載

抑制ルールには説明(Description)を必ず追加。なぜこのルールが必要なのか、誰が承認したのかを記録しておきましょう。

タグを活用

リソースに適切なタグを付けておくことで、環境(dev/prod)や用途に基づいた柔軟な抑制ルールが作成できます。

アーカイブを定期確認

月に一度など、アーカイブされたFindingを確認する運用を入れましょう。想定外のものが抑制されていないかチェック。

💻 抑制ルールの作成例

AWS CLI
# 開発環境のポートスキャン検出を抑制
aws guardduty create-filter \
    --detector-id 12abc34d567e8fa901bc2d34e56789f0 \
    --name "SuppressDevPortScan" \
    --description "開発環境のペネトレーションテストによる検出を除外" \
    --action ARCHIVE \
    --finding-criteria '{
        "Criterion": {
            "type": {
                "Eq": ["Recon:EC2/PortProbeUnprotectedPort"]
            },
            "resource.tags.value": {
                "Eq": ["development"]
            }
        }
    }'
CloudFormation
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  DevSuppressionRule:
    Type: AWS::GuardDuty::Filter
    Properties:
      DetectorId: !Ref GuardDutyDetector
      Name: SuppressDevEnvironment
      Description: 開発環境の低重大度アラートを抑制
      Action: ARCHIVE
      Rank: 1
      FindingCriteria:
        Criterion:
          severity:
            Lt:
              - 4  # Low severity (1-3)
          resource.resourceType:
            Eq:
              - Instance
          resource.tags.value:
            Eq:
              - dev

📌 まとめ

🎯

目的

既知の誤検知や許容されているアクティビティをフィルタリングし、重要なアラートに集中

⚙️

仕組み

条件にマッチしたFindingを自動的にアーカイブ状態にする(削除はしない)

🔑

ポイント

具体的な条件設定・定期的なレビュー・理由の記録を忘れずに

💼

活用シーン

開発テスト・自動化ツール・既知IPアドレスなど、正当なアクティビティの除外に最適

Created by SSuzuki1063

AWS SAP Learning Resources