AWS 道場 08

AWS セキュリティ検知 — 異なる問いを、層でカバーする

CloudTrail、Config、GuardDuty、Macie、Inspector、Security Hubは似た監視サービスではありません。それぞれが答える問いを分けると、重複なく検知の層を設計できます。

TL;DR

  1. 証跡・設定逸脱・脅威・機密データ・脆弱性は、検知したい対象が異なる。
  2. 各サービスは単独で完結せず、Security Hubで検出結果を集約できる。
  3. 予防、記録、検知、修復の役割を混ぜない。

01セキュリティ施策は、対象となるリスクから選ぶ。

サービス名ではなく、守りたい対象と答えたい問いから選ぶ。

セキュリティ施策は、対象となるリスクから選ぶ。
横一列の問いと、その下の各サービスの対応関係を一組ずつ読む。

「誰がS3ポリシーを変えたか」はCloudTrail、「そのS3がpublicか」はConfig、「認証情報が悪用された兆候」はGuardDutyが主な入口になる。

一つのサービスを有効化してセキュリティ対策が完了したと扱わない。観測対象の違いが、そのまま見えない領域になる。

02望ましくない状態と、悪意ある活動を同じ検知器に押し込まない。

望ましくない構成と、攻撃らしい挙動を別の信号として扱う。

望ましくない状態と、悪意ある活動を同じ検知器に押し込まない。
左のConfigは状態とrule、右のGuardDutyは活動とFindingを示す二分割を比較する。

0.0.0.0/0に開いたSecurity GroupはConfig ruleで評価し、通常と異なるAPI呼び出しはGuardDutyのFindingとして調査する。

Configの非準拠は必ずしも侵害ではなく、GuardDutyのFindingも設定修復だけで閉じない。対応手順を分ける。

03複数の検出結果を、優先順位づけして扱う。

複数の検出結果を、共通の優先順位と担当へ集める。

複数の検出結果を、優先順位づけして扱う。
周囲の検知サービスがFindingを中央へ送り、右側で作業順に並ぶ構造を読む。

Inspectorの高深刻度脆弱性とGuardDutyの侵害兆候をSecurity Hubで集約し、担当チームと期限を付けて追跡する。

集約は修復ではない。Findingの重複排除、例外、担当、完了条件がなければ一覧が増えるだけになる。

結論

  1. AWSのセキュリティ検知は、対象ごとの問いでサービスを選ぶ。
  2. ConfigとGuardDutyは、設定逸脱と脅威兆候という別の信号を扱う。
  3. Security Hubは検出を集約する入口であり、対応運用と組み合わせて初めて価値が出る。