EN

NRIセキュア ブログ

PCI DSS v4.0リリース情報|その特徴とv3.2.1との差分、対応方針について解説

目次

     blogtop

     

    クレジットカード会員情報の保護を目的とした国際統一基準であるPCI DSSに関して、新しいメジャーバージョンのPCI DSS v4.02022年3月にリリースされた。PCI DSS v3.0201311月リリース)から約8年ぶりとなるメジャーバージョンアップである。

     

    これまでのPCI DSSの軸となる12区分からなる要件を踏襲しつつも、これまでのベースラインの考え方に加えリスクベースの考え方も追加された点や、クラウドやマルチテナント等への昨今のシステム環境変化に対応した点が主なアップデートとなっている。

     

    本稿では、PCI DSS v4.0準拠までのタイムラインや、主な変更要件、またそれに対する対応方針について解説する。

     

    新規CTA

     

    PCI DSS v4.0準拠までのタイムラインについて

    PCI DSSを発行している、PCI SSCからは以下のタイムラインがアナウンスされている[1]。これによると、現行のPCI DSS v3.2.1の終了が2024年3月31日と記されており、PCI DSS準拠対象の事業体にとってこの期限以降はPCI DSS v4.0での審査及び準拠が必要となる。

     

    PCI DSS v3.2.1からv4.0への移行においては、システム改修や運用変更が必要なケースも想定される。従って、今年(2022年)から来年(2023年)にかけて、各事業体においてはまずPCI DSS v3.2.1とv4.0との要件差分の洗い出し、対応状況をご確認いただいた上で、計画的に運用変更やシステム改修等の移行対応を推進いただくことをお勧めする。

    fig01

    出典:PCI SSC『Updated PCI DSS v4.0 Timeline』

     

    PCI DSS v4.0の特徴

     PCI DSS v4.0の主な特徴としては以下3点が挙げられる。

    • ①リスクベースの考え方の取り込み
    • ②昨今のクレジットカード情報漏洩の傾向を踏まえた新要件の追加
    • ③既存要件で求められる対策の更なる強化

    上記については、昨年末(2021年12月28日)発行のNRIセキュアブログ[2]にて紹介しており、大きな方針変更はないため、各方針の概要はそちらをご参照いただきたい。

     

    本稿では今回正式にリリースされたPCI DSSv4.0にて確認できた、より詳細な要件ごとのポイントについて次章より解説していく。

    PCI DSS v4.0要件の主な変更点

    PCI DSS v4.0の新しく追加された要件や変更された要件の中で、システムの改修を伴うものや対応負荷が大きいと考えられるものを弊社観点でピックアップして解説する。以下の表では該当する要件の概要と、準拠するにあたってのポイントについて重点的に説明する。

     

    変更の概要

    変更のポイント

    準拠する上でのポイント

    【要件1】ー

    大きな差分無し。

    【要件2】ー

    大きな差分無し。

    【要件3】

    要件の対象が「カード会員データ」から「アカウントデータ」となり、機密認証データの保存に関しても言及されるようになった。そのためオーソリ完了までの一時的な保存であっても暗号化が必須となった。

    本来保存が禁止されている事業体から機密認証データの漏洩事故が発生していることを踏まえ、要件が厳密化されたと想定される。

    これまでカード会員データと同様に暗号化する必要があるため、システム改修が必要となる。また、システム改修にあわせて機密認証データの保存に関して文書化が必要となる。

    【要件4】ー

    大きな差分無し。

    【要件5.4】

    フィッシング攻撃を検出・防御するためのプロセスと自動化されたメカニズムを実装することが求められた。

    IPAが公開している「情報セキュリティ10大脅威」でも昨今上位にランキングしている通り、フィッシングによる情報詐取事案が多発していることを踏まえ、要件が新規追加されたと想定される。

    対策としてメールサーバや端末にフィッシング攻撃対策機能を備えたソリューションを導入することが想定される。なお、昨今ではウイルス対策ソフトにフィッシング攻撃対策機能が搭載されている製品もあるため、それらを活用することで対応コストを下げられる可能性がある。

     

    対策ソリューションの例:

    Menlo Security

    Webサイトを閲覧する際に独自開発のSaaSプラットフォームを経由することでWeb分離・無害化し、Web経由のあらゆる攻撃に対策可能。

     

    Cofense

    フィルタをすり抜け受信した攻撃メールに対して気付いた従業員が報告し、分析・分離する。

    【要件6.4.2】

    一般公開しているWebアプリケーションにはWAFを導入する。

    v3.2.1ではWebアプリケーションの脆弱性診断を実施していた場合WAF導入は必須ではなかったが、v4.0ではWAF導入が必須となった。

    アプライアンス型のWAFは事業体の環境に対するカスタマイズ性が優れている一方で導入コストや運用負荷が大きいため、事業体の規模や環境によってはクラウド型WAFの導入も検討する必要がある。

     

    対策ソリューションの例:

    WAF管理サービス

    NRIセキュア設立時から提供している24時間365日監視、独自の洗練されたシグネチャを活用したWAF管理サービス。AWS・Microsoft Azure
    対応も可能。

    【要件6.4.3】

    消費者のブラウザに読み込まれ、実行されるすべての決済ページスクリプトについて以下を管理する。

    ・認可プロセス

    ・整合性チェック

    ・スクリプトのインベントリ

    昨今、決済ページのスクリプトが改ざんされることによるカード情報の漏洩が多発していることを踏まえ、決済ページの改ざんを防ぐための要件が新規追加されたと想定される。

    改ざん検知の実装はv3.2.1でも求められていたが、その対象に決済ページのスクリプトが含まれていない場合は追加対応が必要となる。

     

    対策ソリューションの例:

    Deep Security管理サービス

    ファイルやディレクトリ、レジストリ等を監視し、不正な変更が発生した場合いち早く検知する。IDS/IPS・アンチウイルス・FW等の機能も備えるため、他の要件と合わせて対策頂くことができる。

    【要件7】ー

    大きな差分無し。

    【要件8.3.6】

    ユーザアカウントのパスワードは以下の複雑さを最低限満たす。

    ・12文字以上の長さ

    ・数字と英字の両方を含む。

     

    【要件8.6.3】

    アプリケーションやシステム内で使われるアカウントのパスワードは変更する頻度に応じて十分に複雑に構成する。

    v3.2.1ではアプリケーションやシステム内で使われるアカウントのパスワードについて言及されていなかったが、v4.0では頻度に応じた複雑性を求めるようになった。なお、その頻度については要件12.3.1のリスク分析に基づいて決定する必要がある。

    「十分に複雑」についてはPCI SSCからアナウンスされているグッドプラクティスに従うと、最低年に1回の頻度でパスワードを変更する場合、大文字、小文字、数字、特殊文字を含む15文字以上とすることが求められている。

    【要件8.4.2】

    カード会員データ環境(CDE)への全てのアクセスに多要素認証を実装する。

    v3.2.1まで多要素認証の実装は非コンソールアクセスの管理者やリモートアクセスに限定されていたが、v4.0では社内ネットワークを通じてシステムにアクセスしているような業務担当者であっても多要素認証が必要となる。

    自社環境や規模を踏まえ、多要素認証の導入をサポートする製品の活用を検討することを推奨する。

    【要件9】ー

    大きな差分無し。

    【要件10.4.1.1】

    監査ログのレビューには、自動化されたメカニズムを使用する。

    大量のログを確認する際、不正アクセスを見落とすことがないように自動化が求められたと想定される。

    SIEMやログ解析ツールを導入し、確認が必要なログイベントを抽出するといった対応が想定される。

     

    対策ソリューションの例:

    Access Check

    本番環境へのアクセス制御を行い、そのログを一元管理する。日次レポートを監査担当へ送付することができ、承認のないアクセスやキーワード検知等の結果確認を自動化して実施することができる。また、本番サーバの権限管理、ID/パスワード管理も可能であるため要件7・8と合わせて対応可能。

    【要件11.3.1.2】

    内部脆弱性スキャンにおいて、認証スキャンを実施する。

    新たに認証スキャンの実施が求められた。認証情報を用いてスキャンを行うことで、非認証スキャンに比べてより多くの脆弱性を検出可能となる場合が想定される。

    認証スキャンではこれまでの脆弱性スキャンに比べて多くの脆弱性が検出される可能性が高い。そのため、その後のシステム対応期間を考慮し、PCI DSS審査を行う時期を踏まえて計画的に実施する必要がある。

     

    対策ソリューションの例:

    PCI DSS準拠/維持支援スキャンサービス

    PCI SSCからASV認定を受けた診断メンバーによる脆弱性スキャンサービス。弊社準拠支援コンサルティング/審査サービスと組み合わせることでPCI DSS準拠活動全体をワンストップで解決できる。

    【要件12.3.1】

    PCI DSSの各要件における定期的な実施が求められた運用の実施頻度について、ターゲットリスク分析によって決定される。

    v.3.2.1でもリスク分析に関する要件はあったが、v4.0からはPCIDSS要件の特性を踏まえたターゲットリスク分析を実施する必要がある。

    この変更によって事業体の環境やリスクに適した運用頻度を実装することが可能となると想定される。例えば以下のような運用が対象である。

    ・アクセス権限の棚卸の頻度

    ・POIデバイスの検査の頻度

    ・インシデント対応要員に対する訓練の頻度

    「ターゲットリスク分析」という言葉通り、頻度決定対象の運用毎に、資産(ログファイルや認証情報等)と脅威を踏まえたリスク分析を行う必要がある。

     

    PCI DSSv4.0のリリース前から予告されていた特徴について正式にリリースされた内容を踏まえ、以下の通り見解を述べる。

    ① リスクベースの考え方の取り込み

    定期的な実施が求められる各運用の一部において、リスク分析に基づいた頻度の決定が必要となった。そのため、より効果的・効率的な運用を行うことができると想定される。


    運用頻度の決定にあたっては、保護すべき情報に対してどのようなリスクがあるのか、外部からの攻撃や内部からの不正のリスクを可視化し、そのリスクを基に組織として頻度を決定する必要がある。組織に責任ある対応が求められるようになっており、要件としては柔軟になるが安易に運用のレベルを下げていいというわけではないことに注意してほしい。

    ② 昨今のクレジットカード情報漏洩の傾向を踏まえた新要件の追加

    新しいバージョンではフィッシング攻撃を防ぐためのシステム上の仕組みだけでなく、教育・啓蒙の観点でも対応がもとめられている。2022年のIPAの10大脅威(個人)においても「フィッシングによる個人情報等の詐取」の順位は1位であり、クレジットカードの取扱いに限らずその対策は急務となっていた。昨今の脅威動向を踏まえると当然の変更と感じられる。

    ③ 既存要件で求められる対策の更なる強化

    要件8にて多要素認証の対象範囲が拡大される、パスワード要件が更新されるなど、複数の要件においてPCI DSSv3.2.1で求められている対策が強化された。本要件はv4.0の公開にあたって、最も影響が大きい要件の1つと考えられる。

     

    インターネット外部に公開していない内部システムであっても多要素認証が求められており、PANを取り扱う事業者においてはシステムの改修、またユーザへの教育などに大きなコストや時間がかかるものと考えられる。本要件の意図は、本人認証の強化であるが、これは決済領域における近年のトレンドとも言える。


    例えば、欧州地域の規制となる「決済サービス指令」(PSD)の第2版でも、個人の認証におけるセキュリティ強化を打ち出しており、金融機関は金融決済の取引において、強力な顧客認証(Strong Customer Authentication:SCA)を実現することが求められている。

     

    SCAとは、知識(利用者だけが知っているもの)、所有(利用者だけが持っているもの)、固有性(利用者自身の属性。例えば生体情報など)に分類される2つ以上の要素の利用に基づく認証のことであり、多要素認証の考え方に相当する。


    また、クレジットカードを利用したEC取引においても、近年、3Dセキュア 2.0(EMV 3Dセキュア)が徐々に普及してきており、利便性を確保しながらも、個人の認証におけるセキュリティ向上のための仕組みが考案・提唱されてきている。

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

    PCI DSS v4.0準拠活動全体としての気を付けるべきポイントと、その対応方針について以下説明する。

    要件とリスクを正しく理解し、効果的なカスタマイズアプローチを

    PCI DSS v4.0の大きな特徴の1つであるリスクベースの考え方、カスタマイズアプローチについては準拠に向けた大きなポイントとなる。

     

    しかし、正しいリスクの識別やそれに対する適切な対策の立案ができない場合、思わぬセキュリティホールを生むケースや、逆に過剰な対策を実施し必要以上のコストを掛けてしまうケースも発生してしまうため注意が必要だ。各要件が求めている本質の理解とそれに適応する施策の立案がPCI DSS v4.0準拠のために特に重要なポイントとなる。

     

    また、各事業体のカード会員データを直接取り扱うシステムのほかにセキュリティコンポーネント(ADサーバ・ログ管理サーバ・ウイルス対策ソフト管理サーバ等)への対応も必要となってくるため、それらを考慮した効率的な準拠対応が必要である。

     

    これらはPCI DSS準拠を行う事業体単独で判断することは難しいため、専門家であるQSAと共に適切な判断を行う必要がある。

     

    弊社ではこれまでのPCI DSS v3.2.1でも単にベースラインの要件遵守の考え方だけではなく、お客様の事業/サービスを理解した上で、実際のセキュリティリスクがどこに潜んでいて、それに対する適切な施策が何かという点も重要視してコンサルティングの支援や審査での代替コントロール立案等を実施してきた。

     

    特に昨今はAWSやMicrosoft Azureのようなクラウド環境上でのシステム構築やリモート環境からの接続について、多くのお客様からご相談いただいている。これまでのオンプレ環境でのPCI DSS準拠活動よりも専門的な環境、仕様の理解とリスクの判断が必要となるため、セキュリティ専門機関のアドバイスが必要な場合にはご相談いただきたいと考えている。

    自社システムだけではなく、利用している製品の対応方針、スケジュールの把握を

    前述の通り、各事業体のカード会員データを直接取り扱うシステムのほかにセキュリティコンポーネントでの対応も必要となってくる。PCI DSS準拠活動の中では主に各事業体側での設定変更か、製品ベンダ側での製品仕様改修による対応が必要となるが、見落としがちなのは製品ベンダ側での対応スケジュールだ。

     

    自社システムの対応スケジュールに加え、各製品のPCI DSS v4.0への対応方針と時期をご確認いただき、そのスケジュールを考慮しておく必要がある。

     

    特に、アカウントごとの権限間、ID/パスワード管理に関わる要件(要件7・8)については製品仕様で制御可能な場合と、利用ユーザ側の対処でカバーしなければならない場合があるため注意が必要だ。

     

    弊社製品の場合、Access Checkやクリプト便等、PCI DSS準拠を支援するセキュリティ製品を自社で開発/運用しているものも多く、PCI DSS v4.0対応に向けQSAとソリューション担当のエンジニア間で密に連携を取りながら製品仕様や時期の調整、及びお客様への支援を進めている。

     

    弊社のPCI DSS準拠支援では、各QSAが製品の改修方針やスケジュール、仕様を理解しながらPCI DSS準拠の支援を進められ、お客様に一気通貫で安心感のある支援が可能であるため、是非ご相談いただきたい。

     

     

    [1] 最新(2022年4月時点)のタイムラインは以下PCI SSCブログ参照

    https://www.pcisecuritystandards.org/about_us/press_releases/
    pr_03312022

     

    [2] 決済セキュリティ基準の最新動向|PCI DSS バージョン4.0の新情報などを解説

    https://www.nri-secure.co.jp/blog/pci-ssc-global-community-forum

     

     

     

    新規CTA