ひとつの設定ミスで情報流出ってCDNって、他のCDN利用しているサービスって大丈夫なの？
情報流出の指摘に対し当日中に原因を技術レベルで公開したメルカリの対応は素直に学ぶところが多いなと感じましたが、問題の本質があまり伝わっていないように感じたので記事にまとめてみることにしました。
メルカリの情報流出は、「マイページをクリックしたら他人のアカウントのページが表示された」とのユーザーからの問い合わせの通りコンテンツ配信用のサービスの設定ミスによって、他人のマイページの情報が見えてしまう状態になっていたという問題です。
となっていますが、これを単なる設定ミスで片付けるのは「違うな」と私は考えています。GoogleやYahooはAkamaiというCDNを利用していますし、SlackはAWSのCloud Frontを利用して世界的にサービスを展開しているサービスもありますが、キャッシュの設定ミスで同じことが起こるかといえばそうは思いません。
まずはメルカリの情報流出の原因の理解のためCDNとキャッシュの関係を理解しておきましょう。数百万人の月間ユーザを抱えるのメルカリのようなサービスが大真面目に１つのサーバでコンテンツを配信するのは現実的ではありません。
そんなときのごく一般的な解決策としてCDNは挙がります。
CDNで利便性を向上させると情報流出の危険は増すのか？
CDNとは、世界中のネットワーク上置いてあるサーバにオリジナルのWebサーバのコンテンツコピーさせておき、
サービス利用者に最も近いサーバが代理でリクエストを返すサービスです。
これによりサイトの読み込み時間を短縮しユーザへの利便性を向上するとともに、
アクセスが分散することでサーバへの負担も低減することが出来ます。
役所の出張所や銀行の支店のようにアクセスを良くして、窓口を増やすことで負担を減らしているイメージです。
皆さんの中に、ん？！ロードバランサで負荷分散するのと何が違うんだと思った方もいるかもしれません。
確かに、AWSのELBなどであればOUTトラフィックの問題も解決できますし、
ネットワーク帯の地域分散も可能なので同じように感じてしまうことも理解できます。
しかし、このようにCDNをロードバランサと同じように単なる分散サーバと考えてしまったからこそ
今回のような問題が発生してしまったのではないかと私は考えます。
即ち、メルカリの情報流出はCDNで取り扱うのには向かないマイページのようなユーザ固有の重要情報を、
一括りに「キャッシュ」として処理出来る設計をしてしまっていたことが根本的な原因と考えます。
サーバ自体のコピーをしているのであれば、重要情報も持ってきてしまうのも当たり前です。
しかし、CDNではコンテンツを「キャッシュ」としてコピーします。
この違いが理解で切ればCDNを利用して利便性を高めつつ、
お客様の大事な情報を守ると言った用件を達成できるようになるでしょう。
次に、ここでキーとなる「キャッシュ」をしっかり理解していきましょう。
そして改めてメルカリのニュースを見直して見ましょう。
キャッシュ(cache)はデータコピーの一時預かり所
キャッシュ(cache)とは、貯蔵庫の意味ですが所定の期間、指定のデータをコピーして預かっている「一時的な貯蔵庫」です。
すぐ使うかもしれないデータを一時的に保持しておくことで、データ取得を「差分」に限定することができるため
サービス提供の様々な負担を低減することが出来ます。
キャッシュ(cache)が生まれたタイミングではCDNのようなサービスは存在しておらず
一時保管しているデータはあくまでも１クライアントに帰属しているものという全体があります。
それに対しCDNでは預かった情報は大勢で共有されます。
つまりCDNを「通過する」データは誰が見ても問題ない共通のデータであるべきなのです。
メルカリの公式サイトで原因について技術的に説明しているページがありますが、
ここにどんな錯誤が原因となったかが示されています。
CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして
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ヘッダが過去の日付であっても、Cache-Controlヘッダが存在している場合は利用されないという仕様になっておりました。このためCDNのサーバ上にお客さまの情報が含まれたキャッシュが作成され、別のお客さまへ配信される事態に至りました。
と説明していましたがこの部分は間違っています。
正確には過去日付にするとキャッシュ時間が0秒のとなってオリジンのサーバから
レスポンスが返りますが、実はCDNはレスポンスをまだ返していないタイミングで他のリクエストがきた場合、
同じデータをまとめてレスポンスしてしまいます。
結果、最初に処理中だったページのデータがまとめて他の人にも配送されてしまったわけです。
キャッシュさせない設定の結果、CDNとしての効率的な情報配信の仕組みが裏目に出てしまったのです。
サーバ単体のテストでは問題を見抜くことは困難だと思われます。
この問題はサーバ、CDNと個別に見ず両者の関係を全体的に見ていれば気付くことができた問題となります。
しかし根本的には個別固有の機微なデータはCDNを利用しないとしていれば問題ないことになります。
そもそもCDNって間違って配送するかもですよとか教えてくれないの？
個人情報が流出してしまうような設定変更について
CDNではあくまでキャッシュしたデータ基にきちんとコンテンツ配送しているかしか見ていません。
キャッシュ情報に重要情報いるということを判断して警告してくれるわけではありません。
ようするにどうすればメルカリのような情報流出事故を防ぐことが出来るの
つまり、次のようにすれば今回のような問題は発生しません。
①誰に見られても良い画像ファイルやページの枠組みだけを格納したサーバーを準備そのサーバーだけをCDNの配信元とします。
②個人情報などの重要情報はセッション情報を基にJSONなどで取得してデータの取得元をはっきり切り分けます。
上記であればCDNの対象のデータを扱っているオリジンサーバの設定をいかに間違えようと
情報流出を回避することが出来ます。
人はミスをするものです。１つのミスで重大な事象が発生するのは、仕組みの問題です。
年金機構の情報流出の問題は、添付ファイルを開いたことを問題にしていますが
メールサーバからデータが入ってくるパソコンと年金データのような重要情報にアクセスできるパソコンが
切り分けられていればそもそも起こらない問題です。
全体として不整合が出てしまうといかに個々を丁寧に仕上げたところでほころびが出てしまい。
全体が見える外部からやってくる攻撃者からは容易に弱点を突かれてしまいます。
まさに木を見て森を見ずの状態です。
意識の問題として喚起する前に、仕組みの問題であることを疑いましょう。
人間の行動意識に頼っているのは企業としての仕組みの不備です。
全体を「仕組みとして」不備がないよう日々「設計」を見直し
問題対応や理解の方向性を誤らないように努めましょう。
以上です。