AWS Security Hub CSPM 有効化設計の教科書 CIS / NIST / PCI をどう選ぶか

今回登場する
CIS,NIST,PCIの参考記事は以下の通りです。
AWSで選択できるセキュリティ基準についてまとめているので、設計前に一読ください。
CIS：AWSで最初に有効化すべきCSPM基準はこれだけ CIS AWS Foundations入門
NIST：NISTは設定基準ではない
PCI：「うちはカードを扱っていない」は危険 PCI DSSとCSPMのリアル

またLTを行った資料もこちらにあります。直感的に絵で学びたい方はこちらをご覧ください。
https://speakerdeck.com/renyamauchi/20260220-alittlebittooopen-dot-pptx

第1章：なぜ「全部ON」は間違いなのか

〜CSPMを検証PoC環境で試したとある日の話〜
Security Hub CSPMを触る前に必ず閲覧お願いします。
絶対共感者がいるはず...

「CSPMを入れたら、むしろ治安が悪くなった」

ある日、私は検証用のPoC環境に
CNAPP（CSPM / CWPP / CIEM を含む統合セキュリティ基盤）を導入しました。

ダッシュボードを開いた瞬間に表示されたのは、

• Critical：10件超
• High：100件越
• Medium：把握不能

正直、こう思いました。

「……これ、本番でチケット自動起票にしていたら泣いていたな」

とりあえず「全部ON」にした結果

PoC ということもあり、私は CSPM の設定画面で

• CIS の複数バージョン
• NIST の複数規格
• PCI DSS の新旧両方

を、すべて有効化しました。

理由はとても単純です。

「PoC だし、全部見てみたほうが勉強になるだろう」

この軽い判断が、のちに大きな学びになります。

起きたのは“検知の洪水”

現象	何が起きていたか
同じ指摘が何度も出る	バージョン違いのCISが別々に検知
内容が理解できない指摘が増殖	対象外のNIST項目が混入

PoC 環境だったからこそ冷静に眺められましたが、
これが本番で自動連携されていたら、
現場は確実に混乱していたはずです。

CSPMは「安全装置」ではなく「増幅器」

この検証を通じて強く感じたのは、CSPMは

良い設計ならセキュリティを強化し、
悪い設計なら混乱を何倍にも増幅する装置

だということです。

失敗の本質は「基準の選び方」

問題はツールの性能でも運用の努力でもなく、
「どの基準を有効化するか」を考えずにONにした設計そのものでした。

CSPMにおいて最初に決めるべきなのは、

• どんな顧客か
• どんな規制を背負っているか
• どこまでを守る必要があるのか

――この前提条件です。

第2章：PCI / NIST / CIS の役割を一言で整理する

CSPM を触っていると、必ずぶつかる疑問があります。

「CIS、NIST、PCI…
結局、何がどう違うの？」

ここを曖昧にしたまま基準を有効化すると、
第1章で触れたような“検知の洪水”が必ず発生します。

それぞれは「守る目的」がまったく違う

まずは一言で整理します。

フレームワーク	一言で言うと
PCI DSS	守らないと事業ができなくなる「義務」
NIST	組織としてどう守るかを決める「設計思想」
CIS	AWSのどの設定をONにすればいいかの「実装ルール」

PCI DSS：クレジットカード業界の絶対ルール

PCI DSS は「セキュリティのベストプラクティス」ではありません。

**カード番号を扱うなら、守らなければ契約できない“業界ルール”**です。

• ECサイト
• 決済API
• カード登録画面

このどれかがあるだけで、
PCI DSS 対応は努力目標ではなく必須条件になります。

NIST：セキュリティを構造的に考えるための地図

NIST は、

• どこを守るか
• どう検知するか
• 事故が起きたらどう復旧するか

といったセキュリティ全体の考え方を整理するための設計書です。

代表的な NIST CSF の5機能は以下です。

機能	意味
Identify	何を守るか
Protect	どう守るか
Detect	どう検知するか
Respond	どう対応するか
Recover	どう復旧するか

NIST は「具体的なAWS設定」を決めるものではなく、
CSPM・CWPP・SOARなどをどう組み合わせるかの設計図になります。

CIS：NISTをAWSの設定に翻訳したもの

CIS はとても実務的です。

• CloudTrail は有効か
• Root に MFA は付いているか
• S3 はパブリックになっていないか

といった、
「結局どの設定をONにすればいいのか」だけをまとめたチェックリストです。

多くの CSPM ツールは、
この CIS をそのままロジックとして実装しています。

この3つを混同すると必ず事故る

• PCI は「守らないと契約できないルール」
• NIST は「どう設計するかの考え方」
• CIS は「AWSの具体設定ルール」

この役割を理解せずに全部ONすると、
本来不要な規制で自分の首を絞める設計になります。

このテンプレを知らずに「全部ON」すると

• 検知が爆発する
• 優先度が崩壊する
• 現場がCSPMを信じなくなる

CSPMは、
「顧客を理解しているかどうか」を試される設計領域です。

第3章：設計を誤るとCSPMは“敵”になる

CSPM は本来、
クラウドの治安を良くするための仕組みです。

しかし、設計を誤るとその瞬間から
組織にとって最も厄介な存在に変わります。

① 検知数が爆発する

CIS・NIST・PCI を無秩序に有効化すると、

• 同じ設定ミスを複数基準が別々に検知
• 重要度の異なるアラートが混在
• 「本当に危険なもの」が埋もれる

という状態になります。

② 優先度が崩壊する

• どれも Critical
• どれも High

この状態では、
現場は何もしないという最適解に到達します。

③ セキュリティ部門が孤立する

検知が多すぎると、必ずこう言われます。

「このツール、現場の事情をわかっていないですよね？」

ここから先は早いです。

• アラートが無視される
• ダッシュボードを誰も見なくなる
• CSPMが“形だけの仕組み”になる

④ CSPMは“ツール”ではなく“増幅器”

CSPM は、

• 正しい設計なら、
  　セキュリティレベルを何倍にも引き上げる

• 間違った設計なら、
  　混乱と不信を何倍にも増幅する

ただの増幅器です。

⑤ 最初に決めるべきだった3つの質問

CSPMを有効化する前に、
本来はこの3つに答えるべきでした。

• このシステムは、誰のどんな業務を支えているのか
• この顧客は、どんな規制を背負っているのか
• 守るべきものは「設定」か「データ」か「事業」か

この問いを飛ばした瞬間、
CSPM は味方ではなく敵になります。

4章 バージョンによる違いについて

「バージョンは最新の方が安全だから最新を選択しておく方が安心」
この考えは△、いえ、✕です。

PCI DSSを例にとってみていきます。
〜「v4だけ有効化すればいい」は本当か？〜

PCI DSS v4.0.1 は最新規格であり、
「これから新規に対応するなら v4 だけでよい」と言われることもあります。

しかし、既存環境では“v4だけ有効化”が必ずしも正解にならないケースが存在します。

v3 と v4 の思想の違い

観点	v3.2.1	v4.0.1
基本姿勢	チェックリスト型	継続的運用・リスクベース型
評価方法	年次監査中心	常時運用を前提
実装の自由度	低い	カスタムコントロールが可能
要求レベル	技術要件中心	技術＋運用＋証明責任

v4 は単なるアップデートではなく、
「監査対応型」から「日常運用型」への大転換です。

第5章：CSPMはツールではなく「運用設計」である

ここまで読んでいただいた方は、
CSPM が単なるセキュリティ製品ではないことに
すでに気づいているはずです。

セキュリティ事故は「設定ミス」では起きない

多くの事故は、

• ツールの性能不足
• 現場のスキル不足

ではなく、

どの基準を有効化するかという“運用設計の失敗”

から始まります。

CSPMは組織の判断基準をコードに変換する装置

• 何を最優先で守るのか
• どこまでをリスクとして許容するのか
• どの検知を“対応必須”とするのか

これらはすべて、日々の運用の意思決定です。

CSPM はその判断基準を、
アラートという形でクラウド環境に刻み込む仕組みです。

成功している組織の共通点

CSPM をうまく使いこなしている組織には、
必ず次の特徴があります。

項目	内容
目的	「検知数を減らす」ではなく「守る対象を明確にする」
基準	顧客・事業・規制を起点に選定
運用	セキュリティ部門だけで完結させない
連携	開発・運用と責任を共有

今日から見直すべき3つの設定

この記事を読み終えた今、
まず確認してほしいのはこの3点です。

• 有効化している基準は「顧客」に合っているか
• 本当に必要な規制だけをONにしているか
• その基準を“なぜ”選んだか説明できるか

この3つに即答できなければ、
CSPM はまだ「導入しただけ」の状態です。

最後に

CSPM はツールではありません。
組織の運用をそのまま映す鏡です。

どの基準をONにするかは、
「どんな運用を実現したいか」という
判断そのものと考えます。