AWS Security Hubスコアとは？評価ロジック・計算方法・Suppress：抑制の正しい使い方とは

2025年6月26日

こんにちは！クララ株式会社のAWS Secure開発プロジェクトチームです。

Security Hubを導入したものの、「スコアの意味がわからない」「どう改善すればいいの？」と悩まれている方、意外と多いんです。

この記事では、Security Hubスコアの評価ロジックから、Suppress（抑制）の正しい使い方まで、現場でつまずきやすいポイントをわかりやすく解説していきます。

Security Hubのスコアとは？──“パス率”を示すシンプルな仕組み

Security Hubのスコアは、「有効化されたセキュリティルールにどれだけ準拠できているか」の割合で評価されます。

✅ 評価式の基本構造：

スコア ＝ Pass数 ÷ 評価対象数 × 100

  • Pass数：チェックを通過したリソース×コントロールの組み合わせ
  • 評価対象数：有効なコントロール × チェック対象のリソース数

    評価は、リソース × コントロールの組み合わせごとに行われます。
     つまり、チェック対象が増えれば分母が増え、スコアは相対的に下がりやすくなる仕組みです。

    ただし、だからといってコントロールを削ればいいという話ではありません。
     有効なコントロールは、AWSが提示するベストプラクティスに沿った内容です。
     削除ではなく、対応するか、正当な理由のあるSuppressで調整しましょう。

     

    Severity（重大度）の影響──スコアには関係ないが、リスクとは別物

    Security HubのスコアはFailのSeverityに関係なく1件のFailとしてカウントされます。

    Severity スコアへの影響
    Low 1件のFail
    Critical 同じく1件のFail

    つまり、スコアの数値だけを追いかけると、本当に危ないものを見落とす可能性があります。

    🔍 例：Lowを50個直してスコアを上げても、Criticalが1件残っていればリスクは非常に高いまま。

    スコアを「運用改善の参考」として活用することは有用ですが、スコアだけでセキュリティ状況を評価するのは危険です。

    Suppress（抑制）とは？──Fail扱いにしないのではなく、評価から除外するもの

    Security Hubには、スコアの計算対象から一部のアラートを除外する「Suppress（抑制）」機能があります。
     目的は、本質的に不要なチェックを正当な理由で外すこと。都合よく“見なかったことにする”のとは違います。

    Suppressには、次の2つの使い方があります：

    ✅ コントロール全体のSuppress

    セキュリティ基準内の特定コントロールを、全リソースで無効化します。
     例： 組織ポリシーで、一部のチェックをすべてのアカウントで除外する場合など。

    ✅ アラート（結果）単位のSuppress

    特定リソース × 特定コントロールの組み合わせだけをピンポイントで除外します。
     例： 開発環境の一部で、暗号化が不要なEBSボリュームを除外する、など。

    Suppressはあくまで「Failにしない」のではなく、「そもそも評価対象から外す」という立ち位置です。
     使い方を誤ると“隠れ蓑”になりますが、正しく運用すれば、スコアと実態のギャップを埋める手段になります。

    Suppressがスコアに与える影響は？

    Suppressを使うと、スコアの分母に含まれるかどうかが変わります。
     使い方によって影響の出方が異なるため、以下のように整理しておきましょう。

    Suppressの対象 スコアへの影響
    コントロール全体をSuppress そのコントロールはすべて評価対象から除外されます（＝分母から除外）
    リソース単位でSuppress 特定リソースのみ評価から外れるが、コントロール全体は評価対象のまま（＝分母には含まれる）

    要するに、「全体をSuppress」すればスコアが上がる可能性があるけれど、「個別Suppress」では上がらない、という点に注意が必要です。

    Suppressを使うときの注意点──“都合のよい隠れ蓑”にしない

    Suppressは非常に便利な機能ですが、使い方を間違えると“セキュアなつもり”になってしまう危険性があります。

    • Suppressの乱用 → スコアは高く見えても、実際はリスクだらけなことも。
    • 理由や記録が残っていない → 属人化してしまい、後から確認できずにブラックボックス化する可能性も。

      Suppress運用のガイドライン

      Suppressを使うときは、以下の観点をチームで共有・判断しておくことが大切です。

      • 本当にそのチェックが不要か？
         　例：組織ポリシーに照らして妥当か
      • 一時的なSuppressで終わっていないか？
         　例：例外に有効期限があるか
      • Suppressの経緯や理由を記録しているか？
         　例：運用ルールに従い記録・通知されているか

      おまけ：Security HubスコアにGuardDuty・Inspectorの結果は影響するか？

      結論から言うと、反映されません。

      Security Hubのスコアは、Security Hub Controls（セキュリティベンチマーク）の結果だけで計算されます。

      項目 スコアに影響する？ 補足
      Security Hub Controls ✅ はい ベースライン（例：AWS Foundational Security Best Practices）内のルールに基づく
      GuardDuty Findings ❌ いいえ FindingsはSecurity Hubに表示されるが、スコアの評価には使われない
      Inspector Findings ❌ いいえ 同上。Inspector findingsはSecurity Hubに集約されるが、スコア評価対象外

      なぜ影響しないのか？

      Security Hubスコアは、「静的な構成ルールに準拠しているか」を測るものです。
       たとえば「S3がパブリックじゃないか？」「ルートユーザーが無効になっているか？」などの設定チェックが対象です。

      一方、GuardDutyやInspectorは、脅威や脆弱性の“検出結果”をレポートする仕組みです。
       構成そのもののチェックとは目的が異なるため、スコアに含まれないというわけです。

      スコアに振り回されないセキュリティ運用へ

      Security Hubのスコアは、あくまで“改善のきっかけ”として使うのが正解です。
       数値に一喜一憂するのではなく、本質的なリスク管理につなげていくことが大切です。

      • Suppressも含めた設計で、見せかけでなく“実質的に安全”な状態を目指す
      • Severityの高いアラートはスコアに関係なく最優先で対応する
      • 構成改善がスコア向上に直結するよう、運用を整える

      「形式的なスコア」ではなく、「動けるセキュリティ体制」へ。
       その変革を支援するのが、私たちのAWS Secureです。

      AWS Secureとは？

      AWS Secureは、クララが提供するフルマネージド型のセキュリティ運用支援サービスです。
       Security HubやGuardDutyなど、AWSネイティブのセキュリティ機能を活かしながら、
       通知・判断・改善まで一貫した運用サイクルを支援します。

      AWS Secureが支援する“回るセキュリティ運用”

      • レベル別に通知内容を整理・最適化
      • アラートの傾向をまとめた月次レポート
      • 対応状況の可視化と運用の定着化
      • Slackやメールなど通知先の連携支援
      • 振り返りを通じた継続的な改善支援

        Security Hubを“見るだけのツール”から、“動ける仕組み”に変える──それがAWS Secureの価値です。

        ▶ 詳しくはこちら
         👉 AWS Secureのサービスページを見る

        次に読む：Security Hubスコアを改善する“運用体制”とは？

        スコアの仕組みを理解したら、次は「どう改善していくか」がテーマです。
         属人化せず、継続できるセキュリティ運用体制のつくり方は、以下の記事で詳しくご紹介しています。

        👉 [Security Hubスコアを改善するための“運用体制”──属人化しないための設計と仕組みづくり]

        おすすめ