令和6年度 秋期 情報処理安全確保支援士試験 午後 問2｜情報処理安全確保支援士で学ぶ、なりすましメール対策の事例：SPF・DKIM・DMARCとドメイン名変更の落とし穴

この記事で扱うセキュリティ事例

• 試験区分: 情報処理安全確保支援士

• 出典: 令和6年度 秋期 情報処理安全確保支援士試験 午後 問2

• 主なテーマ: 送信ドメイン認証（SPF・DKIM・DMARC）、なりすましメール対策、ドメイン名変更とメールサービス移行、エンベロープFromとヘッダーFromの整合（アライメント）、メーリングリストとARC

この記事は「情報処理安全確保支援士 午後問題 全70問」シリーズの1本です。→ 全70問の一覧・テーマ別索引はこちら

導入: なぜこの事例が重要なのか

「自社をかたるメールが顧客に届いている」――情報処理安全確保支援士試験のこの事例は、多くの企業が現実に直面しているなりすましメール（送信元を偽装したメール）の問題を、技術と経営の両面から学べる教材です。

この記事では、社名変更にともなうドメイン名（インターネット上の住所にあたる名前。ここでは `a-sha.co.jp` のような文字列）の切り替えを題材に、SPF・DKIM・DMARCという3つの送信ドメイン認証技術が、なぜ必要で、どう組み合わさり、どこで壊れるのかを、ひとつのセキュリティインシデント事例として読み解いていきます。試験対策として設問の考え方を押さえたい受験者にも、自社のブランドと顧客を守る視点がほしい経営者・管理職にも役立つ内容を目指します。

専門用語が多いテーマですが、初めて出てくる用語はそのつど平易に補足します。「メールはなぜ簡単に偽装できるのか」を一度理解すると、ニュースで聞くフィッシング（偽メールで情報を盗む詐欺）の話が一気に立体的に見えてくるはずです。

インシデントの概要

舞台となるのは、従業員1,000名の工作機械製造会社A社です。技術力が高く評価されている会社で、社内には総務部、営業部、情報システム部、技術部、製造部があります。

A社のWebサイトでは、一般向けにIR情報（投資家向けの経営・財務情報）や関連会社へのリンクを、顧客向けには自社製の工作機械を管理するためのアプリケーションプログラムと、その不具合を直す「ソフトウェア修正プログラム」を提供しています。つまり顧客は、A社のサイトからプログラムをダウンロードして自分の設備に適用することが日常的に行われている、という関係です。さらにA社は電子メールを使って顧客と見積書や注文書をやり取りし、業界のニュースサイトのメールマガジンにも登録しています。

ところが、ある時期から不穏な報告が相次ぐようになります。「A社のドメイン名をかたったメールが届いている」という連絡が、多くの顧客から、しかも毎週2通程度という決して小さくない頻度で寄せられるようになったのです。

情報システム部長は危機感を抱きます。A社の名前を信用している顧客が、偽のメールにだまされて金銭や情報をだまし取られれば、被害は顧客に及ぶだけでなく、A社のブランドそのものが傷つく。メールのなりすまし対策は、もはや「いつかやる」課題ではなく「いま着手すべき」課題でした。

ここに、もうひとつの事情が重なります。A社は3か月後にZ社へ社名を変更する予定で、それに合わせてドメイン名も `a-sha.co.jp` から `z-sha.co.jp` へ切り替えることが決まっていたのです。なりすまし対策と、ドメイン名変更にともなうメール基盤の刷新。この2つを同時に進める難しいプロジェクトが、情報システム部のN主任とEさんに託されました。

何が起きたのか

まず2人が直視しなければならなかったのは、「なぜA社のなりすましメールがこれほど簡単に作られてしまうのか」という根本でした。

電子メールには、実は「差出人」を名乗る場所が二重に存在します。ひとつはエンベロープFrom（封筒の差出人にあたり、配送制御に使われる `MAIL FROM` のアドレス）、もうひとつはヘッダーFrom（受信者が画面で目にする「From:」の表示）です。郵便でたとえれば、封筒に書かれた差出人と、便箋の冒頭に書かれた署名のようなもので、この2つは技術的には自由に食い違わせることができます。だからこそ、第三者が「A社」を名乗るメールを作るのは容易だったのです。

A社の当時のメール環境も、移行の障害になりました。社内のメールサーバはS社の権威DNSサービス（ドメイン名と各種設定を世界に公開する仕組み。以下Sサービス）を使ってドメインを管理し、WebサイトはW社のWebサービスで提供されていました。しかしこのメールサーバは、複数のドメイン名のメールを同時に受信できないという制約を抱えていました。社名変更で `a-sha.co.jp` と `z-sha.co.jp` の両方をしばらく併用する必要があるのに、それができない。N主任とEさんは、商用のメールサービスへ移行する判断を下します。選ばれたのはU社のメールサービス（以下Uサービス）でした。

次に2人は、なりすまし対策の本丸である送信ドメイン認証の方針を固めます。柱は3つの技術です。

ひとつ目はSPF（Sender Policy Framework。「このドメインのメールは、これらのIPアドレスからしか送られない」とDNSで宣言し、受信側がエンベロープFromのドメインと送信元IPを照合する仕組み）。ふたつ目はDKIM（DomainKeys Identified Mail。メールに電子署名を付け、受信側がDNS上の公開鍵で署名を検証することで、改ざんと送信元を確かめる仕組み）。そして3つ目がDMARC（Domain-based Message Authentication, Reporting and Conformance。SPFやDKIMの結果に加えて、それらの認証ドメインと、利用者が実際に目にするヘッダーFromのドメインが一致しているか――この「整合」をアライメントと呼びます――を確認し、合わなかったメールをどう扱うかを送信側が宣言できる仕組み）です。

ここが事例最大のポイントでした。SPFはエンベロープFromを、DKIMは署名したドメインを見ます。しかし利用者が信じるのはヘッダーFrom。だから、たとえSPFやDKIMが「成功」しても、その成功したドメインが画面表示のヘッダーFromと食い違っていれば、なりすましを防いだことにはなりません。DMARCはこの隙間を埋めるために、ヘッダーFromとの整合を要求するのです。

2人は送信側・受信側それぞれの方針を整理しました。送信側では、エンベロープFromもヘッダーFromもZ社ドメインにそろえ、DKIM署名を付け、認証に失敗したメールの扱い（DMARCポリシー）を宣言し、そのレポートを分析する。受信側では、SPFかDKIMのどちらかが成功すればDMARCを成功と判断して受信し、相手のDMARCポリシーに従って受信・隔離・拒否を行う、というものです。

移行は慎重に段階を踏む計画でした。試行期間としてまず総務部と情報システム部だけがZ社ドメインを使い、この1か月間のDMARCポリシーは「特定のアクションを要求しない」=監視に徹する。その後、旧メールサーバの利用をやめて全社をUサービスに移し、ポリシーを段階的に「隔離」、半年後にはさらに「拒否」へと厳しくしていく。最後に旧A社ドメイン宛メールの受信を止め、メールサーバ用のDNSレコードを削除する。いきなり拒否にして正規メールまで弾く事故を避ける、現実的な進め方です。

この計画の途中、N主任とEさんは「旧ドメインをどうするか」という、見落とされがちな論点にも向き合いました。社名が変われば `a-sha.co.jp` は不要に見えます。しかし契約を解約すれば、そのドメインは誰でも再取得できる状態になります。もし悪意ある第三者がA社ドメインを手に入れたら何が起きるか。見た目がそっくりの偽Webサイトを立て、配布物のコンテンツを細工して顧客に害を与える。A社ドメインを送信元にしたなりすましメールを大量に送る。さらに、従業員が社外サービスにA社ドメインのメールアドレスを登録したまま連絡先を変え忘れていれば、第三者がそのアドレス宛のメールを受信し、パスワード再設定の通知を盗んでアカウントを乗っ取る――2人はこうした悪用の具体例を洗い出し、結論としてA社ドメインの契約を継続することにしました。使わないドメインこそ、廃止後の悪用に備えて手放さずに管理し、SPFレコードで「このドメインからのメールはすべて失敗扱いにせよ」と宣言しておく。これが、攻撃者に再利用の余地を与えないための守りでした。

ところが、全社移行のさなかで現場から相談が舞い込みます。営業部のHさんは、社内外への一斉配信メール（外部のTサービスを使う計画）が「移行後に届かなくなるのでは」と不安を訴えました。さらに2週間後には技術部のJさんから、製品情報を交換するメーリングリスト（外部のYサービスを使う計画）について同じ相談が持ち込まれます。

ここで、せっかく整えた送信ドメイン認証が、転送系のサービスを通すと壊れるという、この事例の核心が姿を現します。メーリングリストやメルマガ配信は、いったんメールを受け取って加工し、登録者へ送り直します。その過程でヘッダーFromやSubjectが書き換わると、SPFやDKIMの整合が崩れ、認証に失敗してしまうのです。N主任は、Subjectに通番（連番）を付加する設定を選ぶと、DKIMの署名対象が変わって検証が失敗し、メールが届かなくなる場合があることを見抜き、設定の組み合わせを慎重に指定しました。最終的に、ヘッダーFromもSubjectも書き換えない組み合わせを採用することで、移行は順調に完了します。