ネットワークスペシャリスト 2009年 午後1 問02

解答の論理構成

1. ア の判定
   • 【問題文】「JavaScriptの非同期通信の機能による、画面遷移が起こらない動的なユーザインタフェースを実現する ア と呼ばれる技術」
   • “JavaScript の非同期通信”と“画面遷移が起こらない”から、「Ajax」（Asynchronous JavaScript + XML）であることが分かります。
2. イ の判定
   • 【問題文】表の「クライアントが利用するプロトコル」欄で「(25)」番ポートに対応するものを答える設定。
   • ポート「25」は SMTP（Simple Mail Transfer Protocol）です。
3. ウ の判定
   • 同じ表で「(995)」番ポートに対応する暗号化 POP を示しています。
   • ポート「995」は POP3 over SSL/TLS で、呼称は「POP3S」です。
4. エ の判定
   • 【問題文】「FWのエという機能を利用して、一つのグローバルアドレスを共有し、同時に複数のPCがASPサーバと通信」
   • 一つのグローバル IP を多数の内部端末で共有する NAT の一種＝“NAPT”（Network Address Port Translation）です。
5. オ の判定
   • 【問題文】「HTTPSでは、PCは オ メソッドを利用してプロキシサーバへ接続先を指定し、SSLセッションをASPサーバとの間で確立」
   • HTTP プロキシでトンネルを張るときに使うのは CONNECT メソッドです。

誤りやすいポイント

• Ajax を “AjaX” などと大小文字を混在させると減点対象です。
• ポート「587」を見て SUBMISSION と結び付け、25 を誤って “SUBMIT”などと書くケースが散見されます。
• POP3S は「POPS」と書かれることもありますが、問題は「POP3S」を要求しています。
• NAPT と NAT を混同しやすいですが、設問は「ポート変換も行う」ことを明言しているため NAPT が正解です。
• HTTPS におけるプロキシ接続メソッドを「GET」と誤解してしまうミスが多発します。

FAQ

解答の論理構成

1. 要件確認
   • 企画会議で決定した要件に「『Webメールの利用は社内からの接続に限定する。』」とあります。
   • つまり、社外から直接 ASP サーバへ HTTPS 接続されないようにする必要があります。
2. 社内アクセス経路の整理
   • PC は「『PCからインターネットへのアクセスは、プロキシサーバ経由のHTTPとHTTPSだけを許可している。』」ため、社内 LAN から外部へ出る通信は必ずプロキシサーバを経由します。
3. ASP サーバ側の設定項目の確認
   • 表の「『アクセス設定　接続を許可するクライアントの IP アドレスを設定する。』」という機能は、ASP サーバが受け付ける送信元を IP アドレスで制限できることを示しています。
4. 要件を満たす具体策
   • 社内からの通信はすべてプロキシサーバに集約されるため、ASP サーバに登録すべき IP アドレスはプロキシサーバだけで十分です。
   • これにより、社外や私物端末などプロキシサーバを経由しないアクセスは拒否され、要件を満たします。
5. 文章化
   • 以上から、解答は「アクセス設定でプロキシサーバのIPアドレスだけを許可する。」となります。

誤りやすいポイント

• クライアント PC の IP アドレスを列挙しようとする
  → PC には「固定IPアドレス」が振られてはいますが、直接インターネットへは出られないため無意味です。
• 「プロトコル設定」で HTTPS だけに制限すれば十分と考える
  → HTTPS のみ許可しても送信元 IP を制限しなければ社外からアクセスできます。
• DMZ 内の「外部メールサーバ」を残したまま流用できると勘違いする
  → 移行後は ASP サーバに一元化されるため、外部メールサーバではアクセス制御できません。

FAQ

解答の論理構成

1. まず、R君が確認したいのは「社員が実際に受信しているメールトラフィック量」です。
   【問題文】「R君は、内部メールサーバのログを調査し、メールのトラフィックを確認したところ…」
2. 外部メールサーバは DMZ にあり、役割はインターネットとの送受信です。
   DMZ 側にあるため、社内 LAN 内だけで完結するメールは通過しません。
3. 社員同士のメールは内部メールサーバだけで配送が完了します。
   したがって外部メールサーバのログには「社内から社内あてのメール」が記録されません。
4. 社内メールを含めた全量を把握する目的に合致しないため、外部メールサーバのログは利用しません。
   ⇒ 解答：「社内から社内あてのメールのログが残っていないから」

誤りやすいポイント

• 「外部メールサーバの方がインターネット経由の迷惑メールを多く記録しているはず」と考え、内部トラフィックを見落とす。
• DMZ と社内 LAN の配送経路を混同し、内部メールも必ず外部メールサーバを経由すると誤解する。
• ログ分析対象を「どの利用実態を把握したいのか」に結び付けず、単にログサイズの大小で選択してしまう。

FAQ

解答の論理構成

1. 問題文には、下線①として
   「メールを閲覧するだけでPCがウイルスに感染することを防ぐための対策」
   が必要と明記されています。
2. メール閲覧時に感染を引き起こす代表的な仕組みは、HTMLメールに埋め込まれた JavaScript や ActiveX、iframe などの悪意あるコードです。
3. J社の設定項目には
   「HTML メールの表示機能」
   を有効／無効に切り替える選択肢が表形式で提示されています。
4. よって、この機能を無効に設定すれば、HTMLタグやスクリプトがブラウザで解釈されず、閲覧“するだけ”で感染する経路を遮断できます。
5. 以上より、求められる設定は
   「HTMLメールの表示機能を無効にする。」
   となります。

誤りやすいポイント

• 「添付ファイルの PC へのダウンロード機能を無効」にするだけでは、メール本文に埋め込まれた悪意あるスクリプトを防げません。
• 「ウイルスチェック機能」のみで十分と考えがちですが、未知のマルウェアやゼロデイ攻撃は検知をすり抜ける可能性があります。
• HTMLメールを単に“閲覧しないよう周知する”運用対策では、ユーザの操作ミスを排除できず技術的対策として不十分です。

FAQ

解答の論理構成

1. 問題文には「DNSサーバでX社のドメインの カ レコードの値をASPサーバの キ へ変更」とあります。
2. インターネット上で電子メールを配送する際、どのメールサーバ（Mail eXchanger）に届けるかを示すDNSレコードは「MXレコード」です。したがって カ には「MX」が入ります。
3. 「MXレコード」の値には IP アドレスではなくホスト名を書き、これは完全修飾ドメイン名（Fully Qualified Domain Name：FQDN）で指定するのがDNSのルールです。よって キ には「FQDN」が入ります。
4. 以上より、
   ・カ＝「MX」
   ・キ＝「FQDN」
   となります。

誤りやすいポイント

• 「A レコード」と誤答するケース
  A レコードはホスト名と IP アドレスを対応付けるためのもので、メール配送ルートを示す用途ではありません。
• 「CNAME」や「PTR」と混同
  CNAME は別名定義、PTR は逆引き用です。メール配送の指定には関与しません。
• 「MXレコードの値を IP アドレスにする」誤解
  MX は必ずホスト名（FQDN）で指定し、後続の A レコード解決で IP アドレスに変換されます。

FAQ

解答の論理構成

1. 【問題文】には「PCでのメールの送受信には、内部メールサーバとの間でSMTPとPOP3を利用している。」とあります。したがって、PC のメールソフトが内部メールサーバへメールを送信するプロトコルは「SMTP」です。
2. さらに会話文で T 課長は「内部メールサーバにも新規のメールが保存され続けてしまう可能性があるが、何か防ぐ方法はないだろうか。」と問い掛けています。
3. これに対し R 君は「②内部メールサーバの設定を変更すれば、PCのメールソフトでのメール送信はできなくなります。」と回答しています。「メール送信ができなくなる＝SMTP を使えなくする」ことを示唆しています。
4. よって内部メールサーバ側で行う設定変更は、SMTP サービス（メール送信機能）を停止することです。
5. 以上から、解答は「SMTPの機能を停止する。」となります。

誤りやすいポイント

• POP3 や IMAP の停止と勘違いしやすい
  → 送信を防ぐ目的なので、受信系プロトコルではなく SMTP が対象です。
• 「ポート25を閉じる」とだけ書く
  → 対象サービス名が明確でないと減点リスクがあります。
• ファイアウォール設定と混同
  → 会話中の②は「内部メールサーバの設定」であり、FW ではありません。

FAQ

解答の論理構成

1. 移行前のメールクライアント設定
   • 【問題文】には「PCでのメールの送受信には、内部メールサーバとの間でSMTPとPOP3を利用している。」とあり、受信プロトコルは POP3、受信サーバは内部メールサーバでした。
2. IMAPS 非対応という制約
   • 「PCのメールソフトがIMAPSには対応していないことが判明」したため、PC から ASP サーバへ暗号化通信するには「プロキシサーバに、IMAPとIMAPSを相互に変換するSSLゲートウェイ機能」を追加して回避する方針になりました。
3. PC 側で必要となる設定変更
   • 受信プロトコル：SSLゲートウェイへ平文で渡すため「IMAP」に切り替える。
   • 受信サーバ　　：ゲートウェイを置いた「プロキシサーバ」を指定する。
   • これらが移行手順(e)「PCのメールソフトの設定変更」で求められる二つの要素です。
4. よって解答
   ① 受信プロトコルをIMAPにする
   ② 受信サーバをプロキシサーバにする

誤りやすいポイント

• 送信側（SMTP/SUBMISSION）の設定変更を書いてしまう。設問は「設定変更の内容を二つ挙げ」としか書いていないが、段取り上、受信設定の変更が要件を満たします。
• 「IMAPSにする」と答えるミス。IMAPS は PC が非対応であることが【問題文】に明示されています。
• 内部メールサーバのアドレス指定を残したままにする誤答。ゲートウェイを通さなければ暗号化できません。

FAQ

解答の論理構成

• 【問題文】には、メールデータのアップロードを行う (f) の作業が「IMAPやIMAPSを利用」して行われると記されています。
  引用：「IMAPやIMAPSを利用すればASPサーバにメールデータをアップロードできる」
• さらに、T課長は「割り当てられた作業期間以外はアップロード作業ができないような対策」を求めています。
  引用：「割り当てられた作業期間以外はアップロード作業ができないような対策はないのか」
• R君はその対策を「③FWの設定で対応」すると回答しています。
  引用：「R君：③FWの設定で対応したいと思います」
• つまり、FW で IMAP 系ポートへの通信を「誰が・いつ」行えるかを制御すれば、指定期間外のアップロードを遮断できます。
• PC は全台「固定IPアドレスを割り当てている」ため、社員やグループ単位の識別は送信元 IP で行えます。
  引用：「PCには固定IPアドレスを割り当てている」
• 以上より、解答は
  「作業期間ごとにIMAPを利用できる送信元IPアドレスを制限する。」
  となります。FW のアクセス制御リストで IMAP(143)／IMAPS(993) ポートを期間別・IP 別に許可するイメージです。

誤りやすいポイント

• HTTP/HTTPS の制御と混同し、メールアップロードも「HTTPS 制限」と答えてしまう。
• 「宛先 IP」だけを制限すると考え、送信元側の識別（固定 IP）を忘れる。
• IMAPS だけを対象にして IMAP(143) を漏らすパターン。
• 時間帯制御を FW ではなく DNS やプロキシで実施できると誤解する。

FAQ