クラウドがよく分かる！お役立ちコラム

Security Hubの検出結果を直すべき？運用のコツを解説

この記事は約11分で読めます。

AWSのSecurity Hubとは

現在、AWSでは「AWS Security Hub」と「AWS Security Hub CSPM」が区別されています。

AWSのSecurity Hubの概要

Security Hub CSPMは、AWS環境をセキュリティ標準やベストプラクティスに照らして継続的にチェックし、Security scoreやコントロール検出結果を提供するサービスです。

一方、AWS Security Hubは以下のセキュリティシグナルを集約・相関分析します。

• Security Hub CSPM
• Amazon Inspector（脆弱性診断）
• Amazon GuardDuty（脅威検知）
• Amazon Macie（機密データ検知）

優先的に対応すべきリスクを示してくれることが特徴です。

本記事では、主にSecurity Hub CSPMが生成する検出結果と、そのWorkflow statusを使った運用を解説します。

検出結果集約のハブという役割

Security Hub CSPMは複数サービスでの検出結果を「Findings」という共通フォーマットに変換して集約します。そのため、1つの画面でセキュリティ状態全体を俯瞰できることが特徴です。まずはこの「集約ハブ」としての位置づけを押さえておきましょう。

料金の考え方

料金体系は、Security Hub CSPMを単体で利用する場合と、新しいAWS Security Hubを有効化する場合とで異なります。Security Hub CSPM単体では従量課金で、検出結果の取り込みイベントは月10,000件まで無料です。一方、新しいAWS Security Hubを有効化すると、Essentialsプランによるリソース単位課金が適用されます。

Security Hubの検出結果（findings）の見方

対応優先度を考える前に、Security Hubの検出結果を理解しておく必要があります。ここを押さえていないと、優先度付けができません。

Severity（重大度）とSecurity score

検出結果には以下5段階のSeverity（重大度）が付与されます。

• Critical
• High
• Medium
• Low
• Informational

Security Hub CSPMはこれらのチェック結果をもとに「Security score」というスコアを自動算出するのです。これを用いて、アカウント全体のセキュリティ状態を数値で把握できるようにしています。

ただ「スコアがすべて」というわけではありません。検出を抑止することで、点数が変動することがあります。スコアを改善することが目的にならないよう注意すべきです。

準拠基準（Standards）とControl

Security Hub CSPMは、複数のセキュリティ標準（Standards）に対応しています。

• AWS Foundational Security Best Practices（FSBP）
• CIS
• PCI DSS
• NIST

それぞれの標準は多数のControl（統制項目）で構成されています。また、個々の検出結果には、以下のとおりステータスが付与されます。

• PASSED（合格）
• FAILED（不合格）
• WARNING（判定不可）
• NOT_AVAILABLE（評価不可）

これらを集約したControl（統制項目）全体のステータスはControl statusです。こちらはPassed・Failed・Unknown・No data・Disabledの5種類で表されます。

Security Hub CSPMにおける対応状況の管理

検出結果には調査・対応の進捗を示す対応状況の管理（Workflow status）という項目があります。初期状態はNEWで、対応をリソース所有者に依頼した場合はNOTIFIED、対応不要と判断した場合はSUPPRESSED、修復が完了した場合はRESOLVEDに変更する運用です。この状態管理が、大量の検出結果を運用に乗せるための土台といえます。

なお、Workflow statusはSecurity Hub CSPMの仕様です。新しいAWS Security Hub側の検出結果には別のステータス体系が使われます。

検出結果は全部すぐ直すべき？

Severityが分かれば「Critical・Highから直せばいい」と考えたくなるでしょう。しかし、それだけでは現実的な運用は回りません。

「全部すぐ直す」が非現実的な理由

Security Hubを有効化すると、検出結果が数百件から数千件に達することがあります。対応できる人員やリソースは有限であり、すべてを同時に処理することは現実的ではありません。

加えて、Severityは各コントロール共通のリスク評価です。そのため、自社のシステム構成ではリスクが低い項目も高く表示されることがあります。Severityだけを基準に機械的に対応順を決めると、重要な対応が後回しになりかねません。

対応優先度を決める5つの軸

Severity（重大度）に加えて、次の観点を掛け合わせて優先度を判断することをおすすめします。

• 重大度：Security Hub上のCritical／High／Medium／Lowの評価
• インターネット露出：そのリソースが外部からアクセス可能な状態にあるか
• データへの到達性：検出結果の対象リソースから機密情報や個人情報に到達できるか
• 悪用可能性：既知の攻撃手法や公開エクスプロイトが存在するか、悪用の難易度は低いか
• ビジネス影響：対象リソースが停止・侵害された場合に業務やサービスへ与える影響の大きさ

たとえば同じHighの検出結果でも以下はリスクが大きくことなります。

• インターネットに公開されたリソースで機密データに到達可能なもの
• 閉域網内の検証環境にあるもの

この差を意識して優先順位を組み直すことが、限られたリソースを有効に使う鍵です。

AWS自身もリスクベースの優先順位付けへ舵を切っている

AWSも同様の方向でサービスを進化させています。新しいAWS Security Hubでは、検出結果を相関分析し、リスクの組み合わせを評価する「Exposure findings（露出の検出結果）」が導入されました。

対応するリソースについて、ネットワーク到達性や構成、IAMの実効権限、脆弱性などを相関分析してリスクを算出します。ただし、すべてのAWSリソースがExposure findingsの対象になるわけではありません。分析に必要な情報が十分にそろっていないと生成できないのです。

新機能を完璧に理解する必要はありません。ただ「重大度だけで機械的に判断しない」という考え方をAWSが推奨している点は抑えましょう。

検出結果への対応運用に乗せる：トリアージの回し方

優先度の考え方が決まったら、それを日々の運用として回す仕組みが必要です。ここからは、検出結果を継続的にさばいていくための具体的な運用フローを解説します

Workflow statusを使い分けてトリアージする

検出結果を確認したら、対応要否を判断してWorkflow statusを更新していきます。対応が必要なものはNOTIFIEDにしてリソース所有者へ引き継ぎましょう。修復後はRESOLVEDとして管理します。

なお、コントロールの検出結果はCompliance statusがPASSEDになると、Workflow statusが自動的にRESOLVEDに変わります。また、ステータスを変更しても、セキュリティチェックや検出結果の取り込み自体が止まるわけではありません。既存の検出結果が再評価・更新されるほか、検出元や状況によっては新しい検出結果が届くことがあります。

抑制ルール（Suppression）は無視しない

自社環境でリスクが低いと判断できる検出結果は、Workflow statusをSUPPRESSEDに設定します。これは「確認したうえで対応不要と判断した」という記録を残す操作です。個別に手動で設定する以外に、条件を指定して自動的にSeverityやWorkflow statusを更新するルールも用意されています。

ただ、先述のとおりSUPPRESSEDに変更すると、Security scoreに影響することがあります。単なる恒久的な除外にしないための運用ルールとあわせて整備することが重要です。

通知連携で見逃しを防ぐ

Amazon EventBridgeで検出結果のイベントをキャッチし、通知先へ連携する流れがおすすめです。これにより、担当者がSecurity Hubのコンソールを毎回開かずとも異常に気づけます。新しい検出結果や重大度の高い検出結果を自動で通知し、対応の遅れによるリスクを軽減しましょう。

また、検知して対応した後はステータスを変更する作業が必須です。これを忘れてしまうと、状況を適切に把握できなくなってしまいます。

対応優先度別のレビュー目安を決めておく

すべての検出結果に同じ頻度で目を通す必要はありません。Severityに露出・データ到達性・悪用可能性・ビジネス影響を掛け合わせて決めた最終的な優先度を決めて対応しましょう。たとえば以下のとおりランクを用意します。

• 即時確認
• 当日中
• 週内
• 月内

あらかじめ基準を決めておくと、判断のばらつきを防げます。

トリアージ工数の目安（試算）

実際にどの程度の工数がかかるのか気になるでしょう。ひとつのモデルケースとして試算してみます。次のような仮の前提を置いて積み上げると、内訳は次のとおりです。

• Critical・Highのトリアージ：月20件×1件15分＝約5時間
• Medium・Lowの定期レビュー：週1回30分×4週＝約2時間
• 抑制ルールの見直し・メンテナンス：月1回1時間程度
• 準拠基準・Controlのアップデートへの追従：月2時間程度

これらを合計すると、月あたりおよそ10時間の工数になる計算です。もちろん検出結果の件数や1件あたりの調査の複雑さは環境やシステム構成によって大きく異なります。まずは自社環境で一定期間運用し、実際にかかった工数を記録してみましょう。それを踏まえ、体制の見直しやアウトソースの要否を検討することをおすすめします。

Security Hubを運用する際の注意点

Security Hubの検出結果は、一度対応して終わりというものではありません。AWS環境に新しいリソースが追加されたり、設定が変更されたりするたびに新しい検出結果が生まれ続けます。さらに、準拠基準やControlの内容は継続的に更新されるため、新しい基準への対応も必要です。

「有効化してひとまず落ち着いた」状態で満足してはなりません。「検出結果が出続けることを前提とした体制」へ移行できるかどうかが重要です。適切な体制を整えなければ、結局は運用できないまま終わってしまいます。