developersIO
3ヶ月間の AWS セキュリティ運用により確立した Security Hub の検出結果に対する対応を決定するための切り分けフローのご紹介

3ヶ月間の AWS セキュリティ運用により確立した Security Hub の検出結果に対する対応を決定するための切り分けフローのご紹介

AWS Security Hub
FacebookHatena blogX
2025.04.09

こんにちは、製造ビジネステクノロジー部の若槻です。

最近 AWS Security Hub の運用を担当する機会がありました。

https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/what-is-securityhub.html

その際に、AWS 上でインフラの作成や変更が行われる中で次々と発生する Security Hub のアラートに対して、チーム全体で画一的な対応を行うための「切り分けフロー」を確立する必要がありました。

今回は、3ヶ月の運用経験から確立した Security Hub 検出結果の切り分けフローをご紹介します。このフローを活用することで、チームメンバー全員が一貫性のある判断基準でセキュリティアラートに対応できることを目指します。

この記事で扱わないこと

Security Hub の概念確認

まず始めに、AWS Security Hub の主要な概念の関係性を確認しておきます。

【階層構造】
標準 > セキュリティコントロール > 検出結果（リソースに関連付け）

  1. 標準（Security Standard）
  1. セキュリティコントロール（Security Control）
  • 標準の中の具体的なセキュリティ要件
  • 特定のセキュリティチェック項目を定義
  • 複数の検出結果を生成する可能性がある
  • 特定のタイプのリソースに対するチェックを定義
  1. リソース（Resource）
  • AWS内の具体的なサービスやコンポーネント（EC2、S3、IAMなど）
  • セキュリティコントロールによる評価の対象
  • 1つのリソースに対して複数の検出結果が存在可能
  • 複数のセキュリティコントロールによって評価される可能性がある
  1. 検出結果（Finding）
  • セキュリティコントロールによる具体的なチェック結果
  • 特定のリソースの現在の状態を示す
  • ワークフローステータスが割り当てられる
  • リソースとの1対1の関連付けを持つ
  1. ワークフローステータス（Workflow Status）
  • 検出結果に対する対応状態を示す
  • 以下の状態がある：
    • NEW：新規の検出結果
    • NOTIFIED：通知済み
    • RESOLVED：解決済み
    • SUPPRESSED：抑制（無視）

【関係性の流れ】

  1. 標準が定義され
  2. その中のセキュリティコントロールが実行され
  3. 対象となるリソースがチェックされ
  4. リソースに関連する検出結果が生成され
  5. 検出結果に対してワークフローステータスが割り当てられる

【リソースを中心とした見方】

  • 1つのリソースは複数のセキュリティコントロールによって評価される
  • 各評価により検出結果が生成される
  • リソースの状態変更により、関連する検出結果も更新される
  • リソースの削除/変更履歴も検出結果として記録される

これにより、AWS 環境全体のセキュリティ状態を、リソースを中心として体系的に管理・監視することができます。

切り分けフローの目的確認

このフローは、Security Hub の検出結果を適切に管理し、セキュリティ状態を明確に把握することを目的としています。

スタート

  • Security Hub の検出結果で、ワークフローステータスが「NEW」のもの

ゴール

  • 全ての検出結果が以下のいずれかのワークフローステータスとなっていること：
    • 「RESOLVED」（解決済み）：セキュリティ上の問題が解消された
    • 「SUPPRESSED」（抑制）：正当な理由により対応不要と判断された

切り分けフロー

今回確立させた Security Hub の検出結果に対する対応を決定するための切り分けフローを以下に示します。このフローは、検出結果が発生した際に「誰が」「どのように」対応すべきかを明確にすることを目的としています。

フローの概要

フローは大きく以下の判断基準に基づいています：

  1. コントロールへの対応要否
  2. リソースの作成・管理の所有者
  3. リソースの必要性
  4. 修正の実施可否

これにより、検出結果を以下のいずれかの方法で適切に対応することができます：

  • コントロールの無効化
  • リソースの修正
  • リソースの削除
  • 手動での抑制（SUPPRESSED）

フロー図

mermaid 原文
flowchart TD
    A[コントロールがリソースに<br/>ワークフローステータスNEWを割り当てた] --> B{その検出結果の<br/>コントロールは<br/>対処する必要があるか？}

    B -->|いいえ| C[コントロールを無効化する]
    C --> D[検出結果が自動的に<br/>SUPPRESSEDに遷移]

    B -->|はい| E{対象のリソースは<br/>プロジェクト/チームが<br/>明示的に作成または<br/>設定したものか？}

    E -->|はい| F[リソースを修正]
    F --> G[検出結果がRESOLVEDに遷移]

    E -->|いいえ| H{アカウントやサービスの<br/>機能により自動作成された<br/>リソースか？}

    H -->|はい| I{残す必要がある<br/>リソースか？}
    I -->|はい| J{修正を行なっても<br/>良いリソースか？}
    J -->|はい| K[リソースを修正]
    K --> G
    J -->|いいえ| L[検出結果のワークフロー<br/>ステータスを手動で<br/>SUPPRESSEDに変更]

    I -->|いいえ| M[リソースを削除]
    M --> D

    H -->|いいえ| N{管理アカウントにより<br/>作成された<br/>リソースか？}

    N -->|はい| O{管理アカウントの管理者に<br/>依頼をして修正が可能か？}
    O -->|はい| P[管理アカウントの<br/>管理者がリソースを修正]
    P --> G
    O -->|いいえ| L

フロー（リスト形式）

  1. コントロールがリソースにワークフローステータス NEW を割り当てた
  2. その検出結果のコントロールは対処する必要があるか？
    1. いいえ
      1. コントロールを無効化する
        → ステータスが自動的に SUPPRESSED に遷移
    2. はい
      1. 対象のリソースはプロジェクト/チームが明示的に作成または設定したものか？
        1. はい
          1. リソースを修正
            →ステータスが自動的に RESOLVED に遷移
        2. いいえ
          1. アカウントやサービスの機能により自動作成されたリソースか？
            1. はい
              1. 残す必要があるリソースか？
                1. はい
                  1. 修正を行なっても良いリソースか？
                    1. はい
                      1. リソースを修正
                        → ステータスが自動的に RESOLVED に遷移
                    2. いいえ
                      → ステータスを手動で SUPPRESSED に変更
                2. いいえ
                  1. リソースを削除
                    → ステータスが自動的に SUPPRESSED に遷移
            2. いいえ、 管理アカウントにより作成されたリソースである
              1. 管理アカウントの管理者に依頼をして修正が可能か？
                1. はい
                  1. 管理アカウントの管理者がリソースを修正
                    → ステータスが自動的に RESOLVED に遷移
                2. いいえ
                  → ステータスを手動で SUPPRESSED に変更

フロー分岐での切り分け例

◾️その検出結果のコントロールは対処する必要があるか？ → いいえ

セキュリティコントロール [EC2.58] VPCs は、Systems Manager Incident Manager Contacts のインターフェイスエンドポイントで設定する必要があります が検出結果を作成したが、本システムでは Systems Manager Incident Manager Contacts を使っていないため、EC2.58 コントロール自体を無効化する判断とした。

◾️対象のリソースはプロジェクト/チームが明示的に作成または設定したものか？ → いいえ → アカウントやサービスの機能により自動作成されたリソースか？ → はい　→ 残す必要があるリソースか？ → はい → 修正を行なっても良いリソースか？ → はい

セキュリティコントロール [S3.5] S3 汎用バケットではリクエストに SSL を使用する必要があります。 が検出結果を作成した S3 バケットは AWS CDK により自動作成されたものであった。CDK を利用する上で必要なリソースであるため、残す必要があると判断した。また、バケットの設定を変更することで修正が可能であったため、リソースを修正することとした。

◾️対象のリソースはプロジェクト/チームが明示的に作成または設定したものか？ → いいえ → アカウントやサービスの機能により自動作成されたリソースか？ → はい → 残す必要があるリソースか？ → いいえ

セキュリティコントロール [EC2.2] VPC のデフォルトのセキュリティグループでは、インバウンドトラフィックまたはアウトバウンドトラフィックを許可しないようにすることをお勧めします が検出結果を作成したセキュリティグループはアカウントが自動で作成したデフォルト VPC のものであった。その VPC が現在使われていないことを確認し、また今後も使用しない方針としたため、不要なリソースであると判断した。

◾️対象のリソースはプロジェクト/チームが明示的に作成または設定したものか？ → いいえ → アカウントやサービスの機能により自動作成されたリソースか？ → いいえ、 管理アカウントにより作成されたリソースである → 管理アカウントの管理者に依頼をして修正が可能か？ → いいえ

セキュリティコントロール [S3.9] S3 汎用バケットは、サーバーアクセスログ記録を有効にする必要があります が検出した S3 バケットは、AWS Organizations の管理アカウントにより監査ログ集積用に自動作成されたものであった。管理アカウントの管理者に修正を依頼したが、修正ができないとの回答を受けたため、手動で検出結果のワークフローステータスを SUPPRESSED に変更した。

おわりに

3ヶ月間の AWS セキュリティ運用により確立したSecurity Hub の検出結果に対する対応を決定するための切り分けフローのご紹介でした。

この記事が、皆さんの AWS Security Hub の効率的で一貫性のある運用に役立てれば幸いです。

以上

この記事をシェアする

FacebookHatena blogX

関連記事

AWS Security Hub CSPM のLastObservedAtとUpdatedAt、ProcessedAtの違いをまとめてみた
平井裕二
2025.10.31
Secure Account: การตั้งค่าการแจ้งเตือนความปลอดภัย (Security Alert) ทางอีเมล์
kan-jittapramoulboon
2025.10.21
การดำเนินการด้านความปลอดภัยบน AWS: วิธีการใช้งาน Secure Account
kan-jittapramoulboon
2025.10.21
CloudFrontの標準ログ記録において「S3 Legacy」を設定していない場合の、AWS Security Hub CSPM[CloudFront.5]の挙動を確認してみた
吉田 岳史
2025.10.13