0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

SecurityHub Advanced各種機能紹介/注意点

0
Posted at

1.Security Hub Advanced とは何か

2025年12月、AWSは Security Hub の新しい機能群をGA しました。
このアップデートでは 「ほぼリアルタイム分析」や「リスク優先度付け」 などの機能が追加され、Security Hub は従来の「検出結果の集約ツール」から、クラウド環境のリスクを分析・優先順位付けするセキュリティプラットフォームへと進化しました。

re:invent会場でworkshopとsessionを行ってきました。
WorkShopがほかのセッションや社内の用事がかぶりあまり触れなかったので少し後悔しています...
sessionはユーチューブでも公開されているので一度見てみてください!
https://www.youtube.com/watch?v=mYyBQYIeJzk

本記事では、この新しい Security Hub Advanced の機能について、概要と注意点を整理していきます。

従来のSecurity Hub(Security Hub CSPM)

これまでのSecurity Hubは主に CSPM(Cloud Security Posture Management) の役割を担っていました。
CSPM機能はSecurity Hub CSPMとして別サービスに切り離されています。

具体的には以下のような機能です。

  • AWS環境の設定ミスの検出
  • セキュリティベストプラクティスとの比較
  • セキュリティサービスの検出結果の集約
  • コンプライアンス基準(CIS / AWS Foundational Security Best Practices など)の評価

例えば以下のような検出が可能でした。

  • S3 バケットがパブリック公開されている
  • セキュリティグループが 0.0.0.0/0 で特定のポートを許可している
  • CloudTrail が有効化されていない

ただし、この従来モデルには 一つ課題がありました。

「検出結果は分かるが、どれから対応すべきか判断しづらい」

例えば以下のような状況です。

  • Inspector:脆弱性検出
  • GuardDuty:脅威検出
  • Security Hub CSPM:設定ミス検出
  • Macie:機密データ検出

それぞれが 別々のFinding として表示されるため、
どのリスクが本当に重要なのかを判断するのが難しいという問題がありました。

Security Hub Advanced のコンセプト

今回GAされた Security Hub Advanced では、この課題を解決するために
複数のセキュリティシグナルを相関分析し、リスクを優先順位付けする機能が追加されています。

具体的には以下のような情報を統合して分析します。

  • Amazon GuardDuty(脅威検出)
  • Amazon Inspector(脆弱性)
  • Security Hub CSPM(設定不備)
  • Amazon Macie(機密データ)

これらの情報を組み合わせることで、

設定ミス
+
脆弱性
+
外部公開

のような 「実際に攻撃につながる可能性の高いリスク」を検出しやすくなりました。

この考え方は CNAPP(Cloud Native Application Protection Platform) の思想に近いものです。

Security Hub Advanced で追加された主な機能

今回のアップデートでは、主に以下の機能が追加されています。

① Near Real-Time Risk Analytics(ほぼリアルタイムリスク分析)

複数のセキュリティ検出結果を組み合わせて
リスクの高いリソースを自動的に特定します。

「ほぼリアルタイム」については以下の記事で深堀しています。
Security Hub の「ほぼリアルタイム 」はどのくらいなのか?

② Exposure Finding(リスクのまとまり)

複数の検出結果を 1つのリスクとして整理します。

例えば以下のようなケースです。

  • EC2 がインターネット公開
  • 重大な脆弱性あり
  • IAM権限が過剰

これらが 1つのExposureとして可視化されます。

image.png

③ Attack Path 可視化

攻撃者がどのように侵入し、どのリソースへ到達できるかを
攻撃経路として可視化できます。

これにより

  • どこから侵入可能か
  • どのリソースが危険か
  • どの設定を直すべきか

が直感的に理解できるようになります。
攻撃パス.png

④ Trends / ダッシュボード

セキュリティ状態の 長期トレンド分析も可能になりました。

例えば以下のような観点です。

  • 露出リスクの増減
  • 脆弱性の推移
  • セキュリティ改善の進捗

これにより 継続的なセキュリティ改善の指標としても活用できます。
image.png

2. 主要機能① ほぼリアルタイム分析とリスク優先度付け(露出 / 攻撃パス)

本章では、Security Hub Advanced の中核である 「ほぼリアルタイム分析(near real-time)」 と、そこから生まれる 「露出(Exposure)」、そして 「攻撃パス(Attack Path)」 を整理します。
結論から言うと、Advanced の価値は Findingを眺め から 今直すべきリスクが何か分かる へ変わる点にあります。

2-1. 「ほぼリアルタイム分析」とは何が リアルタイム なのか

Blog記事まとめ (1).jpg
Security Hub Advanced は、複数のセキュリティシグナル(例:脅威・脆弱性・設定不備など)を取り込み、リスクの文脈(=攻撃につながりやすさ)を加味して露出を更新していきます。

「リアルタイム」 の対象

  • 新しいFindingが来る/更新される
  • それに応じて 露出(Exposure)の評価が更新される
  • 露出の中で 優先度(どれから対応すべきか) が変わり得る

つまり、リアルタイム性は 「検出結果の相関・再評価」 の部分にあります。

2-2. 注意点:「最初の露出が出るまで」待ちがある

ここが誤解されがちポイントです。

  • Advanced を有効化しても、最初から全リソースの露出が即時に揃うわけではありません
  • 初期評価が揃うまで 時間がかかるケースがあります(環境条件や収集状況に依存)

記事内では「ほぼリアルタイム=数秒で全部揃う」ではない
と明記すると誤解が減ります。

2-3. 露出(Exposure Finding)とは

露出の一言定義

複数のリスク要因(traits)を1つのリスクのまとまりとして整理したものです。

従来は、以下が別々のFindingとして並びがちでした。

  • 外部公開(設定不備)
  • 重大な脆弱性
  • 過剰権限
  • 機密データアクセスの可能性

Advanced では、これらを 「同じリソース(または同じ資産)」という単位で束ね
“対応優先度を付けやすい形”に変えます。

露出が強い理由:人間の判断を「最初から助ける」

運用上、ありがちな状況:

  • 重大な脆弱性は大量にある
  • でも全部が今すぐ危険ではない
  • 例えば「内部ネットワーク限定」なら優先度は落ちることもある

露出の価値はここです。

「外部から到達できる」「攻撃につながる経路がある」
などの条件が揃ったものを上位に押し上げる

2-4. 露出で見るべきポイント

露出の詳細画面を見たら、まず以下を確認します。

① 何が原因(traits)で露出になっているか

  • 外部公開に関する要因
  • 脆弱性に関する要因
  • 権限/IAMに関する要因
  • 機密データに関する要因(該当する場合)

② どのリソースが対象か(対象資産)

  • どのアカウント / リージョン / リソースか
  • 影響範囲(関連する資産)があるか

③ 推奨対応(Remediation guidance)

  • 何を直せば露出が解消するか
  • 一番効く修正がどれか(例:外部公開の遮断、脆弱性修正 など)

2-5. 攻撃パス(Attack Path)とは

攻撃パスの一言定義

**「攻撃者がどこから入って、どう辿ると、この資産に到達できるか」**を示す経路の可視化です。

重要なのは、攻撃パスが 単独機能というより

露出(Exposure Finding)の詳細画面で確認できる可視化機能

という点です。

攻撃パスが効く場面(現場あるある)

  • 「なぜこのEC2が危険なの?」を説明したい
  • 脆弱性があるだけでは、優先度を上げる根拠が弱い
  • 「外部から到達できる」ことが示されると、優先度判断が容易になる

攻撃パスは、セキュリティ担当とインフラ/アプリ担当の会話コストを下げるのに効きます。

3. 主要機能② トレンド / ダッシュボードと運用設計の勘所

第2章では「露出(Exposure)」と「攻撃パス(Attack Path)」を扱いました。
これらは いま危険なものを見つける ための機能です。

一方で、第3章のテーマである 「トレンド(Trends)/ ダッシュボード」 は、
継続的に改善する(増えていないか/減っているか) を扱います。

つまり、

  • 第2章:いま直す(優先度付け)
  • 第3章:改善を回す(状況把握とKPI化)

という役割分担です。


3-1. ダッシュボードは「状況を一瞬で把握する画面」

Security Hub の ダッシュボードは、
アカウント/リージョン全体の状態を **要約(サマリー)**として把握するための画面です。

ここで見るべきは「詳細」ではなく 異常の兆候です。

ダッシュボードで確認すべき観点

  • 露出(Exposure)が増えていないか
  • 重大度の高いリスクが増えていないか
  • どのカテゴリ(外部公開 / 脆弱性 / 権限など)が増えているか
  • 直近の変化(いつから悪化したか)

まずダッシュボードで「怪しい」を見つけ、
その後に Exposure / Finding の詳細へ降りる、という導線が自然です。

3-2. トレンド(Trends)は「改善を証明する機能」

トレンドの一言定義

セキュリティ状態の推移を時系列で見せる機能です。

これがあることで、以下が可能になります。

  • 「今月は改善した/悪化した」を説明できる
  • 運用の成果を見える化できる
  • 施策(例:外部公開の是正キャンペーン)の効果が分かる

セキュリティはやった感になりやすいので、
トレンドで 数値として説明できるのが強いです。

3-3. 運用の型としての使い方

Blog記事まとめ (2).jpg

ここからは、実運用でありがちな運用パターンに落とします。

パターンA:週次の「優先リスク」レビュー

  1. ダッシュボードで「増えたもの」を確認
  2. Exposure を 優先度順に上から見る
  3. 上位の露出を「今週直す対象」として切り出す
  4. 直し終わったら翌週、トレンドで改善を確認

週次で上位N件を潰す が一番回しやすいです。

パターンB:部門/チームへの説明

  • 攻撃パスで「到達可能性」を示す(危険の根拠)
  • 露出のtraitsで「原因」を示す(直すべき点)
  • トレンドで「増えている/減っている」を示す(優先度の根拠)

この3点セットが揃うと、セキュリティ部門が一方的に言っている感が減り、
合意形成が早くなります。

パターンC:改善施策のKPI化(経営/マネジメント向け)

例:

  • 月次で「高優先度Exposureの件数」を追う
  • 「外部公開+重大脆弱性」の件数を追う
  • 一定期間で何件減らしたか をレポート化する

「KPIがないと予算が付かない」問題に強いです。

3-4. ノイズ制御(運用のつらみを減らす考え方)

Advanced を導入すると「見えるもの」が増える一方、
運用上のつらみは ノイズが増える ことです。

ノイズ制御の基本戦略

  • すべてを追わない(優先度上位から)
  • “直せるものにフォーカスする(改善可能性が高いもの)
  • 週次/月次でルーチン化して「燃え尽き」を防ぐ

4. 導入・有効化・料金・落とし穴

第4章では、Security Hub Advanced を 実際に導入・運用するうえでの現実的な論点をまとめます。
機能自体は魅力的ですが、導入でハマるポイントはだいたい以下に集約されます。

  • どの単位(Org/アカウント/リージョン)で有効化するか
  • 既存の Security Hub(CSPM)運用とどう統合するか
  • 料金(Essentials / Add-on)をどう見積もるか
  • ほぼリアルタイム の期待値調整
  • IaC(CloudFormation/CDK/Terraform)でどこまで自動化できるか

4-1. 導入方針:いきなり全社展開しない

おすすめの進め方は「段階導入」です。

フェーズ1:検証(PoC)

  • 代表的なアカウント/リージョンだけで有効化
  • Exposure / Attack Path / Trends が 期待通りに見えるか を確認
  • 既存運用(通知・チケット化)にどう影響するかを確認

フェーズ2:限定展開

  • インターネット公開が多い部門や重要システムから展開
  • 週次レビュー(上位N件)を回せる運用に落とす

フェーズ3:全社展開

  • Organizations 管理で標準化(委任管理者の設計含む)
  • 例外(適用外)ルールを整備してから広げる

いきなり全リージョン全アカウントで有効化すると、
「ノイズ+費用+運用工数」の三重苦になりやすいです。

4-2. 有効化の勘所:Org管理・集約リージョン・責任分界

組織(Organizations)前提での基本パターン

  • 集約管理アカウント(Security運用アカウント)を決める
  • 委任管理者(delegated admin)を設計する
  • 集約リージョン(ホームリージョン)を決める
  • まずは「見る」→次に「直す」→最後に「自動化」の順で成熟度を上げる

どのアカウントが見る人で、どのアカウントが“直す人”か
を先に決めると失敗しづらいです。

4-3. 料金:Essentials / Add-on の理解が必須

Security Hub Advanced は、料金体系が整理されています。
ざっくり言うと、

  • Essentials plan(ベース):リソースベース課金
  • Add-on(追加機能):用途に応じた従量課金(例:脅威分析等)

という構造です。

見積のポイント

  • どのリソースが 課金対象 になっているかを把握する
  • 「まずEssentialsのみ」で開始して、必要ならAdd-onを追加する
  • PoCでは「費用の上振れ要因」を確認する(対象リソース数/ログ量など)

全部入りで有効化 は、費用の見通しが立ちにくいので避けるのが無難です。

※検証をした所管としては、SecurityHubを利用する上でのConfigの料金が大半を占める印象です。

4-4. 落とし穴まとめ(記事で強調すると価値が上がる)

落とし穴①:「ほぼリアルタイム」を誤解する

  • 秒で全部揃う ではない
  • 初期評価/収集状況次第で待ちがある
  • near real-time は「相関・更新が速い」という性質に近い

落とし穴②:露出=Findingが減る、ではない

  • 露出は まとめ なので、元のFindingがゼロになるわけではない
  • 露出とFindingは役割が違う(露出は優先度判断、Findingは根拠)

落とし穴③:運用の型がないと燃える

  • ノイズが増える
  • 週次で上位N件 のような型がないと続かない

落とし穴④:Org/リージョン設計を後回しにすると破綻

  • 後から集約し直すのがつらい
  • まずは「誰が見る/誰が直す/どこに集約」が重要
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?