「クラウドストレージ」も「Webダウンロード」ももう不要
目からウロコのPPAP解決策【TLS確認機能】のご紹介
GOLD SOPNSOR
株式会社クオリティア
1

脱PPAP宣言後の市場の動きは？

2パスワードが掛かっていることが問題なのであって、パスワードZipと読み取りパスワードに違いはないのでは？

パスワード付きZipはダメだけど、パスワード付き7zipならいいの？

3

いや、だったらパスワードZipで送る場合も別経路で伝えればいいのでは？

いずれの三社も• 一部上場• 社員数10,000人以上• IT系・・・(ノД`)・゜・。
4

脱PPAP宣言後の各社の対応は？

5

比較サービス① A社⚫ ファイルの授受にはWebダウンロード方式
受信者

送信者

MTA

④ダウンロードURLを挿入した本文を送付①メール送付②ファイルを隔離③URLの発行⑥ファイルをダウンロード

MTA⑤パスワードメール送付【特徴】 URL付きのメールが発送されるMTAとパスワードを記載したメールが発送されるMTAが異なる
6

比較サービス① A社【懸念点】・元メールとパスワード通知メールの配送サーバーを分けたとしても受信メールサーバー側で盗聴されている場合は、結果、盗聴されてしまうのではないか？

7

比較サービス② B社⚫ ファイルの授受にはWebダウンロード方式⚫ PINコード(ワンタイムパスワード)を使ってダウンロードさせる

MTA④URLが記載されたPDFを本文に添付し送付

送信者①メール送付②ファイルを隔離③URLの発行

MTA⑤URLより、メールアドレス宛にPINコードを発行依頼⑦PINコードを入力しダウンロード⑥PINコードが記載のメール送付【特徴】
・URLが記載されているPDFファイルを元メールに添付し送信・受信側によるパスワード発行の仕組みを搭載※自動別送ではない（待ち伏せ盗聴に対するシビレ切らせ効果）

・PDF付き元メールとPINコード通知メールの配送サーバーは異なる
8

比較サービス② B社【懸念点】
・PDFではセキュリティ的観点では特に意味がない…？
・そもそものURLと鍵を盗聴者に取られたらそこはあきらめる

・元メールとPINコード通知メールの配送サーバーを分けたとしても、受信メールサーバー側で盗聴されている場合は、結果、盗聴されてしまうのではないか？
・利用する為には、別途有償で別プランへの移行が必要

9

比較サービス③ C社⚫ ファイルの授受にはWebダウンロード方式⚫ ダウンロードには端末へ保管される鍵と別送パスワードの二要素による認証が必要
受信者

MTA

送信者

④URL挿入の本文を送付

ファイルサーバー⑤URLアクセスし、パスワード発行ボタンを押下①メール送付②ファイルを隔離⑥端末に鍵がダウンロード③URLの発行⑦パスワードメール送付⑧端末鍵とパスワードが一致した場合にダウンロード【特徴】
・端末鍵を持っていない端末からのアクセス時は不正アクセスとみなしロックを掛ける
・盗聴被害に備え、盗聴者より先に正規受信者がロックすることが可能
10

比較サービス③ C社【懸念点】
・そもそものURLと鍵を盗聴者に取られたらそこはあきらめる
・メーリングリストやグループアドレス宛に送付したファイルは、いち早くアクセスしたユーザー1名のみがファイルを取得できる為、その後の社内展開が必要となるのでは…？
・鍵、、、とはメーカー独自のプログラム？受信者側のEndPointセキュリティでAlertは出ない？
・ 鍵、、、という独自プログラムを相手側（受信者）に扱わせることで、無用の警戒心を抱かせるのでは？
11

比較サービス④ D社⚫ 独自のアプリを使ってファイルを共有⚫ 端末上のアプリ間では独自プロトコルを使ってファイルの授受を行う
受信者

送信者

MTA
ファイル暗号化サーバ⑤権限が設定されたHTMLファイルをメール添付で送付⑥ファイルクリック後、Webブラウザが開きメールアドレスを入力③メール送付 ④ファイル暗号化サーバー ⑦受信メールアドレスの照合後、OTPをメール送付
で閲覧権限を設定⑧OTPを入力しブラウザ上でファイルを確認①端末にアプリをインストール②アプリ上で受信者登録＆権限設定を実施

【特徴】
12

• 受信者側のファイルを送信者側から削除する操作も可能• 独自プロトコルなので盗聴の懸念なし

比較サービス④ D社【懸念点】
・ファイルをアプリ内からOS上の領域へ保存すると、送信者側では削除できない
・使えるファイルは限定される（容量が大きくなりがちな動画ファイルは使用できない）
・HTMLファイル付きメールが盗聴された場合は、あきらめるしかない・HTMLファイルは日常でのやり取りが少ないので相手側（受信者）に無用の警戒心を抱かせるのでは？

13)

当社サービス(⚫ ファイルの授受にはWebダウンロード方式⚫ 固定パスワードを付与し、パスワード通知メールへは「ヒント」のみを記載
受信者
送信者④URL挿入の本文を送付①メール送付⑤別送で「ヒント」をメール送付②ファイルを隔離③URLの発行【特徴】⑥送信者と受信者のみが分かるパスワードでログイン・パスワード自体は通知メールに記載されていない為、パスワードの盗聴が不可能
・別送パスワードメールを待つ必要がなく、決められたパスワードでファイルの取得ができる

・ダウンロード期限を設けることで、ファイル奪取のリスクを低減

14• 初めて送る相手に対してはパスワードをヒントで伝える方式でのやり取りが現実的ではない

15

サービス比較まとめ
A社

B社

C社

D社

当社

ファイルの送信方法

WebDL方式

WebDL方式

WebDL方式

WebDL方式

WebDL方式

パスワード通知メール
配送方式

自動送付

受信者発行

受信者発行

受信者発行

自動送付

一見さんへの汎用性

○○○

×△〇

（別MTAからのパスワード通知）（PINコードを別MTAから通知）（端末鍵とパスワードで認証）（OTPでの認証）（パスワードを通知しない為、漏洩リスク無）

✕△△△

◎

（短時間で自動配送されてくるため）（受信者のタイミングで配送）（受信者のタイミングで配送）（受信者のタイミングで配送）（パスワードを通知しない為、漏洩リスク無）

一通目の盗聴による漏洩リスク

✕✕

✕

✕

○

オンプレでの提供可否

✕✕

○

○

○

追加オプションは不要か？

不要

要不要

要不要

盗聴防止策

待ち伏せ盗聴者への対策

16△(送信者側での受信者登録処理が必要)〇(ヒントを記載)

×◎◆全社共通してWebダウンロード形式を採用◆パスワード送付方法に各社工夫がみられる

ところが、1通目を取られたらどのサービスもOUT
17

じゃあクラウドストレージ使う？
■Dropbox■Box■Google ドライブ
■OneDriveなど●PPAPだけの用途を検討するとコスト高●受信者側でアーカイブが取れない●過去メールからファイルの確認が困難（去年の見積ってどれだっけ？）●PPAPでのメール送付ではないが、結局はURL通知、PW通知が同一経路となる
18

そもそもPPAP問題とは？

⚫盗聴リスクがある（ファイルとPWの同一経路問題）⚫ウイルス検知できない（PWファイルのセキュリティスルー問題）⚫利便性が悪い（スマホで見れない問題）

では、ここで考えてみましょう。

今日現在、Internetを飛び交っているメールの何割が暗号化されているのか？

盗聴リスクがあると言うけれど、今までその手法で盗聴されて情報漏洩えいが明るみになった事故ってありますか？
20

Gmailから送信されるメールの通信の暗号化がされている割合

88％
https://transparencyreport.google.com/safer-email/overview参照
21

Gmailで受信するメールの通信の暗号化がされている割合

90％
22

https://transparencyreport.google.com/safer-email/overview参照

Active! gate SSのTLS通信割合は？

弊社サービスActive! gate SSを利用いた
だいているお客様の暗号化通信(TLS通信)の割合は？

90.8％
23

盗聴リスクについて考える

盗聴リスクがあると言うけれど、今までその手法で盗聴されて情報漏えいが明るみになった事件ってあるのか？

⚫少なくとも当社では聞いたことはない⚫スノーデンレポートのこと言ってますか？
⚫国内のISPってお国の言うillegalなことに黙って従いますか？

24

盗聴リスクについて考える

そもそもあるかどうかもわかんないリスクに踊らされ過ぎPPAPって言い出した人間の罪は重い

25

当社の考えについて暗号化(STARTTLS)通信が確立できるメール配送先へは単純なZipでの送付、もしくは、何もせずに送れば良いのでは？

暗号化(STARTTLS)通信が担保されるか否かをActive! gate SS で判断し配送ができれば良いのでは？

26

STARTTLS通信の確認はどのように行うか# telnet 172.16.**.** 25
Trying 172.16.**.**...
Connected to 172.16.**.**.
Escape character is ‘^]’.
220 receive.qualitia.co.jp ESMTP Service ready
EHLO hoge
250-receive.qualitia.co.jp Hello [172.16.**.**], pleased to meet you
250-8bitmime
250-STARTTLS
250 help
MAIL FROM: <sender@qualitia.co.jp>
250 sender@qualitia.co.jp... Sender OK
RCPT TO: <receiver@example.com>
250 receiver@example.com... Recipient OK
data
354 Enter mail, end with “.” on a line by itself<省略>.
250 Message queued for delivery as 468c1ec829
quit
221 Bye...
Connection closed by foreign host.

送信する方がEHLOを宣言した後、受信する方の応答でTLSが話せる相手かどうかわかる

応答に
250-STARTTLS
がなければTLSで受けられないという意味

27つまり、、、暗号化通信が使える相手なら送信者

TLS対応②試しにEHLOをなげてみる①メール送付

メールサーバー③250-STARTTLSが応答④Zip圧縮⑤再度SMTPセッション開始⑥250-STARTTLSが応答⑦Zip圧縮しただけのファイルを添付して送信（そのまま生ファイルでも可）28

受信者

では、逆に使えない相手なら？
送信者

TLS未対応②試しにEHLOをなげてみる①メール送付

メールサーバー③250-STARTTLSがない
URL④URL発行⑤再度SMTPセッション開始
受信者⑥250-STARTTLSがない⑦URLとヒントで送る

29

URL

もっと過激なことをいうと、、、
送信者

TLS未対応②試しにEHLOをなげてみる①メール送付

メールサーバー③250-STARTTLSがない
受信者④Zip圧縮⑤再度SMTPセッション開始＋⑥250-STARTTLSがない

パスワード⑦Zip圧縮＋PWのファイルを添付して送信

どうして未だにZipPW？

受信のTLSに対応してください
30

まとめ

⚫PPAP（ZipPW）が悪いとされているところ◆ 盗聴されるリスク？
• 実害があったかどうかは不明• でも各社ともに盗聴防止に躍起になっている◆ 相手側のセキュリティシステムをすり抜ける• Emotetなどの被害の原因に◆ スマホで見れない• 確かに利便性が悪い

生で送っても90％は盗聴されません
生で送ればしっかりウイル
スチェック掛かります
クラウドストレージ使っても利便性は上がりません。

まとめ-2

暗号化（STARTTLS）通信は約90％の割合で確立している➡たった残りの一割のために、ファイル共有サービスを利用すべきか再検討しましょう➡本来、暗号化通信(TLS)で送っていい相手先にも• Webダウンロード方式で送ってしまい、アーカイブを取らせてません• 一年前の見積もりなどを過去メールから検索させず、運用の手間を掛けさせてます32クオリティア社としてのご提案

利便性を落とさず、セキュリティ性を担保し、現行の運用を変えずに済むのはメール専業メーカーである当社だからこそできる

TLS確認機能付き
Active! gate SSへのご利用に切り替えること
33

TLSに対応してる相手かどうかを具体的に知りたい

https://www.qualitia.co.jp/product/ag/tls-check.html

34