問1 百貨店における Web サイトの統合
百貨店における Web サイトの統合に関する次の記述を読んで，設問 1〜5 に答えよ。
C 社は，半年ほど前に旧 A 社と旧 B 社が合併してできた会社である。旧 B 社が存続会社となり，旧 A 社の事業を承継した上で，C 社に改称した。C 社は，旧 A 社の 10 店舗の百貨店（以下，A 百貨店という）と，旧 B 社の 5 店舗の百貨店（以下，B 百貨店という）を運営している。
C 社は，旧 A 社が発行していたクレジットカードの会員向け Web サイト（以下，サイト P という），A 百貨店の取扱商品を販売するオンラインストア Web サイト（以下，サイト Q という），及び旧 B 社のポイントカードを保有する会員向け Web サイト（以下，サイト R という）を運営している。
合併後，旧 A 社クレジットカードの B 百貨店での利用を促進したり，旧 B 社ポイントカードの A 百貨店での利用を可能にしたりするなど，両社の顧客サービスの融合に力を入れている。表 1 は，サイト P，Q，R の概要である。
〔機器の集約と運用作業の効率化〕
C 社では，運用作業を効率化するために，別々の場所に設置されていた各サイトを構成する機器を 1 か所のデータセンタに集約するとともに，これらの機器を管理する Web 管理課を新設した。機器集約後のネットワーク構成は図 1 のとおりである。
サイト P，Q，R は，それぞれ独立して運営されている。いずれのサイトも，アカウント情報はサイトごとに設置した LDAP サーバのユーザエントリとして管理しており，ログイン時の認証には，各 LDAP サーバのユーザエントリ内の利用者 ID とパスワードを利用している。
〔サイト間でのアカウントの共通利用〕
C 社では経営戦略の一環として，三つのサイトで収集した情報から顧客の購買傾向を分析することにした。そこで，サイト P，Q，R でクロス分析などの手法を用いて購買傾向を分析する上で，各サイト間で同一の顧客を特定するために，サイト P，Q，R 相互間でのアカウントの共通利用を実現することにした。
アカウントの共通利用では，次の三つの利用方法のいずれかを各顧客に選択してもらうことにした。
- (1) サイト P のアカウントを親アカウントとし，サイト Q，R のアカウントを子アカウントとして，子アカウントを親アカウントに紐付ける。主に旧 A 社の顧客向けである。
- (2) サイト R のアカウントを親アカウントとし，サイト P，Q のアカウントを子アカウントとして，子アカウントを親アカウントに紐付ける。主に旧 B 社の顧客向けである。
- (3) アカウントの共通利用をしない。
顧客がアカウントの紐付けを設定すれば，子アカウントの代わりに親アカウントを用いて各サイトにログインできる。
〔アカウントの共通利用の設計〕
Web 管理課の J 主任は，アカウントの共通利用の設計を任された。J 主任は，アカウントの共通利用を実現するために，次の四つを行うことにした。
- (1) サイト P，Q，R のログイン処理を変更する。
- (2) LDAP-P，LDAP-R で管理するアカウント情報に，紐付け情報を保存する。具体的には，LDAP-P のユーザエントリに siteQid，siteRid 属性を追加して，当該アカウントに紐付けた子アカウントの利用者 ID を保存する。LDAP-R のユーザエントリには，sitePid，siteQid 属性を追加する。なお，紐付け前の sitePid，siteQid，siteRid には，空文字列が設定される。
- (3) Web-P，Web-R の Web アプリケーションプログラム（以下，Web アプリケーションプログラムを Web アプリという）に，アカウントの紐付け機能を追加する。サイト P のアカウントを親アカウントとし，サイト Q のアカウントを子アカウントとして紐付けるときのサイト P の画面と処理内容は図 2 のとおりである。
- (4) FW-P，Q，R のルールに対して必要な変更を行う。例えば，変更後の FW-P のルールは，表 2 のようにする。
〔個人情報の取扱い〕
J 主任は，C 社の法務担当の M さんに，アカウントの共通利用について説明し，個人情報の取扱いの観点から問題がないかどうか相談した。M さんは，合併前後の個人情報の利用目的の内容について確認した。
確認後，M さんは，アカウントの共通利用には，顧客に対して利用目的の変更を通知して，同意を得る必要があると指摘した。
指摘を受け，J 主任は，顧客がアカウントの共通利用を選択したときに，個人情報の利用目的の変更を通知するとともに，変更後の利用目的を明示して同意を得る機能を加えることにした。
〔コードレビュー〕
アカウントの共通利用の設計を終えた J 主任は，サイト P の Web アプリの改修に着手した。
図 3 及び図 4 は，サイト P のアカウントにサイト Q のアカウントを紐付ける場合のサイト P 上での紐付け処理の Java ソースコードである。
利用者が，サイト P にログイン後，図 2 の画面を操作し，“紐付け”ボタンをクリックした場合，図 4 の行番号 101 の siteID にサイトの識別文字列として“siteQ”が代入された状態で図 4 のコードの実行が開始される。図 4 のコードが正常に終了したら，紐付けが完了したことを表示する。
J 主任は，情報処理安全確保支援士（登録セキスペ）の K 主任とともにコードレビューを実施した。K 主任は，次のような特定の状況では，サイト P のある利用者のアカウントに，サイト Q の他人のアカウントが紐付いてしまうと指摘した。
- (1) 図 2 で，サイト Q の利用者 ID 欄に誤った利用者 ID を入力する。
- (2) 図 4 のコードが呼び出され，cに誤った利用者 ID が代入されたまま，dが呼び出される。
- (3) 何らかの理由で，d中の図 3 中の行番号eでfが発生し，結果としてdが再試行される。
- (4) dが 3 回試行され，全て同じくfが発生すると，gの値は true なので，図 4 中の行番号hに進み，紐付けが行われる。
K 主任は，図 3 の 32 行目前後に着目し，iという修正案を提示した。
〔サイト R でのインシデント〕
リリースに向けて準備を進めていたところ，インシデント発生の報告があった。発端は，ある顧客からの指摘で，その内容は，“サイト R のキャンペーン応募履歴を見たら，3 月のキャンペーンに応募したことになっているが，身に覚えがない。3 月にはサイト R に一度もアクセスしていないはずだ。”というものであった。
J 主任が，サイト R のアクセスログを確認したところ，次のことが分かった。
- 3 月 30 日に，当該顧客のアカウントでキャンペーンに応募していた。
- 応募の直前にパスワード失念時の処理を実行し，パスワードを電子メール（以下，メールという）で未登録のメールアドレスに送信した記録がある。
- 3 月 25 日から 3 月 31 日に掛けて，サイト R への通信量が増加傾向にあった。
図 5 は，サイト R のパスワード失念時の操作画面である。
J 主任は，攻撃者がパスワード失念時の処理を悪用して，会員番号及び誕生日を総当たりで入力し，たまたま合致した当該顧客のアカウントを乗っ取ったものと判断した。J 主任は，このインシデントについて Web 管理課の L 課長に報告した。L 課長は旧 A 社出身で，この報告でサイト R のパスワード失念時の操作を初めて知った。次は，その報告の時の L 課長と J 主任の会話である。
- L 課長：サイト R のパスワード失念時の処理には，三つの問題があるね。一つ目は，本人であることを確認するための情報が少なすぎるという問題だ。そこは後で解決するとしよう。二つ目は，パスワードそのものをメールで送るという問題だ。三つ目は，jという問題だ。二つ目と三つ目の問題の解決には，kように改修すべきだ。この方法では，一部の利用者はパスワード失念時にログインできなくなるが，その場合はコールセンタで対応することにしよう。
- J 主任：はい。分かりました。
- L 課長：サイト R では，攻撃者がアカウントを乗っ取ったとしても，あまり経済的利益を得られないので，今回のような被害で済んだと考えられるが，直ちに改修を完了させてほしい。もしもこれらの問題に気付かずにアカウントの共通利用を提供していたら，①利用者に更に大きな被害が発生するところだった。アカウントの共通利用の設計，及びリリースまでのスケジュールも見直してほしい。
〔アカウントの共通利用の設計の見直し〕
J 主任は，次のように全面的に設計を見直し，承認を得た。
- サイト S を立ち上げ，新たにサイト S のアカウントを発行して管理する。
- アカウントの共通利用に当たり，アカウントの紐付け時とサイト P，Q，R へのログイン時には，SAML プロトコルの Web Browser SSO Profile を用いる。サイト S が，IdP（Identity Provider）となり，サイト P，Q，R は，SP（Service Provider）となる。
- サイト Q には，サイト Q のアカウントでも，サイト Q のアカウントと紐付けたサイト S のアカウントでもログインできる。サイト P，R も同様である。
図 6 は，Web Browser SSO Profile の基本的な通信の流れである。
図 7 は，紐付け済みのサイト S のアカウントでサイト Q にログインするときの画面遷移図である。
図 8 は，サイト Q のアカウントとサイト S のアカウントを紐付けるときの画面遷移図である。
〔見直し後のアカウント共通利用の提供開始〕
C 社は，サイト P，Q，R の改修とサイト S の開発を完了して，アカウント共通利用の提供を開始し，順調に運用を続けた。サイト P，Q，R のアカウントの廃止，及びサイト S のアカウントへの統合を目指している。この統合が実現すれば，図 7 の（あ）や，図 8 の（え），（お）などの画面は不要となり，より使いやすいサイトを実現できる。
出題趣旨（IPA）
情報システムの構築時にはリスク分析を行うが，運用開始後の改修時やほかのシステムとの機能統合時にはリスク分析が行われていない場合が見受けられる。リスク分析は，システムのセキュリティを確保するための重要な工程の一つであり，ここで不備があると後続の工程に悪影響を及ぼす。本問では，企業の合併に伴う複数のWebサイトの統合を題材に，リスク分析を行う能力，及びWebアプリケーションプログラムにおけるセキュアプログラミングの能力を問う。
採点講評（問全体・IPA）
問1では，企業の合併に伴う複数のWebサイトの統合を題材に，リスク分析と，Webアプリケーションプログラムにおけるセキュアプログラミングについて出題した。全体として，正答率は平均的であった。
設問と解答例
表 2 中のa，bに入れる適切な字句を答えよ。
〔a〕解答例
- LDAP-P，LDAP-Q，LDAP-R
〔b〕解答例
- LDAP
解説
本文の根拠
図 2 処理内容(i)
Web-P の Web アプリが，LDAP-Q に問合せて，入力されたサイト Q の利用者 ID とパスワードを用いて認証を行う。
図 3 行番号 39
サイト R に対して認証を行い，結果に応じて ERROR_ID_OR_PW 又は
表 2 注記 3
項番 4〜14 には，LDAP に関するルールは記述されていない。
表 2 は変更後の FW-P のルールで，項番 3 は送信元が Web-P の許可ルールである。Web-P で動く Web アプリは，サイト P のログインに加えて，アカウントを紐付けるときに，図 2 のとおり LDAP-Q に問い合わせて子アカウントの認証を行う。サイト R の子アカウントも，図 3 の行番号 39 のとおり同じように認証する。紐付け先の親アカウントは LDAP-P に保存するので，Web-P から LDAP-P，LDAP-Q，LDAP-R の三つの LDAP サーバへの通信が必要になる。したがって a は LDAP-P，LDAP-Q，LDAP-R，b は LDAP である。
図 1 のとおり，Web-P から LDAP-Q・LDAP-R へは FW-P を通り，L2SW を介して FW-Q・FW-R を通る経路になる。表 2 の注記 3 は項番 4〜14 に LDAP のルールが無いとしているので，LDAP の許可は項番 3 に全て書く必要があり，ここに書かなければ最後の項番 15 で拒否される。項番 2 は逆向き（Web-Q，Web-R から LDAP-P）の許可で，サイト P から他サイトへの通信は項番 3 でなければ許可されない。
字数制限は無いが，a は三つの LDAP サーバを全て挙げる点が間違えやすい。LDAP-P だけ，又は LDAP-Q・LDAP-R だけでは，紐付けか認証のどちらかが通らなくなる。
採点講評（IPA）
設問1aは，正答率が低かった。サイトPを運用するために，Web-PからLDAP-Pへの通信が必要だという点を考慮できていない解答が多かった。ファイアウォールの設定は，セキュリティ確保の基本なので，細心の注意を払う必要があることに留意してほしい。
〔個人情報の取扱い〕について，旧 A 社と旧 B 社の合併による C 社への事業承継に伴って取得した個人情報の取扱いに関し，個人情報保護法に定められている禁止事項は何か。70 字以内で述べよ。
解答例
- 本人の同意を得ないで，承継前における当該個人情報の利用目的の達成に必要な範囲を超えて，当該個人情報を取り扱ってはならない。
解説
本文の根拠
〔個人情報の取扱い〕
M さんは，合併前後の個人情報の利用目的の内容について確認した。
〔個人情報の取扱い〕
確認後，M さんは，アカウントの共通利用には，顧客に対して利用目的の変更を通知して，同意を得る必要があると指摘した。
問われているのは，合併による事業承継で取得した個人情報について，個人情報保護法が禁止していることである。解答例は“本人の同意を得ないで，承継前における当該個人情報の利用目的の達成に必要な範囲を超えて，当該個人情報を取り扱ってはならない。”である。事業を承継した C 社は，承継前の利用目的の範囲内でしか個人情報を使えず，その範囲を超えて使うには本人の同意が要る，という意味である。
本文でも，M さんは合併前後の利用目的を確認したうえで，アカウントの共通利用には利用目的の変更を通知して同意を得る必要があると指摘している。サイト P，Q，R のアカウントを紐付けて購買傾向を分析する使い方は，旧 A 社・旧 B 社で取得したときの利用目的に当たらない可能性があるため，同意が要る。
字数は 70 字以内で，解答例は 61 字である。“本人の同意を得ない”と“承継前の利用目的の達成に必要な範囲を超えて取り扱う”の二つの条件を残し，“禁止”で文末をそろえる。
採点講評（IPA）
設問2は正答率がやや低く，設問4は正答率が平均的であった。消費者向けのWebサイトでは，個人情報を取り扱うことが多いので，個人情報保護に関する法規制について，よく理解してほしい。
本文中のc，d，f，gに入れる適切な字句を，解答群の中から選び，記号で答えよ。 解答群 ア idPair.checkChild() イ idPair.childChecked ウ idPair.childID エ idPair.childPW オ idPair.childSite カ idPair.makeLink() キ idPair.parentID ク idPair.siteQAuth() ケ NamingException コ return ERROR_ID_OR_PW サ return NO_ERROR
〔c〕解答例
- ウ
〔d〕解答例
- ア
〔f〕解答例
- ケ
〔g〕解答例
- イ
解説
本文の根拠
図 3 行番号 19
childChecked = childSite.equals(
図 3 行番号 26
if (siteQAuth(childID, childPW) == NO_ERROR) {
図 4 行番号 105
result = idPair.checkChild();
図 4 行番号 113
if (!idPair.childChecked) {
K 主任が指摘した状況を順に追う。(1) 図 2 でサイト Q の利用者 ID に誤った ID を入力すると，図 4 の行番号 101 で作られる idPair の c に誤った ID が入る。AccountLink のコンストラクタは第 2 引数を childID に代入する（図 3 の行番号 14）ので，c は idPair.childID（ウ）である。(2) その状態で図 4 の行番号 105 が呼び出すのは idPair.checkChild()（ア）なので，d はア。
(3) checkChild() の行番号 19 は，サイトの識別文字列が正当なら childChecked を true にする。この時点で true になる。続く行番号 26 の siteQAuth で通信ができないなどの理由があると NamingException（ケ）が発生し，f はケ。この例外は checkChild() の外へ投げられ，図 4 の catch で再試行される。(4) 3 回とも同じ例外が出て，ループを抜けたときに行番号 113 で見る g は idPair.childChecked（イ）で，true のまま残っている。
コ（return ERROR_ID_OR_PW）やサ（return NO_ERROR）は戻り値で，代入先や発生するものではない。idPair.childPW（エ）は ID ではなくパスワードで，誤った ID が代入されるのは childID である点を取り違えない。
採点講評（IPA）
設問3と設問5では，Javaを題材として，Webアプリケーションプログラムにおけるセキュアプログラミングについて出題した。いずれも正答率が高かった。情報処理安全確保支援士の重要な業務の一つに，セキュリティの観点でのソースコードレビューが挙げられる。ソースコードレビューは，開発チーム全体の技術レベルを向上させる効果的な方法なので，ぜひとも今後の業務に生かしてほしい。
本文中のe，hに入れる適切な図 3 又は図 4 中の行番号を，解答群の中から選び，記号で答えよ。 解答群 ア 20 イ 23 ウ 26 エ 34 オ 105 カ 106 キ 117 ク 118
〔e〕解答例
- ウ
〔h〕解答例
- キ
解説
本文の根拠
図 3 行番号 26
if (siteQAuth(childID, childPW) == NO_ERROR) {
図 4 行番号 103
for (int retryCount = 1; retryCount < 4; retryCount++) {
図 4 行番号 117
idPair.makeLink();
e は，例外が発生する図 3 の行番号である。例外 NamingException を投げるのは siteQAuth（「必要な通信ができないなど，認証そのものが実行できない場合，例外 NamingException を投げる」）で，これを呼び出しているのは行番号 26 のウである。行番号 32 の throw e; は，catch した例外を呼出し元へ投げ直す行であり，発生源ではない。
h は，図 4 の行番号 113 の if が偽（childChecked が true）になったとき，行番号 114 の return を飛ばして進む先である。行番号 116〜117 の try の中で，idPair.makeLink() を呼び出して紐付けを実施するのは行番号 117（キ）である。行番号 118 は catch の行，行番号 105・106 はループの中の checkChild() の呼出しと戻り値の判定で，ここには進まない。
行番号 20（ア）や 34（エ）は，エラーコードを返すかどうかの判定である。例外の発生した行と，その後に進む行を分けて読むとよい。
採点講評（IPA）
設問3と設問5では，Javaを題材として，Webアプリケーションプログラムにおけるセキュアプログラミングについて出題した。いずれも正答率が高かった。情報処理安全確保支援士の重要な業務の一つに，セキュリティの観点でのソースコードレビューが挙げられる。ソースコードレビューは，開発チーム全体の技術レベルを向上させる効果的な方法なので，ぜひとも今後の業務に生かしてほしい。
本文中のiに入れる適切な処理内容を 50 字以内で具体的に述べよ。
〔i〕解答例
- NamingExceptionを投げる前に，childCheckedをfalseにする
解説
本文の根拠
図 3 行番号 31〜32
throw e;
図 4 行番号 113
if (!idPair.childChecked) {
図 3 行番号 45 の注釈
必要な通信ができないなど，認証そのものが実行
原因は，行番号 19 で childChecked が true になった後，行番号 26 の認証が例外で終わると，childChecked が true のまま例外が投げられることにある。図 4 は 3 回の再試行のあとで childChecked だけを見て紐付けに進むため，認証を一度も成功していないのに紐付けられる。
そこで，図 3 の 32 行目 throw e; の前後で，例外を投げる前に childChecked を false に戻す。これで，認証が実行できなかったときは childChecked が false になり，図 4 の行番号 113 の判定で ERROR_LINK_FAILED を返し，紐付けに進まない。
字数は 50 字以内で，解答例は 43 字である。“例外を投げる前に”という順序と，“childChecked を false にする”という処理の二つを残す。変数名は英字をそのまま書き，false も省略しない。
採点講評（IPA）
設問3と設問5では，Javaを題材として，Webアプリケーションプログラムにおけるセキュアプログラミングについて出題した。いずれも正答率が高かった。情報処理安全確保支援士の重要な業務の一つに，セキュリティの観点でのソースコードレビューが挙げられる。ソースコードレビューは，開発チーム全体の技術レベルを向上させる効果的な方法なので，ぜひとも今後の業務に生かしてほしい。
本文中のjに入れる適切な内容を 40 字以内で述べよ。
〔j〕解答例
- パスワードを，本人以外のメールアドレスに送ることができる
解説
本文の根拠
〔サイト R でのインシデント〕
パスワードを電子メール（以下，メールという）で未登録のメールアドレスに送信した記録がある。
図 5
［新たなメールアドレスに現在のパスワードをメールで送信］
L 課長が挙げた三つの問題のうち，一つ目は本人確認の情報（会員番号と誕生日）が少ないこと，二つ目はパスワードそのものをメールで送ることである。三つ目は，図 5 の右の画面にある。左の画面で“登録済みのメールアドレスでメールが受信できない場合”を選ぶと，右の画面で“新たなメールアドレス”を入力でき，そこへ現在のパスワードが送られる。
つまり，会員番号と誕生日さえ合えば，攻撃者は自分のメールアドレスを入力して，当該顧客のパスワードを受け取れる。アクセスログにも，パスワードを未登録のメールアドレスへ送信した記録があった。
字数は 40 字以内で，解答例は 28 字である。“パスワードを”“本人以外の（未登録の）メールアドレスに”“送ることができる”を残す。“登録済みでないメールアドレスに送れる”とだけ書いても意味は通るが，何が送られるのかを欠かさない。
採点講評（IPA）
設問2は正答率がやや低く，設問4は正答率が平均的であった。消費者向けのWebサイトでは，個人情報を取り扱うことが多いので，個人情報保護に関する法規制について，よく理解してほしい。
本文中のkに入れる適切な内容を 40 字以内で述べよ。
〔k〕解答例
- パスワードリセットのURLを，登録済みメールアドレスだけに送る
解説
本文の根拠
〔サイト R でのインシデント〕 L 課長
二つ目は，パスワードそのものをメールで送るという問題だ。
〔サイト R でのインシデント〕 L 課長
この方法では，一部の利用者はパスワード失念時にログインできなくなるが，その場合はコールセンタで対応することにしよう。
二つ目の問題（パスワードそのものをメールで送る）と三つ目の問題（本人以外のメールアドレスに送れる）を同時に解決する方法を考える。パスワードを送るのをやめ，パスワードをリセットするための URL を送る方式にすれば，パスワードそのものはメールに載らない。その URL の送り先を登録済みメールアドレスだけにすれば，本人以外のメールアドレスへは送れない。
登録済みのメールアドレスで受信できない利用者は，新たなメールアドレスへ送れなくなるので，パスワード失念時にログインできなくなる。L 課長の“一部の利用者はパスワード失念時にログインできなくなるが，その場合はコールセンタで対応する”という発言はこのことを指す。図 5 の右の画面（新たなメールアドレスの入力）を無くす改修になる。
字数は 40 字以内で，解答例は 31 字である。“パスワードリセットの URL を送る”と“登録済みメールアドレスだけ”の二つを残す。“パスワードを送らない”だけでは，三つ目の問題が解決しない。
採点講評（IPA）
設問2は正答率がやや低く，設問4は正答率が平均的であった。消費者向けのWebサイトでは，個人情報を取り扱うことが多いので，個人情報保護に関する法規制について，よく理解してほしい。
本文中の下線①について，更に大きな被害とは何か。具体的な被害を二つ挙げ，それぞれ 30 字以内で述べよ。
〔①〕解答例
- サイトPでポイントが不正に利用される。
〔②〕解答例
- サイトQでA百貨店の商品が不正に購入される。
〔備考〕①，②は順不同
解説
本文の根拠
〔サイト間でのアカウントの共通利用〕(2)
サイト R のアカウントを親アカウントとし，サイト P，Q のアカウントを子アカウントとして，子アカウントを親アカウントに紐付ける。
〔サイト間でのアカウントの共通利用〕
顧客がアカウントの紐付けを設定すれば，子アカウントの代わりに親アカウントを用いて各サイトにログインできる。
表 1 サイト P の機能
クレジットカード利用ポイントの残高確認，商品又は他社のポイントとの交換申請
表 1 サイト Q の機能
A 百貨店の商品の購入
アカウントの共通利用では，旧 B 社の顧客向けに，サイト R のアカウントを親アカウントとし，サイト P，Q のアカウントを子アカウントとして紐付ける使い方がある。このとき，親アカウントでサイト P，Q にもログインできる。サイト R のパスワード失念時の処理の問題で R のアカウントが乗っ取られると，攻撃者は紐付けられたサイト P，Q にもログインできてしまう。
表 1 のとおり，サイト P ではクレジットカード利用ポイントの商品又は他社ポイントとの交換申請ができ，サイト Q では A 百貨店の商品を購入できる。したがって，サイト P でポイントが不正に利用される，サイト Q で A 百貨店の商品が不正に購入される，の二つが“更に大きな被害”になる。L 課長が，サイト R は乗っ取られても経済的利益を得にくいと言っている点との対比である。
字数は 30 字以内で，解答例は 1 件目が 19 字，2 件目が 22 字である。“どのサイトで”“何が”“不正に（される）”を残す。①と②は順不同で，どちらにどの被害を書いてもよい。
採点講評（IPA）
設問2は正答率がやや低く，設問4は正答率が平均的であった。消費者向けのWebサイトでは，個人情報を取り扱うことが多いので，個人情報保護に関する法規制について，よく理解してほしい。
利用者の操作によって，図 7 のとおりに画面が遷移した場合，（い）（う）の画面は，図 6 の(1)〜(4)のどの時点で表示されるか。それぞれ，(1)〜(4)の記号で答えよ。
〔（い）〕解答例
- (2)
〔（う）〕解答例
- (4)
解説
本文の根拠
図 6
SP から IdP への認証要求
図 6
認証のための通信
図 6
認証応答に基づいた SP のリソース
図 7 の（あ）でリンク“サイト S の ID でのログインはこちら”をクリックすると，SP（サイト Q）から IdP（サイト S）への認証要求が Web ブラウザに返され，(1) の時点でブラウザが IdP へ転送する。その後，ブラウザと IdP が「認証のための通信」を行うのが (2) で，利用者が ID とパスワードを入力する画面（い）は IdP が返すもので，(2) の時点で表示される。
（い）で“ログイン”を押して認証が済むと，IdP から SP への認証応答が (3) でブラウザに転送され，(4) の時点で「認証応答に基づいた SP のリソース」，つまりサイト Q の画面（う）が表示される。したがって（い）は (2)，（う）は (4) である。
(1) と (3) はブラウザが転送を行う一瞬の時点で，利用者に見える画面は表示されない点が間違えやすい。
採点講評（IPA）
設問3と設問5では，Javaを題材として，Webアプリケーションプログラムにおけるセキュアプログラミングについて出題した。いずれも正答率が高かった。情報処理安全確保支援士の重要な業務の一つに，セキュリティの観点でのソースコードレビューが挙げられる。ソースコードレビューは，開発チーム全体の技術レベルを向上させる効果的な方法なので，ぜひとも今後の業務に生かしてほしい。
利用者の操作によって，図 7 のとおりに画面が遷移した場合，（あ）（い）（う）の各画面では，どのサーバから送られた HTML を表示するか。それぞれ，答案用紙の“SP”，“IdP”のいずれかを○印で囲んで示せ。
〔（あ）〕解答例
- SP
〔（い）〕解答例
- IdP
〔（う）〕解答例
- SP
解説
本文の根拠
〔アカウントの共通利用の設計の見直し〕
サイト S が，IdP（Identity Provider）となり，サイト P，Q，R は，SP（Service Provider）となる。
図 7 の（あ）
リンク「サイト S の ID でのログインはこちら」
本文のとおり，サイト S が IdP で，サイト P，Q，R が SP である。図 7 の（あ）は“サイト Q の ID でログイン”と，“サイト S の ID でのログインはこちら”のリンクがある画面で，サイト Q のログイン画面なので SP が送った HTML である。
（い）は，サイト S の ID を入力する画面で，図 6 の (2) の認証のための通信で IdP が提供するので IdP である。（う）は，認証後にサイト Q のトップメニューを含む画面で，SP のリソースなので SP である。
画面の見た目が似ていても，画面を提供するサーバが SP か IdP かは，どのサイトの ID を入力させる画面かで決まる。ID を確認する画面は IdP，サービスの画面は SP と整理する。
採点講評（IPA）
設問3と設問5では，Javaを題材として，Webアプリケーションプログラムにおけるセキュアプログラミングについて出題した。いずれも正答率が高かった。情報処理安全確保支援士の重要な業務の一つに，セキュリティの観点でのソースコードレビューが挙げられる。ソースコードレビューは，開発チーム全体の技術レベルを向上させる効果的な方法なので，ぜひとも今後の業務に生かしてほしい。
利用者の操作によって，図 8 の（え）（お）（か）（き）（く）（け）の順に画面が遷移した場合，（え）（か）（き）（く）の各画面では，どのサーバから送られた HTML を表示するか。それぞれ，答案用紙の“SP”，“IdP”のいずれかを○印で囲んで示せ。
〔（え）〕解答例
- SP
〔（か）〕解答例
- IdP
〔（き）〕解答例
- IdP
〔（く）〕解答例
- SP
解説
本文の根拠
図 8 の（お）
リンク「サイト S の ID と紐付け」
図 8 の（く）
「サイト Q のアカウント“○○○”と，サイト S のアカウント“△△△”を紐付けました。」
（え）は，サイト Q の ID でログインする画面なので SP である。サイト Q にログインした（お）の“サイト S の ID と紐付け”のリンクをクリックすると，（か）で ID とパスワードを入力する。これはサイト S のアカウントを確認する画面で，認証を行う IdP が提供する。
（か）の“アカウントを作成する”を選ぶと，サイト S のアカウントを新規に作る（き）が表示される。サイト S のアカウントを作成するのは IdP なので，（き）も IdP である。作成後に表示される（く）は，“サイト Q のアカウントとサイト S のアカウントを紐付けました”と告げる画面で，その後“サイト Q のトップメニューへ”戻るので，サイト Q（SP）の画面である。
解答例は，（え）SP，（か）IdP，（き）IdP，（く）SP である。図 8 の遷移のうち，サイト S のアカウントを確認・作成する部分が IdP，サイト Q に戻って結果を示す部分が SP という分け方を押さえる。
採点講評（IPA）
設問3と設問5では，Javaを題材として，Webアプリケーションプログラムにおけるセキュアプログラミングについて出題した。いずれも正答率が高かった。情報処理安全確保支援士の重要な業務の一つに，セキュリティの観点でのソースコードレビューが挙げられる。ソースコードレビューは，開発チーム全体の技術レベルを向上させる効果的な方法なので，ぜひとも今後の業務に生かしてほしい。
出典：令和2年度 10月 情報処理安全確保支援士試験 午後Ⅱ 問1（表記を一部改変）
