情報処理安全確保支援士試験 令和3年度 春期 午後1 問1
【出典：情報処理安全確保支援士試験 令和3年度 春期 午後1 問1（一部、加工あり）】
問1 認証システムの開発に関する次の記述を読んで、設問1〜4に答えよ。
S社は、従業員10名のベンチャー企業である。S社のファイル共有サービス（以下、Sサービスという）は機能が豊富であり、登録会員（以下、S会員という）の数を伸ばしている。
Sサービスでは、利用者認証されたS会員が写真などのファイルを自身に割り当てられたフォルダにアップロードできる。さらに、当該ファイルにアクセスするためのURLを電子メールなどで他者に示すことによって、当該ファイルを他者と共有できる。また、Sサービス内でメッセージや”いいね”を送信できる。
Sサービスの企画、開発及び運用は、CTOのF氏が取り仕切っており、そのうち、開発と運用は、F氏の指示の下、S社エンジニア2名が行っている。Sサービスは、外部セキュリティ企業による脆弱性診断を随時受けている。
[Sサービスの改修]
前回の脆弱性診断では、利用者IDとパスワードを用いて利用者認証するSサービスの認証モジュール（以下、S認証モジュールという）の認証方式を、多要素認証にする方がよいとのアドバイスを受けたが、その対処が課題であった。そこで、F氏は、認証及び許可を提供するSNS（以下、認証許可提供SNSという）のうち、多要素認証などの機能をもつT社のTサービスとSサービスとをID連携する改修をCEOのX氏に提案した。その改修によって、S認証モジュールを用いないS会員の登録と多要素認証の実現を目指す。ただし、今回の改修でのID連携では、既存のS会員は対象とせず、新規登録のS会員だけを対象とする。改修後も当面は既存のS会員の認証のために、S認証モジュールも継続して稼働させる。
F氏は、①S認証モジュールの代わりにTサービスとのID連携を利用することにはどのような利点と欠点があるかをX氏に説明した。X氏は、ID連携技術に詳しい情報処理安全確保支援氏（登録セキスペ）のY氏を外部から招聘して、実装の最終段階でのレビューを受けることを前提に、Sサービスの改修を承認した。
今回の改修では、OAuthのAuthorization Code Grantを採用する。OAuthは、認証許可提供SNSと認可情報を送受信するためのプロトコルの一つである。OAuthを用いた認可における三つの主体の説明を図1に、許可のシーケンスを図2に示す。
図2のシーケンスにおいて、（a）は（b）が提供するリソースにアクセスできる。それは（c）が、図3に示す権限を（a）に与えるからである。（c）は（a）に与える権限を図2中の（α）の通信の際に確認する。図3のうち、どの権限を要求するかは、（a）の実装者が決定する。S社では、要求した権限のいずれか一つでも、（c）が与えることを拒否する場合は、シーケンスを止めるように実装することにした。
なお、Sサービスでは、将来どの権限も利用すると考え、図3の全権限を要求することにした。
次に、TサービスとSサービスとのID連携について、実装の最終段階でY氏のレビューを受けた。Y氏はセキュリティ上の問題を三つ指摘した。
下線①について、S社の課題に即した利点を30字以内で具体的に述べよ。：多要素認証の実装をSサービス側に用意しなくてよい。
「F氏は、①S認証モジュールの代わりにTサービスとのID連携を利用することにはどのような利点と欠点があるかをX氏に説明した。」
「S社の課題に即した利点」とあるので、問題文から課題を確認すると、「前回の脆弱性診断では、利用者IDとパスワードを用いて利用者認証するSサービスの認証モジュール（以下、S認証モジュールという）の認証方式を、多要素認証にする方がよいとのアドバイスを受けたが、その対処が課題であった。」とあります。
課題への対処として、S認証モジュールの認証方式を多要素認証に改修する方法よりも、TサービスとのID連携を利用することの利点を考えます。
S認証モジュールの改修の場合、一般的には改修にはコストと時間がかかりますが、既にあるTサービスを利用すればS認証モジュールの改修は不要でその分のコストと時間はかかりません。
つまり、多要素認証の実装をSサービス側に用意しなくていいことが利点になります。
下線①について、可用性の観点での欠点を30字以内で述べよ。：Tサービスの障害時にSサービスを利用できない。
一方、欠点はどうでしょうか。
「可用性の観点」ですが、問題文にはSサービスについての可用性の説明はありませので、一般論で考えます。
利用者認証はSサービスの入口となる機能で、この機能が障害となるとSサービスが利用できなくなります。
TサービスとのID連携を利用すると、当然ですがTサービスの稼働状態がSサービスに影響してくることになり、Tサービスの障害時にSサービスを利用できないことになります。
a：Sサービス、b：Tサービス、c：利用者
OAuthについての記述「OAuthは、認証許可提供SNSと認可情報を送受信するためのプロトコルの一つである。」で、認可情報を送受信する主体を図1（OAuthを用いた認可における三つの主体の説明）から確認します。
すると、「Tサービス：認証認可提供SNSである。図3に示す権限を提供する。」とあることから、Tサービスが認可情報を送信する主体であることが分かります。
それを踏まえて、問題文を確認します。
「図2のシーケンスにおいて、（a）は（b）が提供するリソースにアクセスできる。それは（c）が、図3に示す権限を（a）に与えるからである。」
リソースを提供する（b）がTサービスであること、提供される（a）がSサービスであることはすぐに分かります。
そしてリソースへのアクセスを許可する権限をSサービスに与える（c）に該当するのは利用者となります。
以下の記述でも確認しておきます。
「（c：利用者）は（a：Sサービス）に与える権限を図2中の（α）の通信の際に確認する。図3のうち、どの権限を要求するかは、（a：Sサービス）の実装者が決定する。S社では、要求した権限のいずれか一つでも、（c：利用者）が与えることを拒否する場合は、シーケンスを止めるように実装することにした。」
OAuthでは、あらかじめ認可情報を要求する側がどの権限を利用するかを決めておき、そのうち最終的にどの権限を与えるかは利用者が判断します。
α：（え）
「利用者はSサービスに与える権限を図2中の（α）の通信の際に確認する。」
利用者がSサービス与える権限を確認するのは、Tサービスとの通信中です。
該当するのは「（う）認可の要求」「（え）認証、権限付与の確認」「（お）認可コード」の通信ですが、「（え）認証、権限付与の確認」であることは明らかでしょう。