 |
|||||||
|
|
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
VISAに聞く、実装レベルのカードセキュリティ基準「PCI DSS」【前編】 |
||||||||||||||||||||||
|
||||||||||||||||||||||
|
一般企業にも有効なセキュリティ要件
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
||||||||||||||||||||||
最近では、セキュリティ製品のアピールポイントとして、PCI DSS準拠をうたうのがマーケティングの1つのトレンドとなっている。米国で始まった取り組みだが、日本でも広がりつつあり、今後準拠する事業者が増えてくることだろう。では具体的にどういった仕組みなのか。どういった効果が期待されているのか。ビザ・ワールドワイド カントリーリスクダイレクターの井原亮二氏に話を聞いた。 ■ 「PCI DSS」策定の背景 2004年米国で、VISAとMasterCardの2社によって策定されたのがPCI DSSだ。カード情報を扱う事業者のシステムからカード情報が漏えいしないよう、情報セキュリティを強化することを目的とした基準で、基本的に法的な強制力はないものの、カード情報を扱う事業者は準拠することが望ましいとされている。ここでいう事業者とは、カードを発行する「カード会社」、カード決済を採り入れている小売業などの「カード加盟店」、カードに関連する業務を代行するデータ処理事業者「プロセサ」のことである。 ではなぜ、こうした基準が必要となったのか。 井原氏によると、「当時はカード情報を盗むという意味があまり知られておらず、カード加盟店などから意外に簡単に抜き取ることができる状況だった」という。当時、カード情報を盗む手口として、カードの磁気ストライプ情報を盗むスキミング犯罪が流行した。ところが「スキミングは、店舗などに足を運ばなければならない上に、スキマー（情報を盗み取る機器）で一度に取れる情報はせいぜい100件ほどだった」（同氏）。この制限とICカードの普及により、スキミングは次第に下火となっていくのだが、代わりにインターネットの発達が新たなリスクを生み出すことになる。 カード情報が非対面取引でやり取りされるようになると、犯罪者はスキミングのような手間をかけずとも、不正アクセスなどで一度に大量のカード情報が盗めるようになった。必然的にインターネット越しにカード情報を盗むのが主流になる。「そのもっともシンボリックな事件が、2005年米国で発生した大手プロセサからの大量情報流出事件。4000万件以上の情報が漏れたとされている」（同氏）。こうした大量な情報流出が起こり始めたことが、PCI DSS策定の背景という。 また、カード情報を扱う事業者側にも統一基準を望む理由があった。実はPCI DSS策定以前にも、ブランドごとに独自のセキュリティ基準が存在した。「それらはそれぞれ内容が異なっており、全ブランドを扱うカード加盟店にとっては、すべてに準拠することは負担が大きすぎた。結果、事業者からも基準の業界統一を望む声があがり、PCI DSS策定を後押しすることとなった」と井原氏は語る。 ■ 具体的な6個の「目的」と12個の「要件」 こうした状況を受けて2004年12月、VISAとMasterCardによりPCI DSSが策定された。その後、JCB、American Express、Discover Financial Servicesの3社も加わり、同基準は業界共通のものとなる。さらに2006年9月には運営団体である「PCI SSC（PCI Security Standards Council）」が設立され、推進の基盤が整う。同基準では、カードを扱う事業者のカード処理関連システムから情報流出がないよう、6個の「目的」と12個の「要件」が定められている。詳細は以下の通りだが、PCI DSSに準拠するには、これらの要件をすべて満たさなくてはならない。 ・安全なネットワークの構築・維持 【要件1】ファイアウォールを導入し、最適な設定を維持する。 【要件2】システムまたはソフトウェアの出荷時の初期設定をそのまま利用しない。 ・カード会員情報の保護 【要件3】保管されるデータは安全に保管する。また、カード磁気情報は保管しない。 【要件4】公衆ネットワーク上でカード情報などを送信する場合暗号化する。 ・脆弱性を管理するプログラムの整備 【要件5】アンチウイルス・ソフトウェアを使用し定期的にソフトを更新する。 【要件6】安全性の高いシステムとアプリケーションを開発し保守する。 ・強固なアクセス制御手法の導入 【要件7】データへのアクセスを業務上の必要範囲内に制限する。 【要件8】コンピューターにアクセスする際、利用者ごとの識別IDを割り当てる。 【要件9】カード情報にアクセスする際、物理的アクセスを制限する。 ・定期的なネットワークの監視およびテスト 【要件10】ネットワーク資源とカード情報に対するすべてのアクセスを追跡し、監視する。 【要件11】セキュリティ・システムおよび管理手順を定期的にテストする。 ・情報セキュリティ・ポリシーの整備 【要件12】情報セキュリティに関するポリシーを整備する。 PCI DSSでは、カード会員番号（PAN）の伝送、処理、保管のいずれかを行っている「カード会員データ環境ネットワーク」において、これらの要件をクリアするようにと求めている。つまり、PANを扱っていないネットワークにはPCI DSSは適用されないわけだが、カード会員データ環境とそれ以外の環境が明確に切り分けられていないケースも多いだろう。そのため、可能であるならば、ネットワークを2つの環境に分けることが、PCI DSS準拠への近道、そして運用負荷の低減につながると指摘する声もある。 なお、これら12の要件は、さらに詳細な約200項目にブレークダウンされて規定されている。特徴としてよくいわれるのが、各要件の内容が実装レベルのセキュリティ対策として、非常に具体的で明確であるという点だ。 例えば、安全なネットワークの構築と維持を目的とする【要件1】【要件2】では、サーバーやネットワーク機器でデフォルト設定値を使用しないことから、外部・内部ネットワーク、およびDMZの適切なセグメンテーション、アクセスリストの定義、安全なプロトコルの使用、設定内容の定期的なレビューなど、事細かに規定しており、さらにそれらの文書化も求めている。 システムとアプリケーションの安全性を求める【要件6】では、すべてのシステムとソフトウェアに最新のパッチが適用されているか確認を義務づけるほか、関連するセキュリティパッチはリリース後1カ月以内にインストールするなど、中には厳しい要件も見られる。 昨今、Webサイト改ざんの原因となっているWebアプリケーションに関しても、「入力データの未検証」「クロスサイトスクリプティング」「SQLインジェクション」などと具体的な脆弱性を挙げた上で、その防止に努めることと規定。その具体的な手段として「コードの診断」あるいは「Webアプリケーションファイアウォールの導入」のいずれかを必須とするとしている。 ID管理に関する【要件8】でも、パスワード管理の徹底として、離職したユーザーのアクセスはすぐに取り消す、少なくとも90日ごとに休眠状態のアカウントを取り除く、グループ共有のアカウント・パスワードを使用しない、ユーザーのパスワードは少なくとも90日ごとに変更する、少なくとも7文字以上で数字と英字を組み合わせる、入力ミスに対しては6回以内でロックをかける、セッションタイムアウトは15分とするなど非常に細かい（PCI DSS v1.1より）。 この具体的で明確な要件が、PCI DSSがカード情報を扱う事業者だけでなく、一般企業にとっても有効とされるゆえんである。自社の機密情報を守るためにどうセキュリティ対策を行っていけばよいか、多くの企業がPCI DSSをガイドラインとして利用できるであろう。 ■ 「保護対象」となる情報の種類
保管してよい情報は、「カード番号」「有効期限」「サービスコード」「カード会員名」の4つ。保管してはいけない情報は、「全磁気ストライプ」「CVC2/CVV/CID（カード裏面のサインパネルにある数字のうち、下3けたか4けたの数字）」「暗証番号」の3つ。 後者の3つは、どんな場合であろうと企業内に保管してはならず、これを「センシティブ認証データ」と呼ぶ。前者の4つは保管してもよい情報で、これらを保管している事業者がPCI DSSの対象となる。ただしこの場合も条件があり、「カード番号」を保管している際に始めて保護が要請される。「有効期限」「サービスコード」「カード会員名」も保護が必要とされているが、それは「カード番号」とひも付けられて保管されたときに限られる。言い換えれば、「有効期限」「サービスコード」「カード会員名」だけしか保管していないならば、PCI DSS準拠は不要なのだ。 とはいっても、カード情報を扱う以上、保管する内容・状況がどうであれセキュリティ対策の重要性に変わりはない。井原氏は、「これは全ブランドの共通方針だが」と前置きした上で、「すべてのカード情報を扱う事業者に対応してもらうことがゴールだと考えている」と述べている。 ■ カード取引件数に応じた3つの「審査方法」 では、PCI DSSの対応を進める事業者が、準拠の認定を受けるにはどうしたらよいのか。PCI DSSでは、「自己診断」「訪問審査」「脆弱性審査」という3つの審査方法が用意されている。準拠を目指す事業者は、このいずれか、もしくは複数の審査を受けて、自社の対応が十分であることを示さなければならない。 「自己診断」では、PCI DSSの各要件に対応できているか、アンケートに回答する。「訪問審査」では、QSAと呼ばれる企業が、事業者を訪問し、対応状況をオンサイトレビューによって審査。「脆弱性診断」では、ASVと呼ばれる企業が、脆弱性スキャンを行うことで審査を行う。 どの審査を受けるかは、審査を受ける側の事業者が任意に選ぶことはできず、年間のカード取引件数に応じて決定される。当然、件数が多いほど審査は厳しくなり、その条件は、「AIS（Account Information Security）」や「SDP（Site Data Protection）」などに定められている。 AISはVISAが、SDPはMasterCardが定めたもので、PCI DSS策定以前はそれぞれの独自セキュリティ基準を指すものだった。それぞれの基準がPCI DSSとして統一されてからは、バリデーションの条件を示すプログラムを指すものとなっている。詳細は以下の通りだ。
ここで1つ疑問が生じる。AISとSDPで条件が異なる点があるのだ。例えば、カード決済処理を代行するプロセサ向けの条件を見ると、AISで訪問審査が必須となるのは、年間取引件数が60万件以上の場合である。一方、SDPでは、件数を問わず訪問審査が求められる。 逆にホスティングサービス事業者を見ると、訪問審査が必須となるのは、AISでは60万件以上であるのに対し、SDPでは100万件以上の場合となっている。では、80万件の取引を行う事業者は、訪問審査を受ける必要があるのかないのか。 厳しい方が優先されるので、答えは「必要がある」なのだが、なぜこんなややこしいことになっているのか。そもそもPCI DSSが必要とされた理由の1つは、各ブランドの基準がバラバラでややこしかったからだ。この複雑さを解消するため、PCI DSSは誕生した。では、どうしてこのプログラムも統一されなかったのだろうか。PCI DSSには、各ブランドとは別に専門の運営団体も存在するというのに…。 実際、カード加盟店などからは、どのプログラムに従って審査を受ければよいのか、と迷う声があがっているという。また、認定を受けたことを各ブランドに報告することになっているが、報告フォームも異なるため、報告事務作業にも手間がかかってしまうのだ（このため、同作業の代行までしてくれる審査機関も存在する）。 この件について井原氏は、「バリデーションプログラムを統一しようという動きはなかった。だが、事業者からするとややこしいという指摘はごもっとも。ブランド各社がそれぞれに用意しているものだったため、PCI SSCが関与して統一するということはできずこのままになっているのだが、本来、バラバラである必要はない。現状は、複数ある中で一番条件の厳しいAISに合わせようというのが、デファクトスタンダード化しているのだが、各ブランド間で統一しようという努力は必要だと考えている」と述べている。今後の課題といったところだ。 ■ 準拠していれば情報流出時に「免責」 では、準拠することで、事業者にはどのようなメリットがあるのだろうか。まず、自社のショッピングサイトや店舗などに、認定ロゴを掲示すること可能だ。これにより、消費者へカードを使うことに対する安心感を与えることができる。 また、カード産業の仕組みでは、情報流出による金銭的被害が生じた際、「落ち度の所在などが加味されて、ケースバイケースでカード会社や加盟店などが賠償責任を負うケースがある。しかし、流出した時点で即座にPCI DSS完全準拠が確認されれば、基本的な考え方としては免責される」（井原氏）。 個人情報を流出した際に、対象の消費者へ500円～1000円ほどのプリペイドカードを送付するのも、一般的な対応策として根付いた感があるが、カード情報を流出して、不正にショッピングされるなどの被害が発生した場合の賠償額はおそらくこの比ではない。これが免責されるとなれば、やはり、金額的なメリットが大きいといえる。 なお、現在PCI DSS準拠が認定された企業としては、NTTデータ、DNP、三井住友カード、大和システム開発、楽天などがある。ビザ・ワールドワイドのWebサイトには、ほかにも多数の認定企業がリストされている。 以上でPCI DSSの骨子がお分かりいただけたかと思う。後編では、運営団体のPCI SSCの話に始まり、現在の日本・海外の普及状況などについて説明する。日本でも大きな波紋を起こしそうな法案、「割販法改正案」についても触れる。 ■ ＵＲＬ ビザ・ワールドワイド http://www.visa-asia.com/ap/jp/ ■ 関連記事 ・ VISAに聞く、実装レベルのカードセキュリティ基準「PCI DSS」【後編】（2008/10/24）
（ 川島 弘之 ）
|
