GuardDuty / Security Hub の運用 — 鳴らして終わりにしない

GuardDutyとSecurity Hubは「有効化」で終わらせると、誰も見ないダッシュボードとメールの山になります。委任管理者での集約、トリアージ、EventBridgeでの自動対応、そしてアラート疲れをどう設計するか。運用に乗せるための型を、AWS一次情報を引きながら整理します。

GuardDutyのスイッチを入れ、Security Hubで各種標準を有効化する。ここまでは30分で終わります。難しいのはその後です。誰が検知を見て、どれを無視してよく、どれを自動で潰し、どれを人が調べるのか。この記事は「有効化のあと」に絞って、マルチアカウント環境で運用に乗せるための型をまとめます。

01まず役割分担を間違えない

2つのサービスは目的が違います。混同すると、どちらにも中途半端な期待をして運用が崩れます。

• GuardDutyは脅威検知です。CloudTrail、VPCフローログ、DNSログなどを裏側で継続的に解析し、「このIAMクレデンシャルが見慣れない場所から使われた」「EC2がマイニング先と通信している」といった振る舞いを検知します。ログを自前で有効化・保管する必要はなく、検知ロジックはAWSが更新します。
• Security Hubは統合とベンチマークです。GuardDutyやInspector、Macieなどの検知を一箇所に集約し、AWS Foundational Security Best PracticesやCISといった標準に対してコントロールを自動評価します。個々の検知を集めて「今、組織の姿勢はどうか」を見る場所です。

つまりGuardDutyは「何かが起きている」を鳴らし、Security Hubは「そもそも設定が基準を満たしているか」と「あちこちの検知を束ねた全体像」を見せます。片方だけでは足りません。

02マルチアカウントは委任管理者で集約する

アカウントが数個を超えたら、アカウントごとにコンソールを開いて回るのは非現実的です。両サービスともAWS Organizations連携で委任管理者(delegated administrator)を指定し、1つの運用アカウントに検知を集約します。管理アカウントを委任管理者に使うことは、最小権限の原則からAWSも推奨していません。セキュリティ専用アカウント(例：SecurityやAudit)を割り当てるのが定石です。

ここで運用が破綻しやすい落とし穴が2つあります。

• GuardDutyはリージョン単位です。委任管理者は全リージョンで同一アカウントを指定する必要があり、しかも使うリージョンごとに委任と有効化を行います。東京だけ設定して大阪や海外リージョンを放置すると、そのリージョンは丸ごと検知の空白になります。使わないリージョンはマルチアカウント統制のSCPで作成自体を抑止しておくと、監視漏れと同時に潰せます。
• 新規アカウントの自動有効化(auto-enable)を設定しておかないと、あとから作ったアカウントが監視対象から漏れます。設定値は「新規のみ(NEW)」と「全メンバー(ALL)」があり、オプトインリージョンではNEWの適用順序に癖があるため、確実性を取るならALLが扱いやすい場面があります。

なお委任管理者1つが管理できるGuardDutyメンバーは最大50,000という上限がありますが、実務でここに当たる組織はまれです。上限や料金はバージョン依存なので、公式で最新を確認してください。

03Security Hubの集約は「中央設定」で統制する

Security HubもOrganizations連携で委任管理者を指定します。ここで必ず選びたいのが中央設定(central configuration)です。中央設定を使うと、委任管理者が設定ポリシー(configuration policy)を作り、「どのOU/アカウントでSecurity Hubを有効にし、どの標準・コントロールを有効化するか」を組織全体・複数リージョンにまとめて配布できます。

中央設定を使わないローカル設定(local configuration)だと、各アカウント・各リージョンで個別に設定することになり、AWS自身が「configuration drift(設定のずれ)が起きうる」と明記しています。新規アカウントが増えるたびに設定が食い違い、「あのアカウントだけCISが無効だった」という事故につながります。

04検知をトリアージする — 全部見ようとしない

集約すると、検知は想像以上の量になります。全件を人が見る前提は最初から捨てて、severity(深刻度)で機械的に階層を切ります。GuardDutyのseverityは1.0〜10.0の数値で、Low(1.0–3.9)/Medium(4.0–6.9)/High(7.0–8.9)/Critical(9.0–10.0)の4段階に対応します(Criticalは攻撃シーケンスの検知などで付与されます。閾値の定義はバージョン依存なので公式で確認)。

現場で使えるトリアージの型は、おおむね次の3段です。

重要なのは、Highだけを人に届け、Mediumはチケット、Lowは抑制する、という経路の分岐を最初に設計することです。分岐なしに全部をメールへ流すと、次の章のアラート疲れに直行します。

05EventBridgeで通知と自動対応を組む

GuardDutyは検知をnear real-timeでEventBridgeへ発行します。detail-typeは"GuardDuty Finding"、sourceは"aws.guardduty"で、detail.severityで深刻度を絞り込めます。たとえば「4以上(Medium以上)だけを通知する」なら、severityの値を並べたイベントパターンでルールを作ります。委任管理者アカウントにルールを置けば、メンバーアカウント由来の検知もまとめてトリガーできます。どのアカウントの検知かはdetail.accountIdで判別します。

自動対応の典型は、High検知に対してLambdaを起動し、疑わしいEC2に隔離用セキュリティグループを付ける、漏えいの疑いがあるIAMクレデンシャルを無効化する、SNS経由でSlackへ即時通知するといった封じ込めです。ただし自動封じ込めは本番影響が大きいため、最初は「隔離せず通知だけ」から始め、誤検知率を見てから封じ込めを足すのが安全です。自動化の入り口としては、Lambdaの本番運用の作法も併せて押さえておくと堅くなります。

06アラート疲れを設計で潰す

運用が形骸化する最大の原因はアラート疲れです。「どうせほとんど誤検知」という空気ができた瞬間、本物のHigh検知も見逃されます。疲れは根性ではなく設計で減らします。

• GuardDutyの抑制ルール(suppression rules)：既知の正常な振る舞い(例：脆弱性スキャナからの通信、特定の運用IP)を条件にして自動アーカイブします。重要な性質として、抑制ルールで自動アーカイブされた検知はEventBridgeへ送られません。つまり通知の発生源を根元で止められます。手動アーカイブとは挙動が違う点に注意してください。
• Security Hubの自動化ルール(automation rules)：取り込んだ検知に対し、深刻度の引き上げ/引き下げ、ワークフロー状態の変更、抑制、業務コンテキスト(所有者、データ分類)の付与を自動で行います。「本番でない検証アカウントの特定コントロールは深刻度を下げる」といった調整で、人が見るべき検知を絞れます。ただし1管理者アカウントあたり最大100ルールという上限があるため、ルールは乱立させず設計してから作ります(上限はバージョン依存なので公式で確認)。
• 通知チャネルの分離：Highは即時のSlack/PagerDuty、Mediumはチケット、Lowは週次のダイジェスト。全部を同じメールに流さないだけで、体感の疲れは大きく変わります。

抑制で「見なくてよい」を機械化し、自動化ルールで「文脈」を足し、チャネルで「届く速さ」を変える。この3点セットが、アラート疲れに対する現実的な守りです。監視全体の設計思想はマルチアカウント統制側とも整合させておくと、後で矛盾しません。

07集約先・長期保管とSIEM連携

GuardDutyの検知は90日間保持されます。監査や事後調査のためにそれ以上残したい場合は、GuardDutyのS3エクスポートや、EventBridge経由でのSIEM/データレイクへの転送を組みます。Security Hub側も検知をOCSFフォーマットで正規化して持つため、複数サービスの検知を横断でクエリしやすくなります。

SIEMを持つ組織では、委任管理者のEventBridgeルールで検知をLambdaやFirehoseに流し、既存のSIEM(Splunk、OpenSearchなど)へ集約するのが定番です。将来的にセキュリティログを一元化するなら、Security Lake方面への集約も選択肢になります(この記事の範囲外)。いずれにせよ「検知の一次受けは委任管理者、長期保管と相関は別基盤」という二層構成にしておくと、90日制約にも監査要件にも耐えます。

—まとめ

GuardDutyとSecurity Hubは、有効化した瞬間から価値が出るのではなく、運用の型に乗せて初めて機能します。要点は次の通りです。

• 役割を分ける：GuardDutyは脅威検知、Security Hubは統合とベンチマーク。
• 委任管理者で集約する：管理アカウントは避け、GuardDutyは全リージョン同一アカウント＋リージョンごと有効化、新規アカウントは自動有効化。
• Security Hubは中央設定で統制し、centrally managed を原則にドリフトを防ぐ。
• severityで経路を分岐：Highは即時＋自動対応、Mediumはチケット、Lowは抑制。
• アラート疲れは、抑制ルール(EventBridgeへ送らない)＋自動化ルール＋チャネル分離で設計的に潰す。
• 90日の保持制約を前提に、長期保管とSIEM相関は別基盤で二層化。

「鳴らして終わり」にしないための投資は、封じ込めロジックそのものより、誰が何を見て、何を無視してよいかを先に決めることにあります。そこさえ固まれば、あとは自動化が効いてきます。

—参考(一次情報)

• Managing GuardDuty accounts with AWS Organizations — Amazon GuardDuty User Guide
• Processing GuardDuty findings with Amazon EventBridge — Amazon GuardDuty User Guide
• Severity levels for GuardDuty findings — Amazon GuardDuty User Guide
• Managing administrator and member accounts in Security Hub CSPM — AWS Security Hub User Guide
• Streamline security response at scale with AWS Security Hub automation — AWS Security Blog