【情報処理安全確保支援士】令和4年度春季試験午後Ⅱ 問2【YouTube解説動画あり】

情報処理安全確保支援士　令和4年度　春季試験　午後Ⅱ　問2を解説していきます。

出題テーマ：

出題テーマは『クラウドサービスへの移行』でした。

CDNやKerberos認証、SAML認証、OAuth2.0/OIDCなどの認証の仕組みや攻撃に対する対策が出題されていました。

知識が必要な問題と文章中のヒントから回答することができる問題が半々程度出題されていたと思います。

設問1 (1)

【a】の部分として、『CDNでは、インターネット上に【a】サーバというサーバを分散配置して、動画配信を要求した端末に最も近い【a】サーバから動画を配信するようにします。【a】サーバは、動画配信を要求されたとき、要求された動画を保持していれば代理応答し、保持していなければ動画を保持しているX社動画サーバにアクセスして動画を取得し、応答します。』

通常時というかこれまでは、クライアントがX社動画サーバに対してリクエストをし、X社動画サーバがレスポンスを返すという形で行われてきました。

CDNを用いると、クライアントはX社動画サーバではなく『キャッシュ』サーバ、もしくは『エッジ』サーバと呼ばれるサーバに対してリクエストを行います。

キャッシュ、エッジサーバはリクエストされた動画を保持（キャッシュ）していれば代理応答し、動画を保持していなければX社動画サーバに対して、動画取得を行います。

ちなみに、X社動画サーバのようにコンテンツの大本があるサーバのことをオリジンサーバと呼びます。

ということで、解答例としては『キャッシュ（5文字）』もしくは『エッジ（3文字）』となります。

なお、クライアントがどのようにして、一番近いキャッシュサーバにアクセスするかはDNSを用いることで実現しています。

設問1 (2)

【b】の部分として、『その仕組みによって、【b】攻撃への耐性も向上しますね。』とあります。

重要な部分として、CDNを用いていない現状の問題としては、『X社動画サーバの負荷が高くなっており、インターネット回線もひっ迫している。』とあります。

このようなサーバの負荷を高めたり、回線をひっ迫させるような攻撃を考えると『DDoS（4文字）』攻撃が挙げられます。

CDNを用いることでDDoS攻撃を受けるのはキャッシュサーバとなり、サーバ本体の負荷やインターネット回線のひっ迫は発生しずらくなりますのでDDoS攻撃への耐性が向上します。

設問1 (3)

【c】の部分として、『HTTPリクエストの【c】ヘッダにはRFC7230に基づいて、X-FQDNが指定される。』とあります。

HTTPリクエストにおいてFQDNが入るヘッダは『Host（4文字）』ヘッダです。

実際のパケットキャプチャを用いて確認していきますが、HTTPリクエストのHostヘッダ部分にFQDNが含まれていることがわかります。

直近の傾向として、HTTPに関する出題が多くなってきましたので、HTTPに関しては一度抑えておいたほうがようさそうです。

設問1 (4)

下線部①としては、『Y-CDN-U-FQDNを名前解決したIPアドレスと宛先とする通信をFWで拒否すると、複数のWebサイトが閲覧できなくなる影響があります。』とあります。

Y-CDN-U-FQDNについては図5内に『あるCDN（以下、CDN-Uという）が、X社内から頻繁にアクセスする他社のWebサイトの複数で利用されているとする。それらのWebサイトの一つをY社Webサイトとする（以下、Y社WebサイトのFQDNをY-FQDNといい、CDN-UからY社Webサイト用に割り当てられたFQDNをY-CDN-U-FQDNという）。』とあります。

たとえば、Apacheには1つのWebサーバ上で複数のWebサイトを動作させることができるバーチャルホストという機能があります。

test1.com : X.X.X.X
test2.com : X.X.X.X

上記のようにIPアドレスは1つでも2つのWebサイトを設定をすることができ、クライアント（PC）はURLにhttp://test1.comと入力すれば”test1.com”側にアクセスでき、http://test2.comと入力すれば”test2.com”側にアクセスすることができます。

Webサイトは2つなのですがDNSによる名前解決ではどちらもX.X.X.Xという結果が返ってきます。

このようにY-CDN-U-FQDNを名前解決したIPアドレスが他のサイトでも使用されている可能性がありますので、単純にこのIPアドレスのみを拒否した場合に下線部のように複数のWebサイトが閲覧できなくなる可能性があります。

よって解答例としては、『Y-CDN-U-FQDNを名前解決した結果のIPアドレスと同じIPアドレスのWebサイト（44文字）』と考えることができます。

設問1 (5)

【d】の部分としては、『【d】とHTTPリクエスト中の【c：Host】ヘッダの値が一致していることを検証して、』とあります。

図4(4)に、『TLSの接続先サーバ名にはRFC6066に基づいて、HTTPリクエストの【c】ヘッダにはRFC7230に基づいて、X-FQDNが指定される。』とあります。

正常な通信であればTLSの接続先サーバ名と【c：Host】ヘッダのFQDNは一致すると考えることができます。

図5(3)に『Y-CDN-U-FQDNを名前解決したIPアドレスのサーバとのHTTPS通信を行うため、TLS接続を確立する。』とあり、図5(4)に『当該マルウェアは、HTTPリクエストを送信する際、【c：Host】ヘッダにZ-FQDNを指定する。』とあります。

つまりはCDNを悪用してドメインフロンティング攻撃が行われる場合、TLSの接続先サーバ名はY-CDN-U-FQDNで、HostヘッダはZ-FQDNとなっており異なっている状況となります。

このようにTLSの接続先サーバ名とHTTPリクエスト中のHostヘッダが一致していない場合に遮断するとすればよいので、解答例としては『TLSの接続先サーバ名（11文字）』と考えることができます。

設問2 (1)

下線部②としては、『STの偽装については、認証サーバ側で検知することができません。』とあります。

図7および表1を確認すると、認証サーバは処理2で『TGTを復号して検証し、問題なければ、STを発行する。』とありSTを発行のみを行っており、GrW-Gサーバで処理3として『STを復号して検証し、問題なければ、アクセスを許可する。』とあり、認証サーバはその後STを用いた処理には関与していません。

なので、STが偽装されたところで、認証サーバは知る余地もないということです。

よって解答例としては、『認証サーバはSTの発行のみを行うため（18文字）』と考えることができます

設問2 (2)

下線部③としては、『奪取されたSTに対してサーバ管理者アカウントのパスワードの総当たり攻撃が行われ、それが成功すると、当該サーバ管理者アカウントでアクセスできるサーバが乗っ取られてしまいます。この総当たり攻撃は、サーバ側でログイン連続失敗時のアカウントロックを有効にしていても有効になりません。』とあります。

そもそもSTとは、図7の注釈に『アクセス対象のサーバごとに発行されるチケットである。アクセス対象のサーバの管理者アカウント（以下、サーバ管理者アカウントという）のパスワードハッシュ値を鍵として暗号化されている。』とあります。

このSTに対する攻撃はKerberoastingと呼ばれます。

記載のある通りですが、奪取したSTをオフラインで総当たり攻撃や辞書攻撃などをして、パスワードを解析します。

攻撃はSTに対して行われますので、サーバに対して行われるわけではないので、サーバ側で対策しても意味がないということがわかります。

ということで解答例としては、『総当り攻撃はサーバではなく、STに対してオフラインで行われるため（33文字）』と考えることができます。

設問3 (1)

【e】の部分として、『図8中の(3)のHTTPリクエスト中の【e】からSAML Requestを取得する。』とあります。

知識がある方は即答できたかと思いますが、解答は『ウ　クエリ文字列』となります。

『http://sample.com&aabbccddee』というURLにおける『?』以降の内容となります。

知識がないという方は消去法で考えるとよいかと思います。

ア　cookie

Amazonや楽天にログインをし、一度ページを離れて再度アクセスした際にログインしている状態になっているかと思います。

また、Amazonや楽天で商品をカートに追加し、一度ページを離れて再度アクセスした際には、カートに追加されている状態で買い物を続けることができます。

このように再度アクセスした際にログインしている・していないやカートの状態などの状態を引き継いで利用できる際に用いられているのがcookieです。

cookieはサーバ側が発行するというケースが多く、図8や表2中にcookieは登場してきていませんので、違うと判断することができます。

イ　HTML

HTMLはWebページを構成するコード（言語）のことです。

HTTPリクエスト、つまりはこのページにアクセスしたいという要求時ではなく、HTTPリクエストに対するHTTPレスポンス時に含まれる内容となりますので、こちらも違うと判断することができます。

エ　ボディ

今回の処理の内容としては、表2中の処理1に『エンコード結果とIDaaSのログインがメインのURLを組み合わせて、リダイレクトURLを生成する。』とあります。

一般的にリダイレクト時にはGETが用いられます。

そしてGETを用いる際にはボディ部は含まれませんので違うと判断することができます。

SAML RequestにはGETを用いる場合とPOSTを用いる場合があります。

GETを用いる今回の場合は『HTTP Redirect Binding』と呼ばれ、エンコード結果をクエリ文字列内に含めるという今回の方法となりますが、URLの長さには制限がありますので長過ぎる場合には使用できない方法となってしまいます。

POSTの場合は『HTTP POST Binding』と呼ばれ、エンコード結果をボディ部に含めます。

この場合はGETの場合にあったURLの長さの制限に引っかからないというメリットがあります。

オ　リファラ

HTTPのリファラとはURLにおけるファイル名のことをさします。

『http://www.sample/index.html』のようなURLにおける『index.html』の部分となります。

昔のWebサイトですと表示されていることが多かったですが、今のWebサイトにおいて隠蔽されることが一般的かと思います。

URL内のリファラを部分をいじるのは自由ですが、リクエストを受ける側にそのファイルがなければエラーとなってしまいますので違うと判断することができます。

消去法でもやや難易度は高いですが、いくつかの選択肢は消せるかと思います。

設問3 (2)

【f】の部分として、『SAML Responseに含まれるデジタル署名を検証することで、デジタル署名が【f】のものであること』とあります。

処理3で『認証処理を行う。利用者の認証が成功した場合、処理4で用いるSAMLアサーションと、それに対するデジタル署名を含めたSAML Responseの送信フォームを生成する。』とあります。

そして、図8を確認しますと処理3を行っているのは『IDaaS』です。

ということで、解答は『ア：IDaaS』と考えることができます。

設問3 (3)

デジタル署名を検証する目的としては、受信したデータの送信者が正しいことおよびそのデータが改ざんされていないことです。

【g】の部分として、『SAML Responseに含まれるデジタル署名を検証することで、デジタル署名が【f：IDaaS】のものであること、及びSMALアサーションの【g】がないことを確認する。』とあります。

なので解答例としては『改ざん（3文字）』と考えることができます。

設問3 (4)

まずは【h】から考えていきます。

【h】の部分として、『図8中の処理【h】で用いるURL』とあります。

URLが登場する処理は処理『1』となります。

次に、【i】と【j】について考えていきます。

【i】および【j】の部分として、『図8中の処理【i】及び処理【k】において必要なデジタル証明書などがあります。』とあります。

注意してほしいのは『デジタル証明書』であって、『デジタル署名』ではないことです。

デジタル署名はハッシュ値をIDaaSの秘密鍵で暗号化したもので、検証の際にはIDaaSの公開鍵を用いて行う必要があります。

そして、デジタル証明書とは公開鍵の発行元を証明するものとなります。

処理3でデジタル署名と一緒にデジタル証明書を送付し、処理4でデジタル証明書（公開鍵）を用いてデジタル署名の検証を行います。

ということで、処理『3』と処理『4』が該当すると考えることができます。

よくデジタル署名は印鑑、デジタル証明書は印鑑証明に例えられます。

印鑑と印鑑証明をセットで提出することで信頼性がより高まりますので、デジタル署名とでデジタル証明書がセットで送付されることがあります。

設問4 (1)

まずは【k】から考えていきます。

表3中の利用手順に『(1) 主催者は、Sサービスにアクセスする。』とあります。

まず主催者（利用者）はSサービスにアクセスするところから処理が始まります。

よって『ウ：Sサービス』と考えることができます。

次に【l】について考えていきます。

少し強引ではありますが、【l】は図9内の(3)で利用者から認可要求を受けて認可コードを発行していたり（認可同意処理）、(8)でトークン要求を受けてトークンを発行していたりします（トークン応答）。

この点から認証関連のサービスであると推測することで、『イ：IDaaS』と考えることができます。

そして、残った【m】には『ア：GrW-G』が入ると考えることができます。

設問4 (2)

先程の設問4 (1)で穴埋めをしましたので、問題に関連する【k：Sサービス】、【m：GrW-G】については埋めています。

【n】は図9内の処理としてあります。

重要な部分として、『Sサービスは、GrW-Gから主催者のスケジュールを取得し、空き時間を表示する。』とあります。

つまりは【k：Sサービス】から【m：GrW-G】に対して行われるべき処理となりますので、『エ』と考えることができます。

設問4 (3)

【o】、【p】の部分として、『対策として、stateパラメタの実装が求められています。適切な実装であれば、図9中の【o】において、stateパラメタを付与して送信し、図9中の【p】で送られてきたものと比較することで、攻撃を検知しているはずです。』とあります。

OAuth2.0におけるクロスサイトリクエストフォージェリ攻撃（CSRF攻撃）において有効な対策はstateパラメータを使用することです。

stateパラメータはURL上に付与される単純なコードとなりますが、認可要求を行ったユーザとリダイレクトを行いアクセスしたユーザが一緒であることを証明することに役立ちます。

利用者は【k：Sサービス】に対して(1)サービス要求を行い、(2)リダイレクトを受けています。

このタイミングで【k：Sサービス】はstateパラメータの発行を行います。

次に利用者は【l：IDaaS】に対して(3)認可要求を行いますが、このやり取りでもstateパラメータは含めた状態で行われます。

その後、(4)認可同意処理、(5)リダイレクトを受け、再度【k：Sサービス】に対して(6)認可コードの要求を行います。

このタイミングでstateパラメータのチェックが行われ、一致する場合は後続の処理が行われ、一致しない場合は攻撃であると検知します。

このようにstateパラメータは認可要求を行ったユーザと認可コードを送るユーザが一緒であることを証明します。

ということで、解答としては『o：(2)』、『p：(6)』となります。

攻撃と検知される場合ですが、攻撃者が処理を進めていき(5)リダイレクトで受け取ったURLをメールなどで攻撃対象へ送付します。

state値はセッションに基づいて付与されます。

攻撃者と攻撃対象のセッションは異なりますので、state値も異なります。

なので、攻撃対象はメール記載のURLにアクセスしてしまってもstate値が異なるため移行の処理を進めずCSRFを防ぐことができます。

設問4 (4)

この問題は知識が必要となります。

【q】の部分として、『Sサービスのスマホアプリでランダムな検証コードとその値を基にしたチャレンジコードを作成して、そのチャレンジコードを認可要求に追加し、検証コードをトークン要求に追加します。二つのコードを検証することで、検証コードを知らない攻撃者からのトークン要求を排除できます。この仕組みは、【q】として標準化されています。』とあります。

ア　ASLR Address Space Layout Randomization

コンピュータにおけるデータ領域をランダムに配置するという技術です。

データ領域を規則的に配置するよりもランダムに配置することで攻撃者が発見する可能性を下げることができます。

イ　EIAM　Enterprise Identify and Access Management

『Enterprise』の『IAM』と分割して考えるとわかりやすいかと思います。

社員番号などをもとに、企業内で使用するサービスやアプリケーション、PCなどにログインする際に用いるユーザIDを一元的に管理することができます。

ウ　PKCE Proof Key for Code Exchange

解答はこちらの『ウ：PKCE』となります。

エ　SCIM System for Cross-domain Identify Management

直訳の通りではあるのですが、複数のドメイン間でユーザIDなどの情報をやりとりする規格となります。

英語からなんとなく『ウ』を選んだという方もいらっしゃるかと思いますが、それも立派な解き方です。

設問5 (1)

重要な部分として、『T社が運営しているメッセージ投稿サイト（以下、T社投稿サイトという）とX社動画サーバとを連携させ、T社投稿サイトの認証サーバを用いた認証機能、及びT社投稿サイトの投稿サーバへの自動投稿機能をX社動画サーバに追加したいというものだった。』とあります。

この点から登場人物は『X社動画サーバ』、『T社投稿サイトの認証サーバ』、『T社投稿サイトの投稿サーバ』に絞ることができます。

次に重要な部分として、『X社動画サーバに動画を投稿すると、”動画の概要”がT社投稿サイトに自動で投稿されるようにもできる。』とあります。

図10を確認しますと、中略のあとの処理に【r】から【t】に対して『APIを使った”動画の概要”の投稿』があることがわかります。

ということで、【r】は『オ：X社動画サーバ』、【t】は『ウ：T社投稿サイトの投稿サーバ』と考えることができます。

そして、残った【s】は『エ：T社投稿サイトの認証サーバ』となります。

設問5 (2)

『(8)トークン応答時』にIDトークンを送付しますので、こちらが解答となります。

重要な部分として、『認可コードフローの場合、IDトークンは、JSON Web Token形式で表現され、ヘッダ、ペイロード、署名の三つの部分で構成されます。署名は、ヘッダとペイロードに対して、T社投稿サイトの認証サーバの秘密鍵を使って作成します。』とあります。

IDトークンを構成する署名がT社投稿サイトの認証サーバの秘密鍵を使用して作成されているという点からも、IDトークン自体もT社投稿サイトの認証サーバで作成されていると考えることができます。

設問5 (3)

こちらは知識が必要な問題となります。

【v】の部分として、『ヘッダ、ペイロード、署名はそれぞれ【v】でエンコードされます。』とあります。

ODICにおいてIDトークンのエンコードには『イ：base64url』が用いられます。

重箱の隅をつつくような問題となっていますので、回答できなくてもお気になさらず。

設問5 (4)

【w】、【x】の部分として、『ハイブリッドフローを用いる場合、stateパラメタのほか、nonce値を実装しているかを確認すべきです。まず、nonce値と生成し、【w】に含めて送信します。次に、送られてきた【x】に含まれるnonce値を検証することで、攻撃者によるIDトークンの不正利用を防ぐことができます。』とあります。

nonce値の発行は利用者からサービス要求があったタイミングで、X社動画サーバ上で発行されます。

そのnonce値を含めて利用者はT社投稿サイトの認証サーバへ認証要求を行います。

処理が進み、トークン応答で発行されるIDトークンにもnonce値が含まれている状態で発行されます。

そして、X社動画サーバ上では、自身が発行したnonce値とIDトークンに含まれているnonce値が一致するかと確認します。

一致していればその後の処理を進め、一致しない場合はその後の処理を進めません。

ということで、解答例としては、【w】は『認証要求（4文字）』、【x】は『IDトークン（6文字）』となります。

公式解答例との比較

私の解答と公式解答を比較してみました。

満点ではないにせよ、少なくとも7割～8割程度は取れているかと思いますので合格ラインには達していると思います。

予想配点はあくまで予想ですので参考程度でお願いします。

出題テーマは『クラウドサービスへの移行』でした。

記述式の問題こそ少なかったですが、その分CDNやKerberos認証、SAML認証、OAuth2.0/OIDCなどの認証の仕組みや攻撃に対する対策が出題され、特に認証周りでは少し知識が必要となりました。

記述式の問題が少ないこと、半分程度は文章中のヒントから論理的に考えることで解答することができるかと思いますので、難易度としては普通～やや難程度だったかと思います。

設問	解答例	公式解答例	予想配点
設問1 (1)	キャッシュ（5文字） or エッジ（3文字）	キャッシュ	4点
設問1 (2)	DDoS（4文字）	DDoS	4点
設問1 (3)	Host（4文字）	Host	4点
設問1 (4)	Y-CDN-U-FQDNを名前解決した結果のIPアドレスと同じIPアドレスのWebサイト（44文字）	Y-CDN-U-FQDNを名前解決したIPアドレスと同じIPアドレスをもつWebサイト	8点
設問1 (5)	TLSの接続先サーバ名（10文字）	TLSの接続先サーバ名	5点
設問2 (1)	認証サーバはSTの発行のみを行うため（18文字）	STは認証サーバに送られないから	5点
設問2 (2)	総当り攻撃はサーバではなく、STに対してオフラインで行われるため（33文字）	総当り攻撃はオフラインで行われ、ログインに失敗しないから	7点
設問3 (1)	ウ	ウ	3点
設問3 (2)	ア	ア	3点
設問3 (3)	改ざん（3文字）	偽装	4点
設問3 (4)	h：1 i：3（順不同） j：4（順不同）	h：1 i：3（順不同） j：4（順不同）	各3点
設問4 (1)	k:ウ l:イ m:ア	k:ウ l:イ m:ア	各3点
設問4 (2)	エ	エ	3点
設問4 (3)	o：(2) p：(6)	o：(2) p：(6)	各3点
設問4 (4)	ウ	ウ	3点
設問5 (1)	r：オ s：エ t：ウ	r：オ s：エ t：ウ	各3点
設問5 (2)	(8)	(8)	3点
設問5 (3)	イ	イ	3点
設問5 (4)	w：認証要求（4文字） x：IDトークン（6文字）	w：認証要求 x：IDトークン	各4点