AWS のセキュリティサービスを入れ始めると、最初に困るのは「検知できないこと」ではなく、「検知結果が多すぎて運用できないこと」です。GuardDuty は脅威検知を出し、Inspector は脆弱性を出し、Macie は S3 上の機密データに関する検出を出します。さらに Security Hub も画面に出てくるので、慣れていないと「結局どれを見ればいいのか」が分からなくなります。

まず結論から言うと、Security Hub は新しい攻撃を発見する主役ではありません。この記事では、Security Hub を「複数サービスの検出結果を集約し、優先順位をつけ、対応状況を管理しやすくする整理役」として捉える方法を整理します。

Security Hub を“検知サービス”として見るとズレる

Security Hub という名前だけを見ると、これ自体が何かをスキャンして攻撃を見つけてくれるサービスに見えます。ここが少しややこしいところです。

Security Hub の中心的な役割は、AWS アカウント内外のセキュリティ検出結果を finding として集約し、標準化された形式で扱えるようにすることです。

たとえば、次のようなサービスが別々に結果を出します。

サービス	主な役割	Security Hub での見え方
Amazon GuardDuty	脅威検知	不審な API 呼び出し、異常な通信などの finding
Amazon Inspector	脆弱性管理	EC2、ECR、Lambda などの脆弱性 finding
Amazon Macie	データ保護	S3 上の機密データ検出 finding
AWS Config / Security Hub standards	設定チェック	CIS、AWS Foundational Security Best Practices などの準拠状況

つまり Security Hub は、センサーそのものというより、複数のセンサーから上がってきた結果を同じ棚に並べる場所です。

価値は「発見」より「収口」にある

セキュリティ運用で本当に詰まりやすいのは、検知件数が増えた後です。

GuardDuty のアラートを誰が見るのか
Inspector の脆弱性をどの順番で直すのか
Macie の検出結果を情報管理チームへ渡すのか
同じリソースに対する複数の finding をどう扱うのか
解決済み、抑制、対応中をどこで管理するのか

この整理を各サービスの画面だけでやろうとすると、運用はだんだん破綻します。Security Hub を入れる意味は、ここを一か所に寄せることです。

Security Hub では、finding に重大度、リソース、ワークフロー状態、関連アカウント、標準チェックなどの情報が付きます。これにより「どのアカウントの、どのリソースに、どれくらい危ない問題があるのか」を横断的に見やすくなります。

実務では severity だけで並べると危ない

Security Hub の画面では重大度で finding を絞り込めます。ただし、severity だけを見て上から順に潰す運用は雑です。雑な運用はだいたい半年後に負債になります。

見るべき軸は少なくとも次の 4 つです。

観点	確認したいこと
重大度	Critical / High か
露出	インターネット到達可能か、公開 S3 か
重要度	本番、決済、顧客データなどに関わるか
再発性	同じ finding が継続的に出ているか

たとえば、High の脆弱性でも隔離された検証環境なら即日対応ではないかもしれません。一方で Medium でも、公開 ALB 配下の本番 EC2 に関係するなら優先度は上がります。Security Hub はこの判断の材料を集める場所であり、判断そのものを丸投げする場所ではありません。

EventBridge と組み合わせて対応フローへ流す

Security Hub の finding は Amazon EventBridge と組み合わせることで、通知やチケット化に流せます。

たとえば構成としては次のようにします。

GuardDuty / Inspector / Macie
        ↓
   Security Hub
        ↓ finding imported / updated
   EventBridge rule
        ↓
SNS / Chatbot / Lambda / ticket system

ここで大事なのは、全部を Slack に流さないことです。全部流す通知設計は、通知しない設計とほぼ同じです。人間が読まなくなるので。

まずは条件を絞ります。

severity が Critical または High
workflow status が NEW
product が GuardDuty または Inspector
対象アカウントが本番
特定のリソースタグが付いている

このようにルールを決めて、初動が必要なものだけを通知します。それ以外はダッシュボードや週次レビューに回すほうが現実的です。

導入時に最初から決めておくこと

Security Hub を有効化するだけなら簡単です。難しいのは、その後の運用ルールです。最低限、次は先に決めておくべきです。

どのアカウントを集約対象にするか
どの standards を有効にするか
Critical / High の一次対応者は誰か
false positive や例外をどう記録するか
解決済み finding のクローズ条件を何にするか

特にマルチアカウント構成では、Security Hub の委任管理者アカウントを使って、組織全体の finding を集約する設計にしておくと後で楽です。後から手作業でアカウントごとに見る運用にすると、だいたい見落とします。

まとめ

Security Hub は「何でも検知してくれる魔法のセキュリティサービス」ではありません。

むしろ価値は地味です。GuardDuty、Inspector、Macie、設定チェックなどから出てくる finding を集め、標準化し、優先順位づけと対応フローに乗せやすくすることです。

この記事の要点は次の通りです。

Security Hub は検知の主役ではなく finding の集約・整理役
GuardDuty、Inspector、Macie などの結果を横断的に見られる
severity だけでなく、露出・業務重要度・再発性も見る
EventBridge と組み合わせて、必要なものだけ通知・チケット化する
導入時点で担当者、例外処理、クローズ条件を決める

セキュリティ運用は、検知を増やすだけでは強くなりません。見つけたものを処理できる形に畳むところまで設計して、ようやく運用になります。Security Hub はそのための収口です。