PCI DSS v4.0.1とは？リリース情報とベストプラクティス要件への対策を解説

すでに、運用を開始している必要があるPCI DSS v4.0。2025年3月31日には、より難易度の高いベストプラクティス要件※の運用開始が控えています。PCI DSS v4.0準拠を促進するクラウドサービス・運用代行サービスを提供している株式会社リンク セキュリティプラットフォーム事業部 事業部長 滝村 享嗣が、PCI DSS v4.0ベストプラクティス要件への対応策を語ります。

ベストプラクティス要件：バージョンアップによって企業に大きな負担がかかる新要件に対して、特定の期日までの猶予期間を設ける措置。期限までは対応していなくても不適合にならないが、その期日以降は正式な要件になるという考え方。

PCI DSS v4.0.1とは?

PCI DSS（Payment Card Industry Data Security Standard）はクレジットカード情報を保護するために策定された国際的な情報セキュリティ基準です。PCI DSSの各バージョンはクレジットカード会員データの安全管理について具体的な要件を定めており、企業はこれを遵守することでカード情報漏えいリスクを低減します。

PCI DSS v4.0.1は、PCI DSS v4.0の次にあたる最新版（※2024年時点）であり、2024年6月11日にPCI SSC（PCI Security Standards Council）から公開されました。v4.0.1は限定的な改訂版であり、v4.0で定められた要件そのものに新規追加や削除は行われていません。

主な目的は、PCI DSS v4.0発行後に寄せられたフィードバックや質問を受け、要件の表現やガイダンスの明確化、誤字・書式の修正などを行うことにあります。言い換えると、PCI DSS 4.0.1はv4.0の「軽微なアップデート版」であり、基準自体の基本的な方向性は維持しつつ、細部の改善が図られたものです。

PCI DSS v4.0.1の移行スケジュール

移行のスケジュールについても押さえておきましょう。PCI SSCの発表によれば、v4.0.1は公開と同時に有効となり、2024年内は従来のv4.0と並行して適用可能でした。ただしPCI DSS v4.0は2024年12月31日をもって廃止され、それ以降はv4.0.1が唯一有効なバージョンとなります。

したがって、2025年以降にPCI DSS準拠を目指す企業はv4.0.1に従う必要があります。もっとも、v4.0.1で要件が大きく変わったわけではないため、v4.0に準拠していた企業にとってv4.0.1への適応は比較的容易だと考えられます。

関連記事：PCI DSS v4.0.1の移行期限に向けて行うべき対応策を解説

PCI DSS v4.0からv4.0.1の変更概要

PCI DSS 4.0.1へのアップデート内容を概観すると、前述の通り新たな要件追加や既存要件の削除はありません。主な変更点は以下のように要約できます。

誤植・書式の修正

文書内の誤字脱字やフォーマット上の不備（例えば段落番号やヘッダーの欠落など）が修正されています。これにより文書全体の可読性が向上しました。

ガイダンスの整合性と明確化

既存の関連文書（v4.0のクイックリファレンスガイドや公開されているFAQなど）との齟齬を解消するため、標準のガイダンス記述が更新・明確化されています。

また、要件の「適用に関する注意事項（Applicability Notes）」が多数修正され、各要件が適用される範囲や条件がより明示されました。

用語の整理

ガイダンス内で定義されていた用語のうち、既に用語集に含まれているものはガイダンス側から削除し付録Gの用語集参照に一本化しました。

逆に、新たに定義が必要な用語や、従来明確な参照先が無かった用語は用語集に追加されています。これにより用語の定義が統一的に管理されています。

全体的な表現統一

基準書全体にわたり、「CDEのセキュリティに影響する」という表現を「カード会員データおよび/または機密認証データのセキュリティに影響する」に置き換える修正が行われました。

従来の「CDEに影響する」という表現では範囲がやや曖昧でしたが、具体的にカード会員データ（CHD: Cardholder Data）や機密認証データ（SAD: Sensitive Authentication Data）への影響であることを明示することで、要件の意図する範囲が明確になりました。

テスト手順の調整

一部の要件について内容が変更されたことに合わせ、審査時のテスト手順も必要に応じて更新されています。これも実質的な要件追加ではなく、変更後の要件に沿った審査プロセスを反映したものです。

以上のようにPCI DSS 4.0.1の変更は全般的な明確化とドキュメント上の改善が中心です。特にガイダンスや適用範囲の注記が見直されたことで、各組織が要件をどのように解釈し実装すべきかについての不明点が減り、PCI DSS遵守に取り組む企業にとって理解しやすい内容となっています。

PCI DSS v4.0からv4.0.1の具体的な変更点

それでは、PCI DSS v4.0からv4.0.1への具体的な変更点について、企業のセキュリティ担当者が特に注目すべきポイントを解説します。先述の通り追加・削除された新要件こそありませんが、一部要件の細かな修正によってコンプライアンス対応に影響を及ぼす可能性があります。

ここではその中でも代表的な「8.4.2」、「11.6.1」、「12.1.4」、「12.8.24」の4つの要件に注目し、旧バージョンから何が変わったのかを具体的に見ていきます。

要件8.4.2

要件8.4.2は、カード会員データ環境（CDE）へのアクセスに対する多要素認証（MFA）の要件です。v4.0では「CDEへのすべてのアクセスにMFA」と読み取れる表現でしたが、v4.0.1では適用範囲と例外が明確になりました。

結果として、現場の運用設計で判断しやすくなっています。セキュリティ担当者は、アクセス経路の棚卸しと認証方式の確認を優先してください。

変更点は次のとおりです。

「非コンソールアクセス」は、物理コンソール以外のリモート接続や間接的なアクセス経路を指します。例えばVPN経由の管理アクセスや、踏み台を介したアクセスが該当します。

一方で「フィッシング耐性のある認証」は、認証情報を盗み取る攻撃への耐性が高い方式を指し、例としてFIDO2のような公開鍵暗号ベースの方式が挙げられます。自社でパスワードレス認証を導入している場合は、追加のMFAの要否を整理し直すと運用が安定します。

要件11.6.1

要件11.6.1は、決済ページ周辺で起きる改ざんを検知し、異常を把握できる状態を維持する要件です。v4.0.1では、監視対象の範囲と、外部決済を埋め込むケースでの責任分界がより明確になりました。

監視対象を広げ過ぎると運用負荷が上がります。重要なポイントに集中し、検知から対応までの流れを整えることが現実的です。変更点の要旨は次の2つです。

「決済ページのコンテンツ全般」ではなく「セキュリティに影響する要素」に焦点を当てた点が実務上の大きな違いです。例えば、見た目だけが変わる文言変更まで対象にするとアラートが増えます。

反対に、悪意あるスクリプト挿入や重要ヘッダーの改変は優先度が高い検知対象です。外部の決済ページをiframeなどで埋め込む場合は、自社ページ側の改ざん検知と、TPSP側が管理すべき範囲を契約や運用ルールで整理すると判断がぶれにくくなります。

要件12.1.4

要件12.1.4は、情報セキュリティプログラムを管理・推進する責任者を明確にし、必要な権限と役割を与える要件です。v4.0.1では、特定の役職名を前提にした説明が見直されました。

組織ごとに体制は異なるため、肩書きよりも実態として「意思決定できる責任者がいるか」を重視する方向に整備されたと捉えると理解しやすくなります。

主な変更点は次のとおりです。

この変更により、専任のCISOがいない組織でも要件の意図に沿った体制を説明しやすくなります。例えば情報システム部門の責任者が権限を持ち、経営層がレビューと承認を担う形でも整理できます。

ただし、経営層の関与が重要である点は変わりません。責任者を決めるだけでなく、予算確保や優先順位付けができる状態を整えると、実効性のある運用につながります。

要件12.8.2

要件12.8.2は、サードパーティ・サービスプロバイダ（TPSP）との契約管理に関する要件です。カード会員データや認証データに影響する業務を委託する場合、委託先がPCI DSS要件を満たす責任を負うことを契約書で明確にする必要があります。

v4.0.1では「契約として認められない証拠」の例が追加され、契約書の扱いがより厳格になりました。

変更点は次のとおりです。

追加された例として、ポリシーステートメント、責任マトリクス、契約に含まれないその他の証拠が挙げられます。これらは有用な補足資料になり得ますが、契約書の代わりにはなりません。AOC（Attestation of Compliance）の提示やWebサイト上の宣言だけで済ませている場合は、契約書に責任範囲が明記されているか再点検が必要です。

特にクラウドや決済関連の委託が多い組織では、委託先ごとに責任分界を整理し、監査時に説明できる状態を作ると対応がスムーズになります。

ベストプラクティス要件への対応に向けたクラウドサービスの検討

まずは、PCI DSS v4.0への移行スケジュールを確認です。皆さまは、すでに2024年3月末からPCI DSS v4.0の運用を開始しているかと思います。
ただ、ベストプラクティス要件に関しては、2025年3月末までの1年間の猶予期間が設けられており、多くの事業者は、今まさにベストプラクティス要件への対応を計画や構築をスタートされている段階にあるのではないでしょうか。

リンクが提供する『PCI DSS Ready Cloudマネージドモデル』は、PCI DSS v4.0及びそのベストプラクティス要件への対応を支援するサービスです。PCI DSSに必要なセキュリティコンポーネントをクラウドで提供するコンセプトで2013年よりサービスを開始し、最新モデルが『PCI DSS Ready Cloud マネージドモデル』です。

このマネージドモデルは、AWS、Microsoft Azure、Google Cloud、オンプレミスなどあらゆる環境での利用を可能とし、準拠にかかる構築および運用の工数とコストの大幅な削減を支援します。

また、運用代行サービスもオプションとして用意しています。一つがPCI DSSの運用です。ファイアウォールのルールセットレビューやパッチ適用などを代行しています。もう一つのサービスが、システム監視、障害対応、定期運用といったシステムサポートを提供します。

運用代行サービスは、PCI DSS Ready Cloudを利用いただいているお客さま限定サービスとなっているため、PCI DSS v4.0への移行を機に、すべてをカバーできるPCI DSS Ready Cloudマネージドモデルの導入をぜひ検討いただければと思います。

AWSやMicrosoft Azure、Google Cloud、サーバーレスからオンプレミスまで対応

PCI DSS Ready Cloudマネージドモデルのサービス提供形態について、紹介したいと思います。

 AWSやMicrosoft Azure、Google Cloudなど、メガクラウドサービスを利用中のお客さまの場合から説明します。
黄色いボックスのお客さま環境に対して、青いボックスに記載されたサービスをマネージドモデルで提供しています。
左側の緑のボックスは、お客さまのリモート環境を想定しています。お客さま環境からのアクセスに対し、同じくマネージドモデルによって、操作ログの取得や多要素認証機能を提供しています。

次はサーバーレスの事例です。PCI DSSに準拠したAWSのコンテナサービスと組み合わせて利用するため、全体の構築・運用コストをさらに抑えることが可能です。

また、金融系事業者のように自社データセンターで運用しなければいけない場合でも、サービス提供は可能です。この場合は当社とお客さまのデータセンターを専用線で接続します。

お客さまの環境に合わせて、カスタマイズできるのもPCI DSS Ready Cloudマネージドモデルの特長となっています。

難易度の高いベストプラクティス要件へどのように対応するのか

難易度の高い3つのベストプラクティス要件に対して、我々がどのような・サービスを提供しているのかを説明します。

1つ目がログ管理への対応です。
PCI DSS v4.0ではログ管理の要件が厳しくなっています。要件番号「10.4.1.1」には「監査ログのレビューを行うために、自動化されたメカニズムが使用されている」と記載されています。
さらに要件番号「10.5」では「監査ログの履歴は保持され、分析に利用できる状態にする。監査ログの履歴を少なくとも12カ月間保持し、少なくとも直近の3カ月間は分析のために直ちに利用できるようにする」といった対応の必要があります。

これらの要件に対応するソリューションとして、SIEM※の導入が不可欠です。SIEMもさまざまなソリューションがリリースされていますが、「運用に手間がかかり、使いこなせない、高額だ」といった課題を伺います。その点、PCI DSS Ready CloudマネージドモデルのSIEMは要件をスムーズに実現する機能を備えています。

※SIEMとは、「Security Information and Event Management」の略。セキュリティ機器やネットワーク機器などのログを一元的に管理してリアルタイムに分析することで、セキュリティ上の脅威や問題を早期に発見するためのソリューションの一つ。

例えば、クラウドコンピューティングリソースを活用するため、大量のログ分析がスピーディーに実現でき、標準で366日間ログを保存できます。特定のキーワードやしきい値を越えたログを検知すると、自動でアラートを担当者に通知する機能も備えているなど、難易度の高い要件を満たすことが可能です。

2つ目は、WAFとオンラインスキミング対策です。
ベストプラクティス要件には、オンラインスキミングに対する対策の項目が含まれています。要件番号の「6.4.2」、「6.4.3」、「11.6.1」にWAFやオンラインスキミング対策への要件がまとまっています。

要件「6.4.2」は「一般公開されているウェブアプリケーションについては、ウェブベースの攻撃を継続的に検知・防止する自動化された技術的ソリューションを導入」と記載されており、要件を満たすWAFを準備する必要があります。

要件「6.4.3」は「消費者のブラウザに読み込まれ実行されるすべての決済ページスクリプトの管理」、そして、「11.6.1」は、「消費者のブラウザが受信したHTTPヘッダー情報と決済ページのコンテンツに対する不正な変更がなされてないかを監視」と記載されています。

ツールを購入せずに、CSPを記述すればオンラインスキミング対策は可能です。ただし、これは非常に難易度が高い。そこで、我々としてはWAFとオンラインスキミング対策をセットにした「WAF/オンラインスキミング対策サービス」をオプションとして提供しています。

リンクが提供するWAFは、マネージドルールによるサービスを提供しているので、お客さまがルールを設定する必要はありません。クラウド、オンプレといったお客さまの環境に依存することなく、サービス提供が可能です。

また、オンラインスキミング対策に関しては、決済ページなどに対し、入力フォームの監視やスクリプト監視、データ送信元のサイトの監視を提供しています。

異常を検知後、SIEMにログを連携してお客さまにアラートを送信します。またWAFの場合は、異常を検知した際、通信のブロックやレポート提供、アラートを関係者に通知する設定も可能です。

この図は、入力フォーム監視の例です。コンテンツが改ざんされてないかや不正なJavaScriptの動きがないかを検知する、スクリプト監視サービスになります。許可していない接続先への通信が発生した場合、アラートを通知します。

最後は、なりすまし、フィッシング対応です。
要件番号「5.4」に「フィッシング対策機構は、フィッシング攻撃からユーザーを保護する」必要があります。
実はPCI DSSの要件以外にも、経産省、総務省、検察庁からクレジットカード事業者などに対して、フィッシング対策が要請されており、送信ドメイン認証技術であるDMARCの導入とポリシー強化が求められています※。

※クレジットカード会社等に対するフィッシング対策の強化を要請
https://www.meti.go.jp/press/2022/02/20230201001/20230201001.html

これらの要件に対して、お客さまのメール環境がDMARC、SPF、DKIMに対応できているのかを数値化する「迷惑メールスコアリングサービス」を提供しています。

このサービスは、お客さまがメールを送信すると、メールの内容を評価・スコアリング化したレポートを提供します。
さらに、DMARCレポートの分析を簡単に行うことが可能です。DMARC認証がNGになる原因を4つのパターンに分類した「エラーパターン分析」や、自社で把握できていないIPアドレスについて分析をできる「成りすまし可能性分析」といったレポートを活用することで、ポリシーを強化するDMARCの運用を支援します。

今回はベストプラクティス要件に関するソリューションの説明をさせていただきましたが、ベストプラクティス運用開始日は、迫ってきています。お気軽に問い合わせいただければと思います。