JINSオンラインショップで個人情報漏洩!クレジット情報も流出
JINSと言えば、低価格でデザイン性の高いメガネを販売するメガネチェーンで、最近では海外への出店やコンタクトレンズ市場への参入など、ビジネス展開がとりわけ注目される企業です。
そんなJINSですが、2013年に自社が運営するオンラインショップ「JINS ONLINE SHOP」に不正アクセスを受け、深刻な個人情報漏洩事故を起こしています。
ここでは、この事件の内容と経緯を順を追って見ていきます。
個人情報漏洩の内容と規模は?
JINSが発表した「不正アクセス(JINSオンラインショップ)に関する調査結果(最終報告)」によると、漏洩の可能性がある個人情報はオンラインショップに登録された顧客情報2,059件で、その中にはクレジットカードの決済情報が含まれていたということです。
さらに、事故が初回発表された3月15日から最終報告時点までにクレジットカードの不正利用が20件申告され、申告がない被害も含めると、最大被害額は305万3,000円であるとの見方を示しました。
原因は基盤プログラムの脆弱性
JINSはオンラインショップの構築に「Apache Struts 2(以下、Struts)」と言うミドルウェアを使用していました。Strutsとは、WEBアプリケーションを作成する際に使用するフレームワークで、汎用的なプログラムの機能をパッケージにしたものです。
JINS側の説明によると、外部の者がこのStrutsの脆弱性を利用し、オンラインショップのシステムにアクセスし、不正プログラムを仕掛けることにより、個人情報の窃取を行ったということです。
また、オンラインショップで使用されていたStrutsは旧バージョンで、以前から脆弱性が報告されていたものであったと発表しました。
個人情報が流出した経緯は?
個人情報流出の経緯とJINS側の動きを、時系列でまとめると以下のようになります。
3月6日
JINSのウェブサイトに不正プログラムが埋め込まれ、クレジット決済情報が外部に送信され始める。
3月14日
- JINSオンラインショップのサーバーに不正アクセスの動きがあることを検知する。
- クレジット情報が流出していることを想定のうえ、対策本部を設置する。
- 緊急措置としてJINSオンラインショップを閉鎖する。
事件発覚後未明
- クレジット決済情報が流出した可能性があることをクレジットカード会社に通知する。
- 警視庁・警察署に対して、当該事件についての捜査を要請する。
3月15日
JINSは、オンラインショップへの不正アクセスにより、クレジットカード情報を含む個人情報が1万2,036人分流出した可能性があると発表。
3月18日
外部専門家で構成される「情報漏えい事故調査委員会」を立ち上げ、専門的知見からの調査を依頼する。
~4月8日
- JINS対策本部は、外部機関 Payment Card Forensics(以下、PCF)に事故についての調査を依頼する。
- PCFから事故の原因と影響範囲について、調査結果の報告を受ける。
4月9日
JINSは、PCFの調査結果を元に中間報告を行い、その中で、当初流出した可能性がある個人情報の件数を1万2,036人分としていたのを修正し、2,059人分にとどまると発表する。
また、当初流出が想定された1万2,036人全員をケアの対象とし、お詫びとしてQUOカード1,000円分を配布し、クレジットカード再発行の手数料を負担することを報告する。
4月22日
当該不正アクセスについての被害届を警察署に提出する。
5月1日
不正アクセスでの個人情報漏洩について、最終報告を発表する。
JINSの対応とその問題点は?
不正アクセスの検知について
まず問題点として気になるのが、不正アクセスが発覚するまでの時間です。
3月6日にサーバーに不正プログラムが仕込まれた後、即座に顧客情報の外部への送信が始まったと仮定すると、約1週間もの期間その状況が続いたということになります。
公式発表の再発防止策では触れられていませんが、状況から考え、不正アクセスをより早く検知するための施策は必須ではないかと思います。
情報公開と対応について
不正アクセスの発覚から発表までのJINS側の対応は迅速だったと言えます。
意図的にクレジット情報が窃取されている状況において、事件の全容解明を待たずに即時公表したことは、二次被害を防止するための適切な措置だったと思います。
しかしながら、事件発表後に前述のように20件の不正利用が報告されたことから、顧客に対して事故の周知が徹底されていたのか、という疑問は残ります。
セキュリティの強化について
JINSは再発防止策として、クレジット決済の国際セキュリティ規格「PCI DSS」に適合したうえ、クレジットカード情報が自社サーバーを経由しないシステムを採用すると発表しました。
しかしながら、一番最初の原因になったStrutsの脆弱性対策については触れられておらず、JINSが行う再発防止策では今回と同様の事象には有効性が期待できるものの、Strutsの脆弱性を持ったままサイトが運営されれば、別のセキュリティインシデントが起る可能性は否定できないと思います。
一般的にWEBフレームワークは、プログラムの基盤に深く関係しますので、脆弱性の解消にはサイトの全面改修が必要になるなど、費用と時間がかかるうえ、長期のサイト休止も想定されます。
そういったことから、機会費用やコストの観点で、現状の基盤を維持しながら、セキュリティを相対的にアップするという判断をしたのかも知れません。
ただ、顧客情報の安全を最優先に考えるのであれば、システムの脆弱性については踏み込んだ対策が必要になると思います。