2020

問題文

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

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

私どもの会社は,某地方で地元のIT企業として多角的にICT導入事業を進めてきました.このたび,地元自治体の要望もあり,地域通貨(地域ポイント)を発行して地域の経済活動・社会活動を活性化させる事業を手がけることになりました.当該地域では主に観光産業が盛んですが,それ以外の産業は低迷しており,何よりも地元住民の交流による活力が欠けているように感じられます.地元住民の交流を活発化し,自分たちの活動で地域を活性化する方向性を持たせることを目標として,意欲的に事業の展開を始めています.

さて,本地域ポイント事業ですが,主に住民が地域に貢献する活動をしたときにポイントが付与され,それを地域の商店で使えるようにすることで,地域の活動を活性化します.地元に貢献する活動はいろいろあります.例えば,地元商店での買い物の他,文化・スポーツ活動への参加,ボランティア活動,健康作り(ジムでの運動,ウォーキング)などのイベントが対象となります.付与されたポイントは,地元の認定商店で買い物をするときに,1ポイント1円として支払いに使うことができます.認定商店は月に一度,使われたポイント相当の金額を自治体から受け取ります.イベントは,その自治体が管轄する地域の個人・法人・任意団体等が開催できます.個人消費者,認定商店,およびイベント開催者は,自治体の役場で申請をすればアカウントを作成できます.申請時には本人確認した上で登録されます.アカウントを作成すると,個人消費者も,認定商店やイベント開催者等の団体も,スマートフォンやタブレットにアプリをインストールすることで地域ポイントを扱えるようになります.これらのアプリの開発,およびポイント残高やアカウント情報等を管理するデータベースサーバの設計・構築は弊社が担当し,管理・運用を行っています.

システムの仕組みは次の通りです.個人消費者は発行されたアカウントでスマートフォンアプリにログインし,地元銀行の銀行口座を登録すると,その口座から,1円1ポイントの換算率でポイントをチャージできるようになります.ただし,セキュリティを考慮して,スマートフォンの認証を通れば(アプリのログイン状態は維持されているので)個人アプリの機能を利用できるのに対して,銀行口座からのチャージだけは,チャージ用に登録した暗証番号を入力する必要があります.スマートフォンでの支払いは,支払い用QRコードを画面に表示し,それを商店の端末で読み取るいわゆるストアスキャン方式を採用しました.個人消費者がポイントで支払いをする際には,支払い金額の2%がポイントとしてその消費者のアカウントに付与されます.ボランティアや健康イベント等の主催者は,そのイベントの実施を自治体に申請し,承認を得ると,イベントがシステムに登録されます.イベント会場では,参加者である個人が,現地で個人を証明するQRコードをスマートフォンに表示し,イベント主催者が申請した時間帯にこれを読み取ることで,個人がイベントに参加したことになり,個人に一定のポイントが付与されます.付与されるポイント数は,自治体が申請時に,イベント内容に応じて決定します.

本システムでは,地域住民の誰もが使いやすい地域通貨を目指して,スマートフォンが使えない高齢者や子供でも使える機能を用意しています.家族の中で一人でもこのスマートフォンアプリを使える人がいれば,その人のアカウントでログインし,自分のポイントから一定額を引き出して金券を発行し印刷をすることができます.金券にはQRコードが印刷されており,これを読み取ることで,金券の金額の範囲内での支払いが可能です.設定された有効期限内であれば,その使用額累計が金券の金額を超えるまでは何度でも使用でき,残額はサーバで管理されます.また,有効期限が切れると残額は発行者に戻されます.この金券を使うと,スマートフォンを使えない高齢者や子供でもポイントを使った買い物ができます.また,金券は,アカウントを持っている他のユーザに譲渡することも可能です.金券の譲渡は,他の人へのプレゼントとして利用可能で,アプリ内で氏名を指定すれば譲渡できます.譲渡すると金券の所有権が譲渡先ユーザに移ります.金券の譲渡履歴や利用履歴は所有者のアカウント内に残り,個人用アプリから閲覧できます.ただし,有効期限が切れた場合には,残額は所有者ではなく発行者に戻されます.有効期限は無期限に設定することも可能です.他にも,家族向けの機能として,個人証明用のQRコードが入った個人カードを印刷することができます.(A4サイズの紙にカードサイズのカード画像を印刷し,切り取れば良い).この個人カードを家族に渡して財布等に入れておいてもらえば,家族がイベントに参加した時に,一家族で同じアカウントにポイントを貯めることができます.

このような機能を実現するシステムの中核として,データセンターに配置された仮想サーバを借り,データベースサーバとしてセットアップしました.仮想サーバ内にインターネットからのアクセスを受け付けるプログラムを置き,そのプログラムがデータベースにクエリを発行して検索・更新等の処理を行います.このサーバは,個人用のスマートフォンアプリ,商店およびイベント開催者用のタブレットアプリ,そして自治体の管理アプリからアクセスされます.自治体の管理アプリからは,各消費者ユーザや商店ユーザのポイント情報や履歴を閲覧できる他,申請に応じて個人や商店等のユーザアカウント作成が可能です.自治体の管理端末は,特定部署の担当者数名のみがパスワードを知っており,他の職員がアクセスできないように厳重に管理するようにお願いしていますし,実際にそのように運用されていることも確認済みです.

本サービスは使い勝手が良さそうだと前評判も良く,地方活性化の起爆剤として期待されておりました.サービス開始からユーザも順調に増加して調子が良かったのですが,2ヶ月ほどして2つのトラブルが発生しました.

一つ目は個人ユーザからのクレームです.ある個人ユーザのAさんから,自分の身に覚えがない金券の譲渡が発生しているので,原因を特定してポイントを戻して欲しいと連絡がありました.詳しく聞くと,Aさんは普段からチャージもしてポイントを積極的に使用しているが,最近になって自分のポイントが減っているのに気づき,ポイント履歴一覧からチェックすると,銀行口座からのチャージはされていないものの,最近になって2〜3回,二千円程度の金額の金券が発行され,見知らぬ他人に譲渡された履歴が残っていたということです.Aさんは家族にこのことを聞いてみましたが,身に覚えがないし,そもそも譲渡先の人を知らないとのことです.自分も家族も身に覚えがないことから,Aさんは,外部からシステムに侵入されて,勝手に譲渡処理がなされたのではないかと疑っておられて,早く解決し返金するようにと怒っておられます.

二つ目のクレームは自治体の担当者からでした.今月のポイント発行量が認可した商店やイベントから想定されるよりも随分多いので,管理アプリでポイント発行履歴を確認してみると,一部のユーザがかなり多くのイベントに参加して多量のポイントを得ていることがわかったそうです.詳しく調べると,あるユーザは毎日開催されるウォーキングイベントに欠かさず参加しているのですが,毎日10ものウォーキングイベントに参加していることになっています.しかも,高齢者にも関わらず自宅からかなり遠いウォーキングイベントも含まれているそうです.もちろん家族が参加している可能性もありますが,それでも不自然に見えます.しかも,同様に10以上のウォーキングイベントに参加している人は,ざっと見ただけでも20名以上に上ります.自治体の担当者は,実際にあり得ないと思われるイベント参加記録が見られることから,システムのセキュリティ問題で自治体が損害を被っていると怒っておられて,外部からの侵入と改竄,或いはプログラムのバグを早く発見して排除するようにと強く要求されています.

これらの疑惑に対して,弊社のデータベースサーバを確認しましたが,ログを確認すると,当該期間にそもそも仮想サーバへ外部からのログインが記録されていないため,外部者の侵入は考えられません.SQLインジェクション等の外部からの攻撃も疑いましたが,外部からのアクセス履歴を見ても改竄が疑われるようなアクセス記録は認められず,データベースの改竄はないと判断しました.なお,各アプリからの通信は暗号化されており,サーバへの通信時にはアプリ認証(通信元アプリケーションが正規のアプリであるかどうかを確認)に加えてユーザ認証(アクセスしようとするデータが送信ユーザの権限でアクセスできるかどうかを確認)を行った上でデータベースアクセスを許可していますので,データベースへの不正アクセスはできないはずです.ソフトウェアのアップデートも適切に実施しており,データベースサーバが原因ではないように思います.

もしデータベースの改竄でないとすれば,どうしてこのような問題が起きたのでしょうか.我々も地方の会社とはいえ,システム開発では実績のある会社ですので,基本的なログは全て残すような仕様で問題がトレースできるようになっていますが,地域通貨という我々にとって新しい事業を扱っていますので,どのようなログから何を調べれば良いのか,見当がついておりません.今回ご相談させていただいたのは,今回発生した2つのトラブルの原因究明方法と,短期・長期の対応方法についてご指導いただきたいというのが一番の目的です.一方で,これも我々は重要視しているのですが,我々の地域通貨サービスのシステム設計や運用方法に問題や発展(の可能性)があれば,これに関しても是非アドバイスをいただき,今後の改善につなげたいと考えています.大変お手数をおかけしますが,是非有益なご助言をいただきたく,どうぞよろしくお願いいたします.


○×システムソフト開発 白浜美砂


講評

皆様、一次予選はお楽しみいただけましたでしょうか。今年は最近話題に上がることが多いオンライン決済を題材に問題を作ってみました。当たり前ですが、この手のサービスは堅牢にできていて、同じようなサービスにすると面白い問題にならないので、地域ポイントを組み合わせたサービスを組み立ててみました。その結果、いかにも危ういシステムが出来上がっていると思います(笑)。ここにインシデントが2件発生します。金券譲渡の問題と、イベントポイント付与の問題です。金券譲渡の問題は例年通りのセキュリティインシデントで、不正がどこで起こったかを探索する問題ですが、一方でイベントポイントの問題はサービス設計自体に問題点を含めましたので、解決のためのサービス設計の修正を指南することになります。これらのインシデントの原因自体は、比較的わかりやすいネタ振りをしておいたので、皆さんならわかるだろう、差がつかないだろうと思っていました。今回の課題の真意は、金券譲渡のインシデントでは原因をどう切り分けるのか、イベントポイントのインシデントでは、サービス設計を直すためにどのような提案をするのか、を主たる戦場として競ってもらうことでした。

つまり、昨年までのコンテストで多くみられた原因列挙のアドバイスでは戦えない(他チームとは差がつかない)ことになります。また、今回はセキュリティホールを突いた外部からの侵入も可能性を低く設定したので、自然とサービスまたは人的要因の分析が重要になります。結果がどうなるのか、楽しみにしていました。いざ蓋を開けてみたら、見事にそこで差がつきました。何が起こっているかをわかりやすく説明し、どのように原因を切り分け、解決すれば良いかを明快に示してくれたチームがいくつかありました。一方で原因の可能性を列挙しただけのチームは評価を落とすこととなりました。やはりコンサルタントとしてアドバイスをするわけですから、わかりやすくクライアントをガイドして欲しいものです。今回の選考はそのような観点を重く見ています。

今回のクライアントは実績のあるシステム開発会社ということで、基本的なシステムはしっかり作ってあるという前提としました。ログも基本的なものは残っているという前提になります。そのログを解析して原因の切り分けをすることになります。金券譲渡の件は、可能性の高い原因は、家族によるスマートフォン操作、何らかの方法でのパスワードの奪取、或いは本人の虚偽申告、といったところでしょう。万一サーバへの侵入があったとすれば、譲渡履歴を残すにはデータベースやアプリの仕様を理解したうえで全てのログを一貫した形で残さなければならず、これはかなり難しいと考えられます。これらの原因をどのように切り分けるかが、解決の鍵になりますし、ここを指南することこそクライアントが求めていることではないでしょうか。どのログをどのように用いれば、その切り分けができるのか、その方法をしっかり書いてくれたチームは素晴らしかったと思います。一方、イベントポイントの件は、根本的な解決方法は、システム設計の更新ですが、根本解決をしようとすると利便性が失われます。そのバランスをとった解決策をうまく提案できたでしょうか。また、システム設計の変更はすぐにはできませんので、短期的な間に合わせの対策と併せて提案するのがベターです。こちらは、見事にやり切ったチームはなかったように思いますので、どうすれば良かったのか、一度考えてみてください。

今回はさらに、システム設計がまずい部分をいくつか用意し、改善提案してもらうことも課題に含めておきました。金券を氏名で検索して譲渡できること、イベント申請や参加認証の仕組み、自治体の管理システムが共通パスワードを用いていること、管理システムから個人データにアクセスできてしまうこと、等です。これらは、先ほどのように利便性と安全性がバランスする部分もあり解決が難しいものもありますが、うまく頭を使ってアイデアを捻り出してもらえると良いですね。このサービス設計の問題は奥が深く、改めて皆さんに考えてもらうと面白い部分ですが、情報危機管理コンテストが要求するスキルとは少し離れますので、この部分は少し評価の比重を落としていることを補足しておきます。

このような思いで皆様のアドバイスを見させていただきました。手応えはありましたでしょうか。全体的には、やはり細かい原因を列挙するチームが多かったという感想を持ちました。皆さんが技術を中心に勉強されているのは知っていますし、二次予選以降でも技術は必須ですから、そのアピールをされる気持ちは良くわかります。別に書くなとは言いません。アピールしてもらえればと思います。でも、もっと重要なことを中心に書いて欲しいなとは思いました。技術を含めた深い知識が行間に溢れ出るサービス分析。とてもカッコいいと思いますので、目指して欲しいと思います。次に、解決する上での全体戦略が書かれていないチームが多かったです。この場合、顧客はどの可能性を優先してどのように対応をしていけば良いのかがわからないため、原因のリストを見て、自分で優先度を検討して具体的行動を計画することになります。この作業を省き、適切な行動計画を素早く作れるようにしてあげると良いでしょう。ちなみに、各原因に対して優先度やインパクト、発生可能性の大きさ等を付与したチームが多くありますが、根拠が書かれていない例が多かったです。文中または行間に、そのような優先度にした根拠が説得力をもって書かれていなければ、結局顧客は行動計画の検討に時間をかけることになります。なぜそのような優先度になるのか、その根拠を説明することは重要です。

一方、上記とも関連しますが、今回はインシデントが2件あったからか、まとめ方(文章構成)がうまくなくて、損をしているチームが多いなと感じました。論文等の技術文書全般に通じることですが、少しコツを書いておきます。まず、大きなことから順に書いて詳細化することが、わかりやすさを高めます。前から順に読めば理解でき、読み返しが不要、というのがわかりやすい文章の鉄則です。要因分析や解決戦略の全体像を書いて、そこから個々の原因や切り分け方法にスムーズにつながるような構成がベストです。今回は、全体像がなく、いきなり個々の原因の列挙をするチームが多数ありました。また、全体像があっても、そこからいきなり原因の列挙に進んで繋がっていない例もありました。文章のはじめから読んでスムーズに詳細につながっていく流れを作りたいところです。次に、重要事項から順に書くことも意識しましょう。原因の検討を、(可能性の低い)システムへの侵入から説明を始めるチームや、どんなインシデントでも共通のマニュアル的な対応方法から始めるチームがありました。今回の場合、顧客の関心は2つのインシデントをどう解決するかです。まずそこにフォーカスして話を進め、重要性の薄い原因や、どんな事件でも共通の事項は後にまわす方が良いです。もし、共通事項であり相手もわかっているはずだけど念押しをしたい、という場合には、そのように書いて位置付けを明らかにすると良いでしょう。重要事項を優先して説明しなければ、顧客は自分のニーズを汲んでもらっているとは思わないでしょうし、その結果、あなたへの信頼が揺らぐことになります。プレゼンテーションの良し悪しは皆さんのアドバイスの品質に直結しますので、決して疎かにはできない技能なのです。

いろいろ書きましたが、今回は結果的に、主たる要因の分析ができているか、解決への戦略(考え方)は妥当か、原因の切り分けや解決方法が説得力をもって示されているか、というあたりが主な観点となってボーダーラインを引くことになりました。今年は珍しくボーダーライン付近のチームは少なく、ほぼ悩むことなく予選通過チームを選択できました。二次予選に進めなかったチームには申し訳ありませんが、一次予選だけでも楽しんでいただけていれば嬉しく思います。また実力を磨いていただいて、来年のチャレンジをお待ちしています。一方で、予選通過された皆さん、おめでとうございます。今年は新型コロナウィルスのおかげで二次予選以降の日程はまだ確定しておりませんが、概ね1週間遅れての実施となる見込みです。また、決勝戦も恐らくオンライン実施となる見込みです。詳しくは二次予選・決勝戦担当から連絡があると思いますので、連絡をお待ちください。本コンテストを通じて、皆さまが今後、情報セキュリティやシステム管理の専門家として、活躍されることを心より祈念しております。


それではまたどこかでお会いしましょう。

ーーーーー 

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