本執筆は
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 対応を成立させるには
技術と運用を同時に設計する覚悟が不可欠です。