本執筆は
AWS Security Hub CSPM 有効化設計の教科書 CIS / NIST / PCI をどう選ぶか
の補足資料です

PCI DSS は、CIS や NIST と並べて語られがちですが、
位置づけはまったく別物です。

これは“ベストプラクティス”ではありません。

カード情報を扱うなら、守らなければ事業が止まる“業界ルール”です。

また、PCI DSSの資料ダウンロードが出来なかったため今回はインターネット上で公開されている情報を拾った記事となっています。

1. PCI DSSは“ベストプラクティス”ではない

PCI DSS は、

クレジットカード番号
有効期限
セキュリティコード

といったカード会員データを保護するための強制基準です。

守らなければ、

カード会社との契約停止
取引停止
事業インパクト

という、技術ではなくビジネス上の致命傷に直結します。

2. v3 と v4 の何が変わったのか

〜「v4だけ有効化すればいい」は本当か？〜

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

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

v3 と v4 の思想の違い

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

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

v4だけで“自動判定しきるのは難しい？

v4 では、

要件の表現が抽象化
「組織のリスク評価に基づき適切な管理を実施すること」

という文言が多くなり、
技術設定だけでは“合否を機械的に判断しにくく”なっています。

一方 v3 は、

Security Group はこう設定する
ログはこの条件を満たす

といった、CSPMと相性の良い具体的ルールが多い。

つまり

v3 = 設定の健全性を機械でチェックしやすい
v4 = 運用の成熟度を人が説明する必要がある

という構造です。

v3 を併用する価値が残るケース

以下のような環境では、
v3 をベースラインとして残す意義があります。

既に v3 ベースで長年運用している
監査証跡が v3 項目単位で整備されている
CSPM による機械検知を重視したい

この場合、

v3 = 技術的ベースライン
v4 = 将来の運用モデル

という二層構造で考える方が現実的です。

結論：v4はゴール、v3は足場

新規環境
　→ v4 を中心に設計
既存環境・CSPM重視
　→ v3 をベースに v4 へ段階移行

PCI DSS v4 は最終到達点であり、
v3 を“捨てるべき過去の規格”と考えると、
運用が破綻する可能性があります。。

3. PCIがCSPMにもたらす運用インパクト

PCI を有効化すると、CSPM は一気に厳しくなります。

暗号化されていないストレージ
不要に公開されているポート
監査証跡が残らない構成

これらは即「違反リスク」として検知されます。

PCI は、
CSPM を「アドバイスツール」から
「契約を守るための仕組み」へ変化します。

4. PCIを入れるときに絶対に決めるべきこと

PCI 対応で最初にやるべきことは、
どこまでがカード会員データ環境（CDE）かを定義することです。

すべてのAWSアカウントか
一部のVPCだけか
特定のシステムだけか

これを曖昧にしたまま PCI を有効化すると、
本来不要な領域まで監査対象になり、運用が破綻する可能性があります。

5. PCI対応が必要な顧客の見分け方

以下のどれかに当てはまれば、
PCI DSS は“必須”です。

Webアプリでカード番号を入力させている
決済代行サービスと直接API連携している
カード情報を一時的でも自システムで保持している

逆に、決済画面を完全に外部サービスへリダイレクトしている場合は、
PCI 対象範囲を大きく縮小できる可能性があります。

6. PCI DSSの12要件

画像から見えてくる、PCI DSSの本質

この図が示しているとおり、
PCI DSS の 12 要件は次の6つのカテゴリに整理できます。

安全なネットワークの構築・維持
カード会員データの保護
脆弱性を管理するプログラムの整備
強固なアクセス管理手法の導入
定期的なネットワークの監視およびテスト
情報セキュリティポリシーの整備

この分類を意識すると、
PCI が「技術ルールの集合」ではないことが一気に見えてきます。

CSPMが担えるのは、この中のどこまでか

CSPM が直接カバーできるのは、主に以下の領域です。

分類	CSPMでのカバー範囲
安全なネットワークの構築・維持	Security Group / NACL / 公開設定など
カード会員データの保護	ストレージ暗号化 / 公開設定の検知
強固なアクセス管理手法の導入	IAM / MFA / 過剰権限の検知

一方で、次のカテゴリは
CSPM単体では成立しません。

脆弱性を管理するプログラムの整備
定期的なネットワークの監視およびテスト
情報セキュリティポリシーの整備

PCIは「設定基準」ではなく「運用モデル」

PCI DSS の特徴は、
日々の運用が機能しているかを要求している点です。

脆弱性は定期的に評価されているか
不審な通信は検知・調査されているか
その結果はポリシーとして文書化されているか

これらは CSPM のチェックボックスを
ON にするだけでは決して満たせません。

PCIを有効化する前に決めるべき3つのこと

PCI を CSPM に適用する前に、
最低限、以下を明確にする必要があります。

カード会員データ環境（CDE）はどこか
その範囲を誰が管理するのか
検知されたアラートに誰が責任を持つのか

この3点を定義せずに PCI を有効化すると、
PCI は守る仕組みではなく、疲弊を生む仕組みになります。

まとめ

この6分類が示しているのは、

PCI DSS は
「設定 × 監視 × 組織運用」すべてを要求する規格

だという事実です。

CSPM はその一部を支える強力な手段ですが、
PCI 対応を成立させるには
技術と運用を同時に設計する覚悟が不可欠です。