AWS Security Hubでの露出の検出結果を使用した情報セキュリティリスクの優先順位付けについて

1. なぜ「重大度が高い順」だけでは優先順位が決まらないのか

1-1. 情報セキュリティ運用で詰まりやすいポイント

AWS 環境の情報セキュリティ運用をやっていると、InspectorやSecurity Hub CSPM、GuardDutyなど複数サービスから日々大量の検出結果が上がってきます。

それぞれに重大度（Critical / High / Medium / Low）が付いているので、「とりあえずCriticalから片付ければいいんでしょ？」と思いたくなるのですが、実際に運用してみると、Criticalの件数を消化することが目的化してしまい、本当に危険なリソースが後回しになる、という本末転倒な状態に陥りがちです。

Criticalが多すぎて、結局どれから手を付けるか決められない。

マルチアカウントで複数アカウントを管理していると、Criticalだけで数百件になることも珍しくありません。

単体の検出結果だけでは「実際どのくらいヤバいのか」が分からない。

たとえば「SGのポートが開いている」という検出結果があっても、そのインスタンスにインターネットから到達できるかどうかで緊急度はまったく変わります。

リソース同士の関係性が見えない。

インターネットに露出したEC2に管理者権限のIAMロールが紐付いている、といった「組み合わせの危険性」は、個別の検出結果を眺めているだけでは見落としがちです。

つまり重大度は「その検出結果単体のリスク評価」であって、環境全体をふかんした優先順位にはなっていないわけです。

1-2. 検出結果の多さと対応の遅れが起きる構造

情報セキュリティチームが数百〜数千件の検出結果を手動で突き合わせていくと、だいたい以下のような悪循環にはまります。

1. 検出結果が多すぎて、優先順位付だけで時間を消費する
2. 個別の検出結果を深追いしてしまい、全体像が見えなくなる
3. 本当に危険な組み合わせが埋もれる
4. 対応が後手に回り、インシデント発生後の火消しが増える

「検出結果が上がってくるのはうれしいけど、結局どうすればいいの？」という状態、CSPMを運用したことがある方なら一度は経験があるのではないでしょうか。

この構造を打破するために登場したのが、Security Hubの「露出の検出結果」です。

NTT東日本ではAWSの導入・移行・運用の支援を行っております。詳しくはこちらからお問い合わせください。

2. 露出とは何か

2-1. 露出がやっていること

従来でも、InspectorやGuardDuty、CSPMなどの検出結果を集約して重大度で並べることはできていました。

ただ、あくまで「個々の検出結果に重大度が付いて、一覧で見られる」という段階で、検出結果同士の関係性まではつないでくれませんでした。

たとえば「このEC2はInspectorで脆弱性が出ていて、かつSGが0.0.0.0/0で開いていて、かつIAMロールにAdministratorAccessが付いている」という組み合わせのリスクを把握するには、検出結果をフィルタしてリソース単位で突き合わせたり、自前のスクリプトなどで頑張る必要がありました。

露出の検出結果は、ここをSecurity Hub側で自動的にやってくれるのが大きな進化です。

具体的には、以下のプロセスで露出を生成します。

1. 複数のAWSセキュリティサービスから情報を収集
2. リソースの設定やリソース間の関係性を評価
3. ネットワーク到達性を分析
4. 関連する情報セキュリティ問題を相関付け、攻撃パスを特定

従来との一番の違いは、「ネットワーク到達性の自動評価」と「攻撃パスの可視化」が加わったことです。

SGやネットワークACLの設定を解析して「このリソースにはインターネットから実際に到達できるのか」まで判定してくれるので、「SGが開いているけど、パブリックIPがなく、ALBの入口もなく、ルート的にも外部から到達できない構成」というケースを無駄にCritical扱いせずに済みます。

従来のSecurity HubだとSGのルール違反は一律で検出されてしまい、到達性の有無までは考慮されなかったので、ここは明確な改善ポイントです。

2-2. 露出で見えるようになる観点

露出の検出結果では、従来のSecurity Hubで別々に確認していた情報が一画面にまとまります。

実際の運用で効果を感じるのは攻撃パスです。「インターネット→EC2（脆弱性あり）→IAMロール（管理者権限）→S3（機密データ）」のような攻撃の経路が視覚的に表示されるので、経営層やアプリチームに「なぜこのリソースの対応が急務なのか」を説明しやすくなります。

2-3. 露出の対象範囲

露出の検出結果は、以下のAWSサービスからの情報を取り込みます。

• Security Hub CSPM — 設定のベストプラクティスへの準拠
• Inspector — ソフトウェア脆弱性の検出
• GuardDuty — 脅威の検出（不審なアクティビティ、アカウント侵害の兆候など）
• Macie — 機密データの検出と分類

ここで注意しておきたいのは、これらのサービスを有効化していないと、そもそも露出の精度が上がらないということです。

たとえばMacieを有効化していなければ「機密データが含まれるS3バケットが露出している」というシグナルは生成されません。

露出の検出結果を活用するなら、まずはこれらのサービスの有効化状況を確認しておきましょう。

対象リソース

露出の検出結果が生成される主なリソースは以下のとおりです。

• EC2
• ECS
• EKS
• Lambda
• S3
• RDS
• DynamoDB
• IAM

最新の対応範囲は公式ドキュメントを参照ください。

NTT東日本ではAWSの導入・移行・運用の支援を行っております。詳しくはこちらからお問い合わせください。

3. 露出を確認して手を付ける順番を決める

3-1. まず見るべき指標

Security Hubコンソールにログインすると、サマリーダッシュボードに「露出サマリーウィジェット」が表示されます。ここで最初に確認すべき指標は以下の3つです。

1. Criticalの件数 — 即時対応が必要なリスク。悪用の容易さ・影響度ともに高い
2. Highの件数 — 優先的に対応すべきリスク。特定条件下で悪用される可能性がある
3. 露出タイトルごとの傾向 — 同じタイプの露出が繰り返し出ていないかをチェック

3-2. フィルタ／グループ化のコツ

露出ダッシュボードに移動したら、フィルタを活用して効率よく絞り込みましょう。

• 重大度でフィルタ — まずはCritical→Highの順に絞る
• アカウントIDでフィルタ — マルチアカウント環境では、本番アカウントを優先
• リソースタイプでフィルタ — EC2、S3、Lambdaなど攻撃面が大きいリソースに注目
• グループ化 — アカウントIDやリソースタイプで束ねると、対応の塊を作りやすい

おすすめの手順としては下記になります。

1. Critical×本番アカウントでフィルタ
2. リソースタイプでグループ化して影響範囲を把握
3. 件数が多いタイトルを優先的に展開

実際にやってみると、「EC2の露出が8割」みたいにリソースタイプが偏っていることがあります。

そういう場合は、EC2に対する横断的な対策を検討するきっかけにもなります。

3-3. 露出詳細の読み方

個別の露出を展開すると、3つのタブで情報が整理されています。

概要

• 重大度、リソースID、作成日時、リージョン
• 攻撃パス — 攻撃者がどのような経路でリソースに到達し得るかを視覚的に表示。ここが露出の一番の目玉可と思います。

特性

• Misconfiguration（設定ミス）、Vulnerability（脆弱性）などの特性タイプごとに分類
• 各シグナルを選択すると、CSPMやInspectorなど元の検出結果レベルで詳細を確認できる。「この露出の元ネタは何なのか」を追いたいときに使います

リソース

• 露出に関連するすべてのリソース（EC2、S3、IAMロールなど）の一覧。修正すべきリソースの特定と対応範囲の見積もりに活用できます

読み方のポイントとしては、まず攻撃パス図で「インターネット→リソース→機密データor権限」の連鎖がないかを真っ先に確認すること。この連鎖があるものは、被害が大きくなりやすいので最優先です。

3-4. 初動30分の進め方

露出の検出結果を使った初動トリアージの流れを、30分の目安で整理します。

初めてやるときは少し時間がかかりますが、慣れると15分くらいで回せるようになります。

ちなみに、EventBridgeでSecurity Hubの検出結果イベントを拾って通知できます。

Criticalの露出が生成されたタイミングでSlackやTeamsに自動通知する仕組みを作っておくと、毎朝ダッシュボードを見に行かなくても検知できます。

特定パターンの露出に対して自動でチケットを起票することも可能なため、設定しておくと便利です。

NTT東日本ではAWSの導入・移行・運用の支援を行っております。詳しくはこちらからお問い合わせください。

4. 優先順位付けを運用に落とす

4-1. 優先順位の判断軸

露出の検出結果を日々の運用に組み込むためには、チームで共通の判断軸を定めておくことが重要です。「人によって判断が変わる」状態だと、結局優先順位付に時間がかかって元の木阿弥になってしまいます。

Security Hubが複数の要因をもとに 「いま現実的に危険で、優先してつぶすべきもの」を判断した結果だという点です。露出検出結果の重要度は、主に次の要素を加味して決まります。

認知度

露出が理論上のものではなく、すでに公開されている、または自動化されたエクスプロイトが存在する程度（※EC2/Lambda の露出に適用）

検出の容易さ

ポートスキャンやインターネット検索などの自動ツールで、リスクのあるリソースを見つけられるか。

悪用の容易さ

脅威アクターが露出を悪用しやすい条件がそろっているか（例：オープンなネットワークパス、誤って設定されたメタデータなど）。

悪用の可能性

今後30日間に悪用される確率（※EPSSに対応。EC2/Lambda の露出に適用）

影響

悪用された場合の損害の大きさ（説明責任の喪失、可用性低下、機密性の喪失など）

つまり、運用としては「Criticalが多いから上からつぶす」ではなく、Security Hubが重要度算出に使っているこの5要素を意識して、

「見つけられやすいか、すぐ悪用できる状態か、近いうちに悪用されそうか、やられた時に被害が大きいか」

を短時間で説明できる形にして、対応判断と担当アサインにつなげるのがポイントです。

露出検出結果は、これらの観点を織り込んだ優先順位付けを自動化してくれるため、運用の初動に向いています。

4-2. 優先順位ルールの例

以下は、チームで運用しやすいシンプルなルールの例です。

即日対応

• 重大度：Criticalかつ本番アカウント
• 攻撃パスにインターネット到達性がある

3営業日以内

• 重大度：Highかつ本番アカウント
• 重大度：Criticalかつ開発・検証アカウント

次期対応

• 重大度：Mediumかつ本番アカウント
• 重大度：Highかつ開発・検証アカウント

保留

• 重大度：Low
• 重大度：Mediumかつ開発・検証アカウント

このルールはあくまで出発点です。組織の規模やリスク許容度に合わせてカスタマイズしてください。

たとえば「開発アカウントでも本番データのコピーがある場合は本番扱い」とか、「PCI DSSスコープ内のリソースは一律即日対応」のように、自社のコンプライアンス要件に合わせた例外条件を足していくと実用的になります。

4-3. 例外・保留の扱い

運用を続けていくと、すぐに対応できない露出や、意図的に受容するリスクが出てきます。ここのルールを決めておかないと、「対応済み」と「放置」の区別がつかなくなって混乱します。

• 受容：ビジネス要件上やむを得ないリスク。承認者・期限・根拠を記録し、定期的に再レビューする
• 保留：対応リソースが不足している場合。最大保留期間を設定し、期限到来で自動的にレビュー対象に戻す
• 誤検知：Security Hubのステータスを更新し、Automation Ruleで同様の検出結果を自動抑制する

4-4. 週次運用の型

露出の検出結果を継続的に活用するための、週次運用サイクルの例を紹介します

毎日（5〜10分）

• サマリーダッシュボードで新規Critical / Highをチェック
• P1該当があれば即時対応フローを起動

週次（30〜60分）

1. 露出ダッシュボードで前週からの増減を確認
2. P2以上の未対応一覧をレビュー
3. 保留・受容の期限切れがないかチェック
4. 対応状況をチームに共有
5. 新たに発生した傾向（同種の露出が急増していないか等）を分析

月次（60〜90分）

• 露出件数の推移を振り返り、改善傾向か悪化傾向かを確認
• 優先順位ルールの妥当性を再評価
• Automation Ruleの追加・調整を検討

実際にやってみると、最初は露出の件数が多くて大変に感じるかもしれません。

ただ、Automation Ruleで誤検知や許容済みリスクを自動抑制していくと、本当に見るべき露出だけが残るようになります。

この「ノイズを減らす作業」が最初の運用のキモです。

NTT東日本ではAWSの導入・移行・運用の支援を行っております。詳しくはこちらからお問い合わせください。

5. まとめ

AWS Security Hubの露出の検出結果を活用することで、情報セキュリティ運用は「検出結果を一つずつ追いかける」スタイルから、「リスクの高い露出を起点に効率よく対応する」スタイルへ変わります。

5-1. 露出を入口にして、単発の検出結果の深追いを減らす

露出の検出結果は、複数のシグナルを自動で相関分析した結果です。

個別の検出結果を一つずつ調べるのではなく、露出をトリアージの入口にすることで、本当に対応すべきリスクに素早くたどり着けます。

攻撃パス図を使えば、脆弱性・設定ミス・ネットワーク到達性・権限の連鎖を一目で把握でき、対応の優先度を根拠をもって判断できます。

5-2. 判断軸を決め、チームで同じ基準で動けるようにする

「重大度×環境×インターネット到達性」のようなシンプルな判断軸を定めておけば、担当者が変わっても同じ基準で優先順位を付けられます。

属人化を防ぎ、チーム全体の情報セキュリティ対応力を底上げしましょう。

5-3. 運用ルールと期待値を合わせる

「即日対応はこの条件」「保留は最大30日」のようにルールを明文化し、チーム内で合意しておくことが継続的な運用のカギです。

週次レビューと月次の振り返りで、ルールの実効性を検証し続けることも忘れずに。

このコラムがどなたかのお役に立てれば幸いです。

NTT東日本ではAWSの導入・移行・運用の支援を行っております。詳しくはこちらからお問い合わせください。

• Amazon Web Services（AWS）およびその他のAWS 商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。