TL;DR
Security Hub CSPMは、AWS 環境の設定不備を継続的にチェックして Findings として出してくれるCSPMサービスです。- 是正を進めるときは、まず
Control IDを起点に AWS 公式リファレンスを確認し、対象リソース、Severity、関連AWS Configルール、Remediation を読む流れが安定します。 Security Hubはより広い統合セキュリティ基盤で、Security Hub CSPMはその中でも「クラウド設定不備の検知」に寄った位置づけと理解すると整理しやすいです。
はじめに
既存 AWS 環境のセキュリティ是正を進める中で、かなり重要な入口になったのが Security Hub CSPM でした。
実際の作業では、
- まず
Security Hub CSPMの Findings を見る - そのまま感覚で直すのではなく、公式リファレンスを確認する
- 対象リソースと是正方針を整理してから対応する
という流れを取ることが多かったです。
この記事では、
Security HubとSecurity Hub CSPMの違いSecurity Hub CSPMを使った是正の進め方- 公式リファレンスをどう読むか
を、実務寄りに整理します。
まず整理: Security Hub と Security Hub CSPM は何が違うか
最初に少し混乱しやすいのがここです。
2026年8月11日時点の AWS 公式情報では、AWS Security Hub はより広い統合セキュリティ基盤として説明されており、Essentials plan にリスク分析、脆弱性管理、セキュリティ体制管理、セキュリティ対応管理が含まれます。
一方で AWS Security Hub CSPM は、クラウド設定不備を継続的に評価する Cloud Security Posture Management の機能として整理されています。
aws.amazon.com
docs.aws.amazon.com自分なりには、以下の理解がしっくりきました。
Security Hub- セキュリティシグナル全体を集約し、優先順位付けや対応管理まで含めて扱う広い土台
Security Hub CSPM- その中でも、AWS リソース設定をベストプラクティスや標準に照らして評価する機能
つまり、是正対応でよく見る
IAM.1S3.8EC2.13
のようなコントロールベースの指摘は、基本的に Security Hub CSPM を起点に捉えると分かりやすいです。
Security Hub CSPM の基本
AWS 公式ドキュメントでは、Security Hub CSPM は AWS およびマルチクラウドのリソースに対して、セキュリティベストプラクティスに基づく継続的なチェックを行うと説明されています。
docs.aws.amazon.com特に実務上重要なのは以下です。
- 複数アカウント、複数リージョンの状態をまとめて見やすい
- 各コントロールに
Control IDがある - Control ごとに公式リファレンスがある
- Findings ごとに対象リソース、Severity、Remediation を追える
また、多くのコントロールは AWS Config の記録と評価を前提にしています。
公式ドキュメントでも、ほとんどのコントロールの Findings 生成には AWS Config のリソース記録が必要とされています。
docs.aws.amazon.com公式リファレンスを起点に進める理由
現場で Findings を見ていると、
- タイトルだけでは意図が分からない
- どのリソースタイプが対象か曖昧
- どこまでが本当に是正対象か判断しづらい
ということがよくあります。
このとき、公式リファレンスを見に行くと少なくとも以下が分かります。
- 対象リソースタイプ
- Severity
- 関連する
AWS Configルール - スケジュールタイプ
- Remediation の考え方
- 注意事項
たとえば IAM.1 の公式ページでは、
- タイトル
AWS::IAM::Policyが対象- Severity が
High - 関連
AWS Configルール - なぜ危険か
- どう直すべきか
がまとまっています。
docs.aws.amazon.com私がやっている進め方
1. まず Findings を Control ID 単位で見る
最初から 1 件ずつ追うとかなり重いです。
そのため、まずは
- どの
Control IDが多いか - どのサービスに偏っているか
- Severity はどうか
を見ます。
Control ID は安定して使える識別子なので、フィルタや自動化の起点にも向いています。
公式リファレンスでも、タイトルや説明文より Control ID ベースで扱うことが推奨されています。
docs.aws.amazon.com2. 公式のコントロールページを読む
次に、対象 Control ID の公式ページを開きます。
ここで最低限見るのは以下です。
- 何をチェックしているか
- 対象リソースタイプ
- Severity
- 関連
AWS Configルール - Remediation
- 注意事項
これで「何をもって失敗としているか」がかなり明確になります。
3. 対象リソースを洗い出す
その後に CLI やコンソールで対象リソースを一覧化します。
ここで大事なのは、「Security Hub の Findings に出たものだけ」ではなく、
同種のリソース全体を横並びで確認すること です。
たとえば S3 の公開設定なら、指摘された 1 バケットだけではなく、同系統のバケットを一覧で確認した方が抜け漏れが減ります。
4. 是正 / 対象外 / 保留を分ける
ここはかなり実務寄りですが重要です。
Security Hub の指摘は有用ですが、全部を機械的に直せばよいとは限りません。
そのため、
- 是正する
- 代替統制ありで対象外
- 業務要件上すぐ変えられないため保留
を切り分けます。
5. 変更後に再評価する
修正したら終わりではなく、
AWS ConfigSecurity Hub CSPM- 関連サービスの状態
が再評価され、Findings が解消されることを確認します。
どの公式ページを見るか
私はだいたい次の順で見ます。
1. コントロールリファレンス
まず全体像の入口です。
どんなコントロールがあるかを一覧で確認できます。
docs.aws.amazon.com2. サービス別コントロールページ
たとえば、
- IAM
- S3
- EC2
- Config
のようにサービス別でまとまっているページを見ると、対象サービスの注意点が把握しやすいです。
docs.aws.amazon.com3. 個別コントロールの詳細
ここで Remediation と注意事項まで確認します。
4. 元サービスの公式ドキュメント
最終的な変更手順は、IAM や S3、KMS など元サービス側の公式ドキュメントに戻って確認することが多いです。
Security Hub CSPM を使うときの注意点
AWS Config 前提で考える
多くのコントロールは AWS Config を前提にしています。
そのため、Config の記録が不十分だと、Security Hub 側の評価も見えづらくなります。
docs.aws.amazon.com組織運用なら central configuration を先に意識する
複数アカウントで運用するなら、各アカウントでバラバラに設定するより central configuration を検討した方が管理しやすいです。
公式でも、AWS Organizations と連携した集中管理が案内されています。
docs.aws.amazon.comFindings の件数より、優先度と密度を見る
件数が多いと圧倒されますが、実際には
- High / Critical
- 影響範囲の広いサービス
- 横展開しやすいパターン
から着手した方が進みやすいです。
ざっくりした是正の型
私がよく使う型はこんな感じです。
Control IDで対象をまとめる- 公式ページで意図を確認する
- CLI で対象リソースを洗う
- 顧客と是正有無をすり合わせる
- 手順書を作る
- 是正を実施する
- Findings の解消を確認する
この流れにすると、単発の修正ではなく「再利用できる是正フロー」になりやすいです。
まとめ
Security Hub CSPM は、既存 AWS 環境のセキュリティ是正を進める上でかなり強い入口になります。
ただし、重要なのは Findings を眺めることではなく、
Control IDを起点に- 公式リファレンスを読んで
- 対象リソースを整理し
- 是正 / 対象外 / 保留を分ける
という流れで進めることだと感じています。
また、Security Hub と Security Hub CSPM は完全に同義ではなく、後者は特にクラウド設定不備の検知と体制管理に寄った位置づけです。
今後は、
- どの
Control IDが現場で出やすいか IAMやS3、KMS周りの是正例- CLI でどう洗い出すか
といったテーマも個別にまとめていきたいと思います。