ネットワークスペシャリスト試験 令和6年度 春期 午後2 問2
【出典：ネットワークスペシャリスト試験 令和6年度 春期 午後2 問2（一部、加工あり）】
[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）の導入が有効であることが分かった。
【ネスペR6午後2問2】徹底解説！(4) ～委託先のメールセキュリティ、落とし穴はどこだ？～
これまで、SPFとDKIMという強力な送信ドメイン認証技術を学んできました。しかし、理論は実践で試されてこそ真価が問われます。今回は、Y社がサポート業務を専門会社のZ社へ委託するという、極めて実践的なシナリオです。
自社のセキュリティは万全でも、サプライチェーン（取引先や委託先）が絡むと、新たな課題やリスクが生まれます。X主任と一緒に、この難問に挑んでいきましょう！
✅ シナリオの確認：Z社に委託する際のメール運用
まずは、X主任がまとめたZ社への業務委託時のメール運用方法を整理します。
- 送信元アドレス: Z社のサポート担当者も、Y社の公式窓口である support@y-sha.com を送信元アドレスとして使用する。
- メール送信経路: Z社の担当者が送信したメールは、Z社の社内メールサーバ → メール中継サーバZ (z-mail1) を経由して顧客に届けられる。
- セキュリティ要件: Y社のドメイン (y-sha.com) を使う以上、Y社のセキュリティ運用規定に従い、SPFとDKIMによるなりすまし対策を講じる必要がある。
この要件を満たすために、Y社とZ社はどのような設定をすべきでしょうか？【設問4】で見ていきましょう。
💡【設問4】サプライチェーンに潜むセキュリティリスクを解き明かす
【設問4】は、Z社からのメール送信にSPFとDKIMを正しく適用し、そこに潜む限界を見抜く問題です。
(1) SPF対応：Z社からの送信を許可するには？
【問題】 本文中の下線⑥について、登録する DNSサーバ名及びDNS サーバに登録する情報を、それぞれ、図1又は図6中の字句を用いて答えよ。
【解答】
DNSサーバ名: 外部DNSサーバY / y-ns1
登録する情報: メール中継サーバZのIPアドレス / z-mail1のIPアドレス
【解説】 Z社から y-sha.com のメールが送信されても、顧客側で「なりすましではない」と判断してもらう必要があります。そのためには、y-sha.com のSPFレコードに、Z社のメールサーバを「正規の送信元」として追加登録しなければなりません。
- どのDNSサーバに登録する？: SPFレコードは、検証対象ドメインの権威DNSサーバに登録します。今回検証されるドメインは y-sha.com です。このドメインを管理しているのは、図1にあるY社の外部DNSサーバY (y-ns1) です。
- 何を登録する？: SPFレコードに登録するのは、正規の送信元サーバのグローバルIPアドレスです。Z社から送信されるメールは、最終的にメール中継サーバZ (z-mail1) からインターネットに出ていきます。したがって、この z-mail1 のグローバルIPアドレス（図7より 222.c.d.1）を、Y社のSPFレコードに追加する必要があります。
(2) DKIM対応：誰のドメインとして署名する？
【問題】 本文中の (j) に入れる適切な字句を答えよ。
【解答】 y-sha.com
【解説】 Z社のメール中継サーバでDKIMの署名を行う際、DKIM-Signatureヘッダーの dタグ（電子署名を行ったドメイン名を示すタグ）に何を指定すればよいか、という問題です。
受信側のメールサーバは、dタグで指定されたドメインのDNSサーバに、署名検証用の公開鍵を問い合わせに行きます。
今回、送信元メールアドレスは support@y-sha.com であり、受信者に「Y社からの正規のメールである」と証明したいわけです。そのためには、受信者がY社のDNSサーバに公開鍵を問い合わせるように仕向ける必要があります。
したがって、dタグにはy-sha.com を指定します。これにより、受信者はY社の外部DNSサーバを参照し、正しく署名を検証できるのです。
(3) 鍵を分けるメリット：リスクを限定せよ！
【問題】 本文中の下線⑦について、異なる鍵を利用することによる、Y社におけるセキュリティ面の利点を、50字以内で答えよ。
【解答】 メール中継サーバZから鍵が漏えいしても、Y社で実施中のDKIMの処理は影響を受けない。
【解説】 この問題は【採点講評】で「正答率が低かった」と指摘されています。セキュリティの重要な原則「影響範囲の限定」が問われています。
X主任は、Z社で使うDKIMの鍵をY社で使う鍵とは別にし、セレクターも sel.zsha として区別することにしました。なぜこのような面倒なことをするのでしょうか？
【採点講評】のヒントを見てみましょう。
鍵の漏えい時に発生する影響を基に、影響の具体的な内容を導き出してほしい。
もし、Y社とZ社で同じ秘密鍵を共有していた場合、万が一、Z社からその秘密鍵が漏えいするとどうなるでしょうか？攻撃者はその鍵を使って、Y社のドメイン (y-sha.com) を完璧に詐称したメールを自由に作成できてしまいます。Y社自身のメールサーバから送るメールの信頼性まで、根底から揺らいでしまうのです。
しかし、鍵を分けていれば、Z社用の鍵 (sel.zsha の鍵) が漏えいしても、その影響はZ社から送信されるメールだけに限定されます。Y社が自社サーバで使っている鍵 (sel.ysha の鍵) は安全なままなので、Y社本体のメール送信の信頼性は保たれます。
このように、鍵を分離することでリスクを局所化し、万一のインシデントにおける被害を最小限に食い止めることができます。これが大きなセキュリティ上の利点です。
(4) SPF/DKIMの限界：W課長の鋭い指摘
【問題】 本文中の下線⑧について、顧客のメールサーバでは、なりすましを検知できない理由を、40字以内で答えよ。
【解答】 なりすましメールも、メール中継サーバZから社外に転送されるから
【解説】 これも【採点講評】で「正答率が低かった」と指摘された、本設問の核心を突く問題です。
X主任の対策を聞いた上司のW課長は、「Z社のサポートチームY以外の従業員がなりすました場合、検知できない」と指摘しました。なぜでしょうか。
SPFとDKIMは、あくまで「サーバの正当性」を検証する技術です。「そのサーバを誰が使ったか」までは検証できません。
Z社のネットワーク構成（図6）を見てみましょう。
- サポートチームYのPCも、サポートチームAのPCも、同じ社内ネットワークに接続されています。
- どちらのPCからメールを送っても、最終的には同じメール中継サーバZ (z-mail1) を通って外部に送信されます。
- SPF認証でチェックされる送信元IPアドレスは、z-mail1 のものです。
- DKIM署名も、この z-mail1 で行われます。
つまり、Z社のサポートチームAの悪意ある従業員が、送信者名を「サポートチームYの担当者」、送信元アドレスを support@y-sha.com に偽装してメールを送ったとしても、顧客のメールサーバから見れば、正規の経路（IPアドレス）から送られ、正しくDKIM署名されたメールにしか見えません。
これがSPF/DKIMの限界であり、W課長が指摘した「検知できないなりすまし」の正体です。
まとめ
今回は【設問4】を通して、業務委託という実践的な場面でのメールセキュリティの難しさを学びました。
- 委託先から自社ドメインのメールを送る際は、SPFとDKIMの設定を委託先にまで拡張する必要がある。
- DKIMの鍵を委託先と自社で分離することは、リスクを限定し、漏えい時の影響を最小化するために極めて重要である。
- SPF/DKIMは「サーバ認証」であり、「送信者（人間）の認証」ではない。そのため、正規のサーバを踏み台にした「内部のなりすまし」は検知できない。
このW課長の鋭い指摘により、新たな課題が浮き彫りになりました。この課題を解決するために、X主任は次の対策「S/MIME」の調査へと進みます。
次回はいよいよ最終回！【設問5】で、メールに送信者個人の電子証明書を付与するS/MIMEの仕組みを解き明かします。お楽しみに！