Amazon GuardDuty

Amazon GuardDuty は、AWS 環境内のさまざまなログを継続的に分析し、不正アクセスや侵害の兆候を自動的に検知するマネージド型の脅威検知サービスです。検知のためのインフラやログ収集基盤を自前で構築せずに、有効化するだけで脅威モニタリングを開始できます。

解決する課題

クラウド環境では、攻撃者による認証情報の悪用、暗号資産マイニングを目的とした不正なインスタンス起動、マルウェアに感染したホストからの外部通信など、多様な脅威が発生します。これらを検知するには本来、VPC フローログや DNS ログ、API 操作ログなどを収集・正規化し、相関分析する仕組みを継続的に運用する必要があります。

自前でこうした分析基盤を構築・維持するのは負荷が大きく、検知ルールの陳腐化や運用漏れも起こりがちです。GuardDuty は、必要なログソースの取り込みから分析、脅威の判定までをマネージドサービスとして提供することで、運用負荷を抑えつつ高い検知精度を実現します。利用者は検知結果のトリアージと対応に集中できます。

主要概念と用語

• 検出結果（Finding）: GuardDuty が脅威の可能性を判断した際に生成するレコード。脅威の種類、重大度、関連リソースなどの情報を含む。
• 脅威の種類（Finding type）: 検出結果を分類する識別子。偵察、不正アクセス、暗号資産マイニング、データ持ち出しなどのカテゴリーに整理されている。
• 重大度（Severity）: 検出結果の深刻度を示す指標。低・中・高などのレベルで表され、対応の優先順位付けに使う。
• データソース / ログソース: 分析対象となる入力。VPC フローログ、DNS クエリログ、AWS CloudTrail の管理イベントなどが基盤となる。
• 保護プラン（Protection plan）: 基本の検知に加えて分析対象を拡張する機能群。データベースやストレージ、コンテナ、実行時の挙動などを対象とするオプションが用意されている。
• ディテクター（Detector）: リージョンごとに作成される GuardDuty の設定単位。サービスの有効化はこのディテクター単位で行う。
• 委任管理者アカウント: AWS Organizations 連携時に、組織全体の GuardDuty を統括するために指定するアカウント。
• 抑制ルール（Suppression rule）: 既知で問題のない検出結果を自動的にアーカイブし、ノイズを減らすためのフィルター設定。
• 信頼済み IP リスト / 脅威 IP リスト: 検知から除外する IP や、独自に脅威とみなす IP を登録するためのリスト。

仕様・制限・クォータ

GuardDuty はリージョンごとに有効化するサービスであり、監視したいリージョンそれぞれで設定する必要があります。基盤となるログソースは GuardDuty 内部で自動的に取り込まれるため、利用者が VPC フローログや DNS ログを別途有効化しておく必要はありません。

検出結果には保持期間があり、一定期間を過ぎたものは自動的に削除されます。アカウントあたりに作成できるディテクターやリスト、抑制ルールの数などにはサービスクォータが設定されています。具体的な保持日数やクォータの上限値は変動しうるため、最新の公式ドキュメントとサービスクォータの値を確認してください。組織での一括管理を行う場合は、メンバーアカウント数の規模に応じた管理運用も考慮します。

内部の仕組み

GuardDuty は、対象アカウント・リージョンのログストリームを継続的に取り込み、機械学習モデル、異常検知、AWS が収集・更新する脅威インテリジェンス（既知の悪意ある IP やドメインの情報）を組み合わせて分析します。エージェントのインストールは基本機能では不要で、AWS 側のテレメトリを利用するエージェントレスな構成が中心です。

分析の結果、脅威の可能性が一定の閾値を超えると検出結果が生成され、種類と重大度が付与されます。生成された検出結果は GuardDuty コンソールで確認できるほか、Amazon EventBridge に自動的に送信されます。これにより、通知や自動対応のワークフローを後段で組み立てられます。保護プランを追加で有効化すると、ランタイムの挙動監視など、対象に応じて必要な範囲でのデータ収集が行われます。

設計パターン / ベストプラクティス

代表的な構成は、AWS Organizations と連携し、委任管理者アカウントから組織全体の GuardDuty を一元管理するパターンです。新規アカウントを自動で GuardDuty 有効化対象に含める設定にしておくと、アカウント追加時の有効化漏れを防げます。

検出結果は EventBridge ルールで受け取り、Amazon SNS による通知や AWS Lambda、AWS Step Functions による自動対応へつなげます。ノイズの多い既知の検出結果には抑制ルールを適用し、運用チームが本当に重要なものに集中できるようにします。検出結果やログは AWS Security Hub に集約して横断的に管理する構成もよく採られます。

運用・監視

日々の運用では、生成された検出結果を重大度に応じてトリアージし、誤検知か実害かを判断します。重大度の高いものから優先して調査し、必要に応じてインシデント対応プロセスへエスカレーションします。EventBridge と連携した通知により、重要な検出結果を見逃さない仕組みを整えます。

抑制ルールや信頼済み IP リストを適切に整備することで、繰り返し発生する既知の検出結果を抑え、アラート疲れを防ぎます。組織全体での有効化状況や、各リージョンでの設定状態を定期的に点検することも重要です。検出結果は Security Hub や SIEM へ集約し、他のシグナルと相関させて全体像を把握します。

コスト

GuardDuty の料金は、主に分析対象となったログの量に基づく従量課金です。VPC フローログや DNS ログの分析量、CloudTrail イベントの分析量、そして有効化した保護プランごとに対象データ量に応じて課金されます。トラフィックや API 操作が多い環境ほど分析量が増え、コストも増加します。

新規利用者向けには一定期間の無料トライアルが提供されることが一般的で、有効化前に推定コストを把握する機能も用意されています。これらを活用して本格運用前にコスト感を確認すると安全です。

セキュリティ

GuardDuty 自体は検知に特化したサービスであり、ログソースを GuardDuty が取り込む際に対象リソースの設定を変更することは基本的にありません。検出結果へのアクセスは AWS IAM のポリシーで制御し、委任管理者やメンバーアカウントの権限を最小権限の原則に沿って設計します。

検出結果は機密性の高い情報を含むため、EventBridge や S3 へエクスポートする際の出力先の保護、暗号化、アクセス制御を適切に行います。GuardDuty は AWS の他のセキュリティサービスと組み合わせて多層防御を構成する一要素として位置づけ、検知だけでなくその後の対応プロセスまでを含めて設計することが重要です。

Well-Architected の観点

セキュリティの柱の観点では、GuardDuty は継続的なモニタリングと脅威検知を担い、インシデントの早期発見に寄与します。検知をトリガーとした自動対応を組み込むことで、対応までの時間を短縮し、人手による運用負荷を下げられます。

組織全体での一元的な有効化と、検出結果の集約管理は、ガバナンスとセキュリティ態勢の可視化につながります。検知から通知、対応までの一連のフローをコード化しておくことで、再現性のあるインシデント対応を実現できます。

試験で問われるポイント

関連サービス・比較

AWS Security Hub は、複数のセキュリティサービスの検出結果を集約・標準化し、セキュリティ態勢を横断的に評価するサービスです。GuardDuty が脅威の検知そのものを担うのに対し、Security Hub はその結果を含む各種シグナルを集約・管理する役割を持ちます。両者は競合ではなく、組み合わせて使うのが一般的です。

ハンズオン / CLI例

次の例は、現在のリージョンで GuardDuty を有効化し、作成されたディテクターの一覧と検出結果の状況を確認するものです。

# GuardDuty を有効化してディテクターを作成（検出結果の取得頻度を指定）
aws guardduty create-detector \
  --enable \
  --finding-publishing-frequency FIFTEEN_MINUTES

# 作成済みディテクターの ID を確認
aws guardduty list-detectors

# 検出結果の ID 一覧を取得（重大度の高い順に確認したい場合の起点）
DETECTOR_ID=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)
aws guardduty list-findings --detector-id "$DETECTOR_ID"

# 取得した検出結果の詳細を確認
aws guardduty get-findings \
  --detector-id "$DETECTOR_ID" \
  --finding-ids <finding-id>