〜GuardDuty連携・EventBridge通知・検証方法までまとめ〜
AWS Security Hub と GuardDuty を組み合わせて、
AWS環境の脅威を統合監視し、Slack/メールへ自動通知する仕組みを構築した際の手順・検証内容をまとめました。
Security Hub/GuardDuty が初めての方でも、
検知→通知→対応の一連の流れ を理解できます。
📌 1. Security Hubとは?
AWS Security Hub は、AWS内の複数サービスから
セキュリティイベント(Findings)を統合管理するプラットフォーム です。
特に下記のサービスと相性がよく、実質 “セキュリティの司令塔” の役割になります。
| 連携サービス | 役割 |
|---|---|
| GuardDuty | 脅威検知(攻撃・侵入の兆候) |
| Inspector | 脆弱性スキャン |
| Config | 設定変更・準拠性違反の検知 |
| Macie | S3 の機密データ検出 |
Security Hub は 自身では防御行為は行いません。
かわりに GuardDuty/Inspector などが検知したイベントを集約し、
- 重要度(Severity)
- 影響範囲(Resources)
- 発生元サービス
などを横断的に管理しやすくなる仕組みです。
📌 2. Security Hub の有効化
AWSコンソール → Security Hub を開き、
[有効化]ボタンを押すだけで利用開始 できます。
※注意
初期画面には「委任された管理者アカウント」の設定項目が出ますが、単一アカウントでの利用なら設定不要です。
マルチアカウント統合(Organizations)を使う場合だけ設定します。
📌 3. GuardDutyとの連携(自動)
Security Hubを有効化すると、
- GuardDuty
- Inspector
- Config
などのセキュリティサービスは 自動的に統合対象として登録 されます。
実際、Security Hub ダッシュボードの「セキュリティカバレッジ」で
GuardDuty が “カバーされています” と表示されていれば正常に連携済みです。
📌 4. サンプル検出(Sample Findings)の作成
Security Hubで検知の流れを確認するには、
GuardDuty のサンプル検出を利用するのが最も確実 です。
▶ GuardDuty 側でサンプル検出を作成
aws guardduty create-sample-findings \
--detector-id <DETECTOR_ID>
※ 検知器ID(DETECTOR_ID)は下記で取得できます:
aws guardduty list-detectors
実行すると GuardDuty の「検出結果」に大量のテストイベントが生成されます。
※ これらはサンプルになります。
📌 5. Security Hub 側でサンプルを確認
Security Hub → 検出結果 にて次のようなイベントが現れます:
- C2通信(Command & Control)
- 不正APIコール
- RDSに対する不正プロービング
- 不審なDNS問い合わせ
- IAM資格情報の窃取疑い
など、GuardDuty の全Findingが Security Hub 側へ取り込まれます。
📌 6. EventBridge 経由で通知ルールを作成
Security Hub単体では通知機能は持たないため、
EventBridge → SNS → Slack/メール などの経路で通知します。
▶ EventBridgeルール作成(コンソール)
- EventBridge → ルール作成
- “イベントパターン” を選択
- 以下のような設定にする:
{
"source": ["aws.securityhub"],
"detail-type": ["Security Hub Findings - Imported"],
"detail": {
"findings": {
"Severity": {
"Label": ["HIGH", "CRITICAL"]
}
}
}
}
重要度 High / Critical のみ通知 するフィルタです。
▶ ターゲットに SNS を設定
- SNSトピック
- メール通知 or Slack(Lambda)など
を紐付ければ即時通知が可能になります。
📌 7. SNSメール通知の確認
EventBridge → SNS → メール のフローが正しく構成されていれば、
Security Hub 経由で GuardDutyの検知が メールで届きます。
大まかなメール例:
Finding Imported V2
An IP address that is associated with known malicious activity probed an RDS instance …
Severity: HIGH
Service: GuardDuty
📌 8. Security Hub を使った運用例(実務向け)
Security Hub+GuardDutyを導入しただけでは十分ではありません。
実運用にするには以下のようなルール作りが必要です。
▶ ① 即時対応するべき検知(Critical/High)
- IAM資格情報漏えい
- EC2からC2通信
- RDSへの不審プローブ
- API連打(ブルートフォース)
→ Slackまたはメールに即時通知
→ IAM無効化 / SG遮断 / インスタンス隔離 などを実施
▶ ② Medium以下は定期レビュー
- 不審ドメインアクセス
- 小規模な設定変更
- スキャン試行
→ 月次レビューで問題ない
→ GuardDuty側のフィルタでノイズ削減しても良い
▶ ③ 最新の防御ルールへ反映
- WAFへの遮断ルール追加
- SGの改善
- IAM権限見直し
- Inspectorの脆弱性修正
Security Hubは 検知のハブ であり、
実際の防御は WAF / IAM / SG / Config が担当します。
📌 9. Security Hub・GuardDuty・他サービスの役割まとめ(図)
【外部トラフィック層】──▶ AWS WAF / Shield
│
【ネットワーク層】──▶ GuardDuty(VPC Flow Logs / DNS)
│
【ホスト層】──▶ Inspector(脆弱性診断)
│
【データ保護層】──▶ Macie(S3 機密情報)
│
【構成・準拠性層】──▶ AWS Config
│
【統合管理層】──▶ Security Hub(Findings統合)
│
【操作監査層】──▶ CloudTrail(API監査ログ)
📌 10. まとめ
本記事では Security Hub の導入から GuardDuty連携、
EventBridge通知、検証方法までを実際の操作ベースで整理しました。
✔ 押さえるべきポイント
- Security Hub は 検知の統合ビュー
- GuardDutyの Findings を自動取り込み
- EventBridge + SNS で通知自動化が可能
- High / Critical のみを通知し運用負荷を軽減
- Slack/メールで実運用に組み込める
Security Hub を導入するだけで
AWSのセキュリティ監視が “見える化” され、優先順位づけも簡単になります。


