マネージドサービス部 佐竹です。
AWS re:Inforce 2025 に現地参加してきましたので、そのログを順番に記述しています。
はじめに
2025年6月16日から18日にかけて、ペンシルベニア州フィラデルフィアで AWS のセキュリティに特化したカンファレンス「AWS re:Inforce 2025」が開催されました。
参加したセッションのレポートを「1日のまとめ」に書いていこうとしたらあまりにも文章量が増えすぎてしまったので小分けにしています。
本ブログは「【AWS re:Inforce 2025】現地参加レポート 3日目 6月18日(火) 佐竹版」より TDR309-NEW AWS Security Hub: Detect and respond to critical security issues のセッションレポート（解説）です。
私の感想やコメントは解説の邪魔になると感じたので「脚注」として記載しています。ただし大きく補足が必要な場面では別途いくつか補足を記載しています。
TDR309-NEW AWS Security Hub: Detect and respond to critical security issues 解説
翻訳すると「AWS Security Hub で重大なセキュリティ問題を検出し対応する」となります。ようは「新しい AWS Security Hub について」のセッションです。
ちなみに、"NEW" とあるのは「新サービスのアップデートによって追加されたセッション」のためです。基調講演まで本セッションは言わばシークレットでした。
概要
本セッションは、プレビュー版として新たに発表された AWS Security Hub について、その背景、主要なケイパビリティ*1、そして具体的なデモを交えて解説するものでした。
従来の AWS Security Hub *2 が抱えていた課題を解決し、真の「統合セキュリティソリューション」となることを目指して開発された、新サービスです*3。
セッションでは、新 Security Hub が解決する4つの主要な顧客課題が挙げられました。
新しい Security Hub が解決を目指した4つの顧客課題
セッションでは、セキュリティチームが直面する複雑性として、スライドに示された以下の4つの課題が挙げられました。
断片化された可視性と運用 (Fragmented Visibility)
GuardDuty や Inspector など、サービスごとにコンソールや API が異なり、セキュリティ態勢と運用への可視性が分断されるという課題がありました。お客様は、これらを一元管理できる単一の窓口を求めていました。限定的なコンテキスト (Limited Context)
個々の検出結果は特定のリソースに閉じていたため、ビジネス全体のリスクを評価するための文脈が欠けるという課題がありました。分断されたシグナルと手動分析 (Disconnected Signals)
各サービスからの検出結果が分断され、人間による手動での相関分析を必要とするという課題がありました。重大なインシデントへの対応の遅延 (Delayed Response)
EventBridge や SQS といった「ビルディングブロック」を手動で連携させる必要があり、結果として対応が複雑化・遅延する課題がありました。
新しい Security Hub は、これらの課題を解決するために再設計されたものです。
断片化されたツール群を「統合ソリューション」としてまとめ、個別の事象に「豊富なコンテキスト」を付与します。さらに、これまで人手に頼っていた分析と対応のプロセスを「自動化された相関分析」と「合理化されたレスポンス」によって置き換え、セキュリティ担当者が本当に重要なリスクに集中できる環境*4を提供します。
既存の Security Hub との棲み分けについて
新しい Security Hub の登場に伴い、既存の Security Hub は「Security Hub CSPM」へと名称が変更されました。
- AWS Security Hub CSPM (旧 Security Hub)
クラウドセキュリティ態勢管理 (Cloud Security Posture Management) に特化します。主な役割は、AWS のセキュリティベストプラクティスに基づくセキュリティチェックの実行と、各サービスからの検出結果を集約する機能です*5。各サービスからの検出結果を集約するアグリゲーターとしての役割も引き続き担います。 - AWS Security Hub (新 Security Hub)
検知、自動相関分析、リスクの優先順位付け、そして自動レスポンスまでをカバーする、「統合セキュリティハブ」として生まれ変わりました。プレビュー期間中は無料で利用が可能です。
さてこうなると、AWS Security Hub (新 Security Hub) の機能が気になるところでしょう。
このスライドは、新しい AWS Security Hub がどのようにセキュリティ情報を処理し、価値あるインサイトを生み出すか、その中核的なケイパビリティを視覚的に表現したものです。
ここでは下（根拠となる情報）から上（結果）への情報の流れで記載しています。
Security signals (セキュリティシグナル)
一番下の層は、元データとなる「セキュリティシグナル」です。これは GuardDuty, Inspector, Macie など、様々な AWS サービスから収集される個々の検出結果や設定を示します。Automated correlation & enrichment (自動的な相関分析と情報の付与)
中間層では、収集したシグナルを自動で関連付け、コンテキスト情報を加えて意味のある情報へと変換します。情報を集めるだけではなく、分析が行われます。主要ケイパビリティ群
最上層が、具体的な4つの主要ケイパビリティです。- Exposure findings (エクスポージャー検出結果):
複数のシグナルを相関分析して発見された、単一の脆弱性を超える「危険な組み合わせ」です。 - Attack path (攻撃経路):
Exposure がどのように攻撃者に悪用されうるかを視覚的に示した経路図です。 - Asset inventory (資産インベントリ):
セキュリティの観点から、組織内の全リソースを一覧化したものです。 - Triage & alerting (トリアージとアラート):
上記の分析を経て、対応が必要なリスクに絞り込み、優先順位付けされたアラートを生成します。
- Exposure findings (エクスポージャー検出結果):
これら全ての情報は、最終的に Unified summary dashboard (統合サマリーダッシュボード) 上で一元的に管理され、可視化されます。
情報ソースですが、Amazon GuardDuty, Amazon Inspector, AWS Security Hub CSPM, Amazon Macie などが主要な「検知エンジン」として、新しい Security Hub にシグナルを供給します。
新しい Security Hub の特筆すべきケイパビリティ
新しい Security Hub は、単なる検出結果のアグリゲーターではなく、セキュリティ運用を大きく変革する機能を備えているとのこと。
ここからは「主要ケイパビリティ群」で挙げた各項目を、さらに掘り下げていきます。
Exposure Findings と Attack Path の掘り下げ
新しい Security Hub の中核となる機能（ケイパビリティ）が「Exposure Finding (エクスポージャー検出結果)」という概念です。
これは、単一の脆弱性や設定ミスではなく、複数の要素が組み合わさって生まれる「危険な組み合わせ（Toxic Combination）」を指します。
例えば、以下のような要素を自動的に相関分析し、1つの Exposure Finding を生成します。
- 脆弱性: Inspector が検出した CVE などの脆弱性。
- ネットワーク到達可能性: インターネットからリソースにアクセス可能かどうか。
- 機密データ: Macie が S3 バケット内で発見した機密データ。
- リソース間の関係: EC2 インスタンスが特定の IAM ロールを引き受けられるといった権限設定。
- 設定ミス: IMDSv1 が利用されているなど、単体では低リスクでも組み合わせで危険度が増す設定。
そして、各 Exposure Finding には「Attack Path (攻撃経路)」が視覚的に表示されます。これにより、攻撃者がどのように環境へ侵入し、リソースを悪用する可能性があるかを直感的に理解できます。
セキュリティに特化したリソースインベントリ
AWS Organizations と統合された、セキュリティに特化したリソースインベントリ機能が提供されます。これにより、組織内の全アカウント・全リージョンにまたがるリソースを、セキュリティの観点から一元的に把握できます。
「どの種類のリソースがいくつあるか」「どのリソースに、どのような種類の検出結果が出ているか」「そのリソースの現在の設定はどうなっているか」といった情報を、コンソールを移動することなく確認できます。
ネイティブなチケット連携と自動化
これまで手動での構築が必要だったチケットシステムとの連携が、ネイティブ統合として提供されます。プレビュー時点では Jira Cloud と ServiceNow に対応しています。
コンソールから数クリックで連携設定が完了し、個別の検出結果から直接チケットを作成したり、「Automation Rules (自動化ルール)」を定義して「重要度が Critical の検出結果は自動的に ServiceNow に起票する」といったワークフローを簡単に実現できます。これにより、対応までの時間が大幅に短縮されます。
Open Cybersecurity Schema Framework (OCSF) への準拠
新しい Security Hub のデータストアは、業界標準の「Open Cybersecurity Schema Framework (OCSF)」に準拠しています。これにより、従来のフォーマットよりもはるかに豊富で詳細な情報を検出結果に含めることが可能になります。
また、OCSF を採用している他のサードパーティ製ツールとの連携も容易になります*6。
簡素化されたオンボーディングとクロスリージョン集約
組織全体への簡単な有効化
AWS Organizations と連携し、オンボーディングプロセスが大幅に簡素化されました。管理アカウントで Security Hub を有効化し、委任管理者を設定した後は、その委任管理者アカウントからポリシーを定義するだけです。
ポリシーでは、対象アカウント（全アカウント、特定 OU など）と対象リージョン（全リージョン、特定リージョン）を指定します。一度設定すれば、新規に作成されたアカウントがポリシーに合致する場合も、自動的に Security Hub が有効になります。
リージョン集約 (Region Aggregation)
複数のリージョンで運用している場合でも、「ホームリージョン」を1つ定義することで、他のリージョンからの検出結果をそのホームリージョンに集約できます。
これにより、単一の委任管理者アカウントの、単一のホームリージョンから、組織全体の全アカウント・全リージョンのセキュリティ情報を一元的に確認できるようになります*7。
関連記事等
セッションの動画
この概要を読んで興味が出た方は YouTube に既に動画がアップロードされているので是非ご覧ください。
新しい AWS Security Hub でセキュリティを統合し、リスクの優先順位付けと大規模な対応を実現 (プレビュー)
まとめ
本セッションで解説された新しい AWS Security Hub は、従来の Security Hub CSPM が担っていた「検出結果の集約と表示」という役割から大きく進化し、「検知」「相関分析」「優先順位付け」「対応」をシームレスに繋ぐ、統合セキュリティプラットフォームへと生まれ変わったものです。
特に、「Exposure Finding」と視覚的な「Attack Path」は、多数のアラートの中から「本当に優先して対応するべきリスクの特定」を効率化してくれる可能性があります。
また、Jira や ServiceNow とのネイティブなチケット連携や自動化ルールは、セキュリティチームの運用負荷を大幅に軽減する可能性があります。ただしこれは、「基調講演のまとめとポイント」で記載したように、既存のセキュリティパートナーの領域と直接的に競合する可能性が高い機能だという点は気になる点です。
加えて OCSF への準拠は、今後の拡張性とサードパーティ製品との連携においてメリットとなって行くでしょう。
現在プレビューとして登場した New AWS Security Hub は、AWS 上のセキュリティ運用を「簡素化（Simplifying）」し、次のレベルへと引き上げる可能性を秘める重要なサービスであると感じます。
ところで私はこのセッションを、次の「Winning the DDoS battle」のために最初の20分程度で離席したため、本レポートは続きを動画でキャッチアップして記載させて頂きましたことを念のため記しておきます。
では、またお会いしましょう。
*1:本セッションではケイパビリティという言葉が多く使われています。「ケイパビリティ」とは、個別の「機能」とは少し意味合いが異なります。「機能」が個別の要素、例えばボタンを押下したら達成される設定等を指すのに対し、「ケイパビリティ」はそれらを組み合わせることで実現可能な Security Hub の「インシデント対応力」といったような、より大きな「価値や流れを含んだ能力」を指しています
*2:後述しますが、Security Hub CSPM に名称が変更されました。本件は「基調講演のまとめとポイント」のブログ記事でも記載しています https://blog.serverworks.co.jp/reinforce2025-keynote-simplifying-security-at-scale#AWS-Security-Hub-%E3%81%AE%E5%A4%89%E9%9D%A9
*3:こう記載すると少々申し訳ないですが、とてもややこしい上に混乱するので新サービスは名前を変えて欲しかった気はします
*4:いわゆるトリアージの実現を指します
*5:AWS Foundational Security Best Practices (FSBP) 標準によるベストプラクティスの実行度合いの可視化はこれまで通り本ツールの範疇です
*6:OCSF で真っ先に思い浮かぶのが Security Lake ですね
*7:このあたりは、既存の AWS Security Hub の central configuration と同じように思えます
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
セキュリティサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。
