PCI DSS v4.0 | 主な変更点とv3.2.1との差分、対応方法を解説【動画付き】

日々進化するサイバー攻撃の脅威、そしてクラウド化やリモートワークといったビジネス環境の大きな変化。こうした現代の潮流に対応するため、クレジットカード業界の国際的なセキュリティ基準である「PCI DSS」は、約8年ぶりとなるメジャーバージョンアップを果たし、「v4.0」へと進化を遂げました。

「PCI DSS v4.0とは、具体的に何が、どのように変わったのだろうか？」 「v3.2.1までの準拠状態を維持していれば、それで十分ではないのか？」 「新たに追加された要件に対して、どのような準備と対応が必要になるのだろうか？」

カード情報を扱う全ての事業者にとって、この新しい基準への対応は、もはや避けては通れない、喫緊の経営課題です。

本記事では、このPCI DSS v4.0とは一体どのような基準なのか、その目的と特徴、そして旧バージョンからの主要な変更点を、誰にでも簡単にわかりやすく解説します。

PCI DSS v4.0準拠までのタイムライン

PCI DSS v4.0は、2022年3月31日に、PCI SSC（PCI Security Standards Council）によって、正式にリリースされました。しかし、事業者が、この新しい基準に対応するための準備期間として、十分な移行期間が設けられています。

まず、旧バージョンであるPCI DSS v3.2.1は、新バージョンv4.0のリリースから2年後の、2024年3月31日をもって、その効力を失い、引退しました。したがって、現在、PCI DSSへの準拠を目指す、あるいは維持する全ての事業者は、PCI DSS v4.0を基準として、その取り組みを進める必要があります。

さらに、PCI DSS v4.0で新たに追加された要件の中には、即時の対応が求められるものと、事業者が準備期間を確保できるよう、段階的な適用が求められるものがあります。PCI DSS v4.0で「ベストプラクティス（強く推奨されるが、義務ではない）」として定義されている、64の新しい要件は、2025年3月31日までは任意とされていますが、その翌日である2025年4月1日からは、完全に「要件化（必須項目）」されます。

つまり、2025年3月末までは、いわばPCI DSS v4.0への「助走期間」です。この猶予期間の間に、自社の現状を分析し、新たな要件に対応するための、計画的な準備と実装を進めることが、全ての事業者にとって、極めて重要となります。

PCI DSS v4.0の特徴

PCI DSS v4.0には、これまでのバージョンの基本的な考え方を継承しつつ、近年のセキュリティ脅威や、IT環境の変化に対応するため、いくつかの重要な特徴があります。

その最大の特徴は、セキュリティ目標を達成するための「柔軟性」を高めた点にあります。
これまでのバージョンでは、各要件に対して、具体的な実装方法がある程度、規定されていました。しかし、PCI DSS v4.0では、新たに「カスタマイズアプローチ」という考え方が導入されました。これは、要件が目指す「目的（セキュリティインテント）」さえ達成できるのであれば、必ずしも規定通りの方法でなくても、事業者が、自社の環境に合わせて、独自に設計した、代替的なセキュリティ管理策を導入することを許容する、というものです。

もちろん、その代替策が、十分なセキュリティ強度を持つことを、客観的に証明する必要はありますが、これにより、事業者は、より自社のビジネス実態に即した、合理的で、効果的なセキュリティ対策を、構築することが可能になります。

その他にも、ゼロトラストの考え方を取り入れた、アクセス制御の強化や、フィッシング、オンラインスキミングといった、最新の脅威に対する、具体的な要件が追加されるなど、現代のセキュリティ環境に、より適合した基準へと、進化を遂げています。

PCI DSS v4.0要件の主な変更点/考え方

PCI DSS v4.0には、前回のメジャーバージョンアップ以降に登場した新技術やシステム環境変化への対応や、オンラインスキミング、フィッシングなどをはじめとする新しい攻撃手法への対応が多く盛り込まれています。
以下で、PCI DSS v4.0で主に変わった点をピックアップします。

PCI DSS v4.0では、既存の要件の明確化や、新たな脅威への対応、そして柔軟性の向上という、3つの大きな方針に基づいて、要件の変更・追加が行われました。ここでは、その主要な変更点の考え方について、解説します。

変更の方向性	ポイント	具体的な変更例（要件番号）
セキュリティの継続的な推進	セキュリティを、年一度のイベントではなく、日々の事業プロセスとして、継続的に維持することを重視。	リスク分析を、すべての要件に対して、定期的に実施することを要求（12.3.1）
柔軟性の向上と目的の明確化	「カスタマイズアプローチ」の導入により、事業者が、より柔軟なセキュリティ対策を導入可能に。	事業者が、要件の目的に合わせて、代替の管理策を定義・実装することを許容（要件全体）
セキュリティ手法の強化	多要素認証（MFA）の適用範囲拡大や、パスワード要件の強化など、既存の対策を、より堅牢なものに。	・全てのカード会員データ環境（CDE）へのアクセスに、多要素認証を義務化（8.4.2） ・パスワードの最小文字数を、12文字（システムアカウントは15文字）に増加（8.3.6）
新たな脅威への対応	フィッシングや、オンラインスキミングといった、最新のサイバー攻撃に対応するための、新規要件を追加。	・フィッシング攻撃から、ユーザーを保護するための、技術的な管理策を導入（5.4.1） ・顧客向け支払いページで実行される、スクリプトの管理を要求（6.4.3, 11.6.1）

リスク分析

PCI DSS v4.0で、最も強調されている概念の一つが、この「リスク分析」です。PCI DSS v3.2.1でも、一部の要件でリスク分析は求められていましたが、PCI DSS v4.0では、その適用範囲が、全ての要件に拡大されました。

これは、セキュリティ対策の頻度（例えば、パスワードの変更頻度や、ログのレビュー頻度など）を、事業者が、自社の環境に応じた、リスク分析の結果に基づいて、主体的に決定することを、より広く許容する、という考え方の表れです。

画一的な基準を、全ての事業者に当てはめるのではなく、事業者自身が、自らのビジネス環境に潜むリスクを、正しく評価し、そのリスクレベルに応じて、合理的で、最適なセキュリティ対策のレベルや、頻度を決定する。こうした、より成熟した、リスクベースのアプローチへの移行が、PCI DSS v4.0の大きな特徴といえるでしょう。

最近の情報漏洩の動向に基づいた新規要件の追加

PCI DSS v4.0では、近年のサイバー攻撃のトレンドを反映した、多くの新しい要件が追加されています。 例えば、Eコマースサイトを狙った、オンラインスキミング攻撃（悪意のあるスクリプトを、支払いページに埋め込み、入力されたカード情報を窃取する攻撃）の脅威が増大していることを受け、顧客のブラウザ上で実行される、全てのスクリプトの正当性を管理し、不正な変更を検知する仕組みを導入すること（要件6.4.3、11.6.1）が、新たに求められるようになりました。

また、標的型攻撃の主要な侵入経路となっている、フィッシング攻撃への対策として、具体的な技術的管理策の導入（要件5.4.1）も、新たに義務付けられています。

既に求められている対策の一層強化

既存のセキュリティ対策についても、その基準が、より高く、そして厳格なものへと強化されています。 その代表例が、多要素認証（MFA）です。これまでは、CDE（カード会員データ環境）への、リモートアクセスなどに限定されていましたが、PCI DSS v4.0では、その適用範囲が大きく拡大され、CDEへの、全てのアクセスに対して、多要素認証の使用が、義務付けられました。

これには、社内ネットワークからの、管理者によるアクセスなども含まれます。 また、パスワードの要件も強化され、最小文字数が、これまでの7文字から12文字へと、大幅に引き上げられました（システムアカウントの場合は15文字）。

こうした、基本的なアクセス制御の強化が、不正アクセスに対する、防御力を高める上で、極めて重要であると、再認識された形です。

関連記事：多要素認証とは？メリット・デメリットや具体例を詳しく解説

PCI DSS v4.0要件の変更点から考える新たな脅威と求められる対策

PCI DSS v4.0で追加・強化された要件は、現代の私たちが直面している、新たなサイバー攻撃の脅威を、色濃く反映しています。

不正サーバー証明書

Webサイトの正当性を証明する「サーバー証明書（SSL/TLS証明書）」の有効期限切れや、不正な証明書を悪用する攻撃が増えています。

これにより、ユーザーは、偽のサイトに誘導され、情報を窃取される危険にさらされます。PCI DSS v4.0では、こうした脅威に対応するため、CDEに接続する全てのシステムにおいて、証明書の有効性を、常に監視・維持することが、求められています。

フィッシングによるカード情報などの窃盗行為

特定の個人や組織を狙い、巧妙な偽メールを送ることで、認証情報（ID、パスワード）や、カード情報を盗み出す「フィッシング攻撃」は、ますます高度化、悪質化しています。

PCI DSS v4.0では、こうした、人間の心理的な隙を突く攻撃から、従業員と顧客を守るため、定期的なセキュリティ意識向上トレーニングの実施に加え、DMARCといった、具体的な技術的対策の導入（要件5.4.1）が、新たに求められるようになりました。

Log4jなどライブラリやAPIの脆弱性を悪用

現代の多くのシステムやアプリケーションは、オープンソースのライブラリや、外部のAPIを、数多く組み合わせて構築されています。しかし、2021年に発覚した「Log4j」の脆弱性のように、これらの構成要素に、深刻な脆弱性が発見されるケースが、後を絶ちません。

PCI DSS v4.0では、自社開発のソフトウェアだけでなく、そこで使用している、全てのサードパーティ製のコンポーネントを、正確に棚卸し、その脆弱性情報を、常に監視・管理することが、新たに求められています（要件6.3.2）。

不正なJavaScriptなどによるオンラインスキミング

Eコマースサイトの、カード情報を入力する支払いページに、悪意のある不正なJavaScriptを、密かに埋め込むことで、顧客が入力したカード情報を、リアルタイムで窃取する。
この「オンラインスキミング（Magecart攻撃）」の被害が、世界的に急増しています。PCI DSS v4.0では、この脅威に直接的に対応するため、支払いページで読み込まれる、全てのスクリプトの、正当性と完全性を、管理・監視する仕組み（要件6.4.3、11.6.1）が、新たに追加されました。

GitHubのリポジトリなどから盗み出したソースコード内の認証情報の悪用

アプリケーションのソースコードを管理する、GitHubなどのリポジトリが、不正アクセスを受け、そこにハードコーディング（直接記述）されていた、データベースへの接続情報や、APIの認証キーといった、機密情報が盗み出され、悪用される、というインシデントも発生しています。

PCI DSS v4.0では、こうしたリスクを低減するため、パスワードや、秘密鍵、暗号鍵といった、認証情報を、ソースコード内に、平文で保存することを、明確に禁止しています。

PCI DSS v4.0準拠に向けてのポイント

この、より高度で、複雑になったPCI DSS v4.0への準拠を、効率的に、そして確実に達成するためには、いくつかの重要なポイントがあります。

まず、第一に、「スコープ（適用範囲）の、徹底的な見直しと、最小化」です。自社のシステムの中で、本当にカード情報に触れる必要のあるコンポーネントは、どこなのか。トークン化などの技術を活用し、カード情報を、そもそも自社システムで「保持しない、処理しない、伝送しない」ようにすることで、PCI DSSの適用範囲を、劇的に縮小させることが可能です。

次に、「カスタマイズアプローチの、戦略的な活用」です。PCI DSS v4.0で新たに導入された、この柔軟なアプローチを、積極的に活用することを検討しましょう。既存の要件を、ただ文字通りに解釈して実装するのではなく、自社のビジネスの実態や、リスクレベルに合わせて、より合理的で、効果的な、独自のセキュリティ管理策を設計・導入することで、不要なコストを抑えつつ、真に価値のあるセキュリティ投資を、行うことができます。

そして、最後に、「専門家との、早期の連携」です。PCI DSS v4.0への対応は、もはや、片手間でできるような、簡単なタスクではありません。QSAや、セキュリティコンサルタントといった、専門家の知見を、できるだけ早い段階から活用し、的確なアドバイスを受けながら、計画的にプロジェクトを進めることが、結果的に、準拠達成への、一番の近道となるのです。

v4.0への対応一例：ディスク暗号化の代替手段

PCI DSS v4.0がリリースされましたが、新要件となる要件3.5.1.2ではディスク暗号化の禁止が定められました。本要件では、リムーバブル電子媒体以外のサーバ機などについては、ディスク暗号化を禁止しています。

これはv4.0への移行において非常に影響が大きい新要件といえるでしょう。ディスク暗号化によるPANの暗号化を行っている場合は、代替案について検討する必要が出てきます。
代表的な方法としては、アプリケーションデータの暗号化、DBMSによるデータの暗号化、ファイルの暗号化といった3つの方法です。それぞれについて解説します。

アプリケーションデータの暗号化

プログラムでPANの処理を行う際、暗号化するプログラムを活用した上で保存できれば問題ありません。復号する場合については、一度ファイルやDBなどに保存している暗号化済みのデータを呼び出した上でプログラムにてPANを復号し、PANを処理します。

そもそもディスク暗号化が禁止されることになったのは、万が一の事態にPANの漏えいを防ぐためです。例えば、サーバーが起動している状態でOSの管理者権限が奪われてしまえば、PANの漏えいに繋がってしまいます。
ですが、アプリケーションの暗号化に対応しておけば、仮にOSの管理者権限が奪われてしまったような場合でもPANを読み取ることができません。非常に安全性の高い方法といえます。

ただし、デメリットとして復号化・復号を行うためには、すべてでプログラムを経由しなければならない点についておさえておきましょう。例えば、企業によっては複数のサーバーを使い分けているようなケースもあるのではないでしょうか。このようなケースではプログラム同士の相性に問題がないかについてもよく確認が必要です。
また、DBMSのバッチ処理においてPANが扱えないことがあるのもデメリットといえるでしょう。

DBMSによるデータの暗号化

2つ目の代替案は、データベース管理システムであるDBMSを活用してデータの暗号化を行う方法です。DBMSとは、コンピューター上のデータベースの整理やデータの検索といったもののほか、更新や共有などが行えるソフトウェアのことをいいます。
暗号化/復号機能を持つDBMSの場合、、仮にOSの管理者権限が奪われてしまってもDBMSにログインできなければPANデータが読み取られてしまうようなことがありません。
また、暗号化した後であっても従来と同様の方法でデータにアクセスできるのもDBMSによる暗号化の大きなメリットといえるでしょう。

ただ、サーバーやパソコンのメモリ上にあるデータについては、一時期に暗号化されていない形で残ってしまいます。そのため、DBMSによるデータ暗号化で対応しようと考えているのであれば、それらのファイルについては別途セキュリティについて検討しなければなりません。

ファイルの暗号化

3つ目の代替案が、ファイルの暗号化となります。プログラムに依存することなくすべてのデータを暗号化できるのが特徴です。
ファイルの暗号化に取り組む場合は、ファイルに書き込みをしたり、読み込んだりする際に暗号化・復号できるようなプログラムを導入しましょう。万が一、OSの管理者権限を奪われてしまったときのことを考えても、ファイル自体が暗号化されていれば情報を読み取ることができなくなります。
暗号化ソフトの導入について検討する場合は、権限の制御ができるかについても確認しておきましょう。例えば、従業員に対しても復号権を与えるようなソフトを選択した場合は、データの持ち出しなどのリスクについても検討しなければなりません。また、ソフトウェアとの相性問題についても確認が必要です。
特に注意したいのが、ウイルス対策ソフトです。相性が悪いものを選択すると動作に支障をきたす恐れもあります。

PCI DSS v4.0準拠に向けてのポイント

前述したように、PCI DSS v4.0ではカスタマイズアプローチが加わりました。カスタマイズアプローチでは、従来のように要件書に定義されているテスト手順とは異なる方法であっても、セキュリティ目標が満たせていれば問題ないと判断されるものです。

なお、カスタマイズアプローチについては、すべての要件で認められるものではない点にも注意しましょう。要件によってはカスタマイズアプローチの対象外であると定められているものもあるため、そういったものについては従来と同様に要件書に定義されている形で取り組んでいく必要があります。

PCI DSS v3.2.1の有効期間については、2024年3月31日と定められています。技術的に難しい要件や、準拠するとなると企業負担が重くなる新要件は、特定の期日までの猶予期間を設ける措置であるベストプラクティス要件の対象となります。猶予期間は、2025年3月です。

First Look at PCI DSS v4.0（日本語字幕付き） 公開

PCI Security Standards Council の Youtubeチャンネル

First Look at PCI DSS v4.0（日本語字幕付き）も公開されています。

主な解説ポイント

・要件の変更: 認証、パスワード
・柔軟性の向上: ターゲットリスク分析、カスタマイズアプローチ、代替コントロール、進化するテクノロジーへの対応
・脅威への対応: フィッシングとソーシャルエンジニアリング、脅威への対応: オンラインスキミング
・継続的なプロセスとしてのセキュリティの推進
・レポーテイングの更新
・PCI DSS v4.0への移行タイムライン

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

PCI DSS v4.0のリリース後、2024年4月に、マイナーバージョンアップとして「v4.0.1」が公開されました。このアップデートは、新たな要件の追加や、既存要件の変更を伴うものではなく、主に、PCI DSS v4.0の記述に関する、誤字脱字の修正や、分かりにくい表現の明確化といった、編集上の修正が中心となっています。

例えば、特定の用語の定義が、より正確なものに修正されたり、要件の目的を説明する文章が、より理解しやすいように、リライトされたりしています。
したがって、すでにPCI DSS v4.0への対応を進めている事業者にとっては、このPCI DSS v4.0.1への変更が、技術的な対応計画に、大きな影響を与えることはありません。ただし、今後、準拠性の評価を受ける際には、この最新のv4.0.1の文書を参照することが、推奨されます。

PCI DSS v4.0.1のベストプラティクス要件への対策

PCI DSS v4.0（およびv4.0.1）で、2025年3月31日までは「ベストプラクティス（推奨）」とされ、それ以降に「要件化（必須）」される、64の新しい要件。これらの要件に、どのように対応していくかは、多くの事業者にとって、直近の大きな課題です。

これらの新要件は、多要素認証（MFA）の適用範囲の拡大や、パスワード要件の強化、あるいは、フィッシング対策や、オンラインスキミング対策といった、より高度で、具体的な技術的・組織的対策を、幅広く含んでいます。
これらの要件に、一つひとつ対応していくためには、まず、自社の現状との「ギャップ分析」を、正確に行い、その上で、計画的な実装ロードマップを、策定する必要があります。

PCI DSS Ready Cloudについて

PCI DSS準拠を目指す上で、最も大きなハードルとなるのが、堅牢なセキュリティ要件を満たす、サーバーインフラの構築と、その24時間365日の運用管理です。 この課題に対する、最も効果的で、そして現実的なソリューションとして、私たち株式会社リンクが提供しているのが「PCI DSS Ready Cloud」です。

「PCI DSS Ready Cloud」は、その名の通り、PCI DSSへの準拠を前提として、あらかじめ設計・構築された、クラウド型のホスティングプラットフォームです。 ファイアウォールや、WAF（Web Application Firewall）、ファイル改ざん検知、統合ログ管理といった、PCI DSSが要求する、12要件の大部分に対応した、サーバー環境と、運用監視サービスを、オールインワンで提供します。
お客様は、自社で高価なセキュリティ機器を購入したり、サーバーを構築したり、あるいは専門のエンジニアを雇用したりすることなく、月額のサービス利用料だけで、PCI DSSに準拠した、安全なインフラを、すぐに利用開始することができます。 インフラ部分を、私たちプロフェッショナルにアウトソースすることで、お客様は、本来のビジネスである、アプリケーションの開発や、サービスの提供に、全ての経営リソースを集中させることが可能になります。

PCI DSS準拠 事例







PCI DSS Ready Cloudでは、PCI DSS v4.0への効率的な移行支援及び準拠を促進するクラウドサービスを提供しています。
是非一度、ご相談ください。
PCI DSS準拠を促進するクラウドサービスならPCI DSS Ready Cloud

PCI DSSへの準拠はすべての事業者の義務である

今回は、クレジットカード社会の安全を支える、国際的なセキュリティ基準「PCI DSS」について、その目的から、具体的な要件、そして準拠を達成するためのプロセスまで、網羅的に解説しました。

デジタル化が加速し、決済手段が多様化する中で、お客様の情報を、いかに安全に、そして誠実に扱うか、という企業の姿勢は、これまで以上に、厳しく問われるようになっています。

PCI DSSへの準拠は、もはや、一部の大企業だけが取り組むべき、特別な課題ではありません。それは、規模の大小に関わらず、カード決済を取り扱う、全ての事業者に課せられた、社会的責務であり、そして、お客様からの信頼を勝ち得るための、必須条件なのです。 この記事が、皆様の、安全で、そして持続可能なビジネスの発展に、少しでも貢献できれば幸いです。

■ PCI DSS の構築、維持・運用にかかるコストと工数を削減する
■ AWSでの開発事業者や外部ベンダー/事業者との専用線接続がない場合に最適
■ 国内トップクラスのPCI DSS専門のコンサルタント集団によるPCI DSS準拠支援サービス