https://www.ipa.go.jp/shiken/mondai-kaiotu/gmcbt8000000d5ru-att/2021r03h_sc_pm1_qs.pdf
以下のおすすめ問題の解説となります。
良書。
問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社モジュールで行わなくてよい
S社の課題は、S社モジュールに対して多要素認証を追加する開発費がないということが読み取れる。F氏の提案は、その機能をもつ他社と連携しないか?という提案になるのである。
下線①について、可用性の観点での欠点を30字以内で述べよ。
T社またはS社のサーバが落ちたときにシステムが停止してしまう
これまでT社がいなかったので、S社のみの責任でサーバが運用で来ていたが、
今後はT社のサーバが落ちないように監視し続ける必要がある。可用性とはサービスを維持できるような指標なので、T社サービスが落ちたとき、S社のサービスが停止してしまうが欠点となる
aSサービス bTサービス c利用者
αえ
利用者が権限を確認するフェーズはえしかない