TL;DR
Security Hub Findingは 1 種類ではなく、Security Hub CSPM、GuardDuty、Inspectorなど複数の由来があります。Security Hub CSPM由来の Finding は、コントロールベースで生成され、IAM.1やS3.8のようなControl IDを起点に追いやすいです。- まずは「この Finding はどこから来たのか」を切り分けてから、優先順位を付ける方が整理しやすいです。
はじめに
Security Hub を見始めたときに、最初に少し混乱したのが
- これは
Security Hubの指摘なのか - それとも
Security Hub CSPMの指摘なのか GuardDutyやInspectorのものも混ざっているのか
という点でした。
実務でも、Finding が 1 画面にまとまって見えると便利な反面、どこ由来の情報なのかを意識しないと、是正の進め方を誤りやすい と感じます。
この記事では、
Security Hub FindingとSecurity Hub CSPMの関係- どれが
Security Hub CSPM由来なのか - どんな順番で見ればよいか
を整理します。
まず整理: Security Hub と Security Hub CSPM は別物
2026年8月11日時点の AWS 公式ドキュメントでは、Security Hub と Security Hub CSPM は補完関係にある別サービスとして説明されています。
docs.aws.amazon.comざっくり言うと、
Security Hub CSPM- クラウド設定不備を継続評価する
- コントロールに対するセキュリティチェックを走らせる
- Findings を生成する
Security Hub- 複数のセキュリティサービスからの Findings を集約する
- 相関付け、優先順位付け、対応ワークフローに載せる
という役割分担です。
AWS 公式でも、Security Hub CSPM findings are routed to Security Hub automatically と説明されています。
つまり、Security Hub CSPM が作った Finding は Security Hub に自動連携されます。
docs.aws.amazon.comSecurity Hub Finding はどこから来るのか
Security Hub 上で見える Finding は、必ずしも全部 Security Hub CSPM 由来ではありません。
たとえば代表的には以下があります。
Security Hub CSPM- 設定不備、ベストプラクティス違反
GuardDuty- 脅威検知、不審な挙動
Inspector- 脆弱性検知
Macie- 機微データ関連の指摘
この違いを意識せずに全部同じ粒度で見ると、
- 設定不備の是正で直せるもの
- 監視や調査が必要なもの
- 脆弱性対応が必要なもの
が混ざって見えてしまいます。
Security Hub CSPM 由来の Finding はどう見分けるか
ここは自分も最初に整理したかったポイントです。
Security Hub CSPM では、コントロールを有効化するとセキュリティチェックが走り、その結果として Security Hub CSPM findings が生成されます。
docs.aws.amazon.com見分けやすいポイントは以下です。
1. Control ID がある
IAM.1、S3.8、EC2.13 のように、サービス名 + 番号の Control ID を起点に見られるものは Security Hub CSPM 由来と捉えやすいです。
docs.aws.amazon.com2. Compliance.Status が前面に出る
Security Hub CSPM 由来の Finding は、コントロール評価結果として PASSED / FAILED / WARNING などの Compliance.Status を持ちます。
docs.aws.amazon.com3. コントロール詳細ページに辿れる
コンソール上でコントロール詳細や関連標準、Remediation に辿りやすいものは Security Hub CSPM の文脈で読むと分かりやすいです。
docs.aws.amazon.comSecurity Hub CSPM 由来の Finding はどう作られるのか
ここが分かると、かなり腹落ちしやすいです。
AWS 公式では、Security Hub CSPM はコントロールごとにセキュリティチェックを実行し、その結果として Finding を生成・更新すると説明されています。
docs.aws.amazon.comつまり、
- コントロールを有効化する
- チェックが走る
- リソースごとに Finding が生成される
- 次回チェック時は新規作成ではなく更新される
という流れです。
このため、Security Hub CSPM 由来の Finding は
- どのコントロールに対するものか
- どのリソースに対するものか
- 今の
Compliance.Statusは何か
で追うのが基本になります。
では、どんな順で見ると分かりやすいか
私なら次の順で見ます。
1. まず由来を意識する
これは CSPM 由来なのか、それとも GuardDuty など別系統なのかをまず意識します。
2. CSPM 由来なら Control ID を見る
ここで IAM.1 や S3.8 のような識別子が見えると、かなり追いやすくなります。
3. コントロールの公式ページを読む
そこで、
- 何をチェックしているか
- 対象リソースは何か
- なぜ失敗なのか
- どう直すべきか
を確認します。
4. 対象リソースを横に見る
指摘 1 件だけで終わらせず、同種リソースが横展開で同じ問題を持っていないか確認します。
優先順位はどう付けるか
Security Hub CSPM 由来の Finding を見るとき、私は以下の観点で優先度を考えます。
1. Severity
まずは High や Critical から見るのが自然です。
2. 横展開のしやすさ
1件だけ直すより、同じ設定不備を複数リソースでまとめて改善できるものを先にやると進めやすいです。
3. 影響範囲
IAM, S3, KMS, CloudTrail のように、基盤全体へ効きやすいものは優先度が上がりやすいです。
4. 顧客と合意しやすいか
技術的に正しくても、業務要件や運用都合で即是正できないものもあります。
そのため、
- すぐ是正できる
- 合意形成が必要
- 対象外や代替統制候補
を分けて見る方が現実的です。
自分が最初に混乱した理由
今振り返ると、自分が少し混乱した理由は、Security Hub という大きい器の中に複数の Finding が載っていたからだと思います。
つまり、
- 画面上は全部
Security Hub Findingに見える - でも発生源は同じではない
- 是正の仕方も同じではない
という構造です。
ここが分かると、かなり整理しやすくなります。
まとめ
Security Hub Finding は 1 種類ではなく、Security Hub CSPM、GuardDuty、Inspector など複数の発生源があります。
その中で Security Hub CSPM 由来の Finding は、
- コントロールベース
Control IDで追いやすいCompliance.Statusで評価状態が見える
という特徴があります。
そのため、Finding を見るときはまず
- どこ由来か
CSPM由来ならどのControl IDか- 公式リファレンス上で何を求めているか
の順で見るとかなり整理しやすいです。
次に Security Hub CSPM の Finding を扱うときは、単に件数を見るのではなく、どのコントロールがどのリソースに対して失敗しているのか を軸に見ていきたいと思います。
続編では、この切り分けをコンソールと AWS CLI の両方でどう確認するかを整理します。