JTB個人情報漏えい事故、データを守るのは暗号化

f:id:PentaSecurity:20170412153344j:plain

 

ジェイティービーJTB)から約793万人の個人情報の流出が疑われる事故が発生した。事故の経緯は以下の通りである

 

JTB個人情報漏えい事故の経緯

2016年3月15日、旅行商品のインターネット販売を行う子会社であるi.JTBに問題のメールが送られてきた。約250人のオペレーター体制で顧客に対応していて、既存の取引先の社名でのお問い合わせメールであり、通常の業務処理を行った。メールに添付されていた圧縮ファイルの中にはPDF形式の電子航空券(eチケット)が入っており、圧縮を解除しファイルを開いたが、航空券には申請者の名前が書かれていなかった点と、本文にもこれといった内容がなかったため、「無効」メールに分類し、処理を終えた。

 

このオペレーターのコンピュータは、この時から添付ファイルに仕組まれていた内部ネットワーク侵入用マルウェアに感染されていたが、これを検出するウイルス対策ソフトは、その役割を果たせなかった。

 

3月19日、社内Webサーバから外部への異常な通信が発覚、3月19日、当のWebサーバを一旦物理的に分離した後、問題になった回線を遮断すべく、ブラックリストに登録するなどの措置を行った。その後も、異常な通信はまた発生していた。

 

4月1日、顧客向けの広報メールやアンケート調査などに使用される個人情報データを保存する「実績データベース」内部に外部からの侵入によりCSV(Comma-Separated Values:データフィールドをコンマで区分したテキストデータファイル、主にお互いに互換されないフォーマットを使用するプログラム同士で資料を受け渡すとき使用される)ファイルが生成され、削除された痕跡が発見された。生成ルートは不明、削除命令は商品情報などの情報を社内の各サーバーに転送する制御サーバにより実行されたとみられる。

 

5月13日、生成された後、すぐ削除されたCSVファイルの復元中に該当ファイル内部に顧客の個人情報が含まれていたことが発見された。6月10日、問題のファイルを復元してみると、約793万人の個人情報が漏洩された可能性が確認された。そして6月14日、JTB社は、顧客の個人情報漏えい可能性をメディアに公表した。事故が発生した以後、状況分析までかかった時間がとても長いとは思うが、とにかく隠蔽せずに、公表したことは、ほめられるものである。

 

事故発生後、論争の空しさ

JTBの発表後、とても騒々しくなった。実質上日本は深刻な情報セキュリティの死角地帯と言っても過言ではない。他の先進国に比べ情報セキュリティ関連法律は、極端に言うと、あまりにも不十分である。「平和ボケしているからね」と日本のお客様からよく聞く。今回のような大規模の情報漏えい事件が発生すると、その原因の分析やセキュリティ対策のお粗末さを非難するに走り、その論争で盛り上がる。

 

その一部だが、次のようなことが議論されているようだ。

  • 勤務者のセキュリティ意識が希薄
  • 情報セキュリティの責任者が不在で、セキュリティポリシーが甘い
  • データベースに対するセキュリティ対策が不十分
  • データ暗号化をしなかった

これは、セキュリティ関連問題で常に議論される話である。すべて正しい。もう情報漏えいされてしまってからには、議論することすら空しさを感じてしまうが、ここからどのような実質的な対策を見出していくのかは、勉強にあるのである。

 

「勤務者のセキュリティ意識の希薄」だが、もちろん、最も言いやすい原因ではあるが、セキュリティ意識が高くても、事故は起こる。その確率を下げることはできるが。そして、現実問題として大きな大企業では情報セキュリティの専門部隊と責任者を別途設置し運用することができるかもしれないが、みんなができるわけではないのだ。

 

オペレーターの250人が一日処理しているメールは何通あるのだろうか。「不明な送信先からのメールは開けない」といった社内ルールがあったとしても既存のお客様を装ったメールであれば、通常の業務として処理をする。JTBも「問題のメールを処理した人の過ちとは思えない」と話す。これは責任回避ではなく、事実がそうであり、セキュリティ意識が希薄とは違う気がする。

 

JTBの発表内容からセキュリティ対策自体、不十分とは言い難い。通常の対策は行っていた。事故当時も問題になった「実績データベース」に関するセキュリティ対策の甘さはあったものの、普通にセキュリティ措置を行っていたとみられる。実績データベースのデータを暗号化しなかったということは、痛いんだが、データ暗号化を実施していない会社は、実に結構あるものだ。マイナンバー制度の施行後この半年、個人情報を保管している企業でどれほど、暗号化を実施しているんだろうか。だから今回の事故は、個人情報を持っている企業なら、どこにでも起こり得ることであり、JTBの肩を持つわけではないが、「運が悪かった」とも言えるだろう。事故後はもう遅いが、今後の対策はより具体的かつ、現実的でなければならない。

 

内部ネットワーク侵入は、実はいとも簡単に起きる

言うまでもなく今回の問題は、極端にいえばデータを暗号化しなかったことに尽きる。データ暗号化さえすりゃ、今回の問題は起こらなかったことを言っているわけではない。まず、内部ネットワークへの侵入だ。ありとあらゆる方法でいとも簡単に内部ネットワークに侵入できるわけで、情報漏え事故はいつ、どこでも起こり得るのだ。打つ手がないとでも思ってしまうかもしれないが、セキュリティ対策は、事故発生の確率を減らすための日々の努力を意味するということを理解して頂きたい。

 

この言葉を覚えて頂きたい。「内部ネットワーク侵入は、必ず起こる」

 

悪意のある者は、忍者のように忍び込んでくるために、知らないうちにやられるわけで、しかもやられたのかも認識できずいるケースも多々ある。ここで、セキュリティ対策として、暗号化の出番になる。暗号化を実施していなかったことが今回の漏えい問題の至らないところである。その故に名前や性別、生年月日、メールアドレス、住所、電話番号、パスポート番号、パスポート取得日などが含まれた、なんと793万人分の個人情報がこっそり抜かれたしまったのだ。データ暗号化を実施しておいたならば、最悪の結果にまでは至らなかったのではと、私は思う。

 

でも、ハッカーがルート(Root)の権限をどうやって奪取できたかは不明らしい。この点も、極めて重要だ。DBAにスーパーAdminの権限を持たしているのであれば、ゲームオーバーである。したがって、暗号化、そしてDBAとセキュリティ管理者の権限分離は同時に考慮すべきものである。もちろん暗号化には適切な鍵管理は必須である。

 

情報社会、その利便性とリスク

JTBは、「これから専務取締役をトップとするITのセキュリティの専任統括部門を設置し、グループ全体のITセキュリティの更なる向上に努める」とした。本件の発生経緯と事故後の対応から一応は、応援したくなる気持ちでいるが、最大手のJTBの会社イメージはガタ落ちし、失った顧客の信頼を回復するまでは、かなりの時間はかかるでしょう。

 

今年は、国民背番号制度、マイナンバーの元年でもある。マイナンバーの利用領域は、制限された部門となっているが、今後ありとあらゆるサービスと連携することで、無数の個人情報と紐づいていくことになる。これは、マイナンバー制度施行の目的でもある社会構造改善による利便性につながるだろうけど、その分のリスクも同時に抱え込むことになるのだ。個人情報漏えいを懸念していた、まさしくこの時期に、行った今回の大規模の漏えい事件である故に、その余波は大きいのだ。痛い分、予防接種だと考え、これからの情報セキュリティについて、社会全体で真剣に考える良いチャンスではないか。予防接種は、効くものである。

 

データベース暗号化そりゅション「D'Amo

 

製品に関するお問い合わせ

E-Mail : japan@pentasecurity.com / TEL : 03-5361-8201