Breadcrumb navigation
PCI DSS v4.0.1の解説<第1回>
セキュリティコラム2024年11月15日
2024年11月現在の状況
2024年6月にPCI DSS v4.0.1がリリースされました。
続いて、2024年8月にPCI DSS 4.0.1のROCテンプレートがリリースされました。
PCI DSS v4.0は2024年12月31日に廃止され、以降はv4.0.1が有効なバージョンとなることがアナウンスされています。
v4.0.1はPCI SSCにより「限定的な改訂であり、追加または削除された要件はない」と声明されていますが、事業体によっては影響がありうる変更もありますし、「適用に関する注意事項」が数多く改訂されており、要件への対応策に影響を及ぼす場合もありますので、無視することはできません。
本コラムでは、2024年11月11日時点のPCI DSS v4.01改定内容の概略をお伝えします。
NECセキュリティはPCI SSCによる認定を受けたQSA企業(注1)であり、お客様のPCI DSS準拠審査サービスを提供しています。また、PCI DSS準拠のための総合的なコンサルティングサービスも提供しています。本コラムがお客様ならびにPCI DSS関連企業の助けとなれば幸いです。
- 注1:PCI DSS 要件を遵守していることを検証するための資格を有する企業
目次
PCI DSS v4.0.1の概要
バージョン番号から類推できるように、PCI DSS v4.0.1で新たに追加された要件や大幅に変更された要件は存在しません。
PCI SSCはバージョンアップの際の変更タイプを以下の3つに分類していますが、今回のバージョンアップでは、以下の①は存在せず、②が大半です。
- ①進化する要件
- ②明確化またはガイダンス
- ③構造またはフォーマット
全体的な改訂項目
全体的には「適用性の注記 Applicability Notes」を修正することにより要件の内容を明確化した内容が目につきます。次項でNECセキュリティが注目している改訂について解説します。
個別の改訂項目
以下は、今回目立った改訂があった要件となります。
要件8.4.2
今回の改定で最も目立つ改訂は本要件にあると考えられます。v4.0における目玉要件であるカード会員データ環境(以下、CDE)への全てのアクセスに対する多要素認証の採用が、「コンソール以外のアクセス」時に限定されることが明確化されました。また、FIDO2(注2)のような「フィッシングに強い認証要素でのみ認証されるユーザアカウント」がMFAの対象外となることも追記されました。
- 注2:パスワードレスを可能にする技術規格
v4.0 | v4.0.1 | |
---|---|---|
定義されたアプローチ | 8.4.2 カード会員データ環境(CDE)へのすべてのアクセスにMFAが実装されている。 | 8.4.2 カード会員データ環境(CDE)へのコンソール以外のすべてのアクセスにMFAが実装されている。 |
適用性の注記 | この要件は、以下のものには適用されない。 • 自動化された機能を実行するアプリケーションまたはシステムアカウント。 • 1回の取引を促進するために一度に1つのカード番号にのみアクセスできるPOS端末のユーザアカウント(POS端末のレジ係が使用するIDなど)。 |
この要件は、以下のものには適用されない。 •自動化された機能を実行するアプリケーションまたはシステムアカウント。 •1回の取引を促進するために一度に1つのカード番号にのみアクセスできるPOS端末のユーザアカウント。 •フィッシングに強い認証要素でのみ認証されるユーザー アカウント。 |
用語集 | なし | フィッシング耐性認証: ユーザーが認証しようとしている正当なシステムではないパーティへの認証シークレットの開示と使用を防止するように設計された認証(たとえば、中間者(ITM)攻撃や偽装攻撃など)。フィッシングに強いシステムは、多くの場合、コアセキュリティ制御として非対称暗号化を実装します。 パスワードやワンタイムパスワード(OTP)などの知識ベースまたは時間制限のある要素のみに依存するシステムは、フィッシングに強いとは見なされず、SMSやマジックリンクもそうではありません。フィッシングに強い認証の例としては、FIDO2があります。 |
要件11.6.1
不正変更の警告対象が、「セキュリティに影響を与える」HTTPヘッダーと決済ページ(注3)スクリプトコンテンツであることが明確化されました。
また、適用性の注記の追加内容において、埋め込み決済ページを使用する場合には埋め込まれたものはサードパーティサービスプロバイダ(TPSP)の責任である旨追記されています。非保持化の進展もあり、多くの事業体でマルチペイメント事業者の利用が進んでいますが、そうした場合の責任範囲が明確になりました。
- 注3:"決済ページ"という日本語からはオーソリゼーションが行われるページであるように読めますが、英語原文では"Payment Page"となっていることから、決済に関連するウェブページは広範に含まれるものと考えています
v4.0 | v4.0.1 | |
---|---|---|
定義されたアプローチ | 11.6.1 変更・改ざん検知のメカニズムは、以下のように展開されています。 • 消費者ブラウザが受信した HTTP ヘッダーと決済ページのコンテンツに対する不正な変更(侵害の指標、変更、追加、および削除を含む)を担当者に警告すること。 (後略) |
11.6.1 変更・改ざん検知のメカニズムは、以下のように展開されています。 •消費者ブラウザが受信したセキュリティに影響を与えるHTTP ヘッダーと決済ページのスクリプトコンテンツに対する不正な変更(侵害の指標、変更、追加、および削除を含む)を担当者に警告すること。 |
適用性の注記 | なし | この要件は、TPSP/決済処理業者の埋め込み決済ページ/フォーム(1つ以上のiframe(注4)など)を含むウェブページを持つ事業体にも適用されます。 この要件は、TPSP/支払処理業者の埋め込み支払ページ/フォーム(たとえば、1つ以上のiframe)内のスクリプトの事業体には適用されず、事業体のウェブページにTPSP/支払処理業者の支払ページ/フォームが含まれています。 TPSP/支払処理業者の埋め込まれた支払ページ/フォームのスクリプトは、TPSP/支払処理業者がこの要件に従って管理する責任があります。 |
- 注4:ウェブサイト内に別のウェブサイトを埋め込む手法
要件12.1.4
目的欄で「十分な権限と責任を持つ者」の例として挙げられていたCISOやCSOの記載が削除された代わりに、グッドプラクティスに「エグゼクティブ管理職」についての記載が追記されました。
事業体によってPCI DSS推進体制は多様であり、組織構成も千差万別です。経営陣を巻き込んでのセキュリティ体制は確かにグッドプラクティスではあるものの、それ自体が要件ではないことが明確化されました。
v4.0 | v4.0.1 | |
---|---|---|
目的 | 十分な権限と責任を持つ者が、組織の情報セキュリティプログラムを積極的に管理し、推進するためには、組織内の幹部レベルで情報セキュリティの説明責任と責任を割り当てる必要があります。 この役割を担う一般的な経営幹部には、最高情報セキュリティ責任者(CISO)や最高セキュリティ責任者(CSO:この要件を満たすには、CSOの役割が情報セキュリティの責任者である必要があります)などがあります。これらの役職は、多くの場合、経営陣の最上位に位置し、最高経営責任者(CEO)または取締役会の直属の部下であるCレベルの役職となります。 |
十分な権限と責任を持つ者が、組織の情報セキュリティプログラムを積極的に管理し、推進するためには、組織内の幹部レベルで情報セキュリティの説明責任と責任を割り当てる必要があります。 |
グッドプラクティス | また、事業者は、重要なセキュリティ活動において潜在的なギャップを回避するために、これらの主要人物の移行計画および/または後継者計画を検討すべきです。 | このようなエグゼクティブ管理職は、多くの場合、経営陣の最上位レベルに位置し、最高経営責任者(CEO)または取締役会に報告する最高経営責任者レベル(C-レベル)に属します。このような幹部管理職に必要な情報セキュリティの知識は、実務経験、学歴、及び/又は関連する専門資格によって示すことができる。効果的なセキュリティプログラムの実施について保証を提供し、適切な技術専門家を確実に採用できることが期待されます。 また、事業者は、重要なセキュリティ活動において潜在的なギャップを回避するために、これらの経営幹部の移行計画および/または後継者計画を検討すべきです。 |
要件12.8.2
契約書に含まれないものとして、従来のAOCおよび企業ウェブサイトでの宣言に加え、「ポリシーステートメント、責任マトリックス、または書面による契約に含まれていないその他の証拠」が追加され、契約書の意味が狭まりました。これらの証拠で審査または自己問診を実施していた場合は証拠の差し替えが必要になる場合があります。
v4.0 | v4.0.1 | |
---|---|---|
適用性の注記 | (前略) TPSPがPCI DSS要件を満たしている証拠(たとえば、PCI DSSコンプライアンスに関する証明書(AOC)や企業の ウェブサイト上の宣言)は、この要件で指定されている書面による契約書と同じものではありません。 |
(前略) TPSPの書面による承認は、TPSPが顧客に代わって保存、処理、または送信する可能性のあるアカウントデータのセキュリティ、またはTPSPが顧客のカード会員データおよび/または機密性の高い認証データのセキュリティに影響を与える可能性がある範囲について、TPSPが責任を負うことを明記する確認です。 TPSP が PCI DSS 要件を満たしている証拠(たとえば、PCI DSSコンプライアンスに関する証明書(AOC)や企業の ウェブサイト上の宣言)は、この要件で指定されている書面による承認と同じものではありません。たとえば、PCI DSS Attestation of Compliance(AOC)、企業のウェブサイトでの宣言、ポリシーステートメント、責任マトリックス、または書面による契約に含まれていないその他の証拠は、書面による承認ではありません。 |
2024年のアクションアイテム
2025年1月1日からはv4.0.1による自己問診が必要になりますので、かかる事業体においてはv4.0.1のSAQ(自己問診表)を確認していただく必要があります。
おわりに
今回は目立った改訂部分について記載しました。次回はその他の要件も含めて解説します。
関連項目
- [サービス]
執筆者プロフィール
佐々木 教等(ささき のりとも)
NECセキュリティ セキュリティコンサルティングユニット
PCI DSS準拠支援および審査、NIST準拠支援業務に従事。
PCI DSS QSA、CISSP、CISA、システム監査技術者、ITサービスマネージャを保持。