令和6年度 春期 ネットワークスペシャリスト試験 午後II 問題 問2 送信ドメイン認証(SPF/DKIM/S-MIME)の総合設計

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

FWに設定されている静的NATを表1に示す。

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

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

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による送信ドメイン認証の流れを次に示す。

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

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

以下は，設問1で参照されるPTRレコードの形式である。

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