Internet Infrastructure Review（IIR）Vol.55
2022年6月30日発行

1. 定期観測レポート

今、求められるメールセキュリティ～パスワード付きZIPと送信ドメイン認証「DMARC」

1.1 はじめに

昨年6月に発行した本レポートのVol.51（https://www.iij.ad.jp/dev/report/iir/051/01.html）の「定期観測レポート」で、迷惑メールと、ウイルス数の集計と傾向を報告しました。特徴的だったのは、最大値でその前年度の200倍もの迷惑メールを受信したことと、Emotet（エモテット）と呼ばれるウイルスが自分自身をZIPで暗号化することでウイルススキャンを回避し、猛威をふるっていたことでした。

今回は、IIJがそうした脅威から自社を守るために取り組んだ2つのセキュリティ強化策について紹介します。1つは暗号化ZIPの運用を廃止したこと、もう1つはDMARCの強化です。読者の皆様にもぜひ実施いただきたい内容ですので、ご参考になれば幸いです。

1.2 IIJ、暗号化ZIPの運用を廃止

1.2.1 暗号化ZIP廃止の背景

IIJでは、2022年1月26日以降、メールに添付された暗号化ZIPファイルを原則受信拒否するよう、全社ポリシーを変更しました（注1）。

日本国内では、メールで添付ファイルを送付する際にパスワード付きZIPとして暗号化し、そのパスワードを別送する手法が誤送信対策として広まっています（注2）。しかし、この手法は誤送信対策として効果が少ないだけでなく、ウイルススキャンを回避できてしまう致命的な問題を抱えていることから、CISA（米国サイバーセキュリティ・インフラセキュリティ庁）からも受信拒否することが推奨されています（注3）。

また、前途のとおり、猛威をふるったEmotetがこの手法を用いており、今後も同様の手口で拡散するウイルスの登場が予想されます。IIJ社内のみならず、大切なお客様や取引先様よりお預かりする情報を守るためにも、このリスクを看過することはできないとの経営判断に至り、トップダウンで対策が進められました。

1.2.2 暗号化ZIP廃止までの準備

今回のポリシー変更はおおよそ次のような手順で進められました。

• 情報システム部門から危機管理部門・経営層への説明
• 経営層から社内へのリスク説明・方針説明
• 情報システム部門での対策実現のための検討
• 情報セキュリティ担当部門での統一ルール検討
• 社内の各部門への説明とスケジュールの展開
• お客様・取引先様への説明
• ポリシーの変更

経営層からの方針説明があってから最終的にポリシーを変更するまでに、約1年掛かりで準備が進められました。丁寧に準備を進めていった結果、約半年経過した現時点で大きな混乱は生じていません。

1.2.3 暗号化ZIP廃止の効果

1.2.4 代替策はあるか

暗号化ZIP廃止論とセットで話題になるのが、この代替策です。前回のIIR Vol.51では、どのような手法を用いても一長一短があることを説明しました。

IIJでも、この点を十分理解しており、社外とのファイル共有方法として、3つの手段を用意しています。

1つ目は、全社統一のオンラインストレージです。代替策として論じられている、最もオーソドックスな手段でしょう。ただし、オンラインストレージにはメールをアーカイブしているときに、後からファイルの追跡がしにくいという内部統制上の弱点になり得る点や、URL1つで大容量のファイルを持ち出すことができてしまうため内部犯行を見つけ出すのが困難である点をリスクとして抱えています。

2つ目は、添付ファイルをそのまま送信する方法です。暗号化ZIPは誤送信対策として効果が少なく、ウイルススキャンを回避できてしまうことが問題なのですから、そのまま送信すれば良いという判断です。また、一部の取引先様によっては、宛先の社内から社外Webへのアクセスが許されていないケースもありますので、そのような場合は直接送信して対応しています。

3つ目は、従来の暗号化ZIP運用を続ける方法です。これは例外措置です。メールでのやり取りは、送信・受信の双方あって成立するものですから、一部の組織や取引先様で従来の手法を取らざるを得ないケースが残っています。このような場合は、リスクを十分に理解した上で、その組織長の承認によって、例外措置を入れた運用をしています。

そして、この3つの方法をメール監査システムと組み合わせることで、それぞれの弱点を補強しています（表-1）。

拡大する

表-1 代替策の代表的なアドバンテージとリスク

繰り返しになりますが、暗号化ZIPを一律受信拒否としたことで、Emotetを代表とするウイルスの脅威にさらされることがなくなりました。こうしている間にも攻撃者は次のターゲットを狙っています。全社ポリシーを変更するには時間が掛かることもありますので、今すぐ対策に着手されることをお勧めします。

1.3 IIJ、DMARCポリシーを強化

1.3.1 DMARCポリシーを強化した背景

IIJは、2013年にDMARCポリシーを導入し、しばらくの間p=none、つまり、外部に対してDMARC検証が失敗したメールについて何もしないでください、と宣言してきました。p=noneだとしても、DMARCレコードを公開してDMARCレポートを受信することが可能です。受信したレポートの統計データを集計することで、なりすましメールを見抜くことができるため、自社ドメインのブランドを守るという観点ではとても有用です。IIJが提供しているメールセキュリティSaaS「IIJセキュアMXサービス」でも、DMARCレポートを自動で集計し、統計情報を参照できる機能を提供しています。

近年、スパムフィルタを巧みに回避するようなフィッシングメールや差出人詐称メールが流行しており、メールによる様々な脅威に対して多角的なアプローチが必要になっています。法人系メールセキュリティSaaSをお客様に提供しているIIJとしても、まずは社内メールのセキュリティ強化を図るため、p=quarantineへポリシーを変更することとなりました。

1.3.2 送信ドメイン認証

IIJのDMARC導入について報告する前に、改めて送信ドメイン認証技術について以下に記します。送信ドメイン認証技術にはSPF、DKIM、DMARCが世界的に一般に使用されており、それぞれRFCにて定義されています（表-2）。

拡大する

表-2 一般的な送信ドメイン認証技術の特徴

いままでのメールに関するフィルタ処理は受信者側での判断に委ねられていましたが、DMARCポリシーを使ったフィルタ処理は、送信者側から"DMARCの認証に失敗したメールはこう処理してほしい"と受信者へ依頼をする形となっており、メールをフィルタする手段としては従来にはなかった画期的なフレームワークです。

1.3.3 送信ドメイン認証導入の準備

DMARCポリシーを変更するにあたって、作業自体はDMARCレコードの変更のみですが、それ以前にSPFレコードの宣言またはDKIM署名の実装が必要です。DMARCポリシーはSPFまたはDKIMを元にそのメールが正当かどうかを評価しますので、送信ドメイン認証されていないメールが社内ユーザから送信される状況を作らなければいいわけです。

そこで大事なのが、次のような下準備です。

1. （1）会社のメールは会社のメールアドレス（ならびにメールシステム）からしか出してはいけない、という社員への啓蒙活動
2. （2）メールの出口の集約による送信ドメイン認証への対応コスト削減
3. （3）DMARCポリシー導入後の）定期的なDMARCレポートの確認

これら3つの対策について詳述します。

①社員への啓蒙活動

IIJではiij.ad.jpドメインで送信するメールが何種類か存在します。

• IIJ社員が送信する業務メール
• 各システム機器からの通知メール
• お客様へ送信するアナウンスメール

社員の業務メールについては、以前は社内の様々なサーバから送信されている状況でしたが、社内メールシステムの出口が情報システム部門によって管理されるようになったことと、そもそも社内メールシステム以外から@iij.ad.jpを使ってメールを送信することをポリシーにより禁止し、社内からインターネットへの通信を常時監視して定期的に違反ユーザへ送信停止依頼を通知することで解消しました。

また、社内の様々なシステムから送信されるメールについても問題がありました。IIJではいくつものサービスが各部署で運用されており、至るところからアラートメールや通知メールなどが送信されていました。現在は、サービスを統括する部署により各種サービスから送出されるすべてのメールの出口が統一されています。

更に、グループ会社や地方拠点の中にもアラートメールなどの差出人アドレスをiij.ad.jpとしている機器があったので、各担当者へ通知をしてIIJで定めたポリシーに従ってもらいました。

②メールの出口の集約

前述したように、"メールの出口の集約化"というのは送信ドメイン認証の運用を考慮する上で非常に重要になってきます。

SPFレコードにはメールの送信元IPアドレスをCIDR表記することができますが、メールの出口を/32や/31、広くなっても/28程度に取りまとめておけばレコードを長々と書く必要もなく、出口が追加や変更になったとしても運用コストを削減することができます。メールの出口となるIPアドレスがいくつもある場合、includeを重ねに重ね、SPFの検証がうまくできなくなったり、考慮漏れが発生して意図せずにSPF検証に失敗したりする場合もあります（ちなみに、RFC 7208にはSPFにincludeを記載する際、DNS lookupの回数は10回までとの記載があります）。

③定期的なDMARCレポートの確認

IIJでは、各所からDMARCレポート（rua）を受信しています。様々な組織から"我々のシステムで受信した@iij.ad.jpからのメールの送信ドメイン認証の結果はこのとおりです"という情報が定期的に送られてくるのです。メール送信の出口を管理しているため、それ以外から送られているメールについては基本的にはスパムメールのはずですが、以下のようなそうではないメールも散見されたため、その情報を元に少しずつ各部署にポリシー設定の修正をお願いしていきました。

拡大する

図-2 iij.ad.jp 2022/02のDMARCレポートサマリー
（左）検証結果の割合（右）検証失敗ドメインランキング上位20ドメイン

• アラートメール
  ネットワーク機器やサーバの監視システムなどのenvelope fromを勝手にiij.ad.jpにしてSPF/DMARC failしているケースがあった
• プロモーションならびにリクルーティングメール
  これらは外部のSaaSを利用することがよくあるが、そのシステム内でenvelope fromがiij.ad.jpとなり、送信ドメイン認証を考慮せずに送っているメールがあった

1.3.4 DMARCポリシー変更の決断

DMARCポリシーは段階的にquarantineからrejectへと強化していくことも可能です。IIJでは、DMARCポリシーp=quarantineを導入することにしました。隔離であれば、メールを受け取った相手方でDMARCポリシーによるフィルタリングをしていたとしても、メールを受け取れないわけではないためです。

実際の作業

作業自体はとても簡単で、DMARCレコードの宣言をp=noneからp=quarantineに書き換えるだけです。本報告では詳細の記載は省略しますが、この段階で既にSPFレコードの宣言、ならびにDKIM署名の実装が完了していることが前提となっています。

事後のレコード確認を含めても、ものの10分もかからずに作業は完了します（図-3）。

拡大する

図-3 作業前と作業後のiij.ad.jpのDMARCレコード

ここでDMARCレコードについて紹介しておくと、adkim、aspfパラメータはDKIM、SPFそれぞれについての認証識別子（ドメイン）のアライアメントモードをr（relaxed mode）またはs（strict mode）と指定することができ、該当メールの組織ドメインとHeader Fromが一致しているかどうかの判定をする際のパラメータとなります。

例えば、組織ドメインがexample.com、Header Fromがsystem@alert.example.comであるメールのSPFを元に評価する場合、アライアメントモードrを指定していると認証結果がpassとなります。また、sを指定していた場合、完全にドメインが一致している必要があるためfailとなります。ruaはDMARCレポートの送信先の指定であり、前項目で紹介した集計結果はdmarc-rua@dmarc.iij.ad.jpにて受信したレポートを可視化した情報となります。

変更後の影響

IIJでは2021年12月15日にDMARCレコードを変更しました。

設定変更後、社内からの問い合わせ状況や動向を注視していましたが、大きな混乱はありませんでした。DMARCレコードの変更を難しいと考える方も多いかと思いますが、実際はそこまで影響もなくメールを受信した相手に対して"我々は送信管理をしたメールしか出していないのでそれ以外は隔離なり拒否してください"と宣言できるので、導入を検討してみてはいかがでしょうか。

過去には、IIJのハニーポット環境でDMARCポリシーを宣言していないことから大量のなりすましメールが送信されてしまう事象が観測されています。メール文書に正当性を保持したい機関（金融機関や行政機関など）では、DMARCを導入することで詐称メールと明確な差別化ができるのでお勧めです。

本稿を執筆中、IIJではDMARCポリシーp=quarantineを導入して数週間、様子を見ていましたが、特に業務メールに影響がないと判断し、2022年3月23日にDMARCポリシーをp=rejectに変更しました。DMARCポリシーp=quarantineを導入した際と同様、社内からの問い合わせなどもありませんでした。

1.4 送信ドメイン認証統計

1.4.1 送信ドメイン認証の普及状況

前回、本レポートのVol.51（https://www.iij.ad.jp/dev/report/iir/051/01.html）で報告した集計結果と比較すると、DKIMとDMARCのpass割合が増えていることが分かります。DKIMのpass割合が前回と比較して数ポイント増加していることから、リモートワークの状況下にて各企業でのSaaS導入がやや増加傾向にあるのではないかという予測ができます。また、DMARCのpass割合も増加していることから、徐々にではありますが、送信ドメイン認証への世間への関心が高まっている様子が窺えました。

1. （注1）IIJからのプレスリリース「パスワード付きzipファイルが添付されたメール及び別送のパスワード記載メール（PPAP）に対する当社運用の変更について」（https://www.iij.ad.jp/ppap/）。
2. （注2）PPAPと呼ばれることがあります。
3. （注3）CISA「Emotet Malware」（https://www.cisa.gov/uscert/ncas/alerts/aa20-280a）。

1. 定期観測レポート 今、求められるメールセキュリティ～パスワード付きZIPと送信ドメイン認証「DMARC」

• 1.1 はじめに
• 1.2 IIJ、暗号化ZIPの運用を廃止
• 1.3 IIJ、DMARCポリシーを強化
• 1.4 送信ドメイン認証統計