情報処理安全確保支援士 2021年 春期 午後1 問01

解答の論理構成

1. 問題文は、外部セキュリティ企業からの指摘として「多要素認証にする方がよい」と述べています。
   引用：「前回の脆弱性診断では、…認証方式を、多要素認証にする方がよいとのアドバイスを受けた」。
2. しかし S社は従業員が「10名」でエンジニアも「2名」しかおらず、自前で多要素認証を開発・運用する負荷は大きいことが読み取れます。
3. そこで F氏は「T社のTサービスとSサービスとをID連携する改修」を提案し、「その改修によって、S認証モジュールを用いないS会員の登録と多要素認証の実現を目指す」と記載されています。
4. 以上より、ID連携を採用する利点は「多要素認証の機能を外部サービスに任せられ、Sサービス側で開発・維持しなくて済む」点であると導けます。
5. したがって模範解答「多要素認証の実装をSサービス側に用意しなくてよい。」が妥当になります。

誤りやすいポイント

• 利点を「セキュリティが高まる」とだけ書くと具体性不足で減点されやすい。
• 「Tサービスのユーザが増える」など、S社の課題と直接関係しない利点を書くと的外れになる。
• 欠点と混同し、「外部サービス依存が増す」などネガティブ要素を書いてしまうミス。

FAQ

解答の論理構成

• 【問題文】では、F氏が実施する改修について「①S認証モジュールの代わりにTサービスとのID連携を利用することにはどのような利点と欠点があるか」を説明したと記載されています。
• 可用性とはサービスが“使いたいときに使える”状態を指します。
• S認証モジュールを停止し、新規 S会員 は「Tサービス」との ID 連携でしか認証できなくなるため、利用可否が Tサービス の稼働状況に依存します。
• もし「Tサービス」に障害が発生すれば、Sサービス側で認証処理を完了できず、利用者はログインできません。
• 以上より、可用性の観点からの欠点は「Tサービスの障害時にSサービスを利用できない」となります。

誤りやすいポイント

• 「可用性」を問われているのに、セキュリティ（機密性・完全性）面の欠点を書いてしまう。
• 「障害時にID連携ができない」とだけ書き、Sサービスを利用できない点まで踏み込まない。
• 連携停止＝S認証モジュールへ自動フォールバックと誤解し、欠点がないと判断する。

FAQ

解答の論理構成

1. 問題文では「図2のシーケンスにおいて、a は、b が提供するリソースにアクセスできる。」とある。OAuth の文脈で“リソースを提供する”主体はリソースサーバであり、本設問では「Tサービス」がその役割を担うため、b ＝「Tサービス」。
2. 「それは c が、図3に示す権限を a に与えるからである。」とある。リソースオーナ（権限を与える主体）は利用者自身であるため、c ＝「利用者」。
3. 「図3のうち、どの権限を要求するかは、a の実装者が決定する。」とある。a は権限を要求し、アクセストークンを取得する“クライアント”であり、本設問では「Sサービス」が該当する。
4. 以上より
   　a：Sサービス（ア）
   　b：Tサービス（イ）
   　c：利用者（ウ）

誤りやすいポイント

• リソースを“保有”する主体と“提供”する主体を混同し、b に「利用者」を入れてしまう。
• OAuth の三者関係（クライアント／リソースサーバ／リソースオーナ）を覚えていても、具体的なサービス名に置き換える際に逆転させてしまう。
• a の実装者が権限を決定するという記述から a を「利用者」と誤解するケース。実際に実装（プログラム）を行うのはサービス側である点を見落としやすい。

FAQ

解答の論理構成

1. 問題文には「“Tサービス は a に与える権限を図2中のαの通信の際に確認する。”」と記されています。
2. 権限（scope）の確認は、OAuth 2.0 Authorization Code Grant における“利用者が認可サーバ（ここではTサービス）に対してログインし、同意画面で権限付与を選択する”タイミングで行われます。
3. 図2の各通信（あ）〜（こ）のうち、Tサービスと利用者が直接やり取りし、利用者が認証と同意を行うフェーズは「（え）」だけです。
4. よって、αに入るのは「（え）」であり、模範解答「α：（え）」が導かれます。

誤りやすいポイント

• 「（う）」の“利用者→Tサービス”を同意画面と勘違いする
  (う) はブラウザ経由でリクエストが飛ぶだけで、まだ同意確認は始まっていません。
• 「（か）」の“認可コード受領”を権限確認と誤解する
  認可コードが発行された後では同意はすでに完了しており、確認フェーズは終了しています。
• “Sサービスが確認する”と読んでしまう
  問題文は「Tサービス は … 確認する」と明示しており、主体を取り違えると選択を誤ります。

FAQ

解答の論理構成

1. 図4のステップ6で「Tサービス」から「攻撃者」へ送られるメッセージのラベルは【問題文】に「認可コード」と明示されています。攻撃者はこれを自サイト内の2か所の枠（d）に保持し、リダイレクトで利用者に送り返します。
   ── よって d には「ウ：認可コード」が入ります。
2. 図4のステップ9で「利用者」から「Sサービス」へ渡る内容も同じ d であるため、ここも「認可コード」です。
3. 認可コードを受け取った「Sサービス」は、図2の（き）に相当する処理として「アクセストークンの要求」を「Tサービス」に送ります。図4ステップ10の e がこれに対応します。
4. 解答群を照合すると、アクセストークンを要求するメッセージは「ア：アクセストークンの要求」に一致します。

誤りやすいポイント

• 認可コードとアクセストークンを混同し、d に「イ：アクセストークン」を入れてしまう。アクセストークンは図2の（く）で Tサービス→Sサービス に返る応答であり、利用者経由ではない点に注意です。
• 図4と図2を対応付ける際、攻撃者が介在しているため手順番号がずれて見え、メッセージの向きや送信者を取り違える。
• 「認証、権限付与の確認」（オ）は Tサービス→利用者 に出る対話画面を指し、コードやトークンを運ぶメッセージではない点を見落としやすい。

FAQ

解答の論理構成

1. 攻撃シナリオの概要
   • 本文では、罠サイト経由で「図4　攻撃のシーケンス」が実行されると、「利用者が攻撃を受けているとは知らずにSサービスにファイルをアップロードすると、そのファイルを攻撃者にダウンロードされてしまうおそれがある」と述べています。
   • ここで問題となるのは、Sサービスが 誰の Tサービスアカウント（T-ID） を利用して操作を行っているかです。
2. T-ID が攻撃者にすり替わる仕組み
   • 図2の注記には、初回利用時に「Tサービスから取得したアカウント名（以下、T-IDという）をSサービス内に登録する」とあります。
   • 図4では、攻撃者が「認可の要求」〜「認可コード」を自分のブラウザで完結させた後、d（認可コード）を利用者のブラウザへリダイレクトさせています。
   • Sサービスは state パラメタ未検証 のまま d を受信するため、攻撃者の認可コードを正規の利用者セッションに紐付けてしまい、結果として「攻撃者の T-ID」を登録します。
3. アップロード時に使われるアカウント
   • 利用者は自分のつもりでファイルをアップロードしますが、Sサービス側が保持する T-ID は「攻撃者の T-ID」です。
   • よって、Tサービス上は “攻撃者” アカウントの権限 でアップロードが行われることになります。
4. ダウンロード時に使われるアカウント
   • ファイルが攻撃者の領域に置かれているため、攻撃者は自分の T-ID でログインしたまま正規機能を使い、容易にダウンロードできます。
   • したがって、ダウンロードも “攻撃者” アカウント によって実施されます。
5. 以上より
   • ファイルのアップロード：攻撃者
   • ファイルのダウンロード：攻撃者

誤りやすいポイント

• 「アップロードは利用者が操作しているから利用者のアカウント」と勘違いする。実際には登録済み T-ID が攻撃者に置き換わっている。
• 「ダウンロードは攻撃者だからアップロードは利用者」と対称関係で覚えてしまう。
• state パラメタ検証の有無がアカウントすり替えの核心であることを見落とす。

FAQ

解答の論理構成

1. 【問題文】には
   “Sサービスはstateパラメタをβを送信する際に付与する”
   とあり、state 付きの“認可リクエスト”をどのタイミングで送るかを示しています。
2. 図2では、Sサービスから利用者へ“認可の要求”を出す工程が(い)です。ここが“認可リクエスト”に相当するため、[ β ]＝(い) と判断できます。
3. 次に
   “Sサービスはγを受信する際に、そのセッションが…同一であるか否かを確認する”
   とあります。state を検証するのは、“認可コード”が返ってくるタイミングです。
4. 図2で“認可コード”がSサービスに戻る工程は(か)であり、ここで state 値を照合して CSRF を防御します。したがって [ γ ]＝(か) となります。

誤りやすいポイント

• “state を付与する”場面を(う)と誤認する例が多いですが、(う)は利用者がTサービスへ転送する部分であり、Sサービスが直接パラメータを付けられません。
• “state を検証する”場面を(き)と誤答しやすいですが、(き)はアクセストークン要求であり、state の照合は既に完了しているべき段階です。
• “利用者→Sサービス”の戻り工程を見落とし、Tサービス→Sサービスのライン(お)を選んでしまう混同も頻発します。

FAQ

解答の論理構成

1. 要求する権限は、Sサービスが Tサービスから何を取得したいかで決まります。図1には
   「Sサービス：Tサービスでのアカウント名を要求する．」
   と明記されています。
2. 図2のシーケンスでも、(け)「アカウント名の要求」→(こ)「アカウント名」という通信しか行っていません。
3. したがって、必要最小限の権限は「利用者のアカウント名、電子メールアドレスなど登録情報を取得する権限」です。これは図3の
   「(エ) 利用者のアカウント名、電子メールアドレスなど登録情報を取得する権限」
   に該当します。
4. (ア)〜(ウ)は“いいね”送信や投稿代行など、Sサービスの機能要件に含まれていない行為を許可してしまうため過剰権限になります。
5. 以上より、下線③の解答は （エ） であると導かれます。

誤りやすいポイント

• 「今後使うかもしれないので全権限を要求する」という本文前半の方針に引きずられ、最小限という条件を読み落とす。
• “ファイル共有サービス＝投稿権限が必要”と早合点し、(ウ) を選んでしまう。
• “メッセージ機能があるから (イ) が要る”と考えるが、Tサービス経由でメッセージを送る仕様ではない。
• 図4の攻撃シナリオを気にするあまり、権限とは無関係の state パラメタ対策と混同する。

FAQ

解答の論理構成

1. 問題文の前提
   • 改修前は「利用者IDとパスワードを用いて利用者認証する」S認証モジュールだけで全 S 会員を認証していました。
   • 改修後は「既存のS会員は対象とせず、新規登録のS会員だけを対象」として T サービスとの ID 連携を導入し、「S認証モジュールを用いないS会員の登録」を実現します。
2. 三つ目の問題への対応方針
   • 「TサービスとのID連携を一時的に停止し、S認証モジュールだけで認証することにした」と記載されています。
3. 停止時に利用できなくなる利用者
   • 停止後は S 認証モジュールでしか認証を行わないため、S 認証モジュールに情報をもたない利用者はログインできません。
   • その利用者とは、改修後に「S認証モジュールを用いない」方式で新規登録された S 会員です。
4. したがって下線④が示すのは「S認証モジュールに利用者IDとパスワードを登録していないS会員」となります。

誤りやすいポイント

• 既存会員と新規会員を取り違える
  既存会員は従来どおり S 認証モジュールに情報が残っているため影響を受けません。
• 「Tサービスを利用しているすべてのS会員」と答えてしまう
  既存会員が後から T サービスを併用し始めても、パスワードが残っていればログイン可能です。
• 「多要素認証を設定していないS会員」と誤読する
  問題の論点は多要素認証の有無ではなく、S 認証モジュールへの登録有無です。

FAQ

解答の論理構成

1. 改修方針
   問題文は「今回の改修では、OAuthのAuthorization Code Grantを採用する。」と述べています。OAuthでは、連携先（ここではSサービス）がアクセストークンを取得し、APIを呼び出して利用者の識別子を得るのが一般的です。
2. 直接認証しないという前提
   さらに本文には「Sサービスは利用者を直接認証していない」と明記されており、Sサービス側にパスワード等は存在しません。したがって、Tサービスが発行する利用者識別情報だけが頼りになります。
3. 利用者識別子としての「T-ID」
   模範解答が示すとおり、Tサービスのアカウント名は「T-ID」と呼ばれています。Sサービスは初回登録時にこの「T-ID」を自システムに保存しておきます。
4. 認証の成立条件
   利用者が再度アクセスすると、OAuthフローで得たアクセストークンを用いてSサービスがTサービスへ照会し、同一の「T-ID」を取得します。保存済みの「T-ID」と一致すれば、その利用者は「Tサービスで認証されたS会員」であると判断できます。
5. 結論
   以上より、Sサービスは「Tサービスで認証されたS会員のT-IDが、Sサービス内に登録されていることを確認する」ことで利用者認証を実現しています。

誤りやすいポイント

• アクセストークンを得ただけで認証が終わると誤解し、T-IDとの突き合わせを実装し忘れる。
• Tサービスのメールアドレスや他属性で確認しても同一性は保証されると考えてしまう（アカウント名は変更不能という条件を見落とす）。
• OAuthとOpenID Connectを混同し、「IDトークン」がないのに同一人物保証が得られると思い込む。

FAQ