Amazon GuardDutyは、AWSアカウントやワークロードで起きている不審な活動を継続的に分析し、調査すべき兆候をFinding（検出結果）として知らせるマネージド脅威検知サービスです。
有効化すれば監視を始められますが、GuardDutyだけで攻撃を防いだり、侵害から自動復旧したりするわけではありません。通知先、担当者、確認手順、封じ込めの判断基準まで決めて、初めて検知を対応へつなげられます。
- GuardDutyが担うのは、不審な活動の検知と優先度付けです。
- Findingは侵害の確定判定ではなく、周辺状況を調べる出発点です。
- 自動化は通知と情報収集から始め、隔離や停止は検証済みの手順に限定します。
Amazon GuardDutyが担う役割
脅威検知とは、操作履歴や通信の特徴から、認証情報の悪用、不審なAPI操作、悪意のある通信などの兆候を見つけることです。GuardDutyはAWS側で分析基盤を運用するため、利用者が検知エンジンやログ収集サーバーを構築する必要はありません。
一方、GuardDutyはファイアウォールや脆弱性診断と同じ役割ではありません。通信を遮断するAWS WAFやセキュリティグループ、ソフトウェアの脆弱性を検出するAmazon Inspector、複数サービスのセキュリティ情報を集約するAWS Security Hubとは目的が異なります。役割の違いは、Amazon Inspector、GuardDuty、Security Hubの違いも参考になります。
| 工程 | GuardDutyが行うこと | 運用側が行うこと |
|---|---|---|
| 監視 | 対象データを継続的に分析する | リージョン、アカウント、保護範囲を確認する |
| 検知 | 不審な活動をFindingとして示す | 業務上の正当な操作か侵害の兆候かを調べる |
| 対応 | FindingをEventBridgeなどへ送る | 通知、封じ込め、復旧、再発防止を実行する |
分析対象とFindingの読み方
3つの基礎データソース
GuardDutyの基礎的な脅威検知では、次のデータを分析します。
- AWS CloudTrail管理イベント：誰がどの管理APIを呼び出したかを確認するための操作履歴です。
- Amazon VPC Flow Logsのデータ：ネットワークインターフェースを出入りする通信の情報です。
- Amazon Route 53 Resolver DNSクエリログ：AWSのDNSリゾルバーを利用した名前解決の記録です。
これらはGuardDutyを有効化すると分析が始まる基礎データソースです。AWSの説明では、既存のCloudTrailやVPC Flow Logsの設定をGuardDuty用に変更する必要はありません。追加の保護プランを利用する場合は分析対象が増えるため、対象リージョンで利用できる機能と有効化状態をGuardDutyの基礎データソースに関するAWS公式資料で確認してください。
Findingは調査の入口
Findingは、GuardDutyが調査対象として提示する検出結果です。対象リソース、Findingの種類、重大度、観測時刻などを手掛かりに、実際の操作履歴や通信、直前の変更を確認します。
重大度はCritical、High、Medium、Lowに分かれます。ただし、重大度だけで対応を決めると、業務影響や対象資産の重要性を取りこぼします。外部公開中の本番環境か、管理者権限に関わるか、同じ兆候が複数アカウントで起きているかも併せて判断します。区分と数値範囲はAWS公式の重大度レベルで確認できます。
導入前に決めておくこと
設定画面を開く前に、検知後の運用を決めておくと通知が放置されにくくなります。
- 監視範囲：どのAWSアカウントとリージョンを対象にするかを整理します。
- 保護範囲：基礎的な脅威検知に加え、どの保護プランが必要かを確認します。
- 通知先：勤務時間内と時間外の連絡先、チケットの担当グループを決めます。
- 初動時間：重大度と資産の重要性を踏まえ、確認を始める目安を決めます。
- 対応権限：認証情報の無効化やインスタンス隔離を誰が承認できるかを明確にします。
導入と初期設定の手順
- 対象リージョンでGuardDutyを有効化する
コンソールで有効化し、検出器が動作していることを確認します。複数アカウントでは、集約して運用する管理方法も先に決めます。 - 保護プランの状態を確認する
初回有効化時の状態は機能やリージョンによって変わり得るため、必要な保護だけが有効かを確認します。 - サンプルFindingで表示を確認する
実際の侵害を待たず、担当者がFindingの詳細画面と必要な項目を読めるかを試します。 - 通知経路を作る
GuardDutyのFindingをAmazon EventBridgeで受け、Amazon SNS、AWS Lambda、チケット管理など必要な宛先へつなぎます。設計の基礎はAmazon EventBridgeのルールとイベント連携で確認できます。 - 受信から初動まで通して試す
通知が届くだけでなく、担当者が対象リソースを特定し、連絡と記録を始められるところまで検証します。
Findingを受け取った後の初動
Findingを見つけたら、すぐにリソースを削除するのではなく、事実確認と被害拡大の防止を順に進めます。拙速な削除は調査に必要な記録を失わせる可能性があります。
- 対象を特定する：アカウント、リージョン、リソース、Findingの種類、最初と最後の観測時刻を確認します。
- 正当な変更と照合する：作業申請、デプロイ履歴、管理者の操作予定と突き合わせます。
- 影響範囲を調べる：関連する認証情報、通信先、同じ権限を持つリソースに範囲を広げます。
- 封じ込めを判断する：必要に応じて認証情報の無効化やネットワーク隔離を行います。業務停止の影響も考慮します。
- 証拠を保全して復旧する：ログやスナップショットなど調査に必要な情報を残し、原因を取り除いてから復旧します。
- 再発防止へつなげる：権限、公開範囲、通知条件、手順書を見直します。
| 場面 | 最初に確認すること | 対応例 |
|---|---|---|
| 通常と異なるAPI操作 | 実行主体、送信元、変更対象、直前の認証履歴 | 正当性を確認し、疑わしい認証情報を止めて影響範囲を調べる |
| 不審な外部通信 | 通信元リソース、宛先、開始時刻、同様の通信の有無 | 必要に応じて通信を制限し、ログとディスクの状態を保全する |
| ポート探索の兆候 | 外部からの探索か、承認済みの診断作業か | 公開範囲を確認し、意図した診断なら条件を限定して扱う |
運用自動化は通知と情報収集から始める
自動化しやすいのは、通知、チケット作成、Finding情報の追記、担当者の割り当てです。これらは同じ処理を繰り返しやすく、誤作動時の業務影響も比較的限定できます。
インスタンスの隔離、認証情報の無効化、リソースの停止は、影響が大きい処理です。対象を誤ると正常なサービスまで止めるため、事前に検証した条件と復旧手順がある場合だけ自動化します。最初は承認を挟む半自動の流れにし、運用実績を見ながら範囲を広げると安全です。
抑制ルールは繰り返し確認した後に使う
業務上正当な診断や通信が繰り返しFindingになる場合、抑制ルールで条件に合う新しいFindingを自動的にアーカイブできます。ただし、抑制されたFindingはEventBridgeやSecurity Hubなどへ送られません。原因を確認せず広い条件で抑制すると、必要な兆候まで通知経路から消えるため、対象リソースやFindingの種類を狭く指定します。挙動の詳細はAWS公式のGuardDuty抑制ルールで確認できます。
Security Hubで複数サービスのFindingをまとめる
複数のAWSセキュリティサービスを利用する環境では、GuardDutyのFindingをAWS Security Hubへ集約すると、確認場所と優先度付けをそろえやすくなります。ただし、集約しても調査や対応が自動的に完了するわけではありません。運用方法はAWS Security Hubによるセキュリティ情報の一元管理も併せて確認してください。
料金を見積もるときの注意点
GuardDutyは、分析するログ、イベント、ワークロード、データなどの量に応じた従量課金です。料金体系はデータソース、保護プラン、リージョンによって異なるため、単純なGB単価だけでは見積もれません。
初めて有効化するアカウントとリージョンでは30日間の無料トライアルがありますが、保護機能によって例外があります。導入前にAmazon GuardDutyの公式料金ページで対象範囲を確認し、コンソールに表示される利用量と推定コストを追跡してください。
コストを抑えるために通知を減らしても、分析量が同じなら料金が同じ場合があります。通知ノイズの削減と分析コストの管理を分け、不要な追加保護プランの有無、対象リージョン、実際の利用量を確認します。
運用開始前のチェックリスト
- 必要なAWSアカウントとリージョンでGuardDutyが有効になっている
- 追加の保護プランと料金を確認している
- サンプルFindingが通知先まで届く
- 重大度だけでなく資産の重要性も優先度判断に使う
- 担当者、連絡先、初動手順、承認者が決まっている
- 隔離や無効化の前に証拠を保全する手順がある
- 抑制ルールを定期的に見直す
まとめ
Amazon GuardDutyは、AWS環境の不審な活動を継続的に検知し、調査すべきFindingを提示します。導入の中心はサービスの有効化ではなく、Findingを誰が読み、どの情報と照合し、どこまで自動で処理するかを決めることです。
まずは監視範囲を確認し、サンプルFindingによる通知試験と手動の初動手順を整えます。そのうえで通知、チケット作成、情報収集を自動化し、隔離や停止は検証済みの条件に限ると、検知を安全に対応へつなげられます。
この記事に関連する株式会社greedenの取り組み
GuardDutyは、有効化するだけでなく、検知後の確認と対応を運用へ組み込んでこそ力を発揮します。株式会社greedenはWebシステム開発を通じ、AWS環境の設計から保守・運用改善まで支援しています。