令和６年春　午後Ⅱ　問２

問2　電子メールを用いた製品サポートに関する次の記述を読んで、設問に答えよ。

　Y社は、企業向けにIT製品を販売する会社であり、電子メール(以下、メールという)を使用して、販売した製品のサポートを行っている。Y社では、取扱製品の増加に伴って、サポート体制の強化が必要になってきた。そこで、サポート業務の一部を、サポートサービス専門会社のZ社に委託することを決定し、Y社の情報システム部のX主任が、委託時のメールの運用方法を検討することになった。

　Y社のネットワーク構成を図1に、外部DNSサーバYが管理するゾーン情報を図2に、社内DNSサーバYが管理するゾーン情報を図3に示す。

　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が設定されている。

　送信元メールアドレスの詐称の有無に対しては、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社が導入しているSPFによる送信ドメイン認証の流れを次に示す。

（ⅰ）サポート担当者は、送信元メールアドレスがsupport@y-sha.comにセットされたサポートメー
　　ルを、顧客宛てに送信する。

（ⅱ）サポートメールは、社内メールサーバYからメール中継サーバY1又はY2を経由して、顧客の
　　メールサーバに転送される。

（ⅲ）顧客のメールサーバは、メール中継サーバY1又はY2から、メール転送プロトコルである
　　（　d　）の（　e　）コマンドで指定されたメールアドレスのドメイン名の（　f　）を入手
　　する。顧客のメールサーバは、DNSを利用して、（　f　）ドメインのゾーン情報を管理する外
　　部DNSサーバYに登録されているSPFレコードを取得する。

（ⅳ）顧客のメールサーバは、④取得したSPFレコードに登録された情報を基に、送信元のメールサー
　　バの正当性を検査する。

（ⅴ）正当なメールサーバから送信されたメールなので、なりすましメールではないと判断してメー
　　ルを受信する。なお、正当でないメールサーバから送信されたメールは、なりすましメールと判
　　断して、受信したメールの隔離又は廃棄などを行う。

[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に示す。

　DKIMにおける送信側は、電子署名データなどを登録したDKIM-Signatureヘッダーを作成して送信するメールに付加する処理(以下、DKIM処理という)を行う。DKIMでは、一つのドメイン中に複数のセレクターを設定することができ、セレクターごとに異なる鍵が使用できる。セレクターは、DNSサーバに登録されたDKIMレコードを識別するためのキーとして利用される。

　DKIM-Signatureヘッダー中のタグの説明を表3に示す。ここで、DKIM-Signatureヘッダーの構成図は省略する。

　Y社は、顧客宛てのサポートメールに対するDKIM処理を、メール中継サーバY1及びY2で行っている。Y社では、ドメイン名がy-sha.comでセレクター名がsel.yshaのセレクターを設定している。Y社が送信するメールのDKIM-Signatureヘッダー中のsタグには、図5中に示したセレクター名のsel.yshaが登録されている。

Y社が導入しているDKIMによる送信ドメイン認証の流れを次に示す。

（ⅰ）サポート担当者は、送信元メールアドレスがsupport@y-sha.comにセットされたサポートメー
　　ルを、顧客宛てに送信する。

（ⅱ）サポートメールは、社内メールサーバYからメール中継サーバY1又はY2を経由して、顧客の
　　メールサーバに転送される。

（ⅲ）メール中継サーバY1又はY2は、サポートメールに付加するDKIM-Signatureヘッダー中に電子署
　　名データなどを登録して、顧客のメールサーバに転送する。

（ⅳ）顧客のメールサーバは、DKIM-Signatureヘッダー中のdタグに登録されたドメイン名であるy-
　　sha.comとsタグに登録されたセレクター名を基に、DNSを利用して、当該ドメインのゾーン情報
　　を管理する外部DNSサーバYに登録されているDKIMレコードを取得する。

（ⅴ）顧客のメールサーバは、⑤取得したDKIMレコードに登録された情報を基に、電子署名の真正性
　　を検査する。

（ⅵ）正当なメールサーバから送信されたメールなので、なりすましメールではないと判断してメー
　　ルを受信する。なお、正当でないメールサーバから送信されたメールは、なりすましメールと判
　　断して、受信したメールの隔離又は廃棄などを行う。

[Z社に委託するメールの運用方法の検討]

　まず、X主任は、自社のメールシステムのセキュリティ運用規程に、次の規定があることを確認した。

（あ）社内メールサーバYには、Y社に勤務する従業員以外のメールボックスは設定しないこと

（い）社内のPCによるメール送受信は、社内メールサーバYを介して行うこと

（う）メール中継サーバY1及びY2にはメールボックスは設定せず、社内メールサーバYから社外宛て、
　　及び社外から社内メールサーバY宛てのメールだけを中継すること

（え）Y社のドメインを利用するメールには、なりすまし防止などの情報セキュリティ対策を講じるこ
　　と

　次に、メールの運用方法の検討に当たって、X主任は、Z社のネットワーク構成とサポート体制を調査した。

　Z社のネットワーク構成を図6に、外部DNSサーバZが管理するゾーン情報を図7に示す。

　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に示す。

　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社の窓口担当者との調整に取り掛かった。

設問１

[Y社のネットワーク構成とセキュリティ対策の背景]について答えよ。

本文中の下線①について、転送先のメール中継サーバのFQDNを答えよ。

1. 下線①の文脈を確認
2. 「どのFQDN宛に転送しているのか」を特定するヒントを探す
3. DNSラウンドロビンとは何か
4. 図3の内容を確認
5. どのFQDNが該当するかを判断する

下線①の文章を確認すると、

サポート担当者が送信したサポートメールが①社内メールサーバYからメール中継サーバに転送されるとき…

ここで言いたいのは、社内メールサーバYが、メールを中継して外部に届けるために「どの宛先に送っているか」を聞いています。

下線②でヒントが与えられています。

②DNSラウンドロビンによって、メール中継サーバY1またはY2に振り分けられる。

この一文が重要です。

つまり、固定の1台ではなく、DNSの仕組みによりY1かY2に振り分けるように構成されているということです。

DNSラウンドロビンとは、1つのFQDN（ホスト名）に複数のIPアドレスを登録しておき、名前解決のたびに異なるIPアドレスを返す仕組みです。

たとえば、次のような指示を行います。

mail.example.com → 192.0.2.1（1回目）
mail.example.com → 192.0.2.2（2回目）
mail.example.com → 192.0.2.1（3回目）……のような感じになります。

mail.y-sha.lan. IN A 192.168.0.1
mail.y-sha.lan. IN A 192.168.0.2

→ つまり mail.y-sha.lan というFQDNに対して2つのIPが登録されています。

• 192.168.0.1 → y-mail1.y-sha.lan
• 192.168.0.2 → y-mail2.y-sha.lan

DNSラウンドロビンの典型的な構成です。

ポイントは、

• 社内メールサーバYは 中継先の個別ホスト（y-mail1など）を直接指定しているのではない
• 代わりに、共通のFQDN（mail.y-sha.lan）宛てにメールを出し、その名前解決結果としてどちらかに送る

よって解答はmail.y-sha.lanとなります。

このFQDNに対して名前解決を行うことで、DNSラウンドロビンによってY1またはY2のいずれかに振り分けられます

したがって、転送先のメール中継サーバのFQDNとして最も適切です。

• それぞれは特定の中継サーバを直接指定するFQDNであり、可用性や冗長性の観点で不利
• Y社の構成では、中継サーバが冗長構成（Y1/Y2）になっており、DNSラウンドロビンで分散されている
• したがって、ラウンドロビン対象の「mail.y-sha.lan」を指定するのが正解

まとめると、メール中継サーバが複数あり、DNSラウンドロビンで振り分けている場合、転送先には個別ホスト名（y-mail1など）ではなく、共通のFQDN（mail.y-sha.lan）を使うということになります。

本文中の下線②について、社内メールサーバYからメール中継サーバY1又はY2へのメール転送時に、振分けの偏りを小さくするために実施している方策を、25字以内で答えよ。

この問題は、「DNSラウンドロビンによる負荷分散における偏り対策」がテーマです。

②DNSラウンドロビンによってメール中継サーバY1又はY2に振り分けられる。

この方式は、同じFQDNに複数のAレコードを設定して、アクセス先を分散させる構成です。

Y社では mail.y-sha.lan に以下の2つのAレコードが設定されています（図3より）。

• mail.y-sha.lan → 192.168.0.1（y-mail1）
• mail.y-sha.lan → 192.168.0.2（y-mail2）

ラウンドロビンDNSは、DNSクライアント（この場合は社内メールサーバY）が名前解決結果をキャッシュしてしまうと、次回以降も同じ中継サーバばかり使い続けるという問題があります。

つまり、キャッシュ時間が長いと、振り分けが効かなくなる → 負荷が偏るということになります。

この対策は、DNSキャッシュの寿命（TTL）を短く設定することです。

図3を見てみると、

$TTL 172800（上段）
mail.y-sha.lan. 60 IN A 192.168.0.1
mail.y-sha.lan. 60 IN A 192.168.0.2

→ mail.y-sha.lan のTTLだけが 「60秒」に設定されています。

つまり、社内メールサーバYが60秒ごとに再度DNSクエリを行う →回答順が変わる → 振り分けが偏りにくくなる、ということになります。

• TTL（Time To Live）とは、DNSのレコードがクライアント側で保持される期間
• TTLが長い → 名前解決が早いが、負荷分散が効きにくい
• TTLが短い → 名前解決が頻繁になり、DNS負荷は上がるが、ラウンドロビンが効果的に機能する

本文中の（　a　）～（　c　）に入れる適切な字句を答えよ。

（a）に入る語句

顧客が送信したサポートメールがメール中継サーバに転送されるときは、外部DNSサーバYに登録された MXレコードの（　a　）値 によって…

これはMXレコードに付属する「優先度（Preference）」のことを指しています。

MXレコードの例（図2より）

y-sha.com. IN MX 10 y-mail2.y-sha.com.
y-sha.com. IN MX 20 y-mail1.y-sha.com.

この「10」「20」が Preference値（優先度）であり、数値が小さいほど優先度が高い（先に選ばれる）ということになります。

（b）に入る語句

平常時は、ホスト名が（　b　）のメール中継サーバが選択される。

Preference値が小さい方（=優先される）を見ると、

10 → y-mail2.y-sha.com
20 → y-mail1.y-sha.com

つまり、平常時に使われるのは y-mail2.y-sha.com です。

（c）に入る語句

DNSの（　c　）と呼ばれる名前解決によって…

この文の文脈は、送信元メールサーバのIPアドレスからメールサーバのFQDNを取得し、そのFQDNと送信元メールアドレスのドメイン名が一致するか検査する方法のことを示しています。

これは、IPアドレスからFQDNを得る名前解決、すなわち「逆引きDNS」の説明です。

• 順引き（正引き）：FQDN → IPアドレス
• 逆引き：IPアドレス → FQDN（PTRレコードを使う）

表1中の（　ア　）、（　イ　）に入れる適切なIPアドレスを答えよ。

この設問は、表1「静的NATの設定情報」に関するものです。

NATの変換元／変換先のIPアドレスを正しく読み取り、空欄（ア）（イ）を埋める必要があります。

表1には、Y社のFWで設定されている静的NATの情報が記載されています。

変換対象のサーバ	変換元IPアドレス	変換先IPアドレス	ポート番号
メール中継サーバY1	（ア）	（イ）	25

ここで、重要なのは、

• 変換元IPアドレス（ア）：インターネット側から見たIPアドレス（グローバルIP）
• 変換先IPアドレス（イ）：社内ネットワーク内のIPアドレス（プライベートIP）

です。

「メール中継サーバY1」のプライベートIPはどこか？→ 図3（社内DNSゾーン情報）より

y-mail1.y-sha.lan. IN A 192.168.0.1

よって、変換先（イ）は：192.168.0.1となります。

図2（外部DNSのゾーン情報）より、メール中継サーバY1に対応するホスト名は、

y-mail1.y-sha.com. IN A 200.a.b.1

つまり、メール中継サーバY1のグローバルIPは 200.a.b.1→ これがインターネット側から見える「変換元IPアドレス」となります。

まとめると

空欄	解答	説明
ア	200.a.b.1	グローバルIP（y-mail1.y-sha.com）
イ	192.168.0.1	プライベートIP（y-mail1.y-sha.lan）

この対応関係がNATで設定されていることで、外部からのSMTPアクセス（ポート25）が正しくY1サーバに届くわけです。

本文中の下線③について、攻撃者がPTRレコードに対して行う不正な操作の内容を、次に示す図8を参照して45字以内で答えよ。

この問題では、下線③の内容と図8（PTRレコードの形式）を用いて、「攻撃者がどのようにして“逆引きの検査”をすり抜けるか」を答えます。

③攻撃者は、自身が管理するDNSサーバのPTRレコードに不正な情報を登録することができるので、ドメイン名が一致しても詐称されているおそれがある

ここで問われているのは、

• 攻撃者がどんなPTRレコードを登録しているのか？
• それによって逆引き検査をどうすり抜けようとしているのか？

ということです。

203.0.113.1.in-addr.arpa. IN PTR mail.y-sha.com.

これは、IPアドレス 203.0.113.1 に対してFQDNとして mail.y-sha.com. を逆引きで登録している、という意味になります。

本来、逆引きのチェックとは、

送信元IP → PTRでFQDNを取得 → 得られたFQDNのドメインと、メールアドレスのドメインが一致しているかを確認

という流れですが、もし攻撃者が自分の持っているIPアドレス（例：203.0.113.1）に、偽のPTRレコードを登録して、あたかも「y-sha.comドメインの正規サーバ」であるかのように装うと、「逆引き結果のFQDN」と「メールアドレスのドメイン」が一致してしまう→ “詐称されていない”と誤認される→ 攻撃が成功する、ということが起こってしまいます。

• PTRレコードは誰でも管理できるDNSで登録可能（攻撃者でも）
• 「正引き」と「逆引き」が一致するとは限らない
• 信頼できないPTR情報に依存する検査は、なりすましに弱い

設問２

[Y社が導入しているSPFの概要]について答えよ。

図4中の（　ウ　）、（　エ　）に入れる適切なIPアドレスを答えよ。

この問題は、図4に記載されたSPFレコードにおける、送信元IPアドレスの許可設定に関する空欄（ウ）（エ）を問うものです。

SPF（Sender Policy Framework）は、そのドメイン（ここでは y-sha.com）から送られるメールについて、「どのIPアドレスからの送信を正当とするか」をDNSに記録する仕組みです。

これにより、メール受信側は「この送信元IPは正規の送信者か？」を検証できます。

SPFレコードは、ドメインのDNSゾーン情報内にTXTレコードとして記述されます。

図4のSPFレコードを抜粋すると、下記のようになります。

“v=spf1 ip4:(ウ) ip4:(エ) -all”

• v=spf1 ：SPFのバージョン指定
• ip4:（ウ）・ip4:（エ）：正当な送信元IPアドレス
• -all：それ以外は拒否

→ よって、空欄（ウ）と（エ）には、「Y社がメール送信に使う中継サーバのグローバルIPアドレス」が入ります。

図2（外部DNSのゾーン情報）より

y-mail1.y-sha.com. IN A 200.a.b.1
y-mail2.y-sha.com. IN A 200.a.b.2

→ これらが、社外向けにメールを送るメール中継サーバY1／Y2のグローバルIPです。

よって答えは

空欄	IPアドレス	説明
ウ	200.a.b.1	メール中継サーバY1のグローバルIP
エ	200.a.b.2	メール中継サーバY2のグローバルIP

このようになります。

SPFの目的は、送信元IPアドレスが正当なものかどうかを検証することです。

検証対象は、メールの送信元IPアドレスとなります。

仕組みは、

1. メールの受信側が、送信元メールアドレスのドメイン（例：y-sha.com）に対してDNS問い合わせを行い、SPFレコード（TXT形式）を取得。
2. SPFレコードに登録されたIPアドレスと、実際にメールを送ってきたIPアドレスを比較。
3. 一致していれば正当な送信者と判断。不一致なら「なりすまし」と判定可能。

特徴は、

• 検証対象がIPアドレスなので、メール中継サーバを通す構成でないと認証が通らない。
• メール本文やヘッダーの改ざん検知はできない。

一方で、DKIMの場合、目的は送信者のドメインの正当性と、メールの改ざん有無の検証です。

検証対象は、メールのヘッダーと本文（署名されたデータ）となります。

仕組みは、

1. メール送信時に、送信側が自ドメインの秘密鍵で署名を生成し、DKIM-Signatureヘッダーに付加。
2. 受信側は、DKIM-Signature内の「dタグ（ドメイン）」と「sタグ（セレクター）」を元に、公開鍵をDNSから取得（TXTレコード）。
3. その公開鍵で署名を検証し、改ざんされていない正当な送信かを判断。

特徴は、

• IPアドレスは関係ないので、中継サーバが変わっても有効。
• メール本文やヘッダーの一部が改ざんされた場合、署名検証が失敗する。
• 第三者の認証局（CA）による証明書は不要（自前で鍵を管理できる）。

項目	SPF	DKIM
検証対象	送信元IPアドレス	メールヘッダーと本文
設定場所	ドメインのDNS（TXTレコード）	ドメインのDNS（TXTレコード）
主な目的	なりすまし防止（送信元の正当性）	改ざん検知＋送信元の正当性の検証
メール中継可否	中継不可（IPが変わるとNG）	中継OK（本文が改ざんされなければ有効）
改ざん検知	× 検知不可	○ 署名が壊れることで検知できる
鍵の使用	不要	必要（公開鍵・秘密鍵）
柔軟性	やや低い	高い（セレクターで鍵の管理も柔軟）

SPFとDKIMは、どちらか片方だけでは完全ななりすまし対策にはなりません。

SPFだけだと、本文の改ざんを検知できません。

DKIMだけだと、そもそも送信元IPが無関係になってしまうため、誰でも署名を付ければよくなってしまう恐れがあります（鍵が漏れていると意味がない）。

そのため、多くの企業では SPFとDKIMを併用し、さらにその検査結果をポリシーとして通知する DMARC（ディーマーク）もあわせて導入しています。

本文中の（　d　）～（　f　）に入れる適切な字句を答えよ。

この設問は、SPFによる送信ドメイン認証の仕組みに関する記述の空欄（d）〜（f）に、適切な用語を補う問題です。

顧客のメールサーバは、メール中継サーバY1又はY2から、メール転送プロトコルである
（　d　） の （　e　） コマンドで指定されたメールアドレスのドメイン名の （　f　） を入手する。

この記述は、SPFの検証対象となるメールアドレスのドメイン名をどのようにして取得するかを説明しています。

（d）に入る語句：メール転送プロトコル

メール送信時の転送プロトコルといえば、SMTP（Simple Mail Transfer Protocol）です。

→SMTP というプロトコルによって、メールがサーバ間で送られます。

（e）に入る語句：送信元メールアドレスを指定するSMTPコマンド

SMTPにはいくつかのコマンドがありますが、送信元アドレスを指定するコマンドは、MAIL FROM:（送信元アドレスの指定）です。

一方、RCPT TO: は宛先（受信者）アドレスの指定なので、ここでは不適切です。

（f）に入る語句：MAIL FROMで指定されたメールアドレスのドメイン名

例えば、送信者アドレスが support@y-sha.com なら、ドメイン名は y-sha.comとなります。

このドメイン名を使って、外部DNSサーバYに登録されたSPFレコードを取得し、正当な送信元IPかどうかを検証します。

空欄	解答	説明
d	SMTP	メール転送プロトコル
e	MAIL FROM	送信元アドレスを指定するSMTPコマンド
f	y-sha.com	検証対象となるドメイン名（送信者のドメイン）

この設問では、「SMTPの動作」「SPFがどの情報をもとに検証を行うか（MAIL FROMのドメイン名）」といった知識が求められています。

本文中の下線④について、正当性の確認方法を、50字以内で答えよ。

この問題はSPF（Sender Policy Framework）による送信者の正当性確認方法に関するもので、ネットワークスペシャリスト試験でもよく問われる「ドメイン認証」の仕組みを正しく理解しているかが試されています。

④取得したSPFレコードに登録された情報を基に、送信元のメールサーバの正当性を検査する。

1. メール受信時に、送信者のドメイン（MAIL FROM）を確認する。
   • たとえば、support@y-sha.com という送信元アドレスであれば→ ドメイン名は y-sha.comとなります。
2. そのドメインのDNSゾーンにある「SPFレコード」を取得する。
   • DNSには TXT レコードとして、たとえば次のようなSPF情報が設定されています。
   • 例：v=spf1 ip4:200.a.b.1 ip4:200.a.b.2 -all
   • これは、「このドメインから送信されるメールは 200.a.b.1 または 200.a.b.2 からしか送っちゃダメ」という意味です。
3. 実際に接続してきたメールサーバのIPアドレスと、SPFレコード内のIPアドレスを比較する。
   • 接続元IPが 200.a.b.1 だった場合→OK（正当）となります。
   • 接続元IPが 203.0.113.99 だった場合→NG（不正）となります。
4. SPFに登録されているIPアドレスと一致していれば、その送信は正当とみなされる。

つまり、SPFの正当性の確認方法とは、「接続してきた送信元IPアドレス」が、ドメインのDNSに登録されているSPFレコードの中に含まれているかを確認することです。

SPFレコードが存在しない、あるいは一致しない→なりすましの可能性があるということです。

SPFチェックに失敗したメールは、受信拒否・隔離・マーク付与などの処理を受けることがあります（※処理は受信側のポリシーによる）。

SPFは「IPアドレス」だけを見ているので、以下のような限界があります。

• 中継サーバを経由すると送信元IPが変わる→正当でもNGになる
• ヘッダーや本文の改ざんは検出できない
• 「Reply-To」や表示名に悪意のある文字列を入れても検知できない

→ だからこそ、DKIMやDMARCとの併用が重要になります。

設問３

[Y社が導入しているDKIMの概要]について答えよ。

本文中の（　g　）～（　i　）に入れる適切な字句又は数値を答えよ。

この設問は、DKIM（DomainKeys Identified Mail）による署名の仕組みと、DNSでの鍵公開方法に関する理解を問う問題です。

DKIMは、送信側のメールサーバでメールに電子署名を付与し、受信側のメールサーバで電子署名の真正性を検証することで、送信者のドメイン認証を行う。電子署名のデータは、メールの（　g　）及び本文を基に生成される。

DKIMでは、送信者のドメインのゾーン情報を管理する権威DNSサーバを利用して、電子署名の真正性の検証に使用する鍵を公開する。鍵長は、2,048ビットより大きな鍵を利用することも可能である。しかし、DNSをトランスポートプロトコルである（　h　）で利用する場合は、DNSメッセージの最大長が（　i　）バイトという制限があるので、（　i　）バイトに収まる鍵長として、一般に2,048ビットの鍵が利用される。

（g）に入る語句：「ヘッダー」

KIMでは、送信するメールの改ざんを防ぐために、メールの一部に電子署名を付けて送ります。

この署名は、以下の情報を元にハッシュ化し、秘密鍵で署名します。

• メールの本文（本文が改ざんされていないか確認するため）
• メールヘッダーの一部（FromやSubject、Dateなど）

特にヘッダーはメールの信頼性に直結する重要な情報です。

ここが書き換えられていたら、なりすましの温床になってしまいます。

■ 署名対象となるヘッダーの例

• From:
• To:
• Subject:
• Date:

※DKIM-Signatureヘッダーの h= パラメータにどのヘッダーを署名対象にするかが明示されます。

◆（h）に入る語句：「UDP」

• DNSは名前解決をするプロトコルで、一般的にはUDPを使って動作します。
• DNSクエリは「軽量・高速な通信」が求められるため、接続確立の必要がないUDPが使われるのです。

ただし、以下のケースではTCPが使われます。

• 応答が512バイトを超える（EDNS未対応環境）
• ゾーン転送（AXFRなど）
• 応答が断片化された場合（TCP再試行）

しかし、DKIMの公開鍵は通常DNSの TXT レコードに格納されるため、DNSの標準動作＝UDP前提でサイズ制限が課題になります。

（i）に入る数値：「512」

UDPでDNSを使う際の、1パケットあたりの最大サイズが512バイトという仕様が、RFC（※RFC 1035）で定められています。

そのため、

• DKIMの公開鍵（TXTレコードに格納）は、この512バイトの範囲内に収まるように設計する必要がある
• 実際には、TXTレコードのオーバーヘッドもあるので、公開鍵の長さは2,048ビット（256バイト）程度が最適とされている

※EDNS（拡張DNS）を使えば512バイト以上も扱えますが、レガシーな環境では非対応もあるため、保守的な設計が好まれます。

空欄	解答	補足
g	ヘッダー	DKIMはメールのヘッダー＋本文で署名生成
h	UDP	DNSで使われる標準的なトランスポートプロトコル
i	512	UDPによるDNS応答サイズの最大値（バイト）

なぜヘッダー全体ではなく「一部」だけを署名対象にするの？

メール中継時に Received: ヘッダーなどが追加されるため、変化する可能性があるヘッダーを除外する必要があります。
一方で、改ざんされると困る From: や Subject: は署名対象に含めます。

もし512バイトを超えるとどうなる？

DNS応答が途中で切れて失敗するか、再試行でTCP接続になることがありますが、確実性を求めるなら512バイトに収まる設計（鍵長2,048ビット）が望ましいです。

図5のDKIMレコードで指定されている暗号化方式のアルゴリズム名、及び表2中の（　オ　）に入れる適切な鍵名を答えよ。

この問題は、DKIMで使われている暗号化方式と、それに関連する鍵の名称（公開鍵か秘密鍵か）を問うものです。

DKIM（DomainKeys Identified Mail）は、以下のように動作します。

1. 送信側が、メールに電子署名を付ける（署名の材料：ヘッダーと本文のハッシュ）
2. その署名を、ドメイン管理者が用意した秘密鍵で暗号化
3. 受信側は、DNSに登録された公開鍵を使って署名を検証

このように、DKIMは公開鍵暗号方式を使っており、署名と検証で「非対称鍵ペア（秘密鍵・公開鍵）」を利用します。

v=DKIM1; k=rsa; p=MIIBIjANBgkq…（鍵データ）

この中の k=rsa に注目してください。

k= は「鍵のアルゴリズム」を示すタグです。

rsa は、公開鍵暗号方式の中で最も一般的なRSA暗号のことです。

この問題は、DKIMレコード中の「p=」タグが何を表すのか？　すなわち、どの鍵（公開鍵／秘密鍵）を指しているのかを問うものです。

DKIM（DomainKeys Identified Mail）は、公開鍵暗号方式を利用してメールのなりすましを防ぐ技術です。

使われる鍵は2種類あります。

鍵の種類	誰が保持？	用途
秘密鍵	送信側メールサーバ	署名の生成（電子署名を作る）
公開鍵	DNSに公開	署名の検証（正当性を確認）

DKIMでは、受信側がメールの署名を検証するために、送信側が用意した「公開鍵」をDNSから取得します。

その公開鍵は、TXTレコードとしてDNSに次のように登録されています。

v=DKIM1; k=rsa; p=MIIBIjANBgkqh…（Base64でエンコードされた文字列）

この中で

• v=DKIM1：バージョン指定
• k=rsa：鍵のアルゴリズム（RSA）
• p=…：公開鍵（Public Key）そのもの

p=タグには、DKIM署名の検証に使う公開鍵が入っています。

Base64形式でエンコードされた文字列としてDNSに登録されており、受信側はこの「p=」の中身を使って、署名の整合性をチェックします。

注意したいポイントとしては、

• 「p=」に入っているのは秘密鍵ではありません。
• 秘密鍵は送信者だけが持っており、絶対に外部に公開してはいけません。

DKIMは、送信者が署名し、受信者が検証する仕組みです。

その検証のために、受信者は送信者が提供した「公開鍵」が必要となります。

それをDNSに登録することで、誰でも検証できるようにしているのです。

本文中の下線⑤について、電子署名の真正性の検証によって送信者がなりすまされていないことが分かる理由を、50字以内で答えよ。

この設問では、「なぜDKIMの電子署名の検証によって、送信者がなりすまされていないと判断できるのか？」という根拠を、しっかり理解して答える必要があります。

顧客のメールサーバは、⑤取得したDKIMレコードに登録された情報を基に、電子署名の真正性を検査する。

1. メール送信時、送信者（Y社やZ社など）が、自分の秘密鍵を使って署名を生成する。
2. 署名は、メールのヘッダーと本文の内容を元に作られる。
3. この署名は、DKIM-Signature: というメールヘッダーに付けて一緒に送られる。
4. 受信者は、送信者のドメインのDNSに登録された「公開鍵（p=）」を使って署名を検証する。

①秘密鍵は送信者だけが持っている

• DKIMの署名は、「そのドメインの持ち主（送信者）」しか知らない秘密鍵で作られます。
• 第三者（攻撃者）が勝手に正しい署名を作ることは不可能。

②受信者は公開鍵で検証する

• 受信者は、そのドメインのDNSから公開鍵を取得して、送られてきた署名の正当性を検証します。
• 署名が一致していれば、そのメールは「正当な送信者」から送られたと判断できるのです。

攻撃者が送信元メールアドレスを詐称してメールを送ったとしても、正しい秘密鍵を持っていないので、署名を生成することは不可能です。

DKIM署名を偽造したり、中身を改ざんすれば、検証に失敗します。

逆に、検証に成功するということは、「秘密鍵を持っている正当な送信者」が送った証拠となります。

つまり、正規のドメインの秘密鍵で署名されたメールだけが、受信者側で検証に成功するという仕組みです。

• 「公開鍵は誰でも見られる」
• 「秘密鍵は送信者しか持っていない」

この2つの前提から、「正しい署名は正規の送信者しか作れない」→「検証が通ればなりすましではない」と言えるのです。

設問４

[Z社に委託するメールの運用方法の検討]について答えよ。

本文中の下線⑥について、登録するDNSサーバ名及びDNSサーバに登録する情報を、それぞれ、図1又は図6中の字句を用いて答えよ。

この設問は、下線⑥に関連する「SPF対応のために登録すべきDNS情報」を問うもので、以下2つの情報を図から正確に答える必要があります：

1. DNSサーバ名（どのDNSサーバに登録するのか）
2. 登録する情報（どんなIPアドレスを登録するのか）

SPFには、⑥DNSサーバにSPFで利用する情報を登録することで対応できると考えた。

この文は、次のような背景を前提にしています。

• Z社がY社に代わって、support@y-sha.comというアドレスで顧客にメールを送る
• SPFはドメインごとに「どのIPから送ってよいか」をDNSで定義する

→つまり、Z社のメール中継サーバのIPアドレスを、Y社のDNSにSPFレコードとして登録する必要がある。

質問内容	解説のポイント
DNSサーバ名	どのDNSにSPFレコードを登録すべきか？
登録する情報	どの送信元IPアドレス（サーバ）を登録すべきか？

図を確認すると、

• support@y-sha.comのドメインは「y-sha.com」。
• このドメインのゾーン情報を管理しているのは、Y社の外部DNSサーバYです。
• 図1ではこのサーバのホスト名は→y-ns1

これは、SPFに限らず、ドメインの認証に関わるレコード（SPF・DKIM・DMARCなど）は、そのドメインを管理しているDNSに登録するというルールに基づいています。

よって答えは「外部DNSサーバY、y-ns1」となります。

次に、「Z社からメールを送るのはどのサーバか？」を見ていきます。

図6（Z社の構成図）を確認すると、

• メール中継サーバ：z-mail1
• IPアドレス：203.0.113.1

このメール中継サーバが、support@y-sha.comというアドレスを使ってY社の顧客にメールを送るわけです。

なので、このサーバ（z-mail1）のIPアドレスを、SPFレコードに登録する必要があるということになります。

v=spf1 ip4:203.0.113.1 -all

このように書くことで、「このドメイン（y-sha.com）のメールは 203.0.113.1 から送ってOK」と世界に宣言するわけです。

よって答えは「メール中継サーバのIPアドレス、z-mail1のIPアドレス」となります。

SPFは「送信元ドメインのDNS」でしか設定できない

support@y-sha.comというアドレスでメールを送るということは、「y-sha.com」ドメインの名を借りている状態になります。

そのため、その正当性（送信元IPが正規かどうか）を宣言するのは、y-sha.comの持ち主（Y社）だけができることです。

よって、Z社側で勝手にDNSを用意してSPFを登録しても意味がありません。Y社側のDNSに登録する必要があるのです。

補足：なぜこの登録が必要なのか？

もしこれを登録しないとどうなるのでしょうか？

• 受信者のメールサーバがsupport@y-sha.comという送信元アドレスを見て、DNSからSPFを調べる
• そのSPFレコードに、Z社の中継サーバ（z-mail1）のIPが載っていない
• → なりすましと判断され、迷惑メール扱い or 受信拒否される

→ つまり、委託先（Z社）からメールを出すために、Y社のDNSにきちんと設定を追加しておくことが不可欠ということです。

本文中の（　j　）に入れる適切な字句を答えよ。

この設問は、DKIM-Signatureヘッダー中の d= タグに指定すべきドメイン名（（j）に入る語句）を問うものです。

文脈的には、「Z社がsupport@y-sha.comというメールアドレスを使ってメールを送信する際、DKIMでどのドメイン名を指定すべきか？」という点が問われています。

DKIM-Signatureヘッダー中のdタグで指定するドメイン名には（　j　）を登録し…

この文章は、Z社がsupport@y-sha.comとしてメールを送る際に、DKIM-Signatureに含めるべき送信ドメイン（d=タグの値）を指定するための文です。

d=：この署名が属するドメイン名（＝送信者のドメイン名）を示します。

DKIM署名の検証時には、この d= のドメイン名に対応するDNSにある公開鍵を取得して検証を行います。

つまり、メールの送信元アドレスのドメイン部分と d= の値は原則として一致させる必要があるのです。

Z社が送信するメールの送信元は、support@y-sha.comです。

つまりこのアドレスのドメインは y-sha.comとなります。

DKIM署名は、あくまで“メールアドレスのドメインの正当性”を示すためのものです。

たとえメールがZ社から送られたとしても、support@y-sha.comという送信元アドレスを使う以上、署名対象のドメインもy-sha.comにしないと認証が失敗することになります。

つまり、メールがZ社の設備から出ても、「Y社のドメインを使って送っている」という扱いになるため、d=にはY社のドメインを使う必要があるのです。

本文中の下線⑦について、異なる鍵を利用することによる、Y社におけるセキュリティ面の利点を、50字以内で答えよ。

この設問は、DKIMにおけるセレクターと鍵の分離運用のセキュリティ的利点を深く理解できているかを確認するものです。

「委託先（Z社）」と「本体（Y社）」が別々の鍵を使う理由を問うています。

本文では、Y社がZ社にサポート業務を委託し、Z社からも support@y-sha.com というメールアドレスで顧客にメールを送るようにしたいと考えています。

そのためには、Z社からのメールについてもDKIM署名が必要になります。

このとき、Y社が行った設定は以下の通りです。

• Z社で使用するDKIMのセレクター：sel.zsha
• Z社はこのセレクターに対応する独自の鍵ペア（公開鍵・秘密鍵）を使って署名
• そして、その公開鍵を Y社の外部DNSサーバ（y-ns1）に登録

DKIMで使うセレクターは、DNS上の公開鍵を特定するための識別子です。

• DKIM署名では、ヘッダーに s=sel.ysha などと記載
• DNSでは、sel.ysha._domainkey.y-sha.com に公開鍵がTXTレコードで登録される

つまり、「どの鍵を使ったか？」を識別するための鍵の名前のようなものがセレクターです。

もしY社とZ社で同じ鍵ペアを使っていたら？

仮にZ社の中継サーバ（z-mail1）が攻撃を受けて秘密鍵が漏えいすると……。

→ その秘密鍵を使って誰でもy-sha.comの正規メールを装って署名できる

→ Y社の本体の信頼性まで失墜する

ということが起こりかねません。

一方、鍵を分けていれば？

Z社用の鍵（sel.zsha）しか漏れていないなら、Z社が送ったメール署名しか悪用されません。

そのためY社本体（sel.ysha）のメール署名には全く影響が出ません。

つまり、「鍵の独立性」により、被害の範囲を限定（局所化）できるのです。

DKIMは、署名を行ったドメインのDNSに公開鍵を登録する必要があります。

今回は、support@y-sha.com というアドレスなので、DNSは y-sha.com のものです。

たとえZ社からメールを送っていても、DKIMの検証先はあくまで Y社のDNSとなります。

そのため、Y社のDNSにZ社用の鍵（sel.zsha）も登録する必要があります。（それが下線⑥や図5に対応）

比較ポイント	鍵を共有した場合	鍵を分離した場合（今回）
鍵が漏えいしたときの影響	Y社もZ社も署名破られる	Z社側の署名だけが破られる（Y社は無傷）
被害の広がり	ドメイン全体の信頼が失われる恐れ	影響が委託先（Z社）に限定される
管理のしやすさ	楽だが危険	やや複雑だがセキュア

この設問は、セキュリティ事故の被害範囲をいかに限定するか＝「影響範囲の分離（セグメンテーション）」という、実務でも非常に重要な視点を問う良問でした。

本文中の下線⑧について、顧客のメールサーバでは、なりすましを検知できない理由を、40字以内で答えよ。

この問題は、なぜDKIMやSPFで守られているはずのsupport@y-sha.comのメールなのに、Z社内の別人がなりすましできてしまうのか？　という仕組み的な脆弱性を問うものです。

⑧“Z社のサポートチームY以外の部署の従業員が、送信元メールアドレスにsupport@y-sha.comをセットしてサポート担当者になりすました場合、顧客のメールサーバでは、なりすましを検知できない”、との指摘を受けた。

本来であれば、Z社の「サポートチームY」の担当者が、support@y-sha.comを使って顧客対応をします。

ところが、Z社内の別の部署の社員が、自分の業務とは無関係に、support@y-sha.comを送信元に設定してメールを送信できてしまいます。

これが「なりすましメール」です。

SPF・DKIMで守られているのに、なぜ検知できないのか？

• SPFは、メールの送信元IPアドレスが、DNSに登録された正当なIPかどうかをチェックします。
• 今回、Z社のメール中継サーバ z-mail1（IP：203.0.113.1）は、すでにY社のDNSにSPFレコードとして登録されている。

よって、誰が送っても z-mail1 経由であれば SPF はパスしてしまいます。

• DKIMは、メールの署名が正規の秘密鍵で作られているかどうかをチェックします。
• 送信時に DKIM-Signature を z-mail1 が付加し、秘密鍵（sel.zsha）で署名。
• これも、サポート担当者でなくても、同じ送信サーバを使えば署名できてしまう。

よって、DKIMも通過してしまいます。

結果として、DKIMでもSPFでも「正規のメール」と判定されてしまうのです。

→ つまり受信者のメールサーバ側では、このメールが“Z社の別人によるなりすまし”だとは判別できないということになります。

受信者側は、メールが「support@y-sha.com」から届いた」＋「正規の中継サーバ」＋「正しい署名」ということで、正当と判断するしかないのです。

補足：どうすれば防げるのか？

本文にもあるように、X主任はこの課題を認識して、S/MIMEの導入を決めました。

[S/MIMEの導入効果]

• 各担当者に個人単位で電子証明書と秘密鍵を配布
• 担当者ごとに異なる署名を付けられる
• 受信者はその署名が“誰”のものか、証明書で検証可能
• 結果：「Z社のサポート担当者のAさん」が送ったのか、「他部署のBさん」が偽装したのかが分かる

→ DKIMやSPFでは「会社単位」までしか認証できないが、S/MIMEでは「人単位」での認証が可能になります。

認証方式	検証するのは…	なぜ検知できない？
SPF	送信元IPアドレス	z-mail1から出ていればOKと判定される
DKIM	ドメインに対応する署名（ドメイン単位）	同じ秘密鍵で署名できていればOKと判定される
S/MIME	個人ごとの電子署名（証明書）	← これがあれば、人単位の識別が可能！

設問５

[S/MIMEの調査と実施策]について答えよ。

表4中の下線⑨の電子署名データの作成方法を、25字以内で答えよ。

【不備により設問5(1)～(3)は成立しない。】

表4中の下線⑩のハッシュ値aを取り出す方法を、20字以内で答えよ。

【不備により設問5(1)～(3)は成立しない。】

表4中の下線⑪について、どのような状態になれば改ざんされていないと判断できるかを、25字以内で答えよ。

【不備により設問5(1)～(3)は成立しない。】