AWS Security Hubとは？CSPMとの違い・料金と有効化手順を実装者目線で解説

AWSマネジメントコンソールで「Security Hub」を開くと、いま2つのサービスが並んでいます。2025年12月のre:Invent 2025で統合版のAWS Security HubがGAし、それまでのSecurity Hubが「AWS Security Hub CSPM」へ改称されたためです。検索で見つかる解説がどちらを指すか分からないまま設定を進めると、参照するAPIも料金の増え方も食い違います。この記事では2系統の役割分担、CLIでの有効化とAWS Configの前提条件、ASFFとOCSFで分かれた検出結果の取り扱い、リソースユニット課金の実額、採用条件と見送り条件を実装者目線で整理します。数値は2026年9月時点で公式ドキュメントと料金ページを実際に開いて確認したものです。

まとめ：AWS Security Hubを有効化する前に決める4つの前提

AWS Security Hubは、自分で脅威を検知するサービスではありません。GuardDutyが出す脅威、Inspectorが出す脆弱性、AWS Configが出す設定違反を集め、正規化し、対応の優先順位を付ける集約層です。ただし2025年12月の統合以降、集約層と検出側の境目は料金の面から見ると曖昧になりました。Essentialsプランのリソースユニット単価には、CSPMのコントロール評価もInspectorのEC2・ECR・Lambdaスキャンも含まれます。

先に決めておく前提は4つあります。第1に、設定準拠の確認だけならCSPM、脆弱性・脅威・機密データを横断して危険度の高い組み合わせを特定したいなら統合版、という選択。第2に、AWS Configの持たせ方。Security HubとCSPMを両方有効化する構成ではサービスリンク設定レコーダーが自動で作られ、手動のConfig設定は不要になりました。第3に、課金の主語がリソース量なのかログ量なのかという切り分け。Threat Analyticsを足すとログ量が主語に変わります。第4に、検出結果を週次以上でトリアージする担当の有無。担当が居ない環境では、有効化しても請求額が増えるだけです。

2系統のSecurity Hubを見分けて読むドキュメントを切り替える

設計を始める前に、どちらのSecurity Hubの話かを固定します。ここが曖昧なまま進むと、参照するドキュメントも料金試算も噛み合いません。

2025年12月のGAで分かれた新旧2系統と名称の対応を押さえる

2018年から提供されてきたAWS Security Hubは、統合版がGAしたタイミングで「AWS Security Hub CSPM」へ改称されました。社内で「Security Hub」と呼んできたものは、現在の名称ではCSPMを指します。新しくAWS Security Hubを名乗るのは、CSPMを内包しつつ脅威・脆弱性・機密データのシグナルを相関させる統合プラットフォームです。公式ドキュメントのURLも securityhub-v2- で始まるページ群が統合版、それ以外がCSPM側という分かれ方をしており、検索結果からいきなり開くと取り違えます。

既存のCSPM利用者に強制的な移行は課されていません。Security Hubの公式FAQにも、AWSリソースをベストプラクティスに照らして評価することが主目的ならCSPMを使い続けてよい、と明記されています。両方を同時に有効化する構成も公式に認められており、新規検討時の選択肢は「CSPM」「統合版」「両方」の3択です。

Security Hub CSPMでのFSBPとCIS v5.0.0のコントロール評価

CSPMの中核は、セキュリティ標準に対するコントロール単位の継続チェックです。AWSが定めたAWS Foundational Security Best Practices（FSBP）に加え、CIS Benchmarks、PCI DSS、NISTに対応します。判定の粒度は「S3バケットのパブリックアクセスがブロックされているか」といったレベルで、合否の二値評価に振り切っているのがCSPMの性格です。

CIS AWS Foundations Benchmarkについては、公式のバージョン比較表でv5.0.0・v3.0.0・v1.4.0・v1.2.0の4版が並存すると確認できます。AWSの推奨はv5.0.0で、複数版の同時有効化も可能です。版を上げるときは新しい版を有効化してから旧版を無効化する順序が案内されており、逆順にするとチェックの空白期間ができます。なお有効化直後にすぐ結果は出ません。既に有効な標準と同じConfigサービスリンクルールを使うコントロールでは、検出結果の生成まで最大18時間かかると明記されています。この待ち時間を知らずに「設定を間違えた」と切り分けに入る事故がよく起きます。CIS側の最新版はすでにv7.0.0まで進んでおり、Security Hub CSPMが追随していない版の差分はCIS AWS Foundations Benchmarkの版ごとの変更点で整理しています。

統合版の露出検出結果とtraitに基づく対応順序と件数の判断基準

統合版が持ち込んだのは「露出（Exposure）」という単位です。設定ミス、脆弱性、脅威検出、機密データの所在といった複数のシグナルを掛け合わせ、単独では低リスクに見える問題の組み合わせを露出検出結果にまとめます。インターネットから到達できるEC2に悪用されやすい脆弱性があり、そこへ強い権限のIAMロールが付いている──こうした構成が上位に浮かびます。

構造は2階建てです。露出検出結果に寄与する個々のfindingを「シグナル（signal）」と呼び、シグナルが持つ逸脱の種別を「トレイト（trait）」と呼びます。公式の用語集が挙げるtraitは、Assumability（引き受け可能性）、Misconfiguration（設定不備）、Reachability（到達可能性）、Sensitive Data（機密データ）、Vulnerability（脆弱性）の5種類です。1つのシグナルが複数のtraitを持つこともあります。ここで注意したいのが件数の数え方で、同じ用語集の説明は「1つのリソースが複数の露出検出結果に関与しうる」という記述です。リソースごとに1行しか出ない前提でダッシュボードの件数を見積もると、実際の対応件数を過少に見ます。traitが1つも無い、あるいは足りないリソースには露出検出結果自体が作られません。

Essentialsプランに含まれる機能のひとつが、IAM Access Analyzerのサービスリンクアナライザーです。有効化すると90日間さかのぼって未使用のIAMロール・ユーザー・アクセスキー・権限を洗い出す仕組みが自動で作られ、IAMがグローバルサービスであるためus-east-1で動きます。権限設計そのものの考え方はAWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説に整理しているので、未使用アクセスの検出結果を棚卸しする前に読むと手戻りが減ります。

ASFFとOCSF 1.6のどちらでfindingを受け取るかを確定する

CSPMは検出結果をAWS Security Finding Format（ASFF）で正規化します。取得APIはGetFindings、EventBridgeへ流れるイベントのdetail-typeは「Security Hub Findings – Imported」です。統合版はOpen Cybersecurity Schema Framework（OCSF）を採用し、公式ドキュメントはサポート版を「OCSF schema version 1.6」と記載しています。取得APIはGetFindingsV2、detail-typeは「Findings Imported V2」に変わりました。スキーマの定義そのものはOCSFの公開スキーマで引けます。

この差は表記ゆれではありません。フィールド構造そのものが違うため、ASFFのフィールド名を条件に書いた自動化ルールはOCSF側で動きません。統合版のAutomation rulesが条件に使えるのはcompliance.statusやvulnerabilities.cve.uidといったOCSF属性で、更新できるフィールドはComment・SeverityId・StatusIdの3つに絞られています。ASFF時代にWorkflow.Statusを直接書き換えていた運用は、そのままでは移せません。

CLIで有効化しAWS Configの前提条件を満たすまでの手順

前提サービスの持たせ方が、そのままカバレッジと請求額に反映されます。ここは2025年12月の統合で作法が変わった箇所です。

enable-security-hub-v2を実行して作られる資材を確認する

統合版の有効化はコンソールからでもできますが、複数リージョンへ展開するならCLIのほうが確実です。公式の有効化手順は、サービスリンクロールAWSServiceRoleForSecurityHubV2を先に作る方法として、管理アカウントでenable-security-hub-v2を実行するか、IAM側から直接ロールを作る2通りを案内しています。

# サービスリンクロールだけを先に作る（管理アカウント・任意のリージョン）
aws iam create-service-linked-role --aws-service-name securityhubv2.amazonaws.com

# 委任管理者アカウント側で統合版を有効化する
aws securityhub enable-security-hub-v2 --region ap-northeast-1

# CSPM側も併用する場合（既定の標準を同時に有効化する）
aws securityhub enable-security-hub --region ap-northeast-1 --enable-default-standards

有効化すると、上記のサービスリンクロールに加えてサービスリンク設定レコーダーとサービスリンクアナライザーがアカウントに作られます。作られるレコーダー名は用語集に列挙されており、各アカウント・各リージョンにAWSConfigurationRecorderForSecurityHubAssets、グローバルリソース用にus-east-1へAWSConfigurationRecorderForSecurityHubAssetsGlobal、CSPMを併用しているリージョンにはAWSConfigurationRecorderForSecurityHubCSPMが追加されます。名前を知っておくと、AWS Configのコンソールに見覚えのないレコーダーが増えたときにも、慌てずに確認できるはずです。

サービスリンク設定レコーダーに任せるか手動でConfigを組むか

ここが旧記事の記述から最も変わった箇所です。Configの前提条件ページは、Security Hub CSPMとSecurity Hubの両方が有効な場合、CSPMがサービスリンク設定レコーダーを自動で作成するため「手動でAWS Configを有効化・設定する必要はない」と明記しています。このときConfig.1コントロールは常にPASSEDになります。

手動設定が要るのは、Security Hubを有効化せずCSPM単体で使う場合に限られます。その構成では、有効化した各リージョンでConfigを有効にし、コントロールが評価するリソース種別の記録をオンにしなければなりません。対象の一覧は必要なAWS Configリソースに載っています。記録が抜けたコントロールはFAILEDではなくWARNINGを返すため、スコアだけを見ていると「評価されていない」ことに気付けません。記録対象の選び方とコスト設計はAWS Configとは？設定変更の記録・ルール評価・料金の考え方と導入判断で詰められます。

費用面では、Configの記録コストを自分で持つのか、Essentialsのリソースユニット単価に含まれるサービスリンクレコーダーに寄せるのかという選択になります。料金ページはEssentialsに含まれる機能として「Service Linked Config Recorder (AWS Config)」を明示的に挙げています。グローバルリソースの記録は1リージョンに寄せ、集約先を決めているならそのリージョンに置くのが公式の推奨です。

組織内の委任管理者の指定とメンバーアカウントへの展開手順・管理範囲

マルチアカウント運用の作法も変わりました。CSPMで使えたアカウントの招待と受理によるメンバー管理が、統合版では使えません。AWS Organizations配下で委任管理者アカウントを指定する構成が前提です。手順は、管理アカウントが委任管理者を指定して委任管理者ポリシーを作り、その委任管理者が自分のアカウントで有効化し、最後に組織全体へ適用する設定ポリシーを作る3段階になります。

指定できるアカウントには制約があります。CSPM側で既に委任管理者を設定していて、それが管理アカウント以外なら、そのアカウントが自動的に統合版の委任管理者になり、別のアカウントは選べません。管理アカウント自身を委任管理者にすることもできません。組織設計の考え方はAWS Organizationsとは？マルチアカウント管理・SCP/RCP・一括請求の仕組みと設計判断を実装者目線で解説にまとめているので、Organizationsを組んでいない環境はそちらの整備から着手してください。この順序を飛ばすと、カバレッジ画面が虫食いのまま埋まりません。

有効化するリージョンを絞りCIS完全準拠の要件と費用を突き合わせる

Security Hubが取り込むのは有効化した後に生成された検出結果だけで、過去に遡って既存の問題を吸い上げる動きはしません。受け取る範囲も有効化したリージョンに限られます。CSPM単体構成ではAWS Configも各リージョンで有効化が要るため、CIS AWS Foundations Benchmarkの準拠を対外的に示すなら、全対応リージョンで有効化する話になります。現実解はクロスリージョン集約で集約先を1つに寄せる構成です。

ここは費用と直結します。全リージョンを有効化すればチェック件数もリソースの監視対象も全リージョンで走るためです。準拠を証明する必要がないなら、使用リージョンに限定して有効化し、未使用リージョンはService Control Policiesでリソース作成自体を封じるほうが軽く済みます。証明が要るのか、実害を減らしたいのか。この問いを先に決めると設定は一意に定まります。自社で線引きを決めきれないなら、インフラ構築（AWS・Google Cloud・Azure）のような外部の設計支援で、アカウント構成とリージョン方針を先に固めてから有効化に入る進め方もあります。

リソースユニット課金の実額試算と構成・監視時間による請求額の変化

2026年9月時点のSecurity Hub料金ページは、Essentialsプランを土台に、Threat AnalyticsとLambdaコードスキャンをアドオン、提携製品をExtended Planとして載せる3層構成になっています。以下の金額は同ページの表示に基づく2026年9月時点の値で、リージョンによって単価は異なります。

Essentialsプランに何が含まれるかを料金ページの記載で確認する

Essentialsプランはリソースユニット単価3.75USDの月額課金で、スキャン回数では増減しません。料金ページが「per-resource unit price」に含まれると列挙している機能は次のとおりです。

• リスク分析・検出結果の優先順位付け・セキュリティリソースグラフ
• 露出検出結果、AIインベントリ、ネットワークスキャン、未使用アクセス検出
• 検出結果の取り込みと集約、Security Hub Automation Rules
• Cloud Security Posture Management（Security Hub CSPM）
• Inspectorによる EC2・ECRコンテナイメージ・Lambda標準スキャンとCISベンチマーク評価
• サービスリンク設定レコーダー（AWS Config）

旧来の「CSPMはチェック実行数と検出結果取り込み数の従量課金、取り込みは月1万件まで無料」という説明は、2026年9月時点の料金ページには掲示がありません。公式FAQも、CSPM利用者は従量課金からリソースベース課金へ移り、セキュリティチェックと検出結果の取り込みが無制限になると説明しています。旧来の単価で試算した見積りを持っているなら、作り直しが要ります。

リソースユニットの換算比率に基づく月額計算と監視時間による日割り

課金対象はEC2インスタンス、ECRコンテナイメージ、Lambda関数、IAMユーザーとロールの4種類だけです。他のリソースも監視されますが、料金には乗りません。換算比率は次のとおりで、Azure側の同等リソースにも同じ比率が適用されます。

# 月額の見積り：EC2 40台・Lambda 120関数・ECRイメージ 90個・IAMプリンシパル 250個
# 換算は EC2=1台で1、Lambda=12個で1、ECRイメージ=18個で1、IAM=125個で1
python3 -c "print(round((40 + 120/12 + 90/18 + 250/125) * 3.75, 2))"
# 出力: 213.75  （57ユニット × 3.75USD）

EC2の比重が大きい設計のため、サーバーレス中心の構成ほど単価の負担が軽くなる料金体系です。もうひとつ効くのが日割りで、料金ページは「監視された時間に応じてプロレート」と明記しています。EC2の平均台数は稼働時間の合計を月720時間で割って求めるため、360時間・350時間・10時間の3台は合計720時間、つまり平均1台として数えられます。ECRイメージも同じ考え方で、既定14日の再スキャン期間のうち実際に監視された分だけが対象です。常時稼働していないバッチ用インスタンスを多く抱える環境では、台数をそのまま掛けた見積りは過大になります。

料金ページの試算例を読む際に注意したいのは、内訳と請求行の整合性です。CloudTrail管理イベント200万件・セキュリティデータ800GB・EC2 500台の例は、8.00USD・440.00USD・1,875.00USDで合計2,323.00USDと整合しています。一方、大規模例のほうはEC2 1,000台・Lambda 5,000関数・ECRイメージ2,000個・IAM 3,000個の内訳を1,000＋417＋111＋24＝1,552ユニットと自ら示しながら、請求行は2,233ユニットで計算されています。2026年9月時点の表示を実際に読んだ結果として食い違いが残っているため、見積りは例文を引き写さず、上の換算表から自分で計算してください。

Threat Analyticsのログ単価と段階の境目を見てから足す

Threat AnalyticsはGuardDutyを土台にしたアドオンで、CloudTrail管理イベント、S3データイベント、VPCフローログ、DNSクエリログ、EKS監査ログを対象にします。単体では使えず、Essentialsプランが前提です。課金はログ量に応じた別建てで、段階の境目は次のように置かれています。

月数百GB程度の環境では0.55USDの帯から出ません。全サブネットで全トラフィックのVPCフローログを取得している環境は、有効化の前に取得対象を絞ってください。逆に500TB規模になると段階制が効き、料金ページの例では1,000GB＋9,000GB＋502,000GBの三段で計算した金額は53,000USDです。土台になるCloudTrail側の設計はAWS CloudTrailとは？監査とセキュリティを強化する仕組みと合わせて決めると重複が避けられます。検出結果を送り込むGuardDuty側の単価はAmazon GuardDutyの料金：東京リージョンの実額とMalware Protectionの追加課金で確認できます。

無料トライアルの範囲にも線があります。30日間の無料トライアルはアカウント単位・リージョン単位で付与され、過去にCSPMやInspectorのトライアルを使っていても対象です。ただし公式FAQは、Threat AnalyticsとLambdaコードスキャン、そしてExtended Planはトライアルに含まれないと明記しています。トライアル中の請求額をそのまま本番の月額と見なすと、アドオンのぶんだけ外れます。

Extended Planの提携製品課金を使うか自前調達かを分ける

2026年9月時点の料金ページには、旧記事の時点では無かったExtended Planが載っています。エンドポイント、アイデンティティ、メール、ネットワーク、データ、ブラウザ、クラウド、AI、セキュリティ運用の各カテゴリにわたる23の提携製品を、AWSの請求に相乗りする形で調達する枠組みです。前払い不要でPPAやEDPのコミットメントにも算入でき、Essentialsプランの有効化が前提になります。

実際の単価も掲示されています。CrowdStrikeはワークロード種別と数量階層で分かれ、サーバー1台あたり月15.75USDから6.30USDまで6段階。Oktaは1ユーザー月20USD（最低10ユーザー）、Zscalerは席数階層で545USDの定額から1席8.25USDまで、Proofpointは1ユーザー月5.00USD（最低750ユーザー）といった具合です。判断軸は単純で、既にこれらの製品を直接契約していて調達も安定しているなら乗り換える理由は薄く、逆に調達部門を通す手間と支払いの一本化に価値があるならExtended Plan側に寄せる。ライセンス単価そのものが大幅に引き下げられる仕組みではないため、値引きを期待して選ぶと外します。

GuardDuty・Inspector・Macieとの役割分担と重複投資の整理

Security Hubを入れても検出能力そのものは増えません。増えるのは、既に出ている検出結果を処理する効率と、料金の束ね方です。

脅威・脆弱性・機密データを出す3サービスと集約側の境界を引く

材料を供給する主なAWSサービスは3つです。GuardDutyがCloudTrailやVPCフローログ、DNSログから不審な挙動を検知し、Amazon InspectorがEC2・ECRイメージ・Lambdaの既知脆弱性をスキャンし、Amazon MacieがS3上の機密データを検出します。加えてAWS Config、IAM Access Analyzer、Firewall Managerも検出結果の送信元です。集約したfindingから根本原因を辿る側はAmazon Detectiveとは？behavior graphの仕組み・料金とGuardDutyとの使い分けを実装者目線で解説が担います。

脅威検出の仕組みはAmazon GuardDutyとは？AWS環境の脅威検出サービスの基本的な概要と特徴、脆弱性スキャン側の仕様と料金はAmazon Inspectorとは？対応スキャンと料金・Classic終了後の導入判断、Classic時代の操作手順はAmazon Inspectorで行う脆弱性診断の手順とそのメリットが対応します。逆に言えば、脅威検出を有効にしないままSecurity Hubだけ有効化しても、集まるのは設定準拠と脆弱性のシグナルに寄ります。統合版の露出検出は複数シグナルの相関で成り立つため、供給元が1系統では中核が働きません。露出という単位で継続的に危険度を測る考え方そのものはCTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断で整理しており、Security Hubはその実装のひとつと位置づけられます。

有効化で既存サービスの請求がSecurity Hub側へ寄る影響を織り込む

見落としやすいのが請求の付け替えです。公式FAQは、Security Hubを有効化すると既存のInspector・GuardDuty・CSPMの課金がSecurity Hubの料金体系へ移り、個別のサービス請求ではなく統合された請求になると説明しています。移行のための操作は要りません。

判定はアカウント単位です。同じOrganizations配下でも、Security Hubを有効化したアカウントはリソースベース課金、有効化していないアカウントは従来どおり各サービスの個別課金という混在が起こります。コスト配賦を部門別に切っている組織では、有効化の順番がそのまま請求書の見え方を変えます。先に1アカウントで試すなら、どのコストセンターに紐づくアカウントかを選んでから有効化してください。

サードパーティCSPMとの併用時におけるクラウド構成と一次窓口の判断

既にCNAPP製品やサードパーティのCSPMを導入している環境では、機能が正面から重なります。判断軸はマルチクラウドかAWS単独かの一点に置くとぶれません。Google Cloudを含む3クラウド構成なら外部製品を主系にし、Security Hubは送信元へ回します。AWS単独なら外部製品のライセンス費用を払う理由は薄く、カテゴリ自体の整理はCNAPとは？クラウドネイティブ保護を1つに束ねる仕組みとCNAPPとの違い・採用判断にまとめています。

ただしAzureを含む2クラウド構成は判断が変わりました。Essentialsプランがマルチクラウドを内包し、Azure VMを1リソースユニット、Azure Function Appsを12個で1ユニットと、AWS側と同じ比率で課金します。Azure連携を作ると、その監視にも独立した30日間の無料トライアルが付きます。AWS＋Azureだけなら外部製品を入れずに済む可能性があるので、併用の判断前に一度カバレッジを実測してください。併用する場合は同じ設定違反が二重に上がるため、どちらを一次窓口にするかを先に決めます。

検出結果の取得から抑制ルールの作成までを含む有効化後の運用設計

有効化はゴールではありません。出てきた検出結果を減らす仕掛けを同時に入れておかないと、初週で運用が止まります。

GetFindingsV2をCLIで叩いて重大度の高いものから取り出す

統合版の検出結果はコンソールだけでなくCLIからも取れます。get-findings-v2のコマンドリファレンスによると、--filtersは最大10個の複合フィルタを受け取り、文字列・日付・真偽値・数値・マップ・IPアドレスの各フィルタと3階層までのネストに対応します。

# CRITICAL の検出結果を重大度の降順で50件取り出す
aws securityhub get-findings-v2 \
  --region ap-northeast-1 \
  --max-items 50 \
  --sort-criteria '[{"Field":"severity","SortOrder":"desc"}]' \
  --filters '{"CompositeFilters":[{"StringFilters":[{"FieldName":"severity","Filter":{"Value":"CRITICAL","Comparison":"EQUALS"}}],"Operator":"AND"}],"CompositeOperator":"AND"}'

フィルタ値は大文字と小文字を区別します。CRITICALをCriticalと書くと空の配列が返り、しかもエラーにならないので気付きにくい落とし穴です。委任管理者アカウントなら--scopesで組織単位（OU）を指定して絞り込めます。もうひとつ覚えておきたいのが、GetFindingsV2はアーカイブ済みのfindingも一緒に返す仕様です。現役の問題だけを見たいなら、statusフィールドの条件を明示的に加えてください。IAMポリシー側で必要なアクションはGetFindingsと共通で、securityhub:GetFindingsを許可します。

Automation rulesで初週のトリアージ件数を数十件に抑える

有効化直後は検出結果が数百件から数千件出ます。全件対応は現実的でないので、初期対応は重大度と対象環境の2軸で切ります。本番タグの付いたリソースのCRITICALとHIGHだけを対応対象とし、それ以外はAutomation rulesで抑制する。この設定を有効化と同時に入れておくと、初週のトリアージが数十件に収まります。

Automation rulesの公式ドキュメントには、後から入れても手遅れになる仕様が2つ書かれています。1つ目は評価対象で、ルールはルール作成後に生成・取り込みされた検出結果だけを見ます。既存の山は片付きません。2つ目は評価順で、複数のルールが同じフィールドに作用する場合、ルール順の数値が大きいものが最後に適用されて最終値を決めます。抑制ルールを足すたびに順序を確認しないと、先に書いた重大度の引き上げが後のルールで打ち消されます。

リージョンの扱いにも癖があります。集約を使っている場合、ルールを作れるのはホームリージョンだけで、そこで定義したルールが全リンクリージョンへ適用されます。リンクしていないリージョンでは、それぞれに個別のルール作成が必要です。JiraクラウドとServiceNow ITSMへのチケット起票もAutomation rulesから設定でき、検出結果が届いた時点でチケットが立ちます。

EventBridgeとSIEMのどちらへ流すかを条件で切り分ける

通知や自動修復を組むなら、EventBridge経由が基本形です。イベント形式のドキュメントによれば、統合版のfindingはsourceがaws.securityhub、detail-typeがFindings Imported V2として自動的に送られます。属性値で絞り込む場合は、その属性がOCSF構造のどこにあるかをイベントパターンに反映させる必要があります。

# OCSF形式のfindingをEventBridgeで受ける（統合版）
aws events put-rule \
  --region ap-northeast-1 \
  --name securityhub-v2-findings \
  --event-pattern '{"source":["aws.securityhub"],"detail-type":["Findings Imported V2"]}'

# 旧CSPM側は detail-type が別物なので、両系統を受けるならルールを2本に分ける
aws events put-rule \
  --region ap-northeast-1 \
  --name securityhub-cspm-findings \
  --event-pattern '{"source":["aws.securityhub"],"detail-type":["Security Hub Findings - Imported"]}'

ルーティングの組み方そのものはAmazon EventBridgeとは｜イベント駆動連携の仕組み・料金・実装と採用判断で整理しています。その先にSIEMまで作るかは別の判断です。Security Hubが扱うのはセキュリティサービスが出した検出結果だけで、アプリケーションログ、OSのイベントログ、オンプレミス機器のログ、SaaSの監査ログは対象外です。SIEMが要るのは3つの場合に絞られます。AWS以外の環境やSaaSのログを横断相関したいとき、検出結果を1年を超えて長期保管する要件があるとき、SOCが既にあり全アラートを1窓口へ集約する方針が決まっているときです。機能範囲と製品選定の考え方はSIEMとは？仕組み・機能とEDR/XDR/SOARの違い・製品選定を実装視点で解説で整理しています。どれにも当てはまらない段階でSIEMを先に買うと、投入するログが集まらないまま容量課金だけが走ります。

導入を採用する組織と見送る組織を分ける運用体制・対応工数の条件

実務で費用対効果が出る条件と、出ない条件をそれぞれ言い切ります。

採用条件となる組織内のアカウント数と検出結果を処理する担当の有無

効果が出るのは、次の2条件を同時に満たす組織です。第1に、AWS Organizations配下でアカウントが概ね5つ以上あり、環境ごとにセキュリティ設定が分散していること。横断ビューが無いと、どのアカウントに未対応の問題が残るかを人手で追う羽目になります。第2に、検出結果を週次以上の頻度で見る担当が決まっていること。担当が居なければ、集約しても何も起きません。

この2条件が揃うなら統合版のEssentialsプランを推奨します。露出検出が「今週どれから手を付けるか」の答えを出すためです。加えて、既にInspectorとGuardDutyを個別課金で使っている組織は、有効化するだけで請求が一本化されるぶん、コスト管理の手間も減ります。逆に、監査への回答が主目的で設定準拠の証跡だけが要るならCSPM単体で足ります。

月次の工数は、トリアージ会議1時間、個別対応が1件あたり0.5〜2時間、四半期ごとの抑制ルール見直しに半日、という粒度で置くと現実に合います。統合版の露出検出は件数が絞られる設計のため、CSPMのコントロール検出結果を全件見る運用より工数は下がります。ただし抑制ルールを見直さないと本来対応すべき問題まで紛れ込むので、四半期の棚卸しは外さないでください。

単一アカウント運用での導入見送りを判断する規模・担当・予算の3つの条件

見送るべき条件は3つあります。1つ目は、AWSアカウントが1つでリソースも数十程度にとどまる環境。この規模ならAWS Config単体のルール評価とGuardDutyの通知で回ります。2つ目は、検出結果を処理する担当も外部委託先も決まっていない状態。無料トライアルの後、誰も開かないダッシュボードに月額が発生し続けます。

3つ目は、検出結果に対応する予算も枠も確保していない状態です。有効化すれば設定不備が必ず出るという前提です。出たあとに直す工数が取れないなら、可視化しただけで放置された記録が残り、監査ではむしろ不利に働きます。いずれかに当てはまるなら、まず検出側のサービスを1つずつ整えるほうが投資効率は高くなります。

ASFF依存の自動化が壊れる失敗パターンを移行前に棚卸しする

CSPMから統合版へ移る際の典型的な失敗が、自動化の断線です。ASFFのフィールド名でフィルタしていたEventBridgeルール、ASFF構造を前提にJSONをパースしていたLambda関数、ASFF形式で受け取る想定のSIEM連携。これらはOCSFへ切り替わった時点で条件に一致しなくなり、アラートが静かに止まります。エラーが出ないため、気付くまで時間がかかります。

移行前にやることは棚卸しです。ASFFのフィールドを参照する箇所を洗い出し、書き直す分を仕分けます。仕分けが終わるまではCSPMと統合版を併用し、旧系統の自動化を生かしたまま移行するのが安全です。detail-typeを2本立てにしておけば、切り替え中もどちらの経路からも受け取れます。棚卸しの工数を割ける人が居ない場合や、現行環境にどんな設定不備が残るかを先に把握したい場合は、脆弱性診断・セキュリティ診断のような外部診断で現状を確定させてから設計に入ると、有効化後に検出結果が大量に出て手が止まる事態を避けられます。

AWS Security Hubの有効化と料金に関するよくある質問

検討段階で問い合わせが多い論点を、仕様と料金の観点で5つ回答します。

AWS Security HubとSecurity Hub CSPMはどちらを使えばよいですか？

設定がベストプラクティスに沿っているかを確認し、監査へ回答できる証跡が欲しいだけならSecurity Hub CSPMで足ります。設定ミスに加えて脆弱性・脅威・機密データを横断し、最も危険な組み合わせを特定したいなら統合版です。両者は併用でき、公式FAQも同時利用を認めています。判断軸は組織の規模ではなく、運用にどこまで踏み込むかの深度に置いてください。

Security Hubを使うにはAWS Configを有効にする必要がありますか？

統合版のSecurity HubとSecurity Hub CSPMを両方有効にする構成なら、サービスリンク設定レコーダーが自動で作られるため手動のAWS Config設定は不要です。この場合Config.1コントロールの評価結果は常にPASSEDです。手動設定が必要なのはCSPMを単体で使う場合で、有効化した各リージョンでConfigを有効にし、コントロールが評価するリソース種別の記録をオンにします。記録が抜けたコントロールはWARNINGを返します。

有効化する前に発生していた問題も検出結果として出ますか？

出ません。Security Hubは有効化した後に生成された検出結果のみを取り込み、遡及的な収集は行いません。受け取る範囲も有効化したリージョンに限られます。Automation rulesも同様で、ルール作成後の検出結果しか評価しません。監査対応の直前に有効化しても過去分の証跡にはならないため、証跡が要る要件があるなら早い段階で有効化して蓄積を始めてください。

Security Hubの料金はどのくらいかかりますか？

Essentialsプランは1リソースユニットあたり月額3.75USD（料金ページの表示に基づく2026年9月時点の値。リージョンで単価は異なる）で、EC2 1台が1ユニット、Lambda 12関数が1ユニット、ECRイメージ18個が1ユニット、IAMプリンシパル125個が1ユニットに換算されます。この単価にCSPMのコントロール評価とInspectorのスキャンが含まれます。Threat Analyticsは別建てで、CloudTrail管理イベントが100万件4.00USD、セキュリティデータは初回1,000GBが1GB 0.55USDです。30日間の無料トライアルはEssentialsのみが対象で、アドオンとExtended Planは含まれません。

CSPMから新しいSecurity Hubへ移行するとき何に注意すべきですか？

検出結果のスキーマがASFFからOCSF 1.6へ変わる点です。ASFFのフィールド名を条件にしたEventBridgeルール、JSONを直接パースしているLambda関数、SIEM連携は、切り替え後に一致しなくなり通知が止まる可能性があります。統合版のAutomation rulesが更新できるのはComment・SeverityId・StatusIdの3フィールドに限られるため、ASFF時代の書き換え処理はそのまま移せません。移行前にASFF依存箇所を棚卸しし、当面は両方のdetail-typeを受ける構成で併用しながら切り替えてください。

関連記事

• AWS Configとは？設定変更の記録・ルール評価・料金の考え方と導入判断：CSPM単体構成で前提になる設定記録の仕組み。
• AWS Organizationsとは？マルチアカウント管理・SCP/RCP・一括請求の仕組みと設計判断を実装者目線で解説：委任管理者を置く前段の組織設計。
• Amazon GuardDutyとは？AWS環境の脅威検出サービスの基本的な概要と特徴：脅威の検出結果を送る側。
• Amazon Macieとは？S3の機密データ検出の仕組み・料金と日本語データの限界：機密データのシグナル供給元。
• AWS KMSとは？仕組み・料金とキーポリシー設計・採用判断：暗号化コントロールの合否に関わる鍵管理。
• AWS Secrets Managerとは？料金・ローテーションと採用判断：認証情報の扱いに関するコントロール対応。