情報処理安全確保支援士 2020年 秋期 午後2 問01

解答の論理構成

1. 【問題文】には、“変更後のFW-Pのルールは、表2のようにする。”とあり、表2のabは“Web-P ➜ 他サイトのLDAPサーバへ認証問い合わせ”を許可する新設ルールである。
2. 図2の処理説明では
   　“(i) Web-PのWebアプリが、LDAP-Qに問合せて…認証を行う。”
   　と明記され、図3のsiteQAuthメソッドもLDAP-Q／LDAP-Rへの通信を想定している。
3. さらに、Web-Pは従来から自サイトの認証にもLDAP-Pを使用している（ログイン時の認証は“各LDAPサーバのユーザエントリ内の利用者IDとパスワードを利用している。”）。
4. よって、Web-Pから到達すべき宛先は “LDAP-P、LDAP-Q、LDAP-R” の三つ、通信プロトコルはLDAPで統一される。
5. 以上より
   　a “LDAP-P、LDAP-Q、LDAP-R”
   　b “LDAP”
   　が妥当となる。

誤りやすいポイント

• 「自サイトなのでFW-Pを通らない」と誤解し、“LDAP-P” を除外してしまう。実際には“LDAP-P、FW-P、Web-P”が一列配置されており、横並びでもファイアウォールを経由する構成である。
• “プロトコル: TCP” と答えてしまうケース。表2の他項目で“LDAP”と明示的に書かれているため、同じ粒度で“LDAP”と記載するのが適切である。
• “宛先”欄をIPアドレスレンジで答えようとするミス。設問は字句（機器名）を問うており、機器名で記載する必要がある。

FAQ

解答の論理構成

• 【問題文】では、合併後に「サイトP、Q、Rでクロス分析などの手法を用いて購買傾向を分析」するために、三サイト間でアカウントを共通利用すると説明しています。
• しかし法務担当のMさんは「アカウントの共通利用には、顧客に対して利用目的の変更を通知して、同意を得る必要がある」と指摘しました。
• これは、旧A社・旧B社が取得していた個人情報をC社が新たな分析目的で利用する行為が、承継前の「利用目的の達成に必要な範囲」を超える恐れがあるためです。
• 個人情報保護法は、本人の同意を得ないまま「利用目的の達成に必要な範囲を超えて」個人情報を取り扱うことを禁止しています。
• よって、禁止事項は「本人の同意を得ないで、承継前における当該個人情報の利用目的の達成に必要な範囲を超えて、当該個人情報を取り扱うこと」と導けます。

誤りやすいポイント

• 「第三者提供の禁止」と混同し、利用目的の範囲を超えた内部利用も同意が必要である点を見落とす。
• 事業承継＝同一事業体と解釈し、利用目的の再確認や同意取得を不要と考えてしまう。
• 「利用目的の変更を通知」だけで足りると誤解し、本人同意（オプトイン）まで求められることを忘れる。

FAQ

解答の導き方

1. [c] が何かを特定する

• 図4の101行には「AccountLink idPair ＝ new AccountLink(siteID, userID, userPassword, loginId);」とあります。ここでコメントに「userIDには、紐付けるアカウントの利用者ID」と明記されています。
• 図3のコンストラクタ（11〜16行）を見ると「childID = id;」と代入しています。つまり呼び出し元のuserIDはコンストラクタでchildIDに格納されます。
• 以上より [c] にはidPair.childIDが入るため、選択肢は ウ です。

1. [d] が何を指すかを特定する

• 図4の106行には「result = idPair.checkChild();」と明示されています。したがって呼ばれる処理はidPair.checkChild() であり、選択肢は ア です。

1. [f] と [g] の因果関係を読み取る

• 図3のcheckChild()の冒頭（19行）に「childChecked = childSite.equals("siteQ") || childSite.equals("siteR");」とあり、サイト識別が正当ならchildCheckedを先にtrueに設定しています。
• siteQの分岐を見ると、26行で「if (siteQAuth(childID, childPW) == NO_ERROR) { childChecked = true; } else { childChecked = false; }」と認証結果に応じてchildCheckedを上書きする処理がありますが、31行の「catch (NamingException e) { throw e; }」では例外をそのまま再スローしています。さらに図3のsiteQAuthの説明に「必要な通信ができないなど、認証そのものが実行できない場合、例外NamingExceptionを投げる。」とあります。
• よってsiteQAuthの実行中に通信障害等で例外が発生すると（この例外はNamingException）、catchで再スローされtryブロック内のchildCheckedの上書き処理が実行されず、先に設定されたtrueの値が残ります。
• 図4の再試行ループ（103〜115行）で3回とも同じNamingExceptionが発生すると、ループを抜けた後の113行の「if (!idPair.childChecked) { return AccountLink.ERROR_LINK_FAILED; }」の判定はchildCheckedがtrueのためスキップされ、116〜117行でidPair.makeLink() が呼ばれて紐付けが実行されてしまいます。
• したがって例外の型はNamingException（ケ）、ループ後に評価される変数はidPair.childChecked（イ）です。

誤りやすいポイント

• childCheckedは「認証成功時のみtrueになる」と早合点すること。実際は図3行19で先にchildCheckedをtrueに設定しており、例外で上書きされなければtrueのまま残ります。
• ループ内の戻り値resultとオブジェクトの状態childCheckedを混同すると誤読します。図4ではループ中にresultを見ている一方、ループ後の判定はidPair.childCheckedを参照しています。
• 例外発生時の制御フローを見落とすと誤答します。catchが再スローしている箇所では、以降の上書き処理が実行されない点に注意してください。

FAQ

解答の論理構成

1. “何らかの理由で、d中の図3中の行番号eでfが発生”
   – 図3を見るとcatch (NamingException e) { の直後、行番号32でthrow e; が実行されます。ここが NamingException を発生（再スロー）させる箇所であり、外側の再試行ロジックに制御が戻るポイントです。したがって
   – e ＝ 図3行番号32 → 解答群で該当する記号は “ウ”。
2. “図4中の行番号hに進み、紐付けが行われる。”
   – 図4ではidPair.makeLink(); が実際にLDAPへ紐付けを書き込む処理です。これは行番号117に位置しています。
   – よってh ＝ 図4行番号117 → 解答群で該当する記号は “キ”。
3. なぜ誤った利用者IDでも紐付くのか
   – 行番号19でchildChecked = childSite.equals("siteQ") … により サイト識別文字列だけでchildCheckedがtrue になる。
   – 行番号32でNamingExceptionが発生し再試行しても、childCheckedはtrueのまま維持。
   – 3回の再試行後、図4行番号113のif (!idPair.childChecked) がfalseとなり、行番号117 idPair.makeLink() に到達してしまう。
   – この一連の流れが設問本文の説明と一致するため、上記行番号の選択が妥当と結論付けられます。

誤りやすいポイント

• 例外が投げられる“場所”と“原因”の混同
  NamingExceptionは行番号26のsiteQAuth呼び出し内部で起きるものと思い込みやすいが、再スローされる行番号32が指定箇所。
• childCheckedの更新タイミング
  認証未完了でも行番号19でtrueになるため、ループ後の判定条件を見落とすと誤答に結び付く。
• 行番号117と116の取り違え
  紐付けそのものは117行目、116行目はtryブロック開始。処理主体の行を正確に把握する必要がある。

FAQ

解答の論理構成

• 【問題文】には、誤った利用者IDを入力し、d＝checkChild() が3回再試行されても、 “gの値はtrueなので、図4中の行番号hに進み、紐付けが行われる。” とあります。
  ここで g はchildChecked、h はidPair.makeLink() 直前の判定です。
• childCheckedが誤って true のままになる原因は、図3の26〜32行にあるtry‐catchブロックです。
  32行でNamingExceptionを発生させてcatchへ伝搬する際、childCheckedをfalseに戻す処理が存在しません。

• そのため、最初の認証でchildChecked = trueになった直後にNamingExceptionが投げられると、 ループを抜けてもchildCheckedは true のまま保持され、誤ったIDでも紐付けが成立します。
• よって、32行目前後で “i” として求められる修正は
  “NamingExceptionを投げる前にchildChecked = falseを設定する” ことになります。
  これにより、例外発生時は必ずchildChecked == falseとなり、図4の
  if (!idPair.childChecked) { return AccountLink.ERROR_LINK_FAILED; } が働いて紐付け処理を中断できます。

誤りやすいポイント

• 例外処理＝エラー終了と短絡し、フラグ変数の状態遷移を見落とす。
• checkChild() から返される戻り値だけを注視し、メンバ変数childCheckedの副作用を確認しない。
• 32行目のthrow e; を「再スローだから問題ない」と考え、例外発生時にフラグをリセットする必要性に気付かない。

FAQ

解答の論理構成

• 問題文には、インシデント調査の結果として
  “パスワードを電子メール…で未登録のメールアドレスに送信した記録がある。”
  と明記されています。この時点で“登録済み以外のアドレスへ送信できる”仕様が判明します。
• 会話シーンでL課長は
  “二つ目は、パスワードそのものをメールで送るという問題だ。三つ目は、jという問題だ。”
  と述べています。二つ目が「平文パスワードを送信」であるため、三つ目は“送信先メールアドレスの適切な制限がない”ことだと導けます。
• 図5の画面には“新たなメールアドレスに現在のパスワードをメールで送信”ボタンが存在し、本人確認を経ずに第三者が自由なアドレスを指定できる設計になっています。
• 以上から j に入る内容は
  “パスワードを、本人以外のメールアドレスに送ることができる”
  が適切となります。

誤りやすいポイント

• 「本人確認情報が少なすぎる」をそのまま入れてしまう
  → それは会話中で“一つ目”と明示されており、j ではありません。
• 「メールを暗号化していない」を挙げてしまう
  → 二つ目の“パスワードそのものをメールで送る”に内包される別論点であり、三つ目とは異なります。
• 画面仕様から“新規メールアドレス入力”の危険性を見落とす
  → 未登録アドレス可という仕様に気付けないと誤答になりがちです。

FAQ

解答の論理構成

1. 【問題文】には、“二つ目は、パスワードそのものをメールで送るという問題だ。三つ目は、jという問題だ。二つ目と三つ目の問題の解決には、kように改修すべきだ。”とあります。
2. 二つ目の問題「パスワードそのものをメールで送る」は、漏えいリスクが高く、現行の安全指針では推奨されません。
3. 三つ目の問題（j）は、図5の“新たなメールアドレスに現在のパスワードをメールで送信”機能から読み取れる“登録済み以外のメールアドレスへも送信できてしまう”点です。
4. これら二つの問題を同時に解決する改修方法としては、 ・パスワード自体を送らない（リセットURL方式）
   ・送信先を「登録済みメールアドレスのみに限定」
   が不可欠です。
5. したがって k には「パスワードリセットのURLを、登録済みメールアドレスだけに送る」が入ります。

誤りやすいポイント

• 「パスワード再発行メールを送る」とだけ書くと、“送信先制限”が抜け落ち減点対象になります。
• 「ワンタイムパスワードを送る」とすると、結局“未登録メールアドレスにも送れる”問題を解決していません。
• リセットURL方式の主眼は“パスワードを平文で送らない”ことであり、単に暗号化通信を挙げると論点がずれます。

FAQ

解答の論理構成

1. インシデントで明らかになった事実
   • 攻撃者はサイトRのパスワード失念機能を悪用し、ある顧客のアカウントを乗っ取った（本文「攻撃者がパスワード失念時の処理を悪用して…当該顧客のアカウントを乗っ取った」）。
2. 予定していたアカウント共通利用の仕様
   • 「顧客がアカウントの紐付けを設定すれば、子アカウントの代わりに親アカウントを用いて各サイトにログインできる。」
3. 設問の下線①の文脈
   • L課長は「もしもこれらの問題に気付かずにアカウントの共通利用を提供していたら、①利用者に更に大きな被害が発生するところだった」と発言。
   • つまり、乗っ取られたサイトRアカウントが親または子として紐付けられると、攻撃者はサイトP・Qにもログインできる。
4. 各サイトで想定される被害
   • サイトPの機能には「クレジットカード利用ポイントの残高確認、商品又は他社のポイントとの交換申請」がある。
     → 攻撃者がポイントを不正交換・利用できる。
   • サイトQの機能には「A百貨店の商品購入」がある。
     → 攻撃者が商品の不正購入を行える。
5. 以上から、下線①で指す「更に大きな被害」は
   ① サイトPでポイントを不正に利用される被害
   ② サイトQで商品を不正に購入される被害
   となる。

誤りやすいポイント

• サイトPを「クレジットカード明細閲覧サイト」とだけ捉え、ポイント交換機能の存在を見落とす。
• 「更に大きな被害」を抽象的に答え、具体的なサイト名・被害内容を示さない。
• サイトR自体の被害（キャンペーン応募）を再度挙げてしまい、設問の趣旨とずれる。

FAQ

解答の論理構成

1. 画面(い)の位置付け
   • 図7の(い)は、利用者が「サイトSのIDでログインはこちら」を選択した結果表示されるIdP（サイトS）のログインフォームです。
   • 図6では、IdPとの「認証のための通信」を示す部分に“(2)→─── 双方向矢印：「認証のための通信」”と記載されています。
   • よって、IdPで資格情報を入力する(い)の画面は、図6の「(2)」のタイミングに該当します。
2. 画面(う)の位置付け
   • 図7の(う)には“ログインしました。ようこそ、サイトQへ”とあり、認証完了後にSP（サイトQ）が保護リソースを返す場面で表示されます。
   • 図6では、IdPからの認証応答を受け取った後にSPがリソースを返却する段階を“(4)→───◀ 「認証応答に基づいたSPのリソース」”と示しています。
   • したがって、SPがトップメニューを表示する(う)の画面は、図6の「(4)」に相当します。
3. 以上より
   • (い)：図6の(2)
   • (う)：図6の(4)

誤りやすいポイント

• IdPとSPを混同し、図6の「(3) IdPからSPへの認証応答転送」をログイン完了画面と誤解する。実際の画面表示は(4)のリソース返却時です。
• 図7(い)を「ユーザが認証要求をSPから転送された直後の画面」と考え、(1)と回答するミス。フォーム表示は既にIdP上なので(2)です。
• SAMLの一連の流れを「リダイレクト＝(3)」のように単純化し、画面表示のタイミングを見落とす。

FAQ

解答の論理構成

1. 【問題文】で、アカウント共通利用は“「SAMLプロトコルのWeb Browser SSO Profile」を用いる。サイトSが、IdP（Identity Provider）となり、サイトP、Q、Rは、SP（Service Provider）となる。”と明示されています。
2. 同じく【問題文】には“図6は、Web Browser SSO Profileの基本的な通信の流れである。”とあります。図6の流れを要約すると
   (1) 利用者が“SPのリソースへのアクセス要求”→SPは“IdPへの認証要求”をブラウザに転送
   (2) ブラウザはIdPへ遷移し認証
   (3) IdPは“認証応答”をブラウザ経由でSPへ返却
   (4) SPは認証後のリソースを返却
   というステップになります。
3. 図7の画面と図6のステップを対応づけます。
   ・(あ) 画面は“サイトQのIDでログイン”というSP独自のログイン画面で、ここで“サイトSのIDでのログインはこちら”リンクを押すとIdP連携に進みます。これは“(1) SPのリソースへのアクセス要求”で返されるHTMLなので送信元はSP。
   ・(い) 画面はIdP（サイトS）のログイン画面です。図6の“(2) IdPでの認証のための通信”に相当し、送信元はIdP。
   ・(う) 画面は“ログインしました。ようこそ、サイトQへ”とSPであるサイトQのトップメニューを表示しています。これは図6の“(4) 認証応答に基づいたSPのリソース”に該当するため送信元はSP。
4. 従って解答は
   (あ)：SP
   (い)：IdP
   (う)：SP

誤りやすいポイント

• 「リンクをクリックした直後もまだSPの画面」と勘違いし、(い)をSPと答えてしまう。実際にはリンク遷移でIdPにリダイレクトされている。
• 認証成功後の“ようこそ、サイトQへ”を「IdPからのメッセージ」と誤認する。SAMLでは最終的なHTMLはSPが生成する点に注意。
• 図7だけを見て判断し、図6のSAMLフローと結び付けないため送信元を取り違える。

FAQ

解答の論理構成

1. 役割の前提を確認
   • 【問題文】には
     “サイトSが、IdP（Identity Provider）となり、サイトP、Q、Rは、SP（Service Provider）となる。”
     とあり、画面を出す主体はIdPかSPのいずれかだけです。
2. (え) の画面
   • 【図8】(え) には
     “楕円形ボタン『サイトQのIDでログイン』”
     と明示されています。ログイン対象が “サイトQ” であるため、HTMLを返すのは “サイトQ ＝ SP” です。
3. (か) の画面
   • (え) から “サイトSのIDでのログインはこちら” のリンクをたどると (か) が表示されます。
   • (か) にはサイト名の記載がなく、ボタンも単に “ログイン”。これは共通認証基盤であるIdPのログイン画面と読み取れます。したがって送り手は “IdP” です。
4. (き) の画面
   • (か) から “アカウントを作成する” をたどると (き) に遷移します。
   • (き) は
     “『ID』、『パスワード』…『アカウントを作成』”
     と、IdP側で新規アカウントを発行する機能そのものです。よって “IdP” がHTMLを返します。
5. (く) の画面
   • (き) でIdPに新規アカウントを作成後、SP側に戻り
     “『サイトQのアカウント “[　]” と、サイトSのアカウント “[　]” を紐付けました。』”
     という完了メッセージを表示します。ここで主語になっているのは “サイトQ”、すなわちSPです。
6. 以上より
   (え)：SP
   (か)：IdP
   (き)：IdP
   (く)：SP

誤りやすいポイント

• 画面デザインが似ているため、(か) をSPと誤認しやすい。リンク遷移先の文言を手掛かりにIdPへのリダイレクトであることを見抜く必要があります。
• “アカウント作成”＝IdP機能という鉄則を忘れて (き) をSPと答えてしまう。
• “紐付け完了”メッセージに両方のサイト名が出てくるので混乱し、(く) をIdPとしてしまう。メッセージ作成主体がどちらかを冷静に判断することが大切です。

FAQ