新Security Hub exposure findings運用｜OCSF相関のリスク優先度とSOCトリアージ

1. この記事について

本記事は「AWS Security Hub exposure findings 本番運用」シリーズの第1弾(Vol1)です。本Vol1では、exposure findingの構造理解からSOC日次トリアージ運用までの基礎を確立することに焦点を当てます。次Vol以降では、本Vol1で確立した運用基盤の上に、Automation Rulesを使った対処の自動化や、Terraformによる運用パイプラインの構築といったテーマへ発展させていく予定です。

exposure findingが解決する具体的な悩みとして、次のようなものが挙げられます。

• GuardDuty・Amazon Inspector・Amazon Macieからそれぞれ個別に通知が届き、どれから対処すべきか判断に迷う
• 脆弱性スキャン結果単体では”悪用可能かどうか”の文脈(到達性や権限)が分からず、severityを鵜呑みにするしかない
• 影響範囲(blast radius)を評価する手段がなく、対処の優先順位を勘や経験則に頼っている

exposure findingは、これらの悩みに対して複数シグナルの相関結果を1つのfindingとして提示することで応えます。本記事では、この相関結果を実際の日次オペレーションでどう使うかを軸に解説します。

先に知っておくと理解が早まる用語(詳細は§3以降で解説)

• 寄与トレイト(contributing trait): exposure findingを生成する根拠となった、到達性・脆弱性・機密データ・設定ミス・権限奪取可能性のいずれかの要素
• コンテキストトレイト(contextual trait): exposure finding生成の直接根拠にはならないが、追加の判断材料として提示される要素(unused accessなど)
• blast radius: ある露出が悪用された場合に影響が波及し得る範囲
• attack path: 攻撃者が露出を起点として到達し得るリソースの経路

これらの用語は§3で詳しく解説しますが、まず概要を押さえておくことで、以降の章をスムーズに読み進められます。

1-1. 本記事のゴール

本記事を読み終えると、新Security Hubが生成するexposure findingを”生成されたら終わり”の一過性イベントとして眺めるのではなく、日次で読み解き、優先度順に対処する運用サイクルとして回せるようになります。到達する状態を具体的に示すと、以下のとおりです。

• OCSF構造の読解: exposure findingのOCSF正規化された構造と寄与トレイト(Reachability / Vulnerability / Sensitive data / Misconfiguration / Assumability)を見て、どのシグナルソースが何を根拠に相関したのかを説明できる
• severity判断: Critical/High/Medium/Lowのseverity分類がどのような軸(発見容易性・悪用容易性・悪用可能性・公知性・潜在的影響)で決まるのかを理解し、単純なCVSSスコアだけでは見えない環境コンテキストを踏まえて対処順序を判断できる
• attack path/blast radius評価: 攻撃経路可視化とblast radius(影響範囲)から、この露出を放置した場合の被害波及範囲を評価し、次アクションを決められる
• contextual traitの活用: IAM Access Analyzerのunused access情報のようなcontextual traitを、over-privilegedなIAMロールのblast radius評価に組み込める
• near-real-time相関の運用: GuardDuty / Amazon Inspector / Amazon Macie / Security Hub CSPMの相関結果を、単なる通知の受け皿ではなく能動的なトリアージ材料として扱える
• 運用サイクルの定着: SOCアナリストの日次トリアージ・週次全体レビュー・月次トレンド分析という運用リズムに、exposure findingsのレビューを属人化せず組み込める

本記事の構成早見表

exposure findingは”生成すること”自体がゴールではなく、生成された後にどう読み、どう優先順位を付け、どう運用に落とし込むかで価値が決まります。本記事はこの”読解から運用定着まで”の一連の流れを一冊で完結させることを目指しています。

到達状態の具体例

たとえば、あるEC2インスタンスに対してCriticalなexposure findingが生成されたとします。本記事を読み終えた状態では、まずそのfindingの寄与トレイトを確認し、インターネットからの到達性(Reachability)と既知の脆弱性(Vulnerability)が組み合わさっている点を特定できます。次に、そのインスタンスにアタッチされたIAMロールのunused access情報(contextual trait)を確認し、万一侵害された場合にどこまで権限が悪用され得るか(blast radius)を評価できます。最後に、これらの情報を踏まえて「今日中に対処すべきか、今週中でよいか」という優先順位を、severityの数値だけでなくコンテキストを踏まえて自分の言葉で説明できるようになります。

1-2. 読者像

本記事は、新Security HubをGAで有効化済み、あるいは有効化を検討中のSOCアナリストやセキュリティ運用担当を主な読者として想定しています。想定読者像を具体的に挙げると、以下のとおりです。

• 新Security HubをGAで有効化したが、コンソールに並ぶexposure findingをどう読み、どう対処順序を付ければよいか手探りのSOCアナリスト
• GuardDuty・Amazon Inspector・Amazon Macie・Security Hub CSPMをそれぞれ個別運用してきたが、これらが横断的に相関された結果を扱うのは初めてのセキュリティ運用担当
• すでにマルチアカウント環境でSecurity Hubの委任管理者設定やOrganizations展開を終えており、次のステップとして日次運用の型化を求めている組織のセキュリティリード
• 旧Security Hub(CSPM)のASFF集約やStandards評価には馴染みがあるが、near-real-timeの相関エンジンが出す”すでに優先順位付けされたリスク”の読み方に不慣れな担当者
• attack path・blast radius可視化やcontextual traitといった新しい概念を、実際の日次判断にどう落とし込めばよいか知りたい担当者

既存の個別運用経験と本記事で埋めるギャップ

本記事では導入手順そのものを扱いません。あくまで「exposure findingという新しいアウトプットをどう読み、どう優先順位を付け、どう日々のオペレーションに組み込むか」という運用面に焦点を当てています。

本記事を読み進めるうえでの前提知識として、GuardDuty・Amazon Inspector・Amazon Macie・Security Hub CSPMそれぞれの基本的な役割(脅威検知・脆弱性スキャン・機密データ検出・設定コンプライアンス評価)を把握していることを想定しています。各サービスの詳細な有効化手順や個別機能そのものの深掘りは扱わないため、初めて触れるサービスがある場合は各サービスの公式ドキュメントを併読することを推奨します。

1-3. なぜ今これを書くか

新Security Hubは2025年12月2日に一般提供(GA)が開始されました。exposure findingはこのGAで登場した機能であり、GuardDuty・Amazon Inspector・Security Hub CSPM・Macieなど複数サービスのシグナルをnear-real-timeで相関し、脆弱性・設定ミス・機密データ露出・権限奪取可能性といった寄与トレイトの組み合わせから、リソース単位で最大1件のexposure findingを生成する仕組みです。これは個々のサービスがそれぞれ出力するfindingを単純に集約していた従来の運用とは根本的に異なります。

GAによってexposure findingがもたらす運用上の変化は、次のように整理できます。

• 複数サービスのシグナルが個別のアラートではなく、1つの相関済みexposure findingとして統合出力される
• 寄与トレイトとcontextual traitが明示され、どのシグナルが根拠になったかを追跡できる
• attack pathとblast radiusが可視化され、影響範囲の評価が個々人の勘に依存しなくなる
• 相関結果がnear-real-timeで更新され続け、状況変化に追従できる

一方で、GA直後の時点では「新旧Security Hubの名称がどう違うか」「どう有効化するか」といった導入面の情報は充実してきているのに対し、生成されたexposure findingを実際にどう読み、severityやattack path/blast radiusから何を判断し、日次のSOC運用サイクルにどう組み込むかという運用ノウハウはまだ手薄な状態です。本記事はこの空白を埋めることに特化し、名称区別やGAの基本、委任管理者展開といった導入面の解説は既存記事に委譲したうえで、運用の実践知に絞って解説します。

本記事が委譲する既存記事一覧

これらの話題は本記事の主題である「exposure findingsの運用深掘り」とは別レイヤーの内容であり、深掘りすると本記事の主題がぼやけてしまいます。そのため各話題は上記の既存記事へ委譲し、本記事はexposure findingを日次運用に組み込むための実践知に集中します。

想定読了時間はおよそ20〜25分です。§2で運用の前提条件を確認したうえで、§3以降でOCSF構造・severity分類・attack path評価・日次トリアージ運用へと読み進めてください。実際にAWSマネジメントコンソールで手元のexposure findingを確認しながら読み進める場合は、40〜50分程度を見込んでおくとよいでしょう。

新旧Security Hubの区別・委任管理展開はマルチアカウント基盤 Vol2 §4-1へ

2. 前提・環境・準備

2-1. exposure findings 生成の前提条件

exposure findingsを生成するための前提条件は、AWS公式ドキュメントで次のように明記されています(取得日: 2026-07-14)。exposure findings・trends・near-real-time相関分析といった新Security Hubの機能は、Security Hub CSPMとAmazon Inspectorという「必須サービス(essential services)」の有効化が前提となります。この2サービスのいずれかを無効化すると、対象リソースのexposure findingsは生成されません。

一方、GuardDutyとAmazon Macieは必須サービスではなく、有効化されていればexposure findingsの相関に寄与するシグナルソースという位置づけです。GuardDutyは脅威検知シグナルを、Macieは機密データ露出シグナルを提供し、Security Hub CSPMの設定コンプライアンスシグナル・Amazon Inspectorの脆弱性シグナルと組み合わさることで、寄与トレイトの種類と数が増え、より精度の高いexposure findingsが生成されます。

前提条件早見表

AWS Configの扱いに関する注意点

Security Hub CSPMはAWS Config rulesを使ってコントロールのセキュリティチェックを実行しますが、新Security HubとSecurity Hub CSPMを両方有効化している環境では、Security Hub CSPMがAWSConfigurationRecorderForSecurityHubCSPMという名前のservice-linked configuration recorderを自動的に作成・管理します。そのため、この構成ではAWS Configを手動で有効化・設定する必要はありません。Security Hub CSPMを新Security Hubなしで単独有効化している場合のみ、AWS Configの手動有効化とリソースレコーディングの手動設定が必要な点に注意してください(取得日: 2026-07-14)。

手動でAWS Configを設定する必要があるケース(Security Hub CSPM単独有効化時)では、以下の点に注意が必要です。

• 有効化のタイミング依存の再試行スケジュール: AWS Configが未設定のままStandardsを有効化すると、Security Hub CSPMは「有効化当日」「翌日」「3日後」「7日後以降は7日おき」というスケジュールでservice-linked AWS Config ruleの作成を再試行します。この間はコントロールが正しく評価されません
• グローバルリソースの記録: IAMのようなグローバルリソースは、Cross-Region Aggregationを使う場合はホームリージョンでのみ記録するのが推奨構成です。複数リージョンでグローバルリソースを重複記録するとコストが無駄になります
• 記録対象外リソースの扱い: あるコントロールが評価するリソースタイプの記録がオフになっていると、そのコントロールは実際の設定を評価しないWARNINGステータスのfindingを返します。これは一見PASSEDのように見えて実は評価されていない状態のため、運用上は特に注意が必要です

本記事の前提である「新Security Hub + Security Hub CSPM + Amazon Inspector」という組み合わせでは、上記のAWS Config手動設定は不要ですが、既存環境でAWS Configを他用途にも使っている場合は、記録対象リソースタイプの設定状況を一度確認しておくことを推奨します。

exposure findingsが生成されない場合のよくある原因

前提サービスを有効化したにもかかわらずexposure findingsが確認できない場合、以下の原因が考えられます。

• Security Hub CSPMのStandards(AWS Foundational Security Best Practices等)自体は有効だが、必要なコントロールが個別に無効化されている
• Amazon Inspectorは有効だが、対象リソースタイプ(EC2 / ECR / Lambda)のスキャンが有効化されていない
• 対象リソースの寄与トレイトが不足している(軽微な設定ミス1件のみでは、しきい値に達せずexposure findingが生成されない)
• 前提サービスを有効化した直後で、near-real-timeの相関処理がまだ反映されていない
• 確認しているリージョンを間違えている(前提サービスは別リージョンで有効化されている)

有効化状態を確認するCLIコマンド

# Security Hub(新世代)の有効化状態確認
aws securityhub describe-hub --region ap-northeast-1

# Security Hub CSPMで有効なStandards(CIS/AWS Foundational等)の確認
aws securityhub get-enabled-standards --region ap-northeast-1

# Amazon Inspectorのアカウントステータス確認(EC2/ECR/Lambda各スキャン種別)
aws inspector2 batch-get-account-status --region ap-northeast-1

# GuardDutyの有効化状態確認(任意・シグナルソースとして)
aws guardduty list-detectors --region ap-northeast-1

# Amazon Macieの有効化状態確認(任意・シグナルソースとして)
aws macie2 get-macie-session --region ap-northeast-1 2>&1 | head -5

上記のうち、Security Hub CSPMとAmazon Inspectorの2つがENABLED相当の状態になっていることが、exposure findings生成の必須条件です。GuardDuty/Macieは未有効化でもexposure findingsそのものは生成されますが、相関に使われる寄与トレイトの種類が限定される点を運用上理解しておく必要があります。

確認コマンドに必要なIAMアクション

上記の確認コマンドを実行するには、以下のIAMアクションに対する読み取り権限が必要です。日次トリアージ担当のSOCアナリストには、書き込み系アクションを含まない読み取り専用ポリシーを付与するのが安全です。

読み取り専用のIAMポリシー例は以下のとおりです。SOCアナリストの日次トリアージ用ロールには、このような最小権限のポリシーをアタッチすることを推奨します。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "ExposureFindingsReadOnly",
"Effect": "Allow",
"Action": [
  "securityhub:DescribeHub",
  "securityhub:GetEnabledStandards",
  "securityhub:GetFindings",
  "inspector2:BatchGetAccountStatus",
  "guardduty:ListDetectors",
  "macie2:GetMacieSession"
],
"Resource": "*"
 }
  ]
}

2-2. 対象リージョンと有効化の確認

本記事の手順はAsia Pacific (Tokyo) リージョン(ap-northeast-1)での再現を想定しています。AWS公式のサービスエンドポイント一覧(General Reference Guide)では、Security Hubのエンドポイントとしてsecurityhub.ap-northeast-1.amazonaws.comが明記されており、東京リージョンでのサービス提供が確認できます(取得日: 2026-07-14)。あわせて、新Security HubのGAアナウンス(2025-12-02公開のAWSブログ)でも、プレビュー期間からTokyoリージョンを含む複数リージョンでの提供が案内されています。ご自身の環境で作業する際は、念のため最新のAWS公式ドキュメントまたはAWSマネジメントコンソールのリージョン一覧で有効化状態を再確認してください。

対象リージョンでの有効化確認は、以下の手順で行います。

# 現在のデフォルトリージョン設定を確認
aws configure get region

# ap-northeast-1を明示してSecurity Hubの有効化状態を確認
aws securityhub describe-hub --region ap-northeast-1 \
  --query '{HubArn:HubArn,SubscribedAt:SubscribedAt}' \
  --output table

# ap-northeast-1でAmazon Inspectorが有効か確認
aws inspector2 batch-get-account-status --region ap-northeast-1 \
  --query 'accounts[0].{State:state.status,ResourceState:resourceState}' \
  --output table

これらのコマンドがエラーなく応答し、HubArnが返ってくればSecurity Hub(新世代)は有効化済みです。Amazon Inspectorのstate.statusがENABLEDになっていれば、exposure findings生成の前提条件を満たしています。いずれかが未有効化の場合は、AWSマネジメントコンソールまたは該当サービスのAPIから有効化してください(本記事では有効化手順そのものは扱いません)。

2-3. 使用サービス・前提スタック

本記事で扱うサービスと、それぞれの本記事内での位置づけを整理します。新旧Security Hubの名称区別そのものは§1でリンクした別記事に委譲し、ここでは「本記事の中でどう位置づけて読むか」に絞って整理します。

サービス有効化の推奨順序

これから前提サービスを揃える場合、以下の順序で有効化すると、依存関係で躓きにくくなります。

1. Security Hub CSPMを有効化する(AWS Foundational Security Best Practicesなど必要なStandardsも同時に有効化)
2. Amazon Inspectorを有効化する(EC2/ECR/Lambdaのうち、実際にスキャンしたいリソースタイプを選択)
3. 任意でGuardDutyとAmazon Macieを有効化する(相関に寄与するシグナルソースを増やすため)
4. IAM Access Analyzerを有効化する(unused access情報をcontextual traitとして活用するため)
5. 数分〜数十分待ってから、get-findings-v2でexposure findingsが生成され始めていることを確認する

すでにこれらのサービスを個別に運用している環境では、上記の順序を意識する必要はありません。未有効化のサービスがあれば、上記の順序で揃えれば前提条件を満たせます。

AWS CLIバージョン要件

exposure findingsをget-findings-v2 APIで確認するには、これに対応したバージョンのAWS CLI v2が必要です。古いバージョンでは該当サブコマンドが存在しないため、事前に以下で確認してください。

aws --version
# aws-cli/2.x系であることを確認。get-findings-v2が存在しない場合はアップデートする
aws securityhub get-findings-v2 help > /dev/null 2>&1 && echo "get-findings-v2 利用可能" || echo "CLIのアップデートが必要"

2-4. ゴール状態の定義

本章を完走した時点で、以下の状態がAWSマネジメントコンソールおよびAWS CLIで確認できることをゴールとします。

• 前提サービスの有効化確認済み: Security Hub CSPMとAmazon Inspectorがap-northeast-1リージョンで有効化されており、describe-hubとbatch-get-account-statusで状態が確認できる
• シグナルソースの把握: GuardDuty/Macieが有効化されているかどうかを把握し、有効化されていない場合はどの寄与トレイトが得られないかを説明できる
• exposure findingsの参照経路確立: AWSマネジメントコンソールのSecurity Hub exposure findings画面、またはAWS CLIのget-findings-v2で、実際に生成されたexposure findingsを参照できる

コンソールでの確認手順

CLIでの確認とあわせて、AWSマネジメントコンソールからも参照経路を確認しておきます。

1. AWSマネジメントコンソールにサインインし、リージョンをAsia Pacific (Tokyo)に切り替える
2. Security Hubコンソールを開く
3. 左ナビゲーションからexposure findingsの一覧画面を選択する
4. 一覧にexposure findingsが表示されていれば、前提条件を満たし生成経路が確立されていることが確認できる
5. 表示されない場合は、2-1の「exposure findingsが生成されない場合のよくある原因」を再確認する

本章のセルフチェックリスト

§3以降へ進む前に、以下の項目をすべて満たしているか確認してください。

確認コマンドチートシート

# 直近生成されたexposure findingsを10件取得(タイトルにGuardDuty由来を含むものでフィルタ例)
aws securityhub get-findings-v2 --region ap-northeast-1 \
  --max-results 10 \
  --filter '{"CompositeFilters":[{"StringFilters":[{"FieldName":"finding_info.title","Filter":{"Value":"GuardDuty","Comparison":"PREFIX"}}]}]}'

# EC2リソースに紐づくexposure findingsのみ抽出
aws securityhub get-findings-v2 --region ap-northeast-1 \
  --filter '{"CompositeFilters":[{"StringFilters":[{"FieldName":"finding_provider_fields.types","Filter":{"Value":"Exposure/EC2","Comparison":"EQUALS"}}]}]}'

上記のコマンドが正常に応答し、exposure findingsが1件以上返ってくれば、§3以降で解説するOCSF構造・寄与トレイト・severity分類を実際のfindingで確認しながら読み進めることができます。まだfindingsが0件の場合は、前提サービスの有効化から一定時間(near-real-timeでの生成トリガが働くまでの間)を空けて再確認してください。

3. exposure findings とは — OCSF構造と寄与トレイト

exposure findingは、単一のシグナルソースが個別に生成するfindingとは異なり、複数のセキュリティシグナルを1つのリソースに対して相関させた結果として生成される、合成型のfindingです。本節では、この合成findingがどのようなデータ構造で表現され、どのような要素(トレイト)から生成されるのかを、AWS公式ドキュメントに基づいて整理します。

3-1. OCSF(Open Cybersecurity Schema Framework)による正規化

exposure findingsを含め、Security Hub(新世代)が生成するfindingは、OCSF(Open Cybersecurity Schema Framework)スキーマ(2026年7月時点でschema version 1.6に対応)で正規化されています(取得日: 2026-07-14)。OCSFはLinux Foundation配下のオープンソースプロジェクトで、ベンダー中立のコアセキュリティスキーマと、データ型・属性辞書・タクソノミーのセットを提供し、異なるセキュリティツール間でのデータ共有・正規化を目的としています。

旧世代のSecurity Hub(CSPM)はASFF(AWS Security Finding Format)でfindingを表現していましたが、新Security Hubのexposure findingはOCSFで表現される点が構造上の違いです(ASFF自体の詳細な集約方式は既存記事へ委譲します)。OCSFへの正規化により、exposure findingは他のセキュリティツール・SIEM・データレイクとの相互運用性を確保しつつ、フィールド名やカテゴリ分類が一貫した形でエクスポートできるようになっています。

3-2. exposure finding生成の仕組み

Security Hubは、次の4つの処理を通じてexposure findingを生成します(取得日: 2026-07-14)。

• 複数のAWSセキュリティサービスからのシグナル分析: GuardDutyの脅威検知finding・Amazon Inspectorの脆弱性評価finding・Security Hub CSPMの設定チェックfinding・Macieの機密データ露出findingを継続的に収集し、相関エンジンで処理してリスクの兆候を識別します
• リソース設定と関係性の評価: リソース設定をセキュリティのベストプラクティスと突き合わせて詳細評価します。サービス固有の設定・コンプライアンス要件・セキュリティコントロールを精査し、他の要素と組み合わさった場合に脆弱性となり得る誤設定を特定します
• ネットワーク到達性の評価: インターネットからの露出と内部ネットワーク経路の両方を評価します。セキュリティグループやネットワークACLの設定を分析して潜在的な攻撃経路を特定し、意図せずアクセス可能になっているリソースを識別します
• 関連するセキュリティ課題の相関: AWSリソース間の関係性をマッピングし、リソースがどう相互作用するかを分析します。IAM権限・ロール・リソースアクセスパターンを精査し、個々には無害に見える設定の組み合わせによって生じるリスクを特定します

この4つの処理が組み合わさることで、GuardDuty・Inspector・CSPM・Macieがそれぞれ個別に出力していたfindingが、1つの相関済みexposure findingとして統合される仕組みが成立しています。

3-3. exposure findingを構成する要素

AWS公式ドキュメントでは、1件のexposure findingは次の要素で構成されると説明されています(取得日: 2026-07-14)。

exposure findingは1リソースにつき最大1件しか生成されません。あるリソースに寄与トレイトが存在しない、または十分な数のトレイトが揃っていない場合、そのリソースに対するexposure findingは生成されない点にも注意が必要です。§2で触れた「軽微な設定ミス1件のみでは生成されない」という挙動は、この仕組みに基づいています。

3-4. 寄与トレイト(contributing trait)の5分類

exposure findingの寄与トレイトは、以下の5種類に分類されます。それぞれどのAWSサービスのfindingを根拠に生成されるかが公式ドキュメントで明記されています(取得日: 2026-07-14)。

各トレイトには、そのリソースへの具体的な影響を示す「タイトル」が複数紐づくことも珍しくありません。たとえばVulnerabilityトレイトには「Exploit Available」のようなタイトルが付与されます。これは、悪用コードが既に公開されている脆弱性であることを示します。

なお、公式ドキュメントではこの5つの寄与トレイトに加えて、Impact(影響)という別種のトレイトも定義されています。Impactは寄与トレイトと同列で扱われますが、finding生成の直接の根拠というよりも「侵害された場合にどこまで影響が波及するか」を示す指標であり、リソースに関連付けられたIAMプリンシパルの実効権限(effective permissions)分析に基づいて算出されます。Impactトレイトの評価ロジックは、severityのimpact軸として§4で扱います。

3-5. 寄与トレイトとコンテキストトレイトの違い

寄与トレイトとコンテキストトレイトは、どちらもexposure findingの詳細画面に表示されますが、役割が異なります。

• 寄与トレイト(contributing trait): そのexposure findingが生成される直接の根拠となった要素。上記5分類のいずれかに該当します
• コンテキストトレイト(contextual trait): finding生成の根拠にはならないものの、対処の優先順位付けを助ける追加情報。代表例はIAM Access Analyzerが検出するunused access(未使用アクセス許可)情報です

たとえば、あるEC2インスタンスにソフトウェア脆弱性(Vulnerabilityトレイト)があり、そのインスタンスにアタッチされたIAMロールが5つのサービスにまたがる47個の未使用権限を持っている場合、この未使用権限情報はコンテキストトレイトとしてexposure findingの詳細に補足表示されます。過剰な権限を持つIAMロールほどリスクが高い、すなわち侵害された場合に未使用権限が悪用され得るという理解を助ける材料になります。コンテキストトレイトを含む具体的な影響範囲の評価方法は§5で扱います。

コンテキストトレイトとしてunused access情報が表示される対象リソースは、Amazon EC2インスタンス・AWS Lambda関数・Amazon ECSサービス・Amazon EKSクラスター・IAMユーザー(直接)です。

OCSF正規化されたexposure findingがトレイトの組み合わせとして構造化されていることで、GuardDuty・Inspector・CSPM・Macieの結果を個別に確認する従来の運用と比べて、自動化された相関による手動分析の削減と、リスクに基づき優先順位付けされたビューの両方が得られます(取得日: 2026-07-14)。この構造を踏まえたうえで、次節ではseverityがどのように算出されるかを見ていきます。

4. severity分類とリスク優先度スコアリング

Security Hubはexposure findingごとに、デフォルトのseverityとしてCRITICAL・HIGH・MEDIUM・LOWのいずれかを割り当てます。INFORMATIONAL相当と判定されたexposure findingは公開されません(取得日: 2026-07-14)。

4-1. severityを決める2つの軸 — likelihoodとimpact

severityは単一のスコアではなく、likelihood(悪用されやすさ)とimpact(影響の大きさ)という2つの軸を組み合わせたリスクマトリクスによって決定されます。likelihoodはその露出がどれだけ容易に悪用され得るかを、impactは悪用された場合の被害の大きさを表します。

公式ドキュメントで示されているリスクマトリクスは以下のとおりです(取得日: 2026-07-14)。

このマトリクスは、likelihoodがベースラインのseverityを決め、impactがそれを補正する構造になっています。impact補正の内訳は次のとおりです。

• impactがHighの場合: severityを1段階引き上げます(上限はCritical)
• impactがMediumの場合: severityは変化しません
• impactがLowの場合: severityを1段階引き下げます(下限はLow)

なお、対象リソースに対してimpactを判定できないケースでは、likelihoodのみに基づいてseverityが決定されます。

4-2. likelihood(悪用されやすさ)の判定要素

likelihoodは、§3で解説した寄与トレイト(Assumability・Misconfiguration・Reachability・Sensitive Data・Vulnerability)の存在状況をもとに、以下の観点から評価されます(取得日: 2026-07-14)。

これらの観点は、単純なCVSSスコアだけでは捉えきれない実環境の文脈を反映しています。CVSSは脆弱性そのものの技術的な深刻度を評価する指標ですが、実際にそのリソースがインターネットに到達可能かどうか、悪用コードが既に出回っているかどうかといった環境固有の条件までは考慮しません。exposure findingのlikelihoodは、この環境コンテキストを寄与トレイトの組み合わせとして取り込むことで、同じ脆弱性でも到達性や悪用実績の有無によって優先度が変わる仕組みを実現しています。

4-3. impact(影響の大きさ)の判定要素

impactは、その露出が悪用された場合に環境へ与える被害の大きさを表します。公式ドキュメントでは、次の4種類の損失観点が示されています(取得日: 2026-07-14)。

impactを評価するため、Security Hubは対象リソースに関連付けられたIAMプリンシパルの実効権限(effective permissions)を分析し、攻撃者がどのようなアクションやAWSサービスを呼び出せるかを特定します。さらに、権限昇格を通じて攻撃者が到達し得る既存リソースも特定します。この実効権限分析の結果は、§3で触れたImpactトレイトとして表現され、attack path(攻撃経路)とblast radius(影響範囲)の可視化に使われます。可視化そのものの読み解き方は§5で扱いますが、ここではimpact軸が単なる脆弱性の深刻度ではなく、そのリソースを起点にどこまで被害が波及し得るかを表している点を押さえておいてください。

4-4. 対処順序への活用

Critical/Highのexposure findingを優先して対処するのが基本方針ですが、公式ベストプラクティスでは、severityだけでなくリソースの重要度やビジネスへの影響も踏まえたリスクベースの優先順位付けを推奨しています(取得日: 2026-07-14)。たとえば同じHigh severityのexposure findingが2件あった場合でも、一方が本番環境の顧客向けAPIを提供するリソースで、もう一方が開発環境の検証用リソースであれば、前者を先に対処すべきと判断できます。

さらに、公式ベストプラクティスではseverityに応じたレビュー頻度も示されています(取得日: 2026-07-14)。日次・週次・月次・四半期という多層的なレビュー体制を敷くことで、即応が必要なリスクと、長期的なセキュリティ姿勢の両方に目を配れるようになります。

具体的な日次トリアージのワークフロー(レビュー→優先度判断→remediation→再評価のサイクルや自動化との連携)は§7で扱います。ここでは、severityがそのまま「いつ・どのくらいの頻度で見るべきか」という運用リズムに直結する指標であることを押さえておいてください。

具体例として、§1で触れたEC2インスタンスのケースを振り返ります。このインスタンスがインターネットから到達可能(Reachabilityトレイト)で、かつ悪用コードが公開済みの既知の脆弱性(Vulnerabilityトレイト、Awarenessが高い)を持つ場合、ease of discovery・ease of exploit・awarenessのいずれも高くなるため、likelihoodは「Very High」相当と判断できます。さらに、このインスタンスにアタッチされたIAMロールが広範な実効権限を持っている場合、impactは「High」と判断され、リスクマトリクス上ではlikelihood=Very High・impact=Highの組み合わせとなり、severityはCriticalと判定されます。この場合、SOCアナリストは「今日中に対処すべき」exposure findingとして扱うべきと判断できます。

一方、likelihoodもimpactも低いケースも押さえておく価値があります。たとえば、インターネットから到達不能な社内検証用リソースに軽微な設定ミス(Misconfigurationトレイトのみ)が1件見つかった場合、ease of discovery・ease of exploitともに低く、impactも限定的であるため、likelihoodは「Low」、impactは「Low」と判断され、severityはLowにとどまります。このように、同じ「設定ミスがある」という状態でも、到達性や影響範囲の文脈次第でseverityは大きく変わります。これが、単純なCVSSベースの評価と異なる本質的なポイントです。

5. attack path と blast radius の読み解き

exposure findingの構成要素として§3-3で触れた「attack path/blast radius可視化」を、本節では実際にどう読み解き、日々の判断に活かすかという観点で解説します。Security Hubコンソール上のこの可視化は、公式には「potential attack path graph(潜在的な攻撃経路グラフ)」と呼ばれています(取得日: 2026-07-14)。

5-1. potential attack path graphとは — 何を可視化しているか

potential attack path graphは、Security HubコンソールのExposuresページからexposure findingの詳細を開き、Overviewタブの「Potential attack path and Blast radius」セクションで確認できるインタラクティブな可視化図です(取得日: 2026-07-14)。このグラフは、exposureが生成された起点となる主要リソース(primary resource)、ネットワーク経路(該当する場合)、そして攻撃者が権限昇格によって到達し得るダウンストリームリソースを示します。

グラフを構成する要素は次のとおりです。

• ノード: 1つ1つのAWSリソースを表します
• エッジ(接続線): あるリソースから別のリソースへ攻撃者が移動することを可能にする権限関係を表します
• 凡例(レジェンド): primary resource・involved resource・blast radius resources・寄与トレイト数を色分けで示し、トレイトのカテゴリと件数も併記されます

Security Hubが主要リソースから他リソースへの具体的な権限昇格経路を特定した場合、その経路がグラフのblast radius部分として表示されます。つまり、このグラフに表示されているダウンストリームリソースは単なる理論上の可能性ではなく、Security Hubが実際にたどれることを確認した経路だという点が重要です。

グラフはドラッグ操作でリソースの位置を調整でき、ズームイン/ズームアウトやフルスクリーン表示にも対応しています。リソースを選択すると詳細情報の表示やリソースID・AWSアカウント番号のコピーができます。Reachabilityトレイトを持つexposure findingでは、インターネットとの間の(折りたたまれた)ネットワーク経路もノードとして表示され、選択すると展開して詳細を確認できます(取得日: 2026-07-14)。

5-2. Impact assessmentタブ — 実効権限のチェーンを追う

potential attack path graphの隣にある「Impact assessment」タブでは、ダウンストリームリソースへの権限昇格経路をより詳細に確認できます。各経路は、攻撃者がたどり得るリソースの連鎖と、その各段階で使われる具体的な権限を示します(取得日: 2026-07-14)。

この経路は、§4-3で触れたImpactトレイトの実体です。Security Hubは、リソースに関連付けられたIAMプリンシパルの実効権限(identity-basedポリシーとresource-basedポリシーを組み合わせて評価した、実際に行使可能な権限)を分析し、主要リソースを起点とした権限昇格経路を追跡します。具体的な到達先リソースが特定できた場合、その経路がImpactトレイトの一部として提示されます。さらにImpactトレイトは、経路化しにくい権限、たとえば他リソースを作成・変更できるAWSサービスの呼び出し能力のようなものも加味して評価されます(取得日: 2026-07-14)。

Impact assessmentタブを確認する際は、「どのリソースに到達できるか」だけでなく「どの権限が経路の各段階を成立させているか」まで見ることが重要です。経路上のどこか1段階の権限を取り除くだけで、それ以降のダウンストリームリソースへの到達を遮断できる場合があるためです。

5-3. unused access(コンテキストトレイト)をblast radius評価に組み込む

§3-5で、あるEC2インスタンスの脆弱性(Vulnerabilityトレイト)と、アタッチされたIAMロールの47個の未使用権限(5サービスにまたがるunused access情報)がコンテキストトレイトとして表示される例に触れました。ここでは、このコンテキストトレイトをblast radius評価にどう組み込むかを掘り下げます。

unused access情報自体は寄与トレイトではないため、そのexposure findingのseverityやImpactトレイトの算出には直接使われません。しかし、over-privilegedなIAMロール(実務では使われていない権限を多く持つロール)は、たとえ現時点のpotential attack path graphに具体的な権限昇格経路として現れていなくても、将来的にそのロールの権限が悪用された場合の潜在的な被害が大きいことを意味します(取得日: 2026-07-14)。

実務上は、次のような判断に使えます。

• potential attack path graphに具体的な経路が表示されている場合: その経路上の権限を優先して削除し、blast radiusを直接縮小します
• 経路としては表示されていなくても、unused accessの多いIAMロールがコンテキストトレイトとして提示されている場合: 現時点のリスクは経路化されたものより低いものの、最小権限化(不要な権限の削除)を予防的な対処として計画に組み込みます

unused access情報を持つリソースがEC2インスタンス・Lambda関数・ECSサービス・EKSクラスター・IAMユーザー(直接)に限られる点は§3-5のとおりですが、本節ではこれを「経路化されていない潜在リスク」として日次判断にどう位置づけるかに焦点を当てました。

5-4. 可視化から次アクションへ — 読み解きの実務フロー

§1で触れたCriticalなexposure finding(インターネット到達可能で既知の脆弱性を持つEC2インスタンス)を例に、attack path graphを実際にどう読み進めるかを整理します。

1. Overviewタブでpotential attack path graph全体を眺め、primary resource(該当EC2インスタンス)を起点にネットワーク経路とダウンストリームリソースの有無を確認します
2. Reachabilityトレイトがある場合、折りたたまれたネットワーク経路ノードを展開し、インターネットからの到達経路を具体的に確認します
3. Impact assessmentタブで、権限昇格によって到達可能なダウンストリームリソースと、各段階の具体的な権限を確認します
4. コンテキストトレイトを確認し、経路化されていないunused accessがあれば、将来的なblast radius拡大要因として評価に加えます
5. 経路上の不要な権限、またはunused accessとして指摘された権限を削除し、remediation後にグラフを再確認してblast radiusが縮小したことを確かめます

公式ドキュメントも、potential attack path graphで経路を確認したうえで不要な権限を削除しblast radiusを縮小することを推奨しています(取得日: 2026-07-14)。攻撃経路とblast radiusの可視化は、severityの数値だけでは見えない「侵害された場合にどこまで波及するか」を具体的なリソース単位で示すため、日次トリアージで対処順序を決める際の重要な判断材料になります。日次トリアージのワークフロー全体は§7で扱います。

6. near-real-time相関の運用 — シグナルの”使い方”

6-1. near-real-time相関とは — 運用上何が変わるか

Security Hub(新世代)は、GuardDuty・Amazon Inspector・Security Hub CSPM・Macieが生成するシグナルを継続的に収集・分析し、near-real-timeでexposure findingsに反映します(取得日: 2026-07-14)。GA発表では、near real-timeのリスク分析と高度なトレンド分析によって相関済みのセキュリティシグナルを実用的なインサイトへ変換する機能として案内されていますが、具体的な更新間隔(何秒/何分でfindingに反映されるか)は公式ドキュメント上で明示されていません(取得日: 2026-07-14)。そのため本記事では、正確な反映速度を断定せず「シグナルが増えるたびに継続的に更新され続ける」という運用モデルとして扱います。

この運用モデルが従来と大きく異なる点は、exposure findingを”生成されたら固定される一過性のレコード”としてではなく、”生きたレコード”として扱う必要があることです。たとえば、あるリソースについて一度Lowと判定されたexposure findingが、後からGuardDutyで新たな脅威シグナルが検知されたことで寄与トレイトが増え、severityがHighやCriticalへ引き上げられる、という更新が起こり得ます。日次トリアージで「一度確認済み」を理由に対応不要と判断したexposure findingも、near-real-time相関によって内容が変わっている可能性がある点を運用上意識しておく必要があります。

6-2. シグナルソース別の”使い方”

near-real-time相関は、4つのシグナルソースそれぞれが担う役割を理解しておくと運用しやすくなります(取得日: 2026-07-14)。

GuardDutyの検知エンジン内部はExtended Threat Detection Vol2へ

6-3. 複数シグナルが1つの相関結果にまとまる運用上の意味(unified enablement)

新Security Hubでは、上記4つのシグナルソースの結果が個別のダッシュボードにではなく、単一のexposure finding・単一のコンソール上に統合されます。公式にはこの一元化された仕組みは”unified enablement”の一部として案内されています(取得日: 2026-07-14)。この統合によって、SOCアナリストはGuardDuty・Inspector・Macie・CSPMそれぞれのコンソールを個別に巡回する必要がなくなり、相関済みのexposure findingsを起点に対処順序を判断できるようになります。

ここで運用上注意すべき点は、相関の精度は有効化されているシグナルソースの数に依存するということです。§2-1で触れたとおり、Security Hub CSPMとAmazon Inspectorは必須サービスですが、GuardDutyとMacieは任意のシグナルソースです。GuardDutyやMacieを有効化していない環境では脅威系やSensitive data系の寄与トレイトを得られないため、同じリソースでも本来より低いseverityでexposure findingが生成されます。寄与トレイトの不足度合いによっては、そもそもexposure finding自体が生成されないケースもあります。相関結果を評価する際は、どのシグナルソースが有効化されているかを運用チーム側で把握しておくことが前提になります。

なお、複数アカウント・複数リージョンにまたがる有効化管理の仕組みそのものは、本記事の主題である運用深掘りとは別レイヤーの話題のため、§1でリンクしたマルチアカウント基盤Vol2 §4-1に委譲します。ここでは単一アカウント内で複数シグナルソースが1つの相関結果にまとまる、という運用上の意味に絞って扱いました。

6-4. 相関結果を日次運用にどう接続するか

near-real-timeで更新され続ける相関結果を日次運用に落とし込むには、次の2点を運用ルールとして定めておくことが有効です。

• 再確認のトリガーを決めておく: 一度triage済みのexposure findingであっても、寄与トレイトの数やseverityが変化した場合は再度triage対象に戻す、というルールを運用フローに組み込みます
• 有効化状況の定期棚卸し: GuardDuty/Macieのような任意のシグナルソースが意図せず無効化されていないかを、日次とは別に定期的に確認します。有効化状況が変わると相関結果の質そのものが変わるためです

これらのルールを踏まえたうえで、具体的なSOCアナリストの日次トリアージワークフロー(レビュー→優先度判断→remediation→再評価のサイクル)は§7で扱います。

7. SOCアナリスト日次トリアージ運用ワークフロー

§1〜§6で確立したOCSF構造・severity分類・attack path/blast radius評価・near-real-time相関の理解を、本節ではSOCアナリストの実際の日次オペレーションに接続します。AWS公式のベストプラクティスでは、日次のCritical exposureレビュー・週次の全体状況評価・月次のトレンド分析・四半期のセキュリティ姿勢評価という多層的なレビュー体制の実施が推奨されています(取得日: 2026-07-14)。本節では、この多層体制のうち日次レビューを軸に、1件のexposure findingを受信してからエスカレーションに至るまでの実務フローを解説します。

7-1. 日次トリアージの5ステップ

日次トリアージは、大きく分けて「受信」「severity確認」「attack path/blast radius評価」「対処判断」「エスカレーション」の5ステップで構成されます。AWSセキュリティブログでは、Security Hubコンソール上でこのフローを実践するための具体的な画面遷移が案内されています(取得日: 2026-07-14)。

7-2. ステップ①〜③: 受信から評価まで

まずexposure summaryウィジェットで、直近に生成・更新されたexposure findingのうち優先度の高いものを俯瞰します。次にexposure findingsダッシュボードへ遷移し、severity・対象アカウント・リソースタイプによるクイックフィルタでCritical/Highを絞り込みます。この段階での絞り込みは、あくまで対処順序の仮決めであり、確定ではありません。

絞り込んだ各findingは、詳細画面を開いて寄与トレイトとコンテキストトレイトの内容を確認します。ここで、severityの数値だけを見て次のステップへ進まないことが重要です。§5で解説したpotential attack path graphとImpact assessmentタブを実際に開き、このexposureが悪用された場合にどのリソースまで影響が波及し得るかを、グラフ上で具体的に確認します。§5-3で触れたunused access情報がコンテキストトレイトとして提示されている場合は、経路化されていない潜在的なblast radius拡大要因としてあわせて記録しておきます。

7-3. ステップ④〜⑤: 対処判断からエスカレーションまで

attack path/blast radiusの評価結果を踏まえ、対処順序を判断します。§4-4で触れたとおり、同じHigh severityのexposure findingでも、本番環境の顧客向けリソースか開発環境の検証用リソースかでリソース重要度・ビジネス影響が異なるため、severityの数値のみで機械的に順序を決めないことが求められます。

SOCアナリスト単独で対処が完結しない場合は、エスカレーションに進みます。エスカレーションが必要になる典型的な状況は、次のとおりです。

• 是正にリソースオーナーの承認や、他チームが管理するIAMポリシー・ネットワーク設定の変更が必要な場合
• attack path graph上で、本番稼働中の重要システムまでダウンストリームリソースとして到達している場合
• remediation内容がビジネス影響(サービス停止を伴う可能性等)を含み、単独判断で実施できない場合

Security Hubは、コンソールから直接チケットを起票できるAutomation Ruleの機能を備えており、Jira Service ManagementやServiceNowといった主要なサービス管理ツールとのネイティブ統合を通じて、手動でのチケット起票作業を削減できます(取得日: 2026-07-14)。エスカレーション先チームへの引き継ぎは、この機能を使ってfinding単位で追跡可能な形にしておくと、対処漏れを防ぎやすくなります。

7-4. 週次・月次・四半期レビューへの接続

日次トリアージで個別findingを処理するだけでなく、§6-4で触れた再確認のトリガーと、より長い時間軸のレビューを組み合わせることで、運用サイクル全体が機能します。

• 週次: 日次で処理しきれなかったfindingを棚卸しし、exposure状況全体の傾向を確認します
• 月次: severityの分布推移や、どの寄与トレイトの組み合わせが増えているかといったトレンドを分析します
• 四半期: 前提サービスの有効化状況(§2)を含め、セキュリティ姿勢全体を評価します

日次でtriage済みと判断したexposure findingであっても、near-real-time相関によって寄与トレイトやseverityは更新され続けます。この点は§6-1で触れたとおりです。週次レビューのタイミングで、直近1週間にseverityが引き上げられたfindingの有無をあわせて確認しておくと、日次トリアージの取りこぼしを補完できます。

7-5. 自動化との連携(概観)

Security HubのAutomation Ruleは、finding上の各種フィールドの自動更新・severityやworkflow statusの変更・重複findingのsuppression・チケットの自動起票といった機能を提供しており、これらを組み合わせることで一貫性のあるタイムリーな対処と、監査証跡の維持を実現できます(取得日: 2026-07-14)。

本Vol1では、Automation Ruleが日次トリアージの効率化にどう寄与するかという概観にとどめます。§1で触れたとおり、具体的なAutomation Ruleの設計やTerraformによる運用パイプラインの構築は、本Vol1で確立した運用基盤の上に、次Vol以降で扱う予定です。

8. つまづきポイント・アンチパターン(運用面)

exposure findingsの日次運用に取り組み始めた組織でよく見られる、つまづきポイントとアンチパターンを整理します。いずれも§1〜§7で解説した内容の裏返しであり、あわせて確認しておくと運用の型化に役立ちます。

8-1. severityの数値だけで優先度を判断する

severityはlikelihoodとimpactを組み合わせたリスクマトリクスから算出される合成指標です(§4-1)。severityの数値だけを見て対処順序を機械的に決めてしまうと、attack path graphが示す具体的な影響範囲(§5)を見落とし、実際にはblast radiusが大きいfindingの対処が後回しになる恐れがあります。severityは対処順序の出発点として扱い、attack path/blast radiusの評価をセットで行うことが必要です。

8-2. exposure findingsと個別サービスのfindingsを混同する

GuardDuty・Amazon Inspector・Amazon Macieはそれぞれ個別にfindingを出力しますが、exposure findingsはこれらを相関させた別種のfindingです(§3)。GuardDutyコンソール単体のアラート一覧だけを確認して「exposure findingsも確認した」と誤認してしまうと、他シグナルとの相関によって初めて見える寄与トレイトの組み合わせ(§3-4)を見落とします。§6-3で触れたunified enablementの意図は、個別コンソールの巡回を相関済みのexposure findingsへ置き換える点にあります。この運用方針をチーム内で共有しておく必要があります。

8-3. 前提サービスの設定変更に気づかない

exposure findingsの生成には、Security Hub CSPMとAmazon Inspectorという2つの必須サービスの有効化が前提です(§2-1)。運用開始時には有効化を確認していても、その後の設定変更(特定コントロールの無効化、Inspectorのスキャン対象リソースタイプの変更等)によってexposure findingsが生成されなくなっていることに、しばらく気づかないケースがあります。§7-4で触れた四半期レビューのタイミングで、前提サービスの有効化状況を棚卸しに含めておくことが有効です。

8-4. トリアージ済みのfindingを”確定”として扱う

exposure findingsはnear-real-timeで更新され続ける”生きたレコード”です(§6-1)。一度triage済みとしてクローズしたfindingが、後から寄与トレイトの増加でseverityが引き上げられる可能性を考慮せず放置してしまうと、実質的に対応漏れとなります。§6-4・§7-4で触れた再確認のトリガーを運用フローに組み込み、週次レビューでの補完確認を欠かさないことが重要です。

8-5. コンテキストトレイトを軽視する

unused access情報のようなコンテキストトレイトは、severityやImpactトレイトの算出には直接使われません(§3-5)。この位置づけを理由に「寄与トレイトではないから見なくてよい」と判断してしまうと、経路化されていない潜在的なblast radius拡大要因(§5-3)を見落とすことになります。現時点で経路化されていなくても、over-privilegedなIAMロールは予防的な最小権限化の対象として日次レビューの視野に入れておく必要があります。

8-6. 新旧Security Hubの名称を混同する

新旧Security Hubの名称区別・GAの基本・委任管理者Organizations展開そのものは、本記事のスコープ外であり、マルチアカウント基盤Vol2 §4-1で詳しく解説しています。日次運用のアンチパターンとしては、この名称混同によってコンソール上のどの画面がexposure findingsに対応するかを取り違え、旧世代のASFF集約結果(Standards評価等)をexposure findingsと誤認してしまうケースがある点だけ触れておきます。

新旧Security Hubの名称混同を避けたい方はマルチアカウント基盤 Vol2 §4-1へ

9. まとめ

本記事では、新Security Hubが生成するexposure findingを”生成されたら終わり”の一過性イベントとしてではなく、日次で読み解き優先度順に対処する運用サイクルとして回せるようになることをゴールに掲げました(§1)。ここまでの内容を振り返ると、以下の到達状態を確認できます。

• exposure findingのOCSF正規化された構造と、5種類の寄与トレイト(Reachability / Vulnerability / Sensitive data / Misconfiguration / Assumability)の意味を説明できるようになりました(§3)
• likelihoodとimpactの2軸からseverityが決まる仕組みを理解し、単純なCVSSスコアだけでは見えない環境コンテキストを踏まえて対処順序を判断できるようになりました(§4)
• potential attack path graphとImpact assessmentタブから、攻撃経路と影響範囲を具体的に評価できるようになりました(§5)
• GuardDuty / Amazon Inspector / Amazon Macie / Security Hub CSPMのnear-real-time相関結果を、能動的なトリアージ材料として扱えるようになりました(§6)
• 受信からエスカレーションまでの日次トリアージワークフローと、週次・月次・四半期レビューへの接続を運用フローとして組み込めるようになりました(§7)
• severity過信・findingの混同・確定扱い・コンテキストトレイト軽視といった運用面のアンチパターンを避けられるようになりました(§8)

本記事は、新旧Security Hubの名称区別・GAの基本・委任管理者Organizations展開・GuardDuty検知エンジンの内部・旧Security Hub(CSPM)のASFF集約といった導入面・個別サービス面のトピックは扱わず、既存の関連記事へ委譲したうえで、exposure findingsの運用深掘りに焦点を絞りました。これらのスコープ外領域を詳しく知りたい方は、以下の関連記事もあわせてご参照ください。

本Vol1で確立した「exposure findingを読み、優先度を判断し、日次運用に組み込む」という基盤の上に、次Vol以降ではAutomation Rulesを使った対処の自動化や、Terraformによる運用パイプラインの構築といったテーマへ発展させていく予定です。日々のトリアージを属人化せず回せる状態になったところが、本シリーズの次の一歩に進むための土台になります。