JANOG48ミーティング 企画編成委員の今井です。

プログラム紹介第4弾は、Day2(2021年7月15日木曜日)の15:00からOHGAKIにて行われる「増え続けるフィッシング被害に今、我々ができること」の発表者である櫻庭 秀次さん、平塚 伸世さんにお話を伺いました。

登壇者の櫻庭 秀次さん

今回JANOG48に応募したきっかけについて教えて下さい

櫻庭さん: 今回と同じテーマ(フィッシング対策)について、JANOG45、46、47と登壇させて頂いております。
現在、DNS・メールは既にメッセージ交換において十分に基盤技術となっています。しかしその割には、エンジニアの方を含めて、昨今の動向についてあまり認知されていないように思います。
JANOGはネットワークオペレータの集まりで、低いレイヤを専門としている人が多いのは承知していますが、それより一つ上のレイヤであるDNS・メールも、上記の通り十分に基盤技術と呼べるものになっているため、それらについて周知したく継続してJANOGに応募させていただきました。

平塚さん: 櫻庭さんに声掛けしてもらい、本セッションで登壇させていただく事になりました。
普段はフィッシング対策協議会で窓口をしているのですが、2年前からフィッシングメールの件数が急増してきています。
フィッシングメールはいわゆる迷惑メールと同じであるため、対策としては同じ技術が役に立ちます。つまり、迷惑メール対策として有効な送信ドメイン認証の技術は、フィッシングメールの対策にも有効であるはずです。しかしながら、現在あまり活用されておらず、また対応している組織も少ない現状です。
もし、多くの組織が送信ドメイン認証 DMARCに対応したならば、今あるなりすまりメールの半分以上は防ぐことができるのではないでしょうか。そこで、より多くの組織にDMARCに対応してもらえるよう、メールセキュリティについて周知したく、今回のJANOGでお話をさせていただきます。

ドメイン認証技術DMARCについて簡単に教えて下さい

櫻庭さん: 基本的に、送信者情報(メールヘッダのFROM)のメールアドレスにおけるドメイン部分を認証する技術であり、
これにより、このヘッダのFROMが詐称されていないかを検知できるようになります。
受信側でこれらの検知を行うためには、送信側での設定が必要であり、DMARCの普及には送信側での対応が必要になります。
送信側の設定と受信側の認証により、例えばクレジットカード会社や銀行等になりすましたメールをほぼ検知できるようになります。
またDMARCは単体の技術ではなく、その前段でSPFまたはDKIMという送信ドメイン認証技術のいずれかを利用して認証されたドメインがヘッダのFROMと一致しているかを確認しています。そのため、送信側でSFPまたはDKIMを導入して頂き、さらにDMARCを設定することで初めて、受信側でDMARCによる認証を行うことができるようになります。

平塚さん: DMARCの説明については櫻庭さんの説明のとおりです。
DMARCに関して中々導入が進んでいない現状があり、その原因の一端としてDMARCに対する誤解があるかと思います。例えばDMARCを設定することは通信の秘密に抵触してしまう、であったり、DMARCの設定にはDKIMの設定が必須である、であったりなどなど。これらの誤解を解くためにもDMARCの仕組みについてしっかりと説明していきたいと思います。

DMARCを普及させるにあたり、課題点は何だと思いますか

櫻庭さん: JPドメインについてDMARCとSPFの設定率を見てみると、DMARCはまだ2%未満、SPFは70%弱程度であることがわかります。この普及率の差の原因が何かは、常々考えているところではありました。
もしかしたら認知度が足りていないのかなという思いもあるが、やはり先に平塚さんのお話にも上がった誤解(DMARCは通信の秘密に抵触している、DMARCはDKIMが必須、など)があるのではないかというのを薄々感じています。実際、DKIMへの対応もできたほうが良いのは確かではありますが、SPFだけでもDMARCは実現できます。
この辺りについて、今回改めて整理して理解していただきたいと思います。

また誤解の他に、DMARCを設定すべき事業者(クレジットカード会社や銀行等)において、DNSとメールと両方の設定をしなければならないという「面倒臭さ」、そしてこれらの設定を行う設定者の違いも、導入に当たり二の足を踏む原因の一つ担っているのかもしれないなと思います。
このような原因に対しては技術の説明だけでなく、導入することによるメリットを理解していただくと良いかと思います。
今回の発表にもあるBIMIでは、DMARCで認証できたドメインに対しては、ブランドのロゴを表示させるような仕様が検討されている段階です。このあたりの状況についても今回お話させて頂ければと思います。

平塚さん: DMARCを含む送信ドメイン認証はサーバサイドで機能するものであるため、エンドユーザがこれを確認できないと中々ありがたみが伝わりにくいです。そのため、ユーザ側で検証結果が確認できるインターフェースが必要だと思います。
最近では、Yahoo!社のメールアプリでは、送信ドメインの認証結果が見れるようになっており、任意のメールが真っ当な送信元から送信されたのかどうかを確認できるようになっています。このように、今までユーザインターフェースの部分で足りていなかった部分が充実してきており、ここから普及が始まっていくのかなと期待しています。

発表で特に議論したいポイントはどこでしょうか

櫻庭さん: やはり、DMARCの普及していない点について、DMARCを設定しない理由があればお聞きしたいです。
実際の設定としてもtxtレコードを追加するのみなので難しい作業でもないように思っていますが、もし何か問題点があるようであれば、参加者の方々から意見を伺って打開策を考えていきたいと思います。

平塚さん: DMARCを導入した事業者からその集計データを頂いており、実際にDMARCによりどれぐらいのなりすまりメールを検出できているのかを発表の中でお見せしようと思っています。
それを見て頂いた上で、DMARCの導入について前向きな考えを持って貰えたかどうか、ぜひともお聞かせいただきたいです。

最後に一言お願いします

櫻庭さん: とにもかくにも、DMARCの設定をお願いします。
またDMARCの普及のためには、送信側の設定だけでなく受信側でも設定を行う必要があります。送信側での対応と合わせて、受信側でもしっかりと対応して頂きたいと思います。

平塚さん: 技術はニーズがあってこそ使われるものだと思います。そのため、DMARCという技術にどれだけのメリットがあるのか、実際にどれだけの効果が上がっているのか、それをぜひ見て確かめて頂きたいです。
またこれらのデータを通して、なりすましメールなどはいつ自分たちの会社のドメインが利用されてしまうかわからないぐらい身近な問題であることをご理解頂き、しっかりと対応してもらうようお願いしたいと思います。


インタビューにご協力いただきありがとうございました。
また、インタビューの際にDMARCや、SPF・DKIM・BIMIといった要素技術についてわかりやすくまとめてあるwebページをご紹介いただきました。
本セッションの内容をより深く理解するためにも、ぜひご一読ください。
なりすまし対策ポータル ナリタイ