情報処理安全確保支援士 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. 図4の生成部分
   【問題文】「図4の行番号101のsiteIDにサイトの識別文字列として“siteQ”が代入された状態で図4のコードの実行が開始される。」
   行番号101のコンストラクタ呼出し
   AccountLink idPair = new AccountLink(siteID, userID, userPassword, loginId);
   ここで userID が childID に格納されるため、誤った利用者IDは idPair.childID に残ります。
   ⇒ c＝「idPair.childID」（ウ）
2. 認証チェック呼出し
   【問題文】「図4のコードが呼び出され、cに誤った利用者IDが代入されたまま、dが呼び出される。」
   図4 行番号106
   java result = idPair.checkChild();
   認証チェックを行うメソッド呼出しそのものが d です。
   ⇒ d＝「idPair.checkChild()」（ア）
3. 例外発生箇所
   【問題文】「何らかの理由で、d中の図3中の行番号eでfが発生し…」
   図3 行番号32
   java throw e;
   行番号26〜32ではLDAP認証に失敗した際 NamingException を送出します。
   ⇒ f＝「NamingException」（ケ）
4. フラグの状態
   【問題文】「dが3回試行され、全て同じくfが発生すると、gの値はtrueなので、図4中の行番号hに進み、紐付けが行われる。」
   checkChild() 内で認証に成功した場合のみ childChecked = true; に設定されるはずですが、例外時は書き換わらず前回値が残存します。フラグ名は図3 行番号2「boolean childChecked」。
   ⇒ g＝「idPair.childChecked」（イ）

誤りやすいポイント

• コンストラクタのパラメータとクラス内フィールドの対応を取り違え、idPair.childSite などを選んでしまう。
• 図4のループ内で例外処理後にフラグがリセットされない点に気付かず、idPair.checkChild() が再実行されるたびに毎回 false になると誤解する。
• 例外型を Exception と広く捉え、特定の NamingException に絞れない。
• フラグ変数 childChecked の初期化位置（コンストラクタで false）と更新箇所（認証成功時のみ true）を見落とし、値が保持される危険性を想像できない。

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