情報処理安全確保支援士午後II 事例記述令和5年 春期
午後II 問2

午後II 問2 Webサイトのクラウドサービスへの移行と機能拡張

テーマ:Webサイトのクラウドサービスへの移行と機能拡張
左右2分割表示:左側の問題文をスクロールしながら右側の設問に解答できます

長文事例本文

図表クリックで拡大
W社は,従業員100名のブログサービス会社であり,日記サービスというWebサービスを10年前から提供している。日記サービスの会員は,自分の食事に関する記事の投稿及び摂取カロリーの管理ができる。 日記サービスは,W社のデータセンター内で稼働している。ハードウェアの調達には1か月程度を要する。W社は,日記サービスが稼働している各機器の運用をD社に委託している。D社に委託している運用を表1に示す。
表1 D社に委託している運用(概要) 拡大
表1 D社に委託している運用(概要)
この2,3年,会員が急増しているので,W社は,日記サービスをクラウドサービスに移行することにした。 〔移行先のクラウドサービス選定〕 W社は,クラウドサービスへの移行時及び移行後の管理,運用について,検討を開始した。 まず,クラウドサービスへの移行時及び移行後に,W社が何を管理,運用する必要があるかを調べたところ,表2のとおりであった。
表2 W社が管理,運用する必要のある範囲 拡大
表2 W社が管理,運用する必要のある範囲
クラウドサービスへの移行及びクラウドサービスの設定はW社が行い,移行後,表1の項番1〜項番3の運用をD社に委託する計画にした。 移行先のクラウドサービスとして,L社のクラウドサービスを選定した。L社が提供しているクラウドサービスを表3に示す。
表3 L社が提供しているクラウドサービス 拡大
表3 L社が提供しているクラウドサービス
イベント検知のルールはJSON形式で記述する。そのパラメータを表4に示す。
表4 イベント検知のルールに記述するパラメータ 拡大
表4 イベント検知のルールに記述するパラメータ
仮想マシンサービスを利用して構築した,システムIDが0001のシステムにおいて,利用者IDが1000である利用者が仮想マシンを停止させた場合の,イベント検知のルールの例を図1に示す。
図1 イベント検知のルールの例 拡大
図1 イベント検知のルールの例
〔日記サービスのL社のクラウドサービスへの移行〕 移行後の日記サービスの仮想ネットワーク構成を図2に,図2中の主な構成要素を表5に示す。
図2 移行後の日記サービスの仮想ネットワーク構成 拡大
図2 移行後の日記サービスの仮想ネットワーク構成
表5 図2中の主な構成要素 拡大
表5 図2中の主な構成要素
W社は,L社のクラウドサービスにおける,D社に付与する権限の検討を開始した。 〔L社のクラウドサービスにおける権限設計〕 L社の各クラウドサービスにおける権限ごとに可能な操作を表6に示す。
表6 L社の各クラウドサービスにおける権限ごとに可能な操作(抜粋) 拡大
表6 L社の各クラウドサービスにおける権限ごとに可能な操作(抜粋)
W社は,D社に付与する権限が必要最小限となるように,表7に示すD社向けの権限のセットを作成した。
表7 D社向けの権限のセット(抜粋) 拡大
表7 D社向けの権限のセット(抜粋)
さらに,W社は,①D社の運用者がシステムから日記サービスのログを削除したときに,そのイベントを検知してアラートをメールで通知するための検知ルールを作成した。 W社は,L社とクラウドサービスの利用契約を締結して,日記サービスをL社のクラウドサービスに移行し,運用を開始した。 〔機能拡張の計画開始〕 W社は,サービス拡大のために,機能を拡張した日記サービス(以下,新日記サービスという)の計画を開始した。新日記サービスの要件は次のとおりである。 要件1:会員が記事を投稿する際,他社のSNSにも同時に投稿できること 要件2:スマートフォン用のアプリ(以下,スマホアプリという)を提供すること W社は,要件1を実装した後で要件2に取り組むことに決めた。その上で,要件1を実現するために,T社のSNS(以下,サービスTという)と連携することにした。 〔サービスTとの連携の検討〕 OAuth 2.0を利用してサービスTと連携した場合のサービス要求から記事投稿結果取得までの流れを図3に,送信されるデータを表8に示す。
図3 サービス要求から記事投稿結果取得までの流れ 拡大
図3 サービス要求から記事投稿結果取得までの流れ
表8 送信されるデータ(抜粋) 拡大
表8 送信されるデータ(抜粋)
各リクエストの通信でTLS 1.2及びTLS 1.3を利用可能とするために,②暗号スイートの設定をどのようにすればよいかを検討した。また,サービスTとの連携のためのモジュール(以下,Rモジュールという)の実装から単体テストまでをF社に委託することにした。F社は,新技術を積極的に活用しているIT企業である。 〔F社の開発環境〕 F社では,Rモジュールの開発は,取りまとめる開発リーダー1名と,実装から単体テストまでを行う開発者3名のチームで行う。システム開発において,顧客から開発を委託されたプログラムのソースコードのリポジトリと外部に公開されているOSSリポジトリを利用している。二つのリポジトリは,サービスEというソースコードリポジトリサービスを利用して管理している。 サービスEの仕様と,RモジュールについてのF社のソースコード管理プロセスは,表9のとおりである。
表9 サービスEの仕様とF社のソースコード管理プロセス 拡大
表9 サービスEの仕様とF社のソースコード管理プロセス
〔悪意のある不正なプログラムコードの混入〕 F社は,Rモジュールの実装について単体テストまでを完了して,ソースコードをW社に納品した。その後,W社とT社は結合テストを開始した。 結合テスト時,外部のホストに対する通信がRモジュールから発生していることが分かった。調べたところ,不正なプログラムコード(以下,不正コードMという)がソースコードに含まれていたことが分かった。不正コードMは,OSの環境変数の一覧を取得し,外部のホストに送信する。新日記サービスでは,エンコード値GがOSの環境変数に設定されていたので,その値が外部のホストに送信されていた。 W社は,漏えいした情報が悪用されるリスクの分析と評価を行うことにした。それと並行して,不正コードMの混入の原因調査と,プログラムの修正をF社に依頼した。 〔W社によるリスク評価〕 W社は,リスクを分析し,評価した。評価結果は次のとおりであった。 ・エンコード値Gを攻撃者が入手した場合,mのWebサーバであると偽ってリクエストを送信できる。しかし,図3のシーケンスでは,③攻撃者が特定の会員のアクセストークンを取得するリクエストを送信し,アクセストークンの取得に成功することは困難である。 次に,W社は,近い将来に要件2を実装する場合におけるリスクについても,リスクへの対応を検討した。 そのリスクのうちの一つは,スマホアプリのリダイレクトにカスタムURLスキームを利用する場合に発生する可能性がある。W社が提供するスマホアプリと攻撃者が用意した偽のスマホアプリの両方を会員が自分の端末にインストールしてしまうと,正規のスマホアプリとサーバとのやり取りが偽のスマホアプリに横取りされ,攻撃者がアクセストークンを不正に取得できるというものである。この対策として,PKCE(Proof Key for Code Exchange)を利用すると,偽のスマホアプリにやり取りが横取りされても,アクセストークンの取得を防ぐことができる。 要件2を実装する場合のサービス要求から記事投稿結果取得までの流れを図4に示す。
図4 要件2を実装する場合のサービス要求から記事投稿結果取得までの流れ 拡大
図4 要件2を実装する場合のサービス要求から記事投稿結果取得までの流れ
PKCEの実装では,乱数を基に,チャレンジコードと検証コードを生成する。(3)のリクエストにチャレンジコードとcode_challenge_methodパラメータを追加し,(7)のリクエストに検証コードパラメータを追加する。最後に,④認可サーバが二つのコードの関係を検証することで,攻撃者からのアクセストークン要求を排除できる。 〔F社による原因調査〕 F社は,不正コードMが混入した原因を調査した。調査の結果,サービスEのOSSリポジトリ上に,Xトークンなどの情報が含まれるファイル(以下,ファイルZという)がアップロードされた後に削除されていたことが分かった。 F社の開発者の1人が,ファイルZを誤ってアップロードし,承認した後,誤ってアップロードしたことに気付き,ファイルZを削除した上で開発リーダーに連絡していた。開発リーダーは,ファイルZがOSSリポジトリから削除されていること,ファイルZがアップロードされてから削除されるまでの間にダウンロードされていなかったことを確認して,問題なしと判断していた。 F社では,⑤第三者がXトークンを不正に取得して,リポジトリWに不正アクセスし,不正コードMをソースコードに追加したと推測した。そこで,F社では,Xトークンを無効化し,次の再発防止策を実施した。 ・表9中のバージョン管理に関わる見直しと⑥表9中の権限管理についての変更 ・Xトークンが漏えいしても不正にプログラムが登録されないようにするための,⑦表9中のサービス連携に関わる見直し ソースコードには他の不正な変更は見つからなかったので,不正コードMが含まれる箇所だけを不正コードMが追加される前のバージョンに復元した。 W社は,F社が改めて納品したRモジュールに問題がないことを確認し,新日記サービスの提供を開始した。

設問一覧 & 解答・演習

まずは解答を作成してみましょう。「解答例を見る」をクリックするとIPA公式解答例と採点基準が開きます。

設問1記号・選択式
表2中の a 〜 i に入れる適切な内容を、“○”又は“×”から選び答えよ。
※直接入力してください
設問2 (1)記号・選択式
〔L社のクラウドサービスにおける権限設計〕について答えよ。
表7中の j 〜 l に入れる適切な字句を,解答群の中から選び,記号で答えよ。
【空欄スロット選択】 割り当てる空欄を選んでから下の選択肢をクリック:
選択中の解答:未選択(上の選択肢ボタンをクリックしてください)
設問2 (2)記号・選択式
〔L社のクラウドサービスにおける権限設計〕について答えよ。
本文中の下線①のイベント検知のルールを,JSON形式で答えよ。ここで,D社の利用者IDは,1110〜1199とする。
※直接入力してください
設問3 (1)記号・選択式
〔サービスTとの連携の検討〕について答えよ。
本文中,図3中及び図4中の m 〜 o に入れる適切な字句を,“新日記サービス”又は“サービスT”から選び答えよ。
※直接入力してください
設問3 (2)記号・選択式
〔サービスTとの連携の検討〕について答えよ。
表8中の p , q に入れる適切な番号を,図3中の番号から選び答えよ。
※直接入力してください
設問3 (3)記号・選択式
〔サービスTとの連携の検討〕について答えよ。
本文中の下線②について,CRYPTRECの“電子政府推奨暗号リスト(令和4年3月30日版)”では利用を推奨していない暗号技術が含まれるTLS 1.2の暗号スイートを,解答群の中から全て選び,記号で答えよ。
【選択肢】 クリックして選択(複数選択可)
選択中の解答:未選択(上の選択肢ボタンをクリックしてください)
設問4 (1)記述問題
制限字数:40 字以内
〔W社によるリスク評価〕について答えよ。
本文中の下線③について,アクセストークンの取得に成功することが困難である理由を,表8中のパラメータ名を含めて,40字以内で具体的に答えよ。
0 / 40 文字
設問4 (2)記述問題
制限字数:70 字以内
〔W社によるリスク評価〕について答えよ。
本文中の下線④について,認可サーバがチャレンジコードと検証コードの関係を検証する方法を,“ハッシュ値をbase64urlエンコードした値”という字句を含めて,70字以内で具体的に答えよ。ここで,code_challenge_methodの値はS256とする。
0 / 70 文字
設問5 (1)記述問題
制限字数:40 字以内
〔F社による原因調査〕について答えよ。
本文中の下線⑤について,第三者がXトークンを取得するための操作を,40字以内で答えよ。
0 / 40 文字
設問5 (2)記述問題
制限字数:50 字以内
〔F社による原因調査〕について答えよ。
本文中の下線⑥について,権限管理の変更内容を,50字以内で答えよ。
0 / 50 文字
設問5 (3)記述問題
制限字数:40 字以内
〔F社による原因調査〕について答えよ。
本文中の下線⑦について,見直し後の設定を,40字以内で答えよ。
0 / 40 文字
午後長文記述の得点力を引き上げる定番対策書Amazon・楽天 公式提携
PR
うかる! 情報処理安全確保支援士 午後問題集 [第2版]
IPA 厳選対策書うかる! 情報処理安全確保支援士 午後問題集 [第2版]村山 直紀 著 / 日本経済新聞出版
午後記述バイブル
村山 直紀 著 / 日本経済新聞出版

うかる! 情報処理安全確保支援士 午後問題集 [第2版]

💡 推薦ポイント:午後試験の長文事例でどこに着目して脆弱性と対策を抜き出すか、合格答案の記述テンプレートを効率よく習得できます。
※本リンク先はプロモーション(アフィリエイト広告)が含まれています
【出題趣旨】IPA公式発表
近年,クラウドサービスへの移行が加速する中で,セキュリティについてオンプレミスとは異なる知見が求められている。また,外部サービスとの連携が増加しているが,セキュアではない設定がされるケースも散見される。 本問では,Webサイトのクラウドサービスへの移行と機能拡張を題材として,自社システムからクラウドサービスへの移行時及び移行後におけるセキュリティに関わる設定と,外部サービスと連携する際の認可,権限設定についての分析能力を問う。
【採点講評】IPA公式発表
問2では,Webサイトのクラウドサービスへの移行と機能拡張を題材に,権限設定及び認可に関連するセキュリティ対策について出題した。全体として正答率は平均的であった。 設問3(2)qは,正答率がやや低かった。HTTPレスポンスである(8)と誤って解答した受験者が多かった。HTTPプロトコルの理解を深め,HTTPリクエストとHTTPレスポンスとのデータの違いをよく確認しておいてほしい。 設問4は,(1),(2)ともに正答率が低かった。OAuth 2.0のメカニズムについては,用語だけではなく,その具体的な方法を理解してほしい。また,ハッシュ関数など,暗号技術の基礎的な仕組みを理解しておくことが認証認可の中で使われるPKCEなどのメカニズムを理解する上でも重要であることを知ってほしい。 設問5(1)は,正答率が低かった。インシデントの再発防止では,受けた攻撃の経路を特定することが重要であることを知っておいてほしい。 設問5は,(2),(3)ともに正答率がやや高かった。権限は,利用者には必要最小限しか与えないよう,慎重に検討することが求められる。業務などの要件と照らし合わせて,設定が必要最小限かどうかを確認してほしい。
本番形式・制限時間付きで演習する
令和5年 春期 午後(2問選択・150分)を実戦演習モードで通し解答し、総合採点を受けられます。
実戦演習を始める