2017

問題文

貴方は情報セキュリティに関する専門家としてコンサルティング業務を行っています．顧客企業から次のような相談が来ましたので，この相談に対してアドバイスをしてください．

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

私どもの会社は，乗客とタクシーのマッチングを行う配車サービスを手がけています．U社やL社などの同種のサービスが話題になっているのでご存知かと思いますが，スマホのアプリ，またはwebブラウザから乗車位置と目的地を入力すると，近くの空車を見つけたり，配車を依頼することができます．お陰様で業績は順調で，顧客数は上昇の一途を辿っており，多くの顧客に選ばれているようです．提携タクシー会社からは，競合他社に比べて大幅に業績が向上していると喜びの声を聞いており，所属するタクシー会社を移る運転手も現れているそうです．ところが，先日，提携タクシー会社A様から，誤った配車リクエストが届くようになった，業務に支障が出るのでなんとかして欲しいと苦情を受けました．A社様によると，これらのリクエストは複数のユーザから届いているとのことでしたので，アカウントの漏洩も疑われる事案です．しかしながら，弊社にはこのような事案に対応する知見が不足しておりますので，万全を期すために，御社にご相談をさせていただいた次第です．

私どものサービスは，手軽に近くのタクシーを検索して，配車をリクエストできることが特徴です．

アプリ，またはブラウザからタクシー検索画面を呼び出すと，現在地を中心として，近くにいる空車のアイコンが地図上に表示されます．表示されたアイコンをタップまたはクリックすると，到着予想時刻やその運転手のプロフィール，他の乗客からのコメント等の情報を閲覧でき，どのタクシーを呼ぶかを比較検討することが可能です．配車を依頼するときには，乗車位置と目的地を指定します．目的地は，地図上でピンを動かして指定できるほか，住所や建物名をフォームに入力することでも行えます．一方，乗車位置には２つのオプションがあり，「ここから乗車する」を選択すると現在地が乗車位置として指定されます．「別の場所から乗車する」を選択すると，地図上にピンが表示され，乗車位置を指定できるようになります．ただし，誤操作を防ぐために，乗車位置は現在地から半径1km以内からしか指定できないようになっています．これらの情報を入力して配車を依頼すると，乗客の情報と併せてリクエストが運転手に届き，運転手がリクエストを了承すると，乗客に通知される仕組みになっています．

また，私どものサービスでは，車中でいかに快適にお過ごしいただくか，という点にも力を入れています．このためにタクシーの推薦機能を提供しており，例えば，「会話を楽しみたい」ボタンをタップすると，近くにいるタクシーのうち「話題が抱負」「聞き上手」などと評価されているものを，「観光したい」ボタンをタップすると，観光スポットや食事処に詳しいと評価されているものを推薦します．また，自由記述でコメントやプロフィールを検索することも可能です．さらに，乗客がプロフィールを設定すると，この情報に合わせた推薦も可能であり，例えば趣味が同じ運転手を見つけやすくなります．運転手を「お気に入り」として登録することで，次回からその運転手に即座にリクエストすることも可能です．これらの評価システムは弊社サービスの利便性に大きな影響を与えることから，ユーザの意見を取り入れた改善に力を入れており，継続的にアプリを更新しています．最近は月に１回程度のペースでアップデートを行っており，順調にユーザの評価が向上しています．

さて，この度の事案ですが，依頼された乗車位置に行っても乗客が見当たらないということがこの数日で十数件発生したそうです．そのうちの何件かは乗客に電話連絡できたそうですが，そもそも配車依頼をしておらず，乗車位置の近辺にも行っていないと言われたそうです．また，運転手に通知された乗車位置が，乗客が指定した場所と数百メートルほど異なると言われたこともあったそうです．A社様からは，このようなことが続けば業務に多大な支障が出るが，これはシステムの問題なので早急に原因を調査し，再発を防止して欲しいとの要請が来ています．

当初は，アプリからの位置情報の誤送信を疑いましたが，位置情報はスマホの標準機能を利用しており，近年は位置推定の精度が高いことから，実際の位置から数百メートルもの誤差があるのは腑に落ちませんし，そもそも乗客の身に覚えがない配車依頼が送信されることを説明できません．このことから，アカウントの漏洩やデータ改ざん等のセキュリティ事案なのではないかと疑っているところです．

私どものシステムはWebサーバとデータベースサーバから構成され，データセンタ内にサーバを配置しています．乗客のアカウント情報や配車依頼などは全てデータベースサーバに格納されており，当該情報にはWebサーバからのみアクセスを許しています．Webサーバは，近隣タクシーの検索表示や配車依頼の送信処理などを行っており，運転手と乗客が利用するスマホアプリとはWebAPIを通して情報をやり取りしています．将来的に他サービスと連携することを見越してAPIを公開していますが，もちろん当該通信はHTTPSで暗号化していますし，WebAPIを利用するためにはユーザ認証が必要ですので，セキュリティ上の問題はありません．

データセンタ内の上記システムは，弊社に常駐しているサポートチームによって管理されており，本チームが所属するVLANからのみアクセスできるようになっています．本チームはシステムの管理・運用だけでなく，運転手へのシステムの使い方指導や，リアルタイムのトラブル対応も行っており，本サービスに係るICT関連の窓口を一手に引き受けています．このため，本チームには，Windows 10 Proが動作しているPCが複数台割り当てられており，乗客や運転手からの問い合わせに即座に対応可能なように，インターネットに接続された環境になっています．

状況は上記の通りですが，今回の事案はどのように引き起こされたのでしょうか．また，情報漏洩等の危険性はないでしょうか．考えられる原因や，我々が今後取るべき対応について，ご助言をいただけませんでしょうか．

以上，どうぞよろしくお願いします．

○×トランスポートシステムズ　白良浜砂男

講評

従来型の固定サーバ、固定ネットワーク、そして仮想化された世界で起こる不可思議な怪奇事件・・・、というのも鉄板ストーリーとして重要性が衰えない一方で、スマートフォンやタブレットがビジネスに深く入り込むにつれて、より複雑なロールプレイが現実味を帯びてきました。今回は、我々が先日サンフランシスコに遠征をしてきたこともあり、某新鋭のタクシービジネスを例に出題をしてみました。日本では法律の壁で一般人がドライバーになる「白タク」は実現できないそうですが、それでも空想は広がるもので、少しは楽しめる問題設定になったかと思います。典型的なシステムの運用・管理の知識だけでは対応しにくい要素も入ったため考えにくかったかもしれませんが、こういうテンプレートが当てはまらないストーリーこそ、実力が試される試金石になると思います。

さて、今回の「事件」ですが、これはどう料理すれば良いのでしょうか？まずは、誰がどう絡んで何が起きた可能性があるのか、それを推理することから始まります。確認された事実はこうです。配車依頼をタクシーが受けて現場に行ったら誰もいなかった。呼び出したはずの人に連絡を取ると、タクシーは呼んでいないと答えがあった。或いは、数百メートルも離れたところで待っているとの答え。一体何が起きたのでしょう？まず気づいて欲しいのは、一見すると類似したこの２つのケース（虚偽の依頼と位置のズレ）は、実は同じ原因では起こり得ないということです。前者はセキュリティ事案に思えるけど、後者はセキュリティ事案とは考えにくいわけで、問題の完全解決のためには複数の原因を除去しないといけないことになります。また、前者のケースに関しては、誰かがタクシーを呼んだことになりますね？誰が呼んだんでしょう？もちろん、アカウントを盗みとった誰かが呼んだ可能性が一番に思いつきます。（システムに侵入しただけではタクシーは呼べないことに注意しましょう。）その場合は何らかの方法でアカウントが漏れたのでしょうし、セキュリティ事案です。でも、実は、呼んだのは本人で、被害者のふりをしているだけだったりして。例えば、同業他社の人がタクシーを呼んで、「いや呼んでないよ」って嫌がらせ。（そういう伏線はちょっとだけ仕込んでおきました。）あるいは、単なるいたずら。あり得ますよね？しかもこれは、考えてみると、客は誰でも実行できるわけで、本質的にシステムでは防げないわけですから、実際に起こったら対応に手を焼きそうです。さらに、仮にアカウントが漏れたセキュリティ事案だったとしましょう。その場合でも、システムがクラックされた結果漏れたのか、たまたま一人のユーザが（フィッシングを含めた何らかの経路で）漏らしたのか、それによって事のインパクトは大きく違いますし、企業の対応も大きく変わるでしょう。そういうことを考えると、やはり重要なのは、今回の件はどれだけ深刻であるかを明らかにすることが第一。そういう視点で原因の追究をしたいところです。ただ、現段階では情報が不足していますから、そうすると、今ある情報から可能性を分析し、顧客に各ケースのリスクやインパクトを示してあげること。そういう観点から「事件」の全体像を見せてあげること、それが重要だと思います。

そういう前置きをした上で、皆さんのアドバイスを見させてもらうと、多くのチームがかなり詳しく丁寧に原因の可能性を列挙してくれているんですが、そういう分析とそれが顧客に理解できるようにプレゼンされていたかというと、まだ課題があるなあという感じがしました。この数年は皆さんのレベルが相当上がっていて、妥当な可能性を列挙することは、複数のチームができていただろうと思います。文章をよく読めば、そういう可能性を意識できていることはわかります。わかるんですけど、じゃあそういう分析を、客が納得いくようにプレゼンできていたか、というと、話が変わってきます。実際に、決して少なくないチームの傾向として、やはり技術に走った（技術者としては残念ながらありがちなんですけれども）原因の列挙をしていて、とても細かい、例えば社長さんなんかにはとても理解できないような文面になっているものもありました。多分、技術者であっても、システムの運用・管理に明るくない人にはわからないんじゃないかと思える表現でした。これを、もっと粒度を荒くして、全体を俯瞰した視点から、例えばインパクト別にまとめるような整理をしておきたいところですね。今回の事案では、原因の可能性は非常にたくさんあって（しかも現状では原因を特定するための情報量が少ない）、列挙するだけではイマイチ説得力を生まないのです。やはり、今後の対応を左右するような粒度でうまく切り取って、適切なアドバイスをしたいところです。

こういうことを反映して、今回は審査の最重要ポイントを、原因の可能性をどれだけ分析して顧客に提示できているか、という点に置きました。文章が短くても、ポイントを押さえて分析をして、アドバイスをしてくれたチームはありました。その次に、原因可能性を挙げてくれた、その網羅性を評価しました。これは、細かい技術レベルの列挙という意味よりも、いたずらやソフトウェアのバグ（これも伏線が入ってました）、GPSの精度、管理端末の問題、というような大きな項目を見逃さないことを重視しました。他にも、初動対応や現在の運用体制の見直し提案など重要なポイントはあり、これらももちろん評価には入っていますが、いわゆる紋切り型の一般的な提言に関しては、それほど重きを置いていません。顧客のレベルを考えると、アドバイスの中で、初動対応などを細かく伝えておく重要性はもちろん理解していますし、評価の中で汲んでいますが、それよりも実力を測る上で重要な評価項目があった、と理解してもらえればと思います。

最後に、細かいことですが、気になった点をいくつか挙げておきますので、参考にしてください。まず、多くのチームが、A社に「謝罪」せよ、と言っていました。確かに日本の文化では、自分に非がなくてもとりあえず謝っておいて、当たりをやわらかくするという慣習がなくはないのですが、それでも、自分に非がないのに謝るのが妥当なのかどうかは、一度考えてみると良いと思います。今回の件は、他社のいたずらや、ユーザの過失によるアカウント漏洩など、システム的にどうやっても防げない原因もあり得るわけです。原因が特定できておらず、自分の非が確定しない段階で謝る（＝自分の非を認める）のはどうなのか。海外では、自分の非がある時にだけ謝る、という認識が一般的で、安易に謝ることはしないものです。次に、原因可能性を列挙するのは良いのですが、そこに「優先度」「難易度」などのレーティングがされている例がありました。それは、レーティングがあれば一覧性が増し、把握がしやすいと思ったのだろうと思いますけれども（そして実際に、納得した上で把握できる表現がされているチームも多くありました）、その優先度にした根拠が書いているチームもありましたが、そこが書いていないチームもありました。根拠がなければ、これをどう判断すれば良いのかがわからず、納得できにくいんですよね。なぜ優先するのか、が読んでわかるようになっていて欲しいと思います。「危険度」「深刻度」などであれば、あまり説明せずとも分かる場合が多いです。お客さんも、コメントの内容から推し測って納得できるかもしれません。何れにしても、読んで納得できるような整理方法、表現方法を志したいですね。もう一点、「サーバやDBが攻撃されたら今回の事件が起こる」ということを前提にしているチームが多かったように思います。ここは、もう少し間をつなぐ説明が欲しいですね。というのも、例えば、Webサーバに侵入したら今回問題になるような虚偽の配車依頼が出せるかと言うと、必ずしもそうではないからです。WebAPI経由で配車依頼を出すか、スマホアプリからか、配車依頼の発信源は限られるわけで、そのあたりまで言及しないと、説得力が出ない。サーバにログインした状態では配車依頼を出すプログラムにアクセスしないと配車依頼は出せないでしょうし、プログラムを解析している時間も限られるでしょうね。

さて、長くなりましたが、振り返ってみると、今回の問題は、当初思っていたよりも、いろいろと示唆に富む内容が含まれていたのかなと思います。今回は参加チーム数が多かったため、予選通過できなかったチームが多数ありますが、大変お疲れ様でした。一次予選だけでも良い経験をされていれば幸いです。また来年もチャレンジをお待ちしています。予選通過されたチームは、引き続き二次予選をお楽しみください。今後の健闘を祈ります。

それでは、また、お会いしましょう。

ーーーーー

一次予選担当　吉廣卓哉・藤本章宏（和歌山大学）