現在地

「非保持化」対応後の加盟店に求められるセキュリティ対策

はじめに

2018年6月の改正割賦販売法施行に伴い、クレジット加盟店にもクレジットカード情報(以下、カード情報)を適切に管理し、不正利用を防止することが義務化されました。カード情報をいかに管理し、不正利用を防止するかについての実務指針として「クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画」[1](以下、「実行計画」)がクレジット取引セキュリティ対策協議会により策定され、これに基づき、対策が進められています。
一方、「実行計画」に基づいて「非保持化」対応したEC加盟店であっても、情報漏えい事故が発生しています。
本コラムでは、「非保持化」対応後の加盟店、特にEC加盟店を中心に求められるセキュリティ対策について考察します。

「実行計画」が加盟店に対して求めていること

まず、クレジットカード情報を保護するために、「実行計画」が加盟店に対して求めていることをおさらいしましょう。
クレジット加盟店に対するカード情報保護義務化の背景には、情報漏えい対策が不十分な加盟店を狙った不正アクセスにより、カード情報漏えい被害が拡大し、窃取されたカード情報を盗用した不正利用被害が増加し続けているという実態があります。
そのため、2019年版の「実行計画」では、「クレジットカード情報保護対策」として、加盟店では、①カード情報の「非保持化」またはPCI DSS準拠、および②新たな脅威への警戒とセキュリティ対策への継続的な取組を行うという、カード情報を盗らせないための対策が求められています(ここでは、便宜的に①、②と採番しました)。ここからは、対策①、②についての加盟店の現状について考察してみましょう。

対策①についての多くの理解は

  • 加盟店は、カード情報の非保持化が基本であり、それができない(カード情報を取り扱わざるを得ない)場合はPCI DSSに準拠する
  • 非保持化が実現されていれば、PCI DSS準拠は求められない

であり、多くの加盟店は、非保持化に向けて対策が進められているというのが実態であると考えられます。
そもそもカード情報を保持していない加盟店は、保持している加盟店よりも、カード情報を窃取されるリスクは低いといえるでしょう。実際に、これまでのEC加盟店での大規模な被害は、SQLインジェクションの脆弱性などWebアプリケーションの脆弱性やシステムに残っていた脆弱性を悪用され、データベース上に保存されていたカード情報が漏えいすることにより発生することが一般的でした。その点で、カード情報を自社で保有する機器・ネットワークにカード情報を「保存」「処理」「通過」しないという「非保持化」は、不正アクセスによる情報漏えい被害を最小限に抑える上で、有効な考え方であるといえます。

また、PCI DSSは、準拠後であっても、継続的なテストや監視といった運用が求められており、それを負担と考える加盟店にとって、「非保持化」を実現すればPCI DSS準拠までは求められない、という考え方は魅力的に映ったのかもしれません。

一方、対策②の「セキュリティ対策への継続的な取組」は、PCI DSSでは、上記の継続的な運用や、BAU(Business As Usual)のベストプラクティス・要件として含まれた対策[2]であり、PCI DSS準拠を維持するためには必要ですが、これまでの「実行計画」で強調されていたとは言えません。そのため、「非保持化」を実現した加盟店では、あまり意識されていなかったかもしれません。しかし「非保持化」を実現した加盟店でも情報漏えいが発生していることもあり、2019年版の「実行計画」では、「セキュリティ対策への継続的な取組」という対策の考え方が強調されています。

以上を整理すると、「実行計画」が「クレジット情報保護対策」として加盟店に求めているのは、カード情報の保持・非保持によらず、適切なセキュリティ措置を執り、その状態を維持することであるといえます。

「新たな脅威への警戒とセキュリティ対策への継続的な取組」として考えられる対応とは

「実行計画」では、非対面取引を行う加盟店は、2018年3月末までに対策①を実現することが求められていました。このうち、EC加盟店が「非保持化」を実現する方法として、「リダイレクト(リンク)型」または「JavaScript型(トークン型)」の決済システムを導入することが挙げられています。
一方、上記の決済システムの導入だけでは情報漏えい対策として不十分ではないか、ということはセキュリティ専門家の間では早くから指摘されていました。実際に、これらの決済システムを導入したEC加盟店からのカード情報漏えいが発生しています。そのため、「実行計画」では、「非保持化」を実現した加盟店においても、以下に対するセキュリティレベルの向上が重要である、と指摘しています。

  • ECサイトの脆弱性や設定の不備
  • 委託先事業者が提供する決済ソリューション(ショッピングカート機能等)の脆弱性など
  • ウェブサイト開発・運用段階での不十分なセキュリティ対応
  • ECサイトの改ざん、偽画面への誘導など不正犯の巧妙化した新たな攻撃手口

最後の点は、これまで表面化されにくかった「新たな脅威」であり、上の三点については、「継続的な取組」が求められるセキュリティ対策、上記の対策②の一例といえるかもしれません。では、これらの点についての対策として、どのようなことが求められるでしょうか。

「ECサイトの脆弱性や設定の不備」への対策

この対策には、サイトを構成しているサーバーやネットワークの要塞化、およびその維持が求められます。セキュアな状態が維持できていることを確認するために、定期的および変更(アプリケーション改修、OSやソフトウェアのバージョンアップなど)時の脆弱性スキャンやペネトレーションテストを実施し、発見された脆弱性や設定の不備を修正することが重要です。また、発見された脆弱性への不正アクセスによる影響を抑えるための暫定的な対策として、不正侵入防止システムウェブアプリケーションファイアーウォールなどによる不正アクセスの遮断も有効です。

「委託先事業者が提供する決済ソリューションの脆弱性など」への対策

この対策には、委託先事業者がPCI DSSに準拠し、継続的に維持しているか、また、ショッピングカート機能のようにさまざまなEC加盟店で広く利用される決済アプリケーション、決済ソフトウェアがPA-DSSSecure Software Standard[3]のような基準に準拠し、継続的に維持しているかを(できれば、契約前に)確認することが重要です。もし、それが維持できていない場合は準拠維持を求め、対応を拒まれるような場合は他の事業者への切り替えを検討することも望まれます。 なお、PCI DSSに準拠した委託先の、セキュリティ基準を満たしたソフトウェアを使用している場合であっても、それに安心せず、自社の管理範囲における脆弱性対策・設定不備に対する対応も併せて採ることが重要です。決済ソリューションやソフトウェアを利用するうえで、追加で採るべき対策がないかどうか、委託先事業者にご確認ください。

「ウェブサイト開発・運用段階での不十分なセキュリティ対応」への対策

この対策としては、自社のサイトが要件定義、設計、開発、テスト、運用、廃棄といったライフサイクルを通じて、セキュリティを考慮したものとなっているか、変更管理を適切に行っているか、システム管理者・運用者の適切な認証・認可が実施されているか、といった観点で考慮漏れのないシステム開発・運用を行うことが重要です。
使用しているOSやソフトウェアの要塞化を実施したうえで、脆弱性情報を定期的に収集・確認し、リスクを考慮したうえで修正プログラムを適用することは、脆弱性を残さないために必要な運用です。
また、ウェブアプリケーションを開発する段階で脆弱性を作りこんでしまわないように、OWASPなどで紹介されている脆弱性を回避するように開発者教育を実施し、開発したソースコードに対するレビューを行うことが望まれます。 さらに、本番・運用環境と、開発・テスト環境やOA環境とを分離し、セキュリティレベルの低い環境から不正アクセスを受けないようにアクセスコントロールを行うことも重要です。本番環境の管理には多要素認証を導入することも有効です。
そのうえで、適切にログを取得し、定期的にレビューすることで、異常な兆候、不正アクセスの兆候を可能な限り早めに気づき、対応できるように準備しておくことが肝要です。

「ECサイトの改ざん、偽画面への誘導など不正犯の巧妙化した新たな攻撃手口」への対策

この対策としては、新しい攻撃手法の情報を継続的に入手し、その攻撃手法への対策が取られているか、リスクアセスメントを実施し、必要に応じて対応することが求められます。 例えば、ECサイトの改ざんに対しては、改ざん検知システムによる確認を定期的に行い、改ざんに備えることが考えられます。ウェブアプリケーションを構成するスクリプトが書き換えられていないか、覚えのないスクリプトが追加されていないか、といった観点に加え、OSのバイナリファイル、設定ファイルのような頻繁に変更の行われないファイルが変更されていないか、バックドアが設置されていないか、という観点でも確認することが重要です。 なお、DMZのウェブサーバーや、ウェブアプリケーションの確認頻度を高くし、保護された内部ネットワーク内のシステムの、対象ファイルの確認頻度は前者よりも抑える(週次程度)など、改ざん検知の対象ファイルのリスクに応じて確認頻度を変えることも、運用コストを抑える上で有効な場合があります。

それでも盗られたかもしれないという場合に

EC加盟店がカード情報を漏えいした場合、カード会社や決済代行会社からの指摘を受けて、と報道されることが一般的です。一方、外部からの通報による対応と、内部での発見による対応では、その後の対応を進めやすいのはどちらか明白でしょう。
異常な兆候、不正アクセスの兆候を迅速に把握し、情報漏えい被害の影響を最小限にするための第一歩は、適切にログを取得し、そのレビューをリアルタイム(自動化による)、もしくは短い間隔で実施することです。自社のみでそれを実現できないと判断される場合は、マネージドセキュリティサービスプロバイダー(Managed Security Service Provider, MSSP)を利用することも有効です。
そのうえで、異常な兆候、不正アクセスの兆候を把握でき、情報漏えいが発生した可能性があると判断された場合は、あらかじめ準備したインシデント対応計画に基づき、対応することが求められます。インシデント対応計画として、カード会社(アクワイアラ)および/もしくは決済代行事業者、監督官庁への報告とそれらからの指示に基づく対応、フォレンジックへの対応、原因究明後の対策、公表、事後対応と事業再開などの手順を定めておくことが望まれます。

以上のように、「非保持化」を実現した加盟店であっても、セキュアな状態で事業を継続するためには、自社の環境におけるリスクを考慮し、運用のPDCAを維持し続けることが必要となります。そうした企業戦略の決定には、必然的に経営層の関与・判断が必要となるという点をあらかじめ意識しておく必要があるでしょう[4]

さいごに

本コラムでは、「非保持化」を実現したEC加盟店を中心に、「実行計画」に対応した加盟店に求められるセキュリティ対策について考察してきました。
継続的に行うべき対応として「実行計画」でも掲げられ、上記した対策②は、PCI DSSには取り入れられている考え方であると記載しました。しかし、BAUとしてのPCI DSSという考え方は、比較的新しく取り入れられた考え方です。これは、PCI DSSに準拠した事業体であっても、その状態を維持できず、カード情報漏えい事故の発生が相次いだことから、漏えい事故を発生させないために、また事故が発生しても被害を最小限に留めるためのベストプラクティスとして、PCI DSS version 3.0から導入された考え方です。さらに、PCI DSS version 3.2 ではその一部が、要件化されています。こうした現状を考慮した継続した改善は、「非保持化」を実現した加盟店でも求められる対応であるといえます。
セキュリティ対策はゴールではなく、「非保持化」やPCI DSS準拠はカード情報保護のスタート地点でしかありません。息切れせずに走り続けるために、自社にとってどのような走り方が望ましいのか、見直しと改善を続けていただくことが期待されます。

Writer Profile

セキュリティ事業部
セキュリティコンサルティング担当 シニアコンサルタント
羽生 千亜紀(CISSP、CISA、CRISC、QSA、PA-QSA、博士(理学))

参考