JNSA「セキュリティしんだん」
| «（31）今からでもやるべき「敵を知る」ために。 | （33）インターネット利用者の７割が知らない、自分の身に起こること 〜〜電気通信事業法改正方針後退を巡って» |
（32）PPAP問題から、インターネット・コミュニケーション再考する（2021年８月１9日）
電子メールでパスワード付きZipファイルを添付する、いわゆるPPAPが話題になっています。PPAPは情報を保護する手法として有効性が低いだけではなく、マルウエアの検出回避に利用され、しかも受信者に不便を強いることから、PPAPの利用を拒否する「くたばれPPAP！」も提唱されています。
PPAPとは
【P】asswordつきzip暗号化ファイルを送ります
【P】asswordをおくります
【A】ん号化
【P】rotocol
出典：情報処理 2020年７月号 「さよなら,意味のない暗号化ZIP添付メール」
一方で、PPAPに問題があることは確かですが、PPAPを全く使わないメール運用も難しそうです。問題点を理解するためにメールを使ったコミュニケーションの課題を整理し、代表的な対策手法の有効性を検討しました。その結果、それぞれの手法で解決できる課題が異なり、用途によって使い分ける必要があることがわかりました。
本稿では、一般的なメールの課題を整理し、それぞれの対策の特徴について分析を行います。
■主要な対策の有効性
- PPAP：推奨できない
- メール・添付ファイルの保護になっていない
- マルウエアによる悪用、受信者の利便性低下などマイナス面が大きい
- S/MIME：「取引文書」をはじめとした真正証明が必要なメール
- 請求書、通知、その他
- キャンペーンのお知らせなどの広告メール
- クラウドストレージ：添付ファイルの保護とアクセス記録
- クラウドストレージに適切な認証の仕組みが必要
- メールでパスワードを送る場合は十分な軽減策にならない
- IRM：IDに紐づいたメール・添付ファイルの厳格な管理
- 社外への誤送信対策、ファイルのコピー、退職者の対策
- 組織間の利用に課題がある
- ビジネスチャット：誤送信の範囲を限定し、不要な受信を減らす
- 拡張機能のセキュリティ対策に課題
- すべての取引先とワークスペースを作ることはできない
■メールに係るセキュリティ上の課題
まず、電子メールに関する代表的な課題について考察します。ここでは、メール送信時の課題、メール受信時の課題、メール閲覧時の課題に分けて考えます（表1-3）。
| 大項目 | 中項目 | 例 |
| S1:組織外への誤送信 | 宛先間違い | 個人のメールアドレス メーリングリスト等 |
| 添付ファイル等の誤添付 | 社内資料を顧客へ添付 別の顧客の資料を添付 その他の誤添付 |
|
| S2:送信先アドレス開示 | BCC問題 | BCCを誤って CC/TOへ |
| S3:送信内容の保護 | ネットワーク上の保護 | 平文での送信 複数のメールサーバを経由 |
| コピーの保護 | 目的外利用の抑止 想定しない閲覧の抑止 |
| 大項目 | 中項目 | 例 |
| R1:攻撃メール | マルウエア | ウイルスメール 標的型攻撃などの攻撃メール |
| フィッシング BEC 詐欺 |
送信元を詐称 類似アカウント・類似ドメイン 架空の関連組織・個人 取引委員会等の規制機関 政府機関等 政府機関等の職員 送信元アカウントの侵害 |
|
| R2:迷惑メール | 迷惑メール | OPT INなしに送付されるメール 配信停止を要求したのに送付されるメール |
| 不要なメール | OPT INしたが興味のない広告・情報等 | |
| R3:受信内容の保護 | メールサーバ上の保護 | 通信の暗号化 メールの暗号化 |
| クライアント上の保護 | アクセス制御 メールの暗号化 |
| 大項目 | 中項目 | 例 |
| V1:メールの特定 | 必要なメールが見つからない | 構造化ができない 適切な分類（振り分け）が困難 適切な検索が困難 受信メールが多すぎる |
| 添付ファイルが検索できない | 暗号化されたファイル(PPAP) リンクされたファイル |
|
| 引用が長すぎる | 構造的でないため、過去の履歴がメールに内在されていたり、いなかったりする 知りたいことが、どのメールに書いてあったか分からなくなる （検索キーワードでは絞り込めないケース） |
|
| 過去情報の閲覧 | 後で参加すると過去のやり取りがわからない |
■代表的な対策手法の評価
PPAPに加えて、以下の代表的な対策について、表1-3で検討した課題への有効性を評価します。
- S/MIME
- IRM (Information Rights Management)
- ビジネスチャット
PPAP
PPAPは添付ファイルの保護手段であって、メール本文の保護ではありません。添付ファイルを自動的に暗号化し、同じ宛先にパスワードを送る手法は、セキュリティ境界がなく、添付ファイルが見られればパスワードも見ることが出来てしまいます。このため、どの課題に対しても解決策になりません。加えて、マルウエア対策のバイパスに利用されることや、受信者の利便性が極めて悪くなることも問題です。
PPAPとは異なり、事前にパスワードを取り決めておけば、問題は解決するとの提案も見かけます。このように、添付ファイルとパスワードを別の手段で送る方法を、BPAPと呼称し、PPAPと合わせて評価します。
BPAP
【B】eつの手段でPasswordお知らせします
【P】asswordつきzip暗号化ファイルを送ります
【A】ん号化
【P】rotocol
| 大項目 | 中項目 | PPAP / BPAP |
| S1:組織外への誤送信 | 宛先間違いの本文 | PPAP ×：対策できない BPAP ×：対策できない |
| 宛先間違いの添付ファイル | PPAP ×：対策できない BPAP 〇：保護される |
|
| 添付ファイル等の誤添付 | ||
| S2:送信先アドレスの開示 | BCC問題 | ×：対策できない |
| S3:送信内容の保護 | ネットワーク上の保護 | PPAP ×：対策できない BPAP 〇：保護される |
| コピーの保護 | ×：保護されない | |
| R1:攻撃メール | マルウエア | ×：マルウエア対策をバイパスする |
| フィッシング BEC 詐欺 |
―：解決策ではない | |
| R2:迷惑メール | 迷惑メール | ―：解決策ではない |
| 不要なメール | ―：解決策ではない | |
| R3:受信内容の保護 | メールサーバ上の保護 | PPAP ×：対策できない BPAP 〇：添付ファイルは保護される |
| クライアント上の保護 | ||
| V1:メールの特定 | 必要なメールの特定 | ×：添付ファイルの閲覧を著しく損ねる |
| 添付ファイルの検索 | ×：検索ができない | |
| 引用が長すぎる | ―：解決策ではない | |
| 過去情報の閲覧 | 後で参加すると過去のやり取りがわからない | ―：解決策ではない |
S/MIME
S/MIMEは、証明書を使うことで、メールの改ざん検知、盗聴防止（暗号化）、なりすまし防止を行う手法です。全てのメールコミュニケーションをS/MIMEで行うことは現実的ではなく、仮にできたとしても有効性は限定的です。しかし、企業対個人、企業対企業の「取引文書」（請求書、領収書、通知、確認など）では、偽メール対策として有効に機能します。企業が「取引文書」を送付する際には、メールの真正証明のためS/MIMEを使うことは常識となって欲しい対応です。
一方で、真正証明は、送信メールアドレスの真正を証明するものであり、送信者や送信元の組織に悪意がないことを保証するものではありません。このため、アカウントが侵害されている場合や、そもそも悪意を持った組織がS/MIMEを使った場合、S/MIMEで受信者を保護することはできません。
| 大項目 | 中項目 | SMIME |
| S1:組織外への誤送信 | 宛先間違いの本文 | ×：対策できない |
| 宛先間違いの添付ファイル | ||
| 添付ファイル等の誤添付 | ×：対策できない | |
| S2:送信先アドレスの開示 | BCC問題 | ×：対策できない |
| S3:送信内容の保護 | ネットワーク上の保護 | 〇：保護される |
| コピーの保護 | ×：保護されない | |
| R1:攻撃メール | マルウエア | ×：ゲートウェイでの対策ができない ×：詐称していないアカウント（、以下、非詐称アカウント）からの送付は対策にならない（アカウントの乗っ取り、悪意を持った組織など） ×：混在環境では、S/MIMEされていないメールを排除できない |
| フィッシング BEC 詐欺 |
〇：「取引文書」の真正証明には有効 〇：送信元アドレス詐称の対策には有効 ×：非詐称アカウントからの送付は対策にならない |
|
| R2:迷惑メール | 迷惑メール | ×：非詐称アカウントからの送付の対策にならない ×：混在環境では、S/MIMEされていないメールを排除できない |
| 不要なメール | ―：解決策ではない | |
| R3:受信内容の保護 | メールサーバ上の保護 | 〇：保護される |
| クライアント上の保護 | 〇：保護される | |
| V1:メールの特定 | 必要なメールの特定 | ―：解決策ではない |
| 添付ファイルの検索 | 〇：実装によるが検索可能 | |
| 引用が長すぎる | ―：解決策ではない | |
| 過去情報の閲覧 | 後で参加すると過去のやり取りがわからない | ―：解決策ではない |
クラウドストレージ
添付ファイルを使わずに、ファイルをクラウドストレージ（CS）に保存し、そのURLをメールに記載する手法です。誤送信や誤添付が判明した場合は、CS上のファイルを削除することで、その後のダウンロードを防ぐことができます。また、CSによっては、ダウンロードしたIPアドレスのログを見ることで、ダウンロードの有無について確認することも可能です。
CSの利用は、添付ファイルの誤送信について一定の有効性がありますが、受信者が閲覧する際の不便さが伴います。また、ゲートウェイでのマルウエア対策が難しいことも考慮する必要があります。
CSでの適切な認証が不可欠
- メールにパスワード：PPAPと同じで、誤送信の対策にならない
- CSへのアカウント作成を要求：受信者側の管理が難しくなる
CSの利用方法
- Anonymous（リンク名だけの保護）：有効性は低い
- Anonymous+パスワード：パスワードの通知方法に課題
- クラウドストレージ上のアカウントが必要
- 取引先のポリシーにより作成できない場合がある
- 取引先にアカウントを作成させることに抵抗感がある
| 大項目 | 中項目 | クラウドストレージ |
| S1:組織外への誤送信 | 宛先間違いの本文 | ×：対策できない |
| 宛先間違いの添付ファイル | 〇：別途適切な認証が求められる場合 ×：認証がないか、送信先アカウントに紐づいた認証の場合 |
|
| △：誤送信に気付いたところで、ファイルの削除などができる △：ログを確認することで、ダウンロードの有無・IPアドレスの確認が期待できる |
||
| 添付ファイル等の誤添付 | ||
| S2:送信先アドレスの開示 | BCC問題 | ×：対策できない |
| S3:送信内容の保護 | ネットワーク上の保護 | △：本文は保護されない 〇：ストレージにアクセス時に認証が伴う場合は、添付ファイルの保護が期待できる |
| コピーの保護 | ×：保護されない | |
| R1:攻撃メール | マルウエア | ―：解決策ではない ×：ゲートウェイでの対策ができない |
| フィッシング BEC 詐欺 |
||
| R2:迷惑メール | 迷惑メール | |
| 不要なメール | ―：解決策ではない | |
| R3:受信内容の保護 | メールサーバ上の保護 | ―：解決策ではない |
| クライアント上の保護 | ―：解決策ではない | |
| V1:メールの特定 | 必要なメールの特定 | ―：解決策ではない |
| 添付ファイルの検索 | ×：添付ファイルの内容が検索できない | |
| 引用が長すぎる | ―：解決策ではない | |
| 過去情報の閲覧 | 後で参加すると過去のやり取りがわからない | ―：解決策ではない |
IRM (Information Rights Management)
認証に基づいてメールそのものや、添付ファイルの暗号化を行う手法です。マイクロソフト社のRMS（Rights Management Services）などとして実装されています。閲覧時（復号時）に認証を行うことから、送信後にも保護条件の変更が可能であり、また、退職者がメールやファイルを保持した場合でも、アカウントの無効化に伴い、アクセス権が無くなります。
IRMは、メールをはじめとした情報保護における多くの課題を解決する手法ですが、認証に基づいた保護を行うことから、認証基盤が異なる利用者間での運用に課題があります。また、ソフトウェアの不具合があった場合の影響も懸念されます。
| 大項目 | 中項目 | IRM |
| S1:組織外への誤送信 | 宛先間違いの本文 | 〇：閲覧時に認証が必要であるため、組織外のアカウントでは閲覧できない ×：組織外とのメールでは利用困難 |
| 宛先間違いの添付ファイル | ||
| 添付ファイル等の誤添付 | ||
| S2:送信先アドレスの開示 | BCC問題 | ×：対策できない |
| S3:送信内容の保護 | ネットワーク上の保護 | 〇：閲覧時に認証が必要であるため、組織外のアカウントでは閲覧できない ×：組織外とのメールでは利用困難 |
| コピーの保護 | ||
| R1:攻撃メール | マルウエア | ―：解決策ではない ×：ゲートウェイでの対策ができない |
| フィッシング BEC 詐欺 |
||
| R2:迷惑メール | 迷惑メール | |
| 不要なメール | ―：解決策ではない | |
| R3:受信内容の保護 | メールサーバ上の保護 | 〇：閲覧時に認証が必要であるため、組織外のアカウントでは閲覧できない ×：組織外とのメールでは利用困難 |
| クライアント上の保護 | ||
| V1:メールの特定 | 必要なメールの特定 | ―：解決策ではない |
| 添付ファイルの検索 | ―：解決策ではない | |
| 引用が長すぎる | ―：解決策ではない | |
| 過去情報の閲覧 | 後で参加すると過去のやり取りがわからない | ―：解決策ではない |
ビジネスチャット
近年、slack, Teamsなどのビジネスチャットの利用が広がっています。
メールは、インターネット全体が送信可能ドメインとなりますが、ビジネスチャットは、ワークスペース内が送信可能ドメインとなります。このため、誤送信先が限定されることに加え、ウイルスメール、広告メール、詐欺メールの懸念が少ないという特徴があります。
一方で、メールで利用される、グループアドレス（ML（Mailing List）やDL(Distribution List)）を使ったコミュニケーションが難しい面があり、また、取引先ごとにワークスペースを作ると、ワークスペース数が多くなり、利便性が低下するといった問題もあります。
ビジネスチャットのセキュリティは、ワークスペースに閉じていることに依存していますが、アドオンやボットと呼ばれる拡張機能を使うと、この制限が外れてしまいます。ビジネスチャットのセキュリティを考えるうえで、拡張機能のセキュリティドメインは、今後の課題になっていくと考えられます。
| 大項目 | 中項目 | ビジネスチャット |
| S1:組織外への誤送信 | 宛先間違いの本文 | 〇：ワークスペース外に投稿出来ない △：チャネルやワークスペースを間違うことがある 〇：投稿や添付ファイルの削除が可能 |
| 宛先間違いの添付ファイル | ||
| 添付ファイル等の誤添付 | ||
| S2:送信先アドレスの開示 | BCC問題 | 〇：原則的に存在しない |
| S3:送信内容の保護 | ネットワーク上の保護 | 〇：保護される |
| コピーの保護 | ×：保護されない | |
| R1:攻撃メール | マルウエア | 〇：現状での懸念は少ない △：MFA等によりアカウント侵害の対策ができる ×：アドオンの悪用が懸念される |
| フィッシング BEC 詐欺 |
||
| R2:迷惑メール | 迷惑メール | 〇：ワークスペース内に閉じているため、メールと比較して圧倒的に少ない |
| 不要なメール | 〇：閲覧するチャネルを選択できる ×：チャネル内の不要な情報はフィルタできない |
|
| R3:受信内容の保護 | メールサーバ上の保護 | 〇：保護される（認証） |
| クライアント上の保護 | △：クライアントの設定に依存 | |
| V1:メールの特定 | 必要なメールの特定 | 〇：で比較的容易 〇：条件付き受信通知ができる |
| 添付ファイルの検索 | 〇：比較的容易 | |
| 引用が長すぎる | 〇：引用はほとんど使われない | |
| 過去情報の閲覧 | 後で参加すると過去のやり取りがわからない | 〇：過去の投稿を閲覧できる |
■むすび
この資料を作成するにあたり、自分のメールボックスを調べてみたところ、読まなければならないメールは受信ボックスの１割もありませんでした。「迷惑メール白書 2018」[1]で紹介されている約35%と比較すると、ずいぶんと迷惑メールが多い印象ですがCISCOのデータ[2]では、85%弱と筆者の感覚に近いデータとなっています。迷惑メールの定義が明確でないことが、大きな数字の違いにつながっていると考えられます。
自身が受け取っているメールを大きく分類すると、同じメールアカウントでも、特定個人として受け取っているもの、組織や業務グループ（以下、組織）として受け取っているものがあります。送信元との組み合わせでは、「個人から個人」、「組織から個人」、「個人から組織」、「組織から組織」の組み合わせがあります。「迷惑メール」や「攻撃メール」は、これらの組み合わせの中に紛れ込んできます。
メールの内容に注目すると、なんらかの公式な意味を持つ「取引文書」や「準取引文書」と、それ以外の「一般的な文章」に分類されます。「一般的な文章」はいわゆる「双方向のコミュニケーション」と、広告やニュースなどの「ブロードバンド型の一方向のコミュニケーション」に分類することが出来ます（表 9）。
メールの安全な運用を考えるにあたっては、このようなコミュニケーションの分類について、もう少し深く考えてみる必要がありそうです。これまで、メールはインターネットの普及に大きな役割を果たしてきましたが、利用法を見直す時期に来ているのかもしれません。先に述べたように、着信メールの大半は読む必要がないメールであり、また、コミュニケーションのメディアもSNSや、ビジネスチャットなどのメール以外の手段が使われるようになっていることから、メールへの依存度は大きく下がっていると考えられます。一方で、ブロードバンド型のコミュニケーションや、不特定多数から連絡を受ける手段として、メールは重要なメディアとしての地位を保っています。
メールに適したコミュニケーションと、メールに適さないコミュニケーションを理解し、それぞれに対して適切なセキュリティ対策を行っていくことが重要です。
- [1]
- 迷惑メール白書2018 (dekyo.or.jp)
https://www.dekyo.or.jp/soudan/data/anti_spam/2018/HB18_00_all.pdf - [2]
- Email and Spam Data || Cisco Talos Intelligence Group - Comprehensive Threat Intelligence
https://talosintelligence.com/reputation_center/email_rep
| «（31）今からでもやるべき「敵を知る」ために。 | （33）インターネット利用者の７割が知らない、自分の身に起こること 〜〜電気通信事業法改正方針後退を巡って» |
