ネットワークスペシャリスト 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のメールソフトでのメール送信はできなくなります。」とあり、この「設定変更の内容」を具体的に15字以内で述べることが求められています。
2. PCがどの経路で送信するかを確認する
   本文には「PCでのメールの送受信には、内部メールサーバとの間でSMTPとPOP3を利用している。」とあります。ここから、PCのメールソフトによる送信は内部メールサーバのSMTP機能を使って行われていることがわかります。したがって、PCのメールソフトからの送信を不能にするには、内部メールサーバ側でSMTPを受け付けないようにするのが直接的な方法です。
3. MXレコード変更との関係を整理する
   T課長の発言「移行手順(c)の後、インターネットからのメールはASPサーバに保存されるわけだな。」が示すように、DNSのMXレコード変更はインターネット側から自社宛てに届くメールの配送先（受信側）を決めます。しかし、クライアント（社員のPC）がどのサーバへ送信するかは各PCのメールソフトの設定（送信サーバの指定）や送信リレー設定で決まるため、MX変更だけではPCからの送信先は変わりません。よって、PCの送信を止めたい場合は内部メールサーバ自身の設定を変更してSMTP受信を止める必要があります。
4. 以上より導かれる具体的な設定変更
   内部メールサーバのSMTP受信を止めれば、PCのメールソフトは内部メールサーバへ送信できなくなります。具体的には内部メールサーバのSMTP機能を停止しますので、対応すべき具体的な変更は「SMTPの機能を停止する。」です。

誤りやすいポイント

• MXレコードの変更だけで社内PCからの送信もASPに切り替わると誤解する。MXは受信（MTA→MTA）ルールであり、クライアント送信は別の設定で決まります。
• POP3を無効にすれば送信が止まると思う誤り。POP3は受信（受信箱取得）プロトコルで送信には関係ありません。
• 「SMTP機能を停止する」を、単にFWで外向けのTCP/25を閉じることで代替できると考える誤り。社内PCが内部メールサーバへ送る場合はFW遮断だけでは防げないため、サーバ側での停止が必要です。
• SUBMISSION(587)や認証付きSMTPなど、別ポート／別サービスを見落として停止対象にしないと送信が残る可能性がある点。
• SMTP停止とメールデータの移行を混同する誤り。送信停止は送受信の制御であり、既存メールデータの移行はIMAP/IMAPS等で別途実施する必要があります。

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