対象読者: AWS のインフラ構築経験はあるが、Security Hub はまだ使ったことがない方。
筆者自身も学びながら書いているので、「最初にこれを知っていれば迷わなかった」という順番で整理します。

この記事でわかること

AWS のセキュリティサービス群(GuardDuty / Inspector / Macie / Config / CloudTrail …)の役割分担と関係
Security Hub が実際にやっている「2つの仕事」— そして自身は何も検知しないこと
CSPM の採点が AWS Config で動いていること — 知らないと「有効化したのに採点ゼロ」になる落とし穴
紛らわしい新旧の名前(Security Hub CSPM と新 Security Hub)の整理

シリーズ: ① 概念編(本記事) → ② CDK 構築編 → ③ トラブル編

1. 導入 — なぜ Security Hub 周りは迷子になりやすいのか

「セキュリティ対策として Security Hub を入れよう」と調べ始めると、すぐに2つの壁に当たります。

壁① 登場人物が多すぎる。 GuardDuty、Inspector、Macie、Config、CloudTrail、Access Analyzer……
似た文脈で似た名前のサービスが次々に出てきて、どれが何をしていて、Security Hub とどう関係するのかが分からなくなります。「全部セキュリティのサービスなんでしょ?」で思考が止まりがちです。

壁② Security Hub は「有効化すれば動く」サービスではない。 正確には、有効化しただけではその真価をほとんど発揮しません。周辺サービス — 特に AWS Config — と組み合わさって初めて機能します。この依存関係を知らないまま有効化だけして、「採点が一度も走っていない Security Hub」が放置されるケースは実際に起こり得ます(仕組みは第5章で詳しく)。

この記事では、壁①に対して全体地図(4層モデル)を、壁②に対して Security Hub の正体と
Config への依存関係を、図で描いていきます。

2. 先に用語だけ押さえる — 9語ミニ用語集

本文を読みながら「この単語なんだっけ?」となったら、ここに戻ってきてください。
それぞれ公式ドキュメントへのリンクも付けたので、深掘りしたくなったらそちらへ。

用語	意味(かんたんな例つき)	公式
finding	検知・検査の結果1件。例:「S3 バケット X が公開設定になっている」という指摘1件	docs
ASFF	findings の共通 JSON 形式(AWS Security Finding Format)。例: GuardDuty 発でも Inspector 発でも「重要度」「対象リソース」が同じ項目名で読める	docs
標準(Standard)	検査項目集。コントロールの束。例: FSBP =「AWS がまとめたベストプラクティス検査項目集」。他に CIS、NIST、PCI DSS	docs
コントロール(Control)	検査項目1つ。例: `S3.5`「S3 への通信は SSL を強制すべき」。FSBP はこれが 300個以上集まったもの(2026年時点)	docs
CSPM	Cloud Security Posture Management。「設定がベストプラクティス通りか」を継続的に採点する考え方。例: AWS アカウントの健康診断を毎日自動でやるイメージ	docs
サービスリンク Config ルール	標準を有効化すると Security Hub が自動で作る AWS Config のルール(`securityhub-*`)。例: コントロール S3.5 の「検査の実体」はこのルール	docs
Configuration recorder	AWS Config の記録装置(リージョンに1つ)。例: アカウント内リソースの設定変化を録画し続けるビデオカメラ。これが止まっていると Config ルールは評価できない	docs
クロスリージョン集約(finding aggregator)	他リージョンの findings を集約リージョンへ自動で寄せる仕組み。例: us-east-1 の findings も東京の画面で見られるようになる(第2回の主役)	docs
OCSF	業界標準の findings スキーマ(Open Cybersecurity Schema Framework)。新 Security Hub(第6章)が採用。例: AWS 以外のセキュリティ製品とも同じ形式でデータ交換できる	docs

読み方のコツ: 今は全部覚えなくて大丈夫です。「finding = 指摘1件」「標準 ⊃ コントロール」「recorder = 録画カメラ」の3つだけ頭に入れて先へ進み、詰まったらこの表に戻ってください。

3. 全体地図 — AWS セキュリティサービスの4層モデル

サービス名を個別に暗記するより、4つの層で捉えると一気に見通しが良くなります。
下の層から上の層へ、「記録 → 検知 → 集約 → 対応」と情報が流れます。

図A: AWS セキュリティサービスの4層モデル。検知層の findings が Security Hub CSPM に集まり、EventBridge 経由で通知・対応につながる。右端の破線が本記事の主役 —「CSPM の採点は Config ルールで動く」。

層	サービス	見ているもの	一言でいうと
① 記録層	AWS CloudTrail	API コール(操作の履歴)	「誰がいつ何をしたか」の記録係
① 記録層	AWS Config	リソースの構成と変更履歴	「今どんな設定か」の記録係 — 本記事の重要人物
② 検知層	Amazon GuardDuty	脅威(不審な API・通信・侵害の兆候)	脅威検知の探偵
② 検知層	Amazon Inspector	脆弱性(EC2 / ECR / Lambda の CVE)	脆弱性スキャナ
② 検知層	Amazon Macie	S3 内の機密データ(個人情報など)	データの見張り役
② 検知層	IAM Access Analyzer	過剰な権限・外部公開	権限の監査役
③ 集約層	AWS Security Hub CSPM	上記すべての findings + 自身の採点結果	集約ハブ + 採点者(検知はしない)
④ 対応層	Amazon EventBridge(→ SNS / Slack / チケット)	findings をトリガーに動く	通知・自動対応の配線

ポイント: ②検知層の各サービスは互いに独立で、それぞれ形式の違う「findings(検知結果)」を出します。バラバラのまま4つのコンソールを巡回するのは辛い — そこで③の Security Hub が登場します。

4. Security Hub の正体 — 仕事は2つ、検知はしない

「Security Hub」という名前から万能のセキュリティ監視装置を想像しがちですが、実際にやっている仕事は2つだけです。

仕事① findings の集約(single pane of glass)

GuardDuty・Inspector・Macie などが出す findings を、ASFF(第2章)という共通フォーマットに揃えて1か所に集めます。これにより「セキュリティ検知結果はとりあえず Security Hub を見ればよい」という単一の窓口ができます。

仕事② CSPM — 設定の採点

もう1つの仕事が CSPM(第2章)。標準と呼ばれる検査項目集(FSBP・CIS など)に沿って、アカウントの設定がベストプラクティスに従っているかを継続的に検査し、PASSED / FAILED をfindings として出します。こちらは「検知」ではなく「採点」です。

最重要ポイント: Security Hub 自身は脅威も脆弱性も検知しない。

脅威検知は GuardDuty、脆弱性は Inspector の仕事。Security Hub だけ有効化しても、「集約するものが無いハブ」と「設定の採点表」ができるだけです。逆に言えば、Security Hub の価値は周辺サービスと繋がって初めて出ます。

料金はどうなる? Security Hub CSPM には初回有効化から 30日間の無料トライアルがあり、以降はセキュリティチェック数・findings 取り込み数に応じた従量課金です。ただし採点の土台となるAWS Config は別料金(configuration item の記録数などに課金)で、こちらに無料トライアルはありません。小規模アカウントなら月数ドル程度に収まることが多いですが、正確にはSecurity Hub 料金・Config 料金で確認してください。

5. CSPM の採点は AWS Config で動いている — INCOMPLETE の正体

ではその「採点」はどういう仕組みで動くのか。ここが本記事の核心で、Security Hub を使うなら絶対に知っておくべき依存関係です。

図B: Hub ⊃ 標準 ⊃ コントロールの入れ子構造。コントロールの実体は AWS Config のサービスリンクルールで、recorder が無いと採点システム全体が止まり、標準は INCOMPLETE になる。

構造は入れ子になっています:

Hub(リージョン単位の有効化)の中に標準を有効化する — FSBP、CIS など
標準はコントロールの束 — 例: 「S3.5: S3 は SSL を強制すべき」「IAM.4: ルートアクセスキーを作らない」
そしてコントロールの実体は、AWS Config のサービスリンクルール(securityhub-*)。
Security Hub が標準を有効化すると、対応する Config ルールが自動生成され、それが実際の検査を行う

AWS 公式ドキュメントも明言しています:

"Security Hub CSPM uses service-linked rules from AWS Config to run security checks for most controls. … You must enable AWS Config and record resources in AWS Config for Security Hub CSPM to generate most control findings."

(訳)Security Hub CSPM はほとんどのコントロールの検査に AWS Config のサービスリンクルールを使う。コントロール findings を生成するには、AWS Config を有効化しリソースを記録していることが必須である。

つまり依存関係はこうなります:

標準の採点  ←  コントロール  ←  Config ルール  ←  Configuration recorder(記録中であること)

この一番右の recorder が存在しないと、鎖全体が動きません。実際、recorder が無いアカウントで標準を有効化すると、ステータスはこうなります:

aws securityhub get-enabled-standards --region ap-northeast-1

# → 有効化した標準が:
#   "StandardsStatus": "INCOMPLETE",
#   "StandardsStatusReason": { "StatusReasonCode": "NO_AVAILABLE_CONFIGURATION_RECORDER" }

厄介なのは、コンソールが目立つ場所で警告してくれるわけではないこと。「有効化した」という事実に安心してしまうと、採点が一度も走っていないことに気づけないまま放置されやすいのです。「有効化されているのに採点ゼロの Security Hub」はこうして生まれます。

教訓: Security Hub を有効化したら、必ず get-enabled-standards で StandardsStatus を確認する。READY 以外(特に INCOMPLETE)なら採点は動いていない。そして Security Hub より先に、AWS Config の recorder が動いているかを確認する。

6. 紛らわしい名前の整理 — 「Security Hub」は2つある

2025年に製品ラインが再編され、「Security Hub」という名前が指すものが2つになりました。調べ物をするとき混乱しやすいので整理しておきます。

	AWS Security Hub CSPM(本シリーズの主役)	新 AWS Security Hub(2025〜)
旧称	旧「AWS Security Hub」そのもの(改名された)	—(re:Inforce 2025 発表の新製品)
役割	findings 集約 + 設定の採点(CSPM)	複数サービスのシグナルを相関分析し、リスクを優先順位付け(exposure findings)
findings 形式	ASFF	OCSF(業界標準スキーマ)

両者は競合ではなく積み重ねの関係です。新 Security Hub は GuardDuty・Inspector・Macie、そして Security Hub CSPM をデータソースとして統合し、その上で相関分析を行います。

古い記事やブログで単に「Security Hub」と書かれているものは、ほぼすべて現在の
Security Hub CSPM のことです。本シリーズもまず CSPM を扱います(新 Security Hub は CSPM が土台として動いていることが前提になるため、順番としても CSPM が先)。

7. もうひとつの前提 — Security Hub は「リージョン単位」

最後にもう1つ、設計に効いてくる性質を予告しておきます。Security Hub CSPM の有効化・findings の保持はリージョン単位です。東京リージョンで有効化しても、us-east-1(バージニア北部)の findings は東京からは見えません。

「じゃあ CloudFront や WAF(us-east-1 にリソースがあるサービス)はどうするの?」—そこで登場するのがクロスリージョン集約(finding aggregator)(第2章)で、リンクしたリージョンの findings を集約リージョン(例: 東京)に自動で寄せられます。この設計と CDK での実装が第2回のテーマです。

8. まとめと次回予告

AWS のセキュリティサービスは「記録 → 検知 → 集約 → 対応」の4層で捉える(図A)
Security Hub CSPM の仕事は集約と採点の2つ。自身は何も検知しない
採点の実体は AWS Config のルール。recorder が無いと INCOMPLETE のまま採点ゼロ —
しかもコンソールは大きく警告してくれないので気づきにくい(図B)
「Security Hub」という名前は現在2製品(CSPM と新 Security Hub)を指すので注意

次回(第2回): この概念を踏まえて、AWS CDK で Security Hub CSPM を東京 + us-east-1 の2リージョンに構築します。既存リソースが混在する実アカウントで衝突しないための「ゲートパターン」、FSBP 単独方針、us-east-1 → 東京への findings 集約アーキテクチャを図で解説。

第3回: 構築中に実際にハマった AWS Config の循環デッドロック(CREATE_FAILED → ハング → 解決)。