ネットワークスペシャリスト 過去問研究 R6（2024年） 午後2 問2
https://www.ipa.go.jp/shiken/mondai-kaiotu/2024r06.html#haru_nw
ネットワークスペシャリスト試験（NW）
 |
ネスペR6 －本物のネットワークスペシャリストになるための最も詳しい過去問解説 左門 至峰, 平田 賀一 技術評論社 2024/11/13 ￥2970 |
※（wikiの仕様により）本サイトでは、下線表現に <u> タグではなく <ins> タグを使用しています。
問2 電子メールを用いた製品サポートに関する次の記述を読んで、設問に答えよ。
Y社は、企業向けにIT製品を販売する会社であり、電子メール（以下、メールという）を使用して、販売した製品のサポートを行っている。
Y社では、取扱製品の増加に伴って、サポート体制の強化が必要になってきた。
そこで、サポート業務の一部を、サポートサービス専門会社のZ社に委託することを決定し、Y社の情報システム部のX主任が、委託時のメールの運用方法を検討することになった。
Y社のネットワーク構成を図1に、外部DNSサーバYが管理するゾーン情報を図2に、社内DNSサーバYが管理するゾーン情報を図3に示す。
図1 Y社のネットワーク構成（抜粋）
図2 外部DNSサーバYが管理するゾーン情報（抜粋）
図3 社内DNSサーバYが管理するゾーン情報（抜粋）
Y社では、サポート契約を締結した顧客企業の担当者（以下、顧客という）からの製品サポート依頼を、社内メールサーバYに設定された問合せ窓口のメールアドレスである、 support@y-sha.com で受け付けている。
このメールアドレスはグループアドレスであり、 support@y-sha.com 宛てのメールは、Y社のサポート担当者のメールアドレスに配信される。
サポート担当者は、送信元メールアドレスが support@y-sha.com にセットされた製品サポートのメール（以下、サポートメールという）を、社内メールサーバYを使用して顧客に返信している。
〔Y社のネットワーク構成とセキュリティ対策の背景〕
Y社のネットワーク構成とメールのなりすまし防止などの情報セキュリティ対策の背景について次に示す。
・サポート担当者が送信したサポートメールが①社内メールサーバYからメール中継サーバに転送されるとき、②DNSラウンドロビンによってメール中継サーバY1又はY2に振り分けられる。
・転送先のメール中継サーバが障害などで応答しないとき、社内メールサーバYは、他方のメール中継サーバ宛てに転送する機能をもつ。
・顧客が送信したサポートメールがメール中継サーバに転送されるときは、外部DNSサーバYに登録されたMXレコードの[ a ]値によって、平常時は、ホスト名が[ b ]のメール中継サーバが選択される。
・FWには、インターネットからDMZのサーバ宛ての通信に対して、静的NATが設定されている。
FWに設定されている静的NATを表1に示す。
表1 FWに設定されている静的NAT（抜粋）
| 宛先のホスト | 宛先IPアドレス | 変換後のIPアドレス |
| y-mail1.y-sha.com | [ ア ] | [ イ ] |
| y-mail2.y-sha.com | 省略 | 省略 |
送信元メールアドレスの詐称の有無に対しては、DNSの[ c ]と呼ばれる名前解決によって、送信元メールサーバのIPアドレスからメールサーバのFQDNを取得し、そのFQDNと送信元メールアドレスのドメイン名が一致した場合、詐称されていないと判定する検査方法が考えられる。
しかし、③攻撃者は、自身が管理するDNSサーバのPTRレコードに不正な情報を登録することができるので、ドメイン名が一致しても詐称されているおそれがあることから、検査方法としては不十分である。
このような背景から、受信側のメールサーバが送信元メールアドレスの詐称の有無を正しく判定できるようにする手法として、送信ドメイン認証が生まれた。
送信ドメイン認証の技術には、送信元IPアドレスを基に、正規のサーバから送られたかどうかを検証するSPF（Sender Policy Framework）や、送られたメールのヘッダーに挿入された電子署名の真正性を検証するDKIM（DomainKeys Identified Mail）などがある。
Y社ではSPF及びDKIMの両方を導入している。
〔Y社が導入しているSPFの概要〕
SPFでは、送信者のなりすましの有無を受信者が検証できるようにするために、送信者のドメインのゾーン情報を管理する権威DNSサーバに、SPFで利用する情報（以下、SPFレコードという）を登録する。
Y社では、外部DNSサーバYにSPFレコードをTXTレコードとして登録している。
Y社が登録しているSPFレコードを図4に示す。
| y-sha.com. IN TXT "v=spf1 +ip4: [ ウ ] +ip4: [ エ ] -all" |
図4 Y社が登録しているSPFレコード
Y社が導入しているSPFによる送信ドメイン認証の流れを次に示す。
（i）サポート担当者は、送信元メールアドレスが support@y-sha.com にセットされたサポートメールを、顧客宛てに送信する。
（ii）サポートメールは、社内メールサーバYからメール中継サーバY1又はY2を経由して、顧客のメールサーバに転送される。
（iii）顧客のメールサーバは、メール中継サーバY1又はY2から、メール転送プロトコルである[ d ]の[ e ]コマンドで指定されたメールアドレスのドメイン名の[ f ]を入手する。
顧客のメールサーバは、DNSを利用して[ f ]ドメインのゾーン情報を管理する外部DNSサーバYに登録されているSPFレコードを取得する。
（iv）顧客のメールサーバは、④取得したSPFレコードに登録された情報を基に、送信元のメールサーバの正当性を検査する。
（v）正当なメールサーバから送信されたメールなので、なりすましメールではないと判断してメールを受信する。
なお、正当でないメールサーバから送信されたメールは、なりすましメールと判断して、受信したメールの隔離又は廃棄などを行う。
〔Y社が導入しているDKIMの概要〕
DKIMは、送信側のメールサーバでメールに電子署名を付与し、受信側のメールサーバで電子署名の真正性を検証することで、送信者のドメイン認証を行う。
電子署名のデータは、メールの[ g ]及び本文を基に生成される。
DKIMでは、送信者のドメインのゾーン情報を管理する権威 DNSサーバを利用して、電子署名の真正性の検証に使用する鍵を公開する。
鍵長は、2,048ビットより大きな鍵を利用することも可能である。
しかし、DNSをトランスポートプロトコルである[ h ]で利用する場合は、DNSメッセージの最大長が[ i ]バイトという制限があるので、[ i ]バイトに収まる鍵長として、一般に2,048ビットの鍵が利用される。
DKIMの電子署名には、第三者認証局（以下、CAという）が発行した電子証明書を利用せずに、各サイトの管理者が生成する鍵が利用できる。
Y社では、Y社のネットワーク運用管理者が生成した鍵などのDKIMで利用する情報（以下、DKIMレコードという）を、外部DNSサーバYにTXTレコードとして登録している。
Y社が登録しているDKIMレコードを図5に、DKIMレコード中のタグの説明を表2に示す。
| sel.ysha._domainkey.y-sha.com. IN TXT "v=DKIM1; k=rsa; t=s; p=（省略）" |
注記 sel.yshaは、y-sha.comで運用するセレクター名を示し、y-sha.com.は、電子署名を行うドメイン名を示す。
図5 Y社が登録しているDKIMレコード
表2 DKIMレコード中のタグの説明（抜粋）
| タグ | 説明 |
| v | バージョン番号を示す。指定する場合は"DKIM1"とする。 |
| k | 電子署名の作成の際に利用する鍵の形式を指定する。 |
| t | DKIMの運用状態が本番運用モードの場合は"s"を指定する。 |
| p | Base64でエンコードした[ オ ]のデータを指定する。 |
DKIMにおける送信側は、電子署名データなどを登録したDKIM-Signatureヘッダーを作成して送信するメールに付加する処理（以下、DKIM処理という）を行う。
DKIMでは、一つのドメイン中に複数のセレクターを設定することができ、セレクターごとに異なる鍵が使用できる。
セレクターは、DNSサーバに登録されたDKIMレコードを識別するためのキーとして利用される。
DKIM-Signatureヘッダー中のタグの説明を表3に示す。
ここで、DKIM-Signatureヘッダーの構成図は省略する。
表3 DKIM-Signatureヘッダー中のタグの説明（抜粋）
| タグ | 説明 |
| b | Base64でエンコードした電子署名データ |
| d | 電子署名を行ったドメイン名 |
| s | 複数のDKIMレコードの中から鍵を取得する際に、検索キーとして利用するセレクター名 |
Y社は、顧客宛てのサポートメールに対するDKIM処理を、メール中継サーバY1及びY2で行っている。
Y社では、ドメイン名がy-sha.comでセレクター名がsel.yshaのセレクターを設定している。
Y社が送信するメールのDKIM-Signatureヘッダー中のsタグには、図5中に示したセレクター名のsel.yshaが登録されている。
Y社が導入しているDKIMによる送信ドメイン認証の流れを次に示す。
（i） サポート担当者は、送信元メールアドレスが support@y-sha.com にセットされたサポートメールを、顧客宛てに送信する。
（ii） サポートメールは、社内メールサーバYからメール中継サーバY1又はY2を経由して、顧客のメールサーバに転送される。
（iii） メール中継サーバY1又はY2は、サポートメールに付加するDKIM-Signatureヘッダー中に電子署名データなどを登録して、顧客のメールサーバに転送する。
（iv） 顧客のメールサーバは、DKIM-Signatureヘッダー中のdタグに登録されたドメイン名であるy-sha.comとsタグに登録されたセレクター名を基に、DNSを利使用して、当該ドメインのゾーン情報を管理する外部DNSサーバYに登録されているDKIMレコードを取得する。
（v） 顧客のメールサーバは、⑤取得したDKIMレコードに登録された情報を基に、電子署名の真正性を検査する。
（vi） 正当なメールサーバから送信されたメールなので、なりすましメールではないと判断してメールを受信する。
なお、正当でないメールサーバから送信されたメールは、なりすましメールと判断して、受信したメールの隔離又は廃棄などを行う。
〔Z社に委託するメールの運用方法の検討〕
まず、X主任は、自社のメールシステムのセキュリティ運用規程に、次の規定があることを確認した。
（あ）社内メールサーバYには、Y社に勤務する従業員以外のメールボックスは設定しないこと
（い）社内のPCによるメール送受信は、社内メールサーバYを介して行うこと
（う）メール中継サーバY1及びY2にはメールボックスは設定せず、社内メールサーバYから社外宛て、及び社外から社内メールサーバY宛てのメールだけを中継すること
（え）Y社のドメインを利用するメールには、なりすまし防止などの情報セキュリティ対策を講じること
次に、メールの運用方法の検討に当たって、X主任は、Z社のネットワーク構成とサポート体制を調査した。
Z社のネットワーク構成を図6に、外部DNSサーバZが管理するゾーン情報を図7に示す。
図6 Z社のネットワーク構成（抜粋）
| z-sha.co.jp. IN MX 10 z-mail1.z-sha.co.jp. |
| z-mail1.z-sha.co.jp. IN A 222.c.d.1 |
注記 222.c.d.1はグローバルIPアドレスである。
図7 外部DNSサーバZが管理するゾーン情報（抜粋）
Z社は、複数の企業から受託したメールを用いたサポート業務を、チームを編成して対応している。
X主任は、Z社のネットワーク構成、サポート体制及びY社のメールシステムのセキュリティ運用規程を基に、Z社に委託するメールによるサポート方法を、次のようにまとめた。
・Z社のサポートチームYのサポート担当者は、現在使用している問合せ窓口のメールアドレス support@y-sha.com でサポート業務を行う。
・ support@y-sha.com 宛てのメール中から、Z社に委託した製品のサポート依頼メール及びサポート途中のメールが抽出されて、Z社のサポートチームYのグループアドレス宛てに転送されるようにする。
・サポートチームYのサポート担当者は、送信元メールアドレスが support@y-sha.com にセットされたサポートメールを、社内メールサーバZを使用してY社の顧客宛てに送信する。
次に、セキュリティ運用規程の（え）に対応するために、Z社に委託するサポートメールへのSPFとDKIMの導入方法を検討した。
SPFには、⑥DNSサーバにSPFで利用する情報を登録することで対応できると考えた。
DKIMには、図6中のメール中継サーバZで、送信元メールアドレスが support@y-sha.com のメールに対してDKIM処理を行うことで対応できると考えた。
このとき、顧客のメールサーバが、外部DNSサーバYを使用してDKIMの検査を行うことができるように、DKIM-Signatureヘッダー中のdタグで指定するドメイン名には[ j ]を登録し、⑦sタグで指定するセレクター名はsel.zshaとして、Y社と異なる鍵を電子署名に利用できるようにする。
また、外部DNSサーバYに、sel.zshaセレクター用のDKIMレコードを追加登録する。
委託時のメールの運用方法がまとまったので、検討結果を上司のW課長に説明したところ、⑧“Z社のサポートチームY以外の部署の従業員が、送信元メールアドレスに support@y-sha.com をセットしてサポート担当者になりすました場合、顧客のメールサーバでは、なりすましを検知できない”、との指摘を受けた。
そこで、X主任は、追加で実施する対策について調査した結果、S/MIME（Secure/MIME）の導入が有効であることが分かった。
〔S/MIMEの調査と実施策〕
S/MIMEでは、受信者のMUA（Mail User Agent）によるメールに付与された電子署名の真正性の検証で、なりすましやメール内容の改ざんが検知できる。
MUAによる電子署名の付与及び電子署名の検証の手順を表4に示す。
表4 MUAによる電子署名の付与及び電子署名の検証の手順
| 処理MUA | 手順 | 処理内容 |
| 送信者のMUA | 1 | ハッシュ関数hによってメール内容のハッシュ値aを生成する。 |
| 2 | ⑨ハッシュ値[ a ]を基に、電子署名データを作成する。 | |
| 3 | 送信者の電子証明書と電子署名付きのメールを送信する。 | |
| 受信者のMUA | 4 | ⑩受信したメール中の電子署名データからハッシュ値aを取り出す。 |
| 5 | ハッシュ関数hによってメール内容のハッシュ値bを生成する。 | |
| 6 | ⑪ハッシュ値を比較する。 |
X主任は、S/MIME導入に当たってY社とZ社が実施すべき事項について検討し、次の四つの実施事項をまとめた。
・Y社のホームページ上で、サポートメールへのS/MIMEの導入をアナウンスし、なりすまし防止対策を強化することを顧客に周知する。
・取得した電子証明書は、Z社にも秘密鍵と併せて提供する。
・Y社のサポート担当者及びZ社のサポートチームYのサポート担当者は、自身のPCに電子証明書と秘密鍵をインストールする。
・Y社及びZ社のサポート担当者は、送信するメールに電子署名を付与する。
X主任は、サポートメールにSPFとDKIMだけでなく新たにS/MIMEも導入したメールの運用方法と、サポート委託を開始するまでにY社及びZ社で実施すべき事項をW課長に報告した。
報告内容が承認されたので、X主任は、委託時のメールの運用を開始するまでの手順書の作成、及びZ社の窓口担当者との調整に取り掛かった。
設問1 〔Y社のネットワーク構成とセキュリティ対策の背景〕について答えよ。
（1）本文中の下線①1について、転送先のメール中継サーバのFQDNを答えよ。
（2）本文中の下線②について、社内メールサーバYからメール中継サーバY1又はY2へのメール転送時に、振分けの偏りを小さくするために実施している方策を、25字以内で答えよ。
（3）本文中の[ a ]～[ c ]に入れる適切な字句を答えよ。
（4）表1中の[ ア ]、[ イ ]に入れる適切なIPアドレスを答えよ。
（5）本文中の下線③について、攻撃者がPTRレコードに対して行う不正な操作の内容を、次に示す図8を参照して45字以内で答えよ。
| ホストのIPアドレス IN PTR ホストのFQDN |
図8 PTRレコードの形式（抜粋）
設問2 〔[Y社が導入しているSPFの概要〕について答えよ。
（1）図4中の[ ウ ]、[ エ ]に入れる適切なIPアドレスを答えよ。
（2）本文中の[ d ]～[ f ]に入れる適切な字句を答えよ。
（3）本文中の下線④について、正当性の確認方法を、50字以内で答えよ。
設問3 〔Y社が導入しているDKIMの概要〕について答えよ。
（1）本文中の[ g ]～[ i ]に入れる適切な字句又は数値を答えよ。
（2）図5のDKIMレコードで指定されている暗号化方式のアルゴリズム名、及び表2中の[ オ ]に入れる適切な鍵名を答えよ。
（3）本文中の下線⑤について、電子署名の真正性の検査によって送信者がなりすまされていないことが分かる理由を50字以内で答えよ。
設問4 〔Z社に委託するメールの運用方法の検討〕について答えよ。
（1）本文中の下線⑥について、登録するDNSサーバ名及びDNSサーバに登録する情報を、それぞれ、図1又は図6中の字句を用いて答えよ。
（2）本文中の[ j ]に入れる適切な字句を答えよ。
（3）本文中の下線⑦について、異なる鍵を利用することによる、Y社におけるセキュリティ面の利点を、50字以内で答えよ。
（4）本文中の下線⑧について、顧客のメールサーバでは、なりすましを検知できない理由を、40字以内で答えよ。
設問5 〔S/MIMEの調査と実施策〕について答えよ。
（1）表4中の下線⑨の電子署名データの作成方法を、25字以内で答えよ。
（2）表4中の下線⑩のハッシュ値aを取り出す方法を、20字以内で答えよ。
（3）表4中の下線⑪について、どのような状態になれば改ざんされていないと判断できるかを、25字以内で答えよ。
