2026.03.25

[AWS]Amazon GuardDutyで検知した脅威情報をAmazon SNSでEメール通知

こんにちは。植松です。
久しぶりの投稿となります。

AWSを運用していると色んなサービスを使う方は多いと思います。各サービスにて異常を検知した際、どのように運用管理者は知る運用にしていますか？
今回はGuardDutyを使って脅威を検出し、SNSを使って通知を行う仕組みをご紹介します。

GuardDuty（脅威検出）→ EventBridge（イベントルーティング）→ SNS（Eメール通知）

1. Amazon GuardDutyとは

Amazon GuardDutyは、AWSアカウント内の脅威を継続的にモニタリングするマネージド型の脅威検出サービスです。以下のようなデータソースを自動的に分析し、不審なアクティビティを検出してくれます。

AWS CloudTrail管理イベント -- APIコールの異常（不正なリージョンからの操作、普段使わないAPIの呼び出しなど）
VPC Flow Logs -- ネットワークトラフィックの異常（ポートスキャン、C&Cサーバーへの通信など）
DNS Logs -- 不審なドメインへの名前解決リクエスト

GuardDutyが検出した脅威は「Finding（検出結果）」として記録され、それぞれに重要度（Severity）が付与されます。

Low（1.0〜3.9） -- 偵察行為など、すぐに対処が不要なもの
Medium（4.0〜6.9） -- 不審な動作。調査が推奨されるもの
High（7.0〜8.9） -- 侵害の可能性が高く、早急な対応が必要なもの

ポイントは、GuardDuty自体は検出のみを行い、通知や自動修復の機能は持っていないという点です。そのため、検出結果を運用者に届けるには、EventBridgeやSNSと組み合わせる必要があります。

GuardDutyの保護対象とオプション保護プラン

上記の基盤データソースに加え、GuardDutyにはオプションの保護プランが用意されています。有効化することで、より広い範囲の脅威を検出できます。

保護プラン	対象	検出内容の例
S3 Protection	Amazon S3	不審なデータアクセス、バケットポリシーの改ざん
EKS Protection	Amazon EKS	Kubernetes監査ログの異常、コンテナへの攻撃
Runtime Monitoring	EC2 / EKS / ECS	OS レベルの不審なプロセス実行
RDS Protection	Aurora / RDS	不審なログイン試行（ブルートフォースなど）
Lambda Protection	AWS Lambda	Lambda関数のネットワーク通信の異常
Malware Protection	EC2（EBS）/ S3	マルウェアの検出

ALBやWAFの脅威検知について

「GuardDutyでALB（Application Load Balancer）やAWS WAFの脅威も検知できるのでは？」と思われるかもしれませんが、GuardDutyがWAFのログ（どのリクエストをブロックしたか等）を直接データソースとして取り込むことはありません。SQLインジェクションやXSSといったHTTPリクエストの中身を検査するのは、あくまでWAF自身の役割です。

ただし、GuardDutyはCloudTrailやVPC Flow Logsを通じて、WAF周辺の異常を間接的に検知することができます。

観点	GuardDutyの役割
WAFが止めたHTTPリクエストの中身（SQLi、XSSなど）	見ない（WAF自身の領域）
WAFの設定変更（CloudTrail経由）	不審な操作として検知できる（例：普段使わないIAMユーザーがWebACLを削除・変更した場合など）
WAFを通過した後のネットワーク異常（VPC Flow Logs経由）	検知できる（例：C&Cサーバーへの通信、異常なポートスキャンなど）

つまりGuardDutyは「WAFが止めたログ」そのものを見るのではなく、「WAFを通り抜けようとする動き」や「WAFの設定自体をいじろうとする不正操作」を別ルート（CloudTrailやVPC Flow Logs）から監視しているイメージです。

とはいえ、Webアプリケーション層の防御はGuardDutyだけではカバーしきれないため、以下のサービスとの併用を検討してください。

AWS WAF -- SQLインジェクションやXSSなどのWebアプリケーション攻撃をルールベースでブロック・検知
AWS Shield Advanced -- DDoS攻撃の検出と自動緩和（ALB/CloudFront/Route 53などが対象）
AWS Firewall Manager -- 複数アカウント・リソースのWAFルールを一元管理

GuardDutyは「インフラ・アカウントレベルの脅威検出」、WAF/Shieldは「Webアプリケーションレベルの防御」と守備範囲が異なります。両方を組み合わせることで、より包括的なセキュリティ体制を構築できます。

2. GuardDutyの有効化とメール通知の設定

ステップ1：GuardDutyを有効化する

AWSマネジメントコンソールで「GuardDuty」を検索して開く
「今すぐ始める」→「GuardDutyの有効化」ボタンをクリック
これだけで有効化は完了です。30日間の無料トライアルが適用されます

※ GuardDutyはリージョン単位のサービスです。利用中のすべてのリージョンで有効化することを推奨します。

ステップ2：SNSトピックを作成する

SNSコンソールを開き、「トピックの作成」をクリック
タイプは「スタンダード」を選択し、名前を入力（例：guardduty-alerts）
トピック作成後、「サブスクリプションの作成」をクリック
プロトコルに「Eメール」を選択し、通知先のメールアドレスを入力
登録したメールアドレスに確認メールが届くので、リンクをクリックして承認する

ステップ3：EventBridgeルールを作成する

EventBridgeコンソールを開き、「ルールを作成」をクリック
名前を入力（例：guardduty-to-sns）
イベントパターンで「カスタムパターン」を選択し、以下のJSONを入力
ターゲットに先ほど作成したSNSトピックを指定

3. 通知の絞り込み（重要）

⚠ 注意：有効化直後、大量の「Low（重要度：低）」アラート（単なるポートスキャンなど）でメールボックスが埋まりました。これでは運用が回りません。

そこで、EventBridgeのイベントパターンを編集し、「Medium（中）」および「High（高）」以上（Severity 4.0以上）のみをメール通知対象にするようフィルタリングしました。

// EventBridgeのフィルタ例（Severity 4.0以上）
{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [
      { "numeric": [">=", 4] }
    ]
  }
}

これにより、真に対応が必要なアラートだけが届くようになりました。

フィルタリングの目安

重要度	Severity値	通知の推奨	例
Low	1.0〜3.9	コンソールで定期確認	ポートスキャン、偵察行為
Medium	4.0〜6.9	メール通知	不審なAPIコール、異常なトラフィック
High	7.0〜8.9	即時対応	暗号通貨マイニング、データ流出の兆候

まとめ

今回は、GuardDuty + EventBridge + SNS を組み合わせた脅威通知の仕組みを紹介しました。

GuardDutyは有効化するだけで脅威検出を開始してくれる手軽さが魅力
EventBridgeのフィルタリングで、通知の嵐を防ぐことが運用のカギ
Severity 4.0以上に絞ることで、対応が必要なアラートだけを受け取れる
ALB/WAFなどWebアプリケーション層の防御にはAWS WAFやShield Advancedとの併用が有効

特にGuardDutyは、複雑なログ解析を肩代わりしてくれるため、Webサービス運営者には必須のサービスだと感じています。メール通知の嵐には注意が必要ですが、適切にフィルタリングすれば強力な味方になります。

次のステップとして、Lambda連携による自動修復（例：不審なIPをセキュリティグループでブロック）なども検討してみると、さらに運用が楽になるかもしれません。

ITブログの一覧に戻る