パスワード付き (暗号化) ZIP廃止の考え方と対策
2020年11月30日 月曜日
CONTENTS
2020/11/17(火)、平井デジタル改革担当相が定例会見で「パスワード付き ZIP (通称、PPAP) の廃止」について言及されました。国民からの意見を直接募り、一国の担当者が、このような運用にまで言及されたことは、とても珍しいように思えます。
IIJスタッフがやりとりするメールでも、業務やお客様のご都合もあり、全面的にすぐ廃止はできませんが、準備ができたところから順次、パスワード付き ZIP を廃止していく方針です。
IIJは、2022年 1月 26日よりパスワード付き ZIP ファイルは原則として、受け取らない方針になりました。
詳細は次のページをご覧ください。
なぜパスワード付き ZIP を廃止するのか
まず、メールを運用する立場から、パスワード付き ZIP 廃止の方針に賛成します。
なぜなら、一言に危険だからです。
じつは、従来から誤送信対策とされるパスワード付き ZIP (暗号化 ZIP) は効果が薄いばかりか危ない、という主張をしていました。次の資料は 2018年 11月に開催された「迷惑メール対策カンファレンス × JPAAWG」で、私が発表したスライドの一部です。
大事なことなので 2回書きますが、
- パスワード付き ZIP は誤送信対策としての効果は薄く
- むしろマルウエアの隠れ蓑となり、ウイルススキャン回避の手段に使われてしまうリスクのほうが高い
ことを IT 管理者はよく理解しておくべきです。実際に、ウイルススキャン回避を狙った標的型攻撃・BEC も観測しています。(詳細は上記ページの資料をご覧ください)
また、このような ZIP ファイルにパスワードを付けて送る手法は、日本国内で見られるガラパゴスな習慣であることも特筆すべき点です。海外で、このような運用は見かけません。海外の人にこの運用を説明すると、「なぜ、そんな危険を犯してまで手間を掛けるのだ?」と首を傾げられます。
私もそう思います。
なぜパスワード付き ZIP がダメなのか
次に利用者として、パスワード付き ZIP 廃止の方針に賛成します。
これはすでに出尽くされている議論ではありますが、ご存知の通り、とても無駄が多いからです。
改めて、この運用を手順書にしてみましょう。こうなります。
- 添付ファイルを ZIP で圧縮・暗号化する
- パスワードを入力する
- 大抵は誤入力防止のため、もう一度入力する
- メールに添付して送信する
- 別メールでまたメールにパスワードを書いて送信する
これだけの手順を踏んでいる時間があったら、宛先、本文、添付ファイルを 100回見直していたほうが良いでしょう。
また、パスワード付き ZIP は自動化を妨げます。
(本来であれば、もっと別の方法が良いのですが) システムや企業間を越えたレガシーなデータ連携として、そのやり取りにメールを使っているケースが少なからずあるでしょう。例えば、メールの着信をトリガーにして、添付ファイルを展開し、予め定められた処理をして、データを加工して、別のデータを生成したり保存する、といった具合です。
このプロセスの中にパスワードの抽出・入力があると、添付ファイルとパスワードを紐付ける必要があります。
これは地味な割に実装の手間が掛かり、Power Automate をはじめとしたモダンな RPA の妨げになります。
「予め取り決めておいたパスワードを使えばよいのでは?」という声も聞こえてきそうですが、それは誤送信対策でしょうか? 本来の目的を見失ってはいけません。
どのようなときにパスワード付き ZIP を使うべきか
データを保護する目的として、ファイルにパスワードを付与することで、一定のリスクを低減させられることは事実です。
しかし、インターネットが安全ではなく、E メールによる攻撃がある限り、そうした用途は極めて限定的であると捉えるのが妥当でしょう。「誤送信時のデータ漏洩に対するリスク低減」と、「ウイルススキャン回避のリスク受容」とを比較したとき、後者の小さくないリスクを受容する方がお互いに危険と言えます。E メールから脅威の侵入を許してしまい、後々大規模な情報漏洩になることのほうが大惨事です。
また、もしかしたら、通信経路上の盗聴対策を挙げられるかもしれませんが、メールには、世界的に普及しており標準化されている暗号化通信(TLS)があります(※1)。Google 社の透明性レポートで、どのくらいのメールが経路暗号化されているかレポートを見ることができます。
https://transparencyreport.google.com/safer-email/overview?hl=ja
残念ながら日本では普及が遅れていますので、こちらのキャッチアップを急ぐべきでしょう。(※2)
国内企業の動き
平井デジタル改革担当相の会見を受け、早くもパスワード付き ZIP の受信拒否に動いたクラウドサービスもあります。クラウド会計 SaaS を展開するフィンテック企業、freee 社です。
2020-11-18 freee、メールによるパスワード付きファイルの受信を廃止
https://corp.freee.co.jp/news/filepassword_abolished.html
方針決定の背景として、
- メール受信時にマルウエア検査を迂回されてしまうため、結果的にパスワード無しのファイルと比較して社内のセキュリティリスクを増大させていること
- パスワード付き ZIP の運用が、昨今の Emotet 感染を助長させてしまっていること(※3)
- 米国 CISA からパスワード付きファイルはブロックすることが推奨されていること(※4)
が挙げられています。
「会計」という極めて重要なデータを扱う企業として、賞賛に値する動きと言えるでしょう。
3回目になりますが、ウイルススキャンを回避されて、パスワードで保護されたマルウエアが平然と社内ネットワーク内に流通するほうが、よほど危ないのです。
トロイアの木馬の歴史を繰り返してはいけません。
IIJ がオススメする誤送信対策
では、どのようにして誤送信対策をするべきでしょうか?
クラウド型の統合メールセキュリティサービスを提供する、IIJセキュアMXサービスでは、従来から誤送信対策として以下の機能を提供しています。
送信一時保留 (標準機能)
利用者が送信したメールを、管理者が指定した時間だけ、IIJセキュアMXサービスの設備内に保留させる機能です。
「送信ボタンを押した直後に間違いに気づいた」
こんな経験、心当たりありませんか?
誤送信に気づくのは、大抵送信ボタンを押してから数分以内です。
Gmail や Outlook にも類似の機能がありますが、IIJセキュアMXサービスなら、ご利用のメーラーやオンプレミス環境と組み合わせても利用できます。誤送信の問題は「間違った相手に送ってしまう」ことですから、ここで宛先と本文を再確認してから安心して送信できますし、万が一、誤りに気づいたら送信前に安全に削除できます。
少しでも不安があれば、ここで一旦送信を取りやめて、もう一度送り直せばよいのです。
送信フィルタ (標準機能)
管理者が指定したポリシーによって、予め送信制限を掛けておく方法です。
- 社内で規定された添付ファイル以外はポリシー違反として送信拒否する
- フリーメール宛や宛先の多いメールは管理者へ通知を出しておく
- タイプミスと考えられる自社ドメインと類似した宛先は削除する
といったユースケースに対応できます。
特に 3つ目のような、本物そっくりの偽物ドメインのことを「Cousin Domain (いとこドメイン)」とか「Homograph Attack (ホモグラフ攻撃)」と呼びます。例えば、iij.ad.jp とするところを、iijad.jp (“iij” と “ad” の間にドットがない) としてしまうケースです。こうした例は差出人に再確認させても人の目では気づきにくいため、システム側で対処すべきポイントです。
また、IIJセキュアMXサービスにはパスワード付き (暗号化) ZIP を検知できるフィルタがありますので、ここでパスワード付き ZIP の送信を拒否し、差出人にエラーとして返すこともできます。すでに海外では、パスワード付き ZIP は受け取らないポリシーであることも多く、あとで「メールが届かない」などといった問い合わせを減らすことも期待できます。
メール監査 (オプション)
管理者が指定したルールにマッチしたメールを、IIJセキュアMXサービス内で記録・保留し、上長やメール担当者が、保留解除・差戻し・削除などを行える機能です。
- 都度、メールの宛先や内容を見て送信可否を判断したい
- 部門ごとに定められたポリシーによって細かい制御をしたい
- 条件に一致するメールを特定アドレスに Bcc したい
といったユースケースに対応できます。
これらの対策をすべて利用する必要はありません。利便性とリスク、組織のポリシーに従って、柔軟に組み合わせて利用できます。(※5)(※6)
受信側のパスワード付き ZIP 対策
どんなに社内の対策を進めても、社外からパスワード付き ZIP ファイルが送信されることがあるでしょう。
IIJセキュアMXサービスでは、パスワード付き ZIP を検知できる機能がありますので、これを条件にして自由にフィルタを組むことができます。例えば、次のようなユースケースに対応できます。
パスワード付き ZIP が添付されていたら、
- そのメールを隔離する
- そのメールを受信拒否する
- そのメールの件名に注意喚起の文字列を付与して配送する
といったような対策が可能です。
なお、3つ目の方法は、海外とのやり取りでもよく見かける手法です。そのようなメールがやり取りされると、件名に「WARNING: This message could not be scanned antivirus」といった文字列が入ったりしますので、完全にパスワード付き ZIP の受信を廃止するまでの移行措置として利用するのも良いでしょう。
さらに、メールを隔離するときは、管理者だけ見える領域に隔離しておくこともできます。
例えば、管理者が Emotet でないかチェックしたあと、管理者の権限で隔離メールをリリースすることにし、ユーザにはリリースさせないといった運用にすることが可能です。
ところで、少々対策のベクトルが異なりますが、添付ファイルが暗号化されてパスワードが別に送られていると、後日、訴訟対応などでアーカイブが必要になったときに、無駄な手間を強いられることがあります。なぜなら、中身を確認するために、添付ファイルの付いたメールとは別に展開パスワードを探さなければいけないからです。別の手段でパスワードが通知されていると、パスワードを発見できないかもしれません。
そういった有事のときに限ってスピード感が求められたりしますので、経営者や IT 管理者としては、絶対に避けたいところでしょう。
まとめ
パスワード付き ZIP は主に、
- メールの運用者(IT 管理者)にとってリスクが高い。なぜならウイルスの侵入を許してしまうから。
- メールの利用者にとって手間が大きい。しかも効果は薄い。
という 2点においてダメであるという説明をいたしました。
今回の発表は、長年パスワード付き ZIP の運用を何となく続けてしまっていた国内企業にとって、大きな転換期となるでしょう。「誤送信対策だから」といって、受信者にリスクを負わせていた悪習を、今こそなくすときです。
何度も書きますが、パスワード付き ZIP は誤送信対策として効果が薄い割に、リスクの高い運用であることをよく理解しておく必要があります。
注釈
- RFC3207 で SMTP 拡張の STARTTLS が標準化されています。これは 2002年に標準化されているものであり、十分に枯れているプロトコルです。[↑]
- いわゆる「スノーデン事件」を期に大きく普及しました。この話は、映画「スノーデン」がとても興味深いので、ぜひ観てください。そして危機感を感じてください。[↑]
- 全く口裏を合わせていませんが、当社の「wizSafe Security Signal 2020年9月観測レポート」をご覧いただいていたようです。ありがとうございます！[↑]
- 「Emotet の再来に最大限の警戒・対策を – 迷惑メール 2020/2Q レポート」でも、Emotet 対策として触れています。こちらもあわせてご覧ください。[↑]
- メディアからは添付ファイルを送る代替案としてオンラインストレージを利用する手法が定石のように語られていますが、これもリスクとのトレードオフになります。例えば、こっそり内部情報をオンラインストレージにアップロードして情報を持ち出し、すぐに URL を無効化してしまうような内部犯行は、証跡保存(アーカイブ)の観点からは抜け道になってしまいますので要注意です。サービスラインナップとしては、IIJ ドキュメントエクスチェンジサービス(DOX) と連携する、オンラインストレージ(DOX)連携オプションを提供しています。[↑]
- IIJセキュアMXサービスでは、添付ファイルの自動暗号化機能を提供しています。この機能が追加されたのは 2009年。当時はお客様からの強い要望があって実装したものでしたが、以上で述べてきた理由により、積極的にはオススメできない機能となっています。[↑]
