第５９５号コラム：「私たちはなぜパスワード付きｚｉｐファイルをメール添付するのか」

第５９５号コラム：上原哲太郎副会長（立命館大学　情報理工学部　教授）
題：「私たちはなぜパスワード付きｚｉｐファイルをメール添付するのか」

皆さんの組織でも、重要な情報を含むファイルをメールで外部に送付する際に、その漏洩防止等のため、何らかのルールを設けておられるところが多いのではないかと思います。その中で非常によく見かける方式に、このようなものがあります。

①添付するファイルをあるパスワードを使って暗号化ｚｉｐファイルにする。
②そのファイルをメール添付して送信する。
③続いてそのパスワードをメール送信する。

私が見聞きする限り、多くの日本企業や組織がこのようなファイル送信法をセキュリティ強化策と信じて」内規で義務づけたり、自動化システムを導入したりしています。しかしこの種のメール、少し考えるだけでセキュリティの観点からは効果がないことは明らかです。同一経路でファイルとパスワードを送っているのですから、仮に攻撃者がいれば片方が入手できれば他方も入手できるはずです。そして、この種のメールは受信者にとっては煩わしいだけの、大変やっかいな、大きく言えば生産性を阻害する要因にしかなっていないと感じます。このようなファイル送信方式は、一部では（揶揄して）ＰＰＡＰ方式と呼ばれています。曰く、

Passwordつきｚｉｐ暗号化ファイルを送ります
Passwordを送ります
Aん号化（暗号化）
Protocol

の略だそうです。命名者は（一財）日本情報経済社会推進協会（ＪＩＰＤＥＣ）の大泰司章さんです。最近では（一財）日本インターネットプロバイダー協会（ＪＡＩＰＡ）のイベントでこんな講演をされていました。

くたばれＰＰＡＰ！～メールにファイルを添付する習慣を変えるところから始める働き方改革～

それにしても何故ＰＰＡＰ方式という無意味な手法が広がってしまったのでしょう。メールの使われ方についてシステム管理者としてずっと関心を持ってきた経験からすると、このＰＰＡＰ方式が普及するまでには次のような経緯があったように感じています。

（ａ）インターネット上での通信は暗号化されてこなかった歴史がある。しかし、セキュリティ上の脅威が認識されるにつれ、インターネット上のどこかでの盗聴の脅威に備えて何らかの暗号化が必要であるという認識は広まった。

（ｂ）そんな中、公開鍵暗号の普及がありインターネットプロトコル全般への適用が進んでいった。ＴＥＬＮＥＴ、ＦＴＰやＨＴＴＰといった当時の主要プロトコルは送受信者間の通信が直接ＴＣＰで行われるため、そのＴＣＰ通信そのもの、又はその1つ上のレイヤを公開鍵暗号で暗号化するプロトコルが生まれ、普及を迎えた。結果としてＴＥＬＮＥＴＳ、ＦＴＰやＦＴＰＳ、ＳＦＴＰそしてＨＴＴＰＳなどが広く使われるに至った。

（ｃ）しかしメールは１つのＴＣＰセッションで送受信されるわけではないため、このような対処では通信全体が暗号化できない。現在ではメールは以下のような手順で送信者から受信者に届けられる。

（ア）送信者のメールクライアント（ＭＵＡ）から、まず所属組織のメールサーバ（ＭＴＡ）にＳＭＴＰ、またはＴＬＳで暗号化されたＳＭＴＰＳを用いて送信される。

（イ）送信者側のＭＴＡは受信者に向けて多くの場合はいくつかのＭＴＡ間をバケツリレーのように何度かＳＭＴＰ（運が良ければＳＭＴＰＳ）で転送されてから、受信先の組織のＭＴＡに届く。

（ウ）受信者がその組織のＭＴＡのメールボックス内のメールを読む。この際多くの場合、その認証情報であるユーザ名とパスワードを保護する必要から暗号化されたプロトコル（ＰＯＰ３ＳやＩＭＡＰ４Ｓ、ＨＴＴＰＳなど）が用いられる。

この手順の随所にメール盗聴のリスクはあるが、特に（イ）におけるＭＴＡ間の転送が暗号化されるとは限らないことが大きなリスクとして残っている。送信者にとってＭＴＡ間通信の暗号化は強制できないし、暗号化されるかどうか事前に確認する術もない。なので、同一組織内でメールが送受信されるのでない限りは、受信者の手元に届くまでの間に暗号化されない通信が残りうる。

（ｄ）この問題の解決には、メール本文や添付ファイルを暗号化する必要がある。そのため公開鍵暗号を用いた安全なメール暗号化方式として、ＰＧＰやＳ／ＭＩＭＥが　提案され規格化された。しかし、ＨＴＴＰＳなどの通信路暗号化方式がサーバ側に公開鍵と秘密鍵のペアを持ちさえすればよいのに比べ、メールの場合は全ての利用者がそのメールアドレスに対応する公開鍵と秘密鍵を個別に持って管理する必要がある。
この鍵の管理の煩雑さやコスト（特にＳ／ＭＩＭＥ用の電子証明書コスト）がネックになって、メールの標準的な暗号化は普及しなかった（現在もこの状況は改善していない）。

（ｅ）そこで苦肉の策として、パスワード付ｚｉｐなど共通鍵方式で暗号化したファイルを送り、文書やＦＡＸなどの別の手段でパスワードを事前に共有したり、後から送付する手法が広まった（この前後には専用ツールによるファイル暗号化や、暗号化された自己解凍ファイルの送付が一部で広まった時期もあったが、汎用性の無さから廃れた）。折しも、Ｐマーク認証などの取得に際して「メール送信時の個人情報を含む添付ファイルに対するセキュリティ対策」が必要な審査項目に入り、パスワード付ｚｉｐファイルにした上での送信をセキュリティ対策として認める動きが広がった。こうして急速に添付ファイルのパスワード付ｚｉｐファイル化がセキュリティ対策として標準的地位を得るようになった。

（ｆ）しかしこのパスワードの伝達を電子メール以外の手段で行うことは極めて煩雑なので、結局「別メールならパスワードをメールで送って良い」という規定で運用する組織や企業が現れ、ＰＰＡＰ方式が誕生した。これがＰマーク等の審査時にセキュリティ対策として認められてしまったことと、「メールによる情報漏えいの主なリスクは盗聴ではなく誤送信であり、その対策としてＰＰＡＰ方式は一定の効果がある」という理屈が捻り出されたことにより、一気に普及が加速して現在に至っている。

ざっとこんな経緯ではないでしょうか。

それにしても、おそらくＰマーク認証等の要請から生まれたパスワード付ｚｉｐファイルでの添付ファイル送信が、ＰＰＡＰ方式に劣化するに至ってもまだ審査に通ってしまうのは困ったものです。一般にデータの暗号化というのは「データのアクセス制御問題を暗号鍵の管理問題に置き換える」手続きと見なすことが出来ます。パスワード付ｚｉｐファイルにおいては、その暗号鍵がパスワードにあたるわけですから、重要なファイルの送信問題はパスワードの管理問題に置き換わっているのであり、そのリスク評価は不可欠です。単純に考えれば、そのままメール送信してはいけないとされるデータが暗号化されている場合に、その暗号鍵がそのままメール送信されていたのでは何もリスク軽減になっていません。特に「ＰＰＡＰが自動化」されているソリューションでは、それにセキュリティ的な意味を見いだすのは困難です。せいぜい、受信者が添付ファイルを暗号化したまま保存しておいてくれることが期待できる、とか、そのファイルを重要なものと送信者が考えているというメッセージになるとか、その程度のものではないかと思います。

また、ＰＰＡＰ方式が「誤送信対策として一定の効果がある」かどうかも怪しいものです。誤送信は１通目のメールの送信後、手作業で２目のパスワード送信する前に誤送信に気づくということが期待されているのですが、どのような作業手順なら誤送信が高い確率で気づけるのかよく分かりません。また仮にそれが成り立ったとしても、パスワード付ＰＰＡＰは、パスワードが十分に予測不能な複雑さと長さを持たない限り、暗号化されたデータ本体がオフラインでの総当たり攻撃によって復号できる可能性は高いので、既に誤送付されてしまったパスワード暗号化ｚｉｐファイルは情報が既に漏洩したと見なさなくてはならないと思います。最近のパソコンはＧＰＵと十分高速に総当たり攻撃が行えるので、古いZipCrypt方式（しかし今でもよく使われています）で暗号化されたファイルなら英数字８字程度のパスワードの総当たりには１台のパソコンでも５分とかかりません。パスワードに記号を入れたり文字数を伸ばすことで総当たりが困難にできますが、今度はパスワードの管理の煩雑さが増してしまいます。

このようにＰＰＡＰ方式は煩雑であって労働生産性に少なからぬ悪影響を与えていると思われる割に、普通の平文メールに比べてセキュリティ的なリスクが下がっているか疑わしい手法であります。まして、現在のメールを用いた業務で最も注意すべき標的型メール攻撃に対して、暗号化されたｚｉｐファイルは受信側ＭＴＡ前後でのマルウェア対策を無効化してしまうため、かえって受信者のセキュリティリスクを高めている恐れすらあります。

では、メールを起点に考えたときにファイルはどのように送付するべきなのでしょうか。
私はこのように考えています。

（１）いっそ何もせずそのまま添付ファイルでメールする。いきなり何を言い出すのだと思われるかもしれませんが、私は大真面目にそう思っています。ＰＰＡＰ方式ではセキュリティリスクが下がらないどころか、受信者に作業負担とセキュリティリスクを上積みさせてしまう恐れがあります。それなら、そのままメールで送った方がましです。そもそも、メールの「暗号化」とやらは上記の（ｃ）、（イ）つまりＭＴＡ間転送での暗号化が行われていない恐れがあることを根拠に求められていたのだろうと思うのですが、現在はメールの転送トポロジは単純になってきていますので、転送に関わるＭＴＡが送信側と受信側いずれかの管理下にない第三者であるということはあまりありません（あるとしても大抵はどちらかと契約したＩＳＰです）。さらに転送経路のＴＬＳ暗号化も進んでいますし、受信ドメインのＭＴＡがＴＬＳ対応であることを広報したり、ＴＬＳ以外での受信をしないことを宣言できるＭＴＡ－ＳＴＳ（MTA Strict Transport Security）という規格の普及も始まっています。ですので、ＳＭＴＰが暗号化していなかったことに起因するメール盗聴リスクはほとんどなくなってしまっていると思われるのです。注意するべきは経路上のＭＴＡが不正アクセスを受けて中継メールが読み取られているリスクですが、これこそＰＰＡＰ方式では全く対抗できません。

（２）クラウドストレージ等を用いて送る
Google DriveやOneDrive、Dropboxといったクラウドストレージだと、やり方によっては受信者を確実に指定できますし、ファイル伝送路での暗号化も保証できます。仮に受信者を間違って指定してしまったら、気づいた時点でファイルの共有を無効にすれば、それが運良くファイルダウンロード前なら情報の漏洩も防ぐことが出来るでしょう。受信者側の立場からしても、システムにもよりますがファイル送信者（この場合にはファイル共有元）がメールよりは詐称しにくい場合が多く、標的型攻撃に逢うリスクも下がります。ただし問題は双方が同じサービスを利用しておかねばならないことですが、その対策として一部サービスではＵＲＬを認証代わりにして、そのシステムにアカウントがなくてもファイルをダウンロードできるシステムがあります。この場合にはそのURLをメールで送ることになるため、メール盗聴での情報漏えいリスクがありますが、これも本来受信するべき相手がファイルを入手したことを確認した時点でＵＲＬを無効にすれば、単純なメールへのファイル添付よりはリスクが軽減できます。面白いのはFirefox sendで、ＵＲＬでの送信に特化する代わりに、ダウンロード回数と有効期限を必ず指定することになっているため、手軽に「通常のメールへのファイル添付よりは漏洩リスクの少ない」ファイル送信が行えるので、最近愛用しています。

他にリスクとして残っているのは、これらのクラウドストレージが実はファイルの中身をインフラ側で見ているのではないか？という問題です。ただ、それをリスクに感じるならそれこそ、パスワード付きｚｉｐにしてしまい、パスワードはメールで送れば良いのだと思います。ただし、長く複雑なパスワードにして。

（３）ビジネスチャットやＳＮＳ等を用いて送る最近SlackやTeams、ChatworkやLINE Workといったビジネスチャットが広く使われるようになったので、これが使えるのであれば送受信者がお互いに相手を確認しながら暗号化状態でファイルを送受信できます。ただ、これも厳密にはＥ２Ｅの暗号化ではないので、必要ならパスワード付きｚｉｐにして送り、パスワードだけメールで送るなどの対応をすることになるのでしょう。また、一般のＳＮＳのファイル送信機能も同様に利用可能ですが、業務の上でこれらのＳＮＳを使うことはポリシーの上でも許されない場合が多いかもしれません。

本来はＳ／ＭＩＭＥやＰＧＰの普及を促すべきなのでしょうが、とりあえず脱ＰＰＡＰを目指すことは、メールのセキュリティをもう少し本質的に考え直すよい機会でもあります。少なくとも、現在メールの
リスクを下げる上では、標的型メール攻撃を防ぐためのなりすましメール防止策と添付ファイルのマルウェア対策と、ビジネスメール詐欺を防ぐためのメールアカウントへの不正アクセス防止策の方がずっと優先度が高く、また誤送信防止はもう少し別のシステム的な対策が必要なように思っています。いずれにせよ、ＰＰＡＰ方式ではほとんどリスクが軽減されておらず、生産性低下だけが起きていることはもう少し認知が広がっても良いのではないかと思います。皆さん、「くたばれＰＰＡＰ！」ですよ。

追伸：ＰＰＡＰに加えて、ＰＨＳというのも撲滅したいのですが、それは稿を改めて。
ＰＰＡＰを何とかしたいがＰＨＳも何とかしたい（ＰＤＦ版）

【著作権は、上原氏に属します】