Amazon GuardDutyによる脅威検出を理解する
GuardDutyはAWS環境の不審な活動を分析して脅威の兆候を知らせるサービスです。検出することと遮断・修復することを分け、他の安全性サービスとの役割の違いを学びます。
この単元で学ぶこと
- GuardDutyの脅威検出と所見を説明する
- ログ分析と追加保護機能の範囲を区別する
- 検出後の調査・対応と他サービスの役割を判断する
本文解説
1. 脅威の兆候を見つける GuardDutyは環境内のログやイベントを分析し、不審な活動を検出します。例えば通常と異なる認証情報の利用や悪意のある接続先への通信は調査のきっかけになります。脆弱なソフトウェアの一覧を作ることと、実際に起きる活動の不審さを見つけることを区別します。
2. 基本のデータ GuardDutyの基本検出ではCloudTrail管理イベント、EC2のVPCフローログに相当する情報、DNSログを分析します。基本データの分析を始めるために、利用者が別途これらのログの配信を有効化する必要はありません。ただし監査目的で自分が長期保存するログの設定とは別に考えます。
3. 不審さの判断 脅威インテリジェンスや機械学習等を用い、悪意のあるIPアドレスやドメイン、活動の傾向を分析します。所見は調査すべき潜在的脅威を示すもので、事業上許可した作業かも含めて確認します。所見の発生だけで担当者の不正が確定したと断定しません。
4. 追加保護の範囲 S3 ProtectionやRuntime Monitoring等の保護プランでは、対象ログやイベントが異なります。例えばS3の不審なデータアクセスと、実行時のOSレベルの挙動では見る情報が違います。利用リージョン、対象資源、機能の有効化状態を確認し、基本機能だけで全対象を分析したと考えません。
5. 所見を読む 検出結果をfinding（所見）と呼びます。影響を受ける資源、検出した活動、重大度や時刻等を確認して調査の優先順位を決めます。例えば重要な業務の認証情報が不審に利用されていれば、その範囲と操作を追跡し、権限や認証情報への対応を検討します。
6. 検出と対応を分ける GuardDutyを有効にしたこと自体を、不審な通信の遮断や認証情報の失効が完了したこととはみなしません。通知や対応はEventBridge等との連携で設計できます。自動対応を行う場合も、どの条件で何を変更するか、業務への影響や復旧方法を確認します。
7. 他サービスとの比較 Inspectorは対象ソフトウェアの脆弱性等、MacieはS3の機密データ発見、Security Hub CSPMは複数の所見の集約や標準チェックを担います。GuardDutyの不審な活動検出と併用できます。目的に合うサービスを選び、どれか一つが他の機能を全て置き換えるとは考えません。
8. 運用で検証する サンプル所見等で通知と対応手順を確認します。サンプルの発生は実際の侵害が起きた証拠ではなく、経路を試す材料です。対象アカウント・リージョン・保護プランと受信側の設定を点検し、所見を誰が確認するか決めます。分析範囲と対応担当をそろえることが大切です。
図解
重要ポイント
- 不審な活動から潜在的脅威を検出する。
- 基本データと追加保護の範囲を分ける。
- 検出・調査・遮断や修復は別の段階。
間違えやすい点
- 有効化だけでインシデント対応も完了したと考える。
- 所見がないことを未監視範囲の安全証明に使う。
用語解説
- 所見（finding）
- 検出された問題や潜在的脅威の詳細を示す記録。
- 脅威インテリジェンス
- 悪意のある接続先や攻撃活動等に関する情報。
- 保護プラン
- 特定の対象ログや活動を追加して分析するGuardDutyの機能群。
関連教材
参考資料
教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。
確認問題の出題・採点や学習履歴の保存にはログインが必要です。