令和元年度 秋期 情報処理安全確保支援士試験 午後Ⅰ 問1｜なりすましメールはなぜ防ぎきれないのか——情報処理安全確保支援士で学ぶSPF・DKIM・DMARCの実例

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

• 試験区分: 情報処理安全確保支援士
• 出典: 令和元年度（2019年）秋期 情報処理安全確保支援士試験 午後Ⅰ 問1
• 主なテーマ: 送信ドメイン認証（SPF / DKIM / DMARC）、なりすましメール、Envelope-FROMとHeader-FROM、メール転送によるSPF認証の失敗、類似ドメインによるなりすまし

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

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

取引先から届いた一通のメール。差出人の名前も、メールアドレスのドメインも、いつもと同じに見える。だからあなたは疑いもせず添付ファイルを開き、本文に書かれた振込先口座を信じてしまう——。ビジネスメール詐欺（BEC）や標的型攻撃の入口は、たいていこんなに静かです。

情報処理安全確保支援士試験の午後Ⅰで出題されたこの事例は、まさにその「なりすましメール」に企業がどう立ち向かうかを正面から扱っています。主役になるのは、SPF・DKIM・DMARCという三つの送信ドメイン認証技術（メールの差出人ドメインが詐称されていないかを受信側で検証する仕組み）です。名前は聞いたことがあっても、「結局それぞれ何を検証していて、何を防げないのか」を正確に説明できる人は意外と多くありません。

この記事を読むと、SPFがIPアドレスを、DKIMが電子署名を、DMARCがその両方の結果とメールの整合性を、それぞれどう確かめているのかが整理できます。さらに、これだけ対策を重ねても「取引先にそっくりな別ドメイン」を使われると防げないという、認証技術の根本的な限界も見えてきます。受験者にとっては頻出論点の総まとめになり、メールを業務の生命線とする経営者にとっては「自社のドメインは他人に詐称され放題になっていないか」を点検する判断軸になるはずです。

インシデントの概要

舞台は、従業員数500名の情報サービス事業者であるN社です。N社の情報システムは、インターネットとの境界にファイアウォール（FW）を置き、DMZ（社内ネットワークとインターネットの中間に設けた緩衝地帯）にプロキシサーバ、外部DNSサーバ、外部メールサーバを配置した、ごく標準的な構成でした。社内には内部メールサーバと内部DNSサーバがあり、運用は情報システム部——社内では「情シ部」と呼ばれます——のQ部長とU主任を含むわずか5名で回していました。

各PCやサーバには脆弱性修正プログラムが自動で適用され、マルウェア対策ソフトの定義ファイルも自動更新される。外部メールサーバではスパムメールフィルタも動いている。基本的な衛生管理は行き届いていたといってよいでしょう。N社は「n-sha.co.jp」というインターネットドメイン名を取得し、これを社員のメールアドレスのドメインにも使っていました。

平穏に見えたこの環境に、外から一つの問題意識が持ち込まれます。きっかけは、N社が所属する業界団体での出来事でした。会員企業の間で、なりすましメールによる攻撃の被害が現実に発生していたのです。メールを悪用して企業秘密や金銭をだまし取る——そうした攻撃を少しでも抑えるため、業界団体は「送信者メールアドレスが詐称されていないかをドメイン単位で確認する技術（送信ドメイン認証技術）を普及させよう」と会員各社に働きかけました。これを受けて、N社でも情シ部が中心となり、送信ドメイン認証技術の導入を検討することになったのです。

つまりこの事例は、実際に大きな被害を受けてから慌てる話ではありません。「業界全体でなりすましが起きている。次は自社かもしれない」という危機感から、被害が出る前に守りを設計していく——予防と制度設計の物語です。

何が起きたのか

検討は、Q部長とU主任の会話から始まりました。「当社でも送信ドメイン認証技術を使うべきだと経営陣に報告したい。まずは、どの技術を使うかを検討しよう」。Q部長のこの一言が、二人の長い調査の起点になります。

最初に二人が向き合ったのは、そもそも「送信者メールアドレス」とは何を指すのか、という根本的な問いでした。メールには、実は差出人を示す欄が二つあります。一つはEnvelope-FROM。これはSMTP（メールを送受信するための通信手順）の「MAIL FROM」というコマンドで指定されるアドレスで、配送エラーが起きたときに通知メールが返される宛先になります。郵便でいえば封筒の裏に書く差出人です。もう一つはHeader-FROM。これはメールデータの中のヘッダに書かれるアドレスで、受信者の画面に「差出人」として表示されるもの。便箋の本文に書かれた署名にあたります。通常、社員がPCからメールを送るときは両者とも自分のアドレスになりますが、この二つは技術的には別々に設定できてしまう。ここが、なりすましの温床になります。

U主任は、利用候補となる三つの技術を整理しました。SPF、DKIM、DMARC。いずれも標準化されており、N社の外部メールサーバではどれも利用可能だといいます。Q部長は、攻撃のパターンを二つ示し、各技術がそれぞれの攻撃の対策になるかをまとめるようU主任に指示しました。

一つ目の攻撃は、N社の取引先のメールアドレスを送信者に設定したメールを、攻撃者のメールサーバからN社へ送りつけるもの。取引先になりすまして、N社の社員をだます攻撃です。二つ目は逆に、N社のメールアドレスを送信者に設定したメールを、攻撃者のメールサーバから取引先へ送りつけるもの。N社になりすまして取引先をだます——N社のブランドが踏み台にされるパターンです。

U主任はまず、SPFに絞って検証を進めました。SPFは「送信元のIPアドレスが正当かどうか」を確かめる技術です。送信側はあらかじめ、自社の正規メールサーバのIPアドレスをDNSサーバにSPFレコードとして公開しておきます。受信側はメールを受け取ったとき、Envelope-FROMのドメインのDNSに問い合わせ、「このメールを送ってきたサーバのIPアドレスは、そのドメインが認めた正規のIPか」を照合する。ここで二人が突き当たったのは、ある単純で、しかし見落とされがちな事実でした。SPFが詐称を見抜けるのは、「送信者側のドメインがSPFレコードをDNSに公開している」ことと、「受信側のメールサーバが受信時にSPF検証を実施している」ことの、両方が同時に揃ったときだけだ、ということです。

どちらか一方でも欠ければ、SPFは沈黙します。送信者側が公開していなければ、受信側は照合する基準を持てない。受信側が検証しなければ、いくら公開されていても確かめようがない。U主任が整理した一覧表のうち、この「公開済み」かつ「検証実施」の条件を、攻撃の向きに対して正しく満たしていたのは、わずか一通りの組み合わせだけでした。残りはすべて、SPFが効かない=詐称されているかを「判断不可」だったのです。攻撃者のサーバからN社へ取引先を騙って送りつける一つ目の攻撃に至っては、ほとんどの場合でSPFは無力に近い。対策を「導入した」だけでは安全にならない——その現実が、表の上に冷たく並びました。

さらにU主任は、SPFの構造的な弱点にも気づきます。送信側のDNSと受信側のメールサーバが両方ともSPFに対応していても、その途中で、Envelope-FROMを書き換えずにメールを中継・転送する別のメールサーバが挟まると、受信側のSPF認証は失敗してしまうのです。理由はSPFの仕組みそのものにあります。受信側が照合するのは「いまSMTPで接続してきたサーバのIPアドレス」。ところが転送が挟まると、接続元IPは元の正規サーバではなく転送サーバのIPになる。SPFレコードに登録された許可IPと一致せず、正規のメールなのに「不正」と判定されてしまう。正しいメールが弾かれるという、運用上やっかいな副作用でした。

次にDKIMの検討に移ります。DKIMは、メールに電子署名を付ける技術です。送信側は公開鍵と秘密鍵のペアを作り、公開鍵をDNSサーバに登録しておく。メールを送るときは、本文とヘッダをもとに秘密鍵で署名を計算し、DKIM-Signatureというヘッダに付けて送ります。受信側は、署名に書かれたドメイン名をもとにDNSから公開鍵を取り寄せ、受け取ったメールの本文とヘッダから自分でハッシュ値を計算し直して、署名が正しいかを検証する。ここでU主任は重要な点に触れます。DKIMが確認できるのは、送信元が正当であることだけではない。署名は本文とヘッダをもとに作られているため、「メールの本文やヘッダが途中で改ざんされていないか」までわかるのです。しかもSPFと違い、転送サーバが本文を書き換えさえしなければ、転送されても検証は通る。SPFの弱点を補える性質でした。

最後にDMARCです。DMARCは、SPFとDKIMの検証結果を受けて、認証に失敗したメールをどう扱うか——何もしない、隔離する、拒否する——という方針（ポリシ）を、送信側がDNSで宣言しておく仕組みです。さらにDMARCは、SPFやDKIMで検証したドメインと、受信者の目に映るHeader-FROMのドメインが整合しているかまで確かめます。SPFはEnvelope-FROMを、DKIMは署名のドメインを見ますが、利用者が実際に「差出人」として見るのはHeader-FROMです。この三者を突き合わせて初めて、「表示されている差出人」へのなりすましに網がかかる。SPFとDKIMという二つの部品を、利用者視点で束ねる司令塔——それがDMARCでした。

検討結果を経営陣に報告したところ、N社はSPF・DKIM・DMARCをすべて導入することを決め、情シ部が作業に着手します。そしてここで、新たな事情が持ち上がりました。N社の営業部が、取引先向けにニュースレターを配信する計画を立てたのです。配信にはX社のクラウド型メール配信サービスを使う。メールはX社のメールサーバから送られ、Header-FROMにはN社ドメインのアドレス（letter@n-sha.co.jp）を、Envelope-FROMにはN社のサブドメインのアドレス（letter@a-sub.n-sha.co.jp）を設定する——。自社のサーバではなく、外部サービスから自社ドメイン名義でメールを送る。これは現代のメール運用でごく当たり前の構成ですが、送信ドメイン認証の観点では、設定を一つ間違えると正規のニュースレターが認証に失敗して隔離される、という落とし穴をはらんでいました。N社は、このニュースレター配信についても三つの認証技術を正しく効かせるべく、追加のDNSレコードを設計していきます。