2016年3月11日11:18
PCI DSS（Payment Card Industry Data Security Standard）は、加盟店やサービスプロバイダが取り扱うカード会員のクレジットカード情報を保護するためのデータセキュリティ基準である。同基準を運用するPCI SSC（Payment Card Industry Security Standards Council）は、2015年4月15日、PCI DSS Version3.1(以下、Ver3.1)を発表した。その発表の概要、要件の詳細、要件対応の実際について解説する。
１．PCI DSS Version.3.1発表の概要
PCI DSS Version3.1のリビジョンは、Version3.0（以下、Ver3.0）に対するマイナーな更新や記載内容の明確化を含んでいるが、主な変更はWebサーバなどの暗号化通信で標準的に使用されている、Secure Socket Layer（以下、SSL）やTransport Layer Security （以下、TLS）での脆弱性への対処を規定していることである。
近年、SSLや初期バージョンのTLSに「POODLE」や「BEAST」と呼ばれる重大な問題のある脆弱性が相次いで発見されている。NIST（The National Institute of Standards and Technology ： アメリカ国立標準技術研究所）は、SSLは安全な通信のためには許容されないとしている。同じく、IPA（独立行政法人情報処理推進機構）では、2015年8月に公表した「SSL/TLS暗号設定ガイドライン」の中で、SSLの使用は「セキュリティ例外型」でのみ使用を許可するとしており、その場合もその使用は無期限ではなく近いうちには使用を制限する可能性があるとも言及している。
SSLの最新版であるSSL3.0は1995年に、初期バージョンのTLSであるTLS1.0は1999年にそれぞれリリースされたものであり、かなり古い時代のものである。これらのプロトコルの使用にあたっては、パッチの適用などの脆弱性対策ではもはや不十分であり、これらの古いプロトコル自身が脆弱性を内在しているので、新しいバージョンのプロトコルに置き換えて使用しなければならないということなのである。
これらの業界の流れを受けて、今回のVer3.1においては、今まではセキュリティ上強固で安全なプロトコルの範疇に入れ使用を許可していたSSLや初期バージョンのTLS （TLS1.0及び一部のTLS1.1）を、一転して安全ではなく使用を禁止するプロトコルとみなすこととなった。そのため、SSLや初期バージョンのTLSを使用する設定がある場合は、これらを無効化しTLS1.1以上に対応することが必要となった。
なお、今回の発表は即日有効とされており、またそれに伴い古いVer3.0は同年6月30日に終了となっている。
Ver3.1のポイントを以下に記載する。
（1）SSL/TLS通信の暗号プロトコルはTLS1.1以上を使用。SSLと初期バージョンのTLSの使用は禁止
Ver3.1からは、SSLの全バージョンやTLSの初期バージョン（TLS1.0及び一部のTLS1.1）は、PCI DSSで定義される「安全なテクノロジー/強力な暗号化」の要件をみたすことができなくなり、TLS1.1以上の使用が強制されることとなった。移行期限である2016年7月以降は、現在使用している場合も含めて、すべてのSSLや初期バージョンのTLSの使用は禁止される。
今回の方針変更の影響を受けるのは、具体的には以下の①～③に記載のPCI DSS要件が求めるセキュリティ対応であり、それぞれで通信プロトコルの更新が必要となる。
①システム構成基準に沿った安全な通信プロトコルの実装
②強力な暗号化によるコンソール以外のすべての管理通信（特にWebの通信）の保護
③強力な暗号化によるインターネット経由のカード会員データの保護
なお、TLS1.1の使用に関してだが、初期バージョンでなければその使用は認められてはいるが、実装によってはセキュリティのリスクをはらむ可能性がある。そのため、PCI SSCでは、TLS1.2の使用を強く推奨している。
（2）新規のシステム実装時のTLS1.1以上の使用
新規のシステム実装では、移行期限である2016年7月を待たず、今すぐにTLS1.1以上に対応する必要がある。なお、「新規のシステム実装」とは、「SSLや初期バージョンのTLSに依存しない環境へのシステム実装」と規定しており、単純なWebサーバ増設やOSの更改などは、新規の実装には含まれていない。
（3） 2016年6月末までのTLS1.1以上への移行と「リスク低減策および移行計画」の作成
現在、脆弱性のあるプロトコルでサービス提供中であるといった、既存のシステム実装の場合は、すぐにはVer3.1の要件が求めるTLS1.1以上への移行ができないので、当面はSSLや初期バージョンのTLSを使用し続けることとなる。Ver3.1では、その移行に関しての猶予期間と期限が定められており、2016年6月末という移行完了期限までに、SSLや初期バージョンのTLSの使用をやめて、TLS1.1以上に移行させなければならないとされている。さらに、この移行期間中に、移行完了期限内に移行を完了させるための移行計画と、移行期間中のリスクの低減について記載した「リスク低減策および移行計画」を作成することを要求している。SSLおよび初期バージョンのTLSを使用し続けることは、セキュリティ的なリスクが残存するため、2016年7月を待たずに早急にアップグレードすることが推奨されている。
なお、PCI SSCは、昨年末の2015年12月18日のプレスリリースで、Ver3.1で定められた移行完了期限を2016年6月30日から2018年6月30日に2年間延長すると発表している。また、これらを含むPCI DSSの次期バージョンは2016年に発表される予定である。詳細については、「4.TLS1.1以上への移行期限の延長」に記載する。
２．要件の詳細
「１．PCI DSS Version.3.1発表の概要」では、Ver3.1の概要を述べたが、「２．要件の詳細」では、Ver3.1で変更された要件の詳細を記載する。
（1）要件の変更内容
「１．（1） SSL/TLS通信の暗号プロトコルはTLS1.1以上を使用」に記載したように、今回のTLS1.1以上の使用という方針変更の影響を受けるのは、下記の3つの要件である。それぞれに対して、具体的な要件名とその変更内容を記載する。
①システム構成基準に沿った安全な通信プロトコルの実装（要件2.2.3）
安全でないとみなされているサービス、プロトコル、またはデーモンに対して、構成基準に沿ったセキュリティ機能を実装することを要求している要件である。この中で実装すべき安全なプロトコルに変更が発生している。Ver3.0では、セキュリティ機能の例としてSSH、SFTP、SSL、または IPsec VPN を挙げているが、Ver3.1では、SSLの記述が削除され、TLSに置き換わっている。
新規の実装では、TLS1.1以上の使用ということとなるが、その他の既存の実装に対しては以下の2つの対策が定義されている。
・通常の使用形態でSSLやTLS初期バージョンを使用している場合は、それらのすべての実装ごとに「リスク低減策および移行計画書」の作成と実行を行う必要がある。当然、移行計画書は、2016年6月30日という移行期限までの移行を行う計画となっており、この計画に沿って移行を進める必要がある。
・上記への例外として、POS/POIターミナルで使用されているSSL/TLSのうち、SSLやTLS初期バージョンに対する既知の攻撃の影響を受けないことが確認できている通信は、移行完了期限以降も使用できる。ただし、その場合、既知のすべてが攻撃の影響を受けないことを確認する文書（ベンダー文書、システム/ネットワーク設定詳細など）が必要である。
②強力な暗号化によるコンソール以外のすべての管理通信（特にWebの通信）の保護（要件2.3）
すべてのコンソール以外の管理通信は、強力な暗号化を用いて保護することを要求している要件である。WebではHTTPSを使用することから、Webの管理通信についてTLS1.1以上への移行が必要となる。強力に暗号化された通信を使用しない場合、悪意を持った第三者に、管理者の ID やパスワード等が盗聴される可能性があり、これらを知られてしまうことによってネットワークやシステムにアクセスし、不正な操作や情報を持ち出される可能性がある。Ver3.0では、強力な暗号化を実現する技術の例としてSSH、VPN、またはSSL/TLSなどを使用することを要求しているが、Ver3.1では、SSLの記述が削除された。
新規の実装への対応や既存の実装への対応内容は、要件2.2.3と同様である。
③強力な暗号化によるインターネット経由のカード会員データの保護（要件4.1）
インターネット経由でカード会員データを通信する場合は、強力な暗号化とセキュリティプロトコルを使用することを要求している要件である。これは、悪意のある第三者がカード会員データの送信中にデータを傍受したり宛先を変更させたりする可能性があるためである。Ver3.0では、セキュリティプロトコルの例としてSSL/TLS、IPSEC、SSH などを使用することを要求しているが、Ver3.1では、SSLの記述が削除された。
新規の実装への対応や既存の実装への対応内容は、要件2.2.3と同様である。
なお、ここでTLS1.1以上に対応すべき適用範囲を、通常想定されるインターネット経由で個人情報をやり取りするときの暗号化通信（要件4.1）だけではなく、社内の管理通信をはじめとするその他の暗号化通信（要件2.3など）にも適用していることは特筆すべきである。インターネットほどの脅威はないとしても、クラウドを多用する時代にあっては、社内ネットワークでも盗聴や攻撃のリスクはかなり存在する。そのリスクを想定して、やはり暗号化すべき通信には脆弱性のあるプロトコルの使用はやめるべきという考えである。
（2）リスク低減策および移行計画の作成
TLS1.1以上にすぐに移行できない場合、移行完了までの当面の間はSSLや初期バージョンのTLSを使い続ける必要があるが、そのすべての通信に対して、「リスク低減策および移行計画」を作成する必要がある。つまり、2016年6月末までにTLS1.1以上への移行がすんでさえいればよいというわけではなく、事前にリスクアセスメントを行い、移行に対する計画を作成し、移行前でも実施可能なリスク低減策を実行する必要がある。なお、PCI DSSのQSA（Qualified Security Assessor：認定審査員）による実地審査の時は、必ずこの「リスク低減策および移行計画」がレビュー対象となり、その内容の妥当性やその計画に対する実施状況が確認される。SSLや初期バージョンのTLSの使用に伴うリスクを少しでも低減し、確実に移行を完了させるために、わざわざそのための計画を作成させ、レビューを実施させる要件となっている。
Ver3.1では、「リスク低減策および移行計画」に、以下が含まれていることを要求している。
①伝送されるデータを含む使用の詳細や、SSLや初期バージョンのTLSを使用しているシステムタイプとシステム数、環境
②リスクアセスメント結果と対応したリスク低減策
③SSLや初期バージョンのTLSの最新の脆弱性を収集するプロセスの詳細
④SSLや初期バージョンのTLSが新しい環境に実装されていないことを保証する変更管理プロセスの詳細
⑤移行完了予定日が移行完了期限以降になっていないことを含む移行計画の概要
この「リスク低減策および移行計画」は、ASV検査を受けるときにも必要となる。移行が終了していないときは、脆弱性のあるプロトコルを使用しているということで、ASV診断結果は一般的には「不合格」となるが、その場合はASVベンダーに対して「リスク低減策および移行計画」を提出し、「合格」の判定に修正してもらう必要がある。
３．要件対応の実際
Ver3.1の発表から、8カ月が経過し多くの組織では本格的な検討や対策実施が進められてきている。実際にシステム改修を実施したり、エンドユーザへの告知を行ったりするなどのアクションを実施している組織も多く見受けられる。
ただし、SSL/TLS通信では、必ずしも通信相手が社内にとどまらず、大切な消費者/取引先であったり、改修がすぐにできなかったりする場合が多くある。QSAの会合や、PCI DSS準拠対応している組織との会議の中でも、Ver3.1の対応の困難さは必ず議題の1つとなってきていた。2015年10月に東京で初めて開催されたPCI SSC年次総会でも、数多くの質問がPCI SSCの幹部に投げかけられた。
結果として、それらの声に応える形で、移行完了期限が2年間延期となったが、以下に、PCI DSS準拠対応を本格的に実践している組織での実例をベースに対策実施のポイントを記載する。準拠対象範囲が広く多くのシステムを保有し、対消費者へのサービスも提供している場合は、Ver3.1の対応は想像以上に困難な場合が多いと考えていただきたい。
（1）対象通信洗い出しの準備
Ver3.1で求める「リスク低減策と移行計画」の作成の最初のタスクは、対象となる通信の洗い出しである。対象システム数が多い場合は内部の管理通信の洗い出しなど工数が膨大であるため、複数の担当者で手分けをして実施することが予想される。そのため、あらかじめ以下について準備をしておくと、洗い出しがスムーズである。
①対象通信の定義の明確化
まず、Ver3.1で要求されている対象通信の定義を明確化しておく必要がある。SHA-2対応の証明書問題などで、インターネット経由でのWebサービス提供時のhttps通信は検討がなされ詳細が把握されているのが通常であろう。一方、コンソール以外のWeb等による管理通信は、現状が把握しづらく、専用画面であるが実は通信プロトコルはSSLであるケースもある。意外なところでSSLや初期バージョンのTLSが使われていることもあり、その定義付けが重要である。
②対象通信の洗い出し用のフォーマットの作成
対象通信の洗い出しは、対象通信だけではなく、対応策やリスク低減策を決定する際の判断に必要な項目も洗い出す必要がある。そこであらかじめ対象通信洗い出し結果の記入用のフォーマットを作成しておくと、対応策やリスク低減時に必要な情報の過不足や手戻りがなくなる。記入用のフォーマットは、例えば、横軸を対象機器や暗号区間、暗号化プロトコルのバージョン等の対応策やリスク低減策を決定する際の判断に必要な項目、縦列に対象通信の情報を記入できるようにしておく。
（2）要件毎のリスクの分類とそれらに紐づいた対応策やリスク低減策のパターンの検討
Ver3.1で移行対象となるSSL/TLS通信は、システム数に比例してその量が増加していき、個別に対応策やリスク低減策を検討するには、時間がかかるし、偏りが出てくることが考えられる。そこで、あらかじめ要件毎にリスクを整理し大まかなパターンに分け、そのパターン毎に対応策やリスク低減策を検討しておくと、対応策やリスク低減策の考え方が整理でき、これらが正当なものであることを容易に示すことができる。
特に、要件2.3に対応する社内の管理通信と、要件4.1に対応する社外のWebサービス通信では、対象やリスク、方式、移行手段等が全く異なる場合が多く、別途検討することが多いと思われる。
（3）リスク低減策と移行計画の策定
（1）で洗い出しを行った対象通信毎に、（2）の考え方を当てはめることによっておのずと対応策とリスク低減策が決定される。後はそれを実現するための、具体的な移行計画の検討を行う必要がある。この移行計画の移行完了予定日は、すべて移行完了期限以前である必要がある。
また、リスク低減策や移行計画の中には、上記以外にもSSLや初期バージョンのTLSの新しい脆弱性をチェックするプロセスの詳細やそれらが新しい環境に実装されていないことを保証する変更管理プロセスの詳細が要求されている。これらも忘れずに計画の中に盛り込んでいく必要がある。
（4）サーバ側やブラウザー側のTLS対応
移行計画を具体的に策定するにあたっての2つの重要な要素は、サーバ側でのTLS対応と、クライアント側（ブラウザー）でのTLS対応である。
サーバ側のTLS対応は基本的に容易である。ただ、一部の古い機器/ソフトは、そもそもTLS1.1以上をサポートしていないものも多く、更改や入替が必要になる場合があるので注意が必要である。このような機器/ソフトは、このVer3.1を機に最新版に更新することを強く推奨する。対外的なWebサーバではTLS1.1以上に未対応というのはかなり少ないが、社内での管理通信では、アプライアンスや製品に組み込まれたWebサーバなどの問題で、TLS1.1以上へすぐに対応できない場合がある。
クライアント側は、社内ユーザーとの通信の場合はブラウザーの入替などは比較的容易であるが、インターネット経由での通信の場合は、一般的に困難である。ユーザーの環境なので組織側が管理できない場合がほとんどである。特に、クライアント側であるユーザーは、組織の大切な「顧客」である場合が多く、一方的にSSL3.0/TLS1.0の接続禁止を行うことはできない。さらに、日本ではフィーチャー・フォン経由でアクセスする場合や、MicrosoftのInternet Explorerを使っている場合があり、TLS1.1以上への移行がより困難となる。ある組織では、アクセスするユーザーのブラウザーの30％程度が、TLS1.1以上への対応が不可であり、Ver3.1への対応が死活問題にもなりかねない状況であった。「POODLE」が発見されて以来、SSL3.0を無効化するのはほぼ常識であるが、依然としてTLS1.0は多く残っている。こういったことから、eコマース企業などでは、TLS1.1以上に移行することによって、古いバージョンのブラウザーを使用しているユーザーが、サービスを使用できなくなることによるユーザー離れが深刻な問題となっている。
「英断を持って」TLS1.1以上に移行の実施をする場合も、事前のユーザーへの告知やユーザーからの問い合わせ対応窓口の設置など、システムの移行以上に大きなインパクトが出てくる。
４．TLS1.1以上への移行期限の延長
「３．（4） サーバ側やブラウザー側のTLS対応」に書いた通り、暗号化プロトコルをTLS1.1以上に移行するには、具体的にはサーバとブラウザーの双方で対応が必要であるが、その技術的な難易度は低いにもかかわらずビジネス的な難易度は高い。なぜならば一方的にサービス提供側がSSLやTLS1.0を無効化することは、SSLやTLS1.0のみしか使用できない接続環境を持つユーザーを切り捨てることになり、ビジネスチャンスを失う可能性が高いからである。そのためカード決済にかかわる加盟店（ホテル業界、レストラン業界、その他小売業界など）やペイメントゲートウェイなどいくつかの団体から、Ver3.1でもともと定められた移行完了期限である2016年6月末までに移行を完了するのが難しいという意見が多々寄せられた。これに伴いPCI SSCは、2015年12月18日のプレスリリースで、Ver3.1の要件を一部変更し、移行完了期限を2年間延期する発表を行った。2月17日にPCI SSCのWebに掲載された情報によると、これらの変更を含むPCI DSSの次期バージョンは、PCI DSS Ver.3.2として、本年の初め（3月～4月ぐらい）にリリースされる計画となっている。
PCI SSCが、一度発表した基準の内容を一年経ずして緩めるというのは今までには前例がない異例のことである。逆に言えば、それだけ加盟店などの業界団体からの声が強かったということと考えられる。
（1）発表内容
今回の大きな変更点は、Ver3.1で要求されているTLS1.1以上への移行完了期限を2年間延長することである。これ以外にも以下が発表に含まれている。
①カード決済サービスを提供する事業者は、2016年6月30日までにTLS1.1以上への移行を開始しなければならない。
②すべての新規のシステム実装はTLS1.1以上でなければならない。
③POI端末のSSL/TLSの使用は、既知の全ての脆弱性に対応していることが確認されれば、移行完了期限以降も使用することができる。
移行完了期限は延長されたが、今回の移行はセキュリティ上必要な対応であるため、PCI SSCはできるだけ早い時期での移行完了を強く推奨している。変更内容の詳細に関しては、PCI DSS Ver.3.2の正式リリースを待ちたい。
（2）組織側の対応
今回、TLS1.1以上の移行が2年間延長されたが、脆弱性の存在する通信を使用し続けることは変わらない。そのためできるだけ早くTLS1.1以上への移行を開始し終了させる必要がある。今回の変更にしたがって「リスク低減策および移行計画」を見直す必要が出てくる。
５．最後に
POODLE、BEASTなど、Webの暗号化通信の脆弱性が2014年秋から話題となり、PCI DSSはそれに対応する形で2015年4月にVer3.1を発表した。その趣旨とその対策内容は時流に合ったものであるし正当なものであったが、移行期限の問題で、現実の壁に突き当たったと考えられる。予想以上に、加盟店からの圧力があり、ブランドとしてもその意見を飲まざるを得なかったのであろう。
ただし、移行期限が2018年6月末になったからといって、脆弱な暗号プロトコルを使用し続けるのは問題である。高いリスクを保有しているインターネットでの通信に関しては、少なくともSSL3.0は今すぐにも無効化し、ユーザーに対するTLS1.1以上の使用の啓発を根気強く実施していくべきであろう。
※PCI DSS Version3.1の詳細については、QSA（認定審査機関）にお問い合わせください
