情報処理安全確保支援士 2012年 春期 午後2 問01
インターネット向けサーバの災害対策に関する次の記述を読んで、設問1~5に答えよ。
A社は、従業員数3,000名の医薬品卸売会社である。東京に本社があり、大阪に関西地域本社がある。支社は、東京と大阪を含めた7都市にある。12か所に物流センタ(以下、LCという)を置き、60か所に営業所を置く。本社には、企画部、人事総務部、財務部及び情報システム部がある。関西地域本社には、営業本部、物流本部、人事総務部分室及び情報システム部分室がある。各支社には、営業部及び物流部がある。
〔A社の情報システムの概要〕
A社の情報システムには、営業システム、物流システム、人事総務システム及び財務システムに加えて、電子メール(以下、メールという)サーバ、プロキシサーバなどで構成されているインターネット接続システム(以下、Iシステムという)がある。営業システム及び物流システムは関西LCに設置されている。人事総務システム、財務システム及びIシステムは関東LCに設置されている。営業システムは、社外の電子取引システム(以下、M-EDIという)と連携している。
営業システム、物流システム、人事総務システム及び財務システムのサービス提供時間は、営業日の8~20時である。営業日は、年末年始を除く平日である。Iシステム及び社内ネットワーク設備のサービス提供時間は、24時間365日であるが、日曜日は保守のため停止することがある。
全ての従業員に1台ずつPCを貸与している。事業所からのPCの持出しは禁止されているが、従業員がA社の他の事業所へ出張している時、出張先で他の従業員のPCを借用して情報システムを利用することができる。
A社では、災害対策を目的として、情報システムの再構築を行ったばかりである。情報システムの再構築では、12か所あるLCのうち関東LC及び関西LCを重要拠点と位置付け、自家発電設備を導入した。災害時でも注文受付と物流が続けられるよう、営業システムの災害時用のバックアップとして営業DRシステムを、物流システムの災害時用のバックアップとして物流DRシステムを、それぞれ関東LCに設置した。平常時、営業システムと営業DRシステムとのデータの同期及び物流システムと物流DRシステムとのデータの同期を行うことにした。さらに、M-EDIが使用できない場合は、メールで注文受付を行うことにし、それらを踏まえた災害時の注文受付運用手順を作成した。
〔情報システムの構成〕
A社では、DNSサーバ、公開Webサーバなどの運用に、ISPのB社が提供するデータセンタ(以下、B社DCという)を利用している。B社DC及びA社のネットワーク構成を図1に、Iシステムの機器と概要を表1に、B社DCの機器と概要を表2に示す。



各ファイアウォールでは、通信の許可と拒否の状況をログとして記録している。各サーバでは、サーバへのアクセス及びプログラムの動作の状況をログとして記録している。
〔情報システムの運用〕
関東LCの機器の運用は情報システム部が行っている。関西LCの機器の運用は、情報システム部分室が行っている。両LCとも機器の起動、停止及び設定変更は、遠隔操作で行っている。設定変更時には機器のセキュリティに関する設定を行うこともあるので、遠隔操作には通信の暗号化が必要であり、TELNETやFTPではなくbを用いている。
〔地震発生とその影響〕
情報システムの再構築から半年後、月曜日の午前中に関東地方で強い地震が発生した。A社では、関東地区の一部の営業所と関東LCが被害を受け、業務遂行に支障が出た。直ちに、本社に災害対策本部を設置し、被害を受けた営業所と関東LCの復旧を行った。復旧のめどがついた1か月後、A社の経営会議は、今回の地震で起きた災害対策の問題点をまとめることを決めた。その決定を受けて、人事総務部長は、社内各部門に災害復旧対応と地震発生時の状況をヒアリングするよう、担当部員に指示した。担当部員がヒアリングした結果を図2に示す。

人事総務部長は、災害対策本部長及び全社の部長を集め、図2のヒアリング結果を報告し、対応策を検討した。議論の結果、次のとおりとなった。
・災害時、メールによる注文受付に切り替えても、停電が長時間になると営業業務と物流業務は継続できない可能性がある。それぞれの業務を継続するために、翌営業日の午前8時までにIシステムを稼働できるようにする。
・Xウイルスのような、災害情報提供に見せかけた添付ファイル付きメールによって広まるウイルスへの対処が必要なので、Xウイルスに関する対処の経過と、そこから得られる知見をまとめる。
人事総務部長は、Xウイルスに関する対処の経過の報告を情報システム部のD部長に依頼するとともに、ヒアリング結果とそれに関する災害対策本部長及び全社の部長との議論の結果を経営会議で報告した。経営会議において、M-EDI 使用不能時の代替としてのIシステムの重要性が認識された。
〔Xウイルスに関する対処の経過〕
D部長は、情報セキュリティ担当のE主任とFさんに、Xウイルスに関する対処の経過をまとめるように指示した。E主任とFさんは、図3に示すXウイルスに関する対処の経過をD部長に報告した。

D部長は、内部メールサーバのフルスキャンでXウイルスが検出されたメールボックスから利用者を調べれば、万が一ウイルスに感染したPCがあったとしても、それをより早く特定して、対処を完了できるのではないかと指摘した。E主任は、D部長が指摘した調査方法では、②Webメールの性質上、ウイルスに感染したPCを特定できないことを説明した。D部長はXウイルスに関する対処の経過を確認し、人事総務部長に伝えた。
〔I-DR システムの導入に関する検討〕
その後、経営会議において、関西 LC に I システムの災害時用のバックアップとして I-DR システムを導入することが決定された。I-DR システムの構築は情報システム部が担当することになり、D部長は、E主任に要件の検討を指示した。
〔I-DR システムに関する要件の検討〕
I-DR システムに関する要件の検討は、E主任と Fさん、情報システム部分室の G主任から成る検討チームが行うことになった。業務の継続性の観点から、I-DR システムに関する要件を図4の(案)のように整理した。

検討チームは、I-DR システムに関する要件(案)を D部長に報告し、承認を得た。続いて検討チームは、図4を基に、図5に示す B社 DC 及び I-DR システムを含む A社のネットワーク構成(案)、並びに表3に示す I-DR システムの機器と概要(案)を作成した。


〔I-DRシステムの方式設計〕
Fさんが、I-DR システムの方式設計を行うことになった。まず、図6のI-DR システムのメールに関する方式設計(案)ができたので検討チームでレビューを行った。

レビューの結果、③DNS の設定変更の直後は、外部メール DR サーバからインターネット上のメールサーバに転送したメールが SPF によって迷惑メールと判定される可能性があることが分かった。検討の結果、A社のドメイン名のメールを送信することが許可されるサーバとしてdとeのIPv4 アドレスをTXTレコードに登録しておけば、切替時にはTXTレコードの設定変更が不要であることが分かり、図6の方式設計を修正した。
次に、Fさんは、DR-FW-A、プロキシ DR サーバ、社内 WebDR サーバ及び PC 管理 DR サーバの方式設計を行い、レビューを行って問題がないことを確認した。
B社 DC については、サービス管理Webサーバの使用に当たって、事前に B社に依頼しておくべき事項があることが分かり、I-DR システム構築時にその依頼を行うことになった。
〔災害時の情報提供と情報収集の手段の確保〕
次に、公開Webサーバについて、災害時の情報提供のあり方を検討した。地震発生当日及び翌日の公開Webサーバのログを分析したところ、ページの構成を工夫することで、アクセス量が平常時の5倍程度になっても応答が遅くならないようにできることが分かった。そこで、災害時に公開WebサーバのWebページに盛り込む内容を見直すことにした。
続いて、④災害時は、情報収集の手段としてインターネット上のWebサーバへのアクセスを認めるが、図2の状況が発生しないように、プロキシサーバ及びプロキシDRサーバの機能を用いて対応することに決まった。
D部長と人事総務部長は、以上のように検討した内容をI-DRシステム導入(案)として経営会議に報告し、承認を得た。
〔Iシステム及びI-DRシステムの災害対応訓練の実施〕
情報システム部は、I-DRシステム構築が完了した1か月後の日曜日に、訓練として、I-DRシステムへの切替え、I-DRシステムの運用及びIシステムへの切戻しを行った。訓練の実施後、情報システム部は反省会を開いた。反省会において、外部メールDRサーバの起動後、メールの転送を開始するまでの間にセキュリティ確保のために実施すべき事項が図6以外にもあることが分かり、切替手順を修正することにした。
検討チームは、Iシステムの復旧まで3か月という想定で、復旧手順を検討した。検討の結果、Iシステムの復旧において、Iシステムの機器に関する情報セキュリティ対策として行うべき事項があることが分かり、復旧手順に盛り込んだ。
それから更に1か月後の日曜日に、修正した復旧手順に基づいてび訓練を行い。問題がないことを確認した。
その翌月の経営会議では、災害対策への習熟度を高めることを目的に、訓練を年2回実施することにし、必要に応じて、切替手順、切戻手順及び復旧手順の見直しを行うことが決まった。
設問1:
表2中のa、本文中のbに入れる適切な字句をそれぞれ英字で答えよ。
模範解答
a:「HTTP over SSL」または「SSL」
b:SSH
解説
解答の論理構成
- まず a について
- 【問題文】には「サービス管理WebサーバとPCのブラウザの間は暗号化のためにa通信を使用している。」とあります。
- ブラウザと Web サーバ間の暗号化手段として一般的に用いられるのは SSL/TLS で保護された HTTP、つまり “HTTP over SSL” です。よって a には “HTTP over SSL”(略して “SSL” でも可)が入ります。
- 次に b について
- 【問題文】には「遠隔操作には通信の暗号化が必要であり、TELNETやFTPではなくbを用いている。」とあります。
- 暗号化された遠隔操作プロトコルの代表は SSH(Secure Shell)です。TELNET や FTP が平文通信であるのに対し、SSH は暗号化と認証を同時に提供するため、b は “SSH” となります。
- 以上より
- a:HTTP over SSL(または SSL)
- b:SSH
誤りやすいポイント
- a に “HTTPS” と記載してしまうケース
“HTTPS” も実質同義ですが、設問は「英字で答えよ」とだけ指定しており、模範解答は “HTTP over SSL” または “SSL” です。答えの表記に注意しましょう。 - b に “SFTP” を入れてしまうケース
SFTP は SSH 上で動作するファイル転送ですが、遠隔操作全般を表すプロトコルではありません。設問は TELNET の代替としてのリモートログインを指しているため “SSH” が正答です。
FAQ
Q: “HTTPS” と “HTTP over SSL” は違うのですか?
A: 実装的には同じですが、本問の模範解答は “HTTP over SSL” または “SSL” です。設問の指示に合わせて記載しましょう。
A: 実装的には同じですが、本問の模範解答は “HTTP over SSL” または “SSL” です。設問の指示に合わせて記載しましょう。
Q: SSH のポート番号は覚える必要がありますか?
A: 実務でも試験でも TCP 22 番を押さえておくと、ファイアウォール設定問題で役立ちます。
A: 実務でも試験でも TCP 22 番を押さえておくと、ファイアウォール設定問題で役立ちます。
Q: TELNET や FTP を避ける理由は何ですか?
A: どちらも平文で ID/パスワードが流れるため盗聴リスクがあります。SSH は通信内容を暗号化し、公開鍵認証も使えるため安全です。
A: どちらも平文で ID/パスワードが流れるため盗聴リスクがあります。SSH は通信内容を暗号化し、公開鍵認証も使えるため安全です。
関連キーワード: HTTPS, SSH, 暗号化通信、リモート管理、SSL/TLS
設問2:〔Xウイルスに関する対処の経過〕について、(1)〜(4)に答えよ。
(1)図3中cに入れる適切なサーバ名を図1中の字句を用いて答えよ。
模範解答
c:プロキシサーバ
解説
解答の論理構成
-
図3の記述
“FW-Aとcのログを調査したところ、Xウイルスの活動がなかったことが確認できた。”
― ここで調査対象となるcは、PC がインターネット上の “特定Webサーバ” と通信した形跡を把握できる装置でなければなりません。 -
PC が外部 Web サーバと通信する経路
〔情報システムの構成〕の表1には
“プロキシサーバ:『PCからインターネット上のWebサーバへのアクセスを中継する。…通信の中継時…ログを記録』”
とあります。社内 PC は直接インターネットへ出ず、必ず “プロキシサーバ” を経由します。 -
ログに求められる内容
Xウイルスは “ブラウザの設定情報を使うこともある” とされており、HTTP/HTTPS で外部の “特定Webサーバ” へアクセスする可能性が高いです。したがって、アクセスを中継し URL・宛先 IP を記録している “プロキシサーバ” のログを確認するのが適切です。 -
結論
上記 1〜3 から、FW-A と対になる c は “プロキシサーバ” となります。
誤りやすいポイント
- 「C-DNSサーバ」のログと混同する
DNS 問い合わせの有無だけでは HTTP 通信の詳細を追えず、不正アクセスの有無を確定できません。 - “外部メールサーバ” を選んでしまう
メール転送のログは SMTP/POP/IMAP が中心であり、ブラウザ経由の Web 通信監視には不向きです。 - FW-A のみで十分と考える
ファイアウォールでは通過パケットのヘッダ情報しか残らず、URL などアプリケーション層の情報は得られません。
FAQ
Q: プロキシサーバのログには具体的にどのような情報が残りますか?
A: アクセス日時、ユーザID、要求 URL、宛先 IP、バイト数、レスポンスコードなどの詳細が記録されるため、ウイルスが接続を試みた “特定Webサーバ” を特定できます。
A: アクセス日時、ユーザID、要求 URL、宛先 IP、バイト数、レスポンスコードなどの詳細が記録されるため、ウイルスが接続を試みた “特定Webサーバ” を特定できます。
Q: FW-A のログを調べる意味はありますか?
A: あります。FW-A は通信の許可・拒否結果を残すので、プロキシを経由しない異常通信やポートスキャンの有無を確認できます。プロキシログと突き合わせることで漏れのない調査が可能です。
A: あります。FW-A は通信の許可・拒否結果を残すので、プロキシを経由しない異常通信やポートスキャンの有無を確認できます。プロキシログと突き合わせることで漏れのない調査が可能です。
Q: プロキシサーバにキャッシュ機能がありますが、ウイルス検知と関係しますか?
A: 直接の検知には関係しませんが、キャッシュに感染ファイルが保存されていないかの確認や、アクセス頻度分析による感染兆候の発見に役立ちます。
A: 直接の検知には関係しませんが、キャッシュに感染ファイルが保存されていないかの確認や、アクセス頻度分析による感染兆候の発見に役立ちます。
関連キーワード: ファイアウォール、プロキシ、ログ分析、マルウェア、HTTP通信
設問2:〔Xウイルスに関する対処の経過〕について、(1)〜(4)に答えよ。
(2)Xウイルスの活動がなかったことを確認するには、FW-Aで何を調べればよいか。35字以内で述べよ。
模範解答
PC及びプロキシサーバから特定Webサーバへの通信がないこと
解説
解答の論理構成
- Xウイルスが感染すると、ウイルス本体が「攻撃者が用意した複数の特定のWebサーバ(以下、特定Webサーバという)と通信を行う。」(図3)と明記されています。したがって、これら外部サイトへのアクセス有無が活動指標です。
- Iシステムの境界には「FW-A」があり、「通信の許可と拒否の状況をログとして記録している。」(問題文)ため、PCやプロキシサーバが外部へ出る通信は必ずFW-Aを通過し、ログに残ります。
- Xウイルスはブラウザ設定を利用する可能性も示されており、「・特定Webサーバとの通信の際、ブラウザの設定情報を使うこともある。」(図3)とあるため、PCが直接/間接的(プロキシ経由)の両方を考慮する必要があります。
- 以上より、FW-Aのログで「PC及びプロキシサーバから特定Webサーバへの通信」が無いことを確認できれば、ウイルスの外部通信活動は発生していないと判断できます。
誤りやすいポイント
- 内部メールサーバのログだけを調べれば十分と誤解しやすい。メール受信は感染契機に過ぎず、活動確認には外部通信の有無を見る必要があります。
- プロキシサーバ経由の通信だけを対象にし、PCからの直接通信(設定変更や例外設定による)を見落とすケース。FW-Aログなら両方を一括で確認できます。
- 「特定Webサーバ」と一致する通信をドメイン名で検索するだけで済ませるミス。DNSキャッシュやIP直接指定の通信を考慮し、IPアドレスでも検索すべきです。
FAQ
Q: プロキシサーバのログだけでは不十分ですか?
A: はい。不正なプログラムがプロキシをバイパスして直接外部と通信する可能性があるため、ネットワーク境界に位置するFW-Aのログ確認が不可欠です。
A: はい。不正なプログラムがプロキシをバイパスして直接外部と通信する可能性があるため、ネットワーク境界に位置するFW-Aのログ確認が不可欠です。
Q: 特定WebサーバのIPアドレスが変わっていた場合はどう判断しますか?
A: まずベンダ情報で最新のIPアドレスリストを確認し、FW-Aログをそのリストで検索します。未知の変化を想定する場合は不審な宛先やパターンも併せて調査します。
A: まずベンダ情報で最新のIPアドレスリストを確認し、FW-Aログをそのリストで検索します。未知の変化を想定する場合は不審な宛先やパターンも併せて調査します。
Q: DNS問合せの有無では判定できませんか?
A: DNSキャッシュやIP直指定で通信するケースがあるため、DNSログだけでは検知漏れの恐れがあります。実際のHTTP/HTTPSなどの送信先IPをFW-Aログで確認する方が確実です。
A: DNSキャッシュやIP直指定で通信するケースがあるため、DNSログだけでは検知漏れの恐れがあります。実際のHTTP/HTTPSなどの送信先IPをFW-Aログで確認する方が確実です。
関連キーワード: ファイアウォールログ、アウトバウンド通信、トラフィック解析、ウイルス検知、DNS
設問2:〔Xウイルスに関する対処の経過〕について、(1)〜(4)に答えよ。
(3)図3中の下線①のように、フルスキャンを実施したかどうかを確認できないPCがあった。PCがどのような状態にある場合に確認できないのか。その状態を二つ挙げ、それぞれ20字以内で具体的に述べよ。
模範解答
・電源が入っていない状態
・LANに接続していない状態
解説
解答の論理構成
- PC 管理サーバは、表1で「PCの起動後に自動的に実施されるフルスキャンの結果、並びにPCのウイルス対策ソフトがウイルス検出時に送信する情報の管理を行う。」と説明されている。
- したがって、フルスキャン結果を受信・記録できる前提は、(a)PC が起動している、(b)ネットワーク経由で PC 管理サーバへ到達できる、の二つである。
- 図3では「PC管理サーバのログを調査したところ、①フルスキャンの実施を確認できないPCが複数台あった」と記載されており、これは上記前提が満たされなかった PC が存在したことを示す。
- 具体的に前提が崩れる典型的な状態は、
・PC の電源が入っておらず起動していない
・LAN から外れており PC 管理サーバへ通信できない - よって、解答は「電源が入っていない状態」「LAN に接続していない状態」となる。
誤りやすいポイント
- “ウイルス定義ファイルが古い”など、スキャン実行可否とは無関係の要因を挙げる。
- “フルスキャンをスケジュール外で実行した”など、結果は送信されるため確認は可能である点を見落とす。
- PC 管理サーバ側のログ障害を想定してしまい、クライアント側要因であることを外す。
FAQ
Q: スキャン結果が届かない場合、PC 管理サーバ側の障害は考えなくてよいのですか?
A: 図3で問題になっているのは「複数台」のみであり、サーバ全体の障害なら全台で確認不可になります。よってクライアント側要因と判断します。
A: 図3で問題になっているのは「複数台」のみであり、サーバ全体の障害なら全台で確認不可になります。よってクライアント側要因と判断します。
Q: LAN に接続していても VPN や FW の設定で届かないケースは?
A: FW-A のログ調査で「Xウイルスの活動がなかったことが確認できた」とあり、通常通信は通っている前提なので、追加の通信遮断は想定しません。
A: FW-A のログ調査で「Xウイルスの活動がなかったことが確認できた」とあり、通常通信は通っている前提なので、追加の通信遮断は想定しません。
Q: 電源が入っていない PC にはどのように再依頼すれば良いですか?
A: 図3にあるように「そのPCの利用者に実施を再度依頼」し、利用者が起動後フルスキャンを実行する運用とします。
A: 図3にあるように「そのPCの利用者に実施を再度依頼」し、利用者が起動後フルスキャンを実行する運用とします。
関連キーワード: ウイルススキャン、クライアント管理、ネットワーク接続、ログ管理、遠隔監視
設問2:〔Xウイルスに関する対処の経過〕について、(1)〜(4)に答えよ。
(4)本文中の下線②について、従業員がどのようにWebメールを使用した場合、PCを特定できないか。30字以内で述べよ。
模範解答
他の従業員のPCを借用し、Webメールを使用した場合
解説
解答の論理構成
- 問題文には、全従業員に PC が貸与されているものの、
「従業員がA社の他の事業所へ出張している時、出張先で他の従業員のPCを借用して情報システムを利用することができる。」
と明記されています。 - Webメールはブラウザを介して利用するため、クライアント側にメールデータを残さず、ログイン ID とパスワードさえ一致すればどの PC からでも同じメールボックスにアクセスできます。
- したがって、A さんが B さんの PC で添付ファイルを開いてウイルスに感染しても、メールボックスの所有者は A さんですが、感染した端末は B さんの PC という食い違いが発生します。
- 本文の下線部「②Webメールの性質上、ウイルスに感染したPCを特定できない」理由は、利用者 ID と実際の PC が 1 対 1 で対応していない点にあります。
- 以上より、PC を特定できないケースは「他の従業員のPCを借用し、Webメールを使用した場合」と結論づけられます。
誤りやすいポイント
- ログイン ID と PC が常に一致すると決めつけてしまう。
- メールボックス所有者=感染端末の所有者と短絡的に考える。
- Webメールでもキャッシュが端末に残るから追跡可能と思い込む。
- 端末管理番号や MAC アドレスで容易に逆引きできると誤解し、貸与運用ルールを見落とす。
FAQ
Q: メールソフト(POP/IMAP)運用なら特定は容易ですか?
A: クライアントソフトの設定が PC に残るため、貸与 PC を突き止めやすくなります。今回はブラウザ利用の Webメールなので痕跡が乏しい点が問題です。
A: クライアントソフトの設定が PC に残るため、貸与 PC を突き止めやすくなります。今回はブラウザ利用の Webメールなので痕跡が乏しい点が問題です。
Q: PC 交換を禁止すれば解決しますか?
A: 出張時の業務継続を考慮した現行ルールの利便性があるため、完全禁止は現実的ではありません。端末貸出簿の整備やアクセスログの詳細記録など、運用で補う対策が望まれます。
A: 出張時の業務継続を考慮した現行ルールの利便性があるため、完全禁止は現実的ではありません。端末貸出簿の整備やアクセスログの詳細記録など、運用で補う対策が望まれます。
Q: Webメール利用でも端末を特定する技術的手段は?
A: Web プロキシや DHCP サーバで接続元 IP、MAC、時刻を突き合わせる方法がありますが、貸借が頻繁だと結び付けが複雑になり、完全な保証は困難です。
A: Web プロキシや DHCP サーバで接続元 IP、MAC、時刻を突き合わせる方法がありますが、貸借が頻繁だと結び付けが複雑になり、完全な保証は困難です。
関連キーワード: Webメール、ログ管理、クライアント特定、端末貸与運用、ウイルス感染源追跡
設問3:〔I-DRシステムの方式設計〕について、(1)〜(3)に答えよ。
(1)本文中のd、eに入れる適切なサーバ名をそれぞれ図5中の字句を用いて答えよ(dとeは順不同)。
模範解答
d:外部メールサーバ
e:外部メールDRサーバ
解説
解答の論理構成
-
SPF では「そのドメインのメールを送信してよい MTA の IPv4 アドレス」を TXT レコードで宣言します。
【問題文】では、 “③DNS の設定変更の直後は、外部メール DR サーバからインターネット上のメールサーバに転送したメールが SPF によって迷惑メールと判定される可能性がある”
と指摘しています。 -
これに対し検討チームは、 “A 社のドメイン名のメールを送信することが許可されるサーバとしてdとeのIPv4 アドレスをTXT レコードに登録しておけば、切替時にはTXT レコードの設定変更が不要”
と判断しました。
つまり、平常時と DR 時の両方で “送信元となり得るメールサーバ” の IP をあらかじめ SPF に登録しておく、という方針です。 -
図5の機器名称を見ると、I システム側には “外部メールサーバ”、I-DR システム側には “外部メールDRサーバ” が配置されています。
この 2 台こそが切替前後で送信元となるサーバであり、TXT レコードに列挙すべき対象です。 -
したがって、 d:外部メールサーバ
e:外部メールDRサーバ
が正答となります(順不同指定)。
誤りやすいポイント
- 「内部メールサーバ/内部メールDRサーバ」を SPF 登録対象と誤解する
→ SPF は外向き SMTP(MTA) の IP を宣言する仕組みであり、社内利用者がアクセスする内部メールサーバは対象外です。 - “プロキシサーバ” など他の DMZ 機器を候補に入れてしまう
→ SPF に関係するのはメール転送を行う MTA のみです。 - 図6の手順に引きずられて「DNS 切替後に DR-MTA の IP を追加登録」と考える
→ 手順書の改善ポイントは “最初から両方登録しておく” ことでした。
FAQ
Q: SPF に複数 IP を登録すると、なぜ切替時の TXT レコード変更が不要になるのですか?
A: 送信元となる全 MTA の IPv4 アドレスがあらかじめ TXT レコードに含まれていれば、平常時も DR 時も既存レコードで SPF 認証をパスできるからです。
A: 送信元となる全 MTA の IPv4 アドレスがあらかじめ TXT レコードに含まれていれば、平常時も DR 時も既存レコードで SPF 認証をパスできるからです。
Q: 内部メールサーバがウイルス検出後に外部へ送信する場合も SPF で保護されますか?
A: 内部メールサーバ自体は外部 SMTP 送信を行わず、外部メールサーバ(または DR 版)が中継するため、登録対象は外部メールサーバ群のみで問題ありません。
A: 内部メールサーバ自体は外部 SMTP 送信を行わず、外部メールサーバ(または DR 版)が中継するため、登録対象は外部メールサーバ群のみで問題ありません。
Q: DNS キャッシュの残存によるメール遅延は解決しますか?
A: MX レコードは切替時に変更しますが、TXT レコードは共通なので SPF 失敗は防止できます。メール遅延は TTL 設定を短くする運用で緩和します。
A: MX レコードは切替時に変更しますが、TXT レコードは共通なので SPF 失敗は防止できます。メール遅延は TTL 設定を短くする運用で緩和します。
関連キーワード: SPF, TXTレコード、DRサイト、メールリレー、DNSキャッシュ
設問3:〔I-DRシステムの方式設計〕について、(1)〜(3)に答えよ。
(2)本文中の下線③について、インターネット上のメールサーバが外部メールDRサーバから転送されたメールをSPFによって迷惑メールと判定する条件を40字以内で述べよ。
模範解答
参照するDNSサーバのキャッシュに切替前の情報が保持されている。
解説
解答の論理構成
- SPF 判定の基本
- SPF はメールを受信したサーバが DNS に問い合わせ、送信元ドメインの TXT レコードに記載された 送信許可 IP アドレス と実際の送信元 IP を照合します。
- 切替時の手順とリスク
- 本文では「I-DR システムへの切替えは、DNS サーバの設定情報のうち、MXレコード及びTXTレコードをI-DRシステム用に設定することで行う」とあります。つまり切替え直後は TXT レコード(SPF 情報)が更新されます。
- しかし下線③には「DNS の設定変更の直後は、外部メール DR サーバからインターネット上のメールサーバに転送したメールが SPF によって迷惑メールと判定される可能性」と記述されています。
- 迷惑メール判定が生じる理由
- 多くの DNS キャッシュサーバは TTL 期間中、既に取得したレコードを保持します。
- 切替え直後、受信側の DNS キャッシュに 切替え前の TXT レコード が残っている場合、新たに送信してくる 外部メールDRサーバ の IP アドレスは SPF 許可範囲に含まれません。
- これが「迷惑メールと判定される可能性」の原因であり、本設問はその条件を問うています。
以上より、解答は
参照するDNSサーバのキャッシュに切替前の情報が保持されている。
参照するDNSサーバのキャッシュに切替前の情報が保持されている。
誤りやすいポイント
- MX レコードが更新されれば十分と考え、TXT レコード(SPF)を見落とす。
- 送信側(A 社)ではなく受信側の DNS キャッシュに問題がある点を取り違える。
- SPF 失敗の原因を「外部メールDRサーバの逆引き未設定」などと誤解する。
- TTL の概念を忘れ、DNS 変更が即時全世界に反映されると思い込む。
FAQ
Q: MX と TXT を同時に変更しても SPF エラーが起こるのはなぜですか?
A: 受信側が既に取得している TXT レコードを TTL 期間中キャッシュし続けるため、最新の送信許可 IP が反映されない場合があるからです。
A: 受信側が既に取得している TXT レコードを TTL 期間中キャッシュし続けるため、最新の送信許可 IP が反映されない場合があるからです。
Q: 切替え直後の SPF 問題を完全に避ける方法はありますか?
A: 本文のように「dとeのIPv4 アドレスをTXT レコードに登録しておく」など、平常時から両サーバの IP を SPF に含め、切替え時に TXT の変更を不要にする方法が効果的です。
A: 本文のように「dとeのIPv4 アドレスをTXT レコードに登録しておく」など、平常時から両サーバの IP を SPF に含め、切替え時に TXT の変更を不要にする方法が効果的です。
Q: TTL を短く設定すれば十分ではありませんか?
A: 効果はありますが、すべてのキャッシュサーバが即座に再問い合わせする保証はなく、ゼロにはできません。平常時に両方の IP を登録する方が確実です。
A: 効果はありますが、すべてのキャッシュサーバが即座に再問い合わせする保証はなく、ゼロにはできません。平常時に両方の IP を登録する方が確実です。
関連キーワード: SPF, DNSキャッシュ、TTL, MXレコード、フェールオーバー
設問3:〔I-DRシステムの方式設計〕について、(1)〜(3)に答えよ。
(3)サービス管理Webサーバの使用に当たり、B社に依頼しておくべき事項を50字以内で述べよ。
模範解答
プロキシDRサーバからサービス管理Webサーバへの通信を許可するようにFW-Iの設定を追加する。
解説
解答の論理構成
- 前提確認
- 表2でサービス管理Webサーバについて、送信元は「プロキシサーバ」に限定されていると明記されています。
引用:
「FW-1のフィルタリングルールの設定によって、送信元はプロキシサーバに限定している。」
- 表2でサービス管理Webサーバについて、送信元は「プロキシサーバ」に限定されていると明記されています。
- I-DRシステムへの切替え時の変化
- 図5では関西LC内に「プロキシDRサーバ」が配置されていますが、関東LCの「プロキシサーバ」は利用停止となる想定です。
- 切替え後にDNSや公開Webサーバの設定変更を行うためには、担当者がサービス管理Webサーバへアクセスする必要があります。
- アクセス元不一致による問題点
- サービス管理Webサーバ側のファイアウォール(図5では「FW-I」)は、従来の「プロキシサーバ」のIPv4アドレスしか許可していません。
- 切替え後は「プロキシDRサーバ」経由でアクセスするため、このままでは通信が拒否されます。
- 依頼内容の導出
- よって、B社に対し「プロキシDRサーバ」からの通信を許可するフィルタリングルールを追加するよう依頼する必要があります。
- これによりI-DRシステム運用時でもDNS設定変更やコンテンツ更新が滞りなく行えます。
誤りやすいポイント
- 「FW-A」や「DR-FW-A」に設定を追加すると誤解する。実際にサービス管理Webサーバを保護しているのはB社DC側のファイアウォールです。
- 「プロキシDRサーバ」ではなく担当者PCのIPv4アドレスを許可すると考える。表2にあるとおり送信元はプロキシ系サーバで統一されています。
- 暗号化方式(a通信)の設定変更と混同する。本問はアクセス元制限の緩和が論点です。
FAQ
Q: FW-IとFW-1は同じ機器ですか?
A: 図5では名称が「FW-I」に変更されていますが、B社DCで外部と内部を分離している同一のファイアウォールを指しています。
A: 図5では名称が「FW-I」に変更されていますが、B社DCで外部と内部を分離している同一のファイアウォールを指しています。
Q: DRサイトに切替えてもサービス管理Webサーバは変更不要ですか?
A: サーバ自体の設定は不要ですが、保護するファイアウォールに「プロキシDRサーバ」の通信を許可する設定追加が必要です。
A: サーバ自体の設定は不要ですが、保護するファイアウォールに「プロキシDRサーバ」の通信を許可する設定追加が必要です。
Q: 暗号化方式(a通信)の設定も依頼すべきですか?
A: 暗号化方式は既に設定済みであり、切替え時に変更は不要です。必要なのはアクセス元IPの許可です。
A: 暗号化方式は既に設定済みであり、切替え時に変更は不要です。必要なのはアクセス元IPの許可です。
関連キーワード: アクセス制御、ファイアウォール、災害復旧、DRサイト、プロキシサーバ
設問4:〔災害時の情報提供と情報収集の手段の確保〕について、(1)、(2)に答えよ。
(1)災害時の情報提供について、公開WebサーバのWebページに盛り込む内容を見直した結果について、25字以内で具体的に述べよ。
模範解答
画像情報を最小限にし、文字主体にする。
解説
解答の論理構成
- 図2の分析結果では、地震当日「公開Webサーバへのアクセス数が平常時の5倍程度となり、応答が遅くなった」とあります。すなわち、ページ重量がネットワーク輻輳に拍車を掛けたことが示唆されます。
- その後、「ページの構成を工夫することで、アクセス量が平常時の5倍程度になっても応答が遅くならないようにできることが分かった」と記述されています。ここで言う“工夫”は、転送量の大きい要素(画像・動画など)の削減を指すと推測できます。
- そして「公開WebサーバのWebページに盛り込む内容を見直すことにした」とあるため、求められる具体策は“軽量化”の中身です。
- 以上より、重い画像を抑えてテキスト中心にする構成が最適解となり、解答は「画像情報を最小限にし、文字主体にする。」となります。
誤りやすいポイント
- 「アクセス数が5倍」という数字に注目しすぎ、帯域増強やサーバ増設を解答に盛り込むケース。設問はあくまで“ページに盛り込む内容”の見直しを問うています。
- “動画の削除”だけに言及し、画像を残す回答。図2で輻輳の要因となったコンテンツには「ニュース動画」も含まれますが、災害時のページでは静止画像も十分に負荷要因です。
- “キャッシュ活用”を強調する回答。キャッシュは既に利用しており、それでも輻輳した点を無視しています。
FAQ
Q: 素早く応答させるにはサーバスペック向上も必要では?
A: 問題文はネットワーク負荷が主原因であることを示しており、設問はページ内容の見直しという運用面の対策を限定的に問うています。
A: 問題文はネットワーク負荷が主原因であることを示しており、設問はページ内容の見直しという運用面の対策を限定的に問うています。
Q: 画像を完全に排除しなければいけませんか?
A: 設問は“最小限”とする趣旨であり、必要不可欠な小さなアイコンなどまで絶対禁止という意味ではありません。
A: 設問は“最小限”とする趣旨であり、必要不可欠な小さなアイコンなどまで絶対禁止という意味ではありません。
Q: 動画をリンクだけにする案は適切?
A: 転送量を抑えるという点では妥当ですが、リンク先が同一サーバの場合は効果が薄いため、まずは画像・動画そのものを極力削らなければ根本対策になりません。
A: 転送量を抑えるという点では妥当ですが、リンク先が同一サーバの場合は効果が薄いため、まずは画像・動画そのものを極力削らなければ根本対策になりません。
関連キーワード: Webパフォーマンス、コンテンツ最適化、帯域輻輳、キャッシュ制御、災害時BCP
設問4:〔災害時の情報提供と情報収集の手段の確保〕について、(1)、(2)に答えよ。
(2)本文中の下線④について、プロキシサーバ及びプロキシDRサーバにおいて対応した内容を30字以内で述べよ。
模範解答
フィルタリングするファイル種別に動画を追加する。
解説
解答の論理構成
-
問題文の下線④
「④災害時は、情報収集の手段としてインターネット上のWebサーバへのアクセスを認めるが、図2の状況が発生しないように、プロキシサーバ及びプロキシDRサーバの機能を用いて対応」とあります。
ここで求められているのは“図2の状況”──災害時に発生した通信輻輳──を再発させない施策です。 -
プロキシサーバの機能確認
表1「プロキシサーバ」には次の記述があります。
・「コンテンツフィルタリング機能:通信の中継において、フィルタリングを行う。」
・「…フィルタリングするファイル種別の追加及び削除…を行い、設定パターンとして保存することができる。」
災害時専用の“設定パターン”を用意すれば、業務に不要な大容量ファイルを遮断できます。 -
輻輳の主因の推定
図2の詳細説明は引用できませんが、災害時に従業員がニュース動画など大容量コンテンツを閲覧し、回線使用率が飽和したことは本文で示唆されています。すなわち動画ファイル (mp4, flv など) が帯域圧迫の主要因です。 -
対策方針の導出
(1) 必要最小限の情報収集(テキスト・画像中心のページ閲覧)は許可。
(2) 帯域を圧迫する動画ファイルだけをブロックすれば、メール配送や業務 Web への影響を抑制できる。 -
具体的設定
以上より、災害モードの“設定パターン”に「動画ファイル種別」を追加し遮断すれば要求を満たします。したがって
フィルタリングするファイル種別に動画を追加する。
という解答になります。
誤りやすいポイント
- Web サーバ単位でのブロックと誤解し、ニュースサイト全体を遮断すると正当なテキスト情報まで取得できなくなる。
- 「キーワード追加」で対応しようとすると動画以外のファイルも誤って遮断する恐れがある。
- DR 側(プロキシDRサーバ)の設定を忘れ、本番切替時に輻輳対策が機能しないまま運用してしまう。
FAQ
Q: 動画を遮断すると本当に帯域問題は解決できますか?
A: 大容量かつストリーミング通信が主因なので、動画を排除するだけで回線使用率は大きく低下し、メール遅延や業務アプリへの影響を抑制できます。
A: 大容量かつストリーミング通信が主因なので、動画を排除するだけで回線使用率は大きく低下し、メール遅延や業務アプリへの影響を抑制できます。
Q: ファイル種別の追加はどのタイミングで行うべきですか?
A: 平常時に災害用“設定パターン”として登録し、切替手順に沿って有効化すると作業ミスを防げます。
A: 平常時に災害用“設定パターン”として登録し、切替手順に沿って有効化すると作業ミスを防げます。
Q: フィルタリング定義ファイルの更新と独自設定は競合しませんか?
A: 定義ファイルはベンダ提供リスト、独自設定は管理者定義リストとして別管理されるため、更新によって独自設定が上書きされることはありません。
A: 定義ファイルはベンダ提供リスト、独自設定は管理者定義リストとして別管理されるため、更新によって独自設定が上書きされることはありません。
関連キーワード: コンテンツフィルタリング、プロキシサーバ、帯域制御、ストリーミング、災害対策
設問5:〔Iシステム及びI-DRシステムの災害対応訓練の実施〕について(1)、(2)に答えよ。
(1)外部メールDRサーバの起動後、メールの転送を開始するまでの間に実施すべきことを、図6以外の事項について、30字以内で述べよ。
模範解答
迷惑メール定義ファイルを最新にする。
解説
解答の論理構成
-
外部メールサーバの平常時仕様
表1の「外部メールサーバ」には
「迷惑メール対策機能:メールの転送時に迷惑メールスキャンを行う。迷惑メール定義ファイルを…1時間ごとにダウンロードし、更新する。」
とあります。迷惑メール定義ファイルが最新でなければ、スキャン精度が低下し迷惑メールを社内に通してしまいます。 -
DR側への機能継承
表3の「外部メールDRサーバ」には
「迷惑メール対策機能及びDNS機能:外部メールサーバと同じ機能をもつ。」
と記載され、同一の迷惑メール対策機能が稼働する想定です。 -
切替手順の不足点
図6では「起動」「メール転送設定確認」「メール転送開始処理」「DNS変更」までしか示されておらず、迷惑メール定義ファイル更新については触れられていません。訓練後の反省会で「図6以外にもあることが分かり、切替手順を修正」とあるため、追加すべき作業は迷惑メール定義ファイルの更新と判断できます。 -
したがって、外部メールDRサーバの起動後からメール転送開始までの間に実施すべきことは
「迷惑メール定義ファイルを最新にする。」
となります。
誤りやすいポイント
- ウイルス定義ファイルと混同しやすい
DR切替時に注目すべきは外部メールDRサーバの“迷惑メール定義ファイル”であり、内部メールDRサーバやPC管理DRサーバのウイルス定義ファイルではありません。 - DNSやSPFの設定変更と誤解する
DNS関連の手順は図6で既に扱われているため、本問の「図6以外」に該当しません。 - 定義ファイル更新を自動任せにしてしまう
平常運用と異なり、DR起動直後は自動更新の開始前に手動で最新化する必要があります。
FAQ
Q: 外部メールDRサーバを起動した直後でも、自動更新を待てばよいのでは?
A: 迷惑メールは大量に到着する可能性があり、初動で防げなければ社内へ流入します。そこで転送開始前に手動で「迷惑メール定義ファイルを最新にする」必要があります。
A: 迷惑メールは大量に到着する可能性があり、初動で防げなければ社内へ流入します。そこで転送開始前に手動で「迷惑メール定義ファイルを最新にする」必要があります。
Q: ウイルス定義ファイルの更新も必要では?
A: 外部メールDRサーバに求められる主機能は迷惑メール対策です。ウイルススキャンは内部メールDRサーバが担うため、本設問の対象外です。
A: 外部メールDRサーバに求められる主機能は迷惑メール対策です。ウイルススキャンは内部メールDRサーバが担うため、本設問の対象外です。
Q: SPF設定を変更しなくてよい理由は?
A: 既に検討段階でdとeのIPv4アドレスをTXTレコードへ登録済みのため、切替時の追加作業は不要と整理されています。
A: 既に検討段階でdとeのIPv4アドレスをTXTレコードへ登録済みのため、切替時の追加作業は不要と整理されています。
関連キーワード: DNS, SPF, 迷惑メール対策、定義ファイル更新、DRサーバ
設問5:〔Iシステム及びI-DRシステムの災害対応訓練の実施〕について(1)、(2)に答えよ。
(2)Iシステムの復旧において、Iシステムの機器に関する情報セキュリティ対策として行うべき事項を55字以内で具体的に述べよ。
模範解答
I-DRシステムの機器だけ行った設定の反映及び最新の修正プログラムの適用を、Iシステムの機器に行う。
解説
解答の論理構成
- 災害時は「I-DRシステム」へ切替え、そこで業務を継続します。要件には「I-DRシステムのセキュリティ運用 ・修正プログラムの適用及び設定変更は、常に最新の状態にする。」とあります。
- ところが「検討チームは、Iシステムの復旧まで3か月という想定で、復旧手順を検討した。」と記載されているように、長期停止した Iシステム側の機器はその間パッチや設定更新が行われません。
- 復旧時に旧システムを無更新のまま再稼働させると、未適用の脆弱性や古い設定が残存し、最新状態となっている I-DR システムとの差分が新たなセキュリティリスクになります。
- したがって復旧手順には、(a) I-DR システムだけで実施していた設定変更を I システム機器に反映し、(b) 停止期間中にリリースされた最新修正プログラムを適用する、という二本立ての対策が必須となります。
- 以上をまとめると模範解答のとおり「I-DRシステムの機器だけ行った設定の反映及び最新の修正プログラムの適用を、Iシステムの機器に行う。」が導かれます。
誤りやすいポイント
- データ同期だけで十分と考え、OSやミドルウェアのパッチを失念する。
- DR 切替え時に行ったセキュリティ設定が自動的に本番へ戻ると誤認する。
- 復旧を急ぐあまりパッチ適用前に本番機を接続し、脆弱性を外部に晒してしまう。
FAQ
Q: I-DR と I システムで同じ自動更新機構を有効にしておけば対策は不要ですか?
A: 停電やネットワーク遮断で I システム機器が長期間オフラインになる可能性があるため、自動更新のみでは不十分です。復旧時に手動で更新状況を確認し、差分を解消する必要があります。
A: 停電やネットワーク遮断で I システム機器が長期間オフラインになる可能性があるため、自動更新のみでは不十分です。復旧時に手動で更新状況を確認し、差分を解消する必要があります。
Q: DR 側で行った設定変更を自動的に本番へ同期するツールの導入は有効ですか?
A: 有効ですが、切替え手順でツール自体の動作確認と、復旧後の最終チェックが欠かせません。ツール不具合や通信断で同期に失敗するケースを想定し、人手による検証工程を残しておくべきです。
A: 有効ですが、切替え手順でツール自体の動作確認と、復旧後の最終チェックが欠かせません。ツール不具合や通信断で同期に失敗するケースを想定し、人手による検証工程を残しておくべきです。
Q: パッチ適用後に再起動が必要な場合、サービス停止時間が長くなりますが回避策は?
A: 復旧作業を休日や深夜に計画し、段階的適用(重要パッチ優先)の手順を整備することで業務影響を最小化できます。
A: 復旧作業を休日や深夜に計画し、段階的適用(重要パッチ優先)の手順を整備することで業務影響を最小化できます。
関連キーワード: パッチ管理、変更管理、災害復旧、セキュリティパッチ、システム切替


