ＪＴＢ個人情報流出で分かった個人で「避けられないリスク」

i.JTBトラベル（るるぶトラベル）個人情報流出事件

ＪＴＢは２０１６年６月、個人情報が流出した可能性があると発表した。
ウィルスファイルが添付された標的型電子メールを、関連会社従業員が開封したことによりＰＣに遠隔操作アプリを仕掛けられ、結果、社内サーバーに保管していた約６７９万人分の個人情報を流出させる事態になった。

この事件で、私の個人情報も流出してしまった（可能性がある）と連絡を受けた。

今回、流出した個人情報は
---------------------
(1)氏名
(2)性別
(3)生年月日
(4)（本メールを受信された）メールアドレス
(5)住所
(6)郵便番号
(7)電話番号
---------------------
とされる。

その他、パスポート番号も流出したようだが、私は海外旅行ではこのサービスを利用していなかったので登録していなかった。
しかし漏れたとする(1)～(7)については全て正しい（私が現在も使っている）情報が流出してしまったようだ。メアドや電話番号はまだしも、変更の利かない氏名や生年月日の漏えいは正直痛い。

一般に「サーバーから流出」と聞けば、旅行予約時に登録した情報そのものだと想像する。だが、数度に渡るＪＴＢとのやり取りから実はこの事件、そう単純ではなかったことが分かってきた。

結果から言うと、私は事前に退会することで個人情報の削除を行っていた。にもかかわらず今回、私の情報が流出してしまったのは、ＪＴＢでは本来は残す必要の無かった個人情報を「誤って」別サーバーに保管していた為、そこをクラックされ漏えいさせてしまったというのだ。

ここでは説明のために、予約時に登録された氏名や住所を保管しておくサーバーを仮にＡ、分析や統計データを扱うサーバーをＢとする。

※報道では、感染したＰＣは６台、その他ＷＥＢサーバー、商品情報社内配信用の制御サーバーなど２台以上と報じられているが、ここでは単純にＡ、Ｂと表記し、それぞれの機能を意味するものではない。

予約時に登録した情報はサーバーＡに保管され旅行催行に使われる。今回、このサーバーＡからは情報は流出していない。

しかし、もう一つ「分析用に使うため」サーバーＢにも情報を保管しておく運用を行っていた。
サーバーＢは統計的に使うもので、本来であれば個人を特定できる情報は必要としないはずだが、ＪＴＢではサーバーＡからＢへ「個人情報」を含む形でデータを転送し保管していた。

今回の事件では、このサーバーＢから情報が漏えいしていたのだ。
※報道では「実績サーバーから個人情報が流出」とあるので、実績とはこの分析用データを意味すると思われる。

通常、分析、統計データとして扱う場合は、氏名などは不要で「旅行履歴のみ（行先方面、人数、男女比等)」だったそうだ。ところがこのサーバーＢにもＡと同様に氏名・住所・電話番号・生年月日等々、個人情報を転送し保管していたのだ。
本来はサーバーＢには「個人情報」を保管しない設計になっていたようだが、いつの頃からか誤って個人情報も保管されており、しかも事件が起きてから初めてそのことに気づいたという。

※個人的には、この「誤って保管」という説明には納得していない。なぜならばデータベースを設計をする際に不必要なテーブルを用意していなければ転送すらできないはずだ。従って「設計が誤っていた」または「大は小を兼ねる」から全部転送、というような安易な考え方があったと思われる。

今回、私がなぜここまで突っ込んで尋ねたかというと、当初電話相談窓口で聞いた話と、お客様相談センターへメールで尋ねた内容に矛盾を感じたからだ。

電話窓口のオペレーターは一般的な回答でしかないが、少なくとも私の個人情報の(1)～(7)を正確に把握しており、上述したように現役の今まだ使っている正しいデータを「流出した恐れのある」情報と伝えてきた。
にもかかわらず相談センターからのメールでは「現在、○○様の個人情報は既に削除されている為、保管していない」との回答だ。

ではなぜ「流出の恐れのあるお客様」として連絡があったのか、そもそも流出したのかしていないのか、数度に渡りセンターとメールのやり取りをおこない矛盾点を問い正した。

当初の私の質問は「個人情報のデータを削除してもらうには」というものだった。

しかしメールでの回答は、「もう既に削除されており保管していない」そして「今回の事件で、確認用ツールの為に復活させたデータのみ保管」しており「それ自体を削除すれば（事件の）対象者かどうかも分からなくなる」との返答だった。

ではどのタイミングで誰が私の情報を削除していたのか。

この答えは「自分で退会手続きをして削除していた」という事になる。

以前に利用したことがあったものの、最近ではるるぶトラベル自体は全く使っていなかった事と、2013年に「じゃらん」（リクルート系）で流出事件があったタイミングで、自分で退会処理をし登録情報を削除していたのだ。

正確には、時系列に並べると
2012年に「るるぶトラベル会員」で旅行の予約
2013年8月頃　退会（「じゃらん」ID流出事件の際に自分で手続き）
2014年9月頃　退会後１３か月が経過し個人情報は自動削除

2016年3月頃～ ＪＴＢより個人情報流出の可能性
ということになる。

るるぶトラベル退会後、１３か月を経過すると「自動でデータ削除」というのは、相談センターから教えてもらった。２０１４年９月頃の時点で私の個人データは既に消去されていたのだ。だがしかし、それとは別に「分析用サーバーＢ」にはまだ個人情報が残されていた。

今回の事件では、「本来は削除されていたはずの個人データ」が「別のサーバーに残っており」そこをクラックされ情報が流出した、という流れだと判明した。

ＪＴＢは、個人情報保護に関するJIS Q 15001認証を得ている。当然、設計や監査についても重要な事項として規定されているし、それらが機能していれば少なくても私の場合は個人情報が流出することは無かったはずだ。

大手とはいえ、いつどこから個人情報が洩れてもおかしくない時代。使わなくなったサービスは退会したり、ＩＤを整理したりとリスク管理している人も多いと思う。
しかし、会員規約や個人情報保護方針に則り自分のデータを削除してもらったとしても、今回のように思わぬ形で情報が残っていれば簡単に流出してしまうことになる。
もし仮に、退会以降に私が「個人情報の開示」を求めていたとしても、正規のデータベースには私の情報は残っておらず「該当なし」と返答されたことだろう。

しかし、想定していない形でデータが他のサーバーに残っていれば、存在していないデータとしてセキュリティ面でより脆弱性の高い形で半永久的にリスクに晒されたままになる。
実際、今回のＪＴＢ流出事件では個人情報を管理していたサーバーはハッキングされず（できず？）、実績サーバー（分析用データ）から個人情報ファイルを抜き出されてしまった訳だ。

また今回の事件では、異常な通信ログは監視していたが「正常なログ」の一部は保管されていなかったそうだ。悪意あるものが、遠隔操作を使い内部から「正常を装って転送」した場合、異常とは判別がつかないようだ。

情報は参照はされたが転送は確認できない、したがって「流出した可能性」と発表している。
だが実際は確実にファイル転送され、元ファイルを削除し発覚を遅らせ、いずれかのタイミングでまた侵入を試みるつもりだったのであろう。
※実際、サーバー内に拡張子のない大容量のＣＳＶファイルが（犯人によって）作成された為、「ディスクの容量不足エラー」が発せられたにもかかわらず、管理者は業務に不要と判断し削除しただけだった。このことからも管理者はＬＡＮ内を自由に動き回る犯人の存在に全く気付いていなかったと思われる。

今や標的型ウィルスメールを完璧に見破るのは難しい、だからこそ突破されても持ち出されないシステム、被害が拡大しない運用が大切である。
にもかかわらず、社内運用ルールから逸脱し、不必要な個人データが保管されていた事と、そしてそれを発見できなかったシステム監査の罪は、最初にクリックしてしまった社員より、もっと重いものだと言える。

今回のこの事件で流出してしまった個人情報、今後どのような実害がでるかは分からない。また実害の判定、流出事件との関連、原因の特定は事実上不可能だろう。

ＪＴＢに限らず、システムを運用する企業は、少なくとも個人情報保護方針やポリシーに掲げる看板通りに対処して欲しい。
ユーザーが退会、情報を開示、削除、その手続き通りの対応をしてもらえなければ、もう自衛することすらできなくなってしまうのだから。


２０１６年７月２２日