応用情報技術者 2013年 秋期 午後 問08

解答の論理構成

• 下線部の文章は、 「(1) 更改前は全てHTTPでアクセスさせるようになっていたWebサイトを、①暗号化されていないデータがそのままインターネット上に流れては問題がある部分では、HTTPSでアクセスさせるようにする。」
  と記述されています。ここで「暗号化されていないデータがそのままインターネット上に流れては問題がある部分」とは、漏えいすると利用者に直接被害が及ぶ機密データを指すと読み取れます。
• 直前の段落には、 「会員専用サイトでは、ユーザIDとパスワードでユーザを認証し」
  とあり、認証に利用する情報が具体的に示されています。
• 認証に用いる情報は盗聴されると「なりすまし」につながるため、HTTP（平文）ではなくHTTPS（暗号化）で守る必要があります。
• 以上より、暗号化されずに流れては問題となるデータは「ユーザID」「パスワード」であると論理的に導けます。

誤りやすいポイント

• 「会員専用サイト＝機密ページ」と短絡し、ページ全体を答えてしまう。設問は“データ”を二つと指定しているため不正解になります。
• 「製品情報」や「技術情報」も重要そうに見えますが、漏えいしてもユーザ個人を特定したり不正ログインを許すものではないため、下線①の文脈では対象外です。
• 「Cookie」「セッションID」なども暗号化すべきですが、問題文に明示されていない語句を書くと、指定された“本文中の字句”の条件に抵触します。

FAQ

解答の論理構成

1. (1) の目的
   • 【問題文】には「①暗号化されていないデータがそのままインターネット上に流れては問題がある部分では、HTTPSでアクセスさせる」とあります。
   • HTTPS は通信内容を暗号化して盗聴を防止する技術です。
   • セキュリティ担当課長が挙げた四つの脅威のうち、暗号化で直接対策できるのは「認証情報の盗聴」です。
   • よって (1) に対応する脅威は「認証情報の盗聴」→ 解答群「エ」。
2. (2) の目的
   • 【問題文】「更改前はDMZに配置し、インターネットから直接アクセスさせていたWebサーバを、インターネットから直接アクセスできない内部のLANに移設する」。
   • 直接攻撃されにくい内部LANへ移し、DMZ にはロードバランサとリバースプロキシのみを置く構成は、Webサーバに対する改ざん行為を防ぐ典型的な手段です。
   • よって (2) に対応する脅威は「Webサイトの改ざん」→ 解答群「イ」。
3. (3) の目的
   • 【問題文】「リバースプロキシサーバには、WAF（WebApplication Firewall）の機能をもたせ、ブラックリスト…」とあります。
   • WAF のブラックリストは、【問題文】「Webアプリケーションの脆弱性を悪用した攻撃の特徴的なパターン」を検査します。代表的な攻撃が「SQLインジェクション」「クロスサイトスクリプティング」です。
   • よって (3) に対応する脅威は両方を含む「SQLインジェクション及びクロスサイトスクリプティング」→ 解答群「オ」。
4. 以上をまとめると
   • (1) → エ
   • (2) → イ
   • (3) → オ

誤りやすいポイント

• 「HTTPS＝盗聴防止」だけでなく、SQLインジェクションの対策と混同する受験者が多いです。暗号化は入力内容の妥当性チェックには無関係です。
• DMZ に置く機器＝安全、内部LAN＝危険と逆に覚えてしまい、「改ざん対策」を (3) と誤答するケースがあります。
• WAF が万能と思い込み「認証情報の盗聴」まで防げると考え、(3) を「キ」とする誤答も散見されます。

FAQ

解答の論理構成

1. 【問題文】には「HTTPSを使って通信するためには、aを取得する必要がある。」とあります。HTTPS で Web サーバを公開する際に必要なのは、サーバ証明書です。したがって
   → a は「イ：SSLサーバ証明書」。
2. 続いて【問題文】「証明書署名要求には、識別名とcが含まれており、認証局から取得したaを機器に導入する際には、cとペアを成すdが必要になる。」
   • CSR（Certificate Signing Request）には公開鍵が含まれます。
   • 公開鍵とペアになるのは秘密鍵です。
   よって
   → c は「オ：公開鍵」、d は「カ：秘密鍵」。
3. 公開鍵暗号方式では、 公開鍵（誰でも取得可）＋秘密鍵（サーバ内で厳重保管）
   でペアを構成し、証明書はその公開鍵に認証局の電子署名を付与したものです。問題文の説明と一致します。

誤りやすいポイント

• 「SSLルート証明書」と混同する
  ルート証明書はクライアント側にあらかじめインポートされており、サーバが取得するものではありません。
• 公開鍵と秘密鍵の役割逆転
  CSR 生成時に秘密鍵は装置内に残り、公開鍵だけが申請される点を忘れがちです。
• 「SSLクライアント証明書」を選択する誤答
  クライアント証明書はユーザ認証用であり、サーバ公開用ではないため HTTPS 必要条件とは異なります。

FAQ

解答の論理構成

1. 【問題文】では、識別名を構成する6項目の一つとして
   「コモンネーム（SSL接続するサイトのFQDN）」が示されています。
2. さらに同じ段落で
   「SSL通信を行うWebサイトのURLを“https://www.a.co.jp/member/”とし、識別名を表1のように決定した。」
   と明記されています。
3. FQDN（Fully Qualified Domain Name）は URL のホスト名部分のみを指すため、 “https://” や “/member/” といったプロトコル・パス情報は除外します。
4. 以上より、コモンネームには URL のホスト名である「www.a.co.jp」を設定するのが適切です。

誤りやすいポイント

• URL 全体 “https://www.a.co.jp/member/” をそのままコモンネームに入れてしまう
• “https://” や “/member/” を削り忘れ、証明書検証エラーの原因を作る
• 企業名 “A Japan K.K.” と混同して組織名をコモンネームに誤入力する

FAQ

解答の論理構成

1. 【問題文】には「ロードバランサは、ユーザからのHTTP/HTTPSリクエストを、Cookieの情報を基にWebアプリケーションのセッションを維持するようにリバースプロキシサーバに振り分ける。」とある。
2. Cookie は HTTP ヘッダ部に含まれ、HTTPS で到着した場合は暗号化されている。ロードバランサが Cookie を読めるようにするには、HTTPS をいったん復号する必要がある。
3. 復号にはサーバ証明書（〔　a　〕）と秘密鍵のペアが必須である。【問題文】後段でも「aとdを機器に導入し、HTTPSでのアクセスが可能になるよう設定した。」と述べている。
4. したがって、〔　a　〕を導入すべき DMZ 内機器は「ロードバランサ」となり、理由は「Cookie の情報を参照する必要があるから」である。

誤りやすいポイント

• リバースプロキシが WAF 機能を持つため「証明書もここに置く」と早合点しやすい。だが Cookie を使ったセッション維持はロードバランサで実施する。
• 「HTTPS を終端する＝DMZ 最前段」と思い込み、ファイアウォールを選ぶミス。ファイアウォールは L4 が主で Cookie を扱わない。
• 「ロードバランサは L4 だから秘密鍵を置かない」と決め付けるケース。実際には L7 対応ロードバランサも多く、問題文はその前提。

FAQ

解答の論理構成

1. 事象の確認
   図2のダイアログには
   ・「“セキュリティの警告”ダイアログボックス」
   ・「このサイトのセキュリティ証明書は、有効期間に問題があります。」
   が表示されています。警告の原因は証明書の有効期限切れなど、期限に関する不備であると読み取れます。
2. 証明書の役割
   【問題文】では、HTTPS利用のために「aを取得する必要がある。」と説明され、さらに「認証局から取得したaを機器に導入」して運用を開始したと述べています。ここでのaは公開鍵証明書（SSLサーバ証明書）です。
3. 有効期間に起因するエラー
   証明書には開始日と終了日が含まれ、期限が切れるとブラウザは「不正なセキュリティ証明書」とみなし、引用部のような警告を出します。
4. 管理者の対応
   有効期限の問題を解決する唯一の根本策は、認証局から新しい証明書を再取得し、サーバに再配置することです。したがって適切な対応は「SSLサーバ証明書を更新する。」となります。

誤りやすいポイント

• ブラウザやPC側の設定変更で回避しようと考える
  → 根本原因はサーバ証明書の期限切れなのでクライアント設定では解決しません。
• 中間証明書の再配置やチェーン設定ミスと混同する
  → 今回は「有効期間に問題」が明示されておりチェーン不備ではありません。
• 証明書の再発行と秘密鍵生成を忘れる
  → 新証明書は旧秘密鍵とペアになるか、必要に応じ再生成・再設定が必要です。

FAQ