6月22日にメルカリが起こした個人情報の漏えい事故。最大で5万4180名の個人情報がWeb版のメルカリで閲覧可能な状態になっていたというものだ(スマホアプリは対象外)。

実際の漏えい数は多くない?

近年の情報漏えい事故に多い「マルウェア」や「内部犯」とは本質的に異なる今回の事故では、キャッシュサーバーを世界中に配置してWebサイトの読み込み時間を短縮させるためのサービス「CDN(Contents Delivery Network)」の切り替え作業でミスが起こった。

例えば個人情報を管理するデータベースから内部犯が盗み出すケースや、遠隔操作ウイルスによってADアカウントを乗っ取り、データベースにアクセスするケースなどでは、まとめてデータを抜き取られた可能性が高い。

一方で今回のCDNを起因とした事故では、最大約5万人のユーザーがアクセスしたページをCDNのキャッシュサーバーがキャッシュ(保存)。このキャッシュされたデータをブラウザが参照した結果、第三者に個人情報が表示されたケースがあり、ユーザーからの連絡に繋がった。

9時41分の切り替え作業から14時41分のユーザー問い合わせまでちょうど5時間だが、この間にキャッシュを幾度も参照するには限界もあることから、実際に5万名の個人情報が流出した可能性は低く、漏えいした実数は少ないものとみられる。

ブログで技術詳細を公開したメルカリ

詳細はメルカリが通常、技術情報を公開している「Mercari Engineering Blog」で説明しているが、切り替え前事業者ではnginx Webサーバーでキャッシュをdisableする設定によってブラウザがサーバーへの問い合わせを毎回行うようになっていた。この設定によってサーバーからのレスポンスヘッダはCache-Control: no-cacheになるが、今回はここが仇となった。

切り替え前のCDNプロバイダはCache-Controlヘッダではなく、CDN側の設定でキャッシュを制御する方法だったため、Web版メルカリでキャッシュしない設定にしていた。しかし切り替え後のCDNプロバイダは、Cache-Controlヘッダでキャッシュ制御が可能だったため、nginxサーバーで設定し、切り替え前検証はマシンのhostsファイルの編集で数回のアクセスで動作に問題がないことを確認したという。

しかし、事象が発覚した後にCDNのキャッシュの仕様を確認したところ、キャッシュしないケースはCache-Control: privateが含まれているときのみであり、Expiresヘッダが過去の日付であってもCache-Controlヘッダが存在している場合は利用されない仕様だったという。

なお、9時41分にキャッシュサーバーの切り替えを実施して14時41分にカスタマーサポートへの問い合わせがあったのち、15時5分にはサーバーの切り替え中止と設定を戻す作業を行い、同38分には問題を完全に解消したという。CDNプロバイダについてはメルカリ広報部に問い合わせたものの、「両社に問い合わせする必要がある」として非開示。現時点でWebサイト上で確認できるURLからは、過去のプロバイダがAkamaiである可能性が高い。

23日には再発防止策の詳細も公開

日本のユーザーは5万3816名、米国のユーザーは363名の合計5万4180名の個人情報が閲覧された可能性がある。