Webのセキュリティに関しては昨今SWG・SASE・CASBといったトピックが飛び交う一方で、メールに関してはあまり取り上げられないことが多いように感じます。しかし実際にはIPAが毎年公表している情報セキュリティ10大脅威からもわかるように、セキュリティインシデントの多くはメールを発端に起こっているのが現状です。
フィッシングやランサムウェアもメールを介して流入してくるケースがあります。メール環境を守ることが重要であるのは理解されているとは思いますが、実際にメールセキュリティ対策は難しいと感じている管理者も多くいるのではないでしょうか。
本稿ではメールセキュリティ対策、とりわけSPF・DKIM・DMARCといった仕組みの利用においてどういった点が難しいのかを例を挙げて解説しつつ、今取り組むべき対策について記していきます。
※記事中の統計データは2023年8月時点のものです。ご了承ください。
メールの対策は被害に遭わない対策と被害に遭わせない対策が必要
メールは送信と受信がある双方向のコミュニケーションツールですが、その両方をしっかりと分けて考えないと話が不明瞭になってきます。昨今では「DMARCを導入すべし」と言葉は聞くかもしれませんが、それは送信側の対策なのか受信側の対策なのか、分けて考えないと対策は施せません。
「送信」といっても自身が送信するメールだけでなく、自身を騙る悪意のあるメール（なりすまし）の対策も必要となります。そして、受信の対策、すなわち悪意のあるメールを受信しないことも、結果として、なりすましメールの対策になることを説明していきます。
送信側の対策が必要な理由の1つの代表例がフィッシングメールです。自社や自社サービスのドメインを騙ってメールが送信されてしまい一般ユーザに被害に合わせてしまうということ、それを防止することが必要になります。フィッシングメール対策については昨今では政府もその対策を呼び掛けています[i]。
メールセキュリティ対策は急ぐべきなのか様子見るべきなのか
メールは50年ほど前の1971年に発明されたものとされています。実はそこから様々な規約が加えられていきましたが、普及しないものも数多くありました。例えば、メールの暗号化となりすまし防止を実現するS/MIMEも、一部の企業では用いているかとは思いますが実際には役に立つのを実感するほどには普及はしていません。
そんな経緯を経た今、メール送信者の妥当性（本人確認）をできる仕組みは無いのが実状です。道半ば（というと語弊があるかもしれませんが）の規格、SPF・DKIM・DMARCといったものがありますが、それらは今すぐに100％の効果を期待できる仕組みではありません。S/MIMEが普及しなかったのと同様に現時点では普及率がまだ不足しており、結果としてメールの認証規約として使えないのが現実です。しかし普及してなさそうだから対策する必要はないと考えるのは誤りです。
Proofpoint社が行った調査[ii]では、日本は「なりすましメール詐欺」の対策が調査対象の18か国の中で最下位であると判明しています。この結果は上記の「一般普及していないから入れても現時点では意味がない」といった考えによるものと思われます。
日本では業務影響、すなわち正当なメールを誤って悪意のあるメールとして誤遮断するリスクを懸念してしまうことが多いからです。しかし誤遮断のリスクの低い導入から始めて段階的アプローチをとる方法があります。後述するSPF・DKIM・DMARCといったなりすましメール対策をよく理解すると、誤遮断のリスクを軽減しながら導入することが可能です。
また、悪意のあるメールを送る攻撃者は、対策が遅れているドメイン（メール送信アドレス）を利用するということに注目しなければなりません。日本ではなりすましメール対策が遅れていると述べましたが、大手のECサイトなどでは対策がとられている一方で、東証上場企業でも現時点ではなりすましメール対策はまだ導入が始まったばかりです。攻撃者は対策が取られている企業ではなく、そうした対策が取られていない有名な企業を騙ってなりすましメールを送るようになります。このレポートをご覧いただいている貴社のドメインも攻撃者の標的になっている可能性があります。
対策の遅れが標的とされるまでの流れ
SPF・DKIM・DMARCの導入率
本節では、なりすましメール対策の仕組み（用語）と普及率を説明いたします。なお、普及率については最新のものを把握することが適切ですが、前述のとおり、送信の対策なのか受信の対策なのかが明確ではない記事もありますので注意して理解するようにしてください。
送信側の対策
まず送信側の対策ですが、基本は「自分の送るメールが正当であると主張すること」になります。下記の3つの方法があります。
- SPF：どのIPアドレスから送信されたら正当であるかを示す
- DKIM：メール1通1通に「署名」をつけ、改ざんされていないことを示す
- DMARC：SPF/DKIMをチェックしてもらい正当ではなかった場合にどうしてほしいかを示す
それぞれの詳しい説明についてはいくつか参考サイトを最後に記します[iii]のでそちらに譲ります。
そして普及率については下記のような記事があります。
日経225企業のDMARC導入率は62.2％で、1年間で12.4％増加[iv]
こちらはDMARCを送信対策として導入している率というものになりますが、今回この記事を書くにあたり実際どのくらい普及しているのか私自身で調査してみました。対象は225企業に限定せず、東証上場3千数百社の調査になります。その対象で調べるとDMARCは14％という普及率でした。大手企業ほど導入率は高いと言えそうです。また導入もいくつかレベルがあり以下の3種類でレベル付けします。
- none：現時点では特に何もしない
- quarantine：なりすましと思われるメールは検疫する
- reject：なりすましと思われるメールは拒否（破棄）する
先に紹介したガイドラインではrejectにまでもっていくのが推奨されていますが、今回調査した結果ではrejectは1%にも満たないという状況でした。
東証上場企業のDMARC登録状況（本稿独自調査結果: 調査日2023年8月）
| DMARCポリシー | 割合 |
| none | 10.50％ |
| quarantine | 2.75％ |
| reject | 0.72％ |
| DMARC登録なし | 86.03％ |
DMARCは大手企業で潤沢に予算がなければできないというものではなく、設定だけであれば簡単なところから始められます。
DMARCの導入についてはSPFまたはDKIMが導入されていることが必要になります。DKIMの導入は容易ではないため普及率はまだ低く、上記東証上場企業の調査では1割に満たないことがわかりました。一方でSPFは導入は簡単で9割を超えています。繰り返しになりますが、SPFまたはDKIMが導入されていればDMARCを設定できるため、9割を超える企業ドメインでDMARCを設定できる状況にあるということになります。誤遮断のリスクなど難しい話をしてしまうと導入障壁が高くなってしまいますが、noneの設定であればそういった懸念はないため、まずはnoneから設定していくのが良いと思われます。
受信側の対策
次に受信側の対策、すなわち上記のSPF・DKIM・DMARCのチェックを行い、不審なメールを検疫または拒否する対策です。
こちらは送信の対策よりもぐっと普及率が下がります。前述のProofpoint社の調査は日経225企業における受信の対策を調べたものになりますが仕組みの導入まででも31%、実際に検疫や拒否の運用をしているのは6%という結果になっています。受信の対策は正直なところ送信ほど簡単にはいきません。どうしても誤遮断というデメリットが生じてしまうためです。われわれも業務とセキュリティの両立（バランス）を心に置いてお客様にアドバイスさせていただくことが多く、そうなると「いますぐ遮断運用しましょう」とは言えないのが現実です。
しかし、遮断する仕組みが無ければ常に攻撃のリスクにさらされている状況となっています。大手メールサービスではSPF・DKIM・DMARCの結果を反映し、迷惑メール扱いする仕組みが整いつつあるため、読者の皆様におかれましても今後のメール運用についてご検討されるのが良いかと思います。
メールセキュリティ対策の難しさの例
これまでフィッシングメールの対策について話をしてきましたが、具体的にフィッシングはどのような情報を詐称しているのでしょうか。
メールの「送信者」は様々なものがあります。
- Ａ）SMTPプロトコル上の「送信者」（いわゆるエンベロープFrom）
- Ｂ）メールヘッダ上の「送信者」（いわゆるヘッダFrom）
- Ｃ）メールヘッダ上の「Reply-to」
- Ｄ）再送しているメールアドレス(Resent-Sender)
これらのうち、最も詐称されやすいのが、ユーザが目にするB)（ヘッダFrom）です。一方で、詐称する目的ではなく、意図的にA)やB)が異なるメールを送ることがあります。例えばメルマガの送信においては送信事業者にエラーメールを処理させたい、でも"From"は自社のドメインにしたいという場合にあえてA)を送信事業者のものB)を自社のものにすることをします。他のケースとして同報アドレスを用いている場合、D)とB)は別になります。
先に記したSPF,DKIM,DMARCはどの「送信者」をチェックしているのか。答えは「それぞれ全部違う」になります。DMARCはフィッシングメール対策としての役割をもっているため前述のユーザが一番送信者と思う（攻撃者が騙そうとする）B)ヘッダFromをチェックします。しかしSPFはA)エンベロープFromをチェックする仕組み、DKIMは上記A～Dのどれでもない仕組みになります。
先にDMARCはSPFまたはDKIMのチェック結果を利用すると説明しましたが、そもそもチェックしている"From"がそれぞれ別のものであるということです。これは先ほど例をあげたA)とB)が別になるケースだと正しくDMARCの結果が得られないということを示しています。
メールセキュリティ対策の段階的アプローチ
先に記した通り、日本ではメールセキュリティ対策はこれからといった状況ですが、既に悪意のあるメールが送られてきている以上、できることからやっていくことが重要です。導入には長い時間がかかるため、難しいからといって対策を後手にまわすと、遅れを挽回するためにさらなる難しい局面を迎えてしまいます。
簡単な紹介となりますが、「送信対策」「受信対策」それぞれについて、どのようなステップを踏んで導入していけるのかについて記載しておきます。
送信対策
１）まずはSPFとDMARCの定義を行う
SPFは前述の東証上場企業の調査では9割ほどの企業で導入できています。であるならばまずはDMARCを定義することが可能です。DMARCのポリシーを"none"でまずは導入します。"none"であれば誤遮断のリスクはありません。
２）DMARC対応のレベルアップ
２－１）SPF判定NGとなるケースをつぶしていく
送信元IPアドレスが特定できないメール送信を構成変更していき、すべてのメール送信のIPアドレスを網羅し、遮断可能とすることを目指します。SPFの記載ではDNSに"-all"と宣言することで開示したIPアドレス以外からのメールは存在しないという宣言になりますが、そこが目標です。ちなみに-allできている東証上場企業は18%程度でした。
２－２）エンベロープFromとヘッダFromの共通化
前述の通りDMARCはヘッダFromを、SPFはエンベロープFromをチェックしているという違いから、エンベロープとヘッダが違う場合にはSPFがOKでもDMARCがOKとなりません。つまり、エンベロープ情報をヘッダ情報に合わせていくというのがまず求められるアプローチになります。
安易な理由・メール送信設計をあまり考えずに適当なエンベロープFromで実装してしまったメールなどはよく見かけます。そうした場合はエンベロープ情報をヘッダ情報に合わせていく改修をします。
２－３）DKIMの導入
DKIMを利用する場合、DKIMの改ざん防止機能を利用したり、送信元IPアドレスが固定化できない場合にDMARC対応させることが可能なケースがあります。また２－２に記したエンベロープFromとヘッダFromの共通化ができない場合にもDKIMを利用することができます。DKIMではチェックするドメイン情報をヘッダ情報に埋め込むため、DKIM情報とヘッダFromと合わせることができるためです。
DKIMは、SPF対応の補完として進めていく形になることが多いです。最初は全てのメール送信システムを対応させることは難しいですが、メール全体のグランドデザインを行いメール送信経路の統一をしていけば可能になります。
DKIM対応のメールグランドデザイン例
３）ポリシーの見直し
前述の通りDMARCにはnone・quearantine・reject、SPFも-all・~allというポリシーのレベルがあります。最初はDMARCでいえばnoneから始めて、上記２）の対策状況を確認します。正当なメールであるにもかからずDMARCがNGとなっているものがないかの確認はDMARCレポートを活用していくと漏れの気づきとすることができます。
脚注の参考[v]などをご参照ください。そして、送信メールが全て把握でき遮断してもよいという状況になっていたらquarantine,rejectを検討します。
この対策ができている企業は前述の通り日本では少数であり、またnoneからrejectにまで移行させるのに2年はかかるとも言われています。そのため、noneまでは早急にやらないといけないということになります。
受信対策
１）まずは「止められる」下地をつくる
現在のDMARC等の普及状況を鑑みると、すぐにDMARC判定NGのメールをすべてポリシーで遮断することは難しい状況です。そもそもポリシーが"none"（「遮断はしないで！」）と多くのドメインで定義されています。しかし、大手ECサイトなどフィッシングメールの偽装ドメインとして使われやすいドメインほどポリシーが"quarantine","reject"になっているため、それらを見分けられるだけでも効果はあると考えられます。
２）必要に応じて対策強化
MTAの製品によってはDMARCのポリシー如何を問わず（たとえ"none"でも）DMARC判定NGになったメールを検疫するといったことができる製品もあります。DMARCポリシーが"none"になっているドメインを利用して悪意のあるメールを大量流入させられるといった状況を想定し、当該ドメインについてはポリシー関係なく検疫処理するといったことができます。
ポリシーが"none"であるとはいえ、大半の正当なメールはOKとなるような状態になっているでしょうから、その検疫処理を入れたとしても正当なメールが誤遮断されてしまうケースは少ないはずです。「このドメインからのメールは遮断する」は業務影響（正当なメール遮断）的な側面から実現が難しいと思われますが、万一の場合にDMARCで止められる下地づくりが重要です。
おわりに
本稿で解説したメールセキュリティ対策（フィッシングメール対策）は
- 送信対策は着手、段階的アプローチで対策
- 受信対策は（困難が多いが）準備を開始
の2点ですが、同時にその仕組みが難解なものであることも紹介させていただきました。NRIセキュアのSecurePROtechtサービスでは「メールセキュリティ管理サービス」としてProofpoint社の製品を使って、運用を効率的に実施するサービスを提供しています。メールは複雑な仕組みですが、クラウドサービスへの移行もしやすい仕組みです。自社での運用が難しい場合、Proofpoint社のクラウドサービスへの移行をSecurePROtechtサービスでご支援させていただきます。
そして、今でこそ低い日本のDMARC導入率を高めていき、悪意のあるメール送信を社会から排除していく未来に向かっていきたいと考えます。「S/MIMEは普及しなかった、DMARCもそうだろう…」ではなく「今度こそ！」といきたいものです。
[i] 経済産業省 フィッシング対策の強化を要請 https://www.meti.go.jp/press/2022/02/20230201001/20230201001.html
[ii] Proofpoint 日経225企業の69％が「なりすましメール詐欺」に有効な対策ができておらず、調査対象18か国のうち最下位であることが判明
https://www.proofpoint.com/jp/newsroom/press-releases/nikkei225-dmarc-implementation-rathio-2023
[iii] SPF・DKIM・DMARCの参考サイト
RFC： https://tex2e.github.io/rfc-translater/html/rfc7489.html
google社の説明：https://support.google.com/a/answer/2466580?hl=ja
NRIセキュアブログ：https://www.nri-secure.co.jp/blog/how-to-dmarc
Proofpoint社の説明：https://www.proofpoint.com/jp/threat-reference/dmarc
フィッシングの観点での説明：https://www.antiphishing.jp/report/antiphishing_guideline_2023.pdf
[iv] TwoFive 日経225企業のDMARC導入率は62.2％で、1年間で12.4％増加
https://www.twofive25.com/news/20230518_dmarc_report.html
[v] Proofpoint Email Fraud Defense
https://www.proofpoint.com/jp/products/email-protection/email-fraud-defense
