事故＞【メルカリ】個人情報漏洩の顛末 *私個人的な見解です*
こんばん〇 !! 人体重-18Kです。今回の【メルカリ】個人情報漏洩に見事なまでに引っ掛かってしまった当事者の１人として、後の世に伝えるべく、ここに転載・記させて頂きたいと思います。「お知らせ４通 ＆ 下記の掲げるWEB上での見解」で“幕引き”を図りたいようです。当事者以外にはよく分からない話だと思いますので、私なりの推測を交えて語ってみたいと思います。
‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥
tech.mercari.com ※こういうのはいずれ消されてしまうため、以下、転載させて頂きます。
CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして
本日コーポレートサイトでお知らせした通り、Web版のメルカリにおいて一部のお客さまの個人情報が他者から閲覧できる状態になっていたことが判明しました。原因はすでに判明して修正が完了しております。また、個人情報を閲覧された可能性のあるお客さまには、メルカリ事務局より、メルカリ内の個別メッセージにてご連絡させていただきました。 お客さまの大切な個人情報をお預かりしているにも関わらず、このような事態に至り、深くお詫びを申し上げます。
本エントリでは技術的観点から詳細をお伝えさせていただきます。
概要
メルカリWeb版のコンテンツキャッシュをしているCDNのプロバイダ切り替えを行いました。
その際本来キャッシュされるべきでない情報がCDN側にキャッシュされてしまい、該当時間帯にアクセスしたお客さまに、他のお客さまの情報が表示されておりました。
お客さまからのお問い合わせを受け、問題認識後、即時に設定の切り戻しとプロバイダ側のキャッシュの削除を行いました。 これにより状況は収束し、現在は通常にサービスを提供しております。対象はメルカリWeb版の JP 及び US のみであり、iOS・Androidアプリ版には影響ありません。
原因
メルカリWeb版へのお客さまからのリクエストはCDNプロバイダから、メルカリが管理するnginx Webサーバを介してアプリケーションサーバに到達します。
メルカリではお客さまのメルカリでの体験をよりよくするため、このnginxサーバにて、
location / {
# disable cache
expires -1;
proxy_pass http://127.0.0.1:80;
}
とキャッシュを防ぐ設定を追加しております。本設定を反映することで、お客さまのブラウザはサーバへ毎回問い合わせを行い、画面が更新されないなどの意図しない動作を防ぐようになっております。
具体的には上記の設定をおこなうと、サーバからのレスポンスヘッダに
Cache-Control: no-cache Expires: Thu, 22 Jun 2017 08:58:21 GMT (アクセスの1秒前の時間)
と送信されます。まず、Expiresヘッダがアクセスの時間より過去の時間となるため、ブラウザのキャッシュはすぐに無効になります。またno-cacheオプションによりキャッシュ使用時にサーバに対して問い合わせを行うようになり*1、新しいコンテンツが常に表示されるようになります。この手法はメルカリに限らず広く用いられております。
切り替え前のCDNプロバイダはCache-Controlヘッダではなく、CDNの設定でキャッシュを制御することで、メルカリWeb版においては全くキャッシュが行われないようにしていました。
切り替え後のCDNプロバイダでは、Cache-Controlヘッダでキャッシュの制御が可能であるため(この制御はnginxの設定により行います)、CDNの設定によるキャッシュ無効化は行わず切り替えを行いました。切替前の検証では手元のマシンのhostsファイルを編集し、数回アクセスを行い問題なく動作していることを確認しました。
問題発覚後に切り替え後CDNのキャッシュの仕様を再度確認したところ、キャッシュをしないのは
Cache-Control: private
が含まれている場合のみとわかりました。Expiresヘッダが過去の日付であっても、Cache-Controlヘッダが存在している場合は利用されないという仕様になっておりました。このためCDNのサーバ上にお客さまの情報が含まれたキャッシュが作成され、別のお客さまへ配信される事態に至りました。
影響
本来お客さまごとに異なる内容が表示されるはずが、CDNにてキャッシュされたことにより同一の内容が表示されました。 これによりお客さまの個人情報(配送先住所、メールアドレス)などが、本人以外に表示されました。
意図せずお客さま本人以外に表示された可能性がある情報と影響をうけたお客さまは以下の通りです。*2
| 影響範囲 | アクセス数 |
|---|---|
| 名前・住所・メールアドレス・電話番号 （※登録しているお客さまのみ） |
459名 |
| 銀行口座情報、クレジットカードの下4桁と有効期限 （※登録しているお客さまのみ） |
1855名 |
| 購入・出品履歴 | 22458名 |
| ポイント・売上金、お知らせ、やることリスト | 53816名 |
※ ポイント・売上金は全ページに表示されているため、影響あったお客様と同数になっています。
追記 (6/23 16:00)
調査の結果、新たに判明した事項につきまして、詳細はコーポレートサイトのお知らせをご覧ください。
対応
問題の認識後、以下の対応を行いました。
再発防止について
外形監視を利用した、CDNによる意図しないキャッシュを早期に検知できる仕組みを導入します。
今回はこのような事態に至り、深くお詫び申し上げます。
‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥
技術的な見解は上記の通りなのだと思われます。私は古～い制御系の元ＳＥでした。あれからかなり技術も進歩を遂げており、ハード／ソフト共に目にしたこともない品々も沢山あるとは思います（『サーバー』なんて単語が一般的ではない時代です。ホストコンピューターと端末って感じでしたね。そうそう『ネットワークステーション』なんて呼び方が今やオリンピック会場となる【晴海】の展示会で披露されておりました・笑）。
しかし“基本的には一緒”のはずです。“入り口があって・出口がある”。今の『Windows』などのＯＳ（オペレーティング・システム）を「マルチ・タスク」などと呼び、同時に異なる処理・ソフトを動かしているように見えますが、あれは“見せかけている”に過ぎません。基本は１つの『ＣＰＵ』（セントラル・プロセッシング・ユニットの略で「中央処理装置」のこと）に１つずつ命令を与えています。ＡさんとＢさんを同時に相手をする時に、Ａさんの話を少し訊いて・Ｂさんの話を少し訊く。そんな動作を交互に・高速に繰り返しているため、人間の目には同時進行しているかのように見えているだけです。 あっ、話に付いて来られてますか？(^o^;)
最近はさすがに高度な機能を処理するのに１つの『CPU』だけでは足りないので、２つ・４つ・８つ？と本来１つであることが理想であるべき「中央処理装置」を複数持たせて処理するようになったようです（もうとっくに現役を離れてしまっているため、事の経緯をリアルに存じ上げてはおりません）。これを簡単に言い表すと、混雑している【役所】で同じ受付処理（身分証明発行など）をする窓口が複数設けられていることをイメージして頂けると分かりやすいかと思います。
ここでポイントとなるのが「受付処理は複数」設けられてはおりますが、実際に「管理・記帳するのは１つ」であるべき点です。今回の【メルカリ】事件簿とは少し経緯が違うのですが、ここでは“処理がきちんと行われていなかった”という点を覚えておいて下さい。
‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥
話が長くなりますので端折りますが(苦笑)、ざっくり言うと今回の問題点は【公共機関】で信号制御の試験の確認もロクに行わずに・現場でいきなり登用しちゃったようなものだったんです。
分かりやすく例えると、電車で次の駅のホームに他の電車が停車したままなら赤信号を灯して待機するでしょ？ それが待機させずに出発進行させちゃって・駅のホームに電車が2台入っちゃった。 あとはバスで終着間近で他路線のバスと連なるシーンをよく見かけるじゃないですか？ それでも順番守って進みますよね。それをここでは並列走行しちゃって、前を進んでいたバスの車両内の乗客の顔が真横から覗けてしまったみたいなことができちゃってたわけです。
もう１例挙げると、カラオケ店で満室で待機していたとしましょう。で、空きが出たので案内されて入室してみたら前の人の貴重品が残っていた。前の人は貴重品をフロントに預けていたはずなのに実際には気付かぬ内に貴重品を持参して入室させられていた。気付いていないから貴重品を置きっぱなしにしたまま。それはきちんと清掃するので問題はないとカラオケ店側は考えていた。だが上手く清掃・後片付けができずに貴重品を残してしまった。次に案内されて入室した方がそれを見つけちゃった！ というのが今回の顛末のようです。
『個人情報』が金庫に預けられてなく、常に持参して自ら巡回・お買い物をしていたということです。コレを“愚か者”と言わずしてどうするのか。マッチじゃなくても普通は吼えて熱唱、ゲンコツものだと私は思いますけどね。「快適なアクセスのために荷物は常に持ち歩きさせていた」というのが今回問題となった仕様のようです。ハイ。
もう一度言いましょう。ホームに前の電車が待機して・まだ出発していないのに（情報をまだクリアできていない）次の電車が入ってきて衝突した（前の情報が閲覧できてしまった）という、より具体的に言えば「タイム・ラグ」ならぬ「ジャスト・タイム」重なり合ってしまったというお話しです。重なり合ったその時に住所欄などを見たらば自分のではなく・前にその場所を閲覧していた人のデータが残っていて覗けちゃった！という感じのようです。
ブツブツとイライラしながら推測していたわけですが、この「タイム・ラグ」時間調整というワザを私も以前行ったことがあることを思い出しました。ソフト面・机上論では間違いなく・順番に進めているはずなのですが、ハード面・物理的表示でズレが生じてしまうのです。今回は前の表示データがクリアされる前に次の処理が入ってしまったので、次のデータへの更新が物理的に間に合わず・前のデータが表示可能となってしまった。こんなところではないかと私は思います。当時私はこのズレをまさに数秒「物理的に待つ」というだけのルーチン・処理を入れて対処しておりました。現場で試験するとは実働をきちんと確認するということです。詰まるところ今回の【メルカリ】は『デバッグ試験』が無かった・甘かった・考えてもいなかったと言われても仕方がないわけです。
私は水力発電所の制御・システム改訂を行ったことがあります。ＡＴＭでタッチパネルが導入され始めた頃です（バブル期末期・笑）。指タッチされて次の処理を行うまでの間に、微妙な時間のズレが生じていたことが確かありました。万が一「放水」の指示でズレが生じては、現場作業員ならびに下流に住まわれる方々の“命”に関わりかねません。そんな緊張感・重責を感じつつ、まだ２０ソコソコの私はバカでかい・四六時中キンキンに冷やされまくった大型機械が汎用されている工場の中で、真夏の夜中に１人・２時過ぎまで作業をしておりました。あれから『残業ゼロ』宣言が飛び出すまで２０数年掛かったことになります。それまでに幾人の犠牲者が出たことでありましょう･･･ 。*合掌*
･･･ 、いやこの「タイム・ラグ」処理は某鉄道（現存しています）での信号制御で扱ったのかもしれません。今や化石と言われる国内初のマルチタスクＯＳ『トロン』を確か利用したものだったかと思います。いやー懐かしいなぁ。(^o^;)
‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥
といった感じの経緯だと思っています。微妙に違っているかもしれません。ただ「セキュリティー」に関することですので、本当のところは公表されないはずです。もしかしたらば閲覧だけでなく、前の人そのものとして購入されていた危険性もなくはなさそうです。私は最も大事な「個人情報」は貸金庫のように別途厳重に管理され、買い物・購入する際に「アクセスキー」を使って使用できるものだとばかり思っておりました。ＤＢ管理というのは「共通キー」を設定して、それぞれにデータをテーブルに分類・仕分けしているものです。上記にある説明では『一時保存場所なる・キャッシュサーバー』に全ての個人情報を移して、閲覧・買い物させていたことになるわけです。閲覧数が多い者ほど自身にぶら下げられた個人情報を“自ら見せびらかして”歩いていたことになります。(苦)
これは「アクセス数を軽減させて・快適な環境を求めた」ゆえの設計だと思われます。しかし「タイム・ラグ」が存在した。ＷＥＢ版とアプリとで「表示が異なる」（ＷＥＢ版では新たに出品したものが表示されない etc.）が未だに起っています。実際４月頃には出品していたものが突然消えたり／コメント欄が全部消されていたこともありました。全員一律にではなく・一部の該当する方々だけに起っています。 !? とこの不審な動作に疑問を抱き、今回の事故が起る数週間前から「買い控え」を宣言していたことは【メルカリ】で取り引きされていた方はご存知でしょう。そんな危険を事前に察知しておきながら回避できなかった。この無念は今や“憎悪”を変わり果てておる次第です。
「個人情報漏洩」という観点から見れば、確かにその可能性は今回は低いと思います。意図的ではなく、運用者の単なる“大ボケ”ですから。*バーカ！* ただ５時間も放置されたままだったことからその可能性は決してゼロ近辺ではないと思われます。私はコメント欄を埋め尽くすほど、出品者の方と沢山やり取りをするのですが(笑)、購入が決まった際には記念に“パシャリ”と画像保存しております。今回、他人の個人情報が覗けることを知った輩が興味本位から“パシャリ”していたことは否定できないと思いますね。それを悪用されたら･･･ 。どちらにせよ、このような甘いシステムを構築・運用した責任は重いと私は考えます。一向に表に立って謝罪にも現われない同社の姿勢に対して「どうなのよ？」と私なら思ってしまいますけどねぇ。。。
‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥
思いっきり愚痴ってしまいました。(^^ゞ エー、「未発注品」を受け取らないように今や顔なじみとなった各社の配達業者の方々には今回の一件を報告、受け取る前に「品名」をよくチェックするようになりました。(笑) この時“不便だなー”と感じたのが『匿名配送』です。送付先の都道府県すらありません。「受付番号」という“基本のキ”が使えることを改めて教わりました。でも長すぎて覚えていられませんよね。(苦笑) こうした余計な手間・時間の浪費を【メリカリ】は利用者に課したことになるわけです。商売人の欠片が少しでもあれば謝罪会見するでしょ？【ベネッセ】さんみたいに。あちらは物理的盗難事件だから違うとでも言いたげでしょうけどね。(爆)
‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥
そしてついでなのでライバル【ヤフオク】にも触れておきます。実は【ヤフオク】でも「タイム・ラグ」：出品表示画像がズレてしまうといった不具合がありました。タブレッド版です。その問題点に気付いた同社は先月に早々と運用停止を宣言しています。画面を切り替えれば、きちんと正規の商品は表示されているようでしたが、少しでも可笑しな動作はそのまま放置しなかったわけです。個人情報ではなく・出品段階での展示の話です。
タブレット版アプリ（ヤフオク! for iPad、ヤフオク! for Tablet）提供終了のご案内 -お知らせ - ヤフオク!
【ヤフオク】はオークションなので「購入前」を重視します。購入後は責任負わず。
【メルカリ】は「購入後」の決済を重視します。購入前はバーゲンのワゴンセールさならがの争奪戦です。(苦笑)
とある【古物商】の方は創業以来、一度もシステムがダウンすることのなかった【ヤフオク】に対して絶大なる信頼を寄せておりました。不具合が生じたら確かに「メンテナンス中」のアナウンスと共に即運用停止させてます。次の処理は行わせません。これが「事故を未然に防ぐ」基本動作そのものです。【老舗】と言われる方々は取引相手が本当に信頼のおける所かどうかをよーく見ております。今回の【メルカリ】に於ける一件は、信頼たるを得るのか否か、その判断は自ずと明らかでしょう。
やられたらやり返す・倍返し。私はそういう男です。(^_^;) コノヤロウ
長文失礼しましたー！(笑)
www.youtube.com ※仮面を被って購入していたつもりが、素顔を晒していただなんて恥ずかしい。(^o^;)
