情報処理安全確保支援士 2011年 春期 午後2 問01

解答の論理構成

1. a の役割
   • 【問題文】図2(1) に「SMTPを使用し、メールを転送する」とあります。さらに PC からの送信経路 (3)(a) で「社内メールサーバの a にメールを送信する」と記載されています。
   • SMTP でメールを中継・転送するプログラムは一般に MTA（Mail Transfer Agent）であるため、a＝「ウ：MTA（Mail Transfer Agent）」となります。
2. b の役割
   • 図2(2) に「メールボックス保存プログラムである b によって…保存される」とあります。
   • 受信したメールを各ユーザのメールボックスへ配達・保存するのは MDA（Mail Delivery Agent）の機能です。したがって b＝「ア：MDA（Mail Delivery Agent）」です。
3. c の役割
   • 図2(3) の説明で「PCの c は、SMTPで25番ポートを使用し…」「PCの c は、SMTPで587番ポートを使用し…」とあります。さらに受信側でも POP3 でメールを取り出す主体として登場します。
   • PC 上でユーザが操作するメール送受信ソフトは MUA（Mail User Agent）なので、c＝「エ：MUA（Mail User Agent）」になります。
4. d の役割
   • 図2(3)(b) では「社内メールサーバの d にメールを送信し、d は、a にメールを転送する」とあります。
   • SMTP 587番ポートで受け付け、後段の MTA へ引き渡すのは MSA（Mail Submission Agent）の役割です。よって d＝「イ：MSA（Mail Submission Agent）」となります。

誤りやすいポイント

• MSA と MTA の混同
  • どちらも SMTP を使いますが、MSA は「クライアントからの初期受け付け」、MTA は「サーバ間中継」です。587番ポートと25番ポートの違いに着目しましょう。
• MDA と POP3 サーバの取り違え
  • MDA は保存までを担当し、ユーザが取り出す際に動くのは MRA（POP/IMAP サーバ）。図2に POP3 の説明があるため混同に注意。
• MUA の位置付け
  • 問題文では「PCの c」とだけ書かれており、MUA と明示していません。ユーザインタフェースを持つアプリケーション＝MUA と判断できるかがポイントです。

FAQ

解答の論理構成

1. メール送信の可否は、サーバ側のオープンリレー対策で判断されます。問題文には
   “オープンリレー対策では、表3に示すように、SMTPの転送元のIPアドレス…とメールの受信者ドメイン名の二つの組合せで、転送の許可又は拒否を判定する。”
   とあります。
2. 判定に使われるのは
   ・転送元IPアドレス
   ・受信者ドメイン名
   のみであり、送信者メールアドレス（エンベロープの送信者側）は含まれていません。
3. さらに “社内メールサーバの許可アドレスリストには、PCネットワークのIPアドレスブロックが登録されている。” ため、社内PCからの送信は許可対象です。
4. したがって PC 側で送信者メールアドレスを誤設定しても、サーバは判定材料にしていないため拒否しません。

誤りやすいポイント

• 送信者メールアドレス（From/MAIL FROM）が認証要素だと思い込む。
• SPF設定やSMTP-AUTHの有無と混同し、「正しい送信者でなければ拒否される」と誤解する。
• 受信者ドメイン名＝MLや社外宛のみが判定対象と考え、社内宛でも拒否されると思い込む。

FAQ

解答の論理構成

1. まず DHCP サーバのログで「SさんのPCに割り当てたIPアドレスを特定した」とあります。よって、確認対象は“IPアドレス”と“送信者メールアドレス”を同時に記録しているメールサーバのログです。
2. 図2の送信経路において「PCの c は、SMTPで25番ポートを使用し、社内メールサーバの a にメールを送信する」と記述されています。PC から最初に到達するメールサーバは「社内メールサーバ」であることが分かります。
3. 「社内メールサーバ」には MTA ログが残り、送信元 IP アドレス・エンベロープ From を含むため、「SさんのPCのIPアドレスから送信者メールアドレスがAさん用であるメールが送信された」事実を確認できます。
4. したがって、①で参照したサーバは「社内メールサーバ」、確認内容は「SさんのPCが Aさんのメールアドレスを使って送信したこと」と導かれます。

誤りやすいポイント

• 外部送信用なので「外部メール中継サーバ」と考えてしまうが、PC から直接接続するのは「社内メールサーバ」です。
• ログに着目せずメールヘッダ情報だけで判断しようとしてしまう。
• 送信者アドレスの誤設定という事象から“受信者側ログ”を探してしまい、対応する IP アドレスとの紐付けが取れなくなる。

FAQ

解答の論理構成

1. 調査対象の行動を確認
   図6の(3)には、下線②として
   “同IPアドレスからのリクエストで、ウイルス定義ファイルのダウンロードが行われた”
   と記録されています。
   したがって「ウイルス定義ファイルのダウンロード」を受け付けたサーバのログを確認したことになります。
2. ウイルス定義ファイルのダウンロード経路を特定
   図2(4)には
   “プロキシサーバ経由で、インターネット上のウイルス対策ソフトベンダのWebサーバに未更新ウイルス定義ファイルがあるかを確認し、未更新ウイルス定義ファイルがある場合はダウンロードを行い、更新を行う。”
   とあり、ダウンロード要求は必ず“プロキシサーバ経由”で外部に出ていることが分かります。
3. ログを保有するサーバを確定
   図1のDMZに配置されている“プロキシサーバ”は、社内からインターネットへのWebアクセスを中継し、アクセスログを保持します。
   よって、ウイルス定義ファイル取得リクエストを識別できるのは“プロキシサーバ”のログです。
4. 以上より、下線②の調査に用いたサーバは
   “プロキシサーバ”
   となります。

誤りやすいポイント

• 「社内メールサーバ」を選ぶ誤答
  ウイルス定義の自動更新は社内メールサーバ自身も行いますが、外部との通信は図2(4)のとおり“プロキシサーバ経由”なので、直接ログは残りません。
• 「DNS サーバ」「外部メール中継サーバ」を連想する誤答
  どちらもDMZにありますが、ウイルス定義ファイルのHTTPダウンロードとは無関係です。
• “ウイルス対策ソフトベンダのWebサーバ”と書いてしまう
  図1中の機器名ではなくインターネット上の外部サイトであるため設問条件に不適合です。

FAQ

解答の論理構成

1. 下線部③では、 “③PCでの対策以外に、メールシステムのサーバでの対策もあると助言した”
   とあり、U氏はサーバ側で追加できるウイルス対策を示唆しています。
2. 図2の説明には、 “MRAのメール取り出し中に、ウイルス対策ソフトのウイルススキャン（以下、POP3スキャンという）を行うことも可能である。…しかし、PCのウイルス対策ソフトに同等機能があるのでPOP3スキャンを使用していない。”
   と記載されています。
3. Bさんの事例では、PC側で“メール受信スキャン機能を使用しない設定”に変更していたために、受信時にXウイルスを検知できませんでした。
4. 以上より、サーバ側で未使用の“POP3スキャン”を有効にすれば、PC側設定の有無にかかわらず受信時にウイルスを遮断できます。
5. したがって、U氏の助言は
   「社内メールサーバへのPOP3スキャナを使用する。」
   となります。

誤りやすいポイント

• SMTPスキャンとPOP3スキャンを混同し、既に実施済みの対策と誤認してしまう。
• PC側のウイルス定義ファイル更新強化だけで十分と考え、サーバ側の受信時検査の必要性を見逃す。
• “POP before SMTP”など別機能を連想し、回答をずらしてしまう。

FAQ

解答の論理構成

1. 目的の把握
   本文には「④メールアドレスのドメイン名の使用方法も含めてMLサーバの設定を見直すとともに、社内Webサーバでの許可済ドメイン名の設定ルールとして明示する案を作成した」とあります。つまり、 ・社外メンバ登録ML用ドメイン名の扱い
   ・あて先確認要求機能で利用する許可済ドメイン名のルール
   の両方を再設計する必要があります。
2. あて先確認要求機能の仕様確認
   「現在の許可済ドメイン名は表2のメールアドレスのドメイン名とすることにした」とあるため、p-sha.co.jp と ml01.p-sha.co.jp は確認メッセージなしで送信できます。ところが図7の(A)では「社外メンバ登録MLアドレスあて送信時に、あて先確認要求なしにメールが送信される」と指摘されています。
   ➡ 社外向けMLのドメイン名が許可済ドメイン名に含まれていると、誤送信抑止が効きません。
3. MLサーバ側の対応方針
   社外メンバ登録MLでは従来と異なり外部ドメイン宛ての同報も行います。従来の ml01.p-sha.co.jp と混在させると内部用途と区別できず管理が煩雑になります。
   ➡ 新しい P社サブドメイン名を割り当て、社外メンバ登録ML専用とします。
4. 許可済ドメイン名の設定ルール
   誤送信防止のため、社外メンバ登録ML用のドメイン名は許可済ドメイン名に含めないように規定します。これにより当該MLへ送る際には必ずユーザに確認ダイアログが表示され、誤送信リスクを低減できます。
5. 結論
   ・見直し案：「社外メンバ登録MLのドメイン名として、新たなP社サブドメイン名を使用する。」
   ・設定ルール案：「社外メンバ登録MLのドメイン名を許可済ドメイン名に含めない。」

誤りやすいポイント

• 既存の ml01.p-sha.co.jp をそのまま使い回そうとする
  → 許可済ドメイン名に含まれるため確認ダイアログが出ず誤送信リスクが残ります。
• 設定ルールを「除外する」とせず「別枠で管理する」とだけ書く
  → 明確に「許可済ドメイン名に含めない」と示さないと運用ルールが曖昧になります。
• 新ドメイン名を「社外ドメインにする」と誤解する
  → あくまで P社が管理するサブドメインでなければ SPF 設定や運用統制に支障が出ます。

FAQ

解答の論理構成

1. 前提整理
   • ウイルス検査が行われるのは「社内メールサーバ」のみである。本文では
     「“社内メールサーバでSMTPスキャンが動作した”」（図6(3)）
     と明示されている。
   • よって、(ⅰ)インターネット→P社サブドメイン宛メール、(ⅱ)MLサーバ→社外宛メールの双方が、必ず社内メールサーバを経由しなければならない。
2. 表7の問題点(B)
   指摘箇所(B)では、現行案の
   ・項番「2」：外部メール中継サーバ → P社サブドメイン名 → 「MLサーバに転送」
   ・項番「11」：MLサーバ → 社外のドメイン名 → 「外部メール中継サーバに転送」
   が直接転送になっており、社内メールサーバを経由しない。
3. 経由させる必要性
   • 「社内メールサーバでSMTPスキャン」(図2(1)) によりウイルス除去とログ取得をする。
   • MLサーバのIPアドレスを「社内メールサーバの許可アドレスリストに追加する」（本文⑤）ことで、オープンリレー対策（表3）にも抵触しない。
     以上より、両経路は「社内メールサーバに転送」と修正するのが筋。
4. よって修正結果
   ① 項番「2」／社内メールサーバに転送
   ② 項番「11」／社内メールサーバに転送

誤りやすいポイント

• 「外部メール中継サーバ→MLサーバ」の直接経路を許すと、“SMTPスキャンをバイパスするためウイルスがすり抜ける”点を見落としやすい。
• MLサーバ→社外のメールを直接外部へ出すと、送信元IPがDMZ側になり「SPF不一致」「オープンリレー対策違反」が起きやすい。
• 許可アドレスリストへMLサーバのIP追加を忘れると、社内メールサーバが転送を拒否してしまう。

FAQ

解答の論理構成

1. 【問題文】には「社内メールサーバの許可アドレスリストには、PCネットワークのIPアドレスブロックが登録されている。」とあり、現状では PC 以外のサーバはリスト外です。
2. ところが図7(B)に対処するために「社内メールサーバの許可アドレスリストにeのIPアドレスを追加する案」と記載されています。
3. 表7の変更案を見ると、MLサーバは
   ・項番9「P社ドメイン名 ➔ 社内メールサーバに転送」
   ・項番1０「P社サブドメイン名 ➔ 同報プログラムに転送」
   ・項番11「社外のドメイン名 ➔ 外部メール中継サーバに転送」
   となり、少なくとも「項番9」で MLサーバ から 社内メールサーバ へ SMTP 転送が発生します。
4. オープンリレー対策（表3）は「許可アドレスリスト以外のアドレス」から「社外のドメイン名」への転送を拒否します。MLサーバが社内メールサーバ経由で社外へ出そうとする場合、MLサーバの IP が許可アドレスリストに入っていないと拒否される恐れがあります。
5. したがって、追加すべき IP は「MLサーバ」のものです。
   以上より、e に入るサーバ名は 「MLサーバ」 となります。

誤りやすいポイント

• 表7を読まずに元の表4の転送経路だけで判断してしまう。変更案では MLサーバ が外部メール中継サーバとも直接通信するため、許可アドレスリストへの追加を忘れがちです。
• 「外部メール中継サーバの IP を追加」と誤答するケース。外部メール中継サーバは既に FW ルール1〜4で通信が許可されており、問題は社内メールサーバ側のオープンリレー判定です。
• 「社内メールサーバ自身の IP」や「PC ネットワークの追加範囲」など、既に登録済みの範囲を重ねて指定してしまう。

FAQ

解答の論理構成

1. 前提条件
   • 図7(C)の指摘は【問題文】の引用「社外メンバ登録MLで同報されたメールがウイルスに感染していた場合に、同報リストに登録された協力会社のメンバに連絡する手段が決められていない。」で示されています。
   • これを受けて「連絡手段をメールとする案」を作成したところ、【問題文】の引用「U氏は、⑥連絡手段をメール以外の方法とするように助言した。」となりました。
2. メール連絡案の弱点
   • ウイルス感染メールが同報されると、受信側ではウイルス対策ソフトやメールサーバのフィルタリングによりメール自体が「隔離・削除・遮断」される可能性があります。
   • その結果、感染を通知するメールも同じ経路を通るため届かなくなる、または遅延する恐れがあります。
3. 助言の理由
   • 連絡を必要とする状況が「メールがウイルス感染源になった場合」なので、同じメール経路に依存するのは不適切です。
   • メール以外――例として【問題文】にある「発信者番号を通知した電話で連絡する案」のように、異なる通信チャネルを確保すれば、メールシステムが停止・隔離状態でも確実に連絡できます。
4. よって、U氏の助言理由は「ウイルス感染でメールが使えなくなるリスクを回避するため」であると論理的に導かれます。

誤りやすいポイント

• 「ウイルスに感染しているメールが送れない」ではなく「感染時に通知メールも届かない」ことが本質である点を見落とす。
• 「SPF」や「迷惑メール判定」と混同して助言理由を誤解する。
• 連絡チャネル冗長化の目的が“情報漏えい”防止ではなく、“感染拡大時の迅速連絡”であることを取り違える。

FAQ

解答の論理構成

1. 協力会社側では「迷惑メールの判定にSPFを使用している」（図7(D)）。
2. SPF は“エンベロープの送信者メールアドレス”のドメインと、実際にメールを配送したサーバ IP の組合せで真偽を判断する仕組みです。
3. 表5によると、ML サーバの現在設定は
   「エンベロープの送信者メールアドレス：同報前のメールのエンベロープの送信者メールアドレス」
   となっており、同報前の元メールが社外発である場合、P社の外部メール中継サーバが SPF で許可されていないドメインを名乗ることになります。
4. その結果、協力会社のメールサーバでは “SPF 不一致” と判断され、「P社からのメールが迷惑メールと判定される」事象が発生します。
5. 表5 にはもう一つの選択肢
   「MLアドレス管理者のメールアドレス」
   が用意されています。これは P社ドメインで SPF 設定済みのアドレスであり、外部メール中継サーバの IP が SPF レコードに含まれているため照合に成功します。
6. よって、対策は“ML サーバが再送出する際にエンベロープの送信者メールアドレスを ML アドレス管理者のメールアドレスへ書き換える”ことです。

誤りやすいポイント

• 「ヘッダ From: の書き換え」で十分と誤解し、エンベロープを変更しない。SPF はヘッダではなく MAIL FROM を検査する点を失念しがちです。
• 「外部メール中継サーバの IP を SPF レコードに追加すれば良い」と考えるが、そもそも元メールのドメインが P社以外の場合は登録できず根本解決になりません。
• DKIM や DMARC の導入へ話を広げ過ぎ、本設問が求める“ML サーバ設定だけで解決”という意図を外してしまう。

FAQ

解答の論理構成

• 【引用①】「PJwebサーバでは、利用者の認証を行い。…アクセス状況をログとして記録する。」
  すでに“認証”と“アクセスログ”は備わっています。
• 【引用②】「⑧これらのほかに…PJWebサーバに必要な情報セキュリティ機能を追加する」
  追加機能は、まだ実装されていない情報漏えい対策に焦点を当てる必要があります。
• 伝送経路での盗聴防止と、プロジェクト外利用者による閲覧を封じる細粒度の“認可”が未整備です。
• 以上を踏まえた【解答例】
  • 「HTTPSで通信を暗号化し盗聴を防止する機能」
  • 「PJごと利用者ごとに閲覧操作権限を制御する機能」
  いずれも既存の認証・ログ・FW制限と補完関係にあり、メール誤送信や添付漏えい時の二次被害も低減できます。

誤りやすいポイント

• 認証やアクセスログは既に実装済みであるのに、重複して解答してしまう。
• 暗号化を“VPN構築”など大がかりな仕組みで答え、PJWebサーバ単体に必要な機能という設問意図を外す。
• “アップロードサイズ制限”など可用性寄りの機能だけを挙げ、情報漏えい防止の観点が抜ける。

FAQ

解答の論理構成

1. ⑨で問われている対象は、本文の「⑨これらのほかに、情報システム部は、PIWebサーバの情報セキュリティ対策にかかわる運用も行う」です。ここで「これら」とは、①プロジェクト開始時・終了時の利用者 ID／領域の登録・削除、②「定期的なpJWebサーバの龍調性機査及び修正プログラムの適用」を指します。
2. したがって運用面で追加すべき事項は「情報漏えい対策」―特にプロジェクト終了後に残存データが放置されるリスク、運用中に不正アクセスが見逃されるリスク―を低減するものになります。
3. プロジェクト終了後にデータやアカウントが残れば「PJWebサーバを不正に利用される」危険があるため、確実な削除確認が必要です。
4. さらに、運用中に攻撃・内部不正が起きても気付かなければ機密が流出します。そこで「アクセスログを定期的に分析」し、異常を早期発見することが重要です。
5. 以上を踏まえ、模範解答のとおり「削除確認」と「ログ分析」を具体的運用として挙げるのが最適解となります。

誤りやすいポイント

• 「修正プログラムの適用」は既に本文中で実施済なので、同じ内容を繰り返すと加点されません。
• 「バックアップ取得」を挙げると可用性対策にはなるものの、問われているのは情報漏えい対策であり論点がずれます。
• ログ「保存」だけを書き、分析・点検を省くと運用として不十分と判断される恐れがあります。

FAQ