こんにちは！クララ株式会社の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の価値です。
▶ 詳しくはこちら
次に読む：Security Hubスコアを改善する“運用体制”とは？
スコアの仕組みを理解したら、次は「どう改善していくか」がテーマです。
属人化せず、継続できるセキュリティ運用体制のつくり方は、以下の記事で詳しくご紹介しています。
👉 [Security Hubスコアを改善するための“運用体制”──属人化しないための設計と仕組みづくり]
