サーバー乗っ取りからメールの誤送信まで　PPAPで起こりやすい8つのセキュリティインシデントその対策

セッションの紹介と流れの説明

加瀬正樹氏（以下、加瀬）：このセッションは、「データ保護・誤送信防止のメール技術とは？」と題して、3人でプレゼンテーションしていきたいと思います。よろしくお願いいたします。

私のパートでは、網羅的にさまざまなセキュリティの問題点と、その対策として8つのセキュリティインシデントと、10個の手段を紹介したいと思います。そのあと櫻庭さんにバトンタッチして、TLS通信の暗号化関連の技術の説明。最後に北崎さんにバトンを渡して、モバイルの世界ではどういったデータの保護があるを話してもらおうと思います。

8つのセキュリティインシデントと10個の対策

はじめに今回の「PPAP」（暗号化ZIPで添付ファイルをメールで送るという流れ）のベースを簡単に紹介したいと思います。この図で言うと、左側の組織Aから組織Bに対して、赤いファイルをZIPで暗号化。メールソフトを使って、メールサーバーを経由して、受信者Bに届け、そこで復号化してファイルを見る。そういった流れかと思います。

これらについて、いくつか考えられるセキュリティインシデントを紹介したいと思います。それらに対してどういった対策ができるかも、合わせて10個ぐらいあったので、リストアップしたいと思います。

セキュリティインシデント（1）メールサーバーの乗っ取り

まず1つ目。一番ありそうなところで言うと、送信側の組織 Aのメールサーバーを乗っ取られて、そこから正規にメールを送ってマルウェアを混入させる手法があるなと思います。最近で言うと、Emotetと呼ばれているマルウェア、これもこのパターンを多く踏んでいるかと思います。

これをどうやって解決するか。1つ目の案としては、まずメールサーバーです。MSA（Message Submission Agent）で、送信するところで、そもそも暗号化ZIPを禁止してしまう方法があると思います。2つ目としては、送信は許可されていたとしても、受信する側で同じように暗号化ZIPを禁止するようなルールをつける対策もできるかと思います。この2つによって、こういった攻撃は防ぎやすくなると思います。

セキュリティインシデント（2）送り手のメールサーバーへのマルウェア送信

2つ目。今度は外部に攻撃者がいて、正規のメールサーバーを介さずに、送り手のメールサーバーに直接ZIP暗号化してマルウェアを送信する方法があるかと思います。

このケースをどうやって解決するかというと、先ほど紹介したB、メールサーバーが受信したところで、暗号化ZIPをそもそも拒否する方法が、やはり有効かと思います。

もう1つは、外部から送信者をなりすます。DMARCというなりすましメールの対策を導入することで、そういったメールを拒否したり、なりすましが流通していることを、なりすまされた組織Aに通知するようなことが考えられると思います。

セキュリティインシデント（3）ホモグラフドメインでマルウェア送信

3つ目のパターンは同じように外部に攻撃者がいる場合ですが、今度は正当なドメイン名を騙るのではなく、見た目が似ているような文字列、ホモグラフドメインを使ってマルウェアを送信することも考えられるかと思います。

こういったパターンに関しては、当然ながら受信メールサーバーで暗号化ZIPをそもそも拒否する方法も有効だし、受信サーバーでいわゆるドメイン名が信頼できるものかを判定する「ドメインレピュテーション」の導入も対策としては有効かと思います。

セキュリティインシデント（4）Man in the Middle

4つ目のセキュリティインシデントパターンとしては、いわゆる「Man in the Middle」と呼ばれている、中間者攻撃によってデータが漏洩したり改ざんされるケースがあると思います。

本来であれば、真ん中にあるメールサーバーが通信して、左から右にメールを送信します。しかし、そこに中間者として攻撃者がニセのMTA（メール転送エージェント）を用意して、そこで正しいデータを入手して盗んだり、あるいはその代わりにマルウェア付きのファイルを再添付して相手側に送信することが考えられると思います。

この中間者攻撃に関する対策として1つ考えられるのは、送信側・受信側で通信の暗号化であったり、MTA-STS（SMTP MTA Strict Transport Security）と呼ばれている通信の暗号化をポリシーとして宣言する方法が考えられると思います。これによって、組織Aのメールサーバーは間違った宛先のメールサーバーに送信することを留められるし、中間者攻撃があったことを、TLSレポートと呼ばれているフィードバックによって、組織Bに伝えられると思います。

そのほかに、先ほど紹介した受信サーバーで暗号化ZIPを禁止するようなルールも有効です。また、ドメインのなりすましであるDMARC（Domain-based Message Authentication, Reporting, and Conformance）の判定結果を使って、正しいところから送信されていないメールを拒否する。そして、それを組織Aにフィードバックすることも有効かと思います。

ドメインレピュテーションを使って、受信側のメールサーバーで中間者攻撃を判定することも、対策の1つとして有効かもしれません。一方で、攻撃者はファイルの中身は盗めてしまうリスクは考えておかないといけないと思います。

セキュリティインシデント（5）中央のメールサーバーの盗聴

5つ目は、中央のメールサーバーの間の通信を盗聴することによって、データを漏洩する・盗むことがパターンとしてはあり得ると思います。

5つ目のパターンをどうやって回避するかと言うと、先ほど紹介したように、この中央の通信を暗号化する。そして盗聴を守ることが1つ言えるかと思います。

あるいは、End-to-Endの暗号化を使う。一番よく知られているもので言うと、S/MIMEを使って組織Aから組織Bにデータを渡すことも可能かと思います。

S/MIMEに限っていうと、この場合、データの本文は暗号化できますが、件名や宛先・差出人のような情報は攻撃者に漏洩してしまう。そういったことは念頭に置いたほうがいいと思います。

セキュリティインシデント（6）受信側のクレデンシャル情報を盗む

6つ目のパターンは送信側ではなく、受信側のクレデンシャル情報を盗んで、IMAPやPOPを使ってメールボックスに侵入してファイルを盗む。そういったデータの漏洩のパターンがあると思います。

これをどうやって解決するかというと、先ほど話したEnd-to-Endの暗号化に対応している場合にはファイルの保護ができると思います。Subject（件名）などは読まれてしまうのは、先ほど話したとおりです。

あるいは、メールボックスにアクセスするときに、IMAPやPOPのときはパスワードを使うと思いますが、パスワードに頼らないほかのセキュリティ対策を導入するのもあり得るかと思います。具体的には2要素認証、あるいはそれ以外の機械学習などを使って、攻撃者と正当なアクセス者を判断する。そういった仕組みもあり得るかと思います。

セキュリティインシデント（7）メールの転送設定を仕込む

7つ目のパターンとしては、受信側のメールサーバーに、なんらかの方法でメールの転送設定を仕込むことで、受信者Bにも届くし攻撃者に対してもデータが届くような設定ができてしまう。これによってデータ漏洩することが考えられると思います。

これについてどういう対策が考えられるかと言うと、1つは先ほども話したように、POP・IMAPだけではなく、メールの設定情報に関しても、パスワード以外の認証あるいは権限を設けさせる。そういったことで不正アクセス・不正な設定を防げると考えられると思います。また、ビジネスシーンで言えば、社外へメールを転送することをそもそも制限する。そういった厳しいルールを設けることで、漏洩は防げるかもしれません。

セキュリティインシデント（8）誤って別の人にメールを送る

8つ目のパターンですが、今回PPAPの話題の中で出ていた1つです。誤ってメールを別の人に送ってしまい、それによってデータ漏えいするパターンです。

これについては2つ方法が考えられるかと思っています。メールサーバーから送出されるところでクラウド側にデータを置き、本文とURLを送信する。送信者側で気づいたらファイルを抹消して、結果的にアクセスを禁止できると思います。

一方で、悪意はありませんが、第三者が件名を読む、あるいはクラウドストレージ以外にメールに書かれている情報は読めてしまうことは念頭に置いておく必要があると思います。

もう1つは、送信をいったん保留にして、一定時間経過したあとに送信する。機能で誤りを気づかせて、送信をキャンセルできるかと思います。ちょっと最近の情報を持っていませんが、いわゆる送信失敗したあと、何分後かに気づけるパターンは確率としては多いと聞いているので、これによってデータ漏洩を防止することは有効だと考えています。

どの対策も一長一短

ここまでで合計で8つのセキュリティインシデントのパターンと、それに対する……9個と書いてありますが、10個の手段を整理しました。それぞれが一長一短ある対策かと思っています。

例えばA・B、暗号化ZIPを禁止するのは、口で言うのは簡単ですが、それによって業務に支障が出ることを気にしなければいけないとか、救済措置を入れなければいけないとかが課題だと思います。

CでいうDMARCの対応も、DNS上で宣言することは比較的容易ですが、ポリシーを厳しくしたり、本当に拒否をするとか、運用の難しさのわりに効果は限定的と言えるんじゃないかと思います。

一番下のE、通信の暗号化についても、最近のメールサーバーでTLS対応とは非常に進んでいるのかなと思います。グーグルやマイクロソフトのサーバーをクラウドで使っている場合はすでに対応済みなので、なかなか敷居としては低くなってきているとは思います。しかし、オンプレミス対応が少なかったり、さまざまな問題点があります。そもそも盗聴リスクどこまで高いのかも、ちょっと僕にはわかりかねるところです。

S/MIMEのようなメールの暗号化では、技術規格としては古くからあるものですが、いわゆるメールゲートウェイの時点でもやはり無害化をしたい要望がある場合は、なかなか完全な対策とは言えないのではないかと思います。

G、パスワード以外の不正アクセスを防止するのも重要になりますが、実際にそれを技術規格として持ち合わせているものが、メールの中では非常に乏しいと思います。

また、一番下に2つあるとおり、クラウドサービスを使ってストレージをSaaSに置くこともできると思います。ただ、パスワード付きZIPで送信するのと同じように、パスワードで保護しないといけないのか、それをどうやって送信するのか。そういったところの一般的な解は見つかっていないのかもしれません。

私のほうで、このようにいくつかのセキュリティインシデントのパターンを整理して、合計で10個の対策を用意したので、みなさんはどれが対応できるかをチョイスしてもらうのがいいかなと思って、整理しました。

（次回につづく）