情報処理安全確保支援士 2019年 春期 午後I 問題

共通の文章

Webサイトのセキュリティに関する次の記述を読んで,設問1ご3に答えよ。 M社は,従業員数200名の小売業である。コーポレートサイトであるWebサイト A(URLは,https:/site-a.m-sha.co.jp/)と,自社の特定のブランドを取り扱うECサ イト(以下,ブランドサイトという)を複数運営している。現在運営しているブラ ンドサイトは,WebサイトBからWebサイトFの五つである。Webサイトの開発や |運用は自社の開発部で行っている。 WebサイトAは,ブランドサイト全体のポータルサイトでもあり,各ブランドの キャンペーン情報などを掲載している。会員専用の機能は有していない。 WebサイトB(URLは,https:/site-b.m-sha.co.jp/)は,ブランドBの商品を扱う ECサイトで,会員数は10万名である。WebサイトBでは,Cookieを利用したセッ ション管理を行っている。 会員情報は,各ブランドサイトで個別に管理している。 [各ブランドサイトからWebサイトAへの情報連携] AS],各ブランドサイトの売上数を基にした,ブランド別の売れ筋商品情報を,Web+ イトA上で表示するとともに,希望があれば,各ブランドサイトの会員に電子メールでも 定期的に配信することにし,そのために売れ筋商品情報及び会員情報を取得する機能(LA 下,情報連携機能という)を実装することにした。具体的な機能は次のとおりである。 機能1 WebサイトAが各ブランドサイトの売れ筋商品情報を取得する。 機能2希望する会員に電子メールを配信するために,WebサイトAは,当該会員の 会員情報を取得する。 なお,配信の申込みは,WebサイトA上で行う。 情報連携機能の実装は,開発部のCさんが中心になって進めることになった。ま ず初めにWebサイトBからWebサイトAへの情報連携を行うために,次の二つの Web APIをWebサイトBに実装することにした。 ・WebサイトBの売れ筋商品情報を取得可能とするためのWeb API(LAF,API-Xと いう) ・WebサイトBの会員情報を取得可能とするためのWeb API(以下,APYという) es なお,Web APIで受け渡されるデータは,JSON(JavaScript Object Notation)形式 にする。Cさんは,APLYからブランドサイトの会員情報を取得する際,配信を希望 する会員の同意を得たいと考えた。そこで,会員情報の取得には,会員のWebブラ ウザを経由して行う方式を採用することにした。 WebサイトBからWebサイトAへの情報連携機能を図1に示す。 (X-1)売れ筋商品情報取得リクWebサイトB |waイト4[A ERR rf Amrx|[APE] ストが送られる。リ 、_(X-2)売れ筋商品情報が返される。= (Y-1)会員が売れ筋商品情報配信の申 込ページにアクセスする。?(Y-2)申込ページに加え,(Y-?会員情報を取得す aaを呼び出すスクリプクリプトZから送 7)申込情報と会員情報がWeb WebサイトBのAPI-Yるリクエストがス °トZが返される。られる。 eh 15)会員情報が返される。? CY.3)会員が申込みを行う。lea 注!APLX Clk,WebサイトAからだけアクセスできるように,接続元のIPアドレスを制限す る。 2会員がWebサイトBにログインした状態のときにアクセスする。 3会員情報が得られない場合,エラーを返す。 9(¥5)でエラーが返ってきた場合,WebサイトBにログイン後再度操作を行うよう促す。 1 WebサイトBからWebサイトAへの情報連携機能 [情報連携機能の実装についての検討 スクリプトZは,|』。|ポリシにょって,|5 J,|<人 | 』|のいずれかが異なるリソースへのアクセスが制限される。そこで,CX Ald,この制限をう回するためにTSONP(JavaScript Object Notation with Padding)を 用いることを開発部のD課長に提案した。次は,その時の会話である。 Cさん:API-Yからの会員情報の取得にJSONPを用いるつもりです。 D課長:ISONPは,アクセス先を制限する機能をもたないので,その実装では問題 MHS,例えば,まず,会員情報を幻取するように攻撃者がスクリプトZ を変更して,攻撃者のWebサイトのページに置く。次に,被害者に①特定 の操作をさせた上で,そのページにアクセスさせると,攻撃者が被害者の ーー3ーー 会員情報を初取できてしまう。 Cさん:JSONPの代わりに何の技術を用いればよいでしょうか。 D課長:CORS(Cross-Origin Resource Sharing)を用いるのがよいだろう。 [CORSの概要] CORSとは,あるWebサイトから他のWebサイトへのアクセスを制御することが できる仕組みである。XMLHttpRequestを使って“https://test2.example.com/test”(< リクエストを送るスクリプトの例を図2に示す。 var xhr=new XMLHttpRequest(); xhr.open('GET’,'https://test2.example.com/test'’,true); xhr.setRequestHeader('X-Requested-With',XMLHttpRequest): xhr.send(null); B42 XMLHttpRequestを使ったスクリプトの例 Webブラウザが“https:/test1.example.com/′にアクセスし,図2のスクリプトを 含むページを読み込んだとする。2のスクリプトが実行されると,最初にWebブ ラウザは“https:/test2.example.com/test”にプリフライトリクエストと呼ばれるリク エストを送る。そうすると,実際のリクエスト(以下,メインリクエストという) で許可されるメソッド名やヘッダフィールド名などがレスポンスとして返る。その 後,メインリクエストを送り,レスポンスが返る。この一連の動作を図3に,また, 図3中の(二)~(vil)のリクエストとレスポンスの先頭部分の例を図4ー図7に示 す。 test1.example.com Webブラウザtest2.example.com 1i)アクセス 図3一連の動作 ーー4= OPTIONS/test HTTP/1.1 Host:test2.example.com Access-Control-Request-Method:GET” Access-Control-Request-Headers:x-requested-with 2 Origin:https://testl.example.com® 注'"Access-Control-Request-Methodには,メインリクエストで利用したいメソッド名を指定する。 9 Access-Control-Request-Headersには,メインリクエストで利用したいヘッダフィールド名を 指定する。 ?Origin lk,スクリプトを含むおページのオリジンであり,Webブラウザが付与している。 図4(ii)のリクエストの先頭部分の例(抜粋 HTTP/1.1 200 OK Access-Control-Allow-Origin:https://testl.example.com” Access-Control-Allow-Methods:GET,POST,OPTIONS” Access-Control-Allow-Headers:x-requested-with? 注"Access-Control-Allow-Originには,Webサイトが許可するオリジンが返される。 2 Access-Control-Allow-Methodsには,Webサイトが許可するメソッド名が返される。 ?ツAccess-Control-Allow-Headersには,Webサイトが許可するヘッダフィールド名が返される。 図5(iv)のレスポンスの先頭部分の例(抜粋) GET/test HTTP/1.1 Host:test2.example.com X-Requested-With:XMLHttpRequest Origin:https://testl.example.com 図6(v)のリクエストの先頭部分の例(RE) HTTP/1.1 200 OK Access-Control-Allow-Origin:https://test1.example.com a図(VOLAKYADORARDOB(抜粋) また,CORSでは通常,Webブラウザは,スクリプトを読み込んだページのオリジ ンだけにCookieや,ベーシック認証の情報を送る。図2では設定していないが, XMLHttpRequestのプロパティのwithCredentialsの値がtrueに設定されている場合, 図3であれば,[ec|の動作の際に,test2.example.comから発行されたCookie が送られる。 ーー5ーー (CORSを利用した実装】 Cさんは,スクリプトZの実装にCORSを用いたときの一連の動作を検討し,表1 (ER LOE. 表1スクリプトZの実装にCORSを用いたときの一連の動作 Webプラウザは,WebサイトAの売れ筋商品情報配信の申込ページにアクセスする。 2|WebサイトAは,WebサイトBのAPI-Yを呼び出すスクリプトZを含むページをレスポ VAL CES 3 Webブラウザは,会員が申込みを行うと,WebサイトBにプリフライトリクエストを送 信する。プリフライトリクエストは,OPTIONSメソッドの呼出しであり,Originヘッダ フィールドには“https://site-am-sha.co.jp”"が設定されている。 4|APLYは,送られてきたリクエストにOriginヘッダフィールドが存在する場合,Access- Control-Allow-Orignヘッツッダフィールドを付加し,レスポンスを返す。Access-Control- Allow-Originヘッダフィールドの値は,"| f|]′CHS.Originヘッダフィールド が存在しない場合,エラーを返す。 5|Webブラウザは,とAccess-Control-Allow-Originヘッダフィールドの値を照合 し,アクセスが許可されていることを確認する。許可されている場合は,次の処理に進 む。確認できない場合は,メインリクエストを送らずに終了する。 スクリプトZは,受け取ったTSON形式の値を変数に格納し,表示する。さらに,VIR った値はWebサイトAに送られ,保存される。 Cさんは,表1についてD課長に確認した。次は,その時のD課長とCさんの会 話である。 D課長:今後,他のシステムでもCORSを利用することが考えられるので,コーデ ィング規約も併せてまとめておきたい。Access-Control-Allow-Originヘッダ フィールドに指定できるオリジンは一つだけなので,複数のオリジンから のアクセスを許可するような仕様であった場合に,No.4の内容では不十分 である。Web APIのプログラム内に,許可するオリジンのリストを用意して おく必要がある。プリフライトリクエスト又はメインリクエストがWeb API に送られてきたときに,そのリクエスト中のを, と突合し,した値があればその値をAccess-Control-Allow-Origin ヘッダフィールドに設定するという内容もコーディング規約に含めればよ a 6— いだろう。 Cさん:分かりました。 Cさんは,CORSの利用に関するコーディング規約をまとめ,表1をこれに合うよ うに修正し,D課長に再度確認した。修正後の内容で問題ないということだったので, Cさんは実装を行った。 その後,セキュリティ専門業者に騰羽性診断を依頼し,脆弱性が検出されないこ とを確認した上で,情報連携機能をりリリースした。その後,同様に残り四つのブラ ンドサイトからWebサイトAへの情報連携機能も実装した。

共通の文章

クラウドサービスのセキュリティに関する次の記述を読んで,設問1,2に答えよ。 U社は,東京に本社をもつ従業員数1.000名の商社である。複数の海外拠点を設置 し,海外向けに営業展開している。海外拠点の従業員数は1拠点当たり十数名ほどで ある。 本社の情報システムは,本社の情報システム部が管理しており,各海外拠点の情 報システムは,現地の情報システム担当者が管理している。電子メール(以下,メ ールという)の送受信には,本社ではオンプレミス環境を導入しているが,海外拠 点では,P社が提供するクラウドサービス型Webメールサービス(以下,メールサー ビスPという)を利用している。海外拠点では,全ての従業員にスマートフォンとノ ートPCを貸与している。 〔セキュリティインシデントト発生] 1月10日,送信者が海外拠点Qの従業員Sさんのメールアドレスである不審なメ ールを受け取ったという連絡が,Sさんとやり取りのあった本社の従業員から情報シ ステム部にあった。情報システム部では,情報処理安全確保支援士(登録セキスペ) であるTさんが,調査を担当することになった。Tさんが当該メールのヘッダ情報を 確認したところ,メールサービスPから送信されたものであった。 海外拠点Qの情報システム担当者であるYさんによれば,1月10日にSさんのア カウントからの不審なメール送信と考えられる履歴が複数残っているとのことであ った。そこで,Tさんは,YさんにメールサービスPのSさんのアカウントを一時的 に無効化するよう依頼した。また,会社から貸与されたSさんのスマートフォン及び ノートPC並びにSさんのメールボックスには重要情報がなかったことを確認した。 Tさんが,海外拠点Qの全従業員のアカウントについて,メールサービスPに残っ ていた全てのメール送信履歴をYさんに確認してもらったところ,Sさんのアカウン ト以外に不審なメールの送信履歴はかいとのことであった。 経緯の調査〕 Tさんは,メールサービスPに残っていた海外拠点Qの全従業員のアカウントの メール送信履歴及び監査ログ,並びにSさんへのヒアリングの結果をYさんから送付 ー9一 してもらい,調査した。調査結果を図1に示す。 ・1月10日は,Sさんはアジアの2Z国に出張中だった。 ・U社には,会社から貸与されたノートPCをU社以外の無線LANに接続してはならないとい うルールがあるが,Sさんはそのルールを知らず,その日,出張先のホテルで宿泊客用の無線 LAN(以下,ホテルWRという)を利用していた。 ・ホテルWi-FiのSSIDは,宿泊客で共通であり,そのSSIDと事前共有鍵はロビーなどの共有ス ペースに張り出されていた。 ・SさんのノートPC(以下,PC-Sという)は,IPアドレス及びDNSサーバの情報をDHCPで 自動取得する設定になっていた。 ・Sさんは,その日,メールサービスPを利用するために,Webブラウザのアドレスバーにメー ルサービスPのFQDNを手入力し,ログインページに利用者IDとパスワードを入力した。 ・SさんがメールサービスPにアクセスした時,サーバ証明書が信頼できない旨のエラーはWeb ブラウザ上に表示されなかった。 -・メールサービスPの監表ログに記録されていたSさんの利用者IDによるログイン記録のうち 不審メールが送信されていた時間帯のものは,Z国,及びSさんが出張していない南米のW国 のIPアドレスからのものだった。 図1調査結果(抜粋) Tさんが調べたところ,メールサービスPはHTTP over TLSでサービスが提供さ れている。HTTPでアクセスした場合はHTTP over TLSのURLにリダイレクトされ る仕様になっており,HSTS(HTTP Strict Transport Security)は実装されていない。 こうしたことから,TさんはSさんが不正アクセスを受けたと確信し,図2に示す 手口(以下,FOGという)を使って,攻撃者がメールサービスPのSさんの利用 者IDで不正アクセスしたと推測した。 ・攻撃者は,①無線LANアクセスポイント,DNSサーバ及びWebサーバを用意した。そのDNS サーバには|。|のFQDNと[|5|のIPアドレスとを関連付けるAレコードが 設定されていた。 ・Sさんは,PC-SをホテルWi-Riに接続しようとして,攻撃者が用意した無線LANアクセスポ イントに接続してしまった。 ・その結果,PC-Sに攻撃者が用意したDNSサーバの情報が設定された。 ・Sさんは,WebブラウザからメールサービスPにアクセスしたつもりだったが,実際にはWeb ブラウザは③②攻撃者が用意したWebサーバに接続していた。Sさんは,サーバ証明書が信頼で きない旨のエラーが表示されなかったので,そのWebサーバに対して,利用者D及びパスワ ードを入力してしまった。 ・攻撃者は盗んだSさんの利用者ID及びパスワードを使ってメールサービスPに不正アクセス Wes 図2手口6 Tさんは,今回のセキュリティインシデントの調査結果を情報システム部長に報告 した。情報システム部長は,会社から貸与されたノートPCをU社以外の無線LAN に接続してはならないというルールの全社への周知及びメールサービスPの認証方式 の強化をさんに指示した。 〔認証方式の強化] 情報システム部長からメールサービスPの認証方式の強化について,次の2点が要 求された。 要求1 U社以外の無線LANに接続したとしても手口Gを防ぐこと 要求2 FOGに限らず,偽サイトにアクセスしてしまったときにフィッシングの 手口によるメールサービスPへの不正アクセスを防ぐこと Tさんが調査したところ,メールサービスPは,単体ではパスワード認証にしか対 応していないが,認証連携の機能があることが分かった。認証連携機能を使えば, メールサービスPにアクセスしようとしたときに,他のID管理サービスにリダイレ クトされ,そこで認証が行われ,認証に成功すると,メールサービスPにアクセスで きるようになる。そこで,X社が提供するクラウドサービス型ID管理サービス(以 下,IDaaS-Xという)が対応している,より強力な認証方式を利用することにした。 IDaaS-Xでは,認証サーバXを使って利用者を認証する。 IDaaS-Xが対応している,より強力な認証方式には,次の2種類がある。 ・ワンタイムパスワード(以下,OTPという)認証方式 TOTP(Time-based One-Time Password algorithm)用のスマートフォンアプリケー ションプログラム(以下,TOTPアプリという)を利用した認証方式 ・パスワードレス認証方式 WebAuthn(Web Authentication API)対応のWebブラウザ及び生体認証対応のオー センティケータを搭載したデバイスを利用した認証方式 Tさんは二つの認証方式について,要求1及び要求2を満たすことができるかを検 討した。 ー11一 Tさんは,まずOTP認証方式を検討した。IDaaS-XにおけるTOTPアプリ登録処 理を図3に,OTP認証方式の認証処理を図4に示す。 TOTPアプリ(利用者がIDaaS-Xにログイン済み)認証サーバX Webブラウザ OTP認証方式の利用登録要求 共通鍵を生成・登録| a fia ee カメラでQRコードを読取り aドメイン,共通負を登録 ドメイン:IDaaS-Xのドメイン名 図3 IDaaS-XにおけるTOTPアプリ登録処理 Webブプラウザ|; TOTPアプリ(利用者がIDaaS-Xに未ログイン)認証サーバX 認証要求(利用者ID,パスワード) ||現在時刻,共通鍵からOTF算出 利用者ID,。パスワードの検証| ;OTP要求 利用者がOTPを入力 OTP 現在時刻,共通鍵からOTPを検証 利用者IDに対する共通鍵を選択| 利用者IDの認証結果 図4 IDaaS-XにおけるOTP認証方式の認証処理 OTP設証方式を利用した場合,ログインには時刻によって変化するOTPも必要に なるので,パスワードが綿取された場合でも不正ログインを防ぐことが可能となる。 しかし,@OTP認証方式を利用し,DO,登録処理を正しく行ったとしても,要求2 を満たすことができないおそれがある。 次にTさんは,パスワードレス認証方式を検討した。IDaaS-Xにおけるオーセンテ ィケータ登録処理を図5に,認証処理を図6に示す。 、Webプラウザ オーセンティケータリ!(利用者がIDaaS-Xにログイン済み)認証サーバ双 オーセンティケータの登録要求 乱数cを生成| 利用者ID,KATY,乱数c 利用者ID,KATY,H(オリジン(bb||乱数c) 生体認証によって,現在の利用者が利用者IDに 結びついていることを確認 利用者IDとドメインの組みに対してIDcを発行 IDcごとの公開鍵K,秘密鍵Kを生成 IDc,利用者ID,ドメイン,公開鍵K,秘密鍵K の組合せを登録 |<|を用いて署名しを生成 IDc,H(ドメイン),公開鍵K,証明書A,署名L|Ic,H(ドメイン),公開鍵K, 証明書A,オリジンb,乱数c,BAL オリジンbとオリジンsの一致を確認 乱数<の一致を確認 証明書Aを検証 |d|を用いて和署名しを検証 利用者ID,IDc,公開鍵Kの組合せを登録 H(A):Aのハッシュ値 A||B:AとBを連結 オリジンb:WebブラウザがアクセスしたWebサイトのオリジン オリジンs:認証サーバXのWebサイトのオリジン IDc:利用者IDとドメインの組みに対して,オーセンティケータごとに発行されるID 署名L:IDc,H(ドメイン),公開鍵K,H(オリジンbb||乱数<た)に対するディジタル署名 注りオーセンティケータには,搭載されたデバイスごとにユニークな公開鍵A,MHRA,及び 証明書Aが組み込まれている。ここで,証明書Aは,信頼された認証局が発行した,公開鍵A に対するディジタル証明書である。 図5 IDaaS-Xにおけるオーセンティケータ登録処理 オーセンティケータ(利用者がIDaaS-Xに未ログイン)認証サーバX Webブラウザ 認証要求(利用者D) 利用者IDに対するIDcを選択 H(オリジンb||乱数c)De,ドメイン,乱数 利用者ID,IDc,ドメイン,ーー乱数c^を生成 生体認証によって,現在の利用者が利 用者IDに結びついていることを確認 利用者IDとドメインの組みに対する IDc及び|e|を取得 |<|を用いて署名Mを生成 IDc,H(ドメイン),署名M IDc,H(ドメイン),オリジンb,ALA’, BLM オリジンbとオリジンsの一致を確認 IDc,乱数<*の一致を確認 IDcに対する|f exer (ft|を用いて署名Mを検証 利用者IDの認証結果 署名M:H(ドメイン),H(オリジンb||We’)に対するディジタル署名 図6 IDaaS-Xにおけるパスワードレス認証方式の認証処理 ④パスワードレス認証方式を利用すれば,要求2を満たすことができると考えられ Tog Tさんは,検討結果を情報システム部長に報告した。情報システム部長は,海外拠 点QにおけるメールサービスPへのパスワードレス認証方式の導入を,さん及びY さんに指示した。 海外拠点で従業員に貸与しているスマートフォンとノートPCにはオーセンティケ ータが搭載されていたので,パスワードレス認証方式を速やかに導入することがで きた。 U社では,他の海外拠点でのクラウドサービスについても,同様の方式を導入する Clee.

共通の文章

IoT機器の開発に関する次の記述を読んで,設問1こ3に答えよ。 V社は,IoT機器を製造・販売している従業員数3.000名の会社である。家庭用ゲ ーム機(以下,ゲーム機Vという)の発売を予定しており,設計を開発部が担当し ている。設計リーダは,開発部のHさんである。利用者はゲーム機Vとゲームプロ グラムの利用権を購入し,ゲーム機Yからゲームサーバ上のゲームプログラムを利 用する。複数のゲームプログラム開発会社が,それぞれ複数のゲームプログラムを 開発し,販売する予定である。開発部が設計したゲーム機V,認証サーバ及びゲーム サーバ(以下,三つを併せてゲームシステムVという)の構成を図1に,構成要素 とその概要を表1に示す。 ゲーム機Vリン7へヽへへ 専用OSーー7 NT aoa saa>N 利用者認証プログラム —ゲームサーバ1 クラウドV:V社が用意したク ラウドサービス 注記1ファイアウォールなどのネットワーク機器は省略している。 注記2ゲーム機Vと各サーバとの間の通信には,HTTP over TLSを使用する。 注!利用者ID,パスワードのハッシュ値,ニックネーム,性別及び誕生日から成る。 2利用者ID,利用者が購入したゲームプログラムのゲームプログラムIDから成る。 図1ゲームシステムVの構成(概要) 表1ゲームシステムVの構成要素とその概要 構成要素 ゲーム機V・無線LAN機能.コントローラ"及びディスプレイを備えている。 ・専用0Sがインストールされており,ブートローダから起動される。 ・専用0Sに含まれる通信プログラムは,ゲームサーバ上のゲームプログラム及 び認証サーバ上の利用者認証プログラムと通信する。 ・通信プログラムは,コントローラの操作情報をとをリアルタイムにゲームプログラ ムに送信し,ゲームプログラムからゲームの処理結果をゲーム画面として受信 してディスプレイに表示する。 ・ゲーム機Vごとに一意のデバイスIDが付与される。 ・ゲーム機Vごとに発行されたクライアント証明書を格納している。各サーバと の通信時には,クライアント証明書を使用したクライアント認証が行われる。 ・各サーバとの通信時には,サー認証を行いクラウドV中のサーバとだけ通 信を行う。 ・初期セットアップ時に認証サーバに利用者情報を登録する。 ・PCに接続しても外部ストレージとして認識されず,内部のデータを直接読み 出すことはできない。 ゲームサーバ|・クラウドVに複数のゲームプログラム開発会社がそれぞれゲームサーバを立ち EW,各ゲームサーバでーー又は複数のがゲームプログラムを乏働させる。 ・ゲームプログラム開発会社のゲームサーバ管理者が運用する。 ・各ゲームプログラムには,固有のゲームプログラムIDが付与される。 ・ゲームサーバごとに発行されたサーバ証明書を格納している。 認証サーバ・利用者情報と購入情報を管理する。 ・利用者認証プログラムは,ゲーム機Vがゲームプログラムを利用する際の利用 者の認証を行う。認証の結果,利用者が購入したゲームプログラムだけの利用 を許可する。 ・認証サーバに発行されたサーバ証明書を格納している。 注りゲームを行う際などに使用する入力装置 ゲームを行う際は図2の認証フローで利用者の認証が行われる。 ゲーム機Vの認証サーバの利用ゲームサーバの 通信プログラム者認証プログラムゲームプログラム 1.利用者IDとパスワード 2.アクセス可能なゲームプログラムIDの一覧 3.アクセスするゲームプログラムID 4.認証トークンとゲームプログラムのURL! es ee 注記1.又は5.で認証に失敗した場合は,ゲーム機Vに認証エラー画面が送信される。 注りURLはゲームプログラムごとに固有である。 図2利用者がゲームを行う際の認証フロー 認証トークンには,認証サーバのFQDN,利用者ID及びMAC(Message Authentication Code)が格納される。①MACは,認証サーバのFQDNと利用者IDに WOT,ハッシュ関数を共通鍵と組み合わせて使用し,生成する。共通鍵は,ゲー ムシステムV全体でーつの鍵が使用され,ゲームサーバ管理者がゲームプログラム に設定する。図2の5.Cl,ゲームプログラムによる認証トークンのMACの検証 が成功し,かつ,FQDNが確かに認証サーバのものであることが確認された場合だ け,認証が成功し,図2の6.でゲームプログラムからゲーム画面が送信される。 [セキュリティレビューの実施〕 認証トークンが認証サーバ以外で不正に生成されると,購入していないゲームプ ログラムを利用されたり,クラウドV上のリソースを不正に利用されたりするおそ れがある。そこで仮に認証サーバ以外で認証トークンを生成されたとしてもゲーム プログラムでは検証に失敗することが求められる。また,利用者がコントローラの 不正な操作情報をゲーム機Vから送信することによって,ゲームを有利に進めると いったことも防ぐ必要がある。 V社では,システム設計にセキュリティ上の問題がないか,製品の設計工程でセキ ュリティレビュー(以下,レビューという)を実施することになっており,ゲーム システムVはセキュリティ部のNさんがレビューを担当することになった。次は, NさんがゲームシステムVのレビューを行った時の,さんとの会話である。 Nさん:現状の認証トークンの設計には二つの問題があります。一つ目の問題は, 現在の設計では認証トークンに格納される情報が不足しているということ です。情報が不足していることによって,ゲームプログラムA用の認証ト ークンがゲームプログラムBにおいても認証に成功してしまうので,攻撃 者がゲームプログラムのURLを知ることができればぱば,購入していないゲー ムプログラムも利用できてしまいます。②この問題への対策を検討してく JES Ws HSA:分かりました。 Nさん:二つ目の間題は,③認証トークンをゲームサーバ管理者が不正に生成でき てしまうことです。 ー18一 H SA:その間題への対策としては,ゲームプログラムごとに別の共通鍵を利用す るという設計はどうでしょうか。 Nさん:それでは対策として不十分です。④その設計にしたとしても,不正にゲー ムプログラムが利用できる認証トークンをゲームサーバ管理者が生成でき てしまいます。 Hさん:MACではなく,ディジタル署名を利用すれば対策になりますか。 Nさん:はい。そうすればゲームサーバ管理者が認証トークンを不正に生成したと しても,ゲームプログラムてで検証が失敗します。 Hさん:では,|』|で公開鍵と秘密鍵の鍵ペアを生成し,|b|をゲー ムサーバに配布しておきます。| 。|]が|。]を使って誰証ト ークンに暑名を付加し,ゲームプログラムでは| b|を使って署名の 検証を行います。 Nさん:それで問題ありません。次に,不正な機器から認証サーバとゲームサーバ へのアクセスをどのようにして防ぐのか教えてください。 Hさん:クライアント認証を使います。 Nさん:ゲーム機V内のクライアント証明書とそれに対応する秘密鍵(以下,HEC という)が攻撃者のPCから不正に使用できると,そのPCから各サーバに 接続されてしまいます。さらに,コントローラの操作情報を改ざんして送 信することによって,ゲームを有利に進めることも考えられます。クライ アント証明書と鍵Cはゲーム機Vのどこに格納しますか。 Hさん:鍵Cを含めた全てのデータは,搭載するSSD(Solid State Drive)に格納し ます。搭載するSSDは,広く流通しているものです。 Nさん:それでは問題がありますね。現状の設計では,専用OSに脆弱性が存在しな かったとしても,⑤攻撃者がゲーム機Vを購入すれば,専用0Sを改ざんせ ずに,ゲーム機V内のクライアント証明書と鍵CをPCなどから不正に使 用できます。 Hさん:どのように対策したらいいでしょようか。 Nさん:TPM(Trusted Platform Module)をゲーム機Vに搭載し,TPM内に鍵Cを 保存するという方法があります。TPMは,⑥内部構造や内部データを解析 されにくい性質を備えているので,TPM内に鍵Cを保存すれば不正に読み ー19— 取ることは困難になります。 また,ブートローダ又は専用0Sの改ざんはゲーム機Vの不正利用につなが ります。例えば,コントローラの不正な操作情報を送信されるおそれがあ ります。そのため,ブートローダ及び専用0Sの改ざん対策についても検討 しでください。 Hさん:分かりました。設計を見直します。 [ブートローダ及び専用0Sの改ざん対策〕 2回目のレビューでは,ブートローダ及び専用0Sの改ざん対策について確認した。 次は,その時のHfさんとNさんの会話である。 Hさん:ブートローダ及び専用0Sの改ざんに備えた対策として,ブートローダ又は 専用0Sが改ざんされていると判定されたときは,ゲーム機Vの起動処理を 中止するようにしました。ブートローダ及び専用0Sの改ざん対策の処理の 流れを図3に示します。 1.ブートローダ及び専用OS中の起動時に実行されるファイルのハッシュ値をあらかじめ計算 し,ハッシュ値のリスト(以下,ハッシュ値リストという)を作成しておく。ゲーム機Vへ の専用OSの導入時,ハッシュ値リストを併せて保存する。起動時に専用0S中のファイルが 実行される順番は,あらかじめ決められている。 2.ゲーム機Vの起動時には,CRTM(Core Root of Trust for Measurement)と呼ばれる,改ざん が困難な起動コードから起動処理を開始する。 3.CRTMは,ブートローダのハッシュ値を計算し,そのハッシュ値がハッシュ値リスト中に存 在することを確認できたら実行する。| 4.ブートローダは,BA OSの最初に実行されるファイルのハッシュ値を計算し,ハッシュ値 リスト中に存在することを確認し,実行する。同様に,後続のファイルについて計算,確認, 実行を繰り返し,専用0Sが起動する。 5.ハッシュ値がハッシュ値リスト中に存在しないファイルは改ざんされていると判定され,起 動処理が中止される。 図3ブートローダ及び専用0Sの改ざん対策の処理の流れ Nさん:処理の流れは分かりました。ハッシュ値リストが保護されていないと,改 ざんされたファイルが実行されるおそれがありますが,どのように対策し ていますか。 Hさんは,⑦ハッシュ値リストを保護するための方法を説明した。 Nさん:それであれば,改ざんされたファイルが実行される危険性は低いですね。 その後,クラウドVの準備が整い,ゲーム機Vが発売された。