令和4年度 春期 情報処理安全確保支援士試験 午後II 問2 動画配信サービスのクラウド移行と各種認証方式のセキュリティ対策

設問解説

CDN（Content Delivery Network）の基本的な仕組みに関する問題です。
F氏の「CDNでは，インターネット上に a サーバというサーバを分散配置して，動画配信を要求した端末に最も近い a サーバから動画を配信するようにします」という発言から、分散配置されてコンテンツを一時的に保持し、オリジンサーバ（X社動画サーバ）の代理として応答を行うサーバを指していることが分かります。これは一般に キャッシュ サーバと呼ばれます。

高得点のポイント

• 正確性（内容）: CDNにおいてコンテンツを保持し代理応答を行うサーバ群が「キャッシュ」サーバであることを正確に理解し解答できているか。

設問解説

CDNの導入によって向上するセキュリティ上の耐性についての問題です。
CDNは、インターネット上の多数のキャッシュサーバでトラフィックを分散して処理するため、大量の通信を送りつけてサービスを停止させる攻撃に対して非常に有効です。この攻撃は DDoS（Distributed Denial of Service）攻撃と呼ばれます。

高得点のポイント

• 正確性（内容）: CDNが大量のトラフィックを分散吸収することで耐性が向上する攻撃手法が「DDoS」攻撃であることを理解しているか。

設問解説

HTTPリクエストにおいて接続先のFQDNを指定するヘッダに関する問題です。
図4の(4)に「RFC 7230に基づいて、HTTPリクエストの c ヘッダには、X-FQDNが指定される」とあります。また、図5の(4)のドメインフロンティング攻撃の例において、TLSの接続先と意図的に異なるFQDNを指定してCDNのエッジサーバに転送先を誤認させる目的で使われるHTTPヘッダは Host ヘッダです。

高得点のポイント

• 正確性（内容）: HTTP/1.1において宛先のホスト名を指定するために必須となるヘッダが「Host」ヘッダであることを理解しているか。

設問解説

CDNのIPアドレスをFWで拒否した場合の影響範囲に関する問題です。
図5の(1)において、「あるCDN（CDN-U）が、X社内から頻繁にアクセスする他社のWebサイトの複数で利用されている」ことが示されています。
CDNでは、多数のWebサイト（FQDN）の通信を共通のエッジサーバで受け付けるため、複数のFQDNが同一のIPアドレスに名前解決されることが一般的です。
したがって、Y-CDN-U-FQDNの名前解決結果であるIPアドレスを宛先としてFWで通信を拒否すると、そのIPアドレスを共有している（同じIPアドレスをもつ）他のすべてのWebサイトへのアクセスも遮断されてしまいます。

高得点のポイント

• 知識・理解度（内容）: CDNのエッジサーバのIPアドレスが単一のWebサイト専用ではなく、複数のWebサイトで共有されている事実を理解しているか。
• 論理性（構造）: FWによるIPアドレスベースの遮断がもたらす影響として、「同じIPアドレスをもつWebサイト」が巻き込まれて閲覧不能になるという論理的帰結を明確に記述できているか。

設問解説

ドメインフロンティング攻撃の対策として検証すべき項目についての問題です。
ドメインフロンティング攻撃は、TLS接続時に指定するサーバ名（SNI: Server Name Indicationなど）と、暗号化されたトンネル内を通るHTTPリクエストのHostヘッダの値を意図的に不一致にすることで、CDN側に本来の宛先とは異なる攻撃者サーバへ通信を転送させる手法です。
本文中のF氏の「アウトバウンド通信の復号及び高機能な通信解析ができるものに替え、d とHTTPリクエスト中の c (Host) ヘッダの値が一致していることを検証して」という説明から、比較対象となるのは TLSの接続先サーバ名 であることが分かります。

高得点のポイント

• 正確性（内容）: ドメインフロンティングの仕組み上、比較検証する対象がTLSの接続時のサーバ名情報であることを正確に抜き出し・記述できているか。

設問解説

Kerberos認証におけるST（Service Ticket）偽造を認証サーバで検知できない理由に関する問題です。
図7のKerberos認証の流れを確認すると、XPCは認証サーバからSTを取得した後(8)、GrWサーバへのアクセス時にそのSTをGrWサーバへ直接送信し(10)、GrWサーバ自身がSTの復号と検証(処理3)を行っています。
この過程において、STは認証サーバには送られないため、認証サーバ側ではSTが偽造されたり不正利用されたりしていることを直接検知する手段がありません。

高得点のポイント

• 知識・理解度（内容）: XPCから対象サーバへのアクセス時に、STが認証サーバを経由しない仕組みであることを正しく指摘できているか。
• 論理性（構造）: STの検証経路（送信先）を根拠として、認証サーバが関与・検知できないという因果関係が論理的に記述できているか。

設問解説

奪取されたSTに対するパスワード解読攻撃において、サーバ側のログインロックが対策にならない理由に関する問題です。
奪取されたSTにはサーバ管理者アカウントのパスワードハッシュ値を鍵として暗号化された情報が含まれており、攻撃者はこのSTを手元（オフライン環境）に持ち出し、総当たりで復号を試みることでパスワードの解読を行います。
この解読作業はオフラインで行われるため、実際のサーバに対するログイン試行（通信）は一切発生しません。したがって、サーバ側でログイン連続失敗時のアカウントロックを有効にしていても、試行自体を検知できず機能しません。

高得点のポイント

• 知識・理解度（内容）: 奪取されたSTに対する総当たり攻撃がネットワーク越しではなく「オフライン」で行われる攻撃であることを明記できているか。
• 論理性（構造）: オフラインでの攻撃であるがゆえに「サーバ側でログイン失敗が発生しない」ため、アカウントロックが機能しないという論理構造で説明できているか。

設問解説

SAML認証においてIDaaSがSAML Requestを取得する場所に関する問題です。
表2の処理1において、SaaSはSAML Requestをエンコードし、「IDaaSのログイン画面のURLと組み合わせて、リダイレクト先URLを生成する」とあります。リダイレクト（HTTP GET要求など）によって遷移先URLにパラメータを渡す場合、データはURLの末尾に付加される クエリ文字列 として送信されます。したがって、IDaaSはHTTPリクエスト中のクエリ文字列からSAML Requestを取得します。

各選択肢の解説

• ア (cookie): cookieは状態管理に用いられますが、SaaSからIDaaSへのSAML Requestの伝達手段としては適しません。
• イ (HTML): リダイレクトはHTTPステータスコードとLocationヘッダで行われるため、HTMLのパースは必要ありません。
• ウ (クエリ文字列): 正解です。URLパラメータとして付加されます。
• エ (ボディ): リダイレクト(HTTP GET)には通常ボディは含まれません。
• オ (リファラ): リファラは遷移元のURLを示すものであり、意図的なパラメータ渡しには用いません。

設問解説

SAML Responseのデジタル署名の検証主体に関する問題です。
表2の処理3において、利用者の認証が成功した場合に「SAMLアサーションと、それに対するデジタル署名を含めたSAML Response」を生成するのは IDaaS です。その後、XPCを経由してSaaSに渡されたSAML ResponseをSaaSが検証（処理4）する際、その署名が間違いなく認証を担った IDaaS のものであることを確認します。

各選択肢の解説

• ア (IDaaS): 正解です。署名を生成したエンティティであることを確認します。
• イ (SaaS): SaaS自身は署名の生成側ではなく、検証側です。
• ウ (XPC): XPCは単なる中継点であり、署名鍵を持っていません。

設問解説

デジタル署名によって確認できるセキュリティ特性に関する問題です。
表2の処理4において、デジタル署名を検証する目的は、署名が正規の発行者（IDaaS）によるものであることの確認に加え、途中でデータ（SAMLアサーション）の改ざんや 偽造 が行われていないことを保証するためです。

高得点のポイント

• 正確性（内容）: デジタル署名の主な役割が、データの完全性確認および「偽造」の防止であることを理解し記述できているか。

正解の根拠

表2の処理1では、SaaSがSAML Requestを生成してエンコードし、「IDaaSのログイン画面のURL」と組み合わせてリダイレクト先URLを生成します。SaaSがリダイレクト先URLを生成するためには、あらかじめIDaaSのログイン画面のURLを共有しておく必要があります。したがって、事前に共有するURLを用いる処理 h は「1」です。

正解の根拠

SAML認証では、メッセージの改ざん防止や送信元の真正性を確認するためにデジタル署名とデジタル証明書を使用します。
表2の処理3では、IDaaSがSAML Responseにデジタル署名を付与して送信フォームを生成します。この署名生成のために、IDaaS側の秘密鍵および対応するデジタル証明書が必要です。
また、処理4では、SaaSがそのデジタル署名を検証するためにIDaaSのデジタル証明書を使用します。
したがって、デジタル証明書が必要となる処理 i，j には「3」と「4」が入ります（順不同）。
順不同で「3」と「4」の両方を答えていれば満点、どちらか一方のみを答えている場合（同じ正解を二つ書いた場合を含む）は半分、正解を一つも答えていない場合（同じ誤答を二つ書いた場合を含む）は0点となります。

設問解説

OAuth 2.0を利用した連携フローの構成要素（エンティティ）を特定する問題です。
図9のシーケンスにおいて、利用者の端末から直接(1)サービス要求を受け付け、全体のフローを主導するクライアントアプリケーションの役割を果たしているのは、新しく導入を検討しているスケジュール調整サービスである Sサービス です。したがって、kには Sサービス が入ります。

各選択肢の解説

• ア (GrW-G): OAuth 2.0におけるリソースサーバの役割であり、最後にAPIでアクセスされる対象(m)です。
• イ (IDaaS-G): OAuth 2.0における認可サーバの役割であり、認可要求を受けてトークンを発行する対象(l)です。
• ウ (Sサービス): 正解です。OAuth 2.0のクライアントとして動作します。

設問解説

OAuth 2.0を利用した連携フローの構成要素（エンティティ）を特定する問題です。
図9において、クライアント(k)からリダイレクトされた端末が(3)認可要求を送信し、(4)認可同意処理を行い、(6)認可コードを発行する役割を担うのは認可サーバです。本システムにおいて認証および認可を集中管理しているのは IDaaS-G です。したがって、lには IDaaS-G が入ります。

各選択肢の解説

• ア (GrW-G): リソースサーバ(m)の役割です。
• イ (IDaaS-G): 正解です。認可サーバとして機能します。
• ウ (Sサービス): クライアント(k)の役割です。

設問解説

OAuth 2.0を利用した連携フローの構成要素（エンティティ）を特定する問題です。
図9において、クライアント(k)が認可サーバ(l)からトークンを取得した後、(9)利用者情報の問合せを行う先のシステムはリソースサーバです。本システムにおいて従業員のスケジュール情報（リソース）を保持しているのはグループウェアである GrW-G です。したがって、mには GrW-G が入ります。

各選択肢の解説

• ア (GrW-G): 正解です。保護されたリソースを保持するリソースサーバです。
• イ (IDaaS-G): 認可サーバ(l)の役割です。
• ウ (Sサービス): クライアント(k)の役割です。

正解の根拠

OAuth 2.0において、アクセストークンを取得したクライアントは、保護されたリソースを保持するリソースサーバに対して、そのアクセストークンを提示してリソースへのアクセスを要求します。
本問では、クライアントであるSサービス（k）が、認可サーバであるIDaaS-G（l）からアクセストークンを取得済みです。そして、スケジュール情報を保持しているリソースサーバはGrW-G（m）です。
したがって、アクセストークンを得たクライアントであるSサービス（k）が、リソースサーバであるGrW-G（m）に対して「(11)スケジュール取得要求」を送り、GrW-G（m）からSサービス（k）へ「(12)スケジュール情報」が返却される流れが適切です。これを示している「エ」が正解です。

各選択肢の解説

• ア: 利用者の端末から認可サーバであるIDaaS-G（l）へ直接スケジュール情報を要求する流れになっています。スケジュール情報を取得するのはSサービス（k）であり、利用者の端末が直接要求している点、および要求先が認可サーバである点が誤りです。
• イ: 利用者の端末からリソースサーバであるGrW-G（m）へ直接スケジュール情報を要求する流れになっています。スケジュール情報を取得するのはSサービス（k）であり、利用者の端末が直接要求している点が誤りです。
• ウ: Sサービス（k）からIDaaS-G（l）へ要求する流れになっています。IDaaS-Gは認可サーバであり、スケジュール情報を保持するリソースサーバではないため、要求先が認可サーバである点が誤りです。
• エ: アクセストークンを得たクライアントであるSサービス（k）が、リソースサーバであるGrW-G（m）にスケジュール情報を要求して取得する正しい流れを示しているため正解です。

設問解説

CSRF（クロスサイトリクエストフォージェリ）攻撃を防ぐための state パラメータの実装に関する問題です。
OAuth 2.0のフローにおいて、クライアント（Sサービス）は認可要求を初期化する際、ランダムな state パラメータを生成してセッションに保存し、利用者の端末を認可サーバへリダイレクトさせます。図9において、Sサービスが利用者の端末にリダイレクトを指示し、その際に state を付与して送信させる通信は (2) の通信です。

高得点のポイント

• 正確性（内容）: OAuth 2.0の認可コードフローにおいて、CSRF対策として state パラメータが付与される初期リダイレクトのステップを正しく把握できているか。

設問解説

CSRF攻撃を防ぐための state パラメータの検証タイミングに関する問題です。
認可サーバ（IDaaS-G）での処理が完了すると、認可サーバは state パラメータをそのまま付与してクライアントのコールバックURLへリダイレクトします。利用者の端末からクライアント（Sサービス）へ認可コードと共に state パラメータが送り返される通信は、図9の (6) の通信です。
クライアントはこのタイミングで、受け取った state と事前に保存していた値を比較検証し、正当なフローであることを確認します。

高得点のポイント

• 正確性（内容）: 認可サーバから戻ってきた state パラメータをクライアントが受け取り比較検証するステップを正しく把握できているか。

設問解説

認可コード横取り攻撃に対する対策技術の名称を問う問題です。
スマートフォンアプリ等のネイティブアプリにおいて、悪意のあるアプリがカスタムURLスキームなどを横取りして認可コードを奪う攻撃への対策として、ランダムな検証コード（code_verifier）とそのハッシュ値等によるチャレンジコード（code_challenge）を用いる仕組みは PKCE (Proof Key for Code Exchange) として標準化されています。

各選択肢の解説

• ア (ASLR): メモリアドレス空間の配置をランダム化し、バッファオーバーフロー等の攻撃を防ぐOSレベルの技術です。
• イ (EIAM): 企業内のID・アクセス管理の概念であり、特定のプロトコル拡張ではありません。
• ウ (PKCE): 正解です。RFC 7636で定義された、OAuth 2.0クライアントのためのセキュリティ拡張です。
• エ (SCIM): クラウドサービス間でID情報を自動的に同期・管理するためのプロトコルです。

設問解説

OpenID Connect（OIDC）を用いた連携フローの構成要素を特定する問題です。
図10において、利用者が(1)サービス要求を行い、OIDCのクライアント（Relying Party: RP）として機能するシステムは、自動投稿機能を追加する対象である X社動画サーバ です。したがって、rには X社動画サーバ が入ります。

各選択肢の解説

• ア (IDaaS-G): X社内の認証基盤であり、T社投稿サイトとの連携には直接関与しません。
• イ (Sサービス): スケジュール調整サービスであり、このOIDC連携とは無関係です。
• ウ (T社投稿サイトの投稿サーバ): 最後にAPIでアクセスされるリソースサーバ(t)です。
• エ (T社投稿サイトの認証サーバ): OIDCの認証サーバ（OpenID Provider: OP）の役割(s)です。
• オ (X社動画サーバ): 正解です。OIDCのクライアントとして動作します。

設問解説

OpenID Connect（OIDC）を用いた連携フローの構成要素を特定する問題です。
図10において、クライアント(r)からリダイレクトされた端末が(3)認証要求を送信し、(4)ログイン処理を行い、最終的にIDトークンやアクセストークンを発行するOIDCのOpenID Provider（OP）の役割を担うのは、認証機能を提供する T社投稿サイトの認証サーバ です。したがって、sには T社投稿サイトの認証サーバ が入ります。

各選択肢の解説

• ア (IDaaS-G): 今回のOIDC連携の認証サーバではありません。
• イ (Sサービス): OIDC連携とは無関係です。
• ウ (T社投稿サイトの投稿サーバ): トークン取得後にアクセスされるリソースサーバ(t)です。
• エ (T社投稿サイトの認証サーバ): 正解です。認証・認可を行いトークンを発行します。
• オ (X社動画サーバ): クライアント(r)の役割です。

設問解説

OpenID Connect（OIDC）を用いた連携フローの構成要素を特定する問題です。
図10のフローの最後で、X社動画サーバ(r)がトークンを利用して「APIを使った“動画の概要”の投稿」を行う対象システムは、保護されたリソースを提供するリソースサーバです。本文の要望にある「T社投稿サイトの投稿サーバへの自動投稿機能」という記述から、tには T社投稿サイトの投稿サーバ が入ります。

各選択肢の解説

• ア (IDaaS-G): OIDC連携には関与しません。
• イ (Sサービス): OIDC連携には関与しません。
• ウ (T社投稿サイトの投稿サーバ): 正解です。APIアクセスを受けるリソースサーバです。
• エ (T社投稿サイトの認証サーバ): トークンを発行する認証サーバ(s)です。
• オ (X社動画サーバ): クライアント(r)の役割です。

設問解説

OIDCの認可コードフローにおいてIDトークンが送付付されるタイミングに関する問題です。
認可コードフロー（Authorization Code Flow）では、認証サーバでの認証後、まず認可コードが発行され、フロントチャネル（ブラウザ経由）でクライアントに渡されます。その後、クライアントはバックチャネル（直接通信）でトークンエンドポイントに認可コードを提示し、アクセストークンと IDトークン を取得します。
図10において、クライアント(r)が(7)トークン要求を行い、認証サーバ(s)が応答する (8) の通信でIDトークンが送付されます。

高得点のポイント

• 正確性（内容）: 認可コードフローの特徴を理解し、IDトークンがトークンエンドポイントからの応答として安全に渡されるステップを正確に特定できているか。

設問解説

JSON Web Token (JWT) のエンコード方式に関する問題です。
JWTは、ヘッダ、ペイロード、署名の3つの部分から構成され、各部分はURLセーフな文字列として扱うために base64url 方式でエンコードされ、ドット（.）で連結されます。標準のBase64とは異なり、URLで特別な意味を持つ文字（+ や /）を使用しないのが特徴です。

各選択肢の解説

• ア (base32): JWTのエンコード規格としては使用されません。
• イ (base64url): 正解です。JWTの標準仕様で定義されています。
• ウ (ROT13): 単なるアルファベットの13文字シフト暗号であり、バイナリデータのエンコードには用いません。
• エ (UTF-8): 文字エンコーディング方式であり、バイナリを印字可能文字列に変換するエンコード方式ではありません。

設問解説

OIDCにおける nonce を用いたリプレイ攻撃対策の実装に関する問題です。
ハイブリッドフロー等において、クライアントは認証セッションとIDトークンを紐付けるためにランダムな nonce 値を生成し、認可エンドポイントへの 認証要求（図10の(3)の要求内容を含んだリダイレクト先へのアクセス）のパラメータに含めて送信します。

高得点のポイント

• 正確性（内容）: OIDCのフローにおいて nonce 値が付与される最初のステップが「認証要求」であることを正確に抜き出し・記述できているか。

設問解説

（設問 w の解説に続く）
クライアントから送信された nonce 値は、認証サーバによって生成される IDトークン のペイロード内のクレームとして格納されて返却されます。クライアントは、受け取ったIDトークン内の nonce 値と自身が生成・保存していた値を比較検証することで、攻撃者によるIDトークンの不正利用（リプレイ攻撃等）を防ぐことができます。

高得点のポイント

• 正確性（内容）: 認証サーバから返却され、nonce クレームを含んでおり検証対象となるデータが「IDトークン」であることを正確に抜き出し・記述できているか。