PCI DSS v4.0で変わった脆弱性診断の要件－対応チェックリストと実施のポイント
- 13 分前
- 読了時間: 9分
はじめに
PCI DSS v4.0への完全移行期限（ベストプラクティス要件の必須化）は2025年3月31日に到来しました。すでにv4.0での審査が本格化している今、「脆弱性診断に関する要件はどう変わったのか？」「具体的に何を対応すべきか？」という疑問を持つ方が増えています。
結論を先にお伝えすると、PCI DSS v4.0では脆弱性診断に関連する要件が大幅に強化されています。特に、認証スキャンの必須化、中・低リスク脆弱性への対応義務化、Webアプリケーションへの継続的な保護など、v3.2.1時代よりも「やるべきこと」が明確に増えました。
本記事では、PCI DSS v4.0で変わった脆弱性診断関連の要件を整理し、実務で使えるチェックリストと合わせて解説します。
PCI DSS v4.0の全体像をおさらい
v3.2.1からの移行スケジュール
PCI DSS v4.0は2022年3月に公開されました。約8年ぶりのメジャーアップデートで、全64項目の新規要件が追加されています。
移行スケジュールは以下の通りです。
2024年3月31日：v3.2.1が引退。以降、v4.0のみが有効な基準に
2025年3月31日：ベストプラクティス要件（51項目）が必須化。v4.0完全対応が義務に
つまり、2025年4月以降に実施されるすべての審査では、v4.0のすべての要件への準拠が問われます。
v4.0の改訂の背景
今回の改訂には3つの背景があります。
1つ目は、サイバー攻撃の高度化・巧妙化です。フィッシング攻撃やランサムウェア、サプライチェーン攻撃など、v3.2.1策定時には想定されていなかった脅威が急増しています。
2つ目は、技術環境の変化です。クラウドサービスの普及、コンテナ技術やAPI経済の拡大により、カード会員データ環境（CDE）の構造が大きく変わりました。
3つ目は、柔軟性の導入です。v4.0では「カスタマイズアプローチ」が新設され、規定された方法以外でもセキュリティ目標を満たせることを証明できれば準拠と認められるようになりました。
脆弱性診断に関連する要件の変更点
要件6：安全なシステムおよびソフトウェアの開発と維持
要件6.3.2（新規）：ソフトウェアコンポーネントのインベントリ管理
特注ソフトウェアやカスタムソフトウェア、さらにそこに組み込まれたサードパーティ製コンポーネント（ライブラリ、API等）のインベントリを維持し、脆弱性管理の対象に含めることが求められるようになりました。
Apache Log4jの脆弱性のように、組み込みライブラリの脆弱性が大規模な影響を引き起こすケースが増えたことが背景にあります。SBOM（Software Bill of Marterials）の作成がガイダンスで推奨されています。
実務上のポイント：自社開発のECサイトやWebアプリケーションに使用しているフレームワーク、ライブラリ、APIの一覧を作成し、それぞれの脆弱性情報を追跡する仕組みが必要です。
要件6.4.1（変更）：Webアプリケーションの脆弱性対応
公開用Webアプリケーションの脆弱性に対して、適切な対策を講じることが従来から求められていましたが、v4.0ではこの要件がより具体化されました。
要件6.4.2（新規）：Webベース攻撃の継続的な検知・防止
公開用Webアプリケーションに対して、Webベースの攻撃を継続的に検知し、防止する自動化されたソリューション（WAF等）の導入が求められるようになりました。
実務上のポイント：WAFの導入だけでなく、WAFが「継続的に」機能していること（ルールの更新、ログの監視、誤検知のチューニング）が問われます。WAFを導入して放置している場合、この要件を満たせません。
要件11：セキュリティシステムおよびプロセスの定期的なテスト
要件11.3.1：内部脆弱性スキャン
四半期ごとの内部脆弱性スキャンの実施に加え、以下の強化がなされました。
高リスク脆弱性（CriticalおよびHigh）はすべて解決すること
中・低リスク脆弱性についても、ターゲットリスク分析を行い対応すること（新規）
大幅なシステム変更後には再スキャンを実施すること
要件11.3.2（新規）：認証スキャンの必須化
v3.2.1では非認証スキャン（外部からスキャンするだけ）でも認められていましたが、v4.0では認証スキャン（Authenticated Scan）の実施が必須化されました。
認証スキャンとは、対象システムに正規のアカウント情報を使ってログインした状態でスキャンを行う方法です。非認証スキャンでは検出できない、内部からしか見えない脆弱性も検出できるため、より包括的な脆弱性の発見が可能になります。
実務上のポイント：これまで非認証スキャンのみで対応してきた場合、認証スキャンへの切り替えが必要です。認証スキャンでは、これまで以上に多くの脆弱性が検出される可能性があり、対応工数の増加を見込んでおく必要があります。
要件11.3.2：外部脆弱性スキャン
PCI SSC認定スキャニングベンダー（ASV）による外部脆弱性スキャンを、少なくとも四半期に1回実施する要件は維持されています。加えて、決済環境に重大な変更があった場合にはそのあとにもスキャンを実施する必要があります。
要件11.4：ペネトレーションテスト
年1回以上の内部及び外部ペネトレーションテストの実施要件は維持されています。v4.0では、テストの範囲がカード会員データ環境（CDE）だけでなく、CDEに接続するシステムコンポーネントや、CDEのセキュリティに影響を与えるシステムにまで明確に拡大されています。
要件12：組織的なセキュリティポリシー
要件12.3.1（新規）：ターゲットリスク分析
定期的に実行する各PCI DSS要件（脆弱性スキャンの頻度など）について、ターゲットリスク分析を実施し、実行頻度の妥当性を文書化することが求められるようになりました。
つまり、「四半期に1回スキャンしています」と言うだけでは不十分で、「なぜ四半期に1回が適切なのか」をリスク分析に結果に基づいて説明できる必要があります。
v3.2.1→v4.0 脆弱性診断要件の変更比較
項目 | v3.2.1 | v4.0 |
内部脆弱性スキャン | 四半期ごと | 四半期ごと＋認証スキャン必須化 |
外部脆弱性スキャン（ASV） | 四半期ごと | 四半期ごと（変更なし） |
脆弱性対応の範囲 | 高リスクの脆弱性を解決 | 高リスクに加え、中・低リスクもリスク分析の上で対応 |
ペネトレーションテスト | 年1回以上 | 年1回以上+対象範囲の明確化 |
Webアプリの保護 | WAFまたはコードレビュー | 継続的な検知・防止の自動化ソリューション必須 |
ソフトウェア構成管理 | 明示的な要件なし | サードパーティコンポーネントのインベントリ管理必須 |
実行頻度の根拠 | 明示的な要件なし | ターゲットリスク分析による頻度の妥当性の文書化 |
PCI DSS v4.0 脆弱性診断 対応チェックリスト
以下のチェックリストを使って、自社の対応状況を確認してみてください。
脆弱性スキャン
□ 四半期ごとの内部脆弱性スキャンを実施しているか
□ 内部スキャンを認証スキャンで実施しているか（要件11.3.1.2）
□ ASVによる外部脆弱性スキャンを四半期ごとに実施しているか
□ 検出された高リスク脆弱性をすべて解決しているか
□ 中・低リスク脆弱性についてターゲットリスク分析を行い、対応方針を文書化しているか
□ 大幅なシステム変更後に再スキャンを実施しているか
ペネトレーションテスト
□ 年1回以上の内部ペネトレーションテストを実施しているか
□ 年1回以上の外部ペネトレーションテストを実施しているか
□ テストの範囲にCDE、接続システム、セキュリティ影響システムを含めているか
□ テスト結果に基づき、検出された脆弱性を修正しているか
Webアプリケーション保護
□ 公開用Webアプリケーションに対してWAF等の自動化されたソリューションを導入しているか
□ WAFのルールが定期的に更新されているか
□ WAFが「継続的に」攻撃を検知・防止できている状態になっているか（導入して放置していないか）
ソフトウェア管理
□ 特注/カスタムソフトウェアに含まれるサードパーティコンポーネントのインベントリを維持しているか
□ 各コンポーネントの脆弱性情報を追跡する体制があるか
リスク分析・文書化
□ 脆弱性スキャンやペネトレーションテストの実行頻度について、ターゲットリスク分析を実施し文書化しているか
□ 脆弱性管理プロセス全体（発見→評価→対応→記録）が文書化されているか
対応を効率化するためのポイント
脆弱性診断とWAF運用をセットで考える
v4.0では、脆弱性診断（要件11）とWebアプリケーション保護（要件6.4.2）がセットで強化されています。脆弱性診断で発見された問題をWAFルールに反映し、WAFで検知された攻撃パターンを次回の診断で重点的に検査するーという循環型のセキュリティ運用が理想的です。
認証スキャンへの切り替え計画を立てる
認証スキャンの必須化は、多くの組織にとって最大の変更点です。認証情報の準備、スキャン範囲の拡大、検出数の増加に伴う対応工数の見積など、計画的な移行が必要です。
ターゲットリスク分析を「形だけ」にしない
要件12.3.1のターゲットリスク分析は、「なぜこの頻度で診断を行うのか」の根拠を示すためのものです。自社の事業特性（取引量、データの種類、システム構成の変更頻度など）に基づいた本質的な分析を行い、審査員が納得できる文書を準備しましょう。
外部の専門家の活用を検討する
v4.0で求められる対応範囲は、v3.2.1と比較して大幅に広がっています。すべてを内製で対応するのは、多くの組織にとって現実的ではありません。認証スキャン、ペネトレーション鉄祖、WAF運用などは、外部の専門事業者を活用することで、品質の確保と社内リソースの最適化を両立できます。
まとめ
PCI DSS v4.0への完全移行が完了した今、脆弱性診断に求められるレベルは確実に上がっています。特に重要な変更点を改めて整理すると、認証スキャンの必須化、中・低リスク脆弱性への対応義務化、Webアプリケーション保護の自動化要件、ソフトウェアコンポーネントの管理義務、ターゲットリスク分析による頻度の根拠づけの5点が核心です。
これらの要件は、「審査のためにしかたなく対応する」のではなく、「カード会員データを実際に守るために必要な対策」として設計されています。v4.0への対応をきっかけに、自社のセキュリティ体制を根本から見直す機会として活用していただければ幸いです。
クラスメソッドセキュリティでは、PCI DSS準拠に必要な脆弱性診断・ペネトレーションテストを提供しています。認証スキャンへの切り替えや、v4.0対応のためのスコーピング相談も承ります。
[脆弱性診断サービス「Matrix Inspect」の詳細はこちら→]
[WAF運用自動化「WAF Automator」の詳細はこちら→]
