PCI DSSとは？準拠が必要な企業とセキュリティ対策をガイダンス【図解付き】

割賦販売法が改正され、クレジットカード情報を取り扱う事業者は「PCI DSS準拠」または、「クレジットカード情報の非保持化」が必要です。当記事では、守るべきクレジットカード情報とは何かから、キャッシュレス決済を取り巻く状況、ガイドラインの解釈、対応策、PCI DSS最新バージョン4.0など、すべてを徹底解説します。

▼ PCI DSSの課題を最短距離で解決した「お客さま事例 3点セット」の ダウンロードはこちらから

PCI DSS（Payment Card Industry Data Security Standard）とは

PCI DSSとはクレジットカードの会員データ・取引情報の保護を目的とした、国際クレジット産業向けのデータセキュリティ基準です。
2014年12月に、国際カードブランド5社（American Express、Discover、JCB、MasterCard、VISA）によって策定され、現在は同5社が共同設立した組織である、PCI SSC（PCI=Security Standards Council）によって運営・管理されています。

PCI DSSは安全なネットワークの構築やカード会員データの保護など、12の要件に基づいて約 400の要求事項から構成されており、該当する要求事項に全て対応できていることを「準拠」と呼びます。

PCI DSS準拠の検証方法としては、オンサイトレビュー（認定セキュリティ評価機関（QSA）による訪問審査）、または自己問診（SAQ、自己評価によって PCI DSS準拠の度合いを評価・報告できるツール）、サイトスキャンなどがあります。

 

PCI DSSの設立背景

PCI DSSの策定前までは、カードブランドが各自のセキュリティ基準を運用していました。
しかし、加盟店は複数のカードを取り扱うのが一般的であり、各ブランドの基準を満たし要求に応えるのは、非常に大きな負荷が生じていました。

また、インターネットの急速な発展により、Eコマースや決済がグローバル化するのと同時に、国境を超えたサイバー攻撃も複雑・巧妙化し、大規模な情報流出・悪用事故が多発するようになりました。

そこで、加盟店の負担削減とセキュリティ対策強化を目的とし、クレジットカード情報保護の明確なルールを統一するために定められたのが、PCI DSSです。

PCI DSS認定取得のメリット

PCI DSSの認定取得により、サイバーセキュリティの脅威に伴うビジネスリスクを緩和できます。
世界各地の専門家の意見が反映された、技術・運用面で実績のある包括的なセキュリティ基準を満たすことで、不正アクセスからサイトを保護し、情報漏洩やサイトの改ざん・悪用を防止可能です。

また、最新のセキュリティ基準に則っていることを示すことで、顧客の信頼を獲得でき、企業価値やブランド力の向上に繋がります。

 

PCI DSS認定取得の方法

PCI DSSの認定取得方法は、カード情報の取り扱い規模や事業形態などに応じて、以下の3種類に分類されます。

 

QSAによる訪問審査

PCI SSCに認定された審査機関（QSA=Qualified Security Assessor）による訪問審査を受け、認証を得ます。
カード発行会社や多量の情報を取り扱う規模の大きい事業者に求められる認証方法であり、年1回の定期審査が必要です。
QSAの一覧は、PCI SSCのサイトに掲載されています。

 

サイトスキャン

PCI SSCに認定されたベンダー（ASV=Approved Scanning Vendor）によるスキャンツールを用いて、外部に接続しているサーバー機器やネットワーク機器、アプリケーションが、PCI DSSの要求事項を満たしているかを確認します。

四半期に1回以上の点検を通じ、サイトが脆弱でないことの認証を受けなくてはなりません。
インターネットを利用している事業者や、カード情報の取り扱い規模が中程度の企業に要請される方法です。
ASVの一覧は、PCI SSCのサイトに掲載されています。

 

自己問診

PCI DSSの要求事項に基づく、アンケート形式のチェック項目に全て「Yes」と回答できる場合、準拠していると実質的に認められます。
カード情報の取り扱い規模が小さい事業者や、一般加盟店向けの方法です。

アンケート形式のチェック項目については、VISA-Japanのサイトから確認できます。
もともと、ITの専門用語が多く専門的な知識がないと理解するのさえ難しい内容でしたが、現在は一般加盟店やサービスプロバイダなど、形態別に分けてPCI DSSをより深く理解できるよう工夫され、わかりやすくなりました。
自己問診票（PCI DSS SAQ）については、複数のタイプが用意されており、その中から適したものを選択する必要があります。日本語に対応しているので、わかりやすいでしょう。

例えば、自己問診の内容としては「システムの構成要素が安全に設定され、管理されている。」「保存されているアカウントデータを保護するためのプロセスとメカニズムが定義され、理解されている。」「利用者及び管理者の強力な認証が確立され、管理されている。」などが挙げられます。

 

PCI DSS準拠が必要な企業とは

一般に「カード会社」と呼ばれる企業には、VisaやMastercardなどの国際ブランドと契約して加盟店との契約や決済と精算業務を行うカード会社（アクワイアラ）と同じく国際ブランドと契約してカード会員に対してクレジットカード発行業務を行うカード会社（イシュア）の2種類があります。

カード会員がカードを加盟店に提示すると、その情報は決済ネットワークを通してアクワイアラに送られ、さらにイシュアへと連携されます。この過程でカード情報が通過・処理・保存される事業者は、外部の業務委託先も含め、全てPCI DSSに準拠しなくてはなりません。

なお、海外の場合は原則として銀行がアクワイアラです。一方、日本の場合はイシュアがアクワイアラ業務を兼ねていることが多いといえます。
この場合、カードの発行と加盟店の契約といった両方の業務を行う形となります。業務を兼ねているからこそ、クレジットカード決済導入の申し込みから始まり、審査までワンストップまで行えるのが特徴です。

 
日本政府は、2020年の東京オリンピック・パラリンピック開催を踏まえ、キャッシュレス決済普及と訪日外国人増加を踏まえたATMの海外発行カードの対応やカードを消費者が安心して利用できる環境整備に向けた対策の取りまとめを関係省庁に指示しました。これを受け、経済産業省をオブザーバーとしたクレジット取引セキュリティ対策協議会が、「クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画」（以下実行計画）を2016年から発行しており、2020年まで毎年アップデートが行われました。

実行計画内では、クレジットカード取引にかかわる事業者の種類別に、PCI DSS準拠の期限が決められています（加盟店についてはカード情報の非保持化も選択可能）。間に合わなかった場合、罰則規定はありませんが、決済代行事業者についてはアクワイアラは契約を見直すよう求められています。また2018年6月1日に施行される改正割賦販売法では、加盟店もカード情報保護について法律上の義務を負い、アクワイアラからの指導強化や、最悪の場合は加盟店契約が解除になるといった影響が考えられます。

 

PCI DSS取得の費用相場

PCI DSS取得の費用相場は、事業規模によって異なるものの、オンプレミスでの構築を前提とした場合、最低でも初期費用1500万円以上、保守などの月額費用で120万円以上かかることが想定されます。

個々の事業者がPCI DSSを取得するためには、莫大な費用と1年以上の長い時間がかかるため、PCI DSSの準拠を支援するサービスを活用するのがおすすめです。
 

PCI DSSにおけるカード情報の定義

PCI DSSでは、保護の対象となるカード情報を「アカウントデータ」と呼んでいます。アカウントデータに含まれる項目は「カード会員データ」と「機密（センシティブ）認証データ」の2種類に分けられます。

PCI DSSでは、保護の対象となるカード情報を「アカウントデータ」と呼んでいます。アカウントデータに含まれる項目は「カード会員データ」と「機密（センシティブ）認証データ」の2種類です。
ここでは、この中でも特に理解しておきたいプライマリアカウント番号（PAN）と、セキュリティコードについて詳しく解説します。

プライマリアカウント番号（PAN）

プライマリアカウント番号とは「PAN：Primary Account Number」と呼ばれるものであり、クレジットカード番号のことです。主に16桁（American Expressは15桁）の番号で、将来的には19桁化が予定されています。
それぞれのカードで番号が異なっているため、不正を防ぐ意味でも重要なものです。また、国際ブランドによってもカード番号は異なります。

16桁の桁数が設定されているカードの場合は「1234 5678 9012 3456」のように4桁・4桁・4桁・4桁で成り立ちます。

このうち、左端1桁目から6桁目までの数字が「発行者識別番号」、左端7桁目から最後の1つ手前の数字が「会員口座番号」、最後の1桁が「チェックデジット」です。

●発行者識別番号

左端1桁目から6桁目までの数字にあたる発行者識別番号は、カード会社を識別するための数字で「BINコード：Bank Identification Number」とも呼ばれます。
この6桁のうち、最初の数字は「主要産業識別子」と呼ばれ、そのクレジットカードを発行している国際ブランドが属している産業を示すものです。そのため、同じ国際ブランドのカードの場合は共通の数字が先頭に使われている形になります。
例えばVisaなら「4」、Mastercardは「5」です。このことから、例えばインターネットで買い物をしようとした際、カードの種類にMastercardを選んだのにVisaを指す「4」から始まるカード番号を入力した場合はエラーになります。

●会員口座番号

左端7桁目から最後の1つ手前の数字にあたる会員口座番号は、口座番号といっても銀行などの口座番号ではありません。個人を識別するための数字です。該当する数字は、カードの所持者ごとに異なります。

●チェックデジット

カード番号の最後の1桁がチェックデジットです。クレジットカードの番号が正しいかについて、特殊なアルゴリズムによって確認するために「MOD 10」と呼ばれる式で算出されています。

セキュリティコード

セキュリティコードとは、カードの裏面に印字されている3桁（American Expressはカード表面の4桁）の数字です。国際ブランドによって表現方法が異なり、VISAではCVV2(Card Verification Value)、MastercardではCVC2(Card Validation Code)のような形でCAV2、CID、CVC2、CVV2と表現されています。
カードの磁気ストライプには全トラックデータ・全磁気ストライプ情報と呼ばれる情報が含まれていますが、セキュリティコードの情報は含まれていません。そのため、仮にスキミングなどによって磁気データをコピーされてしまったような場合でも、セキュリティコードを正しく入力しない限り、不正利用ができないことになります。
なお、日本国内すべてのカード発行会社でセキュリティコード対策を施しているわけではありません。

（参考：PCI DSSにおけるカード情報の定義）

 
 

クレジットカード漏洩時のビジネスインパクト

守るべきクレジットカード情報

クレジットカード情報はどのように盗まれるのか

まず、最も典型的な手法としてあげられるのが、「SQLインジェクション」によるカード情報の抜き取りです。SQLインジェクションとは、ECサイトなどのWebサーバに対して、不正なデータベースコマンドを入力して、データベースサーバに保存されている情報を抜き取るという方法です。

また、バックドアによるカード情報の詐取の手口が有名です。バックドアをECサイトなどの決済を行うWebサイトのカード決済画面やアプリケーションサーバに潜ませることにより、カード情報を悪意のある第三者のサーバにも送信することができます。特徴的なのは、カードの決済情報は通常通りPSP(決済代行事業者)にも送られているため、決済は正規に完了します。そのためカード情報の流出に気付かず、長い期間に渡ってカード情報が流出し続けるということが多いです。

最後に、現在米国で急増中のPOSマルウェアによるカード情報盗難の事例を紹介します。POSマルウェアは、加盟店の店舗内のPOSマシンで使用しているネットワークと接続しているネットワーク（Wi-Fiなど）を利用しているPCなどから感染し、POSマシンやストアサーバからカード情報を検索し、外部に不正に送信を行います。
（参考：PCI DSSとは？ カード情報漏えいとセキュリティ対策）

盗まれたカード情報はどう換金されるのか

抜き取ったカード情報は、本人確認の比較的甘いプリペイドカードへの残高チャージや、モバイルペイメントアプリに登録して使用されるケース、他人のクレジットカードをiPhoneに支払カードとして登録して、不正利用されるなどが考えられます。

また、入手したカード情報を自分で使用せず、偽造や不正利用に使えるカード情報リストとして販売するブラックマーケットも存在しています。カード番号・有効期限がセットになったデータが販売されています。こうして不正に得たお金が組織犯罪やテロの資金源となっているとも言われています。

 

カード情報が情報漏えいした加盟店の支出（例）

万一、加盟店がカードデータを流出してしまった時、ビジネスに対してどのようなインパクトがあるか。直接的な金銭支出について考えてみます。

［1］調査のコスト:500万円～1,000万円
［2］お客様へのお詫びのコスト:1人あたり500円程度
［3］他の加盟店でカード情報が不正に使用された場合：損失負担は流出させた加盟店
［4］二次被害を防ぐためにカード会社や国際ブランドによるモニタリング：加盟店負担
［5］カード会社の再発行手数料：1枚あたり2,000〜3,000円を加盟店が負担
［6］カード会社が対応するためのコールセンター運営：加盟店負担

原因を明らかにしてセキュリティ対策が完了するまではカード情報の流出が続いている疑いがあります。そのため、原則としてクレジットカード決済は一時停止措置が取られます。その間当該加盟店は顧客にクレジットカードによる支払手段を提供出来ません。
（参考：PCI DSS準拠の必要性 クレジットカード漏洩時のビジネスインパクト）

 
 

クレジットカード取り扱い事業者が実施すべきセキュリティ対策

クレジットカード取り扱い事業者が実施するべきセキュリティ対策として、クレジット取引セキュリティ対策協議会が取りまとめた、「クレジットカード・セキュリティガイドライン」に基づいた対策が必要です。このガイドラインは、セキュリティ対策置の実務上の指針と位置づけられていた「クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画」（実施期限は2020年3月末）の後継文書となります。

クレジットカード・セキュリティガイドラインは、「割賦販売法（後払分野）に基づく監督の基本方針」において割賦販売法で義務付けられているカード番号等の適切管理及び不正利用防止措置の実務上の指針として位置付けられるものです。本ガイドラインに掲げる措置又はそれと同等以上の措置を講じている場合には、セキュリティ対策に係る法令上の基準となる「必要かつ適切な措置」を満たしていると認められます。

 

必要なセキュリテュ対策内容とは

割賦販売法の改正により拡充されたクレジットカード番号等取扱業者に対するクレジットカード・セキュリティガイドラインにおけるセキュリティ対策の一覧(『クレジットカード・セキュリティガイドライン【3.0版】』P15より) 　以下は抜粋した図です。

改正割賦販売法（抜粋）

PCI DSS準拠が求められるユーザー企業（2021年改正割賦販売法で定義される1号～7号事業者に該当）としてどの事業者に該当するか、確認可能です。

事業者種別	具体的な業種例
1号事業者	・カード発行会社（イシュア）
2号事業者	・加盟店（対面/非対面）
3号事業者	・加盟店契約会社（アクワイアラ）
4号事業者	・決済代行業者等 決済代行業者、ECモール事業者、ショッピングセンター・モール等、CCT端末先　等
5号事業者	・QRコード決済事業者等 QRコード決済事業者、スマートフォン決済事業者、ID決済事業者等、名称にかかわらずカード情報と紐づけた他の決済用番号で決済を行う事業者
6号事業者	・第5号事業者からカード情報の管理を受託している事業者
7号事業者	・加盟店向け決済システム提供事業者 EC システム提供会社(ASP/SaaS として EC 事業者にサービス提供する事業者、EC 事業者に購入プラットフォームを提供する事業者) 　等 ※カード会員データの伝送処理保存を行っている事業者、決済代行会社又はアクワイアラに接続できる決済モジュールを提供している事業者も含まれます。

 
（2022年3月9日更新） 「クレジットカード・セキュリティガイドライン【3.0版】が取りまとめられました」

・「クレジットカード・セキュリティガイドライン」とは、安全・安心なクレジットカード利用環境を整備するため、クレジットカード取引に関わるカード会社、加盟店、決済代行業者等の関係事業者が実施するべきクレジットカード情報漏えい・不正利用防止のためのセキュリティ対策の取組を取りまとめたものです。

・また、同ガイドラインは、割賦販売法に規定するセキュリティ対策義務の「実務上の指針」として位置づけられており、同ガイドラインに掲げられている措置又はそれと同等以上の措置を適切に講じている場合には、同法で定めるセキュリティ対策の基準を満たしていると認められます。

・なお、[3.0版]では、関係事業者における適切なセキュリティ対策の実施を促進するため、割賦販売法に規定するセキュリティ対策の義務対象となる事業者の例示を記載するなどの具体化を図っています。

 
 

EC加盟店はPCI DSSは必要？ 日本独自ルール クレジットカード情報の非保持とは

クレジットカード情報の非保持化とは、自社のサーバーで「カード情報」を『保存』、『処理』、『通過』しないこと」をいいます。これにより、万が一情報漏えいなどが起こってしまった際、会員情報の漏えいを防ぐことに繋がります。

なお、クレジットカード情報保護において、非保持化がPCI DSS準拠と同等であると見なされるのは、クレジットカード加盟店だけであることに留意しなければなりません。実行計画においては、加盟店以外でカード情報を取り扱うカード発行会社（イシュアー）、加盟店契約会社（アクワイアラー）、サービスプロバイダ（PSP、プロセシング事業者＝決済データの処理などを受託する会社など）は、カード情報を保持することになるので、適切な対策の構築を求めています。
これらの事業者はクレジットカード情報の非保持で対応できないため、PCI DSSへの準拠が求められます。

クレジットカード情報の非保持によって対応できるのは、店舗やECサイトといった加盟店です。こちらに該当する場合はカード情報の非保持化を選択することにより、カード情報の保護に対応したとみなされます。
PCI DSSの認定を取得するにはコストと時間がかかってしまうことから、選択できる場合はクレジットカード情報の非保持で対応すると良いでしょう。

クレジットカード情報の非保持化を実現するシステム

ECサイトなどがクレジットカード情報の非保持化を選択する場合、適切な形で行っていかなければなりません。

まず、クレジットカード決済の際、カード情報が事業所のサーバーを通過する通過型の決済システムはNGです。
「モジュール方式」と呼ばれるタイプは通過型の決済システムであるため、カード情報がEC事業者側に渡る形になります。カード情報の非保持化の条件を満たさなくなってしまうため、非通過型の決済システムを選択しなければなりません。
非通過型決済であればカード情報がネットワークを通過しないので、クレジットカード情報の非保持化に対応可能です。非通過型には「リンク方式」と「トークン方式」の2種類があります。それぞれ解説します。

●リンク型

リンク型とは、ECサイトなどで利用者がカード決済を行う際、直接ネットショップのサーバー上で決済するのではなく、1度決済代行業者のドメインであるWebサイトに遷移する形で決済するもののことをいいます。リダイレクト型という名前でご存知の方もいるでしょう。
決済代行事業者が用意している画面を使用することもあり、低コストで利用できるのが大きな魅力です。ただ、掲載時には外部サイトに切り替わることになるので、カート離脱の可能性があるのはデメリットといえます。

決済代行事業者のWebサイトに遷移することになれば、これまで見ていたページとはデザインが大きく異なるページに遷移することになります。注文時だけ別のページに飛ばされると違和感や不安を覚えることがあり、それをきっかけとして注文を取りやめるケースも珍しくありません。
EC事業者の場合はカート離脱が大きな問題になることもあるため、慎重に検討が必要です。

●トークン型

トークン型とは、カード情報を「トークン」と呼ばれる文字列に置き換える形で決済代行業者との通信を行う方法です。そのため、EC事業者側にはカード情報が残りません。情報がトークンに置き換わることから、万が一通信途中で情報の漏えいが発生してしまったとしても不正利用されるリスクを抑えることが可能です。
決済サービスプロバイダが提供するJavaScript APIを組み込む形で対応します。
リンク型と大きく異なるのが、自社サイトドメイン内で決済を完結できる点です。外部サイトに遷移することがないため、カート離脱のリスクを大きく抑えられます。同一サイト内で完了するので、決済代行業者のWebサイトに遷移するすることはありません。
デザインなどが切り替わることもなく、顧客にとっての安心にもつながるでしょう。

また、モジュール組込み型ということもあり、大幅なシステム改修をすることなく利用できるのも大きなメリットです。ただ、JavaScriptが動作する環境でなければ利用できません。
導入するにあたり、初期費用のほか月額固定費用がかかること、決済処理一件ごとに手数料がかかることなどは理解しておく必要があります。

（参考：「カード情報非保持」の定義とは）

 

PCI SSCが提供するドキュメント・ライブラリー

PCI Security Standards Council は、PCI セキュリティ基準の開発、管理、教育、 および認知を担当する、オープンなグローバルフォーラムです。下記サイトでは、PCI DSS準拠を実現するのに役立つさまざまなツール、問診、ガイダンス、FAQ、トレーニングリソースなどの資料や情報が提供されます。是非参考にしてください。
▼参考：PCI Data Security Standard Self-Assessment Questionnaireはこちらから
https://www.pcisecuritystandards.org/document_library
 

認定審査機関一覧（QSA=Qualified Security Assessor）

日本国内においてPCI DSSの審査が可能なQSA(認定審査機関)は、下記のPCI SSCのサイトで、実施場所や言語で絞り込むことで、認定審査機関（QSA）の一覧が確認できます。クレジットカード情報を保存、処理、通貨する企業で、例えば、カード加盟店やカード会社、銀行、決済代行、BPO事業者などのサービス・プロバイダーが対象です。

https://www.pcisecuritystandards.org/assessors_and_solutions/qualified_security_assessors
また、QSA企業一覧は日本カード情報セキュリティ協議会(JCDSC)のQSA／ASV企業一覧のページにも掲載されています。

 

PCI DSSで定められている6つの目標とそれに対応する12の要件

具体的にどのような基準が定められているのか、PCI DSSでは6つの目標とそれに対応する12の要件が定められています。また、カード会員データを扱う範囲と保護が必要な箇所が特定することで、効率的な準拠が実現できます。具体的にPCI DSSで定められている6つの目標とそれに対応する12の要件は以下となります。
（参考：PCI DSS 6つの目標と12の要件 PCI DSS準拠が必要な企業とは）

 

６つの目標	12の要件
安全なネットワークとシステムの構築と維持	要件1 カード会員データを保護するために、ファイアウォールをインストールして構成を維持する 要件2 システムパスワードおよび他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない
カード会員データの保護	要件3 保存されるカード会員データを保護する 要件4 オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する
脆弱性管理プログラムの維持	要件5 すべてのシステムをマルウェアから保護し、ウイルス対策ソフトウェアまたはプログラムを定期的に更新する 要件6 安全性の高いシステムとアプリケーションを開発し、保守する
強力なアクセス制御方法の導入	要件7 カード会員データへのアクセスを、業務上必要な範囲内に制限する 要件8 システムコンポーネントへのアクセスを識別・認証する 要件9 カード会員データへの物理アクセスを制限する
ネットワークの定期的な監視およびテスト	要件10 ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する 要件11 セキュリティシステムおよびプロセスを定期的にテストする
情報セキュリティポリシーの整備	要件12 すべての担当者の情報セキュリティに対応するポリシーを維持する

 
 

PCI DSS準拠への対応プロセス

PCI DSS対象範囲策定

クレジットカード会員情報の取り扱い範囲特定し、PCI DSS準拠対応が必要な範囲を確定します。PCI DSS準拠対応においては、この最初の対象範囲を確定する作業がとても重要な作業となります。

 

FIT&GAP分析、対応方法の検討（ツール/サービス選定）

現在のセキュリティ対策状況を洗い出し、PCI DSSの要求事項とギャップ分析を行います。分析結果に基づいて、対応策の検討を行います。

システムへの実装と文書作成

システム仕様の策定をおこない、実装および運用手順/帳票などのポリシー文書作成を行います。また、執務エリアや店舗など環境整備も必要です。

運用と審査

内部スキャンや外部スキャン、ペネトレーションテストをを行います。検出事項への対応から、審査機関（QSA）へ提出する各種ドキュメント準備をおこないます。

 

PCI DSSの準拠対応後

PCI DSS 準拠は、お客様ビジネスの保護に不可欠な一手ですが、それだけでは十分ではありません。日々の運用改善、継続的な努力が必要です。企業が成長するにつれ、また時代とともにリスクも大きく変化しますので、各事業者は､最新の情報に基づいて、多面的・重層的な対策をする必要があります。

 

PCI DSS v4.0 今後のスケジュールと最新情報

PCI DSS v4.0 公開（2022年4月20日更新）
2022年3月31日、PCI DSS v4.0が公開された。同時に、Summary of Changes（v3.2.1とv4.0の変更点の概要）、準拠報告書（RoC）テンプレート、加盟店向けおよびサービスプロバイダー向けの準拠証明書（AoC）テンプレートが公開された。

（参考：PCI DSS v4.0公開と移行のスケジュール）

 

初めての PCI DSS v4.0（日本語字幕付き動画） 公開

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

 

PCI DSS v4.0で顕在化するクラウドサービスの課題

現行のv3.2.1からの改訂ポイントは、主に4つありますが、その中でも課題となるのが、「④クラウドサービスの要件への取り込み」です。PCI DSS準拠企業は、さまざまな外部委託先を活用しています。近年では、PCI DSS準拠対象となるシステムにSaaS、PaaSなどのクラウドサービスやセキュリティサービスを活用されることが増えています。ところが、日本で展開されるそれらのサービスの多くにPCI DSS準拠に活用できることをうたっているにも関わらず、自身はPCI DSS準拠をしていないという現状があります。

仮に、この問題を放置してPCI DSSに準拠していないサービスプロバイダーのサービスを使い続けた場合、認定審査機関（QSA）の審査からの指摘事項となりPCI DSS完全準拠とは言えないと判断されるケースが想定されます。

もう一点、「外部委託先との間の責任区分の明確化」についても注意が必要です。
PCI DSS準拠企業に対し、PCI DSS要件ごとの責任区分の明確化を求めています。しかし、サービスプロバイダーから情報開示が無いと、準拠側の責任範囲が分からないので、この要件を満たすことができず、PCI DSSに準拠できないことになってしまいます。言い換えると、責任区分を明示した文書を提供していないクラウドサービスを利用してPCI DSSに準拠することはできない可能性があるため注意が必要です。
（参考：PCI DSS準拠のために導入したクラウドサービスがPCI DSS準拠してない矛盾）

関連記事：PCI DSS v3.2の概要と最新バージョン4.0と比較した特徴・違い

V4への対応スケジュール

PCI DSS 事例

クレジットカード情報非保持化 事例 オルビス 様

“Pay TGは非対面加盟店の現場に寄り添い、一から設計されたサービス。オペレーターの負担を最小限に、スムーズにカード情報非保持化を実現できるサービスです”


改正割賦販売法の技術的指針である実行計画に基づいた高いセキュリティレベルを担保したうえで、現場のオペレーターが使いやすい仕組みであることが大切です。その点で、Pay TGは、非対面加盟店の現場に寄り添い、一から開発していることに強みがあると感じます。

一つ例を挙げると、テンキーでカード番号を入力した際の表示があります。他社サービスの場合「＊＊＊＊＊」といったように、入力したカード番号が見えないようマスクされるケースがありますが、Pay TGは、確定されるまではカード番号がそのまま画面に表示される仕様となっています。（参考：オルビス株式会社 様 導入事例）

クレジットカード情報非保持化 事例 株式会社はとバス 様

“セキュリティに関して安心して利用できるPay TG。訪日外国人と邦人向け受注コールセンターで安心して利用しています”



特に重要視したのがセキュリティ面です。内回り方式も検討してましたが非保持化“同等”である事と、社内ネットワークを通過しているため、何かあった場合のインパクトを考慮して、外回り方式を採用しているPay TGをメインに検討を進めていました。
最終的には、入金を確認して初めて旅行契約が締結し、その後に予約番号やお座席をご案内するという当社の運用方法も踏まえ、Pay TGの導入に決定しています。旅行商品は約款上、決済して初めて契約が締結されるという事情などがあります。各種決済方法を検討している中、決済代行会社からのアドバイスもあり、当社の運用上一番スムーズで、しかも手軽に利用できることからPay TG導入を決めました。（営業企画部 通信販売課 高木 滉平氏）（参考：株式会社はとバス 様 導入事例）

クレジットカード情報非保持化 事例 JIMOS 様

“Pay TG は利用するユーザーの意見を取り込んだサービスの開発スタンスが非常に柔軟です。さまざまな企業の運用課題をしっかりヒアリングし、要望を取り入れることでより良いサービスを提供するという企業姿勢を高く評価しました”


Pay TG は、従来のオペレーションを変更することなく、オペレーションミスが発生しない仕組みを構築可能であること、入力したクレジットカード番号が全桁表示されるのでオペレーターが復唱できること、基幹システムと決済端末のAPI 連携の開発コストが他社サービスの半額で済む、大きくこの３点を評価して、Pay TG に決定しました。

サービスの開発スタンスが非常に柔軟な点も高く評価しています。Pay TG は、さまざまな企業の運用課題をしっかりヒアリングし、要望を取り入れることでより良いサービスを提供するという姿勢は、長く付き合いができるパートナーとして、大変ありがたいです。（参考：株式会社JIMOS 様 導入事例）

クレジットカード情報非保持化/サブスク決済 ユースケース PCショップ 様

“パソコンの初期設定、お客さま過失の故障やデータ復旧などを行う月額課金型PCサポートサービス。店頭受付でのクレジットカード決済業務のペーパーレス化と二度打ちから発生する打ち間違いをゼロに。”



（導入前）
・来店されたお客様に、申込書（紙）を記入頂いているが、ペーパーレス化を行いたい。
・紙の申込書をデータ化する時間がかかるため、お客様をおまたせしていた。
・クレジットカード情報を決済端末に手入力するため、たびたび打ち間違いが発生していた。

（導入効果）
・お客様はタブレットに申込情報を入力。タブレットと基幹システム、SmartTGが連携することで、ペーパーレス化を実現。
・お客様の待機時間が大幅減。三密を回避し、満足度アップ。
・Smart TGの磁気/ICでカード情報を読み込ことで、打ち間違いもなく、業務効率がアップ。

（参考：PCショップ 様 ユースケース）

PCI DSS準拠 事例 メトロエンジン 様

“ 新サービスの宿泊予約エンジン「メトロブッキング」に必須となる、PCI DSS 準拠のシステムを1ヵ月で構築。
低コストで、スピード感あるローンチに成功しました ”


PCI DSS Ready Cloud AWSモデルを採用した最も大きな理由は、システムを自社で構築する方法、他社のサービスを利用する方法と比較して低コストで準拠環境を実現できることです。

コスト以外の理由が、短納期での対応ですね。当社はスピード感のある経営を心がけており、サービスのアイデアが生まれ、プロジェクトが始まってから、だいたい1、2ヵ月で、MVP※を完成し、市場でテストマーケティングさせることを目指しています。メトロブッキングも、4月末にプロジェクトが始まり、6月中にリリースするというタイトなスケジュールを組みました。リンクにそのような短期の構築が可能であるか否か確認したところ、自信をもって「できる」との回答をいただき、本当に心強く感じましたね。（参考：株式会社メトロエンジン 様 導入事例）

PCI DSS準拠 事例 北の達人コーポレーション 様

“あらゆる事業リスクを低減させ、お客さまに安心して利用いただけるEC サイトを目指して。低コストでPCI DSS 準拠し、効率の良い運用体制を実現しました”


準拠に必要なセキュリティ機能がパッケージ化されたサービスを用意していたため、そのサービスを活用すれば、PCI DSS 準拠が最短で実現できます。しかもコストもリーズナブルで、AWS を利用した準拠実績が多数あったため、リンク社のサービス利用を決断しました。

PCI DSS の運用に必要な定形、非定形作業を委託できるマネージド・サービスも利用しています。PCI DSS に精通したエンジニアにアウトソースすることで、より効率的な運用体制が構築できたと思います。（参考：株式会社 北の達人コーポレーション 様 導入事例）

PCI DSS準拠 事例 ＪＦＲカード株式会社 様

“データレイクを構築するプロジェクトにPCI DSS Ready Cloudを採用しました。プロジェクトは大変手離れが良く、リンクの技術者にぜひ感謝の旨、お伝えいただければと思います”


左から 執行役員兼システム業務企画本部 本部長 武井 匡仁氏 システム企画部 部長 義友 建弘氏 システム企画部 岩森 吏央氏

PCI DSS準拠という当たり前に求められるセキュリティ対策で、絶対に事故を起こさないことを念頭に置きながら、グループの一つの大きな柱を担っていければと考えています。あらゆる施策を実現するために一丁目一番地は「データの利活用」だと確信しています。

今回のデータレイク構築の取り組みにより、カード事業のOne to Oneマーケティング、マーケティングオートメーションが可能になります。今後、タンキングするデータレイクには、コールセンターの音声データ、外部から購入などするマーケティング関連データを入れるなど、“器”としての機能をより充実させていきます。（参考：ＪＦＲカード株式会社 様 導入事例）

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

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