令和4年度 春期 情報処理安全確保支援士（午後Ⅱ問2）解説

テーマ: クラウド移行・CDN・SAML/OAuth2.0/OIDC認証

---

目次・設問ジャンプ

• 設問1 (CDN・攻撃)
• 設問2 (Kerberos)
• 設問3 (SAML認証)
• 設問4 (OAuth 2.0)
• 設問5 (OIDC)

---

設問1 〔抜本的な対策の検討〕について

1. (1) 空欄 a について

問題文からの引用
「[ a ] サーバは、動画配信を要求されたとき、要求された動画を保持していれば代理応答し、保持していなければ動画を保持しているX社動画サーバにアクセスして動画を取得し、応答します。」

着眼点・注目ポイント
「要求された動画を保持していれば代理応答し」という動作の記述に着目します。オリジンサーバ（X社動画サーバ）の代わりにデータを一時保存して配信を肩代わりする分散サーバ（エッジサーバ）の役割を表す専門用語を導き出します。

• 正解: キャッシュ
• 解説: CDN（Content Delivery Network）において、各地のエッジに配置される分散サーバは「キャッシュサーバ」と呼ばれます。オリジンサーバのコンテンツをキャッシュ（一時保持）してエンドユーザーに近い場所で代理応答することにより、応答の高速化とオリジンサーバへのアクセス集中防止を実現します。

---

2. (2) 空欄 b について

問題文からの引用
「多くの動画配信が代理応答されるので、X社動画サーバの負荷が軽減されます。 Cさん: その仕組みによって, [ b ] 攻撃への耐性も向上しますね。」

着眼点・注目ポイント
前文の「負荷が高くなっており、インターネット回線もひっ迫している」「アクセスが代理応答され負荷が軽減される」という点から、過剰な負荷をかけてサービス不能に追い込む攻撃に対する耐性を指していると分かります。英字5字以内という指定も重要です。

• 正解: DDoS
• 解説: 大量の端末から一斉にアクセスを送りつけてサーバや回線をダウンさせる分散サービス不能攻撃（DDoS攻撃: Distributed Denial of Service attack）です。CDNは多数のエッジサーバでアクセスを分散・代理応答するため、オリジンサーバに対する直接のDDoS攻撃の影響を最小限に抑制できます。

---

3. (3) 空欄 c について

問題文からの引用
「HTTPリクエストの [ c ] ヘッダにはRFC 7230 に基づいて、X-FQDN が指定される。要求された動画をM社 CDN が保持していない場合、M社CDNは、HTTP リクエストの [ c ] ヘッダから X社動画サーバを特定し、HTTPリクエストを転送する。」

着眼点・注目ポイント
RFC 7230（HTTP/1.1の標準規格）において、アクセス先のホスト名（FQDN）を指定するために使われるHTTPリクエストヘッダの名前を問う問題です。

• 正解: Host
• 解説: HTTP/1.1では、1つのIPアドレスで複数のWebサイト（バーチャルホスト）を運用できるため、リクエスト先のFQDNを指定する Host ヘッダが必須とされています。CDNもこの Host ヘッダのFQDNをチェックして、どのオリジンサーバにリクエストを転送するかを判断します。

---

4. (4) 下線①について、閲覧できなくなるWebサイトの範囲

問題文からの引用
「①Y-CDN-U-FQDNを名前解決したIPアドレスを宛先とする通信をFWで拒否すると、複数の Web サイトが閲覧できなくなる影響があります。」

着眼点・注目ポイント
図5(1)の「ある CDN (以下 CDN-Uという)が、X社内から頻繁にアクセスする他社のWebサイトの複数で利用されているとする」に着目します。CDNでは、1つのIPアドレス（エッジサーバ）で複数の異なるテナント（Webサイト）の通信を共有処理している点が重要です。

• 正解・解答例: Y-CDN-U-FQDNを名前解決したIPアドレスと同じIPアドレスをもつWebサイト
• 解説: CDN事業者は限られたIPアドレスプールを複数の顧客サイトで共有運用（マルチテナント）しています。そのため、特定のFQDN（Yサイト）のIPアドレスをFWで拒否すると、偶然同じエッジIPアドレスが割り当てられている無関係な他の正当なWebサイトへの通信まで一括で遮断されてしまいます（巻き添え被害）。

---

5. (5) 空欄 d について

問題文からの引用
「X社では、FW又はプロキシサーバを、アウトバウンド通信の復号及び高機能な通信解析ができるものに替え、[ d ] と HTTP リクエスト中の [ c (Host) ] ヘッダの値が一致していることを検証して、一致していなければ遮断するという対策を検討してもよいでしょう。」

着眼点・注目ポイント
図4(3)「TLS 接続を確立する。TLSの接続先サーバ名にはRFC 6066に基づいて...X-FQDN が指定される」およびドメインフロンティング攻撃の仕組み（TLSハンドシェイク時のSNI偽装）に着目します。プロキシでSSL復号（TLS復号）を行った際、TLS接続時に指定されたSNIの値と、復号されたHTTPヘッダの Host 値の矛盾を検知するのが対策となります。

• 正解・解答例: TLSの接続先サーバ名 （または SNI / SNIの値）
• 解説: ドメインフロンティング攻撃は、TLS層の「SNI（接続先サーバ名）」とHTTP層の「Hostヘッダ」に異なるFQDNを指定するギャップを利用します。通信を復号し、SNI（TLSの接続先サーバ名）とHostヘッダの値が同一であるかを検知・比較することで攻撃を防ぐことができます。

---

設問2 〔SSOの現状〕（Kerberos認証）について

1. (1) 下線②について、認証サーバ側で検知できない理由

問題文からの引用
「一方,②STの偽造については、認証サーバ側で検知することができません。」

着眼点・注目ポイント
図7「Kerberos認証の流れ」の通信経路に着目します。XPCが取得したST（サービスチケット）は、アクセス要求時に「XPCからGrWサーバへ直接送信」されており、認証サーバを通っていません。

• 正解・解答例: STは認証サーバに送られないから
• 解説: Kerberos認証において、端末（XPC）が認証サーバから取得したST（Service Ticket）は、目的のアプリサーバ（GrWサーバ等）へ直接提示されます。認証サーバはこのやり取り（提示）に関与しないため、第三者が不正に偽造したSTを用いてアクセスしても検知できません。

---

2. (2) 下線③について、アカウントロックが対策にならない理由

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

着眼点・注目ポイント
STの注釈2「アクセス対象のサーバの管理者アカウントのパスワードハッシュ値を鍵として暗号化されている」に着目します。奪取したSTを復号する解析作業（総当たり攻撃）はどこでどのように行われるかを考えます。

• 正解・解答例: 総当たり攻撃はオフラインで行われ、ログインに失敗しないから
• 解説: パスワードハッシュ値で暗号化されたSTを入手した攻撃者は、自身の端末（オフライン環境）で様々なパスワード候補を使ってSTの復号を試みます（Kerberoasting攻撃）。サーバに対して認証リクエスト（アクセス試行）を送るわけではないため、サーバ上のログイン失敗回数はカウントされず、アカウントロックが働きません。

---

設問3 〔SaaSでのSSOの実現〕（SAML認証）について

1. (1) 表2中の e について

問題文からの引用
「処理2: 図8中の(3)のHTTPリクエスト中の [ e ] から SAML Request を取得する」
「処理1: リダイレクト先 URLを生成する。」

着眼点・注目ポイント
図8の(2)「リダイレクト」および(3)「HTTPリクエスト」の流れ（HTTP Redirectバインディング）に着目します。リダイレクト時、データはURLの末尾（クエリパラメータ）に付与されて送信されます。

• 正解: ウ （クエリ文字列）

選択肢の解説

• ア (cookie): 不適切。Cookieはセッション情報の保持等に使われるもので、リダイレクト時のパラメータ伝送経路ではありません。
• イ (HTML): 不適切。HTTP Redirectバインディング（GET送信）ではHTMLボディは含まれません。
• ウ (クエリ文字列): 正解。 HTTP GETによるリダイレクトでは、URLのクエリ文字列（?SAMLRequest=...）にエンコードされたデータが含まれます。
• エ (ボディ): 不適切。HTTP POSTバインディングの場合はボディに入りますが、本項のURL生成・リダイレクト処理（GET）ではクエリ文字列が正解となります。
• オ (リファラ): 不適切。Refererは直前の閲覧元URLを示すヘッダであり、SAML Requestそのものを格納する場所ではありません。

---

2. (2) 表2中の f について

問題文からの引用
「処理4: SAML Response に含まれるデジタル署名を検証することで、デジタル署名が [ f ] のものであること...を確認する。」

着眼点・注目ポイント
図8の処理3「IDaaSにおいてSAML Responseおよびデジタル署名を生成する」に着目します。SAML Responseを発行・署名したのはどのエンティティかを考えます。

• 正解: ア （IDaaS）

選択肢の解説

• ア (IDaaS): 正解。 IdP（アイデンティティプロバイダ）であるIDaaSが秘密鍵で署名を作成し、SP（SaaS）が事前共有されたIDaaSの公開鍵で検証します。
• イ (SaaS): 不適切。SaaSは署名を「検証する側（SP）」であり、検証対象の署名作成者ではありません。
• ウ (XPC): 不適切。クライアント端末（XPC）はSAML Responseを仲介して転送するだけであり、署名の作成者ではありません。

---

3. (3) 表2中の g について

問題文からの引用
「デジタル署名を検証することで...SAML アサーションの [ g ] がないことを確認する。」

着眼点・注目ポイント
デジタル署名が提供する主なセキュリティ機能（送信元認証および「改ざん検知・完全性の担保」）の観点から答えます。

• 正解・解答例: 改ざん （または 偽造）
• 解説: デジタル署名を検証することにより、「正当なIDaaSが発行したこと（真正性）」および「途中で内容が改ざんされていないこと（完全性）」を同時に証明・確認できます。

---

4. (4) 空欄 h, i, j に入れる数字

問題文からの引用
「事前共有する情報は、SAML アサーションで用いる属性、図8中の処理 [ h ] で用いる URL, 図8中の処理 [ i ] 及び処理 [ j ] において必要なデジタル証明書などがあります。」

着眼点・注目ポイント
表2中の各処理内容と連携に必要な事前設定をマッチングさせます。

• 「URL」が必要なのは：処理1でリダイレクト先URLを生成する部分、または処理2でIDaaSの受取URLを指定する部分。
• 「デジタル証明書」が必要なのは：デジタル署名の検証を行う処理（処理2でのリクエスト検証、処理3/4での署名検証）。

• 正解（IPA公式解答例）:
  • h = 2 （または 1）
  • i = 3, j = 4 （※ i, j は順不同。3と4）
• 解説:
  • h: SaaSが認証要求を送るIDaaSのログインURL（SSO URL）は、処理2（または処理1）で利用するために事前共有します。
  • i, j: 信頼関係の構築や署名検証のため、処理3（SaaSからの要求検証）および処理4（SaaSでのSAML Response署名検証）で証明書（公開鍵）が必要となります。

---

設問4 〔従業員からの要望〕（OAuth 2.0 / PKCE）について

1. (1) 図9中の k, l, m について

問題文からの引用
「図9 OAuth 2.0を利用したサービス要求からスケジュール情報の取得までの流れ」
「(1) サービス要求 → [ k ]」「(3) 認可要求 → [ l ]」「(9) 利用者情報の問合せ → [ m ]」

着眼点・注目ポイント
OAuth 2.0のロール（役割）をあてはめます。

• クライアント（認可を得てAPIを叩くサービス） = k (Sサービス)
• 認可サーバ（アクセストークンを発行するサーバ） = l (IDaaS-G)
• リソースサーバ（実際にスケジュール情報を保持しているサーバ） = m (GrW-G)

• 正解:
  • k: ウ （Sサービス）
  • l: イ （IDaaS-G）
  • m: ア （GrW-G）

選択肢の解説

• ア (GrW-G): リソースサーバ。スケジュールデータを保持しており、トークンを検証してリソースを提供する役目（mに該当）。
• イ (IDaaS-G): 認可サーバ。利用者に同意を求め、認可コードおよびアクセストークンを発行する役目（lに該当）。
• ウ (Sサービス): OAuthクライアント。利用者の代理としてリソースにアクセスするために認可を要求する役目（kに該当）。

---

2. (2) 図9中の n に入るシーケンス

問題文からの引用
「図9中の枠 [ n ] （(10)利用者情報の取得の後の動作）」

着眼点・注目ポイント
アクセストークンを取得・利用者情報を確認した後、Sサービス(k)がGrW-G(m)に対して「アクセストークンを提示してスケジュールを取得する通信」の流れを考えます。

• 正解: エ

• 解説: 正解の「エ」のフローは以下の通りです：

  • (11) Sサービス(k) → GrW-G(m) : スケジュール取得要求（アクセストークンを添付）
  • (12) GrW-G(m) → Sサービス(k) : スケジュール情報

  Sサービスがアクセストークンを用いて直接GrW-GのAPIにアクセスし、スケジュールデータを取得します。端末を介さずサーバ間でやり取りされます。

---

3. (3) 本文中の o, p に入れる通信番号

問題文からの引用
「対策として、state パラメタの実装が求められています。適切な実装であれば、図9中の [ o ] において, state パラメタを付与して送信し、図9中の [ p ] で送られてきたものと比較することで、攻撃を検知しているはずです。」

着眼点・注目ポイント
OAuth 2.0におけるCSRF対策パラメタ state のライフサイクルに着目します。

• 最初にクライアントから認可要求を送信するタイミング（o）
• 認可サーバから認可コードがレスポンス/リダイレクトで戻ってくるタイミング（p）

• 正解:
  • o: (3) （認可要求）
  • p: (6) （認可コード）
• 解説: クライアント（Sサービス）は(3)認可要求の送信時に一方向のランダム値 state を生成して付与します。(6)認可コードとともに返却された state の値が、自身が発行したものと一致するかチェックすることで、第三者がすり替えた認可コードを受信してしまうCSRF攻撃を防止します。

---

4. (4) 空欄 q について

問題文からの引用
「Sサービスのスマホアプリでランダムな検証コードとその値を基にしたチャレンジコードを作成して、そのチャレンジコードを認可要求に追加し、検証コードをトークン要求に追加します。二つのコードを検証することで...この仕組みは、[ q ] として標準化されています。」

着眼点・注目ポイント
ネイティブアプリ（スマホアプリ）等における認可コード横取り攻撃を防ぐための拡張仕様（Proof Key for Code Exchange）の名前を選びます。

• 正解: ウ （PKCE）

選択肢の解説

• ア (ASLR): Address Space Layout Randomization。OSのセキュリティ機能で、プログラムのメモリ配置をランダム化してバッファオーバーフロー攻撃等を防ぐ技術。
• イ (EIAM): Enterprise Identity and Access Management。企業向けの統合IDおよびアクセス権限管理の体系・製品。
• ウ (PKCE): 正解。 Proof Key for Code Exchange（ピクシー）。認可コード横取り攻撃対策としてOAuth 2.0を拡張した規格。
• エ (SCIM): System for Cross-domain Identity Management。クラウドサービス間でユーザーアカウント情報を自動同期（プロビジョニング）するための標準規格。

---

設問5 〔企画チームからの要望〕（OpenID Connect）について

1. (1) 図10中の r, s, t について

問題文からの引用
「T社が運営しているメッセージ投稿サイト...の認証サーバを用いた認証機能、及びT社投稿サイトの投稿サーバへの自動投稿機能をX社動画サーバに追加したい」
「図10 OIDCを用いたT社投稿サイトとX社動画サーバの連携の流れ」

着眼点・注目ポイント
OIDCの各登場人物をあてはめます。

• RP（Relying Party / 認証を利用する側） = r (X社動画サーバ)
• OP（OpenID Provider / 認証を提供する側） = s (T社投稿サイトの認証サーバ)
• APIリソースサーバ（動画の概要を自動投稿する先） = t (T社投稿サイトの投稿サーバ)

• 正解:
  • r: オ （X社動画サーバ）
  • s: エ （T社投稿サイトの認証サーバ）
  • t: ウ （T社投稿サイトの投稿サーバ）

選択肢の解説

• ア (IDaaS-G): 本設問（企画チームの要望：T社投稿サイト連携）では登場しません。
• イ (Sサービス): 本設問（T社連携）では登場しません。
• ウ (T社投稿サイトの投稿サーバ): リソースサーバ。API経由で「動画の概要」が自動投稿される宛先（tに該当）。
• エ (T社投稿サイトの認証サーバ): Identity Provider (OP)。会員のログイン認証を行いトークンを発行するサーバ（sに該当）。
• オ (X社動画サーバ): Relying Party (RP)。T社の認証機能を利用してユーザーをログインさせるクライアント（rに該当）。

---

2. (2) 本文中の u に入れる通信番号

問題文からの引用
「認可コードフローの場合, ID トークンは、図10 中の [ u ] で送付されます。」

着眼点・注目ポイント
認可コードフロー（Authorization Code Flow）において、クライアント（X社動画サーバ）がIDトークンを受け取るタイミングを考えます。認可コード(6)を添えて(7)トークン要求を送ったレスポンスで返却されます。

• 正解: (8) （トークン応答）
• 解説: OIDCの認可コードフローでは、(7)トークン要求に対する(8)トークン応答のJSONレスポンスの中に、アクセストークンとともに「IDトークン（id_token）」が含まれて返却されます。

---

3. (3) 本文中の v について

問題文からの引用
「IDトークンは、JSON Web Token 形式で表現され、ヘッダ、ペイロード、署名の三つの部分で構成されます。...ヘッダ、ペイロード、署名は、それぞれ [ v ] でエンコードされます。」

着眼点・注目ポイント
JWT（RFC 7519）の仕様において、各要素（ヘッダ・ペイロード・署名）をドット（.）で連結してHTTPヘッダ等で安全に送信するために使用されるエンコード方式を選択します。

• 正解: イ （base64url）

選択肢の解説

• ア (base32): 不適切。アルファベット26文字と数字6文字を使用する方式（TOTP等で使われる）。
• イ (base64url): 正解。 Base64からURLで特別な意味を持つ記号（+ や /）を置き換え、パディング（=）を省略したURLセーフなエンコード方式。
• ウ (ROT13): 不適切。アルファベットを13文字単にずらす古典的な暗号アルゴリズム。
• エ (UTF-8): 不適切。可変長文字コード（文字符号化方式）であり、バイナリやJSONをURLセーフな文字列に文字列化するエンコードではありません。

---

4. (4) 空欄 w, x に入れる字句

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

着眼点・注目ポイント
OpenID Connectにおけるリプレイ攻撃対策の nonce 値のライフサイクルに着目します。

• RPがランダム生成した nonce を最初にどこに入れて送るか？（w）
• OPから返却されるどのオブジェクトにその nonce が埋め込まれて戻ってくるか？（x）

• 正解・解答例:
  • w: 認証要求
  • x: IDトークン
• 解説:
  • クライアント（RP）はリクエスト作成時に一方向ランダム値である nonce を作成し、(3)認証要求のパラメータに付与します。
  • 認証サーバ（OP）は発行するIDトークンのクレーム（payload）内にその nonce 値をそのまま埋め込んで署名返却します。RPは受け取ったIDトークン内の nonce が元の値と一致するかチェックすることで、過去に取得されたIDトークンの使い回し（リプレイ攻撃）を防御します。