CloudWatchでSecurityHubCSPMfindingsを組織規模で取込可能に

Posted at 2026-05-05

Amazon CloudWatch で Security Hub CSPM findings を組織規模で取り込めるようになったので整理する

はじめに

2026年3月31日、Amazon CloudWatch が AWS Security Hub CSPM findings の取り込みに対応しました。

これにより、Security Hub CSPM の検出結果を CloudWatch Logs に直接取り込み、CloudWatch Logs Insights などで検索・集計できるようになりました。

今回のアップデートでは、Security Hub CSPM findings を ASFF または OCSF 形式で取り込めます。また、CloudWatch Pipelines を利用した標準化されたセキュリティデータ取り込みにも対応しています。

1. アップデート概要

1.1 何ができるようになったのか

今回のアップデートにより、Amazon CloudWatch で Security Hub CSPM findings を直接取り込めるようになりました。

取り込まれた findings は CloudWatch Logs に保存されるため、CloudWatch Logs Insights を使った検索や集計が可能になります。

対応している形式は以下です。

ASFF
OCSF

ASFF は Security Hub CSPM の標準的な Finding 形式です。一方で、OCSF は複数のセキュリティログを横断的に扱うための標準化フォーマットとして利用できます。

そのため、Security Hub CSPM の findings をそのまま分析したい場合は ASFF、他のセキュリティログと合わせて分析したい場合は OCSF、という使い分けが考えられます。

また、今回の機能は組織規模での有効化にも対応しています。大規模な AWS Organizations 環境で、各アカウントに対して個別設定するのではなく、CloudWatch 側の仕組みで一貫した取り込み設定を行える点がポイントです。

1.2 これまでとの違い

これまで Security Hub の検出結果を CloudWatch Logs に保存したい場合、一般的には以下のような構成を自前で用意する必要がありました。

Security Hub
EventBridge
Lambda
CloudWatch Logs

この構成でも実現は可能ですが、Lambda の実装、エラーハンドリング、ログ形式の整形、運用保守などを考える必要があります。

今回のアップデートにより、CloudWatch 側の機能として Security Hub CSPM findings を取り込めるようになったため、ログ分析用途の構成をシンプルにできます。

ただし、EventBridge が不要になるというより、役割が分かれると考えるのがよいです。

CloudWatch Logs 連携
- findings を蓄積・検索・集計する用途に向いている
EventBridge 連携
- 特定条件の findings をトリガーに通知・修復・チケット起票する用途に向いている

つまり、今回のアップデートは「Security Hub CSPM findings をログとして分析するための標準ルートが増えた」と捉えると分かりやすいです。

2. 取り込みの仕組み

2.1 取り込み先と関連機能

Security Hub CSPM findings の取り込み先として、以下のロググループが利用されます。

/aws/securityhub_cspm/findings

CloudWatch の telemetry enablement rules のドキュメントでも、Security Hub logging ではこのマネージドロググループパターンを使用することが示されています。

2.2 有効化時の注意

ここで注意したいのは、Security Hub CSPM 側の組織有効化と、CloudWatch 側の組織規模の取り込み有効化は役割が異なるという点です。

Security Hub CSPM 側の組織有効化は、各アカウント・リージョンで Security Hub CSPM を有効化し、検出結果を生成するための仕組みです。

一方で、CloudWatch 側の organization-wide enablement は、生成された Security Hub CSPM findings を CloudWatch Logs に取り込むための仕組みです。

つまり、以下のように分けて理解するとよいです。

Security Hub CSPM 側
→ findings を生成する

CloudWatch 側
→ findings を CloudWatch Logs に取り込む

また、有効化直後にすぐログが出ない可能性があります。

CloudWatch の telemetry configuration は、AWS Config と統合して対象リソースや設定を検出します。そのため、初回検出や反映に時間がかかる場合があります。

検証時は、有効化直後にログが出ない場合でも、設定ミスと決めつけず、以下を確認するとよいです。

Security Hub CSPM 側で findings が生成されているか
対象リージョンが合っているか
CloudWatch 側の enablement rule が有効になっているか
ロググループ /aws/securityhub_cspm/findings が作成されているか
反映まで一定時間待っているか

3. ログ量とコストの注意点

3.1 ログ量を左右する要素

Security Hub CSPM findings を CloudWatch Logs に取り込む場合、気になるのがログ量です。

結論から言うと、AWS公式から「平均で1 Finding あたり何KB」「月間で何GB程度」といった固定目安は見つけられませんでした。

ログ量は、主に以下の要素で変わります。

Finding 件数
1件あたりのサイズ
Finding の更新頻度
有効化しているセキュリティ標準
有効化しているコントロール数
対象リソース数
AWS Config の記録対象
ASFF / OCSF の選択
Consolidated control findings の有効/無効

特に注意したいのは、Finding は新規作成だけでなく、再評価や状態変更によって更新される可能性がある点です。

そのため、単純に「未解決Finding数 × 1件あたりのサイズ」だけでログ量を見積もると、実際の取り込み量とずれる可能性があります。

概算する場合は、以下のように考えるとよいです。

月間ログ量 ≒ 1日あたりのFinding出力・更新件数 × 1件あたりの平均サイズ × 30日

ただし、これはあくまで概算です。実際には、代表アカウント・代表リージョンで有効化して、CloudWatch Logs 側の取り込み量を実測するのが現実的です。

3.2 実測してから展開する

Security Hub CSPM findings のサイズに関して、重要な注意点があります。

ASFF Finding のサイズが 240KB を超える場合、Security Hub CSPM は Resource.Details オブジェクトを Finding から削除します。

つまり、1 Finding あたり最大 240KB 程度を意識する必要があります。

ただし、通常の Finding が常に 240KB になるわけではありません。実際のサイズは、対象リソース、コントロール、Finding の内容、ASFF / OCSF の選択などによって変わります。

CloudWatch Logs 側の取り込み量を確認する場合は、IncomingBytes を確認します。

IncomingBytes は、CloudWatch Logs にアップロードされたログイベントの量を非圧縮バイト数で表すメトリクスです。LogGroupName ディメンションを指定することで、特定ロググループ単位の取り込み量を確認できます。

対象ロググループは以下です。

/aws/securityhub_cspm/findings

そのため、展開時は以下の流れが安全です。

代表アカウント・代表リージョンで有効化する
数日から1週間程度、IncomingBytes を確認する
1日あたりのイベント数と平均サイズを確認する
アカウント数・リージョン数を掛けて月間ログ量を概算する
ログ保持期間を設定する
必要に応じて長期保管は S3 や Security Lake も検討する

特にログ保持期間は忘れやすいポイントです。

Security Hub CSPM findings はセキュリティ分析に有用ですが、すべてを長期間 CloudWatch Logs に保持するとコストが増える可能性があります。短期分析は CloudWatch Logs、長期保管や大規模分析は S3 / Security Lake など、用途に応じて保存先を分ける設計も検討するとよいです。

まとめ

Amazon CloudWatch が Security Hub CSPM findings の取り込みに対応したことで、Security Hub CSPM の検出結果を CloudWatch Logs に直接集約し、検索・集計しやすくなりました。

従来のように EventBridge や Lambda を組み合わせなくても、CloudWatch 側の仕組みでログ分析用途の構成を作りやすくなった点は大きなメリットです。

一方で、実際のログ量は環境によって大きく変わります。

特に以下の点には注意が必要です。

ASFF / OCSF のどちらで取り込むか
Finding の出力・更新頻度
有効化している標準やコントロール数
対象リソース数
1 Finding 最大 240KB の注意
CloudWatch Logs の IncomingBytes
ログ保持期間

大規模な Organizations 環境では、最初から全体展開するのではなく、代表アカウントで実測してから展開範囲を広げるのがよいと考えます。

今回のアップデートは、Security Hub CSPM findings を「画面で確認するもの」から「ログとして蓄積・分析するもの」に広げるアップデートです。

Security Hub CSPM の運用レポート、月次棚卸し、アカウント別・リージョン別の傾向分析などに活用しやすくなるため、Organizations 環境で Security Hub CSPM を運用している場合は、ぜひ確認しておきたいアップデートです。

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up