応用情報技術者 2009年 秋期 午後 問05

解答の論理構成

1. 〔案1〕の記述
   引用：「RASサーバへの接続時のユーザ認証は、aやbなどを利用して通信事業者が行う。」
   • 携帯用PCとRASサーバ間のユーザ認証で代表的なのは「CHAP（Challenge Handshake Authentication Protocol）」と「RADIUS（Remote Authentication Dial In User Service）」。
   • CHAPはPPPのリンク確立後にチャレンジ／レスポンス方式でパスワードを秘匿して認証するプロトコル、RADIUSは集中認証サーバの代表格でISPが多用。
   • 選択肢を見ると「ウ：CHAP」「ク：RADIUS」が該当。よって
     a：ウ b：ク（順不同）
2. 〔案2〕の記述
   引用：「SSL-VPN装置は、cが発行したサーバ証明書を携帯用PCに送信して、自らをサーバ認証してもらう。」
   • サーバ証明書を発行する主体は公開鍵基盤の「CA（Certificate Authority）」。
   • 選択肢「イ：CA」が対応。
     c：イ
3. 〔案3〕の記述
   引用：「セキュリティプロトコルには、データの暗号化機能を提供するdを使用する。」
   • IPsecのセキュリティプロトコルは「AH」と「ESP」。
   • 「AH」は認証・改ざん検出のみ、「ESP」は認証に加え暗号化（機密性）を提供する。
   • 「データの暗号化機能を提供する」と明言しているので「ESP」が正解。
   • 選択肢「エ：ESP」。
     d：エ
4. 以上より模範解答と一致
   a：ウ b：ク c：イ d：エ

誤りやすいポイント

• 「RADIUS＝集中認証サーバ」のイメージが強く、PPPレベルの認証と思い込み「CHAP」を落とすケース。
• IPsecの「AH」「ESP」の違いを機密性の有無で整理しておらず、単に“認証ヘッダだから安全”と誤選択。
• 証明書関連用語で「CA」と「RA」を混同し、発行主体を取り違えるミス。
• a・bが「順不同」である点を見落とし、正しい二つを選んでも順序指定があると思い悩む。

FAQ

解答の論理構成

誤りやすいポイント

• SSL＝HTTPSと短絡し、「HTTP以外のアプリケーションの通信プロトコルに対応できない。」（ア）が案2だと思い込む。実際はポートフォワーディングやクライアントソフト併用で多様なプロトコルを通すことが可能です。
• IPsec＝自動的に証明書方式と早合点し、事前共有鍵を軽視する。小規模・モバイル利用では事前共有鍵が現実的な選択肢である点を忘れがちです。
• 通信事業者のRAS＝専用線と勘違いし、インターネット区間の暗号化を見落とす。図に「インターネット」が明示されていることを必ず確認しましょう。

FAQ

解答の論理構成

1. 本文には次の記載があります。
   ・「社内LANでは、DHCPサーバが割り当てるローカルIPアドレスを使用している。」
   この一文から、T社社内では「DHCPサーバ」により「ローカルIPアドレス」が払い出されていることが分かります。
2. 課題説明の該当箇所を確認します。
   「例えば、携帯用PCが、出張先のホテルにあるeから、動的にfを取得する場合、T社ネットワーク内でfが重複してしまい、リモートアクセスができなくなるおそれがある。」
3. 「ホテルで動的にアドレスを取得する」典型的な仕組みは「DHCPサーバ」です。したがってeには「DHCPサーバ」が入ります。
4. 次にfについて、動的に取得し重複が問題になるものは「ローカルIPアドレス」です。本文にも同じ語が登場しているため、fは「ローカルIPアドレス」と判断できます。
5. 以上より、 ・e：DHCPサーバ
   ・f：ローカルIPアドレス
   が妥当です。

誤りやすいポイント

• 「出張先のホテル」という文脈から、e を「アクセスポイント」や「Wi-Fiルータ」と読み替えてしまうことがありますが、動的アドレス払い出しの主体を問われている点に注意が必要です。
• 社内でもホテルでも同じ語「ローカルIPアドレス」が使われているため、f を「グローバルIPアドレス」と誤解するケースがあります。VPN の内部通信ではローカルアドレスが衝突することが問題になる点を意識しましょう。
• 「動的に取得する」というキーワードから PPP 接続時の「IP アドレスネゴシエーション」を連想し、e を「RASサーバ」と混同するミスも見受けられます。設問はホテル側の設備を想定しています。

FAQ

解答の論理構成

1. 課題の整理
   〔案3の課題〕では、 「携帯用PCが、出張先のホテルにあるeから、動的にfを取得する場合、T社ネットワーク内でfが重複してしまい、リモートアクセスができなくなるおそれ」
   とあるように、ホテル側のDHCPが配るローカルアドレスが、社内LANで使っているローカルアドレスと衝突してしまう点が問題です。
2. なぜ重複が発生するのか
   ・リモートアクセス時、IPsecのトンネルモードでは「IPヘッダとデータ部をまとめて暗号化」するため、クライアント側も社内と同じアドレス体系に“入る”必要があります。
   ・ところがホテルのDHCPから既にプライベートアドレス（例：192.168.0.10 など）を借りていると、そのまま社内と同じ帯域と見なされ、経路があいまいになります。
3. 恒久的対策の要件
   ・社外で取得したアドレスと社内アドレスの“重複”を根本的に回避する。
   ・携帯用PC側の運用を変えずに済む（ホテルやカフェの機器設定は変えられない）。
   ・VPN接続時だけ安全・一意なアドレスを確保できればよい。
4. 候補の検証
   ア：本社DHCPサーバからIPsec専用のIPアドレスを携帯用PCに割り当てる。
   　　→ VPN確立後に“社内専用かつユニーク”なアドレスを再配布できるため重複が生じない。
   イ：本社FWの通信ポート443番の通信を許可する。
   　　→ SSL-VPN の話であり、IPアドレス重複とは無関係。
   ウ：本社と営業所の通信ポート番号の体系を変更する。
   　　→ ポート番号とIPアドレス重複は別問題。
   エ：本社と営業所のローカルIPアドレスの体系を変更する。
   　　→ 重複は“ホテルなど”の不特定アドレスとぶつかるので、社内だけ変えても再び衝突する可能性がある。恒久策にならない。
   オ：本社プロキシサーバのNAPT機能を解除する。
   　　→ NAPTは既に「対処できている」と明記されており、今回の課題とは別件。
5. 結論
   重複を確実に避けるには、VPN接続時に「本社DHCPサーバ」から専用範囲のアドレスを再配布する方法が最も合理的であり、解答群「ア」が妥当です。

誤りやすいポイント

• 「エ」を選び、社内のアドレス体系を変えれば済むと考えてしまう。実際は外部ネットワークが無数にあり、いずれまた衝突する可能性が残るため恒久策にならない。
• NAPT問題と勘違いして「オ」を選ぶケース。本文に「NAPTの利用に関連して発生することのある問題には対処できている」と明示されている点を見落としやすい。
• ポート番号（イ・ウ）とIPアドレスの混同。ポートは“同一IP内での識別子”であり、アドレス重複には効果がない。

FAQ