今回登場する
CIS,NIST,PCIの参考記事は以下の通りです。
今回のアップデートに伴い新規執筆しました。
CIS：AWSで最初に有効化すべきCSPM基準はこれだけ CIS AWS Foundations入門
NIST：NISTは設定基準ではない
PCI：「うちはカードを扱っていない」は危険 PCI DSSとCSPMのリアル
第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項目が混入 |
| 業務と無関係な規制の大量指摘 | PCI DSS が非決済システムにも適用 |
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すると、
本来不要な規制で自分の首を絞める設計になります。
第3章：顧客タイプ別 有効化テンプレート集
ここからが本記事のいちばん実務で使える部分です。
CSPM は「設定」ではなく「設計」です。
顧客の性質が違えば、有効化すべき基準はまったく変わります。
あくまで、以下は筆者が考える一例のため各企業ごとに要件等をお願いします。
① スタートアップ / 一般的なSaaS企業
| 項目 | 設定 |
|---|---|
| CIS AWS Foundations Benchmark v5.0.0 | 有効 |
| NIST 800-53 Rev5 | 無効 |
| NIST 800-171 Rev2 | 無効 |
| PCI DSS v4.0.1 | 無効 |
理由：
まずは AWSの基本セキュリティレベルを担保することが最優先。
この段階で NIST や PCI を入れると、検知量が増えすぎて運用が破綻します。
② 国内SI / ISMSを重視するエンタープライズ企業
| 項目 | 設定 |
|---|---|
| CIS AWS Foundations Benchmark v5.0.0 | 有効 |
| NIST 800-53 Rev5 | 有効 |
| NIST 800-171 Rev2 | 無効 |
| PCI DSS v4.0.1 | 無効 |
理由：
全社統制・ガバナンス観点が必要なため、
CIS に加えて NIST 800-53 を設計軸として使う。
③ 官公庁 / 防衛産業 / 重要インフラ
| 項目 | 設定 |
|---|---|
| CIS AWS Foundations Benchmark v5.0.0 | 有効 |
| NIST 800-53 Rev5 | 有効 |
| NIST 800-171 Rev2 | 有効 |
| PCI DSS v4.0.1 | 無効 |
理由：
CUI（重要非公開情報）を扱う可能性があるため、
800-171 が必須級になるケースが多い。
④ ECサイト / 決済基盤
| 項目 | 設定 |
|---|---|
| CIS AWS Foundations Benchmark v5.0.0 | 有効 |
| NIST 800-53 Rev5 | 無効 |
| NIST 800-171 Rev2 | 無効 |
| PCI DSS v4.0.1 | 有効 |
理由：
カード番号を扱う以上、
PCI DSS は「できれば」ではなく絶対条件。
⑤ 金融機関 / 大規模エンタープライズ
| 項目 | 設定 |
|---|---|
| CIS AWS Foundations Benchmark v5.0.0 | 有効 |
| NIST 800-53 Rev5 | 有効 |
| NIST 800-171 Rev2 | 無効 |
| PCI DSS v4.0.1 | 有効 |
理由：
ガバナンス・監査・決済のすべてを考慮する必要があり、
最も重たい組み合わせになる。
まとめ：顧客タイプ別 有効化マトリクス
| 顧客タイプ | CIS v5.0.0 | NIST 800-53 Rev5 | NIST 800-171 Rev2 | PCI DSS v4.0.1 |
|---|---|---|---|---|
| ① スタートアップ / 一般SaaS | 有効 | 無効 | 無効 | 無効 |
| ② 国内SI / ISMS重視企業 | 有効 | 有効 | 無効 | 無効 |
| ③ 官公庁 / 防衛 / 重要インフラ | 有効 | 有効 | 有効 | 無効 |
| ④ EC / 決済基盤 | 有効 | 無効 | 無効 | 有効 |
| ⑤ 金融機関 / 大規模エンタープライズ | 有効 | 有効 | 無効 | 有効 |
このテンプレを知らずに「全部ON」すると
- 検知が爆発する
- 優先度が崩壊する
- 現場がCSPMを信じなくなる
CSPMは、
「顧客を理解しているかどうか」を試される設計領域です。
第4章：設計を誤るとCSPMは“敵”になる
CSPM は本来、
クラウドの治安を良くするための仕組みです。
しかし、設計を誤るとその瞬間から
組織にとって最も厄介な存在に変わります。
① 検知数が爆発する
CIS・NIST・PCI を無秩序に有効化すると、
- 同じ設定ミスを複数基準が別々に検知
- 重要度の異なるアラートが混在
- 「本当に危険なもの」が埋もれる
という状態になります。
② 優先度が崩壊する
- どれも Critical
- どれも High
この状態では、
現場は“何もしない”という最適解に到達します。
③ セキュリティ部門が孤立する
検知が多すぎると、必ずこう言われます。
「このツール、現場の事情をわかっていないですよね？」
ここから先は早いです。
- アラートが無視される
- ダッシュボードを誰も見なくなる
- CSPMが“形だけの仕組み”になる
④ CSPMは“ツール”ではなく“増幅器”
CSPM は、
-
正しい設計なら、
セキュリティレベルを何倍にも引き上げる -
間違った設計なら、
混乱と不信を何倍にも増幅する
ただの増幅器です。
⑤ 最初に決めるべきだった3つの質問
CSPMを有効化する前に、
本来はこの3つに答えるべきでした。
- このシステムは、誰のどんな業務を支えているのか
- この顧客は、どんな規制を背負っているのか
- 守るべきものは「設定」か「データ」か「事業」か
この問いを飛ばした瞬間、
CSPM は味方ではなく敵になります。
第5章：CSPMはツールではなく「運用設計」である
ここまで読んでいただいた方は、
CSPM が単なるセキュリティ製品ではないことに
すでに気づいているはずです。
セキュリティ事故は「設定ミス」では起きない
多くの事故は、
- ツールの性能不足
- 現場のスキル不足
ではなく、
どの基準を有効化するかという“運用設計の失敗”
から始まります。
CSPMは組織の判断基準をコードに変換する装置
- 何を最優先で守るのか
- どこまでをリスクとして許容するのか
- どの検知を“対応必須”とするのか
これらはすべて、日々の運用の意思決定です。
CSPM はその判断基準を、
アラートという形でクラウド環境に刻み込む仕組みです。
成功している組織の共通点
CSPM をうまく使いこなしている組織には、
必ず次の特徴があります。
| 項目 | 内容 |
|---|---|
| 目的 | 「検知数を減らす」ではなく「守る対象を明確にする」 |
| 基準 | 顧客・事業・規制を起点に選定 |
| 運用 | セキュリティ部門だけで完結させない |
| 連携 | 開発・運用と責任を共有 |
今日から見直すべき3つの設定
この記事を読み終えた今、
まず確認してほしいのはこの3点です。
- 有効化している基準は「顧客」に合っているか
- 本当に必要な規制だけをONにしているか
- その基準を“なぜ”選んだか説明できるか
この3つに即答できなければ、
CSPM はまだ「導入しただけ」の状態です。
最後に
CSPM はツールではありません。
組織の運用をそのまま映す鏡です。
どの基準をONにするかは、
「どんな運用を実現したいか」という
判断そのものと考えます。